Introduksjon
I Odoo definerer modeller hvordan data er strukturert og lagret i databasen. Hver bit av forretningsdata du jobber med, fra salgsordrer til fakturaer til kontakter, lever i en modell.
Å forstå Odoo-modeller er essensielt for både utviklere og funksjonelle konsulenter. Modeller er grunnlaget for Odoo-databasearkitekturen. De definerer felt, relasjoner og forretningslogikk.
Denne artikkelen fokuserer på en av de viktigste modellene i Odoo: sales.order. Enten du bygger tilpassede moduler, integrerer eksterne systemer eller konfigurerer salgsarbeidsflyter, vil du jobbe med denne modellen.
Hva er sales.order-modellen
Modellen sales.order representerer tilbud og salgsordrer i Odoo. Det er det sentrale stedet hvor alle salgstransaksjoner blir registrert før de blir fakturert eller levert.
Denne modellen i Odoo brukes av Salgsmodulen.
Når en selger oppretter et tilbud, oppretter de en sales.order-post. Når kunden bekrefter, går bestillingen fra utkast til bekreftet. Den samme modellen i Odoo holder både utkaststilbud og bekreftede bestillinger. Feltet state sporer livssyklusen.
Andre moduler utvider denne modellen gjennom Odoo-modellarv. CRM kobler muligheter til bestillinger. Regnskap legger til fakturafelt. Lager legger til leverings- og forpliktelsesdatoer. Hver modul legger til det den trenger uten å duplisere den grunnleggende strukturen.
Nøkkelfelt i modellen
Her er de viktigste Odoo-feltene i sales.order-modellen. Å forstå disse vil hjelpe deg å jobbe effektivt med tilbud og bestillinger.
1. name
Type: Char. Dette feltet lagrer bestillingsreferansen eller tilbudsnummeret. Det genereres vanligvis automatisk (f.eks. S00042) og vises i listevisninger og på dokumenter. Det er den primære identifikatoren for bestillingen.
2. state
Type: Selection. Sporer bestillingslivssyklusen. Verdier: draft (tilbud), sent (tilbud sendt til kunde), sale (bekreftet bestilling), done (fullstendig levert og fakturert), cancel (avbrutt). State bestemmer hvilke handlinger som er tilgjengelige.
3. partner_id
Type: Many2one (res.partner). Kunden. Påkrevd. Dette er hovedkontakten eller selskapet for bestillingen. Brukes for all kunde-relatert logikk og rapportering.
4. partner_invoice_id
Type: Many2one (res.partner). Fakturaadressen. Hvis den ikke er satt, standardiseres den til partner_id. Bruk dette når fakturaadressen er forskjellig fra hovedkontakten (f.eks. sentral fakturering).
5. partner_shipping_id
Type: Many2one (res.partner). Leveringsadressen. Hvis den ikke er satt, standardiseres den til partner_id. Brukes for leveringsordrer og fraktberegninger.
6. user_id
Type: Many2one (res.users). Salgspersonen eller ansvarlig bruker. Brukes for CRM, provisjoner og oppgavefordeling. Ofte satt fra salgsteamet eller muligheten.
7. team_id
Type: Many2one (crm.team). Salgsteamet. Grupperer selgere og driver rapportering. Brukes for team-baserte dashbord og kvoter.
8. date_order
Type: Datetime. Ordredatoen. For utkastordrer: opprettelsesdato. For bekreftede ordrer: bekreftelsesdato. Brukes for rapportering og sortering.
9. validity_date
Type: Date. Utløpsdatoen for tilbudet. Etter denne datoen kan tilbudet bli ugyldig. Nyttig for tidsbegrensede tilbud.
10. commitment_date
Type: Datetime. Den lovede leveringsdatoen. Når den er satt, planlegges leveringsordrer basert på denne datoen i stedet for produktledetider. Viktig for kundeverv.
11. order_line
Type: One2many (sale.order.line). Ordrelinjene. Hver linje inneholder produkt, kvantitet, pris og skatt. Dette er kjernedetaljen i ordren.
12. amount_untaxed
Type: Float. Delsummen før skatt. Beregnet fra ordrelinjene. Brukes til rapportering og visning.
13. amount_tax
Type: Float. Det totale skattebeløpet. Beregnet fra ordrelinjene basert på skattekonfigurasjonen. Vist på ordren og fakturaen.
14. amount_total
Type: Float. Det totale beløpet inkludert skatt. Hovedbeløpet for fakturering og rapportering.
15. currency_id
Type: Many2one (res.currency). Valutaen. Vanligvis arvet fra selskapet eller prisliste. Alle monetære felt bruker denne valutaen.
16. pricelist_id
Type: Many2one (product.pricelist). Prisliste som brukes for bestillingen. Bestemmer enhetspriser på linjene. Kan settes fra partneren eller manuelt.
17. payment_term_id
Type: Many2one (account.payment.term). Betalingsbetingelser (f.eks. Net 30, 50% forskuddsbetaling). Brukes ved oppretting av fakturaer.
18. fiscal_position_id
Type: Many2one (account.fiscal.position). Den skattemessige posisjonen for skattekartlegging. Brukes når kunden er i et annet land eller har et spesielt skatteregime.
19. client_order_ref
Type: Char. Kundereferanse eller PO-nummer. Brukes når kunden gir sin egen bestillingsreferanse. Vist på dokumenter og i rapporter.
20. origin
Type: Char. Kildedokumentet. For eksempel, når en bestilling opprettes fra en mulighet, lagres mulighetsnavnet her. Brukes for sporbarhet.
21. create_date
Type: Datetime. Lagrer dato og tid når posten ble opprettet. Administreres automatisk av Odoo. Nyttig for rapportering og revisjon.
22. write_date
Type: Datetime. Lagrer dato og tid for den siste modifikasjonen. Også automatisk administrert. Hjelper med å spore når data sist ble oppdatert.
23. note
Type: Text. Vilkår og betingelser eller interne notater. Kan vises på tilbudet og fakturaen. Brukes for juridisk tekst eller spesielle instruksjoner.
24. require_signature
Type: Boolean. Når True, må kunden signere online før bestillingen bekreftes. Brukes for e-handel og portalstrømmer.
25. require_payment
Type: Boolean. Når True, kreves betaling før bekreftelse. Brukes for forskudds- eller depositumbestillinger.
26. invoice_status
Type: Selection. Sporer fakturering: nei (ikke fakturert), til fakturering (klar til fakturering), fakturert (fullt fakturert), eller upsell (tilleggslinjer å fakturere).
27. locked
Type: Boolean. Når True, kan ikke bestillingen endres. Settes automatisk når bestillingen er bekreftet eller når relaterte dokumenter er postet.
28. company_id
Type: Many2one (res.company). I flerbedriftsoppsett indikerer dette hvilken Odoo-bedrift bestillingen tilhører. Påvirker synlighet og tilgang til poster.
29. tag_ids
Type: Many2many (crm.tag). Merker for kategorisering. Brukes til filtrering, rapportering og segmentering. Fleksibel for tilpassede arbeidsflyter.
30. signed_by
Type: Char. Navnet på personen som signerte bestillingen når require_signature er brukt. Lagrer for revisjon.
31. signed_on
Type: Datetime. Dato og klokkeslett for signatur. Brukes når signatur er nødvendig for bekreftelse.
32. prepayment_percent
Type: Float. Prosentandelen av bestillingen som må betales som forskuddsbetaling. Brukes med require_payment for bestillinger basert på depositum.
Hvordan denne modellen brukes i forretningsarbeidsflyter
1. Tilbud til Bestilling
Selgeren oppretter et tilbud (utkast). Legger til linjer, setter priser, sender til kunde. Kunden bekrefter. Bestillingen er bekreftet (status = salg). Fakturaer og leveringsordrer kan opprettes.
2. E-handel og Portal
Kunder legger inn bestillinger på nettstedet. Bestillinger opprettes som sales.order-poster. require_signature og require_payment kan håndheve online betaling eller signatur før bekreftelse.
3. CRM til Salg
Når en mulighet vinnes, opprettes et tilbud fra den. Feltet origin kobler tilbake til muligheten. user_id og team_id driver salgsrapportering og provisjoner.
4. Fakturering
Fra en bekreftet bestilling oppretter brukere fakturaer. Fakturalinjene hentes fra bestillingslinjene. payment_term_id og fiscal_position_id kommer fra bestillingen. invoice_status sporer fremdrift.
5. Levering og Forpliktelse
commitment_date driver leveringsplanlegging. Når den er satt, planlegges leveringsordrer rundt den. partner_shipping_id definerer leveringsadressen.
Hvordan utviklere utvider denne modellen
Utviklere utvider sales.order ved å bruke flere mønstre. Odoo-modellarv er hovedmekanismen.
Modellarv
Bruk _inherit = 'sale.order' for å utvide modellen. Legg til nye Odoo-felt, overstyr metoder eller legg til begrensninger. Den arvede modellen i Odoo holder endringene dine i en egen modul for enkle oppgraderinger.
Legge til Felt
Definer nye Odoo-felt i den arvede modellen din. Bruk riktig felttype: Char, Many2one, Boolean, Integer, Text, Selection. Vurder selskapsavhengige felt for flere selskaper.
Python-utvidelser
Overstyr action_confirm, create eller write for å legge til logikk. Bruk super() for å kalle den originale. Vær forsiktig med beregnede felt og deres avhengigheter.
Odoo Studio
Odoo Studio lar deg legge til felt uten kode. Bra for raske tilpasninger. For kompleks logikk eller oppgraderinger er tilpassede moduler mer vedlikeholdbare.
Beste praksis
- Bruk riktig tilstand for hver fase. Ikke hopp over tilstander eller omgå bekreftelseslogikk.
- Sett commitment_date når kunden har en lovet dato. Det forbedrer leveringsplanlegging.
- Bruk commercial_partner_id når du trenger toppnivåenheten for gruppering (f.eks. for kreditt eller rapportering).
- Når du bygger API-integrasjoner, bruk XML-RPC eller JSON-RPC API. sales.order-modellen er fullt eksponert. Kartlegg eksterne ID-er nøye.
- For tilpassede felt, bruk
x_-prefikset eller et modulprefiks for å unngå konflikter med fremtidige Odoo-versjoner.
Vanlige feil
- Modifisering av bekreftede bestillinger uten å sjekke låst. Låste bestillinger kan ikke redigeres. Opprett en ny revisjon eller bruk riktig arbeidsflyt.
- Blande sammen partner_id, partner_invoice_id og partner_shipping_id. Hver har et distinkt formål. Sett alle tre når adresser er forskjellige.
- Overstyring av action_confirm uten å kalle super(). Dette kan bryte andre moduler eller fremtidige oppgraderinger.
- Legge til nødvendige tilpassede felt uten standardverdier. Eksisterende bestillinger vil feile validering ved oppgradering.
- Glemme å sette pricelist_id når valutaen eller prisene avviker fra standarden. Feil priser kan føre til feil fakturering.
Konklusjon
sales.order-modellen er sentral for Odoo Salg. Den lagrer tilbud og bekreftede bestillinger. Å forstå feltene dens og hvordan moduler utvider den vil hjelpe deg med å konfigurere, tilpasse og integrere Odoo effektivt.
Enten du er en funksjonell konsulent som kartlegger salgsprosesser eller en utvikler som bygger tilpassede moduler, vil en solid forståelse av sales.order spare tid og forhindre feil.
Trenger du hjelp med din Odoo-implementering?
Dasolo hjelper selskaper med å implementere, tilpasse og optimalisere Odoo. Vi spesialiserer oss på API-integrasjoner og Odoo-utvikling. Vårt team har dyp erfaring med Odoo-datastrukturen og modeller som sales.order.
Hvis du trenger hjelp med din Odoo-implementering, tilpassede moduler eller integrasjoner, er vi her for å hjelpe. Bestill en demo for å diskutere prosjektet ditt.