Oracle JD Edwards and Stedi integration

What moves between them

Purchase orders and invoices flow from JD Edwards to Stedi. ml-connector polls JD Edwards on your schedule for new or modified purchase order headers, detail lines, and open AP invoices. Those records are converted to Stedi's JSON schema, sent as writes with the required Idempotency-Key header, and Stedi translates them to X12 EDI (850 for POs, 810 for invoices) and routes the files to each supplier's SFTP or AS2 connection. Inbound 855 (PO acknowledgments) and 810 (supplier invoices) arrive from Stedi as webhooks after EDI parsing, mapped back to JD Edwards vendor and PO master data, and loaded into open AP for approval and payment.

How ml-connector handles it

ml-connector stores the JD Edwards AIS Server URL and credentials encrypted and obtains a session token on startup, caching it until the 444 (invalid token) response signals expiry, then re-authenticates automatically. Requests to JD Edwards are paginated with maxPageSize parameters and continuation tokens, and the connector tracks the last successful poll timestamp to avoid re-fetching unchanged records. On the Stedi side, ml-connector includes the required Idempotency-Key header on every write, with a unique value per PO/invoice pair, so Stedi deduplicates retries within its 24-hour window. Webhook payloads from Stedi (855 acknowledgments, 810 supplier invoices) include an eventId that ml-connector logs and uses to idempotently update JD Edwards. Vendor lookups validate that each supplier in the PO exists in JD Edwards F0101 (Address Book), and item lookups validate F4101 (Item Master) entries before sending. If a PO or invoice write returns a Stedi rate limit (HTTP 429), ml-connector backs off and retries. Every inbound webhook, PO write, and vendor validation is logged with full request/response bodies so failed transactions can be replayed when vendor data is added or corrected.

A real-world example

A mid-sized component distributor runs JD Edwards on-premises for finance and procurement, serving 60 suppliers across North America and Europe. Before the integration, the procurement team exported purchase orders from JD Edwards into Excel, manually formatted them as X12 850 files, and uploaded them to each supplier's SFTP drop box, a process taking 4 to 6 hours per order cycle. When suppliers sent back invoices (810 files), the finance team downloaded them manually, parsed key fields into a spreadsheet, and re-entered the invoice headers into JD Edwards AP, a task prone to typos and date mistakes. With JD Edwards and Stedi connected, each purchase order generated in JD Edwards automatically flows to Stedi, is translated to X12, and lands in each supplier's inbox within minutes. Incoming supplier invoices are parsed automatically from X12 and flow back as open payables in JD Edwards, ready for approval by the accounting team. The manual file shuffling is gone, invoices arrive faster and more accurately, and the procurement team can focus on procurement strategy instead of file handling.

What you can do

• •Send JD Edwards purchase orders to suppliers as X12 850 EDI files via Stedi, with automatic vendor and item validation.
• •Receive supplier invoices from Stedi as X12 810 files, parse them to JSON, and load them as open AP payables in JD Edwards, mapped to the correct vendors.
• •Route EDI files to suppliers through Stedi's SFTP, FTPS, or AS2 connections, managed centrally in Stedi without touching JD Edwards.
• •Handle JD Edwards session token rotation, Stedi Idempotency-Key deduplication, webhook event idempotency, and full audit trail logging on every transaction.
• •Poll JD Edwards on your schedule, automatically retry failed writes to Stedi with exponential backoff, and replay failed transactions when data corrections are made.

Questions

How does the integration validate vendors and items before sending a purchase order to Stedi?

ml-connector queries the JD Edwards Address Book (F0101) to confirm each vendor exists before the PO is sent to Stedi for translation. It also validates item numbers against the Item Master (F4101) to ensure the PO references real products. If a vendor or item is missing, the PO is flagged with an error, logged, and held until the missing data is added to JD Edwards.

What happens if a purchase order fails to send to Stedi or a supplier invoice fails to load back into AP?

Every transaction attempt is logged with full request and response bodies in the audit trail. If a write to Stedi fails, ml-connector backs off with exponential retries; if an inbound webhook from Stedi cannot be matched to a JD Edwards PO or vendor, it is queued and can be replayed once the vendor is added or the PO is corrected. You can inspect the audit log to see exactly what failed and why.

Does ml-connector handle the Stedi Idempotency-Key requirement and webhook retries?

Yes. Every write to Stedi includes a unique Idempotency-Key per PO or invoice, valid for 24 hours, so Stedi automatically deduplicates retries. Inbound EDI webhooks from Stedi (855 acknowledgments, 810 invoices) include an eventId that ml-connector logs and uses to idempotently update JD Edwards, so retried webhooks do not create duplicate AP records.