Pixi API documentation

Unofficial · by koempf24.de

Postman collection
Orders Write

pixiUpdateOrder

Updates shipping costs, ship date, shop note, voucher, address remarks and payment type of an existing open order.

Updates selected header data of an existing order. The order is found by OrderNr or OrderNrExternal.

Validation steps (each returns an Error row and stops):

  1. At least one of OrderNr or OrderNrExternal must be given.
  2. The order is looked up with OrderNr = @OrderNr OR OrderNrExternal = @OrderNrExternal (first match). If none is found, an error is returned.
  3. VoucherID and VoucherAmount must be given together.
  4. The voucher must not be used on order lines of another order.
  5. If PaymentType is given, it must exist as a Code in the Payments table.
  6. The order must still be editable: the overall order state, calculated from the order lines, must be OPEN or HOLD. In addition, the number of non-final order lines that already have invoice lines must be lower than the number of lines that are neither final nor in status MIN or FUS.

Update:

  • Parameters that are left out keep the current values of the order.
  • ShipCosts is applied to the net shipping costs for B2B orders and to the gross shipping costs for B2C orders.
  • ShipDate replaces the ship date. The value 1900-01-01 clears it to NULL.
  • ShopNote and AddressRemarks replace the stored texts.
  • All other header fields, such as gift message, shipping instructions, ship vendor, CCP merchant, ccpPayID, Verfahren/Product/Extras and order type, are passed through unchanged.
  • The actual update is done by the internal procedure Pixi_UpdateOrder. It sets UpdateDate to the current time.
  • If the shipping costs change and no voucher or discount applies, the ShipCost of the order lines is updated as well.
  • If a voucher is given, it is created in Voucher if it does not exist yet. Otherwise its amount is updated. The voucher ID is then written to all order lines.
  • If PaymentType is given, it is written to APayment of the order's address (AddrRef).

On success, a Success row is returned.

Notes

  • VoucherAmount is passed through NULLIF(@VoucherAmount, ''). Because '' converts to 0 for money, an amount of 0 is treated as not provided. Passing VoucherID with amount 0 therefore returns VoucherID provided without VoucherAmount.
  • An empty VoucherID is treated as not provided.
  • If both OrderNr and OrderNrExternal are given and match different orders, an arbitrary one of them is updated (TOP (1) without ORDER BY).
  • In the does not exist error, the message is built by string concatenation. If one of the two identifiers is NULL, the Message column is NULL.
  • Pixi_UpdateOrder runs in its own transaction and catches its own errors. It logs them via log.InsertError and does not re-raise them, so the outer error handler may not see them. A Success row can therefore be returned even if the inner update was rolled back. log.InsertError is not attached.
  • The Addresses update for the payment type happens after the inner transaction and outside of it.
  • If the order has no CCP merchant, the inner procedure may set one based on the setting DefaultCCPMerchant.
  • If ccpPayID is NULL on an open order, it is stored as an empty string.
  • ShopNote is declared as varchar(max). Characters outside the database code page are lost, even though the target column is nvarchar.
  • Reads in the validation part use NOLOCK; the inner procedure uses UPDLOCK on OrderHeader and Orderlines.

Tables used

Payments · Read OrderHeader · Write Orderlines · Write Invlines · Read OrderStates · Read Addresses · Write Voucher · Write Customers · Read Currency · Read
SQL object:
dbo.pipiUpdateOrder
Updated at 2026-10-30