When you confirm a draft sales order, OCTO Ops works out how much of each line can actually be met from stock, reserves that much against the order, and records anything it couldn't cover.
What counts as available
For each product on the order:
| Counted | What it is |
|---|---|
| Stock on hand | Every stock record for that product with a positive current quantity |
| less Reserved elsewhere | Quantities other confirmed orders are already holding |
Whatever is left is what this order can take. Two lines for the same product draw from the same pool — the first line is satisfied first, then the second takes what remains.
Choosing what stock to look at
Set this on Settings → Modules → Sales orders:
- Across all stores — everything the organisation holds, wherever it is. Right for a single-warehouse operation, and the default.
- One fulfilling store per order — each order names the store it will ship from, and only that store's stock counts.
- A store per order line — each line names its own store, so one order can draw from several warehouses.
For the last two you can also set a default fulfilling store, used whenever an order or line doesn't name one. If a line ends up with no store at all, that line simply isn't checked — it's better to say nothing than to promise stock sitting in the wrong building.
When there isn't enough
By default the order still confirms. Every available unit is reserved, and the rest is recorded as a shortfall against the line. Selling ahead of stock is ordinary business, and the order page shows what was reserved and what was short.
If you'd rather that stopped people, turn on Block confirmation when stock is short. Confirmation is then refused, the order stays in Draft, and the page lists each short line with what was ordered, what's available, and the gap.
Overriding a block
With blocking turned on, you can also decide whether anyone may get past it:
- Let administrators confirm anyway on — team Owners and Admins see a Confirm anyway button on a blocked order.
- Off — nobody can override. The only ways forward are to reduce the order or bring stock in.
Both confirmations and shortfalls are written to the order's audit trail either way.
When the check doesn't apply
Some lines are skipped rather than checked:
- Bundle headers. The bundle itself isn't a physical thing; its component lines are checked instead.
- Lines with no product, such as free-text or charge lines.
- Lines with no store, when you're using one of the per-store scopes and neither the line, the order, nor the default names one.
A skipped line is neither available nor short — it just wasn't assessed.
Three things this deliberately does not do.
It does not count stock you have on order from suppliers. Only stock physically on hand counts, so a delivery arriving tomorrow won't make today's order confirmable.
It does not physically hold the stock. Warehouse can still pick and issue stock this order has reserved, because the warehouse screens don't read these reservations yet. Treat a reservation as a record of what's been promised, not a lock.
A service sold as a product line will show as short, because products carry no "not stocked" marker. With the default settings that blocks nothing.
Releasing a reservation
A confirmed order shows its reservation state in the sidebar — fully reserved, partly reserved, or released — with the reserved and short quantities on each line.
Select Release reservation to give the stock back. It returns to the available pool immediately, so other orders can take it. The order itself is unaffected: the line quantities, totals and status all stay as they were.
The shortfall figures stay on the order too. That a confirmation couldn't be fully met is a record of what happened at the time, not part of the holding, so releasing doesn't erase it.
Releasing an order that has nothing reserved is refused rather than quietly doing nothing — including a second click on an order you've just released.
Releasing does not cancel the order. The order stays confirmed and can still be fulfilled; you've only given up its claim on stock.
When reservations expire
Reservations expire after the number of days set on Settings → Modules → Sales orders, counted from when the order was confirmed. A daily job releases anything past its date, and the stock goes back into the available pool.
An expired reservation looks exactly like one released by hand — the order reads Reservation released, and the reserved quantities go to zero.
Set the setting to 0 if reservations should never expire on their own. Existing reservations made under a different setting keep the expiry date they were given.