RE: Labor Cost Application to G/L -- BPCS-L

Our system is actually much simpler - again, on 4.05CD.

For most of our items we have a single-level bill...buy one, make one.

Our solution has been to close shop orders manually, then each night copy
those closed shop orders to a file FSOHST (and FODHST).

At month-end, we have a report that's sort of mish-mash of standard costs
vs. actuals.  In other words, material is accounted for by the actual
quantity issued times the standard cost of the material.  Labor is actual
hours times the actual labor rate, with overhead being the multiple of that
number.

The 2 reports that are used are: Shop Orders Closed during the desired
period and Current Open Shop Orders.  The reports show 'actual' costs vs.
standard costs and the variances.  The accountants than shuffle that number
against the receipts to finished goods (at standard cost).

Kind of an accounting nightmare.

-----Original Message-----
From: bpcs-l-admin@midrange.com [mailto:bpcs-l-admin@midrange.com]On
Behalf Of Al Mac
Sent: Thursday, August 01, 2002 4:09 PM
To: bpcs-l@midrange.com
Subject: RE: Labor Cost Application to G/L


We are on 405 CD and have done some modifications to help try to track this.

A big grievance from a lot of our people seems to be that when some cost
seems to be whacko, drilling down to how it got that way is rocket science
beyond a lot of us.

The big accounting grievance seems to be that the total value of our WIP is
out of balance each month, we fix it, then next end month it is out of
balance in the opposite direction the next month.

We have added reports to show the value of inventory on-hand and in-WIP,
which accounting uses to make GL adjustments with each end month, to
reflect divergence between our standard tracking and what has actually
happened.

The big engineering grievance seems to be that the timing of actual cost
updates from factory production is not in synchronization with BOM
consumption of WIP materials.  We have had some discussions about what
kinds of modifications needed to fix this, and not yet come up with a
satisfactory solution.

CST900 processes closed shop orders in SEQUENCE of shop orders being purged.
As each order is completed, BPCS updates the cost of the item that was
manufactured.
When CST900 accesses materials used in an order, to get the cost of those
materials, it uses the latest actual cost that is in the system.

So let's suppose we have an item # 123 which uses sub-assemblies 123A 123B
123C etc. and each of them uses similar numbering tacked on the end for
lower components.  When we release cluster of shop orders, they are in item
# sequence.  When we purge the completed work, they in same sequence.

When it purges order for 123 it uses the actual cost of the sub-assemblies
NOT from this production run, but from the previous production run.  Now it
updates 123A AFTER the old cost was used by 123, same deal.  Now this would
not be a big problem if it costs about the same to make parts each and
every time, but we often have big efficient runs alternating with small
correction runs, like to replace scrap or do repairs.

The way CST900 functions, the big efficient low cost run is booked using
the high unit cost of the last small run, and the small expensive run is
booked at the low cost of the efficient run.

As we do production, there are inventory transactions going to GL that
reflect the value of the material as of the time the production was
reported, which as we have seen can be seriously distorted.  Later when we
catch up on purging shop orders with cost info that was not in those
transactions at the time they got posted, there is a cost correction, that
GL never knew about.

Unbeaten Path International has a software plug in to transfer the impact
of that cost correction to GL, so that as of end month, GL is up to date
with all cost corrections between time of inventory actions posted there
and end month.  We do not happen to have that, so I cannot comment on how
effective it is.

Immediately before CST900 we replace a Query/400 work file that has info
from FSO orders coded for purge, and also add some data on costs before the
purge.  Immediately after CST900 we replace another Query/400 work file
with similar info, using the item #s involved in the first work
file.  Various Query/400 reports can then show us how our actual costs
changed because of this latest purge.


Al Macintyre (macwheel99@sigecom.net via Eudora)
http://radio.weblogs.com/0107846/

Driver Alert: Back to school Kids imminent (Aug 12 in Evansville
Indiana).  This means after a lull of months without bunches of kids
careless about crossing the street, we're going to have that again, so be
on your toes, extra watch out.

_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/bpcs-l
or email: BPCS-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.