Aceptar una migración a Odoo: concilia registros y saldos

14 minutos de lectura · 5 nov 2026
Última revisión 5 de noviembre de 2026

Cinco pedidos de origen se convierten en cinco pedidos de destino. Los totales por empresa coinciden. En nuestro modelo local, dos pedidos siguen teniendo un importe incorrecto. Una migración puede superar sus controles generales y dejar datos erróneos para las personas que deben utilizarlos.

Acepta una migración a Odoo comparando una instantánea de origen acordada con los registros de destino esperados y ejecutando después los procesos que dependen de ellos. Comprueba identidades y relaciones junto con importes y estados. Asigna un responsable y una nueva prueba a cada diferencia, y obtén las aprobaciones de negocio correspondientes antes de dar la migración por terminada.

Investigación revisada: 5 de noviembre de 2026. Los datos del producto proceden de fuentes oficiales de Odoo. Ejecutamos nueve casos sintéticos de conciliación JSON con la biblioteca estándar de Python. No migramos una base de Odoo ni inspeccionamos datos de clientes o validamos informes contables. La plantilla CSV incluye controles propuestos con estado NOT_RUN.

¿Qué debe demostrar una migración a Odoo para ser aceptada?

Debe producir los registros de negocio y el funcionamiento acordados para su alcance. Que una base arranque o que una importación termine correctamente solo demuestra una parte. Define quién debe completar cada proceso, qué registros deben resultar y qué información histórica tiene que seguir disponible.

Primero identifica el tipo de traslado. Actualizar una versión de Odoo no equivale a importar el historial de otro ERP. La importación puede exigir nuevas correspondencias y exclusiones deliberadas; una actualización puede cambiar el comportamiento de la aplicación o la compatibilidad de módulos propios. El acta de aceptación debe describir la ruta concreta.

La guía de actualización de Odoo recomienda probar los procesos de negocio y las integraciones externas en la base actualizada antes de pasar producción. Convierte esa indicación en pruebas de tu operación: un pedido parcialmente entregado necesita un control diferente al de un contacto recién creado.

Separa la ejecución técnica de la aprobación de negocio. Ingeniería puede demostrar que un comparador no encontró diferencias bajo unas reglas. Finanzas debe decidir si los controles de saldos y los ajustes documentados respaldan el resultado contable. Almacén debe valorar si las cantidades pendientes representan trabajo que el equipo puede continuar.

¿Qué referencia debes fijar antes de comparar los datos?

Fija la instantánea de origen y el alcance antes de calcular diferencias. Registra las empresas incluidas, los estados de documentos y la fecha de corte, junto con las transformaciones aprobadas para el destino. Sin esos límites, una diferencia puede deberse a poblaciones distintas; una coincidencia puede ocultar un filtro que excluyó datos necesarios.

Conserva las exportaciones originales u otras pruebas de origen aprobadas con sus parámetros de extracción. Identifica la compilación de destino y la revisión de las correspondencias. Si el origen sigue recibiendo operaciones después de la instantánea, define cómo se incorporará y conciliará ese incremento al cambiar de sistema. Un archivo aceptado ayer no cubre automáticamente las entradas de hoy.

Datos de referencia que permiten reproducir una comparación
Límite	Qué registrar antes de probar	Conclusión falsa que evita
Población	Empresas, tipos de objetos, filtros de estado y exclusiones deliberadas.	Los registros archivados o en borrador desaparecen solo de un lado.
Tiempo	Fecha y hora de la instantánea, periodo y criterio de zona horaria.	Una operación posterior parece un defecto de migración u oculta una anterior que falta.
Dinero y cantidades	Moneda, base del importe, unidades y reglas de redondeo aprobadas.	Se suman monedas o unidades diferentes en un total engañoso.
Identidad	Claves estables de origen y su correspondencia con los registros de destino.	Dos clientes con nombres parecidos se consideran la misma cuenta.
Cambios previstos	Transformaciones aprobadas y persona que las autorizó.	Una diferencia sin explicar se declara intencional después de fallar la prueba.

Conserva una referencia de negocio estable aunque cambien los ID de la base. Odoo documenta los ID externos para reconstruir relaciones importadas. La conciliación debe mostrar qué registro de origen corresponde a cada destino, incluidas las divisiones o fusiones aprobadas.

La comprobación necesita una base independiente de la transformación que revisa. Si el cálculo esperado reutiliza la misma conversión de unidades equivocada que el importador, ambos pueden coincidir. Obtén algunos casos de referencia directamente de la regla aprobada o del documento original y compáralos con el resultado importado.

¿Por qué pueden coincidir los recuentos y totales y seguir existiendo errores?

Porque los controles agregados descartan la identidad individual. Un registro ausente puede quedar compensado por otro no previsto, o dos errores de importe pueden anularse. Nuestro modelo conserva cinco registros y todos los totales por empresa y moneda, aunque dos pedidos tienen importes distintos. Mantén los controles agregados y añade la comparación de sus registros.

El modelo contiene pedidos de las empresas A y B, con EUR y USD en grupos separados. Los dos pedidos en EUR de A deberían valer 100,00 € y 200,00 €. El destino incorrecto contiene 110,00 € y 190,00 €:

Origen empresa A / EUR: 100,00 + 200,00 = 300,00
Destino empresa A / EUR: 110,00 + 190,00 = 300,00
Diferencias individuales: +10,00 y -10,00

Una variación agregada de cero no aprueba ninguno de los documentos. Son controles sintéticos de importes de pedidos, no un balance de comprobación. Usamos comparaciones decimales exactas bajo una política ilustrativa de tolerancia cero. No se ejecutaron cálculos fiscales, de cambio de moneda o de valoración.

Casos sintéticos de conciliación ejecutados el 5 de noviembre de 2026
Cambio en los datos de prueba	Controles generales	Diferencias detalladas observadas
Referencia sin cambios	Cinco filas; coinciden los totales por empresa y moneda.	Ninguna diferencia bajo las reglas del comparador.
Errores de importe que se compensan	Los recuentos y totales siguen coincidiendo.	Dos diferencias de importe: +10,00 € y -10,00 €.
La cantidad entregada pasa de 6 a 10	Los recuentos e importes siguen coincidiendo.	Una diferencia de cantidad.
Cambian la referencia del cliente y la empresa de ese cliente	Los recuentos e importes siguen coincidiendo.	Dos diferencias en campos de relación.
Cambia la identidad del adjunto	Los recuentos e importes siguen coincidiendo.	Una diferencia de identidad del contenido.
El borrador pasa al estado sale del modelo	Los recuentos e importes siguen coincidiendo.	Una diferencia de estado.
Se sustituye una referencia de pedido de origen	Los recuentos e importes siguen coincidiendo.	Una identidad ausente y otra inesperada.
Dos registros comparten una clave compuesta	Los recuentos e importes siguen coincidiendo.	Clave duplicada, identidad ausente y seis diferencias de campos.
La instantánea de destino usa otro corte	La comparación se rechaza antes de aceptar los totales.	Alcance incompatible.

Las nueve observaciones esperadas coincidieron con la ejecución local. Descarga el modelo ejecutable de conciliación y los resultados registrados. Ejecuta el archivo de Python guardado con:

python3 reconcile-model.py

El modelo compara campos identificados en registros JSON. No utiliza líneas de venta, asientos ni almacenamiento de adjuntos de Odoo. Los valores de adjuntos son etiquetas de identidad que representan futuras comprobaciones reales de contenido. El caso sin cambios solo demuestra que el comparador acepta su propia referencia especificada.

¿Qué registros de negocio debe cubrir la conciliación?

Concilia los registros que representan compromisos operativos dentro del alcance. Comprueba identidades y relaciones antes de confiar en las sumas. Revisa después importes, cantidades pendientes y estados por empresa y moneda. Añade pruebas de que los documentos siguen accesibles y de que las personas responsables pueden continuar su trabajo.

Matriz de controles propuesta para adaptar al alcance de Odoo
Área	Pruebas que comparar	¿Quién aprueba el resultado de negocio?
Clientes y productos	Identidad estable, atributos necesarios y relaciones previstas.	Responsable de los datos de clientes o productos.
Pedidos abiertos	Referencias de cabecera y líneas, importes, estado y trabajo pendiente.	Responsable del proceso de ventas o compras.
Cumplimiento parcial	Cantidades pedidas, completadas y pendientes en sus unidades aprobadas.	Responsable de almacén o de prestación del servicio.
Cuentas por cobrar y pagar	Saldos definidos por Finanzas según cuenta, empresa, moneda y periodo; excepciones por documento.	Responsable autorizado de Finanzas.
Inventario	Cantidades separadas de la valoración, con las ubicaciones o lotes relevantes.	Responsable de inventario y aprobación financiera para la valoración.
Facturas y notas de crédito	Identidad, estado, importes y relación aprobada con liquidaciones o correcciones.	Responsable autorizado de Finanzas.
Adjuntos	Documento correcto asociado al registro correcto y accesible para el rol previsto.	Responsable del proceso que depende del documento.
Accesos e integraciones	Operaciones permitidas y denegadas, más registros finales tras una transferencia controlada.	Responsables de la aplicación y la integración.

Un control financiero necesita una base contable acordada. No sumes monedas distintas, sustituyas saldos por recuentos de facturas ni supongas que importar un borrador ha contabilizado un asiento. Separa la comparación técnica de la revisión contable y conserva los informes y ajustes aceptados por Finanzas.

En pedidos parciales, revisa la obligación pendiente. Diez unidades pedidas y seis entregadas dejan cuatro por completar bajo la regla simple del modelo. Si la cabecera migrada indica diez entregadas, ese trabajo puede desaparecer de la cola del operador aunque el importe no cambie.

Para los permisos, usa la matriz de aislamiento entre empresas en Odoo 20. Para las correspondencias que generaron los datos, consulta la validación independiente de mapeos de Odoo asistidos por IA. El acta debe enlazar sus pruebas, sin reducir cada revisión especializada a un único porcentaje.

¿Qué debe incluir el CSV de aceptación de la migración?

El CSV debe vincular cada resultado esperado con el observado y sus pruebas, y registrar aparte la revisión responsable. Incluye el alcance de origen y la compilación de destino para reproducir el contraste. Mantén visibles las diferencias pendientes con referencia del defecto y estado de la nueva prueba. Un valor real vacío nunca debe significar una variación de cero.

Descarga la plantilla propuesta de aceptación. Las referencias operativas empiezan como TO_DEFINE, los valores reales están vacíos, la ejecución figura como NOT_RUN y la aprobación como PENDING. No contiene una aprobación financiera implícita ni resultados de una migración real.

Cómo separa el CSV las pruebas y la aprobación
Grupo de campos	Qué introducir	Regla
Referencia	Instantánea, filtros, alcance de empresa/moneda y compilación de destino.	Poblaciones distintas requieren un ajuste documentado antes de comparar.
Control	Método, valor esperado, unidad y tolerancia.	Aprueba las tolerancias antes de ver el resultado.
Ejecución	Valor real, variación, referencia de prueba y estado.	NOT_RUN sigue separado de una comparación superada.
Resolución	Defecto, prueba repetida y responsable técnico.	Una importación corregida exige comparar de nuevo los registros afectados.
Aprobación	Responsable de negocio, decisión y fecha.	Un resultado técnico correcto no completa automáticamente el nombre de quien aprueba.

En el control de importes A/EUR, el valor esperado y el real son 300,00. Esa fila puede indicar que el agregado coincide. Las dos comparaciones por documento siguen fallando y deben conservar sus defectos vinculados. No sustituyas sus diferencias por el cero del agregado.

Cuando una transformación sea intencional, registra su efecto esperado y quién lo autorizó. Una diferencia aceptada debe remitir a una regla o excepción aprobada. No debe convertirse en una forma de cerrar una comparación que nadie sabe explicar.

¿Cómo pruebas el proceso migrado y no solo sus exportaciones?

Empieza con un registro transferido conocido, actúa con su rol previsto e inspecciona los registros resultantes. Usa un entorno protegido y servicios externos controlados. Incluye una excepción que los operadores necesiten resolver. La exportación demuestra valores almacenados; el ensayo demuestra si el equipo puede continuar el trabajo con la nueva configuración.

En un pedido parcial, localiza el registro transferido y su documento de apoyo. Confirma que el operador autorizado ve la cantidad pendiente esperada. Ejecuta el siguiente paso acordado en el entorno protegido y compara el nuevo registro y la obligación restante con el resultado previsto. Conserva también el caso denegado de un rol que no debe realizar esa acción.

La documentación de neutralización de Odoo enumera funciones automáticas y externas desactivadas en bases de prueba. Comprueba por separado los procesos de integración personalizados. El ensayo necesita destinos controlados aunque la base esté marcada como de pruebas.

El proceso de actualización con módulos personalizados distingue los controles en una base vacía de las pruebas con datos actualizados y el ensayo. Conserva esas pruebas por separado. Que un módulo se instale no demuestra cómo trata tus pedidos históricos parcialmente cumplidos.

Si la transferencia utiliza archivos, la guía de integración con ERP antiguos explica la frontera de entrega. Incluye la importación real y su recuperación en el ensayo, con una referencia que una el archivo de origen con los registros creados en destino.

¿Cómo afectan los cambios tardíos y las diferencias pendientes a la salida?

Vincula la aprobación con la compilación y los datos probados. Una correspondencia modificada tarde o un nuevo incremento de origen puede invalidar parte de las pruebas. Identifica los controles afectados y repítelos antes de salir. Cada diferencia pendiente necesita un responsable de decidir; su impacto determina si bloquea el cambio, no su antigüedad o estado en el gestor de tareas.

Define el procedimiento para el último incremento antes del ensayo. Indica cuándo termina la referencia, quién controla nuevas escrituras en origen y cómo se identifican los cambios posteriores. La comparación final debe explicar esos cambios expresamente, en lugar de considerar desconocido todo registro nuevo del destino.

Para cada defecto restante, registra el proceso afectado y su posible consecuencia. Una persona autorizada puede aceptar una excepción según la política acordada. Conserva la decisión y sus condiciones. Una aprobación genérica no permite saber después si se aceptó conscientemente un adjunto ausente o una entrega pendiente incorrecta.

Tras el cambio, repite los controles acordados sobre el resultado de producción y observa el siguiente paso operativo relevante. Una importación programada o una entrega posterior puede revelar un problema que no aparece al iniciar sesión. La lista de QA antes del lanzamiento sitúa estas pruebas dentro de la decisión de publicación.

¿Qué exigiríamos antes de firmar la aceptación?

Exigiríamos una trazabilidad desde la referencia acordada hasta las aprobaciones correspondientes, pasando por comparaciones detalladas y pruebas de procesos. Empieza por un proceso crítico y expón cada diferencia sin resolver. Extiende el método al alcance aprobado. El acta firmada debe explicar qué se demostró, con qué compilación y bajo qué condiciones pendientes.

El servicio de aseguramiento de calidad de Wavect es la vía comercial para una aceptación independiente. Trae el alcance de la migración y un resultado discutido. La primera revisión útil determina si las pruebas distinguen un resultado de negocio correcto de una migración que solo terminó sin errores.

Preguntas sobre la aceptación de migraciones a Odoo

¿Actualizar Odoo e importar el historial de otro ERP requieren la misma aceptación?

Ambos necesitan pruebas del resultado de negocio acordado, pero las reglas de transferencia cambian. Una importación externa puede dividir registros, asignar identificadores o mantener un historial aprobado en un archivo. Una actualización de Odoo puede modificar vistas o módulos propios. Define la ruta y sus diferencias esperadas; no presupongas que todos los campos deben permanecer idénticos.

¿Los recuentos pueden aprobar los saldos de apertura?

No. Un recuento indica cuántos registros cumplen un filtro, no sus importes, base contable ni relaciones. Finanzas debe definir las cuentas, monedas, periodos y estados pertinentes, revisar la conciliación y aprobar los ajustes. Conserva esa aprobación separada del recuento técnico y de un mensaje de importación correcta; ninguno sustituye la decisión contable.

¿Toda diferencia monetaria debe ser cero?

Define la precisión y las transformaciones aprobadas antes de ejecutar. Algunas comparaciones deben ser exactas; otras pueden necesitar una tolerancia o ajuste de conciliación justificado. Conserva cada diferencia y su motivo. No compenses errores opuestos ni inventes una tolerancia después de un fallo. El responsable de negocio debe aceptar la política utilizada.

¿Cómo se trata el historial que se deja expresamente en un archivo?

Registra la población excluida y por qué permanece fuera de la base operativa. Define quién puede recuperarla y cómo se vinculan sus documentos con los registros trasladados. Prueba ese acceso con los roles previstos. La aceptación debe conservar el plan histórico aprobado, sin decidir por su cuenta obligaciones legales de conservación ni eliminar acceso a información necesaria.

¿Cómo comparas un adjunto regenerado de forma deliberada?

Elige la regla de identidad antes de comparar archivos. Un original sin cambios puede comprobarse por identidad de contenido; un documento regenerado puede necesitar una comparación semántica de campos y asociación al registro. Documenta la transformación y las diferencias esperadas. Un hash de bytes distinto no demuestra corrupción si la regeneración estaba aprobada.

¿Puede aprobarse la plantilla con controles en NOT_RUN?

NOT_RUN significa que no se ha registrado evidencia de ejecución para ese control. No equivale a una comparación superada. Si la política permite una excepción concreta, conserva la decisión autorizada y su consecuencia por separado. No cambies el resultado a PASS porque el proyecto necesite una firma o tenga una fecha de lanzamiento.

¿El modelo ejecutable valida mi base de Odoo?

No. Compara sus propios registros JSON sintéticos y reproduce nueve casos definidos. No se conecta a tu base ni inspecciona informes contables; tampoco ejecuta permisos o procesos reales. Úsalo para cuestionar el diseño de aceptación, adapta después el CSV y ejecuta los controles necesarios sobre la instantánea de origen y la compilación de destino reales.