Shopware 6 an die Warenwirtschaft anbinden

Zuerst die Richtung je Datenbereich festlegen #

Eine Shop-ERP-Anbindung besteht meist aus drei getrennten Aufgaben: Bestellungen wandern aus dem Shop in die Warenwirtschaft, Bestände und Preise laufen in die Gegenrichtung, und Status- sowie Versandinformationen kommen zurück in den Shop. Jede dieser Richtungen hat eigene Anforderungen an Aktualität, Fehlerbehandlung und Abnahme.

Bevor es um Endpunkte geht, sollte je Datenbereich feststehen, welches System führt. Der Ratgeber zur Schnittstellenplanung beschreibt diese Vorarbeit im Detail. Dieser Artikel setzt sie voraus und zeigt, worauf es bei Shopware 6 technisch ankommt.

Welche Schnittstelle Shopware dafür vorsieht #

Für Systemanbindungen ist die Admin API zuständig. Sie bietet CRUD-Zugriff auf die zentralen Entitäten wie Produkte, Bestellungen, Kunden und Medien und ist laut Shopware-Dokumentation ausdrücklich für Integrationen, Importe und Datenabgleiche gedacht. Die Store API ist davon zu trennen: Sie bedient Storefronts und Apps aus Kundensicht, nicht die Datenpflege im Hintergrund.

Für viele Schreibvorgänge auf einmal gibt es den Sync-Endpunkt /api/_action/sync. Er ist eine Ergänzung der Admin API und führt mehrere Schreiboperationen, also Anlegen, Aktualisieren und Löschen, in einem Aufruf aus. Die Referenz zu Bulk-Payloads beschreibt Aufbau und Verhalten. Wie groß ein Paket sinnvollerweise wird, ist eine Messfrage und keine feste Zahl.

Ob die Anbindung als externer Dienst über die API läuft oder als Erweiterung im Shop selbst, ist eine getrennte Entscheidung. Ein eigener Dienst hält Last und Laufzeiten aus dem Shop heraus und lässt sich unabhängig aktualisieren. Eine Erweiterung ist näher an den Daten, muss aber bei jedem Shopware-Update mitgepflegt werden.

Bestellungen übernehmen, ohne Dubletten zu erzeugen #

Der häufigste Fehler bei der Übernahme ist eine zweite Bestellung nach einem Timeout. Der Aufruf ist beim Zielsystem angekommen, die Antwort ging verloren, der nächste Lauf legt denselben Vorgang erneut an. Dagegen hilft ein stabiler fachlicher Schlüssel, der auf beiden Seiten gespeichert wird, etwa die Bestellnummer zusammen mit einer Kennung des Shops.

Praktisch bedeutet das: Vor dem Anlegen wird geprüft, ob zu diesem Schlüssel bereits ein Beleg existiert. Die Eindeutigkeit gehört zusätzlich in die Datenbank des Zielsystems, damit ein gleichzeitiger zweiter Lauf nicht durchrutscht. Erst wenn beides steht, ist eine automatische Wiederholung ungefährlich.

Zur Bestellung gehören mehr Daten als die Positionen:

• Zahlart und Zahlungsstatus.
• Versandart.
• Rabatte und Steuersätze.
• Abweichende Lieferadresse.
• Bei Firmenkunden die Umsatzsteuer-ID.

Kläre früh, welche dieser Felder das ERP verpflichtend erwartet und was passieren soll, wenn eines fehlt.

Status zurückmelden: drei getrennte Zustandsmaschinen #

Shopware 6 führt den Zustand einer Bestellung nicht in einem einzigen Feld. Es gibt drei Zustandsmaschinen: die Bestellung selbst, die Zahlung als Transaktion und die Lieferung. Die Dokumentation zur State Machine beschreibt sie und weist darauf hin, dass nicht jeder Zustand direkt in jeden anderen übergehen kann. Eine Rückerstattung ohne vorherige Zahlung ist zum Beispiel kein gültiger Übergang.

Für die Anbindung heißt das: Das ERP meldet keine beliebigen Statuswerte, sondern löst definierte Übergänge aus. Bilde deshalb ab, welcher Vorgang im ERP welchen Übergang in welcher der drei Zustandsmaschinen bedeutet:

• Ein Versand betrifft die Lieferung.
• Ein Zahlungseingang betrifft die Transaktion.
• Ein Abschluss betrifft die Bestellung.

Plane außerdem, was bei einem ungültigen Übergang passiert. Wird er verworfen, protokolliert oder als Aufgabe für eine Person hinterlegt? Stilles Verwerfen führt dazu, dass beide Systeme unterschiedliche Wahrheiten zeigen und niemand merkt es.

Bestände und Preise zurückschreiben #

Seit Shopware 6.5 ist die Bestandsführung vereinfacht: Das Feld stock trägt den maßgeblichen Wert, und availableStock spiegelt ihn, statt aus offenen Bestellungen berechnet zu werden. Für Systeme mit eigener Logik, etwa mehreren Lagern, sieht Shopware die Ablösung des Bestandsspeichers über AbstractStockStorage vor. Das beschreibt die Entscheidungsvorlage zur Stock API. Prüfe die Details für die Version, die bei dir läuft.

Für den laufenden Betrieb ist wichtiger, was übertragen wird: der verkaufbare Bestand abzüglich Reservierungen, nicht der reine Lagerbestand. Ebenso gehört festgelegt, ob der Shop bei fehlendem Bestand weiterverkaufen darf und wer diese Entscheidung pflegt.

Ein vollständiger Abgleich aller Artikel ist als Notfallwerkzeug sinnvoll, als Dauerbetrieb selten. Übertrage im Alltag nur Änderungen seit dem letzten Lauf und plane den Vollabgleich als bewusst angestoßenen Vorgang außerhalb der Hauptzeiten. Wie sich ein großer Erstimport in Pakete zerlegen lässt, zeigt der Fachartikel zu Datenimporten in Laravel.

Was im Betrieb über den Erfolg entscheidet #

• Jeder Vorgang ist über beide Systeme hinweg auffindbar, ohne dass jemand Serverprotokolle liest.
• Fachliche Fehler wie ein unbekannter Artikel landen bei der zuständigen Person, technische Ausfälle bei der Betreuung.
• Ein abgebrochener Lauf kann gezielt fortgesetzt werden und nicht nur komplett wiederholt.
• Bestände und Bestellungen laufen getrennt, damit ein hängender Bestandsabgleich keine Bestellung blockiert.
• Vor dem Start werden doppelte Meldungen, nicht erreichbare Systeme und ungültige Statusübergänge mit Testdaten geprüft.

Zeitpläne verdienen einen eigenen Blick. Ein Abgleich, der länger läuft als sein Intervall, überholt sich selbst und schreibt alte Werte über neue. Eine einfache Sperre je Abgleichsart verhindert das zuverlässiger als eine großzügig gewählte Wartezeit.

Wenn du eine solche Anbindung planst oder eine bestehende stabiler machen möchtest, findest du unter Shopware-Entwicklung und Schnittstellenentwicklung mehr dazu. Für ein Erstgespräch helfen die Shopware-Version, das eingesetzte ERP und ein Beispielvorgang, der heute Handarbeit verursacht.