10.2.200.35
Hi, everyone! I have a question that just came up today on which I need some help. We use Standard costing, and are looking at a couple of invoices that have very different unit costs for the same part. When looking at the field help for the InvcDtl.LbrUnitCost and MtlUnitCost fields, Epicor says that the fields can be updated by COS/WIP Capture if it has not been run prior to invoicing. Below is the text from the InvcDtl.LbrUnitCost field. Does this mean that the unit costs on an Invoice line can change whenever COS/WIP runs, even after posting? Or will this calculation only be performed once if COS/WIP hasn’t run before the invoice is generated?
Labor Unit Cost. The cost is initially captured on the PartTran record for the shipments (MFG-CUS, STK-CUS). It is duplicated from the PartTran when invoiced. If shipped from inventory then it is the cost captured from the part master at time of shipment. If shipped from job it is calculated during the Calculate WIP/COS period end process. Note: the Calculate WIP/COS will also update this cost for invoiced job shipments which had been invoiced prior to having the costs calculated.
If you use standard cost, the cost won’t change. If transactions hit the job, causing the “cost” to be different, those extra costs would generate variances, and not change the COS of the invoiced item.
Job created, for a part with a $100 standard cost.
$95 of materials issued to job
Job shipped
Shipment invoiced. The COS for this item will $100.
Capt COS/WIP run. A MFG-VAR of -$5 will be created.
$10 of extra parts issued to the job.
Capt COS/WIP run. A MFG-VAR of +$10 will be created.
Job cost of $105 ($95 +$10) = $105 (COS of $100 + MFG-VAR of -$5 + MFG-VAR of $10)
@ckrusen I am going to ask one more question about this. I went into a testing environment and went through the process you outlined above just to see it in action and it worked just as you said. I love that about accounting.
Here is a business case I have and I am wondering what we can do to get around it. The sales team (and others) would like to see gross margin for products. I am sourcing the cost elements from invoice detail, but occasionally there are parts where the standard cost is wrong so when the shipment happens those costs get posted to the invoice. Using what I learned above, I see that a MFG-VAR is posted for the difference between that incorrect standard cost and what was recorded on the job, BUT what to do about the costs on the invoice when trying to calculate gross margin…
If I use those costs the gross margin is way off and doesn’t make sense. Is there something you have done to get around this? I had an idea to make UD fields on invoice detail to give the adjusted actual costs and use those for gross margin reporting purposes.
Not sure if there is something native in epicor we could do to “fix” those costs so we could get an accurate gross margin.
Maybe it’s something as simple as just excluding those crazy invoice lines.
Are these all custom, make to order jobs? Such that you can wrap your arms around everything for the jobs that ended up making that invoice entry? If so, then the true COS would be the COS + MFG-VAR (for the job(s) related to that invoice line.
If it’s an item that the job might satisfy multiple orders and/or to stock, then it would get trickier.
A couple of things to keep in mind:
The MFG-VAR transaction isn’t created until the job closes.
A partial shipment of a job might not be costed properly. This happens with AVG costing. In the end, it is properly costed, but the first shipment might happen at zero cost, and the last shipment ends up with all the cost. STD costing would probably not be affected.
If there are sub assemblies with their own jobs. You’d have to include those variances (if any) too.
Is this all in for a BAQ Report or a tweak of a built-in report?
PartTran. Make a BAQ of the PartTran table with table criteria for TranType of MFG-VAR. Sort JobNum. Take a look at that, and see what you get.
Multiple MFG-VAR’s per job would indicate that the jobs are re-opened and costs added/removed, and then reclosed. Not sure if they could all be just summed up or not.
Is the Custom CR report a BAQ report (but with CR as the rendering engine, as opposed to SSRS)? Or is this from outside of E10 and CR just connects directly to the E10 DB?
They do it direct right now from a CR report outside of Epicor. I stick to BAQ or RDD when possible.
Your suggestion to look at MFG-VAR works for those jobs that have a cost different from the standard, but what about STK-CUS shipments that go out using a bad standard cost? Is there a way to revise those?
It’s possible to derive accurate costs for shipments from stock, but could be very complicated. If they were lot controlled parts that would make it easier becuase then you’d know which jobs were for which specific parts shipped. Otherwise, who will you know which job (and its associated variances) made the inventory that was eventually shipped and invoiced.
I think the real issue is why are the STD costs wrong and/or why isn’t production meeting them.
And while accountants need to account for every penny, they’re usually more concerned that everything nets to zero, over being exactly correct.
They agree that the wrong standard costs are an issue and that the root of the problem is just that. They are going to start fixing and staying on top of it, but for historical purposes is there any way to clean it up at the invoice detail level so we can look back at clean data?
Adding a UD field to InvcDtl would be allow you to set “fixed” (both corrected, and unchanging) COS for the invoice line. Which you could then calculate and update for existing InvDtl lines.
The down side would be the maintenance of calculating (or re-calculating) that value for future invoices. It might seem like a BPM could just calc that value and update the InvDtl table, but that would only happen when the invoice is created - and that’s when the COS has the least confidence in its accuracy.
To add onto that… would you really want to be updating those native fields on InvcDtl and interject with epicor best practice?
If we were to use the UD fields I would imagine we only go back and fix those margins after posting/close. It doesn’t happen that often given our volume of invoices and shipments.
Thanks for your input @ckrusen have a great weekend.
Epicor stores final cost from job including variances in the InvcDtl cost fields starting with JC like JCMtlUnitCost, JCLbrUnitCost, etc. These fields get updated when the job is closed. When Sales Gross Margin Report run with an option “Use Adjusted Cost”, it picks from these fields if it has non zero value.