Waarom automatische kostenherwaardering in Business Central systemen vastzet en locking veroorzaakt
Het lijkt logisch om kostenherwaardering automatisch te laten uitvoeren in Business Central. Het systeem corrigeert immers kostprijzen zodra nieuwe informatie beschikbaar komt. Bijvoorbeeld een factuur die later binnenkomt of een productvariant die pas na afloop bekend wordt. Toch blijkt in de praktijk dat automatische kostenherwaardering in Business Central een van de grootste oorzaken van locking en prestatieproblemen is. Om te begrijpen waarom dat zo is, moeten we kijken naar hoe het mechanisme technisch werkt. Waarom grijpt het zo diep in de transactieketen.
Hoe kostenherwaardering en locking in Business Central ontstaan
Kostenherwaardering is een waarderingsproces dat de volledige transactieketen van een artikel opnieuw doorrekent. Wanneer kosten veranderen, bepaalt Business Central welke transacties door die wijzigingen invloed hebben. Dat gebeurt door drie onderliggende datastructuren te analyseren: de Item Ledger Entries, die de fysieke bewegingen van artikelen vastleggen; de Value Entries, die de financiële waardes bevatten; en de Item Application Entries, die de relaties tussen inkoop, verkoop, productie en verbruik beschrijven. Deze tabellen vormen samen een netwerk van transacties dat door de tijd heen met elkaar verbonden is. Cost adjustment doorloopt dat netwerk om te bepalen waar kosten moeten worden doorgegeven.
Het algoritme werkt iteratief. Het scant eerst alle waarde‑entries om te bepalen welke kosten nog niet volledig zijn doorgegeven. Vervolgens volgt het de applicatie‑entries om te achterhalen welke transacties afhankelijk zijn van elkaar. Daarna boekt het nieuwe waarde‑entries om kosten door te geven naar gerelateerde transacties. Het zet voorlopige kosten om in definitieve kosten zodra alle informatie beschikbaar is en verdeelt productievariances over de juiste transacties. Dit proces kan meerdere rondes nodig hebben voordat alle kosten volledig zijn verwerkt, omdat nieuwe informatie steeds opnieuw invloed kan hebben op eerdere transacties.
Meer weten over deze datastructuren? Lees verder over Item Ledger Entries, Value Entries en Item Application Entries.
Waarom kostenherwaardering en locking in Business Central elkaar versterken
De reden dat kostenherwaardering soms terug in de tijd moet kijken, ligt in de manier waarop Business Central kosten definitief maakt. Een inkoop kan bijvoorbeeld op 1 januari zijn geboekt, terwijl de verkoop van die goederen op 5 januari plaatsvond. Als de factuur pas op 20 januari binnenkomt en een hogere prijs bevat, moet het systeem die hogere kosten alsnog doorgeven aan de voorraad, de verkoop, de COGS en de marge. Dat betekent dat historische entries opnieuw moeten worden geopend en gecorrigeerd. Dit retroactieve karakter maakt cost adjustment technisch zwaar.
Wanneer Automatic Cost Adjustment op “Always” staat, probeert Business Central deze volledige waarderingsketen uit te voeren tijdens het boeken van een transactie. Tijdens het boeken van een verkoop, inkoop of productieboeking start Business Central een complexe herwaarderingsoperatie. Onder andere. Het systeem opent historische transacties, corrigeert de kosten en schrijft nieuwe waardes weg. Terwijl het deze keten doorloopt, lockt het de betrokken tabellen. Het systeem houdt Item Ledger Entries vast tijdens het berekenen van correcties, blokkeert Value Entries terwijl het nieuwe waardes aanmaakt en vergrendelt Item Application Entries terwijl het de transactiekoppelingen volgt. Wanneer Automatic Cost Posting is ingeschakeld, lockt het bovendien de grootboektabellen terwijl het de gecorrigeerde kosten direct probeert te boeken.
In SQL‑termen leidt dit tot een combinatie van range locks, update locks, shared locks en intent locks op de belangrijkste tabellen van Business Central. In een omgeving met veel gelijktijdige transacties ontstaat hierdoor een kettingreactie van blocking, deadlocks en time‑outs. Magazijnprocessen lopen vast, verkooporders blijven hangen en gebruikers merken dat het systeem traag en onvoorspelbaar reageert. Niet de transacties zelf veroorzaken deze vertraging, maar het feit dat Business Central cost adjustment realtime uitvoert terwijl gebruikers tegelijkertijd nieuwe boekingen proberen te verwerken.
De oplossing: taakwachtrijposten instellen
Wanneer Business Central kostenherwaardering via een job queue uitvoert, lost het het locking‑probleem vrijwel volledig op. Het systeem doorloopt de volledige waarderingsketen sequentieel, op een moment waarop niemand transacties boekt, waardoor er geen concurrentie ontstaat tussen gebruikers en het herwaarderingsproces. SQL kan efficiënt indexen gebruiken en er is geen concurrentie tussen gebruikers en het waarderingsproces. Cost posting kan direct daarna draaien, zonder dat het grootboek wordt geblokkeerd door actieve transacties.
Microsoft benadrukt in de documentatie dat cost adjustment een intensief proces is dat gepland moet worden en niet bedoeld is om realtime tijdens transacties te draaien. Het mechanisme is ontworpen als batchproces, niet als onderdeel van de transactieroutine. De technische best practice is daarom glashelder: je schakelt automatische cost adjustment uit, je zet automatische cost posting uit, en je laat beide processen ’s nachts via job queues draaien. Door die keuze blijft Business Central tijdens kantooruren snel en stabiel, terwijl het systeem elke nacht alle financiële waardes volledig bijwerkt.
Conclusie
Kostenherwaardering is een waarderingsalgoritme dat afhankelijk is van historische data, transactieketens, costing methods, variances en facturen. Het is een complex proces dat alleen betrouwbaar en performant werkt wanneer het batchgewijs wordt uitgevoerd. Inline draaien leidt onvermijdelijk tot locking. Batchverwerking voorkomt dat volledig en zorgt ervoor dat Business Central stabiel blijft, zelfs bij hoge transactiesnelheid.
Wil je meer weten over dit onderwerp. Kijk dan hier. Wil je contact opnemen met mij, klik dan hier.
