Manufacturing orders are created in the ERP, but it is in the production management software or the MES that the shop floor reports, schedules and inspects them. Sooner or later the question comes up: how do you connect production software to an ERP with no re-keying, no duplicates, and without everyone wondering on Monday morning why yesterday's orders never arrived?
In practice there are four ways to make two production management applications talk to each other: flat files dropped into a folder, an exchange over SFTP or EDI, web APIs, or direct access to the database. This article compares them, gives a method for choosing, then details what makes the difference in the field: what you log, what you replay, and the recurring pitfalls.
Before connecting production software to an ERP: which system owns what?
An MRP–ERP interface starts with a list, not a technology. For each piece of data, write down who creates it, who changes it and which way it flows. The usual split is:
- From the ERP to the production software: items, bills of materials, routings, work centres, manufacturing orders with their quantities and dates.
- From the production software to the ERP: actual times per operation and per operator, good and scrapped quantities, material consumption, order closure, quality inspection results.
The ERP remains the owner of master data and manufacturing orders; the production software never recreates them, it enriches them. Then comes frequency: in a workshop that plans today for tomorrow, a nightly exchange is enough for master data, and a delay of a few minutes is acceptable for time reporting.
The four ways to connect two applications
1. Flat files in a shared folder
The oldest and most widespread method: the ERP exports a CSV or XML file to a network directory, the production software reads it at regular intervals, and vice versa. It works with any software that can export, including a twenty-year-old ERP or an Excel workbook. Its weaknesses are well known: a delay tied to the scheduled task, no built-in alert on failure, a deleted or truncated file that goes unnoticed, and a dependency on the network and on folder permissions.
2. File exchange over SFTP, and EDI
Same principle, but the files travel through a secure SFTP server hosted by one of the two parties. The sending application extracts its data, generates a file and drops it into an agreed directory; the receiving application polls the server, downloads, imports, then archives or deletes the file.EDI adds standardisation of the content (message formats agreed between the parties), widely used with large retailers and carriers. This is the route taken to connect a bespoke production management system to the Diapason ERP, for lack of an API: 11 files one way, 5 the other, strict naming and agreed directories.
3. Web APIs
APIs allow immediate communication: the sending application pushes its data through a secure HTTP request, or the receiving application fetches it when it needs it. Updates are taken into account in real time, an anomaly triggers an explicit error response, and authentication relies on standards (OAuth2, JWT tokens). The condition: the ERP must expose an API that is documented and stable from one version to the next. Odoo, for example, exposes its whole data model; many older specialist ERPs have no API, or a read-only one.
4. Direct database access
Reading the ERP's tables over an SQL or ODBC connection, through views created for the purpose. It is quick to set up and performs well on large volumes. For writing, avoid it: you bypass the ERP's business rules, lose the checks and the history, and an upgrade can break everything without warning. We keep it for reading, towards a planning or analysis tool.
Comparison table
| Integration method | Latency | Built-in traceability | Requirements on the ERP side | When to choose it |
|---|---|---|---|---|
| Flat files | Minutes to hours (scheduled task) | Low, has to be built | An export and an import | Old ERP, low volumes, tight budget |
| SFTP / EDI | Minutes to hours | Medium (server log) | An export, an import, an SFTP server | Two separate companies or teams, standardised flows |
| Web API | Real time | Good (error responses, logs) | A documented, stable API | Need for responsiveness, recent ERP, several tools to connect |
| Database | Real time, read only | None | SQL access, views | Read only, towards a planning or reporting tool |
How to choose
- Start from the ERP, not the production software. The ERP sets the possibilities. If it has neither an API nor SQL access, the discussion is over: it will be files.
- Measure the real need for responsiveness. An order created at 10:00 and visible on the shop floor at 10:15 is generally not a problem.
- Identify who will maintain the interface in three years' time: in-house IT, the ERP vendor, the production software vendor? An API is easier to evolve than a file format negotiated between two service providers.
- Insist on monitoring, whatever the method. In every case you need a screen showing what went through and what failed.
What to log and be able to replay
An interface without monitoring becomes a mysterious object that only a developer can diagnose. Whatever method is chosen, we ask for a screen in the production software that lets you:
- see, for each exchange, the time, the file or message and its status (received, imported, in error);
- view the content received, to check that the ERP actually sent what it should have;
- read an error in business language (“item 12345 unknown”, “order already closed”), not a technical stack trace;
- replay an exchange, in test and then in production, after a fix, without creating a duplicate;
- receive an e-mail alert when an expected flow has not arrived, not only when it has failed.
Replaying without duplicates requires every message to carry a stable identifier (order number, item code, original timestamp) and the import to be idempotent: processing the same file twice gives the same result as processing it once.
The pitfalls we see in the field
- Duplicate processing. A scheduled task running on several instances of the same application processes the same file several times, and ends up trying to delete a file that has already been deleted. You need a single worker per flow, or a lock.
- Two sets of master data that do not match. An item code with a leading zero on one side and not the other, a unit in metres here and in pieces there, a work centre renamed in the ERP but not in the production software. The mapping table must be visible and editable by the business users.
- The missing file. A failure gets noticed; an absence does not. If the ERP sent nothing overnight, nobody is warned, and the shop floor works on yesterday's orders.
- The server you do not control. Connection problems with an SFTP server managed by a third party take a long time to diagnose: plan for logs on both sides and a named contact.
- Encoding and formats. Badly converted accented characters, decimal separators, dates in US format: mundane errors, costly if they are not caught on the way in.
Connecting production software to an ERP is not primarily a technical choice between files and APIs: it is a question of master data, responsibilities and monitoring. The exchange method follows from what the ERP allows; the quality of the interface is judged by what a production manager can see and fix alone.
That is how we designed the connectors of Planitrack and Planiprod : a ready-to-use Odoo connector that reads manufacturing orders, routings and items and sends back times and quantities; reading of Excel or CSV files for every other ERP; and an exchange log that business users can consult. See the page Odoo integration for manufacturing or request a demo.