Retourendaten zwischen Shop, ERP und Zahlungssystem abgleichen

Wenn Sie Shop, ERP und Zahlungsdienst verbinden, braucht eine Retoure mehr als ein gemeinsames Feld „erledigt“. Die Integration muss erkennen, welche Position zurückkommt, was mit dem Bestand geschieht und welchen Stand die zugehörige Erstattung hat. Legen Sie diese Beziehungen vor der Schnittstellenumsetzung fest.

Einen Fall vollständig zuordnen

Ein fiktiver Wohnaccessoire-Shop hat mit der Bestellung O-86 zwei Vasen geliefert; die Bestellung ist bezahlt. Eine Vase kommt mit abgesplittertem Rand zurück. Für diese Vase ist im Beispiel eine Erstattung von 24 EUR vereinbart. Das Team plant folgende Zuordnung:

Die Verknüpfung erfolgt über Positionen und Vorgangsreferenzen. Gleicher Produktname oder gleiche Artikelnummer allein reichen nicht, wenn derselbe Artikel in mehreren Bestellungen vorkommt.

Ein internes Integrationsmodell festlegen

Der folgende Datensatz ist ein eigener Entwurf für diesen fiktiven Fall, kein API-Aufruf eines Anbieters. Die Mengen beziehen sich auf den Retourenvorgang; der Betrag steht in EUR-Cent.

{
  "returnId": "R-86",
  "orderReference": "O-86",
  "shopOrderLine": "OL-86-A",
  "shopFulfillmentLine": "FL-86-A",
  "erpDeliveryLine": "DL-86-A",
  "receivedQuantity": 1,
  "saleableStockDelta": 0,
  "refund": {
    "paymentReference": "PAY-86",
    "amountMinor": 2400,
    "currency": "EUR",
    "state": "requested"
  }
}

Die Referenzen verbinden die Shopbestellposition, die Shoplieferposition und die ursprüngliche ERP-Lieferposition mit der Zahlung. Speichern Sie außerdem die vom Zahlungsdienst zurückgegebene Erstattungsreferenz am Vorgang. Fehlt eine eindeutige Positionszuordnung, soll der Datensatz zur Klärung stehen bleiben, statt durch einen Namensvergleich automatisch gebucht zu werden.

Für jede Änderung die richtige Quelle verwenden

Im Beispiel liefert der Shop den Bezug zur gekauften Position. Das ERP bestätigt Wareneingang, Prüfergebnis und Bestandsfreigabe. Der Zahlungsdienst liefert den Zustand der Erstattung. Diese Zuständigkeiten werden im Datenvertrag festgehalten; andere Systemaufteilungen können eine andere Zuordnung erfordern.

Shopifys ReturnLineItem verweist auf eine Shopify-Lieferposition; die Verbindung zur ERP-Position muss die Integration herstellen. Beim Refund weist die Dokumentation ausdrücklich darauf hin, dass ein Datensatz allein keine erfolgreiche Geldbewegung bestätigt. Stripe beschreibt ebenfalls getrennte Ereignisse für Erstellung, Änderung und Fehlschlag. Die Integration muss die Zustände des tatsächlich gewählten Anbieters auf ihr internes Modell abbilden.

Eine erfolgreiche Erstattung darf deshalb im Beispiel nur den Zahlungszustand ändern. Sie macht die beschädigte Vase nicht verkaufsfähig. Ein Wareneingang wiederum setzt die Erstattung nicht automatisch auf erfolgreich.

Das erwartete Ergebnis prüfen

Prüfen Sie den Fall in einer geeigneten Testumgebung: Die Teilretoure gehört zur richtigen Position, die Bestandsänderung bleibt 0 und 2400 Cent gehören zur richtigen Zahlung. Nach einer bestätigten erfolgreichen Erstattung wechselt deren Zustand, während die Ware gesperrt bleibt. Eine unklare Zahlungsantwort muss als ungeklärt sichtbar bleiben. Eine erneut gelieferte Statusmeldung soll denselben Vorgang aktualisieren. Für die technische Wiederholungsverarbeitung ist zusätzlich eine passende Idempotenzstrategie nötig.

Quellen

• Shopify — ReturnLineItem, GraphQL Admin API

• Shopify — Refund, GraphQL Admin API

• Stripe — Refund and cancel payments