Business systems
Integrations
between your online shop and ERP
Retyping orders, stock levels and prices from one system to another takes time every day and leads to mistakes, and once sales grow it is no longer enough. We connect your shop to your inventory system so that data passes between them on its own.
What a business gains from integration
Above all, integration reduces errors made when retyping data. Selling goods that are not in stock means a phone call to the customer and a refund, and that customer may not come back. With manual stock updates this happens easily, because hours pass between one update and the next.
The second benefit is coping with sales peaks. A business that manually handles a few dozen orders a day has to hire more people when the number grows much larger, or it starts falling behind. An integrated process handles more orders with the same amount of work.
The third benefit is having your data in one place. It becomes easier to answer questions that used to require manual compiling: which product group actually makes money, what handling returns costs, how quickly stock turns over.
What we connect
Below are the systems we come across most often. If yours is not listed, we will check whether it offers any way of exchanging data.
- Shops: WooCommerce, PrestaShop, Shoper, custom-built shops
- Sales systems: Subiekt GT and nexo, WAPRO, Insoft PC-Market
- Sales platforms: Allegro, Amazon, eBay, most often through BaseLinker
- Invoicing: Fakturownia, iFirma, modules within the ERP system itself
- Couriers: InPost, DPD, DHL, GLS, Poczta Polska, shipping brokers
- Payments: Przelewy24, PayU, Autopay, BLIK, deferred payments
Not every business needs all of these connections. We agree the scope of synchronisation individually, based on what is done manually today.
What goes where: designing the data exchange
Before we start connecting anything, we decide which system is the source of truth for each piece of information. The rest of the project depends on this decision, and it is easy to skip. If a price can be changed in two places, sooner or later the two versions will drift apart and it will be hard to tell which one is correct.
A typical setup looks like this: the inventory system is responsible for stock, prices and the product records, and the shop for descriptions, photos and orders. The order goes into the system, the sales document number and fulfilment status come back from it, and the tracking number goes back to the shop and to the customer.
We also agree what should happen in disputed cases: when goods disappeared from the warehouse between the order being placed and processed, when a customer ordered more than is in stock, or when one of the services stops responding. How these cases are handled decides whether the integration makes work easier or adds manual corrections.
| Data | Source of truth | Direction | Frequency |
|---|---|---|---|
| Stock levels | ERP system | ERP → shop | every few minutes |
| Prices and discounts | ERP system | ERP → shop | periodically, e.g. every hour |
| Descriptions and photos | Shop | shop → ERP or none | one-off |
| Orders | Shop | shop → ERP | immediately |
| Sales document | ERP system | ERP → shop | once issued |
| Tracking number | Courier system | courier → ERP → shop | once dispatched |
How the implementation works
We start by mapping the process as it actually runs day to day. Together with the person who handles orders, we go through one working day step by step. This brings out exceptions that are easy to forget but have to be handled: phone orders, customers on prepayment, goods brought in to order.
Then we create a data map and a schedule. We first run the integration in a test environment, on a copy of real data, and pass last week's real orders through it. We move to production only when the result matches what people did.
In the first week of operation we check every batch of data. It is extra work, but it catches edge cases before they make a mess in the warehouse and in the accounts.
We do not switch the integration on in place of manual work straight away. For the first few days it runs in parallel and we compare the results, before anyone stops entering data manually.
What happens when one side stops responding
Integration connects systems we do not fully control. A shop may be unavailable during an update, an ERP server may be switched off overnight, and a courier service has outages of its own. We design the connection on the assumption that such interruptions happen.
Data that could not be passed on goes into a queue and is retried, so an interruption does not mean a lost order. If the problem persists, we get a notification and respond.
We also keep an operations log. When someone asks why an order from three weeks ago has a strange status, the answer is in the log and nobody has to reconstruct events from memory.
- Integration without a retry queue, so data is lost at every interruption
- No operations log, so the history cannot be reconstructed
- Two-way synchronisation without an agreed source of truth
- Going straight to production, without tests on real data
- Dependence on one person who knows how it works
Multichannel sales: the shop, Allegro and the rest
When you sell in several places at once without integration, it is hard to keep stock levels correct. The same product listed in the shop and on an external platform needs a shared stock level, otherwise it can be sold twice.
The standard solution is a middle layer that collects orders from all channels, standardises them and passes them to the inventory system as a single stream. In the other direction, it sends current stock levels to all channels at once. Instead of several separate connections, you are left with two.
The middle layer also deals with the differing requirements of each platform: different data formats, rules on sales documents and shipping deadlines. Standardising them in one place is simpler than handling each channel separately.
What the cost of integration depends on
The cost depends mainly on the number of systems being connected and on whether a ready-made module exists or the connection has to be written from scratch. A module for a popular pair of systems only needs configuring, while an unusual connection has to be designed first.
| Scope | Example | What the cost depends on |
|---|---|---|
| Configuring a ready-made module | WooCommerce ↔ Subiekt, standard scope | amount of synchronised data and number of channels |
| Integration with customisation | Custom fields, B2B price lists, process exceptions | number of exceptions and rules to handle |
| Connection written from scratch | System without ready-made modules, unusual process | data exchange options on both sides |
| Integration maintenance | Monitoring, response, changes after updates | number of connections and frequency of updates |
Maintenance is not mandatory, but it is worth considering. Integrations most often break after one side is updated, and then what matters is whether someone notices quickly. We prepare a free quote for the implementation within 24 hours.
Recommended. A professional approach and high quality of service.
Working together
How we work together, step by step
Process mapping
We go through one working day with the person handling orders, exceptions included.
System analysis
Versions, available ways of exchanging data, limitations on both sides.
Data exchange design
What goes where, how often, and what should happen in disputed cases.
Implementation and testing
Running on a copy of real data and passing last week's orders through it.
Production launch
Running in parallel with the current process, comparing results, and only then switching over.
Monitoring and development
Error notifications, response after updates, changes when the process changes.
Questions
Frequently asked questions
We check this at the start. Older versions can be limited, but there is usually a way, sometimes through file exchange instead of a direct connection. If there is no sensible option, we tell you before quoting.
Every few minutes as standard, more often for critical products. Updating immediately after every change is sometimes possible, but with a large catalogue it can load both systems more than it is worth.
Yes, most often through a middle layer that collects orders from all channels. They then reach the inventory system as a single, standardised stream.
Data waits in a queue and is retried, and we get a notification. As part of maintenance we respond to such alerts and restore the data exchange.
They can be. Once an order is paid, the document is issued by the ERP system or by the invoicing service, depending on where you keep your sales records. It reaches the customer and your accountant without manual retyping.
Yes, if it has some way of exchanging data or one can be added. We describe how we build shops ready for integration on our page about online shops.
Related services
What else may be useful
Your city
ERP integrations in your city
For each of these cities we have a separate page describing the local market and how we work with companies there.
Let's connect your shop to your inventory system
Tell us which shop and which system you use, and what is done manually today. We will tell you whether a ready-made solution exists and prepare a free quote for the implementation.