ERP–MES Error Monitoring and Replay for Manufacturers

When implementing an ERP–MES integration error monitoring and replay system for a manufacturer, the first question is not how many times an API should be called again. The operational question is who identifies a stalled production order, material issue, completion, or quality hold; who fixes the cause; when a replay is safe; and how both systems confirm the final business result. This guide gives production, quality, finance, and IT/OT leaders at Thai plants a practical framework for an exception work queue, reconciliation ledger, RFP, and FAT/SAT. Product features cited below are examples from official vendor documentation, not promises that every ERP or middleware behaves in the same way.

Separate a successful connection from a completed business transaction

An ERP sends an order to MES. MES executes the work and returns output and material consumption. A successful HTTP response or successful enqueue only proves a technical step; it does not prove that the receiver validated the master data and committed the transaction. An item may be rejected after receipt. Conversely, the receiver may commit the transaction and then lose the acknowledgment. The first case needs a data correction. The second needs a lookup before replay, or inventory and cost can be posted twice.

List the business facts covered by each interface: order release, change and cancellation; material issue, consumption and return; good, scrap and rework output; completion and receipt; quality hold and release; and corrections after financial close. For each fact, document the origin, authority to confirm, target, final document, and reversal method. Keep transaction IDs traceable before aggregating by day or factory. Our ERP–production management integration guide covers data contracts and system boundaries. This article concentrates on exceptions after the interface goes live.

Monitor business consequences as well as interface status

A dashboard showing only success rate and failure count cannot tell a supervisor whether today’s shipment or month-end close is at risk. Show whether an order exists in MES, whether MES completion links to an ERP production document, whether consumed quantity and units agree, and whether a held lot was incorrectly made available. Translate technical events into work that the plant understands. An alert should identify plant, line, order, item, lot, affected transaction, and last confirmation time, not just an API name.

Make the exception queue a work ledger, not a replay button

Each queue row should remain an accountable case until closure. Store source and target, interface and transaction type, business key, correlation ID, first occurrence, last attempt, attempt count, error class, quantity impact, state, owner, due time, approver, replay result, and the receiver’s committed document ID. Separate the business fields operators need from raw payloads accessible to authorized technical staff.

A useful state model might include new, investigating, waiting for business data correction, waiting for connection recovery, waiting for replay approval, replaying, awaiting reconciliation, closed, and quarantined. The names can differ. What matters are the conditions and permissions for each transition. Mark a case closed only after comparing the receiver’s committed result, not when a resend request has been accepted. If a message is intentionally discarded, retain the reason, approval, and treatment of downstream transactions.

The official Dynamics 365 Finance and Operations Business events documentation describes an Errors view and Resend action; unsuccessful outbound processing remains in the error log. Oracle Integration documentation, by contrast, says failed messages are not resubmitted automatically and describes limits based on flow type and recovery point. A product replay function is therefore only one part of an operating procedure. In the RFP, ask candidates to demonstrate where processing resumes, what content is retained, and which role can initiate recovery.

Classify errors by retryability and business impact

Timeouts, temporary connectivity loss, service outages, and rate limits may qualify for bounded retries. Unknown item codes, missing unit conversion, closed periods, and missing predecessor documents usually need a correction before repeating the same payload. When the acknowledgment is lost after the receiver may have committed, look up the business key at the receiver first. If its state cannot be established, stop automatic replay and route the case to reconciliation.

Impact is a separate dimension. A delayed analytics extract and a missing quality-hold release may show the same transport error but require different response times. Connect each exception to order, lot, monetary exposure, blocked downstream step, and remaining time before close. Use that impact to set priority and ownership rather than the retry counter alone. Microsoft’s transient fault guidance likewise distinguishes temporary failures from conditions that repeated attempts cannot resolve.

This is a starting taxonomy. Validate actual ERP, MES, and middleware responses during FAT before deciding which errors are automatic. Some product-specific client errors can include a valid retry instruction; a server error can still follow a committed transaction. Do not turn a broad HTTP status category into a business rule without testing.

Use business IDs and correlation IDs for different jobs

Keep a technical message ID, business transaction ID, and correlation ID separately. A message ID identifies a delivery attempt and may change on replay. The business transaction ID should stay stable when the same material-consumption request is delivered again; it is the foundation of duplicate prevention. A correlation ID helps investigators search related order release, consumption, completion, and receipt events. Also carry plant, order, operation, lot, line, business revision, occurrence time, dispatch time, and source state in the data contract.

A repeated network delivery of an unchanged completion is different from a new business revision that corrects the completed quantity. The first should use the same business identity and be idempotent. The second needs a revision, reason, approval, and link to the original or reversing entry. Overwriting JSON and resending it obscures which result was first reported and which was corrected. Confirm whether your ERP requires a reversal document or accepts an adjustment under its specific configuration.

Microsoft documents a control number in Dynamics 365 Business events that a consumer can use to detect duplicate delivery. That number alone does not guarantee that a particular MES–ERP implementation will avoid double posting. Define the boundary between saving the received identity and creating the business document, then test what happens if the process fails at that boundary.

Design replay around confirmation, not transmission

Limit automatic retries to eligible transient faults, with a finite attempt count, delay, and total deadline. Back off when the target is recovering and avoid a simultaneous retry surge from many senders. More attempts are not always better; test duplicate and downstream effects. Microsoft’s guidance discusses idempotency, exponential backoff, retry budgets, and logging. Adapt the settings to plant throughput and closing times rather than copying a vendor default.

For manual replay, use this order: look up the target’s committed state; correct the cause; display the difference between original and proposed payload; obtain approval; submit with the same business identity where appropriate; capture the target document; reconcile both ledgers; close the case. Record technical delivery and business reconciliation as separate outcomes. Keep the case open while reconciliation is pending. Restrict editable fields and log who changed each business value and why.

Azure Service Bus duplicate detection compares sender-defined MessageId values within a configured history window. Microsoft documents its limits and service-tier conditions. It is useful, but it is not universal protection against replay outside the window, delivery through a second path, or duplicate postings inside a receiving application. Validate business-level idempotency against the receiver’s committed records.

Decide how ordering, partial success, and period close work

If order release from ERP fails but MES sends completion, the target may have no order to reference. A material return can also arrive before consumption and make the balance wrong. Global ordering of all messages can block unrelated work. Decide which business key requires ordering: order, lot, or inventory location, depending on transaction dependencies. Hold successors of a failed predecessor and reevaluate them when the first case is resolved.

Some operations cannot be rolled back as a single technical unit. ERP may have committed material consumption while the response disappeared; MES may have finalized output while ERP receipt was rejected. Document the commit point of each system, compensating transaction, reversal document, and deadline for reprocessing. For a correction after period close, agree with finance whether an approved correction or next-period adjustment is required. The integration team cannot decide accounting treatment alone.

SAP Integration Suite’s official JMS retry example stores a message across a temporary external failure and processes it later. SAP’s queue documentation shows message states, retry counts, next retry time, and manual Retry. These are product examples, not generic guarantees. Verify that your chosen platform supports the needed retention, ordering, restart conditions, and authorization; add application controls for gaps.

Reconcile daily to find silent omissions

An exception queue cannot catch a transaction that was never extracted for sending. MES may hold a completion that the outbound job skipped, leaving no error log. Therefore compare business ledgers independently of interface failures. By order, compare planned quantity, MES output, ERP receipt, material consumption, scrap, holds, and reversals. Extract differences in count, quantity, unit, state, and update time. Add checks before shipment or close for critical transactions where a daily cycle is too late.

Define tolerances, conversions, time zones, late arrival, and close boundaries. Which side is authoritative varies by transaction; treating ERP inventory as automatically correct may erase an unposted shop-floor fact. For each difference retain original values, proposed correction, approver, target of change, and the second reconciliation result. Do not close a case after adjusting only one report by hand. Our WIP physical inventory control guide gives further context for reconciling physical work in process and records.

Monitor the reconciliation job itself. A zero-difference report must not hide a job that did not run. Display last run time, input count, period covered, and exclusions. Test holidays, night shifts, day boundaries, multiple factories, and catch-up processing after a network outage.

Assign a real owner and approval path

IT owns integration availability, logs, and technical diagnosis. Production judges order and output validity. Quality decides holds and releases. Warehouse owns stock moves. Finance decides close and cost impacts. Exceptions get stranded at the boundaries between these roles. For each case type name the first responder, correction owner, replay operator, approver, and reconciliation closer. Avoid permissions that let one person alter source data, replay, and close without an independent approval. Define an emergency delegate and next-business-day review.

At a Thai plant, local operators, regional IT, and a Japanese ERP administrator may cross time zones and holidays. Show local Thai time and UTC clearly. Handovers should carry business and correlation IDs, not only screenshots. Keep status codes consistent even when Japanese, English, and Thai labels differ; define exactly when “completion,” “receipt,” and “posted document” occur. Group notifications by priority, age, and owner rather than flooding individuals with repeated alerts.

Turn the operating model into concrete cases

Walk through an unknown completion outcome

Suppose a Thai plant approves completion of order A in MES and sends business transaction T to ERP. The connection breaks just as the ERP receives it. MES sees a timeout, so it cannot know whether ERP posted a document. Do not resend T under a new identity. Put it in the exception queue as an unknown outcome. Query ERP for a document matching order A, T, item, lot, quantity, and revision. If one exists, compare its committed quantity and status with the original MES record. If none appears, verify the search range and any delayed ERP processing before declaring that the transaction was not received. Only then consider replaying the original business identity and content.

If replay returns ERP document D, keep the case awaiting reconciliation until D’s receipt quantity and lot agree with MES. A technically successful response linked to the wrong lot remains a business exception. If a plausible document exists but lacks the key needed to prove identity, an owner must inspect document history and timestamps before replay. During a night-shift outage, production can preserve the physical label and lot, warehouse can avoid treating receipt as confirmed until the defined business point, and the morning ERP owner can take over with the correlation ID. The plant must decide its own interim physical movement rule. If paper or a spreadsheet is used temporarily, write T on that record and prevent a second manual entry after recovery.

Specify a reproducible data contract and the shop-floor boundary

A data contract needs more than field names and types. Specify required fields, length, unit, rounding, time zone, null semantics, code list, version validity, transaction identity, correction and cancellation semantics, ordering, receipt acknowledgment, and retention. If ERP and MES use different decimal precision, decide when rounding occurs and preserve both the original value and mapping version. Otherwise, a replay after a mapping change may no longer reproduce the original result. Address alternate parts, old item codes, plant-specific aliases, and time-limited unit conversions. Decide whether a delayed message is interpreted under the old or new mapping; if it represents a changed business fact, require an approved correction rather than silent remapping.

Distinguish “received,” “validated,” “business document created,” and “propagated downstream.” A product may not expose all these acknowledgments, so combine available responses, lookup APIs, and business reports. Retain both receipt and posted-document IDs when they differ. Also trace where MES got its original fact: scanner, scale, PLC, or inspection instrument. A count duplicated at the machine is a different fault from a single MES result posted twice in ERP. Some equipment cannot carry a business transaction ID; give its event an event ID, equipment ID, collection time, order and lot mapping when MES receives it. Separate raw sensor data from approved actuals and later corrections.

Offline terminals may upload a batch after connectivity returns. Local time alone is an unsafe key because device clocks drift and several events can share one timestamp. Consider a device sequence or event ID, and keep capture, MES receipt, and business approval times separately. Test the method on the actual line because devices differ. Make the intermediate state between “visible in MES” and “committed in ERP” clear to operators so they do not enter a waiting result a second time.

Connect alerts, permissions, and retention to recovery

An alert should show transaction type, affected order and lot, last confirmed point, next retry, owner, and decision deadline. When one root cause creates many failures, group them under an incident while retaining every child transaction; closing the incident does not reconcile the children. Show total backlog and oldest case age even if duplicate notifications are suppressed. Escalate by business deadline: quality before a release decision, finance before a close cutoff. Set thresholds from each plant’s measured latency and work hours, not an arbitrary universal number. Night-shift escalation also needs delegate rights and an interim procedure.

Viewing a payload, changing data, replaying, and discarding should have different permissions. Operators may need business keys without seeing personal data or authentication headers. Auditors need before-and-after values and approvals, not access tokens. State what must be masked, logged, and retained. A queue, case ledger, audit log, business document, and backup may have different retention periods. Before expiry, confirm closure or controlled quarantine and notify the owner. A restore test should reconstruct a named transaction’s history, not merely prove that backup files exist. On every master-data, schema, or closing-time change, test old queued messages as well as new ones and define rollback.

Put testable requirements in the RFP

Do not write only “integrate ERP and MES.” Provide transaction-level failure scenarios and expected evidence. Include interfaces, data contracts, business keys, origin and commit system, retention, error classes, state transitions, bounded automatic retry, manual replay rights, duplicate control, ordering, reconciliation, correction, audit logs, hours of support, incident communications, backup, and recovery scope. Ask bidders to separate standard product capability, configuration, custom code, third-party services, and manual operation in their quote.

Instead of asking whether an error screen exists, ask for a demonstration with representative orders and consumption events: business rejection after technical success; lost acknowledgment; duplicate delivery; absent predecessor; and post-close correction. See whether screen, log, API response, ERP document, and MES actual can be found under one correlation ID. A brochure screenshot does not prove that the recovery data will still exist when needed.

Set acceptance targets from your own volumes and business deadlines. Measure peak input, processing delay, age of unresolved cases, and time to reconciled closure, not just average API latency. Do not borrow another site’s numbers as a guaranteed service level. If the MES itself is also being selected, use our Thailand MES RFP, PoC and acceptance guide for the wider product decision.

Test failure behavior during FAT and SAT

During FAT, inject faults into representative transactions. Block the acknowledgment just after MES receives an order and see whether the sender records an unknown outcome. Send a material-consumption record with an invalid unit and confirm it waits for correction rather than retrying forever. Deliver the same business ID twice and check that the receiver has one document. Deliver completion before an order change and inspect the dependency hold. Attempt a corrected replay without approval. Define the expected outcome in advance and save screens and ledgers from both systems.

During SAT, include real plant networking, shift handovers, physical scans, ERP service hours, and local operators. Test how input is buffered during a short outage; whether the same lot is counted twice after recovery; and whether the morning owner can understand outstanding cases. Record differences between ERP test and production environments and specify extra monitoring for the initial live period. A passing FAT cannot prove that actual master data, permissions, or midnight boundaries work in the plant.

Keep each test as one evidence bundle: input payload, delivery log, queue state transitions, approvals, receiver document ID, reconciliation difference, and final result. Accept on no duplicate posting, traceable unresolved work, resolved differences, and reproducible audit history. Do not treat an unknown outcome as success simply because a dashboard is green.

Start small and measure operational debt

Replacing every interface at once makes causes and cost hard to separate. Begin with one plant, one product family, and two-way transactions such as order release and completion. Record baseline failures, manual reconciliation time, undetected differences, close adjustments, and approval time for replay. These figures differ by site, so this guide does not claim a universal savings rate or payback period.

A practical sequence is: define keys and commit points; collect logs and correlation IDs; configure queue classes and ownership; restrict automatic retries; implement approved manual replay; add ledger reconciliation; accept fault cases in FAT/SAT; then expand by transaction type while measuring performance. At each stage ask whether a real owner can close a real exception. This avoids a technically finished platform with a growing backlog.

Separate license, infrastructure, interface work, data contracts, master-data cleanup, operator screens, audit retention, testing, local training, support, and future change costs. Whether to build a queue or extend an existing integration product depends on contracts, retention rules, and rights to modify ERP and MES. No single architecture is always cheapest. Give every bidder the same end-to-end recovery scenario for comparable quotes.

At cutover, prevent the old and new paths from sending the same business transaction. Inventory messages already sent, committed, and unsent by business key. Reconcile them one by one after the switch. Use the same ledger in rollback and prevent a new-path retry from restarting as soon as the old path returns. Do not make “purge the queue” an incident procedure: that destroys evidence of the cause and impact. Define where expired cases are archived and who can restore them.

After go-live, assess more than failure count. Track automatic recovery, time to human intervention, backlog by cause, unreconciled items, recurrence, and differences carried into close. Fewer alerts are not progress if reconciliation stopped running or logs went missing. Use the review to improve mappings, master-data registration, classes, and approval bottlenecks rather than blaming the person assigned to the case. Confirm during FAT/SAT that these indicators can actually be collected.

Frequently asked questions

Are middleware logs enough for ERP–MES error monitoring?

Logs help diagnose technical causes. They do not by themselves prove that the receiver committed the business transaction or that the owner corrected and approved it. Link business keys and correlation IDs in logs to a case queue and a comparison of ERP and MES ledgers. Reuse existing product functions where they meet the operational requirement.

Which ERP–MES replays can be automated?

Eligible cases are transient faults where the target outcome can be checked, idempotency has been tested, and no business approval is needed. Corrections after close, quality-hold release, and changes affecting inventory or value should follow product and company approval rules. A vendor’s Replay button alone is not an automation policy.

Is a message ID enough to prevent double posting?

Not always. Broker duplicate checks have retention windows and path boundaries. A business correction must also be distinguished from a network resend. Design business transaction ID, revision, target document, and reversal link together; prove the result by delivering the same transaction more than once in FAT.

What should be ready before pricing an exception queue?

Prepare the target transactions and volume, current failure patterns, retention requirement, support hours, owners, ERP/MES API and data access rights, reconciliation reports, and acceptance scenarios. Otherwise bidders will price different scopes under the same phrase “monitoring and replay.”

Conclusion: make every stalled transaction explainable

An ERP–MES interface is operationally complete when the plant can identify a stalled transaction, show its business impact, correct the cause, replay safely, reconcile the committed results, and close the case with evidence. Define exception states, business keys, idempotency, ordering, reconciliation, rights, and audit per transaction, then test unknown outcomes and partial success in FAT/SAT.

TOMAS TECH can help Thai plants map their existing ERP, MES, and shop-floor terminals into an exception operating model, RFP, and fault-injection acceptance plan. If you are still evaluating options, we can start by tracing one production order end to end and listing the unresolved breaks. Contact us.

Sources

• Microsoft Learn: Dynamics 365 Business events overview.
• SAP Help Portal: Apply the Retry Pattern with JMS Queue.
• SAP Help Portal: Managing Messages Stored in Queues.
• Microsoft Learn: Azure Service Bus duplicate message detection.
• Microsoft Azure Well-Architected Framework: Recommendations for handling transient faults.
• Oracle Help Center: Resubmit Failed Messages.