Inledning
I Odoo beskriver en modell hur information organiseras i databasen. All affärsdata — från beställningar och fakturor till lagersaldon — lagras i modeller som bestämmer vilka fält som finns och hur poster länkas ihop.
Att förstå modeller är viktigt både för utvecklare och funktionella konsulter. Modellerna utgör grundstrukturen i Odoo: de definierar fälten, relationerna mellan poster och var affärslogiken bor.
I den här genomgången fokuserar vi på en kärnmodell i Odoo: purchase.order. Oavsett om du bygger skräddarsydd funktionalitet, kopplar ihop system eller konfigurerar inköpsprocesser kommer du ofta att möta och behöva förstå denna modell.
Vad är modellen purchase.order?
purchase.order representerar inköpsordrar och förfrågningar om offert (RFQ) i systemet. Här fångas beställningsinformation innan den blir materialmottagningar eller leverantörsfakturor — modellen är inköpsprocessens nav.
Modellen används av Inköpsmodulen. En köpare skapar en RFQ som blir en purchase.order-post; när leverantören bekräftar eller köparen godkänner flyttas posten från utkast till bekräftad. Samma modell hanterar både utkast och slutliga beställningar, och fältet state speglar var i livscykeln posten befinner sig.
Andra moduler bygger på modellen genom Odoos arvsmekanismer. Lager lägger till mottagningslogik, redovisningen kopplar fakturafält och Produktion kan starta beställningar från stycklistor. Varje modul lägger till sin funktionalitet utan att duplicera grundstrukturen.
Viktiga fält i modellen
Här följer översikten över de viktigaste fälten i purchase.order. Kännedom om dessa gör det lättare att konfigurera, integrera och felsöka inköpsflöden.
1. name
Typ: Char. Referensen för beställningen (t.ex. PO00042). Vanligtvis autogenereras den och används som primär visuell identifierare i listor och dokument.
2. state
Typ: Selection. Beskriver orderns status genom livscykeln: draft (RFQ), sent, to approve, purchase (bekräftad), done (mottaget/fakturerat) och cancel. Statusen styr tillgängliga knappar och rutiners beteende.
3. partner_id
Typ: Many2one (res.partner). Leverantören. Obligatoriskt. Används för leverantörsspecifika villkor, kontaktuppgifter och rapportering.
4. partner_ref
Typ: Char. Leverantörens eget referensnummer eller deras PO-nummer. Hjälper till vid avstämning mellan order, följesedlar och fakturor.
5. date_order
Typ: Datetime. Orderdatum — i utkast vanligtvis skapelsedatum, i bekräftat läge bekräftelsedatum. Används i rapporter och som grund för leveransförväntningar.
6. date_approve
Typ: Datetime. Tidpunkt för bekräftelse/godkännande. Sätts när ordern går till purchase. Läs-skyddat och viktigt för revisionsspår.
7. order_line
Typ: One2many (purchase.order.line). Orderraderna där varje rad anger produkt, mängd, pris och skatt. Här finns detaljerna som styr mottagningar och fakturering.
8. amount_untaxed
Typ: Float. Delbelopp utan skatt. Beräknas från orderrader och används i summeringar och presentationer.
9. amount_tax
Typ: Float. Total skatt på ordern. Beräknas från radernas skatteinställningar och visas även på leverantörsfakturan.
10. amount_total
Typ: Float. Slutbelopp inklusive skatt. Används för fakturering, betalning och rapportering.
11. currency_id
Typ: Many2one (res.currency). Valutan för transaktionen. Vanligen är detta företagets eller leverantörens valuta och påverkar alla beloppsfält.
12. origin
Typ: Char. Pekar på källdokumentet — till exempel en försäljningsorder eller ett produktionsorder som skapade inköpet. Viktigt för spårbarhet i leveranskedjan.
13. dest_address_id
Typ: Many2one (res.partner). Leveransadress. Standard är företagsadressen men kan sättas till kundadress vid dropship, så varorna skickas direkt från leverantör till kund.
14. priority
Typ: Selection. Prioritet i beställningen: Normal eller Brådskande. Används för att sortera och uppmärksamma kritiska leveranser i arbetsflöden.
15. invoice_status
Typ: Selection. Visar faktureringsstatus: no, to invoice eller invoiced. Påverkar synligheten för åtgärder som Skapa faktura.
16. invoice_count
Typ: Integer. Antal kopplade leverantörsfakturor. Beräknas automatiskt och används i gränssnittet för att öppna fakturor.
17. invoice_ids
Typ: One2many (account.move). Länkar till leverantörsfakturor. Viktigt för avstämning och betalningsspårning.
18. picking_ids
Typ: One2many (stock.picking). Kopplade mottagningar eller leveranser. Aktiveras när Lagermodulen används och länkar inköp till fysiska rörelser.
19. picking_count
Typ: Integer. Antal relaterade plock/mottagningar. Beräknas och visas för snabb åtkomst till mottagningsdokument.
20. create_date
Typ: Datetime. Tidpunkten då posten skapades. Hanteras automatiskt och är användbar för rapporter och revision.
21. write_date
Typ: Datetime. Tidpunkten för senaste ändring. Hjälper till att se när innehållet uppdaterades senast.
22. notes
Typ: Text. Fält för villkor eller interna anmärkningar. Visas på beställningen vid behov och kan innehålla instruktioner till leverantören.
23. company_id
Typ: Many2one (res.company). Anger vilken koncern/enhet beställningen hör till i multibolagsmiljöer. Påverkar åtkomstregler och bokföring.
24. user_id
Typ: Many2one (res.users). Ansvarig köpare eller användare. Används i attestflöden och för att tilldela uppgifter och aktiviteter.
25. fiscal_position_id
Typ: Many2one (account.fiscal.position). Skatteposition för momsavstämning vid internationella leverantörer eller särskilda skatteregler.
26. payment_term_id
Typ: Many2one (account.payment.term). Betalningsvillkor som Netto 30 eller förskottsbetalning. Används när fakturor skapas.
27. display_name
Typ: Char. Beräknat visningsnamn som ofta kombinerar referens och leverantör. Används i sökfält och relationer som en läsbar etikett.
28. active
Typ: Boolean. Mjukarkiveringsflagga. När False blir posten dold i standardvyer — poster tas sällan bort helt för att bevara historik.
Hur modellen används i affärsflöden
1. Från RFQ till bekräftad beställning
Köparen skapar en RFQ i utkast, lägger till rader och skickar till leverantör. När leverantören bekräftar eller köparen manuellt godkänner förändras state till purchase och ordern kan ligga till grund för mottagningar och fakturor.
2. Mottagning från leverantör
När varorna anländer skapas en mottagning kopplad till ordern. Plock/detaljer syns i picking_ids, mottagna kvantiteter uppdaterar lagersaldon och inköpspriset kan användas för värdering av lager.
3. Leverantörsfaktura
Från en bekräftad order skapas leverantörsfakturor där fakturaraderna hämtas från orderraderna. Betalningsvillkor och skattepositioner följer med från ordern, och invoice_status visar hur långt faktureringen kommit.
4. Dropshipping
Vid dropship skapas inköp från en försäljningsorder och origin pekar tillbaka till försäljningen. dest_address_id sätts till kundens adress så leverantören skickar direkt till slutkund — purchase.order binder ihop försäljning och inköp.
5. Produktion och MRP
När produktionen behöver komponenter kan den skapa inköpsorder för råvaror. Origin länkar till produktionsordern och modellen är en central del i procure-to-pay-processen.
Hur utvecklare bygger vidare på modellen
Utvecklare bygger ut purchase.order med Odoos ärvningsmönster och flera vanliga tillvägagångssätt.
Model inheritance (modellärv)
Genom att ange _inherit = 'purchase.order' kan du lägga till fält, skriva om metoder eller lägga in begränsningar. Denna strategi håller dina ändringar i separata moduler, vilket underlättar uppgraderingar.
Lägga till fält
Definiera nya fält med lämplig typ: Char, Many2one, Boolean, Integer, Text eller Selection. Tänk på företagsberoende fält i multibolagsmiljöer så att data tolkas rätt per bolag.
Python-utvidgningar
Skriv om metoder som button_confirm, create eller write för att infoga affärslogik. Anropa super() där det behövs och var noga med beroenden i beräknade fält så att allt uppdateras korrekt.
Odoo Studio
Odoo Studio gör det möjligt att lägga till fält utan kod — snabbt för ad-hoc-ändringar. För mer komplexa krav eller långsiktiga lösningar är custom-moduler bättre ur underhållsperspektiv. purchase.order är också åtkomlig via XML-RPC/JSON-RPC för systemintegrationer.
Rekommenderade arbetssätt
- Använd rätt status i rätt skede och hoppa inte över bekräftelsesteg; det kan påverka automatiserade flöden och rättigheter.
- Spara leverantörens egna referenser i partner_ref för enklare avstämning mellan order, leverans och faktura.
- Fyll alltid i origin när beställningen härrör från en annan transaktion — det gör spårbarheten mellan försäljning, produktion och inköp betydligt enklare.
- Vid API-integrationer använd XML-RPC eller JSON-RPC och hantera externa ID:n konsekvent så att poster matchas korrekt mot purchase.order.
- Vid tilläggsfält: använd x_-prefix eller modulprefix för att undvika namnkonflikter vid framtida Odoo-uppgraderingar.
Vanliga misstag
- Modifiera inte bekräftade order utan att kontrollera status — många fält låses när ordern är i purchase-läge och ändringar bör ske via korrekt arbetsflöde.
- Förväxla inte partner_id (leverantör) med dest_address_id (leveransadress). I dropship-scenarion är det avgörande att båda är korrekt satta.
- Att skriva om button_confirm utan att anropa super() kan bryta integrationer och framtida modulers funktionalitet.
- Lägg inte till obligatoriska fält utan att sätta rimliga standardvärden — annars kan befintliga poster misslyckas vid uppgradering eller migrering.
- Glöm inte valutainställningen när du hanterar leverantörer i flera valutor; fel valuta ger fel kostnadsberäkningar och felaktiga fakturor.
Sammanfattning
purchase.order är navet i Odoos inköpsfunktionalitet. Den lagrar både RFQ och slutliga köporder, och förståelsen för dess fält och hur andra moduler bygger på den är avgörande för att konfigurera och integrera systemet korrekt.
Oavsett om du kartlägger inköpsprocesser som konsult eller bygger anpassade moduler som utvecklare, sparar god kunskap om purchase.order tid och minskar risken för fel.
Behöver du hjälp med din Odoo-implementering?
Dasolo hjälper företag att införa, anpassa och optimera Odoo-lösningar. Vi har särskild kompetens inom API-integrationer och anpassad utveckling med djup erfarenhet av Odoos datamodeller som purchase.order.
Behöver du stöd med implementation, skräddarsytt utvecklingsarbete eller integrationer i Odoo? Vi kan hjälpa till. Boka en demo för att diskutera ditt projekt.