[29.0] [CH] When posting with FCY, VAT G/L Entry stores VAT base amount in Source Currency Amount instead of VAT amount

[dcenic]

What & why

During initialization of a system-generated G/L Entry, not recalculating source currency amounts, as it already carries the correct source currency amount.

Linked work

Fixes AB#649596

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)

Automated test to cover the repro steps

Risk & compatibility

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Accept

What this PR does

This change stops the CH posting code from recalculating Source Currency Amount for system-created G/L entries. That lets VAT split entries keep the source-currency amount that was already calculated for the VAT amount.

The guard is narrow: normal non-payable account entries can still receive the net-of-VAT source amount, while system-created VAT entries keep the amount passed into InitGLEntry. The added test posts a foreign-currency purchase journal line and checks both the expense entry and the VAT entry, so it covers the reported posting path.

Problem-solution fit

Fit: Strong

The reported issue is that a foreign-currency VAT G/L entry stores the VAT base in Source Currency Amount instead of the VAT amount. The diff addresses the overwrite that causes this and adds a regression test for the affected purchase posting scenario.

Suggestions

None.

Risk assessment and necessity

Risk: This is a CH finance posting path in GenJnlPostLine.Codeunit.al, so an incorrect change could persist wrong source-currency amounts on VAT or G/L entries. The code change is small, has no public API or event signature change, and leaves non-system-created account-entry behavior in place.

Necessity: The change is needed because the VAT split entry already receives the correct source VAT amount, and recalculating from the full journal amount can store the base amount instead. The scope is appropriate: one posting guard plus a focused regression test.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=11265 round=1 by=alexei-dobriansky at=2026-09-09T13:33:43Z lastSha=514b77d2b6840c0b19712c67b1919bb7eaa392fa reviewKey=1163c5d2357adcca82e06bbb8fa17222185aba5dbc31180e5b4f42bf9744a3e9 suggestions=none