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.
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.
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.
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.
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.
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.
Dependent reservations with positive sign (by-products or co-products) are not considered during the rescheduling check on the standard system. The system behavior can be changed with the implementation of the modification note 203151.
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.
It is also possible to reach the rescheduling customizing for the plant through transaction OPPQ and for the MRP group through transaction OPPR.
At last, even if there is no MRP group assigned to the material master, the settings defined at MRP group level will be consider if the MRP Group key is equal to the material type (see note 34013 for more details). For example, if the material type is ZPRD and there is an MRP Group ZPRD, the settings from this MRP group will be considered by MRP if the field MRP Group is empty on the material master.
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.
SAP Note 25388: MD01, MD02, MD03: Rescheduling proposals: Documentation
SAP Note 34013: MD04, MD05: Material type as MRP group
SAP Note 52448 - MD01: Several order proposals on one day
SAP Note 72267: Resched. for reorder point planning or stor.loc.MRP
SAP Note 71877: MD01: Rescheduling check and lot-sizing procedure
SAP Note 203151: Rescheduling for dependent reservations
SAP Note 550302: FAQ: Rescheduling check
SAP Note 1698291: Rescheduling exception messages 10, 15 are not displayed in transaction MD04 on the cross-plant view.
SAP Note 1794796: Planning calendar is not considered during Rescheduling of MRP.
SAP Note 1745312: MRP creates redundant proposals though there are fixed future receipts which can cover the requirements.
SAP Note 1950299: Exception message 10 is not displayed in transaction code MD04