ERP-Anbindung Shopware 6: SAP, JTL, Sage

ERP-Anbindung ist der mit Abstand teuerste, riskanteste und unterschätzteste Teil eines B2B-Shopware-Projekts. Bei drei von vier Migrationsprojekten, die wir nachträglich übernehmen, ist sie auch der eigentliche Grund für den Re-Launch: nicht das Design, nicht die Performance, sondern Bestände, die in Shop und ERP auseinanderlaufen.

Drei Integrationsmuster, drei Use-Cases

Muster 1: ERP führt, Shop ist Schaufenster

Stammdaten (Artikel, Preise, Lagerbestände) leben im ERP und werden in Richtung Shop synchronisiert. Bestellungen wandern unmittelbar zurück ins ERP, das auch die Kunden-Stammdaten besitzt. Dieses Muster funktioniert für 80 Prozent der klassischen B2B-Mittelständler. Vorteil: nur eine Wahrheit, klare Verantwortung. Nachteil: Shop-Edits wirken erst nach ERP-Sync.

Muster 2: Shop führt für Marketing, ERP für Operations

Marketing-relevante Felder (Texte, Bilder, Kategorisierungen, SEO-URLs) leben im Shop, operative Felder (Preise, Bestände, Bestellungen) im ERP. Felder werden trennscharf aufgeteilt, der Sync ist bidirektional, aber nicht widersprüchlich. Aufwendiger im Setup, gewinnt an Wert ab etwa 10.000 Artikeln oder zwei Marken.

Muster 3: Middleware als Wahrheit

Eine eigene Layer (Akeneo PIM, eigene Postgres-Tabelle, Snowflake, sogar n8n bei kleinen Stacks) hält den Master-Datenbestand. Shop und ERP sind beide Konsumenten. Erfordert Disziplin und ein Team, das die Middleware betreibt. Lohnt sich, wenn ein dritter Kanal (Amazon, B2B-Portal, Marktplätze) dazukommt.

SAP-Anbindung: ehrliche Worte

SAP-Integrationen kosten unabhängig vom Shop-System. Wir sehen drei realistische Pfade:

• SAP-IDoc-basiert via Middleware (Magnalister, ERP-Bridge, eigene Java-Komponente). Klassisch, gut gehärtet, teuer im SAP-Beratungsteil.
• SAP-OData direkt aus Shopware 6 heraus. Modern, schlank, setzt voraus, dass der SAP-Basis-Kollege OData-Services freigibt. Politisch oft das Schwierigste.
• Datei-basiert (CSV/XML aus SAP, Polling von Shopware-Konnektor). Quick-Win für kleine Bestandsmengen, skaliert nicht über 50.000 Artikel.

Unsere Empfehlung in 2026: OData wenn politisch machbar, sonst Middleware-Pfad. Den Datei-Pfad nutzen wir nur als Übergangslösung.

JTL-Wawi: der unaufgeregte Standardweg

JTL liefert eigene Konnektoren und Sync-Logik mit. Für klassische B2C- und gemischte B2B-Shops ist das der schnellste Weg in den Live-Betrieb. Grenzen tauchen bei drei Themen auf:

• Multi-Lagerstandorte mit eigenen Reservierungslogiken
• Streckenlieferanten ohne JTL-Lagerführung
• Kundengruppen-spezifische Preisaufschläge auf bereits berechnete Sondernpreise

Lösbar, aber jedes dieser Themen kostet typischerweise 8 bis 20 Personentage in der Integration.

Sage 100 und KMU-ERPs (Lexware, Büro+, Weclapp)

Für KMU-Systeme empfehlen wir fast immer einen schlanken Eigenbau-Konnektor. Die verfügbaren Off-the-shelf-Konnektoren sind oft pflegeschwach, an einzelne ERP-Versionen gekoppelt und teurer als zwei Wochen sauberer Eigenentwicklung. Der Eigenbau hat den Vorteil, dass Sie genau wissen, was passiert: ein dedizierter Sync-Service in Node oder PHP, ein klares Datenmodell, idempotente Jobs.

Was wir aus Fehlern gelernt haben

1. Lagerbestand ist heiliger als Preis

Ein falscher Preis ist ärgerlich, eine doppelt verkaufte Sondereinheit ist ein Servicefall. Wir bauen Bestandsabgleich immer als kurzgetaktete Pulls (5 bis 15 Minuten) plus Webhook-basierte Sofort-Korrekturen aus dem ERP.

2. Idempotenz schlägt Geschwindigkeit

Jeder Job, der zweimal laufen kann, ohne Schaden zu machen, ist Gold wert. Wir setzen auf klare Job-IDs, deren Wiederholung folgenlos ist. Das erlaubt aggressives Retry und verhindert die meisten Notfälle nachts.

3. Monitoring vor Migration

Bevor Sie Daten migrieren, instrumentieren Sie den Sync-Pfad. Wir setzen Sentry oder BetterStack für Fehler ein, plus eine kleine Grafana-Tafel mit Job-Lauf-Zeiten und Fehlerquoten. So sehen wir Drift in den ersten Stunden, nicht erst beim ersten Kundenanruf.

Aufwandsbänder