Bei der Bewertung von Gambio als möglicher Zielplattform ist zu berücksichtigen: Gambio verbindet einen umfangreichen Commerce-Katalog mit kundengruppenspezifischer Preisgestaltung, Inhaltsverwaltung, mehrsprachigen Feldern, Modulen und zwei Betriebsumgebungen: Gambio Cloud und selbst gehostetem Gambio. Viele Datensätze wirken auf den ersten Blick vertraut, ihre Beziehungen sind jedoch plattformspezifisch. Ein Artikel kann mehreren Categories zugeordnet sein, unterschiedliche Product-Typen verwenden, zusätzliche Felder und Tabs enthalten, seine Sichtbarkeit nach Kundengruppe einschränken und gruppen- oder mengenabhängige Preise erhalten. Käuferauswahlen können außerdem aus verschiedenen Generationen der Gambio-Kataloglogik stammen, darunter ältere Artikelattribute und Artikeleigenschaften sowie aktuelle Optionen, Product Options und Product Variants.
Diese Unterschiede machen eine rein feldweise Übertragung unzuverlässig. Ein Farbwert aus der Quelle kann eine beschreibende Angabe, ein Legacy-Attribut, ein Optionswert oder Bestandteil einer eigenständig identifizierbaren Variante sein. Eine Customer-Stufe kann Sichtbarkeit, Preis, steuerliche Behandlung, Mindestmenge oder mehrere dieser Beziehungen steuern. Ein Inhaltsdatensatz kann dem Content Manager, einem Artikel-Tab, einer Category, einem Theme-Block oder einem Modul gehören. Das Migrationsmodell muss deshalb für jeden Wert den zuständigen Gambio-Bereich identifizieren und die Beziehungen bewahren, die ihm seine geschäftliche Bedeutung geben.
Die Bedeutung von Gambio-Datensätzen hängt von Kataloggeneration und Betriebsumgebung ab
Gambio besitzt eine aktive aktuelle Plattformlinie, doch langjährig betriebene Shops können Daten aus älteren Katalogstrukturen, Drittanbieter-Modulen oder individuellen Datenbankänderungen enthalten. Quellversion und installierte Komponenten beeinflussen, ob eine Auswahl als älteres Artikelattribut oder als Eigenschaft, aktuelle Option, Product Option, Product Variant oder als individueller Moduldatensatz gespeichert ist.
Cloud und Self-Hosting basieren beide auf Gambio, schaffen bei technischen Datensätzen aber unterschiedliche Eigentumsgrenzen. Cloud-Shops stützen sich in der Regel stärker auf plattformseitig verwaltetes Hosting und Updates. Selbst gehostete Shops können lokale Dateien, GXModules, Themes, Datenbankerweiterungen oder direkte Anpassungen enthalten, für die es in einer sauberen Zielinstallation keine Entsprechung gibt. Diese Unterscheidung ändert nicht die Bedeutung nativer Products, Customers oder Orders, wohl aber die Sicherheit, mit der erweiterungseigene Felder als übertragbare Gambio-Daten eingestuft werden können.
| Nachweis in der Quelle | Interpretation in Gambio | Konsequenz für die Beziehung |
|---|---|---|
| Aktuelle Product-Option- und Product-Variant-Datensätze | Aktuelles Modell für Käuferauswahl und verkaufsfähige Kombinationen | Optionsdefinitionen, ausgewählte Werte, Variantenidentität und kommerzielle Werte gemeinsam bewahren. |
| Ältere Artikelattribute oder Artikeleigenschaften | Struktur aus einer früheren Kataloggeneration | Nach Quellversion interpretieren, statt sie gewaltsam in aktuelle Terminologie zu überführen. |
| GXModule oder Drittanbieter-Tabelle | Moduleigener Datensatz oder Erweiterung eines Kerndatensatzes | Modul und den zugehörigen Product-, Customer-, Order- oder Inhaltsdatensatz identifizieren. |
| Datensatz aus einem Cloud-Shop | Native Gambio-Daten im Kontext einer plattformverwalteten Umgebung | Commerce-Daten von der plattformverwalteten technischen Konfiguration trennen. |
| Benutzerdefiniertes Feld oder Tabelle im Self-Hosting | Lokale Erweiterung, verändertes Schema oder Integrationsdatensatz | Ziel erst festlegen, wenn Eigentümer und konsumierender Ablauf bekannt sind. |
| Externe Kennung | Schlüssel aus ERP, PIM, WMS, Marketplace, Buchhaltung oder Auftragsabwicklung | Stabilen Schlüssel erhalten, der für die erneute Verbindung des Zielshops benötigt wird. |
Version und Umgebung sind damit Merkmale der Datenherkunft. Sie erklären, warum zwei Gambio-Shops dieselbe Bezeichnung anzeigen können, obwohl der Wert anders gespeichert oder verwendet wird.
Products, Artikeltypen, Categories und Katalogfelder sind voneinander zu unterscheiden
Gambio verwendet für einen verkaufsfähigen Product häufig den Begriff Artikel. Ein Product kann Artikelnummer, Bestand, Gewicht, Manufacturer, Steuerklasse, Lieferstatus, Barcode oder EAN, Verpackungseinheit, Mengeneinheit, Mindestbestellmenge, Mengenschritte, Bilder, mehrsprachige Beschreibungen, Metadaten und Category-Verknüpfungen enthalten. Der Product-Typ kann außerdem Standardartikel, Download-Artikel und Service unterscheiden.
Categories sind eigenständige Datensätze, und ein Product kann mehreren Categories zugeordnet sein. Diese Beziehung ist besonders wichtig, wenn ein Quellshop Products für mehrere Platzierungen dupliziert oder Categories zugleich Merchandising-, SEO- oder Navigationsfunktionen übernehmen. Im Ziel kann ein einziger Product mit mehreren Category-Zuordnungen richtiger sein als mehrere Products mit identischem Inhalt.
Gambio unterstützt außerdem zusätzliche Product-Felder, Product-Tabs, Filter, Google-Taxonomie-Zuordnungen, Manufacturers, verknüpfte Inhalte und Merchandising-Markierungen. Solche Werte sollten nicht nur deshalb in eine Beschreibung verdichtet werden, weil sie auf derselben Product-Seite sichtbar sind.
| Quellmuster | Zu prüfender Gambio-Eigentümer | Zu bewahrende Bedeutung |
|---|---|---|
| Physisch verkaufsfähiger Artikel | Standard-Product-Datensatz | Identität, Preis, Steuer, Bestand, Gewicht, Bilder und Category-Zuordnungen. |
| Digitale Datei | Download-Product plus Order-Zugriffsbeziehung | Dateiidentität, Zugriffsbedingungen und historischer Kaufkontext. |
| Dienstleistung oder nicht zu versendender Artikel | Service-Product-Typ | Verkaufsfähige Identität, ohne physische Auftragsabwicklungsdaten zu erfinden. |
| Product in mehreren Navigationszweigen | Ein Product mit mehreren Category-Zuordnungen | Gemeinsame Identität bei mehreren Auffindbarkeitspfaden. |
| Technische Spezifikation | Zusätzliches Feld, Filterwert oder strukturierter Inhalt | Beschreibende Bedeutung bleibt von einer Käuferauswahl getrennt. |
| Ausführlichere Product-Erklärung | Product-Tab oder Inhaltsbeziehung | Inhalt bleibt mit richtigem Product und richtiger Sprache verbunden. |
| Lieferanten- oder Markenidentität | Manufacturer oder Beziehung zu externen Stammdaten | Markenbedeutung und externer Schlüssel bleiben konsistent. |
Die zentrale Übertragungsregel lautet, die Product-Identität einmal zu bewahren und anschließend ihre Beziehungen wiederherzustellen. Ein Product für jeden Navigationspfad zu duplizieren erzeugt Inkonsistenzen bei Bestand, SEO und Order-Historie.
Optionen, Product Options, Varianten, Attribute und Eigenschaften dürfen nicht zusammengelegt werden
Das Modell für Käuferauswahlen hat sich in Gambio weiterentwickelt. Aktuelle Entwicklerressourcen unterscheiden Optionen, Product Options und Product Variants; ältere Shops können weiterhin Artikelattribute oder Artikeleigenschaften nutzen. Für Käufer können diese Strukturen ähnlich aussehen, auf Datenebene sind sie jedoch nicht austauschbar.
Eine Option definiert einen Auswahlbereich wie Größe oder Farbe. Eine Product Option verbindet diese Option mit einem Product. Eine Product Variant stellt eine konkrete Kombination aus Product Options dar und kann eigene kommerzielle Werte besitzen. Ältere Attribute oder Eigenschaften können vergleichbare Informationen über andere Tabellen und Regeln speichern. Quelldaten müssen daher nach Verhalten und Herkunft klassifiziert werden, nicht nur nach ihrer sichtbaren Bezeichnung.
| Verhalten in der Quelle | Frage für die Gambio-Interpretation | Beziehung, die erhalten bleiben muss |
|---|---|---|
| Auswahl ändert nur den angezeigten Wert | Option oder Product Option ohne eigenständige kommerzielle Identität | Product-Option-Verknüpfung und ausgewählter Wert. |
| Kombination besitzt eigene SKU, eigenen Bestand, Preis, Gewicht, Bild oder eigene Verfügbarkeit | Product Variant | Übergeordneter Product, ausgewählte Optionswerte, Variantenidentität und kommerzielle Werte. |
| Käufer gibt Text oder Personalisierung ein | GX-Customizer oder moduleigene Eingabe | Eingabewert bleibt mit der betreffenden Order-Position verbunden. |
| Wert beschreibt den Product | Zusätzliches Feld, Filter, Eigenschaft oder Inhalt | Beschreibender Wert bleibt von der gekauften Kombination getrennt. |
| Legacy-Shop nutzt Artikelattribute | Ältere Attributstruktur | Attributname, Wert, Preiseffekt, Bestandsverhalten und Quellherkunft. |
| Legacy-Shop nutzt Artikeleigenschaften | Ältere Eigenschafts- oder Kombinationsstruktur | Eigenschaftsgruppen, Werte, Kombinationen und Product-Beziehungen. |
Eine einfache Größenauswahl kann sich sauber abbilden lassen. Eine Kombinationsmatrix mit getrennten Beständen und Bildern benötigt Variantenidentität. Ein Personalisierungsfeld gehört zur gekauften Order-Position und nicht zu einer wiederverwendbaren Variante. Werden alle drei Fälle als gewöhnliche Optionen behandelt, kann der Katalog optisch korrekt wirken, während Auftragsabwicklung und historische Bedeutung verloren gehen.
Bestand, Preise, Kundengruppen und Mengenregeln bilden eine kommerzielle Ebene
Gambio-Product-Daten können mit Bestandssteuerung, Mindestbestellmengen, Mengenschritten, Sichtbarkeit nach Kundengruppe, gruppenspezifischen Preisen, Staffelpreisen, Rabatten, Steuerklassen, Sonderangeboten und weiteren Geschäftsregeln verbunden sein. Diese Beziehungen bestimmen, wer einen Artikel sehen kann, welchen Preis die Person erhält und welche Menge gekauft werden darf.
Eine Kundengruppe ist nicht nur eine Segmentbezeichnung. In Gambio kann sie die Sichtbarkeit von Products und deren Preise steuern. Eine Großhandelsstufe aus dem Quellsystem kann daher eine echte Customer-Group-Beziehung erfordern, während ein Marketingsegment an anderer Stelle zu verorten ist. Historische Orders müssen den zum Kaufzeitpunkt aufgezeichneten Preis, Rabatt, Steuer- und Mengennachweis bewahren, statt nachträglich aus der aktuellen Kundengruppe neu interpretiert zu werden.
| Bedeutung in der Quelle | Gambio-Beziehung | Abgrenzung bei der Übertragung |
|---|---|---|
| Product nur für freigegebene Käufer sichtbar | Product-zu-Customer-Group-Sichtbarkeit | Zugriffsbeziehung bewahren, nicht nur den Gruppennamen. |
| Großhandels- oder Händlerpreis | Customer-Group-Product-Preis | Product, Gruppe, Währung und Preis miteinander verbunden halten. |
| Mengenstaffel | Staffelpreis oder mengenabhängige Regel | Schwellenwerte und die berechtigte Kundengruppe erhalten. |
| Mindestabnahmemenge | Mindestbestellwert bzw. Mindestbestellmenge des Products | Geschäftsregel vom Lagerbestand trennen. |
| Bestand je verkaufsfähiger Kombination | Variantenbestand, sofern entsprechend abgebildet | Nicht die gesamte Menge dem übergeordneten Product zuweisen. |
| Aktueller Aktionspreis | Aktive Preisbeziehung | Vom historischen Preis auf älteren Orders getrennt halten. |
Gerade auf dieser Ebene werden scheinbar kleine Felder betrieblich relevant. Ein kopierter Preis ohne seine Gruppenbeziehung ist nicht derselbe Preis. Ein kopierter Bestandswert ohne Variantenidentität ist nicht derselbe Bestandsdatensatz.
Customers, Adressen, Gruppen und Orders liefern unterschiedliche Arten von Nachweisen
Gambio-Customer-Daten können Kontoidentität, Adressen, Kundengruppenzugehörigkeit, Händler- oder Wiederverkäuferkontext, Notizen, Kommunikationspräferenzen, Reviews und administrative Beziehungen enthalten. Diese Datensätze müssen nach ihrem Zweck getrennt bleiben. Ein Adressbucheintrag ist nicht dasselbe wie die in einer Order gespeicherte Adresse zum Bestellzeitpunkt. Eine Gruppenzuordnung ist nicht dasselbe wie ein historischer Rabatt. Ein Administratorkonto ist kein Customer-Konto.
Orders enthalten historische kommerzielle Nachweise: Customer- oder Gastidentität, Rechnungs- und Lieferadressen, Product- und Variantenreferenzen, ausgewählte Optionen, Mengen, Preise, Rabatte, Steuern, Versand, Zahlungsbezeichnungen, Order-Status, Kommentare, Rechnungen, Lieferdokumente, Widerrufe und weitere zugehörige Datensätze. Eine migrierte Order muss nachvollziehbar bleiben, auch wenn der Zielshop für den Live-Betrieb andere Zahlungs-, Versand-, Steuer- oder Statuskonfigurationen verwendet.
| Historisches Element | Eigentümer in Gambio | Zu bewahrende Bedeutung |
|---|---|---|
| Registrierter Käufer | Customer-Konto | Identität sowie Beziehung zu Orders und Adressen. |
| Gast beim Checkout | Identitäts-Snapshot auf Order-Ebene | Historischer Käuferkontext, ohne ein Konto zu erfinden. |
| Gespeicherte Adresse | Customer-Adressbuch | Wiederverwendbare Adressbeziehung des Customers. |
| Rechnungs- oder Lieferadresse einer Order | Snapshot zum Bestellzeitpunkt | Nachweis der Transaktion in der damals erfassten Form. |
| Product-Auswahl auf einer Order-Position | Product-/Variantenbezeichnung und ausgewählte Werte | Exakt gekaufter Artikel, auch wenn sich der Katalog später ändert. |
| Zahlungs- und Versandbezeichnungen | Order-Historie | Historischer Methodennachweis, nicht aktuelle Methodenkonfiguration. |
| Erstattungs-, Widerrufs- oder Statushistorie | Zugehörige Order-Datensätze | Kontext nach dem Verkauf bleibt nachvollziehbar. |
Das robusteste Modell hält Customer-Stammdaten und Order-Snapshots getrennt. Wird eine Customer-Adresse nach der Migration geändert, darf dadurch die auf einer älteren Order gespeicherte Adresse nicht überschrieben werden.
Content Manager, Product-Inhalte, URLs und Themes haben getrennte Eigentümer
Gambio-Inhalte können im Content Manager, in Product-Beschreibungen, Product-Tabs, Category-Beschreibungen, Bannern, Teaser-Slidern, Menüs, Rechtstexten, Fehlerseiten, Theme-Blöcken, Sprachdateien oder Modulen liegen. Jede dieser Strukturen besitzt eine eigene Zuständigkeit und Beziehung zu Routen.
CMS Pages sollten ihre eigene Identität, Sprache, Inhalte, Sichtbarkeit, Menüplatzierung und URL-Beziehung behalten. Product-Tabs bleiben mit Products verbunden. Category-Beschreibungen gehören weiterhin zu Categories. Ein Theme-Block oder eine StyleEdit-Konfiguration steuert Präsentation und darf nicht als portable CMS Page missverstanden werden. Rechtliche und Richtlinieninhalte können eine aktuelle fachliche Prüfung benötigen; ihre Datensatzidentität und Platzierung können dennoch als Inhaltsdaten erhalten werden.
Gambio-Products und Categories können außerdem URL-Keywords, URL-Rewrites, Metadaten, Suchbegriffe und mehrsprachige Werte tragen. Diese Beziehungen beeinflussen die Auffindbarkeit, machen Navigation, Inhalte und SEO jedoch nicht zu demselben Objekt.
| Sichtbares Storefront-Element | Wahrscheinlicher Eigentümer in Gambio | Konsequenz für das Datenmodell |
|---|---|---|
| Informations- oder Richtlinienseite | Eintrag im Content Manager | Inhalt, Sprache, Route und Platzierung bewahren. |
| Zusätzliche Product-Erklärung | Product-Tab oder Product-Inhalt | Am Product belassen, statt eine generische Seite zu erzeugen. |
| Landingtext einer Category | Category-Datensatz | Mit Category-Identität und Route verbunden halten. |
| Homepage-Banner oder Teaser | Banner-/Teaser-Konfiguration | Inhaltsasset und Platzierung getrennt behandeln. |
| Menüeintrag | Navigationskonfiguration | Eine migrierte Seite oder Category stellt ihre Menüplatzierung nicht automatisch wieder her. |
| Theme-Block oder Template-Override | Theme- oder Modulpräsentation | Darstellung neu aufbauen, ohne Code als Inhalt einzuordnen. |
| Alte Product- oder Category-URL | Entity-URL- und Redirect-Beziehung | Beziehung vom Quellpfad zum Zielpfad bewahren. |
Eine saubere Migration kann Inhalte erhalten und trotzdem die Präsentation verändern. Entscheidend ist, dass jeder Datensatz beim richtigen Gambio-Eigentümer landet und mit seiner Route und Sprache verbunden bleibt.
Module, GXModules, APIs und externe Systeme erweitern das native Modell
Gambio unterstützt Module, GXModules, Themes, REST APIs, Importe und Exporte sowie Integrationen mit Marktplätzen, Buchhaltung, Auftragsabwicklung, Suche und weiteren Systemen. Diese Komponenten können Felder, Tabellen, Status, Kennungen und Prozessdatensätze erzeugen, die nicht zum nativen Product-, Customer- oder Order-Modell gehören.
Dass ein Wert in der Datenbank vorhanden ist, macht ihn nicht zu einem Gambio-Kernfeld. Ein Modul kann eine Marketplace-Listing-ID, einen Lieferantencode, eine Zahlungsreferenz, einen Product-Feed-Status, eine benutzerdefinierte Customer-Eigenschaft oder ein Kennzeichen für die Order-Bearbeitung speichern. Seine Bedeutung hängt davon ab, welches Modul oder externe System den Wert nutzt.
| Dateneigentümer | Beispieldatensätze | Entscheidung für die Übertragung |
|---|---|---|
| Gambio-Kern | Products, Categories, Customers, Orders, Inhalte, Optionen, Varianten | Über native Datenbeziehungen abbilden. |
| Gambio-Modul oder GXModule | Modulfelder, Tabellen, Status, konfigurationsgebundene Datensätze | Nur mit identifiziertem Zieleigentümer und zugehörigem Kernschlüssel bewahren. |
| Theme oder StyleEdit | Layout, Blöcke, Templates, visuelle Einstellungen | Als Zielpräsentation statt als Commerce-Stammdaten behandeln. |
| Externes ERP/PIM/WMS | Stammdatenkennungen, Bestand, Lieferanten, Preise oder Auftragsabwicklungsdaten | Dauerhafte systemübergreifende Schlüssel und Datenhoheit bewahren. |
| Marketplace oder Kanal | Listing-IDs, Angebotsstatus, Kanalkategorien, Synchronisationsmetadaten | Vom kanonischen Product getrennt halten, sofern der Zielprozess sie nicht weiterhin verwendet. |
| Individueller Code | Eigene Tabellen oder veränderte Kernfelder | Explizite Dateneigentümerschaft definieren, statt native Unterstützung anzunehmen. |
Cloud- und Self-Hosting-Shops können unterschiedliche technische Nachweise liefern, doch dieselbe Regel gilt: Aktive erweiterungseigene Daten brauchen einen zukünftigen Eigentümer. Veraltete technische Artefakte werden nicht allein dadurch wertvoll, dass sie in der Quelldatenbank vorhanden sind.
Gambio-Übertragungsentscheidungen nach geschäftlicher Bedeutung
| Quellmuster | Richtige Frage für Gambio | Folge einer falschen Annahme |
|---|---|---|
| Parent-Product mit untergeordneten Kombinationen | Ist der Quellwert eine Option, Product Option, aktuelle Variante oder Legacy-Attribut-/Eigenschaftskombination? | Untergeordnete SKU, Bestand, Preis, Bild oder ausgewählte Werte gehen verloren oder werden dupliziert. |
| Product nur für Großhändler sichtbar | Steuert die Customer-Group-Sichtbarkeit die Einschränkung? | Das Product wird öffentlich oder für die vorgesehenen Käufer unzugänglich. |
| Staffel- oder Mengenpreis | Welcher Product, welche Gruppe, welcher Schwellenwert und welche Währung definieren den Preis? | Käufer erhalten trotz vorhandenem Zahlenwert den falschen Preis. |
| Inhalt auf einer Product-Seite | Ist es ein Product-Tab, zusätzliches Feld, Modulblock oder eine CMS Page? | Inhalt wird ohne die Beziehung übertragen, durch die er angezeigt wird. |
| Historischer Order-Status | Welcher Order-Verlauf, Zahlungs-, Auftragsabwicklungs- oder Widerrufsdatensatz erklärt den Status? | Mitarbeitende können die frühere Transaktion nicht zuverlässig interpretieren. |
| Modul-erzeugtes Feld | Welches Modul oder externe System besitzt und aktualisiert den Wert? | Verwaiste Daten werden in ein Feld kopiert, das kein Prozess mehr pflegt. |
| Legacy-URL | Welcher Product-, Category- oder Inhaltsdatensatz soll den Redirect erhalten? | Suche und interne Links verlieren Kontinuität, obwohl die Datensätze übertragen wurden. |
Eine Gambio-Migration bewahrt Bedeutung, wenn Product-Herkunft, Käuferauswahlen, kommerzielle Customer-Group-Beziehungen, historische Order-Nachweise, Inhaltseigentum und Erweiterungsdatensätze als verbundene, aber getrennte Domänen behandelt werden.
Fazit
Die Übertragung des Gambio-Datenmodells wird durch Kataloggeneration, Product-Typen, Category-Verknüpfungen, aktuelle und ältere Optionsstrukturen, Preis- und Sichtbarkeitsregeln für Kundengruppen, historische Orders, Content-Manager-Datensätze, Module, APIs sowie Cloud- oder Self-Hosting-Umgebung bestimmt. Ein Quellfeld ist nur dann sinnvoll übertragen, wenn der Zielshop sowohl die zuständige Entität als auch die Beziehungen erhält, die dem Wert Bedeutung geben.
Das robusteste Zielmodell unterscheidet Products von Varianten, beschreibende Felder von Käuferauswahlen, Customer-Stammdaten von Order-Snapshots, Inhalte von Präsentation und Gambio-Kerndaten von Modul- oder externen Systemdaten. Diese klare Eigentumslogik sorgt dafür, dass Katalog und Handelshistorie nachvollziehbar bleiben und nicht lediglich befüllt sind.
Häufige Fragen
Was unterscheidet Gambio-Optionen von Product Variants?
Optionen definieren Auswahlbereiche, und Product Options verbinden diese Auswahlen mit einem Product. Product Variants stellen konkrete Kombinationen dar und können kombinationsspezifische kommerzielle Werte tragen. Ältere Shops können stattdessen Artikelattribute oder Eigenschaften verwenden; deshalb sind Quellversion und Tabellenbeziehungen relevant.
Sollte jede Product-Kombination der Quelle zu einer Gambio Product Variant werden?
Nein. Eine Kombination passt dann zu einer Variante, wenn sie eine eigene Identität oder kommerzielle Werte wie SKU, Bestand, Preis, Gewicht, Bild oder Verfügbarkeit besitzt. Personalisierung und beschreibende Spezifikationen gehören in der Regel in andere Strukturen.
Wie wirken sich Gambio-Kundengruppen auf die Datenmigration aus?
Kundengruppen können Product-Sichtbarkeit, gruppenspezifische Preise, Staffelpreise, steuerliche Behandlung oder anderes kommerzielles Verhalten steuern. Nur den Gruppennamen zu erhalten bewahrt diese Product- und Preisbeziehungen nicht.
Kann ein Gambio Product mehreren Categories zugeordnet sein?
Ja. Gambio kann einen Product mit mehreren Categories verknüpfen. Ein Quellshop, der Products aus Navigationsgründen dupliziert, lässt sich im Ziel möglicherweise besser mit einer Product-Identität und mehreren Category-Zuordnungen abbilden.
Sind Einträge im Gambio Content Manager dasselbe wie Product-Tabs oder Theme-Blöcke?
Nein. Content-Manager-Einträge sind eigenständige Inhaltsdatensätze. Product-Tabs gehören zu Products, während Theme-Blöcke und StyleEdit-Einstellungen zur Präsentation gehören. Jeder Bereich benötigt einen eigenen Zieleigentümer.
Was sollte mit Daten geschehen, die durch Gambio-Module oder externe Integrationen entstanden sind?
Das Modul oder externe System, der erweiterte Kerndatensatz und die stabile Verknüpfungskennung müssen identifiziert werden. Aktive Beziehungen benötigen im Zielshop einen expliziten Bestimmungsort. Veraltete technische Datensätze können ausgeschlossen oder archiviert werden, ohne sie als native Gambio-Daten zu behandeln.