PUT Sale/Invoice/Item returns 37006 "Cannot update order on existing invoice" for any invoice converted from an order

Hi daniel_bcd​ ,

Thanks for the thorough write-up — the matrix of payloads (including a no-change GET→PUT) and the Item invoice / Service order mismatch is exactly what we needed.

What I can see with early investigation is error **37006** (`CannotUpdateOrderOnExistingInvoice`) is documented behaviour for changing an invoice’s linked order after create: the API will not let you add, remove, or retarget `Order.UID` on an existing invoice. See [API Errors & Warnings](https://developer.myob.com/api/myob-business-api/api-overview/error-messages/) (“Cannot update Order.UID on existing Invoice”).

On a normal converted invoice, a PUT that **keeps the same** `Order.UID` from GET (and only changes fields like `CustomerPurchaseOrderNumber`) is expected to succeed. Your control case (invoice with `Order: null`) matching that pattern confirms the rest of the payload is fine.

What you are hitting looks like a **data/layout edge case on the linked order**, not a supported “you cannot update converted invoices” rule:

- The invoice is Item and correctly linked to an order.

- That order is exposed as `OrderType: Service`, with `/Sale/Order/Item/{uid}` 404 and `/Sale/Order/Service/{uid}` returning description-only lines.

- That pattern (Item sales living under Service after import / conversion / missing layout metadata) has been reported before.

In that situation the update path can fail the order-link check even when you send back the same `Order` object GET returned — so there is **no supported PUT payload** that unblocks these invoices today. Editing the same invoices in desktop/browser works because that path does not go through this API validation.

Options I can think of:

1. Set or correct `CustomerPurchaseOrderNumber` in AccountRight (desktop or browser) for the affected invoices.
2. For **new** work: prefer converting a healthy Item order via `POST /Sale/Invoice/Item` with `Order.UID` (or convert in product from an order that still appears under `/Sale/Order/Item`), and set `CustomerPurchaseOrderNumber` on create/convert where you can.
3. We are treating the “GET Order echoes back but PUT 37006” case on Service-misclassified converted orders as a product defect to investigate — if you can share company file ID and one invoice/order UID privately (support / DM), that will speed confirmation on a clone.

The answers to your questions:

1. Not a documented “desktop convert = read-only via API” limitation; it is unexpected failure of a same-`Order.UID` update when the retained order is misclassified as Service.
2. No alternate endpoint for patching only `CustomerPurchaseOrderNumber` on invoices — PUT on the layout endpoint is the supported update, and it is failing here.
3. Invoices converted via API (or browser) from a correct Item order are expected to allow later PUT with the same `Order.UID`. We would not expect the Service/404/Item mismatch on those. Worth a small repro on a test file if you can.
4. The retained order showing as Service while the invoice is Item is a known class of layout-metadata issues (import / conversion / missing layout property). It is related to why the PUT fails, not a separate cosmetic quirk.

Happy to follow up on the thread once I have a clearer fix/workaround from engineering.

Thanks Roc