Zum Inhalt

[SUB] PlentyOne Lookup

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 Sucht zu einem Zendesk-Ticket den passenden Plenty-Auftrag — über Bestellnummer, externalOrderId oder Email.
Wann greift er Aus Parent-Workflows wie MOKI Dispatcher v2 heraus per Subworkflow-Call.
Sichtbarer Effekt für CS Keiner direkt — liefert orderData an den Parent. Sichtbar nur über lookup_status in der Internal Note (found/not_found/skipped).
Symptom wenn kaputt Parent-Workflow zeigt 401-Fehler oder lookup_status: error mit Plenty-bezogener Message.
Owner Susi (Backup: TBD)
Eskalation Susi direkt anschreiben (Slack-DM). Bei 401: zuerst Runbook „PlentyOne Login entsperren" durchlaufen.
Link in n8n SUB PlentyOne Lookup

Architektur

flowchart LR
  In[Input von Parent
ticketData] --> Login[Login PlentyOne]
  Login --> Regex[Regex Extraktor]
  Regex --> Strategy{Lookup-Strategie}
  Strategy -- direct --> Direct[GET /orders/]
  Strategy -- external --> Ext[GET /orders/?externalOrderId=...]
  Strategy -- email --> Email[GET /orders/?contactReceiver=...]
  Strategy -- skip --> Skip[Return: nicht gefunden]
  Direct --> Out[Return orderData]
  Ext --> ValExt[Validierung extern] --> Out
  Email --> Out
  Skip --> Out

Subworkflow-Calls

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

  • (keine — dieser Workflow ist selbst ein Sub)

Trigger & Datenfluss

  • Trigger: Subworkflow-Call aus Parent.
  • Input: ticketData mit subject, body, requester_email.
  • Auth: Custom Auth Credential Plenty Login Body → Login PlentyOne-Node liefert access_token. Folgecalls referenzieren via =Bearer {{ $('Login PlentyOne').item.json.access_token }} (siehe Auth-Patterns).
  • Output: { status, orderData, lookup_status, lookup_method, lookup_error? }.

Lookup-Strategie (Reihenfolge)

  1. Wenn Regex eine orderId (Plenty-Internal) findet → direct.
  2. Wenn Regex eine externalOrderId findet:
    • Bei MKB-… (mokebo-Marketplace-Format): wenn Sender-Email keine Marketplace-Forwarder-Adresse ist, email-Strategie. Sonst skip.
    • Sonst → external.
  3. Sonst → email (Default), außer Sender ist ein Marketplace-Forwarder → skip.

Regex-Patterns (in Regex Extraktor)

# Pattern Marketplace
1 /MKB-\d{4,6}/g mokebo-Internal
2 /302-\d{7}-\d{7}/g Amazon
3 … …
4 /517\d{10}(-[A-Z])?/g XXXLutz (zu eng — siehe Stolperstein)

Bekannte Stolpersteine / Edge-Cases

  • XXXLutz-Pattern erkennt 5xxx… nicht. Echte Bestellnummern beginnen z.B. mit 500… (5002604318955-A). Pattern muss erweitert werden — Susi liefert echte Beispiele aus den letzten 4 Wochen oder gibt Vendor-Doku-Zugang.
  • Marketplace-Forwarder als Sender. marketplace@…, mail-marketplace@…, donotreply@…, no-reply@…, reply+… dürfen nie als Email-Lookup-Quelle verwendet werden — falsche Customer-Matches. Siehe Pattern in Lookup Strategie-Code (MARKETPLACE_EMAIL_PATTERNS).
  • accessToken vs. access_token. PlentyOne-Response liefert snake_case. Vereinzelte alte Workflows nutzen camelCase — Tippfehler aus alten Versionen, korrekt ist access_token.
  • Token wird pro Run neu geholt. Kein Caching — Stand 2026-05-11. Geplant: in [SUB] Plenty Auth extrahieren.

Debug-Anleitung

  1. n8n → Executions → Filter „Failed".
  2. Bei 401 / 403 am Login PlentyOne-Node: → Runbook „PlentyOne Login entsperren".
  3. Bei lookup_status: not_found: prüf den Ticket-Body — ist da überhaupt eine Bestellnummer oder Email-Match möglich?
  4. Bei lookup_status: error mit Plenty 5xx: Plenty-Wartung oder Rate-Limit. Retry oder warten.

Entscheidungen / Geschichte

  • 2026-05-06: Plenty-Login-Lock-Diagnose dokumentiert (siehe Runbook).
  • (offen) Marketplace-Email-Skip-Logik soll in Lookup Strategie-Code aufgenommen werden.