Financial dimensions in X++: DimensionDefault and the right EDTs

To store financial dimensions on a custom Dynamics 365 Finance & Operations table, add a field typed with the right EDT, with its foreign key relation: DimensionDefault (to DimensionAttributeValueSet) for a set of dimensions with no main account, such as on a customer or a document header; LedgerDimensionAccount (to DimensionAttributeValueCombination) for a full ledger account. Microsoft is firm: a wrong EDT stops the framework's tools from detecting dimension usage and can corrupt data during maintenance operations.

Second rule: dimension data is immutable. You never update or delete it in SQL; you create a new value set through the framework and repoint the document to it.

From the Microsoft Learn decision matrix:

• Dimensions only, no main account: DimensionDefault → DimensionAttributeValueSet.
• Multisegment account (main account + dimensions): LedgerDimensionAccount → DimensionAttributeValueCombination.
• Main account only, for a posting profile or parameters: LedgerDimensionDefaultAccount.
• Journal lines whose account type comes from LedgerJournalACType (ledger, customer, vendor…): DimensionDynamicAccount.
• Default main account or non-ledger account: DimensionDynamicDefaultAccount.

Do not store module-specific scenarios that fit none of these categories in dimension tables.

A DimensionDefault field holds a key to a DimensionAttributeValueSet record; each dimension value is a DimensionAttributeValueSetItem row linked to that set. You can read them through the DimensionAttributeValueSetItemView view. Only filled-in dimensions are stored: an empty value is not saved.

On forms, display and entry go through the DimensionDefaultingController controller, which determines the dimensions that apply to the company. To copy or merge dimensions (for example from the vendor to the order header), each process sets its own precedence: the framework does not impose it.

To make a custom table usable as a source of dimension values, Microsoft describes creating a DimAttribute[TableName] view (Key, Value, Name fields) and its read privilege.

• Typing the field as RefRecId or a generic EDT instead of DimensionDefault: reference scanners do not see it.
• Fixing a wrong dimension with a SQL UPDATE on DimensionAttributeValueSet or a "Dimension…" table: every other shared reference changes too. Microsoft recommends recreating the right set through a temporary document, then copying the key back.
• Using a dimension for highly variable values (order, serial or ticket number): dimension tables grow without limit; use financial tags instead.
• Forgetting the main account's "fixed" dimensions, which overwrite the entered value at posting.

Adding dimensions to a custom table, showing them and carrying them into posting is a frequent finance development. Skalp AI writes the specification, generates the X++ code and unit tests, compiles with a best-practice check, then delivers a pull request to your Azure DevOps: nothing is merged without your technical architect's approval. See D365 finance reporting and custom D365 F&O extensions, the bigger picture in building X++ without a consultant in 2026, and the Basic, Pro and Max plans (1 credit, ≈ €400 on Basic, €200 on Pro, consumed only when the code is generated).

See also: X++ Query and QueryBuildDataSource examples.

• Microsoft Learn, "Dimension foreign key reference EDT usage", updated 2 Mar 2026, accessed 18 Oct 2026.
• Microsoft Learn, "Default financial dimensions", updated 27 Mar 2026, accessed 18 Oct 2026.
• Microsoft Learn, "Modifying financial dimension data", updated 30 Mar 2026, accessed 18 Oct 2026.
• Microsoft Learn, "Make backing tables consumable as financial dimensions", updated 27 Mar 2026, accessed 18 Oct 2026.