Oh I know, i was just lamenting that this is not so cut and dry. That is one reason I love math is that it is cut and dry. 2+2=4 always. However, it seems something is calculating funny and has been for a while. At this point, I am going to recommend a consultant help me.
Well, something is probably different somewhere, but itâs so small it might be the law of diminishing returns to fix it.
If you really just want them the same, you can manually update one of them too. That doesnât fix the root cause of the rollup showing something different, but it fixes the accounting problem.
I agree, something is off. Its the WHERE! LOL!!! I am working on it with my engineering lady now. The granular costs form Method Tracker shows the difference is in our ink and labor. Not sure why the labor, but I get the ink. Hopefully we can finally find it.
What screen and sheet is the left image from? You say âMethod Trackerâ, but I see nothing like that in mine (10.1.400.23).
Okay⌠What sheet?
EDIT:
Never mind ⌠I now see the âView Costsâ under actions
Actions view cost
So looping back around⌠The OPâs issue is that the cost from the method, is not what is used when the STD Cost Roll-up was performed?
Furthermore, two assemblies (one Red, one another color), use the same parts and qtys - save for the RED part(which has the same unit cost as the non red part), but their costs are different.
OP should re-arange the columns in the Method Trackerâs View Cost, like such
And compare the two parts
No, the method is whatâs being used, but the costing from the method from 2 âexactly similarâ parts, doesnât come back with exactly the same cost. (the labor is $0.00031 off.)
Actually, over all, including labor, is about .02542 off. Iâd expect the labor to be the same but its off by the .00031 you mentioned. Material I think i have a lead on. Waiting for my engineer to come and confirm before I speak.
I would use the View Cost action of the Method Tracker, and export the grid to Excel. Then do the same for the other part. then compare them line-by-line to see if there is a diff.
If there are any Mtl lines that risk rounding errors, try removing them from the MOM, and then re-adding them. [clutches at straws]
@Banderson @ckrusen I found the issue! I got tunnel vision and didnât think to check out ALL the revisions! Cost Roll Up looks at all approved revisions. When I got my head out the tunnel, I noticed there are differences in material.
Last question⌠Cost Roll Up looks at all approved revisions. How does Epicor figure the cost with more than 1 revision?
? Test it out. Let us know what you find.
Answer is⌠Which ever is the last approved revision that was checked out and back in. Epicor does not average all the costs, it jsut looks at it in this method.
- Is it approved? No-Move on; Yes-Next step
- More than 1 revision? No-Do the math. Yes: Find the one that was checked out and in most recently and use it.
I was a little surprised Epicor doesnât look at all revisions and give an average, or least let you have that option. guess you could do a your own part costs via a DMT and a BAQ, but that is time consuming. So not perfect for us, but understandable.
Thanks for Testing .
Are you sure itâs not the latest approved revision as sorted by effective date? Someone else here thought it was by last checked out for something else, but that wasnât true.
Also, most people donât run with 100âs of approved revisions like you do. Your company is kind of an odd duck that way.
We are a very odd duck! But, I know it is not based completely on the effective date. Yesterday my method was to create two new, but fake, material parts, and one new fake manufactured part. The Manufactured part was setup with the one mtl part in Rev A and the other in Rev B. On the same day, I made all the changes. SO the effective date was identical for each Rev. When cost roll up ran, it was with the one last touched.
Can you do a test and change the effective date so that they are different? Check out the older one last and re-run and see what it does?