Cada empresa maneja datos únicos que el software estándar no contempla; los campos personalizados en Odoo son la herramienta para capturar esa información específica dentro del propio sistema.
En vez de encajonar tus procesos en un modelo de datos rígido, Odoo permite añadir atributos a casi cualquier registro —cliente, pedido, producto o factura— y almacenar esa información junto al resto de los datos del sistema.
Esta guía explica lo esencial: qué son los campos personalizados, cómo se gestionan internamente, las formas de crearlos (con o sin código) y cómo utilizarlos de forma ordenada para mantener Odoo manejable y escalable.
¿Qué es un campo personalizado en Odoo
Un campo personalizado es una columna adicional que añades a un modelo existente en Odoo para guardar un dato concreto relacionado con un registro, con la misma naturaleza práctica que un campo nativo.
En Odoo, esos campos suelen identificarse con el prefijo x_. Los creados desde Odoo Studio adoptan nombres como x_studio_priority_level; los añadidos por desarrollo pueden usar un prefijo propio de la compañía, por ejemplo x_micomp_cost_center.
Para el usuario, un campo personalizado se comporta exactamente igual que cualquier otro: aparece en formularios, vistas de lista, filtros, agrupaciones e informes. Quien trabaje con el sistema no percibe si el campo fue creado vía interfaz o por código.
Tipos de campo disponibles
Odoo ofrece una amplia tipología de campos para cubrir la mayor parte de necesidades de información en una implantación ERP:
- Texto corto (Char): para referencias o etiquetas breves
- Texto largo: notas o descripciones de varias líneas
- Entero (Integer): números sin decimales para contadores o puntuaciones
- Decimal (Float): valores numéricos con decimales para medidas o tarifas
- Moneda (Monetary): importes con manejo de divisa vinculados a un campo de moneda
- Booleano: casilla de verificación verdadero/falso
- Fecha / Fecha y hora: fecha de calendario o sello temporal
- Selección: lista desplegable con opciones fijas
- Many2one: enlace a un único registro de otro modelo
- One2many: listado de registros relacionados desde otro modelo
- Many2many: múltiples registros vinculados de otro modelo
- Binario: adjunto de fichero
- HTML: contenido enriquecido
Elegir bien el tipo desde el principio evita problemas posteriores; cuando los valores posibles se conocen, una selección suele ser preferible a texto libre para preservar la calidad de los datos.
Cómo funciona el campo
Odoo se apoya en el ORM (Object-Relational Mapping): cada vista y registro están respaldados por modelos Python que mapean tablas en PostgreSQL. Al crear un campo personalizado, Odoo lo registra en el ORM y hace la columna correspondiente en la base de datos automáticamente.
Esa capa de metadatos es lo que da flexibilidad al modelo de datos: no modificas el código fuente, sino que extiendes el modelo mediante entradas en la tabla ir.model.fields que Odoo carga al arrancar.
Campos definidos en código vs. campos definidos en la base de datos
En desarrollo tradicional de Odoo, los campos se declaran en clases Python del modelo usando la API del framework. Así es como se crean campos permanentes y versionables en un módulo.
Un ejemplo típico en Python define el campo dentro de la clase del modelo, indicando el tipo y la etiqueta para la interfaz.
Los campos creados vía interfaz o API siguen otra vía: se almacenan como state = 'manual' en ir.model.fields y se cargan en tiempo de ejecución. Desde la perspectiva del usuario, ambos tipos generan una columna real en la base de datos y funcionan igual.
Campos relacionales y reciprocidad
Cuando añades un Many2one a otro modelo, Odoo espera una relación inversa One2many en el modelo destino; no es solo una convención: el ORM usa esas relaciones para navegar entre registros.
Por ejemplo, si pones x_project_id (Many2one hacia project.project) en un pedido de venta, conviene crear x_sale_order_ids (One2many hacia sale.order) en el proyecto para que desde el proyecto se puedan ver las órdenes vinculadas por la interfaz estándar.
Campos calculados (Computed)
Los campos computados en Odoo obtienen su valor a partir de otros campos mediante una función Python. Se declaran con el parámetro compute y son de solo lectura, recalculándose cuando cambian sus dependencias.
Los campos computados son muy útiles pero requieren programación; no se crean con Odoo Studio sin entrar en modo desarrollador y conocimientos de Python.
Casos prácticos en la empresa
En nuestros proyectos es habitual añadir campos personalizados. A continuación, cinco ejemplos reales de uso en empresas.
1. CRM: cualificar leads con más detalle
Más allá de los datos de contacto y etapas, un campo de selección para “Sector” o un Many2one a un modelo interno “Segmento” ayuda a los comerciales a clasificar clientes potenciales y permite informes de pipeline por segmento.
2. Ventas: códigos internos de proyecto
Empresas que facturan por proyecto suelen necesitar vincular un código interno o referencia de presupuesto a cada presupuesto o pedido. Un campo Char «Código de Proyecto» en sale.order permite imprimirlo en documentos y filtrarlo en informes sin integrar un módulo de proyectos completo.
3. Inventario: atributos específicos de producto
Además de los atributos estándar, fabricantes o distribuidores añaden campos como «Meses de garantía» (Integer), «Norma de certificación» (Selección) o «País de origen» (Many2one a res.country) para reflejar especificaciones técnicas en la ficha de producto e informes de stock.
4. Contabilidad: asignación por centro de coste o presupuesto
Los equipos financieros etiquetan facturas o asientos con centros de coste. Un Many2one en account.move hacia un modelo Cost Center permite una asignación detallada que ya es utilizable en filtros, pivots y exportaciones tras su creación.
5. RRHH: datos de onboarding a medida
Recursos Humanos recopilan datos específicos durante la incorporación —tipos de contrato locales, categorías internas de competencias o asignación de vehículo—. Mantener esos campos en hr.employee evita hojas de cálculo externas y facilita búsquedas e informes.
Crear o personalizar el campo
Hay dos vías principales para crear campos personalizados; la elección depende de recursos técnicos y complejidad requerida.
Opción 1: Odoo Studio (sin código)
Odoo Studio es la vía más rápida para usuarios de negocio: permite añadir campos sin desarrollar, directamente desde la interfaz.
- Abre la aplicación y el tipo de registro donde quieras añadir el campo (por ejemplo, el formulario de pedido de venta).
- Entra en el modo edición pulsando el icono del lápiz para activar Studio.
- Arrastra el tipo de campo desde el panel lateral hasta la posición deseada del formulario.
- Configura la etiqueta, el nombre técnico y las propiedades adicionales del campo.
- Guarda y sal del modo Studio.
Studio crea la entrada en ir.model.fields con el prefijo x_studio_ y la incorpora a la vista sin necesidad de desplegar ni reiniciar el servidor, siendo ideal para campos sencillos sin lógica compleja.
Opción 2: personalización técnica vía API o módulo
Para proyectos de personalización, los campos pueden crearse programáticamente mediante XML-RPC o mediante un módulo Python. Esta vía es apropiada si necesitas campos computados, dominios complejos o llevar los cambios en control de versiones.
Con la API es posible crear campos personalizados en scripts de despliegue; el ejemplo siguiente muestra cómo crear una selección en sale.order.
El flujo típico con la API consiste en localizar el id del modelo y luego crear el registro en ir.model.fields indicando nombre, etiqueta, modelo destino, tipo y opciones; el campo queda con state = 'manual'.
Esta técnica forma parte del trabajo habitual de los desarrolladores Odoo para añadir campos sin tocar archivos fuente y es útil en configuraciones remotas o automatizadas.
Si optas por un módulo Python, defines los campos en la clase del modelo y los cargas mediante el mecanismo estándar de módulos, lo que facilita mantenimiento y compatibilidad con actualizaciones.
Añadir el campo a una vista
Crear la columna no garantiza su visibilidad: debes incluir el campo en el formulario o en la vista de lista. Con Studio se hace al mismo tiempo; con personalización técnica debes modificar la vista XML o heredarla para insertar el campo en la posición adecuada.
Buenas prácticas
Crear campos es sencillo, pero una arquitectura de campos mal planificada complica mucho el mantenimiento. Estas prácticas te ayudan a conservar el orden.
Usa selección en vez de texto libre siempre que puedas
Si los valores posibles son finitos, una selección evita entradas inconsistentes ("Cliente", "cliente", "CLI") y protege filtros e informes. Un desplegable asegura uniformidad sin coste adicional.
Nombra los campos de forma clara y coherente
El nombre técnico (por ejemplo x_project_type) debe describir la finalidad del campo. Evita nombres genéricos como x_field_1 que resultan ininteligibles meses después; sigue una convención y documenta el propósito.
No sobrecargues modelos nativos
Si añades muchos campos a un modelo estándar, quizá lo apropiado sea crear un modelo propio que agrupe esos atributos y enlazarlo con un Many2one. Cuando los campos representan una entidad lógica distinta (proyecto, contrato, certificación), conviene modelarlo separadamente.
Prueba siempre en una base de datos de staging
Antes de tocar producción, prueba en una copia del entorno. Aunque añadir campos suele ser seguro, un campo en el modelo equivocado o con tipo erróneo puede necesitar limpieza manual; el staging detecta estos errores a tiempo.
Documenta tus campos personalizados
Lleva un registro con modelo, nombre técnico, propósito y solicitante. Con el tiempo una implantación acumula campos y sin documentación es imposible saber cuáles están en uso o pueden eliminarse.
Usa la herramienta adecuada para lógica calculada
Si un valor depende de otros campos, mejor un campo computado que pedir su relleno manual. Evitarás inconsistencias y errores de entrada; los campos computados son funcionalidad nativa bien soportada por Odoo desde Python.
Errores frecuentes
Incluso equipos expertos tropiezan con problemas repetidos al gestionar campos personalizados. Estos son los más habituales.
Olvidar el One2many al crear un Many2one
Error muy común: si pones un Many2one en el modelo A hacia el B sin crear el One2many inverso en B, la navegación desde B a A queda rota y los usuarios no verán los registros relacionados desde la otra parte. Crea ambas relaciones conjuntamente.
Borrar un campo que contiene datos
Eliminar un campo borra la columna y todos sus datos en la base; no hay deshacer. Si existe la posibilidad de necesitar la información en el futuro, mejor ocultarlo o archivarlo en lugar de suprimirlo.
Crear campos directamente en producción
Hacer cambios en la base de datos productiva sin pasar por pruebas es arriesgado: una mala configuración de vista puede producir errores de usuario. Valida siempre en un entorno de pruebas antes de aplicar en producción.
Conflictos de nombres con campos estándar
Odoo impide crear un nombre ya existente, pero es fácil crear un campo que solape con uno que aporte un módulo instalado más adelante. Usar un prefijo de empresa (por ejemplo x_miempresa_) minimiza ese riesgo.
Añadir campos a la vista sin pensar en la experiencia de usuario
Que un campo pueda añadirse no significa que deba mostrarse por defecto. Formularios recargados ralentizan a los usuarios. Si un campo solo se usa en contextos concretos, colócalo en una pestaña o muéstralo condicionalmente con dominios de visibilidad.
Mezclar campos Studio y campos técnicos sin criterio
Si combinas personalizaciones vía Studio y por código sin una estrategia clara, puedes acabar con campos redundantes o nombres en conflicto. Acuerda desde el inicio: Studio para cambios sin lógica y código para todo lo complejo; mezclar sin plan complica el mantenimiento.
Conclusión
Los campos personalizados son una de las formas más sencillas y efectivas de adaptar Odoo a tu negocio: no requieren tocar el código fuente, encajan con la plataforma y permiten capturar datos precisos sin soluciones externas.
La clave es planificar antes de crear: elige el tipo adecuado, nombra los campos con claridad, respeta las convenciones relacionales y documenta las decisiones. Una arquitectura de campos bien diseñada facilita el mantenimiento y la evolución de tu Odoo a medida que la empresa crece.
Ya uses Odoo Studio para cambios rápidos sin código o módulos Python dentro de un proyecto de personalización, los principios son los mismos: adapta el campo al dato, mantiene el modelo limpio y prueba antes de desplegar en producción.
En Dasolo ayudamos a empresas a implantar, personalizar y optimizar Odoo para que refleje sus procesos reales. Desde añadir unos pocos campos personalizados hasta desarrollar módulos a medida, ofrecemos soporte en todo el ciclo de implementación.
Contacta con nosotros si necesitas orientación sobre tu implantación de Odoo. Revisamos tu configuración actual y proponemos la ruta más limpia y sostenible para avanzar.