Postman-Collection
Orders Schreiben

pixiDeleteOrder

Löscht einen kompletten Auftrag, sofern alle Auftragspositionen den Status ANG, HAL oder STO haben und keine auf einer aktiven Pickliste steht.

Löscht den über OrderNr angegebenen Auftrag samt abhängigen Daten und liefert eine Statuszeile.

Prüfungen (vor jeder Änderung):

  1. Der Auftragskopf wird über OrderNr gesucht und mit Auftragspositionen, Bankzuordnungen, Kundenkonto-Ereignissen und Picklistenpositionen verknüpft. Wird keine Zeile gefunden, lautet das Ergebnis 404.
  2. Hat eine Auftragsposition einen anderen Status als ANG, HAL oder STO, lautet das Ergebnis 409.
  3. Steht eine Auftragsposition auf einer Pickliste, deren Ablaufdatum (PLHexpiryDate) in der Zukunft liegt, lautet das Ergebnis 409 mit der Picklisten-Meldung. Diese Prüfung läuft zuletzt, ihre Meldung gewinnt also, wenn beide 409-Bedingungen zutreffen.

Schlägt eine Prüfung fehl, wird nichts geändert.

Löschschritte (in einer Transaktion):

  • Für jede Auftragsposition wird ein OrderHistory-Eintrag mit Status NEW und Mitarbeiter API geschrieben.
  • Die Auftragspositionen werden nicht physisch gelöscht, sondern vom Auftrag gelöst und zurückgesetzt: OrderNr, CustRef, AddrRef, ShipAdrRef werden 0, Status wird NEW, UpdateEmp wird API, Menge, Preise, Beträge, Rabatte, Steuer und Versandkosten werden 0, ItemRef, ShipRef, Order_Id, BundleOrderlineRef werden NULL.
  • Referenzierte Bundle-Positionen (BundleOrderlines) werden gelöscht.
  • Auftragskopf-Attribute (OrderHeaderAttribute) werden gelöscht.
  • Reservierungen (Reservation) der Auftragspositionen werden gelöscht.
  • Das mit der Bankzuordnung des Auftrags verknüpfte Kundenkonto-Ereignis wird über Pixi_CA_DeleteEvent gelöscht (dabei können auch die zugehörige Rechnung, Bankzuordnungen, Kundenkonto-Matches, DTAUS-Datensätze oder manuelle Buchungen gelöscht werden).
  • Abschließend löscht Pixi_DeleteEmptyOrder Picklisten-Prüfeinträge, Tag-Zuordnungen, restliche Kopfattribute und den Auftragskopf selbst.

Bei Erfolg enthält die Statuszeile 200 und einen Bestätigungstext. Unerwartete SQL-Fehler werden protokolliert und als 500 mit der SQL-Fehlermeldung zurückgegeben.

Hinweise

  • Die Kandidatendaten werden mit NOLOCK gelesen; Änderungen nutzen ROWLOCK. XACT_ABORT ist aktiv. Besteht beim Aufrufer bereits eine Transaktion, wird statt einer neuen Transaktion ein Savepoint gesetzt.
  • CONTEXT_INFO wird zeitweise gesetzt, um die Trigger auf Orderlines und Reservation zu umgehen; deren Triggerlogik läuft für diese Änderungen also nicht.
  • Stolperfalle: Die Prozedur legt einen eindeutigen Index auf den Positionsschlüssel der Kandidatendaten an. Kommt eine Auftragsposition in den verknüpften Daten mehrfach vor (z. B. mehrere Bankzuordnungen zum Auftrag oder die Position steht auf mehreren Picklisten, auch abgelaufenen), schlägt die Indexerstellung fehl und der Aufruf liefert 500.
  • Es wird nur ein Kundenkonto-Ereignis gelöscht (TOP 1 ohne Sortierung), auch wenn mehrere Bankzuordnungen existieren. Ob es gelöscht werden darf, entscheidet fPixi_CA_canIdeleteEvent; Rechnungen werden über Pixi_DeleteInvoice entfernt. Beide Objekte liegen nicht vor, ihr genaues Verhalten ist daher hier nicht dokumentiert.
  • Pixi_CA_DeleteEvent rollt bei einem Fehler die gesamte Transaktion zurück und wirft die Meldung erneut; sie kommt dann als Status 500 zurück.
  • Fehler in Pixi_DeleteEmptyOrder werden dort über log.InsertError protokolliert und nicht weitergereicht.
  • Auch bei 404 oder 409 wird eine leere Transaktion geöffnet und committet.

Parameter

Parameter Typ Standardwert Beschreibung
OrderNr
Pflicht
int –

Nummer des zu löschenden Auftrags (OrderHeader.OrderNr).

Beispiel: 100234

Antwort

Result-Set 1 · Immer (genau eine Zeile)

Statuszeile mit dem Ergebnis des Aufrufs.

Spalte Typ Beschreibung
Status varchar(3)
string

200 = gelöscht, 404 = Auftrag nicht gefunden, 409 = Auftrag kann nicht gelöscht werden, 500 = SQL-Fehler.

ErrorMsg
Kann leer sein
varchar(2000)
string

Bestätigungs- oder Fehlertext.

Fehlermeldungen

Status Meldung Ursache
404 Order with OrderNr: {OrderNr} was not found. Es existiert kein Auftragskopf mit der angegebenen `OrderNr`. Auftragsnummer prüfen.
409 Order can only be deleted when all orderline statuses are in ("ANG","HAL","STO"). Mindestens eine Auftragsposition hat einen anderen Status als `ANG`, `HAL` oder `STO`. Zuerst die Positionsstatus anpassen.
409 Order is already on active picklist. Mindestens eine Auftragsposition steht auf einer noch nicht abgelaufenen Pickliste. Positionen zuerst von der Pickliste entfernen.
500 Pixi_CA_DeleteEvent: deleting of DTAUS record not allowed Das Kundenkonto-Ereignis des Auftrags gehört zu einem DTAUS-Datensatz, dessen Status kein Löschen erlaubt. Die gesamte Löschung wird zurückgerollt.
500 {ERROR_MESSAGE()} Sonstiger SQL-Fehler beim Löschen, z. B. ein doppelter Positionsschlüssel beim Anlegen des eindeutigen Index auf den Kandidatendaten. Der Fehler wird protokolliert und die Transaktion zurückgerollt.

Beispiele

POST https://apigateway.descartes.com/tms/pixi/
Content-Type: text/xml; charset=utf-8
Authorization: Basic BASE64(USERNAME:PASSWORD)

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="https://apigateway.descartes.com/tms/pixi/">
  <SOAP-ENV:Body>
    <ns1:pixiDeleteOrder>
      <OrderNr>100234</OrderNr>
    </ns1:pixiDeleteOrder>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Verwendete Tabellen

OrderHeader · Schreiben Orderlines · Schreiben OrderHistory · Schreiben BankMatch · Schreiben CustomerAccount · Schreiben PLitem · Lesen PLHeader · Lesen BundleOrderlines · Schreiben OrderHeaderAttribute · Schreiben Reservation · Schreiben CustomerAccountMatch · Schreiben DTAUS · Schreiben DTAUSstates · Lesen CustomerAccountManualBookings · Schreiben PL_NotReservedOrdersCheck · Schreiben TagMatch · Schreiben
SQL-Objekt:
dbo.pipiDeleteOrder
Prozedur zuletzt geändert am 2026-10-05
Dokumentation von claude-opus-5-5 am 2026-10-30 geschrieben