Innledning
I Odoo er informasjon organisert i modeller som beskriver hvordan data lagres. Alt fra ordre og fakturaer til produkter ligger i slike modeller, og måten de er definert på styrer hvordan systemet oppfører seg.
Å kjenne Odoo-modeller er nyttig både for utviklere og for konsulenter. Modellene utgjør fundamentet i datastrukturen: felter, relasjoner og forretningslogikk følger faste mønstre som gjør systemet forutsigbart og utvidbart.
Denne artikkelen går gjennom en av de mest sentrale modellene i Odoo: product.template. Enten du bygger moduler, setter opp kataloger eller integrerer mot andre systemer, vil du støte på denne modellen igjen og igjen.
Hva er product.template-modellen
product.template fungerer som en overbygning for produkter som i hovedsak er like, men har variasjoner — for eksempel ulike størrelser eller farger. I stedet for å opprette separate produkter for hver variant, setter man opp én mal med flere varianter under.
Modellen brukes på tvers av salg, innkjøp, lager, nettbutikk og produksjon. Når du oppretter et produkt i katalogen, oppretter du en product.template; ved ordrevalg plukker brukeren ofte en spesifikk variant som arver data fra malen.
Produktmodellen ligger i product-modulen og kan utvides av andre moduler via arv. Salg legger til pris- og fakturafelt, innkjøp håndterer leverandører, og lager beskytter lagerlogikk — alt uten å duplisere kjernen.
Det er viktig å skille mellom product.template og product.product. Malen inneholder fellesinformasjon, mens produktvarianten (product.product) holder variantspesifikk info som strekkode og internkode.
Viktige felt i modellen
Nedenfor finner du en oversikt over de mest sentrale feltene i product.template og hvorfor de betyr noe for konfigurering og integrasjoner.
1. name
Type: Char. Navnet på produktmalen. Vises i lister og skjemaer og er ofte det viktigste gjenkjenningspunktet for brukere og integrasjoner.
2. create_date
Type: Datetime. Tidspunkt for når posten ble opprettet. Håndteres automatisk og er nyttig i rapportering og revisjonsspor.
3. write_date
Type: Datetime. Tidspunkt for siste endring. Også automatisk — viktig for å se hva som er oppdatert og når.
4. active
Type: Boolean. Arkiveringsflagget. Når denne er False skjules produktet fra standardvisninger uten å slette det permanent.
5. sequence
Type: Integer. Bestemmer visningsrekkefølge i lister og valg. Lavere tall prioriteres høyere.
6. type
Type: Selection. Angir om produktet er tjeneste, forbruksvare eller lagerført vare. Dette styrer lagerregistrering og hvordan produktet håndteres i prosesser.
7. categ_id
Type: Many2one (product.category). Produktkategori som påvirker rapporter, standardrutene og hvordan produkter grupperes i katalogen.
8. list_price
Type: Float. Standard salgspris. Brukes i tilbud og som utgangspunkt for prislisten, men kan overstyres av prislister eller varianter.
9. standard_price
Type: Float. Kostpris. Brukes i marginberegninger og verdsetting av lager — viktig for økonomirapportering og lønnsomhetsanalyse.
10. currency_id
Type: Many2one (res.currency). Valuta for list_price og standard_price. Ofte satt per selskap i flerbedriftsoppsett.
11. uom_id
Type: Many2one (uom.uom). Måleenhet for salg (f.eks. stk, kg, liter). Definerer hvordan mengder uttrykkes i salg og rapporter.
12. uom_po_id
Type: Many2one (uom.uom). Måleenhet for innkjøp. Kan være forskjellig fra salgsenheten og krever konvertering ved behov.
13. default_code
Type: Char. Intern referansekode eller SKU. Nyttig ved integrasjoner og mapper mot eksterne systemer — bør holdes unik når mulig.
14. barcode
Type: Char. Strekkode brukt i POS og lager. For produkter med varianter ligger strekkoden ofte på variantenivået (product.product).
15. description
Type: Char. Intern beskrivelse synlig for ansatte. Brukes til interne notater om produktet.
16. description_sale
Type: Text. Salgsbeskrivelse som vises på tilbud og fakturaer. Kan inneholde enkel HTML for formatering på nett og dokumenter.
17. description_purchase
Type: Text. Innkjøpsbeskrivelse som følger med bestillinger og leverandørfakturaer for å gi leverandøren nødvendig informasjon.
18. sale_ok
Type: Boolean. Styres om produktet kan selges. Hvis False fjernes det fra salgs- og tilbudsvalg.
19. purchase_ok
Type: Boolean. Bestemmer om produktet kan kjøpes inn. Hvis False vises det ikke i innkjøpsskjemaer.
20. weight
Type: Float. Produktvekt som brukes i fraktberegninger og logistikkplanlegging. Enhet kommer fra selskapets UoM-innstillinger.
21. volume
Type: Float. Produktvolum som påvirker lagerkapasitet og fraktdimensjonering.
22. product_variant_ids
Type: One2many (product.product). Liste over varianter som hører til malen — hver variant arver de feltene som ligger på malen.
23. product_variant_count
Type: Integer. Antall varianter, beregnet fra product_variant_ids. Praktisk for visning og filtrering i UI.
24. image_1920
Type: Binary. Hovedbilde for produktet. Odoo lagrer flere størrelser og bruker bildet i skjemaer, nettbutikk og rapporter.
25. responsible_id
Type: Many2one (res.users). Ansvarlig produktansvarlig i systemet — nyttig for arbeidsflyter og oppgaveansvar.
26. company_id
Type: Many2one (res.company). Angir hvilket selskap produktet tilhører i flerbedriftsmiljø.
27. tax_ids
Type: Many2many (account.tax). Salgsskatter som skal anvendes ved fakturering og tilbud.
28. supplier_tax_id
Type: Many2many (account.tax). Leverandørskatter som gjelder ved innkjøp og leverandørfakturaer.
29. attribute_line_ids
Type: One2many. Linjer som definerer hvilke attributter (f.eks. størrelse, farge) som genererer varianter for malen.
30. route_ids
Type: Many2many (stock.route). Definerer hvilke ruter produktet følger i forsyningskjeden — for eksempel kjøp, produser eller make-to-order.
31. property_stock_production
Type: Many2one (stock.location). Lokasjon brukt ved produksjon for varer som produseres internt.
32. property_stock_inventory
Type: Many2one (stock.location). Standard lokasjon for lagerjusteringer og tellinger.
33. property_valuation
Type: Selection. Valideringsmetode for lager: automatisk eller manuell — påvirker hvordan beholdning bokføres.
34. property_cost_method
Type: Selection. Kostnadsmetode (Standard eller FIFO) som bestemmer hvordan lagerverdien beregnes over tid.
35. property_account_income_id
Type: Many2one (account.account). Inntektskonto som brukes ved salg for riktig regnskapsføring.
36. property_account_expense_id
Type: Many2one (account.account). Kostnadskonto som brukes ved innkjøp og mottak av varer.
37. invoice_policy
Type: Selection. Bestemmer fakturapolicy: fakturer på bestilling eller ved levering — styrer inntektsføringstidspunktet.
38. expense_policy
Type: Selection. Styrer når kostnader føres: ved bestilling eller levering.
39. service_type
Type: Selection. For tjenesteprodukter: manuell, timeregistrering eller milepæler — påvirker hvordan tjenesteleveransen faktureres.
40. optional_product_ids
Type: Many2many (product.template). Forslag til tilleggskjøp eller oppsalg som vises i tilbud og på nett ved valg av dette produktet.
Hvordan modellen brukes i forretningsprosesser
1. Salg og tilbud
Når selgere bygger et tilbud velges produkter fra katalogen — malen gir fellesinformasjon, mens brukeren eventuelt plukker en spesifikk variant hvis produktet har attributter som størrelse eller farge.
2. Nettbutikk
I nettbutikken presenteres produktmalen i katalogen; når kunden går inn på produktet kan de velge blant varianter. Malen sørger for felles beskrivelser og bilder som vises til kundene.
3. Innkjøp og leverandører
Bestillinger og leverandørfakturaer kobles til produktdata fra malen. Felt som purchase_ok, supplier_tax_id og uom_po_id påvirker hvordan innkjøp håndteres i prosessen.
4. Lager og produksjon
Bevegelsene i lager og produksjonsordrer peker typisk på varianter. Malen bestemmer ruter, verdsettingsmetode og kostnadslogikk, mens lagerstatus føres per variant.
5. Fakturering
Fakturalinjer henter skatte- og kontoinnstillinger fra malen. Invoice_policy avgjør også når inntekten skal bokføres i forbindelse med leveranser eller ordre.
Hvordan utviklere bygger på modellen
Utviklere kan utvide product.template med flere strategier, der Odoo-arv er det mest brukte mønsteret.
Modellarv
Ved å sette _inherit = 'product.template' i en modul kan du legge til felter, overstyre metoder eller legge valideringer. Arv holder tilpasningene i egne moduler, noe som gjør oppgraderinger enklere siden grunnmodulen ikke endres direkte.
Legge til felter
Når du definerer nye felter i din arvede modell, velg riktig datatype (Char, Many2one, Boolean osv.). Tenk også på om feltet skal være avhengig av selskap i flerbedriftsoppsett.
Python-utvidelser
Overstyr create, write eller unlink for å injisere logikk, men kall alltid super() der det er nødvendig. Vær spesielt oppmerksom på avhengigheter i beregnede felt og nominasjon av onchange-metoder.
Odoo Studio
Studio gir et raskt grensesnitt for å legge til felter uten kode — praktisk for raske endringer. For mer robuste endringer eller vedlikehold over tid er egen modul ofte å foretrekke.
Beste praksis
- Legg delt informasjon i malen og variantspesifikk data i product.product. Riktig ansvarsdeling mellom template og variant gjør både drift og integrasjoner enklere.
- Sett kategorier (categ_id) konsekvent for å sikre korrekt ruting og meningsfulle rapporter.
- Bruk default_code aktivt ved integrasjoner — det er ofte nøkkelen ved synk mot eksterne systemer og bør være konsistent.
- Ved API-integrasjoner bruk XML-RPC eller JSON-RPC mot Odoo sitt API. product.template er tilgjengelig via API-et, men pass på å mappe eksterne ID-er riktig.
- For egendefinerte felter bruk prefikser som x_ eller modulspesifikk prefiks for å unngå navnekonflikter ved fremtidige Odoo-oppgraderinger.
Vanlige feil
- Å opprette separate maler i stedet for varianter fører lett til datarot. Bruk attribute_line_ids når forskjellene mellom produktene bare er attributter som størrelse eller farge.
- Ikke forveksle template og product.product — variantspesifikk informasjon som strekkode og SKU skal ligge på variantnivået.
- Husk å sette sale_ok og purchase_ok riktig; produkter som ikke skal vises for salg eller innkjøp må ha disse feltene konfigurert.
- Unngå å overstyre kjernemetoder uten å kalle super(), det kan skape inkompatibilitet med andre moduler og gjøre fremtidige oppgraderinger utfordrende.
- Legg ikke til nye obligatoriske felter uten å gi standardverdier — eksisterende poster vil feile validering ved oppgradering hvis feltet mangler data.
Konklusjon
product.template er kjernen i Odoo for produktdefinisjon og delte attributter. Å forstå feltene og utvidelsesmulighetene gjør det langt enklere å sette opp, tilpasse og integrere Odoo.
Enten du jobber med katalogkartlegging eller utvikler skreddersydde moduler, vil kunnskap om product.template spare tid og redusere risikoen for feil.
Kom i gang med Dasolo
Dasolo hjelper bedrifter med å implementere og optimalisere Odoo, spesielt innen API-integrasjoner og utvikling. Vi har erfaring med Odoos datamodell og modeller som product.template.
Trenger du hjelp med implementasjon, tilpasning eller integrasjoner i Odoo, så kan vi bistå med rådgivning og utvikling. Bestill en demonstrasjon for å snakke om prosjektet ditt.