Yikesā¦it shouldnāt be erroring out period. Canāt just chase everyone off the system just to run MRP eitherā¦
@JMPCONJ when Epicor was on site for our CVEW, their Solutions Engineer encouraged us to run 3 for Number of MRP Processes. She was pretty passionate about making that change. I donāt remember exactly whyā¦this workshop was back in October '25.
There is a science to it, not just random 3. They should have you run some commands to determine how many CPUs you have, threads, cores. Sigh.
Its even documented in Epicor Help somewhere.
3 is the max for SaaS.
How does a Custom Truck Manufacturer run MRP in time? We had to use 8, because the BOM was huge and created about 20-50 Child Jobs. SaaS canāt handle a decent size company thatās not manufacturing tissue paper? 
About 2.5 million parts.
Stay on-prem?
There is rumor of some kind of āhybridā Containers Epicor is working on.
Back in the day (E9?), when this setting first appeared (and EVERYONE was oon-prem), we were taught it referred to the number of processor cores devoted to the process, and depending on A LOT of factors, the law of diminishing returns comes into play at some point. In my environment at the time, 4 was my sweet spot. I remember people telling me that in THEIR environment they could see improvement up to 8 or 10, so it probably DOES depend on a lot of other things, INCLUDING the data that MRP is crunching through.
I have also been told that 3 is the limit for SaaS, regardless of what higher value you may enter there, youāll only ever get 3. Probably the only way to test that is to make it 5, turn on logging, and see how many log files you get (youāll get one per core).
EDIT: Running with a single processor and single scheduler means thereās probably no chance of a thread finding stale data somewhere.
If thatās what they recommended, follow their leadā¦I just pulled our setupā¦YMMV.
Ernie, you are 100% correct, as we are a SaaS company and therefore 3 makes sense for us. Also, gone are the days of on-prem, here soon. Honestly, I loved having everything on-prem, dating back to V6!
Used to be 3 but was reduced in the last year.
From Kinetic Material Requirements Planning Guide 2026.100 page 239:
I just saw that and was going to test it tonight.
I just kicked off MRP in a PILOT environment with ā5ā, and it gave me an error saying I could only use ā3ā. I changed it to three and it is now running (with MRP logging enabled). Iāll see what happens and report back.
Thatās fair play. Documenters and developers are different teams.
yeah my brain also instantly started humming Civil War and now itās stuck there, the way itās always done before
help
ā¦failure to communicateā¦
I got three log filesā¦ the documentation is incorrect (right now) but that may be the way itās gonna be at some point.
Same issue for us.
Worked (but took a lot longer) when we used 1 scheduler.
Apparently this is fixed in hotfix 100.9
Ditto but different custom truck OEM, and we used 7.
I accidentally looked into this a few months ago. For us, 7 was excessive; probably 5 would have sufficedā¦ except for the fact that some nights 5 of them would fail, leaving only 2 to carry the load. So if we had started with 5, that would leave [ā¦calculatingā¦] zero.
Some MRP processes fail but MRP completesā¦ more or less - Kinetic ERP - Epicor User Help Forum
When I was on MT SaaS in 2017, weād crash MRP if was more than one process.
Cloud Migration considerations and advice - Epicor ERP 10 - Epicor User Help Forum