Setting Up TMS Integration With Oracle Fusion Cloud SCM

If your supply chain team runs Oracle Fusion Cloud SCM, you've probably been told that Oracle Fusion Cloud SCM TMS integration means adopting Oracle Transportation Management (OTM/GTM) as your transport layer. That's the path of least resistance, not a technical requirement. This guide walks through connecting a standalone, multi-carrier TMS to Fusion SCM using the same REST endpoints, Oracle Integration Cloud (OIC), and FBDI jobs that the bundled module relies on, so you end up with carrier flexibility without rebuilding your fulfillment process.

Why Oracle Fusion Cloud SCM shippers don't have to default into OTM

Oracle's own documentation makes the architecture explicit: Oracle Integration Cloud (OIC) includes a logistics adapter that can be used to integrate Oracle Fusion Cloud Transportation and Global Trade Management (OTM/GTM), Oracle Fusion Cloud Order Management, Oracle Fusion Cloud Inventory Management, and Oracle Product Hub. That adapter is built for OTM/GTM specifically, but the connection points it uses, sales order releases, shipment plans, fulfillment milestones, sit on documented REST resources that any system can call.

Oracle confirms this directly in its own integration guidance: you can use Oracle Integration Cloud (OIC) to integrate Oracle Fusion Cloud Order Management with Oracle Transportation Planning (OTM), or some other transportation management system that resides outside of Oracle, and to integrate with Oracle Global Trade Compliance (GTM). That one sentence is the entire case for building your own connection rather than defaulting into the bundled module.

Enterprise-native options in this space include OTM itself, SAP TM, MercuryGate, Descartes and Blue Yonder. Shippers who want carrier reach beyond what Oracle's native network offers typically bolt on multi-carrier platforms like Cargoson, FreightPOP or Alpega instead, connecting through the identical REST/OIC layer described below.

What you need before you start

You need a Fusion SCM instance with Inventory Management (Shipping) and Order Management active, ideally on a non-production pod for the first pass. You'll also need either an OIC subscription for the Logistics Adapter pattern, or direct REST access if you're building point to point.

The REST surface itself sits under a single base path, /fscmRestApi/resources/11.13.18.05/, and the create one request method posts to /fscmRestApi/resources/11.13.18.05/shipmentTransactionRequests, while shipment actions post to /fscmRestApi/resources/11.13.18.05/shipmentTransactionRequests/action/shipmentActions. Rule of thumb on volume: use REST for anything real-time and under a few hundred records, and switch to FBDI once you're dealing with mass order import, anything over 500 orders.

One setup detail that trips people up: business events aren't live by default. Business Events are not enabled by default, each event type must be explicitly activated in SCM Setup and then subscribed to in OIC. Skip this step and your event-driven triggers simply never fire, with no error to point you at the cause.

Finally, load carrier and service-level master data into Fusion before you route a single shipment. Nothing downstream works without it.

The integration steps

1. Map the data flow. Decide what travels from Fusion to the TMS (sales order releases, ship-from/ship-to, ready dates) and what comes back (carrier, service level, rate, tracking, actual ship date). Oracle is upfront that this isn't handed to you: Order Management doesn't come predefined to integrate with Transportation Management or Global Trade Management, and integrating requires an orchestration process, connectors, business rules, constraints, and web services that you configure yourself.
2. Choose your integration surface per object. For shipments, use the documented Shipment Transaction Requests resource and its action endpoint from the base path above. For carrier and service-level lookups, pull from the shipping methods list of values, where Carrier is Read Only, Maximum Length 360, the name of the party that transports the shipment, and ServiceLevel is the transportation priority that determines how quickly to transport goods.
3. Build the connector with a name Oracle recognizes. Oracle's own guidance is specific here: name the connector TransportationPlanning. Order Management uses this name at various locations in the flow. Using TransportationPlanning will help you identify the connector involved in the flow during troubleshooting. Register it as a named connector, not an ad hoc script, authenticated via OAuth2 client credentials against Oracle's identity layer.
4. Wire up event-driven triggers instead of polling. Once business events are active, OIC can receive Sales Order Transport Planning events from SCM Order Management when the Sales Order reaches shipping milestone in OM, and then automate the shipping activities by interfacing with the transportation system to complete the shipping leg of fulfillment.
5. Return carrier, rate and tracking data to Fusion. Match the field-level precision Oracle's own mapping uses: one order line in Order Management maps to one order release plus one order release line in Transportation Management, and the integration maps the ScheduleShipDate attribute in Order Management to the GLogDate attribute in Transportation Management. Replicate that same discipline for your TMS's attribute names, field by field, rather than guessing at a loose mapping.
6. Test end to end in the non-production pod. Run a sample order through to shipped status and watch the integration instance complete in OIC rather than assuming success from the TMS side alone.
7. Go live with a parallel run. Keep Oracle's prebuilt OTM/GTM recipes available as a fallback before decommissioning or bypassing them, in case the new connector needs a rollback window.

How you know it worked

Success is observable in Fusion itself, not just inside the TMS. The clearest signal is a status change rather than a log entry: Shipment Plan Complete prevents you from revising the order line in the Order Management work area after Transportation Management sends the transportation plan to Inventory Management, and Order Management uses the transportation plan to determine whether Transportation Management already sent the transportation plan to Shipping. When your standalone TMS triggers that same state change, your integration is doing its job.

At the fulfillment-milestone level, Oracle describes the full loop this way: it sends sales orders for transportation planning, and receives updates at fulfillment milestones, such as plan complete or proof of delivery. If proof-of-delivery updates aren't landing back in Fusion, the return leg of your mapping needs attention before you call the integration complete.

One failure mode to plan for, and the fix

The most common failure isn't a rejected API call. It's a silent one. Oracle builds a strict time window into its own predefined flows: predefined OTM/GTM integrations are time bound to receive an acknowledgment within 30 minutes, and if the acknowledgment isn't sent, Oracle Order Management will make the order lines eligible to be resent. A custom connector to a standalone TMS doesn't inherit that safety net automatically, so a shipment can sit stuck on transportation-planning status with no visible error while your TMS thinks it already confirmed the plan.

The fix is to stop assuming success and start checking job completion explicitly. In addition to business event integration, the ERP Cloud adapter can receive a Callback Event upon Completion of FBDI Bulk Import Jobs, which can notify OIC integrations and be designed to automate flows for post-FBDI processing tasks, a typical example is to check FBDI job completion status, notify an administrator of any errors, or kick off custom error-handling flows to retry FBDI failures. Build that callback into your flow from day one rather than retrofitting it after your first stuck shipment.

Where this fits in a broader vendor landscape

This exact REST/OIC pattern is why Fusion SCM customers aren't locked into OTM. A documented example from outside Oracle's own stack makes the point cleanly: the Warp freight API plugs into SAP TM, S/4HANA, Oracle OTM, and Oracle Fusion Cloud SCM, which confirms that any TMS speaking REST can sit in the same integration slot Oracle built for its own module.

Before you commit either way, pull your current carrier list and check it against what each candidate actually connects to out of the box. The REST layer is identical either way; the difference is how much custom mapping work you take on versus how much carrier flexibility you get back.