[Bug][SubscriptionBilling] Contract lines of type G/L Account never post to the selected G/L account (backport to releases/29.x)

[Miljan Milosavljević (miljance)]

What & why

• This is a backport of PR for 30: to 29.x [Bug][SubscriptionBilling] Contract lines of type G/L Account never post to the selected G/L account #9905
• A backport of the same change to releases/28.x was opened as [Bug][SubscriptionBilling] Contract lines of type G/L Account never post to the selected G/L account (backport to releases/28.x) #10091
• post G/L Account contract lines to their own account. Subscription Billing contract lines of type "G/L Account" always posted to the Customer/Vendor Subscription Contract Account from the General Posting Setup, ignoring the account actually selected on the contract line.
• Without deferrals, CustomerDeferralsMngmt/VendorDeferralsMngmt now skip the General Posting Setup account lookup for "G/L Account" lines so the invoice posts directly to the line's account.
• With deferrals, a new "G/L Account No." field (27) on Cust./Vend. Sub. Contract Deferral carries the account from the sales/purchase line, and is surfaced on the Customer/Vendor Contract Deferrals pages.
• ContractDeferralsRelease now posts to that account when releasing the deferral, falling back to the General Posting Setup account when it is blank, and only requires the General Posting Setup account to be filled when no contract-line account is available.
• Added TDD tests to CustomerDeferralsTest and VendorDeferralsTest covering both the immediate-posting and deferral-release paths, with a shared fixture in ContractTestLibrary.

Linked work

Fixes #9885
AB#648281

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

• This backport is a clean cherry-pick (-x) of the squash-merge commit 32df311 of [Bug][SubscriptionBilling] Contract lines of type G/L Account never post to the selected G/L account #9905 onto releases/29.x — the diff is identical to the original PR's diff, with no conflicts and no context drift. The squash commit carries both commits of the original PR: the fix itself and the test reorder that resolved the IT-localization CI failure.
• The change itself (including the new tests in CustomerDeferralsTest and VendorDeferralsTest) was built, run, and validated on main as part of the original PR: posted contract invoices for G/L Account contract lines with and without deferrals and confirmed the line's G/L account is used for posting and for deferral release; the original PR's CI was green across localizations before merge.
• The backport itself was not built or test-run against a 29.x environment.

Risk & compatibility

• Intentional behavior change: contract lines of type "G/L Account" without
  deferrals now post to the G/L account selected on the line instead of the
  Cust./Vend. Subscription Contract Account from General Posting Setup. Anyone
  who relied on the old (incorrect) routing will see revenue/cost on different
  accounts going forward.
• Schema: purely additive — new field 27 "G/L Account No." on the
  Cust./Vend. Sub. Contract Deferral tables. No breaking changes, no upgrade
  code needed: the field is blank on pre-existing deferral rows, and release
  falls back to the General Posting Setup account, so existing deferrals
  release exactly as before.
• Relaxed validation: Contract Deferrals Release no longer requires the
  General Posting Setup contract account when the deferral carries its own
  account — setups with a blank GPS account now succeed where they previously
  errored (intended).
• Credit memos: reversal copies the deferral record, so the new field is
  propagated automatically.
• Test library: ContractTestLibrary got a new overload; the existing
  CreateServiceObjectForGLAccountWithServiceCommitments signature is unchanged.
• No permissions, telemetry, or feature-flag impact. No follow-up work planned.
• The cherry-pick onto releases/29.x applied cleanly with no conflict resolution.

🤖 Generated with Claude Code

[github-actions]

Issue #9885 is not valid. Please make sure you link an issue that exists, is open and is approved.

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Accept

What this PR does

This backport makes Subscription Billing contract lines of type G/L Account post to the account selected on the contract line. It handles both immediate posting and contract deferral release for customer and vendor contracts.

The change is targeted. For lines without deferrals, the existing BaseApp account chosen from the line is left unchanged. For lines with deferrals, the selected G/L account is stored on each deferral entry and used as the release account, while old deferrals still fall back to the setup account when the new field is blank.

Problem-solution fit

Fit: Strong

The bug says the selected G/L account had no effect on posting for this line type. The diff addresses the direct posting path, the deferral release path, and both customer and vendor flows.

Suggestions

None.

Risk assessment and necessity

Risk: This changes financial posting destinations for Subscription Billing G/L Account contract lines. The scope is limited to that line type, existing setup-account behavior remains for other line types and old deferral records, and no public procedure or event signature is changed.

Necessity: The selected G/L account on the contract line should control the final revenue or cost account. The change is needed because both immediate posting and deferral release previously ignored that account, and the tests cover the customer and vendor paths with and without deferrals.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=11069 round=1 by=alexei-dobriansky at=2026-09-04T19:15:17Z lastSha=5528563cbca2e8c01a4c3e1a9c0c6a17e55db58f reviewKey=ebb14147370d86f6cf32c66bd7765f5b5a1b18c0845ed35dfe468286e7d9623a suggestions=none