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.


Comments (7)
  1. Kurt Hatlevik says:

    Interesing approch. But my experience is that users prefer to have nested kit-lines as salesorder lines, to controll sales prices, VAT and statistics on each item.  

    Looking forward to try it, and will also demo it to some of my customers.

  2. Hi Conrad,

    Agree with Kurt – interesting mash-up of AX2012 capabilities to close a gap in kit driven selling and fulfillment. I can see this covering customer needs in some cases, leaving residual gaps in others. Kurt has called out one of those possible concerns already in his response. In many, but not all cases, the customer would want sales lines and accompanying sales confirmations to appear and be treated as individual line items on the sales order and not a single sales line item with a single price, taxes, etc. This would translate through to pack slips and invoicing as well, especially in the case where the recipient will want to receive and price / pay for the individual items that comprise the kit and not just the single configured sales line item.

    Processing the fulfillment as a sales kanban also may work in some cases but not in others. Where I see it working as described would be in scenarios where the warehouse has its kitting & pack-out functions set up as a unique workcell type of activity. In the warehouse vernacular I am used to this is referred to as a "retail pick face" type of arrangement. Where it needs a little more fleshing out would be where a retail pick face approach is not used, and instead a "shopping cart" type of approach is in use. With the "shopping cart" approach, individual line items required for fulfillment of a kit are included in bulk picks from a generic bulk storage setup along with many other picks. Pickers go and grab these items along with the other items being pulled for outbound orders (hopefully following some guided picking rules for efficiency's sake :-), but instead of dropping these picks at a general packing station they are directed to a separate kit packing operation. Here, the outbound kits are queued waiting for required goods that comprise the kit to show up. Once they all have arrived the kit is completed and outbound packing slips, bills of lading, pallet labels (if required) and shipping carrier consigment (like with UPS via Shipping Authorization) are completed. Just daydreaming here, but I'm thinking that triggering transfer orders for goods to be moved from bulk storage to the kitting fulfillment operation may meet the warehouse pick needs in the "shopping cart" type operation, but still see potential for gaps in generating the outbound shipping documentation.

    Last thing on my mind at the moment would be handling of various returned goods scenarios that surface around products that are initially sold and distrubuted as kits. Need to ponder this some more.

    Thanks for the ideas, I'm adding them to my arsenal of possibiliites too!!!

  3. Narendra Singh says:

    Irs really good one for kitting item.

  4. Evert J Bos says:

    This is an assembly -to- order scenario. I do not know a customer who would find this suitable.

    The essential thing of kits is that there is no assembly of any kind. It is a form of selling.

    One sales price for a bunch of part numbers. One sales order line and a bunch of inventory deductions. And one line on the invoice. Hi tech version of DAX had a solution for this. AXTENSION has a solution for kits that seems to be quite complete (I have not verified). I have done a pretty big customization for kits, in the sales module.

  5. Evert, obviously there are differnt kind of kitting scenarios depending on the industry and the specific use case. As you correctly state, a kit usually has one price that usually is not just the sum of the prices of the components.

    In some kitting scenarios, the components of a kit are packed into one or few common packages, and this is what this scenario adresses. In other cases the components of a kit are picked and sometimes even shipped separatly. I have worked with quite a few customers that needed to pick an pack kits according to specific configuration rules, and they called this process kitting, not assemble to order (as obviously, there was no assembly done, just a packaging operation).

    As you correctly state, there are other business scnearios that go beyond the discribed scenario and I agree that some ISV soltutions cover them pretty well.

  6. HARI says:


  7. SverreThune says:

    If you have two components on the same level in a product configuration model. Tiy can write a constraint on any level above the two components which control their behavior.

Comments are closed.

Skip to main content