[Mai][German Localization] Recurring Frequency DateFormula Exports as Invariant Tokens (+1D/+1Y) Instead of Localized UI Tokens (+1T/+1J) in ExcelInital commit

[sanjmaurya]

Bug 646602: [all-e][Master][German Localization] Recurring Frequency DateFormula Exports as Invariant Tokens (+1D/+1Y) Instead of Localized UI Tokens (+1T/+1J) in Excel

Fix AB#646602

Issue :- German Localization] Recurring Frequency DateFormula Exports as Invariant Tokens (+1D/+1Y) Instead of Localized UI Tokens

Cause :- The page field was bound directly to the DateFormula table field (Rec."Recurring Frequency"). Business Central stores and serializes DateFormula in a language‑neutral (invariant) form, while the web client only localizes it for display. The Excel/OData export uses the serialized invariant value, so the localized tokens are lost.

**Solution:-**On page 283 Recurring General Journal, the field is now bound to a Text variable that holds Format(Rec."Recurring Frequency") — the session-language representation that Excel exports. On validation, the entered text is converted back with Evaluate and stored via

[alexei-dobriansky]

Agentic PR Review - Round 1

Recommendation: Accept with Suggestions

What this PR does

This PR changes the Recurring General Journal page so Recurring Frequency is backed by a text variable filled with Format(Rec."Recurring Frequency"), then written back through Evaluate and Rec.Validate. That matches the bug: Excel exports the page value, so using the formatted value should expose the localized DateFormula text instead of the stored invariant value. The write path also handles valid input, empty input, and invalid input, so the fix is targeted and keeps the stored DateFormula generic.

Suggestions

S1 - Test the localized German token
The current tests use 1M, which looks the same in German and English. Add a test with a German session and a day or year formula, and verify the value exposed by the page is +1T or +1J. This proves the exact bug scenario, not only that the page mirrors Format() in the current language.

Risk assessment and necessity

Risk: The change replaces a direct DateFormula page binding with manual text parsing on the recurring journal page copies in W1, APAC, ES, IT, and RU. If it is wrong, users could export misleading recurrence text or save a wrong recurrence formula, but it does not change posting amount calculation or ledger entry creation. There is no public API or event change, and the added tests cover valid input, invalid input, clearing the field, and the displayed formatted value.

Necessity: The work item shows a clear German localization issue: the UI shows +1T or +1J, while Excel exports +1D or +1Y. Business Central DateFormula values are stored in a generic format and displayed in the selected language, so formatting the value at the page boundary is the right scope for this export issue.

---

[AI-PR-REVIEW] version=1 promptVersion=2 system=github pr=10184 round=1 by=alexei-dobriansky at=2026-08-14T10:11:12Z lastSha=91b8aabb1e3bd4b713b3b93b0412aa2cef54e623 reviewKey=na suggestions=S1@503419ab

[sanjmaurya]

Agentic PR Review - Round 1

Recommendation: Accept with Suggestions

What this PR does
This PR changes the Recurring General Journal page so Recurring Frequency is backed by a text variable filled with Format(Rec."Recurring Frequency"), then written back through Evaluate and Rec.Validate. That matches the bug: Excel exports the page value, so using the formatted value should expose the localized DateFormula text instead of the stored invariant value. The write path also handles valid input, empty input, and invalid input, so the fix is targeted and keeps the stored DateFormula generic.

Suggestions
S1 - Test the localized German token The current tests use 1M, which looks the same in German and English. Add a test with a German session and a day or year formula, and verify the value exposed by the page is +1T or +1J. This proves the exact bug scenario, not only that the page mirrors Format() in the current language.

Risk assessment and necessity
Risk: The change replaces a direct DateFormula page binding with manual text parsing on the recurring journal page copies in W1, APAC, ES, IT, and RU. If it is wrong, users could export misleading recurrence text or save a wrong recurrence formula, but it does not change posting amount calculation or ledger entry creation. There is no public API or event change, and the added tests cover valid input, invalid input, clearing the field, and the displayed formatted value.

Necessity: The work item shows a clear German localization issue: the UI shows +1T or +1J, while Excel exports +1D or +1Y. Business Central DateFormula values are stored in a generic format and displayed in the selected language, so formatting the value at the page boundary is the right scope for this export issue.

[AI-PR-REVIEW] version=1 promptVersion=2 system=github pr=10184 round=1 by=alexei-dobriansky at=2026-08-14T10:11:12Z lastSha=91b8aabb1e3bd4b713b3b93b0412aa2cef54e623 reviewKey=na suggestions=S1@503419ab

Hi alexei-dobriansky
We have fix the S1. Please review

[github-actions]

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

In the new test RecurringFrequencyDisplaysLocalizedGermanDateFormula, GlobalLanguage is switched to German (1031) and only restored to PreviousGlobalLanguage via a plain statement after Page.Run/SetValue/Close calls. If any statement between the GlobalLanguage(1031) call and the restoration line throws (e.g. Page.Run, TestPage field access, or an early Assert failure), the session is left in German language mode, which can contaminate subsequent tests run in the same session/codeunit execution. Wrap the language switch in try/finally (or restore in a cleanup path) so GlobalLanguage is always restored regardless of how the block exits. Note: this pattern (no try/finally around GlobalLanguage) is common elsewhere in this test suite, so this is a pre-existing style the PR follows rather than a novel regression, but it is still worth tightening in new test code.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

        PreviousGlobalLanguage := GlobalLanguage();
        RecurringGeneralJournal.Trap();
        Page.Run(Page::"Recurring General Journal", GenJournalLine);
        GlobalLanguage(1031);
        LocalizedRecurringFrequency := RecurringGeneralJournal."Recurring Frequency".Value;
        RecurringGeneralJournal.Close();
        ExpectedLocalizedRecurringFrequency := Format(GenJournalLine."Recurring Frequency");
        GlobalLanguage(PreviousGlobalLanguage);

_{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.33.4}

[alexei-dobriansky]

Agentic PR Review - Round 2

Recommendation: Accept with Suggestions

What this PR does

This PR makes the Recurring General Journal page back the Recurring Frequency field with a text variable filled from Format(Rec."Recurring Frequency"), then writes it back through Evaluate and Rec.Validate. This exposes the session-language DateFormula tokens (for example +1J / +1T in German) so Edit in Excel exports the localized value instead of the stored invariant token (+1Y / +1D).

Since round 1 the author addressed the test gap: a new test RecurringFrequencyDisplaysLocalizedGermanDateFormula stores a 1Y formula in an English session, switches the session to German (1031), opens the page, and asserts the field value equals the German Format() value and is not equal to the invariant token. This proves the exact bug scenario, and it was added to all six layer copies of ERMGeneralJournalUT.

Status of previous suggestions

ID	Title	Status	Author response
S1	Test the localized German token	Addressed	Fixed in c8659cf: new German-session test asserts the localized token (1J) differs from the invariant token (1Y)

New observations (commits since round 1)

S2 - Restore session language even on failure
The new test sets GlobalLanguage(1031) and restores the previous language with a plain statement after Page.Run / value read / Close. If any of those calls throws, the session stays in German and can affect later tests in the same run. Restore the language in a way that always runs (for example a cleanup path), so a failure between the switch and the restore does not leak German into other tests. This is a non-blocking test-hygiene point and matches a pattern already used elsewhere in this suite.

Risk assessment and necessity

Risk: The change swaps a direct DateFormula page binding for manual text parsing on the recurring journal page across W1 and the localization copies. A wrong parse could export misleading recurrence text or store a wrong recurrence formula, but it does not touch posting amounts or ledger entry creation. There is no public API or event change, and the write path handles valid, empty, and invalid input. The added German-session test now covers the reported export scenario.

Necessity: The work item is a clear German localization defect: the UI shows +1T / +1J while Excel exports +1D / +1Y. Formatting the value at the page boundary is the correct, contained scope for this export issue.

---

[AI-PR-REVIEW] version=1 promptVersion=2 system=github pr=10184 round=2 by=alexei-dobriansky at=2026-08-17T01:16:00Z lastSha=6ced6ad9019de210ad2fb6107425ecca278db895 reviewKey=6a385af3347b6008a5c698d8e6f710499beae2613989f5e57a9f6fcd84c0f689 suggestions=S1@503419ab:addressed,S2@58b2300a:new parentRound=1

[alexei-dobriansky]

Agentic PR Review - Round 3

Recommendation: Accept

What this PR does

This PR backs the Recurring Frequency field on the Recurring General Journal page with a text variable filled from Format(Rec."Recurring Frequency"), then writes it back through Evaluate and Rec.Validate. This exposes the session-language DateFormula tokens (for example +1J / +1T in German), so Edit in Excel exports the localized value instead of the stored invariant token (+1Y / +1D).

Since round 2 the author addressed the last open point (S2). The German-session test now moves the page interaction into a [TryFunction] (TryReadLocalizedRecurringFrequency) and restores GlobalLanguage(PreviousGlobalLanguage) right after it returns, before the assertions. The language is now reset even when the page interaction fails, so German cannot leak into later tests. The same change was applied to all six layer copies of ERMGeneralJournalUT, and the fix matches the cleanup-path shape requested in round 2.

Status of previous suggestions

ID	Title	Status	Author response
S1	Test the localized German token	Addressed	Fixed in round 2: German-session test asserts the localized token (1J) differs from the invariant token (1Y).
S2	Restore session language even on failure	Addressed	Fixed in bc61897: page read moved into a [TryFunction]; GlobalLanguage is restored unconditionally after it returns, then the test errors with GetLastErrorText() on failure.

New observations (commits since round 2)

None - the only new author commit addresses S2, and the change is a test-only refactor with no new behavior.

Risk assessment and necessity

Risk: The round-3 change is limited to the German-session test in the six ERMGeneralJournalUT copies; it does not touch the page logic, posting, or ledger entries. Moving the read into a [TryFunction] and restoring the language before the assertions removes the earlier risk of German leaking into later tests. There is no public API or event change.

Necessity: The work item is a clear German localization defect: the UI shows +1T / +1J while Excel exports +1D / +1Y. Formatting the value at the page boundary is the correct, contained scope, and the test now proves the exact export scenario with a clean session-language cleanup path.

---

[AI-PR-REVIEW] version=1 promptVersion=2 system=github pr=10184 round=3 by=alexei-dobriansky at=2026-08-17T07:08:43Z lastSha=36f9c983bdf84cd9a83b53da5306342d71e823a9 reviewKey=88d3188dda130aa76b85d4d52dd58be9c293c3ad207e9e0c040f8ac91804e38e suggestions=S1@503419ab:addressed,S2@58b2300a:addressed parentRound=2