WooCommerce-Integrationen mit ERP- und Großhandels-APIs

#WooCommerce-Integrationen mit ERP- und Großhandels-APIs

Wenn Sie allgemeine Unterstützung beim Aufbau und Wachstum eines Shops benötigen, beginnen Sie mit der Seite WooCommerce-Entwickler. Auf dieser Seite geht es um ein engeres, technischeres Problem: den Datenaustausch zwischen WooCommerce und externen Systemen.

#Was eine WooCommerce-Integration wirklich ist

In den meisten Shops liegt die Wahrheit über die Produkte nicht in WooCommerce. Sie liegt im ERP, im Lagersystem oder in einer Großhandels-API. WooCommerce ist die Verkaufsfront, doch Bestand, Preise und ein Teil der Produktdaten stammen von anderswo. Eine Integration ist die Schicht, die diese beiden Welten in Einklang hält.

In der Praxis beantwortet eine Integration drei Fragen:

• Was wir synchronisieren - Katalog, Attribute, Bestände, Preise, Bestellungen, Kundendaten.
• In welche Richtung - einseitig (das Quellsystem gibt dem Shop vor) oder beidseitig (zum Beispiel fließen Bestellungen zurück ins ERP).
• Wie oft - vom geplanten Abruf alle paar Minuten bis zu ereignisgesteuerten Aktualisierungen über Webhooks.

#Was Sie mit WooCommerce integrieren können

Sie müssen nicht alles auf einmal umsetzen. Der häufigste erste Schritt ist die Bestands- und Preissynchronisation, weil sie sich am schnellsten auszahlt - durch eingesparte Support-Zeit und vermiedene Rückerstattungen.

#Wie die Datensynchronisation funktioniert

Die Mechanik ist überall ähnlich, egal ob die Quelle ein ERP oder eine Großhandels-API ist. Die Quelle unterscheidet sich, nicht das Prinzip.

#Datenmapping

Das Quellsystem beschreibt Produkte mit seiner eigenen Feldstruktur. Die erste Aufgabe einer Integration ist es, diese in das Produkt- und Attributmodell von WooCommerce zu übersetzen: EAN und Index als Schlüssel, die Datensätze verknüpfen, technische Attribute auf Attribute und Variationen, Medien und Beschreibungen auf Produktseiten. Wir halten die Feldzuordnung deklarativ, sodass ein neuer Parameter eine Erweiterung des Mappings bedeutet und keine Umschreibung der Logik.

#Bestands- und Preissynchronisation

Der Kern der meisten Integrationen ist der geplante Abruf zweier Dinge: Bestand und Preis. Im Quellsystem nicht verfügbare Artikel werden automatisch ausgeblendet oder als nicht verfügbar markiert, was den teuersten Fehler eines Shops beseitigt - etwas zu verkaufen, das nicht ausgeliefert werden kann. Eine Preisänderung im Quellsystem wird beim nächsten Zyklus in den Shop übertragen.

#Margenlogik

Preise aus einem ERP oder Großhandel sind meist Einkaufspreise, nicht der Verkaufspreis. Über der Datenabrufschicht sitzt die Margenlogik: Das System wendet eine definierte Marge auf den Quellpreis an, und nur das Ergebnis erreicht WooCommerce. Der Inhaber steuert die Rentabilität mit Regeln, nicht durch manuelles Bearbeiten von Preisen.

#Eine echte Integration

Dieselbe Mechanik steckt hinter unserem Projekt für einen Kfz-Teile-Shop, der direkt an eine REST-API eines Großhändlers angebunden ist: WooCommerce-Integration mit Großhandels-API. Dort halten sich Katalog, Bestand und Preise selbst aktuell, und die Marge schützt die Rentabilität gegen eine sich ständig ändernde Lieferantenliste.

#Mit welchen ERP-Systemen wir integrieren

Eine wichtige Unterscheidung: Wir integrieren WooCommerce mit der API dieser Systeme, wir implementieren nicht das ERP selbst. Das ist WordPress-, PHP- und Datenaustausch-Arbeit, keine ERP-Beratung.

• Cloud-ERP: Microsoft Dynamics 365 Business Central, SAP Business One, Oracle NetSuite, Odoo. Diese stellen REST-APIs bereit, was die Shop-Anbindung sauber hält.
• Buchhaltung und ERP im DACH-Raum: Systeme wie DATEV, Lexware oder Sage, je nach Betrieb, meist über ihre API oder eine Middleware-Schicht integriert. Für DATEV im Detail: WooCommerce DATEV Schnittstelle.

Wenn Ihr System nicht auf der Liste steht, aber über eine API oder einen Datenexport verfügt, lässt es sich in der Regel integrieren.

#Wie wir Integrationen für konkrete ERP-Systeme architektonisch aufbauen

Jedes ERP hat seine eigene API, sein eigenes Datenformat und seine eigenen Fallstricke. Nachfolgend beschreiben wir, wie wir an die häufigsten Systeme herangehen. Das sind Architekturmuster, kein für ein paar Euro gekauftes Plugin.

#SAP Business One - Skalierung und das wp_postmeta-Problem

Industrielle Distribution: Zehntausende aktive Produkte, häufige Preisaktualisierungen (mehrmals täglich, wenn sich Wechselkurse bewegen), Hunderte von Attributen. Die standardmäßige EAV-Struktur von WordPress speichert jedes Attribut in wp_postmeta, was bei diesem Umfang auf Millionen von Zeilen anschwillt; Echtzeit-Preisaktualisierungen verursachen dann MySQL-Deadlocks und 504-Timeouts für Käufer.

• HPOS und eigene Tabellen: Wir schreiben Attribute nicht mehr in wp_postmeta, sondern verwenden eine dedizierte flache MySQL-Tabelle, die für SAP-B1-Abfragen gebaut ist.
• Elasticsearch als Suchschicht: SAP aktualisiert Daten per API in Elasticsearch, und das Frontend bezieht Ergebnisse und Filter von dort, statt jede Filterabfrage an die Transaktionsdatenbank zu senden. Ziel ist eine berechenbare Katalogsuche auch bei umfangreichen Sortimenten.
• Queueing (RabbitMQ): SAP-Aktualisierungen landen in einer Message-Queue, und ein Hintergrund-Worker holt Stapel von jeweils einigen Hundert Produkten, sodass der Shop rund um die Uhr reaktionsfähig bleibt.

Für SAP Business One im Detail (DI-API vs. Service Layer, Business Partner, Preislisten): WooCommerce SAP Business One Anbindung.

#Microsoft Dynamics 365 (mit BaseLinker und POS)

Ein großer Einzelhändler, der über WooCommerce, Marktplätze (über BaseLinker) und Ladengeschäfte mit einem POS auf Dynamics 365 verkauft. Ohne strikte Hierarchie entstehen Sync-Schleifen und Race Conditions (die letzte Einheit wird im Laden verkauft und eine Sekunde später auf einem Marktplatz), was zu negativen Beständen führt.

• Single Source of Truth: Wir erzwingen eine Hierarchie, in der Dynamics der absolute Master ist und WooCommerce sowie BaseLinker die Slaves sind.
• Redis-Schicht: Statt die Dynamics-API ständig abzufragen, kann eine kurzlebige Verfügbarkeitssicht in Redis geführt werden. Ein Verkauf im Laden aktualisiert sie per Webhook, und WooCommerce sowie BaseLinker prüfen sie vor dem Abschluss eines Warenkorbs. Reservierungs- und Abgleichsregeln bleiben erforderlich, denn kein Cache garantiert die erfolgreiche Aktualisierung jedes externen Kanals.

Für Dynamics 365 Business Central im Detail (OData vs. AL-API-Pages, Dimensionen, Nummernserien): WooCommerce Dynamics 365 Business Central Anbindung.

#Odoo (Open Source) - Konfiguratoren für Auftragsfertigung

Hersteller konfigurieren Produkte in Odoo (eine Stückliste), wobei der Preis einer Komponente von anderen Entscheidungen abhängt. WooCommerce-Variationen können das nicht abbilden, und die Produktionslogik in PHP zu portieren erzeugt nicht wartbaren Code.

• Entkoppelter / headless Ansatz: WooCommerce ist das Warenkorb- und Transaktionssystem (Zahlung, E-Mails), während das Frontend (Astro/Vue) direkt mit der Odoo-API spricht und Preise sowie Produktionsmachbarkeit in Echtzeit abfragt. Beim “In den Warenkorb” wird ein individuelles Produkt mit einem von Odoo berechneten Preis und einem generierten Spezifikations-PDF an WooCommerce gesendet, ohne die Geschäftslogik zu duplizieren.

#Comarch Optima, InsERT Subiekt, enova365 (polnischer und CEE-Markt)

• Comarch Optima: Wenn die verfügbare Schnittstelle Änderungsinformationen bereitstellt, bauen wir eine dedizierte PHP-Middleware und nutzen differenzielle (Delta-)Synchronisation. Ein geplanter Job fragt dann nur die im letzten Zeitfenster geänderten Indizes ab, statt bei jedem Lauf den vollständigen Katalog zu importieren. B2B-Preise können aus der Rabattgruppe des Kunden berechnet werden, statt für jede mögliche Preisstufe eigene Variationen zu speichern.
• InsERT Subiekt GT / nexo: Datenaustausch über EPP und API; eine harte Reservierung sperrt den Bestand in Subiekt für einige Minuten beim Checkout, um Überverkäufe während Lastspitzen zu verhindern, und ein Korrekturbeleg löst einen Webhook aus, der die WooCommerce-Bestellung auf “retourniert” umstellt und den Artikel wieder einbucht.
• enova365: Für Produkte mit hoher Variantenzahl (Farben x Größen, jeweils mit eigener EAN) verwenden wir flache, auf JSON gemappte Varianten, die asynchron über REST geladen werden, statt Hunderttausende von product_variation-Beiträgen zu generieren.

#JTL-Wawi (Deutschland) und Holded (Spanien)

• JTL-Wawi: Omnichannel mit Mehrlager-Betrieb. Ein Logik-Routing analysiert die Postleitzahl des Kunden und wählt algorithmisch das Lager mit dem schnellsten Versand; die One-Stop-Shop-Abwicklung berechnet die Mehrwertsteuer je nach Zielland in Echtzeit neu, sodass die Rechnung in JTL den korrekten Satz trägt. WooCommerce läuft parallel zu BaseLinker für Amazon und eBay. Für JTL-Wawi im Detail: WooCommerce JTL-Wawi Anbindung.
• Holded: ein cloudbasiertes, API-first ERP - eine vollständig dateifreie Integration auf der nativen REST-API mit Token-Authentifizierung und Webhooks. Die Rechnungslogik erkennt den Warenkorbbetrag und signalisiert Holded, den korrekten Belegtyp zu generieren (zum Beispiel eine vereinfachte Rechnung für kleine Beträge), und gibt ein PDF zurück, das an die WooCommerce-E-Mail angehängt wird.

#Enterprise-Architektur: Performance und Zuverlässigkeit

Bei großem ERP-Umfang gehen wir über “ein Plugin installieren” hinaus. Das ist anspruchsvolles Engineering:

• Headless / entkoppelt: WordPress ist die Admin-Engine (Backend), und der Shop rendert in Astro oder Next.js, greift auf eine GraphQL- oder REST-API zu und umgeht langsames SQL, was den Shop schneller und widerstandsfähiger macht. Mehr dazu unter Enterprise-Lösungen.
• Asynchrone Verarbeitung (Queues): Die Synchronisation von Zehntausenden Produkten in einem einfachen PHP-Skript läuft in ein Timeout. Wir setzen dafür auf Queues (RabbitMQ oder Redis), die kleine Teilmengen im Hintergrund verarbeiten.
• Fehlerbehandlung und Logging: Wenn die ERP-API nicht antwortet, blockieren wir den Checkout mit einer Meldung, statt Bestellungen ins Leere anzunehmen; ein vollständiges Fehler-Logging ermöglicht eine schnelle Diagnose.

#Technische Probleme, die wir lösen

• API-Rate-Limiting (429): Cloud-Systeme begrenzen Anfragen. Wir implementieren exponentielles Backoff (bei einem 429 wartet das Skript und versucht es erneut) sowie Chunking und packen Daten in bulk-update-JSON-Anfragen statt in Tausende von Einzelaufrufen.
• Datentyp-Unstimmigkeiten (Rundung): Ein ERP hält Preise womöglich auf vier Nachkommastellen, während WooCommerce zwei erwartet. In der Middleware wenden wir striktes Type-Casting an und gleichen die Rundung pro Rechnungsposition ab, um Cent-Fehler zu vermeiden, die sich über Hunderte von Bestellungen aufsummieren.
• Bilder, Bandbreite und das Inode-Limit: Der Import physischer Bilder in die WordPress-Mediathek (mit jeweils mehreren generierten Thumbnails) erschöpft das Dateilimit des Servers. Stattdessen liefern wir Bilder aus externem Speicher (Amazon S3 oder Cloudflare Image Resizing) über URLs aus, die aus dem ERP gemappt werden, was Platz spart und die Synchronisation selbst beschleunigt.

#Systemgrenzen klären, bevor Endpunkte verbunden werden

Vor der Entwicklung legen wir fest, welches System welche geschäftliche Information besitzt. Ein Diagramm mit einer Linie zwischen WooCommerce und ERP reicht nicht aus. Zu klären ist, wo Produkte angelegt werden dürfen, ob eine Artikelnummer geändert werden kann, wer Steuerklassen pflegt, wann eine Lagerreservierung verbindlich ist und welches System eine bezahlte Bestellung korrigieren darf. Können zwei Systeme dasselbe Feld unabhängig bearbeiten, braucht die Integration eine Konfliktregel und nicht einfach einen weiteren API-Aufruf.

Das Ergebnis der Analyse ist eine Systemlandkarte mit Datenvertrag. Sie benennt die führende Quelle für Produkte, Varianten, Bestand, Preise, Kunden, Bestellungen, Versand und Rechnungen. Der Datenvertrag dokumentiert Kennungen, Pflichtfelder, zulässige Werte, Richtung, Taktung, Wiederholungsverhalten sowie den Umgang mit gelöschten oder unvollständigen Datensätzen. Personenbezogene Daten und Zugangsdaten werden ausdrücklich markiert, damit sie nicht unnötig in Protokolle oder Nebensysteme gelangen.

Anschließend prüfen wir echte Abläufe mit den Personen, die täglich damit arbeiten: ein neues Produkt ohne Bild, eine geänderte Artikelnummer, Bestand in mehreren Lagern, ein kundenspezifischer B2B-Preis, eine Teillieferung, eine Erstattung und ein Ausfall der Lieferanten-API. Solche Gespräche zeigen Geschäftsregeln, die in einer API-Dokumentation meist fehlen. Gleichzeitig lässt sich ein klarer erster Lieferumfang von späteren Automatisierungen trennen.

#Fehlerbilder bei Katalog, Bestand, Preisen und Bestellungen

Eine Katalogsynchronisation kann unbemerkt scheitern. Varianten treffen womöglich vor dem Hauptprodukt ein, ein Attribut ändert seinen Datentyp, eine Bild-URL läuft ab oder zwei Datensätze verwenden dieselbe EAN. Ungültige Datensätze werden deshalb in eine Quarantäne verschoben und nicht als unvollständige Produkte veröffentlicht. Der Importbericht nennt Quelldatensatz, Validierungsfehler und mögliche Korrektur; nach der Bereinigung kann ein späterer Lauf den Datensatz sicher erneut verarbeiten.

Beim Bestand muss die Bedeutung von “verfügbar” eindeutig sein. Gemeint sein kann der physische Bestand, der Bestand nach Reservierungen oder eine Menge nach Abzug eines Sicherheitspuffers. Webhooks können doppelt oder in falscher Reihenfolge eintreffen, während ein geplanter Abruf mit einem Checkout kollidiert. Deshalb verwenden wir idempotente Nachrichten, Versions- oder Zeitprüfungen, sofern die Quelle sie unterstützt, Reservierungsregeln und einen regelmäßigen Abgleich. Für einen Quellausfall wird vorab festgelegt, ob der letzte bestätigte Bestand eingefroren, ein konservativer Puffer angewendet oder der Kauf vorübergehend verhindert wird.

Bei Preisen entstehen Risiken durch Netto- und Bruttowerte, Steuergebiet, Währung, Kundengruppe, Aktionszeitraum, Rundung und Mindestmarge. Die Berechnung erfolgt aus expliziten Eingangsdaten. Zusätzlich bleibt nachvollziehbar, welche Regelversion den angezeigten Preis erzeugt hat. Ein überraschender Preis lässt sich dadurch auf Quelldaten und Regel zurückführen, statt in einer undurchsichtigen Aktualisierung zu verschwinden.

Der Bestellexport muss gefahrlos wiederholbar sein. Ein Timeout nach dem Senden beweist nicht, dass das ERP die Bestellung abgelehnt hat; ein blinder Wiederholungsversuch kann ein Duplikat erzeugen. Wir vergeben eine stabile externe Referenz, prüfen das Ziel vor einem erneuten Versand und speichern Bestätigungen. Adressprüfung, Zahlungsstatus, Versandpositionen, Rabatte, Erstattungen, Stornierungen und Teillieferungen werden ausdrücklich modelliert. Fehlgeschlagene Vorgänge landen in einer bearbeitbaren Warteschlange und nicht nur in einem allgemeinen Log.

#Abnahmenachweise vor dem Produktivstart

Die Abnahme stützt sich auf Nachweise aus einer Staging-Umgebung und eine vereinbarte Auswahl repräsentativer Datensätze. Eine Rückverfolgbarkeitsmatrix verbindet jede Anforderung mit einem Test und dessen Ergebnis. Die Stichprobe umfasst einfache und variable Produkte, fehlende optionale Daten, Sonderzeichen, unterschiedliche Steuerbehandlungen, Bestandsgrenzen, Preisänderungen sowie den vollständigen Bestelllebenszyklus. Falls produktionsnahe Daten nicht genutzt werden dürfen, bilden anonymisierte Testdaten dieselben Strukturen und Grenzfälle ab.

Für jeden Ablauf halten wir Anfragenummer, Zeitstempel, Quell- und Zielkennung, Vorher-Nachher-Werte sowie den Ergebnisstatus fest. Wir testen doppelte Zustellung, verspätete Nachrichten, Rate-Limits, ungültige Zugangsdaten und vorübergehende Nichtverfügbarkeit. Der Abgleich muss entweder Übereinstimmung zeigen oder eine endliche Ausnahmeliste erzeugen, die ein Mitarbeiter bearbeiten kann. Leistungstests orientieren sich an der erwarteten Kataloggröße und Aktualisierungsweise, ohne Laborwerte als Garantie für den Produktivbetrieb auszugeben.

Zu den Startkriterien gehören üblicherweise freigegebene Mappings, erfolgreiche Tests der kritischen Pfade, ein geprüftes Verfahren zum Pausieren oder Zurückrollen, eingerichtetes Monitoring, klare Verantwortung für Zugangsdaten und benannte operative Ansprechpartner. Nach der Bereitstellung beobachten wir kontrolliert die ersten realen Synchronisationsläufe und Bestellungen, bevor der Umfang erweitert wird.

#Betriebshandbuch und Verantwortungsübergabe

Eine Integration wird Teil des Tagesgeschäfts. Daher ist die Übergabe ein eigenes Arbeitsergebnis und keine abschließende E-Mail. Sie umfasst Architekturübersicht, Matrix der führenden Systeme, Mapping-Referenz, Zeitpläne und Webhooks, Ablageorte der Zugangsdaten, Deployment-Hinweise, Monitoring-Regeln sowie ein Betriebshandbuch für typische Fehler. Geheimnisse verbleiben im vorgesehenen Secret Store; die Dokumentation erklärt ihre Rotation, ohne Werte offenzulegen.

Mitarbeiter lernen, ein Problem in den Quelldaten von einem Infrastrukturfehler zu unterscheiden, einen Datensatz sicher erneut zu verarbeiten, einen Datenfluss anzuhalten und die Wiederherstellung zu prüfen. Alarmstufen, Empfänger und Reaktionsverantwortung werden vereinbart. Eine Betriebsansicht sollte praktische Fragen beantworten: Wann war jeder Datenfluss zuletzt erfolgreich, wie viele Datensätze warten oder wurden abgelehnt, ist der Bestellexport aktuell und hat der Abgleich Abweichungen gefunden?

Auch spätere Änderungen brauchen einen geregelten Weg. ERP-Upgrades, neue Lager, Steueränderungen und Aktualisierungen von WooCommerce-Erweiterungen können den Vertrag verändern. Wir empfehlen, Vertragsänderungen in Staging zu testen, Mappings zu versionieren und einen kleinen Regressionstest mit repräsentativen Produkten und Bestellungen zu pflegen. Das reduziert die Abhängigkeit von einer einzelnen Person und macht Wartung nachvollziehbar.

#Was in Ihre schriftliche Anfrage gehört

Senden Sie uns den Shop-Link, ERP- oder Lieferantensystem samt Version, vorhandene API-Dokumentation, Authentifizierungsverfahren und einen technischen Ansprechpartner für das Quellsystem. Nennen Sie ungefähr die Anzahl der Produkte und Varianten, Lager, Währungen, Preislisten und gewünschte Aktualisierungsfrequenz. Schreiben Sie dazu, welches System heute Katalog, Bestand, Preis, Kunden, Bestellungen, Rechnungen und Versand führt.

Beschreiben Sie den ersten Geschäftsablauf, der zuverlässig funktionieren muss, und die heutigen Fehler. Hilfreich sind Beispieldaten für Produkt, Bestand, Preis und Bestellung ohne personenbezogene Angaben sowie Informationen zu Rate-Limits, Sandbox-Zugang und festen Terminbedingungen. Erwähnen Sie vorhandene Integrations-Plugins oder individuellen Code. Auf dieser Grundlage können wir ein abgegrenztes Angebot mit Annahmen, Ausschlüssen, Abnahmenachweisen und offenen Informationen erstellen, statt allein anhand eines Produktnamens zu schätzen.

#Wann sich eine Integration lohnt

• Sie aktualisieren Bestand und Preise manuell oder per Dateiimport, und das skaliert nicht.
• Sie erhalten Bestellungen für Produkte, die der Lieferant gar nicht auf Lager hat.
• Die Shop-Preise driften von der Preisliste des Großhändlers oder ERP ab.
• Bestellungen müssen manuell in das Buchhaltungs- oder Lagersystem übertragen werden.