La validación de una migración hacia VTEX debe demostrar que los registros migrados funcionan a través de los dominios que controlan el comercio. Un Product puede existir mientras su SKU, specifications, asociación con Trade Policy, precio, inventario, Logistics, offer del seller o indexación de Storefront impide la compra. Un Customer o documento de Master Data puede existir mientras la relación, la clave o el flujo de trabajo consumidor son incorrectos. Un Order puede existir mientras no sea posible reconciliar seller, líneas, pago o contexto de preparación de pedidos.
La evidencia debe seguir las relaciones reales de VTEX: Category y Brand con Product; Product con SKU y specifications; SKU con precio y disponibilidad; Trade Policy con Catalog y condiciones comerciales; seller con offer y Orders de marketplace; Customer con Master Data o registros B2B; y Order con evidencia de OMS y Logistics.
Utilice Pass, Watch y Block en todos los dominios de VTEX
- Pass: evidencia representativa y de excepciones demuestra el comportamiento previsto de VTEX.
- Watch: el resultado es utilizable, pero sigue pendiente una corrección documentada que no bloquea, una tarea de configuración del destino, una decisión de responsable o una diferencia aceptada.
- Block: el problema afecta materialmente a ventas, precios, responsabilidad de sellers, inventario, Logistics, Customers, Orders históricos, contenido, SEO, continuidad de integraciones, cumplimiento o alcance de migración acordado.
| Dominio de evidencia | Prueba en VTEX | Condición típica de Block |
|---|---|---|
| Catalog | Categories, Brands, Products, SKUs, specifications, imágenes y activación permiten comprar correctamente. | Un SKU prioritario no puede seleccionarse o comprarse correctamente. |
| Contexto comercial | Trade Policies, precios, Promotions y surtido producen el resultado previsto por canal. | Un canal material recibe un Product o precio incorrecto. |
| Marketplace | Identidad de sellers, offers, correspondencias de Catalog y responsabilidad de Orders permanecen coherentes. | Un Product u Order de seller queda atribuido incorrectamente. |
| Logistics | Inventory, warehouses, docks, políticas de envío y contexto de entrega sostienen disponibilidad. | Stock válido aparece no disponible o se vende stock que no está disponible. |
| Customers y Orders | Perfiles, registros B2B, Master Data, líneas, totales, status y referencias siguen siendo comprensibles. | No puede reconciliarse una relación de cuenta o un Order histórico material. |
| Alcance personalizado | Apps, integraciones, resultados de migración admitidos, entregables no estándar e IDs externos funcionan a través de su responsable. | Un flujo de trabajo crítico para lanzamiento pierde datos o una clave estable. |
El informe final debe identificar la cuenta, Trade Policy, seller, SKU, warehouse, shipping policy, entidad de Master Data y contexto de integración revisados. Un Pass general de Catalog no debe ocultar un seller o canal de ventas bloqueado.
Las decisiones de VTEX deben conservar la responsabilidad por dominio. Catalog, Pricing, Promotions, Logistics, OMS, Marketplace, Master Data, Search y equipos de Storefront pueden alcanzar resultados distintos para el mismo Product u Order; el informe de lanzamiento no debe comprimirlos en un único estado indiferenciado.
Utilice pruebas representativas para demostrar supuestos de Catalog y canal
Las pruebas representativas deben incluir registros que expongan la arquitectura de VTEX:
- Products con varios SKUs y specifications que definen variaciones;
- Categories con grupos heredados de Product y SKU specifications;
- SKUs con imágenes, identificadores, precios, inventario y dependencias de activación;
- Products disponibles bajo distintas Trade Policies;
- Products de marketplace, sellers, offers y correspondencias de Catalog;
- Customers, registros B2B y documentos de Master Data con claves estables;
- Orders de contextos directos y de marketplace;
- warehouses, docks, políticas de envío y excepciones de entrega;
- contenido prioritario de Storefront, URLs y Products sensibles a Search;
- registros propiedad de aplicaciones e identificadores externos.
La evidencia representativa debe mostrar si las variantes del origen se convirtieron en SKUs de VTEX, si Product specifications y SKU specifications conservan su significado y si las relaciones de Trade Policy y sellers apuntan a los registros previstos. Un error estructural repetible es un Block antes de ampliar la ejecución de la migración.
La muestra debe incluir registros inactivos, sin stock, incompletos o excepcionales. Los SKUs activos y limpios por sí solos no demuestran los límites de activación y disponibilidad que suelen causar problemas de lanzamiento en VTEX.
Valide Categories, Brands, Products, SKUs y specifications
VTEX Catalog usa Categories y Brands para organizar Products, mientras los SKUs representan las variaciones físicas que compra el cliente. Los grupos de specifications vinculados con Categories definen campos de Product y SKU.
| Evidencia de Catalog | Pass | Watch | Block |
|---|---|---|---|
| Relación Product-SKU | Cada SKU previsto permanece unido al Product correcto. | Sigue pendiente un ajuste menor de orden visual. | Faltan SKUs, están duplicados o unidos al Product equivocado. |
| Specifications | Los valores de Product y SKU usan campo, tipo y vocabulario previstos. | Sigue pendiente limpieza de bajo impacto. | El significado para selección de variaciones, filtros, integración o cumplimiento es incorrecto. |
| Imágenes | Las imágenes necesarias del SKU se muestran y permiten una selección correcta. | Sigue pendiente ordenamiento secundario. | Un SKU prioritario no puede activarse o identificarse correctamente. |
| Brand y Category | La asignación de Products sostiene descubrimiento y clasificación previstos. | Sigue pendiente refinamiento de merchandising. | Products prioritarios quedan inaccesibles o mal clasificados. |
| Identificadores | Product, SKU, referencia, EAN o claves externas identifican la unidad correcta. | Sigue pendiente limpieza de duplicados no críticos. | Pricing, inventario, seller o integración se resuelven hacia el SKU equivocado. |
| Activación | Product y SKU cumplen los prerrequisitos de disponibilidad previstos. | Sigue pendiente publicación controlada. | Un SKU prioritario no puede ofrecerse en el canal previsto. |
Valide mediante Admin, Storefront o resultados de Search, detalle de Product, carrito, línea de Order y sistemas externos. Un registro de Catalog no debe aprobarse simplemente porque existan sus IDs de Product y SKU.
La evidencia de specifications debe distinguir propiedades descriptivas de Product de valores usados para seleccionar SKUs. Un valor puede parecer correcto en Admin y fallar si pertenece al campo, grupo, ruta de herencia de Category o SKU equivocado.
Incluya SKUs cuya activación dependa de imágenes, specifications y datos comerciales completos. Esto expone registros de Catalog que existen técnicamente pero no pueden participar correctamente en selección de Products o disponibilidad en Storefront.
Valide Trade Policies, precios, Promotions y surtido
Las Trade Policies pueden conectar disponibilidad de Catalog, precios, Promotions, inventario, Logistics, Payments y distintos canales de ventas. Valide dentro del contexto real del canal.
| Evidencia comercial | Prueba necesaria |
|---|---|
| Asociación con Trade Policy | Products y SKUs previstos están disponibles únicamente en el contexto de canal correcto. |
| Price | SKU, seller, Trade Policy, cantidad y moneda exactos producen el precio previsto. |
| Promotion | Condiciones y exclusiones generan el resultado comercial esperado. |
| Restricción de surtido | Los Products excluidos de un canal permanecen no disponibles allí. |
| Contexto de inventario | La disponibilidad sigue las relaciones de warehouse y Logistics usadas por la Trade Policy. |
| Contexto de Payment o Checkout | La configuración actual del destino muestra los métodos previstos por separado de la evidencia histórica de Orders. |
Un precio numérico dentro de Pricing no es evidencia suficiente. Pruebe el resultado que ve el comprador con seller, Trade Policy y cantidad previstos. Utilice Block para errores materiales de precios o surtido y Watch para trabajo documentado de configuración o presentación que no sea crítico.
Los descuentos históricos de Orders permanecen como instantáneas transaccionales. No demuestran que las Promotions o condiciones actuales de Trade Policy estén configuradas correctamente.
Cuando varias Trade Policies compartan parte del Catalog, compare SKUs incluidos y excluidos. La evidencia positiva demuestra disponibilidad; la negativa demuestra que surtido restringido y condiciones comerciales no se filtran a otro canal.
Valide sellers, offers, correspondencias de marketplace y responsabilidad de Orders
Las operaciones de marketplace de VTEX separan identidad canónica de Catalog de offers específicas de sellers. Un seller puede aportar precio, inventario, preparación de pedidos y responsabilidad comercial para un artículo representado en el Catalog del marketplace.
Revise:
- identidad y estado del seller;
- correspondencia del seller SKU u offer hacia Product y SKU previstos;
- contexto de Trade Policy y surtido;
- seller, precio e inventario;
- responsabilidad de preparación de pedidos;
- claves de correspondencia de Category o Product de marketplace;
- origen de Order, atribución de seller y referencias de comisión o liquidación cuando estén incluidas;
- identificadores externos de marketplace y conectores.
Utilice Block cuando una offer apunte al SKU equivocado, un seller pierda responsabilidad, un Order de marketplace quede atribuido incorrectamente o liquidación y preparación de pedidos no puedan identificar al seller responsable. Utilice Watch para configuración controlada del conector cuando la relación de Catalog migrada y los identificadores estén completos.
La evidencia de marketplace no debe promediarse con la evidencia de la Store directa. Un Product puede aprobar en Storefront propio y bloquear marketplace porque offer del seller, Trade Policy, inventario o correspondencia son incorrectos.
Valide inventario, warehouses, docks, políticas de envío y contexto de OMS
VTEX Logistics puede conectar inventario con warehouses, loading docks, políticas de envío, carriers, Trade Policies y opciones de entrega. Valide las relaciones que determinan disponibilidad y promesa de entrega.
| Evidencia de Logistics | Foco de validación |
|---|---|
| Inventory | La cantidad pertenece al SKU y warehouse correctos. |
| Warehouse | El warehouse tiene stock y relación de dock previstos. |
| Loading dock | El dock conecta warehouses, carriers y Trade Policies previstos. |
| Shipping policy | Reglas, rates, niveles de servicio y estado activo sostienen el contexto de destino esperado. |
| Disponibilidad de SKU | El comprador ve disponibilidad y opción de entrega previstas para Trade Policy y seller. |
| Preparación de pedidos del Order | Orders históricos conservan seller, delivery, status y referencias externas. |
| Autoridad externa | ERP, WMS o carrier identifican SKU, warehouse y Order correctos. |
Un total correcto de inventario puede fallar si el stock está asignado al warehouse equivocado o desconectado del dock y shipping policy relevantes. Marque como Block los fallos prioritarios de disponibilidad.
Los Orders migrados no configuran Logistics activa. Warehouses, docks, políticas de envío, carriers, pickup points, comportamiento de SLA y operaciones de OMS actuales requieren aprobación separada en destino.
Pruebe al menos una combinación de destino de entrega y SKU para cada ruta material de Logistics. Esto revela relaciones rotas warehouse-dock-shipping policy que los totales de inventario y estados de Admin no muestran por sí solos.
Valide Customers, relaciones B2B, Master Data y Orders históricos
Los datos relacionados con Customers pueden abarcar identidad de perfil, direcciones, organizaciones B2B, roles, centros de coste, consentimiento, IDs de CRM y documentos de Master Data. Valide la entidad y la clave, no solo campos visibles.
| Evidencia de Customer | Prueba necesaria |
|---|---|
| Identidad de perfil | Email, documento, teléfono o clave externa identifican a la persona prevista. |
| Dirección | La dirección actual del perfil y la dirección histórica de Order permanecen separadas cuando corresponde. |
| Entidad B2B | Organización, usuario, rol, centro de coste, Catalog o relación de aprobación siguen correctamente unidos. |
| Documento de Master Data | Entidad, document ID, schema, campos, relaciones y consumidor son correctos. |
| Identificador externo | CRM, ERP, loyalty, marketplace o soporte pueden localizar el mismo Customer u organización. |
| Order histórico | Customer, seller, líneas SKU, precios, Promotions, Payments, shipping, status e IDs externos siguen siendo comprensibles. |
Utilice Block cuando combinar identidades no sea seguro, una relación B2B esté rota, una referencia de Master Data apunte a la entidad equivocada o un Order material no pueda reconciliarse.
Los Orders históricos no demuestran que Checkout, Payments, Promotions, Logistics, OMS, notificaciones, invoices, reembolsos o flujos de trabajo de segmentación de Customers actuales estén listos. Estas áreas requieren aprobación operativa separada.
La evidencia de Master Data debe incluir campos de relación y documentos referenciados, no solo el cuerpo del documento. Un valor de perfil correcto puede fallar si una organización, centro de coste, aplicación o flujo de trabajo apunta a un identificador obsoleto.
Valide Storefront, Search, URLs y continuidad del contenido
La evidencia de Storefront en VTEX puede incluir indexación de Search, disponibilidad de Products, Categories, Brands, filtros, páginas de contenido, navegación, rutas SEO y presentación administrada por aplicaciones. Valide desde la ruta del comprador, no solo desde presencia en Catalog.
La evidencia representativa debe incluir:
- búsquedas prioritarias de Products y SKUs;
- descubrimiento por Category y Brand;
- filtros impulsados por specifications;
- selección y disponibilidad en Product detail;
- URLs prioritarias del origen y destinos previstos;
- metadata, media y enlaces internos;
- contenido de políticas, servicio y campañas;
- diferencias de locale o domain cuando se utilicen;
- referencias de contenido headless o administrado por aplicaciones.
Utilice Block ante fallos generalizados de indexación prioritaria, selección rota de SKUs, contenido obligatorio ausente o pérdida de URLs de alto valor. Utilice Watch para trabajo controlado de presentación, indexación o metadata cuando registros y responsable estén completos.
Catalog, Search e implementación de Storefront están relacionados pero son distintos. Un Product puede existir en Catalog y seguir ausente de Search o no disponible bajo la Trade Policy prevista.
Valide aplicaciones, integraciones, ajustes admitidos y resultados personalizados acordados
Las Stores de VTEX suelen conectar Catalog, Pricing, Logistics, OMS, Master Data, sellers, Search, aplicaciones de Storefront, ERP/PIM/WMS, CRM, marketplaces, impuestos, Payments y sistemas de analítica. Valide datos personalizados mediante el dominio y consumidor reales.
Para cada valor crítico, documente:
- dominio VTEX y entidad responsable;
- aplicación o sistema externo;
- identificador de Product, SKU, seller, Customer, Master Data u Order;
- dirección prevista de sincronización;
- evidencia representativa de éxito y excepción;
- responsable de despliegue o configuración pendiente.
Valide resultados admitidos y personalizados acordados contra el alcance documentado. Una specification transformada, seller correspondencia, documento de Master Data, ID externo o relación personalizada debe probarse mediante API, aplicación, módulo Admin, Storefront o sistema externo que realmente la consume.
Utilice Block cuando el valor quede huérfano, sea incompatible o no pueda rastrearse dentro de un flujo de trabajo crítico para lanzamiento. Utilice Watch cuando el despliegue restante de aplicación o integración quede fuera del alcance de migración y estén completos dominio VTEX, contrato de datos, clave estable y responsable.
Distinga pruebas representativas de la evidencia de ejecución más amplia
Las pruebas representativas demuestran supuestos estructurales seleccionados. La ejecución más amplia debe demostrar el alcance completo de Catalog, canales, sellers, Logistics, Customers, Orders, contenido e integraciones.
La evidencia de ejecución más amplia debe incluir:
- cada patrón principal de Product y SKU;
- campos y valores completos de specifications;
- cobertura de surtido y precios por Trade Policy;
- todas las offer del sellers y correspondencias de marketplace en alcance;
- inventario, warehouses, docks y referencias relevantes de Logistics;
- Customers, registros B2B, documentos de Master Data y Orders históricos;
- Storefront, Search, URLs prioritarias y contenido;
- todos los resultados admitidos y personalizados;
- excepciones de aplicaciones e IDs externos;
- cambios introducidos después de la migración de prueba representativa.
Reabra un Pass de prueba representativa cuando la ejecución más amplia revele SKU specifications inconsistentes, imágenes ausentes, fallos de activación, asociaciones incorrectas con Trade Policies, fallos de seller correspondencia, desajustes de warehouses, documentos de Master Data huérfanos, Customers duplicados u Orders sin reconciliar.
Segmente excepciones por Trade Policy, seller, Category, familia de Product, grupo de specifications, warehouse, entidad Customer/B2B y periodo del origen. Los totales agregados pueden ocultar un fallo completo en un canal o seller.
Revalide después de acciones posteriores de migración
| Acción posterior | Alcance de revalidación en VTEX |
|---|---|
| continuar con la configuración aprobada | Validar registros recién elegibles y confirmar que los supuestos anteriores de Catalog, Trade Policies, sellers, Logistics, Customers, Orders, contenido e integraciones siguen siendo válidos. |
| continuar con una configuración revisada | Revalidar cada relación afectada por cambios en filtros, correspondencias, selección de tipos de datos o configuración, incluidas aprobaciones previas. |
| producir un resultado de migración distinto | Tratar la salida como un resultado migrado independiente y repetir toda la validación y decisión de lanzamiento de VTEX. |
Conserve juntas decisiones anteriores y nuevas. Si cambia identidad de Product o SKU, asignación de Trade Policy, seller correspondencia o correspondencia de Customers, Orders aprobados previamente, referencias de Logistics e integraciones también pueden requerir revisión.
La revalidación de VTEX debe seguir referencias entre dominios. Un cambio en SKU correspondencia puede afectar precio, inventario, offer del sellers, Logistics, Search y evidencia de Orders; un cambio en clave de Customer puede afectar Master Data, B2B y asociaciones históricas de Orders.
Construya la decisión de lanzamiento de VTEX
La aprobación del lanzamiento requiere:
- ningún Block sin resolver que afecte Catalog, precios, sellers, inventario, Logistics, Customers, Orders históricos, descubrimiento en Storefront, SEO, cumplimiento o integraciones;
- prueba representativa completada y evidencia de ejecución más amplia;
- prueba de los resultados admitidos y personalizados acordados;
- aprobación separada de Pricing, Promotions, Checkout, Payments, Logistics, OMS, operaciones de sellers, Search y despliegue de aplicaciones activos en VTEX;
- revalidación después de las acciones posteriores aplicables;
- responsables y fechas de cierre definidos para elementos Watch.
Mantenga estados separados para preparación de Catalog, canales/precios, marketplace, Logistics, datos históricos, Storefront/Search e integraciones. Un Storefront directo aprobado no debe ocultar una relación de seller o Logistics bloqueada.
Conclusión
La validación de VTEX debe demostrar que Catalog, SKUs, specifications, Trade Policies, sellers, Logistics, Customers, Master Data, Orders, contenido e integraciones funcionan juntos dentro del contexto previsto de canal de ventas.
Las pruebas representativas establecen confianza estructural, la ejecución más amplia demuestra completitud y excepciones, y las acciones posteriores requieren revalidación focalizada o completa. La aprobación del lanzamiento debe basarse en evidencia documentada Pass, Watch y Block.
Preguntas frecuentes
¿Por qué deben validarse Products y SKUs de VTEX por separado?
Products conserva la identidad genérica de Catalog, mientras los SKUs representan las unidades físicas o seleccionables que compra el cliente. Specifications, imágenes, precios, inventario y offer del sellers pueden depender del SKU.
¿Cómo debe probarse la evidencia de Trade Policy?
Use conjuntamente canal de ventas, seller, SKU, cantidad, moneda, precio, Promotion, inventario, Logistics y contexto de Payments previstos, en lugar de revisar un único registro de Admin.
¿Un Pass en la Store directa puede aprobar la preparación de marketplace?
No. Identidad de sellers, offers, correspondencias, Trade Policies, inventario, responsabilidad de preparación de pedidos y propiedad de Orders de marketplace requieren evidencia separada.
¿Los Orders migrados demuestran que Logistics y OMS activos de VTEX están listos?
No. Los Orders históricos demuestran legibilidad transaccional. Warehouses, docks, políticas de envío, carriers, Payments, OMS y preparación de pedidos actuales requieren aprobación separada en destino.
¿Cómo deben aprobarse los registros de Master Data?
Confirme entidad, document ID, schema, valores de campos, relaciones, claves externas y aplicación o flujo de trabajo que consume el documento.
¿Qué requiere revalidación después de una acción posterior de migración hacia VTEX?
Revalide cada registro VTEX nuevo o modificado y cada supuesto de Trade Policy, seller, offer, Logistics, Master Data, Storefront o integración afectado por la acción. Producir un resultado de migración distinto requiere una base de evidencia completa e independiente.