Noon Marketplace Connector

The problem

Gulf sellers running Dynamics 365 Finance & Operations face a specific set of gaps that connectors designed for North American channels simply do not address.

The catalog is bilingual. Product names and descriptions must publish in Arabic and English, and in F&O that means maintaining translated product names properly rather than pasting Arabic into a description field and hoping the encoding survives. Pricing must be VAT-correct against the rate in force in the selling country, and marketplaces generally display tax-inclusive prices while F&O trade agreements are commonly maintained exclusive — get that conversion wrong by a rounding rule and every order posts a small variance that finance chases forever. Fulfilment is usually split: some stock sits in your own warehouse, some sits in a marketplace fulfilment centre in another emirate or another country, and F&O has no visibility of the second. Then the settlement statement lands with commission, fulfilment fees and returns netted off, and reconciliation becomes a manual exercise.

What ECOSIRE builds

A dedicated integration model for F&O, delivered as X++ extensions in your own package. No overlayering, no changes to Microsoft application code, deployed through your LCS or DevOps pipeline.

Bilingual catalog publishing

Released products publish with both Arabic and English names and descriptions, sourced from F&O product translations rather than improvised fields, so the language your marketplace listing shows is the language your ERP actually holds. Variants, unit conversions, barcodes and category-required attributes are mapped, with the marketplace attributes that block a listing held in extension fields on the product so a listing failure is a data problem you can fix in F&O, not a mystery in a portal. Listing identifiers are stored against the product so the relationship survives re-publishing.

VAT-correct pricing

Pricing is derived from sales price and discount trade agreements (PriceDiscTable) and converted to the marketplace's display convention using an explicit, documented rule: which VAT rate applies for the selling legal entity, whether the source price is inclusive or exclusive, and exactly how rounding is performed. That rule is agreed and signed off during scoping and recorded in the mapping document, because this is the single most common source of penny variances between a marketplace order and a posted invoice. Where you sell into more than one Gulf country from different legal entities, each entity carries its own rate and rounding configuration.

Orders, customers and tax documents

Orders are staged and created as F&O sales orders through a data entity, with the marketplace order number retained for traceability and support. Customer handling follows a strategy chosen during scoping — a marketplace customer account per legal entity, or individual records created from a template with a fixed customer group, payment terms, delivery mode and sales tax group. Buyer tax registration details and delivery data are captured on the order so the tax documents your finance team must produce have the fields they need. Cancellations and returns are matched back to the originating sales order and actioned per the agreed rule, generating the credit document finance specifies rather than leaving a manual clean-up.

Fulfilment centre and own-warehouse inventory

Available quantity is calculated from InventSum for nominated sites and warehouses with a configurable buffer, so marketplace listings never advertise stock committed elsewhere. Inventory held in a marketplace fulfilment centre is modelled as its own site or warehouse in F&O, so on-hand reporting is truthful and stock movements to and from the fulfilment centre are real transfer transactions rather than adjustments. Orders shipped by the fulfilment centre post their inventory issue automatically; orders shipped from your own warehouse run through standard picking and packing, including work created and confirmed on the warehouse mobile app if you use advanced warehouse management, with carrier and tracking references written back on packing slip posting.

Settlement reconciliation

Settlement statements are imported into a staging table and matched to the originating sales orders. Commission, fulfilment fees, shipping charges, returns and adjustments post to the ledger accounts and financial dimensions you nominate. Lines that cannot be matched are reported as exceptions rather than posted to a suspense account, so a payout discrepancy is visible immediately instead of at month end.

How it runs

Every message is queued in an integration table with status, attempt count, payload snapshot and last error, processed by batch jobs under the F&O batch framework with configurable batch groups so the work can be pinned to a dedicated AOS. Retries use backoff; exhausted messages park for an administrator and are visible in an operations form that supports filtering and single or bulk requeue. Nothing is silently dropped.

Credentials, endpoints, warehouse selection, VAT and rounding rules, customer strategy, settlement posting profile and job cadence are all configured per legal entity, so a group selling across the Gulf runs several marketplace accounts, currencies and tax profiles from one deployment without code changes. Where it suits your integration estate, the same data is exposed via OData on custom data entities or routed through Power Platform instead of direct calls — decided in scoping.

Who it is for

Distributors, brands and retailers in the UAE, Saudi Arabia and the wider Gulf running F&O who sell through a regional marketplace and need an Arabic catalog, VAT-correct prices and honest inventory. Groups with several legal entities across Gulf countries with different VAT rates. Sellers using marketplace fulfilment who currently cannot see that stock in the ERP at all.

How delivery works

1. Scoping call. Your F&O version and topology, which legal entities and countries are in scope, your VAT position and rounding preference, catalog and translation setup, fulfilment models, customer strategy and settlement posting rules. You receive a written scope listing every mapping and decision.

2. Fixed quote. A fixed price and delivery date against that scope. Anything outside it is quoted separately before work starts.

3. Build. Developed against your version in a dedicated model and package, following your naming conventions.

4. Install in test. The deployable package is installed into your sandbox, configured with you, and taken through agreed test cases using your data — bilingual listing publish, a VAT-inclusive price check against a posted invoice, a live order cycle, a fulfilment-centre order and a settlement import. Production waits for your sign-off.

5. Production. Promoted through your normal release process with a cutover plan covering initial catalog publish, first inventory sync and the point manual order entry stops.

6. Support. A defect-fix window after go-live covering anything that does not behave as the signed-off scope describes.

Lead time for a standard build is two to four weeks from scope sign-off and sandbox access.