# 05 — Shop Floor Control (SFC) — Technical Digest (lossless)

> Source: `files/manufacturing_spec/markdown/05_shop_floor_control.md`. This digest reproduces every entity, field, rule, enum, and formula in the source so an implementer needs no access to the original. Governing principles inherited from `00` (genericity mandate, frozen snapshots, state machines, resource abstraction, config-over-code).

## 5.1 Purpose & Positioning

SFC is a **real-time tracking layer** that cross-cuts the Execution layer. It answers the question: **"where is each order right now?"**

It provides **per-department terminals** where a worker closes an operation, and the order **advances automatically** to the next stage.

Positioning — SFC sits **between Planning and Execution** and connects them in real time:

```
Planning (CRP schedules tentatively)
   ↕
SFC: terminals + operation status + auto-advance + live dashboard
   ↕  reads Routing (the defined sequence)
   ↕  writes Confirmation (actual completion)
Execution (Confirmation, GR — the engine)
```

**Key clarification (do not confuse SFC with Routing):**
- **Routing** = the *defined* sequence; static master data (from file 01).
- **SFC** = the *real-time execution* of that sequence. It *uses* Routing to know "what is the next operation" and dispatches the order to that department's terminal.

The execution engine **already exists** (Confirmation, Routing, `Order_Operation` status). What SFC **adds** is:
1. the real-time interface,
2. the automatic advance between terminals,
3. live monitoring.

## 5.2 The Core Mechanism

```
Each department          = a Work Center Terminal (a screen).
Worker closes a stage    = Operation Confirmation (engine exists).
Order moves to next stage= Routing Step Advance (auto).
Everyone sees status live = Real-time Shop Floor Monitoring.
```

### Walkthrough (example routing: Press → Deflash → Sand → Grade)

```
WO-001 routing: Press → Deflash → Sand → Grade

[Press terminal] incoming: WO-001
  worker taps [Start] → operation[10].status = InProgress, actual_start = now
  worker taps [Done]  → record qty; operation[10].status = Completed
       system reads Routing → next op = Deflash
       operation[20].status = Ready ; notify Deflash terminal
[Deflash terminal] WO-001 appears automatically ← the "advance"
  ... and so on to Grading (last op) → order Completed → ready for GR
```

The "advance" = on `Done`, the system consults **Routing** for the next operation and dispatches the order to the responsible department's terminal automatically.

Operation numbers in the example increment by 10 (operation[10], [20], [30] …) — the conventional routing step numbering.

## 5.3 Key Entity — Operation Status (live)

**This entity already exists** on `Order_Operation` (defined in file 03). SFC **activates its real-time tracking** — it does not introduce a new master table.

### `Order_Operation` fields (as used by SFC)
| Field | Notes |
|---|---|
| `order_no` | the production order this operation belongs to |
| `operation_no` | step number within the routing (e.g. 10, 20, 30) |
| `work_center_id` | which work center / department executes it |
| `tool_id` | the tool/mold resource attached to this operation |
| `status` | enum ∈ { Waiting, Ready, InProgress, Completed } |
| `actual_start_time` | stamped when worker taps [Start] |
| `actual_end_time` | stamped when worker taps [Done] |
| `confirmed_by` | the worker who closed the operation |
| `quantity_completed` | quantity recorded at confirmation |

### Enum — `operation_status`
```
operation_status ∈ { Waiting, Ready, InProgress, Completed }
```
(Also declared as a master enum in `00` §0.5 / §0.2.)

Semantics:
- **Waiting** — predecessor not yet complete; the operation is not actionable on its terminal.
- **Ready** — predecessor completed; operation now appears in the terminal's incoming queue and can be Started.
- **InProgress** — worker tapped [Start]; `actual_start_time` set.
- **Completed** — worker tapped [Done]; `actual_end_time` set, confirmation recorded.

### Advance logic (pseudo-code, language-agnostic intent)
```
on tap "Done" for operation N:
  operation[N].status = Completed
  operation[N].end_time = now
  record confirmation (qty, grades, scrap) → calls Execution engine (file 03)
  next_op = routing.get_next(N)          # ← reads Routing
  if next_op:
      operation[next_op].status = Ready
      notify(next_op.work_center)        # appears on that terminal
  else:
      order.status = Completed           # last op → ready for GR
```

Bridge relationship:
- `routing.get_next(N)` — **Routing** answers "what's next?"
- **Operation Status** records "where we are."

Note: the confirmation recorded on Done carries **qty, grades, scrap** — i.e. yield as a distribution (grades A/B/C) plus a scrap quantity, consistent with the joint-products / grade-distribution rule from `00`.

## 5.4 Terminal UI (per department)

A **minimal worker-facing screen per Work Center**:

- **Incoming orders queue** — orders with status `Ready`, **sorted by priority/schedule**.
- For the **active order**: `[Start]` / `[Done]` buttons.
- **On Done**: prompt for **quantity**, **grade distribution**, **scrap + reason_code**.
- **Shows**: order no, product, target qty, **this operation only**.
- **Sequence enforcement**: an operation appears **only after the prior one is Completed**.

Design constraints for floor use:
- large touch targets,
- minimal typing,
- **offline-tolerant if possible** (sync when connected).

## 5.5 Real-time Dashboard (supervisor)

A **live board** showing each order's current operation and progress, e.g.:
```
WO-001: Sanding (Op 30) — 60% done
WO-002: Pressing (Op 10) — just started
WO-003: Waiting for press (mold busy)
```

**Live bottleneck detection:** many orders `Waiting` before a resource → that resource is the **live constraint**. This **links to CRP** (file 02) but is **real-time** (CRP is the planned/tentative view; the dashboard is the actual current view).

## 5.6 What SFC Affects — the 5 impacts

1. **Real-time visibility** — management knows exactly where each order is, no asking workers.
2. **Auto-feeds Confirmation** — each "Done" creates an **immediate confirmation** (qty + time), making cost data **live & accurate** (no end-of-day manual entry).
3. **Live bottleneck detection** — many "Waiting" before a resource exposes the current constraint.
4. **Actual operation times** — start/end per operation feeds **OEE**, routing-time refinement, and **time variances (actual vs planned)**.
5. **Sequence enforcement** — an operation can't appear before its predecessor completes → quality & process integrity.

## 5.7 Build Note

- **~80% of the logic pre-exists**: Routing defined (file 01), `Order_Operation` status present (file 03), Confirmation engine ready (file 03).
- The build is: **real-time interface + automatic terminal-to-terminal advance + live dashboard** — a layer **ON TOP of execution**, not a rebuild.
- This is the **MES-level functionality**.
- **Optional integrations for a fuller MES** (named, NOT specified here): machine data capture (IoT), **OEE computation**, barcode/RFID scanning.

---

## OEE note (what the file actually says)

OEE is **referenced twice but never defined/formulated** in this file:
- §5.6 impact #4: actual start/end times "feeds OEE."
- §5.7: OEE computation listed as an **optional** fuller-MES integration.

There is **no OEE formula, no availability/performance/quality factor definition** in this spec part. (Confirmed also a "Future phase" in `00` §0.7.) An implementer must NOT assume OEE is in scope of the SFC build — only that actual times are captured to enable a future OEE calculation.

---

## Entities / contracts this part defines or activates

- `Order_Operation` (live status surface) — reused from file 03; SFC adds real-time semantics and the four-state machine.
- **Work Center Terminal** (a screen/UI per Work Center) — new UI surface keyed by `work_center_id`.
- **Real-time Shop Floor Monitoring / Dashboard** — supervisor live board with per-order current-operation + progress %.
- **Auto-advance contract**: on Done → record confirmation (calls Execution engine, file 03) → `routing.get_next(N)` (reads Routing, file 01) → set next op `Ready` + notify its work center, OR mark order `Completed`.
- **Confirmation capture contract** at terminal: `{ quantity, grade_distribution, scrap_qty, scrap_reason_code, confirmed_by, actual_start_time, actual_end_time }`.

## Explicitly "expects from ERP" (dependencies SFC consumes, does not build)

1. **Routing** master data with an ordered sequence and a `get_next(operation_no)` lookup (file 01 / Master Data).
2. **`Order_Operation`** records pre-generated per production order with `work_center_id`, `tool_id`, and `operation_no` (file 03 / Execution).
3. **Confirmation engine** (file 03) to receive each Done event and post qty/time + the implied GL/inventory side-effects (file 03 + `00` §0.4 rule 6: every actual event posts an accounting entry).
4. **Work Center** master records (file 01) so each terminal maps to a department.
5. **CRP** (file 02) for the planned-capacity view that the live bottleneck view contrasts against.
6. **Goods Receipt (GR)** trigger when the last operation completes and order status flips to Completed (file 03).
7. **Priority/schedule** data on orders to sort the Ready queue (from Planning).
8. **Notification mechanism** to push a Ready order onto the next work center's terminal in real time.
</content>
</invoke>