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 Verkaufsaufträgen über Bestandsübertragungen bis hin zu Lageroperationen, 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 Felder, Beziehungen und Geschäftslogik.
Dieser Artikel konzentriert sich auf eines der wichtigsten Modelle in der Inventar-App: stock.picking. Egal, ob Sie benutzerdefinierte Lager-Module erstellen, externe Systeme integrieren oder Arbeitsabläufe konfigurieren, Sie werden mit diesem Modell arbeiten.
Was ist das stock.picking Modell
Das stock.picking-Modell stellt Transfers in Odoo dar. Es ist der zentrale Ort, an dem die Lageroperationen verfolgt werden. Jeder Picking-Datensatz repräsentiert einen einzelnen Transfer von Waren von einem Standort zu einem anderen.
Dieses Modell in Odoo wird im gesamten Modul für Lagerbestände verwendet. Eingänge, Lieferungen und interne Transfers erstellen alle stock.picking-Datensätze. Wenn Sie einen Lieferauftrag aus einem Verkauf bestätigen, Waren aus einem Einkauf erhalten oder Bestände zwischen Lagern bewegen, erstellen oder aktualisieren Sie einen stock.picking-Datensatz.
Das Modell ist im Lager-Modul definiert. Andere Module erweitern es durch die Vererbung von Odoo-Modellen. Der Verkauf fügt lieferbezogene Felder hinzu. Der Einkauf fügt Eingangs-Workflows hinzu. Die Fertigung fügt Produktionsbewegungen hinzu. Jedes Modul fügt hinzu, was es benötigt, ohne die Kernstruktur zu duplizieren.
Das stock.picking-Modell erbt von mail.thread und mail.activity.mixin. Das bedeutet, dass Sie Änderungen verfolgen, Chatter-Nachrichten hinzufügen und Aktivitäten zu Transfers direkt planen können.
Wichtige Felder im Modell
Hier sind die wichtigsten Odoo-Felder im stock.picking-Modell. Das Verständnis dieser Felder wird Ihnen helfen, effektiv mit Transfers und Lageroperationen zu arbeiten.
1. name
Typ: Char. Dieses Feld speichert die Referenz des Transfers. Es wird typischerweise automatisch aus einer Sequenz generiert (z.B. WH/OUT/00001). Es wird im Kopfbereich der Transferformulare angezeigt und ist der primäre Identifikator für das Picking.
2. origin
Typ: Char. Die Referenz des Quelldokuments. Bei einer Lieferung könnte dies der Name des Verkaufsauftrags sein. Bei einem Eingang der Einkaufsauftrag. Es hilft, nachzuvollziehen, wo der Transfer seinen Ursprung hat.
3. state
Typ: Auswahl. Der Status des Transfers. Werte: Entwurf, Warten auf eine andere Operation, Warten, Bereit, Fertig, Abgebrochen. Jeder Status bestimmt, welche Aktionen verfügbar sind. Odoo berechnet dies aus den zugehörigen Lagerbewegungen.
4. picking_type_id
Typ: Many2one (stock.picking.type). Der Operationstyp. Definiert, ob es sich um einen Empfang, eine Lieferung oder einen internen Transfer handelt. Erforderlich. Jeder Picking-Typ hat standardmäßige Quell- und Zielstandorte.
5. move_ids
Typ: One2many (stock.move). Die Lagerbewegungen. Jede Zeile repräsentiert ein Produkt und eine Menge, die bewegt werden sollen. Dies ist der Kern des Transfers. Alle Reservierungs- und Verfügbarkeitslogik funktioniert auf diesen Bewegungen.
6. move_line_ids
Typ: One2many (stock.move.line). Die detaillierten Operationen. Wenn Sie eine Chargen- oder Serienverfolgung haben, speichern diese Zeilen die spezifischen Chargen und Standorte. Verwendet für Picking, Verpackung und Validierung.
7. location_id
Typ: Many2one (stock.location). Der Quellstandort. Wo Produkte entnommen werden. Erforderlich. Bei Lieferungen ist dies normalerweise der Lagerstandort. Bei Empfang ist es der Standort des Lieferanten.
8. location_dest_id
Typ: Many2one (stock.location). Der Zielstandort. Wo Produkte hin bewegt werden. Erforderlich. Bei Lieferungen ist dies normalerweise der Kundenstandort. Bei Empfang ist es der Lagerstandort.
9. partner_id
Typ: Many2one (res.partner). Der Kontakt. Bei Lieferungen der Kunde. Bei Empfang der Lieferant. Verwendet für die Adresse auf Dokumenten und für die Integration mit dem Versanddienstleister.
10. scheduled_date
Typ: Datum/Uhrzeit. Wann die Übertragung geplant ist, um verarbeitet zu werden. Wird für Planung und Priorisierung verwendet. Manuelles Setzen legt das erwartete Datum für alle Lagerbewegungen fest.
11. date_deadline
Typ: Datum/Uhrzeit. Die Frist. Kommt oft aus dem Verkaufsauftrag oder dem Einkaufsauftrag. Wird verwendet, um verspätete Übertragungen zu kennzeichnen und für Kundenversprechen.
12. date_done
Typ: Datum/Uhrzeit. Wann die Übertragung validiert oder storniert wurde. Nur lesbar. Wird automatisch gesetzt, wenn die Kommissionierung abgeschlossen ist.
13. priority
Typ: Auswahl. Die Prioritätsstufe. Produkte werden zuerst für Übertragungen mit höherer Priorität reserviert. Wird für dringende Bestellungen verwendet.
14. move_type
Typ: Auswahl. Die Versandrichtlinie. Werte: So schnell wie möglich (Teillieferung erlaubt) oder Wenn alle Produkte bereit sind (alles oder nichts). Beeinflusst, wann die Kommissionierung verarbeitet werden kann.
15. user_id
Typ: Many2one (res.users). Der verantwortliche Benutzer. Wird für Zuweisung und Arbeitslastverfolgung verwendet. Standardmäßig auf den aktuellen Benutzer beim Erstellen gesetzt.
16. company_id
Typ: Many2one (res.company). Das Unternehmen. Verknüpft mit dem Abholtyp. In Multi-Company-Setups bestimmt dies, welches Unternehmen den Transfer besitzt.
17. group_id
Typ: Many2one (procurement.group). Die Beschaffungsgruppe. Verknüpft verwandte Bewegungen miteinander. Wird verwendet, wenn mehrere Abholungen aus derselben Bestellung stammen.
18. backorder_id
Typ: Many2one (stock.picking). Wenn ein Transfer teilweise validiert ist, wird eine Nachbestellung für den verbleibenden Teil erstellt. Dieses Feld verweist auf die ursprüngliche Abholung.
19. backorder_ids
Typ: One2many (stock.picking). Die Nachbestellungen, die aus dieser Abholung erstellt wurden. Wird verwendet, wenn Sie teilweise validieren und den Rest später bearbeiten müssen.
20. return_id
Typ: Many2one (stock.picking). Wenn diese Abholung als Rücksendung erstellt wurde, verweist dies auf die ursprüngliche Abholung. Wird für Rücksendungs-Workflows verwendet.
21. note
Typ: Html. Interne Notizen. Sichtbar für Lagerbenutzer. Kann spezielle Anweisungen oder Handhabungsanforderungen enthalten.
22. signature
Typ: Bild. Die Unterschrift, die erfasst wird, wenn die Lieferung validiert wird. Wird als Nachweis für die Lieferung verwendet. Als Anhang gespeichert.
23. ist_unterschrieben
Typ: Boolean. Berechnet aus der Unterschrift. Gibt an, ob die Lieferung unterschrieben wurde.
24. besitzer_id
Typ: Many2one (res.partner). Der Eigentümer, der bei der Validierung zugewiesen werden soll. Wird für die Sendung oder wenn Produkte einem Dritten gehören, verwendet.
25. paket_level_ids
Typ: One2many (stock.package_level). Paketstufen bei der Verwendung von 'in Pack legen'. Gruppiert Bewegungszeilen in Pakete für den Versand.
26. erstelldatum
Typ: Datetime. Wann der Datensatz erstellt wurde. Automatisch von Odoo verwaltet. Vom Basismodell geerbt.
27. änderungsdatum
Typ: Datetime. Wann der Datensatz zuletzt geändert wurde. Automatisch verwaltet. Vom Basismodell geerbt.
28. aktiv
Typ: Boolean. Soft-Delete-Flag. Wenn False, wird der Datensatz archiviert. Vom Basismodell geerbt.
Wie dieses Modell in Geschäftsabläufen verwendet wird
1. Verkauf und Lieferung
Wenn ein Verkaufsauftrag bestätigt wird, erstellt Odoo einen Lieferauftrag (stock.picking). Der Picking-Link verweist über den Ursprung auf den Verkaufsauftrag. Das Lagerpersonal kommissioniert und verpackt, dann validiert es. Der Status wechselt von Entwurf zu bereit zu erledigt.
2. Einkauf und Empfang
Wenn ein Einkaufsauftrag bestätigt wird, erstellt Odoo einen eingehenden Empfang. Der Picking empfängt Produkte vom Lieferantenstandort ins Lager. Die partner_id ist der Lieferant. Die Validierung aktualisiert die Bestandsmengen.
3. Interne Transfers
Das Bewegen von Beständen zwischen Lagern oder Standorten erstellt interne Pickings. Der picking_type_id hat den Code 'intern'. Standort und Ziel sind beide interne Lagerstandorte.
4. Rücksendungen und Nachbestellungen
Wenn ein Verkauf zurückgegeben wird, wird ein Rücksendepicking erstellt. Die return_id verweist auf die ursprüngliche Lieferung. Wenn eine Lieferung teilweise validiert wird, enthält backorder_ids die verbleibende Arbeit.
5. Fertigung und Produktion
Fertigungsaufträge erstellen Pickings für Rohstoffe (Verbrauch) und Fertigprodukte (Produktion). Das Modell stock.picking wird durch das mrp-Modul für diese Abläufe erweitert.
Wie Entwickler dieses Modell erweitern
Entwickler erweitern stock.picking mit mehreren Mustern. Die Vererbung von Odoo-Modellen ist der Hauptmechanismus.
Modellvererbung
Verwenden Sie _inherit = 'stock.picking', um das Modell zu erweitern. Fügen Sie neue Felder hinzu, überschreiben Sie Methoden oder fügen Sie Einschränkungen hinzu. Das vererbte 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 vererbten 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_validate, action_assign oder _create_backorder, um Logik hinzuzufügen. Verwenden Sie super(), um das Original aufzurufen. Seien Sie vorsichtig mit Statusübergängen und der Erstellung von Bewegungen.
Odoo Studio
Odoo Studio ermöglicht es Ihnen, Felder ohne Code hinzuzufügen. Gut für schnelle Anpassungen wie benutzerdefinierte Beschriftungen oder zusätzliche Notizen. Für komplexe Logik oder Carrier-Integration sind benutzerdefinierte Module wartungsfreundlicher.
Best Practices
- Setzen Sie immer das picking_type_id, wenn Sie Pickings manuell erstellen. Es steuert die Standardstandorte und das Verhalten.
- Verwenden Sie das Ursprungsfeld, um auf das Quelldokument zurückzuverfolgen. Es hilft bei der Berichterstattung und Fehlersuche.
- Beim Erstellen von API-Integrationen ist das Modell stock.picking vollständig über die Odoo-API zugänglich. Erstellen Sie Bewegungen über die Beziehung move_ids. Erstellen Sie keine Pickings ohne Bewegungen.
- Verwenden Sie scheduled_date für die Planung. Es beeinflusst Reservierung und Priorisierung.
- 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
- Erstellen von Abholungen, ohne picking_type_id festzulegen. Dies kann zu falschen Standardstandorten führen.
- Ändern von move_ids nach der Bestätigung, ohne die Zustandsmaschine zu verstehen. Zustandsübergänge können komplex sein.
- Vergessen, partner_id für Lieferungen festzulegen. Spediteure und Dokumente benötigen den Kontakt.
- Überschreiben von button_validate, ohne super() aufzurufen. Dies kann die Erstellung von Rückbestellungen und anderen Modulen beeinträchtigen.
- Annehmen, dass move_ids und move_line_ids immer synchron sind. Bewegungszeilen werden erstellt, wenn Sie reservieren oder wenn Sie detaillierte Operationen verwenden.
Fazit
Das Modell stock.picking ist zentral für das Odoo-Inventar. Es speichert Übertragungen, Lieferungen und Eingänge. Das Verständnis seiner Felder und wie Module es erweitern, wird Ihnen helfen, Odoo effektiv zu konfigurieren, anzupassen und zu integrieren.
Ob Sie nun ein funktionaler Berater sind, der Lagerprozesse abbildet, oder ein Entwickler, der benutzerdefinierte Module erstellt, ein solides Verständnis von stock.picking wird Zeit sparen und Fehler verhindern.
Bereit, Ihr Odoo-Lager zu optimieren
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 stock.picking.
Wenn Sie Hilfe bei Ihrer Odoo-Implementierung, benutzerdefinierten Lager-Modulen oder Integrationen benötigen, sind wir hier, um zu helfen. Vereinbaren Sie eine Demo um Ihr Projekt zu besprechen.