Creating Lot Numbers Using A Hash
Creating Lot Numbers Using A Hash
A write-up on how best to create, implement, and use lot numbers to control your inventory
Inventory control using lot numbers
Lot numbers, batch numbers, and various other identifying marks are used in most industries today. They work best when you buy certain materials or components to distribute or build new components and assemblies.
While easy to create and implement (or perhaps because they are easy to create), using bad practices while designing your lot numbers and associated processes can lead to a large waste in admin time down the road. I have seen companies that spend hours each week managing various lot numbers because of "edge cases" that have arisen. They use extra logs, lot variations, and all types of devices in order to help control all the different scenarios that arise when using a simple lot number.
I would like to show a different method of lot number-creation that can avoid many of the issues, greatly improve its usefulness, and become a component of your company's modernization strategy rather than a legacy part of the business causing issues.
Lot numbers
A lot number differs from a serial number in that it describes a batch of items rather than a specific item.
Consider the VIN on your car. That number is unique to your car. A VIN would be considered a unique number and fall on the line of being a serial number rather than a lot number.
Lots identify a batch or production run to track and control units that have similar risk exposures; that is, were made from the same raw materials, run at the same time, with the same people running the same machines, at the same factory.
Let's say you order a heat of metal each month for your production. And you are about to produce 100,000 fasteners from your next delivery of metal wire. You set up the machine, run it for a few hours, and then turn it off. Beneath the machine, you have a bucket of fasteners, each one would belong to the same lot. Any parts made before or after that run would have a different and unique lot number.
The reasoning is that if anything was wrong, all of those fasteners would be exposed to the problem. Every one of those fasteners was exposed to the same possible risks and thus belongs to a lot. Any issue with
the material not being correct
dimensions not being correct in the machine setup
factory environment not being good for production
human error in some aspect of sorting the parts
would most likely carry to all of the fasteners.
Production runs before and after would likely not be affected if having used
material from a different order
a different setup on the machine
different factory environment being present
different machine
different sorting operators
Why use a lot number
The use of lot numbers is as much for the supplier as the customer.
Traceability and Control
The number one purpose of a lot number is control and traceability of inventory.
By assigning a lot number to each production run of each part, you can then trace the historical information on those parts.
Using software or a folder system you can save material certs, machine statistics, operator lists, quality gauging reports, and more with that lot. Should there be a problem later on in production, or downstream in the supply chain it will be much easier to track what potential issue caused the error.
Customer: "The parts are breaking when torqued too much"
Supplier: "What is the lot number?"
Customer: "XXXXX"
Supplier: "Ok, I can see here we had a less experienced operator on the cold header that day. I wonder if they used the wrong setup for that machine. We will look into it, in the meantime here are some parts created at a different time by a different operator."
Only by using lot numbers could the parts be traced back, and "different" parts be easily separated and made available. This leads to another benefit of using lot numbers.
Risk and waste reduction
By assigning a lot to each run of work, you can isolate similar parts that were exposed to similar risks.
Should there be a problem with inventory, you would need to scrap everything you have in stock. Without lot numbers and inventory control numbers the cost would increase should an issue arise. You can imagine scenarios such as
spinach that is found to have ebola
beauty product that is found to have contamination
prescription drug that is expired
car with a defective wiring system
fastener that is breaking with use.
All of the above could cause a catastrophic outcome to the problem, a need to throw all inventory out. Without a way to separate specific inventory exposed to similar risks, then we would have to assume it was all bad.
Lot numbers allow you to separate good from bad inventory. This is necessary for expiration dates, recalls, returns, failures, and other issues that may arise due to something that happened at production.
Creating and implementing a lot number
The requirements and implementation are quite easy:
create a unique string
Assign or affix that unique string to all similar parts.
An example for a roof coating company called E Las Tek using the following format to create a lot number:
The first two digits are the two-digit year suffix (2018 would be 18)
The next two digits are the month of production
The next two digits are the day of production
The next digit is the inter-company plant number
The last two digits represent the product batch on that day.
The above is a very common method for creating lot numbers. A combination of
The date
Location identification
Sequential id of some sort to reduce the risk of duplication
Once you have a standardized creation method, you just need to find a way to affix it to all parts. This is usually done with labels on the box if the product is small or a chemical, or on the part itself if large enough for that.
There are many other options including etching and stamping as well.
Issues in lot number-creation methods
The above lot number, while useful and fulfilling its basic function, has several problems that will cause unnecessary issues down the road.
The number of forms, logs, and processes to counter for lot number issues can become quite large before too long. I have seen many small companies that have built very complex systems for managing edge cases in lot numbers rather than questioning the original creation method first.
Collisions
One such issue is that of collisions. For example, some companies use the last digit of the year as a lot input, which can lead to duplication every ten years. This occurs in lot numbers, PO numbers, quotes, etc.
Issues with sequential assignments
Collisions can also occur as operations scale. When there are multiple production and batch runs being done at a large plant, on a daily basis, anything with a sequential number starts to cause issues. If person A is about to start a batch, how does he know what his sequential batch number is? If only one person is running production, then it is easy.
As operations scale, however, this becomes more complex. One person can't know about all production runs at one time except by technology, so there would need to be a way to grab the current number when new runs are starting, as well as a need to push that information to other production runs. Even more complicated is the need to disperse this info to multiple lot assigners as runs are started to make sure no one uses the same sequential number.
Sequential numbers also cause issues when lots are assigned before arriving at a facility. Medical and Industrial production has this issue. Let's say you need to control your product as early in the supply chain as possible. In this case you may have vendors assign lot numbers as they produce or ship product. Therefore you give them a lot number to use which contains a sequential number for the number of production runs of that particular part number or product code.
Now consider these scenarios
You dual-source this and have multiple suppliers sending product at various times. How do you assign the sequential numbers without knowing what will ship when from whom?
A supplier produces a batch but ships them in two shipments. Perhaps you are in a rush and need some shipped before the full batch is done with processing. Or perhaps you have some aired and the rest shipped by truck or boat. Either way, these batches should obtain different lots numbers due to being exposed to different logistical risk factors.
Taken further, what if you don't know a shipment will be split; that is, it is split by logistics?
This all becomes an issue when parts or products come in pre-labeled. You send an order and give them the lot number to use. Partway through they need to split the batch. They only have one lot number so they use it for both batches and now you have a traceability issue.
If the supplier does know to reach out to you, then you are creating multiple communication exchanges over lot numbers.
These and many other scenarios cause small and medium-sized businesses growing administrative time in creating and managing lot numbers for control and traceability.
What we need is a number that
any company or person can create in or outside of the company,
which never has a collision,
is unique,
and can be easily verified.
There is a cryptographic tool called a hash that meets all of these criteria, plus gives us some pretty cool features when we use it.
What is a hash, and why we should use it
A hash, in its broadest sense, is an algorithm that can take information of any size, and reduce it to a fixed size string. So whether you are talking about a 20-page document or a list of information like part number, vendor, quantity, and date; the hash will always give the same sized string of characters.
This is the methodology that most lot numbers use, in a way. A fixed-length letter and number combination to uniquely identify a shipment, production run, or any other controlled product.
Let's walk through creating a lot number using a hash function, and in the process, we will learn about the unique advantages of using this method.
Based on data
Most lot numbers today are more of an algorithm. You consider the date, the batch number, and maybe a few other pieces of information. With this, you fill in certain spaces until you have a lot number.
A hash transforms the actual data into a fixed string. So rather than being *based* on the data... it is the data... only transformed (technically: encrypted).
Readily available and easy to implement by anyone
Hash algorithms are available to all via the internet, and easy to use by anyone with internet access. For example, you can check out a SHA-256 hashing algorithm here
Any data you type into the field will be turned into a hash. Go ahead, play around with it.
They are unique
Hashes are unique in their output and vary greatly with only small changes in input. So let's assume we are using the following information in the form to create a hash:
{part: 1025,
quantity: 100,
date: 08/25/20}If we were to hash this using the SHA256 algorithm above, we would get the following hash
9fb95669ba2cd7c014d5888de0c49f378fcc36773bd5815ed1ffa24ea5d125cb
Now, let's say this is a daily shipment. For a regular lot number, a near-identical shipment would create a near-identical lot number. So if they used the date in format YYMMDD followed by customer code of 0321 and the part number, you would get lot numbers for the two shipments of
2008250321-1025
2008260321-1025
The near-identical information creates near-identical lot numbers. This highly increases the chance for wrong transcription, wrong picking, and wrong shipping. Even when having double checks, the average inspector or picker will miss the difference and might
create one CofC thinking that the lots are identical,
type up one shipment ticket grouping them all in the same lot
put the wrong lot into the shipment computer
This then ruins the traceability because in your system you have that you shipped 2008250321-1025 when you really shipped a mix of both. Eventually, you will show that your inventory on hand for each lot is wrong and you have too many of the 25 lot and not enough of the 26 lot.
This may be ok if shipping hardware and tracking the shipments. However, in industries like agriculture or pharmaceuticals, this is a huge problem.
When using a hash, let's see the difference in the result when we change one character from 25 to 26 to show the same successive shipment two days in a row.
{part: 1025,
quantity: 100,
date: 08/26/20}29342dc6cd6dd08f7d150287080993993b63f6788b5559a494e390ca7da61977
As you can see, the hash is completely different. This makes it much harder to mix, mis-pick, or make other reading and transcription errors, even when information is similar.
It is quick
You'll notice how quick it is to calculate a hash. You reduce the error or mental load on using dates, time, part number, and batch references and create it in less than 0.001ms.
They are normalized in length
Most computer systems rely on set string lengths. For example, Purchase Orders always have the same number of digits, same with Invoice numbers. The value of a hash is always the same.
There are hashes with more and some with fewer digits. The SHA-256 has 256 bits or 64 characters... always. One method of making this more amenable to lot numbers is to take the first 8 or 12 characters from the hash. So for the second example above, your lot number might 29342dc6.
This does increase the chance of collisions or getting the same lot number. If you created 10 lot numbers every day for 120 years, you would probably have 1 collision in that scenario. If you want to be safe, move to a 12 digit number and that will make somewhere north of 9 billion lot numbers before you had a collision.
They are non-invertible
Once I have my lot number, I can't figure out the original data. This is the encrypted aspect.
If I know the data, I will always get the same lot number.
If I know the lot number, I can't figure out the data that was used to create it.
For this reason, hashes are a great way to encode specific lot information right into the lot number. It will permanently be there, but not knowable by anyone except those who created the lot.
This helps with things such as verification, traceability, and transparency later on.
Issues to be controlled when using a hash
Understanding the above leads helps us foresee a few problems and design a useful lot number system.
Inputs must be exact and consistent
Because a small change in the input leads to large changes in output, inputs must be consistent and exact. If one of the inputs is the date, an input of 08/26/2019 will be drastically different from 8/26/2019.
Another example would be if there are text strings encoded in the lot number. If you have a customer ABC Textile encrypted in the lot number, and then later you enter Abc Textile, you will not be able to verify or create the same lot number due to the capitalization differences.
Fixes for this quite easy. The first fix is called sanitation. You sanitize all text before being entered into the hash. This can be built right into the algorithm and isn't something an inputter would need to be concerned with. An example might be a sanitizer that does two things:
Makes all text lower case
Converts all dates to DD/MM/YYYY
So no matter what you may enter:
ABC TEXTILE 8/26/2019Abc Textile 08/26/2019abc Textile 8/26/29
... the same input would be fed into the hash: abc textile 08/26/2019
Another method, and one that offers some additional benefits in transparency and verification, is to use a database to feed certain inputs, rather than entering text or numbers yourself.
You would have a database of suppliers, and each supplier would have a supplier id. When creating the lot number, you would select the supplier XYZ Machine, and it would feed the hash a consistent supplier id from the database 19843.
The additional benefit here is that you could verify with your customer certain information without revealing your supplier. For example, if there is a quality issue, you could prove that the supplier did not change by giving them the supplier ID along with the shipment info. If they went to any publicly available hash calculator online, they could put in the supplier ID for the two shipments in question, and see that they both register the lot number that they already have - thus verifying that the supplier is the same.
Let me show this as a testable example.
You create a shipment and lot number with the following information:
{supplier: 12345, part: 1025, quantity: 100, date: 08/26/20}
Giving you a hash of
45ac47c3bd121d92b45a92584fa8b6dc9eca1e7ac5ab706f5a52ea3b16426559
You send another shipment of the same part later in the year:
{supplier: 12345, part: 1025, quantity: 120, date: 011/20/20}
Giving you a hash of
6cce627c00f1695ebd1575eade829cf942fd4af5530419f657e9e29dbe05a379
These hashes are printed on the box of parts that the customer has, and were on there when the parts were delivered.
Now let's suppose the customer has a quality issue with the second shipment and wants proof that you did not change suppliers. Without a hash system, you would have to show your Packing Slips or Purchase Orders, revealing your suppliers and possibly costs. However, with the lot system, you could give them the inputs including supplier: 12345 and you would be able to see that the supplier has not changed. You have now verified information without revealing unwanted information.
This is part of the power of a hash.
Setting up
So if you want to set something like this up, it is fairly easy. I will walk you through how I did it, however, it can be done using much simpler tools such as excel & the internet.
Choose Inputs
The first thing you need to consider is "What information do I want to be encrypted in the hash?"
This should be things specific to the production run or order, not general part information, or other non-related info. Here are a few questions you can ask to determine what information you should use:
What information is native to the production run or shipment?
What data might a manager or customer ask to be verified?
What information might be needed later to assist in a root cause analysis should there be a problem?
What data is needed for traceability?
Based on the above, what I needed to track within the hash was:
Supplier
Customer
Part Number
Revision
Quantity
Date
From this data, we can understand the product, its production location, its customer, and some of the shipment data like quantity and date. This is also all information that the supplier can generate without contacting the customer. Creating processes and algorithms that don't need your constant input, allows for smoother supply chains without blockages.
As discussed earlier, we don't want issues with supplier or customer names causing problems with our hash because of capitalization or spelling. We also want to be able to verify information without disclosing names. For this reason, the shipper and the receiver are dropdowns with a list of company names.
Create an array
From this input, I have the software create an array with the data in a basic JSON format.
{:supplier=>"648BB", :customer=>"8FEAD", :part_number=>"123456", :revision=>"B", :quantity=>"120000", :date=>"2020-01-03 07:24:30"}
note: My customer and supplier codes are also hashes of the company names. In this way I can verify actual supplier and customer names should I ever need to.
Hash calculator
We then take this array of information and feed it into the hash algorithm.
This returns 938a839608b48c9c42f57a766da5ba263120ee65e68ed1cf79bab0d326c7e026
This is our unique lot number
Truncate
Now I don't want to use a lot number this long, so I can truncate it by just taking the first 12 or so digits.
The risk of "collision" or getting a duplicate is very low (unless you start producing in the billions of lot numbers).
We now have arrived at our lot number 938A-8396-08B4
This lot number goes on labels that are placed on each bag.
I then created a small page for the company to look up and view the lot and associated documentation.
We also have the original array at the bottom. Should any customer or internal manager want to verify quantity or supplier, we can give them the JSON array and they can go to any publicly available hash calculator to verify the first 12 are the same as the lot number
Problems alleviated
This method of lot number-creation solves several problems. Below are a few I have encountered (and now solved).
When ordering parts that come pre-packed and labeled, you often have to pre-assign the lot number and share it with the vendor.
Because the above system uses data that the supplier will have at the time of shipment, they can create and label these parts without your intervention. All that is needed is some calculator for them to enter the details into and get the first 12 digits.
This also creates lot numbers before parts reach your door, which is a higher level of control for traceability and tracking. Usually, these are assigned in your facility, but having them created and assigned pre-facility enables tracking right from production rather than ownership.
Other ideas and implementations
There are encryption methods that actually do use a hash that can be reversed with a key. This is a way to encode a large amount of data, and share the key with the customer. In this way, no one else would know the details of a product, but the customer could scan a barcode with the full hash on a label, and instantly get all the details of the shipment. Again the barcode itself IS the information since it is encrypted. There would be no other software needed to reference the code to data.
Another way to use a key is to encrypt (or hash) the information with your private key as one of the inputs. In this way, it is like digitally signing off on the information. Your key would be needed to unlock the data showing that only the data you signed off on, is the correct data.
This shows how using cryptography can help modernize your supply chain with small changes to your actual workflow, or heavy investments in new technologies.