Marketplace Inventory Sync Hub

The problem

You sell the same items on three, five, sometimes a dozen marketplaces. Each one wants its own stock feed, on its own cadence, in its own shape. Finance and Supply Chain Management holds the truth — on-hand by item, warehouse, site and inventory dimension — but nothing in the box knows how to divide that truth across channels.

So teams improvise. Somebody exports an on-hand report to a spreadsheet each morning and pastes numbers into seller portals. Somebody else writes a one-off integration for the biggest channel, then a second one for the next channel, with different logic. A third team sets a blanket "hold back 20%" rule because nobody trusts the numbers.

The failure is always the same. Two channels sell the last unit within the same minute. The order lands in F&O, reservation fails, and now a customer service agent is apologising and a marketplace metrics dashboard is counting a late-shipment defect against your seller account. Meanwhile the safety buffer you set to avoid that outcome is quietly suppressing sales on everything that moves slowly.

The root cause is that availability is being calculated in the wrong place — in each channel connector, independently, with no shared view of what has already been promised elsewhere.

What ECOSIRE builds

We build a single availability and allocation layer inside Finance and Supply Chain Management, delivered as an X++ extension model. No overlayering — extension classes, table extensions, form extensions, event handlers and Chain of Command only, so the model deploys cleanly through your existing LCS or Azure DevOps pipeline and survives Microsoft's service updates.

The availability engine

The core is a calculation service that reads physical and financial on-hand through InventOnHandItem and InventSum, subtracts what is already committed, and applies your rules to produce a publishable number per item, per channel.

What feeds the calculation:

• On-hand by the inventory dimensions you actually trade on — site, warehouse, location, batch, colour/size/style/configuration where relevant
• Open sales order lines and reservations, so a quantity promised to a B2B order is not offered again on a consumer marketplace
• Inbound supply, with a configurable horizon — a purchase order confirmed to arrive inside your promise window can be made sellable, or not, per channel
• Quarantine, blocked batches and inventory blocking, excluded automatically
• Warehouse management work in progress, so units already picked for another shipment stop counting as available

The allocation rules

Allocation is configured, not coded. A rules table lets you express, per item group / product / channel combination: a fixed reserve quantity, a percentage buffer, a hard cap, a minimum publish threshold below which you publish zero rather than one, and a priority order for who gets the remaining units when supply is short. Rules cascade from a default to progressively more specific overrides, so you configure the exceptions rather than the whole matrix.

Channel publication

Each connected marketplace gets a channel record holding its endpoint configuration, credentials reference, publish cadence and payload mapping. Publication runs on the batch framework as a recurring batch job with configurable batch groups, so heavy channels can be isolated onto their own AOS batch server. Changes are detected by delta — the engine tracks the last published quantity per item/channel and only sends what moved, which keeps you inside marketplace API rate limits.

Inbound and outbound payloads run through data entities so the same logic is reachable from OData and the Data management framework. That means your team can bulk-load rules through DMF import projects, and any other system in your estate can read published availability without a new interface.

Reacting to change

A change tracker subscribes to inventory transaction events so a large receipt, a physical count adjustment, or a transfer order posting triggers a recalculation for the affected items rather than waiting for the next full cycle. Fast-moving items can be put on a short cadence and the long tail on a slow one.

Operations and troubleshooting

Every publication attempt is logged with the calculated quantity, the rule that produced it, the payload sent and the channel's response. A workspace gives operations staff a per-item, per-channel view: current on-hand, buffer applied, published quantity, last successful push, and any channel errors. Failed pushes retry with backoff and raise an alert rather than failing silently. Legal-entity awareness is built in — companies are configured independently, and cross-company operation is supported where your channels map to more than one legal entity.

Who this is for

Brands and distributors running Finance and Supply Chain Management as the system of record while selling through multiple marketplace and direct channels. It fits best when you have real inventory constraints — shared stock pools, seasonal supply, single-warehouse or few-warehouse operations — and where an oversell costs you more than a lost sale.

If you sell only on one channel, or hold effectively unlimited stock, you do not need this.

How delivery works

Scoping call. We walk through your channels, your inventory dimension setup, your warehouse configuration, your F&O version and update cadence, and how you want short-supply situations resolved. We look at real numbers from your environment, not a generic template.

Fixed quote. You receive a written scope with the channels in scope, the rule types being built, the entities and workspaces being delivered, and a fixed price and delivery window. Nothing starts until you approve it.

Build. We develop the model in our own environment, against your version, with unit-testable service classes and a deployable package. Typical build is one working week depending on channel count.

Install in test. We deploy the deployable package to your sandbox through your LCS or DevOps pipeline, configure the rules with your team, and run parallel against your current process so you can compare published numbers before anything goes live.

Production. Once you sign off in sandbox, the same package is promoted to production on your change window. We are on the call.

Support. A support window follows go-live for defect fixes and configuration help, with the source code handed to you so you are never locked to us.