Introduktion
I Odoo beskriver modeller, hvordan forretningsdata organiseres og gemmes i databasen. Alt fra indkøbsordrer til lagerbeholdning og fakturaer repræsenteres via modeller — de er skabelonerne, som bestemmer felttyper, relationer og hvordan poster opbevares.
At forstå modeller er afgørende både for konsulenter og udviklere. Modeller udgør rygraden i Odoo’s datadesign: de fastsætter felterne, relationerne mellem objekter og den forretningslogik, som systemet følger i drift.
Denne artikel dykker ned i en central model i Odoo: purchase.order. Uanset om du sætter op, udvikler integrationer eller bygger tilretninger til indkøbsprocessen, kommer du til at arbejde med denne model.
Hvad er purchase.order‑modellen
purchase.order står for indkøbsordrer og forespørgsler (RFQ). Det er det sted, hvor hele indkøbsflowet dokumenteres, før transaktionerne bliver til modtagelser i lageret eller leverandørfakturaer i regnskabet.
Modellen bruges af Indkøbs‑modulet. Når en køber opretter en RFQ, oprettes en purchase.order‑post i Odoo. Når leverandøren bekræfter — eller køberen godkender internt — skifter posten fra kladde til bekræftet. Samme model håndterer både ubehandlede RFQ’er og endelige ordrer; feltet der hedder state styrer livscyklussen.
Andre moduler bygger videre på modellen via Odoos arve‑mekanismer. Lagerlogik tilføjes af Inventory, økonomifunktioner af Accounting, og Manufacturing kan oprette ordrer fra styklister. Hver app lægger ekstra funktionalitet ovenpå kerne‑strukturen uden at duplikere den.
Væsentlige felter i modellen
Her er de felter i purchase.order, som er vigtigst at kende. Kendskabet gør det nemmere at konfigurere, rapportere og integrere indkøbsprocessen.
1. name
Type: Char. Indeholder ordrenummeret (fx PO00042). Ofte autogenereret og bruges som den primære reference i lister, søgninger og på udskrifter.
2. state
Type: Selection. Angiver hvor i processen ordren befinder sig. Typiske værdier: draft (RFQ), sent, to approve, purchase (bekræftet), done (modtaget/faktureret), cancel. State afgør hvilke knapper og handlinger der er tilgængelige.
3. partner_id
Type: Many2one (res.partner). Leverandøren. Påkrævet. Bruges til kontaktinformation, priser, betalingsbetingelser og rapportering mod leverandøren.
4. partner_ref
Type: Char. Leverandørens referencenummer eller deres PO‑nummer. Vises på dokumenter og hjælper med at matche leverandørens dokumenter med jeres ordrehistorik.
5. date_order
Type: Datetime. Ordredato — ved kladder er det oprettelsesdatoen, ved bekræftede ordrer er det bekræftelsesdatoen. Bruges ved sortering og rapportering samt som default dato på linjer.
6. date_approve
Type: Datetime. Tidspunkt for godkendelse/bekræftelse. Sættes når ordren skifter til purchase. Læsbart feltnavn, nyttigt i revisionsspor.
7. order_line
Type: One2many (purchase.order.line). Ordrenes linjer. Hver linje rummer produkt, antal, pris og skatter — det konkrete indhold i ordren.
8. amount_untaxed
Type: Float. Subtotal før skat. Beregnes fra ordrelinjerne og bruges i visninger og rapporter.
9. amount_tax
Type: Float. Den samlede skattepost. Beregnes ud fra linjernes skatteopsætning og vises både på ordre og faktura.
10. amount_total
Type: Float. Totalbeløbet inkl. skat. Centrale tal for fakturering og økonomisk rapportering.
11. currency_id
Type: Many2one (res.currency). Valutaen for ordren. Som regel arvet fra virksomheden eller leverandøren; alle beløb tolkes i denne valuta.
12. origin
Type: Char. Henviser til kildedokumentet — fx en salgsordre eller en produktionsordre, der har trigget indkøbet. Vigtigt for sporbarhed i hele processen.
13. dest_address_id
Type: Many2one (res.partner). Leveringsadressen. Hvis ikke angivet, benyttes virksomhedens adresse. Bruges ofte ved dropshipping, hvor varen sendes direkte til kunden.
14. priority
Type: Selection. Prioritetsmarkør — Normal eller Haster. Bruges til at sortere og fremhæve ordrer, som kræver hurtigere behandling.
15. invoice_status
Type: Selection. Viser faktureringsstatus: no, to invoice, invoiced. Styrer synligheden af handlinger som Opret Faktura.
16. invoice_count
Type: Integer. Antal tilknyttede leverandørfakturaer. Feltet er beregnet og bruges fx til at åbne listen over fakturaer direkte fra ordren.
17. invoice_ids
Type: One2many (account.move). Link til leverandørfakturaer. Giver forbindelse mellem indkøb og regnskab og muliggør trepartsafstemning.
18. picking_ids
Type: One2many (stock.picking). Tilknyttede pluk/leverancer eller modtagelser. Aktivt når lagerappen er installeret og styrer lagerflowet.
19. picking_count
Type: Integer. Antal tilknyttede pluk. Beregnet og brugbart til hurtig navigation til modtagelser fra ordren.
20. create_date
Type: Datetime. Tidspunkt for oprettelse af posten. Styres automatisk af Odoo og nyttigt i rapporter og revisioner.
21. write_date
Type: Datetime. Sidste ændringsdato. Også automatisk vedligeholdt og hjælper med at se, hvornår en post sidst blev opdateret.
22. notes
Type: Text. Tekstfelt til vilkår, betingelser eller interne kommentarer. Kan vises på ordren for særlige instrukser til leverandøren.
23. company_id
Type: Many2one (res.company). Angiver hvilken koncern/enhed ordren tilhører i multi‑company setups. Påvirker adgang og synlighed.
24. user_id
Type: Many2one (res.users). Den ansvarlige køber eller bruger. Bruges i godkendelsesflows og aktivitetsstyring.
25. fiscal_position_id
Type: Many2one (account.fiscal.position). Momsopsætning og skattemæssige regler, fx ved handel på tværs af lande. Bruges til at mappe skatter korrekt.
26. payment_term_id
Type: Many2one (account.payment.term). Betalingsbetingelser — fx netto 30 dage eller delbetalinger. Overføres til leverandørfakturaer ved oprettelse.
27. display_name
Type: Char. Beregnet visningsnavn der kombinerer ordrenummer og leverandøroplysninger. Visningsfelt i mange2one‑søgeresultater.
28. active
Type: Boolean. Blød sletning — når False arkiveres posten og skjules i standardvisninger. Ordrer bliver som regel ikke slettet for at bevare historikken.
Hvordan modellen indgår i forretningsprocesser
1. Fra RFQ til bekræftet ordre
En typisk proces: køber opretter en RFQ i kladde, tilføjer linjer og sender den til leverandøren. Når leverandøren bekræfter (eller køberen godkender internt), skifter ordren til purchase. Herefter kan lager‑modtagelser og leverandørfakturaer oprettes fra ordren.
2. Modtagelse fra leverandør
Når varerne ankommer, oprettes en modtagelse/picking fra ordren. De tilknyttede picking_ids registrerer bevægelserne, modtagne mængder opdaterer lagerbeholdningen, og produktkostpriser kan blive opdateret med indkøbsprisen.
3. Leverandørfaktura
Fra en bekræftet ordre kan du lave leverandørfakturaer, hvor fakturalinjerne hentes fra ordrelinjerne. Betalingsbetingelser og skattemæssig position overføres fra ordren, og invoice_status holder styr på faktureringsforløbet.
4. Dropshipping
Ved dropshipping skabes en indkøbsordre fra en salgsordre; origin peger tilbage til salget, og dest_address_id sættes til kundens adresse, så leverandøren sender direkte til kunden. purchase.order forbinder salg og indkøb i dette flow.
5. Produktion og MRP
Når produktion har brug for råvarer, kan MRP automatisk oprette indkøbsordrer. Origin bruges til at spore tilbage til produktionsordren — modellen er derfor central i procure‑to‑pay cyklussen.
Hvordan udviklere udvider modellen
Udviklere udvider purchase.order med forskellige mønstre — Odoo’s modelarv er det primære værktøj til at føje felter og logik til modellen.
Modelarv
Ved at arve modellen (_inherit = 'purchase.order') kan du tilføje felter, overskrive metoder eller indføre valideringer. Ændringer placeres i egne moduler, så de bliver lettere at vedligeholde og opgradere.
Tilføjelse af felter
Definér nye felter i din arvede model med korrekte typer: Char, Many2one, Boolean, Integer, Text, Selection osv. Overvej virksomhedsspecifikke felter i multi‑company scenarier og brug feltparametre som company_dependent, når det er nødvendigt.
Python‑udvidelser
Overskriv metoder som button_confirm, create eller write for at indføre ekstra validering eller automatisering. Husk altid at kalde super(), og vær opmærksom på afhængigheder for beregnede felter.
Odoo Studio
Odoo Studio er praktisk til hurtige, kodefrie tilpasninger som felter og visninger. For mere avanceret logik og for at sikre fremtidige opgraderinger anbefales custom‑moduler. purchase.order er desuden tilgængelig via XML‑RPC og JSON‑RPC til eksterne integrationer.
Gode fremgangsmåder
- Brug den korrekte state for hvert trin i processen. Undgå at springe stadier over eller omgå bekræftelses‑logik, da workflow‑handlinger afhænger af state.
- Sæt partner_ref når leverandøren angiver deres ref. Det gør match af dokumenter og forsendelser langt lettere i afstemningsprocessen.
- Brug origin til at kunne spore, hvor ordren stammer fra — særligt vigtigt ved dropshipping og ved indkøb initieret af produktion eller salg.
- Ved API‑integrationer: benyt XML‑RPC eller JSON‑RPC. purchase.order er fuldt eksponeret — kortlæg eksterne ID’er med omtanke for at undgå dubletter.
- Navngiv dine egne felter med
x_‑ eller modulprefix for at undgå konflikt med fremtidige Odoo‑felter og sikre en ren migrationssti ved opgraderinger.
Almindelige fejl
- At ændre bekræftede ordrer uden at tjekke state. Bekræftede ordrer har begrænsede felter — brug korrekt workflow eller opret en ny ordre i stedet for at manipulere direkte.
- At forveksle partner_id og dest_address_id. partner_id er leverandøren; dest_address_id er leveringsadressen (ofte kunden ved dropshipping). Forkert brug giver fejl i logistikken.
- At overskrive button_confirm uden at kalde
super(). Det kan bryde funktionalitet fra andre moduler eller skabe uforudsete problemer ved opgraderinger. - At gøre nye, påkrævede felter uden at sætte default‑værdier. Eksisterende records kan fejle validering ved opgradering eller installation, hvis ikke der er passende defaults.
- At glemme currency_id i multi‑valuta scenarier. Manglende eller forkert valuta fører til forkert prisfastsættelse og fejlagtige fakturabeløb.
Afslutning
purchase.order er kernen i Odoos indkøbsfunktionalitet — modellen dokumenterer RFQ’er og bekræftede ordrer. Kendskab til de centrale felter og hvordan andre apps bygger videre på modellen gør det langt nemmere at konfigurere, tilpasse og integrere Odoo.
Uanset om du kortlægger indkøbsprocesser som konsulent eller udvikler tilpasset funktionalitet, vil et sikkert greb om purchase.order reducere fejl og spare tid.
Brug for hjælp til jeres Odoo‑implementering?
Dasolo hjælper virksomheder med at implementere, tilpasse og optimere Odoo. Vi har særlig erfaring med API‑integrationer og udvikling, og vores team arbejder indgående med Odoo’s datamodeler som purchase.order.
Har I brug for assistance med Odoo‑implementering, skræddersyede moduler eller integrationer, står vi klar til at hjælpe. Book en demo for at tage en dialog om jeres projekt.