Skip to main content
Solved

REST API: Order of Events

  • February 14, 2025
  • 2 replies
  • 87 views

Forum|alt.badge.img

I am trying to change an Inventory ID on an existing SO Line via REST API. It seems the SOLine_InventoryID_FieldUpdated logic is interfering with this. 

Setup:

  1. Create an SO with an inventory item (mine is 011705)
  2. Have at least 2 warehouses available
  3. Have another inventory item (mine is 011706)

In Postman, I PUT to /entity/Default/23.200.001/SalesOrder?$filter=OrderNbr eq '180214'&$expand=Details&$select=OrderNbr,Details/InventoryID,Details/WarehouseID

{
"OrderType": {
"value": "SO"
},
"OrderNbr": {
"value": "180214"
},
"Details": [
{
"id":"fb135987-eeea-ef11-912e-00d86198c979",
"WarehouseID":{
"value":"GREEN"
},
"InventoryID": {
"value": "011706"
},
}
]
}

If the new part has a default warehouse, this request will go through, but the default warehouse will be used instead of the warehouse I sent:

{
"id": "68fc2b59-eeea-ef11-912e-00d86198c979",
"rowNumber": 1,
"note": {
"value": ""
},
"Details": [
{
"id": "fb135987-eeea-ef11-912e-00d86198c979",
"rowNumber": 1,
"note": null,
"InventoryID": {
"value": "011706"
},
"WarehouseID": {
"value": "PBNW"
},
"custom": {},
"_links": {
"files:put": "/Acu2024R2/entity/Default/23.200.001/files/PX.Objects.SO.SOOrderEntry/Transactions/fb135987-eeea-ef11-912e-00d86198c979/{filename}"
}
}
],
"OrderNbr": {
"value": "180214"
},
"OrderType": {
"value": "SO"
},
"custom": {},
"_links": {
"self": "/Acu2024R2/entity/Default/23.200.001/SalesOrder/68fc2b59-eeea-ef11-912e-00d86198c979",
"files:put": "/Acu2024R2/entity/Default/23.200.001/files/PX.Objects.SO.SOOrderEntry/Document/68fc2b59-eeea-ef11-912e-00d86198c979/{filename}"
}
}

If the new part does not have a default warehouse, the request fails with “’Warehouse’ cannot be empty”:

{
"id": "68fc2b59-eeea-ef11-912e-00d86198c979",
"rowNumber": 1,
"note": {
"value": ""
},
"error": "Updating 'Sales Order Line' record raised at least one error. Please review the errors.",
"Details": [
{
"id": "fb135987-eeea-ef11-912e-00d86198c979",
"rowNumber": 1,
"note": {
"value": ""
},
"InventoryID": {
"value": "011706"
},
"WarehouseID": {
"error": "'Warehouse' cannot be empty."
},
"custom": {},
"_links": {
"files:put": "/Acu2024R2/entity/Default/23.200.001/files/PX.Objects.SO.SOOrderEntry/Transactions/fb135987-eeea-ef11-912e-00d86198c979/{filename}"
}
}
],
"OrderNbr": {
"value": "180214"
},
"OrderType": {
"value": "SO"
},
"custom": {},
"_links": {
"self": "/Acu2024R2/entity/Default/23.200.001/SalesOrder/68fc2b59-eeea-ef11-912e-00d86198c979",
"files:put": "/Acu2024R2/entity/Default/23.200.001/files/PX.Objects.SO.SOOrderEntry/Document/68fc2b59-eeea-ef11-912e-00d86198c979/{filename}"
}
}

I also tried sending the same line twice in the same request, which has helped with other situations, but it did not affect the behavior here. It looks like changing the inventory ID triggers the normal field updating logic AFTER the warehouse has already been set. Is there any way I can affect the order those fields are processed in when submitted via API so the warehouse is set after the defaults are filled in?

Thank you for reading.

Best answer by Dmitrii Naumov

@PBSA yes, unfortunately that’s the way it works. 

You can try method PATCH in 25r1

(see release notes https://acumatica-builds.s3.amazonaws.com/builds/preview/25.1/ReleaseNotes/AcumaticaERP_2025R1_Beta_ReleaseNotes_for_Developers.pdf)

It should force update of the warehouse in this case.

2 replies

Dmitrii Naumov
Acumatica Moderator
Forum|alt.badge.img+7
  • Acumatica Moderator
  • Answer
  • February 14, 2025

@PBSA yes, unfortunately that’s the way it works. 

You can try method PATCH in 25r1

(see release notes https://acumatica-builds.s3.amazonaws.com/builds/preview/25.1/ReleaseNotes/AcumaticaERP_2025R1_Beta_ReleaseNotes_for_Developers.pdf)

It should force update of the warehouse in this case.


Forum|alt.badge.img
  • Author
  • Jr Varsity II
  • February 14, 2025

@Dmitrii Naumov This is very helpful information. I was thinking it was an order of operations issue, but you are correct, it is a result of “same” field values being ignored. I don’t have access to a 25R1 instance currently to try the PATCH method, but I confirmed that in my 24R2 instance the request does work as long as both the warehouse and the inventory id are different from what is stored. I also see now why sending a second instance of the line in the json had no effect - only fields not already mentioned are considered. Thank you so much for the extremely relevant information.