Bestellungen mit dem ERP abgleichen

Für die meisten Mittelständler ist das ERP das führende System für die Bestellung, sobald sie existiert. Damit ist die Grenze zwischen den beiden Systemen der Ort, an dem Abgleichprobleme wohnen — und an dieser Grenze zählen genau drei Felder.

Die drei Referenzen

Drei Nummern, drei Eigentümer. Jede Abgleichfrage beantwortet eine von ihnen, und zwei davon zu verwechseln ist der Weg, auf dem eine Zahlung der falschen Bestellung zugeordnet wird.

customer_order_number ist die Nummer, die Ihren Kunden interessiert. Seine Kreditorenbuchhaltung gleicht Ihre Rechnung gegen seine PO ab. Eine Rechnung ohne diese Nummer kommt regelmäßig unbezahlt zurück, und Ihre eigene Bestellnummerierung hilft dann nichts.

external_ref ist die Nummer, die Ihre Kollegen interessiert. Wenn der Innendienst das ERP offen hat und die Shop-Bestellung daneben, ist das das Feld, das die beiden Bildschirme verbindet.

Die Bestätigung ist die Übergabe

acknowledged_at ist der Moment, in dem das abwickelnde System die Verantwortung übernimmt. Der Stempel fällt, wenn das ERP die Bestellung bestätigt und seine eigene Referenz zurückschreibt.

Danach ist die Bestellung hier eingefroren: Adressen, Käuferdaten und Referenzen lassen sich nicht mehr bearbeiten, denn das ERP plant jetzt gegen das, was es erhalten hat. Ein Tenant kann späte Änderungen erlauben, und manche ERPs vertragen das — aber verstehen Sie, was Sie einschalten, bevor Sie es tun.

Wo Sie suchen, wenn eine Bestellung nicht ankam

1. Der Tab Verlauf der Bestellung. Jeder Übergang steht hier, mit Akteur. Ist das Aufgabe-Ereignis da und danach nichts, wurde die Bestellung korrekt aufgegeben, und das Problem liegt stromabwärts.
2. Integration Studio › Integrationen › Läufe. Das ist der Bildschirm, der „die Bestellung hat SAP nie erreicht“ beantwortet; siehe Syncs überwachen.
3. Das Ereignis selbst. Integrationen reagieren auf das Aufgabe-Ereignis, nicht darauf, dass eine Zeile erscheint. Eine Bestellung, die in pending auf Freigabe wartet, ist nicht aufgegeben, und ein Konsument, der auf das falsche Signal reagiert, wickelt Bestellungen ab, die niemand freigegeben hat.

Die Doppelverarbeitungsfalle

Das Leben einer Bestellung wird mit Absicht zweimal veröffentlicht: als benannte Ereignisse für jedes einzelne Geschehen, und als roher Audit-Feed jedes Übergangs.

Wenn Sie doppelte Aufträge in Ihrem ERP untersuchen, prüfen Sie das vor allem anderen. Es ist der teuerste Konfigurationsfehler an dieser Grenze, und vom ERP aus gesehen sieht er wie ein ERP-Problem aus.

Die zwei Türen zurück hinein

Ein externes System ändert eine Bestellung auf genau zwei Arten:

• Bestätigen — einmal, mit der Referenz des ERP.
• Sendung anlegen — so oft, wie es Lieferungen gibt, mit Positionen, Mengen, Versanddienstleister und Sendungsnummer.

Alles andere — der Käufer, die Adressen, die Summen — liegt in der Bestellung fest. Will Ihr ERP die Summen einer Bestellung ändern, ist das kein Abgleichproblem, sondern ein Dissens darüber, was verkauft wurde, und der gehört in ein Gespräch mit dem Kunden.

Ein wöchentlicher Abgleich

Fünf Prüfungen, in dieser Reihenfolge:

1. Unbestätigte Bestellungen, älter als Ihre Durchlaufzeit. Sollten null sein.
2. Bestellungen ohne customer_order_number, wo Ihre Kunden eine verlangen. Reparieren Sie den Checkout statt der Bestellungen.
3. Bestellzahl des Zeitraums gegen die Zahl Ihres ERP für denselben Zeitraum. Eine Lücke von eins ist eine Bestellung; eine Lücke, die täglich wächst, ist eine kaputte Integration.
4. Geliefert, aber unbezahlt — fulfillment_status = fulfilled, payment_status = open — gegen die offenen Posten Ihres ERP.
5. Hier erfasste Sendungen gegen dort ausgestellte Lieferscheine. Eine Lücke heißt: Das Lager versendet an der Plattform vorbei.

Nummer 3 und 5 fangen die stillen Fehler. Ein täglicher Alarm auf Nummer 1 fängt sie schneller.

Weiter

• Bestellungen, die hängen bleiben: die Diagnose je Bestellung.
• Häufige Sync-Fehler: wenn die Integration selbst der Fehler ist.