Introduktion
I Odoo definerer modeller, hvordan forretningsdata organiseres og gemmes. Alle konkrete datapunkter — fra ordrer til fakturaer og lagerbevægelser — lever i hver sin model, der dikterer struktur, relationer og validering.
At have styr på Odoo-modeller er vigtigt både for udviklere og forretningskonsulenter. Modeller er grundstenen i systemets datalandskab: de angiver felter, relationer mellem poster og hvor forretningslogik hører hjemme.
Denne guide zoomer ind på en af de mest centrale modeller i Odoo: stock.move. Uanset om du bygger lagerudvidelser, kobler eksterne systemer op eller konfigurerer vareflow, vil du møde stock.move igen og igen.
Hvad er stock.move-modellen
stock.move beskriver en enkelt bevægelse af varer i lageret — altså overførslen af et produkt fra ét sted til et andet. Hver gang noget flyttes fra hylde til palle, mellem lagre eller sendes til kunde, oprettes eller opdateres en stock.move-post.
Inventory-modulet (Lager) er den primære bruger af modellen. Salg, indkøb, produktion og webshoppen genererer stock.move-poster, når de igangsætter lagerhandlinger. Bekræftelse af en levering, modtagelse af varer eller afslutning af en produktionsordre vil dermed skabe eller ændre stock.move-records.
Modellen ligger i stock-modulet og kan udvides af andre apps via Odoos arve-mekanisme. Salg tilføjer fx et link til salgslinjen, indkøb tilføjer et felt til indkøbslinjen og produktion knytter moves til produktionsordrer. Hver app bygger ovenpå kernen uden at kopiere den.
Væsentlige felter i modellen
Her er de vigtigste felter i stock.move, som du regelmæssigt vil bruge. Kendskab til dem gør det lettere at arbejde med lagerflow og integrationer.
1. name
Type: Char. Feltet indeholder en kort beskrivelse eller titel på bevægelsen. Det er ofte sammensat af produktnavn og antal og vises i lister og dokumenter som den primære identifikation.
2. product_id
Type: Many2one (product.product). Angiver hvilket produkt flytningen handler om. Krævet. Odoo bruger dette felt til lageroptælling, reservation og regler for håndtering.
3. product_uom
Type: Many2one (uom.uom). Enhed for mængden — fx stk., kg eller liter. Dette felt bestemmer, hvordan mængder valideres og vises.
4. product_uom_qty
Type: Float. Den planlagte/efterspurgte mængde i produktets enhed. Det er den forventede mængde der skal flyttes; når arbejdet udføres, opdateres quantity_done.
5. quantity
Type: Float. Visnings- eller beregnet felt for mængde. Kan være identisk med product_uom_qty eller vise en konverteret værdi for brugerens bekvemmelighed.
6. location_id
Type: Many2one (stock.location). Kilden — hvor varerne kommer fra. Skal være korrekt sat, for ellers bliver lagerbeholdningen forkert.
7. location_dest_id
Type: Many2one (stock.location). Destinationen — hvor varerne sendes hen. Også et påkrævet felt, afgørende for korrekt lagerstyring.
8. picking_id
Type: Many2one (stock.picking). Den overordnede overførsel eller plukkeliste, som samler moves til en operation (levering, modtagelse eller intern flytning).
9. picking_type_id
Type: Many2one (stock.picking.type). Operationstypen — fx udgående, indgående eller intern. Bestemmer arbejdsgangen og standardlokationer.
10. state
Type: Selection. Angiver status: draft, waiting, confirmed, assigned, done, cancelled. Fx betyder assigned at varerne er reserveret, done at flytningen er fuldført.
11. date
Type: Datetime. Planlagt dato/tid for bevægelsen. Bruges til prioritering og planlægning af pluk/leverancer.
12. date_deadline
Type: Datetime. Sidste frist for gennemførsel — ofte den lovede leveringsdato til kunden. Indgår i beregninger af hastende ordrer.
13. origin
Type: Char. Reference tilbage til oprindelsesdokumentet, fx salg- eller indkøbsnummer. Vigtigt for sporbarhed og audit.
14. move_dest_id
Type: Many2one (stock.move). Link til en efterfølgende bevægelse i en kæde. Bruges når én bevægelse munder ud i en anden, fx produktionens output til en forsendelse.
15. move_orig_ids
Type: One2many (stock.move). Liste over bevægelser, der har leveret input til denne move — inverse relation til move_dest_id for at følge flowet baglæns.
16. move_line_ids
Type: One2many (stock.move.line). Detaljerede linjer med batch-/lot- eller serienummerinformation og specifikke lokationsoplysninger. Oprettes ved reservation og behandling.
17. partner_id
Type: Many2one (res.partner). Den relevante forretningspartner — kunde ved udgående leverancer eller leverandør ved modtagelser. Brugt til adresse og rapportering.
18. company_id
Type: Many2one (res.company). Angiver hvilken virksomhed i en multi-company-opsætning posten hører til. Påvirker synlighed og regler for tværgående bevægelser.
19. quantity_done
Type: Float. Den faktisk behandlede mængde. Når pluk eller modtagelse udføres, sættes dette felt; move markeres som done når det svarer til product_uom_qty.
20. reserved_availability
Type: Float. Hvor meget af varen der er reserveret til denne move. Viser hvor meget lager der er allokeret ved assignment.
21. create_date
Type: Datetime. Tidsstempel for hvornår posten blev oprettet. Automatisk vedligeholdt og nyttigt i audits og rapporter.
22. write_date
Type: Datetime. Tidsstempel for sidste ændring. Hjælper med at spore opdateringer og hvornår data sidst blev berørt.
23. sequence
Type: Integer. Bruges til sortering inden for en picking; lavere værdier vises først for at styre rækkefølgen i UI.
24. priority
Type: Selection. Prioritetsniveau — typisk normal eller hastende. Indgår i planlægning, så kritiske bevægelser behandles først.
25. description_picking
Type: Char. Notat eller instruktion til håndtering, der vises på pluk- og forsendelsesdokumenter.
26. reference
Type: Char. Intern referencekode til mapping eller ekstern integration.
27. group_id
Type: Many2one (procurement.group). Samler bevægelser der hører til samme indkøbs-/procurement-gruppe, nyttigt ved planlægning og kildesporing.
28. procure_method
Type: Selection. Angiver strategi: make-to-stock eller make-to-order. Bestemmer om der bruges lagervarer eller oprettes indkøb/produktion.
29. sale_line_id
Type: Many2one (sale.order.line). Feltet som salgsmodulet lægger til for at linke bevægelsen til den specifikke salgsordrelinje.
30. purchase_line_id
Type: Many2one (purchase.order.line). Indkøbsmodulet tilføjer dette for at knytte modtagelsen til en indkøbsordrelinje.
31. production_id
Type: Many2one (mrp.production). Produktionsmodulet linker moves til produktionsordren, både for råvareforbrug og færdigvareoutput.
32. active
Type: Boolean. Soft-delete-flag: når False er posten arkiveret og skjult fra standardvisninger uden at blive fysisk slettet.
Hvordan modellen anvendes i forretningsprocesser
1. Kundelevering
Når en salgsordre bekræftes, oprettes der per varelinje en stock.move med lagerlokationen som kilde og kundelokationen som destination. Moves samles i en picking (leveringsordre). Under pluk og afsendelse opdateres quantity_done og status sættes til done.
2. Leverandørmodtagelse
Ved bekræftet indkøbsordre oprettes incoming moves: leverandørlokation som kilde og lager som destination. Moves samles i en receipt, og ved modtagelse angiver brugeren quantity_done for at fuldføre posten.
3. Interne flytninger
Når varer flyttes mellem afdelinger eller lagre, oprettes stock.move-poster med korrekt kilde- og destinationslokation. Anvendes til genopfyldning, omrokering eller multi-lagerstyring.
4. Produktion
Produktionsordrer genererer både moves til råmaterialer (fra lager til produktion) og for færdigvarer (fra produktion til lager). production_id binder moves til ordren, og kædelink via move_dest_id sikrer at output kan fødes direkte videre til fx leverancer.
5. Returneringer og skrot
Kunde returneringer aktiverer omvendte moves, mens skrot oprettes som bevægelser til en skrotlokation. Samme model håndterer alle flow; picking_type_id styrer præcis arbejdsgang.
Sådan udvider udviklere modellen
Udviklere bygger ovenpå stock.move via flere mønstre, hvor Odoos modelarv er det centrale værktøj.
Modelarv
Sæt _inherit = 'stock.move' i dit modul for at udvide modellen. Her kan du tilføje felter, overskrive metoder eller lægge constraints ind. Ved at holde ændringer i et separat modul bliver opgraderinger og vedligehold enklere.
Tilføje felter
Definér nye felter i din arvede model med passende typer: Char, Many2one, Boolean, Integer, Text, Selection osv. Overvej company-dependent felter i multi-company-scenarier. Typiske udvidelser er sporingsnumre, transportørreferencer eller batch-attributter.
Python-udvidelser
Overskriv metoder som _action_done, _action_assign eller _action_cancel for at indsætte logik ved afslutning, tildeling eller annullering. Husk altid at kalde super() hvor det giver mening, så grundfunktionaliteten og lageropdateringer ikke brydes.
Odoo Studio
Odoo Studio gør det hurtigt at tilføje felter og simple tilpasninger uden kode — god til prototyper eller små ændringer. For kompleks workflow eller avanceret logik anbefales modul-baserede løsninger for bedre sporbarhed og versionering.
Gode fremgangsmåder
- Sørg for altid at sætte både location_id og location_dest_id korrekt — fejlagtige lokationer skaber hurtigt forkerte beholdninger.
- Grupper relaterede moves med picking_id i stedet for at oprette løse moves. Picks holder operationer sammen og bevarer reservation- og pluklogik.
- Til API-integrationer: brug XML-RPC eller JSON-RPC og map eksterne ID'er konsekvent. stock.move er tilgængelig via Odoos API, men vær opmærksom på afhængigheder og state-transitioner.
- Navngiv egne felter med x_ eller et modul-præfiks for at undgå navnekonflikter ved fremtidige Odoo-opgraderinger.
- Brug move_dest_id og move_orig_ids aktivt til sporbarhed. Når du opretter kædede moves programmatisk, sæt disse links korrekt for at undgå tabt sammenhæng.
- Skel mellem product_uom_qty (planlagt) og quantity_done (faktisk). Systemet understøtter delpluk; valideringer og rapporter bør tage højde for dette.
Almindelige fejltagelser
- Oprettelse af moves med inkompatible lokationstyper — f.eks. kilde og destination begge sat til kunde — fører til logiske fejl og skal undgås.
- Ændring af product_uom_qty efter at move lines allerede eksisterer kan skabe lagerinconsistenser. Hvis det er nødvendigt, annuller og gengiv moves i stedet.
- Glem ikke origin-feltet. Uden reference tilbage til SO/PO/MO bliver sporing og fejlsøgning langt sværere.
- Overskriv ikke _action_done uden at kalde super(): ellers kan lagerstamdata eller andre afhængige moduler blive påvirket negativt.
- Undlad at oprette moves direkte uden korrekt workflow (fx uden stock.picking). At omgå picking bryder reservationer og assignment-logik.
- Når du splitter eller samler moves, husk at opdatere move_dest_id. Ellers kan kæder blive forældreløse og sporbarheden gå tabt.
Afrunding
stock.move er nøglen i Odoos lagerstyring — den registrerer enhver bevægelse mellem lokationer. Kendskab til felter, relationer og udvidelsesmuligheder gør det muligt at konfigurere, tilpasse og integrere lagerflow korrekt.
Uanset om du kortlægger processer som funktionel konsulent eller udvikler specialmoduler, vil en solid forståelse af stock.move spare tid og minimere fejl.
Brug for hjælp til din Odoo-implementering?
Dasolo hjælper virksomheder med at implementere, tilpasse og optimere Odoo. Vi har særlig erfaring med API-integrationer og udvikling, og kender Odoos datamodel — herunder centrale modeller som stock.move — i dybden.
Har du brug for hjælp til implementering, udvikling af custom modules eller integrationer i Odoo, står vi klar til at assistere. Book en demo for at drøfte dit projekt.