Introdução
No Odoo, os modelos são a forma como os dados são organizados e mantidos na base de dados. Tudo o que representa informação de negócio — desde encomendas de venda até faturas e contactos — vive num modelo específico.
Para quem configura processos ou desenvolve em Odoo, compreender os modelos é fundamental. Eles definem campos, relações entre registos e a lógica de negócio que governa o sistema.
Este texto dedica-se a um dos modelos mais usados no módulo de Vendas: sales.order. Se está a criar módulos, a ligar sistemas externos ou a configurar fluxos comerciais, muito provavelmente irá encontrá‑lo frequentemente.
O que é o modelo sales.order
O modelo sales.order representa tanto as propostas (cotações) como as encomendas confirmadas. É aqui que se regista toda a transacção comercial antes de avançar para faturação ou expedição.
No Odoo, este modelo faz parte integrante do módulo Vendas (Sales) e é o ponto de entrada para a maior parte das operações comerciais.
Quando um vendedor cria uma proposta, está a gerar um registo sales.order em rascunho; após a confirmação do cliente, o mesmo registo passa para o estado de encomenda. Ou seja, cotações e pedidos confirmados convivem no mesmo modelo, e o campo state controla esse ciclo de vida.
Outros módulos acrescentam funcionalidades a este modelo via herança. O CRM liga a oportunidade, a Contabilidade adiciona campos de faturação e o Inventário acrescenta datas e informações de expedição — tudo sem duplicar a estrutura base.
Campos-chave do modelo
A seguir estão os campos mais relevantes do sales.order. Conhecê‑los facilita a gestão de cotações e encomendas e a integração com outros processos.
1. name
Tipo: Char. Identifica a referência da encomenda ou da cotação, normalmente com geração automática (por exemplo S00042). É o identificador visível em listas e documentos.
2. state
Tipo: Selection. Representa o estado da encomenda ao longo do seu ciclo: draft (rascunho), sent (enviada), sale (confirmada), done (entregue e faturada), cancel (anulada). O estado determina que ações estão disponíveis.
3. partner_id
Tipo: Many2one (res.partner). O cliente associado à encomenda. Campo obrigatório, usado para toda a lógica comercial e relatórios.
4. partner_invoice_id
Tipo: Many2one (res.partner). Endereço de faturação. Se não preenchido, herda partner_id. Útil quando a facturação é centralizada noutro contacto.
5. partner_shipping_id
Tipo: Many2one (res.partner). Endereço de entrega. Se faltar, também herda partner_id. Utilizado para planeamento de entregas e cálculos de envio.
6. user_id
Tipo: Many2one (res.users). Responsável comercial pela encomenda. Serve para comissões, relatórios de vendas e atribuição de actividades.
7. team_id
Tipo: Many2one (crm.team). A equipa de vendas responsável. Facilita a agregação por equipas e os dashboards de desempenho.
8. date_order
Tipo: Datetime. Data da encomenda: criação para rascunhos, confirmação para encomendas validadas. Usado em relatórios e ordenação.
9. validity_date
Tipo: Date. Data de validade da cotação. Após essa data a proposta pode caducar — importante para ofertas com prazo limitado.
10. commitment_date
Tipo: Datetime. Data prometida de entrega. Quando preenchida, o planeamento de expedições faz‑se tendo em conta esta data em vez dos prazos internos dos produtos.
11. order_line
Tipo: One2many (sale.order.line). Linhas da encomenda, onde se define produto, quantidade, preço e impostos — o detalhe essencial do pedido.
12. amount_untaxed
Tipo: Float. Subtotal antes de impostos, calculado a partir das linhas. Usado para exibição e análise.
13. amount_tax
Tipo: Float. Total de impostos, também calculado a partir das linhas segundo a configuração fiscal. Aparece em documentos e faturas.
14. amount_total
Tipo: Float. Total com impostos — valor principal para faturação e reportes.
15. currency_id
Tipo: Many2one (res.currency). Moeda usada na encomenda. Normalmente herdada da empresa ou da lista de preços; todas as quantias monetárias usam esta moeda.
16. pricelist_id
Tipo: Many2one (product.pricelist). Lista de preços aplicada à encomenda; determina os preços unitários das linhas.
17. payment_term_id
Tipo: Many2one (account.payment.term). Condições de pagamento (por exemplo 30 dias, 50% adiantamento). Aplicadas na criação de faturas.
18. fiscal_position_id
Tipo: Many2one (account.fiscal.position). Posicionamento fiscal para mapeamento de impostos, especialmente quando o cliente tem regime ou país diferente.
19. client_order_ref
Tipo: Char. Referência do cliente ou número de encomenda que o cliente utiliza. Visível em documentos e relatórios para rastreabilidade.
20. origin
Tipo: Char. Documento de origem — por exemplo, o nome da oportunidade que gerou a cotação. Útil para traçar a origem da encomenda.
21. create_date
Tipo: Datetime. Data e hora de criação do registo. Gerido automaticamente pelo Odoo e importante para auditoria.
22. write_date
Tipo: Datetime. Última data e hora de modificação do registo. Também gerido automaticamente e útil para controlo de alterações.
23. note
Tipo: Text. Texto livre para termos, condições ou instruções internas; pode aparecer na cotação ou fatura quando necessário.
24. require_signature
Tipo: Boolean. Se verdadeiro, exige assinatura do cliente online antes da confirmação — muito usado em vendas por portal ou e‑commerce.
25. require_payment
Tipo: Boolean. Se verdadeiro, exige pagamento antes da confirmação — aplicável a encomendas pré‑pagas ou com depósitos.
26. invoice_status
Tipo: Selection. Estado de faturação: no (não faturado), to invoice (por faturar), invoiced (totalmente faturado), upsell (linhas adicionais a faturar).
27. locked
Tipo: Boolean. Quando verdadeiro, impede alterações no registo — usado após confirmação ou posting de documentos relacionados.
28. company_id
Tipo: Many2one (res.company). Em cenários multi‑empresa, indica a empresa a que o pedido pertence e condiciona visibilidade e permissões.
29. tag_ids
Tipo: Many2many (crm.tag). Etiquetas para categorizar encomendas — úteis para filtros, relatórios e segmentação personalizada.
30. signed_by
Tipo: Char. Nome de quem assinou o documento quando a assinatura é exigida; mantido para fins de auditoria.
31. signed_on
Tipo: Datetime. Data e hora da assinatura; registada sempre que a assinatura é necessária para confirmar a encomenda.
32. prepayment_percent
Tipo: Float. Percentagem do pedido exigida como pagamento antecipado; usada em fluxos com depósitos obrigatórios.
Como este modelo entra nas rotinas de negócio
1. De cotação para encomenda
O fluxo típico começa com um vendedor a criar uma cotação em rascunho, adicionar linhas e preços e a enviar ao cliente. Depois da confirmação, o registo passa para o estado de encomenda e podem ser geradas faturas e ordens de expedição.
2. E‑commerce e portal
Quando um cliente compra no site, o sistema cria automaticamente um registo sales.order. Os campos require_payment e require_signature permitem exigir pagamento online ou assinatura antes da confirmação.
3. Do CRM para Vendas
Ao vencer uma oportunidade, normalmente gera‑se uma cotação a partir dessa oportunidade; o campo origin guarda a referência da origem e user_id/team_id ajudam nos relatórios e comissões.
4. Faturação
A partir de uma encomenda confirmada, criam‑se faturas cujo conteúdo é tirado das linhas da encomenda. As condições de pagamento e a posição fiscal são reaplicadas, e invoice_status mostra o estado do processo.
5. Expedição e compromisso
A commitment_date serve para agendar entregas de acordo com o compromisso com o cliente. O endereço de entrega (partner_shipping_id) é usado para preparar as ordens logísticas.
Como os programadores alargam este modelo
Os programadores têm várias formas de estender o sales.order, sendo a herança de modelos a abordagem padrão.
Herança de modelo
Crie um módulo com _inherit = 'sale.order' para acrescentar campos, métodos ou restrições. Esta técnica mantém as alterações isoladas e facilita atualizações e manutenção.
Adicionar campos
Declare novos campos relevantes no modelo herdado: Char, Many2one, Boolean, Integer, Text, Selection. Para ambientes multi‑empresa, considere campos dependentes da company_id.
Extensões em Python
Sobreponha métodos como action_confirm, create ou write para injectar lógica adicional, sempre chamando super() quando necessário e gerindo corretamente campos computados e as suas dependências.
Odoo Studio
O Odoo Studio permite acrescentar campos sem programar — ideal para personalizações rápidas. Para regras complexas ou caso preveja upgrades, prefira módulos personalizados.
Boas práticas
- Use sempre o estado correto em cada etapa do processo e evite saltar etapas que a lógica do sistema pressupõe.
- Defina a commitment_date quando houver uma data de entrega prometida ao cliente; isso ajuda o planeamento logístico e evita surpresas.
- Quando precisar de agrupar por entidade principal (por exemplo para limites de crédito ou relatórios), utilize commercial_partner_id em vez de partner_id.
- Nas integrações via API, use XML‑RPC ou JSON‑RPC e mapeie cuidadosamente os IDs externos — o modelo sales.order está completamente exposto para integração.
- Para campos personalizados, prefira prefixos x_ ou incluir o prefixo do seu módulo para evitar colisões com futuras versões do Odoo.
Erros comuns
- Não tente alterar encomendas bloqueadas sem seguir o fluxo adequado — registos com locked = True não devem ser editados diretamente; crie revisões ou utilize o workflow correto.
- Não confunda partner_id com partner_invoice_id e partner_shipping_id: cada um tem um propósito distinto. Quando os endereços diferem, preencha os três campos.
- Não sobreponha action_confirm sem invocar super(), pois isso pode quebrar integrações de outros módulos e complicar futuras atualizações.
- Evite tornar novos campos obrigatórios sem fornecer valores por defeito; isso pode causar falhas em registos existentes após atualizações.
- Garanta que pricelist_id está corretamente definido quando a moeda ou preços divergem das configurações padrão; preços incorrectos levam a faturação errada.
Conclusão
O sales.order é o núcleo do módulo Vendas do Odoo: concentra cotações e encomendas confirmadas. Dominar os seus campos e entender como é estendido por outros módulos é crucial para configurar, customizar e integrar o Odoo com sucesso.
Se trabalha como consultor funcional ou como programador, investir tempo em compreender o sales.order evita retrabalho e reduz erros operacionais.
Precisa de ajuda com a sua implementação Odoo?
A Dasolo acompanha empresas na implementação, personalização e optimização do Odoo. Temos experiência em integrações via API e no desenho de módulos que respeitam a arquitectura de dados do Odoo, incluindo modelos como o sales.order.
Se precisa de apoio na sua implementação Odoo, no desenvolvimento de módulos ou em integrações, podemos ajudar a levantar requisitos e a executar o projecto. Agende uma demonstração para conversarmos sobre o seu projecto.