Das architektonische Fundament: Shopify B2B-Primitive vs. Sage 100 Datenstrukturen

Um eine saubere Integration zu gewährleisten, müssen wir zunächst die Datenmodelle abstrahieren und mappen. In der Sage 100 verwalten Sie Ihre Geschäftskunden im Stammdatenbereich (Debitor). Hier definieren Sie Rechnungs- und abweichende Lieferadressen, ordnen Preisgruppen zu, hinterlegen individuelle Rabattstaffeln und definieren das Kreditlimit. Shopify B2B bildet diese Struktur durch sogenannte „Companies“ und „Locations“ (Unternehmensprofile und Standorte) ab.

Als Entwickler stehen wir vor der Herausforderung, die flache, kundenbezogene Struktur klassischer B2C-Shops aufzugeben und stattdessen hierarchische B2B-Graphen zu bedienen. Die Schnittstelle muss in der Lage sein, einen Hauptkunden aus der Sage 100 (inklusive seiner KHK-Stammdaten) zu lesen, daraus einen Payload für die Shopify API zu generieren und das Unternehmensprofil samt aller untergeordneten Standorte und zugewiesenen B2B-Käufer (die eigentlichen Shop-Accounts der Einkäufer) anzulegen oder zu aktualisieren.

Unternehmensprofile und Standorte (Company Profiles & Locations) synchronisieren

Der B2B-Einkauf zeichnet sich oft durch dezentrale Strukturen aus. Ein klassischer Anwendungsfall: Ihr Kunde ist ein Filialist. In der Sage 100 führen Sie eine zentrale Hauptadresse für die Rechnungsstellung und 15 abweichende Lieferadressen für die einzelnen Filialen.

Die Synchronisationslogik überführt dieses Konstrukt wie folgt:

• Der Hauptdebitor: Der Debitor aus der Sage 100 wird als Company in Shopify angelegt. Hierbei werden essenzielle Metadaten wie die Umsatzsteuer-Identifikationsnummer (USt-IdNr.) und die primäre Währung fixiert.
• Die Lieferadressen: Jede abweichende Lieferadresse in der Sage 100 wird zu einer Location (einem Standort) innerhalb dieser Company in Shopify.
• Die Ansprechpartner: Die in der Sage 100 hinterlegten Einkäufer werden als B2B Customers in Shopify angelegt und den jeweiligen Locations zugewiesen. Ein Einkäufer kann die Berechtigung erhalten, für einen bestimmten Standort oder für das gesamte Unternehmensprofil zu bestellen.

Jede Änderung in der Warenwirtschaft – sei es eine neue Filialadresse oder ein ausgeschiedener Einkäufer – triggert über die Schnittstelle ein sofortiges Update in Shopify. So verhindern Sie, dass Bestellungen an veraltete Adressen gesendet werden oder unbefugte Personen im Namen des Unternehmens einkaufen.

Komplexe Preislogiken und individuelle Konditionen abbilden

Das Herzstück jeder B2B-Beziehung ist die Preisgestaltung. Die Sage 100 bietet hier ein extrem tiefes und flexibles Regelwerk: von einfachen Preisgruppen über kundenindividuelle Artikelpreise, Mengenstaffeln und Aktionspreise bis hin zu komplexen Matrixrabatten. Shopify löst dieses Problem konzeptionell durch Catalogs (Kataloge).

Die Kunst der Schnittstellenentwicklung besteht nun darin, die dynamische Preisberechnung der Sage 100 so zu extrahieren und zu transformieren, dass sie performant in die Shopify-Kataloge geschrieben werden kann. Hierfür nutzen wir spezialisierte Preis- und Rabattabgleiche, die folgende Szenarien abdecken:

• Preislisten-Mapping: Wenn Sie in der Sage 100 mit festen B2B-Preislisten arbeiten (z. B. „Händler Gold“, „Händler Silber“), generiert die Schnittstelle entsprechende Catalogs in Shopify und ordnet diese den jeweiligen Companies zu.
• Kundenindividuelle Netto-Preise: Hat ein spezifischer Kunde in der Sage 100 hart hinterlegte Sonderpreise für ein bestimmtes Sortiment, wird für diese Company ein exklusiver Catalog in Shopify erzeugt, der exakt diese Festpreise enthält.
• Prozentuale Abschläge: Globale Rabatte (z. B. pauschal 15 % auf die Kategorie „Zubehör“) werden aus den Rabattgruppen der Sage 100 ausgelesen und als prozentualer Preisabschlag im Shopify Catalog abgebildet.

Die Synchronisation muss hochfrequent und delta-basiert erfolgen. Wenn sich der Basispreis eines Artikels in der Sage 100 ändert, berechnet die Middleware im Hintergrund automatisch alle betroffenen Kundenkataloge neu und pusht die angepassten Payloads via GraphQL an Shopify, ohne die API-Ratelimits des Shopsystems zu verletzen.

Zahlungsziele und Kreditlimits (Payment Terms)

Ein B2B-Checkout unterscheidet sich fundamental von einer B2C-Bestellung. Während Endkunden per Kreditkarte oder PayPal sofort bezahlen, erwartet der B2B-Einkäufer den Kauf auf Rechnung mit spezifischen Zahlungszielen – beispielsweise „14 Tage 2% Skonto, 30 Tage netto“. Diese Konditionen sind vertraglich vereinbart und ausschließlich in der Sage 100 gepflegt.

Damit der Shopify-Checkout diese Konditionen respektiert, liest die Schnittstelle die Zahlungskonditionen des jeweiligen Debitors aus der Sage 100 aus und mappt sie auf die Payment Terms in Shopify. Sobald sich der B2B-Käufer im Shop einloggt, erkennt das System sein Unternehmensprofil und schaltet den Rechnungskauf mit exakt den Fristen frei, die im ERP-System hinterlegt sind.

Zudem können Bestellsperren automatisiert übertragen werden. Hat ein Kunde in der Sage 100 sein Kreditlimit überschritten oder befindet sich im Mahnlauf, kann die Schnittstelle das B2B-Profil in Shopify temporär auf „Nur Vorkasse“ umstellen oder den Checkout für diesen Account vollständig blockieren, bis die offenen Posten geklärt sind.

Architekturwechsel: Die offizielle OEM-Anbindung für Shopware

An dieser Stelle ist eine scharfe technologische Trennung erforderlich: Die zuvor beschriebenen Mechanismen beziehen sich explizit auf die Architektur von Shopify in Verbindung mit der Sage 100. Sollten Sie als Shop-System hingegen auf Shopware setzen und als ERP SelectLine nutzen, ändert sich die Systemlandschaft fundamental. Für dieses spezifische Setup kommt die offizielle OEM-Anbindung zwischen SelectLine und Shopware zum Einsatz. Diese tiefe und vom Hersteller autorisierte Integration nutzt völlig andere Endpunkte und Abgleichsroutinen, um die SelectLine-Stammdaten nahtlos im Shopware-Ökosystem bereitzustellen. Es ist essenziell, diese beiden Welten strikt voneinander zu trennen, da die Datenmodelle und Schnittstellenprotokolle der offiziellen SelectLine OEM-Anbindung exklusiv auf Shopware zugeschnitten sind.

Bestellverarbeitung und Fulfillment-Logik (Sage 100 exklusiv)

Zurück in der Welt von Shopify und der Sage 100: Sobald der B2B-Kunde den Checkout in Shopify abschließt, beginnt die kritische Phase der Bestellübernahme. Da B2B-Warenkörbe oft hunderte von Positionen umfassen, muss der Import in die Sage 100 absolut fehlerfrei und transaktionssicher (ACID-konform) ablaufen.

Die Schnittstelle ruft die Bestellung (inklusive der Referenzen auf Company und Location) via Webhook oder Polling ab und erzeugt in der Sage 100 einen entsprechenden Beleg – in der Regel einen Auftrag. Dabei werden nicht nur die Artikelpositionen übergeben, sondern auch die exakten Steuer-Codes, gebuchten Frachtkosten und die im Shop ausgewählten B2B-Zahlungsziele.

Ist der Auftrag in der Warenwirtschaft angelegt, übernimmt die Sage 100 die vollständige Kontrolle über die nachgelagerten Prozesse. Besonders hervorzuheben ist hierbei die Versandanbindung für die Sage 100. Da B2B-Aufträge häufig Teillieferungen erfordern, steuert die Sage 100 das Splitting der Lieferungen, die Kommunikation mit den Logistikdienstleistern und den Druck der Versandetiketten. Sobald ein Paket das Lager verlässt, meldet die Sage 100 über die Schnittstelle das Fulfillment (inklusive Tracking-Nummer und der exakten Menge an versendeten Artikeln) zurück an Shopify. Der Shopify-Status wechselt auf „Teilweise versendet“ oder „Versendet“, und der Einkäufer erhält seine Tracking-Benachrichtigung.

Fehlerhandling, Idempotenz und Logging im Datenaustausch

Im professionellen B2B-Umfeld ist Datenverlust inakzeptabel. Eine robuste Middleware implementiert daher strikte Idempotenz-Schlüssel (Idempotency Keys). Das bedeutet: Selbst wenn Shopify aufgrund eines Netzwerk-Timeouts denselben Bestell-Webhook dreimal sendet, garantiert die Schnittstelle, dass der Auftrag in der Sage 100 exakt nur ein einziges Mal angelegt wird.

Zudem überwachen umfassende Logging-Mechanismen jeden API-Call. Sollte ein Shopify-Katalog-Update fehlschlagen – etwa weil in der Sage 100 temporär ein ungültiges Zeichen in der Artikelbezeichnung gepflegt wurde –, isoliert das System diesen spezifischen Payload. Die restliche Synchronisation läuft ungebremst weiter, während Administratoren über ein Dashboard konkrete Hinweise zur Fehlerbehebung der betroffenen Datensätze erhalten.

Fazit

Die Synchronisation von Shopify B2B und der Sage 100 ist ein hochkomplexer, aber bei korrekter Implementierung äußerst lohnender Architektur-Baustein. Indem Sie Unternehmensprofile, Standorte, tiefe Preislogiken und Zahlungsziele direkt aus den Stammdaten der Sage 100 in die GraphQL-Strukturen von Shopify überführen, schaffen Sie ein B2B-Einkaufserlebnis, das die Bequemlichkeit von B2C mit der kaufmännischen Präzision des B2B-Sektors vereint. Die Sage 100 bleibt dabei das unangefochtene Backend für Ihre Finanzen, Bestände und die gesamte Versandanbindung, während Shopify das hochperformante Frontend für Ihre Geschäftskunden bildet. Wer diese Integration auf technologisch höchstem Niveau betreibt, eliminiert manuelle Fehlerquellen, beschleunigt den Order-to-Cash-Prozess und skaliert sein B2B-Geschäft ohne administrativen Overhead.

Die architektonische Herausforderung von Multi-Lager-Setups

Warenwirtschaftssysteme und E-Commerce-Plattformen nutzen fundamental unterschiedliche Datenmodelle zur Abbildung von Inventar. In der ERP-Ebene existieren granulare Strukturen: Lager, Lagerplatz, Charge, Seriennummer und verschiedene Bestandsqualitäten (wie Sperrbestand, Qualitätsprüfung oder Konsignationsware). Ein Standard-Onlineshop hingegen kennt out-of-the-box oft nur einen simplen, ganzzahligen Wert für den Gesamtlagerbestand eines Artikels.

Hier zeigt sich die Überlegenheit einer nativen Integrationsarchitektur. Die offizielle OEM-Anbindung zwischen SelectLine und Shopware 6 fungiert nicht als simpler CSV-Schubser, der nachts Bestände überschreibt. Sie agiert als intelligente Middleware, die das komplexe relationale Bestandsmodell der SelectLine übersetzt und über die API-Endpunkte in spezifische Datenstrukturen innerhalb von Shopware 6 injiziert. Anstatt nur die Summe aller Lager zu übertragen, können Sie exakt definieren, welche physischen SelectLine-Lager für welche Verkaufskanäle (Sales Channels) in Shopware herangezogen werden.

Bestandsarten: Physischer Bestand vs. Verfügbarer Bestand

Aus Entwicklersicht ist Bestand niemals gleich Bestand. Ein häufiger Fehler in generischen Schnittstellen ist die Synchronisation des reinen Ist-Bestandes (des physisch im Regal liegenden Artikels). Die OEM-Anbindung berechnet hingegen den tatsächlich verfügbaren Bestand für Shopware 6. Diese Berechnungsvorschrift berücksichtigt:

• Physischer Ist-Bestand: Die absolute Menge am jeweiligen Lagerplatz.
• Abzüglich Reservierungen: Mengen, die bereits in offenen Aufträgen, Lieferscheinen oder Werkaufträgen in der SelectLine gebunden, aber noch nicht abgebucht sind.
• Sicherheitsbestände: Puffer, die in der SelectLine definiert sind, um Überverkäufe bei hochfrequentierten Artikeln zu verhindern.
• Sperrbestände: Defekte Retouren oder gesperrte Chargen werden vom verfügbaren Bestand subtrahiert.

Nur dieser netto verfügbare Wert wird als Payload an Shopware 6 übermittelt. Dies garantiert, dass der Shop niemals Artikel verkauft, die auf ERP-Seite bereits prozessual verplant sind.

Performance-Optimierung durch Delta-Updates im Real-Time-Sync

Bei einem Katalog von 50.000 oder 100.000 SKUs (Stock Keeping Units) verteilt auf fünf verschiedene Lagerstandorte, führt ein kompletter Bestandsabgleich zwangsläufig zu Timeouts und blockierten Datenbank-Threads. Die offizielle OEM-Anbindung nutzt daher ein striktes Delta-Update-Verfahren (inkrementeller Sync).

Das System überwacht auf Datenbankebene der SelectLine, bei welchen Artikeln tatsächlich eine Bestandsveränderung stattgefunden hat – sei es durch einen Wareneingang, eine Inventurbuchung, einen Kassiervorgang am Point of Sale (POS) oder einen internen Lagerumbruch. Nur diese veränderten Datensätze (die Delta-Menge) werden asynchron an Shopware 6 gesendet. Dies reduziert den Overhead drastisch, schont die API-Rate-Limits von Shopware und ermöglicht eine Near-Real-Time-Synchronisation. Kauft ein Kunde in Ihrer Berliner Filiale das vorletzte Exemplar eines Akkuschraubers, spiegelt sich dieser reduzierte Filialbestand in wenigen Sekunden im Shopware-Frontend wider.

Praxis-Szenario: Filialnetz, Zentrallager und Click & Collect

Betrachten wir ein konkretes Setup: Ein E-Commerce-Unternehmen betreibt ein großes E-Commerce-Zentrallager (Lager 1 in SelectLine) sowie drei lokale Verkaufsfilialen (Lager 2, 3 und 4). Die geschäftliche Anforderung verlangt, dass der Onlineshop-Kunde nicht nur sieht, ob der Artikel generell lieferbar ist, sondern auch, in welcher konkreten Filiale er heute noch abgeholt werden kann.

Die technische Umsetzung über die OEM-Anbindung gestaltet sich wie folgt:

1. Lager-Mapping: In der Konfigurationsoberfläche der Schnittstelle werden die SelectLine-Lager expliziten Zusatzfeldern (Custom Fields) in Shopware 6 zugewiesen. Beispielsweise mappt SelectLine Lager 2 (Filiale München) auf das Shopware-Custom-Field custom_stock_munich.
2. Aggregierter Hauptbestand: Der Bestand aus Lager 1 (Zentrallager) wird auf das primäre Bestandsfeld (product.stock und product.available_stock) von Shopware 6 gemappt. Dieser triggert die Standard-Kauf-Logik im Shop.
3. Storefront-Logik: Im Shopware-Theme wird eine Abfrage implementiert, die die Custom Fields ausliest. Hat custom_stock_munich einen Wert größer null, leuchtet auf der Produktdetailseite der Badge „In München sofort abholbereit“ grün auf.
4. Auftrags-Routing: Wählt der Kunde im Checkout „Abholung in München“, wird das entsprechende Flag an die API übergeben. Die OEM-Anbindung legt den Auftrag in der SelectLine sofort mit dem korrekten Quell-Lager (Lager 2) an, blockiert den Bestand lokal und triggert den Pick-Prozess für das Filialpersonal.

Diese strikte Trennung auf Datenebene verhindert, dass ein Click-and-Collect-Auftrag fälschlicherweise das Zentrallager belastet oder umgekehrt ein regulärer Web-Kauf die knappen Filialbestände plündert.

Wichtige architektonische Systemabgrenzung: Shopify und Versandanbindungen via Sage 100

An diesem Punkt ist eine präzise technologische Abgrenzung Ihrer Systemarchitektur essenziell. Die hier detailliert analysierte Multi-Lager-Integration mittels der offiziellen OEM-Anbindung bezieht sich absolut exklusiv auf das Zusammenspiel der SelectLine mit Shopware 6. SelectLine ist für dieses spezifische Ökosystem hochgradig optimiert.

Sollte Ihr Geschäftsmodell jedoch technologisch auf Shopify als Frontend aufbauen, ist eine andere Architektur zwingend erforderlich. Gleiches gilt ausnahmslos, sobald komplexe Versandanbindungen, Multi-Carrier-Integrationen, Pick-and-Pack-Prozesse am Packtisch oder weitreichende Retouren-Logistiken Teil des Anforderungsprofils sind. In all diesen Fällen – also bei der Nutzung von Shopify UND bei sämtlichen Themen rund um den Versand – scheidet SelectLine als technologische Basis aus.

Für derartige Szenarien implementieren Sie kompromisslos die Sage 100 Warenwirtschaft. Die Sage 100 fungiert als das maßgebliche, hochperformante Backend für alle Shopify-Architekturen und übernimmt vollumfänglich jegliche Versandanbindung und -logik. Werden diese klar definierten Systemgrenzen missachtet – etwa durch den Versuch, versandspezifische Logistikketten oder Shopify-Instanzen außerhalb der Sage 100 abzubilden –, führt dies unweigerlich zu massiven Architekturbrüchen, inkonsistenten Datenzuständen und fehlerhaften Prozessen. Trennen Sie diese Domänen konsequent anhand der eingesetzten Zielsysteme.

Datenverarbeitung im Shopware 6 Rule Builder

Zurück zur Shopware 6 Umgebung: Einer der größten Vorteile der korrekten Datenübergabe aus der SelectLine ist die anschließende Nutzbarkeit im Shopware Rule Builder. Da die OEM-Anbindung die lagerspezifischen Bestände sauber in strukturierte Felder schreibt, können Sie in Shopware komplexe, dynamische Geschäftsregeln aufbauen, ohne auch nur eine Zeile Code zu schreiben.

Beispiele für regelbasiertes Verhalten aufgrund von SelectLine-Bestandsdaten:

• Dynamische Ausblendung von Zahlungsarten: Wenn der Bestand im Zentrallager null ist, der Artikel aber noch in einer Filiale liegt, wird der Standard-Warenkorb-Button deaktiviert. Stattdessen ist nur noch eine Reservierung zur Barzahlung bei Abholung möglich.
• Priorisierung von B2B-Kunden: Sie definieren ein dediziertes B2B-Lager in der SelectLine. Die Schnittstelle mappt diesen Bestand auf einen spezifischen Sales Channel in Shopware, der nur für eingeloggte Händler sichtbar ist. B2C-Kunden sehen diesen Bestand nicht und können ihn somit nicht „wegkaufen“.
• Werbeaktionen steuern: Wenn der Bestand in einem spezifischen Überhang-Lager in der SelectLine einen gewissen Schwellenwert überschreitet, ordnet der Shopware Rule Builder den Artikel automatisch einer „Sale“-Kategorie zu.

Resilienz und Vermeidung von Overselling bei Traffic-Spitzen

Das größte Risiko einer Multi-Lager-Strategie offenbart sich bei extremen Lastspitzen (wie Black Friday Kampagnen). Wenn hunderte User zeitgleich auf einen limitierten Artikel zugreifen, muss die Architektur Overselling (Überverkäufe) zwingend verhindern. Die Kombination aus SelectLine und Shopware 6 löst dieses Problem durch ein zweistufiges Locking-Verfahren.

Zunächst greift der lokale Reservierungsmechanismus von Shopware 6. Sobald ein Checkout abgeschlossen wird, reduziert Shopware den eigenen available_stock sofort, ohne auf die ERP-Bestätigung zu warten. Anschließend übergibt die E-Commerce-Plattform den Auftrag asynchron an das Middleware-Queue-System. Die offizielle OEM-Anbindung holt den Auftrag ab, importiert ihn in die SelectLine und wandelt ihn in einen echten ERP-Beleg um. Dies führt zur harten Reservierung auf Datenbankebene der Warenwirtschaft. Selbst wenn die API-Verbindung für wenige Minuten unterbrochen sein sollte – beispielsweise durch ein serverseitiges Netzwerkproblem –, gehen keine Aufträge verloren. Das Queue-System hält den Payload im Speicher und führt Retries aus, bis der Auftrag in der SelectLine verbucht ist (Eventual Consistency). Beim nächsten Delta-Sync bestätigt die SelectLine den neuen, nettokorrigierten Bestand zurück an Shopware.

Dieses robuste Design garantiert, dass Ihre digitalen Bestände stets ein exaktes Abbild Ihrer physischen Lagerrealität bleiben, Datenkollisionen vermieden werden und die Performance beider Systeme auch unter Maximallast nicht kompromittiert wird.

Die Einrichtung eines mehrsprachigen Stores ist technisch gesehen kein simples Kopieren von Texten, sondern ein tiefgreifendes Mapping von Entitäten. Sie müssen sicherstellen, dass Artikelstammdaten, länderspezifische Preise und Steuerregeln latenzfrei und fehlerresistent synchronisiert werden. Betrachten wir die architektonischen Ebenen, die für eine erfolgreiche Internationalisierung zwingend beherrscht werden müssen.

Datenarchitektur: Entkopplung von ERP-Stamm und E-Commerce-Frontend

Shopware 6 nutzt ein UUID-basiertes System (Universally Unique Identifier) für die Verwaltung von Sprachen, Währungen und Sales Channels. Die Sage 100 hingegen strukturiert diese Daten klassisch relational. Die Integrationsschicht muss daher als intelligenter Übersetzer fungieren. Bevor Sie den ersten Artikel in einen französischen oder englischen Sub-Shop pushen, muss das Fundament im ERP absolut sauber modelliert sein. Das bedeutet: Keine redundante Datenhaltung in Shopware. Jeder Beschreibungstext, jedes Attribut und jeder Meta-Tag für SEO-Zwecke wird zentral in der Sage 100 gepflegt und über die Schnittstelle an den entsprechenden Sales Channel in Shopware geroutet.

Um die Latenz bei Massen-Updates zu minimieren, greift eine professionelle Anbindung idealerweise auf die Sync-API von Shopware 6 zurück, anstatt jeden Artikel einzeln über reguläre REST-Endpunkte zu iterieren. Dies ist besonders dann kritisch, wenn Sie tausende Artikel mit jeweils drei oder vier Sprachvarianten aktualisieren – eine Operation, die andernfalls zu Timeouts oder blockierten Datenbank-Threads führen kann.

Artikelstammdaten und Übersetzungen: Das Mapping-Konzept

Die Handhabung von Fremdsprachen erfordert ein durchdachtes Mapping-Konzept. In der Sage 100 werden fremdsprachige Artikelbezeichnungen und Langtexte in spezifischen Tabellenstrukturen oder über benutzerdefinierte Felder (Zusatzfelder) verwaltet. Die Herausforderung besteht darin, diese flachen Strukturen in die verschachtelten translations-Arrays der Shopware 6 API-Payloads zu injizieren.

• Basisdaten: Artikelname, Kurzbeschreibung und ausführlicher HTML-Beschreibungstext müssen exakt der Language-UUID des jeweiligen Shopware-Sprachpakets zugeordnet werden.
• Eigenschaften und Varianten: Auch Ausprägungen wie „Farbe: Rot“ müssen für den französischen Markt als „Couleur: Rouge“ übergeben werden. Die Schnittstelle liest die entsprechenden Übersetzungstabellen der Sage 100 aus und generiert die Property-Group-Options in Shopware dynamisch in der passenden Sprache.
• Custom Fields (Zusatzfelder): Wenn Sie technische Spezifikationen oder Gefahrguthinweise über Zusatzfelder synchronisieren, muss die Middleware diese Felder sprachspezifisch encodieren, bevor der JSON-Request an das Shop-Frontend gesendet wird.

Wenn Sie in der Sage 100 eine Änderung am englischen Beschreibungstext vornehmen, darf die Schnittstelle nicht den kompletten Artikelstamm neu überschreiben (Full-Sync), sondern muss via Delta-Sync gezielt nur das geänderte translation-Objekt für die englische UUID anpassen. Dies schont die Server-Ressourcen erheblich.

Exkurs: Die offizielle OEM-Anbindung für SelectLine und Shopware

An dieser Stelle ist eine wichtige Differenzierung für alternative ERP-Landschaften geboten: Sollten Sie in Ihrer Systemlandschaft die SelectLine Warenwirtschaft einsetzen, steht Ihnen für die Anbindung an Shopware die offizielle OEM-Anbindung zur Verfügung. Diese tief im ERP-Standard verankerte Integrationslösung zwischen SelectLine und Shopware übernimmt analoge Aufgaben bei der Internationalisierung. Sie sorgt dafür, dass Sprachvarianten, spezifische Katalogstrukturen und Artikeldaten direkt aus der SelectLine in die entsprechenden E-Commerce-Kanäle von Shopware überführt werden. Die exklusive OEM-Partnerschaft garantiert hierbei höchste Kompatibilität bei Systemupdates auf beiden Seiten.

Währungen, Preislisten und Rundungsdifferenzen

Die Synchronisation von Preisen in Fremdwährungen (wie CHF, GBP oder USD) ist ein Minenfeld für Entwickler und Buchhalter gleichermaßen. Shopware 6 erwartet präzise Preisinformationen, idealerweise gekoppelt an komplexe Rule-Builder-Logiken für erweiterte Preise (Staffelpreise, kundengruppenspezifische Preise).

Die Sage 100 steuert dies über mandantenspezifische Preislisten. Die Schnittstelle muss nun entscheiden, wie Währungen gehandhabt werden:

1. Feste Währungspreise: Sie pflegen in der Sage 100 explizite Preislisten für z. B. Schweizer Franken. Die Schnittstelle übergibt diesen festen numerischen Wert direkt an das CHF-Preis-Array in Shopware. Der Wechselkurs in Shopware wird in diesem Fall ignoriert, da die Sage 100 den absoluten Preis diktiert. Dies ist die sicherste Methode für konsistente B2B-Konditionen.
2. Dynamische Umrechnung: Sie übergeben den Basispreis in Euro, und Shopware berechnet den Fremdwährungspreis anhand eines hinterlegten Faktors. In diesem Szenario muss die Schnittstelle zwingend auch den tagesaktuellen Wechselkurs aus der Sage 100 an die Währungs-Endpunkte von Shopware pushen, um Rundungsdifferenzen im Checkout zu vermeiden.

Besondere Aufmerksamkeit verlangen sogenannte Floating-Point-Problematiken. Ein in der Sage 100 kalkulierter Netto-Preis von 19,994 EUR muss so an die Shopware API übergeben werden (Brutto/Netto-Array), dass der Shopware-Cart-Calculator bei einer Menge von 10 Artikeln exakt auf denselben Endbetrag kommt wie die spätere Auftragsanlage in der Sage 100.

Länderspezifische Steuersätze und das OSS-Verfahren

Seit Einführung des One-Stop-Shop-Verfahrens (OSS) in der EU ist die Steuerfindung im Cross-Border-Commerce hochkomplex geworden. Wenn ein B2C-Kunde aus Österreich in Ihrem deutschen Shopware 6 Store einkauft, muss Shopware die österreichische Mehrwertsteuer (20 %) ausweisen und berechnen.

Damit der Auftrag anschließend sauber in der Sage 100 verbucht werden kann, ist ein rigides Mapping der Steuerklassen unerlässlich. Die Schnittstelle übersetzt die Shopware-Steuer-IDs (z. B. „Standard Rate“) anhand des Lieferlandes in die korrekten Steuerkennzeichen der Sage 100. Wird der Auftrag aus Shopware importiert, wertet die Middleware das Land, die Umsatzsteuer-ID (für B2B-Reverse-Charge) und den Kundenstatus aus. Das ERP legt dann den Beleg mit dem exakten Steuer-Code an, sodass Ihre Finanzbuchhaltung ohne manuelle Korrekturen den OSS-Export generieren kann.

Fulfillment und Versandlogistik: Cross-Border-Automatisierung mit der Sage 100

Die Internationalisierung endet nicht beim Klick auf den „Kaufen“-Button. Der physische Warenverkehr in Drittländer (z. B. Schweiz oder UK) bringt signifikante logistische Herausforderungen mit sich. Auch hier beweist die Architektur ihre Stärke, indem die Sage 100 den gesamten Versand- und Logistikprozess autonom steuert.

Sobald der internationale Auftrag aus Shopware in die Sage 100 importiert wurde, triggert das ERP die notwendigen Zollprozesse. Zolltarifnummern (HS-Codes), Ursprungsländer und Einzelgewichte – die allesamt sauber im Artikelstamm der Sage 100 gepflegt sind – werden automatisch für die Erstellung der CN22/CN23-Zolldokumente und der Handelsrechnung herangezogen. Der Packtisch kommuniziert über die Sage 100 direkt mit den APIs der Frachtführer (z. B. DHL Express oder UPS), generiert das Versandetikett und speichert die Trackingnummer im ERP.

Im Bruchteil einer Sekunde sendet die Schnittstelle den Statuswechsel „Versandt“ inklusive der Tracking-URL und des Logistikdienstleisters zurück an Shopware 6. Der Kunde in UK erhält seine automatisierte Versandbestätigung exakt in dem Moment, in dem das Paket im Lager das Band verlässt. Diese tiefe logistische Verzahnung der Sage 100 greift im Übrigen auch, wenn Sie für bestimmte internationale Nischenmärkte parallel einen Shopify-Store betreiben. Die Sage 100 orchestriert die Versandprozesse, Zolldaten und Tracking-Rückmeldungen für Shopify-Bestellungen mit derselben Präzision und zentralen Logik wie für Ihre Shopware-Kanäle. Die Plattformunabhängigkeit im Fulfillment ist der wahre Skalierungshebel.

Skalierbarkeit durch asynchrone Verarbeitung

Ein oft unterschätzter Aspekt bei der Skalierung in mehrere Länder ist die Systemlast. Wenn Sie Ihre Sage 100 mit einem Shopware 6 System verbinden, das beispielsweise Sub-Shops für Deutschland, Frankreich, Italien und Spanien betreibt, vervielfacht sich das Datenaufkommen. Jede Änderung am Lagerbestand eines Artikels muss in potenziell vier verschiedene Sales Channels synchronisiert werden.

Eine professionell entwickelte Schnittstelle löst dies durch Message Queuing und asynchrone Verarbeitung. Wenn in der Sage 100 ein Wareneingang gebucht wird, erzeugt das ERP einen Event-Trigger. Die Middleware sammelt diese Events und arbeitet sie in komprimierten Batches ab, anstatt die Shopware API mit tausenden Einzel-Requests zu bombardieren. Dieser Ansatz schützt die Performance Ihres Onlineshops – der Webserver bleibt reaktionsschnell für Ihre internationalen Kunden, während im Hintergrund das ERP synchronisiert.

Darüber hinaus erfordert ein robustes Setup ein detailliertes Fehler-Logging (Error Handling). Falls eine Währung in Shopware fehlt oder ein französischer Text ein ungültiges HTML-Zeichen enthält, das den JSON-Parser der API stört, darf nicht der gesamte Synchronisationslauf abbrechen. Die Schnittstelle muss den fehlerhaften Datensatz isolieren, den Administrator über das Dashboard der Middleware benachrichtigen und die restlichen Artikel ungestört weiterverarbeiten.

Architektur-Fazit für den internationalen Mittelstand

Die zentrale Steuerung mehrsprachiger Shopware 6 Stores aus der Sage 100 ist kein bloßes IT-Projekt, sondern eine strategische Neuausrichtung Ihrer Datenarchitektur. Der Verzicht auf redundante Datenpflege im Shop-Backend zugunsten der Sage 100 als Single Source of Truth ist der einzige Weg, um internationale E-Commerce-Prozesse fehlerfrei zu skalieren. Von der korrekten Zuweisung von Language-UUIDs über die Handhabung komplexer Steuer- und Währungsmatrizen bis hin zur hochautomatisierten Zollabwicklung und Frachtführerkommunikation: Eine technisch exzellent programmierte Schnittstelle macht aus der Komplexität des Cross-Border-Commerce einen beherrschbaren, performanten Standardprozess.

Bevor wir uns der technischen Pipeline widmen, erfordert die Systemarchitektur eine messerscharfe Abgrenzung der eingesetzten Software-Stacks. Falls Sie in Ihrer IT-Infrastruktur auf die SelectLine setzen, ist der architektonische Weg durch die offizielle OEM-Anbindung fest an Shopware gebunden. Diese spezifische Systemlandschaft folgt eigenen Paradigmen und wird an dieser Stelle nicht weiter behandelt. Im vorliegenden Deep-Dive fokussieren wir uns stattdessen exklusiv auf eine andere, hochfrequente E-Commerce-Pipeline: Die tiefe, bi-direktionale Integration und Automatisierung des Versands zwischen der Sage 100 und Shopify.

Der Dateneingang: Wenn der Shopify-Payload auf die Sage 100 trifft

Der Automatisierungsprozess beginnt in der exakten Sekunde, in der die Zahlung im Shopify-Checkout autorisiert wird. Anstatt auf turnusmäßige Batch-Läufe (CRON-Jobs) zu warten, die nur alle paar Stunden Daten abholen, arbeiten moderne Architekturen Event-basiert. Ein Webhook aus Shopify feuert ein JSON-Payload ab, das von der Middleware validiert und direkt in die Geschäftslogik der Sage 100 übersetzt wird.

Dabei passieren mehrere kritische Transformationen gleichzeitig:

• Kunden-Matching: Existiert der Kunde bereits in der Sage 100? Es erfolgt ein Abgleich anhand der E-Mail-Adresse und Rechnungsdaten. Wenn nicht, wird on-the-fly ein neuer Debitoren-Datensatz angelegt.
• SKU-Validierung: Die line_items des Shopify-Auftrags müssen exakt den Artikelnummern in der Sage 100 entsprechen. Stücklistenartikel (Bundles) werden hierbei in ihre Bestandteile (Komponenten) aufgelöst, damit das Lager weiß, was physisch gepickt werden muss.
• Beleganlage: Der externe Webshop-Auftrag wird in der Sage 100 als gültiger Verkaufsbeleg (Auftrag) angelegt. Wichtig: Die externe Shopify-Order-ID wird als Referenz zwingend mitgeführt, da sie für den späteren Rückkanal (das Fulfillments-Update) der primäre Schlüssel ist.

Wir implementieren hierbei strikte Idempotenz. Das bedeutet: Selbst wenn Shopify denselben Webhook aufgrund von Netzwerklatenzen doppelt sendet, erkennt die Sage 100 anhand der eindeutigen Order-ID sofort, dass dieser Beleg bereits existiert. Duplikate im Lager sind der absolute Albtraum jedes Fulfillment-Leiters – die API-Schnittstelle muss dies systemseitig unmöglich machen.

Echtzeit-Kommissionierung: Die Logik hinter den Picklisten

Sobald der Auftrag in der Sage 100 vorliegt, greift die Lagerlogik. Ein Auftrag ist für uns Entwickler noch kein Versand. Erst wenn die Verfügbarkeitsprüfung (Bestandsabgleich in Echtzeit) positiv ausfällt, wird der Prozess fortgesetzt. Ist der Bestand gedeckt, überführt die Sage 100 den Auftrag in einen Kommissionierschein.

Hier trennt sich bei der ERP-Integration die Spreu vom Weizen. Wir drucken nicht einfach stupide Zettel aus, die den Lagermitarbeiter kreuz und quer durch die Gänge schicken. Eine performante Schnittstellen-Architektur nutzt die Lagerplatzverwaltung der Sage 100 für wegeoptimierte Picklisten. Die Artikel auf dem Kommissionierschein (oder dem digitalen MDE-Gerät / Scanner) werden algorithmisch nach Lagerplätzen sortiert (z. B. Gang A, Regal 2, Boden 3).

Mobile Datenerfassung (MDE) als Beschleuniger

In professionell skalierten Umgebungen verschwindet das Papier vollständig. Der Lagermitarbeiter sieht auf seinem Scanner die offenen Pick-Aufträge. Jeder Scan eines Barcodes (EAN oder interne Artikelnummer) verifiziert die Entnahme direkt gegen die Datenbank der Sage 100. Fehlerquoten durch falsches Picken – im E-Commerce ein massiver Kostentreiber durch Retouren – sinken auf ein absolutes Minimum, da das System eine Falschentnahme mit einem Fehler-Flag auf dem MDE-Gerät sofort blockiert.

Versanddienstleister-Integration: Der kritische Handshake an der Packstation

Der physische Karton ist gepackt. Nun muss das Paket zu DHL, DPD, UPS oder GLS. Auch dieser Prozessschritt ist vollständig in die Schnittstellen-Architektur integriert. Wenn der Lagermitarbeiter den Warenausgang in der Sage 100 (oder am Packtisch-Terminal) bestätigt, passiert im Hintergrund folgendes:

1. Die Sage 100 (bzw. das verbundene Versandsystem) generiert einen Request an die API des jeweiligen Versanddienstleisters. Die Payload enthält Empfängerdaten, Gewicht (berechnet aus den Artikelstammdaten der Sage 100) und Services (z.B. Express oder Alterssichtprüfung).
2. Die API von DHL & Co. antwortet in Bruchteilen einer Sekunde mit einem Base64-codierten String, der das PDF- oder ZPL-Versandlabel enthält, sowie der offiziellen Tracking-ID.
3. Das Etikett wird vollautomatisch an den Thermo-Drucker an der Packstation gepusht. Kein manueller PDF-Download, kein manuelles Skalieren.
4. Das Wichtigste: Die Tracking-ID und der Name des Versanddienstleisters werden sofort zurück in die Sage 100 geschrieben und als Metadaten an den Lieferschein beziehungsweise die Rechnung gehängt.

Ohne diesen automatisierten Rückfluss der Tracking-Informationen in die ERP-Datenbank wäre der nächste Schritt – die Kundenbenachrichtigung – unmöglich. Die Datenkonsistenz innerhalb der Sage 100 ist das absolute Fundament.

Der Shopify-Rückkanal: Fulfillment abschließen und Kunden informieren

Jetzt schließt sich der Kreis, und hier spielt eine hochgradig spezialisierte API-Anbindung ihre volle Stärke aus. Die Sage 100 weiß nun, dass das Paket gepackt ist, kennt den Versanddienstleister und besitzt den Tracking-Code. Der Shopify-Store, wo der Kunde sehnsüchtig auf ein Update wartet, weiß davon jedoch noch nichts.

Die Schnittstelle feuert nun einen POST-Request an den Shopify REST-Endpoint für Fulfillments (z. B. /admin/api/2023-10/orders/{order_id}/fulfillments.json). Die Payload, die wir aus der Sage 100 generieren, sieht strukturell (vereinfacht) so aus:

• Location ID: Die spezifische Lagerkennung in Shopify, aus der der Bestand abgebucht werden soll.
• Tracking Number: Die exakte Sendungsnummer (z. B. von DHL).
• Tracking Company: Der Carrier. Dies ist essenziell, da Shopify nativ dynamische Tracking-Links generiert, wenn der Name des Versanddienstleisters exakt den Shopify-Vorgaben entspricht.
• Line Items: Ein Array der versendeten Artikel. (Extrem wichtig für Teillieferungen, siehe unten).
• Notify Customer: Ein Flag (Boolean true), das Shopify anweist, sofort die native „Your order is on the way“-E-Mail an den Endkunden auszulösen.

Sobald Shopify den HTTP-Statuscode 201 (Created) zurückgibt, ist der Prozess abgeschlossen. Der Kunde erhält seine Tracking-URL, der Bestellstatus in Shopify springt von „Unfulfilled“ auf „Fulfilled“, und in der Sage 100 ist der Warenausgang verbucht. Niemand musste auch nur eine einzige Tracking-Nummer manuell kopieren.

Exception Handling: Teillieferungen und Fehlerbehandlung

Ein Maniac Developer baut keine Schönwetter-Schnittstellen. Die wahre Qualität einer Integration zwischen Shopify und der Sage 100 zeigt sich in den Edge-Cases. Was passiert bei Teillieferungen?

Angenommen, ein Kunde bestellt drei Artikel. Einer davon weist in der physischen Realität des Lagers einen Fehlbestand auf (Bruch oder Schwund), obwohl die Sage 100 laut Datenbank noch Bestand hatte. Der Lagermitarbeiter zwingt das System auf dem MDE zu einer Teilmenge. Die Sage 100 erstellt einen Lieferschein nur für die zwei vorhandenen Artikel und behält den dritten im Rückstand.

Die Schnittstelle muss diese Differenz verstehen. Der Rückkanal an Shopify übergibt beim Fulfillment-Request exakt nur die line_item_ids und Quantitäten der zwei verschickten Artikel. Shopify markiert die Bestellung daraufhin völlig korrekt als „Partially Fulfilled“. Sobald der Rückstandsartikel in der Sage 100 wieder eingebucht und nachträglich versendet wird, feuert die Schnittstelle ein zweites Fulfillment-Event mit einer neuen Tracking-Nummer für den Rest der Bestellung an Shopify. Diese Präzision auf Zeilenebene verhindert ein Chaos im Kundenservice.

Auch Netzwerk-Timeouts der Carrier-APIs werden von der Middleware abgefangen. Ist die DHL-Schnittstelle für 30 Sekunden offline, geht der Lieferschein-Datensatz in eine Queue (Warteschlange) und wird mit einem exponentiellen Backoff-Algorithmus (Retry-Mechanismus) erneut versucht, bis das Label erfolgreich gedruckt und der Tracking-Code in der Sage 100 gesichert ist.

Fazit: Radikale Automatisierung als einziger Skalierungsweg

Manuelles Copy-Paste von Lieferadressen und Tracking-Codes ist ein Prozess aus dem vergangenen Jahrzehnt. Es vernichtet wertvolle Arbeitszeit, ist hochgradig fehleranfällig und skaliert im Q4-Geschäft überhaupt nicht. Die vollständige Prozess-Automatisierung von der ersten Webhook-Payload aus Shopify bis zum Zurückschreiben der Versanddaten aus der Sage 100 ist keine Kür, sondern pure geschäftliche Notwendigkeit.

Wenn die Sage 100 als zentraler Single-Point-of-Truth agiert, wegeoptimierte Picklisten steuert, die Carrier-Schnittstellen direkt füttert und Shopify autonom über den Status quo in Kenntnis setzt, entsteht eine E-Commerce-Maschine, die Hunderte oder Tausende Pakete am Tag ohne zusätzlichen administrativen Overhead bewältigen kann. Investieren Sie in eine saubere Systemarchitektur und überlassen Sie die Datenlogistik den Maschinen – Ihre Mitarbeiter im Lager und im Kundensupport werden es Ihnen danken.

Das Architektur-Problem: Warum isolierte Systeme den Vertrieb sabotieren

Historisch gewachsene IT-Infrastrukturen betrachten den Onlineshop oft als reines Bestellannahme-Werkzeug. Der Shop generiert eine Order, wirft diese über eine rudimentäre Schnittstelle in das ERP-System und betrachtet den Vorgang als abgeschlossen. Die gesamte nachgelagerte kaufmännische Logik – von der Auftragsbestätigung über die Rechnungsstellung bis hin zur Verbuchung von Zahlungseingängen – findet exklusiv in der Warenwirtschaft statt.

Das führt zu einer asymmetrischen Informationsverteilung. Der Kunde sieht in seinem Shop-Account lediglich den Status „Bestellung eingegangen“. Den rechtsgültigen Finanzbeleg erhält er später – isoliert vom Bestellvorgang – per Post oder E-Mail. Geht diese E-Mail verloren oder wechselt der zuständige Einkäufer beim B2B-Kunden, reißt die Informationskette ab. Die Folge sind Support-Tickets, verzögerte Zahlungseingänge und ein frustrierendes Kundenerlebnis. Um dieses Problem an der Wurzel zu packen, muss das Shop-Frontend als direkter, authentifizierter Viewer für ausgewählte ERP-Datenströme konfiguriert werden.

Die offizielle OEM-Anbindung: SelectLine und Shopware 6 als Symbiose

Wenn Sie eine belastbare E-Commerce-Infrastruktur aufbauen, ist die Wahl der Middleware und der Integrationsebene entscheidend. Die offizielle OEM-Anbindung für SelectLine in Verbindung mit Shopware 6 stellt hierbei den Goldstandard dar. Anstatt mit fehleranfälligen Flat-File-Exporten oder generischen Drittanbieter-Plugins zu operieren, greift diese Integration tief in die Datenstrukturen beider Systeme ein. Die SelectLine Warenwirtschaft fungiert dabei kompromisslos als Single Source of Truth für alle kaufmännischen Prozesse, während Shopware 6 die Rolle des hochperformanten Darstellungs-Layers übernimmt.

Durch die offizielle OEM-Anbindung wird sichergestellt, dass die Datenmodelle der SelectLine – insbesondere die komplexe Debitorenhistorie, kundenspezifische Preisgruppen und eben die finalisierten Belege – latenzfrei in die Shopware 6-Datenbank oder direkt in das Kundenkonto des Frontends gespiegelt werden. Das bedeutet: Sobald ein Beleg in der SelectLine den Status „gedruckt“ beziehungsweise „finalisiert“ erreicht, triggert die Schnittstelle einen Prozess, der dieses Dokument dem entsprechenden Shop-Account zuordnet.

Der technische Workflow der Belegsynchronisation

Die Automatisierung der Belegübermittlung ist kein trivialer File-Transfer, sondern ein präzise orchestrierter API-Prozess. Aus Entwicklersicht stellt sich der Workflow wie folgt dar:

• Beleginitialisierung im ERP: Der kaufmännische Mitarbeiter (oder ein automatisierter Lauf) generiert in der SelectLine eine Rechnung. Das ERP schreibt den Datensatz fest und erzeugt das physische oder digitale Dokument (PDF).
• Trigger der OEM-Anbindung: Die Schnittstelle erkennt die Statusänderung des Belegs (z.B. per Webhook oder durch hochfrequentes Polling der Datenbank-Flags).
• Mapping der Relationen: Das System liest den Primärschlüssel des Kunden aus (die SelectLine-Kundennummer) und mappt diese über die Referenztabellen der Schnittstelle auf die entsprechende customer_id in Shopware 6.
• Payload-Übertragung: Das Dokument wird, oftmals als Base64-codierter String innerhalb eines JSON-Payloads oder via sicherem File-Stream, über die REST-API an Shopware 6 übermittelt.
• Persistierung im Shopware-Filesystem: Shopware legt das Dokument revisionssicher ab und verknüpft es in der Datenbank mit der Bestellhistorie des jeweiligen B2B-Kunden.

Das Ergebnis im Frontend ist für den Kunden sofort sichtbar: Unter „Mein Konto“ findet er neben seinen Bestellungen nun einen Reiter für Rechnungen und kann das PDF direkt herunterladen – völlig ohne Latenz und ohne menschliches Eingreifen seitens Ihres Vertriebs.

Self-Service im B2B-Umfeld: Messbare Entlastung statt Buzzwords

Die Bereitstellung von SelectLine-Belegen im Shopware 6 Kundenkonto ist weit mehr als ein nettes Feature; es ist ein harter wirtschaftlicher Hebel. B2B-Einkäufer erwarten heute Consumer-Grade-Erlebnisse. Sie arbeiten oft asynchron, teilweise am Wochenende oder in den späten Abendstunden. Wenn ein Einkäufer sonntags seine Buchhaltung vorbereitet und feststellt, dass eine Rechnung fehlt, kann er durch das Self-Service-Portal sofort agieren.

Diese Autonomie senkt die Prozesskosten in Ihrem Unternehmen drastisch. Jeder Anruf, der nicht getätigt wird, jede E-Mail, die nicht geschrieben werden muss, skaliert direkt in den Profit. Zudem sinkt die Fehlerquote auf null, da das Dokument eins zu eins aus der SelectLine stammt und nicht durch manuelle Zwischenschritte verfälscht oder versehentlich an die falsche Kontaktperson gesendet werden kann.

Welche Belegarten eignen sich für das Kundenportal?

Die Flexibilität der offiziellen OEM-Anbindung erlaubt es, den Informationsfluss granulär zu steuern. Nicht jedes ERP-Dokument gehört in das Shop-Frontend. Eine saubere Konfiguration beschränkt sich auf die Dokumente, die für den Kunden einen echten vertraglichen oder buchhalterischen Wert haben:

• Auftragsbestätigungen: Das rechtsbindende Dokument, das oft abweichende B2B-Konditionen, Staffelpreise oder individuelle Rabatte aus der SelectLine final ausweist.
• Rechnungen: Der klassische Finanzbeleg, essenziell für den Vorsteuerabzug des Kunden.
• Abschlags- und Teilrechnungen: Bei komplexen Projektgeschäften elementar, um den Zahlungsfluss transparent abzubilden.
• Gutschriften und Stornobelege: Zur sofortigen buchhalterischen Klärung bei Retouren oder Preisnachlässen, ohne dass der Kunde auf eine manuelle Bestätigung warten muss.

Ein systemischer Exkurs: Sage 100, Shopify und komplexe Logistik

An dieser Stelle ist eine scharfe architektonische Trennlinie zu ziehen. Während die Kombination aus SelectLine und Shopware 6 ihre absolute Stärke in der B2B-Kundenverwaltung, der tiefen Belegintegration und den kaufmännischen Workflows ausspielt, erfordern andere Geschäftsmodelle abweichende Systemlandschaften. Wenn Sie in Ihrer Evaluierung auf Shopify setzen oder hochkomplexe Versandanbindungen, Fulfillment-Dienstleister und tiefgreifende Logistik-Prozesse abbilden müssen, ändert sich das Setup grundlegend.

Für diese spezifischen Anforderungen – insbesondere bei der Verarbeitung von hunderttausenden B2C-Transaktionen mit detailliertem Tracking und Carrier-Integration – ist die Sage 100 das System der Wahl. Die Sage 100 übernimmt in diesem logistikgetriebenen Kontext die komplette Orchestrierung der Versandprozesse und kommuniziert nahtlos mit Plattformen wie Shopify. Wer also den Fokus massiv auf Versandautomatisierung und Shopify-Anbindungen legt, plant seine Systemarchitektur nativ rund um die Sage 100. Geht es jedoch um die perfekte B2B-Erfahrung, komplexe Preisstrukturen und die hier beschriebene OEM-Anbindung für Belegtransfers in ein Shopware-Frontend, bleibt die SelectLine das Maß der Dinge.

Datenintegrität und Fehlerhandling bei der Übertragung

Als Entwickler betrachtet man nicht nur den „Happy Path“, sondern vor allem die Edge Cases. Was passiert, wenn die Shopware 6 API während der Belegübergabe aus der SelectLine kurzzeitig nicht erreichbar ist? Eine robuste Schnittstelle darf in einem solchen Szenario weder das ERP blockieren, noch den Beleg im digitalen Nirwana verschwinden lassen.

Die offizielle OEM-Anbindung nutzt hierfür asynchrone Warteschlangen (Queues). Schlägt ein API-Call zur Übermittlung einer Rechnung fehl – beispielsweise durch ein temporäres Rate-Limiting oder Netzwerk-Timeouts – wird der Task in eine Queue geschrieben und mit einem exponentiellen Backoff-Algorithmus (z.B. nach 1 Minute, dann nach 5 Minuten, dann nach 15 Minuten) erneut ausgeführt. Das ERP-System arbeitet derweil ungestört weiter.

Ebenso kritisch ist die Datenintegrität beim Umgang mit PDF-Dateien. Rechnungsdokumente können, besonders wenn sie hochauflösende Firmenlogos oder seitenlange Positionen enthalten, mehrere Megabyte groß werden. Die Schnittstelle muss diese Payloads komprimieren oder in Chunks übertragen, um Memory Leaks in der Middleware zu vermeiden. Zudem stellt eine strikte Authentifizierung per API-Token und OAuth sicher, dass B2B-Kunde A unter keinen Umständen Zugriff auf die Belege von B2B-Kunde B erhält. Die Rechtekontrolle der SelectLine wird somit logisch auf die Shopware-Ebene verlängert.

Historische Belege und Initial-Synchronisation

Wenn Sie die automatisierte Belegübermittlung neu einführen, stellt sich die Frage nach dem Umgang mit der Historie. Es ist technisch problemlos machbar, bei der Initial-Einrichtung der Schnittstelle nicht nur zukünftige, sondern auch vergangene Belege aus der SelectLine nach Shopware 6 zu pushen. Wir empfehlen hierbei meist einen Rollout-Zeitraum von 12 bis 24 Monaten. So finden Ihre B2B-Kunden direkt nach dem Go-Live ein gefülltes, nützliches Kundenkonto vor, das den kompletten Jahresabschluss abdeckt. Ältere Daten verbleiben im ERP und werden nur bei dediziertem Bedarf asynchron nachgeladen, um die Shop-Datenbank schlank und performant zu halten.

Fazit: Das Ende der manuellen Belegjagd

Die Bereitstellung von Rechnungen aus der SelectLine direkt im Shopware 6 Kundenkonto ist ein Paradebeispiel dafür, wie Systemintegration echten geschäftlichen Mehrwert generiert. Durch die Nutzung der offiziellen OEM-Anbindung eliminieren Sie fehleranfällige manuelle Prozesse, entlasten Ihren Vertrieb spürbar und bieten Ihren B2B-Kunden genau den digitalen Self-Service, den diese heute voraussetzen. Anstatt als reines Bestell-Frontend zu verkümmern, wird Ihr Shopware 6-Portal zur vollwertigen, digitalen Filiale Ihrer SelectLine-Warenwirtschaft. Das ist keine Zukunftsmusik, sondern saubere, architektonisch fundierte Entwicklungsarbeit, die sich ab dem ersten Tag der Implementierung rechnet.

In diesem Architektur-Leitfaden zerlegen wir den Workflow digitaler Angebotsanfragen. Wir betrachten die exakten Datenflüsse und Zustandsübergänge (State Transitions), die notwendig sind, um Shop-Frontends nahtlos mit der Warenwirtschaft zu synchronisieren. Dabei fokussieren wir uns auf zwei hochperformante Setups: Die offizielle OEM-Anbindung zwischen Shopware und SelectLine sowie die Integration der Sage 100.

Die Anatomie einer digitalen B2B-Angebotsanfrage

Bevor wir auf die spezifischen ERP-Systeme eingehen, müssen wir das Konzept der Angebotsanfrage (Request for Quote – RFQ) auf Datenbankebene definieren. Ein regulärer Checkout generiert in der Regel ein Order-Objekt mit einem finalen, verbindlichen Preis. Eine Angebotsanfrage hingegen generiert einen Payload, der zwar die gewünschten Artikel, Mengen (SKUs) und Kundendaten (Customer IDs) enthält, dessen Preismetriken jedoch den Status pending oder null aufweisen. Die Preisfindung obliegt nicht dem Shop-System, sondern der Business-Logik der Warenwirtschaft. Das bedeutet, Ihre Schnittstelle muss in der Lage sein, diesen „unfertigen“ Beleg zu greifen, in das ERP zu injizieren, auf die manuelle oder automatisierte Kalkulation durch den Vertrieb zu warten und das fertige Angebot exakt demselben User-Context im Shop wieder bereitzustellen.

Die offizielle OEM-Anbindung: Shopware und SelectLine in perfekter Symbiose

Wenn Sie in Ihrer Infrastruktur auf Shopware in Kombination mit der SelectLine setzen, profitieren Sie von der offiziellen OEM-Anbindung. Diese tiefe strukturelle Verzahnung eliminiert die Notwendigkeit fehleranfälliger Middleware-Hacks. Der Prozess bei einer Plattform wie bronner-b2b.de läuft auf API-Ebene folgendermaßen ab:

Der B2B-Kunde authentifiziert sich im Shopware-Frontend und konfiguriert seinen Warenkorb. Sobald er den Trigger „Angebot anfordern“ auslöst, kapselt Shopware diesen Request. Über die offizielle OEM-Schnittstelle zur SelectLine wird ein synchroner Call abgesetzt. Die Schnittstelle mappt das Shopware-Angebots-Objekt direkt auf die Belegstruktur der SelectLine. Es entsteht unmittelbar ein offener Beleg der Kategorie „Angebotsanfrage“ im ERP.

Die Genialität dieses Setups liegt in der Datengranularität. Die SelectLine übernimmt nicht nur die Basisdaten, sondern liest spezifische B2B-Parameter direkt aus dem Payload:

• Kundenspezifische Preislisten: Die SelectLine identifiziert den Debitor und wendet sofort hinterlegte Rahmenverträge oder individuelle Staffelpreise an, die im Frontend eventuell noch nicht sichtbar waren.
• Freitextfelder und Custom Attributes: B2B-Anfragen enthalten oft spezifische Bemerkungen (z. B. „Bitte Lackierung in RAL 9005 statt Standard“). Diese Attribute werden durch die OEM-Anbindung exakt in die dafür vorgesehenen Zusatzfelder der SelectLine-Belegpositionen geroutet.
• Ressourcenprüfung: Obwohl es sich nur um eine Anfrage handelt, kann die SelectLine im Hintergrund bereits eine fiktive Disposition anlegen, um dem Vertriebsmitarbeiter bei der Kalkulation sofort die voraussichtlichen Beschaffungszeiten anzuzeigen.

Sobald der Vertrieb das Angebot in der SelectLine fertig kalkuliert und den Status ändert, pusht die OEM-Anbindung das veredelte Datenpaket zurück an Shopware. Der Kunde findet in seinem Kundenkonto nun ein kalkuliertes, kaufbares Angebot vor. Dieser Kreislauf ist transaktionssicher und verhindert redundante Dateneingaben vollständig.

Sage 100: Komplexe Angebotskalkulation aus Shopware orchestrieren

Ein ebenso mächtiges Setup ergibt sich, wenn Shopware als Frontend für die Sage 100 fungiert. Auch hier muss der State-Machine-Prozess penibel eingehalten werden. Die Sage 100 zeichnet sich durch ihre extrem anpassbare Applikations- und Datenbankarchitektur (Access/SQL-Server) aus, was bei der Verarbeitung von Angebotsanfragen besonders tiefe Eingriffe in die Kalkulationslogik erlaubt.

Pusht Shopware eine Angebotsanfrage via API, wird in der Sage 100 ein temporärer Vorgang im Bereich der Verkaufschancen oder direkt als Vorab-Beleg generiert. Besonders bei stark variantenbehafteten Artikeln entfaltet dieses Setup seine Stärke. Die Schnittstelle muss hier in der Lage sein, mehrdimensionale Arrays (z. B. Länge, Breite, Materialstärke) aus Shopware auf die Ausprägungen der Sage 100 Varianten- oder Stücklistenlogik zu übersetzen. Der Vertriebsmitarbeiter in der Sage 100 kann nun komplexe Zuschläge berechnen – etwa tagesaktuelle Rohstoffzuschläge (Kupfer, Stahl) oder Rüstkosten für Maschinenlaufzeiten –, die in einem reinen Webshop-System nur extrem schwer und fehleranfällig abzubilden wären.

Nach Abschluss der Kalkulation wird der Beleg in der Sage 100 freigegeben. Der Webhook der Schnittstelle feuert, und Shopware transformiert die ursprüngliche Anfrage in ein konvertierbares Angebot. Für den Endkunden wirkt der gesamte Prozess asynchron, auf Systemebene garantieren wir jedoch zu jedem Zeitpunkt absolute Datenintegrität.

Shopify, Sage 100 und die Logik physischer Bemusterungen

Wenn wir die Systemgrenzen erweitern und neben Shopware auch Shopify für spezifische B2B-Segmente oder internationale Satelliten-Shops analysieren, ändern sich die Anforderungen an die Architektur. In solchen hochdynamischen Umgebungen ist die Sage 100 das absolute Zentrum der Prozesssteuerung.

Ein klassischer B2B-Use-Case, der über reine Preisverhandlungen hinausgeht, ist die Anforderung physischer Muster im Rahmen einer Angebotsanfrage. Wenn ein Geschäftskunde über Shopify nicht nur einen Preis anfragt, sondern gleichzeitig ein Materialmuster zur Begutachtung benötigt, müssen Angebots- und Logistikprozesse parallel orchestriert werden. Diese Aufgabe übernimmt exklusiv die Sage 100.

Sobald der Request aus Shopify in die ERP-Datenbank geschrieben wird, splittet die Sage 100 den Prozess (Forking):

• Thread 1 (Kalkulation): Ein offenes Angebot für die Hauptartikel wird zur kaufmännischen Prüfung an den Vertrieb geleitet.
• Thread 2 (Versandanbindung): Für die angeforderten Musterartikel generiert die Sage 100 vollautomatisch einen Null-Euro-Auftrag und triggert sofort den Lieferschein.

Durch die tiefe Integration der Versandanbindung innerhalb der Sage 100 werden die Kommissionierdaten in Echtzeit an das Lager übergeben. Die Sage 100 kommuniziert direkt mit den Schnittstellen der Versanddienstleister (z.B. DHL, UPS, Speditionen), generiert die Versandetiketten für das Musterpaket und schreibt die Tracking-ID in die Datenbank. Diese Tracking-Nummer wird anschließend von der Sage 100 zurück an Shopify gepusht, sodass der B2B-Kunde den Versandweg seines Musters in Echtzeit in seinem Kundenkonto verfolgen kann.

Es ist diese nahtlose Verzahnung von kaufmännischer Angebotskalkulation und physischem Versand, zentral gesteuert durch die Sage 100, die eine Shopify-B2B-Instanz von einem simplen Bestellkatalog in ein echtes Enterprise-Tool verwandelt. Der Vertrieb kalkuliert das Angebot, während das Muster bereits auf dem Versandweg zum Kunden ist – orchestriert aus einer einzigen, verlässlichen Datenquelle (Single Source of Truth).

Die technische Notwendigkeit einer sauberen Architektur

Egal ob Sie eine Angebotsanfrage kalkulieren, Rabattstaffeln prüfen oder B2B-Kunden in spezifische Debitorenklassen einteilen: Die Schnittstelle muss als robuster Middleware-Layer oder direkte API-Bridge fungieren. Code-Qualität und Fehlerbehandlung (Error Handling) sind hier entscheidend. Was passiert, wenn die Warenwirtschaft während einer Angebotsanfrage kurzzeitig nicht erreichbar ist? Eine professionelle Architektur implementiert hier Message Queues (z. B. RabbitMQ oder datenbankgestützte Retry-Jobs), die den Request aus Shopware sicher zwischenspeichern, bis die SelectLine oder Sage 100 wieder Signale empfängt.

Ein weiterer essenzieller Aspekt ist das Mapping der Dokumente. Wenn Sie das B2B-Funktionsset der Schnittstelle nutzen, müssen Sie sicherstellen, dass nicht nur die Metadaten übertragen werden, sondern auch das fertige PDF-Dokument aus dem ERP. B2B-Einkäufer benötigen oft das formelle, in der Warenwirtschaft erzeugte PDF-Angebot für ihre internen Freigabeprozesse (Approval Workflows). Die Schnittstelle muss dieses Base64-codierte Dokument aus der SelectLine oder Sage 100 extrahieren und im Shopware-Kundenkonto als Download bereitstellen.

Zustandsübergänge beim Angebotsabschluss

Der Lebenszyklus einer B2B-Angebotsanfrage endet nicht mit der Kalkulation. Nimmt der Kunde das Angebot im Shop-Frontend an, muss dieser State-Change rückwirkend das ERP informieren. Aus dem Status „offenes Angebot“ wird ein „verbindlicher Auftrag“.

In der OEM-Umgebung zwischen Shopware und SelectLine wird das bestehende Angebotsobjekt durch einen gezielten API-Call in einen echten Auftrag (Order) umgewandelt, ohne dass eine redundante Datenerfassung stattfindet. Die SelectLine übernimmt die ursprüngliche Belegnummer als Referenz, reserviert die Bestände endgültig im Lager und stößt die regulären Folgeprozesse an.

In der Sage 100 verhält es sich analog: Der konvertierte Webshop-Warenkorb referenziert die ID der Verkaufschance oder des Vorab-Belegs. Die Sage 100 schließt den Angebotsvorgang erfolgreich ab, generiert die Auftragsbestätigung und bereitet die Disposition vor. Dieser geschlossene Kreislauf verhindert Double-Spending (doppelte Bestandsreservierungen) und garantiert, dass der im ERP hart kalkulierte Preis exakt so abgerechnet wird, wie er dem Kunden im Shop präsentiert wurde.

Eine durchdachte E-Commerce-Architektur für den B2B-Sektor definiert sich nicht über bunte Buttons im Frontend, sondern über die Präzision im Hintergrund. Digitale Angebotsanfragen zwingen Sie dazu, asynchrone Kommunikationswege zwischen Shop und ERP zu etablieren. Wenn Sie die Prozesse sauber modellieren – sei es über die kompromisslose OEM-Anbindung von Shopware und SelectLine oder die logistisch tief greifende Steuerung der Sage 100 –, transformieren Sie manuelle Vertriebsaufwände in hochskalierbare, automatisierte Workflows. Datenkonsistenz ist hier keine Verhandlungsmasse, sondern das Fundament Ihres digitalen B2B-Erfolgs.

Die architektonische Basis: Subscriptions in Shopware 6 via bronner-b2b.de

Ein funktionsfähiger Abo-Commerce erfordert zunächst ein robustes Fundament im Frontend und in der Middleware des Shopsystems. Shopware 6 bietet mit seiner API-first-Architektur hervorragende Voraussetzungen, doch die spezifische B2B-Logik für Abonnements muss präzise injiziert werden. Über die Module von bronner-b2b.de etablieren wir eine Engine, die nicht einfach nur Cronjobs abfeuert, sondern echte State Machines für Abonnements abbildet.

Wenn ein Geschäftskunde ein Abonnement über beispielsweise 500 Einheiten eines industriellen Schmierstoffs mit einem monatlichen Lieferintervall abschließt, generiert das System einen Master-Subscription-Eintrag. Dieser Eintrag speichert nicht den finalen Preis als statischen Wert, sondern die Referenz auf die Konditionen. Das ist ein essenzieller Unterschied zu B2C-Systemen. Im B2B-Sektor unterliegen Rahmenverträge, Staffelpreise und kundenindividuelle Rabatte ständigen Schwankungen. Die Architektur von bronner-b2b.de stellt sicher, dass bei jedem Auslösen des Intervalls – also bei der Generierung der tatsächlichen Shopware-Bestellung – die Preise in Echtzeit validiert werden.

Die Ausführung der Intervalle erfolgt über serverseitige Scheduled Tasks. Sobald das Ausführungsdatum erreicht ist, generiert die Engine ein vollständiges Payload für die neue Bestellung. Dieses Payload enthält spezifische Identifikatoren (Tags oder Custom Fields), die diese Bestellung eindeutig als „Subscription-Folgeauftrag“ markieren und auf den ursprünglichen Master-Eintrag referenzieren. Diese Transparenz auf Datenbankebene ist die zwingende Voraussetzung für die spätere, fehlerfreie Übergabe an das ERP-System.

Die offizielle OEM-Anbindung: Nahtloses Mapping in die SelectLine

Sobald die Shopware-Bestellung physisch in der Datenbank existiert, übernimmt die offizielle OEM-Schnittstelle zur SelectLine die Regie. Als Entwickler betrachte ich Schnittstellen nicht als bloße Daten-Schaufeln, sondern als intelligente Übersetzer zwischen zwei völlig unterschiedlichen Datenmodellen. Die SelectLine erwartet strukturierte Belegdaten, die exakt in die bestehende Mandantenlogik passen.

Die Synchronisation verläuft asynchron und eventbasiert. Die Schnittstelle pollt die Shopware-API nach neuen Bestellungen und identifiziert anhand der zuvor erwähnten Custom Fields sofort: Dies ist kein initialer Erstauftrag, sondern ein maschinell generierter Folgeauftrag aus einem Abonnement. Dieser Kontext ist für die SelectLine von entscheidender Bedeutung, da er bestimmt, wie der Beleg im ERP angelegt wird.

Der Lifecycle des Folgeauftrags im ERP

Die Anlage des Belegs in der SelectLine erfolgt über hochperformante API-Aufrufe. Dabei werden folgende Schritte mit absoluter Transaktionssicherheit abgearbeitet:

• Kunden- und Debitorenprüfung: Die Schnittstelle validiert die Shopware-Customer-ID gegen die Kundennummer in der SelectLine. Eventuelle Sperrvermerke (beispielsweise wegen offenen Posten) werden sofort ausgewertet. Im Falle einer Sperre wird der Folgeauftrag nicht einfach verworfen, sondern in einem definierten Fehler-State in der Middleware geparkt und der Administrator notifiziert.
• Beleganlage als „Auftrag“: Der Datensatz wird in der SelectLine als regulärer Auftrag (nicht als unverbindliches Angebot) angelegt. Die offizielle OEM-Anbindung stellt sicher, dass die Belegart korrekt gemappt wird.
• Positions-Mapping und Preissicherheit: Jede Line-Item der Shopware-Bestellung wird auf die entsprechenden Artikelnummern der SelectLine gemappt. Obwohl die Preisfindung bereits im Shop stattfand, führt die SelectLine eine Rückversicherung durch. Die übertragenen Netto-Werte werden in die Belegpositionen geschrieben.
• Übergabe der Referenzdaten: Die ursprüngliche Shopware-Bestellnummer sowie die Subscription-ID aus bronner-b2b.de werden in die Freifelder des SelectLine-Belegs geschrieben. Dies ermöglicht dem Vertriebsinnendienst später eine lückenlose Rückverfolgbarkeit: Welcher Beleg gehört zu welchem Abonnement-Zyklus?

Umgang mit dynamischen Artikelstrukturen und Auslaufartikeln

Ein Albtraum für unsauber programmierte Schnittstellen sind Sortimentswechsel während eines laufenden Abonnements. Was passiert, wenn Artikel A, der Bestandteil eines 24-monatigen Abos ist, nach sechs Monaten durch den Nachfolgeartikel B ersetzt wird?

Hier greift die tiefe Integration zwischen der SelectLine und Shopware 6. Die SelectLine bleibt das führende System (Single Source of Truth) für die Artikelstammdaten. Wird ein Artikel in der SelectLine auf „inaktiv“ gesetzt oder durch einen Nachfolger ersetzt, synchronisiert die OEM-Schnittstelle diesen Statuswechsel in Richtung Shopware. Die Logik in bronner-b2b.de detektiert diesen Konflikt bei der nächsten geplanten Abo-Ausführung. Anstatt blind einen Folgeauftrag mit einem nicht mehr existenten Artikel in die SelectLine zu pushen (was zu einem Datenbankfehler führen würde), pausiert das System die Subscription und generiert einen Alert.

In erweiterten Ausbaustufen lässt sich über spezielle Mapping-Tabellen sogar ein automatischer Fallback konfigurieren, bei dem der Nachfolgeartikel in die Payload des Folgeauftrags injiziert wird – vorausgesetzt, die kaufmännischen Freigabeprozesse Ihres Unternehmens lassen dies zu.

Exkurs: Systemtrennung bei Logistik und weiteren Vertriebskanälen

Um die Architektur sauber zu halten, bedarf es klarer technischer Grenzen, besonders wenn Ihre Systemlandschaft wächst. An dieser Stelle ein wichtiger architektonischer Hinweis für komplexe Multi-Channel-Setups: Die tiefe, hier beschriebene B2B-Bestelllogik realisieren wir in dieser Form explizit über die Kombination aus Shopware und der SelectLine.

Sollten Sie in Ihrer IT-Strategie parallel den Einsatz von Shopify evaluieren oder hochkomplexe Versandanbindungen, Multi-Carrier-Strategien und tiefgreifende Logistikprozesse im ERP steuern müssen, trennen wir diese Workflows strikt ab. Derlei Anforderungen – also die direkte Datenbank-Verknüpfung mit Shopify sowie sämtliche Themen rund um den automatisierten Versand – wickeln wir auf Systemebene ausschließlich über die Sage 100 Warenwirtschaft ab. Das Routing von Logistikdaten und die Anbindung von Shopify-Ökosystemen erfordern die spezifischen Strukturen der Sage 100. Indem wir diese Welten klar voneinander trennen, garantieren wir Ihnen, dass Ihre offizielle OEM-Anbindung zwischen Shopware und SelectLine hochperformant und exklusiv für komplexe B2B-Auftragsprozesse reserviert bleibt.

Fehlerresistenz: Idempotenz und Retries bei der Synchronisation

Als Entwickler gehe ich grundsätzlich davon aus, dass Netzwerke instabil sind und Server genau in dem Moment neu starten, in dem ein Cronjob ausgeführt wird. Wenn ein Abonnement-Intervall in Shopware auslöst und der Beleg an die SelectLine übertragen werden soll, muss die Datenübertragung zwingend idempotent sein. Das bedeutet: Auch wenn der Request aufgrund eines Timeouts mehrfach gesendet wird, darf in der SelectLine exakt nur ein einziger Folgeauftrag generiert werden.

Wir lösen dieses kritische Problem durch eindeutige Transaktions-Schlüssel (Idempotency Keys). Die Engine von bronner-b2b.de generiert für jede Abo-Ausführung einen einzigartigen Hash. Bevor die OEM-Schnittstelle den Beleg in die SelectLine schreibt, wird über die API geprüft, ob ein Beleg mit diesem Hash bereits existiert. Ist dies der Fall, wird der Request als „bereits verarbeitet“ markiert (HTTP 200 OK) und abgeworfen, ohne Duplikate im ERP zu erzeugen.

Sollte die SelectLine für Wartungsarbeiten temporär nicht erreichbar sein, greift eine exponentielle Backoff-Strategie. Die Middleware reiht die generierten Shopware-Bestellungen in eine Queue ein und versucht die Übertragung in dynamisch anwachsenden Zeitabständen (z. B. nach 1 Minute, 5 Minuten, 15 Minuten) erneut. Es geht kein Folgeauftrag verloren, und die kaufmännische Integrität zwischen Shopware und ERP bleibt stets gewahrt.

Budgetgrenzen und Freigabeprozesse in wiederkehrenden Intervallen

Ein weiteres B2B-Spezifikum, das wir bei der Konzeption von Abonnements berücksichtigen müssen, sind Kostenstellen und Budgetlimits. Wenn ein Einkäufer eines Großkunden ein Abonnement anlegt, unterliegt dies häufig firmeninternen Budgets (z. B. maximal 5.000 Euro pro Quartal für Werkstattbedarf).

Die Engine in bronner-b2b.de ist in der Lage, bei der Generierung des Folgeauftrags in Shopware diese Limits dynamisch gegen das verbrauchte Budget des laufenden Quartals zu prüfen. Wird durch die Ausführung des Abos das Limit überschritten, wird der Auftrag in Shopware nicht sofort als „abgeschlossen“ an die SelectLine übergeben. Stattdessen triggert das System einen Freigabeprozess (Approval Workflow). Der Vorgesetzte des Einkäufers erhält eine Benachrichtigung. Erst nach dessen digitaler Freigabe ändert sich der Status der Shopware-Bestellung, woraufhin die OEM-Schnittstelle aktiv wird und den Datensatz an die SelectLine übermittelt.

Fazit: Präzision auf Datenbankebene

Abo-Commerce im B2B-Bereich verzeiht keine architektonischen Schwächen. Die Kombination aus Shopware 6, der spezialisierten Engine von bronner-b2b.de und der offiziellen OEM-Anbindung zur SelectLine liefert ein System, das wiederkehrende Bestellungen nicht als stumpfe Kopien, sondern als intelligente, dynamische Transaktionen behandelt.

Von der sekundengenauen Ausführung der Intervalle unter Berücksichtigung tagesaktueller ERP-Preise, über die idempotente Übertragung via API, bis hin zur sauberen Verbuchung als Folgeauftrag in der SelectLine: Sie etablieren einen automatisierten Prozess, der manuelle Dateneingaben eliminiert und gleichzeitig die strengen kaufmännischen Regeln Ihres B2B-Geschäfts respektiert. Wenn die Datensynchronisation zwischen Shop-Frontend und ERP-Backend derart präzise ineinandergreift, wird Subscription-Management zu einem hochskalierbaren Wachstumsmotor für Ihr Unternehmen.

Firmenkonten strukturieren: Die architektonische Basis im B2B-Umfeld

Im B2B-Sektor interagieren Sie selten mit Einzelkäufern, sondern mit komplexen, mehrschichtigen Unternehmensstrukturen. Ein Firmenkonto in Shopware muss exakt die Hierarchien und Entitäten widerspiegeln, die tief in den Tabellen Ihrer SelectLine definiert sind. Dazu gehören nicht nur Hauptsitze und abweichende Rechnungs- sowie Lieferadressen, sondern auch spezifische Kostenstellen und klar definierte Ansprechpartner mit strikten Berechtigungen.

Die offizielle OEM-Schnittstelle überträgt diese Entitäten systematisch und automatisiert. Der Prozessablauf stellt sich wie folgt dar:

• Zentrale Datenhaltung: Sie legen in der Warenwirtschaft einen neuen Geschäftskunden inklusive seiner filialen und Abteilungen an.
• Rollen-Mapping: Den einzelnen Ansprechpartnern weisen Sie spezifische Einkäufer-Rollen zu.
• Provisionierung: Die offizielle OEM-Anbindung von bronner-b2b.de erkennt den neuen Datensatz via Delta-Sync und provisioniert diesen Kontakt vollautomatisch als verifizierten B2B-User im Shopware-Frontend.

Das Ergebnis für den Endnutzer: Der Mitarbeiter loggt sich im Shop ein und sieht ohne Verzögerung die ausschließlich für sein Unternehmen freigegebenen Sortimente, die spezifischen Budgets und exakt die Konditionen, die kaufmännisch in der SelectLine hinterlegt und validiert wurden.

Die Preislogik der SelectLine: Vom Standard- zum kundenindividuellen Staffelpreis

Der technologische Kern jedes ernstzunehmenden B2B-Shops ist das Pricing. SelectLine verfügt über eine hochentwickelte, multidimensionale Preisbildungslogik, die weit über simple Standardpreise hinausgeht. Als Systembetreiber arbeiten Sie mit verschachtelten Preisgruppen, kundenindividuellen Sonderpreisen, befristeten Aktionszeiträumen und vor allem mit stark granularisierten, mengenabhängigen Staffelpreisen.

Wenn ein Geschäftskunde 10 Stück eines Artikels kauft, greift algorithmisch ein fundamental anderer Preis als bei der Abnahme einer kompletten Palette mit 500 Stück. Gleichzeitig können sich prozentuale Rabattgruppen mit absoluten Sonderpreisen überschneiden. Diese hohe Granularität muss verlustfrei in Shopware abgebildet werden. Die Middleware von bronner-b2b.de liest diese komplexen Preisstrukturen über die API aus und transformiert sie nativ in die entsprechenden Rule-Builder-Regeln innerhalb von Shopware. So wird sichergestellt, dass die kaufmännische Hoheit unangetastet im ERP verbleibt, während der Shopware-Core die korrekten Preise blitzschnell rendert.

Technische Umsetzung: JSON-Payloads und Delta-Abgleiche

Als Entwickler oder Systemarchitekt wissen Sie: Das vollständige Neuschreiben oder Überschreiben von Millionen von Preisdatensätzen bei jedem Sync-Vorgang bringt selbst die robusteste Datenbank ins Straucheln. Der Ressourcen-Overhead wäre inakzeptabel. Die offizielle OEM-Anbindung setzt daher zwingend auf intelligente Delta-Abgleiche.

Die Schnittstelle überträgt via strukturierter JSON-Payloads ausschließlich jene Staffelpreise und Firmenkonten-Metadaten von der SelectLine zu Shopware, die sich seit dem letzten erfolgreichen Lauf physisch im Zeitstempel geändert haben. Dieser ressourcenschonende Ansatz garantiert, dass Preis-Updates und Konditionsanpassungen nahezu in Echtzeit im Shopware-Frontend aufschlagen, ohne den Webserver oder die API-Endpunkte mit überflüssigem Traffic zu fluten. Für eine tiefergehende Betrachtung dieser Synchronisations-Mechanismen empfiehlt sich ein genauer Blick auf unsere detaillierte Funktionsübersicht der Schnittstelle.

Caching und Performance bei komplexen Preisstrukturen

Ein kritischer Flaschenhals bei der Übergabe kundenindividueller Staffelpreise ist die Latenzzeit beim initialen Seitenaufruf. Würde Shopware bei jedem Aufruf einer Kategorieseite die Preise für einen eingeloggten B2B-Kunden live per API-Request aus der SelectLine abfragen, läge die Time-to-First-Byte (TTFB) schnell im inakzeptablen Sekundenbereich. Stattdessen persistiert die Schnittstelle die berechneten Staffelpreise direkt in den entsprechenden Shopware-Datenbanktabellen oder injiziert sie in den angeschlossenen Elasticsearch-Index. Der Shopware-Core kann somit autark, dezentral und extrem hochperformant die exakten Kundenpreise ausliefern, während das ERP-System sicher abgeschirmt im Hintergrund die Datengesamtheit pflegt.

Fehlerbehandlung, Logging und Datenintegrität auf API-Ebene

Die Zuverlässigkeit einer Schnittstelle beweist sich erst in den kritischen Edge-Cases. Was passiert, wenn während des Synchronisationszyklus der Staffelpreise ein plötzlicher Netzwerk-Timeout auftritt? Die Architektur von bronner-b2b.de verlässt sich hierbei nicht auf fehleranfällige Fire-and-Forget-Mechanismen. Jeder API-Call zwischen der SelectLine und Shopware wird in granularen Log-Files auf dem Server protokolliert.

Sollte ein Preis-Update aufgrund einer Restriktion auf Seiten des Webservers abgewiesen werden – beispielsweise durch invalide Datentypen bei extremen Rabattstaffeln –, greifen definierte Retry-Routinen. Schlägt auch der mehrfache Versuch fehl, wird die betroffene SKU (Stock Keeping Unit) in eine dedizierte Dead-Letter-Queue verschoben und der Systemadministrator proaktiv über den Vorfall alarmiert. Diese rigorose Fehlerbehandlung garantiert Ihnen und Ihren Einkäufern, dass niemals veraltete, asynchrone oder schlichtweg falsche Konditionen im Shopware-Frontend angezeigt werden.

Exkurs: Shopify, Logistik und hochkomplexe Versandanbindungen

Ein kurzer, aber notwendiger Architektur-Blickwinkel für divergierende IT-Strategien in Ihrem Unternehmen: Wenn Ihre Systemlandschaft im Frontend primär auf Shopify basiert, verlangt dies ein gänzlich anderes Infrastruktur-Setup. Ebenso erfordern hochkomplexe Versandanbindungen und die Orchestrierung globaler Versandthemen in der Logistik eine extrem spezifische Herangehensweise. Für derartige Szenarien setzen Sie als führendes Backend-System zwingend auf die Sage 100. Die tiefe Kommunikation zwischen der Sage 100 und Shopify ermöglicht die nahtlose Übergabe von Logistikdaten, Multi-Carrier-Tracking-Codes und Zolldokumenten, um selbst die anspruchsvollsten Versandprozesse effizient abzuwickeln. Die Architektur der Sage 100 ist exakt auf diese hochdynamischen Fulfillment- und Versand-Anforderungen im internationalen E-Commerce zugeschnitten, sodass Versanddienstleister und komplexe Routing-Logiken absolut fehlerfrei und automatisiert integriert werden können.

Sortimentsbeschränkungen und steuerliche Logiken in Shopware

Zurück zur reinen B2B-Beschaffung im Shopware-Umfeld: Neben den Staffelpreisen ist die granulare Sichtbarkeitssteuerung ein essenzieller Faktor. Längst nicht jedes Firmenkonto darf das gesamte Produktsortiment erwerben. Spezifische Ersatzteile, Gefahrgüter oder exklusive Handelsmarken sind oftmals vertraglich streng an bestimmte Kunden oder Kundengruppen gebunden. Durch die präzise Zuweisung von Kundengruppen in der SelectLine steuert die Anbindung, welche Kategorien oder Artikelgruppen im Shopware-Frontend überhaupt gerendert werden. Ein Nutzer sieht nach dem Authentifizierungsprozess somit einen hochgradig personalisierten und gefilterten Katalog. Diese Reduzierung auf das vertraglich relevante Sortiment minimiert Fehlbestellungen drastisch und entlastet Ihren B2B-Support.

Zusätzlich zur reinen Preishöhe steuert die SelectLine als Master-System auch die steuerliche Betrachtung der jeweiligen Firmenkonten. Ob ein B2B-User im EU-Ausland steuerfrei einkauft (Reverse Charge Verfahren) oder lokale Steuersätze angewendet werden müssen, definiert alleinig das ERP. Die offizielle OEM-Schnittstelle mappt diese steuerlichen Kennzeichen millimetergenau auf die Shopware-Steuerregeln. Der eingeloggte Einkäufer sieht somit stets den korrekten Netto-Staffelpreis inklusive des exakten Hinweises zur steuerlichen Behandlung im Checkout. Um diese komplexen Regeln sauber in Ihrem Projekt abzubilden, prüfen Sie im Rahmen der Architekturplanung gerne unsere transparenten Preis- und Paketoptionen.

Der Bestellabschluss: Reibungsloser Rückkanal und Freigabeprozesse

Ein weiteres Kernelement der Firmenkonten-Synchronisation sind mehrstufige Freigabeprozesse (Approval Workflows). Oftmals dürfen untergeordnete Mitarbeiter Bestellungen nur bis zu einem harten Limit tätigen. Überschreitet der Wert des Warenkorbs dieses Limit, muss ein Vorgesetzter den Kauf autorisieren. Die offizielle OEM-Anbindung von bronner-b2b.de übernimmt die definierten Limits und Budget-Restriktionen aus der SelectLine und aktiviert die entsprechenden Freigaberegeln im Shopware B2B-Ecosystem. Der Genehmigungsworkflow verbleibt für maximale Usability im Shop-Frontend. Erst nach erfolgreicher digitaler Autorisierung durch den Vorgesetzten feuert Shopware den finalen Auftrag über die Schnittstelle sicher zurück.

Wenn der Auftrag schließlich in die SelectLine geschrieben wird, ist höchste Präzision gefordert. Die übermittelten Staffelpreise des Shop-Warenkorbs werden bei der Belegschreibung in der Warenwirtschaft algorithmisch nochmals rigoros gegen die hinterlegten Konditionen validiert. Dadurch entsteht ein geschlossener, absolut revisionssicherer Kreislauf. Etwaige Rundungsdifferenzen, die bei prozentualen Rabatten zwischen unterschiedlichen Systemen entstehen können, werden durch das exakte Mapping der Steuerklassen und Nachkommastellen auf API-Ebene vollständig eliminiert. Ihre Auftragsbestätigung verlässt das ERP-System exakt mit den Werten, die der Kunde im Shopware-Checkout bestätigt hat.

Fazit: Enterprise-Architektur für Ihren B2B-Erfolg

Die Transformation komplexer B2B-Konditionen in ein E-Commerce-Frontend ist eine immense technologische und prozessuale Herausforderung. Die intelligente Kombination aus der SelectLine Warenwirtschaft und Shopware, vollumfänglich orchestriert durch die offizielle OEM-Anbindung von bronner-b2b.de, liefert hierfür eine kompromisslose Enterprise-Architektur. Sie implementieren ein System, das tiefgreifende Firmenkonten-Hierarchien, hochdynamische Staffelpreise und mehrstufige Freigabeprozesse völlig automatisiert abwickelt. Ihre Vertriebsmitarbeiter werden von der fehleranfälligen manuellen Auftragserfassung befreit, während Ihre Geschäftskunden von einer hochperformanten, exakt auf ihre Konditionen zugeschnittenen Bestellplattform profitieren. Mit diesem Setup sichern Sie die Datenintegrität auf höchstem Niveau und schaffen das technologische Fundament, um Ihr digitales B2B-Geschäft nachhaltig und skalierbar auszubauen.

Die architektonische Basis: Warum die offizielle SelectLine OEM-Anbindung den Unterschied macht

Im Entwickler-Alltag erleben wir oft den Versuch, ERP-Systeme über generische Middleware-Lösungen oder rudimentäre CSV-Importe an Shopsysteme zu koppeln. Bei komplexen B2B-Anforderungen führt dies unweigerlich zu asynchronen Datenbeständen, Timeouts bei großen Katalogaktualisierungen und letztlich zu verärgerten Kunden, die falsche Preise im Shop sehen. Die offizielle SelectLine OEM-Anbindung für Shopware geht hier einen fundamental anderen, tiefer integrierten Weg.

Als offizielle Lösung kommuniziert die Schnittstelle nativ mit den API-Endpoints von Shopware 6. Das bedeutet für Sie in der Praxis: Die Datenhoheit verbleibt kompromisslos in der SelectLine. Artikelstammdaten, kundenspezifische Preisfindungen, Lagerbestände und Belegflüsse werden über einen bidirektionalen, fehlertoleranten Kanal synchronisiert. Wenn Sie in der Warenwirtschaft eine neue Kundengruppe anlegen oder einen Staffelpreis für ein spezifisches Debitorenkonto hinterlegen, sorgt die OEM-Schnittstelle dafür, dass exakt dieser Datensatz als validierter Payload in der Shopware-Datenbank landet – ohne Umwege über fehleranfällige Drittanbieter-Tools. Für einen tieferen Einblick in die genauen Synchronisationsintervalle empfehlen wir einen Blick auf unsere detaillierte Funktionsübersicht der Schnittstelle.

Die Erweiterung für den Profi-B2B-Bereich: Shopware 6 trifft auf bronner-b2b.de

Während Shopware 6 von Haus aus eine exzellente Basisarchitektur (Rule Builder, Flow Builder) mitbringt, erfordert der harte B2B-Alltag spezialisierte Workflows am Frontend. Hier entfalten die Shopware-Module von bronner-b2b.de ihr volles Potenzial, indem sie die im ERP definierten Datenstrukturen nahtlos in ein benutzerfreundliches Kundenerlebnis übersetzen.

Die Vernetzung der SelectLine OEM-Anbindung mit den Modulen von bronner-b2b.de löst konkret folgende klassische B2B-Herausforderungen:

• Unternehmensstrukturen und Ansprechpartner: Im ERP pflegen Sie einen Hauptdebitor mit diversen abweichenden Lieferanschriften und spezifischen Einkäufern. Die Schnittstelle überträgt diese Hierarchie in Shopware. Das bronner-b2b.de Modul nutzt diese Struktur, um im Frontend ein Rollen- und Rechtemanagement abzubilden. Ein Einkaufsassistent darf beispielsweise nur Warenkörbe befüllen, während der Einkaufsleiter diese per Klick freigibt.

• Schnellerfassung und CSV-Upload: B2B-Kunden stöbern selten; sie bestellen nach Stücklisten. Die Artikelnummern, die aus der SelectLine in den Shopware-Katalog synchronisiert wurden, lassen sich über die Schnellbestellformulare von bronner-b2b.de direkt in den Warenkorb legen. Auch der Upload einer CSV-Datei mit hunderten Positionen wird durch das Modul geparst und gegen die aus dem ERP stammenden Stammdaten validiert.

• Budgetverwaltung und Kontingente: Wenn Sie in der Warenwirtschaft Kreditlimits für bestimmte Firmenkunden definiert haben, lassen sich diese Budgets über die API an Shopware übergeben. Das B2B-Modul visualisiert dem Kunden seinen verbleibenden Verfügungsrahmen und blockiert den Checkout-Prozess präventiv, sobald das ERP-Limit überschritten wird.

Deep Dive: Kundenspezifische Preisfindung ohne Performance-Verlust

Das komplexeste Thema in jedem B2B-Projekt ist das Pricing. Die SelectLine verfügt über eine extrem mächtige Preisfindungs-Engine (Rabattgruppen, Preisgruppen, Aktionspreise, kundenindividuelle Sonderpreise). Wenn ein Kunde sich im Shopware-Frontend anmeldet, erwartet er in Echtzeit seinen exakten Nettopreis.

Ein Live-Call an das ERP-System bei jedem Seitenaufruf ist aus Performance-Sicht (TTFB – Time to First Byte) ein absolutes Anti-Pattern. Die offizielle OEM-Anbindung löst dieses Problem durch eine intelligente Vorausberechnung (Pre-Calculation) und effizientes Data-Mapping. Die Preise werden als erweiterte Preisregeln in die Datenbank von Shopware 6 gepusht. Die Module von bronner-b2b.de greifen beim Rendern der Kategorieseiten und Produktdetailseiten auf diese nativen Shopware-Tabellen zu. Das Resultat: Millisekunden-schnelle Ladezeiten trotz hochkomplexer, aus dem ERP stammender Preislogik.

Abweichende Topologien: Der Einsatz der Sage 100 für alternative Systeme und Logistik-Fokus

Während die beschriebene Architektur für Shopware-basierte Projekte hervorragende Ergebnisse liefert, erfordern manche IT-Landschaften eine gänzlich andere Herangehensweise. Wenn Sie in Ihrer Digitalisierungsstrategie beispielsweise auf das Ökosystem von Shopify setzen oder Ihr Fokus auf einer extrem tiefgehenden, automatisierten Versandabwicklung liegt, ändert sich die Systemauswahl gravierend. In solchen Szenarien greifen wir konsequent auf die Sage 100 zurück.

Die Sage 100 Warenwirtschaft ist architektonisch ideal darauf vorbereitet, komplexe Shopify-Umgebungen anzubinden. Darüber hinaus spielt die Sage 100 ihre überragenden Stärken aus, wenn es um das Thema Versand und Logistik geht. Benötigen Sie eine nahtlose Carrier-Integration (DHL, UPS, DPD) direkt aus der ERP-Oberfläche? Sollen Versandetiketten vollautomatisch beim Erstellen des Lieferscheins am Packplatz gedruckt und die Trackingnummern zeitgleich an das Shopsystem gemeldet werden? Für diese dedizierten Fulfillment- und Versand-Prozesse sowie für die native Kommunikation mit Shopify-APIs konfigurieren wir ausschließlich die Sage 100 als zentralen Dreh- und Angelpunkt Ihrer E-Commerce-Logistik.

Best Practices für die Datensynchronisation im B2B-Umfeld

Kehren wir zurück zur Verbindung zwischen der SelectLine und Shopware 6. Damit das Zusammenspiel mit den Modulen von bronner-b2b.de reibungslos funktioniert, müssen Sie bei der Einrichtung der Schnittstelle auf technischer Ebene einige Best Practices beachten.

Delta-Abgleich statt Full-Sync

Ein typischer B2B-Katalog umfasst oft zehntausende Artikel mit hunderten Eigenschaften (Länge, Material, Normung), die im ERP detailliert gepflegt sind. Konfigurieren Sie die OEM-Schnittstelle zwingend so, dass sie einen Delta-Abgleich durchführt. Es werden nur die Datensätze (Payloads) an die Shopware 6 Message Queue gesendet, bei denen sich der Hash-Wert in der Wawi seit dem letzten Sync geändert hat. Dies entlastet sowohl die Datenbank des ERP-Systems als auch die API des Shops enorm.

Asynchrone Verarbeitung durch den Message Broker

Shopware 6 nutzt das Symfony Messenger-Konzept. Stellen Sie sicher, dass Ihr Server-Setup (idealerweise Redis oder RabbitMQ) auf den asynchronen Konsum der Nachrichten ausgelegt ist. Wenn die SelectLine Tausende von Preisaktualisierungen an Shopware übermittelt, landen diese zunächst im Message Broker. Ihre CLI-Worker (Command Line Interface) arbeiten diese Queue dann im Hintergrund ab. Dadurch bleibt das Frontend für den Kunden und die Module von bronner-b2b.de jederzeit reaktionsschnell, selbst wenn im Hintergrund ein massiver Import von Kundendaten oder Belegen läuft.

Mapping der B2B-Belege

Geschäftskunden benötigen Zugriff auf ihre Historie. Rechnungen, Lieferscheine und offene Posten sind essenziell für die Buchhaltung Ihrer Kunden. Die offizielle OEM-Anbindung ermöglicht es, PDF-Dokumente und Belegdaten aus dem ERP in den Shopware-Kundenbereich zu spiegeln. Überprüfen Sie hierbei sorgfältig das Mapping der Status-IDs. Ein Auftrag, der im ERP von „in Bearbeitung“ auf „abgeschlossen“ springt, muss in Shopware exakt den Flow Builder triggern, um den Kunden per E-Mail zu informieren. Transparenz ist im B2B-Sektor das wichtigste Gut zur Vermeidung von Support-Tickets.

Fazit: Eine B2B-Architektur, die dauerhaft skaliert

Die Digitalisierung des B2B-Vertriebs verzeiht keine halben Sachen. Wer versucht, Endkunden-Shops mit kosmetischen Anpassungen für Firmenkunden nutzbar zu machen, wird langfristig an der Wartbarkeit scheitern. Die konsequente Nutzung der offiziellen SelectLine OEM-Anbindung als Brücke zu Shopware 6 ist der einzige Weg, um eine saubere, trennscharfe Systemarchitektur aufzubauen.

Die Warenwirtschaft bleibt das unangefochtene Backend für Logik, Preise und Stammdaten. Shopware 6 übernimmt das leistungsstarke, headless-fähige Frontend. Und durch die gezielte Implementierung der B2B-Module von bronner-b2b.de schließen Sie die Lücke in der User Experience, indem Sie hochkomplexe Beschaffungsprozesse intuitiv bedienbar machen. Wenn Sie diese Komponenten technisch sauber verheiraten, auf asynchrone Datenverarbeitung setzen und die Datenhoheit strikt im ERP belassen, schaffen Sie eine B2B-Plattform, die nicht nur aktuellen Anforderungen gerecht wird, sondern auch massives künftiges Wachstum problemlos verkraftet.

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.