Integrating with your ERP without replacing it
You connect a portal, website or other system to your ERP through file exchange, an API or middleware. Files are the simplest and suit fixed moments, an API suits data that has to be right straight away, and middleware pays off when several systems talk to each other. Your ERP stays in charge of the finances. The integration keeps products, customers, orders and documents in line.
An ERP does a lot well: bookkeeping, invoicing, stock administration. It is less suited to letting customers order for themselves, presenting a range attractively or planning a load. Replacing it is rarely necessary and often risky, because everything attached to it has to move too. Integrating is the other route: the ERP stays the source for what it does well, and a layer around it does the rest.
What moves back and forth
It usually comes down to four kinds of data: products, customers with their price agreements, orders and documents. Sometimes stock or availability is added. For each kind you need to settle which system is the source and which way the data flows. A common split is that the ERP is the source for customers, price agreements, invoices and financial data, that products are kept in a catalogue or PIM, and that orders originate in the portal and then go to the ERP.
Three approaches
| Approach | How it works | When it suits | Maintenance |
|---|---|---|---|
| File exchange | The ERP exports or reads files, such as CSV or XML, at fixed moments, often through a secure file server. | Product lists, price lists and orders that do not have to be right straight away, a nightly sync, or an ERP with little or no API. | Simple to understand and to test. Watch the file format and error handling whenever fields change. Changes arrive only on the next run. |
| API | Systems ask each other directly for data or pass it on, per order or per change. | Data that has to be right straight away, such as an order status or the current price when ordering, and an ERP that offers an API. | Depends on availability, versions and credentials. A change to the API has to be tested on both sides. |
| Middleware | An intermediate layer receives, translates and distributes messages between several systems. | More than two systems, different formats, or when you want to be able to replace a system later without reconnecting everything. | An extra component to host and monitor. You do get one place where you see errors and adjust rules. |
The approaches do not exclude each other. A common mix is a nightly file sync for products and prices, and an API call at the moment an order is placed.
What decides the choice
- How fast does a change have to arrive: within a second, within an hour or the next morning?
- What can your ERP offer: an API, a file export, or only a manual export?
- What happens when the integration goes down, and who notices?
- How many systems will be added in the coming years?
- Who manages the integration after go-live?
What an integration has to be able to do
- Report and recover from errors: a failed order must not disappear silently.
- Cope with duplicate messages: if the same order arrives twice, that must not produce two orders.
- Check data before it enters the ERP, such as a missing item number or an unknown customer.
- Keep a log, so you can trace what was sent and when.
- Have an owner who responds when something goes wrong.
Change the ERP itself as little as possible
The less you change in the ERP itself, the less work you have at an update. Keep custom work in the layer around it and let the ERP do what it was bought for. That way you can upgrade or replace the ERP later without having to redo everything built around it.
Connect and test on real data
An integration that works on sample data does not yet work on your data. Real data has empty fields, old item numbers and customers with two addresses. So test on a copy of your real data before the integration goes live. That is also part of our approach: ERP, supplier lists and email are connected and tested on real data.
What people ask first.
- Do I have to replace my ERP to use a portal?
- No. The ERP stays in charge of the finances. The portal is connected to it and adds what the ERP does less well, such as ordering by customers, status and document access.
- What is the difference between an API and file exchange?
- With an API, systems ask each other directly for data, per order or per change. With file exchange, a file is created and read in at fixed moments. An API is more direct, files are simpler.
- When do you need middleware?
- When more than two systems talk to each other, when formats differ, or when you want to be able to replace a system later without rebuilding every connection. For a single integration it is often more than you need.
- What happens when the integration goes down?
- That should be worked out beforehand. A good integration reports the error, keeps what did not arrive and can try again, so nothing disappears silently.
Show us where your orders get stuck.
Tell us how an order moves through your business today. We will tell you honestly what is worth building.