PrestaShop and enova365 integration
A store connected with enova365 through the system's API: products, stock, price lists, sales documents and customers, including multi-branch setups.
Integrating PrestaShop with enova365 connects the store with the ERP for products, stock, price lists and trade documents. enova365 has a documented programming interface and supports extensions, so the exchange is cleaner here than with systems you have to work around.
What the synchronisation covers
- Product records with attributes, codes and VAT rates.
- Stock levels and reservations, with support for multiple warehouses and branches.
- Price lists, discounts and trade terms assigned to customers.
- Store orders saved as documents in the agreed flow.
- Customers and their billing details.
- Fulfilment statuses, document numbers and tracking numbers returned to the store.
How the connection works
enova365 provides web service interfaces and, for more complex requirements, the option of writing an add-on that runs inside the system. The choice between these routes depends on how much logic is to stay on the ERP side: simply copying stock levels can be handled by an external connector, while calculating trade terms on the system side requires an extension.
enova’s task scheduler lets you run recurring operations on the ERP side, which is often more convenient than polling the system from outside at short intervals.
B2B sales and multiple branches
enova365 is most often used by companies with complex trade terms that sell from several locations. These are two things to settle at the start: whether the store shows individual prices after login, and which warehouse fulfils the order. Both decisions change the scope of work more than the number of products in the catalogue.
Where these implementations usually go wrong
- Trade terms. Fully reproducing enova’s discount logic in PrestaShop is often not feasible – more often the store asks the ERP for the price for a specific customer and basket.
- Price query performance. Querying the ERP on every product list view brings down both the store and the system. A cache with a sensible lifetime is needed.
- Permissions. The integration’s technical account must have exactly as much access as it needs – not an administrator role “just in case”.
- Test environment. Without a copy of the ERP database for testing, every change to the integration gets tested in production.
What you get
- An exchange design: scope, directions, frequency and conflict resolution rules.
- A connector with a log, a queue and retries.
- Tests in an environment that mirrors production.
- Documentation and repository access.
Frequently asked questions
Can the store show individual prices after login?
Yes, and with enova it is the most common requirement. You just need to decide whether the price is calculated live by the ERP or the store works on a periodically refreshed copy of the trade terms. The first option is more accurate, the second faster.
We have add-ons written for us. Is that a problem?
No, but they need to be reviewed before quoting. Sometimes the logic the store has to reproduce lives in an add-on, and then it is cheaper to extend the add-on than to write that logic a second time outside.
Will the integration survive an enova update?
If it uses documented interfaces – usually yes. The risk grows where the previous contractor reached straight into the database. I check this at the outset when taking over an existing integration.
Describe how you calculate prices for customers – the shape of the whole implementation depends on that answer.