Microsoft Dynamics 365 Business Central and SPS Commerce integration

What moves between them

The inbound flow runs from SPS Commerce into Microsoft Dynamics 365 Business Central. ml-connector polls SPS for new 850 purchase orders and creates a matching sales order in Business Central, mapping the retailer trading partner to a customer and each line item identifier to a Business Central item. The outbound flow runs the other way: when an order ships, ml-connector reads the Business Central shipment and sales invoice and pushes an 856 advance ship notice and an 810 invoice back to SPS for delivery to the retailer. An optional 855 acknowledgment can be sent to SPS as soon as the order is accepted. Polling cadence is configurable, commonly every five to fifteen minutes for inbound orders.

How ml-connector handles it

ml-connector stores both credential sets encrypted and mints two separate tokens: an Entra ID client-credentials token for Business Central, scoped to the business central API and carrying the environment name in the base URL, and an Auth0 client-credentials token for SPS, sent as a bearer on every Transaction API call. Inbound orders are pulled on a schedule because SPS webhook support is not yet published, and the SPS cursor is stored so each poll only fetches documents seen since the last run. SPS documents arrive wrapped in the RSX 7.7.7 envelope, so each one is unwrapped before its fields are mapped into a Business Central sales order. Outbound, the connector reads the posted Business Central sales invoice and shipment and builds the 810 and 856 inside the RSX envelope SPS requires. Trading partner IDs and item identifiers are mapped up front, because SPS does not expose them for discovery and the retailer expects its own item codes. The 850 order number and the SPS invoice number act as deduplication keys, and BullMQ jobs are keyed on those ids so a repeated poll or a re-delivered document does not create a duplicate. SPS rate limits are not published, so the connector backs off with jitter on a 429, and Business Central throttling returns HTTP 429 against its per-environment limit, handled the same way. Every document carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized consumer goods manufacturer with about 150 staff sells to several big-box retailers and runs Microsoft Dynamics 365 Business Central for orders, inventory, and finance. Each retailer sends purchase orders over EDI through SPS Commerce, and before the integration a coordinator opened the SPS portal, read each 850, and typed the order into Business Central by hand, then manually built the ship notice and invoice that the retailer required back in EDI. Orders were missed at peak, ship notices were late, and chargebacks for non-compliant documents kept appearing. With Business Central and SPS Commerce connected, each 850 becomes a sales order automatically, and the 856 and 810 are generated from the posted shipment and invoice, so documents go back on time in the format the retailer expects and the manual re-keying is gone.

What you can do

• •Pull inbound 850 purchase orders from SPS Commerce and create matching sales orders in Microsoft Dynamics 365 Business Central.
• •Push 856 advance ship notices and 810 invoices from Business Central shipments and posted invoices back to SPS Commerce for delivery to the retailer.
• •Map retailer trading partner IDs and EDI item identifiers to Business Central customers and item numbers.
• •Bridge the Entra ID client-credentials token on Business Central and the Auth0 client-credentials token on SPS Commerce.
• •Poll SPS on a schedule with cursor tracking, deduplication on order and invoice numbers, retries, and a full audit trail on every document.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and SPS Commerce?

It moves both ways. Inbound, 850 purchase orders are pulled from SPS Commerce and created as sales orders in Business Central. Outbound, 856 advance ship notices and 810 invoices are built from Business Central shipments and posted invoices and pushed back to SPS Commerce, which delivers them to the retailer. SPS is a pass-through network, so the original order lives in the retailer's system and SPS only carries it.

Does the integration use webhooks or polling for inbound orders?

It uses polling. SPS Commerce defines a webhook framework in its API standards, but producer support is still under development and there is no published event catalog, so the reliable pattern is to poll the Transaction API for new documents. ml-connector stores the SPS cursor and only fetches documents seen since the last run, on a cadence you set, commonly every five to fifteen minutes.

How are EDI item codes and trading partners matched to Business Central records?

They are mapped during setup. SPS uses trading partner IDs for retailers and the retailer's own item identifiers on each line, and these are not discoverable through the API, so the connector holds a mapping from each trading partner to a Business Central customer and from each EDI item identifier to a Business Central item number. That mapping is applied on every inbound order and outbound document, so orders land on the right customer and invoices reference item codes the retailer recognizes.