Sage 300 and Stedi integration

What moves between them

Purchase orders and invoices flow from Sage 300 into Stedi. ml-connector polls Sage 300 on a schedule you define, retrieves POPurchaseOrders and APInvoiceBatches along with their line items and GL allocations, translates them to Stedi's JSON schema, and posts them to Stedi as 850 Purchase Orders or 810 Invoices for EDI translation. Stedi handles the conversion to X12 and routing to your trading partners via SFTP, AS2, or other configured connections. Inbound acknowledgments (855 PO Acknowledgments, 997 Functional Acknowledgments) come back from Stedi as webhook events and can optionally be stored in Sage 300 for audit. The flow is primarily outbound.

How ml-connector handles it

ml-connector stores your Sage 300 credentials encrypted and constructs the Authorization header with base64-encoded USERNAME:PASSWORD in uppercase on every request. It polls Sage 300 using OData $filter parameters to fetch only new or modified purchase orders and invoices since the last sync, ordered by DocumentDate. For each record, it reads the full line details and GL segment allocations, maps Sage 300 vendor codes and GL accounts to Stedi trading partner identifiers and segment numbers, and builds the JSON payload for Stedi. On the Stedi side, ml-connector includes the Idempotency-Key header to prevent duplicate submissions if a send is retried. Because Sage 300 is self-hosted and IIS-based, ml-connector respects IIS AppPool timeouts by chunking large batches and backing off on 503 responses. Every transaction is logged with the source record ID, Stedi file ID, and delivery status so failed sends can be replayed. Webhook events from Stedi are logged for audit but are not written back to Sage 300 unless you configure a separate return flow.

A real-world example

A mid-market distributor uses Sage 300 for procurement and GL. They send purchase orders to suppliers via EDI but currently export from Sage 300 to CSV, manually map vendor codes to trading partner IDs, and use a third tool to translate and submit EDI. With Sage 300 and Stedi connected, new purchase orders are automatically detected by ml-connector, translated to 850s, and delivered to each supplier's SFTP inbox without manual intervention. Invoices are verified in Sage 300 before ml-connector sends them as 810s. The procurement team spends less time on translation and re-keying, and suppliers receive orders and invoices faster and more reliably.

What you can do

• •Poll Sage 300 for new purchase orders and invoices on a schedule, fetch line items and GL allocations, and send them to Stedi as 850 or 810 EDI documents.
• •Handle Sage 300 HTTP Basic Authentication with uppercase credentials and the customer-specific IIS host URL.
• •Apply the Stedi Idempotency-Key requirement for every outbound write to prevent duplicate submissions across retries.
• •Map Sage 300 vendor codes, GL accounts, and cost centers to Stedi trading partner identifiers and segment numbers.
• •Log every transaction with source record ID, Stedi file ID, and delivery status for audit and replay of failed sends.

Questions

How does ml-connector handle Sage 300's HTTP Basic Authentication requirement?

ml-connector stores your Sage 300 username and password encrypted and constructs the Authorization header with base64-encoded USERNAME:PASSWORD on every request. Usernames and passwords must be uppercase to match Sage 300's requirement. The API user must be created in Sage 300 Administrative Services with the Web API security group assigned.

What records move from Sage 300 to Stedi?

Purchase orders (POPurchaseOrders) and invoices (APInvoiceBatches and ARInvoiceBatches) move from Sage 300 to Stedi for EDI translation and delivery to your suppliers. Line items and GL segment allocations are fetched with each order or invoice so the EDI includes full detail. Acknowledgments and functional acknowledgments come back from trading partners as Stedi webhook events but are not written back to Sage 300 unless you configure a return flow.

Does the integration handle Stedi's Idempotency-Key requirement?

Yes. ml-connector includes the Idempotency-Key header on every outbound write to Stedi, derived from the source record ID and timestamp. This ensures that if a send is retried due to a network timeout or temporary error, Stedi deduplicates the request and does not create a duplicate EDI submission to your trading partners.