You could try adding a schedule to automatically process all of the pending emails for a particular mail account. I don’t see a mention of schedules in your message so hopefully this is a helpful suggestion.A automated schedule is how our system sends pending mail that goes out with the SendGrid integration.
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.
Thanks Brian for the solution but in my case I don’t have project files of the customization (unfortunately we lost the consultant) we have just dll files we can see in the customization packages, any idea how can we upgrade the dlls to make them compatible for new version? your help is highly appreciated!! I have a pretty technical suggestion, but if you’re comfortable with application development, it may be an option (Brian’s post covers this option as well). I know that JetBrains Rider comes with an “Assembly Explorer” which allows you to view a decompiled version of a DLL. This allows you to attempt the arduous process of recreating the code base by copying and pasting the decompiled code into new files you create manually. There may be other tools that allow you do decompile some DLLs but I’ve only done this with Rider on a small project and I’ve never tried to automate for something larger. Newer versions of Visual Studio may have this feature (see this blog post), but a
Based on that screenshot, it looks like you’re missing the top-level domain for both mail servers. I believe these should be smtp.office365.com and outlook.office365.com.
Marco, that worked perfectly! Thank you for sharing the information.
I’m working on setting up the Shopify connector on a local Acumatica instance and I ran into this same issue. My instance has data based on a production instance of Acumatica where every stock item has its Weight UOM as LBS. The problem the OP encountered is related to Shopify expecting the weight_unit to be “lb” for pounds and not LBS. It cannot have the S and it must be lower case.To prevent this error from showing up, I first went into CS203100 and added LB to the Units of Measure with a conversion to and from LBS with a 1.0x multiplier. I also setup a standard LB/LB from/to configuration.On the single stock item I was trying to sync, I changed the weight UOM from LBS to LB and everything worked as expected. Given that we have a lot of stock items already setup for LBS, I wanted to find a way to deal with this without having to go modify every stock item’s configuration. Here is how I accomplished a proof of concept that I think should work unless you use some other stock ite
Thanks @AndrewBGL, this was exactly what I was looking for. Most people here know how to work with filters but not everyone. If this happens again, your answers will help me figure out who I need to go do some one-on-one training with.
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.