Trucks, vans, and stock rooms: tying parts usage to jobs without another spreadsheet

Van stock is a black hole in many shops. Techs grab fittings Friday; costing lands on the wrong job—or no job at all. Spreadsheets patched together on Sundays do not scale past a dozen trucks, and they encode a single implicit assumption that breaks immediately: that inventory lives in one place.

The correct model is multi-location inventory where every truck bin and every stockroom shelf is a distinct location with its own balance. Parts move between locations and get consumed against jobs. Framed that way, the shop’s inventory is a ledger of movements, and the ‘black hole’ is simply the movements you never recorded. You fix leaks by making the movement cheap to record, not by auditing harder.

Connect parts pulls—whether from the warehouse or a truck bin—to the active work order as immutable ledger entries: quantity, SKU, source location, job ID, timestamp, actor. Two invariants fall out of a ledger design and are worth enforcing explicitly. First, conservation: on-hand at a location equals sum of receipts minus sum of consumptions and transfers—it should never be derived two different ways. Second, attribution: a consumption entry references exactly one job, so cost of goods flows to the right margin calculation.

When dispatch, inventory, and billing read from that same ledger, reorder thresholds and job margins use identical numbers by construction. There is no reconciliation step because there are not two sources to reconcile—the billing view and the reorder view are both projections of one movement log.

Reordering is a feedback controller, not a nightly cron that blasts POs. The signal is per-location on-hand relative to a reorder point; the control action is a drafted purchase order; the human is in the loop as the actuator that commits spend. Naive threshold triggers thrash—dispatching a PO every time a count dips and recovers—so the loop needs hysteresis (reorder point vs. reorder-up-to level) and debouncing so a single restock trip doesn’t generate ten POs.

A supervised agent groups pending needs by vendor and by job, drafts the PO, and surfaces it for approval. It should also reason about lead time and truck-stock policy so it recommends the right quantity of the right SKU—you approve; the system does not silently stockpile last year’s condenser model because a min was misconfigured.

The whole ledger is worthless if the field won’t feed it, so the capture UX is a first-order engineering constraint, not polish. Keep capture to a scan or a tap at the truck—not a 12-field form at the job site. Every extra required field trades data completeness for data honesty; past a threshold, techs enter garbage to move on, which is worse than a missing row.

Assume offline. Capture has to enqueue locally on a truck with no signal and sync later with idempotency keys, so a delayed upload never posts a duplicate consumption. And design for exceptions explicitly: office staff get a reconciliation queue for unmatched pulls, so the field stays fast and correctness is recovered asynchronously by the people equipped to do it.