PrestaShop and Comarch ERP Optima integration
Exchanging products, stock, price lists and documents between the store and Comarch ERP Optima - through a supported API, with control over document numbering.
Integrating PrestaShop with Comarch ERP Optima moves product records, stock levels, price lists and customers to the store, and orders to the system as trade documents. Optima runs on an MS SQL database at the company’s premises or in the Comarch cloud, so the way it connects depends on the deployment variant and the modules purchased.
What the synchronisation covers
- Product and service records: names, codes, EAN, VAT rates, units, groups.
- Stock levels, taking reservations and the split between warehouses into account.
- Price lists, discounts and individual customer prices – essential in B2B sales.
- Store orders as customer orders, sales invoices or receipts, according to the agreed document flow.
- Customers with tax ID verification and invoicing details.
- Fulfilment statuses, document numbers and waybills returned to the store.
How the connection works
Comarch offers several routes, and the choice between them depends on your licence: the dedicated Comarch ERP API, integration through Comarch e-Sklep, or an exchange handled by an intermediate layer. In on-premise deployments the connector runs inside the company network and exposes to the store only what is needed, instead of opening the Optima database to the world.
What I avoid: writing documents straight into the MS SQL tables. Numbering, settlements, and inventory and accounting links are created in the program’s logic. A document inserted around it looks correct until the first period close.
In B2B sales, the price lists are the whole project
In many companies working on Optima the store has to show individual prices: different for each customer, depending on quantity thresholds and group discounts. PrestaShop has its own model of specific prices and customer groups, but it does not reproduce Optima’s logic one to one. We settle this part before implementation, because it determines the effort of the whole project.
Where these implementations usually go wrong
- Attributes and variants. Mapping Optima attributes to PrestaShop combinations requires decisions, not automation.
- Documents at the wrong moment. An invoice issued when the order is placed rather than when it ships throws the inventory off every time a customer cancels.
- Online payments. You need to decide what happens to the document when an order is unpaid and after a return.
- Performance. With tens of thousands of records a full run is unsustainable – what matters is sending only the changes.
- Returns and corrections. The most often overlooked stage, and the one that generates the most calls to accounting.
What you get
- An agreed document flow: what is created in the store, what in Optima and at what moment.
- A connector with a queue, retries and a log of every operation.
- A notification when synchronisation stops – instead of silence until a complaint arrives.
- Documentation that allows another contractor to take over maintenance.
Frequently asked questions
Do I have to buy Comarch e-Sklep?
No. e-Sklep is a separate Comarch product with a ready-made integration. If the store runs on PrestaShop and is to stay on PrestaShop, the integration is built outside that product.
Our Optima is in the Comarch cloud. Does that change anything?
It changes how the data is accessed, and that needs to be checked at the start, because not every cloud variant offers the same as an on-premise installation. The division of roles between the store and the system stays the same.
How long does such an implementation take?
It depends mainly on the number of exceptions in the price lists and the state of the product records. I set the scope after talking to the person who works in Optima every day – they know why the batch number ends up in the notes field.
Write and tell me how your document flow works – I will reply with what can be synchronised and what is better left on one side.