Inleiding
In Odoo bepalen modellen de structuur en opslag van je bedrijfsgegevens. Alles wat je in je dagelijkse processen gebruikt — offertes, bestellingen, facturen, contacten — wordt in een model georganiseerd zodat het veilig en vindbaar in de database staat.
Kennis van Odoo-modellen is onmisbaar voor zowel functionele consultants als ontwikkelaars. Modellen leggen de velden, relaties en de bedrijfslogica vast en vormen daarmee het fundament van je Odoo-architectuur.
Dit artikel zoomt in op één van de kernmodellen van Odoo: sales.order. Of je nu maatwerk bouwt, koppelingen ontwikkelt of verkoopflows instelt — je komt vroeg of laat met dit model in aanraking.
Wat is het sales.order-model
Het sales.order-model houdt offertes en verkooporders bij. Het is het centrale dossier waarin alle verkooptransacties worden vastgelegd tot ze gefactureerd of geleverd zijn.
Dit model wordt gebruikt binnen de Sales-app van Odoo.
Een verkoper start meestal met een offerte (concept). Zodra de klant bevestigt, verandert het record van concept naar bevestigd. Zowel conceptoffertes als bevestigde orders leven in hetzelfde model; het veld voor de status bewaakt de levenscyclus.
Andere apps breiden dit standaardmodel uit via Odoo-inheritance. Zo koppelt CRM kansen aan orders, boekhouding voegt factuurinformatie toe en voorraad regelt leveringsdata — elk voegt enkel wat nodig is zonder het basisontwerp te dupliceren.
Belangrijke velden in het model
Onderstaand vind je de belangrijkste velden binnen sales.order. Wie deze begrijpt, kan offertes en orders betrouwbaarder beheren en koppelen aan andere processen.
1. name
Type: Char. Bewaart het order- of offertenummer (vaak automatisch gegenereerd, bv. S00042). Dit is de herkenbare referentie die in lijsten en documenten verschijnt.
2. state
Type: Selection. Houdt de status bij: draft (concept), sent (verzonden), sale (bevestigd), done (afgehandeld), cancel (geannuleerd). De status bepaalt welke acties beschikbaar zijn.
3. partner_id
Type: Many2one (res.partner). De klant (contact of bedrijf). Verplicht. Dit is het primaire klantrecord dat gebruikt wordt voor facturatie, communicatie en rapportage.
4. partner_invoice_id
Type: Many2one (res.partner). Factuuradres. Standaard gelijk aan partner_id tenzij een apart factuuradres nodig is (bijvoorbeeld centrale facturatie).
5. partner_shipping_id
Type: Many2one (res.partner). Leveringsadres. Standaard partner_id tenzij een apart afleveradres moet worden gebruikt voor verzending en leveringsberekeningen.
6. user_id
Type: Many2one (res.users). De verantwoordelijke verkoper. Belangrijk voor commissies, follow-up en rapporten. Vaak overgenomen uit het verkoopteam of de gekoppelde opportuniteit.
7. team_id
Type: Many2one (crm.team). Het verkoopsteam. Groepeert verkopers en stuurt teamrapportages en targetberekeningen.
8. date_order
Type: Datetime. Datum van de order: creatiedatum voor concepten, bevestigingsdatum voor orders. Belangrijk voor rapportage en sortering.
9. validity_date
Type: Date. Geldigheidsdatum van de offerte. Na deze datum kan de offerte als verlopen worden beschouwd — handig voor tijdelijke aanbiedingen.
10. commitment_date
Type: Datetime. De beloofde leverdatum. Als deze is ingevuld, plant Odoo leveringen op basis van deze datum in plaats van standaard levertijden.
11. order_line
Type: One2many (sale.order.line). De orderregels: product, hoeveelheid, prijs en belastingen. Dit is de kern van de offerte/order.
12. amount_untaxed
Type: Float. Subtotaal zonder belasting. Wordt berekend uit de orderregels en gebruikt voor weergave en rapportage.
13. amount_tax
Type: Float. Totaal aan belasting. Wordt berekend op basis van de ingestelde belastingen per regel.
14. amount_total
Type: Float. Eindbedrag inclusief belasting. Dit is het bedrag dat uiteindelijk op de factuur en in de rapporten telt.
15. currency_id
Type: Many2one (res.currency). Valuta. Komt meestal van het bedrijf of de prijslijst; alle monetair velden gebruiken deze valuta.
16. pricelist_id
Type: Many2one (product.pricelist). De prijslijst die de eenheidsprijzen bepaalt. Kan automatisch uit het klantrecord komen of handmatig ingesteld worden.
17. payment_term_id
Type: Many2one (account.payment.term). Betalingscondities (bv. 30 dagen, voorschot). Worden overgenomen bij facturatie.
18. fiscal_position_id
Type: Many2one (account.fiscal.position). Fiscale positie voor belastingmappings — belangrijk bij grensoverschrijdende verkoop of speciale regimes.
19. client_order_ref
Type: Char. Klantreferentie of PO-nummer. Gebruikelijk wanneer de klant een eigen orderreferentie aanlevert; zichtbaar op documenten.
20. origin
Type: Char. Brondocument, bijvoorbeeld de naam van de opportuniteit of offerte waar dit uit voortkomt. Handig voor traceerbaarheid.
21. create_date
Type: Datetime. Moment van aanmaak van het record. Automatisch bijgehouden en nuttig voor auditing.
22. write_date
Type: Datetime. Moment van de laatste wijziging. Ook automatisch en helpt bij wijzigingshistoriek.
23. note
Type: Text. Algemene opmerkingen, voorwaarden of interne instructies. Kan op offertes en facturen zichtbaar gemaakt worden.
24. require_signature
Type: Boolean. Als aangevinkt, is online handtekening van de klant vereist voor bevestiging — veel gebruikt bij webshop- of portaalorders.
25. require_payment
Type: Boolean. Als aangevinkt, is betaling vereist vóór bevestiging — handig voor voorschot- of prepaidorders.
26. invoice_status
Type: Selection. Heeft waarden zoals no (nog niet gefactureerd), to invoice (gereed om te factureren), invoiced (volledig gefactureerd) of upsell (extra te factureren regels).
27. locked
Type: Boolean. Als True kan de order niet worden aangepast. Wordt vaak automatisch gezet bij bevestiging of wanneer gerelateerde documenten zijn geboekt.
28. company_id
Type: Many2one (res.company). In multi-company-omgevingen geeft dit aan bij welke vennootschap de order hoort en bepaalt zichtbaarheid en rechten.
29. tag_ids
Type: Many2many (crm.tag). Labels voor categorisering — handig om snel te filteren en segmenteren voor rapporten of workflows.
30. signed_by
Type: Char. Naam van de persoon die het document ondertekende wanneer require_signature gebruikt wordt; bewaard voor auditdoeleinden.
31. signed_on
Type: Datetime. Datum en tijd van ondertekening; relevant als een handtekening vereist is.
32. prepayment_percent
Type: Float. Percentage van het totaal dat als voorschot vereist is; gebruikt samen met require_payment voor aanbetalingen.
Hoe dit model in bedrijfsprocessen wordt ingezet
1. Van offerte naar order
Een typische flow: verkoper maakt een offerte, voegt regels en prijzen toe en stuurt die naar de klant. Na bevestiging verandert de offerte naar een verkooporder (state = sale) waarna facturen en leveringen gegenereerd kunnen worden.
2. E-commerce en klantportaal
Bestellingen via de webshop verschijnen als sales.order. Instellingen zoals require_signature en require_payment dwingen online betaling of ondertekening af voordat de order wordt bevestigd.
3. Van CRM naar Sales
Bij een gewonnen opportuniteit wordt er een offerte gegenereerd. Het origin-veld koppelt terug naar de opportuniteit en user_id/team_id zorgen dat verkooprapportage en commissies correct verlopen.
4. Facturatie
Uit een bevestigde order worden facturen aangemaakt: factuurregels halen hun gegevens uit de orderregels. Betalingscondities en fiscale positie komen ook van de order; invoice_status toont de stand van facturatie.
5. Levering en leverbeloften
commitment_date stuurt de planning van leveringen: als dit veld is ingevuld, plant Odoo leveringen rond die datum. partner_shipping_id bepaalt waar geleverd wordt.
Hoe ontwikkelaars dit model uitbreiden
Ontwikkelaars breiden sales.order uit met verschillende technieken; het meest gebruikte mechanisme is Odoo-modelinheritance.
Model-inheritance
Gebruik _inherit = 'sale.order' om het model uit te breiden. Zo voeg je velden toe, overschrijf je methodes of voeg je constraints toe terwijl je wijzigingen in een aparte module bewaart voor betere upgradebaarheid.
Nieuwe velden toevoegen
Definieer extra velden in je geërfde model met het juiste veldtype: Char, Many2one, Boolean, Integer, Text of Selection. Denk aan company-dependent velden in multi-company-omgevingen.
Python-uitbreidingen
Overschrijf methodes zoals action_confirm, create of write om extra logica toe te voegen en gebruik super() om standaardgedrag te behouden. Let op computed fields en hun dependencies zodat berekeningen correct blijven.
Odoo Studio
Odoo Studio maakt het mogelijk snel velden toe te voegen zonder code — handig voor eenvoudige aanpassingen. Voor complexe businesslogica en onderhoud op lange termijn zijn aangepaste modules doorgaans de betere keuze.
Aanbevelingen en goede gewoontes
- Gebruik altijd de juiste status voor elke fase van het verkoopproces en omzeil de bevestigingslogica niet zonder reden.
- Stel commitment_date in zodra er een afgesproken leverdatum is; dat verbetert de leverplanning en klantcommunicatie.
- Gebruik commercial_partner_id wanneer je met groepsklanten werkt en je wilt rapporteren of kredietbeheer op het hoogste niveau uitvoeren.
- Bij API-koppelingen werk je best via XML-RPC of JSON-RPC. Het sales.order-model is beschikbaar via de API; let op correcte mapping van externe ID's.
- Voor nieuwe velden gebruik je best een x_-prefix of module-prefix in de naam om conflicten met toekomstige Odoo-versies te vermijden.
Veelvoorkomende fouten
- Probeer geen bevestigde orders zomaar te wijzigen wanneer locked = True. Maak een revisie of volg de goedgekeurde workflow om consistentie te bewaren.
- Vermijd verwarring tussen partner_id, partner_invoice_id en partner_shipping_id: elk heeft een aparte rol. Zet alle drie velden wanneer factuur- en leveringsadressen verschillen.
- Overschrijf action_confirm niet zonder super() aan te roepen — dat kan andere modules breken of upgrades bemoeilijken.
- Maak geen verplichte custom velden zonder logische default: anders kunnen bestaande records bij upgraden in validatiefouten lopen.
- Vergeet pricelist_id niet in te stellen wanneer valuta of prijsberekening afwijkt van de standaard; foutieve prijslijsten leiden tot onjuiste facturen.
Samenvatting
Het sales.order-model is de ruggengraat van Odoo Sales: het beheert offertes en verkooporders. Inzicht in de velden en hoe andere modules eraan koppelen helpt je Odoo goed te configureren, aan te passen en te integreren.
Of je nu processen in kaart brengt als consultant of maatwerk bouwt als ontwikkelaar — een degelijke kennis van sales.order voorkomt tijdverlies en fouten.
Hulp nodig bij je Odoo-implementatie?
Dasolo begeleidt bedrijven bij implementatie, maatwerk en optimalisatie van Odoo, met speciale aandacht voor API-koppelingen en ontwikkeling. Ons team heeft uitgebreide ervaring met Odoo-data-architectuur en modellen zoals sales.order.
Heb je hulp nodig met je Odoo-implementatie, maatwerk of koppelingen? We ondersteunen je graag. Plan een demo om je project te bespreken.