Introduktion
I Odoo er modellerne rammen for al forretningsdata — de bestemmer, hvordan information gemmes, relateres og hentes fra databasen. Alt fra tilbud og indkøb til lagerbeholdning og varer er repræsenteret som poster i modellerne.
For både udviklere og funktionskonsulenter er det afgørende at forstå modellerne. De danner fundamentet for Odoos datalogi: felter, relationer og forretningslogik ligger i modellerne og former, hvordan systemet opfører sig.
Her kigger vi nærmere på en af de mest centrale modeller i Odoo: product.product. Uanset om du bygger moduler, kobler eksterne systemer på eller sætter produktkataloger op, kommer du til at arbejde med denne model.
Hvad er produktmodellen product.product
product.product repræsenterer de konkrete varianter — de fysiske eller digitale enheder, som sælges, købes og flyttes i lagerstyringen. Det er de poster, der vises på ordrelinjer, leveringsbevægelser og i webshoppen.
Modellen står i kontrast til product.template: templaten indeholder fælles egenskaber for en produktfamilie, mens product.product er hver enkelt variant. For et simpelt produkt uden varianter svarer en template til én variant; for konfigurerbare produkter (fx T-shirt med størrelse og farve) er hver kombination sin egen variant.
Modellen er defineret i produktmodulet og bliver brugt tværs af Salg, Indkøb, Lager og E-handel. Når du lægger en vare på et tilbud, modtager en leverance eller opretter en linje, arbejder du med product.product-poster.
product.product benytter delegation fra product.template: mange felter er placeret på templaten og videreføres til varianterne. Det gør det nemt at holde fælles data ét sted, mens varianter kan få deres egne værdier.
Vigtige felter i modellen
Nedenfor finder du de væsentligste felter i product.product. At kende dem gør det langt lettere at håndtere varianter korrekt i Odoo.
1. name
Type: Char. Variantens navn — det, der vises i lister, formularer og dokumenter. For simple produkter matcher det template-navnet; for varianter kan det inkludere attributer (fx "T-shirt — Blå / M").
2. product_tmpl_id
Type: Many2one (product.template). Forbindelsen til parent-templaten. Hver variant hører til præcis én template, og denne relation er central, når du udvider eller hænger logik på produktet.
3. default_code
Type: Char. Intern reference eller artikelnr. Bruges til identifikation, stregkoder og integration. Hver variant kan have sit eget SKU.
4. barcode
Type: Char. Stregkode (EAN, UPC osv.). Bruges ved POS, i lageret og ved plukning. Når sat, bør den være unik for hurtig opslag.
5. create_date
Type: Datetime. Tidspunktet for oprettelse af posten. Håndteres automatisk af Odoo og er nyttig til rapportering og audit.
6. write_date
Type: Datetime. Sidste ændringstidspunkt. Også automatisk. Hjælper med at spore opdateringer.
7. active
Type: Boolean. Blødt sletningsflag — når False arkiveres produktet og skjules fra standardvisninger, men historikken bevares.
8. type
Type: Selection. Produkttype: Consumable, Service eller Storable Product. Dette afgør, om varen trackes i lager, om den kan planlægges i MRP osv.
9. categ_id
Type: Many2one (product.category). Produktkategori til rapportering, prisregler og katalogstruktur. Kategorier kan være hierarkiske.
10. list_price
Type: Float. Salgspris vist på tilbud og som standard på ordrelinjer. Kan overskrives af prisregler eller kundespecifikke prislister.
11. standard_price
Type: Float. Kostpris anvendt til lagerværdi og bruttomarginberegning. Opdateres typisk via indkøb eller manuelt ved lagerjusteringer.
12. uom_id
Type: Many2one (uom.uom). Enhed for salg og lager (stk., kg, l osv.). Angiver, hvordan mængder måles.
13. uom_po_id
Type: Many2one (uom.uom). Enhed for indkøb — kan afvige fra salgs-/lagerenheden (fx købes i kasser, sælges i styk). Konvertering håndteres automatisk.
14. description_sale
Type: Html. Salgsbeskrivelse, der vises på tilbud, ordrer og fakturaer. Kan indeholde formatering og produktdetaljer.
15. description_purchase
Type: Html. Beskrivelse til indkøb, synlig på indkøbsordrer og leverandørfakturaer. Bruges til kommunikation med leverandører.
16. sale_ok
Type: Boolean. Kan sælges. Når False er produktet skjult i salg og webshop — praktisk til interne eller kun-indkøbsvarer.
17. purchase_ok
Type: Boolean. Kan købes. Når False kan produktet ikke vælges i indkøb, relevant for produktion eller salg-only varer.
18. image_1920
Type: Binary. Produktbillede i høj opløsning. Odoo gemmer flere størrelser (image_512, image_256 osv.) til visning i formularer og på webshoppen.
19. weight
Type: Float. Vægt — bruges til forsendelsesberegninger og logistik. Enheden afhænger af firmakonfigurationen.
20. volume
Type: Float. Volumen — vigtigt ved forsendelse og lagerkapacitetsstyring, især ved volumetriske begrænsninger.
21. company_id
Type: Many2one (res.company). Angiver hvilken virksomhed i en multi-company opsætning der ejer produktet. Påvirker synlighed og lager.
22. currency_id
Type: Many2one (res.currency). Valuta for list_price og standard_price — normalt firmavalutaen, mens prislister kan konvertere til andre valutaer.
23. qty_available
Type: Float. Lagerantal på lageret. Beregnes fra quants og er skrivebeskyttet. Bruges til tilgængelighedstjek for storable produkter.
24. virtual_available
Type: Float. Forventet tilgængelighed (på lager + indgående − udgående). Computed felt til genbestilling og planlægning.
25. product_template_attribute_value_ids
Type: Many2many. Forbinder varianten med de attributværdier, der definerer den (fx Farve=Blå, Størrelse=M). Bruges i variantkonfiguratorer og filtrering.
26. sequence
Type: Integer. Sorteringsprioritet — lavere tal vises først i lister og konfiguratorer.
27. display_name
Type: Char. Beregnet visningsnavn, som kombinerer navn og attributter. Bruges i dropdowns og søgninger; skrivebeskyttet.
28. responsible_id
Type: Many2one (res.users). Ansvarlig person for produktet — bruges i genbestillingsregler og interne ansvarsfordelinger. Valgfrit.
Hvordan modellen bruges i forretningsprocesser
1. Salg og tilbud
Når en sælger opretter et tilbud vælger de en produktvariant. Listeprisen, salgsbeskrivelsen og enheden overføres til ordrelinjen, mens prislister kan ændre prisen. Kun varer med sale_ok=True vises i salgsvinduet.
2. Indkøb og leverandører
Indkøbsordrer og leverandørfakturaer peger på varianterne. Kostprisen kan opdateres fra indkøb, og uom_po_id styrer, hvordan mængder bestilles (fx i kasser). Kun purchase_ok-varetyper kan vælges i indkøb.
3. Lager og logistik
Lagerbevægelser, pluk og quants er alle knyttet til product.product. Felterne qty_available og virtual_available afgør tilgængelighed. Kun storable produkter trackes, og stregkoder bruges til hurtig identifikation ved scanning.
4. E-handel og webshop
Webshoppen henter varianterne direkte fra product.product. Forskellige attributter vises som valgmuligheder (størrelse, farve), og billeder, beskrivelser og priser kommer fra varianten. Sale_ok styrer, om en variant vises online.
5. Produktion (MRP)
Styklisten kan referere til varianter både som komponenter og færdigvarer. Produkttypen afgør, om varen indgår i lagerstyring eller blot forbruges, og lagerbeholdningen påvirker planlægning af produktion.
Hvordan udviklere udvider modellen
Udviklere kan bygge videre på product.product gennem forskellige udvidelsesmønstre; Odoo-arv er det primære værktøj.
Modelarv
Sæt _inherit = 'product.product' i dit modul for at tilføje felter, overskrive metoder eller indføre begrænsninger. Placer ændringer i et separat modul for nemmere opgraderinger. Vælg product.product for variant-specifikke felter; brug product.template for data, der gælder for hele produktfamilien.
Tilføjelse af felter
Definér nye felter i din arvede model med passende typer (Char, Many2one, Boolean, Integer, Text, Selection). Overvej om feltet skal være på templaten (fælles) eller på varianten (specifikt). Variant-specifikke data som alternativt SKU eller stregkode hører hjemme på product.product.
Python-udvidelser
Override create, write eller unlink for at tilføje forretningslogik, men kald altid super() for at bevare standardadfærd. Pas især på afhængigheder for beregnede felter — product.product har mange beregnede felter fra lager og salg.
Odoo Studio
Odoo Studio giver mulighed for hurtige feltændringer uden kode — fint til hastige tilpasninger. For kompleks logik og langtidsholdbare løsninger er et egentligt modul dog mere robust. API'en (XML-RPC/JSON-RPC) eksponerer modeldata til integrationer.
Best practices
- Brug default_code eller barcode som nøgle i integrationer — hold dem unikke og konsistente på tværs af systemer.
- Sæt produkttypen korrekt: valg mellem Consumable, Storable og Service ændrer hvilke workflows og moduler der gælder.
- Til API-arbejde: brug product.product til ordrelinjer og transaktioner; brug product.template ved katalog- eller masterdata-operationer.
- Tilpasningsfelter bør have x_ eller modulpræfiks for at undgå navnekonflikter ved opgraderinger.
- Sæt felter på product.template når de gælder alle varianter (fx brand eller overordnet kategori). Brug product.product til variant-specifikke oplysninger (fx varianters egne stregkoder).
Almindelige fejl
- Undgå at arve fra product.template hvis du har brug for adfærd per variant — brug product.product til variantlogik.
- Opret ikke variantposter manuelt uden at bruge konfiguratoren ved konfigurerbare produkter; opret dem gennem templaten for konsistens, medmindre der er en særlig grund.
- Glem ikke at sætte sale_ok eller purchase_ok — i visse opsætninger skjules produkter fra salg eller indkøb som standard.
- Overskriv ikke kernemetoder uden at kalde super() — det kan bryde andre moduler eller skabe problemer ved opdateringer.
- Brug ikke product.product i domæner hvor product.template er mere relevant (fx filtrering på kategori på template-niveau).
Konklusion
product.product er kernen i Odoos produktarkitektur: den står for de faktiske salgbare og købsbare varianter. Kendskab til modellens felter og dens relation til product.template er centralt for korrekt konfiguration, tilpasning og integration.
Uanset om du kortlægger produktdata som funktionskonsulent eller udvikler specialmoduler, sparer du tid og undgår fejl ved at have et solidt greb om product.product.
Brug for hjælp til din Odoo-implementering?
Dasolo hjælper virksomheder med at implementere, tilpasse og optimere Odoo. Vi har særligt fokus på API-integrationer og udvikling og dyb erfaring med Odoos datamodel og centrale modeller som product.product.
Har du brug for hjælp til Odoo-implementering, specialmoduler eller integrationer, står vi klar til at assistere. Book en demo for at snakke om dit projekt.