PrestaShop Store Management
This is the installation and configuration guide for PrestaShop Store Management, the module you downloaded from your ECOSIRE dashboard. Everything on this page describes the prestashop_store_management module exactly as it ships today — the facts below were read out of the released build, not from a roadmap.
| Technical name | prestashop_store_management |
| Odoo versions | 17.0, 18.0, 19.0 (Community or Enterprise) |
| Current shipped version | 17.0 → 17.0.2.2.4, 18.0 → 18.0.2.2.4, 19.0 → 19.0.2.2.4 (read out of the builds on 27 September 2026) |
| Price | $499 USD — one-time, per Odoo version |
| Odoo module licence | OPL-1 |
| Category | Connector |
No key is entered anywhere and there is no unlock step, on any of the three
Odoo versions. You install the ZIP and the connector works. Your rights are
governed by the OPL-1 terms the ZIP ships under, and support and updates
still follow your purchase.
Older builds shipped a separate ECOSIRE licensing add-on and refused to install without it. That dependency and every execution-blocking check have been removed. If Odoo asks you for a key, you are on one of those older builds — download the current build from your dashboard.
New since 2.0.3
2.2.4
- Every dashboard label is readable, in light and dark mode. Each status label had been painted in a colour on that same colour's pale tint — green measured 2.04:1, orange 1.90:1, teal 1.78:1, cyan 2.33:1, red 3.10:1, purple 3.66:1 against the 4.5:1 floor — and in dark mode the active period pill and the primary and sync buttons drew white on a pale accent (3.65:1). Each tinted label now uses an ink colour chosen for that exact background (5.38 / 5.76 / 5.81 / 5.47 / 5.74 / 7.60:1) and text on a filled button is its own token (4.92:1 in dark mode). Fill colours are unchanged — a status dot is still its own hue — and this is the same measured palette the Lazada dashboard ships, so the two dashboards now agree.
- The dashboard's populated, empty, loading and error states are each covered by a browser test, together with the Customers list, so a later release cannot regress the dashboard silently.
- The same fix ships on 17.0 and 18.0; no connector behaviour changed in this release.
2.2.3
- Hardened against 36 known real-world connector failure cases, each covered by a named regression test executed on Odoo 17.0, 18.0 and 19.0. The customer-visible changes:
- An imported order records which connection it came from, and its amounts are converted rather than assumed. Two PrestaShop shops of the same company that reuse an order number no longer collide, and an order whose currency has no exchange rate in Odoo is refused instead of being posted at 1:1. The shop's own figures are kept next to the converted ones.
- Re-syncing an order refreshes its lines and totals, not only its status, so a price corrected in the PrestaShop back office reaches Odoo.
- Shipping, shipping-discount and cart-discount amounts are stored, zero included.
- Product variants follow the combination PrestaShop reports. Every combination of one product used to resolve to the same Odoo variant; an ambiguous multi-variant product now stops with an explanation instead of guessing.
- The whole catalogue syncs, not its first page. PrestaShop paginates with
limit=offset,countand the sync read page one only. - Categories, manufacturer and images are imported. Image files are read through the documented
/images/products/{id}resource, and one unreadable image no longer fails the product that carries it. - Test Connection reads a real authenticated resource (
/shops). The API root answers 200 for a key that can read nothing, so a "successful" test used to prove nothing. - Manual import from a spreadsheet. On the connection, download the CSV template, fill it in and import it. The template and the parser share one column set, so a file that imports cannot have depended on a hidden column.
- Customer contact details are masked on the connector's own screens. PrestaShop does not mask them; the module does, and the field help says so.
- The dashboard includes the end date, so "today" is today rather than everything up to yesterday.
- A failed or partial sync no longer reports success or moves the last-sync timestamp the dashboard reads. A partial run is a warning; a run where nothing succeeded is an error.
- Affiliate and creator capabilities are explicitly unsupported. PrestaShop's web service has no such resource, so the connector says so instead of implying it.
- The PrestaShop Orders screen opens the module's own list and search rather than the broad core sales screens.
- Operational fields appear on the core order, product and customer forms, including a GTIN preflight on every synced product and the newsletter/opt-in consent read from the customer record.
2.2.2
- The Validate Payment switch on an Auto Workflow now does what the form promises. It posts the draft invoices the Auto Invoice step creates — PrestaShop orders are prepaid on the storefront, so those invoices represent money already collected and leaving them in draft forced a manual pass over every imported order. Only invoices still in draft are posted; a hand-edited or already-posted invoice is never touched.
- Deleting a product image in PrestaShop now deletes it. PrestaShop identifies a product image by the product and the image; the connector sent the image number alone, which PrestaShop read as a product and removed nothing. The request now names both.
- Credit-slip lines are read from the credit slip itself. PrestaShop has no stand-alone credit-slip-line resource, so the old request was refused by every standard shop. The lines — order line, quantity, and amounts with and without tax — now come from the credit slip, where PrestaShop publishes them.
- Product reviews are out of scope. PrestaShop's web service has no reviews resource, so the two unused review requests were removed. The client now makes 124 of the 414 operations PrestaShop's core web service documents; the rest are documented but not used by the connector.
2.2.1
- The module's own Administrator role can now configure the connector. The API Key field was writable only by Odoo Settings administrators and it is mandatory, so an Administrator could neither see it nor create a connection. Users and Managers still never see the key.
2.2.0
- Settlements now actually build. The scheduled action Sync Settlements (gateway payouts) pointed at a method that did not exist, so switching it on did nothing. It now reads your orders' payment rows and records one settlement per gateway per day, one line per payment, under PrestaShop → Premium → Settlements.
- The daily digest now sends. Daily Digest Email also pointed at a method that did not exist. It emails a one-page summary of the previous day — orders imported, orders dated on the shop, and the settled amount per gateway.
- The API client grew to 128 operations, up from 78. Each path and method is read from the platform contract; none are inferred.
2.1.0
- The connector installs and runs standalone: no licensing add-on, no key, no unlock check.
Requirements
| Requirement | Detail |
|---|---|
| Odoo | 17.0, 18.0 or 19.0, Community or Enterprise. Self-hosted or Odoo.sh — Odoo Online (SaaS) cannot install third-party modules |
| Odoo apps | base, sale_management, stock, account, delivery, mail, web, product, contacts, knowledge — Odoo installs any that are missing |
| Python packages | requests |
| Platform account | A PrestaShop account with API access |
Install the Python packages into the same interpreter that runs Odoo:
sudo -u odoo pip install requests
Installation
1. Download the ZIP for your Odoo version
Sign in at ecosire.com and open your dashboard downloads, and pick the file matching the Odoo version you run. Each Odoo major version is a separate product with its own build.
2. Extract into your addons path
unzip prestashop_store_management_v19_*.zip -d /opt/odoo/addons/
ls /opt/odoo/addons/prestashop_store_management/__manifest__.py # sanity check
The module must end up as a single top-level prestashop_store_management/ directory with __manifest__.py directly inside it. If your ls check fails, the folder landed one level too deep or too shallow — move it so the path above resolves.
3. Restart Odoo and install
sudo systemctl restart odoo
- Go to Apps and click Update Apps List (developer mode must be on).
- Search for PrestaShop Store Management and click Install.
- Odoo pulls in the Odoo apps listed above automatically. There is no second module to install first.
When the install finishes, a PrestaShop menu appears in the main Odoo app switcher.
Configuration
Connect to PrestaShop
Create a connection record on the prestashop.configuration model. The fields the module defines for the connection are:
| Field | Technical name | Type | Required |
|---|---|---|---|
| Configuration Name | name | Char | Yes |
| PrestaShop URL | prestashop_url | Char | Yes |
| API Key | api_key | Char | Yes |
| Company | company_id | Many2one | Yes |
| PrestaShop Version | prestashop_version | Selection | Yes |
| Marketplace | marketplace | Char | No |
| PrestaShop Shop ID (default scope) | prestashop_shop_id | Char | No |
| Shops | shop_ids | One2many | No |
The fields marked Yes are enforced by the model — Odoo will not let you save the record without them. The technical name is the reliable identifier if your screen wording differs.
The same record carries 7 behaviour checkboxes — sync_products, sync_orders, sync_customers, sync_inventory, auto_sync_products, auto_sync_orders, auto_sync_customers. They gate what the module is allowed to do automatically once it is connected. Leave anything you are not ready for switched off, and turn them on one at a time.
To create the API key on the PrestaShop side, log in to the PrestaShop Back Office and open Advanced Parameters → Webservice: enable the webservice, add a new key, and grant it GET, PUT, POST and DELETE on the resources you want the connector to touch.
Public endpoint: the webhook receiver
The module registers one publicly reachable HTTP route. It is the only endpoint on this module that is served without an Odoo login, so it is worth knowing exactly what it does before you expose your instance.
| Endpoint | Method | Auth | Purpose |
|---|---|---|---|
/prestashop/webhook | POST | public (no Odoo session) | Receives inbound PrestaShop event deliveries |
This receiver currently rejects every delivery, on purpose. PrestaShop core ships no webhook push API — real-time events require a third-party PrestaShop module or polling — so an inbound payload arriving at /prestashop/webhook cannot be authenticated as genuinely coming from your shop. Rather than trust an unsigned payload, signature verification fails closed: the endpoint answers HTTP 403 with {"status": "rejected", "message": "signature verification failed"} and processes nothing from the request.
What that means for you in practice:
- You do not need to configure anything in PrestaShop for this route. Registering it as a delivery target on the shop side will produce nothing but 403s.
- Your data still syncs. Product, order, customer and inventory syncing on this connector is driven by the scheduled actions below, which poll the PrestaShop Web Service API on your behalf. Real-time push is not how this connector stays current.
- The route is safe to leave exposed. It reads the request body and headers, finds no verifying webhook record, logs the rejection with the caller's IP, and returns. Nothing is written and no record is created.
- The
prestashop.webhookrecords under the connector's menu (name, topic, delivery URL, secret, delivery/failure counters) exist so the receive path is ready the day a signed PrestaShop delivery scheme is available. They do not enable inbound push today.
The module's remaining routes — /prestashop/api/status, /prestashop/api/sync and /prestashop/dashboard/data — are internal JSON-RPC endpoints used by the module's own screens. They require a logged-in Odoo user and are not part of your external setup.
Settlements and the daily digest
Both live on the connection record's Settlements & Digest tab and both are off by default, because one writes financial records and the other sends mail.
| Setting | What it does |
|---|---|
| Sync Settlements | Reads your imported orders' payment rows and records one settlement per gateway per day, one line per payment, under PrestaShop → Premium → Settlements. Re-running is safe: a day already ingested is never duplicated, and a settlement you have posted is never re-opened. |
| Daily Digest Email | Emails a one-page summary of the previous day — orders imported, orders dated on the shop, and the settled amount per gateway — to the addresses you set. Each figure is labelled with the window it covers, and a day is never sent twice. |
PrestaShop publishes no payout endpoint, so a settlement is your gateway's takings per day as recorded on your orders. Use it for reconciling against your gateway statement, not as a bank statement. The two scheduled actions that drive them run on a timer, but neither does anything until the matching switch above is on.
Scheduled actions
The module installs 8 scheduled actions (Settings → Technical → Scheduled Actions):
| Scheduled action | Runs every | Enabled on install |
|---|---|---|
| prestashop: Sync Products | 1 hour | Yes |
| prestashop: Sync Orders | 30 minutes | Yes |
| prestashop: Sync Customers | 6 hours | Yes |
| prestashop: Sync Inventory | 15 minutes | Yes |
| prestashop: Test Connection | 1 day | Yes |
| prestashop: Cleanup Old Logs | 1 day | Yes |
| prestashop: Sync Settlements (gateway payouts) | 12 hours | Yes — idles until Sync Settlements is on |
| prestashop: Daily Digest Email | 1 day | Yes — idles until Daily Digest Email is on |
Intervals above are the shipped defaults. Adjust them to your volume — but be aware that the platform, not Odoo, sets the API rate limits, and shortening a sync interval is the usual cause of throttling errors in the logs.
Auto workflows
PrestaShop → Premium → Auto Workflows defines what the connector may do to an order after importing it. Each Auto Workflow record carries five switches, and a prestashop.workflow record attaches one to a connection:
| Switch | Effect on an imported order |
|---|---|
| Auto Confirm | Confirms orders still in Draft or Sent |
| Auto Invoice | Creates the invoice for a confirmed order that is still To Invoice |
| Validate Payment | Posts the draft invoices the Auto Invoice step created (only drafts — a posted or hand-edited invoice is never touched) |
| Auto Deliver | Reserves stock, sets the done quantities and validates the delivery |
| Create Invoice Policy | On Order Confirmation, or On Delivery |
Leave them all off until you have watched a few syncs — every one of them writes business records. A workflow step that fails on one order is logged against that order and does not stop the rest of the run.
Using the module
The module's menu is laid out as:
- PrestaShop → Dashboard
- PrestaShop → Orders
- PrestaShop → Products
- PrestaShop → Customers
- PrestaShop → Premium — Shops (Multi-Shop), Tracked Modules, Order Shadows, Product Shadows, Customers (GDPR), Collections, Locations, Carriers, Returns, Refunds, Risk Flags, Settlements, Analytics, Workflows, Auto Workflows, Daily Digest
- PrestaShop → Operations — Import Wizard, Export Wizard, Mapping Wizard, Test Connection, Logs, Reports
- PrestaShop → Configuration — Settings
A normal first run is:
- Save the connection record and confirm the module reports a successful connection before importing anything.
- Review the mapping records so imported data lands on the right Odoo records.
- Run a small import first — restrict it by date or by a handful of products — and check the results before letting the scheduled actions take over.
- Watch the log records during the first full sync. Failures are recorded there rather than raised at the user.
Troubleshooting
Syncing
| Symptom | Cause and fix |
|---|---|
| The connection will not validate | Re-check every required field in the table above. Most failures are a mistyped secret, or credentials created for a sandbox while the module points at production (or vice-versa). |
| Nothing syncs even though the connection is fine | The scheduled actions are disabled at the Odoo level, or Odoo's cron worker is not running. Check Settings → Technical → Scheduled Actions and that --max-cron-threads is greater than zero. |
| Sync starts then stops part-way | Read the module's log records for that run. Rate limiting and rejected field values are the two common causes; both are logged with the platform's own error text. |
| Records import but map to the wrong Odoo values | Fix the mapping records under the module's configuration, then re-run the import. |
| Duplicated products or customers | Run the initial import once. If a first attempt half-finished, check the existing records before re-running rather than importing on top. |
| Orders import but no invoice appears | Turn on Auto Invoice on the connection's Auto Workflow. With Validate Payment also on, the invoice is posted in the same pass. |
| Settlements stay empty | The switch is off on the connection's Settlements & Digest tab, or none of the imported orders carry payment rows yet. |
| The digest email never arrives | No address is set, or Daily Digest Email is off. The sending address is the one on the connection record. |
The requests library is required | requests is missing from Odoo's Python environment. Install it into the interpreter that runs Odoo. |
Version history
| Odoo version | Version you download today |
|---|---|
| 17.0 | 17.0.2.2.4 |
| 18.0 | 18.0.2.2.4 |
| 19.0 | 19.0.2.2.4 |
ECOSIRE module versions are <odoo major>.<module major>.<minor>.<patch>, so 19.0.2.2.4 is the Odoo 19 build of module version 2.2.4. Your installed version is shown in Apps.