Les migrations vers PrestaShop échouent le plus souvent lorsque les enregistrements sont présents mais que leurs relations de boutique, de langue, de combinaison, de module ou de contexte commercial ont changé de sens. La prévention doit donc suivre la relation opérationnelle portée par chaque enregistrement plutôt que se limiter au nombre de données transférées. Les dix pièges ci-dessous couvrent les schémas d’échec les plus fréquents qui peuvent laisser un catalogue apparemment complet tout en dégradant l’achat, la découverte, le service ou les intégrations.
Piège 1 : aplatir les combinaisons dans des champs Product ordinaires
Ce qui se passe mal
Un Product source peut arriver avec son enregistrement principal intact alors que la structure des variations vendables est affaiblie. Les combinaisons PrestaShop portent les différences d’achat qui distinguent un choix vendable d’un autre, tandis que les caractéristiques décrivent les Products et que les champs de personnalisation recueillent des valeurs fournies par l’acheteur. Les traiter comme interchangeables peut créer des Products en double, faire disparaître des prix de variants, attribuer le stock au mauvais niveau ou afficher des informations sans préserver le choix d’achat prévu.
Signaux d’alerte précoces
Le signal n’est pas un faible nombre de Products. C’est l’écart entre ce que les acheteurs peuvent sélectionner et ce que les équipes peuvent administrer. Les enregistrements les plus risqués sont les Products dont les options modifient SKU, prix, poids, image, disponibilité ou stock.
| Signal | Signification probable | Risque immédiat |
|---|---|---|
| Chaque option est devenue une caractéristique | Les structures descriptives et vendables ont été fusionnées | Le Product peut afficher des choix qui ne déterminent pas l’article acheté |
| Chaque combinaison est devenue un Product séparé | La relation Product parent → combinaison a été aplatie | Categories, SEO et merchandising peuvent se fragmenter |
| Le stock n’existe qu’au niveau du Product principal | Le stock propre aux combinaisons n’a pas été conservé | Des choix vendables peuvent être survendus ou apparaître indisponibles |
Prévention
Classifiez chaque option source selon sa fonction métier avant toute mise en correspondance. Un choix qui modifie le SKU acheté relève de la logique de combinaison ; une valeur servant à la comparaison relève des caractéristiques ; le texte ou les fichiers fournis par l’acheteur relèvent de la personnalisation. Incluez des Products représentatifs avec plusieurs dimensions d’option, impacts de prix, images et règles de stock. Conservez les identifiants externes stables lorsqu’un ERP ou système d’entrepôt reconnaît la combinaison plutôt que le seul Product parent.
Exemple de recommandation
Pour une veste vendue par taille et couleur, conservez un seul Product avec des combinaisons pour les choix vendables. Préservez le SKU de la combinaison, son impact de prix, la relation avec l’image et sa position de stock. Gardez « waterproof rating » comme caractéristique et un message de broderie facultatif comme personnalisation au lieu de créer un Product séparé pour chaque valeur.
Condition de réussite
L’acheteur peut sélectionner tous les choix requis, le bon SKU et le bon prix sont ajoutés au panier, le stock de combinaison évolue indépendamment lorsque c’est prévu, et les équipes peuvent relier chaque choix vendable au même identifiant opérationnel que celui utilisé par les systèmes connectés.
Piège 2 : perdre la propriété multiboutique tout en conservant les enregistrements
Ce qui se passe mal
Le multiboutique PrestaShop peut rendre un même enregistrement visible, tarifé, traduit ou configuré différemment selon la boutique ou le groupe de boutiques. Une migration qui conserve Product, Category, Customer ou enregistrement CMS mais perd son contexte de boutique peut exposer le mauvais catalogue, fusionner des contenus régionaux ou affecter des enregistrements partagés à une boutique où ils n’étaient jamais destinés à apparaître.
Signaux d’alerte précoces
Le risque est élevé lorsque les équipes parlent de « la boutique PrestaShop » comme s’il n’existait qu’une seule vitrine. Des différences de domaine, langue, devise, catalogue, thème, tarification ou responsabilité opérationnelle indiquent que le contexte de boutique fait partie du sens des données.
| Domaine | Question multiboutique | Échec si ignoré |
|---|---|---|
| Products et Categories | Partagés globalement ou affectés sélectivement ? | La mauvaise boutique peut publier ou masquer l’enregistrement |
| Prix et promotions | Partagés ou propres à une boutique ? | La logique commerciale régionale peut être aplatie |
| CMS et traductions | Contenu commun ou localisé par boutique ? | Un marché peut écraser le contenu d’un autre |
Prévention
Créez une matrice de propriété par boutique pour chaque famille d’enregistrements incluse au périmètre. Distinguez les données réellement partagées des valeurs variant selon boutique, langue ou région. Utilisez les identifiants explicites des boutiques au lieu de déduire la propriété du nom de domaine ou de la langue. Lorsque la plateforme cible représente les vitrines autrement, définissez la relation de destination pour chaque valeur spécifique à une boutique plutôt que de copier uniquement l’enregistrement commun.
Exemple de recommandation
Un marchand exploite des boutiques française et belge avec un catalogue Product partagé mais des descriptions, présentations fiscales et promotions différentes. Conservez l’identité Product commune tout en affectant les contenus localisés et valeurs commerciales aux bonnes boutiques cibles au lieu de choisir une seule boutique comme source universelle.
Condition de réussite
Chaque boutique cible n’expose que les Products, Categories, contenus, langues et contextes commerciaux qui lui sont destinés ; les enregistrements partagés restent partagés lorsqu’il le faut ; aucune valeur propre à une boutique ne devient silencieusement une valeur globale par défaut.
Piège 3 : migrer les groupes Customer sans leur sens commercial
Ce qui se passe mal
Les groupes Customer peuvent influer sur la visibilité, les prix, les remises, l’affichage fiscal ou les droits d’accès. Copier le nom du groupe sans conserver les relations qu’il contrôle produit des comptes qui semblent correctement classifiés dans le back-office mais reçoivent un traitement ordinaire dans la boutique. Le problème passe facilement inaperçu lorsque la revue s’arrête au profil Customer sans comparer le résultat d’achat pour chaque groupe.
Signaux d’alerte précoces
Les libellés de groupe peuvent être présents tandis que leurs effets commerciaux ont disparu. Le risque augmente lorsque les groupes source combinent logique B2B, wholesale, employé, fidélité, fiscalité ou région.
| Signal d’alerte | Ce qu’il suggère | Effet métier |
|---|---|---|
| Les groupes existent mais tous les acheteurs voient le même prix | La relation tarifaire n’a pas été représentée | Les attentes wholesale ou négociées échouent |
| Les Products restreints sont visibles par tous | La propriété de visibilité a été perdue | Les contrôles de catalogue privé disparaissent |
| L’affichage fiscal est identique pour tous les groupes | Le contexte fiscal lié aux groupes a été aplati | Les montants affichés et facturés peuvent diverger de la politique prévue |
Prévention
Documentez le résultat contrôlé par chaque groupe source, pas seulement son nom. Faites correspondre la relation Customer → groupe séparément de la configuration cible qui donne au groupe son sens. Consolidez volontairement les groupes en double ou obsolètes. Lorsque plusieurs groupes source sont encodés dans un tag ou champ personnalisé unique, déterminez si la cible peut représenter une appartenance équivalente ou nécessite une hiérarchie normalisée.
Exemple de recommandation
Pour un groupe wholesale, conservez l’appartenance Customer et définissez le responsable cible des prix wholesale, Products restreints et de la présentation fiscale. N’approuvez pas le groupe simplement parce que le mot « Wholesale » apparaît sur l’enregistrement Customer.
Condition de réussite
Des Customers représentatifs entrent dans le bon contexte de compte et reçoivent la visibilité Product, les prix, remises et la présentation fiscale prévues pour leur groupe, les différences intentionnelles étant documentées comme fonctionnement cible.
Piège 4 : dégrader la découverte des Categories tout en conservant l’arborescence
Ce qui se passe mal
L’import des Categories peut reproduire noms et relations parent-enfant tout en affaiblissant la manière dont les acheteurs trouvent les Products. La navigation PrestaShop, le filtrage à facettes, l’utilisation des caractéristiques, le merchandising et le fonctionnement du thème peuvent dépendre de davantage que l’arborescence elle-même. Des Categories vides, des Products affectés à la mauvaise Category par défaut ou des caractéristiques descriptives qui ne soutiennent plus le filtrage peuvent rendre un catalogue complet difficile à parcourir.
Signaux d’alerte précoces
Les nombres de Categories restent généralement corrects même lorsque la découverte est dégradée. Les signaux apparaissent dans les parcours de boutique, le placement Product, les filtres et le comportement de la Category par défaut.
| Contrôle | Modèle d’échec | Pourquoi c’est important |
|---|---|---|
| Category par défaut | Le Product a plusieurs affectations mais un mauvais contexte principal | Le fil d’Ariane et le comportement canonique peuvent changer |
| Couverture des caractéristiques | Les valeurs n’existent que pour une partie d’une famille Product | La navigation à facettes devient incohérente |
| Profondeur des Categories | Des branches profondes sont aplaties ou dupliquées | Les acheteurs perdent les parcours de navigation attendus |
Prévention
Définissez les résultats de découverte attendus pour des familles Product représentatives. Conservez toutes les affectations Category nécessaires et identifiez la Category par défaut lorsque PrestaShop en dépend. Normalisez les noms et valeurs de caractéristiques avant de les utiliser pour le filtrage. Retirez les Categories obsolètes uniquement avec une redirection explicite ou une destination de merchandising, et non par suppression sans planification des routes.
Exemple de recommandation
Pour un catalogue de chaussures, vérifiez qu’un modèle reste dans Men, Running et Sale tout en conservant la Category par défaut prévue. Confirmez que les caractéristiques de taille, surface et étanchéité sont suffisamment complètes pour soutenir l’expérience de filtrage cible.
Condition de réussite
Les familles Product prioritaires restent accessibles par les parcours Category attendus, le fil d’Ariane et le contexte par défaut sont cohérents, le filtrage utilise des valeurs complètes et normalisées, et les branches retirées conduisent vers une destination utile.
Piège 5 : supposer que les URL simplifiées conservent automatiquement l’identité des routes
Ce qui se passe mal
Les clés d’URL source, routes réécrites, préfixes de langue et chemins CMS ne reproduisent pas automatiquement la même adresse publique dans un nouvel environnement PrestaShop. Un enregistrement peut être présent alors que sa route à forte valeur change, entre en conflit avec une autre ou aboutit dans la mauvaise boutique ou la mauvaise langue. Le problème touche Customers, campagnes, liens internes et visibilité dans les moteurs de recherche.
Signaux d’alerte précoces
Les signaux les plus forts sont des valeurs réécrites en double, des suffixes de langue inexpliqués, un contexte de boutique manquant ou des pages prioritaires dont la destination n’a jamais été déclarée.
| Type de route | Lacune fréquente | Décision requise |
|---|---|---|
| Route Product ou Category | L’ancienne réécriture ne correspond pas à la structure cible | Choisir la cible canonique et rediriger la route source |
| Route multilingue | Des slugs propres à chaque langue sont aplatis dans une seule valeur | Préserver les destinations propres à chaque locale |
| Route CMS ou campagne | La page existe sous un nouveau chemin | Mettre à jour les liens internes et rediriger l’ancienne route |
Prévention
Créez un registre de routes pour les Products, Categories, pages CMS et destinations de campagne prioritaires. Incluez l’URL source, la langue, la boutique, la route cible prévue et le responsable de la redirection. Contrôlez l’unicité dans le contexte de routage cible. Conservez les slugs utiles lorsque c’est possible, mais privilégiez une cible canonique cohérente plutôt que des routes concurrentes ou dupliquées.
Exemple de recommandation
Une route Product française et une route Product belge partagent un nom traduit mais appartiennent à des boutiques différentes. Affectez chacune à la bonne destination boutique/langue et créez des redirections depuis les deux chemins historiques au lieu de conserver uniquement la route qui génère le plus de trafic.
Condition de réussite
Chaque route historique prioritaire atteint directement ou via une seule redirection utile le bon Product, la bonne Category ou la bonne destination CMS dans la boutique et la langue prévues, sans boucle ni collision.
Piège 6 : traiter les modules, surcharges et la logique du thème comme des données migrées
Ce qui se passe mal
Les modules et surcharges PrestaShop peuvent créer des champs, modifier le processus de commande, ajouter des transporteurs ou des comportements de paiement, changer la présentation Product ou stocker des identifiants d’intégration. Les thèmes peuvent déterminer comment les structures du catalogue sont rendues. Copier les enregistrements standard ne recrée pas ces fonctions, et copier des tables de modules sans comprendre le module consommateur peut créer des données inutilisables ou dangereuses.
Signaux d’alerte précoces
Le risque est visible lorsque des résultats métier critiques sont décrits uniquement par des noms de modules, que des tables personnalisées n’ont aucun propriétaire ou que le thème cible attend des champs et hooks différents.
| Dépendance | Question à résoudre | Responsable probable |
|---|---|---|
| Champ créé par un module | Quel processus actuel le lit ? | Module conservé, intégration ou champ cible restructuré |
| Surcharge ou code personnalisé | Quel fonctionnement par défaut modifie-t-il ? | Mise en œuvre cible plutôt que migration d’enregistrements |
| Contenu propre au thème | La valeur est-elle une donnée ou une configuration de présentation ? | Configuration du thème/contenu cible |
Prévention
Inventoriez modules, surcharges, tables personnalisées, hooks et dépendances de thème selon le résultat métier qu’ils produisent. Ne conservez une valeur que si un consommateur cible existe. Séparez la migration des enregistrements de la réinstallation, configuration, substitution ou reconstruction d’un fonctionnement. Évitez de transporter des données de modules dormants uniquement parce qu’elles sont présentes dans la base.
Exemple de recommandation
Si un module stocke une référence fournisseur utilisée par un export ERP, conservez cette référence dans un champ cible ou un enregistrement d’intégration que le processus ERP pourra continuer à lire. Ne copiez pas simplement la table du module si celui-ci n’existera pas dans l’environnement cible.
Condition de réussite
Chaque module ou surcharge critique possède un propriétaire cible déclaré, les données nécessaires restent lisibles par ce propriétaire et aucun processus de boutique ou d’exploitation n’est supposé continuer uniquement parce que les enregistrements standard ont été migrés.
Piège 7 : aplatir la propriété du stock entre combinaisons et emplacements
Ce qui se passe mal
Le stock peut sembler correct au niveau Product alors que les combinaisons vendables portent de mauvaises quantités ou disponibilités. Des systèmes de stock externes, un ancien historique de stock avancé, des flux d’entrepôt ou du stock propre à certaines boutiques peuvent ajouter d’autres niveaux de propriété. Aplatir ces valeurs peut créer des surventes, de faux états de rupture ou une quantité cible immédiatement écrasée par un système connecté.
Signaux d’alerte précoces
Une quantité unique par Product, des identifiants de combinaison manquants, un stock négatif inexpliqué ou un désaccord entre la boutique et un système externe indiquent un problème de propriété plutôt qu’une simple erreur d’import.
| Signal de stock | Cause probable | Priorité de prévention |
|---|---|---|
| Le total parent égale la somme de tous les variants | La propriété au niveau variant a été ignorée | Préserver la quantité par combinaison ou la clé de stock externe |
| La quantité cible change après synchronisation | Le système externe reste la source d’autorité | Définir le stock d’ouverture et le propriétaire après migration |
| Une boutique affiche le stock d’une autre | Le contexte de boutique a été aplati | Préserver la relation boutique/emplacement |
Prévention
Déclarez le système faisant autorité pour le stock de chaque famille Product et emplacement. Conservez les SKU de combinaisons et identifiants externes. Définissez si la migration fournit un stock d’ouverture, une référence historique ou une valeur de stock durable. Excluez les anciennes tables de stock qui ne gouvernent plus la disponibilité.
Exemple de recommandation
Pour un Product avec des combinaisons de taille gérées par un système d’entrepôt, migrez la quantité d’ouverture par combinaison et conservez le SKU d’entrepôt. Planifiez le retour d’autorité au système d’entrepôt après la bascule au lieu de considérer le total du Product parent comme valeur permanente.
Condition de réussite
La bonne combinaison vendable est disponible dans la bonne boutique ou le bon emplacement, les changements de stock sont contrôlés par le système prévu et la réconciliation peut relier chaque quantité cible à un identifiant Product ou combinaison stable.
Piège 8 : conserver les Orders historiques sans leur contexte explicatif
Ce qui se passe mal
Le total et le statut d’un Order ne suffisent pas à préserver ce qui s’est produit. Les Orders historiques peuvent dépendre de combinaisons Product, groupes Customer, taxes, transporteurs, remises, remboursements, messages et historique de statuts. Si ces relations sont aplaties, les équipes voient une transaction sans pouvoir expliquer le montant, identifier la variation achetée ou comprendre l’action de traitement logistique ou de remboursement réalisée.
Signaux d’alerte précoces
Les Orders semblent complets dans la liste mais deviennent ambigus lorsqu’on les ouvre. Des détails d’option manquants au niveau des lignes, des statuts génériques, un contexte de remise absent ou des enregistrements Customer détachés sont des signaux typiques.
| Contexte d’Order | Échec s’il manque | Conséquence pour le service |
|---|---|---|
| Détail de combinaison ou personnalisation | L’article acheté ne peut pas être identifié | Les décisions de retour et de support deviennent peu fiables |
| Historique des statuts et messages | La séquence opérationnelle est perdue | Les équipes ne peuvent pas expliquer le traitement logistique ou l’annulation |
| Lignes de remise, taxe et transport | Le total ne peut pas être réconcilié | Finance et service client perdent confiance dans l’historique |
Prévention
Conservez l’identité Product au niveau des lignes et le contexte descriptif de l’achat même lorsque la cible ne peut pas recréer chaque ancien état de processus. Faites correspondre les statuts par leur sens plutôt que par similitude de libellé. Gardez les lignes financières distinctes. Conservez les numéros d’Order source et références externes lorsque d’autres systèmes les utilisent pour la recherche.
Exemple de recommandation
Pour un Order remboursé contenant une combinaison taille/couleur et un voucher, conservez la description de la combinaison achetée, les montants d’origine, la ligne de remise, le contexte de remboursement, l’association Customer et la référence source au lieu de représenter l’ensemble comme un Order générique terminé.
Condition de réussite
Les équipes peuvent identifier ce que le Customer a acheté, comment le total a été formé, quelle séquence d’états s’est produite et quel contexte de remboursement ou de traitement logistique reste pertinent, sans consulter l’ancienne boutique pour les questions de support ordinaires.
Piège 9 : transférer une localisation incohérente dans un catalogue partagé
Ce qui se passe mal
Le contenu multilingue contient souvent des traductions partielles, slugs dupliqués, textes de fallback, différences HTML et champs créés par des modules traduits de manière incohérente. Migrer chaque valeur exactement telle qu’elle est stockée peut afficher du contenu dans la langue source dans la mauvaise boutique ou produire des sections vides là où la cible attend une valeur locale.
Signaux d’alerte précoces
Des Products ont un nom traduit mais pas leur description, des slugs de Category entrent en conflit entre locales ou une boutique utilise un contenu copié qui devrait rester distinct.
| Problème de localisation | Résultat visible | Contrôle |
|---|---|---|
| Valeur locale manquante | Contenu vide ou fallback dans la boutique | Définir une règle de fallback ou de complétion approuvée |
| Même slug dans des contextes incompatibles | Collision de route ou mauvaise destination | Affecter des routes tenant compte de la locale et de la boutique |
| Liens intégrant le domaine source | Les Customers reviennent vers l’ancienne boutique | Réécrire les liens vers les destinations cibles |
Prévention
Auditez la complétude des traductions par famille d’enregistrements à forte valeur et par locale. Normalisez l’encodage et le HTML. Décidez où un fallback est acceptable et où un contenu manquant doit rester non publié jusqu’à sa complétion. Traitez les liens, références média et champs SEO comme des relations localisées plutôt que comme de simples chaînes de texte.
Exemple de recommandation
Un Product possède un contenu français complet mais seulement un nom anglais. Publiez normalement la version française, appliquez la politique de fallback anglaise approuvée et empêchez une description anglaise incomplète d’hériter d’un lien vers le domaine source français.
Condition de réussite
Chaque locale publiée affiche la langue prévue, les routes et médias se résolvent dans le bon contexte de boutique, et les traductions manquantes suivent une règle de fallback ou de publication délibérée plutôt qu’un héritage accidentel.
Piège 10 : conserver des identifiants externes sans conserver leurs consommateurs
Ce qui se passe mal
Les bases source contiennent souvent des IDs ERP, clés fournisseur, IDs marketplace, anciennes références Product et valeurs de recherche propres à des modules. Les copier dans un champ de note arbitraire conserve les caractères mais pas leur fonction. Les omettre peut rompre la réconciliation ; les dupliquer peut conduire les systèmes connectés à mettre à jour le mauvais enregistrement.
Signaux d’alerte précoces
Les équipes savent lister les identifiants mais ne peuvent pas dire quel système les possède, s’ils doivent être uniques ni comment ils seront recherchés après migration.
| Identifiant | Question sur le consommateur | Exigence cible |
|---|---|---|
| ID ERP Product ou combinaison | Quel job de synchronisation l’utilise ? | Champ unique stable accessible à l’intégration |
| ID de listing marketplace | Le listing reste-t-il actif ? | Relation de canal maintenue ou retrait volontaire |
| Référence d’Order historique | Qui la recherche ? | Référence historique visible et recherchable |
Prévention
Créez un contrat d’identifiants précisant champ source, propriétaire de l’enregistrement, emplacement cible, règle d’unicité, format et système consommateur. Conservez uniquement les identifiants actifs ou utiles comme preuve. Gardez distinctes les clés du Product parent et des combinaisons. Testez la recherche et la mise à jour via l’intégration ou le processus opérationnel qui continuera à les utiliser.
Exemple de recommandation
Si un ERP met à jour le stock à partir de la référence de combinaison, placez cette référence sur la combinaison vendable cible ou l’enregistrement d’intégration. Ne la stockez pas uniquement sur le Product parent ou dans une note d’administration inaccessible au processus de synchronisation.
Condition de réussite
Chaque identifiant externe requis est unique lorsque cela est attendu, récupérable par son consommateur durable, attaché au bon niveau d’enregistrement et prouve qu’il soutient la réconciliation ou le fonctionnement de l’intégration.
Priorités communes de prévention
Les risques récurrents de PrestaShop peuvent être maîtrisés à travers trois axes de revue reliés.
| Priorité de prévention | Ce qu’elle protège | Éléments attendus avant approbation |
|---|---|---|
| Préserver le sens des combinaisons et du stock | Combinaisons, attributs, emplacements et stock vendable | Des Products représentatifs conservent les bons choix, identifiants, propriétaires de stock et états de disponibilité. |
| Préserver le contexte multiboutique et commercial | Propriété des boutiques, groupes Customer, localisation, Categories et tarification | Les enregistrements apparaissent dans la bonne boutique, langue, devise, groupe et contexte de navigation. |
| Séparer modules et intégrations des enregistrements migrés | Surcharges, thèmes, identifiants externes et consommateurs opérationnels | Chaque dépendance non principale a un propriétaire cible, une décision de mise en œuvre et une méthode de validation. |
Conclusion
Un résultat PrestaShop fiable repose sur des relations explicites : Products vers combinaisons, Categories vers découverte, Customers vers groupes, enregistrements vers boutiques et langues, et valeurs personnalisées vers modules ou intégrations qui continueront à les utiliser. Lorsque ces relations sont définies et testées au moyen de scénarios métier représentatifs, la migration peut préserver la façon dont la boutique fonctionne, et pas seulement le contenu de sa base de données.
Questions fréquentes
Pourquoi les combinaisons PrestaShop constituent-elles un risque majeur en migration ?
Les combinaisons peuvent porter des différences de SKU, prix, image, poids et stock. Les aplatir dans des caractéristiques ou Products séparés modifie la structure vendable et peut affecter le panier et le stock.
Le multiboutique nécessite-t-il une copie séparée de chaque enregistrement ?
Pas nécessairement. Certaines données peuvent être partagées tandis que d’autres valeurs restent propres à une boutique. La migration doit conserver la propriété prévue au lieu de tout dupliquer ou de considérer une boutique comme universelle.
Faut-il migrer chaque table de module ?
Non. Un enregistrement de module ne doit être conservé que si un composant cible ou un processus opérationnel qui continue en a besoin. Les données dormantes ou orphelines ne doivent pas être copiées uniquement pour la complétude.
Comment évaluer les groupes Customer ?
Évaluez le résultat commercial lié à chaque groupe, par exemple le prix, la visibilité, l’affichage fiscal ou l’accès, et pas seulement l’existence du libellé.
Quelle est la manière la plus sûre de préserver les URL PrestaShop ?
Utilisez un registre de routes qui consigne chemin source, boutique, langue, destination cible et responsable de redirection pour les Products, Categories, pages CMS et campagnes prioritaires.
Qu’est-ce qui prouve que les identifiants externes ont été correctement conservés ?
Le processus ERP, entrepôt, marketplace ou support qui continue peut localiser et mettre à jour l’enregistrement cible prévu au moyen de l’identifiant conservé au bon niveau Product, combinaison, Customer ou Order.