Oracle Fusion Cloud ERP and Stedi integration

What moves between them

The main flow runs from Oracle Fusion Cloud ERP into Stedi. ml-connector polls Oracle Fusion Cloud ERP at intervals aligned with your procurement cycle, reading newly created or modified purchase orders and supplier invoices. These are mapped to the corresponding Stedi transaction types, primarily 850 Purchase Order and 810 Invoice, then submitted to Stedi with an Idempotency-Key for deduplication. Stedi translates them to X12 EDI format and routes them to your configured partners via SFTP, FTPS, or AS2. Inbound EDI from partners, such as 855 Purchase Order Acknowledgments and 865 Change Acknowledgments, are parsed by Stedi into JSON and pushed via webhook to ml-connector, which then writes them into Oracle Fusion Cloud ERP as transaction records linked to the original purchase order.

How ml-connector handles it

ml-connector stores the Oracle Fusion Cloud ERP OAuth2 client credentials and refreshes the Bearer token on each poll when the previous one expires (approximately 1 hour). It polls the Oracle Fusion Cloud ERP REST API every 5 to 15 minutes, filtering by LastUpdateDate to fetch only new and changed purchase orders and invoices. For each record, ml-connector maps Oracle Fusion Cloud ERP field values to Stedi's expected 850 and 810 X12 segment structure, then submits them to Stedi's REST API with a unique Idempotency-Key and your configured partnership and transaction settings. On the inbound side, Stedi webhooks deliver parsed EDI documents as JSON to ml-connector, which transforms them into journal entries or transaction records in Oracle Fusion Cloud ERP, linked to the original purchase order by PO number. Because Oracle Fusion Cloud ERP polling is time-driven rather than event-driven, ml-connector deduplicates by checking the LastUpdateDate timestamp and skipping records already processed. Stedi's outbound API enforces Idempotency-Key for 24 hours, so ml-connector stores the key per document to prevent duplicate submissions if a request times out. EDI translation errors from Stedi are captured and attached to the transaction record in Oracle Fusion Cloud ERP so your procurement team can correct the source data and resubmit.

A real-world example

A specialty chemical distributor uses Oracle Fusion Cloud ERP for procurement and accounting. They ship to 40 industrial customers who require X12 EDI purchase orders and invoice transmissions via their preferred methods: 15 partners via SFTP, 12 via AS2, and 13 via web portal. Before the integration, the procurement team printed purchase orders from Oracle Fusion Cloud ERP and manually submitted each one to Stedi's web UI, then downloaded 810 invoices and imported them back into Oracle Fusion Cloud ERP for reconciliation, taking 2 to 3 hours per trading partner per week. With Oracle Fusion Cloud ERP and Stedi connected, purchase orders flow automatically into Stedi on creation, are translated to X12, and route to each partner via their configured transport. Inbound acknowledgments and invoices return through Stedi, are parsed into transaction records, and attach to the original purchase orders with full audit trails. Manual submission time drops to near zero, and discrepancies are caught immediately.

What you can do

• •Poll Oracle Fusion Cloud ERP on your procurement cycle and automatically submit purchase orders and supplier invoices to Stedi for EDI translation.
• •Translate Oracle Fusion Cloud ERP procurement documents into X12 EDI format and route them to trading partners via SFTP, FTPS, or AS2.
• •Map Oracle Fusion Cloud ERP supplier master data to Stedi partnership and transaction settings so documents route to the correct partner.
• •Receive inbound EDI acknowledgments and invoices from Stedi, parse them as JSON, and write them back into Oracle Fusion Cloud ERP as transaction records linked to the original purchase order.
• •Maintain full audit trails and error handling so procurement teams can spot translation failures and correct source data without re-submitting through the UI.

Questions

Which direction does data move between Oracle Fusion Cloud ERP and Stedi?

The main flow is Oracle Fusion Cloud ERP into Stedi. Purchase orders and invoices are polled from Oracle Fusion Cloud ERP, translated to X12 EDI, and routed by Stedi to your trading partners. Inbound acknowledgments and responses are parsed by Stedi and pushed back into Oracle Fusion Cloud ERP as transaction records. The data flow is primarily one-way out and one-way back in, not bidirectional updates to the same records.

How does ml-connector handle Oracle Fusion Cloud ERP's lack of webhooks?

Oracle Fusion Cloud ERP has no direct outbound webhooks for standalone connectors, so ml-connector polls the REST API at regular intervals (every 5 to 15 minutes) using LastUpdateDate filtering to fetch only new and changed records. This pattern avoids the need for Oracle Integration Cloud middleware while keeping procurement data synchronized with acceptable latency for most workflows.

What happens if a Stedi EDI translation fails or a partner rejects the X12 document?

ml-connector captures translation errors and rejection codes from Stedi and attaches them to the transaction record in Oracle Fusion Cloud ERP so your procurement team can review the issue immediately. The original purchase order or invoice is marked with the error status, allowing the team to correct the source data and resubmit without re-entering the document through the UI.