Stackrail

Aus echten ERP-Anbindungen, nicht aus Architektur-Folien

Deine Bestellungen müssen einmal im ERP landen. Nicht zweimal

8 Punkte für idempotenten Order-Export aus echten B2B-Anbindungen. Mit den Fehlern, die Buchhaltung und Support sonst später finden.

PDF kostenlos laden

Warum Order-Exports im B2B regelmäßig kaputt gehen

  • Bestellung wird gesendet, ohne dass jemand weiß ob sie angekommen ist

    Der Plugin-Aufruf gibt 200 zurück. Das ERP hat aber noch keinen Auftrag. Ohne Status-Differenzierung verlierst du Vorgänge im Nirgendwo.

  • Beim Retry entsteht der zweite Auftrag im ERP

    Netzwerk-Timeout, Job-Crash, manueller Replay. Ohne externe Referenz oder Idempotenz-Key bucht das ERP brav ein zweites Mal.

  • Buchhaltung sieht Fehler erst, wenn Kunden anrufen

    Fehlerzustände stehen im Plugin-Log, nicht in der Auftrags-Liste. Das Lager versendet auf Basis von ERP-Daten, die nicht synchron sind.

  • Sales-Channel-Logik versteckt sich in If-Verzweigungen

    CH-Auftrag soll direkt ins ERP, DE über den Großhändler, HU mit EK-Preis. Wenn das in einer Methode landet, ist der vierte Channel der Bruch.

  • Lieferschein-Polling hängt am Order-Export

    Aus dem ERP zurück fließen Belege als PDF, oft per Mail-Inbox oder Graph-API. Wenn das im selben Job läuft wie der Export, kippt eines das andere mit.

Was in der PDF steht

  • Idempotenz-Pattern mit konkreten HTTP-Codes

    Wie 200, 201 und 409 zusammenspielen, damit Retries kein Drama sind. Mit Beispiel für Plugin-Implementierung.

  • Atomic Plugin-Transaktionen

    Was in eine Transaktion gehört, was bewusst nicht. Damit ein Crash kein halbes ERP-Auftragsfragment hinterlässt.

  • Sales-Channel-Logik aus dem Plugin halten

    Mapping-Tabellen, Konfiguration im Admin, klare Trennung. Damit der nächste Channel kein neuer Code-Branch ist.

  • Reconciliation Shopware versus ERP

    Wie du täglich automatisch prüfst, ob beide Systeme dieselben Aufträge kennen. Ohne dass du es im Vertrieb merkst.

Auszug aus der Checkliste

Vier der 8 Punkte als Vorgeschmack. Die anderen vier plus die Reconciliation-Strategie stehen in der PDF.

  1. Punkt 1

    Status feingranular trennen

    Status zwischen pending, sent, acknowledged und failed trennen. Erst acknowledged zählt. Sent ohne ack wiederholt automatisch, mit Obergrenze gegen Endlos-Loops.

  2. Punkt 2

    Externe Referenz als Idempotenz-Key

    Shopware-Order-Nummer geht als externer Schlüssel ins ERP. Zweiter Aufruf antwortet mit HTTP 409 plus bekannter Auftrags-ID. Kein Duplikat, kein Fehler.

  3. Punkt 3

    HTTP 409 als erfolgreichen Pfad behandeln

    409 bestätigt Idempotenz. Plugin liest die Auftrags-ID, speichert sie im Custom-Field, setzt Status acknowledged. Retry-Safety ist eingebaut, nicht aufgepfropft.

  4. Punkt 4

    Sales-Channel-spezifische Regeln in Config halten

    Welcher Channel direkt ins ERP geht, welcher über Zwischensystem, welcher gar nicht. Pro Sales-Channel als Config-Feld, nicht als If-Verzweigung im Code.

Vorschau: Order-Export Shopware ins ERP, 8 Punkte

Lade die PDF kostenlos

Trag deine E-Mail ein, dann schicken wir dir den Download-Link plus Passwort per Mail. Kein Newsletter, kein Verteiler.

  • 8 Punkte für idempotenten Order-Export aus echten Anbindungen
  • HTTP-409-Pattern als acknowledged statt error
  • Reconciliation Shopware versus ERP, automatisch
  • Die Lieferschein-Polling-Falle, die wir einmal gestellt haben

Häufige Fragen zum Order-Export

  • Brauchen wir wirklich Idempotenz, wenn doch alles über einen Job läuft?

    Ja. Spätestens beim ersten Retry, beim ersten manuellen Replay oder beim ersten Plugin-Update mit Datenmigration brauchst du sie. Idempotenz nachträglich einzubauen heißt, die History der bisherigen Aufträge bereinigen zu müssen. Das ist nie billiger als sie von Anfang an mitzudenken.

  • Was machen wir, wenn das ERP keinen 409 zurückgibt?

    Dann brauchst du ein Vorhalte-Pattern. Plugin fragt vor dem Insert per Lookup, ob die externe Referenz schon existiert. Zwei Calls statt einem, aber Idempotenz bleibt erhalten. Wir dokumentieren das Pattern explizit in der PDF, weil viele Legacy-ERPs genau so funktionieren.

  • Lieferschein-Polling im selben Job oder separat?

    Separat. Order-Export und Beleg-Rückfluss sind unterschiedliche Lifecycles. Der Export geht beim Bestelleingang, der Beleg-Rückfluss läuft asynchron Stunden bis Tage später, je nach Versand und Buchhaltung. Wenn das im selben Job hängt, kippt eines das andere im Fehlerfall.

  • Wie groß ist der Aufwand für einen sauberen Order-Export?

    Das hängt am ERP. Moderne REST-APIs mit dokumentierter Idempotenz: zwei bis drei Sprints inklusive Reconciliation-Job und Monitoring. Legacy-ERPs mit XML, Basic-Auth und Tagesgrenzen: drei bis fünf Sprints, weil Idempotenz dort meist nachgebaut werden muss. Konkret schätzen wir nach 30 Minuten Erstgespräch, wenn wir wissen, gegen welches System wir sprechen.

  • Geht das auch ohne eigenes Plugin?

    Selten sinnvoll. Standard-Konnektoren decken den glücklichen Pfad ab und scheitern an den B2B-Sonderfällen, die in der PDF stehen. Sales-Channel-Trennung, kundenspezifische Preise im Export, mehrere Mandanten, Belege-Rückfluss. Wenn dein Use-Case zu 80 Prozent Standard ist, nimm Standard. Bei den interessanten 20 Prozent zahlt sich ein eigenes Plugin ab dem ersten Jahr.

Order-Export bei dir gerade ein Thema?

30 Minuten Erstgespräch, kostenlos. Wir gehen einen konkreten Punkt deiner ERP-Anbindung durch und sagen konkret, was wir tun würden.

Raphael Schnick

Raphael Schnick

Geschäftsführer & Softwareentwickler

Erstgespräch buchen

Öffnet die Buchungsseite in einem neuen Tab.

Oder direkt per Mail anfragen

Wer steckt dahinter?

Stackrail GmbH ist Shopware Partner mit Sitz in Singen am Hohentwiel. Wir bauen ERP-Anbindungen für den B2B-Mittelstand in DACH, pflegen eigene Plugins im Shopware Store und schreiben offen über das, was wir in echten Projekten gelernt haben. Auch über die Doppelbuchungen.

Wenn du tiefer einsteigen willst