The Shelf That Cannot Be Full
You can tell our system how much a storage location holds. There is a field for it on the location, it is offered when you create one, and it saves correctly. Nothing has ever read it — you can put four times that quantity in the location and the system will record it without comment.
Storage capacity is one of the few genuinely physical constraints in stock control. Most limits in an operations system are policy — a credit limit, an approval threshold, a reorder point — and can be changed by somebody with the right permission. A shelf cannot be argued with.
Our system asks you how big each location is, and then ignores the answer.
What actually happens
The capacity is stored against the location and cast as a number. It is offered when a location is created, shown when one is edited, and appears in the list of locations. Everything about its presentation suggests a working constraint.
Then stock is received into that location, or transferred into it, and no comparison happens. There is no refusal, no warning, no flag on the movement afterwards, and no report anywhere that lists locations holding more than they were said to hold. The number sits there being correct and unconsulted.
A constraint that is recorded and never checked is not a weak constraint. It is a note.
This is one of five settings we have found in our own product this month that are captured and consumed by nothing — the running list is kept in the monthly that never comes — and the pattern is clear enough to be worth stating as a general warning rather than a confession: the presence of a field is not evidence that anything acts on it, in our software or anybody else's, and the only way to know is to try to violate it.
Why space is a harder constraint on an island
Every warehouse in the world is finite, so the argument has to be sharper than that.
The difference is what happens when you run out. On a mainland with dense supply, an overfull warehouse is an inconvenience with several answers — rent an overflow unit down the road, push a delivery back a week, move slow lines to a third-party store. Space is a purchasable commodity at short notice.
Across the Pacific it frequently is not. Resupply arrives on a schedule you do not control and in quantities set by what makes the voyage worthwhile rather than by what you can comfortably hold, which means the arriving quantity is often large and the interval long. There may be no second warehouse to rent on the island at all. And you cannot decline the delivery and take it next week, because next week is not on offer.
So the consequence of overfilling is not a cost, it is a physical problem: stock in walkways, mixed pallets, goods stored where they cannot be found, and damage. Every one of those turns into the inventory errors that a counting programme then spends the year discovering.
If
your space is genuinely elastic
Leave the field empty. An unset capacity is honest; a set one implies a check that is not happening, which is worse than saying nothing.
If
you use it as documentation for people
That is a legitimate use and it works — somebody reading the location list learns something true. Just make sure everybody knows it is a note rather than a limit, because the screen does not say so.
If
you need the system to refuse an over-capacity putaway
It cannot, and no setting will make it. Plan the constraint outside the system and ask us before you commit to a process that assumes otherwise.
The verdict
This is a small gap with a large lesson attached. The capacity field looks exactly like a working limit and has never been one, which means anybody who set it has been carrying an assumption the software never earned. If your space is elastic, leave it blank and lose nothing. If you are operating where a container arrives when it arrives and there is nowhere else to put it, understand that the constraint lives entirely in your planning and not at all in our system — and take the general lesson with you into every other tool you evaluate. Set the limit, then break it. Whatever happens next is the real answer.
Four questions about any limit a system offers you
Set a capacity of ten, then put in forty. What happens?
What a straight answer sounds like
A refusal, a warning, or nothing. Ours is nothing.
Why it matters
The only reliable test of any limit is to violate it. This applies to every threshold in every system you evaluate.
Which locations are over capacity right now?
What a straight answer sounds like
A report. Ours cannot answer it.
Why it matters
Even where prevention is absent, detection is usually cheap — and its absence tells you the field is not connected to anything.
What unit is the capacity in?
What a straight answer sounds like
A named unit, or an admission that it is a bare number.
Why it matters
A capacity of 200 that means pallets to the manager and cases to the storekeeper is worse than no capacity at all.
Which other settings here are recorded but not enforced?
What a straight answer sounds like
An honest list. Ours has five and they are published.
Why it matters
Every mature product has some. A vendor who can name theirs knows their own system; one who denies having any has not looked.
What AWRA OpsHub does today
- Locations as real records, with stock held per location rather than only per item.
- A capacity field you can set, which is retained and displayed accurately.
- Stock movements between locations with dispatch and receipt as distinct, signed steps.
- Per-location stock status — available or held, with a reason and a disposition.
What it does not do
- Capacity is never checked. No receipt, transfer or adjustment compares against it.
- No warning at any point, so exceeding it is not merely permitted but unremarked.
- No utilisation report, so how full anything is cannot be asked.
- No units on the capacity, so it means pallets to one person and cases to another, and nothing resolves the ambiguity — a problem the item master has too, since there is no unit of measure on an item either.
- No directed putaway — nothing suggests where to place arriving goods, and we are not a warehouse management system.
Not ours, by choice
- We publish no shipping or port figures for this region. That resupply is infrequent and space is scarce is a description of the operating environment, not a statistic we are sourcing.
- We are not claiming directed putaway is coming. It is a different category of product and we would tell you so rather than sell toward it.
Two, and neither is a warehouse management system
We would keep this modest deliberately. The value is in making a recorded number mean something, not in directing labour.
A unit on the capacity, and a utilisation view
Say what the number counts, then show how full each location is against it. This makes the existing field honest and answers the question people actually have, which is "where am I running out of room" rather than "stop me".
A warning on a movement that exceeds it
A warning rather than a refusal, deliberately. Goods that have physically arrived have to go somewhere, and a system that blocks the putaway of stock already on the floor gets worked around within a week — the same reasoning that keeps short deliveries reportable rather than blockable.
If somebody asks us for a hard refusal on capacity we would push back and explain why. A control that can be satisfied only by lying to the system produces worse records than no control at all.
Talk to us about warehouse constraintsTell us what arrives and how often
Volumes, intervals and how much room you actually have. We will be straight about which parts of the constraint we can help you see and which are yours to plan around.
Talk to us about stock locations