But in general I just want to see the part cost split in half and I am expecting to see a variance, but the whole job cost keeps going to the part and not splitting between the part on the fly and part.
I am producing a part and it uses 65% of the material and the part on the fly co-part uses 35%.
I want the costs to reflect that too, but it’s not working. I thought you just set the Mtl and Labor Yield accordingly and the system does the rest, but I am obviously misunderstanding something very fundamental because the entire cost is going to my actual part.
I am really confused. It doesn’t matter what I set those to, the cost never gets split.
FYI, I am not making a method for this, I am creating jobs and adding co-parts to the job expecting the same functionality that would happen when making a method with co-parts and yeilds and doing a cost roll…
We are using standard cost.
Here’s the business case… Every once in a while we run a part and we get a saleable co-part out of it.
We are costing the part wihtout the co-part in the method because that’s how we most often run it, but they want to see the favorable variance when we do run a co-part with it. That’s why I am trying to split the costs out on a job by job basis and not in the method.
I think I found maybe an issue that was causing my variances to not come out and why I thought maybe this whole thing wasn’t working.
#1 I think the part on the fly is not working well #2 they built the method of the parent part without using co-parts, but put the qty per parent for the material as if they were making a co part so when we do actually use a co-part no variances are being booked because the method was already hacked to come out to this cost (this I am confirming still).
@jkane@jgiese.wci I don’t expect many more responses, but I put the cost yields at 1 for my parent part and 2 for my co-part. Yet they are still coming out to an exact standard cost transaction when I Receive them off the job to inventory- no variances, not cost being given to the co-part. I would expect that because some of the cost is being allocated to the co-part that the parent part therefore costs less per roll than it was costed at- which would result in a variance. But it shows that its a MFG-STK transaction with its normal standard cost, and the co-part is also coming out with no variances.
thanks again for the time you already put in this. I am going to try @jgiese.wci 's thing.
Do y’all think it’s cause I am getting the details for this job from the method of the parent part which was never set up to produce a co-part? @jkane@Beth@jgiese.wci ?
They want to use the normal method of the part and then add a co-part on afterwards.
PArt A consumes all material cost and uses 30" of a 48" semifinished good.
We pull details for Part A.
Customer says, can I get another roll from you at 15". WEll of course, there are 18" left on the semi finished good so we will just cut another 15" out of it and be happy.
So I was thinking they add a co-part to the job, yield is 1:1 and then just adjust the costs yields accordingly, release the job, do the transactions, and the costs will distribute per the yields.
That’s not happening at all, regardless of whether I have two coparts, both being actual parts (not on the fly), or if I have a part and a part on the fly as the co-part.
I do not think it would be. You run standard cost and the cost is rolled for that MOM. Trying to add a co-part at the job level does not create a standard cost set for the part. So, I would expect it to cost out at the standard.
I could be wrong, but it sounds like it should not work how you want.
That’s the thign though, I don’t know why the costs aren’t being distributed per the cost yields. IF they were, then we’d get a favorable variance because teh method that the standard cost was rolled off of using 100% of the semifinished material, but now I am changing that using the mtl cost and labor cost yield fields where the co-part gets a portion of the cost and the parent part gets a portion… which is less than 100% and therefore should be a favorable variance.
For clarity, I am not doing anything in methods and then rolling costs. I am starting at the job level, using methods that are not set up for co-parts.
I’m just adding co-parts willy-nilly to the job and using the cost yield factors hoping like crazy that they do what all the documentation says they do, but getting no where with it.
That’s the thing Utah, you have a MOM and a standard cost for the main part, correct? And you are basing the job on that established MOM, I don’t think it will ever split because it does not know it should as you are dealing with master records.
Create a job for a POTF, bring in the details from the job you have been testing, create a POTF co-part, and see what happens.
Yeah after I close and complete the job I do end up seeing variances which is great.
So I guess it is working to some extent, but I am still seeing some strangeness with the exact variances.
I used @jgiese.wci 's costing factors of 650 and 350, but the actual cost yield came out at 67% and 33% respectively… Not sure why- maybe it’s rounding…
Also I confused myself more because like you just said @Banderson I didn’t run capture cost WIP with the post variances flag so they went away. Starting over from the beginning and hoping to get a little more understanding. Thanks a ton to everyone @Beth@jkane@jgiese.wci@Banderson
I did see them now when running inventory/wip report unposted. Then when I captured them they went away because I think I forgot the “post variances flag.”
So, I see a variance now, which is cool, but I would expect to see two variance transactions (one for each co-part) when the cost for per each part is above or below its standard cost, wouldn’t y’all @Banderson@jkane?
In other words, both co-parts are costed to be run separately. That’s how we’ve typically ran them. However, in this case we are going to run them together which results in the costs being split. This is going to be a net reduction to both costs because now they are splitting the costs between eachothter.
Logically that would mean each one costs less than what they would if you ran them separately… and that ultimately would result in two favorable variance transactions for each part… But when I run the inv/wip report I only see one variance being posted and that’s for the parent part.