ERP–Production Management Integration: Data Contracts, RFP and 90-Day PoC

The difficult part of ERP–production management integration is not opening an API. It is deciding what happens when an ERP production order is sent to a production-management system or MES and material consumption, output, scrap, and holds return to ERP: which system is authoritative, how duplicate posting is prevented, how out-of-order events are handled, and how cancellation remains auditable. This guide is for production, finance, supply-chain, and IT/OT leaders at factories in Thailand. It turns system of record, identifiers, retries, offline operation, period close, cost reconciliation, RFP requirements, a 90-day PoC, and acceptance into one practical method.

This is not a ranking of MES products or a cloud-versus-on-premises comparison. It focuses on keeping business transactions intact between an existing ERP and an existing or new MES. The central recommendation is to assign one authoritative owner per business object, separate commands from facts, include a unique transaction ID, version, occurrence time, and reversal link in each message, and design retry and reconciliation as normal operation.

How to read the numbers: facts attributed to IEC, ISA, OPC Foundation, ISO, GS1, NIST, and BOI come from primary or standards-body sources. The 90-day plan, P95 targets of 2 seconds and 500 ms, zero duplicate postings, 99.5% availability, RPO/RTO values, costs, and ROI are proposed examples—not industry benchmarks or guarantees.

Establish the ERP–MES boundary before selecting technology

ISA-95 describes Level 4 as business planning and logistics, including ERP, and Level 3 as manufacturing operations management, including MES. IEC 62264-2:2026 specifies interrelated conceptual object models for interface content exchanged between Level 3 manufacturing operations and Level 4 business functions. Its stated purpose includes reducing interface implementation risk, cost, and errors.

That boundary is not merely an architecture diagram with ERP above MES. It assigns responsibility: who creates a production order, who schedules equipment and shifts, who authorizes execution, and who records financial inventory and cost. If responsibility is not fixed first, both systems edit the same quantity and one correction silently overwrites the other.

Assign a system of record by business object

This table is a starting point, not a universal answer. PLM, WMS, QMS, or LIMS may own some objects. The essential rule is to avoid “both systems may edit.” Name the accountable role and service level for creation, approval, distribution, correction, and retirement.

Our Thailand MES selection, RFP and acceptance guide covers selection of the MES itself. This article covers the contract that lets orders and actuals travel between that MES and ERP without corrupting the transaction. Separate the product scorecard from the integration scorecard so an attractive interface cannot conceal unreconciled month-end balances.

A data contract is a business promise, not a field list

A data contract must define meaning, owner, unit, version, event condition, order, retry, reversal, and error responsibility in addition to field names and types. quantity=10 is ambiguous: ten pieces or kilograms, ten good units or total output, cumulative ten or an increment of ten?

A minimum common message envelope

• message_id: globally or operationally unique message identity
• business_object_id: order, actual, movement, or other business identity
• event_type: Released, Started, Consumed, Completed, Cancelled, etc.
• schema_version: version of the message structure
• object_version: revision of the same business object
• occurred_at: time and time zone of the physical/business event
• recorded_at: time the source system recorded it
• source_system and source_site
• correlation_id: groups the command, responses, and resulting events
• causation_id: identifies the message that caused this event
• reverses_id: links a cancellation or correction to the original transaction

GS1 EPCIS 2.0 distinguishes unique event identity, event time, repository record time, and local time-zone offset. This does not mean every ERP–MES interface must implement EPCIS. It is a useful standards-based example of why one timestamp and one local sequence number are insufficient.

Separate stable identity from display codes

When a Thailand plant and Japanese headquarters use different codes for the same item, a simple lookup spreadsheet becomes fragile. Use a stable internal identity and treat ERP code, MES code, legacy code, and customer code as aliases with effective dates. Unit conversion needs not only a factor but also rounding, smallest unit, effective date, and item-specific rules.

ISA-95 Part 7 addresses a technology-independent alias-service model for equivalent identifiers and context across namespaces. An implementation need not purchase a specific standards product, but it should govern alias ownership, collisions, merges, splits, and retirement explicitly.

Do not combine commands and actual events into one status update

An ERP production order is a command. A production actual returned from MES is a report of something that occurred. When both are reduced to updates on one shared status table, it becomes unclear who advanced the state, where processing failed, and what a cancellation must reverse.

A robust basic flow is:

1. ERP releases an order with a unique object version.
2. The integration layer validates syntax, required IDs, unit, and effectivity.
3. MES accepts it and safely returns the same result for a duplicate order/version.
4. MES schedules the operation, equipment, and shift.
5. Shop-floor events are recorded as increments.
6. ERP posts each actual idempotently.
7. Receipt, business posting, and rejection are returned as different states.
8. Daily reconciliation compares remaining quantity, material, good output, rejects, and scrap.

An HTTP 200 response means transport receipt, not successful business posting. Separate transport acceptance, schema validation, business validation, ERP document creation, and accounting-period acceptance. Return the result time, reason code, and created ERP document ID.

Treat duplicates, reordering, and cancellation as normal operating states

Networks and queues produce retries and out-of-order delivery. Do not accept an “exactly once” product claim as a business guarantee. Accept an application design in which the same business transaction is posted once even when delivery is repeated.

Make retry harmless with an idempotency key

For material consumption, a business key might be site + order + operation + material_lot + sequence. Repeated delivery of the same message_id must return the prior result rather than create another document. If the business key matches but quantity or unit differs, do not overwrite it; route the conflict to review. The deduplication retention window must exceed the longest realistic offline period and fit audit requirements.

Stop out-of-order changes with versions and prerequisites

Completed can arrive before Started, or revision 3 before revision 2. Check object version and allowed state transition, and hold an event whose prerequisite is missing. Sorting only by receive time confuses network delay with the physical sequence. Combine occurred_at, operation sequence, and object version.

Reverse instead of deleting

Deleting a posted consumption or output removes the audit path. Create a reversal that references the original transaction and posts the opposite quantity/value, then add a corrected event if needed. A reversal for a closed accounting period may require an adjustment in the next period, so align ERP accounting rules with quality and production records. MES “reopen” must not silently delete an ERP document.

Keep incremental, cumulative, and state quantities distinct

A common failure occurs when MES sends cumulative output of 10 while ERP posts increments of 10 at every message. State explicitly whether a field is delta_quantity or cumulative_quantity, with unit and sign. Cumulative interfaces need the previous accepted value and reset rules. Incremental interfaces need missing-event and duplicate monitoring.

Separate good, reject, scrap, rework, and hold

If total output is ten with eight good, one reject, and one quality hold, ERP should not receive ten unrestricted finished goods. Map each quantity state to its inventory status and location. A later quality disposition becomes a separate event. Decide by product family whether rework returns to the original order or uses a rework order.

Preserve causality between consumption and output

In backflush processing, ERP may calculate standard BOM consumption from completed quantity. In other processes, MES sends actual lot consumption. Enabling both produces double consumption. Maintain a matrix by item and operation for backflush, actual issue, and variance adjustment; carry the BOM revision and physical material lot.

Make daily reconciliation and period close part of the interface

Integration is complete when ERP and MES business balances are explainable, not when messages appear in a queue.

Show count, amount, aging, cause, replay attempts, and period-close impact in a shared dashboard. Leaving differences to “self-correct tomorrow” concentrates manual work at month end. Production, finance, and IT should follow the same transaction ID in one unresolved-posting queue.

Our manufacturing cost management and 90-day PoC guide explains how to move cost variance from a month-end surprise toward a daily decision. Integration acceptance should use the same case to trace quantity, standard/actual cost, WIP, and scrap effects.

Design offline queues and retries for factory interruption

Whether a station continues locally or stops when the network fails is a business-risk choice. “Offline capable” is insufficient. Specify what is cached, for how long, which order version remains executable, the queue limit, the replay order, and how duplicate effects are prevented.

Transactional outbox and inbox pattern

The sender commits the business change and an outbox record in one local transaction. A service delivers the outbox message. The receiver records message_id in an inbox before or with business processing. If an acknowledgment disappears, the sender can retry; a receiver that already processed the message returns the earlier result. This is an implementation pattern, not a property automatically guaranteed by a database or broker. Prove it with failure injection.

Define retention and recovery priority

Set terminal/server queue capacity, encryption at rest, power-loss behavior, clock drift, and expiration of stale commands. On recovery, dependencies may require master-data version before an order change, then cancellation, start, consumption, and completion. Do not rewrite physical event time merely to satisfy receive order. Hold unresolved prerequisites for controlled review.

Protect the enterprise–OT boundary

NIST SP 800-82 Rev. 3 provides OT-security guidance while considering performance, reliability, and safety requirements. Avoid broad direct write access from ERP to PLC. Validate and authorize a business command in a managed Level 3 service and convert it into only the minimum control information required.

The RFP should cover segmentation, mutual authentication, service-account ownership, secret storage, least privilege, allowed APIs, certificate renewal, logging, vulnerability response, remote maintenance, backup, and recovery exercises. Measure the effect of security controls on cycle time and availability on the actual factory network.

Master-data quality is a continuing process

ISO 8000-61:2016 specifies processes required for data-quality management and can support improvement and capability/maturity assessment. ISO’s page states that the edition was confirmed in 2022 and remains current. That does not create an automatic quality score; it supports treating quality as a managed process rather than a one-time migration cleanup.

Measure uniqueness, completeness, cross-system consistency, validity, timeliness, and traceability. A successful initial count does not prevent deterioration when a new item, BOM revision, substitute, or machine is introduced. Operate change request, approval, distribution, acknowledgment, comparison, and rollback.

Mandatory sections of an ERP–MES integration RFP

1. Business scenarios and exclusions: make-to-order, make-to-stock, batch, continuous, rework, subcontracting; state what planning, control, quality, and costing are outside scope.
2. System-of-record matrix: assign create, approve, update, cancel, and read responsibility by object and critical field.
3. Data contracts: schema, required fields, units, codes, time zone, versions, positive/negative examples, size, frequency, retention, and personal data.
4. Transaction integrity: idempotency, ordering, delay, partial success, reversal, retry count, dead-letter queue, manual replay, and audit.
5. Nonfunctional operation: peak rate, P95/P99 response, batch deadlines, availability, RPO/RTO, monitoring, clock sync, maintenance, language, and incident ownership.
6. Security and OT constraints: path, authentication, encryption, rights, secrets, logs, remote access, patching, forbidden PLC changes, and safety boundaries.
7. Testing, migration, and exit: replay, reverse order, closed period, unit mismatch, power/network failure, parallel run, rollback, and return of data/configuration/source at contract end.

Accept the interface through a 90-day PoC

The following 90 days is a proposal. Adjust it around ERP freezes, plant shutdowns, audits, and financial close.

Limit the PoC to one factory, product family, and production mode, but do not limit it to one successful path. Cut the connection just before a consumption response, resend the same completion 100 times, send cancellation before completion, close the ERP period, shift the MES clock, and change a unit conversion. The buyer—not only the vendor—must own the destructive test pack.

Acceptance criteria must prove business result and recovery

These are proposed examples to be adjusted for cycle time, volume, and accounting or quality obligations.

Require machine-readable evidence that reconstructs ERP document, MES event, retry, reversal, and approval from one correlation_id. Matching totals without explainable individual transactions is not sufficient.

Estimate cost and ROI by complexity, not interface count

Separate business analysis, master-data remediation, API/message implementation, integration platform, ERP changes, MES changes, test data, failure testing, monitoring, training, parallel run, and support. One interface can be complex when it includes reversal, multiple units, lots, and closed periods. Many events can be economical when one contract and shared components are reused.

Illustrative ROI—not a market price

Assume reconciliation and re-entry consume 700 hours per month at THB 180/hour and avoidance of posting errors, inventory differences, and emergency work is worth THB 220,000/month. Gross benefit is 700×180+220,000 = THB 346,000/month. With THB 4,200,000 implementation and THB 90,000 monthly operation, simple payback is approximately 16.4 months: 4,200,000÷(346,000−90,000). Every value is hypothetical. Recalculate conservative, expected, and upside cases after the PoC.

Thailand implementation conditions

Use common machine-readable reason codes—such as UNKNOWN_ITEM, UNIT_MISMATCH, CLOSED_PERIOD, DUPLICATE, and MISSING_PREDECESSOR—with operator explanations in Thai, English, and Japanese. Never translate the code itself.

Thailand is UTC+7 and Japan UTC+9. Plant operating day, accounting close, server time, event time, and record time can disagree around night shift. Store time-zone-aware timestamps and calculate production_day from the plant calendar instead of splitting every day at midnight.

Divide support into L1 operating procedure, L2 queue/master/integration, and L3 product or code correction. Define support windows in Thailand time, holidays, severity, first response, recovery, and escalation. A shared transaction ID and joint incident exercise prevent ERP and MES vendors from simply blaming each other.

Seven common failures and corrections

1. Synchronizing internal database tables: use a business API/message contract that survives product upgrades.
2. Mapping item code only: govern identity, alias, unit, revision, effectivity, lot status, and site.
3. Treating transport success as posting success: return separate receipt, validation, posting, rejection, and document ID.
4. Creating duplicates with a replay button: implement message/business idempotency and test 100 repeats.
5. Deleting cancelled actuals: post a linked reversal and correction to preserve audit and cost.
6. Completing the PoC on the happy path: inject reorder, outage, period close, and unit mismatch.
7. Writing from ERP directly to PLC: validate at Level 3 and expose the minimum required control interface.

Compare vendors with one common test pack

A proposed weighting is 20 points for system of record and data contract, 25 for transaction integrity, 20 for ERP/MES implementation, 15 for operation and reconciliation, 10 for OT security, and 10 for five-year TCO. Make duplicate posting, unauditable reversal, undefined ownership, and excessive ERP-to-PLC rights minimum gates regardless of total score.

Give every bidder the same order and event pack. Run success, duplicate, reverse order, missing message, cancellation, unit change, closed period, and network loss. Compare created documents, remaining quantity, queues, audit chain, and recovery time—not screen appearance.

FAQ: ERP–production management integration

Which should be the system of record, ERP or MES?

Decide by business object, not by entire system. ERP often owns production order, financial inventory, and cost; MES often owns operation execution and actual events. Adapt that pattern to existing PLM, WMS, QMS, and governance.

Must ERP–MES integration be real time?

No. Define latency by decision deadline: seconds for execution authorization, minutes for output posting, perhaps daily for cost aggregation. Integrity of order, retry, and reconciliation is more important than making every flow fast.

Should production actuals be cumulative or incremental?

Either can work, but never mix them without explicit semantics. Cumulative values require previous accepted value and reset behavior; increments require loss and duplicate control. Always carry quantity type, unit, sign, and disposition.

How should cancellation work in core-system integration?

Do not delete the original. Post a reversal linked to its ID and then a corrected event if needed. Closed periods must follow ERP accounting policy with an approved adjustment path.

How do we prevent duplicate posting after offline replay?

Persist a unique message ID and business key so the receiver can return a stored result. Implement outbox/inbox, retention, expiry, ordering, dead-letter, and controlled replay; test connection loss and 100 identical messages.

How should ERP integration cost be estimated?

Estimate by objects, master data, reversal, multiple units, lots, close, offline behavior, failure testing, monitoring, and support—not API count alone. Compare a one-flow PoC with a separate five-year rollout TCO.

What must a 90-day PoC deliver?

Require the SoR matrix, data contracts, ID/alias dictionary, message/API specification, positive and negative evidence, reconciliation, recovery exercise, runbook, training, issue list, and rollout TCO.

Conclusion: reconcile transactions, not just interfaces

ERP–production integration is not complete when data moves. It is complete when production order, material, output, reject, inventory, and cost describe the same business facts in the factory and core system. Put authority, ID and aliases, command and event, version, order, idempotency, reversal, reconciliation, and offline recovery into the data contract.

TOMAS TECH can support a Thailand factory from mapping an existing ERP, MES, and paper process through data contracts, an RFP, and a 90-day PoC with failure testing. Before a full replacement, we trace one production order end to end and make the breakpoints visible. Contact TOMAS TECH.

Sources

• IEC 62264-2:2026
• ISA-95 Series of Standards
• OPC UA Common Object Model: ISA-95
• OPC Foundation: ISA-95
• ISO 8000-61:2016
• GS1 EPCIS 2.0
• NIST SP 800-82 Rev. 3
• Thailand BOI: Q1 2026 investment applications