You Cannot Sell What You Have Not Received
Our system will not let stock go negative. The issue is refused, per warehouse, before anything is written. That is the correct behaviour and it has a price: the pallet standing in your yard that nobody has booked in does not exist, and cannot be sold.
There are two schools of thought about negative stock and they are both defensible. One says the system should record what happened, even if the arithmetic is temporarily impossible, and reconcile later. The other says an impossible number is worse than a refused transaction.
We are firmly in the second camp, and this page is about what that costs you rather than why we are right.
What the refusal actually is
Availability is computed for the specific warehouse and location the issue is being made from, and if the quantity requested exceeds it the transaction is refused with a message naming the item. Nothing is written. There is no partial issue, no negative balance, and no cleanup to do afterwards.
The same discipline applies to held stock: if you are issuing from a specific held source and that source has gone, the issue is refused rather than silently falling back to general availability.
The refusal is per location, which is the detail that matters. Having the stock in the building is not the same as having it in the place you are issuing from, and the system distinguishes those.
The system will not let you record something that cannot have happened. Everything on this page follows from that, including the awkward parts.
The same philosophy in two more places
It is worth seeing the pattern, because it tells you how the product will behave in situations this page does not cover.
| Situation | Behaviour | Why |
|---|---|---|
| Issuing more than you hold | Refused, before anything is written | A negative balance is not a fact about the world |
| Receiving more than you ordered | Blocked by default, with a tolerance you set, counting every prior delivery on the order | An over-receipt is usually an error and a split delivery should not creep past the order one lorry at a time |
| Receiving less than you ordered | Never blocked — recorded as a shortage | The goods are physically on the floor. Refusing them is how a control gets bypassed rather than obeyed |
The third row is the one that shows the reasoning is real rather than reflexive. A product that refused short deliveries would look stricter and would be worse, because the storekeeper would book in the ordered quantity to get past the screen and the discrepancy would vanish.
The cost: your receiving queue becomes a sales constraint
If stock cannot go negative, then stock that has not been booked in cannot be sold. Which means the moment your receiving falls behind, your sales are constrained by paperwork rather than by goods.
In a Gulf trading operation this is not a hypothetical. Consignments arrive in bulk against long lead times, clearance timing is outside your control, and a container can land on a Thursday afternoon into a receiving team that will not get to it until Sunday. The goods are in the yard. A customer wants twenty of them. The system says there are none, and the system is telling the truth about its own records.
Two failure modes follow, and the second is worse.
-
The sale is lost or delayed
Recoverable, visible, and it hurts once. Somebody chases receiving, the goods are booked in, the order goes out late.
-
Somebody books in an estimate to unblock the sale
Not recoverable, invisible, and it corrupts everything downstream. A receipt entered from a packing list rather than a count is a quantity nobody verified, and it becomes the book figure that the next stocktake will disagree with — by which time nobody remembers why.
The refusal did not cause the second failure. The receiving backlog did. But the refusal is what makes the backlog urgent enough for somebody to take a shortcut, which is worth knowing when you design the process.
The useful build here is not an override
People ask for permission to go negative. We would push back on that hard — a negative balance is a number that is wrong, and every report downstream inherits it. The work worth doing is upstream of the refusal.
A receiving queue with an age
Orders delivered and not yet booked in, with how long they have been waiting. Nothing surfaces this today, and it is the number that would stop the shortcut.
A provisional receipt
Goods booked in as arrived-but-not-verified, available to sell and clearly marked as uncounted, with a forced reconciliation. The hold and disposition states on stock are the natural place for it.
A refusal that says what to do
The smallest of the three: when an issue is refused, telling the user there is an unbooked delivery on the item rather than only that there is no stock.
No dates on a public page. If receiving throughput is your constraint rather than an occasional annoyance, describe it and we will come back with a written scope, timeline and cost.
Scope the receiving flowWhat AWRA OpsHub does today
- A hard refusal on issuing more than is available, computed per warehouse and per location, before anything is written.
- A separate refusal when a specific held-stock source no longer exists, rather than a silent fallback.
- Over-receipt blocked by default with a per-organisation tolerance, counting every prior delivery against the order so a split delivery cannot creep past it.
- Short delivery recorded as a shortage and never blocked.
- Hold and disposition states on stock at a location, which remove it from the available pool with a reason.
- Stock reservable by hand at a location, with a reason, so a commitment can be protected.
What it does not do
- Any negative-stock allowance, override or permission. There is no way to record an issue you cannot make.
- A provisional or unverified receipt. Goods are either booked in or they are not.
- A receiving backlog view — nothing shows deliveries that have arrived and not been entered, or how long they have waited.
- Automatic reservation. Stock is only held against a commitment if a person places the hold.
Not ours, by choice
- We would not build a negative-stock override on request without arguing about it first. It is not a missing feature; it is a position.
- The receiving discipline is the real control here, and it is yours rather than the product's. A same-day booking-in rule removes almost everything on this page.
- Nothing here is Kuwaiti. It is the arithmetic of bulk arrivals against a strict availability rule; the Gulf is where the arrivals are most likely to be bulk.
Our position
Keep the refusal — a system that lets you hold minus four of something will eventually tell you a lie you act on. Then pay for it properly: book goods in on the day they arrive, make receiving throughput somebody's measured responsibility rather than a background task, and treat any receipt entered from a packing list instead of a count as the incident it is. The control is sound; the process around it is where this is won or lost.
Fix receiving, not availability
Almost every complaint about strict availability turns out to be a complaint about how long it takes to book a container in. Tell us how your receiving day works and we will look at where the hours go.
Look at receivingFrequently asked questions
Can an administrator override the refusal?
No. It is not a permission, it is a check on the transaction, and no role bypasses it. That is deliberate — an override on this particular rule would be used routinely within a month and the guarantee would be worth nothing.
What about the point of sale — can the till oversell?
The till moves stock through the same paths, so the same availability logic applies. That consistency is the point: two different answers to "do we have any" in one product is how a shop sells something twice.
How do I sell goods that are cleared but not yet in the warehouse?
Today, you book them in when they arrive and not before, which means the sale waits. The honest workaround for a business that genuinely trades on goods in transit is to make receiving fast rather than to look for a way around the check — and if in-transit selling is a structural requirement of your model, tell us, because that is a design conversation rather than a setting.
