Introduktion
I Odoo definerer modeller, hvordan data er struktureret og gemt i databasen. Hver enkelt del af forretningsdata, du arbejder med, fra indkøbsordrer til fakturaer til lager, findes i en model.
At forstå Odoo-modeller er essentielt for både udviklere og funktionelle konsulenter. Modellerne er fundamentet for Odoo's dataarkitektur. De definerer Odoo-felter, relationer og forretningslogik.
Denne artikel fokuserer på en af de vigtigste modeller i Odoo: purchase.order. Uanset om du bygger brugerdefinerede moduler, integrerer eksterne systemer eller konfigurerer indkøbsarbejdsgange, vil du arbejde med denne model.
Hvad er purchase.order-modellen
Modellen purchase.order repræsenterer indkøbsordrer og anmodninger om tilbud (RFQ'er) i Odoo. Det er det centrale sted, hvor alle indkøbstransaktioner registreres, før de bliver modtagelser eller leverandørfakturaer.
Denne model i Odoo bruges af Indkøbsmodulet. Når en køber opretter en RFQ, opretter de en purchase.order-post. Når leverandøren bekræfter, eller køberen godkender, flytter ordren fra kladde til bekræftet. Den samme model i Odoo indeholder både kladde RFQ'er og bekræftede indkøbsordrer. Feltet state sporer livscyklussen.
Andre moduler udvider denne model gennem Odoo-modelarv. Lager tilføjer modtagelses- og plukningslogik. Regnskab tilføjer felter til leverandørfakturaer. Produktion kan oprette indkøbsordrer fra materialelister. Hvert modul tilføjer, hvad det har brug for, uden at duplikere den grundlæggende struktur.
Nøglefelter i modellen
Her er de vigtigste Odoo-felter i purchase.order-modellen. At forstå disse vil hjælpe dig med at arbejde effektivt med indkøbsordrer.
1. name
Type: Char. Dette felt gemmer ordrenummeret (f.eks. PO00042). Det genereres typisk automatisk og vises i listevisninger og på dokumenter. Det er den primære identifikator for indkøbsordren.
2. state
Type: Selection. Sporer ordres livscyklus. Værdier: draft (RFQ), sent (sendt til leverandør), to approve (afventer godkendelse), purchase (bekræftet), done (fuldt modtaget og faktureret), cancel (annulleret). State bestemmer, hvilke handlinger der er tilgængelige.
3. partner_id
Type: Many2one (res.partner). Leverandøren eller udbyderen. Påkrævet. Dette er den primære kontakt eller virksomhed for ordren. Bruges til al leverandørrelateret logik og rapportering.
4. partner_ref
Type: Char. Leverandørreferencen eller udbyderens PO-nummer. Bruges, når leverandøren giver deres egen ordrefreference. Vist på dokumenter og hjælper med at matche modtagelser og fakturaer.
5. date_order
Type: Datetime. Ordredatoen. For udkastordrer: oprettelsesdato. For bekræftede ordrer: bekræftelsesdato. Bruges til rapportering, sortering og som den standard forventede dato for ordrelinjer.
6. date_approve
Type: Datetime. Godkendelses- eller bekræftelsesdato. Indstillet når ordren bevæger sig til købtilstand. Skrivbeskyttet. Bruges til rapportering og revisionsspor.
7. order_line
Type: One2many (purchase.order.line). Ordrelinjerne. Hver linje indeholder produkt, mængde, pris og skat. Dette er de centrale detaljer i indkøbsordren.
8. amount_untaxed
Type: Float. Delbeløbet før skat. Beregnet ud fra ordrelinjer. Bruges til rapportering og visning.
9. amount_tax
Type: Float. Det samlede skattebeløb. Beregnet ud fra ordrelinjer baseret på skattekonfiguration. Vist på ordren og leverandørfakturaen.
10. amount_total
Type: Float. Det samlede beløb inklusive skat. Det primære beløb til fakturering og rapportering.
11. currency_id
Type: Many2one (res.currency). Valutaen. Normalt arvet fra virksomheden eller leverandøren. Alle monetære felter bruger denne valuta.
12. origin
Type: Char. Kildedokumentet. For eksempel, når en ordre oprettes fra en salgsordre (dropship) eller produktionsordre, gemmes kildens navn her. Bruges til sporbarhed.
13. dest_address_id
Type: Many2one (res.partner). Leveringsadressen. Hvis ikke angivet, default til virksomhedens adresse. Bruges til dropshipping, når varer går direkte til kunden.
14. priority
Type: Selection. Ordreprioritet: Normal eller Hastende. Bruges til sortering og fremhævning. Hastende ordrer kan få særlig behandling i arbejdsgange.
15. invoice_status
Type: Selection. Spor fakturering: nej (ikke faktureret), til fakturering (klar til fakturering), faktureret (fuldt faktureret). Styrer synligheden af handlingen Opret faktura.
16. invoice_count
Type: Integer. Antal relaterede leverandørfakturaer. Beregnet. Bruges til visning og til at åbne listen over fakturaer.
17. invoice_ids
Type: One2many (account.move). De relaterede leverandørfakturaer. Links indkøbsordrer til regnskab. Bruges til trevejsafstemning og betalingssporing.
18. picking_ids
Type: One2many (stock.picking). De relaterede leveringsordrer eller kvitteringer. Bruges når indkøbsmodulet er installeret med lager.
19. picking_count
Type: Integer. Antal relaterede picking. Beregnet. Bruges til visning og til at åbne listen over kvitteringer.
20. create_date
Type: Datetime. Gemmer datoen og tidspunktet for, hvornår posten blev oprettet. Administreres automatisk af Odoo. Nyttig til rapportering og revision.
21. write_date
Type: Datetime. Gemmer datoen og tidspunktet for den sidste ændring. Også administreret automatisk. Hjælper med at spore, hvornår data sidst blev opdateret.
22. notes
Type: Text. Vilkår og betingelser eller interne noter. Kan vises på indkøbsordren. Bruges til særlige instruktioner til leverandøren.
23. company_id
Type: Many2one (res.company). I multi-company opsætninger angiver dette, hvilken Odoo virksomhed ordren tilhører. Påvirker synlighed og adgang til poster.
24. user_id
Type: Many2one (res.users). Køberen eller den ansvarlige bruger. Bruges til godkendelsesarbejdsgange og aktivitetsfordeling.
25. fiscal_position_id
Type: Many2one (account.fiscal.position). Den skattemæssige position til skattekortlægning. Anvendes, når leverandøren er i et andet land eller har et særligt skatteordning.
26. payment_term_id
Type: Many2one (account.payment.term). Betalingsbetingelser (f.eks. Net 30, 50% forudbetaling). Bruges ved oprettelse af leverandørfakturaer.
27. display_name
Type: Char. Beregnet visningsnavn. Kombinerer navn med leverandørinformation. Bruges i many2one dropdowns og søgeresultater. Skrivbeskyttet.
28. active
Type: Boolean. Blød slette flag. Når False, arkiveres posten og skjules fra standardvisninger. Indkøbsordrer slettes ikke fysisk for at bevare historik.
Hvordan denne model bruges i forretningsarbejdsgange
1. RFQ til Indkøbsordre
Køberen opretter en anmodning om tilbud (udkast). Tilføjer linjer, sender til leverandør. Leverandøren bekræfter, eller køberen bekræfter manuelt. Ordren er bekræftet (status = køb). Modtagelser og leverandørregninger kan oprettes.
2. Leverandørmodtagelse
Når varerne ankommer, opretter brugeren en modtagelse fra indkøbsordren. picking_ids er knyttet. Modtagne mængder opdaterer lageret. Produktomkostninger opdateres fra købsprisen.
3. Leverandørregning
Fra en bekræftet ordre opretter brugerne leverandørregninger. Fakturalinjer trækkes fra ordrelinjer. payment_term_id og fiscal_position_id kommer fra ordren. invoice_status sporer fremskridt.
4. Dropshipping
Når en salgsordre udløser et køb, linker oprindelsen tilbage til salget. dest_address_id sættes til kundeadressen, så leverandøren kan sende direkte. purchase.order-modellen er broen mellem salg og indkøb.
5. Fremstilling og MRP
Når en fremstillingsordre har brug for komponenter, kan den oprette indkøbsordrer for råmaterialer. Oprindelsesfeltet linker til fremstillingsordren. Denne model er central for procure-to-pay-cyklussen.
Hvordan udviklere udvider denne model
Udviklere udvider purchase.order ved hjælp af flere mønstre. Odoo-modelarv er den primære mekanisme.
Modelarv
Brug _inherit = 'purchase.order' for at udvide modellen. Tilføj nye Odoo-felter, overskriv metoder eller tilføj begrænsninger. Den arvede model i Odoo holder dine ændringer i en separat modul for nemme opgraderinger.
Tilføjelse af felter
Definer nye Odoo-felter i din arvede model. Brug den rigtige felttype: Char, Many2one, Boolean, Integer, Text, Selection. Overvej virksomhedafhængige felter til multi-virksomhed.
Python-udvidelser
Overskriv button_confirm, create eller write for at tilføje logik. Brug super() til at kalde den oprindelige. Vær forsigtig med beregnede felter og deres afhængigheder.
Odoo Studio
Odoo Studio giver dig mulighed for at tilføje felter uden kode. Godt til hurtige tilpasninger. For kompleks logik eller opgraderinger er tilpassede moduler mere vedligeholdelige. API-modellen i Odoo (purchase.order) er fuldt eksponeret via XML-RPC og JSON-RPC til integrationer.
Bedste praksis
- Brug den korrekte tilstand for hver fase. Spring ikke tilstande over eller omgå bekræftelseslogik.
- Sæt partner_ref, når leverandøren giver en reference. Det hjælper med at matche modtagelser og regninger.
- Brug origin til at spore kilden til indkøbsordrer. Væsentligt for dropshipping og fremstilling.
- Når du bygger API-integrationer, brug XML-RPC eller JSON-RPC API'en. purchase.order-modellen er fuldt eksponeret. Kortlæg eksterne ID'er omhyggeligt.
- For tilpassede felter, brug
x_præfikset eller et modulpræfiks for at undgå konflikter med fremtidige Odoo-versioner.
Almindelige fejl
- Ændring af bekræftede ordrer uden at tjekke status. Bekræftede ordrer har begrænsede felter. Opret en ny ordre eller brug den rette arbejdsgang.
- Forveksling af partner_id og dest_address_id. partner_id er leverandøren; dest_address_id er, hvor varerne skal sendes hen (til dropshipping).
- Overskrivning af button_confirm uden at kalde super(). Dette kan bryde andre moduler eller fremtidige opgraderinger.
- Tilføjelse af nødvendige tilpassede felter uden standardværdier. Eksisterende ordrer vil fejle validering ved opgradering.
- Glemme at indstille currency_id, når man arbejder med multi-valuta leverandører. Forkert valuta kan føre til forkerte omkostninger og fakturering.
Konklusion
purchase.order modellen er central for Odoo Purchase. Den gemmer RFQ'er og bekræftede indkøbsordrer. At forstå dens Odoo-felter og hvordan moduler udvider den vil hjælpe dig med at konfigurere, tilpasse og integrere Odoo effektivt.
Uanset om du er en funktionel konsulent, der kortlægger indkøbsprocesser, eller en udvikler, der bygger tilpassede moduler, vil en solid forståelse af purchase.order spare tid og forhindre fejl.
Har du brug for hjælp med din Odoo-implementering?
Dasolo hjælper virksomheder med at implementere, tilpasse og optimere Odoo. Vi specialiserer os i API-integrationer og Odoo-udvikling. Vores team har dyb erfaring med Odoo-dataarkitekturen og modeller som purchase.order.
Hvis du har brug for hjælp til din Odoo-implementering, tilpassede moduler eller integrationer, er vi her for at hjælpe. Book en demo for at diskutere dit projekt.