The notion that you have no problems with your labor processing ... I wish 
I could live in such a world.  It would simplify things no end.
Did you have any scrap?
Can you have two or more orders open on same item at same time?
What we have found is that if quantity mfg + quantity scrapped exceeds 
quantity to be mfg on some item, BPCS ASSUMES that we posted some labor 
ticket to the wrong order and it hunts around for some other order to post 
it to, and usually screws it up.
I suggest you check the DATES and TIMES of labor posting (show up in ITH 
which you can match with FLT on labor ticket # if you using JIT600 input)
If operations 100 200 300 say
and labor for operation 100 not posted timely manner, but operation 200 
reported for some quantity, BPCS ASSUMES that operation 100 MUST have been 
made, so it invents a posting to operation 100 to record that quantity, 
without all the details associated with our correct reporting,
then later the labor ticket is posted (it was delayed because handwriting 
needed deciphering) and you have some inaccuracy in operation 100 because 
of BPCS assumptions.
Bottom Line - if later operation posted before earlier operation, you can 
have accuracy problems.
I suggest you look at CST270, which we modified to eliminate massive 
categories of garbage, then later changed our corporate rules so that one 
of the categories (operation 999 for outside operations) no longer was 
garbage in CST270 terms, but we not yet back modified that.
Does JIT620 SFC620 ever hang up and have to be taken to a conclusion, and 
are you happy with the recovery options, practices?  We have query list FLT 
member WORK to locate batches not yet taken to conclusion properly.
Check FRT routings if routed correctly for the actual reporting.
Compare FOD to see if shop order maintenance has gone on.
Check that the reporting is consistent with how the part is routed.
There are a BUNCH of different rates that might apply to any given labor 
posting.
I have a hard time figuring out sometimes which is the right one.
It can be price of clock number person or machine, and we use teams of persons.
It can be something in work center master.
Did you know that CST900 gets the cost of component materials from CMF AT 
THE TIME that the shop order posting a closed item is actually processed by 
CST900?
What this means is ... let's suppose your item #s for children of a parent 
part consist of parent item number dash something else, and let's suppose 
you release shop orders in item # sequence.
This means shop order # for parent comes before shop order # for children 
of that parent.
If you close purge them all together, this means CST900 processes parent 
before children of that parent.  This means cost for parent is based on 
PREVIOUS time you made the children.
Depending on how you do cost averaging, and depending on lumpiness of shop 
floor performance, this can put a lot of inaccuracies into your production 
costs.
Hi,
      I am trying to do some reconciliation of shop orders and I have found
something disturbing on some shop orders. If I take all labor in FLT that
is for the shop order/operation and extend by the rate, I come up with
$116.82. When I look at FOD for the operation, it only has $98.9422.  It
doesn't appear to be a record or combination of records that is missing. In
one case, there was only two labor records, and neither is the difference
amount.
       Has anyone run across this before? Any ideas on what might be wrong?
As far as I know, there has been no problems with our labor processing.
Thanks for any ideas.
<===================================================>
Terri Harteau
****************
"There's no point in being grown up if you can't be childish sometimes."
- Dr. Who
****************
-
Al Macintyre
BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
See Al at http://www.ryze.com/go/Al9Mac
Emergency notification (homeland, weather, etc.) http://www.emergencyemail.org/
Find BPCS Documentation Suppliers 
http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
 
As an Amazon Associate we earn from qualifying purchases.
	
 
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.