MES & Shop Floor Integration

The problem you are actually paying for

You run Dynamics 365 Supply Chain Management for planning, costing and inventory, and a dedicated execution system on the shop floor because that is where the machines, the operators and the real-time constraints live. Between the two sits a gap that someone fills manually every shift: a supervisor re-keys yesterday's output into production order feedback, a planner exports released orders to a spreadsheet for the line, material consumption is posted in a Friday batch that no longer resembles what was actually drawn, and scrap gets recorded twice or not at all.

The cost shows up in three places. Standard cost variances that nobody can explain because consumption was posted late. Available inventory that is wrong for hours at a time because a picking list journal has not posted. And a planning run that schedules against WIP quantities that were true yesterday morning.

F&O production control has the right objects — released production orders, routes, operations, BOMs, picking list and route card journals, RAF. What it does not have is a maintained, resilient link to the execution system you actually run. That link is what ECOSIRE builds.

What ECOSIRE builds

This is a build-to-order engagement. There is no shrink-wrapped connector to download — we scope both systems, agree the message contract, and build the integration against your plant.

Outbound: F&O to the shop floor

When a production order reaches the status you nominate — typically Released, sometimes Started — the integration publishes a work package to your execution system. That package is assembled from the real F&O objects: the released production order header, the route with its operations, resource requirements and setup and run times, the BOM lines with the site and warehouse they will be consumed from, batch or serial requirements where the item is tracked, and any attached work instructions or documents.

Delivery is through data entities exposed over OData or through a change-tracked outbound queue drained by a batch job, depending on whether your MES pulls or expects to be pushed to. We agree that in scoping rather than forcing your MES into our preferred shape. Changes matter as much as creations: a quantity change, a route revision, a rescheduled date or a cancelled order all raise an update message so the floor is never executing against a stale order.

Inbound: the shop floor back into F&O

This is where most integrations quietly fail, and where most of the build effort goes. Feedback from the floor is received into a staging table, validated, and then posted into F&O through the standard journals rather than by writing to production tables directly:

• Operation feedback — good quantity, error quantity, setup time and run time per operation, posted through the route card journal against the correct operation number and resource.
• Material consumption — actual quantities drawn per BOM line, posted through the picking list journal, respecting the warehouse, location, batch and serial dimensions the floor actually used rather than what the BOM assumed.
• Scrap and error quantity — recorded against the operation where it occurred with your scrap reason codes, so the variance lands in the right place in the cost calculation.
• Report as finished — end quantity posted with the correct inventory dimensions, optionally with automatic route and BOM consumption disabled so the explicit journals above remain the single source of truth.
• Status transitions — start, stop and completion driven from the floor rather than typed in by a supervisor.

Every inbound message carries an external reference and is processed idempotently, so a retry after a network drop cannot post the same consumption twice. Messages that fail validation land in an error queue with the F&O error text attached, visible to a supervisor in a workspace we build for the purpose, and reprocessable once the underlying data is fixed.

Machine and sensor data

Where you are collecting machine counters, downtime events or cycle data, we handle the aggregation deliberately. Raw high-frequency signals do not belong in F&O. We agree the aggregation window with you, and only the summarised quantities and time postings that the ledger and costing actually need cross the boundary. Everything below that stays in your historian or MES where it belongs.

Warehouse and mobile device alignment

If your plant uses advanced warehouse management, raw material staging and finished goods put-away are aligned with the warehouse mobile app rather than bypassed. Production input location, staging, and the license plate handling on report-as-finished are all part of the scope, so an MES-driven consumption does not leave work lines orphaned.

Operations and observability

The integration is not a black box. You get a monitoring workspace showing outbound queue depth, inbound backlog, error counts and last successful sync per line, plus batch job alerting so a stalled queue raises an alert rather than being discovered at month-end close.

Who this is for

Discrete and process manufacturers running F&O for finance and planning alongside a separate execution layer on the floor — whether that is a commercial MES, a SCADA-fed system, an OEE platform, or an in-house shop floor application. It matters most where you run multiple shifts, where standard costing accuracy is scrutinised, and where planning quality depends on WIP being current.

It is not the right fit if your floor already works directly in F&O production floor execution and you have no separate execution system to integrate.

How delivery works

1. Scoping call. We map both sides: your F&O production configuration (production groups, route and BOM strategy, journal names, costing method, warehouse setup) and your MES data model, API surface and event capabilities. We agree the message contract and the failure semantics before anyone writes code. 2. Fixed quote and specification. You receive an interface specification listing every message, its trigger, its payload and its posting behaviour, along with a fixed price. Anything outside it is quoted before it is built. 3. Build. Development against your version and configuration, delivered as an X++ extension model with no overlayering. Typical lead time is two to four weeks, extending where the MES side needs work or where multiple sites are in scope. 4. Install in test. Deployable package into your sandbox via LCS, connected to your MES test instance. We run a full shift simulation together — order release through consumption, feedback, scrap and RAF — and reconcile the resulting cost against what you expected. 5. Production. Promotion through your normal release process, typically starting on one line and widening once a shift has run clean. 6. Support. A defect support window with a named contact after go-live.

What we will tell you honestly

The hardest part of this work is not the code, it is agreeing what happens when the two systems disagree — when the floor consumes an item the BOM does not list, or reports more good quantity than the order allows. We will push you to decide those rules during scoping, because an integration that has not decided them will make the decision for you at 2am on a night shift.