Skip to main content
Solved

22R1 v118 & v120 not attaching incoming mail to purchase order activities


PorchlightZach
Varsity II
Forum|alt.badge.img

The second week of March we upgraded from 21R1 to 22R1.  Immediately after the upgrade all of our incoming emails related to purchase orders started failing processing with this error:

 

CR Error: Unable to create new case. Business Account is Vendor.

 

Following the hint of the error message, I created customer accounts for a couple vendors.  While this makes the error go away, these messages are now turned into Cases instead of being attached to the related entity. This seems to only be an issue for purchase orders.  Our incoming sales order emails are attaching activities normally.  Originally I thought it was because those emails come from Customers and not Vendors.  However, at the end of this message I’ll go over some of the testing I did before posting here.  The results suggest this is more than just a vendor/customer issue.

 

Prior to the upgrade, we had a total of 20 incoming purchase order email messages fail for some reason or another.  Now, they're all failing until I create a customer for the vendor and then they create cases, like previously mentioned.  This was not how it worked before and is not how we want it to behave.  I’m sharing that just to point out that this used to work quite well before we moved to 22R1.

 

When we first upgraded to 22R1 we were using minor version 118.  Last week I upgraded the system to 120 to see if some other issues would be resolved with the upgrade.  The problem with email processing for purchase orders remains, unfortunately.

 

Before posting here, I setup new system email accounts just for sending/receiving purchase order emails.  There is an Office 365 account for incoming messages and an outgoing account configured to use Sendgrid. 

 

I created new accounts primarily so that cases would not be created from every reply to a PO email.  The secondary reason was to make sure this wasn’t something off with email processing related to the upgrade.  I’ve run into problems with mail processing after making changes to system email accounts.  Needless to say, I’m posting this because creating new email accounts did not resolve the issue.

 

After creating the new account I tested it by sending an email from an existing purchase order’s activities screen.  When I replied to the message with my work account the system downloaded it, but it did not attach to the PO.  My work email is not associated with a vendor in the system.   This is the part that suggests this isn’t really a vendor/customer processing issue.  This seems more like a purchase order activities issue.  

 

I’ll attach an image of the details tab for my incoming message so you can see the related entity has no value:

 

Is this a bug of some kind?  Alternatively could this be a configuration issue after our upgrade?  I looked at the known issues and searched the forum but did not find anything directly related to this.  I submitted logs from the trace that shows the error when a message is processed.  The GUID I got back from the log submission was ebc8b037-f951-4324-b649-7dc784bc6dde.

If this is actually a known issue and I just didn’t find it, is there a work around or a fix?

 

Thank you!

Best answer by PorchlightZach

After working with support and doing a bit of testing on my own I narrowed this down to being a side effect of sending mail using the SendGrid email provider.    Once I conveyed my suspicion of SendGrid being the reason for our issues, support indicated that this was a known issue that is fixed in 22R2. 

(edit) The problem is that tracking numbers are not getting postfixed to email subjects for outgoing mail from a SendGrid account.  This makes it appear that every reply is a new email, not an existing one that should be processed by Acumatica.  I’ve gathered that the “incoming mail processing” option on a standard account configuration screen is the setting that triggers tracking numbers in outgoing email subjects.  Since that setting is not present on the configuration screen for a SendGrid email provider, it cannot be enabled in the UI.

While I cannot upgrade our system right away, there is a workaround that involves a SQL command that should fix the issue.  I’m going to mark this as the answer, although I have not tested it.  The SQL command works but last week I switched all of our outgoing notifications to send mail with standard mail providers so the underlying problem would be solved asap.  If I do not send a reply saying this did not work, you can assume it did.

This is what our support rep sent me:

This is because this System Email Account cannot be marked as Incoming Email Processing as enabled because this tab does not exist from the SendGrid account. This issue has already been fixed in 2022R2.
https://community.acumatica.com/supported-releases-67/acumatica-2022-r2-downloads-and-release-notes-11493

Acumatica ERP 2022 R2 Release Notes: Fixes and Enhancements containing the list of fixes and minor enhancements introduced in Acumatica ERP 2022 R2: https://acumatica-builds.s3.amazonaws.com/builds/22.2/ReleaseNotes/AcumaticaERP_2022R2_ReleaseNotes_Other_Enhancements.pdf

AC-218404: If a user selected the SendGrid plugin in the Email Service Plug-In box in the Summary area of the System Email Accounts (SM204002) form, the system did not support the incoming mail processing by default.


You can workaround the issue in the current version 2022R1 by executing an SQL update:


update EMailAccount set IncomingProcessing = 1 where EMailAccountID = <EMAILACCOUNTID> and CompanyID = <COMPANYID>

 

Updated to remove company specific ID numbers.  Change <EMAILACCOUNTID> with the ID for the outgoing SendGrid mail account for your system and <COMPANYID> should be the company ID that account is associated with.

View original

PorchlightZach
Varsity II
Forum|alt.badge.img

I am still hoping for an official solution to this.  However, since I did not want to just let this problem sit and increase confusion for my coworkers, I created a graph extension for CREmailActivityMaint with an action button that fixes this problem. 

I’m using a business event to automatically find these with a filter tab on the Incoming GI in Time and Expenses.  I’m attaching a .txt file that contains some modified code that matches what we’re using temporarily.


Dana Moffat
Acumatica Moderator
Forum|alt.badge.img+2
  • Acumatica Moderator
  • April 11, 2023

Hi  @PorchlightZach ,

Have you reported this issue to Customer Care or your Partner?  

 

 


PorchlightZach
Varsity II
Forum|alt.badge.img
Dana Moffat wrote:

Hi  @PorchlightZach ,

Have you reported this issue to Customer Care or your Partner?  

 

Yes, my partner is opening a support case with Acumatica. 

I’ve been in the habit of posting here before I contact my partner when I run into issues I cannot resolve on my own.   Even if no one in the forums knows of a solution, I figure documenting my issue here could benefit someone else down the road.  Plus, it means I already have my problem typed out with a URL to share when I do email my support contact.  

When I hear back from support, I’ll be sure to update my post with whatever answer I end up getting.


PorchlightZach
Varsity II
Forum|alt.badge.img

After working with support and doing a bit of testing on my own I narrowed this down to being a side effect of sending mail using the SendGrid email provider.    Once I conveyed my suspicion of SendGrid being the reason for our issues, support indicated that this was a known issue that is fixed in 22R2. 

(edit) The problem is that tracking numbers are not getting postfixed to email subjects for outgoing mail from a SendGrid account.  This makes it appear that every reply is a new email, not an existing one that should be processed by Acumatica.  I’ve gathered that the “incoming mail processing” option on a standard account configuration screen is the setting that triggers tracking numbers in outgoing email subjects.  Since that setting is not present on the configuration screen for a SendGrid email provider, it cannot be enabled in the UI.

While I cannot upgrade our system right away, there is a workaround that involves a SQL command that should fix the issue.  I’m going to mark this as the answer, although I have not tested it.  The SQL command works but last week I switched all of our outgoing notifications to send mail with standard mail providers so the underlying problem would be solved asap.  If I do not send a reply saying this did not work, you can assume it did.

This is what our support rep sent me:

This is because this System Email Account cannot be marked as Incoming Email Processing as enabled because this tab does not exist from the SendGrid account. This issue has already been fixed in 2022R2.
https://community.acumatica.com/supported-releases-67/acumatica-2022-r2-downloads-and-release-notes-11493

Acumatica ERP 2022 R2 Release Notes: Fixes and Enhancements containing the list of fixes and minor enhancements introduced in Acumatica ERP 2022 R2: https://acumatica-builds.s3.amazonaws.com/builds/22.2/ReleaseNotes/AcumaticaERP_2022R2_ReleaseNotes_Other_Enhancements.pdf

AC-218404: If a user selected the SendGrid plugin in the Email Service Plug-In box in the Summary area of the System Email Accounts (SM204002) form, the system did not support the incoming mail processing by default.


You can workaround the issue in the current version 2022R1 by executing an SQL update:


update EMailAccount set IncomingProcessing = 1 where EMailAccountID = <EMAILACCOUNTID> and CompanyID = <COMPANYID>

 

Updated to remove company specific ID numbers.  Change <EMAILACCOUNTID> with the ID for the outgoing SendGrid mail account for your system and <COMPANYID> should be the company ID that account is associated with.


Chris Hackett
Community Manager
Forum|alt.badge.img
  • Acumatica Community Manager
  • April 24, 2023

Thank you for sharing your solution with the community @PorchlightZach !


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings