[Main]Intercompany posting shows incorrect Source Currency Amount on IC control account when G/L Revaluation is enabled in multicurrency scenarios.

[sanjmaurya]

Bug 641511: [master] [all-e]Intercompany posting shows incorrect Source Currency Amount on IC control account when G/L Revaluation is enabled in multicurrency scenarios.

Fixes AB#641511

Issue :- Posting an IC journal line (e.g. 38,500.00 JPY in a GBP functional-currency company) stores the correct source-currency amount on the primary G/L account entry, but the IC control (balancing) account entry shows a rounded-off value like 38,500.23.

Root cause: In GenJnlPostLine.Codeunit.al, the primary account entry (PostGLAcc) stores the entered source-currency amount, but the balancing entry (PostICPartner/PostBankAcc → CreateGLEntryBalAcc) discarded the entered amount and recomputed it by converting the already-rounded LCY amount back to the source currency (CalcAmountSrcCurr). That round-trip conversion introduced the rounding deviation.

Solutions :- In CreateGLEntryBalAcc, when the line has a source currency code, use the entered GenJnlLine."Source Currency Amount" directly (matching the primary-entry behavior) rather than reconverting from LCY. The Exchange Acc. G/L Journal Line codeunit already sets this field to the correctly-signed transaction amount for the balancing side, so the sign remains consistent.

The change compiles with no errors. I recommend adding/running a posting test that verifies the IC control account's Source Currency Amount equals the entered transaction amount in a multicurrency IC scenario to lock in the fix.

[github-actions]

Copilot PR Review

Iteration 4 · Outcome: completed

Knowledge source: https://github.com/microsoft/BCQuality@822cae1b2771ac25f665f73369f69093bd4fd630

Orchestrator pre-filter (13 file(s) excluded)

• layer-disabled (knowledge) : 13 file(s)

_{Findings produced by the Copilot CLI agent against BCQuality at 822cae1b2771ac25f665f73369f69093bd4fd630. Reply 👎 on any inline comment to flag false positives.}

[alexei-dobriansky]

Agentic PR Review - Round 1

Recommendation: Accept

What this PR does

This PR changes CreateGLEntryBalAcc in the BaseApp layers so a balancing G/L entry with a source currency code uses the signed Gen. Journal Line."Source Currency Amount" instead of converting the rounded LCY amount back to source currency. This matches the primary G/L account path, where PostGLAcc already passes the source currency amount into InitGLEntry.

For the IC partner balancing path, Exchange Acc. G/L Journal Line negates the entered FCY amount before PostICPartner calls CreateGLEntryBalAcc, so the IC control account gets the correct signed source amount. The LCY amount and the additional-currency amount calculation are not changed, and the no-source-currency path still uses CalcAmountSrcCurr.

Suggestions

No blocking or optional suggestions.

Risk assessment and necessity

Risk: This is high-sensitivity financial posting code for intercompany, multicurrency, and G/L source currency revaluation. The change is narrow but it is shared by IC partner and bank balancing G/L entries in all touched BaseApp layers. No new event publisher is involved; existing events and public signatures are unchanged.

Necessity: The bug is valid and important because a rounded LCY-to-FCY round trip can store the wrong source currency amount on the IC control account, which then gives G/L revaluation the wrong source balance. The W1 regression test posts a deterministic FCY IC journal and asserts the exact source currency amount on both the main G/L account and the IC control account. The ADO comments did not include an [AI-REPRO] comment, but the PR and work item describe the scenario clearly enough.

---

[AI-PR-REVIEW] version=1 system=github pr=9134 round=1 by=alexei-dobriansky at=2026-07-09 lastSha=0d018668d62b8b196d914b6c431fb6ace6a064b7 suggestions=none