Introduktion
I Odoo beskriver modeller, hvordan forretningsdata organiseres og gemmes. Alt fra ordrer til fakturaer og varekort ligger i modeller — de er kartoteket, som hele systemet bygger på.
At forstå Odoo-modeller er ikke kun for programmører; konsulenter og nøglebrugere får også mest ud af det. Modeller bestemmer felttyper, relationer og forretningslogik, og de følger faste mønstre, som gør det muligt at udvide og genbruge funktionalitet på tværs af systemet.
I denne tekst zoomer vi ind på en af de mest centrale modeller i Odoo, nemlig product.template. Uanset om du opsætter webshoppen, integrerer et ERP-system eller tilretter produktkataloget, dukker denne model op igen og igen.
Hvad er produkt.template-modellen
Produkt.template repræsenterer den generiske vare — et grundlag for produkter, der kun adskiller sig i enkelte varianter som størrelse eller farve. I stedet for at oprette en hel række separate varer, er det ofte smartere at bygge en template og lade varianterne arve de fælles egenskaber.
Modellen bruges på tværs af salg, indkøb, lager, webshop og produktion. Når du opretter et katalogprodukt, opretter du et template-record; når en kunde vælger en variant, er det en variant af denne template, som leveres videre i arbejdsgangene.
Selve definitionen ligger i produkt-modulet, og andre apps tilføjer deres lag via Odoos arve-mekanismer. Salg tilføjer priser og fakturakonti, Indkøb håndterer leverandørlogik, Lager tilføjer lagerførelse — hvert modul fylder på uden at kopiere kerneopbygningen.
At kende forskellen på product.template og product.product er afgørende. Template rummer alt fælles; product.product er den konkrete variant med egne felter som strekkode og SKU.
Væsentlige felter i modellen
Her er de vigtigste felter, du møder i product.template — de forklarer, hvordan varen præsenteres, håndteres og bogføres i Odoo.
1. name
Type: Char. Produktets navn. Dette felt er ofte det mest synlige i lister, søgninger og udskrifter, og det fungerer som primær identifikation for template-posten.
2. create_date
Type: Datetime. Tidspunkt for oprettelse. Odoo sætter dette automatisk og det er nyttigt i rapporter og revision.
3. write_date
Type: Datetime. Tidspunkt for sidste ændring. Hjælper med at følge, hvornår data senest blev opdateret.
4. active
Type: Boolean. Blød sletning/arkivering. Sætter du denne til False, gemmes posten men skjules i standardvisninger.
5. sequence
Type: Integer. Bestemmer visningsrækkefølge i lister og dropdowns — lavere tal vises først.
6. type
Type: Selection. Varekategori efter lageradfærd: Forbrugsvarer, Service eller Lagerført. Servicer har ingen fysisk beholdning; lagerførte varer spores i lageret.
7. categ_id
Type: Many2one (product.category). Produktkategori. Påvirker rapportering, standardruter og opsætning af kataloget; kategorier kan være hierarkiske.
8. list_price
Type: Float. Salgspris. Bruges som udgangspunkt i tilbud og kan overskrives af prislister eller variant-priser.
9. standard_price
Type: Float. Kostpris. Bruges til marginberegninger og lagerverdiansættelse; påvirker profitrapportering.
10. currency_id
Type: Many2one (res.currency). Valuta for list_price og standard_price — typisk arvet fra selskabet.
11. uom_id
Type: Many2one (uom.uom). Salgsmål; definerer måleenheden (stk., kg, liter osv.) for salgsdokumenter.
12. uom_po_id
Type: Many2one (uom.uom). Indkøbsmål; kan afvige fra salgs–UoM ved konvertering mellem enheder.
13. default_code
Type: Char. Internt varenummer eller reference. Bruges til integrationer, stregkodning og som SKU i eksterne systemer.
14. barcode
Type: Char. Strekkode til scan i POS og lager. For varianter ligger strekkoden typisk på product.product.
15. description
Type: Char. Interne noter om varen. Synlig for kolleger men ikke nødvendigvis på kundeudskrifter.
16. description_sale
Type: Text. Salgsbeskrivelse der vises på tilbud, ordre og faktura — kan indeholde formatering og HTML.
17. description_purchase
Type: Text. Beskrivelse til indkøb; medsendes leverandørordrer for klar kommunikation med leverandører.
18. sale_ok
Type: Boolean. Angiver om varen kan sælges. Hvis False skjules den i salgsmodulet og tilbudsskabeloner.
19. purchase_ok
Type: Boolean. Angiver om varen kan købes. Hvis False vises den ikke i indkøbsformularer.
20. weight
Type: Float. Vægt på produktet; bruges i fragtberegninger og logistik — enhed styres af firmaets UoM-indstillinger.
21. volume
Type: Float. Volumen; relevant for lagerkapacitet og plukoptimering i varehusstyring.
22. product_variant_ids
Type: One2many (product.product). Listen over varianter tilknyttet templaten — hver variant arver de fælles felter.
23. product_variant_count
Type: Integer. Antal varianter beregnet fra product_variant_ids; nyttigt til filtrering og visning i kataloget.
24. image_1920
Type: Binary. Produktbillede. Odoo genererer flere størrelser til brug i formularer, web og rapporter.
25. responsible_id
Type: Many2one (res.users). Ansvarlig bruger for produktet — bruges til ejerskab og opgavestyring.
26. company_id
Type: Many2one (res.company). Ved multi-company angiver dette, hvilket selskab varen tilhører.
27. tax_ids
Type: Many2many (account.tax). Moms/taksering for salg; anvendes ved fakturering og tilbud.
28. supplier_tax_id
Type: Many2many (account.tax). Moms for indkøb; benyttes på leverandørfakturaer.
29. attribute_line_ids
Type: One2many. Produktattributter der danner varianter (fx størrelse, farve). Opsætningen her styrer, hvilke kombinationer der oprettes.
30. route_ids
Type: Many2many (stock.route). Ruter for vareflow (fx køb, make-to-order). Bestemmer hvordan varen bevæger sig i supply chain.
31. property_stock_production
Type: Many2one (stock.location). Produktionslagerlokation for fremstillede varer — relevant ved produktionsruter.
32. property_stock_inventory
Type: Many2one (stock.location). Standardlokation til lagerjusteringer og optællinger.
33. property_valuation
Type: Selection. Værdiansættelsesmetode: Automatisk eller Manuel — afgør hvordan lagerværdi håndteres i regnskabet.
34. property_cost_method
Type: Selection. Kostmetode: Standard eller FIFO — bestemmer hvordan lageromkostninger beregnes på bevægelser.
35. property_account_income_id
Type: Many2one (account.account). Indtægtskonto ved salg — anvendes i bogføring af salgsfakturaer.
36. property_account_expense_id
Type: Many2one (account.account). Udgiftskonto ved indkøb — bruges ved bogføring af leverandørfakturaer.
37. invoice_policy
Type: Selection. Faktureringspolitik: efter bestilt eller leveret mængde — har betydning for indtægtsregistrering.
38. expense_policy
Type: Selection. Omkostningspolitik: bogfør ved ordre eller ved levering — påvirker omkostningsføring.
39. service_type
Type: Selection. For services: Manuel, Tidsregistrering eller Milepæle — bestemmer hvordan serviceydelser følges og faktureres.
40. optional_product_ids
Type: Many2many (product.template). Valgfrie tilkøb (upsell). Forslås ofte i tilbud, når kunder vælger et hovedprodukt.
Hvordan modellen anvendes i forretningsprocesser
1. Salg og tilbud
Når sælgere bygger et tilbud, trækker de på produktkataloget. Template-fanen leverer det fælles indhold; hvis et produkt har attributter vælger sælgeren den konkrete variant før ordrelinjen afsluttes.
2. Webshop
På webshoppens produktvisning præsenteres templaten med billeder og beskrivelser; kunder vælger varianter (f.eks. farve eller størrelse) før køb, men grundteksten kommer fra templaten.
3. Indkøb og leverandører
Indkøbsordrer og leverandørfakturaer kobles til varerne via templaten/varianten. Feltet purchase_ok styrer, om varen kan vælges, mens leverandørskat og indkøbs-UoM bestemmer indkøbsadfærden.
4. Lager og produktion
Lagerbevægelser og produktionsordrer arbejder med varianter, men templaten styrer ruter, værdiansættelse og kostmetode — lagerstatus holdes per variant.
5. Fakturering
Fakturalinjer refererer til produktlinjer; templaten leverer skattemæssige regler og bogføringskonti, mens invoice_policy påvirker tidspunktet for indtægtsføring.
Hvordan udviklere udvider modellen
Udviklere bygger videre på product.template ved hjælp af Odoos arvemekanismer og veldefinerede mønstre.
Modelarv
I praksis bruger du _inherit = 'product.template' for at udvide modellen. Det lader dig tilføje felter, overskrive metoder og sætte constraints uden at ændre den originale kodebase — hvilket gør vedligehold og opgraderinger lettere.
Tilføjelse af felter
Du definerer nye felter i din udvidelse med passende typer: Char, Many2one, Boolean, Integer, Text eller Selection. Overvej selskabsspecifikke felter i setups med flere firmaer.
Python-udvidelser
Override create, write eller unlink for at tilføre forretningslogik, men husk altid at kalde super() og pas på computed fields og deres afhængigheder, så du ikke skaber uventede sideeffekter.
Odoo Studio
Studio gør det let at tilføje felter og ændre visninger uden kode — fint til hurtige tilpasninger, men til større eller versionskritiske ændringer er en modul-baseret løsning mere robust.
Gode fremgangsmåder
- Hold relationsansvaret klart: fælles egenskaber hører hjemme på templaten; alt, der kun gælder for en variant (fx strekkode), placeres på product.product.
- Sæt altid categ_id korrekt: kategorier påvirker standardruter og rapporter, så forkert kategori kan give forkert lageradfærd.
- Brug default_code til integrationer og eksterne systemer; sørg for unikhed hvor det giver mening for stable mapping.
- Ved API-integrationer brug XML-RPC eller JSON-RPC. Produktmodellen er fuldt tilgængelig via API, men vær omhyggelig med at mappe eksterne IDs og firma-/valutakontekster.
- Tilpasningsfelter bør navngives med x_ eller med modulens præfiks for at undgå navnekonflikter ved fremtidige Odoo-opgraderinger.
Almindelige fejl
- At oprette gentagne templates i stedet for at bruge varianter er en hyppig fejl — brug attribute_line_ids når forskellene kun er i f.eks. størrelse eller farve.
- At forveksle template og variant fører til datainkonsistens. Variant-specifik info som strekkode og SKU skal ligge i product.product.
- Glem ikke at sætte sale_ok og purchase_ok — produkter uden disse vises ikke i salg/indkøb, hvilket ofte forvirrer brugere.
- Overkørsel af kernemetoder uden at kalde super() kan bryde andres moduler eller skabe problemer ved opgradering — husk altid den oprindelige opførsel.
- Tilføj ikke obligatoriske felter uden fornuftige default-værdier; ellers vil eksisterende poster fejle ved installation eller opgradering.
Konklusion
product.template er en hjørnesten i Odoo-landskabet: den samler produktdefinitioner, fælles egenskaber og metadata, som resten af systemet bygger videre på.
Uanset om du kortlægger kataloger som konsulent eller udvikler specialmoduler, sparer en grundlæggende forståelse af templaten tid og mindsker fejl under konfigurering og integration.
Kom i gang med Dasolo
Dasolo hjælper virksomheder med at implementere og tilpasse Odoo — vi specialiserer os i integrationer, udvikling og optimering af Odoo-dataarkitektur, inklusiv arbejdet med modeller som product.template.
Hvis I har brug for hjælp til implementering, specialudvikling eller integrationer i Odoo, står vores team klar til at assistere. Book en demo for at tale om jeres projekt.