ERP Integration for Manufacturing: Connecting SAP, Dynamics and Navision to the Shop Floor

Every manufacturer running both an ERP and shop-floor systems eventually confronts the same discrepancy. The ERP shows an order as complete; the floor knows two pallets were reworked. The ERP shows material consumed at standard quantity; the actual consumption included scrap nobody booked. Neither system is lying. They are describing different moments — the ERP describes the plan and its financial consequences, the shop floor describes physical reality — and integration is the discipline of keeping those two descriptions reconciled.

The first design decision is direction of ownership, and getting it wrong is the most common cause of integration projects that never stabilise. Master data — customers, suppliers, materials, bills of material, routings, prices — belongs to the ERP and flows downward. Execution data — actual start and finish times, actual quantities produced, scrap, downtime reasons, machine states, operator assignments, real material consumption — is generated on the floor and flows upward. When both systems are allowed to edit the same entity, you do not have an integration; you have a recurring argument with a synchronisation schedule.

Downward flow is usually the easier half. Production orders released in the ERP appear in the MES with their operations, routings and material lists. Item master changes propagate. Customer and delivery data reaches the systems that need it. The main practical difficulty is granularity: an ERP production order frequently corresponds to several shop-floor operations across different work centres, and the mapping between the ERP structure and the executable structure needs to be defined deliberately rather than assumed.

Upward flow is where the value is and where the difficulty concentrates. Confirmations — the messages saying this operation produced this quantity, consumed this material, took this long, scrapped this much — drive the ERP's inventory, costing and capacity figures. When these are captured automatically from machines and operator terminals rather than typed at end of shift from memory, the ERP's numbers stop being approximations. Costing improves immediately, because actual times replace standard times.

The integration patterns available differ mainly in latency and coupling. File-based exchange is simple, universally supported and unavoidably batch-oriented. Direct database access is fast and fragile, breaking on vendor upgrades in ways that are difficult to anticipate. REST and SOAP APIs — SAP via IDoc, BAPI or OData; Dynamics 365 and Business Central via their published APIs — are the modern default and version far more gracefully. Message queues add resilience for high-frequency events, because the floor keeps producing data whether or not the ERP is available.

That last point deserves emphasis because it is where fragile integrations reveal themselves. Production does not stop when the ERP does. If your integration is synchronous and the ERP is unavailable for scheduled maintenance, either the floor stops or the data is lost. A queued, buffered design lets the MES continue capturing and deliver the backlog when the connection returns — and in a factory running multiple shifts, this is not an edge case but a monthly reality.

Local and regional ERP systems complicate the picture in a specific way. Global suites have documented interfaces and large integration ecosystems. Regional products — Panteon, Logo, Nebim and their equivalents in other markets — are widespread among mid-sized manufacturers, often deeply customised, and rarely have an off-the-shelf MES connector. This is not a reason to replace a functioning ERP. It is a reason to treat the integration layer as a first-class part of the project rather than an assumed detail.

Reconciliation is the part that gets omitted from project plans and then consumes the first three months of operation. Messages fail. A confirmation rejects because a material was blocked. A production order is deleted in the ERP after the floor has already started it. Every integration needs a queue you can inspect, a retry mechanism, an error state that alerts a human, and a periodic reconciliation report proving that what the floor recorded and what the ERP holds still agree. Integrations without these do not fail loudly; they drift quietly, which is worse.

The scoping advice that survives contact with reality: start with one order type on one line, prove the full round trip from ERP release to shop-floor execution to confirmation back to ERP, and only then widen. Big-bang integrations across every plant and order type simultaneously fail in ways that are extremely difficult to diagnose, because when everything is new nothing can be used as a reference.