Microsoft Dynamics GP and Orderful integration

What moves between them

The primary flow is Microsoft Dynamics GP to Orderful. Purchase orders and payables invoices created in GP flow to Orderful, where they are translated into EDI X12 850 or 810 documents and routed to suppliers and customers. Inbound EDI 855 purchase order acknowledgments, 860 order changes, and 856 ship notices are polled from Orderful, translated back into GP format, and posted as purchase order changes and goods receipts in GP. Inventory items and GL accounts are synced in both directions to ensure mapping consistency. The cadence is customer-defined, typically every 15 to 30 minutes.

How ml-connector handles it

ml-connector bridges Windows Active Directory authentication on the Microsoft Dynamics GP side (presenting a dedicated domain account) with Orderful's static API key authentication. It polls Microsoft Dynamics GP purchase orders and invoices using SBA REST calls with ModifiedDate filters and posts them to Orderful in /v4 create endpoints, translating GP fields to EDI Mosaic schema (sender and receiver ISA IDs, document type, line items, addresses). It monitors the Orderful polling-bucket endpoint for inbound 855, 860, and 856 documents and posts them back into GP as purchase order change headers and goods receipt transactions, respecting GP's constraint that financial records must be unposted (Work status) to be written. If a GP fiscal period is closed or the company database is unavailable, ml-connector queues the transaction for retry with exponential backoff. Orderful's stream field is set to test during development and switched to live at cutover. Every sync is logged with a full audit trail and can be replayed if a downstream write to GP or Orderful fails.

A real-world example

A mid-sized distributor runs Microsoft Dynamics GP on-premises for purchasing, payables, and inventory across three warehouses. They supply two major automotive OEMs that require all purchase orders and ship notices in EDI X12 format, and a smaller regional retailer that uses SFTP. Before the integration, the procurement team manually keyed each purchase order into Orderful after creating it in GP, matched incoming 855 acknowledgments by hand, and rekeyed 856 ship notices into GP goods receipts. With Microsoft Dynamics GP and Orderful connected, POs in GP automatically translate to X12 850s and flow to all three partners via their preferred channels. Inbound acknowledgments and ship notices flow back to GP automatically, update PO status and receipt postings, and eliminate the manual entry step. The procurement team can now focus on supplier relationships instead of data entry.

What you can do

• •Translate Microsoft Dynamics GP purchase orders and invoices into EDI X12 and EDIFACT documents and route them to suppliers via Orderful's AS2, SFTP, VAN, and HTTP channels.
• •Ingest EDI 855 purchase order acknowledgments and 856 ship notices from Orderful and post them back into Microsoft Dynamics GP as purchase order changes and goods receipts.
• •Authenticate Microsoft Dynamics GP via Windows Active Directory and Orderful via static API key, managing both credential sets encrypted in the integration platform.
• •Poll Microsoft Dynamics GP and Orderful on a schedule you define, with retry and exponential backoff if GP fiscal periods are closed or databases are unavailable.
• •Maintain a full audit trail on every EDI document and provide replay capability if a translation or posting step fails.

Questions

Does the integration handle EDI translation from Microsoft Dynamics GP fields to X12 and EDIFACT?

Yes. ml-connector maps GP purchase orders and invoice fields to the Orderful Mosaic schema, including sender and receiver ISA identifiers, document type (850 for POs, 810 for invoices), line items, quantities, prices, and shipping addresses. You configure the ISA ID mapping once per customer.

What happens to inbound EDI 855 and 856 documents from Orderful?

ml-connector polls Orderful for incoming 855 purchase order acknowledgments and 856 ship notices, translates them back into GP line-item format, and posts them as purchase order changes and goods receipts in Microsoft Dynamics GP. The Receiving module is updated to reflect partner-confirmed quantities and ship dates.

How does ml-connector handle the requirement that Microsoft Dynamics GP is on-premises and requires Windows authentication?

The customer exposes the Microsoft Dynamics GP SBA or SOAP endpoint through the firewall with a valid SSL certificate or via a local agent. ml-connector authenticates using a dedicated Windows domain account created by the customer, and presents that account to every SBA call using Negotiate/Kerberos or NTLM depending on the customer's network configuration.