For our clients who really want to drive productivity, control, and the ability to "Do More with Less", Rubicon can support these needs with through bar-coding. This can be done at varying levels of integration and complexity.

In the simple, all you need to do is produce barcoded labels, usually to meet a customer's requirements. Typically, this involves little more than purchasing one or more special purpose barcode printers and laying out the appropriate label formats. Rubicon has developed tools to allow a great deal of flexibility in the production of labels, both in terms of formats, and the use of various types and even different brands of label printers. This kind of barcode processing can be implemented with very little effort or expense beyond that of creating the label formats and purchasing the printers.

Picture having a way to measure your warehouse investment, along with the tools to increase your productivity and eliminate the need for generating those "late reports". How would you sleep at night knowing that the bottlenecks are gone, and that you are known by your customers as being proactive versus always being in "catch up" mode? Your warehouse no longer needs to be a deep, dark, black hole.

To achieve this requires a more sophisticated use of barcoding to provide complete inventory management and control. Rubicon's implementation of barcoding is at this level. It is completely integrated into existing programs, systems and procedures. This provides you with a substantial and significant benefit over stand-alone barcoding systems: Data is entered and validated in real-time against the live data. There is no duplication of entry and, equally important, no duplication of data files.

The remainder of this document describes these Rubicon barcoding facilities.

There were several goals and objectives in the design of the barcoding facility:

• real-time updating of inventory information -- allows users throughout the company to see completely accurate and up-to-date inventory information
• on-line verification of inventory transactions -- checks data as the transaction is happening; for example, verifies that the product being picked is actually on the order being picked
• capture status information for customer service -- can show that lines 1 and 4 are completed, line 3 is in cutting, and line 2 is on a fork lift heading for shipping
• maximize use of already captured information -- once the order is complete, it can be billed with a single keystroke
• minimize changes to existing programs and procedures -- the facility should not require a lot of retraining, nor require that every location use barcoding
• emphasize consistency -- users should always do things the same way, without having worry about exceptions, special cases, etc.
• deal with "real world" environments -- the programming should be robust enough to deal with equipment failures, "hot rush" picks, etc.

The goals and objectives Rubicon had for the barcoding facility necessitate a real-time connection of the barcode equipment to the main system. Contemporary barcode scanners use the same WiFi connections used by laptops and mobile devices.

Each reader appears to the system as a normal user terminal (albeit one with a very small screen). This is accomplished through terminal emulation software running on the reader.

Costs of equipment have dropped dramatically as WiFi has become a standard environment in businesses and homes. In a small area, an inexpensive WiFi access point ($50 or so) is more than enough. For larger areas, use commercial grade access points - they are better at "handing off" as you move between access points. These are in the $3-400 range. Currently we recommend the M7220 scanner from AML - depending on configuration, these are $1400-$1900 each.

While barcode processing includes only a few completely new programs, a number of other programs, particularly in billing, cycle counting, and physical inventory, work in different ways when using barcoding. These facilities are described in the following section. In addition to the system programs, there is the formatting of various forms of barcode labels, setting up printers, and the usual customization that is always part of a project of this kind. After review of the specific requirements, we can give you a good idea of how much this will cost.

Inventory: There are two types of inventory items in the standard Rubicon environment. The first type are LRB items -- those that are tracked to the lot or reel level. An LRB represents a uniquely identified, discrete chunk of inventory of a particular product, and is an additional level of inventory information beyond knowing the total quantity of the product on hand in the warehouse or location. The most common example is wire, where we need to know the individual lengths in addition to the total quantity. By contrast, non-LRB items (e.g., connectors, patch panels, tools, hardware, etc.) that don't need to be tracked in that detail.

Any product (whether LRB or not) may be in multiple places in the warehouse. The locator facilities of Rubicon's system allow for tracking the specific locations where products are stored. Since an LRB is a unique physical entity, it can only be in one location within the warehouse at any given time (of course other LRBs for the same product may be in other locations).

Again, it should be emphasized that all of this is part of the standard Rubicon system. The only difference in the barcoding environment is the way we identify non-LRB parts on barcode labels. An LRB number is eight characters long, where an item number can be up to twenty, so it is easier to scan and print LRB numbers than item numbers. For LRB items, the LRB number also uniquely identifies the product, since an LRB can only be associated with one inventory item. For non-LRB parts, we create a "dummy" LRB, which is used solely to translate between an eight character number and the item number -- it is essentially an alias for the item number. Doing this also makes processing more consistent: Users always scan what appears to be an LRB number, whether or not the part is an LRB part -- they don't have to decide what kind of part it is. (For the remainder of this document, we will simply refer to "scanning the LRB"; in the case of non-LRB items, this will, in fact, be scanning the alias.)

In some instances, Rubicon users associate an LRB with something other than a single "chunk" of inventory. The most common example is to put a single LRB on a pallet that has, for example, fifty 1,000 foot spools of a product. Taking two spools is reported to the system as "cutting" 2,000 feet from the 50,000 feet associated with the LRB. This requires a bit of special processing in the barcode environment. Normally, a cut requires taking the reel to a cutting area, cutting the required length, and returning the reel to inventory.

Labels: Associated with an item is a label type code that indicates the style of label to be produced for the item. The style determines both size and format. Some items do not get labels at all -- bulk items (e.g., screws) may have a label on the container or shelf.

Each barcode on the label includes an alpha prefix that identifies the data it represents: L for LRB numbers, C for customer orders, B for bin locations, P for purchase orders, etc. This allows the programs to determine what kind of data has been read, and thereby determine that all the necessary data is canned in the correct sequence.

We have included some sample barcode labels as illustrations of what can be done. Rubicon's approach to barcode label printing is unique in that it allows maximum flexibility not only in label format but also in barcode printers and equipment. You can have any mix of printers and formats.

Transactions: The barcode processing integrated into Rubicon's system allows for processing the following warehouse / inventory activities:

• receiving
• put away
• relocation
• picking
• cutting
• rewind
• shipment
• cycle counting
• physical inventory

More detail on these transactions is presented below

Everything is a move: As a unifying principal to the design, we have adopted the approach that "everything is a move", that is, every activity in the warehouse is processed as a location to location transfer of inventory. Even pick up and put down are moves, since each user is identified as a "location". Some of those locations have special meaning, and result in special processing: The system allows certain locations to be defined as goal seeking, that have special meaning in terms of how the reel is processed.

When an order picker is processing an order, a number of moves take place. When, say, a reel is picked up for the order, it becomes associated with that order, and is moved from the shelf location to the "location" associated with the picker. When the picker puts the reel down in another location, it is a move from the picker "location" to the new location. As an example of the special processing associated with some locations, if the picker puts the reel down in the shipping or cutting locations, the reel is moved, but still remains associated with the order for which it was picked. If the new location is not one of these special locations, the system assumes the user was just relocating the reel (perhaps to get to the desired reel), records the location change, and removes the reel from the order.

Basic scan activity: Many activities will require multiple moves. A cutting situation would involve moving the reel from the shelf to the picker, and from the picker to cutting. After cutting, the original "parent" reel will be moved from cutting to a picker, and from the picker to a shelf. The "child" reels will be moved from cutting to shipping for staging with the rest of the order. While this may seem complicated, barcode scanning makes it easy, and the consistency improves accuracy and minimizes errors.

The user always does the same thing: Scan the inventory, scan the location, and for non-LRB parts, enter the quantity. There are no exceptions, no special operations, no mistakes due to incorrect procedures. The procedure is the same regardless of transaction type.

Several other factors also add to the ease of use. Because the barcodes are prefixed by type, the user can scan them in any sequence. Since the system knows what the user is "carrying" (i.e., what is in the user "location"), it can automatically determine whether the material is being picked up or put down. . And since all transactions are treated as moves, the user doesn't have to identify the activity in advance (and, more importantly, can't enter the wrong type). A special "mass put down" allows the user to put everything currently being carried in one transaction, such as delivering a number of items to shipping. Finally, the terminal user has several inquiries and displays available, including all of the items on the current picking ticket, with quantities picked so far, and a complete list of LRBs that are currently in the user's "location".

Transaction detail: The following sections provide some additional detail about specific warehouse activities

Receiving: Receiving is done at a terminal in the warehouse. The items are put into a RECEIPTS location. When receipt entry is completed, barcode labels associated with the items are produced. The put away transaction is simply a relocation from RECEIPTS. When an item is picked up from receiving, the user is notified through the terminal of the primary stocking location for the item. The actual location of the material is updated by scanning the LRB and location as the item is shelved.

Relocation: When material is moved in the warehouse, the user scans the "from" location, and the LRB. When the material is shelved, the user scans the LRB and the new location.

Picking: Picking documents are produced for the order. Most Rubicon clients produce a traditional picking list with barcoded order information added; some print labels identifying the items to be picked. As the ticket is produced, records are created in the picking ticket file identifying the items on the ticket, and the quantities to be shipped.

The picker scans the pick document to identify the order being processed. At each pick, the location and LRB are scanned; the program verifies that the item is on the order being processed. If the item is a non-LRB order, the user is also prompted to enter the quantity being taken. Note that there may be multiple picks for an item.

Non-LRB items will typically go directly to the shipping staging area (since they are usually picked in the correct quantities). LRB items may proceed directly to shipping (if the entire reel is being shipped), or to the cutting location.

In the case of a cut item, additional processing is necessary. When the cutting operator begins processing the reel, he will scan the order and reel number. Again, there is verification that the product is, in fact, associated with the order; the cuts to be made, along with any other comments about the line are displayed to the cutter. As the cuts are made, new reels are created, and LRB numbers are assigned and labels are created for the new child reels. Many Rubicon clients also print a new label parent reel, rather than hand writing the transaction and remaining quantity. All of the reels are shown as being in the cutting location.

At this point, the parent reel (if not empty) can be moved back to the shelf, and the newly created reel(s) can be moved from the cutting location to the shipment staging area.

Rewind / re-reel: Typically this occurs as part of the cutting process -- the quantity left is such that it can be moved to a smaller reel. If the material is also counted and a variance is found, the program automatically generates a shrink adjustment for the difference. New labels are also produced.

Shipment: Eventually, all the material associated with the order has been moved to the shipment staging area. Using a special version of the Shipment Entry program, the shipper performs the following steps:

1. The shipper scans or keys in the picking ticket number.
2. The program determines if all items on the ticket have been picked and moved to the shipping location. If not, the shipper is notified that the order is not complete, and no further processing can be done.
3. The shipper enters shipping information, including carrier, weight, PRO number, and pieces.
4. The system prints a complete packing slip containing order information, the material being shipped, the associated reel numbers, etc.
5. The shipper verifies with the packing slip that all material is present and accounted for.
6. The shipper enters "B" to bill the order. Inventory is updated and an invoice is created.

Cycle counting / physical inventory: Scanning tags replaces the manual entry of information. Both cycle counting and physical inventory are based on counting locations rather than counting groups of items or all items. Automatic adjustments are made for items within user specified tolerances. A complete set of audit and adjustment reports are produced, as in the current system.