Hoppa till innehåll

sale.order.line i Odoo: Så är Sales Order Line uppbyggd

En heltäckande guide till Odoos modell för försäljningsorderrader — framtagen för utvecklare och funktionella konsulter
10 mars 2026 av
sale.order.line i Odoo: Så är Sales Order Line uppbyggd
Dasolo
| Inga kommentarer ännu

Introduktion


I Odoo bestämmer modellerna hur information organiseras och sparas i databasen. Allting från offerter och fakturor till kundkort och artiklar är strukturerat i modeller — de är ryggraden i systemet.


Att förstå modeller är viktigt både för utvecklare och funktionella konsulter. Modellen beskriver fälten, relationerna och affärslogiken som styr dataflödet i Odoo.


Det här stycket fokuserar på en av de mest centrala modellerna i försäljningsmodulen: sale.order.line. Oavsett om du skapar anpassade moduler, kopplar externa system eller sätter upp prissättningsflöden kommer du ofta att stöta på den här modellen.

Vad är modellen sale.order.line


Modellen sale.order.line fångar enskilda rader på en offert eller order. Varje rad representerar normalt en artikel eller tjänst med mängd, pris och skatteuppgifter.


I Odoo används modellen inom försäljning (sale). Den ärver funktionalitet för analys och projekthantering via analytic.mixin, så rader kan kopplas till kostnadsuppföljning och tidrapportering. När du lägger in en artikel på en offert skapas en sale.order.line-post.


Modellen definieras i sale-modulen, men andra moduler kompletterar den genom arv. Exempelvis lägger sale_stock till leveransfält och sale_margin räknar marginaler — varje modul bygger på kärnan utan att duplicera strukturen.

Viktiga fält i modellen


Nedan följer de viktigaste fälten i sale.order.line och vad de betyder i praktiken. Att känna dem underlättar när du arbetar med offerter och säljordrar.


1. order_id

Typ: Many2one (sale.order). Obligatoriskt. Pekar på moderordern och binder raden till sin order. Vid borttagning av ordern försvinner normalt även dess rader (kaskad).


2. sequence

Typ: Integer. Standard 10. Bestämmer i vilken ordning rader visas på dokumentet — viktigt för att gruppera sektioner, noteringar och produktrader.


3. company_id

Typ: Many2one (res.company). Härledd från order_id. Används för regler i multi-företagsmiljö och åtkomstkontroll.


4. currency_id

Typ: Many2one (res.currency). Härledd från order_id. Anger valuta för monetära fält på raden och ser till att pris beräknas i rätt valuta.


5. order_partner_id

Typ: Many2one (res.partner). Härledd från order_id. Kunduppgiften — viktig för prislistor och skatteregler.


6. salesman_id

Typ: Many2one (res.users). Härledd från order_id. Säljaren på ordern, används för provision och rapportering.


7. state

Typ: Selection. Härledd från order_id. Visar orderns status (t.ex. utkast, skickad, bekräftad, klar, annullerad) och styr vilka fält som går att ändra.


8. display_type

Typ: Selection. Värden som line_section eller line_note. Används när raden är en rubrik eller anteckning — inte en produktrad — och andra produktfält lämnas tomma.


9. is_downpayment

Typ: Boolean. Markerar om raden är en handpenning. Handpenningar faktureras separat och hanteras annorlunda i faktureringsflödet.


10. is_expense

Typ: Boolean. Sann när raden härrör från en utgift eller leverantörsfaktura. Hjälper vid uppföljning av projektkostnader.


11. product_id

Typ: Many2one (product.product). Den sålda produkten. Domän brukar begränsa till säljbara varianter. Krävs för produktbaserade rader.


12. product_template_id

Typ: Many2one (product.template). Beräknas från product_id. Används av konfiguratorer när variantval sker.


13. name

Typ: Text. Radens beskrivning. Sätts ofta utifrån produkt och valda attribut — inkluderar variantrader när det är aktuellt.


14. product_uom_qty

Typ: Float. Obligatoriskt. Beställd mängd, standard 1.0. Kan påverkas av förpackningsstorlekar.


15. product_uom

Typ: Many2one (uom.uom). Måttenhet för radens kvantitet. Sätter standard från produkten och används vid prisberäkning.


16. tax_id

Typ: Many2many (account.tax). Skatter applicerade på raden. Beräknas ofta utifrån produkt och kundens skattekonfiguration.


17. price_unit

Typ: Float. Obligatoriskt. Enhetspris per valt mått. Kan hämtas från prislista eller produkt och överskrivas manuellt.


18. discount

Typ: Float. Procentuell rabatt. Appliceras på price_unit innan skattberäkning.


19. price_subtotal

Typ: Monetary. Mellansumma före skatt. Beräknas från mängd, pris och rabatt.


20. price_tax

Typ: Float. Totalt skattebelopp. Beräknas utifrån price_subtotal och valda skatter.


21. price_total

Typ: Monetary. Total inklusive skatt. Detta belopp används vid fakturering och rapportering.


22. product_packaging_id

Typ: Many2one (product.packaging). Valfri förpackning, t.ex. låda om 12. Kan påverka föreslagen kvantitet.


23. customer_lead

Typ: Float. Leveranstid i dagar från orderbekräftelse till leverans — används för planering av leveransdatum.


24. qty_delivered

Typ: Float. Levererad mängd. Uppdateras av lagertransaktioner eller manuellt och används för delvis fakturering.


25. qty_invoiced

Typ: Float. Redovisar hur mycket som redan fakturerats. Sätts utifrån kopplade fakturarader.


26. qty_to_invoice

Typ: Float. Återstående mängd att fakturera. Beräknas från levererat kontra fakturerat.


27. invoice_status

Typ: Selection. Värden som upselling, invoiced, to invoice, no — visar faktureringsstatus för raden.


28. invoice_lines

Typ: Many2many (account.move.line). Länk till fakturarader skapade från denna orderrad — viktigt för spårbarhet.


29. create_date

Typ: Datetime. Tidpunkt när posten skapades. Hanteras automatiskt av Odoo.


30. write_date

Typ: Datetime. Tidpunkt för senaste ändring — användbar för auditloggning.

Hur modellen används i affärsprocesser


1. Offert och säljordrar

När en säljare bygger en offert lägger hen till artiklar som blir varsin orderrad. Dessa rader visar mängd, enhetspris, eventuell rabatt och radens totalsumma. Offerten blir en order när kunden accepterar den.


2. Prislistor och rabatter

Prislistor bestämmer ofta price_unit och rabatt per rad. Regler för volymrabatter eller kundspecifik prissättning appliceras på radnivå via prislistans logik.


3. Leverans och fakturering

När lager plockas och levereras uppdateras qty_delivered. Fakturering kan ske per leverans eller samlat — invoice_status visar vad som återstår att fakturera.


4. Projekt och tjänster

För tjänsteartiklar kopplas rader ofta mot projektuppgifter och tidrapporter. Genom analytic-mixen kan kostnader och tid kopplas tillbaka till projektet.


5. E-handel och kundportal

När besökare lägger varor i kundvagnen skapar systemet motsvarande orderrader vid beställning. Produktkonfiguratorn använder template- och attributdata för att bygga raderna korrekt.

Hur utvecklare bygger ut modellen


Utvecklare bygger ut sale.order.line med flera mönster, där arv mellan modeller är det vanligaste verktyget.


Modellarv

Använd _inherit = 'sale.order.line' i din modul för att lägga till fält, skriva om metoder eller lägga in valideringar. Genom arv håller du dina ändringar i separata moduler vilket underlättar uppgraderingar.


Lägga till fält

Definiera nya Odoo-fält i den ärvda modellen med rätt typ: Char, Many2one, Boolean, Integer, Text eller Selection. Tänk på företagsberoende fält vid multi-company-installationer.


Python-utökningar

Skriv om beräkningsmetoder som _compute_price_unit eller _compute_price_subtotal, eller haka in i create/write för att lägga in affärslogik. Anropa alltid super() där det behövs och var noga med computed-fälts beroenden.


Odoo Studio

Odoo Studio gör det enkelt att lägga till fält utan kod — bra för snabba ändringar. För komplex logik eller stabila lösningar rekommenderas anpassade moduler istället.

Rekommenderade arbetssätt


  • Använd display_type för att skapa rubriker och noteringar i ordern istället för att använda falska produktrader — det håller rapporter och validering rena.
  • När du bygger API-integrationer, skapa rader i samband med ordern. Använd ordern’s order_line-fält med korrekta kommandon för att säkerställa att relationerna blir rätt.
  • Respektera SQL- och valideringsregler: produktlinjer bör ha product_id och product_uom satt, medan sektioner/anteckningar ska ha display_type.
  • För egen prissättning, utnyttja prislistorna när det är möjligt. Bara gå in och överstyra compute-metoder om prislistor inte kan täcka kravet.
  • För anpassade fält, använd x_-prefix eller ett modul-specifikt prefix för att minimera kollisionsrisk med framtida Odoo-uppdateringar.

Vanliga misstag


  • Skapa inte rader utan order_id — fältet är kravfyllt. Alltid skapa orderrader i kontexten av en order för att bevara dataintegriteten.
  • Blanda inte ihop product_id och product_template_id. Produktvarianter anges via product_id; för konfiguratorflöden kan template-id användas för att välja variant.
  • Ändra inte price_unit eller discount efter att delar redan fakturerats. När qty_invoiced är större än noll kan prisjusteringar leda till avstämningsproblem.
  • Skriv inte om kärnmetoder utan att anropa super(). Annars riskerar du att störa andra moduler eller skapa problem vid framtida uppgraderingar.
  • Glöm inte display_type för rubrik- eller notrader — utan det behandlas raden som en produkt och kan misslyckas i valideringen.

Sammanfattning


Modellen sale.order.line är navet i Odoo:s försäljningshantering. Den fångar varje rad på offerter och ordrar. Att förstå dess fält och hur andra moduler bygger ut modellen är avgörande för konfiguration, anpassning och integration.


Oavsett om du kartlägger affärsprocesser som konsult eller utvecklar anpassade moduler, sparar en god förståelse för sale.order.line tid och förebygger fel.

Behöver du hjälp med er Odoo-implementation?


Dasolo hjälper företag att implementera, anpassa och optimera Odoo. Vi är specialiserade på API-integrationer och utveckling, med djup kunskap om Odoo:s datamodell och modeller som sale.order.line.


Behöver ni hjälp med er Odoo-implementation, skräddarsydda moduler eller integrationer? Vi bistår gärna. Boka en demo för att diskutera ert projekt.

sale.order.line i Odoo: Så är Sales Order Line uppbyggd
Dasolo 10 mars 2026
Dela detta inlägg
Logga in att lämna en kommentar