Deserializing Financial Dimensions in Microsoft Dynamics AX 2012

Picture of Camilo Godines

Camilo Godines

The Microsoft Dynamics AX/D365 Support Team at Avantiico is focused on solving our client’s problems, from daily issues to large and more complex problems.

See All Posts

Deserializing Financial Dimensions in Microsoft Dynamics AX 2012

Financial dimensions are stored as a 64bit integer surrogate key in the database. It may be necessary to extract this information to understand the financial dimensions that this surrogate key represents. For example, a custom BI solution, report or integration may require that this surrogate key be de-serialized to reveal the exact financial dimensions it represents. This blog explains some of the common Microsoft Dynamics APIs available and display financial dimension segment from a default dimension surrogate key. A simple job is created to demonstrate this.

In this example, we will be working with the financial dimensions of a customer.

Sales order screen
Figure 1: Customer default dimensions

This is stored in the SQL database as a 64 bit integer.

DAX integrationld
Figure 2: DefaultDimension value

The database schema below represents all the tables and views that are required to de-serialize and display the financial dimensions that this surrogate key represents, however this blog post will demonstrate key Microsoft Dynamics AX API’s that can assist developers.

Figure 3: Data model of dimension framework in AX 2012

The following script is created to demonstrate:

Figure 4: Sample AOT Job

The following Microsoft API’s are used:

  • The DimensionAttributeValueSetStorage class is used to iterate through all the financial dimensions in the DefaultDimension
  • The DimensionAttributeValue table is used, this stores a link to the VALUE of the financial dimension we want to display, for example a department or cost center number. This is usually linked via a surrogate key, e.g. DimensionAttibuteValueEntityInstance is a surrogate key to the exact record we wish to display.
  • The DimensionAttribute table is used, this stores information so we can understand the TYPE of financial dimension. This stores the object ID of the view or tabled used as backing entity, e.g. 11765 = DimAttributeOMDepartment
  • The DimensionDefaultingControllerBase class is used to find the backing entity record. The backing entity is usually a view in the AOT, starting with DimAttribute. This view can then be used to display information about the financial dimension. The DimensionAttribute table is used to find the table that contains the financial dimension, the DimensionAttributeValue table is used to find the specific record in that table.
  • The DimensionAttribute record contains a ValueAttibute field, which is the field id in the backing entity view that stores the VALUE of the financial dimension, this is a natural key, for example a department ID (e.g. Department 10)
  • The NameAttribute field on the DimensionAttribute record stores the field in the backing entity view that stores the NAME of the financial dimension, for example “IT Department”.


The DimAttribute financial dimension backing entities have a key, value and name field. The following example shows the financial dimension backing entity for departments which are stored in the table OMOperatingUnit

  • Key: This is foreign key to the Operating Unit RecId field (e.g. OMOperatingUnit.recId)
  • Value: This represents the Operating Unit ID (e.g. 110)
  • Name: This represents the Operating unit Name (e.g. “Budget Office”)
Attribute screen
Figure 5: DimAttribute View backing entities

Thanks for reading, comment below to let me know if you struggle with something specific in D365 or DynAX!


More to explorer

Request a free Dynamics 365 demo

Discover how Avantiico helps you improve business processes, provide customers with a seamless experience and transform the way you do business.