Skip to content

26 September 2026 · 4 min read

Van stock and return visits need one parts workflow

Connect part requests, reservations, van transfers and job consumption so a return visit is scheduled against more than an expected delivery date.

Author
Sawhorse Engineering
Published
26 September 2026

The office orders a part after a diagnostic visit, then books a return appointment using the supplier's expected delivery date. The delivery slips, a similar part arrives instead, or another job consumes the item first. Dispatch now has a confirmed visit with no confirmed material to complete it.

This is not only an inventory screen problem. Parts move through a chain of decisions: identification, approval, ordering, receipt, reservation, transfer and use. A return visit should depend on the relevant steps in that chain rather than a note that someone ordered the part.

Separate a request from an approved item

The technician's request should identify the job, affected equipment, observed requirement and the evidence available. A photograph or manufacturer reference can help the parts coordinator verify the item. An uncertain identification needs a review state, not an automatic purchase of the nearest catalogue match.

Keep the requested item and the approved replacement separately when they differ. Record the reason for a substitution and the person authorised to approve it. Software should not infer interchangeability from similar names or dimensions. The business needs its own review process for compatibility and any applicable work requirements.

Once approved, use a stable catalogue identifier where available. Supplier descriptions can change, and different suppliers may describe the same item differently. Preserve the supplier's reference alongside the internal item so purchasing and field staff can trace the choice.

Available stock is not the quantity on the shelf

An item physically present may already be reserved for another job. Show on hand, reserved, available and uncertain quantities separately. Do not subtract an incoming purchase order from a shortage as though the goods have already arrived.

For a job reservation, record the quantity, location and current status. Two dispatchers should not be able to reserve the last item concurrently. Enforce that rule at the shared data boundary rather than trusting two browser screens to update quickly enough.

Decide when a reservation expires or is released. A cancelled job should not keep parts unavailable indefinitely, but a postponed visit may still need them. Make the cancellation or reschedule workflow ask the relevant question and record the outcome.

Treat a van transfer as a journey

Moving a part from the store to a van is not the same as consuming it on a job. Record the source, destination, quantity and responsible people. Where the operation requires acknowledgement, distinguish dispatched from received so an item in transit is not shown as ready in both locations.

Let staff report a discrepancy during receipt. The van may receive fewer items than expected or a damaged package. An all or nothing confirmation button encourages people to accept the planned quantity and correct it later, leaving dispatch with misleading availability in the meantime.

Use the same movement history for transfers between vans. A message saying the part was handed over can be useful communication, but the inventory record needs the actual transfer. Keep the interaction short enough that technicians can complete it while working.

Receipt is the point to verify the delivery

Link a delivery to the purchase request and inspect the item reference and quantity before marking it available. Partial receipt should leave the remaining amount open. A substituted item needs its own approval path rather than silently completing the original request.

Store the supplier's current delivery expectation separately from the last confirmed receipt. The expected date can support planning, while the receipt supports commitment. Show both to dispatch so the office can decide whether to hold a tentative window or contact the customer after the part is ready.

If the supplier sends updates electronically, preserve the external order and line identifiers. A repeated update must not create another receipt. An integration should not mark goods physically received merely because the supplier reports them shipped.

Consumption belongs to the actual work

When a technician uses an item, link the movement to the job and asset where practical. Keep unused returned material, damaged stock and consumed stock as different outcomes. They have different implications for availability and for the job record.

Offline capture should create a pending movement with a stable client identifier. On reconnection, the server validates it against current state and applies it once. If the movement conflicts with a later stock correction, expose the discrepancy for review rather than dropping the technician's entry or silently allowing an impossible balance.

Corrections should preserve the original movement. An adjustment with a reason is easier to investigate than replacing yesterday's quantity without history. The balance can then be reconstructed from the accepted movements and approved corrections.

Make return visits depend on explicit readiness

A return visit can have a readiness checklist: approved part, received quantity, assigned stock location and suitable technician. The exact conditions depend on the operation, but they should be visible to the person confirming the appointment.

Allow a responsible dispatcher to proceed with a known exception when the business permits it. Record the missing prerequisite and reason. An override should make risk visible, not turn every incomplete job green.

Test the workflow with a partial delivery, a cancelled job, a van transfer that is not acknowledged and two jobs requesting the last available item. Follow each through to the customer appointment. A useful system does not merely make the stock total add up. It lets dispatch explain what is ready, what is uncertain and what must happen before the next visit can be confirmed.

Let’s talk about the system you need.

Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.

  • A mutual NDA is signed before project details are shared.
  • Scope is fixed in writing before any build starts.
  • You own the source code, the IP and the documentation at delivery.
  • Support plans are available and tailored on a discovery or technical call.