Wer: Mariusz Szatkowski und das WPPoland-Team, WooCommerce-Entwickler, die Shops im DACH-Raum an Microsoft Dynamics 365 Business Central anbinden.
Was: Eine belastbare Schnittstelle zwischen WooCommerce und Dynamics 365 Business Central, bei der Business Central der alleinige Bestandsmaster über Shop, Marktplatz und Kasse bleibt, mit Item- und Variantenmapping, Buchung über Sachkonten und Dimensionen sowie Reservierung gegen Negativbestand.
Wo: Remote für Händler in Deutschland, Österreich und der Schweiz. Wir binden die APIs des Business-Central-Setups an, das Sie bereits betreiben, ohne Ihr ERP umzubauen.
Wie viel: Individuelles Angebot, nachdem wir Lagerorte, Kanäle, API-Strategie und die vorhandene Business-Central-Konfiguration erfasst haben. Wir beginnen mit einer kurzen Scoping-Analyse.
WooCommerce Dynamics 365 Business Central Anbindung für Omnichannel
Diese Seite behandelt einen konkreten technischen Fall: die Anbindung von WooCommerce an Microsoft Dynamics 365 Business Central. Nicht den allgemeinen Shop-Aufbau, sondern die Datenschicht, die Bestand, Aufträge und Buchung über Shop, Marktplatz und Ladenkasse in Einklang hält, mit einer einzigen Bestandswahrheit im ERP.
Wenn Sie eine breitere Einordnung aller Warenwirtschafts- und ERP-Szenarien suchen, beginnen Sie beim Überblick WooCommerce-Integrationen mit ERP-Systemen. Dort steht Business Central neben SAP Business One, JTL-Wawi und Odoo als ein Fall unter vielen, mit der Grundhierarchie und der Redis-Idee kurz umrissen. Hier gehen wir gezielt tiefer in die Business-Central-spezifischen Fragen, die im Überblick nur angerissen werden: die Wahl zwischen Standard-API und eigener AL-Page, das Item- und Variantenmodell, die Buchung über Dimensionen, die Nummernserien und die genaue Mechanik der Reservierung.
Wen Sie beauftragen
- Kommerzielles WordPress seit 2006, vor Gutenberg und der REST API
- Senior-geführt: der Ingenieur aus dem Discovery ist auch in Woche sechs am Code
- Kein Offshore-Handoff, keine PM-Schicht in Rechnung gestellt
- WordCamp-Europe-Organisator, WordPress Foundation Credits Mentor
Was Business Central ist und warum die WooCommerce-Anbindung anders läuft
Microsoft Dynamics 365 Business Central ist das Cloud-ERP von Microsoft für mittelständische Unternehmen, hervorgegangen aus Navision. Es führt Artikelstämme, Bestand über einen oder mehrere Lagerorte, Einkauf, Verkaufsaufträge, Rechnungen und die komplette Finanzbuchhaltung mit Sachkonten und Dimensionen. Für viele Händler im DACH-Raum ist Business Central das operative und buchhalterische Rückgrat, in dem die Wahrheit über Bestand, Preise und Erlöse liegt. WooCommerce ist in diesem Bild ein Verkaufskanal, nicht die Datenquelle.
Der Unterschied zu einer reinen Warenwirtschaftsanbindung ist, dass Business Central Bestand und Buchhaltung in einem System vereint. Eine Bestellung, die den Shop verlässt, berührt hier nicht nur die Lagermenge, sondern erzeugt beim Buchen auch einen Finanzvorgang auf einem Erlöskonto und auf Dimensionen. Wer die Anbindung nur als Bestandssynchronisation denkt, unterschätzt genau die Hälfte, die am Quartalsende zählt: dass jeder Auftrag am richtigen Konto und an der richtigen Kostenstelle landet.
Daraus entsteht der Bedarf für eine saubere Anbindung. Der Shop soll zeigen, was tatsächlich lieferbar ist, zum Preis, den das ERP vorgibt, und jede bezahlte Bestellung soll als Auftrag in Business Central buchen, ohne dass jemand Zahlen doppelt pflegt oder Bestellungen von Hand nachträgt. Ohne verlässliche Schnittstelle entstehen genau die Fehler, die im Omnichannel-Handel am teuersten sind: Überverkäufe über Kanäle hinweg, negative Bestände und Umsätze, die auf dem falschen Konto liegen.
Business-Central-APIs, Standard-OData v2.0 oder eigene AL-API-Pages
Business Central stellt seine Daten über eine REST-Schnittstelle bereit, praktisch über OData in der Version 2.0. Microsoft liefert dafür Standard-API-Pages aus, die die häufigen Objekte abdecken: Artikel, verfügbaren Bestand, Verkaufsaufträge, Debitoren, Preise. Für einen klar strukturierten Fall ist das der schnellste Weg. Ein Lagerort, überschaubare Variantenzahl, eine Preislogik, die der Standard kennt, und der Shop kann direkt gegen die ausgelieferten Endpunkte arbeiten. Alles Weitere wäre unnötiger Aufwand.
Der Standard hat allerdings Grenzen, die bei wachsenden Setups sichtbar werden. Er bildet die Standardobjekte ab und liefert sie so, wie Microsoft sie geschnitten hat, nicht so, wie Ihr Shop sie braucht. Braucht die Verfügbarkeitsanzeige einen über mehrere Lagerorte aggregierten Bestand, muss der Client mehrere Standardaufrufe zusammensetzen und selbst rechnen. Hängt der Preis von Kundengruppe und Aktionszeitraum ab, oder soll eine Rückmeldung Felder aus mehreren Tabellen in einem Aufruf bündeln, wird die reine Standard-Nutzung umständlich und langsam, weil sie viele kleine Aufrufe erzwingt.
Hier setzt eine eigene AL-API-Page an. AL ist die Entwicklungssprache von Business Central, und eine API-Page ist ein selbst entwickelter Endpunkt, der genau die Felder liefert, die der Shop braucht, in genau einem Aufruf. Ein aggregierter verfügbarer Bestand über alle Lagerorte, eine kanalabhängige Preisfindung, eine kombinierte Antwort aus Item, Variant und Reservierungsstatus, all das lässt sich als AL-API-Page kapseln, sodass die Geschäftslogik im ERP liegt und nicht im Shop nachgebaut wird. Für tiefer gehende Architekturmuster bei großen Volumina, etwa Queueing und Caching vor der API, siehe die Enterprise-Lösungen.
Die ehrliche Regel lautet: Nutzen Sie die Standard-OData-Endpunkte, solange sie passen, und bauen Sie eine eigene AL-API-Page erst dort, wo eine konkrete Anforderung sie verlangt. Eine AL-Page ist Entwicklungsaufwand im ERP, den ein einfacher Shop nicht braucht, der einem komplexen Omnichannel-Setup aber viele fragile Client-seitige Zusammenbauten erspart. Wir entscheiden das nach einem kurzen Scoping und nicht nach Prinzip.
Die Omnichannel-Hierarchie, Business Central als alleiniger Master
Sobald ein Händler über mehrere Kanäle verkauft, entscheidet die Bestandshierarchie über alles Weitere. Das typische Bild ist ein Sortiment, das gleichzeitig über den eigenen WooCommerce-Shop, über Marktplätze via BaseLinker und über eine oder mehrere Ladenkassen verkauft wird. Alle diese Kanäle greifen auf denselben physischen Bestand zu, der in Business Central geführt wird.
Der Grundsatz ist einfach und kompromisslos: Business Central ist der alleinige Bestandsmaster, WooCommerce, BaseLinker und POS sind nachgelagerte Kanäle, die eine Sicht auf diesen einen Bestand zeigen und ihn niemals unabhängig fortschreiben. Kein Kanal hält seinen eigenen Wahrheitsstand. Jede Bestandsänderung, ob ein Verkauf im Laden, eine Bestellung im Shop oder ein Wareneingang, wird gegen Business Central verrechnet, und die anderen Kanäle bekommen das Ergebnis, nicht ihre eigene Rechnung.
Der Grund für diese Strenge ist die Sync-Schleife. Erlaubt man zwei Systemen, denselben Bestand zu verändern und sich gegenseitig zu aktualisieren, entstehen Rückkopplungen: Kanal A meldet an B, B meldet die Änderung zurück an A, und bei jeder Verzögerung driften die Zahlen auseinander. Eine klare Master-Slave-Richtung unterbindet das, weil die Aktualisierung immer nur in eine Richtung fließt, von Business Central zu den Kanälen, und der Rückweg ausschließlich als Auftrag oder Reservierung geführt wird, nicht als konkurrierende Bestandswahrheit.
Der Redis-Verfügbarkeits-Cache und seine ehrliche Grenze
Die Business-Central-API ständig für jede Verfügbarkeitsprüfung abzufragen, skaliert bei hoher Kanalfrequenz nicht. Zwischen Shop, Marktplätzen und Kasse können pro Minute viele Prüfungen anfallen, und jede davon direkt an das ERP zu schicken, belastet die API und kostet Antwortzeit. Deshalb kann eine kurzlebige Verfügbarkeitssicht in Redis vor Business Central treten, als schneller Puffer, den jeder Kanal vor dem Abschluss eines Warenkorbs liest.
Diese Sicht wird ereignisgesteuert aktuell gehalten. Ein Verkauf im Laden oder ein Wareneingang löst in Business Central einen Webhook aus, der die betroffene verfügbare Menge in Redis anpasst. So sieht der Shop nahezu in Echtzeit, dass die letzte Einheit gerade an der Kasse verkauft wurde, ohne dass er selbst das ERP fragen muss. Der Cache trägt die schnelle Antwort, das ERP die verbindliche Wahrheit.
An dieser Stelle ist Ehrlichkeit wichtiger als jede Eleganz: Kein Cache garantiert, dass jeder externe Kanal tatsächlich aktualisiert wurde. Ein Webhook kann verloren gehen, ein Kanal kann kurz nicht erreichbar sein, eine Aktualisierung kann verzögert eintreffen. Die Redis-Sicht macht die Prüfung schnell, aber sie ersetzt weder die Reservierung beim Checkout noch den regelmäßigen Abgleich gegen Business Central. Wir setzen den Cache deshalb als Beschleuniger ein, nicht als Ersatz für die Wahrheit im ERP, und behandeln jede Abweichung zwischen Cache und Business Central als das, was sie ist: ein zu meldender Drift, nicht ein Kanal, der recht hat.
Item, Variant und die Dimensionen-Zuordnung
Der häufigste Stolperstein einer Business-Central-Anbindung ist das Mapping variabler Produkte. WooCommerce modelliert ein variables Produkt als ein Elternprodukt mit mehreren Variationen, jede mit eigener SKU. Business Central kennt dafür in der Regel ein Item mit mehreren Variant-Codes, jeder mit eigener Nummer, eigenem verfügbaren Bestand und meist eigener EAN. Beide beschreiben dieselbe Realität mit unterschiedlicher Struktur, und genau an dieser Bruchstelle entstehen die typischen Fehler.
Ein sauberes Mapping braucht einen stabilen Schlüssel, der einen Variant-Code eindeutig mit einer WooCommerce-Variation verbindet, in der Regel die Artikelnummer oder die EAN. Ändert sich dieser Schlüssel im laufenden Betrieb, etwa weil im ERP ein Variant-Code angepasst wird, verliert die Zuordnung ihren Anker, und Bestand oder Preis landen auf der falschen Variation. Deshalb legen wir im Datenvertrag ausdrücklich fest, welches System den Schlüssel führt und ob er überhaupt geändert werden darf.
Für Attribute jenseits der reinen Variante lohnt der Blick auf Dimensionen. Business Central nutzt Dimensionen als querliegende Merkmale für die Auswertung, etwa Verkaufskanal, Marke, Region oder Kostenstelle. Statt solche Merkmale in den Artikelstamm zu pressen oder künstliche Varianten zu erzeugen, bildet man sie über Dimensionswerte ab, die bei der Buchung mitlaufen. Für den Shop bedeutet das, dass die Schnittstelle je Kanal die passenden Dimensionswerte setzt, damit ein WooCommerce-Verkauf später ohne Nacharbeit vom Marktplatz- und vom Ladenumsatz unterscheidbar bleibt.
Sachkonten und Dimensionen beim Buchen
Die Bestandssynchronisation ist nur die eine Hälfte, die andere ist der Auftrags- und Buchungsrückfluss. Eine bezahlte WooCommerce-Bestellung wird zum Verkaufsauftrag in Business Central, und beim Buchen entstehen die Finanzvorgänge: der Umsatz auf einem Erlöskonto, die Umsatzsteuer auf dem passenden Steuerkonto, die Forderung auf dem Debitorenkonto. Für den Shop ist wichtig, dass diese Buchung nicht nebenbei passiert, sondern gesteuert wird.
Der Hebel dafür sind die Dimensionen. Bucht der Auftrag mit den richtigen Dimensionswerten, etwa Kanal gleich Onlineshop und Kostenstelle gleich E-Commerce, lässt sich am Monatsende ohne manuelle Trennung auswerten, welcher Umsatz aus WooCommerce, welcher vom Marktplatz und welcher aus dem Laden stammt. Fehlen diese Dimensionen oder werden sie falsch gesetzt, liegen alle Kanäle auf einem Topf, und die Aufteilung muss von Hand aus den Bestellungen rekonstruiert werden, genau die Art Nacharbeit, die eine Anbindung eigentlich abschaffen soll.
Ebenso zu klären ist die Frage nach dem Debitor. Ein Endkundenshop führt selten für jeden Käufer ein eigenes Debitorenkonto in Business Central. Üblich ist ein Sammeldebitor je Kanal oder Zahlungsart, auf dem die Umsätze gebündelt buchen, während echte B2B-Stammkunden ein Einzeldebitorenkonto erhalten. Die Schnittstelle muss wissen, welcher Fall wann gilt, damit die Debitorenbuchhaltung nicht mit tausenden Einmalkäufern überläuft. Auch das legen wir im Datenvertrag fest, bevor der erste Auftrag bucht, und nicht erst, wenn die offene-Posten-Liste unübersichtlich geworden ist.
Nummernserien und die Negativbestand-Race zwischen Shop, Marktplatz und Kasse
Business Central vergibt Belegnummern über Nummernserien, getrennt etwa für Verkaufsaufträge und gebuchte Rechnungen. Bei parallelen Kanälen ist entscheidend, dass jede Bestellung genau einen Auftrag erzeugt. Der gefährliche Ablauf ist banal: Der Shop übergibt eine Bestellung, die Antwort bleibt wegen eines Timeouts aus, ein blinder Wiederholungsversuch schickt dieselbe Bestellung erneut, und die Nummernserie vergibt pflichtschuldig eine zweite Auftragsnummer für denselben Verkauf. Aus einem Netzwerkhänger wird ein doppelter Auftrag.
Die Gegenmaßnahme ist eine idempotente Übergabe. Wir vergeben je Bestellung eine stabile externe Referenz, prüfen vor jedem erneuten Versand, ob in Business Central bereits ein Auftrag mit dieser Referenz existiert, und speichern die Bestätigung. Ein Timeout beweist nicht, dass das ERP die Bestellung abgelehnt hat, also darf ein Wiederholungsversuch nicht einfach neu anlegen, sondern muss zuerst nachsehen. Die Nummernserie bleibt dabei der ERP-interne Mechanismus, unsere Sicherung liegt eine Ebene davor, in der externen Referenz.
Der zweite kritische Fall ist die Negativbestand-Race über die Kanäle. Ein Artikel ist genau einmal vorrätig. Ein Kunde legt ihn im WooCommerce-Shop in den Warenkorb, im selben Moment scannt ihn die Kasse für einen Laufkunden, und eine Sekunde später bestellt jemand denselben Artikel über einen Marktplatz, bevor die Bestandsänderung über alle Kanäle propagiert ist. Ohne klare Hierarchie und ohne Reservierung verkaufen alle drei dieselbe Einheit, und in Business Central entsteht ein negativer Bestand. Bei einem Marktplatz beschädigt eine daraus folgende Stornierung zusätzlich die Verkäuferkennzahlen. Der schnelle Redis-Cache verkürzt das Zeitfenster, schließt es aber nicht, denn zwischen Prüfung und Abschluss bleibt immer ein Moment. Erst die Reservierung schließt es wirklich.
Reservierungslogik, damit die letzte Einheit nur einmal verkauft wird
Reservierung ist der Mechanismus, der aus einer schnellen Verfügbarkeitsanzeige eine belastbare Zusage macht. Prüfen allein genügt nicht, weil zwischen der Prüfung und dem tatsächlichen Abschluss immer ein kurzer Moment liegt, in dem ein anderer Kanal dieselbe Einheit greifen kann. Reservierung bedeutet, dass die betroffene Menge beim Checkout aktiv gesperrt wird, sodass sie für die Dauer des Vorgangs keinem anderen Kanal mehr zur Verfügung steht.
Praktisch reserviert die Schnittstelle beim Beginn eines verbindlichen Checkouts die Menge gegen Business Central oder gegen eine dem ERP nachgelagerte Reservierungslogik und hält sie für ein definiertes Zeitfenster. Wird der Kauf abgeschlossen, geht die Reservierung in einen Auftrag über. Bricht der Kunde ab oder läuft das Fenster ab, wird die Reservierung freigegeben und die Menge kehrt in den verfügbaren Bestand zurück. So wird verhindert, dass eine noch offene, aber schon angebahnte Bestellung parallel auf einem anderen Kanal verkauft wird.
Die Reservierung wird durch idempotente Bestandsupdates ergänzt, damit doppelt eintreffende Meldungen nicht doppelt buchen, und durch einen regelmäßigen Abgleich, der Drift zwischen der schnellen Sicht und dem ERP-Bestand aufdeckt und meldet. Dieser Dreiklang, strikte Hierarchie, Reservierung und Abgleich, ist der eigentliche Kern einer belastbaren Omnichannel-Anbindung. Der Cache macht sie schnell, die Reservierung macht sie korrekt, und der Abgleich macht sie ehrlich, indem er zeigt, wo schnelle Sicht und Wahrheit doch einmal auseinandergelaufen sind.
Zwei Fälle aus der Praxis
Negativbestand zwischen Shop, Marktplatz und Ladenkasse. Ein Einzelhändler mit einem Ladengeschäft und einem WooCommerce-Shop verkaufte zusätzlich über Marktplätze via BaseLinker, mit dem Bestand in Business Central. Bei knappen und teils einzelstückigen Artikeln kam es wiederholt zu negativen Beständen: Die letzte Einheit wurde im Laden über die Kasse verkauft, und Sekunden später bestellte ein Kunde denselben Artikel im Shop oder auf einem Marktplatz, bevor die Änderung propagiert war. Die Folge waren Stornierungen und belastete Marktplatzkennzahlen. Wir setzten eine strikte Hierarchie durch, in der Business Central der alleinige Bestandsmaster ist und WooCommerce, BaseLinker und POS nachgelagerte Kanäle sind, ergänzt um eine kurzlebige Redis-Verfügbarkeitssicht, die jeder Kanal vor dem Abschluss prüft, sowie um Reservierung beim Checkout und einen nächtlichen Abgleich. Die negativen Bestände verschwanden nicht durch den Cache allein, sondern durch die klare Hierarchie plus Reservierung.
Aggregierter Bestand und langsame Standard-API bei großem Katalog. Ein Händler mit mehreren Lagerorten und einem umfangreichen Sortiment band den Shop zunächst über die Standard-OData-Endpunkte an. Für jede Verfügbarkeitsanzeige musste der Shop den Bestand mehrerer Lagerorte einzeln abfragen und selbst aufsummieren, was bei jeder Kategorieseite viele kleine Aufrufe erzeugte und die Seiten träge machte. Wir entwickelten eine eigene AL-API-Page, die den über alle Lagerorte aggregierten verfügbaren Bestand je Item und Variant in einem einzigen Aufruf liefert, zusammen mit dem Reservierungsstatus. Die Zahl der API-Aufrufe je Seite sank deutlich, die Verfügbarkeitsanzeige wurde schnell und verlässlich, und die Aggregationslogik lag dort, wo sie hingehört, im ERP, statt fragil im Shop nachgebaut zu sein.
Wann Business Central Master bleibt und wann nicht
Eine individuelle WooCommerce-Business-Central-Anbindung lohnt sich, wenn mindestens einer dieser Punkte zutrifft:
- Sie verkaufen über mehrere Kanäle parallel, WooCommerce, Marktplätze über BaseLinker und eine Ladenkasse, und hatten bereits Überverkäufe oder negative Bestände.
- Sie führen den Bestand über mehrere Lagerorte und brauchen einen aggregierten verfügbaren Bestand, den die Standard-API nur umständlich liefert.
- Sie wollen Erlöse je Kanal über Dimensionen sauber getrennt buchen, statt sie am Monatsende von Hand aufzuteilen.
- Ihr Katalog ist groß, die Standard-Endpunkte erzeugen viele kleine Aufrufe, und die Verfügbarkeitsanzeige wird dabei zu langsam.
- Sie brauchen kanalabhängige Preis- oder Buchungslogik, die der ausgelieferte Standard nicht kennt.
Der Grundsatz, dass Business Central Master bleibt, gilt fast immer, aber nicht bedingungslos. Er gilt, solange der physische Bestand, die Auftragsabwicklung und die Buchhaltung im ERP liegen, und das ist der Regelfall im Omnichannel-Handel. Wo Business Central Master bleibt, darf kein Kanal seinen eigenen Bestand fortschreiben, und der Rückweg vom Shop ins ERP führt ausschließlich über Auftrag und Reservierung.
Umgekehrt ist die individuelle Schnittstelle Aufwand, den Sie sich sparen können, wenn Ihr Setup schlicht ist: ein Kanal, ein Lagerort, überschaubare Variantenzahl, eine Preislogik, die der Standard abdeckt. In diesem Fall reichen die ausgelieferten OData-Endpunkte, und wir würden Ihnen davon abraten, eine eigene AL-API-Page und eine Cache-Schicht für einen Bedarf zu bauen, den Sie nicht haben. Der ehrliche Weg beginnt mit der Frage, welche Ihrer heutigen Fehler Geld kosten, und nicht mit der Frage, wie viel Technik möglich ist.
Wenn Sie über die reine Business-Central-Anbindung hinaus allgemeine Weiterentwicklung Ihres Shops brauchen, etwa Performance, Erweiterungen oder Wartung, ist die Seite WooCommerce-Entwickler der richtige Ausgangspunkt.
