Order Processing: The ERP–MES Handshake

What is order processing in manufacturing?

Order processing in manufacturing is the end-to-end handling of a production order from the moment it is released in the ERP to the moment the finished quantity, time consumption and quality data are written back. In a modern plant, it is not a linear "process" in the sense of a workflow diagram. It is a data handshake between two systems — the ERP that owns the order definition, and the MES that owns the execution — with the shop floor operating in the middle. Getting the handshake right is the difference between a plant that knows the status of every order at every second and a plant that still calls the foreman to find out where job 4711 is.

I have spent the last twelve years building the ERP-MES integration layer inside the SYMESTIC platform — SAP R/3 and S/4HANA via ABAP IDoc, Infor via BOD and REST, Microsoft Dynamics and Navision via file and OData, proAlpha via its native interface. The pattern looks different in every ERP, but the underlying architectural question is always the same: which system is authoritative for what, and how do the two agree on reality. This article is about how order processing actually works when it works, and why most implementations fail not at the surface level but at the data model one layer below.

The ERP-MES responsibility split — the clean boundary

The first and most important decision in any order-processing architecture is not technical but organisational: which system owns which part of the order lifecycle. Getting this boundary wrong is the root cause of roughly three-quarters of all failed MES integrations I have seen. The following split is the one that works in practice and scales cleanly across every ERP-MES combination.

The rule behind the rule: the ERP is the system of record for commercial reality (what was ordered, what must be delivered, what it costs). The MES is the system of record for physical reality (what actually happened on the machine, when, for how long, in what quality). Neither system should ever try to do both. Every integration pathology I have debugged in the last decade has its root in a violation of this boundary — an MES that tries to do capacity planning because the ERP's MRP is too slow, or an ERP that tries to track machine status because the MES is not trusted. When the boundary breaks, the data diverges, and within six months nobody knows which system is telling the truth.

The order lifecycle as a state machine

The second precondition for order processing that works is a clean state model. Every order in the MES passes through a small number of well-defined states, with explicit transitions and explicit events that trigger each transition. Hand-waving this into a vague "in progress" flag is how plants end up with orders that have been "running" for three weeks after they actually finished.

The working state model has exactly seven states. Imported — order has arrived from ERP and is ready to dispatch. Dispatched — order is assigned to a machine and scheduled but not yet started. Setup — operator has started the changeover. Running — machine is producing good parts against this order. Interrupted — machine is stopped against an active order, with a classified stop reason. Completed — production has finished, quantities match (or variance is reconciled). Confirmed — data has been written back to ERP and acknowledged.

Every transition must be triggered by an event, not by a timer or a manual tick. State transitions driven by "the operator ticks a box when they remember" produce order timelines that are measurably wrong in every plant I have ever audited. State transitions driven by machine events (cycle start, good-count increment, alarm raise, alarm clear) produce timelines that match reality within seconds.

Push vs pull dispatch — the two integration patterns

How orders move from ERP to MES falls into one of two integration patterns, with genuinely different trade-offs. Getting this choice right matters because switching between them later is expensive.

Push dispatch. The ERP releases an order and immediately pushes it to the MES via an event-driven interface — IDoc, BOD, MQTT, webhook. The MES receives it, validates it, adds it to the dispatch queue, and makes it visible on the relevant machine's terminal. Latency from release to shop-floor availability: seconds to low minutes. Good for: high-volume discrete production, short-cycle-time plants, plants where schedule changes are frequent and need to propagate fast. Failure mode: if the ERP releases too fast or in bursts, the MES queue can saturate and operators see a stale list.

Pull dispatch. The MES queries the ERP on a schedule (typically every 1-15 minutes) and fetches the list of released-but-not-yet-imported orders. Simpler to implement, more forgiving of intermittent connectivity, easier to audit. Latency: the poll interval. Good for: plants with predictable release cadences, smaller plants where integration complexity needs to stay minimal, plants where the ERP has no reliable event-outbound capability. Failure mode: if the poll interval is too long, schedule changes do not reach the floor fast enough.

The honest rule: push dispatch is the right answer for modern SAP S/4HANA, Infor CloudSuite and proAlpha environments where event-driven interfaces are first-class. Pull dispatch is the right answer for older Navision, Dynamics NAV, or custom ERPs where the event layer is missing or unreliable. The Klocke engagement in our portfolio uses pull via file interface because the ERP is Navision and the pull pattern is the appropriate one for that architecture. The Meleghy engagement uses push via SAP ABAP IDoc because SAP supports it natively and the transaction volume justifies it. Both are correct for their context.

The data model trap — where most integrations actually fail

The surface-level integration work — setting up the IDoc, defining the file format, configuring the REST endpoint — is routine. It takes days, not weeks. The real complexity sits one layer below, in the data model, and this is where most integrations fail without anyone noticing until it is too late.

The fundamental problem: ERPs speak in production orders, operations, work centres and materials. Machines speak in cycles, pulses, states and alarms. There is no natural one-to-one mapping between the two. A production order of 10,000 parts becomes 10,000 cycles plus some number of setup cycles plus some number of test cycles plus some number of rejected cycles. The mapping logic — which cycles count against which order, how setup is attributed, how rejects are classified — is custom per plant and has to be designed explicitly. Integrations that skip this step typically end up with "good quantity in MES" numbers that differ from "goods receipt in ERP" numbers by 5-15 % every month, and nobody can reconstruct why.

The integration-design question I run at the start of every engagement: at the end of an order, will the finished quantity in the ERP match the good-count in the MES to the unit, every time, without human reconciliation? If the answer is no, the mapping logic is not complete and the integration is not ready for production. If the answer is "roughly, usually" — the integration will produce disputed numbers every month for the rest of its life. This is the single most underestimated design question in the whole project, and it is where the clean engagements separate from the messy ones.

Bidirectional integration — what actually flows back

The return flow from MES to ERP is where order processing either becomes genuinely useful or reduces to an expensive printer for paper travellers. A complete return flow, at minimum, carries: good quantity per operation, scrap quantity with reason code, setup time, production time, interruption time with classified reasons, operator assignments, and any quality-relevant events (inline reject, SPC excursion, alarm triggering a hold). Each of these becomes available to the ERP's costing, planning and reporting layers, and to every downstream analytical system.

The anti-pattern is the "quantity-only" return, where the MES writes back just the final good-count at order completion. This is common in older integrations and it defeats most of the business case. Without time, stop and reason data flowing back, the ERP cannot do accurate costing, the planning system cannot improve its capacity models, and the analytical layer cannot produce loss Paretos that have commercial context. The "quantity-only" return is the integration equivalent of filling out only the first line of a form — it is technically present but it carries almost none of the value.

A real case: Meleghy Automotive

Meleghy Automotive is a Tier-1 supplier for complex body components with plants in Germany, Spain, the Czech Republic and Hungary. The order-processing integration built for Meleghy is the cleanest example in the SYMESTIC portfolio of a bidirectional ERP-MES handshake done properly, and the architectural choices behind it are worth describing in detail because they scaled from one plant to six in six months without breaking.

The ERP on the Meleghy side is SAP R/3. The integration pattern is push dispatch via ABAP IDoc — when a production order is released in SAP, the IDoc fires into the SYMESTIC platform in seconds, the order appears in the dispatch queue for the relevant press or joining line, and the operator sees it on the shop-floor terminal without any manual import step. On the return path, the same IDoc channel carries back quantities, setup times, production times and interruption events with classified reasons, mapped at the operation level to the correct production order. Every machine cycle traces to an order; every stop traces to a reason. Nothing is estimated, nothing is reconstructed after the fact.

The parallel bidirectional link into CASQ-it from Böhme & Weihs is the detail that turns this from a good integration into a design-level one. The same machine-event stream that drives order confirmation also triggers quality sampling requests into CASQ-it at defined intervals and on defined event patterns. One data layer, two operational consequences — order execution in SAP, quality sampling in CASQ-it — synchronised at the event level. Building the same behaviour with two separate integration layers would have taken twice the effort and produced a system where the two sides drifted within months.

The modular catalogue then let Meleghy scale the same integration pattern across Gera, Brandýs, Bernsbach, Reinsdorf and Miskolc within the first six months — because the mapping logic was defined once, validated once, and reused. The measurable outcomes across the six-plant footprint:

• 10 % reduction in stop time, driven by honest capture of stop reasons now visible at the order level
• 7 % improvement in output, through better order sequencing once real execution data was feeding the planning decisions
• 5 % improvement in availability, through structured analysis enabled by clean order-level event data

The integration architecture was not the cause of those improvements — the operational actions were. But the integration architecture was the reason the actions could be identified with confidence and applied consistently across six plants without divergent local interpretations. That is the strategic value of order processing done right.

FAQ

What is the difference between order processing in ERP and in MES?
The ERP handles the commercial side — what was ordered, for whom, when it is due, what it costs. The MES handles the physical execution side — when the machine actually started, how long setup took, how many good parts came out, where time was lost. Both systems talk about the same order, but they answer different questions. A well-designed integration keeps the responsibility boundary strict: the ERP never tries to track machine events, the MES never tries to own the commercial definition of the order.

Should order dispatch be push or pull?
Push is the right default for modern ERPs (SAP S/4HANA, Infor CloudSuite, proAlpha) where event-driven interfaces are first-class — latency is seconds, schedule changes propagate in near-real-time. Pull is the right answer for older ERPs (Navision, Dynamics NAV, some custom systems) where the event layer is unreliable or missing — simpler to implement, more forgiving of intermittent connectivity, but limited by the poll interval. The choice is driven by what the ERP reliably supports, not by preference.

Why do MES quantity and ERP goods-receipt quantity sometimes disagree?
Almost always because the mapping logic between machine cycles and order operations was not designed explicitly. A production order of 10,000 parts becomes some number of setup cycles, some test cycles, some rejected cycles and some good cycles. Which of those count toward the ERP quantity is a design decision that has to be made upfront. If it is not, the two numbers drift, nobody can reconstruct why, and the divergence becomes folklore. The fix is always the same: define the mapping rules, document them, validate against reconciled test runs before go-live.

What must flow back from MES to ERP at minimum?
Good quantity per operation, scrap quantity with reason code, setup time, production time, interruption time with classified reasons, operator assignments, and quality-relevant events. Anything less defeats most of the business case. The "quantity-only" return flow is a common anti-pattern — technically present but carrying almost none of the value that justified the integration in the first place. Modern ERPs (SAP, Infor, proAlpha, Dynamics) all support the full return flow; using only the quantity field is a self-inflicted limitation.

How long does an ERP-MES order-processing integration take to build?
For a cloud-native MES against a modern ERP with event-driven interfaces, the surface-level integration is 1-3 weeks. The mapping logic design — which cycles count against which order, how setup and scrap are attributed, how operations split — takes another 2-4 weeks and is the part that actually matters. Against older ERPs with file-based or custom interfaces, add 2-4 weeks. Integrations that claim "two days" are skipping the mapping design, and those are the integrations that produce disputed numbers every month for years afterwards.

Do we need a middleware layer between ERP and MES?
For one plant and one ERP, no — direct native integration is cleaner and faster to debug. For multi-plant, multi-ERP environments, an integration platform (iPaaS, ESB, or the ERP's own integration layer like SAP PI/PO) can make sense because it centralises the mapping logic. The decision is driven by the number of systems that need to talk to each other, not by a default preference for one pattern. Adding middleware to a simple two-system integration is over-engineering; omitting it in a ten-system landscape is under-engineering.

What happens to order processing when the ERP is down?
A well-designed MES continues to dispatch, execute and record against the orders it has already imported. Operators on the floor see no interruption; the machines keep running; data is captured and queued. When the ERP comes back, the queued confirmations flow back in order. A poorly-designed MES either blocks the floor waiting for ERP acknowledgement, or loses the queue entirely. The test for any order-processing integration is: what happens when the ERP is unreachable for four hours? If the answer is "production stops," the architecture is fragile and will fail in the first real outage.

How does SYMESTIC support order processing?
Bidirectional ERP integration libraries for SAP R/3 and S/4HANA (ABAP IDoc, RFC, OData), Infor (BOD, REST), Microsoft Dynamics and Navision (OData, file), proAlpha (native interface). Event-driven push dispatch where the ERP supports it, scheduled pull where it does not. Explicit order state model with machine-event-driven transitions — no manual-tick-box approximations. Bidirectional confirmation including quantities, setup and production times, classified stop reasons, quality events. Parallel integration into quality systems (CASQ-it pattern) from the same event stream. Scale-tested across 15,000+ machines in 18 countries. See SYMESTIC Production Control.

Related: MES · MES vs. ERP · Production Scheduling · IoT Integration · Real-Time Monitoring · Traceability · ISA-95 · SYMESTIC Production Control

About the author

Mark Kobbert

CTO of SYMESTIC GmbH. Responsible for the cloud-MES architecture since 2014 — Microsoft Azure, microservice architecture, IoT gateway connectivity, real-time processing of 15,000+ machines across 18 countries. Led the ground-up rebuild from on-premise to cloud-native in the mid-2010s. B.Sc. Business Informatics, SRH Hochschule Heidelberg. · LinkedIn