Which Business Central versions are supported?

Dynamics 365 Business Central cloud is the common case. On-premises and hosted deployments are supported where a connection path and service account can be agreed — that is confirmed during scoping rather than assumed.

No. DSCO remains the retailer-facing network. APIWORX moves the data between DSCO and Business Central and takes responsibility for the agreed workflows.

Which DSCO interface do you use?

It depends on the retailer programme and how your DSCO account is configured. We confirm the applicable interface with you and, where needed, with the network before build.

Can you handle more than one retailer?

Yes. Each retailer programme gets its own mapping, feed rules and exception handling, which is the main reason teams outgrow manual portal work.

Who fixes it when the retailer rejects a document?

APIWORX works the exception queue and corrects mapping or formatting problems. Decisions that are commercial — accepting a late cancellation, for example — come to your named contact.

How is scope and pricing determined?

From the document set, the number of retailer programmes, the mapping complexity and the ongoing support you want. We publish no price on this page; scope is agreed first.

Dropship · Retailer compliance

Microsoft Business Central

DSCO (Rithum)

Connect Microsoft Business Central + DSCO (Rithum)

Automate retailer dropship order, customer / bill-to record, item mapping (retailer sku ↔ bc item), availability / inventory feed, shipment confirmation + tracking between Microsoft Business Central and DSCO (Rithum) — with monitoring and managed support from APIWORX.

See How It Works

APIWORX connects the systems your business already uses and takes responsibility for the agreed integration workflows after go-live. The exact objects, direction and cadence are fixed in writing during scoping.

ERP + eCommerce Specialists

Managed & Monitored Integrations

Expert Integration Team

APIWORX Provides the Service

Yes. APIWORX connects Microsoft Business Central and DSCO (Rithum).

But connecting the applications is only the beginning. The work that costs you time sits in the process running between them.

APIWORX automates that process end to end — the objects moving between Microsoft Business Central and DSCO (Rithum), the ownership rules that decide which system wins, the exceptions when a record will not post, and the monitoring that tells someone before your team finds out from a customer.

Order-to-cash automation EDI & B2B commerce Inventory synchronization

How it works

From requirements to a managed integration

Tell Us What You’re Connecting

Provide the systems, workflow and business requirements.

We Design the Integration

APIWORX recommends the integration architecture, mappings and implementation approach.

We Build, Monitor & Support It

APIWORX implements the integration and provides ongoing monitoring and support as applicable.

Who this is for

This page is for operations and supply-chain teams running a dropship programme for one or more retailers on DSCO while Business Central remains the ERP of record.

What needs to be in place

Dynamics 365 Business Central (cloud, or on-premises with a supported connection path agreed in scoping).
An active DSCO supplier account, with retailer relationships already onboarded by the retailer.
Business Central permissions for the API/service account that will create sales documents and read item availability.
A warehouse or 3PL that can act on released orders and return shipment detail.

When you may not need this

If you have a single retailer, low order volume and no unusual item or pricing rules, a lighter tool or manual portal work may be enough. A managed integration earns its place when you have several retailer programmes, item and price mappings that change, or an ops team spending real hours on exceptions.

What is out of scope

APIWORX does not onboard you to a retailer or negotiate your supplier agreement.
Retailer-specific packaging, labelling and routing-guide compliance remains your operational responsibility; we move the data those processes depend on.
Which DSCO interface applies to your account is confirmed with you in scoping — it varies by retailer programme.

What actually moves, and who owns it

The table below is the shape of a typical Business Central dropship flow. Your final scope is agreed document by document before build.

Microsoft Business CentralAPIWORX (mapping, retries, exception queue)DSCO (Rithum)

Objects exchanged between Microsoft Business Central and DSCO (Rithum), with system of record, trigger, failure handling and owner
Object	From	To	System of record	Trigger	If it fails	Owner
Retailer dropship order	DSCO	Business Central	Retailer (via DSCO)	New order polled on an agreed cadence	Order held in exception queue with the mapping error; retried after correction	APIWORX
Customer / bill-to record	Business Central	Business Central	Business Central	Matched on retailer account at order creation	Order held rather than creating a duplicate customer	APIWORX (mapping) / you (master data)
Item mapping (retailer SKU ↔ BC item)	Agreed mapping table	Business Central	Business Central	Applied per order line	Unmapped SKU raises an exception naming the SKU	APIWORX (maintenance) / you (approval)
Availability / inventory feed	Business Central	DSCO	Business Central	Scheduled publish on an agreed cadence	Last good feed remains in force; failure alerted	APIWORX
Shipment confirmation + tracking	Business Central / WMS	DSCO	Business Central	Shipment posted	Retried, then queued for review if the retailer rejects it	APIWORX
Cancellations and order changes	DSCO	Business Central	Retailer (via DSCO)	Change received before shipment	Flagged to your ops contact when the order has already shipped	APIWORX (delivery) / you (decision)
Invoice	Business Central	DSCO	Business Central	Posted sales invoice	Rejected invoices queued with the retailer's reason code	APIWORX

Three decisions that make or break this integration

Retailer order import and mapping

The hard part of dropship is not the transport, it is agreeing what a retailer order becomes inside Business Central. Each retailer programme carries its own SKU numbering, ship-to structure and cost expectation, so the mapping is decided once and then enforced on every order.

Retailer SKU to Business Central item number, including pack and case variants.
One bill-to customer per retailer programme, with the consumer address carried as the ship-to.
Order-level references (retailer PO number, DSCO order ID) written to Business Central fields you nominate, so support can find any order from either side.
Unmapped items stop that order instead of guessing an item — nothing posts on a guess.

Inventory ownership and availability buffers

Dropship oversell is an inventory-ownership problem. Business Central holds the quantity you actually have; DSCO only knows what you last published. We agree in scoping which locations count towards a retailer feed, and what buffer protects your other channels.

Location filters so only sellable warehouses feed the retailer.
Per-retailer or per-item buffer quantities, applied at publish time rather than edited by hand.
Publish cadence chosen against your order pattern; the last successful feed stays in force if a publish fails.
Feed failures alert the APIWORX team — a stale feed is treated as an incident, not as normal.

Shipment confirmations and exception handling

Retailers judge dropship suppliers on shipment confirmation quality and timeliness. Confirmations are built from the posted Business Central shipment (or your WMS feed) rather than typed into a portal, and rejections are worked rather than left to expire.

Tracking number, carrier and shipped quantity taken from the shipment record.
Partial shipments handled explicitly — the retailer sees what shipped, and the balance stays visible.
Rejected confirmations land in an exception queue with the retailer's reason code attached.
Cancellations arriving after despatch are escalated to your ops contact, because that is a business decision, not a data fix.

Reliability and ownership

Dropship programmes fail quietly — a feed stops, nobody notices, chargebacks follow. These are the arrangements that prevent that.

Every run is logged with the source record reference so a document can be traced end to end.
Failed messages are retried on a defined schedule; anything that still fails lands in an exception queue rather than being dropped silently.
Duplicate prevention keys on the source system's own identifier (order number, PO number, document ID) so a replayed message does not create a second record.
Exceptions are worked by the APIWORX team and escalated to your named contacts when a business decision is needed.
Mapping changes — new SKUs, new accounts, new dimensions, new trading-partner requirements — are handled as part of the ongoing engagement.
Response commitments and support windows are set in your agreement; this page does not state an SLA.

Illustrative field mapping

Illustrative example — not a customer result

The mapping below shows the shape of a dropship order mapping. It is an anonymised illustration used to structure scoping conversations, not a production customer configuration.

Illustrative field mapping
DSCO order ID	Sales order → External Document No.
Retailer PO number	Sales order → Your Reference
Retailer SKU	Sales line → Item No. (via mapping table)
Consumer ship-to name / address	Sales order → Ship-to fields
Requested ship date	Sales order → Requested Delivery Date
Unit cost agreed with retailer	Sales line → Unit Price
Carrier + tracking on despatch	Shipment → Package Tracking No.

Scope and questions

Which Business Central versions are supported?: Dynamics 365 Business Central cloud is the common case. On-premises and hosted deployments are supported where a connection path and service account can be agreed — that is confirmed during scoping rather than assumed.
Do you replace DSCO?: No. DSCO remains the retailer-facing network. APIWORX moves the data between DSCO and Business Central and takes responsibility for the agreed workflows.
Which DSCO interface do you use?: It depends on the retailer programme and how your DSCO account is configured. We confirm the applicable interface with you and, where needed, with the network before build.
Can you handle more than one retailer?: Yes. Each retailer programme gets its own mapping, feed rules and exception handling, which is the main reason teams outgrow manual portal work.
Who fixes it when the retailer rejects a document?: APIWORX works the exception queue and corrects mapping or formatting problems. Decisions that are commercial — accepting a late cancellation, for example — come to your named contact.
How is scope and pricing determined?: From the document set, the number of retailer programmes, the mapping complexity and the ongoing support you want. We publish no price on this page; scope is agreed first.