Oracle Fusion Cloud ERP and Tradeshift integration

What moves between them

Purchase orders and supplier invoices flow from Oracle Fusion into Tradeshift. When a procurement team creates or updates a purchase order in Oracle Fusion, ml-connector polls the Oracle REST API, detects the new or changed order, transforms it into a UBL 2.0 document, and posts it to Tradeshift at your configurable sync frequency, typically daily or on-demand. Supplier invoices received on the Tradeshift network can be polled back into Oracle Fusion for three-way matching and payment processing. Reference data such as suppliers, cost centers, and GL accounts are mapped so purchase orders land with the correct buyer organization and expense allocation in Tradeshift.

How ml-connector handles it

ml-connector stores both credential sets encrypted and manages two distinct OAuth flows. On the Oracle side, it requests bearer tokens using client credentials against the customer's OCI Identity Domain, refreshing when tokens approach expiry. On the Tradeshift side, it signs every REST request with OAuth 1.0a credentials and includes the required X-Tradeshift-TenantId header. Purchase orders are retrieved from Oracle by polling with a LastUpdateDate filter to fetch only recent changes, transformed into valid UBL 2.0 XML documents with the correct documentProfileId, and posted to Tradeshift. Supplier dimensions from Oracle are mapped to the correct supplier company profile on Tradeshift. ml-connector retries failed document posts with exponential backoff, tracks the full audit trail including transform errors and delivery confirmations, and can replay a posting if a downstream acknowledgment is delayed or lost.

A real-world example

A mid-market discrete manufacturer uses Oracle Fusion Cloud ERP for procurement and finance across three regional plants and a headquarters office, and relies on Tradeshift to manage the B2B supplier network. Before the integration, the procurement team exported purchase orders from Oracle Fusion each morning, manually formatted them into a Tradeshift-compatible file, and uploaded them to the portal. When suppliers updated their shipment plans, invoices came in through Tradeshift but had to be re-entered by hand into Oracle for three-way matching. With Oracle Fusion and Tradeshift connected, each new purchase order flows automatically to suppliers on the Tradeshift network, eliminating the manual export-reformat-upload cycle. Incoming supplier invoices are flagged for three-way match in Oracle Fusion, reducing errors and accelerating payment cycles.

What you can do

• •Post Oracle Fusion purchase orders to Tradeshift as UBL 2.0 documents, automatically formatted with supplier and cost center dimensions.
• •Retrieve supplier invoices from Tradeshift and import them into Oracle Fusion for three-way matching and payment.
• •Manage OAuth 2.0 credentials for Oracle Fusion and OAuth 1.0a signing for Tradeshift, with automatic token refresh and signature generation.
• •Poll Oracle Fusion and Tradeshift on a configurable schedule, typically daily, to detect and sync new or changed purchase orders and invoices.
• •Track every document transformation, post, and retrieval in a full audit trail, with the ability to replay failed posts without manual intervention.

Questions

Which direction do purchase orders and invoices flow between Oracle Fusion and Tradeshift?

Purchase orders flow from Oracle Fusion to Tradeshift, where suppliers on the B2B network can see and respond to orders. Supplier invoices flow from Tradeshift back into Oracle Fusion for matching and payment. Reference data such as suppliers and cost centers are aligned in both directions so orders land with the correct expense allocation.

How does ml-connector handle the different authentication methods on each side?

Oracle Fusion uses OAuth 2.0 client credentials to request bearer tokens, which ml-connector refreshes before expiry. Tradeshift uses OAuth 1.0a, which requires ml-connector to sign every REST request with the consumer key, consumer secret, token, and token secret, plus the required X-Tradeshift-TenantId header on each call.

What happens when a purchase order post to Tradeshift fails?

ml-connector retries the failed post with exponential backoff and logs the full error and audit trail. If the retry succeeds, the document is marked complete. If retries are exhausted, the post is flagged for manual review, and the record can be replayed once the underlying issue is resolved.