Fehlgeschlagenes Placement einer Bestellung diagnostizieren

Wenn eine Bestellung im Status released bleibt und der Übergang place fehlschlägt, lesen Sie zuerst die serverseitige Placement-Diagnose:

bash
nucli --tenant <mandantenalias> commerce order diagnose <order-uuid>

Das Kommando verändert weder die Bestellung noch Reservierungen, Rechnungen, Zahlungen oder Sendungen. Es benötigt die vorhandene Berechtigung orders:read und zeigt insbesondere:

  • den Status und Health-Zustand des Workflows der Bestellung;
  • den letzten sicheren Action- und Fehlercode;
  • die im OrderItem gespeicherte Erfüllungsstrategie und die aktuelle ProductLogistics-Strategie;
  • den Promotion-Zustand jeder Position;
  • den aktuellen Follow-up-Modus und den aus dem Strategie-Snapshot abgeleiteten Zieltyp;
  • den geprüften Vertrag aus place und fulfillment.promote sowie die tatsächlich geplanten Effekte;
  • vorhandene Rechnungs-, Zahlungstransaktions- und Sendungsgrenzen;
  • ob der Server einen normalen place-Retry als sicher einstuft.

Mit --json erhalten Sie die unveränderte Lifecycle-Projektion für Automationen:

bash
nucli --tenant <mandantenalias> commerce order diagnose <order-uuid> --json

Ergebnis bewerten

placement.status=retry_ready und retrySafe=true bedeuten, dass der Server den bekannten Graph der Bestellpositionen eindeutig einem unterstützten Placement-Pfad zuordnen kann. Zusätzlich muss der gepinnte Workflow genau die kataloggebundene, transaktions- und replay-sichere Action fulfillment.promote im Übergang place enthalten. Genau dieser Übergang muss in den Status placed führen. Fehlt der Vertrag oder weicht er ab, bleibt das Placement mit ERR_FULFILLMENT_WORKFLOW_CONTRACT_UNSUPPORTED blockiert.

strategyMismatch=true ist ein Diagnosehinweis: Für die bestehende Bestellung bleibt der gespeicherte OrderItem-Snapshot maßgeblich. Bei follow-up-fähigen Strategien zeigt followUp.mode die aktuelle Policy und followUp.targetType den erwarteten Zieltyp. mode=manual bedeutet, dass der Retry nur einen offenen Bedarf anlegt. Er erzeugt keinen PurchaseOrder oder ManufacturingOrder.

Nur bei der abschließenden Klassifikation retry_ready mit retrySafe=true enthält plannedEffects Einträge. Für bereits platzierte Bestellungen, blockierte Graphen und nicht unterstützte Workflows bleibt das Array leer.

Erscheint ERR_FULFILLMENT_FOLLOW_UP_MODE_INVALID, enthält ProductLogistics einen ungültigen aktuellen Wert. In diesem Fall blendet die Diagnose die Follow-up-Felder der betroffenen Position aus; der Rohwert bleibt verborgen. Starten Sie keinen Retry. Korrigieren Sie die Produktvariante über die tenantgebundene PIM-Pflege auf manual oder automatic und rufen Sie die Diagnose anschließend erneut auf.

compatibilityMode=legacy_manual_snapshot_initialization kennzeichnet einen eng begrenzten historischen Cart-Zustand. Der normale place-Übergang darf die fehlenden Promotion-Snapshots innerhalb seiner Root-Transaktion initialisieren. Entweder werden Workflow-State, Positionen und Follow-ups gemeinsam gespeichert oder vollständig zurückgerollt.

Führen Sie einen Retry nur als eigenen, freigegebenen Workflow-Dispatch mit einem neuen Idempotency-Key aus. Die Diagnose selbst autorisiert keinen Retry. Sie erzeugt insbesondere keine Rechnung, Zahlung, E-Mail oder Sendung.

Bei placement.status=blocked führen Sie keine direkte Datenbankkorrektur und keinen heuristischen Retry aus. Dokumentieren Sie die ausgegebenen Fachcodes und lassen Sie den abweichenden Graph als Produktfall prüfen. Die Diagnose veröffentlicht keine rohen SQL-, Treiber-, Provider- oder Kundendaten.