Purchase Orders Realtime-enabled
GETPOSTPATCHDELETETable: Purchase Header
Read and write Purchase Orders, the AP-side counterpart of posted documents on the sales side. POST a full order (header + purchaseOrderLines) in a single call; the header alone is rarely useful, so the line child collection is part of the same deep insert.
Resolve the buy-from vendor
Three ways to name the vendor, in order of convenience: vendorNumber (the Business Central No.), vendorId (its SystemId), or vendorIntegrationId, the vendor's eOne integration external key. vendorIntegrationId is a resolver: it is bound to a global, not a stored column, and on validate it looks the vendor up by its EONE Integration Id and stamps Buy-from Vendor No. for you. Supply exactly one.
vendorIntegrationId you send, the call errors. The order is not created with a blank vendor.Deep insert: header + lines
POST/purchaseOrders
{
"vendorIntegrationId": "ACME-001",
"integrationId": "PO-9F3A",
"purchaseOrderLines": [
{ "itemNumber": "1000", "quantity": 5, "directUnitCost": 12.50 }
]
}The store's order Id round-trips via integrationId; the supplier reference via vendorInvoiceNumber / yourReference. See Purchase Order Lines for how the nested lines behave.
Currency
currencyCode is the ISO code. A blank value means the company's local currency (LCY). It is translated to and from Business Central's blank-is-LCY convention automatically, so you send ISO and never the empty Business Central code.
Bound actions
POST /purchaseOrders({id})/Microsoft.NAV.release releases the order and …/Microsoft.NAV.reopen returns a released order to Open. POST /purchaseOrders({id})/Microsoft.NAV.receiveAndInvoice posts both receipt and invoice in one step. …/Microsoft.NAV.createWarehouseReceipt hands a released order to a require-receive warehouse; the response redirects to the resulting warehouseReceipt.
archive / cancel snapshot a version and keep the order open, or archive then delete it (soft delete). See Archiving & cancelling.
receiveAndInvoice the Purchase Header is deleted (it becomes a posted receipt + posted invoice). The action runs against a fresh local copy for that reason. Do not expect the order to still be GET-able afterward.