Inleiding
In Odoo definiëren modellen hoe gegevens zijn gestructureerd en opgeslagen in de database. Elk stuk bedrijfsgegevens waarmee u werkt, van verkooporders tot facturen tot contacten, leeft 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 velden, relaties en bedrijfslogica.
Dit artikel richt zich op een van de belangrijkste modellen in Odoo: sales.order. Of u nu aangepaste modules bouwt, externe systemen integreert of verkoopworkflows configureert, u zult met dit model werken.
Wat is het sales.order Model
Het sales.order model vertegenwoordigt offertes en verkooporders in Odoo. Het is de centrale plek waar alle verkooptransacties worden vastgelegd voordat ze gefactureerd of geleverd worden.
Dit model in Odoo wordt gebruikt door de Verkoopmodule.
Wanneer een verkoper een offerte aanmaakt, creëert hij een sales.order record. Wanneer de klant bevestigt, gaat de order van concept naar bevestigd. Hetzelfde model in Odoo bevat zowel conceptoffertes als bevestigde orders. Het state-veld volgt de levenscyclus.
Andere modules breiden dit model uit via Odoo modelovererving. CRM koppelt kansen aan orders. Boekhouding voegt factuurvelden toe. Voorraad voegt leverings- en toezeggingsdata toe. 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 sales.order model. Het begrijpen hiervan zal je helpen om effectief te werken met offertes en orders.
1. naam
Type: Char. Dit veld slaat de orderreferentie of offertennummer op. Het wordt meestal automatisch gegenereerd (bijv. S00042) en weergegeven in lijstweergaven en op documenten. Het is de primaire identificator voor de order.
2. state
Type: Selectie. Volgt de levenscyclus van de order. Waarden: concept (offerte), verzonden (offerte verzonden naar klant), verkoop (bevestigde order), voltooid (volledig geleverd en gefactureerd), geannuleerd (geannuleerd). De state bepaalt welke acties beschikbaar zijn.
3. partner_id
Type: Many2one (res.partner). De klant. Vereist. Dit is de belangrijkste contactpersoon of bedrijf voor de order. Gebruikt voor alle klantgerelateerde logica en rapportage.
4. partner_invoice_id
Type: Many2one (res.partner). Het factuuradres. Als dit niet is ingesteld, wordt het standaard op partner_id gezet. Gebruik dit wanneer het factuuradres verschilt van de hoofdcontactpersoon (bijv. centrale facturering).
5. partner_shipping_id
Type: Many2one (res.partner). Het afleveradres. Als dit niet is ingesteld, wordt het standaard op partner_id gezet. Gebruikt voor leveringsorders en verzendberekeningen.
6. user_id
Type: Many2one (res.users). De verkoper of verantwoordelijke gebruiker. Gebruikt voor CRM, commissies en taaktoewijzing. Vaak ingesteld vanuit het verkoopteam of de kans.
7. team_id
Type: Many2one (crm.team). Het verkoopteam. Groepeert verkopers en stimuleert rapportage. Gebruikt voor teamgebaseerde dashboards en quota.
8. date_order
Type: Datetime. De besteldatum. Voor conceptbestellingen: aanmaakdatum. Voor bevestigde bestellingen: bevestigingsdatum. Gebruikt voor rapportage en sortering.
9. validity_date
Type: Date. De vervaldatum van de offerte. Na deze datum kan de offerte ongeldig worden. Nuttig voor tijdgebonden aanbiedingen.
10. commitment_date
Type: Datetime. De beloofde leverdatum. Wanneer ingesteld, worden leveringsorders gepland op basis van deze datum in plaats van productdoorlooptijden. Belangrijk voor klantverbintenissen.
11. order_line
Type: One2many (sale.order.line). De orderregels. Elke regel bevat product, hoeveelheid, prijs en belasting. Dit is de kerninformatie van de bestelling.
12. amount_untaxed
Type: Float. De subtotaal vóór belasting. Berekend op basis van orderregels. Gebruikt voor rapportage en weergave.
13. amount_tax
Type: Float. Het totale belastingbedrag. Berekend op basis van orderregels volgens de belastingconfiguratie. Weergegeven op de bestelling en factuur.
14. amount_total
Type: Float. Het totaalbedrag inclusief belasting. Het belangrijkste bedrag voor facturering en rapportage.
15. currency_id
Type: Many2one (res.currency). De valuta. Gewoonlijk geërfd van het bedrijf of prijslijst. Alle monetaire velden gebruiken deze valuta.
16. pricelist_id
Type: Many2one (product.pricelist). De prijslijst die voor de bestelling wordt gebruikt. Bepaalt de eenheidsprijzen op de regels. Kan worden ingesteld vanuit de partner of handmatig.
17. payment_term_id
Type: Many2one (account.payment.term). Betalingsvoorwaarden (bijv. Net 30, 50% vooruitbetaling). Gebruikt bij het aanmaken van facturen.
18. fiscal_position_id
Type: Many2one (account.fiscal.position). De fiscale positie voor belastingmapping. Toegepast wanneer de klant zich in een ander land bevindt of een speciaal belastingregime heeft.
19. client_order_ref
Type: Char. De klantreferentie of PO-nummer. Gebruikt wanneer de klant zijn eigen orderreferentie verstrekt. Weergegeven op documenten en in rapporten.
20. origin
Type: Char. Het brondocument. Bijvoorbeeld, wanneer een bestelling wordt aangemaakt vanuit een kans, wordt de naam van de kans hier opgeslagen. Gebruikt voor traceerbaarheid.
21. create_date
Type: Datetime. Slaat de datum en tijd op waarop het record is aangemaakt. Automatisch beheerd door Odoo. Nuttig voor rapportage en auditing.
22. write_date
Type: Datetime. Bewaart de datum en tijd van de laatste wijziging. Ook automatisch beheerd. Helpt bij het bijhouden wanneer gegevens voor het laatst zijn bijgewerkt.
23. opmerking
Type: Tekst. Voorwaarden of interne notities. Kan worden weergegeven op de offerte en factuur. Gebruikt voor juridische teksten of speciale instructies.
24. vereis_handtekening
Type: Boolean. Wanneer waar, moet de klant online tekenen voordat de bestelling wordt bevestigd. Gebruikt voor e-commerce en portaalstromen.
25. vereis_betaling
Type: Boolean. Wanneer waar, is betaling vereist voordat de bevestiging plaatsvindt. Gebruikt voor voorafbetaalde of op aanbetaling gebaseerde bestellingen.
26. factuur_status
Type: Selectie. Volgt de facturering: nee (niet gefactureerd), te factureren (klaar om te factureren), gefactureerd (volledig gefactureerd), of upsell (extra regels om te factureren).
27. vergrendeld
Type: Boolean. Wanneer waar, kan de bestelling niet worden gewijzigd. Wordt automatisch ingesteld wanneer de bestelling is bevestigd of wanneer gerelateerde documenten zijn gepost.
28. bedrijf_id
Type: Many2one (res.company). In multi-company setups, this indicates which Odoo company the order belongs to. Affects record visibility and access.
29. tag_ids
Type: Many2many (crm.tag). Tags for categorization. Used for filtering, reporting, and segmentation. Flexible for custom workflows.
30. signed_by
Type: Char. Name of the person who signed the order when require_signature is used. Stored for audit.
31. signed_on
Type: Datetime. Date and time of signature. Used when signature is required for confirmation.
32. prepayment_percent
Type: Float. The percentage of the order that must be paid as prepayment. Used with require_payment for deposit-based orders.
Hoe Dit Model Wordt Gebruikt in Bedrijfsworkflows
1. Offerte naar Bestelling
Verkoper maakt een offerte (concept). Voegt regels toe, stelt prijzen in, verstuurt naar klant. Klant bevestigt. De bestelling is bevestigd (staat = verkoop). Facturen en leveringsorders kunnen worden aangemaakt.
2. E-commerce en Portaal
Klanten plaatsen bestellingen op de website. Bestellingen worden aangemaakt als sales.order records. require_signature en require_payment kunnen online betaling of handtekening afdwingen voordat de bevestiging plaatsvindt.
3. CRM naar Verkoop
Wanneer een kans is gewonnen, wordt er een offerte uit aangemaakt. Het veld oorsprong linkt terug naar de kans. user_id en team_id sturen de verkooprapportage en commissies aan.
4. Facturatie
Vanuit een bevestigde bestelling creëren gebruikers facturen. Factuurregels worden gehaald uit bestelregels. payment_term_id en fiscal_position_id komen van de bestelling. invoice_status volgt de voortgang.
5. Levering en Verbintenis
commitment_date stuurt de planning van de levering. Wanneer ingesteld, worden leveringsorders eromheen gepland. partner_shipping_id definieert het afleveradres.
Hoe Ontwikkelaars Dit Model Uitbreiden
Ontwikkelaars breiden sales.order uit met verschillende patronen. Odoo modelovererving is het belangrijkste mechanisme.
Modelovererving
Gebruik _inherit = 'sale.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 Extensies
Overschrijf action_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.
Beste Praktijken
- Gebruik de juiste status voor elke fase. Sla geen statussen over of omzeil de bevestigingslogica niet.
- Stel commitment_date in wanneer de klant een beloofde datum heeft. Dit verbetert de leveringsplanning.
- Gebruik commercial_partner_id wanneer je de bovenliggende entiteit nodig hebt voor groepering (bijv. voor krediet of rapportage).
- Bij het bouwen van API-integraties, gebruik de XML-RPC of JSON-RPC API. Het sales.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 vermijden.
Veelvoorkomende Fouten
- Bevestigde bestellingen wijzigen zonder te controleren op vergrendeld. Vergrendelde bestellingen kunnen niet worden bewerkt. Maak een nieuwe revisie of gebruik de juiste workflow.
- Partner_id, partner_invoice_id en partner_shipping_id door elkaar halen. Elk heeft een specifieke functie. Stel alle drie in wanneer adressen verschillen.
- action_confirm overschrijven zonder super() aan te roepen. Dit kan andere modules of toekomstige upgrades breken.
- Vereiste aangepaste velden toevoegen zonder standaardwaarden. Bestaande bestellingen zullen falen bij validatie tijdens de upgrade.
- Vergeten om pricelist_id in te stellen wanneer de valuta of prijzen verschillen van de standaard. Foute prijzen kunnen leiden tot onjuiste facturering.
Conclusie
Het sales.order model is centraal in Odoo Sales. Het slaat offertes en bevestigde bestellingen op. Begrijpen hoe de velden werken en hoe modules het uitbreiden, zal je helpen Odoo effectief te configureren, aanpassen en integreren.
Of je nu een functionele consultant bent die verkoopprocessen in kaart brengt of een ontwikkelaar die aangepaste modules bouwt, een goed begrip van sales.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 sales.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.