I’m on 10.2.100.36. We have a manufactured part that’s basically a printed sheet of paper. Multiple final parts will be cut from it. The IUM for the printed paper is EA, which does not allow decimal places. So we created a new UOM called MFG which does allow decimal places and has a 1:1 conversion with EA. The BOM for the final part calls for something like 0.02 MFGs of printed paper.
Cost rollup is coming up with a required quantity of 0 for the material, and therefore a cost of 0. By changing the number of decimal places allowed on EA in my test environment, I determined that cost rollup is calculating the required quantity using the number of decimal places from the material’s Part.IUM instead of PartMtl.UOMCode. This is unexpected. Is this a bug?
We have the same issue. Were you able to resolve your issue? Wondering what approach you may have used. We are going to contact Epicor customizations group to see if they can build a utility that would change the UOM’s on the affected parts since there’s been so much activity, the Part UOM conv doesn’t work.
I think my boss used a direct SQL update to change the IUM of the sheet part from EA to MFG. If the UOM conversion tool that Calvin mentioned doesn’t work, this may be your only option. This may do terrible things to your inventory valuation if the UOM conversion isn’t 1:1 like it was in our case.
@John If there is a lot of current activity it gets more complicated. If you have open POs, Jobs, boms with the part they all have to be removed for the processing of the change and then put back. It is best of all of the activity of the current structures parttran records have already been posted.
If you have screen shots of where the part is now and could make a new part in test with where you want to end up it would be easier to see if there was a possible path to get there.
With respect to the costing, Epicor says the cost rollups work as designed. The Part IUM is used for the rollup regardless of the BOM UOM. So the next option was changing the UOM, which we couldn’t do, so this particular client from the original email just created new parts with the right decimal IUM.
However, at another company, a previous independent consultant built a custom utility which lets you select all the possible places a UOM exists, then changes the UOM through the database. They always check all the boxes for the various tables with the IUM.
It’s worrisome to use it as there have been a few things happen the utility doesn’t account for, but overall, the end user continues to use it, but only as a last resort. Their issue is simply new part setup errors caught after activity has occurred.
Ran across my own old thread. I missed some of the replies because I have a new account.
Yes, you can select some other UOM on the PartMtl. The issue is that cost rollup ignores the number of decimal places for the UOM you’ve chosen there, and instead rounds everything to the number of decimal places from the IUM. If the rationale is that you can’t use a fraction of the IUM, then it should always round up, not down. Pretty clearly a bug, and potentially one with major financial impact.