Zadávací dokumentace – Příloha č. 3.b

Zadávací dokumentace – Příloha č. 3.b

k nadlimitní veřejné zakázce na dodávky

„Portál občana města Český Brod“

Obsah

1. Zkratky a pojmy 3

2. Místo plnění 3

3. Doba plnění 3

4. Způsob prokázání splnění požadavků minimálního plnění 4

5. Požadavky na řešení Portálu občana 5

provedení integrací na současné systémy v prostředí IS zadavatele; 5

úpravy dodaného řešení dle potřeb a požadavků dle pokynů zadavatele; 5

zaškolení uživatelů a administrátorů; 5

testování; 5

zvýšené podpory v předproduktivním provozu; 5

5.1 Společné vlastnosti řešení Portálu občana 6

5.1 Společné vlastnosti řešení Portálu občana 6

5.2 Realizační část a) - Statické stránky webu 7

5.2 Realizační část a) - Statické stránky webu 7

5.3 Realizační část b) - Portál elektronických služeb s platební branou 13

5.3 Realizační část b) - Portál elektronických služeb s platební branou 13

5.4 Realizační část c) - Místní poplatky 17

5.4 Realizační část c) - Místní poplatky 17

5.5 Realizační část d) - Podpora rozhodovacích procesů 26

5.5 Realizační část d) - Podpora rozhodovacích procesů 26

5.6 Realizační část e) – Robotizace správy přestupků 31

5.6 Realizační část e) – Robotizace správy přestupků 31

5.7 Realizační část f) – Participace na řízeném rozvoji města 36

5.7 Realizační část f) – Participace na řízeném rozvoji města 36

6. Fáze A – Implementace řešení 37

6.1 Zpracování a akceptace Detailního cílového konceptu 38

6.1 Zpracování a akceptace Detailního cílového konceptu 38

6.2 Dodávka licencí 39

6.2 Dodávka licencí 39

Implementace Testovacího a Produkčního prostředí 39

Implementace Testovacího a Produkčního prostředí 39

Produkční provoz s podporou 40

Produkční provoz s podporou 40

Předání a převzetí plnění 40

Předání a převzetí plnění 40

6.2.1 Předání a převzetí dokumentů 40

6.2.1 Předání a převzetí dokumentů 40

6.2.2 Předání a převzetí ostatních plnění dle Xxxxxxx o dílo (vyjma služeb) 42

6.2.2 Předání a převzetí ostatních plnění dle Xxxxxxx o dílo (vyjma služeb) 42

6.2.3 Migrace dat 44

6.2.3 Migrace dat 44

6.2.4 Technologické prostředí 44

6.2.4 Technologické prostředí 44

6.2.5 Školení 44

6.2.5 Školení 44

6.2.6 EXIT plán 45

6.2.6 EXIT plán 45

7. Fáze B – Servisní podpora řešení, SLA 46

8. Požadavky na technický popis řešení v nabídce 48

1. Zkratky a pojmy

1. Zkratky a pojmy užité v ZD jsou uvedeny v Příloze 3.a ZD, specifické zkratky a pojmy poplatné zejména této části VZ jsou v následující tabulce.

2. Jedná se o podpůrnou informaci, kterou Zadavatel poskytuje pro zachování jednoznačného výkladu textu dokumentu.

Zkratka / pojem	Význam
DCK	Detailní cílový koncept
Části projektu	Popis rozsahu řešení je rozdělen do realizačních částí projektu a) až e) specifikovaných v kapitolách 5.2 až 5.6
SLA	Service Level Agreement
Fáze A	Implementace technologií v souladu se Smlouvou
Fáze B	Servisní (technická) podpora technologií v souladu se Smlouvou
Smlouva	V rámci tohoto dokumentu je pojmem Xxxxxxx myšlena Příloha č. 4 ZD

2. Místo plnění

Místem plnění je budova MÚ na adrese specifikované v Zadávací dokumentaci.

3. Doba plnění

1. Dodávka jednotlivých částí projektu bude zahájena po podpisu smlouvy VZ a bude řízena milníky uvedenými v Tabulce níže

2. Milníky Fáze A dané části VZ (implementace) dle Smlouvy.

Id	Činnosti		Termín
01	Nabytí účinnosti Smlouvy		bude upřesněno dle ukončení zadávacího řízení
Fáze A – Implementace Portálu občana
02	Zpracování a akceptace Detailního cílového konceptu Výstupem bude dokument Detailní cílový koncept Předání dílčího plnění a Akceptace dílčího plnění		do 6 týdnů od nabytí účinnosti smlouvy
03	Instalace SW Předání dílčího plnění		do 4 týdnů po Id 02
04	Zkušební prostředí a produkční provoz s podporou	Implementace zkušebního (testovacího) prostředí Vytvoření testovací prostředí (vč. požadovaných rozhraní) Školení uživatelů, konzultace Testování funkčnosti na testovacím prostředí (1 měsíc) Akceptace Testovacího provozu a školení	do 5 měsíců po Id 03
05		Produkční provoz s podporou Vytvoření produkčního prostředí (vč. požadovaných rozhraní), metodické a konzultační služby Akceptace produkčního provozu, akceptace Fáze A Ukončení Fáze A	do 2 měsíců po Id 04

3. Fáze B – Servisní (technická) podpora implementovaného řešení dle Smlouvy o podpoře bude zahájena ukončením Fáze A (ukončení projektu akceptací produktivního provozu s podporou).

4. Termín ukončení se může změnit z objektivních příčin, způsobených třetími stranami nebo jinými okolnostmi, nezávislými na vůli smluvních stran.

4. Způsob prokázání splnění požadavků minimálního plnění

1. Zadavatel požaduje, aby Dodavatelem nabízená dodávka splňovala veškeré dále uvedené požadavky (funkcionality a parametry) a tyto byly zahrnuty v nabídce Dodavatele a v celkové nabídkové ceně.

2. Dodavatel ve své nabídce jednoznačně deklaruje splnění, popřípadě absenci každého níže uvedených požadavků v tabulkách označených jako „Minimální požadavky …“, a to vyplněním příslušného pole „Splněno“ jedno ze dvou nabízených možností:

„ANO“ v případě že dodávka Dodavatele (Nabídka) minimální požadavek splňuje

nebo „NE“ v případě že dodávka Dodavatele (Nabídka) minimální požadavek nesplňuje

Zadavatel požaduje po Dodavatelích, aby uvedli informaci o skutečné funkcionalitě nabízeného řešení, kterou bude možné ověřit již v testovacím provozu (Testovací provoz, např. v rámci školení uživatelů a administrátorů).

3. Nesplnění kteréhokoli ze stanovených minimálních požadavků bude znamenat vyloučení účastníka ze zadávacího řízení.

4. Zadavatel požaduje, aby Dodavatel, kromě vyplnění tabulek v kapitole 5, podrobně popsal návrh nabízeného řešení v samostatné kapitole.

5. Tato kapitola 4 platí pro následující kapitoly 5 až 7.

5. Požadavky na řešení Portálu občana

1. Řešení bude integrováno do stávajícího IS města a bude splňovat všechny požadované související legislativní povinnosti.

2. Popis požadovaného rozsahu řešení je rozdělen do realizačních částí a) až f) specifikovaných v kapitolách 5.2 až 5.7

1. Statické stránky webu;

2. Portál elektronických služeb s platební branou;

3. Místní poplatky;

4. Podpora rozhodovacích procesů;

5. Robotizace správy přestupků;

6. Participace na řízeném rozvoji města;

v rozsahu:

• dodávky licencí;

• instalace aplikační a databázové části systému včetně vytvoření testovací instance;

• implementačních služeb:

provedení integrací na současné systémy v prostředí IS zadavatele;

úpravy dodaného řešení dle potřeb a požadavků dle pokynů zadavatele;

zaškolení uživatelů a administrátorů;

testování;

zvýšené podpory v předproduktivním provozu;

• dokumentace:

• k dodaným částem informačního systému v požadovaném rozsahu;

• k dodaným integračním rozhraním.

Zadavatel požaduje vytvoření a provoz dvou prostředí – produkčního a testovacího (školícího) po celou dobu nasazení u zadavatele.

Zadavatel požaduje udržení testovacího prostředí po celou dobu udržitelnosti projektu (5 let od akceptace předmětu plnění).

1. Společné vlastnosti řešení Portálu občana

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

ID	Obecné principy a technologické vlastnosti	Splněno
1	Kompletní lokalizace aplikační části (tj. všech produktů z pohledu licencí) v českém jazyce, vč. dokumentace k předmětným licencím.
2	Soulad všech agend a částí systému s platnou legislativou na území ČR platnou pro subjekty veřejné správy (orgány veřejné moci).
3	Plně elektronizované řešení, nahrazující v implementovaných oblastech papírový oběh dokumentů.
4	V rámci systému zadávání dat pouze jednou, se sdílením dat v dalších oblastech / modulech systému, okamžitý přístup k těmto datům ve všech oblastech / modulech.
5	Pohledy nad daty (základní pohledy, výsledky hledání - filtrování atd.) lze třídit dle různých kritérií vybraných uživatelem, následně vygenerovat výstupní sestavu, kterou bude možno zobrazit na obrazovce, tisknout na tiskárně nebo exportovat do běžných formátů (XLS, XML, DOC, HTML, PDF).
6	Logování operací – všechny kroky a operace prováděné v systému jsou ukládány, a je možné je zpětně dohledat
7	Administrace a konfigurace bez nutnosti zásahu zhotovitele.
8	Součástí nabídky budou zahrnuty veškeré náklady spojené se součinností stávajících dodavatelů systémů (tj. pořízení licence, součinnosti při implementaci a provozní náklady).
9	Dodavatel v nabídce podrobně popíše způsob integrace jím nabízených software komponent se systémy, se kterými je požadována integrace, v dostatečném detailu, který umožní posoudit praktickou možnost realizace navrhovaného technického řešení ve stanoveném harmonogramu.
10	Součástí licencí pro poptávané řešení jsou i licence konektorů pro integraci vůči externím systémům, tzn. z pohledu licencí nebude zadavatel pro účely další integrace nucen pořizovat žádné další licence rozhraní. Aplikační rozhraní bude poskytnuté jako součást plnění a jeho využití nebude vyžadovat žádné další náklady pro zadavatele (např. dokupování licencí, navyšování servisní podpory apod.).
11	Nastavení všech parametrů řešení bez nutnosti zásahu dodavatele.

2. Realizační část a) - Statické stránky webu

Realizačních část webových statických stránek bude jako rozcestník poskytovat statické informace o elektronických službách s provázáním na transakční portál nových elektronických služeb a bude implementována jako funkční rozšíření stávajících webových stránek města.

Uvedené požadované vlastnosti řešení v níže uvedené tabulce znamenají minimální míru plnění dle této ZD.

ID	Požadované principy a technologické vlastnosti statických stránek webu	Splněno
Základní požadavky
1	Uchazeč bude garantovat dostupnost služby webových stránek 99,5 % / měsíc (vyjma předem hlášených a schválených výpadků).
2	Pro webové stránky bude poskytnut prostor minimálně 60 GB, s možností navýšení (velikost záloh se do tohoto limitu nezapočítává). Neomezený limit přenesených dat.
3	Poskytnutí odděleného prostoru, kde bude moci zadavatel nahrát (nejlépe pomocí FTP) a publikovat na redakčním systému nezávislý obsah.
4	K webovým stránkám bude možnost nastavit omezený přístup – takový, aby k nim nebyl veřejný přístup (a nebyl indexován roboty vyhledávačů), ale přístup zadavatele k webovým stránkám byl zachován v plném rozsahu.
5	Možnost obnovení ke stavu kteréhokoliv dne až 30 dní zpětně.
6	Pravidelné aktualizace a udržování bezpečnosti nasazováním záplat na OS a SW (webový server, databázi).
7	Musí být splněny zákonné požadavky vyplývající z níže uvedených předpisů v platném znění: Zákon č. 106/1999 Sb., o svobodném přístupu k informacím, ve znění pozdějších předpisů; Xxxxxxxx č. 515/2020 Sb., kterou se stanoví struktura informací zveřejňovaných o povinném subjektu a o osnově popisu úkonů vykonávaných v rámci agendy; Zákon č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů; Nařízení Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a volném pohybu těchto údajů a o zrušení směrnice 95/46/ES;  Zákon č. 110/2019 Sb., o zpracování osobních údajů;  Zákon č. 99/2019 Sb. o přístupnosti internetových stránek a mobilních aplikací a změně zákona č. 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ů.
Grafické požadavky
1	Grafické zpracování webových stránek (dále jen „grafický návrh“) bude respektovat požadavky na vytvoření moderního designu webových stránek – grafický návrh bude odpovídat obecně zvyklostem a současným trendům a bude akceptovat požadavky zadavatele, a to jak na barevnost, tak na obsah a uspořádání jednotlivých stránek webových prezentací a bude podřízen požadované struktuře webu s akcentem na titulní stranu. Grafický návrh bude spočívat v návrhu kompletního designu, vytvořeného na základě kreativní koncepce vycházející z vymezení zamýšleného charakteru webové prezentace města. Grafický návrh předloží vybraný uchazeč v následujícím rozsahu: 4 grafické návrhy v souladu s grafickým manuálem města; Při zpracování grafického návrhu doporučujeme vycházet z heraldických barev města, grafický manuál bude dodán po jeho schválení. Z předloženého grafického návrhu, resp. ze všech grafických návrhů (dle výše uvedeného) musí být zřejmé: grafické ztvárnění struktury webu (kategorií); logické návaznosti pro uživatele; barevné odlišení jednotlivých typů informací; přehlednost a praktičnost struktury pro uživatele; použitý font písma; vzhled a členění běžné stránky. Zadavatel vybere grafický návrh, přičemž je oprávněn požadovat jeho dopracování a úpravu dle vlastních požadavků. Xxxxxxx se zavazuje zapracovat požadavky zadavatele do vybraného grafického návrhu tak, aby po případných drobných úpravách mohl být grafický návrh odsouhlasen zadavatelem pro finální zpracování pro webové stránky.
2	Grafický návrh musí splňovat požadavky na bezbariérovost, a to jak podle legislativních požadavků dle zákona č. 365/2000 Sb., o informačních systémech veřejné správy, ve znění pozdějších předpisů a zákona č. 99/2019 Sb. o přístupnosti internetových stránek a mobilních aplikací, ve znění pozdějších předpisů, tak podle obecných zvyklostí a současných trendů (WCAG).
3	Grafický návrh bude optimalizován pro všechny druhy nejrůznějších zařízení (mobily, notebooky, tablety atd.). Uspořádání obsahu na stránce, stejně jako velikost obrázků bude přizpůsobeno šířce zobrazení.
4	Administrátorem přístupný archiv sejmutých dokumentů na úřední desce. Součástí plnění je vazba na essl GINIS.
5	Pro zohlednění tisku stránek je požadována optimalizace zobrazení obsahu pro tiskárny ve smyslu odlišného formátování tisku pomocí CSS.
6	Web musí být validní podle specifikací W3C (HTML šablony a CSS styly). Web musí být validní vůči doporučení WCAG 2.1, ze kterých vychází požadavky na bezbariérovost.
7	Webové stránky musí být optimalizovány pro webové vyhledávače, dle standardu SEO.
8	Web bude optimalizován pro podporované webové prohlížeče: Chrome, Firefox, Safari, Edge, Opera. V rámci podpory i pro jejich budoucí verze.
9	Zabezpečení webových stránek a také bezpečnost přístupu k obsahu bude zajištěna na základě HTTPS protokolu a důvěryhodného certifikátu.
10	Funkce ochrany proti spamu, kontrolující a blokující spam ve webových formulářích takovým způsobem, který nevyžaduje akce na straně uživatele (captcha, otázky).
11	Pro správnou sémantizaci textů je požadována funkčnost nabytí lexikálního významu a jazykové reality.
Redakční systém
1	Je požadováno hierarchické rozdělení informací na webu do kategorií s možností tuto strukturu dále rozšiřovat a jinak upravovat.
2	Je požadována jazyková lokalizace uživatelského rozhraní pro uživatele redakčního systému (backendu).
3	Ze struktury webu se musí automaticky vytvářet navigační prvky – menu, drobečková navigace, mapa stránek. Jednotlivé kategorie struktury webu zobrazují automatické výpisy v nich zařazeného obsahu.
4	Je požadována možnost vytvářet role jako skupiny oprávnění nad spravovaným obsahem. Tato oprávnění musí umožnit vytvářet, upravovat nebo publikovat obsah, a to jak podle typu obsahu (viz níže), tak podle jeho zařazení v informační architektuře webu – struktuře webu.
5	Editoři obsahu budou obsah editovat přímo v prostředí webového prohlížeče, a to pomocí nástroje, který nebude vyžadovat znalost HTML a který bude editovaný obsah zobrazovat přibližně tak, jak se následně zobrazí návštěvníkům dané stránky (WYSIWYG). Pro pokročilé uživatele nicméně bude zachována i možnost editovat přímo HTML kód. Kromě běžných funkcí bude umožněno vkládání medií a iframů a dále funkce pro odmazání formátování.
6	Je požadována možnost rozdělení obsahu na několik typů: statická stránka s časově neomezenou platností, např. povinně zveřejňované informace; novinky – kratší zprávy vztahující se k nějaké události většinou časově omezené v tom smyslu, že po nějaké době ztrácejí aktuálnost, např. tiskové zprávy; možnost označit novinku pro zveřejnění na titulní stránce; možnost nastavit datum zveřejnění; akce – informace o připravovaných / probíhajících akcích ve městě s jasně definovaným termínem od do a typem akce např. divadelní představení, výstavy; zobrazení všech akcí v kalendáři na webu, ve kterém může návštěvník vyhledávat podle data, ale i dalších kritérií, např. organizátor, místo konání; možnost zadávat akce i jako opakované, např. každou středu – dlouhodobé akce; možnost zadání nepublikované akce třetí stranou bez nutnosti registrace, např. prostřednictvím webového formuláře. V systému přístupových práv speciální role s omezeným právem pouze na administraci akcí.
7	Novinky a akce bude možné sdílet na sociální sítě. Z novinek bude možné generovat výpisy ve formátu RSS.
8	Fulltextové vyhledávání bude indexovat obsah webových stránek a zároveň bude rozšířeno o funkci našeptávání z obsahu webových stránek.
9	Je požadována funkce rozšířeného vyhledávání podle kritérií, jako je např. zařazení ve struktuře webu, štítků. U vyhledávacích polí se budou nabízet možné hledané termíny pomocí našeptávače.
10	Výpisy obsahu bude možné exportovat, například podle kategorií struktury, ve strojově čitelném formátu (např. csv, xml). Veškerý obsah webových stránek bude možné exportovat jako balík v rámci jedné akce.
11	Je požadována možnost jazykové mutace - využití modulu Google překladače pro snadné udržování obsahu webových stránek města v cizím jazyce.
12	Je požadována možnost označit obsah štítky mimo jeho třídění podle typu nebo zařazení do struktury webu, podle nichž se pak návštěvníkům nabídne související / příbuzný obsah.
13	Je požadována možnost vložit do jednotlivých stránek s automatickými výpisy a statických stránek widgety pro zobrazení banneru/obrázku, galerie, dále výpis novinek, akcí nebo odkazů, vložení bloku s editovatelným textem (WYSIWYG).
14	K obsahu bude možné přiložit / nahrát soubory nebo obrázky, které se automaticky zařadí do knihovny již použitých médií, z níž je možné je opakovaně použít. S možností přidat / zobrazit obrázky seskupené do galerie, ať už samostatně, nebo jako součást jiného obsahu.
15	Je požadována možnost tvorby webového formuláře, který bude sloužit ke sběru hlasů návštěvníků k editorem zadanému tématu, možnost ověřovat zaslané hlasy pomocí telefonního čísla, e-mailu, bez ověření.
16	Je požadována možnost přehledně organizovat jednotlivé kontakty do celků, odborů, komisí, výborů, zastupitelstvo, rada města atd. Vytvoření organizační struktury.
17	Je požadována možnost navázání webu na systém Google analytics pro sběr statistických dat o návštěvnosti webu.
18	Je požadována možnost vytvoření jednoduchého textového formuláře s ukládáním odpovědi to databáze. Možnost sbírat informace i od nepřihlášených návštěvníků s možností notifikací pomocí e-mailu. Jak tomu, kdo formulář vyplnil a odeslal, v případě že uvedl svou e-mailovou adresu, tak vybraným uživatelům/editorům, kteří s informacemi sesbíranými pomocí formuláře dále pracují.
Mobilní aplikace webu
1	Technické parametry: Systém provozován v cloudu, responzivní design. Mobilní aplikace musí obsahovat: profil obce;  informační nástěnku;  hlášení závad a podnětů.  Technický popis funkcionalit: webové zobrazení mobilního rozhlasu musí být zobrazitelné na standardizovaných prohlížečích Chrome, Microsoft Edge, Firefox, Safari, Opera nastavení času odeslání; nastavení cílení (skupiny, ulice); možnost tvorby grafických zpráv (vkládaní obrázků přímo do tela e-mailů, zprávy do aplikace); propojení různých zdrojů informací přes RSS; propojení s Facebookovou stránkou samosprávy; statistiky odeslání, doručení, otevření zaslaných zpráv; možnost dodatečného posílání sms; Sběr osobních údajů občanů v minimální míře, případně dle požadavků zadavatele; zadavatel může v aplikaci zvolit množinu údajů o občanech, které budou uchovávány; soulad s GDPR; možnost konverze dokumentů do listovatelné podoby s interaktivními prvky; konvertované dokumenty budou obsahovat možnost registrace se k odběru informací; možnost samostatné práce pro více odborů úřadu; možnost samostatného rozesílání zpráv pro všechny autorizované pracovníky úřadu. možnost různého nastavení UI pro skupiny uživatelů bez technických znalostí nebo pro seniory; možnost informování občanů o probíhajících blokových čištěních ve městě, a to v grafické formě na základě mapových podkladů; minimalizace počtu subjektů/subdodavatelů služby, které přichází do styku s osobními údaji; možnost množinu subjektů pro styk s osobními údaji nastavovat; pro zasílání informací z městského úřadu občanům musí mít odpovědní pracovníci specifický uživatelský přístup; možnost zadavateli určit dobrovolnost či povinnost uvedení osobních údajů občanů a jejich rozsahu; možnost přidávání a editace uživatelů systému a nastavení různých oprávnění k administraci služeb; možnost vytvoření mikro-webové stránky subjektů typu školy, spolky a instituce a oddělené přístupy do modulů jednotlivých subjektů.
2	Typy zpráv: zprávy pro předávání do aplikace; sms zprávy - textový identifikátor pro odesílání sms bude identifikovat pořadí, délku zprávy tak, aby se vešla do 3 sms (160 zn., systém ukáže počet zbývajících znaků, aplikace bude obsahovat možnost omezení počtu odeslaných sms s cílem minimalizovat náklady; e-mailové zprávy; hlasové zprávy (u hlasových zpráv bude možnost zpětné vazby s vyhodnocením reakcí občanů).
3	Kontakty (přístupné v offline režimu, tzn. když uživatel nemá přístup k internetu): kontakty na samosprávu; pohotovostní kontakty; kontakty na instituce.
4	Zpětná vazba: Je požadována funkčnost pro přijímání podnětů od občanů, interní vkládání podnětů pro interní okruh uživatelů (např. úředníků, městské policie aj.), tvorba vlastních názvů podnětů. Podnět bude mít možnost obsahovat minimálně: fotografie; GPS; Popis; Kategorii. Je požadována možnost přidělování vybraných kategorií podnětů konkrétním příjemcům. Je požadována podpora definice stavů řešení. Je požadována ochrana proti spamu. Je požadována možnost zadávání podnětů přes mobilní aplikaci a webové stránky.
5	Ankety: Je požadována funkčnost pro tvorbu a publikování anket. Nástroj pro tvorbu anket/dotazníků pro zjišťování názoru občanů, podpora různých typů dotazu (jedna odpověď, více odpovědí, otevřená otázka, hlasování s plusovými i mínusovými body, kvalitativní škála). Je požadována možnost vytváření grafických anket (možnost vkládání obrázku ke každé otázce), možnost zaslání ankety jednotlivými komunikačními kanály. Nastavení časové platnosti ankety, sběr dat z anket, ověření unikátnosti hlasu přes SMS, e-mailem či bez ověření. Možnost registrace k odběru informací přímo z ankety, přehledné statistiky výsledků a export výsledků.
6	Pro vyškolení obsluhy webových stránek bude poskytnuto školení pro 5 pracovníků v délce trvání 1 den.

Popis požadovaných integračních vazeb statických stránek webu je uveden v následující tabulce.

ID	Popis požadavku	Popis řešení	Splněno
1	Ginis úřední deska	vložený rám do grafiky - xxxxxxxxxxx.xxxxxxx.xx/xx
2	Ginis evidence smluv	vložený rám do grafiky - xxxxxxx.xxxxxxx.xx/xxx
3	Ginis rozpočet	vložený rám do grafiky - xxxxxxxx.xxxxxxx.xx/xx
4	Mapové služby GIS	vložený rám do grafiky - xxx.xxxxxxx.xx/xxx
5	Xxxxxxx xxxxxxx	vložený rám do grafiky - xxxx.xxxxxxx.xx

3. Realizační část b) - Portál elektronických služeb s platební branou

Realizačních část Portál elektronických služeb s platební branou bude sloužit ke správě a úhradě poplatků z poplatkových vyhlášek. Na platební portál bude možné navázat další služby. Součástí řešení bude systém plateb za pokuty a platby za parkování. Všechny platební agendy se obejdou bez formulářů, protože portál umožní správu poplatkových dat přímo uživateli.

Pro přístup ke zvoleným funkcím bude uživatel mít možnost zvolit způsob ověření prostřednictvím elektronické občanky, bankovní identity, MojeID, ISDS nebo Mobilní klíč eGovernmentu.

Uvedené požadované vlastnosti řešení pro Portál elektronických služeb s platební branou jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky obecné pro Portál elektronických služeb s platební branou	Splněno
Základní požadavky
1	Je požadována lokalizace v českém jazyce, řešení musí umožnit i další jazykové mutace.
2	Služba portálu musí být rozdělena na veřejně dostupnou část a interní část označovanou také jako portálový backoffice.
3	Služba portálu musí být plně kompatibilní s aktuálními verzemi webových prohlížečů (minimálně: Chrome, Firefox, Edge a Safari, Opera).
4	Dostupnost veřejné části portálu občana musí být v režimu 24x7.
5	Portál musí splňovat pravidla přístupného webu dle normy EN 301 549 V2 1.2 standardu WCAG 2.1.
6	Celé řešení musí splňovat pravidla pro ochranu osobních údajů (GDPR) dle aktuálně platné legislativy.
7	Portál musí splňovat pravidla pro uchovávání cookies dle normy opt-in, tzn. před jakýmkoliv shromažďováním cookies je nutný vyslovený a informovaný souhlas uživatele.
8	Pro provoz portálu nesmí být vyžadována dostupnost portálového backoffice s výjimkou první registrace.
Bezpečnostní požadavky
1	Portál poběží na zabezpečené URL.
2	Komunikace veřejné části a interní části musí probíhat zabezpečeně, pomocí komunikační mezivrstvy.
3	Předávání dat z interní části do portálu musí probíhat periodicky pomocí dávek v definovatelných intervalech.
4	Přenos dat musí být šifrován a musí být anonymní pro znemožnění sestavení dat v případě odchycení.
5	On-line načtení dat musí probíhat v případě prvního přihlášení.
6	Pro provoz portálu nesmí být vyžadován žádný prostup do vnitřní sítě úřadu (pro potřeby komunikace s portálovým backoffice).
7	Veškerá osobní data k subjektu musí být uchovávána v portálovém backoffice, v portálu mohou být pouze údaje nutné pro přihlášení.
Technické požadavky
1	Portál musí být instalován v DMZ a portálový backoffice musí být instalován ve vnitřní síti úřadu.
2	Portál musí umožňovat implementaci využitím kontejnerových technologií (docker, kubernetes).
Požadavky na design
1	Portál musí být v rámci svého UI využívat design systém xxx.xx.
2	Portál musí být plně responsivní a všechny funkčnosti musí být plně použitelné i v mobilních zařízení.
3	Portál musí umožnit do svého vzhledu zaintegrovat logotyp, barevnost a obrázek města. Zároveň musí být uživatelsky možné v rámci portálového backoffice tyto položky upravovat.
4	Design celého řešení (interní i vnější části) musí být jednoduchý a přehledný, dle základní definice plochého vzhledu (tzv. flat design).
Registrace a autentizace
1	Registrace a přihlašování musí být možné pomocí služeb NIA a ISDS a musí vyžadovat souhlasy se zpracováním osobním údajů dle GDPR.
2	Znění souhlasu se zpracováním osobních údajů dle GPDR musí být editovatelné v rámci portálového backoffice a dostupné v rámci profilu občana na jednoznačné URL, která musí být i veřejné dostupná bez potřeby přihlášení.
3	Registrace musí být možná i off-line na přepážce úřadu pomocí průvodce v portálovém backoffice.
4	Na přepážce musí být možné vyřešit také přiřazení FO, FOP nebo PO. To samé musí být možné i po přihlášení v profilu občana.
Konto občana
1	Po přihlášení bude mít občan k dispozici správu svého profilu, ve které mu bude umožněno měnit kontaktní údaje (telefon, e-mail).
2	V rámci profilu musí být možné celý portálový účet i s uchovanými daty kompletně smazat (dle platné legislativy a GDPR).
3	Uživatel musí mít v rámci svého profilu náhled informací o svém přihlášení a nastavení k zastupování za FO, FOP, PO nebo své dítě.
4	Nastavení zastupování PO musí být možné pomocí žádosti v profilu občana.
5	Nastavení zastupování FOP musí být možné pomocí žádosti v profilu občana.
6	Nastavení zastupování FO musí být možné pomocí průvodce v profilu občana a pomocí zabezpečeného procesu ověření u zastupované osoby.
7	Nastavení zastupování za své dítě musí být možné v profilu občana. Po dovršení plnoletosti musí být tato vazba automaticky zrušena.
8	V rámci profilu občana bude možné nastavit (zapnout/vypnout) jednotlivé typy notifikací (e-mail, SMS).
Procesní požadavky
1	Portál musí obsahovat hlavičku, hlavní nabídku, obsahovou část, patičku a pozadí s editovatelnou fotografií.
2	Při pohybu v portálu musí být ve všech podkategoriích zobrazována drobečková navigace.
3	Hlavní nabídku musí být možné kompletně konfigurovat v portálovém backoffice, u každé položky bude možné měnit i ikonu.
4	Nepřihlášenému uživateli musí být při první návštěvě zobrazena úvodní stránka s rozcestníkem, výzvou k přihlášení, odkazem na nápovědu a cookies.
5	Nepřihlášenému uživateli musí být zobrazeny všechny veřejné informace, které jsou zveřejněny v jednotlivých částech portálu (sekce: životní situace, formuláře, a jakékoliv textové stránky editovatelné v portálovém backoffice a zveřejněné v portálu občana).
6	Na hlavní stránce musí být možné pro nepřihlášeného i přihlášeného uživatele nastavit bannery s odkazem do jednotlivých částí portálu nebo i na jiné URL stránky - například úřední deska, kontakty, apod.
7	Přihlášenému uživateli musí být zobrazeno na úvodní stránce saldo jeho závazků v přehledném dashboardu.
8	Obsahové stránky portálu musí být viditelné a indexovatelné pro vyhledávače (google, seznam) a musí splňovat základní požadavky na SEO (sémanticky psaný kód, meta klíčová slova a meta popisky). Editace klíčových slov a popisků musí být umožněna z portálového backoffice.
Jak si vyřídit
1	Sekce „Jako si vyřídit“ musí být vytvořena jako uživatelsky editovatelná, zobrazující textové stránky ve stromové struktuře (editovatelné z portálového backoffice).
2	Řešení musí obsahovat návrh základního setu životních situací, jejich textů a grafiky. Životní situace musí být jednoduché a stručné spojené s infografikou.
3	Stromová struktura musí umožnit editovat ikonu, název a doplňkový popisek dané kategorie.
4	Textová stránka musí umožnit editovat za pomoci wysiwyg editoru obsah a strukturovat ho dle nadpisů, odstavců nebo odrážek a také přímo v obsahu vkládat obrázky, odkazy i tabulky.
5	K textové stránce musí být možné přiřadit dále klíčová slova, popisek, ikonu, formulář, přílohu a zařadit jí do struktury životních situací ve vazbě 1-n.
6	V rámci celé části životní situací musí být možné využití fulltextového vyhledávání.
Elektronické platby
1	Řešení musí zobrazovat přihlášenému občanovi jeho závazky v přehledném dashboardu.
2	Data musí být strukturovaně zobrazena pro přihlášeného občana i jeho zástupy dle jednotlivých typů závazků.
3	Každý typ závazku musí být možné rozkliknout a zobrazit jeho detail, který obsahuje saldo, přehled předpisů a provedených plateb.
4	V rámci detailu závazku musí být možné: provést platbu pomocí QR kódu; zobrazit údaje k platbě; provést platbu přes platební bránu.
5	Platba kartou musí být občanovi zobrazena jako nezaúčtovaná operace, která ponižuje saldo konkrétního typu závazku a je odstraněna v případě reálného zaúčtování v ekonomickém systému.
6	Řešení musí občanovi umožnit u jednotlivých závazků exportovat si data ve formátu xls nebo csv.
7	U jednotlivých závazků musí být vidět datum a čas poslední aktualizace zobrazených dat.
Statistiky
1	V rámci portálu musí být implementován analytický nástroj Google Analytics pomocí Google Tag Manager.
2	Další statistiky o využívání portálu musí být v přehledném dashboardu po přihlášení do portálového backoffice.
3	Statistiky v portálovém backoffice musí obsahovat: počet registrovaných subjektů (NIA, ISDS, přepážka), počet přihlášení, počet přihlášených uživatelů, počet podání, počet uskutečněných plateb, výše uskutečněných plateb.
Formuláře
1	Součástí portálu občana je modul Elektronické formuláře
2	Obsahem modulu je 10 elektronických formulářů, které budou upřesněny v části analýzy a přípravy projektu. Tyto formuláře budou navázány na životní situace.
3	Součástí modulu je evidence uskutečněných podání.
4	Vyplněný a odesílaný formulář na portál občana musí být možné autorizovat prostřednictvím: vložení elektronického podpisu podatelem do vyplněného souboru formuláře ve formátu PDF/A-3, autorizace digitálního úkonu NIA (občan nemusí disponovat elektronickým podpisem, pro autorizaci podaného dokumentu použije komponentu NIA).
5	Součástí modulu je možnost autorizace digitálního úkonu prostřednictvím NIA. V případě autorizace digitálního úkonu NIA musí výsledný soubor formuláře ve formátu PDF/A-3 obsahovat i informaci o identifikaci žadatele a provedené autorizaci digitálního úkonu pomocí NIA. Odeslaný formulář bude doručen na emailovou adresu podatelny.
6	Formuláře umožňují nastavení, zda je nutné se k jejich odeslání registrovat/přihlásit nebo je možné jej poslat bez přihlášení.
7	Formulář musí být plně responzivní.
8	Výstupem z procesu elektronického podání je dokument ve formátu PDF/A3 a XML soubor s daty. Odeslaný soubor je uložený v Portálu občana a občan si jej může kdykoli stáhnout.

Popis požadovaných integračních vazeb je uveden v následující tabulce.

ID	Požadavek	Popis	Splněno
1	Agendový IS místní poplatky	Viz popis v kap. 5.4
2	Integrace na IS Podpora rozhodovacích procesů	Viz popis v kap. 5.5
3	ISZR prostřednictvím XZR PROXIO MARBES race na ISZR	Ověřování prostřednictvím ISZR
4	Integrace na NIA	Napojení na Národní identitní bod pro registraci a přihlašování uživatelů
5	Integrace na Přestupky	Viz popis v kap. 5.6

4. Realizační část c) - Místní poplatky

Realizačních část Místní poplatky bude obsahovat přehledným webovým rozhraní. Řešení bude pro uživatele přizpůsobené pro spuštění i na mobilních zařízeních a bude obsahovat kontrolní přehledy dat. Správci poplatků budou mít k dispozici předdefinované pohledy na důležitá data.

Uvedené požadované vlastnosti řešení pro místní poplatky jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkční vlastnosti řešení pro místní poplatky	Splněno
Obecné požadavky
1	Je požadována možnost evidovat místní poplatek minimálně za komunální odpad, místní poplatek ze psů, místní poplatek za užívání veřejného prostranství, místní poplatek z pobytu a místní poplatek ze vstupného.
2	Je požadována možnost zřídit jednotlivým uživatelům přístup k jednotlivým místním poplatkům.
3	Je požadována možnost zřídit přístup do nastavení aplikace vybraným uživatelům, typicky vedoucím ekonomického odboru.
4	Řešení musí disponovat pravidelnou aktualizací. Po aktualizaci musí nabídnout možnost zobrazení informací o změnách v nové verzi aplikace.
5	Řešení musí hlídat unikátnost údajů poplatníků.
6	Řešení musí umožnit pohled na finanční data v rámci jednotlivých roků s možností přepínání jednotlivých roků dle požadavku.
7	Řešen musí nabídnout nástroj na vyhledání poplatků určených k archivaci (poplatky bez aktivních dat, vyrovnaný finanční stav) a nástroj na jejich archivaci, tedy trvalé odstranění všech evidovaných osobních údajů dle platné legislativy.
8	Řešen musí umožnit nastavit datum automatického předepsání poplatků, automatického upomínání neuhrazených pohledávek, automatického vyměření poplatků, automatického vyrozumění o neuhrazených exekučních titulech a automatického předávání neuhrazených exekučních titulech do vymáhání, a to jednotlivě pro všechny typy místních poplatků.
9	Řešen musí nabídnout ergonomické a intuitivní ovládání - tzn. uživateli postačí znát legislativní procesy k základnímu ovládání aplikace bez nutnosti specializovaného školení.
Bezpečnostní požadavky
1	Veřejná část aplikace bude provozována odděleně od interních aplikací určených pro práci úředníka.
2	Veřejná část aplikace nebude vyžadovat přímý prostup do interních aplikací.
3	Veřejná část aplikace musí být odolná vůči DDOS útokům.
4	Pokud bude veřejná část aplikace trvale ukládat vlastní data, musí být data uložena v takové podobě, aby nebylo možné v případě jejich zcizení ztotožnit jednotlivé poplatky, předpisy nebo změnové požadavky s konkrétním občanem.
5	Běhové prostředí aplikací a všechny komponenty aplikace musí být dodány ve verzích, které jsou podporované a jsou pro ně vydávány bezpečnostní aktualizace.
6	Dodavatel musí být schopen aplikace a jejich běhové prostředí na vyžádání aktualizovat na podporované verze a musí být schopen instalovat bezpečnostní aktualizace.
Technické požadavky
1	Veřejná část aplikace musí být provozovatelná v kontejnerové technologii typu Docker/Kubernetes.
2	Práce občana ve veřejné části aplikace nesmí způsobit výrazné zatížení interních aplikací určených pro práci úředníka.
3	Veřejná část aplikace musí být funkční i v případě odstávky či nedostupnosti interní aplikace pro úředníky. Funkční musí být minimálně přihlášení občana, zobrazení dat o poplatcích a platba kartou.
4	Veškerá data musí být bezpečně uložena v databázi/souborovém úložišti interních aplikací.
5	Veřejná část aplikace může kromě vlastní konfigurace trvale ukládat pouze data, která se dají v případě ztráty obnovit z dat interní aplikace.
6	Aplikace musí umožnit snadnou migraci na jiný server.
7	Aplikace musí obsahovat endpoint určený pro uptime monitoring.
Požadavky na design
1	Veřejná část aplikace musí být přizpůsobitelná a konfigurovatelná z hlediska designu tak, aby odpovídala portálu občana, jehož je součástí.
Vyhledávání
1	Aplikace při vyhledávání dat musí disponovat inteligentním našeptáváním hledaných dat na základě identifikačních údajů poplatku (příjmení, jméno, datum narození, název právnické osoby, ičo, adresa, variabilní symbol).
2	Aplikace musí disponovat rychlým vyhledáváním dat i v případě, že v aplikaci bude evidována kompletní historie poplatků se všemi údajů (statisíce poplatků).
Kontrolní mechanismy
1	Aplikace musí nabídnout možnost zobrazení dat jednotlivých místních poplatků v datových přehledech Microsoft Power BI za účelem nadstavbových analytických činností.
2	Aplikace musí umožnit prezentaci dat z agendových systémů jednoduchým, přehledným a moderním způsobem.
3	Aplikace musí umožnit prezentovat anonymizovaná a agregovaná data občanům, úředním osobám i managementu úřadu.
4	Aplikace musí umožnit prezentování dat z DB typu MS SQL i Oracle.
5	Aplikace musí umožnit možnost napojení prezentace dat na jakýkoliv systém, který má uložená data v DB.
6	Aplikace musí umožnit prezentaci dat v barvách obce.
7	Aplikace musí nabídnout prezentaci dat o obyvatelích obce.
8	Aplikace musí nabídnout prezentaci dat o pohledávkách úřadu.
9	Aplikace musí nabídnout prezentaci dat o smlouvách obce.
10	Aplikace musí nabídnout prezentaci dat o přestupcích.
11	Aplikace musí nabídnout prezentaci dat o majetku obce.
12	Aplikace musí nabídnout prezentaci dat za účelem kontroly místních poplatků.
13	Aplikace musí nabídnout prezentaci dat za účelem kontroly majetku obce.
14	Aplikace musí nabídnout prezentaci dat za účelem benchmarkingu vybraných oblastí.
Reportování
1	Aplikace musí umožnit zobrazování sumarizačních údajů jednotlivých místních poplatků v jednoduchém formátu infografiky za účelem rychlého zjištění aktuálních informací o jednotlivých místních poplatcích.
Péče o kvalitu dat
1	Aplikace musí provádět automatickou datovou profylaxi dat u jednotlivých místních poplatků za účelem identifikace dat pro další zpracování a za účelem nápravy dat. Typicky se jedná o profylaxe: - změny ze Základních registrů; - duplicitní poplatníci; - nepřevedené dluhy nezletilců k zákonným zástupcům; - senioři s chybnou sazbou; - nepodaná hlášení k provozovnám; - adresáti bez doručení; - poplatníci v insolvenci; - poplatky, kterým hrozí prekluze; - poplatky, které se mohou archivovat; - neztotožněné subjekty oproti Základním registrům.
Pracovní přizpůsobení
1	Je požadována možnost rychlých odskoků do potřebné legislativy týkající se jednotlivého místního poplatku (zákon o místních poplatcích, daňový řád, správní řád, vyhláška).
2	Je požadována možností evidence vlastních poznámek za účelem dalšího zpracování dat na poplatku.
3	Je požadována možnost evidovat vlastní seznam poplatků uživatele, které má ve zpracování a na kterých bude následně pracovat.
Poplatek za odpad
1	Aplikace musí umožnit zaevidovat přihlášení poplatníka na základě narození poplatníka.
2	Aplikace musí umožnit zaevidovat přihlášení poplatníka na základě přistěhování poplatníka.
3	Aplikace musí umožnit zaevidovat přihlášení poplatníka na základě nabytí nemovitosti, ve které není nikdo přihlášen k trvalému pobytu
4	Aplikace musí umožnit zaevidovat odhlášení poplatníka na základě úmrtí poplatníka.
5	Aplikace musí umožnit zaevidovat odhlášení poplatníka na základě odstěhování poplatníka.
6	Aplikace musí umožnit zaevidovat odhlášení poplatníka na základě pozbytí nemovitosti, ve které není nikdo přihlášen k trvalému pobytu.
	Aplikace musí umožnit zaevidovat osvobození poplatníka (všech zákonných typů).
8	Aplikace musí umožnit upravit údaje o osvobození s následným přepočtem výše poplatku.
9	Aplikace musí umožnit zaevidovat úlevu z poplatku všech typů (cizina, armáda, studium, věk).
10	Aplikace musí umožnit upravit údaje úlevy z poplatku všech typů.
11	Aplikace musí umožnit pravidelné načítání dat změn ze Základních registrů (přistěhování, odstěhování, narození, úmrtí) a tyto změny kompletně zpracovává (automatizovaně zpracuje data, zaeviduje, doplní případná osvobození a úlevy a dle všech údajů vypočte správnou výši místního poplatku).
12	Aplikace musí umožnit pravidelné načítání dat z katastru nemovitostí a vyhodnotit podezřelé adresy. Podezřelé adresy jsou takové, které nesplňují alespoň 60% průměrné obsazenosti bytů a rodinných domů v dané obci. Aplikace dále musí umožnit v případě podezřelé adresy zobrazit údaje vlastníka nemovitosti za účelem kontaktování a případného vyměření místního poplatku
13	Aplikace musí automatizovaně vytvářet / ukončovat úlevy dle věku poplatníka (bude-li aktuálně požadováno), např. 50% úleva do 3 let věku poplatníka či nad 70 let poplatníka.
14	Aplikace musí automatizovaně kontrolovat, zdali není jeden poplatník přihlášen na základě trvalého bydliště a zároveň na základě vlastnictví nemovitosti.
15	Aplikace musí automatizovaně kontrolovat, zda nezletilí poplatníci nemají dluh, aplikace příp. musí automatizovaně převést dluh k zákonnému zástupci v den splatnosti předpisu pohledávky.
Evidence dat k místnímu poplatku za odpad
1	Aplikace musí umožnit evidovat všechna místa svozu komunálního odpadu.
2	Aplikace musí umožnit evidovat jednotlivé typy nádob komunálního odpadu.
3	Aplikace musí umožnit evidovat počty nádob komunálního odpadu.
4	Aplikace musí umožnit četnost svozu nádob komunálního odpadu.
5	Aplikace musí umožnit evidovat osvobození a úlevy z poplatku za komunální odpad.
6	Aplikace musí umožnit evidenci tzv. přísypů.
7	Aplikace musí umožnit evidenci nahlášení o nepovoleném přísypu.
Místní poplatek - pes
1	Aplikace musí umožnit přihlásit jednoho či více psů. Aplikace automaticky vypočítává výši místního poplatku odpovídající všem zadaným hodnotám (očipování, sleva za útulek, sleva za čip, osvobození poplatníka, úlevy poplatníka).
2	Aplikace musí umožnit úpravu evidenčních údajů psa.
3	Aplikace musí umožnit zaevidování všech zákonných typů osvobození a úlev psa.
4	Aplikace musí umožnit zobrazení historii platností všech sazeb na poplatku.
5	Aplikace musí umožnit evidenci očipování psa.
6	Aplikace musí umožnit odhlášení jednoho či více psů s automatickým přepočtem výše místního poplatku.
7	Aplikace musí umožnit automatický výpočet místního poplatku pro všechny evidované poplatníky s možností nastavení dne, kdy se poplatky mají vytvořit.
8	Aplikace bude připravena na možnost ověření očipovaného psa v připravovaném celonárodním registru psů.
9	Aplikace musí disponovat nástrojem na automatickou změnu sazby místního poplatku na základě dovršení zadané věkové hranice.
10	Aplikace musí disponovat nástrojem na kontrolu přihlášených poplatníků k místnímu poplatku s aktuální adresou trvalého bydliště / sídla společnosti mimo danou obec.
11	Aplikace musí disponovat nástrojem na vyhledávání údajů o psu a o majiteli psa městskou policií. Městská policie uvidí pouze údaje o psu (za účelem identifikace psa), údaje o majiteli psa (za účelem kontaktování majitele psa) a informaci o tom, zda majitel psa má či nemá kompletně uhrazený místní poplatek (bez detailních informací).
Místní poplatek - Vstupné
1	Aplikace musí umožnit zaevidování kulturní, sportovní, prodejní či reklamní akce za účelem vyměření místního poplatku. Aplikace dle platného sazebníku musí automaticky vypočítat výši místního poplatku.
Platby za zábor veřejného prostranství
1	Aplikace musí umožnit zaevidování užívání veřejného prostranství s možností výběru dané sazby, s možností výběru dnů, ve kterých bude veřejné prostranství užíváno a musí automaticky vypočítat výši místního poplatku.
2	Aplikace musí umožnit jednoduché prodloužení / opakování užívání veřejného prostranství, např. vyhrazené parkovací stání.
3	Aplikace musí umožnit zaevidování užívání veřejného prostranství z externího systému, např. z IS na evidenci zvláštního užívání komunikace.
Pobytové poplatky
1	Aplikace musí umožnit evidenci nové provozovny, úpravu jejích údajů a případné ukončení takové provozovny.
2	Aplikace musí umožnit zaevidování hlášení k dané provozovně a na základě zadaných údajů automatický výpočet místního poplatku dle platného sazebníku.
3	Aplikace musí umožnit zobrazení všech historických hlášení k dané provozovně
4	Aplikace musí automaticky provést kontrolu provozovny, u které chybí podané hlášení za účelem kontaktování dané provozovny a vyměření místního poplatku.
Evidence a správa
1	Aplikace musí umožnit evidenci poplatníka typu fyzická osoba, fyzická osoba podnikající či právnická osoba.
2	Aplikace musí komunikovat se Základními registry za účelem aktualizace údajů poplatníků
3	Aplikace musí evidovat veškerý přístup k údajům Základných registrů s možností dohledávání údajů.
4	Aplikace musí umožnit evidenci všech typů dokladů poplatníka.
5	Aplikace musí umožnit evidenci všech typů kontaktů poplatníka (datová schránka, email, telefon, doručovací adresa).
6	Aplikace musí umožnit evidenci zákonných zástupců nezletilých poplatníků s automatickým odstraněním zákonných zástupců v den zplnoletnění nezletilce.
7	Aplikace musí umožnit označení poplatníka jako neplatiče (subjekt, který většinově své místní poplatky neplatí). Aplikace musí automaticky vyhodnocovat bonitu poplatníka a případně označit poplatníky jako neplatiče. Xxxx neplatiči musí být následně vyloučeni z hromadných akcí typu vyměření poplatku a nebude jim zasílán dokument platebního výměru (vyměřují se hromadným předpisným seznamem).
8	Aplikace musí umožnit výpis všech poplatníků typu fyzická osoba ve formátu Příjmení, Jméno za účelem správného řazení.
9	Aplikace musí disponovat kontrolou ztotožnění poplatníků a vybízí uživatele, aby neztotožněné poplatníky ztotožnil oproti Základním registrům.
10	Aplikace musí disponovat kontrolou ztotožnění adres poplatníků a musí vybídnout uživatele, aby neztotožněné adresy poplatníků ztotožnil oproti Základním registrům.
11	Aplikace musí disponovat kontrolou zákonných zástupců nezletilých poplatníků a musí vybídnout uživatele k doplnění zákonného zástupce k nezletilci.
Kompletní správa místních poplatků
1	Aplikace musí umožnit jednotlivé i hromadné upomenutí neuhrazených pohledávek.
2	Aplikace musí umožnit jednotlivé i hromadné vyměření neuhrazených pohledávek, a to jak platebním výměrem, tak i hromadným předpisným seznamem. Při tvorbě hromadného předpisného seznamu musí aplikace zohlednit poplatníky na úřední adrese, cizince, neplatiče.
3	Aplikace musí umožnit jednotlivé i hromadné vyrozumění neuhrazených exekučních titulů.
4	Aplikace musí umožnit jednotlivé i hromadné předání neuhrazených exekučních titulů do vymáhání.
5	Aplikace musí disponovat automatickým hlídáním lhůt placení daně. Aplikace musí s předstihem vybídnout uživatele k vymáhacím krokům, aby nedošlo k prekluzi předpisů pohledávek.
6	Aplikace musí umožnit zaslání žádosti o vrácení přeplatku na email konkrétního uživatele (typicky uživatel účtárny).
7	Aplikace u vybraných místních poplatků musí umožnit nastavení rozdělení poplatkové povinnosti na 2 či 4 části (typicky pro psy a odpady).
8	Aplikace musí plnohodnotně podporovat režim splátkování (evidence žádostí o splátky, zpětvzetí žádostí o splátky, rozhodnutí o povolení žádosti o splátky, rozhodnutí o zamítnutí žádosti o splátky, kontrola splácení, zrušení rozhodnutí o povolení splátek, posečkání splácení).
Práce s dokumenty
1	Aplikace musí podporovat tvorbu dokumentu Přihlášení k místnímu poplatku, Upomenutí neuhrazené pohledávky, Platební výměr, Hromadný předpisný seznam, Vyrozumění o neuhrazeném exekučním titulu.
2	Aplikace musí disponovat možností automatické tvorby dokumentu Přihlášení k místnímu poplatku.
3	Aplikace musí umožnit v případě tzv. nepovinných dokumentů (Upomínka, Vyrozumění) odeslání SMS a emailu poplatníkovi.
4	Aplikace bude propojena se spisovou službou a musí umožnit automatické vypravení dokumentu dle platné legislativy.
5	Aplikace bude se spisovou službou komunikovat standardem NSESSS dle platné legislativy.
6	Aplikace musí umožnit tvorbu a ukládání pouze validních souborů formátu PDF a PDF/A.
7	Aplikace musí umožnit podepisování dokumentů samotným uživatelem i možností předání k podpisu (typicky jeho nadřízeným).
8	Aplikace musí automaticky notifikovat uživatele, na jehož podpis se čeká při tvorbě dokumentů.
Napojení na informační systém Insolvenční rejstřík
1	Aplikace musí umožnit aktualizaci dat z Insolvenčního rejstříku a musí nabídnout tak aktuální údaje o tom, zdali je daný poplatník součástí nějakého insolvenčního spisu či nikoliv.
Integrace s Portálem občana
1	Na portálu obce musí být uživateli zobrazen seznam jeho místních poplatků.
2	Na portálu obce musí být uživateli pro každý místní poplatek zobrazena data o financích (předpisy pohledávek, platby), data o proběhlé komunikaci (odeslané emaily, SMS, dokumenty) a agendová data (údaje z jednotlivých místních poplatků - psi, provozovny, hlášení, užívání veřejného prostranství, data k odpadům, akce ze vstupného).
3	Psi - na portálu obce musí být uživateli umožněno online přihlásit psa.
4	Psi - na portálu obce musí být uživateli umožněno online odhlásit psa.
5	Psi - na portálu obce musí být uživateli umožněno online zaevidovat očipování psa.
6	Psi - na portálu obce musí být uživateli umožněno online upravit údaje psa.
7	Psi - na portálu obce musí být uživateli umožněno online upravit sazbu (přidat osvobození či úlevu).
8	Veřejné prostranství - Na portálu obce musí být uživateli umožněno online prodloužit užívání veřejného prostranství.
9	Vstupné - na portálu obce musí být uživateli umožněno online zadat novou kulturní, sportovní, reklamní nebo prodejní akci.
10	Vstupné - na portálu obce musí být uživateli umožněno online upravit údaje kulturní, sportovní, reklamní nebo prodejní akce.
11	Pobyt - na portálu obce musí být uživateli umožněno online zadat novou provozovnu.
12	Pobyt - na portálu obce musí být uživateli umožněno online zadat nové hlášení provozovny.
13	Pobyt - na portálu obce musí být uživateli umožněno zobrazit si online seznam všech podaných hlášení.
14	Pobyt - na portálu obce musí být uživateli umožněno online upravit údaje provozovny.
15	Pobyt - na portálu obce musí být uživateli umožněno online ukončit provozovnu.
16	Odpady - na portálu obce musí být uživateli umožněno online požádat o osvobození.
17	Odpady - na portálu obce musí být uživateli umožněno online požádat o úlevu.
18	Odpady - na portálu obce musí být uživateli umožněno online požádat o svoz komunálního odpadu.
19	Odpady - na portálu obce musí být uživateli umožněno online požádat o zrušení svozu komunálního odpadu.
20	Na portálu obce musí být zobrazeny údaje k platbě místního poplatku (částka, VS, účet, QR).
21	Na portálu obce musí být uživateli umožněno uhrazení místního poplatku platební kartou.
22	Na portálu obce musí být uživateli umožněno online požádat o splácení dluhu.
23	Aplikace musí požadavek z portálu obce zpracovat okamžitě a uživatele portálu občana online informovat o výsledku (uživatel portálu obce ihned uvidí nově přihlášeného psa, novou provozovnu apod.).
24	Aplikace musí nabídnout uživateli seznam zpracovaných požadavků z portálu obce.
25	Na portálu obce musí být uživateli zobrazen seznam jeho místních poplatků.
Náročnost a obsluha
1	Aplikace musí disponovat rychlými uživatelskými odezvami i v případě evidování tisíců transakcí.
2	Aplikace musí umožnit tzv. postupné načítání dat, např. v případě vyhledání tisíců záznamů se seznamy načítají postupně dle toho, jak se uživatel pohybuje v seznamu.
Integrace
1	Aplikace musí disponovat integračním rozhraním na PROXIO XZR v oblasti vazby na Základní registry.
2	Aplikace musí disponovat integračním rozhraním pro komunikaci s ekonomickým systémem GINIS v oblasti subjektů a pohledávek.
3	Aplikace musí disponovat integračním rozhraním na spisovou službu GORDIC.
4	Aplikace musí disponovat integračním rozhraním na IS PROXIO PRX v oblasti aktualizace údajů z insolvenčního rejstříku.
5	Aplikace musí disponovat integračním rozhraním na IS PROXIO Katastr v oblasti aktualizace údajů o nemovitostech na území obce.
6	Aplikace musí umožnit export dat do Microsoft Power BI za účelem nadstavbových analytických činností.
7	Aplikace musí umožnit export dat pro svozové společnosti za účelem nastavení správného harmonogramu svozu komunálního odpadu.
8	Aplikace bude připravena na možnost ověření očipovaného psa v připravovaném celonárodním registru psů.
Správa portálu
1	Aplikace musí umožnit konfiguraci pro jednotlivé části portálu: vzhled, správu účtů, redakční systém a notifikace.
2	Přístup do portálového backoffice musí být řízen na základě přidělených práv jednotlivým úředníkům.
3	Portálový backoffice musí být schopen řešit přístup úředníků za pomoci JIP/KASS.
4	Po přihlášení musí mít úředník základní přehled statistik, které eviduje portál (výčet uveden v sekci statistiky).
5	V rámci části vzhledu musí být možné minimálně vložit logo, faviconu, zvolit barevnost (základní a sekundární barva), nahrát obrázek zobrazující se na pozadí.
6	V rámci správy účtů občanů musí být možné založit nový účet, editovat, přiřadit zastupování nebo smazat celý portálový účet.
7	V redakčním systému musí být možné upravovat: hlavní nabídku, kategorie, textové stránky.
8	Obsah z redakčního systému musí být možné exportovat a také nahrát za pomoci exportního souboru (například pro potřeby přenosu z TST prostředí na PRO prostředí).
9	V rámci notifikací musí být možné nastavit a zapnout typy notifikací (e-mail, sms), vložit prefix do předmětu a definovat podpis. Tyto hodnoty musí být automaticky přenášeny do všech typů notifikací. Dále musí být možné si z prostředí zaslat na uvedený e-mail i testovací notifikaci pro ověření funkčnosti.

Popis požadovaných integračních vazeb je uveden v následující tabulce.

ID	Požadavek	Popis	Splněno
1	Proxio XZR	vazba na základní registry
2	Ginis DDP	pohledávky
3	Proxio PRX	insolvenční rejstřík
4	IS Proxio Katastr	katastr nemovitostí
5	Microsoft Power BI	za účelem nadstavbových analytických činností.

5. Realizační část d) - Podpora rozhodovacích procesů

Realizačních část Podpora rozhodovacích procesů bude propojena s portálem elektronických služeb. Součástí řešení bude možnost parametrického nebo fultextového vyhledávání, možnost notifikace občana, pokud se v usnesení objeví zájmové uskupení slov (tím může být adresa bydliště nebo firmy, prodej městských realit, nabídky města apod.).

V příslušné sekci portálu budou k dispozici usnesení (Rady, Zastupitelstva, výborů apod.). Součástí řešení bude jak samotná agenda přípravy jednání a jeho správa, ale také finalizované dokumenty z jednání a zobrazení výsledků hlasování, vedoucích k rozhodnutí.

Řešení pokryje veškeré rozhodovací procesy v rámci městského úřadu. Součástí řešení jsou moduly pro přípravu materiálů Rady, Zastupitelstva, pracovních skupin a výborů. Dále bude řešení obsahovat funkce prezentace bodů jednání a hlasování, které bude umožněno také vzdáleně. V řešení je počítáno s možností elektronického podepisování, který zajistí autenticitu výstupních dokumentů. Na jednotlivé body jednání budou napojeny úkoly, které budou distribuovány jejich přiděleným řešitelům.

Uvedené požadované vlastnosti řešení pro podporu rozhodovacích procesů jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkční vlastnosti řešení pro podporu rozhodovacích procesů	Splněno
1	Aplikace musí umožnit základní funkční rozdělení evidence do záložek Jednání, Porady, Podklady, Usnesení a Úkoly.
2	Veřejná část pro náhled na zveřejněná anonymizovaná data veřejnosti bude přístupná bez nutnosti přihlášení.
3	Aplikace musí umožnit předávání podkladů členům orgánu v odpovídající lhůtě před jednání elektronicky bez nutnosti VPN přístupu do vnitřní sítě úřadu.
4	Aplikace musí umožnit vyhledání návrhů usnesení a informativních zpráv a finálních usnesení dle specializovaných filtrů na základě více informací.
5	Aplikace musí umožnit fulltextové vyhledávání, a to jak v textech usnesení, tak návrhů usnesení a informativních zpráv, tak v důvodové zprávě, pokud je součástí textu návrhu a finálního usnesení.
6	Je požadovaná integrace s identitním systémem EOS. Řízení oprávnění a rolí uživatelů bude probíhá v EOS. Je požadována možnost omezit právo organizátora na jednotlivé spravované orgány.
7	Personální zastoupení jednotlivých orgánů bude definováno v rámci identitního systému EOS, na straně aplikace Usnesení by pak mělo docházet k automatickému převzetí kontaktních informací pracovníků a členů orgánů města s možností rozesílání pozvánky a případně jiných notifikací bez nutnosti spravovat údaje pracovníků na straně aplikace Usnesení.
8	Pro přípravu jednání budou dostupné funkce: zaevidování nového jednání a nastavení jednotlivých parametrů – výběr oránu města, datum a čas jednání, termín automatického uzamčení jednání, automatické doplňování názvu jednání s možností jeho ruční editace, automatické číslování jednání z číselné řady odděleně pro jednotlivé orgány města s možností nastavení omezení na kalendářní rok, včetně možnosti ručního reset čísla jednání.
9	Pro přípravu materiálu budou dostupné funkce: tvorba návrhu usnesení, případně informativní zprávy editačním nástrojem, který zajistí unifikovanou podobu výsledného materiálu. Tvorba návrhu bude realizována bez vazby na jednání. Materiál bude na jednání zařazován až když je finálně dokončen, případně po schválení ve workflow.
10	Je požadovaná možnost generování čísla návrhu či informativní zprávy na základě automatického generátoru odděleně pro různé orgány města.
11	Je požadovaná možnost přípravu anonymizace již v rámci tvorby návrhu usnesení či informativní zprávy. Vlastní anonymizace a vznik anonymizovaných verzí návrhů usnesení, finálních usnesení a dokumentu Zápisu z jednání realizuje aplikace automaticky, bez nutného zásahu obsluhy. Anonymizované verze finálních Usnesení (případně návrhu usnesení) budou vytvářeny až v rámci procesu publikace do veřejné části Usnesení, ne dříve. Anonymizovaná verze zápisu vzniká ihned v rámci vzniku dokumentu Zápis z jednání.
12	Je požadovaná možnost přiložit k návrhu usnesení, případně k návrhu informativní zprávy samostatné přílohy.
13	Je požadovaná možnost odeslat připravovaný materiál ke schválení do workflow, včetně možnosti vybrat konkrétního schvalovatele. Zajistit možnost vkládání komentářů ke schvalovanému materiálu ze strany schvalovatelů a jejich následné vypořádání v rámci přípravy materiálů před jejich schválením a zařazením na jednání. Upozornit zpracovatele na nevypořádané komentáře v rámci kompletace návrhu.
14	Je požadovaná možnost zařazení bodu na jednání ze strany zpracovatele, případně předkladatele až ve chvíli, kdy je návrh kompletní.
15	Je požadovaná možnost pracovníkům v roli Organizátor zařadit jakýkoliv bod na jednání kdykoliv před jeho začátkem, nebo i v průběhu jednání. Stejně tak je potřeba umožnit pracovníkům v roli Organizátor vytvořit nový bod na jednání v průběhu jednání. Zajistit tak možnost zpracovat materiál tzv. na stůl.
16	Je požadovaná možnost pracovníkům v roli Organizátor správu programu jednání, ruční ovládání zámku jednání, změnu pořadí bodů, zařazení, nebo vytvoření bodů tzv. na stůl, vyřazení bodů z jednání, přeřazení bodů na jiné jednání.
17	Body na jednání se budou číslovat automaticky, včetně automatického přečíslování bodů v rámci změny pořadí bodů na jednání.
18	Je požadovaná možnost tvorby a rozeslání pozvánky formou e-mailové zprávy, kde přílohou je program jednání.
19	Je požadovaná možnost členům orgánů města online přístup k jednání, na které mu byla zaslána pozvánka.
20	Je požadovaná možnost tvorby a rozeslání tzv. distribučního balíčku, který umožní členům orgánů města studium podkladů offline.
21	Je požadovaná možnost tisku dokumentů Sbírka návrhů usnesení a Záznam z jednání na základě předdefinovaných šablon odděleně pro různé orgány města.
22	Je požadovaná možnost finalizace usnesení, včetně doplnění výsledků hlasování, včetně případných úprav obsahu usnesení, včetně možnosti zaevidovat protinávrhy a hlasování o nich.
23	Je požadovaná možnost přidání dalších bodů jednání, které byly v rámci jednání nově předloženy.
24	Je požadovaná možnost generování čísla usnesení na základě automatického generátoru odděleně pro různé orgány města. Umožnit různé nastavení generátoru čísla usnesení - číselná řada bez omezení s ručním reset čísla, číselná řada v rámci kalendářního roku, číselná řada v rámci jednání.
25	Je požadovaná možnost generování dokumentů Zápis z jednání a sbírka finálních usnesení na základě předdefinovaných šablon odděleně pro různé orgány města.
26	Je požadovaná funkce pro automatický vznik anonymizované verze dokumentu Zápis z jednání a zároveň zajistit automatický vznik anonymizovaných verzí usnesení v rámci jejich zveřejnění.
27	Pracovníkům v roli Organizátor musí mít možnost ovlivnit jaké údaje budou publikovány ve veřejné části Usnesení a zároveň umožnit ruční publikaci označených dat. Aplikace provede publikaci anonymizovaných verzí finálních usnesení a anonymizované verze dokumentu Zápis z jednání do veřejné části Usnesení.
28	Je požadovaná funkčnost pro automatický vznik a přidělení úkolů v rámci vzniku usnesení.
29	Je požadovaná možnost integrace veřejné části usnesení na webových stránkách úřadu, a pro usnadnění navigace občana na konkrétní jednání a možnost použití oddělených url adres jednotlivých orgánů města.
30	Je požadovaná funkčnost fulltextového a parametrického vyhledávání ve zveřejněných jednáních, která umožní občanům dohledat požadované usnesení nebo zápis bez znalosti konkrétního čísla usnesení nebo data jednání.
31	Je požadovaná funkčnost notifikací formou e-mailového upozornění v následujících případech – Přidělení nového úkolu, Vyřazení bodu z jednání, Přeřazení bodu na jiné jednání, Blížící se termín splnění úkolu.
32	Je požadovaná funkčnost podání žádosti o prodloužení termínu splnění úkolu a zároveň umožnit pracovníkům v roli Organizátor hromadně schvalovat žádosti o prodloužení termínu splnění úkolu na základně předchozího usnesení o schválení prodloužení termínu splnění úkolu.
33	Je požadovaná možnost rozvoje aplikace Usnesení ve formě integrace na hlasovací zařízení.
34	Je požadovaná možnost evidenci a správy jednání a porad bez usnesení a zajištění tak odlehčené evidence jednání, bodů k projednání a následného zápisu z porady včetně možnosti definovat ověřovatele zápisu z řad pracovníků, účastníků porady.
35	Je požadovaná možnost přidání dalších bodů jednání, které byly v rámci jednání nově předloženy.
36	Je požadována funkce pro oprávnění přístupu minimálně v rozsahu: - referent - právo založit a zpracovat návrh usnesení; - organizátor - má právo založit a spravovat jednání; - administrátor jednání - provádí administraci jednání; . předkladatel - předkládá návrh na jednání; - podepisující - elektronicky podepisuje výstupní dokumenty; - aktivní editace - má právo editovat všechny návrhy za vybraný odbor ; - obecný náhled - má právo náhledu na všechny návrhy za vybraný odbor; - revize - má možnost číst a evidovat komentáře k návrhům; - správce úkolů - spravuje evidenci úkolů; - zodpovídá za úkol - zodpovídá za úkol; - auditor úkolů - má právo náhledu na všechny úkoly; - zařazení bodu - má právo zařadit bod na jednáním; - pozorovatel - má právo náhledu na celý obsah každého jednání vybraného orgánu; - tajné dokumenty - má právo náhledu na obsah utajených příloh.
37	Je požadovaná možnost předat připravovaný návrh ke schválení do workflow před zařazením na jednání: - pro vytvoření schvalovacího workflow přebírat jména osob z evidovaných údajů v rámci daného návrhu; - možnost výběru workflow z předdefinovaných šablon - šablony budou konstruovány jako seznam rolí, které se automaticky vyplňují dle údajů předmětného návrhu; - možnost tvorby uživatelských šablon workflow.
38	Je požadovaná možnost elektronicky podepsat následující výstupní dokumenty: Pozvánka na jednání; Zápis z jednání; Finální usnesení; Sbírka finálních usnesení; a umožnit konfigurací určit: - pro jaký orgán bude elektronické podepisování užíváno; - jaké dokumenty, z výčtu výše, budou elektronicky podepisovány - v kontextu orgánu; - zda bude mít elektronický podpis viditelnou podobu v tisku podepsaného dokumentu - v kontextu orgánu a vybraného dokumentu.
39	Je požadovaná možnost dokumenty tvořit na základě předdefinovaných šablon a konfigurovat šablony pro každý orgán odděleně.
40	Je požadovaná funkce pro rozesílání e-mailové notifikace alespoň ve vyjmenovaných případech: - pozvánka na jednání; - přidělení úkolu; - upozornění na blížící se termín úkolu; - upozornění elektronického schvalování (o vzniku požadavku, o schválení / zamítnutí); - upozornění elektronického podepisování (o vzniku požadavku, o podepsání).
41	Je požadovaná možnost generovat identifikátory minimálně v rozsahu: - pořadové číslo jednání; - číslo návrhu usnesení; - číslo usnesení - číslo úkolu. Generátory musí být možné nastavovat nezávisle pro jednotlivé orgány. Pro čísla jednání, návrhů a usnesení musí být dostupná možnost číslovat automaticky v rámci roku, v rámci volebního období či volné období s ručním resetem. Pro generátor čísla jednání musí být dostupná možnost ručně zasáhnout do číselné řady vytvářené generátorem.
42	Je požadovaná integrace na elektronickou podpisovou knihu s možností opatřit elektronickým podpisem následující typy dokumentů: pozvánka na jednání; zápis z jednání; sbírka finálních usnesení; jednotlivá usnesení.
43	Součástí dodávky jsou reporty v technologii POWER BI: statistika jednání a statistika projednaných bodů; počet jednání orgánu; počty projednávaných bodů dle orgánů; zastupitelstvo a rada – počet jednání; komise a výbory – počty jednání; zastupitelstvo – počty projednávaných bodů; výbory – počty projednávaných bodů; rada – počty projednávaných bodů; komise – počty projednávaných bodů; statistika projednaných bodů dle předkladatele; počty projednaných bodů dle předkladatele; počty projednávaných bodů dle organizační jednotky předkladatele; statistika úkolů dle zodpovědné osoby; nesplněné úkoly po termínu; nesplněné úkoly před termínem; statistika úkolů dle řešitele; statistika hlasování stran (včetně procent); poměr výsledků hlasování; statistika hlasování členů stran; statistika hlasování bodů; statistika hlasování bodů podle stran; detailní hlasování zastupitelstva.

Popis požadovaných integračních vazeb je uveden v následující tabulce.

ID	Požadavek	Popis	Splněno
1	HCL NOTES aplikaci Projekty.	Integrace na LOTUS NOTES aplikaci Projekty. Umožní načíst identifikace a název projektu, částku, subjekt. Možnost načíst si číslo usnesení.
2	Integrace na POWER BI.	Viz požadavek 43
3	Integrace na Portál občana	Na portálu bude zpřístupněno: Časová osa rady a zastupitelstva Jednání výborů Vyhledávání: Výběr orgánu, předkladatele, data jednání, čísla usnesení Fulltextové vyhledávání ve všech usneseních

6. Realizační část e) – Robotizace správy přestupků

Realizačních část Robotizace správy přestupků bude propojená do portálu elektronických služeb a bude koncentrovat všechny přestupky a bude plně robotizovat proces výzev k úhradě přestupků. Řešení bude obsahovat komplexní robotizaci celého průběhu pro všechny oblasti přestupků.

Uvedené požadované vlastnosti řešení pro robotizaci správy přestupků jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkční vlastnosti řešení pro robotizaci správy přestupků	Splněno
Základní požadavky
1	Provoz v kontejnerových technologiích a podpor vzdálené instalace. Webové intuitivní uživatelské rozhraní. Možnost autentizace pomocí Active Directory. Podpora protokolu HTTPS pro aplikační server, API rozhraní a webového klienta.
2	Oprávnění přístupu pro referenty, vedoucí a sekretariát - referent zpracovává přestupkové řízení - vedoucí má náhled na všechna řízení s možností předávání spisů mezi referenty - sekretariát může pouze pořídit oznámení o přestupku a předat příslušnému referentovi
3	Řešení musí umožnit zobrazení dat v datových přehledech Microsoft Power BI za účelem nadstavbových analytických činností.
4	Je požadována integrace se spisovou službou essl GINIS úřadu minimálně na úrovni: - načtení doručených/postoupených dokumentů a spisů; - založení a úprava dokumentu a spisu; - vypravení dokumentu adresátům včetně podpory vypravení pomocí hromadné konverzní pošty a kontroly validity adresních údajů; - načtení výsledku vypravení / doručení adresátům; - vyřízení a uzavření dokumentů a spisů.
5	Je požadována integrace s ekonomickým systémem GINIS úřadu minimálně na úrovni: - evidence odběratelů, generování jednoznačného identifikátoru odběratele, jejich zápis do ekonomického systému: - generování VS/SS a čísel dokladů předpisů pohledávek (faktur); - zápis předpisů pohledávek do VS; - načtení úhrad předpisů pohledávek.
6	Je požadována integrace s registrem vozidel minimálně na úrovni: - načtení informací o vozidle, vlastníka a provozovatele vozidla dle RZ; - načtení údajů z registru EUCARIS pro vozidla registrovaná v EU.
7	Je požadována integrace se systémem základních registrů a spolupracujících AIS minimálně v rozsahu: - fulltextové vyhledání adres; - ověření údajů subjektů v registrech ROB a ROS; - možnost automatické notifikace a aktualizace změn údajů subjektů ověřených na registry ROB a ROS; - načtení údajů o svéprávnosti fyzické osoby; - načtení údajů o rodičích mladistvých a dětí mladších 15-ti let z agendového systému ISEO.
8	Je požadována integrace na informační systém evidence přestupků (ISEP) minimálně v rozsahu: - opis z ISEP; - zápis do ISEP; - změna zápisu do ISEP.
9	Je požadována integrace na registr řidičů – informace o spáchaných přestupcích a uložených zákazech řízení, o rozsahu řidičských oprávnění, zdravotní omezení.
10	Je požadována integrace pro automatické / hromadné načítání oznámení dopravního přestupku z automatizovaných detekčních systémů minimálně v rozsahu: - webové služby pro externí systémy na založení oznámení přestupku včetně příloh (metadata, fotografie, soubor oznámení); - načítání oznámení konektorem MP; - načítání oznámení od PČR.
11	Je požadována podpora procesů zpracování přestupků z hromadných detekčních prostředků a generování oznámení přestupku, např. v rámci procesů obecní policie: - ověření přestupků předaných z hromadných detekčních prostředků; - výběr přestupků pro generování oznámení přestupku; - hromadné generování oznámení přestupku; - hromadné předání oznámení přestupku do řešení výzev provozovateli vozidla nebo odeslání dokumentů oznámení přestupku do spisové služby.
12	Je požadováno automatické a hromadné zpracování níže uvedených procesů: - ověření vlastníků a provozovatelů vozidel; - ověření údajů provozovatelů a vlastníků na základní registry; - přiřazení přestupků ke zpracování jednotlivým referentům s možností rozdělení dle MPZ RZ; - generování výzev provozovateli vozidla v požadovaných jazykových mutacích dle typu přestupku včetně generování předpisu výzvy; - vypravení výzev v kontextu typu (fyzická, právnická osoba) a státní příslušnosti provozovatele včetně vypravení hromadnou konverzní poštou; - načtení doručenek vypravení výzev, nastavení skutečného data splatnosti výzvy; - kontrola úhrady výzev v kontextu data splatnosti; - odložení po uhrazení výzvy; - předání do přestupkového řízení po neuhrazení výzvy; - generování přehledů vratek.
13	Je požadována možnost kontroly oznámeného přestupku referentem s podporou: - výběru fotografií pro výzvu; - ověření provozovatele vozidla na základní registry včetně úpravy údajů provozovatele; - pře ověření provozovatele vozidla na registr vozidel; - určení dalšího procesu zpracování oznámení" k odložení, k předání věci, k výzvě, k předání do přestupkového řízení.
14	Je požadována možnost evidence a zpracování obecných i dopravních přestupků včetně strukturovaných údajů například o dopravním přestupku a fotodokumentace.
15	Řešení bude obsahovat přehledný dashboard pro zpracovatele přestupků a vedoucí pracovníky minimálně v rozsahu: - přehledová statistika zpracovávaných přestupků; - přehled událostí vycházejících ze spisů pro jednotlivé referenty; - upozornění na procesní lhůty a stavy zpracování jednotlivých řízení s podporou minimálně: -- vydání Rozhodnutí; -- dokument Bez Podpisu; -- dokument S Odmítnutým Podpisem; -- dokument Bez Výsledku Doručení; -- dokument Nedoručený; -- dokument Podepsaný, Neodeslaný Do Sps; -- dokumenty Bez Vyznačení Npm; -- lhůta Pro Předání Odvolání Nso; -- “Rozpracované” Dokumenty; -- nevyžádán Opis Z Isep; -- nezapsáno Do Isep; -- nezapsáno Do Karty Řidiče; -- souhlas Přímo Postižené Osoby; -- skartace Spisu; -- podmínečné Upuštění Od Trestu.
16	Je požadována funkce Seznam doručených, postoupených, dokumentů referentovi s možností jejich zpracování: - zobrazení náhledu doručeného PDF dokumentu přímo v aplikaci; - pořízení oznámení o přestupku včetně strukturovaných údajů o přestupku a přestupci; - zařazení dokumentu do již evidovaného spisu nebo založení nového spisu nad dokumentem; - automatické dohledání spisů splňující podmínky společného řízení a možnost vložení oznámení do tohoto spisu.
17	Je požadována funkce vyhledání spisů a přestupků: - fulltextové rychlé dohledání dle spisové značky, ČJ dokumentů, RZ, interního označení a údajů subjektů přestupkového řízení; - strukturovaný seznam evidovaných spisů s možností filtrování dle evidovaných údajů a stavů řízení / přestupků; - hromadné akce nad vybranými spisy (předání/převzetí spisů, skartace spisů).
18	Je požadována možnost úpravy evidovaných údajů spisu a přestupků.
19	Je požadována funkce generování dokumentů na základě předpřipravených šablon: - možnost individuální tvorby a úpravy šablon referenty; - dostupnost datových zdrojů při definici šablon pro automatické doplnění údajů při generování dokumentu.
20	Je požadována funkce automatického přiřazení správného způsobu vypravení adresátům na základě legislativních pravidel, evidovaných kontaktních údajů, typů subjektů včetně domicilu subjektu.
21	Je požadována funkce podepsání dokumentu elektronickým podpisem přímo v aplikaci: - podpora podepsání přímo referentem; - odeslání dokumentu k podpisu jiným pracovníkem; - jednotné rozhraní pro požadavky na podpis, například vedoucí má zobrazenu "frontu(y)" požadavků na podpis od všech referentů všech typů dokumentů.
22	Je požadována podpora průvodce pro společné řízení: - dohledání spisů a přestupků dle legislativních pravidel pro společné řízení; - výběr přestupků pro společné řízení; - výběr cílového spisu pro společné řízení; - automatické vyloučení / sloučení přestupků včetně generování příslušných dokumentů o tomto a předání/převzetí spisů od jiných referentů v případě potřeby.
23	Je požadována podpora automatické před kvalifikace dopravního přestupku na přestupek provozovatele v případě marného uplynutí výzvy provozovatele vozidla.
24	Je požadována podpora evidence událostí ve spisu: - události vycházející ze lhůt a termínů jednání; - individuálně zadané události.
25	Je požadována možnost referenčního nastavení legislativy: - využívané zákony a paragrafy; - definice skutkových podstat a porušených povinností ve vazbě; - definice sankcí; - definice parametrů skutkových podstat (např. recidiva, možnost využití výzvy provozovatele vozidla, nutný zápis do ISEP, nutný souhlas přímo postižené osoby).

Popis požadovaných integračních vazeb je uveden v následující tabulce.

ID	Požadavek	Popis	Splněno
1	Integrace na ekonomický systém	ES GINIS - evidence odběratelů, generování jednoznačného identifikátoru odběratele, jejich zápis do ES - generování VS/SS a čísel dokladů předpisů pohledávek (faktur) - zápis předpisů pohledávek do VS - načtení úhrad předpisů pohledávek automatické vyhodnocení úhrad předpisů výzev a pohledávek.
2	Integrace na spisovou službu	ESSL GINIS - načtení doručených/postoupených dokumentů a spisů - založení a úprava dokumentu a spisu - vypravení dokumentu adresátům včetně podpory vypravení pomocí hromadné konverzní pošty a kontroly validity adresních údajů - načtení výsledku vypravení / doručení adresátům - vyřízení a uzavření dokumentů a spisů
3	Integrace na náběr požadavků z radarů MPK	MPK MARBES Příjem záznamů z radarů.
4	Integrace hybridní poštu	Odesílání dokumentů do hybridní pošty
5	Integrace na ISZR	Fulltextové vyhledání adres - Ověření údajů subjektů v registrech ROB a ROS - Možnost automatické notifikace a aktualizace změn údajů subjektů ověřených na registry ROB a ROS - Načtení údajů o svéprávnosti fyzické osoby - Načtení údajů o rodičích mladistvých a dětí mladších 15-ti let z agendového systému ISEO -načítání informací o datových schránkách (vlastnictví datové schránky)
6	Integrace na ISRV	Načtení informací o vozidle, vlastníka a provozovatele vozidla dle RZ
7	Integrace na ISEP	- Opis z ISEP - Zápis do ISEP - Změna zápisu do ISEP

7. Realizační část f) – Participace na řízeném rozvoji města

Realizačních část Participace na řízeném rozvoji města bude propojená do portálu elektronických služeb a bude zprostředkovávat řízenou komunikace mezi občany a městem.

Interaktivní nástroj pro komunikaci s občany a jejich participaci na řízeném rozvoji města bude poskytovat oboustrannou komunikaci mezi městem a jeho občany a umožní občanům podílet se na tvorbě a plánování budoucích rozvojových projektů města, případně poskytne zpětnou vazbu veřejného mínění ve formě hlasování pro různé oblasti zájmu. Součástí řešení bude backend systém, ve kterém bude administrována a řízena komunikace a informace o plánovaných projektech. Pro uživatele budou k dispozici statistiky a výstupy ve formě výsledků hlasování a rozhodnutí o komunikovaných projektových záměrech.

Uvedené požadované vlastnosti řešení Participace na řízeném rozvoji města jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkční vlastnosti řešení pro participaci na řízeném rozvoji města	Splněno
1	Soubor funkcí „Participace“ bude součástí řešení Portálu občana, který bude obsahovat sekce: Přihlášení projektu; Projekty k hlasování; Projekty k realizaci; Témata města k diskusi.
2	Řešení umožní podat formulář s přihlášením projektu. K projektu bude možné podat přílohy, obrazovou dokumentaci a další podklady. Součástí sekce přihlášení projektu bude i formulář pro stažení podaného projektu.
3	V sekci projekty k hlasování budou zobrazeny všechny přijaté projekty. Portál umožní hlasování o projektech v termínu od - do. Portál umožní ruční nahrání schválených projektů. U každého projektu bude popis projektu, umístění, náklady a mapa.
4	V sekci projekty k realizaci budou zobrazeny všechny projekty, které splnily kritéria výběru: vešly se do alokace, získaly dostatečný počet hlasů, prošly kontrolou realizovatelnosti. U každého projektu bude popis projektu, umístění, náklady a mapa. Projekty budou zobrazovány podle ročníků Participace.
5	V sekci „K diskuzi“ bude vypisovat město témata, ke kterým se občané mohou vyjádřit. V rámci sekce bude možné podat formulář s podáním nebo hlasovat v rámci ankety.

Popis požadovaných integračních vazeb je uveden v následující tabulce.

ID	Požadavek	Popis	Splněno
1	Integrace na PO	Modul participativní rozpočet bude součástí Portálu občana

6. Fáze A – Implementace řešení

1. Implementace řešení bude provedena v jednotlivých požadovaných krocích a termínech uvedených v kapitole 3.

2. Minimální požadavky na implementaci řešení jsou uvedeny v následující tabulce.

Id	Plnění požadavku	Splněno
1	Zpracování Detailního cílového konceptu
2	Dodávka licencí
3	Implementace testovacího prostředí, včetně požadovaných vazeb
4	Školení uživatelů a administrátorů jednotlivých částí informačního systému
5	Implementace Produkčního prostředí, včetně požadovaných vazeb a realizace Produkčního provoz s podporou

1. Zpracování a akceptace Detailního cílového konceptu

1. Dokument Detailní cílový koncept bude obsahovat minimálně:

1. analýzu výchozího stavu a bude vycházet z popisu současného stavu, viz Příloha 3.a. ZD;

2. definici cílového stavu, která bude vycházet z požadavků na budoucí stav, viz tento dokument a bude doplněna Dodavatelem o analýzu současného stavu prováděnou pracovníky Dodavatele v aktuálních podmínkách Zadavatele;

3. návrh řešení instalace aplikační a databázové části systému (architektura technického řešení) detailní popis nastavení – konfigurace a parametrizace jednotlivých oblastí (společné registry, role a přístupová oprávnění, číselníky, reporty atd.);

4. návrh technického řešení integračních vazeb; návrh řešení postupu a pořadí při nasazování jednotlivých částí řešení – upřesnění harmonogramu projektu, který bude vycházet z milníků uvedených v kapitole 3 a z Dodavatelem navrženého Harmonogramu projektu;

5. popis případných organizačních opatření nutných pro implementaci;

6. rozsah součinnosti ze strany zadavatele;

7. akceptační kritéria cílového stavu, pro ověření plnění Dodavatele v rámci Smlouvy o dílo jsou uvedena v tomto dokumentu, a to v tabulkách označených „Minimální požadavky …“, kde Dodavatel bude deklarovat svoji připravenost poskytovat bezvadné plnění již v rámci Zkušebního (testovacího) provozu.

8. Realizační (prováděcí) projekt – podrobný popis realizace dané části VZ, který bude zpracován Dodavatelem na základě návrhu Dodavatelem dodané Xxxxxxxx řízení projektu;

2. Formálně bude tato oblast Fáze A završena dohodnutým a vzájemně odsouhlaseným Předávacím protokolem dílčího plnění (Dodavatel předává dokument Detailní cílový koncept) a Akceptačním protokolem dílčího plnění, kterým Zadavatel akceptuje splnění podmínek této části Fáze A ve Smlouvě o dílo.

3. Dokumentace skutečného nasazení bude připomínkována Zadavatelem a připomínky budou ze strany Dodavatele vypořádány (tj. zapracovány, případně s jasným a konkrétním písemným zdůvodněním odmítnuty jako nevalidní). Ze strany zadavatele nebude v rámci připomínkování v případě nepravdivých, nepřesných nebo věcně nejasných informací v této dokumentaci požadováno její opravování na správné znění, bude se pouze jednat o vyznačení výše uvedených nedokonalostí a je na zadavateli jejich vypořádání.

2. Dodávka licencí

1. Zadavatel požaduje v rámci plnění dodávku takového počtu uživatelských licencí, který zajistí legální provoz a využití dodaného řešení ze strany uživatelů, a to jejich dále uvedeném počtu a skladbě.

2. Minimální požadavky na Licence SYSTÉMU jsou uvedeny v následující tabulce.

Id	Plnění požadavku	Splněno
01	Zadavatel nebude mít žádné omezení v počtu využívaných licencí (uživatelských přístupů) k jakékoliv části nabízeného řešení. Jedná se o časově neomezenou licenci opravňující k neomezenému počtu přístupů Zadavatele ke všem funkcionalitám dodaného řešení, provozovaného a spravovaného na zařízení Zadavatele.
02	Zadavatel požaduje poskytnutí veškerých nezbytných licencí k řádnému plnění předmětu, tj. k řádnému provozu díla na zařízení Zadavatele, zajišťující plnou funkcionalitu nabízeného řešení.
03	Dodavatel specifikuje název, počet, verzi a licenční podmínky ke všem nutným licencím v příloze smlouvy o dílo, a to včetně odůvodnění zvolené licenční nabídky, dále pak uvede licenční politiku, pravidla pro přidělení a případně změny v počtu licencí a verzí licencí.
04	Zadavatel požaduje dodání licence řešení pro produkční i testovací (školící) prostředí.
05	Zadavatel požaduje zajištění veškerých nutných licencí třetích stran, včetně licencí open source software a pod, potřebných pro provozování dodaného řešení.
06	Licence SYSTÉMU zahrnuje rozhraní pro konkrétní počet informačních systémů třetích stran (ISZR, ISDS, CzechPoint, apod.).

3. Formálně bude tato oblast Fáze A završena dohodnutým a vzájemně odsouhlaseným Předávacím protokolem dílčího plnění (Dodavatel předává SW licence SYSTÉMU).

Implementace Testovacího a Produkčního prostředí

1. Dodavatel vytvoří dvě prostředí:

Testovací prostředí

1. v rozsahu dle DCK,

2. které na infrastruktuře Zadavatele připraví Dodavatel,

3. s využitím testovacích dat a rozhraní.

Testovací prostředí bude sloužit zejména pro testování nastavení, migrací, rozhraní apod. a dále proškolení uživatelů a administrátorů a získávání praxe uživatelů a administrátorů na testovacím prostředí.

Produkční prostředí

1. v rozsahu dle DCK,

2. které na infrastruktuře Zadavatele připraví Dodavatel,

3. s využitím produkčních dat a rozhraní.

Produkční prostředí bude sloužit jednak k Testování a Akceptaci a dále k produkčnímu provozu.

2. Formálně bude tato oblast Fáze A završena dohodnutým a vzájemně odsouhlaseným Předávacím protokolem dílčího plnění (Dodavatel předává Testovací prostředí a Produkční prostředí) a Akceptačním protokolem dílčího plnění, kterým Zadavatel akceptuje splnění podmínek této oblasti ve Smlouvě o dílo.

Produkční provoz s podporou

1. Implementace Produkčního provozu s podporou bude v rozsahu dle DCK.

2. Produkční provoz s podporou bude probíhat na produkčním prostředí.

3. Jeho účelem je zjistit, zda jsou splněny akceptační podmínky uvedené v tomto dokumentu a v DCK, včetně ověření funkčnosti veškerých vazeb se všemi provázanými subsystémy a ověření relevantnosti migrovaných dat v reálném provozu.

4. V průběhu Produkčního provozu s podporou může docházet k dílčím úpravám řešení tak, aby nedocházelo k omezení dané funkcionality.

5. Pokud dojde v průběhu Produkčního provozu s podporou k závadám, které omezí funkcionality plnění, prodlužuje se doba Produkčního provozu s podporou o stejnou dobu, po kterou nebylo plnění funkční (bez vad).

6. Formálně bude Fáze A završena dohodnutým a vzájemně odsouhlaseným Předávacím protokolem (Dodavatel předává plnění dle Smlouvy o dílo) a Akceptačním protokolem, kterým Zadavatel akceptuje splnění podmínek Fáze A ve Smlouvě o dílo.

Předání a převzetí plnění

1. Předání a převzetí dokumentů

1. Dokumenty, které mají být vypracovány Dodavatelem a které se poskytují Zadavateli jako součást poskytování díla (zejména Detailní cílový koncept), budou nejdříve předloženy Xxxxxxxxxx ve formě návrhu k posouzení.

2. Dodavatel se zavazuje předat první verzi dokumentu Zadavateli k akceptaci ve lhůtě domluvené mezi Dodavatelem a Zadavatelem na základě Xxxxxxx o dílo, nebo jinak stanovené v souladu se Xxxxxxxx o dílo.

3. Zadavatel je oprávněn ve lhůtě pěti (5) pracovních dnů od doručení příslušného dokumentu písemně předložit Dodavateli své připomínky k návrhu.

1. Po diskusi o těchto připomínkách upraví Dodavatel příslušný návrh v souladu s dohodnutými změnami a se zapracováním těchto dohodnutých změn jej předá ve stejné lhůtě pěti (5) pracovních dnů Zadavateli.

2. V případě, že Zadavatel nemá k předaným dokumentům výhrady, považují se za převzaté k okamžiku doručení jejich konečné verze Zadavateli.

3. V případě, že Xxxxxxxxx připomínky ve lhůtě pěti (5) dnů nepředloží, má se za to, že s předloženým dokumentem souhlasí a dokument se považuje za řádně převzatý.

4. Dodaná dokumentace v rámci řešení slouží k zachycení a vyhodnocování plánovaných činností a též k dokumentaci skutečného stavu.

4. Minimální požadavky na dokumentaci řešení jsou v níže uvedené tabulce.

Id	Plnění požadavku	Splněno
1	Součástí prací bude vytvoření kompletní a detailní dokumentace dle standardů ISVS.
2	Dokumentace nebude chráněna dle autorského zákona, bude umožněno ji dále upravovat a předávat dalším subjektům, které se podílejí na chodu informačních systémů.
3	Dodavatel předloží plán tvorby dokumentace (jako součást Detailního realizačního projektu).
4	Dokumentace bude v elektronické formě, ve formátu PDF
Detailní cílový koncept
5	Úvodní seznámení s funkcionalitami dodávaného řešení pro členy projektového týmu Zadavatele.
6	Kompletní analýza řešení problematiky řešení a jeho implementace v prostředí Zadavatele, včetně stanovení rozsahu migrace a integračních vazeb na okolní AIS a eGovernment.
7	Grafické schéma a podrobný popis architektury řešení, obsahující přehled použitých serverů a jim přidělených zdrojů, včetně popisu funkčních vazeb.
8	Podrobný popis způsobu a rozsahu implementace řešení včetně realizace odpovídajících integračních vazeb.
9	Návrh zátěžových, funkčních, integračních (akceptačních) testů řešení.
10	Návrh monitoringu, zálohování a obnovy řešení s využitím stávajících technologií Zadavatele.
11	Detailní harmonogram realizace zakázky řešení vycházejícího z Milníků uvedených v ZD.
Realizační dokumentace řešení
12	Bude zpracována kompletní implementační a provozní dokumentace v písemné i elektronické editovatelné podobě ve formátu MS Office, včetně popisu pravidelné údržby a dokumentace finálního provedení, zahrnující, krom jiného, i detailní popis rozhraní.
13	Bude zpracována dokumentace finálního vyhotovení řešení včetně detailního popisu všech rozhraní. Součástí dokumentace bude i detailní popis API rozhraní testovacího i produktivního prostředí řešení pro napojení aplikací třetích stran.
14	Pro podporu uživatelů a administrátorů budou zpracovány: uživatelské příručky metodické pokyny popisy procesů administrátorská příručka eLearningové kurzy (v technologii HTML)

2. Předání a převzetí ostatních plnění dle Xxxxxxx o dílo (vyjma služeb)

1. V případě, že součástí poskytování plnění Dodavatelem dle Xxxxxxx o dílo je plnění, které podléhá akceptaci Zadavatelem, musí dojít k podpisu Předávacích protokolů ohledně tohoto plnění v termínech uvedených v harmonogramu, není-li výslovně uvedeno jinak.

1. Detailní kritéria akceptace a vymezení plnění, která podléhají akceptaci Zadavatelem, jsou uvedena v tomto dokumentu, případně v Detailním cílovém konceptu.

2. Jestliže plnění nebo jeho jednotlivé části splní kritéria akceptačního řízení, považují se za řádně ukončené a Zadavatel je povinen jej převzít.

2. Akceptační procedury zahrnují porovnání skutečných vlastností plnění se závaznou specifikací předmětu plnění dle Xxxxxxx o dílo.

1. Akceptační procedura bude zahrnovat akceptační testy, které budou probíhat na základě specifikace akceptačních testů obsahující popis testů, testovací data, příslušné prostředí, pořadí provádění testů a akceptační kritéria.

Nedohodnou-li se smluvní strany jinak, vypracuje specifikaci akceptačních testů Dodavatel a předá Zadavateli k odsouhlasení v termínu pěti (5) pracovních dnů před zahájením akceptační procedury dle harmonogramu.

Odsouhlasení bude provedeno písemnou formou v termínu pěti (5) pracovních dnů před zahájením akceptační procedury. Jestliže se Zadavatel v této lhůtě ke specifikaci akceptačních testů písemně nevyjádří, má se za to, že specifikaci akceptačních testů odsouhlasil.

Jestliže Zadavatel specifikaci akceptačních testů v uvedené lhůtě neodsouhlasil, je povinen Zadavatel v této lhůtě sdělit připomínky k Dodavatelem předložené specifikaci akceptačních testů a poskytnout Dodavateli veškerou potřebnou součinnost k dokončení a odsouhlasení specifikace akceptačních testů.

Lhůta pro provedení akceptačních testů a lhůta pro předání plnění nebo jeho části se prodlužuje o dobu, o kterou se prodloužilo písemné odsouhlasení specifikace akceptačních testů z důvodu připomínek na straně Zadavatele oproti lhůtě stanovené.

2. Dodavatel bude písemně informovat Xxxxxxxxxx, resp. jeho oprávněné osoby nejméně pět (5) dní předem o termínu zahájení akceptačních testů.

Zadavatel je oprávněn se těchto testů zúčastnit a osvědčit jejich konání, a to formou předávacího protokolu (nebo dílčích předávacích protokolů), podepsaného (podepsaných) oprávněnými osobami obou smluvních stran. Pokud se Zadavatel nedostaví v termínu určeném pro provedení akceptačních testů, ačkoli byl s tímto termínem řádně seznámen, je Dodavatel oprávněn provést příslušné akceptační testy bez jeho přítomnosti.

Takto provedené akceptační testy se považují za provedené v přítomnosti Zadavatele. Kopie veškerých dokumentů vypracovaných v souvislosti s provedením těchto akceptačních testů budou Zadavateli poskytnuty do pěti (5) dnů.

3. Základním předpokladem pro řádné předání plnění (nebo jeho části) Dodavatelem a převzetí tohoto plnění (nebo jeho části) Zadavatelem, a to formou předávacího protokolu podepsaného oprávněnými osobami obou smluvních stran je skutečnost, že plnění splní kritéria akceptačních testů uvedená v dohodnutých kontrolních specifikacích a bude provedeno v souladu se závaznou specifikací předmětu plnění dle Xxxxxxx o dílo.

4. Jestliže plnění nebo jeho část splní akceptační kritéria akceptačních testů, Dodavatel se zavazuje v den následující po ukončení akceptačních testů umožnit Zadavateli plnění nebo jeho část převzít a Zadavatel se zavazuje v tomto termínu plnění nebo jeho část převzít.

Pokud Zadavatel plnění nebo jeho část v tomto termínu nepřevezme, ačkoli převzetí plnění nebo jeho části bylo Dodavatelem řádně umožněno, má se za to, že plnění nebo jeho část bylo řádně předáno a Zadavatelem převzato právě v den následující po ukončení akceptačních testů.

5. Jestliže plnění nesplňuje stanovená akceptační kritéria kteréhokoliv akceptačního testu, budou výsledky akceptačního testu (splněno/nesplněno/s výhradami) spolu s uvedením termínů pro nápravu uvedeny ve vyhodnocení Akceptačního protokolu.

Dodavatel napraví tyto nedostatky a příslušné akceptační testy budou provedeny znovu.

Tento proces testování a následných oprav se bude opakovat, přičemž výše uvedená ustanovení se použijí obdobně.

Proces testování a následných oprav lze opakovat, dokud Dodavatel nesplní veškerá akceptační kritéria pro příslušný akceptační test, nejvýše však natřikrát (3x).

V situaci, kdy by bylo nutné opakovat akceptační testy více jak třikrát (3x) pro konkrétní fázi projektu, je v takovém případě nutný souhlas nadřízeného orgánu projektu – tzn. řídícího výboru nebo ředitelů projektu dle použité metodiky řízení projektu.

6. Žádný akceptační test se však nebude považovat za nesplněný, jestliže daný nedostatek nebyl způsoben Dodavatelem, nebo byl zjištěn nebo měl být zjištěn Zadavatelem před nebo při předcházejícím akceptačním testu, ale nebyl v té době oznámen Xxxxxxxxxx, nebo byl nepodstatný, tzn., neměl vliv na řádné poskytování funkčnost díla nebo jeho části tak, jak jsou vymezeny ve Xxxxxxx o dílo.

7. Při převzetí plnění nebo kterékoliv jeho části v souladu s tímto článkem je Zadavatel povinen podepsat potvrzení o přijetí plnění nebo dané části a Zadavatel i Dodavatel se zavazují podepsat příslušný předávací případně akceptační protokol (dílčí předávací případně akceptační protokoly), tj. potvrzení o předání a přijetí (převzetí) plnění nebo jeho určité části.

3. Migrace dat

Zadavatel nepožaduje migraci dat ze stávajících systémů.

4. Technologické prostředí

Instalace řešení a jeho nastavení dle zadavatelem odsouhlasené dokumentace skutečného nasazení bude provedena na hardware a software Zadavatele, který bude dodán a instalován v rámci samostatné části projektu dle zadávacího řízení s názvem „Rozšíření techologie“. Z tohoto důvodu bude v rámci před implementační analýzy definován skutečný rozsah HW/SW podpůrných komponent, na které se bude předmět plnění dle tohoto dokumentu implementovat.

Zadavatel požaduje v rámci plnění také instalaci a nastavení testovací (školící) instance, která bude obsahovat iniciální naplnění anonymizovanými / testovacími daty, bude mít nastavena přístupová oprávnění pro uživatele a bude sloužit k ověření funkčnosti řešení a pro možnost školení a testování systému ze strany jeho uživatelů.

5. Školení

1. Dodavatel poskytne školení pro uživatele a administrátory IS tak, aby všichni pracovníci Zadavatele byli schopni řádně užívat, respektive administrovat, instalované řešení.

2. Dodavatel poskytne školení tak, aby pracovníci Zadavatele získali další znalosti praktického využívání řešení jako efektivní podpory procesů u Zadavatele, znalosti související a aktuální legislativou a jejími připravovanými změnami, znalosti metodické, tj. aby došlo k významnému přenosu znalostí a zkušeností z Dodavatele na Zadavatele.

3. Systém školení uživatelů je velmi podstatnou součástí realizace projektu pro úspěšné zavedení podpůrných nástrojů ICT do procesů s cílem zlepšení fungování úřadu.

4. Minimální požadavky na školení jsou v níže uvedené tabulce.

Id	Plnění požadavku	Splněno
1	Dodavatel předloží plán školení (jako součást Detailního cílového konceptu). Součástí plánu školení bude i realizace testování (přezkušování) získaných znalostí uživatelů a jejich uplatnění v praxi.
2	Bude provedeno základní seznámení s funkčností dodávaného systému pro členy projektového týmu Zadavatele na začátku realizace díla (před zpracováním detailní analýzy a Detailního cílového konceptu).
3	Bude provedeno školení administrátorů systému v rozsahu minimálně 8 školících hodin pro max. 3 zaměstnance určených Zadavatelem, které bude zahrnovat kompletní správu systému. Jako podkladový materiál musí být dodána administrátorská příručka.
4	Bude provedeno školení uživatelů na seznámení s obsluhou modulů dodaného systému. Jako podkladový materiál musí být dodána uživatelská příručka.
5	Veškerá školení poskytovaná v průběhu implementace (realizační fázi), která jsou součástí jednotlivých častí díla, zajistí Dodavatel na své náklady a v místě realizace.

Zadavatel se pro tyto účely zavazuje zajistit:

• školící místnost s prezentační technikou,

• připojení na technologickou infrastrukturu.

6. EXIT plán

Součástí projektu je vypracování ve prospěch Xxxxxxxxxx dokumentace tzv. EXIT plánu, vč. garance případných služeb, a to dle níže uvedených kritérií.

ID	Požadavek
1	Vypracování „Exitového plánu“ v dostatečném předstihu a poskytnutí nezbytné součinnosti k jeho realizaci.
2	Příprava a předání “Exitového plánu“ novému poskytovateli nebo Zadavateli.
3	Poskytnutí požadovaných součinností v souvislosti s předáním podpory a provozu řešení podle pokynů Zadavatele novému poskytovateli.
4	Řádné předání všech dat zpracovávaných řešením, včetně dat doplňkových.
5	Poskytnutí veškeré relevantní Dokumentace a potřebných informací Zadavateli.

7. Fáze B – Servisní podpora řešení, SLA

1. Požadavky, které musí Dodavatel minimálně naplnit na Servisní podporu řešení jsou v níže uvedené tabulce.

Id	Plnění požadavku	Splněno
1	Dodavatel zajistí, že veškeré vlastnosti díla, včetně jeho update, legislativního update, upgrade a legislativního upgrade budou po celou dobu účinnosti Smlouvy o podpoře odpovídat vždy aktuálním obecně platným právním předpisům ČR a platným standardům ISVS.
2	Úpravy programového vybavení (obecné, rozvoj, legislativa apod.) zajistí s dostatečným časovým předstihem před nabytím účinnosti konkrétního právního předpisu, minimálně 5 pracovních dní.
3	V rámci běžného rozvoje jednotlivých částí řešení Dodavatel zajistí poskytnutí aktualizovaných verzí nejpozději do 3 měsíců po uvolnění nové verze k distribuci.
4	Budou poskytovány informace o změnách a nových funkcích v aktualizovaných verzích řešení.
5	Bude prováděna průběžná aktualizace dokumentace k programovému vybavení tak, aby u Zadavatele byla vždy aktuální dokumentace k provozovanému řešení.
6	Bude poskytována součinnost při zásadním upgrade operačního systému a databázového systému na vyšší verze.
7	Bude zajištěna udržitelnost SW třetích stran, dodaných Dodavatelem v rámci veřejné zakázky.
8	Servisní (Technická) podpora a servis budou poskytovány po celou dobu smluvního vztahu (min 60 měsíců ode dne protokolárního ukončení projektu dle Smlouvy o dílo). Poskytování technické a servisní podpory bude odpovídat příkladům nejlepší praxe dle rámce ITIL/ITSM.
9	Technická podpora a servis zařízení SW budou realizovány Dodavatelem, případně prostřednictvím odpovídajícího servisního kanálu výrobce.
10	Technická podpora a servis budou realizovány v místě Zadavatele. Výjimku tvoří činnosti realizované vzdáleným připojením Dodavatele do prostředí Zadavatele.
11	Veškeré požadavky budou evidovány v systému servisní podpory Dodavatele (HelpDesk).
12	Kontaktní místo umožní příjem požadavku na servisní zásah v českém jazyce prostřednictvím služby HelpDesk, popř. služby Hot-line.
13	Služba Hot-Line umožní příjem požadavku na servisní zásah v českém jazyce na telefonním čísle v režimu 5x8 (8 hodin v pracovní dny) v době od 08:00 do 16:00 hod, příjem požadavku bude zajištěn lidskou obsluhou.
14	Služba HelpDesk umožní příjem požadavku na servisní zásah v českém jazyce prostřednictvím webového rozhraní v režimu 7x24 (nepřetržitě vyjma nahlášených servisních zásahů Dodavatele při správě systému HelpDesk).
15	Služba HelpDesk umožní Zadavateli upřesnit nebo doplnit požadavek.
16	Služba HelpDesk bude Zadavateli poskytovat přehled o aktuálně nahlášených požadavcích, jejich stavu a aktuálním způsobu jejich řešení. Služba HelpDesk bude Zadavateli zasílat notifikace o změně stavu jeho požadavku (např. zadaný, v řešení, uzavřený atd.) a musí Zadavateli umožnit schvalování uzavření nahlášeného požadavku.
17	Služba HelpDesk bude poskytovat Zadavateli přístup i k uzavřeným požadavkům a způsobu jejich řešení, bude poskytovat podrobné údaje o historii požadavků od jejich nahlášení, po jejich vyřešení.

2. V rámci zajištění podpory a servisu po dobu udržitelnosti projektu platí následující parametry SLA.

3. Definice stupňů závažnosti incidentů:

Závažnost Závady nebo Chyby		Definice závažnosti Závad a Chyb
A	Kritická chyba	Chyba způsobí, že poskytované řešení nelze zcela provozovat nebo má kritický vliv na provozované aplikace či stav podporovaného systému – vyžaduje okamžité řešení.
B	Urgentní chyba	Chyba výrazně omezuje správnou funkcionalitu řešení lze provozovat s omezením nebo po určitou dobu ve formě náhradního řešení.
C	Chyba	Nekritická chyba řešení – provoz je problémem ovlivněn, ale lze provozovat bez výrazného omezení.
D	Námět na vývoj	Námět na vývoj bude předán Dodavateli prostřednictvím nástroje HelpDesk. Dodavatel bude tyto náměty vyhodnocovat a dle plošného přínosu do následujícího sestavení. Dodavatel má právo předmětné náměty odmítnout.

4. Definice maximální doby nástupů k řešení incidentů podle závažnosti:

Závažnost Chyby	Doba zahájení činnosti (od nahlášení)	Doba odstranění chyby	Řešení
A	4 pracovní hodiny	8 pracovních hodin	a
B	8 pracovní hodiny	16 pracovních hodin	a, b
C	16 pracovních hodin	32 pracovních hodin	a, b
D	podle dohody	podle dohody	c

5. Řešením se rozumí:

1. Odstranění chyby řešení. Opravy Chyb bude provádět Dodavatel do Aktualizované verze (kritické chyby ihned).

2. Poskytnutí přijatelného náhradního řešení problému ze strany Dodavatele.

3. Poskytnutí informace o akceptování/neakceptování námětu k zapracování do budoucích verzí.

6. Sankce za nedodržení výše uvedených termínů:

Za každou započatou hodinu překročení mezních termínů chyb v kategoriích A, B, C má Zadavatel právo na smluvní pokutu 500 Kč.

8. Požadavky na technický popis řešení v nabídce

1. Specifikace předmětu plnění

1. Přehled plnění požadovaných minimálních parametrů

Dodavatel vloží vyplněný tento dokument doplněný u jednotlivých položek označených jako „Minimální požadavky …“.

2. Technický popis řešení

   1. Grafické schéma a podrobný popis architektury řešení.

   2. Grafické schéma bude poskytovat ucelený přehled architektury řešení, zejména

- interní vazby jednotlivých částí - datový a logický model a

- externí vazby řešení na AIS Zadavatele.

Grafické schéma architektury řešení bude doplněno přehledným popisem řešení v souladu se strukturou požadavků definovaných v tomto dokumentu.

2. Dále Dodavatel uvede detailní popis API rozhraní řešení pro napojení stávajících IS Zadavatele.

3. Počet a identifikace poddodavatelů.

4. Popis řešení „Jednotná správa řešení“ v rozsahu nejvýše 2 stránek formátu A4, dle podmínek uvedených v ZD.

5. Rozsah školení vč. uvedení počtu dní školení navrženého Dodavatelem

6. Xxxxx Xxxxxxxx řízení projektu a Harmonogramu projektu.

Strana 1