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

Whats new?

To support and efficient process for putting away produced material, it is now possible to define an output location specific for the last operation in the production route. This accurately reflects the location where the goods are reported as finished in production which will enable the warehouse worker to exactly know where to go, to pick the goods for put away. In AX2012 R3 it was only possible to define one output location. Below illustrations shows the difference between the R3 and the CU8 implementation of the output locations. The first illustration shows that all production orders within the warehouse reports to the same output location. The finished products are from here put away to the finished goods locations

The second illustration shows that each batch order within the warehouse reports to a separate output location. The warehouse worker will be directed, by warehouse work, to the output location where he must pick up the goods for final put away to the finished goods locations

This blog will explain how this new capability is enabled by using the official demo data released for Microsoft Dynamics AX 2012 R3 CU8 Virtual Machine (VM).

In the company USPI there is a formula for making Pellets. This formula will be used for showing how this feature is enabled and used. 

The illustration below shows the Pellets production. The item numbers for the ingredients (or raw materials) as MW4004 - Polypropylene and MW4005 - Rubber are pre-fixed with MW and the four end items are pre-fixed with PW. PW4000 - Pellets is the formula item, and PW4001 – Chips and PW4002 - Blocks are co-products. PW4003 - Slag is a by-product

Let us take a closer look how to enable this feature. First we need to setup the production output location. Looking at the route for the Pellets formula operation 40 DryFilling is the last operation

An applicable output location for this operation is found through the Resource requirements for the operation. In the Resource requirements, criteria for finding an applicable resource or resource group during scheduling, is set up

The output location is specified on the resource group, as it can be seen in below illustration

In case no output location is defined on the resource group, then a default production output location is used as a fallback location. This default output location is setup on the warehouse

In below diagrams the defaulting hierarchy is shown. The diagram shows the rule that applies for finding the production output location when reporting as finished a production or batch order

Example

To see how this works, let us report as finished a quantity of the formula item PW4000 – Pellets. The batch order is in status Started and is ready to be reported as finished

Reporting as finished is done from the mobile device

Batch order number, Item number, quantity and license plate is entered

And the process is completed and put away work is generated

Taking a closer look at the put away work, the pick location for this work is FILL-01. This location is the output location that was set up on the resource group that is applicable for the last operation DryFilling

Let us try to remove the output location from the resource group and then report as finished one of the co-products from the batch order

We report as finished a co-product PW4002 – Blocks and put away work is generated

The put away work will in this case have the default output location OUTPUT. This location is that fallback location set up in the warehouse

The defaulting of the output location is enabled for all the places where the reporting as finished process can be performed. This includes

• Using the report as finished function from the batch order
• Using the report as finished journal
• Reporting as finished from the job or route card journal. This is possible when user reports on last operation and mark field Report as finished on the journal line
• Report as finished from list page Current operations. This is possible when reporting as finished the last operation
• Reporting as finished from the Job registration form in the manufacturing execution module (MES). This is possible when the user reports as finished the last operation

Summary

In CU8 it is now possible to set up an output location for the last operation in a production route. This supports a more efficient process for putting away produced products from the shop floor to the warehouse. The output location is set up on the resource group that is applicable for the route operation. A fallback output location set up on the warehouse is used in case no output location is defined on the resource group. Using the output location defined for the last operation in the production route is applicable for all the places where the report as finished process can be performed.

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

Whats new?

The generation of put away work was in the AX2012 R3 release only enabled for reporting as finished a production or batch order from the mobile device. In CU8 put away work can now also be generated when reporting as finished a warehouse enabled item from the AX Client.

In this blog I am going to walk through two scenarios showing how put away work is now created when reporting as finished from the Dynamics AX client. In this example I am going to use item L0101 from the USMF demo data company

Simple scenario : Shannon has completed the assembly of ten speakers in her work cell. She reports the speakers as finished in the route card journal and put away work is generated

A production order for twenty pieces of mini-speakers exists and is in status Started

Shannon completes the assembly of the twenty Mini-speakers and reports the quantity as finished in the route card journal

Shannon provides the journal line with a license plate number

When Shannon posts the journal, put away work is generated

Advanced scenario : Shannon is working on a production order assembling ten Mini-speakers. Shannon has completed the assembly of eight speakers and reports them as finished in the job registration terminal form and put away work is generated. Shannon completes the assembly of the remaining two speakers but does not have time to report them in the terminal, because she has to rush home. Lars promises Shannon that he will take care of reporting the remaining quantity as finished

A production order for ten pieces of mini-speakers exists and is in status Started

Shannon has started the assembly of 10 mini-speakers

Shannon is now going to report eight pieces as finished from the Job registration form in the manufacturing execution system. In the feedback form Shannon provides a license plate number. This number identifies the goods that Shannon is reporting to the output location of her work cell. The license plate number will be used by the warehouse worker to identify the goods that he is going to put away from the output location to the finished goods locations

Note: The license plate field is enabled in the feedback form under the following conditions

• The item is enabled for the new warehouse processes
• The shop floor operator is reporting on the last operation in the production route

After Shannon has confirmed the feedback of eight pieces of mini-speakers, put away work is generated

As it can be seen this work suggests to put away the eight Mini-speakers from the production output location to the finished goods location.

In order to report the remaining two Mini-speakers, Lars opens the production order form and selects the report as finished function. Here he enters the remaining two pieces and the license plate. In this case he uses the same license plate as Shannon did when she reported the first eight speaker

After confirming the report as finished put away work has been generated for the remaining two speakers reported by Lars

The different options for reporting as finished is outlined in the table below. All these options now supports generation of put away work

Summary

In CU8 it is now possible to have put away work generated when reporting quantity on a production or batch order in the Dynamics AX client. This can for example be useful for customers who wants to enable the new warehouse processes offered in the R3 release, but wants to maintain using the shop floor terminal for manufacturing execution or enable the shop floor supervisor to make corrections.

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

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 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 inventory will not be taken into account for planning and new planned orders will 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. 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.

This post is part of the series of posts explaining performance improvements introduced in Constraint-Based Product Configuration in Microsoft Dynamics AX 2012 R3 CU8.

Motivation

The product configuration model is persisted in a normalized data model in the database. As a result of this, this tables in the data models will need to be queried in order to obtain all the needed information to load a product configuration model. The parent-child relation between components and subcomponents require that this is done in a recursive manner, thus it is not possible to retrieve all the information in a single select statement. For large models the traversal of the data model is a time consuming operation. However we are not just traversing the model, we are also constructing an XML representation of the model that is relevant for a given configuration session. If the model is not changing, all the end users are basically paying a performance penalty of having the same XML generated over and over again. This is why caching is has been introduced.

The setup

Runtime caching is disable by default, so you need to perform a contience decision if you would like to enable it. The parameter of enabling runtime caching is located in the Product Information management setup form.

Working with the cache

Once enabled, cached elements will be loaded with the latest cached value, if you change the value of a cached element in the model details form, be sure to clear the cache before loading the model.

It is not recommended to have the cache enabled during development of configuration models, because the cache will need to be cleared manually by pressing the "Clear cache" button i.e. the cache is not cleared automatically when you update the model.

The clearing of the cache happens on a per model basis, so even if two models are using the same components, clearing of the cache should be performed for both models independently.

The implementation

The runtime cache manager class is to be used for all interaction with the runtime cache. Both classes and record values can be cached see list be below for currently cached elements.

Current cached elements

• Tables (records)
• The entire model definition
• Classes
• RuntimeAttributeType instances used for system defined table constraints

Keys to the cache

• Product configuration model record ID
• Language ID
• Price model record ID
• Price model currency

The above elements define what is used as the identify an entry in the cache. If a request to load a configuration model does not match on all the key elements available in the cache, then the XML will have to generated for the specific request.

This post is part of the series of posts explaining performance improvements introduced in
Constraint-Based Product Configuration in Microsoft Dynamics AX 2012 R3 CU8.

The Solver strategy concept was first introduced in Cumulative update 7 for Dynamics AX 2012 R2 and has been extended in Cumulative
update 8 for Dynamics AX 2012 R3. It now includes the following strategies:

• Default
• Minimal domains first
• Top-down

What is a solver strategy?

Imagine you were given the task of solving a 100 piece jigsaw puzzle. How would you start?

A common solving strategy is to start with the edges and move towards the middle, most of us
will either have done this ourselves or if not it should be pretty simple to
convince yourself that this strategy is sound.

Now, what if the puzzle you have to solve does not have straight line edges (often referred to
as impossible puzzles)? Suddenly our edge-first strategy will be dramatically less efficient as the edges are much more difficult to identify.

For the Solver, a configuration model is a bit like a jigsaw puzzle which needs to be solved.
With the Solver strategy concept, we have enabled you to set the strategy which
the solver will use when it solves the model. Configuration models can however
be very different in nature and the strategy for solving one model efficiently
may prove to be inefficient to solve a different model.

What is the impact?

The impact of response times has been shown on real customer models, to go from minutes to
milliseconds. For this reason it is really worth your time to spend a few
seconds to change this one setting, to see if a change in Solver strategy could
have this impact on your configuration model.

You can change the Solver strategy setting in the model properties form.

Which strategy to choose

Currently there is no build in logic which automatically detects which solver strategy will be most efficient, so for now, you will have to try them out.

Default

What can be said about the different solver strategies is that the default Solver strategy has been optimized so solve models which rely on table constraints. On all the customer models we have seen which use table constraints to a large extend this
solver strategy has proved to be the most efficient.

Minimal domain first and Top-down

These two strategies are closely related. The Top-down strategy, which has been introduced with CU 8 has shown to outperform Minimal domain first in all of our studies, but for
backwards compatibility we have decided to keep the minimal domain first strategy
in the product. Both of these strategies have shown to be more efficient for
solving models which contain several arithmetic expressions and where table constraints are not used.

In short, negative days time fence represents the number of days you are willing to wait with negative inventory, before ordering new replenishment. But if you ever wondered yourself: ’How do the negative days really work?’, then keep reading.

In this post:

I will be explaining how planned orders get created, taking into account the negative days time fence.

I will touch upon the correlation between the negative days time fence and the item’s lead time.

I will also explain the Dynamic negative days time fence calculation and how that factors in the item's lead time into the calculation of the time fence.

I will also try to better explain the MRP runtime improvement suggestions related to negative days that you can find here: http://blogs.msdn.com/b/axmfg/archive/2015/01/02/checklist-for-improving-mrp-performance-part-2-how-to-setup-planning-parameters.aspx

I will explain the above in the context of three different situations. The difference between these situations is at what point within the item’s lead time you get demand.

Please excuse the poor quality of the screenshots. Click on them to get a better view :)

Situation 1

Item _DemoProduct has a 6 days purchase lead time

On day 0 (1st Jan) the inventory level for item _DemoProduct is 0

On day 0 (1st Jan) you get a sales order for item _DemoProduct, quantity 10

On day 7 (8th Jan) there is an existing purchase order for item _DemoProduct, quantity 10

Case A

Negative days are set to 2, a value not really close to the 6 days lead time of _DemoProduct. We don’t use Dynamic negative days.

In this case, MRP will look for receipts for item _DemoProduct within the negative days time fence, and since it won’t find any, it will create a new planned purchase order. This planned order will immediately be delayed with 6 days (the lead time) so it will arrive on 7th Jan. The existing purchase order will get a Cancel action message, since it is now made redundant by the creation of the new planned purchase order.

So far so good, but if you take into account MRP performance and plan nervousness it may be not so good. Why? From a performance standpoint, MRP had to create a new planned order, calculate delays and actions, which are all time consuming tasks. From a plan nervousness perspective, you just got 2 more transactions to deal with…

What you gained? The sales order will not be delayed with 7 days, but with 6 days.

Case B

If this gain is not that important for you, then what you could do is set the negative days to be greater than or equal to the item’s lead time. There is no way you can get the supply inside the lead time anyway, so then why not search for receipts as long as it makes sense? On the bright side, it will make MRP run faster, but beware of orders being further delayed!

Case C

Another thing you could do is use Dynamic negative days (Master planning – Setup – Master planning parameters – General – Coverage – Use dynamic negative days). This setting will automatically correlate the item’s lead time to the negative days time fence. What will happen in this case is that MRP will look for receipts inside the dynamic negative days time fence, which is calculated based on the following formula:

DynamicNegativeDaysTimeFence = PurchaseLeadTime* + NegativeDaysTimeFence + (TodaysDate – RequirementDate)

*If the default order type of _DemoProduct would have been Production or Transfer, than the lead time would be the Inventory lead time.

With Dynamic negative days, the time fence MRP looks for receipts is now 6 + 2 + 0 = 8. So MRP will find the existing purchase order and will peg the sales order against it. No new planned orders will be created, hence MRP runtime will be shorter. The Net requirements for _DemoProduct look as follows:

Schematically, this is what happened:

Case D

So what happens if you set negative days to 0 and use Dynamic negative days only? Would that help you deliver on time and not create impossible planned orders? This actually works just like not using Dynamic negative days, as in the example below.

If you set Negative days to 0 and use only the Dynamic negative days time fence, which will now be 6 + 0 + 0 = 6, you will end up in the same situation as in case A: from a performance standpoint, MRP had to create a new planned order, calculate delays and actions, which are all time consuming tasks. From a plan nervousness perspective, you just got 2 more transactions to deal with… The demand still can’t be fulfilled on time, it will be late anyway.

Case E

If you both set the negative days to be greater than or equal to the item’s lead time and you use the Dynamic negative days time fence as well, than this will be 6 + 6 + 0 = 12. This may lead to a very long time fence MRP will search for results in. At the end of this post, there is a section related to what happens if you set Negative days to a long time fence, so please refer to that in order to understand Case E.

Situation 2

Item _DemoProduct has a 6 days purchase lead time

On day 0 (1st Jan) the inventory level for item _DemoProduct is 0

On day 4 (5st Jan), inside the item’s lead time, you get a sales order for item _DemoProduct, quantity 10

On day 7 (8th Jan) there is a purchase order for item _DemoProduct, quantity 10

Case A

Negative days are set to 2 and don’t use Dynamic negative days.

In this case, MRP will look for receipts for item _DemoProduct within the negative days time fence, and since it won’t find any, it will create a new planned purchase order, order date current date. This planned order will immediately be delayed with 6 days (the lead time) so it will arrive on 7th Jan. The existing purchase order will get a Cancel action message, since it is now made redundant by the creation of the new planned purchase order, with delivery date 7th Jan.

Case B

This is similar to situation 1: if you set the negative days to greater than or equal to the item’s lead time, then you will not get a new planned order. The sales order will be pegged to the existing purchase order.

Case C

This is also similar to situation 1, in the sense that dynamic negative days will work just as well. The dynamic negative days time fence will now be 6 + 2 – 4 = 4. So MRP will find the existing purchase order and will peg the sales order against it. No new planned orders will be created, hence MRP runtime will be better.

Case D

If you set Negative days to 0 and use only the Dynamic negative days time fence, which will now be 6 + 0 – 4 = 2, you will again end up in the same situation as in Case A. For a graphical view, refer to Situation 2, Case A.

Case E

If you both set the negative days to be greater than or equal to the item’s lead time and you use the Dynamic negative days time fence as well, than this will be 6 + 6 – 4 = 8. This may lead to a very long time fence MRP will search for results in. At the end of this post, there is a section related to what happens if you set Negative days to a long time fence, so please refer to that in order to understand Case E.

Situation 3

Item _DemoProduct has a 6 days purchase lead time

On day 0 (1st Jan) the inventory for item _DemoProduct is 0

On day 7 (8st Jan), outside the item’s lead time, you get a sales order for item _DemoProduct, quantity 10

On day 10 (11th Jan) there is a purchase order for item _DemoProduct, quantity 10

Case A

Negative days are set to 2 and you don’t use Dynamic negative days.

MRP will look 2 days ahead from the sales order’s requirement date. Since it doesn’t find anything, it will create a planned purchase order on 2nd Jan, that will be shipped just in time to fulfill the sales order demand. The existing purchase order will get cancelling action message, since it’s not needed.

You may notice that in the above AX screenshot, the Purchase order Requirement date is 12th Jan. That is because the screenshot was taken in 2015, when 11th Jan is a Sunday, so MRP moves the Requirement date to 12th Jan, the next working day. But the purchase order has a Delivery date of 11th Jan.

Case B

This is a case to take a minute and think about. If you set the negative days to be greater than or equal to the item’s lead time, then you will not get a new planned order. The sales order will be pegged against the existing purchase order, so in this case the sales order will be delayed, although if you were to create a planned order you could ship the sales order on time!

Case C

This is also similar to situation 1, in the sense that dynamic negative days will work just as well and even better than if you compare to case B.

The dynamic negative days will be 6 + 2 – 7 = 1, but in this case the system will still consider the negative days lead time (2), because MRP takes into account the maximum value between negative days lead time and dynamic negative days lead time. So the result in case C is the same as in case A.

Case D

If you set Negative days to 0 and use only the Dynamic negative days time fence, which will now be 6 + 0 – 7 = -1, but in this case the system will still consider the negative days lead time (2), hence case A is the same as case D. So all the pitfalls you have in A you will have in D. For a graphical view, refer to Situation 2, Case A.

I will not refer to case E anymore, since it’s exactly the same as in situation 1 and 2 – it has more or less the same benefits and pitfalls.

Based on the above it seems a good idea to set the negative days to be greater than or equal to the lead time of the items in the coverage group and/or to always use dynamic negative days and set the negative days to number of days you are willing to wait with negative inventory, before ordering new replenishment (in other words, the number of days you are willing to further delay demand).

The above hopefully also illustrates why items in the same coverage group should have similar lead times.

If you set the negative days to 0 and you don’t use Dynamic negative days, then MRP will always create a new planned order to fulfill demand. So if you setup the system like this, it’s important to work with the Action messages to make sure you don’t pile up inventory.

I have come across blogs and went to conference session where it is recommended to set the negative days to long time fences and then work with the action messages. This will indeed provide good planning results, but will just be a bit slower and potentially more difficult to analyze, due to the need to analyze and apply the action messages.

Let’s look at the following example:

Item _DemoProduct has a 6 days purchase lead time

On day 0 (1st Jan) the inventory for item _DemoProduct is 0

On day 0 (1st Jan) you get a sales order for item _DemoProduct, quantity 10

On day 10 (10st Jan) you get a sales order for item _DemoProduct, quantity 10

On day 12 (12th Jan) there is a purchase order for item _DemoProduct, quantity 10

Negative days are set to 20, which is a lot more than the item’s lead time.

MRP will create the following result:

You may notice in the above that the sales order Requirement date is 9th Jan, instead of 10th Jan. That is again because the screenshot was taken in 2015, when 10th Jan is a Saturday, so the Requirement date of the order should be the previous working date, hence Friday, 9th Jan.

MRP creates a planned purchase order to fulfill the demand requested by the first sales order, but then it also recommends you cancel this planned order, because you can advance the existing purchase order and increase the quantity on it.

The results are not wrong by any means. But MRP will potentially run longer, because it will need to create all the delays and suggestions. Also, the planner may need more time to understand the MRP results. And, most importantly, in this case it’s essential that the planner understands and uses the action messages!

Setting the negative days to a lower value, close to the item’s lead time (hence also adhering more to the definition that they represent the number of days you allow negative inventory) and using the Dynamic negative days setting, will give the following result:

MRP will create a planned order pegged to the first sales order. Then the second sales order gets pegged against the existing purchase order, as expected based on the negative days setting. This planning result is also correct and in this case MRP will potentially run a faster. In this case it’s not essential that you understand and know how to work with the action messages.

So all in all, it’s not easy to come up with the right setting for negative days. There are some ‘do’s and ‘don’t’s, but finding the right values for your business is a trial and error game, and you have to think in terms of both functionality and MRP runtime.

This blog post describes an new way of interacting synchronously from code with the
Constraint-Based Product Configurator which has been introduced in Microsoft
Dynamics AX 2012 R3 CU8.

Scenario

The scenario that drove the introduction of this feature can be described as follows:

An external 3rd party sales configurator outside of Microsoft Dynamics AX 2012 is used to
assign values to a subset of attributes(a partially configured order), from
which the remaining mandatory attributes can have their values deduced using
the Microsoft Dynamics AX 2012 Configurator, thereby completing the order.

Once the all the values have been deduced, assuming all values are valid, they can be passed on
to the back end configuration module, which will create the BOM and potentially
the Route (if the model has a Route).

Implementation

Included in Microsoft Dynamics AX 2012 R3 CU 8 is a new derived version of the PCRuntimeConfigurator class, named PCRuntimeSynchronousConfigurator.

This class is designed, as the name indicates, for synchronous interaction with the .NET
Configurator component.

The configure method on the class is the method
which exposes the new functionality added to the .NET Configurator to Xpp. The
method takes three arguments; the model as xml, the attribute assignments as
xml and a the number of milliseconds which can be used before a timeout occur.
The return of the method is a IsConfigurationComplete enum value, from which
result of the configuration can be determined;

• Complete
• The configuration is complete
• Incomplete
• One or more mandatory attributes does not have a value
• Timeout
• The configurator was not able to complete the configuration within the given timeout limit
• Contradiction
• One or more constraints have been violated

Note:

The PCRuntimeSynchronuosConfigurator class exposes
the functionality required by the .NET configurator component to support the
above scenario but it is not yet integrated with any order (sales, production
etc) or product variant creation nor is it integrated with the BOM and Route
generation.

KB Article with number 3028719 should be Applied on top of R3 CU 8 as it addresses a stability issue in the solution.

 Example

 In this example values are passed from the simulated 3rd party configurator into Dynamics AX 2012 through a web service, as illustrated below:

To expose the PCRuntimeSynchronousConfigurator class through
a web service, we start by introducing a new class
PCTechDemoService which implements a method with the SysEntryPointAttribute code attribute, which is
needed for a method to be exposed as a web service.

In this simple implementation the example method looks like this:

[SysEntryPointAttribute(true)]

public boolean configure(PCName _modelName, str _xmlValues)

{

    boolean ret;

    str values;

    PCRuntimeSynchronousConfigurator configurator  = PCRuntimeSynchronousConfigurator::construct();

    PCProductConfigurationModel productConfigurationModel  =  PCProductConfigurationModel::findByName(_modelName);

    values = '<Assignments>' + _xmlValues  + '</Assignments>';

   
if(configurator.configure(productConfigurationModel.getXML(), values,120000) == Microsoft.Dynamics.Ax.Frameworks.Controls.ProductConfiguration.IsConfigurationComplete::Complete)

    {

        ret = true;

    }

    return ret;

}

Now we can create a Service in the AOT which uses the PCTechDemoService
class and its configure method as an operation. To use this service, it needs
to be put in a service group, which can then be deployed.

To test the service, navigate to System administration > Services and Application Integration Framework > Inbound ports. Here we find our new PCTechDemoServiceGroup, copy the WSDL URI value.

Open Visual Studio Command prompt and type:

Wcftestclient <Your WSDL URI>

This will open the WCF test client where we can now see our web service.

For the demo data set I have used, I will use the following argument values

_modelName : 20001

_xmlValues : <Assignment xPath="powerCableLength" value="10"/><Assignment xPath="videoSystem/television/size" value="42" />

Note: the xPath mechanism used to identify the attributes in model.

If you are familiar with the 20001(Home theater system) model, you will know that it has just two
mandatory attributes which are not assigned by defaults; the powerCableLength
on the root component and the size on the television component.

Attached you will find an Xpp project with code used for the example.

Enjoy

With the introduction of the new warehouse management capabilities in Microsoft Dynamics AX 2012 R3, it is possible to Report as finished from a handheld device. The only disadvantage of using this capability is that you can’t overproduce. The user will be blocked by the error: Quantity reported as finished exceed the quantity started, and have no option to override the setting.

With Hotfix KB 3034999, we leverage the quantity validation parameters originally built for the Manufacturing execution module. So the parameters now support the scenario where the user needs to report overproduction from a handheld device.

Overproduction is the term used in Microsoft Dynamics AX 2012 for reporting a production or batch order as finished when the quantity produced is greater than originally planned. This is a common scenario in the process industry and can be caused by many factors, for example, potency and yield.

When you produce more items than planned for a production or batch order, you will get the following blocking error: Quantity reported as finished exceeds the quantity started.

In order to allow for overproduction, you have to select the parameter Accept error in the Report as finished parameters. This will bypass the quantity validation check and then allow for overproduction.

For companies that use the Manufacturing execution module in Dynamics AX2012, there is a more advanced support for overproduction. In this module, you can set up a quantity validation based on different criteria. For example, you can accept overproduction in percent based on the planned quantity, the started quantity, or the quantity reported on the previous operation.

To show an example of how overproduction is reported, I have changed the demo script for CU8 "SCM Demo Script - Batch orders and WMS integration" (Attached). I have changed the section:

 DEMO: REPORT THE PRODUCTS AS FINISHED AND MOVE THEM TO LOCATION FOR FINISHED PRODUCTS

The following diagram shows the complete logic. The logic was originally only applicable for reporting overproduction from the job registration form in the Manufacturing execution module, but is now applicable for the scenario where the user needs to report overproduction from a handheld device. 

The hotfix in Microsoft Knowledge Base (KB) article 3093049, that is planned to be released mid-October, enables order picking from license plate locations for raw material picking. This hotfix also introduces a policy that controls the status of the material line after raw material picking has been completed.

Order picking from license plate locations

For raw material picking, there are two picking principles: order picking and staging. The term order picking is used when the ordered quantity is being picked, whereas the term staging is used when the full quantity on the picked license plate is being moved. Up to now, only staging from license plate locations has been possible. However, this hotfix now makes it possible to configure which of the two principles should be used for raw material picking. This policy is controlled at the item level, where a new Material picking in license plate locations field has been added on the Warehouse management FastTab.

By default, when a new product is created, the value of this field is set to Order picking. When you apply this hotfix on a customer installation, it’s important to change the value of this field to Staging for the items that are picked. Typically, these are the items that have been stored at the license plate locations. 

Controlling the status on the material line after material put

A new Status after material put field has been added to the Inventory and warehouse management parameters.

The value of this field controls the status of the inventory transactions for the production material line after warehouse work for raw material picking has been completed. Up to now, the status has always been Picked.

The Picked status deducts physical on-hand inventory. However, feedback indicated that users expect to see the physical on-hand material at the input location after the warehouse work has been completed but not yet consumed by the production order. Therefore, it’s now possible to switch the Issue status between Picked and Reserved physical.

When you select Reserved physical, the material appears as physical on-hand (but reserved) inventory at the input location after warehouse work has been completed. Be aware that with this setting material is reserved at the location and dimensions above the location in the reservation hierarchy. If the material reserved for example has batch number below the location in the reservation hierarchy, then the batch number is not included in the reservation. In this case it will not be possible to backflush the material. If back-flushing is a requirement, then the batch number must above the location in the reservation hierarchy, because that will include the batch number in the reservation.

The hotfix in Microsoft Knowledge Base (KB) article 3093049, which is planned for release in mid-October, enables scenarios where registration of a component’s serial number can be postponed until the time of consumption in production. Here is one of the customer scenarios we have been looking at:

Most of the components we use for our machine assemblies are delivered from vendors. These components are typically received on pallets packed in a quantity of for example 200 pieces. Each component has a unique engraved serial number, but we don’t need to register the serial numbers at product receipt. We just register the receipt of the pallet, so that we don’t have to spend time breaking up the pallet and registering each serial number individually. The serial number also isn’t registered when the warehouse worker picks the component for the production order. However, when the assembly worker mounts the component in the assembly, she reads the engraved serial number on the component and updates it in the system. By registering the serial number at the time of consumption, we can print a list that shows exactly which component serial numbers were used in a given assembly. Then, if we receive a complaint, and the issue that is reported can be tracked to a specific component, we can communicate the serial number back to the vendor. In a worst-case scenario, if the issue is systematic (for example, a batch of bad-quality rubber sealing has been used in the component), the vendor will track all the components that are affected and communicate the serial numbers affected back to us. Because we can track the serial number that is used in a given assembly, we can now identify all the assemblies that are affected and take the necessary measures.

This scenario is now supported in Dynamics AX and can be demonstrated by using a simple bill of materials (BOM) that is named Assembly and a serial-controlled item that is named Component.

In the warehouse, the component is tracked only by location and license plate. The serial number of the individual components on the license plate aren’t known at this point.

A production order is released for the assembly, and warehouse work is created to pick up the component.

The warehouse work is processed without specifying the serial number of the picked component.

The production order is started, and the production picking list journal is created.

The picking list journal can’t be posted unless a serial number is specified. Any attempt to do so will cause the following error message:

This message indicates that a serial number must be registered before the picking list journal can be posted. The new Register serial numbers menu item that has been added to the Inventory Action Pane button can be used to resolve this error.

The journal can now be posted, and the serial number is updated on the issue transaction for the production material line.

The bill of serial for the assembly can now be printed from the tracing tool.

A new field Register serials before consumption has been added to the Tracking dimension groups form to enable this scenario. This field works together with the Capture serial field for the values Picking and Packing. For example, when Picking is selected in the Capture serial field, the serial number also needs to be provided at the time of picking.

The core team has been engaged in a couple of requests about how to set up raw materials that acts as consumables in production. In these requests the following characteristics has been used for consumables:

• They are never stored in the raw material warehouse, but filled up directly at the production locations, therefore warehouse work for raw material picking is never needed for these materials.

• They often represent a low value and are not accounted for at time of consumption, but cycle counted at a periodic basis.

• They are often set up to allow for physical negative inventory to avoid blocking issues when they are back-flushed in production.

As we encountered some issues using items that are WMS-enabled for consumables with the above mentioned properties, we recommend to use items that are NOT WMS-enabled for this purpose. With this item is possible to:

• Setup a default issue location either at the item-warehouse level or by the resource (resource consumption). This location will be defaulted to the production bill of material line, and act as the production input location i.e. the material will be consumed from this location.

• Use it in a warehouse that is WMS-enabled, and there is no problem setting up this product to allow for negative inventory.

• Ensure that warehouse work will never be generated for this item.

   

The problem with using a WMS-enabled item in combination with allowing for negative inventory is, that warehouse work will be generated in case there is no on-hand on the production input location. This happen instead of deducting the input location with a negative quantity, which would be the expected behavior. An attempt to back-flush the material in a later stage will result in a blocking error “Item XXX does not have enough inventory”.

The recommendation of using a WMS-enabled item for consumables, will not support a scenario where the warehouse processes is applicable for the item in other processes, for example, in the product receipt process. Supporting these different scenarios for the same item is currently identified as a gap, but we are currently investigating possible solutions to enable this capability.

This blog post describes a new hofix that is released in the Microsoft Knowledge base (KB) in article 3124753.

When reporting a batch order or a production order as finished with End job, the order state will be updated to Reported as finished. This state indicates that no more finished goods are going to be reported and no more time and material is going to be consumed by the order. As a consequence, any inventory transactions with remaining quantities for both materials and the finished goods will be closed.

So far the End job option has only been supported when reporting as finished from the AX Client and not from the hand held device. With this hotfix the End job option is now also available with reporting as finished from the hand held device.

This hot fix also leverages the Physical reduction parameter in the production control parameters. Setting this parameter can be helpful in for example material back flushing scenarios where it will prevent the reporting as finished process to error out in case of material stock out.

Configuration of the menu item

A new parameter End job has been introduced in the Mobile device menu item for the work creation process Report as finished and put away.

When setting this parameter the End job field will be visible when reporting as finish on the hand held device.

Reporting as finished with End job

Reporting as finished with the End job option can be demonstrated by using a simple Formula FinGood with a formula line named Ingredient. A batch order is created for FinGood

The formula line is set up with flushing principle Finish

Also note that the formula line is set up with a variable scrap percentage of 5.

The batch order is now Released and warehouse work for raw material picking is created. 

The work for raw material picking is processed and the ingredient is now available and physically reserved on the production input location.

Note that the quantity is 1050 as it includes the estimated 5% scrap.  

The batch order is Started and after some time a partial quantity of 500 is reported as finished from the hand held device

Note that the field End job is set to No as we are reporting a partial quantity.

After reporting as finished is completed a quantity of 500 pieces of the finished product is on-hand and the material Component has been back flushed proportional to the reported as finished quantity which can be seen on the material inventory transactions.

Now the last quantity of the FinGood is reported as finished. To indicate it is that last quantity the End job field is set to Yes.

In this example the batch order is over producing with a quantity of 3 (500+ 503), because less material than the estimated 5% was scrapped during the production thereby enabling more finished goods to be produced. As back flushing is consuming proportional to the reported as finished quantity, the system will in this case try to consume 503 + 5% = 528. As there is only 525 left on the input location this will cause the process to error out due to material shortage

 As only 525 was consumed (because we had a lower scrap than estimated) we want the system to consume the remaining quantity of 525 on the input location and not try to consume more.

To support this scenario, the Physical reduction property, that is set up in the Production control parameters, can be used. Using it, will ensure that the system will only try to consume the physical available quantity during back flushing. The parameter is only leveraged, in this scenario, when the End job is set to Yes on the hand held device.

With the Physical reduction parameter set, let us again try to report a quantity of 503 as finished with End job

Looking at the batch order, the status has now changed from Started to Reported as finished

In total a quantity of 1003 has been reported as finished

With the consumption of the original estimated quantity of 1050 of the ingredient

This blog post describes new functionality released with the Microsoft Knowledge base (KB) in article 3089402.
 
When using one or multiple of the product dimensions in production, you can have situations where you would like to produce an item, based on a different variant of the same item.
There are many scenarios where this can be useful, e.g.
•  A Green variant of a specific item that is produced using a white variant of the same item.
•  An item variant produced using a different configuration of the same item.
•  Large item variant cut into multiple smaller variants of the same item.
 
Until now it has been mandatory to use different items for the parent and child product respectively. If this was not the case, the user would get a warning from the BOM check that circular reference is not allowed. If the warning was ignored MRP might fail. This warning was caused by the fact that the level check and the BOM level calculation was done per item.
 
With KB3089402 you can use the same item as both parent and child in a BOM - as long as minimum one product dimension differs.

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

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

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

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

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

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

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

Define size and colors for the product

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

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

The Circularity check will pass, since the color dimension differ

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

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

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

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

This blog post describes the functionality of a new hofix that is released in the Microsoft Knowledge base (KB) in article 3120530.

 After installing this hotfix it is now possible to configure the location directive for raw material picking, so work can be rounded up to the nearest handling unit in which the material is picked for production.

Consider following scenario:

A food manufacturer uses a special flour for making a powdered soup mix. The flour is stored on pallets in 50 lb bags in the bulk warehouse. For making 4,475 lb of the powdered soup mix 510.15 lb of flour is needed. This corresponds to 10 x 50 lb bags + 10.15 lb. As the material is always picked in bags (the handling unit), the warehouse worker will in this case pick 11 bags. After the 11 bags are moved to the production floor, the bags are broken and 510.15 lb is weighed off and applied to the production process. The remaining quantity from the last bag will remain on the input location and either be consumed by the next batch order or moved back to the warehouse.

Before the release of this hotfix it was possible to set up in which handling unit the material should be picked, but it was not possible to round-up the quantity to the nearest handling unit. In the above example, work for raw material picking would have been created for 10 x 50 lb bags and 10 lb i.e. for the same work the material would be picked in two different units. This scenario is still supported, and is relevant for some customers who wants to weigh of the material at the warehouse location (in this case the remaining 10.15 lb).

Let us take a closer look at how the mechanism to round up work to the nearest handling unit has been enabled.

Setting up the location directive for raw material picking

In the location directive for raw material picking a new field Round up to handling unit has been introduced:

In the location directive for raw material picking a new field: Round up to handling unit has been introduced. This field works together with the field Restrict by unit. In this example the location directive is set up to pick in the unit of Bag, and selecting Round up to handling unit indicates that the work generated out of the directive should be rounded up to a multiple of one handling unit.

Setting up formula and ingredient

In this example a formula version for making the soup mix is set up with a batch size of 4475 lb, consuming 510.15 lb of Flour

A unit conversion has been set up for the Flour ingredient between the unit’s bag and lb.

The following Unit sequence group is used for the item. The inventory unit must be the first unit in the sequence group, in this case lb.

Releasing work for raw material picking

A batch order is now created and released for the batch size of 4475 and warehouse work for raw material picking is generated.

As it can be seen from the work details work is in this case rounded up to 11 bags. The batch order is still only reserving the required quantity 510.15 which can be seen from the work transactions form that can be opened from the work details form:

If the rounding option had not been used on the location directive, then the resulting work would have looked like this:

In this case the warehouse worker would have to pick 10 bags and weigh of the remaining 10.15 lb on a warehouse location. This process is enabled in the location directive by adding a line that is not restricted by unit. This line will make work for the remaining quantity.

This post is part of the series of posts explaining performance improvements introduced in
Constraint-Based Product Configuration in Microsoft Dynamics AX 2012 R3 CU8.

The Solver strategy concept was first introduced in Cumulative update 7 for Dynamics AX 2012 R2 and has been extended in Cumulative
update 8 for Dynamics AX 2012 R3. It now includes the following strategies:

• Default
• Minimal domains first
• Top-down

What is a solver strategy?

Imagine you were given the task of solving a 100 piece jigsaw puzzle. How would you start?

A common solving strategy is to start with the edges and move towards the middle, most of us
will either have done this ourselves or if not it should be pretty simple to
convince yourself that this strategy is sound.

Now, what if the puzzle you have to solve does not have straight line edges (often referred to
as impossible puzzles)? Suddenly our edge-first strategy will be dramatically less efficient as the edges are much more difficult to identify.

For the Solver, a configuration model is a bit like a jigsaw puzzle which needs to be solved.
With the Solver strategy concept, we have enabled you to set the strategy which
the solver will use when it solves the model. Configuration models can however
be very different in nature and the strategy for solving one model efficiently
may prove to be inefficient to solve a different model.

What is the impact?

The impact of response times has been shown on real customer models, to go from minutes to
milliseconds. For this reason it is really worth your time to spend a few
seconds to change this one setting, to see if a change in Solver strategy could
have this impact on your configuration model.

You can change the Solver strategy setting in the model properties form.

Which strategy to choose

Currently there is no build in logic which automatically detects which solver strategy will be most efficient, so for now, you will have to try them out.

Default

What can be said about the different solver strategies is that the default Solver strategy has been optimized so solve models which rely on table constraints. On all the customer models we have seen which use table constraints to a large extend this
solver strategy has proved to be the most efficient.

Minimal domain first and Top-down

These two strategies are closely related. The Top-down strategy, which has been introduced with CU 8 has shown to outperform Minimal domain first in all of our studies, but for
backwards compatibility we have decided to keep the minimal domain first strategy
in the product. Both of these strategies have shown to be more efficient for
solving models which contain several arithmetic expressions and where table constraints are not used.

In short, negative days time fence represents the number of days you are willing to wait with negative inventory, before ordering new replenishment. But if you ever wondered yourself: ’How do the negative days really work?’, then keep reading.

In this post:

I will be explaining how planned orders get created, taking into account the negative days time fence.

I will touch upon the correlation between the negative days time fence and the item’s lead time.

I will also explain the Dynamic negative days time fence calculation and how that factors in the item’s lead time into the calculation of the time fence.

I will also try to better explain the MRP runtime improvement suggestions related to negative days that you can find here: http://blogs.msdn.com/b/axmfg/archive/2015/01/02/checklist-for-improving-mrp-performance-part-2-how-to-setup-planning-parameters.aspx

I will explain the above in the context of three different situations. The difference between these situations is at what point within the item’s lead time you get demand.

Please excuse the poor quality of the screenshots. Click on them to get a better view

Situation 1

Item _DemoProduct has a 6 days purchase lead time

On day 0 (1st Jan) the inventory level for item _DemoProduct is 0

On day 0 (1st Jan) you get a sales order for item _DemoProduct, quantity 10

On day 7 (8th Jan) there is an existing purchase order for item _DemoProduct, quantity 10

Case A

Negative days are set to 2, a value not really close to the 6 days lead time of _DemoProduct. We don’t use Dynamic negative days.

In this case, MRP will look for receipts for item _DemoProduct within the negative days time fence, and since it won’t find any, it will create a new planned purchase order. This planned order will immediately be delayed with 6 days (the lead time) so it will arrive on 7th Jan. The existing purchase order will get a Cancel action message, since it is now made redundant by the creation of the new planned purchase order.

So far so good, but if you take into account MRP performance and plan nervousness it may be not so good. Why? From a performance standpoint, MRP had to create a new planned order, calculate delays and actions, which are all time consuming tasks. From a plan nervousness perspective, you just got 2 more transactions to deal with…

What you gained? The sales order will not be delayed with 7 days, but with 6 days.

Case B

If this gain is not that important for you, then what you could do is set the negative days to be greater than or equal to the item’s lead time. There is no way you can get the supply inside the lead time anyway, so then why not search for receipts as long as it makes sense? On the bright side, it will make MRP run faster, but beware of orders being further delayed!

Case C

Another thing you could do is use Dynamic negative days (Master planning – Setup – Master planning parameters – General – Coverage – Use dynamic negative days). This setting will automatically correlate the item’s lead time to the negative days time fence. What will happen in this case is that MRP will look for receipts inside the dynamic negative days time fence, which is calculated based on the following formula:

DynamicNegativeDaysTimeFence = PurchaseLeadTime* + NegativeDaysTimeFence + (TodaysDate – RequirementDate)

*If the default order type of _DemoProduct would have been Production or Transfer, than the lead time would be the Inventory lead time.

With Dynamic negative days, the time fence MRP looks for receipts is now 6 + 2 + 0 = 8. So MRP will find the existing purchase order and will peg the sales order against it. No new planned orders will be created, hence MRP runtime will be shorter. The Net requirements for _DemoProduct look as follows:

Schematically, this is what happened:

Case D

So what happens if you set negative days to 0 and use Dynamic negative days only? Would that help you deliver on time and not create impossible planned orders? This actually works just like not using Dynamic negative days, as in the example below.

If you set Negative days to 0 and use only the Dynamic negative days time fence, which will now be 6 + 0 + 0 = 6, you will end up in the same situation as in case A: from a performance standpoint, MRP had to create a new planned order, calculate delays and actions, which are all time consuming tasks. From a plan nervousness perspective, you just got 2 more transactions to deal with… The demand still can’t be fulfilled on time, it will be late anyway.

Case E

If you both set the negative days to be greater than or equal to the item’s lead time and you use the Dynamic negative days time fence as well, than this will be 6 + 6 + 0 = 12. This may lead to a very long time fence MRP will search for results in. At the end of this post, there is a section related to what happens if you set Negative days to a long time fence, so please refer to that in order to understand Case E.

Situation 2

Item _DemoProduct has a 6 days purchase lead time

On day 0 (1st Jan) the inventory level for item _DemoProduct is 0

On day 4 (5st Jan), inside the item’s lead time, you get a sales order for item _DemoProduct, quantity 10

On day 7 (8th Jan) there is a purchase order for item _DemoProduct, quantity 10

Case A

Negative days are set to 2 and don’t use Dynamic negative days.

In this case, MRP will look for receipts for item _DemoProduct within the negative days time fence, and since it won’t find any, it will create a new planned purchase order, order date current date. This planned order will immediately be delayed with 6 days (the lead time) so it will arrive on 7th Jan. The existing purchase order will get a Cancel action message, since it is now made redundant by the creation of the new planned purchase order, with delivery date 7th Jan.

Case B

This is similar to situation 1: if you set the negative days to greater than or equal to the item’s lead time, then you will not get a new planned order. The sales order will be pegged to the existing purchase order.

Case C

This is also similar to situation 1, in the sense that dynamic negative days will work just as well. The dynamic negative days time fence will now be 6 + 2 – 4 = 4. So MRP will find the existing purchase order and will peg the sales order against it. No new planned orders will be created, hence MRP runtime will be better.

Case D

If you set Negative days to 0 and use only the Dynamic negative days time fence, which will now be 6 + 0 – 4 = 2, you will again end up in the same situation as in Case A. For a graphical view, refer to Situation 2, Case A.

Case E

If you both set the negative days to be greater than or equal to the item’s lead time and you use the Dynamic negative days time fence as well, than this will be 6 + 6 – 4 = 8. This may lead to a very long time fence MRP will search for results in. At the end of this post, there is a section related to what happens if you set Negative days to a long time fence, so please refer to that in order to understand Case E.

Situation 3

Item _DemoProduct has a 6 days purchase lead time

On day 0 (1st Jan) the inventory for item _DemoProduct is 0

On day 7 (8st Jan), outside the item’s lead time, you get a sales order for item _DemoProduct, quantity 10

On day 10 (11th Jan) there is a purchase order for item _DemoProduct, quantity 10

Case A

Negative days are set to 2 and you don’t use Dynamic negative days.

MRP will look 2 days ahead from the sales order’s requirement date. Since it doesn’t find anything, it will create a planned purchase order on 2nd Jan, that will be shipped just in time to fulfill the sales order demand. The existing purchase order will get cancelling action message, since it’s not needed.

You may notice that in the above AX screenshot, the Purchase order Requirement date is 12th Jan. That is because the screenshot was taken in 2015, when 11th Jan is a Sunday, so MRP moves the Requirement date to 12th Jan, the next working day. But the purchase order has a Delivery date of 11th Jan.

Case B

This is a case to take a minute and think about. If you set the negative days to be greater than or equal to the item’s lead time, then you will not get a new planned order. The sales order will be pegged against the existing purchase order, so in this case the sales order will be delayed, although if you were to create a planned order you could ship the sales order on time!

Case C

This is also similar to situation 1, in the sense that dynamic negative days will work just as well and even better than if you compare to case B.

The dynamic negative days will be 6 + 2 – 7 = 1, but in this case the system will still consider the negative days lead time (2), because MRP takes into account the maximum value between negative days lead time and dynamic negative days lead time. So the result in case C is the same as in case A.

Case D

If you set Negative days to 0 and use only the Dynamic negative days time fence, which will now be 6 + 0 – 7 = -1, but in this case the system will still consider the negative days lead time (2), hence case A is the same as case D. So all the pitfalls you have in A you will have in D. For a graphical view, refer to Situation 2, Case A.

I will not refer to case E anymore, since it’s exactly the same as in situation 1 and 2 – it has more or less the same benefits and pitfalls.

Based on the above it seems a good idea to set the negative days to be greater than or equal to the lead time of the items in the coverage group and/or to always use dynamic negative days and set the negative days to number of days you are willing to wait with negative inventory, before ordering new replenishment (in other words, the number of days you are willing to further delay demand).

The above hopefully also illustrates why items in the same coverage group should have similar lead times.

If you set the negative days to 0 and you don’t use Dynamic negative days, then MRP will always create a new planned order to fulfill demand. So if you setup the system like this, it’s important to work with the Action messages to make sure you don’t pile up inventory.

I have come across blogs and went to conference session where it is recommended to set the negative days to long time fences and then work with the action messages. This will indeed provide good planning results, but will just be a bit slower and potentially more difficult to analyze, due to the need to analyze and apply the action messages.

Let’s look at the following example:

Item _DemoProduct has a 6 days purchase lead time

On day 0 (1st Jan) the inventory for item _DemoProduct is 0

On day 0 (1st Jan) you get a sales order for item _DemoProduct, quantity 10

On day 10 (10st Jan) you get a sales order for item _DemoProduct, quantity 10

On day 12 (12th Jan) there is a purchase order for item _DemoProduct, quantity 10

Negative days are set to 20, which is a lot more than the item’s lead time.

MRP will create the following result:

You may notice in the above that the sales order Requirement date is 9th Jan, instead of 10th Jan. That is again because the screenshot was taken in 2015, when 10th Jan is a Saturday, so the Requirement date of the order should be the previous working date, hence Friday, 9th Jan.

MRP creates a planned purchase order to fulfill the demand requested by the first sales order, but then it also recommends you cancel this planned order, because you can advance the existing purchase order and increase the quantity on it.

The results are not wrong by any means. But MRP will potentially run longer, because it will need to create all the delays and suggestions. Also, the planner may need more time to understand the MRP results. And, most importantly, in this case it’s essential that the planner understands and uses the action messages!

Setting the negative days to a lower value, close to the item’s lead time (hence also adhering more to the definition that they represent the number of days you allow negative inventory) and using the Dynamic negative days setting, will give the following result:

MRP will create a planned order pegged to the first sales order. Then the second sales order gets pegged against the existing purchase order, as expected based on the negative days setting. This planning result is also correct and in this case MRP will potentially run a faster. In this case it’s not essential that you understand and know how to work with the action messages.

So all in all, it’s not easy to come up with the right setting for negative days. There are some ‘do’s and ‘don’t’s, but finding the right values for your business is a trial and error game, and you have to think in terms of both functionality and MRP runtime.

This blog post describes an new way of interacting synchronously from code with the
Constraint-Based Product Configurator which has been introduced in Microsoft
Dynamics AX 2012 R3 CU8.

Scenario

The scenario that drove the introduction of this feature can be described as follows:

An external 3rd party sales configurator outside of Microsoft Dynamics AX 2012 is used to
assign values to a subset of attributes(a partially configured order), from
which the remaining mandatory attributes can have their values deduced using
the Microsoft Dynamics AX 2012 Configurator, thereby completing the order.

Once the all the values have been deduced, assuming all values are valid, they can be passed on
to the back end configuration module, which will create the BOM and potentially
the Route (if the model has a Route).

Implementation

Included in Microsoft Dynamics AX 2012 R3 CU 8 is a new derived version of the PCRuntimeConfigurator class, named PCRuntimeSynchronousConfigurator.

This class is designed, as the name indicates, for synchronous interaction with the .NET
Configurator component.

The configure method on the class is the method
which exposes the new functionality added to the .NET Configurator to Xpp. The
method takes three arguments; the model as xml, the attribute assignments as
xml and a the number of milliseconds which can be used before a timeout occur.
The return of the method is a IsConfigurationComplete enum value, from which
result of the configuration can be determined;

• Complete
• The configuration is complete
• Incomplete
• One or more mandatory attributes does not have a value
• Timeout
• The configurator was not able to complete the configuration within the given timeout limit
• Contradiction
• One or more constraints have been violated

Note:

The PCRuntimeSynchronuosConfigurator class exposes
the functionality required by the .NET configurator component to support the
above scenario but it is not yet integrated with any order (sales, production
etc) or product variant creation nor is it integrated with the BOM and Route
generation.

KB Article with number 3028719 should be Applied on top of R3 CU 8 as it addresses a stability issue in the solution.

 Example

 In this example values are passed from the simulated 3rd party configurator into Dynamics AX 2012 through a web service, as illustrated below:

To expose the PCRuntimeSynchronousConfigurator class through
a web service, we start by introducing a new class
PCTechDemoService which implements a method with the SysEntryPointAttribute code attribute, which is
needed for a method to be exposed as a web service.

In this simple implementation the example method looks like this:

[SysEntryPointAttribute(true)]

public boolean configure(PCName _modelName, str _xmlValues)

{

    boolean ret;

    str values;

    PCRuntimeSynchronousConfigurator configurator  = PCRuntimeSynchronousConfigurator::construct();

    PCProductConfigurationModel productConfigurationModel  =  PCProductConfigurationModel::findByName(_modelName);

    values = ‘<Assignments>’ + _xmlValues  + ‘</Assignments>';

   
if(configurator.configure(productConfigurationModel.getXML(), values,120000) == Microsoft.Dynamics.Ax.Frameworks.Controls.ProductConfiguration.IsConfigurationComplete::Complete)

    {

        ret = true;

    }

    return ret;

}

Now we can create a Service in the AOT which uses the PCTechDemoService
class and its configure method as an operation. To use this service, it needs
to be put in a service group, which can then be deployed.

To test the service, navigate to System administration > Services and Application Integration Framework > Inbound ports. Here we find our new PCTechDemoServiceGroup, copy the WSDL URI value.

Open Visual Studio Command prompt and type:

Wcftestclient <Your WSDL URI>

This will open the WCF test client where we can now see our web service.

For the demo data set I have used, I will use the following argument values

_modelName : 20001

_xmlValues : <Assignment xPath=”powerCableLength” value=”10″/><Assignment xPath=”videoSystem/television/size” value=”42″ />

Note: the xPath mechanism used to identify the attributes in model.

If you are familiar with the 20001(Home theater system) model, you will know that it has just two
mandatory attributes which are not assigned by defaults; the powerCableLength
on the root component and the size on the television component.

Attached you will find an Xpp project with code used for the example.

Enjoy

Demo.zip

With the introduction of the new warehouse management capabilities in Microsoft Dynamics AX 2012 R3, it is possible to Report as finished a production or batch order from a handheld device. The only disadvantage of using this capability is that you can’t overproduce. The user will be blocked by the error: Quantity reported as finished exceed the quantity started, and have no option to override the setting.

With Hotfix KB 3034999, we leverage the quantity validation parameters, originally built for the Manufacturing execution module, so the user can now report overproduction from a handheld device.

Overproduction is the term used in Microsoft Dynamics AX 2012 for reporting a production or batch order as finished when the quantity produced is greater than originally planned. This is a common scenario in the process industry and can be caused by many factors, for example, potency and yield.

When you produce more items than planned for a production or batch order, you will get the following blocking error: Quantity reported as finished exceeds the quantity started.

In order to allow for overproduction, you have to select the parameter Accept error in the Report as finished parameters. This will bypass the quantity validation check and then allow for overproduction.

For companies that use the Manufacturing execution module in Dynamics AX2012, there is a more advanced support for overproduction. In this module, you can set up a quantity validation based on different criteria. For example, you can accept overproduction in percent based on the planned quantity, the started quantity, or the quantity reported on the previous operation.

To show an example of how overproduction is reported, I have changed the demo script for CU8 “SCM Demo Script – Batch orders and WMS integration” (Attached). I have changed the section:

DEMO: REPORT THE PRODUCTS AS FINISHED AND MOVE THEM TO LOCATION FOR FINISHED PRODUCTS

The following diagram shows the complete logic. The logic was originally only applicable for reporting overproduction from the job registration form in the Manufacturing execution module, but is now applicable for the scenario where the user needs to report overproduction from a handheld device. 

SCM Demo Script – Batch orders and WMS integration – Overproduction.pdf

The hotfix in Microsoft Knowledge Base (KB) article 3093049, that is planned to be released mid-October, enables order picking from license plate locations for raw material picking. This hotfix also introduces a policy that controls the status of the material line after raw material picking has been completed.

Order picking from license plate locations

For raw material picking, there are two picking principles: order picking and staging. The term order picking is used when the ordered quantity is being picked, whereas the term staging is used when the full quantity on the picked license plate is being moved. Up to now, only staging from license plate locations has been possible. However, this hotfix now makes it possible to configure which of the two principles should be used for raw material picking. This policy is controlled at the item level, where a new Material picking in license plate locations field has been added on the Warehouse management FastTab.

By default, when a new product is created, the value of this field is set to Order picking. When you apply this hotfix on a customer installation, it’s important to change the value of this field to Staging for the items that are picked. Typically, these are the items that have been stored at the license plate locations. 

Controlling the status on the material line after material put

A new Status after material put field has been added to the Inventory and warehouse management parameters.

The value of this field controls the status of the inventory transactions for the production material line after warehouse work for raw material picking has been completed. Up to now, the status has always been Picked.

The Picked status deducts physical on-hand inventory. However, feedback indicated that users expect to see the physical on-hand material at the input location after the warehouse work has been completed but not yet consumed by the production order. Therefore, it’s now possible to switch the Issue status between Picked and Reserved physical.

When you select Reserved physical, the material appears as physical on-hand (but reserved) inventory at the input location after warehouse work has been completed. Be aware that with this setting material is reserved at the location and dimensions above the location in the reservation hierarchy. If the material reserved for example has batch number below the location in the reservation hierarchy, then the batch number is not included in the reservation. In this case it will not be possible to backflush the material. If back-flushing is a requirement, then the batch number must above the location in the reservation hierarchy, because that will include the batch number in the reservation.