Een te snel goedgekeurde bestelbon kan veel meer kosten dan een onvoorziene factuur. Ze creëert een precedent, omzeilt een budget, verbindt een team en bemoeilijkt de financiële controle. De behoefte om een validatieworkflow voor aankopen in Odoo op te zetten, ontstaat doorgaans wanneer aanvragen nog via e-mail, Excel of informele berichten verlopen. In dat stadium gaat het niet enkel om het toevoegen van een goedkeuring: het gaat om de aankoopbeslissing zichtbaar, coherent en evenredig met het risico te maken.
Voor een KMO moet een doeltreffende workflow twee valkuilen vermijden. Te licht laat ze teams bestellen zonder echte controle. Te zwaar vertraagt ze de operaties en drijft ze gebruikers ertoe kortere wegen buiten het systeem te zoeken. Odoo laat toe een evenwicht te vinden, op voorwaarde dat men vertrekt vanuit de werkelijke beheerregels in plaats van validaties uit principe op te stapelen.
Waarom een validatieworkflow voor aankopen opzetten in Odoo
De aankoopvalidatie beantwoordt aan drie zeer concrete behoeften: verbintenissen controleren, verantwoordelijkheden verduidelijken en een bruikbaar spoor bewaren. Wanneer een verantwoordelijke vraagt waarom een uitgave werd aangegaan, moet hij de aanvraag, de leverancier, het bedrag, het betrokken budget en de persoon die zijn akkoord gaf, kunnen terugvinden. Zonder deze keten komen de gesprekken pas na de bestelling, wanneer de manoeuvreerruimte al verdwenen is.
In Odoo onderscheidt de standaardflow van de module Aankoop met name het aanmaken van de prijsaanvraag, de verzending naar de leverancier en de bevestiging van de bestelbon. De controle-instellingen voor bestellingen laten al toe een validatie te vereisen volgens drempels. Dat is een nuttige basis voor veel bedrijven, vooral wanneer een aankoopverantwoordelijke de bestellingen voorbereidt en een directeur de significante bedragen valideert.
Maar de standaard dekt niet systematisch alle bedrijfsgevallen. Een bedrijf kan bepaalde aankopen willen laten valideren door de siteverantwoordelijke, het akkoord van financiën vereisen boven een bepaald bedrag, of IT-uitgaven aan de IT-afdeling onderwerpen ongeacht hun bedrag. Daar voorkomt een voorafgaande analyse dat een eenvoudig proces verandert in een log administratief apparaat.
Beginnen bij de beslissingen, niet bij de schermen
Vóór u Odoo configureert, stel een eenvoudige vraag: welke beslissingen moeten werkelijk worden gecontroleerd? Het antwoord beperkt zich niet tot een financiële drempel. Het hangt af van het type aankoop, de structuur van het bedrijf, de delegatie van bevoegdheid en het maturiteitsniveau van de teams.
Een korte workshop met aankoop, financiën en operationele medewerkers volstaat vaak om de belangrijke gevallen te identificeren. Men moet terugkerende en voorspelbare aankopen onderscheiden van uitzonderlijke uitgaven, gerefereerde leveranciers van nieuwe leveranciers, en exploitatie-uitgaven van investeringen. Gewoon verbruiksmateriaal bestellen voor een werkplaats vereist niet hetzelfde traject als een productieapparaat of een meerjarig softwareabonnement.
Documenteer vervolgens de regel in operationele taal. Bijvoorbeeld: de teamverantwoordelijke kan tot 2.500 euro valideren voor een goedgekeurde leverancier; daarboven valideert de financiële directie; elke nieuwe leverancier vereist een administratieve controle vóór de bestelling. Deze formulering is beter dan een complex schema dat niemand zes maanden later nog kan toepassen.
Drempels bepalen die zinvol zijn
De drempels moeten het risiconiveau weerspiegelen, niet een abstract verlangen naar controle. Een te lage drempel creëert een permanente wachtrij bij de bedrijfsleiders. Een te hoge drempel ontneemt het systeem elk nut. Men moet ook verduidelijken of het bedrag exclusief of inclusief belastingen wordt berekend, en of meerdere gelijkaardige bestellingen binnen een korte periode samen moeten worden beschouwd.
Het juiste niveau hangt af van uw activiteit. Een handelsonderneming met dagelijkse aankopen heeft een snelle en breed gedelegeerde flow nodig. Een dienstenbedrijf dat weinig aankopen doet maar belangrijke contracten aangaat, kan een strengere controle toepassen. Het volume, de kritikaliteit en de frequentie tellen even zwaar als het bedrag.
Een titularis en een vervanger aanduiden
Een workflow mag nooit rusten op één enkele persoon zonder continuïteitsoplossing. Als de goedkeurder afwezig is, mag de kritieke bestelling niet een week geblokkeerd blijven. Bepaal wie goedkeurt, wie vervangt, en binnen welke grenzen.
Deze regel lijkt vanzelfsprekend, maar wordt vaak vergeten bij de configuratie. De Odoo-rechten, de gebruikersrollen en de interne procedures moeten hetzelfde verhaal vertellen. Anders eindigt het aankoopteam met het exporteren van een PDF en het vragen van een akkoord per e-mail, wat het voordeel van de traceerbaarheid teniet doet.
De standaardflow configureren vóór men ontwikkelt
De eerste stap bestaat erin te controleren wat Odoo native dekt in uw versie en uw configuratie. De validatie-instellingen voor aankooporders kunnen één of meerdere goedkeuringsniveaus instellen volgens de bedragen. De rollen van de module Aankoop laten vervolgens toe de voorbereiding van bestellingen te scheiden van hun goedkeuring.
In een eenvoudige configuratie maakt de aankoper de prijsaanvraag aan, vult ze aan met de producten, de leverancier en de onderhandelde voorwaarden, en dient ze in. De bevoegde verantwoordelijke valideert ze of stuurt ze terug voor correctie. Eens de bestelbon bevestigd is, volgen de ontvangst- en facturatiestappen de gebruikelijke regels van het bedrijf.
Deze standaardaanpak is vaak de beste initiële beslissing. Ze beperkt de onderhoudskosten, vergemakkelijkt de updates en vermindert de afhankelijkheid van specifieke code. Een personalisatie wordt pas relevant wanneer ze beantwoordt aan een duidelijke regel die de standaard niet netjes kan beheren.
Wanneer een workflow op maat noodzakelijk wordt
Sommige organisaties hebben nood aan een fijner traject. Dat kan een validatie zijn per departement, per kostenplaats, per productcategorie, per project of per site. Andere wensen een budgettaire controle te integreren vóór de verbintenis, een verantwoordelijke te informeren via een Odoo-activiteit, of de validatie te blokkeren wanneer verplichte informatie ontbreekt.
In deze gevallen kan Odoo Studio volstaan om velden, statussen, activiteiten en bepaalde eenvoudige automatiseringen toe te voegen. Voor complexe regels is een Python-personalisatie doorgaans betrouwbaarder. De keuze hangt af van de toe te passen logica, de auditbehoefte en de verwachte levensduur van het proces.
Voorzichtigheid is geboden. Een slecht ontworpen aangepaste regel kan zich anders gedragen naargelang een bestelling manueel wordt aangemaakt, geïmporteerd, gedupliceerd of gegenereerd vanuit een andere flow. De ontwikkeling moet dus rekening houden met toegangsrechten, uitzonderingsgevallen, meldingen, annuleringen en wijzigingen na goedkeuring.
Uitzonderingen van bij het begin voorzien
De echte test van een workflow is niet de normale bestelling. Het is de dringende bestelling, de correctie na validatie of de aankoop die nodig is om een productiestop te vermijden. Als deze situaties niet zijn voorzien, zullen de teams ze buiten Odoo behandelen.
Bepaal een beperkt noodtraject, met een verplichte rechtvaardiging en een duidelijk geïdentificeerde validatie achteraf. Voorzie ook wat er gebeurt wanneer een bedrag, een leverancier of een bestellijn verandert na het akkoord. In veel gevallen moet een significante wijziging het document terug in afwachting van validatie zetten. Zonder dat kan een goedgekeurde bestelling van 1.800 euro worden gewijzigd naar 8.000 euro zonder nieuwe controle.
Het is ook nuttig te beslissen wie een bevestigde bestelling kan annuleren en hoe de informatie doorstroomt naar financiën. De aankoopworkflow moet coherent blijven met de ontvangsten, de leveranciersfacturen en eventuele budgettaire verbintenissen.
Testen met echte bedrijfsscenario's
Vóór de uitrol, test het traject met representatieve gevallen: een kleine gewone bestelling, een bestelling boven de drempel, een nieuwe leverancier, een dringende aanvraag, een wijziging na goedkeuring en de afwezigheid van een goedkeurder. Deze test moet worden uitgevoerd door bedrijfsgebruikers, niet enkel door het projectteam.
Het doel is de tijd te meten die nodig is voor elke beslissing en dubbelzinnigheden te identificeren. Als een verantwoordelijke niet weet waarom een bestelling aan hem wordt toegewezen, is het probleem niet zijn opleiding: de regel is waarschijnlijk slecht gedefinieerd. Als aankopers de flow moeten omzeilen om hun termijnen te halen, moet het controleniveau of de delegaties worden herzien.
Volg na de ingebruikname enkele eenvoudige indicatoren: gemiddelde validatietermijn, aantal geblokkeerde bestellingen, wijzigingspercentage na goedkeuring en volume van dringende aankopen. Deze gegevens tonen snel of het proces het bedrijf werkelijk beschermt zonder de activiteit af te remmen.
Een goed ontworpen aankoopvalidatieworkflow is geen administratieve rem. Het is een beslissingskader dat teams toelaat snel te werken op lopende uitgaven, terwijl het de directie een betrouwbaar zicht geeft op belangrijke verbintenissen. Bij Agitech stellen we vast dat de beste resultaten zelden voortkomen uit de meest geavanceerde workflow: ze komen voort uit een duidelijke regel, begrepen door de teams en correct toegepast in Odoo.