Für die Bewertung von osCommerce als möglicher Zielplattform ordnet die Fehleranalyse wiederkehrende Risiken und ihre Vermeidung im Zielkontext ein. Migrationen zu osCommerce reagieren besonders empfindlich auf Plattformlinie und Verantwortungsgrenzen. Ein Legacy-osCommerce-Shop, ein angepasster Fork und osCommerce 4 können vertraute Datensatzbezeichnungen teilen und dennoch Kanäle, Products, Customers, CMS, Module und Integrationen unterschiedlich organisieren. Die folgenden typischen Fehler konzentrieren sich auf wiederkehrende Annahmen, durch die eine auf Datensatzebene vollständige Migration geschäftlich unvollständig wird.
Fehler 1: Legacy-osCommerce und osCommerce-4-Struktur als ein Modell behandeln
Was schiefgeht
Der Name osCommerce kann alte 2.x-Shops, stark veränderte Ableitungen oder osCommerce 4 mit deutlich anderer Betriebsstruktur bezeichnen. Werden diese Varianten wie ein einziges Schema behandelt, können alte Annahmen auf ein Multi-Channel-Ziel übertragen oder Custom Fields und Contributions einer Legacy-Quelle übersehen werden.
Frühe Warnsignale
Anforderungen sprechen nur von „osCommerce“, ohne Quellgeneration, Zielgeneration, individuelle Plattformlinie oder installierte Module zu bestimmen. Tabellen und Admin-Oberflächen entsprechen nicht den erwarteten Handbüchern.
| Nachweis in Quelle/Ziel | Bedeutung | Fehlerfolge |
|---|---|---|
| Altes Contribution-basiertes Schema | Legacy-Linie und individueller Code | Standard-v4-Mapping verliert Quellbedeutung |
| osCommerce-4-Vertriebskanäle und moderne Module | Aktuelle mehrschichtige Struktur | Legacy-Warenkorbannahmen flachen Zuständigkeiten ab |
| Fork oder veränderter Shop | Gemischte Plattformlinie | Keines der generischen Modelle reicht aus |
Vorbeugung
Quell- und Zielarchitektur ausdrücklich bestimmen. Legacy-Contributions und eigene Tabellen inventarisieren und ihre geschäftliche Bedeutung auf aktuelle osCommerce-Product-, Customer-, Order-, Front-End-, CMS- und Modulstrukturen abbilden. Kompatibilität darf nicht aus dem gemeinsamen Markennamen abgeleitet werden.
Empfehlungsbeispiel
Ein Legacy-Shop verwaltet Wholesale-Preise über eine individuelle Contribution, während das Ziel osCommerce-4-Kundengruppen und Module nutzt. Erhalten Sie die kommerzielle Beziehung zwischen Customer und Product, übersetzen Sie sie aber in das Zielmodell, statt die Legacy-Tabelle unverändert zu kopieren.
Bestehensbedingung
Die Plattformlinie jedes Shops ist dokumentiert, jede nicht standardmäßige Quellbeziehung hat einen Zieleigentümer und kein Mapping beruht auf der Annahme, dass alte und aktuelle osCommerce-Strukturen identisch sind.
Fehler 2: Vertriebskanal- und Front-End-Zuweisungen verlieren
Was schiefgeht
osCommerce 4 kann Products und Categories Front Ends oder Vertriebskanälen zuweisen und diese Zuweisungen mit Kundengruppenzugriff kombinieren. Werden Datensätze ohne ihren Zuweisungskontext migriert, kann der Katalog im falschen Kanal erscheinen oder für die vorgesehene Zielgruppe unsichtbar werden.
Frühe Warnsignale
Products existieren global, aber kanalspezifische Sichtbarkeit fehlt. Categories erscheinen in jedem Front End oder Kundengruppen können auf Products zugreifen, die für eine andere Marke, Region oder einen anderen Kanal vorgesehen waren.
| Zuweisungsebene | Was explizit bleiben muss | Folge bei Abflachung |
|---|---|---|
| Product zu Front End | Wo das Product angeboten wird | Kanalübergreifende Sichtbarkeit oder fehlende Sichtbarkeit |
| Category zu Front End | Wo die Browse-Struktur existiert | Leere oder doppelte Navigation |
| Product zu Kundengruppe | Wer auf das Product zugreifen darf | Kommerzielle Zugriffsgrenzen versagen |
Vorbeugung
Eine Kanalverantwortungsmatrix für Products, Categories, Inhalte, Währungen, Sprachen und Kundengruppen erstellen. Gemeinsame Identitäten erhalten und jeden Datensatz den vorgesehenen Front Ends zuweisen. Der Standardkanal darf nicht als universelles Ziel verwendet werden, wenn die Quellbedeutung nicht tatsächlich global ist.
Empfehlungsbeispiel
Ein Wholesale- und ein Retail-Front-End teilen dieselbe Product-Identität, bieten aber unterschiedliche Sortimente. Erhalten Sie stabile Product-Schlüssel und weisen Sie die Verfügbarkeit dem richtigen Front End und der richtigen Kundengruppe zu, statt alle Products zu duplizieren oder global sichtbar zu machen.
Bestehensbedingung
Jeder repräsentative Kanal zeigt ausschließlich die vorgesehenen Products, Categories, Inhalte und Customer-Zugriffe; gemeinsame Datensätze bleiben konsistent und keine Standardzuweisung überschreibt die Kanalverantwortung.
Fehler 3: Attribute, Properties und Product Groups abflachen
Was schiefgeht
Attribute können Käuferauswahl definieren, Properties Products beschreiben und vergleichbar machen, und Product Groups verwandte Products organisieren. Werden diese Strukturen gleich behandelt, entstehen Auswahlmöglichkeiten ohne eindeutige verkaufbare Einheit, Spezifikationen ohne Discovery-Funktion oder Product-Familien ohne ihre Beziehung.
Frühe Warnsignale
Jeder Quellwert wird zu einem Attribut, Product-Vergleich verliert Spezifikationen oder Product-Familien werden als unverbundene Datensätze dupliziert. Attributbezogene Modell-, Bild-, Mengen- oder Barcode-Details verschwinden.
| osCommerce-Struktur | Hauptbedeutung | Fehler bei Verwechslung |
|---|---|---|
| Attribut | Auswählbarer Product-Unterschied | Warenkorb erhält unvollständige Artikelidentität |
| Property | Beschreibendes/Vergleichsmerkmal | Suche und Vergleich werden schwach |
| Product Group | Beziehung zwischen Products | Familien und Merchandising fragmentieren |
Vorbeugung
Quell-Product-Daten nach Käuferfunktion und betrieblicher Granularität klassifizieren. Auswählbare Unterschiede in Attribut- oder Variationslogik, beschreibende Werte in Properties und Product-übergreifende Beziehungen in Product Groups erhalten. Attributdetails wie Modell, Menge, Bild oder Barcode bewahren, wenn sie die verkaufbare Einheit identifizieren.
Empfehlungsbeispiel
Eine Laptop-Familie verwendet Speichergröße als auswählbares Attribut, Prozessorgeneration als Property und verwandte Modelle in einer Product Group. Jede Rolle getrennt erhalten, statt alle Werte zu Dropdowns zu machen.
Bestehensbedingung
Repräsentative Products bieten gültige Kaufoptionen, behalten Vergleichs- und Discovery-Merkmale, erhalten verwandte Product-Gruppierung und bleiben auf Ebene der verkaufbaren Einheit nachvollziehbar.
Fehler 4: Katalogdatensätze erhalten, aber Discovery und Bestand beschädigen
Was schiefgeht
Products und Categories können vollständig sein, während Suche, Filter, Marken, Category-Zuweisungen, Bestand, Cross-Sells und Sortierreihenfolge nicht mehr unterstützen, wie Customers Products finden und kaufen. Eine reine Datensatzmigration kann so einen gefüllten, aber kommerziell schwachen Katalog erzeugen.
Frühe Warnsignale
Suche liefert schlechte Ergebnisse, Filter sind leer, Products verlieren Marken oder Categories, Bestand erscheint nur auf Parent-Ebene oder wichtige Beziehungen zu verwandten Products fehlen.
| Discovery-Ebene | Warnsignal | Auswirkung |
|---|---|---|
| Category-/Markenzuweisung | Product liegt im falschen Browse-Pfad | Erwartete Customer Journeys brechen |
| Properties und Filter | Werte sind unvollständig oder inkonsistent | Eingrenzung und Vergleich werden schwächer |
| Bestand und verwandte Products | Granularität oder Beziehungen gehen verloren | Verfügbarkeit und Merchandising führen in die Irre |
Vorbeugung
Repräsentative Discovery-Pfade vom Suchbegriff oder von der Category zum Product und Warenkorb definieren. Category-, Marken-, Property-, Filter-, Bestands-, Sortier- und Related-Product-Beziehungen auf der geschäftlich verwendeten Granularität erhalten. Inkonsistente Werte normalisieren, bevor sie zu Filteroptionen werden.
Empfehlungsbeispiel
Eine Kamera erscheint auf einer Markenseite, in einer Mirrorless-Category, in mehreren Filteransichten und in einer Zubehörbeziehung. Erhalten Sie jede Verbindung und den zuständigen Bestandswert, statt das Product nur deshalb freizugeben, weil seine Detailseite existiert.
Bestehensbedingung
Customers finden repräsentative Products über die vorgesehenen Such- und Browse-Pfade, Filter liefern konsistente Ergebnisse, Bestand gehört zum richtigen Artikel und verwandtes Merchandising bleibt nutzbar.
Fehler 5: Kundengruppen ohne Zugriffs- und Geschäftsregeln kopieren
Was schiefgeht
Kundengruppen können Product-Zuweisung, Preise, Steuern, Kontobehandlung und B2B-Verhalten beeinflussen. Werden Customers und Gruppenbezeichnungen ohne die verbundenen Regeln migriert, wirken Konten klassifiziert, erhalten aber Standardbedingungen.
Frühe Warnsignale
Alle Customers sehen dasselbe Sortiment und denselben Preis, zusätzliche Customer-Felder verschwinden oder Gruppenmitgliedschaft ist nicht mehr mit Front-End- oder Product-Beschränkungen verbunden.
| Customer-Beziehung | Gefährdete Bedeutung | Fehler |
|---|---|---|
| Customer zu Gruppe | Kommerzielle Identität | Konto erhält falsche Standardbehandlung |
| Gruppe zu Product/Front End | Zugriffsgrenze | Privates Sortiment wird offengelegt oder verborgen |
| Zusätzliche Customer-Felder | Betrieblicher oder B2B-Kontext | Vertrieb und Support verlieren benötigte Daten |
Vorbeugung
Das Ergebnis jeder aktiven Gruppe und jedes zusätzlichen Feldes dokumentieren. Mitgliedschaft, Zuweisungen, Preise, Kennungen und benötigten Kontokontext getrennt erhalten. Festlegen, welches Zielmodul oder welche Konfiguration das Verhalten anwendet; der Gruppenname allein aktiviert es nicht.
Empfehlungsbeispiel
Eine B2B-Gruppe greift auf ein Wholesale-Front-End zu und speichert einen Customer-Code, den ein ERP verwendet. Erhalten Sie Gruppenmitgliedschaft, Front-End-Zuweisung, Product-Zugriff und ERP-Code mit expliziter Zuständigkeit.
Bestehensbedingung
Repräsentative Customers gelangen in den richtigen Kanal- und Gruppenkontext, erhalten vorgesehenen Zugriff und kommerzielle Behandlung und behalten betriebliche Felder, die verbundene Systeme benötigen.
Fehler 6: Order-Historie auf Gesamtsummen und Endstatus reduzieren
Was schiefgeht
osCommerce-Orders können ausgewählte Attribute, Total-Module, Adressen, Kommentare, Status, Flags, Marker, zusätzliche Felder und externe Referenzen enthalten. Werden nur Gesamtsumme und Endstatus erhalten, fehlen die Nachweise, die Support, Finance, Returns und Integrationsabstimmung benötigen.
Frühe Warnsignale
Die Anzahl der Orders stimmt, aber Auswahlwerte der Positionen, Rabatt- oder Steuerkomponenten, Statuschronologie, Zahlungsreferenzen oder Custom-Order-Felder fehlen.
| Order-Komponente | Warum sie wichtig ist | Folge bei Auslassung |
|---|---|---|
| Positionsattribute | Identifizieren die gekaufte Konfiguration | Support kann den richtigen Artikel nicht ersetzen |
| Summenkomponenten | Erklären Rabatte, Steuern, Versand und Gebühren | Finance kann den Betrag nicht abstimmen |
| Historie/Flags/zusätzliche Felder | Erklären Prozess und externen Kontext | Betriebliche Bedeutung wird mehrdeutig |
Vorbeugung
Lesbare Order-Header, Positionen, Attribute, Summenkomponenten, Adressen, Daten, Status, Kommentare, Flags und stabile externe IDs erhalten. Quellstatus für historische Verständlichkeit übersetzen, aktive Zielabläufe aber von der Historie der alten Order trennen.
Empfehlungsbeispiel
Eine Wholesale-Order enthält Attributauswahl, verhandelten Rabatt, Fracht, Steuer, ERP-Referenz und mehrere Statuskommentare. Erhalten Sie jede Komponente und ihre Chronologie, damit Mitarbeitende die Transaktion erklären können, ohne den alten Workflow nachzubauen.
Bestehensbedingung
Repräsentative normale, stornierte, erstattete und angepasste Orders bleiben einschließlich Artikelidentität, Zusammensetzung der Summe, Chronologie und externer Referenzen verständlich und abstimmbar.
Fehler 7: CMS, Themes und Front-End-Design als eine Datenschicht behandeln
Was schiefgeht
Informationsseiten, Menüs, Blöcke, Themes, Visual-Editor-Strukturen und Front-End-Zuweisungen verbinden Inhalt mit Darstellung und Kanalverantwortung. Wird nur Seitentext migriert, kann Inhalt unerreichbar, dem falschen Front End zugewiesen oder von den Komponenten getrennt sein, die ihn nutzbar machen.
Frühe Warnsignale
CMS-Datensätze existieren, Menüs, Themes oder Front-End-Platzierungen fehlen jedoch. Ein Kanal zeigt Inhalte eines anderen Kanals oder eingebettete Medien und interne Links verwenden noch Quellpfade.
| Ebene | Was sie besitzt | Erforderliche Behandlung |
|---|---|---|
| CMS-Inhalt | Text, Medien, Metadaten | Migrieren, wenn weiterhin relevant |
| Menü-/Blockplatzierung | Erreichbarkeit und Kontext | Zielzuweisung neu aufbauen |
| Theme/Front End | Darstellung und Kanalumfang | Getrennt vom Inhalt implementieren |
Vorbeugung
Priorisierte Inhalte, Medien, Metadaten, Navigation, Blockplatzierung und Front-End-Verantwortung inventarisieren. Inhaltsidentität und Beziehungen erhalten und die Darstellung anschließend mit unterstützten Ziel-Themes und Komponenten neu aufbauen. Interne Links und Routenreferenzen als Teil desselben Inhaltspfads aktualisieren.
Empfehlungsbeispiel
Ein Einkaufsleitfaden liegt als CMS Page vor, ist aus einer Product Group verlinkt und nur in einem Front End sichtbar. Erhalten Sie Seite und Product-Beziehung, weisen Sie sie dem richtigen Front End zu und bauen Sie Menü- oder Blockplatzierung neu auf.
Bestehensbedingung
Priorisierte Inhalte sind korrekt, erreichbar, den vorgesehenen Front Ends zugewiesen, unter wartbaren Themes dargestellt und frei von defekten Quell-Links oder verborgenen Präsentationsabhängigkeiten.
Fehler 8: SEO-, Such- und Routenverantwortung erst nach den Datensätzen behandeln
Was schiefgeht
Suchbegriffe, Product- und Category-Pfade, Markenseiten, CMS-Routen, Metadaten und Redirects bestimmen, ob bestehende Customers und Suchmaschinen den migrierten Katalog erreichen. Werden neue Routen ohne Quelle-zu-Ziel-Matrix erzeugt, können hochwertige Einstiegspfade brechen, obwohl alle Products vorhanden sind.
Frühe Warnsignale
Prioritäts-URLs sind nicht inventarisiert, Routen unterscheiden sich nach Front End oder Sprache ohne klare Zuständigkeit, Suchsynonyme und Property-Daten fehlen oder interne Links zeigen noch auf stillgelegte Pfade.
| Routen-/Such-Asset | Fehlermuster | Auswirkung |
|---|---|---|
| Priorisierte Quell-URL | Kein explizites Ziel | Traffic landet auf Fehlern oder irrelevanten Seiten |
| Metadaten und Sprachroute | Ein Wert wird global wiederverwendet | Regionale Relevanz sinkt |
| Such-/Property-Daten | Begriffe und Filter sind unvollständig | Products werden schwerer auffindbar |
Vorbeugung
Eine Routenmatrix für priorisierte Products, Categories, Marken, CMS Pages und kanalspezifische Pfade erstellen. Metadaten und Sprachverantwortung erhalten, Redirects für geänderte Pfade definieren und Such- sowie Property-Werte ausreichend normalisieren, damit Discovery funktioniert.
Empfehlungsbeispiel
Ein Product hat getrennte Retail- und Wholesale-Pfade sowie eine stark frequentierte Markenseite. Ordnen Sie jede Quellroute einem passenden Ziel zu, statt sämtlichen Traffic auf eine generische Product-Seite umzuleiten.
Bestehensbedingung
Jede priorisierte Quellroute hat ein relevantes Ziel, Suche und Filter finden repräsentative Products, interne Links lösen korrekt auf und Front-End- oder Sprachgrenzen bleiben erhalten.
Fehler 9: Annehmen, Module und Erweiterungen würden mit ihren gespeicherten Daten mitwandern
Was schiefgeht
osCommerce-Module können Customer-Felder, Order-Strukturen, Zahlungs- und Versandverhalten, Marketingdaten, Marketplace-Anbindungen oder Product-Details ergänzen. Die Migration ihrer Datensätze installiert kein Modul, konfiguriert keine Zugangsdaten, erzeugt keine Events neu und garantiert nicht, dass das Ziel dasselbe Schema lesen kann.
Frühe Warnsignale
Von Modulen erzeugte Spalten sind vorhanden, aber kein Zielmodul ist zugeordnet. Zahlungs-, Versand-, Marketing- oder Reporting-Verhalten wird erwartet, nur weil historische Datensätze vertraute Bezeichnungen enthalten.
| Modulnachweis | Was möglicherweise migriert | Was separate Zuständigkeit benötigt |
|---|---|---|
| Zusätzliches Feld | Gespeicherter Wert und Kennung | Zielfeld/-modul, das den Wert liest |
| Zahlungs-/Versandreferenz | Historischer Name oder Transaktions-ID | Zugangsdaten, Callbacks, aktive Regeln |
| Marketing-/Marketplace-Daten | Externe IDs und Historie | Synchronisierung, Consent, Event-Verarbeitung |
Vorbeugung
Ein Modulabhängigkeitsregister mit Zweck, gespeicherten Daten, externem Konto, Zugangsdaten, Events und Zieleigentümer erstellen. Nur fortbestehende Werte und stabile Kennungen erhalten. Aktives Verhalten separat neu konfigurieren oder ersetzen und veraltete Modulreste ausschließen, nachdem bestätigt wurde, dass kein Prozess sie mehr nutzt.
Empfehlungsbeispiel
Historische Orders behalten eine Zahlungsreferenz aus einem Modul. Die Ziel-Zahlungsintegration wird unabhängig mit aktuellen Zugangsdaten und Callbacks konfiguriert; die alte Referenz bleibt ausschließlich historischer Nachweis.
Bestehensbedingung
Jeder fortbestehende modulspezifische Wert hat einen Zielnutzer, jedes aktive Verhalten eine konfigurierte Zuständigkeit und kein Modul gilt allein deshalb als funktionsfähig, weil seine historischen Daten migriert wurden.
Fehler 10: Verträge externer Systeme und stabile Kennungen beschädigen
Was schiefgeht
ERP-, PIM-, Lager-, Marketplace- und Reporting-Systeme können Products, Customers und Orders über stabile Schlüssel identifizieren, die sich von Storefront-IDs unterscheiden. Werden diese Kennungen neu erzeugt oder Aktualisierungsverantwortungen verändert, können Duplikate entstehen, maßgebliche Daten überschrieben oder Abstimmungen unterbrochen werden.
Frühe Warnsignale
Externe IDs werden wie optionale Notizen behandelt, mehrere Systeme beanspruchen Preis- oder Bestandsverantwortung, Webhook-/API-Nutzer sind nicht dokumentiert oder Zielimporte erzeugen neue Datensätze, statt bestehende Geschäftsobjekte zuzuordnen.
| Vertragsbestandteil | Frage | Fehlerfolge bei Unklarheit |
|---|---|---|
| Stabile Kennung | Welches System nutzt sie zur Datensatzzuordnung? | Duplikate und gebrochene Abstimmung |
| Feldverantwortung | Welches System ist maßgeblich? | Updates überschreiben einander |
| Event-/Update-Pfad | Wie werden Änderungen ausgetauscht und erneut versucht? | Daten werden veraltet oder inkonsistent |
Vorbeugung
Kennungen, Feldverantwortung, Richtung, Frequenz, Event-Trigger, Konfliktregeln und Fehlerbehandlung für jede fortbestehende Verbindung dokumentieren. Die für die Zuordnung verwendeten Schlüssel erhalten und die Zuständigkeiten des Zielshops explizit machen. Historische Referenzen dürfen nicht mit aktivem Synchronisationszustand verwechselt werden.
Empfehlungsbeispiel
Ein PIM besitzt Product-Beschreibungen, während ein ERP Bestand und Preise besitzt. Erhalten Sie die Product-Schlüssel, die beide Systeme erkennen, und definieren Sie, welche osCommerce-Felder jede Verbindung aktualisieren darf, damit ein Feed den anderen nicht überschreibt.
Bestehensbedingung
Verbundene Systeme ordnen die vorgesehenen Datensätze korrekt zu, maßgebliche Felder bleiben unter genau einem Eigentümer, Updates folgen einem dokumentierten Pfad und Ausnahmen lassen sich abstimmen, ohne auf verworfene IDs des Quellshops angewiesen zu sein.
Übergreifende Prioritäten zur Fehlervermeidung
Die Präventionsreihenfolge beginnt mit der Klärung von Plattformlinie und Vertriebskanalverantwortung und führt dann über Product-Strukturen, Discovery, Customer-Regeln, Orders, CMS, Routen und Module zu externen Verträgen. Diese Bereiche sind voneinander abhängig: Ein global vorhandenes Product kann weiterhin scheitern, wenn Front-End-Zuweisung, Kundengruppenzugriff, Property-Daten, Bestandsverantwortung oder externe Kennung falsch sind.
Die Tabellen liefern Prüfpunkte, die Bestehensbedingungen bleiben jedoch beziehungsorientiert. Die Migration ist erst kontrolliert, wenn repräsentative Datensätze in ihrem vorgesehenen Kanal nutzbar sind und jeder separate Modul- oder externe Prozess einen benannten Zieleigentümer hat.
Fazit
Eine belastbare osCommerce-Migration verlässt sich nicht auf Kontinuität des Markennamens. Sie übersetzt die tatsächliche Quelllinie in die aktuelle Zielarchitektur, schützt Vertriebskanal- und Customer-Grenzen, erhält die Bedeutung verkaufbarer Products und historischer Orders, baut CMS- und Modulverhalten bewusst neu auf und hält stabile Kennungen über verbundene Systeme hinweg intakt.
Häufige Fragen
Warum muss die osCommerce-Generation identifiziert werden?
Alte osCommerce-2.x-Shops, angepasste Ableitungen und osCommerce 4 können deutlich unterschiedliche Strukturen nutzen. Der gemeinsame Name beweist keine Kompatibilität von Feldern oder Abläufen.
Was ist ein typischer Vertriebskanalfehler in osCommerce 4?
Products und Categories können ohne ihre Front-End- und Kundengruppenzuweisungen migriert werden, wodurch Kataloge im falschen Kanal erscheinen oder im vorgesehenen Kanal verschwinden.
Wie unterscheiden sich Attribute und Properties?
Attribute stehen typischerweise für auswählbare Product-Unterschiede, während Properties Products beschreiben oder vergleichbar machen. Eine Vermischung kann sowohl Kaufverhalten als auch Discovery beschädigen.
Welche Order-Details sollten lesbar bleiben?
Erhalten Sie Positionsattribute, Summenkomponenten, Adressen, Statuschronologie, Kommentare, Flags, zusätzliche Felder und stabile externe Referenzen, die Support und Finance benötigen.
Migrieren osCommerce-Module zusammen mit ihren Daten?
Nein. Gespeicherte Werte und Kennungen können erhalten werden, Installation, Konfiguration, Zugangsdaten, Callbacks, Synchronisierung und Zielschemaverantwortung sind jedoch separate Aufgaben.
Warum sind externe Kennungen wichtig?
Sie ermöglichen ERP-, PIM-, Lager-, Marketplace- und Reporting-Systemen, dasselbe Geschäftsobjekt wiederzuerkennen. Ihr Verlust kann Duplikate erzeugen oder Abstimmung unterbrechen.