Introdução
No Odoo, um “modelo” define a forma como a informação empresarial é organizada e guardada na base de dados. Qualquer entidade comercial — encomendas, faturas, movimentos de stock — existe como registo de um modelo específico.
Perceber os modelos do Odoo é obrigatório tanto para técnicos como para consultores funcionais. Eles são a espinha dorsal da arquitetura de dados: especificam campos, relações entre registos e a lógica de negócio que governa o comportamento das entidades.
Este texto foca-se num dos modelos mais críticos na área das compras: o purchase.order. Se vai criar módulos à medida, ligar sistemas externos ou configurar fluxos de aprovisionamento, este modelo estará sempre presente.
O que é o modelo purchase.order
O purchase.order representa no Odoo as encomendas de compra e os pedidos de proposta (RFQ). É aqui que se regista toda a informação de procurement antes de se tornar em recibos de entrada ou faturas do fornecedor.
O módulo de Compras (Purchase) utiliza este modelo. Um comprador cria um RFQ que materializa como um registo purchase.order; quando o fornecedor confirma ou o comprador aprova, o estado passa de rascunho para confirmado. O mesmo modelo aloja tanto RFQs como encomendas confirmadas, e o campo state documenta esse ciclo de vida.
Outros módulos acrescentam funcionalidades a este modelo através da herança de modelos do Odoo. O Inventário acrescenta logística de recepção e pickings; a Contabilidade liga campos de faturas; a Produção pode gerar encomendas a partir de listas de materiais. Cada app estende o núcleo sem duplicar a estrutura base.
Campos principais do modelo
A seguir estão os campos essenciais do purchase.order. Conhecê‑los facilita a configuração, personalização e integração das compras na sua empresa.
1. name
Tipo: Char. Guarda o identificador da encomenda (ex.: PO00042). Normalmente gerado automaticamente e mostrado em listas e documentos — é o rótulo primário para localizar a encomenda.
2. state
Tipo: Selection. Regista o estado do processo: draft (RFQ), sent (enviado), to approve (aguarda aprovação), purchase (confirmada), done (recebida e faturada), cancel (anulada). O estado controla que ações estão disponíveis.
3. partner_id
Tipo: Many2one (res.partner). O fornecedor. Campo obrigatório. Representa a entidade ou contacto associado à encomenda e alimenta a lógica de fornecedores e relatórios.
4. partner_ref
Tipo: Char. Referência do fornecedor, como o número de encomenda do próprio vendedor. Facilita a reconciliação entre documentos e aparece nas impressões da encomenda.
5. date_order
Tipo: Datetime. Data da ordem: na fase de rascunho é a data de criação; após confirmação passa a ser a data de confirmação. Serve para relatórios, ordenação e datas padrão das linhas.
6. date_approve
Tipo: Datetime. Data de aprovação/confirmção. Definida ao passar para o estado purchase. Campo apenas leitura, útil para auditorias e análises temporais.
7. order_line
Tipo: One2many (purchase.order.line). Linhas da encomenda — cada uma com produto, quantidade, preço e taxas. Constituem o detalhe operativo da encomenda.
8. amount_untaxed
Tipo: Float. Subtotal sem impostos. Calculado a partir das linhas da encomenda. Utilizado em relatórios e mostradores.
9. amount_tax
Tipo: Float. Total de impostos. Calculado segundo as taxas aplicadas nas linhas. Aparece na encomenda e na fatura do fornecedor.
10. amount_total
Tipo: Float. Valor total com impostos. Principal montante para faturação e relatórios financeiros.
11. currency_id
Tipo: Many2one (res.currency). A moeda aplicável. Normalmente herdada da empresa ou do fornecedor; todos os campos monetários usam esta moeda.
12. origin
Tipo: Char. Documento de origem: por exemplo, quando a encomenda nasce de uma venda (dropship) ou de uma ordem de produção, o nome de origem fica aqui. Serve para rastreabilidade.
13. dest_address_id
Tipo: Many2one (res.partner). Endereço de entrega. Se não definido, usa o endereço da empresa. Importante em dropshipping quando a mercadoria vai diretamente para o cliente.
14. priority
Tipo: Selection. Prioridade da encomenda: Normal ou Urgente. Ajuda a ordenar e destacar pedidos que exigem tratamento especial.
15. invoice_status
Tipo: Selection. Estado da faturação: no (não faturada), to invoice (por faturar), invoiced (totalmente faturada). Controla a visibilidade da ação de Criar Fatura.
16. invoice_count
Tipo: Integer. Número de faturas do fornecedor associadas. Calculado automaticamente; usado para navegação rápida entre documentos.
17. invoice_ids
Tipo: One2many (account.move). As faturas do fornecedor relacionadas. Liga compras à contabilidade para conciliação e pagamentos.
18. picking_ids
Tipo: One2many (stock.picking). Ordens de entrega/receção relacionadas. Popula‑se quando o módulo de Inventário está ativo.
19. picking_count
Tipo: Integer. Contagem de pickings relacionados. Campo calculado; facilita abrir a lista de recibos.
20. create_date
Tipo: Datetime. Data e hora de criação do registo. Gerido automaticamente pelo Odoo; útil para relatórios e auditorias.
21. write_date
Tipo: Datetime. Data e hora da última modificação. Também automática; indica quando o registo foi atualizado pela última vez.
22. notes
Tipo: Text. Campo livre para condições gerais ou instruções internas. Pode ser impresso na encomenda para orientar o fornecedor.
23. company_id
Tipo: Many2one (res.company). Em ambientes multi‑empresa, indica a empresa proprietária do registo. Afeta visibilidade e regras de acesso.
24. user_id
Tipo: Many2one (res.users). Comprador ou utilizador responsável. Utilizado em fluxos de aprovação e atribuição de atividades.
25. fiscal_position_id
Tipo: Many2one (account.fiscal.position). Posição fiscal usada para mapear impostos — importante quando o fornecedor está noutro país ou tem regime fiscal específico.
26. payment_term_id
Tipo: Many2one (account.payment.term). Condições de pagamento (ex.: 30 dias, 50% adiantamento). Transportadas para as faturas do fornecedor.
27. display_name
Tipo: Char. Nome de visualização calculado — normalmente combina o nome da encomenda com dados do fornecedor. Usado em dropdowns e resultados de pesquisa; leitura apenas.
28. active
Tipo: Boolean. Sinal de arquivo (soft delete). Quando False, o registo fica arquivado e não aparece nas vistas por defeito; as encomendas não são apagadas fisicamente para preservar o histórico.
Como este modelo entra nos fluxos de trabalho
1. De RFQ para Encomenda de Compra
O processo típico começa com um RFQ em rascunho: o comprador cria linhas e envia ao fornecedor. Após confirmação pelo fornecedor (ou aprovação do comprador), o RFQ transforma‑se numa encomenda (state = purchase) e podem então ser gerados recibos de entrada e faturas.
2. Receção de Fornecedor
Na chegada das mercadorias, gera‑se um documento de receção ligado à encomenda. Os pickings e quantidades recebidas atualizam o stock; os custos de produto podem ser ajustados segundo o preço de compra.
3. Fatura do Fornecedor
A partir da encomenda confirmada gera‑se a fatura do fornecedor: as linhas de fatura são derivadas das linhas da encomenda e campos como prazo de pagamento e posição fiscal são trazidos automaticamente; invoice_status mostra o progresso até ao pagamento.
4. Dropshipping
No dropshipping, uma venda pode disparar uma compra cujo campo origin referencia a venda. dest_address_id aponta para o cliente, permitindo que o fornecedor envie diretamente para a morada final. O modelo purchase.order faz a ponte entre vendas e aprovisionamento.
5. Produção e MRP
Quando uma ordem de fabrico precisa de componentes, o MRP pode criar encomendas de compra para matérias‑primas; o campo origin liga a encomenda de compra à ordem de produção. Assim, este modelo participa de todo o ciclo procure‑to‑pay.
Como os programadores estendem este modelo
Os programadores estendem o purchase.order recorrendo a diferentes padrões de customização. A herança de modelos do Odoo é o método central.
Herança de Modelo
Em módulos personalizados usa‑se _inherit = 'purchase.order' para acrescentar campos, sobrescrever métodos ou introduzir restrições. Essa abordagem mantém as alterações organizadas num módulo à parte, facilitando atualizações futuras.
Adicionar Campos
Declare novos campos no modelo herdado usando os tipos adequados: Char, Many2one, Boolean, Integer, Text, Selection. Pense também em campos dependentes da empresa quando estiver em cenários multi‑empresa.
Extensões em Python
Sobrescreva métodos como button_confirm, create ou write para inserir lógica adicional, mas chame sempre super() para preservar comportamento existente. Preste atenção às dependências de campos computados para evitar resultados inconsistentes.
Odoo Studio
O Odoo Studio permite acrescentar campos sem programar — é rápido para pequenas personalizações. Para lógica complexa ou quando prevê upgrades, é preferível desenvolver módulos. O modelo purchase.order está disponível via XML‑RPC e JSON‑RPC para integração com sistemas externos.
Boas práticas
- Use o estado correto em cada etapa do processo e não contorne a lógica de confirmação. Respeitar os estados evita que workflows e automações fiquem inconsistente.
- Registe partner_ref quando o fornecedor der uma referência própria — isso ajuda a bater documentos na recepção e na faturação.
- Preencha origin para manter rastreabilidade entre processos (venda → compra → produção). É crucial em dropshipping e na análise posterior.
- Para integrações API, utilize XML‑RPC ou JSON‑RPC e mapeie IDs externos com cuidado para evitar duplicados ou erros de referência.
- Para campos personalizados, prefixe com x_ ou com o prefixo do seu módulo para reduzir o risco de colisões com futuras versões do Odoo.
Erros comuns
- Modificar encomendas já confirmadas sem verificar o estado. Encomendas confirmadas têm restrições — se necessário, crie um novo registo ou siga o fluxo correto de ajustamento.
- Confundir partner_id com dest_address_id. partner_id identifica o fornecedor; dest_address_id é onde as mercadorias devem ser entregues (útil em dropshipping).
- Sobrescrever button_confirm sem chamar super(). Isso pode quebrar comportamentos de outros módulos e complicar upgrades.
- Adicionar campos obrigatórios nas customizações sem definir valores por omissão. Registos existentes podem falhar validações após a atualização.
- Esquecer de definir currency_id em casos multi‑moeda. Moeda errada leva a custos e faturas incorretas.
Conclusão
O modelo purchase.order é um pilar do módulo de Compras no Odoo: armazena RFQs e encomendas confirmadas. Conhecer os seus campos e perceber como outros módulos o estendem ajuda a configurar, personalizar e integrar o Odoo com segurança.
Se é consultor funcional a desenhar processos ou programador a criar módulos, dominar o purchase.order evita retrabalho e reduz o risco de erros operacionais.
Precisa de ajuda com a sua implementação Odoo?
A Dasolo apoia empresas a implementar, personalizar e otimizar o Odoo. Temos experiência em integrações via API e desenvolvimento sobre a arquitetura de dados do Odoo, incluindo modelos como o purchase.order.
Se precisa de suporte para implementação Odoo, desenvolvimento de módulos à medida ou integrações, podemos ajudar a desenhar e executar a solução adequada. Agende uma demonstração para discutir o seu projeto.