Einleitung
In Odoo beschreiben Modelle, wie Geschäftsdaten strukturiert und in der Datenbank abgelegt werden. Alles, was im Tagesbetrieb wichtig ist – Bestellungen, Rechnungen, Lagerbewegungen – lebt in solchen Modellen.
Ein fundiertes Verständnis der Odoo‑Modelle ist für Entwickler und Berater gleichermaßen unverzichtbar. Modelle bilden das Rückgrat der Datenarchitektur: Sie bestimmen Felder, Beziehungen und die Kernlogik, die Geschäftsabläufe steuert.
Dieser Beitrag konzentriert sich auf ein zentrales Modell in Odoo: purchase.order. Egal ob Sie Module erweitern, Schnittstellen bauen oder Beschaffungsprozesse konfigurieren — früher oder später arbeiten Sie mit diesem Modell.
Was das purchase.order‑Modell ist
Das purchase.order‑Modell bildet Bestellungen und Angebotsanfragen ab. Es ist die zentrale Sammelstelle, in der Beschaffungsvorgänge erfasst werden, bevor sie in Wareneingänge oder Lieferantenrechnungen überführt werden.
Das Modell wird vom Purchase‑Modul genutzt: Eine angelegte RFQ ist ein purchase.order‑Datensatz. Nachdem der Lieferant bestätigt oder der Einkäufer freigibt, wechselt der Eintrag vom Entwurf in den bestätigten Status. Entwürfe und bestätigte Aufträge werden im selben Modell gehalten; der Status steuert den Lebenszyklus.
Andere Module bauen über Vererbung auf diesem Modell auf. Das Lager ergänzt Empfangs‑ und Kommissionierlogik, die Buchhaltung fügt Felder für Rechnungen hinzu, und die Fertigung kann Bestellungen aus Stücklisten heraus anlegen. So bleibt die Grundstruktur einmalig erhalten, während Funktionalität modular ergänzt wird.
Wichtige Felder im Modell
Im Folgenden die wichtigsten Felder des purchase.order‑Modells. Wer diese Felder kennt, kann Bestellungen sicher konfigurieren, auswerten und erweitern.
1. name
Typ: Char. Bezeichnet die Bestellnummer oder Referenz (z. B. PO00042). Meist automatisch vergeben und prominent in Listen und Dokumenten angezeigt — das wichtigste Identifikationsmerkmal einer Bestellung.
2. state
Typ: Selection. Führt den Bestellstatus: draft (Angebot), sent (an Lieferant gesendet), to approve (zur Freigabe), purchase (bestätigt), done (vollständig empfangen und verrechnet), cancel (storniert). Der Status bestimmt verfügbare Aktionen und Workflows.
3. partner_id
Typ: Many2one (res.partner). Der Lieferant. Pflichtfeld. Verknüpft die Bestellung mit dem Geschäftspartner und steuert lieferantenbezogene Auswertungen und Regeln.
4. partner_ref
Typ: Char. Lieferantenreferenz oder deren Bestellnummer. Nützlich, um Lieferantendokumente nachzuvollziehen und Eingänge bzw. Rechnungen abzugleichen.
5. date_order
Typ: Datetime. Bestelldatum: bei Entwürfen das Erstellungsdatum, bei bestätigten Aufträgen das Bestätigungsdatum. Wichtig für Berichte, Sortierung und als Basis für erwartete Liefertermine der Positionen.
6. date_approve
Typ: Datetime. Datum der Bestellfreigabe oder -bestätigung. Wird beim Übergang in den purchase‑Status gesetzt, ist schreibgeschützt und dient Audit‑ und Reportingzwecken.
7. order_line
Typ: One2many (purchase.order.line). Positionen der Bestellung. Jede Position enthält Produkt, Menge, Preis und Steuern — das eigentliche Herz der Bestellung.
8. amount_untaxed
Typ: Float. Zwischensumme ohne Steuern. Aus den Positionen berechnet, relevant für Darstellung und Auswertung.
9. amount_tax
Typ: Float. Gesamte Steuerbeträge. Basierend auf den Positionen und Steuerkonfiguration berechnet und auf Bestellungen sowie Rechnungen angezeigt.
10. amount_total
Typ: Float. Gesamtbetrag inklusive Steuern. Zentrale Größe für Rechnungslegung und Berichte.
11. currency_id
Typ: Many2one (res.currency). Währung der Bestellung. Meistens von Firma oder Lieferant vorgegeben — alle monetären Felder orientieren sich daran.
12. origin
Typ: Char. Quellbeleg: z. B. die zugehörige Verkaufsbestellung oder Produktionsauftrag. Dient der Rückverfolgbarkeit zwischen Prozessen.
13. dest_address_id
Typ: Many2one (res.partner). Lieferadresse. Fällt diese leer aus, wird standardmäßig die Firmenadresse genutzt. Wichtig bei Direktlieferungen an Kunden (Dropshipping).
14. priority
Typ: Selection. Priorität der Bestellung: Normal oder Dringend. Hilft bei Sortierung und kann besondere Bearbeitungsschritte auslösen.
15. invoice_status
Typ: Selection. Zeigt den Rechnungsstand an: no (nicht verrechnet), to invoice (abrechnungsbereit), invoiced (voll verrechnet). Beeinflusst Sichtbarkeit von Aktionen wie 'Rechnung erstellen'.
16. invoice_count
Typ: Integer. Anzahl verknüpfter Lieferantenrechnungen. Berechnet, dient der Anzeige und dem schnellen Öffnen der Rechnungsübersicht.
17. invoice_ids
Typ: One2many (account.move). Verknüpfte Eingangsrechnungen. Verbindet Einkauf mit Buchhaltung für Abstimmungen und Zahlungsverfolgung.
18. picking_ids
Typ: One2many (stock.picking). Zugehörige Lieferscheine oder Wareneingänge. Wird genutzt, wenn Einkauf mit Lager kombiniert ist.
19. picking_count
Typ: Integer. Anzahl der zugehörigen Pickings. Berechnet, praktisch für Übersichten und schnelle Navigation zu Eingängen.
20. create_date
Typ: Datetime. Zeitpunkt der Datensatzanlage. Automatisch gesetzt, wichtig für Audit und zeitliche Analysen.
21. write_date
Typ: Datetime. Zeitpunkt der letzten Änderung. Ebenfalls automatisch verwaltet, nützlich zur Nachverfolgung von Aktualisierungen.
22. notes
Typ: Text. Interne Hinweise oder Geschäftsbedingungen. Können auf Bestelldokumenten erscheinen und dienen Sonderanweisungen an den Lieferanten.
23. company_id
Typ: Many2one (res.company). Bei Multi‑Company‑Setups zeigt dieses Feld, zu welcher Firma die Bestellung gehört. Beeinflusst Sichtbarkeit und Berechtigungen.
24. user_id
Typ: Many2one (res.users). Verantwortlicher Einkäufer. Relevant für Freigabeprozesse, Benachrichtigungen und Aufgabenverteilung.
25. fiscal_position_id
Typ: Many2one (account.fiscal.position). Fiskalposition für Steuerabbildungen — wichtig bei grenzüberschreitenden Lieferanten oder speziellen Steuerszenarien.
26. payment_term_id
Typ: Many2one (account.payment.term). Zahlungsbedingungen (z. B. 30 Tage netto, 50% Anzahlung). Werden beim Erstellen der Rechnungen übernommen.
27. display_name
Typ: Char. Berechneter Anzeigename, kombiniert Bestellnummer mit Lieferanteninfos. Wird in Many2one‑Feldlisten und Suchergebnissen gezeigt und ist schreibgeschützt.
28. active
Typ: Boolean. Archivierungsflag. Bei False wird der Datensatz ausgeblendet, bleibt aber erhalten — wichtige Historien‑Sicherung, Bestellungen werden selten wirklich gelöscht.
Wie dieses Modell in Geschäftsprozessen genutzt wird
1. Von RFQ zur Bestellung
Ein Einkäufer legt eine Angebotsanfrage als Entwurf an, ergänzt Positionen und sendet sie an den Lieferanten. Nach Bestätigung durch den Lieferanten oder nach manueller Freigabe durch den Einkäufer wechselt die RFQ in den bestätigten Status und kann in Wareneingänge und Rechnungen überführt werden.
2. Wareneingang
Beim Eintreffen der Ware erzeugt man aus der Bestellung einen Wareneingang: die Pickings werden mit der Bestellung verknüpft, Lagerbestände aktualisiert und Produktkosten bei Bedarf angepasst.
3. Lieferantenrechnung
Aus einer bestätigten Bestellung lassen sich Eingangsrechnungen erzeugen. Positionsdaten, Zahlungsbedingungen und Fiskalpositionen werden übernommen; das invoice_status‑Feld zeigt den Fortschritt der Rechnungsbearbeitung an.
4. Dropshipping
Löst eine Verkaufsbestellung eine Beschaffung aus, verlinkt das origin‑Feld die Vorgänge. Die dest_address_id wird auf die Kundenadresse gesetzt, damit der Lieferant direkt an den Endkunden liefert — purchase.order verbindet Vertrieb und Beschaffung.
5. Fertigung (MRP)
Benötigt die Produktion Material, können daraus Bestellungen für Rohstoffe entstehen. Die Herkunftsreferenz verbindet Bestellung und Produktionsauftrag — das Modell ist ein zentraler Baustein im Procure‑to‑Pay‑Prozess.
Wie Entwickler das Modell erweitern
Entwickler erweitern purchase.order über verschiedene Muster; zentrale Methode ist die Odoo‑Model‑Vererbung.
Modellvererbung
Setzen Sie _inherit = 'purchase.order', um das Modell zu erweitern. So fügen Sie neue Felder hinzu, überschreiben Methoden oder ergänzen Constraints. Änderungen bleiben in Ihrem Modul gebündelt und sind upgradesicherer.
Felder hinzufügen
Definieren Sie neue Felder mit passendem Typ: Char, Many2one, Boolean, Integer, Text, Selection. Denken Sie an firmaabhängige Felder bei Multi‑Company‑Szenarien.
Python‑Erweiterungen
Überschreiben Sie Methoden wie button_confirm, create oder write, um zusätzliche Logik zu implementieren — rufen Sie super() auf, um Basisverhalten zu erhalten. Achten Sie auf berechnete Felder und deren Abhängigkeiten.
Odoo Studio
Mit Odoo Studio fügen Sie schnell Felder ohne Code hinzu — praktisch für einfache Anpassungen. Für komplexe Logik oder langfristige Wartbarkeit sind Module jedoch die bessere Wahl. Das Modell ist über XML‑RPC/JSON‑RPC für Integrationen zugänglich.
Best Practices
- Nutzen Sie für jeden Schritt den passenden Status. Überspringen Sie keine Statusübergänge und umgehen Sie nicht die Bestätigungslogik.
- Tragen Sie partner_ref ein, wenn der Lieferant eine Referenz liefert — das erleichtert Abgleich von Wareneingang und Rechnungen.
- Verwenden Sie origin, um die Herkunft einer Bestellung nachzuvollziehen. Das ist unerlässlich für Dropshipping und Produktion.
- Für API‑Anbindungen nutzen Sie XML‑RPC oder JSON‑RPC. Das purchase.order‑Modell ist vollständig verfügbar — achten Sie beim Mapping externer IDs auf Konsistenz.
- Für eigene Felder nutzen Sie das Präfix x_ oder ein Modulpräfix, um Kollisionen mit künftigen Odoo‑Versionen zu vermeiden.
Häufige Fehler
- Bestellungen nach Bestätigung ohne Statusprüfung ändern. Bestätigte Aufträge haben eingeschränkte Felder — bei Anpassungsbedarf lieber neuen Auftrag anlegen oder den vorgesehenen Workflow nutzen.
- partner_id und dest_address_id verwechseln. partner_id ist der Lieferant, dest_address_id beschreibt den Lieferort (bei Direktlieferungen oft der Kunde).
- button_confirm überschreiben ohne super() aufzurufen. Das kann andere Module stören und zukünftige Updates brechen.
- Pflichtfelder in bestehenden Systemen hinzufügen, aber keine sinnvollen Defaults setzen. Bestehende Datensätze können dadurch bei Migrationen oder Upgrades fehlschlagen.
- Die currency_id bei Multi‑Currency‑Lieferanten vergessen. Falsche Währung führt zu fehlerhaften Kostenberechnungen und Rechnungsbeträgen.
Fazit
Das purchase.order‑Modell ist das Herzstück des Odoo‑Einkaufs: Es hält RFQs und Bestellungen und ist die zentrale Schnittstelle für Erweiterungen. Wer seine Felder und Integrationspunkte kennt, kann Odoo effizient konfigurieren und anbinden.
Ob Sie als Prozessberater Einkaufsabläufe abbilden oder als Entwickler Module bauen — ein solides Verständnis des purchase.order‑Modells spart Zeit und verhindert typische Fehler.
Brauchen Sie Unterstützung bei Ihrer Odoo‑Einführung?
Das Team von Dasolo begleitet Unternehmen bei Einführung, Anpassung und Optimierung von Odoo. Wir sind spezialisiert auf Schnittstellen und Individualentwicklungen und kennen die Datenarchitektur und Modelle wie purchase.order sehr genau.
Wenn Sie Unterstützung bei Ihrer Odoo‑Einführung, bei individuellen Modulen oder Integrationen brauchen, unterstützen wir Sie gerne. Demo vereinbaren um Ihr Projekt zu besprechen.