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 pedidos de venta hasta facturas y contactos, 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 campos, relaciones y lógica empresarial.
Este artículo se centra en uno de los modelos más importantes de Odoo: sales.order. Ya sea que estés construyendo módulos personalizados, integrando sistemas externos o configurando flujos de trabajo de ventas, trabajarás con este modelo.
¿Qué es el modelo sales.order?
El modelo sales.order representa cotizaciones y pedidos de venta en Odoo. Es el lugar central donde se capturan todas las transacciones de ventas antes de que se facturen o se entreguen.
Este modelo en Odoo es utilizado por el módulo de Ventas.
Cuando un vendedor crea una cotización, crea un registro de sales.order. Cuando el cliente confirma, el pedido pasa de borrador a confirmado. El mismo modelo en Odoo contiene tanto cotizaciones en borrador como pedidos confirmados. 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. CRM vincula oportunidades a pedidos. Contabilidad añade campos de factura. Inventario añade fechas de entrega y compromiso. 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 sales.order. Comprender estos te ayudará a trabajar de manera efectiva con cotizaciones y pedidos.
1. name
Tipo: Char. Este campo almacena la referencia del pedido o el número de cotización. Generalmente es auto-generado (por ejemplo, S00042) y se muestra en vistas de lista y en documentos. Es el identificador principal del pedido.
2. state
Tipo: Selection. Rastrear el ciclo de vida del pedido. Valores: draft (cotización), sent (cotización enviada al cliente), sale (pedido confirmado), done (totalmente entregado y facturado), cancel (cancelado). El estado determina qué acciones están disponibles.
3. partner_id
Tipo: Many2one (res.partner). El cliente. Requerido. Este es el contacto principal o la empresa para el pedido. Se utiliza para toda la lógica y reportes relacionados con el cliente.
4. partner_invoice_id
Tipo: Many2one (res.partner). La dirección de facturación. Si no se establece, se predetermina a partner_id. Utilice esto cuando la dirección de la factura difiera del contacto principal (por ejemplo, facturación central).
5. partner_shipping_id
Tipo: Many2one (res.partner). La dirección de entrega. Si no se establece, se predetermina a partner_id. Utilizado para pedidos de entrega y cálculos de envío.
6. user_id
Tipo: Many2one (res.users). El vendedor o usuario responsable. Utilizado para CRM, comisiones y asignación de actividades. A menudo se establece desde el equipo de ventas u oportunidad.
7. team_id
Tipo: Many2one (crm.team). El equipo de ventas. Agrupa a los vendedores y impulsa la elaboración de informes. Utilizado para paneles y cuotas basados en equipos.
8. date_order
Tipo: Datetime. La fecha del pedido. Para pedidos en borrador: fecha de creación. Para pedidos confirmados: fecha de confirmación. Utilizado para informes y ordenación.
9. validity_date
Tipo: Fecha. La fecha de expiración de la cotización. Después de esta fecha, la cotización puede volverse inválida. Útil para ofertas limitadas en el tiempo.
10. commitment_date
Tipo: Fecha y hora. La fecha de entrega prometida. Cuando se establece, los pedidos de entrega se programan en función de esta fecha en lugar de los plazos de entrega del producto. Importante para los compromisos con el cliente.
11. order_line
Tipo: Uno a muchos (sale.order.line). Las líneas del pedido. Cada línea contiene producto, cantidad, precio e impuesto. Este es el detalle central del pedido.
12. amount_untaxed
Tipo: Flotante. El subtotal antes de impuestos. Computado a partir de las líneas del pedido. Utilizado para informes y visualización.
13. amount_tax
Tipo: Flotante. El monto total de impuestos. Computado a partir de las líneas del pedido según la configuración de impuestos. Se muestra en el pedido y la factura.
14. amount_total
Tipo: Flotante. El monto total incluyendo impuestos. La cantidad principal para la facturación y los informes.
15. currency_id
Tipo: Muchos a uno (res.currency). La moneda. Generalmente heredada de la empresa o la lista de precios. Todos los campos monetarios utilizan esta moneda.
16. pricelist_id
Tipo: Many2one (product.pricelist). La lista de precios utilizada para el pedido. Determina los precios unitarios en las líneas. Se puede establecer desde el socio o manualmente.
17. payment_term_id
Tipo: Many2one (account.payment.term). Condiciones de pago (por ejemplo, Net 30, 50% por adelantado). Se utiliza al crear facturas.
18. fiscal_position_id
Tipo: Many2one (account.fiscal.position). La posición fiscal para la asignación de impuestos. Se aplica cuando el cliente está en un país diferente o tiene un régimen fiscal especial.
19. client_order_ref
Tipo: Char. La referencia del cliente o número de pedido. Se utiliza cuando el cliente proporciona su propia referencia de pedido. Se muestra en documentos e informes.
20. origin
Tipo: Char. El documento de origen. Por ejemplo, cuando se crea un pedido a partir de una oportunidad, el nombre de la oportunidad se almacena aquí. Se utiliza para la trazabilidad.
21. create_date
Tipo: Datetime. Almacena la fecha y hora en que se creó el registro. Gestionado automáticamente por Odoo. Útil para informes y auditorías.
22. write_date
Tipo: Fecha y hora. Almacena la fecha y hora de la última modificación. También se gestiona automáticamente. Ayuda a rastrear cuándo se actualizó por última vez los datos.
23. nota
Tipo: Texto. Términos y condiciones o notas internas. Se puede mostrar en la cotización y la factura. Se utiliza para texto legal o instrucciones especiales.
24. requerir_firma
Tipo: Booleano. Cuando es Verdadero, el cliente debe firmar en línea antes de que se confirme el pedido. Se utiliza para flujos de comercio electrónico y portales.
25. requerir_pago
Tipo: Booleano. Cuando es Verdadero, se requiere el pago antes de la confirmación. Se utiliza para pedidos prepagados o basados en depósitos.
26. estado_factura
Tipo: Selección. Rastrear la facturación: no (no facturado), a facturar (listo para facturar), facturado (totalmente facturado) o venta adicional (líneas adicionales para facturar).
27. bloqueado
Tipo: Booleano. Cuando es Verdadero, el pedido no puede ser modificado. Se establece automáticamente cuando se confirma el pedido o cuando se publican documentos relacionados.
28. id_empresa
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.
29. tag_ids
Tipo: Many2many (crm.tag). Etiquetas para la categorización. Utilizadas para filtrar, informar y segmentar. Flexibles para flujos de trabajo personalizados.
30. signed_by
Tipo: Char. Nombre de la persona que firmó el pedido cuando se utiliza require_signature. Almacenado para auditoría.
31. signed_on
Tipo: Datetime. Fecha y hora de la firma. Utilizada cuando se requiere firma para la confirmación.
32. prepayment_percent
Tipo: Float. El porcentaje del pedido que debe pagarse como prepago. Utilizado con require_payment para pedidos basados en depósitos.
Cómo se utiliza este modelo en los flujos de trabajo empresariales
1. Cotización a Pedido
El vendedor crea una cotización (borrador). Agrega líneas, establece precios, envía al cliente. El cliente confirma. El pedido se confirma (estado = venta). Se pueden crear facturas y órdenes de entrega.
2. Comercio electrónico y Portal
Los clientes realizan pedidos en el sitio web. Los pedidos se crean como registros sales.order. require_signature y require_payment pueden exigir el pago en línea o la firma antes de la confirmación.
3. CRM a Ventas
Cuando se gana una oportunidad, se crea una cotización a partir de ella. El campo de origen se vincula de nuevo a la oportunidad. user_id y team_id impulsan los informes de ventas y las comisiones.
4. Facturación
A partir de un pedido confirmado, los usuarios crean facturas. Las líneas de la factura se extraen de las líneas del pedido. payment_term_id y fiscal_position_id provienen del pedido. invoice_status rastrea el progreso.
5. Entrega y Compromiso
commitment_date impulsa la programación de entregas. Cuando se establece, los pedidos de entrega se planifican en torno a ello. partner_shipping_id define la dirección de entrega.
Cómo los desarrolladores extienden este modelo
Los desarrolladores extienden sales.order utilizando varios patrones. La herencia de modelos de Odoo es el principal mecanismo.
Herencia de Modelos
Utiliza _inherit = 'sale.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. Utiliza el tipo de campo correcto: Char, Many2one, Boolean, Integer, Text, Selection. Considera campos dependientes de la empresa para multiempresa.
Extensiones de Python
Sobrescribe action_confirm, create o write para añadir lógica. Usa super() para llamar al original. Ten cuidado con los campos calculados y sus dependencias.
Odoo Studio
Odoo Studio te permite añadir campos sin código. Es bueno para personalizaciones rápidas. Para lógica compleja o actualizaciones, los módulos personalizados son más mantenibles.
Mejores prácticas
- Usa el estado correcto para cada etapa. No omitas estados ni eludas la lógica de confirmación.
- Establece commitment_date cuando el cliente tenga una fecha prometida. Mejora la planificación de entregas.
- Usa commercial_partner_id cuando necesites la entidad de nivel superior para agrupaciones (por ejemplo, para crédito o informes).
- Al construir integraciones API, usa la API XML-RPC o JSON-RPC. El modelo sales.order está completamente expuesto. Mapea los IDs externos con cuidado.
- Para campos personalizados, usa el prefijo
x_o un prefijo de módulo para evitar conflictos con futuras versiones de Odoo.
Errores comunes
- Modificar pedidos confirmados sin verificar bloqueados. Los pedidos bloqueados no pueden ser editados. Crea una nueva revisión o usa el flujo de trabajo adecuado.
- Confundir partner_id, partner_invoice_id y partner_shipping_id. Cada uno tiene un propósito distinto. Establece los tres cuando las direcciones difieran.
- Sobrescribir action_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 la validación en la actualización.
- Olvidar establecer pricelist_id cuando la moneda o el precio difieren del predeterminado. Precios incorrectos pueden llevar a facturación errónea.
Conclusión
El modelo sales.order es central para Odoo Sales. Almacena cotizaciones y pedidos confirmados. Comprender sus campos 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 ventas o un desarrollador construyendo módulos personalizados, un sólido entendimiento de sales.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 sales.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.