Introducción
En Odoo, los modelos definen cómo se estructura y almacena la información en la base de datos. Cada pieza de datos empresariales con la que trabajas, desde órdenes de compra hasta facturas e inventarios, reside en un modelo.
Entender los modelos de Odoo es esencial tanto para desarrolladores como para consultores funcionales. Los modelos son la base de la arquitectura de datos de Odoo. Definen los campos, relaciones y lógica empresarial de Odoo.
Este artículo se centra en uno de los modelos más importantes en Odoo: purchase.order. Ya sea que estés construyendo módulos personalizados, integrando sistemas externos o configurando flujos de trabajo de aprovisionamiento, trabajarás con este modelo.
¿Qué es el modelo purchase.order?
El modelo purchase.order representa órdenes de compra y solicitudes de cotización (RFQs) en Odoo. Es el lugar central donde se capturan todas las transacciones de aprovisionamiento antes de que se conviertan en recibos o facturas de proveedores.
Este modelo en Odoo es utilizado por el módulo de Compras. Cuando un comprador crea una RFQ, crea un registro de purchase.order. Cuando el proveedor confirma o el comprador aprueba, la orden pasa de borrador a confirmada. El mismo modelo en Odoo contiene tanto RFQs en borrador como órdenes de compra confirmadas. El campo de estado rastrea el ciclo de vida.
Otros módulos extienden este modelo a través de la herencia de modelos de Odoo. Inventario añade lógica de recibo y picking. Contabilidad añade campos de facturas de proveedores. Manufactura puede crear órdenes de compra a partir de listas de materiales. Cada módulo añade lo que necesita sin duplicar la estructura central.
Campos clave en el modelo
Aquí están los campos más importantes de Odoo en el modelo purchase.order. Comprender estos te ayudará a trabajar de manera efectiva con las órdenes de compra.
1. name
Tipo: Char. Este campo almacena la referencia de la orden (por ejemplo, PO00042). Generalmente se genera automáticamente y se muestra en vistas de lista y en documentos. Es el identificador principal para la orden de compra.
2. state
Tipo: Selection. Rastrear el ciclo de vida de la orden. Valores: draft (RFQ), sent (enviado al proveedor), to approve (esperando aprobación), purchase (confirmado), done (totalmente recibido y facturado), cancel (cancelado). El estado determina qué acciones están disponibles.
3. partner_id
Tipo: Many2one (res.partner). El proveedor o suministrador. Requerido. Este es el contacto principal o la empresa para la orden. Se utiliza para toda la lógica y reportes relacionados con el proveedor.
4. partner_ref
Tipo: Char. La referencia del proveedor o número de orden del suministrador. Se utiliza cuando el proveedor proporciona su propia referencia de orden. Se muestra en documentos y ayuda a coincidir recibos y facturas.
5. date_order
Tipo: Fecha y hora. La fecha del pedido. Para pedidos en borrador: fecha de creación. Para pedidos confirmados: fecha de confirmación. Utilizado para informes, clasificación y como la fecha esperada predeterminada para las líneas de pedido.
6. date_approve
Tipo: Fecha y hora. La fecha de aprobación o confirmación. Se establece cuando el pedido pasa al estado de compra. Solo lectura. Utilizado para informes y auditorías.
7. order_line
Tipo: Uno a muchos (purchase.order.line). Las líneas del pedido. Cada línea contiene producto, cantidad, precio e impuesto. Este es el detalle principal del pedido de compra.
8. amount_untaxed
Tipo: Flotante. El subtotal antes de impuestos. Computado a partir de las líneas de pedido. Utilizado para informes y visualización.
9. amount_tax
Tipo: Flotante. El monto total de impuestos. Computado a partir de las líneas de pedido según la configuración de impuestos. Se muestra en el pedido y en la factura del proveedor.
10. amount_total
Tipo: Flotante. El monto total incluyendo impuestos. La cantidad principal para la facturación y los informes.
11. currency_id
Tipo: Many2one (res.currency). La moneda. Generalmente heredada de la empresa o proveedor. Todos los campos monetarios utilizan esta moneda.
12. origin
Tipo: Char. El documento fuente. Por ejemplo, cuando se crea un pedido a partir de un pedido de venta (dropship) o un pedido de fabricación, el nombre de origen se almacena aquí. Se utiliza para la trazabilidad.
13. dest_address_id
Tipo: Many2one (res.partner). La dirección de entrega. Si no se establece, por defecto se utiliza la dirección de la empresa. Se utiliza para el dropshipping cuando los bienes van directamente al cliente.
14. priority
Tipo: Selección. Prioridad del pedido: Normal o Urgente. Se utiliza para ordenar y resaltar. Los pedidos urgentes pueden recibir un tratamiento especial en los flujos de trabajo.
15. invoice_status
Tipo: Selección. Rastrea la facturación: no (no facturado), a facturar (listo para facturar), facturado (totalmente facturado). Controla la visibilidad de la acción Crear Factura.
16. invoice_count
Tipo: Entero. Número de facturas de proveedor relacionadas. Computado. Se utiliza para mostrar y abrir la lista de facturas.
17. invoice_ids
Tipo: One2many (account.move). Las facturas de proveedor relacionadas. Vincula órdenes de compra a la contabilidad. Utilizado para la conciliación de tres vías y el seguimiento de pagos.
18. picking_ids
Tipo: One2many (stock.picking). Las órdenes de entrega o recibos relacionados. Utilizado cuando el módulo de Compras está instalado con Inventario.
19. picking_count
Tipo: Entero. Número de recogidas relacionadas. Computado. Utilizado para mostrar y abrir la lista de recibos.
20. create_date
Tipo: Fecha y hora. Almacena la fecha y hora en que se creó el registro. Gestionado automáticamente por Odoo. Útil para informes y auditorías.
21. write_date
Tipo: Fecha y hora. Almacena la fecha y hora de la última modificación. También gestionado automáticamente. Ayuda a rastrear cuándo se actualizó por última vez la información.
22. notes
Tipo: Texto. Términos y condiciones o notas internas. Puede mostrarse en la orden de compra. Utilizado para instrucciones especiales al proveedor.
23. company_id
Tipo: Many2one (res.company). En configuraciones de múltiples empresas, esto indica a qué empresa de Odoo pertenece el pedido. Afecta la visibilidad y el acceso a los registros.
24. user_id
Tipo: Many2one (res.users). El comprador o usuario responsable. Se utiliza para flujos de trabajo de aprobación y asignación de actividades.
25. fiscal_position_id
Tipo: Many2one (account.fiscal.position). La posición fiscal para la asignación de impuestos. Se aplica cuando el proveedor está en un país diferente o tiene un régimen fiscal especial.
26. payment_term_id
Tipo: Many2one (account.payment.term). Términos de pago (por ejemplo, Net 30, 50% por adelantado). Se utiliza al crear facturas de proveedores.
27. display_name
Tipo: Char. Nombre de visualización calculado. Combina el nombre con la información del proveedor. Se utiliza en menús desplegables many2one y resultados de búsqueda. Solo lectura.
28. active
Tipo: Boolean. Indicador de eliminación suave. Cuando es Falso, el registro se archiva y se oculta de las vistas predeterminadas. Las órdenes de compra no se eliminan físicamente para preservar el historial.
Cómo se utiliza este modelo en los flujos de trabajo empresariales
1. RFQ a Orden de Compra
El comprador crea una solicitud de cotización (borrador). Agrega líneas, envía al proveedor. El proveedor confirma o el comprador confirma manualmente. La orden está confirmada (estado = compra). Se pueden crear recibos y facturas del proveedor.
2. Recibo del Proveedor
Cuando llegan los bienes, el usuario crea un recibo a partir de la orden de compra. Los picking_ids están vinculados. Las cantidades recibidas actualizan el stock. Los costos de los productos se actualizan a partir del precio de compra.
3. Factura del Proveedor
A partir de una orden confirmada, los usuarios crean facturas de proveedores. Las líneas de la factura se extraen de las líneas de la orden. payment_term_id y fiscal_position_id provienen de la orden. invoice_status rastrea el progreso.
4. Dropshipping
Cuando un pedido de venta activa una compra, el origen se vincula de nuevo a la venta. dest_address_id se establece en la dirección del cliente para que el proveedor envíe directamente. El modelo purchase.order es el puente entre ventas y adquisiciones.
5. Fabricación y MRP
Cuando una orden de fabricación necesita componentes, puede crear órdenes de compra para materias primas. El campo de origen se vincula a la orden de fabricación. Este modelo es central en el ciclo de compra a pago.
Cómo los desarrolladores extienden este modelo
Los desarrolladores extienden purchase.order utilizando varios patrones. La herencia de modelos de Odoo es el principal mecanismo.
Herencia de Modelos
Utiliza _inherit = 'purchase.order' para extender el modelo. Agrega nuevos campos de Odoo, sobrescribe métodos o añade restricciones. El modelo heredado en Odoo mantiene tus cambios en un módulo separado para facilitar las actualizaciones.
Añadiendo Campos
Define nuevos campos de Odoo en tu modelo heredado. Usa el tipo de campo correcto: Char, Many2one, Boolean, Integer, Text, Selection. Considera campos dependientes de la empresa para multiempresa.
Extensiones de Python
Sobrescribe button_confirm, create o write para añadir lógica. Usa super() para llamar al original. Ten cuidado con los campos computados y sus dependencias.
Odoo Studio
Odoo Studio te permite añadir campos sin código. Bueno para personalizaciones rápidas. Para lógica compleja o actualizaciones, los módulos personalizados son más mantenibles. El modelo API en Odoo (purchase.order) está completamente expuesto a través de XML-RPC y JSON-RPC para integraciones.
Mejores prácticas
- Utiliza el estado correcto para cada etapa. No saltes estados ni evites la lógica de confirmación.
- Establece partner_ref cuando el proveedor proporcione una referencia. Ayuda a emparejar recibos y facturas.
- Utiliza origin para rastrear la fuente de las órdenes de compra. Esencial para dropshipping y fabricación.
- Al construir integraciones API, utiliza la API XML-RPC o JSON-RPC. El modelo purchase.order está completamente expuesto. Mapea los IDs externos con cuidado.
- Para campos personalizados, utiliza el prefijo
x_o un prefijo de módulo para evitar conflictos con futuras versiones de Odoo.
Errores comunes
- Modificar pedidos confirmados sin verificar el estado. Los pedidos confirmados tienen campos restringidos. Crea un nuevo pedido o utiliza el flujo de trabajo adecuado.
- Confundir partner_id y dest_address_id. partner_id es el proveedor; dest_address_id es donde van los productos (para dropshipping).
- Sobrescribir button_confirm sin llamar a super(). Esto puede romper otros módulos o futuras actualizaciones.
- Agregar campos personalizados requeridos sin valores predeterminados. Los pedidos existentes fallarán en la validación durante la actualización.
- Olvidar establecer currency_id al tratar con proveedores de múltiples divisas. Una moneda incorrecta puede llevar a costos e facturación incorrectos.
Conclusión
El modelo purchase.order es central para Odoo Purchase. Almacena RFQs y pedidos de compra confirmados. Comprender sus campos en Odoo y cómo los módulos lo extienden te ayudará a configurar, personalizar e integrar Odoo de manera efectiva.
Ya seas un consultor funcional mapeando procesos de adquisición o un desarrollador construyendo módulos personalizados, un sólido entendimiento de purchase.order te ahorrará tiempo y evitará errores.
¿Necesitas ayuda con tu implementación de Odoo?
Dasolo ayuda a las empresas a implementar, personalizar y optimizar Odoo. Nos especializamos en integraciones de API y desarrollo de Odoo. Nuestro equipo tiene una profunda experiencia con la arquitectura de datos de Odoo y modelos como purchase.order.
Si necesitas ayuda con tu implementación de Odoo, módulos personalizados o integraciones, estamos aquí para ayudar. Reserva una demostración para discutir tu proyecto.