Daten-Mapping zwischen ERP und Shop: Feldzuordnung richtig

Daten-Mapping beschreibt den Prozess der Zuordnung von Feldern eines Quellsystems zu Feldern eines Zielsystems. In der ERP-Shop-Integration bedeutet das konkret: Welches SAP-Feld wird in welches Shopware-Feld geschrieben? Wie wird ein SAP-Datentyp in den Shopware-Datentyp konvertiert? Welche Geschäftslogik wird bei der Transformation angewendet?

Die Kritikalität des Mappings wird oft unterschätzt. Ein fehlerhaftes Mapping führt nicht sofort zu einem sichtbaren Fehler -- die Daten fließen, aber sie sind falsch. Preise werden ohne Mehrwertsteuer im Shop angezeigt, Lagerbestände werden als Stück statt als Karton interpretiert, oder Kundendaten werden dem falschen Account zugeordnet. Solche Fehler fallen erst auf, wenn ein Kunde eine falsche Rechnung erhält oder ein Artikel als verfügbar angezeigt wird, der längst ausverkauft ist.

Laut einer Untersuchung von Gartner investieren erfolgreiche Integrationsprojekte 25 bis 30 Prozent der Projektzeit in die Mapping-Phase (Gartner, 2025). Diese Investition zahlt sich aus: Ein sauberes Mapping reduziert die Fehlerrate in der Produktionsphase um den Faktor vier und senkt die Nachbearbeitungskosten erheblich. Für die API-Entwicklung ist das Mapping-Dokument die zentrale Spezifikation.

Nicht jedes Feld-Mapping ist gleich komplex. In der Praxis unterscheiden wir fünf Mapping-Typen, die sich in ihrem Transformationsaufwand unterscheiden und in der Middleware jeweils anders implementiert werden.

Artikelstammdaten sind der umfangreichste Mapping-Bereich. Ein typischer ERP-Artikeldatensatz umfasst 80 bis 150 Felder (Projekterfahrung), von denen je nach Anforderung 30 bis 60 im Shop benötigt werden. Die Herausforderung liegt nicht nur in der Anzahl der Felder, sondern in den strukturellen Unterschieden: SAP arbeitet mit einem flachen Artikelmodell und separaten Varianten-Tabellen, während Shopware Produkte mit konfigurierbaren Eigenschaftsgruppen und Varianten als eigene Entitäten abbildet.

Besonders komplex ist das Varianten-Mapping. In SAP werden Varianten häufig als separate Artikel mit einer übergeordneten Stückliste oder Matrix verwaltet. In Shopware sind Varianten Kindelemente eines Elternprodukts, die über Eigenschaftsgruppen (Größe, Farbe, Material) konfiguriert werden. Die Middleware muss die SAP-Variantenstruktur analysieren, die Eigenschaftsgruppen ableiten und die Zuordnung zwischen SAP-Varianten-Codes und Shopware-Eigenschaftswerten herstellen.

Das Preismapping gehört zu den fehleranfälligsten Bereichen der ERP-Shop-Integration. Der Hauptgrund: ERP-Systeme arbeiten in der Regel mit Nettopreisen, während Shop-Systeme je nach B2B/B2C-Konfiguration Brutto- oder Nettopreise anzeigen. Die Middleware muss den korrekten Steuersatz ermitteln und den Bruttopreis berechnen -- wobei der Steuersatz je nach Produktkategorie, Kundenstandort und Lieferland variieren kann.

Bei kundenindividuellen Preisen multipliziert sich die Komplexität. SAP Business One unterstützt bis zu zehn Preislisten pro Artikel. Jede Preisliste kann Staffelpreise (mengenabhängig) und Zeiträume (gültig von/bis) enthalten. In Shopware werden diese Strukturen über Preisregeln und Kundengruppen abgebildet. Das Mapping muss definieren: Welche SAP-Preisliste entspricht welcher Shopware-Kundengruppe? Wie werden Staffelpreise in Shopware-Preisstaffeln überführt? Wie werden zeitlich befristete Sonderpreise behandelt?

Laut einer Erhebung des EHI Retail Institute nutzen 68 Prozent (Projekterfahrung) der B2B-Händler kundenindividuelle Preismodelle (EHI Retail Institute, 2025). Das korrekte Preismapping ist damit für die Mehrheit der B2B-Integrationsprojekte geschäftskritisch. Ein Fehler beim Preismapping -- etwa eine fehlende MwSt-Berechnung oder ein falsch zugeordneter Staffelpreis -- kann erhebliche finanzielle Auswirkungen haben.

Validierung ist die Schutzschicht zwischen Transformation und Übertragung. Bevor ein gemappter Datensatz an das Zielsystem gesendet wird, prüft die Middleware die Daten auf Vollständigkeit, Konsistenz und Gültigkeit. Fehlerhafte Datensätze werden nicht übertragen, sondern in einer Fehlerliste gesammelt und dem Administrator gemeldet.

Wichtige Validierungsregeln umfassen Pflichtfeld-Prüfungen (Artikelnummer, Preis, Maßeinheit müssen vorhanden sein), Wertebereichs-Prüfungen (Preise dürfen nicht negativ sein, Bestände nicht kleiner als null), Referenz-Prüfungen (die referenzierte Kundengruppe muss im Shop existieren), Format-Prüfungen (Artikelnummern müssen dem definierten Format entsprechen) und Plausibilitäts-Prüfungen (Bruttopreis muss größer als Nettopreis sein). Laut einer Studie von IBM reduzieren systematische Validierungsregeln die Fehlerrate bei Datenmigrationen um 75 bis 85 Prozent (IBM Data Quality Study, 2024).

Ein Mapping-Dokument ist die zentrale Spezifikation einer ERP-Shop-Integration. Es definiert jede Feldzuordnung, die Transformationslogik, die Validierungsregeln und die Datenhoheit (welches System führt welches Feld). Dieses Dokument wird vor der Implementierung erstellt und von beiden Fachabteilungen -- IT und Fachbereich -- abgenommen.

Bewährt hat sich eine tabellarische Struktur mit den folgenden Spalten: Quellsystem, Quellfeld, Quelldatentyp, Zielsystem, Zielfeld, Zieldatentyp, Mapping-Typ, Transformationsregel, Validierungsregel und Datenhoheit. Für eine typische SAP-Shopware-Integration umfasst das Mapping-Dokument 150 bis 300 Zeilen (Projekterfahrung) -- eine Investition, die sich durch reduzierte Implementierungsfehler und einfachere Wartung vielfach auszahlt.

Das Mapping-Dokument sollte versioniert und in einem für alle Beteiligten zugänglichen Format gepflegt werden. Änderungen am Mapping -- etwa durch neue ERP-Felder oder geänderte Shop-Anforderungen -- werden dokumentiert und durchlaufen einen Freigabeprozess. Dieses Vorgehen stellt sicher, dass die Middleware-Konfiguration stets dem aktuellen Stand des Mapping-Dokuments entspricht.

Für internationale B2B-Shops kommt eine zusätzliche Mapping-Dimension hinzu: die Sprachzuordnung. Artikelbezeichnungen, Produktbeschreibungen und Maßeinheiten können in SAP mehrsprachig gepflegt sein. Die Middleware muss die Sprachcodes zwischen den Systemen mappen (SAP nutzt ISO-Codes wie 'DE', 'EN', Shopware verwendet Locale-Codes wie 'de-DE', 'en-GB') und die übersetzten Felder den korrekten Sprachversionen im Shop zuordnen.

Eine besondere Herausforderung ist der Umgang mit fehlenden Übersetzungen. Wenn ein Artikel in SAP nur auf Deutsch gepflegt ist, aber der Shop auch eine englische Version benötigt, muss die Middleware entscheiden: Wird der deutsche Text als Fallback verwendet, ein Platzhalter eingesetzt oder der Artikel auf der englischen Seite ausgeblendet? Diese Fallback-Logik muss im Mapping konfiguriert und mit dem Fachbereich abgestimmt werden.

Die meisten ERP-Shop-Integrationen sind bidirektional: Stammdaten fließen vom ERP in den Shop, Bestellungen und Kundendaten fließen vom Shop zurück ins ERP. Für jeden Datenfluss wird ein eigenes Mapping benötigt -- und die Mapping-Richtung beeinflusst die Transformationslogik erheblich.

Beim Bestellmapping (Shop zu ERP) müssen Shopware-Strukturen in SAP-Aufträge konvertiert werden. Shopware-Positionen werden zu SAP-Auftragspositionen, Shopware-Zahlungsmethoden zu SAP-Zahlungsbedingungen, Shopware-Versandmethoden zu SAP-Versandarten. Dieses Reverse-Mapping erfordert eigene Lookup-Tabellen und Validierungsregeln. Die Fehlerbehandlung ist hier besonders kritisch: Ein nicht zuordenbarer Bestellwert darf nicht zum Datenverlust führen, sondern muss einen Klärungsfall in der Middleware erzeugen.

Ein systematisches Mapping erfordert systematische Tests. Für jede Mapping-Regel sollte mindestens ein Testfall existieren, der die korrekte Transformation verifiziert. In der Praxis hat sich ein dreistufiger Testansatz bewährt: Unit-Tests für einzelne Mapping-Regeln (wird der Nettopreis korrekt in den Bruttopreis konvertiert?), Integrationstests mit realen Datensätzen (wird ein vollständiger SAP-Artikel korrekt als Shopware-Produkt angelegt?) und End-to-End-Tests für den gesamten Datenfluss (wird eine Bestellung im Shop korrekt als SAP-Auftrag angelegt?).

Automatisierte Mapping-Tests können in die CI/CD-Pipeline integriert werden: Bei jeder Änderung am Mapping-Code werden alle Tests ausgeführt und Regressionen sofort erkannt. Dieser Ansatz ist besonders wertvoll bei langlebigen Integrationsprojekten, bei denen über Monate oder Jahre hinweg neue Felder hinzukommen und bestehende Mappings angepasst werden.

Die Erfahrung aus zahlreichen Integrationsprojekten zeigt wiederkehrende Mapping-Fehler, die mit der richtigen Vorgehensweise vermeidbar sind.

Ein Daten-Mapping ist kein statisches Dokument. Im Laufe einer Integration werden Felder hinzugefügt, Transformationsregeln angepasst und Validierungen verschärft. Ohne eine saubere Versionierung geht der Überblick schnell verloren: Welche Version des Mappings läuft aktuell in Produktion? Welche Änderung hat den Fehler verursacht? Kann die letzte Änderung rückgängig gemacht werden?

Die Middleware speichert Mapping-Konfigurationen versioniert -- ähnlich wie Quellcode in einem Versionskontrollsystem. Jede Änderung erhält einen Zeitstempel, den Namen des Bearbeiters und eine Beschreibung der Änderung. Bei Problemen kann die Middleware auf eine vorherige Mapping-Version zurückgesetzt werden, ohne dass die Integration neu implementiert werden muss. Laut einer Untersuchung von Gartner reduziert die Versionierung von Mapping-Konfigurationen die Fehleranalysezeit bei Integrationsproblemen um 50 Prozent (Gartner, 2025).

Das Mapping von Bestandsdaten erfordert besondere Aufmerksamkeit, da hier mehrere Werte aus dem ERP zu einem einzigen Shop-Wert aggregiert werden müssen. Der physische Lagerbestand in SAP setzt sich zusammen aus dem Gesamtbestand abzüglich reservierter Mengen, gebundener Mengen (für offene Aufträge) und Sicherheitsbestand. Erst der resultierende verfügbare Bestand wird in den Shop übertragen.

Bei Multi-Warehouse-Szenarien multipliziert sich die Komplexität: Bestände aus mehreren Lagern müssen je nach Geschäftslogik summiert, das Maximum gebildet oder standortspezifisch angezeigt werden. Die Middleware implementiert die Aggregationslogik als konfigurierbare Regel, die pro Artikelkategorie oder Kundengruppe unterschiedlich sein kann. Darüber hinaus müssen Mindestbestellmengen und Verpackungseinheiten berücksichtigt werden -- ein Artikel, der nur in 10er-Kartons verkauft wird, zeigt den Bestand nicht in Einzelstücken, sondern in verfügbaren Kartons an.

Das Mapping von Kundenstammdaten ist im B2B-Kontext besonders komplex, weil B2B-Kunden häufig hierarchische Strukturen aufweisen: Ein Konzern hat mehrere Tochtergesellschaften, jede Tochtergesellschaft hat mehrere Standorte, und jeder Standort hat möglicherweise eigene Lieferadressen und Ansprechpartner. In SAP Business One werden diese Strukturen über Geschäftspartner-Hierarchien und Kontaktpersonen abgebildet.

Die Middleware muss diese Hierarchien in das Kundenmodell des Shops überführen. In Shopware können Kunden-Accounts mit mehreren Adressen und Ansprechpartnern angelegt werden, aber die hierarchische Zuordnung (welche Tochtergesellschaft gehört zu welchem Konzern) erfordert Custom Fields oder spezielle B2B-Erweiterungen. Das Mapping muss definieren, auf welcher Hierarchie-Ebene Preiskonditionen gelten (Konzernpreis oder Standortpreis) und welche Berechtigungen jeder Benutzer innerhalb der Hierarchie hat. Laut einer Analyse des EHI Retail Institute haben 45 Prozent (Projekterfahrung) der B2B-Kunden mehr als fünf unterschiedliche Lieferadressen (EHI Retail Institute, 2025), was die Relevanz eines durchdachten Adress-Mappings unterstreicht.