Prezentace: Co to vlastně děláme a jak to má fungovat?

Interní prezentace pro vývojářský tým ProfiSpis

Prosinec 2025, michal.rada@gem.cz

Dva významy pojmu spisové služby

U původců se často setkáváme s dvojím pojetím sousloví \"spisová služba\", a to v těchto dvou významech:

Spisová služba (z pohledu spisovenského) je správa a evidence všech dokumentů v organizaci a obsahuje procesy týkající se samotného spravování dokumentů a spisů jako předmětů.
Spisová služba (z pohledu úředního) je evidence spisového materiálu v úředním jednání, tedy spis k jednomu řízení či kauze a dokumenty jako podklady pro toto úřední jednání.

Tyto dva světy se prolínají. Je nicméně nutné si vždy ujasnit, když mluvíte o spisové službě, o spisech, o dokumentech, a třeba i o lhůtách, o kterém z významů se bavíte. Lhůta doručení pro spisovou službu a lhůta doručení pro úřední úkon jsou dvě odlišné věci.

Nás bude zajímat ten první význam, tedy správa všech dokumentů. Nehledě na to, že některé spisy a dokumenty jsou úředního charakteru, my se budeme soustředit na spisovou službu jako evidenci, nikoliv na spisovou dokumentaci podle Správního řádu. Nicméně i klientům se tyhle dva světy často pletou, obzvlášť pokud se bude jednat o klienta, který je úřadem (orgánem veřejné moci) a provádí činnosti i podle Správního řádu, či jiného správně-procesního předpisu.

Tři důvody existence spisové služby

Proč spisová služba existuje?

Aby byl pořádek v dokumentech, šlo je vždy rychle najít a pracovat s nimi.
Aby existovaly důkazy každé operace a manipulace s dokumenty, včetně toho, kdo a kdy ji udělal.
Aby měl původce důkazní prostředky o své práci a nezpochybnitelné prokázaní dokumentu.

Dvě věci, o kterých je spisová služba

Spisová služba je o dvou hlavních předmětech:

Spisy a dokumenty - ať už fyzické dokumenty na papíru, či digitální dokumenty v evidenci v počítači.
Metadata (údaje) o dokumentech - veškerá metadata o dokumentech, spisech a také o tom, co se s dokumenty a spisy v průběhu času dělo. —- Při každé drobnosti týkající se spisové služby se bavíme o obou těchto

Dokument versus údaj

Jako zdroj a aspekt informací řešíme dvě základní formy:

Dokument: Statický nosič informací zakotvený v určitém čase a vybavený určitou mírou důvěryhodnosti
Údaj: informace vedená v informačním systému dynamicky se měnící s definovanou mírou aktuálnosti a časového okamžiku platnosti

Dva druhy dokumentů a ESSL

Elektronická spisová služba se zabývá:

Digitálními dokumenty (všechno se vede v ESSL, a to včetně samotných souborů dokumentů)
Analogovými dokumenty (v ESSL se o nich vedou metadata a evidence, samotné dokumenty se vedou papírově)

Vždy tedy v systému dokumenty evidujeme, vedeme jejich metadata, vedeme záznamy o událostech a operacích, vytváříme a odesíláme, střednědobě ukládáme a vyřazujeme je.

Životní cyklus dokumentu podle fází a procesů

Diagram Fází a procesů spisové služby rozdělených do fází

Spisová služba podrobněji

Kdo je masochista, může si projít celou teoretickou kapitolu O spisové službě obecně Je tam třeba

Detailní popis legislativy
Jednotlivé závazné procesy spisové služby a jejich popisy
Podrobnosti k egdilna:essl

Jak by to mělo správně fungovat (na tohle asi radši nekoukejte)

Hele,tohle není pro prohloubení deprese, ale jen vysvětlení jak to má fungovat

Ryze entitní model, nepracuje se s daty, ale jen s entitami, neměnné core pak řeší datovou práci
Rozdělit do jednotlivých funkcí a eventů (event se skládá z funkcí), funkce rovnou volá další funkce a technicky zajišťuje backend
Vše je funkcemi měnitelné a proveditelné, frontendové funkce zajistí že se udělá jen to na co má uživatel či systém práva
I sám ESSL je uživatel, automatizované úlohy se dělají jeho jménem
Transakčí protokol je jen částí celkového auditního logu (viz Elektronická kniha záznamů v EIDAS)
Oddělená podatelna (distribuuje nejen do ESSL) a výpravna (odesílá nejen z ESSL)
Hlavním životním organismem je spis nikoliv dokument

Jak to můžeme dělat teď?

Možná v budoucnu najdeme prostředky na celý architektonický refactoring, nicméně teď alespoň:

dělejme úplný auditní log se vším rozdělený do událostí a k tomu TP
snažme se o entitní přístup, nepracujme přímo tvrdě s daty v tabulce, ale s entitou, zkusme backendové univerzální funkce pro práci s entitami
při jakékoliv úpravě podatelny a výpravny ji pomalu připravujme na oddělené storage a metadata a a protokoly
UI na frontendu skládejme z mikrofunkčních UI kousků pokud to jde a určitě u nových obrazovek
verzujme všechno, vždycky a pořád - nikdy nevíme kdy se to bude hodit
každá nová funkce by se měla programovat jako funkce a endpoint a UI by mělo postupně volat tyto funkce a ne řešit něco natvrdo