Noon Store Management
This is the installation and configuration guide for Noon Store Management, the module you downloaded from your ECOSIRE dashboard. Everything on this page describes the noon_store_management module exactly as it ships today — the facts below were read out of the released build, not from a roadmap.
| Technical name | noon_store_management |
| Odoo versions | 17.0, 18.0, 19.0 (Community or Enterprise) |
| Current maintained build | 17.0 → 17.0.3.9.1, 18.0 → 18.0.3.9.1, 19.0 → 19.0.3.9.1 |
| Price | $499 USD — one-time, per Odoo version |
| Odoo module licence | OPL-1 |
| Category | Connector |
A purchase for Odoo 17 unlocks only the 17.0 download — the 18 and 19 ZIPs will not appear in your dashboard. Buy the version you actually run, and if you later upgrade Odoo you need the purchase for the new version. There is no key and no unlock step; this is enforced on the download path.
The Namshi service boundary is now stated on the connection, before anything runs. noon and Namshi are two marketplaces on one Partner API Platform, reached through two different gateways, and those gateways do not host the same services. Open Probe Capabilities on a Namshi connection and the report exports, the warehouse lookup, FBN Inbound and catalog push are reported as Not Offered with the reason - no sync has to fail first. See What Namshi offers, and what is noon-only. The dashboard connection query added in 3.9.0 is also bounded, so the dashboard payload stays constant-cost.
Namshi works end to end, VAT appears on invoices, and the dashboard says which connection it is showing.
- Namshi Test Connection. Namshi answers on its own gateway and does not serve the warehouse lookup that Test Connection performed, so a perfectly good Namshi account reported a failed connection. Enter your Warehouse Code from Namshi Seller Lab and the connection is now valid; the missing lookup is recorded as a capability, not an error. See Connecting Namshi below.
- VAT on imported amounts. noon reports amounts that already include VAT, so the connector removed the tax lines - correct totals, no VAT anywhere, which is not filable if you are VAT-registered. Pick a VAT-included sales tax per connection and the total stays exactly the amount noon reported with the VAT broken out. Existing connections keep the old behaviour until you choose.
- Dashboard connection selector. The dashboard read one connection and named none. It now offers a selector when you have more than one connection, states which one the figures belong to, and remembers your choice. Each connection also has an Open Dashboard button.
- Delivery Handling. Choose per connection whether the delivery transfer is cancelled (FBN default: noon already shipped the goods) or validated so the stock move happens in your own inventory.
- Removed: the unreachable Workflow / Auto Workflow screens. They had no menu, so nobody could open them, and their settings were never applied. The live settings are on the connection.
Reconciliation that names the problem, and refunds that say so. Three things the earlier builds reported ambiguously:
- Negative closing balances are now flagged in their own right. A closing balance below zero is impossible in a fulfilment centre; it means noon exported more units leaving a SKU and warehouse than it ever exported arriving. Some centres take stock in only through warehouse transfers and return re-inbounds, and noon exports those without a matching inbound row, so the balance goes negative through no fault of yours. Every affected month is flagged, with the filter Negative stock — missing Noon movement rows and an on-screen explanation of what to ask Seller Support for.
- Snapshot comparisons no longer disagree because of the clock. The Seller Lab inventory snapshot used to be compared against the running closing balance, so every movement noon posted after taking the snapshot showed up as a discrepancy between two entirely correct noon reports. The comparison now uses the balance as it stood when the snapshot was taken, and the row shows both Snapshot Taken At and Balance at Snapshot so you can audit it. Your closing balance itself is unchanged.
- Refunded orders are called refunded. An order with noon finance rows but no gross item value used to read Noon Reported No Item Value, which sounds like missing data. When noon has booked a reversal against a fulfilled order it is now reported as Refunded / Returned, with the credited amount and its own filter, on both the noon order and its Sales mirror. A cancellation fee is deliberately not counted as a refund — there was never an item value for it to reverse.
Also added: Inbound Receipts, Has Receipt / Document Nr filters and a Receipt / Document Nr grouping on the FBN movement ledger, so a receipts walk-through per inbound shipment (ASN) is one click. Upgrading re-flags the negative balances, relabels the refunded orders and rebuilds the reconciliation on the new snapshot basis for you.
Safer concurrent imports and clearer reconciliation evidence. Manual, wizard and scheduled order imports now share a transaction-scoped lock, so an overlapping run makes no duplicate noon request and does not advance the sync timestamp. Product imports use the same protection. Reconciliation row failures are contained inside their own savepoints.
Lost and Found labels now state explicitly that the monthly Found, Lost, net and row-count figures are the saleable subset compared with the default saleable snapshot; the stored movement ledger still retains all inventory-condition rows. Returns capability probing is non-mutating and stops after noon reports that the seller account is not granted that program, instead of presenting a false success.
Automatic finance recovery, explicit Lost and Found, and current API parity. Every scheduled finance run now revisits three historical months containing the oldest delivered or in-transit orders still waiting for a noon item-value row. Empty and fee-only months rotate to the back of the queue, so one month cannot trap the backlog forever. Noon Orders and their linked Sales orders now distinguish Awaiting Noon Finance, Valued from Noon Finance, and Noon Reported No Item Value instead of presenting every zero as the same condition.
The Inventory v2 detailed ledger's signed Lost and Found rows are now shown separately as Found Units, Lost Units, net quantity, and row count per SKU, fulfilment centre, and month. They remain part of the movement total and are never hidden inside a generic adjustment.
The API client was re-audited against noon's current public Partner API reference. All 51 current documented operations have typed helpers and an allowlisted symbolic dispatcher; all 65 unique current, legacy, and replaced operation identities are classified. Product publishing uses the current Content API, price pushes use the current country-scoped Pricing API, the Warehouse Platform path is corrected, and legacy global-seller FBN operations remain clearly marked as program-gated rather than being presented as universally available.
Month-end anchored reconciliation. The Inventory v2 movement export is a rolling window, while the Seller Lab FBN Inventory Detail Report is noon's point-in-time month-end close. The connector imports that closing report through Operations → Import FBN Month-End Close and anchors each month on it: FBN Reconciliation shows noon's opening and closing next to the movement-derived balance, and any remaining difference appears as a named per-SKU Noon Adjustment. Lost and Found rows that are present in Inventory v2 are already included and shown separately; the adjustment covers only the residual difference. SKU matching is case-insensitive because noon's exports sometimes vary the case of the same SKU. The month-end close itself is not advertised by the Impex API, so CSV import remains the truthful fallback for this one report.
Order routing and settlement posting. Each configuration can now choose the Orders Warehouse and Sales Team imported sales orders are stamped with, and the Invoice Journal auto-created invoices are written to — leave any of them empty to keep your Odoo defaults exactly as before. Settlement statements gained a Create Journal Entry action: a balanced draft entry (net payout, noon fees, marketplace clearing) on the journal and accounts you configure, linked back to the statement and never posted automatically. An opt-in Auto Draft Settlement Entries toggle drafts the entry for every statement the finance sync brings in.
Nothing to unlock any more. Earlier builds bundled a separate licensing add-on that blocked
features until a key was entered. That dependency and every execution-blocking check have been
removed: you install the ZIP and everything works. Your rights are governed by the OPL-1
licence the ZIP ships under, and support and updates still follow your purchase.
This release also publishes the 3.3.x fix pack, which had previously gone out to a customer directly while the download here still served the earlier 3.3.0 build.
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 |
| ECOSIRE dependency | None — since 3.4.0 the module installs on its own |
| Python packages | requests, PyJWT[crypto] (RS256 service-account login) |
| Platform account | A noon (or Namshi) seller account with unified Partner API access — a downloaded service-account credential .json, or OAuth 2.0 credentials |
| Purchase | Your ECOSIRE purchase for this module and your Odoo version (no key is entered in Odoo) |
Install the Python packages into the same interpreter that runs Odoo:
sudo -u odoo pip install requests "PyJWT[crypto]"
Installation
1. Download the ZIP for your Odoo version
Sign in at ecosire.com and open your dashboard downloads. You will only be offered the file matching your purchase's Odoo version — that is expected, see the warning above.
2. Extract into your addons path
unzip noon_store_management_v19_*.zip -d /opt/odoo/addons/
ls /opt/odoo/addons/noon_store_management/__manifest__.py # sanity check
The module must end up as a single top-level noon_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 Noon Store Management and click Install.
- Odoo pulls in the Odoo apps listed above automatically. No ECOSIRE dependency is needed.
Configuration
What changed in 3.0 — unified Partner API (re-authentication required)
Version 3.0.0 rewrote the connector onto noon's unified Partner API Platform (shared by noon and Namshi), replacing the legacy static-bearer client. If you upgrade from a 2.x build, every configuration must be re-authenticated — the old Base URL / API Key / Bearer Token fields are deprecated no-ops (columns are preserved, so no data is lost, but they are no longer used). Later 3.0.x releases hardened every sync loop with per-record savepoint containment (3.0.7) and rewrote the App Store listing to state only shipped capabilities (3.0.8).
What's new in 3.1 — Noon OMS/FBN order sync and item-level finance pricing
The OMS/FBN order sync and finance-report pricing below first shipped on the 19.0 build (19.0.3.1.1). Since the 3.2.1 release (2026-08-10) the 17.0, 18.0 and 19.0 builds are at feature parity — everything on this page applies to all three. Check Apps in your own database to see which patch you are on.
The FBPI endpoints described above are warehouse-scoped and only see orders placed under the FBPI program. From 3.1.1 the sync also pulls noon's official noon_noonoms_ordersexport report — the project-wide order export used by Noon OMS and Fulfilled-by-Noon (FBN) — so orders that FBPI cannot see (FBN fulfilment, project-wide OMS orders) are imported too, matched to a dedicated Noon Orders menu under Sales.
That OMS/FBN report carries no buyer PII and no line prices, so orders imported through it behave differently from a normal FBPI order:
- Their Sales mirror is created as a draft and is never auto-confirmed — it triggers no stock move, delivery, or accounting entry.
- Line prices start at zero with an explicit note ("this report does not expose buyer PII or line prices; amounts remain zero and this draft must not be invoiced without source pricing") — unless the finance report described below supplies a real price.
- From
3.1.9, when your noon project also exposes the live item-level finance report (noon_financeweb_transactionviewreportonitemlevel), the sync matches its rows to the same order by exact order and item number and prices the mirror in the report's real currency (AED on ECOSIRE's connected UAE project) instead of leaving it at zero. Orders absent from the finance report stay at zero, honestly. 3.1.12fixed a pricing gap in that match: some finance rows book the item's value into a credit column (for example "Other Order Fees including VAT") instead of "Net Proceeds" — noon's own report still satisfiesTotal = Net Proceeds + <those columns>, so the sync now recovers the value from that identity instead of reporting zero. Fee-only rows (cancellations, returns) correctly remain zero — there is no item value to recover.3.1.13added optional sales workflow automation per configuration, all OFF by default: auto-confirm completed orders once their real finance amounts arrived (delivered quantities are recorded and the automatic delivery transfer is cancelled, because noon fulfils the goods physically), auto-create draft customer invoices, and optionally auto-post them. Invoices default to draft because the finance amounts are noon gross values with no Odoo tax inferred — VAT treatment stays reviewable by your accountant.3.1.13also prices orders whose value arrives as a laterorder_updatesettlement correction instead of on the initial order row.3.1.14added FBN (Fulfilled By Noon) inventory import: noon's fulfilment-centre stock is not reachable over the Partner API, so Operations → Import FBN Inventory loads the Seller Lab inventory export instead. One line per SKU, fulfilment centre and inventory type; customer returns are never counted as saleable; re-uploading the same export changes nothing; a stale export cannot overwrite fresher stock; and the import never creates stock moves, deliveries or journal entries.3.1.15refuses to delete a configuration that still owns imported Noon orders (deletion used to cascade to every imported order shadow and FBN stock line — archive instead to disconnect while keeping data), and fixes a crash when a date window is passed to the order sync.3.7.0makes zero-valued order handling operational rather than ambiguous: each order shows whether finance has not arrived, noon supplied a real value, or noon supplied a fee-only/zero item row. The scheduled finance job automatically drains historical delivered and in-transit backlogs three oldest months at a time; cancelled orders are excluded because a zero on a cancellation is expected.
Noon does not publish buyer name, phone or address through the OMS/FBN order export or any other partner endpoint — this is a platform limitation, not something this connector can work around. Every OMS/FBN order mirror links to one explicit, clearly labelled privacy-protected marketplace buyer partner record instead of inventing or guessing a name. Real, per-order buyer detail is available only for orders placed through the FBPI program, fetched from noon's /fbpi/v1/fbpi-order/{order_nr}/customer-details/get endpoint — if that lookup fails or the order did not go through FBPI, the order keeps the shared privacy-protected buyer and the sync log records the reason at warning level (3.1.12) instead of staying silent.
3.1.0 also rebuilt the OWL dashboard: money now follows the Sales order's live currency (AED on the connected UAE project) instead of a hard-coded dollar sign, the headline KPI is labelled Gross Order Value to distinguish it from noon's post-fee net transaction amount, country cards and Top Products now read the same verified linked Sales orders and respect the selected date range, and the dashboard form was rebuilt on Odoo's stock accessible form vocabulary (WCAG 2.2 AA, keyboard-reachable KPI cards, dark-mode-aware charts). 3.1.7 added the multi-company record rules for the noon.order, noon.product and noon.customer shadow models (previously readable across companies on a multi-company database).
What's new in 3.2 — finance ledger, FBN reconciliation, and the rest of noon's official reports
Your noon seller project advertises eight official Impex export categories; earlier builds consumed three. The 3.2.0 release (2026-08-10) consumes the rest, and 3.2.1 (same day) fixed the column mapping against a live store's API exports. Everything below ships on all three Odoo majors:
- Finance ledger and statements. noon's item-level finance report is now stored row by row (
noon.finance.transaction) and grouped by statement reference (noon.finance.statement) into a receivables view: gross item value, every fee column, payouts and balance transfers. Returns, refunds and post-sale corrections appear as the negative rows noon reports them as — nothing is re-signed on the way in. - FBN inventory ledger (
noon.fbn.ledger) through the officialfbn_inventoryv2_ledgerdetailedviewexport: every customer shipment, return re-inbound, warehouse transfer, inbound receipt, vendor return and lost-and-found adjustment, with quantities signed exactly as noon reports them. This is now the primary FBN lane; the Seller Lab CSV import (3.1.14) remains the fallback and the only source of a point-in-time snapshot. - FBN reconciliation (
noon.fbn.reconciliation): opening balance, movements in and out, closing balance and mismatch flags per SKU, per fulfilment centre, per month. Balances chain forward between periods; the first period observed reports its opening as unknown rather than assuming zero. - FBN inventory aging on the FBN stock lines, through the
fbn_inventoryv2_agingexport — age buckets (0–30… open-ended366+days) with a staleness threshold you set to flag long-stored stock. - Returns actually run now. The returns lane in earlier builds could never have executed (its request payload failed the module's own contract check, and nothing called it). Returns now have a menu and a schedule, are looked up per barcode, persisted as
noon.returnrecords, and linked back to their order through the item number. - Catalog content rejections (
noon.content.rejection) — why a listing you believe you published never went live. - Product views and sales analytics (
noon.product.analytics), per product, per country, per day, rolled up onto the catalogue as views, units, revenue, conversion and a "viewed, never sold" flag. - Account capability panel on the configuration form: each API family is probed and reported as available, not granted, not offered, or unknown. A program restriction is labelled as one — FBN inbound answers "only available to global sellers" instead of surfacing as an authentication failure.
- Event notifications are opt-in (configuration → Event Notifications). Enabling them registers your database as an event destination on YOUR noon project — an outbound change to your account — so the toggle is OFF by default.
- Bounded finance re-poll for delivered orders that never received a finance row, walking the oldest unpriced orders first.
3.2.1made the FBN ledger and aging lanes read both of noon's naming families — the Impex API export headers (transaction_date,quantity_delta,partner_barcode, type-qualifiedreference_nr) alongside the Seller Lab CSV headers — after a live store proved the API family differed and every row was being skipped. It also applies the requested date window client-side when the export offers no window parameter, and excludes non-saleable movements from the saleable-snapshot reconciliation.
Every new lane runs an official Impex export, which spends the seller's report quota — capability is on by default, but each lane's SCHEDULE is opt-in, matching the existing product/order/customer lanes.
Current Partner API coverage (3.9.1)
The module's client layer covers every operation in noon's current public Partner API reference as of 2026-08-27: identity and OAuth, Catalog Platform, Content, Event Notifications, FBPI, FBPO, Impex, Offer, Pricing, Returns, Stock, Warehouse Platform, and cross-border pricing. Each of the 51 current operations is represented by an exact method/path pair, a typed helper, and an allowlisted dispatcher entry. Older FBN inbound operations remain available for entitled global-seller programs but are labelled legacy and program-gated; removed pricing and warehouse paths are retained only as historical aliases that route to the current contract. The 51 operations were re-counted against the 3.9.1 build; nothing was added or removed since the 2026-08-27 reconciliation.
This is the noon surface. Namshi is a different gateway hosting a smaller set, and a Namshi connection reports the difference itself — see What Namshi offers, and what is noon-only.
Coverage does not override noon permissions. Credential administration, sandbox order creation, shipment cancellation, invoice upload, and other privileged write operations run only when the seller account grants them and an authorized workflow invokes them. The module does not probe destructive operations merely to claim coverage.
Connecting Namshi
Namshi is a marketplace on the same noon Partner API Platform, reached through its own gateway. One connection per marketplace and per country: Namshi AE and Namshi KSA are separate connections, each with its own credentials, country and warehouse code.
Namshi does not serve the Warehouse Platform lookup that noon serves, so the connector cannot discover your warehouse for you there. That is a difference between the two gateways, not a problem with your account:
- Create the connection and set Marketplace to Namshi.
- Copy the Warehouse Code from Namshi Seller Lab into the Warehouse Code field. This is required on Namshi and optional on noon.
- Press Test Connection. It reports success and tells you that the lookup is unavailable and that the code you entered is being used.
- Open Probe Capabilities on the Capabilities tab to see the same fact recorded per connection: Warehouse Lookup - Not Offered, with the marketplace it was observed on.
Every sync and every scheduled job uses the code you typed and never calls the lookup. Namshi has no warehouse listing API at all - the 404 is correct platform behaviour, not an outage.
What Namshi offers, and what is noon-only
noon and Namshi are two marketplaces on one Partner API Platform, reached through two different gateways, and those gateways do not host the same services. Verified against the live Namshi documentation index on 2026-08-30:
| Area | Namshi | noon |
|---|---|---|
| Orders (FBPI), shipments, AWBs | Yes | Yes |
| Stock list and update | Yes | Yes |
| Pricing (global and local) | Yes | Yes |
| Returns references | Yes | Yes |
| Event notifications (webhooks) | Yes | Yes |
| Warehouse lookup | No API - set up in Seller Lab, enter the code by hand | Yes, discovered automatically |
| Report exports (finance, OMS, catalog, product analytics, content rejections) | Not offered | Yes |
| FBN inventory ledger, reconciliation and aging | Not offered | Yes |
| FBN Inbound (ASN) | Not offered | Yes |
| Catalog product create/update push | Not offered (access-gated) | Access-gated |
The connector states this on the connection itself: open Probe Capabilities on the Capabilities tab and a Namshi connection reports those areas as Not Offered, with the reason, before any sync is attempted. That is deliberately different from noon replying that your account has not been granted something - a permission you can ask for - and it means you can see what a Namshi connection will do without running anything.
If a Namshi sync stops with a message not covered above, that message names the endpoint and the gateway - send it to us, because it tells us whether anything beyond the documented boundary differs on Namshi.
VAT on imported amounts (3.9.0)
noon reports a VAT-inclusive amount per item. Adding a 5% tax on top of that
figure would overstate the invoice, so until 3.9.0 the connector removed the
tax lines instead: the totals were right and the invoice showed no VAT at all.
That is not something a VAT-registered seller can file, and no amount of
configuration on your side survived the next finance sync.
Connection - VAT on Imported Amounts now offers three treatments:
| Setting | What happens | Use it when |
|---|---|---|
| Remove tax lines | Tax lines are cleared. Correct total, no VAT shown. | You are not VAT-registered. This is the default and the historical behaviour. |
| Apply a VAT-included tax | The tax you choose is set on every imported line. Because it is included in the price, the line total stays exactly the amount noon reported and the VAT is shown separately. | You are VAT-registered. This is the setting your accountant wants. |
| Keep whatever Odoo computed | The connector does not touch tax lines at all, so your fiscal position survives the sync. | Your sale taxes are already configured as VAT-included. |
The tax you pick must be configured as included in the price. A tax that is not included is refused, because applying it on top of a VAT-inclusive amount would overstate every invoice - which is the exact error the old behaviour existed to avoid.
Delivery Handling (3.9.0)
Connection - Sales Workflow - Delivery Handling decides what the auto-workflow does with the delivery transfer:
- Record delivered, cancel the transfer (default). noon holds and ships FBN stock from its own fulfilment centre, so the quantities are marked delivered and the Odoo transfer is cancelled. Your warehouse is not decremented a second time for goods that already left your premises.
- Validate the transfer. Odoo performs the real stock move and the delivery is recorded in your inventory like any other. Choose this if you hold the stock in Odoo. If a transfer cannot be completed it is left open and the order is reported as failed, rather than being counted as delivered.
Reading the dashboard on more than one connection (3.9.0)
With noon and Namshi both connected, the dashboard used to read the first active
connection and say nothing about it - so the figures looked like the whole
business and were one channel. From 3.9.0 a Connection selector appears in
the dashboard header whenever you have more than one active connection, the
response names the connection the figures belong to, and your choice is
remembered. Each connection also carries an Open Dashboard button.
Reconcile FBN inventory against Seller Lab
Understand the three separate numbers
Do not compare an activity report directly with a point-in-time close and expect them to be the same number. The module keeps the evidence in three layers:
| Layer | Source | What it proves |
|---|---|---|
| Reported activity | Inventory v2 detailed and summary exports | Which signed movements noon published, including Lost and Found |
| Closing truth | Seller Lab FBN Inventory Detail Report | What noon says was held at the selected close date |
| Residual | Odoo reconciliation calculation | Quantity not explained by the published opening plus movements |
The residual is labelled rather than hidden:
Noon Adjustment = Noon Closing Anchor - (Noon Opening Anchor + Net Reported Movements)
A zero adjustment means the two noon sources tie for that SKU, warehouse, month and inventory scope. A non-zero adjustment is a review item; it does not by itself prove an Odoo error.
Import the same FBN Inventory Detail close CSV and compare the same seller, close date, warehouses and inventory types. The imported Noon Closing Anchor should match that source file exactly. The movement-derived closing is a different measure and can differ when the rolling ledger starts after stock was already present or does not publish a movement.
Month-end procedure
- In Seller Lab, open Noon.com → Fulfilled by Noon → FBN Reports → Generate Reports.
- Choose Inventory → FBN Inventory Detail Report and the required close date. Noon describes this as a point-in-time report and makes the latest close available up to T-1.
- Download and preserve the original CSV. Do not remove rows, merge SKUs, alter fulfilment centre codes, or change SKU letter case.
- In Odoo, open Noon → Operations → Import FBN Month-End Close. Select the matching configuration, close date and CSV; leave Rebuild Reconciliation enabled.
- Review the import result: processed, created, updated, skipped and failed counts. Re-importing the same source is idempotent.
- Open Noon → Operations → FBN Month-End Close and confirm seller/configuration, close date, warehouses, inventory-type rows and the total against the CSV.
- Open Noon → Operations → FBN Reconciliation, group by Period, and use Anchored Month Ends, Noon Adjustments, or Carried Forward filters.
- For a difference, open the row and choose View Movements. Compare the exact partner SKU, fulfilment centre, month and inventory condition before opening a noon support case.
Six like-for-like checks
Before escalating a mismatch, confirm both sides use:
- the same seller project and country;
- the same close date and timezone cut-off;
- the same fulfilment centres — do not mix real warehouses with transit unless both totals do;
- the same inventory-type scope — the default anchor totals all reported inventory types, while a saleable-only comparison must apply that filter on both sides;
- the same partner SKU after case-insensitive normalization; and
- the same report family — an aging snapshot or dashboard tile is not an Inventory Detail close unless its as-of date and scope align.
Lost and Found
The Inventory v2 detailed ledger imports Lost and Found automatically when noon publishes those rows. Quantities retain noon's sign, and the reconciliation shows Found Units, Lost Units, net quantity, and source-row count for the saleable subset used in the default saleable comparison. The full ledger retains all condition rows.
Lost/Found is operational inventory evidence. The connector does not assume a lost unit will be reimbursed, create a reimbursement, or auto-post an accounting entry. An accountant should review the corresponding finance/settlement rows and the company's stock-loss policy before a draft entry is approved.
Zero-valued Noon orders
The OMS/FBN order export contains references and quantities but no line prices. Historical value comes only from noon's item-level finance report, never from today's offer price.
| Amount status | Meaning | Action |
|---|---|---|
| Valued from Noon Finance | A matching item-level finance row supplied a historical value | Verify currency and gross/net before invoicing |
| Awaiting Noon Finance | The order arrived before its finance value, or the bounded backfill has not reached that month | Run Configuration → Settings → Re-poll Unpriced Orders or allow the scheduled finance recovery |
| Noon Reported No Item Value | noon supplied a fee-only or zero item row | Review the source row; do not invent a value |
| Cancelled / not applicable | Zero is expected because the commercial event did not complete | No valuation unless a later correction arrives |
Open Sales → Noon Orders, display Noon Amount Status, Noon Net, and Adjustments, then inspect Finance Transactions for the exact order and item. Scheduled finance runs revisit the three oldest delivered or in-transit months still awaiting a value; cancelled orders are excluded from that backlog.
Automatic, manual, and permission-gated lanes
| Availability | Examples | Meaning |
|---|---|---|
| Automatic when configured | OMS/FBN and FBPI orders, catalogue, offers/stock, item-level finance, Inventory v2 movements and aging, analytics, content rejections | The module uses documented Partner API or Impex operations |
| Manual source control | FBN Inventory Detail month-end close | noon's public Impex category list does not advertise this historical point-in-time report, so the original Seller Lab CSV is imported |
| Permission/program gated | Returns merchant lookup, privileged Content/Pricing writes, legacy global-seller FBN inbound | The endpoint is implemented, but noon decides whether the seller account/program may use it |
| Not exposed as a public partner feed | OMS/FBN buyer PII and dedicated bank-statement matching | The connector keeps the limitation visible and does not invent data |
For noon's definitions and report access, see FBN Inventory Detail, Inventory Ledger Reports, and Accessing FBN Reports.
Reading FBN reconciliation month by month (3.3.0)
Group noon → FBN Reconciliation by Period and the list becomes a monthly stock statement: the Opening and Closing columns total per month, and one month's closing total is the next month's opening total.
Up to 3.2.3 that only held per SKU. Read per month it did not, because a SKU that held stock in the fulfilment centre but recorded no movement that month had no row at all — so its balance dropped out of the monthly total and reappeared the month it next moved. 3.3.0 gives those months a row of their own, marked Carried Forward (No Movement): opening equals closing, no movements, greyed out in the list. A SKU whose balance is zero is still left out — it adds nothing to either total, and listing every SKU that ever sold out in every later month would bury the report.
- The Hide Carry-Forward Rows filter restores the movements-only reading. The monthly totals will not chain in that view, by design — the dormant balances are exactly what carries them across a boundary.
- The Carried Forward (No Movement) filter shows only the dormant months, which is the quickest way to see stock sitting in a fulfilment centre with no activity behind it.
- Per-SKU behaviour is unchanged: each row still opens on that SKU's previous closing, and the first period observed still reports its opening as unknown rather than assuming zero.
3.3.0 also removes a silent limit: a rebuild used to read the oldest 20,000 saleable movements only, so a large ledger quietly lost its most recent months from the report. The ledger is now walked in full, and the rebuild reports whether the scan was complete before pruning anything.
Upgrading rebuilds the reconciliation for you from the movements already stored — nothing is re-downloaded and no report quota is spent.
Connect to noon or Namshi
Create a connection record on the noon.configuration model — one per country and/or marketplace. The connection fields in the 3.x builds are:
| Field | Technical name | Type | Notes |
|---|---|---|---|
| Configuration Name | name | Char | required |
| Seller ID | seller_id | Char | required |
| Country | country | Selection | ae / sa / eg — drives currency, warehouse and tax preflight routing |
| Company | company_id | Many2one | required |
| Marketplace | marketplace | Selection | noon or namshi — both route through the unified Partner API gateway |
| Authentication Mode | auth_mode | Selection | service_account (primary) or oauth |
| Service-Account Credential | credential_json | Text | paste the downloaded service-account .json; key_id, project_code and the private key are parsed out on save |
| OAuth Access Token | oauth_access_token | Char | OAuth mode only — sent as a Bearer header |
| User Agent | user_agent | Char | mandatory on every request; a default is provided |
| Sandbox Mode | sandbox | Boolean | routes to the sandbox gateway |
In service-account mode the client signs an RS256 JWT with your downloaded private key, logs in at /identity/public/v1/api/login and holds the returned session cookie; it re-authenticates once automatically on a 401 and honours Retry-After on 429 responses. The Test Connection wizard calls the authenticated whoami route and reports the real outcome.
The module contacts the marketplace-scoped gateways: noon-api-gateway.noon.partners (sandbox: noon-sandbox-api-gateway.noon.partners) and namshi-api-gateway.noon.partners for Namshi. Your firewall must allow outbound HTTPS to them.
The same record carries per-scope sync toggles (sync_products, sync_orders, sync_customers, sync_inventory, and their auto_sync_* counterparts). Leave anything you are not ready for switched off, and turn them on one at a time.
KSA and Egypt tax preflights
- KSA (ZATCA Phase 2): the module refuses to process a KSA order until the customer's partner record carries a VAT registration number and CR number — both fields are added on the partner form by this module because Odoo's Saudi localization does not carry them. The refusal names the missing fields.
- Egypt (ETA): Egypt orders require the customer's 14-digit ETA tax id; an invalid or missing id is refused before the operation runs.
- Orders for other countries are untouched by these preflights.
Webhook and API endpoints your server exposes
| Endpoint | Auth | Purpose |
|---|---|---|
/noon/webhook | public | Inbound Event Notifications from noon. Verified by IP allowlist (noon's documented event source IPs, honouring the left-most public X-Forwarded-For), not by an HMAC signature; duplicate deliveries are deduplicated by message_id |
/noon/api/status | logged-in user | connection/sync status for the dashboard |
/noon/api/sync | logged-in user | triggers a sync from the dashboard |
/noon/dashboard/data | logged-in user | dashboard KPI data |
Register your https://<your-odoo-host>/noon/webhook URL as an HTTPS event destination from Noon → Configuration → Webhooks — the module creates and updates the destination through the Event Notifications management API. Scheduled polling crons remain active as the fallback, so no order is missed if events do not arrive.
Honest capability boundaries
- Product publishing is supported through the current Content API, but it requires noon permission plus complete category, brand, image, and attribute mappings. Missing mappings stop before the API call and name exactly what must be configured.
- Price synchronization is supported through the current country-scoped Pricing API. Current offer prices are never substituted for historical order amounts; order valuation comes only from noon's finance report for that order and item.
- Settlement statements can create balanced draft journal entries on the configured accounts. The connector never posts them automatically.
- The Seller Lab month-end Inventory Detail close remains a manual CSV import because noon's Impex API does not advertise that point-in-time report. The Inventory v2 detailed ledger, including Lost and Found, syncs automatically through Impex.
- No documented bulk coupon/customer export exists. The module does not invent one.
The detail above was read from the 19.0.3.9.1 build. The Odoo apps it depends on, the scheduled actions and the menu layout can differ slightly between the 17.0, 18.0 and 19.0 builds, so check the values in your own database after installing rather than assuming this page matches your version exactly.
Negative closing balances, and what they mean (3.8.0)
A closing balance below zero is not an arithmetic slip — it is the report telling you that the
noon movement export is incomplete for that SKU and fulfilment centre. Some centres never receive
an inbound_received row at all: stock reaches them through warehouse transfers and return
re-inbounds, and those arrive in the export without the matching receipt. The balance then goes
negative no matter how correct your own books are.
- The Negative stock — missing Noon movement rows filter lists every affected month. The flag is set on every period in which the balance is negative, not only the newest one, so you can see when the gap opened.
- The row is coloured in the list and carries an explanation on the form. Re-importing what noon already sent will not fix it; ask Seller Support for the missing movement rows for that SKU, warehouse and period.
- The count appears in the notification after Sync FBN Inventory Ledger, Rebuild FBN Reconciliation and the month-end close import, so it is visible without opening the list.
Why a snapshot mismatch is measured at the snapshot time (3.8.0)
noon takes its Seller Lab inventory snapshot at a moment; the movement ledger keeps running afterwards. Comparing a running balance from today against a snapshot taken three days ago reports three days of perfectly normal trading as a discrepancy.
From 3.8.0 the comparison is made against the movement-derived balance as of the snapshot
moment. Two fields on the reconciliation row make it auditable: Snapshot Taken At (the time
noon stamped on the export) and Balance at Snapshot (what your movements said at that moment).
The Variance is the difference between those two — a real disagreement between two noon
reports, worth raising with Seller Support.
- Closing is unchanged: it remains the running balance at period end.
- Where a SKU is summed from stock lines exported at different times, the oldest is used — a summed quantity is only as current as its oldest component.
- If noon reported no snapshot time for a line, the previous running-balance comparison still applies. That is stated on the row (Snapshot Taken At is empty) rather than assumed.
Receipt (ASN) tie-out (3.8.0)
On noon → FBN Inventory Movements, filter Inbound Receipts and group by Receipt / Document Nr. Each group is one inbound shipment, with its units summed — which is the shape you need when tying a month of receipts back to what you actually sent in. Has Receipt / Document Nr narrows to the movements that carry a reference at all.
Troubleshooting
Keys and unlocking
There is nothing to enter and nothing to unlock: from 3.4.0 everything works as installed,
and your rights are governed by the OPL-1 terms the ZIP ships under.
| Symptom | Cause and fix |
|---|---|
| Odoo asks you for a key | You are on a 3.3.x or older build; from 3.4.0 no key exists — download the current build from your dashboard. |
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). |
| 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. |
Version history
| Odoo version | Current maintained build |
|---|---|
| 17.0 | 17.0.3.9.1 |
| 18.0 | 18.0.3.9.1 |
| 19.0 | 19.0.3.9.1 |
ECOSIRE module versions are <odoo major>.<module major>.<minor>.<patch>, so 19.0.3.9.1 is the Odoo 19 build of module version 3.9.1. Your installed version is shown in Apps. The 3.0.0 release migrated the connector to the unified Partner API (re-authentication required after upgrading from 2.x); 3.0.7 added fleet-wide savepoint containment to every sync loop; 3.1.0 rebuilt the OWL dashboard for accessibility (WCAG 2.2 AA) and dark-mode support; 3.1.14–3.1.16 added FBN inventory import, deletion safety on connected configurations, and a listing-truth pass; 3.2.0/3.2.1 (2026-08-10) added the finance ledger, FBN ledger/reconciliation/aging, returns, content rejections, product analytics and the capability panel described above — and brought 17.0 and 18.0 to feature parity with 19.0; the 3.3.x fix pack followed; 3.4.0 removes the licence-client dependency and every execution-blocking licence check; 3.4.1 fixed the Imported Products/Orders screen wiring and the silently-replaced warehouse code; 3.5.0 (2026-08-21) adds per-configuration order routing (warehouse, sales team, invoice journal) and settlement statements as draft journal entries; 3.6.0 (2026-08-25) adds month-end anchored reconciliation; 3.7.0 (2026-08-27) adds automatic historical finance recovery, explicit valuation states, visible Lost and Found totals, complete current public API helpers, current Content/Pricing operations, and the corrected Warehouse Platform path; and 3.7.1–3.7.5 harden permission probing, savepoint isolation, concurrent product/order imports and the marketplace order date through confirmation; 3.8.0 (2026-08-30) flags impossible negative closing balances, measures snapshot variances at the moment noon took the snapshot, reports reversed orders as Refunded / Returned and adds receipt (ASN) grouping; 3.9.0 makes Namshi connections testable and adds VAT-included tax handling, a dashboard connection selector and a per-connection Delivery Handling choice; 3.9.1 states the Namshi service boundary on the connection before any sync is attempted.