Migrer des données vers Jumpseller exige davantage que de faire correspondre des colonnes source à des champs cibles. Jumpseller sépare le Product parent, ses variantes réellement vendables, les personnalisations saisies par le Customer, les champs personnalisés descriptifs, l’appartenance aux Categories, la navigation, le stock, l’identité du Customer, les Orders historiques, le contenu de la boutique et les enregistrements d’intégration en relations distinctes. Une plateforme source peut stocker plusieurs de ces significations dans un même système d’attributs ou une même table d’extension.
La question centrale n’est donc pas de savoir si une valeur source peut être copiée, mais quel objet Jumpseller doit en devenir le propriétaire et quelle relation doit rester intacte. La taille et la couleur peuvent définir des variantes portant du stock ; un texte de gravure peut rester une saisie liée à une ligne d’Order ; la marque peut devenir un champ personnalisé utilisé pour le filtrage ; une Category peut organiser les Products sans reproduire l’ancien menu ; et un identifiant externe peut rester indispensable même s’il n’est jamais visible pour les clients.
Les Products sont des enregistrements parents du catalogue, pas toujours des unités vendables complètes
Un Product Jumpseller fournit l’identité catalogue partagée d’une offre vendable. Il peut porter le nom, les descriptions, les images, les relations avec les Categories, le statut, les valeurs tarifaires par défaut, les paramètres de stock, les champs SEO, les options, les champs personnalisés et d’autres informations de merchandising. Lorsque les options génèrent des variantes, le Product parent ne détient toutefois plus à lui seul toutes les valeurs commerciales.
Les plateformes source combinent souvent différemment les données du Product maître et celles de l’unité réellement vendable. Une source peut stocker chaque taille et chaque couleur comme un Product indépendant. Une autre peut stocker un Product accompagné de SKU enfants. Une troisième peut conserver un Product parent tout en plaçant les images, le coût, le stock et les ajustements de prix dans une matrice détenue par une application. La destination Jumpseller doit préserver cette distinction parent-enfant au lieu d’aplatir tous les enregistrements au même niveau.
| Modèle de catalogue source | Interprétation dans Jumpseller | Conséquence sur les relations |
|---|---|---|
| Un enregistrement pour chaque taille et couleur | Product parent avec variantes générées par les options lorsque les enregistrements représentent une même famille commerciale | Les descriptions et Categories communes peuvent rester au niveau du parent tandis que SKU, stock, prix, poids et images peuvent appartenir aux variantes. |
| Product parent avec SKU enfants | Product accompagné de combinaisons de variantes | Les identifiants enfants existants doivent rester associés à la combinaison d’options correspondante. |
| Product simple sans choix sélectionnable | Product portant ses propres valeurs commerciales | Il n’est pas nécessaire de créer artificiellement une couche de variantes simplement parce que la source expose une table d’attributs. |
| Article numérique ou non expédié | Product dont le sens du traitement et du stock diffère d’un article physique | Les références de livraison, fichiers et attentes d’expédition doivent rester distincts des données de stock ordinaires. |
| Famille Product générée par une application | Enregistrements Product plus relations détenues par l’application | Les valeurs descriptives peuvent rejoindre des champs standard, tandis que les règles générées ou enregistrements liés restent détenus par l’application source ou un autre système cible. |
Le statut Product porte lui aussi du sens. Un état source tel que actif, masqué, brouillon, archivé, arrêté ou disponible en commande différée ne correspond pas nécessairement à un unique statut Jumpseller. La représentation cible doit distinguer visibilité publique, possibilité d’achat, disponibilité du stock et conservation saisonnière au lieu de réduire tous les états à activé ou désactivé.
Options, variantes, saisies Customer et champs personnalisés sont des structures différentes
Les Product Options de Jumpseller peuvent générer de véritables variantes, mais toute valeur ressemblant à une option dans la source ne doit pas rejoindre une grille de variantes. Des choix comme la taille ou la couleur peuvent produire des combinaisons dotées de leur propre SKU, prix, stock, poids, coût et relation d’image. D’autres saisies Product recueillent un texte, un message plus long, un fichier ou une sélection facultative sans créer de combinaison portant un stock distinct.
Les Custom Product Fields ont une autre fonction. Ils décrivent un Product et peuvent contribuer à sa découverte lorsqu’ils sont représentés par des valeurs sélectionnables adaptées. La marque, la matière, la famille olfactive, le type de compatibilité, la saison ou une spécification technique peuvent appartenir à cette couche lorsqu’ils ne créent pas d’unités vendables indépendantes.
| Sens métier | Structure Jumpseller appropriée | Ce qui ne doit pas être perdu |
|---|---|---|
| Taille ou couleur avec stock indépendant | Product Option générant des variantes | Identité de combinaison, SKU, stock, prix, poids et relations d’images |
| Gravure, dédicace ou message court | Champ de texte saisi par le Customer | La valeur choisie doit rester associée à la ligne d’Order achetée, et non à la définition du Product parent. |
| Instructions détaillées de personnalisation | Zone de texte | Une saisie libre de l’acheteur ne doit pas devenir une métadonnée réutilisable du catalogue. |
| Illustration ou document fourni par l’acheteur | Champ fichier | La référence du fichier appartient au contexte de l’achat plutôt qu’au stock. |
| Emballage facultatif ou supplément payant | Sélection ne créant pas de variante lorsque ce modèle convient | L’influence sur le prix et la valeur choisie sur la ligne d’Order doivent rester distinctes d’une variante stockée. |
| Marque, matière, arôme, classe de compatibilité ou spécification | Custom Product Field | Le descripteur peut informer le Product ou alimenter les filtres sans multiplier les variantes. |
| Règle de configurateur conditionnelle | Relation détenue par une application ou un système externe | Les dépendances, formules et règles d’affichage conditionnel ne sont pas équivalentes à de simples valeurs d’option. |
Cette distinction évite l’explosion artificielle du nombre de variantes. Un catalogue source qui stocke couleur, taille, texte de monogramme, choix de garantie et spécifications techniques dans une seule table d’attributs peut nécessiter quatre représentations différentes dans Jumpseller. Traiter les cinq dimensions comme des variantes crée des combinaisons qui ne sont pas de véritables unités de stock ; traiter les cinq comme des champs personnalisés supprime au contraire la possibilité de sélectionner et stocker les vraies variantes.
Categories, navigation et filtres forment des relations de découverte distinctes
Les Categories Jumpseller organisent les Products et peuvent former des hiérarchies parent-enfant. Elles peuvent également porter des noms, descriptions, images, ordres, informations SEO et relations d’appartenance des Products. Les enregistrements Category sont donc importants pour la structure du catalogue, mais ils ne reproduisent pas à eux seuls l’ensemble du parcours de navigation de la boutique.
La navigation peut placer des Categories dans le menu principal, un menu de Category ou le pied de page, et imbriquer ces entrées indépendamment de la relation Product-to-Category. Une taxonomie source peut aussi inclure des regroupements internes de merchandising, des collections de campagne, des marques, des facettes de recherche ou des libellés opérationnels masqués. Chaque regroupement doit recevoir un sens cible explicite.
| Regroupement source | Propriétaire possible dans Jumpseller | Décision de représentation |
|---|---|---|
| Famille Product permanente | Category et appartenance des Products | Préserver la hiérarchie et l’appartenance comme structure de catalogue. |
| Branche principale de navigation | Entrée de navigation pointant vers une Category ou une autre page | Garder le routage et l’emplacement du menu séparés de l’existence de la Category. |
| Facette marque ou matière | Custom Product Field et relation de filtrage | Utiliser un descripteur lorsque la valeur regroupe des Products sans définir un choix achetable. |
| Facette taille ou couleur | Product Option et relation de filtrage | Conserver un vocabulaire cohérent afin que des choix équivalents puissent alimenter le filtrage. |
| Campagne saisonnière | Category, contenu d’atterrissage, contexte promotionnel ou lien de thème | Choisir l’objet qui détient réellement la campagne au lieu de créer par défaut une taxonomie permanente. |
| Libellé interne de reporting | Champ back-office ou classification d’un système externe | Ne pas exposer un code interne dans la navigation simplement parce qu’il provient d’une table Category. |
Les filtres Jumpseller peuvent s’appuyer sur des Product Options générant des variantes et sur des champs personnalisés sélectionnables. La cohérence des noms devient donc une partie du modèle de données. « Color », « Colour » et « Finish » peuvent représenter le même concept métier dans la source mais devenir trois filtres distincts s’ils sont traités comme des champs sans relation. À l’inverse, des valeurs portant des libellés similaires peuvent devoir rester séparées lorsque l’une définit une variante et l’autre n’est que descriptive.
Prix et stock peuvent appartenir au Product, à la variante, au contexte Customer ou à un emplacement
Une valeur de prix ou de stock n’a pas de sens sans son propriétaire. Un Product simple peut détenir un prix et une quantité. Un Product avec variantes peut déplacer vers chaque combinaison le SKU, le prix, le coût, le poids, les images et le stock. Une tarification propre à certains Customers peut créer une relation distincte entre Customer Category et liste de prix. Des tarifs par volume peuvent ajouter des seuils de quantité sans changer l’identité du Product de base.
Le stock peut aussi dépendre d’un emplacement. Lorsqu’un stock par emplacement existe, la destination doit préserver la relation entre Product ou variante, emplacement de stock, quantité et état de disponibilité. Une quantité totale unique ne permet pas de représenter quel emplacement peut traiter l’article ni quelle intégration fait autorité.
| Valeur commerciale | Propriétaire possible | Pourquoi la propriété compte |
|---|---|---|
| Prix de vente de base | Product ou variante | Un prix parent ne peut pas remplacer des prix distincts pour de vraies combinaisons. |
| Prix barré ou prix de référence | Product ou variante | La valeur de référence doit rester attachée à la même unité vendable que le prix actif. |
| Coût | Product ou variante | Les données de marge deviennent trompeuses si le coût d’une variante est remonté au parent. |
| Palier de quantité | Product ou relation de tarification | Le seuil et le prix unitaire doivent rester liés. |
| Prix propre à une catégorie de Customers | Customer Category et relation de liste de prix | Le prix dépend de la classification de l’acheteur et n’est pas un champ Product universel. |
| Stock | Product ou variante à un emplacement | La quantité doit rester liée à la bonne unité vendable et au bon emplacement de stock. |
| État de stock illimité | Règle de disponibilité du Product ou de la variante | Une quantité vide ou égale à zéro n’équivaut pas nécessairement à un stock illimité. |
Les mouvements historiques de stock sont également distincts du stock actuel. Les Orders peuvent modifier le stock à mesure que leur statut évolue, mais un Order importé constitue un élément historique et non une instruction visant à rejouer le mouvement de stock d’origine. La destination doit conserver séparément l’état de stock final souhaité et le contexte historique des Orders.
Customers, Customer Categories, adresses et relations marketing doivent conserver des sens séparés
Un enregistrement Customer Jumpseller représente l’identité du compte et du contact, mais un profil Customer source peut contenir davantage qu’un nom et une adresse e-mail. Les adresses, identifiants fiscaux, informations d’entreprise, consentements marketing, état du compte, notes, segmentation, identifiants CRM externes et appartenance à une Customer Category peuvent chacun avoir un propriétaire différent.
| Élément de compte source | Sens cible dans Jumpseller | Limite de la relation |
|---|---|---|
| Nom et e-mail | Identité Customer et informations de contact | L’identité ne doit pas être dupliquée simplement parce qu’une personne possède plusieurs Orders. |
| Adresses de facturation et de livraison | Contexte d’adresse lié au Customer ou à un Order historique | Les adresses du compte actuel et les instantanés d’Order peuvent légitimement différer. |
| Informations d’entreprise ou fiscales | Champ Customer, champ d’adresse ou enregistrement métier externe | La valeur appartient à l’objet qui l’utilise dans le contexte du compte ou de la transaction. |
| Groupe de Customers ou niveau de gros | Customer Category et contexte associé de prix ou d’accès lorsqu’il est représenté | Un segment commercial n’est pas seulement un libellé lorsqu’il change les prix ou les droits. |
| Consentement newsletter | Relation marketing ou plateforme marketing externe | Le sens et la source du consentement doivent rester distincts de la simple existence d’un compte. |
| Solde de fidélité ou état d’adhésion | Enregistrement d’application ou de système externe | Un enregistrement Customer seul ne recrée pas la relation avec le programme. |
| Identifiant CRM ou ERP | Identifiant externe stable | La clé doit rester attachée à la même personne ou entreprise que celle utilisée par le système externe. |
Les données de mot de passe nécessitent une interprétation séparée. Le hash d’un mot de passe source peut utiliser un mécanisme impossible à réutiliser dans Jumpseller. Dans ce cas, l’identité du Customer reste valable même si les informations d’authentification exigent un autre parcours d’accès au compte. Le modèle de données ne doit pas considérer une adresse e-mail migrée comme la preuve que les anciens identifiants de connexion sont portables.
Les Orders préservent un contexte commercial historique, pas la configuration actuelle de la boutique
Un Order Jumpseller rassemble l’identité du Customer ou de l’invité, les lignes d’Order, variantes sélectionnées, valeurs d’options saisies par le Customer, adresses, prix, remises, taxes, frais d’expédition, état du paiement, état de traitement, notes, horodatages et références externes. Ces valeurs constituent un instantané historique de ce qui s’est produit au moment de l’achat.
Cet instantané doit rester distinct des Products et paramètres actuels. Une ancienne ligne d’Order peut conserver un titre Product, un SKU, des options sélectionnées et un prix même si le Product actif a ensuite été renommé, repricé, désactivé ou supprimé. Des frais d’expédition historiques peuvent montrer ce qui a été payé sans définir le mode d’expédition actuel. Une référence de paiement peut servir au rapprochement sans configurer la passerelle active.
| Composant d’Order | Sens historique | Relation dans la destination |
|---|---|---|
| Identité Product de la ligne d’Order | Ce qui a été acheté à ce moment-là | Préserver si possible la référence Product ou variante tout en conservant le texte de l’instantané. |
| Options sélectionnées et saisies personnalisées | Choix de l’acheteur pour cette ligne | Les conserver avec la ligne d’Order même si la définition actuelle du Product change. |
| Prix, remise et taxe | Instantané commercial | Ne pas recalculer l’historique à partir des paramètres Product ou fiscaux actuels. |
| Adresses de facturation et de livraison | Adresse au moment de la transaction | Les conserver séparément des modifications ultérieures du profil Customer. |
| État et référence du paiement | Contexte historique du paiement | L’enregistrement ne détient pas la configuration actuelle de la passerelle. |
| État de traitement et suivi | Contexte historique de livraison | L’enregistrement ne définit pas les règles actuelles du transporteur ou de l’entrepôt. |
| Canal source ou identifiant externe | Clé de rapprochement et d’intégration | Préserver la clé lorsqu’un autre système l’utilise pour identifier l’Order. |
Les Orders invités, annulés, partiellement traités, remboursés et ceux contenant des saisies personnalisées exposent des relations qu’un simple Order payé ne montre pas. Le modèle cible doit prendre en compte ces états sans transformer des enregistrements historiques en configuration active des processus.
CMS Pages, Blog Posts, URL et contenu de thème ont des propriétaires différents
Le contenu de la boutique Jumpseller peut inclure des CMS Pages, Blog Posts, descriptions Product et Category, entrées de navigation, bannières, sections de thème, images, contenus de politique et champs SEO. Une plateforme source peut stocker tous ces éléments dans un même page builder ou une même table de contenu, alors que Jumpseller les répartit entre des objets distincts.
| Contenu source | Interprétation dans Jumpseller | Distinction de propriété |
|---|---|---|
| À propos, contact, politique ou guide | CMS Page | Le contenu stable de la page et son routage restent distincts de son placement dans les menus et de la mise en page du thème. |
| Article éditorial ou annonce | Blog Post | Date de publication, contexte d’auteur, Categories ou tags, médias et permalink peuvent différer d’une CMS Page. |
| Texte Product ou Category | Description détenue par le catalogue | Le contenu appartient à l’objet catalogue et non à une page générique séparée. |
| En-tête, pied de page, bannière ou section d’accueil | Contenu de thème ou navigation | Le placement visuel n’est pas le même objet que l’enregistrement métier sous-jacent. |
| Meta title, meta description ou permalink | Relation SEO et de routage de l’objet propriétaire | Les métadonnées doivent rester reliées au Product, à la Category, à la CMS Page ou au Blog Post qu’elles décrivent. |
| Redirection ou ancien chemin | Relation de routage | L’ancienne URL reste utile même si l’objet cible reçoit un autre permalink. |
Le code du thème peut lire des champs Product, champs personnalisés, Categories, menus et sorties d’applications, mais il ne détient pas ces enregistrements. Reproduire l’ancien balisage ne remplace donc pas la représentation correcte des données sous-jacentes. De même, copier le corps d’un contenu sans ses liens, médias, route et propriétaire peut créer une page présente mais qui ne fonctionne plus comme partie intégrante de la boutique.
Applications, API, webhooks et identifiants externes forment une couche de données périphérique
Jumpseller peut échanger des données avec des systèmes externes au moyen d’applications, d’API et de webhooks. Une boutique source peut dépendre d’un ERP pour le stock, d’un CRM pour la classification des Customers, d’un service de traitement pour les états d’expédition, d’une marketplace pour les annonces ou d’une application pour les abonnements, réservations, avis, fidélité, bundles ou configurations Product.
Ces enregistrements doivent être classés selon leur propriétaire plutôt que selon leur visibilité. Une valeur affichée sur une page Product peut faire autorité dans un PIM externe. Une quantité visible dans Jumpseller peut être synchronisée depuis un ERP. Un tag Customer peut être dérivé d’un CRM. Un identifiant d’annonce marketplace peut désigner une offre de canal et non le Product principal.
| Enregistrement d’intégration | Propriétaire probable | Exigence de représentation |
|---|---|---|
| Identifiant ERP du Product ou de la variante | Relation ERP et catalogue | Préserver la clé sur le Product ou la variante correspondant utilisé pour la synchronisation. |
| Identifiant d’entrepôt ou d’emplacement | Système de stock ou de traitement | Garder l’identité de l’emplacement distincte d’une simple quantité de stock. |
| Identifiant CRM du Customer | Relation CRM et Customer | Éviter de créer une nouvelle clé sans relation pour la même personne ou entreprise. |
| Identifiant d’annonce marketplace | Annonce du canal de vente | Ne pas confondre l’annonce avec le Product ou la variante canonique. |
| Abonnement, réservation ou enregistrement de fidélité créé par une application | Domaine de l’application | Maintenir explicites les références vers le Product, le Customer et l’Order parents. |
| État de synchronisation webhook | Processus d’intégration | Traiter horodatages, identifiants d’événement et curseurs comme données opérationnelles d’intégration, pas comme contenu de boutique. |
Une destination cohérente n’a pas besoin de reproduire chaque table source. En revanche, elle doit définir un propriétaire pour chaque identifiant et relation utiles à la gestion du catalogue, à la continuité Customer, au rapprochement historique ou à la synchronisation externe.
Une carte de représentation Jumpseller doit résoudre le sens avant le stockage
Le modèle de données Jumpseller peut être résumé comme un ensemble de décisions de propriété. Les Products parents détiennent le merchandising partagé. Les variantes détiennent les combinaisons vendables. Les saisies du Customer appartiennent à l’interaction avec un Product puis à une ligne d’Order. Les champs personnalisés décrivent les Products. Les Categories organisent l’appartenance au catalogue. La navigation détient la position dans les menus. Les Customers détiennent l’identité et le contexte de compte. Les Orders détiennent les instantanés historiques des transactions. Les applications et systèmes externes détiennent leurs enregistrements et identifiants spécialisés.
| Question posée par la source | Décision de représentation |
|---|---|
| La valeur crée-t-elle une unité dotée d’un prix ou d’un stock indépendant ? | La représenter au niveau de la variante plutôt que comme champ personnalisé descriptif. |
| La valeur est-elle saisie par l’acheteur pour un achat précis ? | La conserver comme saisie Customer et la préserver avec la ligne d’Order. |
| La valeur décrit-elle plusieurs Products sans créer de variantes ? | Utiliser un champ personnalisé ou une relation de classification appropriée. |
| Le regroupement organise-t-il les Products ou contrôle-t-il la navigation ? | Séparer l’appartenance à une Category de la position dans les menus. |
| La valeur correspond-elle à une configuration actuelle ou à un élément historique ? | Garder la configuration active du catalogue et des opérations séparée des instantanés d’Order. |
| Un autre système utilise-t-il cet identifiant comme clé ? | Le préserver sur l’entité cible représentant le même objet métier. |
| L’enregistrement appartient-il à une application plutôt qu’au cœur de Jumpseller ? | Préserver la relation avec l’application au lieu de forcer les données dans un champ standard sans rapport. |
Résoudre ces questions permet d’obtenir une boutique capable de gérer les données migrées de façon cohérente. La destination reflète ce que signifie chaque enregistrement, quel objet le détient et comment il se relie au reste de l’environnement Jumpseller.
Conclusion
Jumpseller modifie la représentation des données en séparant Products parents, variantes, saisies Customer, champs personnalisés, Categories, filtres, navigation, stock, Customers, Orders, contenu et intégrations en relations distinctes. Une table d’attributs, une table Customer ou un enregistrement de page builder dans la source peut donc nécessiter plusieurs objets cibles au lieu d’une correspondance directe champ à champ.
Une migration cohérente préserve la propriété derrière chaque valeur. Les Products restent reliés à de vraies variantes vendables, les champs descriptifs restent distincts des choix de l’acheteur, les Categories restent séparées de la navigation, l’identité Customer reste distincte des programmes d’applications, les Orders restent des instantanés historiques et les identifiants externes restent attachés aux systèmes et entités qui en dépendent.
Questions fréquentes
Les Product Options et les champs personnalisés de Jumpseller sont-ils la même chose ?
Non. Les Product Options peuvent créer des variantes ou recueillir une saisie de l’acheteur selon leur type. Les champs personnalisés décrivent le Product et peuvent contribuer au filtrage lorsqu’ils sont représentés correctement. Une valeur doit être affectée selon qu’elle crée une combinaison vendable, recueille un choix ponctuel de l’acheteur ou décrit simplement le Product.
Quand un attribut source doit-il devenir une variante Jumpseller ?
Il doit participer à une variante lorsque le choix identifie une véritable unité vendable possédant son propre sens commercial ou de stock, par exemple un SKU, un prix, une quantité, un poids, un coût ou une relation d’image distincts. Les valeurs descriptives et les personnalisations libres doivent rester en dehors de la grille de variantes.
Les Categories migrées reproduisent-elles automatiquement l’ancien menu ?
Non. Les Categories détiennent le regroupement des Products et leur hiérarchie, tandis que la navigation détient le placement dans les menus et la présentation des routes. Une Category peut exister sans apparaître dans le menu principal, et un menu peut contenir des liens vers des CMS Pages, Blog Posts, pages de campagne ou autres destinations.
Comment les Orders historiques doivent-ils rester liés aux Products actuels ?
Les Orders historiques doivent conserver leurs instantanés de ligne, options sélectionnées, prix, adresses, statuts et références externes. Lorsqu’une relation fiable avec un Product ou une variante existe, elle peut être conservée, mais les modifications ultérieures du catalogue ne doivent pas réécrire ce que l’Order enregistrait au moment de l’achat.
Que devient une donnée d’application source qui n’a aucun champ natif dans Jumpseller ?
L’enregistrement doit rester classé sous son véritable propriétaire, c’est-à-dire l’application ou le système externe concerné. Les références parentes importantes et les identifiants stables peuvent être conservés dans une structure cible appropriée, tandis que le fonctionnement spécialisé reste distinct des champs Product, Customer ou Order ordinaires.
Un même champ source peut-il avoir différentes destinations Jumpseller selon les Products ?
Oui. Un champ source nommé « Size », « Type » ou « Status » peut porter un sens métier différent selon les familles de Products. La destination dépend de sa fonction réelle : créer une variante, décrire le Product, contrôler la disponibilité, recueillir une saisie Customer, alimenter un filtre ou appartenir à un processus externe.