Introducción
Hay funcionalidades discretas en el modelo de datos de Odoo que pasan desapercibidas hasta que te topas con una estructura multisociedad. Uno de esos elementos es el llamado campo dependiente de empresa: una pequeña propiedad técnica que evita duplicar datos y simplifica mantener registros compartidos entre varias empresas.
En la mayoría de instalaciones cada campo de un registro tiene un único valor visible para todos los usuarios. El problema surge cuando varias sociedades comparten el mismo producto pero requieren información distinta —por ejemplo, códigos internos diferentes o cuentas contables por defecto distintas— sin querer replicar el producto para cada entidad.
Ahí entra el atributo company_dependent. Tanto si desarrollas módulos, personalizas Odoo o simplemente exploras la plataforma, saber cómo y cuándo usar campos dependientes por empresa te permite diseñar soluciones limpias en entornos multiempresa.
¿Qué es un campo dependiente de empresa en Odoo?
Un campo dependiente de empresa es, en esencia, un campo que puede almacenar un valor distinto por cada sociedad, manteniéndose en el mismo registro. Un usuario de la Empresa A verá la versión de su entidad; otro usuario de la Empresa B verá otra distinta, aunque ambos miren la misma ficha.
Para el usuario la interacción no cambia: en la interfaz se comporta como cualquier otro campo. La gestión diferencial ocurre a nivel del ORM, que redirige lecturas y escrituras según la empresa activa.
Cómo se muestra en la interfaz
Visualmente no hay iconos ni etiquetas que indiquen que un campo es dependiente de empresa. Esa transparencia es deliberada: la experiencia de usuario debe ser coherente, sin complejidad visible.
Desde el punto de vista del desarrollador, el comportamiento se puede aplicar a muchos tipos de campo (Char, Boolean, Integer, Float, Many2one, etc.). Basta añadir company_dependent=True en la declaración del campo para activar la lógica del ORM.
Odoo Studio ofrece algunos de estos campos ya expuestos en modelos estándar —por ejemplo, campos de cuentas en productos— y permite crear campos personalizados. No obstante, el soporte de Studio para la opción company_dependent varía según la versión, así que para control total conviene el desarrollo técnico.
Cómo funciona el campo
Bajo el capó, el almacenamiento y recuperación de valores de estos campos difiere de los campos normales. Comprender la mecánica evita sorpresas al diseñar integraciones, migraciones o depurar comportamientos inesperados.
Almacenamiento en ir.property
En Odoo 16 y versiones anteriores, los valores de los campos dependientes por empresa no se guardan en la tabla del modelo principal, sino en una tabla sistema llamada ir.property.
Cada fila en ir.property asocia:
- Un registro concreto (por ejemplo, un producto con ID 42)
- Un campo concreto (por ejemplo, property_account_income_id)
- Una compañía determinada
- Y el valor correspondiente a esa combinación
Por eso el comportamiento resulta transparente: el ORM consulta y actualiza ir.property automáticamente según la compañía activa en el entorno.
Cambios en Odoo 17 y posteriores
A partir de Odoo 17 el enfoque cambió: los valores por empresa se almacenan directamente en la tabla del modelo usando una columna jsonb que guarda un diccionario con las entradas por compañía. Esto mejora notablemente el rendimiento y simplifica las consultas.
La API para desarrolladores y la apariencia en pantalla se mantienen, pero las operaciones a gran escala son ahora mucho más ágiles.
Valores por defecto
Los campos dependientes por empresa admiten valores por defecto específicos de cada entidad. Si no se ha definido un valor para una compañía, el campo puede recurrir al valor por defecto del campo o al ajuste establecido por compañía (ir.property en Odoo 16 y anteriores, o directamente en la definición del modelo en Odoo 17+).
Interacción con el ORM
Cuando accedes a un campo dependiente en el ORM, siempre se respeta la compañía activa en el entorno (self.env.company). Esto implica:
- Leer el campo devuelve el valor correspondiente a la compañía activa
- Escribir actualiza solo el valor de la compañía activa
- Cambiar el contexto con record.with_company(company) permite leer o escribir para otra compañía específica
Casos de uso empresariales
El campo dependiente de empresa no es una mera curiosidad técnica: resuelve problemas habituales en configuraciones multiempresa. A continuación verás escenarios prácticos donde resulta especialmente útil.
1. Contabilidad: cuentas de ingresos y gastos por empresa
Un uso típico en Odoo son las cuentas de producto: las propiedades property_account_income_id y property_account_expense_id suelen configurarse por empresa.
En la práctica eso significa que el mismo producto puede tener el mismo catálogo compartido y, sin embargo, cada entidad aplicará su propio plan contable. No hace falta duplicar el producto para tener cuentas distintas.
2. Ventas y CRM: listas de precios por entidad
En grupos con varias sociedades, cada una puede aplicar estrategias comerciales distintas. Un campo de lista de precios dependiente por empresa permite que, aunque el cliente sea el mismo en el CRM, cada compañía use su propia lista por defecto al crear pedidos.
Así se centraliza la información del cliente sin sacrificar reglas comerciales propias por entidad.
3. Inventario: método de valoración por compañía
Cuando un grupo opera almacenes en jurisdicciones con normativas o prácticas contables diferentes, un producto puede necesitar FIFO en una entidad y coste medio en otra. Marcar el método de valoración por empresa evita replicar categorías o productos.
4. Fabricación: proveedor por defecto según la entidad
Si el proveedor habitual varía según la sociedad, un Many2one dependiente de empresa hacia res.partner almacena el proveedor preferido por cada entidad sin conflictos entre ellas.
5. Campos regulatorios específicos por país
Empresas que operan en múltiples países suelen requerir referencias regulatorias distintas en el mismo registro (códigos arancelarios, clasificaciones fiscales, etc.). Un campo Char dependiente por empresa es una solución sencilla y de bajo coste para mantener esos datos.
Crear o personalizar el campo
Crear campos dependientes: Studio o código
Hay dos vías principales para añadir este tipo de campo: Odoo Studio para cambios rápidos sin código, o declarar el campo en un módulo Python para control total.
Con Odoo Studio
Studio facilita la creación de campos sin programar, pero no siempre muestra una casilla clara para marcar company_dependent en todas las versiones. En Odoo 16 y 17 algunas combinaciones de modelo y tipo de campo sí permiten activarlo desde Studio.
En muchos casos, cuando se necesita precisión o lógica adicional, el desarrollo técnico sigue siendo la vía más fiable.
Enfoque técnico: campos en Python
Declarar un campo dependiente en un módulo personalizado es directo y es la práctica habitual en desarrollos profesionales. Un ejemplo típico sería:
Basta añadir company_dependent=True en la definición del campo; el ORM se encarga del resto.
Establecer valores por defecto por empresa
En Odoo 16 y versiones anteriores puedes fijar un valor por defecto para una compañía mediante ir.property. Esto es útil para proporcionar un valor razonable a todas las fichas de una entidad sin tocar cada registro individualmente.
Ejemplo de asignación de defecto por código con ir.property:
En Odoo 17+ los valores por defecto se almacenan directamente en el modelo y también pueden exponerse en la definición del campo.
Limitaciones de Odoo Studio y campos personalizados
Recuerda que los campos personalizados deben llevar el prefijo x_ y que la visibilidad de la opción dependiente por empresa en Studio no siempre es completa. Cuando sea necesario, activa el modo desarrollador y revisa la configuración técnica o crea el campo desde un módulo.
Buenas prácticas
Patrones y buenas prácticas
1. Úsalo solo cuando el valor realmente varíe por empresa
Este tipo de campos añade complejidad. Si el dato es idéntico para todas las entidades, es preferible un campo normal. Reserva company_dependent=True para cuando cada sociedad necesite una versión distinta del mismo dato.
2. Prueba siempre en contexto multiempresa
Desarrolla y valida con al menos dos compañías activas: errores que no aparecen en un entorno monocompañía suelen aflorar en producción.
3. Utiliza with_company() para operaciones entre compañías
Si necesitas leer o escribir valores para otra compañía, emplea record.with_company(target_company) en lugar de cambiar manualmente el contexto de env.company y no restaurarlo.
4. Cuidado con importaciones y exportaciones
Las exportaciones reflejan la compañía del usuario que realiza la acción; importar el mismo fichero desde otra compañía aplicará los valores a esa segunda entidad. Documenta este comportamiento en procesos de migración e importación de datos.
5. Documenta qué campos son dependientes por empresa
Los usuarios raramente saben qué campos cambian según la compañía. Añadir una nota en la documentación interna o en la formación evita confusiones al cambiar de entidad y ver distintos valores en la misma ficha.
6. Prefiere Many2one a Char para datos referenciados
Si el valor por empresa hace referencia a otro registro (cuenta, lista de precios, partner), usa un Many2one dependiente de empresa en lugar de guardar un nombre como texto: mejora la integridad y los informes.
Errores comunes
Trampas comunes y cómo evitarlas
Error 1: Ignorar el contexto de compañía en acciones automáticas
Acciones programadas o automatismos suelen ejecutarse con la primera compañía de la base por defecto. Si tocan un campo dependiente, especifica el contexto (with_company) para evitar escribir en la compañía equivocada.
Error 2: Confundirlo con un campo calculado
Un campo dependiente no es un compute: la variación por empresa viene del almacenamiento, no de una función compute. Mezclar compute= con company_dependent puede producir comportamientos erráticos o errores.
Error 3: Buscar sin tener en cuenta todas las compañías
Las búsquedas estándar del ORM respetan la compañía activa. Si necesitas cruzar datos entre todas las entidades debes consultar ir.property directamente (Odoo 16-) o tratar la columna jsonb en Odoo 17+, lo cual requiere consultas específicas.
Error 4: No establecer valores por defecto para todas las compañías
Al introducir un campo dependiente en un sistema en producción, los registros existentes devolverán False/None para compañías que no tengan valor explícito. Si tu lógica exige un valor por defecto, aplícalo masivamente mediante un script de migración.
Error 5: Confundirlo con permisos de acceso
Este atributo determina qué valor se muestra según la compañía, no quién puede ver el campo. Para ocultar un campo a ciertos usuarios o compañías usa reglas de registro o control de acceso a nivel de campo.
Conclusión
Un campo dependiente de empresa es una de esas utilidades que no llaman la atención hasta que resuelven un problema real. Cuando varias entidades comparten registros, permiten mantener datos comunes y, al mismo tiempo, respetar configuraciones específicas por sociedad: contabilidad, precios, referencias regulatorias y más.
Conocer su funcionamiento interno, qué versión de Odoo cambia el modelo de almacenamiento y los riesgos habituales te ahorrará tiempo en proyectos multiempresa. Manejar bien estos campos es una habilidad práctica muy valorada en implantaciones complejas.
Si necesitas mantener datos por compañía sin romper el modelo de datos compartido, company_dependent=True es la herramienta adecuada.
¿Necesitas ayuda con tu implantación de Odoo?
En Dasolo acompañamos a empresas en implantaciones, personalizaciones y optimización de Odoo, incluyendo escenarios multiempresa complejos. Podemos diseñar el modelo de datos, definir una estrategia de campos por compañía o encargarnos de un despliegue completo adaptado a tus necesidades.
Si tienes dudas sobre campos dependientes por empresa o cualquier otro aspecto de tu implementación de Odoo, estaremos encantados de ayudarte. Contacta con nosotros y hablemos sobre tu proyecto.