Walmart Marketplace Connector

A second marketplace channel usually starts optimistically and degrades quietly. Someone downloads orders to a spreadsheet, someone else keys them into Finance and Operations, and for a few weeks it works. Then the channel grows. Acknowledgements slip past their window, oversells happen because on-hand was published from yesterday, tracking numbers go up late, cancellations arrive after the pick list is printed, and the finance team spends the last three days of the month trying to explain why the deposit does not match the sum of the invoices.

The temptation is to reuse whatever mapping already exists for another marketplace. It does not transfer cleanly. The item model, the order lifecycle, the shipping update contract, the returns flow and the settlement report are all shaped differently, and the fulfilment service adds a third inventory position that your ERP does not own but still has to account for. A generic field-mapping tool can move data; it cannot express the difference between inventory you can pick, inventory sitting in a fulfilment centre, and inventory reserved against an order you have already acknowledged.

ECOSIRE builds a purpose-made connector as a Dynamics 365 Finance and Operations extension model, written in X++ with no overlayering, so it lives beside your existing customisations and moves through your normal deployment pipeline.

What ECOSIRE builds

### Item and listing publishing Released products in InventTable and EcoResProduct are the source of truth. The connector maps the product, its attributes, its unit of measure conversions and its category assignment into the marketplace item structure, then submits through the bulk item feed and tracks the feed result back onto the product record. Product masters with variants are handled as variants rather than as unrelated items, so size and colour dimensions stay coherent. Publishing is deliberately opt-in per product through a channel assignment, not a blanket push of your whole catalogue.

### Order intake and acknowledgement A batch job polls for new orders on a schedule you set and creates sales orders in Finance and Operations with the channel, the marketplace order identifier and the customer purchase order reference stamped on SalesTable. Order lines land on SalesLine with the marketplace item mapped back to your released product, tax handled through your sales tax groups rather than recalculated, and shipping charges landed as a charge code so revenue and freight do not blur together. Acknowledgement is sent back automatically as soon as the order is created, because that acknowledgement has a clock on it, and the acknowledgement result is recorded so a failure is visible rather than assumed.

### Inventory and price synchronisation Available quantity is calculated from InventSum across the warehouses you nominate, net of reservations and net of the buffer you configure per product or per warehouse, then published through the inventory feed on an interval. Price updates come from your trade agreements in PriceDiscTable or from a channel-specific price list, whichever you choose during scoping, so the storefront price and the ERP price cannot drift apart unnoticed. Every publish records what was sent and what the marketplace accepted.

### Fulfilment, shipping and returns When the warehouse picks and packs, the shipping update goes out with the carrier, the tracking number and the line quantities, sourced from the packing slip or from the load and shipment records if you run advanced warehouse management. Warehouse mobile app work is unchanged; staff scan as they do today and the connector reads the result. Cancellations and refunds are pulled in and applied against the sales order or as a return order, so credit does not have to be raised by hand and reconciled later.

### Fulfilment operated by the marketplace Where goods are held in the marketplace fulfilment network, the connector treats that as its own warehouse in Finance and Operations. Inbound shipments create transfer orders, received quantities post against them, and the on-hand position in that warehouse reflects what the marketplace reports rather than what you hope is there. Orders fulfilled from that inventory create the sales order and invoice without generating pick work for your own staff, which keeps your warehouse KPIs honest.

### Finance, fees and reconciliation Settlement reports are imported and broken into their components, so commission, fulfilment fees, shipping recovery and adjustments post to the ledger accounts you designate through a journal rather than being netted into one line nobody can audit. Deposits are matched against the invoices they cover, and unmatched amounts are surfaced as a working list. Channel financial dimensions are stamped on the transactions so contribution by channel is a report rather than a project.

Who this is for

This suits North American sellers already running Finance and Operations who have taken a second marketplace beyond the volume a person can key in, and who care that the ERP remains the system of record rather than becoming a downstream copy of a marketplace dashboard. It suits operations with real warehouse complexity, where advanced warehouse management, multiple sites and reservation logic mean a naive quantity push causes oversells. It suits finance teams who have been asked to explain a deposit and could not.

It is a poor fit if you are pre-launch with no order history and no clear picture of your fulfilment model, or if your inventory is managed entirely outside Finance and Operations.

How delivery works

This is built to order. Nothing is downloadable, there is no trial, and the connector does not exist until we build it for your environment.

1. Scoping call. We map your channel model, the warehouses and sites in scope, whether advanced warehouse management is live, how you want customers represented, your tax and charge setup, your fulfilment mix, and your platform and application version. 2. Fixed quote. You get a written scope and a fixed price before development starts. Anything discovered later that falls outside it is quoted separately, not absorbed quietly. 3. Build. We develop the extension model against your version, with the marketplace sandbox credentials you issue us, and test against representative products and orders from your data. 4. Install in test, then production. The package deploys to your sandbox through your LCS pipeline first, where your team runs the documented test pack end to end, including a real order through to invoice and settlement. Production follows on your change window after sign-off. 5. Support. An agreed support window follows go-live for defects in what we built, with a documented escalation route.

Typical lead time from signed quote to a package ready for your sandbox is one working week, driven mostly by how many fulfilment models you run and whether advanced warehouse management is in scope.

What this is not

We are not an authorised or accredited partner of the marketplace, and we do not resell its services. The connector is built against the publicly documented seller APIs and runs on your own developer credentials, held in Azure Key Vault, in your tenant. We also do not manage your listings, your pricing strategy or your account health; we build the integration that keeps your ERP and your channel telling the same story.