Pixi API documentation

Unofficial · by koempf24.de

Postman collection
Direct-Fulfillment Write

pixiDFUpdateOrderlineStatus

Sets the direct-fulfillment status of an orderline for an authenticated supplier, optionally with ship date, tracking ID, invoice number, partial quantity and batch data.

API call for direct-fulfillment suppliers to report the processing state of an orderline back to Pixi.

1. Authentication

  • The supplier is looked up in Suppliers by SupplNr; Secret must match the supplier's CustNr, the supplier must not be disabled and must have CanDoDirectFulfillment = 1.
  • If no supplier matches and the setting DFAPIAllowFullAccessWithoutSecret is 0 (or missing), a single row with Error = '403' is returned and nothing is changed.
  • If that setting is not 0, the call continues even with a wrong secret.

2. Finding the orderline

  • If OrderlineRef is less than 1 (default), the orderline key is read from OrderHistory using OrderHistoryKey.
  • Empty strings in BatchNumber, BestBeforeDate and SerialNumber are treated as NULL.

3. Validation (done by the internal procedure Pixi_UpdateOrderlineDFStatusByOrderlineKey). The update is rejected if:

  • the orderline does not exist;
  • the setting DFRequiredDataForSystemTags is active and the item carries the system tag for batch number (tag -6) and/or best-before date (tag -7) but the corresponding value is not sent;
  • Qty is less than 1 or greater than the current orderline quantity;
  • the orderline already has status FUS or a status marked as final in OrderStates.

4. Update

  • If Qty is smaller than the current quantity, the orderline is split first: the original line keeps Qty, a new line with the remaining quantity is created with the old status.
  • The new status is derived from Status: STO and NLB are taken over as they are; any other value results in FUS for DF type 1, 3 or no DF type, otherwise BES.
  • The orderline gets the new status, DFShipDate, DFShipmentTrackingID (from DFTrackingID), InvoiceNrExternal, batch number, best-before date, serial number, UpdateDate and UpdateEmp = 'DF API'.
  • If the resulting status is BES, a reservation is created for the whole order.

5. Response One row with Error (200 or 500) and ErrorMsg. 500 is returned if the message contains the word error. On success ErrorMsg is empty or contains the split info. Each call that passes authentication writes a line to LogTable.

Notes

  • The call does not check that the orderline belongs to the authenticated supplier; any orderline key can be addressed.
  • DFShipDate, DFTrackingID and InvoiceNrExternal are always written; omitting them overwrites existing values with NULL. BatchNumber, BestBeforeDate and SerialNumber keep their existing values when not sent.
  • Validation messages overwrite each other; only the last failing check is reported.
  • The detection of errors relies on CHARINDEX('error', ErrorMsg); this works for the upper-case ERROR: messages only with a case-insensitive database collation.
  • Runtime exceptions inside the update are caught, rolled back and logged via log.InsertError, but they do not change ErrorMsg; the response can therefore be 200 with an empty or INFO message although nothing was saved. Check the orderline afterwards if in doubt.
  • The check for a failed reservation (ERROR: Error Creating Reservation) reads @@ERROR after a SET statement and is therefore practically never triggered.
  • The work runs in its own transaction or savepoint if called inside an existing transaction. Lookups use NOLOCK.
  • The behaviour of GOSBreakOrderline, Pixi_Res_CreateReservationForOrder, dbo.SettingGet and log.InsertError is not visible here; further tables may be written by them.
  • A best-before date of 1900-01-01 is treated like an empty value because of the comparison with ''.

Tables used

Suppliers · Read Settings · Read OrderHistory · Read Orderlines · Write TagMatch · Read OrderStates · Read LogTable · Write
SQL object:
dbo.pipiDFUpdateOrderlineStatus
Updated at 2026-10-30