One quick addition:  Each time this has happened I’ve logged into the shared mailbox and re-forwarded the message in question to the system email account. 

When I do this, I replace the “Fw:” prefix on the subject with “Re:” in an attempt to more closely mirror what a customer reply would look like.

Each time I do this, the message ends up in Acumatica.  The same is true for the most recent message.  It is showing up out of order, with today’s date instead of the date the customer replied (as expected).

I find this suggests that there is nothing inherently wrong with the message’s contents.

Now that my coworkers are more aware of the fact that this is happening, I believe it occurs more frequently than previously thought.  

On Tuesday, a message was sent to a customer through Activities on a sales order letting them know that we would have to use a faster shipping method to meet a requested shipping date.  That email went out at 11:49 AM central.  The customer replied at 2:04pm (14:04:50 to be precise) and that message is not in Acumatica, but I saw it in the inbox for the system email account. 

I checked the scheduled status history and can confirm there were no errors before or after the time the missing message was delivered.  Here is part of an export of the log for that day.  Unfortunately, it doesn’t show the seconds indicator in the timestamp.  A database query on AUExecutionHistory shows me that the 14:04 and 14:09 checks happened at 33 seconds.

11/29/2022 1:59 PM    1    1    0    0    Processing completed
11/29/2022 2:04 PM    1    1    0    0    Processing completed
11/29/2022 2:09 PM    1    1    0    0    Processing completed
 

If Acumatica downloaded mail at 14:04:33 and the customer email showed up at 14:04:50, could it be possible that Acumatica skipped it because it isn’t taking seconds into consideration when loading newly arrived emails?  I don’t know enough about how the system email account downloads mail to know if this is a silly question or not, but I can’t think of another reason it would skip emails like it has been.

I had the system downloading email every 5 minutes but I plan to increase it to 10 minutes so there are fewer chances to skip emails each day.

I’ve been continuing to track this issue with our system email account and the amount of mail Acumatica is not downloading is much larger than I originally thought.

Part of this was due to some erroneous assumptions on my part.  I had the send/receive email process scheduled daily between 4am and 8pm on week days.  My assumption was that any email that showed up outside the scheduled time would automatically be downloaded the next time the system checked mail.  This is how any other mail client works. 

Based on the read/unread status of messages for this inbox and searching for the unread messages in the ERP, that is not the case at all.  Every message received from 8:00 PM Friday to 4:00 AM Monday remains unread in the inbox and is not in the ERP.

Obviously it is easy for me to change the email schedule to send/receive on the weekends without any downtime.  That does not solve the issue of the messages that are not being downloaded when the schedule was running before.  

I see at least 47 emails that were not downloaded from today but showed up during the scheduled send/receive email timeframe.   As there are no errors showing up in the history for this scheduled task, I remain at a loss for what to do about this.   

This situation puts us in kind of a bad spot.  It looks like we’re ignoring our customers which we would never do on purpose.  The easiest way to avoid this would be to tell people to check the inbox where these messages show up.  If I do that, they’re bypassing the ERP entirely which defeats the purpose of why we have all of this setup to begin with.

Did you ever get this resolved? We are also having issues with the incoming mail not showing up in Acumatica. Thanks!

Hello!

Hope all is well today, I do have a suggestion for getting email to redownload into Acumatica.

Newer versions of Acumatica have an option on the system email account to leave messages on email server as read, unread or delete. 

However any version before 22R1 does not have this option, and the email must be “unread” in the inbox for IMAP to sync this into Acumatica. 

Sometimes not even that works though, and for those instances, my suggestion is to do the following things
1. Move all those email that have not been downloaded into Acumatica to a new folder in Outlook
2. Mark those emails as “unread”
3. Move these emails back into the inbox folder 

Doing these actions will basically reset those emails on the email server, and because they are unread (and ‘new’ because we moved them between folders in Outlook), Acumatica IMAP should be able to sync those into Acumatica. 

I actually just solved this today!  A couple weeks ago I dug through the known issues for 2021 R1 and found that AC-203243 looked very similar to our issue.  Given what I described above regarding the changes that were made to our system email account, it seemed pretty likely, even if our change wasn’t entirely the same thing as that issue described.  Here is the text from the known issues page

AC-203243: The system did not receive some emails sent to an IMAP mailbox if on the System Email Accounts (SM204002) form, for a system email account, the email address was changed to one configured to use the IMAP incoming protocol.

Workaround: For the system email account, change the incoming email protocol to POP3. Also, avoid changing the email address for existing system email accounts, create a new system email account instead.

The issue suggests this was fixed in 2021 R2, so maybe just upgrading will work for other people.  

I did not want to use POP3 for our email processing and I couldn’t do a quick upgrade to 21R2.  Instead, today I setup a new app registration in our Azure AD and created a new system email account that pointed to the same inbox as the one we were using.  I kept the previous system email account in place and manually went through our screen configurations that referenced default system email accounts to replace the old account with the new one.  

When I finally triggered a send/receive all action, Acumatica went into the account and downloaded all of the messages it had missed.  At first, I thought it was just grabbing everything and duplicating emails and cases, but after spot checking in both places, that was not happening.  

If you create a new system account like I did, I recommend disabling “Route employee emails” in the advanced settings tab.   Our system generated a fair amount of routed email to my coworkers before it completed the first pass at the inbox.   

If you’d like to prevent any cases from being created while the new account syncs the first time, you could turn off Incoming processing as well.  Just remember to turn both settings back on when you’re ready to use the account for real (if you use those options).

Thanks for sharing your solution. We are upgrading to 2022 R2 in the next week or two, so I was waiting until after the upgrade to see if this is still an issue. If it is I will try one of the suggestions above and see if we can get the incoming emails to work again.

we are using 2019R1 and recently we have started noticing similar issue. Any workaround to get the emails downloaded until we do the upgrade?

If you create a new system email account (SEA) to download the same inbox as your existing account, it should work.   Be sure to update any automation schedules so that it only downloads mail for the new account.

If you’ve specified the original SEA as the default for any notification templates or mailing settings, you’ll want to update that to use the new SEA.  Afterwards you can mark the original SEA as inactive.

@PorchlightZach , after re-creating a dummy SEA, we now see all the emails that were previously archived on Acumatica have been recreated with Processed status. Any idea if this the expected behavior?