Multichannel Inventory and Listing Sync Hub

Selling the same unit twice

A seller listing on four channels with one warehouse has a arithmetic problem no spreadsheet solves. Each channel believes it owns the stock it can see. Publish the true on-hand figure everywhere and you will sell the last unit four times; publish a quarter of it everywhere and you sit on stock you could have sold. Meanwhile prices drift because a promotion went up on one channel and never came down on another, and listings go stale because nobody wants to re-enter the same product data for the fifth time.

The usual patch is a person with a spreadsheet doing a morning stock update and an evening order download. It works until volume rises, then it produces the two failure modes that actually cost money: oversells that turn into cancellations and channel metric penalties, and phantom out-of-stocks where inventory exists but no channel is allowed to sell it.

SAP Business One holds the truth — real on-hand quantity per Warehouse, committed quantity against open Sales Orders, ordered quantity on open Purchase Orders, and the correct price for each item. What is missing is the layer that turns that truth into per-channel availability and keeps every channel in step with it.

What ECOSIRE builds

ECOSIRE builds a synchronisation hub that sits beside SAP Business One and makes SAP the single source of truth for stock, price and product data across every channel you sell on.

Availability and allocation

The hub computes available-to-promise from SAP itself — on-hand per Warehouse, less committed quantity on open Sales Orders and Deliveries, plus incoming quantity on open Purchase Orders where you choose to sell forward. That single availability figure is then allocated to channels by the rules you define: fixed buffers held back for trade customers, percentage splits, priority ordering so a high-margin channel is served first, and per-channel caps on fast-moving lines. When stock moves for any reason — a Goods Receipt PO, an Inventory Transfer, a counter sale, a Delivery — the allocation recalculates and pushes to every affected channel.

Listing and price synchronisation

Product data is maintained once, on the SAP Item Master and its User-Defined Fields, and published outward: titles, descriptions, attributes, images, barcodes, categories and channel-specific overrides where a marketplace demands its own taxonomy. Prices come from SAP price lists with per-channel uplift or discount rules, so a promotion is a change in SAP rather than four manual edits. A User-Defined Object holds the channel-mapping configuration — which items publish where, under which channel SKU, in which category and at which price basis — so administration happens inside the SAP client.

Order ingestion

Orders pull back from every channel and post as Sales Orders (ORDR) against the Business Partner you have designated for that channel, with the channel order reference, buyer details, shipping method and channel fees carried into header and row User-Defined Fields. Item mapping resolves channel SKUs to your SAP Item Codes so nothing posts against a guessed item. Where you invoice per order, the flow continues to Delivery and A/R Invoice; where you settle by channel remittance, orders can be grouped for periodic invoicing. Cancellations and refunds map to the corresponding SAP documents rather than being handled off-system.

Reliability where it matters

Every channel call is queued, retried with backoff, and idempotent, so a marketplace outage delays a push instead of losing it or duplicating an order. Each order carries an idempotency key so a channel that redelivers a webhook cannot create two Sales Orders. A reconciliation job compares what each channel believes it has against what the hub last published and repairs drift rather than waiting for a human to notice. Every push and pull is logged with a correlation id so any single item's history is answerable.

Operational visibility

A control view inside SAP, backed by a User-Defined Object, shows per-channel publish status, last successful sync, items in error with the channel's own rejection message, and unmapped SKUs. Crystal Reports layouts cover channel sales by item and margin after channel fees where that is in scope.

Integration approach

The hub reads and writes SAP through the Service Layer (OData/REST), falling back to the DI API for operations only exposed there, and runs as its own service so channel latency never touches the SAP client. Channel credentials are stored encrypted outside the company database, and per-channel rate limits are respected by design rather than discovered in production.

Who it is for

SAP Business One users selling the same inventory across two or more marketplaces or webstores from shared stock. It is most valuable where SKU counts and order volume have outgrown manual updates, where oversells are already causing cancellations or channel penalties, and where the same product data is being maintained in several places.

It is not the right tool for a single-channel seller — one channel does not need allocation — and it will not rescue an item master whose data is wrong, because it publishes what SAP holds.

How delivery works

The hub is built to order. Nothing is downloadable and there is no trial instance, because the build is specific to your channels, your allocation policy and your document flow.

1. Scoping call. We establish which channels and which of their APIs, how many SKUs and channel listings, how stock should be allocated between channels, whether you sell forward against open Purchase Orders, how orders should become SAP documents, and how returns, cancellations and channel fees are handled today.

2. Fixed quote. You receive a written scope naming each channel integration, the allocation rules, the order-to-document flow, the UDF/UDT/UDO inventory, the reports, and a fixed price and timeline. Nothing is built before you approve it.

3. Build. Typical lead time is three to four weeks and rises with the number of channels, since each marketplace API is separate work. We build against a copy of your company database structure so item codes, warehouses, price lists and series match yours.

4. Install in test. We install against your test company and connect channel sandbox accounts where the channel provides them, or run in publish-disabled mode against live credentials where it does not. We replay your real SKU set and order shapes, prove the allocation maths against your expectations, and you sign off before production.

5. Install in production. Production install is scheduled with your Basis or hosting contact. We start with a read-only reconciliation pass so you can see what would change before anything publishes, then enable channels one at a time rather than all at once.

6. Support. A support window from go-live covers defects, channel API changes and allocation-rule adjustments once real trading exposes the edges. Ongoing support is available separately.

Honest limits

We are not a marketplace and hold no partnership with any channel — you bring your own seller accounts and API credentials. What can be synchronised is bounded by what each channel's API actually exposes; some marketplaces restrict listing creation, category assignment or price frequency, and we will tell you those limits during scoping instead of after the invoice. Channel APIs change, and changes inside your support window are ours to fix.