La validation d’une migration VTEX doit prouver que les enregistrements migrés fonctionnent dans les domaines de la plateforme qui contrôlent réellement l’activité e-commerce. Un Product peut exister alors que son SKU, ses spécifications, son association à une trade policy, son prix, son stock, sa logistique, son offre seller ou son indexation storefront empêchent l’achat. Un Customer ou un document Master Data peut exister alors que sa relation, sa clé ou le processus qui le consomme est incorrect. Un Order peut exister alors que son seller, ses lignes, son paiement ou son contexte de traitement ne peut pas être rapproché.
Les éléments de validation doivent suivre les relations VTEX réelles : Category et Brand vers Product, Product vers SKU et spécifications, SKU vers prix et disponibilité, trade policy vers Catalog et conditions commerciales, seller vers offre et Order marketplace, Customer vers Master Data ou enregistrements B2B, et Order vers éléments OMS et logistiques.
Utiliser Pass, Watch et Block dans les différents domaines VTEX
- Pass : les éléments représentatifs et les cas d’exception prouvent le fonctionnement VTEX attendu.
- Watch : le résultat est exploitable, mais une correction non bloquante documentée, une tâche de configuration cible, une décision de responsable ou une différence acceptée reste ouverte.
- Block : le problème affecte matériellement la vente, la tarification, la responsabilité seller, le stock, la logistique, les Customers, les Orders historiques, le contenu, le SEO, la continuité des intégrations, la conformité ou le périmètre de migration convenu.
| Domaine de validation | Preuve VTEX | Situation typique de Block |
|---|---|---|
| Catalog | Categories, Brands, Products, SKUs, spécifications, images et activation permettent l’achat. | Un SKU prioritaire ne peut pas être sélectionné ou acheté correctement. |
| Contexte commercial | Trade policies, prix, promotions et assortiment produisent le résultat attendu dans le bon canal. | Un canal important reçoit le mauvais Product ou le mauvais prix. |
| Marketplace | Identité seller, offres, correspondances catalogue et propriété des Orders restent cohérents. | Le Product ou l’Order d’un seller est attribué au mauvais acteur. |
| Logistique | Stock, entrepôts, docks, shipping policies et contexte de livraison soutiennent la disponibilité. | Du stock valide devient indisponible ou du stock indisponible est vendu. |
| Customers et Orders | Profils, B2B, Master Data, lignes, totaux, statuts et références restent compréhensibles. | Un Order historique important ou une relation de compte ne peut pas être rapproché. |
| Périmètre personnalisé | Applications, intégrations, sorties de migration convenues, livrables non standard et IDs externes fonctionnent via leur propriétaire. | Un processus critique pour le lancement perd des données ou une clé stable. |
Le rapport final doit nommer le compte, la trade policy, le seller, le SKU, l’entrepôt, la shipping policy, l’entité Master Data et le contexte d’intégration examinés. Un Pass général sur le Catalog ne doit pas masquer un seller ou un canal bloqué.
VTEX exige de conserver la responsabilité par domaine. Catalog, Pricing, Promotions, Logistics, OMS, Marketplace, Master Data, Search et les équipes storefront peuvent aboutir à des conclusions différentes sur le même Product ou Order ; le rapport de lancement ne doit donc pas les compresser en un statut unique.
Utiliser des tests représentatifs pour valider les hypothèses Catalog et canal
Les tests représentatifs doivent inclure des enregistrements qui exposent l’architecture VTEX :
- Products avec plusieurs SKUs et spécifications définissant les variations ;
- Categories avec groupes de spécifications Product/SKU hérités ;
- SKUs avec images, identifiants, prix, stock et dépendances d’activation ;
- Products disponibles sous différentes trade policies ;
- Products marketplace, sellers, offres et correspondances catalogue ;
- Customers, enregistrements B2B et documents Master Data avec clés stables ;
- Orders directs et marketplace ;
- entrepôts, docks, shipping policies et exceptions de livraison ;
- contenus storefront prioritaires, URLs et Products sensibles à la recherche ;
- enregistrements détenus par des applications et IDs externes.
Les éléments représentatifs doivent montrer si les variantes source sont devenues des SKUs VTEX, si les spécifications Product et SKU conservent le bon sens et si les relations trade policy/seller pointent vers les bons enregistrements. Une erreur structurelle répétable constitue un Block avant toute exécution plus large.
L’échantillon doit aussi inclure des enregistrements inactifs, hors stock, incomplets ou exceptionnels. Des SKUs actifs et propres ne suffisent pas à prouver les frontières d’activation et de disponibilité qui provoquent souvent les problèmes de lancement VTEX.
Valider Categories, Brands, Products, SKUs et spécifications
| Élément Catalog | Pass | Watch | Block |
|---|---|---|---|
| Relation Product-SKU | Chaque SKU prévu reste attaché au bon Product. | Un ordre d’affichage secondaire reste à ajuster. | SKUs manquants, dupliqués ou attachés au mauvais Product. |
| Spécifications | Valeurs Product/SKU utilisent le champ, le type et le vocabulaire attendus. | Nettoyage de faible importance restant. | Sens de variation, filtrage, intégration ou conformité incorrect. |
| Images | Images SKU requises affichées et utiles à une sélection correcte. | Ordre secondaire restant. | Un SKU prioritaire ne peut pas être activé ou identifié correctement. |
| Brand et Category | Affectation Product soutient découverte et classification prévues. | Raffinement merchandising restant. | Products prioritaires inaccessibles ou mal classés. |
| Identifiants | Product, SKU, référence, EAN ou clés externes identifient la bonne unité. | Nettoyage de doublons non critiques restant. | Prix, stock, seller ou intégration résolvent vers le mauvais SKU. |
| Activation | Product et SKU respectent les prérequis de disponibilité attendus. | Travail de publication contrôlé restant. | Un SKU prioritaire ne peut pas être proposé dans le canal prévu. |
Validez via l’Admin, le storefront ou les résultats de recherche, la page Product, le panier, la ligne d’Order et les systèmes externes. Un enregistrement Catalog ne doit pas passer uniquement parce que ses IDs Product et SKU existent.
Les spécifications doivent distinguer propriétés descriptives Product et valeurs de sélection SKU. Une valeur peut sembler correcte dans l’Admin tout en échouant si elle appartient au mauvais champ, groupe, chemin d’héritage de Category ou SKU.
Incluez des SKUs dont l’activation dépend d’images, spécifications et données commerciales complètes. Cela expose les enregistrements Catalog techniquement présents mais incapables de participer correctement à la sélection Product ou à la disponibilité storefront.
Valider trade policies, prix, promotions et assortiment
Les trade policies peuvent relier disponibilité catalogue, prix, promotions, stock, logistique, paiement et canaux de vente. La validation doit être réalisée dans le contexte réel du canal.
| Élément commercial | Preuve requise |
|---|---|
| Association trade policy | Products et SKUs attendus sont disponibles uniquement dans le bon contexte de canal. |
| Prix | Le SKU, seller, trade policy, quantité et devise exacts produisent le prix attendu. |
| Promotion | Conditions et exclusions produisent le résultat commercial prévu. |
| Restriction d’assortiment | Products exclus d’un canal y restent indisponibles. |
| Contexte de stock | Disponibilité suit les relations entrepôt/logistique utilisées par la trade policy. |
| Contexte paiement/checkout | Configuration cible actuelle expose les méthodes attendues, séparément de l’historique Order. |
Un prix numérique dans Pricing ne suffit pas. Testez le résultat côté acheteur avec seller, trade policy et quantité prévus. Utilisez Block pour les erreurs tarifaires ou d’assortiment significatives et Watch pour des travaux de configuration ou présentation non critiques et documentés.
Les remises historiques dans les Orders restent des instantanés transactionnels. Elles ne prouvent pas que les Promotions ou conditions de trade policy actuelles sont configurées correctement.
Lorsque plusieurs trade policies partagent une partie du même catalogue, comparez les SKUs inclus et exclus. Les preuves positives valident la disponibilité ; les preuves négatives montrent que l’assortiment restreint et les conditions commerciales ne débordent pas vers un autre canal.
Valider sellers, offres, correspondances marketplace et propriété des Orders
Les opérations marketplace VTEX séparent l’identité Catalog canonique des offres propres aux sellers. Un seller peut fournir prix, stock, traitement logistique et responsabilité commerciale pour un article représenté dans le marketplace Catalog.
Vérifiez :
- identité et statut seller ;
- correspondance du seller SKU ou de l’offre vers le Product/SKU prévu ;
- contexte trade policy et assortiment ;
- prix et stock du seller ;
- responsabilité de traitement ;
- clés de correspondance Category/Product marketplace ;
- origine de l’Order, attribution seller, références commission/règlement lorsqu’elles sont dans le périmètre ;
- identifiants marketplace externes et connecteurs.
Utilisez Block lorsqu’une offre pointe vers le mauvais SKU, qu’un seller perd sa responsabilité, qu’un Order marketplace est mal attribué ou que règlement et traitement ne permettent plus d’identifier le seller responsable. Utilisez Watch pour une configuration de connecteur contrôlée lorsque la relation Catalog migrée et les identifiants sont complets.
Les éléments marketplace ne doivent pas être moyennés avec ceux du storefront direct. Un Product peut passer sur le canal direct et bloquer la marketplace si son offre seller, sa trade policy, son stock ou sa correspondance est incorrecte.
Valider stock, entrepôts, docks, shipping policies et contexte OMS
La logistique VTEX peut relier le stock aux entrepôts, loading docks, shipping policies, transporteurs, trade policies et options de livraison. Validez les relations qui déterminent disponibilité et promesse de livraison.
| Élément logistique | Point de validation |
|---|---|
| Stock | La quantité appartient au bon SKU et au bon entrepôt. |
| Entrepôt | L’entrepôt possède le stock prévu et la bonne relation avec le dock. |
| Loading dock | Le dock relie les entrepôts, transporteurs et trade policies attendus. |
| Shipping policy | Les règles, tarifs, niveaux de service et l’état actif soutiennent le contexte de destination prévu. |
| Disponibilité SKU | L’acheteur voit la disponibilité et l’option de livraison attendues pour la trade policy et le seller. |
| Traitement Order | Les Orders historiques conservent seller, livraison, statut et références externes. |
| Autorité externe | Les systèmes ERP, WMS ou transporteurs identifient le bon SKU, entrepôt et Order. |
Un total de stock correct peut tout de même échouer si le stock est placé dans le mauvais entrepôt ou déconnecté du dock et de la shipping policy pertinents. Les échecs de disponibilité prioritaires sont des Block.
Les Orders migrés ne configurent pas la logistique active. Entrepôts, docks, shipping policies, transporteurs, points de retrait, fonctionnement SLA et opérations OMS actuels nécessitent une approbation cible séparée.
Testez au moins une combinaison destination de livraison + SKU pour chaque parcours logistique important. Cela révèle les relations entrepôt-dock-shipping policy rompues que les totaux de stock et les statuts Admin ne montrent pas.
Valider Customers, relations B2B, Master Data et Orders historiques
Les données Customer peuvent couvrir identité de profil, adresses, organisations B2B, rôles, centres de coûts, consentements, IDs CRM et documents Master Data. Validez l’entité et sa clé, pas seulement les champs affichés.
| Élément Customer | Preuve requise |
|---|---|
| Identité de profil | E-mail, document, téléphone ou clé externe identifie la bonne personne. |
| Adresse | Adresse actuelle du profil et adresse historique d’Order restent distinctes lorsque nécessaire. |
| Entité B2B | Organisation, utilisateur, rôle, centre de coûts, catalogue ou relation d’approbation reste correctement attaché. |
| Document Master Data | Entité, ID document, schéma, champs, relations et consommateur sont corrects. |
| Identifiant externe | CRM, ERP, fidélité, marketplace ou support retrouve le même Customer ou la même organisation. |
| Order historique | Customer, seller, lignes SKU, prix, promotions, paiements, expédition, statuts et IDs externes restent compréhensibles. |
Utilisez Block lorsque la fusion d’identités n’est pas sûre, qu’une relation B2B est rompue, qu’une référence Master Data pointe vers la mauvaise entité ou qu’un Order important ne peut pas être rapproché.
Les Orders historiques ne prouvent pas que Checkout, Payments, Promotions, Logistics, OMS, notifications, factures, remboursements ou workflows de segmentation Customer actuels sont prêts. Ces domaines nécessitent une approbation opérationnelle distincte.
Pour Master Data, contrôlez aussi les champs relationnels et documents référencés, pas seulement le corps du document. Une valeur de profil correcte peut échouer lorsqu’une organisation, un centre de coûts, une application ou un workflow pointe vers un identifiant obsolète.
Valider storefront, recherche, URLs et continuité du contenu
Les éléments de validation storefront peuvent couvrir indexation de recherche, disponibilité Product, Categories, Brands, filtres, pages de contenu, navigation, routes SEO et présentation gérée par des applications. Validez depuis le parcours acheteur, pas uniquement depuis la présence dans Catalog.
Incluez des éléments représentatifs pour :
- recherches prioritaires Product/SKU ;
- découverte par Category et Brand ;
- filtres pilotés par les spécifications ;
- sélection et disponibilité sur page Product ;
- URLs source prioritaires et destinations attendues ;
- métadonnées, médias et liens internes ;
- contenus de politique, service et campagne ;
- différences de locale ou domaine lorsqu’elles existent ;
- références de contenu headless ou gérées par applications.
Utilisez Block pour une défaillance généralisée d’indexation prioritaire, une sélection SKU rompue, un contenu requis manquant ou une perte d’URL à forte valeur. Utilisez Watch pour des travaux contrôlés de présentation, indexation ou métadonnées lorsque les enregistrements et le responsable sous-jacent sont complets.
Catalog, Search et implémentation storefront sont liés mais distincts. Un Product peut exister dans Catalog tout en étant absent de la recherche ou indisponible dans la trade policy prévue.
Valider applications, intégrations, ajustements pris en charge et livrables Tailored
Les boutiques VTEX relient souvent Catalog, Pricing, Logistics, OMS, Master Data, sellers, recherche, applications storefront, ERP/PIM/WMS, CRM, marketplaces, fiscalité, paiement et systèmes d’analytique. Validez les données personnalisées via leur domaine et leur consommateur réels.
Pour chaque valeur critique, documentez :
- domaine VTEX et entité propriétaire ;
- application ou système externe ;
- identifiant Product, SKU, seller, Customer, Master Data ou Order ;
- direction attendue de synchronisation ;
- exemple de réussite et d’exception ;
- responsable du déploiement ou de la configuration restante.
Validez les sorties prises en charge et les livrables Tailored convenus par rapport au périmètre documenté. Une spécification transformée, une correspondance seller, un document Master Data, un ID externe ou une relation personnalisée doit être testé via l’API, l’application, le module Admin, le storefront ou le système externe qui le consomme.
Utilisez Block lorsque la valeur est orpheline, incompatible ou intraçable dans un processus critique au lancement. Utilisez Watch lorsque le déploiement restant d’une application ou intégration est hors périmètre de migration et que domaine VTEX, contrat de données, clé stable et responsable sont complets.
Distinguer tests représentatifs et preuves d’une exécution plus large
Le test représentatif valide des hypothèses structurelles sélectionnées. Une exécution plus large doit prouver l’ensemble du périmètre Catalog, canaux, sellers, logistique, Customer, Order, contenu et intégrations.
Elle doit couvrir :
- tous les grands modèles Product-SKU ;
- tous les champs et valeurs de spécifications ;
- couverture d’assortiment et de prix par trade policy ;
- toutes les offres seller et correspondances marketplace dans le périmètre ;
- stock, entrepôts, docks et références logistiques pertinentes ;
- Customers, B2B, documents Master Data et Orders historiques ;
- storefront, recherche, URLs prioritaires et contenu ;
- toutes les sorties prises en charge et Tailored ;
- exceptions liées aux applications et IDs externes ;
- changements intervenus après le test représentatif.
Rouvrez un Pass du test représentatif si l’exécution plus large révèle des spécifications SKU incohérentes, images manquantes, problèmes d’activation, mauvaises associations trade policy, erreurs de correspondance seller, décalages d’entrepôt, documents Master Data orphelins, Customers dupliqués ou Orders non rapprochés.
Segmentez les exceptions par trade policy, seller, Category, famille Product, groupe de spécifications, entrepôt, entité Customer/B2B et période source. Les agrégats peuvent masquer l’échec complet d’un seul canal ou seller.
Revalider après les actions de migration ultérieures
| Action ultérieure | Périmètre de revalidation VTEX |
|---|---|
| continue under the accepted configuration | Valider les nouveaux enregistrements éligibles et confirmer que les hypothèses Catalog, trade policy, seller, logistique, Customer, Order, contenu et intégration précédemment approuvées restent valides. |
| continue under revised configuration | Revalider chaque relation affectée par les changements de filtres, correspondances, sélection de types de données ou configuration, y compris les approbations antérieures. |
| produce a distinct new migration result | Traiter la sortie comme un résultat migré distinct et répéter la validation VTEX complète et la décision de lancement. |
Conservez ensemble les décisions anciennes et nouvelles. Si l’identité Product/SKU, l’affectation trade policy, la correspondance seller ou la correspondance Customer change, les Orders, références logistiques et intégrations précédemment approuvés peuvent également nécessiter une nouvelle revue.
La revalidation VTEX doit suivre les références de domaine. Un changement de correspondance SKU peut affecter prix, stock, offres seller, logistique, Search et éléments Order ; un changement de clé Customer peut affecter Master Data, B2B et associations Order historiques.
Construire la décision de lancement VTEX
Le lancement exige :
- aucun Block non résolu touchant Catalog, prix, sellers, stock, logistique, Customers, Orders historiques, découverte storefront, SEO, conformité ou intégrations ;
- test représentatif et preuves d’exécution plus large terminés ;
- preuve des sorties prises en charge et Tailored convenues ;
- approbation séparée pour Pricing, Promotions, Checkout, Payments, Logistics, OMS, opérations seller, Search et déploiement des applications VTEX actives ;
- revalidation après les actions ultérieures concernées ;
- responsables et dates de clôture nommés pour les éléments Watch.
Conservez des statuts séparés pour préparation Catalog, préparation canal/prix, préparation marketplace, préparation logistique, données historiques, storefront/recherche et intégrations. Un storefront direct en Pass ne doit pas masquer une relation seller ou logistique bloquée.
Conclusion
La validation VTEX doit prouver que Catalog, SKUs, spécifications, trade policies, sellers, logistique, Customers, Master Data, Orders, contenu et intégrations fonctionnent ensemble dans le contexte de canal prévu.
Les tests représentatifs établissent la confiance structurelle, l’exécution plus large prouve la complétude et les exceptions, et les actions de migration ultérieures exigent une revalidation ciblée ou complète. L’approbation du lancement doit suivre des éléments Pass, Watch et Block documentés.
Questions fréquentes
Pourquoi faut-il valider séparément Products et SKUs dans VTEX ?
Les Products portent l’identité catalogue générale, tandis que les SKUs représentent les unités physiques ou sélectionnables achetées. Spécifications, images, prix, stock et offres seller peuvent dépendre du SKU.
Comment tester les éléments liés aux trade policies ?
Utilisez ensemble le canal de vente, le seller, le SKU, la quantité, la devise, le prix, la promotion, le stock, la logistique et le contexte de paiement prévus plutôt que de contrôler un seul enregistrement Admin.
Un Pass sur le canal direct peut-il approuver la préparation marketplace ?
Non. Identité seller, offres, mappings, trade policies, stock, responsabilité du traitement et propriété des Orders marketplace nécessitent des éléments séparés.
Les Orders migrés prouvent-ils que VTEX Logistics et OMS sont prêts ?
Non. Les Orders historiques prouvent la lisibilité des transactions. Entrepôts, docks, shipping policies, transporteurs, Payments, OMS et traitement actuels nécessitent une validation cible séparée.
Comment approuver des enregistrements Master Data ?
Confirmez l’entité, l’ID document, le schéma, les valeurs de champs, les relations, les clés externes et l’application ou le workflow qui consomme le document.
Que faut-il revalider après une action de migration VTEX ultérieure ?
Revalidez chaque nouvel enregistrement ou enregistrement modifié, ainsi que chaque hypothèse trade policy, seller, offre, logistique, Master Data, storefront ou intégration affectée. produce a distinct new migration result exige une nouvelle base de validation complète.