Author: Roxana Cristina Diaconu

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

A few times already I’ve been asked to investigate customer cases that went something like this:

Create a production order for some item from the standard test data.

Schedule the order (job scheduling or operation scheduling, doesn’t matter).

Expected result:
The order gets scheduled.

Actual result:
Production order ### could not be scheduled. Not enough capacity could be found.

 

In some cases it turned out it was a product bug. In other cases the message was perfectly valid.

The question is: how would you, as a user, know what’s happening? How would you figure out why capacity was not found?

Ideally the scheduling engine should not only return a dull message saying that it didn’t find enough capacity. It should come up with a reason or a trace or something you could analyze. And we sincerely hope that in future releases we will get to enhance the error reporting of the scheduling engine! But until then, here is a list of things you can do when you get the error:

1. Check if there are any applicable resources that satisfy the operation requirements at the production order site.

Path:
Production order list page – chose the production order that can’t be scheduled – Production details – Route – chose the operation that’s causing the failure – Applicable resources – check if you have any applicable resource on the production order site

 

Img 1 – There are applicable resources, but none on the production site

 

2.  If it turns out that there are no available resources at the production order site, make sure you have resource requirements enabled for the type of scheduling you are doing: operations vs job.

Path: Production order list page – chose the production order that can’t be scheduled – Production details – Route – chose the operation that’s causing the failure – Applicable resources – toggle ‘Use requirements for’ between Job and Operation scheduling.

 

 

3.  Make sure you have calendars associated to the resources/resource groups identified as applicable and that the calendars have working times and that efficiency percentages are not 0.

Path: Production order list page – chose the production order that can’t be scheduled – Production details – Route – chose the operation that’s causing the failure – Applicable resources – for each applicable resource right click and or click
View resource – Resource form – Resource groups – make sure there is a Calendar associated with the resource.

If there is a calendar, make sure it has working times: right click on the Calendar and View details or Organization administration – Calendars – Calendars – chose the calendar – Working times and check the form is not empty or that the days don’t have Control set to Closed. Pay attention to the base calendars as well, and make sure they have working times and correct efficiencies and the days are not closed.

If the error occurs during Operations scheduling, make sure that there is a calendar on all the applicable resource groups.

In operations scheduling, the resource group’s calendar is used for determining the start and end times and dates for each operation. The resource group’s calendar puts a limit on how much time that can be operations scheduled for one specific
operation for one specific day in one specific resource group. For example, if the working time for a resource group on one specific date is between 8-16, one operation can’t put more load on the resource group than what can be fit into 8 h, no matter how much capacity that the resource group has available on that day. The available capacity can however limit the load further

 

4.  Due to performance reasons, the scheduling engine will only search for a resource for a certain time/number of scheduling conflicts encountered. Make sure that in Organization Administration – Setup – Scheduling – Scheduling parameters you
haven’t turned on any of the scheduling parameters. If you did, try to change the values and reschedule the order.

 

5.  If you are doing finite scheduling, it may very well be that you really have no free capacity. To make sure this is not the case, you can either:

 

6.  Revert to doing infinite scheduling, by un-checking Finite capacity check box during scheduling.

 

7.  Check the available capacity on the resources/resource groups applicable for the operations that couldn’t be scheduled.

Path: Resources/Resource groups form, opened either by View details or from Organization administration – View – Capacity load or Capacity load, graphically and make sure there is available capacity.

 

8. And if none of the above worked, then you need to revert to more ‘serious’ stuff – doing scheduling engine diagnostics, by enabling logging. Here’s how you do it.

(Note: you’ll need to have extended permissions to some files and the AX database in order to perform this, so if you are a production planner, shop floor supervisor, etc you will need to contact your internal AX support person to help you)

First of all, you need to know that the scheduling engine can produce 3 logs:

1. Log that gives you the full picture of all the input data that the scheduling engine will work with when trying to figure out the schedule for the production order: list of jobs/operations that need to be scheduled, applicable resources, scheduling constrains, etc

Log file name: Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\Log\SchedulingDataModel_[funky_numbers_here].xml

It is pretty easy to read. Look at this log in order to determine if the correct input information is fed to the scheduling engine.

       2.  Log with all the available capacity slots that the engine receives for scheduling – we will not get into details about who is providing these slots and so on, what is important to understand is that basically these are the available resource working times, based on the calendars associated with the resources.

Log file name: Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\Log\SchedulingSlots_[funky_numbers_here].xml

It is also fairly easy to read. Look at this log to see if the capacity slots that are sent to the engine make sense.

     3. Log with all the capacity reservations that the scheduling engine wants to make, that should be saved in the AX database.

Log file name: Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\Log\SchedulingResults_[funky_numbers_here].xml

This is basically the scheduling result.

           

By default, the scheduling engine does no logging at all, so none of the above files will be created. So how do you enable these logs? You go to Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\bin, open SchedulingEngine.config and set:

UseXmlOutput = true, in order to generate SchedulingDataModel_[funky_numbers].xml

UseSlotsXmlOutput = true, in order to generate SchedulingSlots_[funky_numbers].xml

LogResults = true, in order to generate LogResults_[funky_numbers].xml

 

 

Don’t bother with LoggerEnabled and LogVerboseEnabled – they are there just for historical reasons and are, in fact, never used. LogToTextFile will be explained later.

Don’t bother to stop/restart the AOS – no need for that in order to enable logging.

Now, as soon as you schedule your production order again, you’ll get the log files.

These logs that you’ve just got are very generic, as you can see, so it would be a huge step forward for us if a ‘Not enough capacity found’ customer case had these attached!

I will not go now into detail about the fields in the logs, what they mean and so on – this will be explained in a future post, more technical. What you can do until then is play with different parameters, play with applicable resources, play with different route parameters and you will get a decent understanding, I believe.

So what does LogToTextFile do? Up until now we’ve produced log files that are decently readable by anyone. You can also enable the scheduling engine to log every tiny thing it does, using standard Windows event tracing. Here’s how you enable this!

 

1. Go to Performance monitor (go to Run – type Perfmon.msc)

       2. Create a new User defined Data collector set. Give it a name to remember and follow the wizard.

       3.Chose Create manually

 
        4. Chose Create data logs – Event trance data

       5. Add a trace provider

 

       6. Chose Microsoft-DynamicsAX-Tracing

 

 

       7. Specify what you want to trace from AX, by clicking Edit. You want to choose MRP from the list of all keywords.

       8. Specify where you want to keep the log

9. And you’re done, just click Finish

      10.  Well, you’re not 100% done – you need to start tracing, by clicking start in the tool bar

 

If you now schedule a production order, you can view the trace in the standard Windows Event viewer – Action – Open saved log – open the log saved at the location you set in the wizard, in my case C:\PerfLogs\Admin\DAXTrace\[MachineNameHere]_20130116-000001

 

 And good luck keeping track of these!

What you could do to make your life a little bit easier is to convert all the messages into a .csv file, which you can open in Notepad and search for some keywords or something like that. You do this by running the following command:

tracerpt [location_of_the_trace_file] -o [destination_file] -of csv

 

 

 

Whatever you do, remember to switch off tracing after you’ve collected your data! You don’t want to keep on piling data you don’t need, not to mention that tracing always has a negative impact on scheduling performance.