Has anyone else had the MRP process break everything?!
Ok, maybe not everything… but it felt pretty close to that last week.
We have MRP (regen) run in the early morning hours every weekday. Last Thursday morning was no different. MRP finished successfully and all was quiet. Our schedulers also run MRP (net change) a couple time during the day too. Mid-morning Shipping called to say they can’t ship from a sales order. They were getting “Cannot Ship From Unfirm Job”… even though they weren’t shipping from a job.
When our Schedulers were trying to firm up their jobs for the day, they were getting “The demand job is not firmed, do you wish to continue?”… even though the parent job was in fact firmed already.
All our Transfer Order Lines that had not fully shipped yet disappeared.
We could not generate jobs from our sales orders using Order Job Wizard. That error was “Part detail not found”.
None of our PO’s were showing in Time Phase so it was generating a bunch of unneeded PO suggestions.
We found that a TON of data was missing from the PartDtl table and impacting each area above. Epicor Support is providing data fixes for some of these items to repopulate PartDtl. We fixed the sales order releases ourselves by running an update DMT to uncheck/recheck the “make” flag on all open sales order releases.
However, I’m looking for the “WHY” and “HOW” of this issue. I don’t want this to happen again. It was/is very disruptive to our business. The only answer I’m getting from Support on my 5 open cases regarding this is basically “if you can’t reproduce it, we can’t troubleshoot it”.
I have the logs from that last Regen run of MRP on that day, but I don’t know what I’m looking for. I’m not even 100% sure it was MRP’s fault. What standard processes in Epicor can delete mass amounts of data from the PartDtl table?
Has anyone else encountered this type of issue? If so, what was the culprit?
Open the logs and do a search (Ctrl + F) for the word error. That’s always helpful to me.
I’ve found that a BPM can mess some things up you wouldn’t expect. Any BPMs on any of the tables related to MRP?
Nope, I had searched for “error” and only a couple random unfirm jobs popped up an error about not finding a revison for one of our spare parts… not the end of the world. I also searched for “fail” in the logs but got no hits. So far I’ve stumped Support on all of my 5-6 cases that I have open for this issue. We don’t have any BPMs or customizations around PartDtl. We have a few change log BPMs on the Job, OrderRel, and PORel tables, that’s it. Should be nothing to cause concern.
You are not alone. Recently our PartDtl table crashed for the second time (first was back just prior to 2023.1.10, most recent was sometime just prior to Thanksgiving). Epicor has never provided any fix to rebuild partdtl despite numerous requests. We had to deal with tons of close and reopen on both our POs and Orders. This most recent we also had our Unfirmed Jobs affected and are working to get them cleansed. We still have an open ticket for this last instance, will let you know if anything comes out of it that might help you.
Another possible cause for the related error: Cannot ship from unfirm job
Resolution
This happens when there is a Job Number that is blank. That is invalid. So the system thinks that every Order that has a blank Job Number is related to this Job. That is all Orders Shipping from Inventory. So all we need to do, is correct the Job tables and change the blank value to a new value. It can be anything that has not been used before as a Job Number. Maint01 or E10FIX, donotuse, error, etc.
You will need to request fix OF_Upd_BlankJobNum.df.
@rob.neiley / @scline - Sorry to dig this post up from the grave, but I think this just bit us yesterday afternoon. My scheduler said Epicor froze up for awhile (5 minutes), and then when it finally started moving for him, it seems like our PartDtl table is missing most if not all of the Order Release information. There is a little bit in there now (SourceFile = 'OR' I believe is what I’m looking for) but I think that is because sales has created new orders or touched orders since all the order info disappeared from PartDtl table.
Is manually closing/re-opening every open sales release still the best way to deal with this, or is there some conversion I can run now? Do I need to worry about other records missing from PartDtl ?
Any advice you can offer much appreciated! We’re freaking out a little bit here.
Fair point Mark. We have experienced numerous data type losses inside PartDtl. Job related losses are most easily remedied by running a full MRP regen. For PODetail losses (where you still have an open qty on a POLine/Release) we find them with a simple BAQ comparison and then we use 2 DMTs, the first is to close the PORel (company, ponum, poline, porelnum, openrelease = false, reopenrelease = false) then we turn right back around and reopen the PORel records (company, ponum, poline, porelnum, openrelease = true, reOpenRelease = true). While this puts the POs right back in the same state they were in, it readds the missing rows of data into partdtl table as well. We have also seen the exact same problem and solution for OrderRel, only difference was since we have some sales kit we had to recode a field (don’t recall which one off the bat, but could find my files if critical).
We’ve shared all this with Epicor on tickets the 2-3 times it had happened to us. The never found a root cause. I have not seen a rebuild or fix process that fixes these issues.
Thanks @rob.neiley for getting back to me, and saving me the trouble of attempting to open a ticket with Epicor. I guess someone out there let us know if you ever find a conversion or process that can be run to rebuild all of the PartDtl records that don’t regenerate during a full regen of MRP.
We basically did the same thing Rob, after we figured out what all was missing. So far, we have discovered the following that needed fixing:
Sales Order Releases (Table Erp.OrderRel)
PartDtl.SourceFile = 'OR'
Ran DMT to mark OrderRel.FirmRelease as 0 and then again back to 1
Purchase Order Releases (Table Erp.PORel)
PartDtl.SourceFile = 'PO'
Ran DMT to mark PORel.OpenRelease as 0 and then back to 1
Did have to deal with some oddness where PORelease.Status was still V for Voided after the re-open, so forced these to be O for Open, but in a future run-in with this issue, would instead see if I can make Status part of the before/after DMT
Forecast (Table Erp.Forecast)
PartDtl.SourceFile = 'FC'
Ran DMT to mark Forecast.Inactive as 1 and then back to 0 for all where ForeDate >= CAST(GETDATE() AS DATE) (today)
Master Production Schedule (MPS) (Table Erp.MasProd)
PartDtl.SourceFile = 'MP'
Ran DMT to mark PORel.OpenRelease as 0 and then back to 1
Will come back and update this if we find anymore things missing we need to get re-populated.
