A successful decode can still put the wrong identifier into a warehouse application. When a label contains an order code, a product code and a logistics code, decide which field the current task requires before choosing how the handheld should capture it. Selecting one symbol, reading several symbols and accepting the right business value are separate decisions.
Consider a returns desk where an operator must identify an item against an open return order. A reused carton carries three readable codes. This is an editorial example, not an AIDC GO customer installation or a measured scan result. The question is not whether the scanner can read all three: it is whether the workflow can distinguish their roles without accepting the wrong record.
Name the required field before aiming
In this example, the application already knows order PO-48021 and asks for the product identifier ITEM-0836. A third code, SHIP-92107, refers to the carton movement. These invented values illustrate three roles; they are not a GS1 coding specification or a recommended numbering scheme. Each could be represented by the same barcode symbology, so barcode type alone would not separate them.
The screen should make the requested role clear. “Scan product identifier” is more useful here than “Scan barcode.” The application team must define which values belong to the open order, what to do with an unexpected but well-formed identifier, and whether an operator may override a rejection. The printed caption helps a person aim; it does not make the decoded value a valid product for that order.
If the next step requests a carton identifier, the intended code changes even though the label does not. Record the current application step alongside the expected value when preparing a demonstration. Otherwise a supplier can show a technically correct read while the project team assumes it proves a different task.
Choose between selecting one code and collecting several
For a task requiring one field at a time, deliberate selection can keep the interaction understandable: request the field, aim at its symbol, then show the returned value. Evaluate this at the normal working distance and label orientation. Do not assume that the code nearest the aimer will always be the one decoded on every configuration.
Zebra's DataWedge 15.0 Barcode Input guide describes Picklist selection using a reticle and separately describes MultiBarcode capture. Its fixed-count example can return values in decode order, not label order. These are documented Zebra modes, not confirmed AIDC GO features. Source: DataWedge 15.0 Barcode Input
Collecting several codes can be useful when one task needs several named fields. It also creates an assignment problem: which result fills which field? “Three codes received” is not equivalent to “order, product and shipment verified.” If two codes have the same format, the application needs a dependable way to identify their roles or request clarification.
| Capture approach | Suitable question to evaluate | What the result does not establish |
|---|---|---|
| One requested symbol at a time | Can the operator select the product code without accepting the neighbouring order code? | A single decode does not establish that the product belongs to the open order. |
| Several decoded values in one session | Can the receiving application assign every required value to its named field? | A result count does not establish field identity or business completeness. |
| A configured document or label template | Does the supported template still identify the required fields when the label layout changes? | A match on one layout does not establish support for another supplier's label. |
| Application confirmation of the assigned values | Does the screen show the intended order, item and carton before the operation is accepted? | A correct screen display alone does not establish that the backend committed the operation. |
The third row is an evaluation option only where the proposed equipment and software actually support it. Do not purchase against a mode name alone. Zebra's feature-matrix guide distinguishes device, Android, build, scan-engine and DataWedge dependencies, with licensing indicators for relevant features. Ask for the corresponding information for the actual proposed configuration, not another device shown in a video. Source: DataWedge feature-matrix scope
Keep decoded values separate until their roles are known
Ask to see what the application receives, not only a success beep. Is it one text string, several values with separators, or a structured result with a barcode type for each value? A receiving screen designed for one text field may not interpret a multiple-code result as intended.
The DataWedge 15.0 Intent Output documentation provides a manufacturer-specific example: multiple-decode output has a barcode bundle containing each code's type, raw data and character data. This demonstrates why the receiving format matters; it does not mean an AIDC GO device exposes that API or supplies an application that maps those values. Source: DataWedge 15.0 Intent Output
For the returns example, an application could reject SHIP-92107 in a product field because it does not match the configured product rule. That rule must also handle a wrong product value that has a valid format. Prefix checks are a useful illustration, not a complete acceptance design: the application still needs the relevant order or item records and an agreed exception path.
Keep two implementation questions separate. The existing Wedge, Intent and SDK comparison covers how captured data reaches an application. The GS1 parsing guide covers fields within a structured barcode. Neither replaces the decision about which physical code on this label should be used now.
Make the demonstration include the plausible wrong code
Prepare test labels with the correct product code next to a clearly readable but inappropriate code. Include a second product code with the same format but a different value. Ask the operator to complete the normal task without covering unwanted symbols by hand unless that is genuinely the proposed working method.
Then change one condition at a time: rotate the label, change the spacing between codes, place an older label nearby, or remove one required symbol from a multiple-code example. Retain the label image, requested field, returned values and application decision for each observation. These are suggested evaluations, not completed tests or universal pass rates.
A useful failure is specific. “The wrong carton identifier reached the product field and the application rejected it” is different from “the scanner reported no result.” Record whether the problem occurred during physical selection, decoding, field assignment or business acceptance. Repeating the trigger until a favourable result appears would hide that distinction.
If the target code is difficult to decode even when isolated, investigate that separately using barcode scanning versus verification. If the application accepted the right value but the transaction result is unknown, use the offline capture and unconfirmed transactions guide. This label-selection exercise should not become a substitute for either investigation.
Turn the result into a configuration enquiry
Start with the handheld terminal category, then send an annotated label showing which code is required at each application step. Include representative data, normal scan positions, the proposed model and the receiving screen or interface. Use test identifiers rather than live customer information.
Ask which selection and multiple-code options are available for that exact configuration, which software component owns them, and how the application receives results. Request matching versioned documentation and a demonstration of the agreed wrong-code cases. The supplier's device documentation and the customer's acceptance rules should describe compatible parts of the same workflow.
Use Integration Support for model, interface and version questions, or contact AIDC GO with the annotated material. A useful outcome is a configuration and an acceptance method tied to your label and application, not a general promise that a handheld will always choose the right barcode.