RE: JIT620 SFC620 RE: BPCS-L Digest, Vol 1, Issue 703 -- BPCS-L

The biggest single savings for us was the discovery of the TEAM SCREEN, which you get to by leaving the employee clock # not filled out on the main entry screen.

Previously we did not know about the TEAM SCREEN so that when there was labor reporting on some operation that had say 10 workers working in a crew, we divided the quantity up by the 10 workers (easy for 10, not so fast when odd numbers like prime numbers) and credited each with a simulated labor reporting - their hours, their faction of the time. Now with the TEAM SCREEN we are able to use the CREW file, which we have modified so that efficiencies are distributed to reports automatically.

The TEAM SCREEN meant no more dividing up of quantities, and the total volume of keying reduced approximately by the size of each team or crew. And of course that was in addition to redesigning the input screens. We added a command ... if there are a string of labor tickets with work done by same clock #, certain info duplicated from one screen to the next. Fields that looking for some data already in the shop orders, we defaulted to that, and gave the option of all numeric keypad entry where previously alpha characters needed.

If you doing a string of tickets of particular kind ... machine time for example, take a command and get screen optimized for that kind of input, with fields not relevant to that kind of input blocked off, so users not have to cursor past them, and new users not have to puzzle over what this or that is for.

Our labor tickets are picked up during the day and entered in clerical batches by an office staff whose working hours are staggered relative to the factory personnel. This way, everything that is done by first shift factory is entered to BPCS that same day's office staff ... all production, all inventory transactions, all shipments, all billing. Our second and third shifts are fractions of the size of first shift. I run some reports to capture any odd ball stuff that did not reach satisfactory conclusion that day. Inventory removed from stock room when stock room clerk not on duty, goes on a form on their desk, so they enter details first thing next morning. - Al Macintyre http://www.ryze.com/go/Al9Mac Find BPCS Documentation Suppliers http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/

We did the as Al Mac...not 1/10th the keystrokes, but cut down entry keying
and errors by a LOT.  Our reporting is done next day.

-----Original Message-----
From: Al Mac

We also 405 CD
I have modified some of this, and it is very complicated.
One part that might interest you is that we rejiggered the input screens so
that only 1/2 as many keystrokes needed to do the same input, and in the
process of researching all the screens available, found how to do the same
input in 1/10 the keystrokes.
We also interjected mods to intercept some common transcription errors.
JIT610/SFC610 is no good for our error checking, because what we need is
for someone who not understand 100% of SFC/JIT to verify reasonableness of
data entry, so for that purpose we have a Query/400 over the FLT member
WORK, selecting on basis of facility folks who did which batch input.
We use one JOBQ just for this stuff because of some problems when multiple
people updating same files at same time.

I suggest you check BPCS archives on BAR CODING.
There are a lot of solutions in which the data from labor reporting can go
right into BPCS without actually using the JIT600/SFC600 screens.

>Hello All,
>
>We are on BPCS 4.05CD. Does anyone have experience doing and automated call
>to JIT620/SFC620? We want to post production reporting as close to it's
>occurence as possible.
>
>TIA,
>
>Wally M Carr
>Business Systems Analyst
>The Bergquist Company
>952.820.6516
>WallyC@xxxxxxxxxxxxxxxxxxxx

-
Al Macintyre