Re: FOD Costs

Al Mac on AS/400 mixed mode with 405 CD Rel 2 & a ton of Y2K BMRs

Bottom Line Lesson for other folks using SFC600 or JIT600 for factory work 
centers that have a mixture of machine & labor rates ... try to incorrectly 
enter labor on an operation that is routed as Human Run Time in which you 
report it as if it is M Machine Time ... BPCS should not accept this as valid 
input, but I am betting that it will.  This has a major negative effect on 
the accuracy of your actual costs.

I share most of my BPCS_L posts with co-workers & also forward relevant stuff 
that I see here that applies to us.  My inquiry about FOD costs led to some 
interesting information from some co-workers & subsequently other information 
of possible interest to other folks on BPCS_L.

Buckets 3 & 4 are currently zero in all of our FOD records

> From: Jerry Cooper
>  
>  CST1  is  Labor Cost computed multiplying the Hours Posted by the Standard 
> Labor rate from the Employee Record Not the Workcenter.  So this in effect 
> becomes Actual Labor Costs for that operation.

Al checked out CEM file & found that 99% of our records are populated by a 
Labor Rate & has an inquiry into Accounting regarding whether this is kept 
current with pay raises & should it reflect employer costs after applying 
taxes paid by employer, along with sharing list of employees who have no 
labor rate & is that Kosher?

How is this calculated for Machine Time?.

>  CST2 is Overhead Cost computed by multiplying CST1 by the Overhead rate 
from 
> the Workcenter File.  So this in effect becomes Actual Overhead Cost for 
that 
> operation.
>  
>  Note: On the order that I checked out, labor was also misreported as 
machine 
> time and NO costs were calculated for those hours because the workcenter is 
> set up for labor not machine time.  This is an example of what I was saying 
> about the need for ACCURATE reporting, because this type of an error makes 
it 
> look like we're doing fine, but in reality are NOT.

Well Al believes that in THIS scenario it is a combination of accuracy in 
data entry, and why can't the 600 program take the fact of R or M user input 
& just get the right code from work center & plug it in without harrassing 
the data entry person?

>  Remind me, is there a way to block this kind of error?

Well Al looked at the source code for SFC600 JIT600 & found something 
ISNT THAT SPECIAL as they say on Saturday Nite Live

SSA had made BMR 4071 to fix a problem presumably reported by some customer 
who did not understand machine vs. labor & whoever it got reported to at SSA 
did not understand it either.

Machine Load codes should come with valid machine rates & 0 labor rates
Labor Load codes should come with valid labor rates & 0 machine rates
Hours should be reported in concert with the type of work center loading.
If reported against the wrong kind, then there should be an error message to 
block input of the wrong kind.
However, someone complained about the error message & SSA "fixed" this so now 
we can enter factory hours to the wrong type which results in those hours 
being ignored in actual costs.
Fortunately SSA documented the error of their ways & this is only one line of 
code to undo.

> From: Brenda Schultz 
> Work centers designated as Machine Time DO NOT ALLOW the entry of 
> labor type R, but 
> Work centers designated as Human Run Time DO ALLOW the entry of 
> Labor Type M for Machine time.  
> Can this be corrected for both programs JIT600 and SFC600?.

Yes, Al fixed that last nite in our test version & it is ready for test 
verification.  
Yes, SSA wrote the program correctly in the first place, then only undid half 
of this.

> From: Jerry Cooper
> I am surprised that you or I or at least someone has not seen this before 
now.

>  I created a query to identify any orders that were mis-keyed using the 
> incorrect Labor Type (M versus R)
>  
>  Resulting in:
>  
>  LAW        68.6 hours  24 orders
>  GWD        14.8 hours  8 orders
>  EVA         0 hours  0 orders
>  
>  In contrast NO database had errors in reporting for Cutting.
(Cutting Dept is one that most often has problems with labor reporting 
accuracy)

Al got clarification from Jerry that this represented just the last ONE WEEK 
of data misposting due to this one problem.  I suggested that the query be 
adjusted to include order operation status so it would be obvious for which 
ones it was not too late to fix within the order reporting.  And our internal 
discussion continues.

Al Macintyre  ©¿©
MIS Manager Green Screen Programmer & Computer Janitor of BPCS 405 CD Rel-02 
running on AS/400 V4R3 http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---