Bug 643235: Payment Reconciliation Journal does not round imported bank fee amounts#9673
Conversation
f7f33bd to
3eec1d6
Compare
github-actions
Bot
added
the
Build: scripts & configs
This reverts commit 7df0f8a.
github-actions
Bot
removed
the
Build: scripts & configs
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| GenJnlLine.Validate("Currency Code", BankAcc."Currency Code"); | ||
| GenJnlLine.Amount := -PaymentLineAmount; | ||
| Currency.Initialize(GenJnlLine."Currency Code"); | ||
| GenJnlLine.Amount := Round(-PaymentLineAmount, Currency."Amount Rounding Precision"); |
There was a problem hiding this comment.
Rounding GenJnlLine.Amount here changes a shipped runtime contract: the amount exposed through OnPostPaymentApplicationsOnBeforeValidateApplyRequirements / OnPostPaymentApplicationsOnAfterPostGenJnlLine and the posted G/L entry no longer match previous releases for the same input. Preserve the legacy value for existing subscribers, or introduce a new opt-in event/path for rounded posting, so dependent extensions do not silently change behavior.
Agent judgement — not directly backed by a BCQuality knowledge article.
👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.15.4
| GLEntry.SetRange("Document Type", GLEntry."Document Type"::Payment); | ||
| GLEntry.SetRange("Document No.", DocNo); | ||
| GLEntry.SetRange("G/L Account No.", AccNo); | ||
| GLEntry.FindFirst(); |
There was a problem hiding this comment.
The new VerifyGLEntrySourceCurrencyAmount helper reads only Source Currency Code and Source Currency Amount from G/L Entry, but the added FindFirst() call materializes the full row because no SetLoadFields() is set first.
Suggested fix (apply manually — could not be anchored as a one-click suggestion):
GLEntry.SetLoadFields("Source Currency Code", "Source Currency Amount");
GLEntry.FindFirst();Knowledge:
👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.15.4
| // [THEN] "Account No." in Gen. Journal Line is not blank in GeneralJournalPageHandler. | ||
| end; | ||
|
|
||
| [Test] |
There was a problem hiding this comment.
The four new PaymentReconciliation* tests invoke a HandlerFunctions-based UI flow without enqueueing the expected dialog interactions or finishing with LibraryVariableStorage.AssertEmpty, so the dialog contract is never verified and an unexpected or extra UI interaction can still leave the tests green. Note: this reuses the pre-existing PostAndReconcilePageHandler/PostAndReconcilePageStatementDateHandler pair, which is already invoked with the same hardcoded-reply pattern by 14 other existing tests in this same codeunit, so this is a pre-existing convention gap rather than a pattern newly introduced by this PR.
Knowledge:
👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.15.4
1 participant
ISSUE:
Payment Reconciliation Journal posting fails when an imported bank fee amount does not match the configured amount rounding precision.
CAUSE:
The imported application amount is copied to the general journal without rounding, so general journal posting rejects it.
SOLUTION:
Round payment reconciliation amounts according to the posting currency's amount rounding precision before posting.
TESTS:
Added coverage for LCY rounding, foreign-currency precision, already rounded amounts, and midpoint rounding.
Fixes AB#643235