Introduktion
I Odoo definierar modeller hur data struktureras och lagras i databasen. Varje bit affärsdata du arbetar med, från försäljningsorder till fakturor till kontakter, 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 Odoo:s dataarkitektur. De definierar fält, relationer och affärslogik.
Denna artikel fokuserar på en av de viktigaste modellerna i Odoo: sales.order. Oavsett om du bygger anpassade moduler, integrerar externa system eller konfigurerar försäljningsarbetsflöden, kommer du att arbeta med denna modell.
Vad är sales.order-modellen
Modellen sales.order representerar offerter och försäljningsorder i Odoo. Det är den centrala platsen där alla försäljningstransaktioner registreras innan de faktureras eller levereras.
Denna modell i Odoo används av Försäljningsmodulen.
När en försäljare skapar en offert, skapar de en sales.order-post. När kunden bekräftar, flyttas ordern från utkast till bekräftad. Den samma modellen i Odoo håller både utkastsofferter och bekräftade order. Fältet state spårar livscykeln.
Andra moduler utökar denna modell genom Odoo-modellärv. CRM kopplar möjligheter till order. Bokföring lägger till fakturafält. Lager lägger till leverans- och åtagandedatum. Varje modul lägger till vad den behöver utan att duplicera den grundläggande strukturen.
Nyckelfält i modellen
Här är de viktigaste Odoo-fälten i sales.order-modellen. Att förstå dessa kommer att hjälpa dig att arbeta effektivt med offerter och order.
1. name
Typ: Char. Detta fält lagrar orderreferensen eller offertnumret. Det genereras vanligtvis automatiskt (t.ex. S00042) och visas i listvyer och på dokument. Det är den primära identifieraren för ordern.
2. state
Typ: Selection. Spårar orderlivscykeln. Värden: draft (offert), sent (offert skickad till kund), sale (bekräftad order), done (fullständigt levererad och fakturerad), cancel (avbruten). State styr vilka åtgärder som är tillgängliga.
3. partner_id
Typ: Many2one (res.partner). Kunden. Obligatorisk. Detta är den huvudsakliga kontakten eller företaget för ordern. Används för all kundrelaterad logik och rapportering.
4. partner_invoice_id
Typ: Many2one (res.partner). Faktureringsadressen. Om den inte är angiven, används partner_id som standard. Använd detta när faktureringsadressen skiljer sig från huvudkontakten (t.ex. central fakturering).
5. partner_shipping_id
Typ: Many2one (res.partner). Leveransadressen. Om den inte är angiven, används partner_id som standard. Används för leveransorder och fraktberäkningar.
6. user_id
Typ: Many2one (res.users). Säljaren eller ansvarig användare. Används för CRM, provisioner och aktivitetsfördelning. Sätts ofta från säljteamet eller möjligheten.
7. team_id
Typ: Many2one (crm.team). Säljteamet. Grupperar säljare och driver rapportering. Används för teambaserade instrumentpaneler och kvoter.
8. date_order
Typ: Datetime. Orderdatumet. För utkastorder: skapelsedatum. För bekräftade order: bekräftelsedatum. Används för rapportering och sortering.
9. validity_date
Typ: Datum. Utgångsdatumet för offerten. Efter detta datum kan offerten bli ogiltig. Användbart för tidsbegränsade erbjudanden.
10. commitment_date
Typ: Datum och tid. Det lovade leveransdatumet. När det är inställt planeras leveransorder baserat på detta datum snarare än produktens ledtider. Viktigt för kundåtaganden.
11. order_line
Typ: One2many (sale.order.line). Orderraderna. Varje rad innehåller produkt, kvantitet, pris och skatt. Detta är kärndetaljen i beställningen.
12. amount_untaxed
Typ: Float. Delbeloppet före skatt. Beräknas från orderrader. Används för rapportering och visning.
13. amount_tax
Typ: Float. Det totala skattebeloppet. Beräknas från orderrader baserat på skattekonfiguration. Visas på ordern och fakturan.
14. amount_total
Typ: Float. Det totala beloppet inklusive skatt. Huvudbeloppet för fakturering och rapportering.
15. currency_id
Typ: Many2one (res.currency). Valutan. Vanligtvis ärvd från företaget eller prislistan. Alla monetära fält använder denna valuta.
16. pricelist_id
Typ: Many2one (product.pricelist). Prisslistan som används för beställningen. Bestämmer enhetspriser på rader. Kan ställas in från partnern eller manuellt.
17. payment_term_id
Typ: Many2one (account.payment.term). Betalningsvillkor (t.ex. Net 30, 50% förskott). Används vid skapande av fakturor.
18. fiscal_position_id
Typ: Many2one (account.fiscal.position). Den skattemässiga positionen för skattekartläggning. Tillämpas när kunden är i ett annat land eller har ett särskilt skattesystem.
19. client_order_ref
Typ: Char. Kundreferensen eller PO-nummer. Används när kunden tillhandahåller sin egen beställningsreferens. Visas på dokument och i rapporter.
20. origin
Typ: Char. Källdokumentet. Till exempel, när en beställning skapas från en möjlighet, lagras namnet på möjligheten här. Används för spårbarhet.
21. create_date
Typ: Datetime. Lagrar datum och tid när posten skapades. Hanteras automatiskt av Odoo. Användbart för rapportering och revision.
22. write_date
Typ: Datum och tid. Lagrar datum och tid för den senaste ändringen. Hanteras också automatiskt. Hjälper till att spåra när data senast uppdaterades.
23. anteckning
Typ: Text. Villkor och bestämmelser eller interna anteckningar. Kan visas på offert och faktura. Används för juridisk text eller särskilda instruktioner.
24. kräva_signatur
Typ: Boolean. När sant, måste kunden skriva under online innan beställningen bekräftas. Används för e-handel och portalflöden.
25. kräva_betalning
Typ: Boolean. När sant, krävs betalning innan bekräftelse. Används för förbetalda eller depositionsbaserade beställningar.
26. fakturastatus
Typ: Val. Spårar fakturering: nej (inte fakturerad), att fakturera (redo att fakturera), fakturerad (fullständigt fakturerad) eller merförsäljning (ytterligare rader att fakturera).
27. låst
Typ: Boolean. När sant, kan beställningen inte ändras. Ställs in automatiskt när beställningen bekräftas eller när relaterade dokument publiceras.
28. företags_id
Typ: Many2one (res.company). I flerföretagsinställningar anger detta vilken Odoo-företag beställningen tillhör. Påverkar synlighet och åtkomst av poster.
29. tag_ids
Typ: Many2many (crm.tag). Taggar för kategorisering. Används för filtrering, rapportering och segmentering. Flexibel för anpassade arbetsflöden.
30. signed_by
Typ: Char. Namnet på den person som signerade beställningen när require_signature används. Lagrad för revision.
31. signed_on
Typ: Datetime. Datum och tid för signatur. Används när signatur krävs för bekräftelse.
32. prepayment_percent
Typ: Float. Den procentandel av beställningen som måste betalas som förskottsbetalning. Används med require_payment för beställningar baserade på deposition.
Hur denna modell används i affärsarbetsflöden
1. Offert till Beställning
Säljaren skapar en offert (utkast). Lägger till rader, sätter priser, skickar till kund. Kunden bekräftar. Beställningen bekräftas (status = försäljning). Fakturor och leveransorder kan skapas.
2. E-handel och Portal
Kunder lägger beställningar på webbplatsen. Beställningar skapas som sales.order-poster. require_signature och require_payment kan tvinga onlinebetalning eller signatur innan bekräftelse.
3. CRM till Försäljning
När en möjlighet vunnits skapas en offert från den. Ursprungsfältet länkar tillbaka till möjligheten. user_id och team_id driver försäljningsrapportering och provisioner.
4. Fakturering
Från en bekräftad beställning skapar användare fakturor. Fakturalinjer hämtas från beställningslinjer. payment_term_id och fiscal_position_id kommer från beställningen. invoice_status spårar framsteg.
5. Leverans och Åtagande
commitment_date driver leveransschemaläggning. När den är inställd planeras leveransordrar runt den. partner_shipping_id definierar leveransadressen.
Hur utvecklare utökar denna modell
Utvecklare utökar sales.order med flera mönster. Odoo-modellärvning är den huvudsakliga mekanismen.
Modellärvning
Använd _inherit = 'sale.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 behå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
Överskriv action_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.
Bästa praxis
- Använd rätt status för varje steg. Hoppa inte över statusar eller kringgå bekräftelselogik.
- Ställ in commitment_date när kunden har ett lovat datum. Det förbättrar leveransplaneringen.
- Använd commercial_partner_id när du behöver den översta enheten för gruppering (t.ex. för kredit eller rapportering).
- När du bygger API-integrationer, använd XML-RPC eller JSON-RPC API. Modellen sales.order är helt exponerad. Mappa 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 låsta. Låsta beställningar kan inte redigeras. Skapa en ny revision eller använd rätt arbetsflöde.
- Blanda ihop partner_id, partner_invoice_id och partner_shipping_id. Var och en har ett distinkt syfte. Ställ in alla tre när adresserna skiljer sig.
- Överskridande av action_confirm utan att anropa 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 valideringen vid uppgradering.
- Att glömma att ställa in pricelist_id när valutan eller prissättningen skiljer sig från standarden. Felaktiga priser kan leda till felaktig fakturering.
Slutsats
Modellen sales.order är central för Odoo Sales. Den lagrar offerter och bekräftade beställningar. Att förstå dess 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 försäljningsprocesser eller en utvecklare som bygger anpassade moduler, kommer en solid förståelse av sales.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 sales.order.
Om du behöver hjälp med din Odoo-implementering, anpassade moduler eller integrationer, är vi här för att hjälpa till. Boka en demo för att diskutera ditt projekt.