Innledning
I Odoo organiseres all forretningsdata i modeller. Hver modell beskriver hvordan oppføringer lagres i databasen — fra ordrelinjer og leverandørdata til fakturaer og lagerbevegelser — og danner grunnmuren for hvordan systemet fungerer.
Å ha kontroll på hvordan modeller fungerer er viktig både for konsulenter og utviklere. Modeller definerer felt, relasjoner og forretningslogikk, og det er her prosessregler og dataintegritet håndheves.
Denne artikkelen dykker ned i en av nøkkelmodellene i Odoo: purchase.order. Enten du setter opp innkjøpsflyter, bygger tilpasninger eller integrerer eksterne systemer, vil du ofte støte på og jobbe med denne modellen.
Hva er purchase.order-modellen
purchase.order-modellen representerer innkjøpsordrer og forespørsler om tilbud (RFQ). Her samles alt som skjer i anskaffelsesfasen — fra første forespørsel til bekreftet ordre — før det blir mottak eller leverandørfakturaer.
Modellen brukes primært av Innkjøp-modulen. Når en innkjøper oppretter en RFQ, lages en purchase.order-post. Når leverandør bekrefter eller innkjøper godkjenner, endres status fra utkast til bekreftet. Samme modell håndterer både utkast og endelige ordrer, og et statusfelt følger ordren gjennom livssyklusen.
Flere andre moduler bygger på og utvider denne modellen ved arv. Lager legger på logikk for mottak og plukking, Regnskap knytter på fakturafelter, og Produksjon kan generere bestillinger fra stykklistene. Hver modul tilfører funksjonalitet uten å duplisere kjernen.
Viktige felt i modellen
Under finner du en oversikt over de viktigste feltene i purchase.order. Kjennskap til disse gjør det enklere å sette opp, feilsøke og integrere innkjøp i Odoo.
name
Type: Char. Referansen til ordren (f.eks. PO00042). Vanligvis automatisk generert og brukt som primær identifikator i lister og dokumenter.
state
Type: Selection. Forteller hvor i prosessen ordren er. Vanlige verdier: draft (RFQ), sent (sendt til leverandør), to approve (venter godkjenning), purchase (bekreftet), done (mottatt og fakturert), cancel (avbrutt). Statusen styrer hvilke handlinger som er tilgjengelige.
partner_id
Type: Many2one (res.partner). Leverandøren. Feltet er påkrevd og knytter ordren til riktig leverandør for priser, kontaktinfo og rapportering.
partner_ref
Type: Char. Leverandørens eget ordrenummer eller referanse. Brukes for avstemming mellom dokumenter og vises på utskrifter.
date_order
Type: Datetime. Dato for ordren — opprettes som opprettelsesdato i utkast, og settes til bekreftelsesdato ved godkjenning. Viktig for rapportering og beregninger av forventet leveringstid.
date_approve
Type: Datetime. Tidspunkt for bekreftelse/godkjenning. Settes ved overgang til kjøpstilstand og brukes i revisjonsspor og rapporter.
order_line
Type: One2many (purchase.order.line). Ordrelinjene. Hver linje beskriver produkt, kvantum, pris og skatt — kjernen i innkjøpsordren.
amount_untaxed
Type: Float. Sum før skatt. Beregnes fra ordrelinjene og brukes i visninger og rapporter.
amount_tax
Type: Float. Beregnet skattebeløp fra linjene basert på skatteinnstillinger. Vises på ordren og følger videre til leverandørfaktura.
amount_total
Type: Float. Totalbeløp inkludert skatt. Brukes ved fakturering og økonomirapportering.
currency_id
Type: Many2one (res.currency). Valutaen knyttet til ordren. Hentes ofte fra selskapet eller leverandøren — alle pengesummer bruker denne valutaen.
origin
Type: Char. Kilden til ordren, for eksempel et salgsordrenummer ved dropship eller produksjonsordre ved behovsdekning. Viktig for sporbarhet.
dest_address_id
Type: Many2one (res.partner). Leveringsadresse. Hvis ikke angitt, brukes selskapets adresse. Ved dropshipping settes dette til kundens adresse slik leverandør sender direkte dit.
priority
Type: Selection. Prioritering: Normal eller Haster. Brukes for sortering og for å gi visuell markering av viktige bestillinger.
invoice_status
Type: Selection. Status for fakturering: no (ikke fakturert), to invoice (klar for faktura), invoiced (fakturert). Styrer synlighet av handlinger som Opprett Faktura.
invoice_count
Type: Integer. Antall tilknyttede leverandørfakturaer. Beregnet felt brukt for visning og navigasjon til fakturalisten.
invoice_ids
Type: One2many (account.move). Lenke til leverandørfakturaer. Viktig for treveis avstemming mellom ordre, mottak og faktura.
picking_ids
Type: One2many (stock.picking). Relaterte mottak eller leveranser. Synkes når lager er aktivert og brukes til å oppdatere beholdning ved mottak.
picking_count
Type: Integer. Antall relaterte plukk/mottak. Beregnet og gir rask tilgang til mottaksoversikten.
create_date
Type: Datetime. Tidspunkt for når posten ble opprettet. Odoo setter dette automatisk og det er nyttig i rapporter og revisjonsspor.
write_date
Type: Datetime. Tidspunkt for siste endring. Også automatisk satt og hjelper med å spore oppdateringer.
notes
Type: Text. Felt for interne noter eller leveringsbetingelser som kan vises på ordren. Brukes for spesielle instruksjoner til leverandøren.
company_id
Type: Many2one (res.company). Ved multi-selskap angir dette hvilken enhet ordren tilhører, og påvirker synlighet og tilgangsstyring.
user_id
Type: Many2one (res.users). Ansvarlig innkjøper eller bruker. Brukes i godkjenningsflyt og tildeling av oppgaver.
fiscal_position_id
Type: Many2one (account.fiscal.position). Fiske posisjon for skatemapping ved handel over landegrenser eller spesielle skatteoppsett.
payment_term_id
Type: Many2one (account.payment.term). Betalingsbetingelser som Netto 30, forskudd osv. Overføres til leverandørfakturaer.
display_name
Type: Char. Beregnet visningsnavn som ofte kombinerer ordrenummer og leverandør for enklere valg i nedtrekksmenyer. Leses kun.
active
Type: Boolean. Arkiveringsflagg. Når False skjules ordren fra standardvisninger, men historikken beholdes for sporbarhet.
Hvordan denne modellen brukes i forretningsprosesser
1. Fra RFQ til innkjøpsordre
Prosessen starter typisk med et RFQ i utkast hvor linjer legges inn og sendes til leverandør. Når leverandør eller innkjøper bekrefter, settes status til bekreftet og systemet kan opprette mottak og fakturaer.
2. Leverandørmottak
Når varer ankommer opprettes et mottak som knyttes til ordren (picking_ids). Mottatte mengder oppdaterer lagerbeholdningen, og varekostnad kan justeres basert på kjøpspris.
3. Leverandørfaktura
Fra en bekreftet ordre kan du opprette leverandørfakturaer som henter linjer fra ordren. Betalingsbetingelser og skattemessige innstillinger følger over fra ordren, og invoice_status viser fremdriften.
4. Dropshipping
Ved dropshipping genereres bestillinger fra salgsordre og origin-feltet binder dem sammen. dest_address_id settes til kundeadresse slik leverandør sender direkte til sluttkunde — purchase.order fungerer da som koblingen mellom salg og innkjøp.
5. Produksjon og MRP
Produksjonsordre kan automatisk lage innkjøp for råvarer. Origin-feltet gir sporbarhet til produksjonsordren, og modellen er dermed et sentralt ledd i procure-to-pay-prosessen.
Hvordan utviklere utvider modellen
Utviklere bygger ut purchase.order med flere mønstre hvor modellarv er det vanligste.
Modellarv
For å utvide modellen bruker man _inherit = 'purchase.order'. Da kan man legge til nye felt, overstyre metoder eller legge inn begrensninger. Endringene legges i en modul som gjør det enklere å vedlikeholde og oppgradere.
Legge til felt
Definer nye felt i den arvede modellen med riktig feltetype: Char, Many2one, Boolean, Integer, Text eller Selection. Tenk også gjennom selskapsavhengige felt i multi-selskap-oppsett.
Python-utvidelser
Overstyr metoder som create, write eller button_confirm for å legge inn forretningslogikk, men kall alltid super() når nødvendig. Vær nøye med avhengigheter for beregnede felt slik at de oppdateres korrekt.
Odoo Studio
Odoo Studio gir muligheten til å lage felt og enkle tilpasninger uten kode — raskt og praktisk. For mer avansert logikk eller for å sikre oppgraderbarhet er egne moduler og kodebaserte løsninger ofte å foretrekke. purchase.order er også tilgjengelig via XML-RPC/JSON-RPC for integrasjoner.
Beste praksis
- Bruk riktig status i hvert steg og unngå å hoppe over godkjenningsflyten.
- Registrer partner_ref når leverandøren oppgir sin referanse — det forenkler avstemming mellom dokumenter.
- Bruk origin-feltet aktivt for å spore hvor bestillingen stammer fra, spesielt ved dropshipping eller produksjonsbehov.
- Ved API-integrasjon, benytt XML-RPC eller JSON-RPC og sørg for korrekt mapping av eksterne ID-er for å unngå duplikater eller feilkoblinger.
- Når du legger til egendefinerte felt, prefiks dem med x_ eller et modulnavn for å unngå kollisjoner ved oppgraderinger.
Vanlige feil
- Endring av bekreftede ordrer uten å sjekke status. Mange felt er låst etter bekreftelse — følg korrekt arbeidsflyt eller opprett ny ordre.
- Blande partner_id og dest_address_id. partner_id er leverandør; dest_address_id er leveringssted (brukes ved direktelevering til kunde).
- Å overstyre button_confirm uten å kalle super(). Det kan ødelegge integrasjoner og gjøre oppgraderinger problematiske.
- Legge til obligatoriske egendefinerte felt uten å gi standardverdi. Eksisterende poster kan da feile under oppgradering eller import.
- Glemme å sette valuta_id for leverandører i andre valutaer. Feil valuta gir uriktige kostnader og fakturaer.
Oppsummering
purchase.order er selve navet i Odoos innkjøp: den samler RFQ-er og bekreftede ordrer og gir sporbarhet gjennom mottak og fakturering. Å kjenne modellens felt og hvordan den utvides gjør både konfigurering og integrasjon enklere.
Enten du kartlegger innkjøpsprosesser som funksjonell konsulent eller utvikler egne moduler, vil god innsikt i purchase.order spare tid og redusere risiko for feil.
Trenger du hjelp med Odoo-implementasjonen din?
Dasolo hjelper bedrifter med Odoo-implementasjon, tilpasning og optimalisering. Vi har spisskompetanse på API-integrasjoner og modulutvikling, og god erfaring med Odoos datamodeller som purchase.order.
Trenger du hjelp med implementasjon, egendefinerte moduler eller integrasjoner — ta kontakt, så finner vi en løsning. Book en demo for å diskutere prosjektet ditt.