Walmart Marketplace Connector

The problem

Walmart Marketplace runs on clocks. An order has to be acknowledged within a short window of being released. It has to ship by its expected ship date. Tracking has to go back promptly, and cancellations and defects count against your seller performance. None of those clocks care whether someone was at a desk.

SAP Business One is where the rest of the business lives — OITM and OITW hold the stock, ORDR and RDR1 hold the demand, ODLN holds what actually shipped, OINV holds what was billed. What B1 does not have is any awareness of a marketplace. So the usual pattern is a person downloading order reports, keying Sales Orders by hand, updating quantities on the seller portal when stock moves, and pasting tracking numbers back one at a time.

That pattern fails in three predictable ways. Acknowledgement gets missed overnight and at weekends. Inventory drifts, so you oversell an item that B1 knew was gone hours earlier. And tracking goes back late, which shows up in seller metrics rather than in anyone's inbox.

What ECOSIRE builds

We build a SAP Business One connector that runs the Walmart order lifecycle on a schedule, so the SLA clocks are met by a service rather than by a person remembering.

Order ingestion and acknowledgement

The connector polls Walmart for released orders on a configurable interval and creates them as Sales Orders in B1 through the Service Layer (/b1s/v1/Orders) or the DI API. Each order line resolves to a B1 item through a SKU mapping table, and the Walmart purchase order identifier, customer order identifier and line-level identifiers are stored in UDFs on ORDR and RDR1 so the linkage survives for the life of the document. Acknowledgement is sent back as soon as the Sales Order is successfully created — that ordering matters, because acknowledging an order you failed to create is how you end up with an SLA met and no document behind it.

Buyer details are written to a Business Partner strategy agreed at scoping: either a single marketplace Business Partner with the buyer held on the document, or per-buyer Business Partners created on the fly, depending on how your AR and reporting are organised. Shipping address, requested carrier method and the expected ship date all land on the Sales Order, with the ship-by date exposed as a UDF the warehouse can sort and filter on.

Inventory and price publishing

Available quantity is calculated from OITW — on-hand less committed, restricted to the warehouses you designate as marketplace-fulfilling, with an optional buffer per item or item group — and published to Walmart on a schedule. The connector publishes deltas rather than the whole catalogue on every cycle, so a normal run is small and a full republish is an explicit action. Price updates are driven from the B1 price list you nominate, so a repricing in B1 propagates without a second manual edit on the portal.

Shipment and tracking

When a Delivery (ODLN) is added against a linked Sales Order, the connector sends the shipment back to Walmart with carrier, tracking number, ship date and the lines actually shipped. Partial shipments are handled as partials rather than being held until the order is complete. Where you invoice from B1, the A/R Invoice (OINV) is created from the delivery through the standard B1 flow, so revenue recognition follows your existing process rather than a parallel one.

Cancellations, refunds and returns

Cancellations initiated on either side are reconciled: a Walmart-side cancellation closes or reduces the B1 Sales Order, and a B1-side cancellation is pushed back with the reason. Refunds are mapped to A/R Credit Memos so the accounting is a real document rather than an adjustment nobody can trace. Returns feed a Returns document against the original delivery where you want stock brought back into OITW.

Reliability

Every call is logged to a User-Defined Table with the request, the response and the outcome, because when a marketplace disputes an acknowledgement time you need the transmission record, not a recollection. Failed calls retry with backoff, and anything that exhausts its retries lands in an exception worklist rather than disappearing into a log. Ingestion is idempotent on the Walmart purchase order identifier, so a re-run after an outage does not create duplicate Sales Orders — this is the failure mode that does the most damage in marketplace connectors, and it is designed against explicitly.

Operational surfaces

A UDO-based cockpit shows orders awaiting acknowledgement, orders past or approaching their ship-by date, shipments not yet transmitted, and the exception worklist with retry actions. Where you want approval on a cancellation or a refund above a threshold, we wire it to a B1 approval procedure so it follows your existing authorisation rules. Operational reporting — marketplace order volume, fulfilment ageing, SLA exposure — can be delivered as Crystal Reports against the B1 data.

Who this is for

Businesses running SAP Business One that sell on Walmart Marketplace and are currently bridging it manually or with an export-import routine. It suits sellers with enough order volume that acknowledgement latency is a real risk, sellers with multiple warehouses where available-to-promise is not a single number, and sellers who also need refunds and returns to land as proper B1 documents rather than manual journal adjustments.

Compatibility

Built for SAP Business One 10.0 on Microsoft SQL Server or SAP HANA, on-premise or cloud-hosted, using the Service Layer, the DI API, and UDF/UDT/UDO extensibility. Delivered per tenant against your own Walmart seller credentials; nothing is shared between customers.

How delivery works

1. Scoping call. We go through your B1 version and platform, warehouse and available-to-promise rules, SKU mapping state, Business Partner strategy for marketplace buyers, price list selection, how you invoice, and how you want returns and refunds to post. Bundles, kits and multi-warehouse fulfilment are called out explicitly because they change the shape of the build.

2. Fixed quote. Written scope and a fixed price before development begins.

3. Build. We build against your configuration and your seller account structure. Typical lead time is one working week depending on scope. This is written for you on order — there is no shelf copy to download.

4. Install in test, then production. Installed into your test company database and run against the Walmart sandbox and then a controlled set of live orders, so acknowledgement, shipment and cancellation paths are all proven before cutover. Production installation follows your sign-off.

5. Support. A support window from go-live covering defects, SKU mapping questions, and adjustment as your warehouse or fulfilment setup changes.