AI, in your work.

Why rows can remain after posting

Inventory follows several steps on its way to the general ledger. Business Central records changes in value in value entries and posts their costs to the general ledger to reconcile the two ledgers. This distinction helps explain why a row awaiting processing does not necessarily represent an amount still awaiting posting. Microsoft documentation.

BCApps commit 184c24a addresses residual records in table 5811, Post Value Entry to G/L. According to its description, mark-based deletion could leave processed rows behind when delete subscribers or Change Log were involved. Microsoft links this accumulation to slower runs and possible errors; the source provides no broadly applicable measurement of the improvement. Original commit.

What changes in processing

Report 1002, Post Inventory Cost to G/L, collects processed identifiers in a temporary table and deletes through filters. It also handles removal of references without a value entry and certain skipped rows whose costs are already posted. Queue deletion depends on the Post option being enabled; running without posting preserves its rows. Report 1002 code.

The eligibility check compares actual costs in local and additional reporting currency; it includes expected costs when their posting to the general ledger is enabled. The OnAfterIsFullyPostedToGL event lets an extension change the result. Filters group consecutive numbers without including gaps. Table 5811 code.

Inspect before cleaning up

The new page 5813 displays references and amounts in a list that prevents direct editing, insertion or deletion of rows. Its cleanup action passes the list's filters to the corresponding report. Page code.

Report 5813 includes Count only to count eligible rows without deleting them. Cleanup processes batches of up to 1,000 candidates and commits each batch. Deletion targets queue table 5811: it does not remove value entries or general ledger entries. Cleaning up residual references therefore does not replace reconciliation. Cleanup report code.

Synthetic examples for interpreting the queue

These examples illustrate the reviewed logic; they are not observed results. They assume no differences in expected costs or additional reporting currency, and no extension changing the eligibility decision.

Integration, tests and availability

The PR was merged into main on 6 November, and GitHub reports 172 checks passed. It is assigned to the Version 30.0 milestone. Although the description retains a warning that compilation and execution are pending, later evidence confirms integration. That checks summary alone does not detail execution of every scenario or establish deployment to customers. PR 13442.

The test code includes non-consecutive records, preservation of interleaved references and costs outstanding only in additional reporting currency. Their presence documents intended scenarios; this editorial review has not run Business Central. SCM Inventory Reports - III tests.

Nexo's interpretation: separating volume from unposted costs

Our interpretation is that the change's value lies in helping finance and development teams diagnose the situation together: separating outstanding accounting work from references that no longer contribute work to the process.

As a proposed validation exercise, once a version containing the change is confirmed, compare counts, retained rows and amounts before and after processing in a test environment. The matrix should alternate Post and Count only, enable and disable expected cost posting, and include extensions involved in deletion. The objective would be to verify that cleanup preserves all outstanding costs and respects filters, without assuming a proven performance benefit.