Innledning
I Odoo beskriver modeller hvordan informasjon organiseres og lagres i databasen. Alt fra kundekontakter til fakturaer og salgsordre ligger i egne modeller som sørger for struktur og konsistens.
Å forstå Odoo‑modeller er kritisk både for utviklere og funksjonelle konsulenter. Modellene utgjør fundamentet i datamodellen, de definerer felttyper, relasjoner og forretningslogikk som styrer systemets oppførsel.
Denne guiden ser nærmere på en kjernekomponent i Odoo: sales.order. Enten du bygger egne moduler, kobler mot eksterne systemer eller setter opp salgsflyter, kommer du til å støte på denne modellen.
Hva er sales.order‑modellen
Modellen sales.order fanger opp både tilbud og bekreftede salgsordre. Her samles alle data om en salgstransaksjon før den eventuelt blir fakturert eller plukket for levering.
Modellen brukes primært av Salg‑modulen i Odoo.
Typisk arbeidsflyt: en selger oppretter et tilbud som ligger i draft. Når kunden godkjenner, endres ordren til bekreftet. Samme modell håndterer både utkast og bekreftede ordre, og feltet for status speiler hvor i livssyklusen ordren befinner seg.
Andre moduler bygger videre på sales.order ved hjelp av arv. CRM kan knytte en mulighet til en ordre, regnskap legger inn fakturarelaterte felt, og lager moduler legger til leveringsdatoer. Hver modul utvider kjernen uten å kopiere strukturen.
Viktige felt i modellen
Her er en oversikt over de sentrale feltene i sales.order som du oftest vil jobbe med. Kjennskap til disse gjør det enklere å konfigurere og utvikle mot salgsordrer.
1. name
Type: Char. Referansen for ordren — ofte et automatisk løpenummer som vises i lister og dokumenter. Dette er ordres identifikator i brukergrensesnitt og utskrifter.
2. state
Type: Selection. Forteller ordrestatus gjennom livssyklusen: draft, sent, sale, done, cancel. Statusen avgjør hvilke handlinger som er tilgjengelige i brukergrensesnittet og i arbeidsflyter.
3. partner_id
Type: Many2one (res.partner). Kunden til ordren. Dette feltet er avgjørende for prisberegning, betalingsbetingelser og rapportering, og er vanligvis obligatorisk.
4. partner_invoice_id
Type: Many2one (res.partner). Fakturaadresse. Hvis den er tom, arves den fra partner_id. Brukes når fakturadressen avviker fra hovedkontakten, for eksempel ved sentralisert fakturering.
5. partner_shipping_id
Type: Many2one (res.partner). Leveringsadresse. Også denne arves fra partner_id når den ikke er angitt. Påvirker plukklister og fraktberegning.
6. user_id
Type: Many2one (res.users). Ansvarlig selger eller bruker. Fletter seg inn i CRM‑rapportering, provisjonsberegning og tildeling av aktiviteter.
7. team_id
Type: Many2one (crm.team). Salgsteamet som ordren tilhører. Brukes for team‑dashboards, mål og rapporter.
8. date_order
Type: Datetime. Dato for ordren — i praksis opprettelsesdato for utkast og bekreftelsesdato for endelige ordre. Sentral for rapportering og sortering.
9. validity_date
Type: Date. Tilbudsutløpsdato. Godt å bruke for tidsbegrensede tilbud så du automatisk kan markere tilbud som ugyldige etter fristen.
10. commitment_date
Type: Datetime. Lovet leveringsdato. Når den er satt, planlegges leveranser etter denne datoen i stedet for standard ledetider — viktig for kundeløfter.
11. order_line
Type: One2many (sale.order.line). Ordrelinjene med produkt, antall, enhetspris og skatter. Dette er ordredetaljene som bestemmer subtotaler og beregninger.
12. amount_untaxed
Type: Float. Sum før skatt. Beregnes fra ordrelinjene og brukes i visninger og rapporter som delsum.
13. amount_tax
Type: Float. Total skatt. Også beregnet fra linjene basert på skatteregler, og vises på ordren og senere på faktura.
14. amount_total
Type: Float. Totalbeløp inkludert skatt — beløpet som vanligvis faktureres og rapporteres som ordreverdi.
15. currency_id
Type: Many2one (res.currency). Valutaen for ordren. Arves ofte fra selskapet eller prislisten, og alle pengeverdi‑felt forholder seg til denne valutaen.
16. pricelist_id
Type: Many2one (product.pricelist). Prislisten som bestemmer enhetspriser på linjene. Kan settes fra kundeprofil eller manuelt ved ordreopprettelse.
17. payment_term_id
Type: Many2one (account.payment.term). Betalingsbetingelser som Net 30 eller delbetalinger — følger med ved opprettelse av faktura.
18. fiscal_position_id
Type: Many2one (account.fiscal.position). Skatteposisjon for mapping av mva‑regler ved eksempelvis eksport eller spesielle skattemodeller.
19. client_order_ref
Type: Char. Kundens egen referanse eller bestillingsnummer. Nyttig å vise på dokumenter slik at kunden kjenner igjen ordren internt.
20. origin
Type: Char. Kilde‑dokumentet — for eksempel navnet på en mulighet eller et prosjekt som genererte ordren, brukt for sporbarhet.
21. create_date
Type: Datetime. Tidspunktet ordren ble opprettet. Vedlikeholdes automatisk av Odoo og nyttig ved revisjon og tidsserierapportering.
22. write_date
Type: Datetime. Sist endret‑tidspunkt. Også automatisk, og hjelper med å følge med på når data siste ble oppdatert.
23. note
Type: Text. Felt for vilkår, interne notater eller spesifikke instrukser som kan vises på tilbud og fakturaer.
24. require_signature
Type: Boolean. Kryss av for å kreve elektronisk signatur fra kunden før ordren bekreftes — vanlig i netthandel og portalløsninger.
25. require_payment
Type: Boolean. Når aktivert kreves betaling før bekreftelse — brukt for forskuddsbetaling eller depositum.
26. invoice_status
Type: Selection. Viser fakturastatus: ingen, til fakturering, fakturert eller behov for tilleggslinjer. Hjelper brukere å se hva som gjenstår.
27. locked
Type: Boolean. Når True er ordren låst for endringer. Settes typisk ved bekreftelse eller når tilknyttede dokumenter er postert.
28. company_id
Type: Many2one (res.company). I multiselskap oppgir dette hvilken juridisk enhet ordren hører til — påvirker synlighet og tilgangskontroll.
29. tag_ids
Type: Many2many (crm.tag). Frie tagger for kategorisering og filtrering — nyttig for segmentering og enkle arbeidsflyter.
30. signed_by
Type: Char. Navn på personen som signerte ordren når signatur kreves — lagres for sporbarhet.
31. signed_on
Type: Datetime. Tidspunkt for signatur — brukt ved dokumentasjon av kundesamtykke.
32. prepayment_percent
Type: Float. Prosentandel som må betales som forskudd når require_payment er aktiv — nyttig for depositumberegninger.
Hvordan modellen brukes i forretningsprosesser
1. Fra tilbud til ordre
Standardflyt: selgeren bygger et tilbud, legger inn linjer og priser, sender til kunde. Når kunden bekrefter, skifter ordren til salgsstatus og videre aktiviteter som faktura og levering opprettes.
2. Netthandel og kundeserviceportal
Når kunder bestiller via nettbutikken, opprettes sale.order automatisk. Innstillinger som krever betaling eller signatur styrer om ordren kan bekreftes uten manuell godkjenning.
3. Fra CRM til salg
Ved vunnet mulighet genereres ofte et tilbud direkte fra CRM. Origin‑feltet binder ordren tilbake til muligheten, og bruker/team‑feltene sørger for riktig rapportering og kommisjon.
4. Fakturering
Når en ordre er bekreftet, lager man fakturaer basert på ordrelinjene. Betalingsbetingelser og skatteposisjon overføres fra ordren, og invoice_status gir oversikt over faktureringsstatus.
5. Levering og leveringsforpliktelser
commitment_date påvirker planleggingen av plukk og leveranser. partner_shipping_id avgjør hvor varene skal sendes, og gjør planlegging mer presis.
Slik utvider utviklere modellen
Utviklere kan utvide sales.order med flere mønstre. Modellarv er den vanligste og kraftigste metoden i Odoo.
Modelarv
Bruk _inherit = 'sale.order' i din modul for å legge til felt, overstyre metoder eller legge til valideringer. Slik holdes endringene i en separat modul som gjør oppgraderinger enklere.
Legge til felt
Definer nye felttyper i arvemodellen etter behov — Char, Many2one, Boolean, Integer, Text, Selection. Vurder også selskapsavhengige felt i multiselskapsscenarier.
Python‑utvidelser
Overstyr metoder som action_confirm, create eller write for å legge inn forretningslogikk. Husk alltid å kalle super() der det er nødvendig, og tenk gjennom avhengigheter for beregnede felt.
Odoo Studio
Odoo Studio lar deg legge til felt raskt og uten kode — fint for raske tilpasninger. For mer kompliserte endringer og vedlikehold over tid foretrekkes egne moduler.
Beste praksis
- Bruk riktig status i arbeidsflyten. Unngå å hoppe over steg eller omgå bekreftelseslogikk som andre prosesser bygger på.
- Sett commitment_date når dere har en avtalt leveringsdato fra kunden — det gir bedre planlegging for lager og logistikk.
- Bruk commercial_partner_id når du trenger konsern‑ eller overordnet kundeentitet, for eksempel i kredittvurdering og rapportering.
- Ved API‑integrasjoner, benytt XML‑RPC eller JSON‑RPC. sales.order er tilgjengelig via API‑ene — vær nøye med å kartlegge eksterne IDer riktig.
- Navngi egendefinerte felter med x_ eller modulprefiks for å unngå kollisjoner ved fremtidige Odoo‑oppgraderinger.
Vanlige feil
- Endre ikke bekreftede eller låste ordre uten å sjekke locked‑feltet. Om nødvendig, arbeid via revjoner eller definerte arbeidsflyter for å sikre sporbarhet.
- Ikke forveksle partner_id, partner_invoice_id og partner_shipping_id — de har separate roller og bør settes korrekt når adresser avviker.
- Undvik å overstyre action_confirm uten å kalle super(), da kan andre moduler eller oppgraderinger slutte å fungere som forventet.
- Unngå å legge til nye obligatoriske felt uten standarder — eksisterende poster eller migrasjoner kan feile ved oppgraderinger.
- Husk å sette prislisten ved valuta‑ eller prisavvik. Manglende pricelist_id kan føre til feil priser og uriktig fakturering.
Oppsummering
sales.order er selve kjernen i Odoo‑salg: tilbud og bekreftede ordre styres her. Å kunne modellens felter og hvordan den kan utvides gjør det enklere å konfigurere, tilpasse og integrere systemet.
Enten du kartlegger salgsprosesser eller utvikler spesialtilpasninger, sparer du tid og reduserer feil ved å ha god kontroll på sales.order.
Trenger du hjelp med Odoo‑implementasjonen din?
Dasolo bistår virksomheter med å implementere, tilpasse og optimalisere Odoo. Vi har erfaring med API‑integrasjoner og dyp innsikt i Odoos datamodeller som sales.order.
Trenger du bistand med implementasjon, tilpassede moduler eller integrasjoner, så hjelper vi gjerne. Book en demo for å diskutere prosjektet ditt.