RFID inventory and tag-locate workflows can use the same handheld reader, but they answer different questions. Inventory asks which tags were reported in a defined observation. Locate starts with a specific tag identity and gives the operator changing feedback while searching. A buyer should not use a successful inventory count as proof that a locate workflow is available, or treat a proximity indicator as a measured distance.
This guide uses an editorial maintenance-store example to compare the two tasks. It does not claim locate support for an AIDC GO RFID mobile computer or sled. Begin with the RFID Mobile Computers and RFID Sleds categories, then request the exact model, region, firmware and SDK evidence.
Start with the question the operator must answer
An inventory task asks for a population: which expected tags were observed, which expected tags were missing and which unexpected tags appeared. A locate task asks for one defined identity: can the operator move through a search area and narrow the likely position of that tag?
Zebra's RFID SDK for Android 2.0.5.226 inventory tutorial describes a continuous inventory that reports tags in the field of view and retrieves tag data from an SDK queue. The named implementation illustrates population capture; it does not establish inventory behavior for another reader.
Write the question into the work instruction. “Find asset P-214” requires an authoritative mapping from asset P-214 to the exact tag identity used by the locate operation. “Check the tool crib” requires an expected population and rules for missing, duplicate or stray identities.
Resolve the target identity before locating
A locate operation cannot repair an uncertain asset-to-tag relationship. Select the target EPC or other supported identifier from the authoritative asset record, display it to the operator and preserve the source of that selection. If the asset record points to an old or replaced tag, proximity feedback can guide the user toward the wrong physical object.
The damaged RFID tag replacement guide explains why the asset record, EPC, TID and old-to-new relationship must remain distinct. The tag commissioning guide covers initial encoding and independent readback.
Confirm whether the proposed application locates by EPC, another memory value or an application-side mapping. Check required length, formatting and filter behavior. Do not assume that a human-readable asset number is directly usable by the reader.
Follow one editorial tool-crib example
In the editorial scenario, the expected crib list contains 24 tools. Inventory reports 23 expected EPCs and two unexpected EPCs near the doorway. The missing asset is tool P-214. The application resolves P-214 to EPC 3034...8A7C and starts a locate task for that one value.
The operator walks from the doorway toward three racks while watching a changing proximity indication. A stronger indication near rack B narrows the search, but the operator still verifies the physical asset label and application record before closing the task. The locate feedback is directional evidence within that setup, not a distance measurement or proof of asset identity.
If P-214 has no trusted tag mapping, stop before locate. Use another approved asset identifier and correct the record under the project's responsibility rules. Do not search for a guessed EPC merely because it appeared in the inventory list.
Treat proximity as configuration-specific feedback
Zebra's RFID SDK Windows Developer Guide documents a named handheld-reader locationing feature that accepts a specific EPC and reports a relative proximity percentage. It also states that the feature applies to handheld readers in that SDK context. A relative percentage is not a calibrated metre value and should not be compared across undocumented devices or settings.
Reader capability must be checked before the workflow is designed. Zebra's RFID SDK for Android 4.0.0.9 developer guide includes a capability flag for tag locationing support. This is evidence that software should query a named reader's capabilities, not a promise that every RFID handheld implements locate.
Record the reader, antenna, region, power or profile settings, firmware, SDK, target identity and search route. Metals, liquids, tag placement, nearby tags and operator orientation can change observed feedback. Evaluate repeatability in the intended environment without converting the display into an unsupported physical-distance claim.
Give inventory and locate different completion rules
Inventory completion may require an expected-population comparison, a dwell or route requirement, duplicate handling and review of unexpected tags. A timer ending is not the same as all expected assets being accounted for. The inventory-scope guide keeps physical population, reader filtering and business membership separate.
Locate completion should require physical confirmation of the intended asset and an application record of who confirmed it, not only a high proximity indication. Define what happens if the target is never reported, several tagged objects are stacked together, or the operator finds a tag detached from the asset.
The UHF RFID read-range guide remains the place for read-zone, missed-tag and stray-read evaluation. Locate does not replace that inventory coverage work.
Compare the two task designs
| Task | Evidence that can support completion | What still requires separate confirmation |
|---|---|---|
| Population inventory | Observed identifiers, timestamps or counts compared with an authoritative expected list. | Confirm route, dwell, filtering, duplicate handling and the reason for every missing or unexpected identity. |
| Single-tag locate | Feedback tied to one documented target identity while the operator follows a defined search route. | Confirm that the target mapping is current and that the physical asset, not only the tag, was found. |
| Locate after an inventory gap | The missing expected asset selects the target identity for a separate locate step. | Confirm that the inventory gap was not caused by an incorrect list, damaged tag or configuration mismatch. |
| Found loose tag | The target tag is physically found away from the expected object. | This does not establish that the associated asset was found or that the tag should be reattached. |
| No locate response | The named target produced no usable feedback under the recorded setup. | This does not by itself establish absence, tag failure, mapping error or unsupported reader capability. |
Use the table as two linked workflows, not one universal score. Inventory produces a population observation; locate narrows a search for a selected identity; the application closes the business task.
Request the complete reader-and-application evidence
Provide the deployment country, candidate integrated reader or sled, host device and OS, firmware and SDK versions, antenna arrangement, target tag type and mounting, expected population source, asset-to-tag mapping, search area and required operator messages. State whether the project needs inventory, locate or both.
Ask for explicit locate capability and API documentation for the exact configuration, including the target identifier format and returned feedback. Separately request inventory trigger, reporting, filtering and queue behavior. Do not infer one task from the other.
Use the UHF RFID Inventory & Asset Tracking solution to frame the operating sequence, Integration & Support to reconcile reader and software versions, and Contact AIDC GO to submit the project evidence. The selection is ready when each task has its own input, observable result and business completion rule.