A barcode scan can identify an item, license plate or transfer document, but it does not say whether stock is still available at the source, physically on a vehicle, accepted at the destination or already put away. A reliable warehouse transfer keeps these events separate and links each confirmation to the same approved transfer record.
This guide is for warehouse operations, inventory-control teams and WMS integrators evaluating a handheld workflow. Its scenario is editorial, not an AIDC GO customer deployment or device test. The handheld-terminal category, warehouse and logistics solutions, Integration Support and Contact are commercial handoff points; the transaction rules belong to the selected WMS or ERP.
Start with the transfer record, not an isolated scan
A transfer order normally identifies a source warehouse, destination warehouse, item lines and planned quantities. Projects may also track source and destination locations, units, batches, serials, license plates, handling units, transport references and an in-transit warehouse. The device must capture the identifiers required by that configured process, not invent missing transfer data from a product barcode.
The same physical label can participate in several events. Scanning license plate LP-S-014 during source picking can identify stock selected for the transfer. Scanning it at loading can associate the handling unit with dispatch. Scanning it at the receiving dock can select an expected inbound unit. Those scans are not interchangeable just because the decoded string is identical.
Microsoft's current warehouse mobile-device configuration lists distinct transfer-order receiving and receiving-and-put-away processes, and also a configured flow that creates transfer orders from scanned license plates. These are named Dynamics 365 Supply Chain Management behaviors. They illustrate why menu item, work type and configuration matter; they are not built-in features of a generic handheld.
Keep five business states observable
Define what each project state means before deciding which screen or scan confirms it.
| State | Evidence the workflow should retain | What the state does not prove |
|---|---|---|
| Requested | Transfer ID, approved source and destination, expected item or handling-unit lines and quantities | That the source has picked or dispatched the goods |
| Prepared | Actual picked item, unit, batch or serial and handling-unit relationship, with unresolved differences visible | That the load left the source warehouse |
| Dispatched | Approved shipment confirmation, actual dispatched quantity and custody or transport reference | That the destination received the same physical set |
| Received | Destination observation matched to the open transfer, actual quantity and accepted exceptions | That all stock has been put into its final location |
| Put away or closed | Completed destination work and the configured transfer close condition | That every earlier exception was automatically resolved |
Microsoft's inventory-posting explanation describes transfer-order shipment and receipt as separate updates and uses an in-transit warehouse in its accounting example. Use that only as a Dynamics 365 example. The chosen system may model transit differently, but a buyer should still ask when source availability changes and when destination availability begins.
Walk through an editorial transfer
Assume transfer TR-0842 moves ten units of item VALVE-22 from warehouse WH-A to WH-B. Eight units are in license plate LP-S-014; two are loose. The item is batch controlled, and the order expects batch B2407. These identifiers and quantities are invented for teaching.
At the source, the application opens TR-0842, confirms WH-A, and prompts for the actual stock. The operator scans LP-S-014; the application resolves eight units of VALVE-22, batch B2407. The two loose units are then scanned or entered through the project's approved quantity path. The quantity-and-unit guide explains why a product read and a transaction quantity are separate observations.
If the operator scans batch B2408, a successful decode is not enough. The application must show that the batch differs from the approved line and either reject it or open the configured substitution or exception path. The operator must not edit the displayed characters until they resemble the expected batch.
When source preparation totals ten accepted units, the load can be presented for dispatch. The project may require a dock, vehicle, route or seal reference before a supervisor or system process confirms shipment. Only that configured confirmation moves the transaction from prepared to dispatched. The packing-verification guide covers carton contents and shipping labels; it does not replace the transfer's source and destination state changes.
At WH-B, the receiving operator opens the same transfer and scans LP-S-014. The loose portion arrives as only one unit. The destination records nine units observed and one unit short. It does not change the expected quantity to nine simply to close the screen. The unresolved unit remains a documented difference for the authorized role to investigate.
Treat partial receipt and duplicate work as explicit branches
A partial receipt can be legitimate, but it needs a rule. The destination might record nine received while the remaining one stays in transit, is declared short, or is moved to an investigation state. The correct choice depends on the transfer system and the evidence from the source and carrier.
Microsoft's transfer-order receiving configuration distinguishes registration from later receipt processing in configured Supply Chain Management flows, including a version-specific option introduced in 10.0.44. This demonstrates that a mobile registration and the system's final receipt update can be separate. It must not be generalized into every WMS.
Prevent a second operator from silently repeating work. Before accepting a scan, show whether the handling unit is still expected, already received, partly received, cancelled or assigned to another open operation. A duplicate event may need to display the earlier transaction and stop; it should not create another receipt just because the barcode is valid. The duplicate-read guide addresses rapid repeated decoder output, whereas this article addresses a later business attempt against a transfer state.
Do not hide source and destination disagreements
Common differences require different evidence and owners:
– Wrong source stock: the scanned item, batch, serial or status does not match the approved transfer line. Keep it out of the prepared set until the WMS owner approves a change. – Dispatch quantity differs from preparation: reconcile loading evidence rather than assuming the prepared set left the site. – Destination receives an unknown handling unit: quarantine or hold it under the agreed process. Do not attach it to the nearest open transfer based only on location. – Short or damaged receipt: record the observed quantity and condition separately from the planned quantity and from any later inventory or financial decision. – Network result is unknown: preserve the transaction identity and query its status before retrying. The offline transaction guide covers accepted-versus-unconfirmed outcomes.
The source may show “shipped” while the destination application still has an older expected list. That is not permission to create a new transfer on the handheld. Check synchronization time, transfer ID, system environment and current server record.
Verify item tracking across the handoff
When batches or serials matter, confirm what the system carries from shipment into receipt. Microsoft Business Central's item-tracking documentation describes transfer orders as using shipment and receipt from the same transfer line and carrying item-tracking entries. This is a Business Central example, not a universal data model.
For the project, test at least one batch-controlled line, one serialized line if applicable, a partial quantity and a rejected identifier. Preserve the raw scan, normalized value, transfer line selected, quantity and unit, business outcome and server transaction reference. A report that retains only “scan succeeded” cannot answer which stock moved.
Evaluate the complete handheld workflow
Hardware evaluation should reproduce the real working sequence: scan a transfer or handling unit, confirm source location, collect required batch or serial data, enter quantity, read the result, move to loading, then perform a controlled destination receipt. Check the display under site lighting, gloved or keypad input where required, network transitions, cradle or vehicle use and error recovery. The picking-verification guide and putaway guide cover the adjacent warehouse tasks; neither proves the transfer handoff.
Ask the application provider for the exact transfer statuses, mobile menu or workflow configuration, units, item-tracking behavior, offline contract, duplicate controls and audit output. Ask the device supplier for the exact scanning and connectivity configuration to evaluate. A barcode handheld can capture the identifiers used by the process, but the WMS decides whether dispatch, in-transit custody, receipt and putaway have actually been recorded.