Inleiding
In Odoo definiëren modellen hoe gegevens zijn gestructureerd en opgeslagen in de database. Elk stuk bedrijfsgegevens waarmee u werkt, van inkooporders tot facturen tot inventaris, bevindt zich in een model.
Het begrijpen van Odoo-modellen is essentieel voor zowel ontwikkelaars als functionele consultants. Modellen zijn de basis van de Odoo-gegevensarchitectuur. Ze definiëren Odoo-velden, relaties en bedrijfslogica.
Dit artikel richt zich op een van de belangrijkste modellen in Odoo: purchase.order. Of u nu aangepaste modules bouwt, externe systemen integreert of inkoopworkflows configureert, u zult met dit model werken.
Wat is het purchase.order Model
Het purchase.order model vertegenwoordigt inkooporders en aanvragen voor offertes (RFQ's) in Odoo. Het is de centrale plaats waar alle inkooptransacties worden vastgelegd voordat ze ontvangstbewijzen of leveranciersfacturen worden.
Dit model in Odoo wordt gebruikt door de Purchase-module. Wanneer een koper een RFQ aanmaakt, creëren ze een purchase.order record. Wanneer de leverancier bevestigt of de koper goedkeurt, gaat de bestelling van concept naar bevestigd. Hetzelfde model in Odoo bevat zowel concept RFQ's als bevestigde inkooporders. Het state-veld volgt de levenscyclus.
Andere modules breiden dit model uit via Odoo modelovererving. Voorraad voegt ontvangst- en pickinglogica toe. Boekhouding voegt velden voor leveranciersfacturen toe. Productie kan inkooporders aanmaken vanuit stuklijsten. Elke module voegt toe wat het nodig heeft zonder de kernstructuur te dupliceren.
Belangrijke Velden in het Model
Hier zijn de belangrijkste Odoo-velden in het purchase.order model. Het begrijpen hiervan zal je helpen om effectief met inkooporders te werken.
1. name
Type: Char. Dit veld slaat de orderreferentie op (bijv. PO00042). Het wordt doorgaans automatisch gegenereerd en weergegeven in lijstweergaven en op documenten. Het is de primaire identificator voor de inkooporder.
2. state
Type: Selection. Volgt de levenscyclus van de bestelling. Waarden: draft (RFQ), sent (verzonden naar leverancier), to approve (in afwachting van goedkeuring), purchase (bevestigd), done (volledig ontvangen en gefactureerd), cancel (geannuleerd). De state bepaalt welke acties beschikbaar zijn.
3. partner_id
Type: Many2one (res.partner). De leverancier of leverancier. Vereist. Dit is de belangrijkste contactpersoon of het bedrijf voor de bestelling. Gebruikt voor alle leverancier-gerelateerde logica en rapportage.
4. partner_ref
Type: Char. De leverancierreferentie of het PO-nummer van de leverancier. Gebruikt wanneer de leverancier zijn eigen orderreferentie verstrekt. Weergegeven op documenten en helpt bij het matchen van ontvangstbewijzen en facturen.
5. date_order
Type: Datetime. De besteldatum. Voor conceptbestellingen: aanmaakdatum. Voor bevestigde bestellingen: bevestigingsdatum. Gebruikt voor rapportage, sortering en als de standaard verwachte datum voor bestelregels.
6. date_approve
Type: Datetime. De goedkeurings- of bevestigingsdatum. Ingesteld wanneer de bestelling naar de aankoopstatus gaat. Alleen-lezen. Gebruikt voor rapportage en auditsporen.
7. order_line
Type: One2many (purchase.order.line). De bestelregels. Elke regel bevat product, hoeveelheid, prijs en belasting. Dit is de kerninformatie van de aankooporder.
8. amount_untaxed
Type: Float. De subtotalen voor belasting. Berekend op basis van bestelregels. Gebruikt voor rapportage en weergave.
9. amount_tax
Type: Float. Het totale belastingbedrag. Berekend op basis van bestelregels volgens de belastingconfiguratie. Weergegeven op de bestelling en de leverancier factuur.
10. amount_total
Type: Float. Het totaalbedrag inclusief belasting. Het belangrijkste bedrag voor facturering en rapportage.
11. currency_id
Type: Many2one (res.currency). De valuta. Gewoonlijk geërfd van het bedrijf of de leverancier. Alle monetaire velden gebruiken deze valuta.
12. origin
Type: Char. Het brondocument. Bijvoorbeeld, wanneer een bestelling wordt aangemaakt vanuit een verkooporder (dropship) of productieorder, wordt de bronnaam hier opgeslagen. Gebruikt voor traceerbaarheid.
13. dest_address_id
Type: Many2one (res.partner). Het afleveradres. Als dit niet is ingesteld, wordt standaard het bedrijfsadres gebruikt. Gebruikt voor dropshipping wanneer goederen rechtstreeks naar de klant gaan.
14. priority
Type: Selection. Bestelprioriteit: Normaal of Urgent. Gebruikt voor sorteren en markeren. Urgente bestellingen kunnen speciale behandeling krijgen in workflows.
15. invoice_status
Type: Selection. Volgt de facturering: nee (niet gefactureerd), te factureren (klaar om te factureren), gefactureerd (volledig gefactureerd). Bepaalt de zichtbaarheid van de actie Factuur Aanmaken.
16. invoice_count
Type: Integer. Aantal gerelateerde leveranciersfacturen. Gecomputeerd. Gebruikt voor weergave en om de lijst met facturen te openen.
17. invoice_ids
Type: One2many (account.move). De gerelateerde leveranciersfacturen. Koppelt inkooporders aan de boekhouding. Gebruikt voor drieledige matching en betalingstracking.
18. picking_ids
Type: One2many (stock.picking). De gerelateerde leveringsorders of ontvangstbewijzen. Gebruikt wanneer de Inkoopmodule is geïnstalleerd met Voorraadbeheer.
19. picking_count
Type: Integer. Aantal gerelateerde pickings. Gecomputeerd. Gebruikt voor weergave en om de lijst van ontvangstbewijzen te openen.
20. create_date
Type: Datetime. Slaat de datum en tijd op waarop het record is aangemaakt. Automatisch beheerd door Odoo. Nuttig voor rapportage en auditing.
21. write_date
Type: Datetime. Slaat de datum en tijd van de laatste wijziging op. Ook automatisch beheerd. Helpt bij het bijhouden wanneer gegevens voor het laatst zijn bijgewerkt.
22. notes
Type: Text. Voorwaarden of interne notities. Kan op de inkooporder worden weergegeven. Gebruikt voor speciale instructies aan de leverancier.
23. company_id
Type: Many2one (res.company). In multi-company setups, dit geeft aan tot welk Odoo-bedrijf de bestelling behoort. Beïnvloedt de zichtbaarheid en toegang tot records.
24. user_id
Type: Many2one (res.users). De koper of verantwoordelijke gebruiker. Gebruikt voor goedkeuringsworkflows en toewijzing van activiteiten.
25. fiscal_position_id
Type: Many2one (account.fiscal.position). De fiscale positie voor belastingmapping. Toegepast wanneer de leverancier zich in een ander land bevindt of een speciaal belastingregime heeft.
26. payment_term_id
Type: Many2one (account.payment.term). Betalingsvoorwaarden (bijv. Net 30, 50% vooruitbetaling). Gebruikt bij het aanmaken van leveranciersfacturen.
27. display_name
Type: Char. Gecomputeerde weergavenaam. Combineert naam met leveranciersinformatie. Gebruikt in many2one dropdowns en zoekresultaten. Alleen-lezen.
28. active
Type: Boolean. Soft delete-vlag. Wanneer False, wordt het record gearchiveerd en verborgen in standaardweergaven. Inkooporders worden niet fysiek verwijderd om de geschiedenis te behouden.
Hoe Dit Model Wordt Gebruikt in Bedrijfsworkflows
1. RFQ naar Aankooporder
De koper maakt een aanvraag voor offerte (concept). Voegt regels toe, verzendt naar de leverancier. Leverancier bevestigt of koper bevestigt handmatig. De bestelling is bevestigd (status = aankoop). Ontvangsten en leveranciersfacturen kunnen worden aangemaakt.
2. Leveranciersontvangst
Wanneer goederen aankomen, maakt de gebruiker een ontvangst aan vanuit de aankooporder. De picking_ids zijn gekoppeld. Ontvangen hoeveelheden actualiseren de voorraad. Productkosten worden bijgewerkt op basis van de aankoopprijs.
3. Leveranciersfactuur
Vanuit een bevestigde bestelling creëren gebruikers leveranciersfacturen. Factuurregels worden gehaald uit de bestelregels. payment_term_id en fiscal_position_id komen van de bestelling. invoice_status volgt de voortgang.
4. Dropshipping
Wanneer een verkooporder een aankoop triggert, linkt de oorsprong terug naar de verkoop. dest_address_id is ingesteld op het klantadres zodat de leverancier rechtstreeks verzendt. Het model purchase.order is de brug tussen verkoop en inkoop.
5. Productie en MRP
Wanneer een productieorder componenten nodig heeft, kan deze aankooporders aanmaken voor grondstoffen. Het oorsprongsveld linkt naar de productieorder. Dit model is centraal in de procure-to-pay cyclus.
Hoe Ontwikkelaars Dit Model Uitbreiden
Ontwikkelaars breiden purchase.order uit met verschillende patronen. Odoo modelovererving is het belangrijkste mechanisme.
Modelovererving
Gebruik _inherit = 'purchase.order' om het model uit te breiden. Voeg nieuwe Odoo-velden toe, overschrijf methoden of voeg beperkingen toe. Het erfmodel in Odoo houdt je wijzigingen in een aparte module voor gemakkelijke upgrades.
Velden Toevoegen
Definieer nieuwe Odoo-velden in je geërfde model. Gebruik het juiste veldtype: Char, Many2one, Boolean, Integer, Text, Selection. Overweeg bedrijfsspecifieke velden voor meerdere bedrijven.
Python Uitbreidingen
Overschrijf button_confirm, create of write om logica toe te voegen. Gebruik super() om de originele aanroep te doen. Wees voorzichtig met berekende velden en hun afhankelijkheden.
Odoo Studio
Odoo Studio stelt je in staat om velden toe te voegen zonder code. Goed voor snelle aanpassingen. Voor complexe logica of upgrades zijn aangepaste modules beter onderhoudbaar. Het API-model in Odoo (purchase.order) is volledig blootgesteld via XML-RPC en JSON-RPC voor integraties.
Beste Praktijken
- Gebruik de juiste status voor elke fase. Sla geen statussen over of omzeil de bevestigingslogica niet.
- Stel partner_ref in wanneer de leverancier een referentie biedt. Dit helpt bij het matchen van ontvangsten en facturen.
- Gebruik origin om de bron van inkooporders te traceren. Essentieel voor dropshipping en productie.
- Bij het bouwen van API-integraties, gebruik de XML-RPC of JSON-RPC API. Het purchase.order model is volledig blootgesteld. Map externe ID's zorgvuldig.
- Voor aangepaste velden, gebruik de
x_prefix of een moduleprefix om conflicten met toekomstige Odoo-versies te voorkomen.
Veelvoorkomende Fouten
- Bevestigde bestellingen wijzigen zonder de status te controleren. Bevestigde bestellingen hebben beperkte velden. Maak een nieuwe bestelling of gebruik de juiste workflow.
- Partner_id en dest_address_id verwarren. partner_id is de leverancier; dest_address_id is waar de goederen naartoe gaan (voor dropshipping).
- De button_confirm overschrijven zonder super() aan te roepen. Dit kan andere modules of toekomstige upgrades verstoren.
- Vereiste aangepaste velden toevoegen zonder standaardwaarden. Bestaande bestellingen zullen falen bij validatie tijdens de upgrade.
- Vergeten om currency_id in te stellen bij het omgaan met leveranciers in meerdere valuta. Een verkeerde valuta kan leiden tot onjuiste kosten en facturering.
Conclusie
Het model purchase.order is centraal in Odoo Purchase. Het slaat RFQ's en bevestigde aankoopbestellingen op. Begrijpen hoe de Odoo-velden zijn en hoe modules het uitbreiden, zal je helpen Odoo effectief te configureren, aan te passen en te integreren.
Of je nu een functionele consultant bent die inkoopprocessen in kaart brengt of een ontwikkelaar die aangepaste modules bouwt, een goed begrip van purchase.order zal tijd besparen en fouten voorkomen.
Hulp Nodig Bij Uw Odoo Implementatie?
Dasolo helpt bedrijven bij het implementeren, aanpassen en optimaliseren van Odoo. We zijn gespecialiseerd in API-integraties en Odoo-ontwikkeling. Ons team heeft diepgaande ervaring met de Odoo-gegevensarchitectuur en modellen zoals purchase.order.
Als je hulp nodig hebt bij je Odoo-implementatie, aangepaste modules of integraties, zijn we hier om te helpen. Boek een demo om je project te bespreken.