Connecting an eshop to an ERP: which system has the last word?

Most connections between an eshop and an ERP don’t break because the code is bad. They break because nobody decided at the start which system has the last word.

An example: someone in the office changes a price in the ERP. The same day, someone else changes the same price on the eshop, for a promotion. The connection runs at night and finds two different prices. Which one does it keep? If the answer isn’t written down, the connection picks one on its own, and someone finds out when a customer pays the wrong price.

The fix isn’t technical. It’s one rule for each kind of data, written down before the code.

In a typical business the table looks like this. Yours may differ in a few rows, and that’s fine, as long as it’s written down.

Data	Has the last word	How often
Products, codes, barcodes	The ERP	On every change
Retail, wholesale and per-customer prices	The ERP	On every change
Stock per warehouse	The ERP	Every few minutes
Descriptions and photos	The eshop or the ERP, as you agree	On every change
Orders	The eshop	Within seconds
Customers and VAT numbers	The ERP	With every new customer or change
Invoices and their MARK (the Greek tax authority’s number)	The ERP	As soon as the MARK is back

The rule also says something practical: you change a piece of data only in the system that has the last word. If prices are decided in the ERP, any change made on the eshop will be overwritten at the next sync. The whole team needs to know this.

Prices live in the ERP, because that’s where the invoice is issued. If the price on the eshop doesn’t match the price on the invoice, someone will have to explain the difference to the customer. Tiered discounts and per-customer prices stay in the ERP too, and the eshop shows them as they are.

The same goes for stock: the warehouse knows what’s on the shelf, not the eshop. If you also sell on marketplaces, they take their stock from the same place, so that no marketplace shows “in stock” for something that ran out yesterday.

“How often” matters here. Prices change rarely and can go across on every change. Stock changes all the time, and depending on your volume it’s updated every few minutes.

The order starts on the eshop, so that’s where it has the last word. It goes across to the ERP within seconds, with the customer, the lines and the payment method.

The most common mistake here is the same order going in twice. It happens when the connection drops at the moment of sending and tries again without checking whether the first attempt went through. The fix is simple: the eshop’s order number is written into the ERP, and before every new attempt the connection checks whether it’s already there.

Customers are the hardest kind of data, because they change on both sides. The customer changes their address on the eshop. The accounts team corrects their company name in the ERP.

The usual rule is this: new customers go from the eshop to the ERP, with their VAT number checked against the register of AADE, the Greek tax authority, when they are businesses. From then on, tax details are decided in the ERP, and the delivery address on the eshop. The connection map spells it out field by field.

Even with good rules, at some point the two systems will disagree. For each kind of data you write down three things: which one we keep, what happens to the other, and who is alerted.

For example: if the price changed in both, we keep the ERP’s, and the pricing manager gets an email. If stock on the eshop goes negative, we keep the ERP’s, and the product is closed for orders until it’s fixed.

Every connection will drop at some point: an upgrade, a slow server, a network that cuts out. The question isn’t whether, but what happens then.

A good connection loses nothing. The order waits its turn, is resent as soon as the connection is back, and goes in once. Anything that still fails after a few attempts is seen by a person, and everyone knows in advance who that person is. See it step by step on one order, with the switch “What if the connection drops?”.

Before a connection is built, ask for a connection map that answers six questions:

1. For each kind of data, which system has the last word, and how often the other one is updated.
2. What happens when they disagree: which one we keep and who is alerted.
3. How something that failed is resent without going in twice.
4. Who sees the errors, where, and how quickly.
5. Where the history of every transfer (the logs) is kept, and for how long.
6. Who owns the code, the passwords and the logs. The answer should be “you”.

With this map, whoever looks after the connection later knows exactly how it works. That’s how we work on eshop–ERP integration too, and the map is handed over with the connection.