ERP Integration for Production Planning: Who Owns Which Data?

Sales asks a simple question: how much of order 4711 is left to make? The ERP says 320. The planner's schedule says 308. The shop floor says "done". Three systems, three answers, and each is correct by its own rules. That is the problem ERP integration has to solve.

ERP integration for production planning means connecting your ERP (SAP, Oracle, Microsoft Dynamics 365 or another) with the tool that plans and schedules production, so that orders, stock and confirmations mean the same thing in both. The hard part is rarely the technical link. It's agreeing which system owns which data, and what each number means.

Three answers, one order

Order 4711 is for 500 good units. So far the machine has processed 192: 180 good and 12 scrap.

• The ERP subtracts good units: 500 − 180 = 320 left.
• The planning tool subtracted everything that went through the machine: 500 − 192 = 308 left.
• The shop floor got a job order for this week's run of 192. That run is finished, so for them it's done.

Nobody made a typo. They use different definitions of "left". Integration starts by agreeing on those definitions, before a single field is mapped.

One partial confirmation, traced through both systems

A production order for 100 brackets has three operations: 10 cutting, 20 welding, 30 painting. The welder confirms 60 good pieces at operation 20 and goes home.

• In the planning tool, operation 20 has 40 pieces remaining, moved to tomorrow. Painting may start on the 60, if your transfer rules allow partial batches. The job order shows as partially complete, still linked to the customer order.
• In the ERP, the order gets a partial confirmation of 60 at operation 20. No finished goods are received yet; that happens only after painting.

Now two things that go wrong in real life.

The message is sent twice. A network hiccup, a retry, and the ERP shows 120 of 100 welded. Every confirmation needs a unique ID so the receiving system can spot a duplicate and ignore it.

The count is corrected. Next morning, inspection finds 5 of the 60 welds bad. The confirmation becomes 55 good and 5 scrap, so 45 are still needed, not 40. Someone must decide whether 5 extra pieces get cut or the customer takes 95. That's a decision for a person, not for the interface.

Requested vs calculated vs promised date

Most orders carry three dates, and they must not overwrite each other:

• Requested: what the customer asked for, March 10. It changes only if the customer changes it.
• Calculated: what the planning tool says is possible, March 14. It can change with every schedule run.
• Promised: what sales confirmed after seeing the calculated date, March 15. It changes only when someone decides to re-promise.

The classic mistake is to write the calculated date straight into the promised date. Then every schedule run silently changes what the customer was told. Better: if the calculated date moves past the promised one, alert sales. Don't overwrite. How the promise gets checked in the first place is covered in sales orders to production.

Who owns which data in an ERP integration

The rule: each field has exactly one owner, the only system allowed to change it. The other reads it. A typical split:

Your split may differ. What matters is that it's written down.

Think of two cooks salting the same soup. Each tastes it, finds it bland, adds salt. Both acted sensibly. The soup is ruined. Data with two owners goes the same way.

The myth: "Good integration syncs everything, both ways, in real time"

Sending every field both ways guarantees that two systems overwrite each other. Good integration is selective: what the other side needs, when it needs it, one direction per field. Confirmations may flow every few minutes, item data once a day.

SAP, Oracle, Dynamics: same questions

None of this depends on the brand. With SAP, Oracle or Microsoft Dynamics 365 you still need to agree what "left" means, which date is which, and who owns each field. The field mapping differs by system and configuration, so settle ownership first. Why a separate planning layer is needed at all is explained in why ERP thinks every order takes 10 days.

How factory.online helps

factory.online integrates with SAP and Microsoft Dynamics 365. If you run Oracle or another ERP, ask what a connection would involve for your setup. Inside factory.online, the planner sees each manufacturing order with its job orders and good and scrap confirmations per operation, so the 60 welded brackets and the remaining 40 are visible, linked to the customer order. Produced batches keep their history for batch traceability.

If your ERP, your planner and your shop floor give three different answers, book a demo and we'll trace one of those orders together.