AI, in your work.

Merged into the public code

Microsoft merged BCApps PR 13725 into `main` on November 6, 2026. The pull request carries the 30.0 milestone.

The affected process serves a specific accounting purpose. Cost adjustment forwards cost changes to related entries, as explained in Microsoft’s documentation. For average costing, Business Central uses a periodic weighted average; the configured period and grouping define the calculation. Microsoft describes this in its average-cost design details.

What changes in data retrieval

The commit diff modifies codeunit 5895, Inventory Adjustment, in the W1, APAC and RU variants. Its main changes are:

• Cache `Positive` by item ledger entry number and clear the cache in `DeleteAvgBuffers`.
• Expand the field-loading lists for application chains and other subsequent operations.
• Remove two calls to the `LoadFields` helper in paths that copy value entries into temporary buffers.

What the validation establishes

The PR description retains a contradiction: its checklist marks local building and execution as completed, but the explanation says neither was performed and relies on CI. That text does not establish that local testing occurred.

Public automation evidence is available: the PR’s W1 build succeeded, and CI/CD for the merged commit reports Success. Full logs require signing in. These statuses provide no comparative performance measurement and do not constitute independent reproduction by Nexo.

Nexo’s interpretation: check which fields are needed

The AL partial-record documentation explains the mechanism: accessing an unloaded field can trigger an additional just-in-time, or JIT, read. It also warns that copying partial records into temporary records requires loading every field. Selecting fewer columns initially can lose its advantage if the next operation needs to retrieve them.

Our editorial interpretation is that the change addresses redundant data-access work. The size of any benefit needs measurement against a specific workload. Fewer reads alone also cannot establish that execution time will grow linearly as entry counts increase.

An evaluation example using synthetic data

As a Nexo proposal, a test could compare two builds that allow the change to be isolated, restoring the same data copy before each run. Configuration, extensions and resources would remain constant. A synthetic dataset would include purchases, sales, returns and item charges for average-cost items, with runs repeated at increasing volumes. This example presents no measured results.

Microsoft documents that cost adjustment logs expose duration and cost differences for each run. Investigating reads additionally requires data-access profiling.

Availability: the distributed build remains unidentified

The milestone indicates planning. The consulted sources do not identify a customer-available build containing the change. Attributing an improvement in a particular environment requires first confirming inclusion in that version and then measuring the process.