Ad-hoc relocation in the client app
This document covers ad-hoc relocations in the client app — recording a move that has already happened, without a plan upfront. No reservations or incoming-stock records are created; the system assigns the final status automatically based on the recorded facts.
To plan a move in advance and reserve stock for it, see Planned relocation.
Phase 1. Applicability context
An ad-hoc relocation records a move that has already happened, without a plan upfront. The document is created with the Ad-hoc flag set; facts are then added directly; the system moves the document to Completed automatically once facts are saved. No reservations are made, no incoming-stock records are created.
Server grouping note
To reduce document noise, the server groups ad-hoc facts that share the same executor, warehouse, and hour of day into a single document. When the operator saves a new ad-hoc fact, the server may attach it to an existing ad-hoc document instead of creating a new one — if such a document is found that meets all three conditions and was opened earlier in the current hour. The result is the same from the operator's point of view (the move is recorded) but the document list shows one entry per operator-hour rather than one per fact.
When to choose planned instead
If the move is known in advance — a planned consolidation, a replenishment run, an assignment to a specific operator — use the planned relocation flow so the system reserves stock and prevents conflicts.
Phase 2. Creating the ad-hoc document
The operator opens the Relocations list and presses the + floating action button — the detail screen opens in Add mode.
General tab
The operator fills the warehouse and checks the Ad-hoc checkbox. Notes and document date are optional. Executor assignment is not used in this scenario — facts are tied to whoever records them.
Plan tab
The Plan tab stays visible but empty in this scenario — an ad-hoc document has no planned rows; the operator works on the Execution tab from the start.
Saving the document
On save the document is created. The system then waits for the first fact: as soon as the operator records a move on the Execution tab (see Recording move facts), the document automatically transitions to Completed.
Phase 3. Recording move facts
The operator opens the document and switches to the Execution tab. The + action opens the fact dialog.
Fact entry
Unlike the planned scenario, there is no plan row to pick from — the operator builds the whole row from scratch:
- Source — kind (cell or container) and the specific identifier.
- Target — kind (cell or container) and the specific identifier.
- Product — chosen from the catalog or by scanning; optional product feature and lot.
- Quantity — full or partial; optional pack-type change (repack).
- Save — the fact is committed.
The row dimensions work the same way 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
The same source-quantity check applies as in the planned scenario: if the source does not hold enough goods, a localized error appears and the fact is not persisted.
Auto-completion
The operator does not press a Close action — after the fact is saved the system moves the document to Completed automatically. To record another ad-hoc move the operator simply creates another document (see Creating an ad-hoc document); the server may attach the new fact to an existing same-hour document of the same operator and warehouse, transparently.