Microsoft Dynamics GP and Stedi integration

What moves between them

Purchase orders flow from Dynamics GP to Stedi as outbound records. ml-connector polls GP for newly created or modified purchase orders, translates them to X12 850 format, and writes them to Stedi via its REST API with Idempotency-Key headers to prevent duplicates. Inbound documents flow from Stedi to GP: 810 invoices and 856 advance shipment notices arrive at Stedi via SFTP or AS2 from suppliers, Stedi parses them into JSON and pushes them via webhook, and ml-connector creates corresponding payables invoices in GP. Reference data such as vendor names and GL accounts are read from GP and used as the source of truth for mapping and validation.

How ml-connector handles it

ml-connector stores the Dynamics GP instance URL and a dedicated Windows domain account credential in encrypted storage. On poll, it uses the SBA REST endpoint with ModifiedDate filters to retrieve unposted purchase orders since the last sync, transforms each order into a Stedi-compatible X12 850 JSON payload, and POSTs it to Stedi with an Idempotency-Key that uniquely identifies each order. If Stedi returns a 429 rate limit, ml-connector backs off and retries. When Stedi pushes inbound 810 or 856 events via webhook, ml-connector receives the webhook, decrypts the API key stored for the Stedi account, validates the payload, parses the EDI data, and creates an unposted Payables Invoice record in GP. It maps the Stedi trading partner name to the correct GP vendor, looks up the GL account for AP and the cost allocation account, and populates the invoice with line items. Because GP requires the fiscal period to be open, ml-connector checks the GP calendar first and surfaces a validation error if the period is closed. X12 segment validation, Stedi rate limits, and credential expiry are all tracked in the audit log so retries can be traced.

A real-world example

A mid-sized manufacturing distributor uses Dynamics GP to manage AP and purchase orders for dozens of vendor accounts, and supplies goods to large OEM customers who mandate EDI. Before the integration, the procurement team created purchase orders in GP, exported them to CSV, manually formatted them as X12 850 EDI, and uploaded them to a Stedi account to reach suppliers. When suppliers sent back ASNs and invoices via EDI, the team parsed them by hand and re-entered the invoice details into GP, risking duplicate entries and typos. With Dynamics GP and Stedi connected, purchase orders flow directly from GP to Stedi in X12 format, and inbound 856 and 810 documents are automatically parsed and posted as payables invoices in GP without manual intervention.

What you can do

• •Poll Dynamics GP for unposted purchase orders and translate them to X12 850 EDI format for Stedi.
• •Receive inbound 810 invoices and 856 advance shipment notices from Stedi and create corresponding payables invoices in Dynamics GP.
• •Authenticate GP with Windows domain credentials and manage SBA REST endpoints at the customer's instance URL.
• •Map Stedi trading partner names to GP vendor accounts and validate GL account and fiscal period status before posting.
• •Track all EDI transmissions, inbound documents, and GL postings in a complete audit log with retry logic and error handling.

Questions

How does ml-connector handle Windows authentication for Dynamics GP?

ml-connector stores the Windows domain account credentials encrypted and uses them to authenticate every call to the GP Service Based Architecture REST or SOAP endpoint. The account must be created by the customer in their Active Directory and mapped to a GP User role. There is no OAuth or API key alternative for GP, so this Windows domain account is the only auth method available.

What happens if a fiscal period is closed in Dynamics GP when ml-connector tries to post an invoice?

ml-connector queries the GP calendar before attempting to post any transaction. If the target fiscal period is closed, it logs a validation error in the audit trail and surfaces the issue so the customer can open the period or route the invoice to a different open period. This prevents silent posting failures and keeps the AP ledger in a known state.

How does Stedi's Idempotency-Key prevent duplicate purchase orders?

When ml-connector POSTs each purchase order to Stedi, it includes an Idempotency-Key header with a value derived from the GP purchase order number and modification timestamp. Stedi deduplicates based on this key over a 24-hour window, so if the same order is transmitted twice in error, Stedi will return the original transaction ID rather than creating a duplicate. This is critical because duplicate X12 850 documents can confuse suppliers or trigger duplicate PO receipt alerts.