Re: Data Collection

[Lmittman@xxxxxxx]

Jeff:

In evaluating what solution is best for your client, it is important to know 
what their requirements are for data collection.  Is it for Time and 
Attendance, Labor Reporting, Inventory Transactions, Data Capture from 
Electronic Scales, etc.  As was mentioned by KLChilds@aol.com in a subsequent 
e-mail, there are several stand-alone data collection systems that could be 
interfaced into BPCS.  Several software packages were suggested in subsequent 
e-mails.

Typically, these systems are LAN-based and use a batch interface through 
CIMPath or they have some other batch mechanism to update BPCS.  These 
systems also require separate databases that must be maintained and 
synchronized with the BPCS data files.  Many people successfully use such an 
approach.

Another option that you might consider is to use a 5250 emulation approach 
with handheld and/or fixed terminal devices.  With this technique, you are 
using the data collection devices as AS/400 terminals that are directly 
connected to BPCS.  There are NO separate databases to maintain or 
synchronize.  In effect, you are performing the BPCS functions on a smaller 
screen.  The edits on real-time and the updates are online.

I have used this approach very successfully.  The technique revolves around 
taking the BPCS transaction entry programs (INV500, INV510, PUR550, etc.) and 
reformatting the screens so that the relevant screen fields display in the 
upper left portion of the screen.  For example, the Intermec handheld that 
was used had a screen size of 31 across with 16 lines.  We moved the key 
screen fields into this portion of the screen.

With this approach, only 1 version of each transaction entry program was 
required.  They are modified BPCS AS/400 RPG programs.  Those users on PC 
terminals see the same screen as the handheld users.

We also created additional programs for the handheld devices for such things 
as Material Status Inquiry (INV300).  These versions were much easier to use 
and only showed the key information that the people out on the floor required.

Another consideration is whether your client's objective is to use the data 
collection system to maintain inventory at a Bar Code/Pallet Label level.  
Again, some of the software packages will store this detailed data on the 
separate system and update BPCS at only a Lot/Location basis.  This does work 
fine.

Another technique within BPCS is to use the Container Level Inventory (using 
the YCI File).  The Container ID will be a Bar Code Number (up to 10 
characters) and BPCS will automatically assign it.  Inventory is maintained 
at this level.

For my client, we used this technique together with the TL Ashford software 
to print the actual Bar Code Labels.  We also connected the fixed terminals 
to electronic scales to capture weights that input directly into INV500.

You need to analyze your clients needs and objectives and compare them to the 
different approaches.  Also, the cost of a separate software package and the 
associated hardware should be compared to the cost of performing the mods to 
BPCS.  There are several other factors that need to be considered.

Please let me know if you have any questions about my comments.  I would be 
happy to discuss it further with you.

Thanks.

Les Mittman, CPIM
BSI Consulting, Inc.
Phone:  (847) 831-9388

(Specializing in BPCS implementation and support for 17 years)
+---
| 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
+---