NetSuite Integration Guide for SkyPlanner APS Production Scheduling

Oracle has set the direction. From 2026.1, new integrations should be built on SuiteTalk REST web services with OAuth 2.0. From 2027.1, no new integrations on SOAP or Token-Based Authentication (TBA). SOAP endpoints are disabled in 2028.2. Any scheduling integration started today belongs on REST.

Authentication

For a server-to-server scheduler, use OAuth 2.0 Client Credentials (machine-to-machine). The admin path is Setup > Integration > Manage Authentication > OAuth 2.0 Client Credentials (M2M) Setup. You upload a public certificate and map it to an entity, a role and the integration record. Each integration record holds at most five active certificates.

Create a dedicated integration role: view on items, BOM revisions, routings and work centers; edit on work orders, completions and issues. The SkyPlanner REST API (API reference) uses JWT, so the middleware holds both credentials.

Events: there is no standard webhook

Oracle’s documentation describes no native outbound webhook. The working pattern is a SuiteScript User Event script on Work Order (afterSubmit) that queues an outbound call through N/task or a Map/Reduce script, calling out with N/https. Never call out synchronously in afterSubmit: the call runs inside the user’s save, so a slow endpoint slows or breaks the save.

User events do not cover every change path. Mass updates and CSV imports can bypass them. Pair the event script with a scheduled SuiteQL reconciliation poll on lastmodifieddate so nothing is missed. In the other direction, SkyPlanner’s own webhooks drive the write-back, so NetSuite gets new dates as soon as the plan changes.

1. Initial master data load. Read work centers first, then items, BOM revisions and routings with SuiteQL. Routings reference work centers, so order matters. In the trial, export the same data to CSV and import it into SkyPlanner. The schedule is validated before any code exists.

2. Order sync. Pull work orders in Released and In Process status. Decide early whether Planned work orders come along. If they do, treat them as tentative demand. Sync open purchase orders in the same cycle, so the schedule checks each job against stock and incoming material, not stock alone.

3. Schedule write-back. When the schedule changes, a SkyPlanner webhook pushes the new operation dates to the middleware. The middleware sends PATCH /services/rest/record/v1/manufacturingOperationTask/{id} (Oracle record reference) with startDate and endDate for each changed operation. One more PATCH on the workOrder header sets the Production Start and End Date. Write only dates and, if you use one, a custom sequence field. Never write quantities or BOM data back. To update many operations in one transaction, a small RESTlet saves the whole operation list in one call. The record API stays the default.

4. Shop floor confirmations. Operators log work in SkyPlanner Mobile Confirmations. The middleware posts each confirmation through the Work Order transforms with POST /services/rest/record/v1/workOrder/{id}/!transform/workOrderCompletion, carrying startOperation, endOperation, the completed quantity and the logged time on the operation lines. Non-WIP work orders close with !transform/assemblyBuild instead. Work Order Completion over REST requires the Manufacturing Work In Process feature. Inventory and cost postings stay in NetSuite.

5. Idempotency and retries. Each completion carries the SkyPlanner timelog ID as its NetSuite external ID. External IDs are unique per record type, so a replayed webhook is rejected as a duplicate instead of posting quantities and cost twice. Writes go through a queue. A failed call (concurrency limit, locked record, expired certificate) is retried and logged. Anything that still fails is visible to the SkyPlanner team supporting the integration.

6. Ownership rules. NetSuite owns what is made: item, quantity, BOM, routing, location. SkyPlanner owns when and where: operation sequence, workstation, start and end. Dates edited in NetSuite are overwritten on the next write-back, so lock Production Start/End Date with a form customization or workflow.

• Work orders without routings. A work order with no Manufacturing Routing has no operations to schedule. Oracle says the same about its own finite scheduler: “Work orders not associated with a NetSuite routing should not be scheduled.” Find them with SuiteQL before go-live.
• Work centers are thin. A NetSuite work center is a Group with two counts, Machine Resources and Labor Resources (both default to 0), and one Work Calendar, usually “Default Work Calendar”. Load work centers once, then maintain individual workstations, shifts per person, tools, the setting time matrix and alternative workstations in SkyPlanner.
• Setup Time and Run Rate quality. NetSuite’s infinite scheduling uses these fields, but because it ignores capacity, wrong values go unnoticed. A finite schedule exposes them on day one.
• WIP or non-WIP. With Manufacturing WIP, output posts through Work Order Issue, Work Order Completion and Work Order Close. Without WIP, an Assembly Build is used. The integration posts completions for WIP items and assembly builds for the rest, so the model per item is part of the mapping.
• Advanced Manufacturing in the same account. If the account also runs the Advanced Manufacturing SuiteApp, its Manufacturing Work Bench records must match the routing exactly: operation sequence, operation name and work center. Decide which system sets operation dates. Two schedulers on the same work orders means two competing plans.
• Concurrency limits. Web services and RESTlet calls share one account concurrency limit, set by service tier plus 10 per SuiteCloud Plus license. Parallel per-record polling hits it fast. Use SuiteQL with paging for reads and queue writes.
• Sandbox refresh wipes M2M setup. OAuth 2.0 client credentials mappings are cleared on sandbox refresh and are not copied between accounts. An expired or revoked certificate stops the sync until a new mapping is created. Alert on authentication failures.