ESCA

PDF výstup jídelníčku na týden

Systém vygeneruje tisknutelný PDF dokument s jídelníčkem na daný týden. PDF bude obsahovat:

• Tabulku s chody pro každý den (přesnídávka, polévka, oběd, svačina)
• Alergeny u každého jídla
• Tématickou grafiku/ilustraci relevantní k danému týdnu (roční období, svátky, téma jídelníčku)
• Logo a kontaktní údaje jídelny
• Poznámku o výběru nápojů a dostupnosti pitné vody

Inspirace: Viz formát jídelníčku MŠ Holandská Znojmo (velikonoční téma, barevné chody).

PWA s notifikacemi a TODO listy pro vedoucí jídelny

Aplikace bude fungovat jako Progressive Web App (instalovatelná na mobil/tablet) a bude aktivně upozorňovat vedoucí jídelny na úkoly, které má splnit.

Push notifikace

• Upozornění na úkoly vázané na konkrétní čas (např. „8:00 — Opsat ranní docházku")
• Připomenutí nesplněných denních úkolů
• Upozornění na blížící se termíny týdenních/měsíčních úkolů
• Notifikace o změnách v dodávkách nebo cenách surovin (napojení na solver)

TODO listy — víceúrovňový systém

Úkoly se dělí podle periody a vázanosti na čas:

• Denní TODO — opakující se každý pracovní den (opsat docházku, zkontrolovat příjem zboží, zapsat teploty HACCP, uzavřít denní výdej)
• Časově vázané úkoly — konkrétní hodina v rámci dne (např. 6:30 kontrola teplot lednic, 10:00 uzávěrka objednávek, 11:30 kontrola teploty jídla)
• Týdenní TODO — úkoly splnitelné kdykoli během týdne (inventura skladu, objednávka u dodavatele, kontrola expiračních dat)
• Měsíční TODO — uzávěrky a reporty (uzávěrka spotřebního koše, finanční report stravného, hlášení pro zřizovatele)

Chování TODO listu

• Každý den se generuje čerstvý denní TODO list z šablony + aktuálních podmínek
• Vedoucí odškrtává splněné úkoly — systém loguje čas splnění (audit trail)
• Nesplněné úkoly se eskalují (barevné zvýraznění, opakovaná notifikace)
• Dashboard ukazuje souhrnný stav: „5/8 denních úkolů splněno, 2 týdenní zbývají"
• Některé úkoly mohou být automaticky splněny systémem (např. „docházka opsána" po importu dat)

Technické požadavky PWA

• Service Worker pro offline funkčnost a push notifikace
• Web App Manifest pro instalaci na home screen
• Offline-first: TODO list funguje i bez připojení, synchronizace po reconnectu

Variabilita jídelníčků napříč měsíci — „anti-monotónnost"

Solver nesmí při neměnných podmínkách generovat opakovaně identický jídelníček. Musí zohledňovat historii předchozích období a aktivně střídat recepty tak, aby se během školního roku vystřídaly všechny dostupné recepty z databáze.

Problém

Pokud se nezmění vstupní podmínky (ceny surovin, ruční zámky, docházka), deterministický solver najde vždy totéž optimální řešení. Výsledkem by byl identický jídelníček každých 14–20 dnů, což je pro děti i rodiče nepřijatelné.

Řešení

• Historie jako vstup do solveru — solver při generování nového měsíce dostane jako Problem Fact historii receptur z předchozích 1–2 měsíců. Soft constraint penalizuje receptury, které byly nedávno použity (čím čerstvější použití, tím vyšší penalizace).
• Pokrytí celé databáze (Coverage Score) — soft constraint odměňuje použití receptur, které nebyly v posledních N měsících vůbec nasazeny. Cíl: během školního roku (10 měsíců) projít co nejvíce receptur z databáze.
• Sezónnost — recepty mohou mít příznak sezónnosti (jaro/léto/podzim/zima). Solver preferuje sezónně relevantní recepty a penalizuje „letní" jídla v zimě a naopak.
• Random seed — při stejných podmínkách použít odlišný random seed pro metaheuristiku, aby solver prozkoumával jiné větve stavového prostoru.

Constraint model

• Soft: „Čerstvost receptury" — penalizace = f(počet dnů od posledního použití). Recept použitý minulý týden = vysoká penalizace, před 2 měsíci = nízká, nikdy = bonus.
• Soft: „Pokrytí databáze" — na konci školního roku by měl být počet nikdy-nepoužitých receptur blízko nule. Reward za každý unikátní recept v plánu, který nebyl v historii.
• Soft: „Sezónní shoda" — penalizace za nesezónní recepty.

Datový model

• Entita HistorieReceptury — (recepturaId, datum posledního použití, počet použití v aktuálním školním roce)
• Atribut Receptura.sezona — bitmask nebo Set<Sezona> (JARO, LETO, PODZIM, ZIMA, CELOROCNE)
• Problem Fact AktualniSezona — odvozená z kalendářního měsíce

Duální názvy receptur — kuchařský a dětský

Každá receptura bude mít dva názvy:

• Kuchařský název — technický, jednoznačný, pro interní plánování a kuchařky (např. „Treska zapékaná se sýrem, bramborová kaše, salát mrkvový")
• Dětský/rodičovský název — kreativní, pro tisk jídelníčku a komunikaci s rodiči (např. „Aljašská treska na mandlích, brambor s máslem, salát mrkvový s ananasem")

Inspirace: MŠ Dělnická Znojmo používá kreativní názvy jako „Drvoštěpova tvarohová pomazánka" nebo „Krůtí jarní závitek". Tyto názvy jsou atraktivní pro rodiče, ale pro plánování a normování potřebujeme jednoznačnou identifikaci.

Podkategorie alergenů

Systém bude rozlišovat nejen hlavní alergenové skupiny, ale i jejich podkategorie dle legislativy:

• 01 Obiloviny obsahující lepek → 1A Pšenice, 1B Žito, 1C Ječmen, 1D Oves, 1E Špalda
• 08 Ořechy → 8A Mandle, 8B Lískové, 8C Vlašské, 8D Kešu, 8E Pekanové, 8F Pistácie

Podkategorie jsou důležité pro přesné dietní omezení — dítě s alergií na pšenici (1A) může tolerovat špaldu (1E). Aktuální praxe MŠ Dělnická Znojmo již tyto podkategorie používá.

Rozpočet per chod s legislativním rozmezím

Finanční limit stravného není jedno číslo, ale rozmezí per chod definované vyhláškou 107/2005 Sb., příloha č. 2. Konkrétní částky stanovuje ředitel školy v rámci rozmezí.

Reálné ceny MŠ Holandská Znojmo

Legislativní rozmezí (vyhl. 107/2005, příloha 2)

• Děti 3–6 let: přesnídávka 8–15 Kč, oběd 17–36 Kč, svačina 8–15 Kč, celkem 57–114 Kč
• Děti 7 let: přesnídávka 9–20 Kč, oběd 20–47 Kč, svačina 8–16 Kč, celkem 65–141 Kč

Požadavek: Solver musí respektovat rozpočet per chod (ne jen celkový denní). Polévka je součástí rozpočtu na oběd.

Přihlašování a odhlašování stravy

Systém musí podporovat online přihlašování/odhlašování stravy s automatickým dopadem na plánování.

• Termín odhlášení: den předem do 13:00 (aktuální pravidlo MŠ Holandská)
• Kanály: aplikace (primární), e-mail, osobně, telefon (fallback)
• První den nemoci: dotovaný oběd lze vyzvednout do jídlonosiče (výdej 11:00–11:30)
• Neodhlášená strava: účtována v plné výši (104 Kč děti do 6, 107 Kč od 7 let)
• Dopad na solver: po ranní uzávěrce docházky přepočet denních norem (vážený průměr dle skutečné docházky)

Platby a fakturace stravného

• Platba bezhotovostně k 25. dni předchozího měsíce na účet jídelny
• Systém generuje měsíční předpis stravného dle přihlášených dnů
• Automatické vyúčtování (odhlášené dny → přeplatek → převod do dalšího měsíce)
• Upozornění na nezaplacené stravné (návaznost na PRD-002 notifikace)
• Plná cena při neodhlášení (automatický přepočet)

Dietní stravování

Systém musí podporovat dietní stravování dle § 2 odst. 4 a 5 vyhlášky 107/2005 Sb.

• Evidence dětí s dietou (potvrzení odborného lékaře)
• MŠ Holandská řeší diety externě — obědy z partnerské jídelny (Přemyslovců 8, Znojmo)
• V budoucnu: solver generuje alternativní menu pro dietní skupinu paralelně s hlavním
• Constraint: pokud má X % dětí bezlepkovou dietu, alespoň N jídel v měsíci musí být přirozeně bezlepkových

Dynamická cena receptury — sklad, objednávky, odhady

Cena receptury není konstanta. Mění se v čase podle aktuálního stavu skladu a dodavatelských cen. Solver musí pracovat s nejlepším dostupným odhadem ceny v daném okamžiku.

Tři úrovně ceny suroviny

1. Skladová cena — vážený průměr nákupních cen ze skladových karet (šarží). Např. brambory: 50 kg za 18 Kč/kg + 30 kg za 22 Kč/kg → průměr 19,5 Kč/kg. Toto je nejpřesnější cena pro suroviny, které na skladě jsou.
2. Smluvní / odhadovaná cena — pro suroviny, které je třeba dokoupit. Zdroje: smluvní ceník od dodavatele, poslední nákupní cena, manuální odhad vedoucí.
3. Normativní cena — orientační cena z recepturního systému. Nejméně přesná, používá se jen při plánování bez skladových dat (demo mód, nová jídelna).

Výpočet ceny receptury

cena_receptury = Σ (gramáž × cena_suroviny × počet_porcí)

cena_suroviny =
  pokud sklad ≥ potřeba → průměrná_nákupní_cena_ze_skladu
  pokud sklad < potřeba → mix (sklad × sklad_cena + dokup × odhad_cena)
  pokud sklad = 0 → odhadovaná_cena (poslední nákup / smlouva)

Continuous Planning — reakce na změnu cen

• Příjem dodávky → OCR dodacího listu → aktualizace skladové ceny → event do SolverManageru
• Solver na pozadí přepočítá finanční constraint. Pokud zdražení narušuje rozpočet, automaticky zamění dražší receptury v budoucích (neuvařených, nezamčených) dnech za levnější alternativy.
• Notifikace vedoucí (PRD-002): „Brambory zdražily o 15 %. Solver upravil jídelníček ve dnech 12, 15 a 18."

Životní cyklus jídelníčku a uzavření

Jídelníček prochází fázemi s odlišnou možností zásahu solveru:

1. Plánování (měsíc/2 týdny dopředu) — solver generuje návrh, vedoucí upravuje a kontroluje. Všechny recepty jsou volné pro optimalizaci.
2. Uzavření (typicky týden předem) — jídelníček na daný týden se zamkne, vytiskne PDF (PRD-001), roznese na nástěnky, vyvěsí na web. Od tohoto okamžiku solver nesmí měnit uzavřené dny.
3. Realizace — vaří se podle uzavřeného plánu. Přijímají se dodávky, ceny se aktualizují.
4. Vyhodnocení — konec měsíce: uzávěrka spotřebního koše a financí.

Klíčové pravidlo: solver nikdy nezmění uzavřený týden

Pokud zdraží suroviny v již uzavřeném jídelníčku, s tím se nedá nic dělat — jídelníček je vytištěný a vyvěšený. Solver musí deficit kompenzovat v budoucích, dosud neuzavřených dnech:

• Uzavřené dny = automaticky pinned (solver je přeskočí)
• Finanční constraint se počítá za celý měsíc — pokud první 2 týdny vyšly dráž, solver musí v 3. a 4. týdnu volit levnější recepty
• Pokud deficit není řešitelný (rozpočet už je nezvratně překročen), systém upozorní vedoucí a navrhne eskalaci (úprava stravného, žádost o dotaci apod.)

Datový model

• JidelnicekDen.stav — enum: PLANOVANI → UZAVRENO → REALIZOVANO → VYHODNOCENO
• Uzavření = hromadný pin celého týdne + generování PDF + publikace na web
• Solver vidí uzavřené dny jako Problem Facts (ne Planning Entities) — nemůže je měnit, ale počítá s jejich náklady pro celkový rozpočet

Dopad na demo

Aktuální demo používá úroveň 3 (normativní ceny) a nemá koncept uzavření. Produkce bude primárně pracovat s úrovní 1+2 a stavovým automatem dní.

Spotřební koš dle vyhlášky 107/2005 — legislativní gramáže a netto výpočet

Normy spotřebního koše jsou definovány jako průměrná měsíční spotřeba na strávníka a den v gramech čisté hmotnosti (netto). Nejde o porci jednoho jídla, ale o denní průměr přes celý měsíc.

Legislativní gramáže (příloha č. 1, tabulka 1) — MŠ bez snídaně

Výpočet pro jídelnu s mixem věkových skupin

denní_norma = (počet_3_6 × norma_3_6 + počet_7 × norma_7) / celkem_dětí

Příklad maso MŠ Holandská:
(146 × 47 + 14 × 56) / 160 = 47,8 g/strávník/den

Netto výpočet (novela 2025/2026)

• Brutto (starý systém) = hmotnost suroviny jak je nakoupena (vč. slupek, kostí, nejedlých částí)
• Netto (nový systém) = čistá hmotnost po očištění. Koeficienty z tabulky č. 4: brambory neočištěné ×0,8, sterilované luštěniny ×0,4, sterilovaná zelenina ×0,65 atd.
• Pokud je surovina nakoupena již očištěná (loupané brambory), koeficient = 1,0

Koeficienty pro spotřební koš (tabulka č. 2)

• Sterilovaná zelenina: ×0,65 (započítává se jen podíl pevné složky)
• Sterilované luštěniny: ×0,4
• Extrudované luštěniny: ×2,0
• Celozrnné obiloviny, luštěniny (suchý stav): ×1,0
• Sušené mléko: ×10,0

Poznámky k implementaci

• Spotřební koš se vyhodnocuje za celý měsíc, ne per den — denní výkyvy jsou OK, pokud měsíční průměr sedí
• Zaměstnanci mají vlastní normy (dospělí) — v demo zatím neřešíme
• Vyhláška definuje komodity jinak než naše demo — např. "Zelenina + ovoce" je jedna skupina, ne dvě. V produkci musíme komodity přesně namapovat
• Demo aktuálně zjednodušuje na 10 komodit; legislativa má 8 (maso, ryby, mléko+mléčné, tuky, cukry, zelenina+ovoce, brambory, obiloviny)

Konfigurovatelné typy chodů — MŠ vs. internát

Systém musí podporovat různé stravovací režimy:

• MŠ (4 chody): přesnídávka, polévka, oběd, svačina — aktuální demo
• Internát / speciální škola (6 chodů): snídaně, přesnídávka, polévka, oběd, svačina, večeře
• Pouze obědy: polévka + hlavní jídlo — pro ZŠ, SŠ

Typ chodů se konfiguruje per jídelna. Solver dynamicky vytváří odpovídající počet planning entities. Podíly na celodenním stravování se přepočítávají dle režimu.

Zdroj: Speciální školy Znojmo — 6 chodů denně vč. snídaně a večeře (lasagne, hamburger, smažený květák).

OCR digitalizace dodacích listů

Lokální open-source OCR mikroslužba pro automatickou digitalizaci papírových dodacích listů od malých dodavatelů.

• Capture: Pracovník vyfotí dodací list tabletem
• OCR: PaddleOCR (Python/FastAPI) extrahuje řádkové položky (název, množství, cena)
• Fuzzy matching: Jaro-Winkler + Levenshtein párování OCR textu na skladové karty (Kotlin)
• Human-in-the-loop: Nejisté shody → potvrzení vedoucí → systém se učí aliasy
• Re-optimalizace: Po příjmu zboží s novou cenou → event do solveru (PRD-010)

HACCP digitální logbook

Tabletová aplikace „Kitchen Companion" pro digitalizaci povinné HACCP agendy přímo v kuchyni.

• Záznam teplot: lednice, mrazáky, jádro masa (BLE Bluetooth teploměry)
• Kontrola expiračních dat
• Audit trail s časovými razítky (vyšší věrohodnost než ruční zápis)
• Offline-first: WatermelonDB/SQLite na zařízení, sync po reconnectu
• Notifikace: připomenutí měření, upozornění na odchylky

Skladové hospodářství

Kompletní evidence skladových zásob s vazbou na plánovací engine.

• Příjem: Registrace dodávky (manuálně nebo přes OCR PRD-013) → založení/aktualizace skladové karty
• Výdej: Automatický výdej dle jídelníčku (po uvaření) → snížení stavu skladu
• Šarže: FIFO výdej, sledování trvanlivosti (trvanlivostDo), upozornění na blížící se expiraci
• Průměrná nákupní cena: Vážený průměr z šarží → vstup do solveru (PRD-010)
• Solver vazba: Soft constraint preferuje receptury využívající suroviny na skladě (minimalizace food waste)

Import a sdílení receptur

Systém pro import receptur z externích zdrojů a sdílení mezi jídelnami.

• Import z PDF/webu: Strojové čtení jídelníčků z webů škol (formáty: VIS PDF, HTML, obrázky)
• Sdílení: Jídelna může publikovat svoje recepty do sdílené databáze
• Normování: Importovaný recept potřebuje doplnit gramáže a komoditní mapování
• Zdroj: V demo databázi máme 186 receptur ze 7 škol — důkaz, že import funguje

Multi-tenancy — správa více jídelen

Systém podporuje provoz více jídelen v jedné instanci.

• Každá jídelna má vlastní: parametry (strávníci, rozpočet), receptury, sklad, jídelníčky
• Sdílené: databáze surovin, legislativní normy, recepturní fond
• Uživatelské role: vedoucí jídelny, kuchařka, ředitelka, zřizovatel, rodič
• Zřizovatel (obec/kraj) vidí agregované reporty napříč jídelnami
• V demo máme data z: MŠ Holandská, MŠ Dělnická, MŠ Pražská, MŠ Nám. Republiky, MŠ Nám. Armády, MŠ Tasovice, Speciální školy Znojmo