SMLOUVA O DÍLO. Programové vybavení pro výkon státní správy v oblasti památkové péče

Smlouva o dílo uzavřená na základě nadlimitní veřejné zakázky zadávaná v otevřeném řízení s názvem „Programové vybavení pro výkon státní správy v oblasti památkové péče“

SMLOUVA O DÍLO „Programové vybavení pro výkon státní správy v oblasti památkové péče“ uzavřená níže uvedeného dne, měsíce a roku podle § 536 a násl. zákona č. 513/1991 Sb., obchodního zákoníku, ve znění pozdějších předpisů a podle zákona č. 121/2000 Sb. (autorský zákon), ve znění pozdějších předpisů

Čl. 1. Smluvní strany 1.1. Plzeňský kraj se sídlem: Škroupova 18, 306 13 Plzeň IČ:

70890366

DIČ:

CZ 70890366

zastoupený:

Milanem Chovancem, hejtmanem Plzeňského kraje

na základě

usnesení Rady Plzeňského kraje č. 5980/12 ze dne 25.06.2012 pověřen

k podpisu:

Ivo Grüner, náměstek hejtmana

bankovní spojení: č.ú.:

Raiffeisenbank a.s., pobočka Plzeň

1083003606/5500

kontaktní osoba:

Norbert Szabó, vedoucí oddělení aplikací a databází, odbor informatiky,

Krajský úřad Plzeňského kraje telefon: +420 377 195 283, +420 602 195 024 e-mail: [email protected] (dále jen „objednatel“, „zadavatel“) a

1.2. Obchodní jméno: Softech, spol. s r.o. se sídlem / místem podnikání: Denisovo nábřeží 6, 301 00 Plzeň IČ:

45330018

DIČ:

CZ45330018

zastoupený/jednající: RNDr. Pavel Mach bankovní spojení: č.ú.:

Raiffeisenbank a.s.

68009001/5500

zapsán v obchodním rejstříku, vedeném Krajským soudem v Plzni, oddíl C, vložka č. 1522 kontaktní osoba:

RNDr. Pavel Mach

telefon:

377 226 294

e-mail:

[email protected]

(dále jen „zhotovitel“, „uchazeč“)

1


Pokyn pro uchazeče: Při zpracování návrhu smlouvy jako součásti nabídky na veřejnou zakázku „Programové vybavení pro výkon státní správy v oblasti památkové péče“ doplní uchazeči pouze ty údaje, které jsou relevantní vzhledem k charakteru jejich právní formy, údaje týkající se jiné právní formy nebudou v nabídce obsaženy. Tato smlouva se uzavírá v návaznosti na nadlimitní veřejnou zakázku „Programové vybavení pro výkon státní správy v oblasti památkové péče“, zadávanou objednatelem jakožto zadavatelem v otevřeném zadávacím řízení podle § 27 a násl. zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů. Jedná se o veřejnou zakázku realizovanou v rámci projektu Plzeňského kraje s názvem "ICT služby technologického centra Plzeňského kraje – části I., III., IV. a V.“ Výzvy č. 08 na „Rozvoj služeb eGovernementu v krajích“ v rámci Integrovaného operačního programu (IOP). Projekt registrační číslo CZ.1.06/2.1.00/08.07231. Nabídka uchazeče byla zadavatelem vybrána jako nabídka nejvhodnější usnesením Rady Plzeňského kraje č. 5980/12 ze dne 25.06.2012.

Čl. 2. Předmět smlouvy 2.1.1. Touto smlouvou se zhotovitel zavazuje provést řádně a včas pro objednatele dílo spočívající ve vytvoření systému „Programové vybavení pro výkon státní správy v oblasti památkové péče“ v souladu s Technickou dokumentací zadavatele /objednatele/ , uvedenou v příloze č. 1 této smlouvy a nabídkou uchazeče /zhotovitele/, uvedenou v příloze č. 2 této smlouvy.

2.2. Předmětem díla jsou následující činnosti zhotovitele: a) Zhotovení programového vybavení pro výkon státní správy v oblasti památkové péče se zárukou 3 roky. Jedná se o řešení, pokrývající svojí funkčností veškeré agendy na úrovni krajských úřadů (dále jen KÚ), ale především zajišťující a plně pokrývající metodiku výkonu správních úkonů směrem k obcím 3. stupně (tedy obcí s rozšířenou působností), dle přílohy č. 1 – Technické dokumentace, včetně poskytnutí neomezené licence pro jeho používání. b) Implementace programového vybavení do infrastruktury zadavatele. Před zahájením samotné implementace je uchazeč povinen předložit zadavateli prováděcí dokumentaci, v níž bude uvedeno, jakým způsobem bude provedena implementace dodávaného programového vybavení do infrastruktury zadavatele (do HW a SW prostředí). Řešitel je povinen dodržet základní systémovou platformu, definovanou v příloze č.1 – Technické dokumentaci. c) Zajištění integračních vazeb na příslušné subsystémy třetích stran – podatelna AthenA, systém autentifikace a autorizace (Active Directory, single sign-on modul, ePusa), systém dotačních titulů, Portál Plzeňského kraje, katastr nemovitostí, územně identifikační registr, GIS, Monumnet - systém NPÚ, Google maps. Integrační vazby jsou popsány v příloze č. 1 – Technické dokumentaci. d) Zajištění vazby programového vybavení na systém základních registrů veřejné správy (viz zákon č. 111/2009 Sb. v platném znění) včetně zajištění souladu programového vybavení s požadavky zákona o základních registrech.

2


e) Vytvoření videokurzu a e-learningového kurzu pro užívání programového vybavení pro výkon státní správy v oblasti památkové péče. f)

Vytvoření dokumentace uživatelské a dokumentace pro správce programového vybavení pro výkon státní správy v oblasti památkové péče.

g) Vytvoření on-line nápovědy pro programové vybavení pro výkon státní správy s pracovními postupy (odděleně pro procesy KÚ a pro procesy ORP). h) Proškolení administrátorů programového vybavení – 3 osoby z řad zaměstnanců Plzeňského kraje v předpokládaném rozsahu 8 hodin. i)

Proškolení uživatelů programového vybavení – v termínu 1x pro zaměstnance Krajského úřadu Plzeňského kraje a 2x pro zaměstnance obcí 3. stupně. Všechny tyto termíny proškolení musejí proběhnout nejpozději do 1 měsíce od uvedení do provozu. Každé školení se předpokládá v rozsahu 8 hodin.

j)

Transformace dat ze stávajícího systému Kultura. Data pro transformaci jsou v relační databázi MS SQL 2000 zadavatele. Jejich stávající struktura a popis požadavků na novou datovou základnu je součástí příloh této zadávací dokumentace.

k) Vytvoření nových šablon dokumentů (nebo transformace původních) nezbytných pro úkony státní správy v oblasti památkové péče tak, aby byla zajištěna jejich použitelnost v novém programu. Rozsah a oblasti dokumentů jsou uvedeny v příloze č.1 – Technická dokumentace . l)

Vytvoření popisu architektury programového vybavení pro výkon státní správy v oblasti památkové péče s detailním popisem jednotlivých rozhraní a vazeb tak, aby se s pomocí tohoto popisu byla na řešení schopna napojit třetí strana i bez asistence dodavatele.

2.2.1. Předmět smlouvy rovněž obsahuje plnění, které není uvedeno v příloze č. 1 Technické dokumentaci, ale jehož realizace je nezbytná pro provedení díla, tj. pro řádné a včasné dokončení díla v souladu s touto smlouvou. Zahrnuje veškerá plnění včetně software pro zajištění 100% funkčnosti a provozuschopnosti aplikace.

Čl. 3. Doba a místo plnění 3.1.1. Plnění díla bude zahájeno ihned po uzavření této smlouvy.

3.2. Místo plnění: 3.2.1. Místem plnění díla je území Plzeňského kraje.

3.3. Doba dokončení díla: 3.3.1. Řádně zhotovené a dokončené dílo bude předáno objednateli nejpozději do čtyř kalendářních měsíců od data uzavření této smlouvy.

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

3


4.1.2. Při zhotovování díla se zhotovitel zavazuje počínat si s odbornou péčí tak, aby byl zcela naplněn předmět a účel smlouvy. 4.1.3. Zhotovitel je povinen vynaložit maximální úsilí, aby docílil nejlepšího možného výsledku při plnění předmětu této smlouvy prostřednictvím využití svých znalostí a zkušeností.

4.1.4. Při provádění díla postupuje zhotovitel samostatně, je však vázán případnými písemnými pokyny objednatele. Zhotovitel je povinen bez zbytečného odkladu písemně upozornit objednatele na nevhodnost jeho pokynů k provedení díla. Pokud nevhodné pokyny brání v řádném provádění díla, je zhotovitel povinen v nezbytně nutném rozsahu přerušit provádění díla do doby změny pokynů objednatele nebo písemného sdělení, že objednatel trvá na provádění díla dle svých pokynů. Zhotovitel nemá nárok na náhradu nákladů spojených s přerušením provádění díla. 4.1.5. Zhotovitel je povinen v průběhu provádění díla dodržovat obecně závazné předpisy a normy, postupovat s náležitou odbornou péčí, podle nejlepších znalostí a schopností, sledovat a chránit oprávněné zájmy objednatele. 4.1.6. Zhotovitel je povinen v průběhu provádění díla neprodleně informovat objednatele o všech skutečnostech, které mají nebo mohou mít vliv na provedení díla. 4.1.7. Pokud objednatel zjistí, že zhotovitel provádí dílo v rozporu se svými povinnostmi, je oprávněn požadovat, aby zhotovitel odstranil v objednatelem stanovené lhůtě vzniklé vady a dílo prováděl řádným způsobem. 4.1.8. Zhotovitel se zavazuje v průběhu provádění díla poskytovat objednateli průběžné informace o stavu plnění díla, a to 1 x za 14 dnů emailovou zprávou, zaslanou kontaktní osobě objednatele. 4.1.9. Objednatel se zavazuje řádně a včas dokončený předmět smlouvy od zhotovitele protokolárně převzít a zaplatit zhotoviteli sjednanou cenu.

4.2. Součinnost 4.2.1. Objednatel požaduje, aby maximum práce odvedl zhotovitel samostatně, bez zatěžování pracovníků objednatele. Součinnost objednatele bude omezena na nezbytnou míru a bude se vztahovat především na schvalování výstupů zhotovitele v předem definovaných kontrolních dnech a na nezbytnou IT podporu nutnou k nasazení řešení a realizaci vazeb. 4.2.2. Rozsah součinnosti bude odsouhlasen při zahájení realizace, včetně termínů jejího poskytování. 4.2.3. V případě následného požadavku zhotovitele na součinnost nad dohodnutý rámec má objednatel právo součinnost odmítnout, případně ji poskytnout v termínu a rozsahu dle svých možností, a to bez dopadu na harmonogram realizace a z něj vyplývající sankce za nedodržení termínů. 4.2.4. Neposkytnutí součinnosti jako důvod pro posun smluvních termínů bude akceptován pouze tam, kde byla součinnost objednatelem přislíbena při zahájení realizace.

4


Čl. 5. Cena díla 5.1.1. Cena za zhotovení díla představuje objednatelem /jakožto zadavatelem/ akceptovanou nabídkovou cenu, předloženou zhotovitelem /jakožto uchazečem/ v nabídce na veřejnou zakázku „Programové vybavení pro výkon státní správy v oblasti památkové péče“. 5.1.2. Zhotovitel výslovně prohlašuje, že nabídková cena a cena díla obsahuje veškeré práce a dodávky, poplatky a jiné náklady nezbytné pro řádnou a úplnou realizaci sjednaného předmětu plnění a veškeré náklady včetně všech rizik a vlivů souvisejících s plněním předmětu smlouvy. 5.1.3. Objednatel a zhotovitel se dohodli, že cena za řádné a včasné provedení celého díla, specifikovaného v čl. 2 této smlouvy, činí celkem částku: 1.397.400,- Kč včetně DPH, přičemž cena bez DPH činí 1.164.500,- Kč, sazba DPH činí 20 %, výše DPH činí 232.900,- Kč. 5.1.4. Tato cena je stanovena jako cena konečná a úplná. 5.1.5. Zhotovitel není oprávněn požadovat po objednateli poskytnutí zálohy. 5.1.6. Zhotovitel na sebe výslovně bere odpovědnost za to, že sazba a výše daně z přidané hodnoty bude stanovena v souladu s platnými právními předpisy. 5.1.7. Daň z přidané hodnoty bude připočtena k ceně díla ve výši dle právní úpravy platné ke dni uskutečnění zdanitelného plnění. 5.1.8. Sjednaná celková cena uvedená v odst. 3. tohoto článku smlouvy je cenou nejvýše přípustnou, kterou je možné překročit pouze v případě zvýšení sazby DPH, a to tak, že zhotovitel ke sjednané ceně bez DPH připočítá DPH v procentní sazbě odpovídající zákonné úpravě účinné k datu uskutečnitelného zdanitelného plnění.

Čl. 6. Platební podmínky 6.1.1. Cena díla bude objednatelem uhrazena jednorázovou platbou na základě zhotovitelem vystavené faktury. 6.1.2. Fakturu je zhotovitel oprávněn vystavit nejdříve následující den po dni uskutečnění zdanitelného plnění, jímž se pro účely této smlouvy rozumí řádné dodání předmětu díla definovaného v čl. 2 této smlouvy. 6.1.3. Podkladem pro vystavení faktury je podepsaný protokol o předání a převzetí předmětu díla. 6.1.4. Splatnost faktury činí 60 dnů ode dne jejího prokazatelného doručení na adresu sídla objednatele. 6.1.5. Faktura bude mít náležitosti daňového dokladu dle platných právních předpisů (zákona č. 563/1991 Sb., o účetnictví, v platném znění a zákona č. 235/2004 Sb., o dani z přidané hodnoty, v platném znění).

5


6.1.6. Faktury musí obsahovat číslo smlouvy, číslo účtu zhotovitele a všechny údaje uvedené v § 28 odst. 2 zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů, a v § 13a obchodního zákoníku. 6.1.7. Součástí faktury bude specifikace dodaného plnění tak, aby byla v souladu s platnými účetními a daňovými předpisy, a to za účelem řádného vedení evidence majetku objednatele v souladu s těmito právními předpisy. 6.1.8. V případě, že faktura – daňový doklad nebude obsahovat stanovené náležitosti nebo v něm nebudou správně uvedené údaje, je objednatel oprávněn ji vrátit ve lhůtě splatnosti zpět zhotoviteli s uvedením chybějících náležitostí nebo nesprávných údajů. V takovém případě přeruší běh lhůty splatnosti a nová lhůta splatnosti počne běžet doručením opravené faktury – daňového dokladu. 6.1.9. Po vzniku práva fakturovat je zhotovitel povinen vystavit a objednateli předat faktury v trojím vyhotovení. 6.1.10. Cena bude zhotoviteli zaplacena bezhotovostní formou převodem na jeho bankovní účet. Faktura je považována za proplacenou okamžikem odepsání příslušné částky z účtu objednatele ve prospěch zhotovitele. 6.1.11. Dojde-li ke dni uskutečnění zdanitelného plnění ke změně sazby DPH, bude zhotovitel fakturovat objednateli cenu s DPH ve výši odpovídající platné právní úpravě ke dni uskutečnění zdanitelného plnění. 6.1.12. Každý originální účetní doklad bude obsahovat informaci, že se jedná o projekt IOP a musí být označen názvem a číslem projektu (registrační číslo CZ.1.06/2.1.00/08.07231). 6.1.13. Pokud to bude možné, bude účetnictví vedeno v elektronické formě. V souladu s předpisy ES se účetní záznamy o účetních operacích budou v co největší možné míře uchovávat v elektronické formě, minimálně do 31. 12. 2021. 6.1.14. Zhotovitel souhlasí s tím, aby subjekty oprávněné dle zák. č. 320/2001 Sb., o finanční kontrole ve veřejné správě a o změně některých zákonů (zákon o finanční kontrole), ve znění pozdějších předpisů, provedly finanční kontrolu závazkového vztahu vyplývajícího ze smlouvy s tím, že se zhotovitel podrobí této kontrole, a bude spolupůsobit jako osoba povinná ve smyslu ust. § 2 písm. e) uvedeného zákona při výkonu finanční kontroly prováděné v souvislosti s úhradou služeb z veřejných výdajů. 6.1.15. Zhotovitel se zavazuje archivovat originální vyhotovení smlouvy včetně jejích dodatků, originály účetních dokladů a dalších dokladů vztahujících se k realizaci předmětu smlouvy minimálně do 31.12.2021. Po tuto dobu je zhotovitel povinen umožni osobám oprávněným k výkonu kontroly projektů provést kontrolu dokladů souvisejících s plněním této smlouvy. 6.1.16. Zhotovitel je povinen všechny písemné zprávy, písemné výstupy a prezentace opatřit vizuální identitou projektů dle Pravidel pro provádění informačních a propagačních opatření (viz příloha č. 4 Příručky pro žadatele a příjemce finanční podpory v rámci Integrovaného operačního programu – Výzva č. 08 na Rozvoj služeb eGovernmentu v krajích). Zhotovitel prohlašuje, že ke dni uzavření této smlouvy se s těmito pravidly seznámen. V případě, že v průběhu plnění této smlouvy dojde ke změně těchto pravidel, zavazuje se objednatel o této skutečnosti zhotovitele bezodkladně informovat.

6


Čl. 7. Předání díla 7.1.1. Zhotovitel splní svoji povinnost zhotovit dílo jeho řádným a včasným dokončením v souladu s podmínkami této smlouvy a předáním hotového díla objednateli. 7.1.2. Objednatel prohlašuje, že převezme pouze dokončené dílo bez zjevných vad, nedodělků a podstatných vad bránících funkcionalitě předávaného díla. V opačném případě si objednatel vyhrazuje právo převzetí díla odmítnout, bez nároku na navýšení ceny díla. 7.1.3. Předání a převzetí díla proběhne na základě porovnání skutečných vlastností díla dle specifikace díla uvedené v čl. 2. této smlouvy. Plnění bude potvrzeno podpisem protokolu o předání Objednatelem. Součástí protokolu o předání je jednoznačná identifikace předávaného díla. 7.1.4. Akceptaci díla musí předcházet úspěšný převod dat a jejich vyčištění zhotovitelem dle článku 2.2 písm. j) této smlouvy a dle bodu 1.13 přílohy č. 1 této smlouvy – Technické dokumentace. Předávací protokol o úspěšném převodu dat bude podkladem pro akceptaci díla objednatelem. 7.1.5. Zjistí-li objednatel nedostatky, nedodělky, či vady, oznámí to písemnou formou bez zbytečného odkladu zhotoviteli. 7.1.6. Místem předání díla je sídlo objednatele na adrese Škroupova 18, 306 13 Plzeň. Za objednatele je oprávněn hotové dílo převzít a akceptační protokol podepsat Bc. Eliška Pečenková, pověřená zastupováním vedoucího odboru informatiky Krajského úřadu Plzeňského kraje. 7.1.7. Vlastnické právo k dílu přechází na objednatele okamžikem předání díla objednateli. Práva z poskytnuté licence objednatel nabývá okamžikem převzetí díla od zhotovitele.

Čl. 8. Záruka za dílo 8.1.1. Zhotovitel poskytuje objednateli záruku v délce trvání 3 let. Dílo dle této smlouvy bude ke dni předání a převzetí objednatelem způsobilé k řádnému užití a bude mít vlastnosti stanovené touto smlouvou. 8.1.2. Zhotovitelem poskytovaná záruka se vztahuje na kompletní funkčnost díla, jakož i na jeho vlastnosti požadované objednatelem. 8.1.3. Záruční doba začíná běžet ode dne převzetí díla objednatelem. Záruční doba se prodlužuje o dobu, po kterou mělo dílo vadu bránící jeho řádnému užívání objednatelem, nebo po kterou bylo plnění mimo provoz z důvodu vady, na kterou se vztahuje záruka. 8.1.4. Veškeré zjištěné nedostatky, nedodělky a vady díla, které se vyskytnou v záruční době, je zhotovitel povinen bez zbytečného odkladu písemně oznámit objednateli. 8.1.5. Vadou díla se pro účely této smlouvy rozumí rozpor mezi sjednanými podmínkami provedení díla a skutečným stavem díla. 8.1.6. Objednatel má vůči zhotoviteli tato práva z odpovědnosti za vady: •

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

7


•

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

•

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

•

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

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

Čl. 9. Licenční ujednání 9.1.1. Zhotovitel v rámci plnění předmětu této smlouvy vytvoří dílo podléhající ochraně podle zákona č. 121/2000 Sb. (autorský zákon), a tak poskytuje objednateli licenci - tj. oprávnění k výkonu práva užívat jím vytvořené autorské dílo.

9.2. Zhotovitel poskytuje licenci jako: nevýhradní licenci k veškerým známým způsobům užití takového díla, zejména, nikoliv však výlučně k účelu, ke kterému bylo takové dílo zhotovitelem vytvořeno v souladu se smlouvou a to v rozsahu minimálně nezbytném pro řádné užívání díla objednatelem, licenci omezenou územím Plzeňského kraje a neomezenou množstevním rozsahem a rovněž tak neomezenou způsobem nebo rozsahem užití; licenci udělenou na dobu určitou, a to po celou dobu trvání majetkových práv k dílu; licenci převoditelnou a postupitelnou, tj. která je udělena s právem udělení bezúplatné podlicence či postoupení licence třetí osobě z řad obcí v Plzeňském kraji; licenci, kterou není objednatel povinen využít. 9.2.1. Povinnost týkající se licence platí pro zhotovitele i v případě zhotovení části díla subdodavatelem. 9.2.2. Licence je poskytnutá v maximálním rozsahu povoleném platnými právními předpisy. 9.2.3. Zhotovitel je povinen zajistit, aby výsledkem jeho plnění nebo jakékoliv jeho části nebyla porušena práva třetích osob. Pro případ, že užíváním předmětu plnění nebo jeho dílčí části nebo prostou existencí předmětu plnění nebo jeho dílčí části budou v důsledku porušení povinností zhotovitele dotčena práva třetích osob, nese zhotovitel vedle odpovědnosti za takovéto vady plnění i odpovědnost za veškeré škody, které tím objednateli vzniknou.

9.3. Zhotovitel uděluje objednateli oprávnění dílo (nebo jeho dílčí část), které podléhá ochraně podle zákona č. 121/2000 Sb. (autorský zákon), upravovat, zpracovávat, měnit jeho název, a oprávnění dílo spojit s dílem jiným a zařadit jej do díla souborného. 8


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

Čl. 10.

Subdodávky

10.1.1. Zhotovitel nebude pro předmět smlouvy využívat služeb žádného subdodavatele.

Čl. 11.

Odpovědnost za škodu

11.1.1. Smluvní strany nesou odpovědnost za způsobenou škodu v rámci platných právních předpisů a této smlouvy. 11.1.2. Smluvní strany se zavazují k vyvinutí maximálního úsilí k předcházení škodám a k minimalizaci vzniklých škod.

Čl. 12.

Sankční ujednání

12.1.1. Dojde-li k prodlení s úhradou daňového dokladu - faktury, je zhotovitel oprávněn účtovat objednateli úrok z prodlení ve výši 0,05 % z dlužné částky za každý započatý den prodlení po termínu splatnosti až do doby zaplacení dlužné částky. 12.1.2. Nesplní-li zhotovitel svůj závazek v rozsahu a čase plnění sjednaném touto smlouvou, je oprávněn objednatel požadovat po zhotoviteli zaplacení smluvní pokuty ve výši 0,5 % ze sjednané ceny plnění dle této smlouvy za každý započatý den prodlení, až do řádného dokončení a předání celého předmětu plnění a zhotovitel je povinen takto požadovanou smluvní pokutu zaplatit. 12.1.3. Nesplní-li zhotovitel v dohodnutém termínu svůj závazek odstranit vady a nedodělky vytknuté při převzetí díla nebo v průběhu záruční doby, je objednatel oprávněn požadovat na zhotoviteli zaplacení smluvní pokuty ve výši 0,05 % ze sjednané ceny předmětu plnění za každý započatý den prodlení až do jejich úplného odstranění a zhotovitel se zavazuje takto požadovanou smluvní pokutu objednateli zaplatit. 12.1.4. Zaplacením smluvní pokuty není dotčeno právo poškozené strany na náhradu vzniklé škody. Výši smluvních pokut považují obě smluvní strany shodně za přiměřené. 12.1.5. Smluvní pokuty a úroky z prodlení podle tohoto článku jsou splatné do 30 dnů ode dne doručení jejich vyúčtování.

Čl. 13.

Ukončení smlouvy

13.1.1. Tuto smlouvu lze ukončit dohodou smluvních stran. Dohoda o ukončení smluvního vztahu musí být písemná, jinak je neplatná. 13.1.2. Od této smlouvy lze odstoupit v případě podstatného porušení povinností jednou smluvní stranou, jestliže je takové porušení povinnosti označeno za podstatné touto smlouvou nebo zákonem. Odstoupení od smlouvy je účinné dnem doručení písemného oznámení o odstoupení druhé smluvní straně.

9


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

dodání vadného předmětu plnění,

•

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

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

prodlení se zaplacením vyfakturované ceny díla (jeho části) delší než třicet (30) kalendářních dnů.

13.1.5. Porušení jakékoliv jiné povinnosti objednatele nebo zhotovitele, vyplývající z této smlouvy, je třeba splnit v dodatečné přiměřené lhůtě k tomu poskytnuté. 13.1.6. Odstoupením od této smlouvy nejsou dotčena ustanovení týkající se smluvních pokut a úroků z prodlení a stejně tak práva a povinnosti smluvních stran vzniklá do okamžiku účinnosti odstoupení od smlouvy.

Čl. 14.

Závěrečná ustanovení

14.1.1. Práva a povinnosti smluvních stran v této smlouvě výslovně neupravené a z ní vyplývající nebo s ní související se řídí zákonem č. 513/1991 Sb., obchodní zákoník, ve znění pozdějších předpisů a zákonem č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon), ve znění pozdějších předpisů. 14.1.2. V případě rozporu technické dokumentace objednatele (zadavatele) a technické nabídky (technického řešení) zhotovitele platí, není-li uvedeno jinak, technická dokumentace zadavatele tj. příloha č. 1 – Technická dokumentace. 14.1.3. Pokud jakýkoli závazek dle smlouvy nebo kterékoli ustanovení smlouvy je nebo se stane neplatným či nevymahatelným, nebude to mít vliv na platnost a vymahatelnost ostatních závazků a ustanovení dle smlouvy a smluvní strany se zavazují takovýto neplatný nebo nevymahatelný závazek či ustanovení nahradit novým, platným a vymahatelným závazkem, nebo ustanovením, jehož předmět bude nejlépe odpovídat předmětu a ekonomickému účelu původního závazku či ustanovení. 14.1.4. Vzhledem k veřejnoprávnímu charakteru objednatele zhotovitel výslovně souhlasí se zveřejněním smluvních podmínek obsažených v této smlouvě v rozsahu a za podmínek vyplývajících z příslušných právních předpisů (zejména zákon č. 106/1999 Sb., o svobodném přístupu k informacím, ve znění pozdějších předpisů). 14.1.5. Tato smlouva je vyhotovena ve čtyřech (4) stejnopisech, z nichž každý má platnost originálu. Každá ze smluvních stran obdrží po dvou vyhotoveních. 14.1.6. Tuto smlouvu je možno platně měnit pouze na základě dohody smluvních stran, formou písemných a vzestupně číslovaných dodatků, podepsaných oběma smluvními stranami. 14.1.7. Tato smlouva nabývá platnosti i účinnosti dnem jejího podpisu oběma smluvními stranami.

10


14.1.8. Uzavření této smlouvy bylo v souladu s ustanovením § 23 zákona č. 129/2000 Sb., o krajích (krajské zřízení), ve znění pozdějších předpisů, schváleno usnesením Rady Plzeňského kraje č. 5980/12 ze dne 25.06.2012.

14.2. Nedílnou součástí této smlouvy jsou její přílohy: •

příloha č.1 Technická dokumentace předmětu díla

•

příloha č.2 Harmonogram

•

příloha č.3 Nabídka uchazeče v části technické řešení

14.2.1. Smluvní strany prohlašují, že tuto smlouvu před jejím podpisem přečetly, zcela rozumí jejímu obsahu a s celým jejím obsahem souhlasí. Dále prohlašují, že tato smlouva vyjadřuje jejich pravou a svobodnou vůli. Na důkaz toho připojují vlastnoruční podpisy svých oprávněných zástupců.

V Plzni dne ………………..

V Plzni dne ………………..

Za zhotovitele

Za objednatele

……………………………………

……………………………………

RNDr. Pavel Mach

Ivo Grüner

jednatel společnosti Softech spol. s r.o.

náměstek hejtmana Plzeňského kraje

11

Příloha č. 1 Smlouvy o dílo – Technická dokumentace nadlimitní veřejné zakázky zadávané v otevřeném řízení „Programové vybavení pro výkon státní správy v oblasti památkové péče“

Příloha č. 1 Smlouvy o dílo – Technická dokumentace

Technická dokumentace smlouvy o dílo k nadlimitní veřejné zakázce s názvem

Programové vybavení pro výkon státní správy v oblasti památkové péče

1


Obsah: 1

ZÁKLADNÍ INFORMACE ........................................................................................................................... 4 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15

OBSAH A CÍL ZADÁNÍ PROJEKTU ......................................................................................................................... 4 PLATFORMA/KLIENT ....................................................................................................................................... 4 AUTOMATIZOVANÁ TVORBA DOKUMENTŮ .......................................................................................................... 4 ZÁKLADNÍ SADA VÝCHOZÍCH ŠABLON .................................................................................................................. 4 KDO BUDE PRODUKT VYUŽÍVAT ......................................................................................................................... 4 FUNKCE ....................................................................................................................................................... 4 ZÁKLADNÍ SPRÁVA NUTNÉ DATOVÉ ZÁKLADNY ...................................................................................................... 5 DOKUMENTACE A DALŠÍ PŘÍLOHY ...................................................................................................................... 5 SPRÁVA OBRAZOVÉ DOKUMENTACE ................................................................................................................... 5 VAZBA NA PRODUKTY TŘETÍCH STRAN ............................................................................................................ 5 VAZBA NA SYSTÉM ZÁKLADNÍCH REGISTRŮ VEŘEJNÉ SPRÁVY ............................................................................... 5 DATA MINING........................................................................................................................................... 6 TRANSFORMACE A KONSOLIDACE STÁVAJÍCÍCH DAT .......................................................................................... 6 SERVEROVÁ PLATFORMA/TECHNOLOGIE ........................................................................................................ 6 SHRNUTÍ ................................................................................................................................................. 6

2

HISTORICKÉ KOŘENY PROJEKTU .............................................................................................................. 7

3

SOUČÁSTI ŘEŠENÍ .................................................................................................................................... 7

4

REFERENCE A ZNALOSTNÍ PŘEDPOKLADY ................................................................................................ 7

5

HARMONOGRAM POSTUPU ŘEŠENÍ ........................................................................................................ 7

6

JEDNOTLIVÉ SOUČÁSTI ŘEŠENÍ DLE HARMONOGRAMU .......................................................................... 8 6.1 DATOVÁ ZÁKLADNA ........................................................................................................................................ 8 6.1.1 Hlavní nevýhody současné datové základny jsou: ........................................................................... 8 6.1.2 Požadavky na novou datovou základnu jsou následující: ................................................................ 9 6.2 ZÁKLADNÍ RÁMEC PRO AUTENTIZACI A AUTORIZACI ............................................................................................... 9 6.2.1 Základní rámec a vzhled .................................................................................................................. 9 6.2.2 Autentizace...................................................................................................................................... 9 6.2.3 Autorizace ....................................................................................................................................... 9 6.2.4 Administrace ................................................................................................................................... 9 6.2.5 Auditní log ..................................................................................................................................... 10 6.3 VYTVOŘENÍ ZÁKLADNÍCH AGEND ..................................................................................................................... 10 6.3.1 Památky ........................................................................................................................................ 10 6.3.2 Vlastníci ......................................................................................................................................... 10 6.3.3 Památkově chráněná území .......................................................................................................... 11 6.3.4 Ochranná pásma ........................................................................................................................... 11 6.4 ZAČLENĚNÍ DO UIR, KATASTRU, ZÁKLADNÍCH REGISTRŮ ....................................................................................... 11 6.4.1 UIR ................................................................................................................................................. 11 6.4.2 RÚIAN ............................................................................................................................................ 11 6.4.3 Katastr nemovitostí ....................................................................................................................... 11 6.4.4 Přečíslování parcelních čísel pozemků ........................................................................................... 12 6.5 SYSTÉM EVIDENCE OBRAZOVÝCH PŘÍLOH ........................................................................................................... 12 6.5.1 Základní cíle ................................................................................................................................... 12 6.6 INTERFACE PRO SPOLUPRÁCI S INTERNETOVÝM PORTÁLEM ................................................................................... 12 6.6.1 Vazba na internetový portál je ve třech oblastech: ....................................................................... 12 6.6.2 Funkčnost spočívá ve vytvoření těchto funkčností: ....................................................................... 12 6.7 SPRÁVA VŠECH SOUVISEJÍCÍCH ČÍSELNÍKŮ .......................................................................................................... 12 6.7.1 Základní pomocné číselníky a agendy ........................................................................................... 13 6.8 ŘEŠENÍ PODATELNY ...................................................................................................................................... 13 6.8.1 Řešení číselných řad....................................................................................................................... 13 6.8.2 Vazby na jiné podatelny ................................................................................................................ 13 6.8.3 ATHENA ......................................................................................................................................... 13 6.8.4 Identifikátory podání ..................................................................................................................... 14

2

Příloha č. 1 Smlouvy o dílo – Technická dokumentace nadlimitní veřejné zakázky zadávané v otevřeném řízení „Programové vybavení pro výkon státní správy v oblasti památkové péče“ 6.8.5 Databáze žadatelů ........................................................................................................................ 14 6.9 TECHNOLOGIE ŠABLON .................................................................................................................................. 14 6.9.1 Požadavky na systém správy šablon ............................................................................................. 14 6.9.2 Platforma....................................................................................................................................... 14 6.10 AGENDY VYJÁDŘENÍ A ROZHODNUTÍ ............................................................................................................ 15 6.10.1 Rozhodnutí k památkám .......................................................................................................... 15 6.10.2 Rozhodnutí k pam.chr.území .................................................................................................... 15 6.10.3 Rozhodnutí k ochrannému pásmu ............................................................................................ 15 6.10.4 Ostatní agenda k památkám .................................................................................................... 15 6.10.5 Ostatní agenda ......................................................................................................................... 15 6.11 AGENDY ROZHODNUTÍ O FINANČNÍM PŘÍSPĚVKU ........................................................................................... 16 6.11.1 Rozhodnutí o finančním příspěvku............................................................................................ 16 6.12 AGENDA SYSTÉMU DOTACÍ ........................................................................................................................ 16 6.12.1 Systém dotací ........................................................................................................................... 16 6.13 VAZBA NA EXTERNÍ SYSTÉM SPRÁVY DOTACÍ.................................................................................................. 16 6.13.1 Import dat bude probíhat ve dvou rovinách ............................................................................. 16 6.14 PŘÍLOHY K VYJÁDŘENÍM/ROZHODNUTÍM A JEJICH SPRÁVA ............................................................................... 17 6.14.1 Přílohy budou k dispozici v těchto agendách ............................................................................ 17 6.15 APLIKACE AUTOMATICKÉ TVORBY DOKUMENTŮ KE KAŽDÉ AGENDĚ A JEJICH VERZOVÁNÍ ......................................... 17 6.15.1 Platforma .................................................................................................................................. 17 6.15.2 Postup práce s aplikací měl být dle uvedeného schématu: ...................................................... 17 6.15.3 Požadavky na systém generování dokumentů ......................................................................... 17 6.16 DOPLNĚNÍ HLAVNÍCH ČÍSELNÍKŮ O VAZBY NA KARTOGRAFICKÁ DATA – GOOGLE MAPS, GIS .................................... 18 6.16.1 GIS............................................................................................................................................. 18 6.16.2 Požadavky ................................................................................................................................. 18 6.16.3 Google maps ............................................................................................................................. 18 6.17 ŘEŠENÍ PŘÍLOH K HLAVNÍM ČÍSELNÍKŮM ....................................................................................................... 18 6.17.1 Přílohy budou k dispozici v těchto agendách ............................................................................ 18 6.18 ŘEŠENÍ PŘÍLOH K DALŠÍM VÝKONNÝM AGENDÁM ........................................................................................... 18 6.18.1 Přílohy budou k dispozici v těchto agendách ............................................................................ 18 6.19 VAZBA NA SYSTÉM MONUMNET ................................................................................................................ 19 6.19.1 Realizace vazeb na Monumnet spočívá v následujících krocích ............................................... 19 6.20 ZÁKLADNÍ SESTAVY .................................................................................................................................. 19 6.20.1 Požadavky na základní reporty jsou následující ....................................................................... 19 7

SERVEROVÁ A KLIENTSKÁ PLATFORMA ................................................................................................. 19 7.1 KLIENTSKÁ PLATFORMA ................................................................................................................................. 19 7.1.1 Prohlížeč ........................................................................................................................................ 19 7.1.2 Tvorba dokumentů ........................................................................................................................ 20 7.2 SERVEROVÁ PLATFORMA ............................................................................................................................... 20 7.3 DATOVÝ SERVER .......................................................................................................................................... 20 7.3.1 Hlavní data .................................................................................................................................... 20 7.3.2 Stávající data ................................................................................................................................. 20 7.3.3 Reporting services ......................................................................................................................... 20 7.4 INTERNETOVÝ SERVER ................................................................................................................................... 20 7.4.1 Webový prostor ............................................................................................................................. 20 7.4.2 Podpůrná platforma ...................................................................................................................... 20 7.5 POŽADAVKY NA BEZPEČNOST PORTÁLU ............................................................................................................. 21

8

DOKUMENTACE A NÁPOVĚDA .............................................................................................................. 21 8.1 8.2 8.3 8.4

9

UŽIVATELSKÁ DOKUMENTACE ......................................................................................................................... 21 DOKUMENTACE PRO SPRÁVCE ........................................................................................................................ 21 BEZPEČNOSTNÍ DOKUMENTACE....................................................................................................................... 21 ONLINE NÁPOVĚDA ...................................................................................................................................... 21

PŘÍLOHY: ............................................................................................................................................... 22

3


1 Základní informace 1.1 Obsah a cíl zadání projektu Cílem zadání je zhotovení programového vybavení pro výkon státní správy v oblasti památkové péče. Jedná se o řešení, pokrývající svojí funkčností veškeré agendy na úrovni krajských úřadů (dále jen KÚ), ale především zajišťující a plně pokrývající metodiku výkonu správních úkonů směrem k obcím 3.stupně (tedy obcí s rozšířenou působností, dále jen ORP), které na obou těchto úrovních zajistí soulad s legislativou. Nové programové vybavení plně nahradí stávající řešení, jehož funkcionalita a datový obsah budou do nového programového vybavení převedeny a rozšířeny v rozsahu této zadávací dokumentace.

1.2 Platforma/klient Celé rozhraní systému musí být přístupné pomocí klienta na bázi webového prohlížeče. Povinně požadovaný je MS Internet Explorer ve verzích 8 a 9, v kterém musí být aplikace plně funkční. Jedná se tedy o čistě internetovou aplikaci, pro klienta jako cloud computing model.

1.3 Automatizovaná tvorba dokumentů Projekt zahrnuje zhotovení produktu, který bude umožňovat automatizovaně produkovat jednotnou správní dokumentaci k jednotlivým úkonům státní správy, a to na základě dat, pořízených do systému jednotlivými subjekty. Dokumentace bude generována na základě uživatelsky definovaných šablon jednotlivých správních dokumentů, zahrnující problematiku k územnímu plánování a prohlašování KP, rozhodnutí k památkám, k národním kulturním památkám, k památkově chráněným územím a k ochranným pásmům. Dále pak dokumentaci k dotačním programům, rozdělování finančních prostředků.

1.4 Základní sada výchozích šablon Součástí dodávky bude základní sada šablon dokumentů, která bude pokrývat potřeby fungování KÚ a ORP. Šablony pro ORP musí být škálovatelné minimálně ve smyslu rozdílných hlaviček a v tom smyslu, že každá ORP bude mít svoji sadu šablon. V současném provozu je celkem cca 85 různých šablon v oblastech památek, oblastí, NKP, archeologie, pásem a ostatní agendy jak pro KÚ, tak pro ORP. Lze postupovat metodou transformace stávajících šablon.

1.5 Kdo bude produkt využívat Za subjekty jsou považováni pracovníci/uživatelé oblasti památkové péče K.Ú, pracovníci jednotlivých ORP, pracovníci pořizující dokumentaci. Vybrané informace ze systému budou produkovány veřejnosti pomocí webového portálu (portál není součástí řešení, pouze poskytnutí dat prostřednictvím definovaného rozhraní a systém pro sofistikovaný výběr dat pro zveřejnění).

1.6 Funkce Pro jednotlivé agendy vyjádření je třeba zajistit příslušné procesní funkce, jako například sledování zákonných termínů pro jednotlivé správní úkony a další související funkce, ať už administrační, tak na úrovni jednotlivých profesí/rolí 4


v systému. Jedná se především o podatelnu, o řešení správy příloh k podáním a k vyjádřením, řešení historizace vývoje automaticky generovaných dokumentů (verzování). Speciálním souborem funkcí je také poměrně úzká vazba na spisovou službu (především z důvodu zamezení zbytečného dvojího pořizování dat). Řešení bude hlídat, aby používání funkcí bylo v souladu s platnou legislativou, tj. nedovolí uživateli provést akci v rozporu se zákonem, hlídá termíny aj.

1.7 Základní správa nutné datové základny Nutnou základnou pro fungování tvorby zmíněných dokumentů musí být samozřejmě zajištěna potřebná agenda správy základních číselníků. Jedná se především o vytvoření datové základny movitých a nemovitých památek, národních kulturních památek (dále jen NKP), pam.chr.území a ochranných pásem spolu s jejich kompletní správou a vzájemnou provázaností. K tomu je třeba provázanost s územně identifikačním registrem a jeho správou na úrovni možnosti správného začlenění památky, pam.chr.území či pásma až na úroveň adresního bodu, včetně ověření v základním registru územní identifikace, adres a nemovitostí (ZRÚIAN). Dále pak je nutné, aby součástí řešení byla správa celé řady návazných číselníků (ukládací znaky, druhy památek, druhy dotací,druhy vlastníků, druhy využití, typy území a dalších cca 20 číselníků nezbytných pro pořizování základních dat). Vybrané číselníky budou platné jen pro definované období, tj. bude nutná jejich historizace.

1.8 Dokumentace a další přílohy Součástí systému by měla být jednotná agenda příloh. Předpokládá se, že u podání, vyjádření a rozhodnutí v jednotlivých oblastech budou (kromě primárních automaticky generovaných dokumentů) přílohy v podobě dokumentace libovolného formátu.

1.9 Správa obrazové dokumentace Zvláštní kapitolu tvoří dokumenty/přílohy k základním kamenům datové základny, kterým jsou památky, pam.chr.území a ochranná pásma. V této oblasti se předpokládá vytvoření sofistikovaného systému evidence obrazové dokumentace. Část obrazové (a i textové) dokumentace bude využita pro prezentaci veřejnosti na turistickém webovém portálu. Podmínkou je přátelská práce s obrazovou dokumentací – hromadný import, nahlížení, miniatury aj.

1.10 Vazba na produkty třetích stran Portál www.turisturaj.cz je jedním z produktů třetích stran, ke kterým je třeba zajistit příslušný interface. Dalšími systémy jsou již zmíněný UIR, dále katastr.úřad, Google maps, GIS, datový sklad a systém Monumnet (produkt NPÚ). Speciální vazbou je vazba na podatelnu (spisová služba).

1.11 Vazba na systém základních registrů veřejné správy Jedná se o vazbu na nový systém, který je ovšem pro jakoukoliv datovou aplikaci v oblasti státní správy stěžejní. Stávající aplikace nemá z pochopitelných důvodů tuto problematiku vůbec řešenu, není tedy na co navazovat. Vazba na základní registry je požadována v rozsahu umožňujícím splnění platné legislativy. Řešení využije jednotné rozhraní pro napojení IS Plzeňského kraje na ZR, bude-li krajem realizováno.

5


1.12 Data mining Pro interní potřeby čerpání dat, přehledů a výkazů se předpokládá zhotovení cca 10 základních interaktivních reportů s možností tisku a exportu do základních přenositelných formátů (PDF, MS Word, MS Excel, CSV). Soubor funkcí pro reporting zahrnuje možnost volby filtrovacích kritérií, především ve vztahu k příslušné ORP. Ukázky reportů současného systému budou uchazečům předloženy na vyžádání.

1.13 Transformace a konsolidace stávajících dat Součástí projektu je převzetí dat (cca 80%) ze stávající datové základny. Jedná se o přípravu modulu, který jednorázově (před vlastním ostrým provozem) přetransformuje aktuální data a tím umožní plynule navázat na stávající provoz (viz historie vývoje dále v textu). V průběhu transformace by také mělo dojít i k odstranění některých duplicit, ke kterým došlo při zadávání dat v průběhu mnoha let práce. Dále je třeba odstranit již nevyužívaná, nebo nežádoucí data. Převod dat včetně jejich čištění zajistí dodavatel vlastními silami na základě instrukcí pracovníků kraje. Z převodu vytvoří dodavatel podrobný předávací protokol, obsahující veškeré modifikace datové základny a jehož potvrzení krajem je podmínkou spuštění produktivního provozu a akceptace díla. Nebude-li ve výjimečných případech dohodnuto jinak, bude dodavatel provádět převod dat mimo pracovní dobu krajského úřadu, tj. v noci nebo o víkendu. Pokud kraj odmítne převzít převedená data z důvodu chyb při převodu, provede dodavatel nový převod a vytvoří nový předávací protokol, a to i opakovaně. Na takovou situaci nebude nahlíženo jako na neposkytnutí součinnosti a veškeré důsledky z případného posunu termínu ponese dodavatel.

1.14 Serverová platforma/technologie Požadavkem je orientace na produkty spol.Microsoft (MS IIS, MS SQL). Zadavatel je vybaven jak potřebnou technikou, systémovou technologií, tak personálním odborným zajištěním podpory a provozu. (Více v sekci platforma).

1.15 Shrnutí Z uvedených informací je zřejmé, že se ve své koncepci nejedná primárně o vytvoření souhrnu funkcí a datových struktur pro evidenci dat památek, ochr.pásem a dalších souvisejících agend a vazeb, ale že tato správa je pouze základem pro vybudování systému pro zprocesování cyklu žadatel – podatelna – vyjádření – rozhodnutí – tvorba dokumentu – distribuce dokumentu k žadateli. Hlavní důraz je kladen na systém automatizovaného systému pro generování výsledných dokumentů včetně řešení systému šablon a verzování jednotlivých dokumentů. Dále je kladen důraz na jednoduchost obsluhy v podobě tenkého/internetového klienta, možnost řízeného prolínání dat mezi různými subjekty (ORP,KÚ) a využitelnosti dat pro jejich prezentaci směrem k veřejnosti (opět s možností řízení úrovně informací, které je možno zveřejnit). Je na místě také ještě jednou zdůraznit požadavek na soulad řešení a jeho funkcionality s platnou legislativou, kterou dodavatel musí zajistit jak ve funkcionalitě řešení, tak procesech a postupech, popsaných v uživatelské dokumentaci,

6


2 Historické kořeny projektu V současné době je na Krajském úřadu Plzeňského kraje používán produkt typu klient server. Jeho počátky sahají do roku 1996, kdy referát kultury, mládeže a tělovýchovy Okresního úřadu Plzeň - sever vypracoval na základě vlastních potřeb návrh programu, který měl pokrývat náplň práce na úseku státní památkové péče. Návrh programu byl zrealizován a od ledna 1997 byl program prověřován na příslušném referátu. Po úspěšném zkušebním provozu byl nasazen na okresních úřadech v ČR. S příchodem nových technologií a se změnami v organizaci v systému státní správy se objevily nové požadavky na tento produkt a především na použití současných a perspektivních technologií tak, aby byla zajištěna kontinuita vývoje a možnost snadné komunikace s třetími stranami. Z této úvahy vychází přehodnocení současných požadavků a tedy i tato nová specifikace zadání.

3 Součásti řešení Celý projekt lze chápat jako souhrn následujících částí • Analýza požadavků, problematiky, interface třetích stran • Vytvoření produktu v několika krocích (interaktivní vývoj na serveru, interakce s uživateli/testery) • Nasazení do ostrého provozu • Transformace dat bez výpadku provozu (jedná se o poměrně stěžejní požadavek) • Podpora uživatelů na úrovni centra (KÚ) a na úrovni jednotlivých ORP, metodika výkonu státní správy a její aplikace v provozu • Zajištění dalšího vývoje (předpokládá se časem změna UIR, další třetí strany, reakce na legislativní změny, reakce na změny platformy – nové verze MSIE apod.) • Zajištění nepřetržitého provozu – support na úrovni úprav a oprav chyb, systém podpory uživatelů, odborná a uživatelská pomoc

4 Reference a znalostní předpoklady •

• •

Předpokládá se dobrá znalost problematiky činností subjektů státní správy v oblasti památkové péče na úrovni KÚ a ORP včetně znalosti legislativy, a dále znalost problematiky a legislativy závazné pro informační systémy ve veřejné správě – tyto znalosti přinese dodavatel a nebudou již součástí analýzy. Předpokládá se komunikace s uživateli a poradenství jak v oblasti vlastního interface, tak ohledně metodiky a vazeb na legislativu na úrovni KÚ i ORP. Očekáváme reference v oblasti intranetových/internetových aplikací podobného rozsahu

5 Harmonogram postupu řešení Harmonogram je navržen s ohledem na to, aby bylo možné ze strany zadavatele včas ověřit navržené součásti systému a ovlivnit směr vývoje potřebným směrem. Uchazeč na základě tohoto návrhu v nabídce popíše postup prací tak, jak je předpokládá realizovat, včetně návrhu termínů. Vítězný uchazeč se může při realizaci od navrženého harmonogramu mírně odchýlit, pokud změnu dostatečně obhájí. Zadavatel si však vyhrazuje právo změny neakceptovat. 7


Harmonogram postupu navržený zadavatelem: • Návrh konzistentní datové základny • Vytvoření základního rámce pro autentizaci a autorizaci • Vytvoření základních agend – správy hlavních číselníků • Doplnění vazby základních číselníků na zásadní související data třetích stran – UIR, katastr • Řešení systému evidence obrazových příloh a jejich vazby k hlavním číselníkům (Systém obrazových příloh k hlavním číselníkům, komplexní správa) • Interface pro prezentaci dat na internetovém portálu (systém URL adres, vazba na portál ohledně obrazových příloh a vybraných položek hlavních číselníků) • Vytvoření správy všech souvisejících číselníků • Řešení podatelny a vazby na systémy podatelen třetích stran • Řešení vazby na základní registry • Technologie šablon pro všechny agendy • Agendy vyjádření, rozhodnutí, vázané na základní číselníky • Agendy rozhodnutí o finančním příspěvku a jejich specifické funkce dle legislativy • Agenda systému dotací • Vazba na externí systém správy dotací • Přílohy k vyjádřením/rozhodnutím a jejich správa • Aplikace automatické tvorby dokumentů ke každé agendě a jejich verzování • Doplnění hlavních číselníků o vazby na kartografická data – Google maps, GIS • Řešení příloh ke všem hlavním číselníkům (včetně řešení příloh k podáním) • Řešení příloh ke všem výkonným agendám • Vazba na systém Monumnet (spolupráce s NPÚ) • Základní sestavy

6 Jednotlivé součásti řešení dle harmonogramu 6.1 Datová základna V následujících řádcích jsou shrnuty požadavky na datovou základnu. Lze předpokládat, že z datové základny se budou čerpat data pomocí webových služeb i pro jiné subsystémy KÚ. Pro návrh datové základny nelze v plném rozsahu využít strukturu datové základny současně používaného systému. Datová základna je sice plně funkční, ale její rozvoj probíhal na různých platformách od Unixu přes FoxPro až po současnou podobu MS SQL databáze.

6.1.1 Hlavní nevýhody současné datové základny jsou: • • •

Vzájemné vazby tabulek nejsou realizovány pomocí auto id, ale položkou, jejíž naplnění řeší sama aplikace Konzistence dat je zajištěna na úrovni aplikace a ne na úrovni databáze Současné řešení není jednoduše možné napojit na základní registry bez významnějších změn ve funkcionalitě a datovém modelu.

8


6.1.2 Požadavky na novou datovou základnu jsou následující: • • • • • • •

Zajištění konzistence dat a logiky pokud možno na úrovni databáze (důvodem je především nezavřít si možnost v budoucnu pořizovat data i pomocí jiných subsystémů) Uchovávat veškeré binární dokumenty v databázi Oddělit souborově část databáze, ukládající data via BLOB (z důvodu rozdělení zálohování objemných dat separátně od všech ostatních - textových) Schopnost importovat stávající data a správně je prezentovat v nové aplikaci V průběhu transformace zajistit opravu některých sekcí dat v oblasti duplicit, ke kterým došlo při zadávání dat v průběhu mnoha let práce Transformace bude zahrnovat i převod prefixů stávajících údajů parcelních čísel do formátu kompatibilního s aplikací katastrálního úřadu Udržovat ve strukturované podobě auditní log významných akcí tak, aby byl chráněný proti modifikaci, především u operací s daty ze základního registru obyvatel a osobních údajů

6.2 Základní rámec pro autentizaci a autorizaci 6.2.1 Základní rámec a vzhled Pro vlastní rozhraní (dále jen GUI) bude zvoleno minimální zobrazované rozlišení klientských počítačů, pro které bude aplikace navržena. Aplikace musí umět využít veškeré velikosti displeje (neomezovat zobrazení na pevnou velikost), ovládání musí být přehledné. Uživatel bude mít na každé obrazovce možnost zavolat kontextovou online nápovědu s informacemi o obrazovce, na které se nachází. Odkazy mimo aplikaci se budou otevírat v novém okně. Veškeré sestavy bude moci uživatel filtrovat a třídit podle jednotlivých sloupců, případně sloupce schovávat a přehazovat, takto nadefinovaný pohled si následně jednoduchým způsobem uložit a následně kdykoli vyvolat.

6.2.2 Autentizace Pro autentizaci bude možné využít v oblasti intranetu ověřené jméno uživatele v doméně (NTLM). Pro vnější přístup se předpokládá login form. V průběhu realizace bude upřesněno, zda ověření via login form proběhne proti vlastní membership API, nebo proti Microsoft Active Directory (dále jen AD). Aplikace musí být připravena na ověření uživatele proti dalším zdrojům, především využití tzv. SSO modulu, který zajišťuje ověření proti dalším zdrojům a komunikuje na bázi webových služeb.

6.2.3 Autorizace Autorizace bude řešena na úrovni aplikace dle uživatelského jména. Požadována je škálovatelnost pomocí rolí a jejich kombinací. Každá role (tam, kde to má smysl) vyžaduje členění práv ve smyslu – čtení i zápis, pouze čtení, čtení i zápis vlastních záznamů.

6.2.4 Administrace Aplikace bude obsahovat rozhraní pro správu uživatelů a nastavování jejich oprávnění. Dále bude umožňovat hromadnou i individuální správu uživatelských nastavení (pohledů). 9


6.2.5 Auditní log Aplikace bude logovat informace o přihlašování uživatelů a jejich akcích v systému způsobem, zajišťujícím neměnnost auditního logu. Administrátor bude mít přístup k auditnímu logu akcí jednotlivých uživatelů způsobem, umožňujícím jeho filtrování a vyhledávání (minimálně podle uživatele, data, typu akce a objektu/subjektu, nad kterým byla prováděna).Logování bude dodavatelem přednastaveno tak, aby bylo v souladu s platnou legislativou – především legislativa týkající se ochrany osobních údajů, základních registrů, informačních systémů veřejné správy a svobodného přístupu k informacím.

6.3 Vytvoření základních agend Základními číselníky se rozumí památky, památkově chráněná území a ochranná pásma. Specifickou částí karty památky je vazba na vlastníky.

6.3.1 Památky Struktura dat karet památek by měla zahrnovat základní 5 oblastí, i opticky členěných: 1. základní údaje 2. údaje o vlastníkovi (zmíněno dále v přesnější specifikaci) 3. údaje KÚ, nezveřejňované 4. sekce údajů NPÚ 5. sekce veřejných údajů Dále pak musí být začleněna/vázána minimálně na následující objekty: - obrázky - přílohy - pam.chráněná území - ochranná pásma - popisná čísla - parcelní čísla - UIR, RÚIAN - Katastr - www odkazy

6.3.2 Vlastníci Vlastník bude uveden na kartě památky v podobě běžného datového pole (datových polí). Evidence vlastníků by měla zahrnovat možnost jejich historizace. Výchozím zobrazením bude poslední aktuální vlastník. Pro kontrolu aktuálního vlastníka bude sloužit link do aplikace katastru nemovitostí, kde si uživatel může údaje přečíst a zaktualizovat. Není třeba řešit automatizovaný import, nebo přenos údajů z aplikace katastru nemovitostí do datové základny. Údaje budou také ověřovány v základních registrech (ROB, ROS, RÚIAN) ve všech případech, kdy to ukládá zákon, případně na požadavek uživatele. • Historizace (datum od kdy je vlastníkem a kdo záznam upravil) • Základní textové údaje pro vložení adresy • Ruční historizace (tedy ne historizace při každé změně, ale ruční vložení nového záznamu a jeho vyplnění pomocí příslušného GUI) • ROS, ROB, RÚIAN • Link do aplikace katastru nemovitostí 10


6.3.3 Památkově chráněná území Struktura dat karet pam.chr.území by měla zahrnovat oblasti: 1. základní údaje 2. údaje KÚ, nezveřejňované 3. sekce údajů NPÚ Dále pak musí být karta pam.chr.území začleněna/vázána na následující objekty: - obrázky - přílohy - popisná čísla - parcelní čísla - UIR, RÚIAN - www odkazy - přehled památek, patřících do chr.území

6.3.4 Ochranná pásma Ochranná pásma jsou vázána na objekty: - přílohy - popisná čísla - parcelní čísla - UIR, RÚIAN - www odkazy - historizace - přehled památek, patřících do ochranného pásma

6.4 Začlenění do UIR, katastru, základních registrů Začlenění do UIR, potažmo RÚIAN je na úrovni adresního bodu. U katastru jsou známa parcelní čísla.

6.4.1 UIR UIR je v současné době stále v podobě separátní databáze. S ohledem na avizované změny v distribuci UIR je ovšem na straně databáze UIR cílem vytvořit webovou službu (dále jen WS) a komunikaci řešit konzumací této WS. V okamžiku změny distribuce pak bude přepracována wWS na straně nového UIR tak, aby nedošlo k narušení kontinuity provozu.

6.4.2 RÚIAN V okamžiku zahájení provozu základního registru územní identifikace, adres a nemovitostí (RÚIAN) bude dodávané řešení napojeno na tento registr a bude ověřovat veškerý relevantní datový obsah v tomto registru. V případě neshody bude řešení obsahovat procesy, které v souladu s legislativou zahájí proces řešení této neshody.

6.4.3 Katastr nemovitostí KÚ má zajištěnu chráněnou úroveň přístupu do aplikace katastru. Aplikace musí zjistit snadný přístup pomocí přímého odkazu na základě parcelních čísel

11


6.4.4 Přečíslování parcelních čísel pozemků Současná databáze obsahuje parcelní čísla nekompatibilní s prefixy. Dodavatel zajistí jejich transformaci do správného formátu.

6.5 Systém evidence obrazových příloh Systém obrazových příloh se týká výhradně příloh v podobě obrázků – bmp, jpg, png, gif, tiff, případně dalších formátů dle analýzy. Současná datová základna obsahuje poměrně rozsáhlou obrazovou dokumentaci k památkám, k pam.chr.územím a ochranným pásmům. Tato dokumentace bude využita jak pro účely interní (aktuální stav památky, kontrola dotací, přidělování finančních příspěvků), tak pro účely veřejné (turistický portál, portál Plzeňského kraje) a případně pro tiskové účely (pouze okrajově).

6.5.1 Základní cíle • • • • • • •

ukládání obrazových dat v BLOB polích oddělit fyzicky databáze obrazových příloh z důvodů separátního plánu zálohování začlenit přílohu k větám základních číselníků mechanismus pro on-line resampling bitových map pro zmenšení datového toku směrem ke klientovi (některé přílohy mohou být datově objemné, přímo z digitálního fotoaparátu, skeneru apod.) opatřit každou přílohu základními popisnými poli (název, popisek, klíčová slova, datum vzniku, autor a další – bude definováno při analýze) další atributy obrázku (základním atributem je pořadí obrázku a úroveň zveřejnění) systém separátní práce s obrazovou dokumentací (systém vyhledávání a hromadné práce s materiály)

6.6 Interface pro spolupráci s internetovým portálem 6.6.1 Vazba na internetový portál je ve třech oblastech: • • •

zveřejnitelná textová pole na kartách památek, pam.chr.území a památkových zón části obrazových příloh, určených k veřejné prezentaci systém databáze URL odkazů a jejich vazeb na jednotlivé subjekty, týkající se památek (souhrnná tabulka URL odkazů, z nichž každý se může vázat na jednu, či více karet památek)

6.6.2 Funkčnost spočívá ve vytvoření těchto funkčností: •

ve vytvoření pohledu (pohledů) v databázi nebo WS, které budou poskytovat zveřejnitelná data • vytvoření nástrojů (GUI) pro správu webových (URL) odkazů • poskytnutí dat URL odkazů (pohled, WS) Detaily budou specifikovány při analýze

6.7 Správa všech souvisejících číselníků Pro fungování příslušných vazeb, výběrů (dropdownlisty, listboxy apod.) se předpokládá celá řada souvisejících číselníků. Některé z nich vycházejí z dané 12


metodiky a problematiky (například ukládací a skartační znaky), některé vyplývají z nutnosti komfortu intellisense seznamů, nebo společných dat pro všechny agendy. Každý číselník je třeba opatřit rozhraním pro jeho správu a návazné vzájemné vazby.

6.7.1 Základní pomocné číselníky a agendy • • • • • • • • • • • •

Druhy památek Stavy památek Druhy využití Druhy dotací Druhy vlastníků Typy území Druhy rozhodnutí Druhy vyjádření Ukládací znaky Vyřizuje (seznam pracovníků, příprava na řešení elektronického podpisu) Číselník vlastníků (problematika číselníku vlastníků zmíněna dále v textu) Číselník www odkazů (viz interface pro správu webových odkazů)

Předpokládá se vytvoření dalších, buď automaticky generovaných číselníků, nebo ručně spravovaných číselníků pro účely aplikace. • Např. generování klíčových slov pro intellisense našeptávače apod.

6.8 Řešení podatelny Systém musí obsahovat autonomní řešení zakládání jednotlivých podání s univerzální podporou vazeb na různé typy podatelen 3. stran.

6.8.1 Řešení číselných řad Každý subjekt (KÚ, ORP) bude do systému pořizovat podání ve své vlastní číselné řadě. Rovněž je uplatněn princip izolace č.řad, tedy přístup pouze ke svým vlastním podáním daného subjektu.

6.8.2 Vazby na jiné podatelny Základní vazba bude uplatněna ve smyslu zavedení podacího čísla ze systému konkrétní podatelny a nastavení parametrů vazby na danou podatelnu. Vazbu lze uplatnit oběma směry: • Import dat podání z elektronické podatelny na základě čísla podání Jedná se o import polí podání z elektronické podatelny v podobě vazby na WS dle specifikace dané podatelny. ORP používají omezenou verzi spisové služby. KÚ využívá systém ATHENA. • Linkování na dokumenty daného čísla spisu Jedná se o prolinkování na dokumenty daného čísla spisu v těch částech rozhraní, kde je to vhodné (podání, rozhodnutí, vyjádření).

6.8.3 ATHENA KÚ využívá systém ATHENA, kde je možné uplatnit import polí v plném rozsahu. Ke každému podání pak v systému ATHENA vzniká celá řada souvisejících dokumentů, 13


které je třeba dát k dispozici (linkovat) přímo z aplikace tak, aby byl seznam linků se základními údaji o daném dokumentu k dizpozici přímo v GUI. Klepnutím na link se pak uživatel dostává do externího modulu, který daný dokument zobrazí. Podobný systém lze realizovat i v případě ORP. Import polí ze systému ATHENA bude dále rozšířen o speciální import v oblasti programu dotací (viz dále v textu).

6.8.4 Identifikátory podání Systém vazby na podatelny je třeba zajistit těmito výchozími identifikátory: 1. pořadové číslo podatelny (externí podatelny = spis.služba, ATHENA) 2. číslo jednací (v principu každý dokument v ext. podatelně má svoje číslo jednací, pouze první a poslední má v principu shodné číslo jednací) 3. číslo spisu (číslo složky, ve které jsou písemnosti a dokumenty k případu)

6.8.5 Databáze žadatelů Nebude řešena separátní databáze žadatelů. Každý žadatel bude uveden na daném podání, ať už byla data pořízena importem, nebo ručním vložením pomocí GUI.

6.9 Technologie šablon Technologie šablon je základním kamenem fungování celého systému. Systém musí být postaven tak, aby uživatel byl schopen si vytvořit vlastní šablonu prostředky MS Office. Předpokládá se proto naprogramování zásuvného modulu pro MS Office, který zajistí integraci s dodávaným systémem Šablona primárně obsahuje text s grafickou hlavičkou daného subjektu (úřadu), do které pak aplikace při vlastním procesu automatické tvorby dokumentu dosadí na určená místa hodnoty souvisejících dat (např.číslo podání, údaje žadatele, text vyjádření, popis související památky apod.) V současnosti existuje celá řada šablon, používaných na KÚ, které je třeba určitým způsobem zachovat pro zajištění kontinuity práce. Všechny jsou tvořeny v MS Office 2003, 2007, 2010 jako dokument šablony (.DOT/.DOTX). Při této příležitosti dodavatel veškeré šablony zreviduje z hlediska jejich aktuálnosti.

6.9.1 Požadavky na systém správy šablon • • • • •

řešitel musí zajistit funkčnost výchozích šablon (buď vytvořit šablony nové, nebo převést stávající používané šablony ve formátu .DOT/.DOTX) pro každý subjekt (KÚ, jednotlivá ORP) je separátní sada šablon pro každou oblast je rovněž separátní sada šablon (oblast příslušných rozhodnutí, vyjádření), která se liší exaktně danou sadou vkládaných polí finální dokument by již neměl být nijak vázán na jeho původní šablonu (protože šablona může být v průběhu času předmětem změn) šablona by měla být postavena tak, aby bylo umožněno automaticky vkládaným hodnotám (textům) přizpůsobit prostor dle své velikosti (délce vkládaného textu)

6.9.2 Platforma Všechny klientské počítače, které budou pracovat s agendami tvorby dokumentů, budou vybaveny minimálně aplikaci MS Word 2003, 2007, 2010 (případně vyššími verzemi). Toto lze pokládat za minimální konfiguraci klientského pracoviště ohledně tvorby finálních dokumentů. 14


V rámci placené podpory dodavatel zajistí aktualizaci nástrojů pro případné nové verze MS Office.

6.10 Agendy vyjádření a rozhodnutí Jedná se o agendy, pomocí kterých se tvoří podklady (data) pro následnou automatickou tvorbu dokumentů příslušné oblasti státní správy. Agendy jsou vázany na základní číselníky (památky, pam.chr.území, ochranná pásma) a související podpůrné číselníky. Důležitou podmínkou je garantování souladu těchto agend s legislativou ze strany dodavatele. Jedná se o následující agendy se separátním GUI a s uvedeným minimálním rozsahem vazeb:

6.10.1

Rozhodnutí k památkám

Jedná se o standardní vyjádření a rozhodnutí, vázané na kartu památky, případně na ochr.pásmo, nebo pam,chr.zónu do které památka patří. - dokumenty - žádosti (podání) - památky

6.10.2

Rozhodnutí k pam.chr.území

- dokumenty - žádosti (podání) - pam.chr.území - ochranná pásma

6.10.3

Rozhodnutí k ochrannému pásmu

- dokumenty - žádosti (podání) - pam.chr.území - ochranná pásma

6.10.4

Ostatní agenda k památkám

Jedná se o univerzální agendu, která není využívána jako standardní vyjádření k památce, ale přesto je na památku vázána. - dokumenty - přílohy - žádosti (podání) - památky - UIR

6.10.5

Ostatní agenda

Ostatní agenda je nejuniverzálnější agenda, která je vázána na všechny hlavní číselníky. Vazba je zcela nepovinná. Tato agenda je zamýšlena jako nástroj pro stavební odbory, které jsou na mnoha místech pověřeny zajišťováním státní správy ohledně památkové péče a zároveň vykonávají i jejich původní zaměření. Pak mohou s výhodou použít pro práci shodný produkt se stejnou funkčností. Tematicky je třeba ostatní agendu (pomocí příznaku) rozdělit na následující typy: 15


1. problematika územního plánování 2. prohlašování KP 3. ostatní agenda Funkčnost opět sestává z těchto oblastí a začlenění - dokumenty - přílohy - žádosti (podání) - UIR - památky - pam.chr.území - ochranná pásma

6.11 Agendy rozhodnutí o finančním příspěvku Jedná se o agendu s následujícími vazbami, doplněné o jejich specifické funkce dle legislativy. Agenda zahrnuje kromě sledování termínů i určité finanční výpočty. Kromě běžného postupu výpočtu spoluúčasti je třeba zahrnout i opačný systém výpočtu: tedy že se vyjde z přidělené částky a zjišťuje se celkový rozpočet.

6.11.1

Rozhodnutí o finančním příspěvku

- dokumenty - žádosti (podání) - památky - pam.chr.území - ochranná pásma

6.12 Agenda systému dotací Agenda systému dotací vychází z agendy rozhodnutí o finančním příspěvku, doplněná o sadu doplňujících položek a vazeb. Tato agenda není doposud zastoupena ve stávajících datech a není tedy třeba transformovat žádná existující data. Navíc je zde vyřešit subsystém importu dat z externího produktu (viz dále v textu).

6.12.1

Systém dotací

- dokumenty - žádosti (podání) - památky - pam.chr.území - ochranná pásma

6.13 Vazba na externí systém správy dotací Agenda systému dotací bude pro subjekt KÚ vázána na nový informační systém externí správy dotací, který je přístupný na http://dotace.plzensky-kraj.cz.

6.13.1 •

Import dat bude probíhat ve dvou rovinách

ATHENA (specifická pole z podatelny) 16


•

IS správy dotací, výběry dotačních titulů

6.14 Přílohy k vyjádřením/rozhodnutím a jejich správa Každá agenda finálních funkcí musí být opatřena možností připojení libovolné přílohy (v podobě standardního attachmentu, uploadovaného uživatelem). Jedná se především o přílohy typů PDF, DOC, XLS, JPF, TIFF apod., které nebudou přímo zobrazovány v aplikaci, ale bude možné je formou linku (downloadu) stáhnout, případně dle lokální asociace zobrazit uživateli.

6.14.1

Přílohy budou k dispozici v těchto agendách

Rozhodnutí k památkám Rozhodnutí k pam.chr.území/ochrannému pásmu Rozhodnutí o finančním příspěvku Agenda dotací

6.15 Aplikace automatické tvorby dokumentů ke každé agendě a jejich verzování Správa šablon spolu s jednotlivými agendami umožní ve finále automatizovanou tvorbu finálního dokumentu.

6.15.1

Platforma

Jako formát dokumentu bude využit .DOC pro MS Word 2003 nebo vyšší, který je k dispozici na všech klientských počítačích jako primární nástroj pro tvorbu dokumentace.

6.15.2

Postup práce s aplikací měl být dle uvedeného schématu:

1. uživatel vybere příslušnou agendu a příslušný případ 2. vybere z připravených šablon pro danou agendu požadovaný formulář (šablonu) 3. vytvoří prvotní automaticky vygenerovaný dokument a opatří ho základním popisem (subjektem) 4. dokument si stáhne na svůj počítač a provede v něm potřebné korektury 5. výsledný upravený dokument zpět odešle do systému (upload) příkazem z prostředí MS Word (tj. aniž by si uživatel musel pamatovat cestu k souboru a zadávat ji do dialogu) 6. dokument se v systému uloží jako další verze původního dokumentu 7. body 4-6 se mohou cyklicky opakovat, nebo body 2-6 se mohou libovolně opakovat

6.15.3

Požadavky na systém generování dokumentů • • • • •

bezzásahový systém vygenerování prvotního dokumentu verzování dokumentů (poslední verze dokumentu bude zobrazena s možností rozbalení historizace) informace o tom, kdo dokument vytvořil, nebo upravil možnost dokument označit jako smazaný (nebude se ve výchozím zobrazení nabízet v seznamu dokumentů) možnost uploadu vlastního dokumentu (znamená to, že prvotní/i následný dokument bude možné uploadovat i bez použití generátoru) 17


6.16 Doplnění hlavních číselníků o vazby na kartografická data – Google maps, GIS Hlavní číselníky je třeba doplnit sekcí údajů ohledně pozice. Tento údaj bude dále využit pro vazbu na interní systémy GIS, případně Google maps.

6.16.1

GIS

K mnoha památkám dnes existují údaje o pozici v systému WGS84, které je možno dle identifikátoru ústředního seznamu naimportovat do dat památek.

6.16.2 • • • •

umožnit import souřadnic ze souboru CSV (v definovaném formátu) umožnit ruční vstup (GUI pro zadávání souřadnic) konfigurace URL adresy pro přímé linkování na zobrazovací stránku GISu umístění linku tam, kde je to vhodné (na kartě hlavného číselníku)

6.16.3 • • •

Požadavky

Google maps

konfigurovatelnost URL odkazu na google maps možnost využití API (KÚ má svůj API key pro účely intranetu) umístění linku tam, kde je to vhodné (na kartě hlavního číselníku)

6.17 Řešení příloh k hlavním číselníkům Každá agenda finálních funkcí musí být opatřena možností připojení libovolné přílohy (v podobě standardního attachmentu, uploadovaného uživatelem). Jedná se především o přílohy typů PDF, DOC, XLS, JPF, TIFF apod., které nebudou přímo zobrazovány v aplikaci, ale bude možné je formou linku (downloadu) stáhnout, případně dle lokální asociace zobrazit uživateli.

6.17.1


Památky Pam.chr.území Ochranná pásma Žádosti (podání)

6.18 Řešení příloh k dalším výkonným agendám Podpůrné (univerzální) víceúčelové agendy musí být opatřeny možností připojení libovolné přílohy (v podobě standardního attachmentu, uploadovaného uživatelem). Jedná se především o přílohy typů PDF, DOC, XLS, JPF, TIFF apod., které nebudou přímo zobrazovány v aplikaci, ale bude možné je formou linku (downloadu) stáhnout, případně dle lokální asociace zobrazit uživateli.

6.18.1


Ostatní agenda k památkám Ostatní agenda

18


6.19 Vazba na systém Monumnet Vazba na systém NPÚ – Monumnet (monumnet.npu.cz) je pracovníkům v oblasti památkové péče přístupná v několika úrovních dle příslušných oprávnění přihlášeného uživatele.

6.19.1 Realizace vazeb na Monumnet spočívá v následujících krocích • • • • •

nalezení společného identifikátoru (není jisté, zda se bude jednat o číslo ústředního seznamu, neprohlášené památky lze identifikovat číslem kauzy) dohodnutí vzájemné vazby tak, aby bylo možné uživateli přímo zobrazit kartu z Monumnetu zavedení konfiguračního GUI pro nastavení propojení s Monumnetem, případně pro automatické zalogování přihlášeného uživatele do Monumnetu zobrazení přímého linku na Monumnet v podobě odkazu na kartu Monumnetu, případně na kartu obrazové dokumentace vyřešení základního importu dat z monumnetu (název památky, začlenění a základní popis), podobu je třeba dohodnout přímo s NPÚ (kontaktní osoba a kontaktní informace budou řešiteli poskytnuty)

6.20 Základní sestavy V základní dodávce bude specifikováno 10 základních reportů napříč všemi agendami, které budou k dispozici v separátní části menu pro příslušná oprávnění.

6.20.1 • • • • •

Požadavky na základní reporty jsou následující

dostatečná univerzálnost pro příslušný účel možnost interakce (filtrování, řazení, skrývání sloupců, rozbalování/sbalování skupin) možnost exportu (XLS, CSV, PDF, MS Word) u vybraných reportů možnost tisku (u ostatních není třeba omezovat šířku reportu pro tisknutelnost) pro účely reportů bude na MS Reporting Services zřízen jednotný účet s právem browse, pomocí kterého se bude aplikace logovat

7 Serverová a klientská platforma Požadovaná platforma vychází ze současného vybavení KÚ a zúčastněných ORP, a z možnosti supportu vlastními silami. Orientace je výhradně na serverové a kancelářské produkty spol. Microsoft, včetně databázové platformy.

7.1 Klientská platforma 7.1.1 Prohlížeč Jako prohlížeč se primárně předpokládá Microsoft Internet Explorer 8 (a později jeho následné verze). V případě potřeby bude povolena instalace modulů ActiveX, především ohledně prohlížeče reportů. Komunikace ORP vůči KÚ bude probíhat zabezpečeným tunelem (VPN).

19


7.1.2 Tvorba dokumentů Pro tvorbu šablon a finálních dokumentů bude na každém klientském počítači k dispozici buď lokálně nebo síťově MS Word 2003,2007.

7.2 Serverová platforma Systém aplikace programového vybavení pro výkon státní správy v oblasti památkové péče bude rozdělen na dva fyzické servery. Na prvním serveru bude nainstalována aplikační vrstva. Na druhém serveru bude databáze, ve které budou uložena všechna data včetně všech dokumentů a příloh (tedy veškerá data budou uložena v databázi). Databáze bude provozována na MS SQL 2008. Aplikační server je zapojen přes propojovací prvky sítě krajského úřadu tak, aby byl viditelný z ostatních serverů a pracovních stanic. Oba servery běží na Windows serveru 2008, které poběží na VMware ESX serveru. Serverům bude v rámci VMware ESX serveru přidělena minimálně (tedy buď přesně uvedená konfigurace, nebo lepší) tato garantovaná virtuální konfigurace: • aplikační server: 2x 3GHz cpu (2 jádra), 4GB RAM, 200GB diskového prostoru • databázový server: 4x 3GHz cpu (2 jádra), 8GB RAM, 500GB diskového prostoru

7.3 Datový server 7.3.1 Hlavní data Pro umístění databáze je určen server Microsoft SQL Server 2008. Zde by byla umístěna hlavní databáze produktu spolu s vedlejší databází pro binární data. Zálohování je zajištěno ze strany zadavatele.

7.3.2 Stávající data Stávající data pro transformaci jsou uložena v databázi ve verzi Microsoft SQL 2000. Obsahují jak všechna hlavní data, tak tabulky s binárními daty (obrázky, dokumenty, přílohy).

7.3.3 Reporting services Pro účely reportování bude vytvořen separátní kořenový adresář s možností členění do jednotlivých adresářů. Bude zřízen jednotný browse účet pro účely aplikace, která se bude k němu přihlašovat jako klient. Pro účely ladění zadavatel zřídí účet pro publikaci reportů a testování.

7.4 Internetový server 7.4.1 Webový prostor Aplikace by měla být navržena pro IIS 6 nebo 7. Speciální nastavení práv do specifikovaných adresářů zadavatel provede dle specifikace řešitele.

7.4.2 Podpůrná platforma Předpokládá se využití platformy AJAX a .NET ve verzi 2.0, 3.5 , nebo 4.0. Jiný framework není v prostředí KÚ pro webové aplikace provozován a aktualizován. Pokud uchazeč ve své nabídce předloží jinou platformu, musí zajistit její údržbu v rámci poskytování technické podpory a údržby k dodanému programovému vybavení. 20


7.5 Požadavky na bezpečnost portálu Aby mohl být informační systém zařazen do infrastruktury KÚPK, tak musí splňovat bezpečnostní opatření, která zajistí, že informační systém projde penetračními testy dle metodiky: http://www.owasp.org/index.php/Category:OWASP_Project Všechny techniky napadnutí webu, proti kterým musí být informační systém zabezpečen, jsou v odkazu. Zda tento informační systém tato bezpečností opatření splňuje, si objednatel ověří na vlastní náklady. Při zjištění bezpečnostních vad, je dodavatel povinen tyto vady odstranit. Ještě jeden následný penetrační test po odstranění takových závad hradí objednatel. Pokud bezpečnostní chyby přetrvají, další penetrační testy bude hradit dodavatel. Bezpečný průchod informačního systému penetračními testy je podmínkou pro akceptaci díla.

8 Dokumentace a nápověda Dále je uveden výčet dokumentace, kterou dodavatel dodá a bude udržovat aktuální v rámci plnění této zakázky. Dokumentace bude dodána ve zdrojovém (nebo jiném editovatelném) formátu podle volby zadavatele, preferován je formát MS Word 2003 (.DOC) pro dokumenty, MS Visio pro nákresy a schemata.

8.1 Uživatelská dokumentace Součástí dodávky bude zpracování kompletní uživatelské dokumentace, která popíše práci s řešením na úrovni jednotlivých procesů, včetně nasnímaných obrazovek nebo výřezů. Uživatelská dokumentace bude zpracována v podobě, která umožní její import do e-learningového prostředí KÚ (Moodle). Uživatelská dokumentace bude dostupná z aplikace (URL link na aktuální verzi).

8.2 Dokumentace pro správce Bude dodána příručka pro správce, která bude obsahovat veškeré úkony správy aplikace – administrace přístupových práv, nastavování číselníků, řešení problémů atd. Součástí bude popis architektury celé aplikace a detailní popis jednotlivých rozhraní a vazeb tak, aby se s pomocí tohoto popisu byla na řešení schopna napojit třetí strana i bez asistence dodavatele.

8.3 Bezpečnostní dokumentace Bude zpracována bezpečnostní dokumentace podle platné legislativy a vnitřních směrnic KÚ.

8.4 Online nápověda V každé chvíli bude mít uživatel možnost stisknout tlačítko pro online nápovědu, kdy se mu v novém okně otevře nápověda k aktuálně otevřenému oknu aplikace s popisem jednotlivých voleb. 21


9 Přílohy: • Příloha č. 1 Technické dokumentace – Struktura datové základny • Příloha č. 2 Technické dokumentace – Ukázka vzoru dokumentu

22

Příloha č. 1 Technické dokumentace – Struktura datové základny k nadlimitní veřejné zakázce zadávané v otevřeném řízení s názvem „Programové vybavení pro výkon státní správy v oblasti památkové péče“ Příloha č. 1 Technické dokumentace – Struktura datové základny

Přílohy Přílohy zahrnují přehled a popis výchozích datových struktur, včetně současné podoby databáze UIR. Jedná se o stávající datovou základnu, která nezohledňuje zákonné změny a aktuální požadavky na novou aplikaci! Jedná se o datovou základnu, kterou je třeba přetransformovat do nově vyvinuté aplikace. Stávající datová základna především: 1. neřeší exaktní vazbu na ORP - toto je řešeno zřetězením vazeb přes UIR 2. zcela nepokrývá některé další agendy 3. obsahuje data, která nebudou již dále využívána - např.vyjádření NPÚ Celá výchozí datová základna je ve své podstatě rozdělena na 3 oblasti: - databáze KULTURA - databáze UIR - databáze KATASTR

1

Příloha č. 1 Technické dokumentace – Struktura datové základny k nadlimitní veřejné zakázce zadávané v otevřeném řízení s názvem „Programové vybavení pro výkon státní správy v oblasti památkové péče“

Seznam agend a souvisejících funkcí stávajících dat památek a výkonných provozních agend Přehledný seznam základních agend a jejich součástí. agenda

podřízené agendy

související agendy

památky historie přílohy historie pam.chr.území (zóny) historie přílohy historie ochranná pásma (pásma) historie přílohy historie podání historie přílohy historie rozhodnutí k památkám historie dokumenty historie rozhodnutí k pam.chr.ú./ochr.pásmům historie dokumenty historie rozhodnutí o fin.příspěvku historie dokumenty historie archeologická vyjádření historie dokumenty historie ostatní agenda historie přílohy historie dokumenty historie vyjádření NPÚ historie dokumenty historie Seznam č.parcelních+poznámka k památce Seznam č.popisných+poznámka k památce Seznam č.parcelních+poznámka k zóně Seznam č.popisných+poznámka k zóně Seznam č.parcelních+poznámka k pásmu Seznam č.popisných+poznámka k pásmu

tabulky kultura.pamatky kultura.hist_pamatky kultura.obrazkypam kultura.hist_obrazkypam kultura.zony kultura.hist_zony kultura.obrazkyzon kultura.hist_obrazkyzon kultura.pasma kultura.hist_pasma kultura.obrazkypas kultura.hist_obrazkypas kultura.zadosti kultura.hist_zadosti kultura.zadostiprilohy kultura.hist_zadostiprilohy kultura.rozh_pam kultura.hist_rozh_pam kultura.dokument_rp kultura.hist_dokument_rp kultura.rozh_zon kultura.hist_rozh_zon kultura.dokument_rz kultura.hist_dokument_rz kultura.rozh_fin kultura.hist_rozh_fin kultura.dokument_rf kultura.hist_dokument_rf kultura.vyjarch kultura.hist_vyjarch kultura.dokument_va kultura.hist_dokument_va kultura.ostagenda kultura.hist_ostagenda kultura.oagendaprilohy kultura.hist_oagendaprilohy kultura.dokument_oa kultura.hist_dokument_oa kultura.vyjspu kultura.hist_vyjspu kultura.dokument_vs kultura.hist_dokument_vs kultura.pam_poz_parcely kultura.pam_pop_cisla kultura.zon_poz_parcely kultura.zon_pop_cisla kultura.pas_poz_parcely kultura.pas_pop_cisla

2


Agenda památky Název položky

Typ

Poznámka

PAM_KOD_PAMATKY PAM_REJSTRIKOVE_CISLO_US PAM_REJSTRIKOVE_CISLO_SS PAM_KAUZA PAM_NAZEV_PAMATKY PAM_ZONA_CISLO_JEDNACI PAM_OP_CISLO_JEDNACI PAM_VYUZITI PAM_KATASTR PAM_CASTI_PAMATKY PAM_VLASTNICI PAM_UZIVATELE PAM_POZNAMKA PAM_MOVITA PAM_KOD2_PAMATKY PAM_HTML PAM_ZAKL_POPIS PAM_VYHLASIL PAM_KDY PAM_STAV PAM_OKRES_KOD PAM_OBEC_KOD PAM_MCAST_KOD PAM_COBCE_KOD PAM_OBJEKT_KOD PAM_ADRESA_KOD

char char char char char char char char int memo memo memo memo logical char memo text char datum char int int int int int int

Jednoznačný identifikátor (navrhovaný ručně)

Číslo kauzy dle NPÚ Vazba na tabulku ZONY Vazba na tabulku PASMA Výběr z číselníku DR_VYUZITI Vazba na katastr

Svázání movitých a nemovitých památek

Kdo a kdy prohlásil památku Odkaz do číselníku STAV_PAM (pam.ochrana) Začlenění památky dle UIR

Agenda zóny (pam.chr.území) Název položky

Typ

ZON_CISLO_JEDNACI ZON_NAZEV_ZONY ZON_TYP ZON_VYHLASIL ZON_KDY ZON_REJ_CISLO ZON_POZNAMKA ZON_POPIS ZON_OKRES_KOD ZON_OBEC_KOD

char char char char datum char memo memo int int

Poznámka

Výběr z číselníku TYPYZON

začlenění dle UIR

Agenda pásma (ochr.pásma) Název položky

Typ

OP_CISLO_JEDNACI OP_ZONA_CISLO_JEDNACI OP_NAZEV_ZONY OP_TYP

char char char Char

Poznámka

Vazba na zóny (tabulku ZONY) Výběr z číselníku TYPYZON 3

Příloha č. 1 Technické dokumentace – Struktura datové základny k nadlimitní veřejné zakázce zadávané v otevřeném řízení s názvem „Programové vybavení pro výkon státní správy v oblasti památkové péče“ OP_VYHLASIL char OP_KDY datum OP_REJ_CISLO char OP_POZNAMKA memo OP_POPIS memo OP_OKRES_KOD int začlenění dle UIR OP_OBEC_KOD int

Agenda podání cislo_jednaci datum_podani zadatel_kod zadatel

Char Datum char memo

termin_ano_ne termin_dny ve_věci Vyrizeno Ukladaciznak vyrizeno_dne Vyridil vypraveno_dne obsah_spisu Okres_kod

logical num char logical char datum char datum memo Int

Vazba do číselníku ZADATELE Jméno a adresa žadatele (pokud není vyplněn kód žadatele, pak se místo vazby do číselníku žadatelů použije tento text).

Vazba do číselníku ZNAK Buď vazba, nebo přímo jméno či značka

Výběr z číselníku UIR (z důvodu filtrování dle okresu)

Agenda rozhodnutí k památkám ev_cislo cislo_jednaci datum_vydani vyrizuje doruceno_dne pravni_moc_od kod_pamatky vyj_pu vydano_pu sankce_anone sankce_jaka typ odvolani Okres_kod

char char datum char datum datum char char datum logical Char char logical Int

Vazba na žádosti (podání)

Vazba do číselníku TYPYROZHODNUTI Výběr z číselníku UIR (z důvodu filtrování dle okresu)

Agenda rozhodnutí k zóně/pásmu ev_cislo cislo_jednaci datum_vydani vyrizuje doruceno_dne pravni_moc_od

char char datum char datum datum


4

Příloha č. 1 Technické dokumentace – Struktura datové základny k nadlimitní veřejné zakázce zadávané v otevřeném řízení s názvem „Programové vybavení pro výkon státní správy v oblasti památkové péče“ kod_zony char Vazba na ZONY Kod_pasma char Vazba na PASMA vyj_pu char vydano_pu datum objekt_c char parcela_c char sankce_anone logical sankce_jaka char typ char Vazba do číselníku TYPYROZHODNUTI odvolani logical Okres_kod Int Výběr z číselníku UIR (z důvodu filtrování dle okresu)

Agenda finančního rozhodnutí ev_cislo cislo_jednaci datum_vydani vyrizuje doruceno_dne pravni_moc_od kod_pamatky kod_zony Kod_pasma druh_vlastnika druh_dotace naklad_celkem fin_prispevek fin_podil_vlastnika fin_prispevek_p fin_podil_vlastnika_p odvolani Okres_kod

char char


char

char char char Char char num num num num num logical Int

Vazba Vazba Vazba Výběr Výběr

na památky na zóny na pásma z číselníku DR_DOTACE z číselníku DR_VLASTNIKU


Agenda arch.vyjádření ev_cislo cislo_jednaci datum_vydani vyrizuje doruceno_dne nalez uhrada druhnalezu mistoulozeni Okres_kod

char char datum char datum logical char char char Int



Agenda „ostatní agenda“ ev_cislo cislo_jednaci datum_vydani

char char datum

Vazba na žádosti (podání) 5

Příloha č. 1 Technické dokumentace – Struktura datové základny k nadlimitní veřejné zakázce zadávané v otevřeném řízení s názvem „Programové vybavení pro výkon státní správy v oblasti památkové péče“ vyrizuje char doruceno_dne datum kod_pamatky char Vazba do agendy (číselníku) PAMATKY. vyj_pu char vydano_pu datum typ char Vazba do číselníku TYPYROZHODNUTI KOD_ZONY char Vazba na zónu (pam.chr.území) KOD_PASMA char Vazba na pásmo (ochr.pásmo) OKRES_KOD int Vazba do UIR OBEC_KOD int MCAST_KOD int COBCE_KOD int OBJEKT_KOD int ADRESA_KOD int

Agenda vyjádření NPÚ ev_cislo cislo_jednaci datum_vyrizeni Kod_pamatky kod_zony Kod_pasma objekt_c parcela_c typ katastr Okres_kod Datum_zadosti C_jednaci_zadosti Druh_vyjadreni Vyrizuje Rozhodnuti_cislo Rozhodnuti_vydano Rozhodnuti_dne projektant firma restaurator Prilozena_pd

char char datum char char char char char char int Int datum char Char Char char char datum char char char Memo

Vazba na žádosti (podání) Vazba na PAMATKY Vazba na ZONY Vazba na PASMA

Vazba do číselníku TYPYROZHODNUTI Vazba na KATASTR Výběr z číselníku UIR (z důvodu filtrování dle okresu)

Vazba na DRUHYVYJADRENI Možnost výběru více jmen z číselníku VYRIZUJE Pro doplnění jediného čísla rozhodnutí, které na základě tohoto vyjádření bude vydáno Vazba do číselníku PROJEKTANT Vazba do číselníku FIRMA Vazba do číselníku RESTAURATOR Přiložená projektová dokumentace

6


Seznam základních číselníků Asociace Dr_dotace Dr_vlastnika Dr_vyuziti Stav_pam Typyrozhodnuti Typyzon Users Znak Druhyvyjadreni Vyrizuje Projektant Firma Restaurátor Zadatele

Tyto číselníky jsou portovány ze stávající aplikace Kultura na SQL server v nezměněné podobě. Změny se týkají pouze tabulky USERS vzhledem k rozšířené správě přístupových práv. Dále budou všechny tabulky obsahovat nové položky pro interní funkce aplikace (kdo upravil záznam a kdy).

Dv_druh Vyr_jmeno Pr_kod Pr_text Fi_kod Fi_text Re_kod Re_text Za_kod Za_text

char char char memo Char memo char memo char memo

Číselník druhů vyjádření. Číselník osob, které se podílejí na vyřizování agend. Číselník projektantů. Číselník firem. Číselník restaurátorů. Číselník žadatelů.

7


Struktura využitých tabulek externí databáze UIR Zde bude třeba primárně vytvořit a využít web services, které nejsou součástí standardní dodávky UIR. Více informací na http://forms.mpsv.cz/uir/popis/popis.jsp .

1

OKRES Tabulka všech okresů v ČR (existujících i zaniklých). Pro každý okres obsahuje časově poslední platné hodnoty atributů NAZEV a ZKRATKA Datový typ

1

2

3

4

5

6 7

8

3

OKRES_KOD Kód okresu podle SIS. Je jednoznačný v celé tabulce OKRES. Předpokládá se i neměnnost tohoto kódu v čase. NAZEV Název okresu. Je jednoznačný (bez ohledu na velikost písmen) v rámci všech existujících okresů v tabulce. ZKRATKA Zkratka názvu okresu. Je jednoznačná (bez ohledu na velikost písmen) v rámci všech existujících okresů v tabulce. STAV 1 = okres v současnosti existuje 2 = okres existoval v minulosti a již zanikl 3 = okres nikdy neexistoval a byl vložen omylem VZNIK_DNE Datum právní platnosti vzniku okresu. NULL značí neznámé datum vzniku. VZNIK_INFO Nestrukturované doplňující informace o vzniku okresu z hlášení o vzniku. ZANIK_DNE Datum právní platnosti zániku okresu. NULL značí neznámé datum zániku. Pro existující okresy (STAV = 1) je vždy NULL. ZANIK_INFO Nestrukturované doplňující informace o zániku okresu z hlášení o zániku. Pro existující okresy (STAV = 1) je vždy NULL.

4

ANO

ZNAKY

32

ANO

ZNAKY

16

ANO

ČÍSLO

1

ANO

DATUM

TEXT

3

4

5

6

NE

254

DATUM

TEXT

NE NE

254

NE

OBEC

Datový typ

2

Povinný

ČÍSLO

Tabulka všech obcí v ČR (existujících i zaniklých). Pro každou obec obsahuje časově poslední platné hodnoty atributů OKRES_KOD, NAZEV a ZKRATKA 1

Max. délka

OBEC_KOD Kód obce podle SIS. Je jednoznačný v celé tabulce OBEC. Předpokládá se i neměnnost tohoto kódu v čase. OKRES_KOD Kód mateřského okresu obce z tabulky OKRES. NAZEV Název obce. Je jednoznačný (bez ohledu na velikost písmen) v rámci všech existujících obcí v mateřském okrese. ZKRATKA Zkratka názvu obce. Je jednoznačná (bez ohledu na velikost písmen) v rámci všech existujících obcí v mateřském okrese. STAV 1 = obec v současnosti existuje 2 = obec existovala v minulosti a již zanikla 3 = obec nikdy neexistovala a byla vložena omylem VZNIK_DNE

Max. délka

Povinný

ČÍSLO

6

ANO

ČÍSLO

4

ANO

ZNAKY

48

ANO

ZNAKY

16

ANO

ČÍSLO

1

ANO

DATUM

NE 8

7 8

9

17

Příloha č. 1 Technické dokumentace – Struktura datové základny k nadlimitní veřejné zakázce zadávané v otevřeném řízení s názvem „Programové vybavení pro výkon státní správy v oblasti památkové péče“ Datum právní platnosti vzniku obce. NULL značí neznámé datum vzniku. VZNIK_INFO TEXT 254 NE Nestrukturované doplňující informace o vzniku obce z hlášení o vzniku. ZANIK_DNE DATUM NE Datum právní platnosti zániku obce. NULL značí neznámé datum zániku. Pro existující obce (STAV = 1) je vždy NULL. ZANIK_INFO TEXT 254 NE Nestrukturované doplňující informace o zániku obce z hlášení o zániku. Pro existující obce (STAV = 1) je vždy NULL.

MCAST Tabulka všech městských částí v ČR (existujících i zaniklých). Pro každou městskou část obsahuje časově poslední platné hodnoty atributů OBEC_KOD, POBVOD_KOD, TYP, NAZEV a ZKRATKA. Datový typ

1

2 3

4

5

6

7

8

9

10

11

5

MCAST_KOD Kód městské části podle SIS. Je jednoznačný v celé tabulce MCAST. Předpokládá se i neměnnost tohoto kódu v čase. OBEC_KOD Kód mateřské obce městské části z tabulky OBEC. POBVOD_KOD Kód mateřského pražského obvodu městské části z tabulky POBVOD. Městské části mimo hl.m. Prahu mají tento atribut = NULL. TYP typ prvku: 1 = městská část , 2 = městský obvod, 3 = nečleněná část obce NAZEV Název městské části. Je jednoznačný (bez ohledu na velikost písmen) v rámci všech existujících městských částí v mateřské obci. ZKRATKA Zkratka názvu městské části. Je jednoznačná (bez ohledu na velikost písmen) v rámci všech existujících městských částí v mateřské obci. STAV 1 = městská část v současnosti existuje 2 = městská část existovala v minulosti a již zanikla 3 = městská část nikdy neexistovala a byla vložena omylem VZNIK_DNE Datum právní platnosti vzniku městské části. NULL značí neznámé datum vzniku. VZNIK_INFO Nestrukturované doplňující informace o vzniku městské části z hlášení o vzniku. ZANIK_DNE Datum právní platnosti zániku městské části. NULL značí neznámé datum zániku. Pro existující městské části (STAV = 1) je vždy NULL. ZANIK_INFO Nestrukturované doplňující informace o zániku městské části z hlášení o zániku. Pro existující části obce (STAV = 1) je vždy NULL.

Povinný

ČÍSLO

6

ANO

ČÍSLO

6

ANO

ČÍSLO

4

NE

ČÍSLO

1

ANO

ZNAKY

48

ANO

ZNAKY

16

ANO

ČÍSLO

1

ANO

DATUM

TEXT

NE

254

DATUM

TEXT

NE

NE

254

NE

COBCE Tabulka všech částí obce v ČR (existujících i zaniklých). Pro každou část obce obsahuje časově poslední platné hodnoty atributů OBEC_KOD, MCAST_KOD, NAZEV a ZKRATKA. Datový typ

1

Max. délka

COBCE_KOD Kód části obce podle SIS. Je jednoznačný v celé tabulce COBCE. Předpokládá se i neměnnost tohoto kódu v čase.

ČÍSLO

Max. délka

6

Povinný

ANO

9

2 10

3

4

5

6

7

8

9

9

Příloha č. 1 Technické dokumentace – Struktura datové základny k nadlimitní veřejné zakázce zadávané v otevřeném řízení s názvem „Programové vybavení pro výkon státní správy v oblasti památkové péče“ OBEC_KOD ČÍSLO 6 ANO Kód mateřské obce části obce z tabulky OBEC. MCAST_KOD ČÍSLO 6 NE Kód mateřské městské části k části obce z tabulky MCAST. NULL značí, že část obce neleží v žádné městské části mateřské obce. NAZEV ZNAKY 48 ANO Název části obce. Je jednoznačný (bez ohledu na velikost písmen) v rámci všech existujících částí obce v mateřské obci. ZKRATKA ZNAKY 16 ANO Zkratka názvu části obce. Je jednoznačná (bez ohledu na velikost písmen) v rámci všech existujících částí obce v mateřské obci. STAV ČÍSLO 1 ANO 1 = část obce v současnosti existuje 2 = část obce existovala v minulosti a již zanikla 3 = část obce nikdy neexistovala a byla vložena omylem VZNIK_DNE DATUM NE Datum právní platnosti vzniku části obce. NULL značí neznámé datum vzniku. VZNIK_INFO TEXT 254 NE Nestrukturované doplňující informace o vzniku části obce z hlášení o vzniku. ZANIK_DNE DATUM NE Datum právní platnosti zániku části obce. NULL značí neznámé datum zániku. Pro existující části obce (STAV = 1) je vždy NULL. ZANIK_INFO TEXT 254 NE Nestrukturované doplňující informace o zániku části obce z hlášení o zániku. Pro existující části obce (STAV = 1) je vždy NULL.

OBJEKT Tabulka všech objektů v ČR (existujících i zaniklých). Pro každý objekt obsahuje časově poslední platné hodnoty atributů COBCE_KOD, CISDOM_TYP a CISDOM_HOD. Datový typ

1

2 3

4

5

6

7

8

OBJEKT_KOD Kód objektu jednoznačný v celé tabulce i v čase s kontrolní číslicí v řádu jednotek vypočtenou metodou MODULO 11 - ADDO. Je generován počítačem tak, že nové objekty mají kód (bez kontrolní číslice) o 1 vyšší než nejvyšší hodnota OBJEKT_KOD v tabulce. COBCE_KOD Kód mateřské části obce objektu z tabulky COBCE. CISDOM_TYP Typ čísla domovního dle SIS objektu v mateřské části obce: 1 = číslo popisné, 2 = číslo evidenční. CISDOM_HOD Hodnota čísla domovního dle SIS objektu v mateřské části obce. Kombinace CISDOM_TYP a CISDOM_HOD je jednoznačná v rámci všech existujících objektů v mateřské části obce. STAV 1 = objekt v současnosti existuje 2 = objekt existoval v minulosti a již zanikl 3 = objekt nikdy neexistoval a byl vložen omylem VZNIK_DNE Datum právní platnosti vzniku objektu. NULL značí neznámé datum vzniku. VZNIK_INFO Nestrukturované doplňující informace o vzniku objektu z hlášení o vzniku. ZANIK_DNE

Max. délka

Povinný

ČÍSLO

9

ANO

ČÍSLO

6

ANO

ČÍSLO

1

ANO

ČÍSLO

4

ANO

ČÍSLO

1

ANO

DATUM

TEXT

DATUM

NE

254

NE

NE 10

9

11

Příloha č. 1 Technické dokumentace – Struktura datové základny k nadlimitní veřejné zakázce zadávané v otevřeném řízení s názvem „Programové vybavení pro výkon státní správy v oblasti památkové péče“ Datum právní platnosti zániku objektu. NULL značí neznámé datum zániku. Pro existující objekty (STAV = 1) je vždy NULL. ZANIK_INFO TEXT 254 NE Nestrukturované doplňující informace o zániku objektu z hlášení o zániku. Pro existující objekty (STAV = 1) je vždy NULL.

ADRESA Tabulka všech adres v ČR (existujících i zaniklých). Pro každou adresu obsahuje časově poslední platné hodnoty atributů OBJEKT_KOD, ULICE_KOD, CISOR_HOD, CISOR_PIS a PSC. Datový typ

1

2

3 4

5

6

7

8

9

10

11

ADRESA_KOD Kód adresy jednoznačný v celé tabulce i v čase s kontrolní číslicí v řádu jednotek vypočtenou metodou MODULO 11 - ADDO. Je generován počítačem tak, že nové adresy mají kód (bez kontrolní číslice) o 1 vyšší než nejvyšší hodnota ADRESA_KOD v tabulce. OBJEKT_KOD Kód mateřského objektu adresy z tabulky OBJEKT. Pro každý objekt z tabulky OBJEKT existuje alespoň jedna jeho adresa v tabulce ADRESA. ULICE_KOD Kód mateřské UVP adresy z tabulky ULICE. CISOR_HOD Hodnota čísla orientačního dle SIS adresy v mateřské UVP. Je-li ULICE_KOD = NULL, je i CISOR_HOD = NULL. CISOR_PIS Koncové písmeno dle SIS čísla orientačního adresy v mateřské UVP. Je-li CISOR_HOD = NULL, je i CISOR_PIS = NULL. PSC PSČ doručovací pošty adresy z tabulky POSTA. NULL značí, že Česká pošta na tuto adresu zásilky nedoručuje. STAV 1 = adresa v současnosti existuje 2 = adresa existovala v minulosti a již zanikla 3 = adresa nikdy neexistovala a byla vložena omylem VZNIK_DNE Datum právní platnosti vzniku adresy. NULL značí neznámé datum vzniku. VZNIK_INFO Nestrukturované doplňující informace o vzniku adresy z hlášení o vzniku. ZANIK_DNE Datum právní platnosti zániku adresy. NULL značí neznámé datum zániku. Pro existující adresy (STAV = 1) je vždy NULL. ZANIK_INFO Nestrukturované doplňující informace o zániku adresy z hlášení o zániku. Pro existující adresy (STAV = 1) je vždy NULL.

Max. délka

Povinný

ČÍSLO

9

ANO

ČÍSLO

9

ANO

ČÍSLO

7

NE

ČÍSLO

3

NE

ZNAKY

1

NE

ČÍSLO

5

NE

ČÍSLO

1

ANO

DATUM

TEXT

NE

254

DATUM

TEXT

NE

NE

254

NE

11

Příloha č. 2 Technické dokumentace – Ukázka vzoru dokumentu

MĚSTSKÝ ÚŘAD ODBOR VÁŠ DOPIS ZN: ZE DNE: NAŠE ZN.:

žadatel

VYŘIZUJE: TEL.: FAX: E-MAIL: DATUM:

Věc : Rozhodnutí o přerušení řízení

Rozhodnutí Dne č.

jste podal(a) žádost o vydání závazného stanoviska ve věci . Objekt je nemovitou kulturní památkou zapsanou v ústředním seznamu pod rej. a je umístěn uvnitř městské ( vesnické) památkové zóny .

Předložená žádost neposkytuje dostatečné podklady pro vydání rozhodnutí. Podle § 19 odst. 3 zák. č. 71/67 Sb. o správním řízení Vás Městský úřad , odbor vyzývá, abyste v přiměřené lhůtě ode dne doručení rozhodnutí odstranil nedostatky podání tím, že podklady pro rozhodnutí doplníte o: 1/ Doklad o vlastnictví objektu, který je předmětem řízení 2/ Podle § 14 zák. č. 20/87 Sb. předložte 2x projektovou dokumentaci, která je nezbytná k vydání stanoviska , 1x současný stav objektu ev. doplňte fotodokumentací současného stavu. Z uvedených důvodů Městský úřad odst. 1 zák.č. 71/67 Sb. řízení

, odbor

, podle § 29

p ř e r u š u j e. Odůvodnění Řízení bylo zahájeno dnem podáním žádosti o závazné stanovisko u Městského úřadu , odboru . Podle § 14 odst.1 zákona č. 20/87 Sb. o státní památkové péči je pro stavební povolení i pro práce prováděné na základě ohlášení nezbytné závazné stanovisko výkonného orgánu státní památkové péče, odboru Městského úřadu , které se vydává formou rozhodnutí, ale protože Vaše žádost neobsahuje potřebné údaje, bylo nutno prakticky ihned po zahájení řízení toto přerušit. Po dobu přerušení řízení lhůta podle zákona č. 71/67 Sb. neběží. Správní orgán bude v řízení pokračovat, jakmile pominou překážky, pro které bylo řízení přerušeno.

Poučení Proti rozhodnutí o přerušení řízení se podle § 29 odst. 3 zák. č. 71/67 Sb. nelze odvolat.

jméno vedoucí odboru

Na vědomí: NPÚ, územní odborné pracoviště v Plzni

harmonogram prací ýást Ĝešení Analýza Návrh konzistentní datové základny Návrh Ĝešení a nasazení Ĝešení VytvoĜení základního rámce pro autentizaci a autorizaci VytvoĜení základních agend – správy hlavních þíselníkĤ DoplnČní vazby základních þíselníkĤ na zásadní související data tĜetích stran – UIR, katastr ěešení systému evidence obrazových pĜíloh a jejich vazby k hlavním þíselníkĤm (Systém obrazových pĜíloh k hlavním þíselníkĤm, komplexní správa) Interface pro prezentaci dat na internetovém portálu (systém URL adres, vazba na portál ohlednČ obrazových pĜíloh a vybraných položek hlavních þíselníkĤ) VytvoĜení správy všech souvisejících þíselníkĤ ěešení podatelny a vazby na systémy podatelen tĜetích stran Technologie šablon pro všechny agendy Agendy vyjádĜení, rozhodnutí, vázané na základní þíselníky Agendy rozhodnutí o finanþním pĜíspČvku a jejich specifické funkce dle legislativy Agenda systému dotací Vazba na externí systém správy dotací PĜílohy k vyjádĜením/rozhodnutím a jejich správa Aplikace automatické tvorby dokumentĤ ke každé agendČ a jejich verzování DoplnČní hlavních þíselníkĤ o vazby na kartografická data – Google maps, GIS ěešení pĜíloh ke všem hlavním þíselníkĤm (vþetnČ Ĝešení pĜíloh k podáním) ěešení pĜíloh ke všem výkonným agendám Vazba na systém Monumnet (spolupráce s NPÚ) Základní sestavy Transformace dat ěešení pĜevodu dat mezi pĤvodní a novou datovou základnou Testování aplikace SpuštČní do pilotního provozu Celkem

Doba realizace ve dnech 6 5 7 7 6 1 7 5 7 5 4 4 5 5 4 4 4 3 2 4 5 3 20 123

ParalelnČ zpracovávaná doprovodná þást - proškolení Tvorba screenshotĤ pro nápovČdu Základní popis fungování systému PĜíprava souboru testovacích otázek pro learning Tvorba videoshotĤ Kompletace beta verze - pĜípadný tisk Celkem

5 7 3 5 7 27

ParalelnČ zpracovávané vazby na základní registry Analýza legislativy Analýza datových struktur a jejich doplnČní z pohledu ZR PĜíprava potĜebného interface ZaþlenČní interface do aplikace Administrativní kroky (zajištČní pĜístupu k rozhraní), testování interface. Celkem

2 1 4 4 3 14

Technické Ĝešení - popis Základní popis celkové architektury navrhovaného Ĝešení 1. Jádro systému Jádrem celého systému bude webová aplikace, postavená na .NET4 frameworku. Uživatelské rozhraní bude Ĝešeno pomocí komerþních ASP AJAX komponent, pro javascriptovou komunikaci s webovými službami na pozadí. 2. Data Webová aplikace bude komunikovat s datovým skladem, postaveným na MS SQL serveru. Veškerá logika aplikace bude pokud možno Ĝešena na stranČ SQL databáze. Tedy pomocí T-sql procedur, funkcí, spouští. Tím se vyhneme roztĜíštČnosti, která (patrnČ) existuje ve stávajícím Ĝešení. SQL databáze bude tedy zajišĢovat pro aplikaci: - ukládání základních dat - ukládání binárních dat - þtení dat pro webové formuláĜe - aktualizace a mazání vČt - potĜebné výpoþty - integritu dat - þtení dat pro reporty 3. Reporty Veškeré reporty budou zajištČny standardním využitím MS Reporting Services. Reporty budou pĜístupné ve webové aplikaci pomocí MS Reporting Viewer, který zajistí i autorizaci k jejich prohlážení. 4. Komunikace s tĜetími stranami V pĜípadČ on-line komunikace, vyvolané pĜímo uživatelem (jeho þinností), se bude o obsluhu pĜíslušných interface starat pĜímo internetová aplikace. PravidelnČ vykonávané akce (komunikace, pumpování dat apod.) budou Ĝešeny DLL knihovnou, bČžící jako služba. Je to z toho dĤvodu, že internetová aplikace vykonává þinnost pouze pĜi podnČtu z klienta (browseru). 5. Využití základních registrĤ (ZR) pro úþely vyvíjené aplikace Aplikace bude navržena tak, aby podpora informací základních registrĤ nebyla mandatorní složkou fungování základních procesĤ vyvíjené aplikace. Jedním z dĤvodĤ je oficiální spuštČní k 1.7.2012, což z našeho pohledu nezaruþuje dostateþný prostor na bezchybný vývoj a perfektní otestování. Aplikace nebude ani v jedné z využitých oblastí (ROS, ROB, RUIAN) fungovat jako editor ZR. Datová základna bude upravena tak, aby bylo možné uchovávat zdrojové a agendové identifikátory. Tím dojde k oddČlení jednotlivých složek dat subjektĤ tak, aby byla zajištČna ochrana osobních údajĤ. Vazba na ZR se dotkne následujících agend: - vlastníci památek ... vazba do ROS,ROB tak, aby nebylo nutné aktualizovat ruþnČ údaje o aktuálním vlastníkovi

- podání/žadatelé ... ovČĜení žadatele resp.pomoc pĜi vyplĖování údajĤ o žadateli týká se ROS, ROB (pokud se bude jednat o ROB, bude vhodné ovČĜit via ZR, zda má žadatel zĜízenu datovou schránku) - památky, zóny a jejich zaþlenČní na úroveĖ adresního bodu (vazba na UIR, RUIAN, nejlépe via IS KÚ tak, jak je zmínČno v zadávací dokumentaci)

SMLOUVA O DÍLO. Programové vybavení pro výkon státní správy v oblasti památkové péče

Recommend Documents