Microsoft Dynamics 365 F&O and SPS Commerce integration

What moves between them

Inbound, the connector polls SPS Commerce on a configurable interval for new 850 purchase orders and creates the corresponding purchase or sales order header and lines in Microsoft Dynamics 365 F&O. Outbound, when an order is acknowledged, shipped, or invoiced in Dynamics, the connector reads the relevant Dynamics records and pushes an 855 acknowledgment, 856 advance ship notice, or 810 invoice to SPS Commerce for delivery to the retailer. Inbound order intake runs on the poll schedule, typically every five to fifteen minutes; outbound documents are sent shortly after the triggering event in Dynamics. SPS Commerce remains the intermediary that delivers each document to the trading partner.

How ml-connector handles it

The connector holds two separate OAuth client credentials sets: an Entra ID client for Dynamics 365 F&O, scoped to the environment host, and an Auth0 client for SPS Commerce. Each side issues short-lived bearer tokens that the connector caches and refreshes per request as needed. For intake, it polls the SPS Transaction API, advances a last-seen cursor through SPS cursor-based paging, and unwraps each RSX 7.7.7 envelope into purchase order header and line fields before writing to Dynamics OData. SPS trading partner identifiers map to Dynamics customer accounts and SPS item identifiers map to Dynamics product numbers; this mapping is required because SPS uses partner and SKU codes, not Dynamics keys. Since Dynamics Business Events deliver only a stub, the connector can use a confirmation event as a trigger and then call OData back for the full order or invoice. Neither system offers a vendor idempotency key, so dedup relies on natural identifiers: the SPS purchaseOrderNumber on intake and the Dynamics InvoiceNumber on outbound, matched against what was already processed. Dynamics OData writes require fully specified entity keys including dataAreaId, so the connector resolves the correct legal entity per trading partner. Retries use exponential backoff with jitter, honoring the Retry-After header on Dynamics HTTP 429 responses and backing off on SPS 429s whose limits are not publicly published. Edge cases handled include the slow first OData call after an AOS restart, financial dimensions passed as a formatted display string, and the four to eight week SPS retailer certification window during which a trading partner is mapped and tested before going live.

A real-world example

A mid-sized consumer goods supplier with roughly 150 employees sells to several big-box retailers and runs Dynamics 365 F&O for order management and finance. Their team rekeys retailer EDI purchase orders into Dynamics by hand and types invoice and ship notice data back into the SPS portal, which is slow and causes chargebacks when a document is late or mistyped. With the connector in place, new 850 purchase orders pulled from SPS Commerce land in Dynamics automatically, and 810 invoices and 856 ship notices generated in Dynamics are pushed back to SPS as soon as a shipment posts. Order intake and document turnaround stop depending on manual entry, and the supplier meets retailer EDI timing requirements without adding staff.

What you can do

• •Pull retailer 850 purchase orders from SPS Commerce and create matching order records in Microsoft Dynamics 365 F&O.
• •Push 810 invoices, 856 advance ship notices, and 855 acknowledgments from Dynamics back to SPS Commerce for delivery to retailers.
• •Bridge Microsoft Entra ID OAuth on the Dynamics side and Auth0 OAuth on the SPS side without manual token handling.
• •Map SPS trading partner and item identifiers to Dynamics customer accounts and product numbers per legal entity.
• •Deduplicate inbound and outbound documents using natural keys such as purchaseOrderNumber and InvoiceNumber when no vendor idempotency key exists.

Questions

Does SPS Commerce push purchase orders to the connector, or does the connector have to poll?

The connector polls. SPS Commerce defines a webhook path pattern in its API standards, but webhook producer support is still under development and not confirmed for the Transaction API. The supported pattern is a scheduled poll of the SPS Transaction API on a configurable interval, advancing a cursor so only new documents are processed each cycle.

How are duplicate documents prevented when neither system has an idempotency key?

Both systems rely on natural identifiers rather than a vendor idempotency header. On intake, the connector deduplicates against the SPS purchaseOrderNumber; on outbound, it uses the Dynamics InvoiceNumber. The connector tracks what has already been processed and matches against these identifiers, since creating the same Dynamics record twice would raise a duplicate-key error and resending an EDI document would deliver it twice.

Why does the connector need a legal entity and item mapping rather than sending data straight through?

SPS Commerce identifies parties by trading partner ID and products by its own item identifiers, not by Dynamics keys. Dynamics 365 F&O requires fully specified OData entity keys including a dataAreaId legal entity, and writes data against customer accounts and product numbers. The connector maps each SPS trading partner to the correct Dynamics legal entity and customer, and each SPS item identifier to a Dynamics product number, so inbound orders land on valid accounts and outbound documents reference the right partner.