# 02 — Planning Layer

> The brain. Translates expected/actual demand into a concrete, feasible production plan. Inherits all rules from `00`. Three sequential components: **MPS → MRP → CRP**, with a closed feedback loop.

---

## 2.1 The Three Outputs of Planning

Planning, as a whole, produces exactly three deliverables. Keep these as the mental model:

```
Output 1: Can we accept the order? By when can we deliver?   (MPS + CTP)
Output 2: Material schedule — what to buy/make, how much, when (MRP)
Output 3: Detailed production plan — when each stage starts    (MRP draft + CRP confirm)
```

Inputs: customer order, master data (BOM/Routing/WC), current inventory, item settings, material ownership.

---

## 2.2 Component: MPS (Master Production Schedule)

**Purpose:** Decides what to produce, how much, when. Under make-to-order it shifts from "forecaster" to "order translator + acceptance/capacity checker."

### Behaviour branches by `production_type`
```
if MakeToStock:
    demand = apply_forecast_consumption(forecast, actual_orders)
    PAB[t] = PAB[t-1] + planned_production[t] - demand
    if PAB[t] < safety_stock: suggest production
if MakeToOrder:
    ignore forecast; planned_production = confirmed_orders; safety_stock = 0
    run CTP check (capacity-based promise)
if AssembleToOrder:
    components → MakeToStock; finished assembly → MakeToOrder
if TollManufacturing:
    plan capacity only (material is customer's, see 2.3)
```

### Core formula — PAB (Projected Available Balance)
```
PAB[t] = PAB[t-1] + scheduled_production[t] - demand[t]
demand[t] = (see forecast_consumption + time_fence rules below)
```

### Forecast Consumption (avoid double-counting)
Actual orders **consume** the forecast, they don't add to it:
```
consumed = MIN(actual_orders[t], forecast[t])
remaining_forecast = forecast[t] - consumed
total_demand[t] = actual_orders[t] + remaining_forecast
if actual_orders[t] > forecast[t]: total_demand[t] = actual_orders[t]
```
Config: `forecast_consumption_method ∈ {None, Backward, Forward, Both}`, `consumption_window`.

### Time Fences (state by distance from today)
```
distance = t - today
if distance <= DTF (Demand Time Fence):   zone=FROZEN  → demand = actual_orders only (ignore forecast)
elif distance <= PTF (Planning Time Fence): zone=SLUSHY → MAX/consumption blend, changes need approval
else:                                       zone=LIQUID → demand = forecast (no orders yet)
```
Prevents "system nervousness": near-term plan is stable, far-term is flexible.

### CTP (Capable to Promise) — core of make-to-order
```
CTP_Check(product P, qty Q, due D):
    for op in routing(P):
        if op.wc is PRESS-like:
            cycles = Q / op.cavity_count
            load[wc] += cycles × op.cycle_time + op.setup_time
        else:
            load[wc] += Q × op.run_time + op.setup_time
    for wc in required: earliest[wc] = find_earliest_slot(wc, load[wc])
    promised = MAX(earliest[wc])           # bottleneck决定
    return promised <= D ? "on time" : ("earliest: " + promised)
```

### Order splitting & batching (Many-to-Many)
- Large order → multiple **delivery schedules** (e.g. monthly).
- Multiple similar orders → ONE production order (reduce setup/mold changes).
- Links recorded in **Pegging** table (see 06).
```
Pegging: { production_order_id, sales_order_id, allocated_quantity }
```

### MPS data model
```
MPS_Header: { id, plan_name, plant_id, time_bucket∈{Day,Week,Month},
              start_date, end_date, frozen_fence, slushy_fence, status }
MPS_Line:   { product_id, period_date, forecast_qty, confirmed_orders_qty,
              planned_production, projected_balance, safety_stock_target,
              available_to_promise }
```

### ATP calculation (3 modes — config)
```
Discrete:   ATP[t] = production[t] - orders until next production
Cumulative: ATP[t] = Σproduction≤t - Σorders≤t
Look-ahead: ATP[t] = production[t] - orders(t .. next production)   ← safest
```

---

## 2.3 Component: MRP (Material Requirements Planning)

**Purpose:** Turn production orders into material needs: what to buy/make, how much, when. It is a **process**, not a table — produces transient Planned Orders.

### Item MRP settings
```
Item_MRP_Settings: {
  item_id, mrp_type∈{Planned,ReorderPoint,NoPlanning},
  procurement_type∈{Buy,Make}, material_ownership∈{Own,Customer},
  lot_sizing_rule∈{Exact,Fixed,MinMax,EOQ,PeriodOrder}, lot_size, min_lot, max_lot,
  safety_stock, lead_time_days, reorder_point
}
```

### Algorithm (level-by-level, top to deepest)
```
MRP_Run():
  sort items by BOM level (finished=0, raw=deepest)
  for each item, for each period t:
    Gross[t]     = MPS_demand (finished) + dependent_demand_from_parents (component)
    Available[t] = on_hand + open_POs[t] + open_WOs[t] - reserved[t]
    Net[t]       = MAX(0, Gross[t] - Available[t] + safety_stock)
    Order_Qty    = apply_lot_sizing(Net[t], lot_rule)
    Release_Date = Required_Date - lead_time
    if procurement_type == Make:
        explode_BOM → dependent demand for components → recurse deeper
```

### BOM Explosion (recursive, multi-level)
```
explode_BOM(product P, qty Q):
  for line in BOM(P):
    required = Q × line.quantity × (1 + line.scrap_pct)
    dependent_demand[line.component] += required
    if line.component.procurement_type == Make:
        explode_BOM(line.component, required)
```

### Lot Sizing (key branch for tooling factories)
```
apply_lot_sizing(net, rule):
  Exact:       net
  Fixed:       round_up(net, lot_size)
  MinMax:      clamp(net, min, max)
  EOQ:         economic_order_qty()
  PeriodOrder: Σ net over several periods   ← consolidate to cut setup/mold changes
```
Tooling-heavy items use `PeriodOrder`/`Fixed` to batch demand and minimize mold mounts.

### Toll manufacturing branch
```
when generating purchase for a component:
  if component.material_ownership == Customer:
      DO NOT raise purchase order   (customer supplies it)
      instead: verify customer-supplied quantity is sufficient; if short → alert
  else:
      raise normal purchase order
```

### Outputs
```
- Planned Purchase Orders   → Procurement module
- Planned Production Orders → Execution layer
- Exception Messages        → "will be late", "reschedule in/out", "cancel"
```

---

## 2.4 Component: CRP (Capacity Requirements Planning)

**Purpose:** MRP plans assuming infinite capacity. CRP injects reality — verifies work centers (and tools, and labor) have enough capacity at the required time. **In tooling factories, CRP matters more than MRP** (materials are easy; scheduling N tools on M machines is the real problem).

### Algorithm
```
CRP_Run():
  # 1. Load per planned order
  for order, op:
    if op.wc is PRESS-like:
      cycles = order.qty / op.cavity_count
      load = cycles × op.cycle_time + op.setup_time
    else:
      load = order.qty × op.run_time + op.setup_time
  # 2. Distribute over periods → 3. Aggregate per resource
  Total_Load[resource, period] = Σ loads
  # 4. Compare
  Util = Total_Load / effective_capacity × 100
  Util > 100 → OVERLOAD ; Util < 70 → UNDERLOAD ; else OK
  # 5. Resolve overload
  → reschedule / overtime / extra shift / defer order / use multi-cavity tool
```

### Resource intersection (Machine + Tool + Labor)
```
earliest_start = MAX(machine_free_time, tool_free_time, labor_free_time)
```
The binding constraint is the **minimum-availability** resource. A tool is a movable resource that must be tracked across machines.

### RCCP vs CRP (both supported)
```
RCCP (Rough Cut): on MPS, critical resources only → used by CTP for order acceptance
CRP  (Detailed):  on MRP, all resources → used for detailed scheduling
```

### Melamine test case
```
WC-PRESS week3 capacity 90h. Order 6000 dishes, mold cavity=1, cycle 80s → 133h.
Util=148% → OVERLOAD. Resolution options surfaced, including:
  use 4-cavity mold variant → 6000/4 ×80s = 33h ✓
This links a scheduling decision (CRP) to a master-data choice (which mold).
```

---

## 2.5 Known Gap — Detailed Scheduling (APS)

CRP detects overload but does NOT sequence operations hour-by-hour on specific machines. A future **Advanced Planning & Scheduling (APS)** component should:
- Sequence operations on each machine/tool on a timeline (Gantt).
- Optimize mold-mount order to minimize changeovers (the hardest problem: ~50 molds on ~4 presses).
- Respect machine warm-up, shift patterns, tool availability.

Interface: consumes Planned Orders + Routing + Resource calendars; emits a time-phased schedule that SFC (file 05) executes.

---

## 2.6 Closed Loop

```
CRP finds conflict → feeds back to MPS → adjusts promised_date → re-runs
Costing variances (file 04) → inform standards & future planning
```