Scanning an empty container can signal demand, but it does not prove that a replenishment task was created, accepted, picked, delivered or confirmed at the workstation. A useful barcode-kanban workflow connects the physical trigger to one controlled business task and keeps every later state visible. That distinction prevents an operator from mistaking a successful decode for material availability.
The scenario below is an editorial construction, not a customer deployment or AIDC GO device test. The handheld-terminal category, warehousing and logistics page and Integration Support are commercial starting points. The replenishment rules, task states and software integration must be specified for the actual project.
Define what the barcode identifies
A line-side code might identify a reusable bin, a kanban card, a material, a storage location or a replenishment rule. These are related records, not interchangeable meanings. Before choosing the handheld or scanner configuration, document the identifier in the symbol and the records the application must resolve from it: material number, source and destination locations, standard quantity and unit, container type, active rule and current task state.
If the code identifies only bin BIN-L04-772, the application must use an approved mapping to determine that the bin belongs to material BOLT-M8, destination LINE-04, and replenishment rule KR-772. The scan does not independently supply those values. A printed quantity may help an operator read the card, but the transaction quantity should come from the configured rule or an authorized exception, not from an assumption that one scan always means one piece. The quantity-and-unit guide explains that boundary in more detail.
Microsoft's Lean manufacturing overview gives a bounded Dynamics 365 Supply Chain Management example: kanbans can signal demand, and a fixed-quantity strategy can create a new kanban when a handling unit is registered as empty. This is a named software behavior, not a universal meaning for every empty-bin scan and not an AIDC GO terminal function.
Keep the signal and the supply task separate
The first accepted scan may record an empty-bin signal. The application can then create or expose a replenishment request with its own identity, requested material, quantity, unit, source, destination, priority and status. Later states might include received, accepted, picking, dispatched, partially delivered, delivered, workstation-confirmed, cancelled or exception. The exact names vary, but the project should prevent one state from being silently treated as another.
Microsoft's kanban transfer board documentation describes specific Select, Start, Complete and Empty modes for its configured transfer workflow. That source demonstrates why a barcode action needs a declared business meaning. It does not establish that another ERP, WMS or handheld application uses the same modes.
A task can be received by the material team without being picked. A tote can be dispatched without reaching the correct station. A delivery can arrive without the line operator confirming the material and quantity. Store the responsible party and time at each event so the workstation can distinguish an open request from completed supply.
Follow one empty bin through the complete workflow
Assume an editorial two-bin process at LINE-04. Bin BIN-L04-772 is mapped to material BOLT-M8; the approved rule requests one tote of 80 pieces from supermarket location SUP-02. When the active bin becomes empty, the operator scans its label. The application resolves the current mapping, shows material, destination, quantity and unit, and creates task REP-581 only after the operator accepts the signal.
The material handler opens REP-581, scans source location SUP-02, verifies BOLT-M8, confirms 80 pieces in the required unit and associates the outbound tote. The picking-verification guide covers the source, item, quantity and destination checks inside that pick. The handler then records dispatch. At LINE-04, the receiving operator verifies the tote and records workstation receipt against REP-581. Only that final event establishes completion under this editorial rule.
The saved history should show the original signal, resolved rule version, request identity, requested and delivered quantities, units, source and destination, state transitions, operator or system actor, and exception decisions. A dashboard that displays only the last status loses the evidence needed to explain a shortage or duplicate request.
Stop duplicates from becoming duplicate supply
If BIN-L04-772 is scanned again while REP-581 remains open, the application should show the existing task and its state. It can record a second observation when useful, but it should not create REP-582 merely because another decode arrived. A second request may be valid only when the project rule permits overlapping demand and the operator can see why it is needed. The duplicate-read guide addresses scanner-side repetition; the replenishment application still needs transaction-level idempotency.
If a code from BIN-L05-219 is presented at LINE-04, resolve the actual bin relationship before creating work. Do not replace the destination with the current screen merely to make the scan pass. If the mapped material has changed, require an effective, approved rule version; a readable old label should not revive a retired mapping.
An offline capture needs an operation identity that the server can recognize after reconnection. Until the server accepts or reconciles it, show the signal as pending rather than promising that a unique task exists. Repeated submission after an uncertain response must query the original operation instead of blindly creating a second request.
Keep shortages and partial delivery explicit
Suppose only 60 of the requested 80 pieces are available. The handler should not close REP-581 as fully delivered by editing the request quantity without authority. Record 60 as the delivered amount, retain the 20-piece balance or an approved short-close decision, and show the workstation which state applies. If a substitute material is proposed, require the project's material and engineering approval; a barcode that matches a compatible-looking part is not that approval.
For stockout, blocked stock, wrong unit, damaged container or unreadable label, route the task to a defined exception owner. The operator should see whether the line is waiting, partially supplied, substituted under approval, or cancelled. A station confirmation should refer to the physical material actually received, not merely acknowledge that a request once appeared on a screen.
Test the handheld and application as one chain
Acceptance should start with the real labels, mounting positions, line lighting, gloves and network conditions. Verify that the scanner selects the intended bin code when other symbols are nearby, that the application resolves the current rule, and that it displays material, quantity, unit, source, destination and open-task state before commitment. The mobile barcode data-capture solution describes the capture layer, while the replenishment lifecycle remains an application and integration responsibility.
Run at least one correct empty-bin flow and one each for repeated scan, already-open task, wrong bin, stockout, partial delivery and uncertain reconnect. Read the resulting server records rather than accepting a beep or a changed screen as the result. Confirm who can alter quantity, close a shortage, approve a substitute and cancel a request. For a project discussion, use Contact AIDC GO; no built-in kanban system, fixed replenishment quantity or third-party ERP compatibility is implied.