SMLOUVA O DÍLO

SMLOUVA O DÍLO

č.j. R-06-1/12-2019

„Elektronická spisová služba“

uzavřená podle § 2586 a násl. zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů, a podle zákona č. 121/2000 Sb., o právu autorském (autorský zákon), ve znění pozdějších předpisů

Nemocnice Xxxxxxx a Stefanie Benešov, a.s., nemocnice Středočeského kraje

IČO 27253236

se sídlem Máchova 400, 256 01 Benešov

zastoupen XXXx. XXXXX XXXX, předseda představenstva bankovní spojení PPF banka a.s.

číslo účtu 2014310033/6000

dále také jako „objednatel“

a

ICZ a.s.

Obchodní společnost zapsaná v obchodním rejstříku vedeném městským soudem v Praze v oddílu B pod spisovou značkou 4840.

IČO 25145444

DIČ CZ699000372

se sídlem Na hřebenech II 1718/10, 140 00 Praha 4 Nusle

zastoupen Xxxxxxx Xxxxxxxxx, na základě plné moci

bankovní spojení UniCredit Bank Czech Republic and Slovakia, a.s.

číslo účtu č. účtu: 2109164825/2700

dále také jako „zhotovitel“

objednatel a zhotovitel také společně jako „smluvní strany“.

Čl. 1. Úvodní ustanovení

1.1. Tato smlouva je uzavřena na základě výsledku zadávacího řízení na veřejnou zakázku s názvem

„Elektronická spisová služba“ (dále jen „veřejná zakázka“), zadávanou objednatelem jako zadavatelem podle zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „ZVZ“).

1.2. Účelem této smlouvy je dodání kompletních dodávek a služeb k realizaci a naplnění účelu veřejné zakázky, který vyplývá ze zadávací dokumentace veřejné zakázky (dále jen „zadávací dokumentace“).

1.3. Zhotovitel touto smlouvou garantuje objednateli splnění zadání veřejné zakázky a všech z toho vyplývajících podmínek a povinností podle zadávací dokumentace. Tato garance je nadřazena ostatním podmínkám a garancím uvedeným v této smlouvě. Pro vyloučení jakýchkoliv pochybností to znamená, že:

a) v případě jakékoliv nejistoty ohledně výkladu ustanovení této smlouvy budou tato ustanovení vykládána tak, aby v co nejširší míře zohledňovala účel veřejné zakázky vyjádřený zadávací dokumentací,

b) v případě chybějících ustanovení této smlouvy budou použita dostatečně konkrétní ustanovení zadávací dokumentace.

1.4. Předmět smlouvy (dílo) je realizován z Integrovaného regionálního operačního programu „IT projekty II: Modernizace a rozvoj NIS Nemocnice Rudolfa a Stefanie Benešov a.s., nemocnice Středočeského kraje“, Výzva č. 28 „Specifické informační a komunikační systémy a infrastruktura II.“, specifický cíl 3.2 „Zvyšování efektivity a transparentnosti veřejné správy prostřednictvím rozvoje využití a kvality systémů IKT“, reg. číslo projektu CZ.06.3.05/0.0/0.0/16_044/0005622 (dále jen „Projekt“). Z tohoto důvodu:

a) je zhotovitel povinen minimálně do konce roku 2029 poskytovat požadované informace a dokumentaci související s realizací smlouvy zaměstnancům nebo zmocněncům pověřených orgánů (CRR, MMR ČR, MF ČR, Evropské komise, Evropského účetního dvora, Nejvyššího kontrolního úřadu, příslušného orgánu finanční správy a dalších oprávněných orgánů státní správy) a je povinen vytvořit výše uvedeným osobám podmínky k provedení kontroly vztahující se k realizaci díla a poskytnout jim při provádění kontroly součinnost;

b) zhotovitel výslovně souhlasí s tím, že objednatel je oprávněn poskytnout veškeré dokumenty související s realizací díla (včetně nabídky zhotovitele z veřejné zakázky);

c) zhotovitel je povinen uchovávat veškerou dokumentaci související s realizací díla (veřejné zakázky) včetně účetních dokladů minimálně do konce roku 2029;

d) zhotovitel je povinen spolupůsobit při výkonu finanční kontroly ve smyslu § 2 písm. e) zákona č. 320/2001 Sb., o finanční kontrole ve veřejné správě a o změně některých zákonů (zákon o finanční kontrole), ve znění pozdějších předpisů;

e) zhotovitel je povinen seznámit se s podmínkami pro čerpání předmětné dotace zveřejněné na stránkách xxxx://xxx.xxxxxxxxxxxx-xxxxx.xx/xx/Xxxxxxxxxx/XXXX/xxxxxxxxx, které musí zhotovitel splňovat v rámci dotačního programu. K plnění podmínek dotace je zhotovitel povinen poskytovat objednateli potřebnou součinnost, lze-li to po něm spravedlivě požadovat.

Čl. 2. Předmět smlouvy

2.1. Předmět plnění:

2.1.1. Předmětem plnění této smlouvy je dodávka informačního systému spisové služby včetně implementace systému a rozvoj informačního systému, integrace systému vůči externím systémům, zaškolení uživatele, vytvoření eLearning kurzu pro uživatele, dodání licencí a zpracování dokumentace pro Nemocnici Xxxxxxx a Stefanie Benešov, a.s. (dále též „NRSB“).

2.2. Předmětem díla jsou následující činnosti zhotovitele:

2.2.1. Dodávka licencí, implementace jednotlivých částí díla, testovací provoz a předání do řádného užívání.

2.2.2. Pro výše uvedený rozsah plnění:

• provedení integrací na další systémy v prostředí objednatele i mimo něj

• úprava dodaného řešení dle potřeb a požadavků dle pokynů objednatele

• zaškolení odborného personálu objednatele

2.2.3. Dále je předmětem plnění dodávka

• dokumentace k dodanému plnění v požadovaném rozsahu

• dalších licencí potřebných pro provoz jednotlivých částí díla

• listinného potvrzení dodaných licencí co do jejich počtu a rozsahu

2.2.4. Detailní předmět plnění je uveden v příloze č. 1 – Technická specifikace a příloze č. 2 -

Technická specifikace zhotovitele.

2.2.5. Předmět smlouvy rovněž obsahuje plnění, která nejsou přímo uvedena v přílohách č. 1 a č. 2 této smlouvy, ale jejichž realizace je nezbytná pro provedení díla tak, aby dílo splnilo svůj účel.

2.3. Vzdálený přístup do prostředí objednatele

2.3.1. Předmětem této smlouvy je dále i zajištění a sjednání podmínek vzdáleného přístupu zhotovitele bez aktivní účasti objednatele do prostředí objednatele za účelem plnění této smlouvy.

2.3.2. Objednatel se zavazuje, že umožní zhotoviteli vzdálený přístup k informačním systémům a aplikacím uvedeným v předmětu plnění této smlouvy nejpozději do 5 dnů ode dne uzavření této smlouvy.

Čl. 3. Doba a místo plnění

Plnění díla bude zahájeno bez odkladu po uzavření této smlouvy.

3.1. Plnění předmětu díla této smlouvy bude dokončeno jeho řádným zhotovením ze strany zhotovitele a řádnou a bezvýhradnou akceptací ze strany objednatele, a to nejpozději do 28. 6. 2019.

3.2. Závazný harmonogram plnění včetně dílčích milníků je obsažen v příloze č. 4 této smlouvy

– Harmonogram plnění.

3.3. Místem plnění díla je sídlo objednatele na adrese Máchova 400, 256 30 Benešov.

Čl. 4. Práva a povinnosti smluvních stran

4.1.1. Zhotovitel se zavazuje za podmínek stanovených touto smlouvou na svůj náklad a na své nebezpečí ve sjednaném termínu splnit celý předmět smlouvy. Zhotovitel se dále zavazuje dodat řádně a včas plnění podle této smlouvy bez právních a faktických vad.

4.1.2. Při zhotovování díla se zhotovitel zavazuje počínat si s odbornou péčí tak, aby byl zcela naplněn předmět a účel smlouvy.

4.1.3. Zhotovitel je povinen vynaložit maximální úsilí, aby docílil nejlepšího možného výsledku při plnění předmětu této smlouvy prostřednictvím využití svých znalostí a zkušeností.

4.1.4. Při provádění díla postupuje zhotovitel samostatně, je však vázán zejména písemnými pokyny objednatele. Zhotovitel je povinen bez zbytečného odkladu písemně upozornit objednatele na nevhodnost jeho pokynů k provedení díla. Pokud nevhodné pokyny brání v řádném provádění díla, je zhotovitel povinen v nezbytně nutném rozsahu přerušit provádění díla do doby změny pokynů objednatele nebo písemného sdělení, že objednatel trvá na provádění díla dle svých pokynů. V souvislosti s realizací díla po dobu takového přerušení má zhotovitel nárok na prokazatelně vynaložené náklady.

4.1.5. Zhotovitel je povinen v průběhu provádění díla dodržovat obecně závazné předpisy a normy vztahující se k prováděnému dílu a týkají se činnosti zhotovitele, postupovat s náležitou odbornou péčí, podle nejlepších znalostí a schopností, sledovat a chránit oprávněné zájmy objednatele.

4.1.6. Zhotovitel je povinen při realizaci díla dodržovat veškeré bezpečnostní předpisy, bezpečnosti práce, požární ochraně a ochraně životního prostředí a interní směrnice upravující zejména pohyb na pracovištích objednatele. Pokud porušením těchto předpisů zhotovitelem nebo jeho poddodavateli vznikne škoda, nese veškeré související náklady zhotovitel.

4.1.7. Zhotovitel je povinen v průběhu provádění díla neprodleně informovat objednatele o všech skutečnostech, které mají nebo mohou mít vliv na provedení díla.

4.1.8. Pokud objednatel zjistí, že zhotovitel provádí dílo v rozporu se svými povinnostmi, je oprávněn požadovat, aby zhotovitel odstranil v objednatelem stanovené lhůtě vzniklé vady a dílo prováděl řádným způsobem.

4.1.9. Zhotovitel se zavazuje v průběhu provádění díla postupovat v souladu se zásadami projektového řízení a zejména jejich jednotlivými konkrétními pokyny objednatele.

4.1.10. Objednatel se zavazuje řádně a včas dokončený předmět smlouvy od zhotovitele protokolárně převzít a zaplatit zhotoviteli sjednanou cenu.

4.2. Součinnost

4.2.1. Objednatel požaduje, aby maximum práce odvedl zhotovitel samostatně, bez zatěžování pracovníků objednatele. Součinnost objednatele bude omezena na nezbytnou míru a bude se vztahovat především na schvalování výstupů zhotovitele v předem definovaných kontrolních dnech a na nezbytnou IT podporu nutnou k nasazení řešení a realizaci vazeb.

4.2.2. Rozsah součinnosti bude odsouhlasen mezi smluvními stranami do 10 dnů po uzavření této smlouvy, včetně termínů jejího poskytování.

4.2.3. V případě následného požadavku zhotovitele na součinnost nad dohodnutý rámec má objednatel právo součinnost odmítnout, případně ji poskytnout v termínu a rozsahu dle svých možností, a to bez dopadu na harmonogram realizace a z něj vyplývající sankce za nedodržení termínů.

4.2.4. Neposkytnutí součinnosti jako důvod pro posun smluvních termínů bude akceptován

pouze v případě, pokud byla součinnost objednatelem přislíbena při zahájení realizace.

Čl. 5. Cena díla

5.1. Cena za zhotovení díla představuje objednatelem akceptovanou nabídkovou cenu předloženou zhotovitelem v nabídce na veřejnou zakázku.

5.2. Zhotovitel výslovně prohlašuje, že nabídková cena díla obsahuje veškeré práce a dodávky, poplatky a jiné náklady nezbytné pro řádnou a úplnou realizaci sjednaného předmětu plnění a veškeré náklady včetně všech rizik a vlivů souvisejících s plněním předmětu smlouvy.

5.3. Objednatel a zhotovitel se dohodli, že cena za řádné a včasné provedení díla

specifikovaného v čl. 2 této smlouvy činí celkem částku 2 827 891 Kč včetně DPH, přičemž cena bez DPH činí 2 337 100 Kč

sazba DPH činí 21 %

výše DPH činí 490 791 Kč

5.4. Tato cena je stanovena jako cena konečná a úplná.

5.5. Zhotovitel není oprávněn požadovat po objednateli poskytnutí zálohy.

5.6. Zhotovitel na sebe výslovně bere odpovědnost za to, že sazba a výše daně z přidané

hodnoty bude stanovena v souladu s platnými právními předpisy.

5.7. Daň z přidané hodnoty bude připočtena k ceně díla ve výši dle právní úpravy platné ke dni uskutečnění zdanitelného plnění.

5.8. Sjednaná celková cena díla dle této smlouvy je cenou nejvýše přípustnou, kterou je možné překročit pouze v případě zvýšení sazby DPH, a to tak, že zhotovitel ke sjednané ceně bez DPH připočítá DPH v procentní sazbě odpovídající zákonné úpravě účinné k datu uskutečnitelného zdanitelného plnění.

Čl. 6. Platební podmínky

6.1. Cena díla bude objednatelem uhrazena na základě zhotovitelem vystavených faktur.

6.2. Fakturu je zhotovitel oprávněn vystavit nejdříve následující den po dni uskutečnění zdanitelného plnění, jímž se pro účely této smlouvy rozumí řádná realizace předmětu díla nebo jeho části definovaného v čl. 2 této smlouvy.

6.3. Podkladem pro vystavení faktury je podepsaný protokol o předání a převzetí předmětu díla nebo jeho části (akceptační protokol).

6.4. Faktury musí obsahovat název a registrační číslo projektu Název projektu: „IT projekty II: Modernizace a rozvoj NIS Nemocnice Rudolfa a Stefanie Benešov a.s., nemocnice Středočeského kraje“, reg. číslo projektu CZ.06.3.05/0.0/0.0/16_044/0005622.

6.5. Splatnost faktur činí 30 dnů ode dne jejího prokazatelného doručení na adresu sídla

objednatele.

6.6. Faktura bude mít náležitosti daňového dokladu dle platných právních předpisů (zákona č. 563/1991 Sb., o účetnictví, v platném znění a zákona č. 235/2004 Sb., o dani z přidané hodnoty, v platném znění).

6.7. Faktura musí obsahovat označení smlouvy, číslo účtu zhotovitele a všechny údaje uvedené v § 28 odst. 2 zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů.

6.8. Součástí faktury bude specifikace dodaného plnění tak, aby byla v souladu s platnými účetními a daňovými předpisy, a to za účelem řádného vedení evidence majetku objednatele v souladu s těmito právními předpisy.

6.9. V případě, že faktura – daňový doklad nebude obsahovat stanovené náležitosti nebo v něm nebudou správně uvedené údaje, je objednatel oprávněn ji vrátit ve lhůtě splatnosti zpět zhotoviteli s uvedením chybějících náležitostí nebo nesprávných údajů. V takovém

případě se přeruší běh lhůty splatnosti a nová lhůta splatnosti počne běžet doručením opravené faktury – daňového dokladu.

6.10. Cena bude zhotoviteli zaplacena bezhotovostní formou převodem na jeho bankovní účet. Faktura je považována za proplacenou okamžikem odepsání příslušné částky z účtu objednatele ve prospěch zhotovitele.

6.11. Pro případ, že zhotovitel je, nebo se od data uzavření smlouvy do dne uskutečnění zdanitelného plnění stane, na základě rozhodnutí správce daně „nespolehlivým plátcem“ ve smyslu ustanovení § 106a zákona č. 235/2004 Sb., o DPH, ve znění pozdějších předpisů, souhlasí zhotovitel s tím, že mu objednatel uhradí cenu plnění bez DPH a DPH v příslušné výši odvede za nespolehlivého plátce přímo příslušnému správci daně. V souvislosti s tímto ujednáním nebude zhotovitel vymáhat od objednatele část z ceny plnění rovnající se výši odvedeného DPH a souhlasí s tím, že tímto bude uhrazena část jeho pohledávky, kterou má vůči objednateli, a to ve výši rovnající se výši odvedené DPH.

Čl. 7. Předání díla

7.1. Xxxxxxxxxx splní svoji povinnost zhotovit dílo řádným a včasným dokončením díla

v souladu s podmínkami této smlouvy a předáním hotového díla objednateli.

7.2. Předání a převzetí jednotlivých částí díla a díla jako celku je podmíněno provedením akceptačního řízení s výsledkem „Akceptováno bez výhrad“. Podmínky akceptačního řízení jsou podrobně uvedeny v příloze č. 5 této smlouvy – Akceptační řízení.

7.3. Objednatel prohlašuje, že převezme dokončené dílo a jeho části bez zjevných vad, nedodělků a podstatných vad bránících funkcionalitě předávaného díla. V opačném případě si objednatel vyhrazuje právo převzetí díla odmítnout, bez nároku na navýšení ceny díla.

7.4. Předání a převzetí díla proběhne na základě porovnání skutečných vlastností jednotlivých částí díla dle specifikace díla uvedené v čl. 2 této smlouvy. Plnění bude potvrzeno podpisem protokolu o předání objednatelem. Součástí protokolu o předání je jednoznačná identifikace předávaného díla a jeho částí.

7.5. Zjistí-li objednatel nedostatky, nedodělky, či vady, oznámí to písemnou formou bez zbytečného odkladu zhotoviteli.

7.6. Místem předání díla je sídlo objednatele.

7.7. Vlastnické právo k dílu přechází na objednatele okamžikem předání díla objednateli. Práva

z poskytnuté licence objednatel nabývá okamžikem převzetí díla od zhotovitele.

Čl. 8. Záruka za dílo

8.1. Zhotovitel poskytuje objednateli záruku v délce trvání 2 let. Dílo dle této smlouvy bude ke dni předání a převzetí objednatelem způsobilé k řádnému užití a bude mít vlastnosti stanovené touto smlouvou.

8.2. Zhotovitelem poskytovaná záruka se vztahuje na kompletní funkčnost díla, jakož i na jeho vlastnosti požadované objednatelem.

8.3. Záruční doba začíná běžet ode dne převzetí díla objednatelem. Záruční doba se prodlužuje o dobu, po kterou mělo dílo vadu bránící jeho řádnému užívání objednatelem, nebo po kterou bylo plnění mimo provoz z důvodu vady, na kterou se vztahuje záruka.

8.4. Veškeré zjištěné nedostatky, nedodělky a vady díla, které se vyskytnou v záruční době, je

objednatel povinen bez zbytečného odkladu písemně oznámit zhotoviteli.

8.5. Vadou díla se pro účely této smlouvy rozumí rozpor mezi sjednanými podmínkami provedení díla, jeho parametry a skutečným stavem díla.

8.6. Objednatel má vůči zhotoviteli tato práva z odpovědnosti za vady:

a) právo na bezplatné odstranění reklamovaných vad, a to bez odkladu po oznámení vady objednatelem, nejpozději ve lhůtě 15 dnů od oznámení vady objednatelem,

b) právo na poskytnutí přiměřené slevy z ceny odpovídající rozsahu reklamovaných vad či nedodělků,

c) právo na odstoupení od smlouvy, kdy vady či nedodělky jsou takového charakteru, že podstatně ztěžují či dokonce brání v užívání díla,

d) právo na zaplacení nákladů na odstranění vad v případě, kdy si objednatel vadu či nedodělek odstraní sám nebo použije třetí osoby k jejich odstranění.

8.7. Uplatněním nároků z odpovědnosti za vady není dotčeno právo na náhradu škody. Zhotovitel odpovídá objednateli za případnou škodu, která mu vznikne z titulu neodstranění vady díla zhotovitelem ve stanoveném termínu.

8.8. Záruka je poskytována v souladu s ustanovením § 2113 a násl. zákona č. 89/2012 Sb., občanský zákoník, v platném znění.

Čl. 9. Licenční ujednání

9.1.1. Zhotovitel v rámci plnění předmětu této smlouvy vytvoří dílo podléhající ochraně podle zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon), a zákona č. 89/2012 Sb., občanský zákoník, a tak poskytuje objednateli licenci - tj. oprávnění k výkonu práva užívat jím vytvořené autorské dílo.

9.2. Zhotovitel poskytuje licenci jako:

⮚ nevýhradní licenci k veškerým známým způsobům užití takového díla, zejména, xxxxxxx však výlučně k účelu, ke kterému bylo takové dílo zhotovitelem vytvořeno v souladu se smlouvou a to v rozsahu minimálně nezbytném pro řádné užívání díla objednatelem,

⮚ licenci neomezenou územím výkonu působnosti objednatele,

⮚ licenci co do rozsahu oprávněného počtu uživatelů k užívání informačního systému a jeho jednotlivých oblastí neomezenou, nestanoví-li příloha č. 2 této smlouvy jinak pro konkrétní části díla;

⮚ neomezenou způsobem nebo rozsahem užití;

⮚ licenci udělenou na dobu určitou, a to po celou dobu trvání majetkových práv k dílu;

⮚ licenci, kterou není objednatel povinen využít.

9.2.1. Povinnost týkající se licence platí pro zhotovitele i v případě zhotovení části díla

poddodavatelem.

9.2.2. Licence je poskytnutá v maximálním rozsahu povoleném platnými právními předpisy.

9.2.3. Zhotovitel je povinen zajistit, aby výsledkem jeho plnění nebo jakékoliv jeho části nebyla porušena práva třetích osob. Pro případ, že užíváním předmětu plnění nebo jeho dílčí části nebo prostou existencí předmětu plnění nebo jeho dílčí části budou v důsledku porušení povinností zhotovitele dotčena práva třetích osob, nese zhotovitel vedle odpovědnosti za takovéto vady plnění i odpovědnost za veškeré škody, které tím objednateli vzniknou.

9.3. Xxxxxxxxxx uděluje objednateli

⮚ oprávnění dílo (nebo jeho dílčí část), které podléhá ochraně podle zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon) a zákona č. 89/2012 Sb., občanský zákoník, upravovat, zpracovávat, měnit jeho název,

⮚ oprávnění dílo spojit s dílem jiným a s dílem dále pracovat za účelem jeho dalšího rozvoje a používání.

9.3.1. Objednatel a zhotovitel se výslovně dohodli, že odměna za veškerá licenční oprávnění poskytnutá objednateli je již zahrnuta v ceně za poskytnuté plnění dle této smlouvy, tj. cena za poskytnutí licence, včetně nákladů souvisejících s případnou aktualizací licence.

9.4. Licence k datům

Veškerá data zpracovávaná nejen objednatelem v informačním systému jsou daty objednatele a o nakládání s nimi rozhoduje výhradně objednatel.

Čl. 10. Odpovědnost za škodu

10.1. Smluvní strany nesou odpovědnost za způsobenou škodu v rámci platných právních předpisů a této smlouvy.

10.2. Smluvní strany se zavazují k vyvinutí maximálního úsilí k předcházení škodám a

k minimalizaci vzniklých škod.

Čl. 11. Vzdálený přístup do prostředí objednatele

11.1. Vzdálený přístup je poskytován výhradně zhotoviteli a nelze ho dále převádět na jinou osobu nebo osoby. Porušení této povinnosti bude považováno za podstatné porušení této smlouvy.

11.2. Zhotovitel se zavazuje, že vzdálený přístup k informačním systémům a aplikacím v prostředí počítačové sítě objednatele na základě této smlouvy bude využívat jen za účelem dodávky těchto informačních systémů a aplikací a poskytování služeb uvedených v této smlouvě a samostatné smlouvě o servisní podpoře k předmětnému informačnímu systému. Porušení této povinnosti bude považováno za podstatné porušení smlouvy.

11.3. Zhotovitel se zavazuje postupovat při realizaci svých práv a povinností vyplývajících z této smlouvy tak, aby v počítačové síti objednatele nezpůsobil poškození, ztrátu nebo odcizení dat. Pokud by se tak stalo, zavazuje se na vlastní náklady takto vzniklé závady odstranit v co nejkratším termínu, nejpozději však do 5 pracovních dnů.

11.4. Zhotovitel se zavazuje pro případ, že se v průběhu plnění předmětu smlouvy dostane do kontaktu s osobními údaji, že je bude ochraňovat a nakládat s nimi v plně v souladu s příslušnými právními předpisy, a to i po ukončení plnění smlouvy. Smluvní strany se v případě kontaktu s osobními údaji, ve smyslu příslušných ustanovení zákona č. 101/2000 Sb., o ochraně osobních údajů, ve znění pozdějších předpisů, zavazují uzavřít dodatek ke Smlouvě spočívající v dohodě o zpracování osobních údajů. Ochrana osobních údajů musí být zahrnuta do bezpečnostní dokumentace tak, aby nemohlo dojít k neoprávněnému nebo nahodilému přístupu k osobním údajům v systému, k jejich zneužití, změně, zničení či ztrátě.

11.5. Zhotovitel se rovněž zavazuje pro případ, že se v průběhu poskytování plnění dostane do kontaktu s údaji objednatele vyplývajícími z jeho provozní činnosti, tyto údaje žádným způsobem nezneužít, nezměnit, ani jinak nepoškodit, ztratit či znehodnotit. Zhotovitel se rovněž zavazuje provádět svoje činnosti tak, aby nebyl v nadbytečném rozsahu omezen provoz pracovišť objednatele.

11.6. Ukončení účinnosti této smlouvy z jakéhokoliv důvodu se nedotkne ustanovení tohoto článku o ochraně osobních údajů a jejich účinnost přetrvá i po ukončení účinnosti této smlouvy.

Čl. 12. Sankční ujednání

12.1. Dojde-li k prodlení s úhradou daňového dokladu - faktury, je zhotovitel oprávněn účtovat objednateli úrok z prodlení ve výši 0,05 % z dlužné částky za každý započatý den prodlení po termínu splatnosti až do doby zaplacení dlužné částky.

12.2. Nesplní-li zhotovitel svůj závazek předat dílo v termínu sjednaném touto smlouvou, je oprávněn objednatel požadovat po zhotoviteli smluvní pokutu ve výši 0,05 % ze sjednané ceny plnění dle této smlouvy za každý i započatý den prodlení, až do řádného dokončení a předání celého díla a zhotovitel je povinen takto požadovanou smluvní pokutu zaplatit.

12.3. Nesplní-li zhotovitel v dohodnutém termínu svůj závazek odstranit vady a nedodělky vytknuté při převzetí díla nebo v průběhu záruční doby, je objednatel oprávněn požadovat na zhotoviteli zaplacení smluvní pokuty ve výši 0,05 % ze sjednané ceny předmětu plnění za každý započatý den prodlení až do jejich úplného odstranění a zhotovitel se zavazuje takto požadovanou smluvní pokutu objednateli zaplatit.

12.4. Nesplní-li zhotovitel řádně podmínky projektového řízení zejména v případě zápisů ze schůzek a pracovních jednání, je objednatel oprávněn požadovat po zhotoviteli smluvní pokutu ve výši 500,- Kč za každý případ takového pochybení a to i opakovaně.

12.5. Pokud zhotovitel nesplní svůj závazek vyplývající ze vzdáleného přístupu na základě této smlouvy, zejména v oblasti odstranění vzniklých závad v souvislosti s jeho vzdáleným přístupem do počítačové sítě objednatele, zavazuje se uhradit objednateli nutné náklady spojené s uvedením počítačové sítě do původního stavu a navíc se zavazuje zaplatit smluvní pokutu ve výši 10.000,- Kč za každý zjištěný a prokázaný případ porušení povinnosti spojené se vzdáleným přístupem do počítačové sítě objednatele.

12.6. Nepředloží-li zhotovitel pojistnou smlouvu ve stanovené lhůtě, je oprávněn objednatel požadovat po zhotoviteli zaplacení smluvní pokuty ve výši 5.000,- za každý započatý den prodlení až do dne předložení pojistné smlouvy.

12.7. V případě, že v důsledku jednání zhotovitele spočívajícího v porušení jeho povinnosti chránit osobní údaje dle čl. 11 této smlouvy bude objednateli uložena sankce Úřadem na ochranu osobních údajů, vzniká objednateli nárok na smluvní pokutu ve výši 130% finanční výše sankce uložené Úřadem na ochranu osobních údajů za každý jednotlivý případ.

12.8. Zaplacením smluvní pokuty není dotčeno právo poškozené strany na náhradu vzniklé škody. Výši smluvních pokut považují obě smluvní strany shodně za přiměřené.

12.9. Základem pro výpočet smluvní pokuty je na základě dohody smluvních stran cena v Kč bez DPH.

12.10. Smluvní pokuty a úroky z prodlení podle tohoto článku jsou splatné do 30 dnů ode dne doručení jejich vyúčtování.

12.11. Smluvní pokutu je objednatel oprávněn započíst formou jednostranného zápočtu proti jakékoliv pohledávce zhotovitele za objednatelem z titulu úhrady ceny plnění dle této smlouvy, kterou zhotovitel uplatnil nebo uplatní vystavením faktury.

Čl. 13. Ukončení smlouvy

13.1. Tuto smlouvu lze ukončit dohodou smluvních stran. Dohoda o ukončení smluvního vztahu musí být písemná.

13.2. Od této smlouvy lze odstoupit v případě podstatného porušení povinnosti jednou ze smluvních stran, jestliže je takové porušení povinnosti označeno za podstatné touto smlouvou nebo občanským zákoníkem. Odstoupení od smlouvy je účinné dnem doručení písemného oznámení o odstoupení druhé smluvní straně.

13.3. Smluvní strany se dohodly, že za podstatné porušení této smlouvy ze strany zhotovitele považují:

a) dodání nebo zhotovení vadného předmětu plnění,

b) prodlení s plněním závazku vyplývajícího z této smlouvy po dobu delší než třicet (30) dní a nezjednání nápravy ani do patnácti (15) dní od doručení oznámení objednatele o prodlení s plněním závazku.

13.4. Smluvní strany se dohodly, že za podstatné porušení této smlouvy ze strany objednatele považují prodlení se zaplacením vyfakturované ceny díla delší než třicet (30) kalendářních dnů.

13.5. Porušení jakékoliv jiné povinnosti objednatele nebo zhotovitele, vyplývající z této smlouvy, je třeba splnit v dodatečné přiměřené lhůtě k tomu poskytnuté.

13.6. Odstoupením od této smlouvy nejsou dotčena ustanovení smlouvy týkající se licencí, záruk, nároků z odpovědnosti za vady, nároky z odpovědnosti za škodu (škoda může spočívat i v nákladech vynaložených objednatelem na realizaci nového zadávacího řízení) a nároky ze smluvních pokut, ustanovení o ochraně informací, ani další ustanovení a nároky, z jejichž povahy vyplývá, že mají trvat i po zániku účinnosti této smlouvy.

13.7. V případě odstoupení od smlouvy tato zaniká ke dni doručení odstoupení druhé smluvní straně. Smluvní strany si vrátí již poskytnutá plnění, není-li touto smlouvou stanoveno jinak. Objednatel má právo rozhodnout, zda si ponechá rozpracované dílo nebo jeho část.

V případě, že si objednatel rozpracované dílo nebo jeho část ponechá, má zhotovitel nárok na poměrnou část ceny odpovídající poměrné části zhotoveného díla, kterou si objednatel ponechá. V případě, že objednatel nebude mít zájem ponechat si rozpracované plnění, má zhotovitel, nebude-li se jednat o odstoupení od smlouvy z důvodu porušení povinností zhotovitele, nárok na náhradu účelně vynaložených nákladů na provedení daného plnění do doby doručení odstoupení od smlouvy, výše náhrady těchto nákladů však nesmí být vyšší, než by byla 1/2 výše ceny předmětného plnění ponížená dle předchozí věty.

13.8. Smlouvu lze také ukončit písemnou dohodou smluvních stran k dohodnutému datu s tím, že v dohodě bude rovněž řešeno vypořádání smluvních stran.

Čl. 14. Ostatní ustanovení

14.1. Práva a povinnosti smluvních stran v této smlouvě výslovně neupravené a z ní vyplývající nebo s ní související se řídí zákonem č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů a zákonem č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon), ve znění pozdějších předpisů.

14.2. V případě zjištění rozporu technické specifikace objednatele (zadavatele) uvedené v příloze č. 1 a technické specifikace zhotovitele (technického řešení) uvedené v příloze č. 2 se uplatní, není-li uvedeno v této smlouvě jinak, technická specifikace objednatele tj. příloha č. 1 – Technická specifikace.

14.3. Pokud jakýkoli závazek dle smlouvy nebo kterékoli ustanovení smlouvy je nebo se stane neplatným či nevymahatelným, nebude to mít vliv na platnost a vymahatelnost ostatních závazků a ustanovení dle smlouvy a smluvní strany se zavazují takovýto neplatný nebo nevymahatelný závazek či ustanovení nahradit novým, platným a vymahatelným závazkem, nebo ustanovením, jehož předmět bude nejlépe odpovídat předmětu a ekonomickému účelu.

14.4. Zhotovitel se zavazuje udržovat v platnosti a účinnosti po celou dobu účinnosti této smlouvy pojistnou smlouvu, jejímž předmětem je pojištění odpovědnosti za škodu způsobenou zhotovitelem třetí osobě, a to tak, že limit pojistného plnění vyplývající z pojistné smlouvy, nesmí být nižší než 1.000.000,- Kč. Zhotovitel je povinen objednateli takovou smlouvu (případně pojistný certifikát) předložit do 14 dnů ode dne uzavření této smlouvy.

14.5. Objednatel má právo přesvědčit se kdykoliv v průběhu plnění díla o stavu prací na díle včetně kontroly jakosti díla nebo jeho částí a zhotovitel mu k tomuto musí vytvořit podmínky, přičemž případné náklady nese zhotovitel.

14.6. Zhotovitel je povinen bez zbytečného odkladu písemně informovat objednatele

o skutečnostech, které mají nebo mohou mít vliv na plnění smlouvy.

14.7. Zhotovitel je povinen všechny písemné zprávy, písemné výstupy a prezentace (včetně prováděcího projektu a předávacích protokolů) opatřit povinnou vizuální identitou projektu, je-li tato vyžadována pravidly dotace. Zhotovitel prohlašuje, že ke dni uzavření smlouvy je s těmito pravidly seznámen.

14.8. Minimálně dva členové realizačního týmu zhotovitele se musí zúčastnit pravidelných kontrolních dní v sídle objednatele dle pokynu objednatele, které budou probíhat minimálně jednou za měsíc ode dne, kdy smlouva nabude účinnosti. Objednatel může dle aktuální potřeby frekvenci konání těchto kontrolních dní upravit.

14.9. Zhotovitel je povinen účastnit se na základě pozvánky objednatele všech jednání týkajících se předmětu smlouvy, řídit se při provádění plnění dle této smlouvy jeho pokyny a poskytnout mu požadovanou dokumentaci. Účast na těchto jednáních není považována za technickou podporu, údržbu, poradenství ani konzultaci a zhotoviteli za takové jednání nenáleží odměna.

14.10. Zhotovitel je povinen z každého jednání či kontrolního dne týkajícího se plnění předmětu smlouvy vyhotovit zápis o průběhu a závěrech jednání či kontrolního dne, který bude poté ve formátu *.DOC nebo *.DOCX předán objednateli k odsouhlasení a následně podepsán zástupci objednatele i zhotovitele. Každý ze zápisů bude obsahovat minimálně tyto náležitosti: pořadové číslo zápisu, datum konání, místo konání, seznam přítomných či omluvených účastníků, program jednání, popis sjednaných úkolů, závěrů z jednání či kontrolního dne a popis splnění úkolů ujednaných na předchozím jednání či předchozím kontrolním dni. Každý ze zápisů bude dále obsahovat název projektu, registrační číslo projektu a prvky povinné publicity.

14.11. Objednatel je povinen ve smyslu zákona o registru smluv a ZVZ uveřejnit text smlouvy uzavřené se zhotovitelem, včetně jejích příloh, případných změn a dodatků a dále skutečně uhrazenou cenu. Zhotovitel s uveřejněním souhlasí v plném rozsahu. Souhlas zhotovitele se vztahuje také na uveřejnění předmětných dokumentů a informací objednatelem podle zákona č. 106/1999 Sb., o svobodném přístupu k informacím, ve znění pozdějších předpisů.

14.12. Zhotovitel se zavazuje v případě potřeby spolupracovat se stávajícími dodavateli informačních systémů objednatele, a to tak, aby došlo k bezproblémové migraci databází, resp. nezávadovému přechodu na informační systém, který je předmětem díla dle této smlouvy a nebyl tak jakýmkoliv způsobem ohrožen běžný provoz objednatele.

14.13. Xxxxxxxxxx se zavazuje, že nezastaví pohledávky, které bude mít vůči objednavateli z tohoto smluvního vztahu a ani s nimi nebude manipulovat jiným způsobem. Pokud by zhotovitel porušil tento svůj závazek, bude tato skutečnost posuzována jako závažné porušení této smlouvy zhotovitelem a objednatel má právo od smlouvy odstoupit. Za porušení závazku zhotovitele uvedeného ve větě první je objednatel oprávněn zhotoviteli vyúčtovat smluvní pokutu ve výši 50.000 Kč. Smluvní pokuta se nezapočítává na náhradu škody.

14.14. Nebude-li jakákoli sporná záležitost vyřešena do šedesáti (60) dnů ode dne doručení výzvy k smírnému vyřešení sporu zaslané kteroukoliv smluvní stranou druhé smluvní straně, bude tento spor rozhodován s konečnou platností u příslušného obecného soudu České republiky.

Čl. 15. Bankovní záruka

15.1. Objednatel požaduje poskytnutí bankovní záruky ze strany zhotovitele za kvalitu provedení díla, za řádné provádění následných služeb poskytování servisní podpory a na plnění smluvních podmínek k odstraňování záručních vad včetně řádné úhrady případných smluvních pokut.

15.2. Bankovní záruku doloží zhotovitel objednateli originálem záruční listiny vystavené oprávněným peněžním ústavem ve prospěch objednatele jako oprávněného. Bankovní záruka musí být vystavena jako neodvolatelná a bezpodmínečná, přičemž vystavitel bankovní záruky se zaváže k plnění bez námitek a na základě první výzvy oprávněného (objednatele).

Bankovní záruka musí splňovat tyto podmínky:

a) výše zajištěné částky 100.000,- Kč,

b) záruční listinu předá zhotovitel objednateli nejpozději do 14ti dnů ode dne podpisu této

smlouvy,

c) bankovní záruka bude platná nejméně po dobu pěti let ode dne předání díla,

d) právo z bankovní záruky bude objednatel oprávněn uplatnit v případech, že zhotovitel neuhradí objednateli způsobenou škodu či smluvní pokutu, k níž je podle smlouvy povinen, neodstraní vadu díla způsobem a v době, k nimž je podle příslušných ustanovení smlouvy o odstraňování vad v záruční době povinen.

15.3. Objednatel je oprávněn využít prostředků zajištěných bankovní zárukou ve výši, která odpovídá výši splatné smluvní pokuty, jakéhokoli neuspokojeného závazku zhotovitele vůči objednateli, nákladů nezbytných k odstranění vad díla, škod způsobených plněním zhotovitele v rozporu se smlouvou, nebo jakékoli částce, která podle mínění objednatele odpovídá náhradě vadného plnění zhotovitele.

15.4. Před uplatněním plnění z bankovní záruky oznámí objednatel jako oprávněný písemně zhotoviteli výši požadovaného plnění ze strany vystavitele bankovní záruky jako povinného.

15.5. Bankovní záruka bude uvolněna nejpozději po uplynutí pěti let od protokolárního předání díla, a to na základě písemné žádosti zhotovitele.

15.6. Zhotovitel může zvolit formu poskytnutí této bankovní záruky složením finanční částky na účet objednatele.

15.7. V případě, že zhotovitel požadavek objednatele na poskytnutí bankovní záruky v požadovaném rozsahu nesplní, vyhrazuje si objednatel právo odstoupit od plnění této smlouvy s okamžitou platností bez jakýchkoliv sankcí.

Čl. 16. Závěrečná ustanovení

16.1. Smluvní strany se budou bez zbytečného prodlení vzájemně informovat o všech změnách v adresách, telefonních číslech apod. Komunikace smluvních stran bude probíhat písemně. Za písemnou formu se považuje i prostá elektronická pošta (e-mail).

16.2. Doplnit a změnit smlouvu mohou smluvní strany pouze formou písemných dodatků, které budou vzestupně číslovány, výslovně prohlášeny za dodatek této smlouvy a podepsány oprávněnými zástupci smluvních stran. Změny smlouvy lze provést výhradně v souladu se ZVZ.

16.3. Zhotovitel nesmí bez předchozího souhlasu objednatele postoupit svá práva a povinnosti

plynoucí ze smlouvy třetí osobě.

16.4. Smlouva je vyhotovena ve třech stejnopisech, které mají platnost originálu, z toho jeden

stejnopis smlouvy obdrží zhotovitel a dva stejnopisy smlouvy objednatel.

16.5. Vztahy vznikající ze smlouvy a v ní výslovně neupravené se řídí právním řádem ČR, zejména pak příslušnými ustanoveními občanského zákoníku a autorského zákona.

16.6. Smluvní strany prohlašují, že smlouva byla sepsána dle jejich pravé a svobodné vůle, že si ji před jejím podpisem přečetly a s celým jejím obsahem souhlasí.

16.7. Nedílnou součástí této smlouvy jsou přílohy: Příloha č. 1 – Technická specifikace

Příloha č. 2 – Technická specifikace zhotovitele

Příloha č. 3 – Specifikace všech nutných licencí

Příloha č. 4 – Harmonogram plnění předmětu díla

Příloha č. 5 – Akceptace výsledků poskytovaného plnění (akceptační řízení)

Za objednatele Za zhotovitele

V Benešově dne V Praze dne 7. 6. 2019

XXXx. XXXXX XXXX XXXXXX XXXXXXXX

předseda představenstva Na základě plné moci

Příloha č. 1 smlouvy o dílo

TECHNICKÁ SPECIFIKACE

Spisová služba – technické požadavky

Účel řešení

Poptávané řešení pokryje oblast elektronické spisové služby vč. subsidiárního nástroje pro dlouhodobé důvěryhodné ukládání dokumentů v roli elektronické spisovny, tj. informačního systému vybudovaného na principech mezinárodního standardu Open Archival Information Systém (ISO 14721:2012), který slouží k uložení elektronických dokumentů a dat (a to po dobu skartačních lhůt daných legislativou nebo vnitřními předpisy nemocnice) nebo k trvalému uložení těchto dat po dobu jednotek až desítek let.

Tento systém musí zajistit, že po celou dobu péče o tyto data budou tato udržována v čitelném stavu, který je umožní interpretovat a na aktuálním běžném SW vybavení prezentovat. Zároveň je ukládá takovým způsobem, který umožní věrohodně prokázat, že data nebyla po celou dobu svého uložení pozměněna a jedná se tedy o jejich původní podobu. Způsob péče o data musí být zároveň v souladu s platnou legislativou. Systém bude primárně určen k ukládání vyřízených dokumentů a uzavřených spisů elektronické spisové služby. Toho tento systém dosáhne splněním požadavků uvedených v následujících kapitolách.

Legislativní požadavky

Oblast dopravy musí naplňovat požadavky dané následující legislativou:

Zákon č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů, ve znění pozdějších předpisů

soulad s čl. II, odst. 2 zákona č. 190/2009 Sb., kterým se mění zákon č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů, ve znění pozdějších předpisů

Zákon č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů

Vyhláška č. 259/2012 Sb., o podrobnostech výkonu spisové služby Vyhláška č. 259/2012 Sb., o

podrobnostech výkonu spisové služby

Národní standard pro elektronické systémy spisové služby, VMV část 57/2017 (část II)

Zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, ve znění

pozdějších předpisů

Vyhláška č. 193/2009 Sb., o stanovení podrobností provádění autorizované konverze dokumentů

Vyhláška č. 194/2009 Sb., o stanovení podrobností užívání a provozování informačního systému

datových schránek, ve znění pozdějších předpisů

Zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů

Zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších

zákonů, ve znění pozdějších předpisů

Zákon č. 297/2016 Sb., o službách vytvářejících důvěru

požadavky Národního standardu pro elektronické systémy spisových služeb

Uvedené parametry a vlastnosti řešení v níže uvedené tabulce znamenají minimální míru plnění dle

ZD.

ID	Obecné principy a technologické vlastnosti	Splněno ano/ne	Popis splnění požadavku/parametru (příp. odkaz na stranu nabídky)
1	Řešení elektronické spisové služby bude řešeno formou tenkého klienta ve webovém prostředí, přičemž uživatelská vrstva bude tvořena webovou aplikací a uživatelské rozhraní je zobrazováno v prohlížečích • Mozilla Firefox verze 52 a vyšší • Internet Explorer verze 11 vyšší	ANO	Řešení je poskytnuto na principu tenkého klienta, přičemž uživatelské rozhraní běží v celém rozsahu aplikace ve webovém prostředí (Internet explorer a Mozilla firefox).
2	Řešení elektronické spisové služby bude poskytnuto v režimu multilicence vč. veškerých potřebných podpůrných licencí (např. run- time licence – běhové prostředí).	ANO	Řešení je poskytnuto v multilicenčním režimu vč. Garance všech nezbytných licencí k provozu.
3	Řešení elektronické spisové služby bude moderní třívrstvá aplikace, postavená na standardizaci a komponentovou architekturu vč. maximální jednoduchosti a intuitivnosti ovládání.	ANO	Viz. kapitola Základní popis systému ICZ e-spis ®
4	V rámci uživatelského prostředí elektronické spisové služby bude nativně integrován vysouvací interaktivní přehledový manažer, v rámci kterého bude uživateli zajištěno: - na jeden klik filtrovat dokumenty dle stavu v rámci spisové služby, - na jeden klik přepínat mezi jednotlivými moduly/částmi spisové služby, - prezentovat statistiky písemností dle stavu a počtu vč. možnosti refreshe na jeden klik.	ANO	Předmětný požadavek je nativně integrován ve stávajícím řešení spisové služby, dostupnost funkcí lze nalézt na připojených obrazovkách systému ICZ e-spis ®.
5	Systém zajistí seskupování adres.	ANO	Systém e-spis umožnuje v roly správa subjektu jednoduché sdružování duplicitních subjektů i adres. Systém nabízí i vyhledání duplicit pro sdružení adres.
6	Systém při příjmu DZ automaticky vyplní do záznamu o dokumentu údaje o odesílateli.	ANO	Systém e-spis při evidenci DZ automaticky vyplní informace o doručiteli z DZ a uloží metadata k záznamu.
7	Systém umožňuje administrátorovi vymazat chybně zadanou adresu s možností kontroly, že daná adresa není spojena s žádným záznamem.	ANO	Systém e-spis umožnuje v roly administrátor promazat chybně zadanou adresu. Pokud je adresa uložena v uživatelském adresáři administrátor je upozorněn.

8	Systém spisové služby umožňuje ověřit správnost adresy v registru územní identifikace, adres a nemovitostí (RÚIAN).	ANO	Systém e-spis umožnuje napojení na základní registry resp lze ověřit adresy proti RUIAN prostřednictvím specializovaného modulu REX
9	Systém při příjmu DZ automaticky vyplní do záznamu o dokumentu údaje o počtu příloh dokumentu.	ANO	Systém e-spis při zaevidování DZ rozpozná parametr tělo a příloha a do metadat profilu dokumentu tyto hodnoty uvede
10	Uživatelské prostředí spisové služby bude disponovat dynamickou rozklikávací stromovou architekturou na typ složek vedených v rámci spisové služby, vč. zajištění sdílení procesu nad danou složkou a dokumenty v nich obsažené.	ANO	Systém e-spis disponuje intuitivní stromovou strukturou, která zohledňuje příslušnou roly a zjišťuje dynamické složky pro jednoduché zobrazení dokumentů v nich na jedno klinknutí
11	V systému je možné nastavit lhůty pro vyřízení dokumentu/ spisu s přihlédnutím k existenci dnů pracovního volna, jejichž taxativní výčet obsahuje zákon č. 245/2000 Sb. (např. nastavení lhůty pro vyřízení 10 pracovních dnů, kdy termín vyřízení se automaticky vypočte s ohledem na soboty, neděle a svátky).	ANO	Systém e-spis disponuje možnosti automatického předvyplnění termínu vyřízení dle typu písemnosti.
12	Systém umožňuje zaznamenat ztrátu či poškození dokumentu/spisu včetně vazby na číslo jednací nebo jednoznačný identifikátor dokumentu, kterým byla ztráta, poškození či zničení řešeno. Jedná se o případy ztráty či zničení dokumentu v analogové podobě, k nevratnému poškození nebo ke zničení dokumentu v digitální podobě anebo nelze - li dokument v digitální podobě zobrazit uživatelsky vnímatelným způsobem.	ANO	Systém e-spis umožňuje zaznamenat ztrátu či poškození dokumentu, včetně vazby na číslo jednací nebo jednoznačný identifikátor dokumentu, kterým byla ztráta, poškození či zničení řešeno. Jedná se o případy ztráty či zničení dokumentu v analogové podobě, k nevratnému poškození nebo ke zničení dokumentu v digitální podobě anebo nelze-li dokument v digitální podobě zobrazit uživatelsky vnímatelným způsobem.
13	Systém umožňuje vytvářet adresy poboček.	ANO	Systém e-spis umožnuje tvorbu dalších adresních údajů k hlavnímu kontaktu subjektu. Dále umožnuje tvorbu vícero kontaktních údajů detašovaných pracovišť organizace (např. různé výpravny v různých lokalitách)

14	Systém bude možné nastavit tak, aby v určitém okamžiku odeslal na příslušnou mailovou adresu nebo mailové adresy odkaz. Po kliknutí na tento odkaz a autorizaci systém uživateli zobrazí metadata dokumentu a umožní uživateli zobrazení dokumentu, pokud je v systému uložen v digitální podobě.	ANO	Součástí aplikace e-spis je i systém upozorňování uživatelů pomocí e- mailových zpráv. Tyto zprávy obsahují jednoduchý popis a odkaz na dokument, ke kterému se váží. Nastavení avíz je opět plně v plné moci administrátora aplikace, který může jednotlivá upozornění nastavovat. Lze volit například z avíz týkajících se vypršení termínů k dokumentům, notifikacím o čekajícím dokumentu k převzetí atd. Každý z uživatelů má také možnost si jednotlivá avíza zneaktivnit, například pro případy, kdy zpracovává velké množství dokumentů a byl by avízy zahlcen. Avíza tak najdou uplatnění zejména u uživatelů, kteří s aplikací nepracují pravidelně.
15	Systém bude schopen vygenerovat tiskovou sestavu všech adres, na kterou byl dokument odeslán.	ANO	Systém e-spis umožnuje tisk složek a záložek včetně obsahu…umožnuje také tisk seznamu vypravení tedy adres na kterou byl dokument odeslán
16	Systém umožňuje omezit zaměstnanci výběr jen z určitých spisových znaků spisového a skartačního plánu.	ANO	Na vybrané spisové znaky lze nastavit přístupová práva pro vybrané pracovníky. Tyto znaky uvidí tedy vybrané FM nebo odbor nebo kombinace
17	Řešení elektronické spisové služby zaručí možnost provozu na všech hlavních platformách (AIX, Microsoft Windows, Linux, UNIX) bez zásadních zásahů do infrastruktury zákazníka a využití běžných databází na trhu (Microsoft SQL Server, ORACLE).	ANO	Viz kapitola Potřeby HW a SW (str 39)
18	Systém je možné nastavit tak, aby byla z uložiště automaticky smazána DZ v okamžiku, kdy došlo k vyřazení všech dokumentů, které byly jako součást této DZ přijaty nebo odeslány.	ANO	Pokud je dokument skartován pak je příloha smazána včetně dalších příloh obsažených v datové zprávě (záznam se bere jako celek a to vazbou přes křížové odkazy)
19	Součástí řešení bude systém virtuálního "pracovního stolu", na který "přicházejí" dokumenty přidělené uživateli k vyřízení. Oběh dokumentů mezi jednotlivými pracovními stoly zajistí systém spisové služby. O všech krocích zpracování dokumentu se vedou záznamy v	ANO	Podstatou práce uživatele v systému je práce s virtuálním "pracovním stolem", na který

	historii, takže je možno zpětně určit kdo, kdy a jak s dokumentem pracoval - v historii se zaznamenává nejen funkční místo, které činnost provedlo, ale i jméno konkrétního uživatele.		"přicházejí" dokumenty přidělené uživateli k vyřízení. Oběh dokumentů mezi jednotlivými pracovními stoly zajišťuje systém spisové služby. Oběh dokumentů/spisu je možno předdefinovat pomocí referátníku (workflow proces). O všech krocích zpracování dokumentu se vedou záznamy v historii, takže je možno zpětně určit kdo, kdy a jak s dokumentem pracoval. Systém podporuje osobní odpovědnost za zpracování - v historii se zaznamenává nejen funkční místo, které činnost provedlo, ale i jméno konkrétního uživatele.
20	Ke každému dokumentu/spisu evidovanému v systému elektronické spisové služby jsou definována určitá přístupová práva. Přístupová práva se ve spisové službě vztahují na funkční místa, nikoliv na konkrétní uživatele, vč. zajištění při změně obsazení funkčního místa jiným uživatelem převzetí všech práv k dokumentům novým uživatelem. Přístupová práva jsou aplikací nastavována automaticky podle fáze životního cyklu, ve kterém se dokument nachází, a podle toho, kde v organizaci je dokument právě zpracováván.	ANO	Ke každému dokumentu/spisu evidovanému v ICZ e-spis ®u jsou definována určitá přístupová práva. Přístupová práva se ve spisové službě vztahují na funkční místa, nikoliv na konkrétní uživatele. Důsledkem toho je, že při změně obsazení funkčního místa jiným uživatelem, přebírá nový uživatel všechna práva k dokumentům daného funkčního místa. Přístupová práva jsou aplikací nastavována automaticky podle fáze životního cyklu, ve kterém se dokument nachází, a podle toho, kde v organizaci je dokument právě zpracováván.
21	Řešení elektronické spisové služby disponuje intuitivním uživatelským rozhraním pro Internetový prohlížeč (Internet Explorer, Mozilla).	ANO	Viz kapitola Potřeby HW a SW (str.39 - 40)
22	Řešení elektronické spisové služby bude možné uživatelsky nastavit i z pohledu barevného znázornění uživatelského prostředí, a to minimálně ve třech variantách.	ANO	Systém e-spis disponuje možností oddělit barevně prostředí a to testovací (zelená), školící (oranžová), produkční (modrá) toto nastavení provádí administrátor systému

23	Součástí řešení elektronické spisové služby bude modul (agenda) Elektronické podatelny, v rámci které bude řešeno zejména příjem a odesílání e-mailových zpráv opatřených kvalifikovaným elektronickým podpisem dle zákona č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce v platném znění. Kromě těchto typů zpráv lze v elektronické podatelně řídit i způsob zpracování ostatních e-mailových podání doručovaných na elektronické adresy podatelny.	ANO	Viz kapitola Elektronická podatelna a výpravna (str. 42 )
24	Elektronická podatelna provádí všechny operace nutné ke zpracování přijatých e-mailových podání – kontroluje e-mailové podání a dokumenty v něm obsažené, zda odpovídají požadavkům na doručení dokumentů, kontroluje, zda e-mailové podání a v něm obsažené dokumenty, jsou opatřeny uznávaným elektronickým podpisem, uznávanou elektronickou značkou a kvalifikovaným časovým razítkem a ověřuje jejich platnost. Elektronická podatelna zasílá potvrzení o doručení e-mailového podání nebo o zamítnutí s uvedením důvodů zamítnutí přijetí e-mailového podání odesílateli podání. O výsledku kontroly a ověření elektronická podatelna provádí a ukládá záznam.	ANO	Viz kapitola Elektronická podatelna a výpravna (str. 42)
25	E-mailové podání spolu s protokoly je dále předáno k dalšímu zpracování, kde pověřený zaměstnanec provádí příjem a evidenci doručených e-mailových podání a jejich přidělení ke zpracování určeným organizačním jednotkám. Zaevidovaný dokument v systému elektronické spisové službě obsahuje jednak popisná metadata a dále elektronické dokumenty z doručeného e-mailového podání (tj. tělo zprávy a jednotlivé přílohy obsažené v doručeném e- mailovém podání).	ANO	Viz kapitola Elektronická podatelna a výpravna (str. 42)
26	Texty notifikací spolu s kritérii pro příjem e-mailových podání může upravit administrátor aplikace.	ANO	Viz kapitola Elektronická podatelna a výpravna (str. 42)
27	V rámci implementace bude systém spisové služby konfigurován tak, že umožní: • Zaevidování dokumentu z elektronické podatelny včetně uložení příloh, • vrácení jednacího čísla zaevidovaného dokumentu, • předání dokumentu k vypravení do elektronické podatelny, • přijetí zpětného hlášení o odeslání.	ANO	Viz kapitola Elektronická podatelna a výpravna (str. 42)
28	Součástí řešení elektronické spisové služby bude modul (agenda) Podatelny datových zpráv pro zajištění: • činnosti spojené s příjmem a odesíláním elektronických zpráv z/do Datových schránek. • Zároveň je v systému spisové služby doplněna podpora činností podatelny, výpravny a referenta spojených s komunikací s ISDS včetně služby zjištění existence Datové schránky konkrétního subjektu.	ANO	Viz kapitola Modul elektronické podatelny datových zpráv (str. 42)
29	Modul zajistí pro systém spisové služby vlastní komunikaci s ISDS a dále splní povinnosti stanovené jí legislativou: • Vedení evidence o přijatých a odeslaných zprávách, • kontrola na škodlivý kód, • kontrola elektronických příloh, jsou-li podepsány, na platnost elektronického podpisu a certifikátu, • ukládání originálu zpráv, • vedení žurnálu událostí.	ANO	Viz kapitola Modul elektronické podatelny datových zpráv (str. 42)

30	Příjem listinných zásilek bude probíhat v systému elektronické spisové služby ve speciálním formuláři, který bude k dispozici pracovníkům podatelny. Tento formulář bude optimalizován právě pro činnosti spojené s hromadnou evidencí dokumentů. Uživatel zde bude moci zaznamenat všechny informace spojené s povahou zásilky a subjektu, od kterého byla doručena. V případě, kdy již bylo v minulosti s tímto subjektem komunikováno, je možné jej vybrat z adresáře subjektů, který aplikace obsahuje. Po evidenci dokumentu je možné nechat na tiskárně čárových kódů vytisknout štítek s čárovým kódem, kterým lze nahradit podací razítko. Čárový kód pak lze použít i při oběhu dokumentu mezi zpracovateli.	ANO	Příjem listinných zásilek probíhá v aplikaci ve speciálním formuláři, který mají k dispozici pracovníci podatelny. Tento formulář je optimalizován právě pro činnosti spojené s hromadnou evidencí dokumentů. Uživatel zde může zaznamenat všechny informace spojené s povahou zásilky a subjektu, od kterého byla doručena. V případě, kdy již bylo v minulosti s tímto subjektem komunikováno, je možné jej vybrat z adresáře subjektů, který aplikace obsahuje. Po evidenci dokumentu je možné nechat na tiskárně čárových kódů vytisknout štítek s čárovým kódem, kterým lze nahradit podací razítko. Čárový kód pak lze použít i při oběhu dokumentu mezi zpracovateli a je nutným předpokladem pro digitalizaci dokumentu. Tiskárna čárových kódů, ani skener nejsou součástí této nabídky.
31	V rámci systém elektronické spisové služby má každý z uživatelů možnost založit dokument pocházející z jeho vlastní tvorby. Při evidenci dokumentu pak uživatel musí vyplnit alespoň povinná pole (povinná pole může definovat administrátor). Pro zrychlení práce, aplikace bude disponovat funkcionalitou, díky které je možné definovat tzv. „šablony dokumentů“. Šablona dokumentu je vlastně předvyplnění metadatových polí u opakujících dokumentů.	ANO	Každý z uživatelů má možnost založit dokument pocházející z jeho vlastní tvorby. Při evidenci dokumentu pak uživatel musí vyplnit alespoň povinná pole (povinná pole může opět definovat administrátor). Dále aplikace disponuje funkcionalitou, díky které je možné definovat tzv. „šablony dokumentů“. Šablona dokumentu předvyplní profilové pole a najde využití u stále se opakujících dokumentů, což má za následek zvýšení uživatelského komfortu.
32	Přidělování čísel jednacích probíhá v systému elektronické spisové služby automaticky po evidenci dokumentu. Na podatelně mají uživatelé možnost dokument buď evidovat (a přidělit ČJ rovnou), nebo pokud si nejsou jisti, zda dokument do evidence patří, tak zvolit „Přijmout“. V takovém případě je dokumentu přidělen pouze	ANO	Přidělování čísel v systému e-spis jednacích probíhá v aplikaci automaticky po evidenci dokumentu. Na

	jednoznačný identifikátor a o zanesení do evidence či jeho zrušení rozhodne až odborný referent. Formát přidělovaných čísel jednacích bude možné definovat v nastavení aplikace.		podatelně mají uživatelé možnost dokument buď evidovat (a přidělit ČJ rovnou), nebo pokud si nejsou jisti, zda dokument do evidence patří, tak zvolit „Přijmout“. V takovém případě je dokumentu přidělen pouze jednoznačný identifikátor (UID) a o zanesení do evidence či jeho zrušení rozhodne až odborný referent. Formát přidělovaných čísel jednacích je možné definovat v nastavení aplikace.
33	Jednou z povinných položek je u každého evidovaného dokumentu (vlastního i doručeného) pole „Typ dokumentu“. Typy dokumentů pak mohou odpovídat jednotlivým agendám, které budou v organizaci zpracovávány. V aplikaci elektronické spisové službě pak budou moci být administrátorem nastaveny zvláštní číselné řady tzv. Agendová čísla, která lze navázat právě na položku Typ dokumentu.	ANO	Povinná položka u každého dokumentu (vlastního i doručeného) pole „Typ dokumentu“. Typy dokumentů pak mohou odpovídat jednotlivým agendám, které budou v organizaci zpracovávány. V aplikace ICZ e-spis ® pak mohou být administrátorem nastaveny zvláštní číselné řady tzv. Agendová čísla, která lze navázat právě na položku Typ dokumentu.
34	Řešení elektronické spisové služby plně podporuje tvorbu a práci se spisy, kdy každý vytvořený spis dostává označení ze speciální číselné řady určené pouze pro spisy, spisovou značku. Tato číselná řada může být opět definována administrátorem. Každý dokument vložený do spisu si ponechává své číslo jednací, pod kterým byl evidován a navíc od nadřízeného spisu přebere spisovou značku. Do spisů lze spolu s dokumenty vkládat i další spisy a to do maximálně třetí úrovně vnoření.	ANO	systém e-spis plně podporuje tvorbu a práci se spisy, kdy každý vytvořený spis dostává označení ze speciální číselné řady určené pouze pro spisy, spisovou značku. Tato číselná řada může být opět definována administrátorem. Každý dokument vložený do spisu si ponechává své číslo jednací, pod kterým byl evidován a navíc od nadřízeného spisu přebere spisovou značku. Do spisů lze spolu s dokumenty vkládat i další spisy a to do maximálně třetí úrovně vnoření.

35	Řešení elektronické spisové služby zajistí variabilní vyhledávání podle oprávnění uživatele. Filtrování dokumentů lze provádět v téměř každé složce v aplikaci pomocí uživatelem nastavitelných filtrů, které si může uložit. Ve výsledcích filtrování pak uživatel může vyhledávat pomocí všech dostupných sloupců v aktuálním zobrazení. Systém umožní vytvářet komplexní logické vyhledávací dotazy, které je možné řetězit za sebe. Všem uživatelům je k dispozici dále vyhledávání včetně rozšířeného vyhledávání napříč všemi složkami, kde uživatelé mohou využít plného vyhledávacího formuláře, ve kterém lze hledat podle kteréhokoli údaje, který je o dokumentu v aplikaci zaznamenán.	ANO	Vyhledávání je jednou z nejčastěji používaných funkcí při práci se spisovou službou a proto v aplikaci existuje mnoho způsobů, jak filtrovat a vyhledávat dokumenty. To, jaké dokumenty může uživatel vyhledat, se pak odvíjí od jeho oprávnění, kterým je níže věnována speciální kapitola. Filtrování dokumentů lze provádět v téměř každé složce v aplikaci pomocí uživatelem nastavitelných filtrů, které si může uložit. Ve výsledcích filtrování pak uživatel může vyhledávat pomocí všech dostupných sloupců v aktuálním zobrazení. Pro zdatnější uživatele existuje v zobrazeních možnost vytvářet komplexní logické vyhledávací dotazy, které je možné řetězit za sebe. Všem uživatelům je k dispozici dále vyhledávání včetně rozšířeného vyhledávání napříč všemi složkami, kde uživatelé mohou využít plného vyhledávacího formuláře, ve kterém lze hledat podle kteréhokoli údaje, který je o dokumentu v aplikaci zaznamenán. Některým uživatelům může administrátor přidělit rozšířená oprávnění na vyhledávání dokumentů, tito uživatelé jsou následně schopni nalézt jakýkoli dokument napříč aplikací.
36	Systém umožní administrátorovi přidělit rozšířená oprávnění na vyhledávání dokumentů, tito uživatelé jsou následně schopni nalézt jakýkoli dokument napříč aplikací.	ANO	Administrátor má možnost nastavit tzv. právo na dokument, určené FM má pak možnost dle úrovně práv vyhledat jakýkoliv dokument organizace
37	V aplikaci je možné definovat šablony textových dokumentů ve formátu .DOCX. Při vytváření dokumentu tak může uživatel využít této šablony, do které je možné na předem definovaná místa automaticky vyplnit hodnoty z metadatových polí, kterými jsou	ANO	Pro pohodlnější zpracování vlastních dokumentů je možné v aplikaci definovat šablony textových

	například ČJ, Věc a další. Další vlastností aplikace bude tzv. přímá editace dokumentů, kdy uživatel nemusí při úpravách dokument ukládat do počítače, na kterém pracuje, provést úpravy a dokument opět nahrát zpět do aplikace jako novou verzi. Je totiž možné dokument otevřít přímo z aplikace, kdy dojde automaticky ke spuštění kancelářského programu MS Word a po provedení změn je dokument při uložení rovnou odeslán zpět do aplikace a verzován.		dokumentů ve formátu .DOC nebo DOCX, Při vytváření dokumentu tak může uživatel využít této šablony, do které je možné na předem definovaná místa automaticky vyplnit hodnoty z metadatových polí, kterými jsou například ČJ, Věc a další. Modul editace dokumentů el. přílohy je funkce kdy uživatel nemusí při úpravách dokument ukládat do počítače, na kterém pracuje, provést úpravy a dokument opět nahrát zpět do aplikace jako novou verzi. Je totiž možné dokument otevřít přímo z aplikace, kdy dojde automaticky ke spuštění kancelářského programu MS Word a po provedení změn je dokument při uložení rovnou odeslán zpět do aplikace a verzován. Pokud bude vše v oragnizaci vedeno metodicky správně a budou všechny odchozí dokumenty vycházet ze šablon v aplikaci, bude důsledkem sjednocení stylů použitých v dokumentech.
38	Aplikace obsahuje, kromě řízení životního cyklu dokumentu/spisu, konkrétní implementaci workflow. Toto workflow je předpis, který určuje kdo v jakém termínu a jak má s dokumentem/spisem (obecně s objektem spisové služby) pracovat. Pokud je k danému dokumentu přiřazeno workflow, systém zajistí, aby byl podle této definice předáván jednotlivým uživatelům (resp. funkčním místům). Navíc bude možné dokument předat i mimo určený proces, např. pro doplnění dalšího mimořádného odborného posouzení nebo schválení. Historie dokumentu/spisu zachycuje celý postup vyřizování, takže je možno zpětně analyzovat typické oběhy a vytvořit pro ně šablony procesů.	ANO	Systém e-spis obsahuje možnost nastavení workflow v podobě Referátníku. Referátník je předpis, který určuje kdo v jakém termínu a jak má s dokumentem/spisem (obecně s objektem spisové služby) pracovat. Pokud je k danému dokumentu přiřazen Referátník, systém zajistí, aby byl podle této definice předáván jednotlivým uživatelům (resp. funkčním místům). Do předdefinovaného workflouw je možnost dokument předat i mimo určený proces, např. pro doplnění dalšího

			mimořádného odborného posouzení nebo schválení. Historie objektů zachycuje celý postup vyřizování, takže je možno zpětně analyzovat typické oběhy a vytvořit pro ně šablony procesů
39	Aplikace bude obsahovat několik předdefinovaných sestav tisků. Jsou jimi například podací deník, poštovní podací arch a další. Mimo to má uživatel možnost tisku vlastních sestav dokumentů ze složek a zobrazení. Míra uživatelského nastavení bude definována až do úrovně, kdy v zobrazení složky na počítači mohou být zobrazeny jiné sloupce o jiných šířkách, než jaké jsou použity pro tiskovou sestavu.	ANO	Systém e-spis obsahuje několik předdefinovaných sestav tisků. Tj. podací deník, poštovní podací arch a další. Uživatel má možnost tisku vlastních sestav dokumentů ze složek a zobrazení. Uživatelského nastavení jde až do té míry, kdy v zobrazení složky na počítači mohou být zobrazeny jiné sloupce o jiných šířkách, než jaké jsou použity pro tiskovou sestavu.
40	Součástí aplikace bude i systém upozorňování uživatelů pomocí e- mailových zpráv. Tyto zprávy obsahují jednoduchý popis a odkaz na dokument, ke kterému se váží. Nastavení avíz bude plně v gesci administrátora aplikace, který může jednotlivá upozornění nastavovat. Bude možné volit například z avíz týkajících se vypršení termínů k dokumentům, notifikacím o čekajícím dokumentu k převzetí atd. Každý z uživatelů bude mít také možnost si jednotlivá avíza zneaktivnit.		Systém e-spis umožňuje automaticky generovat a uživatelům odesílat avíza. Avízem je myšlena informace (upozornění) v podobě e-mailu do poštovní schránky uživatele. Definice avíza obsahuje kromě určení typu (viz tabulka)
			- určení sledované události, resp. jejího výsledku (stav aktivity, stav oběhu)
		ANO	- určení předmětu avíza a textu avíza (obsahu generované zprávy)
			- určení typu dokumentu, pro který má být avízo generováno (bez určení = pro všechny)
			Nově vytvořené avízo je automaticky aktivováno všem uživatelům systému ESSL e-spis. Ti si jej mohou v případě potřeby aktivovat nebo deaktivovat ve svých uživatelských nastaveních.
			Provádí: Administrátor

			ESSL Způsob: administrační rozhraní Nastavení – Systém / Nastavení avíza
41	Každý zásah uživatele je u každého objektu zaznamenán a to od prostého čtení až po jednotlivé změny. Tyto změny budou u objektů k dispozici na speciální záložce. U každé změny je pak uvedeno který pracovník operaci provedl, z jakého funkčního místa, jak vypadal dokument před provedenou změnou a jak vypadá po provedené změně.	ANO	Systém e-spis disponuje „journálováním“ jednotlivých akcí prováděných uživatelem nebo systémem. Tyto informace jsou zobrazovány také na záložce „historie“ které si muže zobrazit uživatel s právy na příslušný objekt. Záznam historie obsahuje jak informace před akcí tak po akci včetně záznamu o pracovníkovi a funkčním místě pod kterým byla změna učiněna.
42	Mimo těchto záznamů vede aplikace dle požadavků NSESSS Transakční protokol, do kterého budou zaznamenávány všechny požadované informace. Ten se bude ukládat každý den ve výstupním formátu PDF/A s možností jeho opatření časovým razítkem nebo systémovou značkou. Toto nastavení bude dostupné administrátorovi včetně toho, jakou věcnou skupinu a skartační znak má generovaný dokument převzít.	ANO	Systém e-spis zaznamenává úkony prováděné uživatelem během řízení životního cyklu dokumentu nebo spisu do transakčního protokolu pro případnou kontrolu. Zaznamenána je operace, datum a čas, funkční místo a uživatel, jenž operaci provedl a také podrobnosti operace (např. měněná metadata a hodnota metadat). Transakční protokol je v pravidelných intervalech, zpravidla každý den, ztvárněn a uložen do ESSL. Záznam definuje administrátor včetně nastavení funkčního místa pro ukládání dokumentu. Záznam je opatřován razítkem dle nastavení.
43	Aplikace elektronické spisové služby bude pracovat se systémem funkčních míst, která jsou zařazena do organizační struktury. Dokumenty a všechna oprávnění se váží právě na tato funkční místa.	ANO	Organizační struktura v aplikaci plně kopíruje organizační strukturu v organizaci. Aplikace ICZ e- spis ® pracuje se systémem funkčních míst, která jsou zařazena do organizační struktury. Dokumenty a všechna oprávnění se váží na tato funkční místa. Práva na dokumenty jsou dány zařazením funkčního místa v organizační struktuře,

			přidělenou rolí či individuálním nastavením pro daný dokument. Role v ICZ e-spis ® jsou definovány takto: REFERENT VEDOUCÍ SEKRETARIÁT PODATELNA VÝPRAVNA SPISOVNA ADMINISTRÁTOR
44	Pro případy zastupitelnosti bude mít každý zaměstnanec možnost zvolit, kdo a případně na jak dlouho jej má zastupovat na jeho funkčním místě (zastupující pracovník si po vstupu do aplikace může vybrat, které funkční místo bude vykonávat). Možnost nastavit zástupy ostatním uživatelům má pouze administrátor, nebo vedoucí pro své podřízené. Do historie a transakčního protokolu se zaznamenává jméno uživatele, který skutečně operace provedl a funkční místo ze kterého operace provedl.	ANO	Pro případy zastupitelnosti má každý zaměstnanec možnost zvolit, kdo a případně na jak dlouho jej má zastupovat na jeho funkčním místě (zastupující pracovník si po vstupu do aplikace může vybrat, které funkční místo bude vykonávat). Možnost nastavit zástupy ostatním uživatelům má pouze administrátor, nebo vedoucí pro své podřízené. Do historie a transakčního protokolu se zaznamenává jméno uživatele, který skutečně operace provedl a funkční místo ze kterého operace provedl.
45	Systém umožní uživatelům vytvářet strukturované pohledy na dokumenty.	ANO	Registratury umožňují uživatelům vytvářet strukturované pohledy na dokumenty. Jednotlivým úrovním strukturovaného pohledu říkáme registratura. Zařazením dokumentu do registratury získá uživatel snadnější přístup k dokumentu prostřednictvím věcného členění díky systému registratur. Dokument je možné začlenit do více registratur a využívat více věcných pohledů. Registratury dále umožňují nastavení speciálních přístupových práv pro

			jednotlivé úrovně registratur, aby uživatelé podle zvolené úrovně mohli nahlížet nebo upravovat dokumenty, ke kterým jinak nemají přístupová práva.
46	Systém zajistí ověřování v souladu s článkem 32 nařízení eIDAS a souvisejícími normami pro ověřování kvalifikovaných elektronických podpisů, kvalifikovaných elektronických pečetí a kvalifikovaných časových razítek musí být prováděno pro dané typy podpisů, značek a pečetí, a to pro certifikáty vydané důvěryhodným poskytovatelem z kterékoliv členské země EU.	ANO	Viz kapitola Ověřování (str. 47)
47	Systém pokryje činnosti související s ukládáním elektronických dokumentů pro potřeby spisové služby tak, aby byla zachována jejich průkaznost a důvěryhodnost z pohledu platnosti obsahu, popřípadě přiřazených autentizačních prvků, vč. zajištění služby pro manipulaci s elektronickými soubory, resp. jejich binární podobou. V systému elektronické spisové služby budou uchovávány elektronické přílohy dokumentů, např. došlé datové zprávy, skenované došlé dokumenty i soubory vytvořené zaměstnanci. Tyto soubory budou ukládány buď v databázovém úložišti komponenty nebo v souborovém úložišti. Funkcemi systému budou: • ukládání • verzování obsahu • vyzvedávání pro další použití • vyhledávání v obsahu • uchování informací o době platnosti autentizačních prvků • případné další funkce	ANO	Viz kapitola Modul důvěryhodnosti (důvěryhodné úložiště) (str. 48)
48	Systém elektronické spisové služby bude vybaven možnostmi fulltextového vyhledávání nad obsahem elektronických příloh objektů.	ANO	Systém e-spis je vybaven možnostmi fulltextového vyhledávání nad obsahem elektronických příloh objektů ESS. Používá-li ESS ICZ e-spis ® komponentu tDMS DB, je pro službu fulltextového vyhledávání využito nativní vlastnosti databáze. V případě využívání komponenty tDMS FS je pro fulltextové vyhledávání využíváno externí služby Apache Solr, která je součástí distribuce komponenty tDMS FS.
49	Oblast důvěryhodného ukládání bude standardně implementována v systému elektronické spisové služby pro služby validace a vytváření autentizačních prvků a služby převodu datových formátů.	ANO	Systém e-spis obsahuje služby vytvářející důvěryhodné ukládání pro manipulaci s elektronickými soubory, resp. jejich binární podobou: · ukládání · verzování obsahu

			· vyzvedávání pro další použití · vyhledávání v obsahu · atd. Implementuje také služby validace a vytváření autentizačních prvků, služby převodu datových formátů.
50	Systém elektronické spisové služby zabezpečí konverzi elektronických příloh do definovaného jednotného výstupního formátu PDF/X. Xxxxx bude určen pro přípravu příloh před případným podepsáním a elektronickým odesláním (ISDS, mail, datový nosič).	ANO	Systém e-spis zabezpečuje konverzi elektronických příloh do definovaného jednotného výstupního formátu PDF/X. Xxxxx je určen pro přípravu příloh před případným podepsáním a elektronickým odesláním (ISDS, mail, datový nosič). Dle novelizace zákona č. 499/2004 Sb. musejí být všechny dokumenty opouštějící organizaci (OVM) v předepsaném výstupním formátu, pro dokumenty textového charakteru je to formát PDF/A. Proto je možné doplnit systém ICZ e-spis ® modulem zajišťujícím konverzi elektronických příloh do tohoto výstupního formátu přímo z uživatelského prostředí ICZ e-spis ®.
51	Systém elektronické spisové služby zajistí automatický příjem a odesílání DZ (datových zpráv) dle nastavení v rámci Zadavatele. Bude možné nastavit časové intervaly, kdy budou DZ odesílány a kdy přijímány bez nutné asistence pracovníka výpravny či podatelny. Autentizace vůči ISDS bude prováděna pomocí komerčního serverového certifikátu a to pro každou DS zákazníka zvlášť. Zároveň však bude zajištěno manuální stažení či odeslání DZ v případě, že je tak během práce potřeba.	ANO	Viz kapitola Automat DZ (str. 49)
52	Součástí systému elektronické spisové služby bude modul spisovny pro střednědobé ukládání dokumentů (archív) pro archivaci, ochrany před ztrátou dat, zachování čitelnost dokumentů, jejich autenticitu a nezměnitelnost. Řešení naplní legislativní požadavky zákona č. 499/2004 Sb. ve znění pozdějších předpisů a Národního standardu pro elektronické systémy spisové služby.	ANO	Viz kapitola Produkt ICZ IS DESA ® (str. 55)
53	Systém elektronické spisové služby bude nastaven pro zajištění důvěryhodnosti pro využití časových razítek. Časovým razítkem se na vstupu bude opatřovat nejenom dokument, ale i jemu příslušná	ANO	Časové razítko se aplikuje na celý datový balíček a při

	(popisná) metadata, resp. celý ukládací balíček.		jeho aplikaci dojde k vypočtení otisku datového souboru balíčku (tzv. HASH), který je pro každý balíček jedinečný a ten je pomocí API odeslán certifikační autoritě. Certifikační autorita přidá k tomuto otisku informaci o aktuálním čase a tento text zašifruje privátním klíčem certifikační autority. Výsledný řetězec/text je časové razítko a je zaslán zpět systému ICZ DESA, který jej uloží jako speciální typ datového balíčku s odkazem na razítkovaný datový balíček.
54	Systém elektronické spisové služby zajistí, že systém bude provádět pouze kontrolovatelné a autorizované zásahy a ty budou prokazatelně dokladované. Veškeré procesy s dokumenty budou dokumentovány tak, aby budoucí uživatel mohl v případě potřeby vyhodnotit, jaké zásahy byly provedeny, kdo, kdy a z jakého důvodu je prováděl – jsou vytvářeny tzv. transakční logy.	ANO	Systém e-spis zaznamenává činnosti prováděné nad spravovanými datovými balíčky (příjem balíčku, odeslání balíčku apod.), nad systémem jako takovým (systémový log změny parametrů, změny v číselnících apod., chyby, výjimky) a nad činností samotných uživatelů (aplikační log přihlašování do systému apod.). Podle nastavení parametrů systému jsou v časových intervalech vytvářeny z transakčních záznamů nové datové balíčky (auditní logy) obsahující skupiny transakčních záznamů. Tyto balíčky se také ukládají do archivního úložiště jako ostatní obsah a podléhají tak stejný pravidlům a požadavkům na důvěryhodnost, dlouhodobost a shodu se standardy. Systém tím zvyšuje úroveň důvěryhodnosti a možnosti věrohodně prokázat informace o své činnosti a o operacích prováděných se spravovanými datovými balíčky. U každého uloženého záznamu je odlišeno, zda se jedná o

			záznam činnosti vykonané systémem nebo uživatelem. V případě činnosti systému je uvedeno jaká komponenta systému činnost vykonala. V případě činnosti vykonané uživatelem je zaznamenána identifikace uživatele. Každý záznam obsahuje: Datum a čas vzniku Úroveň Název komponenty Název uživatele Popis záznamu Popis události Kód chyby pokud se jedná o chybu Identifikátor a verzi relevantního datového balíčku Systém umožňuje sběr záznamů na těchto úrovních: Administrace Fáze příjmu datového balíčku Kontrola digitálního archivu Kontrola kvality balíčku Přístup k databázi Skartace Ukládací jednotky Výdej/zápůjčka balíčků Uživatelské rozhraní nabízí přehledný modul pro kontrolu transakčních záznamů a umožňuje jejich výpis filtrovat dle výše uvedených kritérií.
55	Po vypršení skartační, nebo archivační lhůty může být dokument ze systému vyřazen. Proces Skartačního řízení je několikafázový proces, který zahrnuje výběr dokumentů k vyřazení, sestavení skartačního návrhu, schválení skartačního návrhu a vlastní vyřazení.	ANO	Životnost dokumentů a spisů uložených v elektronickém archivu může být řízena legislativou a organizačními potřebami původce. Uložené dokumenty a složky zde

			čekají na skartační řízení. Po uplynutí skartační lhůty dojde ke skartaci (zničení) dokumentů. Je třeba počítat s tím, že některé dokumenty mohou v DESA zůstávat po velmi dlouhou dobu, aniž by se skartovaly, jiné mají svou životnost v organizaci omezenu spisovým a skartačním plánem. Po vypršení skartační lhůty může být balíček (dokument) ze systému vyřazen. Proces skartačního řízení je několikafázový proces, který zahrnuje výběr balíčků k vyřazení, sestavení skartačního návrhu, schválení skartačního návrhu a vlastní vyřazení
56	Systém elektronické spisové služby zajistí vyřazení (zničení obsahu skartovaných dokumentů, resp. export dokumentů a jejich metadat do formátu vhodného pro přenos do nadřazeného archivu (NDA)). Podle nastavení systému se dokumenty předané prokazatelně do nadřazeného archivu také zničí, nebo zůstanou jako kopie nadále v systému. O vyřazení se pořídí skartační, resp. předávací protokol.	ANO	Životnost dokumentů a spisů uložených v elektronickém archivu může být řízena legislativou a organizačními potřebami původce. Uložené dokumenty a složky zde čekají na skartační řízení. Po uplynutí skartační lhůty dojde ke skartaci (zničení) dokumentů. Je třeba počítat s tím, že některé dokumenty mohou v DESA zůstávat po velmi dlouhou dobu, aniž by se skartovaly, jiné mají svou životnost v organizaci omezenu spisovým a skartačním plánem.
57	V systému elektronické spisové služby budou zajištěny popisné údaje o katastrálních údajích vč. promítnutí do několika oblastí v evidenci dokumentů. K profilu doručeného i vlastního dokumentu, spisu a smlouvy lze evidovat údaje o katastru a parcelách. Jeden objekt může obsahovat údaje o více katastrech a každý z katastrů může mít na sebe navázán několik čísel parcel. O tyto údaje je doplněno i vyhledávání.	ANO	Viz kapitola Modul Katastry (str. 46)
58	Evidence dokumentů v systému elektronické spisové služby zajistí možnost zakládání, úpravu a dokumentů.	ANO	Systém e-spis umožnuje uživateli zakládat, editovat dokumenty a to i elektronické přílohy k nim připojené.

59	Systém elektronické spisové služby eviduje celou řadu údajů o dokumentech zpracovávaných úřadem. Tyto údaje v souhrnné formě poskytují informace pro řízení úřadu (např. počty vyřízených dokumentů jednotlivých typů, počet vypravených dokumentů, počet zpracovávaných dokumentů nebo smluv jednotlivými pracovníky). Systém umožní na základě pravomocí uživatele vytvořit statistický přehled dle vlastních potřeb, zobrazit a vytisknout údaje souhrnnou formou. Přehled je možné exportovat do CSV souboru pro další zpracování. Modul umožní minimálně vytvořit přehledy z šesti základních zdrojů údajů: • údaje o dokumentech nebo spisech, • údaje o vyřizování, • údaje o vypraveních, • údaje o doručeních, • údaje o převzatých nebo předaných dokumentech, • údaje o provedených akcích s dokumenty.	ANO	Viz kapitola Modul Statistiky (str. 50)
60	Systém elektronické spisové služby zajistí jak práci se štítky s předtištěnými čárovými kódy, tak s vlastním tiskem štítků s čárovým kódem. Systém umožní tisk štítků s čárovým kódem, který nahrazuje otisk podacího razítka (označení původce, datum doručení, číslo jednací, počet listů a příloh), a v případě skenování dokumentu i automatizované rozdělení naskenované dávky a uložení pořízeného obrazu dokumentu k zaevidovanému záznamu ve spisové službě.	ANO	Viz kapitola Skenování a tisk čárových kódů (str. 50)
61	Systém elektronické spisové služby bude disponovat nástrojem, který umožní administrátorovi vytvářet strukturovaná pravidla pro sledování klíčových událostí, prováděných uživateli v aplikaci spisové služby, a na základě vyhodnocení kritérií dané události provádět následné automatické akce – procesy – nad objekty spisové služby (tj. dokumenty, spisy nebo ukládacími jednotkami). Systém bude navržen tak, aby kritéria událostí, tj. podmínky pro spuštění procesů, pracovaly ve smyčce, čímž bude umožněno jednoduché řetězení procesů nad objekty ve spisové službě, tedy vytváření procesních workflow nad dokumenty, spisy nebo ukládacími jednotkami. V systému bude možné sledovat události: • úprava profilu • změna stavu aktivity • změna stavu vypravení • vložení do workflow A aplikovat tyto procesy: • předání spisovně • úprava profilu • vyřízení • předání externí aplikaci • předání oběhem • založení spisu • založení odpovědi	ANO	Viz kapitola Modul Automatizovaných procesů (str. 51)
62	Systém elektronické spisové služby zajistí přidat vrstvu s vizualizací informací o el. certifikátu, kterým byl dokument podepsán. Pro uživatele se po instalaci a aktivaci této sužby změní dialogové okno na záložce el. dokumenty/Podepsat a umožní vložit tzv. vizualizovaného podpisu (viditelný podpis) vč. výběru místa zobrazení.	ANO	Viz kapitola Vizualizace el. podpisu (str. 51)

63	Systém umožní administrátorům a uživatelům možnost využít výhody plynoucí ze zpracovávání dokumentů pomocí čárových kódů, a to bez nutnosti pořizovat speciální tiskárny pro tisk štítků čárových kódů, nebo si nechávat tisknout role se štítky předtištěnými. Přímo v aplikaci bude možné vytvořit šablonu tisknutých čárových kódů a nechat je vytisknout na standardní kancelářské tiskárně, která umí tisknout na archy samolepících etiket.	ANO	Viz kapitola Modul Tisk etiket (str. 55)
64	Součástí systému je řešení elektronické úřední desky, umožňující publikování dokumentů na elektronickou úřední desku, stejně jako publikaci do internetových stránek zadavatele. V rámci činností (publikování informací a využívání informací) bude definována práce s elektronickou úřední deskou formou rolí, jaké v přípravě dokumentů, nebo naopak využívání dokumentů, přijímají jednotlivé osoby (pracovníci zadavatele a klienti zadavatele).	ANO	Viz kapitola Publikace dokumentů na úřední desku (eDeska) (str. 52)
65	V uživatelském prostředí elektronické úřední desky bude pro externí uživatele zajištěno: Sledování dokumentů zveřejněné zadavatelem Vytváření seznamů dokumentů dle základních kritérií (aktuální, k určitému datu,…) Vyhledávání dokumentů Zobrazení detailů dokumentů Zobrazení připojených elektronických příloh dokumentů	ANO	Viz kapitola role občan (str. 52)
66	V rámci systému elektronické spisové služby bude definována role správce úřední desky pro zajištění následující činnosti: Export dokumentů (nová vyvěšení, svěšení a aktualizace vyvěšení), Rozšíření atributů pro přímé vyvěšení dokumentů o termín vyvěšení doručujícím orgánem, Export (XML a souborů na desku zadavatele) je prováděn buď ručně, nebo automaticky systémem.	ANO	Viz kapitola Role Správce úřední desky (str. 52)
67	Systém elektronické spisové služby bude garantovat princip hromadného odesílání dokumentů pro jednorázové odeslání velkého množství vypravení vč. možné konfigurovatelnosti položek.	ANO	Viz kapitola Hromadné odesílání (str. 51
68	Pro zajištění hromadného odeslání bude umožněno pro uživatele připravení CSV souboru, který je pak nahrán do aplikace s možností připojit ZIP soubor s elektronickými přílohami, které se budou odesílat. Během přípravy vypravení bude mít uživatel možnost konfigurovat, která výpravna bude pro odeslání použita, text způsobu vyřízení a může aktivovat kontroly pro doručení a automatické vyřízení. Modul bude možné použít v následujících módech: • založen 1 dokument (nový) s jedním vypravením • založen 1 dokument (nový) s N vypraveními • založeno N dokumentů (nových) s jedním vypravením • založeno X vypravení k již existujícímu dokumentu (dle specifického indetifikátoru)	ANO	Viz kapitola Hromadné odesílání (str. 52)
69	Systém elektronické spisové služby zajistí proces elektronické skartace pro komunikaci s příslušným archívem. Elektronická skartace umožní: • Vygenerovat elektronický skartační návrh – tj. vygenerovat SIP balíčky určené k odeslání do příslušného archivu dle NSESSS2 bez komponent (el. příloh). • Po posouzení archivu vygenerovat v případě nejasností nový SPI balíček včetně komponent (el. příloh). • Import rozhodnutí archivu po posouzení obsahu skartačního návrhu – rozhodnutí obsahuje změněné skartační znaky u jednotlivých objektů, popř. rozhodnutí a	ANO	Viz kapitola Modul elektronická skartace (str. 53)

	odložení skartace. • Schválení a export archivem vybraných archiválií k trvalému uložení. • Zpracování potvrzení o přejímce archiválií. • Odmazávání balíčků (tedy souborů mets a elektronických příloh) z úložiště, stav skartačního návrhu se změní na „Skartace a archivace ukončena“ a v aplikaci zůstane k dispozici pouze povinná hlavička metadat (detail balíčku se všemi záložkami).
70	Systém zajistí vytváření statistiky časových razítek dle důvodu čerpání.		Pro tvorbu uživatelských tiskových sestav sumářů a přehledů o dokumentech, spisech, doručeních a vypraveních dokumentů je určen modul Statistiky.
			Systém e-spis eviduje celou řadu údajů o dokumentech zpracovávaných organizací, tyto údaje v souhrnné formě poskytují informace pro řízení organizace (např. počty vyřízených dokumentů jednotlivých typů, počet vypravených dokumentů, počet zpracovávaných dokumentů jednotlivými pracovníky).
		ANO	Administrační rozhraní správy statistik a přehledů umožňuje vytvářet a parametrizovat sestavy a a sumáře podle potřeb organizace a jejích útvarů. Výstup je generován v datovém formátu PDF a CSV, a je možné vytvořit a nastavit sumární výstup některého z uvedených typů:
			- Vyřizování - o počtech objektů dle vyřizování,
			- Obecný - o počtech dokumentů nebo spisů obecně,
			- Vypravení - o počtech a struktuře vypravení,
			- Doručení - o počtech a struktuře doručení,
			- Oběh - o počtech

			předání nebo převzetí dokumentů a spisů, - Historie - o počtech provedených akcí nad dokumenty či spisy - Komponenty – o počtech a struktuře komponent (el. příloh dokumentů) - Časová razítka – o počtech čerpaných časových razítek za určené období - Klíčová slova – o počtech dokumentů a spisů dle výskytu klíčového slova
71	Systém elektronické spisové služby umožní vyřízení dokumentů v držení některých funkčních míst, které mají v držení velký počet dokumentů a umožní jejich předávání do Správy spisovny na principu automatizovaných procesů. Procesy budou operace (procedury), které budou v systému aplikovány automaticky na objekt dokumentu, spisu nebo ukládací jednotky na základě splnění kritérií sledované události.	ANO	Systém e-spis umožní vyřízení dokumentů v držení některých funkčních míst, které mají v držení velký počet dokumentů a umožní jejich předávání do Spisovny. Řešení bude využívat Modulu automatizovaných procesů, který byl popsán výše. Pomocí automatizovaných procesů budou definovány následující procesy • proces Vyřízení dokumentu – proces umožní automatické vyřízení dokumentů splňujících stanovená kritéria, automatický proces provede nastavení atributů Typ dokumentu, věcná skupiny a způsob vyřízení a vyřídí dokument. • proces Předat do spisovny – proces umožní stanovit spisovnu pro předání a volbu zda mají být předané objekty rovnou převzaty, tj. předány bez kontroly přebíraných dokumentů/spisů pracovníkem spisovny.
72	Pomocí automatizovaných procesů budou definovány následující procesy • proces Vyřízení dokumentu – proces umožní automatické vyřízení dokumentů splňujících stanovená kritéria, automatický proces provede nastavení atributů Typ	ANO	Viz kapitola Modul Automatizovaných procesů (str. 51)

	dokumentu, věcná skupiny a způsob vyřízení a vyřídí dokument. • proces Předat do spisovny – proces umožní stanovit spisovnu pro předání a volbu zda mají být předané objekty rovnou převzaty, tj. předány bez kontroly přebíraných dokumentů/spisů pracovníkem spisovny.
73	Automatizované procesy budou rozšířeny o proces Převzít spisovnou a sledované události o kontrolu stavu Předání do spisovny. Toto rozšíření umožní automatizovaně přebírat vybrané dokumenty, spisy a ukládací jednotky spisovnou.	ANO	Viz kapitola Modul Automatizovaných procesů (str. 51)
74	Na základě analýzy budou stanovena kritéria sledovaných událostí, při kterých se budou spouštět automatické procesy. V analýze budou stanoveny také parametry použitých automatických procesů.	ANO	Viz kapitola Modul Automatizovaných procesů (str. 51) V rámci implementace budou stanoveny parametry pro nastavení procesů
75	Řešení umožní hromadně předat objekty vybrané na základě filtračních kritérií do Správy spisovny. Předání bude provedeno odloženou úlohou. Úprava zahrnuje: • Úprava zobrazení obsahu složek – samostatná složka pro objekty v hromadném zpracování, vyjmutí objektů určených k hromadnému zpracování z běžných provozních složek (zde složky Ukončené) a omezení operací nad vyhledaným objektem zařazeným do zpracování odloženou operací • Nové funkce pro provedení akcí dle filtračních kritérií • Vytvoření interní tabulky evidence odložených operací • Tvorba interních zpráv – sumáře výsledku provedení hromadné akce Funkce provedou zařazení všech objektů vyhovujícím podmínce filtru složky / filtru záhlaví seznamu do tabulky odloženého zpracování. Současné uplatnění podmínek filtrů je nutnou podmínkou pro zachování konzistence mezi uživateli zobrazenými objekty ve složce s uplatněním filtrování a objektů, které budou takto, na základě filtru složky vstupovat do hromadné akce. Před zařazením objektů do tabulky odloženého zpracování bude uživateli zobrazen dialog s celkovým počtem vybraných objektů. Provedení akcí odloženého zpracování bude realizováno na pozadí, časovou úlohou, výsledek zpracování všech záznamů jedné akce bude zaslán uživateli formou interní zprávy systému.	ANO	Řešení umožní hromadně předat objekty vybrané na základě filtračních kritérií do Správy spisovny. Předání bude provedeno odloženou úlohou. Úprava zahrnuje: • Úprava zobrazení obsahu složek – samostatná složka pro objekty v hromadném zpracování, vyjmutí objektů určených k hromadnému zpracování z běžných provozních složek (zde složky Ukončené) a omezení operací nad vyhledaným objektem zařazeným do zpracování odloženou operací • Nové funkce pro provedení akcí dle filtračních kritérií • Vytvoření interní tabulky evidence odložených operací • Tvorba interních zpráv – sumáře výsledku provedení hromadné akce Funkce provedou zařazení všech objektů vyhovujícím podmínce filtru složky / filtru záhlaví seznamu do tabulky odloženého zpracování. Současné uplatnění podmínek filtrů je nutnou podmínkou pro

			zachování konzistence mezi uživateli zobrazenými objekty ve složce s uplatněním filtrování a objektů, které budou takto, na základě filtru složky vstupovat do hromadné akce. Před zařazením objektů do tabulky odloženého zpracování bude uživateli zobrazen dialog s celkovým počtem vybraných objektů. Provedení akcí odloženého zpracování bude realizováno na pozadí, časovou úlohou, výsledek zpracování všech záznamů jedné akce bude zaslán uživateli formou interní zprávy systému (počet provedených neprovedených objektů, odkaz na profil zpracovávaného JOBu
76	Řešení umožní nad vyhledanými a ukončeným objekty ve složce „Ukončené“, které mají společný některý se slučovacích prvků, hromadné vložení do již existující UJ. V případě, že UJ ještě není založena, dojde k jejímu založení automaticky. Jakýkoli z těchto parametrů, které budou součástí profilu každého dokumentu/spisu ve spisové službě, může být zapisován údaj, společný pro množinu dokumentů, např. IČ subjektu, RČ subjektu apod.	ANO	Systém e-spis disponuje nad vyhledanými a ukončeným objekty ve složce „Ukončené“, které mají společný některý se slučovacích prvků, hromadné vložení do již existující UJ. Pokud UJ ještě není založena, dojde k jejímu založení automaticky. Řešení je vhodné pro případy, kdy jsou dokumenty/spisy ukládány do UJ podle společného klíčového, zpravidla agendového, označení např. např. IČ subjektu, RČ subjektu apod.
77	Systém umožní zaznamenání bezpečnostní kategorie v rámci profilu objektu a řízení přístupu k elektronickým dokumentům.	ANO	Viz kapitola Modul Bezpečnostní kategorie (str. 54)
78	Systém zajistí konverze dle § 22 zákona č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, tj. zajistí: • úplné převedení dokumentu v listinné podobě do dokumentu obsaženého v datové zprávě nebo datovém souboru způsobem zajišťujícím shodu obsahu těchto dokumentů a připojení doložky o provedení konverze (dále jen „doložka“), nebo	ANO	Viz modul Modul pro integraci CzechPOINT@Office (str. 54)

	• úplné převedení dokumentu obsaženého v datové zprávě do dokumentu v listinné podobě způsobem zajišťujícím shodu obsahu těchto dokumentů a připojení doložky. Integrace spisové služby s CzechPOINT@Office umožní zaevidování výstupu z autorizované konverze z moci úřední ve spisové službě. Dokument z provedené konverze získá v systému spisové služby veškeré potřebné atributy vyžadované platnou legislativou: • identifikátor zaručení prokazatelnosti • ČJ • spisový znak • skartační znak • skartační lhůtu Systém elektronické spisové služby uloží výstupy z provedené konverze včetně ověřovací doložky. • PDF vzniklý spojením původního dokumentu bez elektronických podpisů a vytvořené doložky – v případě konverze z elektronické do listinné podoby • PDF vzniklý spojením skenovaného obrazu, doložky, podepsáno certifikátem uživatele a časovým razítkem CzechPoint – v případě konverze z listinné do elektronické podoby Integrace umožňuje oba dva typy konverzí: • z listinné podoby do elektronické • z elektronické podoby do listinné Součástí systému je evidence provedených konverzí. Jedná se o tvorbu tiskové sestavy provedených konverzí CzechPOINT, který bude obsahovat tyto údaje: • ID doložky z detailu akce • UD objektu • ČJ objektu • ID komponenty z detailu akce • název komponenty z detailu • Pracovník • Datum akce • Ukázka ověřovací doložky.
79	Systém umožňuje sloučit všechna avíza pro jednoho uživatele za posledních 24 hodin do jedné mailové zprávy.	ANO	Součástí systému e-spis je i systém upozorňování uživatelů pomocí e- mailových zpráv. Tyto zprávy obsahují jednoduchý popis a odkaz na dokument, ke kterému se váží. Nastavení avíz je opět plně v plné moci administrátora aplikace, který může jednotlivá upozornění nastavovat. Lze volit například z avíz týkajících se vypršení termínů k dokumentům, notifikacím o čekajícím dokumentu k

			převzetí atd. Každý z uživatelů má také možnost si jednotlivá avíza zneaktivnit, například pro případy, kdy zpracovává velké množství dokumentů a byl by avízy zahlcen. Avíza tak najdou uplatnění zejména u uživatelů, kteří s aplikací nepracují pravidelně. Avíza jsou generováne dle časové úlohy která lze nastavit na generování 1* za den. Avíza jsou následně sdružena do 1 emailu.
80	Systém umožňuje napojení na stávající frankovací stroj a automatický přenos informací z frankovacího stroje k příslušnému záznamu (např. váha, cena).	ANO	Systém e-spis umožnuje napojení na frankovací stroj, pokud frankovací stroj disponuje API rozhraním. Přenos se zajištuje v pro tyto elementy váha, cena hmotnosti.
81	Systém umožňuje korektním způsobem zaznamenat odeslání více dokumentů adresovaných stejnému adresátovi, ale patřících do různých spisů v jedné obálce	ANO	Systém e-spis umožnuje tvorbu tzv, Hromadné zásilky. Ta slouží pro odeslání poštovních a osobních vypravení různých čísel jednacích v jedné sdružené zásilce. Pro manipulaci s hromadnou zásilkou je ve vybraných složkách vypravení referenta, sekretariátu a výpravny menu Úpravy rozšířeno o „Vytvořit hromadnou zásilku“ a „Přidat do hromadné zásilky“.
82	Systém umožňuje vytvářet souhrnné výstupy ze spisové služby pro vedení organizace, zejména počet vyřízených dokumentů, počet zpracovávaných dokumentů jednotlivými pracovníky, statistiku použití časových razítek.	ANO	Viz kapitola Modul Statistiky (str. 50)
83	Systém umožňuje vytvořit přístup k dokumentům dle věcného členění (obdoba sdílení) a v rámci tohoto věcného členění definovat speciální přístupová práva tak, aby uživatelé mohli nahlížet na dokumenty, ke kterým jinak nemají přístupová práva. Tato funkcionalita je chápána jako nadstavba a neovlivňuje základní funkcionality a principy práce.	ANO	Viz kapitola Oprávnění na dokumenty a spisy (Registratury) (str. 46)
84	Systém je možné nastavit tak, aby bylo možné v rámci útvaru provést předání záznamů o dokumentech/spisech bez nutnosti potvrzení jejich převzetí příjemcem.	ANO	Systém je takto možné nastavit v rámci prvoinstalace produktu pomocí unikátně definovaných scriptů.

85	Systém podporuje administrativní činnosti spojené se zpracováním smluv (např. návrh, připomínkování, schvalování, zveřejnění).	ANO	Viz kapitola Modul Smlouvy a modul publikace smluv do ISRS (str. 54)
86	Systém lze nastavit tak, aby spis a jednotlivé dokumenty v něm zařazené přijímaly nejpřísnější skartační znak.	ANO	Tvorba spisu je založena na přebírání hodnot z profiu spisu u vkládaných dokumentů. Texx xokud je vložen dokument do spisu pak si přebírá hodnoty z příslušného spisu ,pokud by však měl přísnější skratační režim dojde ke kontrole a skartační režim bude nastaven tak, aby odpovídal nejpřísnější kombinaci.
87	Pro veškeré instance v rámci tohoto projektu bude zajištěna služba centrální spisovny a garantovaného úložiště vedeného v rámci Zadavatele, přičemž v rámci této infrastruktury budou jednotlivé data a dokumenty vedeny v paralelních oddělených instancích dle původců dat.	ANO	Viz kapitola produkt DESA (str. 55 – 61)
88	Systém bude disponovat dlouhodobě důvěryhodným úložištěm (DDÚ) v roli elektronické spisovny, a bude vybudovaný na principech mezinárodního standardu Open Archival Information Systém (ISO 14721:2012), který slouží k uložení elektronických dokumentů a dat a to po dobu skartačních lhůt daných legislativou nebo vnitřními předpisy zadavatele.	ANO	Viz kapitola produkt DESA - Soulad se standardy (str. 55)
89	Řešení dle bodu 88 této tabulky, jako systém na dlouhodobé uchovávání elektronických dokumentů, musí odpovídat mezinárodnímu standardu pro dlouhodobé ukládání informací OAIS (Open Archival Information System – norma ISO 14721:2003). Ten specifikuje základní funkční části otevřeného archivu, komunikaci s okolím, procesy a informační model ve formě informačních balíčků přijímaných, poskytovaných a především uložených v úložišti. Zejména pak musí splňovat tyto požadavky: • Dokumenty a jejich metadat tvoří v rámci systému jeden balíček a jsou tak uloženy po celou dobu, po kterou je dokument přítomen v systému • Systém umožní příjem, uchování a výdej dokumentů ve formě balíčků SIP, AIP, DIP • Řešení není svázáno s konkrétním formátem dokumentu nebo technologií a je připraveno na změnu těchto technologií • Systém musí podporovat migrační strategie na jiné formáty, technologie nebo kompletně jiný systém • Informace jsou v datovém balíčku uchovávány v otevřené podobě, tedy v takovém formátu, který lze číst běžně dostupnými prostředky, které nejsou závislé na dodávaném systému • Data jsou organizována na úrovni ukládacích jednotek, které odpovídají fyzickému uložení dokumentů ve spisovně/archivu	ANO	Viz kapitola produkt DESA - Soulad se standardy (str. 57)
90	Způsob příjmu datových balíčků, jejich vnitřní organizace, způsob uložení a strukturování doprovodných popisných metadat a funkce aplikačního rozhraní pro práci s balíčky, musí odpovídat podlesní verzi Národnímu standardu pro elektronické systémy spisových služeb (dále též NSESSS3).	ANO	Viz kapitola produkt DESA - Edice DES (str. 56)
91	Systém bude disponovat mechanismy, které zajistí odolnost proti	ANO	Viz kapitola produkt DESA -

	změnám obsahu a zajistí důvěru v pravost a neporušenost uloženého obsahu. Tento stav zajistí využitím systému časových razítek ve spolupráci s akreditovanou certifikační autoritou, která tato časová razítka vydává. Konkrétně bude systém v této oblasti disponovat těmito vlastnostmi: • Integrací s akreditovanou certifikační autoritou zajistí automatické vydávání časových razítek a jejich aplikaci na uložené datové balíčky. • Bude pravidelně (v konfiguračně nastavitelných intervalech) kontrolovat platnost časových razítek jednotlivých uložených datových balíčků a s dostatečným, konfiguračně nastavitelným předstihem, zajistí vydání časových razítek nových a jejich aplikaci na související datové balíčky. • Umožní aplikaci časových razítek na celou skupinu datových balíčků najednou. Bude možné konfiguračně nastavit velikost této skupiny. Zároveň bude možné konfiguračně nastavit, jak dlouho mohou datové balíčky čekat na příjmu, než jejich počet dosáhne stanovené velikosti skupiny. Po uplynutí této lhůty dojde k aplikaci časového razítka na balíčky aktuálně čekající na příjmu, přesto že jejich počet nebude odpovídat nastavené velikosti skupiny. • Systém skupinového razítkování nebude nijak omezovat možnost provést řízenou skartaci jednotlivých balíčků ze skupiny, na kterou je aplikováno jedno časové razítko. I po skartaci části datových balíčků ze skupiny nebude porušena integrita a důvěryhodnost ostatních datových balíčků. • Možnost napojení na nejméně na dvě akreditované certifikační autority najednou jako zálohu v případě nedostupnosti jedné z nich. • Možnost aplikovat na jeden datový balíček časová razítka od více certifikačních autorit. • Systém umožní aplikovat časová razítka pouze na datové balíčky s elektronickými dokumenty. Razítkovat datové balíčky s metadaty k analogovým dokumentům není požadováno.		Specifikace systému (str. 56)
92	• Data nebude možné v systému nijak měnit ani mazat. Jediným způsobem jak data vyřadit bude plánovaná skartace dle platné legislativy. I pak mohou být dokumenty v systému přítomny. • Při opravě dokumentu nebo jeho metadat dojde vždy k vytvoření další verze dokumentu. Všechny předchozí verze jsou vždy dostupné. • Při příjmu datového balíčku se stejnou identifikací na úrovni systému bude tento uložen vždy jako nová verze tohoto datového balíčků. • Pokud DDÚ podporuje funkci konverzí mezi datovými formáty uloženého obsahu, musí být konvertovaná verze obsahu vždy uložena jako nová verze datového balíčku. • Uživatelské i aplikační rozhraní poskytne přístup ke všem existujícím verzím datového balíčku.	ANO	Viz kapitola produkt DESA - Specifikace systému (str. 56)
93	Po celou dobu uložení, tedy od příjmu až po skartační řízení, se budou zaznamenávat veškeré systémové i uživatelské akce provedené nad balíčkem. Tyto informace budou uloženy rovněž jako datový balíček a budou na něj aplikována stejná pravidla jako na ostatní uložený obsah. Systém poskytne sběr informací o své činnosti minimálně v tomto rozsahu: • Aplikační log uchovávající informace o chodu systému • Transakční logy uchovávající informace o operacích uživatelů a systému nad datovými balíčky • Transakční log bude ukládán jako PDF soubor v datovém	ANO	Viz kapitola produkt DESA - Specifikace systému (str. 56)

	balíčku.
94	Přístup uživatelů k funkcím DDÚ a obsahu bude možné nastavit na úrovni uživatele, jemuž bude možné přiřadit předem definované role s příslušnými oprávněními k funkcím systému. Oprávnění k používání systému musí být možné rozdělit dle činností do těchto skupin/rolí: • Centrální správce - spravuje celkovou konfiguraci systému, provádí údržbu systému a centrální dohled. • Lokální správce - spravuje a konfiguruje vlastnosti spojené s jedním původcem dat a spravuje uživatele tohoto původce • Archivář - nakládá s balíčky na příjmu a při skartaci na základě skartačních plánů • Uživatel - běžný uživatel, který může vyhledávat a zobrazovat balíčky dle přidělených oprávnění	ANO	Viz kapitola produkt DESA - Specifikace systému (str. 56)
95	Systém lze provozovat na serverových operačních systémech Windows2012 nebo vyšší a Linux.	ANO	Viz kapitola Potřeby HW a SW (str 39-40)
96	Celý systém bude dodán jako 2 samostatná prostředí. Jedno prostředí bude sloužit k testovacím a školícím účelům, druhé prostředí bude sloužit jako primární produkční systém.	ANO	Systém e-spis lze rozdělit na více nezávislých instancí tedy školícím testovací a další jako produkční.
97	Uživatelská vrstva DDÚ je tvořena webovou aplikací a uživatelské rozhraní je zobrazováno v prohlížečích • Mozilla Firefox verze 52 a vyšší • Internet Explorer verze 11 vyšší	ANO	Viz kapitola Potřeby HW a SW (str 39-40)
98	Systém lze provozovat ve virtualizovaném prostředí.	ANO	Ano systém e-spis lze provozovat ve virtualizovaném prostředí po aplikační stránce tak databázové
99	Systém Je kompatibilní s databázemi Oracle 11 a MS SQL Server 2012 Standard nebo vyšší.	ANO	Viz kapitola Potřeby HW a SW (str 39-40)
100	Uživatelské prostředí DDÚ zajistí interatkivní prezentaci statistik (tj. přímo uživatelském prostředí bez nutnosti odskoku do jiného okna či exportu do zobrazovacího formátu), a to např.: Objemy úložišť dle lokalit, Statistiky institucí/jednotek, Využití CPU a počty vláken, Využití paměti.	ANO	Viz kapitola Komfort administrátorského prostředí (str 65)
101	Uživatelské prostředí, v rámci kterého bude možné měnit rozlišení pomocí klávesy CTRL + roll tlačítka myši.	ANO	Systém e-spis je provozován jako webový klient, lze tedy použít pro změnu velikosti klávesu CTRL + rol na myši…
102	Systém bude disponovat dynamickými rozklikávacími nabídkami jak z pohledu modulů, tak procesů, a to formou integrovaného stromu v rámci uživatelského prostředí bez nutnosti odskoku či vyvolání funkce v rámci hlavní uživatelské obrazovky.	ANO	Pro přehlednou orientaci v systému e-spis je vše zobrazeno v jednom okně hlavní obrazovky. Uživatel pod panelem e-spis najde (Navigační strom), Informační okno a vlastní Pracovní stůl. Navigační strom je rozdělen na záložky Agendy , Registratury (jen při

			současné instalaci modulu Registratury), Číselníky , Nastavení , Rychlé vyhledávání - viz Uživatelská příručka systému e-spis „Jak pracovat v systému e-spis“. Záložka Agendy obsahuje na první úrovni složky rolí přihlášeného uživatele (Základní, Referent,...) a dalších modulů e-spisu (Jednání, Smlouvy, Úkoly). Počet a druh zobrazených složek záleží na roli uživatele a používaných modulech
103	Systém umožní jak více instanční vedení spisové služby pro více subjektů, vč. podpory „multicompany/multiičo“ instance.	ANO	Systém e-spis lze provozovat v režimu multicompany instance
104	Systém zajistí založení smlouvy přímo v prostředí spisové služby bez nutnosti odskoku do jiné aplikace/modulu, přičemž ve formuláři založení smlouvy budou minimálně tyto hodnoty: Předmět smlouvy, Forma smlouvy (analogová, digitální, hybridní), Klíčová slova, Spis. a skartační znaky, Počet listů, příloh a listů příloh, druh příloh, Typ zakázky, Agendové číslo, Datum podpisu, platnosti (od, do), účinnosti, Druh finanční operace (Příjem, výdej), Částka, měna, Žadatel, objednatel, garant.	ANO	Rozšiřující modul smlouvy je obsažen v navigačním stromu v levé části na stejné úrovni jako spisová služba. Bez nutnosti odskoku do jiné aplikaci nabídne možnost založení profilových položek kde lze naplnit minimálně tyto hodnoty: Předmět smlouvy, Forma smlouvy (analogová, digitální, hybridní), Klíčová slova, Spis. a skartační znaky, Počet listů, příloh a listů příloh, druh příloh, Typ zakázky, Agendové číslo, Datum podpisu, platnosti (od, do), účinnosti, Druh finanční operace (Příjem, výdej), Částka, měna, Žadatel, objednatel, garant.
105	Systém spisové služby zajistí prvky tzv. virtuálních složek, prezentovaných formou stromové architektury, v rámci kterých	ANO	Předmětné složky jsou obsaženy v rámci modulu

	bude zajištěna služba koordinovaných či souhrnných dokumentů napříč organizační strukturou nemocnice.		Registratury.
106	Systém spisové služby zajistí podporu a synchronní provoz s kancelářským SW LibreOffice.	ANO	Systém e-spis zajištuje podporu kancelářského balíku Libreoffice
107	Systém bude disponovat otevřenou integrační komponentou v úplném souladu s Národním standardem, přičemž daná komponenta bude poskytnuta v režimu licenční multilicence, tj. bez omezení počtu napojených AIS (agendových informačních systémů) a bez nutnosti pořizování případných sublicencí.	ANO	Systém e-spis disponuje rozhraním API dle národního standardu. Licenčně je komponenta poskytnuta v režimu multilicence.
108	Součástí plnění bude poskytnutí odborného specialisty na pozici Projektového vedoucího metodika, který bude k dispozici v místě plnění po celou dobu průběhu projektu, maximálně však v roszahu 30 ČD (člověkodnů) práce ve prospěch zadavatele.	ANO	Předmětná služba je součástí předmětu plnění.
109	Součástí plnění bude poskytnutí architekta pro oblast IS (SSL, AIS) v místě plnění v rozsahu 10 ČD práce ve prospěch zadavatele.	ANO	Předmětná služba je součástí předmětu plnění.

Příloha č. 2 smlouvy o dílo

TECHNICKÁ SPECIFIKACE ZHOTOVITELE

Spisová služba – technické požadavky

Účel řešení

Poptávané řešení pokryje oblast elektronické spisové služby vč. subsidiárního nástroje pro dlouhodobé důvěryhodné ukládání dokumentů v roli elektronické spisovny, tj. informačního systému vybudovaného na principech mezinárodního standardu Open Archival Information Systém (ISO 14721:2012), který slouží k uložení elektronických dokumentů a dat (a to po dobu skartačních lhůt daných legislativou nebo vnitřními předpisy nemocnice) nebo k trvalému uložení těchto dat po dobu jednotek až desítek let.

Tento systém musí zajistit, že po celou dobu péče o tyto data budou tato udržována v čitelném stavu, který je umožní interpretovat a na aktuálním běžném SW vybavení prezentovat. Zároveň je ukládá takovým způsobem, který umožní věrohodně prokázat, že data nebyla po celou dobu svého uložení pozměněna a jedná se tedy o jejich původní podobu. Způsob péče o data musí být zároveň v souladu s platnou legislativou. Systém bude primárně určen k ukládání vyřízených dokumentů a uzavřených spisů elektronické spisové služby. Toho tento systém dosáhne splněním požadavků uvedených v následujících kapitolách.

Legislativní požadavky

Oblast musí naplňovat požadavky dané následující legislativou:

Zákon č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů, ve znění pozdějších předpisů

soulad s čl. II, odst. 2 zákona č. 190/2009 Sb., kterým se mění zákon č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů, ve znění pozdějších předpisů

Zákon č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů

Vyhláška č. 259/2012 Sb., o podrobnostech výkonu spisové služby Vyhláška č. 259/2012 Sb., o podrobnostech výkonu spisové služby

Národní standard pro elektronické systémy spisové služby, VMV část 57/2017 (část II)

Zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, ve znění pozdějších předpisů

Vyhláška č. 193/2009 Sb., o stanovení podrobností provádění autorizované konverze dokumentů

Vyhláška č. 194/2009 Sb., o stanovení podrobností užívání a provozování informačního systému datových schránek, ve znění pozdějších předpisů

Zákon č. 111/2009 Sb., o základních registrech, ve znění pozdějších předpisů

Zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších

zákonů, ve znění pozdějších předpisů

Zákon č. 297/2016 Sb., o službách vytvářejících důvěru

požadavky Národního standardu pro elektronické systémy spisových služeb

Uvedené parametry a vlastnosti řešení v níže uvedené tabulce znamenají minimální míru plnění dle

ZD. Předmětná tabulka je zahrnuta v rámci Přílohy č. 1 této Smlouvy.

Technický popis SYSTÉMU

Grafické schéma a podrobný popis architektury SYSTÉMU

Nabízené řešení je postaveno na systémech společnosti ICZ a.s.

Při vývoji jednotlivých součástí řešení jsou využívány moderní technologie, zahrnující např. využití platformy JAVA, komunikaci prostřednictvím webových služeb dle protokolu SOAP a další. Jednotlivé komponenty řešení poskytují popsané aplikační rozhraní, které umožňuje externím systémům využít dat a služeb těchto komponent. Pro uložení dat je využívána relační databáze.

Architektura systému ICZ e-spis ®

Aplikace ICZ e-spis ® je vytvořena v třívrstvé architektuře. Jednotlivé vrstvy spolu komunikují prostřednictvím XML rozhraní.

Datová vrstva realizuje napojení na konkrétní datový zdroj tak, aby ostatní vrstvy byly od této problematiky odstíněny. Jejím úkolem je přijmout požadavek na konkrétní data, tato data získat z databáze či jiného zdroje dat a vrátit je ve formátu XML.

Aplikační vrstva zajišťuje funkční logiku komponenty. Vstupy ve formátu XML získává z datové vrstvy, výstupy (opět ve formátu XML) poskytuje prezentační vrstvě.

Prezentační vrstva řeší vizuální prezentaci dat, které získá od aplikační vrstvy. Data získaná ve formátu XML převádí do formátů HTML, PDF a dalších.

Obrázek: Architektura aplikace ICZ e-spis ®

Pro provoz aplikace ICZ e-spis ® pro zadavatele bude poskytnuta multilicence pro neomezený počet uživatelů. Bude vybudováno testovací/školící prostředí a prostředí produkční.

Přehledný popis SYSTÉMU

Produkt spisová služba ICZ e-spis ®

Plnění dle ustanovení ZD, resp. přílohy č. 3. b je navrženo systémem ICZ e-spis ® dle níže uvedené specifikace a dále v souladu s předmětnou přílohou ZD.

Základní popis systému ICZ e-spis ®

Aplikace ICZ e-spis ® je moderní třívrstvá aplikace, při jejímž vývoji byl kladen důraz zejména na standardizaci použitých technologií, komponentovou architekturu a maximální jednoduchost a intuitivnost ovládání.

Z těchto důvodů byly použity technologie JAVA, XML, XQW a ODBC. Tyto technologie zaručují možnost provozu na všech hlavních platformách (AIX, Microsoft Windows, Linux, UNIX) bez zásadních zásahů do infrastruktury zákazníka a využití nejlepších databází na trhu (Microsoft SQL Server, ORACLE).

Dalším důsledkem použitých technologií je jednoduchá možnost rozšiřování aplikace o další moduly a funkcionality a jednoduché zapracování legislativních změn.

Aplikace ICZ e-spis ® je navržena s ohledem na mnoho často se opakujících činností. Proto byly nejčastěji používané funkce optimalizovány a celkově byl kladen velký důraz na maximální ergonomii ovládání.

Potřeby HW a SW

Na straně koncového uživatele

Aplikace ICZ e-spis ® komunikuje s uživatelem prostřednictvím webového rozhraní. Pro bezproblémovou funkčnost je tedy nutný některý z podporovaných internetových prohlížečů z tabulky, která se nachází níže. Dle charakteru práce jednotlivých uživatelů v aplikaci ICZ e-spis ® je vhodné doplnit pracovní stanice běžným kancelářským software.

Minimální HW nároky na koncovou stanici z pohledu aplikace ICZ e-spis ® jsou pak dány minimálními nároky operačního systému a některé z podporovaných verzí internetového prohlížeče.

PRODUKT		PODPOROVANÁ VERZE
	Internet Explorer (32bit) Operační systém	11 WINDOWS 7, WINDOWS 10 (plný doménový název – FQDN)
	Firefox ESR (32bit) Operační systém	52.8 není platformě omezeno

	Java	1. 8. 131 – 171
	Adobe Reader	11, DC
	MS Office (pro přímou editaci dokumentů1) LibreOffice (pro přímou editaci dokumentů)	2013, 2016 5.5
	SW602 Form Filler	4.70

Na straně serveru

Celé řešení je postaveno na přenositelných technologiích (Java, XML) a lze jej tedy provozovat na různých HW a SW platformách, které podporují platformu Java Enterprise Edition (J2EE).

Z hlediska standardního software je potřeba mít na databázovém serveru k dispozici výrobcem databáze podporovanou verzi operačního systému a dále mít vyřešenu otázku licenční politiky vůči databázi. Systémem ICZ e-spis ® podporované databáze podporují i nástroje pro fulltextové vyhledávání, které je potřeba mít nainstalované na úrovni databázového serveru.

SW

Aplikaci ICZ e-spis ® je možno provozovat na aplikačních serverech typu Microsoft Windows, Linux, Solaris a na pracovních stanicích s instalovaným operačním systémem Microsoft Windows, Linux a výše specifikovaným internetovým prohlížečem.

Jediným požadavkem je podpora provozního prostředí Oracle JDK ve verzi aktuálně podporované aplikací ICZ e- spis ® . Nad ním je potřeba mít nainstalován vhodný Java aplikační engine se servletovým rozhraním a dále pak robustní WWW server s podporou potřebných autentifikačních postupů (např. SSL). Dodavatel řešení doporučuje a též běžně provozuje java kontejner TomCat, který splňuje uvedené požadavky a je šířen pod licencí GNU/GPL, což znamená, že je šířen zdarma.

Další software (jako jsou např. antivirové programy, software pro firewall, síťové komunikační programy, apod.) není vyžadován. Tento typ SW je plně v kompetenci zákazníka.

PRODUKT PODPOROVANÁ VERZE

1 Podporovaná verze MS OFFICE na koncové stanici uživatele se vztahuje pouze k modulu „Přímá editace“. Pro otvírání elektronických příloh dokumentů je nutné mít na PC nainstalován odpovídající SW, který je kompatibilní s danou přílohou. Otvírání elektronických příloh dokumentů se řídí nastavením daného PC. Změnu nastavení programu pro otevírání daného typu souboru je možné přes volbu „Otevřít v programu“ na vašem PC.

	Windows Server	2008, 2008 R2, 2012 R2
	Linux	Na verzi nezáleží, pokud umožní práci s aktuálně aplikací e-spis podporovanou verzí Java SE
	Oracle JDK	1.8
	TomCat	8.0
	MS SQL Server	2008 R2 SP3 a SP4, 2012, 2014 (v kompatibilním režimu)
	Oracle Database	11.1, 11.2, 12.1 SE2, 12.1 EE
	MS Office 32bit (pro konverzní modul)	2013, 2016 (Office 365 – SMTP – bez autentizace)

HW

Pro provoz řešení předpokládáme využití vyhrazeného aplikačního serveru pro aplikaci ICZ e-spis ®

a samostatného databázového serveru.

Základní moduly a funkce ICZ e-spis ®

Spisová služba

Spisová služba ICZ e-spis ® (ESSS) je systém specializovaný na podporu evidence zpracování a oběhu dokumentů. Spisová služba ICZ e-spis ® je určena jak pro evidenci zpracování dokumentů v klasické papírové podobě, tak v podobě elektronických dokumentů.

Spisová služba umožňuje náhled na elektronický spis občanovi, který musí mít možnost se seznámit se spisem, jednotlivými dokumenty v „jeho“ správním řízení. Ze zákona takto postupují všechny správní orgány, pokud vymáhají nebo vybírají různé poplatky a pokuty, a také organizace, které poskytují informace daňovému subjektu dle daňového zákona.

Spisová služba se zaměřuje na procesní část zpracování dokumentů a jejich životního cyklu uvnitř organizace v souladu s vyhláškou o vedení spisové služby. Je určena pro řízení zpracování dokumentů od vstupu do organizace např. na podatelně (doručená korespondence), přes přidělení dokumentu zpracovatelskému útvaru a konkrétnímu zpracovateli, zpracování odpovědi a vypravení (odeslaná korespondence), včetně sledování souvisejících podkladů, např. žádost o zpracování posudku a vyjádření jiných útvarů (vnitřní dokumenty). Dokumenty příslušející k sobě jsou spojeny do spisu. Uzavřené a schválené dokumenty a spisy se ukládají ve

spisovně. Následně je řešena archivace a skartace na základě věcných skupin, skartačních operací a lhůt. Systém řeší jednotné přidělování čísel evidenčních (UID) a čísel jednacích (ČJ). Systém podporuje kromě zpracování dokumentů, také řídící činnost v organizaci. Vedoucí může přidělovat a kontrolovat práci svých podřízených a stav vyřízení jednotlivých dokumentů.

Podstatou práce uživatele v systému je práce s virtuálním "pracovním stolem", na který "přicházejí" dokumenty přidělené uživateli k vyřízení. Oběh dokumentů mezi jednotlivými pracovními stoly zajišťuje systém spisové služby. Oběh dokumentů/spisu je možno předdefinovat pomocí referátníku (workflow proces). O všech krocích zpracování dokumentu se vedou záznamy v historii, takže je možno zpětně určit kdo, kdy a jak s dokumentem pracoval. Systém podporuje osobní odpovědnost za zpracování - v historii se zaznamenává nejen funkční místo, které činnost provedlo ale i jméno konkrétního uživatele.

Ke každému dokumentu/spisu evidovanému v ICZ e-spis ® jsou definována určitá přístupová práva. Přístupová práva se ve spisové službě vztahují na funkční místa, nikoliv na konkrétní uživatele. Důsledkem toho je, že při změně obsazení funkčního místa jiným uživatelem, přebírá nový uživatel všechna práva k dokumentům daného funkčního místa. Přístupová práva jsou aplikací nastavována automaticky podle fáze životního cyklu, ve kterém se dokument nachází, a podle toho, kde v organizaci je dokument právě zpracováván.

Pro každý ze stavů zpracování lze v konfiguraci systému definovat přístupová práva pro jednotlivé prvky organizační struktury (pouze čtení, čtení/zápis, bez přístupu, …). Definice výchozího nastavení přístupových práv pro jednotlivé fáze životního cyklu dokumentu bude součástí implementačního projektu. Administrátor může toto nastavení měnit podle konkrétních specifických požadavků provozu.

Pro dokumenty zpracovávané spisovou službou je charakteristické, že mají svůj právní význam a jejich řádná evidence a zpracování patří k zákonným povinnostem organizace.

Produkt spisové služby má pro uživatele k dispozici jednoduché, intuitivní uživatelské rozhraní pro Internetový prohlížeč (Internet Explorer, Mozilla) – viz obrázek níže. Produkt je koncipován tak, aby jeho vlastnosti (uživatelé, typy dokumentů, složky a další) byly dynamicky přizpůsobitelné potřebám organizace. Produkt disponuje definovaným programovým rozhraním pro integraci s jinými systémy a aplikacemi.

Obrázek: Uživatelské rozhraní systému spisové služby

Obrázek: Profil dokumentu

Elektronická podatelna a výpravna

Elektronická podatelna řeší zejména příjem a odesílání e-mailových zpráv opatřených kvalifikovaným elektronickým podpisem dle zákona č. 297/2016 Sb. O službách vytvářejících důvěru pro elektronické transakce v platném znění. Kromě těchto typů zpráv lze v elektronické podatelně řídit i způsob zpracování ostatních e- mailových podání doručovaných na elektronické adresy podatelny.

Elektronická podatelna je předřazena modulu ESSS spisové služby a provádí všechny operace nutné ke zpracování přijatých e-mailových podání – kontroluje e-mailové podání a dokumenty v něm obsažené, zda odpovídají požadavkům na doručení dokumentů, kontroluje, zda e-mailové podání a v něm obsažené dokumenty, jsou opatřeny uznávaným elektronickým podpisem, uznávanou elektronickou značkou a kvalifikovaným časovým razítkem a ověřuje jejich platnost. Elektronická podatelna zasílá potvrzení o doručení e-mailového podání nebo o zamítnutí s uvedením důvodů zamítnutí přijetí e-mailového podání odesílateli podání. O výsledku kontroly a ověření elektronická podatelna provádí a ukládá záznam.

E-mailové podání spolu s protokoly je dále předáno k dalšímu zpracování, kde pověřený zaměstnanec provádí příjem a evidenci doručených e-mailových podání a jejich přidělení ke zpracování určeným organizačním jednotkám. Zaevidovaný dokument v ICZ e-spis ® obsahuje jednak popisná metadata a dále elektronické dokumenty z doručeného e-mailového podání (tj. tělo zprávy a jednotlivé přílohy obsažené v doručeném e- mailovém podání).

Odesílateli e-mailového podání aplikace potvrdí doručení podání na elektronickou adresu odesilatele, ze které bylo podání odesláno. V případě, že doručené e-mailové podání nevyhovuje stanoveným podmínkám pro přijetí podání, je podání automaticky nebo na základě rozhodnutí uživatele zamítnuto. V každém případě je odesílateli odeslána emailová zpráva s důvodem zamítnutí.

Texty notifikací spolu s kritérii pro příjem e-mailových podání může upravit administrátor aplikace. Modul elektronické podatelny provádí následující operace:

Přijetí e-mailového podání, kontrolu těla e-mailu a el. příloh, jsou-li podepsány, na platnost elektronického podpisu a certifikátu, odeslání notifikací adresátovy (dle zvoleného nastavení zákazníkem).

V rámci implementace je systém spisové služby konfigurován tak, že umožní:

Zaevidování dokumentu z elektronické podatelny včetně uložení příloh, vrácení jednacího čísla zaevidovaného dokumentu, předání dokumentu k vypravení do elektronické podatelny, přijetí zpětného hlášení o odeslání.

Modul elektronické podatelny datových zpráv

Modul zahrnuje činnosti spojené s příjmem a odesíláním elektronických zpráv z/do Datových schránek. Zároveň je v aplikaci spisové služby ICZ e-spis ® doplněna podpora činností podatelny, výpravny a referenta spojených s komunikací s ISDS včetně služby zjištění existence Datové schránky konkrétního subjektu.

Modul zajišťuje pro spisovou službu vlastní komunikaci s ISDS a dále plní povinnosti stanovené jí legislativou:

Vedení evidence o přijatých a odeslaných zprávách, kontrola na škodlivý kód, kontrola el. příloh, jsou-li podepsány, na platnost elektronického podpisu a certifikátu, ukládání originálu zpráv, vedení žurnálu událostí.

Příjem listinných podání

Příjem listinných zásilek probíhá v aplikaci ve speciálním formuláři, který mají k dispozici pracovníci podatelny. Tento formulář je optimalizován právě pro činnosti spojené s hromadnou evidencí dokumentů. Uživatel zde může zaznamenat všechny informace spojené s povahou zásilky a subjektu, od kterého byla doručena. V případě, kdy již bylo v minulosti s tímto subjektem komunikováno, je možné jej vybrat z adresáře subjektů, který aplikace obsahuje. Po evidenci dokumentu je možné nechat na tiskárně čárových kódů vytisknout štítek s čárovým kódem, kterým lze nahradit podací razítko. Čárový kód pak lze použít i při oběhu dokumentu mezi zpracovateli a je nutným předpokladem pro digitalizaci dokumentu. Tiskárna čárových kódů, ani skener nejsou součástí této nabídky.

Vlastní dokument

Každý z uživatelů má možnost založit dokument pocházející z jeho vlastní tvorby. Při evidenci dokumentu pak uživatel musí vyplnit alespoň povinná pole (povinná pole může opět definovat administrátor). Pro zrychlení práce, aplikace disponuje funkcionalitou, díky které je možné definovat tzv. „šablony dokumentů“. Šablona dokumentu je vlastně předvyplnění metadatových polí a najde využití u stále se opakujících dokumentů, což má za následek zvýšení uživatelského komfortu.

Přidělování ČJ

Přidělování čísel jednacích probíhá v aplikaci automaticky po evidenci dokumentu. Na podatelně mají uživatelé možnost dokument buď evidovat (a přidělit ČJ rovnou), nebo pokud si nejsou jisti, zda dokument do evidence patří, tak zvolit „Přijmout“. V takovém případě je dokumentu přidělen pouze jednoznačný identifikátor (UID) a o zanesení do evidence či jeho zrušení rozhodne až odborný referent. Formát přidělovaných čísel jednacích je možné definovat v nastavení aplikace.

Evidence dle agend

Jednou z povinných položek je u každého evidovaného dokumentu (vlastního i doručeného) pole „Typ dokumentu“. Typy dokumentů pak mohou odpovídat jednotlivým agendám, které budou v organizaci zpracovávány. V aplikace ICZ e-spis ® pak mohou být administrátorem nastaveny zvláštní číselné řady tzv. Agendová čísla, která lze navázat právě na položku Typ dokumentu.

Spisy

Aplikace ICZ e-spis ® plně podporuje tvorbu a práci se spisy, kdy každý vytvořený spis dostává označení ze speciální číselné řady určené pouze pro spisy, spisovou značku. Tato číselná řada může být opět definována administrátorem. Každý dokument vložený do spisu si ponechává své číslo jednací, pod kterým byl evidován a navíc od nadřízeného spisu přebere spisovou značku. Do spisů lze spolu s dokumenty vkládat i další spisy a to do maximálně třetí úrovně vnoření.

Vyhledávání

Vyhledávání je jednou z nejčastěji používaných funkcí při práci se spisovou službou a proto v aplikaci existuje mnoho způsobů, jak filtrovat a vyhledávat dokumenty. To, jaké dokumenty může uživatel vyhledat, se pak odvíjí od jeho oprávnění, kterým je níže věnována speciální kapitola. Filtrování dokumentů lze provádět v téměř každé složce v aplikaci pomocí uživatelem nastavitelných filtrů, které si může uložit. Ve výsledcích filtrování pak uživatel může vyhledávat pomocí všech dostupných sloupců v aktuálním zobrazení. Pro zdatnější uživatele existuje v zobrazeních možnost vytvářet komplexní logické vyhledávací dotazy, které je možné řetězit za sebe.

Všem uživatelům je k dispozici dále vyhledávání včetně rozšířeného vyhledávání napříč všemi složkami, kde uživatelé mohou využít plného vyhledávacího formuláře, ve kterém lze hledat podle kteréhokoli údaje, který je o dokumentu v aplikaci zaznamenán.

Některým uživatelům může administrátor přidělit rozšířená oprávnění na vyhledávání dokumentů, tito uživatelé jsou následně schopni nalézt jakýkoli dokument napříč aplikací.

Šablony Word dokumentů

Pro pohodlnější zpracování vlastních dokumentů je možné v aplikaci definovat šablony textových dokumentů ve formátu .DOC. Při vytváření dokumentu tak může uživatel využít této šablony, do které je možné na předem definovaná místa automaticky vyplnit hodnoty z metadatových polí, kterými jsou například ČJ, Věc a další.

Další vlastností aplikace je tzv. přímá editace dokumentů. Kdy uživatel nemusí při úpravách dokument ukládat do počítače, na kterém pracuje, provést úpravy a dokument opět nahrát zpět do aplikace jako novou verzi. Je totiž možné dokument otevřít přímo z aplikace, kdy dojde automaticky ke spuštění kancelářského programu MS Word a po provedení změn je dokument při uložení rovnou odeslán zpět do aplikace a verzován.

Pokud bude vše v organizaci vedeno metodicky správně a budou všechny odchozí dokumenty vycházet ze šablon v aplikaci, bude důsledkem sjednocení stylů použitých v dokumentech.

Referátník

Aplikace obsahuje, kromě řízení životního cyklu dokumentu/spisu, konkrétní implementaci workflow v podobě Referátníku. Referátník je předpis, který určuje kdo v jakém termínu a jak má s dokumentem/spisem (obecně s objektem spisové služby) pracovat. Pokud je k danému dokumentu přiřazen Referátník, systém zajistí, aby byl podle této definice předáván jednotlivým uživatelům (resp. funkčním místům). Navíc je možné dokument předat i mimo určený proces, např. pro doplnění dalšího mimořádného odborného posouzení nebo schválení.

Historie dokumentu/spisu zachycuje celý postup vyřizování, takže je možno zpětně analyzovat typické oběhy a vytvořit pro ně šablony procesů.

Úpravy dokumentů a verzování příloh

Jak již bylo napsáno v části Šablony Word dokumentů aplikace vytváří u el. příloh dokumentů jejich verze, mezi kterými se pak uživatel může pohybovat.

Sestavy a tisky

Aplikace obsahuje několik předdefinovaných sestav tisků. Jsou jimi například podací deník, poštovní podací arch a další. Mimo to má uživatel možnost tisku vlastních sestav dokumentů ze složek a zobrazení. Míra uživatelského nastavení jde až do té míry, kdy v zobrazení složky na počítači mohou být zobrazeny jiné sloupce o jiných šířkách, než jaké jsou použity pro tiskovou sestavu.

Avíza

Součástí aplikace je i systém upozorňování uživatelů pomocí e-mailových zpráv. Tyto zprávy obsahují jednoduchý popis a odkaz na dokument, ke kterému se váží. Nastavení avíz je opět plně v plné moci administrátora aplikace, který může jednotlivá upozornění nastavovat. Lze volit například z avíz týkajících se vypršení termínů k dokumentům, notifikacím o čekajícím dokumentu k převzetí atd. Každý z uživatelů má také

možnost si jednotlivá avíza deaktivovat, například pro případy, kdy zpracovává velké množství dokumentů a byl by avízy zahlcen. Avíza tak najdou uplatnění zejména u uživatelů, kteří s aplikací nepracují pravidelně.

Historie a Transakční protokol

Každý zásah uživatele je u každého objektu zaznamenán a to od prostého čtení až po jednotlivé změny. Tyto změny jsou u objektů k dispozici na speciální záložce „Historie“. U každé změny je pak uvedeno který pracovník operaci provedl, z jakého funkčního místa, jak vypadal dokument před provedenou změnou a jak vypadá po provedené změně.

Mimo těchto záznamů vede aplikace dle požadavků NSESSS Transakční protokol, do kterého jsou zaznamenávány všechny požadované informace. Ten se ukládá každý den ve výstupním formátu PDF/A s možností jeho opatření časovým razítkem nebo systémovou značkou. Toto nastavení je dostupné administrátorovi včetně toho, jakou věcnou skupinu a skartační znak má generovaný dokument převzít.

Odeslání dokumentů

Napříč celou aplikací je snaha o vytváření co nejmenších rozdílů ve zpracování listinných a elektronických dokumentů a nejinak je tomu i u vypravování. Pokud uživatel potřebuje odeslat dokument, založí k němu nové vypravení, u kterého vybere, komu chce vypravení dokumentu provést a jakou formou tak chce učinit. Při vyhledávání subjektu, kterému má být vypravení doručeno, je uživatel nucen nejdříve daný subjekt vyhledat. Vyhledávání se provádí nejprve v adresáři ISDS kvůli existenci datové schránky, která je pro doručování prioritní a až následně dojde k prohledání adresáře subjektů v aplikaci. Pokud ani tak uživatel subjekt nenajde, má možnost údaje zapsat ručně. Následně provede předání vypravení na výpravnu/podatelnu.

Elektronicky

U vypravení prováděných elektronickou formou a to jak e-mailem, tak DS je situace jednodušší, protože uživatel již vyplnil, komu je vypravení adresováno a jaké přílohy osahuje. V aplikaci lze také nastavit automatické odesílání DS. V takovém případě není nutné, aby s připravenými vypraveními cokoli dělal další uživatel – viz Automat DZ.

Listině

U vypravení prováděných listinnou formou disponuje aplikace možností vytvářet šablony poštovních obálek. Na obálky pak může být vytištěna identifikace adresáta včetně poštovní adresy, čísla jednacího a mimo jiné i identifikátor obálky ve formě čárového kódu. Pokud organizace využije právě této funkcionality aplikace, povede to k dalšímu zvýšení uživatelského komfortu při práci s dokumenty, nicméně toto není nutnou podmínkou provozu. Oběh obálek lze realizovat i ručně bez použití čárových kódů a čteček čárových kódů.

Pro předávání dokumentů poskytovateli poštovních služeb je aplikace připravena i na standardní procesy s tím spojené, jako je například využití poštovních archů, nebo elektronických poštovních archů

Oprávnění

Oprávnění uživatelů na dokumenty vychází z organizační struktury. Tudíž uživatelé mají právo zacházet s dokumenty i do nich nahlížet jen v případě, že jsou jejich vlastníky, nebo se jedná o dokumenty uživatelů jim podřízených. V případech, kdy vznikne potřeba porušit toto hierarchické uspořádání přístupových práv, je v aplikaci dostupná funkce tzv. Registratur popsaných níže.

U všech ostatních nastavení přístupových práv, jakou jsou práva na typy dokumentů, různé šablony a podobně může práva uživatelům řídit administrátor aplikace.

Zastupování

Aplikace ICZ e-spis ® pracuje se systémem funkčních míst, která jsou zařazena do organizační struktury. Dokumenty a všechna oprávnění se váží právě na tato funkční místa a nikoli na konkrétního zaměstnance. Toto řešení je zejména vhodné při změnách zaměstnanců na funkčních místech, kdy stačí provést změnu uživatele a není třeba převádět všechny dokumenty a znovu nastavovat oprávnění. Pro případy zastupitelnosti má každý zaměstnanec možnost zvolit, kdo a případně na jak dlouho jej má zastupovat na jeho funkčním místě (zastupující pracovník si po vstupu do aplikace může vybrat, které funkční místo bude vykonávat). Možnost nastavit zástupy ostatním uživatelům má pouze administrátor, nebo vedoucí pro své podřízené.

Do historie a transakčního protokolu se zaznamenává jméno uživatele, který skutečně operace provedl a funkční místo ze kterého operace provedl.

Modul Katastry

V aplikaci ICZ e-spis® jsou katastrální údaje promítnuty do několika oblastí v evidenci dokumentů. K profilu doručeného i vlastního dokumentu, spisu a smlouvy lze evidovat údaje o katastru a parcelách. Jeden objekt může obsahovat údaje o více katastrech a každý z katastrů může mít na sebe navázán několik čísel parcel. O tyto údaje je doplněno i vyhledávání.

Oprávnění na dokumenty a spisy (Registratury)

Registratury umožňují uživatelům vytvářet strukturované pohledy na dokumenty. Jednotlivým úrovním strukturovaného pohledu říkáme registratura. Zařazením dokumentu do registratury získá uživatel snadnější přístup k dokumentu prostřednictvím věcného členění díky systému registratur. Dokument je možné začlenit do více registratur a využívat více věcných pohledů.

Registratury dále umožňují nastavení speciálních přístupových práv pro jednotlivé úrovně registratur, aby uživatelé podle zvolené úrovně mohli nahlížet nebo upravovat dokumenty, ke kterým jinak nemají přístupová práva.

Modul elektronického podpisu v souladu s eIDAS

Modul zahrnuje aplikační podporu podepisování elektronických příloh z prostředí spisové služby (tedy i těch zasílaných pomocí systému datových schránek), kde z povahy dokumentu vyplývá nutnost tyto elektronické přílohy podepisovat kvalifikovaným elektronickým podpisem úředníka.

Pro opatřování elektronických dokumentů kvalifikovaným elektronickým podpisem je systém ICZ e-spis ® doplněn funkcionalitou, umožňující uživateli z prostředí jeho pracovní stanice avšak stále v uživatelském prostředí ICZ e-spis ® tyto dokumenty podepisovat.

V těch procesních krocích životního cyklu dokumentu evidovaného ve spisové službě ICZ e-spis ®, kdy je nutné jej opatřit kvalifikovaným časovým razítkem, provádí systém ICZ e-spis ®, popřípadě modul elektronické podatelny datových zpráv toto automaticky.

V uživatelském prostředí ICZ e-spis ® je pro každého oprávněného pracovníka složka K podpisu, ve které jsou zobrazovány elektronické přílohy, jež referenti označili pro podepsání (jednotlivé/hromadné podepisování vč. jednotlivé/hromadné konverze dokumentů).

Ověřování v souladu s článkem 32 nařízení eIDAS a souvisejícími normami pro ověřování kvalifikovaných elektronických podpisů, kvalifikovaných elektronických pečetí a kvalifikovaných časových razítek musí být prováděno pro dané typy podpisů, značek a pečetí, a to pro certifikáty vydané důvěryhodným poskytovatelem z kterékoliv členské země EU.

Vytváření podpisů a pečetí

Systém ICZ e-spis ® je rozšířen o podporu nástrojů pro vytváření kvalifikovaných elektronických podpisů, jejichž soukromý klíč je uložen na kvalifikovaném prostředku. Zároveň je možné systém integrovat i s kvalifikovaným prostředkem pro vytváření pečetí – HSM. Vytvoření této integrace není součástí nabídky uchazeče, neboť v ZD nebylo definováno.

Obrázek: Podepisování

Ověřování

Ověřování v souladu s článkem 32 nařízení eIDAS a souvisejícími normami pro ověřování kvalifikovaných elektronických podpisů, kvalifikovaných elektronických pečetí a kvalifikovaných časových razítek musí být prováděno pro níže uvedené typy podpisů, značek a pečetí, a to pro certifikáty vydané důvěryhodným poskytovatelem z kterékoliv členské země EU.

Na níže uvedeném obrázku, který znázorňuje chování modulu elektronického podpisu, jsou znázorněny:

- varianta standardního ověřování prostředky modulu eIDAS,

- varianta ověřování prostředky nástroje třetí strany (integrační práce nejsou součástí této nabídky),

- varianta ověřování podpisu s využitím kvalifikované služby ověřování platnosti kvalifikovaných elektronických podpisů. (integrační práce nejsou součástí této nabídky).

Obrázek: Ověřování

Obrázek: Udržování důvěryhodnosti

Modul důvěryhodnosti (důvěryhodné úložiště)

Tento modul slouží k ukládání elektronických dokumentů pro potřeby spisové služby tak, aby byla zachována jejich průkaznost a důvěryhodnost z pohledu platnosti obsahu, popřípadě přiřazených autentizačních prvků.

Z technického pohledu se jedná o komponentu elektronické spisové služby (ESS) ICZ e-spis ® vytvářející služby pro manipulaci s elektronickými soubory, resp. jejich binární podobou.

V ESS ICZ e-spis ® jsou uchovávány elektronické přílohy dokumentů, např. došlé datové zprávy, skenované došlé dokumenty i soubory vytvořené zaměstnanci. Tyto soubory jsou ukládány buď v databázovém úložišti komponenty ICZ - tDMS DB nebo v souborovém úložišti ICZ tDMS FS. Rozdíl ve fungování je ve způsobu ukládání elektronických dokumentů a to buď ve formě „blob“ položek v databázi nebo jako klasické digitální soubory na souborový systém.

Funkcemi systému jsou:

• ukládání

• verzování obsahu

• vyzvedávání pro další použití

• vyhledávání v obsahu

• uchování informací o době platnosti autentizačních prvků

• atd.

ESS ICZ e-spis ® je vybavena možnostmi fulltextového vyhledávání nad obsahem elektronických příloh objektů ESS. Používá-li ESS ICZ e-spis ® komponentu tDMS DB, je pro službu fulltextového vyhledávání využito nativní vlastnosti databáze. V případě využívání komponenty tDMS FS je pro fulltextové vyhledávání využíváno externí služby Apache Solr, která je součástí distribuce komponenty tDMS FS.

Modul důvěryhodného ukládání (tDMS) je standardně implementován v ESS ICZ e-spis ® pro služby validace a vytváření autentizačních prvků a služby převodu datových formátů.

Modul konverze do výstupního formátu

Tento modul zabezpečuje konverzi elektronických příloh do definovaného jednotného výstupního formátu PDF/X. Xxxxx je určen pro přípravu příloh před případným podepsáním a elektronickým odesláním (ISDS, mail, datový nosič).

Automat DZ

Modul Automat DZ slouží k automatickému příjmu a odesílání DZ dle nastavení dané organizace. Je možné nastavit časové intervaly, kdy budou DZ odesílány a kdy přijímány bez nutné asistence pracovníka výpravny či podatelny. Autentizace vůči ISDS je prováděna pomocí komerčního serverového certifikátu a to pro každou DS zákazníka zvlášť.

Tím je v organizaci šetřena jak práce zaměstnanců, tak i strojový čas, kdy stahování či odesílání může být naplánováno do nočních hodin, kdy na serverech nikdo nepracuje.

Modul Automat DZ však nevylučuje manuální stažení či odeslání DZ v případě, že je tak během práce potřeba.

Integrační modul REX

Modul REX (REgistry proXy) společnosti ICZ a.s. je komponentou zprostředkující produktům společnosti ICZ a.s. služby základních registrů v souladu s platnou legislativou (zejména se jedná o zákon 111/2009 Sb., o základních registrech) a zásadami ochrany osobních údajů.

Modul zprostředkovává definovanou podmnožinu služeb vnějšího rozhraní ISZR (Informačního systému základních registrů) při respektování pravidel připojování AIS vůči ISZR, viz dokument Správy základních registrů

„Podmínky pro připojení Agendových informačních systémů do ISZR“. Tedy AIS musí disponovat autentizačními údaji vůči ISZR, modul REX je pouze využívá.

Základní vlastnosti modulu REX

Umožňuje zprostředkování služeb ISZR pro více organizací (přesněji pro více orgánů veřejné moci – režim provozu „multicompany“) a více agend z těchto organizací.

Poskytuje zprostředkované služby RUIAN (registr územní identifikace a nemovitostí), ROS (registr osob) a ROB (registr obyvatel) prostřednictvím svého rozhraní webových služeb. Definice těchto služeb odpovídá WSDL (Web Services Definition Language) popisům služeb publikovaným ISZR.

Služby ROB jsou pro danou agendu a AIS poskytovány odděleně s využitím samostatného logického úložiště dat využívající pro každou evidovanou entitu přidělený agendový identifikátor fyzické osoby (AIFO).

Z RUIAN zprostředkovává služby územní identifikace.

Provádí žurnálování zprostředkovaných požadavků ve smyslu požadavků zákona o ZR.

Udržuje ve svých lokálních úložištích aktuální údaje ZR (RUIAN) v souladu s definovanou aktualizační politikou (např. aktualizace 1 x 24 hod apod.). Pro aktualizaci vlastní kopie referenčních údajů využívá notifikačních služeb ZR. Pokud vlastní kopie referenčních údajů modulu REX je aktuální, potom poskytuje služby s využitím této kopie (neprovádí synchronní dotaz do ZR).

Pro referenční údaje modul eviduje také informaci, kdy byl tento údaj naposled aktualizován a údaj, kdy byl naposled využit mechanismus pravidelné distribuce změn.

Fulltext

Systém ICZ e-spis ® disponuje fulltextovým vyhledáváním v el.přílohách dokumentů. Podmínkou vyhledání je existence textové vrstvy dokumentu.

Organizační struktura

Organizační struktura v aplikaci plně kopíruje organizační strukturu v organizaci. Aplikace ICZ e-spis ® pracuje se systémem funkčních míst, která jsou zařazena do organizační struktury. Dokumenty a všechna oprávnění se váží na tato funkční místa. Práva na dokumenty jsou dány zařazením funkčního místa v organizační struktuře, přidělenou rolí či individuálním nastavením pro daný dokument. Role v ICZ e-spis ® jsou definovány takto:

REFERENT VEDOUCÍ SEKRETARIÁT PODATELNA VÝPRAVNA SPISOVNA

ADMINISTRÁTOR

Modul Statistiky

Spisová služba, případně další její rozšiřující moduly Jednání, Úkoly a Smlouvy, evidují celou řadu údajů o dokumentech zpracovávaných úřadem. Tyto údaje v souhrnné formě poskytují informace pro řízení úřadu (např. počty vyřízených dokumentů jednotlivých typů, počet vypravených dokumentů, počet zpracovávaných dokumentů nebo smluv jednotlivými pracovníky).

Modul Statistika umožňuje na základě pravomocí uživatele vytvořit statistický přehled dle vlastních potřeb, zobrazit a vytisknout údaje souhrnnou formou. Přehled je možné exportovat do CSV souboru pro další zpracování.

Modul umožňuje vytvořit přehledy z šesti základních zdrojů údajů:

údaje o dokumentech nebo spisech,

údaje o vyřizování, údaje o vypraveních, údaje o doručeních,

údaje o převzatých nebo předaných dokumentech, údaje o provedených akcích s dokumenty.

Skenování a tisk čárových kódů

Systém ICZ e-spis ® obecně umožňuje práci jak se štítky s předtištěnými čárovými kódy, tak s vlastním tiskem štítků s čárovým kódem.

Modul umožňuje tisk štítků s čárovým kódem, který nahrazuje otisk podacího razítka (označení původce, datum doručení, číslo jednací, počet listů a příloh), a v případě skenování dokumentu i automatizované rozdělení naskenované dávky a uložení pořízeného obrazu dokumentu k zaevidovanému záznamu ve spisové službě.

Skenovaní pracoviště

Pro svůj provoz na klientské stanici musí být vybaveno dostatečnou pamětí (při skenování je obraz ukládán nekomprimovaně do paměti stanice). Doporučená konfigurace procesor Intel Pentium III, 1 GB RAM, HDD 10 GB, NIC 100 Mb/s, SCSI-2, monitor s uhlopříčkou 17“, MS Windows 2000/XP. Pro podporu rozpoznávání BarCode z neskenovaných image musí být na stanici instalován OCR SW.

Modul Automatizovaných procesů

Nástroj, který umožní správci ESS vytvářet strukturovaná pravidla pro sledování klíčových událostí, prováděných uživateli v aplikaci ESS, a na základě vyhodnocení kritérií dané události provádět následné automatické akce – procesy – nad objekty ESS (tj. dokumenty, spisy nebo ukládacími jednotkami).

Modul je navržen tak, aby kritéria událostí, tj. podmínky pro spuštění procesů, pracovaly ve smyčce, čímž je umožněno jednoduché řetězení procesů nad objekty ESS, tedy vytváření procesních workflow nad dokumenty, spisy nebo ukládacími jednotkami.

V modulu "Automatické procesy ESS" je možné sledovat události:

• úprava profilu

• změna stavu aktivity

• změna stavu vypravení

• vložení do registratury - událost je vázána na doplňující modul Registratury)

A aplikovat tyto procesy:

• předání spisovně

• úprava profilu

• vyřízení

• předání externí aplikaci

• předání oběhem

• založení spisu

• založení odpovědi

• (vložit do registratur - proces je vázán na doplňující modul Registratury)

Vizualizace el. podpisu

Tento modul umožňuje uživateli při podepisování dokumentu prostřednictvím aplikace ICZ e-spis ® přidat

vrstvu s vizualizací informací o el. certifikátu, kterým byl dokument podepsán.

Do informací o podpisu je možné doplnit informace o důvodu podpisu a místě podpisu. Tato pole jsou nepovinná.

Vizualizovaný podpis je možné vložit pouze do souborů formátu PDF nebo PDF/A.

Publikace dokumentů na úřední desku (eDeska)

Rozšíření funkčnosti systému spisové služby o modul eDeska umožňuje publikování dokumentů na elektronickou úřední desku, stejně jako publikaci do internetových stránek úřadu.

V rámci činností (publikování informací a využívání informací) definujeme práci s eDeskou formou rolí, jaké v přípravě dokumentů, nebo naopak využívání dokumentů, přijímají jednotlivé osoby (pracovníci úřadu a klienti úřadu).

Role Občan

Občan využívá informace zveřejňované prostřednictvím modulu eDeska na internetové stránce úřadu, případně přímo na elektronické úřední desce úřadu, má-li úřad k dispozici vhodné HW vybavení.

V uživatelském prostředí eDesky může občan:

Sledovat dokumenty zveřejněné úřadem

Vytvářet seznam dokumentů dle základních kritérií (aktuální, k určitému datu,…)

Vyhledávat dokumenty

Zobrazit detaily dokumentu

Zobrazit připojené elektronické přílohy dokumentu

Role Referent

Zajišťuje přípravu dokumentů určených k vyvěšení na úřední desce, přičemž dokumenty jako takové nejsou měněny oproti stavu, v jakém jsou evidovány v systému spisové služby.

Role Správce úřední desky

Správce úřední desky zajišťuje, v rámci využívání a nastavení modulu eDeska v systému spisové služby ICZ e-spis

®, následující činnosti:

Export dokumentů (nová vyvěšení, svěšení a aktualizace vyvěšení) na eDesku

Rozšíření atributů pro přímé vyvěšení dokumentů o termín vyvěšení doručujícím orgánem Export (XML a souborů na desku úřadu) je prováděn buď ručně, nebo automaticky systémem. Integrace eDesky na systémy třetích stran

Pro integraci a propagaci dat z eDesky na systémy třetích stran slouží API rozhraní eDesky. Součástí této nabídky není součinnost Uchazeče při realizaci integrace eDesky na AIS systémů třetích stran.

Hromadné odesílání

Modul hromadného odesílání dokumentů umožňuje v rámci výkonu spisové služby jednorázově odesílat velké množství vypravení.

Práce s modulem je koncipována tak, aby měla co nejuniverzálnější použití. Z toho pak vychází i množství položek, které je možné konfigurovat a tím zvýšit užitnou hodnotu tohoto modulu.

Ve zkratce uživatel připraví CSV soubor dle dané definice. Ten je pak nahrán do aplikace s možností připojit ZIP soubor s el. přílohami, které se budou odesílat. Během přípravy vypravení má uživatel možnost konfigurovat, která výpravna bude pro odeslání použita, text způsobu vyřízení a může aktivovat kontroly pro doručení a automatické vyřízení.

Modul je možné použít v následujících módech:

• založen 1 dokument (nový) s jedním vypravením

• založen 1 dokument (nový) s N vypraveními

• založeno N dokumentů (nových) s jedním vypravením

• založeno X vypravení k již existujícímu dokumentu (dle UID)

Modul elektronická skartace

Modul je určený pro komunikaci s příslušným archivem. Modul umožňuje:

• Vygenerovat elektronický skartační návrh – tj. vygenerovat SIP balíčky určené k odeslání do příslušného archivu dle NSESSS2 respketive NSESSS3 bez komponent (el. příloh).

• Po posouzení archivu vygenerovat v případě nejasností nový SPI balíček včetně komponent (el. příloh).

• Import rozhodnutí archivu po posouzení obsahu skartačního návrhu – rozhodnutí obsahuje změněné skartační znaky u jednotlivých objektů, popř. rozhodnutí a odložení skartace.

• Schválení a export archivem vybraných archiválií k trvalému uložení.

• Zpracování potvrzení o přejímce archiválií.

• Odmazávání balíčků (tedy souborů mets a elektronických příloh) z úložiště, stav skartačního návrhu se změní na „Skartace a archivace ukončena“ a v aplikaci zůstane k dispozici pouze povinná hlavička metadat (detail balíčku se všemi záložkami).

Statistiky časových razítek

Modul umožňuje vytvářet statistiky časových razítek dle důvodu čerpání.

Vyřízeni a přesun do Správy spisovny

Řešení umožní vyřízení dokumentů v držení některých funkčních míst, které mají v držení velký počet dokumentů a umožní jejich předávání do Spisovny. Řešení bude využívat Modulu automatizovaných procesů, který byl popsán výše. Pomocí automatizovaných procesů budou definovány následující procesy

• proces Vyřízení dokumentu – proces umožní automatické vyřízení dokumentů splňujících stanovená kritéria, automatický proces provede nastavení atributů Typ dokumentu, věcná skupiny a způsob vyřízení a vyřídí dokument.

• proces Předat do spisovny – proces umožní stanovit spisovnu pro předání a volbu zda mají být předané objekty rovnou převzaty, tj. předány bez kontroly přebíraných dokumentů/spisů pracovníkem spisovny.

Hromadné předávání do SpSp/DESA - předat/převzít dle filtru

Řešení umožní hromadně předat objekty vybrané na základě filtračních kritérií do spisovny. Předání bude provedeno odloženou úlohou.

Plnička ukládacích jednotek

Řešení umožní nad vyhledanými a ukončeným objekty ve složce „Ukončené“, které mají společný některý se slučovacích prvků, hromadné vložení do již existující UJ. V případě, že UJ ještě není založena, dojde k jejímu založení automaticky. Řešení je vhodné pro případy, kdy jsou dokumenty/spisy ukládány do UJ podle společného klíčového, zpravidla agendového, označení např. např. IČ subjektu, RČ subjektu apod.

Modul Bezpečnostní kategorie

Tento modul umožňuje zaznamenání bezpečnostní kategorie v rámci profilu objektu a řízení přístupu k el. dokumentům.

Každému nově zakládanému objektu je automaticky přiřazena bezpečnostní kategorie "Veřejné". V aplikaci jsou založeny čtyři výchozí bezpečností kategorie, které nelze modifikovat. Stupně v rámci bezpečnostních kategorií určují přístup k el. dokumentům. Čím nižší číslo BK, tím vyšší stupeň zabezpečení el dokumentů.

Modul pro integraci CzechPOINT@Office

Integrace spisové služby ICZ e-spis ® s CzechPOINT@Office umožňuje zaevidování výstupu z autorizované konverze z moci úřední ve spisové službě.

Dokument z provedené konverze získá v ICZ e-spis ® veškeré potřebné atributy vyžadované platnou

legislativou.

Modul v ICZ e-spis ® uloží výstupy z provedené konverze včetně ověřovací doložky.

PDF vzniklý spojením původního dokumentu bez el. podpisů a vytvořené doložky – v případě konverze

z elektronické do listinné podoby

PDF vzniklý spojením skenovaného obrazu, doložky, podepsáno certifikátem uživatele a časovým razítkem

CzechPoint – v případě konverze z listinné do elektronické podoby Integrace umožňuje oba dva typy konverzí:

Z listinné podoby do elektronické

z elektronické podoby do listinné

Součástí modulu je evidence provedených konverzí. Obsahuje následující položky: (ID doložky z detailu akce, UID objektu, ČJ objektu, ID komponenty z detailu akce, název komponenty z detailu, Pracovník, Datum akce, Ukázka ověřovací doložky.

Modul Publikace smluv do ISRS

Slouží k publikaci smluv v ISRS a následně ke svázání potvrzení o publikované smlouvě v ISRS.

Modul Smlouvy

Modul Smlouvy podporuje administrativní činnosti spojené s procesem zpracování smluv uzavíraných v

organizaci.

Modul je svázán s organizační strukturou úřadu, z níž vycházejí přístupová práva uživatelů. Modul Smlouvy umožňuje následující funkce:

Evidenci došlých i v organizaci vzniklých smluv s možností připojovat elektronické dokumenty,Kopie smluv, Evidenci dodatků platných smluv, Evidenci věcně související dokumentace smluv ve spisu, Nastavit interní číslování smluv i zaznamenat vlastní číslo smlouvy, Zaznamenat podstatné informace týkající se smlouvy jako je předmět smlouvy, smluvní strany, platnost a účinnost smlouvy, Hlídání termínů, Připomínkové řízení, Připojení a kontrolu úkolů (např. činnosti a plnění vyplývající ze smlouvy)

Podstatou práce uživatele v systému je práce s virtuálním "pracovním stolem", na který "přicházejí" smlouvy přidělené uživateli ke zpracování (např. vyřízení, schválení, posouzení). Oběh smluv mezi jednotlivými pracovními stoly je zajišťován systémem.

O všech krocích zpracování smluv se vedou záznamy v historii, takže je možno zpětně určit kdo, kdy a jak se

smlouvou pracoval.

Systém podporuje osobní zodpovědnost za zpracování – v historii se zaznamenává nejen funkční místo, které činnost provedlo, ale i jméno konkrétního uživatele. Aplikace řeší i problematiku zastupování pracovníků při jejich nepřítomnosti.

Aplikace je koncipována tak, aby její vlastnosti byly dynamicky přizpůsobitelné potřebám organizace (např. organizační struktura, typy dokumentů a další).

Aplikace je navržena tak, aby v případě změn legislativy nebo vnitřních předpisů mohly být tyto změny promítnuty bez zásahu do programového kódu aplikace, tj. změnou šablon a hodnot v číselnících.

V případě využití šablon el, dokumentu lze vytvořit návrh smlouvy.

Anonymizér

Slouží k anonymizaci dokumentů v organizaci.

Integrace dle NSESSS

Součástí aplikace ICZ e-spis ® je veřejné API dle Národního standardu pro elektronické systémy spisových služeb, který vydalo MV ČR 4.7.2017.

Modul Tisk etiket Modul Tisku etiket dává administrátorům a uživatelům možnost využít výhody plynoucí ze zpracovávání dokumentů pomocí čárových kódů v aplikaci ICZ ICZ e-spis®, a to bez nutnosti pořizovat speciální tiskárny pro tisk štítků čárových kódů, nebo si nechávat tisknout role se štítky předtištěnými.

Přímo v aplikaci je totiž s tímto modulem možné vytvořit šablonu tisknutých čárových kódů a nechat je vytisknout na standardní kancelářské tiskárně, která umí tisknout na archy samolepících etiket. Administrátor tak má možnost vytvořit šablonu štítků tak, aby odpovídala skutečným potřebám uživatelů.

Produkt ICZ IS DESA ®

Obecný popis systému ICZ DESA

Pro pokrytí požadavků na dlouhodobé ukládání dokumentů je nabízeno řešení ICZ DESA (Důvěryhodná Elektronická Spisovna a Archiv). ICZ DESA je dlouhodobé a důvěryhodné úložiště, které implementuje principy mezinárodního archivního modelu OAIS (ISO 14721). Systém implementuje opatření, která zajišťují dlouhodobé ukládání a péči o uložená data jako jsou:

- Opatření proti degradaci a zastarávání nosiče

- Veškerý obsah archivu bude ukládán paralelně, alespoň ve dvou identických fyzických kopiích. Tato problematika je popsána dále v textu. ICZ DESA obsahuje mechanismy pravidelné kontroly integrity uloženého obsahu a řešení situace, kdy je zjištěno, že jedna z kopií obsahu má porušenou integritu. Konkrétní specifikace fyzických úložišť je záležitostí implementační procedury.

- Opatření proti zastarávání systémového hardware a operačního systému

- S vývojem počítačových technologií je nutno počítat s tím, že se fyzická úložiště a média budou měnit. S vývojem počítačových technologií je nutno počítat s tím, že se bude měnit systémový hardware a jeho operační systém. Pro dlouhodobý archiv je nutno počítat s tím, že v nějakém období bude nutno celý archiv přemigrovat ze starého na nový systém. Proto provoz systému je rozdělen na tzv. provozní cykly odpovídající životnosti jednoho infrastrukturního systému (HW + OS). Délku trvání provozních cyklů není možné předvídat. Pravděpodobně nebude kratší než 10let. Většinou se počítá s délkou 15 let.

- Opatření proti zastarávání SW principů

- S vývojem počítačových technologií je nutno počítat s tím, že se budou měnit použité metody pro různé moduly systému. Pro některé použité metody, u kterých je předpoklad rychlého vývoje, je možnost změny přímo zaintegrována v systému (např. pro tzv. hashovací funkce – funkce pro výpočet kontrolních součtů zajišťujících integritu dat a jejich bezpečnost. Identifikace funkce použité pro konkrétní data/dokument je vždy uložena spolu s vypočítanou hodnotou). Změnu ostatních metod je nutno řešit individuálně podle situace (například odložením řešení na konec provozního cyklu a jeho vyřešení v rámci migrace na nový systém).

- Výše popsané principy jsou detailně rozebrány v kapitolách níže.

- Systém ICZ DESA existuje v několika edicích, z nichž každá je určena pro jiný typ dlouhodobé péče o data. Ke splnění požadavků uvedených v zadávací dokumentaci je vhodná edice DES – důvěryhodná elektronická spisovna.

Edice DES

Důvěryhodná elektronická spisovna (dále DES) řeší problematiku střednědobého a dlouhodobého, důvěryhodného uložení elektronických dokumentů a spisů v organizaci, která je definována legislativou i potřebami organizace.

Dokumenty a spisy vznikají a vyřizují se v různých systémech a aplikacích jako jsou např. elektronická podatelna, spisová služba, agendové systémy a aplikace apod. Tyto systémy zajišťují příjem dokumentů, přípravu, odesílání a spojování do spisů v rámci správního řízení či jiných odborných procesů organizace. Závěrečnou fází těchto procesů je vyřízení dokumentů a uzavření spisů (objektů). Uzavřené objekty se již nesmí měnit a pro jejich uchování je třeba postupovat předepsaným způsobem. Listinné dokumenty a spisy se předávají do analogových spisoven. Elektronické objekty se po uzavření ukládají do elektronické spisovny, kterou představuje DES.

Životnost dokumentů a spisů uložených ve spisovně je řízena spisovým plánem organizace. Uložené dokumenty a spisy zde čekají na skartační řízení. Po uplynutí skartační lhůty dojde buď ke skartaci (zničení) objektů, nebo k výběru za archiválie, které se předávají do nadřízeného digitálního archivu (např. Národní digitální archiv).

Tato edice je určena k ukládání dat dle standardu NSESSS3.

Specifikace systému

- Systém poskytuje otevřené API pro přístup z okolních systémů jako je spisová služba nebo digitalizační systémy.

- Data jsou v systému vždy minimálně ve dvou nezávislých kopiích (data nejsou replikována na HW úrovni).

- Data nelze nijak měnit ani mazat. Jediným způsobem jak data vyřadit je plánovaná skartace dle platné legislativy. I pak mohou být dokumenty v systému přítomny.

- Metadata s obrazovými daty jsou ukládána jako jeden datový balíček a jsou nezávislé na dodané

technologii.

- Při opravě dokumentu nebo jeho metadat dojde vždy k vytvoření další verze dokumentu. Všechny předchozí verze jsou vždy dostupné.

- Data se kromě ostré kopie mohou vyskytovat i v kopiích pracovních, které mohou být umístěny například na rychlejším, nebo geograficky dostupnějším zařízení.

- Vstup do systému je omezen výčtem akceptovaných formátů. Tento výčet je konfigurační položka a lze jej měnit.

- Před vstupem do systému je ověřena formální struktura a obsah datového balíčku, čímž je zajištěna jeho datová integrita.

- Před vstupem jsou dokumenty podrobeny dvojí antivirové kontrole.

- Uživatel může do archivu přistupovat přes webové rozhraní a dokumenty v archivu vyhledávat a stahovat. Rozsah dostupných funkcí je omezen seznamem oprávnění.

- Počet uživatelů není nijak omezen.

- Veškerá činnost systému i uživatelů je ukládána do transakčních logů, které se také ukládají jako archivní balíčky.

- Neměnnost balíčků je zaručena aplikací časového razítka.

- Po vypršení platnosti časového razítka dojde automaticky k aplikaci nového časového razítka vydaného certifikační autoritou. K pokusu o přerazítkování dojde automaticky a s dostatečným časovým předstihem v řádu měsíců.

- Razítkovat lze celé skupiny datových balíčků a šetřit tím náklady.

- Systém je připraven na budoucí změnu formátů a technologií a uložená data nejsou na systému ICZ DESA závislá.

Jednotlivé body, které popisují shodu s poptávaným řešením, jsou popsány v následujících kapitolách.

Obrázek: Architektura systému DESA

Soulad se standardy

Systém ICZ DESA implementuje pracovní postupy, procesy a datové formáty ve shodě s mezinárodními standardy pro dlouhodobé a důvěryhodné ukládání dat.

- Norma ISO 14721 – OAIS. Systém mimo jiné splňuje tyto požadavky, které jsou podrobně popsány v kapitolách dále

- Dokumenty a jejich metadata tvoří v rámci systému jeden balíček a jsou tak uloženy po celou dobu, po kterou je dokument přítomen v systému.

- Systém umožňuje příjem, uchování a výdej dokumentů ve formě balíčků SIP, AIP, DIP

- Řešení není svázáno s konkrétním formátem dokumentu nebo technologií a je připraveno na změnu těchto technologií.

- Systém podporuje migrační strategie na jiné formáty, technologie nebo kompletně jiný systém.

- Informace jsou v datovém balíčku uchovávány v otevřené podobě, tedy v takovém formátu, který lze číst běžně dostupnými prostředky, které nejsou závislé na dodávaném systému.

- Data jsou organizována na úrovni ukládacích jednotek, které odpovídají fyzickému uložení dokumentů ve spisovně/archivu.

- Norma ISO 15489 – Records management

- Národní standard pro elektronické systémy spisové služby (dále též NSESSS2 / 3)

Architektura ICZ DESA vychází z mezinárodně uznávaného standardu OAIS (ISO 14721:2003 – Open Archival Information System). Tento standard vymezuje základní koncepci systému pro uložení elektronických dokumentů. Standard definuje hlavní funkce, které má archiv zajišťovat. Jedná se o příjem dokumentů, správu dat, archivní uložení, přístup, administraci a plánování uchovávání. Funkční model OAIS je na následujícím obrázku:

Otevřený archivní informační systém (OAIS) FUNKČNÍ MODEL

6. Plánování uchovávání

P Ů V O D C E

Popisné informace

4. Správa dat

Popisné informace

SIP

2. Vstupní operace

dotazy výsledky dotazů

požadavky výstupní balíček

AIP

3.

Archivní úložiště

7.

Přístupové operace

AIP

DIP

K O N Z U M E N T

5. Administrace

ŘÍZENÍ ARCHIVU

SIP = Submission Information Package (vstupní balíček) AIP = Archival Information Package (archivní balíček)

DIP = Dissemination Information Package (výstupní balíček)

Obrázek: Funkční model OAIS

Můžeme shrnout, že OAIS zahrnuje šest vysokoúrovňových funkčních částí, které spojíme-li je dohromady, tvoří mechanismus pro dlouhodobé uchovávání informací, které též zpřístupňuje určené komunitě. Systém založený na modelu OAIS implementuje každou z těchto služeb, přičemž formu této implementace nepředepisuje.

Plnění legislativních požadavků

Systém ICZ DESA implementuje pracovní postupy, procesy a datové formáty ve shodě s platnou legislativou pro dlouhodobé a důvěryhodné ukládání dat.

• Zákon č. 499/2004 Sb., o archivnictví a spisové službě, v platném znění

• Vyhláška č. 259/2012 Sb., o podrobnostech výkonu spisové služby

• Vyhláška č. 194/2009 Sb., o stanovení podrobností užívání a provozování informačního systému datových schránek

• Zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů

• Nařízení vlády č. 495/2004 Sb., kterým se provádí zákon č. 227/2000 Sb., o elektronickém podpisu a o změně některých dalších zákonů, ve znění pozdějších předpisů

• Zákon č. 227/2000 Sb., o elektronickém podpisu a o změně některých dalších zákonů

Funkční vlastnosti

Příjem dat

Funkce API pro odesílání dat do DESA. Podrobně dokumentované Aplikační rozhraní nabízí funkce pro odesílání datových balíčků do procesu příjmu (proces příjmu je podrobně popsán v následující kapitole). Umožňuje tak okolním systémům, jako je například spisová služba nebo digitalizační systémy zasílat datové balíčky přímo do systému DESA bez nutnosti jejich dočasného ukládání na souborový systém.

Vstupní kontrola dat

Elektronické dokumenty jsou dále doplněny metadaty podporujícími procesy řízení, uchovávání a zpřístupňování (viz dále). Každému dokumentu je přidělena jednoznačná identifikace a vše je zabaleno do archivního informačního balíčku (všechna metadata a elektronické přílohy/soubory/dokumenty). Archivní balíček je poté uložen do archivního úložiště. ICZ DESA pak zajišťuje bezpečné uložení archivních balíčků. Na základě uchovávající strategie provádí činnosti pro udržení čitelnosti a životaschopnosti elektronických dokumentů.

Jak již bylo uvedeno, každý uložený dokument bude doplňován metadaty. Metadata obsahují vlastnosti

dokumentu, jeho strukturu a další informace, potřebné pro archivaci.

Popisná metadata (například název, popis, autor, původce, typ, kategorie a další) slouží převážně pro popis elektronických dokumentů a jsou využívána pro vyhledávání objektu a zjištění základních údajů o objektu. Popisná metadata vycházejí ze standardu Moreq2, který definuje doporučení při návrhu spisových služeb.

Uchovávající metadata slouží pro podporu uchovávání a pro archivační aktivity. Uchovávající metadata obsahují údaje o formátu, technické údaje o uložených digitálních objektech. Dále obsahují informace o činnostech či změnách provedených s elektronickým obsahem.

Strukturální metadata slouží pro sdružení všech částí informačního balíčku do jednoho logického celku.

Indexace

Během fáze příjmu dochází k ukládání metadat a obsahu dokumentu do databáze a to ve struktuře vhodné k rychlému vyhledávání v těchto datech, tzv. indexu. Vytváří se 2 druhy indexu:

Index metadat, který systém používá při vyhledávání datových balíčků na základě jednotlivých datových položek metadat nebo při vyhledávání datových balíčků fulltextovým vyhledáváním napříč všemi metadaty.

Index obsahu dokumentu, tzv. fulltext. Tento index systém používá při vyhledávání datových balíčků na základě klíčových slov a frází v obsahu dokumentu. Aby mohl vzniknout fulltextový index, musí být ve vstupním dokumentu přítomna textová informace. Dokument pocházející z digitalizace musí obsahovat OCR textovou vrstvu. Pokud není textová informace dostupná, fulltextový index není pro takový vstupní balíček vytvořen.

Vyhledávání

Systém poskytuje pokročilé funkce k vyhledávání datových balíčků na základě různých kritérií a umožňuje tak uživateli efektivně a rychle najít požadovaný obsah. Uživatel může vyhledávání provádět v tomto rozsahu:

Může definovat jakoukoli množinu a rozsah hodnot jednotlivých položek uložených metadat. Může definovat stav zpracování datového balíčku, který hledá.

Transakční a auditní záznamy, ukládané také jako datové balíčky, lze také zahrnout do množiny nalezených datových balíčků.

Lze definovat text, který bude vyhledáván napříč všemi uloženými metadaty k datovému balíčku. Tzv. fulltextové vyhledávání v metadatech.

Lze definovat text, který bude vyhledáván v obsahu dokumentu. Definovat lze jednotlivá klíčová slova, ale také celé fráze. Hledaná klíčová slova lze kombinovat logickými operátory „A“ a „Nebo“. Systém dokáže kromě hledání zadaných slov vyhledávat také různé tvary slov, jako jsou například varianty různých pádů podstatných jmen. Uživateli tak ulehčuje vyhledávání v případě, kdy nezná přesný tvar hledaného obsahu.

V případě, že dochází k vyhledávání datových balíčků na základě obsahu dokumentu, je výsledek hledání zobrazen jako seznam nalezených balíčků, kdy u každého z nich je zobrazena část textu před a za nalezeným výrazem pro snadnější orientaci uživatele. V případě, že datový balíček obsahuje více dokumentů, může uživatel zobrazit náhled všech těchto dokumentů.

Obrázek: ukázka vyhledávání

Položky vyhledávacího filtru

Jednotlivé položky vyhledávacího filtru se dělí na standardní položky metadat, které jsou součástí strukturálních a uchovávajících metadat a na položky podrobného vyhledávání, kam může správce systému zařadit libovolná popisná metadata, která jsou zařazena do předpisu pro metadata, dle požadavků na spravovanou agendu. Pro představu jsou níže uvedena kritéria, dle kterých je možno datové balíčky vyhledávat.

Zápůjčky a nahlížení

Systém DESA poskytuje několik nástrojů pro poskytování obsahu subjektům a osobám, které nemají do systému standardně přístup. V rámci těchto procedur je možné generovat zápůjční lístky, evidovat totožnost

osob, kterým byl obsah zapůjčen/zpřístupněn a je evidován seznam těchto datových balíčků a historie těchto činností s nimi, včetně detailní informace o datu a času, kdy k těmto událostem došlo.

Zápůjčky

V systému nemusí být uložen pouze elektronický dokument, ale může se jednat o evidenci analogového dokumentu uloženého ve spisovně/archivu. Analogové dokumenty jsou půjčovány ze spisovny/archivu oprávněným osobám. Pro tyto účely nabízí DESA modul pro evidenci zápůjček, který eviduje osoby, termíny zápůjček a lhůty pro navrácení zapůjčené písemnosti. Modul také umožňuje generovat tiskové sestavy s přehledy zápůjček.

Výdej datových balíčků

Podobně jako analogové dokumenty i elektronické dokumenty mohou být předmětem zájmu oprávněných osob. Nejedná se o zápůjčky v pravém slova smyslu, ale výdej kopie uloženého datového balíčku. I v tomto případě dochází k žádosti o výdej oprávněným uživatelem, kdy je třeba zadat identifikační údaje žádající osoby. Žádosti o výdej může schvalovat další oprávněný uživatel. Lze tak přidělit oprávnění k žádostem o výdej více uživatelům a dalšímu uživateli udělit oprávnění tyto žádosti schvalovat.

Systém nahlížení

Modul pro nahlížení do uložených datových balíčků slouží k samoobslužnému odbavení externích uživatelů, například občanů, kteří požadují nahlédnout do dokumentace, kterou mají právo si prohlédnout. V tomto modulu může oprávněný uživatel vybrat balíčky k nahlédnutí a vygenerovat pro ně jednorázový přístupový kód s omezenou platností. Externí uživatel se pak může do systému přihlásit (například z jiné pracovní stanice) a je mu dočasně zpřístupněn pouze vybraný obsah svázaný s tímto přístupovým kódem.

Transakční záznamy

Systém zaznamenává činnosti prováděné nad spravovanými datovými balíčky (příjem balíčku, odeslání balíčku apod.), nad systémem jako takovým (systémový log změny parametrů, změny v číselnících apod., chyby, výjimky) a nad činností samotných uživatelů (aplikační log přihlašování do systému apod.). Podle nastavení parametrů systému jsou v časových intervalech vytvářeny z transakčních záznamů nové datové balíčky (auditní logy) obsahující skupiny transakčních záznamů. Tyto balíčky se také ukládají do archivního úložiště jako ostatní obsah a podléhají tak stejný pravidlům a požadavkům na důvěryhodnost, dlouhodobost a shodu se standardy. Systém tím zvyšuje úroveň důvěryhodnosti a možnosti věrohodně prokázat informace o své činnosti a o operacích prováděných se spravovanými datovými balíčky. U každého uloženého záznamu je odlišeno, zda se jedná o záznam činnosti vykonané systémem nebo uživatelem. V případě činnosti systému je uvedeno jaká komponenta systému činnost vykonala. V případě činnosti vykonané uživatelem je zaznamenána identifikace uživatele. Každý záznam obsahuje:

Datum a čas vzniku Úroveň

Název komponenty Název uživatele Popis záznamu Popis události

Kód chyby pokud se jedná o chybu

Identifikátor a verzi relevantního datového balíčku

Systém umožňuje sběr záznamů na těchto úrovních:

Administrace

Fáze příjmu datového balíčku Kontrola digitálního archivu Kontrola kvality balíčku

Přístup k databázi

Skartace

Ukládací jednotky

Výdej/zápůjčka balíčků

Uživatelské rozhraní nabízí přehledný modul pro kontrolu transakčních záznamů a umožňuje jejich výpis filtrovat dle výše uvedených kritérií.

Neměnnost dat

Neměnnost dat zajišťuje systém ICZ DESA aplikováním technologie časových razítek ve spolupráci s akreditovanými důvěryhodnými certifikačními autoritami (TSA). Časové razítko je speciální typ elektronického podpisu, který je určen pro označení dokumentu v čase. Je založena na asymetrické kryptografii a principu veřejného klíče.

Časová razítka vydává certifikační autorita za poplatek. Úhrada vystavených razítek není součástí této nabídky a jejich objednávku je nutné řešit odděleně. Aplikaci časových razítek lze nastavit na globální úrovni, nebo pro každého původce/agendu zvlášť. Kombinací nastavení pravidel na globální úrovni i úrovni původců/agend lze nastavit požadovanou úroveň aplikace razítek pro různé původce i použití různých přístupových údajů k časové autoritě. Různé agendy tak mohou být součástí společných nebo samostatných fakturací od časové autority.

Aplikace a uložení časového razítka

Časové razítko se aplikuje na celý datový balíček a při jeho aplikaci dojde k vypočtení otisku datového souboru balíčku (tzv. HASH), který je pro každý balíček jedinečný a ten je pomocí API odeslán certifikační autoritě. Certifikační autorita přidá k tomuto otisku informaci o aktuálním čase a tento text zašifruje privátním klíčem certifikační autority. Výsledný řetězec/text je časové razítko a je zaslán zpět systému ICZ DESA, který jej uloží jako speciální typ datového balíčku s odkazem na razítkovaný datový balíček.

Ověření neměnnosti datového balíčku

Systém pak dle konfigurace v pravidelných intervalech kontroluje neměnnost datových balíčků a to tak, že pro každý z nich znovu spočítá otisk a pomocí veřejného klíče certifikační autority (dostupný ke stažení z certifikační autority přes její API) dešifruje uložené časové razítko. Pokud se shoduje aktuálně spočítaný otisk s původním otiskem v časovém razítku, je zaručeno, že obsah kontrolovaného datového balíčku nebyl pozměněn a je zřejmé v jakém čase k zašifrování došlo. Důvěra v tento výsledek je zaručena tím, že zašifrování původního

otisku mohla vytvořit pouze certifikační autorita svým privátním klíčem a dešifrování lze provést pouze veřejnou částí klíče.

Aplikace nových razítek na již orazítkované balíčky

Certifikát certifikační autority, jehož privátní klíč byl použit k vytvoření časového razítka a jehož veřejný klíč je používán k ověřování neměnnosti datový balíčků, má z bezpečnostních důvodů omezenou platnost a přesto, že jej lze nadále používat k ověřování neměnnosti, certifikační autorita jej po ukončení jeho platnosti (cca 3 – 5 let) označí za neplatný a tím pádem za nedůvěryhodný. Pokud má být důvěra v neměnnost datových balíčků zachována, musí dojít k vystavení nového časového razítka tzv. prolongaci. To systém ICZ DESA zajišťuje automatickým vystavením nového časového razítka v dostatečném předstihu v řádu měsíců před ukončením platnosti razítka předchozího. Původní časové razítko zůstává v systému uchováno a tak je možné pomocí ověření celého řetězce časových razítek prokázat neměnnost původního obsahu.

Aplikace razítka na skupinu datových balíčků

V rámci úspor lze konfiguračním parametrem definovat, že se bude jedno časové razítko aplikovat na skupinu více datových balíčků najednou. Neměnnost dat je tak zaručena pro celou tuto skupinu datových balíčků a při případné změně obsahu jednoho z nich je porušena důvěra v neměnnost napříč celou skupinou. Z pohledu důvěry v neměnnost obsahu tak celá skupina datových balíčků vystupuje jako jeden datový balíček. Aplikování časových razítek na skupinu datových balíčků probíhá v pravidelných časových intervalech, které je možné stanovit konfiguračně. Během aplikace razítka dojde ke kontrole počtu datových balíčků čekajících na orazítkování. Pokud je jejich počet menší, než maximální velikost skupiny balíčků definovaná v konfiguraci, vznikne jedno časové razítko na všechny datové balíčky čekající na orazítkování. Pokud je počet balíčků čekajících na orazítkování větší než maximální velikost skupiny balíčků definovaná v konfiguraci, dojde k aplikaci více razítek a čekající balíčky jsou rozděleny do více skupin dle maximální velikosti definované v konfiguraci.

Více certifikačních autorit

V rámci zvýšení spolehlivosti při aplikování časových razítek, je možné definovat napojení systému DESA na více důvěryhodných (akreditovaných) certifikačních autorit najednou. V případě nedostupnosti jedné z nich je pak použita druhá certifikační autorita. Současně lze pro tentýž obsah použít i více časových razítek různých autorit současně. Jeden datový balíček pak bude orazítkován dvěma časovými razítky.

Zabezpečení dat

Systém DESA umožňuje uchovávat data ve více nezávislých kopiích. Nezávislou kopií se myslí možnost připojit různá úložiště, která mohou být libovolného charakteru. Jedinou podmínkou je, aby připojené úložiště podporovalo komunikaci protokolem CIFS a proto je možno připojovat různá (heterogenní) úložiště, která mohou být umístěna v různých lokalitách (geograficky oddělena). Ukládání datového balíčku po příjmu na všechna specifikovaná úložiště provádí systém DESA na aplikační úrovni. Replikace kopií na úrovni samotných úložišť, ovladačů nebo operačních systémů není vhodná.

Konfigurace úložišť umožňuje kromě technických parametrů, jako je například velikost vyrovnávacích pamětí, nastavit také pravidla pro to, jaká úložiště budou použita pro datové balíčky jednotlivých původců/agend. Lze také určit prioritu úložišť pro čtení datového balíčku a tím zabezpečit že datové balíčky se budou primárně načítat s lokálních a rychlých úložišť, zatímco jejich kopie se budou ukládat na vzdálenější a pomalejší úložiště. Prioritami tak lze například odstupňovat úložiště dle výkonu v pořadí 1. Diskové pole připojené optikou 2. NAS připojené síťovou rychlostí 100Mbit/s 3. Pásková knihovna.

Systém DESA v pravidelných intervalech počítá a ověřuje kontrolní součty kopií v jednotlivých úložištích a porovnává je s kontrolními součty uloženými v databázi. Z této činnosti vznikají detailní transakční záznamy. V případě neshody v kontrolních součtech, která může znamenat narušení obsahu jedné z kopí, je tato událost zaznamenána. Administrátor systému má k dispozici kompletní informace o těchto kontrolách a může je filtrovat dle jejich výsledku, tedy i dle těch, které skočily nějakým druhem chyby.

V systému DESA nejsou uživatelům ani správcům dostupné na aplikační úrovni žádné funkce, které by umožňovali jakákoli data jakkoli pozměnit nebo mazat.

Správa verzí

Při jakékoli potřebě měnit obsah, jako například při konverzi dokumentů nebo při opravě metadat, dojde vždy k vytvoření nové verze datového balíčku. Ke vzniku nové verze datového balíčku dojde také v případě, kdy je přijímán datový balíček se shodnými metadaty (včetně identifikátoru), ale s pozměněným obsahem. V systému nemohou existovat dva datové balíčky s totožným obsahem. Totožným obsahem se myslí shodná metadata i obsah dokumentu. Takový balíček je ve fázi příjmu odmítnut jako duplicitní.

V uživatelském prostředí je možné v profilu každého datového balíčku jednoduše poznat, že datový balíček obsahuje více verzí a je také možné si zobrazit i kompletní historii verzí a stáhnout si a zobrazit datový balíček v podobě v jaké existoval v této verzi.

Nezávislé agendy

Systém DESA umožňuje spravovaný obsah rozdělit na samostatné logické celky, které se nazývají původci. Pod pojmem původce si lze představit samostatnou agendu, oddělení nebo odbor. V rámci tohoto původce lze samostatně bez návaznosti na ostatní původce evidovat následující parametry:

Seznam oprávněných uživatelů s přístupem k tomuto původci Skupiny uživatelů

Třídy dokumentů a oprávnění činností k nim

Definici pravidel pro ukládání kopií datových balíčků tohoto původce do jednotlivých připojených úložišť Spisové a skartační plány

Skartační návrhy

Podpora skartačního řízení

Zákon č. 499/2004 Sb., o archivnictví a spisové službě určuje pravidla provádění skartací organizacemi, které mají povinnost vykonávat spisovou službu.

Systém DESA podporuje v každé své edici lehce odlišný způsob vyřazování (skartace), který odpovídá účelu provozování dané edice systému. V následujícím textu bude popsána společná část pro obě edice. V dalších dvou kapitolách jsou pak popsány specifické funkcionality obou edic.

Společná funkcionalita edic DESA

Životnost dokumentů a spisů uložených v elektronickém archivu může být řízena legislativou a organizačními potřebami původce. Uložené dokumenty a složky zde čekají na skartační řízení. Po uplynutí skartační lhůty dojde ke skartaci (zničení) dokumentů. Je třeba počítat s tím, že některé dokumenty mohou v DESA zůstávat po

velmi dlouhou dobu, aniž by se skartovaly, jiné mají svou životnost v organizaci omezenu spisovým a skartačním plánem.

Po vypršení skartační lhůty může být balíček (dokument) ze systému vyřazen. Proces skartačního řízení je několikafázový proces, který zahrnuje výběr balíčků k vyřazení, sestavení skartačního návrhu, schválení skartačního návrhu a vlastní vyřazení.

Vyřazování v DESA edice DES

Vyřazování v DES začíná vytvořením skartačního návrhu. Tento návrh lze vytvořit pouze automaticky na základě spisového a skartačního plánu. Zařazování datových balíčků do skartačního návrhů lze omezit na vybrané organizační jednotky nebo vybrané spisovny.

Po sestavení skartačního návrhu je skartační návrh ve stavu, kdy je dostupný k úpravám. V tomto stavu lze do skartačního návrhu přidávat další datové balíčky nebo datové balíčky vyřazovat. Lze také jednotlivým balíčkům pozastavit skartaci a tím je dočasně ochránit před skartací. Skartační režim platí i nadále, ale dokumenty nemohou být vyřazeny do konce platnosti pozastavení. Balíčku lze také změnit skartační režim. Takto označený balíček tedy nebude v rámci aktuálního skartačního návrhu skartován/archivován. Do dalšího skartačního návrhu organizace bude automaticky zařazen, až poté co uplyne jeho nová skartační lhůta. Skartační lhůtu lze prodloužit, není ji však dovoleno zkracovat.

Dle Vyhlášky č. 259/2012 Sb. o podrobnostech spisové služby, § 20, odst. 5 má v rámci skartace organizace povinnost odeslat příslušnému archivu skartační návrh obsahující i objekty označené skartačním znakem „V“. Jejich zařazení mezi objekty se skartačním znakem „S“ či „A“ provede příslušný nadřízený archiv. Rozhodnutí skartačního znaku nezáleží pouze na správci spisovny, který skartační návrh vytváří a připravuje. Rozhodnutí by mělo proběhnout na základě posouzení např. nadřízeným archivem organizace, případně speciální komisí, která může být sestavena za tímto účelem.

DES Umožňuje provádět návrhy těchto změn v rámci skartačních návrhů. Tyto návrhy jsou posouzeny odpovědným pracovníkem nadřazeného archivu.

Takto vytvořený skartační návrh je možno schválit a přistoupit buď k tisku sestavy skartačního návrhu, který slouží pracovníkům nadřízeného archivu k jeho posouzení například v místě umístění spisovny s analogovými dokumenty, nebo k provedení elektronické skartace. Elektronická skartace probíhá v následujících krocích:

Předání skartačního návrhu k posouzení příslušnému nadřízenému archivu. V momentě předání k posouzení prochází skartační návrh kontrolou na přítomnost případných konfliktů (například zapůjčený obsah). Pokud se v tomto kroku nějaké konflikty zobrazí, musí uživatel v detailu návrhu vyhledat konflikty a odpovídajícím způsobem je odstranit.

Pokud nejsou přítomny žádné konflikty, aplikace vygeneruje SIP balíčky určené k odeslání do příslušného archivu dle standardu NSESSS3. Tyto SIP balíčky jsou generovány bez dokumentového obsahu (elektronických příloh). Balíčky se generují do předem nadefinovaného adresáře do formátu zip. Archivu jsou předány např. pomocí technického nosiče či jinou cestou – dle objemu předávaných dat. Příslušný archiv posoudí odeslané SIP balíčky. V případě nejasností může vyzvat původce k předložení vybraných objektů k archivní prohlídce. Archiv zašle soubor ve formátu XML, který obsahuje seznam objektů, ke kterým je nutné vygenerovat nový SIP balíček včetně dokumentového obsahu (elektronických příloh) a znovu předat příslušnému archivu. Soubor se seznamem objektů k prohlídce je uložen do libovolného adresáře a importován do DES. Při úspěšném importu se u jednotlivých položek skartačního návrhu automaticky změní skartační znak dle pokynů příslušného archivu či vyznačí informace o odložení skartace.

Po importu rozhodnutí příslušného archivu následuje schválení a export archivem vybraných archiválií k trvalému uložení. Na základě rozhodnutí archivu jsou balíčky označené skartačním znakem „A“ vygenerovány do předdefinovaného adresáře. SIP balíčky obsahují nejen metadata, ale i dokumentový obsah (elektronické přílohy). Z adresáře jsou opět nahrány na technický nosič a následně předány příslušnému archivu.

Po zpracování balíčků archivem je zpět odesláno potvrzení o přejímce archiválií ve formátu XML, které se opět importuje do aplikace. Tím je elektronická skartace dokončena.

Při vytváření skartačního návrhu lze určit, jestli se má mazat skartovaný obsah (skartační znaky „S“) a jestli se má smazat archivovaný obsah (skartační znaky „A“). Pokud jsou tyto volby zapnuté, zůstanou balíčky v příslušném stavu stále přítomné v systému včetně dokumentového obsahu (elektronických příloh) a je možné je později trvale vymazat v procesu interního vyřazování

Autentizace

Systém ICZ DESA je vybaven autentizačními mechanismy, které umožňují správu uživatelů lokálně bez napojení na externí autentizační systémy, ale umožňuje také napojení na adresářové služby Microsoft Active Directory. Uživatele lze organizovat do skupin a lze jim přidělovat role.

Autorizace

Uživatel je autorizován k činnostem v systému na základě individuálních nebo hromadných oprávnění, které jsou mu přidělována na základě členství ve skupinách a přidělováním rolí.

Skupiny

Skupina je jednotka, která má oprávnění na jednotlivé třídy dokumentů dle spisového plánu. Může obsahovat libovolný počet tříd dokumentů, přičemž každé třídě dokumentů lze přiřadit oprávnění, které vyjadřuje dostupnost těchto dokumentů uživatelům náležící k této skupině. Například lze definovat, že uživatelé skupiny

„Podatelna“ uvidí v rámci třídy „01.01 materiály pro jednání rady“ pouze metadata dokumentu a ne jeho obsah. Pokud je jedním z popisných atributů uživatele i lokalita, lze nastavit oprávnění i na základě této lokality a to sdružováním uživatelů do skupin dle těchto lokalit.

Role

Role je přednastavená množina oprávnění, která se váže k typickým rolím zaměstnanců v organizaci. V systému jsou přednastaveny tyto role:

Centrální administrátor - spravuje celý systém

Administrátor původce - spravuje pouze jednu agendu. V terminologii OAIS jednoho původce dokumentů. Administrátor původce - bez přístupu k obsahu

Administrátor původce - pouze správce uživatelů Centrální archivář

Archivář původce

Uživatel původce - může vyhledávat a zobrazovat obsah datových balíčků Uživatel původce poskytovatel – zpřístupňuje datové balíčky žadatelům

Uživatel v badatelně - veřejnost

Externí uživatel – veřejnost

Nefunkční vlastnosti

Kompatibilita s infrastrukturním prostředím

DESA je stavěna jako aplikace klient server, kdy klientskou část tvoří webová aplikace, která se uživateli zobrazuje ve webovém prohlížeči. Podporované prohlížeče jsou:

Internet Explorer 11 Firefox 53 a vyšší

Serverová aplikační část může být provozována na serverových operačních systémech Microsoft Windows Server 2012 nebo novějších nebo na operačních systémech Linux. Systém je otestován a provozován také na virtualizovaných výše uvedených operačních systémech. Pro svůj běh systém vyžaduje běhové prostředí Java 2 v1.8. Pro data ukládaná do databáze podporuje systém databázově servery Microsoft SQL Server 2012 nebo vyšší nebo databázový systém Oracle 11 nebo vyšší.

Komfort uživatelského prostředí

Přístup oprávněných osob k archivním dokumentům je možné v případě integrace se spisovou službou e-spis řídit přímo z elektronické spisové služby, čímž je zaručena návaznost na stávající metodiku archivace elektronických dokumentů, aniž by tím byla ovlivněna vlastní činnost pracovníků oddělení archivu. Tzn. schopnost systému automaticky na základě nastavených oprávnění obsloužit jednotlivé žadatele. V případech žádostí, které jsou nad, nebo mimo rámec oprávnění jednotlivých žadatelů, pak schopnost systému poskytnout informaci co je třeba učinit, nebo komu eskalovat svou žádost, aby daný dokument mohl být zpřístupněn.

Přístup k dokumentům z prostředí spisové služby nijak nezvyšuje nároky na znalost obsluhy, protože čerpá ze stávajících znalostí uživatelů spisové služby. Vedle toho aplikace disponuje vlastním aplikačním rozhraním, poskytujícím jednoduchý a přehledný přístup k dokumentům, dostatečně rychlé odezvy k vyhledání daného dokumentu, včetně zajištění přehledu o historii práce s dokumentem.

Uživatelské prostředí umožňuje uživateli měnit velikost jednotlivých částí plochy aplikace a také dynamicky zobrazovat nebo skrývat oblast pro vyhledávání a filtraci objektů jako jsou například datové balíčky, zápůjčky, migrace, transakční protokoly, skartační návrhy a podobně. Uživatel tak má možnost využívat maximální plochu svého monitoru k zobrazení a práci se samotným obsahem.

Komfort administrátorského prostředí

Aplikace ICZ DESA je na základě integrace s elektronickou spisovou službou či Active Directory schopna automaticky reagovat na personální a organizační změny organizační struktury zadavatele. Tzn. schopnost integrace systému na Active Directory provozovaného Zadavatelem.

Aplikace ICZ DESA je schopna automaticky generovat notifikace změn v systému směrem k administrátorovi systému. Schopnost systému operativně promítat legislativní změny do produkčního prostředí systému a v rámci poskytované provozní podpory zajistit soulad požadovaných funkcionalit s požadavky zadávací dokumentace a platnou legislativou. Provozní podpora není součástí této nabídky.

Administrátor má dále k dispozici přehledné graficky znázorněné informace o vnitřním stavu aplikace, běhového HW a stavu připojených datových úložišť.

Dostupnost

Systém DESA podporuje běh aplikace v prostředí, kde jsou jednotlivé instance operačních systémů sdruženy do tzv. clusteru a to prostředky těchto operačních systémů, ale tato konfigurace není pro provozování systému DESA požadována.

Dodávaná dokumentace

Jako součást dodávky je v rámci projektu nasazení systému DESA dodávána dokumentace v požadovaném rozsahu, konkrétně ve složení těchto dokumentů:

Před implementační fáze

Implementační analýza projektu

Implementační fáze

Zápisy z koordinačních schůzek

Technická dokumentace

Realizační návrh popisující rozsah a postup implementace. Tento dokument obsahuje schémata dodávaného řešení.

Dokumentace aplikačního rozhraní dodávaného systému.

Dokumentace testů

Dokumentace testů obsahuje údaje, které dokládají jaký systém, v jakém rozsahu a jakými postupy byl otestován.

Provozní dokumentace

Uživatelská příručka popisující uživatelské rozhraní systému a jeho ovládání, funkce dostupné uživatelům a jejich používání a standardní pracovní postupy.

Administrátorská příručka popisující správu a administraci systému.

Předávací protokoly

Předávací protokoly vznikají postupně při předání každé samostatně funkční komponenty (například jedné instance DESA) zvlášť. Každá komponenta je předávána spolu s instalačním protokolem popisujícím, prostředí, konfigurační položky a výsledek instalace.

Celé řešení je akceptováno podpisem akceptačního protokolu, který detailně popisuje skutečně dodaný rozsah řešení a jeho stav v době akceptace.

Správa jednotlivých agend

Systém DESA umožňuje dlouhodobě spravovat požadované agendy/původce dat. V rámci implementační analýzy bude stanoveno, které z vyjmenovaných agend budou uloženy v DESA edice DES. V analýze bude zároveň stanoveno, zda lze některé z agend provozovat v rámci jedné instance DESA nebo je třeba provozovat agendu/původce jako samostatnou instanci. Pro každou z implementovaných instancí DESA bude vytvořen předpis datové struktury dle standardu NSESSS3 (DES) a to tak, aby tento předpis umožňoval, aby metadata vytvořená dle tohoto předpisu obsahovala popisné údaje požadované pro jednotlivé agendy/původce dat.

1. Detailní popis API rozhraní SYSTÉMU

Čl. 16. 2.1 Autorizace uživatele

Požadavky NS API vyžadují uvádět autorizaci uživatele, pod nímž je příslušná akce prováděna.

ESSL kontroluje práva autorizovaného uživatele k objektu, který je upravován a na akci, kterou požadavkem

provádí.

Typy autorizace

Podporované typy autorizace uživatelů:

Typ	Hodnota	Popis
Standardní	login	login jméno uživatele ESSL e-spis
	kodFM	kód funkčního místa v ESSL e-spis
	osc	osobní číslo uživatele (RŽP)
Volitelné	login|kodFM	login jméno rozšířené volitelně o kód funkčního místa uživatele v ESSL e- spis
	kodFM|osc	osobní číslo uživatelevolitelně rozšířené o kód funkčního místa (výhradně IS RŽP)

Hodnota - konkretizovaná podle příslušného uživatele/FM - se použije v elementech provedlKdo a vlastniKdo

Multicompany

Uživatel se v multicompany autentizuje rovněž pouze konkrétním údajem, neuvádí se kód organizace. Pro multicompany platí:

▪ každá organizace v multicompany má svůj vlastní endpoint (např. URL 4. řádu, kde je uveden kód organizace)

▪ systém při zpracování požadavku API rozhraní kontroluje kód organizace v doméně, pokud není nalezen zde, hledá se aplikace podle hodnoty atributu "cil" v hlavičce requestu; pokud nebude uveden kód organizace ani zde, končí požadavek chybou

Čl. 17. 2.2 Bezpečnost

Bezpečnost

Míra zabezpečení komunikace mezi ESSL e-spis a integrujícím se ISSD je závislá na celkové infrastruktuře řešení, resp. vzájemná komunikace je vždy výsledkem dohody mezi dodavatelem ESSL e-spis a dodavatelem daného ISSD.

Tam, kde je integrace realizována prostřednictvím veřejné sítě Internet, je vhodné pro komunikaci zajistit důvěrnost a autentičnost předávaných dat. Důvěrnost dat lze zabezpečit protokolem HTTPS s autentizací serveru certifikátem. Autentičnost dat lze zabezpečit elektronickými podpisy obsahu předávaných zpráv.

Pro autentizaci HTTPS serveru a podepisování dávek (bude-li stranami dohodnuto) se budou používat certifikáty akreditovaných CA. Pro autentizaci serveru lze použít komerční systémové certifikáty, pro podepisování dat je doporučeno použít kvalifikované certifikáty (není to ale podmínkou).

Pro integraci mezi ESSL a ISSD v rámci interní sítě organizace není nutné používat HTTPS protokol a ani podepisovat obsah zpráv.

Struktura elektronického podpisu

Elektronické podpisy používané v tomto rozhraní jsou založeny na standardu „Web Services Security v1.1“ –

xxxx://xxx.xxxxx-xxxx.xxx. s následujícími podmínkami :

• podpisy jsou založeny na X.509 certifikáech vydávaných akreditovanými CA, tzn. že podepisovací klíče mohou být pouze RSA délky 1024 nebo 2048 bitů

• použití hash funkce SHA-2,

• podepisuje se kompletní obsah SOAP zprávy, tzn. element Body

Příklad podepsané SOAP obálky

<?xml version="1.0" encoding="utf-8"?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="xxxx://xxxxxxx.xxxxxxx.xxx/xxxx/xxxxxxxx/" xmlns:ds="xxxx://xxx.x0.xxx/0000/00/xxxxxxx#">

<SOAP-ENV:Header>

<wsse:Security xmlns:wsse="xxxx://xxxx.xxxxx-xxxx.xxx/xxx/0000/00/xxxxx-000000-xxxxxxxxxxxxx-xxxxxx- 1.0.xsd">

<ds:Signature xmlns:ds="xxxx://xxx.x0.xxx/0000/00/xxxxxxx#">

...

<ds:Reference URI="#MsgBody">

<ds:DigestMethod Algorithm=xxxx://xxx.x0.xxx/0000/00/xxxxxxx#xxx0>

</ds:DigestMethod>

<ds:DigestValue>...</ds:DigestValue>

</ds:Reference>

...

<ds:KeyInfo>

<ds:X509Data>

<ds:X509Certificate>...</ds:X509Certificate>

</ds:X509Data>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>...</ds:Modulus>

<ds:Exponent>...</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

</ds:KeyInfo>

</ds:Signature>

</wsse:Security>

</SOAP-ENV:Header>

<SOAP-ENV:Body ds:Id="MsgBody">

<ermsAsyn xmlns="xxxx://xxxxx.xxxxxx.xx/xxxx/x_00_00">

...

</ermsAsyn>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Čl. 18. 2.3.1 Způsob komunikace mezi ESSL a ISSD

Integrovaný ISSD bude ESSL e-spis předávat požadavky a události týkající se evidence dokumentů sekvenčně a ESSL e-spis bude tyto události sekvenčně zaznamenávat, resp. zpracovávat do evidence dokumentů. ESSL bude podle potřeby předávat ISSD informace o událostech, které se týkají objektů z evidence dokumentů zpracovávaných právě danou agendou.

Při předávání události, tzn. volání funkcí, může být použit protokol HTTP i HTTPS a technologie webových služeb.

Rozhraní umožní dva způsoby předávání událostí:

• synchronní on-line

• asynchronní dávkové

Synchronní komunikace

U synchronního volání funkcí pomocí protokolu HTTP/HTTPS je podmínkou, aby odpověď byla vrácena volajícímu ISSD v jednom http requestu – tzn. aby odpověď byla on line. Zpracování synchronních volání funkcí ESSL tedy probíhá v rámci jednoho http request-response a ESSL zpracovává požadavky podle toho, jak přicházejí.

Každé volání je jednoznačně identifikováno tak, aby bylo možno jej opakovat se stejným výsledkem. Volající ISSD je zodpovědný za dokončení požadavku při chybě.

Příklad synchronní komunikace - založení dokumentu, žádost o ČJ:

• dokument v poždavku na přdělení ČJ musí být trvale a jednoznačně identifikován (složený element Identifikátor - HodnotaID a ZdrojID),

• ISSD může opakovaně žádat o přidělení ČJ pro jeden dokument, ESSL pak vrací dokumentu vžy stejné ČJ (ESSL vyhledá dokument na záladě Identifikátoru),

• pokud dojde při žádosti o založení dokumentu / přidělení ČJ k chybě, musí ISSD poždavek opakovat.

V rámci synchronních funkci mohou být předávány i asynchronní funkce/události. Události jsou předávány v XML elementu „UdalostiPredchazejici“. Tyto události se zpracovávají před zpracováním synchronní funkce a zpracování všech událostí předaných synchronně musí proběhnout v jedné transakci. Tzn. že jsou zpracovány všechny události a synchronní funkce a nebo žádná událost.

Synchronní předávání událostí se tedy typicky využije v situacích vyžadujících okamžitou interakci mezi ESSL e-

spis a ISSD, typicky při přidělování ČJ a spisových značek z jednotné číselné řady původce.

Asynchronní komunikace

U asynchronního předávání událostí spojení zahajuje ten systém, který předává informace k události, tzn. buď ISSD nebo ESSL. Příjemce události pouze potvrdí syntaktickou správnost požadavku a zpracování událostí může provést později, v odloženém zpracování.

Asynchronní předávání bude využívat komunikaci prostřednictvím dávek, kde jedna dávka může obsahovat 0 až N událostí a 0 až N zpráv. Velikost dávky určuje jejich odesílatel

Každá dávka musí být jednoznačně identifikována souvisle číslovaným pořadím, každá událost v dávce pak jedinečným pořadím (Id) v rámci této dávky.

Při příjmu dávky je v ESSL e-spis:

• ověřena struktura dávky,

• ověřen elekornický podpis (pokud je použito),

• potvrzeno přijetí nebo odmítnutí dávky.

Zprávy slouží pro informování „protistrany“ :

• že při zpracování události došlo k chybě

• o potvrzení zpracování dávky – zprávou s kódem „000“ se potvrdí zpracování poslední události v příslušné dávce

Každá zpráva obsahuje jednoznačnou identifikaci události a kód a popis chyby.

Chybou se zde nerozumí technická chyba na straně příjemce, ale pouze situace, kdy byla předána chybná událost, tzn. že nebyly splněny podmínky, nebo událost obsahuje chybná data.

Při zpracování asynchronních událostí je potřeba dodržet následující zásady:

• dávky se zpracovávají sekvenčně

• události v dávce se zpracovávají sekvenčně (události jsou jednoznačně identifikovány v rámci příslušné dávky),

• v případě chybné události (jsou chybné vstupní parametry nebo nejsou splněny předpoklady provedení) se zpracování zastaví a chyba se oznámí odesílateli dávky formou zprávy v dávce,

• oznámení chyby obsahuje identifikaci dávky, identifikaci události v dávce a odůvodnění (výčet nesplněných předpokladů nebo chybných vstupních parametrů),

• v případě oprávněné „reklamace“ je odesílající systém povinen dávku (a všechny následující po chybné) odeslat znova opravenou,

• při zpracování opravené dávky se pokračje od události, která byla chybná – transakce jsou na

úrovni událostí, ne na úrovni dávky.

Asynchronní předávání bude tedy typicky využito v ostatních případech, kdy není bezpodmínečně nutná okamžitá interakce mezi ESSL a ISSD. Důvodem pro asynchronní výměnu dat je požadavek, aby nedostupnost jednoho z komunikujících systémů (ESSL, ISSD) neovlivnila činnost protistrany.

Čl. 19. 2.3.2 Vlastnictví objektů

Daný ISSD pracuje s objektem (dokumentem, nebo spisem), evidovaným v ESSL, ve výhradním režimu. Tzn. že ESSL ani jiný ISSD nemůže modifikovat atributy objektu. Zamčený objekt i nadále zůstává dostupný „pro prohlížení“ jak v ESSL, tak i pro ostatní ISSD.

Čl. 20. 2.3.3 Identifikátory objektů

Jednou z klíčových událostí při komunikaci mezi ESSL a ISSD je způsob identifikace objektů. Pro potřebu výměny

dat mezi systémy jsou jednoznačně identifikovány tyto entity:

• spis,

• dokument,

• zásilka (vypravení)

• soubor (el. příloha, komponenta dokumentu),

• obálka,

• uživatel (viz kapitola Autorizace uživatele).

Identifikátor spisů, dokumentů, zásilek, souborů a obálek bude přidělovat vždy ten systém, který objekt zaeviduje jako první. Ostatní systémy (ESSL nebo ISSD) musí identifikátor převzít.

Všechny identifikátory jsou jednoznačné pouze v rámci jednoho původce (organizace).

Identifikátor dokumentů může být úřadem prohlášen za jednoznačný identifikátor dokumentu podle zákona č. 499/2004 Sb. a může být tisknut na dokumenty ve formě čárového kódu. Na straně ESSL e-spis má jednoznačný

identifikátor celkovou délku maximálně 14 znaků (je doporučeno nepřekračovat ani ze strany ISSD). Struktura

tvorby jednoznačného identifikátoru vychází z následujících pravidel:

Výsledný tvar identifikátoru: xxxxyyZZZZZZZZ

Element	Část	Popis
ZdrojID	xxxx	zkratka původce (organizace) uvedena malými písmeny
	yy	zkratka označení agendy, ISSD, jednoznačně v rámci organizace, pro ESSL e- spis využívána standardně zkratka "es"
HodnotaID	ZZZZZZZZ	variabilní hodnota; v ESSL použit princip spojení dvouciferného čísla roku (YY) a pořadového čísla ze sekvence (VVVVVVVV), výsledné decimální číslo ve tvaru YYVVVVVVVV je převedeno do hexadecimálního tvaru ZZZZZZZZ

Z pohledu jednotlivých ESSL a ISSD to bude znamenat, že integrující se ISSD dostane přidělen původcem (organizací) 6ti znakový prefix (ZdrojID, resp. zdroj) pro generování identifikátorů.

Identifikátor může obsahovat číslice a písmena malé anglické abecedy. Dalším požadavkem je, že identifikátory jsou jednoznačné i mezi objekty. Tedy nemůže např. existovat spis a dokument se stejným identifikátorem.

Pro předávání identifikátorů bude použit datový typ „tIdentifikator“ z defince NS API, 6ti znakový prefix bude uváděn v elementu „ZdrojID“ a zbylé znaky (dle doporučení max. 8 znaků) bude uváděno v elementu

„HodnotaID“.

U objektů zásilek a obálek (vypravení) je element „IdZasilky“ použit pro předávání čárového kódu, který bude vytištěn na obálce. Obsah tohoto elementu může obsahovat jednoznačný identifikátor zásilky nebo obálky, ale není to podmínkou.

Čl. 21. 2.3.4 Typ dokumentu, věcná skupina a skartační režim

Jedná se o hodnoty klasifikace dokumentů a spisů, jejich označení číselníkovou hodnotou typu dokumentu/spisu a věcnou skupinou (spisovým znakem) ze spisového plánu.

V e-spis platí:

• dokument (vlastní, doručený)

o může být založen bez označení hodnotou typu nebo spisového znaku

o podle nastavení e-spis (globální parametr systému) může být typ dokumentu požadován jako povinná položka při vyřizování dokumentu

o při vyřízení samostatného dokumentu, nezařazeného ve spisu, musí být vždy označen spisovým znakem

• spis

o musí být založen vždy s označením typu a spisového znaku

o všechny dokumenty ve spisu přebírají jeho spisový znak (jsou zařazeny do téže věcné

skupiny, jako jejich spis)

Pro konfiguraci integrace ISSD je rozhodující, zda externí systém bude rozlišovat různé typy dokumentů/spisů a různé spisové znaky, např. v případě vedení různých typů spisových dokumentací. V takovém případě přiřazení typu dokumentu/spisu a spisového znaku řídí ISSD, hodnoty elementů plní v požadavcích na založení nebo úpravu dokumentu/spisu.

Pro ISSD, které s hodnotami typu a spisového znaku neumějí pracovat, je možné v nastavení integračního můstku definovat tzv. výchozí (defaultní) hodnoty. Výchozí hodnoty jsou definovány zvlášť pro doručený dokument, vlastní dokument a spis, ale jedná se vždy o jednu konstantu. V takovém případě pak budou všechny dokumenty a spisy zakládané tímto ISSD označeny vždy stejnými hodnotami typu a věcné skupiny, podle nastavení výchozích hodnot v konfiguraci integračního můstku.

Pravidla nastavení typu a VS

Def. typ / VS nastaven	ISSD typ / VS posílá	Založení DD/VD	Založení spisu
NE	NE	Proběhne Založí se bez hodnot typu / VS	Neproběhne Spis bez typu / VS nelze v e-spis založit
	ANO	Proběhne Založí se s hodnotami z ISSD	Proběhne Založí se s hodnotami z ISSD
ANO	NE	Proběhne Založí se s defaultními hodnotami z konfigurace	Proběhne Založí se s defaultními hodnotami z konfigurace
	ANO	Proběhne Založí se s hodnotami z ISSD	Proběhne Založí se s hodnotami z ISSD

21.1. Hodnoty typu dokumentu a věcné skupiny

21.1.1. Element TypDokumentu

V hodnotě elementu se uvádí kód záznamu v číselníku ESSL e-spis.

Hodnoty může ISSD získat dotazem CiselnikZadostRequest, kód = TypDokumentu

21.1.2. Fragment VecnaSkupina

Fragment dovoluje určit hodnotu odkazem na Identifikátor číselníkové položky ESSL e-spis nebo uvedením

hodnot SpisovyPlan a SpisovyZnak.

a) Určení hodnoty věcné skupiny Identifikátorem

Ve fragmentu VecnaSkupina ISSD naplní složený typ Identifikátor hodnotou ZdrojId a HodnotaId vybraného spisového znaku z číselníku e-spis.

Hodnoty Identifikátorů spisových znaků získá ISSD např. dotazem CiselniZadostRequest, kód = SpisovyZnak

b) Určení hodnoty věcné skupiny kódem spisového znaku

Ve fragmentu VecnaSkupina ISSD naplní hodnotu SpisovyZnak kódem číselníkové položky věcné skupiny spisového plánu. Hodnota SpisovyPlan je nepovinná, pokud není uvedena, vybírá se věcná skupina z aktuálně platného spisového plánu organizace. Poznámka: element SpisovyPlan je nutné v XML uvést i bez hodnoty.

21.1.3. Fragment SkartacniRezim

Skartační režim je v ESSL typicky svázán s věcnou skupinou spisového plánu. Jedná se o systémovou vazbu, proto v požadavcích na založení dokumentu či spisu ISSD hodnoty nemusí uvádět.

21.1.4. Příklad užití

Příklad nastavení hodnot TypDokumentu a VecnaSkupina při zakládání dokumentu základním postupem, a to nastavením hodnoty kódu číselníkové položky ESSL e-spis. Fragment SkartacniRezim se při založení neuvede.

Request - např. DokumentZalozeniRequest

<v:TypDokumentu>ROZ</v:TypDokumentu>

<v:VecnaSkupina>

<v:SpisovyPlan></v:SpisovyPlan>

<v:SpisovyZnak>53.1</v:SpisovyZnak>

</v:VecnaSkupina>

Význam: Výše uvedeným postupem ISSD zakládá dokument typu "ROZ" (rozhodnutí) a přiřazuje dokumentu věcnou skupinu s kódem spisového znaku "53.1". Předpokladem kladného výsledku, založení dokumentu je existence obou hodnot v příslušných číselnících ESSL e-spis. Response ESSL, potvrzení založení dokumentu, je pak rozšířeno o automaticky doplněné hodnoty fragmentu SkartacniRezim.

Response - např. DokumentZalozeniResponse

<v:TypDokumentu>ROZ</v:TypDokumentu>

<v:VecnaSkupina>

<v:SpisovyPlan>SP_2018</v:SpisovyPlan>

<v:SpisovyZnak>53.1</v:SpisovyZnak>

</v:VecnaSkupina>

<v:SkartacniRezim>

<v:SkartacniZnak>A</v:SkartacniZnak>

<v:SkartacniLhuta>10</v:SkartacniLhuta>

<v:SpousteciUdalost>VyrizeniUzavreni</v:SpousteciUdalost>

</v:SkartacniRezim>

Význam: Z odpovědi ESSL lze vyčíst, že založenému dokumentu byl nastaven typ dokumentu "ROZ", dokument byl zařazen do věcné skupiny "53.1" ze spisového plánu s kódem "SP_2018" a této věcné skupině je ve spisové plánu přiřazen skartační režim A/10 se spouštěcí událostí (okamžikem počátečního data pro stanovení výpočtu úložné doby dokumentu ve spisovně) k datu vyřízení dokumentu nebo uzavření spisu.

21.2. Spisový plán ve struktuře dle přílohy č. 5 NSERMS

Integrovaný ISSD může získat informace o spisovém plánu (spisových plánech) prostřednictvím volání metody CiselniZadostRequest, hodnota Kod = "SpisovyPlan". Uvede-li zároveň v údajích filtru metody kód konkrétního spisového plánu, pak response metody obsahuje v doplňujících datetech XML strukturu spisového plánu dle přílohy č. 5. NSERMS.

21.2.1. Příklad užití

1) ISSD odešle požadavek CiselnikZadostRequest, kde uvede hodnotu atributu Kod (kód požadovaného číselníku) "SpisovyPlan"

2) Odpověď CiselnikZadostResponse obsahuje seznam spisových plánů ESSL, jednotlivé položky charakterizované kódem a textovým popisem, např. Kod=SP_2012, Text=Spisový plán organizace rok 2012

3) ISSD požaduje obsah spisového plánu s kódem SP_2012 ve formátu XML dle přílohy č. 5 NSERMS:

Request

CiselnikZadostRequest - filtr spisový plán SP_2012

<soapenv:Envelope xmlns:soapenv="xxxx://xxxxxxx.xxxxxxx.xxx/xxxx/xxxxxxxx/" xmlns:v="xxxx://xxxxx.xxxxxx.xx/xxxx/x_00_00" xmlns:icz="xxxx://xxxxx.x.xx/xxxx/x_00_00">

<soapenv:Header/>

<soapenv:Body>

<v:CiselnikZadostRequest Zdroj="SOAPB2" Cil="OrVESS">

<v:Kod>SpisovyPlan</v:Kod>

<v:Autorizace>

<v:provedlKdo>spsadmin</v:provedlKdo>

<v:provedlKdy>2018-05-16T12:03:04</v:provedlKdy>

</v:Autorizace>

<v:DoplnujiciData>

<icz:espisCiselnikExtensions>

<icz:Kod>SP_2012</icz:Kod>

</icz:espisCiselnikExtensions>

</v:DoplnujiciData>

</v:CiselnikZadostRequest>

</soapenv:Body>

</soapenv:Envelope>

Response

CiselnikZadostResponse - data pro spisový plán SP_2012

<SOAP-ENV:Envelope xmlns:SOAP-ENV="xxxx://xxxxxxx.xxxxxxx.xxx/xxxx/xxxxxxxx/">

<SOAP-ENV:Header/>

<SOAP-ENV:Body>

<CiselnikZadostResponse xmlns="xxxx://xxxxx.xxxxxx.xx/xxxx/x_00_00" xmlns:soap="xxxx://xxxxxxx.xxxxxxx.xxx/xxxx/xxxxxxxx/">

<Kod>SpisovyPlan</Kod>

<Polozky>

<Polozka>

<Kod>SP_2012</Kod>

<Text>Spisový plán organizace</Text>

<DoplnujiciData>

<!-- SPISOVY_PLAN_ZACATEK -->

<SpisovyPlan ID="SP_SP_2012" xmlns="xxxx://xxx.xxxx.xx/xxxxxx/x0">

<Identifikator zdroj="OrVESS">4211283</Identifikator>

<Nazev>Spisový plán organizace</Nazev>

<Komentar/>

<Manipulace>

<DatumOtevreni>2000-01-01</DatumOtevreni>

<DatumUzavreni>2015-03-30</DatumUzavreni>

</Manipulace>

<Vydavatel>

<Subjekt>

<IdentifikatorOrganizace zdroj="OrVESS">ORA_VYV</IdentifikatorOrganizace>

<NazevOrganizace>VYV ORA</NazevOrganizace>

<SidloOrganizace>Xxxxxxxx 0, 000 00, Xxxxx 0</SidloOrganizace>

<ElektronickyKontakt>xxxxx.xxxxx@x.xx</ElektronickyKontakt>

</Subjekt>

</Vydavatel>

<PlanVecnaSkupina ID="VS_49">

<EvidencniUdaje>

<Identifikace>

<Identifikator zdroj="OrVESS">4211285</Identifikator>

</Identifikace>

<Popis>

<Nazev>Podání Czech POINT</Nazev>

<Komentar/>

</Popis>

<Pristupnost>

<BezpecnostniKategorie>

<Identifikator zdroj="OrVESS"/>

<Nazev/>

<BezpecnostniStupen/>

</BezpecnostniKategorie>

</Pristupnost>

<JineUdaje>

<ICZ>

<PovolenyObsah/>

<Ident_delka>3</Ident_delka>

<Ident_start_hodnota>1</Ident_start_hodnota>

<Ident_automat>N</Ident_automat>

<Ident_increment>1</Ident_increment>

<Ident_oddelovac/>

<Ident_prefix/>

<Ident_sufix/>

</ICZ>

</JineUdaje>

<Puvod>

<DatumVytvoreni>2000-01-01</DatumVytvoreni>

</Puvod>

<Trideni>

<JednoduchySpisovyZnak>49</JednoduchySpisovyZnak>

<PlneUrcenySpisovyZnak>49</PlneUrcenySpisovyZnak>

</Trideni>

<Vyrazovani>

<SkartacniRezim>

<Identifikator zdroj="OrVESS">S15</Identifikator>

<Nazev>Dokumenty určené ke skartaci</Nazev>

<Komentar/>

<Oduvodneni>Instrukce MVČR ze dne 25. 5. 1992 čj. VSC/1-

793/92</Oduvodneni>

<SkartacniZnak>S</SkartacniZnak>

<SkartacniLhuta>15</SkartacniLhuta>

<SpousteciUdalost>VyrizeniUzavreni</SpousteciUdalost>

</SkartacniRezim>

</Vyrazovani>

<Manipulace>

<DatumOtevreni>2000-01-01</DatumOtevreni>

<DatumUzavreni>2015-12-31</DatumUzavreni>

</Manipulace>

</EvidencniUdaje>

</PlanVecnaSkupina>

</SpisovyPlan>

<!-- SPISOVY_PLAN_KONEC-->

<icz:espisCiselnikExtensions xmlns:icz="xxxx://xxxxx.x.xx/xxxx/x_00_00">

<icz:PlatnostDo>2015-03-30T23:59:59</icz:PlatnostDo>

</icz:espisCiselnikExtensions>

</DoplnujiciData>

</Polozka>

</Xxxxxxx>

<nsess:OperaceStatus xmlns:nsess="xxxx://xxxxx.xxxxxx.xx/xxxx/x_00_00">

<nsess:Kod>0000</nsess:Kod>

<nsess:Popis>OK</nsess:Popis>

</nsess:OperaceStatus>

</CiselnikZadostResponse>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

V XML souboru spisového plánu jsou použity atributy ID a Identifikátory v následující struktuře

	Atribut "ID"		"Identifikator" entity
	je tvořen	použití v NS API	je tvořen	použití v NS API
SpisovyPlan	prefixem "SP_" a hodnoto u kódu záznamu spisovéh o plánu v číselníku ESSL e- spis	Hodnota bez prefixu "SP_" odpovídá hodnotě elementu Kod pro položku číselníku SpisovyPlan z response CiselnikZadostRespon se. Kód spisového plánu se využívá při nastavování věcné skupiny dokumentu/spisu kombinací hodnot SpisovyZnak+SpisovyP lan	atribut "zdroj" = zdroj_id záznamu v číselníku (db) ESSL e-spis hodnota Identifikat or = hodnota_i d záznamu v číselníku (db) ESSL e-spis	N/A

PlanVecnaSkupi na	prefixem "VS_" a hodnoto u plně určenéh o spisovéh o znaku	N/A	atribut "zdroj" = zdroj_id záznamu v číselníku (db) ESSL e-spis hodnota Identifikat or = hodnota_i d záznamu v číselníku (db) ESSL e-spis	Využívá se při nastavování věcné skupiny dokumentu/spisu: ▪ "zdroj" → VecnaSkupina/Identifikator/Z drojID ▪ hodnota → VecnaSkupina/Identifikator/H odnotaID
SkartacniRezim	N/A (atribut není použit)	N/A	atribut "zdroj" = zdroj_id záznamu v číselníku (db) ESSL e-spis hodnota Identifikat or = kód položky v číselníku ESSL e-spis	Využívá se při nastavování skartačního režimu dokumentu/spisu: "zdroj" → SkartacniRezim/Identifikator/ZdrojID hodnota → SkartacniRezim/Identifikator/Hodnota ID Pozn.: Nastavení skartačního režimu se nyní v implementaci e-spis ignoruje, dokumentu/spisu je nastaven SR přiřazený spisovému znaku (věcné skupině)

Čl. 22. 2.4 Číselníky ESSL e-spis Čl. 23. Žádost o obsah číselníku

Nová metoda pro načtení obsahu číselníku dohodnutého kódu – CiselnikZadostRequest

Příklad volání - request:

CiselnikZadostRequest

<soapenv:Envelope xmlns:soapenv="xxxx://xxxxxxx.xxxxxxx.xxx/xxxx/xxxxxxxx/" xmlns:v="xxxx://xxxxx.xxxxxx.xx/xxxx/x_00_00">

<soapenv:Header/>

<soapenv:Body>

<v:CiselnikZadostRequest Zdroj="SOAPB2" Cil="OrVESS">

<v:Kod>DopisOnLineTyp</v:Kod>

<v:Autorizace>

<v:provedlKdo>spsadmin</v:provedlKdo>

<v:provedlKdy>2018-05-16T12:03:04</v:provedlKdy>

</v:Autorizace>

<v:DoplnujiciData>

<icz:espisCiselnikExtensions>

<!--viz dokumentace Doplnujici data - Vstup filtr-->

<icz:Strankovani>

<icz:odZaznamu>1</icz:odZaznamu>

<icz:pocetZaznamu>10</icz:pocetZaznamu>

</icz:Strankovani>

</icz:espisCiselnikExtensions>

</v:DoplnujiciData>

</v:CiselnikZadostRequest>

</soapenv:Body>

</soapenv:Envelope>

Příklad odpovědi - response:

CiselnikZadostResponse

<soap:Envelope xmlns:xalan="xxxx://xxx.xxxxxx.xxx/xxxx" xmlns:xsi="xxxx://xxx.x0.xxx/0000/XXXXxxxxx-xxxxxxxx" xmlns:icz="xxxx://xxxxx.x.xx/xxxx/x_00_00" xmlns:soap="xxxx://xxxxxxx.xxxxxxx.xxx/xxxx/xxxxxxxx/" xmlns:exprit="xxxx://x.xx/xxxxxx/xxx.xxx">

<soap:Body>

<CiselnikZadostResponse xmlns="xxxx://xxxxx.xxxxxx.xx/xxxx/x_00_00" xmlns:nsess="xxxx://xxxxx.xxxxxx.xx/xxxx/x_00_00" xmlns:isds="xxxx://xxxx.xxxxxxxxxx.xx/x00" xmlns:icz="xxxx://xxxxx.x.xx/xxxx/x_00_00" xmlns:espisReg="urn:cz:isvs:espisReg:schemas:erms:v1">

<Kod>DopisOnLineTyp</Kod>

<Polozky>

<Polozka>

<Kod>DOPOR_CZ_TEST</Kod>

<Text>Test doporučená zásilka CZ</Text>

</Polozka>

<Polozka>

<Kod>DOPOR_EU_TEST</Kod>

<Text>Test doporučená zásilka EU</Text>

</Polozka>

<Polozka>

<Kod>URED_POUKAZKA_TEST_B</Kod>

<Text>Test úřední zásilka s poukázkou - typ B</Text>

</Polozka>

<Polozka>

<Kod>URED_TEST</Kod>

<Text>Test úřední zásilka</Text>

</Polozka>

<Polozka>

<Kod>URED_POUKAZKA_TEST_A</Kod>

<Text>Test úřední zásilka s poukázkou - typ A</Text>

</Polozka>

</Xxxxxxx>

<nsess:OperaceStatus>

<nsess:Kod>0000</nsess:Kod>

<nsess:Popis>OK</nsess:Popis>

</nsess:OperaceStatus>

</CiselnikZadostResponse>

</soap:Body>

</soap:Envelope>

Kódy číselníků ESSL e-spis, které lze z ISSD vyžádat

Verze e-spis	Kód číselníku	Doplňující data (od 2.35)	Popis
2.33	TypDokumentu	PlatnostOd, PlatnostDo, SkartacniRezim	Číselník typů dokumentů
	SpisovyPlan	PlatnostOd, PlatnostDo, SpisovyPlan (XML content)	Číselník spisových plánů
	SpisovyZnak	Identifikator, SkartacniRezim, PovolenyObsah, PlatnostOd, PlatnostDo	Číselník věcných skupin spisových plánů
	Vypravny	TypMista, TypKontaktu	Číselník výpraven a elektronických úředních desek
2.34	DopisOnLineTyp	ZpusobZachazeni, DopisOnLineParametry	Číselník typů zásilek "Dopis OnLine" (hybridní pošta)
	KategorieUredniDesky	OblastUredniDesky	Číselník kategorií úřední desky a oblasti, v níž je kategorie zařazena
	DruhZasilky	ZkratkaSluzby	Číselník druhů zásilek (uživatelské, nad rámec enumerátů DruhZasilkyId)
	ZpusobManipulace	Skupina	Číselník způsobů vypravení (způsobů manipulace - uživatelské nad rámec enumerátů ZpusobManipulaceId)

	PostovniSluzby	ZkratkaSluzby	Číselník základních a doplňkových poštovních služeb (uživatelské, nad rámec enumerátů PostovniSluzbaId)
2.35	SkartacniRezim	Identifikator, SkartacniZnak, SkartacniLhuta, SpousteciUdalost	Číselník skartačních režimů
	FunkceUtvarIdentifikator	NadrizenaOrgJednotka, KategorieUtvar	Číselník organizačních jednotek (OJ, např. pro interní vypravení)
	ZpusobZachazeni	DruhZasilky, PostovniSluzby, ZkratkaSluzby	Číselník povolených (organizací používaných) kombinací druhů zásilek, základních a doplňkových poštovních služeb Určuje celkové dispozice zásilky
	VysledekDoruceni	n/a	Číselník stavů zásilek - uživatelské hodnoty číselníku e-spis "Výsledek doručení"

Čl. 24. Doplňující data

Rozšíření e-spis pro doplňující data metody CiselnikZadostRequest (filtrování hodnot) a CiselnikZadostResponse (doplňující data položek dotazovaného typu číselníku)

24.1. Vstup - filtr

Element Povinný Pro číselník Hodnoty Popis