Planned relocation in the client app
This document covers the end-to-end flow for planned relocations in the client app — from creating the document with its plan rows through closing it. The planned scenario reserves goods at sources and creates incoming-stock records at targets, preventing other operations from competing for the same stock while the relocation is open.
To record a move that has already happened without a plan, see Ad-hoc relocation.
Phase 1. Applicability context
A planned relocation is created when a supervisor or planner knows in advance what to move, from where, and to where. The system reserves the quantity at the source and creates an incoming-stock record at the target — between the moment the plan is saved and the moment a physical move actually happens, no other operation can consume the reserved goods or compete for the target slot.
Use planned relocation when there is time to think through the move before doing it: consolidation work, replenishment of pick faces, rebalancing storage zones, or any move scheduled to be executed by a specific operator. If you want to record a move that has already happened — there was no plan — use the ad-hoc relocation flow instead.
Phase 2. Creating and editing the plan
The planner starts from the Relocations list and presses the + floating action button — the detail screen opens in Add mode.





General tab
On the General tab the planner fills the warehouse, optionally an executor and notes, and a document date. The Ad-hoc checkbox must stay unchecked — leaving it checked produces an ad-hoc document instead, with no plan.
Adding rows
On the Plan tab the planner adds rows one by one. Each row carries: the source (kind + cell or container), the target (kind + cell or container), the product, optional product feature and lot, and the quantity. If the goods need a pack-type change, the planner sets a different target pack type — see below.






Each relocation row describes what, from where, and where to you move.
The source and target of a row are each one of two kinds — a cell or a container — giving four combinations:
Cell → Cell — the most common case: moving goods between storage areas (for example, consolidating partial pallets from a pick face into a reserve aisle).
Cell → Container — packing goods from a cell into a container (for example, to stage a shipment or to move loose goods on a carrier).
Container → Cell — unpacking a container into storage cells (for example, breaking down a received pallet onto the rack).
Container → Container — moving the contents from one container to another (for example, consolidating two half-full bins).
Pack-type change (repack)
A row may also change the pack type of the goods: the source pack type and the target pack type differ, while the quantity in the base unit of measure stays exactly the same.
Example: a product is stored as cases of 12 units. You want to put it on pallets of 144 units. In a single row you set the source pack as "case" (source quantity = 12 cases), the target pack as "pallet" (target quantity = 1 pallet), and the base quantity stays 144 units.
Repack is available in both planned and ad-hoc scenarios — it is a property of an individual row, not of the document.






What saving does
When the planner saves the document into the Planned status, the system:
- Reserves the row quantity at each source — so other operations cannot consume the same goods until this relocation is closed or cancelled.
- Creates an incoming-stock record at each target — so other operations know the target cell or container has goods en route.
These bookkeeping records are released as facts accumulate against the plan (see Recording move facts) and on document closure (see Closing the document).
Editing the plan after save
While the document is in Draft or Planned status, the planner can re-enter Edit mode from the detail screen and modify rows, change the assigned executor, or update notes. Once the first fact is recorded the document moves to In progress — at that point row-level editing is no longer possible; only assignment and notes can still be updated.
Phase 3. Recording move facts
The operator opens the document and switches to the Execution tab. The + action opens the fact dialog.
Fact entry cycle
For each fact:
- Pick a plan row — the dialog lists the rows of the plan; the operator selects the one being executed.
- Fill the actual source and target — by default the dialog pre-fills source and target from the plan, but the operator can record different ones (the system always trusts the actual move, not the planned one).
- Enter the quantity — full or partial; multiple facts per plan row are allowed (for splitting the moved quantity across two cells, for example).
- Save — the fact is committed.
The row dimensions (source kind, target kind, optional repack) work the same way for facts as for plan rows:


Each relocation row describes what, from where, and where to you move.
The source and target of a row are each one of two kinds — a cell or a container — giving four combinations:
Cell → Cell — the most common case: moving goods between storage areas (for example, consolidating partial pallets from a pick face into a reserve aisle).
Cell → Container — packing goods from a cell into a container (for example, to stage a shipment or to move loose goods on a carrier).
Container → Cell — unpacking a container into storage cells (for example, breaking down a received pallet onto the rack).
Container → Container — moving the contents from one container to another (for example, consolidating two half-full bins).
Pack-type change (repack)
A row may also change the pack type of the goods: the source pack type and the target pack type differ, while the quantity in the base unit of measure stays exactly the same.
Example: a product is stored as cases of 12 units. You want to put it on pallets of 144 units. In a single row you set the source pack as "case" (source quantity = 12 cases), the target pack as "pallet" (target quantity = 1 pallet), and the base quantity stays 144 units.
Repack is available in both planned and ad-hoc scenarios — it is a property of an individual row, not of the document.
Stock-balance check
When saving a fact, the system checks the current quantity at the source. If there is not enough — a localized error appears (the partial fact is not persisted; the operator must reduce the quantity or fix the source).
Status auto-transition
The first fact saved against a document moves it from Planned to In progress automatically. Subsequent facts keep the document in In progress until the operator closes it.
Toolbar actions
The ⋮ menu on the detail screen exposes secondary actions: History (audit log), Print (print forms), and Movements (related stock-ledger transactions for this document). See the general client-app screen documentation for details — these actions are not specific to relocation.
Phase 4. Closing the document
The operator closes the document from the detail screen. Three actions are available, depending on the state of the work:
- Complete — when every plan row has been fulfilled. The document moves to Completed.
- Close partially — when some quantity remains unplaced. The document moves to Partially completed; the unplaced quantity stays physically where it is; reservations for the unplaced portion are released.
- Cancel — available while the document is in Draft, Planned, or In progress. Cancellation releases the remaining reservations and incoming-stock records; facts recorded before the cancellation stay posted — the goods remain where they were actually moved.



Effect on cell state
A Close partially action has a side effect on the source cells whose work was not fulfilled: each such cell is given the Count required status in the Inventory state section of the cell. Warehouse staff are then expected to verify the actual quantity in those cells — the system no longer assumes the booked quantity matches reality.
Reservations and stock
On any closure path, reservations covering not-yet-completed quantity are released automatically; the executed quantity is debited from the source and credited to the target. Operators do not manage these records directly.
For the full list of statuses and what each one allows, see Relocation statuses.