Wholesale and inventory
Stock across locations, purchasing against demand, orders picked and dispatched, and a stock figure the sales side can actually trust when it promises a delivery date.
Talk about scopeThree things that decide whether this works
On hand is four numbers, not one: physically present, reserved against an order, in transit from a supplier, and available to promise. Sales needs the fourth, the warehouse needs the first, and a system that shows one figure will be wrong for somebody every day.
A unit is not a unit: the same product is bought by the pallet, stocked by the case and sold by the item, with conversions that are sometimes not clean. Every quantity in the system therefore carries its unit, and every conversion is explicit — this is one of the few modelling mistakes that is genuinely unrecoverable later.
The count will disagree with the system: stock is miscounted, damaged, mispicked and occasionally stolen. The question is not how to prevent divergence but how to find and post it — cycle counting with a recorded adjustment and a reason, rather than an annual stocktake that silently rewrites the number.
Committing to a delivery date is the real feature
Wholesale customers do not want a stock level, they want to know whether it ships on Thursday. Answering that means combining what is on the shelf, what is already promised to somebody else, what is arriving from a supplier and when, and whether the order can be split. This is the calculation the business runs on, and it is the one most inventory systems leave to a person with a spreadsheet and a good memory.
Picking is a physical process with a layout
An order becomes a route through a building. Pick lists ordered by location rather than by order line, short picks recorded where they happen, and a partial dispatch that leaves the remainder correctly back-ordered rather than quietly cancelled. Software written without reference to how the warehouse is actually laid out gets printed out and ignored.
- 01FX-118A3
- 02QT-904D1
- 03FX-220A7
- 04MR-051B2
- 05QT-880D4
- 06MR-119B6
A → D → A → B → D → B. Four crossings.
- 01FX-118A3
- 02FX-220A7
- 03MR-051B2
- 04MR-119B6
- 05QT-904D1
- 06QT-880D4
A → A → B → B → D → D. One pass.
Buying against demand rather than against a feeling
Reorder points set once and never revisited are why a business is simultaneously overstocked on some lines and out of the one a customer wanted. Useful purchasing reads real consumption per line, accounts for supplier lead time, and proposes a quantity with its reasoning visible so a buyer can disagree with it.
It should also be honest about what it cannot know. Seasonality, a promotion, or a single large customer changing their order pattern will beat any forecast, so the system's job is to surface the change quickly rather than to predict it confidently.
What we would expect to build
- Multi-location stock with transfers between them
- Units of measure, with explicit conversion
- Available-to-promise, not just on-hand
- Purchase orders, receipts and three-way matching
- Cycle counts with reasoned adjustments
- Pick, pack and partial dispatch with back-orders
- Batch or serial tracking where the goods require it
- Customer-specific pricing and terms
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.