I’m reconciling the BOM cost report with the GL (Inventory/WIP report), but they do not match and there are discrepancies. I ran the cost roll without posting and checked the cost set group report, but the BOM cost remains unchanged. Do you have any recommendations or pointers on what to check
What costing method are you using on the part you’re looking at?
The wip report matches the material issued to the job based on the cost method of the material. In job tracker there is a transaction tab under the assemblies tab that should show you the cost of the materials added.
4 Likes
…at the point in time each was issued. If component costs vary (and they always do!), that can make auditing the provenance of cost aggregated over a timespan more tedious than expected. Greg’s approach is good - if you can drill down on one job with some side trips to time phase inquiry, that can be an approachable way to prove if that job’s costs make sense or not.
And then someone will ask why neither cost matches that job’s estimated cost, which of course is a snapshot from yet another point in time.
1 Like
I’ve always felt that Epicor could make a boatload of money providing the very tools and screens and functionality to reconcile these variances and costs. They write the engine that posts the costs to the GL, yet there’s people all over the world still asking, how do I make sense of this. If they have the logic written, then write it in a way that people can audit it.
1 Like
That leaves the boatload for us 
Also as soon as someone writes a custom wip recon posting rule which I have then they would also have to adapt to those.
1 Like
Man if they can post it to a GL they can give the detail behind what parameters it used- custom rules included.
But yes, I have a boatload of work ahead 
Trying to start up standard costing for real here soon… Needless to say, it’s a little overwhelming.
3 Likes
AKA job security! 
For real though, it’s not just an Epicor thing. Job estimate vs last week’s actual cost vs today’s part bom cost always start arguments that make work for the data folks. “We used up the last of the cheap bolts when we did that job last week, that’s why cost isn’t what we’d expect this week” is usually what the answer looks like. Then it’s purchasing’s problem mwahaha.
Except for estimated total material cost in Epicor. It’s a copy that is separately maintained and sometimes it gets out of alignment.
2 Likes
I might be oversimplifying, but Tranglc is your friend as well as having your gl correctly set up to capture manufacturing variances. Won’t stop the arguments, but a clear understanding across the board of what a major variance is.
Getting multiple people engaged of $100 that happened last month, then getting ERP specialist engaged, makes no financial sense. In your example it may not be the case.
Others would argue “Look after the pennies and the pounds will look after themselves”, that quote can be counter productive in some respects.
Finally every business is different in process and culture, we need to keep reminding ourselves that Kinetic is General Manufacturing, Distribution, CRM, Finance, project management… (did I miss something?) system, so we can’t expect it to be perfect, by all means throw the idea over the fence about the parameters, I am pretty sure the direction you will be pointed in is the posting engine and the transaction technical refences, which by the way are very useful tools, laborious as they are to read (Hmmmm copilot transaction what if posting tool) That would be a time saver.
3 Likes
This is what I’m saying though, why does it take an ERP specialist or looking at the TranGLC to understand a variance. When the posting engine runs and chooses to post the variance to a material variance account based on GL control, it knows the cost it’s comparing against, and the cost that was posted and why it was that cost, put all that math and breakdown somewhere. What parts did you source the cost from, why were those parts costed that way, what rev did that come from, etc. It should take me the same amount of time to look at a penny that it takes to look at a pound, unless there’s many variances that make up the pound, but one variance should take the same amount of time to understand.
I know we all have come up with reports so that what’s posted to the GL can be made sense of, and we all know about tranglc and how it ties to part tran and how that ties to the costing method and the way the transactions were made, etc., but why do all of us have to make the same reports over and over. The posting engine has all the logic in there to have made the transactions, post the detail behind each calculation that was made, that’s all I’m saying.
Wishful thinking I know, but standard costing is standard costing across any industry, so at least for that costing method I think the rules are the same.
1 Like
I have been pondering today after my exasperatingly long reply (sorry).
I am thinking that being able to create a prompt. “Explain how the cost for this part arrived at this value” and it would go though the logic based on the Transaction hierarchy documents and the Posting Engine tech ref and others"
Now that would be a useful tool.
1 Like
Exactly man
oops forgot to mention the information from the Epicor Support KB
1 Like
They know exactly how the calculation was made, so break it down for us so it doesn’t take a whole team to understand. Make it so that anyone can look at it and walk through the calculation just like you said.
1 Like
Yeah, I think I recall that KB.
1 Like
I was meaning have the AI suck up all those 14854 KB articles as well. I believe AWS Bedrock has the capability to do that.
oh… I guess, I really just want every variance to have a breadcrumb trail about why it came up with that variance (down to the cost rolls that the costs were based on). This would be much easier for standard costing, where average costing would be a littttttle difficult.
If they were accurate.
I am making a PPT for finance here about this, and every time I pull an example out, I have to apologize for a typo.
Here is a simple one - which “clearing account” [context] is it? Yes, a finance person knows that a PO isn’t going to AR. But would a robot?
(Unrelated, the strikethrough is not the error. It’s just illustrating that WE had intentionally not set up a clearing account on the AP GLC.)
A more glaring issue from a few months ago - drop shipments use an account context of “Drop Shipment” - not Inventory.
All they did was copy-paste the PUR-STK and not go back and edit it for drop shipment:
(Also, PUR-STK is not only for BTO…)
I always go to this doc as well, for simplicity. But when I know it’s lying, I use the PE Log Viewer to show me what REALLY happened.
1 Like
what I’m saying is, don’t give me a document, just tell me where it was pulled from, tell me, this posting was pulled from the Part GL control, on the screen, visually show me the GL control code it was pulled from. Same thing with the costs. Just make it part of the module. Let me dig into every variance and show me exactly how it was calculated just like we had to in grade school math.
1 Like