[Main]- Mismatch between Purchase Invoice Total in Lines and Statistics after VAT adjustment

[DeepsShukla]

Workitem Bug 642172: [master] [all-e]Mismatch between Purchase Invoice Total in Lines and Statistics after VAT adjustment.

Fixes AB#642172

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Performance}$

TryGetGroupedVATAmount rebuilds grouped VAT by calling CalcVATAmountLines over the full document, and this helper is now invoked from both PurchaseDeltaUpdateTotals (the incremental/delta update path) and CalculatePurchaseSubPageTotals. Because it runs unconditionally on every line edit rather than only for the mixed-VAT-groups-on-one-G/L-account scenario the fix targets, each delta update can trigger an extra full Purchase Line scan and VAT regrouping pass, defeating the purpose of the 'delta' optimization.

Recommendation:

• gate the recomputation to cases where it is actually needed (e.g. detect mixed VAT groups on the same account) or cache/reuse the grouped result instead of recalculating on every call.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Testing}$

CreatePurchLineWithGLAccAndVATSetup assigns PurchaseLine."VAT Bus. Posting Group" directly while building the fixture. That bypasses the field's TableRelation and OnValidate logic, so the test data can drift from production behavior when VAT setup validation changes.

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

        PurchaseLine.Validate("VAT Bus. Posting Group", VATPostingSetup."VAT Bus. Posting Group");

Knowledge:

• microsoft/knowledge/testing/use-library-codeunits-for-test-fixtures.md

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

[alexei-dobriansky]

Agentic PR Review - Round 1

Recommendation: Request Changes

What this PR does

This PR recalculates purchase document totals from grouped VAT amount lines after a VAT amount is changed on the Purchase Statistics page. The main W1 scenario is valid and the new W1 test targets the reported mixed-VAT purchase invoice case, but the same change was copied into BE where Document Totals has extra reverse-charge and non-deductible VAT adjustments. The new grouped VAT overwrite runs after those adjustments and can undo them, so the fix is not safe for all changed layers.

Suggestions

S1 - Preserve BE VAT total adjustments
In src/Layers/BE/BaseApp/Utilities/DocumentTotals.Codeunit.al, the new grouped VAT overwrite runs after the BE code subtracts reverse charge VAT and adjusts non-deductible VAT. Keep those BE adjustments when replacing VATAmount, or limit the new grouped calculation to the W1-style path. Otherwise BE purchase documents can show the wrong Total VAT and Total Incl. VAT.

S2 - Fix the new variable order warning
The new test declares PurchaseInvoicePage between Record variables. Move the TestPage variable after the Record variables so AA0021 is not raised. The W1 build currently fails because this PR introduces that warning.

Risk assessment and necessity

Risk: The touched code is in purchase document totals, so the regression surface is financial UI totals for purchase invoices and related purchase documents. The BE layer is higher risk because its existing reverse-charge and non-deductible VAT logic is overwritten by the new generic grouped VAT value. CI also shows W1 build failures from a new analyzer warning.

Necessity: The bug is valid: after a manual VAT adjustment, the line totals should match the Purchase Statistics total that posting uses. The scope is reasonable for W1 and NA, but the BE copy must preserve local VAT rules before this can be merged.

---

[AI-PR-REVIEW] version=1 promptVersion=2 system=github pr=10178 round=1 by=alexei-dobriansky at=2026-08-12T14:57:55.7182996Z lastSha=1e33fb1cbe86dbde93b67dbbc15694f1b9bc512f reviewKey=ad0d8bc45a180be57d8ad56f049c86476aa0b2d81e86fc3e0d458d70b5dfd6d3 suggestions=S1@415589dd,S2@7db6ff2a