Introducción
En Odoo, los modelos funcionan como planos: definen cómo se organiza y almacena cada dato en la base. Todo lo relacionado con la actividad —pedidos, movimientos de almacén, fichas de producto— se guarda dentro de modelos que estructuran esos datos y sus relaciones.
Tanto para consultores funcionales como para programadores, comprender los modelos de Odoo es imprescindible. Son la base sobre la que se declaran campos, vínculos entre objetos y la lógica que gobierna el comportamiento de la aplicación.
Vamos a centrarnos en uno de los modelos más utilizados: product.product. Si trabajas con módulos a medida, sincronizas catálogos o configuras la tienda online, acabarás manipulando este modelo a diario.
¿Qué es el modelo product.product?
El modelo product.product representa las variantes concretas de producto: los ítems que realmente se venden, compran y se mueven por el almacén. Es la entidad que aparece en líneas de pedido, albaranes y facturas.
Es distinto de product.template: la plantilla contiene atributos compartidos por una familia de productos, mientras que product.product recoge cada variante específica. Un producto sin variantes tendrá un solo product.product ligado al template; un artículo configurable tendrá tantas variantes como combinaciones de atributos (talla, color, etc.).
El modelo se define en el módulo product y es referenciado por Ventas, Compras, Inventario y e‑commerce. Cada vez que añades una línea a una cotización o registras una recepción, trabajas con registros de product.product.
product.product hereda por delegación de product.template: muchos campos comunes residen en la plantilla y los variantes los reutilizan. Esto permite tener datos compartidos centralizados y a la vez sobrescribir valores específicos por variante.
Campos clave del modelo
A continuación explicamos los campos más relevantes de product.product. Conocerlos te ayudará a gestionar variantes, sincronizaciones y reglas comerciales de forma correcta.
1. name
Tipo: Char. Nombre de la variante, visible en listados y documentos. En productos simples coincide con el nombre de la plantilla; en variantes suele combinarse con valores de atributos (por ejemplo, "Camiseta — Azul / M").
2. product_tmpl_id
Tipo: Many2one (product.template). Relación con la plantilla padre. Es la conexión esencial: cada variante pertenece a una única plantilla y se usa para heredar campos compartidos o ampliar la lógica desde la plantilla.
3. default_code
Tipo: Char. Referencia interna o SKU. Se emplea para identificación, búsquedas por código y sincronizaciones con sistemas externos. Cada variante puede disponer de su propio SKU.
4. barcode
Tipo: Char. Código de barras (EAN, UPC, etc.). Se utiliza en puntos de venta, almacén y escaneo. Debe ser único entre productos cuando está definido.
5. create_date
Tipo: Datetime. Fecha y hora de creación del registro. Odoo lo gestiona automáticamente y es útil para auditorías e informes.
6. write_date
Tipo: Datetime. Fecha de la última modificación. También gestionada automáticamente; permite saber cuándo se actualizó por última vez el registro.
7. active
Tipo: Boolean. Indicador de visibilidad (archivo lógico). Si está a False, el producto se oculta de vistas por defecto sin eliminarse, manteniendo el histórico.
8. type
Tipo: Selection. Tipo de producto: Consumible, Servicio o Producto Almacenable. Determina si se controla stock y qué flujos aplican (por ejemplo, servicios no tienen stock).
9. categ_id
Tipo: Many2one (product.category). Categoría del producto. Se usa para informes, reglas de precio y organización del catálogo; las categorías pueden formar jerarquías.
10. list_price
Tipo: Float. Precio de venta por defecto. Se muestra en cotizaciones y sirve de base hasta que lo modifiquen listas de precio o reglas comerciales.
11. standard_price
Tipo: Float. Precio de coste. Afecta la valoración de inventario y el cálculo de márgenes; se actualiza desde compras o mediante entradas manuales.
12. uom_id
Tipo: Many2one (uom.uom). Unidad de medida para ventas e inventario (unidad, kg, litro…). Define cómo se expresan las cantidades en operaciones comerciales y logísticas.
13. uom_po_id
Tipo: Many2one (uom.uom). Unidad de compra. Puede diferir de la unidad de venta (por ejemplo, comprar por cajas y vender por unidades); Odoo gestiona la conversión entre unidades.
14. description_sale
Tipo: Html. Descripción para ventas. Se muestra en cotizaciones, pedidos y facturas; admite formato y detalle del producto para el cliente.
15. description_purchase
Tipo: Html. Descripción para compras. Aparece en órdenes de compra y facturas de proveedor para comunicar especificaciones o instrucciones de aprovisionamiento.
16. sale_ok
Tipo: Boolean. Indica si el producto puede venderse. Si está a False, se oculta en ventas y e‑commerce —útil para artículos solo de compra o uso interno.
17. purchase_ok
Tipo: Boolean. Indica si el producto puede comprarse. Si está a False, no aparece en procesos de compra —útil para productos fabricados internamente o solo comercializados.
18. image_1920
Tipo: Binary. Imagen a resolución completa. Odoo genera varias versiones (image_512, image_256...) para mostrar en formularios, tienda online e informes.
19. weight
Tipo: Float. Peso del producto. Se usa en cálculos de envío y logística; la unidad depende de la configuración de la compañía.
20. volume
Tipo: Float. Volumen del producto. Importante para transporte y capacidad de almacén cuando hay restricciones volumétricas.
21. company_id
Tipo: Many2one (res.company). Empresa propietaria del producto en entornos multiempresa; condiciona visibilidad y stock por compañía.
22. currency_id
Tipo: Many2one (res.currency). Moneda asociada a list_price y standard_price; normalmente la moneda de la empresa, aunque las listas de precio pueden convertir a otras monedas.
23. qty_available
Tipo: Float. Cantidad disponible en stock. Campo computado a partir de quants, solo lectura; sirve para comprobaciones de disponibilidad en productos almacenable.
24. virtual_available
Tipo: Float. Cantidad prevista: stock disponible más entradas menos salidas. Campo computado que ayuda en decisiones de reposición y planificación.
25. product_template_attribute_value_ids
Tipo: Many2many. Relación con los valores de atributo que definen la variante (por ejemplo, Color=Azul, Talla=M). Se usa para configurar variantes y filtrar productos.
26. sequence
Tipo: Integer. Orden de visualización. Determina el orden en listados y configuradores; los valores más bajos aparecen antes.
27. display_name
Tipo: Char. Nombre mostrado calculado. Combina el nombre con los atributos de la variante y se utiliza en desplegables y resultados de búsqueda; es de solo lectura.
28. responsible_id
Tipo: Many2one (res.users). Persona responsable del producto. Se usa para reglas de aprovisionamiento y asignaciones internas; es opcional.
Cómo se utiliza este modelo en los procesos de negocio
1. Ventas y cotizaciones
Al crear una cotización, el comercial selecciona una variante (product.product). El precio base, la descripción y la unidad de medida se copian a la línea; las listas de precio pueden ajustar el importe. Solo aparecen productos con sale_ok activo.
2. Compras y proveedores
Órdenes de compra y facturas de proveedor referencian variantes. El coste estándar suele actualizarse desde las recepciones o facturas de compra y la uom_po_id define cómo se pide (por ejemplo, por caja). Solo se usan productos con purchase_ok activo.
3. Inventario y almacén
Movimientos, albaranes y quants usan product.product. Los campos qty_available y virtual_available guían la disponibilidad; solo los productos almacenables se rastrean por cantidad. El escaneo por código de barras facilita búsquedas rápidas en almacén.
4. Comercio electrónico y web
La tienda online muestra registros de product.product. Las variantes aparecen como opciones (talla, color) y la imagen, la descripción y el precio proceden del modelo. El flag sale_ok controla si un artículo es visible en la web.
5. Fabricación y MRP
Las listas de materiales enlazan con variantes tanto para componentes como para producto final. El campo type determina si un producto se fabrica (almacenable) o se consume, y los niveles de stock influyen en la planificación de producción.
Cómo amplían los desarrolladores este modelo
Los desarrolladores amplían product.product mediante distintos patrones, aprovechando el sistema de herencia de modelos de Odoo y las extensiones por módulo.
Herencia de modelos
Para añadir campos o cambiar comportamiento usa _inherit = 'product.product'. Así incorporas campos nuevos, sobrescribes métodos o añades restricciones manteniendo las modificaciones en módulos independientes, lo que facilita actualizaciones. Decide si el dato corresponde a la plantilla (compartido) o a la variante (específico) antes de elegir product.template o product.product.
Añadir campos
Declara nuevos campos en tu herencia usando los tipos adecuados (Char, Many2one, Boolean, Integer, Text, Selection…). Piensa si el dato debe aplicarse a todas las variantes (iría en la plantilla) o solo a cada SKU (iría en la variante). Campos como SKU o códigos de barras específicos por variante deben añadirse en product.product.
Extensiones en Python
Sobrescribe métodos como create, write o unlink para incorporar lógica. Llama siempre a super() para conservar el comportamiento base. Ten cuidado con campos computados y sus dependencias: product.product recibe funciones calculadas desde módulos como stock o sale.
Odoo Studio
Odoo Studio permite añadir campos y vistas sin programar, ideal para cambios rápidos. Para lógica compleja y proyectos mantenibles a largo plazo, un módulo personalizado es preferible. La API de Odoo (XML‑RPC/JSON‑RPC) expone product.product para integraciones externas.
Buenas prácticas
- Usa default_code o barcode como claves de enlace para sistemas externos y mantén consistencia y unicidad en esos identificadores.
- Configura bien el campo type para cada artículo: si es consumible, servicio o producto almacenable. Esa elección define qué flujos y módulos son relevantes.
- En integraciones por API, emplea product.product para líneas de pedido y transacciones y product.template para operaciones a nivel de catálogo o familia de producto.
- Al crear campos personalizados, aplica prefijos como x_ o añade el prefijo del módulo para evitar choques con futuras versiones y otros módulos.
- Si un dato aplica a todas las variantes (marca, categoría principal), añádelo en product.template. Para información propia de cada SKU (código de barras por variante, cantidad mínima por variante), usa product.product.
Errores frecuentes
- Evita heredar product.template cuando lo que necesitas afecta solo a variantes: elige product.product para comportamientos por variante y product.template para propiedades compartidas.
- No crear variantes manualmente de forma inconsistente: si el producto es configurable, genera variantes mediante el configurador para asegurar relaciones correctas con atributos y plantillas.
- Olvidar activar sale_ok o purchase_ok puede ocultar productos de ventas o compras según la configuración; comprueba estos flags al importar catálogos.
- Sobrescribir métodos centrales sin invocar super() puede romper la integración con otros módulos y dificultar actualizaciones futuras.
- Usar product.product en dominios cuando en realidad se busca filtrar por datos de plantilla (por ejemplo, categoría) puede producir resultados incorrectos; elige el modelo adecuado para cada condición.
Conclusión
product.product es el eje de la arquitectura de productos en Odoo: modela las unidades vendibles y comprables. Comprender su relación con product.template y sus campos clave te permitirá configurar, personalizar e integrar Odoo con menos errores.
Tanto si mapeas catálogos como si desarrollas módulos a medida, conocer bien product.product evita pérdidas de tiempo y problemas de sincronización entre sistemas.
¿Necesitas ayuda con tu implementación de Odoo?
Dasolo ayuda a empresas con implementaciones, personalizaciones y optimizaciones de Odoo. Somos especialistas en integraciones por API y desarrollo sobre la arquitectura de datos de Odoo, con amplia experiencia en modelos como product.product.
Si necesitas soporte para implementación, desarrollo de módulos personalizados o integraciones, podemos acompañarte en el proyecto. Solicita una demostración para hablar sobre tu proyecto.