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.

'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

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

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.