Wenn Storeden als potenzielle Zielplattform für einen bestehenden Shop bewertet wird, reicht es nicht, Datensätze in eine neue Administrationsoberfläche zu übertragen. Storeden beziehungsweise TeamSystem Commerce ist eine Cloud-Commerce-Umgebung, in der Katalogverwaltung, Bestand, Order-Verarbeitung, Zahlungen, Themes, Anwendungen, Marktplatzverkauf, Logistik, API-Ressourcen und Datensätze aus dem erweiterten TeamSystem-Ökosystem zusammenwirken können. Dieses Betriebsmodell verändert, wie migrierte Daten interpretiert werden müssen.
Ein Quellshop kann Products, Categories, Customers, Orders, SEO-Daten, App-Felder, Marktplatz-IDs oder ERP-Referenzen enthalten, die auf der bisherigen Plattform vollständig wirkten. Nach der Migration müssen dieselben Werte die Katalogstruktur, Channel-Bereitschaft, Order-Abläufe, Integrationen und das Reporting in Storeden unterstützen. Die entscheidende Datenmodellfrage lautet deshalb nicht nur, ob Datensätze ankommen, sondern ob sie innerhalb der Zielplattform weiterhin die richtige geschäftliche Bedeutung tragen.
Storeden-Daten auf einen Blick richtig einordnen
Die Migrationsplanung muss Datensatzübertragung und betriebliche Interpretation voneinander trennen. Ein Wert, der im Quellshop als Product-Option, Order-Notiz, Zahlungsbezeichnung, Versandart, Customer-Gruppe, benutzerdefiniertes Feld oder Marktplatzreferenz erscheint, kann in Storeden eine andere Behandlung benötigen.
| Datenbereich | Zu erhaltende Bedeutung | Frage zur Datenhoheit in Storeden | Warum der Unterschied wichtig ist |
|---|---|---|---|
| Products | Verkaufbare Katalogidentität | Name, Beschreibung, Bilder, Preis, Bestand, Category-Zuordnung, Sichtbarkeit und Channel-Bereitschaft | Ein Product kann vorhanden sein und trotzdem schlecht verkaufbar, auffindbar, administrierbar oder publizierbar sein. |
| Varianten und Optionen | Kaufentscheidung und operative SKU-Bedeutung | Variantenähnliche Auswahlwerte, Attribute, SKU-Beziehungen, Bestand, Bildlogik und Preisunterschiede | Die Optionsstruktur beeinflusst Storefront-Auswahl, Fulfillment, Bestand und Marktplatzfeeds. |
| Categories und Navigation | Product-Auffindbarkeit und Merchandising-Hierarchie | Category-Gruppierung, Menülogik, Product-Platzierung, Filter und SEO-Pfade | Ein Katalog kann im Backend vollständig aussehen, während die Auffindbarkeit für Käufer schlechter wird. |
| Bestand | Verfügbarkeit und Fulfillment-Verlässlichkeit | Mengen, SKU-Referenzen, Multichannel-Verfügbarkeit, Logistikabhängigkeiten und TeamSystem-gebundene Bestandsquellen | Bestandsbedeutung kann von mehreren Kanälen oder Systemen abhängen. |
| Customers | Konto-, Käufer- und Serviceidentität | Profil, Rechnungs-/Lieferhistorie, Kontaktdaten, Unternehmenskontext und externe Referenzen | Customer-Daten müssen Service, Order-Suche, Kontinuität und Marketing weiterhin unterstützen. |
| Orders | Historischer Handelskontext | Gekaufte Products, Customer-Bezug, Summen, Steuern, Zahlungs-/Versandangaben, Status und Marktplatzursprung | Order-Historie ist nur wertvoll, wenn Mitarbeiter sie nach der Migration verstehen und nutzen können. |
| Zahlung und Versand | Historische Bezeichnung gegenüber Live-Konfiguration | Erhaltene Order-Bezeichnungen im Vergleich zu aktiver Zahlungs-, Carrier-, Logistik- und Steuerkonfiguration | Migrierte Historie richtet keinen zukünftigen Checkout ein. |
| Marktplatzdaten | Kanalspezifischer Verkaufskontext | Listing-IDs, Marktplatz-Categories, Channel-Preise, Verfügbarkeitsregeln und Order-Ursprung | Marktplatzkontinuität kann über normale Product- und Order-Migration hinausgehen. |
| Apps und API-Daten | Workflow-Verantwortung und Integrationsidentität | App-eigene Daten, API-Referenzen, externe IDs, Automatisierung und TeamSystem-Verbindungen | Verbundene Abläufe können trotz migrierter Standarddaten Konfiguration oder ein separates Zieldesign benötigen. |
| SEO und Inhalte | Auffindbarkeit und Kontinuität | URLs, Redirects, Metadaten, Product-Texte, Category-Inhalte, Bildnamen und Theme-gesteuerte Seiten | Such- und Nutzerkontinuität hängt von Darstellung und Routing ab, nicht nur von importierten Datensätzen. |
Product-Daten werden zu einem verwalteten Storeden-Katalog
Product-Datensätze stehen sichtbar im Zentrum einer Storeden-Migration, ihre Bedeutung reicht jedoch weit über die einzelne Product-Zeile hinaus. Ein Quell-Product kann Titel, Beschreibungen, Codes, SKUs, Marken, Lieferanten, Steuerklassen, reguläre und Aktionspreise, Sichtbarkeit, Categories, Bilder, Variantenbeziehungen, Related Products, benutzerdefinierte Felder, Marktplatzattribute und externe Bestandskeys enthalten.
Storeden muss daraus einen zentral verwaltbaren Katalog bilden, der über die vorgesehenen Verkaufskanäle verteilt werden kann. Drei Ebenen sollten getrennt bleiben: das kommerzielle Product, das der Käufer sieht; der operative Artikel, den Mitarbeiter verwalten; und die Channel- oder Fremdsystemdarstellung, die Marktplätze, Bestandsdienste oder Buchhaltungssysteme verwenden.
| Quellelement | Interpretation in Storeden | Auswirkung auf Beziehungen |
|---|---|---|
| Product-Titel und Beschreibungen | Käufergerichteter Kataloginhalt | Sprache, Formatierung und Product-Identität müssen am selben kommerziellen Artikel bleiben. |
| SKU oder Product-Code | Operative oder systemübergreifende Identität | Varianten, Order-Positionen, Bestandsupdates und Integrationen müssen auf das richtige verkaufbare Element zeigen. |
| Bilder | Medienbeziehung zu Product oder Variante | Haupt-, Galerie- und variantenspezifische Bilder dürfen nicht zu einer ungeordneten Dateiliste abgeflacht werden. |
| Regulärer und Aktionspreis | Kommerzieller Wert, möglicherweise zeit- oder channelabhängig | Historische Order-Preise bleiben Nachweis; zukünftige Preisverantwortung liegt im Zielpreisprozess. |
| Category-Zuordnung | Katalogorganisation | Category-Mitgliedschaft ist nicht dasselbe wie Menüplatzierung oder Marktplatztaxonomie. |
| Sichtbarkeit oder Status | Publikationszustand | Aktive, verborgene, Entwurfs- und eingestellte Products brauchen eine bewusste Zielbedeutung. |
| Benutzerdefiniertes Feld | Beschreibungs-, Betriebs-, Channel- oder Integrationsdaten | Der Zielort richtet sich danach, wer den Wert nach der Migration liest oder aktualisiert. |
Ein Product ist erst dann vollständig abgebildet, wenn Identität, Variantenbeziehungen, Categories, Medien, Preiskontext und externe Schlüssel dasselbe verkaufbare Objekt beschreiben.
Varianten, Optionen und Attribute haben unterschiedliche Verantwortlichkeiten
Größe, Farbe, Material, Packungsmenge, Personalisierungstext, Bundle-Auswahl, Abonnementintervall oder Lieferpräferenz können in einem Quellexport alle als „Optionen“ erscheinen, stellen aber nicht zwangsläufig denselben Datensatztyp dar. Bei der Abbildung in Storeden müssen verkaufbare Varianten von beschreibenden Product-Informationen, Order-Positions-Eingaben, App-Logik und channelspezifischen Attributen getrennt werden.
Das ist wichtig, weil eine echte Variante eine eigene SKU, Bestand, Preis, Bild, Gewicht, Steuerlogik oder Marktplatzidentität tragen kann. Ein beschreibendes Attribut kann Filterung oder Product-Verständnis unterstützen, ohne einen separaten verkaufbaren Artikel zu erzeugen. Personalisierung kann an die Order-Position statt an das Product-Stammobjekt gehören. Bundle-Verhalten kann von einer App oder einem externen Bestandssystem berechnet werden.
| Quellmuster | Zielbedeutung | Beziehung, die eindeutig bleiben muss |
|---|---|---|
| Größe oder Farbe mit SKU und Bestand | Verkaufbare Variante | Parent Product, gewählte Werte, Bestand, Preis, Bild und Order-Position müssen auf dieselbe Variante zeigen. |
| Material oder technische Eigenschaft | Beschreibendes Attribut oder Filterwert | Strukturierte Bedeutung erhalten, ohne fälschlich bestandsführende Varianten zu erzeugen. |
| Personalisierungstext | Käuferangabe zu einem Kauf | Wert bei der relevanten Order-Position erhalten, wenn er historisch sichtbar bleiben muss. |
| Bundle oder Kit | Zusammengesetzte Handels- oder Bestandsbeziehung | Festlegen, ob Storeden, eine Anwendung oder ein externes System die Komponentenlogik besitzt. |
| Marktplatzattribut | Channel-Taxonomie oder Listing-Anforderung | Vom kanonischen Webshop-Product-Modell getrennt halten, sofern die Bedeutung nicht identisch ist. |
| ERP-verknüpfter Code | Systemübergreifender Schlüssel | Stabilen Identifier erhalten, ohne ihn unnötig als Storefront-Inhalt offenzulegen. |
Diese Interpretation verhindert einen Katalog, der visuell korrekt aussieht, aber nicht mehr eindeutig zeigt, welcher Artikel bepreist, bestandsgeführt, veröffentlicht oder ausgeliefert wird.
Categories, Navigation und Channel-Taxonomien sind getrennte Strukturen
Eine Quell-Category kann gleichzeitig Katalogparent, Menüpunkt, SEO-Landingpage, Aktionsgruppe, Filterregel, Reporting-Segment oder Mapping zu einer Marktplatztaxonomie sein. Storeden sollte nicht all diese Bedeutungen durch einen einzigen Category-Datensatz übernehmen.
| Quellstruktur | Rolle in Storeden | Konsequenz für die Datenhoheit |
|---|---|---|
| Parent-Child-Category-Baum | Kanonische Katalogorganisation | Product-Mitgliedschaft und Hierarchie bleiben Datenbeziehungen. |
| Storefront-Menü | Navigationsdarstellung | Reihenfolge und Beschriftung können Categories referenzieren, sind aber nicht das Category-Modell selbst. |
| Category-Beschreibung und Metadaten | Landingpage-Inhalt | Content- und SEO-Bedeutung müssen an der richtigen öffentlichen Route bleiben. |
| Filter oder Facette | Discovery-Logik aus strukturierten Werten | Das zugrunde liegende Attribut muss über Products hinweg konsistent bleiben. |
| Manuelle Collection oder Kampagnengruppe | Merchandising-Beziehung | Sie kann Kuratierung, Regeln oder Theme-Darstellung statt einer dauerhaften Category erfordern. |
| Marktplatz-Category | Channelspezifische Taxonomie | Mapping getrennt vom Storefront-Category-Baum erhalten. |
Durch diese Trennung kann Storeden den Katalog zentral verwalten, während Storefront und Marktplätze Products jeweils über ihr eigenes Discovery-Modell präsentieren.
Bestandswerte benötigen ein eindeutig bestimmtes führendes System
Eine Quellmenge kann physischen Bestand, verkaufbaren Bestand, Reservierungen, Lieferantenverfügbarkeit, Lagerbestand, Channel-Verfügbarkeit, Vorbestellkapazität oder einen aus dem ERP synchronisierten Wert bedeuten. Storeden sollte den Bestandswert erhalten, der zu seiner Rolle passt, zusammen mit den IDs, die zukünftige Aktualisierungen mit dem richtigen führenden System verbinden.
| Bestandsmuster | Bedeutung | Entscheidung zur Verantwortung in Storeden |
|---|---|---|
| Eine Menge je Product | Einfache verkaufbare Verfügbarkeit | Storeden kann den Wert führen, wenn kein anderes System den Bestand verwaltet. |
| Menge je Variante oder SKU | Verfügbarkeit gehört zum verkaufbaren Child | Variantenidentität und Bestand müssen zusammenbleiben. |
| ERP- oder lagergeführter Bestand | Externe operative Hoheit | Storeden kann synchronisierte Verfügbarkeit erhalten, während das externe System führend bleibt. |
| Marktplatzspezifische Verfügbarkeit | Channel-Zuteilung | Channel-Regeln von physischem beziehungsweise kanonischem Bestand trennen. |
| Bundle-Bestand | Aus Komponentenverfügbarkeit abgeleitet | Komponenten-IDs und Verantwortlichen der Berechnung erhalten. |
| Nicht bestandsgeführter Artikel oder Service | Verfügbarkeit ist keine physische Menge | Keine Bestandsbeziehungen erfinden, die im Quellmodell nicht existierten. |
Die Migration sollte Anfangsbestände erhalten, soweit dies sinnvoll ist. Noch wichtiger ist, Product- oder Variantenkeys zu erhalten, damit spätere Bestandsupdates den richtigen Datensatz erreichen.
Customer- und Kontodaten erfüllen mehrere Rollen
Customer-Datensätze können Käufer, Kontoinhaber, Newsletter-Kontakte, Unternehmenskonten, B2B-Einkäufer, Rechnungs- oder Lieferempfänger, Marktplatzkunden, CRM-Datensätze oder mit TeamSystem verbundene Identitäten darstellen. Werden sie zu einer flachen Customer-Liste zusammengeführt, kann der Zielshop an Nutzwert verlieren.
Die Planung muss definieren, was Customer-Kontinuität für den Händler bedeutet. Manche Shops benötigen vor allem die Suche in alten Orders. Andere benötigen Kontozugang, Segmentierung, B2B-Beziehungen, Marketingberechtigung, Rechnungsreferenzen oder Integrationskontinuität.
| Customer-bezogener Wert | Datenmodellfrage | Relevanz für die Storeden-Migration |
|---|---|---|
| Name und E-Mail | Handelt es sich um echtes Konto, Käuferdatensatz oder Kontakt? | Dubletten oder unvollständige Datensätze können Service und Marketing beeinträchtigen. |
| Rechnungs- und Lieferadressen | Sind Adressen vollständig und dem richtigen Customer oder der richtigen Order zugeordnet? | Mitarbeiter benötigen sie für historische Order-Prüfung und Kundenservice. |
| Customer-Gruppe oder Segment | Ist der Wert beschreibend, preisrelevant oder berechtigungsrelevant? | Preis- und Zugriffsverhalten kann Zielkonfiguration oder separates Zieldesign erfordern. |
| Unternehmens- oder Steuerdaten | Nutzt der Händler B2B- oder Rechnungsprozesse? | Unternehmensdaten können für Buchhaltung und Order-Historie wichtig sein. |
| Externe IDs | Verlassen sich CRM, ERP, Buchhaltung oder Marketing darauf? | IDs erhalten oder mappen, wenn sie operativ weiter gebraucht werden. |
| Einwilligungs- und Marketingdaten | Enthält die Quelle rechtlich sensible Präferenzdaten? | Kontaktmigration nicht als Erlaubnis zur ungeprüften Wiederverwendung von Marketingdaten behandeln. |
Ein brauchbares Storeden-Customer-Modell erlaubt Mitarbeitern, Customers korrekt zu erkennen, zu betreuen und zu segmentieren. Datensatzanzahlen allein erhalten Konto-, Segmentierungs-, B2B-, Einwilligungs- oder Fremdsystembedeutung nicht.
Orders erhalten historische Handelsbeziehungen
Eine Storeden-Order ist dann nützlich, wenn sie den historischen Kauf erklärt: wer gekauft hat, welches Product oder welche Variante gewählt wurde, welche Menge und welcher Preis galt, welche Rabatte und Steuern die Summe veränderten, wie Zahlung und Versand bezeichnet waren, aus welchem Kanal die Order kam und welcher Status- oder Trackingkontext folgte.
| Historischer Order-Wert | Zu erhaltende Bedeutung | Separates Zielthema |
|---|---|---|
| Product- und Variantenbezeichnungen | Identität des gekauften Artikels | Die aktuelle Product-Struktur kann sich weiterentwickeln, ohne historische Positionen umzuschreiben. |
| Preis, Rabatt und Steuer | Kommerzieller Snapshot zum Kaufzeitpunkt | Zukünftige Preise, Kampagnen und Steuerregeln gehören zur aktuellen Konfiguration. |
| Zahlungsbezeichnung oder Transaktionsreferenz | Nachweis, wie die Order bezahlt wurde | Erzeugt keine Live-Zahlungsverbindung. |
| Versandart und Tracking | Historischer Fulfillment-Kontext | Definiert keine aktuellen Carrier-Tarife oder Logistikregeln. |
| Status und Notizen | Vergangener Betriebszustand | Neue Order-Workflows dürfen andere Status verwenden. |
| Marktplatzursprung | Channel-Zuordnung und Reporting-Kontext | Aktuelle Listings und Synchronisierung bleiben separate Datensätze. |
Diese Trennung hält Order-Historie lesbar, ohne historische Labels fälschlich für zukünftigen Checkout, Zahlung, Steuer oder Fulfillment verantwortlich zu machen.
Marktplatz- und Multichannel-Daten bilden eine parallele Datenebene
Storedens Multichannel-Rolle macht Marktplatzdaten zu einer parallelen Ebene und nicht nur zu einigen zusätzlichen Product-Feldern. Listing-IDs, Channel-Categories, Angebotstitel, Channel-Preise, Verfügbarkeitsregeln, Marktplatzattribute, Verkäuferreferenzen und Order-Ursprünge können sich auf dasselbe kanonische Product beziehen und trotzdem einem bestimmten Channel oder Connector gehören.
| Channel-Datensatz | Kanonische Beziehung | Eigentumsgrenze |
|---|---|---|
| Listing-ID | Verbindet Storeden-Product oder Variante mit einem externen Angebot | Erhalten, wenn zukünftiger Connector oder Reporting-Prozess sie weiter nutzt. |
| Marktplatz-Category | Ordnet Product der Channel-Taxonomie zu | Nicht in den Storefront-Category-Baum von Storeden übernehmen. |
| Channel-Preis | Kommerzieller Wert für ein bestimmtes Ziel | Klären, ob Storeden, Middleware oder Marktplatz den endgültigen Preis veröffentlicht. |
| Channel-Bestand | Zugewiesene oder synchronisierte Verfügbarkeit | Channel-Regel vom physischen beziehungsweise kanonischen Bestand trennen. |
| Marktplatz-Order-Ursprung | Historischer Sales-Channel-Kontext | Auf Orders erhalten, wenn er Reporting und Service unterstützt. |
| Feed-Attribut | Vom Channel benötigte Product-Daten | Separat speichern, wenn es nicht die kanonische Product-Bedeutung darstellt. |
Die wichtige Beziehung lautet: ein kanonischer Handelsartikel, mehrere Channel-Darstellungen. Die Migration sollte diese Identität bewahren, ohne jedes Marktplatzobjekt als eigenständiges Storeden-Product zu duplizieren.
Apps, APIs und TeamSystem-Verbindungen bestimmen die Datenhoheit
Storeden kann Teil eines größeren Ökosystems aus Anwendungen, APIs, Buchhaltung, Bestand, Logistik, Marktplätzen und TeamSystem-Workflows sein. Solche Verbindungen erzeugen Datensätze, die im Shop sichtbar sein können, aber weiterhin anderswo erstellt oder geführt werden.
| Verantwortlicher | Typische Daten | Abbildungsregel |
|---|---|---|
| Storeden Core Commerce | Products, Categories, Customers, Orders | Beziehungen zwischen unterstützten Datenkategorien direkt in Storeden erhalten. |
| Anwendung oder Connector | Reviews, Loyalty-Daten, individuelle Optionen, Feeds, Automatisierungszustände | Prüfen, ob die Zielanwendung einen entsprechenden Datensatz und dauerhafte ID bereitstellt. |
| ERP, Buchhaltung, CRM oder Lager | Product-Codes, Bestandsführung, Customer-Keys, Rechnungsreferenzen | Systemübergreifenden Key erhalten und das vollständige externe Datenmodell nicht unnötig duplizieren. |
| Marktplatz | Listing-, Angebots-, Taxonomie- und Channel-Status | Nur Datensätze erhalten, die der fortgeführte Channel-Prozess benötigt. |
| Theme- oder Storefront-Ebene | Layout, Blöcke, Menüs und Darstellungsverhalten | Darstellung getrennt von kanonischen Commerce-Daten neu erstellen. |
| API-Workflow | Import-, Update-, Synchronisierungs- oder Eventlogik | Workflow als Integrationsdesign behandeln, nicht als statisches migriertes Feld. |
Enthält die Quelle nicht unterstützte Anwendungstabellen oder proprietäre Connector-Daten, sollte das Migrationsmodell deren geschäftliche Bedeutung und externe IDs nur dann erhalten, wenn ein eindeutig definierter Verantwortlicher auf der Zielseite existiert.
Inhalte, URLs und SEO-Daten besitzen eigene Beziehungen
Product-Beschreibungen, Category-Texte, Seiten, Blog Posts, Bilder, Metadaten, interne Links, Menüs und Redirects können über den Quellshop verteilt sein. Storeden sollte Content-Verantwortung von Katalogverantwortung trennen, selbst wenn der Inhalt auf einer Product- oder Category-Route erscheint.
| Content- oder Routenelement | Beziehung zu Commerce-Daten | Zielbedeutung |
|---|---|---|
| Product-URL | Öffentliche Route zu einem Product | Route kann sich ändern, während Product-Identität durch interne/externe Keys stabil bleibt. |
| Category-URL | Öffentliche Route zu einer Kataloggruppe | Category-Hierarchie, Slug, Menüplatzierung und Redirect hängen zusammen, sind aber getrennt. |
| Metadaten | Suchmaschinenbeschreibung einer öffentlichen Ressource | Am richtigen Product, an der richtigen Category oder Seite erhalten. |
| Umfangreicher Seiteninhalt | Redaktionelle oder Theme-gesteuerte Darstellung | Über die passende Content- oder Storefront-Ebene neu aufbauen, wenn es kein gewöhnlicher Katalogtext ist. |
| Bilder und Alt-Kontext | Medienbeziehung zu Products oder Content | Zuordnung und Reihenfolge erhalten, nicht nur Dateien. |
| Interner Link | Beziehung zwischen öffentlichen Routen | Umschreiben, wenn sich Quellpfade ändern. |
| Redirect | Kontinuitätsregel von alter Route | Als Routinglogik statt Product-Inhalt erhalten. |
Diese Trennung verhindert, dass die Katalogmigration mit Theme-Verhalten überladen wird, schützt aber weiterhin Inhalte und Routen, die Products auffindbar machen.
Fazit
Storeden verändert die Bedeutung von Daten dort, wo ein zentral verwaltetes Product über Varianten, Categories, Bestand, Marktplätze, Anwendungen und externe Geschäftssysteme dargestellt wird. Derselbe Quellwert kann Katalogdaten, Channel-Attribut, Order-Snapshot, Connector-Key oder Storefront-Inhalt sein - abhängig davon, wer ihn besitzt und wie er aktualisiert wird.
Ein schlüssiges Storeden-Migrationsmodell definiert deshalb eine kanonische Product-Identität, erhält Varianten- und Order-Beziehungen, benennt das führende Bestandssystem, trennt Webshop-Categories von Marktplatztaxonomien und übernimmt nur jene externen IDs, die fortgeführte Integrationen tatsächlich benötigen. Das schafft ein saubereres Multichannel-Modell, als jedes Quellfeld ohne Eigentumskontext in Storeden zu kopieren.
Häufige Fragen
Warum ist Product-Migration bei Storeden mehr als ein Product-Import?
Product-Daten müssen Storefront-Darstellung, Category-Platzierung, Bestandsvertrauen, Preise, Bilder, Channel-Bereitschaft und Verwaltung unterstützen. Ein Product ist unvollständig, wenn Varianten, Category-Zuordnung, Sichtbarkeit oder Marktplatzattribute nicht mehr dieselbe Bedeutung tragen.
Konfigurieren migrierte Orders Zahlung und Versand in Storeden?
Nein. Migrierte Orders erhalten historische Zahlungs- und Versandinformationen als Referenz. Zukünftiger Checkout, Zahlung, Versand, Logistik, Steuer und Fulfillment gehören zu separaten aktuellen Plattformdatensätzen und zur Betriebskonfiguration.
Wann sollten Marktplatzdaten separat geprüft werden?
Wenn der Quellshop channelspezifische Listings, Preise, Categories, Attribute, Bestandsregeln, Order-Ursprünge oder Marktplatz-IDs verwendet. Diese Werte können sich anders verhalten als gewöhnliche Webshop-Product-Felder.
Wie sollten benutzerdefinierte Felder und externe IDs behandelt werden?
Sie sollten nach ihrer geschäftlichen Nutzung klassifiziert werden. Unterstützen sie ERP, Buchhaltung, CRM, Logistik, Marktplatzsynchronisierung oder Reporting, benötigen sie gegebenenfalls Mapping, strukturierte Zielbehandlung oder ein separates Zieldesign statt einer simplen Feldübertragung.
Warum reichen Datensatzanzahlen für die Storeden-Datenabbildung nicht aus?
Anzahlen zeigen nicht, ob Varianten weiterhin verkaufbare Artikel identifizieren, Bestand dem richtigen System gehört, Marktplatzdaten verknüpft bleiben, Orders ihren kommerziellen Kontext behalten oder externe IDs noch die richtigen Systeme verbinden. Entscheidend ist die Bedeutung der Beziehungen.
Wie sollten Marktplatz- oder Channel-Integrationen die Datenhoheit in Storeden beeinflussen?
Bestimmen Sie, welches System das kanonische Product, den Bestandswert, die Customer-Identität, den Order-Status und die externe Listing-ID führt. Erhalten Sie die systemübergreifenden Keys, die operativ weiter gebraucht werden, aber duplizieren Sie integrationsgenerierte Datensätze nicht so, als wäre Storeden deren ursprüngliche Quelle.