[SUB] Sendungsstatus¶

Wird vom DAILY mokebo-ops Sync automatisch befüllt — bitte nicht manuell editieren.

Status: — Letzter Erfolgs-Run: — Erfolgsquote 7d: — Trigger: — Node-Count: —

🟢 Auf einen Blick¶


Was tut der Workflow	Holt aus `orderData` (von SUB PlentyOne Lookup) den aktuellen Tracking-Status und draftet eine passende CS-Antwort.
Wann greift er	Aus MOKI Dispatcher v2 heraus, wenn `lookup_status === 'found'`.
Sichtbarer Effekt für CS	Internal Note mit Tracking-Status + Draft-Antwort. (Macro-Anwendung in Zendesk noch nicht aktiv.)
Symptom wenn kaputt	Internal Note bleibt aus, oder Draft enthält keinen Tracking-Status obwohl Plenty einen hat.
Owner	Susi (Backup: TBD)
Eskalation	Susi direkt anschreiben (Slack-DM). Ticket-ID + Sheet-Row aus Ticket Log v2.
Link in n8n	SUB Sendungsstatus

Architektur¶

flowchart LR
  In[orderData] --> Extract[Extract Tracking-Info]
  Extract --> Status{Status?}
  Status -- versendet --> SetDraft[Set Result: macro versendet]
  Status -- in_zustellung --> SetZust[Set Result: macro zustellung]
  Status -- nicht_gefunden --> SetMiss[Set Result: macro nicht_gefunden]
  Status -- zugestellt --> SetZuge[Set Result: macro zugestellt]
  SetDraft --> Out[Return]
  SetZust --> Out
  SetMiss --> Out
  SetZuge --> Out

Subworkflow-Calls¶

Auto-generiert aus den executeWorkflow-Nodes — bitte nicht manuell editieren.

(keine — ist ein reiner Sub)

Trigger & Datenfluss¶

Trigger: Subworkflow-Call aus Parent.
Input: orderData aus SUB PlentyOne Lookup (NIEMALS null — Parent muss vorher routen).

Output: strukturiertes Objekt nach mokebo-Standard:

{
  "ticketId": "...",
  "sub_action": "sendungsstatus_replied",
  "sub_status": "success",
  "sub_reason": "tracking_<status>",
  "sub_macro_id": "...",
  "sub_message": "..."
}

Dies ist die Vorlage für die Output-Convention aller mokebo-Subworkflows. Die Set Result/Set Result1-Code-Nodes hier sind Referenz für SUB Portalverweis (das aktuell noch eine andere Output-Form hat — siehe Status).

Bekannte Stolpersteine / Edge-Cases¶

Wenn orderData: null reinkommt → NPE. Parent darf den Sub nicht callen wenn lookup_status !== 'found'. IF-Routing im Parent (siehe MOKI Dispatcher v2, Sektion „Bekannte Stolpersteine").
Plenty-Tracking-Status ist nicht 1:1 zu Carrier-Status. Mapping ist im Extract Tracking-Info-Node — bei neuem Carrier ggf. ergänzen.

Debug-Anleitung¶

n8n → Executions → Filter „Failed".
Wenn Cannot read properties of null → Parent-Routing-Bug, nicht im Sub fixen.
Wenn falscher Macro getriggert: schau ins Mapping in Extract Tracking-Info.

Entscheidungen / Geschichte¶

(älter): Output-Convention {ticketId, sub_action, sub_status, sub_reason, sub_macro_id, sub_message} als Standard für alle Subworkflows festgelegt — dieser Workflow ist die Referenz.