Introducción
Si alguna vez has intentado guardar un formulario en Odoo y un campo se te ha iluminado en rojo, ya conoces el comportamiento de los campos obligatorios. Es una herramienta básica del modelo de datos que impide que se registren procesos con información incompleta y, por tanto, es clave para mantener la calidad de los datos en los flujos de trabajo.
Tanto si configuras Odoo para un equipo comercial, como si diseñas un modelo a medida o trabajas en un proyecto técnico, saber cómo funciona la propiedad required te permite construir procesos más sólidos y predecibles.
Esta guía explica lo esencial: cómo se comporta el campo en el framework de Odoo, las formas de configurarlo desde Studio o código Python, cuándo conviene usarlo y los errores habituales que conviene evitar.
¿Qué significa que un campo sea obligatorio en Odoo?
En Odoo, la etiqueta required es una restricción a nivel de campo que impide guardar un registro si ese campo está vacío. Se puede aplicar a casi cualquier tipo de campo: texto, números, selecciones, many2one, fechas, etc.
Forma parte del núcleo del modelo de datos de Odoo y suele ser la primera línea de defensa para evitar registros incompletos o inconsistentes durante la personalización del sistema.
Cómo se muestra en la interfaz
En la interfaz de Odoo los campos obligatorios se distinguen visualmente de los opcionales. Mientras el formulario está en edición, esos campos suelen mostrar un indicador sutil y, si intentas guardar sin rellenarlos, el sistema los marca en rojo y muestra un mensaje de validación.
Este feedback inmediato es consistente en la interfaz web y ayuda a los usuarios a corregir errores al momento, reduciendo la probabilidad de almacenar registros incompletos.
Obligatorio estático frente a obligatorio dinámico
Existen dos formas de obligar un campo: de forma estática, donde el campo siempre debe tener un valor, y de forma dinámica, en la que la obligatoriedad depende de condiciones (otros campos del mismo registro, etapa del proceso, etc.).
Ambas soluciones se usan con frecuencia; la elección depende de la lógica de negocio y de la experiencia de usuario que quieras ofrecer.
Cómo funciona el mecanismo
Comprender el funcionamiento técnico del atributo required te ayudará a aplicarlo correctamente y a resolver problemas cuando surjan.
Validación en la capa de aplicación
Un detalle importante que sorprende a muchos: la validación del atributo required se realiza en la capa de aplicación, no en la base de datos. Es la ORM de Odoo la que comprueba la condición cuando se crea o se actualiza un registro.
Por defecto no se añade un constraint NOT NULL al campo de PostgreSQL al marcar required=True. La comprobación sucede en Python, dentro de la capa ORM de Odoo.
En la práctica, esto significa que si se insertan datos directamente en la base de datos, saltándose Odoo, la restricción no los bloqueará. Por eso siempre debes interactuar con los campos a través del ORM o la API para mantener la protección.
Qué ocurre cuando se viola la restricción
Al intentar guardar un formulario con un campo obligatorio vacío suceden dos cosas:
- El campo se muestra en rojo en la interfaz y Odoo muestra un mensaje de validación.
- La operación de guardado queda bloqueada hasta que se rellene el campo.
Si la validación se activa programáticamente (por ejemplo vía XML-RPC o una acción de servidor), Odoo lanza un ValidationError indicando qué campo requerido falta.
Requerir de forma dinámica mediante dominios
En Odoo es posible condicionar la obligatoriedad desde la vista. En versiones hasta la 16 esto se hacía con attrs en el XML de la vista:
<field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />En Odoo 17 y posteriores la sintaxis se simplifica permitiendo una expresión directa required en la etiqueta del campo:
<field name="x_delivery_date" required="order_type == 'delivery'" />Estas reglas condicionales residen en la capa de vista, no en el modelo: required=True en el modelo siempre obliga, mientras que las expresiones en la vista solo aplican en el contexto de esa interfaz concreta.
Interacción con el ORM y la API
Cuando llamas a create() o write() en un modelo, la ORM chequea todos los campos con required=True antes de ejecutar la operación en la base de datos. Si falta un campo marcado como obligatorio, se lanza un ValidationError.
Lo mismo ocurre al crear registros vía la API XML-RPC: cualquier campo requerido en la definición del modelo debe incluirse en el diccionario de datos, o la llamada fallará.
Casos prácticos en la empresa
Los campos obligatorios aparecen en muchos puntos de Odoo y también son útiles en configuraciones a medida. A continuación tienes cinco ejemplos prácticos donde marcar un campo como obligatorio mejora procesos reales.
1. CRM: segmento de cliente obligatorio en oportunidades
Si el equipo comercial necesita segmentar leads desde el primer contacto, dejar el campo de segmento opcional suele provocar que se omita, lo que dificulta después el análisis de origen o campañas.
Hacer obligatorio un campo de selección “Segmento de Cliente” en el formulario de leads garantiza que la información se capture en el origen: sin segmento, no hay guardado.
2. Ventas: dirección de entrega obligatoria en pedidos
Para empresas que envían productos físicos, la dirección de entrega es esencial. En algunas configuraciones de Odoo ese campo no viene obligatorio por defecto, lo que permite confirmar pedidos sin dirección.
Marcar la dirección de entrega como obligatoria evita que los pedidos se confirmen sin la información logística necesaria, reduciendo errores en el proceso de preparación y envío.
3. Almacén: lote o número de serie obligatorio en recepción
En sectores regulados (alimentación, farmacéutico, electrónica) el registro del lote o número de serie en las recepciones es imprescindible. Odoo lo facilita mediante la trazabilidad en productos, que obliga a indicar lote/serie durante los movimientos.
Para campos personalizados en el formulario de recepción, marcar como obligatorio referencias de control de calidad u otros datos evita que el equipo de almacén omita información crítica.
4. Contabilidad: centro de coste obligatorio en facturas de proveedor
Los equipos financieros suelen necesitar que cada gasto vaya asociado a un centro de coste para controlar presupuestos. Si ese dato no se exige, se crean huecos en la contabilidad analítica.
Un many2one obligatorio hacia el modelo de centros de coste en el formulario de factura de proveedor asegura que ninguna factura se contabilice sin esa asignación.
5. RRHH: tipo de contrato obligatorio antes de finalizar la incorporación
En onboarding, RRHH necesita que el tipo de contrato esté registrado antes de completar la ficha del empleado. Un campo obligatorio en el formulario evita guardar registros incompletos durante procesos intensos de alta.
Crear o personalizar campos obligatorios
Existen dos vías principales para marcar un campo como obligatorio en Odoo: Studio para evitar código o el enfoque técnico mediante Python. La elección depende del nivel de control que necesites.
Usando Odoo Studio
Odoo Studio permite configurar campos sin escribir código. Al abrir Studio y seleccionar un campo verás un interruptor “Obligatorio” en las propiedades del campo.
Activarlo marca el campo como requerido en la vista y almacena la configuración a nivel de modelo; es la manera más rápida para casos sencillos y sirve tanto para campos estándar como para campos personalizados creados desde Studio.
La limitación de Studio es que suele aplicar una obligatoriedad estática. Para reglas condicionales basadas en otros campos necesitarás editar la vista XML o usar la vía técnica.
Enfoque técnico: campos en Python
En un módulo personalizado de Odoo, declarar un campo obligatorio se hace añadiendo required=True en la definición del campo. Es la práctica estándar en desarrollo con Python:
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_customer_segment = fields.Selection(
selection=[
('smb', 'SMB'),
('enterprise', 'Enterprise'),
('public', 'Public Sector'),
],
string='Customer Segment',
required=True,
)
x_cost_center_id = fields.Many2one(
comodel_name='account.analytic.account',
string='Cost Center',
required=True,
)Con este enfoque la restricción se aplica en el modelo, por lo que es válida independientemente de la vista o la interfaz desde la cual se cree o edite el registro.
Obligatorio dinámico en el XML de la vista
Cuando la obligatoriedad solo debe aplicarse bajo ciertas condiciones, añádela en la vista en lugar de forzarla en el modelo. En Odoo 16 se hacía así:
<field name="x_cost_center_id"
attrs="{'required': [('order_type', '=', 'invoiced')]}" />En Odoo 17:
<field name="x_cost_center_id"
required="order_type == 'invoiced'" />Recuerda: esta es una restricción de vista. Tiene menos potencia que required a nivel de modelo porque solo se aplica cuando el registro se edita mediante la vista que contiene la definición.
Crear campos obligatorios vía API
Si automatizas la creación de campos mediante la API XML-RPC, también puedes marcar required al crear el registro en ir.model.fields. Es útil para despliegues automatizados:
models.execute_kw(ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_customer_segment',
'field_description': 'Customer Segment',
'model_id': model_id,
'ttype': 'selection',
'selection': "[('smb', 'SMB'), ('enterprise', 'Enterprise')]",
'required': True,
'state': 'manual',
}]
)Así creas el campo y aplicas la obligatoriedad en un mismo paso, algo útil en pipelines de despliegue que generan campos programáticamente.
Buenas prácticas
Marcar un campo como obligatorio es sencillo, pero usarlo bien requiere reflexión. Estas prácticas te evitarán dolores de cabeza y mejorarán la experiencia de los usuarios.
1. Obliga campos solo cuando realmente sean imprescindibles
Exigir demasiados campos es un error común. Si un usuario no puede terminar un formulario porque falta información que no está disponible en ese momento, tenderá a usar soluciones temporales (valores provisionales) que deterioran la calidad de los datos.
Antes de imponer obligatoriedad pregúntate: ¿esta información está siempre disponible al crear el registro? Si no, valora exigirla en una etapa posterior (por ejemplo, al confirmar) o implementarla de forma condicional.
2. Valida por etapas en lugar de obligarlo todo desde el inicio
En procesos con varias fases (oportunidades comerciales, órdenes de fabricación) suele ser mejor validar campos en puntos concretos del flujo en lugar de hacerlos obligatorios desde la creación. Esto se consigue con restricciones en Python o acciones automáticas al cambiar de etapa.
Este patrón resulta más flexible y cómodo para los usuarios que marcar todos los campos como obligatorios desde el primer paso.
3. Combina campos obligatorios con valores por defecto cuando tenga sentido
Si un campo obligatorio suele tener un valor predecible, establece un default en la definición. Así evitas fricciones para usuarios que no necesitan modificar ese valor y aseguras que el campo nunca quede vacío.
4. Prefiere required a nivel de modelo para datos críticos
Para información esencial (datos contables, identificadores regulatorios) aplica la obligatoriedad en Python a nivel de modelo. Las restricciones solo en la vista pueden ser eludidas por la API o por otras vistas que no incluyen la regla.
5. Comunica los cambios a los usuarios
Cuando añadás campos obligatorios a formularios existentes, informa al equipo antes del despliegue. Los usuarios que están en mitad de procesos pueden llevarse sorpresas si los registros actuales empiezan a fallar en la validación.
6. Prueba con datos vacíos y parciales
Antes de desplegar nuevos campos obligatorios, prueba todo el flujo con valores vacíos y datos parciales. Haz pruebas desde la interfaz web, vía API y con cualquier integración que cree registros en Odoo.
Errores frecuentes
Incluso los implementadores con experiencia se topan con problemas por la obligatoriedad. Conocer los puntos críticos te ahorrará tiempo y retrocesos dolorosos.
Error 1: hacer obligatorio un campo en un modelo con registros existentes
Si añades required=True a un campo en un modelo que ya contiene miles de registros vacíos, cuando se editen esos registros los usuarios se encontrarán con que no pueden guardar cambios hasta completar el nuevo campo.
Antes de imponer la restricción en un campo existente, comprueba si los registros ya tienen valores. Si no, ejecuta una migración de datos para rellenarlos previamente.
Error 2: confundir obligatoriedad en la vista y en el modelo
Marcar un campo como obligatorio en la vista (Studio o XML) no lo hace obligatorio a nivel de modelo. Un registro creado por API, por otra vista o mediante importación puede saltarse la restricción de la vista.
Si necesitas una regla inquebrantable, usa required=True en la definición Python; este malentendido es causa frecuente de problemas de calidad de datos en producción.
Error 3: campos obligatorios en acciones automáticas o programadas
Si una acción automática crea registros y no suministra valores para nuevos campos obligatorios, empezará a fallar tras desplegar la restricción. Fallos silenciosos o errores crípticos son habituales en estos escenarios.
Revisa todo el código que crea registros tras añadir un campo obligatorio en un modelo existente.
Error 4: importar datos sin los campos obligatorios
Al importar CSV u otros ficheros, la ausencia de campos obligatorios provoca que la importación falle. Es el comportamiento correcto, pero sorprende a quienes esperan poder importar datos parciales.
Incluye siempre los campos obligatorios en las plantillas de importación y documenta claramente qué campos son imprescindibles.
Error 5: usar required en vez de una comprobación en Python para reglas complejas
required solo comprueba que un campo no esté vacío; no valida contenido ni relaciones entre campos. Para comprobaciones complejas (fechas futuras, coherencia entre campos) usa @api.constrains en Python.
Intentar meter lógica de negocio compleja solo con campos obligatorios produce configuraciones rígidas y difíciles de mantener.
Resumen final
La etiqueta required es una de las herramientas más sencillas de Odoo, pero su impacto en la calidad de los datos es real. Bien usada, garantiza que la información crítica se capture en el momento adecuado; mal empleada, genera frustración y atajos que degradan la base de datos.
La clave es distinguir entre restricciones a nivel de modelo y de vista, ser intencionado sobre qué datos deben imponerse y anticipar cómo afectará a automatizaciones e integraciones.
Ya sea que sigas una guía de desarrollo, desarrolles una personalización completa o ajustes un formulario con Studio, comprender a fondo el atributo required te ayudará a evitar problemas a medio plazo.
¿Necesitas ayuda con tu implementación de Odoo?
En Dasolo acompañamos a empresas en la implantación, personalización y optimización de Odoo en todos los ámbitos. Si necesitas diseñar un modelo de datos robusto, configurar validaciones o desarrollar módulos a medida, aportamos experiencia técnica y funcional en cada proyecto.
Si tienes dudas sobre campos obligatorios u otros aspectos de tu configuración de Odoo, podemos ayudarte. Contacta con nosotros y cuéntanos qué necesitas construir.