Product Configuration Synchronous Execution

This blog post describes an new way of interacting synchronously from code with the
Constraint-Based Product Configurator which has been introduced in Microsoft
Dynamics AX 2012 R3 CU8.

 

Scenario

The scenario that drove the introduction of this feature can be described as follows:

 

An external 3rd party sales configurator outside of Microsoft Dynamics AX 2012 is used to
assign values to a subset of attributes(a partially configured order), from
which the remaining mandatory attributes can have their values deduced using
the Microsoft Dynamics AX 2012 Configurator, thereby completing the order.

 

 

Once the all the values have been deduced, assuming all values are valid, they can be passed on
to the back end configuration module, which will create the BOM and potentially
the Route (if the model has a Route).

 

Implementation

Included in Microsoft Dynamics AX 2012 R3 CU 8 is a new derived version of the PCRuntimeConfigurator class, named PCRuntimeSynchronousConfigurator.

This class is designed, as the name indicates, for synchronous interaction with the .NET
Configurator component.

 

The configure method on the class is the method
which exposes the new functionality added to the .NET Configurator to Xpp. The
method takes three arguments; the model as xml, the attribute assignments as
xml and a the number of milliseconds which can be used before a timeout occur.
The return of the method is a IsConfigurationComplete enum value, from which
result of the configuration can be determined;

 

  • Complete
    • The configuration is complete
  • Incomplete
    • One or more mandatory attributes does not have a value
  • Timeout
    • The configurator was not able to complete the configuration within the given timeout limit
  • Contradiction
    • One or more constraints have been violated

 

Note:

The PCRuntimeSynchronuosConfigurator class exposes
the functionality required by the .NET configurator component to support the
above scenario but it is not yet integrated with any order (sales, production
etc) or product variant creation nor is it integrated with the BOM and Route
generation.

 

KB Article with number 3028719 should be Applied on top of R3 CU 8 as it addresses a stability issue in the solution.

 Example

 In this example values are passed from the simulated 3rd party configurator into Dynamics AX 2012 through a web service, as illustrated below:

 

 

To expose the PCRuntimeSynchronousConfigurator class through
a web service, we start by introducing a new class
PCTechDemoService
which implements a method with the SysEntryPointAttribute code attribute, which is
needed for a method to be exposed as a web service.

 

In this simple implementation the example method looks like this:

 

[SysEntryPointAttribute(true)]

public boolean configure(PCName _modelName, str _xmlValues)

{

    boolean ret;

    str values;

 

    PCRuntimeSynchronousConfigurator configurator  = PCRuntimeSynchronousConfigurator::construct();

    PCProductConfigurationModel productConfigurationModel  =  PCProductConfigurationModel::findByName(_modelName);

    values = ‘<Assignments>’ + _xmlValues  + ‘</Assignments>’;

   
if(configurator.configure(productConfigurationModel.getXML(), values,120000) == Microsoft.Dynamics.Ax.Frameworks.Controls.ProductConfiguration.IsConfigurationComplete::Complete)

    {

        ret = true;

    }

 

    return ret;

}

Now we can create a Service in the AOT which uses the PCTechDemoService
class and its configure method as an operation. To use this service, it needs
to be put in a service group, which can then be deployed.

 

 

To test the service, navigate to System administration > Services and Application Integration Framework > Inbound ports. Here we find our new PCTechDemoServiceGroup, copy the WSDL URI value.

 

 

 

Open Visual Studio Command prompt and type:

Wcftestclient <Your WSDL URI>

 

This will open the WCF test client where we can now see our web service.

 

For the demo data set I have used, I will use the following argument values

 

_modelName : 20001

_xmlValues : <Assignment xPath=”powerCableLength” value=”10″/><Assignment xPath=”videoSystem/television/size” value=”42″ />

 

Note: the xPath mechanism used to identify the attributes in model.

 

 

If you are familiar with the 20001(Home theater system) model, you will know that it has just two
mandatory attributes which are not assigned by defaults; the powerCableLength
on the root component and the size on the television component.

 

Attached you will find an Xpp project with code used for the example.

 

Enjoy

 

 

 

Demo.zip

Checklist for improving MRP performance – Part 1: How to run MRP

If Master Planning (MRP) runtime is too long, here are a couple of simple things you can try in order to improve it. The list was compiled for Microsoft Dynamics Ax 2012, so parts of the checklist may not apply to earlier versions. You must, of course, try these out on a test environment first and, if you see an improvement, apply the same settings to the production environment. It is recommended that you apply one setting at a time, so you can get a good sense of what helped and what didn’t. It is also recommended that the test environment is as close as possible to the production environment in terms of data volumes: number of products and number of transactions. If you are running MRP in recurrent batch, note that some of the settings will be cached, so it’s better to make the parameter change and re-create the batch and then run MRP again.

 

1. Use helpers for master planning

Using helpers (parallel processing threads) during master planning will most likely improve the runtime. Request one or more helper threads when running master planning, by setting the Scheduling helpers – Number of helpers parameter in the Master scheduling dialog to a value greater than zero.

More information about helpers can be found here:

TechNet: http://technet.microsoft.com/en-us/library/gg242496.aspx

InformationSource: https://informationsource.dynamics.com//RFPServicesOnline/Rfpservicesonline.aspx?DocName=TC2014+Help!++MRP+is+slow%7cQJ4JEM76642V-8-1608

Also make sure you have applied to the Ax environment the latest hot fixes related to helpers. Below are just a couple of KBs that you should consider installing or porting to your AX version:

KB article 2693422 https://mbs2.microsoft.com/Knowledgebase/kbdisplay.aspx?WTNTZSMNWUKNTMMYTPNRYVZNNPWYSWVQRWURNYWNXVKVRNQY

KB article 2690230 https://mbs2.microsoft.com/Knowledgebase/kbdisplay.aspx?WTNTZSMNWUKNTMMYTPNRYVZNNPWYSWVQUOLKVSMVQULNVYQT

KB article 2862912 https://mbs2.microsoft.com/Knowledgebase/kbdisplay.aspx?WTNTZSMNWUKNTMMYVWQXNRNXTVKNSKYVQNYNRZQRRRTPMQYY

 

2. Number of helpers used during master planning needs to be less than or equal to the maximum number of threads allowed on the batch server

It makes no sense to have the number of threads requested by planning greater than the sum of available batch threads on all batch servers in the selected batch group that runs master planning. Set the number of master planning helpers to be lower than the sum of available batch threads on all batch servers in the selected batch group to run master planning or increase the number of threads on selected batch servers.

To check the number of available batch threads per server/batch group go to System administration – System – Server configuration

 

3. Use multiple AOSs for master planning

Using more AOSs during master planning will most likely improve the planning runtime. It is also very important that you make sure no other lengthy routine is running simulataneosuly with master planning. It is also very important that you make sure no other routine requireing locks on tables used by master planning (for example InventTrans, InventSumLogTTS, ReqItemTable, etc) is running at the same time as MRP. 

 

4. Configuration keys that are not actively used should be disabled

For example, when Process Industries functionality is used, a lot of additional planning logic is being triggered, like for instance expiration dates for batches. This will increase the master planning runtime. If Process Industries functionality is not used, make sure the ‘Process manufacturing’ configuration key is switched off.

 

5. Action message usage

Calculating action messages leads to longer master planning runtime. If action messages are not analyzed and applied on a regular basis (daily, weekly, etc), consider disabling the calculation during the master plan run, by making sure the Action message time fence is 0 on the master plan you are running (Master planning – Setup – Plans – Master plans). Also make sure all the coverage groups have Action message setting disabled.

 

6. Futures usage

Calculating futures leads to longer master planning runtime. If you are not planning BOMs or if propagating delays from supply to demand during planning is not needed for you, consider disabling futures calculation during MRP, by making sure the Futures time fence is 0 on the master plan you are running. Also make sure all the coverage groups have Futures setting disabled.

 

7. Number of tasks in a master planning helper task bundle

Changing the number of tasks in the task bundle may have a positive effect on the runtime. The number of tasks in a bundle controls how many items are planned together by a single helper. It is recommended to increase the number of tasks when the number of items is very large (hundreds of thousands) and decrease the number  of tasks otherwise. In most cases it is a trial and error approach before an optimal value is determined. Remember to change this value as you add to Dynamics Ax more and more products!

 

8. Caching during master planning should be set to Maximum

Master planning logic is controlling the amount of caching used. This parameter is obsolete and is a candidate for removal in future versions of Microsoft Dynamics AX. In all the companies master planning is executed, consider setting Master planning parameters –  Use of cache to Maximum

Product Configuration: Setting values based on system variables – example, current user ID

In this blog post we will describe how you can  set values
based on the current user ID by leveraging system-defined table constraints
together with the build-in query range methods.

 

If you are familiar with the Product Builder configurator,
you may by familiar with the User Profile
feature where you can associate a collection of default values with a given
user. Use the following description to achieve a similar behavior using the
Product Configurator.

Creating the System Table

 

The table we create for this example should look like this and have two columns, that is, one for
the User ID (uses the  UserID EDT) and one for our user-specific value (an Integer to keep it simple).

 

 

 

Once the table is created, we can add the user specific data.

 

As seen above, we have added the value 42 for the Admin
user ID. The intention is that when the table constraint is created and used in
model, the attribute, which will be bound to the UserSpecificIntegerValue
column, will be assigned the value that corresponds to the current user ID.

 

Creating the Table Constraint

Now that the System Table is created, we can create the actual table constraint. This is done by
opening the Table constraint definition
form, under Product information management -> Common -> Product configuration models.

Create a new table constraint by clicking the new button.

 

Select System defined, and enter the name of the table created previously.

 

Add a column for the user-specific integer value and choose an integer attribute type with ranges.

  

Now comes the part which gives the attribute a user-specific value. This can be accomplished by
opening the Select query (SysQuery) form and entering the range specified
below. The content of the table will be filtered to just return the records
associated with the current user ID.

 

Click OK to complete the table constraint creation, click Next in the Wizard, and then click OK again.

Using the system-defined table constraint in a Product configuration model

Having just created our system-defined table constraint, we are now ready to use it in a Product
configuration model. Below I have create a very simple model with 3 attributes:

  1. One integer attribute to hold
         the user-specific value
  2. Two boolean attributes for
         each of which I will be using the Hidden modifier with a condition
         expressing that the attribute is only to be shown if the user-specific
         value matches that of the current user. 
         The “Only Admin” attribute will be hidden if the user
         specific value is different from 42.

 

 

Similarly, I have added an attribute named “Only Dmitry”, which only will be
visible if the user log on to Dynamics AX is associated with User ID Dmitry.

 

Once the attributes have been defined, it’s time to attach the table constraint to the
model. This is done by creating a new constraint in the constraints section and
selecting Table constraint in the opened dialog.

Then select the new table constraint and associate the user-specific value attribute with
the user-specific value column, as shown below.

 

Launching the model and understanding the results

We are now ready to launch the model we created with the attached table constraint. As can be seen
below, once the model is loaded, the User Specific Value is assigned the value 42 by the configurator. The “Only
Admin” attribute is shown and the”Only Dmitry” attribute is hidden.

 

 

This example can be extended to include several other concepts like hiding subcomponents and
grouping user specific value into table constraints. An obvious use case would
be that you hide some parts of the Product configuration model from the order
takers (Susan persona). This could be engineering-specific details and the
product designer (Emil persona) would still be able to see them.

 

Furthermore, the above pattern can be used together with other of the build-in query range
methods.

 

  • currentCompany
  • currentLanguageId
  • currentUserLanguage
  • currentLegalEntity
  • currentParty

 

Note:

It you are running
on a build that has a performance fix to run the XML generation in IL, you will
need to generate IL for the SysQueryRangeUtil class.

 

I hope you find this useful 

 

 

 

PrivateProject_MyUserSpecificValuesDemo.xpo

Supply chain excellence in manufacturing

Today I had the opportunity to take part at a Master Class on Supply chain management with Professor Martin Christopher from Cranfield University, Bedford, UK. The master class was hosted by Implement Consulting and the attendants were coming from all Industries in Denmark.

 

Professor Christopher succeeded to draw a relevant picture of the future trends and challenges to global supply chain management and to manufacturing in particular, and I would like to share a couple of quotes and thoughts.

 

  • Move from forecast driven to demand driven – Instead of planning to replenish inventory, establish supply chains that allow you to fulfill demand as a single event.
  • For products, where individuality and responsiveness are relevant, the agile supply chain – and the agile manufacturing process – must be designed for responsiveness,      not for the lowest cost. Responsiveness has to be built in the process and comes with a certain cost.
  • Substitute information for inventory – sharing information on demand and supply chain execution across the supply chain helps reducing or even eliminating inventory.
  • Flexible capacity – Move from static capacity to flexible capacity models, that allow to scale according to actual demand. Instead of acquiring manufacturing and distribution capacity based on forecast before the fact, a now model of
         acquiring capacity options that can be used on specific actual demand is emerging in the markets.
  • Economics of scale vs. Economics of scope – Instead of the volume of products, the bandwidth of products that can be delivered out of a supply chain drives the economic success.

 

It was an inspiring morning, leaving me with a lot of thoughts and ideas.

If you are inspired as well about these topics, join Roxana, Sverre and me at our session on Mass customization in a distributed supply chain in Microsoft Dynamics AX 2012 R2 at Convergence EMEA in Barcelona next
week, where we will share our vision on how the combination of product configuration, intercompany planning and lean manufacturing can bring you to the next level of supply chain excellence.

 

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.

image

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.

clip_image003

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.

clip_image004

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

clip_image005

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.

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

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.