Epicor Kinetic Integration Guide for Production Scheduling with SkyPlanner APS

Epicor states that “All Kinetic services, including business objects, processes, reports, BAQs, and Epicor Functions, are accessible through REST endpoints.” A scheduling integration is built on four Epicor technologies:

1. Kinetic REST API v2 (OData v4). Business objects are exposed as services named Erp.BO.<Name>Svc. The usual path is /api/v2/odata/{Company}/Erp.BO.{Svc}/{EntitySet}. REST v1 still exists but is legacy, so build on v2. Confirm entity sets and methods for your release in REST Help at /api/help/v2/.
2. Business Activity Queries (BAQ) over REST. A BAQ is exposed at /api/v2/odata/{Company}/BaqSvc/{BAQ}/Data. This is the practical read path for planning extracts that join JobHead, JobOper, JobMtl, PartWhse and PORel in one call (community example).
3. Epicor Functions (EFx). Server-side functions callable at /api/v2/efx/{Company}/{Library}/{Function}. Epicor states they “can be triggered from multiple entry points, including BPMs, REST services, schedules, and application events.”
4. BPM directives. Method and Data Directives fire when a job or operation changes and can call a function that pushes data out.

For files, DMT handles inbound imports and BAQ exports handle outbound extracts. Epicor also offers Epicor Automation Studio, which it describes as “a low-code app for integration-led automations”. Skip direct database access: REST, BAQs and functions work the same on premises and on Kinetic Cloud.

Epicor documents no generic outbound webhook API, so Kinetic changes reach SkyPlanner in one of two ways:

• Event-driven. A BPM Data Directive on JobHead or JobOper calls an Epicor Function, which posts the changed job to the SkyPlanner REST API.
• Scheduled polling. A BAQ filtered on change date runs every few minutes or hourly. It is simpler to own and to recover.

In the other direction, SkyPlanner pushes state and schedule changes through its webhooks. Your middleware or an EFx endpoint receives them and writes to Kinetic.

1. Initial master data load. Read parts, resource groups, resources, capabilities, calendars and employees. Build SkyPlanner workstations from Kinetic resources, and workstation groups from resource groups. Page large reads with $top and $skip, or pull bulk data through a BAQ.

2. Order sync. Send released and firm jobs with their operations and materials. Pull the job tree with GetDatasetForTree or a BAQ, not entity by entity. Leave unfirm MRP jobs in Kinetic until they are firmed. Sync open PO releases with their due dates alongside the stock read. SkyPlanner treats ordered material as available on the delivery date and updates stock when the PO is marked Delivered, so the schedule checks both stock and incoming purchases.

3. Schedule write-back. SkyPlanner’s webhook sends the planned start, end and workstation per operation to an EFx endpoint (/api/v2/efx/{Company}/{Library}/{Function}). The function writes through Kinetic’s schedule engine, the same business object behind Job Entry scheduling and the scheduling boards (community example):

1. ScheduleEngine.GetNewParamsForJob builds the schedule engine dataset for the job.
2. The function sets job number, assembly and operation sequence and the planned start date and time, then calls ScheduleEngine.MoveJobItem.
3. When SkyPlanner placed the operation on another resource in the group, ScheduleEngine.ChangeResource moves it there. MoveJobItem alone keeps the group’s default resource.
4. The function sets the job’s schedule lock (JobHead.SchedLocked, the Lock option in Job Entry), so Global Scheduling keeps SkyPlanner’s dates.

One Epicor Function around these calls keeps the write atomic per job and lets you add your own validation. Where a site prefers no custom function, the same sequence runs as direct REST calls to Erp.BO.ScheduleEngineSvc. Never write ResourceTimeUsed or JobOper date fields directly: that bypasses the engine and the board allocations go out of step.

4. Shop-floor confirmations. Operators log work in SkyPlanner with Mobile Confirmations, the Production Timer or Quick Log Mode. Each closed timelog becomes labor in Kinetic through Erp.BO.LaborSvc: StartActivity and EndActivityByEmp for live activity, or Labors with Update for after-the-fact entries. If your site requires approval, include submitForApproval in the flow and the scope.

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

Jobs SkyPlanner schedules carry the schedule lock, so Global Scheduling leaves their dates alone. Keep Kinetic scheduling for any resources SkyPlanner does not plan.

Implementation is normally completed within weeks after onboarding starts. A Kinetic project covers:

1. A 30-day trial on CSV or Excel exports of jobs, operations and resources, before any development.
2. API key, access scope, a dedicated integration user and the BAQs the integration reads.
3. Master data mapping: capabilities, resource groups, resources, calendars and employees to SkyPlanner workstations, groups, shifts and personnel.
4. Initial load of parts, methods (BOM and operations) and resources.
5. Job sync and purchase order sync (PORel due dates), plus PartWhse stock.
6. Schedule write-back of planned operation dates through ScheduleEngineSvc (MoveJobItem, ChangeResource) in an Epicor Function, with the job lock set.
7. Shop-floor confirmations posted as labor through LaborSvc.
8. Testing in parallel with the current Kinetic schedule, then go-live.

No two plants run Kinetic the same way. Capability routing, resource group calendars, BAQ design, BPM directives and release-specific write-back methods differ from site to site. Getting them right is the difference between a schedule planners trust and one they rework.

1. The SkyPlanner team configures it during onboarding and supports it after go-live. The team maps your resources, jobs and PO releases and sets up the BAQ reads, BPM triggers and the write-back function. It connects SkyPlanner’s REST API and webhooks to Kinetic REST v2. Support continues when your BAQs, BPMs or Kinetic release change.
2. Your Epicor partner. Partners who already write BAQs, BPMs and Epicor Functions can work on the same documented SkyPlanner REST API, which reads and writes orders, products, materials, process steps and timelogs.
3. Your own developers. In-house teams with Kinetic REST experience can build directly, or in Automation Studio if you run it. A SkyPlanner API key is enough to start (integration tutorial), and the SkyPlanner team assists when needed. Product documentation is public at SkyPlanner docs.

The same API-and-webhook pattern runs in production with other ERPs, for example at UTU. At Laboratory & Allied, the in-house IT team built the SAP Business One integration largely on its own with SkyPlanner’s help.

Every route starts the same way: run the 30-day free trial on CSV imports first, prove the schedule, then build the integration. Pricing is from 199 € per month with 5 workstations, 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.