AX2012 R2 : Understanding technical design of product dimensions data

Hi,

In this blog we will take a dive into tables storing product dimension data for product master and also look at the code which we can use to generate this data automatically.
Standard Microsoft Dynamics AX 2012 R2 provide the following product dimensions: Configuration, Size, Color, Style. For each dimension there is a master table as shown below:

Notice that each master table has only one field called "Name" and each master table has unique index defined on this field.

So the above table hold the master data for the product dimensions in the system.

Now there are another set of 4 table which store the product dimension data for a product master. Shown below:

The above 8 tables can be seen as datasources on EcoResProductMasterDimension form where we define the product dimension data for product master.

For understanding purposes let us focus on configuration dimension and try to explore EcoResProductMasterConfiguration table.

If we notice the fields and relations on this table, we see it is storing the following references in each record:

• ConfigProductMaster --> Stores RecId of product master
• Configuration --> Stores the RecId of EcoResConfiguration ( This is the master table configurations)
• ConfigProductDimensionAttribute --> Stores RecId of dimension attribute [Let's park this field for now , we'll come to it later]

So now once we have understood how the tables are related, let's see the X++ code which we can create product dimensions for a product master by pulling data from the master tables.

[P.S --> Currently we are focussing only on product dimension configuration]

 

So now let's understand the above code: The logic is pretty simple, we just need to know the recId of product master and the dimension for which we are going to create the product dimensions [In this case Configuration]. Loop through the ecoResConfiguration table and insert record for Product master.

But the interesting thing to notice is, the way we have initialized ConfigProductDimensionAttribute. This field stores refRecId.  The same code can be found on the standard AX form where we create product dimensions for product master, shown below:

 

 

So to understand this field ( which we parked earlier), let's take a closer look at the table EcoResProductDimensionAttribute

 

 

We will see this table only holds a single field DimensionTableId which is actually a RefTableId.

 

On closer look if we look in the table browser, the records in this table store the tableId of the dimension master tables [EcoResSize, EcoResConfiguration, EcoResColor, EcoResStyle] , see below the example for EcoResConfiguration:

 

 

 



Well doesn't it looks odd to have table Id stored in a table, and in order to get the recId of that record we are using a static function

EcoResProductDimensionAttribute::inventDimFieldId2DimensionAttributeRecId(fieldNum(InventDim, ConfigId));

in which we pass the fieldNum of ConfigId field of InventDim Table !!!!!!! 

 

The answer lies in the static function itself, see below the function:

 

 

The tableId is being determined by the configId fieldNum of InventDim table. What I think is that Microsoft wants to make sure that we do not use these tables for storing incorrect data and we can refer to them from dimension fieldID's itself. I see this might provide a tight binding of data model from code for storing dimensions. No one really wants to mess them ;)

 

So now show time, let's create a product master with attach a product dimension with only color enabled in it.

 

So now once the product master is created, let's see what are the colors stored in EcoResColor table:

To do this we can view details of colors available from the form where we define color dimensions for product master

 

 

 

So now we need a programme define all these colors for this product master, let's use the code I mentioned above but with the tables of color dimensions this time: so let's execute the code: [ notice this time we have used tables storing colorId]

 

Once the code is executed and now let go to product dimension form for the product master and see the color are defined for the product master:

 

 

So the above code can be useful in implementing product master for companies which have a common dimension master data which they want to assign to all products.

In my next blog I'll continue to explain on how we can create released product variants from the product dimension data defined for product master.

 

Till then take care friends and keep sharing!!!!