AcumatiCares
Introduction
Troubleshooting Platform Errors on Acumatica can be difficult. In general, we expect error messaging to tell us the exact thing that has gone wrong. Unfortunately, there are errors that the platform engineers cannot anticipate. Acumatica can hardly be blamed when my custom software causes an issue when integrating with the standard product. Sometimes the xRP Platform will throw generic errors or worse, no errors at all.
As an example, our product, SPS Commerce EDI has a process that will automatically pack shipments based on a complicated set of options. We will create x number of packages, content for each package with y number of items from the ship lines, assign pallets, etc. We also have a processing page where the customer can pack multiple shipments at a time. It is like shuffling cards or making a giant Dagwood sandwich. The looping gets complicated, and I have run into a few issues along the way.
Below are two of the toughest problems I’ve come across and I detail them here because I hope my experience will be helpful for others. These two problems do not generally throw exceptions and you only find out about them when you try to save the work at the end of processing.
Timestamp Issues
The dreaded Another process has updated the ‘xxx’ record. Your changes will be lost. error has a lot of possible causes. One of which is that the object you are currently working with has a timestamp value that does not match the database and is younger. If you try to save the shipment back to the database when it is out of date, the process will throw an exception. Obvious right? However, it may be that you have updated a related DAC object that because of some connection, will also cause the header object you are working on to update in the database.
As an example, I have some code that performs some transactions against several Acumatica tables in a separate transaction scope. I update SOPackageDetail and SOShipline before refreshing those caches and beginning to pack. I have found that in some scenarios, once the transaction scope is committed, the SOShipment object I was working with was now out of date in relation to the database. When I went to save my changes at the end of processing, the exception was thrown. The takeaway is that other processes may update the cache and even save to the database while you interact with Acumatica. If you get this error, your objects may need a refresh from the cache.
Failed Insertions
One of the most frustrating issues I have come across while working with Acumatica is when an insertion fails with no exception. The object returned at the end of a cache insertion is null and there is no error to describe the problem.
GIST: https://gist.github.com/patrick711/40653d1db0358bfcede94011fb7df22c
My understanding is that there are three main reasons for this:
- Inserted record is of the wrong type. What you sent is not of the correct DAC. This one is pretty easy to spot
- The save was cancelled in a RowInserting event. Some event logic tied to the Cache may be cancelling the insertion.
- PXParent and PXLineNbr attributes. If your DAC is in a Parent-Child relationship. You might find that the record was refused because your cache is out of sync with the .Current record of the main DAC. In particular, the PXLineNbr attribute can cause issues if it can’t correctly calculate the next line number based on the .Current parent.
Conclusion
Hopefully, this article will give you a place to start the next time you run into similar errors. It’s easy to feel like there is nothing to work from in these instances. At the very least, the next time you find yourself banging your head against your desk because of vague and non-specific errors, remember that no, Acumatica doesn’t hate you and yes, there is a reason for the error even if the message is not nearly enough.
Take a deep breath and examine the relationships that the DAC you are working with might have with the Database, the Event Model, and to other DACs.
Happy Coding!
Patrick
