Declining Job Finish Unit Cost
Solution ID = KB-698
Goal : Declining Job Finish Unit Cost
Version = All Version
Module : SLMFG
Fact 1 : SFC
Fact 2 : Costing
Symptom : You see multiple job finish transactions for the same job and the unit cost is decreasing with each transaction.
Fix
Overview
If your "Cost Based on Complete" SFC
parameter is set to "Operations" and you post multiple positive and
negative moves into inventory from a job which is for an actual costed
item, it is possible that the cost of each positive move (Job Finish)
will decrease and even go negative. Although there are variations, the
most common scenario which can result in this happening is the
following:
1) You enter a move to inventory while some operations are open.
2) You enter a negative move to pull the pieces back to the job.
3) One or more open operations are closed with actual cost less than planned.
4)
You enter another move which makes the job quantity complete equal to
the quantity complete at the operations which were closed between the
moves.
The higher the planned cost and lower the actual for these operations or the higher the percentage of the job's cost which was in the operations which were closed at the time of the first move, the more the cost of the subsequent moves will be lowered (possibly very negative). If a given job has many operations and you enter many positive moves each followed by a negative move and more transactions are posted and operations closed between the positive moves, the costs of each positive move may be reduced dramatically. Depending on the status of the job's operations at the time of each move in terms of planned vs actual cost, quantity complete at the operation, closed or open, etc., the cost of the moves may actually increase at some point.
If such a job is closed via the job transaction which is for the final move to inventory, the final move will be at a cost which results in the total cost moved into inventory for all pieces being equal to the total actual cost for the job. If the job is not closed as part of the final move but later closed manually, the final move may still be done at a very low or negative cost with a possibly large entry made to inventory adjustment to clear WIP when the close occurs.
Why it Happens
This happens because of the nature of
the algorithm which is used to calculate the move-to-stock cost when
the "Cost Based on Complete" flag is set to "Operations", and the job
is not being closed. In that scenario, the basic logic used is to
calculate a unit cost from each operation using the actual cost for
complete operations and planned cost for open operations. The
calculated unit costs for each operation are added up and the result is
the unit cost used for the move.
A key field used for these calculations is a WIP amount field which is maintained for each operation (jobroute.wip-amt). This field is increased anytime you issue materials tied to the operation or post setup, run or machine transactions against the operation. When you move pieces from the job to inventory, this field is then decreased by the cost pulled out of the operation (actual or planned) so that the same cost is not used for subsequent moves. So, at any point in time, that field holds the total actual cost posted against the operation minus any costs pulled out of the operation for a move to stock.
If the operation is complete at the time of a job finish, the system takes the actual cost from the operation by dividing the WIP amount by the quantity complete at the operation to arrive at a per unit actual cost for the operation. The WIP amount is then decreased by the (resulting unit cost * the quantity being moved into inventory). If the entire quantity completed at the operation is being moved into inventory, the WIP amount for the operation will then be zero. That is, all of the cost will be pulled from the operation.
If the operation is not complete at the time of the move, the system calculates the planned unit cost for the operation and decreases the operation WIP amount by that cost extended by the quantity being moved. If the actual costs posted aga.inst the operation are less than planned, the WIP amount will be driven negative, possibly very negative if little or no actual cost has been posted to the operation. The situation of the decreasing job finish costs can then occur if a negative move is posted to pull the parent item back to the job, the operation in question is closed with little additional costs posted against it and then the pieces are again moved into inventory.
Since the operation is closed at the time of the second move, the system will use the WIP Amount from the operation. In this scenario, the WIP amount will still be negative and the negative unit cost will be added to the unit costs of the other operations resulting in a lower move to stock cost for the second move. Basically, the system is backing out some of the costs it had used for the operation for the first move since it now knows the actual cost and it is lower than the planned. Since the planned cost is used for an open operation for each move to inventory, the WIP amount for an open operation can continue to go more and more negative if a quantity of the parent item is moved in and out of inventory repeatedly. They more times that occurs, the bigger the negative impact that operation's cost will have when it is finally closed before one of the moves to inventory.
Cost Flow for a Negative Move
While not a requirement
for the decreasing job finish costs to occur, it can be magnified if
some operations are closed at the time of the initial move.The size of
the move-to-stock cost decrease is impacted by the percentage of the
job's total cost that is contained in the closed operation's. This is
due to the way the system updates operation WIP amounts when a negative
move is entered. When you post a negative move transaction which moves
the parent item from inventory back to the job, it is pulled from
inventory at whatever cost is appropriate based on the item's cost
method.
However, rather than attempting to somehow spread this cost over all operations and increase each operation's WIP amount, it adds the entire amount to the last operation's WIP amount. The idea is that amount will be used for a subsequent move to stock when that operation is closed. Basically, the last operation is temporarily holding all of the cost used for the prior moves until it is closed via a job transaction which moves pieces to inventory.
However, if the last operation is not closed at the time of the next move, its planned cost will again be used which will contribute to the decreasing move-to-stock cost. The portion of the cost of the initial move which came form the closed operations will remain the last operation's WIP amount and not be used again until the last operation is closed as part of or before the last move to inventory. Or, if the last operation is not closed at the time of the final move, that cost will end up being written off to inventory adjustment when the job is closed.
So, if operation 10 had the bulk of the actual cost of a job due to having all of the materials tied to it and it was closed at the time of the initial move, all of its cost would be used for that move. If you then posted a negative move, all of the parent item's cost would go into the last operation's WIP amount and operation 10's would remain zero. If you then posted another positive move without closing the last operation, a unit cost of zero would be pulled from 10 and the planned would still be used for the last resulting in the move-to-stock cost being much lower for the second move.
Verifying the Move to Stock Cost
If you see the unit
cost for multiple job finish transactions decreasing for a specific
job, it can be very difficult to "manually" verify the costs due to the
number of variables involved. Using the Job Transaction by Job,
Material Transaction by Job and Job Detail Cost Status reports you
could review the transactions in the s.equence they occurred and try to
determine which operation's were closed at the time of each move. Using
those reports, you may be able determine the cost pulled from each
operation as well as what each operation's WIP amount would have been
after each move to inventory.
This can sometimes be accomplished if the job is processed in a somewhat straightforward manner. However, the more positive and negative moves which have been posted which move the parent in and out of inventory, the harder it becomes to track how each job finish cost was calculated. If operations are closed and reopened multiple times with additional costs being posted each time, materials or operations are added during the life of the job, operation rates are changed while the job is in process, etc. it can become impossible to manually recreate the calculation done by the system at the time of each move.
Summary
While seeing the costs of the positive moves
decline after negative moves may be disturbing, the information
presented here is the intended system design. That is, the system is
working properly.
Hopefully, processing a job in this fashion is
the exception rather than the rule. You should typically only see large
decreases in the costs if:
1) The job item is actual costed.
2) Your "Cost Based on Complete" parameter is set to "Operations".
3) You move pieces to inventory while some operations are open without closing the job.
4) You perform a negative move or run transaction to pull the pieces back to the job.
5) You close some of the operations which were open at the time of a previous move.
6)
The actual cost is less than the planned for those operations and/or
the majority of the job's actual cost was in operations which were
closed at the time of previous moves.
7) You move the pieces into inventory again without closing the last operation or the job.
While it is always a good idea to close jobs as part of the last transactions which moves pieces to inventory, the following example illustrates how critical it is when the job has been processed in this manner.
Example of the Job Finish Cost Decreasing
The
following simple example illustrates how this situation can unfold for
a job for 1 piece with 3 operations which have planned costs of:
10: $3000
20: $2000
30: $1000
1) Post transactions totalling $3500 to 10 and close it. Its Wip Amount will be 3500.
2) Post transactions totalling $300 against 20 do not close it. Its WIP amount will be 300.
4) Move 1 from 30 into inventory and do not close the operation or the job. It will be moved at $6500 (3500 + 2000 + 1000). The WIP amounts for each oepration will then be:
10: 0
20: -1700 (300 actual - 2000 planned pulled for move)
30: -1000 (planned pulled for move)
5) Move -1 from inventory back to 30. Since the entire cost at which the item is pulled from inventory is put into the last operation's WIP amount, all $6500 will be added to 30's WIP amount which will then be $5500.
6) Post $500 more against 20 and close it. Its WIP amount will then be -1200.
7) Move 1 from 40 into inventory. It will be moved at -$200 (0 + -1200 + 1000) and the WIP amounts will be the following.
10: 0
20: 0
30: 4500 (prev amt of 2500 - 1000 used for second move)
8) Move -1 from inventory back to 40. The WIP amount for 40 will then be 4300.
9) Post $1100 against 30 making its WIP amount $5400.
At this point, if you reviewed the Material Transactions by Job report for this job, you would see that there were two positive job finish transactions at 6500 and the second at -200. How the costing for this job turns out now depends totally on whether or not you elect to "Close Job" when you enter the final move from 30 into inventory.
If.you do close the job via the job transaction, the final move will be done at the $5400 WIP amount of operation 30 which matches the total actual cost posted against all operations (3500 + 800 + 1100). The item will be moved into inventory at $5400 and WIP will be cleared for the job with no adjusting entry required.
If you do not close the job when you move the piece, it will go into inventory at the $1000 planned cost of operation 30 and its WIP amount will be reduced to $4400. When you then close the job at a later date, the system will create transactions in the SF Dist journal clearing the $4400 out of WIP and into Inventory Adjustment.
