Now available: Cumulative Update 7, featuring the product change case management

With the recent release of Cumulative Update 7 for Microsoft Dynamics AX 2012 R2, the case management functionality of Microsoft Dynamics AX has been enhanced for documenting and releasing product changes to production.

Many manufacturing companies will welcome this simple built in possibility of creating product change cases to document component substitutions in bills of materials or formulas, or changes in the production route, and of being able to visualize the impact of such component changes.

The new product change functionality provides enhanced support for approval and activation of the changes to bills of materials, formulas and routes that are associated with a product change case, which reduces the effort needed for releasing product changes to planning and production. This new capability also offers a new opportunity to integrate changes from an external PLM solution into Microsoft Dynamics AX with the context of the PLM change order with enhanced support for validation, approval and activation in production.

The diagram below illustrates the overall product change process, and highlights those elements (with black outline) that are supported by the new product change features in Cumulative Update 7 for Microsoft Dynamics AX 2012 R2.

Meet me at Convergence EMEA 2013 at the Manufacturing booth if you would like to see the feature in action.

We will soon share more details about this new functionality in this blog.

Download it now!

Microsoft Dynamics AX 2012 R2 Cumulative Update 7 (KB2885603) – build #6.2.1000.4051

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.

Product configurator, new Calculations concept

In cumulative update 6 for Dynamics AX 2012 R2 we are introducing a new concept
called Calculations in the Constraint-based product configuration models.
Calculations have many similarities with constraints in the way they are
created and maintained, but constraints are focused on limiting the number of
possible combinations and Calculations to enable mathematical expressions. One other
important difference between Constraints and Calculations is that Calculations
can work with decimal numbers. So for instance if the cable length for a home
theater system is decided by the room size it could be expressed as in the
screenshot example below.

If[ RoomSize / 1.33 > 7.5, 3.33, 6.66]

The image below shows how Calculations are defined for a product configuration model.

A Calculation, much like other product configuration model concepts, has a name
and a description to allow you to state the purpose of the Calculation.

Calculation expressions are uni-directional and the Target attribute receives the value
from the expression. The attributes can not be of type free text.

(It is possible to use a Text with a fixed list, also known as an Enumeration, but for a Target attribute of this type the return vale has to be the Integer order of the text value in the text list)

An attribute can both be used as a target attribute and
in expressions for other target attributes. The order of the calculations will
be determined accordingly.

The Calculation expression holds the logical or mathematical expression that
represents the Calculation. The expression syntax is similar to the syntax
available for expression constraints, but a wider range of operators are
available, such as the If operator shown in the example above. Also, both
decimal numbers and unbound integers can be used both as Target attributes and
in the Calculation expression. You can type the calculation expression yourself,
or build it using the new expression editor (Screenshot below). This is also a
new capability in CU6, and I will give a more detailed introduction in my next
post.

This enhancement makes it possible to manipulate decimal numbers at run-time during
configuration; you no longer need to express this type of operation through the
dedicated application programming interface represented by the PCAdaptor class.

In the screenshot above, the Target attribute is of type decimal number and it can be
used as a property on a bill of material (BOM) line or a route operation, but
it cannot be included in a constraint or a condition. If you want to control
the inclusion of a certain BOM line or route operation, this can be achieved by
using a Target attribute of type Boolean and then using the Target attribute in
the condition on the BOM line or route operation. Please see example below:

Target attribute: widthLengthRatioBoolean

Calculation: widthAttribute > lengthAttribute

BOM line condition: widthLengthRatioBoolean

Route operation condition: !widthLengthRatioBoolean

In this example the widthLengthRatioBoolean attribute takes the value true if the
widthAttribute is greater than the lengthAttribute and false if it is equal to
or smaller than lengthAttribute. The BOM line condition will include the BOM
line only if the calculation returns true, whereas the route operation will
only be included if the calculation returns false.

The introduction of the Calculation concept means that an attribute can get its
value set by four different sources:

User, value entered by the user during the configuration
Default, value set in the product model
Calculation, value resulting from a calculation expression
Constraint, value set by a constraint

In the matrix below the rows state, which input sources have the ability to overwrite
an existing attribute value. Overwriting a value set by a constraint would result
in a model, which is in contradiction, and thus the configuration cannot be
finished and saved. This is indicated by the * in the Constraint column cells.

So one example here is that a calculation can overwrite a value set by a constraint,
but then the configuration cannot be saved.

Input order matrix
		Can be overwritten?
		User	Default	Calculation	Constraint
Can overwrite?	User		Yes	Yes	Yes *
	Default	No		Yes	Yes *
	Calculation	No	No		Yes *
	Constraint	No	No	No

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

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

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 – 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.

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.