'Demand forecasting in Dynamics AX 2012 R3' whitepaper available for download

Download the paper from http://www.microsoft.com/en-us/download/details.aspx?id=43128 if you want to learn more about:

– demand forecasting in Dynamics Ax 2012 R3 value proposition and market positioning

– what this forecast tool is, but also what it isn’t

– functionality details

– demand forecasting parameters and how to set them up

– troubleshooting and improving demand forecasting performance

Product Configuration: Setting values based on system variables – example, current user ID

In this blog post we will describe how you can set values
based on the current user ID by leveraging system-defined table constraints
together with the build-in query range methods.

If you are familiar with the Product Builder configurator,
you may by familiar with the User Profile
feature where you can associate a collection of default values with a given
user. Use the following description to achieve a similar behavior using the
Product Configurator.

Creating the System Table

The table we create for this example should look like this and have two columns, that is, one for
the User ID (uses the UserID EDT) and one for our user-specific value (an Integer to keep it simple).

Once the table is created, we can add the user specific data.

As seen above, we have added the value 42 for the Admin
user ID. The intention is that when the table constraint is created and used in
model, the attribute, which will be bound to the UserSpecificIntegerValue
column, will be assigned the value that corresponds to the current user ID.

Creating the Table Constraint

Now that the System Table is created, we can create the actual table constraint. This is done by
opening the Table constraint definition
form, under Product information management -> Common -> Product configuration models.

Create a new table constraint by clicking the new button.

Select System defined, and enter the name of the table created previously.

Add a column for the user-specific integer value and choose an integer attribute type with ranges.

Now comes the part which gives the attribute a user-specific value. This can be accomplished by
opening the Select query (SysQuery) form and entering the range specified
below. The content of the table will be filtered to just return the records
associated with the current user ID.

Click OK to complete the table constraint creation, click Next in the Wizard, and then click OK again.

Using the system-defined table constraint in a Product configuration model

Having just created our system-defined table constraint, we are now ready to use it in a Product
configuration model. Below I have create a very simple model with 3 attributes:

One integer attribute to hold
the user-specific value
Two boolean attributes for
     each of which I will be using the Hidden modifier with a condition
     expressing that the attribute is only to be shown if the user-specific
     value matches that of the current user.
     The “Only Admin” attribute will be hidden if the user
     specific value is different from 42.

Similarly, I have added an attribute named “Only Dmitry”, which only will be
visible if the user log on to Dynamics AX is associated with User ID Dmitry.

Once the attributes have been defined, it’s time to attach the table constraint to the
model. This is done by creating a new constraint in the constraints section and
selecting Table constraint in the opened dialog.

Then select the new table constraint and associate the user-specific value attribute with
the user-specific value column, as shown below.

Launching the model and understanding the results

We are now ready to launch the model we created with the attached table constraint. As can be seen
below, once the model is loaded, the User Specific Value is assigned the value 42 by the configurator. The “Only
Admin” attribute is shown and the”Only Dmitry” attribute is hidden.

This example can be extended to include several other concepts like hiding subcomponents and
grouping user specific value into table constraints. An obvious use case would
be that you hide some parts of the Product configuration model from the order
takers (Susan persona). This could be engineering-specific details and the
product designer (Emil persona) would still be able to see them.

Furthermore, the above pattern can be used together with other of the build-in query range
methods.

currentCompany
currentLanguageId
currentUserLanguage
currentLegalEntity
currentParty

Note:

It you are running
on a build that has a performance fix to run the XML generation in IL, you will
need to generate IL for the SysQueryRangeUtil class.

I hope you find this useful

PrivateProject_MyUserSpecificValuesDemo.xpo

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

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

Use of ingredient types for batch balancing in production

In an earlier blog post, http://blogs.msdn.com/b/axmfg/archive/2012/12/05/what-s-new-in-microsoft-dynamics-ax-2012-r2-potency-management.aspx#10421522, we introduced the new capabilities in Microsoft Dynamics AX 2012 R2 that support potency management business processes for process industries. This blog provides more information about the four ingredient types that were introduced, None, Active, Compensating, and Filler, and the impact that they have on how quantities are calculated for batch orders.

There are many examples of the use of potency; in chemical industry the percentage of caustic can be characterized as an active ingredient in Pottassium Hydroxide, alcohol can be an active ingredient is liqueurs or fat can be an active ingredient in foods. The amout of active ingredient will often vary around a target value for these products, and the purchase price and the amount to consume in further production will often be affected by this variation. The batch balancing process, which is described in more details here, is focusing on how to take this variation into account

The key to setup formulas, where items with active ingredients must be taken into account, is by the use of the Ingredient types on the formula lines. For the example we will be looking at product A, B, C and D which each represent a seperate Ingredient type.

Ingredient type: Active

You can specify the potency of a product by defining the percentage of its active ingredient. When a product with an active ingredient is included in a formula, the ingredient type on the formula line gets the value Active and cannot be changed. Products must have a potency specified for them before they can be used as an active ingredients in formulas.

The potency of a product is defined by the use of a base attribute of the product. The base attribute is specified from the Manage inventory tab on the Action Pane in the Released products form. Before the base attribute can be associated with a product, the product must have the following setup:

The batch dimension must be active for the product. This is done by assigning to the product a tracking dimension group with an active batch dimension.
The attribute that will act as the base attribute for the product must be defined as a product specific batch attribute for the product. (Manage inventory > Batch attributes > Product specific). The associated attribute must have minimum, maximum, and target values.

The balanced quantity of an active ingredient is calculated according to the target value specified for the base attribute. Batch orders for products that have active ingredients in their formulas must go through a batch
balancing process. The batch balancing process is carried out from the Batch balancing form, which is available from the Batch orders list page and Batch order details form when the batch order status is Started. The batch balancing process estimates the amount of each ingredient in the formula that is required to produce the product. The estimation is based on the potency of the on-hand batches that are selected for the production.

Example

Ingredient B has a base attribute X and a target value of 30, and it’s included in a formula that requires 30 liters of Ingredient B for every 100 liters of the product. A batch order is created with a batch size of 100 liters. The batch order is started, and during the batch balancing process the user points to a batch of Ingredient B that has a potency level of 35. Because the potency level of 35 is higher than the target value of 30, the balanced quantity of ingredient B is reduced with the ratio of the potency value and the target value of the batch compared to the estimated quantity. The calculation of the balanced quantity looks like this:

(30/35) * 30 Liters = 25,71 Liters.

Ingredient type: None

When using this type there will be no difference between the estimated quantity and the balanced quantity when performing the batch balancing operation.

Example

Ingredient A is assigned to an ingredient type None, and is added to a formula for a finished product. The formula calls for 10 liters of Ingredient A for every 100 liters of the finished product. When a batch order requires 200 liters both the estimated and the balanced quantity of Ingredient A is calculated as 20 liters.

Ingredient type: Compensating

A compensating ingredient can either offset or compliment the effect of the active ingredient in a product. Therefore, the quantity of a compensating ingredient that will be consumed depends on the potency of the product.

Opposing effect – If the amount of the active ingredient is higher than anticipated, less of the compensating ingredient is required. The earlier blog gave an example of ice-cream, where cream compensates for a higher concentration of fat in milk.
Complementary effect – If the amount of the active ingredient is lower than anticipated, you need to add more compensating ingredient. The earlier blog used potato chips as an example, where more oil was added to the boiling process when the degree of moisture in the potatoes is higher than anticipated.

The relation between an active ingredient and a complementary ingredient is set up in the “Compensating principle” form, which is available from the Action Pane in the Formula lines form. You need to select the line that represents a compensating principle, and then point to the active ingredient you want to compensate. In the compensating principle, you also specify a positive or negative compensating factor to determines how much to compensate for and whether the principle should be opposing or complementary. A positive factor is used for complementary, and a negative factor is indicates opposing.

Example

Ingredient B is an active ingredient that has a base attribute X and a target value of 30. It’s included in a formula that requires 30 liters of Ingredient B for every 100 liters of the product. Ingredient C is a compensating ingredient, and is included in the same formula with a quantity of 10. The compensating principle is set up with a factor of 1.10. With a factor of 1.10, the balanced quantity of the compensating ingredient will be reduced by the difference between the active ingredient’s balanced quantity and the estimated required quantity multiplied by 1.10

In a previous example, the balanced quantity of the active ingredient needed was calculated to 25.71, and the estimated required quantity was calculated to 30. In this case, the balanced quantity of the compensating ingredient would be calculated as follows:

Difference between estimated and balanced quantity:

25.71 – 30 = – 4.29

Multiplied with compensating factor:

4.29 * 1.10 = – 4,72

Compensating estimated quantity will be reduced with -4.72 in order to calculate balanced compensating quantity:

10 – (- 4.72) = 14.72

Because 1.10 is a positive factor, this is a compensating principle with a complementary effect. And because the active ingredient is more potent than anticipated, more of the compensating ingredient is required.

Ingredient type: Filler

The filler ingredient is a neutral ingredient used to reach the desired output quantity of the finished product. Adjustment to the filler quantities are calculated based on variations in the active and compensating ingredient compared to the standard quantity.

Example:

We have formulated a product with ingredient A, B, C and D for a formula size of 100 liters. We have calculated the balanced quantity of all the ingredient types except for the line with ingredient type Filler. The balanced quantity of the filler ingredient calculates as the difference between the batch size of 100 liters and the sum of the ingredients:

100 – 20 – 25.71 – 14.72 = 39.57

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

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.