[feat] Supporting pasing and resuming work orders with changes in between

[buzzy84]

Problem / motivation

OpenMES currently supports pausing and resuming a work order through the PAUSED status.

A work order can also enter the BLOCKED status, and production downtime can be recorded separately.

However, the current pause and resume workflow is mainly a direct status transition:

IN_PROGRESS → PAUSED → IN_PROGRESS

It does not provide a controlled process for cases where production is stopped because the product, process or production instructions must be changed before work can continue.

Typical scenarios include:

• a technical problem is discovered during production;
• a product revision must be changed;
• a component or material must be replaced;
• a BOM quantity must be corrected;
• a process step must be added, removed or changed;
• an instruction or technical document must be updated;
• quality requirements must be modified;
• partially produced quantities must remain traceable under the previous configuration;
• production must resume under a newly approved configuration.

The existing work-order edit endpoint currently allows several important fields, including product, quantity, line and status, to be updated without a dedicated change-control workflow.

This may create inconsistencies between:

• work already completed;
• consumed materials;
• active batches;
• process steps;
• product revision;
• technical documents;
• remaining quantity.

Proposed solution

Introduce a controlled production-stop and work-order change workflow built on the existing PAUSED and BLOCKED statuses.

Suggested workflow:

IN_PROGRESS
    ↓
CHANGE_HOLD or PAUSED
    ↓
Change request created
    ↓
Changes reviewed and approved
    ↓
New work-order configuration snapshot
    ↓
RESUME
    ↓
IN_PROGRESS

A new status such as CHANGE_HOLD may be introduced, or the existing PAUSED status may be extended with a structured pause type.

Suggested pause types:

OPERATIONAL
MATERIAL_SHORTAGE
MACHINE_FAILURE
QUALITY_HOLD
ENGINEERING_CHANGE
OTHER

Stopping production

When stopping an active work order, the user should provide:

• stop or pause type;
• reason;
• timestamp;
• affected batch or step, when applicable;
• whether production is expected to resume unchanged;
• whether a configuration change is required;
• optional attachments or evidence;
• optional issue or non-conformance reference.

OpenMES should record:

• who stopped production;
• when it was stopped;
• current produced quantity;
• active batches;
• active and completed steps;
• materials already allocated or consumed;
• product revision and configuration snapshot active at the stop.

The stop must not delete or overwrite execution data already recorded.

Production-change request

When a configuration change is required, an authorized user should create a production-change request linked to the work order.

The request should contain:

• change title;
• detailed reason;
• affected work order;
• affected batches, steps or serial units;
• old product revision;
• proposed product revision;
• old and proposed planned quantity;
• old and proposed BOM;
• old and proposed process;
• changed technical documents;
• changed quality requirements;
• disposition of partially produced items;
• disposition of allocated or consumed material;
• requested-by user;
• approval status;
• approver;
• approval timestamp;
• implementation notes.

Suggested statuses:

DRAFT
SUBMITTED
APPROVED
REJECTED
APPLIED
CANCELLED

Allowed modifications

The change request should explicitly identify which fields are being changed.

Supported changes may include:

• product revision;
• remaining planned quantity;
• production line;
• process steps not yet started;
• BOM requirements for remaining production;
• material substitutions;
• technical-document revisions;
• inspection or quality requirements;
• due date or schedule;
• description and production notes.

Changes to already completed execution records must not be permitted.

The system must not rewrite:

• completed batch steps;
• historical material consumption;
• completed quality checks;
• recorded scrap;
• serial genealogy;
• historical quantities.

Impact analysis

Before applying a change, OpenMES should show an impact summary:

• quantity already produced;
• quantity remaining;
• active and completed batches;
• affected future steps;
• materials already consumed;
• materials allocated but not consumed;
• obsolete allocations;
• new material requirements;
• technical documents being replaced;
• product revision change;
• affected serial numbers or lots.

The user should be warned when a proposed change is incompatible with work already completed.

Applying the change

When an approved change is applied:

• the previous work-order snapshot must be retained;
• a new versioned work-order configuration snapshot must be created;
• the new configuration must apply only from an explicit effective point;
• remaining material requirements must be recalculated;
• future, not-yet-started steps may be regenerated or updated;
• active batches must be handled explicitly;
• all changes must be audited.

Suggested effective points:

NEXT_BATCH
SPECIFIC_BATCH
SPECIFIC_SERIAL_NUMBER
REMAINING_QUANTITY
IMMEDIATE

IMMEDIATE should only be allowed where no incompatible step or consumption has already occurred.

Partial production and revision traceability

When some quantity was produced before the change and the remainder after the change, OpenMES must preserve both configurations.

Example:

Work order WO-2026-0105
Planned quantity: 100

Units 1–35:
- Product revision B
- Configuration snapshot 1

Units 36–100:
- Product revision C
- Configuration snapshot 2

For batch production:

Batch 1 — Revision B — Completed
Batch 2 — Revision B — Stopped
Batch 3 — Revision C — New production

The system should avoid changing the revision of a batch that already contains completed production. Where necessary, the existing batch should be closed or split and a new batch created.

Resuming production

Production may resume only when:

• the stop reason has been addressed;
• any required change request is approved and applied;
• a valid product revision is selected;
• the new configuration snapshot exists;
• required technical documents are released;
• required material allocations are valid;
• blocking quality or production issues are resolved or formally overridden;
• the user confirms the effective point of the new configuration.

The resume action should record:

• resumed-by user;
• resume timestamp;
• applied change-request ID;
• active configuration snapshot;
• notes;
• resulting work-order status.

Downtime integration

The production stop should be linked to the existing downtime model where appropriate.

The system should distinguish:

• a work-order pause;
• a machine downtime;
• a line downtime;
• an engineering or quality hold.

One event may create linked records, but they should not be treated as identical concepts.

Duration should be calculated from stop to resume and exposed in:

• work-order history;
• downtime reports;
• OEE analysis where applicable;
• audit logs;
• REST API;
• webhook events.

REST API support

Suggested endpoint concepts:

POST /api/v1/work-orders/{workOrder}/stop
GET  /api/v1/work-orders/{workOrder}/stops
POST /api/v1/work-orders/{workOrder}/change-requests
GET  /api/v1/work-order-change-requests/{changeRequest}
PATCH /api/v1/work-order-change-requests/{changeRequest}
POST /api/v1/work-order-change-requests/{changeRequest}/submit
POST /api/v1/work-order-change-requests/{changeRequest}/approve
POST /api/v1/work-order-change-requests/{changeRequest}/reject
POST /api/v1/work-order-change-requests/{changeRequest}/apply
POST /api/v1/work-orders/{workOrder}/resume

Suggested stop payload:

{
  "type": "ENGINEERING_CHANGE",
  "reason": "Hole diameter must be changed before continuing production",
  "batch_id": 18,
  "requires_change": true
}

Suggested resume payload:

{
  "change_request_id": 52,
  "effective_from": "NEXT_BATCH",
  "notes": "Production resumed using product revision C"
}

Suggested acceptance criteria:

• an IN_PROGRESS work order can be stopped with a structured reason;
• stop and resume timestamps and users are recorded;
• the configuration active at stop time is preserved;
• a controlled change request can be created during the stop;
• changes require approval before application;
• completed execution records cannot be rewritten;
• a new versioned configuration snapshot is created when changes are applied;
• remaining material requirements are recalculated;
• production can resume using the new configuration;
• quantities or batches produced before and after the change remain distinguishable;
• product revisions remain traceable by batch, lot or serial number;
• stop duration appears in history and reporting;
• existing simple pause and resume behavior remains available for stops that do not require configuration changes.

Affected roles

• Operator
• Supervisor
• Admin

Alternatives considered

Edit the active work order directly

Using the existing work-order edit form during production was considered.

This is unsafe for structural changes because it may change the current order without preserving:

• the previous configuration;
• the effective point;
• already produced quantities;
• consumed materials;
• completed process steps;
• document revisions used by operators.

Direct editing may remain acceptable for non-structural fields such as priority, notes or due date, subject to permissions.

Cancel the original order and create a new order

Cancelling the old work order and creating a new one was considered.

This can preserve some separation, but it loses a clear controlled relationship between:

• the original order;
• the reason for the change;
• partially produced quantity;
• remaining quantity;
• transferred materials;
• old and new product revisions.

A change workflow may optionally create a successor work order, but the relationship must be explicit and auditable.

Reopen a completed or cancelled order

The existing reopen transition was considered.

Reopening changes the status back to production but does not define:

• which configuration is now active;
• what changed;
• which quantities were previously completed;
• whether old batches may be modified;
• which revision applies after reopening.

Reopen and controlled production change should therefore remain separate concepts.

Use only downtime records

Recording a downtime was considered.

Downtime explains that production stopped and measures duration, but it does not control modifications to product revision, BOM, process or documents.

Downtime and configuration-change records should be linked where applicable but remain separate domain objects.

Additional context

OpenMES already provides useful foundations:

• work-order statuses include IN_PROGRESS, PAUSED and BLOCKED;
• pause and resume actions already exist;
• work orders store process_snapshot;
• audit support is present;
• batches, steps, material allocations, issues and downtime records already exist;
• status-change webhooks are available.

The requested feature should extend the current pause/resume model with structured records and configuration versioning.

Suggested UI concept:

Work order: WO-2026-0105
Status: PAUSED
Stop type: ENGINEERING_CHANGE
Stopped at: 2026-07-15 10:42
Produced: 35 / 100

Current configuration
- Product revision: B
- Snapshot: 1

Proposed change
- Product revision: C
- BOM: 2 lines changed
- Process: Step 40 instruction changed
- Technical documents: 2 replacements

Impact
- Completed batches: 1
- Active batches: 1
- Remaining quantity: 65
- Material reallocations required: Yes

[Review change] [Approve] [Apply and resume]

Suggested history:

10:42 — Production stopped by Supervisor
10:50 — Change request CR-52 submitted
11:15 — Change request approved by Admin
11:22 — Configuration snapshot 2 applied
11:30 — Production resumed by Supervisor

The central requirement is that stopping, modifying and resuming production must never overwrite the historical configuration or execution data already recorded.