Process a work order

Where you do this

Click a WO number on the Work Orders list, or open /login/wo/processWorkOrder.xhtml?id=<id>. The page header reads Work Order: WO-XXXXXX with the type, status and target date alongside.

What you can do here depends on the WO's status:

• DRAFT — build the routing (add/edit/delete steps), set header fields, run a preflight check, then Release to Floor.
• IN_PROGRESS — drive each step through its lifecycle, request stock, capture progress, complete or pause.
• COMPLETED / CLOSED / CANCELLED — read-only audit view.

The action toolbar (top right)

• Release to Floor — the headline button on a DRAFT. Validates the routing, sets the WO IN_PROGRESS, and activates all PENDING steps at the lowest priority.
• Recalculate Routing — re-runs the priority-based routing algorithm on the current line set; useful after editing step priorities.
• Check Routing Config — opens the Preflight dialog (see below) — surfaces problems that would stop a release.
• Save as Template Copy — clones the current DRAFT into a new TEMPLATE WO so you can reuse the routing later.
• Cancel Work Order — full WO cancel. Marks the WO CANCELLED and runs onCancel() on every non-terminal step (downstream domain entities — leave requests, custom-schedule rows, etc. — clean themselves up).
• Copy Tracking Link — copies the public customer-tracking URL (an AES-encrypted token) to your clipboard.
• Download Report — PDF summary of the WO.

Progress

Under the toolbar sits a Progress panel — visual breakdown of how many steps are PENDING, ACTIVE, PAUSED, COMPLETED, etc. Live, refreshes as steps move.

Routing Steps

The heart of the page. A table of every step, sorted by executionPriority. Columns:

What you can do per step

• Process — opens the step's processing view (e.g. the repair-bench page for a REPAIR_TASK, the receipt page for a LOCAL_RECEIPT). Available when the step is ACTIVE and you're eligible.
• Edit — only on PENDING steps. Opens the step builder dialog for that line type.
• Delete — only on PENDING steps. The system rejects deletes on ACTIVE / COMPLETED.
• Pause / Resume — system pause is automatic when a step is waiting on a child (e.g. a delivery); user pause is allowed on certain task types and asks for a reason.
• Force Complete Step — admin-only. Bypasses handler validation. A confirm dialog warns you to enter a reason; the override is recorded.
• Reassign Area — admin-only. For REPAIR_TASK and ASSEMBLY_TASK lines; routes the step to a different area when the original area is unavailable.

Adding a step

Click Add Step above the routing table. The builder dialog asks:

1. Step Type — picks which line type (and therefore which builder form is shown).
2. Priority — its routing slot. The system rejects priorities ≤ the currently active priority on an IN_PROGRESS WO — you can only add steps that fall after the current group.
3. Description — free text.
4. Type-specific fields — vary per builder. Examples:
   • Local Receipt — expected items table
   • Local Shipment — planned items table
   • Courier Booking — parcels table (Add Parcel button)
   • Delivery Request — a basket of products to fetch from the warehouse
   • Sales Replacement — planned items for the replacement

Click Save Step (or Update Step when editing). Adding a step on a DRAFT just persists; on an IN_PROGRESS WO at a higher priority slot, the step is queued and activates when its priority comes up.

Releasing

1. Make sure every step has the right priority and assignee.
2. Click Check Routing Config — the preflight dialog lists any blocking issues (missing assignees, missing assembly area on a BOM component, etc.). Click Fix on a row to jump straight to the offending step or use Re-check after fixing.
3. When the preflight is clean, click Release to Floor. The WO flips to IN_PROGRESS, the lowest-priority steps activate, and the relevant assignees see them in their task queues (My Repair Tasks, My Assembly Tasks, Pending Approvals, etc.).

Activity Log

A second tab next to Routing Steps with the full audit trail — every state change, comment, material consumed, delivery confirmed, etc. Columns: Time, User, Action, Ref, Description. The same events are also posted to the WO's system-chat conversation.

Recovering a step in ERROR

If a step's onStart() or onComplete() threw, the row turns red and the status is ERROR. Two recovery paths:

• Clear error — flips ERROR → ACTIVE so the operator can fix the underlying cause and click Complete again. Does not re-run onStart().
• Retry from error — only useful for auto-completing handlers (where the step does its work in onStart()). Resets to PENDING, re-runs onStart(), and auto-completes if it succeeds.

A STEP_ERROR activity event captures the technical reason in its payload — visible in the activity log; not shown to the public tracking page (those summaries are filtered).

Tips

• Lines at the same priority run in parallel. Use this to run independent steps concurrently (e.g. a Repair Router that spawns four parallel Repair Tasks).
• A PAUSED step holds its priority slot — downstream steps will not advance until it resumes or completes.
• Force Complete should be the last resort. Most stuck steps clear with a normal complete or with stock arriving. Use it when a step genuinely can't be completed via its handler (e.g. an external system died) and you want to move on.