Thanks Roc, feel free to DM me and I'll provide details you are after.
I've don these on a test customer, all through the API:
1. POST /Sale/Order/Item, one line, qty 1, $0 -> 201, order 00030356, Status Open
2. GET /Sale/Order/Item/{uid} -> 200, Item line present
3. POST /Sale/Invoice/Item with "Order": { "UID": "<order uid>" } and the same line
-> 201, invoice 00030357, linked to 00030356
4. GET /Sale/Order/Item/{uid} after conversion -> 200, Status "ConvertedToInvoice",
OrderType "Item", item line intact
5. GET /Sale/Invoice/Item/{invoice uid} -> Order link present
6. PUT the invoice with the Order object exactly as returned and
CustomerPurchaseOrderNumber changed -> 200, RowVersion advanced
So an order converted through the API stays a healthy Item order and the invoice
updates normally. The failing invoices in this file were all converted with
"Change to Invoice" in the AccountRight desktop app (every converted order in the
file since 2020 shows as Service with the Item path returning 404). That points at
the desktop conversion as the step that leaves the retained order without its
layout metadata.
Two things I noticed that may help engineering:
- The API conversion assigned a new invoice number (00030357 for order 00030356).
The desktop conversion kept the order number on the invoice. The file has
"Retain original invoice number on change of status" behaviour in the desktop app.
- With "Order": {} on one of the broken invoices the API returns "Order is
required", so it does expect a link on those invoices, then rejects the only
UID it returns for them.
I will send the company file ID and the UIDs for both pairs privately: the
failing invoice 00030351 with its order, and the passing 00030357 with order
00030356, so you can compare them on a clone.
A questions while engineering looks at it:
On an API conversion, can the invoice be given the order's number by setting
"Number" on the POST, or is a new number always assigned?
Thanks again,
Daniel
