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.

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.

Als Entwickler, der sich tagtäglich mit der Datenintegrität zwischen E-Commerce-Plattformen und ERP-Backends befasst, betrachte ich die Schnittstelle als das zentrale Nervensystem dieser Infrastruktur. Die offizielle OEM-Anbindung für SelectLine ist exakt für solche Belastungsspitzen und Logik-Verschachtelungen konzipiert. Sie übernimmt die Aufgabe, das asynchrone JSON-Payload eines komplexen Shopware-Auftrags bitgenau und fehlerfrei in die strikte relationale Datenbanklogik der SelectLine Warenwirtschaft zu übersetzen.

Schnellbestellungen per CSV: Wenn Datenmassen auf die ERP-Logik treffen

Die Implementierung einer Schnellbestellfunktion via CSV-Upload in Shopware 6 optimiert die User Experience für den B2B-Einkäufer enorm. Anstatt sich durch Kategoriestrukturen zu navigieren, lädt das System eine rohe Liste mit oft hunderten product_number– und quantity-Werten in den Speicher. Das Shopware-Frontend validiert diese Eingaben gegen den aktuellen Index, berechnet individuelle B2B-Rabatte und erzeugt ein massives Checkout-Payload.

Die Herausforderung für die Schnittstelle beginnt exakt in der Sekunde des Kaufabschlusses. Ein Auftrag mit 350 Positionen darf das ERP-System bei der synchronen Übergabe nicht blockieren. Die offizielle OEM-Schnittstelle nutzt hierfür intelligente Warteschlangen (Message Queues) und verarbeitet die Aufträge asynchron. Dies bedeutet für Ihre Architektur:

• Transaktionssicherheit: Der gesamte Auftrag wird als eine atomare Transaktion an SelectLine übergeben. Bricht die Verbindung bei Position 349 ab, wird der gesamte Beleg in der SelectLine verworfen (Rollback) und der Übertragungsversuch nach einem definierten Intervall neu gestartet. Es entstehen keine „Halb-Aufträge“ in der Warenwirtschaft.
• Performance-Erhalt: Durch die Pufferung der Datenmassen bleibt sowohl Shopware 6 als auch die SelectLine performant. Die API-Limits werden respektiert, während Hintergrund-Worker die Datensätze kontinuierlich abarbeiten.
• Validierung der Artikelnummern: Oftmals weichen SKU-Formate in CSV-Dateien (z.B. durch vorangestellte Nullen) leicht von der Datenbank ab. Die Schnittstelle mappt die Shopware-SKU präzise auf die korrespondierende Artikelnummer in SelectLine, ohne dass es zu Fehlzuordnungen kommt.

Freigabeprozesse: Der feine Unterschied zwischen Entwurf und rechtsgültigem Auftrag

In B2B-Szenarien, insbesondere bei der Nutzung der Shopware B2B Suite oder der B2B Components, löst der Klick auf „Kaufen“ oft noch keinen echten Auftrag aus. Wenn der bestellende Mitarbeiter sein monatliches Budget überschreitet oder bestimmte Warengruppen bestellt, geht der Warenkorb in einen Status „Wartet auf Freigabe“ (Pending Approval) über. Ein Vorgesetzter muss diesen Vorgang zunächst autorisieren.

Aus Schnittstellen-Perspektive erfordert dies eine präzise Überwachung der State Machine in Shopware. Ein fataler Fehler unsauber programmierter Middleware ist es, jeden erzeugten Checkout blind an das ERP zu senden. Die Folge: In der SelectLine entstehen Aufträge, die rechtlich noch gar nicht bindend sind, blockieren physische Lagerbestände und verfälschen die Disposition.

Die offizielle OEM-Anbindung löst dieses Problem durch ein striktes Status-Mapping (siehe auch unsere Funktionsübersicht zur Auftragssynchronisation). Der Prozesszyklus sieht dabei wie folgt aus:

1. Der Mitarbeiter schließt die CSV-Schnellbestellung ab. Der Auftrag erhält in Shopware den internen Status in_progress oder ein äquivalentes B2B-Flag.
2. Die Schnittstelle registriert den Auftrag, ignoriert ihn jedoch bewusst für den Import in die SelectLine, da die Mapping-Regel vorschreibt: Importiere nur Aufträge mit dem Status open oder approved.
3. Der Abteilungsleiter loggt sich in Shopware ein und erteilt die Freigabe. Die State Machine von Shopware ändert den Auftragsstatus.
4. Ein Webhook oder der nächste Cronjob-Zyklus der Schnittstelle erfasst diese Statusänderung. Jetzt erst wird das Payload generiert und der Auftrag als gültiger Beleg (z.B. „Auftrag“ oder „Internetauftrag“) in der SelectLine angelegt.

Das technische Mapping: Shopware-Datenstrukturen in SelectLine-Belege übersetzen

Die Übersetzung eines komplexen B2B-Auftrags ist kein simples Kopieren von Textfeldern. Die SelectLine Warenwirtschaft verlangt nach einer strukturierten Anlage von Belegköpfen und Belegpositionen unter strenger Einhaltung kaufmännischer Logik. Die OEM-Schnittstelle greift tief in diese Architektur ein.

Kunden- und Debitor-Zuordnung

B2B-Kunden in Shopware verfügen oft über abweichende Rechnungs- und Lieferadressen, die als Unternehmenskonten geführt werden. Die Schnittstelle prüft beim Import zunächst, ob die übermittelte customer_number bereits als Debitor in SelectLine existiert. Ist dies der Fall, wird der Auftrag exakt diesem Mandanten zugeordnet. Existiert eine neue Lieferadresse, wird diese nicht als freier Text in den Beleg geschrieben, sondern sauber als neue, verknüpfte Lieferadresse im Kundenstamm der SelectLine angelegt.

Preise, Steuern und Rundungsdifferenzen

Ein berüchtigtes Problem bei der Übertragung langer Stücklisten sind Rundungsdifferenzen. Shopware berechnet den Gesamtpreis (oft netto im B2B) auf Basis eigener Algorithmen. Wenn das ERP-System nun versucht, den Auftrag anhand der übermittelten Mengen und der ERP-internen Preislisten neu zu berechnen, kommt es bei 350 Positionen fast zwangsläufig zu Abweichungen im Cent-Bereich.

Um dies zu verhindern, agiert die Schnittstelle hochgradig defensiv: Sie zwingt die SelectLine nicht zur Neuberechnung, sondern übergibt die in Shopware kalkulierten Netto-Einzelpreise als fixe Werte (Fremdpreise) in die Belegpositionen. Die Steuerklassen (Voll, Ermäßigt, Steuerfrei bei innergemeinschaftlichen Lieferungen) werden anhand der Shopware-Steuer-IDs auf die entsprechenden Steuerschlüssel der SelectLine gemappt. Das Ergebnis ist ein Buchungsbeleg, dessen Gesamtsumme auf den Cent genau dem Checkout in Shopware entspricht.

Verpackungseinheiten (VPE) und Staffelpreise

B2B-Bestellungen via CSV enthalten oft Mengen, die an bestimmte Verpackungseinheiten gebunden sind (z.B. „Gebinde à 50 Stück“). Die Schnittstelle muss die quantity des Shopware-Payloads korrekt interpretieren. Bestellt der Kunde 5 Gebinde, erfasst Shopware möglicherweise „5“, während SelectLine eine Basisstückzahl von „250“ abbuchen muss, je nachdem, wie der Artikelstamm konfiguriert ist. Die OEM-Anbindung gleicht die Umrechnungsfaktoren aus den Artikelstammdaten ab und sorgt dafür, dass die korrekte Basismengeneinheit im Beleg landet, um eine fehlerfreie Lagerabbuchung zu gewährleisten.

Fehlerbehandlung: Wenn Rohdaten korrupt sind

Trotz aller Vorab-Validierungen im Shopware-Frontend kann es vorkommen, dass unsaubere Daten die Schnittstelle erreichen. Ein B2B-Kunde lädt eine veraltete CSV-Datei hoch, die einen Artikel enthält, der in der SelectLine bereits archiviert oder gesperrt ist. Wie reagiert eine sauber konstruierte Middleware?

Anstatt abzustürzen oder den Auftrag komplett verschwinden zu lassen, greift ein mehrstufiges Error-Handling:

1. Validierungsphase: Bevor der Beleg in SelectLine geschrieben wird, simuliert die Schnittstelle den Import (Dry-Run).
2. Fehlererkennung: Das System erkennt, dass Position 112 (SKU: 9988-X) in der SelectLine nicht existiert oder für den Verkauf gesperrt ist.
3. Quarantäne: Der Auftrag wird nicht in die SelectLine geschrieben, um die Datenintegrität des ERPs zu schützen. Gleichzeitig wird der Auftrag in Shopware nicht als „erfolgreich exportiert“ markiert.
4. Alerting: Die Schnittstelle loggt den spezifischen Fehler detailliert („Auftrag #10452 fehlgeschlagen: Artikel 9988-X in SelectLine gesperrt“) und benachrichtigt den Shop-Administrator.

Dieses Vorgehen garantiert, dass Administratoren exakt wissen, wo das Problem liegt, die Stammdaten in SelectLine korrigieren (z.B. den Artikel entsperren) und den Import des Auftrags über das Dashboard der Schnittstelle per Knopfdruck erneut anstoßen können. Es geht kein Umsatz verloren und das ERP bleibt von fehlerhaften Datensätzen verschont.

Fazit

Die Automatisierung komplexer B2B-Aufträge, die über CSV-Uploads generiert und durch Freigabeprozesse verzögert werden, erfordert weit mehr als nur den Transport von Daten von A nach B. Es geht um die semantische Übersetzung von E-Commerce-Logik in strikte, buchhalterische ERP-Richtlinien.

Die offizielle OEM-Anbindung für SelectLine bietet exakt die tiefe Integration, die für solche Hochlastszenarien und verschachtelten Workflows zwingend erforderlich ist. Indem sie Shopware-Statusänderungen exakt abhört, Rundungsdifferenzen durch präzises Preis-Mapping eliminiert und gigantische CSV-Warenkörbe über asynchrone Warteschlangen ressourcenschonend verarbeitet, verwandelt sie potenzielle administrative Flaschenhälse in einen lautlosen, fehlerfreien Hintergrundprozess. Für Unternehmen, die ihren B2B-Einkauf skalieren möchten, ist diese architektonische Stabilität das Fundament für ein verlässliches und profitables E-Commerce-Geschäft.