CS-Cart bildet Commerce über Beziehungen ab, die sich leicht fälschlich einebnen lassen. Products können Features, Filter, Options, Option Exceptions und Product Variations enthalten. Categories und Products können unterschiedlichen Storefront-Umfängen angehören. Multi-Vendor-Editionen ergänzen Vendors, Vendor-Administratoren, seller-eigene Products, Marketplace Orders, Provisionen und Auszahlungskontext. Customer Groups können Preise, Zugriff und Promotions beeinflussen. Plattform-Erweiterungen können Datensätze einführen, die überhaupt nicht zum Kernkatalog gehören.
Diese Unterschiede sind wichtig, weil ähnliche Bezeichnungen im Quellsystem kein ähnliches Verhalten garantieren. Ein Feld „Farbe“ kann ein beschreibendes Feature, ein Filterwert, eine Option mit Preiswirkung oder ein Feature zur Erzeugung separater Product Variations sein. Ein Quellshop kann zu einem unabhängigen CS-Cart-Storefront, einer regionalen Marketplace-Niederlassung oder lediglich einer lokalisierten Darstellung werden. Ein Supplier kann in einem System eine interne Referenz und in einem anderen ein Marketplace Vendor mit Product- und Order-Verantwortung sein.
Eine CS-Cart-Migration erfordert deshalb die Übertragung von Zuständigkeit und Beziehungen, nicht nur von Feldnamen. Ziel ist, die Bedeutung jedes Datensatzes für Katalog, Storefront, Seller, Customer, Order und angebundene Systeme zu erhalten.
CS-Cart trennt Katalogfakten, Kaufentscheidungen und verkaufbare Variations
CS-Cart verwendet unterschiedliche Strukturen für Product-Fakten und Product-Auswahlmöglichkeiten. Features sind untrennbare Product-Eigenschaften wie Marke, Material, ISBN oder technische Spezifikation. Sie können gruppiert und für Vergleich, Filterung oder Katalogorganisation genutzt werden. Options sind getrennte Käuferentscheidungen wie Gravur, Geschenkverpackung oder Garantie; sie besitzen keinen eigenen Bestand, können aber Preis oder Gewicht beeinflussen. Product Variations sind Products, die über ausgewählte Feature-Werte gruppiert werden, und jede Variation bleibt ein Product mit eigener kommerzieller Identität.
| Quellwert | Verantwortliche CS-Cart-Struktur | Bedeutung, die getrennt bleiben muss |
|---|---|---|
| Technische Spezifikation | Product Feature oder Feature Group | Beschreibt das Product und kann Filterung oder Vergleich unterstützen. |
| Vom Käufer gewählte Konfiguration | Product Option und Option Variant | Verändert die gekaufte Konfiguration, ohne eigenständiger Lagerbestand zu werden. |
| Untergeordnete SKU für Farbe/Größe | Product Variation innerhalb einer Variation Group | Bleibt ein Product und kann eigene SKU, Preis, Bestand, Bild und Katalogsichtbarkeit tragen. |
| Unzulässige Auswahlkombination | Option Exception oder Verfügbarkeitsregel einer Variation | Verhindert ungültige Konfigurationen, statt einen neuen Attributwert zu erzeugen. |
| Wiederverwendbare Merchandising-Auswahl | Global Option oder templateähnliche Struktur | Eine Definition kann mehreren Products zugewiesen werden. |
| Suchfacette | Filter auf Basis von Features oder anderen unterstützten Werten | Benötigt normalisierte Werte und korrekte Category-Beziehungen. |
Besonders wichtig ist die Trennung zwischen Variations und sichtbaren Katalogeinträgen. Jede Variation ist ein Product, aber sie muss nicht zwingend einen eigenen sichtbaren Platz in Product-Listen besitzen. Ein Quellkatalog, der jede untergeordnete SKU als eigenes Product darstellt, kann mehrere sichtbare Katalogeinträge benötigen; ein anderer Katalog zeigt nur ein Parent Product und hält die meisten Variation-Entscheidungen auf der Product-Seite.
Werden alle Quell-Options als CS-Cart Features abgebildet, geht Kaufverhalten verloren. Werden alle Spezifikationen zu Options, entstehen unnötige Auswahlmöglichkeiten. Werden alle untergeordneten SKUs in ein Product zusammengeführt, können eigenständige Bestände und Identitäten verschwinden. Die korrekte Struktur richtet sich danach, welche Funktion der Quellwert tatsächlich steuert.
Products, Categories, Features und Filter bilden das Discovery-Modell
Ein CS-Cart Product enthält zentrale kommerzielle Felder, Bilder, Preis, Menge, Status, Versand- und Steuerinformationen, Beschreibungen, Categories, Features, Options, Dateien und erweiterungseigene Werte. Categories liefern Hierarchie und Storefront-Umfang; Features strukturierte Fakten; Filter machen ausgewählte Werte für die Produktsuche nutzbar.
Eine Source Category kann Navigation, SEO-Landingpage, Marke, technische Klassifikation oder interne Gruppierung darstellen. Diese Bedeutungen sollten nicht automatisch Categories bleiben. Eine als Category gespeicherte Marke kann besser als CS-Cart Brand Feature abgebildet werden. Ein Spezifikationsbaum für facettierte Navigation kann Feature Groups und Filter benötigen. Eine Merchandising-Landingpage kann zusätzlich zu Product-Zuweisungen Inhalte und Blocks erfordern.
| Discovery-Struktur im Quellsystem | Übersetzungsfrage für CS-Cart | Auswirkung auf Beziehungen |
|---|---|---|
| Category-Hierarchie | Welche Categories bleiben für Käufer sichtbar und welche sind intern? | Product-Zuordnung und Storefront-Verantwortung hängen davon ab. |
| Brand Categories | Soll die Marke zu einem Product Feature werden? | Die Marke kann Filterung und Vergleich unterstützen, ohne Navigation zu duplizieren. |
| Facettenwerte | Sind es normalisierte Features, Options oder Custom Extension Fields? | Nur die richtige Verantwortungsstruktur kann konsistente Filter ermöglichen. |
| Products in mehreren Categories | In welchen Categories und Storefronts soll jedes Product erscheinen? | Ein Product kann vorhanden sein und dennoch in einem wichtigen Käuferpfad fehlen. |
| Product-Dateien | Sind es Downloads, Anhänge, Handbücher oder Erweiterungsdatensätze? | Dateiverantwortung bestimmt Zugriff und Bedeutung in Order-Positionen. |
CS-Cart Product Codes sind Kennungen, aber nicht automatisch als eindeutig garantiert. Wenn der Quellshop auf eindeutige SKUs für ERP-, Lager- oder Marketplace-Abgleich angewiesen ist, muss diese externe Kennungsbeziehung explizit erhalten werden statt nur aus der Plattformbezeichnung abgeleitet zu werden.
Storefronts verändern Product-, Category-, Customer- und Konfigurationsumfang
Das Storefront-Verhalten von CS-Cart unterscheidet sich je nach Edition. In Store Builder Ultimate können Storefronts wie unabhängige Shops mit eigenen Products, Categories, Einstellungen, Benutzerbasen und Checkout-Mechanismen funktionieren. In Multi-Vendor Ultimate können Storefronts regionale Marketplace-Niederlassungen mit ausgewählten Vendors, Währungen, Sprachen, Zahlungs- und Versandmethoden, Themes, Layouts und Blocks darstellen.
Damit ist „Store“ keine universelle Source-to-Target-Einheit. Dasselbe Product kann einem Storefront gehören, über Category-Zuordnungen in mehreren Storefronts erscheinen oder in Marketplace-Niederlassungen der Sichtbarkeit seines Vendors folgen. Categories können einem Storefront gehören oder im Marketplace-Kontext einen breiteren Umfang haben. Customer Accounts und Administratoren können abhängig von der Konfiguration global oder Storefront-spezifisch sein.
| Quellkontext | Interpretation in Store Builder | Interpretation in Multi-Vendor |
|---|---|---|
| Marken- oder Regionalshop | Unabhängiger Storefront mit eigenem Katalog und eigenen Einstellungen | Marketplace-Niederlassung mit ausgewählten Vendors und regionaler Konfiguration. |
| Product-Verantwortung | Storefront-eigenes Product, das über zugewiesene Categories erscheinen kann | Vendor-eigenes Product, sichtbar dort, wo der Vendor teilnimmt. |
| Product-Preis | Kann sich je Storefront unterscheiden | Folgt normalerweise dem Vendor Product über Niederlassungen hinweg, sofern keine andere Preisstruktur gilt. |
| Category | Gehört zu einem bestimmten Storefront | Kann global oder einem bestimmten Storefront zugeordnet sein. |
| Customer-Basis | Kann je Storefront getrennt sein | Kann abhängig vom Marketplace-Design geteilt oder begrenzt sein. |
| Administrator | Storefront-spezifische administrative Beziehung | Marketplace-Administratoren und Vendor-Administratoren haben unterschiedliche Verantwortungsbereiche. |
Der Migrationsumfang muss deshalb klären, ob Unterschiede zwischen Quell-Storefronts Daten, Konfiguration oder eigenständige Betriebsbereiche darstellen. Locale-, Währungs-, Zahlungs-, Versand-, Theme- und Checkout-Einstellungen ersetzen keine Product- oder Category-Verantwortung. Ein Datensatz kann korrekt migriert sein und trotzdem im falschen Storefront erscheinen, wenn seine Umfangsbeziehung fehlt.
Vendors und Common Products ergänzen Marketplace-Verantwortung
CS-Cart Multi-Vendor führt den Vendor als kommerziellen Verantwortlichen ein, nicht bloß als Manufacturer-Bezeichnung. Vendors können Administratoren, Products, Storefront-Teilnahme, Order-Positionen, Versandmethoden, Plans, Provisionen, Salden, Auszahlungen und Profildaten besitzen. Ein Supplier-Feld aus dem Quellsystem sollte nur dann zu einem Vendor werden, wenn diese Organisation tatsächlich Marketplace-Aktivität verantwortet.
Manche Marketplace-Implementierungen verwenden außerdem Common Products oder Konzepte eines gemeinsamen Katalogs. Ein Common Product kann eine gemeinsame Katalogidentität bereitstellen, während Vendor-Angebote seller-spezifische kommerzielle Informationen tragen. Das unterscheidet sich sowohl vom Kopieren desselben Products in mehrere Vendor-Kataloge als auch von einem einzigen store-eigenen Product mit Supplier-Metadaten.
| Quellbeziehung | CS-Cart-Ziel im Marketplace | Zu erhaltende Bedeutung |
|---|---|---|
| Manufacturer oder Marke | Product Feature, manufacturerähnlicher Wert oder Brand Data | Beschreibende Herkunft ohne Seller-Verantwortung. |
| Supplier-Referenz | Internes Feld oder externe Kennung | Operative Beschaffung ohne Marketplace-Kontoverhalten. |
| Marketplace Seller | Vendor-Datensatz | Verantwortung für Products, Order-Positionen, Provisionen und Auszahlungen. |
| Seller Administrator | Vendor User oder administrative Beziehung | Zugriff gehört zum richtigen Vendor. |
| Gemeinsamer Katalogartikel mit Seller-Angeboten | Common Product plus vendor-spezifische Angebotsdaten, sofern verwendet | Gemeinsame Identität bleibt von Seller-Preis und -Bestand getrennt. |
| Marketplace Order | Parent Order plus vendorbezogene Order- oder Positionsbeziehung | Seller-Verantwortung und Abrechnung bleiben interpretierbar. |
Eine Vendor-Migration ist unvollständig, wenn Seller Products ohne Vendor-Verantwortung ankommen oder Vendor-Konten ohne ihre Products, Administratoren, Order-Kontext und externen Kennungen übertragen werden. Umgekehrt erzeugt die Umwandlung jedes Suppliers aus dem Quellsystem in einen Vendor Marketplace-Beziehungen, die vorher nicht existierten.
Customers, User Groups und kommerzielle Segmentierung
CS-Cart Users können Customers, Administratoren und Vendor Users umfassen. Customer Groups können Product-Preise, Rabatte, Steuerbehandlung, Zahlungsarten, Versandmethoden und Zugriff auf Products oder Categories beeinflussen. Profilfelder und Adressen enthalten zusätzliche Customer-Informationen, während externe Systeme Kontonummern, Kreditstatus oder Unternehmensbeziehungen verwalten können.
Eine Customer-Bezeichnung aus dem Quellsystem muss nach ihrer Funktion interpretiert werden. Wholesale-, VIP-, Dealer-, Staff-, tax-exempt-, Distributor- oder Subscription-Status sollten nur dann einer CS-Cart User Group zugeordnet werden, wenn die Gruppe tatsächlich die richtige Steuerungsinstanz für dieses Verhalten ist. Ein Company Account mit mehreren Käufern kann eine andere Struktur oder Plattform-Erweiterung erfordern. Ein CRM-Segment, das nur Marketingzwecken dient, sollte nicht automatisch zu einer Pricing Group werden.
| Customer-Bedeutung im Quellsystem | Zu prüfende CS-Cart-Struktur | Zentrale Beziehung |
|---|---|---|
| Einzelner Käufer | Customer User und Adressen | Identität, Login, Adressen und Orders bleiben verbunden. |
| Preisstufe | User Group und Product-Preisbeziehung | Customer-Mitgliedschaft beeinflusst die vorgesehenen kommerziellen Werte. |
| Zugriffssegment | User Group und Product-/Category-Beschränkung | Sichtbarkeit bleibt von beschreibender Kennzeichnung getrennt. |
| Vendor-Mitarbeiter | Vendor-User-Beziehung | Der User gehört zum richtigen Seller und nicht zur Customer-Population. |
| Externes Unternehmenskonto | Custom Profile Data, Plattform-Erweiterung oder externe Kennung | Käufer bleiben mit der maßgeblichen Organisation verbunden, wenn dies erforderlich ist. |
Order-Historie und Customer-Segmentierung sollten getrennt bleiben. Eine historische Order kann Preis und Steuer zum Zeitpunkt des Kaufs dokumentieren; sie sollte nach der Migration nicht anhand der aktuellen Customer Group neu berechnet werden.
Orders bewahren Marketplace- und kommerzielle Momentaufnahmen
Eine CS-Cart Order kann Customer- oder Guest-Identität, Adressen, Product- und Variation-Referenzen, Option-Auswahlen, Mengen, Preise, Rabatte, Steuern, Versand, Zahlungsbezeichnungen, Status, Notizen, Dateien, Promotions und Marketplace-Verantwortung enthalten. Im Multi-Vendor-Kontext kommen sellerbezogene Order-Strukturen und Provisionen hinzu.
Order-Positionen sind historische Momentaufnahmen. Der aktuelle Product-Name, Preis, Bestand, Feature-Werte oder Vendor einer Variation können sich später ändern. Die Order muss trotzdem erklären können, was der Customer gekauft hat. Ebenso sollten historische Zahlungs- und Versandbezeichnungen lesbar bleiben, obwohl die aktuellen Checkout-Methoden Konfiguration des Zielshops sind.
| Order-Element | Historische Beziehung, die erhalten bleiben muss |
|---|---|
| Product-Position | Product- oder Variation-Identität, Code, Menge, Preis und gewählte Options. |
| Promotion | Rabattbetrag und soweit verfügbar Quellregel- oder Coupon-Kontext. |
| Steuer | Angewendeter Steuerbetrag und Bezeichnung zum Kaufzeitpunkt. |
| Shipment | Carrier, Methode, Tracking, erfüllte Menge und soweit verfügbar Seller-Kontext. |
| Payment | Historische Methodenbezeichnung und soweit verfügbar Transaktionsreferenz. |
| Vendor-Kontext | Seller-Verantwortung, Provision, Auszahlung oder Vendor-Order-Beziehung. |
| Status | Bedeutung des Quell-Lebenszyklus für Service-, Fulfillment- und Reporting-Teams. |
Der Zielshop muss nicht jeden veralteten Workflow reproduzieren, um Historie zu bewahren, aber die importierte Order sollte verständlich bleiben. Ein Datensatz, der nur eine Gesamtsumme ohne Product-Konfiguration, Seller, Rabatt, Steuer und Statuskontext zeigt, entspricht nicht der kommerziellen Historie des Quellsystems.
Inhalte, Sprachen, URLs und Storefront-Darstellung
CS-Cart-Storefront-Inhalte können Pages, Blog-Datensätze sofern installiert, Product- und Category-Beschreibungen, Banner, Menüs, Blocks, Layouts, Themes, Metadaten, SEO Names und sprachspezifische Werte umfassen. Diese Assets haben unterschiedliche Verantwortliche und sollten nicht in einer generischen Content-Entität zusammengeführt werden.
Product- und Category-Beschreibungen gehören zum Katalog. Pages und Navigation besitzen eigene Hierarchie und Storefront-Umfang. Blocks und Layouts beschreiben Darstellung. SEO Names und Redirects steuern Routen. Sprachwerte können als Übersetzungen eines gemeinsamen Datensatzes gespeichert sein statt als unabhängige Products oder Categories.
| Quell-Asset | CS-Cart-Zielebene | Zu erhaltende Grenze |
|---|---|---|
| Product- oder Category-Übersetzung | Sprachspezifischer Katalogwert | Eine Entität bleibt mit mehreren lokalisierten Werten verbunden. |
| Informationsseite | Seitenhierarchie und Storefront-Zuordnung | Inhalt, Parent-Beziehung, Zugriff und Route bleiben getrennt. |
| Menü- oder Navigationseintrag | Menüstruktur oder Storefront Block | Navigation wird nicht allein aus vorhandenen Categories abgeleitet. |
| Banner oder Promotional Block | Darstellungs- oder Marketingdatensatz | Visuelle Platzierung bleibt vom zugrunde liegenden Product getrennt. |
| Legacy URL | SEO Name und Redirect-Beziehung | Quellpfad und Ziel bleiben explizit. |
| Theme Layout | Zielseitige Darstellungs-Konfiguration | Theme-Struktur darf nicht mit portablen Inhaltsdaten verwechselt werden. |
Diese Trennung ist in Multi-Store- und Marketplace-Umgebungen besonders relevant, weil derselbe Inhalt global, Storefront-spezifisch, Vendor-spezifisch oder sprachspezifisch sein kann.
CS-Cart-Erweiterungen, benutzerdefinierte Tabellen und Integrationen besitzen zusätzliche Daten
CS-Cart-Plattform-Erweiterungen können Product-Felder, Marketplace-Verhalten, Loyalty-Datensätze, Subscriptions, Bookings, Reviews, Reward Points, Zahlungs- oder Versanddaten, externe Feeds und Custom Workflows ergänzen. Ihre Datensätze können in erweiterungsspezifischen Tabellen liegen und von Hooks, Einstellungen, Scheduled Tasks oder externen Services abhängen.
In CS-Cart ist ein add-on eine Plattform-Erweiterung und keine generische Bezeichnung für gewöhnliche Product-Felder. Der Migrationsumfang sollte die Erweiterung, ihre Entitäten und die Kerndatensätze identifizieren, die sie erweitert.
| Datenverantwortlicher | Typische Datensätze | Übertragungsanforderung |
|---|---|---|
| CS-Cart Core | Products, Categories, Features, Options, Variations, Users, Orders, Storefronts | Native Entitäts- und Beziehungssemantik erhalten. |
| Multi-Vendor-Ebene | Vendors, Vendor Users, seller-eigene Products, Provisionen, Auszahlungen | Seller-Verantwortung über Katalog und Orders hinweg verbunden halten. |
| CS-Cart-Plattform-Erweiterung | Reviews, Rewards, Subscriptions, Booking Data, besondere Product-Felder | Erweiterungsschema und Zielfunktion getrennt prüfen. |
| individuelle Entwicklung | Individuelle Tabellen, Felder, Status oder Workflow-Datensätze | Für jede aktive Geschäftsbeziehung ein explizites Ziel definieren. |
| Externes System | ERP-Artikel, CRM-Konto, Lager, Marketplace-Listing, Accounting-Referenz | Kennungen erhalten, die für Abstimmung und Wiederanbindung erforderlich sind. |
Import- und Exportformate definieren nicht das vollständige Datenmodell. Ein Feld kann exportierbar sein, ohne die zugehörige Erweiterungskonfiguration oder den Workflow mitzunehmen. Umgekehrt kann eine externe Kennung nur wenig Datenvolumen erzeugen, aber entscheidend sein, um den migrierten Datensatz wieder mit ERP-, PIM-, WMS-, CRM- oder Marketplace-Daten zu verbinden.
CS-Cart-Übertragungsentscheidungen nach Beziehung
Eine belastbare CS-Cart-Zuordnung klärt zuerst den Verantwortlichen jedes Quellwerts und entscheidet erst danach über das Zielfeld.
| Quellmuster | Übertragungsfrage | Folge einer falschen Zuständigkeit |
|---|---|---|
| Farbe und Größe mit untergeordneten SKUs | Handelt es sich um eine auf Features basierende Variation Group? | Eigenständige Product-Identität, Bestand oder Katalogsichtbarkeit geht verloren. |
| Gravur oder Geschenkverpackung | Ist dies eine Option ohne eigenen Bestand? | Eine Service-Auswahl wird fälschlich als verkaufbare Variation dargestellt. |
| Technische Spezifikation | Ist dies ein Feature und gegebenenfalls ein Filter? | Discovery und Vergleich werden inkonsistent. |
| Mehrere regionale Stores | Sind es unabhängige Storefronts oder Marketplace-Niederlassungen? | Product-, Category-, Customer- und Konfigurationsumfang werden vermischt. |
| Supplier oder Seller | Handelt es sich um beschreibende Beschaffung oder Vendor-Verantwortung? | Vendor Products, Users, Orders, Provisionen und Auszahlungen gehen entweder verloren oder werden erfunden. |
| Customer Tier | Ist es eine User Group, ein externes CRM-Segment oder eine Company-Beziehung? | Preis- und Zugriffsverhalten werden an die falsche Customer-Struktur gebunden. |
| Extension Field | Welches CS-Cart-Modul verantwortet es und welchen Datensatz erweitert es? | Daten werden kopiert, ohne die Funktion zu erhalten, die sie interpretiert. |
Eine CS-Cart-Migration bewahrt Bedeutung, wenn Katalogfakten, Kaufentscheidungen, Variations, Storefront-Umfang, Vendor-Verantwortung, Customer-Segmentierung, Order-Historie, Inhalte und Erweiterungsdatensätze getrennt, aber miteinander verbunden bleiben.
Fazit
CS-Cart ist kein flaches Product-und-Order-Schema. Features beschreiben Products; Options bilden getrennte Auswahlmöglichkeiten ab; Variations bleiben Products, die über ausgewählte Features gruppiert sind. Storefronts können Katalog- und Customer-Umfang in Store Builder und Multi-Vendor unterschiedlich verantworten. Vendors führen Marketplace-Verantwortung ein, während User Groups die kommerzielle Behandlung beeinflussen. Orders hängen von historischen Positions-, Promotion-, Steuer-, Payment-, Shipment-, Status- und Seller-Kontexten ab. Plattform-Erweiterungen und externe Systeme können Datensätze außerhalb der Kern-Datenkategorien besitzen.
Der stärkste Migrationsumfang weist jeden Quellwert der CS-Cart-Struktur zu, die dieselbe geschäftliche Bedeutung steuert. So bleiben Product Discovery, Kaufentscheidungen, Seller-Verantwortung, Customer-Behandlung, historische Orders, lokalisierte Storefronts und Integrationskontinuität erhalten, ohne unähnliche Datensätze in oberflächlich ähnliche Felder zu pressen.
Häufige Fragen
Was ist der Unterschied zwischen einem CS-Cart Feature und einer Option?
Ein Feature ist eine untrennbare Product-Eigenschaft wie Marke, Material oder ISBN und kann Filterung oder Vergleich unterstützen. Eine Option ist eine getrennte Käuferauswahl wie Gravur, Geschenkverpackung oder Garantie; sie kann Preis oder Gewicht beeinflussen, besitzt aber keinen eigenen Bestand.
Wann sollten untergeordnete SKUs aus dem Quellsystem zu CS-Cart Product Variations werden?
Sie passen zu Product Variations, wenn jedes Kind ein Product bleibt und sich die Gruppe über ausgewählte Feature-Werte unterscheidet. Die Zuordnung sollte Child-SKU, Bestand, Preis, Bild und Katalogsichtbarkeit erhalten, statt alle Kinder in einer flachen Option-Liste zusammenzuführen.
Kann ein Quellshop immer einem CS-Cart-Storefront entsprechen?
Nein. In Store Builder kann ein Storefront ein unabhängiger Shop mit eigenem Katalog und eigenen Customers sein. In Multi-Vendor kann ein Storefront eine regionale Marketplace-Niederlassung mit ausgewählten Vendors und regionaler Konfiguration darstellen. Die Betriebsgrenze im Quellsystem bestimmt das richtige Modell.
Sollte jeder Supplier aus dem Quellsystem zu einem CS-Cart Vendor werden?
Nein. Ein Vendor besitzt Marketplace Products und sellerbezogene kommerzielle Datensätze. Manufacturer, Brand, Supplier Code oder Beschaffungsquelle können beschreibende oder externe Systemdaten bleiben, wenn sie kein Seller-Konto darstellen.
Warum müssen Daten aus CS-Cart-Plattform-Erweiterungen von Core-Daten getrennt werden?
Eine Plattform-Erweiterung kann eigene Tabellen, Status, Konfiguration und Beziehungen besitzen. Das Kopieren ihrer Felder in einen Core-Product- oder Customer-Datensatz erhält nicht den Workflow, der diese Felder interpretiert.
Wie sollten gemeinsame Marketplace-Katalogdatensätze übertragen werden?
Trennen Sie die gemeinsame Product-Identität von vendor-spezifischen Angeboten, Preisen, Beständen, Verantwortlichkeiten und Order-Zuständigkeiten. Unabhängig davon, ob der Zielshop Common Products oder eine andere Marketplace-Struktur verwendet, dürfen diese Ebenen nicht zu unverbundenen doppelten Products zusammenfallen.