A few months back we implmented using APR to send invoice emails to our customers. At face value this all seemed to be working ok but we’ve noticed an increasing number of customers requesting copy invoices as they say they never received them. We send about 500 invoices per day but usually in multiple batches of 100-200 at a time. We have proven that the missing invoice just doesnt email. No errors we can find anywhere, certainly not the Epicor logs. Support just say its a performance issue and to review the tuning guide but difficult to know where to start. Those invoice batches print to screen fine
I’ve seen other topics on here related to mailing, that had their root cause in the rate at which the emails were sent to the sending mail server. Doesn’t sound exactly like your problem, but worth a look at.
Also, anything that stands out? Particular customers, invoices at the end of the batch, etc …?
And are your Breaking on Invoice number, or customer?
Thanks Calvin - no cant see any particular pattern at all. There is a lean towards consecutive invoice numbers for a customer failing but I wouldnt say its conclusive. We’ve calculated a 31% failure rate since June. Breaking on invoice number. Will check the mail server but seeing similar issues regardless of batch size. A 10 invoice batch seems statistically no safer that a 200 invoice batch!
Not a question directly for you but i’m traying to establish what the underlying send mechnism is. Does it create a big PDF then loop through splitting out each invoice from there or is it done back in the database/Business Object?
When using APR, the data source is split and multiple individual reports are generated. It’s the equivalent of adding a GROUP BY clause to the underlying SQL. We do have multiple customers using APR and it’s all working nicely here…
When using SMTP there is always a chance that transport might fail, or that your SMTP is getting blacklisted as spam by other relays, although a 31% failure rate seems excessive. Try to ask the customers to make sure the email isn’t getting filtered.
If there was an error sending the email or generating the report, it should show up in the report monitor when you double click the tray icon. If you are not logged in to Epicor as an administrator, you will only see your own tasks however…
If you are using an on-premise Exchange relay, check the logs on there, it will be a lot easier to see what happened.
And to be clear, a report can contain multiple invoices.
Splitting on InvoiceNum would give you one email per invoice. And each of those emails would have an attachment consisting of a single invoice.
Splitting on CustNum would give you one email per customer. And each of those emails would have an attachment ( a single PDF) consisting of all the invoices for that CustNum.
I’m pretty sure that APR will only ever generate 1 attachment. But that one attachment may contain multiple invoices (or whatever report is being processed).
One thing I’ve found is that if the TO or CC address fields get too long, APR would fail. We resolved this by creating Mail Groups in Exchange, and then use the grop instead of the half dozen individual addresses.
And lastly, some emails would fail if there was a trailing ; (the address separater character) after the last name in a list on a TO or CC field. I think trailing spaces would cause issues too.
And I’ve never had luck trying to include the displayed name with the email address.
Ex: Joe Blow <jblow@test.com> is problematic, while jblow@test.com is not. So check the entries in various locations (customer, contacts, shipto, shipto contacts, etc…) for malformed email addresses.
Thanks all
There is a BPM on the posted flag that is then invoking APR and sending with our AR invoice template
Seeing Http 503 errors in the system monitor for those that fial
Rich
What is giving the 503 errors? potentially, it could be 365 rate limit but if you are using a relay… it might be epicor, you could put in a delay between each invoice
Thanks all - seems to be related to SSRS believing there has been a denial of service attack. We’re seeing much lower failure rate this week after altering this setting