CS-Cart représente l’activité commerce au moyen de relations qu’il est facile d’aplatir à tort. Les Products peuvent porter des features, des filtres, des options, des exceptions d’option et des Product Variations. Categories et Products peuvent relever de périmètres de storefront différents. Les éditions Multi-Vendor ajoutent des Vendors, des administrateurs vendeurs, des Products appartenant aux vendeurs, des Orders marketplace, des commissions et un contexte de versement. Les groupes Customers peuvent influer sur les prix, l’accès et les promotions. Enfin, certaines extensions créent des enregistrements qui n’appartiennent pas du tout au catalogue principal.
Ces différences comptent parce que des libellés similaires dans la source ne garantissent pas le même fonctionnement. Un champ « couleur » peut être une feature descriptive, une valeur de filtre, une option qui modifie le prix ou une feature utilisée pour générer des Product Variations distinctes. Une boutique source peut devenir un storefront CS-Cart autonome, une branche régionale de marketplace ou simplement une présentation localisée. Un fournisseur peut n’être qu’une référence interne dans un système et devenir, dans un autre, un Vendor de marketplace qui possède Products et Orders.
Migrer vers CS-Cart exige donc de transposer la propriété des données et leurs relations. L’objectif est de préserver ce que chaque enregistrement signifie pour le catalogue, le storefront, le vendeur, le Customer, l’Order et les systèmes connectés, plutôt que de reproduire uniquement les noms de champs.
CS-Cart sépare les caractéristiques du catalogue, les choix d’achat et les variations vendables
CS-Cart utilise des structures différentes pour les caractéristiques d’un Product et les choix proposés à l’acheteur. Les features sont des propriétés indissociables du Product, par exemple la marque, le matériau, l’ISBN ou une spécification technique. Elles peuvent être regroupées et utilisées pour la comparaison, le filtrage ou l’organisation du catalogue. Les options représentent des choix séparables, comme la gravure, l’emballage cadeau ou une garantie ; elles ne disposent pas de stock indépendant mais peuvent modifier le prix ou le poids. Les Product Variations regroupent des Products selon des valeurs de features sélectionnées, et chaque variation reste un Product avec sa propre identité commerciale.
| Valeur source | Structure CS-Cart propriétaire | Sens à maintenir distinct |
|---|---|---|
| Spécification technique | Product feature ou groupe de features | Décrit le Product et peut servir au filtrage ou à la comparaison. |
| Choix effectué par l’acheteur | Product option et variante d’option | Modifie la configuration achetée sans devenir un stock indépendant. |
| SKU enfant couleur/taille | Product Variation au sein d’un groupe de variations | Reste un Product et peut avoir son propre SKU, prix, stock, image et visibilité catalogue. |
| Combinaison interdite | Exception d’option ou règle de disponibilité d’une variation | Empêche une configuration invalide au lieu de créer une nouvelle valeur d’attribut. |
| Choix merchandising réutilisable | Option globale ou structure de type modèle | Une définition peut être attribuée à plusieurs Products. |
| Facette de recherche | Filtre fondé sur des features ou d’autres valeurs prises en charge | Demande des valeurs normalisées et des relations correctes avec les Categories. |
La distinction entre variation et élément de catalogue est particulièrement importante. Chaque variation est un Product, mais elle n’occupe pas nécessairement une place visible indépendante dans les listes de Products. Un catalogue source qui affiche chaque SKU enfant comme Product séparé peut nécessiter plusieurs éléments visibles ; un autre peut afficher un seul parent et conserver la plupart des choix de variation sur la page Product.
Mapper toutes les options source vers des features CS-Cart ferait perdre le fonctionnement d’achat. Mapper toutes les spécifications vers des options créerait des choix inutiles. Regrouper tous les SKU enfants dans un seul Product pourrait supprimer leur identité et leur stock indépendants. La structure correcte dépend de ce que la valeur source contrôle réellement.
Products, Categories, features et filtres forment le modèle de découverte
Un Product CS-Cart comprend des champs commerciaux de base, des images, un prix, une quantité, un statut, des informations de livraison et de taxe, des descriptions, des Categories, des features, des options, des fichiers et des valeurs appartenant à des extensions. Les Categories apportent hiérarchie et périmètre de storefront ; les features structurent les caractéristiques ; les filtres exposent certaines valeurs pour faciliter la découverte.
Une Category source peut représenter la navigation, une landing page SEO, une marque, une classification technique ou un regroupement interne. Ces sens ne doivent pas automatiquement rester des Categories. Une marque stockée comme Category peut mieux correspondre à une feature de marque. Une arborescence de spécifications destinée à la navigation par facettes peut nécessiter des groupes de features et des filtres. Une landing page merchandising peut nécessiter du contenu et des blocks en plus de l’affectation des Products.
| Structure de découverte source | Question de transposition vers CS-Cart | Conséquence sur les relations |
|---|---|---|
| Hiérarchie de Categories | Quelles Categories restent visibles pour l’acheteur et lesquelles sont internes ? | L’affectation des Products et la propriété du storefront dépendent de cette réponse. |
| Categories de marques | La marque doit-elle devenir une Product feature ? | La marque peut soutenir filtrage et comparaison sans dupliquer la navigation. |
| Valeurs de facettes | S’agit-il de features normalisées, d’options ou de champs d’extension personnalisés ? | Seule la bonne structure propriétaire permet des filtres cohérents. |
| Products dans plusieurs Categories | Quelles Categories et quels storefronts doivent exposer chaque Product ? | Un Product peut être présent mais absent d’un parcours d’achat important. |
| Fichiers Product | S’agit-il de téléchargements, pièces jointes, manuels ou données d’extension ? | La propriété du fichier détermine les droits d’accès et son sens dans les lignes d’Order. |
Les codes Product de CS-Cart sont des identifiants, mais la plateforme ne garantit pas par principe leur unicité. Lorsque la boutique source dépend d’un SKU unique pour les correspondances ERP, entrepôt ou marketplace, cette relation d’identifiant externe doit être explicite plutôt que déduite du seul libellé de plateforme.
Les storefronts modifient le périmètre des Products, Categories, Customers et configurations
Le fonctionnement des storefronts dépend de l’édition. Dans Store Builder Ultimate, ils peuvent fonctionner comme des boutiques indépendantes avec leurs propres Products, Categories, paramètres, bases utilisateurs et mécanismes de parcours de commande. Dans Multi-Vendor Ultimate, ils peuvent représenter des branches régionales d’une marketplace avec une sélection de Vendors, devises, langues, moyens de paiement, modes de livraison, thèmes, layouts et blocks.
Cela signifie qu’une « boutique » n’est pas une unité universelle de correspondance entre source et cible. Un même Product peut appartenir à un storefront, apparaître dans plusieurs storefronts via les Categories affectées ou suivre la visibilité de son Vendor entre plusieurs branches marketplace. Les Categories peuvent appartenir à un storefront ou avoir une portée plus large selon le contexte marketplace. Les comptes Customers et les administrateurs peuvent également être globaux ou propres à un storefront selon la configuration.
| Contexte source | Interprétation Store Builder | Interprétation Multi-Vendor |
|---|---|---|
| Boutique de marque ou régionale | Storefront indépendant avec son catalogue et ses réglages | Branche marketplace comprenant certains Vendors et une configuration régionale. |
| Propriété d’un Product | Product appartenant au storefront et éventuellement exposé via les Categories affectées | Product appartenant à un Vendor et visible là où celui-ci participe. |
| Prix du Product | Peut varier selon le storefront | Suit normalement le Product du Vendor entre branches, sauf autre structure tarifaire. |
| Category | Appartient à un storefront précis | Peut être globale ou associée à un storefront précis. |
| Base Customers | Peut être séparée par storefront | Peut être partagée ou délimitée selon la conception marketplace. |
| Administrateur | Relation administrative propre au storefront | Administrateurs marketplace et administrateurs vendeurs ont des responsabilités distinctes. |
Le périmètre de migration doit donc déterminer si les différences entre storefronts de la source relèvent des données, de la configuration ou d’opérations indépendantes. Langue, devise, paiement, livraison, thème et paramètres du parcours de commande ne remplacent pas les relations de propriété des Products et Categories. Un enregistrement peut être correctement transféré et apparaître malgré tout dans le mauvais storefront si son périmètre n’est pas préservé.
Vendors et Products communs ajoutent une couche de propriété marketplace
CS-Cart Multi-Vendor traite un Vendor comme un propriétaire commercial, et non comme un simple libellé fabricant. Les Vendors peuvent avoir leurs administrateurs, Products, participation aux storefronts, lignes d’Orders, méthodes de livraison, plans, commissions, soldes, versements et données de profil. Un champ fournisseur de la source ne doit devenir un Vendor que si cette organisation possède réellement une activité marketplace.
Certaines implémentations utilisent également des Products communs ou un catalogue partagé. Un Product commun peut fournir une identité catalogue unique tandis que les offres vendeurs portent les informations commerciales propres à chacun. Ce modèle est différent d’une duplication du même Product dans plusieurs catalogues vendeurs et différent encore d’un Product appartenant à la boutique avec un simple champ fournisseur.
| Relation source | Destination marketplace CS-Cart | Sens à préserver |
|---|---|---|
| Fabricant ou marque | Product feature, valeur de type fabricant ou donnée de marque | Origine descriptive sans propriété vendeur. |
| Référence fournisseur | Champ interne ou identifiant externe | Approvisionnement opérationnel sans comportement de compte marketplace. |
| Vendeur marketplace | Vendor | Propriété des Products, lignes d’Orders, commissions et versements. |
| Administrateur vendeur | Utilisateur Vendor ou relation administrative | L’accès reste rattaché au bon Vendor. |
| Élément de catalogue partagé avec offres vendeurs | Product commun plus données d’offre propres aux Vendors lorsque le modèle est utilisé | L’identité partagée reste distincte du prix et du stock de chaque vendeur. |
| Order marketplace | Order parent et contexte Order/lignes lié aux Vendors | Responsabilité vendeur et règlement restent interprétables. |
La migration des Vendors est incomplète si les Products vendeurs arrivent sans propriété Vendor, ou si les comptes Vendors arrivent sans leurs Products, administrateurs, contexte d’Orders et identifiants externes. À l’inverse, transformer tous les fournisseurs source en Vendors inventerait des relations marketplace inexistantes.
Customers, groupes utilisateurs et segmentation commerciale
Les utilisateurs CS-Cart peuvent être des Customers, des administrateurs ou des utilisateurs Vendor. Les groupes Customers peuvent influencer les prix Product, remises, traitements fiscaux, moyens de paiement, modes de livraison et accès aux Products ou Categories. Les champs de profil et les adresses transportent d’autres informations Customers, tandis que des systèmes externes peuvent rester propriétaires des numéros de compte, du statut de crédit ou des relations entre entreprises.
Un libellé Customer de la source doit être interprété par sa fonction. Wholesale, VIP, revendeur, employé, exonération fiscale, distributeur ou abonnement ne doivent devenir un groupe utilisateur CS-Cart que si ce groupe est bien propriétaire du fonctionnement recherché. Un compte entreprise avec plusieurs acheteurs peut demander une autre structure ou une extension. Un segment CRM utilisé uniquement pour le marketing ne doit pas automatiquement devenir un groupe tarifaire.
| Sens Customer dans la source | Structure CS-Cart à envisager | Relation essentielle |
|---|---|---|
| Acheteur individuel | Utilisateur Customer et adresses | Identité, connexion, adresses et Orders restent reliées. |
| Niveau tarifaire | Groupe utilisateur et relation de tarification Product | L’appartenance du Customer influence les valeurs commerciales prévues. |
| Segment d’accès | Groupe utilisateur et restriction Product/Category | La visibilité reste distincte d’un simple étiquetage descriptif. |
| Employé d’un Vendor | Relation d’utilisateur Vendor | L’utilisateur appartient au bon vendeur, pas à la population Customers. |
| Compte entreprise externe | Données de profil personnalisées, extension ou identifiant externe | Les acheteurs restent reliés à l’organisation de référence lorsque nécessaire. |
L’historique des Orders et la segmentation Customers doivent rester distincts. Une Order historique peut conserver le prix et la taxe appliqués au moment de l’achat ; elle ne doit pas être recalculée à partir du groupe actuel du Customer après migration.
Les Orders préservent un instantané commercial et marketplace
Une Order CS-Cart peut contenir l’identité du Customer ou de l’invité, les adresses, les références Product et variation, les options choisies, quantités, prix, remises, taxes, livraison, libellés de paiement, statuts, notes, fichiers, promotions et propriété marketplace. Dans Multi-Vendor, les structures d’Orders liées aux vendeurs et les commissions ajoutent une couche supplémentaire.
Les lignes d’Order sont des instantanés historiques. Le nom, le prix, le stock, les valeurs de features ou le Vendor actuel d’une variation peuvent changer plus tard. L’Order doit néanmoins continuer à expliquer ce que le Customer a acheté. De la même manière, les anciens libellés de paiement et de livraison doivent rester lisibles même si les méthodes actives du parcours de commande relèvent de la configuration de la boutique cible.
| Élément d’Order | Relation historique à conserver |
|---|---|
| Ligne Product | Identité Product ou variation, code, quantité, prix et options choisies. |
| Promotion | Montant de remise et contexte de la règle source ou du coupon lorsqu’il existe. |
| Taxe | Montant et libellé de taxe appliqués lors de l’achat. |
| Expédition | Transporteur, méthode, suivi, quantité traitée et contexte vendeur lorsqu’il existe. |
| Paiement | Libellé historique de la méthode et référence de transaction lorsqu’elle existe. |
| Contexte Vendor | Propriété vendeur, commission, versement ou relation d’Order Vendor. |
| Statut | Sens du cycle de vie source utilisé par les équipes service client, traitement des commandes et reporting. |
La boutique cible n’a pas besoin de reproduire chaque ancien processus devenu obsolète pour préserver l’historique, mais l’Order importée doit rester intelligible. Un total sans configuration Product, vendeur, remise, taxe ni contexte de statut n’est pas équivalent à l’historique commercial d’origine.
Contenu, langues, URLs et présentation des storefronts
Le contenu d’un storefront CS-Cart peut comprendre des Pages, des entrées Blog lorsqu’une extension le permet, les descriptions Product et Category, bannières, menus, blocks, layouts, thèmes, métadonnées, noms SEO et valeurs localisées. Ces éléments n’ont pas tous le même propriétaire et ne doivent pas être regroupés dans une entité de contenu générique.
Les descriptions Product et Category appartiennent au catalogue. Les Pages et la navigation ont leur propre hiérarchie et leur propre périmètre de storefront. Les blocks et layouts décrivent la présentation. Les noms SEO et redirections déterminent les routes. Les valeurs linguistiques peuvent être stockées comme traductions associées à une entité partagée plutôt que comme Products ou Categories indépendants.
| Élément source | Couche cible dans CS-Cart | Limite à préserver |
|---|---|---|
| Traduction Product ou Category | Valeur catalogue propre à une langue | Une seule entité reste reliée à plusieurs valeurs localisées. |
| Page d’information | Hiérarchie de Pages et affectation au storefront | Contenu, relation parent, accès et route restent distincts. |
| Élément de menu/navigation | Structure de menu ou block du storefront | La navigation ne se déduit pas de la seule existence d’une Category. |
| Bannière ou block promotionnel | Enregistrement de présentation ou marketing | Le placement visuel reste distinct des données Product sous-jacentes. |
| Ancienne URL | Nom SEO et relation de redirection | Le chemin source et la destination restent explicites. |
| Layout du thème | Configuration de présentation cible | La structure du thème ne doit pas être confondue avec des données de contenu transportables. |
Cette séparation est particulièrement importante avec plusieurs boutiques ou une marketplace, où un même contenu peut être global, propre à un storefront, à un Vendor ou à une langue.
Extensions CS-Cart, tables personnalisées et intégrations possèdent des données supplémentaires
Les extensions de plateforme CS-Cart peuvent ajouter des champs Product, du fonctionnement marketplace, des données de fidélité, abonnements, réservations, avis, points de récompense, informations de paiement ou livraison, flux externes et processus personnalisés. Leurs enregistrements peuvent vivre dans des tables propres à l’extension et dépendre de hooks, réglages, tâches planifiées ou services externes.
Dans CS-Cart, un add-on désigne une extension de plateforme, et non une étiquette générique pour des champs Product ordinaires. Le périmètre de migration doit identifier l’extension, ses types d’enregistrements et les enregistrements principaux qu’elle étend.
| Propriétaire des données | Enregistrements typiques | Exigence de transposition |
|---|---|---|
| Noyau CS-Cart | Products, Categories, features, options, variations, utilisateurs, Orders, storefronts | Préserver le sens des types d’enregistrements natifs et de leurs relations. |
| Couche Multi-Vendor | Vendors, utilisateurs Vendor, Products vendeurs, commissions, versements | Maintenir la propriété vendeur à travers le catalogue et les Orders. |
| Extension CS-Cart | Avis, récompenses, abonnements, réservations, champs Product spéciaux | Examiner séparément le schéma de l’extension et les capacités de la cible. |
| Développement personnalisé | Tables, champs, statuts ou enregistrements de processus spécifiques | Définir une destination explicite pour chaque relation métier active. |
| Système externe | Article ERP, compte CRM, entrepôt, listing marketplace, référence comptable | Préserver les identifiants nécessaires au rapprochement et à la reconnexion. |
Les formats d’import/export ne définissent pas le modèle de données complet. Un champ peut être exportable sans transporter la configuration ou le processus de l’extension associée. À l’inverse, un petit identifiant externe peut être essentiel pour reconnecter l’enregistrement migré à l’ERP, au PIM, au WMS, au CRM ou à une marketplace.
Décider la transposition à partir des relations
Une mise en correspondance fiable avec CS-Cart détermine d’abord le propriétaire de chaque valeur source avant de choisir son champ cible.
| Modèle source | Question de transposition | Conséquence d’une mauvaise attribution |
|---|---|---|
| Couleur/taille avec SKU enfants | S’agit-il d’un groupe de variations fondé sur des features ? | L’identité Product indépendante, le stock ou la visibilité catalogue est perdu. |
| Gravure ou emballage cadeau | S’agit-il d’une option sans stock indépendant ? | Un choix de service est représenté à tort comme une variation vendable. |
| Spécification technique | S’agit-il d’une feature, éventuellement utilisée dans un filtre ? | Découverte et comparaison deviennent incohérentes. |
| Plusieurs boutiques régionales | S’agit-il de storefronts indépendants ou de branches marketplace ? | Les périmètres Product, Category, Customer et configuration se mélangent. |
| Fournisseur ou vendeur | Est-ce une information d’approvisionnement ou une propriété Vendor ? | Products, utilisateurs, Orders, commissions et versements vendeurs sont perdus ou inventés. |
| Niveau Customer | S’agit-il d’un groupe utilisateur, d’un segment CRM externe ou d’une relation entreprise ? | Prix et accès sont rattachés à la mauvaise structure Customer. |
| Champ d’extension | Quel module CS-Cart en est propriétaire et quel enregistrement étend-il ? | La donnée est copiée sans la capacité qui l’interprète. |
La migration vers CS-Cart préserve le sens lorsque caractéristiques du catalogue, choix d’achat, variations, périmètre des storefronts, propriété Vendor, segmentation Customers, historique Orders, contenu et données d’extensions restent distincts tout en conservant leurs relations.
Conclusion
CS-Cart n’est pas un schéma plat limité aux Products et Orders. Les features décrivent les Products, les options représentent des choix séparables et les variations restent des Products regroupés selon certaines features. Les storefronts peuvent contrôler différemment le périmètre du catalogue et des Customers entre Store Builder et Multi-Vendor. Les Vendors ajoutent une propriété marketplace, tandis que les groupes utilisateurs influencent le traitement commercial. Les Orders dépendent du contexte historique des lignes, promotions, taxes, paiements, expéditions, statuts et vendeurs. Les extensions et systèmes externes peuvent posséder des enregistrements hors des types de données principaux.
Le meilleur périmètre de migration rattache chaque valeur source à la structure CS-Cart qui contrôle le même sens métier. Cela protège la découverte des Products, les choix d’achat, la responsabilité vendeur, le traitement des Customers, les Orders historiques, les storefronts localisés et la continuité des intégrations sans forcer des enregistrements différents dans des champs seulement similaires en apparence.
Questions fréquentes
Quelle est la différence entre une feature et une option dans CS-Cart ?
Une feature est une propriété indissociable du Product, comme la marque, le matériau ou l’ISBN, et peut servir au filtrage ou à la comparaison. Une option est un choix séparé proposé à l’acheteur, comme une gravure, un emballage cadeau ou une garantie ; elle peut modifier le prix ou le poids mais ne possède pas de stock indépendant.
Quand les SKU enfants de la source doivent-ils devenir des Product Variations CS-Cart ?
Lorsqu’un enfant reste un Product et que le groupe varie selon certaines valeurs de features. La correspondance doit conserver le SKU enfant, le stock, le prix, l’image et les relations de visibilité catalogue plutôt que de regrouper les enfants dans une simple liste d’options.
Une boutique source doit-elle toujours devenir un storefront CS-Cart ?
Non. Dans Store Builder, un storefront peut être une boutique indépendante avec son propre catalogue et ses Customers. Dans Multi-Vendor, il peut représenter une branche régionale d’une marketplace comprenant certains Vendors et une configuration régionale. La limite opérationnelle de la source détermine le bon modèle.
Chaque fournisseur source doit-il devenir un Vendor CS-Cart ?
Non. Un Vendor possède des Products marketplace et des enregistrements commerciaux liés au vendeur. Un fabricant, une marque, un code fournisseur ou une source d’approvisionnement peuvent rester des données descriptives ou externes lorsqu’ils ne représentent pas un compte vendeur.
Pourquoi les données appartenant aux extensions CS-Cart doivent-elles rester séparées des données principales ?
Une extension peut posséder ses propres tables, statuts, paramètres et relations. Copier ses champs dans un Product ou Customer principal ne préserve pas le processus qui donne un sens à ces champs.
Comment transposer un catalogue marketplace partagé ?
Il faut séparer l’identité Product commune des offres propres aux Vendors, notamment prix, stock, propriété et responsabilité sur les Orders. Que la boutique cible utilise des Products communs ou une autre structure marketplace, ces couches ne doivent pas être aplaties en plusieurs Products sans relation.