>>Alex, a good quality laser scanner good to ~36" from the gun to the label is going to cost well over $500 - more in the $750-1000 range for something "industrial grade" (IOW, if you drop it once it is not going to be broken.) A long-distance laser is going to cost considerably more, and the size of tghe bar code is going to need to be larger.
>
>Hi Ed!
>
>I think the above would be overkill... I've looked at these racks. They usually have a big label (about 4" x 2") every 5 'hooks'. This label could be made a bit larger and have a preprinted barcode, or hang a little tablet off it vertically with the barcode.
>
>The user's hand gets quite close to this label when they place the garments on the rack, which means that they can scan the garments, then look for an empty space and as they hang the clothes, scan the rack's label.
>
>Since this label is preprinted and will not change, you can use any process you want to make it chemically inert (is that the right word?).
>

As long as it's pre-printed, then you can ensure that the chemicals won't cause the image to smudge; I wouldn't count on output from a DMP or inkjet printer to be stable around naptha, or even where the stock might get wet or steamed, causing the paper to deform as well as the inks to smudge or run. I've been in the barcoding realm for a long time (I've been doing warehousing, shipping, commercial labelling and publishing for better than 15 years, so I have been exposed to most of the issues for printing and reading barcodes, including various QA issues for implementing reliable barcode-driven document processing, and the single biggest issue with implementing barcoded entry is the consistency and readability of the barcode in the real workplace - I've had to deal with acceptance of app-generated barcodes by people like UPS and the US Snal (AKA the Post Awful) and the gamut of reading devices used for reading barcodes, their relative costs, stengths and environmental limitations like dust, surface reflection and normal wear and accumulated dirt buildups.

The single most important issue for barcode use is readability and reliability - as mentioned, other than DMPs using thin-film ribbons, lasers or thermal printers, really reliable barcode printing is difficult at best; it's worse when a wide range of humidity and inconsistent stock deform the lines for the barcode, ensuring that adequate 'quiet space' exists around the barcode to let the reader isolate the coded area, use of check-digits to help detect mis-reads, and the various standards for what the actual content of the barcoded data represents affects lots of decisions. The low-cost wands, while requiring physical contact with the label, are least subject to optical side-effects like reflection and refraction; CCD readers, while not requiring physical contact with the label, function at extremely short distances and are often less sensitive to warping of the stock carrying the barcode, and laser scanners are not all interchangable - they vary in the read distance, sensitivity to alignment, light frequency, and especially significant, durability - the optics are sensitive, and the shock mounting, internal alignment adjustments, sensitivity of the reader cover (cheap plastic lenses scratch easily as well as break, so it's the same issue as with people wearing glasses; scratch-resistant material costs more, shock mounts cost more, foam-lined housings hold up better than hard plastic cases, weight and balance affect the user's ability to accurately point the reader, and different types of laseremitters last for different times; many units allow you to replace functional assemblies for the reader, or are software configurable, or have intelligent wedge interfaces which identify their scans with a distinct scan code that can be processed in the Windows messaging loop by a language other than VFP that can intercept WIndows messages and redirect them (VB can do this with a bit of API coding and tghe AddressOf function, obvious C/C++ can handle this, and you can also use VBScript or JScript in conjunctions with the WSH Script compiler to build a COM object.)

Trying to do barcoding 'on the cheap' almost always delivers poor results; if the expected time and accuracy benefits of using barcoded input or producing barcode-readable complaint documents for your business partners doesn't justify the cost of using good hardware for handling them, barcoding may hinder acceptance of the software because the barcode interface appears to be nearly as error-prone as manual data entry. My rule of thumb for warehousing applications is that if we generate shipping labels for a carrier, the carrier must cetify that the barcoded labels are compliant with their readers; our in-house documents use paper with known reflectivity, and we use a polynomial-generated checkdigit to detect misreads of our internal documents, and have established our own standards for placement and isolation of barcodes on our documents. We use different readers for different apps; the shipping and packing/order checking stations have wedge-based short distance programmable code laser scanners (they run in the ~$700 range, and have to handle 2 of 5, 3 of 9, UPC-A, EAN-13 both with and without 3 and 5 digit extensions and PostCode barcode languages), and a CE-based portable scanner with an RF-Ethernet link for picking orders and doing inventory checking; the CE app is written in VB for CE, and talks to a VFP-based COM object that accepts a pick list number and downloads the quantity and part ids for the order to be picked, but does not directly update the VFP-based inventory (the invoice depletes inventory on hand to inventory committed, and the packing/check-in depletes inventory committed and assigns it to carton content for shipping, with the final inventory actually depleted when the carton is processed at the shipping station), and another app is used to scan warehouse location, individual product in the pick bins, and cartons in secondary storage that carry a barcode with a serial number, the part contained, and the quantity in the carton. A shipping station ships cartons packed and checked by 1-4 checking stations - shipping stations have Ascent, a 150lb capacity scales, a Monarch barcode printer and wedge laser scanner, modem and Internet link and a presense on the LAN, and in some cases a high end postage meter/mail sorter, and runs an average cost of $7000-$12000 depending on the exact hardware, and softtware providing carrier support. TYpical peak load is 400-600 packages/day. A checking station is a low-end reasonably current HP Pavilion with laser wedge, HP 2100 laser printer, and a presense on the LAN, running a packing and checking application written in VFP. People in the warehouse have a modified Journada CE box and laser scanner; download an order to pick and grab a pick sheet, a barcoded slip indicating a packing list, extracting the pick list for an invoice via a DCOM application, which downloads the bin location, quatity, title, and backup storage locations for the items they need to pick for an order; the vast majority of the stock is barcoded with an EAN-13 barcode on the back cover, and they fill bins with items on the pick list and place them on the shipping line. A checker takes a bin, retrieves the pick sheet to process, printing a packing sheet, packs one or more cartons generating a packing list per carton, and confirming that the order is correctly picked. The packed carton is put back on the shipping line, where it's scanned again to find the destination address and shipping method, generate the address label and any required carrier barcode or manifest documents, verified for weight and assigned the carrier tracking number, written back to the order processing system via ODBC to the VFP database.

We can detect short ships, mispicks, duplicate packings, identify exactly what the content of any given carton shipped contained, and link carrier tracking numbers to shipments so that we know the ship date, and assuming the carrier provides package delivery confirmation (at this point, everything we send out uses a shipping method with delivery confirmation, since the Post Awful added their own first class delivery confirmation last year) and most of the carriers we use (UPS/RPS/DHL/Airborne/FedEx/USPS) offer a web-based delivery tracking capability that we use to check on 'lost' shipments. Most of the year, one shipping station is active; peak periods (textbook shipment at the start of a semester, annual calendar shipments, etc.) we add a second shipping station and if necessary, rent a couple PCs to check a second shipping line; we sometimes will bring up a pick/check/shipping station when processing a single large order for a distributor, where that station acts as both packing and shipping processing) or when releasing a backorder, where one or two titles go into dozens of orders, so the stock is moved to the station, packed and shipped at the single point rather than picked separately an order at a time into a bin.

It's a significant investment in hardware and software, OTOH, the company handles $15-20M in book orders annually for something approaching 80 separate publishers sold under 4 separate imprints, with a warehouse staff of 4-9 people. Checking stations also serve as returns processing stations, taking in returns - the opposite process of packing, counting returned books, ensuring that the books returned are our product (currently, there are around 3,000 products we handle, and in some cases, a book is either non-returnable because it's out-of-print or the publisher no longer uses us for their distribution, so we can't accept the book, issue credit, etc, or a book belonging to someone else is sent to us) and are in returnable condition (some sales are non-returnable, or returned books are no longer sellable due to wear or improper storage.)

Getting to the point where the separation of pick, pack/check and shipment made sense took a good deal of time to idnetify. Making it economically feasible required that the business reach a critical volume of business where the automated functions paid for themselves required that we reached points where the manual processes that handled the process reached a point where eitherwe couldn't handle more work without expanding our staff or manual operations were too error-prone (the separation of shipping from packing/checking, and automation of order checking) drove the refactoring and automation of human- and paper-driven taks (we used to print packing lists which were carried into the warehouse, and inspection involved hand-counting books, with the obvious errors with identifying products or miscounting pieces, and the need to speed up inventory checking originally brought in the RF-LAN portable scanners, which we then had as a resource the bulk of the year when inventory is not being taken) and frustration over acceptance and processing speed drove the decision to use higher-end products (there's a huge difference in processing speed using a thermal printer capable of handling 6"/sec output vs 2"/sec output waiting on a shipping label, and the operators were far more willing to rely on barcode input when the barcode scanned reliably constantly, and when it failed, the error was detected immediately when the scanned input misread the content.

The use of barcoding throughout the operation was successful because the volume of work that could be accurately completed in a timely fashion by a reduced full time staff made sense. It would not make sense for a publishers with 10 titles, shipping 25 packages/week, using only one carrier for their shipping (especially now that many carriers provide single carrier shipping solutions to their customers for little or no charge!) If our product was not consistently barcoded, automated checking of orders would still need to be a manual process. If one in ten pick list labels were unreadable, we'd need printed pack lists to carry around in the warehouse. We implemented barcode automation in stages as it made sense - for WI, that meant barcoded packing lists that were manually checked at first, with the barcode used by Ascent to pick up shipping details and record the packed cartons shipped for an order. Next, automated returns processing that picked up things we weren't responsible for got done. Automated inventory counting came after that. Automated checking and packing followed. Electronic picking was the latest change, since we had the hardware and the capability was there and unused most of the time, and it gave an added, unseen benefit; with paper pick lists, the packer might decide to leave an order which made them run out to the secondary storage and pull cartons 'until later' - in a few cases, a few days later! It also was easy to place an order in need of priority processing on the top of the waiting orders to process without having a sales rep run out to the warehouse and hand it to someone - the system would queue up orders to process, and allows the priority of an order to be set above or below normal.

The biggest mistake is to do a half-hearted implementation, cutting cost corners without understanding the effect of the low-cost implementation. Ultimately, the developer ends up either taking the blame for a problem application, or ends up being the message bearer when achieving the end-user's expected goal is doable, but the cost suddenly becomes astronomical (been there; my worst week at WI was the week after the operations staff went and visited Prentice-Hall, watching their extremely slick order processing and shipping operation, which included automated box making, shrink-wrapped carton content and foam fill, per-carton picklist generation and automated conveyor-line shipping; I had to point out that each packing station had a $12,000 box folder/sealer, the foam fill cost $.08/box, but had to be bought in 55 gallon drum quantities, the automated camera-scanned conveyor version of Ascent ran about $50,00 per line, the laser printers cutting the invoice and label to size for each box in real time cost around $150,000...doable if you're Prentice Hall, not Weatherhill...