Introduktion
I Odoo definierar modeller hur data struktureras och lagras i databasen. Varje bit affärsdata du arbetar med, från inköpsorder till fakturor till lager, finns i en modell.
Att förstå Odoo-modeller är avgörande för både utvecklare och funktionella konsulter. Modeller är grunden för Odoos dataarkitektur. De definierar Odoo-fält, relationer och affärslogik.
Denna artikel fokuserar på en av de viktigaste modellerna i Odoo: purchase.order. Oavsett om du bygger anpassade moduler, integrerar externa system eller konfigurerar upphandlingsarbetsflöden, kommer du att arbeta med denna modell.
Vad är purchase.order-modellen
Modellen purchase.order representerar inköpsorder och förfrågningar om offert (RFQ) i Odoo. Det är den centrala platsen där alla upphandlingstransaktioner registreras innan de blir mottagningar eller leverantörsfakturor.
Denna modell i Odoo används av Inköpsmodulen. När en köpare skapar en RFQ, skapar de en purchase.order-post. När leverantören bekräftar eller köparen godkänner, flyttas ordern från utkast till bekräftad. Den samma modellen i Odoo håller både utkast RFQ:er och bekräftade inköpsorder. Fältet state spårar livscykeln.
Andra moduler utökar denna modell genom Odoo-modellärvande. Lager lägger till mottagnings- och plocklogik. Redovisning lägger till fält för leverantörsfakturor. Tillverkning kan skapa inköpsorder från materiallistor. Varje modul lägger till vad den behöver utan att duplicera den centrala strukturen.
Nyckelfält i modellen
Här är de viktigaste Odoo-fälten i purchase.order-modellen. Att förstå dessa kommer att hjälpa dig att arbeta effektivt med inköpsorder.
1. name
Typ: Char. Detta fält lagrar orderreferensen (t.ex. PO00042). Det genereras vanligtvis automatiskt och visas i listvyer och på dokument. Det är den primära identifieraren för inköpsordern.
2. state
Typ: Selection. Spårar orderlivscykeln. Värden: draft (RFQ), sent (skickat till leverantör), to approve (väntar på godkännande), purchase (bekräftad), done (fullständigt mottagen och fakturerad), cancel (avbruten). State driver vilka åtgärder som är tillgängliga.
3. partner_id
Typ: Many2one (res.partner). Leverantören eller försäljaren. Obligatorisk. Detta är den huvudsakliga kontakten eller företaget för ordern. Används för all leverantörsrelaterad logik och rapportering.
4. partner_ref
Typ: Char. Leverantörens referens eller beställningsnummer. Används när leverantören tillhandahåller sin egen orderreferens. Visas på dokument och hjälper till att matcha mottagningar och fakturor.
5. date_order
Typ: Datum och tid. Beställningsdatum. För utkastbeställningar: skapelsedatum. För bekräftade beställningar: bekräftelsedatum. Används för rapportering, sortering och som det förväntade standarddatumet för beställningsrader.
6. date_approve
Typ: Datum och tid. Godkännande- eller bekräftelsedatum. Ställs in när beställningen går till inköpsstatus. Endast för läsning. Används för rapportering och revisionsspår.
7. order_line
Typ: One2many (purchase.order.line). Beställningsraderna. Varje rad innehåller produkt, kvantitet, pris och skatt. Detta är kärndetaljen i inköpsordern.
8. amount_untaxed
Typ: Float. Delbelopp före skatt. Beräknas från beställningsrader. Används för rapportering och visning.
9. amount_tax
Typ: Float. Det totala skattebeloppet. Beräknas från beställningsrader baserat på skattekonfiguration. Visas på beställningen och leverantörsfakturan.
10. amount_total
Typ: Float. Det totala beloppet inklusive skatt. Huvudbeloppet för fakturering och rapportering.
11. currency_id
Typ: Many2one (res.currency). Valutan. Vanligtvis ärvts från företaget eller leverantören. Alla monetära fält använder denna valuta.
12. origin
Typ: Char. Källdokumentet. Till exempel, när en beställning skapas från en försäljningsorder (dropship) eller tillverkningsorder, lagras källnamnet här. Används för spårbarhet.
13. dest_address_id
Typ: Many2one (res.partner). Leveransadressen. Om den inte är inställd, standardinställs den till företagsadressen. Används för dropshipping när varor går direkt till kunden.
14. priority
Typ: Val. Beställningsprioritet: Normal eller Brådskande. Används för sortering och framhävning. Brådskande beställningar kan få särskild hantering i arbetsflöden.
15. invoice_status
Typ: Val. Spårar fakturering: nej (inte fakturerad), att fakturera (redo att fakturera), fakturerad (fullständigt fakturerad). Styr synligheten för åtgärden Skapa faktura.
16. invoice_count
Typ: Heltal. Antal relaterade leverantörsfakturor. Beräknad. Används för visning och för att öppna listan över fakturor.
17. invoice_ids
Typ: One2many (account.move). De relaterade leverantörsfakturorna. Kopplar inköpsordrar till bokföring. Används för trevägsavstämning och betalningsspårning.
18. picking_ids
Typ: One2many (stock.picking). De relaterade leveransordrarna eller kvittona. Används när inköpsmodulen är installerad med lager.
19. picking_count
Typ: Heltal. Antal relaterade plockningar. Beräknad. Används för visning och för att öppna listan över kvitton.
20. create_date
Typ: Datum och tid. Lagrar datum och tid när posten skapades. Hanteras automatiskt av Odoo. Användbar för rapportering och revision.
21. write_date
Typ: Datum och tid. Lagrar datum och tid för den senaste ändringen. Också automatiskt hanterad. Hjälper till att spåra när data senast uppdaterades.
22. notes
Typ: Text. Villkor eller interna anteckningar. Kan visas på inköpsordern. Används för särskilda instruktioner till leverantören.
23. company_id
Typ: Many2one (res.company). I flerföretagsinställningar indikerar detta vilken Odoo-företag beställningen tillhör. Påverkar synlighet och åtkomst av poster.
24. user_id
Typ: Many2one (res.users). Köparen eller ansvarig användare. Används för godkännandearbetsflöden och aktivitetsuppdrag.
25. fiscal_position_id
Typ: Many2one (account.fiscal.position). Den skattemässiga positionen för skattekartläggning. Tillämpas när leverantören är i ett annat land eller har en speciell skatteregim.
26. payment_term_id
Typ: Many2one (account.payment.term). Betalningsvillkor (t.ex. Net 30, 50% förskott). Används vid skapande av leverantörsfakturor.
27. display_name
Typ: Char. Beräknat visningsnamn. Kombinerar namn med leverantörsinformation. Används i many2one-rullgardinsmenyer och sökresultat. Endast läsbar.
28. active
Typ: Boolean. Mjuk raderingsflagga. När den är False arkiveras posten och döljs från standardvyer. Inköpsorder raderas inte fysiskt för att bevara historik.
Hur denna modell används i affärsarbetsflöden
1. RFQ till inköpsorder
Köparen skapar en begäran om offert (utkast). Lägger till rader, skickar till leverantör. Leverantören bekräftar eller köparen bekräftar manuellt. Beställningen bekräftas (status = inköp). Kvitteringar och leverantörsfakturor kan skapas.
2. Leverantörskvittering
När varorna anländer skapar användaren en kvittering från inköpsordern. picking_ids är länkade. Mottagna kvantiteter uppdaterar lagret. Produktkostnader uppdateras från inköpspriset.
3. Leverantörsfaktura
Från en bekräftad beställning skapar användare leverantörsfakturor. Fakturarader hämtas från beställningsrader. payment_term_id och fiscal_position_id kommer från beställningen. invoice_status spårar framsteg.
4. Dropshipping
När en försäljningsorder utlöser ett köp, länkas ursprunget tillbaka till försäljningen. dest_address_id sätts till kundens adress så att leverantören skickar direkt. purchase.order-modellen är bron mellan försäljning och upphandling.
5. Tillverkning och MRP
När en tillverkningsorder behöver komponenter kan den skapa inköpsorder för råvaror. Ursprungsfältet länkar till tillverkningsordern. Denna modell är central för procure-to-pay-cykeln.
Hur utvecklare utökar denna modell
Utvecklare utökar purchase.order med flera mönster. Odoo-modellärv är den huvudsakliga mekanismen.
Modellärv
Använd _inherit = 'purchase.order' för att utöka modellen. Lägg till nya Odoo-fält, åsidosätt metoder eller lägg till begränsningar. Den ärvda modellen i Odoo håller dina ändringar i en separat modul för enkla uppgraderingar.
Lägga till fält
Definiera nya Odoo-fält i din ärvda modell. Använd rätt fälttyp: Char, Many2one, Boolean, Integer, Text, Selection. Tänk på företagsberoende fält för flera företag.
Python-tillägg
Åsidosätt button_confirm, create eller write för att lägga till logik. Använd super() för att anropa den ursprungliga. Var försiktig med beräknade fält och deras beroenden.
Odoo Studio
Odoo Studio låter dig lägga till fält utan kod. Bra för snabba anpassningar. För komplex logik eller uppgraderingar är anpassade moduler mer underhållbara. API-modellen i Odoo (purchase.order) är helt exponerad via XML-RPC och JSON-RPC för integrationer.
Bästa praxis
- Använd rätt tillstånd för varje steg. Hoppa inte över tillstånd eller kringgå bekräftelselogi.
- Ställ in partner_ref när leverantören tillhandahåller en referens. Det hjälper till att matcha mottagningar och fakturor.
- Använd origin för att spåra källan till inköpsorder. Viktigt för dropshipping och tillverkning.
- När du bygger API-integrationer, använd XML-RPC eller JSON-RPC API. purchase.order-modellen är helt exponerad. Karta externa ID:n noggrant.
- För anpassade fält, använd
x_-prefixet eller ett modulprefix för att undvika konflikter med framtida Odoo-versioner.
Vanliga misstag
- Ändra bekräftade beställningar utan att kontrollera status. Bekräftade beställningar har begränsade fält. Skapa en ny beställning eller använd rätt arbetsflöde.
- Blanda ihop partner_id och dest_address_id. partner_id är leverantören; dest_address_id är dit varorna går (för dropshipping).
- Överskrida button_confirm utan att kalla super(). Detta kan bryta andra moduler eller framtida uppgraderingar.
- Lägga till nödvändiga anpassade fält utan standardvärden. Befintliga beställningar kommer att misslyckas med validering vid uppgradering.
- Glömma att ställa in currency_id när man hanterar flervaluta-leverantörer. Fel valuta kan leda till felaktiga kostnader och fakturering.
Slutsats
Modellen purchase.order är central för Odoo Purchase. Den lagrar RFQ:er och bekräftade inköpsbeställningar. Att förstå dess Odoo-fält och hur moduler utökar den kommer att hjälpa dig att konfigurera, anpassa och integrera Odoo effektivt.
Oavsett om du är en funktionell konsult som kartlägger upphandlingsprocesser eller en utvecklare som bygger anpassade moduler, kommer en solid förståelse av purchase.order att spara tid och förhindra fel.
Behöver du hjälp med din Odoo-implementering?
Dasolo hjälper företag att implementera, anpassa och optimera Odoo. Vi specialiserar oss på API-integrationer och Odoo-utveckling. Vårt team har djup erfarenhet av Odoo:s dataarkitektur och modeller som purchase.order.
Om du behöver hjälp med din Odoo-implementation, anpassade moduler eller integrationer, är vi här för att hjälpa till. Boka en demo för att diskutera ditt projekt.