What is rescheduling and how does it work

Purpose
The objective of this WIKI is to provide an overview of the MRP rescheduling check and examples of the most
common issues and questions in this area.

Overview
Whenever the MRP finds a requirement, it checks if this requirement can be covered for an existing fixed receipt
(within the rescheduling horizon), before creating a new replenishment element (planned order). This procedure is
called “rescheduling check”.

If a fixed replenishment element is found, an exception message is created, suggesting the user to reschedule this
fixed element in order to cover the shortage.

System first searches for fixed elements before the requirement date. If a fixed element is found before the
requirement date, then this receipt is not needed until later. In this case, the exception message “15 – Postpone
process” is displayed for the element.

If the fixed element is after the requirement date, within the rescheduling horizon and this type of fixed element is
included on the rescheduling check, according to the customizing, exception message “10 - Bring process forward”
is displayed for the element.

Example 1:
There is a reservation on 30.03.2012 and a production order on 20.03.2012.
In this case, system displays exception message 15 for the production order, suggesting the user to reschedule
this order to 30.03.2012, when this is really needed.

Example 2:
There is a reservation on 30.03.2012 and a production order on 30.04.2012.

Instead of creating a new planned order to cover the reservation, MRP creates exception message 10, suggesting
the existent production order to be rescheduled to 30.03.2012, in order to cover the reservation.

That happens because the production order is within the rescheduling horizon and, according to the customizing;
this is included on the rescheduling check.

Example 3:
Now consider the following scenario, where there is still the same reservation on 30.03.2012 and the same
production order on 30.04.2012, but also a planned independent requirement on 30.04.2012.
Instead of creating a new planned order on 30.03.2012, systems suggests you to reschedule the production order
to 30.03.2012 and creates a new planned order on 30.04.2012. Why?

It happens because the rescheduling check is carried out before the actual materials planning, that means, before
creating the new planned order, system had already run the rescheduling check an suggested the production order
to be moved to cover the reservation.

Therefore, system considers that the production order should be moved, and that would cause a shortage on
30.04.2012, therefore, the planned order was created to cover this shortage.

Rescheduling customizing:
You can find the rescheduling customizing on transaction OMDW or access I directly the following SPRO path:
For the plant, you will find the following options:
Rescheduling horizon: It is the number of day for which the system checks whether the fixed replenishment
elements should be rescheduled. The rescheduling horizon is calculated in working days, according to the plant
factory calendar and it starts on the end of the replenishment lead time. 

Firmed elements: You can define which specific elements will be included on the rescheduling check. If the flag is
unchecked, MRP will not consider the element during the rescheduling check.

Comparison values: If the difference between the requirement date and the firmed receipt element is less than the
tolerance value, system will not display an exception message.

The rescheduling horizon and the firmed elements can also be defined at MRP Group level.

Example 4:
The scenario is similar to the scenario on example 1, there is a reservation on 30.03.2012 but now the production
order is on 02.07.2012. 

This time MRP created a new planned order on 30.03.2012, instead of rescheduling the production order to cover
the reservation. It happens because the production order was outside the rescheduling horizon, which was defined
as 30 working days on the customizing.
You may also notice differences between the rescheduling messages displayed on the stock/requirements list
(transaction MD04) and the MRP list (transaction MD05). It happens because MD05 displays the MRP results, and
as it was already explained, the rescheduling check happens before the actual MRP calculation, while on
transaction MD04 the rescheduling check happens when all the planning elements are already created. Therefore,
the exception messages from MD05 can’t be compared with the exception messages from MD04.