Tim,
The process of checking the partdtl was an important part of the process.
I worked with a customer a few years ago that had over 600,000 parts and their PO Suggestions would take forever.
I wrote a query that would select all parts with no partdtl records and I would use the results to uncheck Generate suggestions on the PartPlant table.
I wrote a second one that would select all parts with partdtl records that were not set to Generate Suggestions and use the results to turn on Generate suggestions on the PartPlant.
Is Generate suggestions using the same logic as you described for MRP?
Just curious… how is it that this announcement of the BIGGEST MRP Improvement EVER does not have 999999 likes?
THIS is a HUGE DEAL! Ridiculously Absurdly Enormous optimization (I am running out of adjectives).
We just updated our DEV environment to 2023.2.4 and I’m going to test the performance improvements in Process MRP and Generate PO suggestions.
We have Process MRP and Generate PO Suggestions in a process set along with other nightly processes we run.
I’m using Process Set Maintenance in the Kinetic UX. How do I see the parameters on the Process MRP in the task set in the Kinetic? In Classic UX I double-click on the task and it opens Process MRP so I can view the settings on the instance in the task set.
I believe I heard that we are missing that option in the browser… so to see the parameters, (at least for now) you may need to go back to the classic view…
THAT SAID, you may not need to worry about it for the new functionality. The new MRP option is a special “sticky” option that turns on when you turn it on, and stays defaulted on until you turn it off… so you may be able to simply run it manually one time with the option turned on, and it will keep going.
Please report back your results! (this might seem like a bold statement, but I have confidence that you will see positive results). We want both before and after times for both FULL MRP and FULL PO Regeneration.
We spun up our UPGRADE 2023.2.4 testing environment last week. Running MRP the old way timed out after 9 hours at Level 3 (with 1 process and scheduler). The new way completely finished in 45 minutes! Wooot! At least a 91.6666666666666% improvement here. We’ve got 150k parts, for what that’s worth.
Our LIVE environment has much more horsepower, and currently takes about 3 hours for a regen (with 3 processes and schedulers). I can’t wait to see how it does in 2023.2! Great job Team Epicor.
This is a HUGE deal and a loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong, (did I mention LONG?) awaited improvement. Maybe you could ask if this post could be pinned to the top of the epiuser.help list for a while as maybe some people haven’t seen it yet. I just found it today myself… excited to test this and report our findings. Thank you for this announcement!!
This change in MRP is wonderful!! Do you know if there is anything in the works to add something to stop processing of new orders until they are ready to be processed? That was always an issue for Perlick because the orders are so large and take a long time to enter especially if it was end of day.
@timshuwy
If I am running MRP for three parts - isn’t the first step in the process to look at filters on the process before doing anything with the low level codes?
@Beth, the “out-of-the-box” method for having MRP ignore an order release is the “Firm Order” checkbox at the OrderRel level. What you might do is put in a BPM to set that to “false” automagically (it is set true by default), and then another to set it true when Ready to Process is selected. I’ve done that a couple of times before for various reasons.
Nope… this MRPRecalcNeeded is for the Net Change, and has nothing to do with the new optimized MRP feature. The Recalc needed is for those environments where you are running net change avery day for many weeks. There are instances where MRP will not examine parts becuase there is “no change” except for the fact that “today” is now many days since the last change… running the recalce needed will look to see if there are parts that have not had a change but are NOW within the planning window, and need to be analyzed.
I dont believe that it will change the global scheduling calculation, BUT we would love to know if it does. we simply have not done duration testing on that yet.
