Understanding the default configuration concept for constraint-based products

Introduction

The default configuration concept enables users to start the product configuration process when the main product master data are available within a legal entity. You can learn more of the details of this concept in this post.

The default configuration concept

You must use the configuration technology Constraint-based when you configure product masters and the product masters must be configured with only one active product dimension, the Configuration dimension. We refer to the products masters as constraint-based products throughout this post.

To create a constraint-based product you must specify a valid product dimensions group which complies with this requirement.

Figure 1 Error message when the wrong dimension group is selected

You use the Configuration dimension to capture the final product configuration of a certain product model. The product model is represented in the system as a new product variant with a specific configuration dimension value. This is how Dynamics AX distinguishes between different results of the final product configuration. This allows you to complete a lot of tasks, such as:

Record and view on-hand inventory for individual configurations.
Run master planning against specific customer requirements (and across different legal entities).
Reuse existing product definitions in order to create products that are identical to existing products. You can also apply existing product definitions across legal entities.

Once you have released a constraint-based product to a legal entity, you can kick off a product configuration process from the following source document lines:

Sales order line
Sales quotation line
Project order line
Production order line
Purchase order line

The product dimension Configuration must have a value before you can start the product configuration process for a selected constraint-based product on an order line. Also, all active product dimensions must be specified before you can save an order line. These requirements are based on a series of technical solutions which are consistent with the experience that many users have from the Product Builder functionality.

Note – This is always the case for stocked products .For non-stocked products, you can specify a product category instead of defining the particular SKU.

The default product configuration concept is dedicated to solve the above described issue. It enables end users to proceed with the product configuration as soon as the product has been released to the legal entity.

Figure 2 The Default configuration is just there, after the product release

When a constraint-based product is released to a legal entity, the system automatically creates and releases a default product variant with the configuration value Default. The Default parameter is derived from the Default configuration ID field on the Constraint-Based product configuration models tab in the Product information management parameters form. This form is located under Product information management > Setup. The Default configuration ID value is set automatically during system installation. It references the SYS Label @SYS331038, but you can always change the value.

Figure 3 Product Parameters form

The process to create and release the default product variant is completely transparent and once the Default configuration ID parameter is set, no further action is required. If the product is released to multiple legal entities, the same default product variant will automatically be released to all of those legal entities.

Once the default product variant is released to the legal entity, the system will also update the default product variant fields on the released product. The default configuration dimension value is provided when you enter the item number on the order line. Any end user can change this setup in order to, for example, always have a basic configuration of a specific product suggested on all order lines

Figure 4 The default product variant dimensions are set to match the Default Configuration ID

Summary

The default configuration concept makes it possible to start the product configuration process at the point where the main product master data are available within a given legal entity. In order words, it facilitates the first step in the overall process of configuring an order line and it goes without saying that the first step is a prerequisite to move on in the process. Thanks for reading.

Working with Overlap in Microsoft Dynamics AX

Conducting Dynamics AX Manufacturing training for a class in Malaysia, it became clear that the current documentation on Overlap in Dynamics AX was not telling the full story.
Therefore, I decided to write this blog.

So, what is Transfer batch and Overlap quantity?

In Dynamics AX ‘Transfer batch’ is the field used to control an overlapped schedule. Apics define ‘Overlapped schedule’ as “A manufacturing schedule that overlaps successive operations. Overlapping occurs when the completed portion of an order at one work center is processed at one or more succeeding work centers before the pieces left behind are finished at the preceding work centers.”

Overlapped schedule is also known as lap phasing, operation overlapping, telescoping or send ahead.

‘Overlap quantity’ is a calculated field on the production order – ensuring that we avoid gaps in the schedule, when the successor operation to the operation with a Transfer batch value, has a shorter process time.
The ‘Overlap quantity’ determines the first transfer batch size for the operation; the following transfers to the next operation will use the ‘Transfer batch’ value.

Overlap quantity example

Say you have a production order for 10 pcs and it has two operations 10 and 20, each operation taking 2 minutes per pcs:

Without overlap:

Normally operation 20 will start when the entire quantity (10 pcs) has been processed on operation 10

With overlap:

When you have specified something in ‘Transfer batch’ field, let us say 2 pcs, it means the next operation (in our case 20) can already start when only 2 pcs has been processed on the operation 10. The value from ‘Transfer batch’ is by default copied to the ‘Overlap quantity’, on the production order.

Why does the Overlap quantity sometimes change when I estimate a production order?

The ‘Overlap quantity’ parameter on the production order route is calculated by the system. This is done during the estimation (or scheduling) of the production order, to prevent gaps in situations where a later operation have a shorter process time than the current operation. The fact that the successor would be waiting for the delivery from the predecessor would be causing a gap.
So, the calculation of an optimal ‘Overlap quantity’ is done based on the ‘Transfer batch’ and the operation process durations on the route.

Overlap example with gaps (two operations):

Say you have a production order for 10 pcs and it has two operations 10 and 20, this time the first operation takes more time than the second does:
Opr 10: 20 min per pcs
Opr 20: 10 min per pcs
Again, we have a Production order for 10 pcs and Transfer batch quantity set to 2 pcs

Without any change during Estimation the jobs on the route would have a gapped schedule and look like this:

However, as the first operation in total will take 200 min to complete and the second will take 100 min you will get the following information when estimating:

With the change from 2 to 6 we ensure that there are no gaps between the jobs in the second operation.

Overlap example with gaps (three operations):

Now let us spice it up a bit and add another operation – Opr. 30 with a run time of 5 min per pcs. We will also set a ‘Transfer batch’ = 4 on operation 20

In this case, you get the following information during estimation:

Now the schedule will look like this:

Therefore, by updating the ‘Overlap quantity’ on the production order during the Estimation Dynamics AX ensures that production on the following operation can happen without any gaps – avoiding a gapped schedule.

Christian Rytt, Senior Program Manager at Microsoft Development Center Copenhagen

Use of ingredient types for batch balancing in production

In an earlier blog post, http://blogs.msdn.com/b/axmfg/archive/2012/12/05/what-s-new-in-microsoft-dynamics-ax-2012-r2-potency-management.aspx#10421522, we introduced the new capabilities in Microsoft Dynamics AX 2012 R2 that support potency management business processes for process industries. This blog provides more information about the four ingredient types that were introduced, None, Active, Compensating, and Filler, and the impact that they have on how quantities are calculated for batch orders.

There are many examples of the use of potency; in chemical industry the percentage of caustic can be characterized as an active ingredient in Pottassium Hydroxide, alcohol can be an active ingredient is liqueurs or fat can be an active ingredient in foods. The amout of active ingredient will often vary around a target value for these products, and the purchase price and the amount to consume in further production will often be affected by this variation. The batch balancing process, which is described in more details here, is focusing on how to take this variation into account

The key to setup formulas, where items with active ingredients must be taken into account, is by the use of the Ingredient types on the formula lines. For the example we will be looking at product A, B, C and D which each represent a seperate Ingredient type.

Ingredient type: Active

You can specify the potency of a product by defining the percentage of its active ingredient. When a product with an active ingredient is included in a formula, the ingredient type on the formula line gets the value Active and cannot be changed. Products must have a potency specified for them before they can be used as an active ingredients in formulas.

The potency of a product is defined by the use of a base attribute of the product. The base attribute is specified from the Manage inventory tab on the Action Pane in the Released products form. Before the base attribute can be associated with a product, the product must have the following setup:

The batch dimension must be active for the product. This is done by assigning to the product a tracking dimension group with an active batch dimension.
The attribute that will act as the base attribute for the product must be defined as a product specific batch attribute for the product. (Manage inventory > Batch attributes > Product specific). The associated attribute must have minimum, maximum, and target values.

The balanced quantity of an active ingredient is calculated according to the target value specified for the base attribute. Batch orders for products that have active ingredients in their formulas must go through a batch
balancing process. The batch balancing process is carried out from the Batch balancing form, which is available from the Batch orders list page and Batch order details form when the batch order status is Started. The batch balancing process estimates the amount of each ingredient in the formula that is required to produce the product. The estimation is based on the potency of the on-hand batches that are selected for the production.

Example

Ingredient B has a base attribute X and a target value of 30, and it’s included in a formula that requires 30 liters of Ingredient B for every 100 liters of the product. A batch order is created with a batch size of 100 liters. The batch order is started, and during the batch balancing process the user points to a batch of Ingredient B that has a potency level of 35. Because the potency level of 35 is higher than the target value of 30, the balanced quantity of ingredient B is reduced with the ratio of the potency value and the target value of the batch compared to the estimated quantity. The calculation of the balanced quantity looks like this:

(30/35) * 30 Liters = 25,71 Liters.

Ingredient type: None

When using this type there will be no difference between the estimated quantity and the balanced quantity when performing the batch balancing operation.

Example

Ingredient A is assigned to an ingredient type None, and is added to a formula for a finished product. The formula calls for 10 liters of Ingredient A for every 100 liters of the finished product. When a batch order requires 200 liters both the estimated and the balanced quantity of Ingredient A is calculated as 20 liters.

Ingredient type: Compensating

A compensating ingredient can either offset or compliment the effect of the active ingredient in a product. Therefore, the quantity of a compensating ingredient that will be consumed depends on the potency of the product.

Opposing effect – If the amount of the active ingredient is higher than anticipated, less of the compensating ingredient is required. The earlier blog gave an example of ice-cream, where cream compensates for a higher concentration of fat in milk.
Complementary effect – If the amount of the active ingredient is lower than anticipated, you need to add more compensating ingredient. The earlier blog used potato chips as an example, where more oil was added to the boiling process when the degree of moisture in the potatoes is higher than anticipated.

The relation between an active ingredient and a complementary ingredient is set up in the “Compensating principle” form, which is available from the Action Pane in the Formula lines form. You need to select the line that represents a compensating principle, and then point to the active ingredient you want to compensate. In the compensating principle, you also specify a positive or negative compensating factor to determines how much to compensate for and whether the principle should be opposing or complementary. A positive factor is used for complementary, and a negative factor is indicates opposing.

Example

Ingredient B is an active ingredient that has a base attribute X and a target value of 30. It’s included in a formula that requires 30 liters of Ingredient B for every 100 liters of the product. Ingredient C is a compensating ingredient, and is included in the same formula with a quantity of 10. The compensating principle is set up with a factor of 1.10. With a factor of 1.10, the balanced quantity of the compensating ingredient will be reduced by the difference between the active ingredient’s balanced quantity and the estimated required quantity multiplied by 1.10

In a previous example, the balanced quantity of the active ingredient needed was calculated to 25.71, and the estimated required quantity was calculated to 30. In this case, the balanced quantity of the compensating ingredient would be calculated as follows:

Difference between estimated and balanced quantity:

25.71 – 30 = – 4.29

Multiplied with compensating factor:

4.29 * 1.10 = – 4,72

Compensating estimated quantity will be reduced with -4.72 in order to calculate balanced compensating quantity:

10 – (- 4.72) = 14.72

Because 1.10 is a positive factor, this is a compensating principle with a complementary effect. And because the active ingredient is more potent than anticipated, more of the compensating ingredient is required.

Ingredient type: Filler

The filler ingredient is a neutral ingredient used to reach the desired output quantity of the finished product. Adjustment to the filler quantities are calculated based on variations in the active and compensating ingredient compared to the standard quantity.

Example:

We have formulated a product with ingredient A, B, C and D for a formula size of 100 liters. We have calculated the balanced quantity of all the ingredient types except for the line with ingredient type Filler. The balanced quantity of the filler ingredient calculates as the difference between the batch size of 100 liters and the sum of the ingredients:

100 – 20 – 25.71 – 14.72 = 39.57

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:

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.
Get the attributes and their user selected
values for a component instance.
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

Kitting in Microsoft Dynamics AX 2012 using product configuration and sales event kanbans

Many Microsoft Dynamics AX users have asked for a solution that supports kitting. To support a kitting solution, two primary components are needed:

Configuration of a kit for the order management
An activity that assembles the kit

Many ERP and SCM solutions support kitting as part of the Warehouse management or logistics functionality. Without having native support for kitting, Microsoft Dynamics AX 2012 offers an approach where it might not have been expected: Using to product configurator to configure kits based on a product configuration model combined with a lean process activity where the kits are built or packaged to order.

So in fact, the kits are built based on sales event kanban’s, with a single kanban per kit.

It all starts with modeling the kit as a configurable product, and then creating a configuration model that represents the products that can be combined in kits, possibly also including the packaging material. In our example we have a configurable speaker set that consists of two front and two rear speakers per kit. This is represented by a simple product configuration model.

The model structure is rather flat, and consists of the front and the rear car speaker set. The products that can be selected in each configuration step are modeled as conditional BOM lines. In our example the configuration model makes sure that while different models of speakers can be selected for the front and rear speaker pairs, all speakers – front and rear – will have the same cover color. Because the assembly of the kit is done by a lean production flow, route operations are not
needed in the configuration of the product model.

Therefore a global attribute of Color is associated to the Car speaker set. This constrains the selection of components to the common color.

Based on the model shown above, a sales order taker can configure the kits based on the customer’s demands, or use pre-configured kits by selecting a specific configuration of the kit.

The individual configuration is done in the sales order line as shown below, by clicking Product and supply > Product model > Configure line.

The Configure line form allows the configuration of the kit to be based on the product model.

Before finishing the configuration, the sales price of the kit can be calculated based on the configuration of the new kit:

After the configuration is done, a new variant of the kit is created with a corresponding BOM version, and the sales line is updated with the new configuration and sales price.

Note that the BOM version is automatically approved and activated.

Once the configuration is final, the order taker can create the kanban that is to assemble the kit on the packaging work cell directly in the order form:

This creates one or more kanbans, depending on the number of packages that are needed, and load them on the kanban board of the packaging work cell.

In our example, Set05 with the new configuration has been added and is now ready to be picked and completed.

On the same work cell, other preconfigured kits (in our example CSS_SS1B) and other products can also be packaged and delivered to order or to stock.

The kanban rule

The magical configuration that enables this process is the kanban rule. A kanban rule uses the activities that are configured for a production flow. Evaluating the possibilities of configuration of the production flow would go too far for this blog entry. To learn more about that, refer to the Whitepaper “Lean manufacturing for Microsoft Dynamics AX 2012 – Production flow and activities.” Assume that for the kitting application, a single activity production flow, as described in the whitepaper, could apply.

In the actual case, the kanban rule is a manufacturing kanban rule with a replenishment strategy event.

The packaging activity is followed by a transfer to a vendor managed warehouse.

Some highlights of the kanban rule configuration should be emphasized in the context of our scenario. Let’s start with the Product selection field in the Details FastTab of the kanban rule.

Notice that product CSS_SS_CUST is a configurable item for which the configuration dimension is mandatory. A configuration is not assigned to the kanban rule, so it is valid for all configurations of this product. In other words, any kit that is configured based on this model by using the product configurator will be supplied using this kanban rule.

The Events FastTab specifies the events that will trigger the creation of a kanban. In this case, Manual is selected in the Sales event field. The event cannot be created automatically when using the product configurator because the configuration of the line must be completed before the event kanbans are created. The dependency to the source requirement – in our case the sales line – ensures that the sales line cannot be shipped before all kits have been assembled and received. However, in the current example, a reservation is not needed. Because every sales line will have a separate configuration it’s unlikely that the wrong kit will be reserved so the lean approach would be to not make a reservation.

The maximum quantity of a kit per kanban is 1. Every kit creates a separate kanban and receives a separate kanban card. The automatic planning quantity of 1 ensures that every
kanban is directly loaded to the schedule, so the picking and packaging can start immediately after the kanban is created from the sales order line.

Depending on the settings of the kanban rule, the kanban card can be printed automatically in two ways:

When the kanban is created,
When the first activity is planned for the kanban and printed on the printer that is associated to the work cell responsible for the picking activity.

The picking list can be automatically added to the kanban card as well. Instead of having to look at the kanban board first, the worker can take the kanban card directly from the printer and start the picking process. When the kit is assembled, the worker can complete the packaging activity by scanning the card ID.

Costing the Kit

In many cases, the cost of a kit is mainly driven by its components. The cost of the packaging activity can be calculated based on the activity time. To enable the full cost support for the kitting solution, the cost price needs to be calculated and activated for each configuration. However, the value of costing the kitting might be really low, especially if this process usually creates no or only low variance. On top of that, the configured kits usually don’t stay in the warehouse for very long because they are assembled to order shortly before the shipment. For this reason, it might be a good idea to configure the kit so that it has only one standard cost activated for all of its configurations. This is done by clearing the Use cost
price by variant check box in the product master.

This configuration will result in material variances because different materials are used in the kits. To avoid manual corrections, the account that is used for material variance could be redirected to the cost of goods sold. Some people might disagree with this, but from the lean perspective, if costing of the kits and the related variances are not an issue then a manual or even an automatic cost calculation and activation should be avoided.

Both Product configuration and Lean manufacturing in Microsoft Dynamics AX 2012 are powerful tools that support manufacturing and the logistics processes required in many industries. When combined, they can support many use
cases in a very flexible way. I hope this example provides insight into the capabilities and opportunities and how they can be used to empower your business.

The approach that is described in this blog might leave open a couple of requirements that a kitting process in your company might require. If that’s the case, we’d very much like to hear more about your scenarios. But without a doubt we would also like to hear from you if this matches your requirements.

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

Logging and Tracing Dynamics AX MRP Runs

Understanding why software acts like it does can be an overwhelming task. There can be discrepancies between what we expect a program to do and what it actually does. The more complex a program is the more likely we are to experience these discrepancies.

Master planning (MRP) in Microsoft Dynamics AX is a prime example. Because it’s designed with a huge set of parameters that provide the flexibility required to fit a wide variety of businesses, configuring MRP is a complex task. And, historically speaking, the lack of transparency has made it difficult to analyze and understand the results of an MRP run by looking at its configuration. To provide this transparency, tracing and event logging functionality that gives a planner better insight into an MRP run has been added to Microsoft Dynamics AX 2012 R2.

Enabling MRP Logging and Tracing

The new logging and tracing features in MRP come in two flavors: One is purely a UI centered experience. The other ties in to the existing facilities for tracing and logging, and uses the Event Tracing for Windows (ETW) with the normal Microsoft Dynamics AX tracing providers.

Tracing/Logging in the UI

The UI centered experience is a powerful, light-weight tool that a planner can use to find out why certain choices were made during an MRP run, and to validate changes in an MRP configuration. A planner can quickly view the impact of a change when the dynamic master plan is updated. The Explanation tree view uses familiar UI elements, which makes it easier to use. In Figure 1 below, the requirement calculation is set to update an explosion for a production order (note that the Explanation tree view is available only for explosions). The setup for this requires only that the Enable trace check box is selected.

Figure 1

When the explosion is complete, information about the MRP run is displayed in the Explanation tab on the Explosion form. Figure 2 provides an example of what the explanation looks like.

Figure 2

A couple of things in Figure 2 are worth noting. First, the tree structure denotes the hierarchical nature of MRP. As can be seen from the tree, in producing the speaker enclosure (level 1), an issue is generated for which a receipt is sought. As none is found, a planned order is created (level 2). All of the details for the new planned order are listed and indented below the event – in this case the creation of a planned order. Additionally, the issue is pegged to the planned order, and at level 2 the initial futures date is set.

Another cool thing about the explanation is that you can perform a free text search. In Figure 2, for example, you could search for any lines that contain the word “delay.” If there are any hits, the text for the line is displayed in bold font. You can navigate between multiple hits by using the Up and Down arrows that are next to the Find text field.

Tracing/Logging of MRP Runs using Event Tracing for Windows (ETW)

While the tracing and logging experience in the UI is targeted towards the planner, the tracing and logging that uses ETW is geared more toward offline diagnostics scenarios. Using the offline capabilities requires the steps that are described in this section. Also, whereas the Explanation tree view is available only for explosions that are started manually to update the dynamic master plan, the ETW tracing is also available for generating full master plans.

First you must set up a data collector set by using the Performance Monitor utility. The steps to do this are as follows:

Open Performance Monitor.
Right click the User Defined node in the tree view, point to New, and select Data Collector Set.
Give the collector a meaningful name, like Dynamics AX MRP Trace.
Select the Create manually (Advanced) option, and click Next.
On the next step of the wizard, verify that the Create data logs radio button is selected, and then select the Event trace data check box. Click Next.
Note To avoid generating a lot of data that is not related to MRP tracing, you may want to clear the other check boxes.
You must now select the data providers. Do this by clicking the Add button.
In the dialog that appears, select Microsoft-DynamicsAX-Tracing, and then click OK.
After the provider is added, the Properties field displays properties related to the provider. In the list, select Keywords(Any), and then click Edit. On the list of properties that comes up, select MRP. Click OK to exit the Property dialog. In the wizard, click Next.

Figure 3
On the next step of the wizard, specify where you want to store the tracing data, and then click Next.
On the final step of the wizard you can either change some selections or click Finish to accept the defaults.

You can verify that ETW has started collecting the tracing data by clicking the new collector set (in the example, it’s “Dynamics AX MRP Trace”) and then looking at the icons on the toolbar.

Let’s take this functionality out for a spin by doing the explosion again. The same information that was displayed in the UI in the example is now available to a multitude of tools via the data collector. For instance, you can use Event Viewer to open the log file that the data collector creates, and you can export the data to Excel or to a database for further analysis. Let’s look at an example of what the data looks like in the Event Viewer.

To view the data, start Event Viewer. Right-click Saved Logs, select Open Saved Log and navigate to the location where you store the log data. The file should be called DataCollector01 or something similar, depending on how many data collector sets you defined. After selecting the data collector, you’ll be prompted to decide where the log data is to be displayed in the Event Viewer tree – I usually just select the default.

Since the collector we defined is collecting all data related to MRP, there will be a lot of events logged. In my particular case, the number of events is around 9,500. Fortunately, you can filter by clicking the Filter Current Log in the Actions pane on the right hand side of the Event Viewer. In this context, the two events of interest are:

107 (This will be referred to as ReqExplanation)
108 (This will be referred to as ReqExplanationDetail)

You can specify multiple events in the filter dialog by separating them with commas. Using the filter to limit the number of events in the view leaves around 650 events from my MRP run.

The first of the event types, ReqExplanation, is shown below in Figure 4 below.

Figure 4

The following table describes a couple of interesting pieces of information that the event log gathered during the MRP run.

Message	This is the message that would be displayed in the Explanation tree view.
Trace ID	Each trace has a unique identifier that all events relate to. If you run MRP multiple times in a data collector session, the trace ID lets you identify the events that belong to each run.
Event ID	This is the unique identifier for the particular event. As you’ll see shortly, this is used to tie together related events in the MRP run.
Plan Version	Version of the plan in which the records were created.
BOM Level	The level of the BOM that is being examined by the MRP scheduling.
Req Level State	Indicates the state for each level while in the master planning run.
Req Process Status	Scheduling process status.
Sequence	The sequence number of the event, so that events can be ordered chronologically.
Item ID	The item that is being examined.
ReqTransRefId	Reference to the ReqTrans to which this message relates.
Message Type	The type of message that is being logged. This allows for filtering of message types in a locale independent way.

The second type of events logged, a ReqExplanationDetail, is shown below in Figure 5.

Figure 5

Message	As for the ReqExplanation event type, this is also displayed in the Explanation tree view.
Trace ID	The unique identifier of the trace.
Event ID	The unique identifier of the event.
Parent Event ID	The unique identifier of the parent event that the detail relates to.
Sequence	The sequence number of the event, so that events can be ordered chronologically.
Message Detail Type	Type of message detail being logged. This allows for filtering of message types in a locale independent way.

Looking at Figure 4 and Figure 5, one major difference between the Explanation tree view and the ETW stands out. While the Explanation tree view graphically shows the BOM levels that were considered during the MRP run, that cannot be done graphically if you use ETW. To doing this by using the data from the ETW, you’ll have to examine the sequence and BOM Level fields in the data. Also, a detail event (108) is tied to its parent by the Parent Event ID field (incidentally, the two examples shown here are parent/child as the Parent Event ID of the ReqExplanationDetail (shown in Figure 5) matches the Event ID of the ReqExplanation (shown in Figure 4).

So, What’s the Cost?

Obviously, cool features like this are not entirely free of charge. We have, however, done our utmost to limit the impact that this will have. First, the Explanation tree view is totally independent of the ETW logging. That is, you can have ETW logging for explosions and full master plans without enabling the Explanation tree view. Conversely, you can enable the Explanation tree view without having the ETW logging enabled.

Because of the nature of the two independent logging and tracing methods, we check in a couple of ways to ensure that we don’t spend cycles doing unnecessary work. For instance, since the ETW tracing is governed solely by enabling a data collector and the MRP keyword, before we do an explosion or master plan generation we check whether the required ETW setup steps have been completed. Based on this check, we minimize the impact during the explosion or when the master plan is generated.

This is simpler for the Explanation tree view: If you don’t enable tracing when you start an explosion, we keep that in mind when doing the explosion and thereby minimize the impact of the feature.

If you do decide to enable the ETW logging for a full master plan generation, there will be some cost related to generating the necessary messages to log. Despite the fact that the ETW was designed with huge volumes of events in mind, you should expect to see some degradation of performance. This, however, we think is acceptable as the feature is a diagnostics feature, and not meant to be switched on and left on, but only switched on while the diagnosis is going on.

Wrapping up this post, I think you’ll find great value in the functionality we have added to assist you in understanding choices/decisions made by the MRP subsystem. Finding the right configuration and set of parameters for master scheduling that are exactly right for your business is difficult. With the tracing/logging, we believe we have made that task a lot easier for you.

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 – Lot inheritance

Process industries often produce items for which certain characteristics, or attributes, of the ingredients need to be transferred or inherited to the manufactured items. These manufactured items may be finished goods and/or co-products. In many cases, only certain characteristics need to be inherited since these characteristics may become diluted when mixed with other ingredients. In some cases, the characteristic may represent an important attribute that needs to be tracked to the end items due to regulatory or other reasons.

Lot Inheritance enables users to configure items in a manner in which the product characteristics and shelf life information of the finished products can be updated by using the ingredients of the formula that is used to produce that item. For shelf life information, this enables users to define items so that the inventory batch that has the earliest shelf life dates updates the finished products, and the shelf life dates of the finished products are inherited from the inventory batch. For product characteristics, this enables users to define batch attributes for both the finished items and their ingredients, and then select the ingredients that pass their characteristics or attribute values to the finished good items. Users can also select to update co-products by using the same information for shelf life and product characteristics on a formula-by-formula basis.

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.