[G/L VAT Reconciliation] Make report 11 runnable in background and make commit calls as it backfills G/L Account No.

[dcenic]

AB#640489

Report 11 "G/L - VAT Reconciliation" backfills the G/L Acc. No. field on VAT Entries (resolving it from the G/L Entry - VAT Entry Link table) before it can reconcile VAT amounts against the general ledger. This PR fixes two defects in that backfill so the report can run unattended and resume after a timeout.

What & why

Problem
Could not run in the background. The backfill is gated by a confirm ("Do you want to fill the G/L Account No. field…"). The gate keyed off the WithUI flag rather than whether a UI actually exists, so in a background / job-queue session ConfirmManagement.GetResponseOrDefault returned its false default, the fill was skipped, and the report then hard-errored in CheckGLAccountNoFilled because in-scope entries were still blank. The OnBeforeSetGLAccountNo event meant to let callers pre-approve the fill was ineffective, because the confirm overwrote whatever Response a subscriber had set.

Progress was not persisted. The fill updates VAT Entries in batches of ~100 via ModifyAll, but never committed between batches. On large datasets a timed-out run lost all progress and restarted from scratch, never completing.

Fix
All changes are in VATEntry.Table.al, propagated to W1 and the 11 country copies (APAC, BE, CH, DACH, ES, FI, FR, IT, NA, NL, NO, RU) because the method is overridden per localization and the report runs against whichever localized "VAT Entry" table is deployed.

Background-safe confirm — only prompt when a GUI is present; in a background session proceed automatically. Also stop the confirm from clobbering an already-approved Response, so OnBeforeSetGLAccountNo can genuinely pre-approve:
Commit per batch — Commit() after each batch's ModifyAll, so a timed-out run resumes from where it left off. Because each batch re-applies the "G/L Acc. No." = '' filter, a re-run only processes the still-unfilled entries.
The change is safe to apply unconditionally: the fill is additive and idempotent (it only populates a blank G/L Acc. No. on entries that already have a G/L link), so committing partial progress can never produce an inconsistent state. The shared VAT Entries page action (SetGLAccountNo(false)) is unaffected by the confirm change and simply benefits from the same per-batch commit.

Linked work

Fixes AB#640489

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome (required — be specific: scenarios, commands, screenshots for UI changes)

Added SetGLAccountNoEventPreApprovalSkipsConfirm plus a manually-bound subscriber codeunit (GL VAT Recon. Adjust Subs.) that pre-approves via OnBeforeSetGLAccountNo. The test runs with no ConfirmHandler and verifies the entries are filled without a confirm being raised — which only passes because of the and not Response change; the pre-fix code would raise Confirm and fail on the unhandled dialog. Manual binding scopes the subscriber to this one test so the existing confirm-handler tests are unaffected.

Risk & compatibility

[github-actions]

Issue #640489 is not valid. Please make sure you link an issue that exists, is open and is approved.

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

The variable declaration 'VATEntry: Record 254' references table 254 by numeric ID instead of by name.

Per the referenced guidance, numeric IDs are fragile across renumbering and unreadable in diffs and stack traces. Use 'VATEntry: Record "VAT Entry"' instead.

Suggested change

	VATEntry: Record 254;
	VATEntry: Record "VAT Entry";

Knowledge:

• microsoft/knowledge/style/named-invocations-not-object-ids.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[github-actions]

Copilot PR Review

Iteration 3 · Outcome: completed

Knowledge source: https://github.com/microsoft/BCQuality@822cae1b2771ac25f665f73369f69093bd4fd630

Findings by domain

Findings split into Knowledge-backed (cite a BCQuality article) and Agent (the agent's own judgement, no matching BCQuality rule).

Domain	Findings	Knowledge-backed	Agent	Inline	Fallback
Agent	1	0	1	1	0

Totals: 0 knowledge-backed · 1 agent findings.

Orchestrator pre-filter (13 file(s) excluded)

• layer-disabled (knowledge) : 13 file(s)

_{Findings produced by the Copilot CLI agent against BCQuality at 822cae1b2771ac25f665f73369f69093bd4fd630. Reply 👎 on any inline comment to flag false positives.}

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Agent} \quad \color{gray}{\texttt{\small Iteration\ 3}}$

SetGLAccountNoEventPreApprovalSkipsConfirm calls VATEntry.SetGLAccountNo(true), which exercises the new Commit() call inside FlushBatchedGLAccountNoUpdate.

Because the test declares no [TransactionModel(...)] attribute, it runs under the default AutoRollback. The first Commit() inside the tested code will produce a runtime error rather than an assertion failure, leaving the test unable to yield a business-logic verdict. Per the referenced guidance, any test that drives code calling Commit() must carry [TransactionModel(TransactionModel::AutoCommit)]. Add the attribute above [Test] on this method. The codeunit should also be paired with a TestIsolation-enabled test runner so the committed rows are reverted between runs.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

    [TransactionModel(TransactionModel::AutoCommit)]
    [Test]

Knowledge:

• microsoft/knowledge/testing/transactionmodel-attribute-governs-test-transactions.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}