Zum Inhalt

01 Retouren-Erfassung

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 täglich neue Retouren-Aufträge aus PlentyOne (Status 9.01–9.02), extrahiert Sendungsnummern aus den Auftragsnotizen und schreibt sie als neue Zeilen ins Tracking-Sheet. Die Tracking-Pipeline für 02 Retouren-Check.
Wann greift er Cron: täglich 8:30 Uhr.
Sichtbarer Effekt für CS Neue Zeilen im Sheet Retouren-Tracking (1VpOWnR_69GyhdWm8NOgvYYBR4zSNKbs3Gfxap3WcXmA, Tab Tracking). 30 Min später checkt 02 die neuen Sendungen bei den Carriern.
Symptom wenn kaputt Heute morgen keine neuen Zeilen im Tracking-Sheet, obwohl in Plenty neue Retouren mit Sendungsnummer angelegt wurden.
Owner Susi (Backup: TBD)
Eskalation Susi direkt anschreiben (Slack-DM). Mit Datum + Beispiel einer fehlenden Retoure (Plenty-Auftrag-ID).
Link in n8n 01 Retouren-Erfassung

Architektur

flowchart TB
  Cron[Täglich 8:30] --> Login[Login PlentyOne]
  Login --> Fetch[GET /rest/orders
orderType=3, status 9.01-9.02]
  Fetch --> Filter[Daten aufbereiten
Cutoff: 21 Tage]
  Filter --> Empty1{Leer?}
  Empty1 -- ja --> Stop1[Ende]
  Empty1 -- nein --> SheetRead[Sheet 'Tracking' lesen]
  SheetRead --> Dedup[Nur neue Aufträge
filtern]
  Dedup --> Empty2{Neue
Aufträge?}
  Empty2 -- nein --> Stop2[Ende]
  Empty2 -- ja --> Calls[3 Calls pro Auftrag:
Hauptauftrag + Retoure +
Comments]
  Calls --> Extract[Sendungsnummern
per Regex extrahieren]
  Extract --> Empty3{Sendungs-
nummern?}
  Empty3 -- nein --> Stop3[Ende]
  Empty3 -- ja --> Append[Append rows
16 Spalten]

Subworkflow-Calls

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

  • (keine — eigenständiger Workflow)

Trigger & Datenfluss

  • Trigger: Cron, täglich 8:30 Uhr.
  • Quelle: PlentyOne GET /rest/orders?orderType=3&statusFrom=9.01&statusTo=9.02&itemsPerPage=50.
  • Ziel: Google Sheet 1VpOWnR_69GyhdWm8NOgvYYBR4zSNKbs3Gfxap3WcXmA, Tab Tracking (gid=0). 16 Spalten pro Zeile (siehe Sheet-Schema unten).
  • Plenty-API-Calls pro neuer Retoure: 3 (Hauptauftrag, Retoure-Auftrag mit orderItems.properties, Comments).

Sheet-Schema (16 Spalten)

Spalte Bedeutung
retouren_auftrag_id Plenty-ID des Retouren-Auftrags (typeId 3)
hauptauftrag_id Plenty-ID der Original-Bestellung (parent)
sendungsnummer Tracking-Nr. — Match-Key für Updates aus 02
carrier GLS / DHL / GLS-Prime / DHL-Prime / UNBEKANNT
erstellt_am Datum des Plenty-createdAt (YYYY-MM-DD)
naechster_check Wann 02 wieder prüfen soll (YYYY-MM-DD)
letzter_check Letzter erfolgreicher Tracking-Lookup
status siehe Status-Lebenszyklus in 02 Retouren-Check
check_count Inkrementiert pro Lookup
letztes_tracking_event Roh-Text vom Carrier (zur Diagnose)
zendesk_ticket_id Wird von 02 gesetzt sobald ein Ticket eröffnet wurde
referrer_id Plenty-Auftragsherkunft (Amazon = 4.01)
externe_auftrags_id Marktplatz-Bestellnummer (Property typeId 7)
in_transit_seit Datum, ab dem Carrier-Status erstmals „transit" war
herkunftsland „ISO — Klartext" der Lieferadresse
retourengrund Komma-separierte Klartexte aus Property typeId 35

Bekannte Stolpersteine / Edge-Cases

  • Marker-Patch (12.05.2026): Code-Node Notizen holen + Sendungsnummern extrahieren priorisiert ab jetzt Comments mit [n8n Amazon-RSA-Prefix. Wenn ein Marker vorhanden ist, wird der Plenty-Auto-Comment (Retourensendung angemeldet: GLSShipping…) ignoriert und nur der Amazon-Comment ins Sheet geschrieben. Dadurch entstehen Carrier-Werte GLS-Prime / DHL-Prime, die 02 sauber routen kann.
  • Hardcoded itemsPerPage=50 — kein Paging. Wenn an einem Tag mehr als 50 neue Retouren entstehen (Black Friday, Marketplace-Bursts), gehen die hinteren verloren bis zum nächsten Run.
  • Cutoff 21 Tage — Plenty-Aufträge älter als 21 Tage werden ignoriert. Wenn eine alte Retoure verspätet eine Sendungsnummer bekommt, wird sie nicht erfasst.
  • itemsPerPage=50 + Cutoff — Annahme: in 21 Tagen entstehen weniger als 50 neue Retouren. Aktuell erfüllt, aber Wachstum beobachten.
  • Sentinel-Inkonsistenz im Code (_empty vs. _noTracking) — funktional egal, aber verwirrend beim Debug.
  • Kein try/catch um Comment-Call (3. Plenty-Call) → Fehler reißt den ganzen Auftrag mit. Die anderen 2 Calls sind try/catched.

Debug-Anleitung

  1. n8n → 01 Retouren-Erfassung → Executions → Filter „Failed" + heute.
  2. Wenn Run grün, aber keine neuen Zeilen: schau im Code-Node-Output, ob _empty: true oder _noTracking: true rauskommt. Beides heißt „nichts Neues / kein Tracking gefunden".
  3. Wenn Run rot bei Daten aufbereiten: Plenty-Response unerwartet — Susi pingen.
  4. Wenn Run rot bei Notizen holen: einer der 3 Plenty-Calls scheiterte. Wahrscheinlich 401 (Login-Lock) oder 5xx (Plenty-Wartung).

Entscheidungen / Geschichte

  • 2026-05-12: Marker-Patch eingeführt (Amazon-RSA-Comment-Priorisierung) — siehe SUB Retoure.
  • (älter): Cutoff auf 21 Tage festgelegt (matched mit DHL-Eskalations-Frist).