Part Costs

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.

1 Like

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).

It is a stock screen.

Okay… What sheet?

EDIT:
Never mind … I now see the “View Costs” under actions

Actions view cost

1 Like

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.)

1 Like

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]

1 Like

@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.

1 Like

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.

2 Likes

Answer is…:drum::drum::drum::drum::drum::drum::drum: 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.

  1. Is it approved? No-Move on; Yes-Next step
  2. 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 .

1 Like

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?