Why Stock Transfers
Moving stock between warehouses is a chain of small, time-sensitive steps: someone requests it, someone dispatches it, a rider carries it, someone receives it, and occasionally someone reconciles a mismatch. When all of that lives in one long, date-sorted grid, the two people who matter most — the one who needs to act and the one who’s just looking something up — get in each other’s way.
Stock Transfers is built action-first to fix that.
Two lists, two jobs
The screen splits into two independent tables:
- Needs your action — the open transfers (
pending,in transit,in progress). Every row here has a next step, and the row’s button says exactly what it is: Dispatch, Rider confirm, Complete, or Review. - All other transfers — the closed ones (
completed,cancelled,partialGRNs). This is the archive you search when you need to look one up.
Because the split is by status, not by position in a page, the “needs your action” list stays stable and true no matter how deep you page into history.
Independent data, independent pages
Each list fetches its own rows from the server, filtered to its own statuses, and paginates on its own. Paging through months of completed transfers never pushes a pending dispatch off the top of your queue — the two queries run in parallel and never disturb each other. (See How the two sections work.)
Triage before you filter
A triage bar of three pills sits above both lists — Awaiting dispatch, In transit / receiving, and Needs review. One click narrows what’s on screen to that bucket, so a dispatcher, a receiver, and a pharmacist chasing mismatches each get their view in a tap, without opening the full filter set.
Nothing hidden, everything findable
The action-first shape doesn’t cost you power: search, a source/destination Locations picker, and a Filters panel (status, type, product, date range, attention-only) are all one click away, and every active filter shows as a removable chip. The list is fast to scan and fast to narrow — but it always leads with what needs doing.