Eliminate Duplicate Data Entry in a Thai Factory: MES, ERP and WMS

Replacing a paper form with a tablet does not, by itself, eliminate duplicate data entry. If an operator records output on paper, a supervisor copies it into a spreadsheet, an administrator enters it into ERP, and a warehouse clerk enters it again into WMS, transcription errors remain. The practical question is where each fact is confirmed once, by whom, and when it is passed to other systems. This guide turns that question into requirements, an RFP, and FAT/SAT acceptance tests for a factory in Thailand.

Map the same fact across the factory before changing screens

Production, finance and warehouse teams often hold similar numbers for good reasons. MES needs downtime and rejects; ERP needs cost and inventory; WMS needs box locations and quantities available for dispatch. The risk arises when each system accepts an independently edited “final” value. When totals differ, no one can tell which record is authoritative or who should correct it.

Trace one real production order through order release, material issue, production confirmation, inspection, packing, putaway and shipment. For every step record where the event first occurs, who confirms it, which application owns the record, where copies go, and when the event is closed. A copy displayed for reference is different from a second editable ledger. If a customer still requires a paper record, decide whether it is the original record or a printout of the electronic one.

For a broader review of roles and processes, see our production workflow redesign guide. This article focuses on repeated registration of the same manufacturing fact after the workflow has been defined. It does not cover invoice automation or a full historical system migration.

Assign a source of truth to each event

“ERP is the source of truth” is too broad. ERP can own orders and accounting without owning the timestamp of a machine stop. MES can own confirmed production output without owning a warehouse bin location. A source of truth is the system where a particular event becomes final, with explicit correction rights and history. Other systems may show the event, but should not silently create a different final value.

For an order, ERP can issue an order ID and revision to MES. Changes to quantity or due date are revised in ERP and acknowledged in MES; completed output is never overwritten by a later order revision. For material consumption, the operator scans the physical container at the point of use and confirms the issue in MES. ERP receives the consumption transaction rather than asking another employee to retype it.

The machine counter is not necessarily saleable stock. Inspection, rework and packing can occur before a good unit becomes finished inventory. MES may confirm completed production, while WMS confirms that a specific box exists in a specific location. ERP availability rules then consider both facts and any quality hold. Collapsing those states into a single number can make held goods appear available or create a pick instruction for goods that have not been put away.

ISA-95 provides a framework for information exchange between manufacturing operations, often including MES at level 3, and enterprise functions, often including ERP at level 4. It does not decide the owner of each event in your factory. Operations, quality, warehouse and finance owners must agree on that boundary.

What belongs in the ownership matrix

For each field, include the triggering event, person entering it, person approving it, source system, read-only destinations, closing point, correction rights, reconciliation key and contingency procedure. A good-quantity entry may be provisional when the operator records it, final after supervisor or quality approval, and amended only through a referenced correction event. The matrix must specify what ERP and WMS receive after a correction. “One entry” means one confirmation of a fact; it does not mean other teams cannot view it.

Prevent transcription errors with common IDs and units

Integration cannot reconcile a product known as “A-100” in one system, “A100” in another and a local-language name in a third without a mapping. Align IDs for item, production order, lot, box, pallet, machine, warehouse and bin. Display names may be Japanese, Thai or English, but internal IDs should be stable. Keep old codes and customer aliases in a mapping table, with effective dates where needed.

Barcodes reduce typing but do not define the source of truth. GS1 specifications include application identifiers such as AI (10) for a batch or lot. Whether you use GS1 or a proprietary code depends on customer requirements. In either case, parse the scanned value into item, lot, quantity, unit and packaging level, validate it against master data, and only then confirm the event. Plan for unreadable or incorrect labels and mixed-lot containers.

Pieces, cartons and kilograms must never be combined without explicit conversion. Store the version and effective date of a pack-size conversion. If cartons changed from one pack size to another, historical cartons must retain their original conversion. Preserve the source quantity and record corrections as differences, not silent replacements. Agree on the base unit and rounding before integration.

Give every business event an identity

An API or queue can deliver the same event more than once. If a sender retries after a timeout and ERP posts both messages, stock doubles. Assign a unique event ID at creation, reuse that ID on retries, and make the receiver record processed IDs. A correction references the original event and carries a new ID; it does not erase the original. Microsoft’s messaging guidance explains why consumers need idempotent processing when duplicate delivery is possible. This is an integration principle, not a recommendation for one cloud product.

An event should contain an ID, type, origin, occurrence time, confirmation time, business object ID, quantity and unit, revision, related event ID, actor or system ID, and payload schema version. Show Thai local time to operators, but exchange timestamps with a time-zone offset. This separates a night-shift production date from a calendar date, and the time an event occurred from the time someone entered it.

Not all events need the same timing. A downtime display may need a short delay; finished stock may be posted after inspection and packing; accounting may close daily. Specify whether each event is transferred when it occurs, is approved, is packed, or is included in a close. Set a tolerable delay and an owner for failures. Otherwise an employee may see an old value and re-enter it “just to be safe.”

Customer-facing order and shipment exchange is a separate boundary from MES-to-ERP integration. Our manufacturing EDI guide covers that external interface.

Put integration failures in an exception queue

Errors are inevitable: an unknown item, inconsistent units, a quality-held lot, an ERP outage or a duplicate box ID. If an error only appears in a technical log, the factory thinks the transaction succeeded while an office employee repairs the gap in a spreadsheet. That is how duplicate entry returns.

An exception queue should show event ID, source, order or lot, failed time, reason, owner, retry count, last response and current state. Distinguish open, investigating, ready to retry, resolved and manually corrected. Retrying must retain the original event ID. A manual correction must be linked to the failed event and require an approver, so that an automatic retry cannot silently double-post it later.

Prioritise by business deadline. A held lot blocking shipment may need immediate attention; a reporting delay may be handled before the daily close. Track unresolved age and count. Define who can resolve master-data errors, who can retry a technical failure and who can authorise a stock adjustment. If an offline terminal issues temporary IDs, map those IDs to server IDs after reconnection without creating new business events.

Keep an audit trail through downstream corrections

Record the old value, new value, reason, actor, approver, time, downstream systems affected and result of each resend. If MES output is corrected after ERP has posted stock, the audit trail should show whether ERP and WMS received the adjustment. Fixing a screen while downstream ledgers remain stale is not a completed correction. Restrict deletion and represent mistakes with cancellation or adjustment transactions.

Separate traceability from unnecessary personal-data display. Quality staff may need to know who confirmed a batch; every user does not need to see the operator’s personal details. Define retention from customer contracts, applicable requirements and company policy. Test that restoration from backup preserves event order and correction links.

Permissions should distinguish entry, approval, cancellation, retry, manual compensation and exception resolution. If a supervisor approves an MES event but an ordinary ERP user can change its copied value without reference to the source event, the ownership matrix is ineffective. Shared terminals need a practical per-person sign-in and shift handover procedure.

Adapt the design to a Thai plant

A Japanese headquarters ERP, Thai MES and locally managed WMS may be supported by different vendors. Include a system-boundary diagram in the RFP, with first-line support, diagnosis responsibilities and night-shift contacts. Localise error messages, exception screens, work instructions and training materials as well as the normal UI. Japanese and Thai display labels can differ, while the event ID and error code remain common.

Test the real terminal with gloves, dust, scanner distance and weak Wi-Fi. Fewer fields are not useful if one entry takes many confusing steps. Scanning an order should prefill item and unit; scanning material should identify a valid lot; a downtime reason should be selectable with a few taps. Define a backup terminal or paper procedure, and how contingency events keep their identity when imported later.

Thailand’s depa has published a survey showing varied levels of manufacturing digital adoption. The survey is useful context, not a diagnosis of a particular factory. Measure your own paper, spreadsheet, MES, ERP and WMS handoffs. If investment incentives matter, confirm current BOI eligibility for the specific project rather than assuming integration automatically qualifies.

Ten RFP questions that reveal hidden manual work

An “ERP integration: yes” tick box may mean a person exports and imports a CSV every day. Provide a real event and failure case, and ask each vendor to mark what is standard, configurable, custom or unavailable.

1. Which system confirms each order, issue, good unit, inspection, putaway and shipment event?
2. How are item, order, lot, box and bin IDs mapped to legacy codes?
3. How are pieces, cartons and kilograms converted, rounded and versioned?
4. At what business point is each event sent, and what is the maximum acceptable delay?
5. How will three deliveries of one event produce exactly one stock and output effect?
6. What happens if a correction arrives before the original event?
7. Who can view, resolve, retry and approve items in the exception queue?
8. How are original values, reasons, approvers and downstream effects audited?
9. How are production and messages recovered after a network, ERP or terminal outage?
10. What are the separate costs and responsibilities for connectors, monitoring, support and changes?

Request a sample payload, field mapping, exception screen, audit log and test plan. Compare multi-year costs for software, API usage, terminals, data retention, interface changes and night-shift support. If the incumbent system is poorly documented, a limited discovery and connection test can establish facts before a fixed implementation quotation.

Prove “no re-entry” in FAT and SAT

FAT can use simulated systems; SAT must repeat the relevant tests with actual terminals, network, labels and incumbent systems. Define initial state, action, expected result, evidence, tester and retest condition. Do not treat a successful API response as proof that a ledger posted correctly: distinguish sent, received, business-validated, posted and reconciled.

Reconcile by event ID, order, item, lot, box, quantity, unit and state, not only grand totals. One duplicate and one omission can cancel out numerically. Measure how often staff re-enter a fact, sent and posted counts, unresolved exceptions, reconciliation differences and time to resolution. Values and acceptance thresholds must come from the factory’s baseline and contracts; no universal performance figure is implied.

Pilot, switch over and monitor

Define the denominator before reporting benefits

Decide what counts as a re-entry. If a good quantity is confirmed once and then typed into two other screens, count one original confirmation and two repeated entries. A barcode verification scan or quality approval is not repeated typing of the same number. A person who exports a CSV, edits it and uploads it elsewhere is still performing a manual registration step even without typing directly into a form. Keep this definition constant before and after the pilot.

For the same lines and event types, record events generated, original entries, repeat entries, manual corrections, pending events, reconciliation differences and operator time. Observe representative work rather than relying only on estimates. Include night shifts and period-end closing. If repeat entry falls but pending exceptions rise, the problem has moved rather than disappeared.

Separate an indicative value for time saved from actual cash savings such as reduced overtime. Time reassigned to quality checks is useful but does not automatically reduce payroll. Also distinguish a measured reduction in errors from an expected reduction in rare shipment incidents. Management reports should show re-entry rate, successful postings, age of unresolved exceptions and event-level reconciliation, with critical exceptions highlighted.

Start with one product group and line. Count current re-entry points, approve the ownership and ID matrices, and ask shop-floor and warehouse owners for exception cases. Integrate one frequent, high-impact event first, such as finished-goods putaway. Complete deduplication, exception handling and corrections before adding other flows. Include a night shift, network outage, quality hold and reprinted label in the pilot.

Review weekly exception count, manual adjustments, inventory differences and retry volume. During parallel operation, state explicitly which ledger is authoritative. Before retiring paper or spreadsheets, confirm retention, backup, contingency, unresolved-event cutover and rollback rules. Historical migration is a separate project; the purpose here is to prevent the new process from recreating duplicate entry.

FAQ about duplicate entry and ERP integration

Must we replace ERP first?

Not necessarily. An existing ERP that accepts reliable API or file transactions with event IDs and corrections may be usable. Map repeated events and test the incumbent’s interface before deciding on replacement.

Will barcodes alone prevent transcription errors?

They reduce typing but do not prevent wrong labels, unit mismatches, repeat scans or premature stock posting. Combine scanning with master-data validation, event identity, approval and exception handling.

Must MES-to-ERP integration be real time?

Not for every event. Monitoring may need short latency, while inventory may wait for quality release and finance for the close. Define a confirmation point and acceptable delay per event.

Can paper remain?

That depends on customer contracts, regulation and internal rules. A required paper copy may be generated from an electronic source. If people still write on paper and retype the same fact, specify which record is authoritative and how differences are corrected.

What is special about linking a Thai factory to a Japanese headquarters ERP?

Test time zones, production-day boundaries, Thai error messages, local support hours, item codes, units and recovery after disconnection. The Thai plant should send confirmed events with common IDs; headquarters should see their status and exceptions without re-entering them.

Conclusion

Eliminating duplicate entry starts with event ownership and confirmation points. Stable IDs, unit rules, idempotent delivery, exception queues and traceable corrections make automatic integration dependable. An RFP should ask about outages and corrections as well as normal transactions; FAT/SAT should measure re-entry and ledger differences.

If your Thai plant enters the same shop-floor fact into daily reports, MES, ERP and WMS, contact TOMAS TECH. We can help map the current handoffs and turn an ownership matrix into testable integration requirements.

Sources

• ISA: ISA-95 Enterprise-Control System Integration
• GS1 Application Identifiers
• Microsoft Learn: Asynchronous Messaging Options
• Microsoft Learn: Publisher-Subscriber Pattern
• OPC Foundation: OPC UA Overview
• depa: Thailand Digital Density Survey
• Thailand BOI: Smart and Sustainable Industry

*Based on public information available in October 2026 and general integration practice. Confirm legal, customer, retention and acceptance requirements for each project.*