Inventory Accuracy

Designing a More Reliable Inventory Tracking System: Physical Events To Digital Records

People frequently talk about inventory systems as databases with inventory numbers and locations

An actual inventory consists of physical objects and their movements

An item is received to a warehouse, located, moved, picked, transferred, returned or shipped. All these events impact the state of the system

But, if the physical event occurs and the software is not updated properly, the information in it becomes inaccurate

This creates an interesting systems-design challenge.

Instead, think about the operations as a set of inventory events

For example:

Receive

↓

Identify

↓

Put Away

↓

Store

↓

Move / Pick

↓

Ship / Return

We can have an inventory item event structure somewhere in the system containing:

Item ID

Location

Timestamp

Event type

Quantity

Operator / Device

Of course, the specifics of the implementation can vary. But there is a general idea to track changes to inventory through physical events.

Now, for each operation, a system scans the item or reads some other piece of information. These are the means by which the application identifies inventory items.

Barcodes, RFID and other technologies

Barcodes and QR codes offer an easy way to identify items, containers and locations. It can be implemented in the following way:

Scan Item

↓

Read identifier

↓

Validate transaction

↓

Inventory Update

↓

Event Creation

That helps minimize manual interventions and standardize the transaction process.

In contrast, RFID does not require visual scanning of particular items, but instead uses radio waves to communicate with tags. This approach allows more automation and addresses the needs for reading multiple tagged items or identifying items as they move.

Finally, BLE or other similar technologies might have their place when the use-case requires something else.

As a summary, the choice of the identification technology depends on the requirements of the application and environment. There is no single best solution. To learn more about RFID, barcode and other technologies, see The Inventory Master website .

A system should understand that events are different from the current state. For instance:

Event:

Item A moved from Location 01 to Location 02

Current state:

Item A → Location 02

The current state is convenient for display and analysis. But an application needs to capture all the changes in order to perform reconciliation and debugging when items are misplaced. By keeping the event history, it can reason about what has happened to a particular item based on a series of atomic movements.

A system is unlikely to operate in isolation. There may be related components, for example:

RFID / Barcode devices

↓

Inventory Platform

↓

WMS / ERP / SCM

↓

Orders / Purchasing / Reporting

The software must process information from these components and, conversely, send some data back. Developers should understand how data flows in the system, identifying possible weak points such as:

Duplicate events

Delivered events (late / not at all)

Communication issues (device connectivity)

Invalid or incorrect identifiers

Incomplete transactions

Authentication and security

Overall data synchronization

Failure during API calls

Conflicting inventory states

A demonstration might work flawlessly in development. But a production system with actual devices and data will inevitably encounter problems.

Idempotency will help in preventing some of these errors from occurring.

For instance, if a scanner sends the same message twice due to a failed attempt, two receive events can erroneously add 20 units to inventory instead of 10:

Receive 10

Receive 10

The simplest way to avoid this issue is to ensure that a system will only accept the first request and reject all others.

This can be achieved, for example, with a unique transaction ID:

event_id = "A7F92..."

The system can store all the event IDs it has received and ensure that a new event does not have duplicates.

This level of protection is especially important for distributed systems and applications using any kind of network communication.

Technology is a means to an end, and an inventory application should drive the selection of particular technologies

There is often a temptation to identify potential pieces of technology first and then try to find a use-case for them. It works the other way around. First, analyze the processes and think about how a particular technology will enhance the system. Some ideas will not work, sometimes the requirements will be different, and in other cases finding a new automation opportunity will be crucial.

For instance, the workflow question should be asked for each process:

Where / How does the item arrive?

Where / How is the item identified?

Where and how is it moved or picked?

Where and how the information gets lost?

Where / When are reconciliation issues identified?

... etc.

Once the pain-points are known, choose tools that will address them.

A barcode reader might be enough to solve the problem. In some situations, RFID, BLE or other technologies may be needed. Some applications will benefit from a barcode / RFID reader and a separate inventory platform. Finally, there are cases when a fully-integrated system is more appropriate.

Systems have to track inventory items as they move from one location to another. This is where the software turns into an inventory system. But it is not enough to know just the number - it has to be able to follow events and reconstruct them when issues arise. That is why developers must consider accuracy when designing software, but also think of all the ways in which information might come in incorrectly and what actions the system should take if that happens.

The software component of an inventory system often consists of databases with inventory numbers and locations. But the underlying physical objects tend to involve scanning devices and actual places inside warehouses. Developers building reliable systems should keep these two aspects in mind and make the application track events accurately. This way, they will be able to easily identify discrepancies and fix them. Finally, systems should incorporate observability practices to ensure that their state reflects the physical reality. But that is a separate topic which will be covered in detail in another article.