Software version used:
Content is valid for all older versions.
Of these two D365 Master Planning dates, the requirement date is the date we will see most prominently, and it’s the date that is used for the MRP calculation. Both the demand and the supply transactions have the requirement date. The only date we will ever see in the Net Requirement screen for an item is the requirement date.
Then why do we need a “Requested date”? Who is doing the requesting? The functionality of the requested date is not immediately clear. This is the reason for this article. There is no simple answer to what the requested date represents. It depends on the scenario. Often, the requested date is the original demand date that reminds the user of what the requirement date used to be before something happened. Often, when the requirement date is not equal to the requested date, an action message will be generated. But not always. Let’s go into detailed testing.
Requested date: there are two!
First of all, surprise, there are TWO requested dates. You will find the field “Requested date” in two places:- In the planned order grid.
- In the pegging fast tab of the planned order.
Four ways requirement date can be different from requested date
1.Using a Receive safety margin
When we are using a receive safety margin in the Coverage group or the Master plan, a planned Purchase order will get a delivery date earlier than the official requirement when needed. We knew that already. Now, what is the Requested date doing?
In our test, we have three calendar days of receive margin. We see there are indeed three days between the Requirement date and Delivery date. April 30, 2020 is the requirement date, coming from the Sales order line, and April 27th is the new date, using the receive margin.
The requested date in the pegging fast tab remains blank. Our sales order knows nothing of our receive margin.
In the planned order grid, the Requested date is now populated. Now the Requested date is our earlier date thanks to the receive margin, and it’s the date when we will receive the PO. It is the receive date on the PO line. The requested date is the recalculated requirement date.
In Net requirements, we will continue to see the requirement date 4/30/2020. This is not very surprising for the planned PO or the actual Purchase order. The delivery date on the line is advanced with the receive margin—three days.
Conclusion: When using a receive margin, the requested date on the planned order grid will show the planned receive date of the Purchase or Production order while the Requirement date that we see in the Net Requirements screen is unchanged.
2.Using an Issue safety margin
The next test is using an issue safety margin in the Coverage group or the Master plan. If I have an issue safety margin of 3 calendar days, the system deducts three days from the requirement date of the demand. Our example is a sales order with a confirmed ship date of April 30. Without issue margin, the planned order will have the requested date of April 30, and the requirement date will also be April 30. Nothing is going on. With the issue margin of three days, the requested date remains April 30, but the requirement date will become April 27. MRP will calculate as if the demand is for April 27.
The requested date is now populated in the pegging section. It is the “original requirement date” that is now altered by the issue margin.
In the planned order grid, I see a blank requested date.
There is no action message, which we have to agree with. Planners in the company decided we wanted the planned order 3 days before he was really needed. It would be strange to have an action message of “postpone” in this situation.
Conclusion: When using an issue margin, the requested date in the pegging tab shows the date of the original demand, while the issue margin has altered the requirement date.
3.Working days in the calendar
If my requested ship date for a sales order is on a Saturday, the requirement date will typically not be on that Saturday because a requirement date has to follow the working day calendar. The requirement date will become April 17. If the Sales order line requested ship date is on Sunday, April 19, the requirement date will also become April 17. In the pegging fast tab of the planned order, the requested date now indicates the “original demand date” of the sales order line.
The requested date on the planned order grid remains blank.
NOTE: For planned purchase orders, the above is only true when a calendar exists on the Coverage group or on the Warehouse.
4.Parameters for forward scheduling
In this scenario, the demand date is in the future but the lead time of the item is greater than the time we have left so MRP will either generate a planned order that starts in the past or it will schedule forward from today, this depends on a parameter. Let’s take a close look. The parameters below exist on the Master plan. We will focus on the first two only.
Parameter 1 “Ensure that the planned orders are not created prior to the master planning run date” = No: We do allow planned orders to start in the past.
Parameter 1 = Yes: We do NOT allow planned orders to start in the past.
Parameter 2 “Add the calculated delay to the requirement date” = No: when there is a delay, we don’t want the requirement date to be recalculated to reflect that delay. The requirement date should remain the original requirement date.
Parameter 2 = Yes: when there is a delay, we want the requirement date to be adjusted to reflect that delay. It comes down to scheduling the planned order forward from today and make the requirement date be equal to the delivery date of the planned order.
With parameters 1 and 2 both to “No,” and having a demand date in the past, nothing is happening with the requested date. The system has no reason to “reverse scheduling direction,” and we get a planned order with a start date in the past.
In the example above, we have a 10-day lead time. Today is April 30th. The planned order starts in the past, meets the demand for the Sales order with April 1st requested delivery date.
No requested date on the pegging fast tab.
No requested date in the planned order grid.
The action message wants to move this planned order to April 1st. This is the expected action message with our parameter setting, but it refutes our theory that an action message would be based on the difference between requirement date and requested date. This is not the case.
We are now switching the second parameter to “Yes.”
The planned order is scheduled forward, and the requested date on the planned order grid indicates the previous delivery date, it is the requirement date of the planned order when parameter 2 was still “no.”
The Requested date in the pegging fast tab remains blank.
D365 Master Planning Dates CONCLUSION
Why are there two “Requested date” fields? Looking at the above, it will become clear.
The green rows are about date modification on the supply side.
The yellow rows are about date modification on the demand side.
Green rows: The requested date in the order grid is only populated when the scenario applies to a modification of the planned order’s delivery date. In this case, the requested date in the planned order grid is populated because there can only be one requested date. A planned order has only one delivery date.
Yellow rows: The requested date in the Pegging fast tab of the planned order is only populated when the scenario is related to the demand date. A planned order can be pegged to multiple demands, which means there can be multiple demand dates or requirement dates. So, I would have to calculate different requested dates. The system has no choice but to populate the requested date on the pegging tab.
We hope the mystery of the Requested date is no longer a mystery. One final comment: a company that does not use any Safety margins and keeps the parameters 1 and 2 to “No” will only see Requested dates populated on planned orders when Sales order lines have requested or confirmed delivery dates on non-working days.
Have any questions about using the D365 Master Planning dates? Don’t hesitate to contact us at any time! 
