MRP Job Deletion Takes 4 to 5 hours


(Jonathan Lang) #1

Good Afternoon everyone,

If you use Sales Configurator you may have noticed that MRP takes 4 to 5 hours to delete jobs BEFORE actually starting MRP. In total MRP runs for about 10 hours. If your business is anything like the one I work for MRP is crucial to the day to day operations.

Now I’ve been a pretty squeaky wheel for Epicor Support, maybe a little bit louder than squeaky, to get this bug fixed. I’ve been working with Warren Germsheid, Epicor Support, to try and resolve the problem. We’ve discovered the root problem has to do with PcValueGrp for Job Material.

From Warren Germsheid:

2018-04-12 15:12:36 -Warren Germscheid
Jonathan

This is a reported issue and is currently being worked on and I have linked your issue with the problem. What development has determined is that the that the hang up is on MfgSys After Delete of Table: PcValueGrp for JobMtl. Please tell everyone at e10help if they have the same issue to please put in a ticket so I can add them added to the group as well. We will get everyone the fix as soon as it is available.

Thanks.

Have a great day everyone!


(Jonathan Lang) #2

If any of you are having this issue Epicor would like to know what version of SQL you are running. The pattern they THINK they’ve found is all of the users are using SQL 2016.

Please reply to this post or submit a ticket with Epicor and include your SQL version.


(Nathan your friendly neighborhood Support Engineer) #3

Please open a support ticket and not just respond to this post please and thank you.


(Nathan your friendly neighborhood Support Engineer) #4

Can you please run the PDT Config Check and attach the exported results to the case you have with Warren please and thank you? KB on how to do that: https://epicorcs.service-now.com/kb_view.do?sys_kb_id=0f4c0f61db0dd7484fbe7aa9bf961982


(Reon Dunlop) #5

Hi

We’ve also seen this issue, we’re on 10.1.500.15 in a single tenant hosted environment and a Epicor help case has been created.

I believe we’re on SQL 2014.

Regards
Reon