Introdução
No Odoo, os modelos são a forma como os dados empresariais são organizados e guardados na base de dados. Tudo o que representa informação de negócio — desde encomendas de venda a entradas de stock e artigos — vive num modelo específico.
Perceber o funcionamento dos modelos é obrigatório tanto para consultores funcionais como para programadores. Os modelos constituem a espinha dorsal da arquitetura de dados do Odoo: definem campos, relações entre registos e a lógica de negócio aplicada.
Este artigo aprofunda um dos modelos mais relevantes do Odoo: product.product. Se estiver a desenvolver módulos personalizados, a integrar sistemas externos ou a configurar catálogos, vai cruzar-se frequentemente com este modelo.
O que é o modelo product.product
O product.product representa as variantes concretas de um produto no Odoo. São os artigos reais que entram em encomendas de venda, compras e movimentos de armazém — os identificáveis e transacionáveis.
Este modelo difere do product.template: o template contém os atributos comuns a toda uma família de produtos, enquanto o product.product corresponde a cada variante específica. Num produto sem variantes, existe uma única variante associada ao template; num produto configurável (por exemplo, uma camisola com cor e tamanho), cada combinação é um registo product.product distinto.
O modelo pertence ao módulo product e é referenciado por Vendas, Compras, Stock e comércio eletrónico. Sempre que se adiciona uma linha a um orçamento ou se recebe mercadoria, está-se a trabalhar com registos de product.product.
O product.product utiliza delegação a partir do product.template: muitos campos estão definidos no template e são herdados pelas variantes. Isso mantém os dados partilhados centralizados no template, permitindo ao mesmo tempo que as variantes tenham campos específicos.
Campos-chave do modelo
A seguir encontra-se uma lista dos campos mais relevantes do product.product. Conhecê-los facilita a gestão de variantes e a integração com outros processos do ERP.
1. name
Tipo: Char. Nome da variante do produto. É o campo exibido em listas, formulários e documentos. Em produtos simples coincide com o nome do template; em variantes costuma incluir os valores de atributos (por exemplo, "Camisola — Azul / M").
2. product_tmpl_id
Tipo: Many2one (product.template). Liga a variante ao seu template pai. É a relação central: cada product.product pertence a exatamente um product.template. Use-a sempre que precisar de relacionar lógica ou heranças entre template e variantes.
3. default_code
Tipo: Char. Referência interna ou SKU. Serve para identificação, procura por código de artigo e integração com sistemas externos. Cada variante pode ter o seu próprio código.
4. barcode
Tipo: Char. Código de barras (EAN, UPC, etc.). Utilizado em POS, armazém e inventário para scans rápidos. Deve ser único entre produtos quando definido.
5. create_date
Tipo: Datetime. Data e hora de criação do registo. Gerido automaticamente pelo Odoo e útil para auditorias e relatórios.
6. write_date
Tipo: Datetime. Data e hora da última alteração. Também gerido automaticamente e útil para controlar atualizações.
7. active
Tipo: Boolean. Sinalizador de arquivamento. Quando False o registo fica oculto nas vistas por defeito — evita eliminação física para preservar histórico.
8. type
Tipo: Selection. Tipo de produto: Consumível, Serviço ou Produto armazenable. Determina se é controlado em stock e que fluxos se aplicam (por exemplo, serviços não têm stock).
9. categ_id
Tipo: Many2one (product.category). Categoria do produto. Serve para organização do catálogo, regras de preço e relatórios. As categorias podem ter hierarquias.
10. list_price
Tipo: Float. Preço de venda sugerido. Mostrado em orçamentos e usado como valor por defeito ao adicionar linhas — pode ser alterado por tabelas de preços.
11. standard_price
Tipo: Float. Preço de custo. Usado na valorização de inventário e cálculo de margens. Normalmente atualizado por compras ou entrada manual.
12. uom_id
Tipo: Many2one (uom.uom). Unidade de medição para vendas e inventário: unidades, kg, litros, etc. Define como as quantidades são expressas.
13. uom_po_id
Tipo: Many2one (uom.uom). Unidade de compra. Pode diferir da uom_id (por exemplo, compra em caixas e venda em unidades); as conversões são tratadas automaticamente.
14. description_sale
Tipo: Html. Descrição para venda. Aparece em orçamentos, encomendas e faturas, e pode incluir formatação e detalhes úteis ao cliente.
15. description_purchase
Tipo: Html. Descrição para compras. Visível em ordens de compra e faturas de fornecedor, usada para comunicação com fornecedores.
16. sale_ok
Tipo: Boolean. Indicador se o produto pode ser vendido. Quando False fica oculto nas vendas e no e-commerce — útil para artigos apenas de compra ou internos.
17. purchase_ok
Tipo: Boolean. Indicador se o produto pode ser comprado. Quando False não aparece nas linhas de compra — útil para produtos apenas fabricados ou vendidos.
18. image_1920
Tipo: Binary. Imagem do produto em alta resolução. O Odoo armazena várias versões (image_512, image_256, etc.) para exibição em formulários, loja online e relatórios.
19. weight
Tipo: Float. Peso do produto. Usado em cálculo de portes e logística; a unidade depende da configuração da empresa.
20. volume
Tipo: Float. Volume do produto. Relevante para cálculo de transporte e capacidade de armazém em operações com restrições volumétricas.
21. company_id
Tipo: Many2one (res.company). Em ambientes multi-empresa indica a empresa proprietária do produto, afetando visibilidade e stocks.
22. currency_id
Tipo: Many2one (res.currency). Moeda aplicada a list_price e standard_price. Geralmente a moeda da empresa; as tabelas de preço fazem conversões para outras moedas.
23. qty_available
Tipo: Float. Quantidade física disponível. Campo calculado a partir dos quants; apenas leitura. Usado para verificações de disponibilidade e relatórios (aplica-se a produtos armazáveis).
24. virtual_available
Tipo: Float. Projecção de stock (disponível + entradas previstas − saídas previstas). Campo calculado e de leitura, útil para planeamento e reposição.
25. product_template_attribute_value_ids
Tipo: Many2many. Liga a variante aos valores de atributo que a definem (por exemplo, Cor=Azul, Tamanho=M). Essencial para configurar variantes e filtros.
26. sequence
Tipo: Integer. Ordem de apresentação. Usado para ordenar produtos em listas e configuradores; valores mais baixos aparecem primeiro.
27. display_name
Tipo: Char. Nome de exibição calculado. Combina o nome com os atributos da variante — usado em dropdowns many2one e pesquisas. Campo somente leitura.
28. responsible_id
Tipo: Many2one (res.users). Pessoa responsável pelo produto. Utilizado para regras de reabastecimento e atribuições internas; é opcional.
Como este modelo entra nos fluxos de trabalho da empresa
1. Vendas e Orçamentos
Ao criar um orçamento, o vendedor escolhe uma variante (product.product) do catálogo. O preço padrão (list_price), a descrição de venda e a unidade de medida são transportados para a linha da encomenda; as tabelas de preço podem alterar o valor. Só aparecem produtos com sale_ok activo.
2. Compras e Fornecedores
Ordens de compra e faturas de fornecedor referenciam product.product. Os custos de compra tendem a atualizar o standard_price. Os produtos com purchase_ok activo ficam disponíveis para encomenda; a uom_po_id define a unidade em que se pede a mercadoria.
3. Inventário e Armazém
Movimentos de stock, pickings e quants trabalham com product.product. Campos como qty_available e virtual_available orientam decisões de disponibilidade. Apenas produtos do tipo armazenable são rastreados; o campo barcode facilita leituras por scanner.
4. Comércio eletrónico e Website
A loja online apresenta registos de product.product. Variantes com atributos distintos aparecem como opções (tamanho, cor). Imagens, descrições e preços vêm do modelo; o campo sale_ok controla se aparecem publicamente.
5. Fabrico e MRP
As listas de materiais (BOM) apontam para product.product tanto para componentes como para produtos finais. O tipo de produto indica se deve ser fabricado ou consumido, e os níveis de stock alimentam o planeamento de produção.
Como os programadores estendem este modelo
Os programadores estendem o product.product recorrendo a vários padrões; a herança de modelos do Odoo é o método principal.
Herança de modelo
Use _inherit = 'product.product' para estender o modelo: acrescente campos, sobrescreva métodos ou estabeleça restrições. Mantendo as alterações num módulo separado facilita upgrades. Decida colocar o campo no template (partilhado) ou na variante (específico) conforme o âmbito do dado.
Adicionar campos
Defina novos campos no modelo herdado usando o tipo adequado (Char, Many2one, Boolean, Integer, Text, Selection). Avalie se o campo deve existir no template (reutilizável) ou na variante (por exemplo, SKU ou código de barras específicos da variante).
Extensões em Python
Sobrescreva create, write ou unlink para introduzir lógica adicional, chamando sempre super() para manter o comportamento base. Tenha atenção às dependências de campos computados — o product.product integra muitos campos calculados por módulos de stock e venda.
Odoo Studio
O Odoo Studio permite adicionar campos sem programar, ideal para alterações rápidas. Para requisitos complexos ou soluções duráveis, recomenda-se criar módulos personalizados. A API do modelo está acessível via XML-RPC e JSON-RPC para integrações externas.
Boas práticas
- Use default_code ou barcode como chave de mapeamento com sistemas externos — mantenha-os únicos e consistentes.
- Defina corretamente o tipo de produto: Consumível, Armazável ou Serviço. Essa escolha altera os fluxos e módulos aplicáveis.
- Em integrações via API, utilize product.product para linhas de encomenda e transações; recorra ao product.template para operações a nível de catálogo.
- Para campos personalizados, prefixe com x_ ou com o prefixo do módulo para evitar colisões com futuras versões do Odoo.
- Prefira product.template se o campo for aplicável a todas as variantes (por exemplo, marca ou categoria). Use product.product para dados que variam por variante, como um código de barras específico.
Erros frequentes
- Considere herdar product.template quando a lógica for por template e product.product para comportamentos por variante.
- Evite criar registos product.product manualmente fora do configurador para produtos com variantes — a criação via configurador garante que os atributos e combinações fiquem consistentes.
- Esquecer de ativar sale_ok ou purchase_ok. Em algumas configurações, produtos ficam por defeito ocultos nas vendas ou compras se esses flags não estiverem definidos.
- Sobrescrever métodos centrais sem chamar super(). Isto pode causar comportamentos inesperados e dificultar atualizações e compatibilidades com outros módulos.
- Usar product.product em domínios quando a filtragem adequada é ao nível do template (por exemplo, categorias aplicadas ao template). Escolha o modelo certo para cada filtro.
Conclusão
O modelo product.product é um pilar da arquitetura de produtos do Odoo: define os artigos efetivamente vendíveis e compráveis. Conhecer os seus campos e a relação com product.template facilita a configuração, personalização e integração do sistema.
Seja a trabalhar no mapeamento de catálogos como consultor funcional ou a desenvolver módulos personalizados, dominar o product.product poupa tempo e evita erros operacionais.
Precisa de ajuda com a sua implementação Odoo?
A Dasolo ajuda empresas a implementar, personalizar e otimizar Odoo, com especial foco em integrações via API e desenvolvimento de módulos. A nossa equipa tem experiência profunda na arquitetura de dados do Odoo e em modelos como o product.product.
Se precisa de apoio na sua implementação Odoo, nos módulos personalizados ou nas integrações, podemos ajudar. Agende uma demonstração para conversar sobre o seu projeto.