Zum Inhalt

02 Retouren-Check

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 Trackt alle offenen Retouren-Sendungen aus dem Tracking-Sheet bei GLS/DHL nach, aktualisiert den Status, und triggert bei drei End-Zuständen automatisch ein Zendesk-Ticket.
Wann greift er Cron: täglich 9:00 Uhr (30 Min nach 01 Retouren-Erfassung).
Sichtbarer Effekt für CS Status-Updates im Tracking-Sheet. Bei 3 End-Zuständen: neues Zendesk-Ticket.
Symptom wenn kaputt Sheet-letzter_check-Spalte zeigt heute kein Update. Oder fällige Sendungen bleiben in offen / in_transit hängen.
Owner Susi (Backup: TBD)
Eskalation Susi direkt anschreiben (Slack-DM). Mit Sendungsnummer einer hängenden Retoure als Beispiel.
Link in n8n 02 Retouren-Check

Architektur

flowchart TB
  Cron[Täglich 9:00] --> SheetRead[Sheet 'Tracking' lesen]
  SheetRead --> Filter[Fällige Einträge filtern
naechster_check ≤ heute]
  Filter --> Empty{Fällig?}
  Empty -- nein --> Stop[Ende]
  Empty -- ja --> GLSToken[GLS Token holen]
  GLSToken --> Track[Tracking prüfen
+ Status bestimmen]
  Track --> Update[Sheet-Updates schreiben]
  Track --> Ticket{End-Zustand?}
  Ticket -- zugestellt --> ZdGutschrift[Zendesk-Ticket:
Gutschrift erstellen]
  Ticket -- in_transit_überfällig --> ZdNachfrage[Zendesk-Ticket:
Carrier-Nachfrage]
  Ticket -- nicht_versendet_geschlossen --> ZdAbgeschlossen[Zendesk-Ticket:
21d nicht versendet]
  ZdGutschrift --> WriteTicket[Ticket-ID zurück ins Sheet]
  ZdNachfrage --> WriteTicket
  ZdAbgeschlossen --> WriteTicket

Subworkflow-Calls

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

  • (keine — eigenständiger Workflow)

Trigger & Datenfluss

  • Trigger: Cron, täglich 9:00 Uhr.
  • Quelle: Sheet 1VpOWnR_69GyhdWm8NOgvYYBR4zSNKbs3Gfxap3WcXmA, Tab Tracking (gleiches Sheet wie 01).
  • APIs:
  • GLS: POST https://api.gls-group.net/oauth2/v1/token (Token), dann GET …/track-and-trace-v1/tracking/simple/trackids/{nr}?showEvents=true.
  • DHL: GET https://api-eu.dhl.com/track/shipments?trackingNumber={nr} mit DHL-API-Key-Header.
  • Zendesk: Ticket-Create bei drei End-Zuständen.

Status-Lebenszyklus

stateDiagram-v2
  [*] --> offen: 01 schreibt
  offen --> in_transit: Carrier sagt 'transit'
  offen --> nicht_versendet_geschlossen: 21 Tage + immer noch not_shipped
  in_transit --> zugestellt: delivered
  in_transit --> in_transit_ueberfaellig: 10 Tage transit
  zugestellt --> ticket_erstellt: Gutschrift-Ticket erzeugt
  in_transit_ueberfaellig --> ticket_erstellt: Nachfrage-Ticket
  nicht_versendet_geschlossen --> ticket_erstellt: Abschluss-Ticket
  ticket_erstellt --> [*]

Sechs Stati: offen, in_transit, zugestellt, in_transit_ueberfaellig, nicht_versendet_geschlossen, ticket_erstellt.

Bekannte Stolpersteine / Edge-Cases

  • Carrier-Patch (12.05.2026): (data.carrier || '').toUpperCase().startsWith('DHL'/'GLS') statt === 'DHL'/'GLS'. Das routet jetzt auch DHL-Prime, GLS-Prime, GLSShipping korrekt zur richtigen Tracking-API.
  • Amazon-Retouren werden öfter geprüft: naechster_check = heute + 2 für Referrer 4.01 (Amazon Germany), +7 für Rest. Im Code abhängig von referrer_id-Prefix 143 — TODO checken ob das nach mokebo-ID-Update noch korrekt ist.
  • DHL 429-Behandlung schwach: RETRY_BACKOFFS_MS = [] → Retry-Schleife läuft genau einmal, bei 429 sofort error-Status. Wenn DHL Rate-Limits, fallen Sendungen aus dem Run und werden morgen wieder aufgenommen.
  • DHL-API-Key hardcoded im Code-Node → bei Rotation muss der Code-Node manuell editiert werden.
  • MAX_RUNTIME_MS = 55000 — Workflow stoppt sich selbst nach 55 Sek., um n8n-Timeout (60 Sek.) zu vermeiden. Bei viel fälligen Sendungen werden hintere nicht abgearbeitet → fließen morgen wieder rein.
  • Sentinel _empty wird in mehreren IFs geprüft — wenn die Filter-Logik mal falsche Form zurückgibt, läuft der ganze Run leer.

Debug-Anleitung

  1. n8n → 02 Retouren-Check → Executions → Filter heute + Failed.
  2. Wenn Run grün aber Sheet nicht geupdatet: schau im Filter-Node-Output, ob _empty rauskam.
  3. Wenn Carrier-spezifischer Fehler: schau, ob Token-Holen-Node lief (GLS-Token braucht GLS Basic Auth Credential).
  4. Wenn DHL-Calls 429 werfen: hat sich nichts an deinem Tun geändert, am nächsten Tag wieder versuchen.

Entscheidungen / Geschichte

  • 2026-05-12: Carrier-Patch (startsWith statt ===) eingeführt für DHL-Prime / GLS-Prime-Unterstützung — siehe SUB Retoure.
  • (älter): 21 Tage als Cutoff für nicht_versendet_geschlossen (DHL/GLS-Frist).
  • (älter): 10 Tage transit als in_transit_ueberfaellig-Schwelle.