Bei der Bewertung von VTEX als mögliche Zielplattform sollte die Datenmodellplanung mit einer Übersetzungsfrage beginnen: Welche Quellobjekte werden zu nutzbaren VTEX-Commerce-Strukturen, und welche gehören künftig in eine andere VTEX-Domäne, die Storefront-Implementierung, eine Integration oder ein externes System? VTEX ist eine modulare Commerce-Umgebung. Die Bedeutung der Daten verteilt sich deshalb auf Catalog, SKUs, Specifications, Pricing, Promotions, Checkout, Orders, Logistics, Sellers, Marketplace-Kontext, Master Data, Search, Storefront-Implementierung und externe Systeme.
Damit unterscheidet sich VTEX von Plattformen, auf denen Product-, Customer-, Order-, Seiten- und URL-Daten weitgehend als einzelne Datensätze betrachtet werden können. Eine Product Option aus dem Quellshop kann in VTEX zu einem SKU, einer Specification, einer Storefront-Auswahl, einem Custom Field oder zu einer Anforderung für einen Neuaufbau werden. Ein Customer-Feld kann gewöhnlicher Profilkontext, Master Data, B2B-Information, CRM-geführte Identität oder Integrationsmetadatum sein. Eine historische Order kann für Supportzwecke wichtig bleiben, konfiguriert aber nicht automatisch VTEX Checkout, Payments, Fulfilment, Marketplace oder Logistics.
Der stärkste Migrationsumfang ist deshalb nicht der größtmögliche Transfer. Er erhält nutzbare Datenbedeutung und trennt migrierte Datensätze zugleich von VTEX-Setup, Frontend-Implementierung, Integrationsverantwortung, strukturiertem Mapping oder dedizierter Zielbehandlung sowie von Anforderungen, die eine gezielte Umstrukturierung benötigen.
Commerce-Bedeutung ist in VTEX über mehrere Services verteilt
VTEX-Daten sollten anhand der Plattformdomäne interpretiert werden, die sie nach der Migration verantwortet. Catalog-Daten können Product-Darstellung, Search, Pricing, Promotions, SKU-Verfügbarkeit, Logistics und Marketplace-Verhalten beeinflussen. Order History kann für Service und Reporting relevant sein, während die Verarbeitung neuer Orders von Checkout, Payments, Fulfilment, Logistics und operativer Konfiguration abhängt. Customer-Daten können auf den ersten Blick einfach wirken, während Master Data, Segmentierung, B2B-Kontext, CRM-Identifikatoren oder Custom Forms eigene Entscheidungen erfordern.
Dieses verteilte Modell verändert die Migrationsprüfung. Ein Feld, das im Quellshop wie ein gewöhnliches Product Attribute aussah, kann in VTEX eine Specification sein. Eine Quellvariante kann eine Struktur auf SKU-Ebene benötigen. Ein Kanalpreis kann zu Pricing-Regeln oder Price Tables gehören und nicht in den Product-Datensatz. Eine Marketplace-Seller-Referenz ist möglicherweise kein gewöhnliches Catalog-Feld. Eine Content-Seite kann Storefront-Implementierung oder Redirect-Planung benötigen statt einer direkten Eins-zu-eins-Übertragung.
| Quellobjekt oder Funktionsweise | Interpretationsfrage in VTEX | Konsequenz für die Migration |
|---|---|---|
| Product Option oder Variant | Definiert sie einen verkaufbaren SKU, eine Product Specification oder eine Auswahl in der Storefront? | Die Beziehung zwischen Product, SKU und Specification muss im Umfang explizit sein. |
| Attribute oder Custom Field | Dient es Filterung, Product Detail, Operations, Integration oder einem Customer Workflow? | Das Mapping richtet sich nach der geschäftlichen Funktion, nicht nur nach ähnlichen Feldnamen. |
| Kanalpreis oder Promotion | Handelt es sich um Basispreis, Price Table, Vertriebskanalbedingung, Coupon oder aktive Promotion-Regel? | Aktives kommerzielles Verhalten muss von historischen Preisdaten getrennt werden. |
| Zusätzliches Customer-Feld | Ist es Profildatum, Master Data, B2B-Kontext, CRM-Metadatum oder integrationsgeführte Information? | Einige Werte benötigen begrenztes Mapping oder Filtering, gezielte Umstrukturierung oder Behandlung im externen System. |
| Order Status oder Fulfilment-Notiz | Ist dies historischer Support-Kontext oder aktuelles OMS-/Logistics-Verhalten? | Order-Migration darf nicht als Konfiguration des Zielworkflows missverstanden werden. |
VTEX erfordert damit ein bedeutungsorientiertes Mapping. Für jeden Datenbereich müssen zukünftiger Owner und Zweck feststehen. Davon hängt ab, ob ein Feld in migrierte Datensätze, VTEX-Konfiguration, Storefront-Implementierung, Integrationsdaten, ein neu strukturiertes Zielmodell oder in einen bewussten Ausschluss gehört.
Die Katalogübersetzung beginnt mit Category-, Brand-, Product-, SKU- und Specification-Beziehungen
Der VTEX Catalog ist keine flache Product-Tabelle. Seine Kernstruktur verbindet Categories, Brands, Products, SKUs und Specifications. Ein Product ist die allgemeine kommerzielle Definition, jeder SKU dagegen die bestandsführbare und kaufbare Variante beziehungsweise physische Einheit. Category-gebundene Specification Groups bestimmen, welche Product- und SKU-Eigenschaften gelten, und können über Category-Ebenen vererbt werden.
| Quellstruktur | Interpretation in VTEX | Folge für die Beziehung |
|---|---|---|
| Parent Product mit Child Variants | Product mit einem oder mehreren SKUs | Verkaufbare Identität, Bilder, Inventory und gegebenenfalls Order Lines gehören auf SKU-Ebene. |
| Product Attribute | Product Specification | Category-gebundene Feld- und Wertebedeutung erhalten statt nur Freitext zu kopieren. |
| Variant Attribute wie Größe oder Spannung | SKU Specification | An den SKU binden, der die physische Variante repräsentiert. |
| Brand oder Hersteller | Brand-Beziehung | Den Wert nicht zu Text reduzieren, wenn Navigation oder Discovery von der Brand-Entität abhängen. |
| Category Tree | Catalog-Klassifizierung | Category-Zuordnung bestimmt Specification-Vererbung und Product-Organisation. |
| Product Image Set | SKU-Medienbeziehung | VTEX verbindet kaufbare Verfügbarkeit und Bildmaterial mit aktiven SKUs. |
| Bundle, Kit oder konfigurierbare Zusammenstellung | Kit, Attachment, Assembly Option, Service oder externe Logik | Bestimmen, welche VTEX-Struktur Komponenten- und Preisbeziehung tatsächlich besitzt. |
Eine Migration kann jeden Product-Namen aus der Quelle erhalten und trotzdem einen schwachen VTEX-Katalog erzeugen, wenn SKUs, Specifications, Bilder, Categories und Brands nicht mehr dasselbe verkaufbare Angebot beschreiben.
Specifications, Attachments und Assembly Options tragen unterschiedliche Bedeutungen
VTEX Specifications sind strukturierte Eigenschaften, die Categories zugeordnet und auf Products oder SKUs angewendet werden. Sie können Navigation, Vergleich, Auswahl, Integration oder Darstellung unterstützen. Ihr Zweck ist daher genauso wichtig wie der Wert. Ein Feld "Farbe", das als Filter dient, ist nicht dasselbe wie eine Freitextnotiz zur Farbe. Eine Größe, die SKUs unterscheidet, ist nicht dasselbe wie eine Maßangabe auf Product-Ebene.
VTEX trennt Specifications außerdem von optionalen Strukturen zur Product-Anpassung. Attachments können Informationen zu einem SKU erfassen. Assembly Options können komplexere Kombinationen, Mengen, zusätzliche Artikel, Kosten und Inventory-Beziehungen darstellen. Kits bündeln gemeinsam verkaufte SKUs; kostenpflichtige Extras können über SKU-Service-Beziehungen abgebildet werden. Diese Konzepte dürfen nicht in einer generischen "Option"-Spalte zusammenfallen.
| Bedeutung in der Quelle | Zielkonzept in VTEX | Zentrale Unterscheidung |
|---|---|---|
| Beschreibende Eigenschaft | Product Specification | Beschreibt das allgemeine Product. |
| Variantenbestimmende Eigenschaft | SKU Specification | Unterscheidet die verkaufbare Einheit. |
| Vom Käufer bereitgestellte Information | Attachment | Ergänzt Informationen zu einem SKU, ohne zwingend einen weiteren SKU zu erzeugen. |
| Komponente oder konfigurierbare Kombination | Assembly Option | Bildet zusätzliche Artikel, Mengen, Kosten oder Inventory-Beziehungen ab. |
| Gruppe verkaufbarer Einheiten | Kit | Erhält eine Zusammensetzung gemeinsam verkaufter SKUs. |
| Kostenpflichtiges Extra zu einem Artikel | SKU-Service-Beziehung | Hält das Extra getrennt von der Identität des Basis-SKU. |
Das Zielmodell sollte die Struktur erhalten, die Product-Identität, Käuferauswahl, Inventory und die Interpretation von Order Lines steuert, und nicht lediglich Bezeichnungen und Werte bewahren.
Pricing, Promotions, Trade Policies und Offers bilden getrennte kommerzielle Ebenen
Ein Quellexport kann Preis, Sale Price, Kanal, Marketplace und Verfügbarkeitswerte direkt neben dem Product-Datensatz ausgeben. VTEX verteilt diese Bedeutungen auf Catalog, Pricing, Promotions, Trade Policies, Logistics, Inventory und Seller Offers. Derselbe SKU kann dadurch in unterschiedlichen kommerziellen Kontexten vorkommen, ohne zu mehreren Products zu werden.
| Kommerzieller Datensatz | Bedeutung in VTEX | Folge für die Eigentümerschaft |
|---|---|---|
| Basis- oder Listenpreis | Pricing-Beziehung zu einem SKU | Preis ist kein dauerhafter Product-Wert. |
| Promotion- oder Coupon-Ergebnis | Regelbasierte kommerzielle Anpassung | Historische Discount-Nachweise auf Orders sind von aktiven Promotion-Regeln getrennt. |
| Trade Policy | Vertriebskanalkontext | Bestimmt, wo Products oder SKUs verfügbar sind, und kann kommerzielle Bedingungen verknüpfen. |
| Inventory und Logistics | Verfügbarkeit und Fulfilment-Versprechen | Bestand und Lieferung werden außerhalb des beschreibenden Catalog-Datensatzes geführt. |
| Seller Offer | Kommerzielles Angebot eines Sellers für einen Katalogartikel | Marketplace-Identität und Seller-Verantwortung bleiben von der Product-Definition getrennt. |
| Kanalspezifisches Sortiment | Product-Verfügbarkeit über Trade Policy oder Seller | Beziehung erhalten, statt das Product zu duplizieren. |
Dieses mehrschichtige Modell ist besonders wichtig, wenn der Quellshop regionale Kataloge, B2B-Preislisten, Marketplace Offers oder ERP-geführtes Pricing verwendet. Die Migration sollte die Identifikatoren bewahren, die einen SKU mit Preis, Kanal, Seller, Inventory und Logistics verbinden.
Customers, B2B-Datensätze und Master Data benötigen eine explizite Identität
Customer-bezogene Daten können in VTEX Shopper Profiles, Adressen, B2B-Organisationsstrukturen, CRM-Identifikatoren, Consent-Datensätze, Custom Forms und Master-Data-Dokumente umfassen. Master Data ist eine native Key-Document-Datenbank zum Speichern, Suchen, Erweitern und Personalisieren von Daten. Ein benutzerdefinierter Datensatz kann deshalb ein eigenes operatives Objekt darstellen und nicht nur ein zusätzliches Customer-Feld.
| Quellobjekt | Möglicher Owner in VTEX | Identitätsfrage |
|---|---|---|
| Shopper Profile | Customer- oder Profildaten | Welche E-Mail, welches Dokument oder welcher externe Schlüssel identifiziert die Person? |
| Adresse | Customer-bezogener Adressdatensatz | Ist sie wiederverwendbare Account-Information, Snapshot einer Order oder beides? |
| Company, Organization, Buyer Role oder Cost Center | B2B-Domäne oder Custom Data Model | Welche Beziehungen steuern Zugriff, Freigabe, Catalog oder Preiskontext? |
| Loyalty-, CRM- oder Qualification-Wert | Master Data oder externes CRM | Welches System aktualisiert den Wert und welcher Schlüssel verbindet ihn mit dem Customer? |
| Custom Form Submission | Master-Data-Dokument | Ist dies ein Customer-Attribut, Workflow-Datensatz oder eine eigenständige Entität? |
| Marketing Consent | Customer- oder Marketing-Systembeziehung | Zweck, Zeitpunkt, Quelle und rechtliche Bedeutung erhalten, soweit erforderlich. |
Saubere Identität verhindert, dass nicht zusammengehörige Personen, Unternehmen, Adressen und Custom-Workflow-Datensätze in einem Profil zusammengeführt werden. Bevor einzelne Zielfelder gewählt werden, sollte das Migrationsmodell dauerhafte Schlüssel und die Kardinalität der Beziehungen definieren.
Orders erhalten Commerce-Historie über getrennte Betriebsdomänen hinweg
Eine historische VTEX Order kann Customer-Identität, Seller, Trade Policy, SKU Lines, Preise, Promotions, Taxes, Zahlungsnachweise, Shipping-Daten, Fulfilment, Status und externe Referenzen verbinden. Diese Beziehungen erklären die vergangene Transaktion. Sie machen aktuelle Checkout-, Payment-, OMS-, Logistics-, Inventory-, Carrier- oder Warehouse-Konfiguration jedoch nicht zu Bestandteilen des Order-Datensatzes.
| Order-bezogener Wert | Historische Bedeutung | Getrennte Live-Domäne |
|---|---|---|
| SKU Line und Seller | Was von wem gekauft wurde | Aktueller Catalog und Seller Offers können sich später ändern. |
| Preis und Discount | Kommerzieller Snapshot | Aktive Pricing- und Promotions-Regeln sind getrennt. |
| Payment Transaction Reference | Nachweis der Zahlungsabwicklung | Aktuelle Gateway- und Antifraud-Konfiguration sind getrennt. |
| Shipping Method, SLA und Adresse | Historisches Lieferversprechen | Logistics, Docks, Warehouses, Carrier und Pickup Points sind getrennt. |
| Status- und Fulfilment-Daten | Vergangener OMS-Zustand | Neue Orders können einem anderen operativen Flow folgen. |
| Externe Order ID | Systemübergreifende Abstammung | Erhalten, wenn ERP, Marketplace, Customer Service oder Reporting sie weiterhin verwendet. |
Entscheidend ist das Beziehungsmodell: Welche historischen Werte bleiben an die Order gebunden, und welche Live-Domänen verantworten zukünftiges Verhalten?
Marketplace Catalogs, Sellers und Offers benötigen getrennte Eigentümerschaft
VTEX kann als Marketplace, als Seller oder als Teil eines verbundenen Marketplace-Netzwerks arbeiten. Marketplace-Daten umfassen daher mehr als Products und Orders. Dazu können Seller-Identitäten, Seller SKUs, Catalog Matches, Offers, Preise, Inventory, Provisionen, Fulfilment-Verantwortung, Product- und Category-Mappings sowie externe Listing-Referenzen gehören.
| Marketplace-Ebene | Bedeutung | Zu erhaltende Beziehung |
|---|---|---|
| Canonical Product und SKU | Gemeinsame Catalog-Identität | Seller Offers sollen auf den vorgesehenen Katalogartikel verweisen. |
| Seller | Kommerzieller und operativer Owner | Seller-Identität von Brand, Lieferant oder Hersteller getrennt halten. |
| Offer | Seller-spezifischer Preis-, Inventory- und Fulfilment-Kontext | Offers nicht in die Product-Definition einbetten. |
| Catalog Mapping | Beziehung zwischen externen und VTEX-Product-/Category-Strukturen | Mapping Key erhalten, wenn der Connector weiterverwendet wird. |
| Herkunft einer Marketplace Order | Kanal- und Seller-Historie | Erhalten, wenn Support, Settlement oder Reporting davon abhängen. |
| Provisions- oder Settlement-Referenz | Finanzieller Marketplace-Kontext | Beim System belassen, das Settlement verantwortet, statt sie in gewöhnliche Order-Felder zu zwingen. |
Für jeden Marketplace-Datensatz aus der Quelle muss feststehen, ob er in VTEX zu einer Catalog-Beziehung, einem Seller Offer, einem externen Connector-Datensatz, einem historischen Order-Attribut oder einem weiterhin extern geführten Objekt wird.
Storefront, CMS Pages, Blog Posts, Search und URLs von der Kerndatenübertragung trennen
Die VTEX-Storefront-Implementierung kann Headless Frontends, CMS-Komponenten, Search-Verhalten, Merchandising, Redirects und SEO-Kontinuität umfassen. Ein Product kann erfolgreich zu VTEX migriert sein, während das Storefront-Erlebnis noch unvollständig ist. Eine CMS Page kann wichtigen Content enthalten, ohne eine direkte Eins-zu-eins-Entsprechung in der Ziel-Storefront zu besitzen. Blog Posts können für organischen Traffic relevant sein; ihre Behandlung hängt jedoch von Migrationsumfang und Plattformsetup ab.
Für die Datenmodellplanung sollten Content- und URL-Datensätze nach ihrer geschäftlichen Rolle und nicht nur nach ihrem Datensatztyp bewertet werden. Eine Category URL kann Catalog Path, Search Landing Page, Merchandising Page oder SEO Asset sein. Eine Content-Seite kann Policy Page, Buying Guide, Campaign Landing Page oder Custom Layout sein. Eine Search-Regel kann plattformeigen, app-geführt oder implementierungsspezifisch sein.
| Quell-Asset | Planungsfrage für VTEX |
|---|---|
| Product URL | Soll sie weiterleiten, gleichwertig bleiben oder über Storefront Routing neu aufgebaut werden? |
| Category- oder Collection-Seite | Dient sie Catalog-Organisation, Navigation, Search Experience, SEO Content oder Merchandising? |
| CMS Page | Soll sie als Content migriert, in der Storefront neu erstellt, umgeleitet oder eingestellt werden? |
| Blog Post | Gehört er zum Migrationsumfang, SEO-Umfang, zur Content-Strategie oder zu einer separaten CMS-Entscheidung? |
| Search-/Filterlogik | Wird sie durch Specifications, Search-Konfiguration, App-Verhalten oder Custom Implementation gesteuert? |
Diese Trennung verhindert, dass Catalog-Datensätze als vollständig gelten, obwohl kundenseitige Discovery-, Content- und URL-Beziehungen noch ungeklärt sind.
Externe Systeme und Custom Data bestimmen die tatsächliche Migrationsgrenze
VTEX-Migrationen umfassen häufig ERP, CRM, PIM, OMS, WMS, Marketplace Middleware, Payment Provider, Loyalty-Systeme, Tax-Systeme, Analytics, Customer-Service-Tools und benutzerdefinierte Storefront-Anwendungen. Diese Systeme können Product-Identifikatoren, Preise, Inventory, Customer-Attribute, Order-Referenzen, Seller-Daten, Fulfilment-Informationen oder Custom Records führen.
Der Migrationsumfang muss die Systemverantwortung benennen. Wird ein Quellwert nach dem Launch durch einen ERP-Feed überschrieben, ist er nur dann relevant, wenn er als Anfangszustand, historische Referenz oder Reconciliation Key benötigt wird. Muss eine externe ID Orders, Customers oder Products systemübergreifend weiter verbinden, kann ihre Erhaltung geschäftskritisch sein. Unterstützt ein Custom Record einen Workflow, den VTEX nicht als Standard-Commerce-Daten abbildet, kann ein gezieltes Mapping oder eine Umstrukturierung notwendig sein.
| Externer oder benutzerdefinierter Datentyp | Umfangsentscheidung |
|---|---|
| ERP Product- oder Order-ID | Erhalten, wenn für Reconciliation oder Synchronisierung erforderlich. |
| PIM Attribute Set | Nur Werte abbilden, die für VTEX Catalog, Specifications oder Search benötigt werden. |
| CRM Customer Identifier | Erhalten, wenn Customer-Service- oder Marketing-Workflows davon abhängen. |
| WMS- oder Fulfilment-Referenz | Entscheiden, ob sie zur Historie, zum Integrationssetup oder zu Custom Handling gehört. |
| App- oder Middleware-Daten | Unterstütztes Migrationsverhalten prüfen, bevor Übertragbarkeit angenommen wird. |
Begrenztes Field Mapping oder Filtering kann helfen, wenn eine Anforderung durch unterstütztes Filtern, Mapping oder Konfiguration abgedeckt wird. Gezielte Umstrukturierung sollte geprüft werden, wenn nicht unterstützte Daten, Custom Records, spezielle Transformation, Custom-Source-Interpretation oder Anpassungen der Migrationslogik außerhalb des unterstützten Verhaltens erforderlich sind.
Eigentumsgrenzen definieren den VTEX-Migrationsumfang
Der VTEX-Umfang wird durch Eigentümerschaft und Beziehungen bestimmt, nicht durch Datensatzvolumen. Ein kleiner Katalog kann strukturell komplex sein, wenn Specification-Vererbung, Assembly Options, mehrere Trade Policies, Sellers, Master-Data-Dokumente oder externe Identifikatoren beteiligt sind. Ein großer Katalog kann vergleichsweise geradlinig sein, wenn Products, SKUs, Categories, Brands und Specifications einem konsistenten Modell folgen.
| Quellmuster | Kernfrage | Konsequenz für den Umfang |
|---|---|---|
| Product mit mehreren kaufbaren Varianten | Welches Quellobjekt wird zum VTEX SKU? | Parent Product, SKU-Identität, Specifications, Bilder und Inventory-Referenzen erhalten. |
| Regionales oder B2B-Sortiment | Welche Trade Policy, welcher Preis und welche Zugriffsbeziehung gelten? | Kommerziellen Kontext von Product-Identität trennen. |
| Custom Customer- oder Workflow-Tabellen | Ist der Datensatz Profil, Master-Data-Dokument, B2B-Entität oder externes Objekt? | Entität und dauerhafte Beziehung modellieren, statt beliebige Customer-Felder anzulegen. |
| Marketplace Catalog | Ist VTEX Marketplace, Seller oder beides? | Kanonische Catalog-Datensätze von Seller Offers und Mapping Keys trennen. |
| Headless- oder Custom-Storefront-Content | Welches CMS, welche App oder welches Repository besitzt den Content? | Storefront-Implementierung nicht als gewöhnliche Catalog-Daten behandeln. |
| ERP/PIM/WMS/OMS-Integration | Welches System ist für jeden Wert führend? | Systemübergreifende IDs und Ownership-Regeln erhalten, ohne externe Modelle zu duplizieren. |
Diese Grenze hält das VTEX-Modell über Catalog-, kommerzielle, Customer-, Marketplace-, Content- und operative Domänen hinweg kohärent.
Fazit
VTEX verteilt Commerce-Bedeutung über miteinander verbundene Domänen. Categories, Brands, Products, SKUs und Specifications bilden den Catalog. Pricing, Promotions, Trade Policies, Inventory, Logistics und Seller Offers ergänzen den kommerziellen Kontext. Customer- und B2B-Datensätze können in Master Data hineinreichen. Orders erhalten historische Beziehungen über Checkout, Payments, OMS und Fulfilment. Storefront Content und externe Systeme behalten eigene Verantwortungsgrenzen.
Das Migrationsmodell sollte deshalb Schlüssel und Beziehungen bewahren, statt jeden Wert in Products, Customers oder Orders zu verdichten. Klare Eigentümerschaft über die VTEX-Domänen hinweg sorgt dafür, dass Products auffindbar, SKUs verkaufbar, Orders verständlich, Seller Offers zuordenbar und externe Integrationen mit dem richtigen Datensatz verbunden bleiben.
Häufige Fragen
Warum sind SKUs bei einer VTEX-Migration so wichtig?
SKUs steuern häufig verkaufbare Varianten, Preis, Inventory, Verfügbarkeit, Logistics und Auswahl in der Storefront. Werden Product Options aus der Quelle nicht in nutzbare VTEX-SKU- und Specification-Strukturen übersetzt, können Products zwar migriert sein, aber kommerzielle oder operative Erwartungen dennoch verfehlen.
Werden alle Quellattribute zu VTEX Specifications?
Nein. Quellattribute müssen nach ihrem Zweck bewertet werden. Manche gehören zu Specifications, manche definieren SKUs, andere zu Content oder Integrationen, und einige sollten ausgeschlossen werden, wenn sie das Zielbetriebsmodell nicht mehr unterstützen.
Können Promotions und Preisregeln aus der Quelle als Product-Felder migriert werden?
In der Regel nicht. Promotions, Coupons, Price Tables, Vertriebskanalbedingungen und externe Pricing-Logik müssen getrennt von Basispreisen betrachtet werden. Einzelne Werte können als Referenz erhalten bleiben, während aktives kommerzielles Verhalten VTEX-Setup oder Integrationsarbeit benötigt.
Sind historische Orders dasselbe wie das VTEX-OMS-Setup?
Nein. Historische Orders erhalten, soweit unterstützt, den Kontext vergangener Käufe. Die Verarbeitung neuer Orders gehört zu aktueller Checkout-, Payment-, OMS-, Logistics-, Inventory- und Seller-Konfiguration.
Wann benötigen VTEX-Daten ein separates Entitätsmodell?
Wenn ein Quellobjekt nicht ohne Verlust von Identität oder Beziehungen zu einem Catalog-, Customer-, Master-Data-, Order-, CMS-, Seller- oder externen Datensatz werden kann. Owner, Schlüssel und Beziehungen der Entität sollten definiert werden, bevor einzelne Felder zugeordnet werden.
Wie beeinflussen Trade Policies und SKU-Beziehungen die VTEX-Migration?
Das Product trägt die gemeinsame beschreibende Bedeutung, SKUs repräsentieren verkaufbare Varianten, und Trade Policies können Sortiment, Preis, Logistics oder kommerziellen Kontext verändern. Das Mapping muss diese Beziehungen erhalten, damit ein Datensatz nicht allein deshalb als vollständig gilt, weil die Product-Hülle vorhanden ist.