It doesn’t go back in time but you could also use a cube/executive query to take a timestamp of standard costs on any schedule you want. Low tech.
1 Like
Yahtzee!
I know, it sounds like we hate efficiency.
But there are not many things that we make more than once. Our main product is always engineered to order, so every order is quoted at that time, roughly based on a dashboard I made.
Then there are a few dozen components that we still make and stock at standard cost. Yes, those need to be reevaluated each year. But I made a dashboard to make that easier also. Again, that’s not that many parts, so it’s not a big to-do.
1 Like
I figured that was the case, that you were engineer to order, that’s wild man. Hard to manage those types of parts and costs in a systematic way!
Good use case of an existing tech.
I was just reviewing this entire post, and saw that I was asked a question (but not tagged, so I missed it… sorry).
No, having multiple cost ids, and storing them does not store the methods of manufacturing as well… it only stores the cost. Any analysis of what the changes were would need to include looking at the BOM Revision history. This of course assumes that you actually keep the revisions, and their effective dates. Some companies (shame on them! 
) actually make changes to their boms and routings without creating a new revision. if that is done, then tracking the changes is not possible… but if you enforce good engineering control… then every change to the bom or routing would have a new revision with a new effectivity date. then you can look back and see what BOM Revisions were changed while trying to analyze what changed in the cost.
2 Likes
That’s us right now haha, trying to change that of course.
Are you sure that the costing workbench tables don’t have a rev in them?
Thanks a ton for all of your help on this Tim, I used one of your comments on the ideas portal that you had for me to keep multiple cost site IDs.
Now that we keep inventory by REV in the latest versions of Kinetic, then a part with two revs could have two different costs. but in the olden days, we didn’t support that. also, your question referred to the need to see what the BOM was at the time you did the roll… we dont have that UNLESS you capture the revision.
Yeah exactly, that’s truly what I need. May have to write a BPM or something to capture it in the costing workbench.
Do you know of any clients doing this via BPM or something?
I really need the rev that was used during the roll.
i dont know of anyone… I just looked and realized that we do NOT yet have cost by revision yet… that is a future roadmap item (
Safe Harbor).
In the future we hope to have costing and purchase price and sales price by revision. but those are a bunch of big asks that we are still investigating.
To capture the revision level using for the cost, you would need to write a BPM that would lookup the active rev (not necessarily an easy task) and then push that into the data set into a UD FIeld.
1 Like
Thanks Tim, I feel like during the roll process it’s going and getting the rev that it’s using to come up with the roll and ideally I’d like that posted to the costpart table for that costing group.
Then you can see when that group was posted and you can see the revs that were used.
That’s ideally how I’d like the rev to be stored. There’s also alternate revs involved.
Tim,
These highlighted fields exist in cost part. So they are there.
And a cost group has a posted date so that’s the date that the cost would have been changed for all the parts in it and the same thing you’d see in part tran for those parts on that day as long as the posting went alright and didn’t hit review journal.
It would have to have been posted to a cost site ID that was assigned to a plant or company otherwise there would be no part-tran impact and that’s why using part-tran is the most reliable way to source when something was last adjusted and it avoids all these “what-ifs.”
In any case, I just wanted people to know that a costing workbench does roll by revision and alt method and it does store which one it used in the costpart table for the costgroup you are in.
So I actually deployed this for us a couple of years ago, was very useful except it doesn’t catch those misc individual cost rolls and cost changes that happen throughout the year on individual parts.
We typically do one possibly two cost rolls per year. 99% of our parts are using std costing methods. We do individually roll parts when there is a significant method change to make the part. These costs are not captured in the solution using the cost id method.
I like the BAQ method. Cost Adjustments and Cost rolls require a reason code right? Can that be filtered on to exclude the variance ADJ-CST transactions?
1 Like