Die technische Orchestrierung eines sogenannten „Blended Stores“ – also der parallele Betrieb von Direct-to-Consumer (D2C) und Business-to-Business (B2B) in einer einzigen Shopware 6 Instanz – erfordert eine absolut kompromisslose Datenarchitektur. Wenn Sie Endkunden und Großhändler über dasselbe Frontend bedienen, darf die Trennschärfe bei Preisen, Sortimenten und Konditionen nicht erst im Shop-System oder durch fehleranfällige Plugins erzeugt werden. Die führende Instanz für diese Geschäftslogik muss zwingend Ihre Warenwirtschaft sein. In diesem Setup fungiert die Sage 100 als Single Source of Truth, die über eine performante Schnittstelle den Shopware 6 Store dynamisch steuert. Lassen Sie uns die Architektur und die konkreten Synchronisationsprozesse auf API-Ebene detailliert aufschlüsseln.
Die Systemarchitektur: Kundengruppen-Mapping zwischen Sage 100 und Shopware 6
Ein Blended Store lebt von der personalisierten Auslieferung von Inhalten, Preisen und Checkout-Regeln. In Shopware 6 übernimmt der „Rule Builder“ diese Aufgabe. Doch die Bedingungen für diese Regeln (z. B. „Kunde ist im B2B-Segment“, „Kunde hat Status Großhändler A“) müssen aus dem ERP-System gepusht werden. Wenn wir eine Schnittstelle konfigurieren, mappen wir die Kundengruppen und individuellen Debitoren-Eigenschaften aus der Sage 100 direkt in die Customer Data von Shopware.
Sobald sich ein B2B-Kunde im Shop einloggt, gleicht das System im Hintergrund die aus der Sage 100 übergebenen Flags ab. Das Frontend schaltet in Millisekunden von der B2C-Brutto-Ansicht (D2C) auf die B2B-Netto-Ansicht um. Dieser Vorgang erfordert eine saubere Anlage der Kundenstämme in der Warenwirtschaft. Das bedeutet konkret: Neuanmeldungen im B2B-Bereich des Shops werden als Leads in die Sage 100 geschrieben, dort vom Vertrieb geprüft, freigegeben und anschließend pusht die Schnittstelle für die Sage 100 das Freigabe-Flag via API-Call zurück an Shopware.
Preismatrizen: Kundenindividuelle Konditionen aus dem ERP orchestrieren
Die Preisberechnung ist bei hybriden Geschäftsmodellen der kritischste Faktor. D2C-Kunden sehen Standard-Bruttopreise, eventuell flankiert von temporären Streichpreisen. Im B2B-Sektor hingegen greifen in der Sage 100 hochkomplexe Regelwerke: Rabattgruppen, kundenindividuelle Sonderpreise, abweichende Währungen oder detaillierte Staffelpreise.
Es ist ein klassischer Architekturfehler, diese Logik im Shop-System nachbauen zu wollen. Stattdessen nutzen wir das „Advanced Pricing“ von Shopware 6 als reines Empfangsgefäß für die Payload aus der Sage 100. Der Prozess sieht wie folgt aus:
- Basispreislisten: Die Sage 100 übergibt die reguläre B2C-Preisliste als Standard-Pricing an den Shop.
- Erweiterte Preismatrizen: Über Delta-Sync-Mechanismen werden kunden- oder kundengruppenspezifische Rabattmatrizen aus der Sage 100 extrahiert. Die Schnittstelle transformiert diese in das JSON-Format, das die Shopware 6 Sync-API für Advanced Pricing erwartet.
- Staffelpreise: Abnahmemengen und die dazugehörigen Stückpreise werden artikelgenau aus dem ERP synchronisiert, sodass der B2B-Einkäufer im Shop sofort seine individuellen Margen sieht.
Da wir hier von enormen Datenmengen sprechen – stellen Sie sich 50.000 Artikel mit jeweils 5 kundenindividuellen Preisstaffeln vor –, muss der Datensync als asynchroner Queue-Prozess laufen, der primär auf Datenbank-Triggern (Delta-Sync) basiert. Nur geänderte Preiskonditionen lösen einen API-Call aus, um die Serverlast auf ein Minimum zu reduzieren.
Echtzeit-Lagerbestände und intelligente Verfügbarkeitsanzeigen
Die Anforderungen an die Logistikkommunikation sind im D2C- und B2B-Bereich völlig konträr. Ein Endkunde bestellt ein einzelnes Produkt und erwartet eine sofortige Verfügbarkeit. Ein Großhändler bestellt Europaletten-Weise, rechnet aber mit branchenüblichen Lieferzeiten. Wenn beide Zielgruppen auf dasselbe physische oder logische Lager in der Sage 100 zugreifen, droht Over-Selling.
Die Sage 100 berechnet den „frei verfügbaren Bestand“ unter Berücksichtigung von Reservierungen und offenen Aufträgen. Die Schnittstelle überträgt diesen Wert an Shopware 6. Um den Blended Store abzusichern, implementieren wir oft Pufferbestände: Das ERP meldet dem Shop beispielsweise ab einem realen Lagerbestand von 5 Stück im D2C-Kanal „ausverkauft“, um Retouren-Umtausch oder spontane B2B-Großaufträge abzusichern. B2B-Kunden wiederum können in Shopware 6 durch ERP-gesteuerte Flags autorisiert werden, auch Artikel mit negativem Bestand (Backorders) in den Warenkorb zu legen, da die Sage 100 im Hintergrund automatisch den Beschaffungsprozess beim Lieferanten anstößt.
Offizielle OEM-Anbindung: Der architektonische Exkurs zur SelectLine
Ein kurzer Blick über den Tellerrand für Systemlandschaften mit anderen ERP-Präferenzen: Sollten Sie in Ihrer Infrastruktur auf die SelectLine setzen, realisieren wir exakt dieses komplexe Zusammenspiel über unsere offizielle OEM-Anbindung für Shopware. Die SelectLine agiert hierbei in Kombination mit Shopware als hochgradig synchronisiertes Gespann. Sämtliche Artikelstrukturen, Kundengruppen und mehrschichtigen Preismatrizen werden nativ aus der SelectLine in den Shopware-Store gepusht. Da es sich um die offizielle OEM-Anbindung handelt, garantieren wir eine tiefe Update-Sicherheit und eine verlustfreie Datendurchlässigkeit, die für den stabilen Betrieb eines solchen Blended Stores zwingend erforderlich ist.
Steuerungslogik für das Fulfillment und Versandanbindungen in der Sage 100
Sobald der Bestell-Button im Shop gedrückt wird, verlagert sich die Intelligenz vollständig in die Warenwirtschaft. Wenn wir über komplexe Versandanbindungen und Fulfillment-Prozesse sprechen, ist die Sage 100 das absolute Kraftzentrum Ihrer Logistik. Ein Blended Store erzeugt völlig unterschiedliche Pick-, Pack- und Versand-Workflows.
Eine D2C-Bestellung muss auf Geschwindigkeit optimiert sein. Die Schnittstelle importiert den Webshop-Auftrag in die Sage 100, das System generiert per Auto-Workflow direkt den Lieferschein und triggert die Versandanbindung. Das Versandlabel (z. B. DHL oder DPD) wird gedruckt, und die Tracking-Nummer wandert sofort per API-Request zurück in den Shopware Store.
Eine B2B-Bestellung hingegen erfordert oft Teillieferungen, Speditionsversand oder die Zusammenführung mehrerer Bestellungen (Sammellieferscheine). Die Sage 100 erkennt anhand des Kundengruppen-Flags der importierten Bestellung sofort, dass es sich um einen Großhandelsauftrag handelt. Hier greifen andere Versandanbindungen – beispielsweise die Übermittlung der Frachtdaten an eine Speditionssoftware.
Sollten Sie Ihre Endkunden-Strategie übrigens noch granularer aufstellen und beispielsweise Shopify als dedizierten, reinen D2C-Kanal neben dem Blended Store betreiben, lässt sich auch dies zentral orchestrieren. Die Sage 100 zieht dann die Bestellungen aus beiden Plattformen an. Sämtliche Versandanbindungen, Label-Drucke und Retouren-Prozesse für Shopify- und Shopware-Aufträge werden einheitlich über das ERP abgewickelt, ohne dass die Logistik-Mitarbeiter jemals die Oberfläche wechseln müssen.
B2B-Features durch ERP-Daten befeuern: Kreditlimits und Schnellbestellungen
Ein herausragender Blended Store zeichnet sich dadurch aus, dass B2B-Kunden Funktionen nutzen können, die für D2C-Kunden unsichtbar bleiben. Diese Features benötigen jedoch belastbare Daten aus der Sage 100.
1. Bonitätsprüfung und dynamische Zahlungsarten
Im Großhandel ist der „Kauf auf Rechnung“ Standard, birgt aber Risiken. Die Sage 100 führt für jeden Debitor ein individuelles Kreditlimit. Über die Schnittstelle synchronisieren wir dieses Limit als Zusatzfeld (Custom Field) in den Shopware 6 Kundenstamm. Zudem übertragen wir den kumulierten Wert der offenen Posten. Der Rule Builder im Shop berechnet die Differenz. Übersteigt der Wert des aktuellen Warenkorbs das noch verfügbare Kreditlimit des Kunden, wird die Zahlungsart „Rechnung“ im Checkout dynamisch ausgeblendet und durch „Vorkasse“ ersetzt. Dies ist ein perfektes Beispiel dafür, wie tiefgreifend ERP-Daten die Frontend-Logik steuern können.
2. Kundenindividuelle Artikelnummern
B2B-Einkäufer suchen oft nicht nach Ihren internen SKU-Nummern, sondern nach ihren eigenen Materialnummern. Die Sage 100 kann pro Debitor und Artikel abweichende Kundenartikelnummern speichern. Übertragen wir dieses Mapping in die ElasticSearch- oder Standard-Suche von Shopware 6, kann der Großhändler im Blended Store seine eigenen Nummern in das Suchfeld eingeben und landet exakt beim richtigen Produkt. Für den D2C-Kunden bleibt dieses Datenfeld irrelevant und unsichtbar.
3. Belegwesen und Historie
Der D2C-Kunde möchte lediglich sehen, ob sein Paket versendet wurde. Der B2B-Kunde benötigt PDF-Rechnungen für die Buchhaltung, Lieferscheinkopien und den Status von Teillieferungen. Auch hier fungiert die Sage 100 als Master. Statt Belege im Shop zu generieren (was buchhalterisch bei B2B oft problematisch ist), generiert die Sage 100 die rechtskonforme Rechnung. Die Schnittstelle pusht das PDF-Dokument – oder zumindest einen sicheren Download-Link – direkt in das Kundenkonto des Shopware-Frontends. Der B2B-Kunde bedient sich im Self-Service, was Ihren Innendienst massiv entlastet.
Fazit: Architektur ohne Kompromisse
Der Betrieb eines Blended Stores mit D2C- und B2B-Segmenten in einem einzigen Shopware 6 Frontend ist technisch hochgradig effizient, sofern die Architektur strikt top-down aufgebaut ist. Die Sage 100 muss die unangefochtene Hoheit über Stammdaten, Preismatrizen, Bestände und komplexe Versandanbindungen behalten. Wenn Sie versuchen, ERP-Logik im Webshop nachzuprogrammieren, enden Sie unweigerlich im Wartungs-Chaos und riskieren fatale Inkonsistenzen bei Preis- und Steuerberechnungen.
Setzen Sie auf eine robuste, API-gestützte Schnittstellenarchitektur, die Delta-Updates nutzt, um Shopware als schnelles, dynamisches Auslieferungs-Frontend zu bespielen. Durch dieses Setup skalieren Sie Ihre Vertriebskanäle ressourcenschonend und bieten sowohl dem spontanen Endkunden als auch dem strukturierten Großhändler eine exzellente, fehlerfreie Customer Experience.