MRP – Devlicious.net

Support for BOMs that includes items with different product dimensions of the same item

This blog post describes new functionality released with the Microsoft Knowledge base (KB) in article 3089402.

When using one or multiple of the product dimensions in production, you can have situations where you would like to produce an item, based on a different variant of the same item.
There are many scenarios where this can be useful, e.g.
• A Green variant of a specific item that is produced using a white variant of the same item.
• An item variant produced using a different configuration of the same item.
• Large item variant cut into multiple smaller variants of the same item.

Until now it has been mandatory to use different items for the parent and child product respectively. If this was not the case, the user would get a warning from the BOM check that circular reference is not allowed. If the warning was ignored MRP might fail. This warning was caused by the fact that the level check and the BOM level calculation was done per item.

With KB3089402 you can use the same item as both parent and child in a BOM – as long as minimum one product dimension differs.

This means that an item can now have multiple levels. In this case:
• Item A Config 1 is level 0
• Item A Config 2 is level 1
• Item A Config 3 is level 2

Required setup
Inventory model: To ensure correct costing, items with BOMs including variants of the same item must use standard cost.
BOM check: Circularity check strategy have to be set to ‘Optimize for high complexity’. The other option ‘Optimize for low complexity’ has not been updated, and will detect circularity for item variants produced from the same item.

High level KB changes
• Update BOM level calculation for planning: Will include any used product dimensions (Configuration, Size, Color, Style).
• A correct configured BOM will need to have at least one product dimension that differs. Blank is not a value. The product dimension that differ must be set on both parent and child item in the BOM structure.
• MRP, Predetermine cost calculation, and Actual cost calculation (inventory closing) is updated to use item and product dimensions with the new BOM levels.

Important implementation note
Ensure that the reqItemLevel table is empty before the first MRP (Master Schedule) run. Any change, like creating or modifying an item, will generate entries to the table and as a result it will not be empty.
The simplest way to do this is to truncate the reqItemLevel table, and then run a full MRP (regenerative with no filters). Otherwise MRP will not generate any planned orders!

Q&A

Q: What dimensions are supported?
A: The Product dimensions: Configuration, Size, Color & Style

Q: Will this require additional setup?
A: Only adding the relevant product dimensions to the BOMs, and ensuring to use Standard cost as well as the Circularity check strategy Optimize for high complexity. Also notice the implementation note regarding reqItemLevel.

Q: Will BOM circularity be checked for local changes on Production and Batch orders?
A: No, this KB is not changing what triggers the circularity check, as this is beyond the scope of the KB.

Q: Will this KB address issues related to rework scenarios, where exactly the same item and product dimensions are both input and output of production/batch order?
A: No, rework is outside the scope of this KB.

Q: What is the impact on performance?
A: Impact is none or minimal for both circularity check and MRP. There is a bit more data to process, but information is now stored outside InventTable. MRP tasks are per Product and BOM level, so multi thread of products with variants on different BOM levels is possible and can give minor performance improvements. Our tests have shown less than 5% change in performance based on this KB.

Q: Can I produce a specific variant from “any variant” – e.g. a Red variant from any (Blank) variant of the same item?
A: No, blank is not a value. The product dimension that differs must be set on both parent and child item in the BOM structure. So in this example you will have to choose a color for the used component.

Q: Will the BOM level calculation be stored in the same location for both Planning and Costing?
A: No, that changed with this KB. Costing will continue to use the current BOM level calculation stored in the InventTable. For planning (MRP) a new table is created to store the BOM levels with both Item and Product dimension information. This design will make it possible in the future to differentiate the processed data for Planning vs costing, e.g. ensuring that ended production orders are not included in BOM level calculation for MRP planning.

Q: Will the BOM consistency check uptake support for product dimensions as well?
A: Yes, with Circularity check strategy set to Optimize for high complexity.

Q: Does this mean that we now have the same options for product dimensions as for items?
A: No, but this is a step on the road to full variant support in AX – and a very important step 🙂

T-Shirt example with screenshots
A Green variant of a T-Shirt item is produced, using a white variant of the same item.

First we set the Circularity check strategy to Optimize for high complexity. Optimize for low complexity does not support BOMs that includes items with different product dimensions of the same item.

Create new T-Shirt item with Product dimension for Size and Color, using standard cost

Define size and colors for the product

Create all the variants for the product. We now have 9 variants of the T-Shirt:
– Size: Small, Medium and Large
– Each size in the Color: White, Red, Green

We can now create a BOM for producing a medium green T-Shirt, using a medium white T-shirt

The Circularity check will pass, since the color dimension differ

Say we made a mistake and tried to produce a medium green T-shirt from the same medium green. Then we would get an error, indicating that we have a circularity loop in our BOM:

Let’s modify the item coverage to ensure that the white T-Shirt is purchased. The green T-Shirt is produced and with a minimum of 3 to trigger a supply when running MRP

Now let’s run MRP and look at the planned orders generated for the T-Shirt

Notice that we get planned orders to produce 3 medium green T-Shirts, and purchase 3 medium white T-Shirts. Also, looking at the Explosion, you can see that the two colors have different levels

Checklist for improving MRP performance – Part 2: How to setup planning parameters

If Master Planning (MRP) runtime is too long, here are a couple of simple things you can try in order to improve it. You must, of course, try these out on a test environment first and, if you see an improvement, apply the same settings to the production environment. It is recommended that you apply one setting at a time, so you can get a good sense of what helped and what didn’t. Some of the settings below will not only have an effect on runtime, but may also improve your plan quality. The list was compiled for Microsoft Dynamics Ax 2012, so parts of the checklist may not apply to earlier versions.

1. Items assigned to the same coverage group should have similar lead times

Coverage parameters, such as the coverage time fence, negative days and positive days, relate to the lead times of the items inside the coverage group. If there is a disconnect between the lead times of the items and these parameters, master planning may create unnecessary planned orders, leading to potential suboptimal planning outcome and potential longer execution times. Items assigned to the same coverage group should have similar lead times.

Be sure at all times that you have the latest hot fixes related to lead times applied to your environment. One example is KB article 2938941: https://mbs2.microsoft.com/Knowledgebase/kbdisplay.aspx?WTNTZSMNWUKNTMMYZWLSWZQTLLRPPXLZNRORZMMMSSMTMNPU

2. Master planning parameters – Use dynamic negative days parameter should be checked

The negative days setting is connected to the lead time of the items. If the negative days are less than or equal to the item’s lead time, unnecessary planned orders may be created. Consider the following example: current date is 1st May, there is a sales order for 1 piece of item A on 5th May, item A has a lead time of 6 days and there is a purchase order for 1 piece of item A on 8th May. The negative day setting is 2, which is less than the item A’s lead time. Master planning will create a new planned purchase order for 1 piece of item A, which, according to the lead time will be delivered 7th May. This is just 1 day before the already existing purchase order. Firming this new planned purchase order may lead to unused inventory piling up. Creating planned orders that are not useful increases master planning runtime for no reason.

Checking Use dynamic negative days parameter makes sure that the connection between the item’s lead time and the negative days is taken into account during planning. Consider the following example: current date is 1st May, there is a sales order for 1 piece of item A on 5th May, item A has a lead time of 6 days and there is a purchase order for 1 piece of item A on 8th May. The negative day setting is 2, which is less than the item A’s lead time. Master planning will not create any planned purchase orders. The sales order will be fulfilled using the existing purchase order.

3. Negative days parameter on the coverage group should not be less than the lead time of the items assigned to the coverage group

If the negative days are less than the item’s lead time, unnecessary planned orders may be created. Consider the following example: current date is 1st May, there is a sales order for 1 piece of item A on 5th May, item A has a lead time of 6 days and there is a purchase order for 1 piece of item A on 8th May. The negative day setting is 2, which is less than the item A’s lead time. Master planning will create a new planned purchase order for 1 piece of item A, which, according to the lead time will be delivered 7th May. This is just 1 day before the already existing purchase order. Firming this new planned purchase order may lead to unused inventory piling up. Creating planned orders that are not useful increases master planning runtime for no reason.

Negative days parameter on the coverage group should not be less than the lead time of the items assigned to the coverage group.

A KB article you should make sure you have installed is 2736992 https://mbs2.microsoft.com/Knowledgebase/kbdisplay.aspx?WTNTZSMNWUKNTMMYMWMSYTMOWZPWLSWNTQWWSZZVXMWPMSOX

4. Positive days parameter on the coverage group should not be 0 or empty

If the positive days parameter on the coverage group should is 0 or empty, then existing incoming orders will not be taken into account for planning and new planned orders will be created. Note that on hand will always be consumed, regardless of the number of positive days set. Creating planned orders that are not useful increases master planning runtime for no reason. Firming these planned orders may lead to unused inventory piling up. Positive days parameter on the coverage group should not be 0 or empty.

5. Items that are regularly procured or produced should be assigned to coverage groups where the Positive days parameters is equal to the item’s lead time

If items have lead times bigger than the Positive days parameter on the coverage group, unnecessary planned orders may be created. Creating planned orders that are not useful increases master planning runtime for no reason. Firming these planned orders may lead to unused inventory piling up. Items that are regularly procured or produced should be assigned to coverage Groups where the Positive days parameters is equal to the item’s lead time.

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

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

1. Use helpers for master planning

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

More information about helpers can be found here:

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

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

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

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

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

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

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

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

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

3. Use multiple AOSs for master planning

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

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

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

5. Action message usage

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

6. Futures usage

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

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

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

8. Caching during master planning should be set to Maximum

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

Choosing the right coverage setting for when to Fulfill minimum

Why this blog post?
Multiple people have asked how the four different options to Fulfill minimum works and I was missing a detailed description of this. Therefore, I decided to describe the different options to ‘Fulfill minimum’ in Microsoft Dynamics AX.

So here we go:
Fulfill minimum defines when the Minimum (in this case 10) should be achieved. The minimum and the Fulfill minimum parameters are active for all Coverage codes, except for Manual that is not planned at all.

Today’s date
With ‘Today’s date’ planning will try to fulfill the minimum with a supply delivered today. However, unless the supply can be delivered on the same day (zero lead time) you will not be able to achieve this.

Example:
Product @Min is purchased with a lead time of 5 working days (7 calendar days)

Today’s date + procurement time
With ‘Today’s date + procurement time’ planning will fulfill the minimum with a supply delivered today + lead time + any safety margins. Compared to ”Today’s date’ adding the procurement time will prevent futures in most situations.

Example:
Product @Min is purchased with a lead time of 5 working days (7 calendar days)

First issue
With ‘First issue’ planning will place the supply to cover the minimum at the same time as the first issue (e.g. a sales order). This ensures that you do not carry unnecessary inventory for new products until there is an actual demand for them.

Example:
Product @Min is purchased with a lead time of 5 working days (7 calendar days) and Coverage code Period to combine demand within the Coverage period into one supply order.
Two sales orders for one pcs each exists: first on 17-07-2014 and second on 28-07-2014

Coverage time fence
With ‘Coverage time fence’ planning will place the supply to cover the minimum at the last day of the Coverage time fence.

Example:
Product @Min is purchased with a lead time of 5 working days (7 calendar days) and a Coverage time fence of 100 days.

I hope this explained the meaning of the Fulfill minimum parameter.

Whitepaper "Lean manufacturing – Capable to promise and Kanban job scheduling" for CU6 now available for download

With Microsoft Dynamics AX 2012, two new concepts were introduced for lean manufacturing:

Event kanbans, which support build-to-order and assemble-to-order scenarios, and also – in combination with the product configurator – configure-to-order scenarios.
Capable to promise (CTP), a new delivery date control method that can be used to calculate the expected delivery date at the time of order entry, based on an update of the dynamic master plan.

In the recently released cumulative update 6 for Microsoft Dynamics AX 2012 R2 these concepts have now been combined to work together.

The white paper starts by explaining the fundamental mechanics of kanban job scheduling for simple and complex production flow configurations. It then introduces the concept of capable to promise in general (lean and non lean applications), and explains how CTP interacts with planned and actual kanban jobs. Finally, it explains how CTP can be combined with event kanbans, and what changes are introduced in cumulative update 6 for Microsoft Dynamics AX 2012 R2 to provide better support for build-to-order and assemble-to-order scenarios with CTP.

You can download the whitepaper from these locations (requires registered Microsoft account):

Download URL – Customersource – Partnersource

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.

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.