UpdatePurchaseOrderCommandRequestInput
Patches an existing purchase order’s header: editable fields and a status transition, in any combination. Every field is optional — an omitted field leaves its column unchanged. Field editability depends on the order’s status (structural fields only while Open or Released, confirmation fields in every status except Completed, annotations always) and is evaluated against the status BEFORE any transition requested in the same call. LINE ITEMS ARE NOT PART OF THIS ENDPOINT: they are addressed individually through purchase-orders//line-items, one operation per position. Returns the full re-queried order, so the caller sees the side effects the write triggers. - Request
UpdatePurchaseOrderCommandRequestInputFields
ID of the purchase order to patch.
Internal comment on the order, not communicated to the supplier. Editable in every status including Completed (annotations tier).
The buyer's own external reference for this order (free text, at most 255 characters). Editable in every status (annotations tier). Not the order's own number, which the server assigns and which this API never lets a client change.
The reference order number — the "Zugehörige Auftragsnummer" field, free text, at most 255 characters. Editable in every status (annotations tier).
The delivery date requested from the supplier. Editable in every status (annotations tier) — unlike a LINE ITEM's delivery date, the header date drives no stock posting of its own.
Whether the order as a whole is confirmed. Editable in every status except Completed (confirmations tier), and bidirectional — an explicit false is a valid reset. An independent flag, never derived from the line items' own confirmation flags; only a genuine false-to-true change raises the confirmation event.
The status to transition the order into. Omit to leave the status untouched; setting the status the order already has is an accepted no-op. Permitted transitions are Open to Released, Open to InProgress, Released to InProgress, Released to Completed, InProgress to Completed, PartiallyDelivered to Completed and Overdue to Completed. Anything else is rejected with PURCHASE_ORDER_INVALID_STATUS_TRANSITION — in particular Open to Completed, any transition back to Released, and any transition out of Completed.
Indicates whether automatic workflows should be suppressed for this update. Defaults to false when omitted.
Client-supplied idempotency key. When provided, a repeated request with the same key and payload replays the original result instead of re-executing the mutation.
Was this page helpful?