Gambio combine un catalogue e-commerce étendu avec une tarification par groupes Customer, la gestion de contenu, des champs multilingues, des modules et deux environnements d’exploitation : Gambio Cloud et Gambio auto-hébergé. Les enregistrements visibles peuvent sembler familiers, mais leurs relations sont propres à la plateforme. Un article peut être lié à plusieurs Categories, utiliser différents types de Product, contenir des champs et onglets supplémentaires, restreindre sa visibilité selon un groupe Customer et recevoir une tarification par groupe ou par quantité. Les choix proposés à l’acheteur peuvent également provenir de plusieurs générations de logique de catalogue Gambio, notamment les anciens attributs d’article, les propriétés d’article, les options actuelles, Product Options et Product Variants.
Ces distinctions rendent peu fiable un transfert champ par champ. Une valeur source « couleur » peut être une information descriptive, un ancien attribut, une valeur d’option ou une partie d’une variante disposant d’une identité propre. Un niveau Customer source peut contrôler la visibilité, le prix, le traitement fiscal, une quantité minimale ou plusieurs de ces relations. Un contenu peut appartenir au Content Manager, à un onglet Product, à une Category, à un bloc de thème ou à un module. Le modèle de migration doit donc identifier le propriétaire Gambio de chaque valeur et préserver les enregistrements liés qui lui donnent son sens commercial.
Le sens des enregistrements Gambio dépend de la génération du catalogue et de l’environnement
Gambio dispose d’une gamme de plateforme actuelle active, mais les boutiques exploitées depuis longtemps peuvent contenir des données créées avec d’anciennes structures de catalogue, des modules tiers ou des modifications personnalisées de la base de données. La version source et les composants installés influencent le fait qu’un choix soit stocké comme ancien attribut ou propriété d’article, option actuelle, Product Option, Product Variant ou enregistrement d’un module personnalisé.
Les environnements Cloud et auto-hébergés utilisent la plateforme Gambio, mais créent des frontières de responsabilité différentes autour des enregistrements techniques. Les boutiques Cloud s’appuient généralement davantage sur l’hébergement et les mises à jour gérés par la plateforme. Les boutiques auto-hébergées peuvent contenir des fichiers locaux, GXModules, thèmes, ajouts de base de données ou modifications directes sans équivalent dans une installation cible propre. Cette distinction ne doit pas modifier le sens des Products, Customers ou Orders natifs, mais elle change le niveau de confiance avec lequel les champs détenus par des extensions peuvent être classés comme données Gambio portables.
| Élément source | Interprétation Gambio | Conséquence sur la relation |
|---|---|---|
| Enregistrements Product Option et Product Variant actuels | Modèle actuel de choix acheteur et de combinaison vendable | Préserver ensemble définition d’option, valeurs sélectionnées, identité de variante et valeurs commerciales. |
| Anciens attributs ou propriétés d’article | Structure d’une génération antérieure du catalogue | Interpréter selon la version source plutôt que de forcer les données dans la terminologie actuelle. |
| GXModule ou table tierce | Entité détenue par un module ou extension d’un enregistrement principal | Identifier le module et le Product, Customer, Order ou contenu qu’il étend. |
| Enregistrement d’une boutique Cloud | Donnée Gambio native dans le contexte d’un environnement géré par la plateforme | Séparer les données e-commerce de la configuration technique gérée. |
| Champ ou table personnalisée auto-hébergée | Extension locale, schéma modifié ou enregistrement d’intégration | N’attribuer une destination qu’après identification du propriétaire et du processus qui consomme la donnée. |
| Identifiant externe | Clé ERP, PIM, WMS, marketplace, comptabilité ou traitement | Préserver la clé stable nécessaire pour reconnecter la boutique cible. |
Version et environnement sont donc des informations de traçabilité des données. Elles expliquent pourquoi deux boutiques Gambio peuvent afficher le même libellé tout en stockant ou utilisant la valeur différemment.
Products, types d’article, Categories et champs de catalogue sont distincts
Gambio utilise couramment le terme article pour désigner un Product vendable. Un Product peut porter un numéro d’article, une quantité en stock, un poids, un Manufacturer, une classe fiscale, un statut de livraison, un code-barres ou EAN, une unité d’emballage, une unité de quantité, une quantité minimale de commande, des incréments de quantité, des images, des descriptions multilingues, des métadonnées et des liens vers des Categories. Le type de Product peut également distinguer un article standard, téléchargeable ou un service.
Les Categories sont des enregistrements distincts et un même Product peut être lié à plusieurs Categories. Cette relation est importante lorsqu’une boutique source duplique des Products pour obtenir plusieurs emplacements de navigation ou lorsque les Categories servent aussi au merchandising, au SEO ou à la navigation. L’interprétation correcte peut être un seul Product associé à plusieurs Categories plutôt que plusieurs Products qui partagent simplement le même contenu.
Gambio prend également en charge des champs Product supplémentaires, des onglets Product, filtres, affectations de taxonomie Google, Manufacturers, contenus associés et indicateurs de merchandising. Ces valeurs ne doivent pas être comprimées dans la description simplement parce qu’elles apparaissent sur la page Product.
| Schéma source | Propriétaire Gambio à considérer | Sens à préserver |
|---|---|---|
| Article physique vendable | Enregistrement Product standard | Identité, prix, taxe, stock, poids, images et affectations aux Categories. |
| Fichier numérique | Product téléchargeable et relation d’accès via l’Order | Identité du fichier, conditions d’accès et contexte historique d’achat. |
| Service ou article non expédié | Type Product service | Identité vendable sans inventer de données de traitement physique. |
| Product dans plusieurs branches de navigation | Un Product lié à plusieurs Categories | Identité partagée avec plusieurs parcours de découverte. |
| Spécification technique | Champ supplémentaire, valeur de filtre ou contenu structuré | La signification descriptive reste distincte d’un choix d’achat. |
| Explication Product étendue | Onglet Product ou relation de contenu | Le contenu reste attaché au bon Product et à la bonne langue. |
| Identité fournisseur ou marque | Manufacturer ou relation de référentiel externe | La signification de marque et la clé externe restent cohérentes. |
La règle principale consiste à préserver une fois l’identité Product puis à reconstruire ses relations. Dupliquer un Product pour reproduire chaque parcours de navigation source crée des incohérences de stock, SEO et historique Order.
Options, Product Options, variantes, attributs et propriétés ne doivent pas être fusionnés
Le modèle de choix de l’acheteur dans Gambio a évolué. Les ressources développeur actuelles distinguent options, Product Options et Product Variants, tandis que les anciennes boutiques peuvent encore utiliser des attributs d’article ou des propriétés d’article. Ces structures peuvent se ressembler côté client, mais elles ne sont pas interchangeables au niveau des données.
Une option définit un domaine de choix comme taille ou couleur. Une Product Option relie une option à un Product. Une Product Variant représente une combinaison concrète issue de Product Options et peut porter des valeurs commerciales propres à cette combinaison. Les anciens attributs ou propriétés peuvent stocker des valeurs semblables via d’autres tables et règles. Les données source doivent donc être classées selon leur fonctionnement et leur origine plutôt que selon leur seul libellé.
| Fonctionnement source | Question d’interprétation Gambio | Relation à préserver |
|---|---|---|
| Le choix modifie seulement la sélection affichée | Option ou Product Option sans identité commerciale indépendante | Lien Product-option et valeur sélectionnée. |
| La combinaison possède son propre SKU, stock, prix, poids, image ou disponibilité | Product Variant | Product parent, valeurs d’option sélectionnées, identité de variante et valeurs commerciales. |
| L’acheteur saisit du texte ou une personnalisation | GX-Customizer ou saisie détenue par un module | La valeur saisie reste liée à la ligne d’Order. |
| La valeur décrit le Product | Champ supplémentaire, filtre, propriété ou contenu | La valeur descriptive reste distincte de la combinaison achetée. |
| L’ancienne boutique utilise des attributs d’article | Structure d’attribut historique | Nom et valeur d’attribut, effet sur le prix, comportement de stock et origine source. |
| L’ancienne boutique utilise des propriétés d’article | Structure de propriété ou de combinaison historique | Groupes de propriétés, valeurs, combinaisons et relations Product. |
Un simple sélecteur de taille peut se transposer directement. Une matrice de combinaisons avec stock et images distincts nécessite une identité au niveau variante. Un champ de personnalisation appartient à la ligne d’Order achetée et non à une variante réutilisable. Traiter ces trois cas comme de simples options peut donner un catalogue visuellement correct tout en perdant le sens pour le traitement et l’historique.
Stock, tarification, groupes Customer et règles de quantité forment une couche commerciale
Les données Product Gambio peuvent être liées au contrôle du stock, aux quantités minimales de commande, aux incréments, à la visibilité par groupe Customer, aux prix spécifiques aux groupes, aux prix dégressifs, remises, classes fiscales, offres spéciales et autres règles commerciales. Ces relations déterminent qui peut voir un article, quel prix lui est appliqué et quelle quantité il peut acheter.
Un groupe Customer n’est pas un simple libellé de segmentation. Gambio peut l’utiliser pour contrôler la visibilité et les prix Product. Un niveau grossiste de la source peut donc nécessiter une relation avec un groupe Customer, alors qu’un segment marketing peut appartenir à un autre système. Les Orders historiques doivent conserver le prix, la remise, la taxe et la quantité effectivement enregistrés lors de l’achat au lieu d’être réinterprétés depuis le groupe Customer actuel.
| Sens source | Relation Gambio | Limite de transposition |
|---|---|---|
| Product disponible uniquement aux acheteurs autorisés | Visibilité Product par groupe Customer | Préserver la relation d’accès, pas seulement le nom du groupe. |
| Prix grossiste ou revendeur | Prix Product par groupe Customer | Garder Product, groupe, devise et prix reliés. |
| Palier de quantité | Prix dégressif ou règle dépendant de la quantité | Préserver les seuils et le périmètre Customer qui en bénéficie. |
| Quantité minimale d’achat | Valeur de commande minimale du Product | Garder la règle commerciale distincte de la quantité en stock. |
| Stock par combinaison vendable | Stock au niveau variante lorsque représenté | Ne pas affecter toute la quantité au Product parent. |
| Prix promotionnel actuel | Relation de tarification active | Le garder distinct du prix historique stocké dans les anciens Orders. |
C’est dans cette couche que des champs apparemment mineurs deviennent opérationnellement importants. Un prix copié sans sa relation au groupe n’est pas le même prix. Une quantité copiée sans l’identité de la variante n’est pas le même enregistrement de stock.
Customers, adresses, groupes et Orders portent des types d’informations différents
Les données Customer Gambio peuvent inclure l’identité du compte, les adresses, l’appartenance à un groupe Customer, un contexte commerçant ou revendeur, des notes internes, des préférences de communication, des Reviews et des relations administratives. Ces enregistrements doivent être séparés selon leur finalité. Une adresse du carnet Customer n’est pas la même chose qu’une adresse figée au moment d’un Order. Une affectation de groupe n’est pas une remise historique. Un compte administrateur n’est pas un compte Customer.
Les Orders contiennent des éléments commerciaux historiques : identité Customer ou invité, adresses de facturation et d’expédition, références Product et variante, choix sélectionnés, quantités, prix, remises, taxes, expédition, libellés de paiement, statuts Order, commentaires, factures, documents de livraison, retraits et autres enregistrements associés. Un Order migré doit rester compréhensible même si la boutique cible utilise une configuration actuelle différente pour le paiement, l’expédition, les taxes ou les statuts.
| Élément historique | Propriétaire Gambio | Sens à conserver |
|---|---|---|
| Acheteur enregistré | Compte Customer | Identité et relation avec Orders et adresses. |
| Acheteur invité | Instantané d’identité au niveau Order | Contexte historique de l’acheteur sans inventer un compte. |
| Adresse enregistrée | Carnet d’adresses Customer | Relation d’adresse Customer réutilisable. |
| Adresse de facturation ou d’expédition d’un Order | Instantané au moment de l’Order | Preuve de la transaction telle qu’elle a été passée. |
| Choix Product sur une ligne d’Order | Libellé Product/variante et valeurs sélectionnées | Article exact acheté, même si le catalogue change ensuite. |
| Libellés de paiement et d’expédition | Historique Order | Preuve de la méthode historique, pas configuration de la méthode actuelle. |
| Historique de remboursement, retrait ou statut | Enregistrements Order associés | Le contexte après-vente reste traçable. |
Le modèle le plus robuste conserve distincts les données maîtres Customer et les instantanés d’Order. Modifier une adresse Customer après migration ne doit jamais réécrire l’adresse enregistrée sur un ancien Order.
Content Manager, contenu Product, URL et thèmes ont des propriétaires différents
Le contenu Gambio peut résider dans le Content Manager, les descriptions Product, les onglets Product, les descriptions de Category, les bannières, sliders, menus, pages juridiques, pages d’erreur, blocs de thème, fichiers de langue ou modules. Chaque structure possède son propre propriétaire et sa propre relation avec les routes.
Les CMS Pages doivent conserver leur identité, langue, contenu, visibilité, placement dans les menus et relation URL. Les onglets Product restent liés aux Products. Les descriptions de Category restent liées aux Categories. Un bloc de thème ou une configuration StyleEdit contrôle la présentation et ne doit pas être confondu avec une CMS Page portable. Le contenu juridique ou de politique peut nécessiter une revue métier actuelle, mais l’identité et le placement de l’enregistrement peuvent toujours être préservés comme données de contenu.
Les enregistrements Product et Category Gambio peuvent également contenir mots-clés d’URL, réécritures d’URL, métadonnées, termes de recherche et valeurs multilingues. Ces relations influencent la découverte, mais ne transforment pas navigation, contenu et SEO en un même objet.
| Élément visible de la boutique | Propriétaire Gambio probable | Conséquence sur le modèle de données |
|---|---|---|
| Page d’information ou de politique | Entrée Content Manager | Préserver contenu, langue, route et placement. |
| Explication Product supplémentaire | Onglet Product ou contenu Product | La garder attachée au Product au lieu de créer une Page générique. |
| Texte d’atterrissage Category | Enregistrement Category | Le conserver avec l’identité et la route Category. |
| Bannière ou teaser d’accueil | Configuration de bannière/teaser | L’actif de contenu et son placement sont distincts. |
| Élément de menu | Configuration de navigation | Une Page ou Category migrée ne recrée pas automatiquement son placement dans le menu. |
| Bloc de thème ou surcharge de modèle | Présentation par thème ou module | Reconstruire la présentation sans classer le code comme contenu. |
| Ancienne URL Product ou Category | URL de l’entité et relation de redirection | Préserver la relation entre parcours source et cible. |
Une migration propre peut préserver le contenu tout en modifiant sa présentation. L’exigence essentielle est que chaque enregistrement atteigne le bon propriétaire Gambio et reste relié à sa route et à sa langue.
Modules, GXModules, API et systèmes externes étendent le modèle natif
Gambio prend en charge modules, GXModules, thèmes, API REST, imports/exports et intégrations avec marketplaces, comptabilité, traitement, recherche ou autres systèmes. Ces composants peuvent créer des champs, tables, statuts, identifiants et enregistrements de processus qui ne font pas partie du modèle natif Product, Customer ou Order.
La présence d’une valeur dans la base de données n’en fait pas un champ Gambio principal. Un module peut stocker un ID d’annonce marketplace, un code fournisseur, une référence de transaction de paiement, un statut de flux Product, une propriété Customer personnalisée ou un indicateur de traitement Order. Son sens dépend du module ou du système externe qui la lit.
| Propriétaire des données | Exemples | Décision de transposition |
|---|---|---|
| Gambio principal | Products, Categories, Customers, Orders, contenu, options, variantes | Transposer via les relations de données natives. |
| Module Gambio ou GXModule | Champs, tables, statuts et enregistrements liés à la configuration du module | Préserver uniquement avec un propriétaire cible identifié et une clé principale associée. |
| Thème ou StyleEdit | Mise en page, blocs, modèles, réglages visuels | Traiter comme présentation cible plutôt que comme données e-commerce maîtres. |
| ERP/PIM/WMS externe | Identifiants maîtres, stock, fournisseur, prix ou traitement | Conserver les clés intersystèmes durables et l’autorité correspondante. |
| Marketplace ou canal | IDs d’annonce, états d’offre, Categories du canal, métadonnées de synchronisation | Garder séparés du Product canonique sauf si le processus cible les utilise toujours. |
| Code personnalisé | Tables sur mesure ou champs principaux modifiés | Définir explicitement la propriété de l’entité au lieu de supposer une prise en charge native. |
Les boutiques Cloud et auto-hébergées peuvent exposer des preuves techniques différentes, mais la même règle s’applique : les données actives détenues par une extension ont besoin d’un propriétaire qui continue. Les artefacts techniques obsolètes ne deviennent pas utiles simplement parce qu’ils existent dans la base source.
Décisions de transposition Gambio selon le sens métier
| Schéma source | Bonne question Gambio | Conséquence d’une mauvaise hypothèse |
|---|---|---|
| Product parent avec combinaisons enfants | La valeur source est-elle une option, Product Option, variante actuelle ou combinaison historique d’attribut/propriété ? | SKU, stock, prix, image ou valeurs sélectionnées de l’enfant sont perdus ou dupliqués. |
| Product visible uniquement aux grossistes | La restriction appartient-elle à la visibilité par groupe Customer ? | Le Product devient public ou inaccessible aux bons acheteurs. |
| Prix par niveau ou quantité | Quels Product, groupe, seuil et devise définissent le prix ? | Les acheteurs reçoivent le mauvais prix même si la valeur numérique existe. |
| Contenu affiché sur une page Product | S’agit-il d’un onglet Product, champ supplémentaire, bloc de module ou CMS Page ? | Le contenu arrive sans la relation qui permet de l’afficher. |
| Statut historique d’Order | Quel historique Order, paiement, traitement ou retrait explique cet état ? | Les équipes ne peuvent plus interpréter correctement la transaction passée. |
| Champ créé par un module | Quel module ou système externe possède et met à jour la valeur ? | Une donnée orpheline est copiée dans un champ qu’aucun processus ne maintient. |
| URL historique | Quel Product, Category ou contenu doit recevoir la redirection ? | La continuité de recherche et de liens internes est rompue malgré un transfert réussi. |
La migration Gambio préserve le sens lorsque l’origine des Products, les choix d’achat, les relations commerciales par groupe Customer, les preuves historiques des Orders, la propriété du contenu et les enregistrements d’extensions sont traités comme des domaines liés mais distincts.
Conclusion
La transposition du modèle de données Gambio dépend de la génération du catalogue, des types Product, des liens Category, des structures d’options actuelles et historiques, de la tarification et de la visibilité par groupe Customer, des Orders historiques, des enregistrements Content Manager, des modules, des API et du contexte Cloud ou auto-hébergé. Un champ source n’est utile que si la boutique cible préserve l’entité qui le possède et les relations qui lui donnent son sens.
Le modèle cible le plus robuste distingue Products et variantes, champs descriptifs et choix de l’acheteur, données maîtres Customer et instantanés d’Order, contenu et présentation, ainsi que données principales Gambio et données de modules ou systèmes externes. Cette discipline d’attribution produit un catalogue et un historique commercial qui restent compréhensibles plutôt que simplement remplis.
Questions fréquentes
Quelle est la différence entre les options Gambio et les Product Variants ?
Les options définissent des domaines de choix et les Product Options relient ces choix à un Product. Les Product Variants représentent des combinaisons concrètes et peuvent porter des valeurs commerciales propres à la combinaison. Les anciennes boutiques peuvent utiliser des attributs ou propriétés d’article, d’où l’importance de la version source et des relations entre tables.
Chaque combinaison Product source doit-elle devenir une Product Variant Gambio ?
Non. Une combinaison correspond à une variante lorsqu’elle possède une identité ou des valeurs commerciales distinctes, comme SKU, stock, prix, poids, image ou disponibilité. La personnalisation et les spécifications descriptives relèvent généralement d’autres structures.
Comment les groupes Customer Gambio influencent-ils la migration ?
Ils peuvent contrôler la visibilité Product, les prix spécifiques aux groupes, les prix dégressifs, le traitement fiscal ou d’autres règles commerciales. Conserver uniquement le nom du groupe ne préserve pas ces relations Product et tarification.
Un Product Gambio peut-il appartenir à plusieurs Categories ?
Oui. Gambio peut relier un Product à plusieurs Categories. Une boutique source qui duplique les Products pour la navigation peut être mieux représentée par une identité Product unique avec plusieurs affectations Category.
Les entrées Content Manager Gambio sont-elles identiques aux onglets Product ou blocs de thème ?
Non. Les entrées Content Manager sont des enregistrements de contenu indépendants. Les onglets appartiennent aux Products, tandis que les blocs de thème et réglages StyleEdit appartiennent à la présentation. Chacun nécessite un propriétaire cible distinct.
Que faire des données créées par des modules Gambio ou des intégrations externes ?
Identifiez le module ou le système externe, l’enregistrement principal qu’il étend et l’identifiant stable qui les relie. Les relations actives ont besoin d’une destination explicite dans la boutique cible ; les enregistrements techniques obsolètes peuvent être exclus ou archivés sans être traités comme des données Gambio natives.