Schedule

The Schedule is the queue of jobs assigned to each machine in Eclipse Pro, along with each job's hold state and its position within a machine's queue. It is derived state — Eclipse Pro builds the schedule from your jobs (which arrive via Order Import) plus the assignments your operators or your external system make. Schedule integration is therefore not about creating jobs; it is about driving what already exists.

There are two independent purposes for schedule integration:

1. Hold control — place a job on hold (skipped by the scheduler; recalled from a machine if it is currently there) or release it. Useful when the ERP needs to suspend work without deleting a job, or when priorities change.
2. Machine sequencing — tell Eclipse Pro which machine a job should run on and in what order, the same operation an operator performs when dragging jobs onto a machine in the UI. This is opt-in; if you only need hold control, sequencing can stay off.

A single integration can drive either purpose, both, or neither. Each source row carries both signals.

Schedule integration is Eclipse Pro only. Eclipse Classic does not expose its schedule for external control.

Paths

#	Path	Pro	Trigger
1	Database sync	✅	Polling, on a configurable interval
2	Explicit REST API	✅	Caller pushes a batch on demand

Both paths run through the same internal mapping pipeline, so for identical input they produce identical end state. They differ in how the source data arrives, how jobs are identified, and how feedback is reported.

---

Job identification

Both paths need to know which job in Eclipse Pro a source row refers to. Eclipse Pro identifies jobs by an internal OrdId — a numeric key generated when the job is imported. External systems rarely know that value, so each path accepts business-level identifiers and resolves them:

Identifier	DB sync	REST API
OrdId	—	✅ (canonical)
OrderCode + MaterialCode + ToolingCode (the full triple)	✅ (required)	✅
OrderCode + MaterialCode	—	✅ (if unique)
OrderCode alone	—	✅ (if unique)

The triple (OrderCode, MaterialCode, ToolingCode) is the candidate key on a job in Eclipse Pro — it identifies one and only one job. The DB-sync path requires the full triple. The REST API also accepts any unique prefix because many ERPs treat OrderCode alone as their unit of work.

For the REST API:

• A shorter identifier that matches more than one job is ambiguous. The entire batch is rejected with a 400 Bad Request and a list of the offending rows. The integrator must add disambiguators (or switch to OrdId) and resend.
• An identifier that matches zero jobs is recorded as a single-row failure note; the rest of the batch proceeds — same as the DB-sync behavior for an unknown triple.

Hold control

Each source row carries an onHold flag. true places the job on hold; false releases it; absent (null/empty) leaves it unchanged.

• A held job that is queued is left in place but skipped by the scheduler.
• A held job that is at a machine is recalled to the queue. If running, the machine is halted before recall.
• A held job that is also given a target machine in the same row is placed at that machine and held there (no recall) — useful when the ERP intent is "stop running this here."
• The Hold Jobs Not In Sync Data option holds every existing runnable job that is not present in the source data. Useful when the ERP is the system of record for what should be running, but note that any manually-entered test jobs will also be held.

Machine sequencing

Sequencing is opt-in (SyncMachineSequence). When enabled, each row may carry a target MachineNumber and an optional Sequence:

MachineNumber	Sequence	Effect
Positive integer	Positive int	Place the job on that machine at that relative position.
Positive integer	Null / empty	Place the job on that machine, appended after any explicitly sequenced rows.
0	(any)	Explicit unschedule. Remove the job from whichever machine it is on.
Null / empty	(none)	The row carries no machine assignment. Hold control still applies.
Null / empty	Non-empty	Invalid combination — row rejected with a failure note; the job is left as it was.

Key behaviors apply to both paths:

• Per-machine atomicity. Each machine's new sequence is applied as a single batched operation. Other machines proceed independently if one is rejected.
• Running jobs are untouchable. A job on the controller (running, sending, or being recalled) keeps its current machine and position. A row that would move it is rejected with a failure note.
• Cross-machine moves are supported. A job currently queued on machine A and assigned in the source data to machine B moves between queues.
• Orphans are held and recalled. A job currently scheduled on machine M but not appearing in the source data for M (and not relocating to another machine in the same run) is held and recalled — same mechanism as Hold Jobs Not In Sync Data, scoped per machine.
• Hold + sequence both apply. A row with onHold = true and a MachineNumber value places the job at that position and holds it there.
• Duplicate sequence values are tie-broken deterministically by OrdId. Lets the ERP intentionally group several jobs at the same sequence to mean "these go together; order within the group doesn't matter."
• Same job listed twice on one machine rejects that machine. That one machine's sequence is left untouched and failure notes are recorded. Other machines proceed normally.
• Holds first, then sequences. Within one run, hold/recall actions are applied first to clear the affected machines, then the new sequences are written. This avoids transient collisions.

---

1. Database sync

Eclipse Pro polls an external SQL table or view on a configurable interval and applies the rows. The schema is small — order_, material, pcode for identification, plus optional onhold, machinenum, sequence, and sqlplant — and the full triple is required on every row.

The full specification, including the SQL Server CREATE TABLE script and the External Connection setup, is on the Schedule Sync page.

Use this when:

• Your ERP can write rows to a SQL table or view Eclipse Pro can reach.
• You want Eclipse Pro to drive the polling (you don't have a good "schedule changed" event to push from).
• You always know the full (OrderCode, MaterialCode, ToolingCode) triple.

2. Explicit REST API

Push a batch of schedule rows directly with a single HTTP call. The payload carries the same per-row signals (onHold, machineNumber, sequence) and the same top-level flags (syncMachineSequence, holdJobsNotInSyncData), and runs through the same mapping pipeline as the DB sync — so the end state is identical for identical input.

The REST API additionally accepts shorter identifiers (ordId, or any unique prefix of the triple). It is synchronous and stateless: there is no polling configuration to set up. Each call is a complete batch, and the response carries immediate per-row feedback.

Endpoint reference and request/response shapes: POST /api/v1/schedule/sync.

Use this when:

• Your ERP can't expose a SQL table for Eclipse Pro to reach.
• You want to drive the timing (push when you know the schedule has changed, not on an interval).
• You only know jobs by their order code.
• You want immediate validation feedback — duplicates, ambiguities, not-found, and parse errors come back in the response, not in an audit log.

---

Audit trail

Both paths persist a ScheduleSyncEvent document in Eclipse Pro for every run, capturing the input rows, the mapped actions, rejected rows, and any apply-side failures. The Eclipse Pro UI surfaces recent events under Settings → Integration → Schedule Sync. For the REST API, the response includes a batchId that points at the same document — useful for cross-referencing what your push produced.

Which path should I use?

• ERP can write to a SQL table and you want continuous sync: Database sync.
• You want to push on your own schedule, by HTTP, with immediate feedback: Explicit REST API.
• You only need hold control, no sequencing: either path — leave SyncMachineSequence off.
• You need both, with mixed identifier strategies (some OrdId, some OrderCode): REST API — the DB-sync schema requires the full triple on every row.