Replenishment
Overview
Replenishment moves goods from reserve to the picking bin before someone reaches into an empty one.
It is deliberately a task, not merely a suggestion list: a suggestion is a calculation that changes with every look. The moment somebody sets off, the work needs a state — otherwise two people walk the same aisle and the second finds an empty shelf.
The task records the route as it was when the task was created: source and target bin with their codes, not just an internal id. The code is what gets scanned on the device — a bin renamed in the meantime must not make a running task unreadable.
Two places, one job: it is started and overseen at the desk, walked and confirmed on the device.
Core tasks
Start a run. Generate suggestions turns the replenishment rules of Multi-warehouse into tasks — from the screen across all warehouses; only the interface narrows this to a single one (warehouseId). Two limits are built in: tasks are created only for bin-based rules with an available source bin, and a target that already has an open task does not get a second one.
Keep an overview. The list shows article, route, suggested and moved quantity, status and the creation date. On screen it filters by status; by warehouse only through the interface (warehouseId).
Confirm on the device. Three scans in the order of the walk: source bin (I am in the right place) → product (I have the right thing) → target bin (I put it in the right place). Every scan must belong to the task; the quantity may be smaller, never larger than the one proposed.
Cancel. With a note — why the route is not being walked. Because the need went away, for instance, or because the goods were found elsewhere.
Fields in detail
Replenishment tasks are calculated, not entered: they arise when a picking location falls below its minimum while stock is still lying in the reserve store. The task itself therefore has not a single editable field — writing happens only through the three actions generate, confirm and cancel.
The task (display)
| Field | Values / format | What it means |
|---|---|---|
description | article name | What is to be moved. |
sourceBinCode → targetBinCode | bin codes | The route as it was when the task was created. The code is recorded, not just the internal id: a bin renamed in the meantime must not make a running task unreadable. |
qtyRequested | pieces | The suggested quantity — calculated from the target bin's minimum and target level. |
qtyMoved | pieces | What was actually moved. Only filled in after confirmation. |
sourceQtyNow | pieces | What really lies at the source bin at the moment of the query. On the device, the preview before you reach in. |
status | open · done · cancelled | Open, done, cancelled. A task that is not open accepts neither confirmation nor cancellation. |
note | text, max. 255 characters | The reason given when cancelling. |
createdAt / completedAt | timestamp | When it was created and when it was closed. |
warehouseId / productId | id | Warehouse and product of the task. |
Confirming on the device
These four entries are the inputs of an operation, not properties of the task: they are scanned and checked, not stored. Scanning follows the order of the walk.
| Element | Required | Values / format | What it does |
|---|---|---|---|
Scan the source bin sourceBinCode | yes | bin code | "I am in the right place." A bin other than the task's is rejected. |
Scan the article productCode | yes | barcode, SKU or packaging code | "I have the right thing." The code is resolved and must lead to the product of the task. |
Quantity moved qty | yes | whole number ≥ 1, at most the suggested one | What was actually moved. Less is allowed, more is not — more would be a stock question, not a replenishment question. |
Scan the target bin targetBinCode | yes | bin code | "I put it in the right place." |
The confirmation runs through the scanner queue and is nameable (X-Idempotency-Key): after a radio blackout the device may repeat without moving stock a second time. Warehouse stock never changes in the process — only its distribution.
Cancelling
| Element | Required | Values / format | What it does |
|---|---|---|---|
Why is this route not being walked? note | no | text, truncated to 255 characters | The reason stays on record with the task. The next run creates it again if the bin keeps running dry — cancelling means "not now", not "never". |
Settings & permissions
- Module
module.wms. wms.replenishment.view— see tasks. Pre-assigned to the role Umsetzung.wms.replenishment.execute— create, move and cancel tasks.- Deliberately separate from
wms.pick.viewandwms.pick.execute: replenishment is different
work in a different place — reserve area, often a forklift, often a different shift. Whoever picks need not be allowed to move pallets, and vice versa.
- No brand. Replenishment is a movement inside one warehouse: no customer, no document, no brand.
Access hangs on the right alone.
- The rules themselves (min/max per warehouse and product) live in
FAQ & troubleshooting
The run creates no tasks. Three possible reasons: no rule is below its minimum, the rule is not bin-based, or there is no source bin holding stock. For a target that already has an open task, no second one is created on purpose.
The scan is rejected. Bin or product does not belong to this task. The device shows the match before you submit — in the aisle an error message afterwards would come too late. The server's check remains the binding one.
The full quantity cannot be confirmed. Less is allowed, more is not. If there was less than expected, confirm the actual quantity — the difference is a stock question, not a replenishment question.
The task can no longer be confirmed or cancelled. Then it is no longer open: somebody else was faster. Both actions re-check the status under a lock — otherwise the second device would book the same quantity a second time.
Then what is the free transfer for? Replenishment is planned work and rejects any scan that does not match the task. The free transfer at the scanner is the other direction: there the person at the rack decides.