Selling on the Decathlon Marketplace means living inside the Mirakl seller portal: exporting order CSVs, re-keying customer and shipping data into Dynamics 365 Business Central, watching stock drift between what the marketplace advertises and what the warehouse actually holds, and reconciling Mirakl's commission and payout statements against your general ledger weeks after the fact. Business Central out of the box has no concept of a marketplace channel. There is no sales channel dimension on the sales header, no offer record next to your item card, no place to store a Mirakl order line id so a refund can find its way back to the right posted sales invoice, and no way for a warehouse shipment posting to tell Decathlon that a parcel is on its way. Sellers end up with two systems of record, an inventory buffer held back "just in case", and a settlement process that is really a spreadsheet.

We build a dedicated AL extension that makes the Decathlon Marketplace a first-class channel inside Business Central. A codeunit layer wraps the Mirakl seller REST API (OR11/OR21 order retrieval, OF01/OF24 offer import and status, SH01/ST01 shipment and tracking, TL01 transaction and invoice lines) behind typed request and response objects, with OAuth or API-key credentials held in Isolated Storage rather than a setup field. Incoming orders are staged in a Decathlon Order Header / Decathlon Order Line buffer pair so a mapping failure never leaves a half-created sales order behind. A mapping engine then resolves the marketplace SKU to an item and variant, the offer's shipping type to a shipment method, the marketplace tax mode to a VAT posting setup, and the channel to a customer template, before creating the sales order and stamping the Mirakl order id and order line id onto table extensions of Sales Header and Sales Line. Those ids survive posting into Sales Invoice Header and Sales Shipment Header, which is what makes later refunds, cancellations and settlement matching deterministic rather than a name-and-amount guess.

Synchronisation runs on Job Queue Entries you control — typically a two-minute order poll, a stock and price push triggered from event subscribers on Item Ledger Entry, Reservation Entry and price changes with a debounce window so a bulk revaluation does not fire ten thousand calls, and a nightly full reconciliation sweep that repairs drift. Available-to-promise is computed from your real availability rules (inventory, reserved quantity, inbound purchase receipts inside a lead-time horizon, and a per-category buffer percentage you set) rather than from a raw on-hand number. Shipment confirmation is pushed back the moment a warehouse shipment or sales shipment posts, carrying carrier code, tracking number and tracking URL so the Decathlon customer sees movement without anyone touching the portal. Settlement files are imported as transaction lines, grouped per payout, and posted as a purchase invoice or journal batch that splits commission, subscription and refund fees onto the G/L accounts your controller nominates, leaving a payout that reconciles to the bank line.

Everything is delivered as a versioned AL extension: table and page extensions rather than modified base objects, a Decathlon Marketplace Setup page with a connection test, dedicated permission sets for administrator, operations and read-only roles, telemetry emitted to your Application Insights resource, and API pages exposed over the Business Central REST API v2.0 (OData v4) so Power BI, Power Automate or a Dataverse virtual table can read channel performance without another integration. It runs on Business Central online and on-premises, and we target the current release wave with a compatibility check against your specific version before we write a line of code. Where an approval or fee-tolerance workflow is wanted, it is built on standard Business Central workflow events rather than a bespoke UI.

This is build-to-order. Nothing is downloaded and nothing installs itself. We start with a scoping call, confirm your Business Central version and deployment type, your Mirakl operator account and API scopes, your item and variant structure, tax treatment and posting groups, and the exact settlement accounts you want fees to land in. From that we write a fixed scope, build against a sandbox copy of your environment, run UAT with your operations team on real Decathlon test orders, and cut over with a documented rollback. Typical delivery is 2 to 4 weeks from confirmed scope, longer only where the scope includes non-standard tax handling, multi-company posting or an unusual third-party WMS in the middle. You receive the full AL source for your version, so you are never locked to us.