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 metodo de costeo le ocultaba a la empresa que, en al menos un producto, vendia sin margen.
Migrar un ERP grande no es copiar un sistema de una version a otra. Es trasladar tambien todo lo que ese sistema tenia mal. Cuando la base esta sucia, la migracion no la limpia: la hereda, la vuelve mas cara de corregir y ademas le pone encima la etiqueta tranquilizadora de "sistema nuevo". Este texto describe como un distribuidor mayorista de iluminacion y mobiliario de proyecto en Mexico se preparo para actualizar de Odoo 16 a Odoo 19 y por que el primer entregable no fue la migracion, sino la estabilizacion de su inventario.
El resultado de esa fase previa fue incomodo y valioso a la vez: el metodo de costeo configurado estaba deformando la lectura financiera del negocio. Lo que sigue son las cifras reales del diagnostico, anonimizadas, y el principio transferible que dejaron.
El espejismo de la migracion limpia
El consejo mas comun cuando una version de Odoo se acerca a su fin de soporte es directo: actualiza. Odoo 16 dejaria de recibir soporte, la presion del calendario era real, y la ruta evidente parecia ser mover la base a la version 19 y seguir operando.
El problema es que "solo actualiza" asume que lo que se traslada esta 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 anios de transacciones sin cortes de periodo.
- 61 campos personalizados que tendrian que actualizarse uno por uno para no romperse en la version nueva.
- Alrededor de 29,000 lineas de codigo en Python y 12,000 en XML de personalizaciones acumuladas.
Migrar todo eso sin revisarlo primero no es una migracion; es mudar una casa sin abrir las cajas para ver que hay adentro. Y adentro habia un problema que ningun upgrade de version iba a resolver por si solo.
El diagnostico: un ERP que ya no decia la verdad
Antes de tocar la version, hicimos lo que casi nadie hace: en lugar de confiar en los numeros que el sistema mostraba, los pusimos a prueba. La pregunta no era "como migramos", sino "podemos confiar en lo que este inventario nos esta diciendo hoy".
La respuesta llego 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 nucleo de la estabilizacion fue validar, con productos reales, los tres metodos 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 metodos. En dos lineas cada uno, para quien no vive en la contabilidad de costos:
- Precio estandar. 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 unico. Estable ante entradas multiples, ideal para rotacion rapida.
No se trata de cual es "el mejor" en abstracto. Se trata de cual esta bien aplicado para cada familia de producto, y sobre todo de si los numeros que genera son creibles. Se documentaron tres escenarios, uno por metodo, con productos reales del catalogo. Y ahi aparecio el hallazgo.
El climax: cuando el costeo miente
En el escenario de PEPS, sobre un producto real de la categoria de tratamiento acustico, los numeros contaban una historia que la operacion no habia notado:
- Margen comercial de 0%. El sistema registraba una venta que, segun su propio costeo, no dejaba ganancia alguna.
- Deflacion de -36.6% en la valuacion del inventario de ese producto. El valor en libros se estaba erosionando de forma silenciosa.
- Rotacion de 11.4%, muy baja: producto que se mueve poco y ata capital.
- 990 unidades sin documentacion de origen clara. Existencias que el sistema tenia, pero cuya entrada nadie podia rastrear.
Cada una de esas cifras, por separado, es un foco amarillo. Juntas, en un solo producto, son un diagnostico: 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 habria estrenado un sistema mas moderno para seguir tomando decisiones sobre datos deformados. La version 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 asi con un rediseno completo. No fue necesario. La cura fue quirurgica: 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 catalogo de mayoreo con miles de referencias, dos productos pueden llamarse igual y ser distintos: mismo nombre comercial, distinta marca o linea. Si se intenta ajustar el inventario por nombre o por referencia interna, Odoo no sabe a cual de los dos aplicar el cambio y falla, o peor, lo aplica al equivocado.
La solucion fue anclar cada ajuste al identificador externo unico 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 ubicacion. El stock fisico y el stock del sistema vuelven a coincidir, que es la condicion minima para que cualquier costeo posterior signifique algo.
Estabilizar antes de migrar, el flujo completo
El orden importa. Este es el flujo que separo la estabilizacion de la migracion, y por que 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 si vale la pena migrar.
El principio transferible
Lo que este mayorista aprendio sirve para cualquier distribuidora que corra Odoo y este pensando en actualizar de version. 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 teoria. Un metodo bien elegido pero mal aplicado produce numeros que parecen sanos y no lo estan.
- 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 senal de que el costeo perdio el hilo.
- Ajuste el inventario por identificador unico, nunca por nombre. En catalogos grandes, los nombres se repiten. El identificador externo es la unica ancla confiable.
- Reconcilie fisico contra sistema antes de migrar. Si esos dos numeros no coinciden hoy en la version vieja, no coincidiran manana en la nueva; solo se veran mas oficiales.
- Migre cuando la base diga la verdad, no cuando el calendario apriete. La urgencia es real, pero una migracion sobre datos deformados cuesta mas de corregir despues que de estabilizar antes.
Cierre: la migracion es el segundo problema
La leccion 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 version del ERP casi nunca es el problema. El problema es que la base perdio su verdad, y ningun software nuevo la devuelve solo.
Estabilizar antes de migrar no es un paso tecnico mas. Es la diferencia entre estrenar un sistema confiable y estrenar uno que miente con mejor interfaz. Primero la verdad del inventario. Despues, la version.
Si su distribuidora corre Odoo y esta pensando en actualizar de version, la conversacion empieza en [email protected]. Traemos el metodo de estabilizacion y el criterio de cuando conviene, o no, migrar todavia.
Nota sobre veracidad y privacidad
Las cifras de este articulo (230 GB de base de datos, 61 campos personalizados, cerca de 29,000 lineas de Python y 12,000 de XML, y en un escenario de costeo PEPS: margen de 0%, deflacion de -36.6%, rotacion de 11.4% y 990 unidades sin origen documentado) provienen de la documentacion de estabilizacion 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 articulo se enfoca exclusivamente en el aprendizaje tecnico. Ningun dato personal fue leido ni citado; solo agregados operativos.