Skip to content

[Master]-]G/L Account Sheet with Foreign Currency report (11564) includes LCY-originated entries after enabling G/L currency revaluation feature resulting in mixed-currency totals in the Swiss version. - Copy - #10041

Open
neeleshsinghal wants to merge 1 commit into
mainfrom
bugs/Bug-642513-G/L-Account-Sheet-with-Foreign-Currency-includes-LCY

Conversation

@neeleshsinghal

@neeleshsinghal neeleshsinghal commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

@neeleshsinghal
neeleshsinghal requested a review from a team August 7, 2026 08:33
@github-actions github-actions Bot added the Finance GitHub request for Finance area label Aug 7, 2026
@github-actions github-actions Bot added this to the Version 29.0 milestone Aug 7, 2026
Comment thread src/Layers/CH/Tests/Local/TestGLAccSheetReports.Codeunit.al
Comment thread src/Layers/CH/Tests/Local/TestGLAccSheetReports.Codeunit.al
@alexei-dobriansky

Copy link
Copy Markdown
Contributor

Agentic PR Review - Round 1

Recommendation: Accept

What this PR does

Report 11564 "SR G/L Acc Sheet Foreign Curr" was accumulating Source Currency Amount from every G/L Entry regardless of whether the entry's Source Currency Code matched the G/L Account's Source Currency Code. After enabling the G/L currency revaluation feature, LCY-originated entries (with a blank Source Currency Code) and entries posted in a different currency were being mixed into the foreign currency totals, producing incorrect balances.

The fix wraps the three assignments (FcyAcyAmt, FcyAcyBalance, Exrate) in a guard that only runs when the entry's Source Currency Code is non-blank and equals the G/L Account's Source Currency Code. The else branch zeroes out FcyAcyAmt and Exrate for the current row but leaves FcyAcyBalance unchanged (nothing is added for a mismatched entry, so the running total stays correct). OnAfterOnAfterGetRecord remains outside the if/else and fires for every entry as before. The logic is parallel to the same guard already present in the Gen. Journal Line dataitem. The new test verifies that entries in two different currencies on an account with no specific source currency produce zero FCY amounts and a zero running balance.

Suggestions

No suggestions.

Risk assessment and necessity

Risk: Low and isolated. The change is inside OnAfterGetRecord of the G/L Entry dataitem of report 11564, which is a Swiss-layer-only report. The condition short-circuits to the else branch only when the entry's source currency does not match the account's; previously posted entries and existing tests (GLSheetForeignCurrFCYBalance, GLSheetForeignCurrLCYBalance) are not affected because those scenarios use an account whose source currency matches the entry. The OnAfterOnAfterGetRecord integration event signature is unchanged.

Necessity: The bug is triggered in production when the G/L currency revaluation feature is on, causing mixed-currency totals that are clearly wrong. The fix is minimal, targeted, and mirrors the pattern already used for the provisional journal-line section of the same report.


[AI-PR-REVIEW] version=1 promptVersion=1 system=github pr=10041 round=1 by=alexei-dobriansky at=2026-08-07T12:07:14Z lastSha=70b751bc6dca16856d6bf68438eea139d53f0ba0 reviewKey=9a29ae6b7a19b21c25fb8f46c2e6db27ff3df3c7b1d6f548f3d1c28d0f400aec suggestions=

FcyAcyAmt := "Source Currency Amount";
FcyAcyBalance := FcyAcyBalance + "Source Currency Amount";
Exrate := CalcExrate("Source Currency Amount", Amount, "G/L Account"."Source Currency Code");
if ("Source Currency Code" <> '') and ("Source Currency Code" = "G/L Account"."Source Currency Code") then begin

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$\textbf{🟡\ Medium\ Severity\ —\ Breaking\ Changes}$

Report 11564 now zeros FcyAcyAmt/Exrate (and therefore leaves the running foreign-currency balance at zero) for every G/L account whose "Source Currency Posting" is "Multiple Currencies", because those accounts keep "Source Currency Code" blank (per GLAccount.Table.al field 20, that field only holds a value for "Same Currency" posting). This is a shipped behavior change for existing CH customers: entries that previously populated the foreign-currency columns will disappear from the report after upgrade, which can break established reconciliations or exports built against the previous output. Consider preserving prior output for registered multi-currency accounts (e.g. by checking membership in "G/L Account Source Currency" rather than only equality with the single "Source Currency Code" field), or call out the behavior change explicitly in release notes.

👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.31.4


LibraryERM.CreateGLAccount(BalGLAccount);

// [GIVEN] An entry posted in "CurrencyCode" ...

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

The new test's comment states it covers entries "including LCY-originated entries", but the fixture only posts two lines with non-blank (foreign) currency codes on a Multiple-Currencies account. The blank/LCY Source Currency Code branch of the new condition is never exercised, so a regression that lets LCY-originated entries leak back into the FCY totals would not be caught by this test. Either add a posted line with a blank Currency Code to the fixture, or narrow the test's scenario comment to match what it actually verifies (mismatched foreign-currency entries only).

👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.31.4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Finance GitHub request for Finance area

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants