Un caso real de mayoreo, anonimizado. Un ERP de 230 GB y 61 campos personalizados estaba listo para saltar de Odoo 16 a Odoo 19. Antes de migrar, saneamos la verdad del inventario. En el intento descubrimos que el método de costeo le ocultaba a la empresa que, en al menos un producto, vendía sin margen.
Migrar un ERP grande no es copiar un sistema de una versión a otra. Es trasladar también todo lo que ese sistema tenía mal. Cuando la base está sucia, la migración no la limpia: la hereda, la vuelve más cara de corregir y además le pone encima la etiqueta tranquilizadora de "sistema nuevo". Este texto describe como un distribuidor mayorista de iluminación y mobiliario de proyecto en México se preparó para actualizar de Odoo 16 a Odoo 19 y por qué el primer entregable no fue la migración, sino la estabilización de su inventario.
El resultado de esa fase previa fue incómodo y valioso a la vez: el método de costeo configurado estaba deformando la lectura financiera del negocio. Lo que sigue son las cifras reales del diagnóstico, anonimizadas, y el principio transferible que dejaron.
El espejismo de la migración limpia
El consejo más común cuando una versión de Odoo se acerca a su fin de soporte es directo: actualiza. Odoo 16 dejaría de recibir soporte, la presión del calendario era real, y la ruta evidente parecía ser mover la base a la versión 19 y seguir operando.
El problema es que "solo actualiza" asume que lo que se traslada está sano. En este caso no lo estaba. El punto de partida era un ERP con historia:
- Una base de datos de 230 GB, engordada por años de transacciones sin cortes de periodo.
- 61 campos personalizados que tendrían que actualizarse uno por uno para no romperse en la versión nueva.
- Alrededor de 29,000 líneas de código en Python y 12,000 en XML de personalizaciones acumuladas.
Migrar todo eso sin revisarlo primero no es una migración; es mudar una casa sin abrir las cajas para ver que hay adentro. Y adentro había un problema que ningún upgrade de versión iba a resolver por sí solo.
El diagnóstico: un ERP que ya no decía la verdad
Antes de tocar la versión, hicimos lo que casi nadie hace: en lugar de confiar en los números que el sistema mostraba, los pusimos a prueba. La pregunta no era "cómo migramos", sino "podemos confiar en lo que este inventario nos está diciendo hoy".
La respuesta llegó por el lado del costeo. Un distribuidor de mayoreo vive de un margen que muchas veces es delgado; si el sistema calcula mal el costo de lo que vende, la empresa toma decisiones de precio sobre una realidad que no existe. Por eso el núcleo de la estabilización fue validar, con productos reales, los tres métodos de costeo que Odoo puede aplicar.
La prueba que casi nadie hace: validar el costeo antes de confiar en el
Odoo permite valuar el inventario con tres métodos. En dos líneas cada uno, para quien no vive en la contabilidad de costos:
- Precio estándar. Se fija un costo por producto y no cambia con cada compra. Simple, pero se desalinea de la realidad si los precios de proveedor se mueven.
- PEPS (primeras entradas, primeras salidas). Lo que entra primero sale primero, y su costo original viaja con la venta. Bueno para trazabilidad por lote.
- Costo promedio ponderado. Cada compra recalcula un costo promedio único. Estable ante entradas múltiples, ideal para rotación rápida.
No se trata de cuál es "el mejor" en abstracto. Se trata de cuál está bien aplicado para cada familia de producto, y sobre todo de si los números que genera son creíbles. Se documentaron tres escenarios, uno por método, con productos reales del catálogo. Y ahí apareció el hallazgo.
El clímax: cuando el costeo miente
En el escenario de PEPS, sobre un producto real de la categoría de tratamiento acústico, los números contaban una historia que la operación no había notado:
- Margen comercial de 0%. El sistema registraba una venta que, según su propio costeo, no dejaba ganancia alguna.
- Deflación de -36.6% en la valuación del inventario de ese producto. El valor en libros se estaba erosionando de forma silenciosa.
- Rotación de 11.4%, muy baja: producto que se mueve poco y ata capital.
- 990 unidades sin documentación de origen clara. Existencias que el sistema tenía, pero cuya entrada nadie podía rastrear.
Cada una de esas cifras, por separado, es un foco amarillo. Juntas, en un solo producto, son un diagnóstico: el inventario no era una fuente de verdad, era una fuente de confianza mal colocada. Si esa base se hubiera migrado tal cual a Odoo 19, la empresa habría estrenado un sistema más moderno para seguir tomando decisiones sobre datos deformados. La versión nueva no corrige un costeo mal cimentado; lo hereda con mejor apariencia.
La cura no fue re-implementar, fue estabilizar
Es tentador responder a un hallazgo así con un rediseño completo. No fue necesario. La cura fue quirúrgica: devolverle al inventario su trazabilidad, no reinventarlo.
Una pieza central de ese trabajo fue el ajuste masivo de existencias hecho de la forma correcta. En un catálogo de mayoreo con miles de referencias, dos productos pueden llamarse igual y ser distintos: mismo nombre comercial, distinta marca o línea. Si se intenta ajustar el inventario por nombre o por referencia interna, Odoo no sabe a cuál de los dos aplicar el cambio y falla, o peor, lo aplica al equivocado.
La solución fue anclar cada ajuste al identificador externo único que Odoo asigna a cada variante, no a su nombre. Con esa ancla, la carga masiva deja de adivinar: cada cantidad contada aterriza en la variante correcta, con su fecha y su ubicación. El stock físico y el stock del sistema vuelven a coincidir, que es la condición mínima para que cualquier costeo posterior signifique algo.
Estabilizar antes de migrar, el flujo completo
El orden importa. Este es el flujo que separó la estabilización de la migración, y por qué cada paso va antes del siguiente.
flowchart LR
A[ERP heredado<br/>230 GB, 61 campos] --> B{Los numeros<br/>son creibles?}
B -->|Validar costeo<br/>3 metodos, productos reales| C[Hallazgo:<br/>margen 0%, deflacion -36.6%]
C --> D[Estabilizar:<br/>ajuste por ID externo]
D --> E[Inventario reconciliado<br/>fisico = sistema]
E --> F{Ahora si:<br/>migrar a v19}
F --> G[Odoo 19<br/>sobre base confiable]
classDef riesgo fill:#3d0a0a,stroke:#f87171,stroke-width:1px,color:#fee2e2;
classDef prueba fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#e2e8f0;
classDef cura fill:#052e16,stroke:#34d399,stroke-width:1px,color:#e2e8f0;
class A,C riesgo
class B,D prueba
class E,F,G cura
Diagrama: en rojo el riesgo heredado, en morado las pruebas que lo revelan, en verde la base ya confiable sobre la que sí vale la pena migrar.
El principio transferible
Lo que este mayorista aprendió sirve para cualquier distribuidora que corra Odoo y esté pensando en actualizar de versión. No es una receta de producto, es una secuencia de criterio:
- No confunda actualizar con sanear. El fin de soporte obliga a migrar; no obliga a migrar el desorden. Son dos proyectos, y el saneamiento va primero.
- Ponga a prueba el costeo con productos reales, no con la teoría. Un método bien elegido pero mal aplicado produce números que parecen sanos y no lo están.
- Trate el margen de 0% como una alarma, no como un dato. En mayoreo, un margen que el sistema reporta en cero casi nunca es la realidad; es una señal de que el costeo perdió el hilo.
- Ajuste el inventario por identificador único, nunca por nombre. En catálogos grandes, los nombres se repiten. El identificador externo es la única ancla confiable.
- Reconcilie físico contra sistema antes de migrar. Si esos dos números no coinciden hoy en la versión vieja, no coincidirán mañana en la nueva; solo se verán más oficiales.
- Migre cuando la base diga la verdad, no cuando el calendario apriete. La urgencia es real, pero una migración sobre datos deformados cuesta más de corregir después que de estabilizar antes.
Cierre: la migración es el segundo problema
La lección de fondo es sencilla y contraintuitiva. Cuando una empresa siente que "su inventario no cuadra" o que "el margen que reporta el sistema no se siente real", el instinto es migrar a algo mejor. Pero la versión del ERP casi nunca es el problema. El problema es que la base perdió su verdad, y ningún software nuevo la devuelve solo.
Estabilizar antes de migrar no es un paso técnico más. Es la diferencia entre estrenar un sistema confiable y estrenar uno que miente con mejor interfaz. Primero la verdad del inventario. Después, la versión.
Si su distribuidora corre Odoo y está pensando en actualizar de versión, la conversación empieza en dev@transgenia.org. Traemos el método de estabilización y el criterio de cuando conviene, o no, migrar todavía.
Nota sobre veracidad y privacidad
Las cifras de este artículo (230 GB de base de datos, 61 campos personalizados, cerca de 29,000 líneas de Python y 12,000 de XML, y en un escenario de costeo PEPS: margen de 0%, deflación de -36.6%, rotación de 11.4% y 990 unidades sin origen documentado) provienen de la documentación de estabilización de un proyecto real de mayoreo ejecutado entre enero y junio de 2026. Ninguna cifra fue estimada ni redondeada. El cliente se presenta de forma anonima: no se nombra a la empresa, sus marcas, sus proveedores ni a las personas involucradas, y el artículo se enfoca exclusivamente en el aprendizaje técnico. Ningún dato personal fue leído ni citado; solo agregados operativos.