Reference Field i Odoo: Den Ultimative Guide for Udviklere

Introduktion

De fleste Odoo-udviklere griber instinktivt efter Many2one-feltet, når to poster skal forbindes — og det er ofte det rigtige valg. Men i nogle arbejdsgange skal en kobling kunne pege på forskellige typer dokumenter afhængigt af situationen: en salgsordre, en indkøbsordre, en timeseddel eller noget helt andet. Her kommer Reference-feltet ind i billedet: et fleksibelt link der kan pege på flere mulige model-typer.

Reference-feltet er et polymorft felt i Odoo ORM, designet til at pege på et record fra en foruddefineret liste af modeller i stedet for kun én fast model. Brugeren vælger først typen af dokument og derefter den konkrete post — resultatet er en dynamisk reference, der kan tilpasse sig forskellige arbejdsprocesser.

Denne guide forklarer hvad Reference-feltet gemmer, hvordan det opfører sig i datamodellen, hvordan du opretter og tilpasser det via Odoo Studio eller i Python, samt konkrete forretningsscenarier hvor feltet virkelig gør en forskel.

Hvad er Reference-feltet i Odoo

I Odoo er Reference-feltet en særlig felt-type, som gemmer en peger til en post fra en af de modeller, du tillader i selection-listen. Det adskiller sig fra Many2one ved at være model-agnostisk — det behøver ikke pegning mod én bestemt model.

I databasen gemmes værdien som en tekststreng i formatet model_navn,record_id. Et link til salgsordre 42 vil fx være sale.order,42. Det er nyttigt at kende til, når du skal lave direkte SQL-forespørgsler eller bygge filtrering, der arbejder med Reference-felter.

I brugerfladen fungerer Reference-feltet som en todelt proces: først vælger brugeren dokumenttypen fra en dropdown (fx Salgsordre, Faktura eller Projektopgave), og derefter søger og vælger den konkrete post fra den valgte model. Når brugerne har vænnet sig til to-trins-valget, er oplevelsen enkel og effektiv.

Et typisk eksempel på en Reference-felt-definition i Python ser ud på denne måde:

from odoo import fields, models

class HelpDeskTicket(models.Model):
    _inherit = 'helpdesk.ticket'

    related_document = fields.Reference(
        selection=[
            ('sale.order', 'Sale Order'),
            ('purchase.order', 'Purchase Order'),
            ('account.move', 'Invoice'),
            ('project.task', 'Project Task'),
        ],
        string='Related Document',
    )

selection-parameteren er en liste af tuples, hvor hver tuple indeholder det tekniske modelnavn (fx sale.order) og den bruger-facing tekst, som vises i dropdown. Du vælger præcis hvilke modeller, der skal kunne vælges.

Du kan også gøre selection dynamisk ved at bygge listen fra ir.model ved runtime, hvilket gør alle installerede modeller tilgængelige. Det kan være kraftfuldt i meget konfigurerbare løsninger, men kræver filtrering for ikke at overvælde brugerne.

I Odoo Studio findes Reference-feltet under felt-typer og hedder Reference. Når du tilføjer det via Studio, kan du vælge hvilke modeller der skal være i listen direkte i GUI, uden at skrive kode. Det gør feltet tilgængeligt også for ikke-udviklere.

Hvordan feltet fungerer

At kende til hvordan Reference-feltet gemmer og henter data er afgørende for at bruge det korrekt i Odoo-udvikling.

Lagring i databasen

I modsætning til Many2one, som kun gemmer en integer (fremmednøglen), gemmer Reference-feltet en tekststreng bestående af både modelnavnet og record-id'et, fx sale.order,15. Kolonnen er typisk en VARCHAR i PostgreSQL — hvilket betyder, at databasen ikke håndhæver en egentlig fremmednøgle, netop for at understøtte feltets polymorfe natur.

Fordi der ikke er en database-level fremmednøgle, rydder Odoo ikke automatisk Reference-feltet, hvis den refererede post slettes. Hvis en salgsordre fjernes, vil Reference-feltet stadig indeholde den gamle streng. Det er en vigtig adfærd at tage højde for i design og automatisering.

Adgang til den linkede post i Python

Når du læser et Reference-felt i Python, returnerer Odoo faktisk den konkrete record-objekt fra den refererede model. Du kan tilgå dens felter som normalt; hvis feltet er tomt returneres False.

ticket = self.env['helpdesk.ticket'].browse(1)
doc = ticket.related_document

if doc:
    print(doc._name)   # e.g. 'sale.order'
    print(doc.name)    # e.g. 'S00042'
    print(doc.id)      # e.g. 15

Det er en praktisk egenskab i Odoo-ORM: selv om værdien i databasen er en tekststreng, oversætter frameworket den til et rigtigt record-objekt når du arbejder med den i kode.

Væsentlige felt-attributter

Her er de vigtigste parametre du typisk konfigurerer på et Reference-felt i Odoo:

• selection: Liste af tuples der bestemmer hvilke modeller brugeren kan vælge. Kan også være navnet på en metode (string) som returnerer listen dynamisk.
• string: Feltets label som vises i brugerfladen.
• required: Gør feltet obligatorisk — brugeren skal vælge både modeltype og post for at kunne gemme.
• readonly: Forhindrer ændringer i UI. Godt til referencer som sættes af systemet.
• help: Hjælpetekst der vises som tooltip for at guide brugeren i hvad der skal vælges.
• compute: Reference-feltet kan være beregnet via en Python-metode, så det sættes automatisk ud fra forretningslogik.

Filtrering og søgning

Da værdien gemmes som en tekststreng, kræver søgninger på Reference-feltet særlige domænenotationer. For at finde poster som peger på en specifik dokument-id skal du sammenstille strengværdien selv:

tickets = self.env['helpdesk.ticket'].search([
    ('related_document', '=', 'sale.order,15')
])

Du kan også filtrere efter modeltype med en like-operator:

tickets = self.env['helpdesk.ticket'].search([
    ('related_document', 'like', 'sale.order,')
])

Husk denne streng-baserede søgeadfærd når du designer rapporter eller beregnede felter, som skal tage Reference-værdier i betragtning — den opfører sig ikke som et typisk Many2one-domæne.

Forretningsscenarier hvor det giver værdi

Reference-feltet viser sin styrke dér, hvor samme type kobling skal kunne pege på flere slags dokumenter alt efter kontekst. Nedenfor er fem praktiske eksempler fra virkelige arbejdsgange.

1. Supporttickets knyttet til forskellige dokumenter

Et supportteam kan få sager relateret til fakturaer, leverancer, kontrakter eller salgsordrer. I stedet for at have separate felter til hver dokumenttype, kan en enkelt Reference på ticket-modellen lade agenten vælge hvilken type dokument og så den konkrete post — al kontekst samles ét sted.

2. Salgsaktiviteter med forskellige kilder

Salgsteamets opfølgnings-aktiviteter kan stamme fra leads, tilbud, kontrakter eller supportsager. Et Reference-felt på aktivitets- eller note-modellen gør det muligt at markere oprindelsesdokumentet uden at binde sig til én model, hvilket giver fleksibel sporing i CRM-arbejdsgange.

3. Centrale noter på tværs af moduler

Nogle organisationer skaber en fælles notemodel til annoteringer på tværs af kundekort, projekter, produktionsordrer eller indkøb. Et Reference-felt gør det muligt at vedhæfte den samme note til mange objekttyper uden at duplikere notemodellen pr. dokumenttype.

4. Generel godkendelsesflow

Når du laver en universel godkendelsesproces, skal godkendelsesanmodningen pege på det dokument, der skal godkendes — og disse kan variere fra indkøb til rejseafregninger eller orlovsanmodninger. En Reference på approval-modellen holder arkitekturen enkel: samme logik håndterer alle dokumenttyper.

5. Udgifter der kan kobles til projekt eller ordre

I mange konsulent- eller projektbaserede virksomheder skal en udgift enten henføres til et projekt eller en salgsordre. Et Reference-felt med både project.project og sale.order i selection-listen giver regnskabsteamet fleksibiliteten til at knytte udgiften korrekt efter type.

Oprettelse og tilpasning af Reference-feltet

Der er to hovedmåder at tilføje et Reference-felt: hurtigt og uden kode via Odoo Studio, eller som del af en teknisk Python-implementation for fuld kontrol.

Brug af Odoo Studio

Odoo Studio gør det nemt at lægge et Reference-felt på en form uden udvikling. Åbn Studio for den ønskede model, gå til felt-panelet og vælg Reference. Studio giver dig mulighed for at vælge hvilke modeller der skal være i dropdown-listen, og feltet oprettes som et x_-felt i systemet.

Dette er perfekt til hurtige tilpasninger eller når en forretningsanalytiker skal udvide et interface. Vær dog opmærksom på, at Studio-felter kan have begrænsninger mht. dynamiske selection-metoder eller komplekse beregnede værdier.

Teknisk implementering i Python

Når du vil have fuld kontrol, definerer du feltet i en Python-model. Her er et eksempel, der viser en Reference med dynamisk selection via en metode:

from odoo import api, fields, models

class ApprovalRequest(models.Model):
    _name = 'approval.request'
    _description = 'Approval Request'

    name = fields.Char(string='Request Name', required=True)

    @api.model
    def _get_document_types(self):
        return [
            ('purchase.order', 'Purchase Order'),
            ('hr.expense.sheet', 'Expense Report'),
            ('hr.leave', 'Time Off Request'),
            ('sale.order', 'Sale Order'),
        ]

    document_ref = fields.Reference(
        selection='_get_document_types',
        string='Document',
        help='Select the document this approval relates to.',
    )

Hvis du giver navnet på en metode som selection, kan du bygge listen dynamisk — fx filtrere på installerede moduler, læse konfigurationsposter eller anvende forretningsregler.

Oprettelse via XML-RPC API

Du kan også oprette Reference-felter programmatisk via Odoo's XML-RPC API, nyttigt ved fjern-deployment af konfiguration. Felt-typen hedder reference og selection sendes som en streng der repræsenterer listen:

field_id = models.execute_kw(
    ODOO_DB, uid, ODOO_API_KEY,
    'ir.model.fields', 'create',
    [{
        'name': 'x_related_document',
        'field_description': 'Related Document',
        'model_id': model_id,
        'ttype': 'reference',
        'selection': "[('sale.order', 'Sale Order'), ('purchase.order', 'Purchase Order')]",
        'state': 'manual',
    }]
)

Bemærk at når du opretter feltet via API, sendes selection som en Python-evaluerbar streng — det er sådan Odoo gemmer den i ir.model.fields.

Anbefalet praksis

Her er nogle praktiske retningslinjer at følge når du arbejder med Reference-felter i din datamodel.

• Hold selection-listen kort og relevant. Medtag ikke alle modeller blot fordi du kan. Begræns valgmulighederne til de dokumenttyper der reelt giver mening for brugernes opgaver — for mange valgmuligheder forvirrer.
• Brug Many2one når relationen altid er mod én model. Hvis feltet altid peger på samme model, er Many2one enklere, hurtigere at forespørge og bedre understøttet i rapporter.
• Tjek altid for tomme værdier i beregnede felter. Et tomt Reference-felt returnerer False i Python. Al kode der tilgår den refererede post skal håndtere dette for at undgå fejl.
• Ryd op i forældreløse referencer gennem automatisering. Fordi der ikke er DB-fremmednøgler, er det smart at have en plan — fx en scheduled action — der periodisk scanner og fjerner eller markerer referencer til slettede poster.
• Brug tydelige, forretningsvenlige labels i selection. Det brugeren ser i dropdown er den anden del af tuplen — skriv fx "Kunde-Faktura" i stedet for det tekniske modelnavn.
• Dokumentér valget i tekniske specifikationer. Reference-felter opfører sig anderledes end Many2one. Beskriv hvorfor en Reference blev valgt og hvilke modeller den linker til, så fremtidige udviklere forstår designet.

Almindelige faldgruber

Her er de fejl vi ser oftest når teams arbejder med Reference-felter for første gang.

At behandle det som en Many2one i domæner

En typisk fejl er at bygge domæner som om feltet var en Many2one, fx [('document_ref', '=', 15)]. Det virker ikke, fordi det faktisk er en streng som skal matche model,ID formatet. Du må bygge den fulde streng ved søgning.

Glemme at slette efter slettede records

Hvis en refereret post slettes, efterlader DB'en stadig strengen i Reference-feltet. Når du læser feltet efter sletningen vil det returnere False i stedet for at give en fejl — men din forretningslogik må tage højde for at referencen kan være forældet.

Overforbrug af dynamisk 'alle-modeller' selection

Selvom du kan hente alle installerede modeller fra ir.model, er det sjældent en god idé at præsentere hundredevis af modeller for slutbrugeren. Begræns altid listen til relevante dokumenttyper for at undgå fejlindtastning.

Forvent ikke native gruppering i rapporter

Reference-felter er tekst i databasen — ikke fremmednøgler — så standard group-by og pivot i Odoo virker ikke på samme måde som på Many2one. Hvis du skal aggregere eller gruppere efter linked dokument, overvej et beregnet felt der ekstraherer modelnavnet eller en separat selection/char-kolonne.

Forveksling af Reference og Many2one i Studio

I Studio kan brugere blive i tvivl mellem Reference og Many2one fordi begge lader dig linke til andre poster. Husk: Many2one er låst til én model ved oprettelse; Reference tillader brugeren at vælge modellen ved hver udfyldelse. Forkert valg kræver ofte, at feltet bygges om.

Afrunding

Reference-feltet udfylder et hul Many2one ikke kan: fleksibiliteten til at pege på forskellige dokumenttyper uden at duplikere logik. Det er let at definere, kan oprettes uden kode i Studio og integreres naturligt i Python for udviklingsscenarier.

De vigtigste pointer at huske er den streng-baserede lagring, manglen på automatisk oprydning ved sletning, og at domæner kræver fulde model,id-strenge fremfor blot ID'er. Forstå disse forskelle, så opfører feltet sig forudsigeligt i din datamodel.

Uanset om du bygger et generisk godkendelsesflow, knytter supporttickets til forskellige dokumenttyper eller laver et fleksibelt noteværktøj på tværs af moduler, giver Reference-feltet en ren og vedligeholdelsesvenlig løsning uden at duplikere logikken for hver modeltype.

Brug for hjælp til din Odoo-implementering?

Hos Dasolo rådgiver og hjælper vi virksomheder med at implementere, tilpasse og optimere Odoo så det matcher deres faktiske arbejdsprocesser. Vi tilbyder både teknisk udvikling og arkitekturarbejde, fra skræddersyede felter til komplet datamodel-design.

Står du med et Odoo-projekt og mangler input til valg af felttyper, dataarkitektur eller udviklingsbest-practices, så kontakt os gerne. Vi kan gennemgå jeres behov og foreslå den mest hensigtsmæssige løsning.

Kontakt Dasolo