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

[DeepsShukla]

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

Fixes AB#648334

Issue: Mismatch between Purchase Invoice Total in Lines and Statistics after VAT adjustment.
Cause: VAT Amount on the Purchase Invoice subform didn't reflect manual VAT adjustments from Statistics when mixed VAT groups were used.
Solution: It gets fixed by recalculating grouped VAT via CalcVATAmountLines (only when a "VAT Difference" exists on the lines) and overriding the subform totals to match.

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Request Changes

What this PR does

The reported bug is a mismatch between the purchase invoice line totals and the statistics totals after a manual VAT adjustment on mixed VAT groups with negative lines. The change recalculates grouped VAT for purchase subpage totals when VAT Difference exists, and it adds a regression test for that purchase invoice flow.

The core idea matches the failing path because the statistics page already uses grouped VAT amount lines, while the subpage previously used the line-summed Amount Including VAT - Amount. However, the new grouped calculation is built from a fresh Purchase Line record and can ignore the line filters that the existing total calculation already applied before the public event hook returns. That can mix a filtered line amount with an unfiltered VAT amount.

Problem-solution fit

Fit: Partial

The change targets the described mismatch and covers the main purchase invoice scenario with a test. It still needs to keep the grouped VAT calculation aligned with the same purchase-line recordset used for the rest of the subpage totals.

Suggestions

S1 (🔴 High): Reuse the filtered purchase lines
Pass the already filtered purchase-line record into GetGroupedVATAmount, or copy those filters before calling CalcVATAmountLines. The current helper starts from a new Purchase Line record, so it can calculate VAT for the whole document while TotalPurchaseLine2.Amount was calculated from a filtered line set. This can show a wrong total for extensions that narrow the line set through the existing subpage-total event.

S2 (🟠 Moderate): Avoid zero VAT adjustment in the test
Use a non-zero lower bound for VATAdjustment. With RandDecInRange(0, MaxVATDifference, 2), the test can choose �.00 and pass without exercising the new VAT Difference path.

Risk assessment and necessity

Risk: This is purchase VAT and total calculation code in W1, NA, and BE, so a wrong result affects visible invoice totals and can confuse posting checks. The change is narrow and has no separate event-publisher dependency, but it sits behind public total-calculation events and must preserve their filtered recordset semantics.

Necessity: The scenario is important because the line totals should match the statistics totals after an allowed manual VAT adjustment. Recomputing grouped VAT is justified, but it should use the same scoped lines as the existing calculation.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=10798 round=1 by=alexei-dobriansky at=2026-08-31T06:15:03Z lastSha=68df5bc8bedf3d95eed696606c634702062ad2c4 reviewKey=081c465a187148a59c9315428f9f34dd9a9a9b6fc96ba3f6acc5033d185e1b28 suggestions=S1@87850e63,S2@490329e2

[github-actions]

⚠️ Stale Status Check Deleted

The Pull Request Build workflow run for this PR was older than 72 hours and has been deleted.

📋 Why was it deleted?

Status checks that are too old may no longer reflect the current state of the target branch. To ensure this PR is validated against the latest code and passes up-to-date checks, a fresh build is required.

---

🔄 How to trigger a new status check:

1. 📤 Push a new commit to the PR branch, or
2. 🔁 Close and reopen the PR

This will automatically trigger a new Pull Request Build workflow run.