Help!
We are on E10.0.700.4 and MRP has been very stable for us for the past 18 months. However…
We had 15 top level assemblies fail to plan last night in MRP. All of them failed with the same error message.
Unit of measure not found for Class:Count UOM:FT
So, we reviewed every part on every BOM affected and none of them had a UOM Class of Count and a UOM of FT. We then wrote a query to review all 325000 parts in our database to see if any of them were setup like this. We found one part, and that part was not included in any of the affected BOMs.
I have entered a case with Epicor Support, but I am hoping that someone in this forum has seen this type of error before and can offer some guidance.
UOM’s are tricky business… Did someone revise the UOM table???
Were these top-level ASEM’s new? Did they "plan’ with no issues previously?
Do you have a TEST platform recently deployed that you could compare PROD UOM structure/content to TEST? Can you run MRP in that TEST environment? How old is TEST?
Your problem is either in the UOM table, or on parts on a MOM RELEASED YESTERDAY!
Presuming MRP ran correctly prior days… (see note below)
Eng-workbench data can offer insight into which parts may be the culprit.
Your 1st problem is NO MRP
2nd problem… what caused the error?
1st problem!!!
Thought: Is it possible to eliminate the demand for these TOP level parts (push SO date out 1 year?) or set MIN to zero temporarily?
MRP will NOT attempt to explode the MOM unless demand exists at the top-level.
Hopefully, at some point u will get clean MRP, and production info…
Then you can work on Problem 2…
You could: slap a copy of Prod into TEST… then do your digging.
Or evaluate the details of these 15 jobs…
or simply re-engineer/
NOTE: Had a brain-frying MRP issue years back and did DEEP dig on the MRP log.
The part causing the problem was actually the PART AFTER the one displayed in the error message!
Found out the EPI-LOGIC did not present the part in the error message causing failure, but showed the last one processed. Also had a problem when a circular reference within a MOM was engineered. Level 2-thru-7 was good, but on 7 a part on level 2 per this branch was listed on level 7…
Good Luck!
We occasionally will have a new part made with an Incorrect UOM. If there are no part transactions against it AND it’s not in a BOM you can change in the part maintenance.
If there are no part transactions, but it’s used in a BOM, you can’t change it in part maintenance, but DMT will allow you change it. Then you have to go into whatever BOM it’s used it, check out that parent part, and update the UOM there. Until we do that, we would have the mismatch like you are talking about.
If you knew all that, just disregard. We don’t use MRP, so I don’t have any help there. I have seen where Epicor will check through a whole table for an error and find things not related to what you are doing and error out, so you can’t always rely on the system to not look where it shouldn’t.