Introdução
No Odoo, os modelos definem como os dados são estruturados e armazenados na base de dados. Cada pedaço de dados empresariais com o qual você trabalha, desde ordens de compra a faturas e inventário, reside em um modelo.
Compreender os modelos do Odoo é essencial tanto para desenvolvedores quanto para consultores funcionais. Os modelos são a base da arquitetura de dados do Odoo. Eles definem os campos do Odoo, relacionamentos e lógica de negócios.
Este artigo foca em um dos modelos mais importantes do Odoo: purchase.order. Quer você esteja construindo módulos personalizados, integrando sistemas externos ou configurando fluxos de trabalho de aquisição, você trabalhará com este modelo.
O que é o modelo purchase.order
O modelo purchase.order representa ordens de compra e pedidos de cotação (RFQs) no Odoo. É o local central onde todas as transações de aquisição são capturadas antes de se tornarem recibos ou faturas de fornecedores.
Este modelo no Odoo é utilizado pelo módulo de Compras. Quando um comprador cria um RFQ, ele cria um registro de purchase.order. Quando o fornecedor confirma ou o comprador aprova, o pedido passa de rascunho para confirmado. O mesmo modelo no Odoo mantém tanto RFQs em rascunho quanto ordens de compra confirmadas. O campo de estado rastreia o ciclo de vida.
Outros módulos estendem este modelo através da herança de modelos do Odoo. O Inventário adiciona lógica de recebimento e separação. A Contabilidade adiciona campos de fatura de fornecedor. A Manufatura pode criar ordens de compra a partir de listas de materiais. Cada módulo adiciona o que precisa sem duplicar a estrutura central.
Campos-chave no modelo
Aqui estão os campos mais importantes do Odoo no modelo purchase.order. Compreender estes ajudará você a trabalhar de forma eficaz com ordens de compra.
1. name
Tipo: Char. Este campo armazena a referência do pedido (por exemplo, PO00042). Geralmente é gerado automaticamente e exibido em visualizações de lista e em documentos. É o identificador principal para a ordem de compra.
2. state
Tipo: Selection. Rastreia o ciclo de vida do pedido. Valores: draft (RFQ), sent (enviado ao fornecedor), to approve (aguardando aprovação), purchase (confirmado), done (totalmente recebido e faturado), cancel (cancelado). O estado determina quais ações estão disponíveis.
3. partner_id
Tipo: Many2one (res.partner). O fornecedor ou fornecedor. Obrigatório. Este é o contato principal ou empresa para o pedido. Usado para toda a lógica e relatórios relacionados ao fornecedor.
4. partner_ref
Tipo: Char. A referência do fornecedor ou número do pedido do fornecedor. Usado quando o fornecedor fornece sua própria referência de pedido. Exibido em documentos e ajuda a corresponder recibos e faturas.
5. date_order
Tipo: Datetime. A data do pedido. Para pedidos em rascunho: data de criação. Para pedidos confirmados: data de confirmação. Usado para relatórios, ordenação e como a data esperada padrão para linhas de pedido.
6. date_approve
Tipo: Datetime. A data de aprovação ou confirmação. Definida quando o pedido passa para o estado de compra. Somente leitura. Usado para relatórios e trilhas de auditoria.
7. order_line
Tipo: One2many (purchase.order.line). As linhas do pedido. Cada linha contém produto, quantidade, preço e imposto. Este é o detalhe central do pedido de compra.
8. amount_untaxed
Tipo: Float. O subtotal antes do imposto. Calculado a partir das linhas do pedido. Usado para relatórios e exibição.
9. amount_tax
Tipo: Float. O valor total do imposto. Calculado a partir das linhas do pedido com base na configuração do imposto. Exibido no pedido e na fatura do fornecedor.
10. amount_total
Tipo: Float. O valor total incluindo imposto. O valor principal para faturamento e relatórios.
11. currency_id
Tipo: Many2one (res.currency). A moeda. Geralmente herdada da empresa ou fornecedor. Todos os campos monetários usam esta moeda.
12. origin
Tipo: Char. O documento de origem. Por exemplo, quando um pedido é criado a partir de uma ordem de venda (dropship) ou ordem de fabricação, o nome da origem é armazenado aqui. Usado para rastreabilidade.
13. dest_address_id
Tipo: Many2one (res.partner). O endereço de entrega. Se não definido, padrão para o endereço da empresa. Usado para dropshipping quando os produtos vão diretamente para o cliente.
14. priority
Tipo: Seleção. Prioridade do pedido: Normal ou Urgente. Usado para ordenação e destaque. Pedidos urgentes podem receber tratamento especial nos fluxos de trabalho.
15. invoice_status
Tipo: Seleção. Rastreia a faturação: não (não faturado), a faturar (pronto para faturar), faturado (totalmente faturado). Controla a visibilidade da ação Criar Fatura.
16. invoice_count
Tipo: Inteiro. Número de faturas de fornecedor relacionadas. Computado. Usado para exibição e para abrir a lista de faturas.
17. invoice_ids
Tipo: One2many (account.move). As faturas de fornecedor relacionadas. Liga as ordens de compra à contabilidade. Usado para correspondência de três vias e rastreamento de pagamentos.
18. picking_ids
Tipo: One2many (stock.picking). As ordens de entrega ou recibos relacionadas. Usado quando o módulo de Compras está instalado com o Inventário.
19. picking_count
Tipo: Inteiro. Número de pickings relacionados. Computado. Usado para exibição e para abrir a lista de recibos.
20. create_date
Tipo: Datetime. Armazena a data e hora em que o registro foi criado. Gerido automaticamente pelo Odoo. Útil para relatórios e auditorias.
21. write_date
Tipo: Datetime. Armazena a data e hora da última modificação. Também gerido automaticamente. Ajuda a rastrear quando os dados foram atualizados pela última vez.
22. notes
Tipo: Texto. Termos e condições ou notas internas. Podem ser exibidos na ordem de compra. Usado para instruções especiais ao fornecedor.
23. company_id
Tipo: Many2one (res.company). Em configurações de múltiplas empresas, isso indica a qual empresa Odoo o pedido pertence. Afeta a visibilidade e o acesso aos registros.
24. user_id
Tipo: Many2one (res.users). O comprador ou usuário responsável. Usado para fluxos de trabalho de aprovação e atribuição de atividades.
25. fiscal_position_id
Tipo: Many2one (account.fiscal.position). A posição fiscal para mapeamento de impostos. Aplicada quando o fornecedor está em um país diferente ou possui um regime fiscal especial.
26. payment_term_id
Tipo: Many2one (account.payment.term). Condições de pagamento (por exemplo, Net 30, 50% adiantado). Usado ao criar faturas de fornecedores.
27. display_name
Tipo: Char. Nome de exibição computado. Combina o nome com informações do fornecedor. Usado em dropdowns many2one e resultados de busca. Somente leitura.
28. active
Tipo: Boolean. Sinalizador de exclusão suave. Quando Falso, o registro é arquivado e oculto das visualizações padrão. Os pedidos de compra não são fisicamente excluídos para preservar o histórico.
Como este modelo é utilizado em fluxos de trabalho empresariais
1. RFQ para Ordem de Compra
O comprador cria um pedido de cotação (rascunho). Adiciona linhas, envia ao fornecedor. O fornecedor confirma ou o comprador confirma manualmente. A ordem é confirmada (estado = compra). Recebimentos e faturas do fornecedor podem ser criados.
2. Recebimento do Fornecedor
Quando os bens chegam, o usuário cria um recibo a partir da ordem de compra. Os picking_ids estão vinculados. As quantidades recebidas atualizam o estoque. Os custos dos produtos são atualizados a partir do preço de compra.
3. Fatura do Fornecedor
A partir de uma ordem confirmada, os usuários criam faturas de fornecedores. As linhas de fatura são extraídas das linhas de pedido. payment_term_id e fiscal_position_id vêm da ordem. invoice_status rastreia o progresso.
4. Dropshipping
Quando uma ordem de venda aciona uma compra, a origem se vincula à venda. dest_address_id é definido como o endereço do cliente para que o fornecedor envie diretamente. O modelo purchase.order é a ponte entre vendas e compras.
5. Fabricação e MRP
Quando uma ordem de fabricação precisa de componentes, pode criar ordens de compra para matérias-primas. O campo de origem se vincula à ordem de fabricação. Este modelo é central para o ciclo de compra a pagamento.
Como os desenvolvedores estendem este modelo
Os desenvolvedores estendem purchase.order usando vários padrões. A herança de modelo do Odoo é o principal mecanismo.
Herança de Modelo
Use _inherit = 'purchase.order' para estender o modelo. Adicione novos campos Odoo, sobreponha métodos ou adicione restrições. O modelo herdado no Odoo mantém suas alterações em um módulo separado para atualizações fáceis.
Adicionando Campos
Defina novos campos Odoo no seu modelo herdado. Use o tipo de campo correto: Char, Many2one, Boolean, Integer, Text, Selection. Considere campos dependentes da empresa para multi-empresa.
Extensões Python
Sobreponha button_confirm, create ou write para adicionar lógica. Use super() para chamar o original. Tenha cuidado com campos computados e suas dependências.
Odoo Studio
O Odoo Studio permite que você adicione campos sem código. Bom para personalizações rápidas. Para lógica complexa ou atualizações, módulos personalizados são mais fáceis de manter. O modelo API no Odoo (purchase.order) está totalmente exposto via XML-RPC e JSON-RPC para integrações.
Melhores práticas
- Use o estado correto para cada etapa. Não pule estados ou contorne a lógica de confirmação.
- Defina partner_ref quando o fornecedor fornecer uma referência. Isso ajuda a corresponder recibos e faturas.
- Use origin para rastrear a origem dos pedidos de compra. Essencial para dropshipping e fabricação.
- Ao construir integrações de API, use a API XML-RPC ou JSON-RPC. O modelo purchase.order está totalmente exposto. Mapeie IDs externos com cuidado.
- Para campos personalizados, use o prefixo
x_ou um prefixo de módulo para evitar conflitos com versões futuras do Odoo.
Erros comuns
- Modificar pedidos confirmados sem verificar o estado. Pedidos confirmados têm campos restritos. Crie um novo pedido ou use o fluxo de trabalho adequado.
- Confundir partner_id e dest_address_id. partner_id é o fornecedor; dest_address_id é para onde os bens vão (para dropshipping).
- Substituir button_confirm sem chamar super(). Isso pode quebrar outros módulos ou futuras atualizações.
- Adicionar campos personalizados obrigatórios sem valores padrão. Pedidos existentes falharão na validação na atualização.
- Esquecer de definir currency_id ao lidar com fornecedores de múltiplas moedas. Moeda errada pode levar a custos e faturamento incorretos.
Conclusão
O modelo purchase.order é central para Odoo Purchase. Ele armazena RFQs e pedidos de compra confirmados. Compreender os campos do Odoo e como os módulos o estendem ajudará você a configurar, personalizar e integrar o Odoo de forma eficaz.
Seja você um consultor funcional mapeando processos de aquisição ou um desenvolvedor construindo módulos personalizados, um sólido entendimento de purchase.order economizará tempo e evitará erros.
Precisa de ajuda com a sua implementação do Odoo?
A Dasolo ajuda empresas a implementar, personalizar e otimizar o Odoo. Especializamo-nos em integrações de API e desenvolvimento Odoo. Nossa equipe tem ampla experiência com a arquitetura de dados do Odoo e modelos como purchase.order.
Se você precisar de ajuda com sua implementação do Odoo, módulos personalizados ou integrações, estamos aqui para ajudar. Agende uma demonstração para discutir seu projeto.