Introducción
El campo Monetary en Odoo es, a primera vista, un número más, pero su comportamiento está pensado específicamente para manejar dinero: formato, monedas y redondeos. Mucha gente lo confunde con un Float y eso provoca fallos en informes y cálculos financieros; comprender su naturaleza evita problemas posteriores.
Si has consultado el total de una orden de venta, el importe de una factura o el precio de un producto en Odoo, ya te has topado con este tipo de campo. Aparecen en multitud de modelos y se encargan, sin que el usuario lo note, de mostrar símbolos de moneda, separar decimales y aplicar las reglas de redondeo definidas para cada divisa.
Esta guía está pensada para desarrolladores Odoo, consultores y usuarios técnicos que quieran entender el comportamiento real del campo Monetary. Ya sea que estés aprendiendo campos en Odoo, desarrollando un módulo o investigando por qué tus importes no coinciden, aquí encontrarás la referencia práctica que necesitas.
¿Qué es el campo Monetario en Odoo?
El tipo fields.Monetary es un tipo nativo del framework Odoo creado para almacenar valores monetarios: precios unitarios, importes de factura, totales, presupuestos y en general cualquier cifra que represente dinero.
Lo que lo diferencia de un Float normal es su vínculo obligatorio con una moneda. Cada campo Monetary sabe en qué divisa trabaja y usa esa información para decidir cuántos decimales mostrar y cómo redondear el valor que almacena.
Cómo se muestra en la interfaz
En la interfaz de Odoo, un campo Monetary se presenta con el formato de la divisa asociada: por ejemplo, si la moneda es el euro verás algo como € 1.234,50, y si es dólar estadounidense $ 1,234.50. Los lugares decimales y el símbolo siguen la configuración del registro de moneda.
El campo es editable en vistas de formulario, se ve limpio en listas y funciona correctamente en pivots e informes. El usuario final no tiene que preocuparse por el formato: Odoo aplica la presentación adecuada automáticamente.
Tipo de dato subyacente
En la base de datos, un Monetary se guarda como float de doble precisión en PostgreSQL. La moneda no se almacena en la misma columna del importe: se referencia mediante un Many2one a res.currency ubicado en otro campo del mismo modelo.
Esta separación entre valor y moneda es intencionada: mantiene las columnas limpias y permite cambiar la divisa de un registro sin tocar la cifra almacenada en la columna numérica.
Cómo funciona el campo
Entender estas reglas internas te ayudará a evitar problemas de redondeo y visualización que surgen con frecuencia en desarrollos personalizados de Odoo.
El parámetro currency_field
Cada campo Monetary debe asociarse a un Many2one que apunte a res.currency. Por defecto Odoo busca un campo llamado currency_id en el modelo, pero puedes indicar otra referencia con el parámetro currency_field:
amount = fields.Monetary(string='Amount', currency_field='currency_id')Si falta la referencia de moneda en un registro, Odoo utiliza por defecto la moneda de la compañía. Eso evita errores críticos, pero en entornos multi-divisa puede generar un formato erróneo. Declara siempre explícitamente el campo de moneda para evitar comportamientos silenciosos.
Redondeo y precisión
A diferencia de un Float, Monetary respeta las reglas de la divisa definidas en res.currency: número de decimales y factor de redondeo. Al leer o mostrar un Monetary, Odoo aplica esas reglas automáticamente.
Por ejemplo, un valor almacenado como 1.2349999 en un campo ligado a EUR se mostrará según las reglas de la moneda, lo que puede dar lugar a 1,23 en pantalla. Esto es crítico en impuestos, totales de factura y conciliaciones: usar Float en esos contextos termina generando discrepancias difíciles de depurar.
Interacción con el ORM de Odoo
Al acceder a un Monetary desde Python, el ORM devuelve un float de Python. La moneda relevante procede del campo Many2one emparejado en el mismo registro. Para cálculos, aplica el método de redondeo de la moneda para mantener la precisión:
rounded_value = self.currency_id.round(self.amount)Esto evita que los errores de punto flotante se acumulen en totales de varias líneas o en cálculos iterativos.
Campos Monetary en informes QWeb
En plantillas QWeb existe un widget específico para formatear Monetary en PDFs y reportes web:
<span t-esc="record.amount"
t-options='{"widget": "monetary", "display_currency": record.currency_id}'/>De este modo el símbolo de la moneda y los decimales son correctos en cualquier documento generado, independientemente de la divisa del registro.
Casos reales de uso en la empresa
Dónde aparecen en los módulos estándar — ejemplos prácticos
1. Ventas: precios y totales de pedido
Campos como price_unit, price_subtotal o amount_total en pedidos y líneas son Monetary. Respetan la moneda del pedido del cliente, que puede ser distinta de la moneda contable de la empresa.
Por eso, si un comercial crea un pedido en USD para una empresa que opera en EUR, la visualización, el redondeo y la conversión se manejan correctamente: cada campo se interpreta en el contexto de su divisa.
2. Contabilidad: importes de facturas y líneas de impuesto
En contabilidad, todas las columnas de importe en una factura son Monetary: amount_untaxed, amount_tax, amount_total. La moneda de la factura determina el redondeo de esos importes.
Esto no es secundario: un redondeo incorrecto en las líneas de impuesto provoca asientos desequilibrados difíciles de reconciliar. El redondeo consciente de la moneda evita esos problemas desde la fuente de datos.
3. CRM: ingresos esperados en oportunidades
El campo expected_revenue en una oportunidad es Monetary. Los equipos comerciales capturan valores en la moneda del prospecto y, luego, los cuadros de mando pueden convertir todo a la moneda de la empresa para análisis y previsiones.
Este comportamiento funciona precisamente porque los Monetary llevan asociada la información de la moneda junto al número.
4. Compras: precios de proveedor y pedidos de compra
Los pedidos de compra utilizan Monetary para precios unitarios y totales, vinculados a la moneda acordada con el proveedor. Una factura de proveedor en yenes se maneja igual que una en euros: el campo se ocupa de la precisión y presentación sin intervención manual del equipo de compras.
5. Campos personalizados: presupuestos y objetivos
Es habitual que pidan añadir un importe de presupuesto, objetivo de ingresos o techo de gasto en proyectos, departamentos o modelos personalizados. En todos esos casos, un campo Monetary es la opción correcta: se integra con la moneda de la empresa y se muestra coherentemente en formularios, listados e informes.
Usar un Float en estas situaciones es posible, pero provoca inconsistencias de formato y problemas de redondeo cuando aparecen escenarios multi-divisa.
Crear o personalizar el campo
Maneras de añadir un campo Monetary: Studio o desarrollo
Hay dos rutas principales para añadir un Monetary a un modelo: Odoo Studio (sin código) o un módulo Python para control total.
Uso de Odoo Studio
Studio incluye un tipo Monetary en su panel de creación de campos. Si añades ese campo, Studio crea automáticamente un campo currency_id si no existe en el modelo. Los campos creados por Studio llevan el prefijo x_ (por ejemplo, x_studio_budget). Si tu modelo ya tiene currency_id, el nuevo Monetary lo reutilizará; si no, Studio generará uno nuevo. Cuando existan varios Monetary en el mismo modelo con posibles monedas distintas, conviene revisar la configuración del campo de moneda compartido antes de lanzar el sistema en producción.
Para escenarios sencillos, Studio es la forma más rápida para usuarios sin acceso a desarrollo.
Enfoque técnico: campos en Python
En un módulo personalizado, debes declarar el campo Monetary y su campo currency asociado. Este patrón es el estándar en desarrollo Odoo con Python:
from odoo import fields, models
class ProjectTask(models.Model):
_inherit = 'project.task'
x_budget = fields.Monetary(
string='Budget',
currency_field='x_budget_currency_id',
)
x_budget_currency_id = fields.Many2one(
comodel_name='res.currency',
string='Budget Currency',
default=lambda self: self.env.company.currency_id,
)Poner como valor por defecto la moneda de la compañía es una práctica habitual para campos internos: evita que la moneda aparezca vacía al crear un nuevo registro y garantiza el formato desde el inicio.
Campos Monetary computados
Los Monetary funcionan bien como campos calculados. Si necesitas sumar líneas o aplicar una fórmula que devuelva un importe, declara el campo como Monetary y usa un método compute:
x_total_budget = fields.Monetary(
string='Total Budget',
currency_field='currency_id',
compute='_compute_total_budget',
store=True,
)
@api.depends('x_line_ids.x_amount')
def _compute_total_budget(self):
for record in self:
record.x_total_budget = sum(record.x_line_ids.mapped('x_amount'))El atributo store=True es clave si vas a filtrar, ordenar o agregar por ese campo en vistas de lista o en informes: los campos computados no almacenados no pueden usarse en dominios del ORM ni en vistas SQL.
Crear un Monetary vía API
Si necesitas crear campos de forma programática mediante XML-RPC (por ejemplo, en un script de configuración remota), puedes crear el campo a través de ir.model.fields:
models.execute_kw(ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_budget',
'field_description': 'Budget',
'model_id': model_id,
'ttype': 'monetary',
'currency_field': 'currency_id',
'state': 'manual',
}]
)Esta técnica forma parte del conjunto de herramientas de personalización de Odoo accesible por API XML-RPC y suele utilizarse en procesos de despliegue automatizado.
Buenas prácticas
Resumen de buenas prácticas
1. Nunca uses Float para valores financieros
Regla de oro: si el dato representa dinero—precio, importe, total, presupuesto—usa fields.Monetary. Un Float no tiene noción de moneda ni aplica redondeos específicos por divisa, lo que termina generando errores en contextos multi-moneda.
2. Declara siempre el campo de moneda explícitamente
No confíes en el fallback automático a currency_id a menos que ese campo exista y esté correctamente definido. Declara currency_field y crea la Many2one a res.currency para evitar comportamientos inesperados.
3. Establece una moneda por defecto
Para campos internos que casi siempre usarán la moneda de la compañía, define un default=lambda self: self.env.company.currency_id. Evita que el campo aparezca sin moneda en la creación de registros.
4. Usa store=True en campos computados que necesites buscar
Si un campo Monetary computado debe servir para filtros, ordenaciones o agregaciones, asegúrate de almacenarlo con store=True. Los campos no almacenados no funcionan en dominios ni en vistas que requieren SQL.
5. Aplica currency.round() en cálculos intermedios
Al realizar operaciones aritméticas en Python sobre importes monetarios, aplica self.currency_id.round(value) en pasos relevantes, no sólo al final. Así evitas que los errores de coma flotante se acumulen y se traduzcan en diferencias en los totales.
6. Sé deliberado en informes multi-moneda
Al agregar valores Monetary de registros con distintas divisas, no sumes los números crudos. Convierte primero todo a una misma moneda mediante res.currency.compute() o diseña el informe por moneda. Mezclar divisas en una suma produce cifras técnicamente correctas por campo pero sin significado financiero.
Errores comunes
Errores frecuentes y cómo prevenirlos
Fallo 1: falta del campo de moneda
El error más habitual al añadir un Monetary es olvidar declarar el Many2one de moneda. Si currency_id no existe, Odoo puede caer en uso silencioso de la moneda de la compañía o lanzar errores según el contexto. Crea siempre la referencia de moneda junto al campo Monetary.
Fallo 2: compartir un campo de moneda entre Monetaries que deberían usar divisas distintas
Si tienes dos Monetary en el mismo modelo pensados para diferentes divisas (por ejemplo, precio cliente en EUR y coste proveedor en USD), no compartas un único currency_id. Cada Monetary necesita su propia referencia; compartirla provocará que una moneda sobreescriba a la otra y genere datos inconsistentes.
Fallo 3: discrepancias al agregar entre monedas
Sumar campos Monetary de registros con diferentes divisas produce totales erróneos a nivel empresarial, porque se están mezclando unidades distintas. Normaliza todas las cifras a una moneda común antes de agregar.
Fallo 4: comparaciones exactas con floats en búsquedas ORM
Buscar por igualdad exacta en un Monetary (por ejemplo, amount = 10.0) puede no devolver resultados por cómo se almacenan los floats. Usa rangos (>= y <= con tolerancia) o aplica el redondeo de moneda antes de comparar en lógica Python.
Fallo 5: ignorar el redondeo de moneda en importaciones
Al importar CSV o datos via XML-RPC, los valores Monetary se guardan tal cual llegan. Si los datos de origen tienen más decimales que la moneda destino, verás discrepancias en pantalla y pequeñas diferencias en totales. Redondea las cifras en los scripts de importación según la moneda antes de enviarlas a Odoo.
Conclusión
El campo Monetary parece sencillo pero encapsula comportamientos críticos para la gestión financiera: redondeos correctos, formato consistente y consciencia de la divisa en toda la interfaz y el motor de informes.
Usarlo adecuadamente —siempre enlazado a un campo de moneda explícito y sin sustituirlo por un Float— te evitará una categoría de errores sutiles y costosos de depurar en producción. El modelo de datos de Odoo está diseñado alrededor de este tipo por una buena razón.
Tanto si sigues una guía para desarrolladores, personalizas un módulo estándar o creas algo desde cero, definir correctamente tus campos Monetary es una decisión fundamental que condiciona la fiabilidad del sistema para manejar dinero.
¿Necesitas ayuda con tu implantación de Odoo?
En Dasolo acompañamos a empresas en la implantación, personalización y optimización de Odoo en proyectos de cualquier tamaño. Si necesitas limpiar tu modelo de datos, diseñar una estrategia de campos, soportar múltiples monedas o ejecutar un despliegue completo, contamos con el equipo funcional y técnico para hacerlo bien.
Si tienes dudas sobre campos Monetary o cualquier otro aspecto de tu implantación de Odoo, podemos ayudarte. Contacta con nosotros y hablemos sobre lo que estás construyendo.