Microsoft Dynamics GP and SPS Commerce integration

What moves between them

Purchase orders and invoices flow outbound from Dynamics GP to SPS Commerce. ml-connector polls Dynamics GP for new or modified purchase orders and invoices using ModifiedDate filters at a cadence you define, typically 15 to 30 minutes. Each document is wrapped in the RSX 7.7.7 JSON envelope format required by SPS, then posted to SPS Commerce, which translates the JSON into EDI X12 or EDIFACT and routes the document to the correct retail trading partner based on the vendor ID and trading partner mapping. Inbound documents from SPS (PO acknowledgments, ASNs) can also be pulled and recorded in Dynamics GP for fulfillment visibility.

How ml-connector handles it

ml-connector stores Dynamics GP credentials (the Windows domain account username and password) encrypted and uses them to authenticate every SBA or SOAP request with Negotiate/Kerberos or NTLM over HTTPS. On the SPS side it stores the OAuth2 client credentials encrypted, exchanges them for a bearer token, and includes the token on all API calls; when a call returns 401, it refreshes the token and retries. Because Dynamics GP is on-premises, the polling agent must access the customer's SBA or SOAP endpoint via the firewall; if the endpoint is not exposed, ml-connector can work with the customer's local agent or integration service. Purchase orders and invoices are read as unposted (Work) transactions in Dynamics GP, then wrapped in the RSX 7.7.7 envelope and posted to SPS using idempotent document-level identifiers (purchase order number, invoice number) to prevent duplicates. Cost center, vendor, and warehouse codes in Dynamics GP are mapped to the correct trading partner IDs in SPS so the EDI translation reaches the right retailer. SPS rate limits are not publicly documented, so ml-connector implements exponential backoff plus jitter on 429 responses. Every document carries a full audit trail and can be replayed if a downstream transmission fails.

A real-world example

A mid-sized distribution company runs Microsoft Dynamics GP to manage suppliers, purchase orders, and receivables. They ship products to multiple retail partners including Walmart, Target, and Amazon, which all require EDI submission of orders and shipment notices via their compliance networks. Before the integration, the supply chain team manually exported purchase orders and invoices from Dynamics GP, formatted them as EDI X12 files, and submitted them to SPS Commerce via SFTP or AS2 several times per day, then tracked acknowledgments and ASNs by checking an SFTP folder. Order errors and manual re-submission during peak seasons added 8-10 hours of weekly rework. With Dynamics GP and SPS Commerce integrated, new purchase orders and invoices post automatically to SPS in the correct EDI format on a 15-minute cycle. Incoming ASNs and acknowledgments are pulled back into Dynamics GP to update fulfillment status. The manual file submission step is eliminated, and the supply chain team has real-time visibility into retailer responses without log file parsing.

What you can do

• •Poll Microsoft Dynamics GP for new and modified purchase orders and invoices at a cadence you define, using ModifiedDate filters to avoid re-processing.
• •Transform Dynamics GP purchase orders and invoices into RSX 7.7.7 JSON envelopes and post them to SPS Commerce for EDI translation and retail partner routing.
• •Authenticate Dynamics GP with Windows domain credentials (Negotiate/Kerberos or NTLM) and SPS Commerce with OAuth2 bearer tokens, managing credential storage and token refresh.
• •Map Dynamics GP vendors, cost centers, and warehouse codes to SPS Commerce trading partner IDs so purchase orders and invoices route to the correct retailers.
• •Receive inbound EDI documents from SPS Commerce such as purchase order acknowledgments and advance ship notices and record them in Dynamics GP for fulfillment tracking.

Questions

Which direction does data flow between Dynamics GP and SPS Commerce?

Purchase orders and invoices flow outbound from Dynamics GP to SPS Commerce, where they are translated into EDI X12 or EDIFACT and routed to retail trading partners. Inbound documents from SPS such as purchase order acknowledgments (855) and advance ship notices (856) can also be pulled back into Dynamics GP for fulfillment visibility. The primary flow is outbound; inbound is optional based on retailer requirements.

Does Dynamics GP's on-premises requirement complicate the integration?

Yes. Because Dynamics GP is on-premises and runs on Windows Server, the SBA or SOAP endpoint must be exposed through the customer's firewall with a valid SSL certificate, or accessed through a local integration agent. ml-connector will work with the customer's network team to confirm the endpoint is reachable. If the endpoint cannot be exposed directly, the customer can install a local agent that forwards requests.

How does ml-connector handle the difference between Dynamics GP's Windows Authentication and SPS Commerce's OAuth2?

ml-connector stores both credential sets encrypted: the Windows domain account credentials for Dynamics GP and the OAuth2 client credentials for SPS Commerce. On each Dynamics GP request, it uses Negotiate/Kerberos or NTLM with the domain account. On each SPS request, it exchanges the OAuth2 credentials for a bearer token and includes it on the call; when the token expires, ml-connector refreshes it automatically before the next request.