APR Email Stability

I will check it out, thanks for the advice!

Where did you get this info? I wanted to read up on it cause we are sending out mass emails during this time of re-scheduling and change. @EarlGrei

What information specifically?

This is a relevant link from Microsoft that may help: How to set up IIS to send emails using Office 365 | Microsoft Learn

Sorry I meant to quote this ^

Thanks tanner!

Firstly the slow down is a 4.2.1 error code I believe. I havent touched SMTP error codes in years though. I used to run a mail sending platform for a popular job site before things like MailGun and similar sending platforms were popular. Learned alot. Generally speaking I have a pretty good feel for whats going on when email is involved. As for the limits I cannot remember where that came (its in my notes) from but I went and checked on it and saying that you can send more is not entirely accurate. It can give you access to the high risk pool if crazy volume is a requirement. However using Office 365 to send out massive amounts of email is not supported and WILL get you in hot water with them. Now understand that ‘massive amounts’ or ‘high volume’ is not something that a reasonable company is ever going to hit. Even accounting for sending invoices to customers and the like. Hope that provides at least some clarity @utaylor

1 Like

Lets theoretically say your email got sent and let your premises, your Customer however didnt receive it because some node in the hop kicked the bucket and their SMTP Server failed.

Who’s fault is it if they don’t pay the Invoice on time and you charge them a late fee? Who will win the court battle?

Portals all the way here :slight_smile: Email sux.

1 Like

We have brought this up many many times… me and @jdewitt6029 agree. @hasokeric

How do you ensure customers check the portal?

:thinking: Send them an email?

2 Likes

Yeah, for us if we want to do business with our suppliers that utilize a portal we have to pay them through their portal or we just don’t do business.

1 Like

I wish that a customer portal were an option but we bend over backwards for our customers and asking them something like this would damage our relationship. As far as a court battle, I would guess we ultimately lose. However, I really think it’s important to provide our customers with timely billing information so the good customers pay us on time :sweat_smile:

1 Like

For your interest, I worked on exactly this emailed invoice problem over many months. Our solution ended up having several layers.

Firstly, the invoices need to go through APR one at a time (I see you already concluded that).

We then put an email check in the APR flow, so obvious problems get diverted to AR staff for checking.

We then bcc’d an internal address so there’s a totally non-technical record of what was successfully sent.

Then there was a UD flag against the invoice header which was set to true if and only if the SysTask tables had record of successful completion, with a daily report of invoices still false after posting.

It was a lot of work over a long time, but seems to be (touch wood) failsafe so far. Obviously you can’t prove the customer received the invoice, but then you can’t prove a hard copy in the post got there either. Statements and a good AR department catch the oddities as long as you minimise all the other problems.

1 Like

There’s a login date. Simple query to follow up who hasn’t checked the portal. How do you know that a customer didn’t open the email? The user was laid off?

:phone: - just like A/R people do all of the time. :wink:

* Collections people

(fixed) :wink:

It’s probably other places on this forum but in case this helps anyone else, here is the code I ended up using for validating the email addresses being entered into my UD field taking @ckrusen’s advice . Like @jgiese.wci mentioned, this would be better to contain in a reusable Epicor function but I don’t have that option for the time being and this works for me in 10.2.300. The code is in a pre directive on customer.update.

/*Erp.Customer.Update/PRE/ValidateEmail
 * 10905 - Invoice Break and Routing
 * 4/9/20 - TP Ensure the email address(es) being entered are legit prior to allowing email field to be entered.  Called if record is added or value in UD field "InvoiceEMail_c" is changed
 */
//using System.Text.RegularExpressions
var VAPatt = @"^[A-Z0-9.&_%+-]+@[A-Z0-9.-]+\.[A-Z]{2,6}$";
var regex = new Regex(VAPatt, RegexOptions.IgnoreCase);
var sb = new System.Text.StringBuilder();

var ivalid = true;

var myc = ttCustomer.Where(r=>!r.Unchanged()).FirstOrDefault();
if(myc != null) {
  //field that contains email(s)
  string alist = myc["InvoiceEmail_c"].ToString(); 
  if(alist!=string.Empty){
    //accept a semicolon delimited list only  
    foreach(var theadd in alist.Split(';')) {
      if(!regex.IsMatch(theadd.Trim())) {
        ivalid = false;
        sb.AppendLine(string.Format("Invalid email: {0}",theadd));
      }
    }
  }

}
//throw error
if(!ivalid) throw new Ice.BLException(sb.ToString());

D’oh! I just saw that after posting.

1 Like

Sorry for the long delay. Too much work.
Unfortunately, I can’t help with APR. Although it looks similar with old BPM, it is completely different project created and maintained by another team.

Ahhhhhhh I made the assumption that the emails from Epicor all used the same base class regardless of APR or BPMs.

Most likely they use same classes. But how those classes are used depends on callers.