Introduksjon
I Odoo organiseres all forretningsinformasjon i modeller — strukturer som bestemmer hvilke data som lagres og hvordan de henger sammen. Alt fra ordrer og fakturaer til kontakter ligger i slike modeller, og de er grunnmuren i systemet.
Å forstå Odoo-modeller er nødvendig både for utviklere og funksjonelle konsulenter. Modellene fastsetter felter, relasjoner og forretningslogikk, og danner dermed grunnlaget for hvordan data flyter gjennom løsningen.
Denne artikkelen går gjennom en av de mest brukte modellene i Odoo: res.partner. Enten du utvikler moduler, kobler til eksterne systemer eller setter opp interne prosesser, vil du ofte møte denne modellen.
Hva er res.partner-modellen
res.partner representerer personer, kunder, leverandører og selskaper i Odoo — kort sagt alle parter du gjør forretninger med. Her samles kontaktinformasjon, adresser og viktige forretningsopplysninger.
Modellen er påkalt i nesten alle moduler: Salg, CRM, regnskap, innkjøp og netthandel henter partnerdata fra res.partner. Når du oppretter en kunde, leverandør eller en kontakt, opprettes eller knyttes et res.partner-objekt.
res.partner ligger i base-modulen og blir utvidet av andre moduler via Odoos arvemekanisme. CRM, regnskap og andre moduler legger til felter og regler uten å duplisere kjernen, slik at funksjonalitet bygges lagvis.
Viktige felt i modellen
Under følger de viktigste feltene du bør kjenne i res.partner. Kjennskap til disse forenkler konfigurasjon, integrasjon og feilsøking knyttet til kontakter og partnere.
1. name
Type: Char. Hovedfeltet for partnerens navn — firmanavn for selskaper eller fullt navn for personer. Navnet vises i de fleste lister og er ofte primæridentifikatoren i grensesnittet.
2. create_date
Type: Datetime. Tidspunktet da posten ble opprettet. Odoo setter dette automatisk og feltet er nyttig for revisjon og rapportering.
3. write_date
Type: Datetime. Tidspunkt for siste endring. Også automatisk håndtert og viktig for sporbarhet når data endres.
4. email
Type: Char. Hoved-e-postadresse for kontakt og kommunikasjon. Brukes ved utsendelse av dokumenter og portaltilgang; Odoo forsøker å validere formatet.
5. phone
Type: Char. Hovedtelefonnummer som vises i kontaktkort og benyttes i arbeidsflyter for kommunikasjon.
6. mobile
Type: Char. Mobilnummer, ofte brukt for varsler eller SMS når det skiller seg fra hovedtelefonen.
7. street
Type: Char. Første adressefelt — gateadresse som inngår i standard adresseblokker på dokumenter og skjemaer.
8. street2
Type: Char. Andre adressefelt for leilighetsnummer, bygning eller tilleggsinformasjon.
9. city
Type: Char. By eller sted. Adresseformat kan variere mellom land, så landavhengig logikk kan påvirke visningen.
10. zip
Type: Char. Postnummer, brukt ved validering og fraktberegning.
11. state_id
Type: Many2one (res.country.state). Fylke eller delstat. Verdiene filtreres basert på valgt land; ikke alle land bruker dette nivået.
12. country_id
Type: Many2one (res.country). Landvelgeren styrer adresseformat, skatteregler og lokaliseringslogikk.
13. is_company
Type: Boolean. Angir om posten er et selskap eller en person. Selskaper kan ha underkontakter, mens personer kan knyttes til en forelder via parent_id.
14. parent_id
Type: Many2one (res.partner). Lenker en kontakt til et moderfirma. Gir hierarki mellom selskap og ansatte/kontakter og kan arve adresseinformasjon fra forelderen.
15. child_ids
Type: One2many (res.partner). Inversen av parent_id — liste over kontakter som hører til et selskap. Gjør det enkelt å navigere fra firma til personer.
16. company_id
Type: Many2one (res.company). Viser hvilken Odoo-virksomhet partneren hører til i multi-selskap-oppsett. Påvirker synlighet og tilgangskontroller.
17. vat
Type: Char. MVA-nummer eller skatteregistrering. Valideres etter landsspesifikke mønstre og er viktig for fakturering og etterlevelse.
18. customer_rank
Type: Integer. Teller som indikerer om partneren er kunde basert på salgsaktivitet. Brukes til filtrering og prioritering i rapporter.
19. supplier_rank
Type: Integer. Tilsvarende for leverandører — økes ved kjøpsordrer eller leverandørfakturaer for å identifisere aktive leverandører.
20. user_id
Type: Many2one (res.users). Ansvarlig selger eller kontaktperson internt. Benyttes i CRM, tildelinger og aktivitetsstyring.
21. type
Type: Selection. Adressekategori for underkontakter: Kontakt, Faktura, Levering eller Annet. Bestemmer hvilken adresse som brukes på dokumenter.
22. ref
Type: Char. Intern referanse eller kode. Nyttig for integrasjoner og eksterne nøkkelkartlegginger.
23. website
Type: Char. Nettadresse for partneren, vises i kontaktkort og på nettsider/handelsscenarioer.
24. comment
Type: Html. Interne notater og instrukser som bare vises for interne brukere, for eksempel salgsanmerkninger.
25. active
Type: Boolean. Arkiveringsflagg — når False skjules posten fra standardvisninger uten å slette den permanent.
26. lang
Type: Selection. Foretrukket språk for kommunikasjon og dokumenter. Kan arves fra parent_id ved behov.
27. image_1920
Type: Binary. Partnerens bilde eller logo. Odoo lagrer flere størrelser for visning i skjema, rapporter og nettsted.
28. category_id
Type: Many2many (res.partner.category). Tagging eller kategorier for segmentering, filtrering og markedsføringstiltak.
Slik brukes modellen i forretningsarbeidsflyter
1. Salg og CRM
I salgsprosessen velger selgeren kunden fra res.partner slik at lead, mulighet og ordre pekes mot samme partnerpost. customer_rank og user_id påvirker styring og rapportering.
2. Fakturering
Fakturaer og leverandørfakturaer peker til partner for fakturaadresse. VAT-feltet er sentralt i skatteberegning, og betalingsbetingelser eller kredittgrenser knyttes ofte til partneren.
3. Innkjøp og leverandører
Innkjøpsordrer og leverandørfakturaer refererer også til res.partner. supplier_rank hjelper med å identifisere leverandører, og buyer_id kan tilordne en ansvarlig for leverandørrelasjonen.
4. Netthandel og portal
Brukere som registrerer seg på nettstedet får partnerposter opprettet som brukes for ordre, tilbud og portaltjenester — alle bestillings- og adressefelt hentes fra partneren.
5. Multi-selskap og konsolidering
I multi-selskap-miljø kan samme juridiske enhet eksistere som egne partnerposter per selskap. company_id og inter-company-regler styrer hvordan og når data deles mellom selskaper.
Slik utvider utviklere denne modellen
Utviklere bygger på res.partner med flere teknikker, der Odoos modellarv er hovedverktøyet.
Modellarv
Ved å sette _inherit = 'res.partner' utvider du modellen: legg til felter, endre metoder eller sette begrensninger. Endringene isoleres i modulen og gjør vedlikehold enklere ved oppgraderinger.
Legge til felt
Definer nye felt i din arvede modell med riktig datatype — Char, Many2one, Boolean, Integer, Text eller Selection. Tenk gjennom selskapsspesifikke felter for multi-selskap-oppsett.
Utvikling i Python
Overstyr create, write eller unlink for å legge forretningslogikk, men kall alltid super() for å bevare eksisterende flyt. Vær varsom med avhengige beregnede felt og deres triggers.
Odoo Studio
Odoo Studio gir mulighet for å legge til felt uten koding — raskt for enkle tilpasninger. For mer avansert logikk eller driftssikre endringer er egendefinerte moduler å foretrekke.
Anbefalte fremgangsmåter
- Opprett selskapet først og legg deretter til kontakter med parent_id for å bevare riktig hierarki.
- Sørg for å sette country_id riktig for korrekt adresseformat og skatteoppsett.
- Bruk commercial_partner_id når du trenger toppnivå-entenheten for grupperinger som kredittvurdering eller konsoliderte rapporter.
- Ved API-integrasjoner bruk XML-RPC eller JSON-RPC. res.partner er tilgjengelig via API-et — kartlegg eksterne ID-er nøye for å unngå duplikater.
- Navngi egendefinerte felt med x_-prefiks eller med modulnavn for å unngå kollisjoner ved fremtidige Odoo-oppgraderinger.
Vanlige feil
- Å opprette duplikate partnere i stedet for å søke opp eksisterende. Bruk felt som
email_normalizedellerreffor deduplisering. - Å forveksle parent_id og company_id. parent_id kobler kontakt til selskap, mens company_id angir hvilken Odoo-virksomhet posten tilhører.
- Å glemme å sette riktig type på underkontakter. Faktura- og leveringsadresser må ha korrekt type for å bli brukt på dokumenter.
- Å overstyre kjernemetoder uten å kalle
super(). Dette kan bryte andre moduler eller skape problemer ved oppgraderinger. - Å legge til nye obligatoriske felt uten å sette standardverdier. Eksisterende poster kan feile validering ved oppgradering.
Avslutning
res.partner er kjernen i Odoo for kontaktadministrasjon. Å mestre modellens felt og hvordan den utvides gjør det enklere å konfigurere systemet, bygge integrasjoner og unngå vanlige fallgruver.
Enten du kartlegger forretningsprosesser som konsulent eller utvikler funksjonalitet som utvikler, vil solide kunnskaper om res.partner spare tid og redusere feil.
Trenger du hjelp med Odoo-implementasjonen?
Dasolo bistår selskaper med implementasjon, tilpasning og optimalisering av Odoo. Vi har spisskompetanse på API-integrasjoner og utvikling, og inngående kjennskap til Odoos datamodeller som res.partner.
Hvis dere trenger hjelp med implementasjon, skreddersydde moduler eller integrasjoner, kan vi hjelpe. Book en demo for å diskutere prosjektet ditt.