Where replenishment tasks come from

Every task has a reason explaining why it appeared.

1. Manual (manual)

A supervisor creates a task in the Panel. The destination shelf is optional; if omitted, the operator scans one when putting the goods away.

2. Recommendation scan (pick_face_empty, pick_face_low, reslotting, directed)

Use Scan warehouse in the Panel. By default this is a dry run: it returns suggestions without saving anything. Tasks appear only after you accept suggestions, or run a saving scan that requires a separate permission.

The scan makes two passes:

• Demand — for every active pick face, compare stock with the min threshold. Empty gives pick_face_empty; below threshold gives pick_face_low. Replenish to max.
• Class relocation — class A products belong in the golden zone, B in mid, C in reserve. A product outside its zone gets a move suggestion (reslotting). If a supervisor narrows the scan with zone filters, the reason becomes directed.

Suggestions are sorted by urgency: days of coverage, rate of depletion, ABC class, travel cost, then how far the location is from its zone.

Limits prevent flooding: by default 100 tasks per scan and 200 open tasks in total.

3. Order demand (order_demand)

An order enters WMS Replenishment when the stock exists in the warehouse but not in the picking path. The system then creates a task to move it where a picker can find it.

This is reconciliation, not accumulation. Each run compares open tasks with actual demand, so the same shortage will not create duplicate tasks even if the process runs ten times.

This can be disabled per picking scenario. The order then waits in WMS Shortage and no move task is created.

A pallet parked beneath a rack is reserve stock, even in a picking aisle. No one picks from a pallet (its type does not have the “picking” flag), so the planner treats it as reserve regardless of the rack zone and creates a “pallet → shelf” task. Previously, a pallet under a rack in the PICKING zone was invisible from both sides: the queue could not pick from it, while the planner thought stock was already in the picking zone. A picker’s cart has the same flags but is not parked on a shelf; it is with the employee or at a packing station. Its goods never become a source.

Orders with one unavailable line still get tasks for available lines. Previously, a single line with no stock anywhere made the planner skip the entire order, including lines sitting in reserve. The order waited in WMS Replenishment with no tasks and could never leave: release required all lines covered, but the zero-stock line could never be covered. Now tasks are created for lines that can be moved, and scenarios that allow shortages release the order after those goods arrive.

Stale tasks are withdrawn. On each run, the planner removes New tasks nobody needs anymore — if all orders in a task note are cancelled, the line no longer exists, nothing needs shipping, or the line has been fully picked. Previously, these tasks stayed on the kiosk forever.

Withdrawal does not apply to:

• In progress tasks — someone is carrying them; they are not taken away;
• orders that merely left the WMS Replenishment status (released, queued, not yet handled);
• bulk tasks with a truncated note that cannot list every order.

Anything still needed is planned in the same run.

A task follows the goods when its source shelf empties. If stock is moved off the source shelf (for example, a pallet is “shortened”), counted to zero, or removed by another route, the next run checks every New task. If no free stock remains, the task is withdrawn; if less remains than planned, the quantity is reduced to what is available. The planner immediately creates a task for the missing quantity from where the stock is now. Previously a task could hang on an empty shelf while an order waited for someone to cancel it manually. In progress tasks are different: if the shelf is empty, the worker uses Report shortage.

An order line that lost its queue shelf also requests a move. An order already in a queue will never enter WMS Replenishment, so the task refreshes its location — if the queue has replenishment for missing locations enabled. It uses the same reason (order_demand) so both triggers share one pool and do not move the goods twice.

A “last chance” shelf does not replace replenishment. If a picking scenario has a last-chance area — SIIN uses the shop — the queue sends the picker there only when moving stock can no longer help. While stock remains in reserve, the line has no shelf and a task is created, rather than routing the picker to the shop. This works both ways: a line sent to the shop because the pick face was empty returns to the picking shelf once stock arrives. If the planner says there is no source to move from (for example, a source-zone filter excludes it), the line does get the last-chance shelf; otherwise it would wait forever.

4. Scheduler (scheduler)

A nightly system job runs shortly after 1:45 each day, with a random delay so companies do not all start at once. It runs, in order:

1. ABC reclassification from order history — on by default;
2. automatic location zoning — on by default;
3. scan that creates tasks — off by default. This is deliberate: tasks created without anyone’s knowledge would leave an unrequested list in the morning.

The nightly scan is attributed to the first active company administrator. If the company has none, the log says the scan was skipped.

5. Self-service (self)

An operator creates a task from the terminal when they see a need. Requires self_replenishment permission. See Replenishment on the terminal — how work flows.

6. Consolidation (consolidation)

Collect individual units scattered around a zone into one place. This is the only reason that permits putting goods on a shelf that is already occupied — Why the system rejects this destination shelf.