i’m not sure what else there is to check. wow
if you use the standard EMAIL option in the PRINT/PrintPreview/Generate option for these customer invoices
and enter the same email addresses … are they also duplicated?
if you actually print to hard copy - do you get multiple copies?
PS: can you try to change the APR to PRINT instead of EMAIL to see if multiple copies get generated from the break
i don’t know of any “# of COPIES” setup by customer
i am at a loss
Hi Al,
Thank you for your ideas. I appreciate your help. We actually have a print step in this rule off the same break. Printing does not produce duplicates, even for the same customer. I have not tried the standard email option, but I will have our team give that a try and see what the results are. Thank you.
Which field(s) do you use?
For example, our APR for OrderAck has two report fields in the “To:”
With #1 being
and #2 being:
both of those are derived by the RDD - It determines the value based on whetehr certain fields are populated or not. There could be a bug where that field gets calculated wrong.
Duplicate the Report Style, and then add the field you’re using for the “To:” to be displayed on it, and see if it appears as a single (and valid) email.
One last thing; I’ve had issues when an email address had a trailing semicolon added to it. Semicolons are often used as the separator.
Okay … One really last thing …
The email addresses are in the form
name@domain.com
and don’t include the brackets < > like
<name@domain.com>
We are using a UD field to contain the email. It does not have <> within the address itself. The email address on the form is a single email without <> or semicolons and is valid.
any luck?
Sorry for the delay. Had to arrange a couple things to conduct the next series of test with someone overseas.
So I got in contact with one of our customers who experience this issue with almost every email we sent them from Epicor so I could conduct tests using their email since I cannot reproduce this issue with any email.
I tested using the standard Email functionality from Invoice Entry and bypass APR, I still get duplicates. This fits in line with my earlier theory that the commonality with the emails that duplicate are related to the extended smtp transaction time that occurs for certain recipients at certain times (I confirmed this was true when I did these tests) and something on the Epicor or IIS side that trigger numerous attempts every 30 seconds until it is successful (whatever that looks like I don’t know) and or times out (produces the error) after 90 seconds which basically adds up to three attempts which is normally the number of emails being sent out. I can query the DB and see that the start time and end time with seconds adds up to 88 or 90 seconds on average.
I’m stuck but I sense I’m closer that I was before. I’m still looking for something to outline what sort of response or test Epicor is doing when it sends out and email and where or how to control that so it can allow for a longer transaction time.
Any ideas?
we’ve had trouble in the past using hosted SMTP server to send out APR emails - specifically, the APR process seemed to run so quickly the combined components Epicor/APR/SMTPserver was overloaded. Resulting in the email NOT being delivered. But never a timeout issue.
I do believe - from my email days - MS email server will queue up emails to be delivered - and in the event of some internet connectivity issue, will hold them in an OUT queue until such time as they can be sent - but that is not a timeout condition.
i would expect getting help on the SMTP / email server side to see how these messages are being presented and sent/forwarded.
there are also the epicor client config - in which there are some timeout parameters. but not certain which one.
it is a pickle of a problem
here’s a link to sending email via PowerShell. It might shed some light on things if you take Epicor out of the equation.
Make a simple powershell script like the on on that linked page, and use the same SMTP settings that E10 is using (these are found in “Company Maintenance”, on the “Email and Reports” tab. If they get three copies, then its not exactly E10’s fault
Hi Calvin, thank you for the suggestion! I actually have already tested that, though I used a different powershell command. When I use this command or a mail client like outlook, the results are good (only one copy is sent). This is why I strongly suspect it is Epicor or the IIS App Pools that Epicor is using.
So finally, we have found out the cause and solution. I will try to keep it brief:
Confirmed by Epicor Support, Epicor 10 is hard coded to retry an email operation after 30 seconds if there isn’t an smtp acknowledgement provided by the smtp server within that timeframe.
The default timeout for Exchange servers to provide an acknowledgement (what’s called the MaxAcknowledgementDelay) when it’s still processing a request is 30 seconds. What this means is that if an email does not fail or succeed within 30 seconds, the email server will still continue to try to send the message for a length of time but at least provide back an acknowledgement message to the sender (Epicor) indicating that it’s email is still in process.
The customers having issues, as I mentioned before, have excessively long smtp transaction times, for what could be a variety of reasons which ultimately take anywhere over 30+. This is why it only happens to some of our customers.
I have configured our email server to provide an acknowledgement within 10 seconds so that Epicor gets the response it’s waiting for well before the timeout. This prevents Epicor from sending additional email send requests every 30 seconds and then ultimately producing the ‘Operation Timed Out’ error despite all emails actually sending.
Thank you everyone for your help and ideas. Hopefully no one else encounters this issue, but if they do they can find this information here.
matthew,
thank you for providing an explanation.
what an arduous journey you had travelled.
The result is that ‘ITS FIXED!’ yeah
APR (and printing in general) uses the standard .Net SmtpClient. The timeout is set for 30 seconds. It will try to send two more time. This is 10.2.500 (as well as what’s in 10.2.600 at this minute).
Hi, Sorry for the late on this.
Is this time from when the task was submitted or from the time epicor attempts to send the email.
Thanks
I’m sorry I don’t recall and we obviously haven’t had the issue for me to check. I think it was from when the task was submitted.
I checked the time stamps on the emails that were duplicated, and they were 5 seconds apart. Not the 30 that you motioned.
Our company is experiencing the same thing, we have made this change on our end and the issue is still happening. Any ideas? I should mention that this seems to only happen for emails that are going to external addresses. Emails that go to internal addresses are ok.
What system/service are you using for email?
Outlook/exchange
Have you used an online tool to conduct some smtp tests to validate that the transaction time for the recipients your are experiencing issues with exceeds 30 seconds? This would help to ensure your are having the same problem we had.