December 2012 – Devlicious.net

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.

What's new in Microsoft Dynamics AX 2012 R2 – Potency management

With this blog entry, I would like you to familiarize you with the concepts that we have introduced in Microsoft Dynamics AX 2012 R2 to support potency management.

Potency management lets users define products as having a concentration of an active ingredient. The concentration of active ingredient can be used to affect the amount of material that is required in production or the amount that should be paid to a vendor based on the
concentration level.

Process industries often have formulas that contain one or more active ingredients. For each active ingredient there may be one or more compensating ingredients. These compensating ingredients for a single active ingredient may have different effects based on the difference in the concentration level of the reserved inventory batch and the standard level of concentration for that particular active ingredient. In some cases, the requirement of compensating ingredient may increase to offset the increase in the concentration level of the active ingredient. In other cases, the requirement of compensating ingredient may decrease to offset the increase in the concentration level of the active ingredient. These are known as complimentary and opposing effects.

A complimentary effect occurs when the concentration level of the reserved batch for the active ingredient increases and therefore, less of the active ingredient is required and less of the compensating ingredient is required. A complimentary effect
also occurs when the concentration level of the reserved batch for the active ingredient decreases, and more of the compensating ingredient is required. In ice cream manufacturing for example, a formula for ice cream may contain milk that has a potency of 2% milk fat as an active ingredient, and milk powder as a compensating ingredient. If milk that has 4% milk fat is used for that production batch instead, then less milk powder, which compensates for the milk fat, is required.

An opposing effect occurs when the concentration level of the reserved batch for the active ingredient increases, and therefore more of the active ingredient is required and more of the compensating ingredient is required. An opposing effect also occurs when the concentration level of the reserved batch for the active ingredient decreases and less of the compensating ingredient is required. In food production for example, a formula for potato chips may contain potatoes that have a certain level of moisture, as the active ingredient. The compensating ingredient is the oil that is used to fry the potato chips. When the moisture content in the potato chips rises, then more oil is required to boil off the excess moisture. If the potatoes are drier, then less oil is needed.

There can be one or more formula ingredients that are configured as filler ingredients. Filler ingredients are used to fill up or ”top off” the batch quantity to achieve a required amount. Due to the nature of active ingredients and the required amount of compensating ingredients that result from the principle factor, the total amount of the active and compensating ingredients may be less than the estimated quantity totals. When this situation occurs, an adjustment is made to the quantities of filler ingredients to achieve the required quantity of the formula item. When more than one filler ingredient exists in the formula, then the adjustment amount is applied to the filler ingredients based on their relationship to each other.

Lean manufacturing for Microsoft Dynamics AX 2012: Event kanbans – the single piece flow

The ultimate lean goal – the single piece flow with zero inventories – is not an illusion. Many industries have been able to replace build to stock/supermarket by assemble to order scenarios that support single piece flow. Lean manufacturing for AX 2012 provides a powerful new instrument to support these scenarios: Kanban production and replenishment based on Events.

The best implementations of Lean manufacturing I have seen so far are mostly driven by a common pain: The explosion of item variants – for the most different reasons – makes it impossible to hold inventory on final product level, without running into a huge risk of holding excess inventory or even worse – constantly depreciating or expensing products that have been hold in the final product stock but cannot be sold based on material expiry or engineering changes.

The need to remove or at least reduce this huge waste of money and resources usually leads to the cleanest implementations of lean manufacturing. Final assembly, packaging and shipping activities are streamlined and aligned to the targeted sales lead time – shipping the product out of final assembly within a very short lead time, usually days or few weeks (ideally 1). Some industries – like JIS (just in sequence) in Automotive – reach lead times of 2.5 hours from call-off to shipment for an assembly process!!

No need to explain that this requirement lies beyond Master scheduling – even if some implementations of Microsoft Dynamics run a net-change on master scheduling in a frequency of 30 minutes.

The new Lean manufacturing framework of Microsoft Dynamics AX 2012 allows definition of kanban rules with the replenishment strategy Event. The creation of event kanbans based on this strategy is triggered by a source requirement and the new kanban is pegged to the source requirement.

The event kanbans replace the previously released modules of LOS-BTO Schedules (Lean order schedules – Build to order) and PTO Kanbans (Pull to order) that were part of Lean manufacturing for Microsoft Dynamics AX 2009 with a single
architecture.

The sales event

The sales event is triggered by the creation or a change of a sales line – no matter if this is happening manually, through enterprise portal or using the sales creation services of Microsoft Dynamics AX.

Each sales line creates one or multiple kanbans to fulfil the related demand, based on the maximum product quantity defined in the kanban rule that corresponds to the maximum handling unit size.

The kanban cards printed for sales event kanbans contain customer and customer order references and can be used as shipment labels for the handling units.

The kanban line event

Kanban line events can be created to pull from a pre-processing activity. In the following example a lean work cell assembles painted parts (B) to finished products (A). The kanbans for A can be of any replenishment strategy – fixed, scheduled or event. While all standard colours – red, green or blue – are picked from a supermarket that is replenished as fixed quantity kanban, the special colours – gold and silver – create event kanbans.

Another application of kanban line events is transfer of material to a production location. In the following example we are assuming that products are produced on two sites 1 and 2, the related components are produced on site 1 and stored in a supermarket. While process B on Site 1 can directly pick from the supermarket, the material for process B on site 2 needs to be transferred to site 2.

By defining a kanban line event withdrawal rule for the transfer from site 1 to site 2 for the item relation All, transfer kanbans are created for all BOM-lines of items in Process B on Site 2. The related kanban transfer jobs can be grouped to consolidated shipments with non kanban material that needs to be transferred to Site 2.

The BOM line event

Like kanban lines, where the picking or transfer issues of a kanban trigger other kanbans, a production order can consume material that is supplied by lean manufacturing. Again, this can happen by picking from a supermarket or by creation of a BOM line event kanban, that pulls material to the production order.

On estimation of the production orders for the final assembly, the BOM Line event kanbans are created and loaded on the Pre-Assembly work cell.

The kanban rule can enforce a consistent reservation, to ensure that the components supplied by event kanbans are automatically reserved for the source of demand, in this case a production order.

Pegging event processing

In different application scenarios the volume of kanbans that are created based on events can be in a range of few event kanbans per day – where event kanbans only cover exceptions – to multiple kanbans per minute. To find the right balance between actual requirement view in the work cells and performance load each event definition on a kanban rule defines the kanban creation policy:

Automatic
The event kanbans are created with the source of demand. On the creation of
sales order lines the correspondent event kanbans are directly created,
allowing the work cell or warehouse to take immediate action on the new demand.
This setting is recommended to be used, when execution is expected to happen on
the same day.

Batch
Instead of the event kanbans a pegging requirement is created. A recurring
batch process that is independent of master scheduling is processing all new
pegging requirements. This light-weight process can be set up in the background
specific to selected production flows or activities ensuring an appropriate
reaction time for every application scenario.

Manual
When event processing is a pure exception taken on priority and capacity
considerations, an sales order line or a kanban can be manually selected to
create event kanbans.

The minimum stock event

When running master scheduling in Microsoft Dynamics AX, additional planned orders are created whenever minimum on-hand is reached. For a lean manufacturing application that surveys minimum on-hand of important parts, this might easily lead to a delay of a day until the signal for replenishment reaches the replenishing work cell. The pegging event processing in Lean manufacturing for AX 2012 checks minimum inventory for selected kanban rules and creates the needed kanbans to replenish instantly.

Lean manufacturing without event driven scenarios is only half the story. Lean manufacturing for Microsoft Dynamics AX 2012 provides a complete suite of tools to model any pull based scenario and scale the processes on volume and frequency of demand. The time effective nature of the kanban rules that model the scenarios support continuous modification and improvement. The bad news is: you can no longer use Microsoft Dynamics AX as the reason why you are not going Lean – it is all up to you now.