Bei der Bewertung von X-Cart als mögliche Zielplattform zeigt das Datenmodell, wie Quelldaten, Beziehungen und geschäftliche Bedeutung in der Zielumgebung abgebildet werden müssen.
Bei der Bewertung von X-Cart als mögliche Zielplattform ist zu berücksichtigen, dass X-Cart-Shops häufig mehrere Generationen von Katalog- und Erweiterungslogik enthalten. Aktuelle Plattformversionen unterscheiden Product Variations von älteren Product Variants, während Product Classes und Attribute strukturierte Kataloginformationen bereitstellen. Customer-Datensätze können mit Benutzertypen, Rollen, Adressen, Profilfeldern und Memberships verbunden sein. Orders besitzen getrennte Zahlungs- und Auftragsabwicklungsstatus. Module können Wholesale Pricing, Fitment, Händlerdaten, Reviews, Loyalty, Subscriptions oder Marketplace-Funktionen ergänzen.
Diese Ebenen bedeuten, dass eine X-Cart-Migration nicht auf Products, Categories, Customers und Orders reduziert werden kann. Eine Color-Size-Matrix aus dem Quellsystem kann aktuelle Product Variations, eine Interpretation älterer Product Variants oder eine andere Product-Optionsstruktur erfordern. Eine Customer-Gruppe kann Membership Pricing, Zugriff, Steuern oder Zahlungseinschränkungen darstellen. Ein Automotive-Fitment-Wert kann einem Modul und einer externen Fahrzeugtaxonomie gehören statt einem allgemeinen Product-Attribut.
Die Migration hängt deshalb von der Übersetzung von Zuständigkeiten und Beziehungen ab: Welche X-Cart-Entität besitzt einen Wert, welche anderen Datensätze geben ihm Bedeutung und ist der Wert nativ, veraltet, moduleigen, präsentationsbezogen oder extern gesteuert?
Die Katalogbedeutung in X-Cart hängt von Version und installierten Modulen ab
Aktuelle und ältere X-Cart-Datenstrukturen müssen vor der Zuordnung voneinander getrennt werden. Aktuelle X-Cart-Versionen verwenden Product Variations, während ältere Shops noch Legacy-Strukturen für Product Variants enthalten können. Langjährig betriebene X-Cart-Installationen können außerdem historische Module, individuellen Code oder importierte Strukturen enthalten, die nicht einer sauberen aktuellen Installation entsprechen.
| Nachweis aus der Quelle | X-Cart-Interpretation | Konsequenz für die Migration |
|---|---|---|
| Aktuelle Variation-Datensätze | Product Variations und zugehörige Product-Daten | Aktuelle Variation-Identität, ausgewählte Attribute und kommerzielle Werte erhalten. |
| Legacy-Variant-Tabellen oder -Felder | Ältere Product-Variants-Struktur | Nach der Quellversion interpretieren statt das aktuelle Schema vorauszusetzen. |
| Product-Class- und Attribute-Datensätze | Strukturierte Product-Fakten und wiederverwendbare Attributdefinitionen | Class-Zugehörigkeit und Attribut-Wert-Beziehungen erhalten. |
| Modulspezifische Product-Felder | Moduleigene Erweiterungsdaten | Nicht jedes Feld als Teil des X-Cart-Kerns behandeln. |
| Individuelle Datenbanktabellen | Individuelle Entität oder Beziehung | Erst nach Identifikation des nutzenden Ablaufs ein Ziel definieren. |
| Externe Integrations-IDs | ERP-, PIM-, WMS-, CRM-, Marketplace- oder Automotive-Identifikator | Stabile Schlüssel für die Wiederanbindung des Zielshops erhalten. |
Quellversion und Modulinventar sind nicht nur technische Metadaten. Sie bestimmen, was ein Product-, Options-, Customer- oder Order-Feld tatsächlich bedeutet. Zwei X-Cart-Shops können dieselbe Bezeichnung verwenden und den Wert trotzdem unterschiedlich speichern und verwenden.
Products, Variations, Classes und Attribute haben unterschiedliche Rollen
Ein X-Cart-Product enthält zentrale Identitäts- und Commerce-Daten wie Name, SKU, Preis, Bestand, Beschreibungen, Bilder, Category-Zuordnungen, Versand- und Steuereigenschaften sowie Sichtbarkeit. Product Variations stellen auswählbare Versionen eines Products dar. Classes und Attribute beschreiben strukturierte Merkmale und können Katalogorganisation, Filterung, Vergleich oder Informationen auf Product-Seiten unterstützen.
Eine Product-Option aus dem Quellsystem sollte nach ihrer Funktion klassifiziert werden. Identifiziert ein ausgewählter Wert eine separat verwaltete Kombination mit eigenem Preis, Bestand, SKU, Bild oder Gewicht, entspricht er eher einer Variation. Verändert ein Wert ein Product ohne unabhängigen Bestand, kann eine andere Auswahlstruktur geeigneter sein. Beschreibt ein Wert das Product, ohne den gekauften Artikel zu verändern, gehört er eher zu Attributen oder Content.
| Quellmuster | Zielfrage für X-Cart | Zu erhaltende Beziehung |
|---|---|---|
| Child-SKU für Farbe und Größe | Aktuelle Product Variation oder Legacy Product Variant | Child-Identität, Bestand, Preis, Medien und ausgewählte Werte. |
| Personalisierungsfeld | Käufereingabe oder moduleigene Product-Auswahl | Eingegebener Wert bleibt mit der Order-Position verbunden. |
| Technische Spezifikation | Product-Attribut unter der passenden Class | Strukturierte Information bleibt von einer Kaufoption getrennt. |
| Mengenabhängiger Wholesale-Preis | Native oder moduleigene Wholesale-Pricing-Beziehung | Mengenschwellen und Membership-Geltungsbereich bleiben verbunden. |
| Digitale Datei | E-Goods- oder Dateianhangsbeziehung, sofern verwendet | Zugriff gehört zum richtigen Product- und Order-Kontext. |
| Automotive Fitment | Fitment-Moduldatensatz und Fahrzeugtaxonomie | Product-Fahrzeug-Beziehung bleibt von allgemeinen Attributen getrennt. |
Aktuelle X-Cart Product Variations und ältere Product Variants dürfen nicht unkritisch vermischt werden. Eine Migration kann ältere Datensätze interpretieren und in ein aktuelles Zielmodell überführen, doch die Herkunft muss nachvollziehbar bleiben, damit Child-Identitäten und Optionskombinationen weder dupliziert noch verloren gehen.
Categories, Classes, Attribute und Suche bestimmen die Auffindbarkeit
Categories strukturieren Käufernavigation und Product-Zuordnung. Product Classes gruppieren wiederverwendbare Attribute. Attribute tragen Product-Fakten. Such- und Filtermodule können Categories, Attribute, SKUs, Brands, Tags, Fitment oder andere erweiterungseigene Werte indexieren. Diese Strukturen hängen zusammen, sind aber nicht austauschbar.
Eine Brand, die im Quellsystem als Category dargestellt wird, kann in X-Cart eher als Attribut oder Brand-Moduldatensatz passen. Ein Spezifikationsbaum aus der Quelle kann zu Product Classes und Attributen werden. Eine Landingpage kann Content und Navigation statt einer Category erfordern. Ein Fitment-Selektor kann Fahrzeugdatensätze und eine Product-Fitment-Beziehung benötigen statt gewöhnlicher Filter.
| Discovery-Element | X-Cart-Verantwortung | Übersetzungsgrenze |
|---|---|---|
| Käuferseitige Hierarchie | Category und Product-Zuordnungen | Das Vorhandensein einer Category stellt Navigation nicht automatisch wieder her. |
| Product-Spezifikation | Class und Attributwert | Werte bleiben strukturiert und mit dem richtigen Product-Typ verbunden. |
| Brand | Attribut oder Brand-Moduldatensatz | Brand-Bedeutung sollte nicht gleichzeitig in Categories und Feldern dupliziert werden. |
| Filterbarer Wert | Attribut oder moduleigenes Indexfeld | Suchfunktion hängt von normalisierten Werten und Zielindexierung ab. |
| Fahrzeugkompatibilität | Automotive-Fitment-Datensätze | Fitment benötigt Fahrzeugtaxonomie und Beziehungsschlüssel, nicht nur Freitext. |
| Related Product | Native oder moduleigene Product-Beziehung | Merchandising-Verknüpfungen bleiben von Category-Zugehörigkeit getrennt. |
Dieses Modell verhindert, dass Discovery-Logik in Product-Beschreibungen abgeflacht wird. Eine migrierte Beschreibung kann Spezifikationen anzeigen, aber strukturierte Attribute, Fitment, Vergleichs- oder Filterbeziehungen nicht ersetzen.
Customers, Benutzertypen, Rollen, Profilfelder und Memberships sind getrennte Konzepte
Die Benutzerverwaltung von X-Cart kann Administratoren, Customers und Vendors, Rollen und Berechtigungen, Customer-Konten und Adressen, individuelle Profilfelder sowie Membership-Levels umfassen. Memberships können Product- und Category-Zugriff, Product-Preise, Mindestmengen, Rabatte, Coupons, Sonderangebote, Steuern oder Zahlungsmethoden beeinflussen.
Ein Customer-Segment aus dem Quellsystem sollte deshalb nach seiner Funktion gelesen werden. Wholesale-, Dealer-, VIP-, Employee-, Tax-Exempt-, Approved-Buyer-, Loyalty- oder Subscription-Status gehört nicht zwangsläufig in eine einzige generische Membership. Manche Werte sind Identitätsmerkmale, manche kommerzielle Zugriffsregeln, manche gehören zu Modulen und andere zu externen CRM- oder ERP-Klassifikationen.
| Bedeutung des Quellkontos | Zu prüfender X-Cart-Verantwortlicher | Zu erhaltende Beziehung |
|---|---|---|
| Einzelner Käufer | Customer-Konto und Adressbuch | Identität, Login, Adressen und Orders bleiben verbunden. |
| Administrativer Benutzer | Administrator-Benutzertyp und Rolle | Berechtigungen bleiben von Customer-Segmentierung getrennt. |
| Marketplace-Seller-Benutzer | Vendor-Benutzer und moduleigene Organisationsbeziehung | Benutzer gehört zur richtigen Seller- oder Marketplace-Entität. |
| Preis- oder Zugriffsstufe | Membership-Level und zugehörige kommerzielle Regeln | Membership beeinflusst die vorgesehenen Products, Preise, Steuern oder Methoden. |
| Zusätzliche Customer-Information | Profilfeld oder externer Identifikator | Feldzweck und Datenschutz bleiben explizit. |
| Externes Unternehmenskonto | Individuelle/Modulstruktur oder externer Systemschlüssel | Mehrere Käufer bleiben bei Bedarf dem autoritativen Unternehmen zugeordnet. |
Auch Membership-Historie unterscheidet sich von der aktuellen Membership-Zuweisung. Eine historische Order sollte Preis, Rabatt, Steuer und Zahlungsnachweise zum Kaufzeitpunkt erhalten; diese Werte sollten nach der Migration nicht anhand der heutigen Membership des Customers neu berechnet werden.
Orders verwenden getrennte kommerzielle und Auftragsabwicklungsbeziehungen
X-Cart-Orders können Customer- oder Gastidentität, Adressen, Product- und Variation-Referenzen, ausgewählte Attribute, Mengen, Preise, Rabatte, Steuern, Zahlungsstatus, Auftragsabwicklungsstatus, Sendungen, Transaktionen, Retouren, Notizen, Rechnungen und moduleigene Datensätze enthalten. X-Cart trennt Zahlungs- und Auftragsabwicklungsstatus, weshalb ein einzelner generischer Order-Status aus der Quelle möglicherweise nicht genügend Information trägt.
| Element der Quell-Order | X-Cart-Beziehung | Historische Bedeutung |
|---|---|---|
| Order-Position | Product- oder Variation-Snapshot, SKU, Menge, Preis und ausgewählte Optionen | Zeigt genau, was gekauft wurde. |
| Zahlungsstatus | Zahlungsstatus und Transaktionsdatensätze | Trennt finanziellen Fortschritt von Auftragsabwicklung. |
| Auftragsabwicklungsstatus | Status der Auftragsabwicklung, Sendung und Tracking | Zeigt, was versendet wurde oder noch offen ist. |
| Retoure oder Erstattung | Retourenmoduldatensatz, Erstattungsbetrag und betroffene Positionen, soweit verfügbar | Bewahrt die After-Sales-Historie. |
| Customer-Adresse | Billing- und Shipping-Snapshot zum Order-Zeitpunkt | Historische Adresse darf nicht durch das aktuelle Adressbuch überschrieben werden. |
| Moduleigene Daten | Subscription-, Marketplace-, Loyalty-, Fitment- oder externe Integrationsinformationen | Die Order kann von Datensätzen außerhalb der Kern-Order-Tabellen abhängen. |
Ein Quellstatus wie complete, processing, shipped, partially refunded oder canceled kann Zahlungs- und Auftragsabwicklungsbedeutung kombinieren. Die Migration sollte die vorhandenen Nachweise erhalten, statt die Bezeichnung zwangsläufig in ein einzelnes Feld zu pressen. Aktuelle Zahlungs-, Versand-, Steuer- und Benachrichtigungskonfiguration bleibt von historischen Order-Datensätzen getrennt.
Content, statische Seiten, URLs und Darstellung in der Shop-Oberfläche haben unterschiedliche Verantwortungsbereiche
X-Cart-Daten der Shop-Oberfläche können Product- und Category-Beschreibungen, statische Pages, Menüs, Bilder, Videos, individuelle Product-Tabs, Banner, Layout-Blöcke, Themes, Metadaten, Clean URLs, Redirects und Sprachwerte enthalten. Diese Bestandteile müssen nach Content-, Routing- und Präsentationsverantwortung getrennt werden.
Product-Beschreibungen gehören zu Products. Statische Pages besitzen eine eigene Identität und Route. Individuelle Product-Tabs können einem Modul gehören. Menüs und Layout-Blöcke steuern Platzierung. Themes und Templates bestimmen die Darstellung. SEO-Metadaten und Redirects schützen Routingbeziehungen. Eine Headless- oder stark angepasste Shop-Oberfläche kann weitere Inhalte außerhalb des X-Cart-Kerns führen.
| Quellbestandteil | Zielebene in X-Cart | Zu erhaltende Bedeutung |
|---|---|---|
| Product- oder Category-Beschreibung | Katalog-Content | Text bleibt mit der richtigen Entität und Sprache verbunden. |
| Statische Informationsseite | Page-Datensatz | Content, Route, Hierarchie und Sichtbarkeit bleiben getrennt. |
| Individueller Product-Tab | Moduleigene Product-Content-Beziehung | Tab-Platzierung und Product-Zuordnung bleiben verbunden. |
| Banner oder Homepage-Block | Präsentationskonfiguration oder Moduldatensatz | Visuelle Platzierung ergibt sich nicht automatisch aus der Content-Migration. |
| Legacy-URL | Clean-URL- und Redirect-Struktur | Alter Pfad und Ziel im Zielshop bleiben explizit. |
| Theme-Anpassung | Präsentationsimplementierung im Zielsystem | Template-Code ist kein gewöhnlicher CMS-Datensatz. |
Dieses Zuständigkeitsmodell verhindert einen häufigen Kategorienfehler: jedes sichtbare Shop-Element als portablen Content zu behandeln. Manche sichtbaren Elemente werden aus Products und Categories erzeugt, manche sind separate Pages, andere existieren nur, weil ein Modul oder Theme sie darstellt.
X-Cart-Module können Katalog-, Customer- und Order-Daten besitzen
X-Cart-Module können Felder und Entitäten für Wholesale Pricing, Loyalty, Subscriptions, Reviews, Product Attachments, Custom Tabs, Automotive Fitment, Dealers, Marketplace Vendors, Retouren, Social Login, Steuerservices, Zahlungsservices, Versandintegrationen und externe Feeds einführen. Moduleigene Datensätze können von Einstellungen, geplanten Prozessen, API-Zugangsdaten oder externen Taxonomien abhängen.
Die Kernfrage der Migration lautet nicht, ob ein Modulname im Zielshop existiert. Entscheidend ist, ob die Datensätze und Beziehungen weiterhin benötigt werden und ob die Zielplattform ein Ziel besitzt, das sie interpretieren kann.
| Datenverantwortung | Beispielhafte Datensätze | Bedeutung für den Umfang |
|---|---|---|
| X-Cart Core | Products, Categories, Classes, Attribute, Benutzer, Orders, Pages | Über native Datenbeziehungen abbilden. |
| X-Cart-Modul | Membership Pricing, Fitment, Dealer Locations, Reviews, Loyalty, Subscriptions | Modulschema und Verknüpfungen zu Kerndatensätzen prüfen. |
| Individueller Code | Eigene Felder, Tabellen, Status oder Abläufe | Bewusstes Ziel oder Archivierungsentscheidung definieren. |
| Externer Service | Zahlung, Steuer, Versand, Suche, Marketplace, Analytics | Referenzen erhalten, die historische und aktive Systeme miteinander abgleichen. |
| ERP/PIM/WMS/CRM | Master-Identifikatoren für Product, Customer, Bestand und Order | Stabile Schlüssel für Wiederanbindung und Zuständigkeit bewahren. |
Automotive-Daten verdeutlichen den Unterschied besonders gut. Year, Make, Model, Engine, Trim, Fitment Type und Dealer Location können wie Product-Attribute aussehen, die tatsächliche Kompatibilität hängt jedoch von gemeinsamen Fahrzeugtaxonomien und Product-Fahrzeug-Beziehungen ab. Werden diese Informationen zu Freitext abgeflacht, bleiben zwar Wörter erhalten, Fitment-Suche und Wartbarkeit gehen aber verloren.
Data-Transfer-Formate definieren nicht das gesamte X-Cart-Modell
X-Carts Import- und Exportfunktionen können Products, Categories, Attribute, Benutzer, Orders, Bestand, Reviews und bestimmte Moduldaten verarbeiten. Dass ein Feld in CSV dargestellt werden kann, beweist jedoch nicht, dass alle umgebenden Beziehungen, Moduleinstellungen oder externen Abhängigkeiten enthalten sind.
Der Import eines Attributwerts stellt beispielsweise nicht automatisch dessen Product Class und Darstellungslogik wieder her. Der Import eines Customers richtet kein membership-spezifisches Pricing ein, wenn Membership und zugehörige Regeln fehlen. Der Import einer Order erzeugt keine aktuellen Zahlungs- oder Versandmethoden. Eine Fitment-ID ist bedeutungslos, wenn die referenzierte Fahrzeugtaxonomie fehlt.
| Nachweis aus dem Transferformat | Zusätzlich zu identifizierende Beziehung |
|---|---|
| Product-Zeile | Category, Class, Attribute, Variation, Medien, Bestand und Modulverknüpfungen. |
| Attributwert | Attributdefinition, Class-Zuweisung, Eingabetyp und Product-Beziehung. |
| Customer-Zeile | Benutzertyp, Adressen, Profilfelder, Membership und externe Identität. |
| Order-Zeile | Positionen, Status, Transaktionen, Sendungen, Retouren und historische Snapshots. |
| Modul-CSV | Installiertes Modul, Referenztabellen, Konfiguration und externe Taxonomie. |
| Externes ID-Feld | Autoritatives System, Eindeutigkeitsregel und Wiederanbindungsprozess. |
Der Übersetzungsplan sollte den Datenbeziehungen folgen und nicht der Form einer einzelnen Exportdatei. Das ist insbesondere bei älteren X-Cart-Shops wichtig, deren Daten bereits Upgrades, individuelle Importe oder Modulwechsel durchlaufen haben.
X-Cart-Zuordnungsentscheidungen nach Geschäftsmeaning
| Quellmuster | Richtige Übersetzungsfrage | Folge einer falschen Annahme |
|---|---|---|
| Aktuelle oder ältere Child-Kombinationen | Nutzt die Quelle aktuelle Product Variations, Legacy Product Variants oder individuelle Optionslogik? | Child-SKU, Bestand, Preis oder ausgewählte Werte werden dupliziert oder gehen verloren. |
| Technische Spezifikationen | Gehören sie zu Product Classes und Attributen? | Filterung, Vergleich und Katalogsteuerung werden unzuverlässig. |
| Wholesale- oder Dealer-Segment | Ist die Bedeutung Membership, moduleigene Unternehmensdaten oder externe CRM-Klassifikation? | Pricing und Zugriff werden der falschen Identitätsebene zugeordnet. |
| Kombinierter Order-Status | Wie müssen Zahlungs- und Auftragsabwicklungsnachweise getrennt werden? | Historischer Finanz- oder Versandstatus wird irreführend. |
| Automotive-Kompatibilität | Welches Modul und welche Fahrzeugtaxonomie besitzen die Beziehung? | Fitment-Suche und Wartbarkeit verschwinden, obwohl Textwerte migriert wurden. |
| Custom Tab oder Feld | Handelt es sich um Core Content, Moduldaten oder Theme-Präsentation? | Daten kommen an, ohne die Shop-Oberfläche-Struktur, die sie verwendet. |
| ERP- oder Marketplace-Schlüssel | Welches System ist autoritativ und welchen Datensatz identifiziert der Schlüssel? | Der migrierte Datensatz kann nicht abgeglichen oder synchronisiert werden. |
Die Bedeutung einer X-Cart-Migration bleibt erhalten, wenn Versionsherkunft, native Datenkategorien und Strukturen, Module sowie externe Systeme als getrennte Zuständigkeitsbereiche behandelt werden. So entsteht ein Zielshop, in dem Product-Auswahl, Customer-Behandlung, historische Orders, Content und Integrationen nicht nur vorhanden, sondern verständlich und nutzbar bleiben.
Fazit
Die Übersetzung des X-Cart-Datenmodells hängt von Quellversion, Katalogstruktur, Benutzerbeziehungen, Order-Semantik, Modulen und externen Systemen ab. Aktuelle Product Variations müssen von älteren Product Variants getrennt werden. Product Classes und Attribute bleiben von Kaufoptionen zu unterscheiden. Memberships können Preis-, Zugriffs-, Steuer- und Zahlungsbeziehungen steuern. Orders benötigen getrennten Zahlungs-, Auftragsabwicklungs-, Transaktions-, Versand- und Retourenkontext. Module können Datensätze wie Wholesale Pricing, Fitment, Dealers, Loyalty, Subscriptions und Marketplace-Daten besitzen.
Ein belastbarer Migrationsumfang ordnet jeden Quellwert der X-Cart-Entität oder dem Modul zu, das dieselbe geschäftliche Bedeutung trägt, und erhält stabile Identifikatoren über verbundene Systeme hinweg. Dadurch wird die Scheinsicherheit einer rein feldweisen Übertragung vermieden und ein Zielshop geschaffen, dessen Katalog und kommerzielle Historie tatsächlich nutzbar bleiben.
Häufige Fragen
Was ist der Unterschied zwischen aktuellen X-Cart Product Variations und älteren Product Variants?
Sie gehören zu unterschiedlichen Generationen der X-Cart-Katalogstruktur. Aktuelle Versionen verwenden Product Variations, während ältere Shops noch Legacy-Datensätze für Product Variants enthalten können. Quellversion und Tabellenbeziehungen müssen identifiziert werden, bevor die Kombinationen im Zielshop abgebildet werden.
Sollte jede Quelloption zu einer X-Cart Product Variation werden?
Nein. Eine Variation ist passend, wenn ein Wert eine separat verwaltete Kombination mit eigenen kommerziellen Werten identifiziert. Personalisierung, Geschenkservices oder beschreibende Spezifikationen können besser in eine andere Product-Auswahlstruktur, ein Attribut oder ein moduleigenes Feld gehören.
Wie beeinflussen X-Cart Product Classes und Attribute die Migration?
Classes gruppieren wiederverwendbare Attributdefinitionen, während Attributwerte einzelne Products beschreiben. Werden nur Werte erhalten, nicht aber Class- und Definitionsbeziehungen, verlieren Katalogsteuerung, Filterung, Vergleich und Product-Seitenstruktur an Qualität.
Kann jede Customer-Gruppe aus der Quelle zu einer X-Cart Membership werden?
Nein. Eine Membership ist sinnvoll, wenn sie kommerzielles X-Cart-Verhalten oder Zugriff steuert. Marketingsegmente, Unternehmensbeziehungen, Loyalty-Status, Steuerkennzeichen und externe CRM-Klassifikationen können andere Ziele benötigen.
Warum müssen Automotive-Fitment-Daten getrennt von gewöhnlichen Product-Attributen behandelt werden?
Fitment basiert in der Regel auf gemeinsamen Fahrzeugdatensätzen und Product-Fahrzeug-Beziehungen. Freitextwerte für Year, Make und Model erhalten nicht die Taxonomie und Beziehungsschlüssel, die für präzise Kompatibilitätssuche und Wartung benötigt werden.
Was sollte mit Datensätzen geschehen, die einem X-Cart-Modul oder einer individuellen Tabelle gehören?
Ermitteln Sie das Modul oder den individuellen Ablauf, die Kerndatensätze, die dadurch erweitert werden, sowie verwendete externe Taxonomien oder Identifikatoren. Aktive Beziehungen benötigen ein explizites Ziel im Zielshop; veraltete Daten können archiviert oder ausgeschlossen werden, ohne sie fälschlich als native Product-, Customer- oder Order-Daten zu behandeln.