La validación de Square debe demostrar que los registros migrados funcionan dentro de las relaciones de catálogo, ubicaciones, inventario, Customers, Orders y sitio online de Square. Un recuento coincidente de artículos resulta útil para conciliar, pero no demuestra que pueda venderse la variación correcta, que el inventario pertenezca a la ubicación prevista, que los modificadores sigan diferenciados de las variantes, que los Customers puedan localizarse, que los Orders históricos sigan siendo comprensibles ni que Square Online presente el catálogo y las rutas previstos.
El modelo de prueba debe separar los datos migrados de la configuración activa de Square. Los Orders históricos pueden conservar líneas, ajustes, contexto de procesamiento y referencias de pago sin configurar los pagos o el procesamiento actuales. El catálogo puede estar completo mientras la navegación de Square Online, recogida, entrega, envío, dominios o presentación de páginas todavía necesitan trabajo en el destino. La aprobación del lanzamiento depende tanto de la evidencia migrada como de asignar un responsable a cada asunto pendiente de configuración o implementación.
Define el conjunto de evidencia para validar Square
La validación debe comenzar con registros representativos que expongan el modelo de relaciones de la plataforma. Los ejemplos sencillos confirman la transferencia básica; los difíciles revelan si se conservaron las estructuras que realmente utilizan el equipo, los procesos de inventario, atención al Customer y los sistemas conectados.
Cuando corresponda, el conjunto de evidencia de la prueba representativa debe incluir:
- un artículo sencillo con una única variación vendible;
- un artículo con varias variaciones definidas por opciones;
- un artículo que use modificadores en lugar de variaciones con inventario;
- una variación con inventario específico por ubicación;
- un artículo sensible a Category o con muchas imágenes;
- un Customer con varios Orders o con contexto de grupos/atributos personalizados;
- un comprador invitado o con identidad débil;
- un Order con descuentos, impuestos, cargos por servicio, propinas, procesamiento, reembolso o referencias externas;
- una ruta de alto valor de Item o Category en Square Online;
- un identificador propiedad de una aplicación o sistema externo.
| Tipo de evidencia | Prueba en una migración representativa | Prueba en una ejecución de migración más amplia |
|---|---|---|
| Catalog | Artículos, variaciones, opciones, modificadores, Categories, imágenes, impuestos y descuentos representativos conservan sus funciones previstas. | El catálogo completo sigue la estructura aprobada de artículos y variaciones sin excepciones no explicadas. |
| Inventario | Las variaciones seleccionadas muestran la cantidad, estado y relación de ubicación previstos. | Todas las cantidades variación-ubicación incluidas concilian con el modelo aprobado de inventario inicial. |
| Customers y Orders | Los ejemplos difíciles de Customer y Order siguen conectados y son legibles. | Se concilian el alcance histórico completo, exclusiones, duplicados y excepciones de relaciones. |
| Square Online | Ejemplos prioritarios de artículos, Categories, contenido, dominios y rutas llegan a los destinos previstos. | Todas las rutas prioritarias y contenido incluido tienen un resultado aprobado y un responsable. |
| Integraciones | Los IDs externos y registros propiedad de aplicaciones tienen responsables definidos y consumidores que pueden probarse. | Cada clave de integración y resultado personalizado incluido concilia en todo el alcance. |
Las pruebas representativas deben descubrir suposiciones antes de una ejecución más amplia. No deben aprobarse únicamente porque Products sencillos y Orders recientes parezcan correctos.
Valida Items, variaciones, opciones y modificadores
La biblioteca de artículos de Square distingue el artículo general de la variación que se vende. Las opciones pueden estandarizar atributos de variación como talla o color. Los modificadores representan añadidos o preferencias seleccionados durante la venta y no crean automáticamente una identidad independiente con stock. La validación debe demostrar que la estructura migrada refleja estas diferencias.
| Relación del Catalog | Evidencia para Pass | Señal para Watch | Señal para Block |
|---|---|---|---|
| Item y variación | El artículo principal y la variación vendible permanecen conectados; SKU, precio, imagen, unidad de medida e identificadores pertenecen a la variación prevista. | Queda limpieza menor de nombres u orden de visualización. | La identidad de la variación se aplana, duplica o conecta al artículo equivocado. |
| opciones de Item | Los valores de opción generan o describen de forma coherente las combinaciones previstas. | Las etiquetas o el orden necesitan normalización en el destino. | Los compradores no pueden seleccionar la combinación vendible correcta. |
| Modificadores | Los añadidos y preferencias opcionales siguen separados de las variaciones con inventario. | La presentación o agrupación necesita configuración. | Un modificador se convirtió en falso SKU o una variación real quedó como modificador sin stock. |
| Categories e imágenes | Los Items aparecen en las Categories correctas y conservan el significado de imagen principal, galería o variación. | El orden de medios de baja prioridad necesita ajustes. | Products prioritarios quedan ocultos, mal clasificados o sin imágenes esenciales. |
| Impuestos y descuentos | Las relaciones incluidas del catálogo se asocian a los Items previstos y los Orders históricos siguen siendo financieramente comprensibles. | La configuración actual de reglas todavía tiene un responsable asignado en el destino. | Los valores migrados generan precios visibles incorrectos o hacen incomprensibles los totales históricos. |
La validación también debe comprobar que el contenido pueda editarse. El equipo tiene que identificar el Item y la variación correctos, entender qué valores se comparten y cuáles son específicos de una variación, y actualizar el registro previsto sin crear identidades comerciales duplicadas. Incluye al menos un Product donde coexistan modificadores y opciones, porque la tienda puede parecer correcta aunque el equipo no pueda distinguir qué selección cambia inventario, precio o solo una preferencia realizada durante la venta.
Valida el inventario por variación y ubicación
Square controla inventario para Item Variations y puede hacerlo por ubicación. Una cantidad a nivel de Product es insuficiente cuando la tienda de origen utilizaba SKU hijos, sucursales, almacenes o bolsas de stock separadas. La evidencia debe conectar la cantidad tanto con la variación vendible como con la ubicación prevista de Square.
Para registros representativos con stock, confirma:
- que la Item Variation correcta tiene control de inventario;
- que SKU y claves externas identifican la misma unidad vendible;
- que la cantidad aparece en la ubicación activa prevista;
- que estados ilimitados, sin seguimiento, cero, reservados, dañados, devueltos u otros tienen un significado aprobado en Square;
- que una venta o devolución afectaría a la variación y ubicación previstas, no al artículo principal ni a otra sucursal;
- que un ERP, almacén o integración de canal puede seguir identificando la variación de destino cuando ese sistema mantiene la autoridad.
| Resultado | Interpretación para lanzamiento |
|---|---|
| La cantidad difiere únicamente porque cambió la marca temporal aprobada del inventario inicial | Watch, siempre que la diferencia esté explicada y exista un responsable para la regla final de cambio. |
| La cantidad es correcta pero está asignada a la ubicación equivocada | Block, porque disponibilidad operativa y propiedad del procesamiento son incorrectas. |
| El total principal coincide pero no las cantidades por variación | Block, porque no se puede confiar en las unidades vendibles. |
| La clave externa de stock existe pero la autoridad de inventario ya no la reconoce | Block hasta corregir la clave o la asignación de integración. |
| Un servicio sin stock no se controla intencionadamente | Pass cuando está documentado el funcionamiento de disponibilidad previsto. |
La validación de inventario no debe provocar cambios duplicados de stock a partir de Orders históricos. El Order importado es evidencia de comercio pasado; el inventario inicial aprobado es el estado operativo actual.
Valida Square Online, Categories, búsqueda y rutas
La validación del catálogo de Square y la de Square Online están relacionadas, pero son independientes. Un artículo puede existir en la biblioteca y seguir sin publicarse, ser difícil de encontrar, estar asociado a una Category equivocada o desconectado de la ruta online prevista. Por eso, cuando formen parte del alcance de destino, las páginas, navegación, dominios, URL, redirecciones, recogida, entrega, presentación de envío y publicación del sitio necesitan su propia evidencia.
Utiliza un registro de rutas prioritarias que cubra Products que generan ingresos, Categories importantes, destinos de campañas, páginas de políticas, contenido y URL enlazadas externamente. Para cada ruta, registra el destino esperado de Square Online y clasifica el resultado como resolución directa, una única redirección relevante, retirada aprobada o fallo pendiente.
La evidencia para Pass incluye:
- Items y Categories prioritarios visibles en el contexto online previsto;
- pertenencia a Categories y navegación que conducen al conjunto esperado de Products;
- búsqueda o navegación que muestran artículos representativos con etiquetas y opciones previstas;
- imágenes, descripciones, precios, disponibilidad y presentación de procesamiento coherentes;
- dominios y estado de publicación que llevan a los compradores al sitio previsto;
- URL antiguas prioritarias que resuelven a un destino relevante sin bucles ni redirecciones no relacionadas.
La ausencia de un enlace de menú no es automáticamente un defecto de migración y una Category migrada no recrea automáticamente la navegación del sitio. El registro de lanzamiento debe distinguir las correcciones de datos migrados del trabajo de configuración y diseño de Square Online.
Valida Customers y Orders históricos
Los perfiles de Customer de Square pueden contener contacto, relaciones con grupos, IDs de referencia, atributos personalizados y vínculos con Orders. La validación debe demostrar continuidad de identidad sin crear fusiones falsas ni duplicados innecesarios. Correo y teléfono son evidencia útil, pero compras como invitado, datos compartidos, direcciones cambiadas e IDs externos de CRM pueden requerir contexto adicional.
La evidencia de Customer debe cubrir:
- compradores registrados e invitados;
- identidades duplicadas o casi duplicadas;
- direcciones e información de empresa;
- contexto de grupo, segmento, consentimiento, fidelización o atributos personalizados cuando esté incluido;
- IDs externos de Customer usados por CRM, contabilidad, fidelización o soporte;
- vínculos entre Customers y Orders históricos representativos.
La evidencia de Orders históricos debe incluir líneas, referencias o instantáneas de variaciones, modificadores, cantidades, precios, descuentos, cargos por servicio, propinas, impuestos, vínculos con Customers, direcciones, origen, ubicación, procesamiento, reembolsos e IDs externos cuando estén incluidos. El equipo debe poder responder quién compró qué, en qué ubicación, bajo qué Order y con qué contexto financiero y de procesamiento.
| Resultado de evidencia | Estado |
|---|---|
| Los totales del Order concilian y el significado de las líneas está claro, mientras la configuración actual de la pasarela permanece separada | Pass |
| La etiqueta de pago es legible, pero una referencia externa de transacción requiere confirmación de responsable | Watch |
| Los Orders existen pero las líneas apuntan a variaciones o Customers incorrectos | Block |
| Existe historial de procesamiento, pero la configuración activa de recogida o entrega está incompleta | Watch o Block según su dependencia para el lanzamiento; corresponde a implementación del destino, no a corrección de migración |
| Falta o resulta engañoso un historial de reembolso o ajuste que cambia de forma relevante el resultado financiero | Block |
Los Orders históricos no demuestran que proceso de compra, pagos, impuestos, procesamiento, notificaciones o inventario actuales estén preparados. Estos flujos activos requieren evidencia independiente en el destino.
Valida contenido, atributos personalizados, aplicaciones y sistemas externos
Las migraciones hacia Square pueden incluir atributos personalizados, IDs de referencia, campos propiedad de aplicaciones, referencias de fidelización o tarjetas regalo, claves contables, registros de entrega, identificadores de mercado en lÃnea u otros datos externos. Cada valor incluido necesita una entidad principal definida y un consumidor que seguirá activo.
Utiliza un registro trazable para cada requisito no estándar:
| Campo necesario | Evidencia |
|---|---|
| Responsable y ejemplo de ID en el origen | Identifica el registro y sistema exactos del origen. |
| Destino en Square | Nombra el Item, variación, Customer, Order, línea, registro del sitio u objeto de aplicación responsable del valor. |
| Transformación | Explica cualquier normalización, combinación o reestructuración. |
| Consumidor que continuará | Identifica el flujo de trabajo, API, aplicación, ERP, CRM, almacén o informe que utiliza el resultado. |
| Condición de Pass | Define el resultado que demuestra que el valor sigue siendo utilizable. |
Los resultados aprobados de migración deben comprobarse frente a la solicitud contratada de filtrado, asignación o configuración. Los resultados no estándar deben comprobarse frente a la especificación personalizada acordada. La validación no debe ampliar el alcance aceptado para incluir implementación no relacionada de Square, instalación de aplicaciones, diseño o despliegue de integraciones salvo que esos entregables se hayan incluido expresamente.
Cuando una integración continúa activa, verifica identificadores y relaciones mediante el flujo conectado. La presencia de una clave ERP en Square no basta si el ERP ya no encuentra la variación; una referencia de Order no basta si contabilidad no puede conciliarla; un ID de fidelización no basta si la cuenta de fidelización queda desconectada del Customer.
Vuelve a validar después de acciones de migración posteriores
Un resultado previamente aprobado no cubre automáticamente actividad posterior del origen ni cambios de configuración. La nueva validación debe seguir exactamente la acción utilizada:
| Acción de migración | Enfoque de nueva validación |
|---|---|
| continuar con la configuración aceptada | Demuestra que los nuevos registros elegibles siguen filtros, asignaciones, modelo Item/variación, propiedad por ubicación y claves de integración previamente aprobados. |
| continuar con configuración revisada | Vuelve a validar cada área afectada por cambios en filtros, asignaciones, selección de tipos de datos o configuración compatible, incluidas suposiciones anteriores que ya no se aplican. |
| producir un resultado de migración nuevo e independiente | Trata el nuevo resultado como un conjunto de evidencia distinto; repite comprobaciones de catálogo, inventario, Customer, Order, contenido, integraciones y decisión de lanzamiento. |
Para cada acción, compara los registros afectados con el resultado previamente aprobado y confirma que los registros sin cambios permanecen estables. Registra Items, variaciones, conjuntos de opciones, modificadores, asignaciones de ubicación, Customers, Orders, rutas, atributos personalizados y referencias de aplicaciones externas que cambiaron; después repite los escenarios de comprador, equipo e integración que dependen de ellos. El muestreo focalizado es aceptable solo cuando la última configuración utilizada y las relaciones de objetos de Square no han cambiado. Una configuración nueva o un resultado independiente requiere una base de evidencia más amplia. Los nuevos Products, Customers, Orders y Blog Posts migrados deben conciliarse junto con sus relaciones, no únicamente como recuentos adicionales.
Aplica decisiones de lanzamiento Pass, Watch y Block
La decisión final debe basarse en evidencia y tener responsables claros. Cada hallazgo relevante debe identificar el registro o flujo afectado, la persona responsable, la corrección necesaria y la condición para volver a comprobarlo.
| Decisión | Interpretación en Square |
|---|---|
| Pass | El resultado migrado es correcto y utilizable para su finalidad prevista en Square. |
| Watch | Queda una corrección no bloqueante, configuración o decisión de responsable con fecha y nueva comprobación registradas. |
| Block | El problema afectaría materialmente venta, identidad de variaciones, inventario, continuidad de Customers, Orders históricos, contexto financiero, rutas prioritarias, procesamiento, cumplimiento o resultado personalizado acordado. |
Square solo está preparado para lanzamiento cuando todos los Block están cerrados, los Watch tienen responsables, fechas y nuevas comprobaciones definidas y la evidencia cubre tanto los registros migrados como el funcionamiento requerido del destino. El registro de decisión debe nombrar el Item, variación, conjunto de opciones, modificador, ubicación, Customer, Order, ruta y flujo externo probados. También debe diferenciar la evidencia histórica de Orders de la publicación actual del catálogo, inventario por ubicación, pagos, impuestos, procesamiento, presentación de Square Online y configuración de aplicaciones. Un recuento de catálogo, inicio de sesión correcto o captura limpia de la tienda no sustituye este registro de decisión.
Conclusión
La validación de Square debe demostrar un funcionamiento comercial conectado entre Items, variaciones, modificadores, inventario por ubicación, Customers, Orders históricos, Square Online y sistemas externos. Las pruebas representativas deben exponer relaciones difíciles; una ejecución más amplia debe conciliar todo el alcance aprobado y sus excepciones.
La decisión de lanzamiento es creíble cuando se separan datos migrados y configuración del destino, los resultados compatibles y adaptados se prueban contra los requisitos acordados, las acciones posteriores reciben una validación proporcional y cada hallazgo termina en Pass, Watch o Block con un responsable claro.
Preguntas frecuentes
¿Qué debe validarse primero después de una prueba representativa en Square?
Empieza por los registros que exponen el modelo de relaciones de Square: un Item con varias variaciones, un artículo basado en modificadores, inventario específico de ubicación, un Customer con Orders vinculados, un Order con ajustes financieros o de procesamiento, una ruta prioritaria de Square Online y un identificador externo utilizado por un sistema que seguirá activo.
¿Basta con que coincidan los recuentos de Items y Orders para aprobar una migración hacia Square?
No. Los recuentos pueden descubrir registros ausentes, pero no demuestran una estructura Item-variación correcta, inventario por ubicación, vínculos de Customer, significado de líneas de Order, visibilidad en Square Online ni continuidad de integraciones.
¿Cómo debe validarse el inventario de Square?
Valida cantidad y estado a nivel de Item Variation y ubicación. Confirma que el equipo y cualquier ERP, almacén, canal o sistema de informes que continúe activo reconocen la misma variación.
¿Los Orders migrados demuestran que pagos y procesamiento están preparados en Square?
No. Los Orders históricos conservan evidencia de transacciones. El funcionamiento actual de pagos, impuestos, recogida, entrega, envío, notificaciones y procesamiento requiere configuración y evidencia independientes en el destino.
¿Cómo deben aprobarse los resultados de Agreed Adjustment o Tailored Migration?
Comprueba los ajustes aprobados de migración frente al resultado contratado y acotado de filtrado, asignación o configuración, y el tratamiento no estándar frente a la especificación personalizada acordada. Ninguno debe aprobarse contra una expectativa indefinida de implementación completa de Square.
¿Qué debe volver a validarse después de una acción de migración posterior en Square?
Vuelve a validar los registros y relaciones afectados por la acción seleccionada. Una configuración nueva exige comprobaciones focalizadas de cada asignación o filtro modificado; una migración nueva requiere un conjunto nuevo de evidencia de principio a fin.