Align SalesTaxCalculate across countries

[Alexander-Ya]

What & why

Linked work

Fixes #

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)

Risk & compatibility

[github-actions]

Could not find a linked ADO work item. Please link one by using the pattern 'AB#' followed by the relevant work item number. You may use the 'Fixes' keyword to automatically resolve the work item when the pull request is merged. E.g. 'Fixes AB#1234'

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Error\ Handling}$

InitSalesTaxLines now has a duplicated outer if TaxLiable then begin guard. That makes the inner else AddedTaxAmount := 0; unreachable and also skips the shared TempTaxDetail insertion/allocation path entirely when TaxLiable = false, changing the procedure's control flow from the pre-change shape. Remove the extra outer guard so the non-taxable path still follows the common zero-amount flow.

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

                    // This code uses a temporary table to keep track of Maximums.
                    // This temporary table should be cleared before the first call
                    // to this routine.  All subsequent calls will use the values in
                    // that get put into this temporary table.

                    TempTaxDetailMaximums := TaxDetail;
                    if not TempTaxDetailMaximums.Find() then
                        TempTaxDetailMaximums.Insert();

                    if TaxLiable then begin
                        if (Abs(TaxBaseAmount) <= TaxDetail."Maximum Amount/Qty.") or
                           (TaxDetail."Maximum Amount/Qty." = 0)
                        then begin
                            AddedTaxAmount := TaxBaseAmount * TaxDetail."Tax Below Maximum" / 100;
                            TempTaxDetailMaximums."Maximum Amount/Qty." := TempTaxDetailMaximums."Maximum Amount/Qty." - Quantity;
                            TempTaxDetailMaximums.Modify();
                        end else begin
                            MaxAmount := TaxBaseAmount / Abs(TaxBaseAmount) * TaxDetail."Maximum Amount/Qty.";
                            AddedTaxAmount :=
                              ((MaxAmount * TaxDetail."Tax Below Maximum") +
                               ((TaxBaseAmount - MaxAmount) * TaxDetail."Tax Above Maximum")) / 100;
                            TempTaxDetailMaximums."Maximum Amount/Qty." := 0;
                            TempTaxDetailMaximums.Modify();
                        end;
                    end else
                        AddedTaxAmount := 0;
                    TaxAmount := TaxAmount + AddedTaxAmount;
                    TempTaxDetail := TaxDetail;
                    TempTaxDetail."Tax Below Maximum" := AddedTaxAmount;
                    TempTaxDetail."Tax Above Maximum" := TaxBaseAmount;
                    TempTaxDetail.Insert();
                    RemainingTaxDetails := RemainingTaxDetails + 1;

_{Agent judgement — not directly backed by a BCQuality knowledge article.}

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

[github-actions]

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

This branch updates only the first TempTaxDetail row and never calls Next(), so FindSet(true) is doing multi-row iteration setup for a single-record access. Use FindFirst() here and keep Modify() on that one record.

Suggested change

	if TempTaxDetail.FindSet(true) then begin
	if TempTaxDetail.FindFirst() then begin

Knowledge:

• microsoft/knowledge/performance/pair-findset-with-next-loop.md

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

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Privacy}$

The new "Expense/Capitalize" field is a Normal table field with no explicit DataClassification, so it remains implicitly unclassified at field scope. BCQuality's privacy guidance and AS0016 require every Normal field to declare its own non-"ToBeClassified" classification.

Knowledge:

• microsoft/knowledge/privacy/table-level-data-classification-cascades.md

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

[github-actions]

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

Both renamed labels still contain multiple placeholders but no Comment, so translators have no canonical meaning for %1-%6 when localizing these errors.

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

        MissingTaxAreaValuesErr: Label '%1 in %2 %3 must be filled in with unique values when %4 is %5.', Comment = '%1 = Calculation Order field caption, %2 = Tax Area table caption, %3 = Tax Area code, %4 = Calculate Tax on Tax field caption, %5 = Boolean value of Calculate Tax on Tax.';
        SalesTaxAmountIncorrectErr: Label 'The sales tax amount for the %1 %2 and the %3 %4 is incorrect. The calculated sales tax amount is %5, but was supposed to be %6.', Comment = '%1 = Tax Area Code value, %2 = Tax Area Code field caption, %3 = Tax Group Code value, %4 = Tax Group Code field caption, %5 = Calculated sales tax amount, %6 = Expected sales tax amount.';

Knowledge:

• microsoft/knowledge/style/label-comment-explains-placeholders.md

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