An RFID handheld can report tags it detects during an inventory session, but a tool-room transaction needs more than a list of EPC values. The application must identify the assets, connect them to an authorised person or work order, record the custody change, and treat missing or unexpected tools as exceptions rather than as a misleading total.
This guide uses an editorial six-tool maintenance kit. It is not a customer case or an AIDC GO performance test. Reader behavior, tag suitability, application interfaces and workflow controls must be confirmed for the exact models, software versions and mounted tags.
Define the custody event before starting inventory
Write the business state that must change. A check-out may require tool identity, borrower, work order, source location, issue time and condition. A return may require the expected kit, returning person, destination, condition and an authorised exception result. A read event alone should not change custody.
The expected set must come from an authoritative asset or kit record. The inventory-scope guide explains how the eligible population differs from everything a reader can see. This guide applies that distinction to a custody transaction.
Keep tag identity, asset identity and user identity separate
The reader may return an EPC or other configured tag data. The application needs a maintained mapping from that identifier to the tool record. The operator or borrower requires an independent identity and authorisation method. A tool tag cannot prove who is holding it, and a user badge cannot prove which tools are present.
The tag-commissioning guide covers initial encoding, readback and binding. The damaged-tag guide covers later identity changes. Complete those controls before a checkout system treats a read value as a named tool.
Build the issue transaction around an approved set
For the editorial example, work order WO-417 requires tools T1 through T6. The tool-room operator selects the work order and identifies the borrower. The application loads the expected set, then starts a bounded inventory session. It compares resolved asset identities with the expected list before presenting a check-out decision.
Zebra's RFID SDK for Android 2.0.5.292 Inventory tutorial documents a specific SDK flow that starts and stops inventory and retrieves tag data from an internal queue. It supports the separation between collecting reads and applying business rules. It does not establish an AIDC GO API, a tool-room workflow or automatic custody transfer.
Only commit the issue after the application shows the expected assets, resolves unexpected reads, confirms the borrower and work order, and records the authorised action. Preserve the transaction identity so a retry cannot silently issue the same set twice.
Compare membership, not only the total
The return scan reads five expected tools plus one tool from another kit. The raw total is six, the same as the expected quantity, but the kit is not complete. One expected identity is absent and one unexpected identity is present.
| Set result | Business meaning | Required next action |
|---|---|---|
| Six expected identities found | Candidate complete set, subject to condition and custody checks | Confirm each resolved asset and complete the authorised return |
| Five expected plus one unexpected | Total count matches but membership does not | Identify the missing tool and route or remove the unexpected tool |
| Five expected and no unexpected tool | One expected identity has no valid observation | Check the physical kit, tag, presentation and recorded expected list |
| More than six identities in the read zone | Reader observed assets outside the intended transaction | Narrow the zone or apply verified scope logic before accepting a set |
Hilti's ON!Track inventory documentation gives a named software example that classifies assets as expected, found, not found and unexpected. Those categories illustrate set comparison in that product; they are not evidence that an AIDC GO reader supplies ON!Track or the same workflow.
Treat a missing read as an investigation trigger
Not observing T4 does not establish that T4 is lost. Check whether the physical tool is present, whether its tag is intact and mapped correctly, whether metal mounting or shielding changed, whether tools were stacked, whether the intended zone was covered, and whether the expected list itself is current.
The metal-asset mounting guide explains why the tag, housing, fixing method and installation surface form one assembly. The read-range guide covers representative positions and orientations. Do not use one failed observation to change an asset to “lost” or one successful observation to prove that the whole kit was inspected.
Record check-out and return as separate commitments
At issue, record the borrower or responsible team, work order, tool identities, source, condition, transaction ID and confirmation. At return, compare the expected custody set with the observed and physically checked set, then record the destination and any exception. A return must not merely reverse the latest read list if the issue transaction is incomplete or disputed.
Hilti's loaned-tool return guide shows a named product flow where a user selects an asset, completes return details, reviews a summary and submits a form. It demonstrates that asset selection and a business return record are separate steps in that application. It is not a universal RFID process.
Keep maintenance and calibration states in the business record
A reader can help identify the tool presented, but it cannot determine from one inventory observation whether that tool is calibrated, under repair, retired or safe to issue. Those states come from the authoritative service record and an actual condition check.
Hilti's service-documentation guide is a bounded example in which historic service data and documents are viewed from an asset record. Do not translate those functions into an AIDC GO feature claim. The purchasing requirement is that the chosen application can retrieve the relevant business status for the resolved asset.
Choose the reader form around the work
An integrated RFID mobile computer keeps display, user input and RFID capture in one handheld direction. An RFID sled may suit a project that must retain an approved host, subject to confirmed host, mounting, connection, power and SDK conditions. A fixed cabinet can automate observations at a controlled boundary, but it does not remove the need for identity mapping, exception review and custody rules.
Use the RFID asset-tracking solution page to frame inventory and application responsibilities. Confirm tag construction, metal-surface installation, regional reader configuration, user interface, work-order integration and the exact read or SDK path before choosing hardware.
Validate the complete kit workflow
Run check-out and return with the correct six tools, five expected plus one unexpected tool, a present tool whose tag is not observed, an absent tool, a duplicate observation and an asset marked unavailable in the business record. For every case, retain raw observations, resolved asset identities, expected-set comparison, user decision and committed transaction.
Send the asset list, tag part numbers and mounting drawings, reader and region configuration, host and application versions, borrower and work-order fields, exception states, service-status source and acceptance evidence through Integration Support. Use Contact to request the model and interface documents for the shortlisted configuration. The application owner remains responsible for custody, authorisation and audit records.