Les boutiques X-Cart réunissent souvent plusieurs générations de logique de catalogue et d’extensions. Les versions actuelles distinguent les Product Variations des anciennes Product Variants, tandis que les classes de produits et les attributs structurent les caractéristiques du catalogue. Les données client peuvent être reliées à des types d’utilisateurs, des rôles, des adresses, des champs de profil et des adhésions. Les Orders utilisent des statuts distincts pour le paiement et le traitement logistique. Des modules peuvent ajouter des fonctions de tarification grossiste, de compatibilité automobile, de réseau de revendeurs, d’avis, de fidélité, d’abonnements ou de marketplace.
Ces différentes couches signifient qu’une migration X-Cart ne peut pas être réduite à Products, Categories, Customers et Orders. Une matrice couleur-taille provenant de la source peut nécessiter des Product Variations actuelles, l’interprétation d’anciennes Product Variants ou une autre structure d’options produit. Un groupe de clients peut représenter un niveau d’adhésion qui contrôle la tarification, l’accès, les taxes ou les moyens de paiement. Une valeur de compatibilité automobile peut appartenir à un module et à une taxonomie de véhicules externe plutôt qu’à un attribut produit général.
La migration dépend donc de la traduction des responsabilités et des relations : quelle entité X-Cart possède la valeur, quels autres enregistrements lui donnent son sens, et si cette valeur relève du cœur de la plateforme, d’une structure historique, d’un module, de la présentation ou d’un système externe.
La signification du catalogue X-Cart dépend de la version et des modules installés
Les structures de données actuelles et historiques de X-Cart doivent être distinguées avant toute mise en correspondance. Les versions actuelles utilisent des Product Variations, tandis que les anciennes boutiques peuvent conserver des structures historiques de Product Variants. Les installations X-Cart exploitées depuis longtemps peuvent également contenir d’anciens modules, du code personnalisé ou des structures importées qui ne correspondent pas au schéma d’une installation actuelle propre.
| Élément observé dans la source | Interprétation X-Cart | Conséquence pour la migration |
|---|---|---|
| Enregistrements de variations actuelles | Product Variations et données Product associées | Préserver l’identité actuelle de la variation, les attributs sélectionnés et les valeurs commerciales. |
| Tables ou champs d’anciennes variantes | Structure historique Product Variants | Interpréter les données selon la version source plutôt que de supposer le schéma actuel. |
| Enregistrements de classes et attributs produit | Caractéristiques Product structurées et définitions d’attributs réutilisables | Conserver l’appartenance à la classe et les relations attribut-valeur. |
| Champs Product propres à un module | Données d’extension possédées par le module | Ne pas traiter chaque champ comme faisant partie du cœur de X-Cart. |
| Tables de base de données personnalisées | Entité ou relation personnalisée | Définir une destination uniquement après avoir identifié le processus qui consomme ces données. |
| Identifiants d’intégration externes | Identifiant ERP, PIM, WMS, CRM, marketplace ou automobile | Préserver les clés stables nécessaires pour reconnecter la boutique cible. |
La version source et l’inventaire des modules ne sont pas de simples métadonnées techniques. Ils déterminent ce qu’un Product, une option, un Customer ou un champ d’Order signifie réellement. Deux boutiques X-Cart peuvent utiliser le même libellé tout en stockant et en exploitant la valeur de manière différente.
Products, variations, classes et attributs remplissent des rôles différents
Un Product X-Cart porte l’identité principale du produit, notamment son nom, son SKU, son prix, son stock, ses descriptions, ses images, ses affectations aux Categories, ses propriétés d’expédition et de taxe, ainsi que sa visibilité. Les Product Variations représentent des versions sélectionnables d’un Product. Les classes et attributs décrivent des caractéristiques structurées et peuvent contribuer à l’organisation du catalogue, au filtrage, à la comparaison ou à l’affichage d’informations sur la page produit.
Une option produit issue de la source doit être classée selon son fonctionnement. Si la valeur sélectionnée identifie une combinaison gérée séparément avec son propre prix, stock, SKU, image ou poids, elle se rapproche d’une variation. Si elle modifie un Product sans stock indépendant, une autre structure de choix peut être plus appropriée. Si elle décrit le Product sans modifier l’article acheté, elle relève plutôt des attributs ou du contenu.
| Structure source | Question de destination dans X-Cart | Relation à préserver |
|---|---|---|
| SKU enfant couleur-taille | Product Variation actuelle ou ancienne Product Variant | Identité enfant, stock, prix, médias et valeurs sélectionnées. |
| Champ de personnalisation | Saisie de l’acheteur ou choix Product possédé par un module | La valeur saisie reste attachée à la ligne d’Order correspondante. |
| Spécification technique | Attribut Product dans la classe appropriée | La caractéristique structurée reste distincte d’un choix d’achat. |
| Tarif grossiste par quantité | Relation de tarification grossiste du cœur ou d’un module | Les seuils de quantité et le périmètre d’adhésion restent associés. |
| Fichier numérique | Relation e-goods ou pièce jointe au fichier lorsqu’elle est utilisée | L’accès reste lié au bon Product et au bon contexte d’Order. |
| Compatibilité automobile | Enregistrement du module de compatibilité et taxonomie de véhicules | La relation Product-véhicule reste distincte des attributs généraux. |
Les Product Variations actuelles et les anciennes Product Variants ne doivent jamais être mélangées sans distinction. Une migration peut devoir interpréter des enregistrements historiques et les exprimer dans le modèle actuel de la boutique cible, mais la lignée de la source doit rester claire pour éviter de dupliquer ou perdre les identités enfant et les combinaisons d’options.
Categories, classes, attributs et recherche définissent la découverte des produits
Les Categories structurent la navigation des acheteurs et l’affectation des Products. Les classes de produits regroupent des attributs réutilisables. Les attributs portent les caractéristiques Product. Les modules de recherche et de filtrage peuvent indexer les Categories, attributs, SKU, marques, tags, compatibilités ou autres valeurs appartenant à des extensions. Ces structures sont liées, mais ne sont pas interchangeables.
Une marque représentée comme Category dans la source peut mieux correspondre à un attribut X-Cart ou à un module de marque. Une arborescence de spécifications peut devenir des classes et attributs Product. Une page d’atterrissage peut nécessiter du contenu et de la navigation plutôt qu’une Category. Un sélecteur de compatibilité automobile peut dépendre d’enregistrements de véhicules et d’une relation Product-compatibilité plutôt que de filtres ordinaires.
| Élément de découverte | Propriétaire dans X-Cart | Limite de traduction |
|---|---|---|
| Hiérarchie visible par l’acheteur | Category et affectations Product | La présence des Categories ne recrée pas automatiquement la navigation. |
| Spécification produit | Classe et valeur d’attribut | Les valeurs restent structurées et reliées au bon type de Product. |
| Marque | Attribut ou enregistrement d’un module de marque | La signification de la marque ne doit pas être dupliquée dans des Categories et des champs. |
| Valeur filtrable | Attribut ou champ d’index appartenant à un module | Le fonctionnement de la recherche dépend de valeurs normalisées et de l’indexation cible. |
| Compatibilité véhicule | Enregistrements de compatibilité automobile | La compatibilité nécessite une taxonomie de véhicules et des clés de relation, pas du texte libre. |
| Product associé | Relation Product du cœur ou d’un module | Les liens de merchandising restent distincts de l’appartenance à une Category. |
Ce modèle évite d’aplatir la logique de découverte dans les descriptions Product. Une description migrée peut afficher des spécifications, mais elle ne remplace pas des attributs structurés, une logique de compatibilité, des comparaisons ou des relations de filtrage.
Customers, types d’utilisateurs, rôles, champs de profil et adhésions sont distincts
La gestion des utilisateurs X-Cart peut inclure des administrateurs, Customers et vendeurs ; des rôles et autorisations ; des comptes clients et adresses ; des champs de profil personnalisés ; ainsi que des niveaux d’adhésion. Les adhésions peuvent modifier l’accès aux Products et Categories, la tarification Product, les quantités minimales, les remises, les coupons, les offres spéciales, les taxes ou les moyens de paiement.
Un segment Customer provenant de la source doit donc être interprété selon sa fonction. Les statuts grossiste, revendeur, VIP, employé, exonéré de taxe, acheteur approuvé, fidélité ou abonnement ne correspondent pas nécessairement à une seule adhésion générique. Certaines valeurs sont des caractéristiques d’identité, d’autres des règles d’accès commercial, d’autres appartiennent à des modules, et certaines sont des classifications externes provenant d’un CRM ou d’un ERP.
| Signification du compte source | Propriétaire X-Cart à envisager | Relation à conserver |
|---|---|---|
| Acheteur individuel | Compte Customer et carnet d’adresses | Identité, connexion, adresses et Orders restent reliés. |
| Utilisateur administratif | Type d’utilisateur administrateur et rôle | Les autorisations restent distinctes de la segmentation Customer. |
| Utilisateur vendeur marketplace | Utilisateur vendeur et relation d’organisation possédée par le module | L’utilisateur reste relié à la bonne entité vendeur ou marketplace. |
| Niveau de prix ou d’accès | Niveau d’adhésion et règles commerciales associées | L’adhésion affecte les Products, tarifs, taxes ou moyens prévus. |
| Informations Customer supplémentaires | Champ de profil ou identifiant externe | L’objectif du champ et les exigences de confidentialité restent explicites. |
| Compte entreprise externe | Structure personnalisée/module ou clé de système externe | Plusieurs acheteurs restent associés à l’entreprise de référence lorsqu’il le faut. |
L’historique d’adhésion diffère également de l’adhésion actuellement attribuée. Une Order historique doit conserver le prix, la remise, les taxes et les données de paiement qui ont réellement été enregistrés, sans que la plateforme cible doive reproduire l’ancien calcul à partir du niveau d’adhésion actuel du client.
Les Orders utilisent des relations commerciales et logistiques distinctes
Les Orders X-Cart regroupent Customers ou acheteurs invités, lignes d’Order, Products, options sélectionnées, prix, remises, coupons, taxes, frais d’expédition, adresses, statuts, transactions, notes, expéditions, retours et références externes. Les anciennes versions ou certains modules peuvent combiner des informations qu’une boutique actuelle représente avec des états séparés.
Le statut financier, le statut de traitement logistique et le statut opérationnel ne doivent pas être fusionnés. Une commande peut être payée sans avoir encore été expédiée, remboursée après expédition, partiellement exécutée ou annulée avec une transaction financière historique toujours pertinente. La migration doit préserver les éléments historiques nécessaires pour comprendre l’Order, et non forcer un ancien libellé combiné dans un seul champ cible.
| Élément source | Relation X-Cart | Point de traduction |
|---|---|---|
| Identité de l’Order | Enregistrement Order et numéro de référence | Préserver les clés stables utilisées par le service client et les systèmes externes. |
| Lignes de produits | Lignes d’Order et Products ou snapshots | Conserver le produit acheté, les valeurs sélectionnées, la quantité et le prix historique. |
| Statut financier | Paiement, transaction, remboursement ou éléments associés | Préserver l’état financier historique séparément de l’exécution logistique. |
| Statut d’exécution | Expédition, livraison, retour ou état de traitement | Conserver les éléments logistiques sans réécrire l’historique de paiement. |
| Valeur personnalisée de ligne | Choix de l’acheteur, champ ou donnée de module | Maintenir la valeur avec la ligne d’Order qu’elle décrit. |
| Identifiant externe | ERP, WMS, marketplace ou autre clé d’intégration | Préserver la continuité avec le système autoritatif externe. |
Lorsqu’une ancienne plateforme utilise un statut combiné, la traduction doit préserver les éléments historiques disponibles au lieu de forcer le libellé dans un seul champ. Les configurations actuelles de paiement, d’expédition, de taxes et de notifications restent séparées des enregistrements historiques d’Orders.
Contenus, Pages statiques, URL et présentation de la vitrine ont des propriétaires différents
Les données visibles dans une vitrine X-Cart peuvent inclure les descriptions de Products et Categories, des Pages statiques, menus, images, vidéos, onglets Product personnalisés, bannières, blocs de mise en page, thèmes, métadonnées, URL propres, redirections et valeurs linguistiques. Ces éléments doivent être distingués selon leur responsabilité : contenu, route ou présentation.
Les descriptions Product appartiennent aux Products. Les Pages statiques possèdent leur propre identité et leur route. Les onglets Product personnalisés peuvent appartenir à un module. Les menus et blocs de mise en page contrôlent le placement. Les thèmes et modèles définissent la présentation. Les métadonnées SEO et redirections protègent les relations de routes. Une vitrine headless ou très personnalisée peut conserver d’autres contenus en dehors du cœur de X-Cart.
| Élément source | Couche de destination X-Cart | Signification à préserver |
|---|---|---|
| Description Product ou Category | Contenu du catalogue | Le texte reste attaché à la bonne entité et à la bonne langue. |
| Page d’information statique | Enregistrement Page | Contenu, route, hiérarchie et visibilité restent distincts. |
| Onglet Product personnalisé | Relation de contenu Product possédée par un module | Le placement de l’onglet et son affectation au Product restent liés. |
| Bannière ou bloc de page d’accueil | Configuration de présentation ou enregistrement de module | La migration du contenu n’implique pas son placement visuel. |
| Ancienne URL | Structure d’URL propre et de redirection | L’ancien chemin et la destination dans la boutique cible restent explicites. |
| Personnalisation du thème | Mise en œuvre de la présentation cible | Le code de modèle n’est pas une donnée CMS ordinaire. |
Ce modèle de responsabilité évite une erreur fréquente : considérer chaque élément visible de la vitrine comme du contenu portable. Certains éléments visibles sont générés à partir de Products et Categories, d’autres sont des Pages distinctes, et certains n’existent que parce qu’un module ou un thème les affiche.
Les modules X-Cart peuvent posséder des données de catalogue, client et Order
Les modules X-Cart peuvent introduire des champs et entités pour la tarification grossiste, la fidélité, les abonnements, les avis, les pièces jointes Product, les onglets personnalisés, la compatibilité automobile, les revendeurs, les vendeurs marketplace, les retours, la connexion sociale, les services fiscaux, les services de paiement, les intégrations d’expédition et les flux externes. Les enregistrements de modules peuvent dépendre de paramètres, de traitements planifiés, d’identifiants API ou de taxonomies externes.
La question centrale n’est pas de savoir si le nom du module existe dans la boutique cible. Il faut déterminer si les enregistrements et leurs relations restent nécessaires et si la plateforme cible possède une destination capable de les interpréter.
| Propriétaire des données | Exemples d’enregistrements | Conséquence pour le périmètre |
|---|---|---|
| Cœur X-Cart | Products, Categories, classes, attributs, utilisateurs, Orders, Pages | Mettre en correspondance via les relations de données natives. |
| Module X-Cart | Tarification par adhésion, compatibilité, adresses de revendeurs, avis, fidélité, abonnements | Examiner le schéma du module et ses liens avec les enregistrements du cœur. |
| Code personnalisé | Champs, tables, statuts ou processus spécifiques | Définir volontairement une destination ou une décision d’archivage. |
| Service externe | Paiement, taxe, expédition, recherche, marketplace, analyse | Préserver les références nécessaires pour rapprocher les systèmes historiques et actifs. |
| ERP/PIM/WMS/CRM | Identifiants de référence pour Products, Customers, stocks et Orders | Maintenir des clés stables pour la reconnexion et la responsabilité des données. |
Les données automobiles illustrent bien cette distinction. Année, marque, modèle, moteur, finition, type de compatibilité et adresse de revendeur peuvent ressembler à de simples attributs Product, mais la compatibilité opérationnelle dépend de taxonomies de véhicules partagées et de relations entre Products et véhicules. Les aplatir en texte peut préserver les mots tout en détruisant la recherche de compatibilité et sa maintenance.
Les formats de transfert ne définissent pas tout le modèle X-Cart
Les fonctions d’import et d’export de X-Cart peuvent traiter Products, Categories, attributs, utilisateurs, Orders, stocks, avis et certains enregistrements de modules. La présence d’un champ dans un fichier CSV confirme qu’une donnée peut être représentée dans un format de transfert ; elle ne prouve pas que toutes les relations associées, les paramètres de module ou les dépendances externes sont également inclus.
Par exemple, importer une valeur d’attribut ne recrée pas automatiquement sa classe Product ni son mode d’affichage. Importer un Customer ne crée pas une tarification propre à une adhésion si l’adhésion et les règles correspondantes n’existent pas. Importer une Order ne recrée pas les moyens actuels de paiement ou d’expédition. Importer un identifiant de compatibilité ne signifie rien si la taxonomie de véhicules référencée est absente.
| Élément de transfert | Relation supplémentaire à identifier |
|---|---|
| Ligne Product | Category, classe, attributs, variation, médias, stock et liens de modules. |
| Valeur d’attribut | Définition de l’attribut, affectation de classe, type de saisie et relation Product. |
| Ligne Customer | Type d’utilisateur, adresses, champs de profil, adhésion et identité externe. |
| Ligne Order | Lignes, statuts, transactions, expéditions, retours et snapshots historiques. |
| CSV de module | Module installé, tables de référence, configuration et taxonomie externe. |
| Champ d’identifiant externe | Système autoritatif, règle d’unicité et processus de reconnexion. |
Le plan de traduction doit suivre les relations de données plutôt que la forme d’un seul fichier d’export. C’est particulièrement important pour les anciennes boutiques X-Cart dont les données peuvent avoir traversé des mises à niveau, des imports personnalisés ou des remplacements de modules.
Décisions de traduction selon la signification métier dans X-Cart
| Structure source | Bonne question de traduction | Conséquence d’une mauvaise hypothèse |
|---|---|---|
| Combinaisons enfant actuelles ou historiques | La source utilise-t-elle des Product Variations actuelles, d’anciennes Product Variants ou une logique d’options personnalisée ? | Le SKU enfant, le stock, le prix ou les valeurs sélectionnées sont dupliqués ou perdus. |
| Spécifications techniques | Relèvent-elles des classes et attributs Product ? | Le filtrage, la comparaison et la gouvernance du catalogue deviennent peu fiables. |
| Segment grossiste ou revendeur | S’agit-il d’une adhésion, de données d’entreprise appartenant à un module ou d’une classification CRM externe ? | Tarification et accès sont rattachés à la mauvaise couche d’identité. |
| Statut d’Order combiné | Comment séparer les éléments de paiement et de traitement logistique ? | L’état financier ou d’expédition historique devient trompeur. |
| Compatibilité automobile | Quel module et quelle taxonomie de véhicules possèdent la relation ? | La recherche de compatibilité et sa maintenance disparaissent même si le texte est migré. |
| Onglet ou champ personnalisé | S’agit-il de contenu du cœur, de données de module ou de présentation du thème ? | Les données arrivent sans la structure de vitrine qui les utilise. |
| Clé ERP ou marketplace | Quel système est autoritatif et quel enregistrement la clé identifie-t-elle ? | L’enregistrement migré ne peut plus être rapproché ni synchronisé. |
La migration X-Cart préserve la signification lorsque l’historique des versions, les types de données et structures du cœur, les modules et les systèmes externes sont traités comme des domaines de responsabilité distincts. Cette approche permet d’obtenir une boutique cible dans laquelle les choix Product, le traitement des Customers, l’historique des Orders, les contenus et les intégrations restent compréhensibles plutôt que simplement présents.
Conclusion
La traduction du modèle de données X-Cart dépend de la version source, de la structure du catalogue, des relations utilisateur, de la signification des Orders, des modules et des systèmes externes. Les Product Variations actuelles doivent être distinguées des anciennes Product Variants. Les classes et attributs Product doivent rester séparés des choix d’achat. Les adhésions peuvent gouverner des relations de prix, d’accès, de taxe et de paiement. Les Orders nécessitent des contextes distincts de paiement, traitement logistique, transaction, expédition et retour. Les modules peuvent posséder des enregistrements tels que tarification grossiste, compatibilité, revendeurs, fidélité, abonnements et données marketplace.
Un périmètre de migration solide attribue chaque valeur source à l’entité ou au module X-Cart qui porte la même signification métier et préserve des identifiants stables entre les systèmes connectés. Cette méthode évite la fausse confiance d’un transfert champ par champ et produit une boutique cible dont le catalogue et l’historique commercial restent exploitables.
Questions fréquentes
Quelle est la différence entre les Product Variations actuelles de X-Cart et les anciennes Product Variants ?
Elles appartiennent à deux générations différentes de la structure de catalogue X-Cart. Les versions actuelles utilisent des Product Variations, tandis que les anciennes boutiques peuvent encore contenir des enregistrements Product Variant historiques. La version source et les relations entre tables doivent être identifiées avant d’exprimer ces combinaisons dans la boutique cible.
Chaque option source doit-elle devenir une Product Variation X-Cart ?
Non. Une valeur correspond à une variation lorsqu’elle identifie une combinaison gérée séparément avec ses propres valeurs commerciales. La personnalisation, les services cadeau ou les spécifications descriptives peuvent relever d’une autre structure de choix Product, d’un attribut ou d’un champ appartenant à un module.
Comment les classes et attributs Product X-Cart influencent-ils la migration ?
Les classes regroupent les définitions d’attributs réutilisables, tandis que les valeurs d’attribut décrivent chaque Product. Conserver uniquement les valeurs sans les relations de classe et de définition affaiblit la gouvernance du catalogue, le filtrage, la comparaison et la structure des pages Product.
Un groupe de Customers source peut-il toujours devenir une adhésion X-Cart ?
Non. Une adhésion est appropriée lorsqu’elle gouverne un fonctionnement commercial ou un accès dans X-Cart. Des segments marketing, relations d’entreprise, statuts de fidélité, indicateurs fiscaux ou classifications CRM externes peuvent nécessiter d’autres destinations.
Pourquoi les données de compatibilité automobile doivent-elles être traitées séparément des attributs Product ordinaires ?
La compatibilité dépend généralement d’enregistrements de véhicules partagés et de relations entre Products et véhicules. Des valeurs texte libres pour l’année, la marque et le modèle ne préservent ni la taxonomie ni les clés relationnelles nécessaires à une recherche et une maintenance fiables de la compatibilité.
Que faire des enregistrements appartenant à un module X-Cart ou à une table personnalisée ?
Il faut identifier le module ou le processus personnalisé, les enregistrements du cœur qu’il étend ainsi que toute taxonomie ou identifiant externe utilisé. Les relations encore actives nécessitent une destination explicite dans la boutique cible ; les données obsolètes peuvent être archivées ou exclues sans être classées à tort comme données natives Product, Customer ou Order.