Re: SFC600 question -- BPCS-L

My suggestion to Jim to get the maximum information with the minimum modification hassle effort. in the job stream of SFC620/JIT620 copy contents of FLT.WORK to some other file before BPCS moves it into FLT.FLT because at that point you lose the user/WS identification, as far as FLT is concerned. What you should be copying is ONLY the contents of FLT.WORK that corresponds to the user/WS that is running the current iteration of SFC620/JIT620 Be very careful about file access design to avoid running into hassles if multi-threading is going on.

We track by employee because we are very interested in performance and accuracy. Employee raises are tied to performance.

There are various merit awards ... like the factory department with consistently the best quality performance reporting etc. over a time period ... the company springs for PIZZA or other meal for them and a longer lunch period, with the company paying them the extra time they were given to enjoy the meal. We find out which department merits this because we are tracking performance by employee, and keeping overall score by department.

Employees who cannot fix their performance are replaced (after counsel opportunities to address the problem). When there is excessive scrap, defective parts, quality problems, we want to know who did it (perhaps the human is in need of additional training), what equipment was used (perhaps the machine is in need of maintenance) Employees with more seniority are paid more, and by using employee # (CEM file) we can capture true costs of making the parts.

We correlate the work that was reported as being done and the payroll hours by employee. The same clock # is used on both payroll and labor reporting. Thus we are able to correlate costs by department and what that department accomplished.

The numbers do not match exactly because we not bother to tell BPCS about potty breaks, other breaks, cleanup, etc. but there are predictable percentages to correlate payroll with BPCS labor time, and BPCS labor to standards.

Query/400 reports off of labor history can show us if an employee is deliberately misreporting what they did to make their performance look better than it really is, or under reporting scrap (e.g. we have part weight in the item master and bins where the scrap accumulates ... BPCS captures enough info on where the scrap allegedly happened for us to get at the weight of the scrap at that location and compare it to the weight of what went into the scrap bin, and see where it is being correctly reported, and where not.)

SFC600 updates ITH when JIT600 is used instead.
We using 405 CD and get
PR Production Receipts
CI Component Issued
RJ Rejects (scrap)

I believe ITH only tracks inventory transactions(issues, receipts for
instance) to a SO, where as SFC600 is tracking the time spent on an
operation for a SO.SFC600 does not update ITH. I know the correct way would
be to require an Emp # when reporting time but then dont want to do this at
this time.  This is what I am suggesting they do.


----- Original Message -----
From: <Lisa.Abney@xxxxxxxxxxxxxxxxx>

> Jim ...
>
> Can't you use the user and workstation ID's from the ITH file, for I, CI,
> etc., transactions?  This file also carries shop order number, operation
> number, and work center ... you ought to be able to link from the FLT or
> FOD file to get this info.
>
>
>
>
>                       "Jim Mergen"
>                       <jmergen@pctcnet

>
> Hello,
>
> I have a client running 4.05 . When they they post to a Shop Order(SFC600)
> the users all use '1' (Generic Emp) for the Emp/Line/Clock number. Now
they
> would like to know user/workstation of any operation posted , but without
> requiring the users to enter a unigue Emp number.
>
> Is there anywhere in BPCS that captures User/WSID when a user posts to a
> Shop Order? Looking at ITH I see issues and reciepts. FLT(if there was
> labor posted) shows the Emp#, but again they all use #1. FOD shows SO#,
Op#
> , Qty but no WSID or user.
>
> I was looking at creating a work file and each time they post I would
> capture this info, but wanted to make sure I am not overlooking something.
>
> Thanks