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

[miljance]

Describe the issue

When creating a Sales Invoice from a Customer Subscription Contract, the Default Dimension Priorities (set for source code "Sales") are not respected. The dimension value is incorrectly taken from the Customer instead of the Item, regardless of the configured priority order.

Setup:

• Customer has Global Dim 1, Value = A
• Item has Global Dim 1, Value = B
• Default Dimension Priorities: Item = 1 (highest), Customer = 2

After generating the Sales Invoice from the Customer Subscription Contract, Global Dimension 1 is set to Value A (from Customer) instead of Value B (from Item).

Expected behavior

Global Dimension 1 should be set to Value B (from Item), as the Item has the higher priority (1) over the Customer (2) in the Default Dimension Priorities for source code "Sales".

Steps to reproduce

1. Open Default Dimension Priorities and configure source code Sales with: Item = priority 1, Customer = priority 2.
2. Set up a Customer with Global Dim 1 = Value A.
3. Set up an Item with Global Dim 1 = Value B.
4. Create a Customer Subscription Contract (e.g. DV000028) using that Customer and Item.
5. Generate a Sales Invoice from the Subscription Contract.
6. Open the created Sales Invoice and inspect the value of Global Dimension 1.
7. Observe that the value is A (from Customer) instead of B (from Item).

Additional context

No response

I will provide a fix for a bug

• I will provide a fix for a bug

[JesperSchulz]

🤖 AI triage completed. Product group, please validate the triage report (Microsoft internal access only, use Ctrl+Click to open in new tab).

---

_{Was this triage helpful? React with 👍 or 👎 on this comment to provide feedback.}

[Franco111000]

Hi @miljance, since this is fresh I wanted to ask before claiming. I already had a look into it and I think I might have a solution. Would you like me to put a pull request together, or would you prefer to take it yourself?

[miljance]

@Franco111000 — Thanks for the suggestion! I do have a dilemma on how best to resolve this.

I filed this issue as originally reported. The dimensions on the Contract Invoice line are currently a combination of:

1. Dimensions from the Subscription Line, and
2. Default dimensions generated when validating Item No. on a new Sales Line.

The original decision was that Subscription Line dimensions should overwrite any duplicates from the default dimensions - which is what leads to the current behavior.

We could of course reverse the priority like this:

However, that feels off - or even like a regression - since default dimensions from the newly generated Sales Line would then take precedence.

What approach did you have in mind? Feel free to open a PR so we can discuss whether your proposal fits the intended behavior. I also plan to check with the consultant, since I recall the original requirement specifically asked for Subscription Line dimensions to win over defaults.

[Franco111000]

@miljance, thanks for the detail. Digging in, I think this runs a bit deeper than the param order at the merge. If I'm not mistaken, two mechanisms together cause priority to be bypassed:

1. SubscriptionLine.SetDefaultDimensions (table 8059, around line 1100) calls DimMgt.GetDefaultDimID(..., '', ...) with an empty Source Code, so Default Dimension Priority is never read. Only Item / G/L Account are added as dim sources, never Customer / Vendor.

2. GetCombinedDimensionSetID is a blind last-slot-wins merge. UpdateFromCustomerContract then merges the Customer Contract dim in, and Customer values overwrite anything that was on the Subscription Line.

So by the time billing runs, ServiceCommitment."Dimension Set ID" already carries the Customer's dim regardless of priorities, and the slot order at lines 264 and 383 just compounds it.

Your "feels like a regression" instinct seems right. The simple swap fixes the reported case but would also let Sales Line defaults beat genuine Subscription Line user overrides. The root issue I think is that nothing distinguishes user-set Subscription Line dims from contract-inherited dims, they both live in the same Dimension Set ID.

Two directions:

Upstream fix: Make SetDefaultDimensions priority-aware (pass SourceCodeSetup.Sales / .Purchases, feed Customer / Vendor as dim sources). Then ServiceCommitment."Dimension Set ID" carries priority-resolved values from the start, and any later edit is a real user override.

Merge-step fix: Apply Microsoft's CreateDimFor{Sales|Purch}LineWithHigherPriorities pattern (DimensionManagement.Codeunit.al around line 2180, used by Job Create Invoice and Purchase Line job-task merge). Surgical, but the upstream pollution of ServiceCommitment.Dim with Customer values remains.

Both will touch the assertions in ServiceCommDimensions.Codeunit.al that currently pin slot-2 wins.

Would be useful to know what the consultant intended for the distinction between explicit Subscription Line overrides and contract-inherited values. That seems to be the real call to make before picking a direction.

If any of that isn't clear, happy to open a draft pull request in one of the two directions so we have something concrete to discuss against, and iterate from there.

[miljance]

@Franco111000 You're right on both counts - the bug likely lives in SetDefaultDimensions, which needs to respect priorities, and your proposed merge-step fix looks correct to me as well. I'll verify the details with the consultant.

On the broader design intent: dimensions can be entered on a contract manually or through other means. When Subscription Lines are fetched into the contract, the contract dimensions should win over any conflicting ones from the Subscription Lines - but still respecting the configured priority order. The same applies when a Sales Line is created: it may introduce new default dimensions, but the Service Commitment dimensions (already combined with Contract dimensions at that point) should take precedence. I still need to confirm this with the consultant, as you asked.

Your analysis is impressive - thank you. I had difficulties to understand the whole picture, but I think I managed. Please go ahead and open a PR; I'd be glad to follow along and review.