Los riesgos de una migración hacia Square se concentran en los límites entre sistemas. Square conecta una biblioteca de artículos tipados con Point of Sale, inventario por ubicación, Customers, Orders, pagos, procesamiento de pedidos y Square Online. Por eso, un registro puede estar presente y aun así crear riesgo operativo si queda asociado al objeto de catálogo, ubicación, identidad de Customer, contexto de transacción o aplicación equivocados.
El supuesto más peligroso es tratar Square como una base de datos genérica de tienda online. No lo es. Los artículos, variaciones, opciones, modificadores, Categories, impuestos, descuentos y atributos personalizados cumplen funciones diferentes. El inventario pertenece a relaciones entre variación y ubicación. Los Orders históricos conservan evidencia de transacciones, pero no configuran el funcionamiento actual de pagos, impuestos o procesamiento. Square Online añade responsabilidades de sitio y de rutas que son independientes del traslado del catálogo.
Para evaluar Square como plataforma de destino, conviene seguir una cadena completa de riesgo: el supuesto de la tienda de origen, la restricción de Square, la consecuencia para la migración, el impacto operativo, la dirección de mitigación y la señal que demuestra que el riesgo está controlado.
El riesgo en Square empieza por la propiedad de objetos y sistemas
Los dominios de catálogo, inventario, Customers, Orders y sitio online de Square están conectados, pero no comparten un registro universal. El riesgo aumenta cuando un campo de la tienda de origen se traslada al destino visible más cercano en lugar de al objeto de Square responsable del mismo significado empresarial.
| Supuesto de origen | Restricción de Square | Consecuencia para la migración | Impacto operativo | Orientación de mitigación | Señal de control |
|---|---|---|---|---|---|
| Una fila de Product contiene toda la unidad vendible. | Square separa los artículos de las variaciones y de otros objetos del Catalog. | SKU, precio, stock, imagen o unidad de medida pueden terminar en el nivel equivocado. | El equipo vende o informa sobre la variación incorrecta y las integraciones no pueden identificar el stock previsto. | Define el artículo principal y cada variación gestionada de forma independiente antes de relacionar campos. | Cada identificador vendible de origen resuelve a una variación concreta de Square. |
| Cada elección del comprador es una variante. | Square distingue opciones, variaciones y modificadores seleccionados durante la venta. | Los extras opcionales se convierten en falsas unidades de inventario o las variantes reales pierden su identidad de stock. | La selección en Point of Sale se vuelve confusa y los recuentos dejan de ser fiables. | Clasifica cada elección según cree o no un artículo con precio, stock o identificación independientes. | Las estructuras de variantes y modificadores coinciden con la forma real de vender y procesar el artículo. |
| Una sola cantidad de stock es suficiente. | El inventario de Square depende de la variación y de la ubicación y registra cambios de estado. | Una cantidad agregada puede asignarse a la ubicación o variación equivocada. | Aparecen sobreventa, faltantes y diferencias de conciliación entre ubicaciones. | Declara quién controla el inventario y asigna las cantidades al nivel variación-ubicación. | Los totales por ubicación concilian con el modelo operativo declarado. |
| Los Orders históricos recrean las operaciones actuales. | Los Orders conservan contexto transaccional; pagos, impuestos y procesamiento actuales se configuran por separado. | El historial importado se confunde con una configuración activa de proceso de compra o procesamiento. | El negocio puede consultar ventas anteriores, pero no procesar nuevas de forma fiable. | Mantén la evidencia histórica y la configuración operativa activa como controles separados. | El equipo puede interpretar Orders históricos sin tratarlos como prueba de preparación actual. |
| Square Online se recrea al trasladar el catálogo. | El sitio online tiene sus propias relaciones de páginas, navegación, dominio, rutas y presentación. | Los artículos existen, pero recorridos clave, contenido o continuidad de URL quedan incompletos. | Se pierde tráfico y capacidad de descubrimiento aunque el recuento del catálogo sea correcto. | Asigna un destino online a cada ruta y objeto de contenido de alto valor del origen. | Las rutas prioritarias llegan al destino previsto de Square Online. |
Este mapa de propiedad es la base de las cadenas de riesgo detalladas a continuación. Sin él, las comprobaciones posteriores pueden demostrar que los registros existen sin demostrar que Square pueda utilizarlos correctamente.
Confundir artículos, variaciones, opciones y modificadores
El principal riesgo del catálogo es comprimir significados diferentes. Una plataforma de origen puede usar una misma tabla de opciones para talla, color, envoltorio de regalo, preferencia de preparación, grabado, selección de paquete y especificaciones técnicas. Square no trata todos esos valores de la misma manera.
Una variación representa una versión comprable de un artículo. Una opción puede estandarizar los valores que definen las variaciones. Un modificador representa un cambio o añadido elegido durante la venta. Un atributo personalizado puede guardar información estructurada sin convertirse en una elección del comprador. Si se confunden estas funciones, el catálogo visible puede parecer correcto mientras la venta y los informes funcionan mal.
| Cadena de riesgo | Causa y consecuencia | Impacto operativo | Dirección de mitigación | Señal de control |
|---|---|---|---|---|
| Los SKU hijos del origen se aplanan en un solo artículo. | El artículo principal recibe elecciones descriptivas, pero desaparecen SKU, precio, inventario, imagen o unidad de medida a nivel de variación. | El personal de POS no identifica el artículo correcto; inventario y sistemas externos quedan ambiguos. | Conserva cada hijo gestionado de forma independiente como la variación prevista. | Los artículos representativos con muchas variantes conservan identificadores y valores comerciales únicos. |
| Los extras opcionales se convierten en variaciones. | Envoltorios, preferencias de preparación o servicios opcionales generan combinaciones que no son unidades reales de stock. | El catálogo crece innecesariamente, el stock se fragmenta y el equipo afronta elecciones innecesarias. | Representa añadidos de venta mediante modificadores cuando no definen identidad de inventario. | Los extras aparecen en la línea de Order sin crear falsos registros de stock. |
| Las variantes reales se convierten en modificadores. | Talla o color siguen visibles, pero dejan de controlar SKU, stock, precio o imagen. | El comprador puede elegir una etiqueta, pero el negocio no puede gestionar el artículo seleccionado como unidad vendible distinta. | Utiliza variaciones para combinaciones con identidad comercial propia. | La línea seleccionada del Order apunta a la variación y registro de inventario correctos. |
| Las especificaciones de Product se convierten en elecciones del comprador. | Los datos descriptivos se introducen como opciones o modificadores. | El equipo mantiene combinaciones irrelevantes y los Customers ven entradas confusas. | Mantén los datos no seleccionables en descripciones o atributos personalizados adecuados. | Las especificaciones siguen siendo informativas sin modificar la variación comprada. |
| Los paquetes se tratan como un artículo ordinario. | Se pierde la identidad de componentes y quién controla su stock. | Puede conservarse el precio mostrado mientras disponibilidad y procesamiento de componentes dejan de ser explicables. | Define si el paquete es una oferta de catálogo, relación de descuento, estructura propiedad de una aplicación o ensamblaje externo. | El sistema responsable del stock de componentes puede seguir identificando cada artículo incluido. |
Los responsables afectados son administradores de catálogo, personal de comercio minorista, equipos de inventario y sistemas conectados. La mitigación no consiste en reproducir cada tabla del origen, sino en conservar la unidad comercial mínima que Square, el equipo y los sistemas externos reconocen de forma coherente.
Interpretar mal las ubicaciones y los estados de inventario
El inventario de Square se construye mediante recuentos físicos y cambios de estado. También puede verse afectado por Orders completados y aplicaciones externas. Migrar inventario implica mucho más que copiar una columna de cantidad.
La primera restricción es la granularidad: la cantidad pertenece a una variación en una ubicación. La segunda es la autoridad: Square puede controlar el inventario o recibir actualizaciones de un almacén, ERP, hub de mercado en lÃnea u otro sistema de confianza. La tercera es el momento: el recuento inicial no debe reproducir ventas o ajustes históricos como nuevos eventos.
| Supuesto | Restricción de Square | Consecuencia para la migración | Impacto operativo | Orientación de mitigación | Señal de control |
|---|---|---|---|---|---|
| Los almacenes de origen se pueden sumar sin riesgo. | Las ubicaciones de Square conservan la propiedad operativa del stock. | Un total agregado elimina qué sucursal, almacén o punto de procesamiento posee las unidades. | Recogida, venta y reposición utilizan una disponibilidad incorrecta. | Relaciona las bolsas de stock de origen con las ubicaciones previstas de Square antes de asignar cantidades. | Los totales por ubicación concilian con el modelo operativo declarado. |
| El stock a nivel de Product puede copiarse al artículo principal. | Square controla el inventario de las variaciones. | La cantidad queda separada del SKU vendible. | Un Product parece disponible mientras la variación elegida está agotada o no controlada. | Asocia el stock con la variación utilizada por POS, Orders e integraciones. | Cada identificador vendible controlado tiene una relación clara de inventario. |
| Deben reproducirse los eventos históricos de inventario. | Square calcula inventario mediante transiciones de estado ordenadas y recuentos físicos. | El historial importado puede descontar dos veces o distorsionar el estado inicial. | Los recuentos dejan de cuadrar inmediatamente y el equipo pierde confianza. | Establece el estado inicial previsto y conserva eventos antiguos solo en su responsable histórico. | El recuento inicial puede explicarse sin reproducir operaciones comerciales anteriores. |
| Un recuento inicial resuelve la sincronización futura. | Los sistemas externos responsables del inventario seguirán publicando cambios después de la migración. | Square comienza correctamente pero deriva cuando las actualizaciones usan IDs ausentes o incorrectos. | Las diferencias de stock reaparecen entre canales y ubicaciones. | Conserva identificadores de variación, ubicación y sistema externo usados por la integración que continuará activa. | Una actualización desde el sistema autorizado llega a la variación y ubicación previstas. |
| Cero, no disponible y sin control de stock significan lo mismo. | La disponibilidad de Square depende de ajustes de catálogo e inventario, no solo de un número. | Servicios, artículos ilimitados, agotados e inactivos se interpretan igual. | Artículos válidos dejan de venderse o artículos no disponibles siguen expuestos. | Clasifica por separado casos con stock, sin stock, servicios y no disponibles. | Cada clase muestra el funcionamiento de venta previsto sin una cantidad engañosa. |
El riesgo de inventario afecta directamente a los ingresos. El control estructural exige que Square, el equipo de la tienda y todos los sistemas que sigan gestionando stock entiendan la misma identidad variación-ubicación.
Límites entre Orders históricos, pagos, reembolsos y procesamiento
Los Orders de Square pueden incluir líneas, referencias a variaciones, modificadores, impuestos, descuentos, cargos por servicio, propinas, relaciones con Customers, origen, ubicación, procesamiento, pagos y reembolsos. Una migración histórica puede conservar gran parte de ese contexto, pero no puede convertir una pasarela antigua, un flujo de envío o un modelo de estados del origen en configuración actual de Square.
| Cadena de riesgo | Consecuencia para la migración | Impacto operativo | Dirección de mitigación | Señal de control |
|---|---|---|---|---|
| Las etiquetas de estado del origen se copian sin interpretación. | Una etiqueta puede combinar pago, procesamiento, cancelación o devolución que Square registra por separado. | El equipo interpreta mal si un Order fue pagado, procesado, reembolsado o sigue requiriendo acción. | Traslada el significado histórico a un contexto legible de Order, pago, reembolso y procesamiento. | Los Orders complejos representativos pueden entenderse sin consultar el sistema de origen. |
| Las líneas del Order se vinculan solo al artículo principal. | Se pierde la variación comprada o el modificador seleccionado. | Soporte y conciliación no pueden identificar qué compró realmente el Customer. | Conserva instantáneas de línea y referencias fiables a variación o modificador cuando existan. | La línea muestra la identidad comprada y las elecciones realizadas durante la venta. |
| Las referencias históricas de pago se tratan como datos reutilizables. | La evidencia de transacción se confunde con un método o credencial de pago activo. | El equipo asume que puede procesar reembolsos o nuevos cargos mediante datos que solo documentan el pasado. | Conserva referencias de conciliación no sensibles y mantén separada la configuración de pago activa. | El equipo puede rastrear la transacción sin exponer ni utilizar incorrectamente credenciales. |
| El historial de procesamiento se trata como configuración actual de entrega. | Etiquetas antiguas de transportista, recogida, envío o entrega se copian sin su propietario operativo actual. | Los nuevos Orders siguen rutas de procesamiento incompletas o incorrectas. | Conserva la evidencia histórica y define de forma independiente los métodos actuales. | Los registros históricos y actuales de procesamiento son claramente distinguibles. |
| Los Orders importados provocan efectos de stock no deseados. | La actividad histórica se confunde con nuevas operaciones que cambian inventario. | El stock se reduce una segunda vez o las cantidades iniciales dejan de cuadrar. | Separa las responsabilidades del historial de Orders y del inventario inicial. | El historial sigue siendo legible mientras la posición inicial de stock permanece estable. |
Los responsables afectados son atención al Customer, finanzas, operaciones e inventario. La mitigación consiste en conservar evidencia transaccional sin otorgar autoridad operativa actual a registros históricos.
Identidad de Customer, grupos, fidelización y perfiles propiedad de aplicaciones
Los perfiles de Customer de Square pueden contener identidad, datos de contacto, direcciones, grupos, segmentos, preferencias, IDs de referencia y atributos personalizados. Otros productos de Square y aplicaciones conectadas pueden controlar relaciones de fidelización, citas, restauración, suscripciones, entrega o CRM. Por eso una tabla de “Customer” del origen puede mezclar varias identidades que no pertenecen a un único perfil de Square.
| Supuesto | Restricción de la plataforma | Consecuencia para la migración | Orientación de mitigación | Señal de control |
|---|---|---|---|---|
| El correo electrónico por sí solo demuestra identidad. | Ventas como invitado, direcciones compartidas, correos cambiados, cuentas duplicadas e IDs externos pueden representar personas o historiales distintos. | Customers no relacionados se fusionan o una misma persona termina en varios perfiles desconectados. | Usa una jerarquía de identidad documentada que incluya ID de origen, correo, teléfono, vínculos con Orders y claves externas. | Customers de alto valor y propensos a duplicidad resuelven al perfil previsto. |
| Cada registro de comprador debe convertirse en Customer permanente. | El contexto de una transacción como invitado puede existir sin una relación de cuenta duradera. | Perfiles artificiales inflan la lista y distorsionan consentimiento o segmentación. | Conserva la identidad de invitado en el Order salvo que exista una relación permanente justificada. | El historial de invitados sigue siendo útil sin inventar significado de cuenta. |
| Los grupos de origen recrean fidelización o segmentación de Square. | Grupos de Customer, segmentos, programas de fidelización y membresías de aplicaciones tienen responsables diferentes. | Las etiquetas sobreviven mientras desaparecen elegibilidad, saldo o funcionamiento del programa. | Separa la agrupación descriptiva del sistema que controla beneficios y actividad. | El sistema de fidelización o segmentación que continúa activo reconoce la misma clave de Customer. |
| El estado de marketing es un dato de contacto ordinario. | El consentimiento y las preferencias de comunicación tienen propósito y procedencia. | Los contactos importados pueden tratarse como aptos para marketing sin una relación válida. | Conserva solo datos de preferencias compatibles cuyo significado y propiedad estén claros. | Los sistemas de marketing distinguen identidad de contacto de estado de consentimiento. |
| Los campos personalizados son notas inocuas del perfil. | Los sistemas externos o aplicaciones pueden depender de atributos estructurados e IDs de referencia del Customer. | Soporte, informes o sincronización pierden el vínculo con la cuenta autorizada. | Relaciona identificadores duraderos con campos estructurados o con la aplicación que seguirá siendo responsable. | Un CRM o aplicación conectada resuelve correctamente el Customer de Square. |
El control no consiste en importar el máximo número posible de Customers. Consiste en un modelo de identidad que impida fusiones erróneas, cuentas no justificadas y relaciones de aplicación huérfanas.
Square Online, contenido, navegación y continuidad de URL
Square Online utiliza datos comerciales, pero añade responsabilidades propias de sitio. Products y Categories pueden existir en la biblioteca de artículos mientras la tienda online sigue sin las páginas, rutas de menú, comportamiento de dominio, contenido o continuidad de URL previstos.
La cadena de riesgo suele comenzar con la suposición de que migrar el catálogo recrea la tienda online. La restricción de Square es que la propiedad del catálogo y la del sitio están relacionadas, pero son distintas. La consecuencia es una biblioteca de artículos poblada sin un recorrido completo del comprador. El impacto operativo es pérdida de capacidad de descubrimiento, tráfico y conversión.
| Recurso de origen | Restricción y riesgo | Dirección de mitigación | Señal de control |
|---|---|---|---|
| Ruta de Product o Category | Square Online puede generar otra ruta y otro contexto de presentación. | Asigna un destino canónico y una relación de redirección para las rutas prioritarias. | Las URL antiguas de alto valor resuelven al destino activo previsto. |
| CMS Page o contenido de políticas | El contenido puede necesitar una página de Square Online u otro responsable definido. | Separa el contenido de la página de la navegación y su ubicación en el tema. | El contenido tiene un único destino autorizado y una ruta accesible. |
| Blog o archivo editorial | El soporte de publicación y la estructura pueden diferir del origen. | Define si el contenido permanece en Square Online, otro CMS o un archivo deliberado. | Los enlaces editoriales no terminan en páginas inexistentes o no relacionadas. |
| Jerarquía de menú | Las Categories de artículos no reproducen necesariamente la navegación del sitio. | Reconstruye la navegación como relación del sitio apuntando a los destinos correctos de catálogo o contenido. | Los recorridos prioritarios no dependen de menús huérfanos ni de suposiciones sobre Categories. |
| Scripts y widgets incrustados | Fragmentos del sitio, aplicaciones y código específico del origen tienen propietarios distintos. | Recrea únicamente el funcionamiento necesario mediante la capa compatible del sitio o de integración. | El resultado empresarial existe sin copiar código obsoleto del origen. |
| Medios y enlaces internos | Los archivos pueden moverse mientras las rutas incrustadas siguen apuntando al dominio antiguo. | Reescribe referencias de contenido y conserva quién controla cada recurso. | Imágenes y enlaces internos resuelven desde las páginas previstas. |
El riesgo estructural está controlado cuando la propiedad del contenido, la intención de las rutas y el destino que seguirá activo están explícitos. La verificación por página puede comprobar después esas relaciones declaradas sin redefinirlas.
Aplicaciones conectadas, atributos personalizados y riesgo de sistemas externos
Square puede conectarse con aplicaciones de contabilidad, inventario, fidelización, citas, restauración, entrega, CRM, suscripciones, analítica y otros ámbitos. La presencia de un campo en el origen no demuestra que el núcleo de Square sea responsable del registro equivalente.
| Supuesto sobre la dependencia | Restricción de Square | Consecuencia para la migración | Impacto operativo | Orientación de mitigación | Señal de control |
|---|---|---|---|---|---|
| Aplicaciones similares utilizan el mismo modelo de datos. | Cada aplicación puede poseer entidades, estados e identificadores distintos. | Los datos se colocan en campos genéricos sin el flujo que los consume. | El equipo ve valores que ningún sistema mantiene o entiende. | Identifica la entidad real de la aplicación y quién seguirá siendo responsable antes del traslado. | La aplicación de destino puede resolver su artículo, Customer u Order principal. |
| Los IDs externos pueden regenerarse. | ERP, CRM, almacén, mercado en lÃnea y sistemas contables pueden considerar la clave existente como referencia. | Conciliación y sincronización apuntan a registros nuevos o duplicados. | Las actualizaciones de stock, Customer u Order fallan o se asocian al objeto equivocado. | Conserva identificadores estables en la misma granularidad de objeto Square utilizada por el sistema externo. | Una consulta de ida y vuelta devuelve el registro de Square previsto. |
| Los atributos personalizados conservan el funcionamiento personalizado. | Un atributo guarda datos, pero no reproduce scripts o flujos del origen. | El valor llega mientras desaparece la lógica de precios, visibilidad, aprobación o automatización. | Automatizaciones o reglas comerciales dejan de funcionar aunque el campo exista. | Separa los datos descriptivos del funcionamiento que los consume. | El responsable en el destino tanto del valor como del funcionamiento está documentado. |
| El historial de aplicaciones pertenece al núcleo de Square. | Reservas, fidelización, suscripciones, restauración y entregas pueden vivir en dominios separados. | El historial especializado se aplana como notas de Customer u Order. | Soporte no puede interpretar derecho, calendario, saldo o estado de participación. | Conserva los registros especializados únicamente en un dominio compatible o archivo intencional. | El equipo puede acceder al historial mediante su responsable real. |
| La conectividad API garantiza equivalencia de migración. | El acceso API expone recursos definidos; no crea semántica empresarial que no exista. | El equipo sobreestima lo que pueden representar los objetos estándar de Catalog, Customer u Order. | Las brechas de alcance aparecen después de reconstruir integraciones. | Evalúa propiedad de recursos y compatibilidad de relaciones, no solo presencia de API. | Cada integración que continúa tiene un mapa explícito entre entidad de origen y de destino. |
Los responsables afectados incluyen ingeniería de integración, operaciones, finanzas, marketing y administradores de aplicaciones. La mitigación exige un registro de propiedad, no un inventario genérico de campos personalizados.
Propiedad de riesgos entre dominios
Los riesgos de Square se multiplican cuando varios dominios comparten una misma suposición débil. Aplanar una variación puede afectar simultáneamente inventario, Orders, POS, Square Online y un ERP. Fusionar un Customer puede afectar soporte, fidelización, marketing y reembolsos. Romper una URL puede dañar el tráfico de búsqueda aunque el catálogo siga correcto.
| Riesgo entre dominios | Responsable principal | Responsables de apoyo | Dirección de mitigación | Señal de control |
|---|---|---|---|---|
| Identidad del catálogo | Administrador de catálogo | comercio minorista, inventario, integraciones | Define artículos principales, variaciones vendibles, modificadores e IDs duraderos. | Todos los sistemas dependientes hacen referencia a la misma unidad vendible. |
| Autoridad del inventario | Responsable de inventario u operaciones | Responsables de ubicaciones, integraciones | Define propiedad variación-ubicación y responsabilidad del estado inicial. | Los recuentos concilian sin aplicar dos veces eventos históricos. |
| Historial de transacciones | Responsable de atención al Customer o finanzas | Operaciones, pagos, procesamiento | Conserva instantáneas legibles y evidencia financiera/de procesamiento relacionada. | Los Orders históricos complejos pueden explicarse de principio a fin. |
| Identidad de Customer | Responsable de operaciones de Customer | Marketing, fidelización, CRM | Define coincidencia, tratamiento de invitados, consentimiento y claves externas. | No quedan fusiones falsas relevantes ni perfiles huérfanos. |
| Continuidad online | Responsable del sitio | SEO, contenido, catálogo | Asigna rutas, navegación, contenido y redirecciones por separado de la migración de artículos. | Las rutas prioritarias de tráfico llegan a destinos utilizables. |
| Continuidad de aplicaciones | Responsable de aplicación | Responsables de integración y datos | Relaciona registros especializados e identificadores con el sistema que continuará. | El flujo de destino reconoce los mismos objetos empresariales principales. |
Un riesgo está controlado cuando la persona responsable puede explicar la restricción de Square, la mitigación prevista y la evidencia de que la relación es coherente. Así se crea una condición gobernable en lugar de una advertencia sin respuesta responsable.
Conclusión
Las restricciones de una migración hacia Square surgen de cómo los objetos del Catalog, ubicaciones, estados de inventario, Customers, Orders, Square Online y aplicaciones dividen la propiedad. Los supuestos de mayor riesgo son considerar que todas las elecciones del comprador son variantes, que el stock es una sola cifra del Product, que los Orders históricos configuran las operaciones actuales, que los Customers pueden identificarse solo por correo electrónico y que trasladar el catálogo recrea la tienda online.
Una migración controlada conserva la identidad vendible mínima, asigna el inventario a la variación y ubicación correctas, mantiene las transacciones históricas separadas de la configuración actual, protege las claves de Customer y sistemas externos y asigna cada registro online o de aplicación a un responsable que continuará activo. Estos controles atacan la consecuencia operativa desde su origen en lugar de confiar únicamente en recuentos de registros.
Preguntas frecuentes
¿Cuál es el riesgo más importante del catálogo de Square?
El mayor riesgo es confundir artículos, variaciones, opciones y modificadores. Una estructura incorrecta puede parecer aceptable en el Dashboard y aun así debilitar la identidad de SKU, el inventario, la selección en Point of Sale, el significado de las líneas de Order y las coincidencias con sistemas externos.
¿Por qué el riesgo de inventario de Square depende de la ubicación?
El inventario de Square está vinculado a una variación y una ubicación y se ve afectado por recuentos y cambios de estado. Una cantidad agregada puede conservar el total y, al mismo tiempo, asignar unidades a la sucursal, almacén o punto de procesamiento equivocados.
¿Pueden los Orders históricos demostrar que Square está preparado para nuevas ventas?
No. Los Orders históricos conservan evidencia de transacciones. El funcionamiento actual de pagos, impuestos, descuentos, procesamiento, notificaciones e inventario pertenece a la configuración activa de Square y a sus sistemas conectados.
¿Por qué el número de Customers puede ser correcto y la migración de Customers seguir siendo arriesgada?
Los recuentos no muestran fusiones erróneas, identidades duplicadas, tratamiento de invitados, significado del consentimiento, propiedad de fidelización ni IDs de CRM rotos. El riesgo solo queda controlado cuando las relaciones previstas entre Customers y aplicaciones siguen siendo coherentes.
¿Trasladar el catálogo de Square recrea Square Online?
No. Square Online también necesita páginas del sitio, navegación, rutas, dominios, presentación, referencias de medios y relaciones de redirección. La presencia del catálogo es una dependencia del sitio, no el modelo completo del sitio.
¿Cómo deben tratarse los datos de Square propiedad de aplicaciones?
Identifica la entidad de la aplicación, su artículo, Customer u Order principal y el identificador estable utilizado por el flujo que seguirá activo. El historial especializado debe permanecer en un dominio de aplicación compatible o en un archivo deliberado, no aplanarse como notas genéricas.