[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}