Quick answer
When warehouse work is blocked, report the workflow, current screen, exact message, and the last scan or action before changing anything. The goal is to preserve enough context for a supervisor or support to identify the blocker safely.
Common use cases
Picker or packer: A tote, product, barcode, route, or batch step is blocked.
Receiver: A receiving order, lane, container, quantity, or validation step is blocked.
Inventory associate: Replenishment, adjustment, bin, pallet, or product work cannot continue.
When to use this
The app rejects a scan or code.
The expected order, product, tote, container, bin, route, or task is missing.
A workflow shows an error that does not explain the next action.
The physical work and the app state do not match.
Before you start
Do not repeat the same scan many times if it keeps failing.
Do not change inventory, release holds, discard records, or resolve exceptions just to clear the blocker.
Keep the screen open when possible so the exact state is preserved.
Steps
Identify the workflow: picking, packing, replenishment, receiving, inventory adjustment, route, batch, or exception review.
Capture the current screen and exact error message.
Write down the order, activity, route, batch, receiving order, SKU, product, tote, container, bin, or pallet involved.
Record the last scan or action before the blocker appeared.
Check whether manual entry behaves differently from scanner entry when scanning is involved.
Escalate to a supervisor or support with the evidence checklist below.
Screenshots
Screenshot: Use Fulfill Orders context when the blocker happens during pick, pack, route, or batch work.
Screenshot: Use receiving validation context when the blocker is tied to receiving work or downstream inventory availability.
What good looks like
Support receives enough context to reproduce the blocker, identify the correct owner, and avoid asking the associate to repeat risky actions.
Common issues and next actions
If this happens | What to do next |
A scan is rejected. | Confirm the code type expected by the screen and include the exact scan input if safe to share. |
The expected work is missing. | Check warehouse, merchant, filters, and workflow tab before assuming the work disappeared. |
The app error is technical or unclear. | Do not guess. Capture the exact message and timestamp. |
Contact us when
Contact support when the blocker stops active warehouse work, the next action is unclear, or changing state could affect orders, inventory, receiving, route work, or customer commitments.
Send us this information
Workspace or merchant.
Warehouse.
Workflow: picking, packing, replenishment, receiving, inventory adjustment, route, batch, or exception.
Order, activity, route, batch, receiving order, product/SKU, tote, container, bin, or pallet.
Exact error message and timestamp.
Recent scan/actions before the blocker.
Screenshot with private customer data masked.
Location or container mismatch
If the physical SKU, storage location or lot, and container code do not match what Logentic expects, treat it as a warehouse state blocker. Stop the workflow, preserve the screen, and route the evidence to a supervisor or Support before changing inventory or container state.
Route SKU/location mismatch
If an iPad or route screen shows a style/SKU that does not match the expected location, lot, bin, tote, or container, stop affected warehouse work and report it as a SKU/location/container mismatch.
Include expected versus actual style/SKU.
Include expected versus shown location/container.
Include route, handling order, Fulfill Orders view/filter, screenshot, timestamp, and whether the location is expected to hold one SKU or multiple SKUs.
Use the wrong storage location/container guide for the full evidence checklist.