Introducción
En Odoo, los modelos son las plantillas que organizan y guardan la información en la base de datos. Todo dato de negocio —pedidos, facturas, productos— se almacena siguiendo la estructura de un modelo concreto, que define qué campos existen y cómo se relacionan entre sí.
Comprender los modelos de Odoo es imprescindible tanto para desarrolladores como para consultores funcionales. Son la columna vertebral de la arquitectura: fijan campos, relaciones y la lógica de negocio. Aunque cada modelo tiene su propósito, todos siguen patrones comunes que facilitan la extensión y el mantenimiento.
En este texto nos centramos en uno de los modelos más relevantes: product.template. Si trabajas configurando catálogos, desarrollando módulos personalizados o integrando sistemas externos, acabarás interactuando con este modelo de forma habitual.
¿Qué es el modelo product.template?
product.template agrupa productos que comparten la mayoría de sus características y difieren solo en aspectos puntuales (por ejemplo, talla o color). En lugar de duplicar información, Odoo utiliza la plantilla para centralizar lo común y variantes para las diferencias.
Este modelo está presente en Ventas, Compras, Inventario, Comercio electrónico y Fabricación. Crear un artículo en el catálogo genera un registro product.template; al vender o mover stock se elige la variante concreta que hereda los datos del template.
El modelo se define en el módulo de producto y el resto de módulos lo amplía mediante herencia. Ventas incorpora precios y facturación; Compras añade gestión de proveedores; Inventario aporta seguimiento de stock. Así cada módulo enriquece lo necesario sin reescribir la base.
Distinguir product.template de product.product es fundamental: la plantilla contiene los datos compartidos, mientras que product.product almacena la información propia de cada variante —como el código de barras o el SKU— que puede variar entre versiones del mismo producto.
Campos clave del modelo
A continuación se enumeran los campos más relevantes de product.template. Conocerlos te ayudará a manejar productos correctamente dentro de Odoo.
1. name
Tipo: Char. Nombre comercial del producto. Es el campo principal que aparece en listados, búsquedas y documentos; sirve como identificador legible para usuarios y clientes.
2. create_date
Tipo: Datetime. Fecha y hora de creación del registro. Odoo la gestiona automáticamente y resulta útil para auditoría e informes temporales.
3. write_date
Tipo: Datetime. Fecha y hora de la última modificación. También gestionada automáticamente; facilita el seguimiento de cambios y sincronizaciones.
4. active
Tipo: Boolean. Indicador de activación/archivo. Si está en False, el registro queda archivado y no aparece por defecto en las vistas, sin borrarse físicamente de la base de datos.
5. sequence
Tipo: Integer. Orden de visualización. Se usa para ordenar listados y desplegables; los valores menores aparecen antes que los mayores.
6. type
Tipo: Selection. Clasifica el producto: Consumible, Servicio o Producto almacenable. Los consumibles no se gestionan en stock; los servicios no tienen inventario físico; los almacenables sí se rastrean en inventario.
7. categ_id
Tipo: Many2one (product.category). Categoría del producto. Influye en informes, rutas por defecto y organización del catálogo; las categorías pueden estructurarse jerárquicamente.
8. list_price
Tipo: Float. Precio de venta por defecto. Se utiliza al generar presupuestos; puede ser modificado por listas de precios o tarifas específicas por variante.
9. standard_price
Tipo: Float. Precio de coste. Sirve para calcular márgenes y valorar inventario; impacta en los informes de rentabilidad.
10. currency_id
Tipo: Many2one (res.currency). Divisa del list_price y standard_price. Normalmente se hereda de la compañía y define la unidad monetaria de los precios.
11. uom_id
Tipo: Many2one (uom.uom). Unidad de medida para ventas. Define cómo se expresan cantidades (Unidades, Kg, Litros, etc.).
12. uom_po_id
Tipo: Many2one (uom.uom). Unidad de medida para compras. Puede diferir de uom_id y permitir conversiones entre lo que se compra y lo que se vende.
13. default_code
Tipo: Char. Referencia interna o código SKU. Muy útil para mapeos con sistemas externos y para identificación rápida en procesos logísticos.
14. barcode
Tipo: Char. Código de barras para escaneo. Se utiliza en TPV, almacén y control de inventario; en productos con variantes el código suele guardarse en product.product.
15. description
Tipo: Char. Descripción interna. Visible solo para usuarios internos y útil como nota o recordatorio en procesos internos.
16. description_sale
Tipo: Text. Descripción comercial. Se muestra en presupuestos y facturas; admite formato HTML para enriquecer la presentación al cliente.
17. description_purchase
Tipo: Text. Descripción para compras. Aparece en pedidos de compra y facturas de proveedor; facilita la comunicación con suministradores.
18. sale_ok
Tipo: Boolean. Indica si el producto puede venderse. Si está en False, no aparece en formularios de venta ni presupuestos.
19. purchase_ok
Tipo: Boolean. Indica si el producto puede comprarse. Si está en False, no está disponible en formularios de compra.
20. weight
Tipo: Float. Peso del producto. Se utiliza en cálculos de envío y logística; la unidad depende de la configuración de UoM de la empresa.
21. volume
Tipo: Float. Volumen del producto. Útil para planificación de bodega y cálculo de ocupación en almacenes.
22. product_variant_ids
Tipo: One2many (product.product). Lista de variantes asociadas al template. Cada variante hereda información compartida y añade sus propios atributos.
23. product_variant_count
Tipo: Integer. Número de variantes. Campo calculado a partir de product_variant_ids; se usa para mostrar y filtrar listados.
24. image_1920
Tipo: Binary. Imagen del producto. Odoo guarda varias resoluciones; la imagen se usa en formularios, catálogos y la web.
25. responsible_id
Tipo: Many2one (res.users). Usuario responsable del producto. Útil para asignar tareas, aprobaciones y la gestión operativa del catálogo.
26. company_id
Tipo: Many2one (res.company). Compañía propietaria del producto en entornos multiempresa; determina políticas y contabilidad asociada.
27. tax_ids
Tipo: Many2many (account.tax). Impuestos aplicables a la venta. Se usan en presupuestos y facturación para calcular el IVA u otros tributos.
28. supplier_tax_id
Tipo: Many2many (account.tax). Impuestos en compras. Se aplican en facturas de proveedor y afectan el tratamiento contable de las compras.
29. attribute_line_ids
Tipo: One2many. Líneas de atributos que generan variantes. Aquí se definen atributos como Talla o Color que combinados crean product.product distintos.
30. route_ids
Tipo: Many2many (stock.route). Rutas logísticas. Definen cómo se gestiona el flujo del producto (Comprar, Fabricar bajo pedido, Reabastecer), influyendo en operaciones de stock.
31. property_stock_production
Tipo: Many2one (stock.location). Ubicación de producción para productos fabricados. Se emplea cuando el producto es almacenable y la ruta incluye fabricación.
32. property_stock_inventory
Tipo: Many2one (stock.location). Ubicación por defecto para ajustes de inventario. Utilizado en recuentos y correcciones de stock.
33. property_valuation
Tipo: Selection. Método de valoración: Automatizada o Manual. Define cómo se registran las variaciones de coste en la contabilidad de inventarios.
34. property_cost_method
Tipo: Selection. Método de coste: Standard o FIFO. Afecta al cálculo del valor de inventario y a la trazabilidad de costes.
35. property_account_income_id
Tipo: Many2one (account.account). Cuenta de ingresos para ventas. Se usa al facturar para asignar el ingreso contable correcto.
36. property_account_expense_id
Tipo: Many2one (account.account). Cuenta de gastos para compras. Se emplea en facturas de proveedor para contabilizar gastos del producto.
37. invoice_policy
Tipo: Selection. Política de facturación: Por cantidad pedida o por cantidad entregada. Influye en el momento en que se reconoce el ingreso.
38. expense_policy
Tipo: Selection. Política de imputación de costes: Por pedido o por entrega. Afecta al momento en que se contabilizan los costes.
39. service_type
Tipo: Selection. Para servicios: Manual, Timesheet o Hitos. Determina cómo se registran y facturan los servicios.
40. optional_product_ids
Tipo: Many2many (product.template). Productos opcionales para venta cruzada o upsell. Se muestran al añadir el artículo a un presupuesto para sugerir complementos.
Cómo se usa este modelo en los procesos de negocio
1. Ventas y presupuestos
Cuando un comercial prepara un presupuesto, busca artículos en el catálogo y selecciona el template base; si el producto tiene atributos, elegirá la variante concreta (por ejemplo, la talla o el color) antes de confirmar la línea de pedido.
2. Comercio electrónico
En la tienda online los clientes navegan por plantillas de producto; al abrir una ficha, ven la descripción e imágenes comunes y seleccionan la variante que desean comprar desde las opciones disponibles.
3. Compras y proveedores
Los pedidos de compra y las facturas de proveedor se asocian al producto. El campo purchase_ok controla si aparece en formularios de compra; además, supplier_tax_id y uom_po_id condicionan el comportamiento al pedir a proveedores.
4. Inventario y fabricación
Los movimientos de stock y las órdenes de fabricación operan sobre variantes concretas. El template define rutas, valoración y método de coste; el seguimiento físico se hace por cada variant.
5. Facturación
Las facturas recogen líneas de producto que referencian la definición del template para impuestos y cuentas contables. La política de facturación del producto decide cuándo se reconoce el ingreso.
Cómo amplían los desarrolladores este modelo
Los desarrolladores amplían product.template aplicando patrones de herencia propios de Odoo. Hay varias estrategias para introducir campos, reglas y lógica adicional sin tocar el núcleo.
Herencia del modelo
Usa _inherit = 'product.template' para extender el modelo. Así añades campos, reescribes métodos o estableces restricciones manteniendo los cambios en un módulo aparte; es la forma estándar de ampliar Odoo sin modificar el código original.
Añadir campos
Declara nuevos campos en el modelo heredado empleando tipos adecuados: Char, Many2one, Boolean, Integer, Text, Selection, etc. Ten en cuenta si los datos deben ser dependientes de compañía en entornos multiempresa.
Extensiones en Python
Sobrescribe create, write o unlink para introducir lógica personalizada, pero siempre llama a super() para preservar el comportamiento base. Presta atención a los campos computados y sus dependencias para evitar inconsistencias.
Odoo Studio
Odoo Studio permite crear campos y vistas sin programar, ideal para cambios rápidos. Para lógica compleja o necesidades que perduren en el tiempo, es preferible un módulo personalizado para facilitar mantenimiento y migraciones.
Buenas prácticas
- Coloca correctamente los datos compartidos y los específicos: usa el template para lo común y product.product para las propiedades que cambian entre variantes (códigos, códigos de barras, niveles de stock).
- Asigna categ_id con criterio: las categorías influyen en rutas, cuentas y reportes automáticos, así que mantener una taxonomía coherente evita sorpresas operativas.
- Utiliza default_code como identificador para integraciones externas. Mantenerlo único y estable simplifica sincronizaciones con ERPs, marketplaces o soluciones logísticas.
- Para integraciones por API emplea XML-RPC o JSON-RPC según tu stack. product.template está disponible vía API: planifica el mapeo de identificadores externos y gestiona bien los IDs para evitar colisiones.
- Al crear campos personalizados, usa prefijos (x_ o el prefijo del módulo) para minimizar conflictos con futuras versiones de Odoo y facilitar la identificación del origen de cada campo.
Errores habituales
- Crear plantillas duplicadas en lugar de usar variantes. Si las diferencias son solo atributos como color o talla, usa attribute_line_ids para generar variantes en lugar de replicar templates.
- Confundir product.template con product.product. Si necesitas datos por variante (barcode, SKU, stock), almacénalos en product.product; usar el lugar equivocado genera errores funcionales y de inventario.
- Olvidar activar sale_ok o purchase_ok. Productos con esos flags en False no aparecen en los formularios correspondientes y pueden romper procesos comerciales si no se revisan.
- Sobrescribir métodos del core sin llamar a super(). Esto puede romper la compatibilidad con otros módulos y complicar futuras actualizaciones del sistema.
- Agregar campos obligatorios sin un valor por defecto. Al actualizar módulos, los registros existentes pueden fallar validaciones si falta un valor en campos requeridos.
Conclusión
product.template es un pilar de Odoo: centraliza la definición de productos y los atributos compartidos. Dominar sus campos y entender cómo se extiende te permitirá configurar, personalizar e integrar Odoo de forma eficiente.
Tanto si eres consultor funcional que mapea catálogos como si eres desarrollador creando módulos, conocer a fondo product.template te ahorrará tiempo y reducirá errores en producción.
Comienza con Dasolo
Dasolo acompaña a empresas en la implementación, personalización y optimización de Odoo. Nos especializamos en integraciones API y desarrollo a medida; nuestro equipo tiene experiencia profunda con la arquitectura de datos y modelos como product.template.
Si necesitas apoyo con tu implementación de Odoo, módulos personalizados o integraciones, podemos ayudarte a diseñar la solución y ejecutarla. Solicita una demo para comentar tu proyecto.