Einleitung
In Odoo legen Modelle die Struktur der Geschäftsdaten fest: Sie bestimmen, welche Informationen gespeichert werden und wie sie in der Datenbank abgelegt sind. Ob Verkaufsbelege, Lagerstände oder Produktlisten — alles wird über passende Modelle organisiert.
Für Berater wie für Entwickler sind Modelle das zentrale Verständniswerkzeug: Sie bilden die Datenlogik, Beziehungen zwischen Objekten und Geschäftsregeln ab. Wer Odoo sinnvoll anpassen möchte, beginnt immer mit einem Blick auf die zugrunde liegenden Modelle.
Im Fokus dieses Beitrags steht eines der wichtigsten Produktmodelle: product.product. Egal ob Sie einen Shop einrichten, Bestellprozesse anbinden oder eigene Module bauen möchten — mit diesem Modell werden Sie regelmäßig arbeiten.
Was ist das Modell product.product?
Das Modell product.product bildet die konkreten Varianten eines Angebots ab. Es beschreibt die tatsächlich handelbaren Einheiten, die auf Angeboten, Bestellungen und in Lagerbewegungen verwendet werden.
product.product unterscheidet sich bewusst vom product.template: Die Template-Ebene fasst gemeinsame Eigenschaften einer Produktfamilie zusammen, die Produktvarianten (product.product) sind die konkreten Ausprägungen. Bei einfachen Artikeln gibt es pro Template genau eine Variante; bei konfigurierbaren Artikeln (z. B. Schuhe in Größe und Farbe) hat jede Kombination eine eigene product.product-Zeile.
Das Modell ist Teil des Kernmoduls für Produkte. Einkauf, Verkauf, Lager und Onlineshop greifen direkt auf product.product zu: Wenn Sie eine Position in einem Angebot anlegen oder Ware empfangen, arbeiten Sie mit Product-Variant-Datensätzen.
Technisch nutzt product.product in Odoo Delegationsvererbung vom Template. Viele Felder werden auf Template-Ebene definiert und von den Varianten genutzt – so bleiben gemeinsame Informationen zentral, während Varianten spezifische Werte überschreiben können.
Wichtige Felder im Modell
Im Folgenden liste ich die wichtigsten Felder des product.product-Modells auf. Wer diese Felder kennt, kann Varianten korrekt konfigurieren, filtern und in Prozesse einbinden.
1. name
Typ: Char. Bezeichnet die Namen der Varianten. In Listen, Formularen und Belegen sichtbar. Bei einfachen Artikeln entspricht der Name dem Template, bei Varianten enthält er oft Attribute (z. B. „T‑Shirt — Blau / M“).
2. product_tmpl_id
Typ: Many2one (product.template). Verknüpft die Variante mit ihrem Template. Diese Beziehung ist zentral: Jede Variante gehört genau zu einem Template und verweist auf die gemeinsamen Produktdaten.
3. default_code
Typ: Char. Interne Referenz (SKU). Dient der Identifikation, als Suchkriterium und für Integrationen. Varianten können eigene Artikelnummern haben.
4. barcode
Typ: Char. Barcode (EAN, UPC etc.). Dient dem Scannen im POS und Lager. Beim Setzen muss auf Eindeutigkeit geachtet werden, um Fehlscans zu vermeiden.
5. create_date
Typ: Datetime. Zeitpunkt der Anlage. Wird automatisch geführt und ist nützlich für Audits und zeitbasierte Auswertungen.
6. write_date
Typ: Datetime. Zeitpunkt der letzten Änderung. Ebenfalls automatisch gepflegt; hilft bei Änderungsverfolgung.
7. active
Typ: Boolean. Weiche Löschung/Archiv-Flag. Nicht aktive Produkte werden aus Standardansichten entfernt, bleiben aber für historische Belege erhalten.
8. type
Typ: Selection. Produktart: Verbrauchsartikel, Dienstleistung oder lagerfähiges Produkt. Diese Einstellung beeinflusst Inventar- und Bestellprozesse (z. B. Lagerführung oder Nicht-Lager-Artikel).
9. categ_id
Typ: Many2one (product.category). Produktkategorie für Reporting, Preisregeln und Katalogstruktur. Kategorien können hierarchisch verschachtelt sein.
10. list_price
Typ: Float. Verkaufspreis. Wird in Angeboten angezeigt und als Standardwert verwendet; kann durch Preislisten überschrieben werden.
11. standard_price
Typ: Float. Einstandspreis. Relevant für Bestandsbewertung und Margenberechnung; wird zumeist durch Einkäufe oder manuelle Anpassungen gepflegt.
12. uom_id
Typ: Many2one (uom.uom). Verkaufseinheit/Bestandseinheit. Definiert die Maßeinheit, in der Bestände und Verkäufe gerechnet werden (Stück, kg, l etc.).
13. uom_po_id
Typ: Many2one (uom.uom). Einkaufseinheit. Kann von der Verkaufseinheit abweichen (z. B. Einkauf in Kartons, Verkauf in Einheiten); Umrechnung erfolgt automatisch.
14. description_sale
Typ: Html. Verkaufsbeschreibung, die in Angeboten und Rechnungen erscheint. Ermöglicht formatierte Produkttexte und Hinweise für Kunden.
15. description_purchase
Typ: Html. Beschreibung für den Einkauf, die in Bestellungen und Lieferantenrechnungen angezeigt wird; dient der internen und externen Kommunikation.
16. sale_ok
Typ: Boolean. Verkaufbar‑Flag. Ist dieser Wert False, taucht das Produkt nicht in Verkaufs- und E‑Commerce‑Ansichten auf.
17. purchase_ok
Typ: Boolean. Einkaufbar‑Flag. Ist dieser Wert False, ist das Produkt nicht für Bestellvorgänge verfügbar.
18. image_1920
Typ: Binary. Hochaufgelöstes Produktbild. Odoo legt mehrere Größenvarianten ab (image_512, image_256 etc.) für unterschiedliche Anzeigezwecke.
19. weight
Typ: Float. Gewicht des Produkts, relevant für Versandkostenberechnung und Logistik; Einheit richtet sich nach Firmenkonfiguration.
20. volume
Typ: Float. Volumen des Artikels. Wichtig für Versandkalkulationen und Lagerkapazitätsplanung bei volumetrischen Beschränkungen.
21. company_id
Typ: Many2one (res.company). Zeigt bei Multi‑Company‑Setups an, welchem Unternehmen der Artikel gehört; beeinflusst Sichtbarkeit und Bestandsführung.
22. currency_id
Typ: Many2one (res.currency). Währung für list_price und standard_price; üblicherweise Firmenwährung, jedoch werden Preislisten in andere Währungen konvertiert.
23. qty_available
Typ: Float. Aktueller Lagerbestand (berechnet aus Quants). Nur lesbar. Wichtig für Verfügbarkeitsprüfungen und Lagerreports; nur bei lagerfähigen Produkten relevant.
24. virtual_available
Typ: Float. Voraussichtlicher Lagerstand (Ist‑Bestand plus Eingänge minus Ausgänge). Ebenfalls berechnet und lesbar; relevant für Bestellvorschläge.
25. product_template_attribute_value_ids
Typ: Many2many. Verknüpft die Attributwerte, die diese Variante definieren (z. B. Farbe=Blau, Größe=M). Grundlage für Variantenauswahl und Filter im Shop.
26. sequence
Typ: Integer. Reihenfolge‑Feld zur Darstellungssortierung. Kleinere Werte erscheinen zuerst, z. B. in Konfiguratoren oder Listen.
27. display_name
Typ: Char. Berechneter Anzeige‑Name, zusammengesetzt aus Namen und Attributen; wird in Many2one‑Dropdowns und Suche angezeigt (lesbar).
28. responsible_id
Typ: Many2one (res.users). Zuständiger Mitarbeiter für den Artikel, nützlich für Nachbestellregeln oder Aufgabenverantwortung; optional einsetzbar.
Wie dieses Modell in Geschäftsprozessen eingesetzt wird
1. Verkauf und Angebote
Beim Erstellen eines Angebots wählt der Verkäufer eine Variante aus dem Katalog. Artikelpreis, Verkaufsbeschreibung und Einheit fließen in die Positionszeile; Preislisten können den Preis noch anpassen. Nur Varianten mit sale_ok=True sind auswählbar.
2. Einkauf und Lieferanten
Bestellungen und Lieferantenrechnungen referenzieren Varianten. Einkaufspreise beeinflussen häufig den Standardpreis. Produkte mit purchase_ok=True sind über Bestellvorgänge verfügbar; die Einkaufseinheit (uom_po_id) steuert, in welchen Mengeneinheiten bestellt wird.
3. Lager und Logistik
Lagerbewegungen, Kommissionierung und Quants arbeiten mit Varianten. Die Felder qty_available und virtual_available steuern Verfügbarkeitsprüfungen. Nur lagerfähige Artikel werden inventarisch verwaltet. Barcodes beschleunigen die Identifikation beim Scannen.
4. E‑Commerce und Webseite
Der Onlineshop zeigt Varianten als auswählbare Optionen (Größe, Farbe). Bilder, Beschreibungen und Preise stammen aus dem Varianten‑Datensatz. Sichtbarkeit wird über das sale_ok‑Flag gesteuert.
5. Fertigung und Produktion (MRP)
Stücklisten und Produktionsaufträge referenzieren Varianten sowohl als Komponenten als auch als Fertigprodukte. Die Produktart entscheidet, ob ein Artikel produziert oder nur verbraucht wird; Bestände sind Grundlage für Produktionsplanung.
Wie Entwickler das Modell erweitern
Entwickler erweitern product.product auf unterschiedliche Weise; Odoo‑Modellvererbung ist dabei das zentrale Mittel.
Modellvererbung
Setzen Sie _inherit = 'product.product', um das Modell zu erweitern. So fügen Sie Felder hinzu, überschreiben Methoden oder implementieren Constraints. Änderungen in einer separaten Erweiterung sorgen für bessere Update‑Fähigkeit. Wählen Sie product.product für variantenspezifische Felder, product.template für gemeinsame Eigenschaften.
Felder hinzufügen
Ergänzen Sie Felder passend zum Datentyp: Char, Many2one, Boolean, Integer, Text, Selection. Entscheiden Sie vorher, ob ein Feld auf Template‑ oder Variantenebene gehört. Variantenspezifische Informationen wie individuelle SKUs oder Barcodes gehören auf product.product.
Python‑Erweiterungen
Überschreiben Sie Methoden wie create, write oder unlink, um zusätzliche Logik einzufügen — rufen Sie dabei stets super() auf. Achten Sie besonders auf berechnete Felder und deren Abhängigkeiten, denn product.product enthält viele berechnete Werte aus Lager und Verkauf.
Odoo Studio
Odoo Studio ermöglicht das schnelle Hinzufügen von Feldern ohne Code — praktisch für Prototypen. Für komplexe Anforderungen und Upgrade‑Sicherheit sind Custom‑Module jedoch langfristig stabiler. Die API (XML‑RPC/JSON‑RPC) bietet darüber hinaus vollständigen Zugriff für externe Integrationen.
Best Practices
- Für Integrationen: Verwenden Sie default_code oder barcode als eindeutige Zuordnungsschlüssel und sorgen Sie für Konsistenz und Eindeutigkeit über Systeme hinweg.
- Stellen Sie den Typ korrekt ein: Verbrauchsartikel, lagerfähiges Produkt oder Dienstleistung beeinflusst maßgeblich die anzuwendenden Workflows.
- Bei API‑Szenarien nutzen Sie product.product für Positions‑ und Transaktionsdaten; product.template eignet sich für katalogweite Änderungen oder Massenoperationen.
- Bei benutzerdefinierten Feldern empfehlen sich Präfixe wie x_ oder ein Modulpräfix, um Konflikte mit künftigen Odoo‑Versionen zu vermeiden.
- Wenn ein Feld alle Varianten betrifft (z. B. Marke, Kategorie), platzieren Sie es auf dem Template; sind die Daten variantenabhängig (z. B. abweichender Barcode), gehört es auf product.product.
Häufige Fehler
- Vermeiden Sie das Vererben vom Template, wenn variantenspezifisches Verhalten gefragt ist — für diese Fälle wählen Sie product.product, sonst verbleibt die Logik auf Template‑Ebene.
- Erzeugen Sie Varianten vorzugsweise über den Produktkonfigurator statt durch manuelles Anlegen einzelner product.product‑Einträge, um Inkonsistenzen zu vermeiden.
- Vergessen Sie nicht, sale_ok oder purchase_ok korrekt zu setzen — sonst sind Produkte in Shops oder Bestellmasken unsichtbar.
- Rufen Sie beim Überschreiben von Kernmethoden immer super() auf, um Seiteneffekte in anderen Modulen oder bei Upgrades zu verhindern.
- Achten Sie bei Domain‑Filtern auf die richtige Ebene: Häufig ist eine Filterung nach Template‑Informationen sinnvoller als nach product.product direkt.
Fazit
Das product.product‑Modell ist das Rückgrat der Produktlogik in Odoo: Es bildet die tatsächlichen, handelbaren Artikel ab. Wer das Zusammenspiel mit product.template und die wichtigsten Felder kennt, kann Odoo effektiver konfigurieren und anpassen.
Ob Sie Produkte modellieren, Schnittstellen bauen oder Module entwickeln — ein tiefes Verständnis der Variantenebene spart Zeit und reduziert Fehlerquellen.
Brauchen Sie Hilfe bei Ihrer Odoo-Einführung?
Dasolo unterstützt Unternehmen beim Einführen, Anpassen und Optimieren von Odoo. Unser Schwerpunkt liegt auf Integrationen und der Entwicklung robuster Odoo‑Lösungen; wir bringen Erfahrung mit Odoo‑Datenmodellen wie product.product mit.
Benötigen Sie Unterstützung bei Ihrer Odoo‑Einführung, kundenspezifischen Modulen oder Integrationen? Wir helfen Ihnen gerne weiter. Demo vereinbaren und Ihr Projekt besprechen.