Best Buy Store Management
This is the installation and configuration guide for Best Buy Store Management, the module you downloaded from your ECOSIRE dashboard. Everything on this page describes the bestbuy_store_management module exactly as it ships today — the facts below were read out of the released build, not from a roadmap.
| Technical name | bestbuy_store_management |
| Odoo versions | 17.0, 18.0, 19.0, 20.0 (Community or Enterprise) |
| Current version | 17.0 → 17.0.3.1.4, 18.0 → 18.0.3.1.4, 19.0 → 19.0.3.1.4, 20.0 → 20.0.3.1.4 |
| Price | $499 USD — one-time, per Odoo version |
| Odoo module licence | OPL-1 |
| Category | Sales/Sales |
Open Apps → Best Buy Store Management and read the version shown on the card.
3.1.4— current build on Odoo 17, 18, 19 and 20. It makes the order automation described below actually reachable: the three switches appear on the instance form, the Automation Rules and Workflows screens exist under Configuration, and the automation runs on each imported order that Best Buy has accepted and debited (once per order; never on an order waiting acceptance or debit, refused or cancelled), keyed on a financial status now derived from the Best Buy order state. Nothing changes for a store that has not switched anything on. It also stops the customer import and export reporting a run that did nothing as Done, and removes a$from the high-value order risk rule on this Canada connector. It includes 3.1.3 (buyer details kept out of stored error messages) and 3.1.2 (the store's Default Warehouse applied to imported orders), and everything in 3.1.1.3.1.1— imports payouts from Best Buy, can pull Best Buy stock into a mapped Odoo warehouse, sends live events to your own endpoints, and fixes Create Bank Statement and the order actions that report Best Buy's answer. It also carries the dashboard, log-visibility, buyer-matching and secret-validation fixes listed under 3.0.1 below. (3.1.0 was never published; 3.1.1 replaces it.)- Odoo 19
3.0.0— previous Odoo 19 build: Import & Export Jobs, reference data and the order-document work, without the 3.1.0 features. Upgrade to 3.1.4. - Odoo 17/18
2.2.7and Odoo 192.2.6— earlier builds with the 2.2.6 order-import, CAD-currency, tax, shipment, return and honest-failure corrections; a bulk file Best Buy rejects looks exactly like one it accepts. Upgrade to 3.1.4. - Odoo 17/18/19
2.2.5or earlier — upgrade before importing or re-importing orders. Those builds do not contain the complete currency, tax and current shipping-contract remediation.
Each Odoo major version is a separate build: 17.0.3.1.4, 18.0.3.1.4, 19.0.3.1.4 and
20.0.3.1.4 are the Odoo 17, 18, 19 and 20 builds of module version 3.1.4. Buy and install the build that matches the Odoo you actually run.
Requirements
| Requirement | Detail |
|---|---|
| Odoo | 17.0, 18.0, 19.0 or 20.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, portal, product, contacts, digest — Odoo installs any that are missing |
| ECOSIRE dependency | None. The connector installs and runs standalone |
| Python packages | requests |
| Platform account | A Best Buy Canada Marketplace seller account with API access (an API key issued in your seller portal) |
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
Download the build for your Odoo major version from wherever you purchased it — your ecosire.com dashboard, or the Odoo App Store. Each Odoo major version is a separate package, so take the one matching the Odoo you run.
If you bought on the Odoo App Store some time ago, check the version you have against Version history before installing; the archive you downloaded at purchase time may pre-date the current build. Download the current build again from the Odoo Apps Store (or your ecosire.com dashboard), where your purchase gives you access to every release.
2. Extract into your addons path
unzip bestbuy_store_management_v18_*.zip -d /opt/odoo/addons/
ls /opt/odoo/addons/bestbuy_store_management/__manifest__.py # sanity check
The module must end up as a single top-level bestbuy_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 Best Buy Store Management and click Install.
- Odoo pulls in the Odoo apps listed above automatically.
When the install finishes, a Bestbuy menu appears in the main Odoo app switcher.
Software terms
The connector is distributed under the OPL-1 terms included in the package. The Odoo package is
self-contained and does not call an ECOSIRE service as part of its runtime.
Deployment
Installing and configuring this connector is a self-service process — this page is the complete guide, and no ECOSIRE access to your systems is required at any point. If you would like us to carry out the deployment for you we are happy to, but it is an optional convenience, never a condition of using the module. Keeping your credentials and infrastructure in-house is a perfectly normal choice and changes nothing about the support you receive.
Configuration
Connect to Best Buy
Best Buy's Marketplace runs on the Mirakl Operator platform (the same connector family as Takealot
and Carrefour). There is no OAuth step — you paste a static seller API key that Best Buy issues
in your seller portal, and every request sends it as a raw Authorization header. Create a
connection record on the bestbuy.instance model. The fields the module defines for the connection
are:
| Field | Technical name | Type | Required |
|---|---|---|---|
| Instance Name | name | Char | Yes |
| Seller Portal URL | shop_url | Char | No — optional label |
| API Base URL | api_base_url | Char | No — defaults to the verified Canada operator URL |
| Shop ID | shop_id | Char | No — multi-shop accounts only |
| Marketplace | country_code | Selection (US / Canada) | No — defaults to Canada |
| API Key | api_key | Char (password) | Effectively required — the connector cannot authenticate without it |
| API Secret | shared_secret | Char (password) | No — only if your seller account was issued a companion secret |
| Alternate API Key | access_token | Char (password) | No — fallback used only when API Key is empty, kept for stores configured before the field was renamed |
| Company | company_id | Many2one | Yes |
Canada uses the verified
https://marketplace.bestbuy.ca/apidefault. If Best Buy or another Mirakl operator issued a different tenant URL for your seller account, enter that exact URL in API Base URL. The connector does not guess a public host for other tenants.
Seller Portal URL is now an optional, purely informational label — the connector never calls it. If you manage more than one Best Buy shop under one seller account, set Shop ID to tell the connector which one this instance is; leave it blank for a single-shop account.
The same record carries 3 order-workflow checkboxes — auto_confirm_order, auto_create_invoice,
auto_validate_invoice — on its Order Workflow tab, under Auto Processing, plus a Stock
Field setting (see Publishing offers and stock below). Leave
anything you are not ready for switched off, and turn features on one at a time. See
Order automation below for what each one does and how they interact with the
per-status rules.
Order automation
Best Buy orders import as quotations. Two things can move them on automatically, and both are off until you turn them on. Either one acts only on an order Best Buy has accepted and debited — Best Buy order state Shipping, Shipped, To Collect, Received or Closed — and once per order. An order still waiting acceptance or debit (Best Buy may yet refuse it), or one Best Buy refused or cancelled, is never confirmed or invoiced; an order accepted later is processed on the first import that sees it accepted. The order form shows the Best Buy order state and whether the automation has run.
- The instance switches (Configuration → Instances → Order Workflow → Auto Processing):
auto_confirm_orderconfirms each imported order,auto_create_invoicecreates its invoice, andauto_validate_invoiceposts that invoice. - Automation Rules (Configuration → Automation Rules): one rule per financial status per instance, each able to confirm the order, create the invoice, post it, register the payment and create the delivery.
Best Buy reports no payment status of its own, so the connector derives the financial status from the Best Buy order state: waiting acceptance or debit → Pending, accepted and debited (Shipping onwards) → Paid, refused or cancelled → Voided (a cancelled order stays Voided on later imports). Since the automation acts only on accepted orders, a rule keyed on Paid is the one that fires; Authorized, Partially Paid and the refund statuses are never derived, so a rule keyed on them does not match an imported order.
A rule whose financial status matches the imported order takes precedence over the instance switches; with no matching rule, the instance switches apply. Both screens ship with everything off, so a store that has configured nothing keeps importing its orders as quotations.
Workflows (Configuration → Workflows) is the multi-step engine for the same schedule: a workflow matches one marketplace status and runs its own steps, conditions and actions in order, with notifications and per-workflow statistics. Use Automation Rules for the common case; reach for Workflows when a status needs more than confirm-invoice-validate-pay-deliver.
The instance switches and Automation Rules are applied by the order import itself (Bestbuy: Sync Orders, every 15 minutes, or Import Orders). Workflows are processed by Bestbuy: Process Workflows, which runs every 10 minutes. Both screens are visible to the Manager and Administrator groups.
The Canada default contacts marketplace.bestbuy.ca. A seller-issued value in API Base URL
replaces that default for the instance. Your firewall must allow outbound HTTPS to the selected
operator host.
Order currency and tax handling (version 2.2.6 or later)
An imported order must carry Mirakl's currency_iso_code. The connector selects or activates the
matching Odoo currency and uses a company-safe pricelist in that currency. It preserves the exact
numeric order, line and shipping amounts sent by Best Buy; it does not relabel CAD amounts as
USD and does not perform an exchange-rate conversion during import.
Re-import is an idempotent repair path. With Skip Existing Records off, it updates the existing mapped sale order and can repair its currency/pricelist, buyer, date, lines and shipping without adding duplicate lines. The 2.2.6 migration can also backfill the stored currency label on older orders; it deliberately never changes their numeric amounts.
Tax is source-driven:
- When
taxesorshipping_taxesis absent or empty, the connector clears Odoo product-default taxes for that imported line. It never guesses GST or PST from the delivery address. - When Best Buy sends line or shipping tax entries, configure the provider code under the connection's Order Tax Mappings section. The mapping must point to a compatible Odoo sales tax; when the payload includes a rate or calculation rule, the mapping must match it.
- An unknown or incompatible tax code fails that order visibly. A non-empty top-level
order_taxestotal also fails visibly because Mirakl does not say how to allocate that total safely across Odoo lines.
Public endpoints this module exposes
None. Best Buy Marketplace (Mirakl) has no webhook or push capability for sellers, so this connector does not run an inbound HTTP receiver of any kind — synchronization is entirely schedule- and action-driven from the Odoo side (see Scheduled actions and Using the module below). If you previously registered a callback or install URL for an earlier version of this connector, you can remove it — nothing in the current build listens on it.
Event notifiers (outbound, from 3.1.0)
From 3.1.0 the connector can send events out to an HTTPS endpoint you own — it still receives nothing. Under Bestbuy → Configuration → Event Notifiers (Best Buy Developer group) create one notifier per event: pick the instance, the event and your Delivery URL, and optionally a Secret Key (system administrators; from 3.1.1 it must be at least 16 characters with no spaces — choose your own and give the same value to your receiver). Use Send Test Event to check your receiver.
| Event | Sent when |
|---|---|
| Order Created / Order Updated | an order is imported for the first time / a re-import finds its status, total or currency changed (an unchanged re-import sends nothing) |
| Order Fulfilled, Fulfillment Created | shipment and tracking are pushed to Best Buy |
| Order Cancelled | the order is cancelled on Best Buy from Odoo |
| Product / Offer Created, Updated, Deleted | an offer is published, updated or deleted from Odoo |
| Inventory Updated | Odoo stock is pushed to an offer, or a stock pull changes Odoo on-hand |
| Refund Created | a refund is pushed to Best Buy, or a new return is imported |
| Incident Updated | an order-line incident is resolved from Odoo |
Incident Created is never sent: Best Buy publishes no incident feed to sellers.
Each event is a JSON POST with event_id, topic, occurred_at, instance, test and data.
The headers carry X-Bestbuy-Topic, X-Bestbuy-Event-Id and, when a secret key is set,
X-Bestbuy-Hmac-Sha256 — the hex HMAC-SHA256 of the raw request body, so verify it against the
bytes you received. Deliveries are queued and leave Odoo once the change that raised them is saved;
the Process Queue Jobs action sends them, and a delivery that does not get a 2xx answer is
retried up to the notifier's Retry Count. Include Fields / Exclude Fields trim data;
Custom Headers (a JSON object) are added to every request.
Official API contract coverage
The contract was refreshed on 2026-08-28 from Mirakl's current official Seller API OpenAPI source. It contains all 125 of 125 official operations in that source, including the 11 operations Mirakl marks deprecated. From version 3.0.0 the connector's API client addresses all 111 of the operations that are callable — every documented operation that Mirakl has not withdrawn; the Odoo screens use the subset described on this page (3.1.0 on every Odoo version; the older 2.2.7 Odoo 17/18 build used 23 reconciled operations). It calls no undocumented operation and no deprecated one.
Three of the 125 rows are one operation written three times: Mirakl's own specification names the
/dynamic-url/ path parameter with a sentence rather than an identifier, so the catalogue renders
it once per export flow. The connector fetches the file from the URL the export publishes instead
of calling a route the specification does not state.
This is complete official-catalog and connector-call coverage, not a claim that the module implements every feature in the Mirakl platform. Authenticated availability still depends on the permissions and capabilities enabled for your own Best Buy seller key.
Scheduled actions
The module installs 13 scheduled actions (14 from 3.1.0) (Settings → Technical → Scheduled Actions):
| Scheduled action | Runs every | Enabled on install |
|---|---|---|
| Bestbuy: Sync Products | 30 minutes | Yes |
| Bestbuy: Sync Orders | 15 minutes | Yes |
| Bestbuy: Sync Customers | 60 minutes | Yes |
| Bestbuy: Sync Inventory | 10 minutes | Yes |
| Bestbuy: Process Queue Jobs | 5 minutes | Yes |
| Bestbuy: Auto Risk Detection | 30 minutes | Yes |
| Bestbuy: Generate Analytics | 4 hours | Yes |
| Bestbuy: Cleanup Old Logs | 24 hours | Yes |
| Bestbuy: Process Workflows — drives Workflows | 10 minutes | Yes |
| Bestbuy: Daily Summary Report | 1 day | Yes |
| Best Buy: Poll Import & Export Jobs | 10 minutes | Yes |
| Best Buy: Refresh Platform Reference Data | 1 day | Yes |
| Best Buy: Import Returns | 6 hours | No — enable it yourself |
| Best Buy: Import Payouts (accounting documents) — from 3.1.0 | 6 hours | Yes (acts only on instances with a Payout Journal) |
If your list instead shows Bestbuy: Import Payout Reports and Bestbuy: Import Refunds, and
has no Best Buy: Import Returns, you are on a 2.0.x build — those two actions called
endpoints that do not exist on Best Buy's platform and were withdrawn. Upgrade, and Odoo removes
them for you.
Best Buy: Import Returns ships disabled on purpose: it only has data to pull once Best Buy has enabled the returns feed for your seller API key. Once your key is approved for returns, turn it on under Settings → Technical → Scheduled Actions.
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.
Using the module
The module's menu is laid out as:
- Bestbuy → Dashboard
- Bestbuy → Orders
- Bestbuy → Refunds
- Bestbuy → Products
- Bestbuy → Customers
- Bestbuy → Payouts
- Bestbuy → Analytics
- Bestbuy → Operations — Run Operations, Queue Jobs, Logs
- Bestbuy → Configuration — Instances, Locations, Payment Gateways, Scheduled Actions, Compliance (and, from 3.1.0, Event Notifiers)
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.
Order actions
Open a record under Bestbuy → Orders to work it manually:
- Accept on Best Buy — confirms the order back to the marketplace.
- Push Tracking — sends Mirakl's flat tracking fields through OR23, using the mapped carrier code when available and the carrier name otherwise, then marks the order shipped through OR24. You do not have to click this yourself for a normal delivery: validating the linked Odoo delivery (Inventory → Transfers, the Validate button) runs the same two-step flow.
- Cancel on Best Buy — cancels through current OR29 without an invented request body.
Returns and refunds
- Import Returns — enable the Best Buy: Import Returns scheduled action (see Scheduled actions) once your seller key has the returns feed, or run it on demand from Bestbuy → Operations → Run Operations (operation Import Returns). Imported returns land under Bestbuy → Refunds.
- Accept Return / Receive Return — process an imported return through its lifecycle from the return record's buttons.
- Push Refund — sends the refund back to Best Buy once you have created the matching credit note in Odoo. A Create Credit Note button on the same record generates it for you first if you have not already.
Publishing offers and stock
- Offer stock publish — from Bestbuy → Products, publishing an offer sends the quantity
from whichever Odoo field is set as Stock Field on the connection record (Configuration →
Instances). Leave Stock Field empty and the connector uses
qty_available; set it tofree_qtyorvirtual_availableif that better matches how you want Best Buy stock levels calculated. - Delete Offer — removing an offer from Best Buy is a deliberate, confirmed action from the product record, not a side effect of archiving the product in Odoo.
- Inventory pull — reads the quantity Best Buy currently holds for each mapped offer and stores it on the offer mapping (Bestbuy → Operations → Run Operations, operation Import Stock Levels, or the Sync Inventory scheduled action, every 10 minutes). Only locations with an Import Stock Warehouse are read. Up to 3.0.0 Odoo's own on-hand stock is never changed. From 3.1.0 a location also has an Apply Best Buy Stock to Odoo switch (Bestbuy → Configuration → Locations, shown once an Import Stock Warehouse is set; off by default). Only when you tick it is the same quantity applied to Odoo on-hand in that warehouse's stock location, as a regular inventory adjustment (a traceable stock move), for storable products that are not tracked by lot or serial number and only when the warehouse belongs to the instance's company. Ticking it means Best Buy's figure overwrites Odoo on-hand every 10 minutes, including stock changes Best Buy does not know about (receipts, other sales channels), so tick it only where Best Buy is the stock you trust. Locations you set up on an earlier version keep the read-only pull after upgrading: the switch starts off, and upgrading never begins adjusting your stock.
Payouts
- Up to 3.0.0 you record each payout by hand; payouts are not imported.
- From 3.1.0 set a Payout Journal on the instance and payouts are imported every 6 hours (or now, with Import Payouts on the instance): one payout per Best Buy billing cycle, read from Best Buy's accounting documents (Mirakl IV01, automatic invoices), with the transaction lines behind it (TL02). The transfer line itself is left out, so the lines add up to the amount Best Buy paid. Refresh from Best Buy re-reads one payout until its statement exists.
- Create Bank Statement books the payout on its journal, one statement line per transaction line. Sale lines are matched to posted invoices where they can be reconciled automatically; the rest you reconcile from the bank statement in Accounting. (Up to 3.0.0 this button failed with an error.)
Reading what Best Buy did with your offers and prices
Every bulk operation on Best Buy is asynchronous. You send a file, Best Buy queues it, processes it on their side, and only then reports the result — including, when a file is rejected, the line-by-line reason.
Best Buy → Operations → Import & Export Jobs lists every bulk operation the connector has sent you, with Best Buy's own job id, its status, and the counts it reported. Open a job and use:
| Button | What it does |
|---|---|
| Poll Status | Re-reads the job from Best Buy |
| Fetch Error Report | Reads Best Buy's rejection report into the Error Report tab — this is where you find out which line of your offer file was wrong, and why |
| Download Result File | For an export, fetches the finished file and attaches it to the job |
| Retry | Reopens a failed job so the next poll picks it up |
If Best Buy accepts a submission but returns no job identity, the job is saved as Status Unknown with an explanation, and it is deliberately not polled — reading a job without an identity would report a different operation's result.
Platform reference data
Currencies, locales, shipping zones and types, offer condition codes, reason codes and value lists differ between sellers on the same Best Buy operator, so the module reads yours from the API rather than assuming them. Press Refresh Platform Reference Data on the instance and read the result under Configuration → Platform Reference Data. The same screen shows the platform configuration, shipping configuration and API version your account reports.
Manual sync wizard (Run Operations)
Bestbuy → Operations → Run Operations opens the Operations Center wizard. Pick your Instance and an Operation:
| Operation | What it does |
|---|---|
| Import Products | Pulls your Best Buy offers and maps them to Odoo products |
| Import Orders | Pulls orders in the selected date range |
| Import Customers | Nothing to import: Best Buy has no customer API, so buyers are created and matched during Import Orders. The run is recorded as Skipped — not Done — with the reason, so the Jobs list does not report an empty import as a completed one |
| Import Stock Levels | Reads Best Buy's quantity for each mapped offer onto the offer mapping; from 3.1.0 also sets Odoo on-hand in the location's Import Stock Warehouse when the location's Apply Best Buy Stock to Odoo switch is ticked |
| Import Payment Gateways | Seeds the Best Buy Marketplace payment gateway record |
| Import Returns | Pulls the returns feed so returns can be accepted and received |
| Export Products | Publishes your mapped offers to Best Buy |
| Export Stock Levels | Publishes Odoo stock (your Stock Field) as the quantity on your Best Buy offers, for locations with export warehouses set |
| Update Order Status / Export Fulfillment | Pushes fulfillment/tracking info to Best Buy |
Three options travel with whichever operation you pick:
- Skip Existing Records — do not touch a record that is already mapped in Odoo (available on every import).
- Specific IDs — a comma-separated list of Best Buy IDs (e.g.
123456,789012) to import only those records instead of the full window. - From Date / To Date — applies to Import Orders only; it defaults to the last 24 hours.
Every operation on the list calls a real implementation; Import Customers is the one that has nothing to fetch, because Best Buy delivers buyers inside orders.
List calls cap Mirakl's max parameter at 100, including when a larger value is requested. When a
provider call fails, the affected record and queue job remain failed with the provider error; the
wizard and dashboard do not convert that failure into a success notification.
Troubleshooting
Installation
| Symptom / error code | Cause and fix |
|---|---|
| Odoo reports a missing third-party dependency | You are installing an older package. Replace it with the current build for your Odoo major; current packages have no ECOSIRE runtime dependency. |
The requests library is required | requests is missing from Odoo's Python environment. Install it into the interpreter that runs Odoo. |
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). |
| Cannot connect / host not found | You are pointed at a generic Best Buy address. Best Buy issues each seller a tenant-specific API host — copy the exact API Base URL shown in your seller portal into the connection record; do not guess it from the Marketplace (US/CA) selection. |
| Offer updates appear accepted but nothing changes | You are on a build older than 2.1.0. Earlier versions called an offer-update endpoint that does not exist on Mirakl, so the call silently failed to change anything on Best Buy's side. Upgrade to 2.1.0 or later, where offer publish/update/delete use the real Mirakl operation. |
| 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. |
| A tax-code or tax-rate error stops an order | Add or correct the code under the connection's Order Tax Mappings, then re-import with Skip Existing Records off. Do not replace the missing source tax with an address-based guess. |
An order reports unsupported top-level order_taxes | The provider sent a total without a safe line allocation. Keep the order failed and contact support with a sanitized payload; do not manually force the amount onto an arbitrary line. |
| CAD amounts appear under a USD pricelist | Upgrade to 2.2.7 (Odoo 17/18) / 2.2.6 (Odoo 19) or later — 3.1.4 is current — then re-import the order with Skip Existing Records off. The repair changes the currency/pricelist label without converting numeric amounts. |
Version history
| Odoo version | Version you download today |
|---|---|
| 17.0 | 17.0.3.1.4 |
| 18.0 | 18.0.3.1.4 |
| 19.0 | 19.0.3.1.4 |
| 20.0 | 20.0.3.1.4 |
ECOSIRE module versions are <odoo major>.<module major>.<minor>.<patch>, so 19.0.2.2.6 is the Odoo 19 build of module version 2.2.6. Your installed version is shown on the module's card under Apps.
3.1.4 (17.0.3.1.4, 18.0.3.1.4, 19.0.3.1.4, 20.0.3.1.4) — the order automation, wired
Everything in 3.1.3 and 3.1.2 (the store's Default Warehouse on imported orders; buyer details kept out of stored error messages) and 3.1.1 below, plus:
- The order automation works. The three per-instance switches were on no screen and read by no code; the rule records keyed on financial status had no screen and their only call site was switched off. The switches now appear on the instance form, a matching financial-status rule takes precedence over them, and the automation runs once on each imported order Best Buy has accepted and debited — never on one waiting acceptance or debit, refused or cancelled. The financial status is now derived from the Best Buy order state (Pending / Paid / Voided), so a Paid rule matches. Every setting on both screens defaults to off, so an upgrading store keeps importing its orders as quotations. Upgrade note: between 2026-05-04 and 2026-08-09 the three switches were visible on the instance form with no effect. If your store ticked any of them then, they take effect with this release; check Order Workflow → Auto Processing on each store before upgrading.
- New Configuration screens: Automation Rules and Workflows. The per-status rules and the multi-step workflow engine both had models, access rights and a 10-minute schedule, but no view and no menu. Both are now open to managers and administrators.
- Jobs no longer report a no-op as Done. Import Customers has no buyer list to fetch and Export Customers has no write API to call; both closed their job as Done. They are recorded as Skipped, with the reason, and the log carries a warning — also when the run was queued.
- The high-value order risk rule no longer prints a
$. This is the Canada connector and imported orders carry CAD; the rule now reads "Orders over 1,000 in the order currency".
3.1.1 (17.0.3.1.1, 18.0.3.1.1, 19.0.3.1.1, 20.0.3.1.1) — 3.1.0 plus the September fixes
Everything in 3.1.0 below, plus the 3.0.1 fixes that were finished before 3.1.0 but left out of it:
- Dashboard: the Order Status chart draws; the dashboard follows Odoo's dark mode; notices and errors sit at the top; figures show a dash until data has loaded; a long store name wraps on a phone; text meets WCAG 2.2 AA contrast. A chart with nothing to plot says so ("No orders in this period", "Loading orders…", "Order data unavailable") instead of showing a legend over an empty area, and Top Products and Recent Activity say "Loading…" or "unavailable" rather than "no data" before a load has finished. A last sync older than a week shows its date.
- No invented figures before you connect a store. Without a connected instance the dashboard shows zeros, empty charts and a "No Best Buy store is connected yet" notice. Earlier builds filled it with sample revenue, orders and products under a "Demo" banner.
- Sync logs written outside a queue job are visible again on the Logs screen (they were hidden from every user by the multi-company rule), and a log message stays on one line in the list.
- One buyer, one contact across the order and customer imports; buyer names and e-mails are no longer written to the server log.
- Secrets are checked when you save them (carrier API secret, notifier signing key).
- An imported product image is stored correctly on Odoo 20 (it was lost with an error).
3.1.0 (17.0.3.1.0, 18.0.3.1.0, 19.0.3.1.0, 20.0.3.1.0) — payouts, stock pull, event notifiers
Never published; 3.1.1 replaces it.
- Payouts imported from Best Buy — one payout per billing cycle from the accounting documents (IV01) with their transaction lines (TL02), every 6 hours or on demand.
- Stock pulled into Odoo — for locations where you tick the new Apply Best Buy Stock to Odoo switch (off by default), Odoo on-hand in the Import Stock Warehouse follows Best Buy's offer quantity, as inventory adjustments. Existing locations keep the read-only pull.
- Live event notifiers — order, fulfilment, offer, inventory, refund and incident events sent to your HTTPS endpoints, signed and retried (see Event notifiers).
- Fixed: Create Bank Statement failed on every payout; the order evaluation, document feed, message thread, incident, additional-fields and shipping-from actions, and the returnable-lines and return-labels actions, reported an error after Best Buy had accepted the call.
3.0.1 — never published on its own; included in 3.1.1
- A carrier API secret or webhook signing secret is validated when you save it. Both are opaque tokens, and the settings form used to store whatever it was handed — so a paste that had been cut short, or that picked up a line break from the clipboard, was accepted without complaint and surfaced much later as an authentication failure with nothing to point at the value. Each is now checked on save: it must be a single token containing no spaces or line breaks, and at least 16 characters. The error names what was wrong, so the problem is fixed at the field rather than at token-exchange time. No exact length is imposed, because your operator defines it.
- The order importer and the customer importer now resolve a buyer through one shared contact
resolver. Each previously ran its own match ladder, and the two ladders disagreed: the order
importer matched an e-mail address case-insensitively and a phone number on its last ten digits,
while the customer importer matched both exactly. A buyer whose address was recorded as
Buyer@Example.comon one import andbuyer@example.comon the other — or whose phone number was written+1 555 123 4567in one place and5551234567in the other — was therefore filed twice. Both importers now run the same ladder (the store's own customer id first, then e-mail, then phone, then name), so a later import enriches the contact the earlier one created instead of creating a second one.
3.0.0 (2026-09-17) — Import & Export Jobs, platform reference data, order documents
- Import & Export Jobs (Operations → Import & Export Jobs). Best Buy processes every bulk operation asynchronously; the module now records each one it submits, with Best Buy's job id, its status, the counts it reports, and its error report. Previously the module sent an offer file and never read the result, so a file Best Buy rejected was indistinguishable from one it accepted.
- Platform Reference Data (Configuration → Platform Reference Data): your account's currencies, locales, shipping zones and types, offer states, reason codes, value lists and more, read from the API and refreshed daily.
- Order documents, incidents and messages: read the buyer's evaluation, list and download Best Buy's order documents, open a message thread, resolve an incident on an order line, set additional fields and declare the shipping-from warehouse.
- Returns completed: mark a return compliant, non-compliant or closed, cancel it on Best Buy, and read the still-returnable order lines and the return labels Best Buy publishes.
- Fixed: the sync log and queue job no longer redeclare Odoo's automatic
Created on/Last Updatedfields, which had silently dropped the database index behind them. The Best Buy location form no longer shows Address, City, Province, Country and ZIP boxes that no Best Buy seller operation can fill; Primary Location is now a real setting, limited to one per instance. - Contract coverage: the connector now addresses all 111 callable operations in Mirakl's published seller API (was 23).
- Odoo 17 and 18 builds prepared. The 17.0 and 18.0 builds of 3.0.0 carried every feature above and the full 277-test suite (2.2.7 ran 220 of the 277). They were not released on their own; Odoo 17 and 18 buyers move from 2.2.7 to 3.1.1, which includes all of it.
2.2.7 (2026-08-28) — Odoo 17/18 description correction
- Corrects the App Store description to identify the supported marketplace as Best Buy Canada. The previous package text contained a stale heading claiming two marketplaces even though its verified API host, configuration and runtime were Canada-only.
- Corrects the Odoo 17 description's requirement, related-module links and release labels. The earlier generated backport incorrectly retained Odoo 19 metadata.
2.2.6 (2026-08-28) — Odoo 19 release; Odoo 17/18 runtime remediation
- Requires the order's exact ISO currency, creates or selects a company-safe matching pricelist, and repairs older mapped orders without foreign-exchange conversion or duplicate lines.
- Clears product-default taxes when Best Buy supplies no tax arrays; applies explicit line and shipping taxes only through validated code/rate mappings; rejects unsafe top-level tax totals.
- Uses current Mirakl shipment, cancellation and return envelopes: OR23 then OR24, OR29 without a body, and wrapped RT21 actions. Single-order reads use OR11 filtering instead of deprecated OR12.
- Caps list pagination at 100 and keeps failed records/jobs visibly failed.
- Reconciles the 23 runtime operations to a complete 125-operation current official catalog.
2.2.5 (2026-08-26) — Mirakl order import repair
- Replaced Shopify-shaped order parsing with Mirakl's
order_id,commercial_id,created_dateandorder_linesfields. - Restored real buyers, per-unit pricing, order dates, shipping lines and Mirakl line identifiers.
- Removed discounts, tips and import-duty lines that depended on fields Mirakl does not send.
2.2.4 (2026-08-24) — listing and visual-assets release
- Publishes the current verified listing and visual assets across Odoo 17, 18 and 19.
- Runtime and API behaviour remain the verified 2.2.3 behaviour.
2.2.3 (2026-08-23) — Canada and standalone remediation
- Corrects the Canada operator default to
https://marketplace.bestbuy.ca/apiwhile retaining seller-issued tenant URLs. - Removes the obsolete inbound-push configuration surface and inactive health schedule.
- Completes company-isolation, workflow access-control and standalone-package remediation.
2.2.0 (2026-08-19) — standalone build
- Removed the former ECOSIRE runtime dependency so the connector installs and runs on its own.
- Use of the module remains governed by the
OPL-1terms included in the package.
2.1.0 (2026-08-18) — API-correctness release
This release was reconciled call-by-call against Best Buy's official Mirakl Marketplace Seller API documentation. If you are on an earlier version, upgrade — several actions that appeared to succeed previously did not actually reach Best Buy.
- Connection rebuilt around how Best Buy actually authenticates. The former OAuth-style "Connect to Best Buy" flow could never authenticate against Best Buy Marketplace and has been removed. You now paste a static seller API key directly (see Connect to Best Buy); Seller Portal URL became an optional label; new Shop ID and Marketplace (US/CA) settings were added; API Base URL is user-editable.
- No more inbound webhook endpoints. The connector no longer exposes any public URL — Best Buy Marketplace has no webhook/push mechanism for sellers, so sync is fully schedule- and action-driven.
- Offer, refund and returns calls now use real Mirakl operations. Offer publish/update/delete, refund push, and returns import previously called endpoints that do not exist on Best Buy's platform and failed silently or with an error; they now use the documented operations.
- New: order actions (Accept on Best Buy, push tracking, cancel) wired end-to-end; returns import and processing; refund push from the refund flow; offer stock publish honoring your chosen Stock Field; the manual sync wizard's Skip Existing / Specific IDs options now actually filter what gets imported.
- Shipping labels are no longer fabricated placeholders — the module calls your configured carrier, or tells you plainly that no carrier is configured.
- Dashboard now follows your company currency instead of a hardcoded
$, and its date filters no longer write to the database on every read.