Einführung
In Odoo bestimmen Modelle die Form und Speicherung Ihrer Geschäftsdaten. Alle Informationen – von Angeboten über Rechnungen bis zu Artikeln – werden in Modelldatensätzen organisiert und nach festen Regeln abgelegt.
Ein gutes Verständnis der Odoo‑Modelle ist für Entwickler ebenso wichtig wie für funktionale Berater. Modelle bilden das Rückgrat der Datenstruktur: sie legen Felder, Beziehungen und Geschäftslogik fest. Praktisch jedes Modell folgt dabei denselben Gestaltungsprinzipien.
Dieser Beitrag konzentriert sich auf ein zentrales Modell: product.template. Ob Sie Module entwickeln, externe Systeme anbinden oder Ihren Produktkatalog aufbauen – früher oder später kommen Sie mit diesem Modell in Berührung.
Was das product.template‑Modell ist
Das product.template fasst eine Produktfamilie zusammen: Artikel, die sich nur in wenigen Merkmalen unterscheiden (z. B. Größe oder Farbe). Statt für jede Variante ein komplett eigenständiges Produkt anzulegen, modelliert man ein Template plus Varianten — das sorgt für Übersicht und weniger Redundanz.
Das Modell spielt in Verkauf, Einkauf, Lager, E‑Commerce und Fertigung eine Rolle. Ein angelegtes Produkt im Katalog ist immer ein product.template. In Vorgängen wie Kundenbestellungen wählen Anwender meist Varianten, die vom Template abgeleitet sind.
Die Kerndefinition liegt im Modul product; viele andere Module erweitern das Template per Modell‑Vererbung. So fügt Verkauf Preise und Rechnungslogik hinzu, Einkauf verwaltet Lieferanten, Lager verfolgt Bestände – ohne die zentrale Struktur zu duplizieren.
Wichtig ist die Unterscheidung zwischen product.template und product.product. Das Template enthält gemeinsame Attribute; product.product repräsentiert die konkrete Variante mit eigenen Angaben wie Barcode oder Artikelnummer.
Wichtige Felder im Modell
Im Folgenden finden Sie die wichtigsten Felder des product.template, kurz erklärt — diese Felder werden Sie häufig konfigurieren oder abfragen.
1. name
Typ: Char. Der sichtbare Produktname, der in Listen, Formularen und Druckvorlagen erscheint und als Hauptkennzeichen des Templates dient.
2. create_date
Typ: Datetime. Zeitstempel der Erstellung. Odoo pflegt diesen automatisch; sinnvoll für Reporting und Nachvollziehbarkeit.
3. write_date
Typ: Datetime. Letzte Änderungszeit. Ebenfalls automatisch verwaltet und nützlich zur Versionskontrolle von Daten.
4. active
Typ: Boolean. Archivierungsflag. Wenn False, wird das Template ausgeblendet, aber nicht gelöscht — praktisch für saisonale oder inaktive Artikel.
5. sequence
Typ: Integer. Steuerung der Anzeige‑Reihenfolge in Listen oder Drop‑Downs; kleinere Werte werden zuerst dargestellt.
6. type
Typ: Selection. Produktart: Verbrauchsartikel, Dienstleistung oder lagerführender Artikel. Legt z. B. fest, ob Lagerbestände geführt werden müssen.
7. categ_id
Typ: Many2one (product.category). Produktkategorie für Berichte, Standardrouten und Struktur im Katalog; Kategorien sind hierarchisch organisierbar.
8. list_price
Typ: Float. Standard‑Verkaufspreis, der als Ausgangswert in Angeboten verwendet wird und durch Preislisten überschrieben werden kann.
9. standard_price
Typ: Float. Einstandspreis bzw. Kostenwert; relevant für Margen, Lagerbewertung und Profitabilitätsanalysen.
10. currency_id
Typ: Many2one (res.currency). Währung, in der list_price und standard_price geführt werden — meist unternehmensabhängig konfiguriert.
11. uom_id
Typ: Many2one (uom.uom). Verkaufseinheit (z. B. Stück, kg, Liter). Definiert, wie Mengen im Verkauf ausgedrückt werden.
12. uom_po_id
Typ: Many2one (uom.uom). Einkaufseinheit; kann sich von der Verkaufseinheit unterscheiden und Umrechnungen erfordern.
13. default_code
Typ: Char. Interne Referenz/Artikelnummer. Wichtig für Integrationen und als SKU‑Feld; sollte möglichst eindeutig gehalten werden.
14. barcode
Typ: Char. Barcode für Scans in POS und Lagerprozessen. Varianten erhalten Barcodes meist auf product.product‑Ebene.
15. description
Typ: Char. Interne Beschreibung für Mitarbeiter; nicht für Kunden sichtbar, sondern als Hinweise im Backoffice gedacht.
16. description_sale
Typ: Text. Verkaufsbeschreibung, die in Angeboten, auf Rechnungen und auf der Website angezeigt werden kann; HTML‑Formatierung möglich.
17. description_purchase
Typ: Text. Beschreibung für Bestellungen und Lieferantenkommunikation; hilft beim Einkauf und beim Abgleich von Spezifikationen.
18. sale_ok
Typ: Boolean. Schaltet die Verkaufbarkeit. Ist das Feld False, erscheint das Produkt nicht in Verkaufs‑ und Angebotsformularen.
19. purchase_ok
Typ: Boolean. Steuert, ob das Produkt eingekauft werden darf; bei False wird es in Einkaufsformularen ausgeblendet.
20. weight
Typ: Float. Gewicht des Produkts; relevant für Versandkostenberechnung und Logistikprozesse.
21. volume
Typ: Float. Rauminhalt/Volumen; nützlich für Lagerplanung und Transportkapazität.
22. product_variant_ids
Typ: One2many (product.product). Liste aller Varianten, die vom Template abgeleitet wurden.
23. product_variant_count
Typ: Integer. Anzahl der Varianten; ein berechnetes Feld, das die Menge an Varianten für Anzeige‑ und Filterzwecke liefert.
24. image_1920
Typ: Binary. Hauptbild des Produkts. Odoo hält Varianten der Bildgröße für Formularansichten, Shop und Druckvorlagen bereit.
25. responsible_id
Typ: Many2one (res.users). Zuständiger Mitarbeiter für das Produkt — nützlich für Aufgaben, Verantwortlichkeiten und Freigabeprozesse.
26. company_id
Typ: Many2one (res.company). Zugehörigkeit in Multi‑Company‑Szenarien; bestimmt Sichtbarkeit und Währungsstandards.
27. tax_ids
Typ: Many2many (account.tax). Steuersätze für den Verkauf, die auf Angebote und Rechnungen angewendet werden.
28. supplier_tax_id
Typ: Many2many (account.tax). Steuersätze für den Einkauf; relevant auf Bestellungen und Lieferantenrechnungen.
29. attribute_line_ids
Typ: One2many. Attributlinien, die Varianten erzeugen (z. B. Größe, Farbe); hier definieren Sie, welche Kombinationen möglich sind.
30. route_ids
Typ: Many2many (stock.route). Lager‑ und Beschaffungsrouten wie Kaufen, Fertigen oder Make‑to‑Order — sie bestimmen Materialfluss und Prozesserstellung.
31. property_stock_production
Typ: Many2one (stock.location). Standard‑Produktionseinlagerungsort für gefertigte Artikel; wichtig bei Fertigungsprozessen.
32. property_stock_inventory
Typ: Many2one (stock.location). Standardort für Inventuranpassungen; wird bei Bestandszählungen genutzt.
33. property_valuation
Typ: Selection. Bewertungsmethode (Automatisch oder Manuell) — beeinflusst, wie Lagerwert und Buchung erzeugt werden.
34. property_cost_method
Typ: Selection. Kostenrechnungsmethode (Standard oder FIFO), die bestimmt, wie Einstandswerte berechnet werden.
35. property_account_income_id
Typ: Many2one (account.account). Erlöskonto für Verkäufe; wichtig für die richtige Buchung in der Finanzbuchhaltung.
36. property_account_expense_id
Typ: Many2one (account.account). Aufwandskonto für Einkäufe; wird beim Buchen von Lieferantenrechnungen verwendet.
37. invoice_policy
Typ: Selection. Fakturierungszeitpunkt: nach Bestellmenge oder nach Lieferung — beeinflusst Umsatzerfassung und Rechnungsstellung.
38. expense_policy
Typ: Selection. Zeitpunkt der Aufwandserfassung: bei Bestellung oder bei Lieferung; relevant für Kostenrechnung.
39. service_type
Typ: Selection. Bei Dienstleistungen: Manuell, Timesheet oder Meilensteine — definiert, wie Leistungen abgerechnet und nachverfolgt werden.
40. optional_product_ids
Typ: Many2many (product.template). Optionale Produkte für Cross‑ und Upsell; werden in Angeboten als Ergänzungen vorgeschlagen.
Wie dieses Modell in Geschäftsabläufen eingesetzt wird
1. Verkauf und Angebote
Verkäufer wählen Produkte aus dem Katalog, wenn sie Angebote erstellen. Das Template stellt die gemeinsame Basis — Varianten kommen ins Spiel, wenn Attribute wie Größe oder Farbe auswählbar sind.
2. E‑Commerce
Im Onlineshop werden Produktseiten auf Template‑Ebene dargestellt: gemeinsame Beschreibungen und Bilder stammen vom Template, Varianten ermöglichen die Auswahl vor dem Kauf.
3. Einkauf und Lieferanten
Bestellungen und Lieferantenrechnungen arbeiten mit den Produktdaten: purchase_ok steuert Sichtbarkeit, supplier_tax_id und uom_po_id beeinflussen Bestell‑ und Rechnungsabläufe.
4. Lager und Fertigung
Lagerbewegungen und Fertigungsaufträge beziehen sich auf konkrete Varianten. Das Template legt jedoch Routen, Bewertungs‑ und Kostenmethoden fest, die für die Varianten gelten.
5. Rechnungswesen
Rechnungszeilen nutzen die Produktdefinition für Steuern und Kontenzuordnungen. Die invoice_policy steuert, wann Umsätze in der Buchhaltung erfasst werden.
Wie Entwickler das Modell erweitern
Entwickler erweitern product.template mit bewährten Odoo‑Mustern, wobei die Modellvererbung das zentrale Werkzeug ist.
Modell‑Vererbung
Verwenden Sie _inherit = 'product.template', um das bestehende Modell zu erweitern. So fügen Sie Felder hinzu, überschreiben Methoden oder ergänzen Constraints, ohne den Originalcode zu verändern — das erleichtert Wartung und Upgrades.
Felder hinzufügen
Ergänzen Sie in Ihrem erweiterten Modell neue Felder mit dem passenden Typ (Char, Many2one, Boolean, Integer, Text, Selection). Berücksichtigen Sie dabei unternehmensspezifische Felder, wenn Sie Multi‑Company‑Szenarien unterstützen.
Erweiterungen in Python
Überschreiben Sie create, write oder unlink für eigene Logik — aber rufen Sie super() auf, um bestehendes Verhalten nicht zu zerstören. Achten Sie besonders bei berechneten Feldern auf richtige Abhängigkeiten.
Odoo Studio
Odoo Studio erlaubt das schnelle Hinzufügen von Feldern ohne Code — praktisch für Prototypen. Für nachhaltige, upgrade‑sichere Lösungen sollten jedoch reguläre Custom‑Module bevorzugt werden.
Empfohlene Vorgehensweisen
- Legen Sie gemeinsame Informationen auf dem Template ab und variantenspezifische Daten auf product.product. Das ist die sauberste Trennung für Pflege und Integrationen.
- Pflegen Sie categ_id sorgfältig: Kategorien beeinflussen Standardrouten, Berichte und das Verhalten in Integrationen.
- Nutzen Sie default_code als Brücke zu externen Systemen. Eine konsistente Artikelnummer erleichtert Abgleiche und Datenimporte.
- Bei API‑Anbindungen empfiehlt sich XML‑RPC oder JSON‑RPC. product.template ist über die Odoo API erreichbar — achten Sie auf stabile External IDs und Mapping‑Regeln.
- Für eigene Felder verwenden Sie ein Präfix (z. B. x_ oder modulname_), um Kollisionen mit zukünftigen Odoo‑Felder zu vermeiden.
Häufige Fehler
- Anstatt doppelte Templates anzulegen, nutzen Sie attribute_line_ids, um Varianten zu modellieren — das vermeidet Inkonsistenzen im Katalog.
- Verwechseln Sie nicht product.template mit product.product: variantenspezifische Daten wie Barcode oder SKU gehören auf product.product.
- Vergessen Sie nicht, sale_ok und purchase_ok korrekt zu setzen — sonst tauchen Produkte unerwartet nicht in Formularen auf.
- Überschreiben Sie Kernmethoden niemals ohne super() — das kann andere Module stören oder Upgrades gefährden.
- Fügen Sie keine neuen Pflichtfelder ohne sinnvolle Standardwerte hinzu; sonst schlagen Migrationen und Upgrades fehl, weil bestehende Datensätze die Validierung nicht bestehen.
Fazit
Das product.template ist ein zentrales Modell in Odoo: Es definiert Produktfamilien, gemeinsame Attribute und die Basis für Varianten. Wer die Felder und Erweiterungsmöglichkeiten kennt, kann Odoo effizient konfigurieren und zuverlässig integrieren.
Ob Sie Kataloge abbilden, Geschäftsprozesse konfigurieren oder Entwicklerfunktionen implementieren — solides Wissen über product.template spart Zeit und vermeidet typische Fehler.
Mit Dasolo loslegen
Dasolo unterstützt Unternehmen bei Implementierung, Anpassung und Optimierung von Odoo‑Lösungen. Unser Schwerpunkt liegt auf Integrationen und individueller Entwicklung — mit tiefem Verständnis der Odoo‑Datenarchitektur und Modellen wie product.template.
Brauchen Sie Unterstützung bei Ihrem Odoo‑Projekt, Custom‑Modulen oder Schnittstellen? Wir helfen Ihnen gern weiter. Demo vereinbaren um Ihr Projekt zu besprechen.