Impact automatische kostenaanpassing met Business Central

Bij het werken met Business Central-omgevingen met een hoog volume in een SaaS-omgeving, is een van de meest over het hoofd geziene prestatieknelpunten het proces van automatische cost adjustment. Deze blogpost gaat over het diagnosticeren van de prestatie impact van automatische kostenaanpassing met behulp van KQL.

Vooral in intercompany-intensieve omgevingen kan dit achtergrondproces stilletjes je systeem overbelasten — waardoor wachtrijen van taken zich opstapelen en gebruikers vertragingen ervaren.

In deze post laten we zien hoe je met behulp van de Kusto Query Language (KQL) de impact van automatische kostenaanpassingen kunt identificeren en visualiseren via Application Insights-telemetrie.

Filter op Cost Adjustment-records

let _startTime = datetime(2025-05-20T08:30:00Z);
let _endTime = datetime(2025-05-20T17:00:00Z);
let _aadTenantId = "84d30a91-7218-4db6-b27d-acc36edf7c3d";
let _environmentName = "Production";
let _environmentType = "Production";
traces
| where timestamp between (_startTime.._endTime)
| where customDimensions.aadTenantId == _aadTenantId
| where customDimensions.environmentType == _environmentType
| where customDimensions.environmentName == _environmentName
| where severityLevel > 0
| extend messageText = tostring(message)
| where messageText has "cost adjust" or messageText has "cost adjustment" or messageText has "automatic cost"
| extend company = tostring(customDimensions.companyName)

Dit geeft het aantal records waarbij de telemetrie aangeeft dat automatische kostprijsberekening actief was als gevolg van een wijziging in de voorraad.

Zoals je kunt zien, is de automatische kostenaanpassing op één dag maar liefst 7593 keer uitgevoerd. We kunnen deze ook per bedrijf opsplitsen om meer inzicht te krijgen.

Wat is automatische kostenaanpassing?

Je kunt de kostenaanpassing op twee manieren uitvoeren:

1. Handmatig, door het uitvoeren van de batchtaak Kosten aanpassen – Artikelposten (Adjust Cost – Item Entries). Je kunt deze taak uitvoeren voor alle artikelen, of alleen voor specifieke artikelen of artikelcategorieën. Deze batchtaak voert een kostenaanpassing uit voor de artikelen in voorraad waarvoor een inkomende transactie is geboekt, zoals een inkoop. Voor artikelen met de kostprijsberekeningsmethode “gemiddeld” past de batchtaak ook kosten aan wanneer er uitgaande transacties plaatsvinden.
2. Automatisch, door kosten aan te passen telkens wanneer je een voorraadtransactie boekt of wanneer een productieorder wordt afgerond. De kostenaanpassing wordt dan alleen uitgevoerd voor de specifieke artikelen die door de boeking zijn beïnvloed. Dit stel je in door het selectievakje Automatische kostenaanpassing (Automatic Cost Adjustment) in te schakelen op de pagina Voorraadinstellingen (Inventory Setup).

Het is een goede praktijk om kosten automatisch aan te passen tijdens het boeken, omdat de stukprijzen dan frequenter worden bijgewerkt en dus nauwkeuriger zijn. Het nadeel is dat dit de prestaties van de database kan beïnvloeden, omdat de kostenaanpassing dan veel vaker wordt uitgevoerd.

Omdat het belangrijk is om de stukprijs van een artikel actueel te houden, wordt aanbevolen om de batchtaak Kosten aanpassen – Artikelposten zo vaak mogelijk uit te voeren, bij voorkeur buiten werktijden. Een alternatief is het gebruik van automatische kostenaanpassing. Zo blijft de stukprijs dagelijks actueel.

Impact automatische cost adjustment bij Business Central

Of je nu handmatig of automatisch kosten aanpast, het effect is hetzelfde. Business Central berekent de waarde van de inkomende transactie en draagt deze kosten over naar uitgaande transacties, zoals verkopen of verbruik, die aan de inkomende transactie zijn gekoppeld. De kostenaanpassing genereert waardeposten die zowel het aanpassingsbedrag bevatten als eventuele afrondingsverschillen corrigeren.

De nieuwe waardeposten voor aanpassing en afronding krijgen de boekingsdatum van de bijbehorende factuur. Uitzonderingen zijn wanneer deze waardeposten vallen in een afgesloten boekhoudperiode of voorraadperiode, of als de boekingsdatum eerder is dan de datum in het veld Boeken toestaan vanaf op de pagina Algemene grootboekinstellingen. In dat geval wijst de batchtaak de eerste dag van de volgende open periode toe als boekingsdatum.

Praktijkscenario impact automatische cost adjustment met KQL

In een scenario waar ik aan werkte, had een bedrijf enkele nevenvestigingen. De hoofdvestiging was verantwoordelijk voor het voorraadbeheer. Via stamgegevensbeheer werden de artikelen naar de vestigingen gekopieerd. Door middel van job queues werden inkoop- en verkooporders automatisch aangemaakt en gesynchroniseerd.

De voorraadniveaus bij de vestigingen stonden daardoor altijd op nul, terwijl de hoofdvestiging de voorraad correct beheerde.

In dit scenario was het niet aan te raden om automatische kostenaanpassing op “Altijd” (Always) in te stellen, omdat telemetrie de volgende gebeurtenissen liet zien die wezen op overbelasting van het systeem.

Telemetry

timestamp:	2025-05-20 12:01:55.810
message:	Operation exceeded time threshold (SQL query)
alDetailedErrorMessage:	
severityLevel:	2
eventId:	RT0005
alObjectId:	472
alStackTrace:	AppObjectType: Table
  AppObjectId: 472
  AL CallStack: "Job Queue Entry"(Table 472).ActivateNextJobInCategory line 11 - Base Application by Microsoft version 26.0.30643.34008
"Job Queue Entry"(Table 472).ActivateNextJobInCategory line 8 - Base Application by Microsoft version 26.0.30643.34008
"Job Queue Activate Next"(CodeUnit 462).OnRun(Trigger) line 2 - Base Application by Microsoft version 26.0.30643.34008
"Job Queue Entry"(Table 472).ActivateNextJobInCategoryIfAny line 9 - Base Application by Microsoft version 26.0.30643.34008
"Job Queue Dispatcher"(CodeUnit 448).OnRun(Trigger) line 25 - Base Application by Microsoft version 26.0.30643.34008
extension:	Microsoft
customDimensions:	{
  "component": "Dynamics 365 Business Central Server",
  "alObjectId": "472",
  "extensionPublisher": "Microsoft",
  "alObjectType": "Table",
  "eventId": "RT0005",
  "telemetrySchemaVersion": "0.5",
  "extensionName": "Base Application",
  "companyName": "CompanyA",
  "environmentName": "Production",
  "componentVersion": "26.0.33865.0",
  "clientType": "Background",
  "extensionVersion": "26.0.30643.34008",
  "aadTenantId": "84d30a91-7218-4db6-b27d-acc36edf7c3d",
  "alObjectName": "Job Queue Entry",
  "extensionId": "437dbf0e-84ff-417a-965d-ed2bb9650972",
  "environmentType": "Production",
  "sqlStatement": "SELECT...
}

Je kunt de informatie over het evenement hier eenvoudig bekijken.

1. Stel Automatische Kostenaanpassing in op “Nooit”
   
   Elke keer dat een inkooporder wordt geboekt, probeert het systeem anders onmiddellijk de kostprijzen van gerelateerde artikelen en transacties aan te passen. Bij veel transacties leidt dit tot prestatieproblemen, vertragingen en mogelijk vergrendelingen.
   
   Aanbevolen alternatief: Plan een periodieke taak in (bijvoorbeeld ’s nachts of buiten piekuren) die de batchtaak “Kosten aanpassen – Artikelposten” uitvoert.
2. Gebruik een batchtaak voor kostenaanpassing. Voer de taak “Kosten aanpassen – Artikelposten” (codeunit 5895) regelmatig uit als job queue, bijvoorbeeld:
   • Daily at night
   • After completing a batch of purchase order processing.
     This keeps costs accurate without putting real-time load on your system.
3. Be cautious with FIFO/LIFO/Standard Costing
   Especially with FIFO or LIFO costing models, it’s crucial to continue adjusting costs accurately via the batch job, since later sales are linked to earlier purchase prices.
4. Inform users about delays in cost prices
   Since costs are not adjusted immediately, users may temporarily see incorrect cost prices in reports. This is normal behavior as long as the batch job has not yet been executed.

Het visualiseren van de impact van automatische kostprijsaanpassing

We kunnen het bovenstaande ook visualiseren via KQL. De query ziet er dan als volgt uit en toont de impact van automatische kostenaanpassing.

// Customer Name: Contoso
// Tenant Id 84d30a91-7218-4db6-b27d-acc36edf7c3d
let _startTime = datetime(2025-05-19T07:00:00Z);
let _endTime = datetime(2025-05-20T23:59:00Z);
let _aadTenantId = "84d30a91-7218-4db6-b27d-acc36edf7c3d";
let _environmentName = "Production";
let _environmentType = "Production";
traces
| where timestamp between (_startTime.._endTime)
| where customDimensions.aadTenantId == _aadTenantId
| where customDimensions.environmentType == _environmentType
| where customDimensions.environmentName == _environmentName
| where severityLevel > 0
| extend messageText = tostring(message)
| where messageText has "cost adjust" or messageText has "cost adjustment" or messageText has "automatic cost"
| project 
    timestamp,
    message,
    alDetailedErrorMessage = customDimensions.alDetailedErrorMessage,
    severityLevel,
    eventId = customDimensions.eventId,
    alObjectId = customDimensions.alObjectId,
    alStackTrace = customDimensions.alStackTrace,
    extension = customDimensions.extensionPublisher,
    company = customDimensions.companyName
|summarize count() by bin(timestamp, 1h)
| render timechart

En de lijngrafiek. Het is helaas niet mogelijk om in Kusto Explorer de X-as en Y-as een naam te geven, maar we geven hier het aantal automatische kostenaanpassingen weer, samengevat per uur binnen een tijdsbestek van één dag. Zo kun je eenvoudig zien hoeveel impact automatische kostenaanpassing op de omgeving kan hebben.

Meer informatie over Business Central is te vinden hier.