Pilot ERP and shop-floor integration for duplicates, delays and conflicting records
For operations leaders, IT teams and integration owners · Plan implementation
TL;DR — what you’ll learn
- Define which system owns each business fact before exchanging events.
- Use stable event identity, explicit version/correction rules and independent reconciliation.
- Pilot one event flow between two systems with timeout, duplicate and out-of-order tests.
- Keep recovery owned and observable; a delivered message does not prove a correct business state.
A shop-floor system sends a completion to the ERP. The ERP commits it, but the response is lost. The sender retries and creates another completion. On a different day, an older correction arrives after the current one and restores the wrong quantity. Both failures can occur while the network appears mostly healthy.
Manufacturing ERP integration needs a business event contract and recovery design. Start with the meaning of the event, its authority and the required effect, then decide how it travels.
Distinguish a new event from another delivery
For an illustrative cumulative-completion flow, revision 1 of job J8 reports 40 completed units. An authorised revision 2 corrects that cumulative quantity to 35. These are complete snapshots for a cumulative reporting view, not incremental stock or accounting movements. In this rehearsal, an authorised revision 2 can establish the view even if revision 1 has not arrived. A target ERP ledger may require different correction operations and predecessor checks.
| Arrival | Required interpretation |
|---|---|
| J8 revision 1: cumulative 40 | Apply once under the event contract |
| Retry of the same event | Return/record the existing result; no extra 40 |
| J8 revision 2: cumulative 35 | Apply the authorised correction using the target's supported method |
| Late replay of revision 1 | Retain evidence; do not restore the stale 40 |
The agreed final cumulative view is 35, not 75. If the real interface sends increments, design a different contract with unique movement identities and explicit reversals. Mixing snapshots and increments is a semantic error that retries cannot repair.
Microsoft's Service Bus documentation describes message-ID-based duplicate detection with a configured history window. Its duplicate key uses the message ID and, with partitioning enabled, the partition key; it does not compare the business payload. Broker deduplication therefore has a boundary; the application still needs business reconciliation and controls against repeated effects beyond that window. Microsoft duplicate detection.
Recover the business effect, not just the message
Scroll horizontally to explore the full diagram, or open the text version below.
Read the complete workflow as text
- Versioned business event at intake → Same event ID has conflicting payload?
- Same event ID has conflicting payload? → Yes: Retain conflict for owner review
- Same event ID has conflicting payload? → No: Validate semantics authority and version
- Validate semantics authority and version → Already applied or stale?
- Already applied or stale? → Yes: Retain prior outcome or stale-event evidence
- Already applied or stale? → No: Apply through supported target operation
- Apply through supported target operation → Outcome certain?
- Outcome certain? → No: Look up and reconcile before replay
- Outcome certain? → Yes: Compare source and target business state
- Compare source and target business state → Mismatch: Look up and reconcile before replay
Scope one flow and its source of truth
Pilot one production event between two named systems using approved APIs or files. Include validation, application result, exception queue, reconciliation and replay. Exclude direct machine-control writes and unrelated master-data synchronisation.
The event contract needs source system, event ID, business key, event type, quantity/unit, revision or correction reference, event time, capture time, schema version and authorisation status. Decide which system owns completion, quality disposition and financial posting; they may have different owners.
Production owns the meaning of completion. Quality owns release where applicable. Finance owns posting rules. IT operates delivery, permissions and monitoring. The exception owner must be able to involve the business owner when a technically valid message is operationally wrong.
Make the ambiguous outcome recoverable
Use a stable business-operation key and a target lookup or ledger that can establish whether a timed-out request already took effect. Where supported, record the effect and its processed identity atomically. Do not promise exactly-once delivery across an unreliable network; demonstrate one intended business effect under the defined retry cases.
An immutable event ID must retain the same business payload. Compare retained semantic fields or a canonical payload fingerprint at the application intake, before broker deduplication can discard a conflicting message. The same ID with a different quantity is an exception, not a successful retry; an authorised correction needs its own identity and revision. AWS describes retaining request parameters and rejecting mismatches under a reused request ID. That is a supporting API design pattern, not a guarantee that the selected ERP implements it. AWS idempotent API design.
Version rules must account for whether a newer snapshot can stand alone or needs earlier history. Park incomplete sequences when the contract requires a predecessor. Preserve conflicting messages for review instead of picking the latest arrival time as truth.
For partial writes, record each completed step and the approved recovery action. An ERP movement already posted may need a controlled reversal, not deletion. Reconciliation should compare business quantities and identities from independent source/target reads, not merely count acknowledgements.
Test inside the operational boundary
NIST's OT guidance addresses security alongside performance, reliability and safety requirements. Use that context when reviewing access and connectivity with the plant's engineering/security owners. NIST SP 800-82 Rev. 3.
Baseline unexplained source-target differences, recovery time and failure visibility for the selected flow. A newly visible exception count may initially rise because monitoring improved; do not label that a deterioration without examining the underlying events.
Run shadow reconciliation before controlled writes. Test duplicate delivery, a reused ID with changed payload, commit-then-timeout, delayed version, missing predecessor, partial write, unavailable target and authorised correction. Deliver revision 2 before a previously unseen revision 1 as a separate case; duplicate-ID detection alone cannot catch that stale version. Require the J8 result to reconcile to 35 and each attempted delivery to have a visible outcome or owned unresolved state.
Accept the bounded pilot only when the seeded cases preserve the intended business effect, reconciliation detects the deliberately introduced differences and the business/IT owners can execute the recovery procedure. Agree any recovery-time improvement target after measuring the baseline; passing a happy-path transfer is insufficient.
Native connectors are useful if they expose the required semantics and recovery. Middleware can manage transport, but it cannot choose business ownership. A custom adapter is justified when the supported boundary needs additional validation or reconciliation. AI may summarise an exception for an operator; it should not invent corrective postings.
On failure, pause affected writes, preserve events and use the approved manual handover. Resolve ambiguous outcomes before replaying. Resume only after source and target agree at the defined checkpoint or authorised exceptions are documented.
The pilot succeeds when a failed message leads to a controlled, explainable recovery. Healthy integration is a reconciled business state, not just a green transport status.
- Define one event's meaning, authority and correction model.
- Rehearse the ambiguous timeout and stale-version cases.
- Agree reconciliation and recovery ownership before enabling controlled writes.
Discuss this integration pilot with NextEdge Labs using the two systems, event flow and failure that currently requires manual reconstruction.
Scope this automation around your operation
Tell us your current systems, transaction volume and the exception you need to resolve. We can discuss a focused first release, its review controls and how to measure the result.
Sources and further reading
Sources checked 15 October 2026. Worked examples and workflow diagrams are original illustrations, not reported client results.