A barcode can identify an item, but many warehouse tasks still need a quantity and a unit of measure before the application can accept the work. The purchasing question is not simply whether the handheld reads the symbol. It is whether the device and application let an operator keep the right item, quantity, unit and work line together through confirmation and correction.
This guide follows an editorial receiving and picking example. It complements Barcode Scanner Integration Methods, which compares data-delivery paths, and Offline Barcode Capture, which addresses uncertain submissions. It does not claim that a specific AIDC GO model supports a named warehouse application.
Start with the quantity represented by the label
An item barcode may identify only the product, or it may carry quantity and unit information that the configured application understands. Those are different inputs. If a case label represents 12 pieces, scanning it as a product identifier alone must not silently become either one piece or 12 pieces without an agreed rule.
Microsoft's piece-picking confirmation documentation provides one bounded software example. In that named Warehouse Management flow, a barcode can include quantity information; otherwise the worker can be prompted to enter quantity manually. The system also considers the unit of measure in configured barcode quantity handling. These are application behaviors for the documented release, not generic scanner functions.
For each label type, record the sample value, the business item it should identify, whether quantity is encoded, the intended unit and the application field that becomes authoritative. A successful decode only proves that the capture path produced data.
Keep item, quantity and unit in one visible state
Consider an editorial receipt for item BX-204. One pallet label identifies the product, while the operator must receive 18 cases and each case contains 12 pieces. The screen should make clear whether the pending quantity is 18 cases, 216 pieces or another configured unit before the worker confirms.
The device interaction should preserve the active purchase-order line or work line while the operator scans the item and enters the count. If the application changes screens, receives an Enter suffix or advances focus automatically, verify that the quantity lands on the same intended record. The article on Gloved Handheld Input provides a separate evaluation of keys, correction actions and glove use.
Do not rely on a repeated beep as the quantity record. The application must expose the accumulated value, unit and transaction state. If repeated scans increment a count, define whether the increment is one piece, one package or the quantity encoded in each barcode.
Define the correction before testing speed
Quantity errors are operationally different from unreadable labels. The worker may scan the wrong item, enter 81 instead of 18, select the wrong unit, scan one carton twice or discover a damaged carton after the count. Each case needs a visible correction path before submission.
Test whether the operator can return to the item field without losing the work context, reduce or replace the quantity, change the unit only when permitted, and cancel an incomplete line. Confirm what the application logs and what remains pending. A hardware shortcut is useful only if the application gives it an unambiguous meaning.
Microsoft's warehouse mobile-device configuration documentation shows that work confirmations can be configured for products, locations or quantities in the named application. It also distinguishes automatic confirmation from requiring a worker confirmation. That example demonstrates why the application configuration belongs in the acceptance evidence.
Follow one line through accepted and rejected quantities
In the editorial receipt, the worker scans BX-204, selects cases and enters 18. The application finds the expected order line and shows 18 cases pending. The worker notices that one case is crushed, changes the quantity to 17 and submits. The backend accepts 17 cases and returns the line's remaining quantity.
Now test a value above the permitted receipt. The handheld can transmit 19 just as easily as 17; the business application decides whether over-receipt is allowed. Microsoft's inbound-load handling documentation describes named configuration options that allow or block over-receipt within defined limits. Do not generalize those controls to another WMS.
Retain the scanned item, entered quantity, unit, source work line, correction, submission identifier and returned status. If the response is missing, do not assume that resubmitting is safe; use the transaction-recovery boundary described in the offline-capture guide.
Compare the evidence at each stage
| Transaction stage | Evidence that closes the stage | Failure that still needs handling |
|---|---|---|
| Item capture | Captured value maps to the intended item and work line. | A readable value can still select the wrong item, variant or order line. |
| Quantity entry | Pending amount and unit are visible before confirmation. | A number without its unit can represent the wrong physical quantity. |
| Correction | The operator can change or cancel the pending line without losing context. | A corrected screen does not prove that an earlier submission was reversed. |
| Application acceptance | The application returns an explicit accepted or rejected result for the same transaction. | A scan beep or keypress does not establish business acceptance. |
| Backend record | The authoritative record shows the accepted amount, unit and reference. | A local success message does not establish that every downstream system is current. |
Use the table to design a representative test, not to assign these responsibilities to the scanner. The device captures and presents inputs; the customer application owns units, limits, work state and transaction acceptance.
Test the interaction on the proposed handheld
Use real label sizes and positions, the approved application build and representative gloves or mounts. Run a single-item quantity, repeated-piece count, packaged quantity, correction, wrong unit, duplicate scan and rejected overage. Include the longest expected item description and a value that requires correction.
Observe screen focus, dedicated keys, touchscreen targets, trigger use and whether the operator can hold the item while entering the count. Compare the published directions on Rugged Handheld Terminals without assuming that every model exposes the same keypad, scanner option or application interface.
Record the exact application configuration and label samples. If the barcode carries quantity or unit data, preserve the symbology, encoded value and parsing rule. If quantity is typed, record the accepted range, decimal rule, unit selection and feedback for an invalid entry.
Bring the transaction contract to the project discussion
Provide representative item and package labels, units of measure, quantity ranges, work types, correction cases, operator actions, application and OS versions, connectivity assumptions and the acceptance response expected from the backend. Identify whether repeated scans accumulate quantity and who owns overage, shortage and duplicate rules.
Ask the application owner to confirm field focus, parsing, unit conversion, validation, idempotency and audit behavior for the exact release. Ask AIDC GO to compare the task with the published handheld directions and to identify the model-specific configuration and integration materials that still need confirmation.
Use Warehousing & Logistics to connect the transaction to receiving, picking or counting, then Integration & Support and Contact AIDC GO to present the evidence. A useful purchase decision keeps item, quantity, unit and application acceptance together from the first scan to the authoritative record.