ERP integration

An ERP integration is tested twice: when it is built, and when the ERP is upgraded or replaced. The second time shows how much of the vendor’s data model was allowed to leak into your own systems.

If reports, the online shop and your own customer register read field names and codes straight from the ERP, a system change does not mean rewriting one integration. It means rewriting every application that did that.

Five questions to answer before you start

1. Which system owns customer, item, order and stock? The answer can differ per field, but there has to be one.
2. What happens when the ERP is down for four hours? Are orders queued, or lost?
3. Can the writes cope with the same order being sent twice?
4. How do you find out a flow has stopped delivering, without a customer calling?
5. Can a day of traffic be replayed after the fact?

We write the answers into the integration plan: an owner per piece of data, what happens during an outage, how retries are handled and what is monitored. A missing answer is a decision still to be made, not a gap to fill during the first incident.

Which ERP systems do you work with?

Those with an API to connect to. Fortnox, Visma, Business Central and SAP all have one, but APIs, permissions and support for events differ between them, so we look at that before we promise anything. The way we build is the same: a translation layer between their model and yours, so field names and codes stay on one side. It means more mapping and more tests at the start. When you change ERP, we check which parts of the contract the new one can meet. Where it cannot, the flow or the systems using it have to change too, but then it is a known list, not a hunt through every system.

If other systems need to read from the ERP through the same contract, that is API integration.