I am reading the MRP Technical Reference guide. Both Kinetic an dE10 have the same line:
Important For Epicor Cloud ERP - Multi Tenant and Epicor Cloud ERP - Dedicated Tenant environments, processing MRP is limited to three processors and two suggestions.
I believe this is a typo and it should say 3 processors and 2 schedulers. We are Cloud DT. Can anyone confirm what values we should use? The guide says never to use just one, and most servers can handle two. Then this last statement makes me think we can do 3 and 2.
What do you think?
I believe that in the cloud you can run 3 processors for MRP. I thought (but may be mistaken) that you could also run 3 schedulers.
That said, there is a new feature coming in 2023.2 which has a major performance improvement for MRP. When I say “Major” it depends on YOUR actual data is defined (how many purchased parts vs Mfg parts, vs Safety/min, etc). We have seen performance improvements from some customers going from 4 hours MRP to 20 minutes… one customer went from almost 3 hours to run PO Suggestions down to 6 minutes. SO… the number of processors could be less important to getting your MRP/PO Suggestions faster.
Old MRP Calculation and NEW Calculations are the same. the results are the same… what is different is the way that we select what needs to be calculated. We were able to perform a pre-filter that eliminated any parts from the MRP Calculations if they didn’t need to be analyzed… basically a pre-analyzer. as a result, MRP has far less to do.
This new feature must be turned on… it is a “sticky” switch (if you turn it on, it stays on… turn it off, it stays off).
The switch describes what it does… it only includes parts that have activity (Demand orders or supply orders) or have Min/Safety quantity set… In other words, if the part has no safety, no min, no orders, no demands, then MRP doesn’t need to look at it. if this switch is turned on, then MRP will still look at the part, and that is not as efficient.
Yes, the generated results from MRP should be IDENTICAL whether the switch is on or off…
You might ask “Why a switch”?.. well, in theory, we can conceive of situations where the extra analysis that we do up front takes longer than letting MRP do the work. For example, if EVERY ONE of your parts has min/safety, then every part needs analysis… our extra code could end up taking longer. Also, the extra query is more complicated and takes more memory. We had one customer early on test this, and the system had a memory problem (we fixed this we think). @josecgomez at Stephen Gould was one of our early testers, and has said that they are happy with the test results. Every one of the controlled release customers are pleased. Several of our channel partners did tests with their customers and said that the tests were amazing.
From what I’m hearing from @timshuwy, this changes nothing in the MRP calculation. It appears they are doing a quick scan ahead time to prevent MRP from looking at the part: net change or not. It’s a statistical gamble to see if they can avoid the MRP process on parts without min/max/etc. Let’s say running the preprocessor takes 3 “processing cycles” but MRP takes 10 “processing cycles” to determine this part with no min/max/safety has no demand, then you save some time. If you have enough of these savings, your overall MRP processing will be quicker.
That’s my current understanding. But I’m an old fart, so take it with a grain of Metamucil.
But isn’t that what Net Change does? If there’s been no new demand since the last MRP run, filter out that part…
Or does the new switched regen just look at parts on open orders or with min/max/safety, while the old regen looked at every single part, regardless of order/min/max/safety? Just guessing here…
I would say it this way, “No changes in the demand since the last MRP.” This means you still have to calculate the new demand (which still takes cycles) to see if it changed from the old demand. The preprocess eliminates a subset of those parts to check.
My understanding is that the new switch makes both regen and net change faster since MRP is looking at fewer parts.
Answers to the above questions: 1. This IS different from net change, but the enhancement MAY also improve Net Change… example: if you have a part that has ONE demand (a sales order) and there is no safety/min… and you SHIP that order, the NET CHANGE flag is set to true… but in this case, there is no futher demand, and no further supply, then there is nothing to check in net change… but since the net change flag is no, then MRP has to go through the cycle to check it. Now with this new feature, we simply skip it. 2. Will this miss any parts?@Mark_Wonsil is right… the way that we did this, we look for parts that have MIN/SAFETY, and parts that have data in the PartDtl table. PartDTL is what populates TIme Phase. If there is nothing in PartDTL, then there are no demands or supplies. Min/Safety is the only demand that doesn’t show in PartDTL. We have done our best to make sure that it doesn’t miss anything. We believe that we have caught everything. We have done testing, and analyzing. We have put this in front of a bunch of customers, and nobody has found instances yet where MRP did anything different. BUT MRP is a complicated engine, and we wanted to make sure, so we put this as a switch to turn it on. IF someone finds that there is a difference, then WE WANT TO KNOW (so we can fix it). Eventually, we will probably remove the switch, and turn it on permanently.
