Datenmapping bei der ERP-Migration: PlentyONE und Odoo fehlerfrei synchronisieren
Der Datentransport ist bei einer ERP-Migration das gelöste Problem. Das ungelöste ist die semantische Zuordnung: Ein Feld, das PlentyONE als einfache Eigenschaft führt, kann im relationalen Datenmodell von Odoo eine eigene Objektbeziehung erfordern. Wird diese Übersetzung falsch aufgesetzt, entstehen keine Fehlermeldungen, sondern falsche Verknüpfungen – sichtbar oft erst Wochen nach dem Go-Live.
Dieser Beitrag behandelt das Mapping als das, was es ist: eine Architekturaufgabe mit klaren Regeln. Business Keys statt Surrogate Keys, dokumentierte Verantwortlichkeiten je Entität, Validierung vor dem Import. Dazu die Referenzimplementierungen für Kunden, Preise, Lagerbestände und Bestellungen, mit denen sich diese Regeln produktiv umsetzen lassen.
Warum Datenmapping das eigentliche Migrationsrisiko ist
PlentyONE, Shopware und Odoo verwenden jeweils eigene, historisch gewachsene Datenmodelle für Kunden, Produkte, Varianten und Preise. Ein Feld, das in einem System eine einfache Eigenschaft ist, kann im Zielsystem eine eigene relationale Struktur erfordern. Wer dieses Mapping unterschätzt und Daten „mechanisch“ 1:1 überträgt, produziert im besten Fall Importfehler – im schlechteren Fall unbemerkt falsche Zuordnungen, die erst im laufenden Betrieb auffallen.
Diese Seite behandelt das Mapping selbst – also die semantische Zuordnung zwischen den Systemen. Welche Daten dabei überhaupt in den Migrationsumfang gehören, klärt PlentyONE Odoo Datenmigration; wie ein solches Mapping technisch fehlerfrei in den produktiven Go-Live überführt wird, zeigt ERP-Migration ohne Downtime.
Proprietäre Strukturen vs. relationale Odoo-Modelle
Odoo 19 verwendet ein durchgängig relationales Modell: Objekte wie Kunden, Produkte oder Bestellungen bestehen aus miteinander verknüpften Datensätzen, nicht aus flachen, in sich geschlossenen Tabellen. PlentyONE- und Shopware-Strukturen müssen deshalb nicht nur kopiert, sondern in dieses relationale Modell übersetzt werden – mit korrekten Fremdschlüsselbeziehungen für Kunden, Produkte, Varianten und Preislogik.
Business Keys vs. Surrogate Keys
Der zentrale technische Grundsatz für jedes seriöse ERP-Mapping: die strikte Trennung zwischen Surrogate Keys und Business Keys.
- Surrogate Keys sind rein technische, systemgenerierte interne IDs (etwa die numerische Datenbank-ID aus PlentyONE). Sie dürfen niemals als Primärschlüssel zwischen Systemen übernommen werden, da Odoo eigene Sequenzen generiert und Kollisionen andernfalls unvermeidlich wären.
- Business Keys sind eindeutige, fachliche Identifikatoren, die unabhängig vom System stabil bleiben – etwa die Artikelnummer (SKU), die EAN, die Umsatzsteuer-ID oder die UUID aus dem Shopware-Frontend.
Das Mapping erfolgt deshalb ausschließlich über Business Keys. Diese werden in Odoo in dedizierten Custom Fields gespeichert (etwa x_shopware_uuid), um die referenzielle Integrität dauerhaft abzusichern. Diese Entscheidung ist keine Ad-hoc-Praxis, sondern in der zugrunde liegenden Architektur explizit als Architecture Decision Record dokumentiert: Werden stattdessen Surrogate Keys gemappt, drohen beim Neuanlegen von Objekten sofortige Zuordnungsfehler, weil unveränderliche Business Keys wie die UUID diese Verwechslung von vornherein ausschließen.
Ein praktisches Beispiel verdeutlicht das Risiko: Wird ein Kunde in Odoo versehentlich gelöscht und später erneut angelegt, erhält er automatisch eine neue interne Datenbank-ID. Wäre diese interne ID die Referenz zwischen den Systemen gewesen, würde der Connector den „neuen“ Kunden nicht mehr mit seiner bisherigen Bestellhistorie verknüpfen können. Die stabile Business-Key-Referenz – etwa die ursprüngliche PlentyONE-Kundennummer oder die Shopware-UUID – bleibt dagegen auch in diesem Fall unverändert gültig.
Produkt- und Variantenmapping
Odoo trennt strukturell zwischen dem Elternprodukt (product.template) und der konkreten Variante (product.product). Das Mapping muss diese Trennung exakt abbilden:
| Quellsystem | Ziel in Odoo 19 |
|---|---|
| Shopware-Parent | product.template |
| Shopware-Variante | product.product |
Die SKU dient dabei als zentraler, unveränderlicher Business Key über den gesamten Prozess hinweg. Fehlt eine SKU, wird der Import dieses spezifischen Artikels durch den ETL-Prozess bewusst blockiert, statt einen unklaren Datensatz zu erzeugen.
Kategorien werden grundsätzlich von oben nach unten importiert, um den Kategoriebaum korrekt aufzubauen. Da das Shopware-Frontend intern durchgängig mit UUIDs statt fortlaufenden IDs arbeitet, werden diese UUIDs dauerhaft in der Odoo-Datenbank gespeichert, um die Beziehung auch nach Änderungen stabil zu halten.
Referenzimplementierung: Kundenimport
Das Kunden-Modul importiert Firmen, Ansprechpartner, Liefer- und Rechnungsadressen sowie Preislisten, Steuerdaten und Fiskalpositionen in einer sauberen Parent-Child-Struktur. Die Reihenfolge ist dabei bewusst festgelegt: zuerst das übergeordnete Unternehmen, danach die zugehörigen Ansprechpartner. Diese Struktur verhindert, dass ein Ansprechpartner ohne gültige Unternehmenszuordnung im System entsteht – ein Fehler, der sich in nachgelagerten Prozessen wie der Rechnungsstellung sofort bemerkbar machen würde.
Referenzimplementierung: Preisimport
Zur Synchronisation von Einkaufspreisen, Verkaufspreisen, Staffelpreisen und B2B-Preislisten erfolgen Importe ausschließlich ressourcenschonend über die write()– oder load()-Methoden der JSON-2 API. Preislisten sind in Odoo eigenständige, mit Kunden oder Kundengruppen verknüpfte Objekte – individuelle B2B-Konditionen werden deshalb nicht als Zusatzfeld am Kunden gepflegt, sondern als eigene Preisliste angelegt und referenziert. Das ermöglicht es, dieselbe Preislogik später auch für neue Kunden mit vergleichbaren Konditionen wiederzuverwenden, ohne das Mapping erneut aufzubauen.
Referenzimplementierung: Lagerbestände
Die Lagersynchronisation transferiert den Bestand aus dem Quellsystem in das Odoo-Modell stock.quant. Das geschieht ausnahmslos über eine revisionssichere Inventur (im Odoo-Sprachgebrauch als „Inventory Adjustment“ bezeichnet), gefolgt von einer strikten Validierung der Zielbestände. Ein häufiger technischer Fehler an dieser Stelle: der Versuch, Lagerbestände direkt per create() mit beliebigen Feldwerten anzulegen. Seit Odoo 15 ist dieser direkte Schreibzugriff systemseitig blockiert – Lagerbestände dürfen ausschließlich über die zulässigen Inventur-Funktionen von stock.quant selbst manipuliert werden. Diese Einschränkung ist kein Hindernis, sondern schützt vor genau der Art von unkontrollierten Bestandsänderungen, die in historisch gewachsenen Systemen zu negativen oder unerklärlichen Lagerbeständen führen.
Referenzimplementierung: Bestellungen
Bei der Übernahme historischer Bestellungen, Auftragspositionen sowie Liefer- und Rechnungsstatus gilt eine wichtige Regel: Gelieferte, fakturierte und offene Mengen müssen anhand der tatsächlichen historischen Belege und Liefer-/Rechnungszustände rekonstruiert werden. Eine direkte Gleichsetzung der gelieferten und in Rechnung gestellten Menge mit der ursprünglich bestellten Menge ist nur zulässig, wenn sie fachlich dem historischen Zustand entspricht – etwa bei vollständig abgeschlossenen Aufträgen ohne Teillieferung. Andernfalls würde das ERP-System den Auftrag fälschlich als vollständig abgeschlossen werten, obwohl in Wirklichkeit noch eine Teillieferung oder Rechnungsstellung offen war. Die konkrete Migrationslogik für diesen Fall ist deshalb immer version- und implementierungsspezifisch zu prüfen, nicht pauschal zu automatisieren.
Kunden, Kategorien, Hersteller und Steuern
Odoo verwaltet Firmen und Ansprechpartner in einem gemeinsamen Parent-Child-Modell: Das Unternehmen bildet den Parent, die zugehörigen Ansprechpartner die Child-Datensätze. Anhand von Herkunftsland und Umsatzsteuer-ID weist das System beim Import automatisch die korrekte Fiskalposition zu (etwa Inland, EU, Drittland) – eine Voraussetzung dafür, dass spätere Rechnungen rechtssicher erzeugt werden. Die bisherige Kundennummer aus PlentyONE bleibt dabei als eindeutige Referenz erhalten.
Ein in der Praxis folgenreicher Fehlerpfad: Wird die Fiskalposition falsch zugeordnet – etwa weil ein Herkunftsland fehlerhaft übernommen wurde –, berechnet das System auf allen Folgerechnungen dieses Kunden eine falsche Steuerlogik. Dieser Fehler bleibt oft unbemerkt, bis eine externe Prüfung oder eine Kundenrückfrage ihn aufdeckt. Deshalb gehört die Validierung der Fiskalpositionszuordnung in jeden Dry Run, nicht erst in die Post-Go-Live-Kontrolle.
Mapping validieren
Vor jedem produktiven Import gehört eine systematische Validierung auf Datenbankebene. Typische, direkt prüfbare Fehlerquellen:
Doppelte SKUs (kritischer Fehler bei Variantenzuordnung):
SELECT default_code, COUNT(*) FROM product_product
GROUP BY default_code HAVING COUNT(*) > 1;Produkte ohne Verkaufspreis:
SELECT id, name->>'en_US' AS name FROM product_template
WHERE list_price IS NULL OR list_price = 0;Negative Lagerbestände (nur lesende Prüfung – die Korrektur erfolgt ausschließlich über die zulässigen Inventur-Funktionen des Systems, nicht über direkte Schreibzugriffe):
SELECT product_id, location_id, quantity FROM stock_quant
WHERE quantity < 0;Diese und weitere Prüfungen sollten fester Bestandteil jedes Dry Runs sein – nicht eine nachträgliche Fehlersuche nach dem Go-Live. Zwei ergänzende Prüfungen gehören ebenfalls in dieses Rezeptbuch: die Suche nach Varianten ohne gültiges Elternprodukt sowie die Kontrolle auf doppelte Kundennummern oder E-Mail-Adressen, die auf eine versehentliche Mehrfachanlage im Quellsystem hindeuten. Beide Fehlerbilder sind erfahrungsgemäß häufiger als eine einzelne fehlerhafte SKU, aber ebenso zuverlässig über einfache SQL-Abfragen auf der Zieldatenbank zu erkennen.
Eine vollständige Validierungsrunde vor dem produktiven Import sollte mindestens folgende Kategorien abdecken:
| Prüfkategorie | Typischer Fehler | Auswirkung, wenn unentdeckt |
|---|---|---|
| SKU-Eindeutigkeit | doppelte Artikelnummern | falsche Variantenzuordnung |
| Elternprodukt-Referenz | Variante ohne product.template | blockierter oder fehlerhafter Import |
| Preisvollständigkeit | fehlender Verkaufspreis | Artikel nicht verkäuflich |
| Lagerbestand-Plausibilität | negative Bestände | fehlerhafte Verfügbarkeitsanzeige |
| Fiskalposition | falsches Herkunftsland/USt-ID | fehlerhafte Steuerberechnung |
| Kunden-Dubletten | mehrfach angelegte E-Mail-Adressen | inkonsistente Bestellhistorie |
Jede dieser Kategorien lässt sich mit vergleichsweise einfachen, wiederholbaren Abfragen direkt auf der Zieldatenbank prüfen – vorausgesetzt, diese Prüfungen sind fester, automatisierter Bestandteil des Dry Runs und nicht eine gelegentliche Stichprobe.
Wie ein vollständiger Testmigrations- und Cutover-Prozess aufgebaut ist, erklären wir in ERP-Migration ohne Downtime. Die häufigsten konkreten Mapping-Fallstricke – von UUID-Konflikten bis zu fehlenden Relationen – beschreiben wir vertieft in PlentyONE Odoo Migration Fehler.
Das Mapping ist eine von mehreren Projektphasen. Den vollständigen Ablauf von der Systemanalyse bis zum Go-Live beschreibt unser Überblick zur Migration von PlentyONE zu Odoo.
Häufig gestellte Fragen zum Datenmapping
Warum dürfen wir nicht einfach die PlentyONE-ID als Referenz in Odoo verwenden?
Weil es sich um einen Surrogate Key handelt – eine rein technische, systemgenerierte ID, die keine fachliche Bedeutung trägt und bei einer erneuten Anlage des Datensatzes kollidieren oder ins Leere laufen kann. Odoo vergibt eigene interne IDs über eigene Sequenzen; nur ein stabiler Business Key wie die SKU oder die Shopware-UUID garantiert eine korrekte Wiedererkennung über beide Systeme hinweg.
Was passiert, wenn eine SKU im Quellsystem nicht eindeutig ist?
Der Import dieses spezifischen Artikels wird bewusst blockiert, statt einen unklaren oder möglicherweise falsch zugeordneten Datensatz zu erzeugen. Dubletten müssen deshalb vor dem produktiven Import identifiziert und bereinigt werden.
Können wir das Mapping schrittweise testen, ohne das Zielsystem jedes Mal zurückzusetzen?
Ja. Die load()-Methode arbeitet über externe IDs idempotent: Ein bereits vorhandener Datensatz wird bei erneutem Import aktualisiert statt dupliziert. Das erlaubt beliebig wiederholte Testläufe gegen dieselbe Staging-Umgebung.
Wie lange dauert ein vollständiges Mapping-Projekt für einen mittelgroßen Katalog?
Das hängt stark von der Komplexität der Variantenstruktur, der Datenqualität und der Zahl bestehender Individualfelder ab. Eine seriöse Zeitschätzung ist erst nach einer technischen Analyse Ihrer konkreten Datenstrukturen möglich.
Quellen
Das Konzept der External IDs (XML-IDs) und ihre Rolle beim Datenimport basiert auf der offiziellen Odoo-Dokumentation: Odoo 19 – Export and import data. Die Einschränkung direkter Schreibzugriffe auf stock.quant (seit Odoo 15, über _get_inventory_fields_write()) ist sowohl im technischen Migrationshandbuch als auch über die Odoo-Dokumentation zu Inventory adjustments belegt.
Technisches Datenmapping prüfen lassen
Ob Ihr bestehendes Datenmodell sauber über Business Keys auf Odoo abbildbar ist oder wo konkrete Konfliktpunkte bei Varianten, Kunden oder Preislogik liegen, zeigt eine technische Analyse Ihrer Systeme. Genau das leisten wir im Rahmen unseres kostenlosen, unverbindlichen E-Commerce Audits.
Lassen Sie Ihr Datenmapping technisch prüfen – kostenfrei und unverbindlich.
Jetzt Mapping-Analyse anfordern
„Wir wissen nicht, wie sauber unsere Artikelnummern und Kundendaten tatsächlich gepflegt sind.“ Das lässt sich vorab messen, nicht schätzen: Doppelte Artikelnummern, Varianten ohne Elternprodukt und fehlende Pflichtfelder sind über einfache Abfragen auf Datenbankebene sichtbar – bevor der erste produktive Import läuft.
✔ kostenlos ✔ unverbindlich ✔ konkrete Mapping-Logik statt Theorie ✔ Antwort innerhalb von 24 Stunden
Christopher Einenkel
Christopher Einenkel ist der strategische Kopf der HQ GmbH für hochentwickelte Systemintegrationen und komplexe API-Architekturen. Immer wenn Datensynchronisationen an harte Grenzen stoßen oder anspruchsvolle Enterprise-Systeme wie Salesforce an Shopify angebunden werden müssen, konzipiert er maßgeschneiderte, hochperformante Schnittstellen-Logiken.
Sein Track Record umfasst die Eigenentwicklung proprietärer Enterprise-Lösungen, darunter automatisierte KI-Übersetzungstools für Artikelstammdaten, lückenlose B2B-Einkaufssysteme sowie automatisierte Marktbewertungs- und Wettbewerbsüberwachungen. Darüber hinaus steuert er für unsere Großkunden die technische Implementierung und API-Vernetzung digitaler Software-Callcenter-Anlagen in bestehende CRM- und ERP-Landschaften.
