Hi Guys,
We have a challenge where we need to try develop a solution to report on statement delivery. So when a bulk statement process is run we need to report on the delivery failures.
I understand that the delivery failures should be visible in the mailbox for the account that was used to send but is there any clever way this can be reported on in Epicor? Or is the only way going through the mails in the mailbox?
The customer ideally would like a report of all failed statements.
Just curious…
Was wondering if you are talking about the printing/emailing of Customer Statement report(s)?
If so, how have you been processing them?
Yes we using advanced print routing on the customer statement report. We have a mass email report style and in the print routing we email to the relevant customer based
on the email address captured on their customer record.
OK, Thanks.
Hmmm…
I do remember it being necessary to find errors in the APM module.
But… I hadn’t really thought much about this exercise in the newer, Advance Print Routing… yet.
I haven’t done this with statements but we had a similar requirement for invoices, where Finance demanded proof that each individual invoice had in fact been sent. It’s tricky, because just the fact of the printing being triggered isn’t enough to prove that. We went through a phase a while ago where the Task Agent would bog down and we could never be sure which tasks had been completed, and while it’s been fine for some time that possibility has stuck in people’s minds.
Our first step was to bcc a record-keeping internal mailbox. That doesn’t help with a list of non-sent items, but our APR uses anonymous Exchange routing so there isn’t any other record to point to when somebody argues whether something was emailed.
We also have a custom field on InvcHead (I’m not sure where you’d put such a thing for statements) that’s an additional “sent” boolean. We have a periodic routine running (kicked off by Service Connect in our case, but other ways are possible) that looks in the System Monitor tables for records showing that the invoice document was produced and sent successfully, which updates that field. So the final step is just a dashboard (or report if you like) showing documents which should have been sent but haven’t had that field set.
So if the scope is specifically to track delivery failures then, it might be worth taking a look at what forms of logging you have on your mail servers to capture delivery failures. You may then be able to take the log data and manipulate it into a form that could be transformed into a Dashboard with an External BAQ, an SSRS report or even a web page that you could add to the active desktop.
I have seen posts for Routing and Breaking that show a condition for validating the email address and if false sends an email stating such, but from what I am reading you are actually past that point in the process. Unfortunately I don’t have any working examples of this sort of thing, but, technically I see no reason why it wouldn’t, but you really need to know how the mail is being delivered, and what mail servers it passes through before it leaves your domain before you can work out what data you can get back about the errant email.
Interesting problem and something that I will be looking more deeply into the future once we finally are up and running. 
I usually add a condition that looks for an @ in the email field.
If that is false, I email the failed record to the AR team.
If you are using Office 365, setup print routing to send using a shared mailbox. Make sure the delivery failures go there too.
Thank you guys for your insights. Appreciate it.
Apologies for not mentioning clearly but we do need to try determine the statements that were not sent because of blank or invalid email addresses. Thank you @bderuvo for the suggestion on this. We could also do a basic dashboard for them to view the problematic email addresses which they can review before sending the statements.
Another reason could be that there was no movement on the account and hence the reason for the statement not being sent (as I understand it) so this is a bit more tricky. If you have DocStar you can attach the generated statement to the customer record which would be an indication whether there was a statement or not but we do not have DocStar. Perhaps the only way to deal with this one is to physically check the customer account when they call about not receiving a statement.
Lastly in addition to other suggestions (@Hally, @dhewi) I thought perhaps we could use an external platform like SendGrid to send the emails since they keep track of all sorts of information around the email delivery etc. This would mean an additional cost though (and would have to check if indeed it can be used with APR emailing).
What do you use currently for your email server, surely there is a way to get delivery reports on failed mail delivery that way? It’s not always a bad email address format in the email address that causes the problem @bderuvo mentioned, for example the email address field has an @ in the string, but the domain is wrong or for some reason the recipient is not at that company any longer and their IT department decided to blow the account away instead of aliasing it.
There are a lot of permutations. The question really is how far do you go to get those statements delivered! and more importantly how much is the company willing to pay in pursuit of excellence/accuracy…Needless to say that’s going to really dictate the effort.
It’s easy to email the report, still have to get the invoice paid!
“Information System” : People and Computers/Software working together. ML and AI have gone a long way, but some of this Customer Relationship/Credit Collections still requires the personal touch…I’m not sure if a “Hey Google. Get that invoice paid” will work currently…no doubt a response like “I’m not sure how to help with that” will ensue. 
Here’s a really wild thought. Have the email contain a picture whose URL contains a unique code, so when their mail program requests it from your server, you could log the request into a DB.
Kind of like how spammers used to see if a email address was “live” but logging the requests for the image files.
That would even give you the ability know if the email was opened (assuming the trust you enough to allow pictures from your domain)
If anything needs this level of surveillance then we use Marketo for it, as it does all of that kind of thing for you. But for us it’s never felt necessary for Finance-related things, and I can’t help feeling it’s out of proportion to the need.
Plus I for one have all my email clients set to not retrieve images for that very reason, so it’s still not foolproof. I personally think that if you can prove something went in the first place, that’s the best you can hope for.
If you have email logs (we don’t, because Epicor is set to use an anonymous account) then PowerShell can help. We do have some things were a periodic PowerShell script sucks up data like that and puts it in a DB table which Epicor and BI can read.