Inventory management system development

What an inventory system is actually for

Most businesses do not begin with an inventory system. They begin with a spreadsheet, a stock room somebody knows by heart, and the habit of checking before promising anything. That holds until the spreadsheet and the shelf disagree, and from then on nobody is certain which version of the truth to act on.

An inventory system exists to settle that argument. It holds items, locations, quantities and the events that changed them, then applies an agreed rule for what may be promised to a customer. Reorder alerts, valuation reports and stock dashboards are all views of that record. When the record is wrong the views are confidently wrong, which does more damage than a spreadsheet nobody trusted in the first place.

This page covers the stock side: items, locations, movements, reservations, adjustments, permissions, counting and reporting. The storefront, the basket and the money belong to e-commerce website development and payment and checkout. Those systems consume stock and ask questions of it. Neither should be the place stock is defined.

It is worth saying early that a packaged product is often the cheaper answer. If you sell a few hundred lines from one location under ordinary rules, an off-the-shelf tool will do more on its first day than a custom build can justify, and we will tell you so. A custom system earns its place when the rules are genuinely yours: allocation by customer, stock committed against contracts, assembled or kitted goods, or a process no product supports without being bent out of shape.

One stock record, or none at all

Before anything is built, decide which system is allowed to be right. Stock tends to exist in several places at once: the online shop, the point of sale, the accounting package, a warehouse sheet and somebody's memory. If two of them can both change a number, they will drift apart, and reconciling them by hand becomes a permanent job nobody was hired to do.

The answer is one authoritative record and a defined direction of travel for everything else. Other systems may read from it, and they may raise events that change it, but only one of them holds the number. That single decision removes more future pain than any feature on the requirements list.

Physical, reserved and available are three different numbers

A stock record carrying one quantity will mislead you. Useful systems distinguish at least three figures, and they state in writing how the third is calculated.

• Physical stock is what is on the shelf, by location. It changes only when goods actually move, are counted, or are written off.
• Reserved stock is physical stock already spoken for: a paid order, a confirmed transfer, a quotation you honour for a fixed period. It is still in the building and it is not yours to sell twice.
• Available stock is what you are prepared to promise, and it is a policy rather than a fact. Usually physical minus reserved, sometimes minus a safety buffer, sometimes plus goods on a purchase order with a delivery date attached.
• Incoming and quarantined stock sit outside the available figure until somebody decides otherwise. A returned item nobody has inspected is not sellable, whatever the courier tracking says.

Two rules have to be agreed with you rather than assumed: whether stock may ever go negative, and what happens when two orders arrive for the last unit within the same second. Both have reasonable answers. Neither has a default we should be choosing on your behalf.

How stock actually moves

The clearest way to scope an inventory system is to walk one item through its life and write down what the system does at each step, who did it, and what happens when the step goes wrong. The table below does that for a fictional single-warehouse retailer. The roles, policies and responses are assumptions used for illustration, and the last column describes evidence to collect at acceptance rather than tests anybody has passed.

Transfers, picks, dispatches and quarantine decisions have the same shape: each is a state transition with an actor, a time and a reason. Modelling them as events rather than as edits to a number is what makes the history useful later, because every figure can then be explained by the entries that produced it.

Where stock has to reach an accounting package, a point of sale or a storefront, the questions are always the same four: which system owns the fact, what triggers a change, which direction the data moves, and who investigates when the two disagree. CRM and integrations covers how we approach those connections, including what has to be confirmed before anyone promises one exists.

Who is allowed to change a number

Stock permissions follow your business process rather than a copied role list. The useful exercise is naming who, in your operation, may do each of these things, and who reviews them afterwards.

• Receive goods and record a discrepancy against a delivery
• Reserve, release or override a reservation
• Move stock between locations and confirm it arrived
• Count a location and submit the result
• Approve an adjustment, particularly one carrying a value
• Decide whether a damaged or returned item ever becomes sellable again

The pattern that survives contact with a real warehouse is that ordinary movement stays fast and unremarkable, while anything that changes value or overrides a rule needs a second person and a stated reason. Every material change records who made it, when, what the figures were before and after, and why. That history is what turns an argument about stock into a five-minute look at the ledger.

Counting, discrepancies and the recheck nobody builds

A count is a workflow, not a text box. The system holds a recorded quantity, somebody counts the shelf, the difference is calculated, a reviewer accepts or rejects it, and the accepted adjustment is written to the ledger as its own entry with a reason attached. Rolling counts by location or by value band are usually kinder to an operation than closing the warehouse once a year, and they surface problems while the cause is recent enough to find.

Reporting then follows the same record: movement history by item or location, adjustments by reviewer and reason, ageing stock, items that repeatedly disagree with their count, and open exceptions nobody has closed. A report earns its place at the point where somebody acts on it, which is why we build these views into the operation rather than as decoration. Admin dashboards covers the staff-side surface in more detail.

Stock in more than one place

Once stock sits in more than one location, three questions decide the design. Does a customer buy from a specific location or from the total? Is stock in transit between branches owned by the sender, the receiver or neither? And can one branch see another branch's figures, or only that stock exists somewhere in the network?

Selling against a total is convenient and quietly dangerous, because a promise made against a total is fulfilled from a place. If a branch can be the source of an order, it needs a way to accept or decline that job. Multi-location scope also decides how counting works: counts are per location and the totals are derived.

What to bring to a scoping conversation

Bring your item list and how it varies, your locations, the events that change stock today and who performs them, the availability rule you want to promise against, the exceptions that already cause arguments, the systems that must be connected and who controls their access, and the tests you would want to see before accepting the work. That is enough to size a build honestly. If you would rather start from the current process, talk it through with us and we will say where a product would serve you better than a build.