Subscription Billing: respect Default Dimension Priorities on Subscription Lines

[Franco111000]

What/why

Fixes #8084.

When a Customer Subscription Contract spawns Sales Invoices, Default Dimension
Priorities (table 354) were not respected. With priorities set as Item = 1,
Customer = 2 the resulting Sales Line still carried the Customer's dimension
value instead of the Item's.

Per the discussion with @miljance on #8084, the simple swap of GetCombinedDimensionSetID
parameter order at the merge step would fix the reported case but would also let
Sales Line defaults beat genuine Subscription Line user overrides, which is a
regression against the original design intent ("Subscription Line dimensions
should overwrite any duplicates from the default dimensions"). This PR addresses
the root cause upstream so both behaviors hold: priorities are respected during
Subscription Line creation, and Subscription Line dimensions remain authoritative
at billing time.

The bug had two compounding causes inside the Subscription Billing module:

1. SubscriptionLine.SetDefaultDimensions called DimMgt.GetDefaultDimID(..., '', ...) with an empty Source Code, so Default Dimension Priority was never read. Only Item / G/L Account were added as dim sources, never Customer / Vendor.
2. GetCombinedDimensionSetID is a blind last-slot-wins merge. UpdateFromCustomerContract then merged the Customer Contract dim set into the Subscription Line as slot 2, so Customer values systematically overrode whatever was on the Subscription Line.

The fix makes SubscriptionLine.SetDefaultDimensions the single priority-aware
entry point for all dim computation:

• Passes SourceCodeSetup.Sales (Customer side) or SourceCodeSetup.Purchases (Vendor side) so Default Dimension Priority is consulted
• Adds Customer / Vendor as a dim source from the linked Customer / Vendor Subscription Contract
• Uses GetRecDefaultDimID with the contract's Dimension Set ID passed as InheritFromDimSetID and Database::Customer / Database::Vendor as InheritFromTableNo, mirroring the standard SalesLine.CreateDim pattern in Base App

UpdateFromCustomerContract and UpdateFromVendorContract now route through
SetDefaultDimensions instead of blind-merging the contract dim set. Same
change at the Pathway B call sites where an existing Subscription Line is
assigned to a contract (CustomerSubscriptionContract.CreateCustomerContractLineFromServiceCommitment,
VendorSubscriptionContract.CreateVendorContractLineFromServiceCommitment, and
the Import paths).

The blind merge at billing time (CreateBillingDocuments.Codeunit.al lines 264
/ 383) is intentionally left unchanged. After this fix the Subscription Line's
Dimension Set ID is already priority-resolved, so the existing "Service
Commitment wins over Sales Line" merge produces the correct result while
preserving the design intent that subscription line dimensions stay
authoritative for billing, which lines up with @miljance's clarification: "the
contract dimensions should win over any conflicting ones from the Subscription
Lines but still respecting the configured priority order."

Linked work

• Fixes [Bug][SubscriptionBilling]: Default Dimension Priorities not respected when creating Sales Invoice from Customer Subscription Contract #8084

How I validated

• Added a focused test RespectDefaultDimensionPrioritiesOnCustomerContractCreation in Service Comm. Dimensions. Configures Default Dim Priority Item = 1, Customer = 2 for source code Sales, gives Customer and Item conflicting values on the same dimension, asserts the resulting Subscription Line carries Item's value.
• CI pipeline tests (will react to results after submission).

Risk & compatibility

Existing tests in ServiceCommDimensions.Codeunit.al may need adjustments if
they rely on the previous "Customer Contract dim always wins" merge order in
scenarios with overlapping dim codes. Will iterate based on CI results.

The two cross-link call sites that propagate Customer Contract dim onto
vendor-paired Subscription Lines (CustSubContractLine.DeleteRelatedVendorServiceCommDimensions,
VendSubContractLine.UpdateServiceCommitmentDimensions) are intentionally not
touched in this PR. They involve a related but distinct concern about
cross-partner dim propagation. Happy to follow up once the direction here is
settled.

Opening as draft so @miljance and the consultant can weigh in before we finalize.

[miljance]

Looks clean and good. I think @Franco111000 is more than capable of finishing this one. From my side, this one can be converted to real PR. I would just like to run all the tests to see if any of those needs adjustment.

[Franco111000]

Thanks @miljance! Converting to ready for review. Looking forward to the test results, I'll iterate on anything that needs adjustment.

[miljance]

Hi @Franco111000,

Two tests are currently failing:

ExpectEqualItemAndServiceCommitmentDimensionSetIDOnDeleteCustomerContractLine
I looked into the background for this test and the intent seems to be that when deleting a Contract Line, the dimensions for Service Commitment should exclude any dimensions that came in with the Contract. I'm not sure this behavior is actually achievable as designed - so I'm weighing whether it makes more sense to remove this test or adapt it.

TestTransferDimensionsFromServiceCommPackageToVendorServiceComm
Something appears to have broken with the changes. In the best case, the test just needs to be updated to reflect the new behavior; in the worst case, some functionality may have been unintentionally affected. Worth investigating to confirm which scenario we're in.

Can you check out and give your thoughts?

[Franco111000]

@miljance, both failures traced to the same cause: my first commit made SetDefaultDimensions priority-aware, but that recomputed the Subscription Line dim from scratch and wiped any custom dim already on the line (auto-insert from cross-package propagation, etc.).

Pushed a restructure:

• SetDefaultDimensions reverted to its original Item-only behavior.
• New ApplyContractDimensions does a 3-slot merge via GetCombinedDimensionSetID: current SC dim, Contract dim, and a priority overlay built only from sources that outrank the Contract partner table per Default Dimension Priority. When the priority table is at the BC default (Customer/Vendor outrank Item), the overlay is empty and the call degrades to the original blind merge with Contract winning, so existing tests that don't configure priorities see no behavior change. The overlay only activates when the user has explicitly flipped priorities (the [Bug][SubscriptionBilling]: Default Dimension Priorities not respected when creating Sales Invoice from Customer Subscription Contract #8084 case).
• UpdateFromCustomerContract / UpdateFromVendorContract and the Pathway B call sites use ApplyContractDimensions.
• Test cleanup added so the new test doesn't leak priority rows to other tests.

Could you give it another run when you have a moment?

[miljance]

@Franco111000 PR looks good and all tests pass. The ApplyContractDimensions approach with GetTableIDsForHigherPriorities is exactly right.

Two small things I'd like addressed before merging:

1. Duplicated source-building logic — SetDefaultDimensions and ApplyContractDimensions share identical code for building the dim-source list (Invoicing Item + ServiceObject type switch). Could you extract that into a shared local procedure? - Not critical though - if you like it this way better - fine by me.

2. Inconsistent priority handling in contract line tables — CustSubContractLine.DeleteRelatedVendorServiceCommDimensions and the equivalent in VendSubContractLine recalculate dims via SetDefaultDimensions + GetCombinedDimensionSetID, bypassing the same priority logic this PR fixes. Those should call ApplyContractDimensions instead.

Both should be straightforward to include in this PR. Let me know if anything is unclear.

[Franco111000]

@miljance, both done in the latest commit:

• Extracted AddDefaultDimensionSources as a local helper on Subscription Line, used by both SetDefaultDimensions and ApplyContractDimensions. The helper uses a guarded if ServiceObject.Get then; the original SetDefaultDimensions had an unguarded Get. No caller relies on that error path, so this is a small defensive improvement.
• CustSubContractLine.DeleteRelatedVendorServiceCommDimensions and VendSubContractLine.UpdateServiceCommitmentDimensions now call ApplyContractDimensions instead of the blind GetCombinedDimensionSetID. Source codes: Purchases + Database::Vendor on the Customer-side delete path (Vendor Contract being applied), Sales + Database::Customer on the Vendor-side cross-link path (Customer Contract being applied). Under vanilla priorities the overlay stays empty and behavior is identical to before.

[miljance]

looks great