Quick answer

If a scan fails, pause and confirm what type of code the workflow expects. Logentic may require the configured product barcode, scan code, tote code, bin code, or another warehouse code; do not assume the visible SKU is always the accepted scan value.

Safe stop/escalate checklist

Start here: Start on the screen where the scan failed, then identify whether the workflow expects a product, SKU, barcode, tote, container, bin, or location code.
Do this first: Try to identify the expected code type before retrying. Scan the configured product barcode or scan code when product matching is involved; do not assume the visible SKU is accepted.
Stop if you see these states/errors: Stop when scanner and manual entry both fail, the app says the scanned code does not match available products, or the same tote/container code keeps failing.
Who owns the blocker: Associate: stop retrying and preserve the screen. Supervisor: confirm code type and workflow context. Support: investigate setup or workflow state. Product/Engineering: clarify accepted scan values or repeated scan errors.
What evidence to send: Workspace, warehouse, workflow screen, order/activity/route if relevant, physical code scanned, exact scan input if safe, product/SKU/barcode/tote/container code, error copy, screenshot, timestamp.

Common use cases

Picker: A tote, product, barcode, SKU, or route scan is rejected.
Warehouse lead: Confirm whether the team is scanning the correct physical code.
Support: Collect enough evidence to identify whether the blocker is setup, hardware, or workflow state.

When to use this

The app says the scanned code does not match available products or expected work.
A tote, bin, SKU, barcode, product, or route scan is rejected.
Manual entry returns the same error as the scanner.

Before you start

Confirm the operator is in the correct workspace, warehouse, and activity.
Confirm whether the workflow expects a tote, product barcode, SKU, bin, location, or route-specific code.
If available, test manual entry carefully to separate scanner hardware issues from code/setup issues.

Steps

Stop retrying the same value repeatedly if the app rejects it.
Confirm the current workflow step: tote scan, item scan, bin/location scan, route scan, or packing scan.
Compare the physical label with the code type your workflow expects.
If the product is involved, scan the configured product barcode or scan code rather than assuming the visible SKU is accepted.
If the tote is involved, confirm the tote or container exists and matches the workflow.
If manual entry and scanner entry both fail, collect the support evidence below.
If only scanner entry fails, check scanner setup and keyboard input behavior before escalating.

Screenshots

Tote Manager page header used for tote-based picking and packing context.

Screenshot: Use tote setup context when a tote or container code is rejected during picking, packing, or route work.

What good looks like

The team identifies whether the rejected scan is caused by the wrong code type, a missing product/tote setup, scanner behavior, or a workflow state issue.

Common issues and next actions

If this happens	What to do next
The visible SKU is rejected.	Use the configured product barcode or scan code. Contact support if the accepted scan code is unclear.
The tote code is rejected.	Confirm the tote exists, belongs to the current process, and is the expected code for this activity.
Scanner entry fails but manual entry works.	Check scanner setup, keyboard language/input mode, and whether the scanner adds Enter after each scan.

If the route or iPad screen shows a SKU/location mismatch

Treat this as more than a scan typo. If the visible style, SKU, or product does not match the location, lot, bin, tote, or container the associate expects, stop and preserve the route screen before retrying scans.

Capture the expected style/SKU and the actual style/SKU shown.
Capture the shown location, lot, bin, tote, or container code.
Capture the Fulfill Orders view/filter, route, handling order, or order context if visible.
Note whether the warehouse expects one SKU per location/container or allows multiple SKUs in the same location.
Use What to do when a SKU is in the wrong storage location or container if the issue appears tied to storage setup.

Contact us when

Contact support when the correct code type is unclear, manual entry also fails, a tote or product should exist but is rejected, or the scan blocker stops active fulfillment work.

Send us this information

Merchant or workspace.
Warehouse.
Order, pick route, handling activity, or batch ID.
Product name, SKU, barcode, or configured scan code involved.
Tote, container, bin, or location code involved.
Exact scan input attempted, if safe to share.
Exact error message and timestamp.
Screenshot with private customer data masked.

Storage location, lot, or container mismatch

If the scan fails because the physical SKU is in one location or container but Logentic appears to expect another, treat it as a location/container mismatch instead of a scanner problem.

If this happens	What to do next
The product is physically in a different lot, bin, or storage location.	Stop the workflow, capture the physical code and the app-shown code, and ask a supervisor to verify before moving or adjusting anything.
The storage container or tote code does not match the SKU or location.	Search the container in Tote Manager if you have permission, then escalate with the SKU, container code, warehouse, workflow, and exact message.
The old location or container still appears after a correction.	Do not keep retrying scans. Capture the old code, new expected code, affected workflow, timestamp, and screenshot so Support can investigate stale or active-work references.
The location or container is unknown or unavailable.	Use What does “Container is unavailable” mean, and what should I do? and include the evidence listed there.