[SUB] Retoure¶

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¶

Architektur¶

flowchart TB
  In[Input von Parent
ticket_id] --> Fetch[Fetch Ticket aus Zendesk]
  Fetch --> Detect{Subject = Amazon-RSA
AND from = donotreply@amazon.com?}
  Detect -- ja --> RSA[Amazon-RSA-Pfad]
  Detect -- nein --> PV[Portalverweis-Pfad]

  subgraph RSA-Pfad
    RSA --> ParseSku[SKUs aus Mail-Body extrahieren]
    ParseSku --> ResolveParent[Plenty: Hauptauftrag holen]
    ResolveParent --> CheckMarker{Idempotency-Marker
schon da?}
    CheckMarker -- ja --> SkipExist[Return: skipped_already_marked]
    CheckMarker -- nein --> CheckChildren{Hauptauftrag hat
schon Retoure?}
    CheckChildren -- ja --> SkipChild[Return: skipped_existing]
    CheckChildren -- nein --> BuildBody[Body bauen: addressRelations,
orderItems, properties]
    BuildBody --> CreateRetoure[POST /rest/orders
Status 9.01/9.02]
    CreateRetoure --> MarkerComment[POST Marker-Comment
am Hauptauftrag]
    MarkerComment --> TrackComment[POST Tracking-Comment
am Retoure-Auftrag]
    TrackComment --> RsaOut[Return: created]
  end

  subgraph Portalverweis-Pfad
    PV --> CheckTag{Tag
'portalverweis-gesendet'
schon gesetzt?}
    CheckTag -- ja --> PvSkip[Return: already_sent]
    CheckTag -- nein --> WriteNote[Internal Note
+ Portal-Link in Zendesk]
    WriteNote --> SetTags[Tags 'portalverweis-gesendet'
und 'kein-portal-eingang']
    SetTags --> PvOut[Return: sent]
  end

  RsaOut --> Out[Return MOKI-Standard-Output]
  SkipExist --> Out
  SkipChild --> Out
  PvOut --> Out
  PvSkip --> Out

Subworkflow-Calls¶

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

• (keine — ist ein reiner Sub)

Trigger & Datenfluss¶

• Trigger: Subworkflow-Call aus MOKI Dispatcher v2 wenn Intent retoure.
• Input: ticket_id (Zendesk-Ticket-ID).
• Output: MOKI-Standard-Convention { ticketId, sub_action, sub_status, sub_reason, sub_macro_id, sub_message }.

Mögliche sub_action-Werte¶

Bekannte Stolpersteine / Edge-Cases¶

• Hermes-Tracking ist Phase 2 — Bei Hermes-RSAs wird die Retoure-Anlage übersprungen (sub_action: …skipped_hermes). Phase 2 zieht Tracking + Regex + Carrier-Map nach. Siehe Glossar → Hermes Phase 2.
• Idempotency-Marker am Hauptauftrag — Format: [n8n] Auto-Retoure für Amazon-RSA Ticket #<ticketId> angelegt: Retoure <retourenAuftragId>. Verhindert Doppel-Anlage (Plenty kann Children eines Parents nicht direkt finden, deshalb Marker-Comment statt Reverse-Lookup).
• Tracking-Comment-Format ist kritisch: [n8n Amazon-RSA #<ticketId>] Retourensendung angemeldet: DHL, Sendungsnummer: <number>. Der Prefix [n8n Amazon-RSA triggert in 01 Retouren-Erfassung die Priorisierungs-Logik — Plenty-Auto-Comment wird ignoriert, nur Amazon-Comment wandert ins Tracking-Sheet.
• Plenty erzeugt trotzdem ein Plenty-Label durch Ereignisaktion 496 (GLS) — bewusst akzeptiert, weil der 01 Retouren-Erfassung-Patch das filtert. Phase 3: Plenty-Label per DELETE /rest/orders/{id}/shipping_packages/{packageId} löschen — noch nicht angegangen.
• Bundle-Bestellungen — Master + Komponenten haben dieselbe SKU am Property typeId: 98. Wenn Master matcht, kommen alle Komponenten automatisch mit (gewollt).
• Portalverweis-Loop-Schutz: Tag portalverweis-gesendet muss prüfbar sein, sonst bekommt der Kunde bei jeder Antwort eine neue Portal-Note.

Debug-Anleitung¶

1. n8n → SUB Retoure → Executions → Filter „Failed".
2. Im Sheet Ticket Log v2 den ticketId suchen → sub_action + sub_reason lesen.
3. Bei Amazon-RSA:
   • sub_action: …failed_no_parent → Hauptauftrag-ID aus Mail prüfen, manuell in Plenty suchen.
   • sub_action: …failed_create → Plenty-API-Call hat 4xx/5xx geworfen. Susi pingen mit Failed Execution.
   • sub_action: …skipped_no_sku → Mail enthält keine bekannte mokebo-SKU. Kein Bug, manuelle Bearbeitung nötig.
   • sub_action: …skipped_unknown_carrier → Carrier in der Mail unbekannt (oder Hermes Phase 1).
4. Bei Portalverweis: check ob Tag portalverweis-gesendet korrekt gesetzt wurde (Zendesk-Ticket öffnen, Tags-Liste).
5. Du darfst Claude konsultieren — siehe Erste Hilfe → Mit Claude debuggen.

Entscheidungen / Geschichte¶

• 2026-05-12: SUB Retoure gebaut + getestet + im MOKI Dispatcher eingebunden. Live ab 13.05.2026.
• 2026-05-12: PlentyOne POST /rest/orders Pflichtfelder empirisch validiert — addressRelations ist Pflicht, sonst Status 1 statt 9.01. Siehe Reference: PlentyOne API.
• 2026-05-12: PlentyOne POST /rest/comments validiert mit userId: 78 (n8n-User) als Pflichtfeld. Siehe Reference: PlentyOne API.
• (älter): Hermes Phase 2 bewusst aufgeschoben.