We have an ongoing issue where MRP is failing we are digging into… We need to run production planner and MRP to get accurate suggestions, but there are concerns we can’t do this in the middle of the day. Can anyone help us to understand if that is a valid concern(do we need to tell everyone to stop using Epicor while MRP is run)?
Depending on how large your DB is and how many orders, jobs etc you have this could put some strain in the application but there’s nothing technical or functional stopping you from doing it.
It will work fine, you wont be able to go into PO Sugestions while its running and your unfirmed jobs will be blasted but outside of that (other than time) there’s nothing that should stop you from running MRP any time you need to.
@hkeric.wci , @bderuvo may have more insight but It should be ok.
3 Likes
Depends if you are running net change or full regen. The MRP guide explains the differences in great detail.
net change will not delete your existing suggestions and will run faster.
regen will first delete all job and po suggestions and start over.
MRP performance always varies by environment.
You can change your logging options and dig into the issue there. I’ve seen bad BOMs or Circular references in BOMs from imports cause issues. Epicor is pretty good at preventing you from doing bad things in Eng Workbench. DMT has allowed me to break things in the past. Look at the logs, it will usually show you where it gets stuck.
Full Regen you should do after hours. But again it depends how long it takes. If its a 30min thing and you can run it during lunch, okay.
Basically what i’ve seen is when you try to run it and people use Epicor, some screen’s wont load data properly, especially Job Entry.
Net Change people have done during the day, while Full Regen usually an overnight thing.
2 Likes
We do a lot of batching of operations on jobs and if we try doing it while MRP is running it usually causes issues.
1 Like
Just adding in my two cents here. MRP is very dependent on how it’s run as to how big of a load it is on users. I know where I am working now any change to MRP requires buy in from the buyers as they will often delete suggestions and change suggestions and they don’t want a full (Regenerative) MRP to remove those or a net to bring back suggestions they’ve already deleted.
I also feel like the length of time MRP takes is reliant on the length of time that it is looking out into the future. If you only have it looking out a week it’s won’t take long but if you have it going out 10 years (what it does when you leave end date blank) it’s going to take longer but may be a necessity due to longer lead times in the current market.
I assume you’re digging into MRP is with the logs? What error is it (the logs) giving when it fails?
2 Likes
we also found that as long as a batched job is not closed, MRP keeps evaluating the Job to Job link of batched jobs , so be sure to close finished jobs, this saves time.
1 Like
If you are troubleshooting an ongoing problem with one or a group of parts, more recent Epicor versions let you run MRP on a part by part basis. That should be pretty safe to run during the day without noticeable effects.
2 Likes
I usually only regen1 or 2 parts during the day as a last resort ( someone wants to know NOW what the new/changed demand will be. Both Buyers are informed to get out of PO Suggestions as that will blow up…
Major concern of doing full regen during the day is this ‘perfect storm’
Regen is running,
Buyer checks part
All the U jobs are deleted, Buyer sees no demand
Buyer goes on to other tasks
regen done
Boss sees no parts ordered , asks buyer about it
Buyer says---- what demand
Boss shows Buyer time Phase
Buyer says, that wasn’t there when i checked this morning…
We are small enough that if I absolutely have to, I will run net change while the buyers are on lunch with the warning to not react to anything till I give then the all clear.
Just my 2 cents…
Dean
1 Like
The only error I see in the log is as follows. Any chance anyone knows what it means? Also, when MRP fails it’s on different parts, but they are all very similar(a family of parts with very similiar BOMs). These parts were likely creating by copying, so I suspect whatever the error is got propagated as we copied these parts to create new similiar flavors… Please note we have logging set as basic, I’m wondering if we should set it to MRP or MRP and Scheduling?
21:00:27 End of Delete Unfirm Jobs
21:00:27 Starting sub-processes
21:00:27 Deleting old Suggestions.
21:00:27 Deleting unfirm jobs…
21:00:27 Deleting transfer order suggestions …
21:00:32 Scheduling Jobs…
21:00:32 Scheduling Jobs…
21:00:32 Building Non-Part List
21:00:32 Building Non-Part List
21:00:37 Building PartList Level: 0
21:00:38 Building PartList Level: 0
21:02:03 Building PartList Level: 1
21:03:39 Building PartList Level: 1
21:04:25 Thread was being aborted.
21:04:25 at System.Threading.Thread.SleepInternal(Int32 millisecondsTimeout)
at System.Threading.Thread.Sleep(Int32 millisecondsTimeout)
at Erp.Internal.MR.MrpExp.mrp(Boolean p_net, String p_plist, Nullable1 p_cutoff, String p_reqtype, Nullable1 MRP_DEBUG_ON, String ipPartList, String ipPartClassList, String ipProdGrupList, List1 ttMrpProcRows, List1 ttMrpQueueRows) in C:_Releases\ERP\ERP10.2.400.0\Source\Server\Internal\MR\MrpExp\MrpExp.cs:line 3343
at Erp.Internal.MR.MrpExp.main_block(List1 ttMrpProcRows, List1 ttMrpQueueRows) in C:_Releases\ERP\ERP10.2.400.0\Source\Server\Internal\MR\MrpExp\MrpExp.cs:line 2726
at Erp.Internal.MR.MrpExp.RunProcess(Int64 instanceTaskNum, String outputFileName) in C:_Releases\ERP\ERP10.2.400.0\Source\Server\Internal\MR\MrpExp\MrpExp.cs:line 926
21:06:13 Building PartList Level: 2
21:07:33 Building PartList Level: 3
21:08:31 Building PartList Level: 4
21:08:57 Building PartList Level: 5
21:09:02 Processing Schedule Load
21:10:08 Processing Orphan PO’s…
Yes, you definitely want to set the logging to MRP and Scheduling to troubleshoot a problem. You will get hundreds of files, that may have more detail about the problem. The MRP log should tell you what part was being processed when the error occurred. And there is a file for each and every job, and what scheduling decisions were made for it.
1 Like