Einleitung
In Odoo legen Modelle fest, wie Geschäftsdaten strukturiert und im System abgelegt werden. Alle relevanten Informationen — von Bestellungen bis zu Lagerbewegungen — existieren innerhalb solcher Modelle und bilden die Basis für Berichte, Workflows und Integrationen.
Für Entwickler und funktionale Berater ist das Verständnis von Odoo‑Modellen unerlässlich. Modelle definieren Felder, Beziehungen und die Geschäftslogik; sie sind das Fundament, auf dem Prozesse, Berechtigungen und Datenflüsse aufgebaut werden.
Dieser Beitrag beleuchtet eines der zentralen Modelle im Lager: stock.picking. Wer Lagerabläufe anpasst, Schnittstellen baut oder Workflows konfiguriert, begegnet diesem Modell zwangsläufig — sei es beim Erfassen von Lieferungen, internen Umlagerungen oder beim Verbinden mit Fremdsystemen.
Was ist das stock.picking‑Modell?
Das stock.picking‑Modell steht für einzelne Warenbewegungen innerhalb von Odoo. Jeder Datensatz bildet eine konkrete Übertragung von Waren zwischen zwei Orten ab und ist der zentrale Anker, an dem Status, Verantwortliche und die zugehörigen Positionen zusammenlaufen.
Im Inventar‑Modul wird dieses Modell für alle Bewegungsarten verwendet: Wareneingänge, Auslieferungen und interne Verlagerungen erzeugen jeweils stock.picking‑Datensätze. Jede Bestätigung, Ankunft oder Umlagerung aktualisiert diese Einträge und damit den aktuellen Lagerbestand.
Das Modell stammt aus dem stock‑Modul und wird von anderen Modulen erweitert. Verkauf, Einkauf oder Fertigung ergänzen nur die nötigen Felder und Logik — so bleibt die Kernstruktur konsistent und Erweiterungen modular.
Da stock.picking von mail.thread und mail.activity.mixin erbt, lassen sich Änderungen nachverfolgen, Nachrichten (Chatter) einbinden und Aktivitäten planen — praktisch für Teamkommunikation und Nachverfolgung von Aufgaben.
Wesentliche Felder des Modells
Im Folgenden finden Sie die wichtigsten Felder des stock.picking‑Modells. Ein gutes Verständnis dieser Felder erleichtert das Konfigurieren, Debuggen und Erweitern von Lagerprozessen.
1. name
Typ: Char. Enthält die Belegnummer oder Referenz der Bewegung — meist automatisch durch eine Sequenz vergeben (z. B. WH/OUT/00001). Sichtbar im Kopf der Belegmaske und häufig das wichtigste Identifikationsmerkmal.
2. origin
Typ: Char. Referenz auf das auslösende Dokument, etwa der Name der Verkaufs‑ oder Bestellung. Hilft beim Zurückverfolgen der Herkunft einer Bewegung.
3. state
Typ: Selection. Zeigt den aktuellen Status der Bewegung an (z. B. Entwurf, Wartet, Bereit, Erledigt, Storniert). Der State steuert, welche Aktionen möglich sind und wird aus den zugeordneten Moves abgeleitet.
4. picking_type_id
Typ: Many2one (stock.picking.type). Legt den Vorgangstyp fest — Wareneingang, Auslieferung oder interne Verlagerung. Bestimmt Standard‑Quell‑ und Zielorte und ist beim Anlegen meist Pflicht.
5. move_ids
Typ: One2many (stock.move). Die eigentlichen Positionszeilen: Produkt und Menge, die bewegt werden. Auf diesen Moves laufen Reservierungen, Verfügbarkeitsprüfungen und die meiste Logik.
6. move_line_ids
Typ: One2many (stock.move.line). Detaillierte Operationen — Seriennummern, Losnummern und konkrete Lagerplätze werden hier festgehalten. Relevant beim Kommissionieren, Verpacken und Validieren.
7. location_id
Typ: Many2one (stock.location). Der Quellort, aus dem die Waren entnommen werden. Bei Auslieferungen typischerweise das Lager, bei Eingängen der Lieferantenort.
8. location_dest_id
Typ: Many2one (stock.location). Der Zielort, an den die Waren gehen. Bei Lieferungen meist Kunde, bei Eingängen das Lager.
9. partner_id
Typ: Many2one (res.partner). Ansprechpartner oder Geschäftspartner — Kunde bei Auslieferungen, Lieferant bei Eingängen. Wichtig für Adressen, Papiere und Versanddienstleister.
10. scheduled_date
Typ: Datetime. Geplanter Zeitpunkt der Bearbeitung. Dient der Priorisierung und Einsatzplanung; eine manuelle Anpassung beeinflusst meist alle zugehörigen Moves.
11. date_deadline
Typ: Datetime. Liefer‑ oder Fertigstellungsfrist — häufig aus der Bestellung oder dem Verkaufsversprechen übernommen. Hilft, verspätete Bewegungen zu erkennen.
12. date_done
Typ: Datetime. Zeitpunkt der abschließenden Bestätigung oder Stornierung. Wird automatisch gesetzt und ist schreibgeschützt.
13. priority
Typ: Selection. Prioritätsstufe; bei Knappheit werden erst Bewegungen mit höherer Priorität bedient — nützlich für dringende Aufträge.
14. move_type
Typ: Selection. Versandpolitik: Sofort (Teillieferungen möglich) oder Warten bis alles bereit ist (Komplettlieferung). Beeinflusst, wann eine Bewegung verarbeitet werden kann.
15. user_id
Typ: Many2one (res.users). Zuständiger Bearbeiter — wichtig für Zuordnung, Aufgabenplanung und Workload‑Reporting. Beim Anlegen wird oft der aktuelle Benutzer vorgeschlagen.
16. company_id
Typ: Many2one (res.company). Zugehörige Firma; in Multi‑Company‑Szenarien bestimmt das die Eigentümerschaft der Bewegung.
17. group_id
Typ: Many2one (procurement.group). Gruppierungskennzeichen für zusammengehörige Beschaffungen oder Aufträge — nützlich, wenn mehrere Pickings aus einem Auftrag entstehen.
18. backorder_id
Typ: Many2one (stock.picking). Verweist auf das übergeordnete Picking, wenn bei Teillieferungen eine Nachfolgebewegung (Backorder) angelegt wurde.
19. backorder_ids
Typ: One2many (stock.picking). Liste der aus dieser Bewegung entstandenen Backorders — hilfreich, um offene Teilmengen zu verwalten.
20. return_id
Typ: Many2one (stock.picking). Verknüpft Rücksendungen mit dem ursprünglichen Beleg — wichtig für Retourenprozesse.
21. note
Typ: Html. Interne Hinweise und Anleitungen für das Lagerpersonal — spezielle Handhabung, Verpackungsanweisungen etc.
22. signature
Typ: Image. Unterschrift, die bei Übergabe erfasst wird; dient als Zustellnachweis und wird als Anhang gespeichert.
23. is_signed
Typ: Boolean. Vom System errechnet, zeigt an, ob bereits eine Unterschrift vorliegt.
24. owner_id
Typ: Many2one (res.partner). Eigentümerangabe für Konsignationsware oder Waren Dritter, die verwaltet werden.
25. package_level_ids
Typ: One2many (stock.package_level). Verpackungsebenen beim Packprozess — fasst Move Lines zu Paketen zusammen.
26. create_date
Typ: Datetime. Zeitpunkt der Erstellung des Datensatzes; automatisch verwaltet.
27. write_date
Typ: Datetime. Zeitpunkt der letzten Änderung; automatisch verwaltet.
28. active
Typ: Boolean. Archivierungskennzeichen: false bedeutet, der Datensatz ist inaktiv (soft delete).
Wie dieses Modell in Geschäftsprozessen genutzt wird
1. Verkauf und Auslieferung
Bei bestätigten Verkaufsaufträgen erzeugt Odoo ein Auslieferungs‑Picking. Dieses ist mit dem Auftrag über origin verknüpft; das Lager kommissioniert, verpackt und bestätigt die Bewegung, wodurch sich der Status Schritt für Schritt von Entwurf zu Erledigt ändert.
2. Einkauf und Wareneingang
Bestätigte Bestellungen erzeugen eingehende Pickings, die Lieferantenware in das Lager bringen. partner_id ist hier der Lieferant; nach Bestätigung werden Lagerbestände angepasst.
3. Interne Verlagerungen
Umlagerungen zwischen Standorten oder Lagern werden als interne Pickings angelegt — pickingt_type_id kennzeichnet diese in der Regel als 'internal', Quell‑ und Zielort sind intern definiert.
4. Retouren und Backorders
Bei Kundenrücksendungen legt Odoo ein Return‑Picking an, das über return_id auf die ursprüngliche Auslieferung verweist. Teilweise bestätigte Lieferungen erzeugen Backorders, die als separate Pickings weiterverarbeitet werden.
5. Produktion und Fertigung
Fertigungsaufträge erzeugen Pickings sowohl für die Entnahme von Rohmaterialien als auch für die Einlagerung fertiger Teile. Das mrp‑Modul erweitert stock.picking um fertigungsspezifische Abläufe.
Wie Entwickler das Modell erweitern können
Entwickler erweitern stock.picking mit bewährten Mustern; Hauptwerkzeug ist die Odoo‑Modellvererbung.
Modell‑Vererbung
Mit _inherit = 'stock.picking' erweitern Sie das bestehende Modell: neue Felder hinzufügen, Methoden überschreiben oder Validierungen ergänzen. So bleiben Erweiterungen in eigenen Modulen getrennt und lassen sich bei Updates leichter pflegen.
Felder hinzufügen
Neue Felder definieren Sie im geerbten Modell — wählen Sie passende Typen (Char, Many2one, Boolean, Integer, Text, Selection). Bei Multi‑Company‑Setups an company‑abhängige Felder denken.
Python‑Erweiterungen
Überschreiben Sie gezielt Methoden wie button_validate, action_assign oder _create_backorder, um zusätzliche Logik einzubauen. Rufen Sie super() auf, um Grundverhalten zu erhalten, und testen Sie Übergänge und Move‑Erzeugung sorgfältig.
Odoo Studio
Odoo Studio ist praktisch für schnelle Anpassungen ohne Code — etwa zusätzliche Notizen oder Anzeige‑Felder. Für tiefere Integrationen oder komplexe Regeln sind Custom‑Module hingegen nachhaltiger.
Empfohlene Vorgehensweisen
- Setzen Sie beim manuellen Anlegen von Pickings immer das picking_type_id. Es steuert Standardorte und Verhalten und verhindert falsche Defaults.
- Nutzen Sie das origin‑Feld konsequent, um die Quelle der Bewegung zu dokumentieren — das erleichtert Reporting und Fehleranalyse.
- Bei API‑Integrationen ist stock.picking über die Odoo API vollständig verfügbar. Legen Sie Moves über move_ids an; vermeiden Sie Pickings ohne zugehörige Moves, da diese in der Regel keinen Sinn ergeben.
- Planen Sie mit scheduled_date. Dieses Datum beeinflusst Reservierungen und Priorisierung in der Kommissionierung.
- Für eigene Felder verwenden Sie ein Modulpräfix (oder x_), um Namenskonflikte mit zukünftigen Odoo‑Versionen zu vermeiden.
Häufige Fehler
- Ohne picking_type_id Pickings erstellen. Das führt leicht zu falschen Standard‑Quell‑ und Zielorten.
- move_ids nach Bestätigung verändern, ohne die Zustandsmaschine zu verstehen. State‑Übergänge können komplexe Folgen haben.
- partner_id bei Auslieferungen vergessen. Versanddienstleister und Dokumente benötigen die Kontaktangaben.
- button_validate überschreiben, ohne super() aufzurufen. Das kann Backorder‑Logik und andere Erweiterungen zerstören.
- Zu glauben, move_ids und move_line_ids seien immer synchron. Move Lines entstehen bei Reservierung oder detailliertem Ablauf — sie sind nicht automatisch identisch mit den Moves.
Fazit
stock.picking ist das Herzstück der Odoo‑Lagerverwaltung: Es bildet Bewegungen, Eingänge und Auslieferungen ab. Wer seine Felder, Erweiterungsmöglichkeiten und Austauschpunkte kennt, kann Odoo effizient konfigurieren und zuverlässig integrieren.
Egal ob Sie Prozesse im Lager abbilden oder eigene Module entwickeln: Gute Kenntnisse des stock.picking‑Modells sparen Zeit und vermeiden Fehler in Live‑Systemen.
Bereit, Ihr Odoo‑Lager zu optimieren?
Das Team von Dasolo unterstützt Unternehmen bei Implementierung, Anpassung und Optimierung von Odoo. Wir haben viel Erfahrung mit Datenarchitektur, API‑Integrationen und Modellerweiterungen wie stock.picking.
Wenn Sie Unterstützung bei Ihrem Odoo‑Projekt, Lageranpassungen oder Integrationen brauchen, sprechen Sie uns gern an. Demo vereinbaren und Ihr Projekt besprechen.