Oracle Fusion Cloud Integration Guide for Production Scheduling with SkyPlanner APS

Oracle Fusion Cloud gives an external scheduler three data routes:

1. REST API for Oracle Fusion Cloud SCM. The base path is /fscmRestApi/resources/11.13.18.05/. The resources a scheduler uses are workOrders (with the children WorkOrderOperation, WorkOrderOperationResource and WorkOrderOperationMaterial), processWorkOrders, workDefinitions, workCenters, productionResources, calendars, itemsV2, itemStructures and inventoryOnhandBalances. Progress is posted to operationTransactions, resourceTransactions and materialTransactions. Purchase orders come from purchaseOrders in the Procurement REST API. (REST endpoints)
2. File-Based Data Import (FBDI). The Import Work Orders process creates or updates work orders with their operations and operation resources from a template, and Import Work Order Resource Transactions loads resource postings. Oracle is clear about the timing: “This option isn’t suitable for importing manufacturing data on a real-time basis.” (source)
3. Oracle Integration (OIC). Oracle’s integration platform carries flows between Fusion and other systems. An Oracle Integration recipe listens to the Work Order Status Change event in Oracle Fusion Cloud Manufacturing (source). Use it where your company already runs OIC.

For live scheduling, REST is the main route. FBDI fits the first master data load.

The Oracle side is polled. Filtered REST queries pick up new and changed work orders, released status changes, on-hand and purchase orders. The frequency is set per plant, from every few minutes for work orders to hourly for stock. Where you run Oracle Integration, the Work Order Status Change event can trigger an immediate read.

SkyPlanner sends webhooks when state or the schedule changes, so the write-back side is event-driven.

1. Initial master data load. Read items, item structures, work definitions, work centers, production resources and calendars over REST, or load them once from FBDI extracts. Map work centers deliberately: a work center with four machines of the same resource becomes one workstation group or four workstations. Each manufacturing organization becomes a workstation group, so every plant sits in one plan.

2. Work order sync. Read released and unreleased work orders with their operations and materials, plus open purchase orders. SkyPlanner treats ordered material as available on the PO delivery date and updates stock when the PO is marked Delivered.

Schedule work orders, not Supply Planning planned orders. Planned orders become work orders in Oracle first.

3. Schedule write-back. When the engine places or moves a job, a SkyPlanner webhook triggers a PATCH on workOrders/{WorkOrderId}/child/WorkOrderOperation/{WorkOrderOperationId} with PlannedStartDate and PlannedCompletionDate. Oracle’s rule applies: “The planned start date must not occur before the start date of the work order or after the finish date of the work order.” (source) So the integration patches the work order header dates first when the new schedule moves outside them, then the operations.

4. Shop-floor confirmations. Operators log work with SkyPlanner Mobile Confirmations or the Production Timer, and the timelogs keep the schedule current. Completed quantities post to operationTransactions, and labor and machine time to resourceTransactions. If your plant reports in Oracle already, SkyPlanner reads that progress instead.

5. Ownership and conflict rules. Write them down before go-live:

Pick one writer of operation dates. SkyPlanner needs no Oracle scheduling work area, so it replaces Production Scheduling as the writer of planned dates. If Production Scheduling still releases schedules, keep its organizations apart from the ones SkyPlanner schedules.

• Default scheduler behavior. Oracle’s unconstrained engine runs on create and “certain update actions.” Test in your environment which updates recalculate dates, and keep SkyPlanner as the last writer of operation dates.
• Work order windows. Operation dates must fall inside the work order start and completion dates. Patch the header first.
• Basis Type. Resource usage is per unit only when Basis Type is Variable. A Fixed basis is a fixed time per operation. Convert on import or every duration is wrong.
• Discrete and process. Discrete plants use workOrders, process plants processWorkOrders. Map both if you run both.
• Paging. Oracle caps the records per REST call. Page every query and filter by organization and status.
• Quarterly updates. Oracle updates Fusion every quarter. Pin the REST version in the path and retest after each update.
• Status rules. Work orders in Pending Approval or closed status should not receive new dates. Filter them on read.