Skip to main content

Noon Store Management

The ECOSIRE Noon Store Management module connects your noon (or Namshi) seller account to Odoo across the UAE, Saudi Arabia and Egypt from a single instance. It talks to noon's unified Partner API Platform — the same gateway noon and Namshi share — to import orders, sync your catalogue, push stock, and enforce the KSA ZATCA Phase 2 and Egypt ETA tax preflights before an order is processed.

Compatibility: Odoo 17 / 18 / 19 (Community or Enterprise) Current maintained build: 17.0 → 17.0.3.10.5, 18.0 → 18.0.3.10.5, 19.0 → 19.0.3.10.5 Price: $499 USD (one-time, per Odoo version) Licence: OPL-1 — no key required; you buy per Odoo major version

Installing for the first time?

This page is the overview. The step-by-step download and configuration guide lives at Noon Store Management — installation & configuration.

What this module does​

  • Every Partner API operation the connector calls is recorded in ECOSIRE's verified API contract (3.10.5) - the catalogue (SKU generation, mapping, renaming, deletion, barcode import), Content, FBPI invoice upload, FBPO purchase-order, Offer and Cross-Border Pricing operations were already implemented but had not yet been checked into the contract our release gates verify against; each was confirmed on its own page of the noon Partner API reference. No request the connector makes has changed. The release also adds 34 regression tests on all three Odoo series, each proving a failure case a real seller has hit on a marketplace connector (idempotent re-imports, two stores keeping the same order number apart, scheduled sync only where enabled, masked customer data staying masked, an unknown report currency failing closed, and more). It also installs with a clean log on Odoo Online and odoo.sh: the OMS and finance report-quota messages the connector emitted while degrading gracefully were error-level lines, which Odoo's hosting treats as a blocked deployment, and they are warnings now. A run that could not read a report still records error on its sync log with the failed-record count, so nothing is hidden

  • Dashboard and sync endpoints respect company boundaries (3.10.4) - in a multi-company database the dashboard and the sync endpoint now work only with the noon connections of the companies you are working in, and starting a sync is reserved for noon Managers. The noon catalogue list, with its Not Mapped to a Product filter, also has its own Noon → Noon Catalogue menu

  • Installs on Odoo Online (3.10.3) - the module declares its version in the form Odoo Online accepts, so it installs on Odoo's own hosting as well as on your own server. The FBN inbound shipment inspector is also restricted to noon managers, the same access level every other warehouse action in the module already uses

  • Partner API route coverage you can check (3.10) - every operation in noon's unified Partner API is referenced by the module's API client in a form tooling can verify, and a coverage guard ships inside the module that fails loudly if a documented operation ever loses its route. The three operations noon has withdrawn or renamed, and the documented families that sit outside the bounded contract, are recorded with their evidence in a ledger the guard checks in both directions

  • Namshi as a first-class marketplace (3.9) - Namshi answers on its own gateway and does not host a warehouse listing API at all (warehouses are created in Seller Lab), so Test Connection no longer treats that as a failed connection: type your Warehouse Code and the connection is valid. The Capabilities panel states up front which services Namshi offers and which are noon-only, so you can see what a Namshi connection will and will not do before running a single sync. Namshi AE and Namshi KSA are separate marketplaces and get one connection each

  • VAT that your accountant can file (3.9) - noon reports VAT-inclusive amounts, so the connector used to strip the tax lines and leave invoices with correct totals and no VAT at all. Choose a VAT-included sales tax per connection and the total stays exactly the amount noon reported while the VAT is shown separately

  • A dashboard that says which connection it is showing (3.9) - with noon and Namshi both connected the dashboard used to read one of them silently; it now has a connection selector and names the connection the figures belong to

  • Delivery Handling per connection (3.9) - record the quantities as delivered and cancel the Odoo transfer (right for a pure FBN seller, and still the default), or validate the transfer so the stock move lands in your own inventory

  • Reconciliation that tells you what is wrong, not just that something is (3.8) — a closing balance below zero is impossible in a fulfilment centre, so it is flagged in its own right (Negative stock — missing Noon movement rows) with the cause named: some centres take stock in only through warehouse transfers and return re-inbounds, which noon exports without a matching inbound row. Inventory snapshots are compared against the balance as it stood when noon took the snapshot, so movements posted afterwards are no longer reported as discrepancies between two entirely correct noon reports

  • Refunded orders are called refunded (3.8) — an order carrying noon finance rows with no gross item value but a reversal booked against it is reported as Refunded / Returned with the credited amount, instead of the ambiguous “noon reported no item value”. A cancellation fee is deliberately not counted as a refund

  • Receipt (ASN) tie-out (3.8) — group the movement ledger by Receipt / Document Nr and walk one inbound shipment at a time

  • Orders — FBPI order import (list → per-order detail → idempotent upsert) with honest processed/created/updated/failed counts; Noon OMS and Fulfilled-by-Noon (FBN) orders are also imported through noon's official orders-export report, as draft Sales mirrors that are never auto-confirmed, priced from noon's item-level finance report where the account exposes it

  • Catalogue — product import through noon's official global-catalogue CSV export, with idempotent product shadows mapped to Odoo products

  • Warehouses — discovered automatically through the Warehouse Platform service; single-warehouse accounts configure themselves during Test Connection

  • Tax preflights — KSA (ZATCA Phase 2: VAT registration number + CR number) and Egypt (14-digit ETA tax id) are required on the customer record before an order for that country is processed

  • Multi-country, multi-marketplace — one configuration per country (UAE/KSA/Egypt) and per marketplace (noon or Namshi, both on the same Partner API gateway)

  • Stock — push to the verified stock-update endpoint for mapped SKUs

  • Finance ledger & statements (3.2) — noon's item-level finance report stored row by row and grouped by statement reference into a receivables view: gross value, fees, payouts and balance transfers

  • FBN inventory ledger, reconciliation & aging (3.2–3.7) — every FBN stock movement from noon's official ledger export, a per-SKU/per-centre/per-month reconciliation with mismatch flags, and age buckets with a staleness threshold; the Seller Lab Inventory Detail close is the authoritative point-in-time control

  • Lost and Found reconciliation (3.7) — signed Lost and Found rows from Inventory v2 appear explicitly as found, lost, net units and source-row count per SKU, fulfilment centre and month; they remain in the movement total and are not disguised as a generic adjustment

  • Automatic historical order valuation (3.7) — scheduled finance runs revisit the oldest delivered and in-transit zero-valued mirrors three months at a time, while explicit amount states distinguish finance still pending from a genuine source-reported zero

  • Current Partner API parity (3.7) — exact helpers and an allowlisted dispatcher cover all 51 operations in noon's current public reference; 65 unique current, legacy and replaced identities are classified, with program-gated operations labelled honestly

  • Content and pricing publication (3.7) — mapped products publish through noon's current Content API and mapped prices use the current country-scoped Pricing API

  • Month-by-month FBN stock statement (3.3) — group the reconciliation by period and one month's closing total is the next month's opening total: SKUs holding stock with no movement that month are listed as Carried Forward so a dormant balance can no longer drop out of the monthly total (filter them out again in one click)

  • Returns (3.2) — returns imported on a schedule, persisted as records and linked back to their orders by item number

  • Content rejections & product analytics (3.2) — why a listing never went live, and per-product/per-country/per-day views, units, revenue and conversion with a "viewed, never sold" flag

  • Capability panel (3.2) — each API family probed and reported as available / not granted / not offered / unknown, so a program restriction never masquerades as an authentication failure

  • Proof of delivery — signature capture from delivery events onto the order

  • Webhooks — Event Notifications with IP-allowlist verification and a fast 200 ACK, with scheduled polling as the fallback so no order depends on the webhook alone

  • Auto-workflow — optional auto-confirm, auto-invoice and auto-deliver per configuration

  • Dashboard — an accessible (WCAG 2.2 AA) OWL dashboard with per-country KPIs in the order's real currency and Chart.js charts

How FBN inventory reconciliation works​

The connector deliberately keeps three measures separate:

MeasureSourceMeaning
Reported activityInventory v2 detailed ledgerThe signed movements noon published, including Lost and Found
Closing anchorSeller Lab FBN Inventory Detail closenoon's point-in-time balance for the selected close date
Noon AdjustmentOdoo calculationThe quantity the close cannot explain from the published opening plus movements

Noon Adjustment = Noon Closing Anchor - (Noon Opening Anchor + Net Reported Movements)

Importing the same FBN Inventory Detail close CSV with the same seller, close date, warehouse, and inventory-type filters should reproduce that file's closing quantity exactly. The movement-derived closing is a different measure and can differ when noon's rolling ledger omits history or a movement. Follow the complete FBN reconciliation procedure before comparing totals.

Honest boundaries​

  • Permissions still apply. Product publication, credential administration, sandbox-order creation, shipment cancellation, invoice upload and other privileged operations work only when noon grants the seller account that capability. Missing product mappings fail before a Content API write and state exactly what is missing.
  • No automatic journal posting. Settlement statements can create balanced draft journal entries on configured accounts, but the connector never posts them automatically.
  • No buyer name, phone or address on Noon OMS/FBN orders. noon does not expose that data on those orders through any partner endpoint. Real buyer detail is only available for orders placed through the FBPI program; every other order links to one explicit, clearly labelled privacy-protected marketplace buyer instead of a guessed name.
  • Historical order values never come from today's offer price. Prices can be pushed through the current Pricing API, but a past order is valued only from noon's item-level finance report for that order and item.
  • One report remains manual. The Seller Lab month-end Inventory Detail close is not advertised by the Impex API, so that point-in-time report remains a CSV import. Inventory v2 movements, including Lost and Found, are automatic.
  • No bulk coupon/customer export. noon's current public reference does not document one, so the module does not invent it.

Prerequisites​

  • Odoo 17, 18, or 19 (Community or Enterprise)
  • Your ECOSIRE purchase for this module and your Odoo major version (no key is entered in Odoo)
  • A noon (or Namshi) seller account with unified Partner API access: a downloaded service-account credential .json, or OAuth 2.0 credentials
  • Python packages requests and PyJWT[crypto] installed into the interpreter that runs Odoo

Quick start​

  1. Download the ZIP for your Odoo version from your ECOSIRE dashboard.
  2. Extract it into your Odoo addons directory and restart Odoo. No ECOSIRE dependency is needed.
  3. Apps → Update Apps List, search for Noon Store Management, install.
  4. Create a configuration per country/marketplace, paste your service-account credential (or OAuth token), and click Test Connection.
  5. Turn on the sync toggles you are ready for — products, orders, customers, inventory — one at a time.

Full detail — including the connection field reference, API coverage boundaries, reconciliation workflow, and troubleshooting — is in the installation & configuration guide.

Support​

Last updated on