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

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.

Separating tactical and operative planning for master scheduling

Master scheduling has to deal with an increasing number of transactions, especially if a company goes through a lean transformation. The lean transformation leads to shorter lead times and smaller batch-sizes. Having reached the ideal of batch size one may suddenly increase the number of transactions that master scheduling deals with by factor 10 to 100.

This is especially true if your configuration is set for your operative scheduling – usually covering few weeks, or in the lean ideal a few days. But if you use the same configuration to calculate your tactical plan, that usually spans over a couple of month up to a year, the volume of transactions can be considerable. At a customer review we found more than 7000 planned transactions for a category C part – a part that should be planned on minimum stock level instead.

In a meeting I had with the planning team of the customer, it became transparent, that one of the challenges is to configure the lead times as well as the positive and negative days for master scheduling. You need to start with analyzing how demand patterns of different products and materials behave. Unfortunately, the formula “longer is better” does not apply here. Having 200 planned purchase orders in the future for an item that has a purchase lead time of only few days is – in lean terms – waste.

To limit the runtime of master scheduling on one hand and the number planned orders and action messages on the other side, It is recommended to work with 2 different plans:

An operational plan, that uses fences and other parameters from the coverage groups and item coverage, not overwritten by the plan itself. The operational plan is updated every night.

A tactical plan that overwrites the planning and coverage fences to a longer horizon to make a full explosion in all details. The tactical plan is re-calculated once a week, usually on the weekend. Firming of planned orders should usually not be done based on the tactical plan.

It is recommended to structure the coverage groups by demand patterns and use item coverage only to punctually override settings for products, that require special treatment or to evaluate modified behavior.

Negative / Positive days:

Positive days:
Positive days allows master scheduling to use a planned receipt to cover a specific demand, that lies n days before the demand. In other words, it allows master scheduling to plan for excess inventory to minimize the number of planned orders. To consider actual on-hand for any demand, the positive days have to be at least as long as the coverage fence. This is valid for low turning products or products that are covered by high security stocks. For quick turning products that have a regular replenishment or receipt per day, week or month (EPEI = n days) should use positive days that are close to the EPEI. Another way of expressing this: positive days should not be more than MAX 2 times inventory turnover rate.

Negative days:
Negative days allows master scheduling to use a planned receipt to cover a specific demand, that lies n days AFTER the demand. It basically allows Master scheduling to plan for being late. It is important to understand that in a supply chain this setting can cumulate for every planning step with the end result of allowing to be late on almost every planned order. Negative days are needed when the inventory or purchase lead times are longer than the corresponding Sales lead times, to avoid multiple creation of planned orders for the case where a new demand that cannot be covered is placed earlier than the new planned order will be scheduled.

In AX 2012, the new possibility of Dynamic negative days have been introduced.
Negative days can be hard to set, as lead time can be different for products assigned to the same coverage group. That is where Dynamic negative days should be used (found under master planning/ setup / master planning parameters). Once dynamic negative days is set, the lead time defined on released product (default order settings, site specific or item coverage) will always be the minimum negative date counted from today. If a demand is calculated in the future, then negative days will be equal to number negative days set on the coverage group.
This feature is a significant change in defining negative days, and should be much easier to define. When calculating with dynamic negative days, the negative days settings should now be 0-5 days – depending on the demand pattern of the related product, and not as earlier recommended = lead time. The usage of dynamic negative days will decrease actions and futures. + all issues that are within lead time will always see receipts within lead time. Especially useful for long lead time items, where periodic or min max is used as requirement policy.

For the improvement of the settings of the operational plan the following guidance should be considered:

The coverage fence of purchased material should not be longer than double the lead time of the material, ideally only 2-3 weeks longer than the purchase lead time. The operational plan should only contain planned purchase orders that are needed to take action by the planner, not the tactical forecast. If a planner needs a longer term view he can consult the tactical plan. For purchase products the positive days should be mostly equal to the coverage fence. Purchase
material should not have negative days = the purchase lead time or even better, use Dynamic negative days. Then purchase material should run with 0 negative days.

Planned transfers that are used for replenishment and internal logistics between warehouses should not have negative days. The positive days should also be very small, ideally 0 to create the planned transfers at the point in time that the transfers are really needed.

Finished goods should only have negative days, if the sales lead times are smaller than the corresponding inventory lead times (or for finished goods that are directly purchased, the corresponding purchase lead time). The negative days would then be the delta between sales lead time (first possible new demand) and the inventory or purchase lead time (first possible new supply). And again, the alternative is to use the Dynamic negative days principle, where again the negative days are calculated automatically based on the lead times.

Master scheduling with Microsoft Dynamics AX is truly a dynamic task. There are many ways of influencing the planning results and the performance of master scheduling by modifying the right parameters. The resulting plan can only be as good as the configuration allows – and of course, dependent on the quality of the actual and the forecasted demand. We would love to hear about your experiences and your best practices related to positive and negative days and Dynamic negative days. We are also interested in your experiences with multi-plan strategies.

Meet the Microsoft Dynamics AX manufacturing team at the AXUG Summit next week or at Microsoft Dynamics AX Technical conference 2012 in the manufacturing focus room.

AX2012 process manufacturing integrates to manufacturing execution

In previous versions it was not possible to collect data on shop floor for process manufactured products. Many customers use both process and discrete manufacturing capabilities in Dynamics AX in their environments regardless of whether they are generally dealing with process manufactured products or with assembled products. Therefore in AX2012 it was made possible to do data collection on products that were manufactured using formulae and batch orders. This post describes the context in which some decisions were made and also lists a number of enhancements to process manufacturing in AX2012 that make this possible.

Synchronous updates
Manufacturing execution in AX2012 is changed so that progress updates made on job registration are instantly updated in the production module. It is now possible to track the production progress within production module by viewing jobs and quantity form from production orders as soon as the progress entry is made. This is also extended to batch orders.

Job registration form
On the job registration form it is now possible to see operations or jobs depending on whether operation or job scheduling was run on batch orders. The setup required for this is described in the documentation here.
Since batch orders can produce multiple outputs, it is now possible to see these multiple outputs by shop floor worker on their terminal. This is made possible by allowing access to co-by products form from job registration form. It is possible to configure job registration form so the co-by products button appears here. Setup of action pane that is needed to set this up is described here.
It is now made possible to set up the action pane on job registration form so that linked quality orders to the batch order in progress can be seen from within the job registration form. This capability enables either shop floor worker or supervisor to easily access and see the status of quality orders for the batch order on which they are still recording progress.
It is now made possible to set up the action pane on job registration form so that linked non-conformances to the batch order in progress can be seen from within the job registration form. This capability enables either shop floor worker or supervisor see the associated non-conformances

Production status list page
This page is intended as an overview for shop floor supervisor. In previous versions it was not possible to see batch order jobs on this page.

In process manufacturing AX2012 it is possible to do the following.

View the batch order jobs,
View the formula connected to the batch order for which jobs are being displayed
View the non-conformances connected to the jobs being displayed
View the consolidated orders form, this form will show consolidated orders, bulk or pack orders that are related to the batch order that is currently in focus on production jobs list page
"Cancel finished report" button will cancel the quantity reported as finished against the batch order, just like in the case of production order

Report as finish
In AX2012 it is possible to report as finish multiple outputs through manufacturing execution. This is achieved by simply making it mandatory for the user to open up report as finish form while reporting quantity as finish. The report as finish form that opens up is standard form that is used for reporting against a batch order. So, all the capability of adding co-by products and reporting against already available multiple co-by products is possible just like through the production module.

Edit job lists form
This is a new form in AX2012 where it is possible to re-prioritize individual jobs. This allows greater flexibility on shop floor. None of the changes are synchronized with master planning and scheduling. Based on our research users wanted some capability to do this without the changes going through master planning and scheduling. Shop floor supervisors often change the resources or get asked to prioritize certain jobs and there wasn’t a way to capture such changes without running master planning. Running MRP is huge overhead, not in control of a single supervisor since it impacts larger site/organization and usually decisions of such an immediate timeframe should not be run through master planning. Therefore, this capability was added in AX2012 in Manufacturing execution module. This job prioritization can be done for individual jobs or multiple jobs. Jobs can be moved from one position to another in the queue. Resources allocated for a job can be also manually changed here if the allocated resource is not available for a short period for whatever reason. This capability is now also available for jobs originating from batch orders.

Inventory Picking
While picking for a batch order from manufacturing execution module, AX2012 ensures that picking is done in FEFO order is this is setup for the item being picked

Catch weight and production module
A number of new fields have been added to many forms. All forms that are used to process products and those that are used to show progress of products through shop floor have new fields to handle products that have dual unit of measure defined.

Forms that have been modified

Production journals
Route jobs form
Route form
Materials form

Grid setup for catch weight products
CW started quantity, CW start quantity and CW requested quantity are three new fields that can now be setup on the grid in the job registration form.

Catch weight and manufacturing execution module
Catch weight fields are now available on several forms so that products with dual unit of measure defined can be processed using the manufacturing execution module.

Forms that have been modified are:

Edit jobs list form
Change feedback form
Raw registrations form
Posted registrations form
Quantity reports form
Approve form

Hopefully this post introduces you to the changes made to allow shop floor workers to record progress against products that are being manufactured using batch orders and formulae.