Preventing Changes of Released PR(Next MRP Run It Should Not Change the PR Internal Number)
In this blog post we can see how to control the Released PR’s and how to protect the Old PR’s number which is released already, and the same PR’s number should not change while re-run the MRP using the planning mode as 3( Delete and Recreate the planning data) for that same materials.
While run standard MRP system generated dependent PR’s, Some PR’s we might released and not converted into Purchase order, Meanwhile we did some changes in any of the master data, After changing we are trying to run the MRP using the planning mode as 3(delete and recreate the planning data) in plant level is standard, In this case already Released PR’s internal number is overwritten (Means it was Changed the Old PR’s internal number into New PR’s internal number of dependent required quantity).
We can control the old PR’s internal number should not to be change by using two different ways, please see the below two scenarios.
If the Purchase Requisition is subject to a release procedure and if it can no longer be changed for materials planning according to its release status. As firmed purchase requisition won’t touch by MRP.
In your release strategy will have a Release Indicator in that Release Indicator active “Firmed for Req. Planning” then system will firm the requisition automatically once it is released. “Fixed” purchase requisitions are not changed by requirements planning.
Steps to follow:
- Release Indicator Configuration.
- In MD04 screen we can see the Pur.Req internal number generated for standard MRP run of the material.
3. Run the MRP using the planning mode as 3(Delete and re-create planning data), After MRP run we can see the Old PR internal number Changed into New PR internal number with the same Quantity.
- After MRP run, I have Released PR using ME54N.
- After Released the PR, Then I have tried to execute the MRP using Planning mode as 3.
- In MD04 screen we can see the PR internal number remains same which I used planning mode as 3 during MRP, and Remaining PR’s internal number has been overwritten into new PR internal number.
For single PR, I have activated the Fixed ID in ME52N and PR Release is not mandatory in this Scenario, I have executed to run MRP using planning mode as 3.
- In MD04 Screen we can see the Dependent Requirement Pur.Req.
2. I have taken one PR and i activated the Fixed ID indicator in ME52N.
- After activated the Fixed ID indicator, Just Refresh the MD04 screen, we can see the star symbol (Means manually changes has been done), Which means if you want to run the MRP again, that Old PR internal number should not to be change.
- After MRP run using planning mode as 3, Old PR internal number not changed and remaining PR’s internal number has overwritten into new number.
If we want to control the Old PR’s not change into New PR’s we have to follow the any one of the scenario depends on the business from client.
That is a nice article. However I have some comments:
Why are you using planning mode 3 as standard. Note 78867 - MD01: Documentation on the planning mode clearly states that planning mode 1 should be used as standard. Planning mode 3 after configuration changes:
Even in planning mode 3, MRP run doesn't change PR numbers! It deletes old PR and creates new ones.
Irrespective of planning mode MRP doesn't change fixed / firmed PR. Therefore it does make sense to setup PR release strategy to fix / firm PR once they are release.
Thank you for your valuable comments, please find below the problem i have faced one of my client.
Once released the PR’s say Ex: Out of 100 PR’ s they have released 40 PR’s on July 01 and Planning team gave the released PR’s list to SCM team, but those SCM team users they are not converted into PO immediately, they will take 10 days time to convert the PO on July 10 in real time scenario as well as in SAP.
We suggested to run the MRP using the planning mode as 1(For all time) in plant level, Suggested to run MRP using MD02 of any BOM& Routing changes using planning mode as 2, Suggested to run MRP using planning mode as 3 if they have done some changes in planning or material master using MD01N for those changed materials only.
But problem is planning team are changing some master data regularly, However different Super users changing different data as per the irregular business, Meanwhile they are not able to track the materials list which they have done changes in master data, In this case they are using planning mode as 3 only, So system automatically deleted the Old PR’s and generated the New PR’s.
After 10 days SCM is going to converted the Old PR’s into PO at that time system will show the error message like PR does not exist, Again they will get the new PR’s from Planning team then will do the routine process as same, Because of this issue only i have used the FIRMING.
Firming PR after release is the right solutions in my mind. It prevents PRs from being changed by next MRP. It does make sense - once PR is released it means the PR is accepted and the system should not change it anymore.
What puzzles me though is the planning mode 2 or 3 usage. I do understand your recommendations to the client. However note 78867 - MD01: Documentation on the planning mode clearly states that when MRP is run with planning mode 1, the system should take care automatically of applying internally the right planning mode to individual materials depending on the changes to master data:
The note also list the change types that trigger planning mode 3 automatically:
You may also look at note 34816 - Planning file entries with reset indicators.
Notice that these are very old notes. Thus they refer to well matured functionalities that are in the SAP ERP for ages. They just have to work. If they don't, an issue should be raised to SAP support.
Thank you for your useful update.
we have one more option to "firm" the Planned receipts by using MRP Type as P1, P2,P3,P4 or M1,M2,M3,M4 by providing the planning time fence (Days).
So during next MRP run, system will do the automatic Firm to the Purchase req. or Planned orders.
Thank you for your useful update.