Zu Content springen
Shopware

Effiziente SoftENGINE Shopware Integration: Ein Praxisleitfaden

von Tim Kelle

Effiziente SoftENGINE Shopware Integration: Ein Praxisleitfaden
15:10

Montagmorgen, 8:15 Uhr. Die ersten Bestellungen sind über Nacht im Shop eingegangen – doch ein Blick ins ERP zeigt: Die Bestände stimmen nicht überein. Ein Artikel ist überverkauft, obwohl das Lager leer ist. Ein anderer liegt seit Wochen auf Reserve, obwohl längst ausgeliefert wurde. Der Vertrieb ruft an und fragt nach dem Status einer Bestellung, doch die Information fehlt – weil der Auftrag noch manuell ins ERP übertragen werden muss. Gerade hier hilft die Zusammenarbeit mit einer erfahrenen Shopware Agentur, die Prozesse und Datenflüsse von Anfang an sauber aufsetzt.

Mitarbeiterin arbeitet am Schreibtisch mit zwei Monitoren und Analytics-Dashboard; im Hintergrund Teamarbeit im Büro mit Whiteboard

Die Lösung liegt in einem sauberen, automatisierten Datenfluss zwischen Shopware und einem ERP-System – mit klarer Datenhoheit, stabilen Prozessen und einer durchdachten Integration.

Was bedeutet SoftENGINE Shopware Integration in der Praxis?

Eine SoftENGINE Shopware-Integration bedeutet den kontrollierten, automatisierten Austausch von Informationen zwischen zwei Systemen mit unterschiedlichen Rollen:

  • ERP (z. B. SoftENGINE ERP-SUITE): Warenwirtschaft, Lager, Einkauf, Belege und Buchhaltung
  • Shopware: Verkaufskanal mit Produktdarstellung, Checkout, Content und Marketing
  • Integration: Die Brücke, die dafür sorgt, dass Daten nicht doppelt gepflegt werden müssen

Wichtig: Eine Integration ersetzt keine Stammdaten- und Prozessklarheit. Sie macht Chaos sichtbar, nicht unsichtbar. Laufende Pflege durch Monitoring, Updates und klare Zuständigkeiten sind Pflicht.

Konkrete Vorteile der Integration

  • Weniger manuelle Arbeit und Fehlerquellen
  • Schnellere Auftragsabwicklung mit weniger Support-Tickets
  • Verlässliche Bestände und Preise in Echtzeit
  • Bessere Datenbasis für fundierte Entscheidungen

Für wen ist dieser Leitfaden gedacht?

Dieser Artikel richtet sich an zwei Zielgruppen mit unterschiedlichen Bedürfnissen:

E-Commerce-Starter: Du möchtest verstehen, was du wirklich integrieren musst und was später kommen kann. Du benötigst einen realistischen Aufwands- und Budgetrahmen sowie Orientierung bei der Wahl zwischen Agentur, Connector oder Middleware. Dein Ziel ist ein stabiles Setup, das mit deinem Geschäft wächst.

Technische Projektleiter: Du suchst Details zu Architektur, Datenkonsistenz, Queue-Design, Webhooks und Update-Strategien. Du brauchst Best Practices für Mapping, Statusmodelle, Fehlerbilder und Performance. Dein Ziel ist ein robustes, wartbares System, das auch unter Last sauber läuft.

Herausforderungen, die eine Integration löst

Viele Probleme im E-Commerce gehen auf Daten-Silos zurück:

  • Bestandsprobleme: Überverkäufe, falsche Reservierungen, Teillieferungen – ohne Integration kennt der Shop den echten Bestand nicht
  • Preis- und Konditionenchaos: B2B-Preislisten, Staffelpreise, kundenspezifische Konditionen – manuelles Nachziehen ist fehleranfällig
  • Belege und Buchhaltung: Rechnungen, Gutschriften, Stornos – ohne Automatisierung verlierst du den Überblick
  • Versand und Logistik: Tracking, Statusupdates – Kunden wollen wissen, wo ihre Bestellung ist
  • Reporting: Verlässliche Kennzahlen statt Excel-Zwischenwelten

Die SoftENGINE ERP-SUITE steuert diese Prozesse von der Warenwirtschaft über CRM bis zur Finanzbuchhaltung. Shopware liefert das Frontend und Kundenerlebnis. Die Integration verbindet beides.

Grundentscheidung: Wer ist führend? (Single Source of Truth)

Bevor du technisch startest, musst du eine zentrale Frage klären: Wer ist für welche Daten verantwortlich?

Das Prinzip "Single Source of Truth" bedeutet: Pro Datenart gibt es genau ein führendes System.

Bewährte Aufteilung

  • ERP führend: Artikelstamm (SKU, EAN, Varianten), Preise, Konditionen, Bestände, Lieferbarkeit
  • Shop führend: Content (Erlebniswelten, SEO-Texte, Kategorien, Filterlogik)
  • Transaktionen: Bestellungen fließen vom Shop ins ERP, Status und Belege kommen zurück

Konfliktregeln definieren

Was passiert, wenn ein Artikel im Shop bestellt wird, der im ERP nicht existiert? Wie gehst du mit Dubletten bei Kunden um? Wer ist die Quelle für den Zahlstatus?

Diese Entscheidungen triffst du vor der technischen Umsetzung – sonst hast du später widersprüchliche Daten.

Welche Daten müssen zwischen SoftENGINE und Shopware fließen?

Stammdaten (meist ERP → Shop)

  • Artikel: SKU, EAN, Varianten, Attribute, Einheiten, Steuerklassen
  • Bestände: verfügbar, reserviert, Lagerorte, Mindestbestände
  • Preise: Standard, Aktionen, B2B-Preislisten, Staffelpreise

Shopdaten (Shop → ERP selektiv)

  • Kundenerstellung: wenn das ERP CRM-führend werden soll
  • Adressänderungen: mit Dubletten- und Validierungsregeln

Transaktionsdaten (bidirektional)

  • Bestellungen: Shop → ERP
  • Auftrags- und Lieferstatus: ERP → Shop
  • Versanddaten/Tracking: ERP → Shop
  • Rechnungen, Gutschriften, Stornos: ERP → Shop
  • Zahlstatus: Payment → Shop/ERP

Fehlerfälle testen (Pflicht)

Diese Szenarien musst du durchspielen:

  • Storno nach Rechnung
  • Teilerstattung und Retouren
  • Split Shipment aus mehreren Lagern
  • Preisabweichung ERP vs. Shop beim Checkout

Wenn du diese Fälle nicht testest, erlebst du sie im Live-Betrieb – und dann wird es teuer.

Integrationswege: Welcher passt zu dir?

Shopware-Bordmittel

Gut bei: sehr wenigen Artikeln, seltenen Bestandsänderungen, geringer Komplexität

Grenzen: kein durchgängiger Beleg-/Lager-/Retourenprozess, viel bleibt manuell

Standard-Connector/Plugin

Gut bei: Standardprozessen, schnellem Start

Risiken: Anpassungsgrenzen, Update-Abhängigkeit, Sonderfälle

Middleware/iPaaS

Gut bei: mehreren Systemen (Shop, ERP, WMS, PIM, BI)

Stärken: Mapping, Monitoring, Retry, Transformation

Risiken: zusätzliche Kosten und Komplexität

Individuelle API-Integration

Maximal flexibel, passend zu Sonderprozessen

Risiken: höhere Initialkosten, mehr Verantwortung für Betrieb und Updates

Entscheidungshilfe

  • "Kleiner Shop, wenig Bewegung" → Bordmittel/leichtes Setup
  • "Nur Shopware + ERP, Standardprozesse" → Connector
  • "Mehrere Systeme, viele Datenflüsse" → Middleware
  • "Spezielle Logik, hoher Durchsatz" → Custom

Budget und Aufwand: Realistische Spannen

Aufwandstreiber

  • Datenqualität (Artikelvarianten, Dubletten, Adressen)
  • Komplexität der Preislogik (B2B, Staffel, Aktionen)
  • Lager- und Versandlogik (Multi-Lager, Reservierungen)
  • Retouren, Erstattungen, Beleglogik
  • Anzahl Systeme
  • Realtime-Anforderungen und Volumen

Budgetrahmen (Orientierung)

Umfang Beschreibung Budget Personentage
MVP/Basis Artikel, Bestand, Bestellungen, Versandstatus 8.000–25.000 € 5–20 PT
Erweitert B2B-Preise, Multi-Lager, Retouren, Belege 25.000–70.000 € 20–60 PT
Komplex Viele Systeme, Sonderlogik, hohe Volumina 70.000–150.000 €+ 60+ PT

Laufende Kosten

  • Wartung und Updates
  • Monitoring und Incident-Handling
  • Anpassungen bei Prozessänderungen

Orientierung: 500–2.000 € / Monat (klein) bis 2.000–6.000 € / Monat (komplex)

Agentur-Auswahl: Entscheidende Kriterien

Must-have Fragen

  • Welche Referenzen mit Shopware 6 + ERP-Integration gibt es?
  • Wer liefert ein Datenhoheits-Konzept, Statusmodell, Fehlerhandling und Testfälle schriftlich?
  • Wie wird Monitoring umgesetzt?
  • Wie ist die Update-Strategie?
  • Wie läuft Übergabe, Dokumentation und Schulung?

Wenn du dafür einen strukturierten Einstieg suchst, kann ein Shopware-Check helfen, typische Risiken vor dem Projektstart zu identifizieren.

Red Flags

  • "Wir integrieren erstmal alles" ohne Phasenplan
  • Kein klares Ownership pro Datenart
  • Kein Testplan für Storno, Teilretoure, Teillieferung

Mitarbeiter scannt Pakete im Lager mit Barcodescanner und Tablet; im Hintergrund Monitor mit Lagerkennzahlen und Diagrammen

Die ersten 30 bis 60 Tage: Minimalumfang und Go-Live

Woche 1–2: Vorbereitung

  • Ziele festlegen (z. B. "keine Überverkäufe")
  • Datenhoheit pro Datenart definieren
  • Artikelstamm bereinigen

Woche 3–4: MVP umsetzen

  • Artikel + Bestand ERP → Shop
  • Bestellungen Shop → ERP
  • Versandstatus/Tracking ERP → Shop
  • Sonderfälle testen

Woche 5–8: Stabilisieren

  • Monitoring + Verantwortlichkeiten festziehen
  • Belege anbinden
  • B2B-Preise erst nach stabilen Stammdaten

Merksatz: Erst sauber laufen lassen, dann erweitern.

Technische Details: Integrationsarchitektur

Dieser Abschnitt richtet sich an technische Projektleiter und Entwickler.

Shopware-6-Integration: Konkrete Anknüpfungspunkte

DAL/Sync API: Nutze die Sync API für Massenupdates (Batch), um Throttling zu vermeiden. Beispiel: 500 Artikel pro Request, max. 2 Requests/Sekunde.

Admin API / Store API: Admin API für Backend-Operationen, Store API für Frontend-nahe Daten. Authentifizierung via OAuth2.

Events und Flow Builder: Shopware 6 bietet Business Events (z. B. order.placed). Nutze diese als Trigger für ERP-Schreibvorgänge über Queue-Jobs.

Scheduled Tasks: Für wiederkehrende Jobs (z. B. Bestandsabgleich alle 15 Minuten). Achte auf Overlap-Schutz und Retry-Logik.

Wenn du in der Praxis viel mit Events arbeitest, lohnt sich ein Blick auf den Flow Builder in Shopware 6, um Trigger und Automationen sauber zu strukturieren.

Integrationsmuster: Idempotenz, Retry, Outbox/Inbox

Idempotenz: Jede Order muss idempotent verarbeitet werden. Nutze eindeutige IDs als Deduplication Key.

Retry und Dead-Letter: Bei API-Fehlern (5xx) leg die Nachricht in eine Retry-Queue. Retry-Policy: 3 Versuche mit exponentiellem Backoff.

Outbox/Inbox Pattern: Für hohe Konsistenzanforderungen schreibe Events transaktional in eine Outbox-Tabelle. Ein separater Worker liest die Outbox und sendet an ERP.

Status- und Datenmodell

Shopware unterscheidet drei Statusmaschinen:

  • Order State: open, in_progress, cancelled, completed
  • Delivery State: open, shipped, partially_shipped, returned, cancelled
  • Transaction State: open, paid, partially_paid, refunded, cancelled

Status-Mapping definieren

Shopware Order State ERP Status Trigger/Aktion
open Auftrag erfasst Order.placed Event → ERP Order Create
in_progress Kommissionierung ERP Status-Update → Shopware Delivery State
completed Warenausgang + Rechnung ERP Warenausgang → Shopware Delivery.shipped

Mapping-Beispiel: ERP-Artikel → Shopware-Produkt

ERP-Daten: SKU "ABC-123", EAN, Name, Preis 29.99 EUR (Netto), Bestand 150 Stück, Steuerklasse 19%

Shopware-Daten: productNumber "ABC-123", Preis 35.69 EUR (Brutto = 29.99 * 1.19), stock 150, taxId (19%), Varianten-Mapping

Queue-Design und Throttling

Für Massenupdates nutze eine Queue (Redis oder RabbitMQ). Splitte den Import in Batches (100 Artikel pro Job). Throttling: Max. 2 Requests/Sekunde, bei 429 Response warte exponentiell.

Deploy- und Update-Strategie

Contract Tests: Definiere API-Contracts und teste, dass ERP und Shop sich an die Verträge halten.

Staging: Nutze produktionsnahe Daten (anonymisiert), teste alle Sonderfälle auf Staging vor Live-Deploy.

Versionskompatibilität: Plane pro Shopware-Release einen Testlauf 2–4 Wochen vor Prod-Update.

Monitoring und Traceability

Technische Metriken: Lag (Zeit zwischen ERP-Event und Shopware-Update), Durchsatz, Error Rate

Business-Metriken: Orders in "pending" > 1 Stunde, Bestandsabweichungen > 5 Stück

Traceability: Jede Order hat eindeutige IDs (Shopware Order Number, ERP Auftragsnummer). Logge beide IDs in jedem Prozessschritt.

Testfall-Matrix für Sonderfälle

Szenario Erwartetes Verhalten
Storno nach Rechnung Gutschrift im ERP, Status "cancelled", Kunde erhält Mail
Teilerstattung Teil-Gutschrift, Delivery State "partially_returned", Bestand hochbuchen
Split Shipment Zwei Tracking-Nummern, Delivery State "partially_shipped" → "shipped"
Preisabweichung Shop-Preis gilt, Differenz als Rabattposition im ERP
Artikel fehlt im ERP Order abgelehnt oder als "manuell" geflaggt, Kunde erhält Info

Typische Fehler vermeiden

  • "Wir integrieren erstmal alles" → MVP + Ausbaustufen
  • Unklare Datenhoheit → Dubletten, widersprüchliche Daten
  • Fehlendes Status-Mapping → Falsche Kundeninfos
  • Kein Sonderfall-Testing → Chaos im Live-Betrieb
  • Kein Monitoring → Daten laufen auseinander
  • Zu viel Customizing ohne Doku → Wartungsrisiko

Praxisbeispiele

Szenario A: Go-Live ohne Chaos

MVP: Artikel/Bestand → Shop, Bestellungen → ERP, Versandstatus → Shop. Danach: Rechnungen/Gutschriften + Zahlungsabgleich + Retourenprozess.

Szenario B: Wachstum und Sonderfälle

Multi-Lager + Reservierungen + Teillieferungen, robuste Queue, Retry, Monitoring, Performance-Tuning.

Szenario C: Omnichannel

POS/Kasse + Online-Shop + ERP → ein Bestand, ein Kundenbild, klare Prioritäten bei Preislogik.

Reporting und Controlling

Operativ

  • Offene Bestellungen, Aufträge im Verzug
  • Pickliste, Lieferfähigkeit, Backlog

Management

  • Umsatz, Rohertrag/DB
  • Top-Kunden/Warengruppen
  • Retourenquote, Cashflow-/OP-Sicht

Kennzahlen müssen auf denselben Daten beruhen (ERP als verlässliche Basis).

Finanzprozesse und Buchhaltung

Zwischen Checkout und Beleg passiert viel: Payment-Fees, Teilrückerstattungen, Chargebacks, Stornos nach Abschluss.

Automatisierbar

  • Belegfluss (Rechnung/Gutschrift)
  • OP-Logik
  • Zahlungszuordnung

Stolperfallen

  • Monatsabschluss
  • Storno nach Rechnung
  • Abweichungen Payment vs. ERP-Beleg
  • USt-/Steuerlogik

Vergleich: Shopware vs. ERP

System Verantwortung
Shop (Shopware) Präsentation, Checkout, Content, Marketing
ERP (SoftENGINE) Bestand, Einkauf, Belege, Buchhaltung, Prozesssteuerung
Integration Synchronisiert, übersetzt Status, sichert Konsistenz

Checkliste: Bist du bereit für die Integration?

  • Artikelstammdaten konsistent?
  • Lagerlogik definiert?
  • Preislogik geklärt?
  • Statusmodell + Mapping dokumentiert?
  • Sonderfälle getestet?
  • Monitoring + Verantwortliche benannt?

Vom Chaos zur stabilen Prozesslandschaft

Erinnere dich an den Montagmorgen: Bestände stimmten nicht, Auftragsstatus war unklar, Rechnungen wurden manuell nachgezogen. Jetzt stell dir vor: Du öffnest das ERP, und alles ist da. Die Bestellungen sind über Nacht sauber reingekommen, die Bestände passen, der Versandstatus ist zurück im Shop, und die Rechnung wurde automatisch erzeugt.

Das ist das Ergebnis einer sauberen SoftENGINE Shopware-Integration. Der Erfolg hängt an drei Dingen:

  • Datenhoheit: Wer ist für was verantwortlich?
  • Statuslogik: Wie fließen Informationen zwischen den Systemen?
  • Betrieb: Monitoring, Updates, Tests – auch nach dem Go-Live

Mit einem MVP-Ansatz wird es schneller stabil und sinnvoll ausbaubar. Die SoftENGINE ERP-SUITE bietet die Basis: Warenwirtschaft, Belege, Buchhaltung, CRM. Shopware liefert das Kundenerlebnis. Die Integration verbindet beides – sauber, automatisiert, wartbar.

Dein nächster Schritt: Zeichne deinen Order-to-Cash-Prozess auf. Markiere pro Datenart: Wer ist führend? Wo entstehen Ausnahmen? Sprich dann mit einem Partner, der beides kennt – ERP und Shop. Die beste Integration ist die, die zu deinen Prozessen passt.

Für die saubere Planung technischer und organisatorischer Anforderungen lohnt es sich außerdem, vorab die wichtigsten Shopware-Anforderungen zu prüfen.

 

Diesen Beitrag teilen