Background Schedulers
Five jobs run on their own every day, on a fixed timetable. You don't open a screen and press "start" — you mostly see and act on the records they leave behind.
Nothing on this page corresponds to a page under /staff that you click into. Each job is a scheduled command that runs unattended on the server. Your involvement is upstream (setting the kill-switches in System Configuration) and downstream (working the sale orders, picking waves and bank statements the jobs produce or touch).
The daily timetable
The five jobs run in this order every day. Reservation runs first because everything else in despatch depends on stock having been set aside; wave creation follows an hour later so it only ever groups moves that are already reserved. The despatch safety net runs two hours after that, checking for anything reservation should have picked up but didn't.
Reservation itself has nothing to do if no one has created stock moves to reserve — that's the job of Release for despatch, a console action rather than a scheduled job. See the callout below the timetable for how the two connect.
The chain that starts with an approved order and ends with a despatched package now runs all the way through: Release for despatch (a Products row action, stock_move.create — see Products) creates Confirmed delivery stock moves → air:auto-reserve reserves them → air:auto-wave groups them into picking waves → waves become packages and go out for despatch. Release is a manual console action, not a scheduled job; the five jobs on this page are what carries a released move the rest of the way automatically.
Auto-reservation Built
Command air:auto-reserve, runs daily at approximately 02:00.
It scans confirmed delivery stock-moves and, in priority order, does one of two things for each: reserve the available stock (moving quantity from available to reserved), or — if the customer fails credit control (credit limit exceeded, or an earlier payment hasn't settled) — hold the move under a suspend reason instead of reserving it. A warehouse or carrier can opt out of this entirely; any move at a location or carrier whose allow_autoreservation flag is off is skipped and left for manual handling.
Controlled by the reservation.enabled switch in System Configuration. Turn it off and the job still runs but does nothing.
There is no standalone stock-move screen in this console, so you observe reservation indirectly: the qty_reserved column on Stock on hand rises for the products it touched, and — an hour later — the moves it reserved start appearing grouped into new picking waves (below).
Auto-wave creation Built
Command air:auto-wave, runs daily at approximately 03:00, after reservation.
It groups reserved delivery moves that aren't yet part of a wave by location, carrier, product category and product timeline, and turns each group into a picking wave — batches of up to 500 moves per wave, with a solo wave carved out for any single large-quantity move (more than 50 units). A move with no carrier assigned is skipped rather than forced into a wave.
Controlled by the wave.enabled switch in System Configuration.
The waves it creates land in Picking Waves at Draft / Items Identified, ready for despatch staff to print labels, pack and send them on.
Despatch safety net Built
Command air:despatch-safety-net, runs daily at approximately 05:00, after auto-wave and before the health check.
This job is a safety net, not a producer — it never creates a stock move itself. It looks for order lines that should have a move by now and don't: any line on an order that is ApprovedForDespatch, whose product is flagged to be considered for despatch, that still has no stock move at all. Each one it finds is logged as a dropped record (so it's possible to review the specific line later), and the scheduler run is marked Warning if it found anything, Success if it found nothing.
In the normal flow, Release for despatch creates the move for every eligible line the moment a product is released. This job exists to catch the exceptions — a release that was never triggered for a product, or one whose queued job failed partway through — before they sit unnoticed for days.
Finding an orphan line here does not create the missing move. If you spot a Warning run, the fix is to release the affected product again from Products — re-releasing is safe and only ever picks up lines that still don't have a move.
Gateway settlement bifurcation Built
Command air:bifurcate-settlements, runs daily at approximately 07:00.
Online-gateway settlements (Razorpay, CCAvenue) arrive as one lump sum covering many customer payments. This job splits a bank statement's gateway settlement lines back into the individual payment vouchers they represent, so each customer's payment can be reconciled on its own. See Bank Reconciliation for the statement screen this feeds.
Health check Built
Command air:health-check, runs daily at approximately 06:00.
Records a snapshot of overall system health. There is nowhere in the console to view this snapshot yet — see Diagnostics below.
Reviewing what the schedulers did
Every run above is recorded and can be reviewed in the console. The Administration → Diagnostics screens (gated diagnostics.view) show Scheduler Runs (each run's status + processed/skipped/failed counts), Dropped Records (exactly what each run skipped and why — e.g. the despatch safety net's orphan-line log or a credit-held reservation), and Health Check Results (the latest health-check output). See the Diagnostics page.