Automated Store Replenishment – Volume XXV

We have talked about 12 and 13-digit UPCs, but before leaving the issue behind, there is one other I would like to tell you about—the 8-digit UPC. This UPC is nothing more than a 12-digit UPC converted to a compact size to fix neatly on smaller items. Using our previous example, a Snickers UPC can be represented in one of two ways; as ‘040000001027’ or ‘04010207’. Both UPCs identify the same product and both are valid.

In our system, we found it more convenient to store only 12-digit UPCs, as it would be wasteful and unnecessary to have two UPCs for each item. Therefore, when encountered by our system, the system automatically converts 8-digits to 12-digits. All scanners can be programmed to perform this conversion as well.

Having a common repository of UPCs gives us the ability to share this information with every company who uses our system. Being on the Cloud, when one of our customers encounters a new UPC, it immediately becomes available to everyone else using the system. And since there is no global UPC database on the Internet that is trustworthy, having a master list that everyone can share saves everybody time and money. Our hope is to convince manufacturers to send us new UPCs as they are created.  

I began writing my system in 1978—thirty-four years ago. I don’t have to tell you; a lot of changes have occurred since then. However, the one advantage we had that most others did not, was that programs written decades ago are still usable today; even with the latest operating systems. There is one disadvantage as well, and I will talk about that now.

When I wrote our initial system, I designed it for my first customer. When I took on a second one, I had to redesign it to address the new customer’s requirements. As I added more clients, fewer and fewer rewrites were needed. Somewhere in 1986, having modified the system for forty clients, it became apparent that I had covered practically everything that might come up in the near, foreseeable future. 

In 1989, a major change occurred in data processing and it became advisable to redesign our system to take advantage of the new and more powerful IBM computers. By then, we had about 360 different companies using our system, and we rolled changes we had made during the previous three years into the new design. In 1992, we added our Satellite system and in the year 2000, we put everything on the Cloud. In 2004, we began working on our POS service. By then, the system was at least 10-times larger than what I had in the early days and probably 20% was just hanging out there with nothing to do.

This is a common problem with all computer software. We have it, our competitors have it, you have it, and your suppliers MOST CERTAINLY have it. If you do not stay on top of the situation, after a period of years, as old programmers leave and new programmers arrive, you end up with what the data processing industry calls, ‘spaghetti code’. If anyone denies it, they are either lying through their teeth, or they have not been in the business long enough to face reality. The purpose of software versions are an attempt at cleaning up spaghetti code and introducing efficiency and new functionality, but unless you throw everything out and start over again from scratch, spaghetti code will continue to grow and continue to have a negative impact on the efficiency and functionality of any system.

Most of your suppliers have software systems that are decades old. The term ‘legacy code’ does not even begin to express the real mess they have to deal with. They designed their systems to control their warehouses, their offices, and to send retailers a bill. Adding functionality to support Automated Store Replenishment has never been high on their list—UNTIL NOW!