Skip to main content

What to do when a SKU is in the wrong storage location or container

Stop safely, collect evidence, and route SKU location or storage container mismatches without forcing risky inventory changes.

Written by Max Villemure

Quick answer

Use this article when a SKU is physically in one storage location, lot, or container but Logentic appears to expect another. The safe first step is to stop the affected workflow, identify the mismatch, collect evidence, and have a supervisor or Support confirm the correction path.

Common use cases

  • Associate: A pick, pack, replenish, receive, count, or scan step does not match the physical product location.

  • Supervisor: Decide whether the issue is a physical move, app-state mismatch, receiving/putaway mismatch, replenishment mismatch, or scan-code misunderstanding.

  • Support or CS: Collect enough evidence to route the issue without promising a state change too early.

Do this first

  1. Stop the current workflow if the app and physical product do not match.

  2. Identify what is wrong: product/SKU, barcode, storage location or lot, storage container, tote, quantity, warehouse, or active task.

  3. Capture the physical code, app-shown code, SKU, product, warehouse, quantity, workflow, and exact error.

  4. Ask a supervisor to check active picking, route picking, replenishment, receiving, cycle counts, inventory adjustments, back orders, and open orders before any correction.

  5. Resume only after the supervisor confirms that the app state and physical warehouse state match.

Associate guidance

  • Do not keep scanning replacement locations or containers if the expected code is unclear.

  • Do not adjust inventory, validate replenishment or receiving, release a tote or container, or switch to a different code unless a supervisor confirms.

  • Keep the current screen open when possible so the error and workflow context are preserved.

Supervisor checklist

  • Confirm whether this is a physical move request or an app-state mismatch.

  • Look up the product/SKU in Products and check on-hand, allocated, back-ordered, and active-work context.

  • Look up the tote or storage container code in Tote Manager when a container is involved.

  • Confirm the old code, new expected code, quantity, warehouse, reason, and approver before any state-changing correction.

  • After correction, verify product, container, replenishment, receiving, picking, and order queues before telling associates to resume.

Screenshots

Products dashboard filters used to find SKU and product context.

Screenshot: Product lookup entry point for reviewing SKU context before escalating a location or container mismatch.

Tote Manager header showing container lookup context.

Screenshot: Tote Manager is the safer place for supervisors or Support to look up a tote or container code before changing anything.

If route or iPad work shows the wrong SKU or location

If a route or iPad picking screen shows a style, SKU, product, location, lot, bin, or container that does not match what the associate expects, stop the route work and collect evidence before changing inventory or continuing the pick.

Do not continue if there is a wrong-product risk. A supervisor should confirm whether the issue is product setup, route setup, a location/container mapping problem, or a legitimate multi-SKU storage location.

  • Expected style, SKU, or product for the pick line.

  • Actual style, SKU, or product shown on the route or iPad screen.

  • Location, lot, bin, tote, or storage container shown in Logentic.

  • Physical location or container the associate expected to use.

  • Fulfill Orders view or filter used to create the route, if known.

  • Route ID, handling order ID, order number, or activity owner if visible.

  • Whether the warehouse expects that location/container to hold only one SKU or multiple SKUs.

  • Screenshot or screen recording of the current route screen, with private customer data removed before reuse.

Common issues and next actions

If this happens

What to do next

SKU is found in a different location or lot than Logentic shows.

Stop active work and capture old code, new physical code, quantity, warehouse, SKU, and screenshot.

Storage container code is unknown or unavailable.

Search the container if you have permission, then escalate with product, container code, workflow, and exact message.

Old scan or old location still appears after a correction.

Do not force a new scan. Capture the old and new codes and the workflow that still references the old state.

Active picking, route picking, replenishment, receiving, or order work depends on the old code.

Pause that work and escalate before changing inventory, validating tasks, or releasing containers.

If multiple SKUs appear mapped to one location

Multiple SKUs in one location can be valid for some warehouse setups, but it is a blocker when the team expects a one-to-one SKU, location, lot, or container mapping and the route shows the wrong product context.

  • Stop affected picking or route work until a supervisor confirms the expected storage setup.

  • Check whether the location/container is intentionally shared by multiple SKUs.

  • Compare the physical product, configured SKU/barcode, location/lot, and storage container before making any inventory or container change.

  • Escalate to Support if the app points the associate to one SKU while the physical location or route context suggests another.

Send us this information

  • Workspace/merchant and warehouse.

  • Product name, SKU, and barcode or scan code attempted.

  • Old location/lot/container code and expected new code.

  • Quantity affected.

  • Workflow where the mismatch appeared.

  • Related order, handling order, pick route, replenishment, receiving, cycle count, or inventory task.

  • Exact error message, timestamp, and screenshot with private data masked.

Related workflows

Did this answer your question?