Skip to main content

Returning a task to the pool

Use this when a task sits with an operator who is not doing it. The operator left, forgot it, or went on leave with the task still open. You take the task away and it goes back to the pool for anyone to pick up at once.

Before you start​

  • You need the role ADMIN, MANAGER or SUPERVISOR, or a role where an administrator granted the method task_force_release. See Who can do what.
  • The task must be Assigned or InProgress.
  • The task must not be in a live pick assignment. Dissolve the assignment instead. See Dissolving a pick assignment.

Steps​

  1. Open Task Manager > Task Board.
  2. Find the task. Use the filters, for example Assignee or Status.
  3. Tick the check box of one task. Return to Pool turns on only for Assigned or InProgress.
  4. Click Return to Pool. The window Return Task to Pool opens.
  5. Type the reason in Reason. Do not leave it empty. Use 80 characters or fewer.
  6. Click Return to Pool in the window.

What happens​

On success the window closes and the grid is read again. The message is Task {code} returned to the pool. The task row now shows:

ColumnValue
StatusCreated
Assignee, Claimed, Started, Lease ExpiresEmpty
Return ReasonThe text you typed
How ReturnedSeized
Qty DoneUnchanged. The work done stays done.
Refusals, EscalatedUnchanged
Available FromEmpty. A supervisor's return starts no cooldown. The task can be taken at once.
VersionUp by one

The command writes your user as the one who changed the row. It writes no line in the audit log, and the reason text is erased when the next operator takes the task. Source: crates/libs/wms-lib-core/src/model/tasks/task.rs:1649-1708 and the comment of TaskError::ReasonRequired in crates/libs/wms-tasks/src/error.rs.

The return does not write a line in Skip History. That list shows only operator refusals and hand backs.

If it is refused​

The failure message is Task {code} could not be returned to the pool: {error}. The window stays open. The grid is not changed.

You see (the {error} part)WhyWhat to do
version conflict on task {id} (current version {n})The task changed after you read the board. Return code 40.Close the window, press the grid refresh, tick the task again and retry.
task {id} is in status {status}, this action does not applyThe task is not Assigned or InProgress any more. Return code 70.Read the board again.
task {id} cannot change hands: PICK_ASSIGNMENT_LIVEThe pick is in a live pick assignment. Return code 70.Dissolve the pick assignment.
task {id} cannot change hands: SERIAL_EPISODE_OPENThe operator has a serial scan open and the SKU rule is Block. Return code 70.Wait until the scan is finished, or change the SKU rule.
task {id} cannot change hands: SERIAL_EPISODE_ABANDONEDAn abandoned serial scan holds the task. Return code 70.A supervisor must close the scan first.
skip_reason is too long: {n} chars, max 80The reason is over 80 characters.Shorten it.
task {id} not foundAnother user deleted it.Read the board again.
Select exactly one taskNot one row ticked.Tick one row.
Say why the task is being returned to the poolThe reason is empty.Type a reason.
The task board has moved on — reselect the task and try againThe ticked row is not on the board any more, or its version is not known.Refresh and tick again.

Sources: crates/libs/wms-tasks/src/service/release.rs:296-370, crates/libs/wms-tasks/src/error.rs, crates/libs/wms-outbound/src/picking/infrastructure/holder_change.rs:74-83, 062_receipt_and_task_use_rpc_command.sql:100-150.

What it affects​

  • The old holder's terminal no longer has the task. A later report from the old holder is refused.
  • The task is offered again to operators who have the right and the equipment for it.
  • For a Count task, the count rules never refuse a return to the pool. Only a reassign can be refused by them. Source: crates/libs/wms-inventory/src/domain/inventory_count/task_manager.rs:109-127.