Hoppa till innehåll

Produkt.product-modellen: Så fungerar Odoo Product Variant-arkitekturen

En komplett handbok för utvecklare och funktionella konsulter om Odoos modell för produktvarianter
10 mars 2026 av
Produkt.product-modellen: Så fungerar Odoo Product Variant-arkitekturen
Dasolo
| Inga kommentarer ännu

Introduktion


I Odoo styr modellerna hur affärsdata organiseras i databasen. Alla konkreta objekt — från kundorder och lagerpost till katalogartiklar — representeras av modeller som bestämmer vilka uppgifter som sparas och hur de kan användas.


Att ha koll på Odoo-modeller är grundläggande både för utvecklare och funktionella konsulter. Modellerna bygger upp datalagret: fält, relationer och affärslogik definieras där och avgör hur systemet bete sig i praktiken.


I den här texten ligger fokus på en av de mest använda modellerna i Odoo: product.product. Oavsett om du sätter upp butikskataloger, kopplar in externa system eller bygger moduler kommer du ofta att behöva förstå den här modellen.

Vad är modellen product.product?


product.product står för de faktiska produktvarianterna — de artiklar du säljer, köper och flyttar i lager. Det är de konkreta enheterna som hamnar på orderrader, inköpsorder och lagerflytt.


Det är viktigt att skilja på product.product och product.template. Produktmallen innehåller det som är gemensamt för en produktfamilj, medan varje variant (storlek, färg osv.) är en separat product.product-post. För en produkt utan varianter finns en variant per mall; för konfigurerbara artiklar skapas en variant per kombination.


Modellen lever i produktmodulen och refereras överallt — försäljning, inköp, lager och e-handel använder product.product. När du lägger till en rad i en offert eller tar emot varor så är det variantposten som används.


product.product använder delegation mot produktmallen: många fält definieras på template-nivå och ärvs av varianterna. Det gör att gemensamma uppgifter hålls centralt medan varianterna kan ha egna värden när det behövs.

Viktiga fält i modellen


Nedan sammanfattas de viktigaste fälten i modellen — de fält du stöter på oftast och som styr beteendet i systemet.


1. name

Typ: Char. Visningsnamn för varianten. Det syns i listor, formulär och dokument. För enkla produkter är det samma som mallens namn; för varianter kan det innehålla attribut (t.ex. "T-shirt – Blå / M").


2. product_tmpl_id

Typ: Many2one (product.template). Pekar på produktmallen som varianten hör till. Varje variant tillhör exakt en mall — det är relationen som binder samman familjen av varianter.


3. default_code

Typ: Char. Intern referens eller SKU. Används för sökningar, streckkodsläsning och integrationer. Varje variant kan ha egen kod för att särskiljas i externa system.


4. barcode

Typ: Char. Streckkod (EAN/UPC etc.). Används i kassa och lagerhantering för snabb identifiering. När satt bör den vara unik för att undvika fel vid skanning.


5. create_date

Typ: Datetime. Tidpunkt när posten skapades. Sätts automatiskt av Odoo och är användbar i rapporter och revisioner.


6. write_date

Typ: Datetime. Tidpunkt för senaste ändring. Automatiskt uppdaterad och hjälper dig spåra när data senast redigerades.


7. active

Typ: Boolean. Mjuk arkivering. Om False göms produkten i standardvyer men sparas historiskt för ordnar och rapporter.


8. type

Typ: Selection. Produktkategori: Förbrukningsvara, Tjänst eller Lagerförd vara. Avgör om artikeln spåras i lager eller inte och vilka flöden som gäller.


9. categ_id

Typ: Many2one (product.category). Produktkategori som används för rapportering, prisregler och ordning i katalogen. Kategorier kan ha hierarki och arv av egenskaper.


10. list_price

Typ: Float. Försäljningspris som visas i offert och som standardpris på orderrader. Prislistor och kundspecifika regler kan ändra detta.


11. standard_price

Typ: Float. Inköps- eller självkostnadspris för värdering och marginalberäkningar. Uppdateras ofta via inköp eller manuella justeringar.


12. uom_id

Typ: Many2one (uom.uom). Enhet för försäljning och lager (st, kg, liter etc.). Definierar hur kvantiteter räknas och konverteras.


13. uom_po_id

Typ: Many2one (uom.uom). Enhet för inköp — kan skilja sig från uom_id (t.ex. köps i kartonger men säljs per styck). Odoo sköter omräkningarna.


14. description_sale

Typ: Html. Försäljningstext som visas på offerter och fakturor. Kan innehålla formatering och produktbeskrivning riktad mot kund.


15. description_purchase

Typ: Html. Inköpstext för leverantörsordrar och fakturor. Används för intern kommunikation eller för att ge leverantören nödvändig info.


16. sale_ok

Typ: Boolean. Anger om produkten får säljas. Om False döljs den i försäljning och webbutiken — användbart för interna eller inköpsbara artiklar.


17. purchase_ok

Typ: Boolean. Anger om produkten får köpas. Om False döljs den i inköp — användbart för tillverkade eller internt använda varor.


18. image_1920

Typ: Binary. Högupplöst produktbild. Odoo sparar flera storlekar (image_512, image_256 osv.) för att visa på webb, formulär och rapporter.


19. weight

Typ: Float. Produktvikt, viktig för fraktberäkningar och logistik. Enhet bestäms av bolagets inställningar.


20. volume

Typ: Float. Volym för frakt och lagerplanering. Viktigt om du hanterar volymbegränsningar i transporter eller lager.


21. company_id

Typ: Many2one (res.company). Anger vilket bolag produkten tillhör i multi-company-miljöer. Påverkar synlighet och lagerhantering.


22. currency_id

Typ: Many2one (res.currency). Valutan för priserna. Vanligtvis bolagets valuta, men prislistor kan konvertera till kundens valuta.


23. qty_available

Typ: Float. Lagerantal på hand. Beräknas från lagerkvantiteter och är skrivskyddat. Används för tillgänglighetskontroller — endast relevant för lagerförda varor.


24. virtual_available

Typ: Float. Prognostiserat saldo (tillgängligt plus inkommande minus utgående). Hjälper vid planering och återbeställning — också beräknat och skrivskyddat.


25. product_template_attribute_value_ids

Typ: Many2many. Kopplar varianten till attributvärden (t.ex. Färg=Blå, Storlek=M). Används av konfiguratorn och för filtrering i katalogen.


26. sequence

Typ: Integer. Visningsordning i listor och konfiguratorer. Lägre värde visas först — användbart för att styra presentationen.


27. display_name

Typ: Char. Beräknat visningsnamn som kombinerar namn och attribut för att bli lättigenkännligt i dropdowns och sökningar.


28. responsible_id

Typ: Many2one (res.users). Ansvarig person för produkten — nyttigt för återbeställningsregler eller intern ägarskap. Fältet är frivilligt.

Hur modellen används i affärsflöden


1. Försäljning och offerter

När en säljare lägger en offert väljs en produktvariant som fyller orderraden med pris, beskrivning och enhet. Prislistor kan ändra priset dynamiskt, och endast produkter markerade som säljbara visas i listor.


2. Inköp och leverantörer

Inköpsordrar och leverantörsfakturor pekar på varianterna. Inköpskostnaden uppdaterar ofta standard_price, och uom_po_id styr hur kvantiteter beställs (t.ex. per kartong). Endast inköpsbara artiklar erbjuds i inköpsvyer.


3. Lager och logistik

Lagerflytt, plock och kvantberäkningar använder product.product. Fälten qty_available och virtual_available styr om varor är tillgängliga för leveranser. Streckkoder används för snabb identifiering i plock- och inleveransflöden.


4. E-handel och webbshop

Webbshoppen visar varianter som valbara alternativ (storlek, färg). Bilder, beskrivningar och priser hämtas från modellen, och synlighet styrs av försäljnings-flaggan.


5. Tillverkning och MRP

Stommen i BOM:ar kan referera både komponenter och slutprodukter som varianter. Produktens typ bestämmer om den lagras eller är förbrukningsartikel, vilket påverkar planeringen av produktion.

Hur utvecklare utökar modellen


Utvecklare brukar utöka product.product med Odoos arvsmönster—det finns flera etablerade sätt att göra tillägg.


Modellarv

Genom att ärva product.product i din modul kan du lägga till fält, skriva om metoder eller lägga in valideringar. Använd product.product när ändringen ska gälla per variant; om attributet är gemensamt för alla varianter bör du använda product.template.


Lägga till fält

Definiera nya fält med lämplig typ (Char, Many2one, Boolean, Integer, Text, Selection). Fundera noga om fältet hör hemma på mallen eller på varianten — unika SKUs eller variantspecifika barcodes hör hemma på product.product.


Python-ändringar

Skriv över create, write eller unlink för att införa affärslogik, men anropa alltid super() för att bevara grundbeteende. Var särskilt försiktig med beräknade fält och deras beroenden, eftersom många fält i product.product är beräknade av andra moduler.


Odoo Studio

Odoo Studio erbjuder ett snabbt sätt att lägga till fält utan kod — bra för snabba anpassningar. För mer komplex logik och långsiktigt underhåll är egna moduler ofta att föredra. Product.product och dess API är fullt åtkomligt via XML-RPC/JSON-RPC för integrationer.

Bästa praxis


  • Bra riktlinje: använd default_code eller barcode som nyckel mot externa system och håll dem konsekventa och unika.
  • Sätt produktens typ korrekt — om det är en förbrukningsvara, tjänst eller lagerförd vara påverkar vilka funktioner och flöden som används.
  • Vid API-integrationer: arbeta mot product.product för orderrader och lagertransaktioner, och mot product.template för katalog- eller utbudsändringar som gäller hela produktfamiljen.
  • När du skapar egna fält, prefiera x_ eller modulprefix för att minska risken för namnkonflikter vid framtida Odoo-uppgraderingar.
  • Tänk igenom om ett fält ska ligga på mallnivå eller variantnivå: varumärke och generell kategori hör ofta hemma på product.template, medan variantunika data hör till product.product.

Vanliga misstag


  • Välj rätt ärvningsnivå: om du behöver beteende per variant, ärva product.product; för gemensamt beteende över alla varianter, arbeta mot product.template.
  • Skapa varianter via konfiguratorn istället för manuellt när produkten har attribut — det håller koll på relationer och minskar fel.
  • Ett vanligt misstag är att glömma slå på sale_ok eller purchase_ok — då försvinner produkter ur försäljnings- eller inköpsflöden utan att någon märker varför.
  • Undvik att skriva över kärnmetoder utan att anropa super() — det kan störa andra moduler och göra framtida uppgraderingar besvärliga.
  • Var också försiktig med att använda product.product i domäner där product.template är mer lämpligt, till exempel när du filtrerar på kategori på mallenivå.

Sammanfattning


product.product är navet i Odos produktmodell: det representerar de faktiska, handlingsbara artiklarna i din verksamhet. Att förstå dess fält och relation till product.template gör det lättare att konfigurera, anpassa och integrera systemet korrekt.


Oavsett om du kartlägger kataloger som konsult eller bygger moduler som utvecklare så sparar rätt förståelse kring product.product tid och förebygger problem i produktion och integration.

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


Dasolo hjälper företag att införa, anpassa och optimera Odoo-lösningar. Vi specialiserar oss på API-integrationer och skräddarsydd utveckling med djup kunskap om Odos datamodeller, där product.product ofta spelar en central roll.


Behöver du stöd med implementation, anpassade moduler eller integrationer så kan vårt team hjälpa dig att komma igång och undvika vanliga fallgropar. Boka en demo för att prata om ditt projekt.

Produkt.product-modellen: Så fungerar Odoo Product Variant-arkitekturen
Dasolo 10 mars 2026
Dela detta inlägg
Logga in att lämna en kommentar