Infor CloudSuite Industrial Integration Guide for Production Scheduling with SkyPlanner APS

SkyPlanner runs in the cloud, so no SkyPlanner software is installed inside CSI. In multi-tenant CSI, integrations run through Infor OS, by one of two routes:

1. Mongoose IDO REST API through the ION API Gateway. CSI business objects are IDOs (Intelligent Data Objects) on the Mongoose framework. The REST service sits under IDORequestService, and Infor publishes it in the ION API repository. REST version 1 offers LoadCollection, AddItem(s), UpdateItem(s), DeleteItem(s), InvokeMethod, IDOInfo and FireAESEvent, with XML or JSON responses. A REST version 2 endpoint set also exists.
2. ION BODs (Business Object Documents) routed by ION through connection points. CSI publishes outbound Sync BODs for ProductionOrder, ItemMaster and PurchaseOrder, plus inventory documents such as InventoryAdjustment, InventoryCount and InventoryHold.

The 2026.10 outbound BOD list has nothing for bills of material, routings or work centers, so a scheduling integration is IDO-first, with BODs as an optional change signal for jobs.

Changes leave CSI as ION BODs, and the ProductionOrder BOD is the one that matters for scheduling. You configure it on the Replication Document Outbound Cross References form with publishing definitions:

Infor’s examples filter on job status: 'Firm' for schedule changes, optionally 'Released' for material and labor changes. They also filter on RecordDate later than the background task’s last manual publish date.

Mongoose’s Application Event System (AES) can also run event actions, and the REST API exposes FireAESEvent. The base pattern is IDO polling: LoadCollection on SLJobs and SLJobRoutes filtered on the record date every few minutes, with the ProductionOrder BOD added where a site wants changes pushed.

In the other direction, SkyPlanner webhooks push schedule changes as they happen, and each one triggers the write-back to CSI.

1. Initial master data load. Read items, item routings, BOMs, resource groups, resources and shifts through LoadCollection. Build SkyPlanner workstations from resources and resource groups, not from work centers. Infor states plainly that the work center “captures costs only and does not affect the actual planning or scheduling.”

2. Order sync. Send firm and released job orders with their operations and materials. Leave APS planned orders in CSI. APS Planning deletes and regenerates its plan on every run, so planned orders have no stable identity to schedule against. Firm them to jobs on Planning Detail first.

3. Schedule write-back. A SkyPlanner schedule webhook triggers the write. The integration reads the new planned start and end per operation from the SkyPlanner REST API. It writes them with UpdateItems on the job operation schedule, keyed on job, suffix and operation number. These are the same operation dates the Scheduler sets and the Resource Gantt edits, and job Start and End dates on SLJobs follow.

Some sites protect schedule fields or want CSI-side logic on every change. There, the write goes through a custom IDO method called with InvokeMethod, which applies the same update with CSI’s own validation.

4. Shop-floor confirmations. Operators record time and quantities on phone or tablet (Mobile Confirmations, Production Timer, Quick Log Mode). Each closed timelog becomes an unposted SLJobtrans row created with AddItems, carrying job, suffix, operation, employee, hours and good and scrap quantities. CSI’s Job Labor Transaction Posting then posts labor cost and overhead to job WIP, on the cadence you choose.

5. Ownership, retries and conflict rules.

Every record is keyed on CSI’s own identifiers (job, suffix, operation number, transaction ID), so a repeated webhook or poll updates the same row instead of creating a duplicate. Failed writes are retried and logged with the CSI error text. A job set to Complete or History in CSI leaves the SkyPlanner schedule on the next sync, and a cancelled SkyPlanner job never writes back.

The native schedulers are the main conflict source. APS Planning treats scheduled operations as frozen, while later runs of the Scheduler (usually a daily run with a one-day horizon) can move them again. When SkyPlanner owns detailed sequencing for a set of resource groups, scope them out of the CSI Scheduler. Then turn off the Shop Floor Control Parameters setting that makes the Scheduler treat planned orders as demand. MRP, APS order planning and Get CTP can stay in CSI. Running Time Lock in SkyPlanner keeps started operations fixed. Inside SkyPlanner, Autopilot reschedules automatically when production changes, within the locks and priorities you set.

• Mapping work centers as machines. SLWcs is the obvious IDO and the wrong one for capacity. Scheduling lives on resources and resource groups (with member sequence).
• BOD filters that miss or repeat jobs. ProductionOrder publishing depends on your trigger choice and status filters. A filter on 'Firm' alone misses material and labor changes on released jobs; a missing last-publish-date filter resends everything.
• Labor rejected at write-back. CSI rejects labor when the job is not Released or Scheduled, when the operation is already complete or when the employee is inactive. Validate first and log rejections.
• Assuming a row equals a posted transaction. An SLJobtrans row is unposted until Job Labor Transaction Posting runs. Set the posting cadence with finance so WIP and payroll see labor when they expect it.
• Late jobs from APS. APS plans backward from the due date and, if that fails, forward from today; it never plans into the past. Let SkyPlanner schedule late orders from real capacity instead of trusting the incoming start date.
• Mongoose details. Escape commas inside InvokeMethod parameter values as \x2c.

SkyPlanner keeps the CSI side small. It reads jobs, operations, materials and resources, and writes back two things: planned operation times and SLJobtrans labor. In between, it does the replanning that CSI leaves to planner edits on the Resource Gantt and to the next Scheduler run:

• Event-driven schedule. Arcturus builds the finite capacity schedule in seconds, and Autopilot reschedules automatically when production changes, whether a changed job arrives from CSI or an operator logs progress. Webhooks then push the new times out.
• Labor captured at the source. Mobile Confirmations, Production Timer and Quick Log Mode turn operator input into timelogs that map to SLJobtrans rows, so labor reaches CSI without re-keying.
• Constraints that match the floor. A setting time matrix picks the changeover order with the least setup. Tools are finite shared resources, several operators can work one workstation at once, and alternative machines and personnel step in when the primary is busy.
• Material-driven sequencing. With job materials, stock and open CSI purchase orders in the feed, material availability is checked in the schedule. Ordered material counts as available on the PO delivery date, and stock updates when the PO is marked Delivered.
• A trial that de-risks the project. Load a Save to Excel export into the 30-day trial and see your own jobs on a finite schedule. Stop a bottleneck, add a rush order and delay a purchase order. The mapping you validate there becomes the scope of the IDO work.

Choose SkyPlanner when CSI should stay the system of record for items, jobs and cost. You get a scheduler and shop-floor app with a small, clear interface: jobs and master data in, planned times and labor out. SkyPlanner starts from 199 € per month with 5 workstations included, billed monthly, cancel any time. The integration is quoted up front for your process and needs, together with your plan, so you see the full cost before you start.

See pricing, features and the SkyPlanner docs. Compare CSI APS and the Scheduler with a cloud scheduler in Infor CloudSuite Industrial finite capacity scheduling. Or go to the Infor CloudSuite Industrial page and the ERP integrations hub.