ERP-Anbindung an Shopware: Datenflüsse zuverlässig automatisieren

Sobald ein Shopware-Shop ernsthaft Bestellungen verarbeitet, kommt fast immer der Wunsch: Aufträge sollen automatisch ins ERP, Bestände in Echtzeit aus dem ERP zurück, Produktdaten nicht doppelt gepflegt werden. Klingt einfach. Ist es nicht.

Was eine ERP-Schnittstelle wirklich leisten muss

Der Anspruch reicht von „Bestellungen exportieren" bis zur vollständigen bidirektionalen Synchronisation. In der Praxis sind das typischerweise diese Datenflüsse:

• Produkte (ERP → Shop): Stammdaten, Preise, Kategoriestrukturen
• Bestände (ERP → Shop): Verfügbarkeit, idealerweise nahezu in Echtzeit
• Kunden (Shop → ERP): Neuregistrierungen, Adressänderungen
• Bestellungen (Shop → ERP): Aufträge mit Positionen, Versand- und Zahlungsdaten
• Status-Updates (ERP → Shop): Versandstatus, Tracking-Nummern, Rechnungen

Die Wahl der richtigen Architektur

1. Direkte Punkt-zu-Punkt-Anbindung

Ein Shopware-Plugin oder Custom-Service spricht direkt mit dem ERP — meist über REST, SOAP oder File-Drops (CSV/XML).
Geeignet für: Standard-ERPs (Sage, Lexware, JTL), klare Datenmodelle, ein Shop.
Risiken: Bei Updates oder ERP-Wechsel viel Arbeit. Schwer zu monitoren.

2. Middleware / iPaaS

Eine Integrationsschicht (n8n, Make, Zapier, Workato, oder selbst gebaut) sitzt zwischen Shop und ERP. Datenflüsse, Mappings und Fehlerbehandlung sind zentral.
Geeignet für: Mehrere Shops/Marktplätze, mehrere ERP-Systeme, sich ändernde Anforderungen.
Risiken: Zusätzlicher Layer, höhere Betriebskosten. Lock-In bei kommerziellen Plattformen.

3. Event-driven über Message-Queue

Shop und ERP publizieren Events in eine Queue (RabbitMQ, Kafka), Verbraucher verarbeiten sie asynchron.
Geeignet für: Hochlast-Setups, mehrere Empfänger pro Event, hohe Resilienz-Anforderungen.
Risiken: Komplexität. Lohnt sich erst ab einer gewissen Größe.

Die häufigsten Fallen

1. Master-Daten-Konflikt: Wer ist Datenhoheit? Wenn Preise sowohl im Shop als auch im ERP änderbar sind, gibt es früher oder später Konflikte. Klare Regel: ein System ist Master pro Datenfeld.

2. Race-Conditions bei Beständen: Wenn der Bestand alle 15 Minuten gepushed wird, verkaufen Sie zwischendurch Produkte, die nicht mehr da sind. Lösung: Reservierungen, Real-Time-Pushes, oder Sicherheitspuffer einbauen.

3. Fehlerbehandlung wird vergessen: Was passiert, wenn das ERP eine Bestellung ablehnt? Verschwindet die Bestellung im Nirgendwo? Eine robuste Schnittstelle hat Retry-Logik, Dead-Letter-Queue und Alerts.

4. Mengengerüst falsch geschätzt: Ein ERP, das mit 50 Aufträgen am Tag stabil läuft, kann bei 5.000 völlig einbrechen. Lasttests vor Go-Live sind Pflicht.

5. Monitoring fehlt: Ohne Logs und Dashboards merken Sie Schnittstellen-Probleme erst, wenn der Kunde anruft. Mindestens: Zähler für erfolgreiche/fehlgeschlagene Syncs, Alarm bei Ausfällen.

Konkrete Empfehlungen

• Schnittstellen-Logik nicht ins Theme oder Standard-Shop-Code packen — eigenes Plugin oder eigener Service.
• Mappings sauber dokumentieren: Welches Feld im Shop entspricht welchem im ERP?
• Idempotenz einbauen: Eine Bestellung darf nicht doppelt im ERP landen, wenn der Sync zweimal läuft.
• Asynchron arbeiten, wenn möglich. Synchrone Echtzeit-Anbindungen sind fragil.
• Test-Modus mit Sandbox-ERP — nichts ist teurer als versehentliche Buchungen im Live-System.

Das richtige Mengengerüst für die Entscheidung

Bei kleinen Shops mit unter 100 Bestellungen pro Tag und einem standardisierten ERP reicht häufig ein bestehendes Plugin (z. B. JTL-Wawi-Connector, ProffixIntegration). Ab dem Punkt, wo Custom-Felder, B2B-Preisfindung oder Mehrlager-Logik ins Spiel kommen, ist eine eigene Anbindung meist die wirtschaftlichere Lösung.