WooCommerce SAP Business One Anbindung für den B2B-Handel

#WooCommerce SAP Business One Anbindung für den B2B-Handel

Wenn Sie eine breitere Einordnung aller Warenwirtschafts- und ERP-Szenarien suchen, beginnen Sie beim Überblick WooCommerce-Integrationen mit ERP-Systemen. Dort steht SAP Business One neben JTL-Wawi, Dynamics 365 und Odoo als ein Fall unter vielen, und die Skalierungsfrage wird nur angerissen. Hier gehen wir gezielt in die SAP-B1-spezifische Tiefe: die Wahl zwischen den beiden Zugriffswegen, das Datenbankproblem bei großem Sortiment und die betriebswirtschaftliche Belegkette, die einen SAP-Anschluss von einer gewöhnlichen Warenwirtschaftsanbindung unterscheidet.

#Was SAP Business One ist und warum die Anbindung anders zählt

SAP Business One ist das ERP des Herstellers SAP SE für kleine und mittlere Unternehmen. Es verwaltet Finanzbuchhaltung, Einkauf, Lager, Produktion, Vertrieb und die vollständige Belegkette eines Handelsbetriebs in einer einzigen Datenbank, wahlweise auf SAP HANA oder Microsoft SQL Server. Anders als eine reine Warenwirtschaft ist SAP Business One tief in die Buchhaltung verzahnt: Ein Lieferschein bucht Bestand aus, eine Ausgangsrechnung erzeugt zugleich den Buchungssatz in der Finanzbuchhaltung. Für viele mittelständische Händler ist SAP Business One das betriebswirtschaftliche Rückgrat, in dem die verbindliche Wahrheit über Preise, Bestand, Kunden und Umsätze liegt.

Genau diese Verzahnung macht die WooCommerce-Anbindung anspruchsvoller als bei einer schlanken Warenwirtschaft. Der Shop darf nicht eigenmächtig Belege erzeugen, die dann nicht zur SAP-Buchhaltung passen. Er muss vielmehr die Rolle des Verkaufskanals einnehmen, der SAP mit Aufträgen versorgt und im Gegenzug Preise, Bestand und Belegstatus aus SAP übernimmt. Wer diesen Grundsatz missachtet und im Shop parallel eine zweite Wahrheit über Preise oder Rechnungen aufbaut, produziert genau die Differenzen, die im B2B-Handel besonders teuer sind: falsch fakturierte Konditionen, doppelte Belege und Bestände, die im Shop lieferbar zeigen, was SAP längst reserviert hat.

#DI-API oder Service Layer, welcher Zugriffsweg passt

SAP Business One bietet zwei grundsätzlich verschiedene Zugriffswege, und die Wahl zwischen ihnen prägt die gesamte Architektur der Anbindung. Die Entscheidung ist keine Geschmacksfrage, sondern hängt an der HANA- oder SQL-Grundlage, an der Art der Zugriffe und an der Last, die das Frontend erzeugt.

Die DI-API ist die ältere, sehr mächtige Schnittstelle. Sie ist eine COM-Bibliothek, die auf einem Windows-Rechner mit installiertem SAP-B1-Client läuft und das vollständige Objektmodell samt aller Buchungs- und Validierungslogik kennt. Alles, was ein Anwender im SAP-Client tun kann, kann die DI-API programmatisch nachbilden, inklusive komplexer Buchungen mit Sonderregeln. Ihr Preis ist die Bindung an einen Windows-Prozess mit Client-Installation, ein zustandsbehaftetes Verbindungsmodell und eine begrenzte Eignung für viele parallele, kurzlebige Zugriffe, wie sie ein Webshop erzeugt.

Der Service Layer ist der moderne Weg, verfügbar auf der HANA-Grundlage. Er stellt die SAP-Objekte über eine REST- und OData-Schnittstelle bereit, spricht ohne Windows-Client direkt gegen die Datenbank und ist auf zustandslose, parallele Webzugriffe ausgelegt. Für einen WooCommerce-Shop ist der Service Layer der natürliche Kandidat für Lese- und Stammdatenzugriffe: Artikel, Preislisten, Bestand, Business Partner und Belegstatus lassen sich über REST sauber und parallel abfragen.

In der Praxis ist die Antwort selten entweder-oder. Ein verbreitetes Muster ist, den Service Layer für die hochfrequenten Lese- und Standardschreibzugriffe zu nutzen und die DI-API nur dort einzusetzen, wo eine Buchung Sonderlogik verlangt, die der Service Layer nicht abbildet. Läuft SAP noch auf SQL Server ohne Service Layer, führt der Weg über die DI-API oder eine dazwischengeschaltete Integrationsschicht, die die zustandsbehaftete DI-API-Verbindung kapselt und dem Shop eine ruhige, wiederholbare REST-Fassade bietet. Wir legen diese Grenze im Datenvertrag fest, bevor die erste Zeile Code entsteht, denn ein späterer Wechsel des Zugriffsweges berührt die gesamte Integrationsschicht.

#Das B1if-Integrationsframework als Alternative

Neben den beiden Programmierschnittstellen bringt SAP Business One mit dem Integration Framework (B1if) eine eigene, mitgelieferte Middleware mit. B1if arbeitet nachrichtenbasiert: Ereignisse in SAP lösen Szenarien aus, die Daten transformieren und an ein Zielsystem übergeben, und umgekehrt. Für standardisierte, klar umrissene Datenflüsse ist B1if eine legitime Wahl, weil es ohne zusätzlichen externen Dienst auskommt und innerhalb der SAP-Landschaft administriert wird.

Die Grenze von B1if zeigt sich, sobald die Transformationslogik komplex wird oder das Frontend hohe, unregelmäßige Last erzeugt. B1if ist für berechenbare, ereignisgesteuerte Übergaben gebaut, nicht als Hochlast-API vor einem Webshop mit tausenden gleichzeitigen Besuchern. Deshalb setzen wir B1if dort ein, wo ein sauberer, wartbarer SAP-interner Datenfluss genügt, und legen eine eigene, für Weblast ausgelegte Integrationsschicht davor, wenn Caching, Queueing und eine schnelle Lesesicht gefragt sind. Welche Aufteilung für Ihren Fall passt, hängt vom Volumen und von der Frage ab, wie viel Logik in SAP bleiben soll und wie viel in die Integrationsschicht wandert.

#Das wp_postmeta-Problem bei 50.000 SKUs und der konkrete Fix

Der technisch härteste Teil einer SAP-B1-Anbindung ist selten die API, sondern die Frage, wie WooCommerce ein großes, sich häufig änderndes Sortiment überhaupt trägt. WordPress speichert Produktattribute standardmäßig als Schlüssel-Wert-Paare in der Tabelle wp_postmeta, einem Entity-Attribute-Value-Modell. Bei einem industriellen Distributionssortiment mit 50.000 aktiven Artikeln, jeweils dutzenden Attributen und mehreren täglichen Preisaktualisierungen aus SAP wächst diese eine Tabelle auf viele Millionen Zeilen. Jede Filterabfrage im Shop und jede Preisaktualisierung wird dann zu einem teuren Join über diese Tabelle, und unter gleichzeitiger Schreiblast entstehen MySQL-Deadlocks und 504-Timeouts, die der Kunde als hängende Kategorieseite erlebt.

Der Überblick auf der ERP-Übersichtsseite benennt dieses Problem. Hier wird der Fix konkret, denn er besteht aus drei ineinandergreifenden Schritten und nicht aus einem einzelnen Schalter.

• Bestellungen auf HPOS umstellen. WooCommerce speichert Bestellungen inzwischen wahlweise in eigenen, dafür gebauten Tabellen (High Performance Order Storage) statt als Beitragsobjekte in wp_posts und wp_postmeta. Für einen Shop mit hohem Bestellvolumen aus SAP-Aufträgen entlastet das die zentrale Metadatentabelle spürbar und trennt die Bestellabwicklung von der Katalogabfrage.
• Attribute und Preise in eigene indizierte Tabellen auslagern. Die für SAP-Abfragen relevanten Attribute und die kundengruppenabhängigen Preise schreiben wir nicht in wp_postmeta, sondern in dedizierte, flache MySQL-Tabellen mit passenden Indizes auf genau den Spalten, nach denen gefiltert und gebucht wird. Eine Preisaktualisierung aus SAP trifft dann eine schmale, indizierte Zeile statt eines generischen Schlüssel-Wert-Eintrags, und die Sperren bleiben kurz.
• Filter über eine Suchschicht bedienen. Statt jede Facettenabfrage gegen die Transaktionsdatenbank laufen zu lassen, aktualisiert SAP die Daten in eine Suchschicht wie Elasticsearch, und das Frontend bezieht Ergebnisse und Filter von dort. So bleibt die Katalogsuche auch bei zehntausenden Artikeln berechenbar, und die Transaktionsdatenbank ist nicht länger der Engpass jeder Kategorieseite.

Ergänzend landen die SAP-Aktualisierungen nicht direkt und synchron im Shop, sondern in einer Nachrichtenwarteschlange, aus der ein Hintergrund-Worker Stapel von einigen hundert Artikeln verarbeitet. Dadurch bleibt der Shop auch dann reaktionsfähig, wenn SAP in einem Rutsch tausende Preisänderungen liefert, etwa nach einer Wechselkursanpassung. Der wichtige Punkt ist die Reihenfolge: Zuerst wird die Datenhaltung entlastet, dann die Last abgepuffert. Wer nur einen Cache davorsetzt, ohne die Datenbankstruktur anzufassen, verschiebt das Problem nur bis zum nächsten Schreibsturm.

#Business Partner: Debitoren und Kreditoren sauber verknüpfen

In SAP Business One sind Kunden und Lieferanten keine losen Kontakte, sondern Business Partner mit einem eindeutigen Schlüssel, dem CardCode. An diesem Datensatz hängen Preisliste, Zahlungsziel, Kreditlimit, Umsatzsteuerstatus und die gesamte Beleghistorie. Für die WooCommerce-Anbindung ist der CardCode deshalb der Anker, an dem ein registrierter B2B-Kunde im Shop mit seinem SAP-Debitor verknüpft wird. Ist diese Verknüpfung sauber, gelten für den angemeldeten Kunden automatisch seine SAP-Konditionen, und jeder Auftrag landet auf dem richtigen Debitor.

Die heikle Entscheidung betrifft neue Registrierungen. Es ist selten sinnvoll, jeden anonymen Shop-Besucher automatisch als vollwertigen Debitor in SAP anzulegen, denn das flutet die Stammdaten mit Karteileichen und untergräbt die Kreditprüfung. Bewährt hat sich, eine Neuregistrierung zunächst als Interessent zu führen und erst nach einer fachlichen Freigabe im SAP-Prozess zu einem Debitor mit Zahlungsziel und Preisliste zu machen. Die Anbindung muss diesen Zwischenzustand kennen und im Shop abbilden, damit ein noch nicht freigegebener Kunde etwa nur gegen Vorkasse bestellen kann. Auf der Beschaffungsseite lassen sich auch Kreditoren spiegeln, wenn der Shop Dropshipping oder Streckengeschäfte abbildet, doch der Regelfall im Verkaufskanal ist die Debitorenseite.

#Kundengruppen-Preislisten und Sonderpreise im B2B

Der eigentliche Grund, WooCommerce überhaupt eng an SAP Business One zu koppeln, ist im B2B fast immer die Preislogik. SAP führt mehrere Preislisten und darüber hinaus Sonderpreise je Business Partner, oft mit Staffelpreisen nach Menge und mit zeitlich begrenzten Aktionskonditionen. Ein Kunde sieht im SAP-Auftrag genau den Preis, der aus seiner zugeordneten Preisliste plus etwaiger Sonderkonditionen folgt. Genau diesen Preis muss der Shop anzeigen, sonst weicht das, was der Kunde im Warenkorb sieht, von dem ab, was auf der SAP-Rechnung steht.

Die Anbindung liest deshalb für den angemeldeten Kunden die gültige Preisliste samt Staffelung und Sonderpreisen und zeigt im Shop den effektiven Preis, den SAP auch fakturieren würde. Weil diese Konditionen sich pro Kunde unterscheiden und häufig ändern, ist die Preisanzeige nicht statisch, sondern hängt an der Business-Partner-Verknüpfung und den ausgelagerten Preistabellen aus dem vorigen Abschnitt. Für nicht angemeldete Besucher legen wir bewusst fest, was sichtbar ist: entweder ein neutraler Listenpreis oder eine Login-Schranke, die den Katalog erst nach Anmeldung mit Preisen zeigt. Das ist keine reine Designfrage, denn vertrauliche B2B-Staffeln gehören nicht öffentlich und indexierbar ins Netz.

#Benutzerdefinierte Felder und Objekte (UDF und UDO) mappen

Kaum eine reale SAP-B1-Installation kommt mit den Standardfeldern aus. Unternehmen hängen benutzerdefinierte Felder (UDF) an Standardobjekte, etwa ein Feld für die Webshop-Kategorie oder die Mindestbestellmenge am Artikel, das gewünschte Lieferdatum am Auftrag oder eine Kundenreferenz am Business Partner. Für Daten, die der Standard gar nicht vorsieht, kommen benutzerdefinierte Objekte (UDO) hinzu, also eigene Tabellenstrukturen innerhalb von SAP.

Für die Anbindung ist das kein Randthema, sondern der Kern der betriebsspezifischen Logik. Ein Mapping, das nur Standardfelder überträgt, lässt genau die Informationen weg, die diesen Betrieb ausmachen. Deshalb erfassen wir zu Beginn, welche UDF und UDO fachlich relevant sind, und bilden sie ausdrücklich auf die Shop-Datenmodelle ab, sei es auf Produktattribute, auf Auftragsfelder oder auf die ausgelagerten Tabellen. Ebenso wichtig ist die Richtung: Manche UDF werden nur aus SAP gelesen, andere, etwa eine im Shop erfasste Kundenreferenz, müssen zurück in das SAP-Feld geschrieben werden, damit sie auf Auftrag und Rechnung erscheinen.

#Der Belegfluss: vom Auftrag über den Lieferschein zur Rechnung

Was einen SAP-B1-Anschluss von einer gewöhnlichen Warenwirtschaftsanbindung unterscheidet, ist die Belegkette. SAP kennt keinen einzelnen Beleg pro Verkauf, sondern eine Kette aus Kundenauftrag, Lieferschein und Ausgangsrechnung, in der jeder Beleg auf den vorherigen referenziert und eigene betriebswirtschaftliche Wirkung entfaltet. Der Lieferschein bucht den Bestand aus dem Lager aus, die Rechnung erzeugt den Umsatz und den Buchungssatz in der Finanzbuchhaltung.

Die Anbindung respektiert diese Kette, statt sie zu umgehen. Eine bezahlte WooCommerce-Bestellung wird zum Kundenauftrag in SAP. Lieferschein und Rechnung entstehen anschließend im SAP-Prozess, häufig ausgelöst durch die Lagerabwicklung oder eine Sachbearbeitung, und ihr Status samt Sendungsnummer und Rechnungsnummer fließt zurück in den Shop und in die Kundenkommunikation. Der Shop schreibt also nicht eigenmächtig eine Rechnung, sondern spiegelt den Stand der SAP-Belegkette. Das ist der Unterschied, an dem viele naive Anbindungen scheitern: Sie erzeugen im Shop eine Rechnung, die dann nie zur SAP-Buchhaltung passt.

Dieser Rückfluss muss gefahrlos wiederholbar sein. Ein Timeout nach dem Anlegen eines Auftrags beweist nicht, dass SAP ihn abgelehnt hat, und ein blinder Wiederholungsversuch kann einen doppelten Auftrag erzeugen. Deshalb vergeben wir eine stabile externe Referenz je Bestellung, prüfen vor einem erneuten Versand über den CardCode und diese Referenz, ob der Auftrag bereits existiert, und speichern die Bestätigung aus SAP. Teillieferungen, Stornierungen, Gutschriften und Anzahlungsrechnungen werden ausdrücklich als Fälle der Belegkette modelliert und nicht als nachträglicher Sonderfall behandelt.

#Chargen und Seriennummern, wenn das Sortiment sie verlangt

In vielen industriellen und regulierten Sortimenten reicht die Artikelnummer nicht aus, weil SAP Business One Bestand nach Chargen oder Seriennummern führt. Eine Charge bündelt gleichartige Einheiten mit gemeinsamem Herkunfts- oder Haltbarkeitsmerkmal, eine Seriennummer identifiziert das einzelne Stück. Wo diese Verwaltung aktiv ist, kann ein Lieferschein nicht ohne die Zuordnung der konkreten Charge oder Seriennummer gebucht werden.

Für die Anbindung heißt das, dass die Bestandssicht im Shop auf Artikelebene bleibt, die Belegbuchung in SAP aber die Chargen- oder Seriennummernebene bedient. Der Shop zeigt, ob und wie viel lieferbar ist, während die Auswahl der konkreten Charge im SAP-Prozess erfolgt, meist bei Lieferschein und Rechnung. Für rückverfolgungspflichtige Waren spiegeln wir die zugeteilte Charge oder Seriennummer in den Belegrückfluss, damit sie in der Kundenkommunikation und in etwaigen Garantie- oder Rückrufprozessen verfügbar ist. Diese Ebene bewusst zu ignorieren ist einer der häufigsten Gründe, warum eine ansonsten korrekte Anbindung an der ersten realen Lieferschein-Buchung scheitert.

#Zwei Fälle aus der Praxis

Industriedistributor mit 60.000 Artikeln und stündlichen Preisen. Ein technischer Großhändler pflegte in SAP Business One rund 60.000 aktive Artikel mit dutzenden Attributen und aktualisierte Einkaufs- und Verkaufspreise mehrfach täglich, sobald sich Wechselkurse bewegten. Im ursprünglichen WooCommerce-Setup lagen alle Attribute in wp_postmeta, und jede Preiswelle aus SAP führte zu Deadlocks und Timeouts auf den Kategorieseiten. Wir stellten Bestellungen auf HPOS um, lagerten Attribute und kundengruppenabhängige Preise in eigene indizierte Tabellen aus und legten Elasticsearch als Suchschicht vor die Filter. Die Preisaktualisierungen laufen seither über eine Warteschlange in Stapeln in die schmalen Preistabellen, statt synchron die zentrale Metadatentabelle zu sperren. Die Kategorieseiten blieben auch während der stündlichen Preiswellen bedienbar, weil die schnelle Lesesicht von der Schreiblast entkoppelt war.

B2B-Händler mit kundenindividuellen Preislisten und falscher Fakturierung. Ein Händler für Ersatzteile führte in SAP Business One je Kunde eigene Preislisten mit mengenabhängigen Staffeln und zeitlich begrenzten Sonderkonditionen. Der alte Shop zeigte einen pauschalen Listenpreis, während SAP beim Auftrag den kundenindividuellen Preis rechnete. Kunden sahen also im Warenkorb einen anderen Betrag als später auf der Rechnung, was zu Reklamationen und manueller Nacharbeit im Innendienst führte. Die Lösung war, jeden angemeldeten Kunden über den CardCode mit seinem SAP-Debitor zu verknüpfen, die gültige Preisliste samt Staffel und Sonderpreisen in die ausgelagerten Preistabellen zu übernehmen und im Shop genau den effektiven SAP-Preis anzuzeigen. Für nicht angemeldete Besucher wurde eine Login-Schranke gesetzt, damit die vertraulichen Staffeln nicht öffentlich sichtbar waren. Die Differenz zwischen Warenkorb und Rechnung verschwand, weil der Shop keine zweite Preiswahrheit mehr aufbaute.

#Wann SAP das führende System bleibt und wann WooCommerce entkoppelt wird

Die ehrliche Regel lautet: In den meisten Fällen bleibt SAP Business One die führende Quelle für Stammdaten, Preise, Bestand und Belege, weil dort die betriebswirtschaftliche und buchhalterische Wahrheit liegt. Der Shop ist der Verkaufskanal, der SAP mit Aufträgen versorgt und Preise, Bestand und Belegstatus übernimmt. Solange die Frontend-Last überschaubar ist und SAP zuverlässig antwortet, ist eine direkte, gut abgesicherte Synchronisation über den Service Layer die einfachste tragfähige Architektur.

Bei sehr hoher Frontend-Last oder einer Headless-Architektur wird der Shop bewusst von SAP entkoppelt. Dann liegt vor SAP eine eigene Datenbank mit den ausgelagerten Tabellen und eine Suchschicht, die das Frontend bedient, auch wenn SAP gerade ein Wartungsfenster hat oder unter Last steht. Wichtig ist die Rollenverteilung: SAP bleibt die Wahrheit, die entkoppelte Schicht ist eine schnelle, regelmäßig und idempotent abgeglichene Kopie, kein zweites führendes System. Diese Entkopplung ist Aufwand, der sich erst ab einer gewissen Last und Sortimentsgröße rechnet, und wir empfehlen sie nicht pauschal. Für die tiefer gehenden Architekturmuster bei großen Volumina, etwa Queueing, Caching und eine entkoppelte Lesesicht, beschreiben wir das Vorgehen unter Enterprise-Lösungen.

#Was in Ihre Anfrage gehört

Damit wir ein abgegrenztes Angebot statt einer Schätzung liefern können, helfen uns: die Zahl der aktiven Artikel und die Häufigkeit der Preisänderungen, die SAP-Grundlage (HANA oder SQL Server) und ob der Service Layer verfügbar ist, die Preislogik im B2B (Preislisten, Staffeln, Sonderpreise), die relevanten benutzerdefinierten Felder und Objekte, die Frage nach Chargen- oder Seriennummernführung sowie ein technischer Ansprechpartner auf SAP-Seite. Geht es Ihnen zunächst um Aufbau, Performance und Pflege des Shops selbst, ist WooCommerce-Entwickler der richtige Ausgangspunkt; für die breitere Einordnung aller ERP-Fälle bleibt die ERP-Übersichtsseite der Startpunkt. Wir sagen im Scoping klar, ob ein direkter Service-Layer-Anschluss genügt oder ob Ihr Volumen die entkoppelte Architektur rechtfertigt.