I have been doing some work with Webhooks and Acumatica, and have been running into the problem where an update done via Webhook will cause concurrency issues with editing the same Sales Order via the Acumtica front end.
The most common error is: “Error: Another process has updated the 'SOOrder' record. Your changes will be lost.”
In researching this issue and its underlying cause, I came across this blog post:
https://asiablog.acumatica.com/2018/03/another-process-has-added-updated-deleted.html
It seems that Acumatica is using record timestamps a a way of managing concurrency. However, this seems like a bad idea. Especially in a web based world where many users can potentially update a record, it seems we would want to use the actual content being saved to determine if we have a concurrency issue or not. If there is no conflict, then we shouldn’t care whether one user is saving on top of another (or at least, we should let the user decide whether it’s a problem or not).
The most obvious example I’ve seen of this is when I will:
1) Open a sales order in acumatica
2) Save line items to sales order externally and save -via webhook code
3) modify sales order header in open acumatica window and try to save…..conflict
There is no overlap or conflict with the data in this case. If one were to hash the individual fields of the three objects, the original sales order object, the new one saved via webhook with additional line items, and the final object with modfiications to the header (and the new sales order lines...since they are pulled in via the transactions section refresh), there is no inherent conflict here. The only conflict is with the timestamps.
Is anyone at Acumatica thinking about this issue? I would point to Git as a better model for managing concurrency than the one being employed here...