The Status That Was Deliberately Not Added
Receiving happens a delivery at a time, so an order can be half in. There is no half-in status, and that was a decision rather than an omission — because "part of it arrived" is already answerable from the receipts, and a fourth state would have to be chased through every place the third one is named.
The tempting fix is a new status. It is also the fix that quietly puts a new string into eleven places that were written when there were three.
For a long time receiving was a single act: an order arrived, somebody booked it in, and the whole chain closed in one motion. That worked because the system assumed one delivery for the full quantity — an assumption that is true of stationery and false of almost everything else.
Once deliveries could arrive in drops, the chain had to be driven by something else: not the act of booking a receipt, but whether the goods are all in. That is a small change in wording and a large one in behaviour.
What "all in" means, precisely
Every ordered line is compared against everything ever received against that order, and what remains is the outstanding quantity, floored at zero so an over-delivery on one line does not offset a shortfall on another. An order is fully received when no line has anything outstanding — and an order with no lines at all is never fully received, which is the safe direction for a record that should not exist.
That outstanding figure is computed in exactly one place and served to both receiving surfaces, the screen and the mobile endpoint. A receiver holding a phone and a receiver at a desk see the same number, because there is only one number. This sounds obvious and is one of the more common ways two-surface systems drift: the same calculation, written twice, diverging on the third change.
Two implementations of one figure will agree until the day it matters.
The status that was not added
The obvious design for partial receipt is a fourth status meaning partly delivered. It was considered and rejected, and the reasoning is the interesting part.
-
The existing status is matched by name in several places
Payment eligibility checks it, tracking status reads it, reporting groups by it. A new state means finding every one of those and deciding what it should do with the new string — and any one that is missed behaves as though the order is in none of the states it knows about.
-
The question is already answerable
"Has part of this arrived" is a fact about the receipts, and the receipts are there. A status would be a cached, denormalised restatement of something the underlying records already say, with all the usual risks of a cache nothing invalidates.
-
So the cost is real and the gain is nil
That combination is rarer than it sounds. Most feature decisions are a trade; this one was a cost with nothing on the other side, which is the clearest kind of decision to make and the easiest to get wrong by defaulting to more structure.
The general form of this
Before adding a state to an enumeration, ask two questions. Can the new state be derived from records that already exist? And how many places match the old states by name? Where the answers are yes and several, the new state is a liability rather than a feature — it will be right on the day it ships and wrong the first time somebody adds a screen that checks for one of the old values.
What happens when the last delivery lands
Four things, and one of them is a refusal to overwrite.
| What | Detail |
|---|---|
| The quotation is marked received | The sourcing document that produced the order is finished with. |
| The order is marked received — unless it is paid | A paid order stays paid. Payment before receipt is permitted where an organisation allows it, and overwriting the status here would lose that fact. |
| Shipping status and delivery date are set | Delivered, dated now — and this time observed rather than inferred, because it is the receipt that triggered it. |
| The request behind it is marked procured | Following the chain back through the sourcing document to the original request, so somebody who asked for something is told it arrived. |
And the whole thing is idempotent. Running it again on an order already marked as received changes nothing — which matters because a later receipt can still land against a completed order, where a tolerance allowed a small over-delivery through. Without that guard, the delivery date would be re-stamped by a receipt that arrived after the order was already finished.
The chain back to the request
Following the trail from a receipt to the person who originally asked is the quiet half of this, and it is the half most systems skip. A full receipt walks back through the sourcing document to the request behind it and marks that as procured. Where no such request exists — the order was raised directly — nothing happens. Where one is expected and cannot be found, a warning is logged and the receipt still completes, because failing to close a request is not a reason to fail a delivery.
Five questions to ask about partial receiving
Can an order be received in several deliveries?
A good answer sounds like
Yes, with outstanding tracked per line.
What ours actually is
Yes. Ordered, received and outstanding are computed per line from every receipt booked against the order.
Is there a partly-received status?
A good answer sounds like
Either yes, or a reason why not.
What ours actually is
No, deliberately. The fact is answerable from the receipts, and a fourth state would have to be handled everywhere the existing ones are matched by name.
Do the screen and the mobile app agree?
A good answer sounds like
One implementation.
What ours actually is
One implementation serving both, so a receiver cannot see a different outstanding balance depending on the device in their hand.
What closes the order?
A good answer sounds like
Full receipt, not the act of receiving.
What ours actually is
Every line at zero outstanding. Booking a receipt does not close anything on its own.
What if a receipt lands after the order is closed?
A good answer sounds like
Nothing is re-stamped.
What ours actually is
The completion is idempotent — a later receipt against a completed order leaves the delivery date as it was.
What AWRA OpsHub does today
- Receiving a delivery at a time, with ordered, received and outstanding computed per line from every receipt booked against the order.
- One implementation of that calculation serving both the web receiving screen and the mobile endpoint.
- Outstanding floored at zero per line, so an over-delivery on one item cannot offset a shortfall on another.
- Completion driven by whether every line is fully received rather than by the act of booking a receipt.
- An order with no lines never treated as fully received, which is the safe direction.
- Completion marking the sourcing document received, the order received, the shipping status delivered and the delivery date now.
- A paid order keeping its paid status through completion, so payment made before receipt is not overwritten.
- The chain followed back to the original request and marked as procured, with a missing request logged rather than failing the receipt.
- An idempotent completion, so a later receipt against an already-completed order does not re-stamp the delivery date.
More we can add to your workspace
- An expected date per delivery, so a partially received order can be chased on the drop that has not arrived rather than on the order as a whole.
- A supplier-facing view of what is still outstanding, so the other side sees the same figure the receiver does.
- Ageing on outstanding quantities, turning "still owed" into a list ordered by how long it has been owed.
- A recorded decision to close an order short, so a balance the supplier will never deliver is written off deliberately rather than left outstanding forever.
- A per-line receiving history on the order, showing which delivery brought which quantity without reading the receipts separately.
- A notification on each partial receipt rather than only on completion, for orders where the drops matter to somebody other than the receiver.
Where we point you to a specialist
- We will not add a status that restates what the receipts already say. A denormalised state is a second source of truth that has to be kept correct by every future writer, and the first one who forgets produces an order whose status and receipts disagree with nothing to reconcile them.
- We will not close an order because a receipt was booked. Completion is a fact about quantities, not about an action somebody took, and driving it from the act is what made partial deliveries impossible in the first place.
- Deciding that a supplier will never deliver the balance is a commercial judgement and stays with you. We will keep the shortfall visible and record whatever decision you take; writing off an outstanding quantity automatically would quietly close a claim you may still have.
Ageing on outstanding quantities is the contained piece most buyers want, because the figures already exist per line and what it adds is the ordering and the sense of time passing.
Chasing the drop, not the order
Partial receiving works and the outstanding figures are accurate. What buyers ask for next is the ability to chase a specific delivery rather than an order in general.
Expected dates per delivery
A schedule of drops against an order, so the one that is late is identifiable rather than the order being generally overdue.
Ageing on what is outstanding
Still-owed quantities ordered by how long they have been owed, which is the report that turns a list into a priority.
A supplier view of the balance
The other side seeing the same outstanding figures the receiver sees, so a chase starts from agreement rather than from a reconciliation.
We publish scope, not dates.
Scope receivingThe next time somebody proposes a status
Ask whether the records already answer the question, and how many places match the existing values by name. It is a two-minute conversation that has saved more systems than any amount of refactoring.
Talk through procurementFrequently asked questions
How do I see that an order is partly received?
From the receiving lines, which show ordered, received and outstanding per item. That is where the fact lives, and it is more useful than a status would be, because "partly received" tells you nothing about which items or how much — and those are the two things anybody chasing a delivery needs.
Why is there no partly-received status?
Because the fact is already answerable from the receipts, and the existing status is matched by name in payment eligibility, tracking and reporting. A fourth value would have to be handled in each of those, and anything missed would treat the order as being in none of the states it recognises. A cost with nothing on the other side of it.
Does booking a receipt close the order?
No. Completion is driven by whether every line has been fully received, not by the act of booking a receipt. That distinction is exactly what makes partial deliveries possible — the old behaviour closed the chain on the act, which is why a single delivery was the only shape that worked.
What happens if an order is paid before it is fully received?
It keeps its paid status through completion. Payment before receipt is permitted where an organisation allows it, and overwriting the status when the goods finally arrive would lose the fact that the money had already gone. The shipping status and delivery date are still set.
What if a supplier never delivers the balance?
The outstanding quantity stays outstanding until somebody decides what to do about it. There is no automatic write-off, deliberately — quietly closing a shortfall would remove a claim you may still have against the supplier. Ageing that outstanding list so the old ones surface is the piece named above.
Does the mobile app show the same outstanding figures?
Yes, from the same implementation. Both receiving surfaces call one calculation, so a receiver cannot be shown a different balance depending on which device they picked up. Two copies of the same figure is one of the most reliable ways a two-surface system drifts, and this is the place it would have hurt most.
