[Bug][SubscriptionBilling]: "Prices Including VAT" option does not correctly update Subscription Line amounts

[miljance]

What & why

• Add EnsureCalculationBaseAmountExcludesVAT on Subscription Line table to strip VAT from Calculation Base Amount when the Sales Header has Prices Including VAT
• Add event subscriber in SalesSubscriptionLineMgmt to recalculate Sales Subscription Line amounts when Prices Including VAT is toggled on the Sales Header
• Add four tests covering: CBA equals unit price with/without PIV, recalculation on PIV toggle, and net CBA on posted Subscription Line
• Refactor test helpers: extract FindNonZeroVATPostingSetup, FindCustomerDocumentPrice- SalesServiceCommitment, SetupItemCustomerAndSalesHeaderWithVAT; replace magic VAT sentinel with explicit ReassignSalesLineToDifferentVATGroup/ReassignSalesLineToZeroVATGroup
• Add GIVEN/WHEN/THEN comments to CheckVatCalculationForServiceCommitmentRhythmInReports

Linked work

Fixes #7399

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
Followed the repro steps from #7399:

1. Created a new Sales Order for a subscription item with a non-zero VAT rate. Enabled Prices Including VAT on the header - confirmed that the Calculation Base Amount on all Sales Subscription Lines was updated to the VAT-exclusive (net) amount.
2. Toggled Prices Including VAT off again - confirmed that Calculation Base Amount reverted to the original VAT-inclusive unit price (i.e. the sales line unit price as stored).
3. Manually edited Calculation Base Amount on a Sales Subscription Line, then toggled Prices Including VAT - confirmed that the manually entered value was preserved but correctly adjusted (VAT stripped or added), not reset to the unit price.
4. Posted the Sales Order - confirmed that the resulting Subscription Line Calculation Base Amount is the net (VAT-exclusive) amount, matching the formula UnitPrice / (1 + VAT% / 100).

Risk & compatibility

None. The change adds a new procedure called only from a new event subscriber and from CreateSubscriptionLineFromSalesLine. It does not touch any existing posting logic, table schema, permissions, or upgrade code. No breaking changes.

Fixes AB#634780

[github-actions]

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

SalesSubscriptionLine.Modify called without transaction guard

In the new RecalculateSalesSubscriptionLineAmountsOnBeforeSalesLineModify event subscriber, SalesSubscriptionLine.Modify(false) is called inside a loop while processing a OnValidatePricesIncludingVATOnBeforeSalesLineModify event. If the calling transaction fails or rolls back after partial execution (e.g. on the second line), some subscription lines will have been recalculated and others will not, leaving the set in an inconsistent state.

Recommendation:

• Ensure that the loop is written to be idempotent, or verify that the calling framework guarantees transactional rollback across all record modifications in this event. Consider using a collect-then-apply pattern rather than modifying inside an event fired mid-validation.

// Collect all changes first, then apply in a single pass after validation completes
// or rely on the caller's explicit Modify after the event returns

Line mapping was unavailable, so this was posted as an issue comment.

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

[JesperSchulz]

Re-running the two failed jobs. They strike me as instabilities.