Skip to Content

sale.order.line i Odoo: Forstå Arkitekturen Bag Salgsordrelinjer

Den komplette guide til Odoo's model for salgsordrelinjer — for udviklere og funktionelle konsulenter
10. marts 2026 af
sale.order.line i Odoo: Forstå Arkitekturen Bag Salgsordrelinjer
Dasolo
| Ingen kommentarer endnu

Introduktion


I Odoo beskriver modeller, hvordan forretningsdata ligger struktureret i databasen. Alting fra ordrer over fakturaer til kundekontakter er gemt som poster i modeller, som definerer felter og sammenhænge.


At have styr på Odoo-modeller er afgørende både for udviklere og forretningskonsulenter. Modeller udgør fundamentet i Odoo's dataarkitektur og bestemmer felttyper, relationer og den forretningslogik, der styrer processerne.


Denne gennemgang koncentrerer sig om en central model i Salgsmodulet: sale.order.line. Uanset om du bygger tilpasninger, kobler eksterne systemer på eller opsætter prislogik, vil denne model indgå i dit arbejde.

Hvad er modellen sale.order.line?


Modellen sale.order.line repræsenterer de enkelte linjer på et tilbud eller en salgsordre. Hver linje svarer normalt til ét produkt eller en service og indeholder mængde, pris og skattemæssige oplysninger.


Modellen bruges af salgsapplikationen (sale) og arver funktionalitet til eksempelvis projektrelateret omkostningsopsamling. Når en vare føjes til et tilbud, oprettes der en sale.order.line-post for den vare.


Definitionen ligger i sale-modulet, men andre moduler udvider modellen via arve-mekanismer i Odoo. Fx tilføjer sale_stock felter for levering, mens sale_margin håndterer marginberegninger — hver udvidelse lægger kun det til, den har brug for.

Vigtige felter i modellen


Nedenfor finder du de vigtigste felter i sale.order.line. Kendskab til disse gør det nemmere at arbejde med tilbud, leverancer og fakturering.


1. order_id

Type: Many2one (sale.order). Påkrævet. Refererer til den overordnede salgsordre. Feltet binder linjen til ordren, og linjer fjernes ved sletning af ordren (kaskade).


2. sequence

Type: Integer. Standard 10. Styrer visningsrækkefølgen af linjer på ordren. Bruges til at sortere sektioner, noter og produktlinjer.


3. company_id

Type: Many2one (res.company). Relateret via order_id. Relevant ved multi-company-regler og adgangskontrol.


4. currency_id

Type: Many2one (res.currency). Relateret via order_id. Bruger valutaen fra ordren til alle monetære felter på linjen, så priser stemmer.


5. order_partner_id

Type: Many2one (res.partner). Relateret via order_id. Kunden på ordren. Påvirker prislisteregler og skat.


6. salesman_id

Type: Many2one (res.users). Relateret via order_id. Sælgeren. Bruges til kommissioner og rapportering.


7. state

Type: Selection. Relateret via order_id. Ordrestatus (draft, sent, sale, done, cancel). Bestemmer hvilke felter der kan redigeres.


8. display_type

Type: Selection. Værdier: line_section eller line_note. Når sat, fungerer linjen som en sektion eller note og ikke som et produkt — produktfelter er tomme.


9. is_downpayment

Type: Boolean. Marker linjen som et forskud. Forskud faktureres separat.


10. is_expense

Type: Boolean. Sand når linjen stammer fra en udgift eller leverandørfaktura. Relevant for projektomkostninger.


11. product_id

Type: Many2one (product.product). Produktet der sælges. Domæne begrænser til salgbare varianter. Påkrævet for produktlinjer.


12. product_template_id

Type: Many2one (product.template). Beregnes ud fra product_id. Bruges af produktkonfiguratoren til valg af varianter.


13. name

Type: Text. Linjetekst/beskrivelse. Genereres ud fra produkt og tilpassede attributter og inkluderer varianter når relevant.


14. product_uom_qty

Type: Float. Påkrævet. Bestilt mængde. Standard 1.0. Kan også styres af emballagevalg.


15. product_uom

Type: Many2one (uom.uom). Måleenhed. Hentes som standard fra produktet. Brugt i mængde- og prisberegninger.


16. tax_id

Type: Many2many (account.tax). Skatter knyttet til linjen. Beregnes ud fra produkt og den gældende skattekonfiguration.


17. price_unit

Type: Float. Påkrævet. Enhedspris pr. måleenhed. Beregnes fra prislisten eller produktet, men kan overskrives.


18. discount

Type: Float. Rabat i procent. Anvendes på enhedsprisen før skat.


19. price_subtotal

Type: Monetary. Delbeløb før skat. Beregnes ud fra mængde, enhedspris og rabat.


20. price_tax

Type: Float. Samlet skattebeløb. Beregnes fra price_subtotal og tax_id.


21. price_total

Type: Monetary. Samlet beløb inkl. skat. Bruges ved fakturering og rapportering.


22. product_packaging_id

Type: Many2one (product.packaging). Valgfri emballage (fx kasse med 12). Ved valg kan mængden styres af emballagen.


23. customer_lead

Type: Float. Leveringstid i dage. Tiden mellem ordre og afsendelse. Bruges til leveringsdato-beregning.


24. qty_delivered

Type: Float. Leveret mængde. Opdateres via lagermoves eller manuelt. Bruges ved delvis fakturering.


25. qty_invoiced

Type: Float. Allerede faktureret mængde. Beregnes fra fakturalinjer.


26. qty_to_invoice

Type: Float. Resterende mængde til fakturering. Beregnes ud fra qty_delivered og qty_invoiced.


27. invoice_status

Type: Selection. Værdier: upselling, invoiced, to invoice, no. Angiver faktureringsstatus for linjen.


28. invoice_lines

Type: Many2many (account.move.line). Link til fakturalinjer skabt fra denne salgs-linje. Vigtigt for sporbarhed.


29. create_date

Type: Datetime. Tidspunkt for oprettelse. Håndteres automatisk af Odoo.


30. write_date

Type: Datetime. Sidste ændringstidspunkt. Bruges til revision og fejlsøgning.

Hvordan modellen bruges i daglige arbejdsprocesser


1. Tilbud og salgsordre

Når sælgere opretter et tilbud, føjes produkter til ordren som linjer. Hver linje viser mængde, pris, rabat og subtotal, og ordren konfirmeres, når kunden accepterer.


2. Prislistestyring og rabatter

Prisregler anvendes per linje: price_unit og discount beregnes ofte ud fra prislisten. Volumepriser eller kundespecifikke priser håndteres her.


3. Levering og fakturering

Når varer bliver afsendt, opdateres qty_delivered. Fakturering kan ske per levering eller samlet, og invoice_status viser, hvad der mangler at blive faktureret.


4. Projekter og serviceydelser

For serviceprodukter knyttes linjerne ofte til projektopgaver og timesedler. Arven fra analytic.mixin gør det muligt at bogføre omkostninger pr. projekt.


5. E-handel og portal

Når kunder køber via webshoppen, konverteres hver kurvlinje til en sale.order.line. Produktkonfiguratoren bruger produkt_template_id og attributter til valg af varianter.

Hvordan udviklere udvider modellen


Udviklere bygger videre på sale.order.line med flere mønstre, hvor Odoo's modelarv er den primære metode.


Modelarv

Brug _inherit = 'sale.order.line' for at udvide modellen. Tilføj felter, overskriv metoder eller læg valideringer ind. Arv holder ændringerne adskilt i dit modul, hvilket gør opgraderinger nemmere.


Tilføjelse af felter

Definér nye felter i dit arvede model-felt: Char, Many2one, Boolean, Integer, Text eller Selection. Tænk over firmaafhængighed i multi-company-opsætninger.


Python-udvidelser

Overskriv metoder som _compute_price_unit eller _compute_price_subtotal, eller hook i create/write for ekstra logik. Husk at kalde super() og vær opmærksom på computed-felters afhængigheder.


Odoo Studio

Odoo Studio gør det muligt at tilføje felter uden at kode — hurtigt og nyttigt til simple tilpasninger. Til kompleks logik eller vedligeholdelse på længere sigt er rene moduler dog bedre.

Bedste fremgangsmåder


  • Brug display_type til at markere sektioner og noter i stedet for at snyde med produktlinjer; det holder rapporter og validering rene.
  • Når I integrerer via API, opret linjerne i kontekst af ordren. Brug order_line_ids på sale.order med de korrekte kommandoformater for at sikre integritet.
  • Respekter SQL- og datavalideringsregler: produktlinjer skal have product_id og product_uom, mens sektioner/noter kræver display_type.
  • Ved specialpriser anbefales det at bruge prislisteregler fremfor at overskrive compute-metoder, medmindre det er strengt nødvendigt.
  • Til egettilføjede felter brug x_-prefix eller et modulnavn som præfiks for at undgå navnekonflikter ved fremtidige Odoo-opdateringer.

Almindelige fejltrin


  • Opret ikke linjer uden en order_id — feltet er påkrævet. Opret altid linjer i ordrekonteksten for at undgå brud i relationer.
  • Bland ikke product_id og product_template_id: sæt produktet i product_id for almindelige produktlinjer; brug product_template_id i konfigurationsflows til at vælge varianter.
  • Undgå at ændre price_unit eller discount efter at qty_invoiced er større end nul — det skaber let uoverensstemmelser i regnskabet.
  • Overskriv ikke kernemetoder uden at kalde super(); det kan bryde funktionalitet i andre moduler eller gøre opgraderinger besværlige.
  • Glem ikke at sætte display_type for sektioner eller noter. Uden det bliver linjen behandlet som et produkt og validering kan fejle.

Afrunding


Modellen sale.order.line er hjørnestenen i Odoo Sales: den holder styr på hver enkelt produkt- eller servicelinje på tilbud og ordrer. Kendskab til felterne og udvidelsesmulighederne gør det lettere at konfigurere, tilpasse og integrere Odoo.


Uanset om du kortlægger forretningsprocesser som konsulent eller udvikler skræddersyede moduler, vil en grundig forståelse af sale.order.line spare tid og forebygge fejl.

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 dyb indsigt i Odoo's datamodel, herunder modeller som sale.order.line.


Har I brug for hjælp til Odoo-implementering, custom-moduler eller integrationer? Så kan vi hjælpe. Book en demo for at tage en snak om jeres projekt.

sale.order.line i Odoo: Forstå Arkitekturen Bag Salgsordrelinjer
Dasolo 10. marts 2026
Del dette indlæg
Log ind for at skrive en kommentar