We are on 10.2.500.40. Average costed parts are causing variances even though we do not have any late arriving costs. The mfg-stk transaction is only done when all labor and materials have been issued. The only thing I can think of is either scrap on operations or ASSM-INS transactions. We are closing jobs with the quantity completed less than planned but again we only do this transaction after all costs have been updated. I can see where the variance would be the difference in the amount of parts not reported but we are seeing variances that are way higher than the quantity not moved to stock.
We have move costs to DMR checked and enable cost elements = true. Anyone remember bugs in this version?
We had the same issue and, unfortunately, the only way we could reliably get control over it was to change the demand quantity to match the production quantity before receiving the parts to stock.
The WIP RECON just gives me the usual debits and credits. Doesn’t explain what is causing the variance. I suspect it has something to do with material but at this point I cant get it to tie to the variance amount
Where is the variance happening? If it is not happening on the job (mfg-var), is it just the standard adjustment of adjusting inventory cost due to a new quantity entering inventory?
Its coming from the job itself. We have only one mfg-stk per job when all costs have been added. We use scrap and non-conform all parts before deciding what goes to reject and what comes back to the job, Last job we did was for 105 pieces, we send all to Inspection. 9 went to reject to DMR, the other 96 came back into the job before the mfg-stk transaction but the costs to mfg were around $3100 and the variance was around $2,300 so not even close to the cost of 9 that were rejected.
Sorry, I messed up on my wording in an earlier post. Does the Inv/WIP Recon show phantom purge to variance anywhere? If yes, those are the lines that will cause the variance when the job is closed. If there are not any of those entries, do you have a GL account set for variances on the GL control?
I’m asking this without knowing the answer, because it’s something that I recently learned our users are doing that I have suspicions is causing a lot of the purge to WIP our Finance team sees:
Are your jobs being set to Completed (like manually through Job Closing) before they are received to stock/job/assembly or shipped?
(Again, I don’t know that this would create a purge/MFG-VAR transaction, but I suspect it might and intend to test soon, unless I find that answer here somewhere.)
That looks like it was run after the WIP was captured as it does not say Phantom. Trying to figure it out after capture is more difficult. You should run the Inv/Wip Recon report before capturing the WIP and see if there are any Phantom entries.
This should not be causing a variance as you are still able to transact to a job when it is Complete. Closing the job does not allow for additional transactions.
Sorry for all the posts, but it has been a while since I have had to troubleshoot variances and it just came back to me.
You need to look for transactions that happened AFTER the goods were received to stock. It looks like everything was received to stock on 1/17. Are there any transactions anywhere on the report that happened after 1/17 (other than the variances)?
There were but a very small dollar amount. I did a time stamp on the part tran record for that job and it shows the mfg-stk transaction was done about 10 minutes after the ins-assm was done which returned 96 parts to the job out of the 105 total
We are in a similar boat as you (avg cost with consistent variances) and after extensive testing got some expert consulting help on this. I saw the real solution mentioned in one of the previous posts, but not with enough emphasis to get picked up on so I’ll restate it here.
If you don’t reduce the job production quantity prior to your last MFG-STK transaction, you will leave some cost on the job. The reason for this as the system is expecting that additional part to be produced and it bases all of the math on that amount. For example, if you have a job of 10 and one falls out so you’ll only be making 9, leaving the job qty at 10 will hold back the labor and material costs for that last one. If you reduce the job qty to 9 then do the last MFG-STK transaction, the costs will get cleared off the job as it’s not expecting to make anymore.
We built a BPM that adjusts the job qty amount when we move the failed part off of the linked DMR to a rework job so we can avoid the manual step of doing this. However, this is simply helping automate the process that needs to be done to avoid variances and can also be done manually fairly easily.
@elfrykman , thanks for posting. That is some fantastic insight and makes sense.
Do you think someone should create an Idea to put a Received Complete flag on Job Receipt like exists on Receiving lines? That way you could tell the system that regardless of Prod Qty, that’s all you are receiving.
