Postman collection
Orders Write

pixiDeleteOrder

Deletes a complete order (Auftrag) if all orderlines are in status ANG, HAL or STO and none is on an active pick list.

Deletes the order identified by OrderNr together with its dependent data and returns one status row.

Checks (run before any change):

  1. The order header is looked up by OrderNr, joined with its orderlines, bank matches, customer account events and pick list items. If no row is found, the result is 404.
  2. If any orderline has a status other than ANG, HAL or STO, the result is 409.
  3. If any orderline is on a pick list whose expiry date (PLHexpiryDate) lies in the future, the result is 409 with the pick list message. This check runs last, so its message wins if both 409 conditions apply.

If a check fails, nothing is changed.

Deletion steps (inside one transaction):

  • An OrderHistory entry with status NEW and employee API is written for each orderline.
  • The orderlines are not physically deleted but detached and reset: OrderNr, CustRef, AddrRef, ShipAdrRef become 0, Status becomes NEW, UpdateEmp becomes API, quantity, prices, amounts, discounts, tax and shipping cost are set to 0, and ItemRef, ShipRef, Order_Id, BundleOrderlineRef are set to NULL.
  • Bundle orderlines (BundleOrderlines) referenced by the orderlines are deleted.
  • Order header attributes (OrderHeaderAttribute) are deleted.
  • Stock reservations (Reservation) of the orderlines are deleted.
  • The customer account event linked to the order's bank match is deleted via Pixi_CA_DeleteEvent (this may also delete the related invoice, bank matches, customer account matches, DTAUS records or manual bookings).
  • Finally Pixi_DeleteEmptyOrder deletes pick list check entries, tag matches, remaining header attributes and the order header itself.

On success the status row contains 200 and a confirmation text. Unexpected SQL errors are logged and returned as 500 with the SQL error message.

Notes

  • The candidate data is read with NOLOCK; changes use ROWLOCK. XACT_ABORT is on. If the caller already has an open transaction, a savepoint is used instead of a new transaction.
  • CONTEXT_INFO is temporarily set to suppress the triggers on Orderlines and Reservation; trigger logic for these changes therefore does not run.
  • Pitfall: the procedure creates a unique index on the orderline key of the candidate data. If an orderline appears more than once in the joined data (e.g. several bank matches for the order, or the line is contained in several pick lists, including expired ones), the index creation fails and the call returns 500.
  • Only one customer account event is deleted (TOP 1 without sort order) even if several bank matches exist. Whether it may be deleted is decided by fPixi_CA_canIdeleteEvent, and invoices are removed by Pixi_DeleteInvoice; both are not attached, so their exact behaviour is not documented here.
  • Pixi_CA_DeleteEvent rolls back the whole transaction on error and re-raises the message, which then comes back as status 500.
  • Errors inside Pixi_DeleteEmptyOrder are logged there via log.InsertError and not re-raised.
  • A 404 or 409 result still opens and commits an empty transaction.

Tables used

OrderHeader · Write Orderlines · Write OrderHistory · Write BankMatch · Write CustomerAccount · Write PLitem · Read PLHeader · Read BundleOrderlines · Write OrderHeaderAttribute · Write Reservation · Write CustomerAccountMatch · Write DTAUS · Write DTAUSstates · Read CustomerAccountManualBookings · Write PL_NotReservedOrdersCheck · Write TagMatch · Write
SQL object:
dbo.pipiDeleteOrder
Updated at 2026-10-30