Una empresa en crecimiento añade una segunda entidad legal en Odoo, tal vez una nueva filial, una empresa conjunta, o un registro separado para un mercado nuevo, y en pocos días algo se rompe sin que nadie lo toque directamente. Un usuario actualiza los datos bancarios de un proveedor y el cambio aparece silenciosamente en una factura de una empresa completamente distinta. Una orden de compra creada bajo una entidad aparece en la cola de aprobación de otra entidad. Nada estaba mal configurado. El código personalizado simplemente nunca se escribió sabiendo que "empresa" podía significar más de una cosa.
Por qué el código de una sola empresa se rompe primero
La mayoría de los módulos personalizados de Odoo nacen limitados a una sola empresa, porque esa es la única realidad que tiene el cliente en ese momento. Los desarrolladores añaden campos, sobrescriben los métodos create y write, y construyen lógica de búsqueda que lee registros sin filtrar por company_id, porque solo hay una empresa en juego y el comportamiento por defecto parece correcto. Las propias apps estándar de Odoo (ventas, compras, contabilidad) llevan reglas de registro multiempresa integradas, pero los módulos personalizados no las heredan automáticamente. En el momento en que se registra una segunda empresa en la misma base de datos, cada lectura y escritura sin filtrar se convierte en una fuga silenciosa entre empresas: datos bancarios compartidos, presupuestos u órdenes de compra apareciendo bajo la entidad equivocada, registros de contactos y productos heredando valores pensados solo para una empresa hermana.
La solución es una adaptación, no una reescritura
La buena noticia es que esto rara vez requiere reconstruir todo. La solución es devolver los dominios de company_id y las reglas de registro a los lugares que se los saltaron: los campos heredados necesitan dominios explícitos con alcance por empresa, la lógica de búsqueda y recuperación necesita un filtro de empresa real en lugar de depender del contexto de empresa por defecto, y cada modelo personalizado necesita su propia regla de registro multiempresa, no solo las estándar. Lo difícil es encontrar cada lugar donde existe la brecha, porque el error solo aparece una vez que hay datos reales multiempresa que lo expongan, y para entonces el cliente ya está operando dos entidades en la misma instancia.
Nuestra opinión
Esto es lo bastante común como para diseñarlo antes de que haga falta: cualquier desarrollo personalizado de Odoo debería asumir que llegará una segunda empresa, incluso cuando el cliente esté seguro de que siempre habrá solo una. Una auditoría multiempresa breve de la lógica personalizada antes de que una nueva entidad entre en producción, en lugar de después, sale mucho más barata que desenredar datos en vivo que ya han cruzado los límites entre empresas. Si tu equipo está añadiendo una entidad legal a una instancia de Odoo existente, este es exactamente el tipo de problema que vale la pena conversar con Majorbird antes de que aparezca por sí solo.