Requesting Stock
Ask another business unit to send you stock — the request, the Transfer Note that fulfils it, and where each side sees it.
A stock transfer is the sending unit deciding to push stock out. A stock request is the opposite direction: the unit that needs the stock asks for it, and the unit that holds it decides what to send. Nothing moves and nothing posts until the request has been turned into a transfer and that transfer has been acknowledged.
Where requests live
Navigate to: Operations → Business Units → open a unit → Stock → Transfers → Requests
The Transfers area has four mini-tabs — Receiving, Sending, Requests, History — each carrying an honest count so a zero never looks like something has gone missing. Inside Requests there is a second toggle, because a unit is on both sides of this conversation:
| Toggle | Shows | What you can do here |
|---|---|---|
| Inbox | Requests other units have sent to this unit — this unit is the source being asked. | Fulfil a submitted request by issuing a Transfer Note. |
| My requests | Requests this unit has raised against other units. | Cancel one you raised while it is still Submitted, and watch for it to be fulfilled. |
Each toggle carries its own count of requests still awaiting action, so it is obvious which side of the exchange is waiting on you.
Raising a request
Click: Request stock (available on the Transfers tab)
The picker lists every business unit except the one you are standing in. Required.
Defaults to today. This is the date the requesting unit needs the stock, and it is shown to the source so they can prioritise.
One row per item. The item picker draws from this unit's catalog, with a search box once there are more than eight items. Add as many rows as you need; every row needs an item and a quantity greater than zero, or it is dropped.
Optional, and the most useful field on the form — what the stock is for, how urgent it is, any special handling. The source sees it verbatim when they open the request.
The request lands in the source unit's Inbox with status Submitted. Nothing has moved.
A request can also be started from an item that is short — from the item's own page, or by selecting several low-stock items in a list. The form opens pre-seeded with those items, and you fill in only the quantities.
Fulfilling a request
From the Inbox, a Fulfil button appears on any request still at Submitted. It opens the request with the requester's name, the fulfilling unit, the requester's notes, and one line per requested item showing what was asked for.
| Field | Details |
|---|---|
| Quantity per line | Pre-filled with the requested quantity, and capped at it. Trim it to send less. Set a line to zero to skip it — at least one line must stay positive or the form refuses. |
| Transfer date | Defaults to today. This is the date the resulting transfer carries. |
| Transfer Note remarks | What you actually sent, condition, and the reason for any short quantity. Worth filling in — it is the record the receiving unit reads. |
Issuing the note does two things: the request flips to Fulfilled, and a normal stock transfer is created at status Pending, linked back to the request.
The Transfer Note is a Pending transfer, nothing more. Quantity moves only when the receiving unit acknowledges it — see Stock transfers. A request that reads Fulfilled means "it has been sent", never "it has arrived".
Request statuses
| Status | Meaning |
|---|---|
| Submitted | Waiting on the source unit. The only status from which a request can be fulfilled or cancelled. |
| Fulfilled | The source issued a Transfer Note. The stock is in transit as a Pending transfer, not yet received. |
| Cancelled | The requester withdrew it. The source no longer sees it as pending. |
| Rejected | A declined request, carrying the reason. See the note below — there is currently no button that produces this status. |
Only a Submitted request can change. Trying to cancel or fulfil one that has already moved on is refused with the current status named.
Rejection exists in the system — the status, the required reason, and the filter option are all there — but no screen offers a Reject action. In practice a source unit that cannot fill a request either fulfils it with reduced quantities and explains the shortfall in the remarks, or tells the requester to cancel it. Until this is fixed, do not expect an unwanted request to be declinable.
Every request is created without a document number, so the printable view falls back to the first characters of its internal id. There is no human reference to quote in a phone call or an email. Identify a request by date, requesting unit, and items instead.
The request list
| Column | Details |
|---|---|
| Date | When the request was raised. |
| Requested by / Requested from | The other party. The heading flips depending on which toggle you are on. |
| Need by | The date the requester needs it, or a dash. |
| Items | How many distinct items are on the request. |
| Total qty | The sum of the requested quantities. |
| Status | Submitted, Fulfilled, Cancelled, or Rejected. |
| Actions | View / Print / Share on any request; Fulfil on a submitted inbound one; Cancel on a submitted outbound one. |
A status filter above the table narrows to one status at a time.
No journal, at any point
Neither the request nor the Transfer Note posts anything to the ledger. A request is a message; the transfer it produces moves quantity between units when acknowledged, and inventory value moves with the quantity — but no journal entry is created, because the stock never left the business.
Related
- Stock transfers — the transfer a fulfilled request becomes, and how it is acknowledged
- Stock transfers between centers — the same flow from the business unit's perspective
- Business units — the units on either side of a request
- Allowed items — the catalog a unit can request from
- Stock overview — where the received quantity lands