Introduction
In Odoo, models define how data is structured and stored in the database. Every piece of business data you work with, from sales orders to invoices to products, lives in a model.
Understanding Odoo models is essential for both developers and functional consultants. Models are the foundation of the Odoo data architecture. They define Odoo fields, relationships, and business logic. Every model in Odoo follows the same patterns.
This article focuses on one of the most important models in Odoo: product.template. Whether you are building custom modules, integrating external systems, or configuring product catalogs, you will work with this model.
What is the product.template Model
The product.template model represents a group of similar products that differ only in a few properties, such as size or color. Rather than creating separate product records for each variation, products are organized into templates with variants.
This model in Odoo is used across Sales, Purchase, Inventory, E-commerce, and Manufacturing. When you create a product in the catalog, you are creating a product.template record. When you create a customer order, you select from product variants that inherit from the template.
The model is defined in the product module. Other modules extend it through Odoo model inheritance. Sale adds pricing and invoicing. Purchase adds vendor handling. Inventory adds stock tracking. Each module adds what it needs without duplicating the core structure.
Understanding the difference between product.template and product.product is key. The template holds shared data. The variant (product.product) holds variant-specific data like barcode and SKU.
Key Fields in the Model
Here are the most important Odoo fields in the product.template model. Understanding these will help you work effectively with products.
1. name
Type: Char. This field stores the name of the product. It is displayed in many Odoo views and is the primary identifier for the product template.
2. create_date
Type: Datetime. Stores the date and time when the record was created. Automatically managed by Odoo. Useful for reporting and auditing.
3. write_date
Type: Datetime. Stores the date and time of the last modification. Also automatically managed. Helps track when data was last updated.
4. active
Type: Boolean. Soft delete flag. When False, the record is archived and hidden from default views. Records are not physically deleted.
5. sequence
Type: Integer. Display order for sorting. Used in product lists and dropdowns. Lower values appear first.
6. type
Type: Selection. Product type: Consumable, Service, or Storable Product. Consumables are not tracked in stock. Services have no physical inventory. Storable products are tracked in inventory.
7. categ_id
Type: Many2one (product.category). The product category. Drives reporting, default routes, and catalog organization. Categories can be hierarchical.
8. list_price
Type: Float. The sales price. Used as default when creating quotations. Can be overridden by pricelists or variant-specific pricing.
9. standard_price
Type: Float. The cost price. Used for margin calculations and inventory valuation. Affects profitability reports.
10. currency_id
Type: Many2one (res.currency). The currency for list_price and standard_price. Usually inherited from the company.
11. uom_id
Type: Many2one (uom.uom). The unit of measure for sales. Defines how quantities are expressed (e.g. Units, Kg, Liters).
12. uom_po_id
Type: Many2one (uom.uom). The unit of measure for purchases. Can differ from uom_id for conversion scenarios.
13. default_code
Type: Char. Internal reference or code. Useful for external system mapping and custom numbering. Often used as SKU.
14. barcode
Type: Char. Barcode for scanning. Used in POS, warehouse, and inventory. For variants, barcode is typically on product.product.
15. description
Type: Char. Internal description. Visible to internal users only. Used for internal notes about the product.
16. description_sale
Type: Text. Sales description. Shown on quotations and invoices. Can include HTML for formatting.
17. description_purchase
Type: Text. Purchase description. Shown on purchase orders and vendor bills. Helps buyers communicate with suppliers.
18. sale_ok
Type: Boolean. Indicates whether the product can be sold. When False, the product is hidden from sales and quotation forms.
19. purchase_ok
Type: Boolean. Indicates whether the product can be purchased. When False, the product is hidden from purchase forms.
20. weight
Type: Float. Product weight. Used for shipping calculations and logistics. Unit depends on company UoM settings.
21. volume
Type: Float. Product volume. Used for logistics and warehouse capacity planning.
22. product_variant_ids
Type: One2many (product.product). The list of product variants. Each variant inherits from the template.
23. product_variant_count
Type: Integer. Number of variants. Computed from product_variant_ids. Used for display and filtering.
24. image_1920
Type: Binary. Product image. Odoo stores multiple sizes. Used in forms, reports, and the website.
25. responsible_id
Type: Many2one (res.users). The responsible user. Used for product management and activity assignment.
26. company_id
Type: Many2one (res.company). In multi-company setups, this indicates which Odoo company the product belongs to.
27. tax_ids
Type: Many2many (account.tax). Customer taxes for sales. Applied on invoices and quotations.
28. supplier_tax_id
Type: Many2many (account.tax). Vendor taxes for purchases. Applied on vendor bills.
29. attribute_line_ids
Type: One2many. Product attribute lines for variants. Defines which attributes (e.g. Size, Color) create variants.
30. route_ids
Type: Many2many (stock.route). Stock routes. Determines how the product moves through the supply chain (e.g. Buy, Make to Order).
31. property_stock_production
Type: Many2one (stock.location). Production location for manufactured products. Used when type is Storable and route includes manufacturing.
32. property_stock_inventory
Type: Many2one (stock.location). Inventory adjustment location. Used for stock counts and corrections.
33. property_valuation
Type: Selection. Inventory valuation method: Automated or Manual. Affects how cost is calculated.
34. property_cost_method
Type: Selection. Costing method: Standard or FIFO. Determines how inventory value is computed.
35. property_account_income_id
Type: Many2one (account.account). Income account for sales. Used when invoicing.
36. property_account_expense_id
Type: Many2one (account.account). Expense account for purchases. Used when receiving vendor bills.
37. invoice_policy
Type: Selection. When to invoice: Order quantities or Delivered quantities. Affects when revenue is recognized.
38. expense_policy
Type: Selection. When to expense: Ordered or Delivered. Affects when costs are recognized.
39. service_type
Type: Selection. For service products: Manual, Timesheet, or Milestones. Determines how services are tracked and invoiced.
40. optional_product_ids
Type: Many2many (product.template). Optional products for upsell. Shown when adding this product to a quotation.
How This Model Is Used in Business Workflows
1. Sales and Quotations
When a salesperson creates a quotation, they select products from the catalog. The product.template model provides the base product. Variants are chosen when the product has attributes (size, color).
2. E-commerce
On the website, customers see product templates in the catalog. When they click on a product, they can choose among variants. The template holds the shared description and images.
3. Purchase and Vendors
Purchase orders and vendor bills link to product.template. The purchase_ok field controls visibility. The supplier_tax_id and uom_po_id drive purchase behavior.
4. Inventory and Manufacturing
Stock moves and manufacturing orders reference product variants. The template defines routes, valuation, and cost method. Inventory is tracked per variant.
5. Invoicing
Invoices and bills reference product lines. The template provides tax rules and accounting accounts. Invoice policy determines when revenue is recognized.
How Developers Extend This Model
Developers extend product.template using several patterns. Odoo model inheritance is the main mechanism.
Model Inheritance
Use _inherit = 'product.template' to extend the model. This is Odoo model inheritance at work. Add new Odoo fields, override methods, or add constraints. The inherit model in Odoo keeps your changes in a separate module for easy upgrades. When you inherit a model in Odoo, you extend it without modifying the original.
Adding Fields
Define new Odoo fields in your inherited model. Use the right field type: Char, Many2one, Boolean, Integer, Text, Selection. Consider company-dependent fields for multi-company.
Python Extensions
Override create, write, or unlink to add logic. Use super() to call the original. Be careful with computed fields and their dependencies.
Odoo Studio
Odoo Studio lets you add fields without code. Good for quick customizations. For complex logic or upgrades, custom modules are more maintainable.
Best Practices
- Use the template-variant relationship correctly. Put shared data on the template, variant-specific data on product.product.
- Set categ_id for proper routing and reporting. Categories drive default behavior.
- Use default_code for external system mapping. Keep it unique when possible.
- When building API integrations, use the XML-RPC or JSON-RPC API. The product.template model is fully exposed as an API model in Odoo. Map external IDs carefully.
- For custom fields, use the
x_prefix or a module prefix to avoid conflicts with future Odoo versions.
Common Mistakes
- Creating duplicate templates instead of using variants. Use attribute_line_ids for products that differ only in size, color, etc.
- Mixing up product.template and product.product. When you need variant-specific data (barcode, SKU), use product.product.
- Forgetting to set sale_ok or purchase_ok. Products are hidden from forms when these are False.
- Overriding core methods without calling super(). This can break other modules or future upgrades.
- Adding required custom fields without defaults. Existing records will fail validation on upgrade.
Conclusion
The product.template model is central to Odoo. It stores product definitions and shared attributes. Understanding its fields and how modules extend it will help you configure, customize, and integrate Odoo effectively.
Whether you are a functional consultant mapping product catalogs or a developer building custom modules, a solid grasp of product.template will save time and prevent errors.
Get Started with Dasolo
Dasolo helps companies implement, customize, and optimize Odoo. We specialize in API integrations and Odoo development. Our team has deep experience with the Odoo data architecture and models like product.template.
If you need help with your Odoo implementation, custom modules, or integrations, we are here to help. Book a demo to discuss your project.