Hi Roc, an update with new findings. The file ID and UIDs are going to you privately.
Since my last post I have been able to watch the client do the import on screen and check each record through the API as he went. The short version: the Service classification is created by the desktop import itself, not by Change to Invoice.
What the client does
The sales file comes from a B2B portal in the standard AccountRight Item sales import layout (31 columns, Co./Last Name through to Sale Status, tab delimited). He imports it with File > Import/Export Assistant > Sales > Item, Match All, with every field matched one to one and Sale Status set to I. When that invoice import is rejected (insufficient stock on a line), he changes Sale Status to O, imports the same file as an order, adjusts the quantity in AccountRight, then uses Change to Invoice.
What the API shows, checked within minutes of each step
1. Order imported from the file, still Open, nothing converted. The /Sale/Order list reports OrderType Service with a /Sale/Order/Service URI. GET on the Service path returns one line with the item name as the Description, an income account, no Item and no ShipQuantity. GET on /Sale/Order/Item/{uid} returns 404. In AccountRight the same order shows the Item Number column with the item on it.
2. Change to Invoice on that order. The invoice is an Item invoice (/Sale/Invoice/Item) with an Order link to the order above, and the order is now ConvertedToInvoice, still Service. This is the same shape as the invoice from my first post, so PUT is expected to fail with 37006 (not tested on this one).
3. Same file imported with Sale Status Q. The quote is reported as QuoteType Service with a /Sale/Quote/Service URI, and /Sale/Quote/Item/{uid} returns 404.
4. Same file imported as an order a second time. Service again.
So three desktop imports in a row (order, quote, order) from a compliant Item sales file, all shown as Service by the API while the product shows them as Item sales. For comparison, an order created with POST /Sale/Order/Item on the same file stays Item, converts cleanly through POST /Sale/Invoice/Item with Order.UID, and the resulting invoice accepts PUT. Every converted order in this file since 2020 (230 of them) is reported as Service, so this has been happening for a long time.
One side observation: the imported order and quote both come back with ShippingMethod blank even though the file has a Ship Via value on every row, and the invoice converted from the order is also blank. I have not yet confirmed what the product shows for Ship Via on those records.
Questions
1. Does this narrow the defect to the Import Assistant writing Item sales with missing layout metadata? If so, is there an import setting, a file field, or a version of AccountRight where the imported order is exposed as Item?
2. Is a fix planned, and is there a way to repair the existing records so their invoices accept PUT?
3. Until then, is POST /Sale/Invoice/Item with Order.UID against one of these Service-exposed orders expected to work, or does it need a healthy Item order as the source?
The private message with the file ID and the UIDs for the order, quote, converted invoice and the clean API pair is on its way.
