Setting up a webshop is easy. Building a shop that knows what is actually on the shelf is a different job entirely. When e-commerce projects fall over, it is almost never the design. It is the connection between the shop and the merchandise management system.
The pattern repeats with tiring regularity. The shop goes live, the first weeks look fine, and then the odd cases pile up. An order for an item that sold out days ago. A customer who saw one price in the basket and another on the invoice. A parcel the warehouse cannot pack because a field is missing. Each incident is small. Together they cost more than the shop build did.
Stock breaks first
Overselling does not happen because someone was careless. It happens because time passes between the sale and the stock movement. Sync stock once a night and your shop spends the whole day selling against yesterday evening's figure. With five orders a day nobody notices. On the first day of real demand everybody notices, and it hits precisely the products that are selling well.
It gets worse, because your goods are rarely in one place. Shop floor, warehouse, allocated to open picks, returns awaiting inspection. The ERP knows those distinctions. In many projects the shop receives a single number, and nobody ever decided which number that should be.
Two systems, two truths about the same product
In the ERP the item is called "Screw M6x40 galv. PU100". In the shop it is "Hex bolt M6, 40 mm, galvanised, pack of 100". Both are correct. Nothing links the two records except the item number, and somebody corrected that by hand in the shop six months ago.
Variants are where it really hurts. A shop needs size and colour as selectable axes. Plenty of merchandise systems instead hold separate item numbers with no relationship between them. If that relationship is not modelled properly, the shop recreates it and maintains it twice from then on. The next time the range changes, one side drifts away from the other.
Prices and discounts belong in one place
A price looks like a simple field. It never is. Tiered pricing, customer groups, promotional windows, minimum quantities, volume rebates. If that logic lives in the ERP and gets rebuilt in the shop, you now run two calculation engines that are supposed to agree. They will not. Not eventually, but on the first edge case.
The robust option is the less comfortable one. The shop does not calculate, it asks. That costs development time and it needs an interface fast enough to answer while the customer waits. In exchange, the basket matches the invoice, and that is where customer trust lives.
One leading source per kind of data
The most important decision in the project costs nothing to build. Decide which system tells the truth for which kind of data. Item master and stock from the merchandise system. Descriptions, images and search data from the shop. Orders are created in the shop and travel one way into the ERP. Customer records: pick a side, but pick one.
What never works is "both systems maintain everything". It comes up in workshops because it sounds flexible. What it means is that there is no truth, and every conflict gets sorted out by hand later.
The same decision determines whether an order arrives complete. Fulfilment needs fields the shop has no interest in: delivery terms, packaging instructions, cost centre, a separate delivery address with access notes. If the checkout never captured them, no interface can invent them.
Nightly imports versus event driven sync
The three a.m. CSV import is cheap, quick to build and unremarkable during acceptance testing. It only pushes the cost into the future. A batch run has no sense of sequence, only of a final state. When it fails, nobody finds out until morning. And it scales badly, because it touches everything even when three items changed.
Event driven synchronisation inverts that. Stock changes, the system announces the change, the shop picks it up within seconds. It is the more demanding route to build. It is also the only one that survives your first sell out. Combining both works well: events for stock and prices, a nightly full reconciliation as a safety net for messages that got lost. In our shop projects we design that interface before anyone touches a template.
Frequently asked questions
Is the standard connector from our shop system enough?
For a simple catalogue with a handful of products, often yes. As soon as variants, customer group pricing or multiple warehouses come into play, it runs out of road. Before you buy, check whether the module really covers your pricing logic and not just the list price.
How often does stock need to sync?
It depends on how fast you turn over. For fast moving items with thin stock, minutes matter. For goods you hold in the hundreds, every few hours is fine.
What about a shop that is already live?
Do not tear it down. Define the leading source per data type first, then move stock onto events, because that is where the damage happens. The rest can follow.
If your shop and your ERP are currently arguing with each other, we are happy to look at it with you and say plainly what we would fix first, no obligation and no sales pressure.
This article is part of our knowledge hub Web development and e-commerce.