Part Costs

STD and AVG are the only two for that question. If zero, how does Epicor handle that when a part is sold and the costing method is STD or AVG?

STD it will take the PartCost and book that value. if the PartCost and Job Cost are different, the difference gets booked the variance account on the Product group GL Control or Inv COS account.

Avg Cost it will take the $0 and add it to the avg of the other times that part was transacted. that value will get booked.

1 Like

to add to that, anything shipped directly from a job will use the job cost. I’m pretty sure that’s irregardless of the costing method. (I would have to check on standard cost, but I know it’s the way it works for average)

Average cost is updated whenever something moves into or out of inventory. Therefore, if you make something on a job and ship it directly, it does not change the average cost, because it did not go to inventory. On materials side, if a material is bought directly to the job, it doesn’t update average cost either because it skipped inventory.

3 Likes

One quibble: average cost is only updated by receipts to inventory - no shipments or issues of any kind alter the average cost. That also agrees with your statement about shipments from jobs, the cost comes from the job and the average remains unchanged.

2 Likes

@Craig Umm, No i do not like Accounting! :rofl::sweat_smile::rofl:

I was reading Job Costing Tech Ref and STD costs. It says that when the actual cost is greater than the STD cost, then the STD needs to be updated and to use the Costing Workbench to do so. So, from my limited experience, it sounds like when Costing Workbench is used (Cost Roll-up??) that STD looks at ACTUAL labor on the parts, actual jobs, to update the STD price to actual price. Does this sound correct?

I am reading page 127 under Costing Method-Standard

no, it’s saying that you should update your standard costs. It’s saying that if your labor cost doesn’t match your estimates, you need to change your estimates, and re-run the cost rollup. It’s not super clear in saying that, but it does not pull costs from actual jobs. There are way too many variables in tracking costs on a job for Epicor to put out something that would automatically, with very little review, apply costs based on jobs.

Now, if you want to create your own BAQ that gets actual costs from a job, you can run your own cost updates through DMT. But the responsibility is on the user (you) to make sure that they are right.

1 Like

In Part Tran, the MFG-STK, would that have any impact on costs?

if you are standard costed, it shouldn’t. The job costs difference from standard should go into a variance account. The idea is you’re standard should be about average, so some jobs will be high, some will be low, but it should even out. If you variance account is growing one way or the other, you have a problem that needs to be addressed. That’s what the tech guide is telling you.

If you are average costed, then MEF-STK will affect your average cost.

2 Likes

To follow-up on @Banderson…
If your part is AVG cost, a MFG-STK will calculate the new Avg Cost based on the weighted average of the QOH and the Qty being received.

For example, if the current Avg Cost is $100 EA, and you have a QOH of 10, then receiving 5 more, whose unit cost is $110 (say the cost of one part went up) would set the new Avg Cost to :

(Prior Cost * Prior Qty + New Cost * New Qty) / (Prior Qty + New Qty)

($100 * 10 + $110 * 5)/(10 + 5) = $103.33

And there would be no Variances created.

If the existing QOH is 0, then the Avg Cost is just set to the new cost
($100 * 0 + $110 * 5)/(0 + 5) = $110

I believe the Last Cost in the PartCost file is always updated when a Receipt happens (PUR-STK, MFG-STK, PUR-MTL, etc…), even when the part uses another costing method.

1 Like

I appreacite the help you and @Banderson have provided. I am trying tifure out why two identical parts in engineering have so different Costs in Part Tracker. Same costing method, same engineering, same resources, everything is identical. The difference is the color and that is printed and adjusted across the board in the engineering. But in part trans i can see where the costs went different, but nothing make sense since its STD. So, put it out there the MFG-STK to see if that straw I’m reaching for I could grab. Starting to not like accounting very much! :rofl::rofl::rofl:

If you look in method tracker and look at the cost there. What do you see? That is basically doing the “cost rollup” real time.

image

1 Like

Left is the Method tracker, Right is the Tracker

yeah, now for the other part that you say doesn’t match.

I doubt it’s your problem, but one big GOTCHA we ran into was with receiving less than the jobs production Qty to stock.

Again we don’t use STD, so not sure how much of the following would affect you…

Say we have:

  • A part that uses AVG costing, with an Avg cost of $100, and a QOH of 10.
  • We make a job to produce 10 more for stock. The Materials issued to the job have an average cost of the parts made of $110 EA.
  • We receive 5 of the 10 into stock without reporting qty completed.

You’d expect the the MFG-STK transaction to update the AVG cost to
($100 * 10 + $110 * 5)/(10 + 5) = $103.33.

But it doesn’t. The new parts will come in at ZERO cost because the production qty wasn’t reported.

So now the Avg cost is
($100 * 10 + $0 * 5)/(10 + 5) = $66.67

When the final 5 parts of the job are received, they are given the full value of what the job cost. I.E. their cost is ($110 x 10) / 5 = $220.

Now these 5 at a unit cost of $220 is used to calculate the new AVG cost
($66.67 * 15 + $220 * 5)/(15 + 5) = $105

The same Avg cost you get if all 10 were initially received
($100 * 10 + $110 * 10)/(10 + 10) = $105

So everything is fine … assuming you didn’t ship any in between the two MFG-STK receipts. Those would hit your cost of sales at $66.67. And it would affect the new Avg cost calculated (since you don’t have the same “prior qty” when the 2nd receipt happens.

2 Likes

Are you worried about $0.02?

I am not, but my boss wants to know why the difference. Truthfully, its been like this even before I was around. I just need a valid reason why, and so far all the ideas I’ve had are not accurate. So, trying to find an accurate reason.

It’s probably rounding error.

At 5 decimal places?

When you look at the method tracker, it has all of the pieces in the grid above. So you can compare it with more granularity there. Without access to your data it’s pretty hard for any of us to track down.

1 Like