Good afternoon and happy Friday!
We have an oddball thing happening - I’m hoping one of you might have some extra insight or advice.
We recently noticed a strange occurrence. We have many demand links on jobs whose production quantity value differs from what the quantity on the sales order release says it should be. I’m only looking at Make Direct jobs. At first, this didn’t seem like such a big deal. The job head production quantity was correct and therefore it seemed to be planning the materials correctly. But today, we stumbled into a big hole. There are 6000+ jobs that are missing their demand link to the sales order. Therefore, they are planning for 0 qty. You can imagine, our PO Suggestions are all over the map right now.
MRP appears to have run correctly last night. When I looked at a few tables, PartDtl for instance, those jobs have entries in there but for quantity 0. So it seems like MRP planned it correctly given that the job is saying to build 0 parts. Where are the demand links? What is happening?! JobProd seems to be all out of whack.
I wanted to put this out here as a PSA to provide closure to this topic just in case it helps someone else along the way.
I don’t know all the tweaks made to MRP in this version - but EpicCare basically said they couldn’t help us with our problem and the only solution was to upgrade - at least to 10.2.700. I won’t get into the details - but we were not able to upgrade at least for a month or two because we need updates to our server.
So I kept asking questions and poking and prodding and eventually found the issue. The demand links were goofy because somehow the JobProd table got out of sync with the JobPart/JobHead tables. So the wrong part number was being associated to JobProd - and basically that was causing a bunch of stuff to fail. Specifically, when MRP would wipe out the unfirmed jobs during a full regen, it would miss all of these broken jobs because they were not being identified in the join that Epicor uses to generate the list of jobs to delete. The join includes PartNum between JobPart and JobProd. So no returned records meant that the jobs just hung out there. If you should find yourself in a similar situation, we ended up having to manually deploy a .DF in the Data Fix Workbench that effectively manually wiped out all the records that MRP should’ve wiped out but didn’t. This 100% fixed our issue. I’ve attached the .DF file in case you need it. Always do a backup before doing something like this… Try it out on the non-Production environment first… etc.
Finally, what caused this to happen in the first place? While I don’t know exactly, I have a strong theory. After we did this fix, I noticed a cluster of MRP-generated unfirm jobs that did not even have a PartNum. It was as if someone created a job but never filled out any of the other information. I dug into the MRP logs and searched for those job numbers. I found the list of part numbers it was trying to create jobs for… but MRP was encountering some kind of error and it would move on to the next line. I found the common theme with all of those parts and they were all affected by a BPM which would generate a row in a UD table that we use for tracking Programming related variables. That BPM was not handling an MRP created job properly. So I had to add an extra condition to that BPM to handle when MRP was creating these jobs. When I fixed that, the next time MRP ran we did not have any such jobs missing a PartNum. JobInconsistencies.baq (43.3 KB)
I am also attaching a BAQ that I wrote which looks for inconsistencies in jobs. This is what I used to determine which jobs were broken and communicate that list to Planning so they knew which parts not to rely on Epicor’s suggestions. So I have been running it every morning now just to check that there are no new broken jobs. If you choose to make your own BAQ, don’t rely on the automatic joins that Epicor will place between tables. That was what kept me in the dark for so long. CR36561MPS_10_2_300_41_SQL (2).zip (258.4 KB)
First of all, thank you for this! Next, I tried this out in TEST and got good results; didn’t have any jobs with a zero qty. Although, when I tried this out in LIVE, it worked well but still have a handful of jobs with zero qty. Is there a sequence of activities you’d recommend during this process? For example, would running the Update QOH and Allocations or MRP Recalc or a Conversion WB task be needed before/after running this step? It seems to work well enough but still have some questions about related processes/steps along the way. Any input would be very appreciated and thanks again for the heavy lifting portion
I don’t recall us running any extra utilities. I can’t help but insist that you set up your MRP Logging properly. Make sure the name of the logs is specific to the environment you’re running it in… Set it at least to MRP Logging Level (not Basic). Then use those logs to help identify what is throwing errors during MRP. I literally use Ctrl + F in the log to look for keywords like “error”. If you’re lucky, the error will tell you what the problem is. Then you can fix that… but make sure you figure out what is causing the discrepancy before applying a datafix or you will continue to allow the discrepancy to screw up the data.
