Stock Requests: Branches Ask, Head Office Decides
The moment your shop opens a second branch, one conversation starts repeating every week.
“We’re out of 10W-40 over here. Can you send some?”
By phone. Or in a chat that sinks out of sight. No record of who asked for what, when, or how much. Then next week the same branch asks for the same thing, and nobody can confirm whether the last lot was ever sent.
Stock transfers alone do not solve this — because a transfer is the act of sending, not the act of asking. If every need is met by transfer, anybody can pull stock with nobody deciding. And a warehouse that can be drained without a decision will always be empty in the wrong place.
Stock requests give asking a route of its own. A branch submits what it needs, head office decides, and the whole thing leaves a trail.
What makes it work in practice is one detail that often surprises people: status does not sit on the request, it sits on each line. One request holding five items can end with three shipped from the warehouse, one bought from a supplier, and one declined — all within a single document, with no need to raise anything new.
And a line that has to be bought can be linked directly to its purchase. Which means “why did we buy this in the first place?” finally has an answer that is stored rather than remembered.
Before you start
- More than one active shop, or one shop with a separate warehouse.
- Products registered with correct units — a request states quantities in units.
Steps
-
First understand how this differs from a stock transfer — they are not the same
A transfer is the act of sending: the goods are already decided, they just need to travel. A request is the act of asking: a branch proposes, and may not get it. Using transfers for every need means branches can pull stock with nobody deciding.
A stock request is not a stock transfer. -
Raise the request from the branch that needs it, not from head office
The person who knows what has run out is the one facing the customers. A request comes from the side that is short, then goes up to be decided. That direction matters — head office guessing branch needs always ships the wrong things.
Raised by the branch in need, not by head office. -
Build the list line by line, not as one long note
Each item becomes its own line with product, quantity and unit. Writing "send oil and filters as needed" in a notes field makes that request impossible to fulfil partially, and impossible to track.
One item per row, not one long note. -
Give the reason in the description, not merely the quantity
There is a description field on the request and on each line. "Out of stock, three repairs waiting" gets prioritised; a request with no reason queues behind. This is not bureaucracy — it is how head office decides what is urgent when every branch asks at once.
-
Understand that every line carries its own status
This is the part that most often surprises people. Status does not sit on the request as a whole, it sits on each line. So one request holding five items can end with three shipped, one bought in, and one declined — without raising a new request.
Every row carries its own status. -
Decide each line: ship from stock, or buy it in
A request line can be linked to a purchase transaction. Which means an item held in no warehouse need not be declined — it can simply be bought, and that purchase stays connected to the request that triggered it. "Why did we buy this?" finally has a stored answer.
-
Decline with a reason rather than in silence
A request declined without explanation will be repeated next week in the same words. Write why — the item was discontinued, or central stock is running low. A branch that knows the reason stops asking; a branch that does not will telephone.
-
Items that do get shipped still go through the transfer flow
A request is the decision; a transfer is the movement of goods. They pair up rather than replace one another. Stock only genuinely moves when the transfer runs and is received — not when the request is approved.
Approved goods still travel through a stock transfer. -
Review hanging requests weekly
Requests that are never closed are the most common reason branches abandon the system and go back to phoning. Fix one regular time to clear the undecided list — even when the decision is no.
Review the outstanding ones every week.
What you end up with
Each branch stock needs travel through a traceable official route: who asked for what, when, why, and how it ended — shipped from the warehouse, bought in, or declined with a reason.
If something goes wrong
The request is approved but branch stock has not increased
Approving is not sending. Stock only moves through a stock transfer, and only arrives once the receiving branch confirms. Check whether the transfer has been created.
One request holds many items, some available and some not
There is no need to cancel the whole thing. Each line has its own status — process what exists, buy in or decline what does not. That is how it is designed to work.
A branch keeps requesting the same item over and over
That is not a request problem, it is a signal that the reorder point at that branch is set too low. Raise its minimum stock threshold and the repeat requests stop by themselves.
I cannot tell what triggered this purchase
If the purchase was born from a request, the link is stored. Trace it from the request line. If there is no link, that purchase was created directly without going through a request.
Branches prefer phoning to raising a request
Almost always because earlier requests were never answered. Fix your response speed first; a rule will never beat a habit while the official route feels slower.