Module settings#
How the warehouse behaves as a whole. You will find it under Warehouse → Settings.
What is set here#
| Setting | What it affects |
|---|---|
| Base currency | what purchase prices and margins are kept in |
| Allow negative stock | whether the quantity may fall below zero |
| Allow partial reservation | whether an order without full cover may go through |
| Reservation validity in minutes | how long before an unconfirmed reservation is released |
| Recount batch size | how many cards the nightly recount handles at once |
| Stale reservation alert (days) | after how many days to report a reservation that is hanging |
| Batch expiry alert (days) | how many days ahead to report an approaching expiry |
| Low-stock email | where the overview is sent |
| Closure notice lead time (days) | when the site starts showing that a warehouse is closed |
Negative stock#
The module's most consequential option.
| On | Off |
|---|---|
| the quantity may go negative | the quantity never drops below zero |
| suits made-to-order goods | suits everything else |
On means promising what you do not have
The customer orders, pays, and then you find the goods are not there. Switch it on only for a range you genuinely restock on demand.
Partial reservation#
A customer purchase does not have it, and should not
The e-shop checkout requires full cover — a customer must not pay for uncovered goods. This option is for routes where a human decides about cover. Switching it on means you take responsibility for the order being fillable.
Reservation validity#
Entered in minutes.
Align it with the e-shop's payment window
If a reservation is released before the order expires, the same goods can be sold twice — and the second customer pays for something that is gone. The opposite mismatch is merely inefficiency. The payment window is in the e-shop settings and is entered in hours — convert before comparing.
Releasing runs every 5 minutes, not at the moment of expiry
A reservation therefore outlives its validity for a while. Do not set values that need to be accurate to the minute.
Alerts#
Three separate alerts, each with its own lead time:
| Alert | When it speaks up |
|---|---|
| low stock | based on the minimum quantity on the card |
| batch expiry | the set number of days before expiry, every morning |
| stale reservations | reservations hanging longer than the set number of days |
The expiry alert does not remove the batch
It only warns. An expired batch stays in the records and is written off normally — removing it is a manual issue note.
Do not set alerts to daily
People stop reading daily messages. An overview timed for the day before you order from your supplier is more useful.
Warehouse closures#
The lead time decides when the site starts showing that a warehouse is closed.
A closure shifts the DISPATCH day, not the transit time
Delivery estimates lengthen by however much dispatch is delayed. For goods held in two warehouses the faster one can be the one that is not closed — even with a longer stated lead time. See Closures.
The nightly recount#
The batch size decides how many cards one run handles.
Without the nightly recount, drift in the reserved quantity is never corrected
The reserved quantity is a stored number, not a computed one. A failure mid-operation can leave a reservation without an order — the physical figure then adds up, the available one does not. Only this run repairs it. Check with your administrator that the task is running.
Walk a test order after every change#
The options only show up across a whole run
Negative stock and reservation validity only reveal themselves on a real order. After every change, walk one from the cart to dispatch and check that the quantity moved where it should have.
Where to go next#
- Stock cards · Reservations · Documents
- Warehouses and batches · Closures
- E-shop settings — where the payment window lives