OXID ERP Schnittstelle: OXID mit ERP und Warenwirtschaft verbinden

Ein OXID eShop arbeitet in vielen Unternehmen nicht isoliert. Produktdaten, Preise, Bestände, Kundendaten und Bestellungen werden häufig in einem ERP-System oder einer Warenwirtschaft verwaltet. Damit diese Informationen nicht manuell zwischen den Systemen übertragen werden müssen, verbindet eine OXID ERP Schnittstelle den Onlineshop mit den relevanten Backend-Systemen.

Entscheidend ist dabei nicht nur, dass Daten übertragen werden. Für jeden Datenbereich muss festgelegt werden, welches System führend ist, in welche Richtung Informationen fließen und wann sie synchronisiert werden. Ein Bestand kann beispielsweise aus der Warenwirtschaft an OXID übergeben werden, während eine neue Bestellung den umgekehrten Weg vom Shop in das ERP-System nimmt.

Je nach Systemlandschaft kann die Anbindung über vorhandene APIs, einen Standard-Connector, Middleware oder eine individuell entwickelte Schnittstelle erfolgen. Welche Architektur sinnvoll ist, hängt unter anderem von den beteiligten Systemen, den Datenmengen, der benötigten Aktualität und den individuellen Geschäftsprozessen ab.

Dieser Artikel zeigt, wie sich OXID mit ERP und Warenwirtschaft verbinden lässt, welche Datenflüsse dabei besonders wichtig sind und worauf Unternehmen bei Systemrollen, Synchronisation, Datenmapping, Fehlerbehandlung und Monitoring achten sollten.

Was ist eine OXID ERP Schnittstelle?

Eine OXID ERP Schnittstelle verbindet OXID eShop mit einem ERP-System und ermöglicht den automatisierten Austausch geschäftsrelevanter Daten. Statt Informationen in mehreren Systemen separat zu pflegen oder manuell zu übertragen, werden definierte Daten zwischen Shop und Backend-System ausgetauscht.

Typische Datenbereiche sind Produkte, Varianten, Preise, Lagerbestände, Kunden, Bestellungen und Auftragsstatus. Dabei müssen nicht alle Informationen in beide Richtungen synchronisiert werden. Für jeden Datenbereich sollte klar definiert sein, welches System die Daten verwaltet und welches System sie empfängt.

Eine solche Anbindung kann beispielsweise dafür sorgen, dass aktuelle Bestände und Preise aus dem ERP-System an OXID übertragen werden. Geht im Onlineshop eine Bestellung ein, können die Bestelldaten wiederum automatisiert an das ERP übergeben und dort weiterverarbeitet werden.

Wird neben dem ERP eine separate Warenwirtschaft eingesetzt, erweitert sich die Systemlandschaft entsprechend. Dann muss festgelegt werden, welche Daten aus ERP, Warenwirtschaft oder OXID stammen und wie die beteiligten Systeme miteinander synchronisiert werden.

Welche Daten werden zwischen OXID und ERP ausgetauscht?

Welche Daten zwischen OXID eShop und ERP ausgetauscht werden, hängt von der bestehenden Systemlandschaft und den internen Geschäftsprozessen ab. Typischerweise geht es um Produktinformationen, Preise, Bestände, Kundendaten, Bestellungen sowie Versand- und Statusinformationen.

Wichtig ist, nicht einfach möglichst viele Daten zwischen den Systemen zu synchronisieren. Für jeden Datenbereich sollte definiert werden, welches System die Information führt, wann eine Übertragung notwendig ist und ob der Datenfluss ein- oder bidirektional erfolgen soll.

Produktdaten und Varianten

Produktstammdaten können beispielsweise aus ERP oder Warenwirtschaft an OXID übertragen werden. Dazu gehören Artikelnummern, Produktnamen, Varianten, Einheiten, Kategorien oder weitere technische Informationen. Umfangreiche Beschreibungen, Attribute und Medien können je nach Architektur auch aus einem PIM-System stammen.

Besonders bei Varianten ist ein eindeutiges Mapping wichtig. Artikelnummern, Varianten-IDs und weitere Schlüssel müssen in den beteiligten Systemen konsistent zugeordnet werden, damit Produkte nicht doppelt angelegt oder falsche Informationen aktualisiert werden.

Preise und kundenspezifische Konditionen

Preise werden in vielen Unternehmen im ERP-System verwaltet und von dort an OXID übergeben. Neben Standardpreisen können auch Staffelpreise, kundenspezifische Konditionen, Rabatte oder unterschiedliche Preislisten relevant sein.

Gerade bei B2B-Shops sollte geklärt werden, ob Preise direkt aus dem ERP übernommen, regelmäßig synchronisiert oder auf Basis definierter Logiken im Shop berechnet werden. Unklare Zuständigkeiten zwischen ERP und OXID können sonst zu unterschiedlichen Preisen in Vertrieb und Onlineshop führen.

Bestände und Verfügbarkeiten

Aktuelle Lagerbestände und Verfügbarkeiten sind für viele OXID-Shops besonders kritisch. Sie stammen häufig aus ERP oder Warenwirtschaft und werden an den Shop übertragen, damit Kunden möglichst aktuelle Informationen zur Lieferfähigkeit erhalten.

Wie häufig Bestände synchronisiert werden sollten, hängt unter anderem von Bestellvolumen, Lagerprozessen und der Bedeutung einer aktuellen Verfügbarkeitsanzeige ab. Bei schnell wechselnden Beständen kann eine häufigere oder ereignisbasierte Synchronisation sinnvoll sein als ein seltener Batch-Import.

Bestellungen und Auftragsdaten

Geht eine Bestellung in OXID ein, werden die relevanten Bestelldaten typischerweise an ERP oder Warenwirtschaft übergeben. Dazu können Kunden- und Lieferadressen, Positionen, Mengen, Preise, Zahlungsinformationen, Versandart und weitere auftragsbezogene Daten gehören.

Im Zielsystem kann die Bestellung anschließend als Auftrag weiterverarbeitet werden. Entscheidend ist, dass Pflichtfelder, Artikelreferenzen, Steuern, Rabatte und weitere Informationen eindeutig gemappt werden, damit aus der Shop-Bestellung ein korrekt verarbeitbarer Auftrag entsteht.

Kunden-, Versand- und Statusdaten

Je nach Geschäftsmodell können auch Kundenstammdaten zwischen OXID und ERP ausgetauscht werden. Dabei sollte klar geregelt sein, ob neue Kunden im Shop angelegt und an das ERP übergeben werden oder ob bestehende Kundenkonten aus dem ERP im Shop bereitgestellt werden.

Nach der Auftragsbearbeitung können Versand- oder Bestellstatus aus ERP oder Warenwirtschaft an OXID zurückgespielt werden. So lassen sich beispielsweise Versandinformationen, Trackingdaten oder Statusänderungen im Kundenkonto anzeigen und manuelle Aktualisierungen reduzieren.

Datenbereich	Typische Richtung	Mögliches führendes System
Produktstammdaten	ERP / WaWi → OXID	ERP oder Warenwirtschaft
Produktbeschreibungen und Medien	PIM → OXID	PIM
Preise und Konditionen	ERP → OXID	ERP
Bestände und Verfügbarkeiten	WaWi / ERP → OXID	Warenwirtschaft oder ERP
Bestellungen	OXID → ERP / WaWi	OXID als Entstehungssystem, ERP/WaWi für Weiterverarbeitung
Kundendaten	abhängig vom Geschäftsmodell	ERP oder OXID
Versand- und Bestellstatus	ERP / WaWi → OXID	ERP oder Warenwirtschaft

OXID mit einer Warenwirtschaft verbinden

Eine Warenwirtschaft übernimmt in vielen Unternehmen zentrale Aufgaben rund um Artikel, Bestände, Lager, Warenbewegungen und Auftragsabwicklung. Wird OXID eShop als Vertriebskanal eingesetzt, müssen diese Informationen zuverlässig zwischen Shop und Warenwirtschaft ausgetauscht werden.

Welche Daten übertragen werden, hängt von der konkreten Systemlandschaft ab. Typisch sind Produkt- und Artikeldaten, Lagerbestände, Verfügbarkeiten, Bestellungen, Kundeninformationen sowie Versand- und Statusdaten. Dabei sollte klar definiert sein, welche Daten in der Warenwirtschaft gepflegt werden und welche Informationen in OXID entstehen.

Besonders wichtig ist die Bestandsführung. Wenn Lagerbestände in der Warenwirtschaft verwaltet werden, sollte OXID diese Informationen regelmäßig oder ereignisbasiert erhalten. So lässt sich vermeiden, dass im Shop Produkte als verfügbar angezeigt werden, obwohl der tatsächliche Bestand bereits abverkauft ist.

Auch Bestellungen sollten möglichst automatisiert an die Warenwirtschaft übergeben werden. Dort können sie in Lager-, Versand- und weitere operative Prozesse einfließen. Statusinformationen oder Trackingdaten lassen sich anschließend wieder an OXID zurückspielen, damit der Shop den aktuellen Bearbeitungsstand abbilden kann.

ERP und Warenwirtschaft werden im Alltag teilweise synonym verwendet, sind aber nicht immer dasselbe. Je nach Unternehmen kann die Warenwirtschaft Bestandteil eines ERP-Systems sein oder als eigenständige Anwendung betrieben werden. Für die OXID-Anbindung ist deshalb entscheidend, nicht nur den Systemnamen zu betrachten, sondern die tatsächlichen Aufgaben, Datenhoheiten und Prozesse. Wird die Warenwirtschaft als eigenständiges System betrieben, muss die Warenwirtschaft-Schnittstelle entsprechend in die gesamte Integrationsarchitektur eingeordnet werden.

Welches System sollte für welche Daten führend sein?

Bei einer OXID ERP Schnittstelle sollte für jeden Datenbereich klar definiert sein, welches System die Information führt. Ohne diese Zuordnung entstehen schnell widersprüchliche Daten, doppelte Pflege oder unklare Verantwortlichkeiten zwischen OXID, ERP, Warenwirtschaft und PIM.

Das führende System ist die Anwendung, in der eine Information fachlich gepflegt und verbindlich verwaltet wird. Andere Systeme erhalten diese Daten über definierte Schnittstellen. Dadurch wird vermieden, dass beispielsweise ein Preis gleichzeitig im ERP und im Shop unabhängig voneinander geändert wird.

Datenbereich	Typisches führendes System	Rolle von OXID
Artikelnummern und kaufmännische Stammdaten	ERP oder Warenwirtschaft	Daten für Darstellung und Verkauf übernehmen
Preise und Konditionen	häufig ERP	Preise im Shop darstellen und für Bestellungen verwenden
Bestände und Verfügbarkeiten	Warenwirtschaft oder ERP	Verfügbarkeit für Kunden anzeigen
Produktbeschreibungen, Attribute und Medien	PIM oder je nach Architektur OXID	Produktinformationen im Shop ausspielen
Bestellungen	OXID als Entstehungssystem, anschließend ERP oder Warenwirtschaft	Bestellung erfassen und zur Weiterverarbeitung übergeben
Kundenstammdaten	abhängig vom Geschäftsmodell ERP oder OXID	Kundenkonto und shopbezogene Informationen bereitstellen
Versand- und Auftragsstatus	ERP oder Warenwirtschaft	Status im Kundenkonto oder Bestellprozess anzeigen

Diese Zuordnung ist kein starres Standardmodell. In einem B2B-Projekt kann das ERP beispielsweise kundenspezifische Preise, Zahlungsbedingungen und Kundenstammdaten führen, während OXID Benutzerkonten, Shoprollen oder bestimmte vertriebsspezifische Einstellungen verwaltet. Bei umfangreichen Produktinformationen kann wiederum ein PIM die zentrale Quelle für Texte, Attribute, Kategorien und Medien sein.

Besonders kritisch wird es, wenn dieselben Daten in mehreren Systemen verändert werden können. Eine bidirektionale Synchronisation sollte deshalb nur dort eingesetzt werden, wo sie fachlich wirklich notwendig ist. Je klarer Datenhoheit und Systemrollen definiert sind, desto einfacher lassen sich Schnittstellen, Fehlerbehandlung und spätere Erweiterungen kontrollieren.

OXID ERP Connector oder individuelle Schnittstelle?

Für die Verbindung von OXID mit ERP oder Warenwirtschaft kommen unterschiedliche technische Ansätze infrage. In manchen Projekten reicht ein vorhandener Connector oder eine bestehende Standardintegration aus. In anderen Fällen sind individuelle Anpassungen oder eine eigens entwickelte Schnittstelle notwendig.

Welche Variante sinnvoll ist, hängt davon ab, wie gut vorhandene Funktionen zur bestehenden Systemlandschaft passen. Entscheidend sind unter anderem die unterstützten Datenobjekte, die benötigten Synchronisationsrichtungen, individuelle Geschäftslogiken und die Frage, wie stark OXID, ERP und Warenwirtschaft bereits angepasst wurden.

Wann ein Standard-Connector ausreichen kann

Ein Standard-Connector kann sinnvoll sein, wenn OXID und das angebundene ERP- oder Warenwirtschaftssystem in einer weitgehend typischen Konfiguration betrieben werden und die benötigten Datenflüsse bereits abgedeckt sind. Dazu können beispielsweise Produkte, Preise, Bestände, Kunden oder Bestellungen gehören.

Vor dem Einsatz sollte jedoch geprüft werden, welche Datenobjekte tatsächlich unterstützt werden, wie das Mapping funktioniert und ob individuelle Module oder kundenspezifische Prozesse berücksichtigt werden können. Auch Updatefähigkeit, Fehlerprotokollierung und Wartung sollten in die Bewertung einbezogen werden.

Wann eine individuelle OXID-Schnittstelle sinnvoll ist

Eine individuelle Schnittstelle wird vor allem dann relevant, wenn Standard-Connectoren zentrale Anforderungen nicht sauber abbilden. Das kann beispielsweise bei speziellen Preislogiken, individuellen B2B-Prozessen, komplexen Produktstrukturen, mehreren Lagerorten oder besonderen Auftragsabläufen der Fall sein.

Auch bestehende OXID-Shops mit individuellen Modulen und angepassten Datenstrukturen benötigen häufig eine genauere technische Abstimmung. In solchen Projekten sollte die Schnittstelle nicht isoliert entwickelt werden, sondern zur vorhandenen Shoparchitektur und zu den Datenmodellen der beteiligten Systeme passen. Soll die ERP-Schnittstelle individuell entwickelt werden, müssen deshalb neben den technischen Schnittstellen auch Datenmodelle, Geschäftslogiken und bestehende Systemabhängigkeiten berücksichtigt werden.

Wie kann eine OXID ERP Schnittstelle technisch umgesetzt werden?

Die technische Umsetzung einer OXID ERP Schnittstelle hängt davon ab, welche Systeme verbunden werden, welche Schnittstellen bereits verfügbar sind und wie schnell die Daten zwischen OXID, ERP und Warenwirtschaft ausgetauscht werden müssen. Je nach Projekt kommen direkte API-Anbindungen, Middleware, Dateiimporte oder zeitgesteuerte Integrationsprozesse infrage.

API-basierte Integration

Wenn OXID und das angebundene ERP- oder Warenwirtschaftssystem geeignete APIs bereitstellen, können Daten direkt zwischen den Anwendungen übertragen werden. Dieser Ansatz eignet sich besonders für strukturierte Datenflüsse, bei denen Produkte, Preise, Bestände, Kunden oder Bestellungen automatisiert verarbeitet werden sollen.

Entscheidend ist nicht nur, welche API-Endpunkte verfügbar sind. Auch Authentifizierung, Datenmapping, Fehlerbehandlung, Limits, Versionierung und die Frage, wie auf technische Unterbrechungen reagiert wird, sollten bereits bei der Schnittstellen- und API-Entwicklung berücksichtigt werden.

Middleware als Integrationsschicht

Bei komplexeren Systemlandschaften kann eine Middleware zwischen OXID und den angebundenen Anwendungen eingesetzt werden. Sie übernimmt beispielsweise die Transformation von Daten, koordiniert mehrere Schnittstellen und kann unterschiedliche Systeme entkoppeln.

Das ist besonders interessant, wenn neben ERP und Warenwirtschaft weitere Anwendungen wie PIM, Logistik, Marktplätze oder interne Systeme beteiligt sind. Statt zahlreiche direkte Punkt-zu-Punkt-Verbindungen aufzubauen, können Datenflüsse über eine gemeinsame Integrationsschicht gesteuert werden. Welche Rolle dabei APIs, Datenmapping, Middleware, Testing und Monitoring spielen, hängt von der jeweiligen Schnittstellenarchitektur ab.

Datei- und Batch-Verarbeitung

Nicht jede Integration muss in Echtzeit über eine API erfolgen. Bei bestimmten Datenmengen oder weniger zeitkritischen Prozessen können auch Dateiimporte, Exporte oder zeitgesteuerte Batch-Prozesse sinnvoll sein.

Beispielsweise können umfangreiche Produktdaten in definierten Intervallen übertragen werden, während Bestellungen oder kritische Bestandsänderungen häufiger verarbeitet werden. Entscheidend ist, dass der gewählte Mechanismus zur fachlichen Aktualität der jeweiligen Daten passt.

Echtzeit oder zeitgesteuerte Synchronisation?

Ob Daten sofort oder in festen Intervallen synchronisiert werden sollten, hängt vom jeweiligen Datenbereich ab. Bestellungen und kritische Bestandsänderungen können eine sehr kurze Verzögerung erfordern, während Produktbeschreibungen oder bestimmte Stammdaten oft auch zeitgesteuert aktualisiert werden können.

Eine Echtzeitintegration ist nicht automatisch die bessere Lösung. Sie erhöht technische Abhängigkeiten und kann komplexer zu betreiben sein. Deshalb sollte für jeden Datenfluss geprüft werden, welche Aktualität tatsächlich erforderlich ist und welcher technische Aufwand dafür gerechtfertigt ist.

Typischer Datenfluss zwischen OXID und ERP

Ein typischer Datenfluss zwischen OXID und ERP besteht aus mehreren aufeinander abgestimmten Schritten. Produkt- und Stammdaten werden an den Shop übergeben, Bestände und Preise aktualisiert, Bestellungen aus OXID an ERP oder Warenwirtschaft übertragen und Statusinformationen anschließend wieder an den Shop zurückgespielt.

Wie dieser Ablauf konkret aussieht, hängt von der bestehenden Systemlandschaft ab. Trotzdem lässt sich ein typischer Prozess vereinfacht in mehrere Schritte gliedern.

1. Produktdaten bereitstellen: Artikelnummern, Varianten, Kategorien und weitere produktbezogene Informationen werden aus ERP, Warenwirtschaft oder PIM an OXID übergeben.
2. Preise und Bestände synchronisieren: Aktuelle Preise, kundenspezifische Konditionen und Verfügbarkeiten werden im Shop aktualisiert.
3. Bestellung in OXID erfassen: Der Kunde bestellt im Onlineshop. OXID erfasst Positionen, Mengen, Preise, Kunden- und Lieferdaten sowie weitere bestellrelevante Informationen.
4. Bestellung an ERP oder Warenwirtschaft übertragen: Die Bestellung wird automatisiert an das Zielsystem übergeben und dort als Auftrag weiterverarbeitet.
5. Auftrag intern bearbeiten: ERP oder Warenwirtschaft steuern je nach Systemlandschaft Lager, Kommissionierung, Versand, Belege oder weitere operative Prozesse.
6. Status an OXID zurückmelden: Versandstatus, Trackinginformationen oder weitere Auftragsinformationen werden an den Shop zurückgespielt.
7. Kundeninformation aktualisieren: OXID zeigt den aktuellen Bearbeitungs- oder Versandstatus im Kundenkonto oder innerhalb des Bestellprozesses an.

Wichtig ist, dass die einzelnen Schritte nicht isoliert betrachtet werden. Die Datenflüsse zwischen E-Commerce und ERP müssen so aufeinander abgestimmt sein, dass Bestände, Aufträge, Preise und Statusinformationen zwischen Shop und Backend-System konsistent verarbeitet werden. Eine Bestellung kann beispielsweise technisch korrekt an das ERP übertragen werden und trotzdem zu Problemen führen, wenn Artikelnummern nicht eindeutig gemappt sind, Preise unterschiedlich berechnet werden oder Statuswerte zwischen den Systemen nicht zusammenpassen.

Besonders bei B2B-Projekten können zusätzliche Datenflüsse erforderlich sein. Dazu gehören beispielsweise kundenspezifische Preise, individuelle Sortimente, Benutzerrollen, Freigabeprozesse oder Zahlungsbedingungen, die aus dem ERP stammen oder zwischen mehreren Systemen abgestimmt werden müssen.

Typische Fehler bei der OXID ERP Integration

Viele Probleme bei einer OXID ERP Integration entstehen nicht durch die eigentliche Verbindung der Systeme, sondern durch unklare Datenhoheiten, fehlerhafte Zuordnungen oder fehlende Prozesse für Ausnahmen und Störungen. Gerade bei geschäftskritischen Daten wie Beständen, Preisen und Bestellungen sollten diese Punkte bereits vor der technischen Umsetzung geklärt werden.

Typischer Fehler	Mögliche Folge	Besserer Ansatz
Unklare Datenhoheit	Preise, Bestände oder Produktinformationen werden in mehreren Systemen unabhängig gepflegt und widersprechen sich.	Für jeden Datenbereich ein eindeutig führendes System definieren.
Fehlerhaftes Datenmapping	Artikel, Varianten, Kunden oder Statuswerte werden falsch zugeordnet oder doppelt angelegt.	IDs, Artikelnummern, Variantenlogik und Wertebereiche vor der Integration eindeutig abbilden.
Zu viele bidirektionale Datenflüsse	Änderungen überschreiben sich gegenseitig oder führen zu schwer nachvollziehbaren Konflikten.	Daten nur dort bidirektional synchronisieren, wo dies fachlich wirklich notwendig ist.
Fehlende Fehlerbehandlung	Nicht übertragene Bestellungen oder fehlerhafte Datensätze bleiben unbemerkt.	Fehler protokollieren, Wiederholungslogiken definieren und kritische Vorgänge sichtbar machen.
Keine eindeutigen Referenzen	Bestellungen, Kunden oder Produkte lassen sich zwischen OXID und ERP nicht sicher zuordnen.	Stabile externe IDs und eindeutige Referenzen zwischen den Systemen verwenden.
Ungeeignete Synchronisationsintervalle	Bestände oder Preise sind im Shop veraltet oder Prozesse werden unnötig oft belastet.	Aktualisierungsrhythmus an die fachliche Relevanz des jeweiligen Datenbereichs anpassen.
Individuelle OXID-Logik wird nicht berücksichtigt	Eigene Module, Preislogiken oder B2B-Prozesse funktionieren nach der Anbindung nicht wie erwartet.	Bestehende OXID-Anpassungen bereits bei Analyse und Mapping einbeziehen.
Fehlendes Monitoring	Störungen werden erst bemerkt, wenn Kunden, Vertrieb oder Lager bereits betroffen sind.	Kritische Datenflüsse überwachen und für relevante Fehler Benachrichtigungen definieren.
Updates werden nicht mitgedacht	OXID-, ERP- oder Modul-Updates beeinträchtigen bestehende Schnittstellen.	Abhängigkeiten dokumentieren und Schnittstellen bei Versionswechseln gezielt testen.

Besonders kritisch sind Fehler, die technisch zunächst unauffällig bleiben. Eine Schnittstelle kann beispielsweise erfolgreich antworten, obwohl ein Datensatz fachlich unvollständig ist oder eine Bestellung im ERP nicht korrekt weiterverarbeitet werden kann. Deshalb sollten technische und fachliche Validierung gemeinsam betrachtet werden.

Fehlerbehandlung und Monitoring einer OXID Schnittstelle

Auch eine technisch sauber entwickelte OXID Schnittstelle muss mit Fehlern und Unterbrechungen umgehen können. ERP, Warenwirtschaft, OXID oder externe Dienste können zeitweise nicht erreichbar sein, Datensätze können unvollständig sein oder fachliche Regeln verhindern eine erfolgreiche Verarbeitung.

Deshalb sollte bereits bei der Planung festgelegt werden, wie fehlgeschlagene Übertragungen erkannt, protokolliert und erneut verarbeitet werden. Besonders bei Bestellungen, Beständen und Preisen ist es wichtig, dass Fehler nicht unbemerkt bleiben oder zu widersprüchlichen Daten zwischen den Systemen führen.

Logging und nachvollziehbare Protokolle

Für relevante Datenflüsse sollte nachvollziehbar sein, wann ein Datensatz übertragen wurde, welches System ihn verarbeitet hat und ob die Verarbeitung erfolgreich war. Bei Fehlern sollten aussagekräftige Informationen gespeichert werden, damit sich Ursache und betroffener Vorgang gezielt analysieren lassen.

Ein reiner technischer Fehlercode reicht dabei oft nicht aus. Gerade bei geschäftskritischen Prozessen sollten auch fachliche Informationen wie Bestellnummer, Artikelreferenz, Kundennummer oder betroffener Datenbereich nachvollziehbar sein.

Retry-Logik und Wiederholungen

Temporäre Fehler können häufig durch eine kontrollierte Wiederholung behoben werden. Ist ein ERP-System beispielsweise kurzzeitig nicht erreichbar, kann die Übertragung zu einem späteren Zeitpunkt erneut versucht werden.

Dabei muss verhindert werden, dass derselbe Vorgang mehrfach verarbeitet wird. Besonders bei Bestellungen ist eine eindeutige Referenz wichtig, damit eine Wiederholung nicht versehentlich einen zweiten Auftrag im ERP erzeugt.

Fehlerqueue und manuelle Nachbearbeitung

Nicht jeder Fehler lässt sich automatisch beheben. Ein fehlender Artikel, eine ungültige Kundenzuordnung oder ein nicht erwarteter Statuswert kann eine fachliche Prüfung erfordern. Solche Vorgänge sollten gezielt in einer Fehlerqueue oder einem vergleichbaren Prozess gesammelt werden.

Dadurch können problematische Datensätze nachbearbeitet werden, ohne den gesamten Datenfluss zu blockieren. Wichtig ist, dass nach einer Korrektur eine kontrollierte erneute Verarbeitung möglich ist.

Monitoring und Benachrichtigungen

Monitoring sollte nicht nur prüfen, ob eine Schnittstelle technisch erreichbar ist. Ebenso wichtig ist die Frage, ob Daten tatsächlich in der erwarteten Menge und innerhalb eines sinnvollen Zeitraums verarbeitet werden.

Wenn beispielsweise über einen längeren Zeitraum keine Bestellungen im ERP ankommen oder Bestandsaktualisierungen ausbleiben, kann das auf eine Störung hinweisen. Für solche Abweichungen sollten geeignete Benachrichtigungen oder Eskalationswege definiert werden.

Bereich	Worauf geachtet werden sollte	Ziel
Logging	Vorgänge, Zeitpunkte, Referenzen und Fehler nachvollziehbar protokollieren.	Ursachen schneller analysieren und betroffene Datensätze identifizieren.
Retry	Temporäre Fehler kontrolliert erneut verarbeiten.	Kurzzeitige Störungen automatisch abfangen.
Dubletten-Schutz	Bereits verarbeitete Vorgänge eindeutig erkennen.	Doppelte Bestellungen oder Datensätze vermeiden.
Fehlerqueue	Nicht automatisch lösbare Vorgänge gezielt sammeln.	Manuelle Nachbearbeitung ermöglichen, ohne den Gesamtprozess zu blockieren.
Monitoring	Technische Verfügbarkeit und fachliche Datenflüsse überwachen.	Störungen früh erkennen.
Benachrichtigungen	Kritische Fehler und ungewöhnliche Abweichungen sichtbar machen.	Reaktionszeiten verkürzen und geschäftskritische Prozesse absichern.

Eine stabile OXID ERP Integration sollte deshalb nicht nur den erfolgreichen Normalfall abbilden. Ebenso wichtig ist, dass Fehlerzustände definiert sind und nachvollziehbar bleibt, welche Daten erfolgreich verarbeitet wurden, welche Vorgänge erneut versucht werden und wo eine manuelle Prüfung notwendig ist.

OXID, ERP und PIM: Wie werden die Systemrollen verteilt?

In komplexeren E-Commerce-Systemlandschaften reicht die Verbindung von OXID und ERP häufig nicht aus. Wenn umfangreiche Produktinformationen, technische Merkmale, Medien oder mehrere Vertriebskanäle verwaltet werden müssen, kann zusätzlich ein PIM-System eine zentrale Rolle übernehmen.

Entscheidend ist, die Aufgaben der Systeme sauber voneinander abzugrenzen. ERP und Warenwirtschaft verwalten typischerweise kaufmännische und operative Daten, während ein PIM produktbezogene Informationen strukturiert, anreichert und für unterschiedliche Kanäle bereitstellt. OXID nutzt diese Daten anschließend für Produktdarstellung, Suche, Warenkorb, Checkout und Kundenprozesse.

System	Typische Rolle	Beispiele für Daten
ERP	Kaufmännische Prozesse und zentrale Geschäftsdaten steuern.	Preise, Kunden, Aufträge, Zahlungsbedingungen, Belege
Warenwirtschaft	Bestände, Lager und operative Warenbewegungen verwalten.	Lagerbestände, Verfügbarkeiten, Versand- und Auftragsstatus
PIM	Produktinformationen zentral pflegen und für Kanäle aufbereiten.	Texte, Attribute, Varianten, Kategorien, Medien, technische Daten
OXID eShop	Produkte verkaufen und digitale Kundenprozesse abbilden.	Produktdarstellung, Warenkorb, Checkout, Kundenkonto, Bestellungen

Ein typischer Datenfluss kann beispielsweise so aussehen: Das ERP liefert Artikelnummern und Preise, die Warenwirtschaft stellt Bestände bereit und das PIM übermittelt Produktbeschreibungen, Attribute und Medien. OXID führt diese Informationen im Shop zusammen und übergibt neue Bestellungen anschließend wieder an ERP oder Warenwirtschaft.

Wichtig ist, dass dieselben Informationen nicht ohne klare Regeln in mehreren Systemen gepflegt werden. Wenn beispielsweise Produktattribute sowohl im PIM als auch direkt in OXID geändert werden können, entstehen schnell widersprüchliche Daten und unnötige Pflegeprozesse.

Je klarer die Systemrollen definiert sind, desto einfacher lassen sich Datenflüsse, Schnittstellen und spätere Erweiterungen kontrollieren. Bei einer E-Commerce ERP Integration ist diese klare Rollenverteilung besonders wichtig, wenn neben Shop und ERP weitere Systeme wie Warenwirtschaft, PIM oder Logistik in gemeinsame Prozesse eingebunden werden.

Was ist bei bestehenden OXID-Shops zu beachten?

Bei einem bestehenden OXID-Shop sollte eine neue ERP- oder Warenwirtschaftsanbindung nicht ohne technische Bestandsaufnahme umgesetzt werden. Gewachsene Shops enthalten häufig individuelle Module, eigene Datenstrukturen, bestehende Importe und Exporte, Cronjobs oder bereits vorhandene Schnittstellen, die bei einer neuen Integration berücksichtigt werden müssen.

Besonders wichtig ist die Frage, welche Daten heute bereits zwischen den Systemen ausgetauscht werden und welche Komponenten davon abhängen. Eine neue Schnittstelle kann bestehende Prozesse beeinflussen, wenn beispielsweise Artikelnummern, Preislogiken, Bestandsberechnungen oder Bestellstatus bisher über individuelle Erweiterungen verarbeitet werden.

Prüfbereich	Was analysiert werden sollte	Warum es wichtig ist
OXID-Version	Aktueller Versionsstand und geplante Updates oder Versionswechsel.	Die technische Anbindung sollte zur eingesetzten und zukünftigen OXID-Version passen.
Individuelle Module	Eigene Erweiterungen, Preislogiken, B2B-Funktionen und Anpassungen.	Module können Daten verändern oder bestehende Schnittstellen beeinflussen.
Bestehende Schnittstellen	ERP-, WaWi-, PIM-, Payment-, Logistik- oder weitere Integrationen.	Neue Datenflüsse dürfen vorhandene Prozesse nicht unbeabsichtigt ersetzen oder duplizieren.
Importe und Exporte	Dateiimporte, Exporte, Batch-Prozesse und manuelle Datentransfers.	Bestehende Übertragungswege müssen in die neue Architektur eingeordnet werden.
Cronjobs und Hintergrundprozesse	Zeitgesteuerte Aufgaben für Preise, Bestände, Produkte oder Bestellungen.	Doppelte oder konkurrierende Prozesse können zu inkonsistenten Daten führen.
Datenmodelle und Referenzen	Artikelnummern, Varianten-IDs, Kundenreferenzen und Statuswerte.	Bestehende Zuordnungen müssen erhalten oder kontrolliert migriert werden.
Monitoring und Logs	Bestehende Protokollierung, Fehlermeldungen und Überwachung.	Hilft, bekannte Probleme und technische Abhängigkeiten früh zu erkennen.

Vor einer technischen Umstellung sollte deshalb geklärt werden, welche bestehenden Komponenten erhalten, angepasst oder ersetzt werden. Ein kompletter Neustart ist nicht automatisch notwendig. Stabile Teile der vorhandenen Architektur können weiter genutzt werden, wenn ihre Funktion und Abhängigkeiten nachvollziehbar sind.

Gerade bei geschäftskritischen Shops empfiehlt es sich, neue oder geänderte Datenflüsse zunächst in einer Test- oder Staging-Umgebung zu prüfen. Dabei sollten nicht nur einzelne Schnittstellenaufrufe getestet werden, sondern komplette Prozesse wie Produktaktualisierung, Bestellung, Auftragsübergabe, Versandstatus und Fehlerbehandlung.

So sollte ein OXID ERP Integrationsprojekt ablaufen

Ein OXID ERP Integrationsprojekt sollte nicht mit der technischen Umsetzung beginnen. Zuerst müssen Geschäftsprozesse, Datenobjekte, Systemrollen und bestehende Abhängigkeiten verstanden werden. Erst auf dieser Grundlage lässt sich entscheiden, welche Daten zwischen OXID, ERP, Warenwirtschaft oder weiteren Systemen ausgetauscht werden sollen und welche technische Architektur dafür geeignet ist.

1. Ausgangssituation analysieren: Bestehende OXID-Version, ERP- oder Warenwirtschaftssystem, vorhandene Schnittstellen, Module, Importe, Exporte und relevante Geschäftsprozesse erfassen.
2. Datenobjekte definieren: Festlegen, welche Produkte, Varianten, Preise, Bestände, Kunden, Bestellungen und Statusinformationen zwischen den Systemen ausgetauscht werden sollen.
3. Systemrollen und Datenhoheit klären: Für jeden Datenbereich bestimmen, welches System führend ist und in welche Richtung die Daten übertragen werden.
4. Integrationsarchitektur auswählen: Prüfen, ob ein vorhandener Connector, eine direkte API-Anbindung, Middleware, Dateiübertragung oder eine individuelle Schnittstelle die Anforderungen am besten abbildet.
5. Datenmapping vorbereiten: Artikelnummern, Varianten, Kundenreferenzen, Preislogiken, Statuswerte und weitere Felder zwischen OXID und den Zielsystemen eindeutig zuordnen.
6. Schnittstelle entwickeln und konfigurieren: Datenflüsse technisch umsetzen, Authentifizierung, Transformationen, Synchronisationslogik und notwendige Erweiterungen einrichten.
7. Prozesse systematisch testen: Produkte, Preise, Bestände, Bestellungen, Kunden- und Statusdaten unter realistischen Bedingungen in einer Test- oder Staging-Umgebung prüfen.
8. Fehlerbehandlung und Monitoring einrichten: Logging, Retry-Logik, Dubletten-Schutz, Fehlerqueues und Benachrichtigungen für kritische Datenflüsse vorbereiten.
9. Go-live kontrolliert durchführen: Produktivschaltung planen, betroffene Prozesse überwachen und sicherstellen, dass Daten nach der Umstellung vollständig und korrekt verarbeitet werden.

Bei größeren Projekten kann es sinnvoll sein, die Integration schrittweise einzuführen. Beispielsweise können zunächst Produktdaten und Bestände angebunden werden, bevor Bestellungen, Kunden- oder Statusdaten folgen. Dadurch lassen sich einzelne Datenflüsse gezielter testen und Risiken beim Go-live reduzieren.

Entscheidend ist, dass fachliche Anforderungen und technische Umsetzung während des gesamten Projekts zusammen betrachtet werden. Eine Schnittstelle kann technisch funktionieren und trotzdem ungeeignet sein, wenn sie bestehende Geschäftsprozesse, Datenhoheiten oder individuelle OXID-Anpassungen nicht ausreichend berücksichtigt.

FAQ zur OXID ERP Schnittstelle

Kann OXID mit einem ERP-System verbunden werden?

Ja. OXID eShop kann über Schnittstellen, APIs, Connectoren oder Middleware mit ERP-Systemen verbunden werden. Welche technische Variante sinnvoll ist, hängt von den beteiligten Systemen, den benötigten Datenflüssen und den individuellen Geschäftsprozessen ab.

Kann OXID mit einer Warenwirtschaft verbunden werden?

Ja. OXID kann mit einer Warenwirtschaft verbunden werden, um beispielsweise Produktdaten, Bestände, Verfügbarkeiten, Bestellungen sowie Versand- und Statusinformationen automatisiert auszutauschen. Entscheidend ist, welche Aufgaben die Warenwirtschaft innerhalb der Systemlandschaft übernimmt.

Welche Daten werden zwischen OXID und ERP synchronisiert?

Typische Datenbereiche sind Produkte, Varianten, Preise, Bestände, Kundendaten, Bestellungen und Auftragsstatus. Welche Daten tatsächlich synchronisiert werden und in welche Richtung sie fließen, sollte für jedes Projekt individuell definiert werden.

Was ist ein OXID ERP Connector?

Ein OXID ERP Connector ist eine technische Verbindung zwischen OXID und einem ERP- oder Warenwirtschaftssystem. Je nach Lösung kann er bestimmte Standarddatenflüsse bereits vorkonfiguriert abbilden. Vor dem Einsatz sollte geprüft werden, ob Datenobjekte, Mapping, individuelle Module und Geschäftslogiken ausreichend unterstützt werden.

Sollte das ERP oder OXID das führende System sein?

Das lässt sich nicht pauschal beantworten. Häufig führt das ERP kaufmännische Daten wie Preise, Kunden oder Aufträge, während OXID shopbezogene Funktionen und Kundenprozesse abbildet. Für jeden Datenbereich sollte separat festgelegt werden, welches System fachlich führend ist.

Wie oft sollten Bestände zwischen OXID und Warenwirtschaft synchronisiert werden?

Das hängt von Bestellvolumen, Lagerprozessen und der erforderlichen Aktualität ab. Bei stark schwankenden Beständen kann eine häufige oder ereignisbasierte Synchronisation sinnvoll sein. Weniger zeitkritische Daten können dagegen in größeren Intervallen verarbeitet werden.

Wann ist eine individuelle OXID ERP Schnittstelle sinnvoll?

Eine individuelle Schnittstelle ist vor allem dann sinnvoll, wenn vorhandene Connectoren zentrale Anforderungen nicht ausreichend abdecken. Das kann bei speziellen Preislogiken, komplexen B2B-Prozessen, individuellen Modulen, besonderen Datenstrukturen oder mehreren angebundenen Systemen der Fall sein.

Fazit: OXID, ERP und Warenwirtschaft sauber verbinden

Eine OXID ERP Schnittstelle kann Produktdaten, Preise, Bestände, Kunden, Bestellungen und Statusinformationen automatisiert zwischen OXID eShop, ERP und Warenwirtschaft austauschen. Entscheidend ist dabei nicht nur die technische Verbindung, sondern eine klare Definition von Datenhoheit, Systemrollen und Synchronisationslogik.

Je besser festgelegt ist, welches System welche Daten führt, wie Informationen gemappt werden und wie Fehler behandelt werden, desto stabiler lässt sich die Integration langfristig betreiben. Besonders bei bestehenden OXID-Shops sollten individuelle Module, vorhandene Schnittstellen und bestehende Datenflüsse vor einer Erweiterung oder Modernisierung berücksichtigt werden.

Ob ein vorhandener Connector ausreicht oder eine individuelle Schnittstelle sinnvoll ist, hängt von den konkreten Geschäftsprozessen, Datenstrukturen und angebundenen Systemen ab. Als OXID Agentur unterstützt maexware Unternehmen bei der technischen Weiterentwicklung von OXID-Shops sowie bei der Anbindung von ERP, Warenwirtschaft und weiteren Systemen.