Wenn Jumpseller als mögliche Zielplattform bewertet wird, bedeutet die Übertragung von Daten dorthin mehr, als Quellspalten Zielfeldern zuzuordnen. Jumpseller trennt den übergeordneten Product-Datensatz, seine verkaufbaren Variants, vom Kunden eingegebene Individualisierung, beschreibende Custom Fields, Category-Zugehörigkeit, Navigation, Bestand, Customer-Identität, historische Orders, Storefront-Content und Integrationsdatensätze in unterschiedliche Beziehungen. Eine Quellplattform kann mehrere dieser Bedeutungen innerhalb eines einzigen Attributsystems oder einer einzigen Erweiterungstabelle speichern.
Die zentrale Übersetzungsfrage lautet deshalb nicht, ob ein Quellwert kopiert werden kann. Entscheidend ist, welches Jumpseller-Objekt diesen Wert besitzen soll und welche Beziehung dabei erhalten bleiben muss. Größe und Farbe können bestandsführende Variants definieren; ein Gravurtext kann als Eingabe an einer Order Line erhalten bleiben; eine Marke kann als filterbares Custom Field dienen; eine Category kann Products organisieren, ohne das alte Menü zu reproduzieren; und eine externe ID kann geschäftskritisch bleiben, obwohl Kunden sie nie sehen.
Products sind übergeordnete Katalogdatensätze und nicht automatisch vollständige Verkaufseinheiten
Ein Jumpseller Product bildet die gemeinsame Katalogidentität eines Verkaufsangebots. Es kann Name, Beschreibungen, Bilder, Category-Beziehungen, Status, Standardpreise, Bestandsregeln, SEO-Felder, Options, Custom Fields und weitere Merchandising-Informationen enthalten. Sobald Options jedoch Variants erzeugen, besitzt der übergeordnete Product-Datensatz nicht mehr jeden kommerziellen Wert allein.
Quellplattformen kombinieren Master-Product- und Verkaufseinheitsdaten unterschiedlich. Ein System kann jede Größen- und Farbkombination als eigenständiges Product speichern. Ein anderes hält ein Product mit untergeordneten SKUs. Ein drittes bewahrt den Parent-Datensatz, legt Bilder, Kosten, Bestand und Preisaufschläge jedoch in einer anwendungseigenen Matrix ab. Die Jumpseller-Zielstruktur muss die Parent-Child-Unterscheidung erhalten, statt alle Datensätze auf dieselbe Ebene zu reduzieren.
| Quell-Katalogmuster | Jumpseller-Interpretation | Folge für die Beziehung |
|---|---|---|
| Ein Datensatz für jede Größe und Farbe | Parent Product mit durch Options erzeugten Variants, wenn die Datensätze zu einer gemeinsamen Merchandising-Familie gehören | Gemeinsame Beschreibungen und Categories können auf dem Parent bleiben, während SKU, Bestand, Preis, Gewicht und Bilder den Variants gehören können. |
| Parent Product mit Child-SKUs | Product plus Variant-Kombinationen | Bestehende Child-IDs müssen der entsprechenden Option-Kombination zugeordnet bleiben. |
| Einfaches Product ohne auswählbare Varianten | Product mit eigenen kommerziellen Werten | Es ist keine künstliche Variant-Ebene nötig, nur weil das Quellsystem eine Attributtabelle besitzt. |
| Digitales oder nicht zu versendendes Product | Product mit anderem Fulfillment- und Bestandsverständnis als physische Ware | Lieferreferenzen, Dateien und Shipping-Erwartungen müssen vom gewöhnlichen Bestandsmodell getrennt bleiben. |
| App-erzeugte Product-Familie | Product-Datensätze plus anwendungseigene Beziehungen | Beschreibende Werte können in Standardfelder passen, während erzeugte Regeln oder verknüpfte Datensätze der Quellanwendung oder einem anderen Zielsystem gehören. |
Auch der Product-Status trägt Bedeutung. Ein Quellstatus wie aktiv, verborgen, Entwurf, archiviert, eingestellt oder nachbestellbar entspricht möglicherweise keinem einzelnen Jumpseller-Status. Die Zielabbildung sollte öffentliche Sichtbarkeit, Kaufbarkeit, Bestandsverfügbarkeit und saisonale Aufbewahrung unterscheiden, statt jeden Zustand in aktiviert oder deaktiviert zu komprimieren.
Options, Variants, Kundeneingaben und Custom Fields sind unterschiedliche Strukturen
Jumpseller Product Options können echte Variants erzeugen, doch nicht jeder optionsähnliche Quellwert gehört in ein Variant-Raster. Auswahl wie Größe oder Farbe kann Kombinationen mit eigener SKU, eigenem Preis, Bestand, Gewicht, Kosten und Bildbezug erzeugen. Andere Product-Eingaben erfassen Text, längere Nachrichten, Dateien oder optionale Auswahl, ohne eine separat bestandsführende Kombination zu erzeugen.
Custom Product Fields erfüllen einen anderen Zweck. Sie beschreiben ein Product und können die Auffindbarkeit unterstützen, wenn sie als geeignete auswählbare Werte modelliert werden. Marke, Material, Duftfamilie, Kompatibilitätstyp, Saison oder technische Spezifikation können in diese Ebene gehören, wenn sie keine eigenständig verkaufbaren Einheiten erzeugen.
| Geschäftliche Bedeutung | Geeignete Jumpseller-Struktur | Was nicht verloren gehen darf |
|---|---|---|
| Größe oder Farbe mit eigenem Bestand | Variant-erzeugende Product Option | Kombination, SKU, Bestand, Preis, Gewicht und Bildbeziehungen |
| Gravur, Widmung oder kurze Nachricht | Vom Kunden eingegebener Text | Der gewählte Wert muss mit der gekauften Order Line verbunden bleiben und darf nicht zur Parent-Product-Definition werden. |
| Ausführliche Personalisierungsanweisungen | Text-Area-Eingabe | Freie Kundeneingaben dürfen nicht in wiederverwendbare Katalogmetadaten umgewandelt werden. |
| Vom Käufer bereitgestelltes Artwork oder Dokument | Datei-Input | Die Dateireferenz gehört zum Kaufkontext und nicht zum Bestand. |
| Optionale Verpackung oder kostenpflichtiges Extra | Nicht-Variant-Auswahl, sofern entsprechend abbildbar | Preiseinfluss und gewählter Order-Line-Wert bleiben von einer bestandsführenden Variant getrennt. |
| Marke, Material, Aroma, Kompatibilitätsklasse oder Spezifikation | Custom Product Field | Die Beschreibung kann Product-Information oder Filterung unterstützen, ohne Variants zu vervielfachen. |
| Bedingte Konfiguratorregel | Anwendungs- oder externes Systemverhältnis | Abhängigkeiten, Formeln und bedingte Sichtbarkeit sind nicht dasselbe wie normale Option-Werte. |
Diese Unterscheidung verhindert unnötige Variant-Vervielfachung. Ein Quellkatalog, der Farbe, Größe, Monogrammtext, Garantieauswahl und technische Spezifikationen in einer Attributtabelle speichert, kann in Jumpseller vier verschiedene Zielrepräsentationen benötigen. Werden alle fünf Werte zu Variant-Dimensionen, entstehen Kombinationen, die keine echten Bestandseinheiten sind. Werden alle fünf zu Custom Fields, geht dagegen die Auswahl- und Bestandslogik realer Variants verloren.
Categories, Navigation und Filter bilden getrennte Beziehungen zur Auffindbarkeit
Jumpseller Categories organisieren Products und können Parent-Child-Hierarchien bilden. Sie können außerdem Namen, Beschreibungen, Bilder, Sortierung, SEO-Informationen und Product-Zugehörigkeit enthalten. Category-Datensätze sind damit wichtig für die Katalogstruktur, bilden aber nicht automatisch den vollständigen Storefront-Pfad nach.
Die Navigation kann Categories im Hauptmenü, in einem Category-Menü oder im Footer platzieren und diese Einträge unabhängig von der Product-to-Category-Beziehung verschachteln. Eine Quelltaxonomie kann zusätzlich interne Merchandising-Gruppen, Kampagnen-Collections, Marken, Suchfacetten oder versteckte Betriebslabels enthalten. Für jede Gruppierung muss deshalb eine eindeutige Zielbedeutung festgelegt werden.
| Quellgruppierung | Möglicher Jumpseller-Eigentümer | Übersetzungsentscheidung |
|---|---|---|
| Dauerhafte Product-Familie | Category und Product-Zugehörigkeit | Hierarchie und Zugehörigkeit als Katalogstruktur erhalten. |
| Hauptnavigationszweig | Navigationseintrag mit Verweis auf eine Category oder andere Seite | Route und Menüplatzierung getrennt von der Existenz der Category behandeln. |
| Marken- oder Materialfacette | Custom Product Field plus Filterbeziehung | Beschreibenden Wert verwenden, wenn er Products gruppiert, ohne eine kaufbare Auswahl zu definieren. |
| Größen- oder Farbfacette | Product Option plus Filterbeziehung | Option-Vokabular konsistent halten, damit äquivalente Auswahl filterbar bleibt. |
| Saisonale Kampagne | Category, Landing-Content, Promotion-Kontext oder Theme-Link | Das Objekt wählen, das die Kampagne tatsächlich besitzt, statt standardmäßig eine dauerhafte Taxonomie zu erzeugen. |
| Internes Reporting-Label | Backoffice-Feld oder Klassifikation eines externen Systems | Einen internen Code nicht allein deshalb als Storefront-Navigation veröffentlichen, weil er aus einer Category-Tabelle stammt. |
Jumpseller-Filter können auf Variant-erzeugenden Product Options und auswählbaren Custom Fields basieren. Damit wird Namenskonsistenz zu einem Teil des Datenmodells. „Color“, „Colour“ und „Finish“ können im Quellsystem dasselbe Geschäftskonzept meinen, aber als getrennte Filter erscheinen, wenn sie als unabhängige Felder übernommen werden. Umgekehrt müssen ähnlich benannte Werte getrennt bleiben, wenn der eine eine Variant definiert und der andere nur beschreibend ist.
Preise und Bestand können Product, Variant, Customer-Kontext oder Standort gehören
Preis- und Bestandswerte sind ohne ihren Eigentümer nicht aussagekräftig. Ein einfaches Product kann einen Preis und eine Bestandsmenge besitzen. Bei Products mit Variants können SKU, Preis, Kosten, Gewicht, Bilder und Bestand auf die jeweilige Kombination übergehen. Kundenspezifische Preise können eine zusätzliche Beziehung zwischen einer Customer Category und einer Preisliste erzeugen. Mengenpreise können Schwellenwerte ergänzen, ohne die grundlegende Product-Identität zu verändern.
Bestand kann außerdem standortbezogen sein. Wenn Standortbestand existiert, muss das Zielmodell die Beziehung zwischen Product oder Variant, Lagerstandort, Menge und Bestandsstatus erhalten. Eine einzige Gesamtmenge sagt nicht aus, welcher Standort einen Artikel erfüllen kann oder welche Integration für den Bestand maßgeblich ist.
| Kommerzieller Wert | Möglicher Eigentümer | Warum die Zuordnung wichtig ist |
|---|---|---|
| Basisverkaufspreis | Product oder Variant | Ein Parent-Preis kann unterschiedliche Preise realer Kombinationen nicht ersetzen. |
| Vergleichs- oder Referenzpreis | Product oder Variant | Der Referenzwert muss derselben Verkaufseinheit wie der aktive Preis zugeordnet bleiben. |
| Kosten | Product oder Variant | Margendaten werden irreführend, wenn variantenspezifische Kosten auf den Parent verschoben werden. |
| Mengenstaffel | Product oder Preisbeziehung | Schwellenwert und Stückpreis gehören zusammen. |
| Kundenspezifischer Preis | Customer Category und Preislistenbeziehung | Der Preis hängt von der Käuferklassifikation ab und ist kein universelles Product-Feld. |
| Bestand | Product oder Variant an einem Standort | Die Menge muss mit der richtigen Verkaufseinheit und dem richtigen Lagerstandort verbunden bleiben. |
| Unbegrenzter Bestand | Verfügbarkeitsregel von Product oder Variant | Eine leere oder null Menge ist nicht automatisch gleichbedeutend mit unbegrenztem Bestand. |
Historische Bestandsbewegungen sind ebenfalls vom aktuellen Bestand zu trennen. Orders können den Bestand beeinflussen, wenn sich ihr Status ändert, doch eine importierte Order ist historischer Nachweis und keine Anweisung, die ursprüngliche Bestandsbewegung erneut auszuführen. Das Ziel benötigt den beabsichtigten aktuellen Bestand und den historischen Order-Kontext als getrennte Informationen.
Customers, Customer Categories, Adressen und Marketingbeziehungen brauchen getrennte Bedeutung
Ein Jumpseller Customer-Datensatz stellt Konto- und Kontaktidentität dar. Ein Quellkundenprofil kann jedoch weit mehr als Name und E-Mail-Adresse enthalten. Adressen, Steuerkennzeichen, Unternehmensdaten, Marketingeinwilligung, Kontostatus, Notizen, Segmentierung, externe CRM-IDs und Customer-Category-Zugehörigkeit können jeweils unterschiedliche Eigentümer haben.
| Element des Quellkontos | Zielbedeutung in Jumpseller | Beziehungsgrenze |
|---|---|---|
| Name und E-Mail | Customer-Identität und Kontaktinformation | Identität sollte nicht dupliziert werden, nur weil dieselbe Person mehrere Orders besitzt. |
| Rechnungs- und Lieferadressen | Adresskontext am Customer oder an einer historischen Order | Aktuelle Kontoadressen und Order-Snapshots dürfen legitimerweise voneinander abweichen. |
| Unternehmens- oder Steuerdaten | Customer Field, Adressfeld oder externer Geschäftsdatensatz | Der Wert gehört zu dem Objekt, das ihn für Konto- oder Transaktionskontext verwendet. |
| Kundengruppe oder Wholesale-Stufe | Customer Category plus zugehöriger Preis- oder Zugriffskontext, soweit abbildbar | Ein kommerzielles Segment ist mehr als ein Label, wenn es Preise oder Berechtigungen verändert. |
| Newsletter-Einwilligung | Marketingbeziehung oder externe Marketingplattform | Bedeutung und Herkunft der Einwilligung müssen vom bloßen Vorhandensein eines Kontos getrennt bleiben. |
| Loyalty-Guthaben oder Membership-Status | Anwendungs- oder externes Systemobjekt | Ein Customer-Datensatz allein bildet das Programmverhältnis nicht nach. |
| CRM- oder ERP-ID | Stabile externe Kennung | Der Schlüssel muss mit demselben Personen- oder Unternehmensdatensatz verbunden bleiben, den das externe System verwendet. |
Passwortdaten benötigen eine eigene Bewertung. Ein Quell-Passworthash kann ein Verfahren verwenden, das Jumpseller nicht übernehmen kann. In diesem Fall bleibt die Customer-Identität sinnvoll erhalten, obwohl Zugangsdaten einen anderen Account-Access-Prozess benötigen. Das Datenmodell darf eine migrierte E-Mail-Adresse nicht als Beweis dafür behandeln, dass die ursprünglichen Login-Credentials portierbar sind.
Orders bewahren historischen Geschäftskontext und keine aktuelle Shopkonfiguration
Eine Jumpseller Order verbindet Customer- oder Guest-Identität, Order Lines, ausgewählte Variants, vom Kunden eingegebene Option-Werte, Adressen, Preise, Rabatte, Steuern, Versandkosten, Payment-Status, Fulfillment-Status, Notizen, Zeitstempel und externe Referenzen. Diese Werte bilden einen historischen Snapshot dessen, was zum Kaufzeitpunkt geschehen ist.
Dieser Snapshot muss von aktuellen Product- und Konfigurationsdatensätzen getrennt bleiben. Eine alte Order Line kann Product-Titel, SKU, ausgewählte Options und Preis behalten, selbst wenn das aktuelle Product später umbenannt, neu bepreist, deaktiviert oder gelöscht wurde. Eine historische Shipping Charge kann zeigen, was bezahlt wurde, ohne die aktuelle Versandmethode zu definieren. Eine Payment-Referenz kann die Abstimmung unterstützen, ohne das aktive Gateway zu konfigurieren.
| Order-Bestandteil | Historische Bedeutung | Zielbeziehung |
|---|---|---|
| Product-Identität der Order Line | Was zu diesem Zeitpunkt gekauft wurde | Product- oder Variant-Referenz soweit möglich erhalten und gleichzeitig Snapshot-Text bewahren. |
| Ausgewählte Options und Custom Inputs | Käuferauswahl für diese Position | Mit der Order Line erhalten, selbst wenn sich die aktuelle Product-Definition später ändert. |
| Preis, Rabatt und Steuer | Kommerzieller Snapshot | Historie nicht aus aktuellen Product- oder Tax-Einstellungen neu berechnen. |
| Rechnungs- und Lieferadresse | Adresse zum Transaktionszeitpunkt | Von späteren Änderungen am Customer-Profil getrennt halten. |
| Payment-Status und Referenz | Historischer Payment-Kontext | Der Datensatz besitzt nicht die aktuelle Gateway-Konfiguration. |
| Fulfillment-Status und Tracking | Historischer Lieferkontext | Der Datensatz definiert nicht die aktuellen Carrier- oder Lagerregeln. |
| Quellkanal oder externe ID | Abstimmungs- und Integrationsschlüssel | Schlüssel erhalten, wenn ein anderes System die Order darüber identifiziert. |
Guest Orders, stornierte Orders, teilweise erfüllte Orders, erstattete Orders und Orders mit Custom Inputs zeigen Beziehungen, die eine einfache bezahlte Order nicht sichtbar macht. Das Zielmodell sollte diese Zustände berücksichtigen, ohne historische Datensätze in aktive Workflow-Konfiguration umzuwandeln.
CMS Pages, Blog Posts, URLs und Theme-Content haben unterschiedliche Eigentümer
Jumpseller-Storefront-Content kann CMS Pages, Blog Posts, Product- und Category-Beschreibungen, Navigationseinträge, Banner, Theme-Bereiche, Bilder, Policy-Content und SEO-Felder umfassen. Eine Quellplattform kann all diese Inhalte in einem Page Builder oder einer Content-Tabelle speichern; Jumpseller ordnet sie dagegen verschiedenen Objekten zu.
| Quell-Content | Jumpseller-Interpretation | Eigentumsunterscheidung |
|---|---|---|
| About-, Contact-, Policy- oder Guide-Content | CMS Page | Stabiler Seiteninhalt und Route bleiben von Menüplatzierung und Theme-Layout getrennt. |
| Redaktioneller Artikel oder Ankündigung | Blog Post | Veröffentlichungsdatum, Autorenkontext, Categories oder Tags, Media und Permalink können sich von einer CMS Page unterscheiden. |
| Product- oder Category-Text | Katalogeigene Beschreibung | Der Content gehört zum Katalogobjekt und nicht zu einer separaten generischen Seite. |
| Header, Footer, Banner oder Homepage-Bereich | Theme- oder Navigations-Content | Platzierung in der Präsentation ist nicht dasselbe wie der zugrunde liegende Geschäftsdatensatz. |
| Meta Title, Meta Description oder Permalink | SEO- und Routenbeziehung am besitzenden Objekt | Metadaten müssen mit dem Product, der Category, CMS Page oder dem Blog Post verbunden bleiben, den sie beschreiben. |
| Redirect oder alter Pfad | Routing-Beziehung | Die alte URL bleibt relevant, selbst wenn das Zielobjekt einen anderen Permalink erhält. |
Theme-Code kann Product Fields, Custom Fields, Categories, Menüs und Anwendungsausgaben lesen, besitzt diese Datensätze aber nicht. Alte Markup-Strukturen zu reproduzieren ist kein Ersatz dafür, die zugrunde liegenden Daten richtig zu übertragen. Ebenso kann das Kopieren eines Content-Bodys ohne Links, Media, Route und Eigentümer eine Seite erzeugen, die zwar existiert, aber nicht mehr als Teil der Storefront funktioniert.
Apps, APIs, Webhooks und externe IDs bilden eine umliegende Datenebene
Jumpseller kann Daten über Anwendungen, APIs und Webhooks mit externen Systemen austauschen. Ein Quellshop kann für Bestand auf ein ERP, für Customer-Klassifikation auf ein CRM, für Versandstatus auf einen Fulfillment-Dienst, für Listings auf einen Marketplace oder für Subscriptions, Bookings, Reviews, Loyalty, Bundles oder Product-Konfiguration auf eine Anwendung angewiesen sein.
Diese Datensätze sollten nach Eigentum und nicht nach Sichtbarkeit klassifiziert werden. Ein auf einer Product Page angezeigter Wert kann im externen PIM maßgeblich sein. Eine in Jumpseller sichtbare Bestandsmenge kann aus einem ERP synchronisiert werden. Ein Customer Tag kann vom CRM abgeleitet sein. Eine Marketplace Listing ID kann ein Channel-Angebot und nicht das Core Product identifizieren.
| Integrationsdatensatz | Wahrscheinlicher Eigentümer | Übersetzungsanforderung |
|---|---|---|
| ERP Product- oder Variant-ID | ERP und Katalogbeziehung | Schlüssel auf dem entsprechenden Product oder der Variant erhalten, die für die Synchronisierung verwendet wird. |
| Warehouse- oder Location-ID | Bestands- oder Fulfillment-System | Standortidentität von einer reinen Bestandsmenge getrennt halten. |
| CRM Customer-ID | CRM- und Customer-Beziehung | Keine neue, unabhängige ID für dieselbe Person oder dasselbe Unternehmen erzeugen. |
| Marketplace Listing ID | Vertriebskanal-Listing | Listing nicht mit dem kanonischen Product oder der Variant verwechseln. |
| Von einer App erzeugter Subscription-, Booking- oder Loyalty-Datensatz | Anwendungsdomäne | Referenzen zu Parent Product, Customer und Order explizit erhalten. |
| Webhook-Synchronisierungsstatus | Integrationsprozess | Zeitstempel, Event-IDs und Cursor als operative Integrationsdaten und nicht als Storefront-Content behandeln. |
Ein kohärentes Ziel muss nicht jede Quelltabelle reproduzieren. Es benötigt aber einen definierten Eigentümer für jede Kennung und Beziehung, die Katalogverwaltung, Customer-Kontinuität, historische Abstimmung oder externe Synchronisierung unterstützt.
Eine Jumpseller-Zuordnung sollte Bedeutung vor Speicherort klären
Das stärkste Jumpseller-Datenmodell lässt sich als Reihe von Eigentumsentscheidungen zusammenfassen. Parent Products besitzen gemeinsames Merchandising. Variants besitzen verkaufbare Kombinationen. Customer Inputs gehören zunächst zur Product-Interaktion und später zu einer Order Line. Custom Fields beschreiben Products. Categories organisieren Katalogzugehörigkeit. Navigation besitzt Menüplatzierung. Customers besitzen Identität und Kontokontext. Orders besitzen historische Transaktions-Snapshots. Apps und externe Systeme besitzen ihre spezialisierten Datensätze und Kennungen.
| Frage zum Quellwert | Übersetzungsentscheidung |
|---|---|
| Erzeugt der Wert eine eigenständig bepreiste oder bestandsgeführte Einheit? | Auf Variant-Ebene darstellen und nicht als beschreibendes Custom Field. |
| Wird der Wert vom Käufer für einen einzelnen Kauf eingegeben? | Als Customer Input erhalten und mit der Order Line bewahren. |
| Beschreibt der Wert viele Products, ohne Variants zu erzeugen? | Geeignetes Custom Field oder Klassifikationsverhältnis verwenden. |
| Organisiert die Gruppierung Products oder steuert sie die Navigation? | Category-Zugehörigkeit von Menüplatzierung trennen. |
| Ist der Wert aktuelle Konfiguration oder historischer Nachweis? | Live-Katalog- und Betriebseinstellungen von Order-Snapshots trennen. |
| Verwendet ein anderes System die Kennung als Schlüssel? | Auf der Zielentität erhalten, die dasselbe Geschäftsobjekt repräsentiert. |
| Gehört der Datensatz einer Anwendung statt Jumpseller Core? | Anwendungsbeziehung erhalten, statt die Daten in ein unpassendes Standardfeld zu zwingen. |
Werden diese Fragen sauber beantwortet, kann der Zielshop die migrierten Daten kohärent verwalten. Das Zielmodell bildet ab, was jeder Datensatz bedeutet, welchem Objekt er gehört und wie er mit dem restlichen Jumpseller-Umfeld zusammenhängt.
Fazit
Jumpseller verändert die Datenbedeutung, indem Parent Products, Variants, Customer Inputs, Custom Fields, Categories, Filter, Navigation, Bestand, Customers, Orders, Content und Integrationen in unterschiedliche Beziehungen getrennt werden. Eine Quell-Attributtabelle, Customer-Tabelle oder ein Page-Builder-Datensatz kann deshalb mehrere Zielobjekte erfordern und nicht nur eine direkte Feldzuordnung.
Eine kohärente Migration erhält das Eigentum hinter jedem Wert. Products bleiben mit real verkaufbaren Variants verbunden, beschreibende Felder bleiben von Käuferauswahl getrennt, Categories bleiben von Navigation getrennt, Customer-Identität bleibt von Anwendungsprogrammen getrennt, Orders bleiben historische Snapshots und externe IDs bleiben den Systemen und Entitäten zugeordnet, die darauf angewiesen sind.
Häufige Fragen
Sind Jumpseller Product Options und Custom Fields dasselbe?
Nein. Product Options können je nach Typ Variants erzeugen oder Kundeneingaben erfassen. Custom Fields beschreiben das Product und können bei geeigneter Darstellung Filterung unterstützen. Ein Wert sollte danach zugeordnet werden, ob er eine verkaufbare Kombination erzeugt, eine einmalige Käuferauswahl erfasst oder das Product beschreibt.
Wann sollte ein Quellattribut zu einer Jumpseller Variant werden?
Wenn die Auswahl eine reale Verkaufseinheit mit eigener kommerzieller oder bestandsbezogener Bedeutung identifiziert, etwa eine eigene SKU, Preis, Bestandsmenge, Gewicht, Kosten oder Bildbeziehung. Beschreibende Werte und freie Personalisierung sollten außerhalb des Variant-Rasters bleiben.
Reproduzieren migrierte Categories automatisch das alte Menü?
Nein. Categories besitzen Product-Gruppierung und Hierarchie, während Navigation die Menüplatzierung und Routendarstellung steuert. Eine Category kann existieren, ohne im Hauptmenü aufzutauchen, und ein Menü kann auf CMS Pages, Blog Posts, Kampagnenseiten oder andere Ziele verweisen.
Wie sollten historische Orders mit aktuellen Products verbunden sein?
Historische Orders sollten ihre Order-Line-Snapshots, gewählten Options, Preise, Adressen, Status und externen Referenzen behalten. Wo eine zuverlässige Product- oder Variant-Beziehung vorhanden ist, kann sie erhalten bleiben. Spätere Katalogänderungen dürfen jedoch nicht nachträglich umschreiben, was die Order zum Kaufzeitpunkt festgehalten hat.
Was geschieht mit Daten einer Quellanwendung, für die es kein natives Jumpseller-Feld gibt?
Der Datensatz sollte beim tatsächlichen Anwendungs- oder externen Systemeigentümer klassifiziert bleiben. Wichtige Parent-Referenzen und stabile IDs können in einer geeigneten Zielstruktur erhalten werden, während spezialisiertes Verhalten von gewöhnlichen Product-, Customer- oder Order-Feldern getrennt bleibt.
Kann dasselbe Quellfeld bei verschiedenen Products unterschiedliche Jumpseller-Ziele haben?
Ja. Ein Quellfeld namens „Size“, „Type“ oder „Status“ kann je Product-Familie unterschiedliche geschäftliche Bedeutung haben. Das Ziel hängt davon ab, ob der Wert eine Variant erzeugt, das Product beschreibt, Verfügbarkeit steuert, Kundeneingaben erfasst, Filterung unterstützt oder zu einem externen Workflow gehört.