Inleiding
In Odoo bepaalt elk model hoe zakelijke gegevens worden bewaard en georganiseerd. Of het nu gaat om bestellingen, facturen of stockmutaties: de structuur en relaties komen altijd terug in een model, dat als opslag- en logica‑laag fungeert.
Kennis van Odoo‑modellen is cruciaal voor zowel ontwikkelaars als functionele consultants. Modellen vormen de ruggengraat van de data‑architectuur: ze definiëren velden, relaties en de zakelijke regels die bepalen hoe processen zich gedragen.
Dit stuk zoomt in op een van de kernmodellen: purchase.order. Of je nu extra modules bouwt, koppelt aan externe systemen of het inkoopproces configureert, je komt onvermijdelijk met dit model in aanraking.
Wat is het purchase.order-model?
Het purchase.order‑model is de digitale kaart van inkoopaanvragen en bevestigde inkooporders in Odoo. Hier verzamelt en bewaart het systeem alle informatie over wat besteld werd, van wie en wanneer — nog vóór er goederen worden ontvangen of facturen geboekt.
De Purchase‑module gebruikt dit model als centrale workflowhub. Een gebruiker begint meestal met een RFQ (concept), voegt lijnen toe en stuurt die naar de leverancier. Na bevestiging of goedkeuring verandert de status naar bevestigd; hetzelfde object houdt zowel concepten als definitieve bestellingen bij, met een statusveld dat hun levenscyclus regelt.
Andere modules bouwen bovenop dit fundament via Odoo‑erfenis. De voorraadmodule koppelt ontvangsten en picking‑logica; accounting voegt velden voor leveranciersfacturen toe; MRP kan bestellingen vanuit stuklijsten genereren. Zo voegt elk onderdeel zijn specifieke functionaliteit toe zonder het basismodel te dupliceren.
Belangrijke velden in het model
Een goed begrip van de belangrijkste velden in purchase.order maakt het eenvoudiger om bestellingen te filteren, koppelingen te leggen en rapporten te bouwen.
1. name
Type: Char. Dit is de referentie van de bestelling (bv. PO00042). Meestal automatisch gegenereerd en prominent zichtbaar in lijsten en documenten — het belangrijkste herkenningskenmerk van de order.
2. state
Type: Selection. Houdt de levenscyclus bij: draft (RFQ), sent, to approve, purchase (bevestigd), done (ontvangen & gefactureerd), cancel. De status bepaalt welke acties en knoppen beschikbaar zijn.
3. partner_id
Type: Many2one (res.partner). De leverancier. Vereist. Dit is de hoofdcontactpersoon of bedrijf voor de bestelling en bepaalt veel leveranciersspecifieke regels en rapporten.
4. partner_ref
Type: Char. Referentie van de leverancier (hun PO‑nummer). Handig om documenten en binnenkomende facturen en leveringen te matchen.
5. date_order
Type: Datetime. De datum van de order: aanmaakdatum voor concepten, bevestigingsdatum voor definitieve bestellingen. Wordt gebruikt voor rapportering en planning.
6. date_approve
Type: Datetime. Datum van goedkeuring/confirmatie. Wordt gevuld bij overstap naar de purchase‑status en is nuttig voor audits en analyses.
7. order_line
Type: One2many (purchase.order.line). De orderregels: product, hoeveelheid, prijs en belastingen. Dit is de gedetailleerde inhoud van de bestelling.
8. amount_untaxed
Type: Float. Subtotaal zonder btw. Wordt berekend uit de orderregels en gebruikt voor weergave en rapporten.
9. amount_tax
Type: Float. Totaalbedrag aan btw. Wordt berekend op basis van de toegepaste belastinginstellingen en verschijnt op bestel- en factuurdocumenten.
10. amount_total
Type: Float. Eindbedrag inclusief btw. Belangrijk voor facturatie en financiële rapportage.
11. currency_id
Type: Many2one (res.currency). Valuta. Vaak afgeleid van bedrijf of leverancier; alle monetaire velden gebruiken deze valuta.
12. origin
Type: Char. Brondocument of verwijzing (bv. verkoopordernummer of M.O.). Handig voor traceerbaarheid en het volgen van hoe de bestelling tot stand kwam.
13. dest_address_id
Type: Many2one (res.partner). Leveringsadres. Standaard het bedrijfsadres tenzij anders opgegeven; essentieel bij dropshipping wanneer de leverancier rechtstreeks naar de klant levert.
14. priority
Type: Selection. Prioriteit van de order: normaal of urgent. Wordt gebruikt om rijen te sorteren en aandacht te vestigen op spoedbestellingen.
15. invoice_status
Type: Selection. Volgt de facturatiestatus: no, to invoice, invoiced. Bepaalt onder meer of de knop 'Maak factuur' beschikbaar is.
16. invoice_count
Type: Integer. Aantal gekoppelde leverancierfacturen. Berekenend veld dat in overzichten gebruikt wordt.
17. invoice_ids
Type: One2many (account.move). De gerelateerde leverancierfacturen. Verbindt inkooporders met de boekhouding voor matching en betalingen.
18. picking_ids
Type: One2many (stock.picking). Gerelateerde leveringen/ontvangsten. Aanwezig wanneer voorraadfunctionaliteit actief is.
19. picking_count
Type: Integer. Aantal gekoppelde pickings. Berekenend veld, handig om snel naar ontvangsten te navigeren.
20. create_date
Type: Datetime. Tijdstip van aanmaak van het record. Automatisch gevuld en nuttig voor rapporten en auditing.
21. write_date
Type: Datetime. Tijdstip van laatste wijziging. Wordt automatisch bijgehouden om updates te monitoren.
22. notes
Type: Text. Vrij veld voor leveringsvoorwaarden of interne instructies. Kan op de besteltekst verschijnen voor de leverancier.
23. company_id
Type: Many2one (res.company). Bij multi‑company setups geeft dit aan bij welk bedrijf de order hoort en bepaalt zichtbaarheid en toegangsregels.
24. user_id
Type: Many2one (res.users). De koper of verantwoordelijke gebruiker. Belangrijk voor goedkeuringsstromen en taken.
25. fiscal_position_id
Type: Many2one (account.fiscal.position). Fiscale positie voor belastingmapping bij grensoverschrijdende of bijzondere gevallen.
26. payment_term_id
Type: Many2one (account.payment.term). Betalingsvoorwaarden (bv. netto 30). Worden meegenomen bij het aanmaken van facturen.
27. display_name
Type: Char. Berekende weergavenaam die referentie met leverancier combineert. Gebruikt in dropdowns en zoekresultaten.
28. active
Type: Boolean. Archiveervlag. Op False wordt de order verborgen in standaardlijsten zodat historische data behouden blijft zonder te verwijderen.
Hoe dit model werkt binnen bedrijfsprocessen
1. Van RFQ naar bevestigde order
Een typische flow begint met een RFQ in conceptfase: de koper voegt orderregels toe en stuurt die naar de leverancier. Na bevestiging verandert de status naar purchase en kunnen ontvangsten en facturen worden aangemaakt.
2. Ontvangst van goederen
Bij ontvangst wordt vanuit de bestelling een ontvangst (picking) aangemaakt. De voorraad wordt aangepast op basis van ontvangen hoeveelheden en inkoopprijzen kunnen of worden gebruikt om productkostprijzen bij te werken.
3. Leveranciersfactuur
Na bevestiging kan een leverancierfactuur worden aangemaakt op basis van de orderregels. Betaalcondities en fiscale positionering komen van de order; de invoice_status laat zien hoe ver de facturatie staat.
4. Dropshipping
Bij dropshipping koppelt de origin‑vermelding terug naar de verkooporder en staat het leveringsadres op het klantadres, zodat de leverancier rechtstreeks naar de klant verzendt. Het purchase.order‑model verbindt verkoop en inkoop in die keten.
5. Productie en MRP
Wanneer de productie onderdelen nodig heeft, kan het MRP‑proces automatisch inkooporders aanmaken voor grondstoffen. De origin verwijst dan naar de productieorder en zo blijft de procure‑to‑pay‑keten volledig traceerbaar.
Hoe ontwikkelaars dit model uitbreiden
Ontwikkelaars breiden purchase.order uit met verschillende technieken; de meest gebruikte is modelerfenis in Odoo.
Modelerfenis
Gebruik _inherit = 'purchase.order' om het bestaand model te verrijken. Je kunt extra velden toevoegen, methodes overschrijven of constraints invoegen. Door uitbreidingen in aparte modules te plaatsen blijft de kerncode upgrade‑vriendelijk.
Veldtoevoegingen
Voeg nieuwe velden toe in je geërfde model met het juiste veldtype (Char, Many2one, Boolean, Integer, Text, Selection). Denk bij multi‑company aan company‑afhankelijke velden en aan default‑waarden.
Python‑uitbreidingen
Overschrijf methodes zoals button_confirm, create of write om bedrijfslogica toe te voegen. Roep steeds super() aan waar nodig en wees voorzichtig met berekende velden en hun dependencies.
Odoo Studio
Met Odoo Studio kun je snel velden toevoegen zonder code — handig voor eenvoudige aanpassingen. Voor complexere logica en toekomstbestendigheid bouw je best een custom module. Het model is daarnaast volledig toegankelijk via XML‑RPC/JSON‑RPC voor integraties.
Aanbevolen werkwijzen
- Gebruik steeds de juiste status voor elke stap; sla geen statussen over of forceer bevestigingen, want dat verstoort downstream‑flows.
- Registreer partner_ref wanneer de leverancier een referentienummer meegeeft; dat vereenvoudigt matching tussen leveringen en facturen.
- Houd origin bij om de herkomst van bestellingen helder te houden — onmisbaar bij dropshipping en MRP‑tracing.
- Voor API‑koppelingen gebruik je XML‑RPC of JSON‑RPC en map je externe ID's zorgvuldig naar purchase.order records.
- Voor custom velden gebruik je een x_‑prefix of moduleprefix om conflicten met toekomstige Odoo‑versies te vermijden.
Veelgemaakte fouten
- Een veelgemaakte fout is bevestigde bestellingen zomaar wijzigen. Veel velden zijn beperkt na confirmatie; volg de workflow of maak een nieuwe order waar nodig.
- Verwar partner_id niet met dest_address_id: de eerste is de leverancier, de tweede is het afleveradres (cruciaal bij dropshipping).
- Overschrijf button_confirm nooit zonder super() te roepen; dat breekt integraties en maakt upgrades problematisch.
- Voeg geen verplichte custom velden toe zonder default‑waarde: bestaande records kunnen daardoor tijdens upgrades verdwijnen of fouten veroorzaken.
- Vergeet bij multi‑currency leveranciers niet currency_id in te stellen; een verkeerde valuta leidt tot foutieve kostprijzen en facturatie.
Samengevat
Het purchase.order‑model is het hart van inkoop in Odoo: het bewaart RFQ's en bevestigde orders en vormt het vertrekpunt voor ontvangsten, facturen en integraties. Begrijpen welke velden er toe doen en hoe modules bovenop dit model bouwen, maakt configuratie en maatwerk veel eenvoudiger.
Of je nu processen in kaart brengt als consultant of modules bouwt als ontwikkelaar: een grondige kennis van purchase.order voorkomt fouten en bespaart tijd gedurende implementaties.
Hulp nodig bij je Odoo-implementatie?
Dasolo ondersteunt bedrijven bij implementatie, maatwerk en optimalisatie van Odoo. We specialiseren ons in API‑koppelingen en development en hebben ruime ervaring met de Odoo‑datamodellen, waaronder purchase.order.
Heb je hulp nodig bij je Odoo‑implementatie, maatwerk of koppelingen? Wij helpen je graag. Plan een demo om je project te bespreken.