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: Xxxxxxxxx 00, 000 00 Xxxxx

IČ: 70890366

DIČ: CZ 70890366

zastoupený: Xxxxxxx Xxxxxxxxx, 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: Xxx Xxxxxx, náměstek hejtmana

bankovní spojení: Raiffeisenbank a.s., pobočka Plzeň č.ú.: 1083003606/5500

kontaktní osoba: Xxxxxxx Xxxxx, vedoucí oddělení aplikací a databází, odbor informatiky,

Krajský úřad Plzeňského kraje

telefon: x000 000 000 000, x000 000 000 000

e-mail: xxxxxxx.xxxxx@xxxxxxxx-xxxx.xx

(dále jen „objednatel“, „zadavatel“)

1.2. Obchodní jméno: Softech, spol. s r.o.

se sídlem / místem podnikání: Xxxxxxxx xxxxxxx 0, 000 00 Xxxxx IČ: 45330018

DIČ: CZ45330018

zastoupený/jednající: RNDr. Xxxxx Xxxx bankovní spojení: Raiffeisenbank a.s. č.ú.: 68009001/5500

zapsán v obchodním rejstříku, vedeném Krajským soudem v Plzni, oddíl C, xxxxxx č. 1522 kontaktní osoba: RNDr. Xxxxx Xxxx

telefon: 000 000 000

e-mail: xxxx@xxxxxxx.xx

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

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.

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.

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.

Č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í).

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. Xxxxxxxxxx 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.

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

7.1.1. Xxxxxxxxxx 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 Xxxxxxxxx 00, 000 00 Xxxxx. Za objednatele je oprávněn hotové dílo převzít a akceptační protokol podepsat Xx. Xxxxxx Xxxxxxxxx, 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,

• 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, xxxxxxx však výlučně k účelu, ke kterému bylo takové dílo zhotovitelem vytvořeno v souladu se smlouvou a to v rozsahu minimálně nezbytném pro řádné užívání díla objednatelem,

⮚ licenci 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. Xxxxxxxxxx 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.

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ě.

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.

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. Xxxxx Xxxx Xxx Xxxxxx

jednatel společnosti Softech spol. s r.o. náměstek hejtmana Plzeňského kraje

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

Obsah:

1 ZÁKLADNÍ INFORMACE 4

1.1 Obsah a cíl zadání projektu 4

1.2 Platforma/klient 4

1.3 Automatizovaná tvorba dokumentů 4

1.4 Základní sada výchozích šablon 4

1.5 Kdo bude produkt využívat 4

1.6 Funkce 4

1.7 Základní správa nutné datové základny 5

1.8 Dokumentace a další přílohy 5

1.9 Správa obrazové dokumentace 5

1.10 Vazba na produkty třetích stran 5

1.11 Vazba na systém základních registrů veřejné správy 5

1.12 Data mining 6

1.13 Transformace a konsolidace stávajících dat 6

1.14 Serverová platforma/technologie 6

1.15 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

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 Uživatelská dokumentace 21

8.2 Dokumentace pro správce 21

8.3 Bezpečnostní dokumentace 21

8.4 Online nápověda 21

9 PŘÍLOHY 22

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í

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 xxx.xxxxxxxxxx.xx 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.

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 xxxx.Xxxxxxxxx (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,

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.

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.

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ů).

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, XXX, RÚIAN

• Link do aplikace katastru nemovitostí

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

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é

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ů,

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ů.

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:

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 xxxx://xxxxxx.xxxxxxxx-xxxx.xx.

6.13.1 Import dat bude probíhat ve dvou rovinách

• ATHENA (specifická pole z podatelny)

• 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)

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 Požadavky

• 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 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).

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

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 Přílohy budou k dispozici v těchto agendách

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

6.19 Vazba na systém Monumnet

Vazba na systém NPÚ – Monumnet (xxxxxxxx.xxx.xx) 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).

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í.

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:

xxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxxxxxx:XXXXX_Xxxxxxx

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 Xxxxx 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.

9 Přílohy:

• Příloha č. 1 Technické dokumentace – Struktura datové základny

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

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

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	tabulky
památky		historie	kultura.pamatky kultura.hist_pamatky
	přílohy	historie	kultura.obrazkypam kultura.hist_obrazkypam
pam.chr.území (zóny)		historie	kultura.zony kultura.hist_zony
	přílohy	historie	kultura.obrazkyzon kultura.hist_obrazkyzon
ochranná pásma (pásma)		historie	kultura.pasma kultura.hist_pasma
	přílohy	historie	kultura.obrazkypas kultura.hist_obrazkypas
podání		historie	kultura.zadosti kultura.hist_zadosti
	přílohy	historie	kultura.zadostiprilohy kultura.hist_zadostiprilohy
rozhodnutí k památkám		historie	kultura.rozh_pam kultura.hist_rozh_pam
	dokumenty	historie	kultura.dokument_rp kultura.hist_dokument_rp
rozhodnutí k pam.chr.ú./ochr.pásmům		historie	kultura.rozh_zon kultura.hist_rozh_zon
	dokumenty	historie	kultura.dokument_rz kultura.hist_dokument_rz
rozhodnutí o fin.příspěvku		historie	kultura.rozh_fin kultura.hist_rozh_fin
	dokumenty	historie	kultura.dokument_rf kultura.hist_dokument_rf
archeologická vyjádření		historie	kultura.vyjarch kultura.hist_vyjarch
	dokumenty	historie	kultura.dokument_va kultura.hist_dokument_va
ostatní agenda		historie	kultura.ostagenda kultura.hist_ostagenda
	přílohy	historie	kultura.oagendaprilohy kultura.hist_oagendaprilohy
	dokumenty	historie	kultura.dokument_oa kultura.hist_dokument_oa
vyjádření NPÚ		historie	kultura.vyjspu kultura.hist_vyjspu
	dokumenty	historie	kultura.dokument_vs kultura.hist_dokument_vs
Seznam č.parcelních+poznámka k památce			kultura.pam_poz_parcely
Seznam č.popisných+poznámka k památce			kultura.pam_pop_cisla
Seznam č.parcelních+poznámka k zóně			kultura.zon_poz_parcely
Seznam č.popisných+poznámka k zóně			kultura.zon_pop_cisla
Seznam č.parcelních+poznámka k pásmu			kultura.pas_poz_parcely
Seznam č.popisných+poznámka k pásmu			kultura.pas_pop_cisla

Agenda památky

Název položky	Typ	Poznámka
PAM_KOD_PAMATKY	char	Jednoznačný identifikátor (navrhovaný ručně)
PAM_REJSTRIKOVE_CISLO_US	char
PAM_REJSTRIKOVE_CISLO_SS	char
PAM_KAUZA	char	Číslo kauzy dle NPÚ
PAM_NAZEV_PAMATKY	char
PAM_ZONA_CISLO_JEDNACI	char	Vazba na tabulku ZONY
PAM_OP_CISLO_JEDNACI	char	Vazba na tabulku PASMA
PAM_VYUZITI	char	Výběr z číselníku DR_VYUZITI
PAM_KATASTR	int	Vazba na katastr
PAM_CASTI_PAMATKY	memo
PAM_VLASTNICI	memo
PAM_UZIVATELE	memo
PAM_POZNAMKA	memo
PAM_MOVITA	logical
PAM_KOD2_PAMATKY	char	Svázání movitých a nemovitých památek
PAM_HTML	memo
PAM_ZAKL_POPIS	text
PAM_VYHLASIL	char	Kdo a kdy prohlásil památku
PAM_KDY	datum	Kdo a kdy prohlásil památku
PAM_STAV	char	Odkaz do číselníku STAV_PAM (pam.ochrana)
PAM_OKRES_KOD	int	Začlenění památky dle UIR
PAM_OBEC_KOD	int
PAM_MCAST_KOD	int
PAM_COBCE_KOD	int
PAM_OBJEKT_KOD	int
PAM_ADRESA_KOD	int

Xxxxxx xxxx (pam.chr.území)

Název položky	Typ	Poznámka
ZON_CISLO_JEDNACI	char
ZON_NAZEV_ZONY	char
ZON_TYP	char	Výběr z číselníku TYPYZON
ZON_VYHLASIL	char
ZON_KDY	datum
ZON_REJ_CISLO	char
ZON_POZNAMKA	memo
ZON_POPIS	memo
ZON_OKRES_KOD	int	začlenění dle UIR
ZON_OBEC_KOD	int	začlenění dle UIR

Agenda pásma (ochr.pásma)

Název položky	Typ	Poznámka
OP_CISLO_JEDNACI	char
OP_ZONA_CISLO_JEDNACI	char	Vazba na zóny (tabulku ZONY)
OP_NAZEV_ZONY	char
OP_TYP	Char	Výběr z číselníku TYPYZON

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	začlenění dle UIR

Agenda podání

cislo_jednaci	Char
datum_podani	Datum
zadatel_kod	char	Vazba do číselníku ZADATELE
zadatel	memo	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).
termin_ano_ne	logical
termin_dny	num
ve_věci	char
Vyrizeno	logical
Ukladaciznak	char	Vazba do číselníku ZNAK
vyrizeno_dne	datum
Vyridil	char	Buď vazba, nebo přímo jméno či značka
vypraveno_dne	datum
obsah_spisu	memo
Okres_kod	Int	Výběr z číselníku UIR (z důvodu filtrování dle okresu)

Agenda rozhodnutí k památkám

ev_cislo	char
cislo_jednaci	char	Vazba na žádosti (podání)
datum_vydani	datum
vyrizuje	char
doruceno_dne	datum
pravni_moc_od	datum
kod_pamatky	char
vyj_pu	char
vydano_pu	datum
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 rozhodnutí k zóně/pásmu

ev_cislo	char
cislo_jednaci	char	Vazba na žádosti (podání)
datum_vydani	datum
vyrizuje	char
doruceno_dne	datum
pravni_moc_od	datum

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	char
cislo_jednaci	char	Vazba na žádosti (podání)
datum_vydani
vyrizuje	char
doruceno_dne
pravni_moc_od
kod_pamatky	char	Vazba na památky
kod_zony	char	Vazba na zóny
Kod_pasma	char	Vazba na pásma
druh_vlastnika	Char	Výběr z číselníku DR_DOTACE
druh_dotace	char	Výběr z číselníku DR_VLASTNIKU
naklad_celkem	num
fin_prispevek	num
fin_podil_vlastnika	num
fin_prispevek_p	num
fin_podil_vlastnika_p	num
odvolani	logical
Okres_kod	Int	Výběr z číselníku UIR (z důvodu filtrování dle okresu)

Agenda arch.vyjádření

ev_cislo	char
cislo_jednaci	char	Vazba na žádosti (podání)
datum_vydani	datum
vyrizuje	char
doruceno_dne	datum
nalez	logical
uhrada	char
druhnalezu	char
mistoulozeni	char
Okres_kod	Int	Výběr z číselníku UIR (z důvodu filtrování dle okresu)

Agenda „ostatní agenda“

ev_cislo	char
cislo_jednaci	char	Vazba na žádosti (podání)
datum_vydani	datum

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	char
cislo_jednaci	char	Vazba na žádosti (podání)
datum_vyrizeni	datum
Kod_pamatky	char	Vazba na PAMATKY
kod_zony	char	Vazba na ZONY
Kod_pasma	char	Vazba na PASMA
objekt_c	char
parcela_c	char
typ	char	Vazba do číselníku TYPYROZHODNUTI
katastr	int	Vazba na KATASTR
Okres_kod	Int	Výběr z číselníku UIR (z důvodu filtrování dle okresu)
Datum_zadosti	datum
C_jednaci_zadosti	char
Druh_vyjadreni	Char	Vazba na DRUHYVYJADRENI
Vyrizuje	Char	Možnost výběru více jmen z číselníku VYRIZUJE
Rozhodnuti_cislo	char	Pro doplnění jediného čísla rozhodnutí, které na základě tohoto vyjádření bude vydáno
Rozhodnuti_vydano	char
Rozhodnuti_dne	datum
projektant	char	Vazba do číselníku PROJEKTANT
firma	char	Vazba do číselníku FIRMA
restaurator	char	Vazba do číselníku RESTAURATOR
Prilozena_pd	Xxxx	Xxxxxxxxx projektová dokumentace

Seznam základních číselníků

Asociace			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).
Dr_dotace
Dr_vlastnika
Dr_vyuziti
Stav_pam
Typyrozhodnuti
Typyzon
Users
Znak
Druhyvyjadreni	Dv_druh	char	Číselník druhů vyjádření.
Vyrizuje	Vyr_jmeno	char	Číselník osob, které se podílejí na vyřizování agend.
Projektant	Pr_kod	char	Číselník projektantů.
	Pr_text	memo
Firma	Fi_kod	Char	Číselník firem.
	Fi_text	memo
Restaurátor	Re_kod	char	Číselník restaurátorů.
	Re_text	memo
Zadatele	Za_kod	char	Číselník žadatelů.
	Za_text	memo

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 xxxx://xxxxx.xxxx.xx/xxx/xxxxx/xxxxx.xxx .

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	Max. délka	Povinný
1	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.	ČÍSLO	4	ANO
2	NAZEV Název okresu. Je jednoznačný (bez ohledu na velikost písmen) v rámci všech existujících okresů v tabulce.	ZNAKY	32	ANO
3	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.	ZNAKY	16	ANO
4	STAV 1 = okres v současnosti existuje 2 = okres existoval v minulosti a již zanikl 3 = okres nikdy neexistoval a byl vložen omylem	ČÍSLO	1	ANO
5	VZNIK_DNE Datum právní platnosti vzniku okresu. NULL značí neznámé datum vzniku.	DATUM	NE
6	VZNIK_INFO Nestrukturované doplňující informace o vzniku okresu z hlášení o vzniku.	TEXT	254	NE
7	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.	DATUM	NE
8	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.	TEXT	254	NE
3	OBEC 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	Datový typ	Max. délka	Povinný
1	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.	ČÍSLO	6	ANO
2	OKRES_KOD Kód mateřského okresu obce z tabulky OKRES.	ČÍSLO	4	ANO
3	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.	ZNAKY	48	ANO
4	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.	ZNAKY	16	ANO
5	STAV 1 = obec v současnosti existuje 2 = obec existovala v minulosti a již zanikla 3 = obec nikdy neexistovala a byla vložena omylem	ČÍSLO	1	ANO
6	VZNIK_DNE	DATUM	NE

Datum právní platnosti vzniku obce. NULL značí neznámé datum vzniku.
7	VZNIK_INFO Nestrukturované doplňující informace o vzniku obce z hlášení o vzniku.	TEXT	254	NE
8	ZANIK_DNE Datum právní platnosti zániku obce. NULL značí neznámé datum zániku. Pro existující obce (STAV = 1) je vždy NULL.	DATUM	NE
9	ZANIK_INFO 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.	TEXT	254	NE
17	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	Max. délka	Povinný
1	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.	ČÍSLO	6	ANO
2	OBEC_KOD Kód mateřské obce městské části z tabulky OBEC.	ČÍSLO	6	ANO
3	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.	ČÍSLO	4	NE
4	TYP typ prvku: 1 = městská část , 2 = městský obvod, 3 = nečleněná část obce	ČÍSLO	1	ANO
5	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.	ZNAKY	48	ANO
6	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.	ZNAKY	16	ANO
7	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	ČÍSLO	1	ANO
8	VZNIK_DNE Datum právní platnosti vzniku městské části. NULL značí neznámé datum vzniku.	DATUM	NE
9	VZNIK_INFO Nestrukturované doplňující informace o vzniku městské části z hlášení o vzniku.	TEXT	254	NE
10	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.	DATUM	NE
11	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.	TEXT	254	NE
5	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	Max. délka	Povinný
1	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	6	ANO

2	OBEC_KOD Kód mateřské obce části obce z tabulky OBEC.	ČÍSLO	6 ANO
10	MCAST_KOD 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.	ČÍSLO	6 NE
3	NAZEV 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.	ZNAKY	48 ANO
4	ZKRATKA 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.	ZNAKY	16 ANO
5	STAV 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	ČÍSLO	1 ANO
6	VZNIK_DNE Datum právní platnosti vzniku části obce. NULL značí neznámé datum vzniku.	DATUM	NE
7	VZNIK_INFO Nestrukturované doplňující informace o vzniku části obce z hlášení o vzniku.	TEXT	254 NE
8	ZANIK_DNE 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.	DATUM	NE
9	ZANIK_INFO 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.	TEXT	254 NE
9	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	Max. délka Povinný
1	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.	ČÍSLO	9 ANO
2	COBCE_KOD Kód mateřské části obce objektu z tabulky COBCE.	ČÍSLO	6 ANO
3	CISDOM_TYP Typ čísla domovního dle SIS objektu v mateřské části obce: 1 = číslo popisné, 2 = číslo evidenční.	ČÍSLO	1 ANO
4	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.	ČÍSLO	4 ANO
5	STAV 1 = objekt v současnosti existuje 2 = objekt existoval v minulosti a již zanikl 3 = objekt nikdy neexistoval a byl vložen omylem	ČÍSLO	1 ANO
6	VZNIK_DNE Datum právní platnosti vzniku objektu. NULL značí neznámé datum vzniku.	DATUM	NE
7	VZNIK_INFO Nestrukturované doplňující informace o vzniku objektu z hlášení o vzniku.	TEXT	254 NE
8	ZANIK_DNE	DATUM	NE

Datum právní platnosti zániku objektu. NULL značí neznámé datum zániku. Pro existující objekty (STAV = 1) je vždy NULL.
9	ZANIK_INFO 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.	TEXT	254	NE
11	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	Max. délka	Povinný
1 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.		ČÍSLO	9	ANO
2 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.		ČÍSLO	9	ANO
3 ULICE_KOD Kód mateřské UVP adresy z tabulky ULICE.		ČÍSLO	7	NE
4 CISOR_HOD Hodnota čísla orientačního dle SIS adresy v mateřské UVP. Je-li ULICE_KOD = NULL, je i CISOR_HOD = NULL.		ČÍSLO	3	NE
5 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.		ZNAKY	1	NE
6 PSC PSČ doručovací pošty adresy z tabulky POSTA. NULL značí, že Česká pošta na tuto adresu zásilky nedoručuje.		ČÍSLO	5	NE
7 STAV 1 = adresa v současnosti existuje 2 = adresa existovala v minulosti a již zanikla 3 = adresa nikdy neexistovala a byla vložena omylem		ČÍSLO	1	ANO
8 VZNIK_DNE Datum právní platnosti vzniku adresy. NULL značí neznámé datum vzniku.		DATUM	NE
9 VZNIK_INFO Nestrukturované doplňující informace o vzniku adresy z hlášení o vzniku.		TEXT	254	NE
10 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.		DATUM	NE
11 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.		TEXT	254	NE

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

MĚSTSKÝ ÚŘAD

ODBOR

žadatel

VÁŠ DOPIS ZN: ZE DNE:

NAŠE ZN.:

VYŘIZUJE: TEL.:

FAX:

E-MAIL: DATUM:

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

R o z h o d n u t í

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 , odbor , podle § 29 odst. 1 zák.č. 71/67 Sb. řízení

p ř e r u š u j e. O d ů v o d n ě 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.

P o u č e n í

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í	Doba realizace ve dnech
Analýza
Návrh konzistentní datové základny	6
Návrh řešení a nasazení řešení
Vytvoření základního rámce pro autentizaci a autorizaci	5
Vytvoření základních agend – správy hlavních číselníků	7
Doplnění vazby základních číselníků na zásadní související data třetích stran – UIR, katastr	7
Ř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)	6
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ů)	1
Vytvoření správy všech souvisejících číselníků	7
Řešení podatelny a vazby na systémy podatelen třetích stran	5
Technologie šablon pro všechny agendy	7
Agendy vyjádření, rozhodnutí, vázané na základní číselníky	5
Agendy rozhodnutí o finančním příspěvku a jejich specifické funkce dle legislativy	4
Agenda systému dotací	4
Vazba na externí systém správy dotací	5
Přílohy k vyjádřením/rozhodnutím a jejich správa	5
Aplikace automatické tvorby dokumentů ke každé agendě a jejich verzování	4
Doplnění hlavních číselníků o vazby na kartografická data – Google maps, GIS	4
Řešení příloh ke všem hlavním číselníkům (včetně řešení příloh k podáním)	4
Řešení příloh ke všem výkonným agendám	3
Vazba na systém Monumnet (spolupráce s NPÚ)	2
Základní sestavy	4
Transformace dat
Řešení převodu dat mezi původní a novou datovou základnou	5
Testování aplikace	3
Spuštění do pilotního provozu	20
Celkem	123

Paralelně zpracovávaná doprovodná část - proškolení
Tvorba screenshotů pro nápovědu	5
Základní popis fungování systému	7
Příprava souboru testovacích otázek pro learning	3
Tvorba videoshotů	5
Kompletace beta verze - případný tisk	7
Celkem	27

Paralelně zpracovávané vazby na základní registry
Analýza legislativy	2
Analýza datových struktur a jejich doplnění z pohledu ZR	1
Příprava potřebného interface	4
Začlenění interface do aplikace	4
Administrativní kroky (zajištění přístupu k rozhraní), testování interface.	3
Celkem	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,XXX 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)

Document Metadata

Table of Contents

SMLOUVA O DÍLO

Document Metadata