[Main]-Payment discount tolerance is doubled when posting a vendor payment

[DhavalMore88]

Bug 644282: [master] [ALL-E]Payment discount tolerance is doubled when posting a vendor payment

AB#644282

Issue: When posting a vendor payment that applies to multiple invoices via Applies-to ID in a foreign currency within the payment discount grace period (accepting payment discount tolerance), the payment discount tolerance amount is doubled in the resulting G/L entries. Instead of Bank = 7092.34 / Payment Discount = 144.74, the bank leg is inflated to 7381.82 and the discount sign is flipped, producing a net error of 289.48 (exactly 2× the 144.74 tolerance).

Cause: In ManagePaymentDiscToleranceWarningVendor in PaymentToleranceManagement.Codeunit.al, the else-branch correctly nets the payment amount down (7237.08 → 7092.34) across the applied invoices, but persisted it via UpdateGenJournalLineAmount only when GenJnlLineApplID = ''. Since the Applies-to ID scenario always has a non-empty ID, this guard was never satisfied (and was mutually exclusive with UpdateGenJournalLineAmount's own internal "Applies-to ID" <> '' guard), so the netted amount was discarded and the journal line stayed gross. At posting, CalcPmtDiscTolerance (codeunit 12) then posts an extra 144.74 with no liability guard, doubling the tolerance.

Solution: Removed the dead if GenJnlLineApplID = '' guard so the netted amount is always persisted to the journal line via UpdateGenJournalLineAmount (whose internal "Applies-to ID" <> '' check correctly permits it for the Applies-to ID case). Added an UpdatingGenJnlLineAmount re-entrancy guard with an early exit(true) in PmtTolGenJnl, set around the Validate("Amount")/Modify call, to prevent infinite recursion since validating Amount re-triggers PmtTolGenJnl. The customer path was left unchanged as the defect is vendor-scoped.

[github-actions]

Could not find linked issues in the pull request description. Please make sure the pull request description contains a line that contains 'Fixes #' followed by the issue number being fixed. Use that pattern for every issue you want to link.

[github-actions]

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

[github-actions]

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

ManagePaymentDiscToleranceWarningVendor now calls UpdateGenJournalLineAmount, but that helper still exits when GenJnlLine."Applies-to ID" is blank. This vendor flow can also be reached through "Applies-to Doc. No.", so the code can increase NewVendLedgEntry.Amount and continue/commit without ever updating the persisted journal line. Handle the document-number application path here, or fail explicitly instead of silently skipping the update.

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

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

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

[github-actions]

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

The new scenario wires UI handlers that hardcode LookupOK, Yes, and true, but it never queues or asserts the expected dialogs. That leaves the test unable to prove the right UI interactions fired exactly once for the bug path; drive these handlers from LibraryVariableStorage/Assert.ExpectedConfirm-style expectations and finish the test with AssertEmpty.

Knowledge:

• microsoft/knowledge/testing/ui-handlers-in-tests.md

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