The Transfer That Approves Itself
Our stock transfer has a button marked Approve. Pressing it does not approve anything — it is a synonym for Dispatch, in both the web application and the API, and the stock leaves the source warehouse in the same instant. There is no approved-and-waiting state, because there is no approved state at all.
A branch in Kandy asks the Colombo warehouse for forty units. Somebody in Colombo opens the request and presses Approve. The forty units are now gone from Colombo, in transit, and on their way — before anybody has picked them, packed them, or put them on a lorry.
That is not a description of a bug. It is a description of what the word means in our product. The approve action returns the dispatch action. They are the same code, reached by two different names, in the web application and in the API alike.
The three states, and the one that is missing
A transfer here moves through pending, then in transit, then either completed or returned. That is a sound and honest little state machine, and each transition does real work: dispatch reduces the source, receipt increases the destination, and a short receipt is recorded as a shortfall rather than silently absorbed.
What is not in that list is a state between asked for and gone. There is nowhere for a transfer to sit having been authorised and not yet physically moved. So the authorisation and the movement are one event, which means whoever authorises is also, necessarily, the person deciding the stock leaves right now.
Approve and Dispatch are two words for one function. The interface only ever shows one of them, which is why nobody has noticed the other exists.
It is worth saying what is not wrong here. There is a reject action, so a transfer is not unstoppable. The movement is recorded with a full history. The receiving end has its own confirmation and its own shortfall handling. Nothing is lost or untraceable. The gap is narrower and more specific than "no approval": it is that the accept path has no stop on it.
Why an island operation feels this first
Because a Sri Lankan distribution network is usually one central store and a scatter of outstations, connected by roads where a journey is measured in hours and a mistake is measured in days. Colombo to Jaffna is not a decision you unwind by driving back.
Three consequences follow, and they compound.
-
The source is short before the goods have moved
Between the press of the button and the pallet actually leaving, the stock is out of the source warehouse in the system and not in the destination. If a walk-in customer wants those units in that window, the system says there are none — and there are, on the floor, twenty metres away.
-
The authoriser and the picker become the same decision
In most operations these are deliberately different people at different times. A manager says yes on Monday; a storeman picks on Tuesday. Here the yes IS the pick, in record terms, so the record says something happened on Monday that happened on Tuesday.
-
A transfer that never physically leaves is invisible
Approved, dispatched, and then the lorry is full or the road is closed. The system believes those units are in transit. Nothing ages an in-transit transfer, nothing asks why it has been travelling for eleven days, and the source cannot see them.
The third one is the expensive one, and it is the reason this post exists. Stock in transit is stock nobody is looking at. The longer the corridor, the more of it there is, and the less anybody notices.
What to do about it without waiting for a build
Four controls that work with the states that exist
- Press the button at the loading bay, not at the desk. This is the whole fix, and it is a process change rather than a feature. Whoever dispatches does it when the goods are physically on the vehicle. The approval conversation happens before, by whatever means you like, and leaves no system record — which is the trade you are making.
- Put a maximum age on in-transit. Agree a number — two days, four days, whatever your longest route is plus one — and review the transfer list against it every week. Nothing in the product will do this for you, so make it somebody's named job rather than a good intention.
- Use the shortfall properly at the receiving end. A short receipt is recorded, and it is the only evidence you will get that something went wrong in the corridor. Insist that receipts are entered on arrival, not on Friday afternoon in a batch.
- Separate the people even though the system does not. If the same person raises, dispatches and receives, the movement has no independent witness at any point. That is a staffing decision available to you today, and it matters more here than it would in a system with an approval step.
A note on the word itself
We would rather the button did not say Approve. A control named for something it does not do is worse than no control, because it recruits the reader's trust for free. The honest label for this action is Dispatch, and that is the only label the interface actually renders — the approve name survives in the routes and the API, where an integrator will meet it and reasonably assume it means what it says.
Four questions to ask about transfers, in any system
Show me a transfer that has been approved and not yet dispatched.
A good answer sounds like
A record in that state, on screen, with a timestamp for the approval and none for the dispatch.
What it actually means
If the answer is that no such state exists, the authorisation and the movement are the same event — as they are here.
Where is stock that has left the source and not arrived?
A good answer sounds like
A named in-transit position, visible in a report, with an age.
What it actually means
In-transit stock that cannot be aged is stock nobody will look at until a count finds it missing.
Can one person raise, send and receive the same transfer?
A good answer sounds like
A clear yes or no, and a demonstration.
What it actually means
A no is a real control. A yes is manageable, but only if you know about it before you write your role design rather than after.
What happens to a transfer that is dispatched and never received?
A good answer sounds like
A shortfall, an alert, an ageing report — something.
What it actually means
Ours records the shortfall at receipt and does not chase the receipt. That difference is where losses hide.
What AWRA OpsHub does today
- A four-state transfer — pending, in transit, completed or returned — with dispatch reducing the source and receipt increasing the destination, each recorded with who and when.
- Partial and line-by-line dispatch and receipt, plus return-to-source with a stored reason.
- A recorded shortfall when less is received than was sent, held against the transfer.
- A reject action, on both the web application and the API, so an unwanted transfer can be refused.
- Signature capture on the transfer, and a PDF of the document.
What it does not do
- An approved state. The approve action is an alias for dispatch in both the web controller and the API controller — pressing it moves the stock.
- Any hold between authorisation and movement, so there is no window in which a transfer is agreed and the goods are still available at the source.
- Ageing of in-transit transfers. Nothing flags a movement that has been travelling too long.
- A reason or an owner on a shortfall. The quantity difference is recorded; why it happened and whose it is are not.
Not ours, by choice
- The interface renders Dispatch, not Approve. The alias is reachable through the routes and the API, which is where an integration will meet it.
- We have not re-verified which permission each transfer route carries in this pass, so we are not making a claim about separation of duties in code. Assume you must enforce it with people.
- Nothing here is Sri Lankan. It applies to any hub-and-spoke network; the longer your corridor, the more the missing state costs you.
What is not built for your market today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in your market. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a tax authority pipeline, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Tax authority pipelines and reporting
Electronic invoicing or invoice registration against your authority's published interface, with retries, a failure queue and a daily report of sales that carry no reference. The regimes across this region differ enough that this is one build per country rather than one build for the region, and the local bench is deep in most of them — so the honest question is usually whether you need this from us at all, or whether you need the operations layer that feeds whatever you already file with.
Local payment rails and bank feeds
Real-time payment collection matched to the invoice, bulk payment files in your bank's format, and statement feeds wired into the Payments Register.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
Statutory payroll and social security schedules computed on live records and produced in the layout each filing body expects. Per-state and per-province variation is the norm rather than the exception here, and it is what makes this a country build rather than a regional one.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedDesign the transfer process around what exists
Most of the risk in this page is closed by deciding who presses the button and where they are standing when they press it. We will walk your network and write that down with you.
Talk it throughFrequently asked questions
If I never use the approve route, does anything change?
No. The interface only ever shows Dispatch, so a normal user is already using the honestly named action. The alias matters if you are integrating against the API, where an endpoint called approve will be read as an authorisation step.
Can I stop a transfer after it has been dispatched?
You can return it to source, which is a real action with a stored reason, and you can reject a transfer before dispatch. What you cannot do is undo the dispatch as though it never happened — the movement is history, and returning it is a second movement.
Would you build an approval step?
An approved state, with its own permission and a hold on the source stock, is a genuine build rather than a setting — the state machine, the availability calculation and the interface all move. If it is decisive for your network, describe it and we will come back with a written scope, timeline and cost before you commit.
