Rámcová dohoda o součinnosti

Rámcová dohoda o součinnosti

Smluvní strany:

Město Český Krumlov

se sídlem: xxxxxxx Xxxxxxxxx 0, 000 00 Xxxxx Xxxxxxx

zastoupené: Xxx. Xxxxxxx Xxxxx, starosta města

IČ, DIČ: 00245836, CZ00245836

bankovní spojení: Komerční banka a.s., číslo účtu: 221241/0100

(dále jen „Město“)

ICZ a.s.

se sídlem: Xx xxxxxxxxx XX 0000/00, Xxxxx, 000 00 Xxxxx 0

jednající: Xxxxxx Xxxxxxxx, na základě plné moci

IČ, DIČ 25145444, CZ699000372

společnost zapsaná v obchodním rejstříku vedeném Městským soudem v Praze, sp. zn. B 4840

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

číslo účtu: 2109164825/2700

(dále jen „Poskytovatel“)

(Město a Poskytovatel společně též označováni dále jako „smluvní strany“)

Smluvní strany dnešního dne uzavřely tuto rámcovou dohodu o součinnosti v souladu s ustanovením § 1746 odst. 2 zákona č. 89/2012 Sb., občanského zákoníku, v platném znění (dále jen „občanský zákoník“ nebo „OZ“) (dále jen „Smlouva“).

Smluvní strany, vědomy si svých závazků v této Smlouvě obsažených a s úmyslem být touto Smlouvou vázány, dohodly se na následujícím znění Smlouvy:

PREAMBULE

Město je příjemcem dotace v rámci projektu „Rozvoj služeb eGovernmentu města Český Krumlov“, reg. č. CZ.06.3.05/0.0/0.0/16_044/0006341 (dále jen „projekt“).

Projekt připraví prostředí pro sdílení elektronických služeb v rámci portálových prostředí včetně možnosti elektronického podání využitím elektronických formulářů, zajistí bezpečné a důvěryhodné prostředí pro výkon eGovernmentových služeb, doplní prvky pro bezpečnost a zajistí odpovídající úroveň síťové infrastruktury. Projekt si tak klade za cíl posílit infrastrukturu, konsolidovat ICT, podpořit standardizaci informačního systému města a zajistit potřebnou úroveň poskytování nejen elektronických služeb. Dojde tak k zefektivnění, zvýšení transparentnosti činnosti organizací Města, přístupnosti služeb a zajištění nezbytné bezpečnosti. Projekt zároveň vytváří podmínky, aby v dalším kroku po zefektivnění řízení procesů v rámci organizací Města došlo k významným úsporám na kapacitách či zdrojích Města.

Sdílí se elektronické služby, využívá se centrálních služeb eGovernmentu a doplní se infrastruktura pro uskutečnění záměrů. S tímto projektem budou sladěné další klíčové projekty Města, které spolu tvoří logický celek.

Projekt respektuje celostátní strategie a využívá jich ve svůj prospěch. Je s nimi komplementární a využívá centrálních služeb produkovaných státem. Je zároveň v souladu se strategickým dokumentem Digitální strategie města Český Krumlov, který udává základní směřování Města při využívání moderních technologií, určuje strategické priority a cíle a v neposlední řadě uvádí základní principy, kterými se Město řídí při pořizování a provozu informačních technologií.

Jedním z poptávaných řešení (mimo plnění této Smlouvy) je realizace Městského portálu občana spočívající mimo jiné v integraci portálu s eSSL ICZ e-spis® (dále jen „řešení“). V předchozí větě uvedené řešení tedy bude napojeno na stávající ICT systémy (ICT infrastrukturu) Města, aby mohlo být funkční, a současně aby mohlo naplnit cíle projektu.

Tato Smlouva je výsledkem zadávacího řízení s názvem „Rozvoj služeb eGovernmentu města Český Krumlov – část 2 – Integrace eSSL ICZ e-spis®“ vyhlášeného Městem.

PŘEDMĚT SMLOUVY

Předmětem této Smlouvy je stanovení podmínek pro uzavírání dílčích smluv a/nebo objednávek (dále jen „dílčích smluv“), kdy na základě těchto dílčích smluv bude Poskytovatelem Městu poskytnuta součinnost k integraci ICZ e-spis® provozovaného a užívaného Městem s ICT řešením Městského portálu občana dodaným vítězným dodavatelem – vítězem veřejné zakázky „Rozvoj služeb eGovernmentu města Český Krumlov – část 8 – Městský portál občana (Portál Krumlováka)“ vyhlášeného Městem.
Podrobný popis předmětu plnění je uveden v příloze číslo 1 a 3 této Smlouvy a bude upřesněn na základě dílčích smluv
Integrace proběhne v krocích a čase dle harmonogramu dle přílohy č. 2 Smlouvy a bude upřesněna na základě dílčích smluv.

CENA ZA PŘEDMĚT PLNĚNÍ
1. Cena předmětu plnění jednotlivých dílčích smluv bude vypočtena jako násobek počtu hodin, za které Poskytovatel dané plnění na základě dílčí smlouvy poskytne a hodinové sazby za služby Poskytovatele, která činí 1 850,- Kč bez DPH. Maximální počet hodin za plnění dodané Poskytovatelem na základě všech dílčích smluv je limitován na 108 hodin a pokrývá zejména konfigurační a konzultační služby spojené s dodáním adekvátního API rozhraní eSSL e-spis, součinnost s dodavatelem řešení, na které je stávající ICT řešení připojováno a případné ostatní náklady spojené s dodáním API rozhraní eSSL e-spis.
2. Cena bude hrazena na základě daňového dokladu (faktury) vystavené Poskytovatelem s třiceti (30) denní splatností. Poskytovatel je povinen Městu řádně vyúčtovat poskytnutý předmět plnění na základě každé dílčí smlouvy nejpozději ve lhůtě 10 dnů od předání daného plnění na základě této Smlouvy, resp. dílčí smlouvy. Faktura bude obsahovat náležitosti daňového účetního dokladu, formou a obsahem odpovídat zákonu č. 563/1991 Sb., o účetnictví, ve znění pozd. předpisů, zákonu o DPH a bude mít náležitosti obchodní listiny dle § 435 občanského zákoníku, ve faktuře bude rovněž uvedena informace, že je vyhotovena na základě této Smlouvy a odkaz na příslušnou dílčí smlouvu. V případě, že daňový doklad (faktura) nebude obsahovat tyto náležitosti, bude Městem vrácen k opravení bez proplacení. V takovém případě lhůta splatnosti počíná běžet znovu ode dne doručení opraveného či nově vyhotoveného daňového dokladu (faktury).
3. Každý daňový doklad (faktura) musí být označen názvem a číslem projektu „Rozvoj služeb eGovernmentu města Český Krumlov“, reg. č. CZ.06.3.05/0.0/0.0/16_44/0006341.
DALŠÍ UJEDNÁNÍ
1. Poskytovatel se jako osoba povinná dle ustanovení § 2 písm. e) zákona č. 320/2001 Sb., o finanční kontrole ve veřejné správě, v platném a účinném znění, zavazuje spolupůsobit při výkonu finanční kontroly, mj. umožnit všem subjektům oprávněným k výkonu kontroly přístup ke všem dokumentům, tedy i k těm částem nabídek, smluv a souvisejících dokumentů, které podléhají ochraně podle zvláštních právních předpisů (např. obchodní tajemství), a to za předpokladu, že budou splněny požadavky kladené právními předpisy; tuto povinnost rovněž zajistí Poskytovatel u případných poddodavatelů Poskytovatele.
2. Smluvní strany jsou povinny uchovávat veškerou dokumentaci související s realizací projektu včetně účetních dokladů minimálně do konce roku 2030. Pokud je v platných právních předpisech stanovena lhůta delší, musí ji smluvní strany dodržet.
3. Smluvní strany jsou povinny minimálně do konce roku 2030 poskytovat požadované informace a dokumentaci související s realizací projektu zaměstnancům nebo zmocněncům pověřených orgánů (Centru pro regionální rozvoj, Ministerstvu pro místní rozvoj ČR, Ministerstvu financí Č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 jsou povinny vytvořit výše uvedeným osobám podmínky k provedení kontroly vztahující se k realizaci projektu a poskytnout jim při provádění kontroly součinnost.
4. Smluvní pokuta pro případ prodlení Poskytovatele s provedením kteréhokoliv dílčího plnění na základě uzavření Dílčí smlouvy, činí za každý započatý kalendářní den prodlení 0,05 % z ceny dílčího plnění, s jehož realizací je Poskytovatel v prodlení. Výše smluvní pokuty však nepřesáhne částku odpovídající 30 % z ceny dílčího plnění.
5. V případě prodlení Města s úhradou bezvadné faktury se sjednává úrok z prodlení ve výši 0,05 % z dlužné částky za každý započatý kalendářní den prodlení.
POSTUP PRO UZAVÍRÁNÍ DÍLČÍCH SMLUV
1. Návrh na uzavření dílčí smlouvy zasílá Poskytovateli Město.
2. Návrh dílčí smlouvy musí obsahovat alespoň: popis plnění ve smyslu Přílohy č. 1 této Smlouvy, počet hodin plnění, lhůtu, ve které má být předmět dílčí smlouvy realizován, další informace nezbytné pro plnění. Počet hodin specifikovaný v návrhu dílčí smlouvy Městem zohlední vždy příslušnou část plnění, na kterou se dílčí smlouva vztahuje, a to zejména s ohledem na: předpokládanou náročnost plnění dílčí smlouvy a jeho vazbu na ICT řešení Městského portálu občana dodaným vítězným dodavatelem – vítězem veřejné zakázky „Rozvoj služeb eGovernmentu města Český Krumlov – část 8 – Městský portál občana (Portál Krumlováka)“ vyhlášeného Městem.
3. Návrh dílčí smlouvy musí být Poskytovatelem písemně potvrzen do 5 kalendářních dnů od jejího doručení Poskytovateli. Pokud Poskytovatel neakceptuje do 5 kalendářních dnů návrh dílčí smlouvy, musí být Poskytovatelem Městu zaslán ve stejné lhůtě protinávrh dílčí smlouvy k vyjádření s odůvodněním. Město buď protinávrh dílčí smlouvy písemně akceptuje, nebo písemně neakceptuje. V případě, že k akceptaci protinávrhu ze strany Města nedojde, Město může zaslat Poskytovateli nový návrh dílčí smlouvy ve smyslu ust. 4.1 této Smlouvy, nebo Město může dané plnění po Poskytovateli dále nepožadovat.
4. Město si vyhrazuje možnost žádný návrh na uzavření dílčí smlouvy za dobu účinnosti této Smlouvy neučinit.

UVEŘEJNĚNÍ SMLOUVY V REGISTRU SMLUV

5.1 Poskytovatel (ICZ a.s.) tímto žádá Město, aby v souladu s ust. § 3 odst. 1 zákona č. 340/2015 Sb., o registru smluv (dále „zákon o registru smluv“) před uveřejněním smlouvy (objednávky) před uveřejněním smlouvy v registru smluv provedl znečitelnění:

veškerých osobních údajů obsažených ve smlouvě, a to zejména v rozsahu jméno, adresa, email, telefon, podpisy jednajících osob,

A aby, Město v souladu s ust. § 3 odst. 1 zákona o registru smluv, výše uvedené informace v registru smluv nezveřejnil.

5.2 Dále Poskytovatel žádá Město, aby v souladu s ust. § 3 odst. 2 písm. b) zákon o registru smluv nezveřejnil:

Přílohu č. 3 smlouvy

a další údaje nebo informace obsažené ve smlouvě (objednávce), které představují technickou předlohu, návod, výkres, projektovou dokumentaci, model, způsob výpočtu jednotkových cen, vzor a výpočet.

Pro vyloučení pochybností Poskytovatel (ICZ a.s.) uvádí, že výše uvedená omezení se vztahují také na jakékoliv jiné uveřejnění smlouvy (objednávky) jako např. uveřejnění smlouvy na webových stránkách zadavatele nebo na profilu zadavatele a poskytnutí informací při postupu podle zákona č. 106/1999 Sb., o svobodném přístupu k informacím.

ZÁVĚREČNÁ USTANOVENÍ
1. Tato Smlouva může být měněna a doplňována pouze formou písemných dodatků podepsaných oběma smluvními stranami. Totéž platí pro dílčí smlouvy na základě této Smlouvy uzavřené.
2. Smluvní strany se dohodly, že v případě že z výše uvedené veřejné zakázky „Rozvoj služeb eGovernmentu města Český Krumlov – část 8 – Městský portál občana (Portál Krumlováka)“ vyhlášené Městem nevzejde vítězný dodavatel (resp. s ním nebude uzavřena smlouva, resp. smlouvy na plnění předmětu veřejné zakázky „Rozvoj služeb eGovernmentu města Český Krumlov – část 8 – Městský portál občana (Portál Krumlováka)“ pozbyde tato Smlouva účinnosti.
3. Tato Smlouva i dílčí smlouvy na základě této Smlouvy uzavřené se řídí právem České republiky. Tato Smlouva je vyhotovena ve třech originálech, z nichž Poskytovatel obdrží jeden originál a Město originály dva. Pokud oddělitelné ustanovení této Smlouvy je nebo se stane neplatným či nevynutitelným, nemá to vliv na platnost zbývajících ustanovení této Smlouvy. V takovém případě se smluvní strany zavazují uzavřít do 20 pracovních dnů od výzvy druhé ze stran této Smlouvy dodatek k této Smlouvě nahrazující oddělitelné ustanovení této Smlouvy, které je neplatné či nevynutitelné, platným a vynutitelným ustanovením odpovídajícím hospodářskému účelu takto nahrazovaného ustanovení.
4. Smluvní strany po přečtení této Xxxxxxx prohlašují, že souhlasí s jejím obsahem, že tato Xxxxxxx byla sepsána vážně, určitě, srozumitelně a na základě jejich pravé a svobodné vůle, na důkaz čehož připojují své podpisy.
5. Uzavřením této Smlouvy se nahrazují veškerá případná předchozí právní jednání Smluvních stran ve věci Poskytovatelem dodávané integrace eSSL ICZ e-spis® provozovaného a užívaného Městem s ICT řešením Městského portálu občana dodaným vítězným dodavatelem – vítězem veřejné zakázky „Rozvoj služeb eGovernmentu města Český Krumlov – část 8 – Městský portál občana (Portál Krumlováka)“ vyhlášeného Městem.
6. Tato smlouva nabývá účinnosti dnem uveřejnění v registru smluv. Uveřejnění v registru smluv provede Město a neprodleně o tom informuje Poskytovatele.
7. Nedílnou součást Smlouvy tvoří tyto přílohy:

Příloha č. 1: Specifikace předmětu plnění

Příloha č. 2: Harmonogram

Příloha č. 3: Integrace dle NS API

Poskytovatel

V XXX dne _____________

Město

V Českém Krumlově dne _____________

.........................................................................

Za Poskytovatele

Jméno a příjmení podepisujícího

.........................................................................

Město Český Krumlov

Xxx. Xxxxxxx Xxxxx, starosta

Příloha č. 1 Smlouvy o součinnosti
- Specifikace předmětu plnění

Přihlášený uživatel může zjistit stav svých el. podání vytvořených v rámci Portálu občana, integrace proběhne dle NS API, jak je blíže specifikováno v příloze č. 3.

Součástí předmětného plnění nebudou programové úpravy systému ICZ e-spis® a poskytnutých rozhraní na dodávaný systém Portálu občana.

Místem výkonu všech činností je sídlo Poskytovatele (ICZ a.s.):
Na hřebenech II 1718, 140 00 Praha 4-Nusle

Jednotlivé práce pracovníků Poskytovatele (ICZ a.s.) budou probíhat:
Ve všední dny v čase mezi 9:00-15:00

Poskytovatel je povinen Městu reagovat na jeho dotazy do 5 pracovních dnů.

Příloha č. 2 Smlouvy o součinnosti
- Harmonogram

Fáze projektu	Délka trvání fáze (v týdnech)
Zahájení projektu	T
Konfigurační dotazník	T+1
Vybudování integračního můstku – TEST prostředí	T+3
Testování a ověřování – TEST prostředí	T+4
Vybudování integračního můstku – PROD prostředí	T+6
Testování a ověřování – PROD prostředí	T+7
Ostrý provoz	T+9

Integrace systému ICZ e-spis a budoucího Portálu občana musí probíhat přes národní standard NS API 2.

Harmonogram předpokládá, že Město bude postupovat při realizaci tohoto projektu ve vzájemné důvěře a maximální součinnosti s Poskytovatelem (ICZ a.s.) se vstřícným vztahem k řešení vyskytnuvších se problémů a součinnost k jednotlivým výše uvedeným bodům poskytne do následujícího pracovního dne.

Pro vybudování integračního můstku je potřeba:

Vyplnění a předání konfiguračního dotazníku do 1 pracovního týdne od převzetí pro následnou konfiguraci spisové služby pro komunikaci s Portálem občana.
Při analýze současného stavu integrace a při pracích vyplývajících z nestandardně provedených stávajících integrací (např. chybějící identifikace již zaevidovaných dokumentů v ISSD, apod.).
Zajištění dispozice a ověření aktuálnosti verze ISSD dodavatele, která musí být kompatibilní s ICZ e-spis® v příslušné verzi provozované u zákazníka a to vč. podpory NSESSS komunikace
Zajištění vzdáleného přístupu k testovací instanci ICZ e-spis ®.
Sdělení e-mailových adres, na které budou zasílány k řešení notifikace o dávkách na rozhraní (např. Nejsou žádné příchozí dávky, Chyba v dávce)
Zaslání testovacích dávek do ISSD a řešené chyb zjištěných v dávkách
Plné otestování funkcionality ze strany integrovaného ISSD vůči rozhraní a včetně komunikace mezi ICZ e-spis® a ISSD.

Příloha č. 3 Integrace dle NS API

Dne 4. 7. 2017 nabyl účinnosti nový Národní standard pro elektronické systémy spisových služeb (dále NSESSS), který zveřejnilo Ministerstvo vnitra ČR na základě § 70 odst. 2 zákona č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů, ve znění zákona č. 190/2009 Sb. a zákona č. 167/2012 Sb., ve Věstníku MVČR v částce 57/2017 (část II). Součástí popisu tohoto NSESSS je i popis rozhraní na propojení systémů spravujících dokumenty (dále jen NS API). Popis API včetně XSD a WSDL souborů je možné stáhnout ze stránek MV ČR zde.

NS API ICZ e-spis^® se vyvinulo z původního API založeného na webových službách (mnohdy nazývané BP API – Best practicies API). Dle požadavků NSESSS bylo nutné ho upravit a v některých elementech rozšířit.

Oproti REST API (http API) ICZ e-spis^® se jedná principiálně o zcela nové pojetí – ne jenom technologicky přechodem na webové služby, ale zejména procesně. Spisová služba (ESSS) i Informační systém spravující dokumenty (ISSD) vystupují ve vzájemné komunikaci zcela rovnocenně, každý z těchto systémů (ERMS) může být stranou volající, ale i volanou.

Níže jsou uvedeny základní principy NS API ICZ e-spis^® (převzato z dokumentu „Obecné rozhraní pro komunikaci mezi elektronickými systémy spisových služeb agendovými informačními systémy.“):

Centrální – Základní předpoklad vychází z toho, že ESSS je centrální bod při evidenci dokumentů u původce (úřadu) a ISSD se podílejí na evidenci dokumentů.
Oboustranná – Je určeno pro oboustrannou komunikaci mezi ISSD a ESSS. Oba systémy jsou současně zdrojem i cílem přenosu dat.
Událostní – V rámci komunikace systémů bude prvotní popis procesu (událostí) a v jeho rámci popis dat objektů.

Jedná se tedy o událostně orientované rozhraní, které bude v rámci událostí přenášet data spojená s dokumenty, spisy, vypravením, obálkami, subjekty apod., popisem jejich metadat, popisem jejich stavů a u dokumentů také jejich obsahem.

ISSD bude ESSS předávat události týkající se evidence dokumentů sekvenčně a ESSS bude tyto události zaznamenávat do evidence dokumentů. ESSS bude podle potřeby předávat ISSD informace o událostech, které se týkají objektů z evidence dokumentů zpracovávaných agendou ISSD. Předávání událostí z ESSS do ISSD se týká zejména předání dokumentu/spisu ke zpracování v agendě, informace o vypravení nebo doručení dokumentu zpracovávaného agendou.

Toto rozhraní se zabývá výhradně daty spojenými s výkonem spisové služby. Neřeší popis procesů, predikci jejich dalších kroků (plánování procesů). Neřeší řízení toku dokumentů, jejich agendové atributy a vazby na agendové procesy atd.

Sekvenční – Jak již bylo zmíněno, události vzniklé v ISSD budou předávány do ESSS a tam zpracovávány sekvenčně, a to podle pořadí jejich vzniku. Stejné pravidlo platí obráceným směrem při přenosu událostí z ESSS do ISSD.

Národní standard – Rozhraní je založeno na Národním standardu pro elektronické systémy spisových služeb. Vychází z XML schémat a pravidel, která byla vytvořena pracovní skupinou sedmi výrobců spisových služeb a následně byly připojeny k NSESSS jako jeho přílohy č. 1A – 1F. Tato spolupráce výrazně usnadnila vznik tohoto rozhraní a dále usnadní napojení spisových služeb dalších ISSD.

Webové služby – Rozhraní je realizováno s pomocí webových služeb. Toto řešení nevyžaduje interakci uživatelů nebo pracovníků IT a funguje zcela samostatně na pozadí. Toto rozhraní je pro uživatele "neviditelné".

Synchronní i asynchronní rozhraní využívá synchronní (on-line) i asynchronní (off-line) komunikace a zpracování dat.

Exkluzivní přístup – Objekty, které jsou předmětem tohoto rozhraní, jsou vždy ve výhradní správě jednoho systému. Tento systém může jako jediný manipulovat s objektem. Tzn. že ESSS ani jiný ISSD nemůže modifikovat atributy objektu. Objekt ve výhradní správě jednoho systému (zamčený objekt) zůstává i nadále dostupný „pro prohlížení“ v ESSS a ostatním agendám.

Konzistence – Rozhraní při své činnosti musí za všech okolností zachovat vždy konzistentní stav objektů, a to v obou komunikujících systémech.

Identifikace – Jednou z klíčových věcí při komunikaci ERMS je způsob identifikace objektů. Identifikace objektů musí být unikátní a v čase neměnná. Všechny objekty, které jsou přenášeny přes rozhraní, musí být identifikovány tak, aby i v budoucnu bylo možnost tyto objekty znovu jednoznačně identifikovat a pracovat s nimi. Identifikace musí být unikátní v rámci původce a všech jeho ERMS.

Práce spojené s nastavením integrace na ISSD zahrnují:

Analýzu stavu stávající integrace.
Konfigurace spisové služby pro komunikaci s ISSD dle konfiguračního dotazníku vyplněného zákazníkem.
Ověření komunikace mezi ICZ e-spis® a ISSD.
Zaslání testovacích dávek do ISSD.
Nastavení notifikací o dávkách na rozhraní v těchto případech:
- Nejsou žádné příchozí dávky
- Chyba v dávce
Další práce vyplývající z analýzy při nestandardně provedených stávajících integracích (např. chybějící identifikace již zaevidovaných dokumentů v ISSD, apod.)
Zvýšená podpora provozu po přechodu do produkce

Změny ICZ e-spis® v souvislosti s přechodem na API WS (NS)

Verze 2.34

1. Metadata subjektů doručení / vypravení

Doručení a vypravení dokumentu bude v response metod API rozhraní obsahovat metadata Subjektu a Adresy ve struktuře údajů zapsaných u doručení či vypravení v GUI e-spis, korespondující s použitým způsobem manipulace (vypravení). Nadále nebudou v údajích subjektu předávány údaje o dalších adresách z rejstříku subjektů. Úprava vychází z potřeby minimalizovat dotazy na údaje subjektů z rejstříku e-spis nad rámec údajů nezbytných pro účely užití v souvislosti s nařízením GDPR a z nutnosti poskytovat integrovaným ISSD metadata odpovídající obsahově danému účelu zpracování - provedení záznamu o subjektu vypravení / doručení.

2. Číselníky

Doplnění nových číselníků, jejichž hodnoty lze načíst službou CiselnikyZadostRequest (DruhZasilky, ZpusobManipulace, PostovniSluzby, KategorieUredniDesky, DopisOnLineTyp)

3. Parametry zásilek

Číselníkové hodnoty ESSL pro DruhZasilky, ZpusobManipulace a PostovniSluzby uvedeny do souladu s enumeráty příslušných metadatových položek dle NSERMS. Nastavené parametry zásilek přes rozhraní NS API odpovídají nastaveným přípustným kombinacím, které organizace v ESSL definuje.

4. Čtecí funkce - dotazy na metadata a obsahy souborů

Funkce ProfilSpisuZadost, ProfilDokumentuZadost a SouborZadost nevyžadují výhradní držení dotazovaného objektu v ISSD. U těchto metod systém provádí pouze kontrolu práv - ACL - autentizovaného uživatele na požadovaný objekt, pokud uživatel oprávnění má, vrátí metoda metadata nebo obsah konkrétně identifikovaného objektu.

5. Vypravení Dopis OnLine

Rozšíření doplňujících dat vypravení (pro metodu VypraveniZalozeni) o specifické atributy zásilek vypravovaných službou hybridní pošty "Dopis OnLine" provozované Českou poštou s.p. - fragment "DopisOnLine" s parametry hybridní zásilky a volitelně poštovní poukázky.

Verze 2.34.02

1. Upraveno zakládání kopie, jakožto souvisejícího dokumentu

Předpokladem pro založení kopie je konkretizace důvodu vazby v elementu DuvodId hodnotou "kopie", příklad <DuvodId>kopie</DuvodId>v rámci elementu SouvisejiciDokument.

2. Založení vypravení s požadavkem na ekonomické doručení

Z důvodu nejednotnosti uváděné hodnoty v rámci elementu PostovniSluzbaText pro způsob ekonomického doručení je možné zasílat hodnotu "EkonomickeDoruceni" i "EkonomickeDorucovani". Obě hodnoty budou zpracovány stejně.

Verze 2.34.03

1. Upraveny adresní údaje o subjektu v rámci funkce ProfilDokumentuZadostResponse

Pro funkci ProfilDokumentuZadostResponse je upraveno uvádění adresy subjektu dle způsobu doručení v elementu Adresa.

2. Připojování nové verze souboru (komponenty)

Událostí SouborNovaVerze lze zasílat e-spisu nové verze jednotlivých elektronických souborů (komponent) i přesto, že nejsou dopodus připojeny k

žádnému dokumentu.

Verze 2.35

1. Číselníky

Rozšíšení žádosti o obsah dalších číselníků ESSL e-spis:

SkartacniRezim - číselník skartačních režimů a spouštěcích událostí

FunkceUtvarIdentifikator - číselník organizačních jednotek pro účely interního vypravení dokumentu mezi útvary

ZpusobZachazeni - číselník způsobů zacházení, tj. kombinací druhů zásilek a poštovních služeb

VysledekDoruceni - číselník uživatelských hodnot výsledku doručení

2. Implementace nových událostí

a) Příchozí do ESSL - SpisExterniSpousteciUdalost, DokumentExterniSpousteciUdalost

b) Odchozí z ESSL - SpisSkartovano, DokumentSkartovano

Jedná se o předávání informace o nastálém okamžiku externí spouštěcí události dokumentu nebo spisu a informace o provedeném skartačním řízení nad dokumentem nebo spisem. Všechny jmenované události rovněž vyžadují autorizaci konkrétního uživatele (zpravidla vlastníka, posledního držitele objetku v ESSL). Vzhledem k tomu, že události mohou nastat v časovém okamžiku, kdy původní uživatel, vlastník, nemusí již v systémech figurovat, byla doplněna konfigurační položka ESSL e-spis (setup), tzv. "API technický účet". Ve výchozí konfiguraci obsahuje parametr hodnotu shodnou se zdroj_ID použitou pro ESSL e-spis. Hodnota musí být obecně akceptovatelná v obou systémech, v ESSL i integrovaném ISSD. Pokud pak

bude některá z výše uvedených nových událostí odeslána s autorizací uživatele pomocí "API technického účtu", bude její zpracování provedeno bez ověření uživatele. V této souvislosti byly upraveny hodnoty tzv. spouštěcích událostí skartačních režimů, předávané prostřednictvím API rozhraní. Spouštěcí události skartačních režimů jsou zobrazeny např. při dotazu na obsah číselníku "Skartační režim" nebo jsou součástí evidenčních údajů dokumentu/spisu, profilových metadat. Element SpousteciUdalost u skartačního režimu může pak nabývat hodnot:

Vznik - spouštěcí událostí pro běh skartačních lhůt je datum vzniku dokumentu či spisu (zpravidla se ve spisových plánech nevyužívá)

VyrizeniUzavreni - spouštěcí událostí pro běh skartačních lhůt je datum vyřízení dokumentu nebo datum uzavření spisu (většina skartačních režimů nastavených k věcným skupinám spisového plánu)

ExterniUdalost - text začínající tímto řetězcem, za pomlčkou může obsahovat upřesnění externí události (př.: ExterniUdalost-

UkonceniSmlouvy, ExterniUdalost-RzpZanikSubjektu apod.), jedná se o spouštěcí události, jejichž datum nemusí být v době vyřízení dokumentu, uzavření spisu známo, ve spisových plánech v rámci spisového řádu organizace jsou tyto tzv. externí spouštěcí události skartačních režimů vyznačeny poznámkou u lhůty, v níž je uvedeno, k jakému okamžiku se počátek běhu lhůty vztahuje (např. zmíněné ukončení smlouvy, zánik stavby, zánik subjektu, neaktivní subjekt apod.)

Skartační režimy, resp. spouštěcí události skartačních režimů ISSD aktivně nenastavuje, jedná se tedy o informaci odesílanou z ESSL do ISSD.

3. Doplňující data vypravení

Rozšíření doplňujících dat zásilky, vypravení dokumentu (espisVypraveniExtensions) o nový element VysledekDoruceni. V elementu bude uváděna skutečná číselníková hodnota ESSL e-spis (tedy bez mapování na enumeráty standardního elementu StavZasilky). Pro uživatelsky založené záznamy v číselníku ESSL e-spis "Výsledek doručení" pak tedy na výstup z ESSL bude uvedena hodnota StavZasilky "vypraveno" a skutečný stav nad rámec enumerátů NSERMS bude uváděn v hodnotě nového elementu doplňujících dat vypravení - VysledekDoruceni.

4. Doplňující data metod a událostí

V rámci událostí DokumentVraceni a SpisVraceni je možné uvádět v doplňujících datech upřesňující způsob vrácení, rozlišit standardní vrácení z postoupení od vrácení z postoupení z důvodu odmítnutí zpracovávání dokumentu či spisu v ISSD. Upřesnění způsobu vrácení se uvádí ve složeném fragmentu DoplnujiciData/VraceniZpusob (je tvořen elementy VraceniTypId a VraceniDuvod). Plnění elementů má dopady na další zpracování vrácených dokumentů a spisů v ESSL e-spis (vyžaduje "ruční" dokončení procesu vrácení objektu z postoupení).

Verze 2.35.03

1. Upraveno zakládání kopie, jakožto souvisejícího dokumentu

Předpokladem pro založení kopie je konkretizace důvodu vazby v elementu DuvodId hodnotou "kopie", příklad <DuvodId>kopie</DuvodId>v rámci elementu SouvisejiciDokument.

2. Založení vypravení s požadavkem na ekonomické doručení

Verze 2.35.04

1. Upraveny adresní údaje o subjektu v rámci funkce ProfilDokumentuZadostResponse

Pro funkci ProfilDokumentuZadostResponse je upraveno uvádění adresy subjektu dle způsobu doručení v elementu Adresa.

2. Připojování nové verze souboru (komponenty)

Událostí SouborNovaVerze lze zasílat e-spisu nové verze jednotlivých elektronických souborů (komponent) i přesto, že nejsou dopodus připojeny k žádnému dokumentu.

Verze 2.36

1. Dávky bez událostí

Pokud generovaná dávka ESSL nebude obsahovat žádné události do dávky, nebude v generované dávce obsažen element Udalosti. Takto budou generovány jak asynchronní dávky ermsAsyn, tak sychronní odpověď DavkaZadostResponse. Změna odpovídá definičnímu schématu NS API. Tato úprava aplikována již od hotfix e-spis 2.35.01.01.

2. Doplňující data - zpracování

Při zpracování rozšiřujících dat (DoplnujiciData) entit dokumentu, spisu, zásilky nebo doplňujících dat metod DokumentVraceni a SpisVraceni budou zpracovávány pouze hodnoty elementů v namespace icz, resp. rzp (pouze agenda RŽP), a to ve struktuře elementů popsaných v dokumentaci NS API e-spis. Elementy doplňujících dat neodpovídající uvedené specifikaci budou ignorovány.

3. Finální verze souboru

V integračním můstku ISSD bude možné nastavit defaultní způsob generování souboru - s příznakem finální verze / bez příznaku finální verze. Zároveň budou rozšířena doplňující data souboru (espisSouborExtension) o elementy:

FinalniVerze - povolené hodnoty [Y, N], umožní nastavit příznak finální verze souboru agendou Puvod - povolené hodnoty [Digitalni, KonverzeOriginal, KonverzeKopie, Digitalizace], umožní specifikovat původ připojovaného souboru Uvedené elementy doplňujících dat budou zpracovávány na vstupu z ISSD do ESSL v metodách SouborZalozeni, SouborVlozitKDokumentu, SouborNovaVerze.

4. Seznam přidělených dokumentů a spisů

Definice response metody PrideleneSeznamResponse v rámci ermsIFSyn.xsd obsahuje formální chybu, kdy response může obsahovat pouze dokumenty nebo pouze spisy. V reálných podmínkách je seznam přidělených objektů tvořen jak dokumenty tak spisy. Aby bylo možné generovat validní response metody dle stávajícího schématu NS API, bude metoda PrideleneSeznamRequest rozšířena následovně: filtr metody (DoplnujicData) rozšířeny o element PrideleneTyp, povolené hodnoty [Dokument,Spis] pokud nebude filtr uveden, vrátí metoda seznam přidělených dokumentů S uvedeným rozšířením tedy metoda vrátí v jednom průchodu pouze jeden druh objektu - bez filtru nebo Dokument vrací seznam přidělených

dokumentů autentizovaného uživatele, s filtrem Spis seznam přidělených spisů uživatele. Pro kompletní seznam přidělených objektů tedy bude nutné ze strany ISSD volat metodu dvakrát.

5. Zrušení dokumentu nebo spisu v ISSD

Při volání metod DokumentZruseni nebo SpisZruseni dojde spolu se zrušením k vrácení zrušeného objektu z ISSD do ESSL e-spis, tedy bude rozpojena vazba externí agendy na zrušený dokument nebo spis.

6. USN - načtení progaramu jednání

Rozšíření, doplnění rozšiřující API metody pro modul Usnesení umožní načíst program konkrétního jednání volitelně určením Identfikátoru jednání nebo určením kombinace čísla jednání (kódu jednání) a data jednání.

7. Rozšiřující metody API rozhraní e-spis

Technická změna, převod rozšiřujících API metod pro Usnesení, Registratury, Portál a Subjekty do schématu NS API.

8. Automatické odeslání VypraveniDoruceno

Události VypraveniDoruceno a VypraveniVypraveno jsou automaticky generovány u způsobu doručení "ElektronickaPosta" a nově i u "Osobne"

9. Vyhodnocení FormaDokumentu při zakládání spisu

Při založení spisu se vyhodnotí FormaDokumentu spisu podle dokumentů nad kterými je zakládaný..

10. Vyhodnocení FormaDokumentu při vkládání komponent do dokumentu.

Do nastavení externí aplikace v Customeru přidána možnost vypnout (checkbox není označen)/zapnout predikci FormaDokumentu při vkládání komponent k dokumentu. Pokud predikci vypneme e-spis nebude vyhodnocovat FormaDokumentu a FormaDokumentu zůstane stejná.

11. Oprava PodaciDenikRok při založení spisu nad dokumentem z minulého roku

Oprava chyby, která vracela špatný PodaciDenikRok. Nyní se PodaciDenikRok vypočítává z data založení dokumentu, nad kterým zakládáme spis.

12. Zrušení odpovědi na doručený dokument

Umožněno zrušit odpověď na doručený dokument . Odpověď nesmí být vypravena (vypravení nesmí být předáno výpravně).

Verze 2.36.05

1. Upraveno zakládání kopie, jakožto souvisejícího dokumentu

Předpokladem pro založení kopie je konkretizace důvodu vazby v elementu DuvodId hodnotou "kopie", příklad <DuvodId>kopie</DuvodId>v rámci elementu SouvisejiciDokument.

2. Založení vypravení s požadavkem na ekonomické doručení

Verze 2.36.06

1. Upraveny adresní údaje o subjektu v rámci funkce ProfilDokumentuZadostResponse

Pro funkci ProfilDokumentuZadostResponse je upraveno uvádění adresy subjektu dle způsobu doručení v elementu Adresa.

2. Připojování nové verze souboru (komponenty)

Událostí SouborNovaVerze lze zasílat e-spisu nové verze jednotlivých elektronických souborů (komponent) i přesto, že nejsou dopodus připojeny k žádnému dokumentu.

3. Evidence portálového podání obsahující IČO v nestandardním formátu

U portálového podání se subjektem obsahujícím zahraniční IČO, jsou tyto údaje zapsány do pole "Poznámka subjektu" na záložce "Doručení" a pole "Reprez. subjekt" na záložce "Profil" zaevidovaného dokumentu.

Verze 2.36.08

1. Podpora SOAP 1.2

2. Evidence nového důvodu vazby mezi souvisejícími dokumenty

Umožněno je vytvoření vazby mezi souvisejícími dokumenty v rámci navazujícího řízení, u kterých je požadována společná likvidace. Jedná se o typ vazby "souvisejici" s upřesněním, že se jedná o navazující dokument. S tímto typem vazby je v DESA možné zajistit (v rámci konfigurace), že objekty s ohledem na skartační lhůty budou moci být zařazeni do skartačního návrhu až společně.

Příklad použití:

<v:SouvisejiciDokument>

<v:Identifikator>

<v:HodnotaID>22344</v:HodnotaID>

<v:ZdrojID>eos</v:ZdrojID>

</v:Identifikator>

<v:DuvodId>souvisejici</v:DuvodId>

<v:DuvodText>navazujici</v:DuvodText>

<v:DoplnujiciData></v:DoplnujiciData>

</v:SouvisejiciDokument>

3. Zasílání informací externí agendě o provedené skartaci či archivaci objektu

Upraveno generování události DokumentSkartovano a SpisSkartovano pro externí agendy, které probíhá automaticky po zaznamenání provedení likvidace či předání archivu ve spisovně.

O konkrétních úpravách a implementacích změn a doplnění budeme průběžně informovat v novinkách každé nové verze ESSL e-spis

Document Metadata

Table of Contents

Rámcová dohoda o součinnosti

Document Metadata