Tag: AX 2012 R2

Product Configuration – Physical data model for user selected values

A constraint-based configurator was shipped with Microsoft
Dynamics AX 2012. In this post, we will provide an overview of the data model
that is used to persist the values that you can select when you configure a
product using the constraint-based configurator.

 

 

 

 

At first glance, you will notice that there are several
tables involved. If you are not familiar with previous versions of Dynamics AX
and the Product Builder configurator, this might not surprise you. However, if
you are familiar with the Product Builder, you will know that the old
configurator persisted all user selections in one table, namely the
PBATableInstance Table. This implies that retrieving the user selected values
is not as simple as writing a select statement against a single table. In the
following, I will use a report as an example and show you how you can retrieve user
selections in tables.Building a report

The report** that we use as an example displays all the user
selected values that are related to the configurations for a given product configuration
model.

**Disclaimer:
The report is not performance optimized. The purpose of the report is solely to
illustrate traversal of the data structure.

 

In the report, each element is indented to show the
parent-child relationship between, for example, the HomeTheaterSystem root
component and the “Color” attribute. The “Color” attribute can be assigned
other values, such as “Red”, but in the data on which the report was executed
no such configuration existed.

Note: I have used the Contoso dataset.

Data requirements

The data required to build the report can be broken down
into three parts:

  1. Get the instances of the root component from a
    given product configuration model. Here we only want the instances that are
    created for product variants and not the ones that are created for configuration
    templates.
  2. Get the attributes and their user selected
    values for a component instance.
  3. Traverse the subcomponent instances recursively
    and repeat part 2.

 

Let’s take a look at how to retrieve the data requirements to
build the report. The following statements will meet the data requirements and you
can also see the table involved:

Get the instances of the root component from a product configuration model

 

 protected void
  provideDataForModel(PCProductConfigurationModel _productConfigurationModel)

{

   PCVariantConfiguration              variantConfiguration;

   PCComponentInstance                 componentInstance;

   PCComponentInstanceRootComponent    rootComponentInstance;

   PCClass                             rootComponent;

…

   // get all
  configurations made for the given product configuration model

   while select componentInstance

   // only get instances which belong to a variant configuration, not a configuration template

  join TableId from variantConfiguration

  where variantConfiguration.RecId == componentInstance.ProductConfiguration

  // find the
  root component instances of the selected model

  join TableId from rootComponentInstance

  where rootComponentInstance.ComponentInstance == componentInstance.RecId

  join  rootComponent

  where   rootComponent.RecId ==  rootComponentInstance.RootComponentClass

        &&      rootComponent.RecId == _productConfigurationModel.RootComponentClass

    {

        //  handle data for component

        …

    }

}

 

Get the attributes and their user selected values for a component instance

 

    PCComponentInstanceValue    componentInstanceValue;

    EcoResAttribute             attribute;

    EcoResAttributeValue        attributeValue;

    EcoResValue                 value;

    

    // get all attribute value assignments
  related to the component instance

    while select  value

        join TableId from attributeValue

        where  value.RecId == attributeValue.Value

        join TableId from componentInstanceValue

        where componentInstanceValue.RecId  == attributeValue.InstanceValue

        &&    componentInstanceValue.ComponentInstance  == _componentInstance.RecId

        join attribute

        where attribute.RecId == attributeValue.Attribute

    {

   // handle data for attribute and attribute value

    …

    }

 

The values as such are sub-typed to model their respective data type.

Traverse the subcomponent instances

 

   

    PCComponentInstance    componentInstance;

    PCComponentInstanceSubComponent  subComponentInstance;

 
    PCSubComponent  subcomponent;

    PCClass                  childComponent;

 

// get all the subcomponents that have been associated with values

while select component

        join TableId from subcomponent

        where  subcomponent.ParentComponentClass == _parentComponent.RecId

        &&    subcomponent.ChildComponentClass  == childComponent.RecId

        join TableId from subComponentInstance

        where subComponentInstance.SubComponent == subcomponent.RecId

        &&  subcomponentInstance.ParentComponentInstance == _componentInstance.RecId

        join componentInstance

        where componentInstance.RecId == subComponentInstance.ChildComponentInstance

    {

   // handle data for component

    …       

    }

 

 

Implementation of the report

 

The data in the report is hierarchical in nature because of
the relationship between components and subcomponents.

The report that we build includes the parent-child
relationship between a component and a subcomponent and it also includes the parent-child
relationships between, for example,  an
attribute and an attribute value. This data cannot be retrieved from Dynamics
AX using a single query[1]
so we will use a data provider to populate a temporary table. The table has the
following structure:


[1]
This is not completely true because in Dynamics AX 2012, each component is
brought about as a reference to the configured variant. Thus, you could
retrieve all the data and then resolve the parent/child relations once the data
is retrieved.

 

A quick explanation of why the fields are required:

  • ID : this is used because the report framework
    will not expose the RecId field of the temporary table
  • Name : this is the name, such as Color, that we choose to display for the
    element
  • Parent : this is a reference to the parent
    record ID that helps grouping the SSRS report hierarchically
  • UniquePath : this is used to distinguish the
    attributes that belong to subcomponents of the same type. The path will be
    unique since it describes the path from the root component to each element in
    the model.

 

For more information about how to build a simple
hierarchical report in SSRS, go to:

http://technet.microsoft.com/en-us/library/dd255243(v=sql.105).aspx

For details on the implementation, take a look at the
attached X++ project.

Enjoy

PrivateProject_PCSessionValues.xpo

Importing product configuration models into AX 2012 R2

Some of the new features in Product configurator for Microsoft Dynamics AX 2012 R2 required that changes were made to the schema for product configuration models. As a result, if you want to import a product configuration model that was exported from a previous version of Microsoft Dynamics AX, you must make sure that the schema adheres to the new structure.

 

This blog post describes how to transform a product configuration model that was exported to xml from Microsoft Dynamics AX 2012 so that it adheres to the new schema for Microsoft Dynamics AX 2012 R2.

 

Disclaimer:

This method of importing product configuration models is not supported. The below xslt file is provided as is. You should review the imported product configuration models to verify that they do not contain any issues.

  

Use XSL transformations to update the schema

A product configuration model is exported from Microsoft Dynamics AX 2012 as a plain xml file named model2012.xml. You can update the xml to the new schema by using XSL transformations. By running the following command from a command prompt, you can convert the XML file using the attached xslt file and the MSXSL tool.

 

msxsl “model2012.xml” “transform2012toR2.xslt” -o model2012R2.xml

 

The command simulates what would happen during a standard upgrade process, and creates new file named model2012R2.xml that has the default values for new fields. You can import this file into Microsoft Dynamics AX 2012 R2.

transform2012toR2.xslt

What's new in Microsoft Dynamics AX 2012 R2 – Batch order sequencing

Many process industries are faced with a need to sequence the production of their products by using multiple levels of complexity. Production is sequenced based on a particular criteria that is assigned the highest priority. Production within that sequence is then further sequenced based on additional criteria that are assigned appropriate priorities. For example, a paint facility is configured so that production is first sorted by color and then by package size. This enables the cleanup time between colors to be reduced. However, there is a change to the packaging line equipment. Then the container configuration has a higher priority than the cleanup time that is required for color changes.

 

The batch order sequencing feature enables a production planner to sequence products on a bottleneck resource in the production facility. You can define sequences and sequence groups. The sequences can be characteristics of items that are used to identify how to sequence the items in production. Sequence groups define how certain sequences are prioritized. You can assign sequences to items and assign sequence groups to bottleneck resources. When you apply a sequencing principle to the MRP, the expected results are calculated.

What's new in Microsoft Dynamics AX 2012 R2 – Attribute based pricing and batch balancing

In Microsoft Dynamics AX 2012 R2 we introduce the batch balancing and attribute based pricing features that are used with potency management. Batch balancing feature enables you to modify a production formula by selecting the inventory batches of the active ingredients based on their current potency. Attribute based pricing is applied to the pricing of a potency item.

As the potency of an active ingredient can differ per batch, the quantities of active, compensating, and filler ingredients for a batch order need to be balanced to accommodate the amount of material that is required for production. This also means that after a batch order is created for a formula that includes an active ingredient, the picking list journal cannot be automatically created and posted. The batches of inventory that are selected for the required active ingredient must be picked before the batch order can proceed. This is performed by using the batch balancing function of the batch order. After inventory is reserved for the active ingredients, the balanced quantity for the compensating ingredients can be calculated. To determine the balanced quantity of the compensating ingredient, the following formula is used:

 

These calculations are part of the batch balancing function in Microsoft Dynamics AX 2012 R2 .

 

Attribute based pricing is applied to the pricing of a potency item which is an item that has a concentration of an active ingredient. This potency, or concentration, of active ingredient can be used to affect the amount of material that is required in production or the amount that is paid to a vendor based on the concentration level.

To calculate batch attribute pricing, take the purchase price and divide it by the batch attribute target to get a price per unit at 100% concentration. Then multiply by the batch attribute actual value. For example, a potency item has a price of $55.00 per lb. at a standard/target potency of 40%. If a batch of inventory of this item is received, and it is determined to have an actual potency of 46%, the price per lb. is (($55.00/40) * 46) $63.25. This is a higher price than the standard price that is paid for this material, because the active ingredient concentration of the material is higher and therefore, you use less than the normal quantity in production.