MRP: Why shouldn’t I use planning mode 3 on a productive system?
Why shouldn’t I use planning mode 3 on a productive system?
Very often, MRP is scheduled to be executed with planning mode 3 on productive systems. This is not necessary and planning mode 3 has several disadvantages, when compared to another planning modes. Generally, planning mode 1 is enough on a dailty MRP execution and planning mode 2 can be used, for example, on a weekly MRP execution.
On this document, we will see why planning mode 3 should be avoided on a productive system.
1 – Performance:
Running MRP with planning mode 3 is the most common cause of performance issues. System takes a lot of time to delete and to recreate the planning elements and that increases the MRP total runtime.
Take the following exercise on a test system:
Schedule two different MRP runs, one with planning mode 1 and another with planning mode 3 (use NEUPL to ensure that the same number of materials will be planned). Now, using the report RMMDMONI (see note 1865330), compare the runtime between the both MRP executions. Analyze how much time system takes to delete and to recreate the planning elements. The blog post Analyze and improve MRP performance provides more details about performance improvement on MRP.
2 – System is smart enough to adapt master data changes with planning mode 1 or 2:
The most common excuse to use planning mode 3 is that the BOMs are frequently changed and the planned orders must be updated with those changes.
In case of a BOM change, a flag is marked on the planning file and, even if you are using planning mode 1, system automatically re-explode the BOM on the next MRP run. Therefore, even on this scenario, planning mode 3 is not required.
3 – Number ranges will be exhausted faster
If you are using planning mode 3, after each MRP run, all the unfirmed planned orders will be deleted and new planned orders will be created. That will make the number range interval to be quickly consumed and also may lead to an error on the MRP execution when the number range is nearly exhausted.
See note 531599 for more details.
4 – Overflow of table EKET
When deleting a schedule line, the quantity is set to zero on table EKET, in order to keep the track of the changes. Using planning mode 3 leads to a large-scale deletion and a new creation of delivery schedules and may lead to an overflow of table EKET.
5 - Negative effect on the database statistics
On of the key factors of MRP performance is the database access to table RESB. This table is generally huge and the daily update of the database statistics is recommended, for a better performance. Running MRP with planning mode 2 or 3 causes a lot of changes on table RESB, since the planned order dependent requirements may be deleted and recreated or at least updated. With these changes, the database statistics will quickly become outdated, leading to performance issues, not only on MRP, but on all the application areas where table RESB is accessed.
For an overview of my SCN documents about MRP, take a look on the following WIKI:
The following notes provide more information about the planning modes on MRP:
135788 - Planning mode in material requirements planning
78867 - MD01: Documentation on the planning mode