La validación de Adobe Commerce debe demostrar que los registros migrados respaldan el modelo operativo empresarial previsto. Un Product puede existir en el Admin mientras sus Products simples asociados, valores de atributos, asignación a catálogo compartido, contenido por store view, inventario por source o precio específico por comprador producen un resultado comercial incorrecto. Una cuenta Company puede existir y, aun así, impedir que sus compradores accedan al catálogo, permisos o contexto de compra previstos.
El conjunto de evidencias debe seguir las relaciones reales de Adobe Commerce: familia de Products con SKU asociados; conjunto de atributos con opciones visibles para el comprador; Company con usuarios y catálogo compartido; website con store y store view; source con stock y disponibilidad vendible; Order histórico con Customer y contexto de transacción; e identificador externo con el sistema que lo consume. Los recuentos ayudan a conciliar, pero no pueden aprobar el lanzamiento por sí solos.
Definir evidencias empresariales y responsables de decisión
Utilice un único estado de decisión para cada área material de prueba:
- Pass: la evidencia representativa y de excepciones demuestra el funcionamiento previsto de Adobe Commerce.
- Watch: el resultado es utilizable, pero queda una corrección no bloqueante documentada, una tarea de configuración, una decisión de responsable o una diferencia aceptada de plataforma.
- Block: el problema afecta materialmente compras, acceso B2B, precios, inventario, alcance de tiendas, Orders históricos, contenido, SEO, continuidad de integraciones, cumplimiento o alcance acordado de migración.
| Área de evidencia | Qué debe demostrar Adobe Commerce | Condición típica de Block |
|---|---|---|
| Arquitectura de catálogo | Tipos de Product, Products asociados, atributos, precios, media y relaciones de Categories sostienen el proceso de compra previsto. | Una familia prioritaria no puede configurarse, fijar su precio o comprarse correctamente. |
| Estructura B2B | Companies, usuarios Company, roles, catálogos compartidos y acceso de compradores se alinean con el modelo operativo. | Un grupo importante ve el surtido, precio o acceso de cuenta equivocados. |
| Alcance de tienda | Websites, stores y store views muestran Products, contenido, idioma, URLs y contexto de Customers previstos. | Una tienda prioritaria carece de datos o muestra datos de otro alcance. |
| Inventario | Sources, stocks, asignaciones de canales, reservas y disponibilidad vendible permiten vender y procesar pedidos correctamente. | Los compradores pueden comprar stock no disponible o no pueden comprar stock válido. |
| Orders y Customers | Identidad Company/Customer, líneas, totales, direcciones, estados y referencias externas siguen siendo comprensibles. | Soporte, finanzas u operaciones no pueden conciliar un Order histórico relevante. |
| Alcance personalizado | Registros de extensiones, integraciones, resultados acordados y entregables no estándar funcionan en el sistema consumidor previsto. | Un proceso crítico pierde los datos o identificadores que necesita. |
La decisión debe identificar el website, store view, Company, catálogo compartido, SKU, stock de inventario y contexto de integración concretos revisados. Un Pass general para toda la tienda no basta cuando distintos alcances empresariales pueden producir resultados diferentes.
Las evidencias empresariales también deben identificar al responsable de negocio de cada alcance. Equipos de catálogo, B2B, inventario, contenido, finanzas e integraciones pueden aprobar partes distintas del mismo resultado migrado; ninguna comprobación técnica individual debe aprobar de forma implícita el ámbito operativo de otro equipo.
Utilizar pruebas representativas para demostrar el modelo empresarial
Las pruebas representativas deben diseñarse alrededor de supuestos estructurales y no de registros fáciles. Incluya:
- Products simples, configurables, grouped, bundle, virtuales y descargables cuando proceda;
- familias configurables con varios SKU asociados, swatches, imágenes, precios y condiciones de inventario;
- Products de diferentes conjuntos de atributos y Categories;
- cuentas Company con distintos roles o permisos de compra;
- Companies asignadas a catálogos compartidos públicos o personalizados;
- ejemplos de precios específicos por comprador y grupo de Customers;
- registros de cada website, store y store view importante;
- Products asignados a varias sources y stocks;
- Customers y Orders con descuentos, impuestos, reembolsos, envíos o contexto B2B;
- CMS Pages, bloques, contenido programado y URLs prioritarios;
- registros gestionados por extensiones e identificadores externos.
Un hallazgo de prueba representativa es Block cuando revela un error estructural que la ejecución más amplia repetiría, como Products secundarios configurables mapeados incorrectamente, usuarios Company separados de su empresa, precios de catálogo compartido asignados al grupo de compradores equivocado o inventario asociado a la source o stock incorrectos.
La prueba representativa no necesita cubrir todo el volumen. Debe demostrar que las muestras seleccionadas exponen las principales relaciones empresariales y que la evidencia puede ser reproducida por los responsables de negocio y técnicos.
Validar tipos de Product, atributos y funcionamiento del catálogo
La validación de Products debe cubrir los tipos que la tienda realmente utiliza. Un Product configurable depende de Products simples asociados con SKU e inventario propios. Bundle y grouped Products dependen de relaciones de componentes. Products descargables y virtuales tienen un significado de entrega distinto. Las custom options pueden recopilar elecciones del comprador sin crear Products asociados con inventario independiente.
| Evidencia de Product | Pass | Watch | Block |
|---|---|---|---|
| Tipo de Product | El tipo de destino permite la compra y el procesamiento del pedido previstos. | Queda una diferencia de presentación no crítica. | El Product no puede comprarse o procesarse como se esperaba. |
| Products asociados | Relaciones principal-secundario, SKU, precios, media y valores de opción son correctos. | Queda por corregir orden o etiquetado menor. | Faltan secundarios, están duplicados o se asocian al principal equivocado. |
| Conjuntos de atributos | Los Products utilizan los campos necesarios para su familia. | Campos opcionales requieren limpieza. | Faltan atributos obligatorios o se asignan a la clase incorrecta. |
| Búsqueda y navegación por filtros | Los atributos buscables y filtrables muestran valores útiles. | Quedan mejoras de filtros de baja prioridad. | Los compradores no pueden encontrar una familia prioritaria. |
| Asignación a Categories | Products aparecen en la Category y alcance de tienda previstos. | Queda orden de merchandising. | Products no son accesibles o aparecen ante el comprador equivocado. |
| Media y URLs | Imágenes, swatches, metadatos y rutas públicas permiten identificar y seleccionar correctamente. | Queda limpieza de media secundaria. | La identidad de Product o una ruta prioritaria es materialmente incorrecta. |
Valide tanto en la tienda pública como en Admin. Un Product puede aprobar la revisión del comprador y fallar operativamente si el personal no puede interpretar su conjunto de atributos, SKU secundario, inventario por source o clave de integración. A la inversa, un registro Admin limpio falla si el comprador previsto no puede encontrarlo o comprarlo.
Incluya también valores de Product con alcance por store view. Nombres, descripciones, etiquetas de opciones, metadatos, URLs y media pueden verse correctos en el alcance predeterminado y faltar o ser incorrectos en vistas localizadas.
Validar Companies B2B, compradores, catálogos compartidos y precios
La validación B2B debe distinguir registros individuales de Customers de relaciones Company. Administradores Company, usuarios, roles, permisos, catálogos compartidos, precios negociados, aprobaciones de compra, contexto de crédito e identificadores externos pueden participar en un mismo recorrido de compra.
| Evidencia B2B | Prueba requerida |
|---|---|
| Identidad Company | El registro, estado, direcciones, IDs externos y responsabilidad administrativa son comprensibles. |
| Usuarios Company | Usuarios representativos siguen conectados con Company y rol correctos. |
| Permisos de compradores | Los compradores solo pueden realizar las acciones de compra y cuenta previstas. |
| Asignación de catálogo compartido | La Company recibe el catálogo público o personalizado correcto. |
| Selección de Products | Los Products y Products asociados necesarios están disponibles en el catálogo asignado. |
| Precios personalizados | Product, cantidad y contexto Company producen el precio previsto. |
| Relación con grupo de Customers | Las asignaciones Company y catálogo producen el contexto esperado de grupo de Customers. |
Valide mediante una sesión real de comprador, no solo desde la cuadrícula Admin. Un catálogo compartido puede existir pero carecer de Products necesarios, omitir componentes asociados de un Product complejo o mostrar precios personalizados a la empresa equivocada. Estos resultados son Blocks de lanzamiento.
En tiendas híbridas B2B/B2C, mantenga separadas las decisiones de la tienda minorista y de compradores Company. La tienda B2C puede pasar mientras una Company B2B queda bloqueada por catálogo, precio, rol o jerarquía. El informe final debe conservar estos estados separados.
Validar websites, stores, store views y alcance de contenido
Adobe Commerce utiliza una jerarquía website–store–store view. La validación debe demostrar el alcance previsto para asignación de Products, Categories raíz, funcionamiento de Customers, precios, idioma, contenido, URL keys, metadatos y registros sensibles a configuración.
Revise cada alcance comercialmente relevante:
- contexto de Product y Customer a nivel de website;
- Categories raíz y navegación a nivel de store;
- traducciones y contenido localizado por store view;
- relaciones de dominio, base URL, moneda y locale cuando correspondan;
- visibilidad de surtidos B2C y B2B;
- CMS Pages, blocks, widgets y campañas programadas;
- URLs y redirecciones prioritarias de Products y Categories.
Use Watch cuando los datos subyacentes sean correctos, pero quede trabajo controlado de tema, navegación o colocación de contenido. Use Block cuando un store view prioritario muestre Product, idioma, precio, ruta, contenido de políticas o acceso de comprador incorrectos.
Content Staging merece evidencia independiente cuando forma parte del modelo operativo. Confirme que el contenido actual migrado y cualquier registro programado acordado tienen versión, calendario, alcance y destino previstos. No asuma que registros históricos de Staging recrearán una programación activa salvo que ese resultado forme parte del alcance y haya sido verificado.
Validar sources, stocks, reservas y disponibilidad
Adobe Commerce Inventory Management separa sources físicas, stocks agregados, asignación de canales de venta, cantidades por source, reservas y cantidad vendible. Copiar una cantidad no demuestra que el Product pueda venderse o procesarse desde la ubicación prevista.
| Evidencia de inventario | Enfoque de validación |
|---|---|
| Asignación de source | El SKU está asignado al almacén, tienda, punto de recogida o source de procesamiento del pedido correcto. |
| Cantidad por source | La cantidad pertenece al SKU y source física correctos. |
| Relación de stock | Los websites o canales previstos utilizan el stock correcto. |
| Disponibilidad vendible | La disponibilidad pública refleja cantidades por source, reservas y configuración como se esperaba. |
| Familia configurable | La disponibilidad del principal sigue a los Products asociados válidos. |
| Autoridad externa | IDs de ERP, WMS o marketplace siguen apuntando al SKU y relación de source correctos. |
| Orders históricos | Los Orders importados no generan reservas ni movimientos de stock nuevos no deseados. |
Un Product visible pero no vendible requiere diagnóstico de estado, disponibilidad de secundarios, asignación de source, asignación de stock, reservas, backorders y alcance de tienda. Marque Block cuando afecte un Product prioritario o provoque sobreventa.
La evidencia de inventario migrado sigue separada de la configuración activa de almacenes, selección de source, recogida, transportistas o ERP. Estos sistemas necesitan su propia aprobación operativa aunque las cantidades iniciales sean correctas.
Validar Customers, Orders, pagos e historial de procesamiento del pedido
La validación de Customers y Orders debe demostrar que el historial comercial sigue siendo comprensible. Incluya Customers minoristas, compradores Company, invitados, varias direcciones, grupos de Customers, IDs externos y patrones propensos a duplicados.
Los Orders históricos deben conservar líneas de Products/SKU, opciones configuradas, contexto Company o Customer, direcciones, precios, descuentos, impuestos, envío, referencias de pago, estados, facturas, envíos, credit memos, comentarios e IDs externos cuando estén incluidos.
Los Orders migrados no demuestran que proceso de compra activo, gateways de pago, impuestos, fraude, envíos, selección de source, procesamiento de pedidos, notificaciones, devoluciones, aprobaciones de compra o procesos de crédito estén preparados. Son configuraciones o integraciones actuales de Adobe Commerce con responsables separados.
Use Block cuando un Order material tenga totales incorrectos, pierda configuración de líneas, se vincule al Customer o Company equivocados o no pueda conciliarse con finanzas o procesamiento del pedido. Use Watch para diferencias cosméticas aceptadas o exclusiones históricas no críticas documentadas.
El informe debe indicar si el Order se aprueba para lectura por atención a Customers, conciliación financiera, informes operativos o los tres. Cada finalidad puede requerir evidencias diferentes.
Validar extensiones, integraciones, ajustes compatibles y resultados de migración a medida
Las implementaciones de Adobe Commerce suelen depender de extensiones, módulos personalizados, integraciones ERP/PIM/WMS, servicios de búsqueda, proveedores fiscales, conectores de marketplace, servicios de pago y datos específicos. La presencia de un valor en un atributo o tabla personalizada no demuestra que el proceso que lo seguirá utilizando pueda consumirlo.
Para cada valor personalizado crítico para el lanzamiento, documente:
- entidad de Adobe Commerce o tabla personalizada propietaria;
- extensión, módulo o sistema externo que lo consume;
- identificador estable de Product, Customer, Company u Order;
- dirección esperada de sincronización;
- evidencia representativa de éxito y excepción;
- responsable de configuración o despliegue aún pendiente.
Valide los resultados compatibles y a medida acordados contra su alcance documentado. Un mapeo, filtro, reestructuración o campo personalizado entregado debe probarse a través de la tienda pública, Admin, API, extensión o proceso externo que lo utiliza. La validación verifica el resultado entregado; no redefine qué servicio debería haberse elegido.
Use Block cuando una integración necesaria no pueda identificar el registro migrado, una relación personalizada quede huérfana o una extensión crítica reciba un valor incompatible. Use Watch cuando despliegue o configuración queden fuera del alcance de migración, pero los datos y responsables estén completos.
Distinguir las pruebas representativas de la evidencia de una ejecución más amplia
Las pruebas representativas demuestran supuestos estructurales seleccionados. Una ejecución más amplia debe demostrar alcance completo, volumen, relaciones y excepciones.
La evidencia de una ejecución más amplia debería incluir:
- todos los tipos de Product y conjuntos de atributos principales;
- cobertura completa de websites, stores y store views;
- integridad de Companies y catálogos compartidos;
- asociaciones de Customers y Orders;
- sources, stocks e IDs externos de inventario;
- CMS Pages, blocks, contenido programado y redirecciones prioritarios;
- todos los resultados compatibles y a medida acordados;
- informes de excepciones de extensiones e integraciones;
- cambios introducidos después de la prueba representativa.
Un Pass obtenido en la prueba representativa debe reabrirse cuando la ejecución amplia revele valores de atributos inconsistentes, Products asociados ausentes, asignaciones Company incompletas, lagunas de catálogos compartidos, sobrescritura de store views, diferencias de inventario por source, Customers duplicados, Orders huérfanos o fallos de registros personalizados.
La revisión de volumen completo debe segmentar excepciones por website, store view, Company, catálogo compartido, familia de Product, conjunto de atributos, ubicación de source y periodo de origen. Los totales agregados pueden ocultar un fallo completo dentro de un segmento empresarial.
Volver a validar después de acciones de migración posteriores
| Acción posterior | Alcance de revalidación en Adobe Commerce |
|---|---|
| Continue the Migration with the Last Used Configuration | Validar nuevos registros elegibles y confirmar que los supuestos previos sobre Products, Companies, catálogos compartidos, alcance, inventario, Customers, Orders, contenido e integraciones siguen siendo válidos. |
| Continue the Migration with a New Configuration | Revalidar todas las relaciones afectadas por cambios de filtros, mapeos, selección de tipos de datos o configuración, incluida evidencia previamente aprobada. |
| Perform a New Migration | Tratar la salida como un resultado de migración distinto y repetir toda la validación de Adobe Commerce y la decisión de lanzamiento. |
Conserve la decisión anterior junto a la nueva. Una familia de Products, Company o store view que pase de Pass a Watch o Block necesita una causa declarada y nueva evidencia.
En Adobe Commerce, la revalidación debe rastrear cadenas de dependencias. Cambiar una asignación Company puede modificar acceso a catálogos compartidos y grupos de Customers; cambiar un SKU asociado puede alterar inventario y referencias de Orders; cambiar el mapeo de un store view puede modificar URLs, contenido y evidencia localizada de Products.
Construir la decisión de lanzamiento para Adobe Commerce
La aprobación del lanzamiento requiere:
- ningún Block sin resolver que afecte compras, acceso Company, catálogos compartidos, precios, alcance, inventario, Orders históricos, contenido, SEO, cumplimiento o integraciones;
- prueba representativa y evidencia de la ejecución más amplia completadas;
- demostración de los resultados compatibles y a medida acordados;
- aprobación separada para proceso de compra activo, pagos, fiscalidad, operaciones de inventario, envíos, procesamiento de pedidos, procesos B2B y despliegue de extensiones;
- revalidación después de acciones posteriores aplicables;
- responsables y fechas de cierre para elementos Watch aceptados.
El informe final debe conservar estados separados para preparación B2C, preparación B2B, preparación de datos históricos, inventario, contenido/SEO e integraciones. Un lanzamiento empresarial no debe aprobarse mediante un resultado promedio que oculte una Company o store view bloqueados.
Conclusión
La validación de Adobe Commerce debe demostrar que arquitectura de Products, atributos, Companies B2B, catálogos compartidos, tiendas con alcance, inventario, Customers, Orders, contenido y sistemas personalizados funcionan juntos dentro del contexto empresarial previsto.
Las pruebas representativas examinan el diseño empresarial a escala de muestra. La ejecución más amplia debe demostrar cobertura completa de empresas, catálogo, alcance, inventario, Orders, contenido e integraciones, mientras que acciones posteriores reabren cualquier dependencia que modifiquen. La decisión de lanzamiento debe basarse en evidencia documentada Pass, Watch y Block, no en la mera presencia de registros.
Preguntas frecuentes
¿Por qué deben validarse los catálogos compartidos de Adobe Commerce mediante cuentas de compradores?
Porque los registros de catálogos compartidos no demuestran acceso. Un comprador representativo de Company debe ver los Products, componentes asociados, Categories, precios y opciones de compra previstos a través del catálogo asignado.
¿Qué debe comprobarse para Products configurables?
Valide juntos Product principal, Products simples asociados, atributos de variación, SKU, precios, imágenes, inventario por source, estado vendible, asignación de Categories y resultado en líneas de Order.
¿Puede un Pass de un solo store view aprobar toda la instalación de Adobe Commerce?
No. Websites, stores y store views pueden contener asignaciones de Products, contenido, idiomas, URLs y configuraciones diferentes. Cada alcance comercialmente significativo necesita evidencia propia.
¿Los Orders migrados demuestran que los procesos B2B y de procesamiento del pedido están preparados?
No. Los Orders históricos demuestran legibilidad de transacciones. Aprobaciones activas, crédito, pagos, impuestos, reservas de inventario, envíos, selección de source y procesamiento de pedidos requieren configuración separada en destino y aprobación operativa.
¿Cómo deben aprobarse los datos de extensiones e integraciones?
Pruebe los valores migrados a través de la extensión, API o sistema externo que los consume, utilizando identificadores estables y registros representativos de excepción.
¿Qué debe revalidarse después de una acción posterior de migración en Adobe Commerce?
Repita la prueba para cada supuesto sobre Company, catálogo compartido, alcance de tienda, SKU, Order e integración que haya cambiado. Perform a New Migration requiere una nueva decisión completa de validación.