Scheduled ≠ Arrived
A date/window exists; the material is not yet physically at the facility.
Support Central · Inbound & Receiving
Inbound Is Stuck, the Scan Is Not Responding or the Counts Do Not Match
Use this guide for inbound problems from arrival scheduling through Gate Receiving and Item Intake: request progression, package verification, QR scanning, Lock & Start, item counts, photos, discrepancies and stage completion.
Do not press a state-changing button repeatedly just because the first click appears slow. First confirm the current task state. A delayed first action may already have been accepted.
Inbound troubleshooting path
Request → arrival → gate → intake → next stage
Request → arrival → gate → intake → next stage
01
Where is the inbound now?
Identify the exact Board stage and whether the problem is scheduling, receiving, scanning, intake or completion.
Where is the inbound now?
Identify the exact Board stage and whether the problem is scheduling, receiving, scanning, intake or completion.
→
02
What physical truth is confirmed?
Packages present, seals/photos, counts, item identity and QR type must match what the workflow is trying to record.
What physical truth is confirmed?
Packages present, seals/photos, counts, item identity and QR type must match what the workflow is trying to record.
03
Run only safe checks
Refocus scanner, verify the code type, refresh visible state once and preserve discrepancy evidence.
Run only safe checks
Refocus scanner, verify the code type, refresh visible state once and preserve discrepancy evidence.
04
Stop before creating false state
If quantity, identity or stage status is inconsistent, do not force completion. Open one ticket with the task reference and screenshot.
Stop before creating false state
If quantity, identity or stage status is inconsistent, do not force completion. Open one ticket with the task reference and screenshot.
Arrived ≠ received · package received ≠ item received · scanned ≠ stage completed.
Keep each boundary explicit
Keep each boundary explicit
01
Start with the stage—not the symptom
Start with the stage—not the symptom
Find the Exact Inbound Boundary that Is Failing
An inbound can look “stuck” for very different reasons. First identify the current Board stage, then confirm what physical evidence and workflow data already exist.
Safe checks
Read current stage, confirm package/item count, identify QR type, capture the visible error and refresh the current view once if needed.
Read current stage, confirm package/item count, identify QR type, capture the visible error and refresh the current view once if needed.
Stop conditions
Do not repeat Complete/Save, overwrite a mismatch, generate a second identity QR or change quantity merely to make the task advance.
Do not repeat Complete/Save, overwrite a mismatch, generate a second identity QR or change quantity merely to make the task advance.
A. Still before physical arrival?Request Submitted / Arrival Scheduling / In Transit → check scheduling and request progression.
↓
B. Material physically at the gate?Arrived at Gate → confirm package count, receiving evidence and optional container QR handling.
↓
C. Package received but individual items not intake-complete?Item Intake → confirm Lock & Start, per-item identity, required photos and item count.
↓
D. Data saved but stage does not move?Confirm the saved state before another click. The first action may be delayed but already accepted.
↓
E. Physical truth and system state still disagree?Open one Inbound & Receiving ticket with task/request reference, current stage and sanitised screenshot.
02
Problem: request is not progressing to arrival
Problem: request is not progressing to arrival
Separate Request Approval, Arrival Scheduling and Physical Arrival
A request can be valid without being scheduled, and a scheduled inbound is not “Arrived at Gate” until the material is physically received.
- Confirm the inbound request/reference is the correct one.
- Check whether pickup or self-drop was selected.
- Confirm date/time window and relevant contact details are present.
- Confirm the destination/warehouse is the intended location.
- Do not manually advance to Arrived at Gate before physical arrival.
Expected stateA scheduled request should show the agreed arrival method/window without pretending that material has already been received.
StopIf the request details point to the wrong warehouse, wrong lot or wrong arrival method, correct/hold before receiving.
Inbound request / arrival schedulingScreenshot slot IR-01
Highlight: request reference + pickup/drop method + date/window + destination.
Replace with a demo inbound scheduling screen.Use fictional contacts/addresses. Do not expose real client logistics unless already public and necessary.
03
Problem: Gate Receiving cannot be completed
Problem: Gate Receiving cannot be completed
Confirm Packages and Receiving Evidence before Creating Any Receiving Identity
Gate Receiving is about the physical shipment entering custody. Container-level QR is optional where the chosen client/lot workflow does not require it.
- Confirm actual packages/boxes/peti/trunks physically present.
- Compare the actual package count with expected count.
- Capture required seal/vehicle/material evidence where applicable.
- If container QR is required, generate/attach one identity per intended container record.
- If QR is not required for this client/lot, do not create unnecessary labels merely to pass the screen.
Container QRIdentifies an outer receiving/storage container. It is not the permanent per-item custody/catalogue identity.
MismatchIf expected 10 packages and 9 physically arrive, record the discrepancy. Do not change the physical truth to 10.
Arrived at Gate / package verificationScreenshot slot IR-02
Highlight: expected vs actual package count + evidence + optional container QR control.
Use the actual Gate Receiving popup with demo data.Show package-count comparison and where the operator chooses/uses container QR.
04
Problem: QR or scanner gives no useful response
Problem: QR or scanner gives no useful response
Identify the Code Type, Keep Focus in the Scan Field and Verify One Identity at a Time
Seller Central may accept Storage QR, Catalogue QR/SKU or another workflow-specific identifier depending on the stage. A scan should not silently create a different identity.
- Confirm the cursor/focus is inside the intended scan field.
- Confirm the scanner/phone/manual entry is sending the complete code.
- Identify whether this stage expects container QR, Storage QR, Catalogue QR or SKU.
- If the scan appears to hang, do not rapidly rescan the same code.
- Check the visible matched/verified state before trying once more.
Fast scanning patternScan → immediate verify → clear/refocus → next item. The operator should not need to mouse back into the field for every item.
Duplicate / wrong matchIf one scan matches the wrong record or creates a duplicate state, stop the batch and open a ticket.
Gate / Intake scan controlScreenshot slot IR-03
Highlight: scan field focus + code type + verify result + next-scan refocus.
Capture phone/scanner/manual-entry workflow.Use a fictional QR/code. Do not display a real client inventory code that exposes private stock.
05
Problem: Item Intake / Lock & Start will not work
Problem: Item Intake / Lock & Start will not work
Confirm the Lot Is Ready for Item-Level Intake before Starting the Intake Session
Item Intake is where individual items become traceable inventory records. Depending on the selected service/commercial route, per-item QR, required photos and item-level details may be mandatory.
- Confirm the inbound is actually in Item Intake, not still in Gate Receiving.
- Confirm the lot/container being opened is the intended one.
- Confirm expected item count is present or discrepancy is explicitly flagged.
- Use Lock & Start once; if it does not visibly initialise, confirm current state before another attempt.
- For rent/sell/subscription routes, do not skip required item identity/photos just to move the task.
Storage-onlyMay require less catalogue preparation, but custody/count/location truth still matters.
Commercial routeIf the route requires item QR/photos/catalogue preparation, do not mark intake complete while those mandatory records are absent.
Item Intake · Lock & StartScreenshot slot IR-04
Highlight: selected lot/container + expected count + Lock & Start + intake-session state.
Use a demo Item Intake popup.Show exactly where the session is started and what visible state proves it actually started.
Per-item identity / photos / routeScreenshot slot IR-05
Highlight: item QR + required photos + category/route + completed-item indicator.
Show one fictional item row, not a real client’s inventory.Use demo QR, demo photos and a generic category.
06
Problem: package or item count does not match
Problem: package or item count does not match
Record the Difference; Never Edit the Physical Truth merely to Match the Request
Discrepancy handling protects custody and later inventory accuracy. A mismatch is not an inconvenience to be hidden—it is a real operational state.
- Recount the physical packages/items once using the same counting unit.
- Confirm whether the request count is package-level or item-level.
- Capture relevant receiving evidence.
- Flag the discrepancy/exception using the workflow control.
- Do not create phantom items or silently reduce expected quantity to make the task green.
ExampleRequest says 100 items; 97 are physically received. Record 97 received and 3 short/missing according to the exception workflow.
Identity mismatchIf a scanned item belongs to a different inbound/client/lot, isolate it rather than assigning it to the current request.
Count discrepancy / exceptionScreenshot slot IR-06
Highlight: expected count + actual count + discrepancy flag/reason + evidence.
Capture a fictional discrepancy.Use clearly demo counts and avoid real shipment/vendor details.
07
Problem: Save / Complete worked but the stage did not move
Problem: Save / Complete worked but the stage did not move
Do Not Double-Submit a State-Changing Action until You Have Confirmed What the First Action Did
A slow response can make it look as if nothing happened even when the server accepted the first action. Repeating the same completion action can create duplicate processing or make the task jump only on the second visible attempt.
- After Save/Complete, wait for the visible result or error.
- Check whether the task/stage/status changed before clicking again.
- If the popup remains open, capture its current state and any message.
- Refresh the Board once only if the current guide says the action is safe to re-read.
- If saved data exists but stage remains wrong, open one ticket instead of repeatedly pressing Complete.
State checkWas data saved? Did the task move? Did a new downstream stage/task appear? Did the activity history record the action?
Do notClick Complete 2–3 times, recreate QRs, duplicate intake rows or manually alter stage/status just to make the Board look correct.
Save / Complete / stage stateScreenshot slot IR-07
Highlight: current stage + success/error message + Complete control + activity/state after first click.
Show the stage transition evidence.Use a demo task and include the activity/status area needed to prove whether the first action was accepted.
Inbound state boundaries
Do Not Collapse Distinct Receiving States into One “Done” Status
These distinctions prevent false custody, false quantity and premature downstream work.
↔ Swipe through inbound state boundaries
Arrived ≠ Received
A vehicle/material is at the gate; package verification and custody evidence may still be incomplete.
Package Received ≠ Item Received
An outer container may be accepted before each item inside is individually identified/intaken.
Container QR ≠ Item QR
The outer box/peti identity is not a substitute for permanent item identity where item-level tracking is required.
Scan ≠ Verification
A code entering the field is not enough; the system must match it to the intended record/state.
Intake Complete ≠ Catalogue Ready
Receiving/custody can be complete before studio/catalogue preparation and destination publishing are complete.
Still unresolved?
Open One Inbound & Receiving Ticket with the Exact Stage and Physical/System State
The support team should be able to tell what has physically happened, what Seller Central recorded and what action is blocked.
Good ticket
Inbound: DEMO-IN-00042
Task: Demo Receiving Task
Stage: Item Intake
Problem: Lock & Start was pressed once; no intake-session state appeared
Physical state: 24 items present in 2 containers
Expected: Intake session opens for the selected container
Evidence: Sanitised popup screenshot + visible timestamp
Bad ticket
“Inbound stuck. I pressed complete many times. Please fix.”
No inbound reference, no stage, no count, no visible error and the repeated action may already have changed state.