Leermoment 1: kortingsstaffels per klantgroep die nergens uniform staan
De meeste groothandels werken met meerdere klantgroepen: vaste afnemers, projectklanten, grootafnemers, incidentele kopers. Elke groep heeft eigen kortingsafspraken, en die afspraken zijn zelden op dezelfde plek vastgelegd. Eén klantgroep staat in het ERP, een andere in een Excel die de accountmanager zelf bijhoudt, en een derde in een e-mailthread van twee jaar geleden. Zodra je de verkoopprijsberekening wilt automatiseren, stuit je hier meteen op. Er is geen enkele bron van waarheid. De enige die weet welke korting van toepassing is, is de accountmanager zelf. Dat maakt automatisering niet alleen technisch lastig: het maakt het ook risicovol, want een fout in de korting valt pas op als de klant de factuur betwist. De oplossing is niet een slimmer systeem, maar eerst het huiswerk: alle kortingsafspraken centraal vastleggen in één gestructureerde tabel, met klantgroep, productcategorie en volumedrempel als dimensies. Pas dan kun je een engine bouwen die de rekensom automatisch maakt. Wie dat huiswerk overslaat en direct begint te automatiseren, automatiseert chaos.
Leermoment 2: valutakoersen die verouderd zijn op het moment van orderbevestiging
Veel groothandels kopen in dollars of andere valuta en verkopen in euro. De inkoopprijs wordt omgerekend bij het aanmaken van het artikel in het systeem, met de koers van dat moment. Die koers kan weken of maanden oud zijn tegen de tijd dat de order daadwerkelijk binnenkomt. Het gevolg: de verkoopprijs is gebaseerd op een inkoopprijs die niet meer klopt. De marge is op papier gezond, maar in werkelijkheid heeft de koers de winst deels opgegeten. Dit patroon zien we terugkomen bij groothandels die importeren uit landen met beweeglijke valuta. De technische oplossing is niet ingewikkeld: koppel een valutafeed aan je prijsengine en herbereken de inkoopprijs in euro op het moment dat een order wordt aangemaakt, niet op het moment dat het artikel in het systeem werd gezet. Maar dat vereist wel een architectuur waarbij inkoopprijs en verkoopprijs losstaande, realtime berekende grootheden zijn, geen vaste velden in een artikelstamkaart. Wie dat onderscheid niet maakt in het datamodel, blijft koersen handmatig corrigeren.
Leermoment 3: de koppeling tussen inkoopprijs en verkoopprijs loopt niet realtime
Dit is het meest voorkomende knelpunt bij het automatiseren van de verkoopprijsberekening in de groothandel. De inkoopprijs komt binnen via een leveranciersbevestiging of een inkooporder. De verkoopprijs staat in een ander systeem, of is handmatig vastgezet op basis van een oude inkoopprijs. De koppeling tussen die twee is geen realtime verbinding, maar een handmatige stap: iemand vergelijkt, rekent bij, past aan. Dat gaat prima als de marges ruim zijn en de prijswijzigingen zeldzaam. Zodra de marges krap zijn en leveranciers frequenter prijzen aanpassen, zie je dat de verkoopprijzen structureel achter de feiten aanlopen. De marge is pas achteraf zichtbaar, bij de maandafsluiting of de kwartaalrapportage. Op dat moment kun je niets meer bijsturen op de orders die al uitgeleverd zijn. De oplossing is een prijsengine die de verkoopprijs herberekent zodra de inkoopprijs wijzigt, met een signalering als de marge onder een ingestelde drempel komt. Dat is geen kunstmatige intelligentie, dat is gewoon goede software-architectuur: inkoopprijs en margepercentage als variabelen, verkoopprijs als berekend veld, niet als handmatig ingevoerd getal.
Wanneer volstaat een configurator voor het berekenen van verkoopprijzen?
Niet elke groothandel heeft maatwerk nodig. Een standaard configurator of een goed ingericht ERP-pakket met prijslijstfunctionaliteit kan voldoende zijn als de kortingsstructuur uniform is (maximaal twee of drie klantgroepen), de valutarisico's beperkt zijn of afgedekt worden via inkoopcontracten, en de inkoopprijs stabiel genoeg is dat maandelijkse updates volstaan. In die situatie is het verstandiger om het bestaande pakket beter te gebruiken dan een maatwerksysteem te bouwen. Maatwerk wordt relevant zodra de kortingsstructuur klantspecifiek is en niet in standaard staffels past, zodra valutaschommelingen direct doorwerken in de marge en je dat realtime wilt zien, of zodra je meerdere systemen hebt die nu handmatig gesynchroniseerd worden. Dan bouw je geen extra laag over het probleem heen: dan is het slimmer om de prijsengine opnieuw en correct te bouwen, met de juiste databronnen als input.
Hoe pak je het automatiseren van verkoopprijsberekening aan in de groothandel?
Begin niet bij de software, begin bij het datamodel. Welke variabelen bepalen de verkoopprijs? Inkoopprijs, valutakoers, vaste marge per categorie, klantspecifieke korting, volumekorting, eventueel transportkosten of toeslagen. Leg die variabelen vast in een gestructureerde tabel. Controleer of er een eenduidige bron is voor elk van die variabelen. Pas als dat klopt, heeft het zin om te bouwen. De architectuur die het meest robuust is in de praktijk: een centrale prijsengine die realtime de inkoopprijs ophaalt, de valutakoers toepast, de klantspecifieke korting opzoekt en de verkoopprijs berekent als uitkomst. Niet als opgeslagen waarde, maar als berekend resultaat op het moment van de aanvraag. Dat geeft ook de mogelijkheid om margewaarschuwingen te tonen voordat een offerte de deur uitgaat, niet pas bij de maandafsluiting.