Handheld Terminal Implementation in Thailand 2026: RFP, PoC and Acceptance Testing

A handheld terminal implementation in a Thailand factory should begin with transactions, identification and acceptance—not a device model comparison. The project must define who scans what, where inventory or work-in-process changes state, how the application behaves during a network interruption, and what evidence proves that the integrated workflow is ready. This guide covers receiving, put-away, picking, material issue, WIP movement, cycle counting and shipping from RFP through PoC, FAT/SAT, rollout and support handover. It is vendor-neutral and does not assume market prices or universal device performance.

The answer: design the business transaction, not only the handheld

The central question is not which terminal has the highest specification. It is whether a worker can identify the right object and location, commit the intended transaction once, recover safely from an interruption and leave an auditable record. Compare proposals against eight decision areas.

If these areas remain unresolved while quantities are purchased, devices may arrive without an operable system. When transaction and acceptance criteria are explicit, different hardware and application approaches can be evaluated on the same basis.

Define handheld terminal inventory management workflows first

Do not describe the project as replacing paper or spreadsheets with a terminal. Identify the physical event and the transaction that approves it. The GS1 Global Traceability Standard begins by defining process steps and critical tracking events. Receiving, storage, picking, packing and shipping may combine handheld and fixed capture devices, while identification and event data must stay linked.

Observe normal and exceptional work separately

A requirement based on one clean demonstration will push production exceptions outside the application. Observe and document:

• which document, label or screen informs each decision;
• when item, lot, quantity, location, container and operator become final;
• how partial, excess or short delivery, substitution, mixed loads and unreadable labels are handled;
• how unpacking, splitting, combining, return and disposal change the tracking unit;
• which discrepancies need approval and which the operator may resolve;
• where the recording time differs from the physical movement time;
• whether devices are personal or shared across workers and shifts; and
• glove use, one-handed work, noise, low light, outdoor areas, cold rooms or dust.

Map “stop,” “hold,” “escalate” and “synchronize later,” not only the happy path. Separate decisions made by the system from judgement retained by people. This prevents an application from silently converting an uncertain physical state into apparently precise inventory.

Turn benefits into measurable acceptance methods

“Increase efficiency” and “reduce errors” cannot be accepted. Measure the current baseline and reuse the same definition in the PoC and production acceptance. For processing time, define start and end events, whether waiting is included and how rework is counted. For errors, separate scan rejection, wrong-item confirmation, quantity correction and upstream integration failure.

Useful project-specific formulas include:

Processing-time improvement = current median − new-process median

Straight-through completion = transactions completed without handwriting, re-entry or administrator correction ÷ all attempted transactions

Inventory agreement = physical observations matching the system at the defined unit ÷ all observations

Segment results by product class, zone, shift, operator experience and exception. If a metric becomes contractual, also fix the sample, exclusions, evidence owner and retest rule. Do not insert an assumed improvement percentage.

Barcode management systems start with identification and master data

A terminal can capture characters from a label. The system must determine what those characters represent, whether they uniquely match the physical object and what happens to expired or replaced identifiers. Define what will be identified before selecting the hardware.

Separate objects from events

An item number alone cannot trace lot-controlled stock or container movements. Depending on the workflow, identify:

• product, component and raw material;
• lot, batch or serial number;
• storage location, rack, zone and staging position;
• pallet, carton or reusable container;
• purchase, receipt, production, issue and shipment document; and
• operator, equipment, inspection and quality-hold state.

Then connect those objects to events such as received, put away, split, issued, counted and shipped. When identity and event records are kept separately and joined later in a spreadsheet, timeliness and auditability degrade.

State the GS1 scope and edition

The GS1 General Specifications define the use of GS1 identification keys and barcodes. The change-notification page identifies the January 2026 publication as the current published baseline; subsequent ratified changes are candidates for the next version. Do not present every candidate change as already normative.

If GS1 is used, specify the identification keys, application identifiers and symbols applied to supplier and internal labels. Do not call an internal ERP material code a GS1 key without qualification. Test variable-length separators, dates, lots and quantities with encoded examples rather than leaving parsing to the implementer.

Test label quality in the real scanning environment

GS1 barcode implementation guidance explains that symbol type, size, placement and quality depend on the scanning environment. Bring the production printer, substrate, mounting surface, distance, lighting, angle, curvature, dirt, abrasion, wrinkles, transparent wrap and reflection into the test.

The RFP should define:

• symbols and representative encoded data;
• minimum and maximum labels agreed through physical samples;
• permissible position and orientation;
• accepted, marginal and rejected specimens;
• codes that can confirm immediately versus those needing screen review;
• selection logic when several codes appear in view; and
• reprint, manual entry, approval and audit behavior after failed capture.

When the identification problem is broader, compare barcode with RFID rather than choosing by fashion. Our guide to RFID implementation cost and PoC design for Thailand factories separates tags, readers, installation, integration and site testing. Evaluate the object, read point, bulk-reading need, metal or liquid, label process and exception handling.

Write a device RFP from work scenarios

Starting the RFP with a preferred model lets published specifications dictate the requirement. Provide work scenarios first and ask bidders for evidence of fit, constraints and alternatives. Published drop, ingress and battery claims must be checked against their test conditions and your operation. No universal thresholds or battery duration are assumed here.

Scanner and operator input

List required 1D/2D, near or far capture, screen-displayed codes, low-quality labels and multi-code selection. Zebra DataWedge is one implementation example whose current documentation covers integrated imagers, cameras, Bluetooth and attached scanners, plus 1D/2D decoder configuration. It is not a universal device requirement.

Test trigger placement, left- and right-handed use, repeated scans, duplicate suppression, sound, vibration, visual confirmation and cancellation. Use the actual gloves and ambient noise. Where physical keys or scan triggers matter, observe posture and fatigue as well as speed.

Design battery, charging and replacement as a shift operation

Rated capacity alone does not prove operational endurance. Brightness, scan frequency, Wi-Fi reconnection, background synchronization, temperature, ageing and between-shift charging affect consumption. During the PoC, record start and end charge under representative work, as well as charging opportunities, spare batteries, replacement method, charger location and device substitution.

Include sockets, protected power, shelving, device numbering, cleaning and issue/return control. Required quantity is not simply simultaneous users: model charging, faults, inspection, training and spares, and document the quantity basis.

Separate environmental certification from site validation

List the actual exposure to drops, dust, water, temperature, chemicals, static electricity and outdoor light. Compare vendor test conditions with the site. Separate items accepted through certificates from those reproduced at the factory. If destructive testing is needed, agree the method, specimen, ownership, safety and pass/fail criteria before contract.

Treat factory Wi-Fi and offline-first behavior as one design

Having Wi-Fi does not prove a mobile workflow will complete. Survey access-point layout, channels, interference, travel routes, roaming, authentication, reconnection and upstream API response using the target terminal and application. At the same time, define which work continues and which stops during an outage.

Survey the actual work route

Walk aisles, docks, cold areas, yards, conveyor paths, lifts and zones around metal equipment, not only points on a floor plan. During production, record association, transitions, delay, retries and disconnection with realistic device orientation. Avoid treating one signal-strength threshold as universal; acceptance is the successful transaction under the intended workload.

Use controlled wireless access, identity, segmentation, least privilege and logs instead of casually joining office or guest Wi-Fi. NIST SP 800-82 Rev. 3 says OT cybersecurity must preserve performance, reliability and safety. It is not a product certification; it supports design principles such as segmentation, managed identities, logging and controlled wireless access.

Decide online and offline behavior transaction by transaction

Android offline-first guidance calls for critical functionality under unreliable connectivity, a local source of truth, queued writes and conflict resolution. Offline writes are not automatically safe.

A scan against a previously downloaded instruction might be queued, while allocation against current stock, release of a quality hold or registration of a unique serial may require an online check. For each transaction define:

• locally available masters and their expiry;
• transactions permitted offline, limits and permissions;
• last-sync time and unsent count shown to the operator;
• send order, retry and backoff after reconnection;
• conflict rules when two devices handle the same object;
• physical hold or reversal after server rejection;
• treatment of unsent data after loss or failure; and
• encryption, deletion, audit and support for the queue.

Choose the handheld business-system integration method

Sending scan characters as keyboard input into an existing screen may suit a simple, short validation. Where transactions need state, multiple fields, error control and auditability, an application should receive scan events explicitly and submit a business transaction through an API. Choose on risk and support ownership rather than assuming one method is always superior.

Compare keystroke wedge and explicit integration

For a keystroke wedge, test focus, prefixes and suffixes, Enter behavior, screen transitions, character encoding and accidental entry into another application. Reusing an existing web screen can be valuable, but the application may have limited control over the source, raw payload and scanner configuration.

An explicit Intent, SDK or API can expose captured data, symbology and state to the application. Zebra DataWedge Intent Output is one Android example. Its documentation describes package targeting and optional application-signature checks to reduce misdelivery. Raw data is not equivalent to keystroke output, and version-sensitive behavior must be validated against current documentation and the target device.

Require idempotent API transactions and an audit trail

After a wireless timeout, the server may have committed a transaction even though the terminal did not receive the response. Assign a transaction ID on the client and make the server return the same result when that ID is retried, preventing double inventory movement.

Record at least:

• transaction, device and user ID;
• transaction type, item, lot, container and location;
• device event, server receipt and commit timestamps;
• application and master-data versions and connectivity state;
• first attempt, retry count, response and final state; and
• cancellation, correction, approver and reason.

The log exists to reconstruct movement and system state, not to blame individuals. Define retention, access, clock synchronization and personal-data handling.

Assign a system of record field by field

In a landscape where ERP owns accounting stock, WMS owns locations, MES owns production events and terminals hold an unsent queue, define ownership for item descriptions, units, lot status, bins, orders and user rights. Create a matrix for creation, change, read and retirement.

For the wider investment scope, see our Thailand factory WMS cost breakdown. A terminal-only quote can hide master-data preparation, APIs, Wi-Fi, training, labels and transition. If WMS and handheld work are contracted separately, keep one integration-test and incident-routing responsibility matrix.

Include dedicated-device management and security

Android dedicated devices are fully managed work-purpose devices. They can use allowlisted or kiosk apps, support shared-shift operation, managed provisioning and QR enrollment. Android explicitly recommends end-to-end testing with an EMM.

Put the entire lifecycle in the RFP

Cover initial enrollment, Wi-Fi and certificate delivery, application release, setting changes, OS updates, lost-device lock, replacement, reset and disposal. Android Management API documentation describes fully managed company-owned devices and locking to one or a small allowlist of apps. Provisioning options include zero-touch, QR code, NFC and DPC identifiers. Confirm eligibility and the EMM arrangement rather than implying every end customer can directly use the API.

The asset register should include serial, department, assignment, application, OS, battery and repair history, loss status and disposal evidence. For shared devices, test login/logout, shift handover, unsent queues and persistence of personal settings.

Separate least privilege from support access

Do not grant operators, supervisors, warehouse managers, IT and vendors identical access. Separate manual entry, discrepancy approval, master synchronization, log viewing, remote control and application release. Temporary support privileges need approval, expiry and recording; permanent shared credentials are poor operational design.

Use the PoC to prove a workflow, not a scanner demo

A PoC retires the most consequential uncertainty on a small scale. Prioritize questions that change the design or budget if they fail: label quality, roaming, offline transactions, gloves, API behavior and shared shifts.

Fix the PoC protocol before execution

• hypothesis and pass, conditional-pass and fail definitions;
• workflow, place, shift, users, device and application version;
• real labels and representative anonymized data, including exceptions;
• prerequisites, procedure, instruments and evidence format;
• injected outage, low battery, duplicate submission and server failure;
• safe substitutes for tests that cannot run in production;
• defect severity, redesign and retest rule; and
• artifacts promoted to production versus discarded.

Close each trial with a test ID, input, expected result, actual result, evidence, decision, owner and due date—not “users liked it.” Keep qualitative feedback, but separate it from measured acceptance.

QR-code inventory management exceptions

Do not adopt QR simply because it can contain more data. Decide what stays on the label and what requires server lookup. Test long payloads, bad separators, old versions, multiple labels on one object, screen-displayed codes, damage, reflection, curvature, copies and unauthorized codes. If supplier symbols coexist with internal QR codes, the application needs a rule that rejects the wrong code type.

Stage FAT, SAT and rollout gates

FAT proves terminal, application, server integration, configuration and documentation in the supplier-controlled environment. SAT proves integration with the Thailand factory’s real Wi-Fi, labels, users, upstream systems and operating pattern. Even when test names overlap, prerequisites and evidence differ.

FAT scope

• traceability from RFP requirement through design and test;
• symbols, formats, validation, exception screens;
• API success, timeout, retry, duplicate, rejection and reversal;
• local queue, restart, loss of power and conflict handling;
• permissions, kiosk, deployment, logs and remote support;
• installation, configuration backup, restore and spare preparation; and
• operator/admin procedures, incident routing and known limitations.

SAT scope

• connectivity and roaming along aisles, docks and production routes;
• accepted, marginal, rejected and multi-code real labels;
• shift change, shared devices, charging and spare substitution;
• real WMS/ERP/MES masters and closing activities;
• concurrency, peak transactions, printers and time synchronization;
• outage, upstream failure, recovery and reconciliation;
• user completion after formal training; and
• repeatable fault isolation across operations, IT and supplier.

Exit criteria from pilot to broad rollout

Do not approve full deployment automatically after one successful workflow. Require no unresolved critical defect, completed reconciliation, active support, prepared spares and backups, completed training and a rollback condition. For phased rollout, assign owner, freeze window, opening inventory, day-one support and gate meeting by site, workflow and shift. Track application and master versions when they change during rollout.

Build a vendor-neutral handheld implementation TCO

Normalize proposals over a defined evaluation horizon. Compare acquisition, deployment, operation, change, downtime and exit on common assumptions. This article does not claim market prices or a universal payback period.

TCO = acquisition and design + deployment + operating support + change and expansion + downtime impact + exit and migration − residual value

Initial categories

• devices, scanners, batteries, chargers, protection and spares;
• label printers, media and location-label preparation;
• Wi-Fi survey, extension, authentication and certificates;
• process analysis, identification design, UI, development and APIs;
• EMM, kiosk and application delivery setup; and
• PoC, FAT, SAT, migration, training, documentation and project control.

Ongoing and risk categories

• software, EMM, support and cloud subscriptions;
• batteries, replacement, repair, cleaning and logistics;
• OS, application, API and security updates and certificates;
• new products, labels, sites and workflows;
• help desk, triage, remote or onsite response and refresher training;
• interruption and rework from device, network, integration or process failure; and
• data extraction, reset and successor transition at contract end.

Keep downtime transparent:

Downtime impact = interruption hours × affected labor/equipment hourly cost + workaround + re-entry/reconciliation + production/shipping impact

Distinguish estimates from historical observations. Run low, baseline and stress assumptions through the same formula to show which variable drives the decision.

RFP and acceptance checklist

Attach process maps and exceptions; identity and code dictionaries; real labels; master ownership; work environment; connectivity and security conditions; UI, offline and audit requirements; WMS/ERP/MES transaction and idempotency rules; PoC/FAT/SAT/pilot gates; EMM and replacement procedures; training, SLA and required use rights; and a normalized cost table with assumptions and exclusions.

Do not award points for an unsupported “compliant.” Request a live test, architecture, record, configuration example, support flow, named responsibility and explicit constraint. A mandatory security or data-integrity gap should not be offset by price points. Record unanswered items as risk and preserve scoring rationale.

Frequently asked questions

Where should a handheld terminal implementation begin?

Begin with the receiving, put-away, issue, count and shipping transactions and their exceptions. Define who identifies what, which data becomes final and which system receives it. Then compare candidates in a PoC using real labels, routes and working posture.

Can handheld terminal inventory management work offline?

Selected functions can, but not every transaction is safe offline. A local source of truth, queue, transaction ID, retry and conflict handling are needed. Current-stock allocation or quality release may remain online-only. Define the physical hold and reconciliation process after rejection.

How should barcode and QR-code inventory management be compared?

Compare data standard, distance, label size, supplier symbols, multiple labels, printing and mounting—not capacity alone. Test accepted, marginal and damaged labels on the candidate device. QR codes still need master-version, duplication and authorization controls.

Is keyboard input into the existing ERP screen sufficient?

It may suit a simple online field. Explicit scan integration and API transactions are usually easier to control when the workflow needs duplicate prevention, offline queues, several fields, auditability or strict error handling. Test focus, timeout, retry and accidental delivery for the chosen approach.

How should handheld implementation cost be compared?

Use a common evaluation period covering devices, charging and spares, labels, Wi-Fi, application, API, EMM, PoC, rollout, training, updates, repair, downtime and exit. Ask all bidders to fill the same quantity and effort model instead of inserting a generic market price.

What is the difference between FAT and SAT?

FAT validates function, integration, offline handling, security and documentation in the supplier environment. SAT validates the same system against real factory Wi-Fi, labels, users, upstream systems and shift operation. Keep prerequisites, evidence and open-item rules distinct.

Conclusion: make the post-scan transaction acceptable before purchasing

The success of a handheld terminal implementation depends on connecting identification, events, outage behavior, integration, access, operations and testing into one transaction design. Use real labels and work in the PoC, prove functional and failure behavior at FAT, and prove Thailand-site integration at SAT. Compare the complete TCO of labels, Wi-Fi, software, WMS/ERP/MES integration, EMM, rollout, support, downtime and transition—not device price alone.

TOMAS TECH can support process discovery, code and master-data design, Wi-Fi and offline requirements, RFP preparation, PoC, WMS/ERP integration and FAT/SAT before a device vendor or quantity is fixed. You can contact us even while the target workflow and rollout scope are still being defined.

Primary sources

• GS1 General Specifications: https://www.gs1.org/standards/barcodes-epcrfid-id-keys/gs1-general-specifications
• GS1 change notifications: https://ref.gs1.org/standards/genspecs/gscn/
• GS1 Global Traceability Standard: https://www.gs1.org/standards/gs1-global-traceability-standard/current-standard
• GS1 barcode implementation guidance: https://www.gs1.org/standards/barcodes/10-steps-to-barcode-your-product/english
• Android dedicated devices: https://developer.android.com/work/dpc/dedicated-devices
• Android offline-first architecture: https://developer.android.com/topic/architecture/data-layer/offline-first
• Android Management API provisioning: https://developers.google.com/android/management/provision-device
• Zebra DataWedge Barcode Input: https://techdocs.zebra.com/datawedge/latest/guide/input/barcode/
• Zebra DataWedge Intent Output: https://techdocs.zebra.com/datawedge/latest/guide/output/intent/
• NIST SP 800-82 Rev. 3: https://www.nist.gov/publications/guide-operational-technology-ot-security