QAD Adaptive ERP Integration Guide for Production Scheduling with SkyPlanner APS

QAD gives an external scheduler three routes:

1. QAD QXtend Inbound (QXI). QAD describes it as “a Web services-based, SOAP-compliant, XML framework, enabling complete platform-independent access to QAD Enterprise Applications business functionality.” Each request is a QDoc that runs a QAD program with the same validation as its screen, and each returns a response QDoc. Released QDocs include maintainItemMaster, maintainRouting and maintainPurchaseOrder. For programs without a released QDoc, QAD’s QGen tool maps the menu program: “QGen is used to map custom programs or QAD Enterprise Applications programs that do not have released QDoc schemas and events files.” QAD uses this route itself: “QAD Production Scheduler uses QAD QXtend to update work orders.” (QXtend guide)
2. QAD QXtend Outbound (QXO). QXO “exports user-configurable business objects as XML QDocs out of QAD products.” Standard business objects include Item, Product Structure, Routing, Work Center, Department, Inventory Transaction and Inventory Status.
3. Business document REST APIs. Since Adaptive ERP 2022.1, “Query REST APIs are now available for business documents,” with filtering, sorting, paging and partial data, documented in Swagger on your instance (release notes).

QXtend carries the writes. QXO and the REST query APIs carry the reads.

QXtend Outbound is QAD’s change-data mechanism. “A change occurs to watched data in QAD Enterprise Applications. Change notifications are written out to the qxevents database.” QXO then builds the QDocs and delivers them “to a directory location where the subscriber polls for and picks up new QDocs,” or to a web service listening on a URL.

SkyPlanner subscribes as a web service where QXO publishes, and polls the REST query APIs for anything QXO does not cover. Work Order is not one of the standard QXO business objects, so the integration either adds a QXO business object on the work order tables (wo_mstr, wr_route) or polls work orders through the REST query APIs every few minutes.

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

1. Initial master data load. Read items, product structures, routings, work centers and calendars through QXO or the REST query APIs. Map work centers deliberately: a work center with four machines becomes one workstation group or four workstations. Repetitive lines from Production Line Maintenance can become workstations too.

2. Work order sync. Read firm planned and released work orders with their routings and components, 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 MRP planned orders. Planned orders become firm planned or released work orders in QAD first.

3. Schedule write-back. When the engine places or moves an order, a SkyPlanner webhook triggers a QXtend Inbound QDoc on Work Order Maintenance (16.1). It sets the release date to the first scheduled operation and the due date to the last. QXtend runs the program with QAD’s own validation and returns a response QDoc that the integration checks.

The operation sequence on each machine stays in SkyPlanner and reaches operators through Mobile Confirmations. That keeps the integration clear of QAD’s routing freeze on released orders.

4. Shop-floor confirmations. Operators log work with SkyPlanner Mobile Confirmations or the Production Timer, and the timelogs keep the schedule current. You choose whether actual times post back to QAD. If yes, setup and run time go to Labor Feedback by Work Order per operation, and completed quantities to Work Order Receipt. If no, labor is entered in QAD as before.

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

Pick one writer of work order dates. SkyPlanner needs no QAD scheduling module, so it replaces the scheduling workbenches or other schedulers as the writer of dates for the orders it schedules.

• CRP reruns. CRP reschedules all open operations of the selected work orders. QAD keeps manual dates only when “you also adjusted the work order release and due date to match,” which is exactly what SkyPlanner writes. Run CRP after the write-back, or exclude the orders SkyPlanner schedules.
• Released routings are frozen. “Once the work order status is Exploded, Allocated, or Released, no more changes can be made to the routing.” Read the routing at release, and change routings only on planned or firm planned orders.
• Routing time units. Setup and run time are load, while “queue, wait, and move times are excluded from load calculations.” Model queue, wait and move as time-only steps in SkyPlanner, and check whether run time is per unit or per order.
• QXtend throughput. QAD warns that “UI API adapter performance may be unacceptable when processing high volumes of data or real-time transactions.” Send only changed orders, in batches, and use native QDocs where they exist.
• Domains and sites. Multi-domain QAD installations keep work centers and work orders per domain and site. Map each site in scope to its own workstation group.
• Repetitive and discrete mix. Advanced Repetitive lines use repetitive schedules, not work orders. Decide in scoping which lines SkyPlanner schedules.