Introducción
En Odoo, los modelos determinan cómo se organiza y guarda la información en la base de datos. Cada pieza de datos de la actividad —pedidos, facturas, asientos contables— vive dentro de un modelo concreto que define su estructura y reglas.
Tener claro qué son los modelos es imprescindible tanto para desarrolladores como para consultores funcionales. Son la columna vertebral de la arquitectura de datos: definen campos, relaciones y la lógica que aplica sobre la información.
Esta guía se centra en uno de los modelos más relevantes para la contabilidad en Odoo: account.move. Si creas informes personalizados, conectas sistemas externos o diseñas procesos de facturación, acabarás tratando con él.
¿Qué es el modelo account.move?
El modelo account.move representa los asientos o movimientos contables. A partir de Odoo 13 se consolidaron en él lo que antes eran modelos separados —facturas de clientes, facturas de proveedor, notas de abono y asientos manuales— y hoy conviven en una única entidad.
Dentro del módulo de Contabilidad, account.move actúa como padre de account.move.line, que contiene las líneas de débito y crédito. Cada factura, factura de proveedor o asiento es un registro account.move con una o varias líneas asociadas.
El núcleo del modelo está en el módulo account, y otros módulos lo amplían mediante la herencia de modelos. Por ejemplo, Ventas añade la creación de facturas desde pedidos y Compras añade la generación de facturas desde órdenes de compra, sin duplicar la estructura principal.
Campos clave del modelo
A continuación se describen los campos más importantes del modelo account.move. Conocerlos facilita trabajar con facturas, proveedores y asientos y evita sorpresas al integrar o reportar.
1. name
Tipo: Char. Identifica el número o nombre del asiento/factura. Normalmente se genera automáticamente según la secuencia del diario y es el identificador visible en listados y documentos impresos.
2. move_type
Tipo: Selection. Indica la clase de movimiento: entry (asiento manual), out_invoice (factura cliente), out_refund (nota de abono cliente), in_invoice (factura proveedor), in_refund (nota de abono proveedor). Determina vistas, validaciones y comportamientos asociados.
3. state
Tipo: Selection. Estado del flujo: draft, posted, cancel. En draft se pueden editar; en posted el asiento está bloqueado y afecta al mayor; cancel revierte o anula su efecto.
4. date
Tipo: Date. Fecha del documento. Es relevante para informes, antigüedad y cierres; en facturas suele coincidir con la fecha de emisión.
5. journal_id
Tipo: Many2one (account.journal). Diario asociado al movimiento: ventas, compras, bancos, varios. El diario define la secuencia, cuentas por defecto y reglas contables.
6. company_id
Tipo: Many2one (res.company). En entornos multiempresa identifica la compañía propietaria del movimiento y afecta a visibilidad y consolidación.
7. partner_id
Tipo: Many2one (res.partner). Cliente o proveedor relacionado. Es obligatorio en facturas y se usa en conciliaciones, informes de antigüedad y encabezados de documentos.
8. currency_id
Tipo: Many2one (res.currency). Moneda del movimiento. Los importes se almacenan en esa divisa; para reporting en moneda de compañía se aplican conversiones.
9. amount_total
Tipo: Monetary. Importe total del movimiento. En facturas representa el total a pagar y se calcula a partir de las líneas.
10. amount_residual
Tipo: Monetary. Saldo pendiente. En facturas pagadas suele ser cero. Se emplea en antigüedad y procesos de pago.
11. payment_state
Tipo: Selection. Estado de pago: not_paid, in_payment, paid, partial, reversed, invoicing_legacy. Condiciona recordatorios y reportes de cobros/pagos.
12. line_ids
Tipo: One2many (account.move.line). Líneas del asiento. Cada línea apunta a una cuenta y contiene débitos y créditos; la suma de débitos debe igualar la de créditos.
13. invoice_line_ids
Tipo: One2many (account.move.line). En facturas y facturas de proveedor son las líneas de producto o servicio. Al registrar el asiento, cada línea de factura genera una o varias líneas contables.
14. invoice_date
Tipo: Date. Fecha de la factura, importante para periodos fiscales y declaraciones; en algunas configuraciones puede diferir de la fecha del asiento.
15. invoice_date_due
Tipo: Date. Fecha de vencimiento del pago. Se calcula desde las condiciones de pago o se establece manualmente; clave para la gestión de vencimientos y morosidad.
16. ref
Tipo: Char. Referencia externa, por ejemplo número de factura del proveedor. Útil para conciliaciones y comparar con documentos externos.
17. invoice_origin
Tipo: Char. Documento origen (por ejemplo, número de pedido). Facilita la trazabilidad desde el pedido hasta la factura.
18. create_date
Tipo: Datetime. Fecha y hora de creación del registro. Gestionado automáticamente por Odoo.
19. write_date
Tipo: Datetime. Fecha y hora de la última modificación. También gestionado por el sistema.
20. narration
Tipo: Text. Notas internas o comentario del asiento. Aparece en asientos impresos pero normalmente no se muestra al cliente en la factura.
21. fiscal_position_id
Tipo: Many2one (account.fiscal.position). Posición fiscal que determina las reglas de impuestos aplicables según partner y país.
22. invoice_payment_term_id
Tipo: Many2one (account.payment.term). Condiciones de pago (por ejemplo, 30 días). Se utiliza para calcular fecha de vencimiento y dividir pagos en plazos.
23. invoice_user_id
Tipo: Many2one (res.users). Usuario responsable o comercial asociado a la factura. Interviene en comisiones y análisis de ventas.
24. reversed_entry_id
Tipo: Many2one (account.move). En asientos de reversión enlaza con el movimiento original para mantener la trazabilidad de la corrección.
25. to_check
Tipo: Boolean. Indicador para marcar asientos que necesitan revisión. Suele utilizarse en conciliación bancaria y flujos de excepciones.
26. active
Tipo: Boolean. Indicador de archivo (soft delete). Si es False el registro queda archivado; habitualmente los movimientos cancelados se inactivan.
27. sequence_number
Tipo: Integer. Número de secuencia del diario; se usa para ordenar y mostrar registros y lo gestiona la mezcla de secuencias (sequence mixin).
28. amount_untaxed
Tipo: Monetary. Importe neto antes de impuestos. En facturas, suma de las líneas sin impuestos aplicados.
29. amount_tax
Tipo: Monetary. Total de impuestos calculados a partir de las líneas y la configuración fiscal.
30. invoice_source_email
Tipo: Char. Dirección de correo origen cuando una factura de proveedor se crea desde email; útil en procesos de ingestión automática de facturas.
Cómo se utiliza este modelo en los procesos de negocio
1. Facturación a clientes
Al entregar un pedido de venta, Odoo genera un account.move con move_type out_invoice. Las invoice_line_ids proceden de las líneas del pedido; al validar la factura se crean las líneas contables y se actualizan las cuentas a cobrar.
2. Facturas de proveedor
Las órdenes de compra pueden generar facturas o estas pueden introducirse manualmente. Cada factura de proveedor es un account.move con move_type in_invoice y, al validar, actualiza las cuentas a pagar del proveedor indicado en partner_id.
3. Conciliación de pagos
Los pagos se emparejan con facturas utilizando amount_residual y payment_state. La conciliación vincula los movimientos de pago con las facturas y borra o ajusta los saldos pendientes.
4. Asientos manuales
Los contables crean moves con move_type entry para ajustes, provisiones o correcciones, añadiendo manualmente line_ids con cuentas, débitos y créditos. Antes de publicar, el asiento debe cuadrar.
5. Notas de abono y devoluciones
Las notas de abono usan move_type out_refund o in_refund y revierten el efecto de la factura original; reversed_entry_id enlaza con la factura origen para auditoría y trazabilidad.
Cómo lo amplían los desarrolladores
Los desarrolladores amplían account.move mediante varios patrones, siendo la herencia de modelos de Odoo el mecanismo más habitual.
Herencia de modelo
Usa _inherit = 'account.move' para extender el modelo: añadir campos, sobreescribir métodos o añadir restricciones. Mantener la lógica en módulos separados facilita futuras actualizaciones y compatibilidad.
Añadir campos
Declara nuevos campos en tu modelo heredado usando el tipo adecuado: Char, Many2one, Boolean, Integer, Text, Selection. Piensa en campos dependientes de compañía en entornos multiempresa y aplica dominios en move_type si el campo sólo tiene sentido para facturas.
Extensiones en Python
Sobrescribe create, write, _post o button_draft para introducir lógica adicional y recuerda llamar a super(). Atiende a las dependencias de campos computados y usa los decoradores del API (@api.model, @api.depends) para controlar cuándo se ejecutan los métodos.
Odoo Studio
Odoo Studio permite añadir campos y ajustes sin programar, útil para cambios rápidos o campos de referencia. Para lógica compleja, validaciones o automatizaciones intensas, un módulo personalizado resulta más sostenible a largo plazo.
Importante: account.move es un modelo persistente que crea tablas en la base de datos; no es un modelo abstracto ni transitorio. Los modelos abstractos sirven como plantilla y los transitorios para asistentes; account.move guarda datos contables permanentes.
Buenas prácticas
- Al generar informes o integraciones, filtra siempre por move_type: cada tipo exige campos y comportamientos distintos y mezclarlos puede dar lugar a errores en los datos.
- Asigna el diario correcto a cada tipo de movimiento. Utilizar diarios inadecuados rompe secuencias y complica el reporting contable.
- Si creas asientos desde la API, asegúrate de que las line_ids cuadren (débitos = créditos) antes de publicar; los asientos desequilibrados serán rechazados.
- Al importar facturas desde sistemas externos, mapea correctamente los tipos de documento a move_type: out_invoice para ventas y in_invoice para compras, por ejemplo.
- Para campos personalizados usa el prefijo x_ para minimizar conflictos con futuras versiones de Odoo.
Errores habituales
- Publicar asientos sin cuadrar. Odoo rechazará la publicación; siempre verifica que débitos y créditos coinciden.
- Modificar directamente asientos publicados. Una vez posteados están bloqueados; en su lugar, crea una reversión o un asiento corrector.
- No asignar partner_id en movimientos de clientes o proveedores. Muchas funciones y reportes dependen de esta asociación.
- Usar un move_type incorrecto. Una out_refund no equivale a una out_invoice negativa: emplea el tipo adecuado para devoluciones y notas de crédito.
- Sobrescribir métodos core sin llamar a super(). Esto puede romper módulos dependientes y complicar upgrades futuros.
Conclusión
El modelo account.move es el eje de la contabilidad en Odoo, unificando facturas, facturas de proveedor y asientos en una estructura común. Comprender sus campos y cómo se extiende te permitirá configurar, personalizar e integrar Odoo con seguridad.
Tanto si diseñas procesos como consultor funcional como si desarrollas módulos, dominar account.move te ahorrará tiempo y reducirá errores operativos y técnicos.
¿Necesitas ayuda con tu proyecto Odoo?
Dasolo acompaña a empresas en la implantación, personalización y optimización de Odoo. Somos especialistas en integraciones por API y desarrollo a medida, con amplia experiencia en arquitectura de datos y modelos como account.move.
Si necesitas apoyo con implantaciones, módulos personalizados o integraciones, podemos ayudarte. Solicita una demo para comentar tu proyecto.