# DESIGN: "Planned Remaining This Week" KPI

## Current behaviour

`info_board.php` — KPI card and WS Overview column both query:

```sql
SUM(planned_hours) FROM llx_planning_schedule
WHERE schedule_date BETWEEN :activeDateThru AND :weekEnd
```

`activeDateThru` = today if shift has started, yesterday if not (so the window
always aligns with the Daily Performance table).

Result on Monday morning = **entire week's planned hours** (e.g. 99 h = FM7 32 h + LASER1 67 h).
Midweek it shrinks naturally as past days fall out of the range.

## What it does NOT do

It does **not** subtract work already performed today.

Example (Monday, 09:00):  FM7 P=8 h, A=1 h → KPI still shows 8 h for today,
not 7 h remaining.

To show "truly remaining" you would need:

```sql
SUM(ps.planned_hours)
  - COALESCE((
      SELECT SUM(ot.qty_delta / pe.qty_per_hour_form)
      FROM llx_mrp_mo_optracking ot
      JOIN llx_mrp_mo m ON m.rowid = ot.fk_mo
      JOIN llx_product_extrafields pe ON pe.fk_object = m.fk_product
      WHERE ot.fk_ws = ps.fk_ws
        AND DATE(ot.date_entry) = ps.schedule_date
    ), 0)
```

This is complex (per-WS rate field varies: form / laser / cnc) and introduces
join cost on every page load.

## Options

**Option A (current):** Keep `SUM(planned_hours)` as-is.
- Simple, fast.
- Slightly overstates remaining capacity on the current day.
- Acceptable because Daily Performance A column already shows actual output.

**Option B:** Subtract today's actual output from today's planned slice.
- Requires per-WS optracking join with correct rate field.
- More accurate "remaining work" signal.
- Higher complexity.

## Decision

Deferred. Revisit when actual vs. planned gap becomes operationally significant.
Current behaviour (Option A) is sufficient for morning board review.