Magento SAP Business One Integrationsarchitektur: Welche Daten sollten synchronisiert werden, welches System sollte sie führen – und warum?

Ein Connector kann funktionieren – und die Integration trotzdem scheitern 

Magento zeigt einen Preis an. In SAP Business One ist ein anderer hinterlegt. Der Kunde bestellt trotzdem, weil im Storefront nichts darauf hinweist, dass die Systeme voneinander abweichen. Der Lagerbestand ist auf dem Papier korrekt synchronisiert – die Bestandszahlen stimmen überein. Doch Magento und SAP sind sich nicht darüber einig, welches System den Preis tatsächlich führen darf. Und genau diese Zuständigkeit wurde nie eindeutig definiert. In diesem Fall muss der Connector technisch nicht einmal fehlerhaft sein. 

Das eigentliche Problem liegt in der Architektur. 

Genau das ist eine der unangenehmen Realitäten bei einer Magento SAP Business One Integration: Die API kann technisch sauber funktionieren, sämtliche Felder können korrekt gemappt sein und trotzdem können falsche Ergebnisse entstehen – schlicht deshalb, weil nie festgelegt wurde, welches System in welchem Fall die verbindliche Wahrheit liefert. Damit kommen wir zur zentralen Frage dieses Beitrags:  Welche Daten sollten zwischen Magento und SAP Business One synchronisiert werden, in welche Richtung sollten sie fließen und welches System sollte für die jeweilige Datenart als zentrale Datenquelle dienen? In den meisten Magento–SAP-Business-One-Integrationen sollte SAP Business One das führende System für ERP gesteuerte Daten bleiben – etwa für Lagerbestände, kundenspezifische Preise, Finanzdaten und Fulfilment. Magento übernimmt dagegen in erster Linie die Darstellung im E-Commerce und das Einkaufserlebnis im Storefront.  Entscheidend ist jedoch: Die Datenhoheit muss für jede einzelne Entität explizit definiert werden, bevor Synchronisationsregeln entwickelt werden. Sie sollte nicht davon abhängen, was eine API technisch aktualisieren kann.

Was ist eine Magento SAP Business One Integration? 

Eine Magento SAP Business One Integration verbindet die E-Commerce-Plattform mit dem ERP System, sodass Geschäftsdaten automatisch zwischen Storefront und Backoffice ausgetauscht werden, anstatt manuell in beiden Systemen gepflegt werden zu müssen. Typischerweise umfasst eine Integration unter anderem: 

• Kundendaten  

• Produktdaten  

• Lagerbestände  

• Preise  

• Bestellungen  

• Zahlungen  

• Versandinformationen  

• Rechnungen  

• Bestellstatus  

Der Connector von Ingold unterstützt beispielsweise bereits eine bidirektionale Synchronisierung in vielen dieser Bereiche –darunter Kunden, Produkte und Lagerbestände, Bestellungen, Preise, Zahlungen und Versandinformationen.   Eine breite funktionale Abdeckung ist allerdings nur die Grundlage einer professionellen Integration. Was einen funktionierenden Connector von einer wirklich belastbaren Integrationsarchitektur unterscheidet, zeigt sich bei der nächsten Frage. 

Die wichtigste Integrationsfrage: Welches System besitzt die Datenhoheit? 

Jedes Integrationsprojekt stößt früher oder später auf das Konzept des System of Record – also des Systems, in dem eine bestimmte Information als verbindlich und autoritativ gilt. Ein häufiger Fehler besteht darin, die Synchronisationsrichtung danach festzulegen, welche Felder eine API technisch aktualisieren kann.  Die bessere Frage lautet: 

Welches System verantwortet den zugrunde liegenden Geschäftsprozess? 

Eine einfache Regel funktioniert in der Praxis besonders gut:  Das System, in dem bestimmte Geschäftsdaten entstehen und fachlich verwaltet werden, sollte als führende Datenquelle gelten. Alle anderen Systeme sollten diese Daten konsumieren – nicht parallel eine zweite Wahrheit erzeugen.

Typische Datenhoheit zwischen Magento und SAP Business One 

Datenobjekt	Typisches führendes System	Typische Synchronisationsrichtung
Produktstammdaten	SAP oder PIM, abhängig von der Architektur	SAP/PIM → Magento
E-Commerce-Content	Magento oder PIM	→ Magento
Lagerbestand	SAP Business One	SAP → Magento
Kundenspezifische Preise	SAP Business One	SAP → Magento
Registrierung von Webkunden	Magento	Magento → SAP
Verkaufsaufträge	Magento	Magento → SAP
Rechnungen	SAP Business One	SAP → Magento/Kunde
Versandstatus	SAP oder WMS	SAP → Magento
Trackingnummer	SAP oder WMS	SAP → Magento
Zahlungstransaktion	Magento / Payment Gateway	Magento → SAP

Diese Zuordnung ist keine universelle Vorgabe für jedes Unternehmen. Sie zeigt jedoch ein typisches Architekturmodell, bei dem klare Zuständigkeiten verhindern, dass beide Systeme dieselben Geschäftsdaten unabhängig voneinander verändern.  

Welche Daten sollten zwischen Magento und SAP Business One synchronisiert werden? 

Kundendaten  Die Kundensynchronisierung umfasst typischerweise: 

• Registrierungsdaten  

• Rechnungsadressen  

• Lieferadressen  

• bestehende Kundenkonten  

• Gastbestellungen  

• Zuordnung zwischen Magento-Kunden und SAP Business Partners  

• Vermeidung von Dubletten  

Gerade die Dublettenvermeidung ist wichtig. Ohne ein sauberes Matching kann derselbe Kunde schnell mehrfach in unterschiedlichen Systemen angelegt werden.  Der Connector von Ingold behandelt beispielsweise neue Kundenkonten, bestehende Webkunden und Gastkunden als separate Synchronisationspfade und ordnet diese den Business-Partner-Stammdaten in SAP Business One zu.

Sollte Magento oder SAP Business One die Kundendaten führen? 

Die Antwort ist differenziert. Magento ist häufig das System, in dem ein Kundendatensatz erstmals entsteht – etwa durch eine Registrierung oder während des Checkouts.  Sobald dieser Kunde jedoch in ERP-Prozesse eintritt, etwa in: 

• Bonitätsprüfungen  

• Bestellhistorien  

• kundenspezifische Preislogiken  

• Kreditlimits  

• B2B-Vertragsprozesse  

wird SAP Business One häufig zum operativ führenden System.  Magento sollte diesen Datensatz anschließend nicht als unabhängige zweite Datenquelle behandeln, sondern als Abbild der in SAP gepflegten Geschäftsinformationen.  

Produktdaten 

Die Produktsynchronisierung kann zahlreiche Datenarten umfassen: 

• SKU  

• Produkttyp  

• Kategorien  

• Attribute  

• Bilder  

• Sichtbarkeit  

• Produktbeschreibungen  

• konfigurierbare Produkte  

• Bundles  

• gruppierte Produkte  

• Download-Produkte  

Sollten alle Produktdaten aus SAP stammen? 

Nicht unbedingt. ERP-Systeme wie SAP Business One sind hervorragend für kommerzielle und operative Produktinformationen geeignet, beispielsweise: 

• Artikelnummern  

• Kosten  

• Lagereinheiten  

• Maßeinheiten  

• Lagerzuordnungen  

• operative Produktstammdaten  

Für umfangreiche E-Commerce-Inhalte sind ERP-Systeme jedoch meist nicht optimiert.  Marketingtexte, Produktbilder, Kategoriestrukturen, SEO-Inhalte und merchandisingrelevante Daten sind in Magento oder in einem vorgeschalteten PIM-System in der Regel besser aufgehoben. Auch wenn der grundlegende Artikelstamm in SAP Business One angelegt wird, muss deshalb nicht zwangsläufig jeder Produktinhalt aus dem ERP stammen.  

Bestandssynchronisierung 

Die Synchronisierung von Lagerbeständen gehört zu den wertvollsten – und gleichzeitig fehleranfälligsten – Bereichen einer Magento SAP Business One Integration. Der typische Datenfluss lautet:  Verfügbarer Bestand in SAP Business One → Connector → verkaufbarer Bestand in Magento  Dabei reicht es nicht aus, lediglich einen einzigen Bestandswert zu übertragen.  Eine belastbare Architektur muss unter anderem berücksichtigen: 

• physischen Lagerbestand  

• bereits reservierte Mengen  

• offene Bestellungen  

• Reservierungen  

• Sicherheitsbestand  

• Bestände über mehrere Lager hinweg  

Diese Informationen müssen so zusammengeführt werden, dass Magento nur jene Menge als verfügbar ausweist, die tatsächlich verkauft werden darf.  Auch Adobe Commerce spiegelt diese Komplexität in seiner eigenen Architektur wider: Physische Inventory Sources werden von verkaufbaren Mengen getrennt, während Reservierungen und Source-Selection-Logiken für Fulfilment über mehrere Standorte hinweg genutzt werden.  

Sollte Magento oder SAP Business One den Lagerbestand kontrollieren? 

Wenn SAP Business One als zentrales ERP eingesetzt wird, sollte SAP in der Regel auch die führende Instanz für Bestandsdaten bleiben.  Magento zeigt dann den Bestand an, den SAP tatsächlich als verkaufbar definiert.  Problematisch wird es, wenn beide Systeme unabhängig voneinander Änderungen vornehmen – beispielsweise wenn ein Mitarbeiter nach einer Inventur einen Magento-Bestand manuell korrigiert, während SAP weiterhin einen anderen Wert führt.  Genau so entstehen mit der Zeit Abweichungen zwischen beiden Systemen.  

Kundenspezifische Preise 

Für stark B2B-orientierte Händler ist die Preislogik häufig einer der wichtigsten Bereiche der gesamten Integration.  Relevante Preisstrukturen können unter anderem umfassen: 

• SAP-Preislisten  

• Kundengruppenpreise  

• Sonderpreise  

• Mengenrabatte  

• zeitbasierte Rabatte  

• individuelle Vertragspreise  

• Shared-Catalog-Preise in Adobe Commerce  

Adobe Commerce unterstützt unternehmensspezifische Shared Catalogues sowie individuell definierte Produktpreise auf Unternehmensebene. Der Connector von Ingold unterstützt außerdem die Synchronisierung von SAP-Preislisten sowie zeit- und mengenabhängigen Rabatten in den Magento-Storefront.  

Sollte derselbe Preis manuell in Magento und SAP gepflegt werden? 

Nein.  Sobald eine Preisstruktur über einfache B2C Standardpreise hinausgeht, ist es unnötig riskant, denselben Vertragspreis manuell in zwei unterschiedlichen Systemen zu pflegen.  Dadurch entstehen genau jene Datenkonflikte, die eine Integration eigentlich verhindern soll. Für komplexe B2B-Szenarien sollte deshalb klar definiert werden, welches System Preise fachlich führt – und das andere System sollte diese Preise zuverlässig übernehmen. 

Bestellungen 

Der empfohlene Datenfluss führt vom Magento-Checkout direkt zum Verkaufsauftrag in SAP Business One. Dabei reicht es nicht aus, lediglich die grundlegenden Bestelldaten zu übertragen. Eine professionelle Integration sollte unterschiedliche Bestellszenarien und alle kaufmännisch relevanten Informationen berücksichtigen, darunter:

• Bestellungen registrierter Kunden  

• Gastbestellungen  

• optionale Verkaufsauftragsentwürfe  

• Rabatte  

• Steuern  

• Versandkosten und Versandinformationen  

• Zahlungsinformationen  

Besonders wichtig ist dabei ein präzises Mapping der Werte und Datenfelder. Die Gesamtsumme einer Bestellung in Magento muss exakt mit dem entsprechenden Verkaufsauftrag in SAP Business One übereinstimmen. Der Connector von Ingold kann Magento-Webbestellungen direkt in SAP Business One Verkaufsaufträge überführen. Alternativ können Bestellungen zunächst als Verkaufsauftragsentwurf angelegt werden. Damit erhalten SAP-Anwender die Möglichkeit, beispielsweise den Lagerbestand zu prüfen, den Zahlungseingang zu verifizieren oder Kundendaten zu kontrollieren, bevor der Auftrag endgültig bestätigt wird.  Über ein dynamisches Mapping lässt sich außerdem steuern, welche Bestellungen direkt verarbeitet und welche zunächst einem Prüfprozess zugeführt werden.  

Zahlungen und Rechnungen 

Viele Beiträge über Magento-SAP-Integrationen konzentrieren sich auf Bestellungen und Lagerbestände. Dabei wird einer der fehleranfälligsten Bereiche häufig nur oberflächlich behandelt: 

Wie gelangen Zahlungsinformationen vom Payment Gateway über Magento korrekt in SAP Business One? 

Hier ist eine klare Trennung verschiedener Vorgänge und Datenobjekte entscheidend: 

• Zahlungsautorisierung  

• Zahlungserfassung bzw. Capture  

• Transaktions-ID  

• in SAP erzeugte Ausgangsrechnung  

• eigentlicher Zahlungsdatensatz  

Diese Vorgänge hängen miteinander zusammen, sind jedoch keineswegs identisch.  Wer sie innerhalb der Integrationsarchitektur wie ein und dasselbe Objekt behandelt, riskiert Probleme bei der späteren Abstimmung von Bestellungen, Rechnungen und Zahlungseingängen.  In einem sauber konzipierten Prozess kann eine erfolgreiche Zahlung die Rechnungserstellung im E-Commerce-System auslösen. Anschließend werden Bestellung, Rechnung, Zahlungsbeleg und Online-Transaktions-ID gemeinsam an SAP Business One übertragen.  Dadurch erhält die Finanzabteilung einen konsistenten Datensatz, anstatt Informationen nachträglich aus zwei verschiedenen Systemen zusammenführen zu müssen.  

Versand- und Fulfilment-Daten 

Auch Versandinformationen sollten Teil einer durchgängigen Magento-SAP-Integration sein.  Typischerweise umfasst die Synchronisierung: 

• gewählte Versandart  

• Fracht- und Versandkosten  

• Lieferstatus  

• Trackingnummer  

• Aktualisierung des Magento-Bestellstatus  

In der Praxis bedeutet dies beispielsweise, dass Versandart und Versandkosten über die API zwischen den Systemen miteinander verknüpft bleiben.  Wird anschließend eine Trackingnummer im SAP-Lieferschein hinterlegt, kann diese Information an Magento zurückgegeben und dem Kunden in seinen Bestelldetails angezeigt werden.   Damit entsteht ein durchgängiger Informationsfluss:  Magento-Bestellung → SAP-Verkaufsauftrag → Fulfilment → Versand → Trackinginformationen zurück an Magento 

Echtzeit- vs. Batch-Synchronisierung 

Nicht jede Information muss in Echtzeit zwischen Magento und SAP Business One übertragen werden.  Alle Datenarten mit derselben Priorität zu behandeln, ist sogar ein häufiger Architekturfehler. Eine solche Vorgehensweise kann Integrationen unnötig komplex machen und die Systembelastung erhöhen.   Echtzeit- und Batch-Synchronisierung im Vergleich 

Faktor	Echtzeit	Batch
Bestandsgenauigkeit	Höher	Verzögerungen möglich
Bestellverarbeitung	Unmittelbar	Zeitgesteuert
API-Traffic	Ereignisbasiert	Periodische Lastspitzen
Komplexität	Höher	Einfacher
B2B-Preise	Schnellere Aktualisierung	Preise können zwischen Updates veralten
Besonders geeignet für	Kritische operative Daten	Weniger zeitkritische Massendaten

Eine durchdachte Integrationsarchitektur kombiniert beide Ansätze gezielt, anstatt sich pauschal für eine einzige Synchronisationsmethode zu entscheiden.  Ein sinnvolles Modell könnte beispielsweise folgendermaßen aussehen: 

• Lagerbestand: Echtzeit oder ereignisbasiert  

• Bestellungen: nahezu in Echtzeit  

• Preise: Echtzeit oder zeitgesteuert, abhängig von der Änderungshäufigkeit  

• Produktbeschreibungen: zeitgesteuert  

• Historische Daten: Batch-Verarbeitung  

Der entscheidende Punkt lautet: 

Die Synchronisationsgeschwindigkeit sollte sich nach der geschäftlichen Relevanz der jeweiligen Daten richten. 

Eine Änderung des verfügbaren Lagerbestands kann unmittelbar Einfluss darauf haben, ob ein Kunde einen Artikel kaufen kann. Eine Änderung einer Produktbeschreibung hat dagegen in den meisten Fällen nicht dieselbe operative Dringlichkeit.  

Warum SAP Business One Webhooks 2026 besonders relevant sind 

Mit SAP Business One 10.0 Feature Package 2602 wurde die Service Layer um Webhook-Unterstützung erweitert. Dadurch kann SAP Business One externe Anwendungen unmittelbar darüber informieren, wenn relevante Geschäftsobjekte neu angelegt oder aktualisiert werden.  Externe Systeme müssen somit nicht mehr ausschließlich in regelmäßigen Abständen bei SAP nachfragen, ob sich bestimmte Daten geändert haben.  

Klassischer Polling-Ansatz 

Der traditionelle Prozess sieht vereinfacht so aus:  SAP Business One → Connector fragt regelmäßig nach Änderungen → Änderung wird erkannt → Magento wird aktualisiert Der Connector muss SAP also kontinuierlich oder nach einem definierten Zeitplan abfragen. 

Event-Driven Architecture mit Webhooks 

Mit einem ereignisbasierten Ansatz verändert sich der Ablauf: 

Änderung in SAP Business One → Webhook → Connector → Magento-Update 

SAP meldet das relevante Ereignis direkt an den Connector. Dadurch kann die entsprechende Aktualisierung in Magento wesentlich unmittelbarer angestoßen werden. 

Welche Vorteile können Webhooks bieten? 

Zu den praktischen Vorteilen einer ereignisbasierten Architektur gehören: 

• weniger permanentes Polling;  

• schnellere Reaktion auf tatsächliche Geschäftsereignisse;  

• weniger unnötiger API-Traffic;  

• eine sauberere Echtzeitarchitektur;  

• bessere Skalierbarkeit bei wachsendem Bestell- und Datenvolumen.  

Für Unternehmen, die eine möglichst aktuelle Magento SAP Business One Integration benötigen, machen Service-Layer-Webhooks eine ereignisgesteuerte Architektur damit deutlich praktikabler als bei früheren SAP-Business-One-Versionen.

Häufige Architekturfehler bei Magento SAP Integrationen 

Eine Integration kann technisch funktionieren und trotzdem langfristig erhebliche Probleme verursachen.  Besonders häufig treten folgende Architekturfehler auf: 

1. BeideSysteme dürfen dasselbe Datenfeld führen 

Das entspricht dem Beispiel zu Beginn des Artikels:  Magento enthält einen Wert, SAP einen anderen – aber niemand hat definiert, welches System im Konfliktfall maßgeblich ist.  Für kritische Daten muss deshalb eindeutig festgelegt werden:  Wer ist der Eigentümer dieser Information? 

2. Jedesverfügbare Feld wird synchronisiert 

Nicht jedes SAP-Feld gehört nach Magento. Und nicht jedes Magento-Feld muss in SAP Business One vorhanden sein.  Wer standardmäßig sämtliche technisch verfügbaren Daten synchronisiert, erhöht den Entwicklungs- und Wartungsaufwand, ohne zwangsläufig einen zusätzlichen geschäftlichen Nutzen zu schaffen.  Synchronisiert werden sollte, was für den jeweiligen Geschäftsprozess tatsächlich erforderlich ist. 

3. Echtzeit-Synchronisierungwird für alles eingesetzt 

Nicht jede Datenänderung besitzt dieselbe Dringlichkeit. Eine Änderung des Lagerbestands kann unmittelbare Auswirkungen auf die Verkaufsfähigkeit eines Artikels haben. Die Aktualisierung einer Produktbeschreibung hingegen muss normalerweise nicht mit derselben Priorität verarbeitet werden. Wer beide Prozesse technisch gleich behandelt, erzeugt unnötige API-Last, ohne einen entsprechenden geschäftlichen Mehrwert zu erzielen. 

4. Esgibtkeine Konfliktlösungsstrategie 

Wenn beide Systeme theoretisch denselben Datensatz verändern können, muss klar definiert sein, was geschieht, wenn die Werte voneinander abweichen. Eine belastbare Architektur braucht eine eindeutige Regel. Die Hoffnung, dass ein solcher Konflikt niemals auftritt, ist keine Integrationsstrategie. 

5. FehlendeIdempotenz 

Idempotenz ist bei ereignisbasierten Integrationen besonders wichtig. Wird beispielsweise ein Webhook erneut ausgelöst oder eine Bestellung nach einem Fehler nochmals übertragen, sollte die Verarbeitung nicht automatisch einen zweiten identischen Datensatz erzeugen.  Ohne idempotente Verarbeitung können Wiederholungsversuche zu: 

• doppelten Bestellungen,  

• mehrfachen Kundendatensätzen,  

• redundanten Transaktionen oder  

• inkonsistenten Geschäftsobjekten  

führen. Eine wiederholte Verarbeitung desselben Ereignisses sollte stattdessen zuverlässig zum gleichen Endzustand führen. 

6. UnzuverlässigesKunden-Matching 

Kunden ausschließlich anhand von Name und E-Mail-Adresse zuzuordnen, kann langfristig problematisch werden. Ohne einen zuverlässigen eindeutigen Identifier können sich in SAP Business One mit der Zeit doppelte Business-Partner-Datensätze ansammeln.  Gerade bei B2B-Kunden mit mehreren Ansprechpartnern, Standorten oder Benutzern muss die Matching-Logik deshalb sorgfältig geplant werden. 

7. Keine Error Queue

Was geschieht, wenn ein Datensatz nicht synchronisiert werden kann? Eine professionelle Integration benötigt einen definierten Ort, an dem fehlgeschlagene Datensätze landen, damit sie: 

• identifiziert,  

• analysiert,  

• korrigiert und  

• erneut verarbeitet  

werden können.  Ein fehlgeschlagener Datensatz darf nicht einfach verschwinden und unbemerkt zu einem falschen Preis, einer fehlenden Bestellung oder einem inkonsistenten Lagerbestand führen. 

8. FehlendesIntegrationsmonitoring 

Eine Integration, dieerst dann überprüft wird, wenn sich ein Kunde über ein Problem beschwert, wird faktisch nicht ausreichend überwacht.  Monitoring sollte deshalb nicht als optionale Zusatzfunktion betrachtet werden.  Es gehört zur Betriebsarchitektur einer geschäftskritischen Magento SAP Business One Integration.

9. API- und Performance-Grenzenwerdenignoriert 

Hohe Bestellvolumina oder umfangreiche Katalogaktualisierungen können erhebliche Last erzeugen.  Wurde die Architektur nicht für realistische Spitzenlasten ausgelegt, können API- oder Performance-Limits auf einer der beteiligten Plattformen zum Problem werden.  Daher sollten bereits während der Planung unter anderem berücksichtigt werden: 

• erwartetes Transaktionsvolumen;  

• Spitzenlasten;  

• Häufigkeit der Synchronisierung;  

• Größe einzelner Datenpakete;  

• Retry-Mechanismen;  

• Parallelverarbeitung.  

10. Eswirdnur der „Happy Path“ getestet 

Eine Integration wurde nicht ausreichend getestet, nur weil eine saubere Bestellung eines bekannten Kunden mit verfügbarem Lagerbestand erfolgreich übertragen werden konnte.  Das ist lediglich der Idealfall.  Getestet werden sollten ebenfalls Szenarien wie: 

• unbekannte Kunden;  

• doppelte Übertragungen;  

• nicht verfügbare Artikel;  

• Preisabweichungen;  

• abgebrochene Zahlungen;  

• API-Ausfälle;  

• Timeouts;  

• ungültige Daten;  

• wiederholte Webhooks;  

• teilweise fehlgeschlagene Synchronisierungen.  

Erst solche Tests zeigen, wie robust die Architektur im tatsächlichen Tagesgeschäft ist.  

Wie Magento B2B die SAP-Integration verändert 

Die B2B-Funktionen von Adobe Commerce erhöhen die Anforderungen an eine SAP-Integration erheblich.  Dazu gehören unter anderem: 

• Unternehmenskonten  

• mehrere Benutzer innerhalb eines Unternehmenskontos  

• Shared Catalogues  

• kundenspezifische Preise  

• Angebotsprozesse  

• Bestellanforderungen und Purchase Orders  

• Company Credit  

Diese B2B-Entitäten benötigen eigene Synchronisationsregeln. Es reicht nicht aus, die klassische B2C-Integration lediglich zu erweitern.   Eine mögliche Zuordnung sieht beispielsweise so aus:  Magento Company → SAP Business Partner  Company User → SAP-Ansprechpartner  Shared Catalog → SAP-Preisliste  Company Credit → SAP-Kreditlimit  Purchase Order → SAP-Verkaufsauftragsworkflow  Jede dieser Zuordnungen bringt wiederum die zentrale Frage nach der Datenhoheit mit sich. Ein Kreditlimit ist beispielsweise eine finanzielle Kontrollgröße. Diese sollte in den meisten Architekturen aus SAP Business One stammen. Magento B2B sollte dieses Kreditlimit beim Checkout berücksichtigen – anstatt unabhängig davon ein zweites Kreditlimit zu verwalten.  

Magento SAP Business One Integration für EU- und US-Geschäfte 

Für Unternehmen, die sowohl in Europa als auch in den USA verkaufen, reicht es nicht aus, Magento und SAP Business One lediglich technisch miteinander zu verbinden.  Die Integrationsarchitektur muss unterschiedliche Märkte, Währungen, Steuerlogiken, Lagerstandorte, Zahlungsarten und Versandprozesse abbilden können. Gleichzeitig sollte vermieden werden, für jeden Markt eine vollständig separate Systemlandschaft aufzubauen.  Zu den wichtigsten Bereichen gehören: 

Multi-Website-Architektur 

Magento unterstützt mehrere Websites und Stores innerhalb einer Installation. Dadurch können Unternehmen beispielsweise separate Storefronts für Deutschland, andere EU-Märkte und die USA betreiben und gleichzeitig eine gemeinsame technische Basis nutzen.  Die Integration mit SAP Business One muss jedoch eindeutig definieren, wie diese Websites den entsprechenden: 

• Kundengruppen,  

• Preislisten,  

• Lagern,  

• Währungen,  

• Steuerregeln und  

• Geschäftsprozessen  

zugeordnet werden. 

Währungen 

Ein internationaler Magento-Shop kann unterschiedliche Währungen verwenden.  Die Integration muss deshalb festlegen, welche Währung für: 

• Bestellungen,  

• Preise,  

• Zahlungen,  

• Gutschriften und  

• Rechnungen  

maßgeblich ist und wie diese Informationen an SAP Business One übergeben werden. 

Steuerlogik 

Die steuerliche Behandlung einer Transaktion kann je nach Land, Kunde und Geschäftsmodell unterschiedlich ausfallen.  Besonders relevant ist die Unterscheidung zwischen: 

• B2B und B2C,  

• nationalen und grenzüberschreitenden Verkäufen,  

• EU- und Nicht-EU-Transaktionen.  

Die Integrationsarchitektur sollte daher eindeutig definieren, welches System die steuerlich relevanten Informationen führt und wie Magento und SAP Business One diese Daten austauschen. 

Mehrere Lager 

Unternehmen mit EU- und US-Geschäft können Waren aus unterschiedlichen Lagerstandorten versenden.  Hier muss die Integration beispielsweise klären: 

• Welcher Magento-Store greift auf welches Lager zu?  

• Welche Bestände dürfen in welchem Markt verkauft werden?  

• Wie werden verfügbare Mengen berechnet?  

• Wie werden Bestandsänderungen zwischen SAP und Magento synchronisiert?  

Zahlungsarten 

Die bevorzugten Zahlungsmethoden können sich zwischen europäischen und US-amerikanischen Märkten deutlich unterscheiden.  Magento kann die Customer Experience und den Checkout steuern, während SAP Business One die für Finanzprozesse relevanten Zahlungsinformationen erhält.  Entscheidend ist ein konsistentes Mapping zwischen beiden Systemen. 

Versandregeln 

Auch Versanddienstleister, Lieferoptionen und Frachtkosten unterscheiden sich je nach Markt.  Eine robuste Integration muss sicherstellen, dass die in Magento ausgewählte Versandart korrekt an SAP Business One übertragen und der spätere Fulfilment-Status wiederum an Magento zurückgegeben wird. 

Kundenspezifische Preislisten 

Gerade im internationalen B2B-Commerce können Preise je nach: 

• Kunde,  

• Kundengruppe,  

• Region,  

• Währung,  

• Bestellmenge oder  

• Vertragsvereinbarung  

variieren.  Eine zentral in SAP Business One gepflegte Preislogik kann dabei helfen, Magento-Storefronts in unterschiedlichen Märkten mit den jeweils relevanten Preisen zu versorgen. 

Lokalisierung 

SAP Business One unterstützt zahlreiche länderspezifische Lokalisierungen, darunter sowohl europäische Märkte als auch die USA.  Für international tätige Unternehmen bedeutet dies jedoch nicht, dass eine einzige Standardkonfiguration automatisch alle Anforderungen erfüllt. 

Die Integrationsarchitektur muss vielmehr berücksichtigen, welche Daten und Prozesse global vereinheitlicht werden können und welche marktspezifisch bleiben müssen.

EU-Magento-SAP-Architekturen auf ViDA vorbereiten 

Für Unternehmen mit Geschäftstätigkeit innerhalb der Europäischen Union gewinnt zusätzlich das Thema VAT in the Digital Age (ViDA) an Bedeutung. Die ViDA-Initiative der EU verändert schrittweise die Rahmenbedingungen rund um Mehrwertsteuer, elektronische Rechnungsstellung und digitale Meldepflichten.  Für Magento-SAP-Integrationsprojekte bedeutet das nicht, dass jedes Unternehmen sofort seine komplette Architektur umbauen muss.  Es bedeutet jedoch, dass Unternehmen bei neuen oder modernisierten Integrationen bereits heute berücksichtigen sollten, wie steuerlich relevante Daten langfristig strukturiert, übertragen und nachvollziehbar gespeichert werden.  Zu den wichtigen Architekturfragen gehören: 

• Welches System ist für Rechnungen führend?  

• Wo werden steuerlich relevante Stammdaten gepflegt?  

• Wie werden strukturierte Rechnungsdaten erzeugt?  

• Wie werden grenzüberschreitende Umsatzsteuerinformationen verarbeitet?  

• Wie lassen sich elektronische Dokumentenprozesse integrieren?  

• Wie wird die Nachvollziehbarkeit von Transaktionen sichergestellt?  

Das zentrale Architekturprinzip bleibt auch hier dasselbe:  Steuerlich relevante Informationen sollten nicht unkontrolliert in mehreren Systemen parallel gepflegt werden.  Stattdessen sollte eindeutig festgelegt sein, welches System die jeweilige Information führt und wie sie an andere Systeme weitergegeben wird.  

Direkter Connector oder Middleware? 

Eine der wichtigsten Architekturentscheidungen bei einer Magento SAP Business One Integration lautet: Soll Magento direkt mit SAP Business One verbunden werden oder sollte eine Middleware zwischen beiden Systemen eingesetzt werden? Beide Ansätze haben ihre Berechtigung. Die richtige Entscheidung hängt von der bestehenden IT-Landschaft, der Anzahl der beteiligten Systeme, den Integrationsanforderungen und der langfristigen Architekturstrategie ab. 

Architektur	Direkte API-Integration	Middleware
Komponenten	Weniger zusätzliche Komponenten	Zusätzliche Plattform
Datentransformation	Im individuellen Connector	Über Middleware-Mappings
Monitoring	Muss entsprechend implementiert werden	Häufig bereits integriert
Flexibilität	Hoch	Hoch
Anbieterabhängigkeit	Je nach Architektur potenziell geringer	Abhängigkeit vom Middleware-Anbieter
Komplexität	Anwendungsspezifisch	Zusätzliche Integrationsschicht

Wann kann Middleware sinnvoll sein? 

Middleware kann besonders sinnvoll sein, wenn ein Unternehmen eine Vielzahl unterschiedlicher Systeme miteinander verbinden muss.  Typische Szenarien sind: 

• mehrere ERP-Systeme;  

• verschiedene E-Commerce-Plattformen;  

• CRM-Systeme;  

• PIM;  

• WMS;  

• Marktplätze;  

• zentrale Enterprise-Integration;  

• komplexe Orchestrierungsprozesse.  

In solchen Umgebungen kann eine zentrale Integrationsplattform dabei helfen, Datenflüsse und Schnittstellen über viele Anwendungen hinweg zu standardisieren. 

Wann kann eine direkte Integration sinnvoll sein? 

Eine direkte Architektur kann besonders interessant sein, wenn: 

• Magento und SAP Business One die primären Systeme sind;  

• eine enge Kontrolle über die Integration gewünscht ist;  

• geringe Latenz wichtig ist;  

• möglichst wenige zusätzliche Infrastrukturkomponenten eingesetzt werden sollen;  

• die Integration gezielt an individuelle Geschäftsprozesse angepasst werden muss.  

Wichtig ist dabei, direkte Integrationen nicht pauschal als „besser“ zu bezeichnen.  Die richtige Architektur hängt vom jeweiligen Anwendungsszenario ab.  Der Connector von Ingold verfolgt einen direkten Integrationsansatz zwischen Magento und SAP Business One, ohne dass ein zusätzlicher Drittanbieter-Server als zwingende Vermittlungsschicht erforderlich ist.  

Wie lässt sich eine Magento SAP Business One Integration überwachen? 

Eine Integration ist kein einmaliges Entwicklungsprojekt, das nach dem Go-live einfach unbeaufsichtigt weiterläuft.  Sie ist eine geschäftskritische Verbindung zwischen E-Commerce und ERP.  Entsprechend wichtig ist ein kontinuierliches Integration Monitoring. Dabei sollten unter anderem folgende Bereiche überwacht werden: 

• Synchronisationsprotokolle  

• fehlgeschlagene Datensätze  

• Retry-Mechanismen  

• Warnmeldungen und Alerts  

• Error bzw. Dead-Letter Queues  

• Datenabgleiche zwischen den Systemen  

• Bestellsummen  

• Bestandsabweichungen  

• doppelte Kundendatensätze  

• API-Latenz  

Ein gutes Monitoring beantwortet nicht nur die Frage:  „Ist die Schnittstelle online?“  Viel wichtiger sind Fragen wie:  „Werden alle Bestellungen vollständig übertragen?“  „Wie lange dauert eine Bestandsaktualisierung?“  „Wie viele Datensätze schlagen fehl?“  „Gibt es Preisabweichungen zwischen Magento und SAP?“  „Werden Kunden doppelt angelegt?“  Wichtige KPIs für das Integrationsmonitoring  Order Sync Success Rate  Welcher Anteil der Magento-Bestellungen wird erfolgreich und vollständig an SAP Business One übertragen?  Eine hohe technische Verfügbarkeit allein reicht nicht aus, wenn einzelne Bestellungen regelmäßig in Fehlerzuständen hängen bleiben.  Inventory Sync Latency  Wie viel Zeit vergeht zwischen einer Bestandsänderung in SAP Business One und der entsprechenden Aktualisierung in Magento?  Gerade bei Produkten mit hoher Umschlagshäufigkeit kann diese Kennzahl geschäftskritisch sein.  Fehlgeschlagene Datensätze pro 1.000 Transaktionen  Diese Kennzahl macht Integrationsqualität über längere Zeiträume vergleichbar.  Ein plötzlicher Anstieg kann beispielsweise auf: 

• Mapping-Probleme,  

• API-Änderungen,  

• fehlerhafte Stammdaten oder  

• Performance-Probleme  

hinweisen. 

Anzahl der Preisabweichungen 

Bei B2B-Shops mit kundenspezifischen Preislisten sollte überprüft werden, ob die in Magento angezeigten Preise tatsächlich mit den vorgesehenen SAP-Preisen übereinstimmen. 

Duplicate Customer Creation Rate 

Wie häufig wird derselbe Kunde mehrfach in SAP Business One angelegt?  Eine steigende Dublettenquote ist häufig ein Hinweis darauf, dass Matching-Regeln oder eindeutige Identifikatoren verbessert werden müssen.  Diese Kennzahlen verwandeln das Monitoring von einer rein technischen Kontrollfunktion in ein Instrument zur Messung der tatsächlichen Integrationsqualität.  

Magento SAP Business One Integration: Checkliste vor dem Projektstart 

Bevor die eigentliche Entwicklung beginnt, sollten die wichtigsten Architekturentscheidungen dokumentiert werden. 

Datenhoheit definieren 

• System of Record für jede relevante Entität festlegen  

• Verantwortlichkeit für Produktdaten definieren  

• Verantwortlichkeit für Lagerbestände definieren  

• Verantwortlichkeit für Preise definieren  

• Verantwortlichkeit für Kunden- und Finanzdaten definieren  

Synchronisationslogik festlegen 

• Synchronisationsrichtung definieren  

• Echtzeit- oder Batch-Anforderungen bestimmen  

• Regeln für Kundenzuordnung festlegen  

• SKU-Mapping definieren  

• Lager-Mapping definieren  

• Preislisten-Mapping festlegen  

• Steuerlogik und Datenhoheit definieren  

• Zahlungsfluss dokumentieren  

Fehlerbehandlung und Betrieb planen 

• Error Handling definieren  

• Retry-Verhalten festlegen  

• Monitoring implementieren  

• Sicherheitsanforderungen dokumentieren  

• Performance-Ziele definieren  

• Rollback- und Recovery-Prozess festlegen  

Diese Entscheidungen sollten vor der Implementierung getroffen werden. Andernfalls werden grundlegende Architekturfragen häufig erst dann sichtbar, wenn bereits Daten synchronisiert werden und Konflikte im laufenden Betrieb auftreten.

Wann ist die Zusammenarbeit mit einer Magento SAP Agentur sinnvoll? 

Nicht jede Magento-SAP-Integration erfordert dieselbe technische Komplexität.  Bei einfachen Geschäftsmodellen mit einem Store, wenigen Preisregeln und überschaubarem Bestellvolumen kann die Architektur relativ geradlinig sein.  Spezialisierte Unterstützung wird insbesondere dann relevant, wenn mehrere komplexe Geschäftsprozesse gleichzeitig abgebildet werden müssen.  Typische Beispiele sind: 

• komplexe B2B-Preisstrukturen;  

• mehrere Lager;  

• Magento Multi-Store-Umgebungen;  

• parallele Geschäftsaktivitäten in der EU und den USA;  

• individuelle SAP-Felder;  

• hohes Bestellvolumen;  

• SAP-Umgebungen mit mehreren Gesellschaften;  

• komplexe Zahlungsprozesse;  

• individuelle Genehmigungs- und Freigabeworkflows.  

In diesen Szenarien besteht die eigentliche Herausforderung nicht darin, eine API mit einer anderen API zu verbinden. Die Herausforderung besteht darin, eine Integrationsarchitektur zu entwickeln, die die tatsächlichen Geschäftsprozesse korrekt widerspiegelt und auch bei wachsendem Daten- und Transaktionsvolumen zuverlässig funktioniert. 

Wie Ingold Solutions Magento SAP Business One Integrationen umsetzt 

Eine erfolgreiche Magento SAP Business One Integration beginnt nicht mit dem bloßen Verbinden zweier APIs. Entscheidend ist zunächst ein klares Verständnis der Geschäftsprozesse, der Datenhoheit und der Anforderungen an die Synchronisierung. Ingold Solutions verfolgt einen Integrationsansatz, bei dem Magento und SAP Business One direkt miteinander verbunden werden können. Dabei werden die relevanten Datenflüsse an die individuellen Anforderungen des jeweiligen Unternehmens angepasst.  Zu den zentralen Bereichen gehören: 

Direkte Verbindung 

Die Integration kann direkt zwischen Magento und SAP Business One erfolgen, ohne dass zwingend ein zusätzlicher Drittanbieter-Server als Vermittlungsschicht erforderlich ist.  Eine solche Architektur kann insbesondere dann sinnvoll sein, wenn Magento und SAP Business One die zentralen Systeme innerhalb der E-Commerce-Landschaft darstellen. 

Anpassbare API 

Nicht jedes Unternehmen arbeitet mit denselben Datenstrukturen, Preislogiken oder Geschäftsprozessen.  Daher sollte eine Integration so konzipiert sein, dass sie sich an individuelle Anforderungen anpassen lässt – beispielsweise an: 

• benutzerdefinierte SAP-Felder;  

• spezifische Magento-Attribute;  

• individuelle Preislogiken;  

• unterschiedliche Kundengruppen;  

• spezielle Bestellprozesse;  

• unternehmensspezifische Fulfilment-Workflows.  

Ereignisgesteuerte Synchronisierung 

Bei zeitkritischen Daten kann eine ereignisgesteuerte Synchronisierung eingesetzt werden. Anstatt sämtliche Informationen permanent oder in kurzen Intervallen abzufragen, kann die Integration auf relevante Geschäftsereignisse reagieren.  Dies ist insbesondere für Daten interessant, bei denen Aktualität eine hohe operative Bedeutung besitzt, etwa: 

• Bestellungen;  

• Lagerbestände;  

• Preise;  

• Kundenänderungen;  

• Versandstatus.  

Kundendaten 

Neue und bestehende Kunden sowie Gastbestellungen können zwischen Magento und SAP Business One synchronisiert werden.  Dabei ist eine saubere Zuordnung zu den Business-Partner-Daten in SAP entscheidend, damit Dubletten vermieden und bestehende Geschäftsbeziehungen korrekt erkannt werden. 

Produkte und Lagerbestände 

Produkt- und Bestandsinformationen können zwischen beiden Systemen ausgetauscht werden.  Dabei sollte klar definiert sein, welche Produktinformationen aus SAP stammen und welche Daten weiterhin in Magento oder einem PIM gepflegt werden.  Für Bestände gilt insbesondere:  SAP Business One sollte in einer ERP-zentrierten Architektur in der Regel die maßgebliche Quelle für verfügbare Bestände bleiben.  Magento übernimmt anschließend die für den E-Commerce relevante Darstellung der Verfügbarkeit. 

Bestellungen 

Magento-Bestellungen können an SAP Business One übertragen und dort als Verkaufsauftrag oder – abhängig vom gewünschten Prozess – zunächst als Verkaufsauftragsentwurf angelegt werden.  Damit lassen sich sowohl weitgehend automatisierte Prozesse als auch Workflows mit manuellen Prüf- und Freigabeschritten abbilden. 

Preisgestaltung 

Die Integration kann SAP-Preislisten sowie zeit- und mengenabhängige Preisregeln berücksichtigen.  Gerade im B2B-E-Commerce ist dies entscheidend, wenn unterschiedliche Kunden individuelle Konditionen erhalten.  Anstatt Preise parallel in Magento und SAP Business One zu pflegen, kann eine zentrale Preislogik dazu beitragen, Inkonsistenzen zu reduzieren. 

Zahlungen 

Zahlungsinformationen aus Magento und den eingesetzten Payment Gateways können mit den entsprechenden Geschäftsprozessen in SAP Business One verbunden werden.  Dabei sollte zwischen Autorisierung, Zahlungserfassung, Transaktionsdaten, Rechnung und Zahlungsbuchung unterschieden werden. 

Versand 

Auch Versandinformationen können Bestandteil der Integration sein.  Dazu gehören beispielsweise: 

• Versandart;  

• Versandkosten;  

• Lieferstatus;  

• Trackingnummern;  

• Statusaktualisierungen in Magento.  

Auf diese Weise kann der Datenfluss nach der Bestellung bis in den Fulfilment-Prozess fortgeführt werden. 

Mehrere Magento-Websites 

Für international tätige Unternehmen kann eine SAP-Business-One-Integration mehrere Magento-Websites berücksichtigen.  Dies ist insbesondere relevant, wenn unterschiedliche Storefronts für verschiedene: 

• Länder;  

• Sprachen;  

• Währungen;  

• Marken;  

• B2B- und B2C-Geschäftsmodelle  

betrieben werden.  Die zentrale Herausforderung besteht darin, die jeweiligen Magento-Websites sauber den entsprechenden SAP-Prozessen, Lagern, Preislisten und Kundengruppen zuzuordnen. 

Individuelle Entwicklung 

Standardisierte Integrationen decken nicht jedes Geschäftsmodell vollständig ab.  Individuelle Anforderungen können beispielsweise entstehen durch: 

• spezielle Freigabeprozesse;  

• kundenspezifische Preisberechnungen;  

• zusätzliche SAP-Felder;  

• besondere Versandlogiken;  

• individuelle B2B-Prozesse;  

• mehrere Lager oder Gesellschaften.  

Die Architektur sollte deshalb nicht nur den aktuellen Prozess abbilden, sondern ausreichend flexibel sein, um zukünftige Anforderungen zu unterstützen. 

Monitoring und Support 

Auch nach dem Go-live muss die Integration überwacht werden.  Synchronisationsfehler, API-Probleme, fehlgeschlagene Bestellungen oder Datenabweichungen sollten frühzeitig erkannt werden, bevor sie sich auf Kunden oder interne Geschäftsprozesse auswirken.  Damit wird Monitoring zu einem festen Bestandteil des laufenden Integrationsbetriebs und nicht erst zu einer Maßnahme, wenn bereits ein Problem aufgetreten ist.   Fazit: Eine erfolgreiche Integration beginnt mit klarer Datenhoheit  Der Erfolg einer Magento SAP Business One Integration wird nicht daran gemessen, wie viele Felder zwischen zwei Systemen synchronisiert werden können.  Entscheidend ist vielmehr, ob für jede wichtige Datenentität vier grundlegende Fragen eindeutig beantwortet sind:  Wer besitzt die Datenhoheit?  In welche Richtung werden die Daten synchronisiert?  Wann müssen sie synchronisiert werden?  Was geschieht, wenn die Synchronisierung fehlschlägt?  Wenn diese Fragen vor Beginn der Entwicklung geklärt werden, entsteht eine Architektur, die nicht nur technisch funktioniert, sondern auch die tatsächlichen Geschäftsprozesse zuverlässig unterstützt.  Für Unternehmen mit komplexen B2B-Preisstrukturen, mehreren Magento-Websites, internationalen EU- und US-Geschäften, mehreren Lagern oder individuellen SAP-Prozessen wird diese Architekturentscheidung besonders wichtig.  Ingold Solutions verbindet Magento und SAP Business One mit einem Integrationsansatz, der auf direkte Konnektivität, individuell anpassbare Datenflüsse und die Automatisierung zentraler E-Commerce- und ERP-Prozesse ausgerichtet ist.  Das Ziel sollte dabei nicht darin bestehen, möglichst viele Daten zwischen zwei Plattformen zu bewegen.  Das Ziel ist eine Integrationsarchitektur, in der Magento und SAP Business One jeweils genau die Aufgaben übernehmen, für die sie vorgesehen sind – und beide Systeme jederzeit mit konsistenten, nachvollziehbaren und geschäftlich relevanten Daten arbeiten.