Pixi API documentation

Unofficial · by koempf24.de

Postman collection
Suppliers Write

pixiUpdateSupplierOrder

Updates status, note for the supplier, external order number and estimated delivery date of a supplier order identified by its internal number.

Changes a supplier order (purchase order to a Lieferant) that is identified by SupplierOrderNR (the order's InternalNumber).

Steps

  1. Empty strings in Status and SupplierOrderNRExtdrnal and an empty Note are treated as NULL (not passed).
  2. UserName must exist in the Pixi user table; otherwise an ERROR row is returned and an SQL error is raised.
  3. The order and its current status are loaded. If Status is not passed, the current status code of the order is used.
  4. Validation (each failure returns an ERROR row, nothing is changed):
    • the order must exist;
    • Status must be NEW, BES, CON or CLS;
    • a closed order (CLS) accepts no new EstimatedDeliveryDate and no new SupplierOrderNRExtdrnal;
    • a confirmed order (CON) accepts no new SupplierOrderNRExtdrnal;
    • no backward change from CLS to NEW/BES/CON and from CON to NEW (CON → BES is allowed);
    • no skipping: NEW cannot go directly to CON or CLS, and BES cannot go directly to CLS.
  5. The order header is updated:
    • status is set (NEW=1, BES=2, CON=3, CLS=4);
    • with BES the order date and ordering user are set to now/the calling user, with CON the confirmation date and confirming user;
    • external code, note for the supplier and estimated delivery date are only overwritten when a value is passed;
    • modification user and timestamp are set.
  6. If EstimatedDeliveryDate is passed, it is also written to all lines of the supplier order.
  7. If the status actually changed, the event SupplierOrderStatusChanged is published with the internal order Id.
  8. A single row with ReturnCode = Ok is returned and the transaction is committed.

Notes

  • Pitfall – dates are reset: because an omitted Status falls back to the current status, every call on an order in status BES sets OrderDate/OrderedByUserId again to now and the calling user; on an order in CON the same happens to ConfirmationDate/ConfirmedByUserId. This also applies when only the note or the delivery date is changed.
  • Fields cannot be cleared: an empty or omitted value keeps the stored value. An EstimatedDeliveryDate of 1900-01-01 is treated as not passed.
  • The note is still accepted on closed orders; only delivery date and external number are blocked.
  • The code comment says NEW cannot be set again, but the code only blocks NEW from CON/CLS; a change BES → NEW is accepted.
  • SupplierOrderNRExtdrnal is limited to 25 characters by the parameter type. The note is stored in a non-Unicode column, so characters outside the database code page may be lost.
  • Status IDs 1–4 are hard-coded in the procedure.
  • Because of operator precedence in the validation, a backward/skip status error can override an earlier validation message; the call still fails in either case.
  • Runs in its own transaction (or a savepoint if an outer transaction exists). Errors are caught, rolled back and written to the error log; except for the user check, no SQL error is raised, only the ERROR row is returned. When called inside an outer transaction, no Ok row is returned and no commit is done.
  • The initial lookup of the order reads with NOLOCK.
  • The status change event is published via Pixi_MQ_EventPublish; whether a message is actually sent depends on the setting pixiMQ_Enabled and the event configuration.

Tables used

SupplierOrder · Write SupplierOrderStatus · Read SupplierOrderLine · Write UCS_USERS · Read
SQL object:
dbo.pipiUpdateSupplierOrder
Updated at 2026-10-30