# Historia harmonogramu — opcje implementacji

**Kontekst (2026-04-10)**  
Commit `2d8485d` zmienił DELETE w calc_engine.php na "usuń wszystkie wiersze dla WS" — przez co wiersze przeszłości (07-09/04) zostały wyczyszczone. Commit `bee8c66` dodał hybrid DELETE który chroni przeszłość od teraz, ale dana już stracona.

Pytanie: jak wyświetlać historię (co było zaplanowane/zrobione w poprzednich dniach)?

---

## Opcja 1 — Akceptuj brak historii (status quo)

Historia zaczyna się od 10/04. Od teraz `bee8c66` pilnuje żeby Calc nie kasował wierszy `< today` dla MOs z `total_made > 0`.

- ✅ Zero pracy
- ✅ Działa już teraz
- ❌ Brak wglądu w dni sprzed 10/04

---

## Opcja 2 — Backfill syntetyczny

Przy Calcu: jeśli MO ma `total_made > 0` ale brak wierszy `schedule_date < today` → oblicz `done_hrs = total_made / rate` i rozlej wstecz na dni robocze od `date_start_planned` do wczoraj wg pojemności WS.

- ✅ Widać historię nawet po wyczyszczeniu DB
- ✅ Jednorazowo uzupełnia dane po stracie
- ❌ To **szacunek**, nie rzeczywistość — nie wiadomo co faktycznie robiono której nocy

---

## Opcja 3 — Flaga `is_frozen` *(rekomendowana — jak Excel)*

Nowa kolumna `is_frozen TINYINT DEFAULT 0` w `llx_planning_schedule`.  
Wieczorny cron (lub ręczny przycisk "Freeze day") ustawia `is_frozen=1` na wszystkich wierszach `<= today`.  
Calc w DELETE pomija wiersze z `is_frozen=1`.

```sql
-- Cron SQL (uruchamiany o np. 23:59 każdego dnia):
UPDATE llx_planning_schedule
SET is_frozen = 1
WHERE schedule_date < CURDATE()
  AND is_frozen = 0;

-- Zmiana w calc_engine.php DELETE:
DELETE FROM llx_planning_schedule
WHERE fk_ws = X AND entity = Y
  AND schedule_date >= '$calcStart'
  AND is_frozen = 0;
```

- ✅ Dokładnie jak Excel — historia zablokowana, przyszłość przeliczana
- ✅ Czyste rozdzielenie plan/historia
- ✅ Nie można "przekalkulować" przeszłości — tak jak chciałeś
- ⚠ Wymaga migracji kolumny + cron lub przycisku "Zamknij dzień"

---

## Opcja 4 — Osobna tabela `planning_schedule_history`

Przed każdym DELETE Calc kopiuje wiersze `< today` do osobnej tabeli historycznej. Grid łączy obie tabele przy renderowaniu.

```sql
CREATE TABLE llx_planning_schedule_history LIKE llx_planning_schedule;
-- przed DELETE w Calcu:
INSERT IGNORE INTO llx_planning_schedule_history
  SELECT * FROM llx_planning_schedule
  WHERE fk_ws = X AND entity = Y AND schedule_date < '$calcStart';
```

- ✅ Historia bezpieczna nawet przy błędnych operacjach na głównej tabeli
- ✅ Można auditować zmiany między Calcami
- ❌ Duplikacja danych
- ❌ Bardziej złożony rendering (UNION lub JOIN)

---

## Opcja 5 — Kolumna `actual_hours`

Calc zapisuje tylko `planned_hours` dla przyszłości.  
Przy zapisie optrackingu (Done++) → przelicz `actual_hours` per dzień i zaktualizuj `planning_schedule`.  
Grid pokazuje `actual_hours` dla przeszłości, `planned_hours` dla przyszłości.

- ✅ Najbardziej precyzyjne — rzeczywiste godziny produkcji
- ✅ Widać różnicę plan vs. wykonanie per dzień
- ❌ Największa zmiana — wymaga powiązania optracking → schedule
- ❌ Złożona logika rozkładania godzin na dni

---

## Decyzja

- [ ] Opcja 1 (status quo)
- [ ] Opcja 2 (backfill syntetyczny)
- [x] **Opcja 3 (is_frozen) — rekomendowana**
- [ ] Opcja 4 (osobna tabela)
- [ ] Opcja 5 (actual_hours)