A handheld inventory system integration succeeds when every scan maps to a defined transaction, every transaction has a clear posting boundary, and WMS and ERP can reconcile the result by event ID. This article builds a transaction matrix for receiving, transfer, issue, and cycle count, then turns it into interface and acceptance criteria. A screen that reads a barcode without this design can create duplicate receipts, lost offline work, wrong-lot issues, and unapproved stock adjustments. Thai factories often pass materials between receiving, warehouse, production, quality, and shipping teams. Their operators may use different languages, but every team needs the same meaning for a completed transaction.
This guide follows the broader handheld terminal implementation guide and the inventory system implementation guide. It focuses on the specifications a project team needs before buying or integrating devices: receiving, location transfers, picking, cycle counting, offline queues, approvals, ERP/MES reconciliation, and FAT/SAT criteria. It is not a device model ranking or a generic WMS comparison.
Separate a successful scan from a posted inventory transaction
A scan proves that a label was read. It does not by itself prove that stock should become available, move to another bin, or leave the warehouse. A received pallet may still be awaiting a purchase order match or quality inspection. A picking scan may still be waiting for supervisor approval because its lot differs from the instruction. Treat “scan captured,” “transaction accepted,” “stock posted,” and “downstream ERP updated” as different states.
Define a transaction record with a stable event ID, transaction type, referenced order or work instruction, item, quantity and unit, lot or serial where relevant, source and destination location, worker, device, event time, server receipt time, approval state, and posting state. A practical design is for the device to create the event ID once and reuse it on every retry. The server then returns the original outcome when it sees that ID again, without adjusting stock twice. This is an integration recommendation, not a claim that any particular ERP provides it by default.
Decide which system is authoritative for each inventory state. Some sites make WMS the operational quantity ledger and send inventory journals to ERP. Others post directly to ERP inventory through an API. MES may hold work in process by production order or operation. Map the ownership of available, reserved, inspection, quarantine, in-transit, and WIP balances. Avoid designs where two systems independently add the same receipt. Keep a visible acknowledgement, error, and retry record for every handoff.
Build a transaction matrix before a screen list
The first deliverable should be a process-by-process transaction matrix. The example below must be adapted to the plant’s item controls, quality rules, and accounting close.
| Process | First scan | Validation | Point of posting | Exception route |
|---|---|---|---|---|
| Receiving | Purchase order or ASN, then item or handling unit | Item, quantity, unit, supplier, lot | Confirmed receipt to inspection or available stock | Over-receipt, unknown lot, label mismatch |
| Put-away and transfer | Handling unit, source bin, destination bin | Allowed destination, capacity, lot policy | Completed movement from one bin to the other | Blocked bin, mixed lots, interrupted move |
| Picking and production issue | Work instruction, bin, item | Reserved item, lot, quantity, order | Confirmed issue or pick | Shortage, substitute lot, unexpected item |
| Cycle count | Bin, item, physical units | Count task, bin state, duplicate count | Approved adjustment after review | Large difference, recount, hold |
An empty “point of posting” column makes acceptance testing impossible. A scanner beep and an ERP balance change must not be reported as the same completion event. Goods can physically be in the factory while still unavailable for production. Define total, available, allocated, inspection, and quarantined quantities separately, then show operators only the state that changes their next action.
Receiving: decide the inventory state before adding quantity
The receiving screen must answer more than “how many arrived?” It must associate the physical goods with a PO or expected receipt, compare item and supplier, confirm the unit, capture the required lot or serial, and decide whether the stock enters inspection, hold, or available inventory. A case label may say one case while the order uses pieces and the inventory ledger uses kilograms. Record the source unit, stock unit, conversion basis, and any rounding. Do not embed a permanent conversion number in a device that may remain outdated after the item master changes.
When several lots arrive for one item, do not collapse them into one anonymous receipt. Capture the lot, expiry, serial, or handling unit required by the downstream process. GS1 Application Identifiers distinguish barcode data elements such as GTIN, batch/lot, and expiry, while SSCC identifies a logistics unit. The plant must still verify supplier labels and decide which standard it will use. Identifier selection is a separate design task; the transaction design here concerns what each scanned value means in the inventory ledger.
Show a specific result for “matches plan,” “short or excess,” “inspection pending,” and “label needs correction.” Define whether an over-receipt is rejected, accepted into hold, or accepted after purchasing approval. If a temporary lot is permitted, record who assigned it, when it must be resolved, and whether it can be issued. A formal hold state is safer operationally than an error screen that drives staff back to paper and later re-entry.
Put-away and transfers: confirm both ends of the movement
Handheld integration does more than replace handwriting. It lets the worker verify the actual goods and bin at the point of work. A compact put-away sequence is: scan received handling unit, scan destination bin, validate the combination, confirm completion. A warehouse transfer should verify the source and destination. Merely showing a suggested bin on screen does not prove the worker used it.
The location master can hold warehouse, zone, bin, allowed use, capacity, lot restrictions, quality state, and whether it is blocked. The device need not show every field. It should show instructions that alter the worker’s next action: “inspection only,” “mixed lots prohibited,” or “rescan destination.” Microsoft’s Dynamics 365 Supply Chain Management documentation provides examples of configurable batch, serial, license plate, and location confirmation for mobile work. That is a useful reference pattern, not a guarantee that all inventory products behave the same way.
Define the in-transit state as well. If the source bin is decremented but the destination is unconfirmed when Wi-Fi drops, where is the quantity? One approach is to hold it as in transit; another is to leave it at source until the full movement is confirmed. Whichever approach the plant chooses, avoid an invisible partial move. If another worker attempts to move or pick the same handling unit, the system should prevent a second posting and route the conflict to review.
Picking and production issue: control the order of confirmation
Shipping picks and material issues both remove goods from a bin, but their downstream effects differ. Shipping needs the customer order and destination. Production issue needs the production order, operation, BOM requirement, and traceable lot. A useful default sequence is instruction, bin, physical item, quantity, then confirmation. If “scan any item first” is required, give it a clearly defined process and permission rather than using it as an uncontrolled shortcut.
Record shortages and substitutions as exceptions, not silent quantity edits. The exception should identify shortage quantity, reason, substitute lot, approver, and disposition of the remaining instruction. Whether substitution is allowed depends on customer, quality, expiry, and FIFO/FEFO rules. Force lot or serial confirmation where the item requires it; adding needless scans to every low-risk item reduces compliance. Localize operator messages in the languages actually used on site, while keeping master IDs, transaction IDs, and error codes stable across languages.
After a confirmed pick, specify what happens to reservation and on-hand quantities and which ERP or MES event receives the result. An asynchronous interface may be valid, but the handheld’s “accepted” status then means the floor transaction was received, not that all downstream systems posted it. Show posting and interface states separately. Define what prevents a second issue while ERP acknowledgement is pending.
Cycle counting: keep the count separate from the adjustment
Do not overwrite the book balance as soon as an operator enters a count. The apparent difference may be caused by a miscount, goods in another bin, an in-transit transfer, or a shipment whose interface has not finished. Model count task, physical result, difference calculation, recount or investigation, approval, and adjustment as distinct steps. Microsoft’s cycle-counting documentation likewise describes mobile counting followed by review and resolution of differences.
Decide whether the operator sees the expected quantity. Showing it can speed entry but may bias the count. A plant could use blind counts for higher-risk items and visible counts elsewhere. If two operators count the same bin, define how their independent results are compared. If picking continues while counting, define the snapshot time: temporarily block the bin or reconstruct the quantity using transaction timestamps. A difference has no meaning without a consistent reference point.
Approval thresholds should reflect the plant’s actual risk and be agreed in the RFP. This article does not prescribe a universal number. Specify who may approve, what evidence is retained, whether the stock may be issued before approval, when the ERP receives the adjustment, and how corrections after the financial close are handled. Negative balances or differences in quality-hold stock deserve a separate exception route.
Offline work: the hard question is safe reconciliation
Metal shelving, building boundaries, and outdoor transfer routes can weaken wireless coverage. “Offline capable” is therefore too vague as a requirement. For each function, state whether work is permitted while disconnected, what is stored on the device, in what order it is resent, and who resolves a server rejection. Microsoft’s Field Service mobile documentation gives an example of separating offline data, synchronization state, and conflicts. It is a design analogy only; it does not establish that a warehouse application offers these functions. Test the candidate product on the plant’s actual devices and network.
Useful operator states include “in progress,” “saved locally, not sent,” “accepted by server,” “awaiting ERP,” “exception hold,” and “posted.” Keep an unsent count visible. Test battery loss, app restart, shared devices, and device loss. Store both device event time and server receipt time, since a wrong device clock should not determine the business sequence. Protect locally saved transaction data as part of the device management policy.
Use a stable client event ID and server-side idempotency to prevent duplicate receipts or issues after retries. If the same ID and content arrive again, return the first outcome. If the same ID arrives with different content, raise a conflict. For movements and issues, compare the inventory or work instruction version as well as the ID. If worker B consumes a lot while worker A is offline, do not silently force worker A’s queued issue into a negative balance. Put it into an exception queue for a responsible person. AWS’s reliability guidance describes idempotency tokens for retried state-changing APIs; the specific warehouse application of that principle is a proposed design.
Reconcile the handheld, WMS, ERP, and MES with evidence
Separate master-data interfaces from transaction interfaces. Item, units, warehouse, location, lot attributes, supplier, BOM, worker, and permissions are master data. Receipts, transfers, reservations, issues, shipments, and approved count adjustments are transactions. If a master update is late, a valid scan can still create wrong stock. Define how stale or inactive items are blocked and which master version supplies unit conversion.
For each transmitted transaction, retain origin event ID, send time, destination acknowledgement, status, error, retry count, and last successful time. A daily total balance alone can hide offsetting errors. Reconcile counts and quantities by document, item, and lot. For example, if ten floor events were accepted, nine posted in WMS, and eight were acknowledged by ERP, the dashboard should expose one held event and one interface failure. Those figures are an illustration, not measured industry data.
A handheld quantity update does not set the plant’s inventory valuation policy. The device collects physical evidence and transaction history; accounting treatment follows the approved ERP and finance rules. For unsent transactions crossing month end, agree how device event time, server posting time, and accounting date relate. Do not allow an ordinary operator screen to silently backdate a closed period.
Remove ambiguity from the data dictionary
An “item code” on a supplier label may not map one-to-one to an ERP item. If one supplier part can represent several internal items, use the PO and pack type to narrow the match before confirming. Distinguish supplier lot, receiving lot, and production lot, and define which one downstream quality searches use. Keep a stable internal location ID even if the displayed bin name changes, so historical transactions remain traceable. A device with an old location master should either validate the current block status before posting or hold its offline transaction for review.
Define quantity precision as well as unit. Pieces, measured kilograms, theoretical weight, and partly used packages need different rules. Specify conversion version, rounding point, and how residual fractions are handled. A failed interface transaction can be retried with the same event ID; a correction to an already posted transaction should instead refer to the original event and record reason, approver, and correction time. Silently overwriting posted history can break the link between the floor record and ERP journal.
Design screens and permissions around exceptions
Normal movements may take only a few screens. Exceptions consume much of the project effort: unreadable label, unexpected item, wrong lot, excess quantity, blocked bin, damage, shared device, or shift change. “Call the manager and fix it later” leaves a poor audit trail. Offer short exception codes and request a photo, note, or approval only when it helps resolve a particular case. Do not require a photo for every routine scan.
Separate permissions by action. An operator may post routine work and create a hold; a team leader may approve certain exceptions; an inventory controller may approve count adjustments; a system administrator may manage masters and retry queues. Log who changed a master and who approved a discrepancy. Shared hardware still needs individual identity. A common sign-in for all workers destroys the usefulness of an audit log. The Japanese and Thai screens can display different wording but must refer to the same event ID and error code.
Put transaction acceptance criteria into the RFP
Send vendors more than device counts and supported barcode types. Include current and proposed receiving, transfer, issue, and count flows; master and transaction fields; posting points and system of record; offline and retry behavior; exception and approval rules; audit requirements; and interface boundaries with ERP, MES, label printers, and access points. Ask them to mark each requirement as standard, configurable, custom development, or unsupported. A demo result should not silently become a contractual promise.
Include device replacement, spare units, battery management, MDM, OS updates, label media, training, integration changes, and support in the cost scope. Both cloud and on-premises choices need a factory outage procedure. Compare total implementation and operating cost based on a documented scope. Any price or payback estimate needs a site-specific quote and measured baseline.
FAT checks configured behavior with controlled master and transaction data. SAT checks the complete workflow with the actual bins, labels, wireless network, workers, and connected systems. Each case should state opening balance, actions, expected device message, expected WMS and ERP balances, audit evidence, and pass/fail rule.
| Test case | Required result | Failure example |
|---|---|---|
| Retry the same receipt after a disconnection | Same event ID, one stock increase | Quantity doubles |
| Scan a lot different from the pick instruction | Hold before posting; exception logged | Warning appears but issue posts |
| Move to a blocked destination bin | Hold; source and destination remain consistent | Only source balance falls |
| Enter a count discrepancy | Book balance stays unchanged until approval | Count overwrites book stock |
| Disable ERP interface | Queue, status, and retry result remain visible | Device says “complete” while failure is hidden |
Specify how all pilot transactions will be reconciled daily across device, WMS, and ERP. A proposed acceptance rule could require zero unexplained unsent, unposted, or duplicate events, with every exception assigned to an owner. This is a project criterion, not an industry average. Determine wireless coverage and response-time thresholds by measuring the actual factory.
Three easily missed SAT conditions
Test a real shift handover: a task started on one worker’s device must remain visible to the next authorized worker without rewriting who performed each action. Test imperfect labels from the actual factory: folds, dirt, curved packaging, protective film, and high shelf positions. If manual entry is allowed, verify its double-check or approval route and the relationship between a replacement label and the original. Finally, deliberately queue transactions while an access point is disabled, restore connectivity, and make some transactions fail because a master changed. Verify that the operator sees accepted versus rejected events, supervisors see the cause, and retrying the same event cannot double the quantity. Hand over a recovery procedure for both shop floor and IT teams.
Pilot one complete transaction chain
A PoC that measures scan speed on one screen cannot establish inventory accuracy. Choose one raw-material store and one production line, then run a complete chain: receipt, put-away, issue, balance reconciliation, and cycle count. Deliberately test at least one frequent exception such as over-receipt, wrong lot, disconnection, or shift handover. Scale the device count only after the exception path is visible and manageable.
If paper and the system run in parallel, state which is authoritative, who checks duplicate entry, and when paper ends. Otherwise, the workaround can become permanent. Adoption metrics should measure whether transactions close, not simply how many scans occur: unsent event count, age of exceptions, cause identification for stock differences, and time an ERP interface error remains open. Set targets after measuring the site baseline. At the end of the pilot, ask a worker to find a held event, an inventory controller to reconstruct a balance, and IT to show the retry outcome. Record exact UI friction such as extra taps, unreadable labels, and unclear error text; fix its process, network, label, or master-data cause before rollout.
Summary: ten checks before asking for a quotation
The integration specification should cover (1) the authoritative inventory system, (2) posting point for each process, (3) item, unit, and lot controls, (4) source and destination bin, (5) instruction versus actual result, (6) offline storage and retry, (7) duplicate prevention, (8) exception and approval, (9) ERP/MES reconciliation, and (10) FAT/SAT pass criteria. These checks turn competing vendor proposals into comparable transaction outcomes. For wider context, see our guide to inventory operations in Thailand and inventory discrepancy diagnosis.
Discuss your integration with TOMAS TECH. If your Thai factory needs to define handheld-to-inventory scope, prevent duplicate ERP postings, or prepare a transaction-based RFP and acceptance test, contact our team with your current process and systems. We can start by mapping one transaction chain and its exceptions.
References
- GS1 Application Identifiers: defined barcode data elements.
- GS1 Global Traceability Standard: traceable objects and identification levels.
- GS1 Logistic Label Guideline: logistics units and SSCC.
- Microsoft Learn: batch, serial, license plate, and location confirmation: an example of mobile validation.
- Microsoft Learn: cycle counting: counting and difference review.
- Microsoft Learn: offline data synchronization in Field Service: design analogy, not a warehouse-app feature claim.
- AWS Well-Architected: make mutating operations idempotent: retry-safe transaction principle.
