Skip to Content

Produkt.product-modellen: Slik fungerer Odoo Product Variant-arkitekturen

En komplett veiledning til Odoo sitt produktvariant-system for utviklere og funksjonelle konsulenter
10. mars 2026 etter
Produkt.product-modellen: Slik fungerer Odoo Product Variant-arkitekturen
Dasolo
| No comments yet

Introduksjon


I Odoo beskriver modeller hvordan forretningsdata organisertes og lagres. Alt fra ordrelinjer til lagerbeholdning og produkter ligger i modeller som gir databasen struktur og gjør informasjonen tilgjengelig for applikasjonen.


Å ha kontroll på Odoo-modeller er viktig både for konsulenter og utviklere. Modeller utgjør grunnmuren i datamodellen: de definerer hvilke felt som finnes, hvordan poster henger sammen, og hvor forretningslogikk plasseres.


Denne artikkelen konsentrerer seg om en av de mest brukte modellene i Odoo: product.product. Enten du bygger moduler, integrerer mot eksterne systemer eller setter opp produktkataloger, vil du møte denne modellen ofte.

Hva er modellen product.product


product.product står for de konkrete produktvariantene i systemet — de fysiske eller digitale enhetene som legges på salgssordre, innkjøp og lagerbevegelser. Det er variantpostene som virkelig håndteres i transaksjoner.


Modellen skiller seg fra product.template ved at templaten holder fellesdata for en produktfamilie, mens product.product er hver enkelt variant. For en vare uten varianter finnes én variant per template; for produkter med attributter (f.eks. T-skjorte med størrelse og farge) får hver kombinasjon sin egen variant.


product.product ligger i produktmodulen og brukes av salg, innkjøp, lager og netthandel. Når du legger til en linje i et tilbud eller registrerer mottak, peker systemet til en product.product-post.


Variantmodellen arver mange felt fra product.template ved delegering, slik at fellesegenskaper samles på templaten og varianter kan overstyre det som må være spesifikt. Det gir en ryddig deling mellom felles- og variantnivå.

Nøkkelfelt i modellen


Nedenfor er de viktigste feltene i product.product. Kjennskap til disse gjør det enklere å navigere variantlogikk og integrasjoner.


name

Type: Char. Navnet på produktvarianten som vises i lister og dokumenter. For en enkel vare tilsvarer dette ofte templatenavn; for varianter kan navnet inkludere attributter for å gjøre valget entydig.


product_tmpl_id

Type: Many2one (product.template). Kobler varianten til sin overordnede template. Hver variant hører til én template — dette er relasjonen som binder familieegenskaper og variantdata sammen.


default_code

Type: Char. Intern referanse eller SKU. Brukes i søk, integrasjoner og strekkodelookup. Hver variant kan ha egen kode for entydig identifikasjon.


barcode

Type: Char. Strekkode (EAN/UPC osv.). Brukes ved skanning i butikk og på lager. Når satt må denne være unik for å unngå forvirring ved skanning.


create_date

Type: Datetime. Tidspunktet posten ble opprettet. Vedlikeholdes automatisk og nyttig i rapportering og revisjonsspor.


write_date

Type: Datetime. Tidspunkt for siste endring. Også automatisk; nyttig for å se når data sist ble oppdatert.


active

Type: Boolean. Arkiveringsflagg. Når false blir produktet skjult i standardvisninger, men ikke slettet — historikk beholdes.


type

Type: Selection. Angir produktkategori: Consumable, Service eller Storable. Dette styrer hvilke prosesser som gjelder — f.eks. om varen skal spores på lager eller ikke.


categ_id

Type: Many2one (product.category). Produktkategori som brukes i rapporter, prisregler og for å organisere katalogen. Kategorier kan være hierarkiske.


list_price

Type: Float. Standard salgspris som vises på tilbud og i nettbutikk. Kan overstyres av prislister eller kundespesifikke priser.


standard_price

Type: Float. Kostpris brukt ved verdivurdering av lager og for marginberegninger. Oppdateres gjerne ved innkjøp eller manuelt.


uom_id

Type: Many2one (uom.uom). Enhet for salg og lager (stk, kg, liter osv.) som definerer hvordan mengder håndteres i systemet.


uom_po_id

Type: Many2one (uom.uom). Enhet for innkjøp, kan avvike fra uom_id (f.eks. kjøp i kasser, selg i enheter) — Odoo håndterer konvertering automatisk.


description_sale

Type: Html. Salgsbeskrivelse som vises på tilbud, ordre og faktura. Støtter formatering og detaljer rettet mot kunden.


description_purchase

Type: Html. Innkjøpsbeskrivelse som følger med ordrelinjer til leverandør og brukes i innkjøpskommunikasjon.


sale_ok

Type: Boolean. Angir om produktet kan selges. Hvis false skjules det fra salgs- og e-handelsgrensesnittet.


purchase_ok

Type: Boolean. Angir om produktet kan kjøpes. Hvis false vises det ikke i innkjøpsmenuer — nyttig for ferdigproduserte eller interne artikler.


image_1920

Type: Binary. Produktbilde i full oppløsning. Odoo lagrer flere størrelser for visning i grensesnitt og nettsider.


weight

Type: Float. Produktets vekt, viktig ved fraktberegning og logistikk. Enhet styres av selskapsoppsett.


volume

Type: Float. Produktvolum, relevant for frakt og lagerkapasitet, spesielt for volumbegrensede distribusjonsprosesser.


company_id

Type: Many2one (res.company). Eierfirma i multibedriftsoppsett — påvirker synlighet og lagerforhold.


currency_id

Type: Many2one (res.currency). Valuta for priser som list_price og standard_price. Ofte selskapets valuta, men prislister kan konvertere.


qty_available

Type: Float. Tilgjengelig beholdning beregnet fra lagerkvanta. Feltet er readonly og viktig ved tilgjengelighetssjekker — gjelder storable-produkter.


virtual_available

Type: Float. Prognosert beholdning (på lager + innkommende − utgående). Brukes i bestillingsforslag og planlegging. Også beregnet felt.


product_template_attribute_value_ids

Type: Many2many. Kobling til attributtverdiene som definerer varianten (f.eks. Farge=Blå, Størrelse=M). Benyttes for konfigurasjon og filtrering.


sequence

Type: Integer. Bestemmelse av sorteringsrekkefølge i lister og konfiguratorer — lavere tall vises først.


display_name

Type: Char. Beregnet visningsnavn som kombinerer variantnavn og attributter for å gi et lesbart valg i drop-down og søk.


responsible_id

Type: Many2one (res.users). Ansvarlig for produktet internt — brukes i reordreringsregler og oppgavefordeling. Er valgfri.

Hvordan modellen brukes i forretningsprosesser


Salg og tilbud

Når selgere lager tilbud velges en variant fra katalogen; pris, beskrivelse og enhet følger til ordrelinjen. Prislister kan overskrive listprisen, og kun produkter markert som salgbare vises i utvalget.


Innkjøp og leverandører

Innkjøpsordre og leverandørfakturaer peker på variantpostene. Kostprisen kan oppdateres fra innkjøp, og innkjøpsenheten styrer hvorledes kvantum bestilles (for eksempel i kasser).


Lager og logistikk

Lageroperasjoner, plukk og kvanta refererer alltid varianter. Tilgjengelighetsfeltene styrer om varer kan reserveres, og strekkoder gir rask identifisering ved skanning. Bare lagervarer spores i beholdningen.


Netthandel og nettsted

Nettbutikken viser produktvarianter som valg for kundene — bilder, beskrivelser og priser hentes fra varianten. Synlighet styres av salgbart-flagget, og attributter presenteres som alternativer i nettbutikken.


Produksjon (MRP)

Produksjonsstykklistene og operasjoner knytter seg til varianter både for ferdigvare og komponenter. Produktens type avgjør om det inngår i produksjonsplan eller bare konsumeres, og lagernivåer påvirker planlagte kjøringer.

Hvordan utviklere utvider modellen


Utviklere kan bygge på product.product med flere mønstre, hvor arving av modellen er mest sentralt.


Modellarv

Sett _inherit = 'product.product' i din modul for å utvide modellen: legg til felt, overstyr metoder eller definer begrensninger. Velg product.product for variantspesifikke endringer, product.template for felt som gjelder hele produktfamilien — på den måten blir tilpasningene lettere å vedlikeholde ved oppgraderinger.


Legge til felt

Definer nye felt med riktig type (Char, Many2one, Boolean, Integer, Text, Selection). Vurder om feltet skal være på templaten (delt) eller på varianten (spesifikk). Eksempelfelt som SKU eller variantstrekkode hører hjemme på product.product.


Utvidelser i Python

Overstyr create, write eller unlink for å legge logikk, men kall alltid super() for å bevare eksisterende oppførsel. Vær særlig oppmerksom på avhengigheter i beregnede felt som kan virke inn fra lager- eller salgsmoduler.


Odoo Studio

Odoo Studio tilbyr et kodefritt grensesnitt for å legge til felt raskt — praktisk for raske tilpasninger. For mer avansert logikk og vedlikehold over tid er egendefinerte moduler likevel å foretrekke. API-et er tilgjengelig via XML-RPC/JSON-RPC for integrasjoner.

Beste praksis


  • Bruk default_code eller barcode som nøkler i integrasjoner, og sørg for entydighet og konsekvent oppdatering.
  • Sett produktets type riktig — valget mellom consumable, storable og service påvirker hvilke prosesser og moduler som er relevante.
  • I API-integrasjoner bruk product.product for transaksjonslinjer (ordre, plukk) og product.template for katalognivåoperasjoner.
  • Marker egendefinerte felt med x_-prefiks eller modulspesifikt prefiks for å unngå navnekonflikter ved oppgraderinger.
  • Legg felter på product.template når de gjelder alle varianter (f.eks. merke), og på product.product når informasjonen er variantspesifikk (f.eks. variantstrekkode).

Vanlige feil


  • Velg arvehierarki med omhu: bruk product.template for felleslogikk og product.product når atferd må skje per variant.
  • Opprett varianter riktig — for produkter med attributter bør du bruke produktkonfiguratoren fremfor å lage varianter manuelt for å sikre korrekte koblinger og attributtverdier.
  • Glem ikke å sette sale_ok eller purchase_ok; uten disse kan produkter være utilgjengelige i salgs- eller innkjøpsflowen.
  • Unngå å overstyre kjernemetoder uten å kalle super(), da det kan bryte funksjonalitet i andre moduler eller skape problemer ved oppgraderinger.
  • Unngå også å bruke product.product når du egentlig ønsker å filtrere på produktfamilien (product.template) — for eksempel ved kategorifiltrering, der templaten ofte er mer relevant.

Oppsummering


product.product er kjernen i Odoos produktmodell: det er variantene du faktisk selger, kjøper og flytter. Å forstå feltene og koblingen til product.template er avgjørende for riktig konfigurasjon, tilpasning og integrasjon.


Enten du jobber med å kartlegge produktkataloger eller utvikle moduler, sparer god kjennskap til product.product tid og reduserer feil i prosesser.

Trenger du hjelp med din Odoo-implementering?


Dasolo bistår bedrifter med implementering, tilpasning og optimalisering av Odoo. Vi har erfaring med integrasjoner og dyp kjennskap til Odoos datamodell og sentrale modeller som product.product.


Trenger du støtte til implementering, skreddersydde moduler eller integrasjoner, står vi klare til å hjelpe. Book en demo for å snakke om ditt prosjekt.

Produkt.product-modellen: Slik fungerer Odoo Product Variant-arkitekturen
Dasolo 10. mars 2026
Share this post
Logg inn to leave a comment