Committing to Accurate Barcodes: Because Royal Doulton Looks Weird Next to a Sippy Cup

Back to Blog Index
Share:

Committing to Accurate Barcodes: Because Royal Doulton Looks Weird Next to a Sippy Cup

Take a moment and think about the most exciting and joyful moment of your wedding. If you aren’t married, then try to imagine it.
What did you pick?

The expression of your love and faithfulness to your spouse? While that’s a sweet sentiment, you’re wrong.

Throwing a party for your family and friends? Barring the judgmental looks from Great-Aunt Ethel, sure, that’s fun. However, the price can sap away some of the enjoyment. So, no. Still wrong.

What about the cake? Surely something so simple, honest and delicious has to be the right answer. Nice try, but still no.

No, the most exciting and joyful moment of your entire wedding is setting up a wedding registry and walking around the store with a scanner. You get to pick all the things you like, decide in that moment you are absolutely going to host weekly candlelight suppers for 12 guests, and shoot laser beams out of a handheld device. The entire experience hinges on two very important principles: Commitment and Accuracy. If you and your spouse aren’t in love with the Royal Doulton with the hand-painted periwinkles, then you might be stuck with that pattern for a long time. Likewise, if you want twelve place settings and find out much later the store doesn’t quite have twelve of everything, then one of your guests is going to have an awkward dining experience. Similarly, a successful inventory barcode process heavily relies on commitment and accuracy to ensure a dependable and long-lasting implementation within your organization.

Commitment

On the surface, one might think that developing an inventory barcode process is pretty simple. Take some key data, translate it into a barcode or QR code, print it on a label and slap it on the box. Done. However, a barcode label is a commitment to a static set of parameters and a narrow interpretation of that data. Let’s take some typically requested fields and put them into context.

  • Logo: Putting the company logo or name on a product label is very common. However, think of the potential ramifications once that package leaves your dock. Do you have customers that demand private labelling? That logo is going to lead to some angry phone calls. Does the competition have access to your client’s facilities or inventory? Don’t make it easy for them to cross-reference your product.
  • Space: Once you have committed to a certain label size, make sure all the fields are tested. If one line on the label can only fit 45 characters but the form field has a 60-character limit, you risk wrapping to the next line and most barcode scanners cannot read that information. Even worse, the extra characters may get cut-off entirely leaving incomplete data and a non-readable barcode.
  • Description: This is a helpful field. While an item number means something to procurement, it might be useless to a warehouse worker. The description should very clearly indicate what the item is. That said, does it really need a barcode? Perhaps that extra space could be utilized elsewhere.
  • Date: A date is good, especially for items with a shelf-life. Which date do we use? Purchase date? Receipt date? Label print date? This should be clearly indicated on the label. Remember, we want to leave as little open to interpretation as possible. Alternatively, consider relying on batch and/or serial numbers, as that data can be easily traced to the originating documents and journals.
  • Quantity: This is commonly requested and very tricky. Let’s assume we’re receiving one box of twelve tubes of sealant. As long as we always commit an entire box in our sales or production process, there’s no issue. However, as soon as we remove one tube from that box, our label is incorrect and that can lead to serious inventory issues and the segue to our next topic.

Accuracy

Simply put, bad data is asking for trouble. Printing a barcode and placing it on a box is capturing a moment in time. Once any of the variables change, the label is no longer accurate. If the label is inaccurate, then it’s only a matter of time before your physical inventory no longer matches your database inventory.

  • Timing: When are labels reprinted? Assuming the original label is printed upon product receipt, when, if ever, is an updated label generated? If we remove certain fields such as quantity or date, we can avoid bad reporting.
  • Reprint Functionality: If a label is to be reprinted, what is the process? A warehouse worker may think they are being helpful by reprinting a missing label. However, if they assume the serial or item number, we may have a serious problem. There needs to be a safeguard in the business process or at the label generation point to ensure the correct data is printed.
  • Warehouse Dimensions: While it may seem like a good idea to print the item’s location at receipt, that data can become problematic after the fact. Let’s say the inventory was received into Bin 1 but was moved via transfer journal to Bin 2 for space optimization. Without reprinting the label, a worker may think he found an item in the wrong location and move it back.
  • Special Characters: Ampersands, slashes and hyphens are great for shortening and delineating descriptions but they can wreak havoc on a barcode. If the scanner cannot read special characters, then have them removed from the barcode programmatically or consider reformatting the form field.

When developing a barcode label, the most important thing to remember is that data is dynamic and labels are static. As managers and consultants, our goal is to make a user’s job as easy and foolproof as possible. Labels can help, but they can hinder as well. Inaccurate inventory counts, loose reprint procedures and poor formatting can lead to questions which then lead to assumptions and inefficiencies. A label should provide fixed information which will help users find the dynamic information.

Matthew Newcomb

Author: Matthew Newcomb

Solution Consultant

Follow: