Introduktion
I Odoo organiseres al forretningsdata i modeller — det er her poster om ordrer, bevægelser og lagerhandlinger gemmes. Hver model beskriver hvilke oplysninger, der skal gemmes, og hvordan de relaterer til hinanden i databasen.
For både konsulenter og udviklere er det afgørende at forstå modellerne. De udgør Odoos dataramme: felter, relationer og den forretningslogik, som bestemmer adfærd og rapportering i systemet.
Denne artikel går i dybden med en kernekomponent i Lager-appen: stock.picking. Uanset om du laver kundetilpasninger, bygger integrationer eller sætter lagerprocesser op, vil du møde og arbejde med denne model.
Hvad er stock.picking-modellen
I korte træk repræsenterer stock.picking en enkelt vareoverførsel i systemet. Hver post dokumenterer et flyt fra én lokation til en anden og er stedet, hvor status, ansvar og detaljer for en transport registreres.
Modellen bruges til alle lagerbevægelser i Inventory-modulet: indgående leverancer, udgående leverancer og interne overførsler. Når du bekræfter en salgslevering, modtager en vare fra en leverandør eller flytter varer internt, oprettes eller opdateres et stock.picking-objekt.
Definitionen ligger i stock-modulet, men mange andre moduler bygger videre på den via Odoos arvemønstre. Salg tilføjer eksempelvis leveringsfelter, Indkøb håndterer modtagelser, og Produktion tilføjer materialeflyt — uden at genopfinde den grundlæggende struktur.
stock.picking arver fra kommunikationsværktøjer som mail.thread og mail.activity.mixin, så du får chatter, aktivitetsplanlægning og sporing af ændringer direkte på overførslerne.
Væsentlige felter i modellen
Nedenfor gennemgår vi de vigtigste felter i stock.picking — kendskab til dem gør det lettere at konfigurere processer, bygge integrationer og fejlfinde lagerflowet.
1. name
Type: Char. Nummeret eller referencen for overførslen. Typisk genereret fra en sekvens (fx WH/OUT/00001) og bruges som hovedidentifikator i skærme og dokumenter.
2. origin
Type: Char. Referencen til kildeordren — fx salgsordrenummer eller indkøbsordre — som gør det muligt at spore, hvor bevægelsen udspringer fra.
3. state
Type: Selection. Statusfeltet for overførslen. Værdier som udkast, klar, udført eller annulleret styrer hvilke handlinger der kan udføres og beregnes ud fra de tilknyttede stock.moves.
4. picking_type_id
Type: Many2one (stock.picking.type). Bestemmer om det er indgående, udgående eller intern post. Picking-typen sætter typiske standard-lokationer og adfærd og er normalt obligatorisk.
5. move_ids
Type: One2many (stock.move). Selve bevægelserne — hver linje angiver et produkt og en mængde, som skal flyttes. Reservation, tilgængelighed og lagerlogik opererer primært på disse poster.
6. move_line_ids
Type: One2many (stock.move.line). De detaljerede pluk-/pakke-linjer. Her registreres specifikke serier/lots, konkrete lokationer og den fysiske håndtering ved validering og pakning.
7. location_id
Type: Many2one (stock.location). Afgivende lokation — hvor varerne tages fra. Feltet er nødvendigt og afhænger af pick-typen (fx lagerlokation ved udgående).
8. location_dest_id
Type: Many2one (stock.location). Modtagende lokation — hvor varerne skal hen. Også obligatorisk og bestemmes ofte af picking-typen.
9. partner_id
Type: Many2one (res.partner). Den eksterne part for forsendelsen — kunde ved udgående, leverandør ved indgående. Bruges til adresser, dokumenter og transportintegrationer.
10. scheduled_date
Type: Datetime. Den planlagte dato/tid for håndtering. Anvendes i planlægning og prioritering — sætter forventet behandlingstid for alle underliggende bevægelser.
11. date_deadline
Type: Datetime. Frist for overførslen, typisk arvet fra salgs- eller indkøbsordre. Bruges til at identificere forsinkelser og leveringsforpligtelser.
12. date_done
Type: Datetime. Tidspunktet for når overførslen blev validere eller annulleret. Feltet er læsbart og opdateres automatisk ved gennemførelse.
13. priority
Type: Selection. Prioritetsniveauet for reservationer. Højere prioritet får forrang ved tildeling af lagerbeholdning ved knaphed.
14. move_type
Type: Selection. Forsendelsespolitik — fx delvis levering tilladt (afsend så snart muligt) eller afsend ved fuld tilgængelighed. Påvirker hvornår pluk kan udføres.
15. user_id
Type: Many2one (res.users). Den ansvarlige medarbejder. Bruges til tildeling og arbejdsbyrdeovervågning; default er brugeren, der opretter posten.
16. company_id
Type: Many2one (res.company). Angiver hvilket selskab posten tilhører i multi-company setups; typisk relateret fra picking-typen.
17. group_id
Type: Many2one (procurement.group). Knytter relaterede bevægelser sammen, fx når flere leveringstrin hører til samme salg eller kundecase.
18. backorder_id
Type: Many2one (stock.picking). Reference til original plukning, hvis der oprettes en restordre ved delvis validering.
19. backorder_ids
Type: One2many (stock.picking). De restordrer som er oprettet ud fra denne pick — praktisk ved delvis levering og efterfølgende håndtering.
20. return_id
Type: Many2one (stock.picking). Hvis posten stammer fra en returnering, peger dette felt på den oprindelige levering og bruges i returflows.
21. note
Type: Html. Interne noter og instruktioner til lagerpersonale — fx særlige håndteringskrav eller kundespecifikke anvisninger.
22. signature
Type: Image. Gemt signatur ved levering som bevis for modtagelse. Typisk lagret som en vedhæftet fil.
23. is_signed
Type: Boolean. Beregnet ud fra om der findes en signatur — indikerer om leveringen er bekræftet af modtageren.
24. owner_id
Type: Many2one (res.partner). Angiver ejer ved validering — relevant ved kommissionerings-forhold eller varer ejet af tredjepart.
25. package_level_ids
Type: One2many (stock.package_level). Pakke-grupperinger ved brug af pakkesporing; organiserer move lines i forsendelsespakker.
26. create_date
Type: Datetime. Tidsstempel for oprettelse. Håndteres automatisk af Odoo og arves fra basismodellen.
27. write_date
Type: Datetime. Sidste ændringsdato. Også automatisk; nyttigt til revision og sporing.
28. active
Type: Boolean. Blødt sletningsflag — sæt til False for at arkivere poster uden at fjerne dem fra databasen.
Hvordan modellen indgår i forretningsprocesser
1. Salg og udgående leverancer
Når en salgsordre bekræftes, opretter systemet en leveringsordre i form af et stock.picking. Lagerpersonalet plukker, pakker og validerer, og posten ændrer status fra udkast til udført i takt med processen.
2. Indkøb og modtagelser
Bekræftes en indkøbsordre, oprettes en indgående modtagelse. Pickingen repræsenterer flyt fra leverandørlokation til lager, og modtagelsen opdaterer beholdningerne ved validering.
3. Interne flytninger
Flytning mellem egne lagerlokationer oprettes som interne pickinger, hvor picking-typen typisk har koden 'internal' og både kilde og mål er interne lagerlokationer.
4. Returneringer og restordrer
Returnerer en kunde varer, oprettes en retur-picking med reference til originalleverancen. Ved delvis validering oprettes restordrer, som knytter sig til den oprindelige post.
5. Produktion og fremstilling
Produktionsordrer genererer pickinger for forbrug af råmaterialer og for færdigvarer. Mrp-modulet udvider stock.picking for at håndtere disse produktionsflows.
Hvordan udviklere udvider modellen
Udviklere tilpasser stock.picking med flere tilgange, hvor Odoos arvemodel er den mest brugte metode.
Modelarv
Ved at bruge _inherit = 'stock.picking' kan du tilføje felter, overskrive metoder eller definere nye begrænsninger. Ændringer ligger i en separat modulpakke, hvilket gør opgraderinger og vedligehold enklere.
Tilføjelse af felter
Tilføj nye Odoo-felter i din udvidelse med passende typer (Char, Many2one, Boolean, Integer, Text, Selection). Overvej company-dependency for felter i multi-company miljøer.
Python-udvidelser
Overskriv metoder som button_validate, action_assign eller _create_backorder for at indsætte forretningslogik — brug altid super() for at bevare eksisterende adfærd og vær opmærksom på tilstandsmaskinens kompleksitet.
Odoo Studio
Studio er brugervenligt til hurtige tilpasninger uden kode, fx ekstra felter eller etiketter. Til avanceret logik, integrationskrav eller genbrugelige løsninger er et egentligt modul dog mere robust.
Bedste fremgangsmåder
- Sørg altid for at sætte picking_type_id ved manuel oprettelse af pickings — det sikrer korrekte standardlokationer og forventet adfærd.
- Brug origin-feltet konsekvent til at kunne spore poster tilbage til kildeordrer — det hjælper meget i rapportering og fejlsøgning.
- Ved API-integrationer er stock.picking fuldt eksponeret. Opret stock.moves via move_ids-relationen — undgå at oprette pickings uden tilhørende moves, da det skaber ufuldstændige poster.
- Benyt scheduled_date til planlægning; det påvirker prioritering og reservation af varer i lagerstyringen.
- Til nye felter anbefales x_- eller modulpræfikser for at undgå navnekonflikter med fremtidige Odoo-opdateringer.
Almindelige fejl
- At oprette pickings uden picking_type_id kan føre til forkerte default-lokationer og uventet adfærd.
- Ændringer af move_ids efter bekræftelse uden kendskab til tilstandsmaskinen kan bryde flows — manipulering skal ske med omtanke.
- Mangler partner_id på leveringer giver problemer med forsendelsesberegning og dokumentudskrifter — sørg for kontaktdata på leveringer.
- At overskrive button_validate uden at kalde super() kan ødelægge restordrelogik og konflikte med andre moduler — altid bevare grundadfærden.
- Antag ikke at move_ids og move_line_ids altid er synkroniserede; move_lines oprettes ved reservation eller detaljeret håndtering, så deres indhold kan afvige før validering.
Konklusion
stock.picking er lagrets centrale model: den dokumenterer overførsler, leverancer og modtagelser. At kende dens felter og udvidelsesmuligheder gør det lettere at konfigurere Odoo korrekt og bygge stabile integrationer.
Uanset om du kortlægger lagerprocesser som functional consultant eller udvikler et specialmodul, sparer en solid forståelse af stock.picking både tid og fejl under implementeringen.
Klar til at optimere dit Odoo-lager?
Dasolo hjælper virksomheder med at implementere og optimere Odoo — særligt inden for lager, API-integrationer og tilpasninger. Vi har dyb viden om Odoos datamodel og erfaring med komplekse flows som stock.picking.
Har I brug for hjælp til Odoo-opsætning, lagertilpasninger eller integrationer, står vi klar til at assistere. Book en demo og lad os tage en snak om dit projekt.