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

Support for Recycled By-products in AX 2012 R3 CU8

This new functionality is available with KB 2989470 / HF 2989470 and will be included in Microsoft Dynamics AX2012 R3 CU8. To find the HF you can use LCS Issue Search.

What’s new?
To support recycled or recurrent products in process industry, it is now possible to use the same product as both input and output on a formula. As an example, this is useful in plastic molding where consumed plastic regrind can be recovered from the manufacturing process. Other examples are processes where you put metal scrap from the stamping/forming process in a foundry.
The recurring co-product solution in Microsoft Dynamics AX2009 had some limitations on the costing side and was not ported to AX2012. This new solution use by-products with a stronger support for costing.

Feature solution
This new feature enables the consumption and reuse of the same by-products in the production of formulas and batch orders, by allowing BOM circularity for output that has the production type, By-product.
For costing purposes a new Burden type, Recycled, was added to handle the cost of the recycled by-products. Use of the Recycled Burden type deducts the joint production cost that is allocated to the formula and co-products, by using the standard cost value of the recovered by-product.
By-product output from planned and firmed batch orders is ignored during planning. This is done to ensure that demand for the recycled product isn’t pegged against by-product output from the same order, or other orders from the same process or BOM chain. This means that the recycled by-product cannot be pegged until it is on-hand (posted from the batch order).
Finally as a small additional improvement on the Explosion form, it is now indicated when a formula output is a by-product. This is done by adding ‘(By-product)’ to the line.

Set up recycled by-products
In order to allow BOM circularity, the recycled item must use standard cost and use the production type By-product or in special cases Co-product. On the formula the recycled product input is a normal formula line, and the output on the same or other formulas is a co-product output of the Production type, By-product, and the Burden type, Recycled.

Product

The recycled functionality only supports standard cost, so ensure that you select an Item model group that uses the Inventory model, Standard cost, on the General FastTab:
Ensure that the Production type is By-product on the Engineer FastTab for the product:

Note: Products with production type Co-product can also be used, but then you will have to change the Production type to By-product on the formula or batch order, to use the recycled by-product functionality.

Input – formula consuming the recycled product
The recycled product is added as a normal formula line on the formula:
Output – formula producing the recycled product
On the formula (can be the input, or another formula) that produces the recycled item, the recycled item must be added as a co-product output of the production type, By-product, with the Burden type, Recycled:

We are aware that the name Burden is not full correct with the Recycled option added. However, the nature of a hotfix release didn’t leave room for renaming.

Let’s try an example to see the feature in action:

We have the following three products:
M1 – Main ingredient, Standard cost – $10/Kg, Purchase, 100 kg On-hand
B1 – By Product, Standard cost – $5/Kg, Purchase, 15 kg On-hand
F1 – Formula item, Standard cost, Production, 0 kg On-hand

To produce F1 we use the following formula:
F1-FORM, Formula Size: 10 Kg

With the following lines
M1, 20 kg
B1, 10 Kg

Co/By-Product lines
B1, Production type = By-product, Burden = Recycled, 8 Kg

In AX it looks like this:

With the B1 added as By-product under the Co-products output:

First sales order
To generate a demand for F1 let’s create a sales order for 10 kg:

Running the explosion on the sales order will generate a batch order to produce the 10 kg because we don’t have any F1 on-hand:

Notice that the first line for B1 indicates that we get an additional co-product output of the type, By-product.

As both M1 and B1 are on hand, we can firm the planned batch order and start the production. (Planned orders -> Firm)

Processing the batch order
Let’s report the batch order as finished with the expected input and output:

What happened to the cost?
I have set a material overhead of 10%, so looking at the cost perspective we get the following.

Batch cost:
     M1 20 kg = 20 * $10 = $200
     B1 10 kg = 10 * $5 = $50
     Overhead 10% = 10% * ($200+$50) = $25
     Total = 200+50+25 = $275

B1 cost share (8kg): 8 * $5 = $40 (note this is fixed to the Std. Cost – no overhead)
F1 cost share (10kg): $275 – $40 = $235 (Incl. all $25 in overhead)

For the formula product – F1:

And for the by-product – B1:

Second sales order
Let’s create another sales order for 20 kg F1, to see how planning handles a shortage of the recycled by-product.

Running the explosion on the sales order will generate a planned batch order to produce the 20 kg. Notice the planned order for B1.

We still have plenty of M1:

We have 80 kg and we need 40 kg for the additional order.

However, we are running short of B1:

Initially, we had 15 kg. The first batch order consumed 10 kg and output was 8 kg, so now we have 13 kg.
For the new order we need 20 kg, so a planned order for 7 kg is created to cover the missing ingredient.

Summary:
With HF 2989470 that is included in Microsoft Dynamics AX 2012 R3 CU8, it is now possible to recycle and reuse by-product output from batch orders.

The recycled product must use standard cost and have the production type, By-product or Co-product
On the formula, co-product output must be of the type, By-product, and have the Burden type, Recycled
Planning will now consider only on-hand inventory for by-products. So potential supply from batch orders is not used for pegging until the batch order output is posted.

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

Understanding the default configuration concept for constraint-based products

Introduction

The default configuration concept enables users to start the product configuration process when the main product master data are available within a legal entity. You can learn more of the details of this concept in this post.

The default configuration concept

You must use the configuration technology Constraint-based when you configure product masters and the product masters must be configured with only one active product dimension, the Configuration dimension. We refer to the products masters as constraint-based products throughout this post.

To create a constraint-based product you must specify a valid product dimensions group which complies with this requirement.

Figure 1 Error message when the wrong dimension group is selected

You use the Configuration dimension to capture the final product configuration of a certain product model. The product model is represented in the system as a new product variant with a specific configuration dimension value. This is how Dynamics AX distinguishes between different results of the final product configuration. This allows you to complete a lot of tasks, such as:

Record and view on-hand inventory for individual configurations.
Run master planning against specific customer requirements (and across different legal entities).
Reuse existing product definitions in order to create products that are identical to existing products. You can also apply existing product definitions across legal entities.

Once you have released a constraint-based product to a legal entity, you can kick off a product configuration process from the following source document lines:

Sales order line
Sales quotation line
Project order line
Production order line
Purchase order line

The product dimension Configuration must have a value before you can start the product configuration process for a selected constraint-based product on an order line. Also, all active product dimensions must be specified before you can save an order line. These requirements are based on a series of technical solutions which are consistent with the experience that many users have from the Product Builder functionality.

Note – This is always the case for stocked products .For non-stocked products, you can specify a product category instead of defining the particular SKU.

The default product configuration concept is dedicated to solve the above described issue. It enables end users to proceed with the product configuration as soon as the product has been released to the legal entity.

Figure 2 The Default configuration is just there, after the product release

When a constraint-based product is released to a legal entity, the system automatically creates and releases a default product variant with the configuration value Default. The Default parameter is derived from the Default configuration ID field on the Constraint-Based product configuration models tab in the Product information management parameters form. This form is located under Product information management > Setup. The Default configuration ID value is set automatically during system installation. It references the SYS Label @SYS331038, but you can always change the value.

Figure 3 Product Parameters form

The process to create and release the default product variant is completely transparent and once the Default configuration ID parameter is set, no further action is required. If the product is released to multiple legal entities, the same default product variant will automatically be released to all of those legal entities.

Once the default product variant is released to the legal entity, the system will also update the default product variant fields on the released product. The default configuration dimension value is provided when you enter the item number on the order line. Any end user can change this setup in order to, for example, always have a basic configuration of a specific product suggested on all order lines

Figure 4 The default product variant dimensions are set to match the Default Configuration ID

Summary

The default configuration concept makes it possible to start the product configuration process at the point where the main product master data are available within a given legal entity. In order words, it facilitates the first step in the overall process of configuring an order line and it goes without saying that the first step is a prerequisite to move on in the process. Thanks for reading.

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

Product configurator, new Calculations concept

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

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

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

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

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

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

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

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

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

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

Target attribute: widthLengthRatioBoolean

Calculation: widthAttribute > lengthAttribute

BOM line condition: widthLengthRatioBoolean

Route operation condition: !widthLengthRatioBoolean

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

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

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

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

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

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

Working with Overlap in Microsoft Dynamics AX

Conducting Dynamics AX Manufacturing training for a class in Malaysia, it became clear that the current documentation on Overlap in Dynamics AX was not telling the full story.
Therefore, I decided to write this blog.

So, what is Transfer batch and Overlap quantity?

In Dynamics AX ‘Transfer batch’ is the field used to control an overlapped schedule. Apics define ‘Overlapped schedule’ as “A manufacturing schedule that overlaps successive operations. Overlapping occurs when the completed portion of an order at one work center is processed at one or more succeeding work centers before the pieces left behind are finished at the preceding work centers.”

Overlapped schedule is also known as lap phasing, operation overlapping, telescoping or send ahead.

‘Overlap quantity’ is a calculated field on the production order – ensuring that we avoid gaps in the schedule, when the successor operation to the operation with a Transfer batch value, has a shorter process time.
The ‘Overlap quantity’ determines the first transfer batch size for the operation; the following transfers to the next operation will use the ‘Transfer batch’ value.

Overlap quantity example

Say you have a production order for 10 pcs and it has two operations 10 and 20, each operation taking 2 minutes per pcs:

Without overlap:

Normally operation 20 will start when the entire quantity (10 pcs) has been processed on operation 10

With overlap:

When you have specified something in ‘Transfer batch’ field, let us say 2 pcs, it means the next operation (in our case 20) can already start when only 2 pcs has been processed on the operation 10. The value from ‘Transfer batch’ is by default copied to the ‘Overlap quantity’, on the production order.

Why does the Overlap quantity sometimes change when I estimate a production order?

The ‘Overlap quantity’ parameter on the production order route is calculated by the system. This is done during the estimation (or scheduling) of the production order, to prevent gaps in situations where a later operation have a shorter process time than the current operation. The fact that the successor would be waiting for the delivery from the predecessor would be causing a gap.
So, the calculation of an optimal ‘Overlap quantity’ is done based on the ‘Transfer batch’ and the operation process durations on the route.

Overlap example with gaps (two operations):

Say you have a production order for 10 pcs and it has two operations 10 and 20, this time the first operation takes more time than the second does:
Opr 10: 20 min per pcs
Opr 20: 10 min per pcs
Again, we have a Production order for 10 pcs and Transfer batch quantity set to 2 pcs

Without any change during Estimation the jobs on the route would have a gapped schedule and look like this:

However, as the first operation in total will take 200 min to complete and the second will take 100 min you will get the following information when estimating:

With the change from 2 to 6 we ensure that there are no gaps between the jobs in the second operation.

Overlap example with gaps (three operations):

Now let us spice it up a bit and add another operation – Opr. 30 with a run time of 5 min per pcs. We will also set a ‘Transfer batch’ = 4 on operation 20

In this case, you get the following information during estimation:

Now the schedule will look like this:

Therefore, by updating the ‘Overlap quantity’ on the production order during the Estimation Dynamics AX ensures that production on the following operation can happen without any gaps – avoiding a gapped schedule.

Christian Rytt, Senior Program Manager at Microsoft Development Center Copenhagen

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