Consolidating stock across multiple godowns
A representative scenario showing how we approach a distribution business whose stock records have diverged across locations.
Representative scenario
A representative scenario showing how we approach a distribution business whose stock records have diverged across locations. It is written from the pattern of work we do in this area rather than a single named engagement.
The shape of this project
How this project was approached
The seven stages this scenario moves through, from the problem as it was found to the position after implementation.
Challenge
The situation as it stood before any work began.
Requirements
What actually had to be true at the end.
Solution
The approach chosen, and why that one.
Technology
The stack, and the reasoning behind it.
Development
How the build was sequenced and verified.
Implementation
Rollout, migration and training.
Outcome
What changed — stated without invented figures.
Challenge
Each godown kept its own stock register. Head office received figures weekly, by which time they were already out of date. Purchasing was therefore done against stale numbers, producing simultaneous overstocking of slow items and stockouts of fast ones. Month-end reconciliation between sales, stock and accounts routinely took most of a fortnight.
Requirements
One authoritative stock figure per item per location, updated as movements happen. Purchase decisions driven by actual sales velocity. Inter-godown transfers recorded properly. Existing accounting software retained, with operational data posting into it rather than replacing it.
Solution
An inventory and purchasing module built first, because that is where the money was leaking. Goods receipt tied to purchase orders, location-wise stock with a formal transfer process, and reorder levels calculated from movement history rather than set by habit. Sales and dispatch followed once inventory was trusted.
Technology
Laravel for the application, PostgreSQL for transactional integrity across concurrent stock movements, and a React interface for the stock-heavy screens where filtering and bulk actions matter.
Development
Delivered module by module. Inventory went live first and ran in parallel with the existing registers until the figures agreed, which is what gave staff confidence to stop maintaining the old ones.
Implementation
Rolled out one godown at a time, with training at each site before go-live. Historical stock was migrated with a reconciliation report the client checked before cutover.
Outcome
Stock figures maintained in one place rather than several, purchasing driven by movement data, and month-end reconciliation reduced to reviewing exceptions rather than rebuilding the numbers. Specific savings figures are deliberately not quoted here: no verified client measurement has been supplied for publication.
Tell us what you are trying to build
Describe the problem in plain language and we will tell you what it would take to solve it — the approach, the moving parts and the sensible order to build them in. No obligation either way.