Re: bar coding and portable devices -- BPCS-L

Chick

If I am not careful here, I will write far too much information, compared to what you are looking for.

Outside auditors give us only a couple hours warning before arrive and select 25-35 items, in which we did not know in advance which items they going to check, they do a physical count of those items and compare to what is in BPCS. We pass those inspections with 100% correct. Because of that, we are confident that our system for stock room inventory is valid.

Our current practice for inventory from stock room is for INV510 (move it from stock room to shop floor) either when it happens, or inventory, taken when clerk not there, recorded on a form for the clerk to enter later. For transactions that occur as the inventory moves, there is no need for a source document other than what is in BPCS. How do we know if human error occurred matching up all the activity with all the input needed? That's what cycle counting is for ... our interest is not if something got done twice or overlooked, our interest is in keeping our inventory accurate.

Stock consumed on shop floor is backflushing through JIT600.

We have a 400 terminal or PC located in the stock room receiving, and another in shipping ... those transactions occur where the inventory moves.

We are not now using bar coded input. I looked into it several times, none in recent years, so I expect technology has improved since I last looked into this. I also looked into SCAN DOCUMENTS input (e.g. customer change orders and blue prints) and was satisfied that there were several outfits that could do a great job for us, but ran into different kinds of objections than you did.

Alternatives that I looked at, basically took the wanded info, or the scanned info, and created a BPCS transaction ... conceptually think someone doing JIT600 or INV500 or ORD500 or combination of SFC100+BOM500 or ACR500/ACP500 but instead of a human being sitting at the keyboard doing all the input, the scanned interface generates the same data as the human would have keystroked. Thus the issue of verifying input, is pretty much the same as now, except that the input documents formatted quite a bit different, and the transcription error rate a millionth of what humans do. I was also looking into solutions that were other than the standard stuff pushed by the bar code companies ... on a 400 terminal you can get a bar code reader attached in addition to the keyboard, like a mouse on a PC combines input several ways. I wanted our labor tickets to contain bar code of what is already in BPCS on that order, so that the bar code reader would say "we processing info on a certain item order operation" which would call up a screen like SFC600/JIT600 prepopulated with some info we now key in, then the user key in the variable data.

This does not eliminate errors, because we still have plenty from problems with the data to be inputted, and bugs in BPCS.

We throw away 90% of our audit trails (delete from spool file without printing) after daily backup ... the purpose of our audit trails is not to verify input, but a safety measure in case something goes seriously wrong before the next backup. We are fortunate that our auditors could care less about original source documents. They are more interested in the accuracy of our overall process, which is real important in an industry where original source documents are like PCs, obsolete the moment you get them.

How we assure ourselves that the proper transactions are being made, is to * look at the transaction history ... ITH FLT and some that modifications have added (history of scrap by machine and mold) (history of changes to customer orders) ... and reports generated off of the transaction history * look at standard results in INV300 SFC300 etc. * look at reports - standard and our own variants, that give the overall picture * We also have some false proofs ... a customer order comes in, someone does ORD500, it issues a CO# which is written on the customer order paperwork ... at this point human error could accidentally cancel the order so BPCS never sees it ... we do not attach BPCS acknowledgement of order or change to the customer paperwork ... our proof is the customer order # (which sometimes not exist in BPCS) written on the source document associated with the customer * I don't seriously suspect that we have missing customer order input ... my suspicion is that production shop floor transactions are incomplete, and that production starts on items before the engineering is complete * I run various reports, mainly queries, that identify mismatches in our data base * There is correlation ... the Payroll system gives HOURS we paid for ... BPCS gives HOURS worked ... it never matches, but the percentages variance steady month after month * We not currently auditing scrap reporting. When we did, we used backflushed info on WHERE in the factory this scrap consumed times sample weight to total the weights by factory location with weekly report compared to weighing bins of scrap not yet exited building & they told me that the figures were good enough to assure production management that pretty much all scrap was being reported correctly. * That kind of approach means that certain kinds of errors cancel each other out. There are also some third party add-ons that can enhance quality assurance that transactions of specific interest to some people are as good as they hope.

this is a generic question not tied to BPCS or any specific portable
data entry device.

our current practice is to print work order forms, send them to the
stockroom to be pulled, they write the actual qty pulled and from what
location, then they forward one copy of the form to a data entry person
who sits and enters the transaction into INV500. i'd like to give the
stockroom staff a portable data entry terminal and have them enter the
transaction themselves. but i am running into interference from some
parties who say that if i did this there would be no audit trail or
verification of the transactions and quantities that were actually
entered.

so my question is: how do companies audit the various transactions that
are made using portable devices? how do you know that the proper
transactions are being made? how do you prove it to the accounting staff
and their legions of auditors that want to see source documents and
transaction audit trails?

chick doe
prime measurement systems
_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.

- 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/ Part time may get commission from some BPCS vendors for helping them ... I will now say in a post if the product I commenting on is also one potentially involved with this ... not that I have made anything from this yet.