Einführung
In Odoo definieren Modelle, wie Daten strukturiert und in der Datenbank gespeichert werden. Jedes Stück Geschäftsdaten, mit dem Sie arbeiten, von Bestellungen über Rechnungen bis hin zu Beständen, lebt in einem Modell.
Das Verständnis von Odoo-Modellen ist sowohl für Entwickler als auch für funktionale Berater unerlässlich. Modelle sind die Grundlage der Odoo-Datenarchitektur. Sie definieren Odoo-Felder, Beziehungen und Geschäftslogik.
Dieser Artikel konzentriert sich auf eines der wichtigsten Modelle in Odoo: purchase.order. Egal, ob Sie benutzerdefinierte Module erstellen, externe Systeme integrieren oder Beschaffungsabläufe konfigurieren, Sie werden mit diesem Modell arbeiten.
Was ist das purchase.order Modell
Das purchase.order-Modell repräsentiert Bestellungen und Anfragen für Angebote (RFQs) in Odoo. Es ist der zentrale Ort, an dem alle Beschaffungstransaktionen erfasst werden, bevor sie zu Eingangsrechnungen oder Lieferantenrechnungen werden.
Dieses Modell in Odoo wird vom Einkaufsmodul verwendet. Wenn ein Käufer eine RFQ erstellt, wird ein purchase.order-Datensatz erstellt. Wenn der Lieferant bestätigt oder der Käufer genehmigt, wechselt die Bestellung von Entwurf zu bestätigt. Dasselbe Modell in Odoo enthält sowohl Entwurf-RFQs als auch bestätigte Bestellungen. Das Statusfeld verfolgt den Lebenszyklus.
Andere Module erweitern dieses Modell durch Odoo-Modellerbschaft. Das Inventar fügt Logik für den Empfang und die Kommissionierung hinzu. Die Buchhaltung fügt Felder für Lieferantenrechnungen hinzu. Die Fertigung kann Bestellungen aus Stücklisten erstellen. Jedes Modul fügt hinzu, was es benötigt, ohne die Kernstruktur zu duplizieren.
Wichtige Felder im Modell
Hier sind die wichtigsten Odoo-Felder im purchase.order-Modell. Das Verständnis dieser Felder wird Ihnen helfen, effektiv mit Bestellungen zu arbeiten.
1. name
Typ: Char. Dieses Feld speichert die Bestellreferenz (z.B. PO00042). Es wird typischerweise automatisch generiert und in Listenansichten und auf Dokumenten angezeigt. Es ist der primäre Identifikator für die Bestellung.
2. state
Typ: Auswahl. Verfolgt den Lebenszyklus der Bestellung. Werte: Entwurf (RFQ), gesendet (an den Lieferanten gesendet), zur Genehmigung (wartet auf Genehmigung), Einkauf (bestätigt), erledigt (vollständig empfangen und fakturiert), storniert (storniert). Der Status bestimmt, welche Aktionen verfügbar sind.
3. partner_id
Typ: Many2one (res.partner). Der Lieferant oder Anbieter. Erforderlich. Dies ist der Hauptkontakt oder das Unternehmen für die Bestellung. Wird für alle lieferantenbezogenen Logik und Berichterstattung verwendet.
4. partner_ref
Typ: Char. Die Lieferantenreferenz oder die Bestellnummer des Anbieters. Wird verwendet, wenn der Lieferant seine eigene Bestellreferenz angibt. Wird auf Dokumenten angezeigt und hilft, Eingänge und Rechnungen abzugleichen.
5. date_order
Typ: Datum/Uhrzeit. Das Bestelldatum. Für Entwurfsbestellungen: Erstellungsdatum. Für bestätigte Bestellungen: Bestätigungsdatum. Wird für Berichterstattung, Sortierung und als standardmäßiges erwartetes Datum für Bestellpositionen verwendet.
6. date_approve
Typ: Datum/Uhrzeit. Das Genehmigungs- oder Bestätigungsdatum. Wird gesetzt, wenn die Bestellung in den Einkaufsstatus wechselt. Nur lesbar. Wird für Berichterstattung und Prüfpfade verwendet.
7. order_line
Typ: One2many (purchase.order.line). Die Bestellpositionen. Jede Position enthält Produkt, Menge, Preis und Steuer. Dies ist das Kerndetail der Bestellung.
8. amount_untaxed
Typ: Float. Der Zwischensumme vor Steuern. Berechnet aus den Bestellpositionen. Wird für Berichterstattung und Anzeige verwendet.
9. amount_tax
Typ: Float. Der Gesamtsteuerbetrag. Berechnet aus den Bestellpositionen basierend auf der Steuerkonfiguration. Wird auf der Bestellung und der Lieferantenrechnung angezeigt.
10. amount_total
Typ: Float. Der Gesamtbetrag einschließlich Steuern. Der Hauptbetrag für Rechnungsstellung und Berichterstattung.
11. currency_id
Typ: Many2one (res.currency). Die Währung. Wird normalerweise von der Firma oder dem Anbieter übernommen. Alle monetären Felder verwenden diese Währung.
12. origin
Typ: Char. Das Quelldokument. Zum Beispiel, wenn eine Bestellung aus einer Verkaufsbestellung (Dropshipping) oder einer Fertigungsbestellung erstellt wird, wird der Quellname hier gespeichert. Wird zur Rückverfolgbarkeit verwendet.
13. dest_address_id
Typ: Many2one (res.partner). Die Lieferadresse. Wenn nicht festgelegt, wird standardmäßig die Firmenadresse verwendet. Wird beim Dropshipping verwendet, wenn die Waren direkt an den Kunden gehen.
14. priority
Typ: Auswahl. Bestellpriorität: Normal oder Dringend. Wird zum Sortieren und Hervorheben verwendet. Dringende Bestellungen können in Arbeitsabläufen eine besondere Behandlung erhalten.
15. invoice_status
Typ: Auswahl. Verfolgt die Rechnungsstellung: keine (nicht fakturiert), zu fakturieren (bereit zur Fakturierung), fakturiert (vollständig fakturiert). Bestimmt die Sichtbarkeit der Aktion Rechnung erstellen.
16. invoice_count
Typ: Ganzzahl. Anzahl der zugehörigen Lieferantenrechnungen. Berechnet. Wird zur Anzeige und zum Öffnen der Liste der Rechnungen verwendet.
17. invoice_ids
Typ: One2many (account.move). Die zugehörigen Lieferantenrechnungen. Verknüpft Bestellungen mit der Buchhaltung. Wird für die Drei-Wege-Abstimmung und die Zahlungsüberwachung verwendet.
18. picking_ids
Typ: One2many (stock.picking). Die zugehörigen Lieferaufträge oder -belege. Wird verwendet, wenn das Einkaufsmodul mit dem Lager installiert ist.
19. picking_count
Typ: Ganzzahl. Anzahl der zugehörigen Abholungen. Berechnet. Wird zur Anzeige verwendet und um die Liste der Belege zu öffnen.
20. create_date
Typ: Datum/Uhrzeit. Speichert das Datum und die Uhrzeit, zu der der Datensatz erstellt wurde. Wird automatisch von Odoo verwaltet. Nützlich für Berichterstattung und Audits.
21. write_date
Typ: Datum/Uhrzeit. Speichert das Datum und die Uhrzeit der letzten Änderung. Ebenfalls automatisch verwaltet. Hilft nachzuvollziehen, wann die Daten zuletzt aktualisiert wurden.
22. notes
Typ: Text. Allgemeine Geschäftsbedingungen oder interne Notizen. Kann auf der Bestellung angezeigt werden. Wird für besondere Anweisungen an den Lieferanten verwendet.
23. company_id
Typ: Many2one (res.company). In Multi-Company-Setups zeigt dies an, zu welchem Odoo-Unternehmen die Bestellung gehört. Beeinflusst die Sichtbarkeit und den Zugriff auf Datensätze.
24. user_id
Typ: Many2one (res.users). Der Käufer oder verantwortliche Benutzer. Wird für Genehmigungs-Workflows und Aktivitätszuweisungen verwendet.
25. fiscal_position_id
Typ: Many2one (account.fiscal.position). Die steuerliche Position für die Steuerzuordnung. Wird angewendet, wenn der Anbieter in einem anderen Land ist oder ein spezielles Steuermodell hat.
26. payment_term_id
Typ: Many2one (account.payment.term). Zahlungsbedingungen (z.B. Net 30, 50% im Voraus). Wird beim Erstellen von Lieferantenrechnungen verwendet.
27. display_name
Typ: Char. Berechneter Anzeigename. Kombiniert den Namen mit Informationen zum Anbieter. Wird in Many2one-Dropdowns und Suchergebnissen verwendet. Nur lesbar.
28. active
Typ: Boolean. Soft-Delete-Flag. Wenn False, wird der Datensatz archiviert und aus den Standardansichten ausgeblendet. Bestellungen werden nicht physisch gelöscht, um die Historie zu bewahren.
Wie dieses Modell in Geschäftsabläufen verwendet wird
1. RFQ zu Bestellung
Der Käufer erstellt eine Anfrage zur Angebotsabgabe (Entwurf). Fügt Zeilen hinzu, sendet an den Anbieter. Der Anbieter bestätigt oder der Käufer bestätigt manuell. Die Bestellung ist bestätigt (Status = Einkauf). Belege und Anbieterrechnungen können erstellt werden.
2. Anbieterbeleg
Wenn die Waren ankommen, erstellt der Benutzer einen Beleg aus der Bestellung. Die picking_ids sind verknüpft. Die erhaltenen Mengen aktualisieren den Bestand. Die Produktkosten werden vom Einkaufspreis aktualisiert.
3. Anbieterrechnung
Aus einer bestätigten Bestellung erstellen die Benutzer Anbieterrechnungen. Rechnungszeilen werden aus den Bestellzeilen gezogen. payment_term_id und fiscal_position_id stammen aus der Bestellung. invoice_status verfolgt den Fortschritt.
4. Dropshipping
Wenn eine Verkaufsbestellung einen Einkauf auslöst, verweist der Ursprung zurück auf den Verkauf. dest_address_id wird auf die Kundenadresse gesetzt, damit der Anbieter direkt versendet. Das Modell purchase.order ist die Brücke zwischen Verkauf und Beschaffung.
5. Fertigung und MRP
Wenn ein Fertigungsauftrag Komponenten benötigt, kann er Bestellungen für Rohstoffe erstellen. Das Ursprungsfeld verweist auf den Fertigungsauftrag. Dieses Modell ist zentral für den Beschaffungs-zu-Zahlungszyklus.
Wie Entwickler dieses Modell erweitern
Entwickler erweitern purchase.order mit mehreren Mustern. Die Vererbung von Odoo-Modellen ist der Hauptmechanismus.
Modellvererbung
Verwenden Sie _inherit = 'purchase.order', um das Modell zu erweitern. Fügen Sie neue Odoo-Felder hinzu, überschreiben Sie Methoden oder fügen Sie Einschränkungen hinzu. Das Erben-Modell in Odoo hält Ihre Änderungen in einem separaten Modul für einfache Upgrades.
Felder hinzufügen
Definieren Sie neue Odoo-Felder in Ihrem geerbten Modell. Verwenden Sie den richtigen Feldtyp: Char, Many2one, Boolean, Integer, Text, Auswahl. Berücksichtigen Sie unternehmensabhängige Felder für mehrere Unternehmen.
Python-Erweiterungen
Überschreiben Sie button_confirm, create oder write, um Logik hinzuzufügen. Verwenden Sie super(), um das Original aufzurufen. Seien Sie vorsichtig mit berechneten Feldern und deren Abhängigkeiten.
Odoo Studio
Odoo Studio ermöglicht es Ihnen, Felder ohne Code hinzuzufügen. Gut für schnelle Anpassungen. Für komplexe Logik oder Upgrades sind benutzerdefinierte Module wartungsfreundlicher. Das API-Modell in Odoo (purchase.order) ist vollständig über XML-RPC und JSON-RPC für Integrationen verfügbar.
Best Practices
- Verwenden Sie den richtigen Status für jede Phase. Überspringen Sie keine Status oder umgehen Sie die Bestätigungslogik nicht.
- Setzen Sie partner_ref, wenn der Anbieter eine Referenz bereitstellt. Es hilft, Belege und Rechnungen abzugleichen.
- Verwenden Sie origin, um die Quelle der Bestellungen nachzuvollziehen. Essentiell für Dropshipping und Fertigung.
- Beim Erstellen von API-Integrationen verwenden Sie die XML-RPC- oder JSON-RPC-API. Das Modell purchase.order ist vollständig verfügbar. Ordnen Sie externe IDs sorgfältig zu.
- Für benutzerdefinierte Felder verwenden Sie das
x_-Präfix oder ein Modulpräfix, um Konflikte mit zukünftigen Odoo-Versionen zu vermeiden.
Häufige Fehler
- Bestätigte Bestellungen ohne Überprüfung des Status ändern. Bestätigte Bestellungen haben eingeschränkte Felder. Erstellen Sie eine neue Bestellung oder verwenden Sie den richtigen Workflow.
- Verwechslung von partner_id und dest_address_id. partner_id ist der Anbieter; dest_address_id ist der Ort, an den die Waren geliefert werden (bei Dropshipping).
- Die Methode button_confirm überschreiben, ohne super() aufzurufen. Dies kann andere Module oder zukünftige Updates beeinträchtigen.
- Erforderliche benutzerdefinierte Felder ohne Standardwerte hinzufügen. Bestehende Bestellungen werden bei einem Upgrade die Validierung nicht bestehen.
- Vergessen, currency_id bei der Arbeit mit Multi-Währungs-Anbietern festzulegen. Falsche Währung kann zu falschen Kosten und Rechnungsstellungen führen.
Fazit
Das Modell purchase.order ist zentral für Odoo Purchase. Es speichert RFQs und bestätigte Bestellungen. Das Verständnis seiner Odoo-Felder und wie Module es erweitern, wird Ihnen helfen, Odoo effektiv zu konfigurieren, anzupassen und zu integrieren.
Ob Sie ein funktionaler Berater sind, der Beschaffungsprozesse abbildet, oder ein Entwickler, der benutzerdefinierte Module erstellt, ein solides Verständnis von purchase.order wird Zeit sparen und Fehler verhindern.
Brauchen Sie Hilfe bei Ihrer Odoo-Implementierung?
Dasolo hilft Unternehmen bei der Implementierung, Anpassung und Optimierung von Odoo. Wir sind auf API-Integrationen und Odoo-Entwicklung spezialisiert. Unser Team hat umfassende Erfahrung mit der Odoo-Datenarchitektur und Modellen wie purchase.order.
Wenn Sie Hilfe bei Ihrer Odoo-Implementierung, benutzerdefinierten Modulen oder Integrationen benötigen, sind wir hier, um zu helfen. Buchen Sie eine Demo um Ihr Projekt zu besprechen.