Oracle Fusion Cloud ERP and SPS Commerce integration

What moves between them

Inbound purchase orders from SPS Commerce trading partners are polled from the /fulfillment/v1/purchaseorders endpoint and mapped into Oracle Fusion's procurement purchase order transactions, including line items, quantities, and delivery locations. Outbound invoices and advance ship notices flow from Oracle Fusion into SPS Commerce, translated into RSX 7.7.7 envelope format and routed to the correct trading partner identifiers provisioned during onboarding. Goods receipts and warehouse acknowledgments from SPS Commerce feed back into Oracle Fusion's receiving module to close purchase orders and trigger three-way matching. The entire flow runs on a schedule tied to your procurement and fulfillment rhythm, typically every 5 to 15 minutes.

How ml-connector handles it

ml-connector manages two independent OAuth 2.0 credential stores, one for Oracle Fusion's OCI Identity Domain and one for SPS Commerce's token endpoint, refreshing bearer tokens when any call returns 401. On the Oracle Fusion side it accepts the full customer-specific pod URL since the tenant URL is unique per customer, and filters query results by LastUpdateDate to retrieve only changed records since the last run. On the SPS Commerce side it uses cursor-based pagination as required by the API, stores the opaque Base64-encoded cursor from each response, and wraps outbound invoices and acknowledgments in the RSX 7.7.7 JSON envelope with the provisioned trading partner identifiers. Since neither system offers direct application-level idempotency keys, ml-connector implements document-level deduplication at the application layer using purchase order numbers, invoice numbers, and receipt identifiers to avoid duplicate posts if a retry occurs. Rate limit handling uses exponential backoff with jitter on SPS Commerce 429 responses. Every record carries a full audit trail mapping the source trading partner order to the Oracle Fusion purchase order, supplier, and GL account, enabling fast root-cause investigation if a document fails to match or post.

A real-world example

A mid-sized consumer goods supplier manufactures products for major retail chains and uses Oracle Fusion Cloud ERP for procurement, supplier management, and finance. The company receives purchase orders from retailers through SPS Commerce and previously downloaded EDI documents from SPS, manually keyed the order details into Oracle Fusion's purchasing module, printed invoices, and uploaded them back to SPS via SFTP for transmission to the retailers. The process was labor-intensive and error-prone, with mismatched quantities, wrong delivery locations, and invoice GL coding errors caught only during audits. With Oracle Fusion and SPS Commerce connected, inbound purchase orders flow directly into Oracle Fusion as procurement transactions, advance ship notices are automatically created and sent back to SPS Commerce when goods are packed, and invoices post with the correct supplier and GL account coding the moment the shipment is recorded. The manual keying step is eliminated, procurement and trading partner data stay in sync, and the finance team regains days of month-end close time.

What you can do

• •Ingest purchase orders from SPS Commerce trading partners and create procurement transactions in Oracle Fusion with correct line items, quantities, and delivery locations.
• •Post invoices and advance ship notices from Oracle Fusion to SPS Commerce trading partners in RSX 7.7.7 envelope format with correct trading partner identifiers.
• •Map goods receipts and warehouse acknowledgments from SPS Commerce into Oracle Fusion's receiving module to close purchase orders and trigger three-way matching.
• •Authenticate with OAuth 2.0 bearer tokens on both systems, manage token refresh, and implement application-layer deduplication using document identifiers.
• •Poll both systems on a schedule tied to your procurement rhythm, with exponential backoff retries, a full audit trail, and error replay for every transaction.

Questions

How does the integration handle the different URL formats and authentication flows on each side?

Oracle Fusion uses a customer-specific pod URL with OAuth 2.0 against an OCI Identity Domain, while SPS Commerce uses a fixed base URL with a separate token endpoint. ml-connector stores both credential sets encrypted and maintains separate bearer token caches for each system, refreshing either token when a call returns 401. The pod URL is accepted per customer since every Oracle Fusion tenant has its own unique hostname.

What is the RSX 7.7.7 JSON envelope format and how does ml-connector handle it?

RSX is SPS Commerce's required JSON wrapper for all EDI documents. When posting invoices, advance ship notices, or acknowledgments to SPS Commerce, ml-connector wraps the document data in the RSX 7.7.7 envelope with the trading partner identifiers provisioned during onboarding. Inbound documents from SPS Commerce arrive pre-wrapped in RSX format and are unwrapped and mapped into Oracle Fusion's native data structures.

Since neither system has webhooks, how does the integration avoid missing or duplicate documents?

ml-connector polls both systems on a configurable schedule, typically every 5 to 15 minutes, filtering Oracle Fusion results by LastUpdateDate and using cursor-based pagination on SPS Commerce as required. Since neither system provides idempotency keys at the API level, ml-connector implements application-layer deduplication using purchase order numbers, invoice numbers, and receipt identifiers, so a retry of a failed document does not create duplicates.