I have a REST API customization from my own code. Trying to do consecutive Updates to a single PackLine in Customer Shipment Entry. I Create a Dataset that Updates the PackLine using Erp.BO.CustShipSvc.ShipDtls POST, The post takes place successfully and the PackLine is modified as expected, but the Returned Dataset is always for the Last PackLine on the Shipment, not the submitted PackLine that was changed. This has caused all sort of inventory related inconsistencies because I had expected the Return dataset to be the completed modification of the same PackLine…
I am now correcting my code to ignore the Returned dataset and go get a new ShipDtls record for the exact PackLine I am working with (Though this is hardly efficient). I have also created a support case with Epicor to get the transaction corrected. I am not sure if other transactions have the same issue, so a warning to others to verify the returned dataset of a POST that Updates a record is actually the data you are expecting.
Epicor has acknowledged the bug and will be fixing it, but appears to be affecting at least ShipDtl and possibly other transactions at 2023.1.10 and earlier.
I was astounded at the first response to the Case was “We replicated the issue and logged a bug report for it. It appears to be a problem with the UpdateExt”
To be honest I am not replicating the REST calls from the application for this transaction. We have a tendency to work with some very large Mark For orders and the Epicor Update process can get excruciatingly slow (Like 5 minutes to save), either through Epicor or through REST. So my calls are bypassing the Full Customer Shipment record processing that Epicor uses from Customer Ship Entry Screens, and only updating individual Lines separately.