EET Specifikace projektu final_v22

Specifikace projektu Elektronická evidence tržeb

Verze: 1.22

Únor 2015

Tento dokument obsahuje 186 stran.

Ministerstvo financí České republiky


Strana 2 z 186

Obsah Manažerské shrnutí ................................................................................................................................. 9

Cíle projektu ......................................................................................................................................... 9

Principy projektu .................................................................................................................................. 9

Koncepční popis projektu .................................................................................................................. 10

Základní finanční ukazatele ............................................................................................................... 11

PR vnímání a koncept ....................................................................................................................... 12

Úvod ...................................................................................................................................................... 14

Účel dokumentu ................................................................................................................................. 14

Metodologie a přístup ........................................................................................................................ 14

Potřeba zpracování dokumentu ......................................................................................................... 15

Omezení zpracování dokumentu ....................................................................................................... 15

Specifikace projektu .............................................................................................................................. 16

Účel a cíle projektu ............................................................................................................................ 16

Výchozí situace .................................................................................................................................. 16

Kvantitativní odhad objemu transakcí ................................................................................................ 17

Legislativní východiska ...................................................................................................................... 20

Základní procesy evidence tržeb ........................................................................................................... 23

Registrace a evidence údajů a certifikátů o povinném subjektu ........................................................ 24

„Registrace“ poplatníka .................................................................................................................. 26

Ověření poplatníka ......................................................................................................................... 32

Změny údajů poplatníka ................................................................................................................. 35

Ukončení evidence (deaktivace) poplatníka .................................................................................. 35

„Registrace“ provozovny ................................................................................................................ 36

Změny údajů provozovny ............................................................................................................... 37

Zrušení provozovny ....................................................................................................................... 38

Evidence tržeb ................................................................................................................................... 39

Procesy Evidence tržeb ..................................................................................................................... 45

Dávková evidence tržeb ................................................................................................................. 50

Přístup poplatníka k vlastním agregovaným údajům ......................................................................... 51

Kontrola účtenky zákazníkem ............................................................................................................ 55

Nahlášení neobdržené účtenky zákazníkem ..................................................................................... 60

Kontrola ze strany FS a CS ............................................................................................................... 65

Specifikace ochranných prvků EET ....................................................................................................... 70

Technické a technologické řešení projektu ........................................................................................... 79

Logická architektura aplikace ............................................................................................................ 80

Metriky systému ................................................................................................................................. 83

Požadované provozní a SLA parametry ............................................................................................ 84



Strana 3 z 186

Specifikace provedení detailní analýzy ............................................................................................. 87

Funkční dekompozice ........................................................................................................................ 91

Komponenty Projektu EET ............................................................................................................. 91

Certifikační autorita ............................................................................................................................ 95

Požadavky na hardwarové prvky prostředí ..................................................................................... 106

Předběžný rozpočet systému EET a infrastruktury ......................................................................... 118

Řešení procesu správy a provozu služeb ........................................................................................ 121

Řešení bezpečnosti systému EET ................................................................................................... 123

Požadavky na monitoring a prostředí datových sálů pro systém EET ............................................ 137

Specifikace požadavků na testování systému ................................................................................. 142

Požadovaná architektura připojení do Internetu pro systém EET ................................................... 144

Analýza rizik......................................................................................................................................... 152

Identifikace rizik ............................................................................................................................... 152

Hodnocení rizik ................................................................................................................................ 154

Mapa rizik ......................................................................................................................................... 157

Eliminace rizik .................................................................................................................................. 158

Projektové řízení a projektový tým ...................................................................................................... 161

Organizace Projektu ........................................................................................................................ 162

Orgány projektu ........................................................................................................................... 162

Řídící komise a sponzor Projektu .................................................................................................... 163

Seznam projektových rolí a jejich základní specifikace: .............................................................. 163

Kompetence jednotlivých projektových týmů ................................................................................... 164

Řízení Projektu ................................................................................................................................ 168

Řízení rizik ....................................................................................................................................... 168

Řízení dodavatelů ........................................................................................................................ 168

Řízení problémů .............................................................................................................................. 169

Principy akceptace ........................................................................................................................... 169

Reporting a monitoring .................................................................................................................... 170

Komunikace v rámci projektu ........................................................................................................... 170

Schvalování výstupů ........................................................................................................................ 171

Řízení kvality ................................................................................................................................... 171

Ověřování výstupů projektu ............................................................................................................. 173

Správa a dokumentace projektu ...................................................................................................... 173

Účtenková loterie ................................................................................................................................. 176

Harmonogram projektu ........................................................................................................................ 178

Analýza přínosů a nákladů .................................................................................................................. 179

Přínosy ............................................................................................................................................. 179

Identifikace přínosů ...................................................................................................................... 179

Náklady ............................................................................................................................................ 181



Strana 4 z 186

Návratnost projektu v čase .............................................................................................................. 184

Přílohy .................................................................................................................................................. 185

Příloha č. 1 – Návrh obsahu datové věty účtenky ........................................................................... 185



Strana 5 z 186

Seznam obrázků Obrázek 1: Rozložení transakcí v týdnu ................................................................................................ 18 Obrázek 2: Průměr počtu transakcí za sekundu ................................................................................... 18 Obrázek 3: Základní procesy evidence tržeb ........................................................................................ 23 Obrázek 4: Případy užití poplatníka ...................................................................................................... 25 Obrázek 5: Případy užití Czech POINTu ............................................................................................... 26 Obrázek 6: Proces registrace poplatníka a jeho provozoven do EET .................................................. 31 Obrázek 7: Proces ověření poplatníka .................................................................................................. 33 Obrázek 8: Evidence tržeb - základní proces zaevidování tržby pokladníkem ..................................... 47 Obrázek 9: Evidence tržeb - zaevidování tržby v době 48 hodin po vystavení účtenky (v případě zjednodušeného režimu 120 hodin) pokladníkem ................................................................................. 48 Obrázek 10: Evidence tržeb - zaevidování tržby v době 48 hodin po vystavení účtenky (v případě zjednodušeného režimu 120 hodin) automatizovaně na straně koncového zařízení ........................... 49 Obrázek 11 Zobrazení agregovaných dat ............................................................................................. 53 Obrázek 12: Kontrola účtenky zákazníkem ........................................................................................... 58 Obrázek 13: Proces nevydané účtenky zákazníkovi ............................................................................. 63 Obrázek 14: Proces kontrolní nákup ..................................................................................................... 68 Obrázek 15: Logická architektura EET .................................................................................................. 80 Obrázek 16: Vazby komunikačních a ostatních informačních systémů na systém EET a okolí ........... 89 Obrázek 17: Funkční dekompozice EET ............................................................................................... 91 Obrázek 18: Enterprise Service Bus ..................................................................................................... 94 Obrázek 19: Blokové schéma CA EET ................................................................................................. 95 Obrázek 20: Řešení CA EET ................................................................................................................. 96 Obrázek 21: Požadované použití rozhraní CA .................................................................................... 100 Obrázek 22: Procesy probíhající v Interní Certifikační Autoritě .......................................................... 100 Obrázek 23: minimální požadavek na síťovou konfiguraci CA EET ................................................... 102 Obrázek 24: Základní schéma zón systému EET ............................................................................... 107 Obrázek 25: Schéma logické komunikační infrastruktury systému EET ............................................. 108 Obrázek 26: Schéma aplikační a databázové vrstvy Varianty 1 ......................................................... 115 Obrázek 27:Schéma aplikační a databázové vrstvy Varianty 2 .......................................................... 116 Obrázek 28: Pojetí řešení procesu správy a provozu služeb .............................................................. 121 Obrázek 29: Schéma bezpečnostních činností a související dokumentace ....................................... 124 Obrázek 30: Schéma etapy 1 řešení bezpečnosti Systému EET ....................................................... 126 Obrázek 31: Schéma etapy 2 řešení bezpečnosti Systému EET ....................................................... 131 Obrázek 32: Schéma etapy 3 řešení bezpečnosti Systému EET ....................................................... 135 Obrázek 33: Monitoring systému EET ................................................................................................. 138 Obrázek 34 : Schéma zapojení s použitím adres více ISP ................................................................. 144 Obrázek 35 : Schéma přístupu POSu k serverům .............................................................................. 145 Obrázek 36 : Schéma zapojení pouze s IP adresami jednoho z ISP.................................................. 146 Obrázek 37 : Schéma zapojení s použitím směrovacího protokolu BGP ........................................... 146 Obrázek 38 : Schéma toku dat za normálního stavu sítě ................................................................... 147 Obrázek 39 : Schéma toku dat při výpadku linky k ISP ...................................................................... 147 Obrázek 40 : Schéma toku dat při výpadku zahraniční konektivity ISP .............................................. 149 Obrázek 41 : Schéma zapojení s vlastním AS .................................................................................... 149 Obrázek 42 : Schéma toku dat za normálního stavu sítě ................................................................... 150 Obrázek 43 : Schéma toku dat při výpadku linky k ISP ...................................................................... 150 Obrázek 44 : Schéma toku dat při výpadku zahraniční konektivity ISP .............................................. 151 Obrázek 45: Organizační struktura projektu ........................................................................................ 162 Obrázek 46: Roční náklady na projekt a výnosy z projektu v čase ..................................................... 184 Obrázek 47: Kumulativní náklady na projekt a výnosy z projektu v čase ........................................... 184



Strana 6 z 186

Pojmy a zkratky pojem význam ust. ZoET A autentizační údaje údaje sloužící k ověření identity účastníka pro

komunikaci se serverem EET, jedná se o údaje, na jejichž základě je systém EET schopen bezpečně rozeznat poplatníka, který se jimi identifikuje jedná se o přihlašovací údaje a certifikát

ČÁST DRUHÁ Hlava II, Díl 1 § 6 - § 9

B běžný režim viz evidence tržeb běžným způsobem BKP „bezpečnostní kód poplatníka“

vytvořený poplatníkem, který prokazuje jednoznačnou vazbu mezi poplatníkem a účtenkou

ČÁST DRUHÁ Hlava II, Díl 3 § 12

C D datová zpráva/datová věta specificky definovaný způsob elektronické komunikace

mezi pokladním zařízením poplatníka a serverem EET obsahuje údaje stanovené ZoET a prováděcím předpisem

ČÁST DRUHÁ Hlava II, Díl 3 § 11 odst. 1 písm. a)

DIČ daňové identifikační číslo slouží k identifikaci účastníka při styku se správcem daně


E EET „elektronická evidence tržeb“ pojem běžně užívaný IS EET Informační systém elektronické evidence tržeb ET „evidence tržeb“ pojem z legislativy název evidence tržeb běžným způsobem

evidenční povinnost, tj. odeslat nejpozději při uskutečnění transakce on-line datovou zprávu a vydat účtenku o transakci


evidenční povinnost kumulativní povinnost zaslat datovou zprávou/datovou větou údaje o této tržbě systému EET (správci daně) a vydat účtenku tomu, od koho evidovaná tržba plyne


evidenční povinnost ve zjednodušeném režimu

Taková evidenční povinnost, kdy povinnost odeslat systému EET (správci daně) datovou zprávu/datovou větu nemusí být splněna v okamžiku uskutečnění transakce, nýbrž nejpozději do 5 dnů od uskutečnění tržby

ČÁST DRUHÁ Hlava II, Díl 3 Oddíl 3 § 16

evidovaná tržba platba poplatníkovi, která je provedena stanoveným způsobem úhrady („hotovostí“) a zároveň se jedná o příjem z podnikání (resp. ze samostatné činnosti), který je předmětem daně z příjmů, není nahodilý, nepodléhá dani vybírané srážkou podle zvláštní sazby daně druhy: - platba hotovostí (bankovky, mince) - platba poukázkou, směnkou, šekem - platba uskutečněná plátcem prostřednictvím příjemce (typicky platba kartou)

ČÁST DRUHÁ Hlava I § 4

F FIK „fiskální identifikační kód“

identifikátor vytvořený systémem finanční správy na základě obdržené datové zprávy poplatníka, prokazuje zaevidování tržby v systému EET

ČÁST DRUHÁ Hlava II, Díl 3 § 1 odst. 2 písm. c)

G GFŘ Generální finanční ředitelství GŘC Celní správa České republiky



Strana 7 z 186

H I informační oznámení informuje v pokladním místě na viditelném místě o

tom, že osoba, od které plyne tržba, je povinna převzít účtenku

ČÁST TŘETÍ § 20 odst. 1

informační povinnost povinnost vyvěsit informační oznámení za podmínek a s náležitostmi stanovenými zákonem a prováděcím předpisem

ČÁST TŘETÍ

ISMS Systém řízení bezpečnosti informací J K koncové zařízení Informační systém nebo elektronické zařízení

poplatníka, které zasílá datové věty a přijímá FIK

kontrolní nákup nákup zboží nebo služeb za účelem zjištění plnění povinností poplatníkem

ČÁST DRUHÁ Hlava IV § 19

L M mezní doba odezvy časový úsek mezi pokusem o odeslání údajů o

evidované tržbě z pokladního (koncového) zařízení a přijetím FIK na zařízení stanoví poplatník tak, aby nemařil průběh evidence tržeb se zohledněním druhu a kvality internetového připojení při stanovení musí poplatník zohlednit čas na zpracování odezvy v systému EET v délce 2 s


MFČR Ministerstvo financí České republiky N O ověření účtenky právo osoby disponující údaji z účtenky způsobem

umožňujícím dálkový přístup ověřit, zda byla konkrétní účtenka vydána k tržbě evidované v evidenci tržeb a zda poplatník eviduje tržby ve zjednodušeném režimu

ČÁST DRUHÁ Hlava III § 18

oznamovací povinnost povinnost oznámit změnu v údajích, které jsou součástí žádosti o autentizační údaje


P pokladna, pokladní zařízení Viz koncové zařízení pokladní místo místo v provozovně, kde se evidované tržby přijímají

„běžně“ (je umístěno pokladní (koncové) zařízení) ČÁST TŘETÍ § 20 odst. 3

povolovací řízení směřuje k vydání povolení plnit evidenční povinnost ve zjednodušeném režimu u určitých typů tržby rozhoduje správce daně na návrh poplatníka

ČÁST ČTVRTÁ

provozovna místo, na kterém dochází k provozování činnosti, a které je účelové pro daný subjekt; vychází ze zákona č. 455/1991 Sb., živnostenský zákon, ve znění pozdějších předpisů (dále jen „živnostenský zákon“), kde je stanoveno, že provozovnou se pro účely zákona rozumí prostor, v němž je živnost provozována za provozovnu je považován taktéž automat nebo obdobné zařízení sloužící k prodeji zboží nebo poskytování služeb a mobilní provozovna

DZ, Zvláštní část, k § 35

překročení mezní doby odezvy

situace, kdy v důsledku technické závady, či dočasného výpadku připojení, prostého zhoršení úrovně přenosu, atp. poplatník neobdrží v jím stanovené lhůtě uběhlé od uskutečnění pokusu o odeslání údajů FIK a proto na jeho straně v daném případě není možné provést evidenci tržeb „on-line“ a poplatník má právo vydat účtenku bez FIK




Strana 8 z 186

původce tržby ten, kdo poskytuje tržbu - uhradil platbu za obdržené zboží nebo poskytnuté služby, zjednodušeně zákazník

ČÁST DRUHÁ Hlava III § 17

R registrační pokladna certifikované zařízení opatřené fiskální pamětí, (pozn.

není záměrem projektu EET evidovat tržby pouze prostřednictvím těchto zařízení)

S SPCS Státní pokladna centrum sdílených služeb, s. p. T U účtenka doklad o transakci splňující náležitosti stanovené ZoET

a prováděcím předpisem ČÁST DRUHÁ Hlava II, Díl 3 Oddíl 1 § 13

účtenková loterie hra, které se lze účastnit pouze na základě zaslání účtenek, doplňkové opatření jako pozitivní motivace příjemců účtenek

ČÁST SEDMÁ Hlava I § 41

V W X Y Z zjednodušený režim evidence

viz evidenční povinnost ve zjednodušeném režimu

ZoET zákon o evidenci tržeb



Strana 9 z 186

Manažerské shrnutí

V EU dochází každoročně v důsledku daňových podvodů, daňových úniků, vyhýbání se daňovým povinnostem a agresivního daňového plánování ke skandální ztrátě potenciálního daňového příjmu v odhadované výši 1 bilionu EUR, což představuje přibližně 2 000 EUR na každého evropského občana za rok. Česká republika není v tomto výjimkou.

Hlavní cíl téměř všech členských států EU je řešení daňového deficitu. Je cestou k postupnému vytváření podstatně vyšších příjmů z daní bez nutnosti zvyšování jejich sazeb.

Evropský parlament vyzval členské státy, aby vyčlenily odpovídající lidské zdroje, odborné poradenství a rozpočtové prostředky pro své vnitrostátní systémy daňové správy a pro pracovníky provádějící daňové audity a také zdroje pro odbornou přípravu zaměstnanců daňové správy v oblasti přeshraniční spolupráce týkající se daňových podvodů a vyhýbání se daňovým povinnostem a aby zavedly účinné protikorupční nástroje1.

Dále EP vybídl členské státy k vyhledávání „podezřelých“ údajů o daňových únicích z dalších registrů vedených státní správou, jako jsou databáze motorových vozidel, pozemků, jachet a dalších hmotných statků, a ke sdílení těchto údajů s ostatními členskými státy a Komisí.

Řešení daňového deficitu je jednou z priorit Vlády ČR obsažené v rámci programového prohlášení vlády ČR.

Jedná se mimo jiné o navržení legislativních a technických opatření směřujících k efektivní kontrole vykazovaných tržeb z maloobchodního prodeje zboží a služeb. Tato opatření zahrnou u vybraných subjektů online hlášení tržeb, povinnost vystavovat doklady s unikátním číslem a „účtenkovou loterii“ – tato opatření lze shrnout pod pojem Elektronická evidence tržeb.

Cíle projektu

Narovnání podnikatelského prostředí v České republice prostřednictvím eliminace nekalé konkurenční výhody subjektů, které krátí daňovou povinnost prostřednictvím nevykazování plné výše tržeb v rámci podnikatelské činnosti při prodeji zboží a služeb.

Získání dodatečného výnosu daní a pojistných od subjektů, které tyto povinnosti krátí prostřednictvím nevykazování plné výše tržeb.

Principy projektu

Otevřené řešení bez omezení z pohledu použitého hardware a software, neexistence povinné certifikace

Jednoduchost a rychlost zavedení, fungování v režimu 24/7 Minimalizace administrativní zátěže a nákladů podnikatelů Minimalizace zpomalení či omezení podnikání v konkrétním oboru Minimalizace nákladů státu, nikoliv však na úkor administrativní zátěže či nákladů podnikatelů Zapojení veřejnosti Pozitivní vnímání ze strany veřejnosti i podnikatelů Vnímání projektu EET jako součást širší iniciativy zaměřené k narovnání podnikatelského

prostředí a zlepšení daňové disciplíny

1 Zpráva o boji proti daňovým podvodům, daňovým únikům a daňovým rájům 3. května 2013 (2013/2060(INI)



Strana 10 z 186

Koncepční popis projektu

1. Hotovostní tržby za prodej zboží a služeb budou podléhat elektronické evidenci. 2. Příjemce tržby bude povinen tržbu [v reálném čase] elektronicky předem definovaným

způsobem nahlásit finanční správě. 3. Finanční správa z nově vybudovaného IT systému EET vygeneruje unikátní kód a odešle ho

zpět příjemci tržby. 4. Příjemce tržby má povinnost tento kód uvést na dokladu vystaveném zákazníkovi. 5. Budou existovat řešení pro případ dočasné nemožnosti spojení i trvalé evidence v off-line

režimu 6. Doklad bude možné využít pro „účtenkovou loterii“ a jeho kontrolu bude moci přes internet

provést i zákazník. 7. Za hotovostní tržby se považují i platby platebními kartami, poukázkami a obdobnými

prostředky. 8. Příjemce tržby bude mít možnost ověřit si rozsah tržeb zaevidovaných pod jeho identitou. 9. Příjemcům tržeb i dodavatelům SW/HW řešení bude k dispozici testovací prostředí a

podpůrná hot line, a to v dostatečném předstihu před spuštěním povinné evidence tržeb i po celou dobu existence povinné evidence tržeb.



Strana 11 z 186

Základní finanční ukazatele

Přínosy

Očekává se, že projekt EET přinese ročně až 10 – 15 mld. Kč. Tento předpoklad vychází z následujících odhadů:

Náklady

Jednorázové kapitálové investice se očekávají v rozmezí od 317 mil. Kč do 337 mil. Kč v návaznosti na zvolené řešení, která jsou uvedena v tabulce

Název položky IBM ORACLE MICROSOFT

Hardware 96 86 125

Software 102 115 62

Vývoj SW 32 32 32

Bezpečnost 15 15 15

PR 21 21 21

Školení 3 3 3

Certifikace subjektů 15 15 15

Call centrum 5 5 5

Implementace projektu 8 8 8

Ostatní 31 31 31

CELKEM v mil. Kč 328 337 317

Roční provozní náklady se odhadují v rozmezí od 308 mil. Kč do 395 mil. Kč v návaznosti na zvolenou variantu. Jednotlivé varianty řešení jsou zobrazeny v následující tabulce

Název položky IBM ORACLE MICROSOFT

Mzdové náklady 199 199 199

Údržba hardware 79 80 75

Call centrum 34 34 34

Kontrolní nákupy 30 30 30

PR 3 3 3

Údržba software 7 7 7

Housing 7 7 7

Ostatní 36 36 35

CELKEM v mil. Kč 395 308 390

Legenda:

Software: nastavení systémů ČP, procesní ICT, úpravy ADIS, aplikace EET

Ostatní investiční: auta, mobilní kanceláře, výstroj, technické prostředky, vybavení kanceláří, výzbroj, znalecké posudky, správní poplatky, osobní vozidla, mzdové náklady, poradenství

Ostatní provozní: obnova a provoz vozidel, obnova výstroje, obnova technických prostředků, nájmy, vybavení pracovišť



Strana 12 z 186

PR vnímání a koncept

Projekt EET bude vyvolávat velkou pozornost veřejnosti. Hladký průběh implementace ovlivní vnímání veřejností. Proto komunikace projektu počítá s aktivními media relations, informační kampaní ATL, spoluprací s oborovými svazy a opinion makery a informační podporou pro daňové subjekty (Call centrum). Těžištěm komunikace v první fázi je obhájení projektu – jeho smyslu (primárním cílem je narovnání podmínek férové soutěže a tržního prostředí v České republice). Druhá fáze začíná krátce před možností daňových subjektů se registrovat do systému a bude zaměřena na awarness a informační podporu hladkého startu systému. Veškerá komunikace se bude snažit přirozeným a nenásilným způsobem přesvědčit občany, že vyžadování placení daní je pro ně přínosné a využívání cest jak „ušetřit“ díky krácení daní v konečném důsledku poškodí životní komfort každého občana České republiky. Komunikační tým počítá i s krizovým komunikačním scénářem při selhání systému.

Externality

Komunikace projektu počítá s využitím většiny dostupných komunikačních kanálů

Media relations

systematická práce s medii. Tiskové konference, tiskové zprávy, autorské komentáře představitelů resortu, využívání třetích stran, vystoupení představitelů resortu v elektronických mediích, příprava podkladů pro autory zabývající se problematikou EET, reakce na kritické nebo zavádějící materiály.

ATL

tisková reklama, omezeně outdoor, TV a rozhlasová reklama na základě dohody s veřejnoprávními medii.

Elektronická media

www stránky projektu, bannerová reklama, reklama na FB. S ohledem na nízkou míru kontroly neuvažujeme s vlastní FB, Twitter stránkami projektu.

Spolupráce s významnými svazy

využití komunikačních kanálů významných profesních a oborových svazů (Horeka, SOCR, AMSP, Hospodářská komora ad.)

Informační linka/Call centrum

zajištění dvousměnného informačního servisu pro daňové subjekty.

Vytvoření značky/jména projektu

Testováním navrhovaných názvů ve dvou focus groups jsme dospěli ke značce e-tržby. S tímto názvem se bude operovat ve veškeré komunikaci.

Součástí komunikačního konceptu je i maximální využití 15 tisíc zaměstnanců resortu financí jako ambasadorů projektu. Proto počítáme s kontinuání interní komunikací na všechny zaměstnance resortu, a to formou newsletteru a podkladů a prezentací určených pro vedoucí pracovníky (ke kaskádování do organizace).

Termín spuštění 1. 1. 2016 může být ohrožen kvůli následujícím aspektům:

a) Způsob zadání a z toho vyplývající délka dodání jednotlivých částí systému EET b) Způsob zadání a z toho vyplývající délka dodání hardware (platformy) pro systém EET c) Realizace a zaškolení „front office“ činností (FÚ, Česká Pošta, Czechpointy) d) Nezbytná doba potřebná na úpravu stávajících pokladních systémů (odhadovaná doba 5-6

měsíců)



Strana 13 z 186

e) Neexistence prověrky SPCSS na stupeň utajení “Důvěrné“, které požaduje NBÚ na dodavatele



Strana 14 z 186

Úvod

Ministerstvo financí České republiky jako ústřední orgán státní správy zodpovědné za koordinaci Finanční správy. Finanční správa ČR je zřízena zákonem č. 456/2011 Sb., o Finanční správě České republiky, ve znění pozdějších předpisů, (dále jen „zákon č. 456/2011 Sb.“) a je tvořena soustavou orgánů finanční správy, které jsou podřízené Ministerstvu financí. Klíčovou součástí kompetence Finanční správy ČR je správa daní, ale zároveň vykonává široké spektrum dalších agend.

Ministerstvo financí ČR má zájem ve spolupráci s GFŘ pro zlepšení podnikatelského prostředí a zvýšení efektivity fungování Finanční správy a kontrolních mechanismů plnění daňových povinností zavést elektronickou evidenci tržeb (dále i jako EET) a evidovat příjem a výdej jednotlivých plateb ve formě bankovek a mincí nebo prostřednictvím elektronického platebního prostředku, ceniny nebo šeku. Tuto snahu projevilo i předložením návrhu zákona o evidenci tržeb.

Hlavním cílem evidence tržeb z pohledu finanční správy je získání informací, které zabezpečí lepší správu daní (zejména daní z příjmů a daně z přidané hodnoty). Základním cílem je narovnání podnikatelského prostředí tak, aby se minimalizovala konkurenční nevýhoda poctivých podnikatelů způsobená krácením daňových povinností ostatními daňovými subjekty.

Na základě zkoumání existujících modelů evidování transakcí, byl shledán jako nejvhodnější systém evidence tržeb, který v maximální možné míře preferuje kritérium jednoduchosti a nízké nákladovosti na straně povinných subjektů při zajištění spolehlivého a plnohodnotného plnění předpokládané funkce.

Cílem aktivit směřujících k vytvoření tohoto dokumentu bylo pochopit kvalitativní ale i kvantitativní rozměr projektu a specifikovat základní charakteristiky projektu ale i technického řešení.

Účel dokumentu

Účelem dokumentu je analyzovat východiskovou situaci a aspekty ovlivňující projekt EET a navrhnou způsob řešení, resp. specifikovat projekt.

Kromě projektových aspektů jako jsou rizika, organizační zabezpečení apod., obsahuje dokument i návrh základních principů řešení a jeho specifikací.

Dokument bude sloužit jako část zadávací dokumentace anebo dokumentace potřebné pro přípravu projektu.

Metodologie a přístup

Pro oblast analýz byly využity následující metodologie:

Analýza požadavků Projektové řízení (část analýzy východiska projektů) Řízení a správa rizik Rešerše technologických trendů Řízení přínosů (Benefit Management).

Pro oblast specifikace projektu byly využity následující metodologie:

Projektové řízení (část, plánování projektu) Řízení organizačních změn Řízení změn procesů.



Strana 15 z 186

Přístup byl zvolen minimalistický, tj. realizace minimálně nutného rozsahu pro identifikaci nejvýznamnějších vlivů na projekt, při zachování konzistentnosti a kvalitativní úrovně i možnosti dalšího rozvoje projektu podle budoucích potřeb.

Shodně byl i v návrhové části, v specifikaci projektu, zvolen minimalistický přístup a jsou uváděny jenom významné charakteristiky či aspekty projektu. Jsou však zahrnuty všechny charakteristiky a aspekty, které jsou klíčové pro naplnění cílů projektu a pro fungování systému v požadovaném rozsahu.

Minimalistický přístup by zvolen z důvodů realizace dalších analýz za účelem větší detailizace a podrobnější specifikace v následujících fázích projektu, např. v průběhu specifikace technického řešení realizátorem, nastavení plánu projektu projektovým týmem, následné legislativy atd.

Potřeba zpracování dokumentu

Specifikace projektu této úrovně je potřebná pro realizaci dalších kroků v přípravě projektu, realizaci obstarání či k vytvoření podzákonné legislativy – vyhlášek Ministerstva financí ČR.

Omezení zpracování dokumentu

Omezení zpracování dokumentu byli zejména:

Omezení časem. Z časových důvodů nebylo možné vykonat některé podrobné zkoumání, např. ověření odhadů materializovaných přínosů, či odhad přijetí projektu okolím projektu, zejména veřejností.

Omezení dostupností informací. Vzhledem k relativně novátorskému přístupu k řešení problematiky evidence tržeb nebyly dostupné informace a zkušenosti z více států s odstupem času jako faktoru ověřujícího koncept dlouhodobě. Odhad dopadů projektu a jejich materializace není možno porovnat s relevantním vzorkem obdobných projektů.

Omezení vedla k relativně vysoké míře abstrakce a použití obecně platných nejlepších odvětvových zkušeností, zejména v návrhové části - ve specifikaci potenciálních průvodních organizačních a podpůrných opatřeních projektu.

Navzdory omezením, je možno konstatovat, že rozsah posouzení a analýz je dostatečný pro přijetí manažerských rozhodnutí o projektu a realizaci následných aktivit.



Strana 16 z 186

Specifikace projektu

Účel a cíle projektu

Hlavním cílem evidence tržeb je z pohledu finanční správy získání informací, které zabezpečí lepší správu daní (zejména daní z příjmů a daně z přidané hodnoty). Základním cílem je narovnání podnikatelského prostředí tak, aby se minimalizovala konkurenční nevýhoda poctivých podnikatelů způsobená krácením daňových povinností ostatními daňovými subjekty.

Dopadem naplnění hlavního cíle bude mít předpokládaný dopad ve formě zlepšeného výběru dani, zejména daní z příjmů podnikatelů a DPH. Samozřejmě je možno počítat i s nárůstem daní z příjmů zaměstnanců, odvodů pojistného nebo spotřebních daní. Blíže viz Analýza přínosů a nákladů.

Dle metody stanovení cílů s kritériem SMART2 možno definovat cíl projektu následovně:

Zavést systém a podmínky pro elektronickou evidenci tržeb na straně finanční správy umožňující evidenci tržeb povinnými subjekty od začátku roku 2016.

Výchozí situace

Pro ukotvení projektu do prostředí je nutné vzít v potaz všechny důležité aspekty projektu. Jejich zhodnocení je uvedeno v následujících částech.

2 SMART – cíle jsou specifické (Specific), měřitelné (Measurable), vykonatelné / realizovatelné (Attainable), směřující k výsledku / záměru (Relevant) a ve specifickém čase (Time-bound).



Strana 17 z 186

Kvantitativní odhad objemu transakcí

Technologická východiska úzce souvisí s objemem zpracovaných transakcí.

Objem transakcí není v ČR nijak prozkoumán a žádné použitelné statistiky nejsou dostupné. Pro kvantifikaci jsme použili data z geograficky a kulturně blízké krajiny – Rakouska.

Ty jsme následně extrapolovali podle počtu obyvatel a zapracovali odchylku ve výši 20 %.

V rámci výzkumu3 objemu transakcí realizovaných obyvateli Rakouska byly zjištěny následující údaje:

Rakousko Počet obyvatel 8 400 000

Podíl Počet v mil.

Hotovostní platby 82% 12 110,68

Platby debetními a kreditními kartami 16% 2 363,06

Ostatní formy 2% 295,38

Celkem 14 769,13

Propočtem se dá určit průměrný počet transakcí jednoho obyvatele Rakouska na hodnotu 4,76 transakce denně. Propočtem dat z jiných zdrojů 4 byl počet transakcí stanoven na hodnotu 4,28 transakce na obyvatele a den. Pro porovnání, uvádíme i jiné země:

Země AT DE NL FR ČR* Počet transakcí na obyvatele a den 4,28 3,74 2,15 2,30 4,52 * propočet

Aproximací průměrné hodnoty Rakouska jsme získali hodnoty pro Českou republiku - objem cca 17 – 20 mld. transakcí ročně. Z tohoto propočtu jsme dále vycházeli.

Kromě kvantifikace počtu transakcí je nutné vzít potaz jejich rozložení v čase. Pro tenhle účel posloužili údaje z výše zmiňovaného průzkumu v Rakousku.

Počet transakcí byl rozložen do jednotlivých dní a rozdělen na dopolední a odpolední část na základě dat průzkumu.

pondělí úterý středa čtvrtek pátek sobota neděle

podíl na transakcích v týdnu

15% 14% 14% 15% 17% 16% 9%

z toho dopoledne 20,0 18,7 18,7 20,0 22,7 21,3 12,0

z toho odpoledne 32,6 30,5 30,5 32,6 37,0 34,8 19,6

Graficky znázorněno:

3 http://www.eea-esem.com/files/papers/EEA-ESEM/2014/1502/capd_masterfile.pdf 4 https://www.worldpaymentsreport.com/reports/noncash_inhabitant

Rozlož12:00)která zsekunpředpokalkulaje ilust

Dalšímmaximtransaobdob

Jak sev průb

žení v průb) nekorespozačíná stoudu rozdělili okládanýchace se špičtrován na n

m aspektemmální kumuakcí vůči pbná charakte

e dá odhadběhu víken

ěhu dne je onduje s typupat od 6:00

nerovnoměh transakcí čkami. Výchásledujícím

m, který je ulace transprůměrnémueristika špič

dovat, špičkdu před V

Obráze

opět nerovpickou křivk0 a utlumujěrně, s předdo tohoto č

hozí počet trm grafu.

Obrázek 2:

nutno zohakcí v času jsme počky i pro ho

ka v roce seVánocemi.

ek 1: Rozlože

vnoměrné. Dkou lidské ae se po 22dpokladem času je rovransakcí, kt

Průměr poč

lednit při ide, tzv. špi

oužili data otovostní pla

e v prostředPodle stat

S

ení transakc

Den rozdělektivity. Důk:00. Z tohottransakcí je

vněž uplatněteré bude m

čtu transakc

dentifikaci pičky. Pro sz transakc

atby.

dí Evropy vtistik společ

M

pecifikace pr

cí v týdnu

ený do dvouazem je nato důvodu jenom v časěním skept

muset systém

cí za sekund

počtu transstanovení

cí platebním

yskytuje v pčnosti VISA

Ministerstvo fi

rojektu Elekt

u stejných čpř. spotřebasme odhad

se od 6:00 dtického odhm zpracova

du

sakcí v časeodchylky š

mi kartami.

předvánočnA, špičkov

inancí České

ronická evide

Stran

částí (do 12a elektrické

d počtu trando 22:00. Khadu a ve pat za jednu

e je charakšpičkového . Předpokla

ním čase, nvý objem t

é republiky

ence tržeb

a 18 z 186

2:00 a od é energie, nsakcí za umulace

prospěch sekundu

kteristika objemu

adem je

nejčastěji ransakcí



Strana 19 z 186

odpovídá 4,54 násobku průměrných hodnot. Obráceně, v průměrný den je 22% transakcí oproti dni ve špičce roku. Jednalo se o tzv. Black Friday (čtvrtý pátek v listopady), což je tradičně den věnovaný nákupům v USA a Kanadě.

V České republice si prvenství v celkovém objemu tržeb však nadále drží platby uskutečněné prostřednictvím platební karty v kamenných obchodech. Podle společnosti Global Payments Europe byl počet transakcí v průběhu vánočních nákupů vyšší dvojnásobně.

GE Money Bank informovala, že počet transakcí byl v prosinci 2014 4,6 mil. Nejvyšší počet transakcí zaznamenán 22. prosince (332 tis.), to znamená, že k průměru za prosinec (148 tis.) byl počet transakcí v tento den na úrovni něco více než dvojnásobku (224%).

Rozložení transakcí v průběhu špičky není známo. Dá se ovšem předpokládat, že bude ještě zvýrazněno a nebude kopírovat rozložení průměrného dne. To znamená, že špička může být 3 a vícenásobná oproti běžným objemům transakcí.

Z tohoto důvodu je vhodné upravit výkonovou kapacitu centrálního systému na kapacitu osmi násobku předpokládané zátěže.

Propočtem na kapacitu zpracovaných transakcí systémem, s ohledem na špičky, je určena

cílová hodnota výkonnosti systému na 10 tisíc transakcí za sekundu.

S touto hodnotou je potřebné v projektu pracovat a projektovat technické a jiné výkonnostní kapacity systémů.



Strana 20 z 186

Legislativní východiska

Základním východiskem pro specifikaci projektu jsou:

Návrh zákona o evidenci tržeb Důvodová zpráva k návrhu zákona Analýza evidence tržeb elektronickými prostředky Programové prohlášení vlády Ostatní právní předpisy ČR Vyhláška

Návrh zákona

Navrhovaná právní úprava de facto doplňuje existující platné normy stanoveným směrem, a to zejména z hlediska způsobu a formy navazující na již dnes běžně prováděné úkony (zejména vedení určité evidence transakcí a vydávání dokladů zákazníkovi).

Obsahem navrhované právní úpravy, relevantní k specifikaci projektu jsou:

a) Vytvoření úložiště dat získaných v rámci evidence tržeb b) Vytvoření aplikační části systému EET a jejích modulů sloužících pro realizaci všech procesů

v rámci evidence tržeb od vstupu povinných subjektů do systému, testování, řešení změn, plnění i ukončení povinností, včetně portálu a certifikační autority

c) Zajištění adekvátní komunikační infrastruktury a dostatečně dimenzovaného připojení k internetu ze strany SPCSS pro zvládnutí výkonnostních provozních parametrů systému EET

d) Zajištění podmínek a prostředků pro orgány Finanční správy a Celní správy ČR pro plnění jejich kompetencí v rámci EET včetně kontrolní a analytické činnosti

e) Poskytnutí autentizačních údajů pro evidenci tržeb a získání údajů o povinném subjektu

Samozřejmě jsou navrhované právní úpravy, které jsou nutné pro vytvoření legislativního rámce projektu EET, zejména:

f) Stanovení obecné evidenční povinnosti g) Evidence tržeb probíhajících mezi stanovenými subjekty, za stanovených okolností

a stanoveným způsobem h) Uložení povinnosti vydání evidenčního dokladu povinným subjektem a povinnosti převzetí i) Sankce za nesplnění povinností daňovými subjekty j) Spolupráce orgánů veřejné moci při kontrole plnění vybraných povinností k) Účtenková loterie

V téhle části budeme vycházet z předpokladu, že návrh zákona o evidenci tržeb bude schválen tak, jak je předložen. Návrh zákona má následující dopady na projekt a definuje charakter projektu:

Navrhovaný stav / oblast Dopad na projektPlatba poplatníkovi Široce pojatá definice platby znamená prakticky všechny hotovostní

platby nebo i platy prostřednictvím platebního nástroje (např. kreditní karta) nebo i stravenek. Předpokládaný počet transakcí je uveden v části Chyba! Nenalezen zdroj odkazů..

Autentizační údaje Součástí projektu musí být i systém pro evidenci registrací provozoven povinných subjektů. Bude se jednat o několik stovek tisíc provozoven a rovněž povinných subjektů. Systém proto bude muset být automatizovaný. Povinnému subjektu budou automatizovaně zaslány autentifikační údaje pro přístup na samoobslužný portál EET, v případě kdy je držitelem datové schránky ISDS, následně pro přihlášení na portál EET může povinný subjekt zaevidovat své provozovny a získat elektronickou značku (certifikát) pro komunikaci



Strana 21 z 186

se systémem EET. V případě kdy povinný subjekt nedisponuje datovou schránkou ISDS, bude nezbytné získat autentifikační údaje prostřednictvím příslušné pobočky České pošty, pracoviště Czechpoint nebo výjimečně prostřednictvím na určeného pracoviště finančního úřadu. Tento proces bude nezbytné perfektně zvládnout z důvodu potřeby registrace většího počtu povinných subjektů během krátkého období.

Evidenční povinnost Evidenční povinnost podle § 11, ods. 1, písm. b) ustanovuje povinnost vydat účtenku. Dále však účtenku blíže nespecifikuje. Teoreticky je tedy možné vydat i účtenku ručně psanou, obsahující však všechny náležitosti požadované právními předpisy. Znamená to, že i živnostník, který vydává účtenku např. párkrát denně, může tržbu zaevidovat, např. prostřednictvím aplikace v telefonu, a „ručně vypsat“ účtenku obsahující fiskální identifikační kód.

Údaje na účtence V zákonu jsou definovány jenom dva údaje – bezpečnostní kód povinného subjektu a fiskální identifikační kód. V případě nedostupnosti systému EET a nemožnosti zaevidování účtenky systémem EET (off-line režim) bude nezbytné zavést i Off-line kód povinného subjektu (OKP). OKP je pomocným ochranným prvkem, který umožňuje kontrolu integrity a prokazuje odpovědnost povinného subjektu za vystavení tištěné účtenky. OKP je vždy předáván v elektronické komunikaci a na účtenku je tištěn pouze v případě, kdy je vydávána v off-line režimu.

Nemožnost evidování tržeb Zákon pamatuje i na tyto situace. Blíže však neurčuje podrobnosti. (budou určené prováděcí vyhláškou). Viz také Návrh obsahu

Mezní doba odezvy Důležitý údaj pro specifikaci parametrů systému. Technický návrh musí zohledňovat stanovené doby.

Zjednodušený režim Nutno je zohlednit při specifikaci parametrů systému (kontrola splnění povinnosti do 5 dnů zaslat údaje v zjednodušeném režimu).

Ověření účtenky Nutno je zohlednit při specifikaci parametrů systému. Účinnost Účinnost je stanovena na 1. ledna 2016. Pro § 6 - § 10 je účinnost

stanovena na 1. listopad 2015. Což znamená, pilotní provoz evidence žádostí a vydávání autentizačních údajů musí začít 1.10. 2015.

Dle vyjádření Ministerstva financí je záměrem postupný náběh povinností u poplatníků, (celkem odhadováno až 600 000 povinných subjektů) s čtvrtletními intervaly, a to následovně:

Leden 2016 – restaurace, stravování, ubytování (cca 10 % z celkového počtu povinných subjektů)

Duben 2016 – maloobchod, velkoobchod (cca 40 % z celkového počtu povinných subjektů)

Červenec 2016 – Postupně by byly zapojeny další skupiny podnikatelů na základě analýz míry rizika zkreslování tržeb v jednotlivých segmentech trhu a významnosti odhadovaného objemu krácení daní, tak, aby všechny povinné subjekty podléhaly evidenci tržeb nejpozději do tří let od účinnosti zákona (zbylých cca 50 % z celkového počtu povinných subjektů)

S ohledem na stanovené povinnosti, je nutno v projektu počítat s postupným spouštěním funkcí systému i v pilotním / ověřovacím provozu minimálně 60 dní před řádným provozem. To znamená:

k 1.7.2015 – zahájit pilotní provoz systému EET a CA EET pro vývojáře software pro povinné subjekty

k 1.10.2015 – zahájit pilotní provoz evidence žádostí a vydávání autentizačních údajů

k 1.11.2015 - zahájit pilotní provoz evidence tržeb, ověřování účtenky, evidence dat v zjednodušeném režimu



Strana 22 z 186

Důvodová zpráva

Důvodová zpráva (dále i jako DZ) podrobněji vysvětluje smysl a principy evidence tržeb.

Poznámka: Důvodová zpráva není sice právně závazná, avšak její obsah je důležitý z hlediska výkladu smyslu zákona a úmyslu zákonodárce, resp. předkladatele zákona.

DZ uvádí některé základní principy EET (pilíře) na kterých má stát:

1. Elektronizace a on-line přístup správce daně k údajům, 2. Umožnění dobrovolného zapojení veřejnosti do kontroly dodržování zákona, 3. Otevřené řešení (SW i HW).

Samostatně uvádí bezpečnost EET, tu však vzhledem k charakteru projektu není zapotřebí zdůrazňovat, vysokou úroveň bezpečnosti proto budeme považovat za samozřejmost.

Vyhláška

Ve vyhlášce bude dle současného návrhu zákona o evidenci tržeb upraveno:

► výjimky z evidováni tržeb (para.5)

► tržby evidované ve zjednodušeném režimu (para.5)

► způsob tvorby BKP (para. 12)

► zasílané údaje k účtence (para.12)

► údaje uváděné na účtence (para. 13)

► obsah a forma informačního oznámení (para. 20)

► přechodný režim - tzv. fázování (para.43)



Strana 23 z 186

Základní procesy evidence tržeb Základní procesy evidence tržeb jsou rozděleny do následujících 8 procesních oblastí:

1. Registrace a evidence údajů a certifikátů o povinném subjektu, změny v údajích 2. Evidence tržeb 3. Přístup poplatníka k vlastním údajům, a to v agregované podobě za definované období a na

žádost v plném rozsahu zaevidovaných údajů za určené období 4. Kontrola účtenky zákazníkem 5. Nahlášení neobdržené účtenky zákazníkem 6. Kontrola ze strany FS a CS 7. Analýza a vyhodnocování dat, včetně možnosti poskytování dat pro statistické účely 8. Loterie

Obsahem tohoto dokumentu je detailní popis procesní oblasti 1, 2, 4, 5 a 6. Oblast 3, 7 a 8 budou zpracovány v následující analytické fázi, budou však součástí zadání projektu, tak, aby bylo možné jejich spuštění k datu spuštění systému.

Obrázek 3: Základní procesy evidence tržeb



Strana 24 z 186

Registrace a evidence údajů a certifikátů o povinném subjektu

Požadavky na IS EET

ID IS/Portál Požadavek Popis EP-1 RS-IS Umožnit registraci poplatníka IS EET musí při splnění podmínek umožnit

založit poplatníka v systému EET EP-2 IS Ověřit technickou korektnost

podané žádosti IS EET musí dokázat ověřit formát a strukturu žádosti a vyhodnotit, zda žádost splňuje požadavky

EP-3 P, IS Umožnit registrovat provozovnu a spravovat její údaje

IS EET musí při splnění podmínek umožnit vznik jedné i více provozoven poplatníka a správu údajů o provozovně v souladu s právy přihlášeného uživatele

Požadavky na portál EET

EP-4 P Vytvořit poplatníkovi účet na webovém portálu EET

Účet je zakládán s odpovídající rolí dle požadavku poplatníka. Pozn.: poplatník může mít více uživatelských účtů, např. pro různé uživatele, které pověří (zejm. u právnických osob).

EP-5 P Generovat autentizační údaje pro přístup k portálu

IS EET musí vytvořit autentizační údaje pro oprávněný přístup poplatníka k jeho údajům prostřednictvím portálu EET. (pozn. Portál slouží jako rozhraní pro přístup poplatníka k jeho údajům v EET).

EP-6 P Zobrazit údaje poplatníka na portálu

IS EET musí zobrazit vybrané údaje o poplatníkovi (pozn. většinu z ADIS na základě jeho DIČ, ostatní jsou vlastní údaje EET k poplatníkovi)

EP-7 P Umožnit vytvořit žádost o autentizační údaje

Umožnit komukoli vytvořit žádost o autentizační údaje v požadovaném formátu a struktuře.

EP-8 P Umožnit odeslat žádost o autentizační údaje za datovou schránku

Umožnit přímé odeslání žádosti datovou schránkou pouze po korektním přihlášení údaji datové schránky

EP-9 P Autentizovat uživatele pro přístup do datové schránky

Pro přímé odeslání žádosti

EP-10 P Paralelní přístup k jednomu účtu poplatníka

Umožnit přístup prostřednictvím portálu více uživatelům k účtu jednoho poplatníka v IS EET a to i paralelně

EP-11 P Systém musí rozlišovat práva a role uživatelů portálu.

Systém musí rozlišovat práva přihlášených uživatelů na základě jejich role.

EP-12 P Umožnit připomenutí hesla Při zapomenutém hesle musí portál umožnit průběh procesu připomenutí hesla.

EP-13 P Umožnit správu autentizačních údajů pro portál

Při splnění podmínek umožnit správu uživatelských údajů (obsluhou). Změny i zneplatnění.

EP-14 P Zpřístupnit historii změn oprávněnému uživateli

Umožnit zjistit, jak byl který údaj nastaven ve zvolené době, kdo a kdy jej změnil.



Strana 25 z 186

Systémové a bezpečnostní požadavky

Předpokladem je, že systémové a bezpečnostní požadavky budou definovány globálně, mimo tyto parciální procesy. Zde jsou jen vybrané požadavky, přímo vyplývající z potřeb procesu.

EP-15 IS, P Evidovat historii vzniku a změn údajů

Při změně údaje musí být zaznamenána původní hodnota, nová hodnota, kdo a kdy údaj změnil.

EP-16 P Logovat přihlášení na portál úspěšná i neúspěšná přihlášení EP-17 P Správa rolí a práv Portál musí umožňovat správu

definovaných rolí a práv v rámci portálu. Dosud identifikováno: role administrátor, role editor provozoven a role pouze pro čtení.

Případy užití poplatníka

Vytváří si žádost

Poplatník

Podává na Czech POINT

Podává žádost

Podává datovou schránkou

Spravuje své provozovny

Spravuje své údaje

Přihlásí se na portál

Zakládá provozovnu

Mění údaje provozovny

Ukončuje provozovnu

«extends»

«extends»

«extends»

«include»

«include»

Spravuje přihlaš. údaje

«include»

Oprávněná osoba

Obrázek 4: Případy užití poplatníka



Strana 26 z 186

Případy užití Czech POINTu

Czech POINT

Přijímá žádost

Vydává autent. údaje

Ověřuje správnost

Odesílá žádost do EET

Ověřuje totožnost podávajícího

Ověřuje oprávnění jednat za poplatníka

Ověřuje souvislost mezi DIČ a poplatníkem

«extends»

«extends»

«extends»

Obrázek 5: Případy užití Czech POINTu

„Registrace“ poplatníka

„Registrace“ poplatníka je proces, kterým poplatník vstupuje do elektronické evidence tržeb.

Smyslem registrace je, aby se poplatník zaregistroval do elektronické evidence tržeb. Při kladně vyřízené žádosti o autentizační údaje je poplatník zaregistrován v systému EET a zároveň jsou mu přiděleny autentizační údaje pro vstup na portál a minimálně jeden certifikát.

Aktéři

Aktér v kontextu „registrace“ poplatníka

Popis

Poplatník Daňový poplatník, přijímající tržby dle § 4 zákona o EET. V jeho roli může vystupovat i oprávněná osoba.

Oprávněná osoba Osoba oprávněně jednající za poplatníka Czech POINT Kontaktní místo veřejné správy, oprávněné k úkonům pro EET

(předpokládá se přepážka na České poště) IS EET Informační systém EET, který přijímá a eviduje registrovaného poplatníka,

jeho atributy a historii akcí. Portál EET Webový portál, mj. umožňující správu údajů v IS EET

Předpoklady

Seznam předpokladů, na jejichž základě byl proces navržen a popsán. Zdrojem předpokladů je platná legislativa, připravovaný zákon o EET, dále vstupy odborného a technického teamu, týkající se omezení a reálných možností za daných časových a technických podmínek.

Název Popis předpokladu Poplatník v procesu má vždy DIČ

Před vydáním DIČ se poplatníka zákon netýká, pracujeme tedy s předpokladem, že poplatník v procesu má vždy DIČ



Strana 27 z 186

Poplatník a IČO Má-li poplatník přiděleno IČO, pak IČO uvádí v žádosti a systém jej zobrazuje jako jeden z údajů poplatníka

Terminologie žádosti Dle terminologie zákona se jedná o Žádost o autentizační údaje, ačkoli věcně znamená mnohem více požadavků (zejm. se jedná o registraci –založení - poplatníka v IS EET)

Obsah žádosti Dle zákona musí být součástí žádosti vše, co potřebujeme k celému procesu evidence tržeb, jinak následně nemůžeme požadovat evidenci, ani hlášení změn potřebných údajů (tzn. i údaje o provozovnách)

Kontrola DIČ Předpokládáme spolupráci s ADIS (rozhraní), pomocí kterého by se daly údaje o poplatníkovi porovnat s údaji v žádosti (vazba na DIČ)

Datum přidělení DIČ Je nutné vědět, kdy bylo přiděleno subjektu DIČ, jelikož zákon stanoví, že je nutné evidovat až tržby vzniklé 10 dní po přidělení DIČ. Datum přidělení DIČ poskytuje ADIS, nikoli poplatník.

Náležitosti podání Žádost musí splňovat náležitosti pro podání dle § 70 daňového řádu (zák. č. 280/2009 Sb.), tj.: kdo podání činí, čeho se podání týká, co se navrhuje a podpis

Autentizace podání Podání musí být autentizováno způsobem dle § 71 daňového řádu. Spisová služba Dokument/y podání bude nutné evidovat ve spisové službě Neposkytování informací

Pokud v procesu žádosti zjišťujeme jakékoli údaje o poplatníkovi, které nám v rámci žádosti neposkytl sám, neposkytujeme je žadateli

Vadné podání Vadné podání je takové, které nesplňuje náležitosti § 70, resp. § 71 daňového řádu

Žádost

Vznik žádosti Předpokládá se, že žádost si poplatník může vytvořit na veřejné části portálu EET (pomocí formuláře) a výstupem bude datová věta v potřebné struktuře. Dle zákona je možné žádost podat pouze datovou zprávou v určeném formátu a struktuře.

Obsah žádosti Žádost o autentizační údaje poplatníka musí obsahovat tyto vstupní údaje:

1. DIČ poplatníka, pro kterého se žádá 2. Čeho se podání týká* – žádost o autentizační údaje 3. Co navrhuje* - žádá o registraci v EET a autentizační údaje na portál 4. Údaje podatele (Kdo podání činí*):

o identifikace podatele FO: jméno, příjmení, datum narození, adresa, PO: název a IČO, má-li jej přiděleno

o Podpis podatele* 5. Údaje poplatníka:

o Zda je fyzická nebo právnická osoba a dále a) když je poplatník totožný s podatelem, tak ještě IČO, má-li jej přiděleno b) když není zároveň podávající, tak potřebujeme všechny údaje jako u podatele

6. Povinné údaje minimálně jedné provozovny (viz dále podrobněji v bodě 4. až 6.) Pozn.: Ze zákona vyplývá, že součástí žádosti musí být i údaje o provozovnách, abychom následně mohli požadovat jejich správu. Další důvod, proč požadujeme zadat alespoň jednu provozovnu přímo při registraci je, že poplatník bez aktivní provozovny není v principu funkční. Poplatník je totiž povinen identifikovat tržby na konkrétní provozovnu (ID provozovny je součástí datové věty účtenky).

* Povinné náležitosti pro podání dle § 70 daňového řádu (zák. č. 280/2009).

Určený formát je XML. Struktura datové věty bude definována po schválení potřebných údajů.



Strana 28 z 186

Podání žádosti Poplatník žádost podá a tím žádá o zavedení do systému EET a zároveň o přihlašovací údaje na portál.

Žádost může podávat:

a) fyzická osoba - podnikatel (pro sebe) b) oprávněný zástupce právnické osoby (např. statutární orgán, …) c) zástupce (zmocněnec) fyzické osoby na základě plné moci d) zástupce (zmocněnec) právnické osoby na základě plné moci

Pozn. Zástupcem může být fyzická i právnická osoba.

Podání žádosti na Czech POINT Czech POINT ověřuje:

1) totožnost podatele, 2) oprávněnost podatele jednat za uvedeného poplatníka a 3) příslušnost DIČ k poplatníkovi, uvedenému v žádosti (ověření ale provádí IS EET)

Proces ověření je popsán samostatně. Výstupem ověření pro potřeby procesu registrace je závěr, zda všechny ověřované skutečnosti odpovídají požadavkům pro podání a zpracování korektní žádosti nebo nikoli.

Pokud je závěr, že odpovídají, Czech POINT zasílá žádost systému EET. Systém EET ověří, zda již tento poplatník (toto DIČ) nebylo zaregistrováno. Pokud nebylo, systém EET poplatníka zaregistruje a vytvoří mu autentizační údaje na portál. Poplatník obdrží autentizační údaje.

Autentizační údaje musí být dle zákona přiděleny obratem.

Podání datovou schránkou Rozdíly proti podání na Czech POINT

Reakční doba je ze zákona delší (24 hod). Zpracování a odpověď musí tedy proběhnout do 24h od podání

Odpadá ověření totožnosti podatele, jelikož totožnost je daná již datovou schránkou

Ověření souvislosti mezi podatelem a poplatníkem, pro jehož DIČ se žádá, bude probíhat stejně jako u podání na Czech POINTU

Porovnání údajů u žádosti podané datovou schránkou vyhodnocuje na shodu systém EET proti údajům poskytnutým ADIS. Při dokonalé shodě potvrdí oprávněnost žádosti.

Při nesrovnalostech odkáže žadatele na Finanční úřad k manuálnímu zpracování žádosti.

Podání zástupcem (na základě plné moci) – není dořešeno a bude patrně muset spadat do ručního zpracování.

Tam, kde jsou potřeba dva podpisy – není problém, je vyřešeno novelou.

Údaje zástupce k ověření:

FO: jméno, příjmení, rodné příjmení, datum narození

PO: název, IČO, sídlo

Při ověření zástupce musí být Plná moc k dispozici (dostupná v ADIS).

Riziko při ověření zástupce: ověření není jednoznačné, ale je to současná praxe. Námět: ISDS má i pole „Místo narození“, které by se dalo využít.

Alternativní cesta Vyplněný formulář žádosti na webu systém může odesílat přímo za svou datovou schránku po úspěšném zadání autentizačních údajů ke své datové schránce. Jednalo by se o obdobný proces jako



Strana 29 z 186

v aplikaci elektronická podání na Daňovém portálu (EPO). Tato cesta ale nyní není zákonem o EET umožňována.

Výsledky a výstupy žádosti Podání žádosti může skončit jedním z následujících způsobů:

A) Žádost bude ověřena s kladným výsledkem Výstupy:

o Autentizační údaje pro přístup na portál

o Potvrzení pro poplatníka, že žádost podal (na vyžádání)

o Potvrzení pro finanční správu, že poplatník vše převzal (aby bylo doloženo, že mu byly autentizační údaje přiděleny v zákonné lhůtě)

Předpokládáme, že elektronicky podaná žádost musí vygenerovat papírovou formu podání k podpisu.

B) Žádost bude ověřena se záporným výsledkem

Výstup: zamítnutí žádosti a přesměrování podatele na finanční úřad k dořešení situace

C) Ověřeno, účet založen, ale certifikáty nebyly vydány bez zavinění poplatníka (např. tech. potíže, dostupnost rozhraní) Výstup: Autentizační údaje na portál a odkázání podatele na portál pro dořešení certifikátů

D) Žádost nebyla podána bez zavinění poplatníka Výstup: Potvrzení pro poplatníka, že chtěl podat

Autorizovaná konverze z moci úřední Plné moci; potvrzení, že převzal. Dále budou uloženy do systému k žádosti.

Potvrzení, že žádost podal, bude uloženo v EET, jelikož jej systém sám vytváří.

Vadné podání žádosti

V případě vadného podání žádosti o autentizační údaje. Důvodová zpráva k zákonu o evidenci tržeb na straně 34, v části k § 7 uvádí „V případě vadného podání se předpokládá automatická odpověď systému, která bude právně výzvou k odstranění vad. Výzva k odstranění vad dle ustanovení § 74 daňového řádu pak jednak přerušuje běh lhůty správce daně a zadruhé zajištuje, aby tato lhůta neskončila dříve než 5 dní ode dne, kdy došlo k požadované součinnosti, tj. odstranění vad. Prakticky tedy dojde k prodloužení lhůty.“ Prakticky to znamená, že pokud systém umožní poplatníkovi učinit jakkoliv vadné podání, bude nutné, aby systém na základě vadného podání pro obě varianty (tj. podání datovou schránkou i prostřednictvím kontaktního místa):

1. vygeneroval automatickou odpověď, která bude nést všechny náležitosti výzvy k odstranění vad podání, včetně řádného odůvodnění (§ 74, § 101 a § 102 daňového řádu)

2. zajistil zaznamenání data doručení této výzvy 3. zaznamenal návaznost k podání, kterým se vady podání odstraní a poznal, zda vady byly či

nebyly odstraněny 4. pořídil/umožnil pořízení úředního záznamu za situace dle ust. § 74 odst. 3 daňového řádu 5. všechny písemnosti (podání, výzva, odpověď na výzvu=opravné podání, úřední záznam

o neúčinnosti podání) umožnil evidovat ve spisové službě.

Alternativní scénáře

Chybné DIČ

ADIS rozhraní nezodpoví na ověřovací dotaz

Neaktuální údaje v ADIS

Podatel žádosti není oprávněná osoba



Strana 30 z 186

Poplatník žádá na Czech Point o vydání autentizačních údajů ve stejný den, kdy mu bylo přiděleno DIČ, tj. ten samý den, kdy na FÚ vyzvedl osobně rozhodnutí o přidělení DIČ (nutno dořešit, zda budou údaje z ADIS přeneseny on-line v rámci jednoho dne)

Duplicitní žádost – poplatník s tímto DIČ je již v EET registrován

Nalezená rizika

Rozhraní ADIS – zda bude vytvořeno včas

Kapacitní nároky na Czech POINT kolem počátku platnosti zákona (ev. v každé vlně)



Strana 31 z 186

Proces registrace poplatníka a jeho provozoven do EET

Czech PO

INT

Žadatel

Portá

l EET

IS EET

26.2. 2015 Gabriela ČížkováVerze 4

Žádá o autentizační

údaje

Vyplní žádost o autentizační údaje (včetně alespoň

jedné provozovny)

Formulář

Uloží žádost na flash disk

Odešle žádost svou datovou schránkou

Vytvoří datovou zprávu (žádost)

Žádost (XML soubor)

Použije datovou schránku?

ANO

NE

Ověří žádost

Odešle poplatníkovi

autentizační údaje k portálu

Zaregistruje poplatníka v

IS EET(založí jej)

Poplatník je zaregistrován k

EET

Založí k poplatníkovi provozovnu/y

uvedené v žádosti

Založí mu účet na portálu a vygeneruje

autentizační údaje k portálu

NE, ale zadá přístupové údaje ke schránce

Podá žádost na Czech POINT

Výsledek ověření

Kladný

Přesměruje žadatele na FÚ k

dořešení

Záporný

Poplatník není zaregistrován k

EET

Zašle žádost do IS EET

Výsledek ověření podatele

Kladný

ZápornýŽádost není podána

Odešle žádost

Ověří totožnost a oprávněnost podatele

Obrázek 6: Proces registrace poplatníka a jeho provozoven do EET



Strana 32 z 186

Ověření poplatníka

Proces ověření poplatníka probíhá v několika krocích.

1. Na portálu žadatel vyplní informace o poplatníkovi a jeho provozovnách. a. Informace o poplatníkovi jsou automaticky získány z IS ADIS

2. V případě, že poplatník zvolí variantu pomocí datové schránky a. Žadatel zadá přihlašovací informace k datové schránce. b. Systém ISDS ověří, zda jsou údaje správné a předá informace o poplatníkovi (IČ,

název poplatníka a jeho adresa). c. Systém ADIS dohledá k IČ a Názvu poplatníka (včetně jeho adresy) z ISDS DIČ. d. V případě, že existuje jenom jedno DIČ, ověření proběhlo správně. Když je

nalezených výsledků víc než 1 nebo 0, proces končí a poplatník musí navštívit pobočku CzechPOINT nebo Finanční úřad.

e. Když existuje jednom jedno DIČ, systém EET ověří, zda DIČ ze žádosti zodpovídá DIČ z ADIS a na základě výsledků ověří poplatníka.

3. V případě, že poplatník zvolí variantu pomocí návštěvy CzechPOINT. a. Pracovník pobočky ověří totožnost žadatele. b. V případě, že žadatel je osobou oprávněnou jednat na základě plné moci.

i. V případě, že má žadatel papírovou plnou moc, pracovník ověří správnost plné moci (podepsání oprávněnou osobou za poplatníka) a odešle údaje o poplatníkovi do systému.

ii. V případě, že je plná moc již zavedena v ADISu, systém vyhledá její existenci k poplatníkovi v systému ADIS. Když neexistuje, proces ověření končí.

c. V případě, že žadatel je osobou oprávněnou jednat za poplatníka bez plné moci. i. Pracovník ověří oprávněnost jednat (porovná totožnost žadatele s výpisem

z OR, ŽR apod.). d. Systém EET porovná DIČ ze žádosti s DIČ, pro který je osoba oprávněna jednat a

provede ověření. 4. Systém odpovídá, zda je žadatel ověřený.



Strana 33 z 186

Ověření pop

latníka

Poplatník

IS EET

Pracovník České pošty

IS ADIS

ISDS

Vygeneruje XML soubor s žádostí

Hledá poplatníka na základě údajů z Datové schránky

Nalezen 1 poplatník?

Ano

Ano

Ne

Ne

Porovnává DIČ žádosti a žádatele

Ověřuje identitu datové schránky a

žádosti

Je DIČ zádosti a nalezený DIČ shodný?

Poplatník ověřen

Vyplní žádost o přihlášení k Elektronické Evidenci Tržeb

Přihlášení pomocí autentizačních údajů Datové schránky

AnoPřihlašuje se údaji Datové schránky

Ne

Ukládá XML žádost na přenosný USB

Disk a jde na Českou poštu

Informuje poplatníka o nemožnosti přihlášení

Je DIČ zádosti a nalezený DIČ shodný?

Ano

Ne

Hledá plnou moc žadatele a poplatníka

Ne

Ano

Ověřuje identitu žadatele

Na základě plné moci?

Ověřuje oprávnění žadatele

Papírová plná moc?

Ano Ověřuje správnost plné moci

NeZadává informace o

žadateli a poplatníkovi

Informuje žadatele o nemožnsti přihlášení

Hledá údaje o DIČ

Ověření autentizace

Zadává informace o

žadateli a DIČ ověřovaného

poplatníka

Obsahuje IČ, Název poplatníka, Adresu

Jméno a příjmění žadatele

Adresa žadatele Název poplatníka DIČ poplatníka

Název poplatníka Adresa

Pověřená nebo oprávněná osoba

Informuje ANO/NE

Zda je statutár, jednatel, oprávnení jednat za DIČ

Informuje ANO/NE

Obrázek 7: Proces ověření poplatníka

Chybo

V příp

Czech

Žádos

e)f)bg)h)

Na Cz

1. 2.

3.

Ověře

Ověřemusí bv násl

Vybra

Ověře

Totožnžadatepoplatstyku na pouvedepracov

Ověře

Rozhrjeden

ADIS existujCzech

Poplat Fyzickosoba

Právnosoba

ové stavy

adě, že pro

h POINT

st může po

)a) fyzická ob) oprávněn)c) zástupce)d) zástupce

zech POINT

Ověření tOvěření, KontrolujOvěření s

ení dle bod

ení totožnosbýt velmi doedných kro

né údaje m

ení na Czec

nost žadateelem a poptníka v žádos údaji o tozadí porovn

enými k DIČvníkům Čes

ení prostřed

raní s ADISDIČ. Systé

musí rovněje plná moc

hPOINT a tr

tník

ká a

Žt

ická a

Žt

oces selže v

odávat

soba - podnný zástupcee (zmocněnee (zmocněne

T probíhá:

totožnosti žže je žadate se proti osouvislosti ž

u 3

sti žadatele obře ošetřecích certifik

uset vykazo

chPOINT

ele se prokplatníkem, posti vůči údaotožnosti žaná a vyhodČ v ADIS aské pošty úd

dnictvím D

S poskytne m EET ově

ěž poskytovc. Rozhraní rvale ověřen

dokumŽádost + totožnosti

Žádost + totožnosti

v jakémkoli

nikatel (pro e právnické ec) fyzické ec) právnick

žadatele (obtel oprávně

obchodnímužadatele s D

a zjištění jeeno, jelikož káty poplatn

ovat 100%

kazuje občapro kterého ajům uvedeadatele, přípdnotí shodua pouze oddaje, které

Datové schr

odpověď, zěří shodnost

vat rozhran(nebo údaj

ní DIČ.

Tabulka

Žádající osenty

průkaz

průkaz

bodě, je ža

sebe) osoby (naposoby na zké osoby na

bčanský průn jednat za

u rejstříku. DIČ poplatn

eho oprávnna základě

níka.

shodu, aby

anským průžádost pod

eným v obchpadně s úd

u nebo nesdpoví, zda není nutné

ránky

zda informat DIČ z ADI

í na zjištěnje) ADIS o p

1 - Kontrola

soba předk

DIČ, jmédatum naro

DIČ, název

Spec

adatel požád

př. statutárnákladě plnéa základě p

ůkaz) – ve v poplatníka

níka, ke kte

ěnosti jedně této žádos

y výsledkem

kazem (ve dává, se zjhodním rejs

daji z obchohodu mezi jsou totožposkytnout

ace z DatovS s DIČ ze

í, zda k poplných moc

a údajů na C

kládá údaje no a adození

v, adresa, IČ

Minis

cifikace proje

dán o návšt

ní orgán, …é moci plné moci

všech čtyřec – v případě

rému se žá

nat za (DIČ)sti vydávám

m bylo ověře

variantě Cjistí porovnástříku. Pracodního rejst

údaji uvedné nebo nt.

vé schránkžádosti.

žadovanémcech musí b

CzechPOINT

Kon

dresa, OŘ(jmnar

ČO OŘ(ná

sterstvo finan

ktu Elektroni

těvu Finanč

)

ch případecě b), c) a d)

ádost podáv

) poplatníkame žadateli p

ení.

CzechPOINTáním údajůovník Czecříku. Údaje

denými k DIne. Důvode

ky jsou nav

mu DIČ a idbýt dostupné

ntrola proti

Ř údaje k DIéno, adrození) Ř údaje k DIázev, adresa

ncí České rep

ická evidence

Stran

čního úřadu

ch (běžná a) (běžná ag

vá:

a, pro kteréhpřístup do p

T). Souvisloů k uvedenéch POINTu e na žádostČ v žádost

em je nepo

vázány na k

dentifikované dle otevír

Č dresa, d

Č a, IČO)

publiky

e tržeb

a 34 z 186

u.

agenda). enda)

ho žádá, portálu a

ost mezi ému DIČ přijde do ti systém ti a údaji oskytovat

konkrétní

né osobě rací doby

datum

Změn

Předp

Údaje

1234567

8911

*Psp

Po

Ukon

Předp

ny údajů

poklady

Většina úADIS) Údaje, poÚdaje k pPoplatníkPři změnzměna prdo EET. bude mít V případě(aktivní/n

e poplatník

. DIČ 2. Datum 3. Stav po4. Datum 5. Zda je f6. Místní p7. Plné m

Údaje na

8. Jméno 9. Datum

0. IČO, po1. Adresa

1a) Daň

Plné moci jspeciální plné

ozn.: zde se

nčení evid

poklady

Finanční ukončeníbuď z moV případěJe třeba Je třeba z

poplatník

údajů o pop

ocházející zpoplatníkovk si nemůžeě údajů oznroběhne v sMůže jít nadopad i doě údajů pop

neaktivní) a

a v EET

získání DIČoplatníka: (Aregistrace dfyzická nebpříslušnost oci*

avíc u fyzic

a příjmení narození

okud jej má místa pobyňového řád

sou vždy v é moci pro E

e předpoklá

dence (de

správa můí činnosti spoci úřední, ně ukončení nastavit návzablokovat

ka

platníkovi se

z ADIS, nelzi, vznikající

e samostatnnámí změnusystému, ktpříklad o ex

o EET. platníka vedto na zákla

Úd

Č Aktivní, Neado EET

bo právnickásprávce da

ckých osob

přiděleno ytu (dle § 13u)

ADIS. Pro EET. Varian

ádá zásah d

eaktivace

že v EET dpolečnosti, pnebo na zákevidence pvaznost na jeho přístu

e v EET pou

ze v EET nií v EET, jsoně editovat u finančnímerý je zdrojxistující pro

dených pouzadě žádosti

aje každéh

aktivní)

á osoba aně dle § 13

b

3 odst.

účely EETnta je potvrz

do ADIS – s

e) poplatn

eaktivovat po skončenkladě žádospoplatníka b

zneplatněnpové údaje

Spec

uze zobrazu

ijak spravovu jen Stav ažádné údaj

mu úřadu staem dat (ADces „Globá

ze v EET mpoplatníka,

ho poplatní

3, odst. 1 da

Ú

121314

T potřebujezení plné m

speciální kó

níka

poplatníka vní řízení o psti poplatníkbudou ukonní jeho certif

na portál.

Minis

cifikace proje

uje (viz sezn

vat a Datum rege poplatník

andardním aDIS). Aktuallní změna D

může finanč, nebo z mo

íka

aň. řádu = (

daje navíc

2. Název sp3. IČO, pok4. Adresa s

me generámoci ze stra

d plné moc

v odůvodněozůstalosti ka čeny také vfikátů

sterstvo finan

ktu Elektroni

nam níže; z

gistrace do ka (ani na poa existujícímizace je budDIČ“ poplatn

ní správa zoci úřední

(číslo územ

právnický

polečnosti kud jej má psídla

lní Plné mony ADIS.

ci – jen pro E

ěných přípapři úmrtí fy

všechny jeh

ncí České rep

ická evidence

Stran

zdrojem úda

EET. ortálu, ani jm postupemde předávaníka v ADIS

měnit pouz

. pracoviště

ých osob

přiděleno

oci (kvůli o

EET.

adech (napřyzické osoby

ho provozov

publiky

e tržeb

a 35 z 186

ajů je

inak). m a t z ADIS

S, která

e Stav

ě FÚ)

věření) i

ř. y apod.)

vny.

„Reg

Předp

Údaje

O kaža dále

Typ p

Mezi tprovoz

Lokali(různá

Režim

Běžný

Zákonvyhláš

„PovoJeho vvýsledpovole

istrace“ p

poklady

V zákoněmateriálutržeb a přpovinnosVzniká nopotřebámProvozovzadání - tKaždý poÚdaje pro

e provozovn

dé provozoe tyto údaje:

ID provoz

je číslo psystému

Datum re

rovozovny

Stálá (poz

Mobilní (n

Semimob

Virtuální typy nelze zovnu.

zace provoá pole dle ty

Stálá: AdMobilní: jSemimobVirtuální:

m provozov

běžný

zjednodu

zjednoduš

ý režim je ne

nné důvodyškou.

olovací řízevýstupem jedek řízení zení“. Režim

provozov

ě není konku předjímámředjímáme,

st provozovnový registr p

m evidence tvny by mělytak i dávkov

oplatník musovozovny m

ny

ovně potřeb:

zovny

přidělené sy(z důvodu,

egistrace (vz

zn. předevší

např. taxi, a

bilní (např. st

(např. e‐shopřecházet.

ozovny ypu provozo

dresa (konkjiná identifikbilní: textový URL

ny

šený ze záko

šený na zák

ejpřísnější a

y pro použ

ení pro užite povolení zadá poplatnje také sou

vny

rétně ošetřeme „provozo

že bude deny přijímajícprovozoventržeb

y jít registrovvě (v připravsí mít regist

může zadat

ujeme evid

ystémem, mže toto ID s

zniku) prov

ím kamenné

autobusy)

tánek, cirku

op) Pokud je t

ovny)

rétní pole bkace (např. ý popis loka

ona (+ výbě

ladě povole

a měl by bý

žití zjednod

í zjednodušzjednodušeník k provozučástí datov

ena definiceovnu“ dle doefinice do zcí hotovostnn! Nikde jind

vat jak ručnvené strukttrovánu alea editovat p

ovat DIČ p

minimálně pse uvádí na

ozovny v E

é obchody)

us)

třeba změni

budou dle RSPZ)

alizace (zde

r ze zákonn

ení (+ číslo je

ýt i nejrozšíř

dušeného

šeného reženého režimzovně – zmvé věty účte

Spec

e „provozovostupných inzákona doplní tržby dle de není regi

ně (jednotlivurované po

espoň jednupouze popla

rovozovate

pětimístné, ua účtence a

ET

it typ provo

RUIAN)

e je výjimka

ých důvodů

ednací příslu

řenější, takž

režimu bez

žimu“ je sammu pro provmění režim penky.

Minis

cifikace proje

vny“. Proto vnformací a lněna. Dále§ 4 registroistr provozo

vě) – předpoodobě) u provozovnatník, nikoli

ele provoz

unikátní v rnesmí být p

ozovny, je

a, lze měnit

/podmínek)

ušného povo

že bude zvo

z nutnosti

mostatný pozovnu/y, nprovozovny

sterstvo finan

ktu Elektroni

v dalších čápotřeb elek

e předjímámovat a spravoven, který

okládá se w

nu Finanční s

zovny (napo

ámci poplapříliš dlouhé

nutné ukon

lokalizaci p

)

olení)

olen jako de

podat pov

proces, probnebo zamítn

na „Zjedno

ncí České rep

ická evidence

Stran

ástech tohoktronické evme, že bude vovat by vyhovov

webový form

práva

ojení na po

tníka, nikolé)

nčit a založ

provozovny)

efaultní.

volení budo

bíhající mimnutí žádostiodušený na

publiky

e tržeb

a 36 z 186

oto vidence

val

mulář pro

platníka)

i v rámci

it novou

)

ou dány

mo EET. i. Kladný základě

Stav p

Pozn.

Každápřechá

ČinnoSeznaČinno

ObvykNepov

Provo

Je zde

Otevř

1. 2. 3.

Změn

Předp

Závěry

provozovnyaktivní přerušenzrušená

Každý stav

á nově zaloázet oběma

ost provozoam vybranýstí může m

klá otevíracvinný údaj, z

oz

sezónní

celoročníe požadave

ené otázky

Jaká defiJaký je koNa jakou

ny údajů

poklady

Změna mu

y

Poplatník mto jedině poVětší množMěnit nelze

ID D T L

Provozovnu mobilníchznamenat Výjimku tvoZa změnu

y

á činnost

v musí mít p

ožená prova směry. Ze

ovny ých činnostít provozov

cí doba zadávaný fo

í k držet hist

y

inice provozonkrétní se dobu se po

provozov

usí být dle z

může měnito úspěšnémžství změn e: D Datum regisTyp provozoLokalizace pa je tak pevh jinou …), ukončit a zaoří semimose nepovaž

počáteční d

vozovna me stavu Zruš

tí z NACE vna zvoleno

ormou texto

torii stavů a

zovny budeeznam činnoovolení vyd

vny

ákona podá

t vybrané údm přihlášenby mělo jít

strace ovny provozovny vně vázanáže každé „paložit novoubilní provozžuje formáln

atum, a pok

má stav Aktšena již nelz

(obory – ci více najed

ové poznám

změn údaj

e použita proostí provozoává? (určito

ána elektron

daje o svýcí provést i dá

(kromě semá (definovánpřestěhováu provozovnzovna, jejíž ní změna ja

Spec

kud se neje

tivní. Mezi ze stav znov

cca do 20dnou.

mky.

ů provozov

o výklad tohovny (výběrou, neurčito

nickou cest

ch provozov

ávkově

mimobilní)na) na svouní“ nebo zmnu lokalizace s

ako přejmen

Minis

cifikace proje

edná o aktuá

stavy Aktvu změnit n

). Konkrétn

vny.

hoto zákonar ze seznamou, po dobu

tou

vnách výhra

lokalizaci (měna SPZ, č

se může měnování či pře

sterstvo finan

ktu Elektroni

ální stav, ta

ivní a Přena žádný jin

ní položky

a? mu NACE)?

trvání důvo

adně prostře

(u stálých pči URL adre

ěnit ečíslování u

ncí České rep

ická evidence

Stran

ak i koncové

rušená činný.

budou def

odů)

ednictvím po

provozoven esy e-shopu

ulice.

publiky

e tržeb

a 37 z 186

é datum.

nost lze

finovány.

ortálu a

adresou, u bude

Zruše

Předp

Zrušen

Závěry

Pov z

ení provo

poklady

ní provozov

y

Zrušení i Stav je třUkončentím i zrušDůvod zr

ozn. Uživatzásadě jedn

ozovny

vny je věcně

Přerušení řeba změnití může zad

šení všech jrušení bude

telsky vhodná o ukonče

ě vázáno na

činnosti prot pro konkréat i finančneho provoz

e povinně uv

né nechat ení evidenc

a zákonné d

ovozovny zaétní provozoí správa, al

zoven. Samváděn při z

jej i uzavříce poplatník

Spec

důvody, kte

adává poplaovnu. e pouze v potné provoz

změně stavu

ít všechny ka pro účely

Minis

cifikace proje

eré budou d

atník na por

případě, kdyzovny ne. u na „Zruše

provozovnyy EET.

sterstvo finan

ktu Elektroni

efinovány.

rtálu – viz z

y jde o dea

ená“ výběre

y „jedním k

ncí České rep

ická evidence

Stran

změny výše

ktivaci popl

m jedné z m

krokem“, ale

publiky

e tržeb

a 38 z 186

.

atníka a

možností.

e pak se

Evide

Klíčovinform

Tržby je vždProvozKaždédatové

Aktéř

Aktér vIS EET

KoncoPoklad

Poklad

Pravid

Seznaznění systém

ID ET-P-1

ET-P-2

ET-P-3

ET-P-4

ET-P-5

ence tržeb

vá procesnímačním syst

jsou zadávdy součástí zovny jsou

é koncové zé věty směř

i

v kontextu eT

ové zařdna)

dník

dla

am pravidelzákona, sta

mu.

Název pPoplatnv IS EE

Koncovzjednodmusí zajejího přVýměnazákladě

Poplatnrelevantýkají ko

Bude-li v datovéodmítnu

b

í oblast, kttémem EET

vány do jedjedné prov

následně zařízení je řující k IS E

evidence trž

řízení (

l, která se atistické úd

pravidla ník je povinT v okamži

vé zařízení,dušený režaevidovat přijetí směrea informacě datové vět

ník je povtní údaje vonkrétní pla

chybět jedé větě, buta.

terá má naT (IS EET).

dnotlivých kvozovny, přvztaženy kvybaveno cET.

žeb PopPřijíuklá

(také InfozasíVytvzasíKon„poktak nZad

vztahují nadaje finančn

nen zaevidoku jejího vz

, které je žim evide

platbu do 12m k IS EETí o platbě ty.

vinen vypln datové vět

atební trans

den z povinbude tako

a starosti k

oncových zřičemž provk jednomu pcertifikátem

pis ímá datové ádá je a genrmační sysílá datové vváří datové ílá směrem

ncové zařízkladnu“ a cnemusí být ává vystave

a evidenci tní správy, te

ovat platbuzniku.

určeno pronce tržeb20 hodin odT.

vzniká na

nit veškerétě, které se

sakce.

nných údajůová zpráva

Spec

omunikaci

zařízení (typvozovna mpoplatníkov

m (i sdíleným

věty z koncneruje odpostém nebo věty a přijím

věty obsahm k IS EETzení může centrální kopřístupná z

ení účtenky

tržeb (účtenechnická a

Popis u IS EET

(mezní dpo kterodoba neze strav případumožnějejího vzpovinnos

o ,

d

Pro korežimu zaevidov120 hod

a Datová informacsémanti

é e

Existuje Avšak provededatové v

ů a

Povinnýv datové

Minis

cifikace proje

mezi konc

picky poklaůže obsaho

vi. Poplatníkm přes více

cových zaříověď včetněelektronické

má FIK. hující informT, přijímá o

být internomunikační z Internetu.y.

nek). Zdrojejiná omeze

potvrzuje doba odezvou musí pení omezenany informdě technickýno zaevidozniku. Poplst předat záncová zař

neplatí vání platby

din. věta je

ce v požce.

min. sana základ

ena, poplatvěty. ými údaji jeé větě.

sterstvo finan

ktu Elektroni

covým zaříz

dna). Každovat více kk je rozlišee zařízení),

ízení, prováě FIK. é zařízení

mace o tržbodpověď a ě rozdělenmodul. Sa

em těchto ení z hledis

přijetí plavy). Jedná oplatník vya, může vš

mačního sých problémovat platbu atník má i ákazníkovi úřízení ve

pravidloy. Je dána

XML soužadované

da povinndě toho, ník vyplňuj

e řádek 3,

ncí České rep

ická evidence

Stran

zením popl

dé koncové koncových zen na zákla kterým po

ádí jejich va

poplatníka,

bě, podepisutiskne účt

no na samamotná pok

pravidel jeska návrhu

atby do 2 se o min.

yčkat. Maxšak být ukonsystému. Pmů je poplat

do 48 hodv takém př

účtenku. zjednoduš

o okamžmaximální

ubor obsastruktuře

ných paramjaká platb

je patřičné

4, 5, 6, 7

publiky

e tržeb

a 39 z 186

atníka a

zařízení zařízení.

adě DIČ. odepisuje

alidaci,

které

uje je, tenku.

motnou kladna

aktuální finálního

vteřin dobu, imální nčena Pouze tníkovi din od řípadě

šeném žitého doba

ahující e a

metrů. ba je části

7 a 9

ET-P-6

ET-P-7 ET-P-8 ET-P-9

ET-P-10

ET-P-12

ET-P-13

Požad

SeznaPožadcharak

ID ET-FP-1

Datová certifikácertifika

KomunizabezpePoplatnúčtenkuSoučásnásledu

Rušení

Každá identifik

Číselnék 1. 1.

davky

am funkčnídavky vychkteristik celé

PožadaInformaschope

věta mátem poplaační autorito

ikace s IS ečeného ko

ník je povinu. stí vystaveující bezpeč

zaevidovan

zpráva mkovatelná.

é řady účte

ích a nefuházejí z uvého systém

avek ační systémn zaevidova

usí být tníka, který

ou EET.

EET probíomunikačníhen předat z

ené účtenčností údaje

ných tržeb

musí být je

nek se res

nkčních povedených p

mu. Součást

m EET muat tržbu.

podepsánaý je vydán

íhá pomocho kanálu. zákazníkov

nky budoue.

ednoznačně

startují vždy

ožadavků kpravidel a tí jsou také

Pousí být Tr

zazjeokv kho Za

Spec

a n

Každémcertifikátdatovýchbude DCertifikámožné hvíce cerprovozukoncový

í Komunikslužeb n

vi Účtenku

u FIK –zaevidovnavráceúčtenky.zaevidovchvíli zaúčtenky.BKP –vypočítánad poúdaji v dElektronk dispozprivátnímPoplatnítržbách se zápvystavujevidovánbyla vyzařízení

ě Jak přkoncovýobsahov

y Vždy kúčtenek

kladených dále je

požadavky

opis ržbou je mařízení či pednodušenýkamžitě. komunikaciodin od vydá

aevidovaná

Minis

cifikace proje

mu poplatníkt pro eh vět. IdeDIČ, obsa

át bude plaho obnovit.rtifikátů, vy (např. ví

ých zařízeníkace probínad protokou předává ja

v případě, vání platbyn zpět popl. V případěvání tržby, jaevidování . bezpečnos

án dle vzorvinnými a

datové zpránický podpzici FIK, je sm klíčem. ík provádí tím způsob

pornou plaje účtenku.na vazba nystavena ví. říchozí, taým zařízevat jednozn1. 1. dojdčíslem 0.

na IS EErozvíjejí d, které jsou

myšlena plapoplatník, ý režim jeV případě s EET smání účtenky

tržba je ide

sterstvo finan

ktu Elektroni

ku bude vygelektronickéentifikátoremažen přímatný po dob Poplatník

yžaduje-li toíce provozí apod.). íhá na zálem HTTPS

ako evidenc

že dojdey IS EETatníkovi a sě, že není je tento FIKa nestává

stí kód poprce provádě

certifikátevě.

pis – v přsoučástí úč

změny v jižbem, že vysatbou. O . V datovéna původnív rámci jin

k odchozním a ISačný identif

de k zaháje

ET z pohledo konkrétnkladené na

atební tranna kterého povinen z

technickí provést zay.

entifikována

ncí České rep

ická evidence

Stran

generován é podepism pro cemo v certifbu 2 let a může požá

o charakterzních míst,

kladě webS (SSLv3).ci proběhlé t

e k okamžT, tento kóstává se somožné oka

K navrácen se tak so

platníka, kteějící MD5 m podeps

ípadě, že čtenky její p

ž zaevidovstaví tržbu n

této trané větě musí účtenku, iného konco

í zprávy S EET bfikátor UUIDení číselné

du evidencních funkča koncová z

nsakce. Koo se nevztzaevidovat kých probaevidování

a na základě

publiky

e tržeb

a 40 z 186

jeden sování rtifikát fikátu. bude

ádat o r jeho více

bových

tržby.

žitému ód je učástí amžité až ve učástí

erý je funkci anými

není podpis

aných novou nsakci sí být i když ového

mezi budou D. řady

ce tržeb. čností či zařízení.

ncové tahuje tržbu

blémů do 48

ě FIK.

ET-FP-2

ET-NP-1

ET-NP-2

ET-NP-3

ET-NP-4

ET-NP-5

V rámcmusí doinforma

IS EET komuni

IS EET

IS EET až 10.0

IS EETkrátkodtransakIS EETdatové dobu 10

ci každéhoocházet k lo

ací.

musí zajistkace.

musí zajist

musí být sc00.000.000

T musí býtobému cí za vteřin musí být světy v obd

0 let a 3 mě

o kroku progování klíč

tit nepopirat

tit integritu d

chopen zpra0 transakcí z

t schopen vytížení u. schopen evržené podoěsíců.

rocesu čových

Kosp„koce Přobvězá

telnost Mkonabubuje Bum

dat. Ms dzaza MjižFIpřk nuloop

acovat za rok.

Jižinfpoko

odolat 4000

Povte

vidovat obě po

Dazhočob Jeraapv jra Úlkapln

Spec

onkrétní sepecifikovat. oncové zař

ertifikát“, „ch

ředpokládá bjemu dat pěty. Logovaároveň komusí být n

onkrétní sua podepisoude obsahude provedznám pouz

ude-li mít poinimálně séusí být datovou věařízení a abezpečený

ůže se státž nedošlo kK) směremřípadě konnavázání sožena. Zárpakované ož k 1. 1. 2frastrukturuostupně narolem 10% vočítá se s eřin.

atová větahruba velikčekávaném bjem dat ko

ednotlivé dazítkem. A

plikována jeden den. zítek.

ožiště budapacity rozné kapacity

Minis

cifikace proje

eznam událJedná se

řízení kontahybějící pov

se, že tyto přibližně steací souboryprimovat jejnepopiratelnbjekt. Nepo

ování datovhovat DIČ eno na zákze poplatník

oplatník vícériovým čísl

znemožněětou v rám

IS EETým kanálem

, že tržba jek přijetí pot

m ke konconcové zařspojení s ISroveň se kdeslání dat

2016 je zau. Avšak růstat. V 1. šech subjekchvilkovým

a, včetně kosti 6kB.

vytížení slem 600 TB

atové věty Avšak jedn

na všechZa rok tak

de navrženozšiřitelné. Ky.

sterstvo finan

ktu Elektroni

ostí k logov o logováaktovalo IS vinné údaje“

informace ejně, jako

y bude možjich velikosné, že tropiratelnostvých vět ce

poplatníkakladě privátkovi.

ce certifikátůem certifikáěna jakák

mci komunikT. Komun

m.

e zaevidovátvrzující zpovému zařířízení evidS EET, aleoncové zařt. potřebí mít

počet tfázi se počktů (60 tis.)

vytížením

podpisu, Za obdo

systému, lB.

budou ukláno časovény transabude použ

o tak, abyK 1.1.16 ne

ncí České rep

ická evidence

Stran

vání bude ní událostíEET“, „ne

“ atd.

budou z hleukládané džné archivot. ržbu zaevt bude zaloertifikátem, a. Podepistního klíče,

ů, bude rozátu. koli manipkace konconikace pr

ána v IS EEprávy (obsaízení. V takduje, že e zpráva nřízení poko

t vystavenutransakcí čítá se zapo. v řádu jed

bude odpoobí 10 leze předpo

ádány s časé razítko akce, evidoito 365 čas

y bylo z hleebude zap

publiky

e tržeb

a 41 z 186

nutné í typu platný

ediska datové ovat a

vidoval ožena

který sování který

zlišeno

pulace ového robíhá

ET, ale ahující kovém došlo

nebyla ouší o

u tuto bude

ojením

dnotek

ovídat et, při kládat

sovým bude

ované sových

ediska potřebí

ET-NP-6

ET-FP-3

ET-NP-7

ET-NP-8

ET-FP-4

ET-FP-5

ET-FP-6

ET-FP-7

ET-FP-8

IS EET0,33 vte

IS EETúdaje, transak

IS EETdatové

KoncovKoncovkomunizabezpestandarKoncovmaximáze stran

Koncovgenerov

Koncovpodepisvěty.

KoncovnotifikovexpiraceKoncovvygenerpravide

T musí zaeeřiny.

T musí zvnež dojd

ce.

T musí umvěty o dalš

vé zařízení vé zařízení mkovat s IS ečené rdem webovvé zařízení uální dobu čeny IS EET.

vé zařízení mvat BKP kód

vé zařízení msovat a o

vé zařízení mvat při be certifikátu

vé zařízení mrovat datol pro její ses

evidovat trž

validovat zade k zaevid

možnit rozšií parametry

musí být scEET na zá

komuvých služebumožní nasekání na od

musí být scd.

musí být scověřovat d

musí být scblížící se u. musí být scovou větustavování.

žbu do Taros pnuprulood Očmá

aslané dování

Kozpshobvý Veúčspv n

iřování y.

Z výmdoupISbutyp

chopna ákladě nikace

b.

Jeprwe

stavení dpověď

MačePomointmče Msta

chopno Mumnaúčpr

chopno datové

NuEEprpove

chopno době

Poza

chopno u dle

Vyge

Spec

ato doba szhraní IS potvrzujícímutné ověřit rovést extraožit do ddpověď, pod

čekává se, á mezní doontroluje seprávu, plathoda identbsaženého ýpočet BKP

eškeré dalščtenek, spprávné formnásledné a

důvodu ýznamných usí být umoplněna o pravovat zp

S EET či koude dostatepu (číslo, ře

edná se o srotokolem Hebových slu

aximální doekat na poplatník vožnosti kternetovéhoůže uzavří

ekací dobou

inimální čeanovena nausí být poumožněno Ba základě čtenkou nebro generováutná podmET. Podeprivátního koplatníka. eřejného klíčo době eaevidovat trž

ytvoření Xenerování U

Minis

cifikace proje

se počítá EET do

m FIK kódintegritu

akci dat, zatabáze, vdepsat a od

že celá traobu odezvy e platnost tnost certiftifikátoru c

v datové .

ší údaje japrávně vymáty dalšícnalýze dat.možnosti zásahů do

možněno, adalší údajůsob zpracncového za

ečné rezervoetězec, true

synchronní HTTPS. Pružeb SOAP

oba, po ktepřidělení Fv takto stakoncového o připojeníít spojení ju.

ekací dobaa 2 vteřiny.žity stejné a

BKP kód vykoncovým

bo na záklaání BKP kódmínka pro pisování zpklíče, kterOvěřování če vydanéhexpirace cžbu.

XML souboUUID.

sterstvo finan

ktu Elektroni

od přijetí o odeslánem. V ráma nepopir

zkontrolovatvygenerovadeslat.

ansakce, vč2 vteřiny. certifikátu,

fikátu certcertifikátu větě, syn

ko návaznyplněné číh dat atd.

rozšiřovánío komunika

aby datová e, aniž by

cování datovařázení. Přeovat 10 polo

e/false).

komunikacrotokol pro

P 1.1.

erou bude kIK k prove

anoveném zařízení

í. IS EETeště před

a (mezní d

algoritmy. Zygenerovat m zařízen

adě vstupnícdu. správnou

práv se drý je vy

zpráv seho pro IS EEcertifikátu

oru s poža

ncí České rep

ická evidence

Stran

datové vění datové

mci této doratelnost zpt povinné úat FIK, př

četně latenc

který podifikační aus DIČ sutaxe údaje

ost číselnéíselné hodse kontrol

í IS EETačního pro

věta mohy bylo zapvé věty na sedpokládá sožek od kaž

ci zabezpečo odeslání

koncové zaedené trančase zoha dostu

podle vytouto max

doba odezv

Zároveň muzpětně a to

ním evidovch údajů nu

komunikacěje na zá

ygenerován e děje poET. nebude m

dovanými

publiky

e tržeb

a 42 z 186

ěty na věty

obu je právy, údaje, řipravit

ce sítě

depsal utority, bjektu e pro

é řady dnoty, ují až

T bez tokolu la být

potřebí straně se, že ždého

čenou zpráv

ařízení nsakci. hlední upnost ytížení imální

vy) je

usí být o buď vanou utných

i s IS ákladě

pro omocí

možné

údaji,

ET-FP-9

ET-FP-10

ET-FP-11

ET-FP-12

ET-FP-13

Popis

KomuwebovschémPřed szpráv,

DatovSloužídokumHlavičpodpiszaříze

PotvrzSloužísamot

ZabezKomuprotokasymepotvrzcertifik

Pro šv zabe

Pro jes DIČ

Koncovopětovnpři prvn(potvrze

0 Koncovvytisknoúdaje n

Koncovfungovazjednod

2 Koncovnastavit(poklad

3 Koncovgenerovúčtenek

komunikac

nikace mezvých služeb

matu. Podepsamotným p mající iden

vá věta í k zaevido

mentu. Souččka obsahusovány na

ení.

zující datoví k potvrzentného dokum

zpečení komnikace mez

kolem. Jednetrické šifrozující datovkační autori

šifrování dezpečené s

ednoznačnouvedeným

vé zařízenné odesláníním odeslánení).

vé zařízení mout veškea účtenku.

vé zařízení mat vdušeném re

vé zařízent číslo konního místa)

vé zařízenvání spojk.

ce

zi koncovýmb dle protokpisování Xpodpisem dntickou XML

ování platečástí je sezuje základnstraně kon

vá věta ní evidence mentu.

munikace zi koncovýmnotlivé zprávání). Dato

vá věta natou IS EET

dat na síťíti IS EET, j

ou identifikav datové vě

í musí uí účtenky, jní neobdrže

musí být sceré požad

musí být scv plném ežimu.

í musí uncového za). í musí uité řady

m zařízenímkolu SOAP ML dokume

dochází ke „L strukturu

ební transaznam položní údaje oncového za

platební tra

m zařízenímávy jsou p

ová věta je paopak privá.

ťové vrstvějsou data za

aci poplatnětě.

možnit jestliže ela FIK

OpkozjimVž(pzaúčdo

chopno dované

V popř

chopno či

V mV I vza

možnit ařízení

Číúd

možnit čísel

Spnev d

m a IS EET 1.1. Datoventů se dě„kanonizacia obsah.

akce. Specžek, které o zasílané

ařízení. Ost

ansakce a

m a IS EET podepisovánpodepisováátním klíče

ě je využasílána v ot

íka obsahu

Spec

pětovné odoncové zařstí, že systůže jednat ždy je však řípadně 120

aevidování čtenky se roba zaevido

případě, žouze BKPřípadě obojí

případě fusí zaeviopačném p

ve zjednoduaevidovat traíslo koncovdajů datové

pojitá řada ebo per prodatové větě

probíhá zavé věty jsouěje dle W3C“ XML zprá

cifikace datse dělí na zprávě statní údaje

předání ide

je na síťovény primárnna privátnímm IS EET

íván SSL tevřené pod

uje jeho ce

Minis

cifikace proje

deslání se ízení pomoém je funkčo ruční úkzapotřebí d

0 hodin ve tržby. Po

rozlišuje přování tržby aže neobdržP, elektroní. fungování vidovat trapřípadě do 4

ušeném režansakci okavého zaříz věty.

musí být ovozovna. Tě.

bezpečenýu XML soubC standard

áv, aby bylo

tové věty hlavičku a

směrem k podléhají

entifikátoru

é vrstvě zaními klíči svm klíčem poT. Veřejný

akcelerátodobě z důvo

rtifikát údaj

sterstvo finan

ktu Elektroni

může dít aocí volání rční a dostupkon na kondodržet mazjednodušekus o opěíznakem. Sa doba odeí FIK, na ú

nický podp

ve zjednodansakci do48 hodin.

žimu může amžitě. ení je jed

buď per kToto rozliše

m HTTPS pbory podléhdu XMLDsig

zajištěno s

je obsaže samotný oIS EET. Tpodpisu ze

FIK. Specif

bezpečenavých odesíoplatníka (kklíč popla

or. Za tímodu rychlost

j DIČ. Ten

ncí České rep

ická evidence

Stran

automatickyrozhraní ISpný. Případncovém zařx. dobu 48

eném režimětovné od

Stejně tak seslání. účtenku vypis. V opa

dušeném ro 120 h

koncové za

ním z důle

koncové zaení je prove

protokolem,hající definog (XML Sigshodného p

ena v samoobsah datoTyto údajee strany ko

fikována je

(šifrována)ílatelů (poukoncového ztníka je po

mto akceleti zpracová

se musí s

publiky

e tržeb

a 43 z 186

y, kdy S EET dně se řízení. hodin u) pro eslání se liší

ytiskne ačném

režimu hodin.

ařízení

ežitých

ařízení edeno

, pomocí ovanému gnature). odpisu u

ostatném ové věty. e nejsou ncového

součástí

) HTTPS užívá se zařízení), odepsán

erátorem, ní.

shodovat

ZpůsoSamotprovádpoplatzpůsovybavepodepnově v

Konkrje vša

GenerBezpejednoz

ChyboNíže uvypořánotifik

KoncoVýpaddo 48

IS EETDatovDIČ v

IS EETChybnsprávnv rámc

IS EETChyba

KoncoPřípaddatováopětov

KoncoPotvrz

ChyboKód

ob komuniktnou komundět jednotlitníka. Zárobem či v jení atd.), n

psaných datvytvářena a

étní způsobk nutné kaž

rování BKPečnostní kódznačnou va

ové stavy uvedené chádání chybace do mod

ovému zařídek na stranhodin, příp

T přijal chyá věta nebdatové větě

T přijal chyný formát Xnost data, ci detailní a

T se nepoda při ukládá

ové zařízend, kdy budeá věta nebvné zaslání

ové zařízenzující datová

ové zprávy chyby C1 Z2 D

IS3 C

(D4 N5 D

v6 C

kace nikaci (včetivá pokladnveň procesjiném pořanapř. zda btových vět

a podepisov

b vytváření ždou tržbu z

P d poplatníkazbu mezi p

hybové stabového stavdulu EETAu

ízení se neně IS EET adně 120 v

bnou datoyla podepsě.

bná data vXML datovéexistence pnalýzy vklá

ařilo uložitní dat nebo

ní neobdržee vygenerovbude koncoí a nastavuj

ní obdrželoá věta neby

Chybová zpZaslaná datoDatová větaS EET. Certifikát, ktDIČ).

Neplatný poDatová větv certifikátu.Chyba při zp

tně podepisna. Ta můžsní kroky vdí (dle typbude na stpro pozděj

vána.

a přijímánízaevidovat

a. Jedná seoplatníkem

avy popisujívu je závisuditSpojení.

epodaří sponebo jakák

ve zjednodu

ovou větu sána validn

v datové věé věty neboprovozovny

ádaných dat

t data o původní da

elo zpětnován FIK, ale

ovým zařízee příznak o

o chybnou yla řádně po

ráva ová věta ne

a byla podep

terým byla

dpis datovéta obsahuj pracování d

sování, genže být zasv kontextu pu koncovétraně koncojší odeslán

í datových a obdržet je

e o kód gen a účtenkou

í situace, kslý na konk.

ojit se s IS Ekoli chyba sušeném reži

ím certifiká

ětě chybná sy

y, sekvenčnt.

atové věty.

ou potvrzuje koncové zením přijataopětovného

zpětnou podepsána c

eodpovídá ppsána certif

podepsána

é věty. je jinou id

datové věty.

Spec

nerování BKstoupena ckoncového

ého zařízenového zařízí nebo jestl

vět je vnitřnejí FIK.

nerovaný veu. Je součá

kdy nedojdkrétní příči

EET sítě. Ukládáimu evidenc

átem nebo n

yntaxe povinost číselné

jící zprávu zařízení či a. Koncovézaslání tržb

otvrzující zcertifikátem

předepsanéfikátem, kte

a datová vě

dentifikaci

Minis

cifikace proje

KP, čísla úentrálním č

o zařízení ní, technickzení docháli s každým

ní záležitos

eřejně dostuástí každé ú

e k řádnémně. Někter

á povinnost ce tržeb.

nesouhlasí

nných údajé řady) se

od IS EETcokoli jinéh

é zařízení pby.

zprávu od IS EET neb

ému formátuerý nebyl vy

ěta, neobsa

poplatníka

sterstvo finan

ktu Elektroni

čtenky atd.či jiným symohou býtkých možn

ázet k ukládm odesláním

stí poplatník

upným algočtenky.

mu zaevidovré chybové

zaregistrov

identifikačn

jů. Sémantikontroluje

ho uzavře spři neobdrž

IS EET bo nastala c

u. ystaven cert

ahuje ident

(DIČ), n

ncí České rep

ická evidence

Stran

.) s IS EETystémem nat realizovánností, softwdání kompl

m bude dato

ka. Bezpod

oritmem a p

vání tržby. mohou ge

vat tržbu ne

ní údaj cert

ika informaaž po zae

spojení a poženém FIK

chyba formá

tifikační aut

ifikaci popla

než je uve

publiky

e tržeb

a 44 z 186

T nemusí a straně ny jiným

warového etních a ová věta

mínečně

rokazuje

Způsob enerovat

ejpozději

tifikátu a

cí (např. evidování

otvrzující provádí

átu dat.

toritou

atníka

edena

Proce

PožadTímto zaevidv rámczaevid

VygenKoncodle detržeb.

Vytvovytvořdatové

Koncovyplnitzvolenkanon

ZaslánPodepslužebzprávykoncovhodnzabez

U poptento kk poku

V přípevidovpokyn

PříjemPři přivalidapřijaty

Vstupntouto akcele

GenerPříjme

UložeExtrahdatovév datopůvod

esy Evide

davek na zakrokem d

dování tržbci zaevidovdovat tržbu

nerování BKové zařízenefinovanéhoBKP je sou

oření a podření datové é věty privá

ové zařízent veškeré reného poplatnizuje a pod

ní datové vpsanou datob (synchrony webové své zařízen

né, aby prozpečeného k

platníků/konkrok být reausu zaslání

adě chyby vány k opětu pokladník

m a zpracovijetí datovéci XML form

y k dalšímu

ní branou dbranou již verátor pro p

rování FIK e-li IS EET v

ní a archivhovaná dataé věty jsou

ové větě, shdní zpráva je

nce tržeb

aevidování ává poklady do IS EEvání a nebv rámci 48

KP í na základo algoritmuučástí datov

epsání datvěty dle X

átním klíčem

ní na základelevantní údtníkem (čísepisuje na

věty směremovou větu

nní způsob lužby obsahí zasílat ví komunikackomunikačn

ncových zařalizován v ddatové věty

při zaslántovnému odka).

vání datové věty IS Emátu dat a zpracování

do IS EET veškerá darovedení zá

validní dato

ace a z datové ukládány dhodné BKPe odstraněn

b

tržby dník pokyn ET. Požadabude přidělhodin.

ě dostupný. BKP kód

vé věty, jeho

ové věty XML schémm.

dě XML scdaje. V tom

selná řada základě sta

m k IS EET koncové zakomunikachuje UUID íce datovýcci s IS EETního kanálu

řízení, kterédobě do 120y směrem k

ní datové vdeslání, ke

é věty na stET zkontrosyntaxe po

í a bude k n

bude SSL ta půjdou vákladních v

ovou větu, p

věty jsou uo archivu. J

P), která jižna.

koncovémavek můželen FIK tra

ých údajů z je jednou

o generová

atu, vyplně

chématu vymto kroku do

pokladny nandardu XM

ařízení zasce). Komuni(generovanch vět (zejT vytvořila má význam

é jsou evido0 hodin od k IS EET v o

věty (koncokterému m

traně IS EEoluje nepopovinných ú

nim vygener

akcelerátov nezašifrovalidací.

provede gen

ukládány dJestliže se jž byl přiděl

Spec

mu zařízeníe být opakoansakce. V

účtované trz klíčovýchní předcház

ění všech p

ytvoří patřičochází také

nebo číselnáMLDiag svým

ílá směremikace je za

ný dle standjména kdyžpouze jednmný vliv na

ovány v režvystavení úokamžiku v

ové zařízenmůže dojít a

ET iratelnost adajů. Pouzrován FIK.

r, který budvané formě

nerování FIK

o databázejedná o opěen FIK je

Minis

cifikace proje

, aby předovaný a to V takovém

ransakce prh bezpečnozí tvorbě da

potřebných

čnou datovoé ke generoá řada skrzm privátním

m k IS EET bezpečena

dardu) a časž eviduje vno HTTPS dobu odpo

žimu zjednoúčtenky. V

vystavení úč

ní neobdržautomaticky

a integritu de korektně

de zabezpe. Nezašifro

K.

e (včetně vyětovně zaslpoužita po

sterstvo finan

ktu Elektroni

vytištěnímve chvíli,

případě je

roveden geostních mecatové věty.

dat, čísla ú

ou větu. Poování čísla úze provozov

m klíčem.

pomocí sta protokolems odeslání dve zjednoduspojení. Vyvědi.

odušené evostatních pčtenky.

í FIK), jsoy nebo man

datové větyvytvořené

ečovat HTTvané XML

ygenerovananou větu (slední zasl

ncí České rep

ická evidence

Stran

m účtenky pkdy dojde poplatník

nerování Bchanizmů e

účtenky. Po

oplatník je účtenky dlevnu). Datov

tandardu wm HTTPS. datové větyušeném reytvoření a

vidence tržepřípadech m

u tyto datonuálně (na

y. Zároveň datové vět

TPS komunzprávy příj

ného FIK). (nastaveny laná datová

publiky

e tržeb

a 45 z 186

provedlo k chybě povinen

KP kódu evidence

odepsání

povinen e modelu vou větu

webových Hlavička

y. Bude-li žimu) je uzavření

eb, může musí dojít

ové věty základě

provede ty budou

ikaci. Za me XML

Původní element

á věta a

VytvoIS EETEET tvěty c

ZaslánVytvořkonco

PříjemPřijde-integri

ZaevidObsahk opětzaevidsměrezasílá

V přípkroku hodin.

UložeKonco

VytištK vytišúčtenkdané

oření a podT vytváří pouto datovouhybového s

ní datové vřenou potvvému zaříz

m a zpracov-li podepsaity. Získá z

dování datohuje-li zprátovnému zadování. Nasem ke koncona, zaevido

adě, že kopřistoupit,

ní přijatýchové zařízen

ění a předáštění a překu vytištěn

epsání datotvrzující dau větu podstavu podep

věty zpět kevrzující datození. Datová

vání datovéaná potvrzudatové věty

ové věty páva FIK, doaslání. V opstane-li chyovému zaříována pro o

oncové zaříaniž by pro

h dat í může prov

ání účtenkyedání účtenspolečně s

ové věty atovou větuepíše svýmpisovány ne

e koncovémovou větu á věta obsa

é věty na stující datováy FIK.

ro pozdějšošlo k jejímpačném přyba v rámcízení nebudopětovné od

ízení pracuovedlo zaev

vést uložen

y ky zákazníBKP kódem

u dle definovm privátním ejsou a odpo

mu zařízenIS EET zhuje UUID

traně koncá věta, kon

í odeslání mu zaevidoípadě ano

ci komunikade dostupnédeslání (kon

uje ve zjednvidování v I

í přijatých d

íkovi musí m. V opačn

Spec

vaného XMklíčem. V

ovídají kapi

í zasílá zpět a čas odes

cového zaříncové zaříz

ování a koa poplatní

ace s IS Eé), je i tato ncové zaříze

nodušenémIS EET. Tu

dat pro svou

dojít vždy. ném případě

Minis

cifikace proje

ML schématuopačném pitole Chybo

vytvořenýmslání.

ízení zení proved

oncové zaříík je povineET (např. datová větaení může p

m režimu evuto povinno

u vlastní ev

V případěě je místo F

sterstvo finan

ktu Elektroni

u. Bude-li vpřípadě došové zprávy.

m HTTPS

de kontrolu

ízení již neen provést spojení v da, která bylrovést dalš

vidence tržst má povin

idenci.

, že dojde FIK na účte

ncí České rep

ická evidence

Stran

vygenerovánšlo k chybě

spojením

nepopirate

eeviduje tuopětovný

době odesía v této komí pokus).

žeb, může nnost splnit

k přijetí FIenku vytiště

publiky

e tržeb

a 46 z 186

n FIK, IS . Datové

zpět ke

elnosti a

uto tržbu pokus o ílání FIK munikaci

k tomuto t do 120

K, je na n podpis účtenky.

Evidence proběhhne současně s

Obráz

vytištěním účten

Specifik

zek 8: Evidence tr

nky. Ve zjednodu

Ministerstvo

kace projektu Elek

ržeb - základní pr

ušeném režimu m

financí České rep

ktronická evidence

roces zaevidován

může dojít k zaev

ubliky

e tržeb

ní tržby pokladník

vidování tržby pr

kem

ro pozdější odesslání.

Strana 47 z 186

Obráze

První pokus je v

ek 9: Evidence trž

validní pouze v rá

žeb - zaevidování

ámci zjednoduše

Specifik

í tržby v době 48

eného režimu evi

Ministerstvo

kace projektu Elek

hodin po vystave

idence tržeb.


ktronická evidence

ení účtenky (v pří

ubliky

e tržeb

ípadě zjednodušeeného režimu 1200 hodin) pokladní

Strana 48 z 186

íkem

Obrázek 10: E

První po

Evidence tržeb - z

okus je

aevidování tržby

validní

Specifik

v době 48 hodin

pouze

Ministerstvo

kace projektu Elek

po vystavení účtkoncového

v r


ktronická evidence

tenky (v případě zo zařízení

rámci zje

ubliky

e tržeb

zjednodušeného

ednodušeného

režimu 120 hodi

režimu

n) automatizovan

evidence

Strana 49 z 186

ně na straně

tržeb.

Dávk

Pro dáje zap

Případ

V rám

Účten

Údajev sam

ková evide

ávkové zpraotřebí pode

dy užití

ci uvedenýc

ZaevidovZaevidovNedostupChyba spManuálnAutomatiHromadnChyba přChyba přChyba foChyba př

nka

, které mostatném d

BKP – teFIK – pouPodpis – klíčem) pmožné naČíslo účt

ence trže

acování neepisovat a z

ch procesů

vání tržby v vání tržby vepnost spojepojení při zpí pokyn pokcké opětov

né zpracováři ověřováníři ověřování

ormátu XMLři ukládání d

usí být sdokumentu.

nto údaj je uze v případnení-li FIK

provozního a účtenku venky – pořa

eb

ní vytvořenzasílat směr

je zapotřeb

běžném ree zjednoduš

ení k IS EETpětném zaskladníka k oné zaevidov

ání tržeb í certifikátu í certifikátu

L datové větdat

oučástí účKaždá účte

obsažen přdě, že IS Ek dispozici

místa (respvytisknout Qadové číslo

o samostatrem k IS EE

bí zohlednit

žimu s obdšeném reži

T sílání FIK opětovnémuvání tržby

datové větypotvrzující ty

čtenky, jsoenka musí m

ři každém vET tento úd, účtenka je

p. poplatníkaQR kód.

účtenky, čí

Spe

tné rozhranET samosta

t následujíc

ržením FIKmu s obdrž

u zaevidová

y datové věty

ou řešeny mimo jiné o

vystavení účdaj vrátí při e podepisova). V případ

íslo provozo

Min

ecifikace proj

ní na straněatně a sekve

í případy už

K žením FIK

ání tržby

y

patřičnou obsahovat:

čtenky. zaevidován

vána elektrodě velkého m

ovny a číslo

nisterstvo fina

ektu Elektron

ě IS EET. Venčně.

žití.

vyhláškou

ní tržby. onickým podmnožství zn

o pokladny.

ancí České re

nická eviden

Stran

Veškeré dat

a jsou

dpisem (privnaků v podp

epubliky

ce tržeb

a 50 z 186

ové věty

uvedeny

vátním pisu je

Přístu

Proceeviden

Aktéř

Aktér IS EETPoplat

Požad

ID SU-F-1

SU-F-2

SU-F-3

SU-F-4

SU-F-5

SU-N-1

SU-N-2

Proce

Popis

ZadánUživatzískan

OvěřeIS EETověřen

up poplat

sní oblast, nce vlastníc

i

T tník

davky

PožadaIS EET poplatndenní, mbázi.

IS EET agregovměsíčnprovozoAgregovpoplatnwebové

IS EET agregovoprávně

IS EET exportu

- Ukládándat nesurčené

- IS EET agregovroce.

es zobrazen

jednotlivých

ní přihlašovtel (poplatnných přihlaš

ení uživatelT ověří (proní provede

tníka k vla

která má ch tržeb. Ve

avek musí poskyíkovi agregměsíční, kva

musí poskyvané údaje í, kvartální aovny poplatvaná data bíkovi posky

é rozhraní.

musí při zovaných dat ění přihláše

musí posky zobrazený

ní a výpočemí mít vliv nk evidenci t

bude evidovaná data p

ní vlastních

h kroků pro

vacích údajník) přistupšovacích úd

le a přihlášovede autepřihlášení.

astním ag

za cíl infoeškeré údaje

PopPoskProc

ytovat ované údajartální a roč

ytovat na denní, a roční bázníka. budou ytnuta skrze

obrazování respektova

eného uživa

ytovat možných dat.

et agregovanna procesy tržby.

ovat denní pouze v aktu

agregovan

ocesu.

ů puje na vedajů.

šení ntizaci) uživ

gregovaný

ormovat pope jsou získá

is kytuje informchází agreg

Po

e na ční

Trměpoudčá+ 4

zi dle

U trž

e Prda(ppř

at tele.

Máagneag

nost Prkvmo

ných Dabýdadainfza

uálním Zapo

ných dat

eřejně dost

vatelem zad

Spe

ým údajů

platníka o ávány z pro

mace o agrgovaná data

opis ržby poplatěsíční, kvaoplatníka jedávajících tástka tržby)4 kvartály +každé pro

žbě.

ro přístup atům budeortál). Popřihlášení umá-li přihlášgregované ebude mu gregovaná dro konkrétnvartální, možnost expoata pro poýt ukládána atabáze proat a jejich frastrukturu

atěžovat či ja předchozouze měsíčn

tupný portá

daných přih

Min

ecifikace proj

m

nashromážocesu Evide

regovanýcha.

tníka jsou artální a re tak evidotržbu (v da, v jednom

+ 1 rok). ovozovny j

poplatníkae využito wlatníkovi bu

možněno dašený uživaúdaje pou

zobrazendata skrze vní výpisy ěsíční a ortu pro jejiskytování av datovém

o evidenci trposkytován

u určenou inak zpoma

zí roky tytoní, kvartáln

ál IS EET

hlašovacích

nisterstvo fina

ektu Elektron

žděných údence tržeb.

datech.

agregovánroční pohleováno 382 atové větě

roce (365

e evidován

a k vlastnímwebové roude na zákta procháze

atel oprávnuze některýn zbytek všechny proagregovandenní) IS ch stažení agregovaný skladu, kte

ržeb. Výpoční tak nebk evidenci alovat). o data nebí a roční.

T. Provádí

h údajů a v

ancí České re

nická eviden

Stran

dajích týkaj

ny skrze dedy. U kažčíselných úpoložka Cední + 12 m

no 382 úd

m agregovozhraní IS kladě úspěšet. nění zobraých provozdat, stejněovozovny. ných dat (

EET pospoplatníkemých dat by erý je oddělčet agregovbude mít vtržeb (neb

budou dost

přihlášení

případě ús

epubliky

ce tržeb

a 51 z 186

jících se

denní, ždého údajů, elková

měsíců

dajů o

vaným EET

šného

azovat zoven, ě tak

(roční, skytne m.

měla len od aných liv na ude ji

tupná,

pomocí

pěšného

ZobraMá-li zobraz

Uživat

Uživatzobraz

ZobraMá-li uPo výb

zení agreguživatel opzeny. V opa

tel vybírá m

tel může zvzen pouze m

zení/výběruživatel oprběru provoz

govaných dprávnění (aačném přípa

mezi denním

volit zobrazměsíční, kv

r provozovrávnění zobzovny uživa

at poplatnutorizaci) kadě jsou mu

m, měsíčním

ení agregovartální a ro

ny brazovat agatelem jsou

íka/provozk zobrazeníu zobrazena

m, kvartálním

ovaných datční agregov

regovaná duživateli zo

Spe

zovny veškerýcha agregova

m či ročním

t v jiném, nvaný údaj.

data více probrazeny ag

Min

ecifikace proj

h agregovananá data skr

pohledem.

ež aktuální

ovozoven, jgregovaná d

nisterstvo fina

ektu Elektron

ných dat prze jednotliv

ím roce. V t

je mu zobradata provoz

ancí České re

nická eviden

Stran

poplatníka, vé provozov

takovém př

azen jejich zovny.

epubliky

ce tržeb

a 52 z 186

jsou mu vny.

řípadě je

seznam.

Obráázek 11 Zobrazení agregovaných ddat

Minis

Specifikace projek

sterstvo financí Če

ktu Elektronická ev

eské republiky

vidence tržeb

Strana 53 z 186

Případ

V rám

Otevř

1.

2.

3.

4.

5.

dy užití

ci procesů j

ZobrazenZobrazenZobrazenExport zo

řené otázky

Jak to buudržovat (měsíce, Jakým zpMěsíčně To by moto bude).Bude nuta ne všecJe dostatjiné cenoBude um

je zapotřeb

ní celkovýchní agregovaní agregovaobrazených

y

ude s retencpouze v akkvartály a r

působem buto bude 1.

ohlo být vho tné data filtrchny? Půjdetečné agreg

ové položky?možněn expo

bí zohlednit

h agregovaaných dat jeaných dat v agregovan

cí dat? Budoktuálním rocroky)? ude realizovden v měsí

odné pro roz

rovat dle preme až na govat skrze ? Jak naložort dat?

následující

ných dat poedné provoz

jiném fiskáných dat

ou se udržoce a pro pře

ván výpočeíci nebo to bzdělení zátě

ovozovny? úroveň pokCelkovou č

žit s vouche

Spec

případy už

oplatníka zovny uživalním obdob

ovat veškeredchozí roky

et agregovanbude počítáěže (i když

Abych napkladny? částku tržby

ery, SMS pla

Minis

cifikace proje

žití.

atele bí

á dat a jak y bude k dis

ných dat? Dáno ode dneje otázkou

ř. některým

y v datové vatbami, dob

sterstvo finan

ktu Elektroni

dlouho? Nespozici pou

Denně to bue, kdy se pojaká distrib

m lidem ukáz

větě? Nebobírkami apo

ncí České rep

ická evidence

Stran

ebo se budeuze 17 údajů

ude každý doplatník reguce v rámc

zal pouze č

je nutné zad.?

publiky

e tržeb

a 54 z 186

e detail ů

den. istroval? i měsíce

část dat

ahrnout i

Kont

Proce

Tržby každoZákazúčtenkpřípad

Aktéř

Aktér vIS EET

Zákaz

Pravid

Seznakontro

NázevZákazPři neEET možnoprovozúčtenkIS EEúčtenkdefinovZákazrelevavztahu

Požad

SeznaPožadcharak

ID KU-1

KU-2

rola účte

sní oblast, k

jsou evidovu účtenku

zník má mokami dále dnou kontro

i

v kontextu eT

ník

dla

am pravidelolních úřadů

v pravidla ník kontroluevalidní úč

poskytnouost zovnu, kdka vydána.

ET dosud nku povaného časník vyplňntní údaj

ují ke konkré

davky

am funkčnícdavky vychkteristik celé

PožadaInformaschopen

Po zadzákazní

nky zákaz

která má na

vány v rámczaevidovat

ožnost ověřpracuje, a

olu poplatník

evidence trž

, která se vů, technická

uje účtenku čtence musut Zákazn

identifikde mu

nezaevidovao uplysu zkontroluňuje veše, které étní účtence

ch a nefunkházejí z uvého systém

avek ační systémn zkontrolov

dání FIK/BKíkovi odpov

zníkem

a starosti ko

ci jednotlivýt, tj. zadat jřit si, že bya odpovědnka (další pro

žeb PopPřijímzprapotřeVklá

vztahují ke ká a jiná ome

PopIS E

sí IS íkovi

kovat byla

IS Einforbudo

anou ynutí uje.

IS Euplyzaev

škeré se

e.

Při BKPúčtePro jsoujakoa čá

kčních požavedených p

mu.

m EET muvat účtenku

KP musí svědět.

ontrolu valid

ých POS (Pjejí kód do la tržba ko

né osoby, oces).

is má inform

acuje a vyhebná pro ko

ádá informa

kontrole účtezení z hled

is EET musí umEET po konrmace nezou zazname

EET musí ynutí definovidována. kontrole úč

P (společněence. Bez t

zamezení již systém validní a z

ástky.

davků kladepravidel a

Pousí být u.

Koz za

systém Syzázaješdo

Spec

dity účtenky

oint of SaleIS EET, k

rektně zprakontroloři,

mace o kohodnocuje, ontrolu. ce z účtenk

tenky. Zdrodiska návrhu

možnit kontntrole nevabytné k ideenány pro o

v případě ovaného ča

čtenky je pě s dateměchto informopakovanéem potvrzeaevidovaná

ených na ISdále je

opis ontrolou úč

účtenky aevidoval.

ystém po ákazníkovi aevidovaná ště nebyla oba, zákazn

Minis

cifikace proje

y informačn

e), dále pokkterý vede acována. IS

na základ

ontrolované případně j

ky.

ojem těchto u finálního s

trolu vydanélidní účtenkentifikaci pověření kon

ještě neeasu zkontro

povinen zákm transakce

mací nemůého vydáváeny (a účtená) je nutné p

S EET v konrozvíjejí d

tenky je mpro ověře

zadání odpověd

nebo nikodo systém

ník je na tuto

sterstvo finan

ktu Elektroni

ím systéme

kladna. Popevidenci úč

S EET s přě těchto i

účtence, je ukládá

pravidel jsosystému.

é účtenky.ky poskytnerovozovny.

ntrolním org

evidované úolovat, zda

kazník zadae a částkoůže být konání stejnýchnka by se zpožadovat z

ntextu konto konkrétn

yšleno posení, zda

dat pro dět, zda oli. V přípau zadána ao skutečnos

ncí České rep

ická evidence

Stran

em EET (IS

latník má pčtenek (dáleípadnými fanformací p

tyto infora generuje

ou aktuální

e možnost Tyto infor

ánem.

účtenky tubyla doda

at FIK, přípou) uvedenntrola proveh BKP/FIK, zákazníkovizadání data

roly validityních funkč

skytnutí infopoplatník

kontrolu je úč

adě, že úča plyne zákst upozorně

publiky

e tržeb

a 55 z 186

EET).

povinnost e tržeb). alešnými provedou

rmace e data

postupy

zadat rmace

to po atečně

padně né na edena.

které jevila

a tržby

y účtenky. čností či

ormací tržbu

musí čtenka čtenka konná ěn.

KU-3

KU-4

KU-5

KU-6

KU-7

Popis

KontrZákaz

LogovSystéma dalšfunkci

Neevidosystéme

IS EETpotřeby

IS EET

IS EET sbírá da

IS EEúčtenku„rychlé“

komunikac

ola účtenkzník v prvním

FIK přípaInformaca zaznam

Částka Informac

Datum náInformac

IČ/DIČ V případě

Název prV případě

Adresa pV případě

PoznámkV případě

vání událosm loguje růší), které monalita bud

ovaná účtem zaznam

T musí zajiy kontroly.

nesmí odm

pro nezaevalší informa

ET bude u, která části systé

ce

y m kroku zad

adně BKP e jsou použ

menána.

e použita k

ákupu e použita k

ě, že je účte

rovozovny ě, že je účte

provozovny ě, že je účte

ka a další úě, že je účte

stí zné technic

mohou být pe předměte

tenka musmenána.

stit notifika

mítnout kont

vidované úace.

schopen je ulože

ému.

dává násled

žity k verifik

verifikaci v

verifikaci v

enka nezae

enka nezae

enka nezae

daje enka nezae

cké informapoužity pro em analytick

sí být V (FsyEEzp

aci pro Poko

trolu. ISkte

čtenky Přpooda da

ověřit ná v

ISčáryckoarúč

dující inform

kaci, zda da

validity evide

validity evide

evidovaná, j

evidovaná, j

evidovaná, j

evidovaná, j

ace kontrolykontrolu „p

kého modul

Spec

případě, žeFIK v systémystému dopET musí pracování ko

o zaevidovontrolního o

EET muserá bude mři kontrole okusí o získd zákaznípoplatníka, alší) pro pot EET bu

ástech. Prvchlá data,

ontrolu. Starchivní částčtenku nebu

mace:

ná tržba by

ence tržby.

ence tržby.

e použito k

e použito k

e použito k

e použito k

y nevalidnícpodvodnéholu.

Minis

cifikace proje

e je kontrolomu neexist

plněno, příptoto zaev

ontrolním o

vání účtenkrgánu, který

sí přijmoutmít vyplněné

nezaevidokání dodateka (název

datum trtřeby kontro

ude pracovvní část b

nad kterýarší účtenki systému (

ude možné

yla zaevidov

k identifikaci

k identifikaci

k identifikaci

k identifikaci

ch účtenek (o“ nahlašov

sterstvo finan

ktu Elektroni

ovaná účtenuje, BKP n

padně jsou vidovat a orgánem.

ky systém ý bude věc

každou ké povinné inované účteečných inforv a lokažby, částk

oly. vat s účtenbude obsahými bude ky budou (pro analýzověřit.

vána systém

i poplatníka

i provozovn

i provozovn

i provozovn

(IP adresa, vání (konku

ncí České rep

ická evidence

Stran

nka neevidonebylo off-li

data falešnzpřístupnit

zajistí notdále prově

kontrolu účformace.

enky se srmací o tranace provoka, poznám

nkami ve hovat nejnmožné propřesouván

zy apod.), k

mem

a.

ny.

ny.

ny.

User-agenurence apod

publiky

e tržeb

a 56 z 186

ovaná ne do ná) IS t pro

tifikaci řovat.

tenky,

ystém nsakci

ozovny mka a

dvou ovější

ovádět ny do kde již

nt, datum d.). Tato

Proce

Popis 1.

2. 3. 4.

5.

6.

7.

es Kontrola

kroků procZákazníkwebovémfotoaparáZákazníkIS EET zV případěloterie. VV případsystém idrealizacepožádán definovanV případv systéminformacese systémzaznameKontrolní

účtenky zá

cesu k přistoupí m portálu, pátu). k vyplní požzkontroluje, ě korektní e

V případě soě nemožnédentifikuje,

e evidence to případn

ného času tdě nesprávnu není zaee o transakm pokusí o

ená. í orgán je no

ákazníkem

na formulpřípadně s

žadované inzda byla účevidence jeouhlasu jsoué kontroly zzda provoz

tržby. Zákazné doplňujíctržbu nezaené evidencevidováno, kci a poplatno získání ne

otifikován o

ář pro konoučástí mo

nformace. čtenka zaeve zákazník iu vyžádány z důvodu čzovna praczník je inforcí informaceviduje). Proce (od data

FIK je sysníkovi/provoejen DIČ z

o nové neko

Spec

ntrolu účteobilní aplika

vidována. nformován,jeho konta

časové produje ve zjedrmován o face (pro příoces končí

a nákupu ustémem neozovně (z dúčtenky ale

orektní účte

Minis

cifikace proje

nky. Formuace (která

, požádán, ktní údaje a

dlevy (při odnodušenémaktu, že tržbípad že popoděkován

uplynulo 48eevidován) ůvodu može i dalších

nce.

sterstvo finan

ktu Elektroni

ulář může může účte

zda souhlaa proces je off-line zpram režimu a ba není zatíoplatník po ním. 8, případně

je zákaznížných falešn

informací)

ncí České rep

ická evidence

Stran

být realizoenku ověřit

así se zařazukončen.

acování poknaplánuje

ím zaevidovuplynutí z

120 hodiník požádánných dat na a systém t

publiky

e tržeb

a 57 z 186

ován na pomocí

zením do

kladnou), kontrolu

vána a je zákonem

n a BKP o další účtence

tyto data

Kontrola účtenky

Zákazník

IS EET

f

FIK Da

tra

Čás

Přistoupí na formulář kontroly

účtenky

Vyplní požadované informace z účtenky

Kontroluje vložená data

K nebo BKPtum nsakce

stka

Je zadaný FIK?

Kontrovaliditu

Hledá Fzadaný

Zadaný

Nezadaný

Nalezen

oluje u FIK

FIK pro ý BKP

FIK nalezen? Nenaleze

Obráz

Zatím nelze určit zdatransakce zaevidová

Provozovna v

zjednodušeném režimu?

en

Účtenka stnež 120 ho

Účtenka stnež 48 hod

Zjednodušený režim

Standardní režim

M

M

Zatím nelze určtransakce zaev

zek 12: Kontrola ú

a je ána

Zobrazí výsledek ko

tarší odin?

tarší din?

Starší

Starší

ladší

ladší

it zda je idována

účtenky zákazník

Nevalidní

ontrolyJe účtenka validní?

Validní

120 hodin

48 hodin

Ověřuje zaevidování transakce v EET

kem

Minis

Specifikace projek

Požaduje zapojení do literie?

V

V

Zaznamenává auditní záznam

kontroly

Z

IP adresa kontroly

Datum a časSlouží pro analytický modul nkontrol



Vyplňuje kontaktní informace

Souhlasí se zadáním

doplňujících informací?

NesouhlasíPoděkkon

Souhlasí

Vyplňuje dodatočné informace

IČ/DIČ

Název p Adresa

Poznám

Druh čin

Zaeviduje nevalidní transakci

Ne

Byla transakce zaevidována v EET

Ano

na odhalování falešných

eské republiky

vidence tržeb

Strana 58 z 186

kuje za trolu

provozovnyprovozovny

mka

nnosti

Případ

Záka

Základužití js

dy užití

azník

dním případsou následu

Plánuje kSystém n

Provede Systém pnekorektn

RegistrujZákazníkúdaje, kte

NotifikujeInformačmůže se orgánu o

Kont

dem užití jeující

kontrolu na základě

kontrolu po uplynutí ní evidenci.

e do loteriek se při koreeré jsou zaz

e kontrolní oní systém zjednat o em

o existenci n

troluje účt

Plánuje

Provád

<<includ

<<includ

e „Kontroluj

provozovny

definované.

e ektní účtencznamenány

orgán zašle notifikmailovou nonově zaznam

tenku

<<i

e kontrolu

í kontrolu

de>>

de>>

e účtenku“,

y a jejího re

doby zkon

ce může zúčy.

kaci (konkréotifikaci, přípmenané ne

Spec

Noinclude>>

<<include>>

, který je bl

žimu naplá

troluje evid

častnit loter

étní implemepadně notifikorektní úč

Minis

cifikace proje

tifikuje ko

Registru

líže procesn

nuje kontro

enci tržby a

rie. Pro zap

entace neníikaci v samčtence.

sterstvo finan

ktu Elektroni

ntrolní org

uje do lote

ně rozpraco

olu evidence

a zaznamen

pojení musí

í předmětemotném syst

ncí České rep

ická evidence

Stran

gán

erie

ován. Další

e tržby.

ná případno

vyplnit kon

m tohoto poému) kontro

publiky

e tržeb

a 59 z 186

í případy

ou

taktní

opisu, olnímu

Nahlá

Proceinform

Tržby každopoplatoznáminform

Aktéř

Aktér vIS EET

Zákaz

Pravid

Seznaaktuál

NázevZákazúčtenkZákazprovozvydánaIS EEToznámZákazrelevakonkré

Bude-lz povinnepovprovozbude zruční z

Požad

Seznaúčtenkcharak

ášení neo

sní oblast, mačního sys

jsou evidovu účtenku ztník zákazn

mit. S těmitmací provedo

i

v kontextu eT

ník

dla

am pravidení postupy

v pravidla ník nahlašuku. ník identifikzovnu, kde a účtenka. T zpracuje a

mení. ník vyplňujentní údaje,

étní provozo

li chybět jednných údajůede ztotožnzovny, takovzařazeno dozpracování.

davky

am funkčnícky. Požadakteristik celé

obdržené

která má nstému EET (

vány v rámczaevidovat,

níkovi nevydo skutečnoou případno

evidence trž

l, která sekontrolních

uje nevydan

kuje mu nebyla

a třídí

e veškeré které se týkovny.

den ů, nebo se nění vé oznámeo fronty pro

ch a nefunkvky vycházého systém

účtenky

na starosti z(IS EET).

ci jednotlivý, tj. zadat jedá účtenkuosti dále pou kontrolu

žeb PopPřijíukláVklákde

vztahují kh úřadů, tec

Popnou IS E

IS E

IS Ena z

kají ExisjaképovipoplDIČ

ní

V přa neurče

kčních požazejí z uvede

mu.

zákazníke

zprostředko

ých POS (Pejí kód do

u, co je jehracují odpopoplatníka

is má informa

ádá je a genádá a upřesmu nebyla

k ohlašovánhnická a jin

is EET musí um

EET sbírá in

EET musí vzákladě infostuje min. saé informace

nnost vyplnlatníka, kdy). řípadě, že bepovede seeno pro dalš

adavků kladených prav

Spec

em

ování oznám

Point of SaleIS EET, kteo povinnosovědné oso(další proc

ace o nevydneruje data sňuje informvydána účt

ní nevydáníná omezení

možnit ozná

nformace ne

v maximálníormací poskada povinnýje zákazník

nění údajů yž je Zákaz

bude zadane přesná idší ruční zpra

dených na idel a dále

Minis

cifikace proje

mení o nevy

e), dále pokerý vede evst, musí IS oby, kontro

ces).

dané účtencpotřebná pr

mace o poptenka.

í účtenky. z hlediska

ámení nevy

ezbytné k id

í možné mkytnutých Záých paramek schopen p(např. nep

zník schope

ná adresa, kdentifikace acování kon

IS EET v kje rozvíjej

sterstvo finan

ktu Elektroni

ydané účten

kladny. Popvidenci účteEET umož

oloři, kteří

ce, tyto inforo kontrolu.

platníkovi, re

Zdrojem těnávrhu finá

ydané účten

dentifikaci p

íře identifikákazníkem.etrů. Avšak poskytnout,

požaduje seen specifiko

kde sídlí něpoplatníka, ntrolním org

kontextu ohí do konkré

ncí České rep

ická evidence

Stran

nce zákazn

latník má penek. V přípžnit tuto skna základě

ormace zpr esp. provoz

ěchto praviálního systé

nky.

rovozovny.

kovat provo. na základě

, je přizpůsoe vyplnění ovat IČ, příp

ěkolik provo bude oznágánem.

hlašování nétních funkč

publiky

e tržeb

a 60 z 186

níkem do

povinnost padě, že utečnost ě těchto

acuje,

zovně,

del jsou mu.

zovnu

ě toho, obena názvu padně

zoven ámení

evydané čností či

ID O-1

O-2

O-3

O-4

O-5

Popis

OznámOznám

Je nezvydánspecifulice, provoz

ChyboOznámna pře

PožadavInformaschopen

Po zadáprovést pokusit identifik

IS EET nepřesn

IS EET potřeby

IS EET

komunikac

mení nevydmení nevyd

Identifika

Název pr

Adresa p

Druh činn

Poznámk

Datum ná

Registrač

Částka

zbytné, abya. Tato ide

fikací Názvunepovinně

zovny a jso

ové stavy mení nevydesnou ident

vek ční systém n přijmout o

ání oznámeztotožnění se o automaci poplatn

musí zajistiných oznám

musí zajistikontroly.

nesmí odm

ce

dané účtenané účtenk

ace poplatní

rovozovny*

provozovny

nosti

ka

ákupu

ční značka

y systém EEntifikace buu poplatníkčísla popi

u určeny pr

ané účtenkifikaci popla

EET musí oznámení.

ení musí sysinformací a

matickou íka.

it zpracovánmení.

it notifikaci

mítnout ozná

nky ky bude obs

íka (IČ nebo

(město*, ul

ET byl schoude realizovka. Provozoisného). Daro posouzen

ky nelze zadatníka a pro

Pobýt Oz

propo

stém a

V poV tozpraprosypropo

ní V muzp

pro Pozaoz

ámení IS vymoza

sahovat nás

o DIČ)*

ice*, číslo p

open identifvána prostřeovna je lokaalší informaní kontrolor

dat bez vypovozovny. P

Spec

opis známením ovozovně,

orušil tím sv

případě zaoplatníka atomto pří

známení, sacuje. V ovozovny

ystém se ovozoven

oplatníka a p

případě, žusí toto za

pracování.

o ztotožněnajistí notifikznámení dál

EET musí yplněny povožné prov

achovat pro

sledující info

popisné)

fikovat poplednictvím (alizována pace jsou urem.

plnění kombProces dále

Minis

cifikace proje

je myšlenkde popl

vé povinnos

adání IČ/DIu adresy ppadě sys

se kterým případě, a název na základ

pokusí provozovnu

že je oznámaevidovat a

ní poplatnkaci kontrole prověřov

přijat každvinné informvést ztotoruční zprac

ormace:

atníka a prodaňového)

prostřednictrčeny na b

binace povinneobsahuje

sterstvo finan

ktu Elektroni

no poskytnatník nevyti.

IČ je možnrovozovny

stém vytvonásledně že je zpoplatníka

ě zadanýcidentifikova

u.

mení nekozpřístupnit

íka a provolního orgávat.

é oznámenmace. V přípožnění, mcování.

ovozovnu, identifikačnvím adresybližší identi

nných údajůe další chyb

ncí České rep

ická evidence

Stran

nutí informydal účten

né přesné ui její identifoří záznakontrolní

zadaná aa (provozoch adres at a zto

mpletní, ISt pro další

vozovny sánu, který

ní, které budpadě, že nemusí ozná

kde nebyla ního čísla, py (povinně ifikaci popla

ů, které jsoubové stavy.

publiky

e tržeb

a 61 z 186

ací o nku a

určení fikace. m o orgán

adresa ovny), všech

otožnit

S EET ruční

ystém bude

de mít ebude ámení

účtenka případně města a atníka a

u určeny

LogovProcenutné,konku

Proce

Popis 1.

2. 3. 4.

5.

6. 7.

vání událoss bude zaz, doporučujerence).

es Oznámen

kroků procZákazníkrealizováZákazníkIS EET zV případvytvořenoV případpřesná, zzaevidovKontrolníSystém p

stí znamenávaeme logová

ní nevydán

cesu k přistoupí án na webovk vyplní požzpracuje ozndě přesné o oznámen

dě, že se idzákazník neváno pro ručí orgán je nopoděkuje zá

t jednotliváání přístupů

ní účtenky z

na formuvém portálužadované innámení. identifikaceí, které je pdentifikace euvedl IČ/Dční zpracovotifikován o

ákazníkovi z

oznámení ů a jejich če

zákazníkov

ulář pro ozu, případně nformace.

e poplatníkoskytnuté knepovede

DIČ, ale názání kontroln

o novém oznza oznámen

Spec

přímo jakotností pro a

i

známení nsoučástí m

ka a provokontrolnímu

(na adresezev poplatnním orgánenámení. ní.

Minis

cifikace proje

o zájmové analýzu příp

nevydané úmobilní aplika

ozovny na u orgánu proe sídlí někíka, který nm.

sterstvo finan

ktu Elektroni

entity. Logopadných fale

účtenky. Face.

základě po další zprakolik provoznení jednozn

ncí České rep

ická evidence

Stran

ování přístuešných útok

ormulář m

oskytnutýchacování. zoven, adrenačný, je oz

publiky

e tržeb

a 62 z 186

upu není ků (např.

může být

h dat je

esa není známení

Kontrola účtenky

Zákazník

IS EET

Přistoupí na formulář oznámení nevydané účtenky

Vyo

Kontroluje zadaná data (formální

validita)

yplní požadované informace poplatníkovi a provozovne

Název provozovny DIČ/IČ

Adresa (město, ulice, číslo popi Poznámka

RZ Částka

Datum nákupu Druh činnosti

Podk

Obsahuje DIČ?

Obsahuj

Neobsahu

isné)

Obrázek 1

děkuje za kontrolu

je

uje

Ztotožnění poplatníka

Validace adresy

3: Proces nevyda

Validate a vytypování

poplatníků na základě názvu

Pona

ané účtenky záka

okus o ztotožnění a základě názvu a

adresy

Ztotožnění úspěšné?

Úspěšné

Zaznamenání oznámění poplatníka

azníkovi

Minis

Specifikace projek

NeúspěšnéZaznamenání

oznámění pro ručné zpracování



Přiložení původního znění oznámění

Nkoo

eské republiky

vidence tržeb

Strana 63 z 186

otifikace ontrolního orgánnu

Případ

Záka

IS E

ZákladDalší p

dy užití

zník

ET

dním případpřípady užit

Prohlíží oKontroloroznámenoznámenmožnost zpracova

OznačujeKontroloroznačujeoznámenkontroly j

PřiřazujeKontrolor(naplánov

ZtotožňujOznámeninformackontrolor


Oz

N

dem užití jetí jsou násle

oznámení (tr v tomto přní pro potřební, poplatníknahlížet na

ané.

e oznámenír po realizac

e oznámení ní není smajiž není potř

oznámení r konkrétní ované, přípa

je nezpraconí, které neí zadaných em, který m

e kontrolní oní systém zjednat o em

o existenci n

znamuje nevydúčtenku

Notifikuje kontorgán

e „Oznamuedující

třídí, filtrujeřípadě užití by dalšího zka, provozoa detail ozná

í jako zpracci kontroly ujako zpracozáno, je jej řebné.

pro zpracovoznámení o

adně probíh

ované oznání možné aZákazníkem

může ztotož

orgán zašle notifikmailovou nonového ozná

danou

rolní

uje nevydan

, nahlíží nadisponuje rzpracování.vny, lokaceámení, přiřa

cované u poplatníkaované a sysmožné pou

vání označuje přající) a dalš

mení automaticky m (oznamo

žnění vykon

kaci (konkréotifikaci, přípámení.

Spec

Prohlíží (třídí,

nahlíží

O

Ztotožň

nou účtenk

detail) rozhraním, k. Oznámene, případné adit oznáme

a a ověření stém k danéužít v další a

říznakem, žší kontrolor

přiřadit popovatelem), jeat s využitím

étní implemepadně notifi

Minis

cifikace proje

oznámění filtruje,na detail)

Označuje oznájako zpracov

ňuje nezpracovaoznámění

Přirazujepro zpr

u“, který je

které mu umí je možné tdalších par

ení kontrolo

vydávaní nému oznámanalytice, n

že je předměby neměl m

platníkovi (ae připravenom svých sc

entace neníikaci v sam

sterstvo finan

ktu Elektroni

áměnívané

ané

oznáměníracování

e blíže proc

možní nahlítřídit a filtrorametrů. Kooru, případn

nebo nevydámení přidá pnicméně pro

ětem probíhmít možnost

a jeho provoo pro další hopností.


ncí České rep

ická evidence

Stran

Ko

cesně rozp

ížet na jednvat dle data

ontrolor má ně označit ja

ávání účtenpříznak. Totoo potřeby př

hající kontrot s ním prac

ozovně) na ruční zprac


publiky

e tržeb

a 64 z 186

ontrolor

racován.

notlivé a

ako

nek o římé

oly covat.

základě cování

opisu, olnímu

Kont

Procetržba s

Aktéř

Aktér vIS EET

Kontro

IS ADI

Pravid

Seznapostup

NázevKontroregistrIS EET

KontroinformIS EETfiskalizIS EETprovozrežimuIS EET

IS EETintegradalší s

Požad

SeznaPožadcharak

ID KN-1

KN-2

KN-3

KN-4

rola ze st

sní oblast, správně zae

i

v kontextu eT

olor

IS

dla

am pravidepy kontrolní

v pravidla olor ověřuje race poplatnT integruje

olor zadává ace z účtenT informuje zace. T naplánujezovna nebyu. T umožní ev

T poskytne ace evidencsubjekty.

davky

am funkčnícdavky vychkteristik celé

PožadavInformaschopenk dani. Informaschopenk EET. InformaumožnitúčtenkyIS EET(při offúčtence

rany FS a

která má nevidována.

evidence trž

l, která se ích úřadů, t

požadovanníka. IS ADIS.

a ověřuje nky o stavu

e kontrolu, kyla v online

videnci kon

možnost ce kontrol p

ch a nefunházejí z uvého systém

vek ční systémn ověřit reg

ční systémn ověřit reg

ční systét ověřeníy. T musí podf-line nákue) ověřit jeho

a CS

a starosti k

žeb PopPřijízpraKonvykoOvě

vztahují kechnická a

Popné IS E

regisPro rozhIS E

IS Ezaev

když IS Euplyfung

ntrol. IS Ekont

ro IS Ekteréinforinfor

kčních požvedených p

mu.

m EET mugistraci popl

m EET mugistraci popl

ém EET í informa

d zadání poupu umístěo validitu.

kontrolní ná

is má a kon

acuje, ukládtroluje zae

onané kontrěřuje registra

e kontrolníjiná omeze

is EET musí strován k dazískaní info

hraní IS ADEET sbírá in

EET na závidována. EET po ko

ynutí nezbyguje) a inforEET umožntrol poplatnEET musí ého budourmace o kormaci zejmé

žadavků klapravidel a

Pousí být latníka

IS po

usí být latníka

IS po

musí ací z

IS a d

odpisu ěn na

V bubý

Spec

kup. Kontro

ntroluje infdá evidenci vidování trrole. aci poplatní

ímu nákupuení z hledisk

umožnit ani a registrormace o reIS, kde jsou

nformace z ú

ákladě zad

ontrolu účtytného časurmuje kontroní vedení aíků, včetně obsahovat

u další subontrolách péna o ulože

adených nadále je

opis EET musí

oplatník regi

EET musí oplatník regi

EET po zadalší) ověří

případě, žeude účtenkaýt schopen

Minis

cifikace proje

olor proved

formace oo kontrole.

ržby, vkládá

íka k daním

u. Zdrojem ka návrhu fi

zjištění infrován v EETegistraci k du tyto informúčtenky pro

aných dat

tenky s Bu (dle režimolora o výsl

a evidenci pinformací o

t integračnbjekty (Celnpoplatníků. ených sankc

a IS EET vrozvíjejí d

umožnit naistrován k d

umožnit naistrován k E

adání inform, zda byla tr

e byl nákupa obsahovat

ověřit, zda

sterstvo finan

ktu Elektroni

e nákup a k

o nákupu,

á a upřesň

m.

těchto prainálního sys

formace, zT.

dani je IS EEmace vedeno kontrolu.

informuje,

KP naplánmu, ve kteedku. probíhajícíco udělenýchí rozhraní,ní správa) Toto rozhra

cích.

v kontextu ko konkrétn

a základě IČdani.

a základě IČEET.

mací z účtenransakce fis

p proveden t část podp

a poplatník

ncí České rep

ická evidence

Stran

kontroluje,

tyto infor

ňuje informa

avidel jsou stému.

zda je pop

ET integrovny.

zda byla

nuje kontroerém provo

ch a ukončh sankcích. prostřednschopny z

aní je nutn

kontrolního ních funkč

Č ověření, z

Č ověření, z

nky (FIK/BKskalizována

v off-line reisu. IS EETvlastní ce

publiky

e tržeb

a 65 z 186

zda byla

rmace

ace o

aktuální

platník

ván na

tržba

olu po zovna

ených

ictvím zasílat né pro

nákupu. čností či

zda je

zda je

KP, IČ a.

ežimu, T musí rtifikát

KN-5

KN-6

KN-7

KN-8

Popis

KontrKontro

LogovSystém

Proce

Popis 1.

2. 3. 4. 5. 6.

IS EETnezaevi

IS EET

IS EETpro zápi

IS EETpotřeby

komunikac

olní nákupolor bude do

IČ/DIČ poBude pou

FIK/BKP Bude pou

Datum traBude pou

InformacEvidenčndůvodu, p

vání událosm zazname

es Kontroln

kroků procKontrolorwebovémKontrolorIS EET oKontrolorV případěV případě

a. Úz

b. ÚDz

T musí zadovaných t

musí vést e

T musí obsis do eviden

T musí zajikontroly.

ce

o IS EET za

oplatníka užito pro ov

užito pro ko

ansakce, čáužito pro ko

e o kontrolení záznam opřípadně po

stí ená při evide

í nákup

cesu r přistoupí m portálu, přr vyplní pož

ověří registrar provede koě nevydání ě vydání účÚčtenka byzaznamenáÚčtenka neDIČ se neszaznamená

ajistit zpractržeb.

evidenci kon

sahovat ronce kontrol.

stit notifika

adávat tyto

věření regist

ontrolu správ

ástka, podpontrolu správ

e obsahující inoznámek.

enci kontrol

na formulářípadně sou

žadované inaci k dani aontrolní nákúčtenky sečtenky: yla správnvá průběh k

ebyla správshoduje apvá průběh k

papopo

cování V EEza

ntrol. IS jedjsosa

ozhraní .

Z tržktekoumzá

aci pro Pozapo

informace:

trace k dan

vné evidenc

pis, číslo povné evidenc

nformace o

ly identifika

ář pro kontučástí mobinformace. a EET. kup.

e legitimuje

ně zaevidokontroly. ně zaznam

pod.) – konkontroly.

Spec

atřící k tomuodepsána coplatníkovi).

případě, žeET musí aevidování p

EET musí dnotlivé koou zejménaankce a jejicdůvodu vyk

žeb externíeré využívontrol, musmožní zapsáákonné udělo dodatečnajistí notifikaokračovat v

i a registrac

ce tržby po

kladny, číslce tržby po

proběhlé k

ci kontrolor

trolu registlní aplikace

a udělí san

ována – k

menána (obtrolor se le

Minis

cifikace proje

uto podpisucertifikátem . e tržba pro

naplánovpo uplynutí

obsahovatontroly evida historie kch důvod. konávání koími orgány vají vlastní í IS EET ání proběhllování sanké verifikac

aci kontrolnkontrole dle

ce k EET

platníkem.

lo provozovplatníkem.

kontrole, udě

ra, který kon

trace. Forme.

kci.

kontrolor s

bsahuje nevegitimuje, u

sterstvo finan

ktu Elektroni

(jinými slovnáležícím

oběhla v ofvat kontrzákonem d

t evidenční dovány. Důkontrol pop

ontrol elektr(zejména IS pro v

obsahovatlé kontroly,

kcí. i off-line trího orgánue výsledku.

vny

ělených san

ntrolu prove

mulář může

e legitimuj

validní FIK,uděluje san

ncí České rep

ická evidence

Stran

vy zda bylakontrolova

ff-line režimrolu budodefinované d

modul, kdeůležité inforplatníka, ud

ronické evidCelní sprá

vedení evt rozhraní,

aby bylo m

ransakce sy, který bude

nkcích včet

edl.

být realizo

je, vrací

podpis je nkci, vrací

publiky

e tržeb

a 66 z 186

a tržba anému

mu, IS oucího doby.

e jsou rmace dělené

dence ávou), idencí které

možné

ystém e dále

ně

ován na

zboží a

falešný, zboží a

7.

c. ÚpKdvpz

Kontrolor

Účtenka byplánuje dalKontrolor jedalší nákupvaliditu BKPpřípadnou záznamu kor zadává inf

yla vydána lší kontrolu

e informováp (systém P a neplánusankci. Ná

ontroly. formace o k

v off-line ru. Systém án o výsledv tomto př

uje pozdějšásledně za

kontrole do

Spec

ežimu – koparalelně

dku, vrací sípadě zkon

ší kontrolu oaznamenává

systému AD

Minis

cifikace proje

ontrolor zaznaplánuje

se do provontroluje valoff-line evidá a doplň

DIS.

sterstvo finan

ktu Elektroni

znamenávákontrolu

ozovny, kdeiditu FIK,

dence), legiuje informa

ncí České rep

ická evidence

Stran

á průběh kopozdější ee může zrepřípadně ptimuje se aace k evide

publiky

e tržeb

a 67 z 186

ontroly a evidence. ealizovat podpis a a uděluje enčnímu

Kontrola účtenky

Kontrolor

IS EET

IS ADIS Ověřu

poplatpřidě

Ověřu

Zadávověřen

k da

Opětovná kontrola?

Ne

je registraci níka k dani ‐ ěleno DIČ

je registraci v EET

vá data pro ní registrace ani a EER

Provádí kontrolnínákup

Provádí připadnýdalší nákup

Obsahuje účtenka FIK?

Ano

Ne

í Vydal poplatník účtenku?

Vydal

Zadává informace z účtenky pro kontrolu

zaevidováni poplatníkem

Nev

ý

Autnákupu

Ob

Nalezen

Kontroluje validitu FIK

Hledá FIK pro zadaný BKP

FIK nalezen?

vydal Legitimuje se

tomaticky se provádí pouze při prvnímu, opakovaný nákup by neměl plánovat

kontrolu účtenky

brázek 14: Proces

Provozovna v zjednodušeném

režimu?Nenalezen

Zjednodušený režim

Standardní režim

Je transakce zaevidována v

EET?

NezaevidovánaUděluje sankc

ZaevidovánaVrací zakoupe

tovar

m t .

s kontrolní nákup

Starší

Starší

Účtenka starší než 120 hodin?

Účtenka starší než 48 hodin?

Mladší

Mladší

ci

ný

p

Minis

Specifikace projek

120 hodin

48 hodin

Ověřtra

Zadává informace o kontrole do

evidence kontrol EET

Plánuje další kontrolu po uplynutí doby pro evidenci



řuje zaevidování ansakce v EET

Notifikuje kontrorgán

Zadává informace o kontrole do IS ADIS

eské republiky

vidence tržeb

Strana 68 z 186

rolní

Případ

Kont

Základpřípad

dy užití

trolor

dním případdy užití jsou

Ověřuje rKontrolorevidenci

Vede eviKontrolorpoplatník

Plánuje oIS EET p


Ověřuje

Ověřu

dem užití je následujíc

registraci r v tomto přtržeb. Tento

denci kontrr (případně ka zazname

off-line ověřpři off-line tra

e kontroloraní systém zjednat o em

o proběhnuté

e validitu fi

uje registra

e „Ověřuje ví

řípadě užití o případ už

rol externí info

enává průbě

ření ansakci nap

a zašle notifikmailovou noé validaci a

Vede evide

<skalizace

ci

<<

validitu fisk

ověřuje, zdžití využívá

ormační sysěh kontroly

plánuje ově

kaci (konkréotifikaci, přípa jejím výsle

S

P

enci kontro

<<include>>

N

<include>>

kalizace“, kt

a je poplatnintegrované

stém integrua eviduje u

ěření po uply

étní implemepadně notifiedku.

M

pecifikace pr

Plánuje offli

ol

Notifikuje ko

terý je blíže

ník registrové rozhraní in

ující rozhrandělené san

ynutí zákon

entace neníikaci v sam

Ministerstvo fi

rojektu Elekt

ine ověření

ontrolora

e procesně

ván k dani anformačníh

ní EET) po kce.

nem definov


inancí České

ronická evide

Stran

í

Ex

rozpracová

a k elektrono systému A

vykonání ko

vané lhůty.


é republiky

ence tržeb

a 69 z 186

xterní IS

án. Další

nické ADIS.

ontroly u

opisu, olnímu

Spe

Vyme

Předmsouvisvěta).

Požad

Stanov

1

23

4

Požad

Požadelektro

ID požOP.E.

OP.E.

OP.E.

OP.E.

5 Tyto vystav

cifikace

zení rozsah

mětem spesejících s účDaná spec

stanovenstanovenstanovenstanovenstanovenstanoven

davky na oc

vení požad

. pro vydápotvrzen

. obdrží-li

. obdrží-li a násled

. Neobdrž

davky na oc

davky na oconickou form

žadavku PV.POS.int

PV.POS.Od

PV.POS.Up

PV.POS.Im

povinné inf

viteli účtene

e ochra

hu

ecifikace ocčtenkou a t

cifikace obsa

ní požadavkní výchozíhoní ochrannýcní postupu tvní algoritmů ní způsobu p

chranné pr

avků na oc

ání účtenkyní jejího přijepotvrzení, vzamítnutí,

dně se pokuží-li odpověď

chranné pr

chranné prvmu účtenky

tegrita

dpovednost

plnost

mplementac

formace jso

ek (povinným

anných

chranných to jak v její ažená dále

ků na ochrao konceptu ch prvků vorby a valipoužitých p

prezentace

rvky EET

hranné prvk

y zasílá povetí a přidělevystaví účte(například

usí zaslat účď, vystaví o

rvky EET ele

vky EET rey stanoveny

SpecifiVystavipotvrzeoproti s(Integrit

t Vystavizpůsobpocházkterém (Neodmstraně vVystavizpůsobinforma(např. č(Pokrytna stran

ce Požadoběžně nad nevystavit(Implem

ou vymezenmi subjekty)

prvků E

prvků EEfyzické („vyv tomto do

nné prvky ochranných

idace vybrapro ochrannochrannýc

ky EET vyc

vinný subjeení ID enku opatřez důvodu nčtenku znovoff-line účten

ektronické

espektující vy následovn

kace požatel účtenky

ení umožňovstavu, ve kteta elektronictel účtenkyem, aby bí od danéhoji vystavitel

mítnutelnostvystavitele) tel účtenkyem, aby se

ace účtenkyčas vystaveí všech důleně vystaviteované potvrdostupným

ezbytně nuttele účtenkymentovateln

ny samostat) a EET

S

EET

ET je vymytištěné“) fokumentu za

h prvků

aných ochrané prvky a jh prvků.

hází ze zák

kt elektroni

enou získanneplatné elevu. nku bez ID,

formy účt

výše naznaě:

davku y je povinenvalo zjistit merém ji vystacké účtenkyy je povinebylo následo vystavitell potvrzovalt odpovědno

y je povinee toto potvy včetně inní, DIČ, proežitých infoele – úplnosrzení vystavi prostředknou úroveňy. nost vystavit

tně v rámci

M

pecifikace pr

mezení klíčormě, tak v jahrnuje:

anných prvkejich síly

kladního ko

cky účtenk

ným ID zákaektronické z

které neob

enky

ačený konce

n ji potvrdit modifikaci čavitel potvrzy na straně en ji nezpodně možnoe a že se v. osti za vyst

en ji nezpovrzení vztahformací soovozovna, aormací účtenst) vitele musí ky. Reálné ň narušova

telova potvr

struktury d

Ministerstvo fi

rojektu Elekt

čových ochjejí elektron

ků

ncepčního

u do systém

azníkovi. značky), mu

bdržel.

epčního mo

takovým zči poškozenzoval. vystavitele

ochybnitelněo ověřit, ž

vztahuje k ú

tavení elekt

ochybnitelněhovalo na vuvisejících

apod.)5. nky vystavit

být reálně provádění

at běžnou o

rzení dostu

atových vět

inancí České

ronická evide

Stran

hranných innické formě

modelu EE

mu EET a

usí zjednat

odelu EET

způsobem, ní informací

) ě potvrdit že dané pčtence ve s

tronické účt

ě potvrdit všechny výs jejím vys

telovým pot

implementpotvrzován

oprávněnou

pnými pros

t předávaný

é republiky

ence tržeb

a 70 z 186

nformací ě (datová

T kdy:

očekává

nápravu

jsou pro

aby toto í účtenky

takovým potvrzení stavu, ve

tenky na

takovým ýznamné stavením

tvrzením

tovatelné ní nesmí u činnost

tředky)

ých mezi

OP.E.

OP.E.

OP.E.

OP.E.

OP.E.

OP.E.

OP.E.

OP.E.

OP.E.

6 Tyto vystav

PV.POS.Va

PV.POS.St

PV.EET.va

PV.EET.Sto

PE.EET.int

PE.EET.Od

PE.EET.Up

PE.EET.va

PV.OST.va

povinné inf

viteli účtene

alidace

top

alidace

op

tegrita

dpovednost

plnost

alidace

alidace

formace jso

ek (povinným

Vystaviskutečnpoškozepotvrzo(Ověřenstraně vVystavi(ukončezaměstvystavit EET mzasílajícúčtenkyoproti s(Ověřenstraně EEET mčinnost„nevaliddojít v dEET je aby totinformakterém (Integrit

t EET jezpůsobpocházkterém (NeodmúčtenkyEET jezpůsobinformapotvrze(PokrytpotvrzeEET mskutečnpoškozepotvrzo(OvěřenEET) Třetí strověřit svystavitinforma(Ověřenstranou

ou vymezenmi subjekty)

tel účtenky ně vystaviteení informa

oval. ní/validace vystavitele) tel musí ení činnostnance apodtele, ke kter

usí mít možcí či konty a že nedstavu, ve ktení/validace EET)

musí mít moi, oznámendnost“ dalšídůsledku dapovinno př

to EET poací zaslané ji EET potvta přijaté ele

e povinno oem, aby toí od EET aji EET potv

mítnutelnosty na straně e povinno oem, aby se

ace potvrzovením na straí všech dů

ením EET namusí mít mně potvrzovení inform

ovalo. ní/validace

rany musí msi z potvrzentelem danéací účtenky ní/validace u)

ny samostat) a EET.

S

musí mít melem danéací účtenk

vystavitelo

mít možnoti, ztráta zd.) oznámitré by mohlo

žnost ověřirolovaný sdošlo k moerém ji vysta

vystavitelo

ožnost (a pní vystaviteího vydávananých okolnředanou valotvrzení um

účtenky povrzovalo. ektronické úopatřit předoto EET poa že se vztavrzovalo. t odpovědnEET) opatřit přede toto potvvané účten

aně EET (naležitých infa straně EE

možnost ovvatelem dan

mací účten

EET potvrz

mít (vyžaduní účtenky vé účtenky aoproti stavuEET potv

tně v rámci

M

pecifikace pr

možnost ověé účtenky aky oproti s

ova potvrz

ost (a pozařízení, pot „nevalidnoo dojít v důs

t si z vystasubjekt je odifikaci či avitel potvrzova potvrz

povinnost) vele apod.)ní potvrzeníností. lidní účtenk

možňovalo otvrzované z

účtenky na danou validotvrzení násahuje k potv

nosti za p

danou validvrzení vztahnky včetně apř. čas přijformací přijET – úplnosěřit si z Ené účtenkyky oproti

zení přijaté

uje-li to provvystavitelema že nedou, ve kterémvrzení přija

struktury d

Ministerstvo fi

rojektu Elekt

ěřit si ze svéa že nedotavu, ve k

ení elektro

ovinnost) vodezření n

ost“ dalšího sledku daný

avitelova poskutečně poškození

zoval. ení elektro

v případě o zajistit krí vystavitele

ku potvrdit tzjistit modifze strany E

straně EETdní účtenkusledně umovrzované úč

potvrzení p

dní účtenkuhovalo na vinformací sjetí/potvrzeaté elektro

st) ET potvrze

y a že nedostavu, ve

elektronické

voz a použím, že daný šlo k modif

m ji daný suaté elektron

atových vět

inancí České

ronická evide

Stran

ého potvrzeošlo k modikterém ji v

onické účte

v případě ona nekalou

vydávaní pých okolnos

otvrzení účtevystaviteleinformací

onické účte

okolností (uroky, které

e, ke které b

akovým způfikaci či po

EET oproti s

T) u potvrdit ožňovalo očtence ve s

přijaté elek

u potvrdit všechny vý

souvisejícícní, apod.)6.nické účten

ení účtenkyošlo k mode kterém

é účtenky n

ívání EET) subjekt je sfikaci či pobjekt potvrz

nické účten

t předávaný

é republiky

ence tržeb

a 71 z 186

ení, že je ifikaci či vystavitel

enky na

okolností činnost

potvrzení tí.

enky, že m dané účtenky

enky na

ukončení é zajistí, by mohlo

ůsobem, oškození stavu, ve

takovým ověřit, že stavu, ve

ktronické

takovým ýznamné h s jejím

nky EET

y, že je difikaci či

ji EET

na straně

možnost skutečně oškození zoval. nky třetí

ých mezi

OP.E.

OP.E.

Požad

Požadfyzicko

ID požOP.F.

OP.F.

OP.F.

OP.F.

OP.F.

7 Tytovystav

PE.OST.va

PE.OST.va

davky na oc

davky na ocou formu úč

žadavku POS.Vazba

PV.POS.int

PV.POS.Od

PV.POS.Up

PV.POS.Im

o povinné ivované pov

alidace

alidace

chranné pr

chranné prvčtenky stano

a

tegrita

dpovednost

plnost

mplementac

nformace jinnými subj

možnospotvrzoinformapotvrzo(OvěřenstranouTřetí strověřit sskutečnúčtenky(Ověřenstranou

rvky EET fyz

vky EET reoveny násle

SpecifiVystavitsrozuminforma(např. čjsou pře(Srozuminformaformě úVystavit(potvrzopoškozevystavil(Integrit

t Vystavit(potvrzododatečvystavitvystave(Neodmstraně vVystavit(potvrzovšechnys jejím v(Pokrytípotvrzo

e Požadoimplemedostupnnutnou účtenky(Implemdostupn

jsou vymezjekty zákazn

st ověřit si ovatelem daací potvrzooval. ní/validace u) rany musí m

si z EET poně EET a y oproti stavní/validace u)

zické formy

espektující vedovně:

kace požadtel fyzickéitelným zp

ace účtenkyčas vystaveedávány v emitelná tišací na fyzicúčtenky) tel účtenkovacím údaení informa. ta fyzické útel účtenkovacím údčných infotele a vztaena. mítnutelnostvystavitele) tel účtenkovacím úday významnvystavenímí všech důvacím údaj

ované potvrentovatelnýnými prostř

úroveň ny. mentovatelnnými prostře

zeny samoníkům.

S

z potvrzenané účtenkyované účte

EET potv

mít (vyžadutvrzení účteže nedoš

vu, ve kteréEET potv

y účtenky

výše nazna

davku é účtenky působem y včetně infení, DIČ, proelektronickétěná prezcké účtenc

ky je povajem), aby ací účtenk

čtenky na sky je povdajem), abrmací určihuje se k d

t odpovědn

ky je povajem), aby é informace

m. ůležitých inem na stranrzení vystavý a na fyředky. Reáarušovat b

nost vystaedky)

statně v rá

M

pecifikace pr

ní účtenky oy a že nedoenky oprot

vrzení přija

uje-li to provenky, že pošlo k modifém ji EET povrzení přija

ačený konce

je povineuvést vešformací soovozovna, aé podobě účence, úplne na infor

vinen opatento údaj y oproti st

straně vystavinen opaby bylo nt, že dandané účten

nosti za v

vinen opase tento p

e účtenky v

nformací fyně vystavitevitele (potvyzické účteálné potvrzběžnou op

avitelova

ámci struktu

Ministerstvo fi

rojektu Elekt

od EET, žeošlo k modi stavu, v

até elektron

voz a použíotvrzovatelefikaci či pootvrzovalo.

até elektron

epčního mo

en na ni škeré releuvisejících apod.)7 ve sčtenky. nost a jemace uved

atřit ji takumožňovaltavu, ve k

avitele) atřit ji taknásledně mý údaj po

nce ve stav

ystavení fy

atřit ji takpotvrzovací včetně info

yzické účteele – úplnosvrzovací údaence prezzování nesrávněnou

potvrzení

ury fyzickéh

inancí České

ronická evide

Stran

e EET je sifikaci či po

ve kterém

nické účten

ívání EET) em dané účoškození in

nické účten

odelu EET

jednoznačevantní výs jejím vys

shodě s úda

ednoznačnádené v elek

kovým potl zjistit modkterém ji v

kovým potmožno s pochází od vu, ve kter

yzické účte

kovým potúdaj vztah

rmací souv

nky vystavst) aj) musí býentovatelnýsmí nad nčinnost vy

fyzické

ho výtisku

é republiky

ence tržeb

a 72 z 186

skutečně oškození

ji EET

nky třetí

možnost čtenky je nformací

nky třetí

jsou pro

čným a ýznamné stavením aji, které

á vazba ktronické

tvrzením difikaci či vystavitel

tvrzením podporou

daného rém byla

enky na

tvrzením hoval na visejících

vitelovým

ýt reálně ý běžně nezbytně ystavitele

účtenky

účtenky

OP.F.

OP.F.

OP.F.

Stano

Konceprvky založe

8 V texse jedsubjek9 Hašopro alhash rpohybKlíčov

PV.POS.va

PE.EET.ID

PV.OST.va

ovení výcho

ept řešení oEET a dos

en na:

jednoznavystavitepředávajednoznavystavitevytištěnévyužití kryptograinformacúčtenek využití vfyzickéhointegrity dostupnovýtisku úpodobě dostatečzákazníkochrannývyužíván

xtu je užívádnalo o pouktů. ovací funkcgoritmy typresp. „heš“)

bují od 160 vé jsou pro k

Jedná seJedná sevýpočetnjednosměBezkoliznhodnoty (

alidace

alidace

ozího konce

ochranných stupnou leg

ačně specieli účtenekné účtenky)ačně specelem zákazé účtenky a konceptu Pafie) k zajice. Podepisa vystaviteybraných ino výtisku úvybraných osti přijateúčtenky. Kr(možnost

čně čitelné kem a dalých prvkůSny hashova

no pojmu eužití ve smy

ce náleží mpu SHA jso) konstantnído 512 bitůkvalitní has

e o funkci: he o jednos

ně možné zěrnost. nost: není v(hashe) jso

Vystavit(potvrzopoškozevystavit(OvěřenvystavitEET jeelektronvydavat(PoskytTřetí strověřit svystavitinforma(Ověřen

eptu ochra

prvků je s gislativní op

ifikovaných k a EET j).

cifikovanýchzníkovi jakpožadavků

PKI a to štění integ

sujícími stral potvrzení nformací (z čtenky tak,klíčových dlných foremritériem přijjejího reálnznakové s

lšími subjeStanovení zcí funkce9.

elektronický yslu elektro

ezi kryptogu dle typu í omezené dů). hovací funk

hashovací fusměrnou fuzpětně stan

výpočetně u shodné –

tel účtenkyovací údaj) ení informtel potvrzovní/validace tele)

e povinno pnické účtentel příslušnotnutí ID účterany musí mi z potvrzentelem danéací účtenky ní/validace

nných prvk

ohledem nporu (zejm

datových akožto příj

h povinnýckožto jejímů na ně).

zejména egrity předáanami jsouo jejich příjmdatových v aby ji bylo

dat a z hledm prezentajatelnosti jsného vytištsady, ve ktekty). Blížepůsobu pre

podpis s tíonické znač

grafické funvstupy omedélky (např

kce následuunkce vracíunkci: pro novit jeho

možné efe– není tzv. m

S

y musí mítje skutečněací fyzické

val. vystavitelo

poskytnout nky potvrzou fyzickouenky ze stramít (vyžaduní účtenky vé účtenky aoproti stavuelektronické

ků EET

na potřeby éna zákon

větách projemcem úč

ch položkácu příjemci

elektronickévaných inf jak vystavmu.

vět elektrono možno saiska odpově

ace ochransou zejméntění) a přeteré je info

e viz kapitezentace oc

m, že ve smčky vytváře

kce, poskytezeny délkoř. pro algorit

ující vlastnoí pro stejný

daný výstvstup (pův

ektivně nalémožné naléz

M

pecifikace pr

t možnost ě pořízen jíé účtenky

ova potvrze

vystaviteli ovací iden účtenku.

any EET) uje-li to provvystavitelema že nedou, ve kterémé účtenky tř

EET, stanoo elektron

o elektroničtenek (str

ch vytištěn(stanoven

ého podpisformací a vitelé účten

icky předávamostatně oědnosti vyst

nných prvkůna délka infehlednost (ormace pretola 0 „Stachranných p

myslu zákonené systémy

tující pro jaou 264 až 2tmy typu SH

osti: vstup vždy tup hašova

vodní zpráv

ézt libovolnzt výpočetn

Ministerstvo fi

rojektu Elekt

ověřit si, ím a že ned

oproti sta

ení fyzické

na základntifikační ú

voz a použím, že daný šlo k modif

m ji daný suřetí stranou

ovené požanickém pod

cké předávruktura a o

né účtenkyní povinnýc

su 8 (s vyuodpovědnoek, tak EE

vané formy ověřovat ztavitele za jů či jejich formace v dpředevším

ezentována anovení zpprvků V rám

na o elektroy na straně

akýkoliv příp2128 bitů) poHA se výsle

stejnou hoací funkce vu). Tato vl

é dva vstuě efektivně

inancí České

ronická evide

Stran

že dané pdošlo k modavu, ve kt

účtenky na

dě předanédaj, kterým

ívání EET) subjekt je sfikaci či pobjekt potvrz)

davky na opisu a sou

vání účtenobsah elek

y předávanch položek

užitím asyosti za pře

ET jakožto

účtenek) khlediska zajejí vystavečástí na f

dané prezese jedná

a dále popůsobu premci prezent

onickém poě EET a po

pustný vstuoskytují výsedné hashe

dnotu - výst(daný has

lastnost se

py (zprávy) kolize.

é republiky

ence tržeb

a 73 z 186

potvrzení difikaci či terém ji

a straně

é validní m opatří

možnost skutečně oškození zoval.

ochranné uvisející),

ek mezi ktronicky

né jejím k fyzicky

ymetrické edávané příjemce

ochraně achování ní. fyzickém entované

o volbu oužitelná ezentace ace jsou

odpisu by ovinných

up (např. stup (tzv.

dle typu

tup. sh) není e nazývá

), jejichž

Naforrmátováno: Čeština

Stano

Pro poochran

OchraPOS XML z

Elektro

Identif

Časov

OchraBKP

OKP

ObecnFIK

Stano

Ochrabudouformátvytvář

Identifpřenáš

ovení ochra

otřeby EETnných prvků

anné prvky

zprávy

onické podp

fikátor zpráv

vé údaje

anné prvky

né ochrann

ovení postu

anné prvky u použity vtu XML, v nřeny dle dop

fikátory zprášeny v jedn

Je výpočfunkce vr

anných prv

T v souladu ů EET, budo

y zaměřené

Infjso

pisy Infpodejej

v JemovaJe

y zaměřenéBeOKpříproje prvBKsilnBKOffumza (koOKpo

né prvky

KópřevlaúčFIK

upu tvorby

zaměřené souladu s

němž budouporučení W

áv budou gnoznačné re

četně nemoracela stejn

ků

s požadavou v rámci

é na elektro

formací jsouou definova

formace přodepisoványetekovatelnoich zaslání.

dnotlivé zpožno identifzby mezi zpdnotlivé zpr

é primárně ezpečnostníKP přiměřípadného nosazuje odppředevším

vku. Bez poKP má též nou vazbou

KP je vždy pffline kód pmožňuje kon

vystavení ontrolních oKP je vždy ouze v přípa

ód přidělovaedmětem tastnosti plntence ze stK je vždy př

a validace

na elektrone standardu prezentov

W3C XML s p

enerovány eprezentaci

ožné najít eou hodnotu

vky na ochrEET použív

onickou vý

u předávánné datové v

edávané vy tak, aby ost jejího př

právy jsou fikovat a řešprávami. rávy jsou op

na ochraní kód povinřenou ocharušení) výpovědnost p

prezentovoužití OKP n

vlastnosti u na jejího vpřenášeno eovinného sntrolu integtištěné účte

orgánů/pracpředáván

adě, kdy je t

aný systéméto specifi

ní daný kódrany systémřenášen ele

vybraných

nickou výmdy a standavány přenášpreferencí „

dle standarzahrnující d

efektivně k u (hash).

S

ranné prvkyvány násled

ýměnu dato

ny formou zvěty.

v rámci zprábyla zajišt

řípadného n

opatřeny všit případné

patřovány č

u informacnného subjhranu inteýznamných povinného satelná a ponení samosdostatečně

vystavitele aelektronickysubjektu, je rity a prosaenky. Kód jecovníků) a nv elektronictato vydává

mem EET. Dkace. Nicmd též úlohumu EET. ektronicky i

h ochrannýc

měnu datovýardními posšené datové„XML envelo

rdních postdatum a ča

dané zprá

M

pecifikace pr

y EET a nadující ochra

ových vět m

zpráv v XM

áv jsou obtěna integrnarušení) a

vhodnými ié opakovan

časových úd

cí fyzickéhojektu, který

egrity (resúdajů uvedsubjektu zaoužitelná pstatně schopě unikátníha její obsahy i tištěno n

pomocnýmazuje odpove určen pro

není běžně cké komuniána v offline

Daný kód jeméně bez ou identifikát

tištěn na vý

ch prvků

ých vět mestupy. Jedné věty. Elekoped signat

upů s vyžitís s přesnos

ávě jakouko

Ministerstvo fi

rojektu Elekt

a základě vnné prvky:

mezi povin

ML formátu,

běma stranrita těchto odpovědno

identifikátorné zaslání z

daji.

o výtisku úý umožňujep. detekodených na va její vystavpodoba danpen výše uvo identifiká. a výtisk účt

m ochrannývědnost povo specifickémanipulováikaci a na

e režimu.

e řešen saohledu na toru přidělo

ýtisk účtenk

ezi povinnýmná se o poktronické poture“.

ím UUID. Čstí na vteřin

oli jinou zpr

inancí České

ronická evide

Stran

výchozího k

nými subje

jejichž obs

ami elektroinformací

ost odesilate

ry tak, abyzpráv či nás

účtenky e spolu s kvatelnost výtisku účtevení. Úlohouného ochranvedené zajiátoru účten

tenky. ým prvkem,vinného su

é potřeby koán zákazníkúčtenku je

amostatně asvou pova

ovaného za

ky.

mi subjektyoužití standodpisy zprá

Časové údajny.

rávu, pro k

é republiky

ence tržeb

a 74 z 186

konceptu

ekty a

sahem

onicky (resp. elů za

y bylo sledné

kódem jejího

enky a u BKP nného stit. ky se

který bjektu

ontroly kem.

tištěn

a není ahu a aslané

y a POS dardního áv budou

je budou

kterou by

Kód F

Ochradvojicidatový

Při offkdy nevýtisk

OKP z

Kód Onásled

1. 2. 3.

Kód B

1

Ověřeposkyt

Stano

S ohlepotřeb

10 S oinformvytvořv certvyčerpÚpravrelevabylo p

IK je řešen

anné prvky zi kódů BKPých vět. Na

fline vydání ebyla účtenúčtenky.

zaslané ele

OKP je hodně na fyzic

M = vH = hOKP = E

BKP je násle

. BKP = h

ení integritytovanou ko

ověření inověření in

o jev

o jeo je

dp

o Jdod

validace validace validace

ovení algori

edem na abami zadava

ohledem namace o ideřenému podifikátech) dpány všechvou této skantní veřejnostačující o

samostatn

zaměřené p a OKP. Obfyzickou úč

účtenky poka v elektro

ktronicky př

odnotou eckém výtisk

vybrané výzhash (M) Encrypt (M,

edně odvoz

hash (OKP)

y a původuntrolujícímu

ntegrity a pntegrity a pe sestavenvýtisku valide spočten he získán hadešifrování podepisujícíJe-li H = H1držitelem popačném přdaným poviBKP BKP je proúspěšná. V

tmů použi

aktuální staatele řešen

a nutnost zentifikaci cedpisu. Z tohdaného povny klíče dankutečnosti ý klíč povin

ověření vůč

ě a není pře

primárně naba tyto kódyčtenku je vž

oskytuje kódonické podo

ři online vyd

lektronickéhku účtenky.

znamné úda

PrivKeyPOS)

en jako has

).

u fyzické úu systémem

ůvodu fyzicůvodu fyzic

na zpráva dované účtehash kód H ash kód H

elektronicího povinné1, pak je vaoužitého veřípadě není nným subje

ovedena spV opačném

tých pro oc

av a dopoí (zejména

zajistit co ertifikátu a oto důvodu

vinného subného povinnmůže být nného subjei tomuto jed

edmětem té

a ochranu iny jsou vždyždy tištěn B

d OKP možobě doručen

dání umožň

ho podpisuJe vytvořen

aje prezento: hash kód

) : zašifrová

sh kód OKP

účtenky (vym EET) má d

cké účtenkycké účtenkyM z vybra

enky zprávy M 1 uložený vckého podého subjektualidace úspeřejného k účtenka va

ektem).

očtení hodnpřípadě nen

chranné pr

ručení v obs ohledem

nejkratší d tedy veře

u je nutno pbjektu, dokuného subjekuvedení úektu („podpdnomu spec

S

éto specifika

nformací fyy zasílány eKP a v příp

žnost kontrona do systé

ňuje ověřen

u vybranýcn standardn

ované násled dat D ání H soukro

P, tedy:

yžaduje nádvě základn

y dle OKP y dle OKP jeaných význ

v kódu (eledpisu za u10 pěšná (účtelíče resp. alidní (je na

noty BKP1 ní kód BKP

rvky a jejich

blasti kryptna reálnou

délku prezeejného klíčpři validaci oud není valktu. daje o sé

pisový certifcifikovaném

M

pecifikace pr

ace.

yzického výtlektronickou

padě vydání

oly integrity ému EET a

í BKP na st

ch významním postupe

edně na fyz

omým klíče

ástroj – naní etapy:

e provedenonamných úd

ektronickémpoužití

enka si zachcertifikátu,

arušena její

= hash (OK validní.

h síly

tografie a použitelno

entovanýchče povinnéověřovat velidace úspě

riovém čísfikát dané

mu klíči/certi

Ministerstvo fi

rojektu Elekt

tisku účtenku cestou syí v offline ře

a původceje možno p

traně systém

mných údajem:

zickém výtis

en povinnéh

př. lokální

o následovndajů uvede

m podpisu) správného

hovala integkterý danýintegrita, ne

KP). Je-li B

s ohledem st a implem

h informacího subjekt

eškeré veřejěšná, nebo

le certifikáúčtenky“). fikátu.

inancí České

ronická evide

Stran

ky jsou zaloystému EETežimu též O

účtenky i zpoužít pouze

mu EET.

ů, prezent

sku účtenky

ho subjektu.

aplikaci č

ně: ených na f

OKP. H1 jeveřejnéh

gritu a bylaý klíč obsaebo není vy

BKP = BKP1

na korekcmentovateln

í neobsahutu, který ojné klíče (onejsou ne

tu, který oPři této var

é republiky

ence tržeb

a 75 z 186

oženy na T v rámci

OKP.

za stavu, e fyzický

tovaných

y

.

či službu

fyzickém

e získán o klíče

a vydána ahuje). V ystavena

1, pak je

ce dané ost) jsou

uje OKP odpovídá bsažené úspěšně

obsahuje riantě by

stanovjejich s

Elektr

Pro elověřovalgorit256 zcertifik

Hasho

Pro tvmotivu

Identi

Pro tvse zeidentif

Stano

K pres ohlezvolen

Prezerespek

Jak sprezen

veny následsíla.

ronické pod

lektronické vání elektrotmus RSA sz rodiny algkátů. Konkré

elektronicmůže býtelektronicelektronicelektronicelektronictvorby kó

ovací algor

orbu bezpeující délky v

ifikátory

vorbu identifejména o pfikátory či pr

ovení způso

ezentaci ocdem na jej

ný rámec pr

ntace je kktovat násle

prvky muv případeprvky muz pohleduprvky mochrannéfyzické oje vhodnémohou uzrychlova

stanoví kapntovat:

BKP OKP v přFIK v přsamostat

dující pro k

dpisy

podpisy buonických ps délkou krygoritmů SHétně potom

cký podpis t použito věcký podpis cký podpis cké podpisycké podpis

ódů OKP a z

itmus pro t

ečnostního kvytištěné po

fikátorů budpřípady typrvky, které

obu prezen

chranných pich délku aro reprezen

klíčová v předující před

usí být prezech, kdy tenusí být repu volené znusí být pr

ého prvku usoby neodré využívat t

usnadnit naat pořizován

pitola 0 „S

řípadě potřeřípadě vydtně a není p

klíčové použ

ude v rámcodpisů v syyptografický

HA2. Toto m:

kořenovéhětší délky klcertifikátů scertifikátů Py vytvářenéy vytvářenéz nich odvo

tvorbu kód

kódu BKP zodoby BKP p

de primárněu identifikámají též fun

tace ochra

prvků v ráma lze používtaci a přeno

řípadě ochdpoklady a o

zentovány pnto ochrannprezentován

nakové sadyrezentoványumožňovalarazovala nataké alterna

akládání s rní účtenek p

Stanovení

eby vydání dání účtenkpředmětem

žité ochran

i řešení EEystému EEých klíčů 20paradigma

ho certifikáíče – 4096 systému EEPOS ve sch na straně Eé na straně

ozených kód

du BKP

z kódu OKPpoužito has

ě využito vhátory zasílankci identifik

anných prv

mci datovývat standaros dat XML

hranných pomezení:

pouze tehdný prvek nenny v dostaty a strukturyy úspornýma stále jehod míru nezbativních (nereprezentovpro povinné

ochranných

účtenky v oky v onlinetéto specifi

S

né prvky d

ET použito ET bude ja048 bitů a ja

se vztahu

tu CA ve bitů - v příp

ET ve schémhématu SHAEET se schě POS (včedů BKP) se

P bude s ohshovacího a

hodné formyaných zprákátorů i jino

ků

ch vět nenrdním norem.

rvků na fy

dy, je-li to úní nutný tečně přehy zápisu m způsobe

o využití fyzbytně nutno

eznakovýchvanými infoé subjekty.

h prvků“, j

off-line móde módu (rikace).

M

pecifikace pr

ále v této k

schématu kožto asymakožto has

uje též na

schématu padě víceúromatu SHA-2A-256/RSA2hématem SHetně elektroschématem

hledem na nalgoritmu SH

y UUID dlev. Ve vybr

ou konstrukc

ní nutno řem a doporu

yzickém vý

účelné, tedy

hledné a č

em tak, abzickými osoou ) tištěných rmacemi p

je nutno n

u reprezentac

Ministerstvo fi

rojektu Elekt

kapitole sta

SHA-256/Rmetrického hovací funkelektronick

SHA-256/Rovňové stru

256/RSA2042048 HA-256/RSonických pm SHA-256/

nutnost přijaHA1.

příslušnýcraných přípci (viz např.

ešit prezenučení. Rozh

ýtisku účten

y nepoužíva

itelné podo

by výslednbami, přípa

forem prezro občany

na fyzickém

ce daného

inancí České

ronická evide

Stran

novené alg

RSA2048. Talgoritmu

kci algoritmké podpisy

RSA2048 (puktury CA)48

A2048 odpisů pro /RSA2048.

atelné a pro

h standardůpadech mo BKP).

ntaci danýchodující je

nky. Zde j

at prezenta

obě, tedy

ná délka tadně od po

entace, paka zjednodu

m výtisku

o kódu je

é republiky

ence tržeb

a 76 z 186

goritmy a

Tvorba a používat us SHA-v rámci

případně

potřeby

o občana

ů. Jedná ohou mít

ch údajů zejména

je nutno

aci prvků

zejména

tištěného užití tyto

kliže tyto ušovat a

účtence

řešena

S ohleprvky délka

OBO

Oba oreprezspecif

Znako

S ohlenejlép-f], nekódov

Vychádále redané v přípapodobúsporn

Výsled

OBO

Ve fázkteré j„0“) či velké účtenk

Altern

Vhodnv rámc

Vzhledaplikanedispinform

edem na voa jejich sílyochranných

Ochranný pBKP OKP

ochranné pzentovatelnéfickou formu

ová repreze

edem na jee přehlednéboť hexade

váním BASE

ází se ze staedukováno délky vstupadě BKP a bě bude přnější.

dná prezent

Ochranný pBKP OKP

zi návrhu řejsou „koliznmalé l a jeO a malé l)ku na straně

nativní repr

nou alternatci EET je m

Současnvýznamn

zjednodukontrolní

reprezen

dem k tomuce pro zařponuje reá

maci je nutno

v případěve znako

olené algoriyStanoveníh prvků BKP

prvek KrSHSH

prvky mají é na fyzicku prezentac

entace kód

ejich délku é a čitelné ecimální preE64.

andardní 64o použití p

pů vkládánydvěma zarořijatelně pře

tace ochran

prvek

ešení je možní/zaměniteldnička („l“ v) jinými z toě povinných

rezentace Q

tivní reprezemotivováno s

á případněných informa

ušit skrze Qorgány

tací velkých

u, že QR kóřízení typu

álně využiteo při použití

ě potřeby vyové podobě

itmy stanoví algoritmů P a OKP ná

ryptograficHA1 HA-256/RSA

charakter kém výtisk

ce.

ů

a požadaveprezentaceezentace zd

4 znakové spotenciálnícy (výstupy ovnávacímiehledná a

nných prvků

KódováníBASE64 BASE64

žné dále zvlné z hledisvs „1“). Ods

ohoto pohledh subjektů.

QR kódem

entací údajsnahou:

ě alternatiací účtenky

QR kód načt

h informací

ód není po SmartPhoelný. Z důví QR kódu n

ydání účtena případně

vené kapitopoužitých p

ásledující:

ké schéma

A2048

binární infu účtenky.

ek na úspoe ve formě hdvojnásobu

sady [0 – 9,ch závěrečnby byly stai znaky v přčitelná a s

ů je tedy vo

í Vý4334

vážit úpravuska čitelnosstranění těcdu nekolizn

ů na fyzické

vní reprezy jedním QR

tení klíčový

typu OKP.

užitelný a "one či tablvodu zajišnakládat s m

nky v off-lině současně

S

olou 0 „Stanpro ochrann

a Biná20 256

formace reOba ochr

ornou reprehexadecimáuje binární d

, a –f, A – Zných zarovnandardně dořípadě OKPsoučasně o

lena násled

ýsledný po3 42

u základní zsti“. Jedná schto kolizí lzními znaky,

ém výtisku

zentace ocR kódem

ch informac

"přepsatelnet, není p

štění přístumodelem, k

e módu budQR kód

M

pecifikace pr

novení algoné prvky a

rní délka v

esp. řetězcranné prvky

ezentaci neálního zápisdélku vstup

Z, ‘/’, ‘+’]. Stnávacích znoplňovány j

P). Výslednáoproti hexa

dovně:

očet prezen

znakové sadse o případze docílit nákteré jsou s

účtenky je

chranných

cí fyzického

ý" bez pouro člověka

upu občanakdy:

de fyzická ú

Ministerstvo fi

rojektu Elekt

oritmů použjejich síly“

v bytech

e bytů a y BKP a O

ení vhodné su v 16 znapu. Proto je

tandardní kónaků ‚=‘, ktejedním zaroá prezentacadecimálním

ntovaných

dy z pohleddy typu velkáhradou kolsoučasně ti

použití QR

prvků a

o výtisku úč

žití prostřed, který taka/zákazníka

účtenka ob

inancí České

ronická evide

Stran

žitých pro oje základn

nejsou tedOKP tedy

použití staakové sadě volena pre

ódování BAeré by jinak ovnávacím ce kódu ve mu zápisu

znaků

du odstraněké O a nulalizních znakištitelné na

kódu. Jeh

optimálně

čtenky pro o

dků jako jskovým prosa k jím po

sahovat BK

é republiky

ence tržeb

a 77 z 186

ochranné í binární

dy přímo vyžadují

andardně [0 – 9, a

ezentace

ASE64 je byly pro znakem znakové výrazně

ní znaků, a („O“ vs ků (např. fyzickou

o použití

dalších

občany a

ou např. středkem oužitelné

KP a FIK


Kapacjednot(schopčtení/skvalitubude vydáva

Optimvýznaznako

Příkla

Výše spříkladpro po

OchraprvekBKP

OKP

v případěznakové

cita QR kótlivých typů pnost výslskenování).u vytištění ado značnéajících na s

álním cílemmných údavé sady.

d reprezen

specifikovadu, který je otřeby příkla

anný

Kó

BA

BA

ě potřeby vpodobě a d

ódů (objem(1 až 40), edného Q. QR kódy a/nebo většé míry dánastraně povin

m, je zajistitajů účtenky.

ntace

ná forma retéž doplně

adu v podob

ódování

ASE64

ASE64

vydání účtedále variant

m reprezendle velikost

QR kódu s vysokou í plochu vya dostupnonných subje

t QR kódem. V takovém

eprezentacen o alternabě „BKP:…

Výsle

X0Z2l7LshiTtrr/DXpZy1HNQWVY/tGKJcM0CFy5bzXS0T8cd/eJS7tWvudCs2/KPlNpQ/q6LWTINt5rJ+VqoIsLoBcPNx7NO2dUFnmwfjFjah71A

enky v onlině OKP ve

ntovatelné ti znakové sodolávat kapacitou s

ytištění. Pouou kvalitou ektů fyzické

m reprezentm případě j

e vede k řetivní reprez. OKP:…“)

edný řetěz

sLJcBUPhUD5uv1GxhXQeE88i3y4JJWb6QTRbbSMfh6jP1d5DpjuqeQvv8oy1z2tP4piwhIafLUahP9B6fJni+qxdKQo5gez6FVMOz21MNmA4fQ5J76kxdAmi7IvmLZ

S

ne módu bznakové po

informace sady ukládachybám/kvastovek až tiužitelná kaptisku a doúčtenky.

taci nejen ke nutno uv

etězcům, jejzentaci QR ):

zec k tisku

UGW2tWc6CXhoSrfwvfjD0Xyj2zbdAV2vGT0W7qGCiD9QHfZFdNz8tzLGYIc+QfJSFqiegrfUtu7DHD+Q4cYWGaHvMpw40kUX+uEyGtigRdFF3PlUnEtw

M

pecifikace pr

bude fyzickáodobě nebo

- počet "ané informaalitě/poškozisíců znakůpacita QR kostupným ti

kódů BKP, važovat s ka

jichž podobkódem (kód

TmM Y96kGKlgxRAKDaA3KS4GrYFhG0UxpgRSI+dCJ

Ministerstvo fi

rojektu Elekt

á účtenka o QR kód o

"znaků") seace a dle úrzení výtisků jsou "hustkódu pro poskovým pro

OKP a FIKapacitou cc

ba je uvededováno je s

Výsled

inancí České

ronická evide

Stran

obsahovat bsahující té

e výrazně rovně korekku či násté" a vyžadotřeby systéostorem u

K, ale také vca 1000 zna

ena na náslspojení BKP

ný QR kód

é republiky

ence tržeb

a 78 z 186

BKP ve éž OKP.

liší dle kce chyb sledného ují vyšší

ému EET zařízení

vlastních aků širší

edujícím P a OKP

d

TecLogickmají b

V prvn

1.

2.

3.

4.

5.

6.

7.

8.

Jedno

V rám

hnické ké aplikačnbýt v rámci f

ní fázi realiz

Registrac

Evidence

Přístup p

Kontrola

Nahlášen

Kontroly

Následná

Loterie

otlivé proces

ci požadova

Interní ce

Auditní z

o E

o E

Evidence

Zálohová

Zabezpe

a techní schéma afunkcionality

zace projekt

ce a eviden

e tržeb

poplatníka k

účtenky zá

ní neobdrže

ze strany F

á analýza a

sy a jejich p

aných proc

ertifikační a

áznamy

Evidence au

Evidence au

e přístupový

ání provozn

čená část te

nologicaplikace EEy aplikace z

tu EET se z

ce údajů a

k vlastním st

kazníkem

ené účtenky

FS a CS

vyhodnoco

požadavky j

esů je nutn

utorita

uditních záz

uditních záz

ých údajů po

ího prostřed

echnického

ké řešeET je definozajištěny.

zajišťuje pro

certifikátů o

tatistickým

y zákazníke

ování dat

sou rozeps

é zajistit da

znamů z ko

znamů o pří

ovinných su

dí

o řešení v ú

S

ení projováno poža

ostředí pro n

o povinném

údajům

em

ány v samo

alší následu

munikačníh

ístupech ev

ubjektů

rovni Důvěr

M

pecifikace pr

jektu adavky jedn

následující

m subjektu

ostatné část

jící souvise

ho rozhraní

vidovaných

rné

Ministerstvo fi

rojektu Elekt

notlivých de

procesy:

ti zadávací

ející služby:

osob

inancí České

ronická evide

Stran

efinic proces

dokumenta

é republiky

ence tržeb

a 79 z 186

sů, které

ace.

Logic

Uživat

Uživat

Uživat

cká archit

telé prostř

telé EET jso

Evidovan

o P

o B

o M

Zákazník

o B

o M

Kontrolní

o B

o M

B2B

o E

telská rozh

Zabezpeo Xo H

tektura ap

edí EET

ou děleni do

ný povinný s

POS – prod

Browser – p

Mobilní aplik

k (držitel účt

Browser - př

Mobilní aplik

í orgány GF

Browser - př

Mobilní aplik

Externí syst

ISD

Zák

Cze

hraní portá

čená oblastXML akceleHSM FIK - V

plikace

Obráze

o následujíc

subjekt

ejní místo,

přístup na p

kace - příst

tenky)

řístup na po

kace - příst

FŘ a GŘC

řístup na po

kace - příst

témy státní

DS – Informa

kladní Regis

ech Point

álu EET

t erace - ZpraVystavení b

ek 15: Logic

cích skupin

pokladna

ortálové roz

up na portá

ortálové roz

up na portá

ortálové roz

up na portá

správy

ační Systém

stry

acování zasbezpečnostn

S

cká architek

zhraní EET

álové rozhra

zhraní EET

álové rozhra

zhraní EET

álové rozhra

m Datových

ílaných účteního eviden

M

pecifikace pr

ktura EET

aní EET

aní EET

aní EET

Schránek

enek nčního kódu

Ministerstvo fi

rojektu Elekt

u FIK

inancí České

ronická evide

Stran

é republiky

ence tržeb

a 80 z 186

Datov

Z hled

Hlavn(dále invest

V obintegrprodu

Aplikas poža

Evidenceo Uo U

Řízení přo E

Náhledy o U

Kontrolnío U

Call Cento U

Zákaznico U

Loterie o U

B2B rozh

vá a aplikač

diska datové

v datovédvěma technolog

ím cílem v DÚ) na bázic, sjednoce

lasti aplikarační/testovukční.

ační vrstva badovanou re

Řízení záAPP účteAPP evidPKI – inteAudit uživAPP účteInterní užAPP loteAPP anaADIS – nESS – naAplikačníZálohováDatabázo

o Ro Do E

e CA Uživatelské Uživatelské řístupů Evidence užna účtenku

Uživatelské í orgány Uživatelské trum Uživatelské cká hlášení Uživatelské

Uživatelské hraní – rozh

ční vrstva

é vrstvy jsou

ém úložišti datovými

gických pro

datové obzi nově budení zabezpe

ační vrstvyvací pro in

bude tvořenedundancí a

ápisu do DBenky – zpradence – eviderní certifikavatelských enky, Náhleživatelské rorie – aplikačlýza – zpra

napojení na apojení na eí sběrnice Eání – provozová vrstva Rychlá dataDlouhodobéEvidence po

rozhraní evrozhraní vy

živatelských rozhraní ná

rozhraní pr

rozhraní pr

rozhraní zá

rozhraní účhraní pro na

u v současn

vybudovanúložišti. D

ostorech v lo

blasti je kondovaného dečeného př

y a datovntegraci a

na serverova funkciona

B – zápis účcování účtedence povinační autoritpřístupů a k

edy na účtenozhraní – ační část EEcování anavybrané slu

elektronickoESB – orchezní zálohy d

a – evidenceé úložiště – ovinných su

vidence povystavení po

h přístupů e

áhledů na ú

ro kontrolní

ro potřeby p

ákaznických

častníků lotapojení na IS

né době dat

ném v rámcDatová úlokalitě dato

nsolidovat, atového úloístupu k da

vých úložištestování

vou farmou,alitou.

čtenek do denek nných subjea komunikacenky – realizplikační roz

ET loterie lýz v systémužby ADIS ou spisovouestrace jedndat EET a a

e účtenek (2evidence ú

ubjektů, pro

S

vinných subožadovanýc

evidovaných

účtenky

orgány GF

pracovníků

h hlášení o

terie SDS, Zákla

ta ukládána

ci projektu ožiště buvého centra

sjednotit aožiště při dotům.

šť jsou vPOS aplika

na které b

atabáze

ektů

e – zpracovzace zpracozhraní EET

mu EET

u službu notlivých sluaplikačních,

2-4 měsíceúčtenek na dvozoven a X

M

pecifikace pr

bjektů h certifikátů

h povinných

FŘ a GŘC

CallCentra

chybách úč

adní registry

a:

EET s poždou umísa SPCSS

a integrovatodržení zás

vybudovánaací a dolad

ude provoz

vání auditnícování přístup

pro pracov

užeb systémdatabázov

) dobu 10 let XML podan

Ministerstvo fi

rojektu Elekt

ů

h subjektů

čtenek

y, CzechPoi

žadavkem těna ve

t technologsady ochran

dvě prodění jejich

zováno aplik

ch záznamůpů na účtenníky GFŘ

mu EET ých serverů

ní

inancí České

ronická evide

Stran

int

replikace ddvou odd

ie datovýchny již vynal

vozní prosvazeb a p

kační prostř

ů systémunky

ů

é republiky

ence tržeb

a 81 z 186

dat mezi dělených

h úložišť ožených

středí – prostředí

ředí EET

Preze

Aplikas poža

Základněkoliportál provoz

Rozhr

o Ko Ao L

RozhraníSPCSS,

o A

ntační vrst

ační vrstva badovanou re

dem prezenk skupin uža B2B roz

zu navzájem

raní:

B2B – ko

Evidencecertifikač

Access m

Náhled n

CallCent

Kontroly

Audit- ev

Kontroly a sAuditní záznLoterie

í GFŘ – inCall centru

Agregované

tva

bude tvořenedundancí a

ntační vrstvživatelů syszhraní je om.

omunikační

e a CA –ční autoritu

manageme

na účtenku

trum – auto

y – autorizo

vidence aud

sankce namy

nterní uživam pro veře

é a analytick

na serverova funkciona

vy je uživastému a rozod sebe log

rozhraní de

– autorizova

ent – správa

u – neautoriz

orizované ro

vané rozhra

ditních zázn

atelské rozhejnost

ké údaje

vou farmou,alitou.

atelský porzhraní B2Bgicky a fyz

edikované p

ané uživate

a uživatelsk

zované roz

ozhraní pro

aní pro kon

namů

S

hraní pro z

na které b

tál prezent pro realiza

zicky odděl

pro komunik

elské rozhr

kých přístup

hraní pro n

služby pos

trolní orgán

M

pecifikace pr

zaměstnanc

ude provoz

tující jednoaci služeb eeno tak, a

kaci s POS

raní pro ev

pů

áhledy na je

skytované e

ny GFŘ

Ministerstvo fi

rojektu Elekt

ce GFŘ a

zováno aplik

tlivé uživatevidence úby nedochá

videnci pov

ednotlivé úč

externím dod

inancí České

ronická evide

Stran

GŘC, Serv

kační prostř

telská rozhčtenek. Užázelo k ovl

vinných su

čtenky

davatelem s

é republiky

ence tržeb

a 82 z 186

vicedesk

ředí EET

raní pro ivatelský ivňování

bjektů a

služeb

Metr

Dále je

Popis

Poče

Poče

Průmpodp

B2B

Průmúčten

Špičkpropu

Průmsysté

Maximsystépři šp

Poža

Rych

Dlouh

Certif

Minimcertifi

Poče

Uživavrstv

Počeuživa

Prům

ObnoReco(RTO

Pro účten

Pro da uživ

Obnoúložiš

Reco(RPO

riky systém

e uvedena

Dostupno

Dostupno

s

t účtenek za

t účtenek za

měrná velikosisem)

rozhraní pro

měrný počet pnek

ková ustnost přijím

měrná odezvmu na vysta

mální odezmu na vys

pičkovém zat

adavky na úl

lé úložiště po

hodobé úloži

fikační auto

mální početikátů

t vystavovan

atelské rozhva

t současně ptelů webové

měrná odezva

ova systémuovery TimO)

rychlé úložnek a B2B ap

dlouhodobé úvatelské web

ova dat ště účtenek

overy PoiO)

mu

základní sa

ost klientské

ost datovýc

rok

den

st účtenky (s

o sběr účten

přijímaných

požadovamaných účten

va centrálnvení účtenky

va centrálnstavení účtetížení

ložiště

o dobu

ště na dobu

orita

t evidovan

ných certifiká

hraní, aplika

pracujících ho rozhraní

a na dotaz

u po incidenme Object

žiště evideplikační rozhr

úložiště účtebové rozhran

dlouhodobé

nt Object

ada metrik:

ého rozhran

h služeb v r

Poč

10 5

3

s el.

nek

aná nek

ního y

ního enky

ých

tů

ční

ntu tive

nce raní

nek í

ého

tive

ní v režimu

režimu 24/7

čet

500 000 000

0 000 000,00

8,50

347,00

4 000,00

0,33

2,00

3

4

2 000 000

200

200

0,5

12

48

až 30

10

S

24/7,

7,

Jedna

,00 ks

0 ks

kB

Ks/s

Ks/s

sec

sec

měs

roky

ks

ks/m

uživ

sec

hod

hod

dní

min

M

pecifikace pr

notk Po

sec

sec

Jevy

Jevy

síců S úlo

y S

Ro

min

vatelů

Časyap

Časyap

Obdlo

Mohaurdapř

Ministerstvo fi

rojektu Elekt

oznámka

edná se o odystavení FIK

edná se o odystavení FIK

rezervou okaožiště na 5 m

možností roz

ozšiřitelné na

as potřebnystému a plikačního roz

as potřebný pystému a zproplikačního roz

bnova dat zeouhodobého

ožná ztráta davarovanéhorčuje pravděpat v časovémředcházejícím

inancí České

ronická evide

Stran

ezvu systéma uložení úč

ezvu systéma uložení úč

amžitého rozměsíců

zšíření na 10

a 5 000 000

ný pro ozprovozněnízhraní, obno

pro obnovu ovoznění zhraní

e zálohy o úložiště účte

dat při obnovo systému. Hopodobnou ztr

m období m havárii.

é republiky

ence tržeb

a 83 z 186

mu na čtenky

mu na čtenky

zšíření

0 let

obnovu í B2B ova dat

enek

vě odnota rátu

Poža

Poo

Woo

Roo

V rámvrstev

Doo

Aoo

Poo

Koo

SLA p

Základ

Sezna

Násled

Číslo

1 2

3

Param

dované p

Portál pro po provozno dostupnWS rozhrano provozno dostupnRozhraní proo provozno dostupn

mci návrhu av architektu

Datová vrstvo provozno dostupnAplikační vrso provozno dostupnPrezentační o provozno dostupnKomunikačno provozno dostupn

ro zajištěn

dní návrh pa

am služeb

duje přehle

služby K

PP

P

metry služeb

provozní a

ovinné subní doba 24xnost v proví pro fiskaliní doba 24xnost v provo front-officní doba 8,5nost v prov

architekturyury (SLA pa

va ní doba 24xnost v provstva ní doba 24xnost v provvrstva (Fro

ní doba 24xnost v provní infrastrukní doba 24xnost v prov

í provozu s

arametrů pr

d služeb a j

Kategorie s

Provoz služeProvoz HW

Podpora pov

b:

a SLA para

bjekty a veřx7 vozní době izaci x7 vozní době ce

5x5 vozní době

y jsou požaarametry):

x7 vozní době

x7 vozní době ontend) x7 vozní době ktura x7 vozní době

systému EE

ro stanoven

jejich význa

služby

eb komunika SW infras

vinných sub

ametry

řejnost

99,9%

99,99%

99,9%

adovány ná

99,99%

99,99%

99,9%

99,99%.

ET

ní provozníh

amných par

kační infraststruktury

bjektů (serv

S

ásledující p

ho SLA sys

rametrů:

truktury

vice desk)

M

pecifikace pr

rovozní par

tému EET

Popis

Provoz inf

Provoz HWsystémy E

HW, SW asubjektů

Ministerstvo fi

rojektu Elekt

rametry slu

frastruktury

W a SW inEET

a aplikační

inancí České

ronická evide

Stran

užeb jednot

systému E

nfrastruktur

podpora po

é republiky

ence tržeb

a 84 z 186

tlivých

ET

ry tvořící

ovinných

Číslo služby

1

2

3

Defini

Dostu

Poskya HW

Hlavn

Služb

I. II.

Vysvě

I.

Oznám

II.

Tuto aPředpnedosv přev

Požad

Provozparamparam

Požadpožad

Vzore

Služba

y Katego

Provozinfrastr

Provozinfrastr

Podporsubjekt

ice dostup

pností služb

ytovatel garaa komunika

í kritérium

a je považo

UživateléProvozov

ětlení defin

Uživatele

mení o incid

Provozov

akceptaci pokládá se

stupná služvážné většin

dované par

zovatel apmetry budoumetrem nesm

dované pardované služ

ec dostupn

a se skládá

orie služby

z služeb komruktury

z HW a SW ruktury

ra povinnýctů

nosti

by se rozum

antuje, že vace budou d

dostupno

ována za n

é oznámí tuvatel potvrd

nice nedost

e oznámí tut

dentu je nez

vatel potvrd

provozovatena základ

žba bude uně případů e

rametry sys

plikace dodu jakékoliv vmí být funkč

rametry sysžby byly dos

osti

á ze jednotliv

y

munikační

ch

mí:

všechny poždostupné, t

sti :

nedostupno

to skutečnoí nedostupn

tupnosti:

to skutečno

zbytnou pod

í nedostupn

elem je moždě historie uznána jakoevidentní a

stémů

dá prokazavlastnosti, pčnost vlastn

stémů jsoustupné, tedy

vých Systém

Garantocelko

dostupn

99,9

99,9

99,9

žadované sedy schopn

ou když:

ost Provozonost služby

ost Provozo

dmínkou pro

nost serverů

žno použít incidentů,

o oprávněnnezpochyb

atelně požprocesy, koní aplikace a

u vlastnosty schopné p

mů.

S

ovaná ová ost %

Gco

99

99

9

systémy dlené provozov

ovateli

ovateli

o to, aby by

ů

pro zjedno, že naproná. Je tombnitelná.

žadované onfigurace čale pouze p

i systémů, provozovat

M

pecifikace pr

Garantovancelková dobobnovy [ho

2

2

4

e definovanývat danou s

yl systém po

dušení proostá většinu tak proto

parametry či soubory podmínky pr

které musaplikace.

Ministerstvo fi

rojektu Elekt

ná ba

od]

Prov

Po

Po

Po

ých služeb,službu.

ovažován z

cesu potvrza incidentůo, že nedo

systémů. na Systémro její provo

sí být spln

inancí České

ronická evide

Stran

vozní doba

– Ne 0:00 –

– Ne 0:00 –

– Ne 7:00 –

tedy jedno

za nedostup

zení nedosů ohlášenýostupnost s

Tyto požamech. Požadoz.

něny, aby

é republiky

ence tržeb

a 85 z 186

a služby

– 24:00

– 24:00

– 17:00

otlivý SW

pný.

tupnosti. ých jako služeb je

adované dovaným

všechny

Dostu

kde

Začáte

Konec

Celko

Kde

pnost jedno

dosti =

Tnedost

ek Tnedost

c Tnedost

ová dostup

D

d

n

otlivého sys

= [ 1 -

dob

nedPož

t Dob

v ponás

Inci

defiOpěsplnnasuko

nost služb

DOST = ∑ d

dosti je do

n je po

stému dosti

Tnedost /

ba po kterou

dostupnosti žadovaná p

ba se zač

ožadované ledujícího)

dent se uk

nice dostuětovná dostnění požadotane mimo nčení nejbl

y je:

dosti / n

ostupnost je

očet systém

je :

(počet hodi

u je jednotl

je započtrovozní dob

íná měřit

provozní zahájení pr

ončí v okam

upnosti. Rtupnost sluovaných parozsah pož

ižšího (časo

ednotlivého

mů služby

S

n v měsíci)

ivý Systém

tena z obdba služby je

v okamžiku

době služrovozní dob

mžiku kdy s

ozhodující žby musí b

arametrů syžadované pově předch

o systému s

M

pecifikace pr

] * 100 %

m nedostupn

obí požadoe 0:00 – 24:

u ohlášení.

žby, počítáby služby.

systém či s

je čas ebýt doložiteystémů. V pprovozní doozího) ukon

lužby

Ministerstvo fi

rojektu Elekt

%

ný v hodiná

ované prov 00 ve všec

. Pokud te

á se od n

služba je op

evidovaný elná na zákpřípadě že oby služby, nčení provo

inancí České

ronická evide

Stran

ách za měs

vozní doby chny dny

ento okamž

nejbližšího

pět dostupn

na Servickladě monit

ukončení ipak se za

ozní doby sl

é republiky

ence tržeb

a 86 z 186

íc. Doba

služby.

žik není

(časově

ná podle

ceDesku. toringu a ncidentu počítává užby.

Spec

První orespek

Obsah

Obsah

Výstu

ifikace pr

oblasti realiktive realiza

h analýzy

hem analýz

Detailní publikova

Detailní Projektem

o B

Jedná seslužeb pu

Detailní z

o k

o p

o z

o d

o pp

Zpřesněn

o H

o d

o te

o vP

o „imin

o č

o b

Návrh zá

Návrh daProjektu

py detailní

1. Deta2. Návr

praco3. Deta

rovedení

izace veřejnaci jednotliv

y a výstupů

popis idenané v prostř

popis procm EET:

B2B přístup

e o detailnublikovanýc

způsob real

kategorie in

potřebné da

způsob real

definice rolí

počet uživapředpokladu

ní požadavk

HW aplikačn

diskového p

kap

přiřa

tier

echnický ná

verifikace vProjektu EE

projekce“ mplementonfrastruktur

časové (har

bezpečnost

ákladních pr

alšího rozvoEET.

í analýzy

ilního technrh jednotnéovníků GFŘilního imple

detailní a

né zakázky vých funkcio

ů bude zpře

ntifikace v ředí EET.

cesu realiz

p, GUI přístu

í specifikacch na EET.

izace jedno

formačních

atové zdroje

izace odpov

(skupiny už

atelů (klientu „náběhové

ků Projektu

ní vrstvy,

prostoru:

acita,

azení pro je

resp. další

ávrh rozlože

výkonnosti ET (zaručen

nárůstů vaných inforu.

rmonogram

ní požadav

rovozních p

oje a dalších

nického projé registraceŘ a GŘC. ementačníh

analýzy

je provedeonalit Projek

esnění způs

informačníc

zace jedno

up, WS (we

ci technické

otlivých info

h služeb (ev

e pro realiza

vědi pro jed

živatelů) vč

ů) a transaé“ křivky těc

EET na inf

ednotlivé ko

parametry,

ení zátěže,

infrastruktuá odezva, S

požadavkůormačních s

),

ky a promít

postupů, pri

h informačn

jektu celéhoe, identifika

o plánu Pro

S

ení detailní aktu EET.

obu realiza

ch systém

otlivých dot

b services)

é realizace

ormačních s

vidence, dot

aci informač

dnotlivé pož

četně přiřaze

akcí (dotazchto počtů,

frastrukturu

omponenty

ury ve vztSLA…)

na výkslužeb s výh

tnutí na rea

ncipů a pož

ních služeb

o Projektu Eace a autor

ojektu EET.

M

pecifikace pr

analýzy vzta

ace této zak

ech Zadav

tazů ve va

přístup,

e. Popis pr

služeb –

taz rychlý, d

ční služby,

žadované in

ení k inform

ů) pro každ

a její využi

Projektu EE

tahu k up

kon a kahledem na 4

lizované řeš

žadavků na

realizovate

EET. rizace pro

Ministerstvo fi

rojektu Elekt

ažené k rea

ázky, zejmé

vatele pro

azbě na s

rocesu real

dotaz poma

nformační s

mačním služ

dou inform

tí, zejména

ET,

přesnění in

apacitu u 4 roky s pro

šení.

personální

lných po uk

povinné s

inancí České

ronická evide

Stran

alizaci Proje

éna potom:

informačn

lužby posk

izace infor

alý, atd.),

lužby,

žbám,

ační službu

:

nformačních

definovaojekcí na na

í a smluvní

končení úvo

ubjekty a

é republiky

ence tržeb

a 87 z 186

ektu EET

í služby

kytované

rmačních

u včetně

h služeb

ných a avrženou

zajištění.

odní fáze

interních

Nutná

Zadavanalýz

Dále Z

Techn

EET bKlientspovinnstran Základ

Vazby

Vazbynásled

á součinnos

vatel předpozy poskytne

SPCSS,

garantů o

vlastníků

právních

Zadavatel z

komunika

jednotné

nická specif

bude jedinoské rozhrané subjekty (externích zdních Regis

y a rozhran

y komunikačdujícím sché

st pro reali

okládá, že e součinnos

odborných a

dat odborn

a metodick

ajistí součin

ační infrastr

registrace,

fikace EET

ou bezpečnní bude poa současně

zdrojů) pro strů po potře

í systému

čních a ostématu:

izaci analýz

vybranémust ze strany

agend GFŘ

ných agend

kých odborů

nnost ze str

ruktury,

identifikace

nou vstupněoskytovat sě bude umopotřeby in

ebu ověřov

EET

tatních infor

zy

u Uchazečinásledující

Ř,

GFŘ zejmé

ů MFČR a G

rany SPCSS

e a autoriza

ě výstupní služby, datožňovat i koterních odbání adres re

rmačních s

S

i, který budch organiza

éna systém

GFŘ,

S zejména v

ace pro prac

branou prota a informomunikačníborných aplegistrovaný

ystémů (na

M

pecifikace pr

de realizovačních jedn

mu ADIS,

v oblastech

covníky GF

o komunikamace pro zí kanály prolikací. Napoých provozo

a systém EE

Ministerstvo fi

rojektu Elekt

at tuto zakotek a prac

h:

FŘ a GŘC.

ci v oblasti zaměstnanco získávání ojení systémoven.

ET a okolí)

inancí České

ronická evide

Stran

kázku, pro covníků:

evidence ce GFŘ, veinformací omu EET na

) jsou znázo

é republiky

ence tržeb

a 88 z 186

realizaci

účtenek. eřejnost,

od třetích a systém

orněny v

Pro zasystém

Rozhr

Pro popříjempro evdatovo

Dalšímadres systémspuště

Datovschrá

PřímávýměPOS

Czec

Klienfyzick

Kont

ISZR

Obrázek 16

ajištění požamy státní sp

raní pro evid

otřeby evidem požadavkůvidenci do ou schránku

m rozhranímevidovaný

m s oprávněění systému

vé ánky

á ěna dat s

ch Point

nti – ké osoby

roloři

6: Vazby kom

adovaných právy tak na

denci

ence povinů na evidenprostředí E

u.

m je napojeých provozoěním přístuu do provoz

Rozhra

ISDS

CzechRoz

Portál

rozhrakomunklienty

RozhrkomukontrpracoRoz

Rozhrkomun

Záklareg

(v bud

munikačníc

služeb prosa interní sys

ných subjenci a ukládáEET, bude

ení na systéoven. Z tohupu do záklazu).

aní B2B

h Point zhraní

-

aní pro nikaci s y

raní pro unikací rolních ovníků zhraní

raní pro nikací se adními gistry

doucnu)

h a ostatníc

středí EET jstémy GFŘ

ktů je požaání těchto žá

rozhraní n

ém základnhoto důvoduadních regi

Systé

klientů

S

ch informačn

je zapotřeb(ADIS, spis

adováno naádostí v pro

na Czech P

ích registrůu musí sysistrů (tato fu

m autentifi

ů a ext. sub

platformkontrolu služeb E

ADIS

Aplikační prostředí

M

pecifikace pr

ních systém

bí zajištění rsové služby

apojení na sostředí spisoPoint pro po

ů (ISZR) prostém EET unkcionalita

ikace

bjektů

a pro řízenprocesů aET (ESB)

EET

CIS

Ministerstvo fi

rojektu Elekt

mů na systém

rozhraní a vy).

systém datoové služby.ovinné sub

o potřeby obýt registroa bude real

ní a a

Elektrspisov

inancí České

ronická evide

Stran

m EET a oko

vazeb na jin

ových schrá Druhým ro

bjekty, které

ověřování eová jako alizována v e

ronická vá služba

Certifikačnautorita

é republiky

ence tržeb

a 89 z 186

olí

né

ánek pro ozhraním é nemají

existence gendový etapě po

ní

Rozhr

B2B rzákazřečení

raní pro rea

ozhraní je nickou koní a zajišťují

lizaci sběru

hlavním výntrolu a rozpřístup k je

u účtenek a

ýkonným rozhraní pro ednotlivým ú

jejich kontr

zhraním nakontrolní púdajům o ev

S

rolu a evide

a které jsouracovníky Gvidovaných

M

pecifikace pr

enci

u kladeny eGFŘ je reaúčtenkách

Ministerstvo fi

rojektu Elekt

extrémní náalizováno v.

inancí České

ronická evide

Stran

ároky. Rozhv rámci por

é republiky

ence tržeb

a 90 z 186

hraní pro rtálového

Funk

Funkčjednotfunkčn

Kom

Dodávrozhracustom

Celkovvzájem

Řešen

ční dekom

ční dekompotlivých komních oblastí

ponenty

vka a impleaní, dodánmizace, kon

Identity/A

Portálovék poskyto

o f

o in

o r

o n

Enterpris

Audit Ma

o s

o o

o o

vé řešení kmně integro

ní EET je na

mpozice

ozice vycháponent je z:

Projektu

ementace řeí vhodných

nfigurace, te

Access Man

é řešení, ktovaným služ

rontend AP

ntegrační p

rozhraní

nástroje pro

se Service B

nager, který

statistik přís

ověřování S

ověřování S

klientskéhoovány a mus

apojeno na

Po

Kz

ází ze zajištzřejmý z po

Obráze

EET

ešení (prosh SW komestování) do

nager, který

teré bude zžbám.

PI rozhraní,

platforma pro

o správu por

Bus

ý bude zajiš

stupů,

SLA poskyto

SLA využíva

o rozhraní ssí vytvářet h

stávající ko

Portál

odpora kli

Komunikazaměstnan

tění hlavnícopisů proce

ek 17: Funkč

středí) EET mponent Eo prostředí

ý bude zajišť

zajišťovat in

o EET,

rtálu (redak

šťovat logov

ovaných slu

aných služe

složené z jhomogenní

omponenty

entů

ace nců

S

ch cílů Projeesů. Funkc

ční dekompo

tj. výběr vhEET a impZadavatele

ťovat auten

nteraktivní w

kční systém

vání vešker

užeb,

b třetích str

ednotlivýchřešení.

SPCSS:

Elekt

vým

Do

funkc

ap

M

pecifikace pr

ektu EET. Pionalitu Pro

ozice EET

hodné platfplementace

e, zejména:

ntizaci a aut

webový přís

),

rých přístup

ran (externí

h definovan

tronická

měna dat

plnění

cionality

plikací

Ministerstvo fi

rojektu Elekt

Podrobnějšíojektu EET

formy pro ree EET (pr

torizaci pov

stup klientů

pů pro potře

ích zdrojů).

ných kompo

inancí České

ronická evide

Stran

í popis funktvoří 5 zá

ealizaci klierovedení in

inných subj

ů a dalších

eby:

onent, které

é republiky

ence tržeb

a 91 z 186

kcionality ákladních

entského nstalace,

jektů.

subjektů

é budou

Portá

Portál(funkčuživat

Primápro sb

Mezi z

Další p

Monitorin

Bezpečno

Service d

Call cent

Posílání s

Autorizac

lové řešen

ové řešenčnosti), kterelů.

rně bude sběr účtenek

základní po

Snadná a

Snadná d

Jednoducskupiny a

Stránky b

Internetov

o I

o F

o G

o A

Intranetov

o I

o F

požadované

Možnost

Podpora

Identity/Aaplikační

Řízený (komunitě

Vyhledáv

Monitorov

ng

ost

desk

rum

stavových a

ce a autenti

í

í musí umré pomocí

sloužit pro k.

žadované f

a rychlá imp

definice a z

chá změnaa typy zaříz

budou plně

vé rozhraní

E (od verze

Firefox (od v

Google Chro

Apple Safar

vé rozhraní

E (od verze

Firefox (od v

é funkciona

prezentace

SOA – inte

Access Maní rozhraní a

přístup k ině).

vání informa

vání aktivit.

a transakčn

zace.

možňovat dwebového

komunikaci

funkčnosti p

plementace

měna grafic

a uživatelsení.

kompatibiln

í:

e stávající m

verze stáva

ome (od ve

ri (od verze

í

e 10),

verze 30),

ality:

e informací

egrace s ost

nager - stáexterní kon

nformacím

ací.

.

ních informa

definovanýmo rozhraní

B2C a B2

patří:

e uživatelské

ckého manu

ského vzhle

ní minimáln

mínus 1),

ající mínus 1

erze stávajíc

stávající m

formou por

tatními syst

ávající usentrolní rozhr

prostředni

S

ací do úložiš

m způsobe(WWW) b

B bude sam

ého rozhran

uálu uživate

edu na úro

ě pro prohl

1),

cí mínus 1),

ínus 1).

rtletů podle

témy.

r managemraní.

ictvím rolí

M

pecifikace pr

ště pro potř

em implembudou dost

mostatný p

ní pro nové

elského roz

ovni obsah

ížeče

,

standardů J

ment pro p

nebo člen

Ministerstvo fi

rojektu Elekt

řeby auditu

mentovat ptupné defin

referovaný

interaktivn

zhraní.

hu pro jed

JSR-168 a

přístupy pra

nstvím uži

inancí České

ronická evide

Stran

oskytovanénovaným s

komunikač

í služby.

dnotlivé uži

JSR-286.

acovníků na

vatele ve

é republiky

ence tržeb

a 92 z 186

é služby kupinám

ční kanál

ivatelské

a interní

skupině

Posky

Poskyprimár

Požad

Doplň

Acces

Enter

ZadavUchazarchitea para

ytované slu

ytované služrně určeny

dované stan

HTTP/HT

SOAP.

WSDL.

ující standa

XML, XS

REST.

ss Manager

Uživatele

o L

Uživatele

o L

o p

o k

Uživatele

o I

Systémovzákladě:

o L

o s

prise Servic

vatel pro rezečů, a násektury a bylametry:

standardvčetně žkomplexn

standard

standard

rozšiřiteln

žby WS

žby musí bpro komuni

ndardy:

TTPS.

ardy:

D, UDDI.

musí umož

e webového

Login/Passw

e (konzume

Login/Passw

přístupovéh

klientského

e rozhraní p

nterního za

vých účtů

Login/Passw

systémovéh

ce Bus (ESB

ealizaci Proslednou reala rozpraco

izovaná intžádost/odponí přenosy u

izace XML,

izované kon

nost a modu

být dostupnéikaci B2B (v

žňovat tyto z

o klientskéh

word Přístu

nty) služby

word,

o klíče s om

certifikátu.

pro vzdálený

aměstnanec

komunikujíc

word,

ho certifikátu

B)

ojektu EET alizaci vybrvána rámco

tegrační apověď, jednoudálostí a z

HTTP, SO

nektory a m

ularizace.

é minimálnvýměnu dat

základní typ

o portálu na

pového klíč

poskytovan

mezenou do

ý přístup na

ckého certifi

cích s aplik

u.

resp. tétoraným Uchová archite

plikace, kterosměrné pzpráv,

OAP, WSDL

možnost vytv

S

ě pomocí rt mezi systé

py autentiza

a základě:

če s omezen

né EET na z

obou platno

a základě:

ikátu, čipov

kacemi třetí

veřejné zahazečem, pktura s využ

rá podporujpřenosy zpr

, a JAX-RP

váření dalš

M

pecifikace pr

rozhraní weémy).

ace:

nou dobou

základě:

osti (OTP),

vé karty

ích stran p

akázky požpožaduje, ažitím sběrn

je všechnyráv s gara

PC,

ích konekto

Ministerstvo fi

rojektu Elekt

ebových slu

platnosti (O

ro získáván

žaduje, abyby byly vyice (ESB) a

y hlavní komantovaným

orů,

inancí České

ronická evide

Stran

užeb (WS)

OTP),

ní externích

y byla pro yužity princia těmito vla

munikační sdoručením

é republiky

ence tržeb

a 93 z 186

a budou

h dat na

nabídky ipy SOA

astnostmi

scénáře, m a vice

B2B (d

V rám(účten

Ošetřeumožňplatný

Inform

Audit

Další vstupn

Audit m

dedikovaný

ci řešení Enek).

ení komunikňovat komuým certifikát

mace předan

Manager

komponenně výstupní

ProvozníPodkladyPodkladyPodklady

manager bu

ý pro sběr

EET bude B

kace prostřunikace poem. Komun

né přes B2B

tou je Audbrány. Sou

í statistiky. y k ověřováy k ověřováy pro bezpe

ude napojen

Obráz

účtenek)

B2B hlavní

řednictvím Bouze definonikace nevy

B rozhraní b

dit Manageučasně mus

ní SLA posní SLA využ

ečnostní aud

n na centrá

zek 18: Ente

í rozhraní p

B2B rozhraovaným zpyhovující de

budou předá

er, kterého sí umožňova

kytovanýchžívaných sldit a řešení

ální audit ma

S

erprise Serv

prezentován

ní musí býtpůsobem aefinovaným

ávány přes

úkolem bat analýzu a

h služeb. užeb třetíchpřípadných

anager SPC

M

pecifikace pr

vice Bus

no jako ex

t zabezpeče formátem požadavků

standardní

bude logováa prezentac

h stran. h bezpečno

CSS

Ministerstvo fi

rojektu Elekt

xterní služb

eno pomocXML opa

m bude zah

í definované

ání veškerýci získaných

stních incid

inancí České

ronická evide

Stran

a pro přijím

í TSSL/SSLatřeným příhazována.

é rozhraní E

ých datovýh dat pro:

dentů.

é republiky

ence tržeb

a 94 z 186

mání dat

L a musí íslušným

EET.

ých toků

Certi

Certifitržeb centráintegri

Certifidvouú

Základna pořna klíč

Bloko

Dopad

CA Estávaj

Výkon

CA EEbudouvydáváa RA z

Požad

Přestoprovozprovozcertifikfrontam

fikační au

kační autor(dále jen E

álním systémity a nepopi

kační autorúrovňová arc

dní softwarořízení, provčové části s

vé schéma

CA EET

dy realizac

EET je novícími IS MF

nové požad

ET a RA EEu zapojovatány statisíczpracovat řá

davky na do

o, že vydánzovatele syzu nepřetržkátu nesmími požadav

utorita

rita (dále jeEET). Účelemům EET (iratelnosti) d

rita PKI a jechitektura s

ové kompovoz a upgrasystému, ze

a

Ce

C

e CA EET n

vě budovanFČR. Jeho v

davky

ET musí býtt do systémce certifikátůádově něko

ostupnost a

í certifikátu ystému a zažitě a aby bí překročit vků.

en CA) je bem CA EETdále jen CSdatových vě

ejí řešení mse zajištěním

onenty PKI ade. Zároveejména na b

ertDB / RA

CA EET

SD

Obráz

na stávající

ný systém,vliv na stáva

t dimenzovámu v někoů denně. Jeolik jednotek

a odezvu

ve skutečnamezení nebylo použitjednotky s

budována pT je vydávaS). Tyto certět, odesílan

musí být nam ochrany k

využívají oeň musí být bezpečnost

ComS

SprávaDohled

ek 19: Bloko

IS GFŘ

, který nebající IS MFČ

ány na vydáolika vlnáchelikož požadk až několik

nosti není čaegativní pubto řešení s sekund, jina

S

pro zajištěnat certifikátytifikáty jsou

ných POSy

avržena na klíčových p

open-sourcedbáno, že dat.

SRV / FW

ové schéma

bude využČR bude mi

ávání a sprh, takže lzdavky se buk desítek žá

asově kriticblicity dopovysokou d

ak hrozí za

M

pecifikace pr

ní funkce syy Povinným dále použído EET a n

základě bervků systém

e licence, cpoužité prv

a CA EET

ívat služebinimální, po

rávu jednoteze předpokudou shlukoádostí za se

cké, s ohledoručujeme, dostupnostíahlcení sys

Ministerstvo fi

rojektu Elekt

ystémů Elem subjektůmívány k podnaopak.

ezpečnostnímu.

ož pozitivnvky nebudo

b ani nebuokud vůbec

ek milionů cládat, že vovat v pracoekundu.

dem na udržaby CA EE. Odezva nstému stále

inancí České

ronická evide

Stran

ektronické em (dále jen depisování (

ích požada

ě ovlivňuje ou mít nega

ISDS

CzechP

Web S

ude kooperjaký.

certifikátů. Pve špičkáchovní době, m

žení dobréhET i RA EEna žádost oe se prodlu

é republiky

ence tržeb

a 95 z 186

evidence POS) a

(zajištění

vků jako

náklady ativní vliv

Point

Services

rovat se

POSy se h budou musí CA

ho jména ET byly v o vydání užujícími

Požad

Budem10 celokáln

Využit

CA EEbez nua RA.podpo

Požad

CA EidenticŠkolícgeograsystém

Předpspolečrežimonapoje

Třetí, T

Strukt

Systémvýhradissuing

Pro mcertifikinstanznázo

Navržopodsvývojonadřaz

davky na př

me-li předportifikátů za ími i rozsáh

tí dohledu

ET musí býutnosti lidsk. Dohled m

oru dodavat

davky na ha

ET v uspockých instací, avšak s naficky jinýcmů POS na

okládá se, čné 19“ přísovým zabezením na fun

Testovací /

tura instan

m je navrždně pro ukog CA) je na

maximální flekáty pouze ce generujrněno na ná

ené řešení statnění proové/testovaczenými CA

řenos dat

okládat, že sekundu,

hlými sítěmi

ýt v provozkého zásahmusí mít mele v případ

ardware

ořádání v pncích, nazýnižšími výkoh lokalitáchrůzných pl

že každá Cstrojové skřzpečením. Onkce dohled

Školící inst

cí certifika

žen jako dotvení hieraopak posky

exibilitu jsopro povinn

je certifikátásledujícím

nesmí vyluo jejich vzcí/demonstrnebude fig

jedna žádojedná se oi.

u nepřetržiu. V mimop

možnost infodě mimořád

principu odývaných Hlonovými poh. Testovacatformách.

CA EET buříni. Tato skObsluha a ddového stře

tance CA E

ční autorit

dvouúrovňoarchie, tedy ytovat poža

ou navrženyné subjektyty pouze p

m diagramu.

O

čovat možnznik. Požarační účelyurovat výše

Root CA

Tier I

ost i jeden co přenos 20

tě. Naprostpracovní doormovat os

dné situace

povídajícímlavní a Zál

ožadavky. Iní / Školící CTomu mus

ude řešena kříň bude udohled buddiska.

EET bude už

ty PKI

ová certifikanevydává dovanou sl

y dvě instany EET (přepro interní

Obrázek 20:

nost pro vybdavek na

y nebyly zae uvedená R

S

certifikát ma0 kB/s, což

tá většina oobě však msoby v dův.

m blokovémložní a třetnstalace HlaCA EET buí odpovídat

jako sada umístěna v ou provádě

žívána pro

ační autoripřímo klienužbu vydáv

nce koncovedstavitele s

IT zařízen

Řešení CA E

budování dořešení, ab

kotveny v hRoot CA.

M

pecifikace pr

ají velikost ž je hodno

operací všausí být zajišvěryhodnýc

mu schémattí, funkčně avní a Zálo

ude obsahovt návrh hard

serverů a jtechnologicěny vzdálen

testování so

ta, přičemžntské certifikvání certifiká

vých CA, přsubjektu, p

ní (je-li pot

EET

oplňkové Tiby případnhlavní hiera

Issuing Csubjekty, p

Issuing sy

Tie

Ministerstvo fi

rojektu Elekt

1 kB a sítí ta bez pro

ak bude proštěn dohled

ch rolích, p

tu bude reshodnou in

ožní instancvat navíc i

dwarového

iných zařízckých prost

ně, pomocí

oftware a p

ž kořenovákáty. Účelemátů.

řičemž jednprodejní mísřeba). Pož

ier II CA, poné CA určarchii důvě

CA – povinnprodejní mí

CA – internystémy

er II

inancí České

ronická evide

Stran

projde 10 žblému dosa

obíhat autod nad provopřípadně vy

ealizována nstanci Tes

ce je doporuněkolik tesřešení.

zení, umístětorách s fyzpracovních

ro školení o

á (root) CAm koncové

na z nich psta apod.)

žadované ře

okud bude ečené pro pry, tedy me

né ísta

ní

é republiky

ence tržeb

a 96 z 186

žádostí a ahovaná

omaticky, ozem CA yžadovat

ve dvou stovací / učeno na stovacích

ěných ve zickým a stanic a

obsluhy.

A slouží CA (tzv.

poskytuje a druhá ešení je

existovat případné ezi jejich

Parame

Archite

Počet i

Algoritmelektro

Velikos

Platnos

AktivníCA

Platnosklientsk

Provo

Parame

Dostupověřová

Dostup

Kapacit

Požad

Subsyvlastna CS v

Subsyplní fukterou

SubsyAktuálschrán

etr systému

ektura CA

nstancí

mus pro tvornických podp

st klíče CA

st certifikátu C

í období certif

st vydávanýckých certifiká

ozní parame

etr systému

pnost služeb –ání certifikátů

pnost služeb -

ta

davky na so

ystém CA Eí selfsignedvydávat pod

ystém CertDunkce regisu pokrývá C

ystém Comlně se přednek (ISDS),

Me

Poč

Pokač

bu pisů

Kommegen

Désou

CA Mafika

fikátu DoCAcer

h átů

Docersys

etry

Me

– ů

Mav hnepřov

- ostatní Mav hnepřov

Řákteevivýk

oftware a fu

EET předstd kořenový depisovací

DB / RA EEstrační autoCA EET.

mSRV / FWdpokládá, ž, kontaktní m

etrika

čet vrstev cert

čet jednotličních autorit

mbinace primechanismů, pneruje elektron

lka bitovéhoukromý klíč ce

aximální doba ační autority.

ba, po kterouA podepisovánrtifikáty.

ba, po kterortifikáty určenstémy

etrika

aximální délkodinách, kdposkytuje sluváním platnost

aximální délkodinách, kdposkytuje služváním platnost

dový počet erý je CA sdovat, aniž bkonu.

unkce

tavuje vlastcertifikát a certifikáty p

T je kompority CA EE

W představuže CA EETmísta Czec

tifikačních auto

vých instanv jednotlivýc

mitivních kryptpomocí nichnické podpisy.

o řetězce, ertifikační auto

platnosti cert

u jsou daným ny vystavovan

u jsou platnéé pro subjek

ka časovéhody certifikačnužby souviseti certifikátů.

ka časovéhody certifikačnžby nesouvisti certifikátů.

vystavených schopná vygeby docházelo

tní certifikanásledně n

pro POSy a

onenta podpT. Tato po

uje komuni bude komhPoint a we

S

orit

ncí certifi-h vrstvách

tografických hž systém

který tvoří rity

tifikátu certi-

certifikátem né klientské

é vydávané kty nebo IT

o intervalu ní autorita ející s ově-

o intervalu ní autorita sející s ově-

certifikátů, enerovat a k degradaci

ační autoritua základě iCS.

porující sprádpora se p

ikační a bemunikovat třebové služb

M

pecifikace pr

Hodnota pro kořenovou CA

1

RSA + SHA

4096 bitů

10 let

4 let

N/A

Hodnota pro kořenovou CA

6 hodin

96 hodin

jednotky až d

u. Základnídentifikace

ávu certifikápředpokládá

ezpečnostnřemi kanályby.

Ministerstvo fi

rojektu Elekt

A Hodn

dvě vrstvy

-256

ů

mm

A Hodn

n

esítky

ím určeníma autentiza

átů a CRL. Sá pro stejno

ní rozhraní y: Informačn

inancí České

ronická evide

Stran

nota pro konc

2

RSA + SHA-2

2048 bitů

6 roky

3 let

max. 3 roky sumax. 2 roky sy

nota pro konc

0,5 hodin

2 hodin

miliony

m CA EET ace žádostí

Subsystém ou množinu

k vnějšímní systém d

é republiky

ence tržeb

a 97 z 186

ovou CA

256

ubjekt ystém

ovou CA

je vydat od POS

zároveň u klientů,

u světu. datových

Regist

CA EERA EE

Regist

O regiCS.

Zde jevíce c(pokla

Otázkamnožskterým

Z těchv poli CAR izapoč

Pro po

Vzhleduživatdávko

Prvotn

Bude-pro ge

Bude-certifik

Impor

Pro im

Po přpárový

trační proc

ET je certifiET.

trace povin

istraci a nás

e třeba uvécertifikátů, adny). Takov

a registracství očekáv

m je právnic

Zaslání žprávnický

zaslání ž

zaslání žslužeb.

hto údajů vyCHR jeho cidentita sysčetím vývoje

odporu regis

Registrac

Prohlížen

Editace K

dem k očeelsky přívětvé příkazy,

ní žádost o

li jako kořeenerování k

li jako kořekační politik

rt vlastního

mport vlastn

Manuáln

Automati

řijetí novéhých dat nále

cedury

kační autor

nných subje

sledně o ce

ést, že neplnapříklad pvýto subjek

ce klientů jeaných klien

cká nebo fyz

žádosti o reých osob,

žádosti pros

žádosti pode

ytvoří registcertifikátu. Rstému CA Ee CA EET.

strace KPO

ce KPOS –

ní KPOS – z

KPOS – mo

kávanému tivými nástrimporty-ex

o vlastní ce

enový certifilíčového pá

enový použkou příslušn

o certifikátu

ího certifiká

í import cer

zované přij

o vlastníhoežejících to

ritou pro PO

ektu

ertifikát moh

atí, že jedepro jednotlikt se samos

e úzce spjntů bude jejzická osoba

egistraci pr

střednictvím

epsané kva

trační autorRA EET vydEET a CHR

OS musí být

prvotní zav

zobrazení r

ožnost změn

počtu KPOroji pro spráxporty aj.

rtifikát

ikát CA EEáru, žádosti

it certifikát né CA.

u

átu musí být

rtifikátu

etí certifikát

o certifikátumuto certifi

OSy a CS.

hou žádat P

en POS = jivé provozo

statným cert

ata s probich registra

a, se předpo

rostřednictv

m služeb Cze

alifikovaným

rita CA EETdá RozhodnR identita K

t implement

vedení regis

registrovaný

nit registrač

OS musí býávu velkého

T použit vlaa certifikát

nadřízené

t implemen

tu.

u se veškekátu.

S

Registračn

POS podle p

eden certifovny nebo tifikátem dá

blematikou ace prováděokládá násl

vím datové

echPoint, to

m elektronic

T jedinečný nutí o regist

KPOS. Napl

továny tyto

stračních úd

ých dat;

ční data klie

ýt CE EET,o počtu klien

astní selfsigu.

autority, říd

továny tyto

eré podpiso

M

pecifikace pr

ní procedury

připravovan

fikát. Zejméi jednotliv

ále nazývám

prvotní žáděna automaedujícími zp

schránky (

o zejména p

kým podpis

kód každéhtraci. V rozhnění polí C

postupy:

dajů;

enta.

, resp. její ntů, jako se

gned certifik

dí se postu

postupy:

ové operac

Ministerstvo fi

rojektu Elekt

y CA EET r

ého Zákona

éna větší POvá místa prme Klient PO

dosti o ceratizovaně. Způsoby:

(ISDS), to

pro fyzické o

sem prostře

ho KPOS, khodnutí o reCHR musí b

registrační eskupování,

kát, musí b

up při žádos

e realizují

inancí České

ronická evide

Stran

realizuje su

a o evidenc

OS mohou ro příjem hOS (KPOS)

rtifikát. VzhZtotožnění ž

zejména v

osoby – OS

ednictvím w

který bude egistraci je být upřesně

autorita, v hromadné

být stanoven

sti o tento

s využitím

é republiky

ence tržeb

a 98 z 186

bsystém

ci tržeb a

žádat o hotovosti .

ledem k žadatele,

případě

SVČ.

webových

obsažen uvedena ěno před

ybavena editace,

n postup

certifikát

nových

Správ

CA EEpočtu

Zprac

Po reg

Důležise něk

Vydán

OvěřecertifikTento musí b

Vydán

Pokudžadate

Modif

CA EEcertifik

CA EEpoložknásled

Požad

Certifi

Systém

a KPOS

ET, resp. jeregistrovan

Registrac

Prohlížen

Editace k

Blokován

Odblokov

ování žádo

gistraci KPO

itou otázkoukolik možno

Zaslání žprávnický

Zaslání ž

Zaslání žslužeb.

ní následné

ení identity kátu vydané

podpis mubýt v době z

ní následné

d nebude vnel musí pod

fikace certi

ET neumožkát a původ

ET rovněž ky Certificadného certif

davky na na

káty obsahu

Certificat

Certificat

m CA EET v

ejí registračných KPOS.

ce klienta –

ní klientů

klienta – úp

ní klienta – z

vání klienta

osti o certif

OS je možn

u je ověřeností řešení.

žádosti o reých osob

žádosti pros

žádosti pode

ého certifik

při zpracového témuž Kusí být vytvzpracování

ého certifik

nější podpidstoupit proc

ifikátu

žňuje modifiní uvést v C

neumožňujte Expiratiofikátu k nov

astavení a k

ují položky

te Effective

te Expiration

vyžaduje ná

ční autorita,. Ve správě

– nástroj na

rava registr

zablokován

.

fikát od KPO

o zpracová

í identity ža

egistraci pr

střednictvím

epsané kva

kátu v době

vání žádosKPOS či CAořen pomožádosti a v

kátu po dob

s žádosti oceduru vydá

ikaci certifikCRL.

je prodloužon Date. Prvému klíčové

kontrolu ča

vymezující

Date – datu

n Date – da

ásobnou ko

, musí dispě KPOS mus

zavedení n

račních úda

ní klienta mu

OS, vydání

vat žádosti

adatele a pr

rostřednictv

m služeb Cz

alifikovaným

ě platnosti

sti o následA. Žádost mcí soukrom

vydání násle

bě platnost

o následný ání prvotníh

kátu. Při po

žení platnosrodloužení ému páru.

asu

časové úda

um generov

atum vyprše

ontrolu časo

S

ponovat softsí být zahrn

nového klien

ajů

usí znemož

certifikátu

o certifikát

ravosti žádo

vím datové

echPoint, to

m elektronic

certifikátu

dný certifikámusí být vemého klíče oedného cert

ti certifikát

certifikát úsho certifikát

otřebě změn

sti certifikátplatnosti c

aje označov

vání certifik

ení platnost

ového údaje

M

pecifikace pr

twarovými nuty tyto po

nta

žnit vydání c

u

od ISY.

osti při prvot

schránky (

o zejména p

ckým podpis

át je provetvaru, kdy jodpovídajíctifikátu platn

tu

spěšně ovětu.

ny obsahu

tu a příslušertifikátu je

vané jako:

átu

i certifikátu.

e (více NTP

Ministerstvo fi

rojektu Elekt

nástroji na stupy:

certifikátu p

tní žádosti o

(ISDS), to

pro fyzické

sem prostře

edeno s vyje opatřenacího certifikáný.

ěřen, bude

certifikátu j

šného klíčoe možné po

.

P serverů, d

inancí České

ronická evide

Stran

správu dat

ro klienta

o certifikát.

zejména v

osoby – OS

ednictvím w

užitím před vnějším poátu. Tento

žádost zam

e nutno vyd

ového páru ouze cestou

ohledové ce

é republiky

ence tržeb

a 99 z 186

t většího

Naskýtá

případě

SVČ

webových

dchozího odpisem. certifikát

mítnuta a

dat nový

změnou u vydání

entrum).

Požad

Proce

Procepřípad

Uživat

V syst

dovaná užit

esní specifik

sy probíhajdů užití:

telé z hledi

tému budou

Žadatel omůže obn

tí rozhraní

kace

jící v Intern

Obráze

iska vydává

u tito uživate

o certifikát novit. Žádá

CA

Obrázek 2

ní Certifikač

ek 22: Proce

ání certifiká

elé:

(povinný s o zneplatn

21: Požadov

ční Autoritě

esy probíhaj

átů

ubjekt) - prění certifiká

S

vané použití

ě (ICA) jsou

jící v Interní

rostřednictvátu.

M

pecifikace pr

rozhraní CA

u znázorně

Certifikačn

vím CA získ

Ministerstvo fi

rojektu Elekt

A

ěny na nás

í Autoritě

kává certifi

inancí České

ronická evide

Strana

ledujícím d

kát, násled

é republiky

ence tržeb

a 100 z 186

diagramu

dně si jej

Předp

V průbpředpi

Předp

1

2

3

4

Obsluha AdresářoDistribučzneplatně

pisová zákla

běhu impleisy.

isová zákla

. CertifikavydávanCertifica

o V

o P

o P

o Z

. Certifika3647:

o O

o Id

o Pk

o Bb

o Bb

o P

o D

. Systémozpůsob vyhodno

o Z

o P

o B

o A

. Příručka

o P

o P

o B

o P

o N

CA - přijímáové služby -ní místo - pěných certif

adna

ementace C

adna musí m

ční politikaých certifikte Policy an

Výklad zákla

Přehled pos

Přehled typů

Základní prá

ční provádě

Obecná usta

dentifikace

Provozní poklíčů)

Bezpečnostbezpečnost

Bezpečnostbezpečnost

Profily certif

Další admin

ová bezpečnochrany d

ocení analýz

Základní po

Popis bezpe

Bezpečnost

Aplikovaná

správce –

Pravidla a p

Provozní pra

Bezpečnost

Pravidla a p

Nastavení p

á žádosti o - představujpředstavujefikátů) gene

Certifikační

minimálně tv

a – zásadykátů v souland Certificat

adních pojm

skytovaných

ů poskytova

áva a povin

ěcí směrnic

anovení (pr

a autorizac

ožadavky a

tní mechan)

tní mechan, komunikač

fikátů a CRL

nistrativní po

nostní politiat systémuzy rizik:

opis systému

ečnosti pros

tní cíle

bezpečnost

návod pro p

postupy inst

avidla a pos

tní pravidla

postupy pro

provozních a

zneplatněnjí úložiště vye úložiště aerovaného I

autority (C

vořit:

y uplatňovaadu s „RFCtion Practic

mů

h služeb (vy

aných certif

nnosti

ce – postupy

ráva, povinn

ce (pravidla

a postupy

nismy –

nismy – teční bezpečn

L

ostupy (změ

ika – způsou pro vydá

u

středí (před

tní opatření

používání a

talace

stupy

a postupy

zajištění ko

a bezpečno

S

ní certifikátůydávaných

aktuálního CCA.

CA) budou

ané při vyC 3647 – Ines Framew

ydávání cer

fikátů

y používané

nosti, odpov

registrace,

(vydávání,

netechnické

chnické (gnost)

ěny, schvalo

ob uplatněnávání certif

poklady, hr

í

a správu sys

ontinuity

ostních para

M

pecifikace pr

ů - tuto roli zcertifikátů.

CRL (Certif

u zpracová

ydávání cernternet X.50

work“:

rtifikátů, CR

é při vydává

vědnost)

obnovení k

zneplatňov

é (fyzická,

generování

ování)

í celkové befikátů, popi

rozby, pravi

stému:

ametrů

Ministerstvo fi

rojektu Elekt

zastává adm

ficate revoc

ny nezbytn

rtifikátů a 09 Public K

RL)

ání certifiká

klíče)

vání, audit,

, procedur

a ochrana

ezpečnostns bezpečn

dla)

inancí České

ronická evide

Strana

ministrátor C

cation list -

né dokume

specifikaci Key Infrastr

átu v soulad

archivace

rální a pe

a klíčů, po

ní politiky v ostních op

é republiky

ence tržeb

a 101 z 186

CI.

Seznam

entace a

obsahu ructure –

du s RFC

, správa

ersonální

očítačová

systému, patření a

Požad

Na obzohledklíčový

Auditn

Systém

V rám

V rám

V rám

V rámzejmé

davky na te

brázku níždňuje požadých kompon

ní záznamy

m musí zaz

ci provozu

Události

Události

Události

Události

Jiné význ

ci událostí,

Zaveden

Generová

Zpracová

Vydání c

Export ce

ci událostí,

Zaveden

Správa u

Úspěšné

Neúspěš

Odhlášen

mci jiných výna:

echnologick

že je zobradavky na benent).

Obrázek

y

znamenávat

CA EET jso

spojené s o

spojené s ř

spojené se

spojené s ž

namné udál

spojených

í certifikátu

ání vlastní ž

ání žádosti o

ertifikátu

ertifikátů.

spojených

í uživatele

uživatele (zn

přihlášení

ný pokus o

ní uživatele

ýznamných

ké řešení

azen minimezpečnost

23: minimá

t do auditní

ou zazname

operacemi v

řízením přís

změnami k

životním cyk

osti spojen

s operacem

žádosti o ce

o certifikát k

s řízením p

neplatnění,

uživatele

přihlášení

.

událostí, s

mální poža(oddělení je

lní požadav

ho logu úda

enávány pro

v rámci živo

stupu k syst

konfigurace

klem klienta

é s provoze

mi životního

ertifikát

klienta

přístupu k sy

atd.)

spojených s

S

adavek na ednotlivých

ek na síťovo

aje, vážící s

ovozní udál

otního cyklu

ému CA EE

systémů C

a

em systémů

o cyklu certif

ystému CA

s provozem

M

pecifikace pr

síťovou kzón firewa

ou konfigur

se k bezpeč

losti násled

u certifikátu

ET

CA EE

ů CA EET.

fikátu, jsou

EET, jsou

systému C

Ministerstvo fi

rojektu Elekt

konfiguraci.lly) a dostu

raci CA EET

čnosti provo

ujících typů

zaznamená

zaznamená

CA EET, jso

inancí České

ronická evide

Strana

Tato konupnost (clus

ozu.

ů:

ávány:

ávány:

ou zaznam

é republiky

ence tržeb

a 102 z 186

nfigurace sterování

enávány

Pro všzávaž

Událo

V rámzejmé

Auditn

Integri

Po exmožno

Záloh

Dodav

Replik

Při nágarant

Replik

Za prosdílen

Při ukoobsah

Možn

Z hled

Spuštění

Ukončen

Proveden

Generová

Provozní

šechny udánost událos

sti jsou zaz

Elektroni

Případně

mci událostna:

Změny p

Změny ko

ní záznamy

Závažnos

Datum a

Kategorie

Zdroj – k

Identifika

Identifika

Unikátní

Data – úd

itu auditních

portu auditno prohlížet s

ování, obn

vatel musí v

kace krypto

vrhu koncetovaly sdíle

kace obsah

ovozu musíým diskový

ončení činnhu relevantn

osti konfig

diska možno

í systému C

í / přerušen

ní záloh

ání párovýc

í chyby.

álosti jsou sti.

znamenáván

cky, v datab

ě současně

tí, spojenýc

olitiky CA E

onfigurace

jsou ukládá

st události

čas vzniku

e typu událo

omponenta

ace uživatele

ace role

číslo událos

daje blíže p

h záznamů

ních záznamstandardním

ova, replik

v rámci vývo

ografických

epce správyení stejných

hu databáze

í být replikoým polem.

nosti na aktiních tabulek

gurace

ostí konfigu

CA EET

ní provozu s

ch dat CA E

zaznamená

ny:

bázi nebo lo

v papírové

ch se změ

EET (událos

systémů CA

ány v textov

události

osti (skupin

a generující

e

sti

popisující za

garantuje j

mů do archmi editory.

kace dat

oje systému

h klíčů

y klíčů zvážikryptografi

e

ována datab

ivním systék databáze p

race musí C

systému CA

EET a certifi

ávány iden

ogovacím s

formě (prov

ěnami konf

st vedena v

A EET (udá

vé podobě s

a a typ)

auditní záz

aznamenan

ejich uložen

hivu bude za

u navrhnout

it metody ackých klíčů

báze na ob

mu CA EETpro přenos

CA EET:

S

A EET

ikátů

ntifikace ud

souboru

vozní deník

figurace sy

provozním

álost vedena

s následujíc

znam

ou událost

ní se zabez

achována s

t procesy pr

utomatické ve všech H

ba uzly clus

T daného dna Záložní

M

pecifikace pr

álosti, čas

ky).

ystému CA

deníku)

a v provozn

cí strukturou

(vstupní úd

zpečením př

struktura da

ro:

replikace kHSM pracuj

teru, případ

ne musí býsystém.

Ministerstvo fi

rojektu Elekt

výskytu ud

A EET, jso

ním deníku)

u:

daje, výsled

řístupových

at v textové

kryptograficících ve sp

dně bude c

ýt provedena

inancí České

ronická evide

Strana

dálosti a u

ou zaznam

.

ek operace

h práv.

podobě, da

ckých klíčů, olečném clu

luster praco

a replikace

é republiky

ence tržeb

a 103 z 186

uživatele,

enávány

e apod.).

ata bude

které by usteru.

ovat nad

(záloha)

Požad

Dodav

Dále d

Požad

Dodav

Bezpe

Pro přzákonzákon

být konfig

mít konfig

být vybav

mít možn

mít možn

musí mít

davky na ro

vatel CA EE

strukturu

jejich náp

požadavk

procesy v

dodá odhad

davky na do

vatel CA EE

Analytick

o A

o A

o A

o B

o S

o P

Provozní

o S

o U

Bezpečn

o S

o S

o S

o S

ečnostní sm

řípad, že ba č. 365/20a požadová

Systémovadministrzákona č

gurovatelná

gurovatelná

vena konfig

nost ručně k

nost konfigu

možnost ko

ole a proces

ET navrhne

důvěryhod

plň činnosti,

ky na slučite

vyžadující s

d pracovního

okumentac

ET zhotoví:

kou dokume

Analýza tec

Analýza rizi

Analýza bez

Bezpečnost

Systémová

Projekt tech

í dokumenta

Systémová

Uživatelské

ostní dokum

Směrnice pr

Směrnice pr

Směrnice pr

Směrnice pr

měrnice pro

by byl pova000 Sb., o áno:

vá příručkarátorských č. 365/2000

á pro použit

á uživatelsk

urovatelným

korigovat na

urovat profil

onfigurovat

sy

:

ných rolí pr

,

elnost a ne

součinnost v

o vytížení p

ci

entaci, tj:

hnického ře

k

zpečnostníc

tní projekt

bezpečnos

hnického řeš

aci, tj.

příručka

příručky pr

mentaci, t.j.

ro technicko

ro netechnic

ro reakci na

ro kontinuitu

o jednotlivé

ažován CA informačníc

a popisuje úkonů na Sb., a vyhl

í všech příp

ká oprávněn

m firewallem

astavení sys

vydávanéh

vytváření z

ro obsluhu C

slučitelnost

více rolí

pro jednotliv

ešení CA E

ch požadav

tní politika

šení CA EE

ro jednotlivé

ou bezpečn

ckou bezpe

a incidenty

u činností.

é role.

EET za obch systéme

způsob inssystému. Pášky č. 529

S

pustných kry

ní

m pro vytvá

stémového

ho certifikátu

záznamů o

CA EET,

t rolí,

vé role.

ET

ků

ET

é role

nost

ečnost

becný informch veřejné

stalace, uvPlní zárove9/2006 Sb.

M

pecifikace pr

yptografický

ření bezpeč

času

u

provozu sy

mační systsprávy, je

vedení do peň úlohu Sy

Ministerstvo fi

rojektu Elekt

ých algoritm

čných komu

stému a čin

ém veřejnépro splněn

provozu, pystémové p

inancí České

ronická evide

Strana

mů

unikačních

nnostech už

é správy veí požadavk

ravidelné úpříručky ve

é republiky

ence tržeb

a 104 z 186

kanálů

živatelů.

e smyslu ků tohoto

údržby a e smyslu

Požad

Součájednot

Součá

Veške

Součáhardwprodukcertifik

Uživatelsprovozu příručka. vyhlášky

davky na šk

ástí dodávatlivých částí

ástí přípravy

erá školení b

ástí dodávaware a softwktech, dopokačních pro

ské příručkCA EET prPlní zárovč. 529/200

kolení

aného sysí dodávanéh

y školení bu

budou prov

aných školeware. Pokudoručujeme pogramů.

y pro jednracovníky vveň úlohu 6 Sb.

tému budeho systému

ude vytvoře

vedena v do

ní nejsou kd objednatepřímo konta

notlivé role v příslušnýc

Uživatelské

e příprava u.

ní dokumen

ohodnutých

konkrétní prl uzná za n

aktovat jedn

S

popisují pch rolích. Pré příručky

a proved

ntace pro úč

termínech

roduktová šnutné, aby onotlivé doda

M

pecifikace pr

provádění jro každou rve smyslu

ení školen

častníky jed

před zaháje

školení dodobsluha a uavatele, kteř

Ministerstvo fi

rojektu Elekt

ednotlivýchroli je zprac

u zákona č

ní uživatelů

dnotlivých š

ením ostréh

dávaná jednživatelé bylří nabízejí c

inancí České

ronická evide

Strana

h úkonů v cována samč. 365/2000

ů a admin

školení.

ho provozu.

notlivými doli vyškoleni celou řadu š

é republiky

ence tržeb

a 105 z 186

běžném mostatná 0 Sb., a

nistrátorů

odavateli v těchto

školení a

Poža

Aplika

Předpredundbezpe

Minim

Parame

Virtuali

Operač

CPU

Paměť

Disková

Síťové

HSM

Hardwschopuchovtudíž k

Zálohozaříze

HSM z

Požad

Aplika

1.

2.

3.

4.

Základčástí přesou

davky na

ační server

okládá se dance. Um

ečnostních a

ální konfigu

etr

izace

ční systém

á kapacita

připojení

warový bezpno generov

vávat. Veškeklíče v čiteln

ování/obnovení pro potře

zařízení mu

dovaná infr

ační prostřed

DMZ 1 –

DMZ 2 –

APP a Dpožadova

CA – cert

dní požadavinfrastruktuuvání jedno

hardwar

využití virmístění Certaktivních pr

urace jedno

Dopo

Virtua

systé

archit

Minim

Vyhra

100/1

pečnostní mvat, ve spoleré operacené podobě

va vnitřnícheby zajištěn

usí mít odpo

rastruktura

dí a potřebn

Zóna pro z

Webové ap

DB – realizaané služby,

tifikační aut

vkem na infury v jednototlivých virtu

ové prvky

rtualizovanétifikační autrvků realizov

oho serveru

oručená hodn

alizační prostř

ém unixového t

tektura x86/x8

málně 8 GB na

azená disková

1000 MBit/s

modul je záklupráci s hlae vyžadujícnikdy HSM

h dat HSMní vysoké do

ovídající úro

a pro aplika

ná infrastru

zpracování ú

plikace. We

ace ESB sb interní uživ

torita

frastrukturutlivých zónualizovanýc

y prostře

ého řešení tority bude vaných v rá

:

nota

edky schodné

typu (RHEL, S

86-64, parame

a server

á kapacita , mi

kladním kamavním HSMcí tyto klíčeneopouštěj

M je citlivouostupnosti a

oveň certifik

ační prostře

ktura bude

účtenek a v

ebový uživat

běrnice pro vatelské roz

u EET je maách. Pro v

ch zdrojů me

S

dí

v rámci relogicky od

ámci komun

é s celkovým p

SUSE Linux ES

try dle doporu

nimálně 1000

menem návM modulem probíhají vjí.

u operací aanebo expo

kace.

edí EET

dělena min

vystavování

telský portá

orchestraczhraní, data

aximální virvirtualizovanezi jednotliv

M

pecifikace pr

ealizace sadděleno od nikační infra

pojetím virtualiz

S, Debian Linu

čení pro opera

0 GB v RAID I

vrhu certifika, náhodné ve vnitřním

a musí umoort obsahu z

nimálně do n

í evidenčníh

ál pro potřeb

ci služeb, aabázové pro

rtualizace zdné prostředvými zónam

Ministerstvo fi

rojektu Elekt

amostatnýcostatních

astruktury E

zace EET

ux apod.)

ační systém

konfiguraci

ační autoritysoukromé kvýpočetním

ožnit duplikzašifrované

následujícíc

ho bezpečn

by aplikačn

plikační seostředí

drojů, redundí je předp

mi.

inancí České

ronická evide

Strana

ch serverů systémů sET.

y. Zařízení klíče a bezpm prostředí

kaci dat naho pomocí

ch zón:

ostního kód

ího rozhran

rvery pro je

ndance jednpokládáno

é republiky

ence tržeb

a 106 z 186

a jejich využitím

musí být pečně je HSM, a

a záložní klíčů.

du FIK

ní EET

ednotlivé

notlivých možnost

Schém

Základ

ma základn

dní schéma

ích zón

a zón s rozddělením pož

Obrázek 24

žadované fu

4: Základní s

S

unkcionality

schéma zón

M

pecifikace pr

y je patrné z

systému EE

Ministerstvo fi

rojektu Elekt

z následujíc

ET

inancí České

ronická evide

Strana

cího obrázku

é republiky

ence tržeb

a 107 z 186

u:

Schém

Základ

ma logické

dní schéma

komunikač

a logické ko

Obrázek 25

ční infrastr

munikační i

5: Schéma lo

uktury

infrastruktu

ogické komu

S

ry je uvede

unikační inf

M

pecifikace pr

eno na násle

frastruktury

Ministerstvo fi

rojektu Elekt

edujícím ob

systému EE

inancí České

ronická evide

Strana

brázku:

ET

é republiky

ence tržeb

a 108 z 186

Komu

Požad

XML a

Pro obpožadúčtenkvystavpožaduloženpopisu

unikační inf

Propustn

Páteřní s(optika, m

Zdvojená

Použítí Uz důvodu

Použití IPoperační

SSL term

Pro přístu

SIEM – bezpečno

Out of ba

davek na po

DDOS ocaplikace.DDOS ocindikace

Firewall musí míreporting

Switchin

Switchinbezpečnovytížení/z

IPS/IDS jejich slab

LoadBalrozkládá

WAF – cnereguléjazyka, mwebovýc

SIEM – kk odhalen

appliance ‐

blast řešendována takoky ve formávení bezpedavky spojení účtenky su požadova

frastruktura

nost prvků 4

switche s pmetalika)

á architektu

UTM - routu garantová

PS/IDS – nch systémů

minace na L

up na webo

analýza nosti

and manage

oužití dedik

chrana - je Toho lze chrany a indvytvoří prav

& routingít alespoň em (vhodné

ng (VLAN se

ng pro OOost a nazatížení/zah

(60000 conbin

ancing – Uzátěž

chrání weborních komu

může ukončh aplikačníc

korelační anní útoků a z

B2B, webo

ní B2B komové řešení

átu XML cerečnostního ené se zabes FIK do daných proce

a

4 Gbps

propustností

ra

tovací funkcní propustn

na základě ů a midlewa

oadbalance

ové rozhran

nebezpečné

ement všec

kovaných z

e specifickádosáhnout

dikovat včavidlo a škod

(ASIC na 100 virtuá

é realizovat

eparace)

OB (manageavíc umožhlcení v pro

nnections /s

Ukončení S

ové aplikačunikačních jačovat SSL ch serverec

nalýza logůzneužití.

ové a aplik

munikace s í, která burtifikátem, kkódu (FIK

ezpečením atabáze spoesů.

í 10 Gbps

ce, Firewalnosti zařízen

požadavkůare před sof

erech (LB),

í použít WA

ého chová

ch prvků z b

zařízení pro

, protože mt jedině takas pakety, kdlivé SSL pa

akceleraci)álních nezát separátním

ement prvkňuje spra

ovozních ka

s) – chrání

SSL (7000 c

ční servery ader přes ksizing odpo

ch.

ů prováděná

ační server

v rámci komde sjednoc

kontrola certK) a jeho

vystavovánolečně s po

S

na portech

l, ukončeníní

zákona o fistikovaným

AF – ve spo

ní/pokusů

bezpečnostn

o následujíc

musí rozeznak, že IPS nkteré jsou vakety odfiltr

) jsou to hlaávislých firmi zařízením

ků mimo prvovat jednnálech, sta

operační sy

connections

před zneužkteré lze vyčovídá IPS/I

á za účelem

ry

munikace pcovat potřetifikátu ve vodeslaní v

ní FIK odpoodepsaným

M

pecifikace pr

h s možnos

í VPN – žá

kybernetickmi útoky.

olupráci s LB

o průnik

ních důvodů

í funkce

at SSL floanebo WAF adné a svěruje.

avní dvě furewallů s cmi)

rovozní komnotlivé prvčí porty 100

ystémy a m

s a ASIC ak

žítím slabinčítat data), DS, loadba

m odhalení

pokladních ebnou funkvztahu k účtv rámci komovídající ce

XML. Deta

Ministerstvo fi

rojektu Elekt

stí použití 1

ádné další f

ké bezpečn

B

– viz záko

ů (OOB).

ad od regulédokáže pr

ědčí o SSL

unkce použcentrálním

munikační vky bez 0/1000 Gbp

midleware př

kcelerací pr

n v aplikacídatamining

alancerům a

nebezpečn

systémů skcionalitu stence, kontrmpaktního ertifikacím pailní popis p

inancí České

ronická evide

Strana

1/10 Gbps

funkce nelz

nosti a pro

on o kybe

érního SSL racovat jakútoku. DDO

ívané z UTmanageme

kanály – gohledu na

ps

řed útoky/z

ro ukončen

ích (např. vgem, zneužia očekávan

ých jevů ve

prostředímspojenou srola správnořešení a

pro HSM zaprocesu je

é republiky

ence tržeb

a 109 z 186

rozhraní

ze použít

ochranu

ernetické

provozu o sonda

OS podle

TM, UTM entem a

garantuje a jejich

neužitím

í SSL) –

vytváření itím SQL né zátěži

edoucích

m EET je příjmem

osti XML, splňovat

ařízení a součástí

ZařízeŘešen

Pro zzpracosystémXML akumulnutné nutnýPodmzařízeDataPpodpoHSM mzejmé

●

●

●

ení musí splní musí splň

abezpečenovávat masmů zasílajíca certifikátůovat několizajištění ta

ých pro pínkou oddě

ení tzv. SOAPower SOAořeno HW modulu. Pona integrac

Při implemWebServicv demilitari

○ Auteiden

○ Validobsa

○ Digi

○ Šifrobyla

○ Ochčast

○ Term

○ Tran

○ Aud

V rámci imzóně k řeše

○ Auteiden

○ ValidXML

○ Akcepodp

○ Och

○ Load

Implement

○ Síla aplik

lňovat minimňovat požad

nou oblastsivní datovécích XML so je nutné zak funkčníchakových po

požadovanoělení zmíněA applianceA appliancakcelerátor

ožadované ucí systémů s

mentaci B2Bces a proizované zón

entizace & tit od propr

dace zprávah (přenáše

tální podp

ování a deuchráněna

hrana před to vystavuj

minace HTT

nsformace f

it zpráv

mplementaceení:

entizace & tit od propr

dace zprávL schématu

elerace XSpisu.

rana před r

dbalancing

ace portálo

HW akcekačního ser

málně bezpdavky vysok

t zpracováné toky generoubory podařízení, kteh požadavkodmínek, aou funkcioných genere, je vysokce koncentrem a integužití v prosts externími

B, B2G a Botokolem ně (DMZ)

Autorizacietárních ře

v – např. zená data) m

is a validac

šifrování oa citlivá data

XML útokyjí služby sy

TPs protoko

formátu dat

e portálové

Autorizacietárních ře

v – např. z.

LT transfor

různými úto

gu požadav

ových a repo

elerátoru prrveru a sníž

pečnostní ceké dostupno

ní XML darované vysoepsané přís

eré maximáů oblasti prby byla zaonalitu v rrických úko

ký výkon přtruje požadgrovanými tředí EET jeentitami (B

B2C řešení SOAP, Da

ce požadavkešení jako je

zpráva musmusí být vali

ce digitáln

obsahu zpráa před zneu

y – při tvorystémů, kte

olu

pro komun

ho řešení E

ce požadavkešení jako je

zpráva mus

rmací a sn

ky (XML th

vků na back

ortovacích ř

ro XSLT vžit latence z

S

ertifikaci Coosti a výkon

at v rámci okým počteslušným celně akcelerropustnosti

ajištěna ochrámci vys

onů s aplikaři zpracovádovanou fubezpečnos

e typické pří2B/B2G):

založenýchataPower

ků a případe LTPA až p

sí být validdní podle X

ího podpisu

ávy za pomužitím

rbě B2B řešeré nikdy n

nikaci s exte

EET, je žád

ků a případe LTPA až p

sí obsahova

ížení laten

reats) – na

kend systém

řešení posta

v zařízení Dpracování p

M

pecifikace pr

ommon Critennostní poža

evidence zem povinnýcertifikátem. ruje prováděa bezpečn

hrana vložestavování ačními daty ání XML daunkcionalitustními vlastípadem, kdy

h na výměnplní význ

dné vytvářepo standard

ní XML, náXML schéma

u pro zajiště

moci integro

šení a obenebyly k po

erní entitou

oucí využít

dné vytvářepo standard

at data val

cí spojenýc

apř. SQL inj

my.

avených na

DataPower požadavků.

Ministerstvo fi

rojektu Elekt

eria (EAL4)adavky defi

zaslaných úch subjektůPro náročněné operacosti. Pro ob

ených bezpbezpečnosz aplikačn

at a vysoká tak, že ztnostmi včey zařízení D

ně XML zprnamné bez

ení SSO tokd SAML

ásledně valatu

ění nepopir

ovaného HS

cně je nutnodobnému

na interní fo

DataPowe

ení SSO tokd SAML.

idní XML p

ch se zprac

ection.

a XSLT

může pom

inancí České

ronická evide

Strana

) FIPS 140-inované pro

účtenek je a jejich poou úlohu ov

ce, které je blast bezpepečnostnícstního kódího serveru

á míra zabezpracování etně integroDataPower

ráv např. szpečnostní

kenů pro p

lidní SOAP

ratelnosti z

SM modulu

no uvažovaúčelu urče

ormát a opa

r v demilita

kenů pro p

podle defino

cováním di

moci ušetři

é republiky

ence tržeb

a 110 z 186

-2 level 3. o EET.

potřeba okladních věřování schopno

ečnosti je h kódů, du FIK. u na HW ezpečení.

XML je ovaného zajišťuje

využitím funkce

ropagaci

P, a také

zprávy

tak, aby

at, že se eny!

ačně

rizované

ropagaci

ovaného

gitálního

it zdroje

IBM Wzejmé

●

●

Základ

IBM Wpožadstraněsystém

Na ob

Front protokKomuprovádMultisbackemožnona bapodep

1) Dainta)b)c) d)e)f) g)h)

2) Da3) Da

a)

4) Ba5) Da

da

WebSphere na jako:

Enterprise

Bezpečnos

dni funkcio

WebSphere davků. Klieně zařízení mu.

rázku je vid

Side Handkolu, který nikaci s baděna v tzv.step Enginnd system o provést packend sypsat.

ataPower: tegrační log) autentiza) validace

kryptogra) obohacen) Service L

content b) transform) záznam pataPower: ataPower: ) Předávaj

nesplňujíackend: ZpataPower: at/zprávy.

DataPowe

Service Bu

stní zařízen

onalita Dat

DataPowent (service re

DataPower

dět, že zaříz

dler (FSH) klient pou

ackend syst Multistep

ne tak můžtak i odpovři zpracovástem před

Multistep gikou: ace a autorizXML (metri

afie (digitálnní zprávy naLevel Manabased routinmace obsahpožadavku Multistep EBack Side í se jen aící nastavenpracování p

Back Sid

er je SOA a

us (ESB) ne

ní v demilita

aPower

er je možnoequester) kr komuniku

Princ

zení DataPo

zajišťuje kžívá – naptémem zajiEngine, k

že zpracovavěď vrácen

ání požadavdán. Podob

Engine z

zace ky XML, va

ní podpis a a základě vgement (SLng u zprávy pro účely aEngine přeHandler (Ba pouze vanou politiku

požadavku, de Handler

appliance, k

ebo jako jeh

rizované zó

o si předstakomunikuje uje s posky

cip práce za

ower pracuj

komunikacipř. http/httpšťuje Back

který leží mat jak přích

nou backenvku autentizbně při zp

pracuje zpr

alidace schéšifrování na

volání jiné wLM)

auditu edá výsledeSH) přepošalidní požaslužby se nvytvoření or (BSH) A

S

kterou je m

ho doplněk

óně k ochra

avit jako prna jedné stytovatelem

ařízení Dat

je na princip

s klientemps, ftp neb

k Side Handezi Front Shozí požadd systémem

zaci a autorpracování

rávu požad

ématu, extea úrovni zprwebové služ

k zpracovášle zpracovaadavky splna backenddpovědi a j

Akceptování

M

pecifikace pr

možno použ

aně interních

rostředníkatraně se zař

služby (s

taPower

pu Proxy.

m. DataPowbo MQ, Wdler. Vlastn

Side Handledavek klienm před oderizaci a rozhodpovědi

davku nako

erní referencrávy) žby (enrichm

ní na Backanou zprávňující nast

d nepropoušejí zaslání zí odpovědi

Ministerstvo fi

rojektu Elekt

žít v závislo

h systémů

(intermediřízením Datervice prov

wer se takWebSphere ní logika zperem a Bacta před jehesláním kliehodnout, zdje možno

onfigurovan

ce…)

ment)

Side Handu na backetavená pravštějí (firewazpět na Baci backend

inancí České

ronická evide

Strana

osti na poža

iary) ve zptaPower a nvider) na

k může přiJMS, Tibc

pracování zck Side Hanho propuštěentovi. Je nda bude po

zprávu d

ou bezpeč

ler (BSH).nd systémvidla – polling). ck Side Han

systému

é republiky

ence tržeb

a 111 z 186

adavcích

racování na druhé backend

způsobit co EMS. zprávy je ndlerem. ěním na například ožadavek digitálně

nostní a

ožadavky

ndler a přijetí

6) Da7) Da

(nk da)

b)c) d)e)

8) DaHa

9) Dapr

10) Kl

Variacúčten

Podpo

1.

2.

ataPower: ataPower: apř. digitádispozici M) validace

i) valida) obohacen

transform) kryptogra) audit

i) Často(přípa

ataPower: andler. ataPower: rotokolu (nalient: Zprac

ce vlastnoek.

orované pr

Transpor HTTP FTP, SFTP WebS TIBC WebS IBM I NFS DB2® IPv4, Link A Virtua 10G 1G E Dyna SSH

Podporov

o So S

Enforcem

OAut SAM XACM Kerbe RAD LDAP Lightw Micro

Back Side Multistep

lní podpis,utlistep EngXML (metriace odpovění zprávy na

mace obsahafie (digitáln

o se DataPadně komuMultistep

Front Side apř. SOAP mcuje data od

ostí DataPo

rotokoly a s

rt a konektivP, HTTPS, W FTPS P Sphere MQ

CO EMS (IntSphere JavIMS™ Conn

®, Microsoft, IPv6 Aggregational LAN (VLAEthernet IE

Ethernet IEEamic Host C

File Transf

vané protok

SSH-2 protoSFTP verze

ment bezpeč

th 2.0 L 1.0, 1.1 aML 2.0 eros, SPNEIUS P versions 2weight Thir

osoft Active

Handler (BEngine z

, šifrování gine i data (ky XML, vaědí patří k da základě vu

ní podpis a

Power využívnikačních m Engine p

Handler (Fmessage podpovědi od

oweru je v

standardy

vita WebSocket

Q and WebStegration an

va™ Messanect, IMS C

ft SQL Serv

n Control PAN) IEEE 8

EEE 802.3-2EE 802.3ab Configuratiofer Protocol

koly jsou ná

ocol definove 3 definova

čnostní poli

and 2.0, SA

EGO

2 and 3 rd-Party Aut Directory

SH) Předánpracuje zpnebo tran

(zprávu) poalidace schédůležité besvolání jiné w

šifrování na

vá k auditovmetadat jakopředá výsle

FSH) předá omocí protozařízení Da

využita př

t Proxy

Sphere MQ nd B2B appge Service

Callout

er, Oracle,

Protocol (LA802.1q 2008

n Protocol ((SFTP) Su

ásledující:

vaný IETF Raný podle dr

itiky

ML Token P

thentication

S

ní zprávy odrávu odpov

nsformace ožadavku. ématu, extet practice v

webové služ

a úrovni zpr

vání vybrano je identitaedek zprac

výslednou okolu HTTPataPower

i návrhu B

File Transfepliances)

(JMS)

Sybase, an

ACP) IEEE 8

(DHCP) upport

RFC 4251 raft-ietf-sec

Profile, SAM

n (LTPA)

M

pecifikace pr

dpovědi na vědi nakonobsahu).

erní referenc bezpečnos

žby (enrichm

rávy)

ných dat ze a klienta) cování zprá

zprávu odpP).

B2B rozhr

er Edition (M

nd IMS data

802.1ax, 80

csh-filexfer-0

ML queries

Ministerstvo fi

rojektu Elekt

Multistep nfigurovanouU synchro

ce…) sti webovýcment)

zprávy pož

ávy odpově

povědi pom

raní systém

MQFTE)

abase conne

02.3ad

02.txt Intern

inancí České

ronická evide

Strana

Engine. u aplikační

onních ope

ch služeb

žadavku a o

ědi na Fro

mocí komun

mu EET p

ectivity

net-Draft

é republiky

ence tržeb

a 112 z 186

í logikou rací má

odpovědi

ont Side

ikačního

pro sběr

3.

4.

5.

6.

FedeSecu

FIPS SAF Intern W3C W3C S/MIM WS-M WS-S WS-I WS-S WS-S

Webové

WS-I WS-I WS-P WS-P WS-P WS-T WS-A WS-E WS-E WS-N Web WS-M WS-I SOA SOA Direc Multi XML- Mess Unive

subsc WebS

Transpor

SSL v SSL v TLS v

Public ke

RSA, PKCS XKM

Managem

Simp SYSL

eral Informaurity Module 140-2 Leveand IBM RAnet Content

C XML EncryC XML SignaME encryptMediationPoSecurity 1.0 Basic SecuSecurityPolSecureConv

služby

Basic Prof Simple SOPolicy FramPolicy AttacPolicy 1.2, 1Trust 1.3 Addressing EnumeratioEventing Notification Services D

Managemen AttachmenP AttachmeP with Attacct Internet Mpurpose Int-binary Optsage Transmersal Descrcription Sphere Ser

rt Layer Sec

version 2 (dversion 3 versions 1.0

ey infrastruc

, 3DES, DES#1, PKCSS for integr

ment

ple Network LOG

tion Procese) el 1 (with buACF® integt Adaptationyption ature tion and digolicy, versio0, 1.1 urity Profileicy versation 1

file 1.0, 1.1 OAP Basic Pmework chments: Me1.5

n

Distributed Mnt nts Profile ent Feature chments (S

Message Enternet Mail Eimized Pacmission Opription, Disc

rvice Regist

curity (SSL

deprecated)

0, 1.1, and

cture (PKI)

ES, AES, SHS#5, PKCS#ration with T

Manageme

ssing Stand

uilt-in cryptogration with n Protocol (

gital signatuons 1.6, 1.7

e 1.0, 1.1

.3

Profile

essage Con

Managemen

1.2 wA)

ncapsulationExtensions kaging (XOtimization M

covery, and

try and Rep

and TLS)

)

1.2 (hardwa

HA, X.509, #7, PKCS#8Tivoli® Secu

ent Protoco

S

ard (FIPS)

ographic soz/OS® ICAP)

re 7, 1.8, and 1

ntent Filters

nt (WSDM)

n (DIME) (MIME)

OP) Mechanism Integration

pository (WS

are acceler

CRLs, OCS8, PKCS#10urity Policy

ol (SNMP)

M

pecifikace pr

140-2 Leve

oftware mod

1.9

s 1.3 (IBM s

(MTOM) (UDDI vers

SRR)

rated on phy

SP 0, PKCS#12Manager

Ministerstvo fi

rojektu Elekt

el 3 (with op

dule)

standard)

sions 2 and

ysical applia

2

inancí České

ronická evide

Strana

ptional Hard

d 3), UDDI v

ances)

é republiky

ence tržeb

a 113 z 186

dware

version 3

Realizzajištěnapoje

Navrž

Datab

Databumožňmusí uuloženúložišt

Požad

WebovaplikaserverDatabserverVirtuaá pla(CPS)Minimvirtual

Minimprostorozšířepožadsystém

SAN s

V rám

Zapojedatovýna dat

Kabel

Požad

Secu Intell

zace webověním požaden do SAN/

ené řešení

bázové serv

ázové servňujícího „tieumožňovat ných dat. Dtě.

davky na m

vé a ční ry

VV

ázové ry

VV

lizovanatforma )

V

ální konfigizačních ře

ální kapacorů přiřazenení celkov

dovaná minimy. Raw ka

witching

ci dodávky

ení SAN swých sálů datové úložišt

áž

davky na ka

ure Shell (SSigent Platfo

vých a apliavku vysok/NAS via FC

musí umož

very a úlož

very musí erování“ jedukládání ve

Databázové

inimální ko

Varianta 1 Varianta 2

Varianta 1 Varianta 2 Varianta 3

gurace aplikšení.

cita Storageí pro jednoté kapacityimální kapapacita je zá

je požadov

witchů budatového ceně.

abeláž musí

SH) orm Manage

kačních seké dostupnoC za pomoc

žňovat horiz

iště

splňovat notlivých delkého objenebo stora

onfiguraci

Platforma

x86 RISC

x86 RISC X86

kačních a

e je požadtlivé virtualny na deseacita 2 TB návislá na ko

váno dodán

e zajišťovantra SPCSS

í být definov

ement Interf

erverů je doosti. Žádný cí běžně po

zontální šká

požadavkyiskových pr

emu dat jak age funkcio

Minimálnpočet jader fyzickéhoserveru 16 20

72 24

-

databázov

ována na ní stroje a veti násobekna SSD. Poonkrétním ře

í 4x SAN sw

at SAN FC S. To Znam

vány v prvn

S

face (IPMI)

oporučeno server nebuužívaných p

álovatelnost

y vysoké rostor v autco do počtunalita musí

ní

o

Minimápaměť fyzickéserveru

64 GB256GB

1TB -

vých server

4-leté obdvirtualizační k. Pro po

ožadované kešení diskov

witch 48 po

redundantmená, že ka

í fázi realiz

M

pecifikace pr

řešit na virude mít lokáprotokolů.

t.

dostupnosttomatickém u ukládanýcí umožnit o

ální

ého u

Minimcelkopočevirtuáprost80

B 60

48 270

rů je počít

dobí provozplatformu střeby zajiškapacity jsových systém

ort 8/16Gb.

ní infrastruaždý sever b

ace projetu

Ministerstvo fi

rojektu Elekt

rtualizovanéální diskový

ti včetně režimu. Da

ch záznamůonline replik

mální ový et jader álního tředí

Mvepvip37

2T5

tána bez v

zu systémus kapacitouštění vysokou netto kapmů.

kturu a to bude mít vž

.

inancí České

ronická evide

Strana

é platforměý systém a

diskového atabázové pů tak co do

kaci dat do

Minimální elikost aměti irtuálního rostředí 20 GB 68 GB

TB 52GB

výkonových

u včetně d 144 TB s mké propustpacity dostu

v každém ždy dvě FC

é republiky

ence tržeb

a 114 z 186

ě x86 se musí být

úložiště prostředí velikosti druhého

Exadata IBM MS

h nároků

iskových možností tnosti je upné pro

ze dvou C spojení

Varian

Variankompaaplikaaplikakonfig

nta 1 aplika

nta 1 je poaktní databáční oblast čním virtuáurovat potře

ační vrstvy

Obráz

ostavena naázové prosje plně v

lním serverebná datab

a Varianta

zek 26: Sché

a platformětředí. Aplika

virtualizovánrům. Datab

bázová pros

a 1 databáz

éma aplikačn

x86 a na ační a datana umožňuázové pros

středí dle ak

S

zové vrstvy

ní a databázo

konsolidovabázová obluje dynamistředí ExaDaktuálních po

M

pecifikace pr

y

ové vrstvy Va

vaném prodlast je řešeicky alokovata s datab

ožadavků ap

Ministerstvo fi

rojektu Elekt

arianty 1

duktu ExaDna jako samvat potřebnbází Oracle plikace.

inancí České

ronická evide

Strana

Data, který mostatné cený výkon umožňuje

é republiky

ence tržeb

a 115 z 186

realizuje elky, kde určeným pracovat

Vizual

komb

Varianpotřebvýkon platfor

Hlavnpožad

Varian

1.

2. 3. 4.

5.

6.

7. 8. 9.

lizace mož

inace

nta 2 řeší bný výpočet

do příslušrmě databá

í částí řešedované prop

nta 3 ‐ Virt

KonvergpožadavkV současŘešení vPodpora integraci Řešení jeSW kompŘízené atotožné HprostředkDoporučoŘešení vCPS nab

žného řeše

Obrá

realizaci natní výkon d

šných částí zových serv

ní pro B2B pustnosti pro

ualizovaná

govaný sysků projektu sné době sevychází ze z

je zajištěnaCPS do pro

e postavenoponent řeše

aktualizace: HW konfiguky ovaný život

využívá techbízí služby:

ení pro Va

zek 27:Sché

a procesordo jednotné

systému dverů Inform

rozhraní jsoo evidenci ú

Platforma

stém – úplnEET

e jedná o řezkušeností pa prostředniostředí zákao na normaení SW opravyraci v labor

ní cyklus jehnologii MicIaaS, PaaS

ariantu 2 a

éma aplikačn

ové platforého virtualizdle aktuální

mix nebo DB

ou XML akcúčtenek a v

a (CPS)

é HW&SW

ešení Microspři návrhu, ictvím služeazníka zajišlizovaném H

y a aktualizaatořích MS

e v závislostcrosoft. S a DBaaS

S

aplikační v

í a databázo

rmě RISC začního proích požada

B2.

celerátory svystavování

řešení dod

soft a DELLrealizaci a p

eb Premier šťují MicrosHW Dell s g

ace všech ka následně

ti na způsob

M

pecifikace pr

vrstvy a Va

ové vrstvy Va

a produkteostředí a umvků. Datab

s integrovaní bezpečnos

dávané na k

L, připravujeprovozu daSupport, př

soft Servicesgarantovano

komponent ě jsou uvoln

bu nasazen

Ministerstvo fi

rojektu Elekt

arianty 2 d

arianty 2

ech IBM. Vmožňuje dybázové pros

nými modulystního kódu

klíč, škálova

e se v2: MStových centřípadné požs ou kompatib

jsou nejprvněny pro na

ní odhadová

inancí České

ronická evide

Strana

databázové

Varianta konynamicky alstředí je ře

y HSM pro u FIK.

atelné dle

S a HP ter žadavky na

bilitou všec

ve testoványsazení na

án na 3 - 5le

é republiky

ence tržeb

a 116 z 186

é vrstvy

nsoliduje okovaný šeno na

zajištění

h HW a

y na

et

CPS S

Šk

ŘešenStamp

Škálov

Záloh

Pro pozdrojoSystémRTO param

Pro vš4h).

Stamp:

kálovatelno

ní je flexibilnp znamená

vatelnost St

V rámci Sdiskové ú

ování

otřeby provové systémm a zvolenýa RPO d

metry pro mo

šechny HW

ost (stručně

ní dle výkonrovněž jedn

tamp:

Stamp je moúložiště.

ozních záloy, které byý způsob záefinovanýmožnost obno

a SW pros

ě)

nových požnu manage

ožné zajisti

oh je požady mohli míálohování m

m pro jednovitelnosti d

tředky je po

žadavků záment domé

t efektivní š

ováno zajišít dopad namusí splňovnotlivé částdat po celou

ožadována

S

kazníka. CPénu provozo

škálování a

štění zálohoa celkové

vat požadavti informaču dobu živo

tříletá main

M

pecifikace pr

PS je dodáované CPS

rozšiřitelno

ování na mézpomalení

vky na recovčního systétního cyklů

ntenance (H

Ministerstvo fi

rojektu Elekt

váno v jedninstance.

ost o sdílený

édia s minimodezvy pr

very time plému. Zaříze

použitých z

HWMA 3y 24

inancí České

ronická evide

Strana

notkách, tzv

ý výpočetní

malizací dorimárního slynoucí z paení musí zálohovacíc

4x7 Respon

é republiky

ence tržeb

a 117 z 186

v. Stamp

í výkon,

opadů na systému. arametru splňovat

ch médií.

nse time

Před

V rámx86 a sále.

Varian

OracleEnterp

Paritio

Real ACluster

Multite

Tuning

Diagno

ExadatServer

WebLobus

storage

Exadatrack

X5‐2 se

DataPoApplia

x3550

x3550

CA s HS

Switch

Diskov

TS3500

TSM

Implem

DDOS

UTM

Switch

Switch

IPS/IDS

Loadba

WAF

SIEM

Implem

EET

Tomca

TSM

bezpec

běžný roz

ci Variantyřešení Exa

ta 1

Database prise Edition

oning

pplication rs

enant

g Pack

ostics Pack

ta Storage Software

ogic + service

e pro replika

ta 5‐2 Quarte

erver

ower Gatewnce

16 way 64 G

16 way 64 G

SM

h 48 port

ve pole

0

mentace

h

h OOB

S

alancing

mentace

at

cnost

zpočet sy

y 1 jsou pouaData. Rep

poče

e

aci

er

way

GB

GB

200 MD

ystému EE

užity produkplika (online

et SW/HW

1 SW

1 SW

1 SW

1 SW

1 SW

1 SW

1 SW

1 SW

1 HW

1 HW

1 HW

4 HW

4 HW

4 HW

3 HW

2 HW

2 HW

1 HW

1 SW

1

2 Networ

2 Networ

2 Networ

2 Networ

2 Networ

2 Networ

4 Networ

1 Networ

SW

SW

ET a infra

kty Oracle ae) dat je pro

W cena

218 8

23 5

5 7

11 4

8 6

2 4

3 7

4 9

21 2

2 0

7 6

1

16 4

1 0

1 0

2 4

1 1

2 3

4 7

1 7

20 0

rk 4 0

rk 6 0

rk 2 0

rk 2 0

rk 3 0

rk 4 0

rk 2 0

rk 2 0

2 5

32 0

1 7

15 0

S

struktury

a to jak HW ovedena na

50 615,96 Kč

573 523,85 K

707 274,19 K

414 548,39 K

684 982,47 K

481 423,56 K

722 135,34 K

962 847,13 K

216 399,20 K

000 000,00 K

649 056,80 K

115 894,80 K

495 498,67 K

096 024,20 K

096 024,20 K

426 891,78 K

146 398,16 K

312 177,42 K

730 187,80 K

759 664,00 K

000 000,00 K

000 000,00 K

000 000,00 K

000 000,00 K

000 000,00 K

000 000,00 K

000 000,00 K

000 000,00 K

000 000,00 K

500 000,00 K

000 000,00 K

‐ K

759 664,00 K

000 000,00 K

M

pecifikace pr

y

tak SW. Pra samostatn

funkce

č

Kč DB

Kč DB

Kč DB

Kč DB

Kč DB

Kč DB

Kč DB

Kč sběrnic

Kč

Kč DB

č správa

Kč XML ak

Kč Aplikač

Kč Middle

Kč Certifik

Kč SAN Inf

Kč Diskove

Kč Páskov

Kč Zálohov

Kč cena im

Kč síťové p

Kč síťové p

Kč síťové p

Kč síťové p

Kč síťové p

Kč síťové p

Kč síťové p

Kč síťové p

Kč implem

Kč vývoj a

Kč Aplikač

Kč Zálohov

Kč

Ministerstvo fi

rojektu Elekt

rostředí je řný storage

ce služeb

kcelerace, ES

ční servery

eware server

kační autorita

frastruktura

e pole

á jednotka

vání

mplementace

prvky

prvky

prvky

prvky

prvky

prvky

prvky

prvky

mentace sít p

implementa

ční servery

vání

inancí České

ronická evide

Strana

řešené na pv druhém d

SB, FIK,

y

a

e

prvků

ace SW

é republiky

ence tržeb

a 118 z 186

platformě datovém

poznámka

Varian

Varian

S822 2

S824 2

CA s H

Storviz

TS3500

Switch

DataPoApplia

TSM

Inform

Tomca

WebSp

Integra

Implem

DDOS

UTM

Switch

Switch

IPS/IDS

Loadba

WAF

SIEM

Implem

Bezpeč

EET

Varianpřipravschop

Varian

CPS ‐ A

TS3500

DataPoApplia

TSM

SQL se

nta 2 vychá

nta 2

20c 256GB RA

24c 1TB RAM

SM

ze v7000

0

h 48 port

ower Gatewnce

mix nebo DB2

at

phere MQ

ation Bus

mentace

h

h OOB

S

alancing

mentace

čnostní proje

nta 3 je zvené řešenné realizov

ta 3

APP,DB

0

ower Gatewnce

erver

ází z předpo

poče

AM

M

way

2

200MD

ekt

aložena naní společnoat prostředí

poče

way

okladu exist

et SW/HW

3 HW

2 HW

2 HW

2 HW

1 HW

2 HW

4 HW

SW

SW

SW

SW

SW

1

2 Networ

2 Networ

2 Networ

2 Networ

2 Networ

2 Networ

4 Networ

1 Networ

SW

a virtualizovostí Microsoí pro OS Mi

et SW/HW

2 HW

1 HW

4 HW

SW

SW

tence smlou

W cena

212 83

3 27

6 84

2 42

9 24

4 73

1 14

22 82

1 75

35 15

6 32

24 60

20 00

rk 4 00

rk 6 00

rk 2 00

rk 2 00

rk 3 00

rk 4 00

rk 2 00

rk 2 00

2 50

15 00

32 00

vané platfooft včetně icrosoft a Li

W cena

202 2

57

4 7

22 8

1 7

23 5

S

uvy ISLO s

39 106,85 Kč

77 085,36 Kč

48 058,72 Kč

26 891,78 Kč

48 709,68 Kč

30 187,80 Kč

46 398,16 Kč

28 832,00 Kč

59 664,00 Kč

52 038,40 Kč

‐ K

21 120,00 Kč

00 120,95 Kč

00 000,00 Kč

00 000,00 Kč

00 000,00 Kč

00 000,00 Kč

00 000,00 Kč

00 000,00 Kč

00 000,00 Kč

00 000,00 Kč

00 000,00 Kč

00 000,00 Kč

00 000,00 Kč

00 000,00 Kč

ormě CPS. HW a SWinux.

245 575,58 K

7 800 000,00

730 187,80 K

828 832,00 K

759 664,00 K

500 000,00 K

M

pecifikace pr

IBM..

funkce

č

č Aplikač

č DB serv

č Certifik

č Dískové

č Pásková

č SAN Inf

č XML ak

č Zálohov

č Databáz

č Aplikač

č Messag

č ESB

č cena im

č síťové p

č síťové p

č síťové p

č síťové p

č síťové p

č síťové p

č síťové p

č síťové p

č implem

č Kompledokumetesty

č vývoj a

Platforma W prostředk

funkc

č

Kč Aplikserve

Kč Páskozáloh

Kč XML

Kč Záloh

Kč Data

Ministerstvo fi

rojektu Elekt

ní servery

very

ační autorita

é pole

á knihovna

frastruktura

celerace, ES

vání

zový systém

ní servery

ge Queue

mplementace

prvky

prvky

prvky

prvky

prvky

prvky

prvky

prvky

mentace sít p

exní bezpečnentace, bezp

implementa

je dodáváků. Virtualiz

ce

kační a databery

ová knihovnahování

akcelerace,

hování

bázový systé

inancí České

ronická evide

Strana

a

B, FIK,

e

rvků

nostní pečnostní

ace SW

ána jako kozované pros

bázové

a ‐

ESB, FIK,

ém

é republiky

ence tržeb

a 119 z 186

poznámka

ISLO

ISLO

ISLO

ISLO

ISLO

ISLO

ompletní středí je

poznámk

a

Integra

CA s HS

Implem

DDOS

UTM

Switch

Switch

IPS/IDS

Loadba

WAF

SIEM

Implem

Bezpeč

EET

ation Bus

SM

mentace

h

h OOB

S

alancing

mentace

čnostní proje

200 MD

ekt

SW

3 HW

1

2 Networ

2 Networ

2 Networ

2 Networ

2 Networ

2 Networ

4 Networ

1 Networ

SW

4 7

2 4

10 0

rk 4 0

rk 6 0

rk 2 0

rk 2 0

rk 3 0

rk 4 0

rk 2 0

rk 2 0

2 5

15 0

32 0

S

700 000,00 K

426 891,78 K

000 000,00 K

000 000,00 K

000 000,00 K

000 000,00 K

000 000,00 K

000 000,00 K

000 000,00 K

000 000,00 K

000 000,00 K

500 000,00 K

000 000,00 K

000 000,00 K

M

pecifikace pr

Kč ESB

Kč Certif

Kč cena

Kč síťov

Kč síťov

Kč síťov

Kč síťov

Kč síťov

Kč síťov

Kč síťov

Kč síťov

Kč imple

Kč Kompdokutesty

Kč vývoj

Ministerstvo fi

rojektu Elekt

fikační autor

implementa

é prvky

é prvky

é prvky

é prvky

é prvky

é prvky

é prvky

é prvky

ementace sít

plexní bezpementace, bey

j a implemen

inancí České

ronická evide

Strana

rita

ace

t prvků

ečnostní ezpečnostní

ntace SW

é republiky

ence tržeb

a 120 z 186

Řeše

Řešen20000konco

Bude úzká služebplánů

Proce

ZajištěISO/IEkterá jprovoverzi přizpůneustázákaz

Řešenna ná

Strat(Serv

Návr(Serv

ní proces

ní procesů 0. Důraz bovým uživat

provedenokoordinaceb, katalogu, plánu a po

esy správy a

ění shody EC 2000-2)je nejvhodzu služeb 3), který zůsobena poálé měření

zníka.

ní procesusledující (d

tegie služevice Strateg

rh služeb vice Design

su správy

provozu abude kladtelům a na

o stanovene a propoju služeb, plolitiky zlepš

a provozu s

s požadav) je nezávinější pro evhodně koahrnuje neotřebám orí a zlepšov

Obráz

u správy adále stručně

eb gy)

n)

a provoz

a správy sluen na proprocesy do

í rozsahu aení s analýlánu managšování služ

služeb

vky průmyislé na orga

efektivní sluombinuje Iejlepší doprganizací r

vání kvality

zek 28: Poje

a provozu ě vymezen

u služeb

užeb systéocesy živoohledu, mo

a cílů řešenýzou rizik gementu sžeb a plánu

yslové normanizační stužbu. V náSO/IEC 20oručení (brozdílných dodávaný

ČSN ISO/ČSN ISO/

ČSN ISO/ČSN ISO/

BIPITSM Man

BIPITSM Man

II

InterníInterní

etí řešení pro

služeb vné) procesy

Správa Správa Správa

Správa Správa Správa Správa Správa

Manag Správa

Manag Správa

S

m EET budotního cykonitorování

ní, provedev rámci řelužeb, provu školení a

my ISO/IECtruktuře. Povaznosti na0000 obsaest practicvelikostí a

ých služeb

/IEC 20000-1 /IEC 20000-1

/IEC 20000-2/IEC 20000-2

P 0005nagers GuideP 0005nagers Guide

TILTIL

í procesyí procesy

ocesu správ

e výše uvy:

a financí (Fina portfolia sla požadavků

a katalogu sa úrovně slua kapacit (Ca dostupnosa kontinuitement)

a bezpečnement)

a dodavatelů

M

pecifikace pr

de řešeno lu jednotliví, podpory u

ena analýzaešení bezpvozních povzděláván

C 2000 (reoskytovatela to, nabízhujícím po

ces) správya která jsoIT a to jak

vy a provozu

vedeném p

nancial Manužeb (Servů (Demand

služeb (Servužeb (Servicapacity Ma

sti (Availabilty služeb

nosti infor

ů (Supplier

Ministerstvo fi

rojektu Elekt

v souladu vých služeuživatelů a

a rizik služečnosti), p

olitik, návrhní.

espektive dl služby mu

zené řešenovinnosti a y služeb ITu zaměřen

k z pohledu

u služeb

pojetí bud

nagement)vice Portfolio

Manageme

vice Catalogce Level Management)lity Manage

IT (IT

rmací (Inf

Manageme

inancí České

ronická evide

Strana

s normou eb poskyto řešení inc

eb (bude zpříprava pou SLA, pro

doporučenusí použít sí procesu sITIL (aktu

T, která mona na služu poskytova

e tedy za

o Management)

gue Managanagement)

ement) Service C

formation

ent)

é republiky

ence tržeb

a 121 z 186

ISO/IEC ovaných identů.

zajištěna olitiky IT ovozních

í normy strukturu, správy a uálně ve ohou být by a na atele tak

aměřeno

ment)

ement) )

Continuity

Security

Přec(Serv

Prov(Serv

Neus(ConImpr

chod služevice Transi

voz služebvice Opera

stálé zlepšntinual rovement)

�

eb ition)

b ation)

šování sluSer

žby rvice

Správa Správa

Configu Správa Plánov

Suppor Správa

Manag Ověřen Vyhodn

Správa Správa Provád Správa Správa

Zlepšov Měření Vykazo

S

a změn (Chaa aktiv auration Mana znalostí (Kání a podprt) a releasů ement)

ní a testovánocení (Eva

a událostí (Ea incidentů (dění požadaa přístupů (Aa problémů

vací procesí služby (Seování služby

M

pecifikace pr

ange Manaa konfigunagement)Knowledge Mpora přech

a nasazen

ní služby (Saluation)

Event Mana(Incident Maavků (RequeAccess Man(Problem M

s v 7 krocíchervice Measy (Service R

Ministerstvo fi

rojektu Elekt

gement) race (Se

Managemeodu (Trans

ní (Release

Service Vali

agement) anagementest Fulfilmenagement)

Managemen

h surement) Reporting)

inancí České

ronická evide

Strana

rvice Ass

ent) sition Plann

e and Dep

dation and

t) ent)

nt)

é republiky

ence tržeb

a 122 z 186

set and

ning and

ployment

Testing)

Řeše

ŘešenEET č. 181bezpemechainformbezpezaved

Řešenpožadzákon

1.

2.

3.

Na záPoskysobě j

Systémho byl

Bezpe15408

ní bezpeč

ní bezpečnobude tento/2014 Sb.,

ečnosti). Dáanismů zaj

mace až do ečnostní zpení systém

ní bezpečnodavků a řeša. Při řešen

Zajistit zimplemen

Vytvořit fsystém b

Navrhnouv souladu

o n

o z(č

o zz

o pp

ákladě výšytovatel řešedoucích eta

Etapa 1 –

Etapa 2 –

Etapa 3 –

m řízení beo možné, v

ečnostní fun8.

čnosti sys

osti Systémo zařazen

o kybernetále je přejišťujících stupně „Dů

působilosti, u řízení bez

osti Systémšení bezpení bezpečno

zapracovánntaci celého

funkční systbezpečně pr

ut a zavéstu s požadav

normy ČSN

zákona č. 1zákon o kyč. 181/2014

zákona č. způsobilosti

požadavky právních no

še uvedenení bezpečnapách násle

– Analýza a

– Implemen

– Monitorov

zpečnosti Sv případě po

nkce budou

stému EET

mu EET mumezi význ

tické bezpeedpoklad, ž

bezpečnosůvěrné“ dle

ve znění zpečnosti in

mu EET budečnostních osti Systém

ní bezpečno systému b

tém řízení brovozovat.

t systém řívky:

ISO/IEC 27

81/2014 Sbybernetické Sb., a vyhl

412/2005 , ve znění p

kladenými orem.

ých cílů anosti Systémedovně:

a návrh bez

ntace bezpe

vání a přezk

Systému EEotřeby, certi

u navrženy

T

usí vycházenamné infoečnosti a o že některá st celého

zákona č. pozdějších

nformací.

de zahrnovapožadavků u EET mus

nostních pbezpečnost

bezpečnost

zení bezpe

7001:2014,

b., o kybernbezpečnos

lášky NBÚ“

Sb., o ocpozdějších

na systémy

a požadavmu EET rea

zpečnosti Sy

ečnosti Sys

koumání be

ET musí býtfikovat pod

ve formě T

S

et z předpoormační sy

změně soudokument

systému m412/2005 S předpisů.

at posouzev souladu

sí Poskytova

požadavků i.

ti informací

ečnosti a n

netické bezpsti) a navaz),

chraně utapředpisů (p

y veřejné s

vků zadávaalizoval zav

ystému EET

tému EET

ezpečnosti S

t Poskytovale normy Č

Typizovanýc

M

pecifikace pr

kladu, že vstémy dle uvisejících tace Systé

může být Sb., o ochra

Pro Systé

ní vstupnícs normou

atel sledova

na Systé

Systému E

ávrh bezpe

pečnosti a zujících vyh

ajovaných pro některé

správy a po

ací dokumvedení bezp

T

Systému EE

atelem navrSN ISO/IEC

ch bezpečn

Ministerstvo fi

rojektu Elekt

vzhledem kpísmena

zákonů (záému EET, klasifikovananě utajovaém EET je

h podmíneISO/IEC 2

at tři základ

m EET o

EET tak, ab

ečnostních

o změně sohlášek NBÚ

informací části dokum

ožadavky d

entace je pečnosti Sy

ET

ržen a impleC 27001:20

nostních pro

inancí České

ronická evide

Strana

k významu Sd) §2 dle

ákon o kybeobsahující

ná jako uaných informe tedy poža

k a bezpeč27001 a poní cíle:

od návrhu

by bylo mož

funkcí tak,

ouvisejícíchÚ (dále také

a o bezpmentace),

dalších rele

požadováystému EET

ementován 14.

ofilů s využ

é republiky

ence tržeb

a 123 z 186

Systému zákona

ernetické í popisy tajovaná mací a o adováno

nostních ožadavky

až po

žné tento

aby byl

h zákonů é „zákon

ečnostní

vantních

no, aby T ve 3 po

tak, aby

žitím ISO

Při reaISO/IEzejmé

O

alizaci řešeEC 27001:2na potom:

zákon č. kyberneti

zákon č.

zákon č. znění poz

zákon č.

zákon č.

zákon č. změně ně

Obrázek 29:

ní bezpečn2014 s tím,

181/2014 Sické bezpeč

101/2000 S

412/2005 zdějších pře

227/2000 S

365/2000 S

121/2000 Sěkterých zá

Schéma bez

nosti Systém že bude d

Sb., o kybečnosti)

Sb., o ochra

Sb., o ochedpisů

Sb., o elektr

Sb., o inform

Sb., o právákonů (auto

zpečnostníc

mu EET buddále akcen

rnetické be

aně osobníc

raně utajov

ronickém po

mačních sys

vu autorskérský zákon

S

ch činností a

de se vychntovat další

ezpečnosti a

ch údajů v p

vaných info

odpisu v pla

stémech ve

m, o práve) v platném

M

pecifikace pr

a souvisejíc

ázet a řídit í relevantní

a o změně

platném zně

ormací a o

atném zněn

eřejné správ

ch souvisej znění.

Ministerstvo fi

rojektu Elekt

cí dokument

ustanovení zákony, n

souvisejícíc

ění

bezpečnos

ní

vy v platném

jících s práv

inancí České

ronická evide

Strana

tace

ími standarnormy a sta

ch zákonů (

stní způsob

m znění

vem autors

é republiky

ence tržeb

a 124 z 186

rdu ČSN andardy,

(zákon o

ilosti, ve

ským a o

Dále je

Jednoznázo

Řešensystémimplem

Vzhledmechainformbezpe

Dále bezpe

e požadová

Přípravaaspektů bezpečnorealizaceEET.

Bezpečna prosazobezpečno

Závěrečnbezpečnointerních

Řízení audržení sstavu beprováděn

otlivé složkyrněny na sc

ní bezpečnomu tak, mentovanéh

dem k tomanismů zaj

mace až do ečnostní způ

Poskytovkterá u n

Zaměstnmechanisosoby pro

Poskytovinformačn„Důvěrné

následuje ečnosti.

áno realizov

a bezpečnoprojektu včostních op

e ve formě

nostní proováním bezostního proj

ný bezpečostních funkprocesů Sy

a údržba bsouladu sta

ezpečnosti snými v rámc

y, jejich nchématu uv

osti Systémaby bylo ho systému

mu, že nějišťujících stupně „Důůsobilosti, js

vatel musí ěho vzniká

anci Posksmů zajišťuo přístup k

vatel musí dních systém

é“ dle zákon

rozklad či

vat řešení b

ostního prčetně stano

patření s nábezpečnos

ojektový zpečnostnícjektu Systé

čnostní aukcí a bezpeystému EET

ezpečnostavu bezpečs bezpečnoci jeho imple

ávaznosti vedeném na

mu EET muzajištěno

u.

ěkterá dokbezpečnosůvěrné“ dle sou na Pos

být držitelenebo je mu

kytovatele, ujících bezputajované i

disponovat mů pro zprana č. 412/20

nností a o

ezpečnosti

rojektu Syovení bezpáslednou stních mech

dohled Sch funkcí a mu EET.

udit řešenečnostních mT.

ti při provonost s bezp

ostními potřementace a

a postup a následujíc

sí být zajiš okamžité

kumentace t celého szákona č. kytovatele k

em Osvědču poskytnuta

zpracovápečnost cenformaci ne

prostředky acování dok005 Sb., a p

obsah výst

S

EET v nás

ystému EEpečnostníchspecifikací hanismů na

Systému Ebezpečnos

ní Systémmechanism

ozu Systémpečnostnímřebami Sysa provozu.

realizace řcí straně.

těno v kooré zapraco

systému systému, m412/2005 Skladeny tyto

čení podnika, nejméně

ávající čáelého systéejméně pro

fyzické a akumentace prováděcích

tupů realiz

M

pecifikace pr

ledujících k

ET zahrnujíh cílů a an

bezpečnos úrovni jed

EET zahrnstních mech

u EET zamů včetně je

mu EET, kmi požadavkstému EET

řešení bez

rdinaci s náování bezp

EET, zejmmůže být Sb., o ochrao požadavk

katele pro pro stupeň

sti dokummu, musí stupeň „Dů

administrativv režimu u

h vyhlášek.

zovaných v

Ministerstvo fi

rojektu Elekt

krocích:

ícího analýnalýzy rizikstních funknotlivých ko

nující dohlhanismů v s

a účelem ejich prosaz

která bude ky prostředí

v souvislo

zpečnosti S

ávrhem a impečnostních

ména část klasifikovánaně utajova

ky:

přístup k uň „Důvěrné“

mentace, být držiteli ůvěrné“.

vní bezpečutajované in

v jednotlivýc

inancí České

ronická evide

Strana

ýzu bezpeč, návrh efekcí a návromponent S

led nad souladu s o

ověření fuzení do rele

zahrnovat í a udržení sti s jeho z

Systému E

mplementach požadav

obsahujícína jako uaných inform

tajované in.

obsahující Osvědčen

čnosti a beznformace do

ch etapách

é republiky

ence tržeb

a 125 z 186

nostních ektivních rh jejich Systému

realizací obsahem

unkčnosti vantních

zejména souladu

změnami

ET jsou

cí celého vků do

í popisy tajovaná mací a o

nformaci,

popisy í fyzické

zpečnosti o stupně

h řešení

Etapa

Analýzsystémkonče

V rámzpracoo aplikprojek

Etapa

1.

2.

3.

Grafic

Fáze 1

V prvnSystémsystém

V této

1 – Analýz

za a návrh mu EET a n jeho předá

ci této etaování bezpekovatelnostikt Systému

1 musí obs

Určení zá

Hodnoce

Zpracová

cké znázorn

1.1 – Určen

ní fázi řešenmu EET, nmu EET.

fázi se pro

Analýzu v němž b

Definováaspekt dl

za a návrh

bezpečnosnavrhnout b

áním do pro

apy bude pečnostní poi a Plánu oEET.

sahovat nás

ákladních p

ení a řízení

ání Bezpečn

ění činnost

b

Obráze

ní základníc

ní bezpečnonávrh cílů ř

vedou úkon

funkčních bude provoz

ní rozsahu le ČSN ISO

bezpečnos

sti systémubezpečnost

ovozu.

provedeno olitiky Systéšetření rizik

sledující fáz

parametrů ře

rizik Systém

nostního pr

tí požadova

EtapbezpEtapbezp

ZpracovánZpracován

ProvedeProvede

NN

Určení a zprozsahu

bezpečnostiEET

Určení a zprozsahu

bezpečnostiEET

Prbezpeč

Prbezpeč

ek 30: Schém

ch parame

osti Systémřešení bezp

ny důležité

a legislativzován.

řešení bezO/IEC 27001

sti systému

u EET budetní řešení S

stanovení ému EET vk Systému

ze:

ešení bezpe

mu EET

ojektu Syst

aných realiz

pa 1 - Anpečnosti pa 1 - Anečnosti

ní BezpečnoE

ní BezpečnoE

ení Analýzyení Analýzy

BezpečnoBezpečnos

ávrh Plánuávrh Plánu

pracování řešení i Systému T

pracování řešení i Systému T

rohlášení o ačnostních oprohlášení o ačnostních op

ma etapy 1 ř

trů řešení

mu EET budpečnosti a

pro realizac

vních bezpe

zpečnosti sy1:2014.

S

u EET

e mít za cíSystému E

rozsahu avčetně bezp

EET. V záv

ečnosti Sys

ému EET

ovat v této

nalýza a systému

nalýza a systému

ostní politikEETostní politik

EET

y rizik Systy rizik Systé

stní projektstní projekt

u ošetření ri ošetření ri

ZpracovbezpečnZpracovbezpečn

aplikovatelnopatření Systéaplikovatelnopatření Systé

řešení bezpe

bezpečnos

de provedennásledně z

ci řešení be

ečnostních

ystému EET

M

pecifikace pr

íl identifikovET počínaj

cílů řešenpečnostní stvěru etapy

stému EET

etapě je uv

návrh u EETnávrh u EET

ky Systémuky Systému

ému EETému EET

tt

izik zik

vání cílů řešenosti Systém

EET

ání cílů řešenosti Systém

EET

osti ému EETosti ému EET

ečnosti Syst

sti systému

no upřesnězpracuje Be

ezpečnosti S

požadavků

T, který bu

Ministerstvo fi

rojektu Elekt

vat požadae návrhem

ní bezpečntrategie, přbude zprac

veden na ná

u u

ení mu ení mu

tému EET

u EET

ní rozsahu ezpečnostn

Systému EE

ů na Systém

de obsahov

inancí České

ronická evide

Strana

avky na bezm celého sy

nosti, analýipravení Prcován bezp

ásledujícím

řešení bezní politiku in

ET:

m EET a p

vat interní a

é republiky

ence tržeb

a 126 z 186

zpečnost ystému a

ýza rizik, rohlášení ečnostní

obrázku.

zpečnosti nformací

prostředí,

a externí

Popis

1.

2.

3.

požadovan

Rozsah EET z hltechnolog

a. o

b. uS

c. z

d. r

e. z

Cíle řešedosaženobudou ksystému

Bezpečnkoncepčnoblastechpopis zaBezpečn

a. S

b. p

c. f

d. b

e. r

f. k

g. z

h. z

i. z

j. z

ných základ

řešení bezlediska zapgií. Rozsah

organizační

umístění orSystému EE

základní akt

rozhraní řeš

závislosti k ř

ení bezpečo řešením

konkrétně sEET.

nostní polního dokumh bezpečnoaváděných ostní politik

Strategie be

popis systém

funkční blok

bezpečnost

regulatorní,

kritéria hodn

zásady bezp

orga

bez

říze

říze

kryp

fyzic

bez

bez

dod

říze

kon

sou

způsob říze

způsob vyčl

způsob mon

ních výstup

zpečnosti pojených or bude mít n

struktura v

ganizačníchET

tiva a techn

šení bezpeč

řešení bezp

čnosti Systbezpečnos

stanoveny

litiku informentu shrnuosti informac

bezpečnosku systému

ezpečnosti S

mu EET

ky systému

prostředí s

právní a sm

nocení rizik

pečnosti inf

anizace bez

zpečnost lids

ení aktiv

ení přístupu

ptografie

cká bezpeč

zpečnost pro

zpečnost ko

davatelské v

ení incidentů

tinuita bezp

lad s požad

ní bezpečn

eňování a ř

nitorování a

pů:

Systému Erganizačníc

následující s

ve vztahu k

h útvarů a

nologie pokr

čnosti Systé

pečnosti Sy

tému EET –sti v určené

na období

rmací sysujícího stratcí s důrazestních zásaEET je pož

Systému EE

EET

systému EE

mluvní poža

formací v S

zpečnosti in

ských zdroj

čnost a bezp

ovozu

munikací

vztahy

ů bezpečno

pečnosti info

davky

ostní dokum

řízení zdrojů

a měření efe

S

EET – upřech složek, vstrukturu:

řešení bezp

zařízení po

rývaní v rám

ému EET

ystému EET

– budou obsm rozsahuí implemen

stému EETtegii a zásam na uvedead v rámci

žadována ná

ET

T

adavky na ře

ystému EET

nformací

jů

pečnost pro

osti informac

ormací

mentace Sy

ů pro zajiště

ektivity řeše

M

pecifikace pr

esní rozsahvybraných

pečnosti Sy

okrývaných

mci k řešení

T.

sahovat stru řešení bentace s výh

T je požaady bezpečení odpovědi jednotlivýásledující s

ešení bezp

T:

ostředí

cí

ystému EET

ění bezpečn

ení bezpečn

Ministerstvo fi

rojektu Elekt

h řešení beprostor, de

ystému EET

h v rámci k

í bezpečnos

učný výčet zpečnosti Shledem na

dováno zpčnosti systédností za oých oblastístruktura:

ečnosti Sys

T

nosti Systé

nosti Systém

inancí České

ronická evide

Strana

ezpečnosti Sefinovaných

T

řešení bez

sti Systému

cílů, kterýcSystému E

a zajištění

pracovat veému EET vblast bezpeí bezpečno

stému EET

mu EET

mu EET.

é republiky

ence tržeb

a 127 z 186

Systému h aktiv a

zpečnosti

u EET

h má být ET. Cíle provozu

e formě ve všech ečnosti a osti. Pro

Fáze 1

Cílem uplatn

V počávybranEET, sidentifnavržeProhlánásled

V závěpřiměřcílů a bezpe

V této

1.2 – Hodn

hodnocenínění hrozeb

átku fáze bnou metodispolu s určefikovány a ena opatřeášení o apldně popsán

ěru analýzřených bezsnížení be

ečnostních o

fázi budou

stanoven

o k

o k

identifika

o pzb

o id

analýza r

o pid

o p

o u

hodnocen

o p

o s

Definová

o vv

o uo

o vv

o va

o fo

o zp

ocení a říz

í a řízení ri, které na a

bude navržku identifikuením jejich hodnoceny

ení k pokrylikovatelnos

n v Plánu oš

y rizik budpečnostníc

ezpečnostníopatření pro

provedeny

ní kritérií rizi

kritéria akce

kritéria pro p

ce rizika be

používá proztrátou důvbezpečnost

dentifikuje v

rizika bezpe

posuzuje pdentifikovan

posuzuje re

určuje úrove

ní rizika bez

porovnává v

stanovuje pr

ní procesu

výběr vhodvýsledky po

určení všecošetření rizi

verifikace ovynecháno

vytvoření a zdůvodně

formulace P

získání soupřijetí zbytko

ení rizik sy

zik bude idaktiva moho

žena metoduje aktiva, bezpečnos

y hrozby aytí rizik. Zsti bezpečnšetření rizik

de zajištěnh protiopatřích rizik budo Systému E

y úkony, vyž

ik bezpečno

eptace rizik

provádění p

ezpečnosti i

oces posuzověrnosti, ini informací

vlastníky riz

ečnosti infor

potenciální ná rizika

álnou pravd

eň rizik

zpečnosti in

výsledky an

riority analy

ošetření riz

ných variaosuzování ri

ch opatřenka bezpečn

patření urč

Prohlášení ní pro jejich

Plánu ošetře

hlasu vlastových rizik

stému EET

dentifikovat ou působit.

dika hodnokterá budostních parama zranitelnoZdůvodnění nostních oSystému E

no provedeření pokrývde vybránaEET.

žadované n

osti informa

posouzení r

informací:

ování rizik bntegrity a

zik

rmací:

následky,

děpodobnos

nformací:

nalýzy rizik s

yzovaných r

zik bezpečn

ant pro ošezik

í nezbytnýnosti inform

ených výše

o aplikoh zahrnutí, a

ení rizik bez

níků rizik obezpečnost

S

T

aktiva Syst

cení a řízeu zahrnuta metrů (důvěsti působíc

výběru opatření Sy

EET.

ení zvládánvajících zjišta vyvážená

ormou ČSN

ací, která za

rizik bezpeč

bezpečnostidostupnost

, které by

st výskytu r

s kritérii rizi

rizik pro oše

nosti informa

etření rizika

ch k impleací

e s cílem ov

ovatelnosti,ať už jsou n

zpečnosti in

ohledně pláti informací

M

pecifikace pr

tému EET,

ení rizik Sydo rozsahuěrnost, integcí na aktivopatření buystému EE

ní a řízení těná rizika.kombinace

N ISO/IEC 2

ahrnují:

čnosti inform

i informací kti informac

y nastaly,

rizik

k

etření rizika

ací pro:

a bezpečno

ementaci v

věřit, že žá

které onebo nejsou

nformací

nu ošetřen.

Ministerstvo fi

rojektu Elekt

a zjistit úro

ystému EETu řešení begrita, dostu

va Systémuude provedT. Způsob

rizik prosPro naplně

e technickýc

27001:2014

mací

k identifikací v rozsah

pokud b

a

osti inform

vybrané var

dné nezbyt

obsahuje nu implement

í rizik bezp

inancí České

ronická evide

Strana

oveň rizik m

T. V návazezpečnosti Supnost). Dálu EET a ndeno v do

b řízení riz

střednictvímění bezpečch a netech

4:

ci rizik spojehu systém

by se rea

ací s ohle

rianty (vari

tné opatřen

nezbytná tována

pečnosti info

é republiky

ence tržeb

a 128 z 186

možného

znosti na Systému le budou následně kumentu

zik bude

m návrhu nostních hnických

ených se u řízení

alizovala

edem na

ant) pro

ní nabylo

opatření

ormací a

Metod

Popis

1.

2.

3.

Fáze 1

Cílem dokumpřehle

Úkolembezpe

Bezpena zábezpebezpefunkcínavaz

Normavýzna

dika analýzy

požadovan

Zpráva o

a. zm

b. p

c. v

d. v

e. s

f. s

g. p

h. d

Prohlášepřehled ořešení beaplikovánzbytkový

Návrh PSystému cílů bezp

a. c

b. ja

c. k

d. k

e. ja

1.3 – Zprac

přípravy ment Bezpeed a odůvod

m bezpečnečnostních f

ečnostní prákladě urč

ečnostních ečnosti proví pro funkčnzujících prof

a ČSN ISOmu jednotliv

úvod – v

charakte

y rizik musí

ných základ

o hodnocen

základní prmetodologie

přehled akti

výčet hroze

výsledky an

stanovení va

stanovení p

přehled vlas

detailní výsl

ení o aplikoopatření dleezpečnosti na. Součásch rizik.

Plánu ošetřEET, relev

pečnosti info

co bude vyk

aké zdroje b

kdo bude od

kdy to bude

ak budou vý

cování Bezp

bezpečnosečnostní p

dnění bezpe

nostního pfunkcí), kter

rofil systémčení systémcílů. Bezpe

vozního prosní celky sysfilů ochrany

O/IEC 1540vých dílčích

vymezuje zá

eristika sys

zároveň od

dních výstu

ní rizik Sys

ravidla a pe

v včetně ur

b a zranitel

alýzy pro je

ariant pro o

riorit pro oš

stníků rizik

edky analýz

ovatelnoste přílohy ASystému E

stí prohláše

ření rizik Svantních jedormací mus

konáno

budou vyža

dpovědný

dokončeno

ýsledky vyh

pečnostníh

stního projprojekt syečnostních f

projektu Syré budou sn

mu je specimu, analýzečnostní fustředí. Hlavtému EET a

y.

8 stanovujeh částí:

ákladní cha

stému – ob

dpovídat zá

upů

stému EET

postupy an

rčení bezpe

ností, která

ednotlivá ak

ošetření rizik

šetření rizik

zy rizik.

ti bezpečnoA normy ČSEET a přípení o aplik

Systému Ednotlivým fusí Poskytova

adovány

o

hodnoceny.

ho projektu

ektu Systéystému EEfunkcí vybra

ystému EEnadno a jed

ifikací konkzy prostředunkce jsou vním cílem a jejich kom

e následují

rakteristiky

ecný popis

S

konu č. 181

T – souhrnný

nalýzy rizik

čnostních p

na aktiva (

ktiva

ka

ostních opSN ISO/IEC

padné důvokovatelnost

EET – budenkcím a úroatel určit:

u Systému E

ému EET ET přehledaných k rea

T bude nnoznačné i

rétních bezdí, v kterésměrovány

bezpečnostmponenty po

ící strukturu

bezpečnos

systému, p

M

pecifikace pr

1/2014 Sb.,

ý dokument

k a přísluš

parametrů a

(skupiny akt

patření SysC 27001:20

ody, pro ktei bude spe

e obsahovaovním řízen

EET

bude zpra posuzova

alizaci a pos

avrhnout mplemento

zpečnostnícém bude y do všechtních profilůodle normy

u bezpečno

stního profil

pro který je b

Ministerstvo fi

rojektu Elekt

a jeho prov

t, který mus

šná hodnot

a vlastníků

tiv) působí

stému EET 014, která jeré nebyla ecifikace a

at stanovenní. Při pláno

acovat souaných bezpstup a způs

bezpečnosovatelné.

ch funkcí, ktprovozovánh oblastí bů tedy je výby ČSN ISO/

ostního pro

u,

bezpečnost

inancí České

ronická evide

Strana

váděcím vy

sí obsahova

tící kritéria

– uvede sojsou aplikonevhodná

a rozhodnut

ní cílů bezování jak do

uhrnný podpečnostníchsob jejich re

stní profil

eré jsou den, a požadbezpečnostiběr bezpečIEC 15408

filu, jeho o

tní profil urč

é republiky

ence tržeb

a 129 z 186

yhláškám.

at:

a včetně

ouhrnný vána při opatření í o výši

zpečnosti osáhnout

dkladový h funkcí, ealizace.

ly (sady

efinovány ovaných , včetně nostních a určení

obsahu a

čen,

V tétoSystém

Popis

1.

Etapa

Cílem bezpe

V návabezpenávazčinnos

Etapa

bezpečnjsou upřezásady a

bezpečndosaženybezpečno

požadavpožadavkinformačnsprávnosinformačn

o fázi budoumu EET:

výběr rekompone

konkretiz

návrh rea

požadovan

BezpečnČSN ISOs Bezpečprojekt bu

a. P

b. Sb

c. Vin

d. Sbin

e. M

2 – Implem

této fázeečnostních p

aznosti naečnostní smzností na jist bezpečno

2 obsahuje

2.1 Imple

2.2 Bezp

2.3 Zprac

nost prostřesněny záka hrozby, kte

nostní cíle y, ty jsou ostní cíle pr

vky na beky jsou rozními technst, a na požních techno

u proveden

elevantních enty;

zace bezpeč

alizace bezp

ných základ

nostní projO/IEC 1540čnostní polude zahrno

Popis systém

Specifikaci bbezpečnost

Vymezení nformační t

Stanovení bezpečnost nterpretace

Mapování v

mentace b

e bude rozpravidel a p

a výsledkyměrnice Syiné existujíostního sprá

e následujíc

ementace b

ečnostní šk

cování bezp

ředí – rozboladní aktivaerým systém

– upřesněrozděleny

ro prostředí

ezpečnost zděleny na ologiemi, n

žadavky na ologií.

ny následuj

bezpečno

čnostních fu

pečnostních

ních výstup

jekt – bude08. Budou itikou inform

ovat:

mu EET na

bezpečnostních předpo

bezpečnostechnologie

požadavkůjednotlivýc

e bezpečnos

zájemných

ezpečnost

zpracovat postupů Sys

y analýz ystému EEící či zpracávce.

cí fáze:

ezpečnostn

kolení a vzd

pečnostních

or bezpečnoa, předpoklam musí čeli

ní bezpečny na bezpí, ve které js

– naplněnpožadavky

na požadavbezpečnos

ící úkony,

ostních pro

unkcí;

h funkcí v rá

pů

e zpracovározpracovámací systé

a úrovni vym

tního prostřoklad, hroze

tních cílů a cílů bezp

ů na bezpch klíčovýchstních poža

vztahů mez

i Systému E

vybraná bstému EET.

a bezpečET, bezpečcované pos

ních opatřen

dělávání v S

h příruček a

S

osti prostřeady pro bezt,

nostních cílpečnostní csou systém

ní cílů návy na bezpevky na zárst prostředí,

které jsou

ofilů pro

ámci systém

án dle formny výchozí

ému EET d

mezení účel

ředí Systémeb a zásad

Systému pečnosti pro

pečnost Syh kompone

adavků a zá

zi cíli, předp

EET

ezpečnostn

nostního pčnostní přístupy) včet

ní Systému

Systému EE

a zajištění k

M

pecifikace pr

edí, ve kterézpečné fung

ů, které mucíle pro iny provozov

vrhem bezečnostní funruky, kde , které upře

důležité pro

funkční ce

mu EET.

mální struktuí bezpečnodo bezpečn

u, hranic a

mu EET na úbezpečnos

EET na o prostředí;

ytému EETent, požadaáruk;

poklady a h

ní opatření

projektu míručky a ntně příručk

EET

ET.

kontinuity Sy

Ministerstvo fi

rojektu Elekt

ém je systégování syst

usí být při nformační ány,

pečnostnícnkce, kteréje upřesně

esňuje opat

o realizaci

elky systém

ury profilu ostní cíle stnostních fu

struktury;

úrovni záklastní politiky;

úrovni cílů

T na úrovavků na bez

hrozbami.

í a bezpeč

musí poskynavazující ky/bezpečno

ystému EET

inancí České

ronická evide

Strana

ém provozovtému, bezp

řešení beztechnologi

h požadavé jsou prosěna míra zření v přímé

řešení bez

mu EET

ochrany dltanovené vnkcí. Bezp

adních aktiv

ů bezpečn

vni požadazpečnost p

čnostní fun

ytovatel zpostupy (p

ostní směrn

T

é republiky

ence tržeb

a 130 z 186

ván, zde ečnostní

zpečnosti e a na

vků, tyto sazovány záruk za ém okolí

zpečnosti

a jejich

e normy souladu ečnostní

v, služeb,

osti pro

avků na prostředí,

nkce do

pracovat případně nice pro

Graficnásled

Fáze 2

V této (dle Č

Nedílndle od

Ve smpracovSystém

Způsobezpeoblast

V této Systém

cké znázorndujícím obrá

2.1 – Imple

fázi budouSN ISO/IEC

nou součástdst. 3) § 5 zá

měrnicích Povních náplnmu EET bu

ob, formálníečnostního tí a náležito

fázi budoumu EET:

zavedení

určení a z

nění činnosázku.

ImzprImzpr

ImzpImzp

Mbs

Mbsy

ss

výs

výs

ZaZa

bb

Obráze

ementace b

u rozpracovC 27001:20

tí bezpečnoákona č. 18

oskytovatel ní a odpověddou zařaze

í uspořádánprojektu Systí normy Č

u proveden

í a zdokume

zdokument

stí požadov

EtapbezpeEtap

bezpeplementacracování Bplementaceracování Be

mplementacpracování b

mplementacpracování b

Zpracovábe

Zpracovábe

Managementbezpečnostiystému EET

Managementbezpečnosti ystému EET

Fyzická bezpečnost

systému EET

Fyzická bezpečnost

systému EET

Pořizování, ývoj a údržbsystému EET

Pořizování, ývoj a údržbsystému EET

ajištění shodajištění shod

Příručky probezpečnostn

role

Příručky probezpečnostn

role

ek 31: Schém

bezpečnost

vány cíle a 014 – Příloh

ostních činn81/2014 Sb.

stanoví ve dnosti v pro

eny do systé

ní směrnic ystému EEČSN ISO/IE

y následují

entování vy

tování způs

vaných rea

pa 2 - Imečnosti pa 2 - Imečnosti

e bezpečnoezpečnostne bezpečnoezpečnostn

ce bezpečnbezpečnostce bezpečnbezpečnost

ání Programezpečnostn

ání Programezpečnostn

t i

T

t

T

Klasinfo

systé

Klasinfo

systé

t Tt T

Bezpesysté

Bezpesysté

ba Tba T

Spbezpe

incsysté

Spbezpeč

incsysté

dy s bezpečE

dy s bezpečE

Bezppropo

Bezppropo

o ní o ní

ma etapy 2 ř

tních opatř

opatření ba A - bezp

ností bude n.

spolupráci ocesu řízenému řízení d

a jejich počT. SměrnicC 27001:20

ící úkony, k

ybraných be

obu měření

S

lizovat Pos

mplemesystém

mplemesystémostních opaních směrnostních opaních směrn

nosti na protních příručosti na provtních příruč

mu školení aního povědo

mu školení aního povědo

sifikace ormací ému EET

ifikace ormací mu EET

ečnost ICT ému EETčnost ICT ému EET

práva čnostních

cidentů ému EET

práva čnostních

cidentů ému EET

čnostními poEETnostními poEET

pečnostní ovozní ostupy

ečnostní ovozní ostupy

řešení bezpe

ření Systém

bezpečnostiečnostních

návrh a pop

se Zadavaí bezpečnodokumentac

čet navrhnece však vžd014 a zákon

které jsou d

ezpečnostn

í účinnosti v

M

pecifikace pr

skytovatelem

entace mu EETentace mu EET

atření a funnic systémuatření a funknic systému

ovozní úrovnček a postuvozní úrovnček a postu

a zvyšovánomí a zvyšovánomí

Bezpečnolidských zdsystému E

Bezpečnolidských zdsystému E

Řízenpřístupovpráv syst

EET

Řízenípřístupovpráv systé

EET

Řízenkontinučinnos

systému

Řízeníkontinučinnos

systému E

ožadavky syožadavky sys

HavarijnpostupHavarijnpostup

ečnosti Syst

mu EET

informací profilů dle

pis nástrojů

telem Systésti Systémuce provozov

e Poskytovady budou ona č. 181/2

důležité pro

ích opatřen

vybraných b

Ministerstvo fi

rojektu Elekt

m v této et

kcí a u EETkcí a u EET

ni a upůni a upů

ní ní

ost drojů EET

ost drojů EET

í vých ému

í vých ému

í uity stí EET

í ity

stí EET

stému stému

ní pyní y

tému EET

do postupůISO/IEC 15

relevantníc

ému EET rou EET. Bezvatele.

atel na zákobsahovat 014 Sb., vč

o realizaci

í (ČSN ISO

bezpečnost

inancí České

ronická evide

Strana

tapě je uve

ů ve formě 5408).

ch pro Syst

ole, navrhnepečnostní s

kladě zpracozapracovánčetně vyhláš

řešení bez

O/IEC 27001

tních opatře

é republiky

ence tržeb

a 131 z 186

eden na

směrnic

tém EET

e úpravu směrnice

ovaného ní všech šek NBÚ.

zpečnosti

1: 2014;)

ení.

Popis

1.

2.

3.

Fáze 2

V této bezpeúkolemzaměs

Dále bbezpezajištězaměsbude v

V této inform

požadovan

Směrnic

a. MboI

b. Bp

c. Ks

d. Fjezp

e. Szte

Směrniczpracová

a. Břs

b. Řk

c. Apcp

SměrnicEET bud

a. Řin

b. Řz

2.2 – Bezpe

fázi budeečnostními m bude zabstnanci prov

budou vyškečnosti Sysění bezpečstnanců, ktevytvořen e-l

fázi budoumací Systém

zpracová27001:20

zpracová– upřesn

ných základ

ce řízení be

ManagemenbezpečnostodpovědnosSMS. Bezpečnostpersonální bKlasifikace schématu a Fyzická bezejichž cílemzničení či jinpro zpracovShoda s bezajištění sechnologick

ce bezpečnána v rozsah

Bezpečnostřádný a bezs tím souvisŘízení přísk informacímAkvizice, vpořizování, celého životprovoz a údce řízení ince zpracová

Řízení incidncidentů, reŘízení kontzahrnující st

ečnostní šk

e provedenopatřeními

bezpečit znvozovatele.

koleni pracostému EETčnosti Systeří budou plearningový

u provedenmu EET:

ání program014 a zákon

ání podkladůnění katego

ních výstup

ezpečnosti

nt bezpečni informací stí za průb

t lidských zbezpečnost

informací způsob ma

zpečnost a bm je předcným zásahů

vání informaezpečnostnsouladu pkými postup

nosti informhu:

t provozu azpečný pro

sejících. stupu stanom, službám vývoj a úd

vývoje a tního cyklu ržbu. cidentů bezna v rozsah

dentů bezpeeakce na něinuity činnotanovení ro

kolení a vzd

o seznáme. Bude vyalost a poc

ovníci provo. Tito zamému EET

provádět intý portál.

y následují

mu školení na č. 181/20

ů pro školeorií, pro kte

pů

Systému E

nosti informa bezpečn

běh celého

zdrojů definti.

určující zpanipulace s bezpečnost

cházet neauům do inforací. ími požadařijímaných py dle přijatmačních a

a bezpečnoovoz prostře

ovující opaa procesům

držba inforúdržby SysSystému E

zpečnosti hu:

ečnosti infoě a jejich vyostí a základolí, procesů,

dělávání v S

ení pracovnytvořen prochopení pos

ozovatele Směstnanci b

vyplývají. terní audity

ící úkony, k

a zvyšová014 Sb., vče

ní zaintereseré bude šk

S

EET bude z

ací definujnosti informcyklu ISM

nující bezp

působ klascitlivými inf

t prostředí dutorizovanérmací a do

avky rozpropatření

tých norem komunika

ost komunedků pro z

atření zaměm. rmačních sstému EETEET od fáz

informací a

ormací stanyhodnocovádní rámec ř, struktury d

Systému EE

níků provoogram budostupů a činn

Systému EEbudou sezn

Zvláštní p bezpečnos

které jsou d

ání bezpečetně vyhláš

sovaných zkolení prov

M

pecifikace pr

zpracována

ící pravidlamací v proje

MS a uvede

pečnostní p

sifikace infformacemi.definující beému přístup

prostor, ve

racovávajícís legislati

a standardačních tech

ikací stanopracování

ěřená na

systémů dT k prosazee návrhu, v

a zajištění

novující posání. řízení kontindokumentac

ET

ozovatele Sování bezpností v obla

ET, kteří jsonámeni s prpozornost msti Systému

důležité pro

čnostního pšek NBÚ)

aměstnancvedeno, pří

Ministerstvo fi

rojektu Elekt

v rozsahu:

a a postupyektovém řízení způsob

pravidla a p

formací vč

ezpečnostnpu, poškoze kterých se

í konkrétníivou a bů. hnologií S

ovující opatinformací a

ochranu a

efinující pení bezpečvývoje, test

í kontinuity

stupy hláše

nuity podnikce a odpově

Systému EEpečnostníhoasti bezpeč

ou zahrnutiravidly a úmusí být vu EET. Pro

o realizaci

povědomí

ů provozovprava prez

inancí České

ronická evide

Strana

y pro manazení včetněu měření ú

postupy pr

etně klasif

í pravidla aení, znehod

e nacházejí

í postupy bezpečnost

Systému EE

tření zaměa služeb a

a kontrolu

ravidla a čnosti informtování až po

y činností S

ení bezpeč

katelských ědností.

ET se zavo povědomnosti Systé

do rozsahúkoly, kterévěnována školení pra

řešení bez

(dle ČSN

vatele Systézentace a D

é republiky

ence tržeb

a 132 z 186

agement ě určení účinnosti

ro oblast

fikačního

postupy, dnocení, zařízení

v oblasti tními či

ET bude

ěřená na procesů

přístupu

postupy mací do o vlastní

Systému

nostních

činností,

áděnými mí, jehož ému EET

u řešení é jím ze přípravě

acovníků

zpečnosti

ISO/IEC

ému EET Desatera

Popis

1.

2.

3.

Fáze 2

V této úrovně

Rozsaz implbezpe

V rám

Důrazpříruče

bezpečnoNBÚ)

proškolen27001:20

základních

ProgrambudovánSystému

a. Z

b. O

Materiálypro provzaměstna

E-learninformou evčetně vh

2.3 – Zprac

fázi budouě.

ah činnostíementovan

ečnostního p

ci fáze mus

Info

zajiz musí být ek pro obla

osti informa

ní zaměstna014 a zákon

požadovan

m školení aí bezpečnoEET. Rozs

Způsob bud zák

stra

kate

plán

odp

odp

odpSys

odppos

Obsahová n ško

Vstu

Per

Mim

vzd

y školení bvedení škoanců provoz

ngový porte-learninguhodného ob

cování bezp

u rozpracov

í a konkreých bezpeprojektu Sys

sí být vytvoř

ormační bez

štění kontinpoložen n

ast bezpečn

ací (ČSN IS

anců provona č. 181/20

ných výstup

a zvyšovánostního povsah program

dování bezpladní cíl bud

ategie budov

egorie zamě

nování budo

povědnost z

povědnost z

povědnost zstému EET,

povědnost ztupy Systém

náplň budolení k systé

upní školen

iodické ško

mořádné pro

ělávání v o

bezpečnosolení k zajizovatele Sy

tál – Vlastn. Poskytov

bsahu.

pečnostníc

vány bezpe

etizace výsečnostních stému EET

řena bezpe

zpečnosti S

nuity činnosna zpracovnosti se bud

SO/IEC 270

zovatele Sy014 Sb., vče

pů

ní bezpečnvědomí su

mu bude ná

pečnostníhodování bez

vání bezpeč

ěstnanců,

ování bezpe

za budování

zaměstnanc

za organiza

za seznámmu EET

vání bezpeému řízení b

ní bezpečno

olení bezpeč

oškolení be

blasti bezpe

ti Systémuištění bezpystému EET

ní školení bvatel zajist

h příruček

čnostní pos

stupů budeopatření

T.

čnostní pro

Systému EE

stí Systémuvání bezpede opírat o

S

01:2014 a

ystému EETetně vyhláš

nostního pbjektů účasledující:

o povědompečnostníh

čnostního p

ečnostního

í bezpečnos

ců,

aci a proved

mení zamě

čnostního pbezpečnost

osti Systému

čnosti Systé

zpečnosti S

ečnosti Sys

u EET – tvopečnosti ST.

bude pro vhí vytvoření

a zajištění

stupy a pra

e upřesněnvybraných

ovozní doku

ET;

EET čnostních informace

M

pecifikace pr

zákona č. 1

T, po určenšek NBÚ).

povědomí –astnících se

í: o povědom

povědomí,

povědomí,

stního pově

dení školen

stnanců tře

povědomí“i Systému E

u EET,

ému EET,

Systému EE

stému EET.

oří ppt prezeSystému E

hodné kategí standardn

kontinuity

avidla Systé

na na počna základ

mentace ze

příruček ve směrnic

Ministerstvo fi

rojektu Elekt

181/2014 S

ých katego

– obsahujee správy,

mí,

ědomí,

ní zaměstna

etích stran

EET,

ET,

entace a poET pro je

gorie zaměního e-lea

y Systému E

ému EET d

čátku fáze dě proved

ejména v ob

pro jednocích a o info

inancí České

ronická evide

Strana

Sb., včetně v

oriích (ČSN

e koncepci provozu a

anců provo

n s bezpeč

odkladové mednotlivé k

stnanců prorningového

EET

do nejnižší

a musí vené analýz

blastech:

otlivé role.ormace ze

é republiky

ence tržeb

a 133 z 186

vyhlášek

ISO/IEC

tvorby a užívání

ozovatele

nostními

materiály kategorie

ovedeno portálu

provozní

vycházet zy rizik,

Tvorba schůzek

s pracexistuj

V rámSystém

V této Systém

zavedč. 181

Popis

1.

Etapa

Cílem zlepšobezpepřezko

V rámkonfigEET d

Etapa

covníky, ktejících směr

ci této fázmu EET.

fázi musí bmu EET:

ení a zdoku/2014 Sb.,

požadovan

Bezpečnpro jedno(zde pro

a

3 – Monit

etapy budování. V ráečnosti Sysoumání bez

ci této eturačních a

do produkčn

3 musí obs

3.1 Přípra

eří budou znic.

ze musí bý

být provede

umentovánívčetně vyh

ných základ

nostní příruotlivé role a příklad bez

a. Bezpečn říze

řízea za

zajišbezprac

řízeprov

řízeman

akvs dů

fyzicv za

spráman

BezzpraSys

orování a p

de zavést pmci etapy stému EETzpečnosti Sy

tapy budoupenetračníc

ního provoz

sahovat nás

ava a prove

zastávat je

ýt zapracov

eny následu

í vybranýchlášek NBÚ)

ních výstup

učky a navúčastníky s

zpečnostníh

nostní příruení bezpečn

ení a klasacházení s

štění bezzpečnostníhcovníků pro

ení bezpečvozní postu

ení přístupunažera a do

izice, vývoůrazem na s

cká bezpečabezpečený

áva incidennažera.

zpečnostní acována v stému EET.

přezkoumá

postupy promusí Pos

T, postupyystému EET

u provedech testů k ou.

sledující fáz

edení auditu

ednotlivé ro

vána proble

ující úkony,

h bezpečnos).

pů

vazující possprávy a pro

ho manažera

čka bezpečnosti s důraz

sifikace aktaktivy v záv

zpečnosti o manaže

ovozu Systé

čnosti komuupy, řízení z

k systémůohled a kon

oj a údržbstanovení b

čnost a beých oblastec

ntů a řízení

příručka obdobném

ání bezpečn

o zajištění eskytovatel ny interníhoT.

ny základověření výsl

ze:

u bezpečno

S

ole. Struktu

ematika be

které jsou

stních opat

stupy definovozu Systa systému E

čnostního mzem na roli

tiv Systémvislosti na je

lidských ra při přij

ému EET.

unikací a změn, záloh

m Systémutrolu přístup

ba informabezpečnostn

ezpečnost ch.

kontinuity s

bezpečnosrozsahu ja

nosti Systé

efektivního navrhnout

o auditu b

ní bezpečledné imple

osti Systému

M

pecifikace pr

ura příruček

ezpečnosti

důležité pr

ření (ČSN I

nující konkréému EET. ZEET) je nás

manažera Sbezpečnos

mu EET sejich klasifik

zdrojů ímání, ško

provozu Shování a mo

u EET s důpových práv

ačních systních požada

prostředí s

s důrazem

stního sprako příručk

ému EET

řízení bezpa zavést m

bezpečnosti

nostní tesementace ře

u EET

Ministerstvo fi

rojektu Elekt

k musí vyc

do uživate

ro realizaci

ISO/IEC 27

étní činnostZákladní rosledující:

ystému EETstního mana

důrazem kaci.

s důrazem olení a be

Systému Eonitorování.

razem na rv.

témů v rámavků a doku

s důrazem

na povinno

rávce Syska bezpečn

pečnosti Symetriky pro a postup

ty Systémešení před s

inancí České

ronická evide

Strana

cházet ze s

elské doku

řešení bez

7001:2014 a

ti a pravidla zsah jedné

T: ažera,

na eviden

na: pozpečném o

EET s důra

roli bezpeč

mci Systémumentace.

na pravidl

osti bezpeč

stému EETnostního m

ystému EEo měření úpy pro pr

mu EET vspuštěním S

é republiky

ence tržeb

a 134 z 186

struktury

mentace

zpečnosti

a zákona

chování příručky

nci aktiv

ovinnosti odchodu

azem na

nostního

mu EET

la práce

nostního

T bude manažera

T a jeho účinnosti ravidelná

rozsahu Systému

Grafic

Fáze 3

Cílem bezpeSystém

V rámprovádV tomt

V ráms vyčlea zprabezpe

3.2. Pove

cké znázorn

3.1 – Přípra

této fáze ečnosti Systmu EET.

ci fáze buddění internto dokumen

vstupy pbezpečnopreventivČSN ISO

výstupy k zlepšovEET (dle

interní auEET vyhona bezpeISO/IEC

mci této fáeněnými praacuje zpráv

ečnosti Syst

zpracová

zahájení

edení přezk

ění činnost

EE

Obráze

ava a prove

bude zajisttému EET.

e zpracováích auditů nt Poskytov

pro zhodnoosti Systémvně nápravnO/IEC 27001

zhodnocenvání efektivČSN ISO/I

udity bezpeovují požadečnost info27001:2014

áze bude acovníky Zavu z tohototému EET S

ání program

a příprava

koumání bez

tí požadova

Etapa 3 -bez

Etapa 3 -bez

Zpracování Zpracování

ProvedeProvede

Provedení pProvedení p

Provedení záProvedení zá

ek 32: Schém

edení audit

tit prováděnFáze bude

án plán interbezpečnos

vatel uvede:

ocení, ktermu EET, ných činnos1:2014 a zá

ní, které buvnosti, změnEC 27001:2

čnosti Systdavkům na rmací a jso4 a zákon č

zpracovánadavatele bo auditu. DStrukturu au

mu auditu,

auditu – us

zpečnosti S

aných realiz

MonitorozpečnostMonitoro

zpečnost

Programu auE

Programu auE

ení Auditu bení Auditu bez

přezkoumánípřezkoumání

ákladních bezE

ákladních bezE

ma etapy 3 ř

tu bezpečn

ní kontrolní e zahrnovat

rních auditůti Systému:

ré budou zajištění zstí a dopor

ákona č. 18

udou zahrnny postupů 2014 a záko

tému EET, systém, noou funkční č. 181/2014

n program bezpečnostDále budouuditu je poža

stavení jeho

S

Systému EE

ovat v této

ování a přti systémuování a při systému

uditů bezpečET

uditů bezpečnET

zpečnosti syzpečnosti sys

í bezpečnostibezpečnosti

zpečnostníchETzpečnostníchET

řešení bezpe

nosti Systém

a auditní čt přípravu a

ů bezpečno EET a me

mimo jinézpětné vazručení pro 1/2014 Sb.,

novat jakáka potřeby

ona č. 181/

které zajistíormě ČSN I

a jsou zav Sb., a vyhl

pro prvníi Systému E připraveniadována v n

o základního

M

pecifikace pr

ET

etapě je uv

řezkoumáu EETřezkoumáu EET

nosti systémnosti systém

ystému EETstému EET

i systému EEi systému EET

h testů systémh testů systém

ečnosti Syst

mu EET

činnosti k pa proveden

osti Systémuetrik měřen

é zahrnovazby od zazlepšení be, a vyhlášky

koliv rozhodzdrojů na z

/2014 Sb., a

í, že cíle a SO/IEC 27vedeny a udlášky NBÚ)

í audit, prEET dle nori a vyškolenásledující:

o rámce,

Ministerstvo fi

rojektu Elekt

veden na ná

ání ání

mu mu

TT

mu mu

tému EET

posouzení ení interního

u EET, včetní účinnosti

at výsledkyainteresovaezpečnosti y NBÚ);

dnutí a činzajištění bea vyhlášky N

opatření be001, legisladržovány e.

rovede vzormy ČSN ISeni interní :

inancí České

ronická evide

Strana

ásledujícím

efektivního auditu bez

tně popisu přijatých o

y auditů aaných stran

Systému E

nnosti vztahezpečnosti SNBÚ);

ezpečnosti Sativě a požaefektivně ((d

orový interSO/IEC 270auditoři pr

é republiky

ence tržeb

a 135 z 186

obrázku.

provozu zpečnosti

způsobu opatření.

a analýz n, stavu EET (dle

hující se Systému

Systému adavkům dle ČSN

rní audit 001:2014 ro oblast

Popis

1.

2.

3.

4.

Fáze 3

Cílem hodno

Návrhmanag

Přúrzle

příprava jeho účas

provedenposouzenz auditov

vyhodnoczvoleným27001:20

požadovan

Plán aupřezkoumefektivno

Materiálypro provlearningo

Programzpůsob bezpečno

Zpráva zbude pos

3.2 – Prove

fáze budeotící dokume

Přezkoumgementem

návrh naEET

doporuče

návrh zm

zdroje po

doporuče

návrh cílů

řezkoumánroveň zaveepšování be

auditu – přstníků na st

ní auditu ní, zpracovvaných obla

cení auditumi kritérii au014. Výsled

ných základ

uditů bezpmávání a ovosti celého ř

y školení iedení inter

ového škole

m interníhoprovedení, osti Systém

z interního skytnout kom

edení přezk

e zpracovaent pro dalš

mání bezperesortu MF

a zlepšení b

ení ke zlepš

měny postup

otřebné pro

ení ke zlepš

ů ISMS pro

ní bezpečnedení bezpezpečnosti

říprava audtraně provo

– shromážvání a schvastí.

– bude zjiuditu – poždky budou u

ních výstup

pečnosti Svěřování beřešení bezp

interních arního audituení.

o auditu bekritéria a

mu EET.

auditu bemplexní zpr

koumání be

at Přezkoumší provoz a

ečnosti SysČR v násle

bezpečnost

šení efektivi

pů zajištění

zlepšování

šení účinnos

další cyklu

nosti Systépečnosti SySystému E

ditních podkzovatele Sy

ždění relevválení ve fo

ištěna úrovadavky na

uvedeny ve

pů

Systému ezpečnosti

pečnosti.

auditorů – u bezpečno

ezpečnostia organiza

ezpečnosti rávu o stavu

ezpečnosti

mání bezpzlepšování

stému EETdující strukt

i Systému

ity bezpečn

bezpečnos

í bezpečnos

sti opatření

us provozu b

ému EET –ystému EE

EET.

S

kladů, upřesystému EET

vantních inormě audit

veň shody abezpečnosZprávě z in

EET – stSystému E

budou tvořosti Systém

i Systému ční zajiště

Systému Eu bezpečno

Systému E

ečnosti Sybezpečnos

T bude zprtuře:

EET do da

osti Systém

sti Systému

sti Systému

bezpečnos

bezpečnost

– bude tvořET a navr

M

pecifikace pr

snění rámcT,

nformací zních zázna

aktuálního st Systému nterního aud

tanoví způEET k zajišt

it ppt prezemu EET spo

EET – buění konkrét

EET – budeosti Systému

EET

ystému EETsti Systému

racován ve

alšího přezk

mu EET a k

EET

u EET

sti Systému

ti Systému E

řit dokumenrhnout dalš

Ministerstvo fi

rojektu Elekt

e a průběh

z auditovanýamů a příp

stavu auditEET a nor

ditu bezpeč

ůsob provátění účelno

entace a poolu s přípra

de tvořit dotního (prvn

e tvořit doku EET.

T, které bu EET.

e spoluprác

koumání be

aktualizaci

EET

EET.

nt, jehož cílší postup

inancí České

ronická evide

Strana

hu auditu a

ých oblastrava závěr

tovaných obrmou ČSN čnosti Systé

ádění pravosti, dostate

odkladové mavou modu

okument prního) audit

kument, jeh

ude tvořit

ci s bezpeč

ezpečnosti S

hodnocení

lem bude zpři provoz

é republiky

ence tržeb

a 136 z 186

příprava

tí, jejich rů auditu

blastí se ISO/IEC

ému EET.

videlných ečnosti a

materiály lu do e-

ropisující tu stavu

ož cílem

základní

čnostním

Systému

í rizik

zhodnotit zování a

Poža

Monit

Všeob

davky na

toring systé

provádí n

průběžněnormální

provádí p

pořizuje z

zpracovázatížení i

provádí z

dohlíží npoložek (

plánuje a

provádí s

klasifikujeodstraňov

spoluprac

becné vlast

Konsolida

Kompletnjednotkam

Jednotné

Integracepodnikov

Drill-dowtechnolog

Nativní pService D

monitori

ému EET

nepřetržitý d

ě monitorujho stavu, s

primární vyh

záznamy pr

ává a distriinfrastruktu

zálohování d

a dodržová(Configurati

a provádí ov

správu a uc

e poruchy vání a prov

cuje s admi

tnosti moni

ace a korela

ní viditelnosmi.

é grafické p

e s externímvé/obchodní

n – vizualgie

provázanosDesk, Stora

ing a pros

dohled prov

je zejménaleduje trend

hodnocení a

rovozních u

ibuuje periry

dat podle s

ání postupůion manage

věřovací a p

hovávání lo

a odchylvádí jejich d

inistrátory p

itoringu:

ace systém

st všech KP

rezentační

mi systémy í funkce

izace od p

st s ostatníage, atd.

středí dat

vozního stav

a kvalitu a dy a reportu

alarmů a ne

událostí do T

odická hláš

chválené do

ů Řízení zmement) HW

profylaktické

ogů

lky od prookumentac

při řešení in

mových udál

PI a SLA na

prostředí a

a tzv. busin

přehledovýc

mi moduly

S

tových sá

vu a datové

dostupnosuje dosažen

estandardní

Trouble Tic

šení a rep

okumentac

měn (Chana SW a jeji

é činnosti

ovozního si prostředni

cidentů

ostí v reáln

příč aplikac

single-sign

ness contex

ch pohledů

– síťový

M

pecifikace pr

lů pro sys

é průchodno

st služeb Ení prahovýc

ích provozn

cket System

porting o do

e

ge manageich dokume

stavu, spoictvím TTS

ném čase a

cemi, síťový

n on

xt - tedy jak

ů až po de

a aplikačn

Ministerstvo fi

rojektu Elekt

stém EET

osti aktivníc

EET, odchh hodnot

ních stavů a

m (TTS)

ostupnosti

ement), Řízentace

oluvytváří p(trouble tick

“root-cause

ými segmen

k jsou techn

etailní poh

ní performa

inancí České

ronická evide

Strana

T

ch prvků

ylky param

a jejich eska

služeb a d

zení konfig

postupy prket systém)

e“

nty nebo pro

nologie napo

ledy pro k

ance mana

é republiky

ence tržeb

a 137 z 186

metrů od

alace

datovém

uračních

ro jejich )

ovozními

ojeny na

konkrétní

agement,

Konce

Metrik

SLA M

epčně exist

Businesslužbáchvyhodnoc

Consolidmanageminfrastruk

Domain security,

ky:

Objem tra

Transakč

Výkonno

Celkový z

Záznamy

Žádosti o

Monitoring

Aktuální

Procentu

tují tyto fun

s Service, aplikacíccuje SLA a

dated Operment, tedy kturou

Managemestorage, Vo

ansakcí

ční chyby

st procesů

zisk služby,

y o incidente

o změnu (‘c

stav SLA

uální poměr

Obráz

nkční bloky

Managemch, transak

celkovou vý

rations Majednotná

ent: SprávaoIP atd.

a jejich deg

, dostupnos

ech a probl

hange requ

, kdy je služ

zek 33: Moni

:

ment: Nejvcích a proýkonnost IT

nagement:správa na

a jednotlivý

gradace

st, SLA a př

émech

uest’)

žba dostupn

S

itoring systé

vyšší vrstvocesech. TT organizac

: Konsolidaad celou h

ých technol

řípadná pen

ná

M

pecifikace pr

ému EET

va, která pTato vrstvace

ce fault a pheterogenn

ogických do

nalizace

Ministerstvo fi

rojektu Elekt

poskytuje ca sleduje a

erformanceí technolog

omén jako

inancí České

ronická evide

Strana

celkový přagregované

e dat a tzv. gickou a a

jsou sítě, a

é republiky

ence tržeb

a 138 z 186

řehled o é KPI a

umbrella aplikační

aplikace,

Monit

Prostřnezáv

Do jedsítě.

Pro vzfunkci umístěSPCSresp. k

Pro vprostřejednotadmin

Síťové

Každýprotoknapř. i

Každýport. K

Požad

Prosto

a)

b)

c)

d)

e)

f)

Celkový d

Zbývající

Celková

Systémov

toring infra

ředky pro vislé adminis

dnotlivých V

zdálené připVPN kon

ěným v jednSS. Vlastní aklíč pro IPS

větší bezpeedky vložetliví uživatenistrátorem a

é prvky v ad

ý dohlížený kolových praiptables v li

ý síťový prvKonzolové p

davky na fy

ory, kde bud

) teplota p

65%,

) v místnos

tyto pros

zabezpeč

a jednotli

) prostory

či obdobn

) technolog

třídě WK

elektroma

požadavk

a. v

s

down-time s

í čas do pře

cena (pena

vá architekt

astruktury

správu a strativní sítě

VLAN logic

pojení admncentrátorunom z bezpautentizace

SEC komuni

ečnostní oden server selé umístěna terminálo

dmin síti mu

prvek je davidel na tonuxu apod.

vek je navícporty z adm

zické a tec

de datový s

prostředí se

stech, kde j

story jsou n

čovací sign

ivé uličky m

jsou vybav

ným

gické prosto

K 2 podle

agnetického

ky zajištění

všechny tec

samostatný

i. nez

služby pro d

ekročení SL

alizace) za n

tura

dohled EEě.

ckých sítích

ministrátorů . Autentizapečných see je realizovikaci.

ddělení adms termináloy na těchtovým server

usí podporo

o OOB sítěomto portu )

c připojen domin sítě jsou

hnologické

ál EET umí

pohybuje v

je datový sá

napojeny n

nalizace, a j

mezi stojany

eny stabiln

ory datovéh

e EN 162

o zařízení a

silnoproudý

chnologické

mi okruhy:

zálohovaná

dané SLA

LA

nedostupno

ET budou

jsou připoj

z prostředí ace adminigmentu adm

vána prostře

ministrátorůovými služo aplikačnírem jsou da

ovat technol

ě zapojen s(síťové pro

o OOB sítědostupné p

é zabezpeč

ístěn, musí

v rozmezí o

ál EET umís

a systém e

sou vybave

y s možnost

ím hasicím

ho sálu EET

27 s mec

a elektronic

ých rozvod

é prostory

AC síť 230V

S

ost služby

připojeny k

jovány jedn

Internetu nistrátorů jemin sítě neednictvím h

ů bude mebami. Vlasích termináata „o obraz

ogii PVLAN

samostatnýmostředky Ac

ě ještě jednpřes síťový

čení datový

odpovídat n

od 19°C do

stěn, jsou in

elektronické

eny kamero

í přisvětlen

zařízením

T musí mít i

chanickým

kého zámku

ů:

jsou vybav

V,

M

pecifikace pr

k infrastruk

notlivé kom

nebo Intrane možná pebo prostřed

esla a certi

ezi adminisstní nástrojálových servovce a kláv

N (Private V

m Ethernetccess-list, s

ím nezávislterminálový

ý sálů EET

následujícím

o 25°C, rela

nstalována

é protipožá

ovým systém

í ve tmě

s hasícím

nstalovaný

zavíračem

u s napojen

veny mezile

Ministerstvo fi

rojektu Elekt

ktuře SPCS

mponenty ad

netu slouží prostřednictdnictvím „mifikátu pro id

strátora a ve pro admverech. Převesnici“.

VLAN).

t portem s mservery loká

lým kanálemý server.

m požadavk

ativní vlhko

požární čid

rní signaliz

mem hlídaj

médiem FM

dveřní syst

m dveří, vč

ním na stáv

ehlým rozv

inancí České

ronická evide

Strana

SS prostře

dmin (Out-O

tentýž hardtvím AAA

master“ AAAdentifikaci u

vlastní sprministraci penášená da

možností nální firewally

m a to je ko

kům:

st v rozmez

dla na kouř a

zace a elek

ící vstup do

M 200, Nov

tém v bezp

četně přidrž

ající systém

aděčem se

é republiky

ence tržeb

a 139 z 186

ednictvím

Of-Band)

dware ve serveru

A serveru uživatele

ravované pak mají ata mezi

astavení y jako je

onzolový

zí 35% -

a teplotu,

ktronické

o prostor

vec 1230

ečnostní

žovacího

m EKV

e dvěma

g)

h)

i)

j)

k)

l)

m

n)

b. t

o

n

g

) požadavk

a. te

k

c

b. m

m

v

v

) požadavk

a. v

p

b. n

s

je

p

c. ř

c

m

a

d. ř

8

z

v datovém

zařízení

vlastnost

včetně b

všech čá

v datovém

a silnopro

vyšší nos

je zajiště

v týdnu, p

s datovým

datový sá

technický

) prostory,

) datové sá

které spl

metrů a j

ii. AC

technologic

okruhy urče

napájen ze

generátoru

ky zajištění

echnologick

kVA v modu

co nejblíže d

modulární ř

modulů, vče

výkonových

vzdálený do

ky zajištění

všechny tec

plánovanou

návrh řešen

systém klim

ednotlivých

provozovate

řešení klima

chladícího

modulu bez

a WWW přís

řešení chlad

800 x 1000

zařízení s p

m sálu EE

s montáží

tmi: robustn

ezpečnostn

stí stojanu,

m sálu EET

oudých roz

snost - mož

ěna vnější o

přičemž jso

m sálem EE

ál EET splň

ých prostřed

v nichž se

ály EET jso

ňují podmí

sou napáje

síť 230V zá

cké prostory

eným pro n

e zálohova

přes centrá

zálohován

ké prostory

ulární výsta

distribučníh

řešení UPS

etně řešení

modulů i

ohled (SNM

klimatizace

chnologické

kapacitu.

ní komplexn

matizačních

místnoste

ele.

atizace mus

systému, ta

přerušení

stup)

dícího systé

mm s chlad

příkonem p

ET musí bý

do 19“ liš

ní svařovan

ního zámku

T je instalov

zvodů s zátě

žnost instala

ochrana bud

ou prokazate

ET nacháze

ňují podmín

dků, ve zně

datový sál

ou z hledisk

nku, že jso

ny z různýc

álohovaná g

y jsou vybav

napájení za

né sítě ge

ální UPS jak

í silnoproud

y jsou vyba

avbě s možn

ho stojanu, n

S předpokl

redundanc

baterií be

P a WWW

e

é prostory

ního chladic

h prvků, m

ech i stoja

sí umožňov

ak ventilač

provozu. Sy

ému musí

dicím výkon

přesahujícím

ýt instalova

št o hloubc

ný rám, sta

u vpředu i v

ván systém

ěží dimenz

ace roznáše

dovy bezpe

elně evidov

ejí,

ky Vyhlášk

ění vyhlášky

EET nachá

ka geografic

ou od sebe

ch rozvoden

S

generátorem

veny distrib

ařízení ve

enerátorem

ko zdroj nep

dého napáje

aveny nepř

ností výkon

na překlenu

ádá redun

ce baterií (

ez přerušen

přístup) ,

požadujem

cího systém

modulů s

anových řa

vat redunda

čního systé

ystém vyba

zohledňova

nem 8 kW n

m 2,5 kW.

né stojany

ce 1 m a

atická zatíž

vzadu, 19“

zvýšené po

ovanou min

ecích roštů

ečnostní slu

vány osoby

ky č. 528/20

y č. 19/2008

ází, leží mim

cké lokaliza

e vzdáleny

n elektrické

M

pecifikace pr

m,

bučním stoja

stojanovýc

a druhý

přerušitelné

ení:

řerušitelným

nového rozš

utí náběhu g

daci N+1,

2 okruhy).

ní provozu

me vybavit

mu musí ob

možností

adách v pr

anci N+1 a s

ému, včetně

avit modulem

at uzavřeno

na každý sto

modelově

montážní

žitelnost 10

montážní

odlahy pro a

nimálně na

užbou nepře

vstupující d

005 Sb. o fy

8 Sb. pro st

mo zátopovo

ace umístěn

více než 6

energie,

Ministerstvo fi

rojektu Elekt

anem se dv

ch řadách,

bude nap

ého napájen

m zdrojem v

šíření na 80

generátoru

jak řídícíc

Požadujem

. UPS vyb

klimatizač

bsahovat fle

reakce na

růběhu do

střídání zák

ě možnost

m pro vzdá

ou stojanov

ojan, určené

„řady DK-

výškou 42

000 kg, čtyř

rám vpředu

aplikaci kom

850 kg/m2

etržitě 24 h

do objektu,

yzické bezp

tupeň utaje

ou oblast tz

ny ve dvou

000 metrů

inancí České

ronická evide

Strana

věma samo

jeden okru

ájen ze z

ní.,

v kapacitě

0 kVA, s um

max. 5 min

ch, tak výk

me možnost

bavit modu

čním systém

exibilní a m

změny z

by dle po

kladních mo

i výměny v

lený dohled

vou řadu se

é pro techn

-TS8“, urč

2U s násle

řbodové za

u i vzadu, z

munikační k

2, při požad

odin denně

v němž se

pečnosti a c

ení Důvěrné

v. stoleté vo

různých lo

a méně ja

é republiky

ence tržeb

a 140 z 186

ostatnými

uh bude

áložního

min. 50

místěním

n.,

konových

výměny

ulem pro

mem na

modulární

zátěže v

ožadavků

odulů, jak

vadného

d (SNMP

e stojany

nologická

čené pro

edujícími

amykání,

zemnění

kabeláže

davku na

ě a 7 dní

prostory

certifikaci

é,

ody,

okalitách,

ak 30000

o)

p)

Kapac

V datopro za

) možnost

montáže

požadova

) datové sá

�

cita datový

ovém sále Eařízení s mo

instalace s

, splňující

ané krytí IP

ály EET jso

ch sálů

EET je požontáží do 19

systému dat

fyzickou be

P56),

ou redundan

adováno um9“ lišt o hlou

tových kom

ezpečnost d

ntně připoje

místění minubce 1 m a

S

or s možno

dle Certifiká

eny na páteř

nimálně 5 smontážní v

M

pecifikace pr

ostí rozšířen

átu technick

řní infrastru

stojanů modvýškou 42U

Ministerstvo fi

rojektu Elekt

ní nebo dem

kého prostř

kturu MFČR

delově „řady.

inancí České

ronická evide

Strana

montáže a n

ředku NBÚ,

R a Internet

y DK-TS8“,

é republiky

ence tržeb

a 141 z 186

následné

, třída 2,

t

určené

Spec

Testovprovozpravidtestovv rámc

Test C

V příp

Testo

Cílem

ifikace po

vání je nedz systému

dly jako tvorvání nutné ci návrhu ap

Case je obv

test case

test case

testovací

nutné po

síla testu

test kateg

autor,

označení

výsledek

poznámk

adě testová

Testován

Testovan

vání infras

Výkonno

Integračn

Bezpečn

Disaster-

Load test

m testování

ladění sy

odstraně

nastavenaplikační

otestován

testování

otestován

otestován

otestován

ožadavků

dílnou součEET. Zabe

rba aplikacevytvořit tesplikace.

ykle tvořen

e ID,

e popis,

í kroky nebo

žadavky k v

u,

gorie,

í, jestli test j

testu (úspě

ky.

ání celého ř

ní infrastruk

ní webových

struktury v

stní testová

ní testování

ostní testov

-Recovery t

t

samotné i

ystémových

ní potencio

ní spodních ích kompon

ní obnovy s

í rozkládaní

ní přepnutí

ní monitoro

ní zálohová

na testov

částí životnezpečuje ue. Z pohledstovací příp

jedním neb

o pořadí tes

výkonu test

je automati

ěšný/neúsp

řešení EET

ktury (non-fu

h služeb (fu

sobě zahr

ání

í

vání

esty

nfrastruktu

parametrů

nálních pro

prahovýchent,

systému při

í zátěže me

do záložní

vání prostře

ání prostřed

vání systé

ního cyklu držování ku RUP jako

pady (testca

bo vícero kr

stování,

tu,

zován, neb

ěšný),

budou jedn

unctional tes

unctional tes

nuje:

ury je:

,

oblémů z po

h hodnot pro

jeho pádu

ezi jednotliv

lokality a ob

edí

í a obnova

S

ému

vývoje webkvality celého obecné mase). Je to

roky. Test c

bo ne (jestli j

notlivé testy

st)

st)

ohledu bezp

o další test

(single-poin

é kompone

bnova prim

jednotlivých

M

pecifikace pr

bových služho řešení.

metodiky proo obdoba tv

case obsahu

je možno je

y rozděleny

pečnosti, vý

tování, při p

nt-of-failure)

enty v rámci

ární lokality

h kompone

Ministerstvo fi

rojektu Elekt

žeb a výstTestování

o tvorbu apvorby přípa

uje následu

ej pravideln

do několika

konnosti,

postupné in

)

clusteru

y

nt

inancí České

ronická evide

Strana

tavby prostse řídí polikací je naadů užití (u

ující údaje:

ě spouštět)

a oblastí:

nstalaci jedn

é republiky

ence tržeb

a 142 z 186

tředí pro dobnými začátku usecase)

),

notlivých

Test D

Speciábude p

1.

2.

3.

4.

5.

6.

7.

Tyto te

K tomtestovsimulu

Zátěžo

Zátěžo

Pro spreálnýsystém

Výsledprovádzpožd

Nutno

Na záinfrast

Disaster Re

álním typemproveden k

fyzické ka

validaci p

validaci tý

validaci č

zjištění m

validaci p

validaci č

esty budou

u, abychomvací služby, ujících reáln

ový test (lo

ový test pat

samotnýc

provozníh

právně otesý provoz. Tmy povinnýc

4000 dot

100 edita

dky této zděny za pění, která v

u podmínko

hardware

propustn

výkonnos

výkonnos

ákladě výstruktury EET

covery

m funkčníhootestování

apacity infra

postupů nav

ýmu pro pro

časového p

možných ztr

postupů náv

času potřeb

prováděny

m mohli do které běží

ný provoz.

oad test)

tří mezi nefu

ch služeb,

ho prostřed

stování zátTo znamench subjektů

azů za 1s n

ačních dotaz

zátěže budpřítomnosti vznikají na k

ou zátěžové

e (využití CP

ost sítě,

sti samotné

sti aplikační

ledku zátěT a jednotliv

o testu z p:

astruktury,

vrhnutých p

ovedení jed

lánu,

rát dat při zt

vratu zpět d

bného pro n

pravidelně

statečně kví na jednotl

unkcionální

dí.

těže bude á vytvořit z, které nám

na fiskalizač

zů za 1s na

dou zpracomonitorov

komponentá

ého testu je

PU, paměť)

é služby,

ích platfore

ěžového tesvých služeb

ohledu fun

pro účely dis

dnotlivých p

trátě jedné

do primárná

ávrat do pri

podle stan

valitně otesivých komp

í testy, slou

nutné vytvozhruba až

m vytvoří zát

ční rozhraní

a portále.

ovány do facích nástách infrastru

e monitorová

),

m.

stování, bub implemen

S

kcionality E

saster-recov

procesů,

lokality,

á lokality,

imární lokal

oveného pl

stovat infrasponentách a

ží pro valid

ořit sadu k4000 tran

těž s násled

í

formy výsttrojů. Důvouktury nebo

ání jednotliv

ude identifitovaných v

M

pecifikace pr

EET je test

very,

lity.

ánu těchto

strukturu, ba zároveň

aci výkonno

klientů (poksakcí za sdujícími par

upního repodem je zo konkrétníc

vých kompo

ikováno, kdrámci EET

Ministerstvo fi

rojektu Elekt

t disaster-re

testů.

bude zapotřvytvoření v

osti:

kladen), ktesekundu simrametry:

portu. Zátězjištění jednch služeb.

onent na úr

de jsou sl.

inancí České

ronická evide

Strana

ecovery. Te

řebí vytvořvlastních “po

eří budou smulujících

ěžové testynotlivých č

ovni:

abá místa

é republiky

ence tržeb

a 143 z 186

ento test

it vlastní okladen”

simulovat pokladní

y budou časových

v rámci

Poža

K posknutné Providprostře

Takovzařízepřipojepřipojeoptickýprojekbodů nejvhosystém

Připoj

Tato mpoužij

Pojme

Pokudnucencestu

Pokudserverpřesto

dovaná a

kytování slumít zálohov

der) je nejjeednictvím p

véto připojeeních ISP. ení na více ení SPCSSými spoji). A

ktu EET jsointernetu a

odnější se mu.

jení s použ

možnost jee při adresa

enování serv

každé

všem Id je každé In si vybrat (Obrázek 3

d je adresár, ale jmennože stále vs

rchitektu

užby EET, vané připoje

ednodušší vposkytovate

ení však n Zajištění vposkytovat k síti InternArchitektura

ou rozebrána 3 možné

jeví posled

itím adres

často pouaci svých se

Obrá

verů je mož

IP adrese

P adresámP adrese pz různých p

35Obrázek 3

ám přiřazenné servery tupuje na te

I

ura připoj

u které je zení. Vícenávariantou. Pele T-Mobile

neřeší zajišvelmi vysotelů. Pro renet. Kapacia a možné ny níže. Jed

varianty přdní varianta

od více ISP

užívána. Orerverů.

ázek 34 : Sc

žné v DNS

je přiřazen

m je přiřazeřiřazeno jinpřipojení to35). V přípa

no pouze jmu vrací I

entýž odkaz

DMZ s IP adresa

WWW server

ISP 1

ení do Int

zapotřebí uásobné připoPřipojení SPe, dvěma ne

štění dostukých nárok

ealizaci projtu připojenízpůsoby redná se o připojení na a připojení

P

rganizace o

chéma zapoj

provést dvě

no jméno

eno pouzeé jméno je

o, u kteréhoadě nedostu

ediné jménP adresy sz, mívá různ

ami ISP 1

Router-1

S

ternetu p

udržet vysoojení k jednPCSS k síti ezávislými o

upnosti sluků na dostektu EET bí bude zapoealizace přippřipojení SP

vícero posprostřednic

obdrží od k

jení s použit

ěma způsob

e jediné jmépokladní sy

o má nejlepupnosti sám

no nemusí erverů v cynou odezvu

SP CSS

INTERNET

NIX

NAT

EET

M

pecifikace pr

pro systém

kou dostupnomu posky

Internet jeoptickými sp

žby v přípaupnost je

bude zapotřotřebí navýšpojení SPCPCSS do dskytovatelůctví vlastníh

každého po

tím adres ví

by:

éno ystém povinpší odezvu

m musí zkus

sice POS yklu (tzv. rou podle toho

DMZ s IP adre

Router-2

W

Ministerstvo fi

rojektu Elekt

m EET

pnost fiskaliytovateli (IS v současnpoji o rychlo

adě problémožné do

řebí navýšitšit na 2 x 1G

CSS k síti Indvou nezáv

připojení kho autonom

oskytovatele

íce ISP

nného subje. Sám POS

sit připojení

vyhledávaound robin)o, kterou IP

esami ISP 2

WWW server

ISP 2

inancí České

ronická evide

Strana

začních seSP - Internet

é době reaosti 100 Mb

ému na hrosáhnout pt kapacity aGb/s (1Gb/s

nternetu provislých přístk síti Internmního směr

e blok adre

ektu (dále jeS si vybírá na další se

t nejlépe d. Stává se adresu dos

é republiky

ence tržeb

a 144 z 186

erverů, je t Service

alizováno it/s.

raničních ouze při

a způsob s dvěma

o potřeby tupových net. Jako rovacího

es, který

en POS) nejlepší

erver.

dostupný tedy, že stane od


jmennostatnnemuspro PO

Tato va mož

ného serverních cest (Osí být zpoždOS obtěžují

varianta tudžnost provoz

ru. NejlepšObrázek 35O

dění nijak dící.

íž není přílizování bez

POS

í připojení Obrázek 35dramatické,

Obrázek 35

iš vhodná pnutnosti na

DMZ s IP adre

ISP 1

WWW server

je přímo u5 - modré ce, ale zpožd

: Schéma p

pro poskytovadstandardn

esami ISP 1

Router-1

S

u ISP (Obráesty) již docění na vytíž

přístupu POS

vání služební spoluprác

INTERNET

NIX

NAT

EET

SP CSS

M

pecifikace pr

ázek 35Obchází ke zpžených zah

Su k serverů

b EET. Její ce s ISP.

DMZ s IP ad

Router-2

Ministerstvo fi

rojektu Elekt

rázek 35 -poždění. Přhraničních l

ům

výhodou je

dresami ISP 2

ISP 2

WWW server

inancí České

ronická evide

Strana

červená ci připojení pinkách již m

však jedno

é republiky

ence tržeb

a 145 z 186

cesta). U přes NIX může být

oduchost

Nafor

Nafor

rmátováno:

rmátováno:

Čeština

Čeština

Připoj

MnoheposkytPOS v

Tato vnadstaprotok(Borde

Je nuti v ostdo intsměroadresypředáv

jení s použ

em efektivntovatele přivždy k serve

varianta je andardní spkolu. Z důvoer Gateway

tné zajistit datních sítíchernetu stan

ovací informy přidělenévat hraničn

itím adres

nější než připojení (Oberům přistu

Obrázek

mnohem vpolupráci sodu zamezey Protocol).

Obrázek 37

domluvu a sh (Obrázekndardním z

mace o blok poskytovaím směrova

A

jednoho z

ředchozí varázek 36Obpuje pouze

36 : Schém

vhodnější p poskytovat

ení nežádou

7 : Schéma z

souhlas ISPk 37Obrázekpůsobem(mu adres z p

atelem ISP1ačům ISP1

ISP 1

ISP 1

AS1000

AS

ISP

arianta je vybrázek 36). jedinou ce

a zapojení p

pro komunikteli připojenucího propo

zapojení s p

P k šíření blok 37). ISP modré šipkyprivátního a1. Tito osta(červené ši

DMZ s

WRouter-1

DMZ s I

WW

IN

Propagace celéhadresního rozsahu I

S65001

Router-1

S

yužít připoje. Díky jedinstou, která

pouze s IP a

kaci mezi sní. Také jižojení mezi s

oužitím smě

oku adres, 1 jehož adry). Do sítě utonomního

atní poskytopky).

SP CSS

IP adresami ISP 1

WWW server

INTERNET

NIX

EET

NAT

SP CSS

P adresami ISP 1

WW server

NTERNET

NIX

EET

NAT

Propaz adresního

hoSP 1

M

pecifikace pr

ení s adresnnému adresse za norm

adresami jed

systémem ž vyžaduje sítěmi ISP je

ěrovacího p

který je přidresy jsou podalších po

o systému Aovatelé moh

1

Router-2

z ad

agace adreso rozsahu ISP 1

Router-2

Ministerstvo fi

rojektu Elekt

ním prostorsnímu prostmálního stav

dnoho z ISP

EET a POpoužití vně

e téměř nez

protokolu BG

dělen jednooužity šíří smskytovatelůAS65001, vhou tyto sm

ISP 2

ISP 2

Propagace adresdresního rozsahu ISP

AS2000

inancí České

ronická evide

Strana

rem pouze jtoru je zajišvu nemění.

OSem, ale vějšího směrzbytné použ

GP

omu z poskyměrovací inů se po dohv němž jsouměrovací in

P 1

é republiky

ence tržeb

a 146 z 186

jediného štěno, že

vyžaduje rovacího žití BGP

ytovatelů nformace hodě šíří u použity nformace

Nafor

Nafor

rmátováno:

rmátováno:

Čeština

Čeština

Poskyk serv

Předáposkyt39Obr

Poskyale nneodpEurop

Mimo 2) a muvede

ytování směverům i POS

vání směrotovatele ISPrázek 39).

ytování směemusí vžd

povídají doéens).

jiné akceptmenší blokyeného v data

ěrovacích iSům připoje

Obr

ovacích infoP1 vytváří z

Ob

ěrovacích indy fungovaporučení a

tují směrovay ignorují. Dabázích or

POS

POS

nformací zeným prostř

rázek 38 : Sc

ormací o bzáložní spoj

brázek 39 : S

nformací jint. Většina

a informac

ací informaDále mohoganizace R

ISP 1

ISP 1

Výpadek linky

z privátního ednictvím tě

chéma toku

bloku adresjení pro příp

Schéma toku

ným poskytISP totiž

ím uveden

ace s minimu akceptov

RIPE.

DMZ s

Router-1

DMZ s

Router-1

S

AS dalšíměchto ISP (

dat za norm

s použitém padný výpa

u dat při výp

ovatelům nkontroluje

ných v data

málním prefivat směrova

SP CSS

s IP adresami ISP

INTERNET

NIX

EET

NAT

WWW server

SP CSS

s IP adresami ISP

INTERNET

EET

NAT

WWW server

NIX

M

pecifikace pr

m poskytovObrázek 38

málního stav

v privátnímadek linky m

padku linky

nebo do ob a filtruje

abázích org

xem /19 přací informa

1

POS

Router-2

1

POS

Router-2

Ministerstvo fi

rojektu Elekt

vatelům um8Obrázek 3

vu sítě

m AS na hmezi organiz

k ISP

ecně internsměrovac

ganizace R

řípadně /20 ace o síti p

ISP 2

POS

ISP 2

POS

inancí České

ronická evide

Strana

možní přímý38).

hraniční smzací a ISP (

netu je sicecí informacRIPE (Rés

(Tabulka 2okud přichá

é republiky

ence tržeb

a 147 z 186

ý přístup

měrovače Obrázek

e možné, e, které eaux IP

2Tabulka ází z AS

Nafor

Nafor

Nafor

rmátováno:

rmátováno:

rmátováno:

Čeština

Čeština

Čeština

početpočet

prefixmask

Tabulka 2 :

t bitů t adres

x a

Počeadre

1

2

4

8

16

32

64

128

256

512

1K

2K 4K

8K

16K

32K

64K

128K256K

512K

1M

2M

4M

8M 16M

32M 64M

128M

256M

512M

1024: Označován

Velikost pMnožství paměti, žadresy (rezervováDélka smSíťová mačísel oddě

et s

Pbi

0

1

2

3

4

5

6

7

8

9

10

1112

13

14

15

16

K 17K 18

K 19

20

21

22

2324

2526

M 27

M 28

M 29

4M 30ní velikosti a

přiřazenéhodostupný

e normálnsamé nu

ány. ěrovacího aska definělených te

očet itů

Pr

/32

/31

/30

/29

/28

/27

/26

/25

/24

/23

0 /22

1 /212 /20

3 /19

4 /18

5 /17

6 /16

7 /158 /14

9 /13

0 /12

1 /11

2 /10

3 /9 4 /8

5 /7 6 /6

7 /5

8 /4

9 /3

0 /2 adresního p

o adresníhých adres ně je početly, samé

předčíslí (nující směrčkou.

S

efix Mask

2 255.2

1 255.2

0 255.2

9 255.2

8 255.2

7 255.2

6 255.2

5 255.2

4 255.2

3 255.2

2 255.2

1 255.20 255.2

9 255.2

8 255.2

7 255.2

6 255.2

5 255.24 255.2

3 255.2

2 255.2

1 255.2

0 255.1

255.1255.0

254.0252.0

248.0

240.0

224.0

192.0rostoru a sm

ho prostorupři použit

t stanic o jedničky

(routing prrovací pře

M

pecifikace pr

ka

255.255.25

255.255.25

255.255.25

255.255.24

255.255.24

255.255.22

255.255.19

255.255.12

255.255.0

255.254.0

255.252.0

255.248.0255.240.0

255.224.0

255.192.0

255.128.0

255.0.0

254.0.0 252.0.0

248.0.0

240.0.0

224.0.0

192.0.0

128.0.0 0.0.0

0.0.0 0.0.0

0.0.0

0.0.0

0.0.0

0.0.0 měrovacího

u v bitechté masce.2 nižší, pr

v části

refix) adresdčíslí (rou

Ministerstvo fi

rojektu Elekt

55

54

52

48

40

24

92

28

předčíslí (r

. Je všakrotože nejnoznačující

sního prosting prefix

inancí České

ronická evide

Strana

outing prefi

k nutné mnižší a nejí stanici)

toru. x) ve formě

é republiky

ence tržeb

a 148 z 186

x)

ít na vyšší jsou

ě čtyř

Při dose zákv přípa

Při pobudouNIXu p

V přípposkytRIPE.

Připoj

Z hledvarianvšech zapotř

držování prkazníci nebadě ztráty k

oužití této vu adresy popřes více sm

adě potřebtovatele be

jení s vlastn

diska technnta řeší vše

ISP, se kteřebí jiné nas

ravidel a dobudou mocikonektivity d

Obrázek 40

varianty je oužity. Je veměrovačů. P

by je možnéez nutnosti

ním autono

nického seechny nevýerými je totstavení smě

POS

oporučení jei připojit (Odo NIXu.

0 : Schéma

potřeba veelice žádouPotom nebe

é požádat přeadresov

omním sys

e jeví variaýhody předto domluveněrování než

Obrázek 4

ISP 1

Výpad

ISP 1

AS1000

A

Propagace adresz AS3000

e tedy možnObrázek 40O

toku dat při

elice dobřecí aby tentoezpečí nedo

o „providervání. Při př

témem

anta s vlasdchozích vano. Za všecž je uvedeno

41 : Schéma

DMZ s

ek linky

Router-1

DMZ

W

AS3000

Propagace adresz AS3000

Router-1

S

né, v případObrázek 40

výpadku za

e vybírat poo ISP měl zostupnosti s

r independeřechodu sta

stním autoariant. Směch okolnosto v databáz

a zapojení s

SP CSS

s IP adresami ISP

INTERNET

NIX

EET

NAT

WWW server

SP CSS

s vlastním IP adresami

WWW server

INTERNET

NIX

EET

NAT

Propagz AS

M

pecifikace pr

dě ztráty ko0). Obdobn

ahraniční ko

oskytovatelezálohovanoserveru kles

ent“ adresyačí pouze z

nomním syěrovací infotí jsou dodrzích RIPE.

vlastním AS

1

POS

Router-2

i

Propaz

A

ace adresS3000

Router-2

Ministerstvo fi

rojektu Elekt

onektivity ISé problémy

onektivity IS

e, z jehož ou konektivisá na minim

y, které umzměnit záz

ystémem jormace jsorženy dopo

S

ISP 2

POS

ISP 2

agace adresAS3000

AS2000

inancí České

ronická evide

Strana

SP1 do intery by mohly

SP

adresního itu do internmum.

možní rychleznamy v da

jako nejlepou propagoručení RIPE

é republiky

ence tržeb

a 149 z 186

rnetu, že nastat i

prostoru netu i do

e změnit tabázích

pší. Tato vány od E a není


Za lib(Obrázzahran

ovolného szek 42Obrániční konek

stavu je proázek 42, Oktivity ISP n

Obr

Ob

POS

POS

o směrovánObrázek 43nedojde k ne

rázek 42 : Sc

brázek 43 : S

ISP 1

AS1000

A

ISP 1

AS1000

AS

ní provozu 3Obrázek 4edostupnos

chéma toku

Schéma toku

DMZ s

AS3000

Router-1

DMZ s

S3000

Router-1

S

mezi POS43 a Obrázsti služby E

dat za norm

u dat při výp

SP CSS

vlastnímiIP adresami

INTERNET

NIX

EET

NAT

WWW server

SP CSS

s vlastnímiIP adresami

INTERNET

NIX

EET

NAT

WWW server

M

pecifikace pr

Sem a EETzek 44ObráET.

málního stav

padku linky

POS

Router-2

POS

Router-2

Ministerstvo fi

rojektu Elekt

T hledána názek 44). A

vu sítě

k ISP

ISP 2

AS2000

POS

ISP 2

AS2000

POS

inancí České

ronická evide

Strana

nejvýhodnějAni v případ

é republiky

ence tržeb

a 150 z 186

jší cesta dě ztráty Nafor

Nafor

Nafor

rmátováno:

rmátováno:

rmátováno:

Čeština

Čeština

Čeština

Pro prCoord

Tato v

U menvelcí ps dost

Hraničsměro

Je nuk přetěv přípapřijíma

rovozování dination Cen

varianta je

nších sítí jsposkytovatetupností do

ční směrovaovačů. S ros

utné dosáhěžování smadě několikat směrovac

Obrázek 44

vlastního Antre).

z hlediska

sou přidělenelé, předevštěchto sítí.

ače by mělstoucími ná

hnout maximěrovačů. Pkeré změnycí informace

POS

4 : Schéma

AS je nutné

dodržován

ny rozsahy ším v USA,

y mít plné roky roste c

imální stabProto má věy směrovace z těchto s

ISP 1

AS1000

A

toku dat při

podat žádo

ní pravidel

adres jejich tato dopor

směrovací cena zaříze

bility hraničětšina ISP cích informasítí. Po tuto

DMZ s

AS3000

WRouter-1

S

výpadku za

ost na RIPE

nesprávně

hž samostaručení obča

tabulky. Toení.

čních směnakonfiguroací v krátkédobu budo

SP CSS

vlastnímiIP adresami

INTERNET

NIX

EET

NAT

WWW server

M

pecifikace pr

ahraniční ko

E NCC (Ré

ější. Přináš

tné směrovas nerespek

o klade vyso

rovačů. Růovám ochraém čase přu problémy

A

POS

Router-2

Ministerstvo fi

rojektu Elekt

onektivity IS

éseaux IP E

ší však i ně

vání je dopoktují a moh

oké nároky

ůzné nestaanu proti „nřestane, nay s dostupno

ISP 2

AS2000

POS

inancí České

ronická evide

Strana

SP

Européens

ěkteré prob

oručováno. ou nastat p

y na paměť

ability mohnestabilním a nastavenoostí některý

é republiky

ence tržeb

a 151 z 186

Network

blémy.

Bohužel problémy

a výkon

hou vést sítím“ a

ou dobu, ých sítí.

AnaCílem dopadnásledvybran

Něktes omeopatře

Řízentýmu. závažeskalo

Identifnásled

První význakteré j

Ident

Jednímsvého

A.B.C.D.E.F.G

Následnastatcelkovapod.)

Kód

A.1

A.2

A.3

alýza rizřízení rizi

dů a celkovédků při reáná opatření

rá identifikoezenými opaení (zejmén

í rizik projeTuto činnoná rizika, jeována k pos

fikace a vydujících sub

fází analýzmných rizikje prováděn

tifikace ri

m z význam charakteru

. právní riz

. finanční r

. technická

. personáln

. provozní bezpečno. projektov

dující tabult v průběhuvého projek).

Riziko

Nedod

Neschsystém

Nevhoautorsatd.

zik k je identifé závažnoslném uplatnplánována

ovaná rizikatřeními) s a nároky na

ektu provádost koordinuejich dopadsouzení a p

hodnocení bkapitol.

zy rizik je idk. Následnno na základ

zik

mných aspeu rozdělit do

zika; rizika; á rizika; ní rizika; rizika;

ostní rizika;vá rizika.

lky předstau přípravy ktu. Pro zvý

o

držení právn

hopnost udmu nebo jeh

odné smluské právo,

fikace a spti a vymezenění danéh v rámci pro

ka mohou bohledem n

a časové, fi

dí průběžněuje projektody a návrhyřípadnému

rizik a op

dentifikace pou druhou dě hodnoce

ektů řízení o předem de

avují výsledči realizac

ýšení přehle

ních norem

držet legisho částí

uvní podmsankce, ná

pecifikace jení vhodnýcho rizika. Nojektu.

být záměrnna přílišnounanční a lid

ě Vedení řeový manažey na jejich rozhodnutí

patření přija

potenciálnícfázi analý

ení míry dop

rizik je ideefinovaných

dný sezname předkládednosti byla

Právn

ČR, EU.

lativní sho

mínky, naáhrada ško

S

jednotlivýchch opatření

Na základě

ně akceptou (danému dské zdroje)

ešitelských er tak, aby řešení či o

í ŘK projekt

atá pro jej

ch rizik, kteýzy předstapadu a prav

entifikace (dh klasifikačn

m identifikovdaného proja jednotlivá

ní rizika

Dopad

Zpoždnebo náhrad

odu Snížennevymkompr

apř. ody

Alternaprojektnevym

M

pecifikace pr

h rizik projna prevencidentifikace

vána bez jriziku nead).

týmů a konse plně pro

omezení jstu.

jich násled

erá spočívá avuje vyhodvděpodobno

definice) poních skupin

vaných potojektu, ale á rizika ozn

d

ění projekprotiprávno

dy škody.

ní nebo možitelnosti

omitace pro

ativní řešetových potř

možitelnost n

Ministerstvo fi

rojektu Elekt

jektu včetnci daného re a specifik

jakýchkoli dekvátní) n

nsoliduje Vošetřila moou neprodl

dnou elimin

v zjištění adnocení ideosti výskytu

otenciálních:

tenciálních i v průběhuačena kóde

tu z důvodost části p

absence ppovinností

ojektu samo

ení technřeb za zvýšnáhrady ško

inancí České

ronická evide

Strana

ně posouzerizika nebo okace jsou n

opatření (náročnost n

edení projeožná rizika. eně předkl

naci jsou o

a následné entifikovanýu rizika.

rizik, která

rizik, kteráu běžného em (např. A

du nápravyprojektu a

přínosů zí poplatníkotného.

ických a šenou cenuody a sankc

é republiky

ence tržeb

a 152 z 186

ení jejich omezení následně

nebo jen ěkterých

ektového Zjištěná

ádána a

obsahem

evidenci ých rizik,

á lze dle

á mohou provozu

A.1, B.3,

y stavu možné

důvodu ů nebo

jiných u, nebo cí.

Kód B.1

B.2

B.3

Kód C.1

C.2

C.3

Kód

D.1

D.2

D.3

D.4

D.5

D.6

Kód E.1

E.2

E.3

Riziko

Nedospředpo

Navýša dalš

Růst pprojek

RizikoVýběr

Výběr

Riziko(pře/po

Riziko

Nedosv proje

Nedos

Nedospracov

Fluktuprovoz

Závislozaměs

Nedosspecif

Riziko

Neschv požaNenapv prov

Rizikovztahu(závis

o

statečné úokladů návr

šení cen tecích vstupů.

provozních ktu.

o nekvalitníh

nevhodné

o souvisoddimenzov

o

statečná ektovém tým

statečný vni

statek kvavní síly v pr

ace zamězu projektu.

ost na specstnancích d

statečné zického know

o

hopnost kooadovaném čplnění dvozní fázi pr

o spjaté su údržby lost na dod

údaje pro ratnosti

chnologií, s

nákladů v

ho dodavate

technologie

sící se vaná kapac

delegace mu.

itřní kontrol

alifikované rovozní fázi

stnanců za.

cifických zaodavatele.

znalosti nw-how.

ordinace rozčase a rozsdodavatelskrojektu.

s nastaveníma provoz

avateli)

Finanč

vyhodnoc

služeb a pr

provozní f

Technic

ele.

e.

zařízencita / výkon)

Person

kompete

ní systém.

a kval.

apojených

městnancíc

ebo potře

Provoz

zvoje systésahu kých sm

m smluvnzu systé

S

ční rizika

Dopad

ení Nemožstránky

rací Zvýšenzvýšenv realiz

fázi Zvýšen

cká rizika

Dopad

Ohrožea prodzvýšenstavu.

OhrožeprojektRiziko náprav

ním )

Komprlegisla

ální rizika

Dopad

ncí NeefekOhrožeběžnéh

NeefekOhrožeprovoz

itní Ohrože

do Nedosfungov

ch / OhrožeZvýšen

eba ZvýšenOhrože

zní rizika Dopad

mu Ohrože

mluv Ohrože

ího mu

Zvýšenkvalita

M

pecifikace pr

d

žnost vyhy, částečná

ní celkovýcní nároků zační fázi pní provozní

d

ení kvaloužení

ných náklad

ení kvalitytu vůbec,

zvýšenýchvu stavu.

romitace ptivní povinn

d

ktivní fungení přípravho provozu

ktivní fungení realizzu.

ení běžnéh

statečně kvání.

ení projektné náklady

né nákladyení kvalitati

d ení běžnéh

ení běžnéh

né nákladtivní úrovně

Ministerstvo fi

rojektu Elekt

hodnotit pá kompromit

ch nákladů na fina

projektu. náročnosti

ality výdoby re

dů (dodateč

y výstupuprodloužen

h nákladů

projektu, nnosti za stra

gování provy a real.

gování proace proje

o provozu.

kvalitní pe

tu, nebo bna projekt n

y na projevní úrovně

o provozu.

o provozu.

dy na pě provozu.

inancí České

ronická evide

Strana

projekt z ftace projekt

projektu a zancování p

.

stupu pealizace. čných) na n

u projektuní doby re(dodatečný

neschopnosany státu.

ojektového izace proje

ojektového ektu či b

rsonální z

běžného pnebo provo

ekt nebo projektu.

provoz. O

é republiky

ence tržeb

a 153 z 186

finanční tu.

zároveň projektu

projektu Riziko

nápravu

nebo alizace. ých) na

st plnit

týmu. ektu či

týmu. běžného

zajištění

provozu. oz.

provoz.

Ohrožení

Kód F.1

F.2

F.3

F.4

Kód G.1

G.2

G.3

G.4

G.5

G.6

G.7

Hodn

Druhopravdškálác„D“ a p

Hodn

1

2

3

4

5

RizikoKráde

Terorisútoku)

Bezpe

Nedodz legisutajov

RizikoNedos

Neschkvalitypřebíra

Dodat

Špatná

Zpoch

Škodyškody medianezáv

Nedod

nocení riz

ou fází anaděpodobnoch (stupnicípravděpodo

nota

o ž technolog

stický útok).

ečnostní rizi

držení poslativy, zejmaných skute

o statky v proj

hopnost ey dodanýcaní výstupů

ečné změn

á koordinac

hybnění vali

y z nedosspojené

alizovaného islého výbě

držení term

zik

lýzy rizik jeosti výskytích) s definobnost výsk

Dopa

Téměř nez

Drobn

Význam

Velmi význ

Nepřijat

gií nebo jejic

k (včetně k

ika

ovinností ména zákonečností.

jektové dok

expertního ch služebů dodavatele

y v projektu

ce dodavate

dity projekt

tatečné sos reputací

ěru dodavat

ínu realizac

e její vyhotu „P“ rizinovaným výkytu rizika „P

ad

znatelný

ný

mný

namný

telný

Bezpečn

ch poničení

ybernetické

vyplývajícnu o ochra

Projekt

kumentaci.

zhodnocb (částeče)

u.

elských pra

u

outěže anena záklazpochybn

ele

ce.

odnocení, kika. Obě významem jP“ jsou hod

Pra

Té

Výj

B

P

Hra

S

ostní rizika

Dopadí. Znemo

resp. n

ého Ohrožeponičeohrožeprojekt

Komprnarušedůvěrn

cích aně

KomprkomprzvýšenŠkody utajova

ová rizika

DopadMůže d

ení čné

Může služeb

Dodatedobu realiza

cí. Zpoždkvality Komprprojekt

ebo adě ění

Zpochopakov

Zpoždplánov

které spočíveličiny jsojednotlivýchnoceny dle

avděpodobvýskytu

éměř nemož

ýjimečně mo

Běžně možn

ravděpodob

aničící s jist

M

pecifikace pr

a

d

ožnění pronutnost její o

ení běžnení technoení z hledistu.

romitace ení bezpečnosti nebo i

romitace omitace pné náklady.značného

aných skute

d dojít k celko

dojít k akb nebo jejich

ečné změnyrealizace

aci.

ění zahájedodaných

romitace ptu.

ybnění reavání soutěž

ění zahájvaných příno

ívá v určenou hodnoceh bodů škástupnice uv

bnost

žná

ožná

ná

bná

totou

Ministerstvo fi

rojektu Elekt

ovozování dopravy.

ého provologií a ka reputace

bezpečnčnosti v obntegrity dat

bezpečnprojektu, zm rozsahu v p

ečností.

ovému zpož

kceptaci neh částí.

y by mohly projektu

ení provozprací/služeprojektu a

alizátora pží, nebo zpo

jení provoosů. Nesho

ní míry doeny v kvaliály. Míra dovedené v n

Mírapravdě

Ve

S

V

Vel

inancí České

ronická evide

Strana

dané techn

vozu. Nebsystému.

e a důvěryh

ostních blasti dostut.

ostních měny proj

případě pro

ždění realiz

ekvalitního

y významněa ohrozit

u. Riziko b/technolog

a nesplně

projektu, poždění proje

ozu. Nedooda s legisla

opadu „D“tativních bopadu (vlivásledující ta

a dopadu/ ěpodobnoselmi malá

Malá

Střední

Vysoká

mi vysoká

é republiky

ence tržeb

a 154 z 186

nologie,

bezpečí Možné

hodnosti

prvků; upnosti,

prvků; jektu a

ozrazení

zace.

díla a

ovlivnit t jeho

snížení gií. ní cílů

případné ektu.

osažení ativou.

rizika a bodových vu) rizika abulce:

sti

Z hledjednouZ tohosoučin

�

�

�

Význadle nárizik je

Pro úkatego

Cílem míru d

Následv průb

Kódrizik

A.1 A.2

A.3

B.1

B.2

B.3

C.1

C.2

C.3

diska efektu konkrétní oto důvodu n bodového

�

amnost rizikásledující tae v grafické

spěšné řízorie „Kritická

této podkadopadu, pra

dující tabulkběhu příprav

�d ka

Nedod

Neschsystém

Nevhoautors

Nedospředpo

Navýšdalších

Růst projekt

Výběr

Výběr

Riziko (pře/po

ivity řízení hodnotou),byl pro každ

o ohodnocen

ka „V“ lze nabulky). Dispodobě zp

StBě

Zá

Kr

zení rizik jeá rizika“), kt

apitoly tedyavděpodobn

ka představvy a realiza

držení právn

hopnost umu nebo jeh

odné smlké právo, s

statečné úokladů návr

ení cen tech vstupů.

provozních tu.

nekvalitníh

nevhodné t

souvisoddimenzov

rizik je nu který zahrndé riziko staní dopadu r

na základě stribuce dosracována fo

upeň význěžné

ávažné

itické

e nejdůležiterá je nutn

y bylo vytvonost výskytu

vuje výslednce předklád

Riziko

ních norem

držet legiho částí

uvní podsankce, náh

údaje proratnosti

chnologií, s

nákladů v

o dodavate

technologie

sící sevaná kapac

utné pro kanuje jak míranoven stuprizika „D“ a

dosažitelnýsažených hormou mapy

amnosti

tější zaměné co nejdřív

oření tzv. kau a význam

ný katalog rdaného proj

PrávnČR, EU.

islativní s

dmínky, hrada škody

Finanč

o vyhodno

služeb a pra

v provozní

Technicele.

e.

e zařízcita / výkon)

V =

S

aždé riziko ru dopadu rpeň význampravděpodo

ých hodnot hodnot význy rizik (viz k

řit se na rve eliminov

atalogu riznost rizik.

rizik – souhjektu, ale i v

Mdo

ní rizika

hodu

např. y atd.

ční rizika

ocení

ací a

í fázi

cká rizika

ením )

D x P

M

pecifikace pr

stanovit jerizika, tak i mnosti rizikobnosti výs

klasifikovatnamnosti rizkapitola „Ma

Hodnota 1 – 4

5 – 11

12 – 25

rizika nejzávat nebo ale

zik, ve které

hrn potenciáv průběhu b

Míra padu

Mí

5 5

3

1

2

3

3

4

4

Ministerstvo fi

rojektu Elekt

eho význampravděpodoka „V“, ktekytu rizika „

t dle do 3 szika „V“ u vapa rizikMa

ávaznější (espoň minim

ém jsou uv

álních rizik, běžného pro

íra pravděpvýskytu

1 1

2

3

3

3

3

4

3

inancí České

ronická evide

Strana

m (interpretobnost jeho

erý je defino„P“.

skupin (vizvšech definpa rizik“).

rizika spadmalizovat.

vedeny hod

která mohoovozu.

p. Stupvýznam

53

6

3

6

9

9

16

12

é republiky

ence tržeb

a 155 z 186

tovatelný o výskytu. ován jako

stupnice ovaných

dající do

noty pro

ou nastat

peň mnosti

5 3

6

3

6

9

9

6

2


Kódrizik

D.1

D.2 D.3

D.4

D.5

D.6

E.1

E.2

E.3

F.1

F.2

F.3

F.4

G.1

G.2

G.3

G.4 G.5

G.6

G.7

d ka

Nedosv proje

Nedos

Nedossíly v pFluktuaprovoz

Závislozaměs

Nedosspecifi

Neschv požaNenapv provo

Riziko vztahuna dod

Krádež

Terorisútoku)Bezpe

Nedodz legisutajova

Nedos

NeschdodanvýstupDodate

ŠpatnáZpoch

Škodyspojenmediavýběru

Nedod

statečná ektovém tým

statečný vni

statek kvalifprovozní fázace zamězu projektu.

ost na spestnancích do

statečné ického know

hopnost kooadovaném čplnění ozní fázi pr

spjaté u údržby a pdavateli)

ž technolog

stický útok.

ečnostní rizi

držení pslativy, zejmaných skute

statky v proj

hopnost expých služe

pů dodavateečné změny

á koordinacybnění valid

y z nedostatné s replizovaného u dodavatel

držení termí

Riziko

delegace mu.

třní kontroln

fikované a kzi. ěstnanců z

ecifických zodavatele.

znalosti w-how.

ordinace ročase a rozsadodavatels

rojektu.

s nastavenprovozu sys

gií nebo jejic

k (včetně

ka

povinností ména zákoečností.

jektové dok

pertního zhoeb (částkele) y v projektu

ce dodavatedity projektu

tečné soutěputací zpochybně

e

ínu realizac

Person

kompe

ní systém.

kvalitní prac

zapojených

zaměstnanc

nebo pot

Provoz

ozvoje sysahu kých s

ním smluvstému (záv

Bezpečnch poničení

kybernetic

vyplývajonu o och

Projektkumentaci.

odnocení kvkové přeb

u.

elských pracu

ěže anebo šna zákění nezávis

ce.

S

Mdo

ální rizika

etencí

covní

h do

cích /

třeba

zní rizika

tému

smluv

vního islost

ostní rizikaí.

ckého

jících hraně

ová rizika

vality bíraní

cí.

škody kladě slého

M

pecifikace pr

Míra padu

Mí

2

2 2

2

2

2

3

2

1

a 3

5

3

5

1

4

3

3 3

1

5

Ministerstvo fi

rojektu Elekt

íra pravděpvýskytu

3

2 5

2

4

5

1

2

5

1

2

5

2

3

3

5

3 2

2

2

inancí České

ronická evide

Strana

p. Stupvýznam

6

410

4

8

10

3

4

5

3

10

15

10

3

12

15

96

2

10

é republiky

ence tržeb

a 156 z 186

peň mnosti

6

4 0

4

8

0

3

4

5

3

0

5

0

3

2

5

9 6

2

0

�Mapa rizik sloužMapa rizik je pidentifikovanýchvzájemného sou

Mapa

Do

pad

Nepřijat

Velmi výz

Význam

Drobn

Téměneznate

ží ke grafickémupromítnuta v nás rizik spadá do

uběhu negativně

rizik

telný 5

namný 4

mný 3

ný 2

ěř elný

1

znázornění katasledující tabulceo kategorie „Běž

ovlivnit projekt.

Téměř nem

1

A.1 A

E.1 F

alogu rizik – mír, ve které je zožná rizika. Přes

možná Vý

A.2

.1

Stránka 15

Mapa ri

ry dopadu „D“, pobrazeno rozložto bude kladen

ýjimečně možná

2

F.2 F.4 G.7

A.3 G.5

D.2 D.4 E.2

G.6

57 z 186

izik

pravděpodobnostžení jednotlivých

důraz na elimi

Pravděpo

á Běžně

3

C.3

B.3 C

B.2

B.1

ti výskytu „P“ a sh rizik do definoinaci všech iden

odobnost

možná

3

G.2

.1 G.4

D.1

G.1

stupně významnovaných kategontifikovaných riz

Pravděpodobná

4

C.2

D.5 D.6

nosti „V“ identifikrií významnosti zik, protože moh

á Hraničí

G

kovaných rizik. rizik. Nejvíce

hou v případě

cí s jistotou

5

G.3F.3

D.3

E.3



Strana 158 z 186

Eliminace rizik

�Na analýzu rizik navazují opatření, jejichž cílem je úplná eliminace potenciálních rizik nebo

alespoň jejich minimalizace do podoby, která již projekt zásadně neovlivní a neohrozí jeho průběh. Taktika řízení rizik spočívá ve výběru nejvhodnějšího postupu pro zvládání příslušného rizika. Zvládání rizika spočívá obecně ve snižování jeho dopadu anebo jeho pravděpodobnosti výskytu. Pro kritická rizika se stanovují tzv. generické taktiky k jejich zvládnutí výběrem jedné z dále uvedených metod:

► vyloučení rizika – zákaz vybraných rizikových aktivit a procesů;

► snížení rizika – snížení velikosti dopadu např. pojištěním rizika;

► přenos rizika – redukce rizika snížením pravděpodobnosti nežádoucích událostí;

► přijetí rizika – akceptace rizika na stávající úrovni bez dalších aktivit.

Volba základní taktiky vychází z disponibilních možností, jakými vůbec lze v principu snížit

dopad a pravděpodobnost konkrétního rizika. Smyslem základních taktik je především uvědomění si základního směru (resp. možnosti) pro

snižování významností rizika (tj. směru zamýšleného posunu pozice rizika v mapě rizik a to prostřednictvím snižování jeho pravděpodobnosti anebo dopadu s cílem posunout „pozici“ rizika v mapě rizik co nejvíce k počátku).

Pro eliminaci identifikovaných rizik byla vždy zvolena vhodná taktika zvládání rizika, která vedla

ke stanovení konkrétního opatření. Tato opatření jsou specifikována v následující tabulce „Opatření navržená pro eliminaci rizik projektu“:

Kód

rizika Riziko Opatření vedoucí k eliminaci

Právní rizika A.1 Nedodržení právních norem ČR, EU. Podrobná analýza legislativy a specifikace

požadavků legislativy v úvodní fázi projektu. A.2 Neschopnost udržet legislativní shodu

systému nebo jeho částí Průběžný monitoring změn legislativy v průběhu projektu a implementace změnového managementu.

A.3 Nevhodné smluvní podmínky, např. autorské právo, sankce, náhrada škody atd.

Návrh smluvních podmínek ze strany zadavatele a jejich ověření více právníky.

Finanční rizika B.1 Nedostatečné údaje pro vyhodnocení

předpokladů návratnosti Implementace metriky a systému pro vyhodnocování finančních dopadů projektu.

B.2 Navýšení cen technologií, služeb a prací a dalších vstupů.

Smluvní fixace cen za služby, standardizace technologií a otevřenost technologií, autorských práv a detailní dokumentace systémů.

B.3 Růst provozních nákladů v provozní fázi projektu.

Standardizace provozu, implementace systému řízení kvalitativní úrovně služeb provozu.



Strana 159 z 186

Kód rizika

Riziko Opatření vedoucí k eliminaci

Technická rizika C.1 Výběr nekvalitního dodavatele. Při výběrových řízeních bude kladen důraz na

kvalitu uchazečů (realizované projekty, reference od zákazníků apod.) a nabízenou cenu. Žadatel má bohaté zkušenosti s prováděním výběrových řízení.

C.2 Výběr nevhodné technologie. Určení kvalitativních kritérií technologií a testování technologií před / v průběhu jejich obstarání.

C.3 Riziko souvisící se zařízením (pře/poddimenzovaná kapacita / výkon)

Dimenzování podle zátěžových testů, opce na zvýšení / snížení kapacit technologií.

Personální rizika D.1 Nedostatečná delegace kompetencí

v projektovém týmu. Uplatnění standardní metodiky řízení projektů a definování kompetencí v projektovém týmu.

D.2 Nedostatečný vnitřní kontrolní systém. Implementace kontrolního systému s vnějším prvkem pro nezávislost kontroly.

D.3 Nedostatek kvalifikované a kvalitní pracovní síly v provozní fázi.

Zahrnutí získání know-how pracovníků spolu s ověřením jejich znalostí do realizační fáze projektu.

D.4 Fluktuace zaměstnanců zapojených do provozu projektu.

Uplatnění struktury znalostí v týmu s redundantním výskytem znalostí.

D.5 Závislost na specifických zaměstnancích / zaměstnancích dodavatele.

Kvalitní dokumentace s podrobným popisem všech částí systémů a infrastruktury, obstarání paralelního rámce pro poskytování služeb z vnějšího prostředí, rotace pracovníků více poskytovatelů.

D.6 Nedostatečné znalosti nebo potřeba specifického know-how.

Zmapování znalostní báze a identifikace mezer v znalostech, zavedení plánu transferu / obstarání specifického know-how.

Provozní rizika

E.1 Neschopnost koordinace rozvoje systému v požadovaném čase a rozsahu

Standardizace provozu, implementace systému řízení kvalitativní úrovně služeb provozu včetně systému řízení změn.

E.2 Nenaplnění dodavatelských smluv v provozní fázi projektu.

Standardizace provozu, implementace kontrolních mechanizmů a smluvní dohoda s náhradním poskytovatelem služeb.

E.3 Riziko spjaté s nastavením smluvního vztahu údržby a provozu systému (závislost na dodavateli)

Standardizace provozu, implementace kontrolních mechanizmů a smluvní dohoda s náhradním poskytovatelem služeb.



Strana 160 z 186

Kód rizika

Riziko Opatření vedoucí k eliminaci

Bezpečnostní rizika F.1 Krádež technologií nebo jejich poničení. Zajištění maximální úrovně ostrahy jak

z hlediska personálního zabezpečení, tak i moderních zabezpečovacích systémů. Umístnění technologií do přiměřeného prostoru datacanetra.

F.2 Teroristický útok (včetně kybernetického útoku).

Uplatnění metodiky / standardu pro řízení bezpečnostních rizik a řízení bezpečnosti. Technická opatření pro eliminaci útoků.

F.3 Bezpečnostní rizika Uplatnění metodiky / standardu pro řízení bezpečnostních rizik a řízení bezpečnosti. Technická opatření pro zabezpečení dostupnosti, integrity a důvěrnosti dat.

F.4 Nedodržení povinností vyplývajících z legislativy, zejména zákonu o ochraně utajovaných skutečností.

Postupování ve shodě se zákonem a příslušnými předpisy.

Projektová rizika G.1 Nedostatky v projektové dokumentaci. Uplatnění standardní metodiky řízení projektů

a kvalitativních kritérií na dokumentaci. G.2 Neschopnost expertního zhodnocení

kvality dodaných služeb (částkové přebíraní výstupů dodavatele)

Definice kvalitativních úrovní, jejich oponentura třetí stranou a kontrola / audit jejich uplatnění v průběhu projektu.

G.3 Dodatečné změny v projektu. Uplatnění standardní metodiky řízení projektů a změnového řízení.

G.4 Špatná koordinace dodavatelských prací. Uplatnění standardní metodiky řízení projektů a kontrolních mechanizmů postupu.

G.5 Zpochybnění validity projektu Podpora prostřednictvím podporné komunikace s okolím projektu a příprava krizové komunikace - scénářů krizové komunikace.

G.6 Škody z nedostatečné soutěže anebo škody spojené s reputací na základě medializovaného zpochybnění nezávislého výběru dodavatele

Uplatnění principů transparentnosti a zákonných pravidel pro podporu soutěže v projektu nebo jeho částech.

G.7 Nedodržení termínu realizace. Za dodržování termínu realizace (příp. etap) bude zodpovědný dodavatel, případné porušení sjednaného harmonogramu bude řešeno smluvní pokutou.



Strana 161 z 186

Projektové řízení a projektový tým Pro realizaci Projektu EET je kladen velký důraz na úspěšné zvládnutí vhodných metod a nástrojů. Dobré a vžité praktiky projektového řízení se opírají především o následující zdroje:

Norma ČSN ISO 10006 – Management jakosti – Směrnice jakosti v managementu projektu.

Mezinárodní metodika Project Management Body of Knowledge.

Metodiky, doporučení a Prince2.

Metodologie řízení projektu se skládá z následujících klíčových procesních oblastí, jež je nutné zásadním způsobem zvládat:

Procesy vztahující se ke zdrojům.

Procesy vztahující se k pracovníkům (řízení lidských zdrojů v rámci projektu).

Procesy vztahující se k řízení vzájemných závislostí (řízení integrace projektu).

Procesy vztahující se k záměru (řízení rozsahu prací projektu).

Procesy vztahující se k časovým lhůtám (řízení času v rámci projektu).

Procesy vztahující se k nákladům (řízení nákladů projektu).

Procesy vztahující se ke komunikaci (řízení komunikace v rámci projektu).

Procesy vztahující se k rizikům (řízení rizik projektu).

Procesy vztahující se k nakupování (řízení obstarávání v rámci projektu).

Procesy vztahující se ke zlepšování (řízení jakosti v rámci projektu).

Metodika řízení projektu je založena na definici organizace projektu a nastavení procesů projektového řízení. Metodika je navržena tak, aby poskytovala metodickou podporu a metodické nástroje pro:

Řízení projektu tak, aby bylo efektivním způsobem dosaženo stanovených cílů projektu.

Kontrolu plnění smluvních závazků a podmínek plynoucích ze Smluvních vztahů:

o kvality, včasnosti a úplnosti plnění závazků smluvních stran,

o identifikace případného neplnění smluvních závazků smluvními stranami,

o identifikace zřejmých, jednoznačných a rychle aplikovatelných termínovaných postupů vedoucích k odstranění překážek plnění Smluvních závazků a k případné reflexi těchto postupů do znění Smluvní dokumentace.

Koncepce metodiky řízení projektu včetně organizace projektu vychází z následující základních prosazovaných zásad:

Racionálně navržená struktura orgánů řízení projektu

Organizační struktura projektu zahrnuje pouze nutné řídící orgány, jejichž struktura je minimalizována tak, aby mohly řádně plnit jim svěřené řídící funkce. Struktura řídících orgánů je navržena hierarchicky tak, aby se na příslušné úrovni řízení projektu nakládalo pouze s adekvátními a na nižších úrovních dostatečně předzpracovanými informacemi a tak, aby probíhaly pouze řídící činnosti, které jsou adekvátní dané úrovni řízení.

Racionálně navržené rozhodovací procesy

Rozhodovací procesy jsou navrženy takovým způsobem, aby byl minimalizován počet nutných kroků vedoucích ke konečnému rozhodování, ovšem při zachování kvality rozhodovacího procesu. V rámci rozhodovacích procesů je uplatněna zásada individuální rozhodovací odpovědnosti a zásada „rozhoduje jeden“ (ať již ve smyslu řídícího orgánu jako celku, tak jednotlivých účastníků projektu).



Strana 162 z 186

Prosazování cílené adresné odpovědnosti

V rámci projektu je jednoznačně určena odpovědnost jednotlivých účastníků. Jednotlivé úkoly jsou předávány k řešení těm účastníkům projektu, kteří mají předpoklady a potřebné zdroje k jejich vykonání. Provádění jednotlivých činností (plnění úkolů včetně kvality plnění) je důsledně sledováno.

Zajištění účelnosti a efektivity metodiky řízení projektu

Metodika řízení projektu není chápána staticky. V průběhu projektu, se může částečně měnit, a to vždy tak, aby vždy odpovídala aktuálnímu stavu projektu a byla účinná a efektivní při řešení aktuálních potřeb projektu včetně těch, které mohou plynout ze změny priorit projektového řízení. Soulad aktuální podoby metodiky se stavem a potřebami projektu je průběžně sledován.

Organizace Projektu

V této kapitole jsou popsány orgány Projektu EET z hlediska jejich struktury a vzájemných vazeb.

Orgány projektu

Organizační struktura Projektu EET je graficky znázorněna na schématu níže.

Obrázek 45: Organizační struktura projektu



Strana 163 z 186

Řídící komise a sponzor Projektu

Sponzor Projektu EET

Sponzorem projektu je statutární zástupce organizace, který je vybaven rozhodovací pravomocí a bude se zasazovat za realizaci projektu. Sponzor projektu především rozhoduje o způsobu financování projektu, provádí strategická rozhodnutí, která mají vliv na směřování projektu a řeší případné spory a problémy, které se nepodaří vyřešit na nižších úrovních. Sponzor projektu odpovídá především za:

Oficiální zaštítění celého projektu.

Řešení velkých změn projektu.

Schvaluje výstupy projektu.

Sponzorem projektu je Ministr financí ČR.

Řídící komise

Řídící komise projektu (ŘK) má celkem sedm členů, předsedou komise je statutární zástupce GŘC. Jeho členy jsou zaměstnanci nejvyššího vedení MFČR a GŘC:

Simona Hornochová

Miroslav Hejna

Michaela Pobořilová

Lukáš Wagenknecht

Martin Janeček (předseda)

Hanuš Weisl

Roman Hozák

Mezi hlavní úkoly ŘK patří především:

Schvalování hlavních výstupů Projektu EET, tj. zejména Základní listiny Projektu EET, apod.

Projednávání aktuálního stavu hlavních aktivit Projektu EET a přijímání případných zásadních rozhodnutí týkajících se Projektu, zejména schvalování podstatných změn.

Řešení rizik a přijímání opatření k jejich eliminaci, respektive odstranění.

Schvalování personálních změn projektového týmu a řešitelských týmů.

Řídící komise se bude v plném složení scházet minimálně jednou za měsíc, v případě potřeby častěji. Jednání ŘK se bude za účelem informování o aktuálním stavu Projektu účastnit rovněž projektový manažer. Projektový manažer nebude mít hlasovací právo. Konkrétní mechanismy jednání a schvalování na úrovni ŘK budou upraveny v Základní listině Projektu EET.

Seznam projektových rolí a jejich základní specifikace: Role Specifikace role Zainteresovaná smluvní strana projektu

Zainteresovanou smluvní stranou se rozumí subjekt, který je v projektu přímo zastoupen a nějakým způsobem projekt přímo ovlivňuje. V tomto případě MFČR, GFŘ, GŘC, SPCSS.

Člen řídící komise Člen řídící komise odpovídá spolu s ostatními členy řídící komise za dohled nad plněním celkového rámce projektu, zejména dohleduje projektové vedení. Člen řídící komise se podílí na rozhodování zásadních otázek a stavů projektu, které jsou mu k rozhodnutí předkládány z úrovně vedení projektu. Člen řídící komise plní úkoly uložené mu rozhodnutím řídící komise.



Strana 164 z 186

Vedoucí projektu/ projektového týmu

Vedoucí projektu odpovídá za vedení jemu podřízeného projektového týmu, zejména zadává úkoly a sleduje jejich plnění. Vedoucí projektu je hlavní odpovědnou osobou za projekt a je současně hlavní kontaktní osobou zajišťující komunikaci s ostatními řešitelskými projektovými týmy a řídící komisí.

Kontaktní osoba projektového týmu

Kontaktní osoba projektového týmu je hlavní odpovědnou osobou za projekt za danou zainteresovanou smluvní stranu. Zajišťuje komunikaci za svou smluvní stranu napříč mezi všemi projektovými týmy.

Členové projektového týmu

Členové projektového týmu jsou vedoucí jednotlivých řešitelských týmů a administrátor projektu. Předkládají projektovému vedoucímu výstupy za své řešitelské týmy. Jedná se o výkonnou složku projektu.

Administrátor projektu

Administrátor projektu zajišťuje některé běžné agendy projektu (např. zápisy z jednání řídící komise, zápisy z jednání projektového týmu, atp.) a zprostředkovává a zastřešuje další organizační požadavky plynoucí z projektového týmu.

Vedoucí řešitelského projektového týmu

Vedoucí řešitelského projektového týmu je zodpovědný za vedení jeho týmu. Organizuje schůzky svého týmu, zadává úkoly členům svého týmu, kontroluje plnění těchto úkolů, předkládá a zodpovídá za výstupy svého týmu směrem k projektovému vedoucímu. Každý vedoucí řešitelského týmu má povinnost delegovat svého zástupce, v případě nutnosti zastoupení při jednáních projektového týmu.

Člen řešitelského projektového

Člen řešitelského projektového týmu řádně a včas plní úkoly uložené nadřízeným vedoucím odborného týmu nebo jím pověřenou osobou. Každý člen řešitelského projektového týmu je zejména povinen neprodleně informovat nadřízeného vedoucího, nebo vedoucího projektu o skutečnostech, které mohou ohrozit projekt či naopak napomoci jeho realizaci.

Kompetence jednotlivých projektových týmů

Řídící komise Projektu EET (dále také „ŘKO“)

Řídící komise Projektu EET (dále jen ŘKO) je vrcholový řídící orgán Projektu EET, který rozhoduje o zásadních otázkách ovlivňujících směr a průběh realizace Projektu EET.

Člen ŘKO musí být vybaven potřebnými kompetencemi rozhodovat v zásadních otázkách Projektu EET, musí mít možnost alokovat potřebné projektové zdroje a musí mít možnost prosadit rozhodnutí v rámci příslušné smluvní strany.

Řídící komise Projektu je složena ze zástupců MFČR, GFŘ a SPCSS.

Na jednání ŘKO mohou být na žádost zástupců MFČR, GFŘ či zástupců SPCSS přizváni s poradním hlasem další externí odborníci nebo zástupci dalších stran participujících na realizaci Projektu.

ŘKO se schází dle potřeby tak, aby byla zabezpečena dostatečná kvalita sledování Projektu. V případě nutnosti rychlého a zásadního rozhodnutí se Řídící komise Projektu sejde v prvním možném termínu na vyžádání kterýmkoliv jejím stálým členem.

ŘKO svolává vedoucí projektu, pokud není domluveno jinak.

Kompetence ŘKO:

Jmenuje členy ostatních týmů na návrh vedoucího projektu.

Informuje vedení Ministerstva financí ČR o průběhu projektu; kontroluje stav a průběh projektu a vydává rozhodnutí za účelem podpory plnění cílů projektu.

Rozhoduje o návrhu na změnu projektu (rozsah plnění, harmonogram, cena) včetně případných změn smlouvy.

Řeší krizové situace projektu a rozhoduje o mimořádných opatřeních k jejich odstranění.



Strana 165 z 186

Potvrzuje jednotlivá plnění projektu a schvaluje zahájení a ukončení projektu.

Řídí a schvaluje součinnosti, které budou poskytnuty v rámci projektu (včetně třetích stran).

Je eskalačním orgánem, který řeší případné spory, jež se nepodařilo vyřešit v rámci ostatních projektových týmů.

Quality assurance (QA)

Garant kvality dohlíží na všechny procesy, od návrhu, realizaci až po dokumentaci projektu. Cílem QA je dohlédnout na procesy projektu, tak aby byl projekt dokončen dle zadání a v požadovaném čase a kvalitě. Garant kvality (z BDO) je nominován dočasně a to do 27.2. 2015.

Projektový tým (PT)

Projektový tým, řeší aktuální problémy při přípravě a provozu Služeb, koordinuje činnost řešitelských týmů, které se podílejí na přípravě a realizaci služeb.

PT projednává a předkládá návrhy na optimalizaci a změnu, zpracovává zprávy o průběhu Projektu, identifikuje možná rizika, iniciuje jednání na mitigaci rizik.

PT schvaluje dokumenty, jež jsou součástí plnění, schvaluje dílčí harmonogramy jednotlivých etap Projektu.

Tým je složen ze zástupců SPCSS, MFČR a GFŘ a případně zástupců třetích stran.

Kompetence Projektového týmu

Definuje a hodnotí požadavky na systém EET, určuje priority ve spolupráci s ostatními týmy.

Předkládá výstupy Řídící komisi.

Řídí a monitoruje kvalitu v průběhu všech etap projektu.

Připravuje a projednává návrhy postupů k mitigaci rizik.

Odpovídá za vedení aktuálního Registru rizik.

Předkládá podklady Řídící komisi a poradě vedení (ZPV)

Odborný tým (OT)

Kompetence Odborného týmu: Specifikuje zadání - věcný popis fungování systému elektronické evidence tržeb z hlediska

povinných subjektů a z hlediska správce daně, včetně souvisejících kontrolních postupů a udělování sankcí.

Navrhuje a upravuje procesní postupy ve vztahu k zavedení EET ve spolupráci s ostatními týmy.

Provádí věcné hodnocení vůči Chorvatskému modelu. Komunikuje s odbornými subjekty ze zahraničí.

Spolupracuje také s ostatními týmy, zejména s týmem legislativy a technickým týmem, s týmem PR komunikuje propagační stránku projektu.

Podílí se na vytvoření zadávací dokumentace pro projekt EET.

Zodpovídá za formální i obsahovou správnost specifikace zadání

Technický tým (TT)

Kompetence Technického týmu:

Vytváří funkční a technickou specifikaci pro zadání projektu EET.



Strana 166 z 186

Provádí sběr požadavků od odborného a legislativního týmu a převádí věcné požadavky do technického řešení.

Formalizuje požadavky a komunikuje požadavky s ostatními týmy.

Připravuje návrh technického řešení EET.

Připravuje podklady pro zadávací dokumentaci projektu EET.

Zodpovídá za správnost vytvořené funkční a technické specifikace

Tým legislativa (TL)

Kompetence Týmu legislativa:

Odpovídá za přenesení věcného řešení do legislativního textu, tj. při požadavku na regulaci, tým zváží, zda je ji třeba provádět zákonem, vyhláškou či postačí řešení v rovině metodické či správní. Pokud bude daný požadavek regulován zákonem či vyhláškou, pak je odpovědný za formulaci daného ustanovení do předmětného právního předpisu.

Vyhodnocuje požadavky ostatních týmů zejména s ohledem na nutnost regulace zákonem, vyhláškou atd.

Navrhuje formulace ustanovení zákona.

Odpovídá za realizaci legislativního procesu přípravy zákona o EET, tj. realizace připomínkových řízení a procesů v rámci vlády a Parlamentu České republiky (tj. zajištění potřebné součinnosti ze strany předkladatele)

Vede harmonogram legislativního procesu

Zodpovídá za legislativní zachycení věcného řešení.

Tým právní a administrativní podpora (PP)

Kompetence Tým právní a administrativní podpora:

Právní a administrativní podpora projektu, tj. organizuje přípravu pro zadání veřejných zakázek na realizaci EET včetně vedení dokumentace.

Podílí se na vytvoření zadávací dokumentace pro projekt.

Připravuje a vede harmonogram zadání veřejných zakázek.

Komunikuje s dotčenými orgány (ÚOHS …).

Zodpovídá za smluvní zajištění systému EET ve všech fázích projektu

Tým PR a komunikace (PR)

Kompetence Týmu PR a komunikace:

Příprava strategického plánu komunikace, segmentace cílové skupiny, volba nástrojů, precizace hlavních sdělení, časový plán

Příprava obsahu kampaně (název projektu, Corporate identity projektu, argumentář, tonalita sdělení)

Sběr mediálně důležitých témat a informací z jednání týmů.

Hodnotí získané informace z hlediska nutné komunikace směrem k veřejnosti či jiným zájmovým skupinám.

Zpracovává manuál krizové dokumentace.

Provádí analýzu mediálního obsahu.

Navrhuje témata, která je nutné sdílet. Navrhuje postupy sdílení.

Podporuje klíčové zaměstnance MFČR při prezentacích EET a veřejném vystupování



Strana 167 z 186

Zodpovídá za komunikaci s médii a třetími stranami na podporu v médiích (on-line komunikace včetně zvláštní webové stránky)

Tým Rozpočet/controlling (RO)

Kompetence Týmu Rozpočet a controlling:

Nastavuje a řídí rozpočet projektu a kontroluje jeho plnění ve 2 rovinách (rozpočet a controlling)

Plánování zdrojů a řízení nákladů projektu (rozpočet)

Příprava podkladů pro plánování zdrojů, rozpočtu a řízení nákladů projektu,

Plánování zdrojů - určování, jaké zdroje (pracovníci, vybavení) a v jakých množstvích by měly být použity pro provedení projektových a provozních činností.

Odhadování nákladů - stanovení přibližných nákladů potřebných k dokončení projektových a provozních činností.

Rozpočtování nákladů – zpracování a rozdělování celkových odhadovaných nákladů mezi jednotlivé etapy projektu a provozu.

Operativní řízení nákladů - operativní řízení změn rozpočtu projektu.

Návrh, nastavení a zavedení systému controllingu projektu v za účelem pravidelného informování o stavu čerpání a rezerv finančních a dalších prostředků,

Pravidelné zpracovávání výkazů čerpání rozpočtu a porovnání plánu a skutečnosti.

Zodpovídá za řádné plnění rozpočtu

Tým Front Office (FO)

Kompetence Týmu Front Office:

Komunikuje se zástupci a Ministerstva vnitra (ISDS, Czechpoint) a České pošty za účelem přípravy a realizace obslužných procesů EET prostřednictvím služeb ISDS (datové schránky) a kontaktních míst České pošty a Czechpoint.

Zodpovídá za řádné a včasné zajištění procesů EET spojených s obsluhou povinných subjektů na kontaktních místech (FÚ, Česká pošta, Czech point) a prostřednictví ISDS.

Tým Utajované informace (UI)

Tým Utajované informace (UI) je složen z bezpečnostních ředitelů GFŘ a SPCSS a zástupce ředitele Odboru Bezpečnost a krizové řízení MFČR.

Kompetence Týmu Utajované informace:

Komunikuje ve spolupráci s právním týmem s dotčenými orgány (NBÚ).

Zodpovídá za realizaci veškeré agendy spojené s nakládáním se stávajícími utajovanými informacemi v rámci projektu EET i s těmi co vzniknou v průběhu realizace, jakož i dalšími bezpečnostními aspekty EET.

Vede seznam poskytnutých utajovaných informací (utajovaných dokumentů), které v rámci projektu EET vznikly.

Vede seznam pracovníků (členů projektových týmů) s přístupem k předmětným utajovaným informacím a provádí jejích poučení.

Kontroluje nakládání s utajovanými informacemi v rámci projektu EET.



Strana 168 z 186

Řízení Projektu

Následující kapitoly popisují hlavní principy řízení Projektu. Detailní a aktuální specifikace řízení Projektu EET bude uvedena v Základní listině Projektu, která bude zpracována bezprostředně po schválení tohoto dokumentu.

Základní listina Projektu bude jasně definovat aktivity řízení a implementace Projektu EET, odpovědnosti a termíny plnění. Za zpracování Základní listiny Projektu a její případné změny odpovídá projektový manažer a schvaluje ji Řídící komise Projektu.

Základem metodiky řízení projektu je vyvážený a vzájemně provázaný systém procesů a postupů, jehož cílem je efektivní dosažení stanovených cílů v plánovaném rozsahu a s využitím plánovaných zdrojů. Tento systém zahrnuje následující procesní okruhy popsané dále v následujících podkapitolách:

Řízení rizik.

Řízení dodavatelů.

Řízení změn.

Kontrolu postupu projektu.

Řízení problémů.

Akceptační postupy.

Komunikační strategie.

Řízení kvality.

Správa dokumentace.

Řízení rizik

Hlavní odpovědnost za řízení rizik (monitorování a realizaci opatření k eliminaci / odstranění rizika) nese projektový manažer (PM).

Nástrojem pro řízení rizik je Katalog rizik. Rizika uvedená v Katalogu budou předmětem monitorování a řízení na úrovni projektového týmu, respektive řešitelského týmu, který odpovídá za jeho eliminaci / odstranění.

Za identifikaci případných dalších rizik Projektu EET jsou odpovědni všichni členové řešitelských týmů. O identifikovaném riziku, včetně návrhu nápravného opatření, je každý člen povinen informovat příslušného vedoucího týmu.

Vedoucí řešitelského týmu ohodnotí riziko z hlediska jeho významnosti (tj. pravděpodobnost a dopad) a schválí navržené nápravné opatření. Pokud jde o riziko střední / vysoké významnosti, eskaluje jej na PM, který jej zařadí na nejbližší jednání projektového týmu.

Projektový tým nově identifikovaná rizika, jejich významnost a návrh opatření projedná a rozhodne o začlenění do Katalogu rizik. Každému novému riziku PT následně přidělí osobu odpovědnou za sledování rizika a realizaci nápravného opatření. Nápravná opatření ve formě nepodstatných změn schvaluje PM, ve formě podstatných změn pak ŘK.

Monitorování a řízení rizik je vždy předmětem jednání ŘK.

Řízení dodavatelů Za řízení dodavatelů odpovídá vedoucí projektového týmu. Na přípravě veřejných zakázek se

budou podílet jednotlivé řešitelské týmy, každý za svojí oblast. Odpovědnost zahrnuje nastavení a kontrolu smluvních vztahů.

Odpovědnost za řízení změn v rámci Projektu EET nese projektový manažer (PM).

„Podstatné“ změny v Projektu na základě návrhu PM schvaluje ŘK. „Nepodstatné“ změny v projektu schvaluje PM a informuje na nejbližším jednání ŘK.



Strana 169 z 186

Řízení problémů

Cílem řízení problémů je včasná identifikace a řízené řešení faktorů (problémů), které ohrožují úspěšné dosažení cílů projektu (zejména pak lokálně jeho řádný průběh).

Na rozdíl od změny, která je řízenou (byť dodatečnou) změnou předmětu projektu či způsobu jeho realizace, může být problémem jakákoli skutečnost související s projektem, která má na jeho průběh a výsledek negativní vliv menšího i většího rozsahu.

Řešení problémů probíhá primárně uvnitř projektových týmů v pravomoci příslušného vedoucího řešitelského týmu. Vedoucí řešitelského týmu informují o problémech svého vedoucího řešitelského týmu a jejich řešení ostatní členy vedení řešitelského týmu. V případě zásadních problémů, které přesahují pravomoci vedení řešitelského týmu jsou tyto přenášeny na vedení projektového týmu a případně až na ŘK projektu.

Řešení některých problémů může vyústit do požadavku na změnu.

Identifikace problému

Kdokoliv z projektového týmu projektu může identifikovat problém. V tomto případě zašle hlášení problému (popis problému, jeho příčin, dopadů a možných řešení) elektronickou cestou nadřízenému vedoucímu řešitelského týmu.

Příslušný vedoucí řešitelského týmu potvrdí ohlašovateli elektronickou cestou přijetí hlášení problému.

Rozhodnutí o řešení problému

Vedoucí řešitelského týmu posoudí přijatý problém a je-li to třeba k řešení, konzultuje jej s vedením projektového týmu. Vyžaduje-li to situace, může být problém spolu s návrhy řešení a dalšími relevantními podklady předán vedení projektu případně následně řídící radě projektu. Následně rozhodne o způsobu řešení problému jedním z následujících způsobů:

Odložení problému: neshledá-li potřebu řešit hlášený problém, pak jej uzavře.

Operativní řešení problému: rozhodne-li o operativním řešení problému, pak stanoví způsob řešení včetně předpokládaných termínu a zdrojů a pověří příslušné členy řešitelského týmu úkoly a sleduje jejich plnění. Po operativním vyřešení problému uzavře tento problém s tím, že o uzavření informuje vedení projektového týmu a případně ŘK (jestliže došlo k eskalaci problému na dané úrovně).

Návrh na změnu: shledá-li potřebu řešit problém formou změnového požadavku, pak připraví příslušný změnový požadavek.

Řešení problému

Problémy vedení řešitelských týmů a vedení projektového týmu sleduje nejméně s týdenní periodicitou a podle potřeby přijímá příslušná opatření. Informace o problémech a jejich řešení jsou dle závažnosti a úrovně eskalace zaznamenávány v rámci zápisů z jednání řešitelských týmů, vedení projektového týmu a ŘK.

Principy akceptace

Akceptační řízení je činnost, která začíná protokolárním předáním předmětu dílčího plnění (etapy, fáze) a během které vedoucí projektového týmu a jednotlivými dodavateli ověřují, zda předaný předmět plnění odpovídá smluvním vztahům, a to prostřednictvím akceptačních kritérií a v dohodnutých lhůtách.

Akceptační protokoly – v souladu s odevzdanými výstupy dodavatelů zajišťují vedoucí řešitelských týmů jejich vypracování a podepsání dotčenými stranami.



Strana 170 z 186

Reporting a monitoring

Za průběžný monitoring Projektu na úrovni jednotlivých řešitelských týmu odpovídá příslušný vedoucí. Za monitoring na úrovni celého Projektu odpovídá projektový manažer. Aktuální stav realizovaných aktivit je předmětem pravidelných jednání projektového týmu. Projektový manažer pravidelně informuje o stavu Projektu ŘK.

Etapové a závěrečná monitorovací zpráva – předkládá se poskytovateli po ukončení etap, respektive celkovém ukončení Projektu EET. Za zpracování zpráv odpovídá projektovému manažer, který zprávu předloží ke schválení ŘK. Po schválení je zpráva předána k podpisu statutárnímu zástupci.

Všichni členové týmu budou povinni zpracovávat měsíční pracovní výkazy, které budou specifikovat počet hodin účelně strávených na realizaci Projektu (v souladu s popisem práce na Projektu) a realizovanou aktivitu. Výkaz práce je schvalován nadřízeným člena týmu.

Za řízení rozpočtu Projektu a jeho aktuální čerpání odpovídá vedoucí řešitelského rozpočet a controlling. Řízení rozpočtu je předmětem jednání na úrovni projektového týmu. Změny rozpočtu schvaluje vždy projektový manažer. Tzv. podstatné změny rozpočtu musí být schváleny ŘK.

Komunikace v rámci projektu

Řídící komise

Řídící komise Projektu se schází minimálně jednou za měsíc, v případě potřeby častěji. Na prvním jednání ŘK si členové zvolí předsedu.

Jednání ŘK svolává předseda ŘK na podnět PM minimálně 1x za měsíc, respektive v případě eskalovaného problému. Agendu připravuje a zápis pořizuje PM Projektu EET.

ŘK je pravidelně informován o aktuálním stavu a dalším vývoji v Projektu EET. V případě rozhodování hlasováním rozhoduje prostá většina hlasů, sponzor má právo veta,

PM má hlas pouze poradní. Pro účely hlasování musí být přítomni členové ŘK, nebo jimi určení náhradníci. Pro zefektivnění realizace Projektu EET Základní listina Projektu dále specifikuje případy, kdy je možné hlasování / schvalování „per rollam“.

Ze všech jednání ŘK jsou pořizovány písemné zápisy, které jsou archivovány v souladu s pravidly archivace.

Projektový tým

Projektový tým se schází zpravidla jednou za týden, v případě potřeby častěji. Nastavení frekvence jednání bude předmětem úpravy v Základní listině Projektu.

Jednání týmu svolává PM, agendu připravuje asistent PM.

Účelem jednání projektového týmu je zejména monitoring stavu Projektu EET, koordinace prací a činností řešitelských týmů, řízení rizik, koordinace s ostatními projekty, které mají vazbu na Projekt EET, řízení změn apod.

Ze všech jednání projektového týmu pořizuje asistent PM písemné zápisy, které jsou archivovány v souladu s pravidly archivace.

Řešitelské týmy

Řešitelské týmy se schází zpravidla jednou za týden, v případě potřeby častěji. Nastavení frekvence jednání bude předmětem úpravy v Základní listině Projektu.

Jednání týmu svolávají příslušní vedoucí řešitelských týmů.

Účelem jednání řešitelského týmu je zejména monitoring stavu Projektu na úrovni týmu, koordinace prací a činností v rámci týmu, monitoring dodavatelských vztahů, řízení rizik, koordinace s ostatními řešitelskými týmy, apod.

Ze všech jednání řešitelského týmu jsou pořizovány písemné zápisy, které jsou archivovány v souladu s pravidly archivace.



Strana 171 z 186

Schvalování výstupů

ŘK schvaluje změny v projektovém týmu, podstatné změny v Projektu EET a monitorovací zprávy.

PM schvaluje výstupy Projektu EET na úrovni projektového týmu (tzn. akceptační kritéria dílčích etap, akceptační protokoly z řešitelských týmů, nepodstatné změny v Projektu EET, návrhy podstatných změn v Projektu EET).

Vedoucí řešitelských týmů schvalují výstupy dodavatelů dodané v rámci jimi věcně řízené oblasti.

Řízení kvality

Principy řízení kvality

Zajištění kvality jednotlivých klíčových výstupů projektu a projektu samotného patří mezi povinnosti vedoucích řešitelských týmů a je dohledováno manažerem kvality projektu z hlediska dodržování metodiky řízení projektu a souladu se smluvním rámcem stanoveným smlouvou o dílo. Zajišťování kvality výstupů projektu vychází ze dvou principů:

Zdokonalování kvality projektových postupů.

Kontroly kvality klíčových výstupů projektu.

PM společně s manažerem kvality vypracovávají plán zajišťování kvality projektu. Mezi nástroje k zajištění kontroly kvality patří:

Osvědčený projektový postup, jehož použití je na závěr projektu (a případně i v jeho průběhu) posuzováno a který je soustavně zdokonalován.

Pokud na úkolu pracuje více zdrojů, je stanoveno, který z nich za splnění úkolu zodpovídá a role/úloha ostatních zdrojů.

Projektový postup obsahuje na závěr jednotlivých kroků úkoly spočívající v posouzení zpracovaných výstupů, přičemž podle možností jsou k těmto úkolům přiřazeny zdroje, které nezpracovávaly posuzované výstupy.

Vytvoření katalogu požadavků na systém a ověření, že splnění těchto požadavků je ověřitelné.

Zapojení uživatelů do kontroly kvality (posuzování návrhů uživatelského rozhraní, akceptační testování).

Provedená posouzení kvality produktů jsou dokumentována (kdo kontroloval, co kontroloval, s jakým výsledkem).

Produkty, u kterých byly zjištěny nedostatky, jsou zadány k úpravě a odstranění a těchto nedostatků je kontrolováno.

Určování příčin zjištěných chyb a zapracování preventivních činností do projektového postupu.

Při zadání úkolu jen vždy specifikován požadovaný výstup a kriteria pro posouzení jeho kvality, specifikaci kriterií kvality stanovuje PM nebo jím pověřený zdroj (zejména o produktů výkonné části projektu).

Před zahájením testování je zpracovávána specifikace testovacích případů pro jednotlivé úrovně testování.

Kontroly kvality

V rámci řízení kvality se uplatňují vedle sebe pravidelné (povinné) a nepravidelné (nepovinné) kontroly kvality.



Strana 172 z 186

Pravidelné kontroly

Pravidelné kontroly jsou prováděny v následujících termínech a rozsahu dle stanoveného schématu:

Dodržování projektového plánu Metoda: Monitorování a sledování Plánu projektu. Informování o stavu projektu včetně

hlášení výrazných projektových odchylek. Odpovídá: PM. Četnost: Kontinuálně, formálně minimálně jedenkrát týdně. Cíl: Dodržet všechny plánované milníky realizace.

Shoda výstupů se specifikací Metoda: Ověření, zda výstup splňuje všechna kvalitativní a kvantitativní akceptační

kritéria formou akceptace či dílčí kontroly. Odpovídá: PT a subjekty definované v Akceptačních kritériích. Četnost: Při akceptačním řízení. Cíl: Dodržet kritéria kvality realizace Projektu.

Projektová dokumentace Metoda: Ověřit kompletnost projektové dokumentace dle požadavků Metodiky. Odpovídá: PT. Četnost: Průběžně minimálně jedenkrát týdně a při ukončení hlavních částí projektu. Cíl: Zajistit auditovatelnost realizace projektu.

Nepravidelné kontroly

Nepravidelné kontroly mohou být provedeny podle potřeby kdykoliv v průběhu projektu. Provedení kontroly iniciují PM nebo ŘK. Kontrolu kvality dokumentace, průběhu realizace a výstupů projektu provádí určený PM ve spolupráci s manažerem kvality projektu nebo manažer kvality sám a dle potřeby se účastní kterýkoliv účastník projektu. Pokud jsou při kontrole kvality shledány nedostatky, stanoví se přiměřené lhůty k jejich odstranění. Za odstranění těchto nedostatků odpovídá určení PM.

Kontrola vedení projektu Formální kontrola, které se účastní zástupci liniového řízení MFČR, GFŘ, GŘC, SPCSS (včetně např. zástupců příslušných organizačních jednotek). Provedení kontroly je vedeno PM, výsledky kontroly jsou schváleny ŘK.

Kontrola Vedoucích řešitelských týmů Kontrola kvality, prováděná manažerem kvality.

Kontrola člena týmu Kontroly kvality na úrovni řešitelských týmů jsou prováděny formou pracovních jednání/workshopů či tzv. distribučním způsobem. Při těchto kontrolách, zpracovávají připomínky k předloženým výstupům ostatní členové PT, s odpovídajícími zkušenostmi a dovednostmi ve vztahu k revidovanému výstupu.

Kontrola sebe sama Autor a/nebo vlastník výstupu sám provádí kontrolu výsledků své práce, v průběhu realizace i před předáním.

Ověřování požadavků a návrhu

Součástí procedur zajištění kvality je také prosazování řádného ověřování požadavků a návrhu, jehož cílem je omezení projektových rizik, která plynou z realizace částí projektu na základě chybných či neúplných vstupních požadavků nebo na základě návrhu, který by stanovené požadavky nerespektoval.



Strana 173 z 186

Veškeré požadavky musí vycházet z primárních požadavků definovaných v základním dokumentu projektu s tím, že je pouze vhodně upřesňují či doplňují, musí být specifikovány a odsouhlaseny kvalifikovanými subjekty a dále prověřeny. Tento cíl je zajištěn řízeným procesem konzultací / interview aplikací následujících kroků:

PM stanoví požadavky a strukturu konzultací / interview, zvolí vhodné osoby pro jednotlivé konzultace / interview (respondenty) a naplánují konzultace / interview.

Určení pracovníci provedou dle plánu jednotlivé konzultace / interview a zdokumentují je v podobě záznamů typu Zpráva / Zápis z jednání / Zápis interview, které jsou potvrzeny jednotlivými respondenty a prověřeny PM, případně dalšími jím určenými osobami.

Je-li třeba, jsou po dohodě provedeny další doplňující konzultace / interview.

Veškeré návrhy částí díla musí vycházet z požadavků Smlouvy a z požadavků získaných v rámci konzultací / interview tak, aby splňovaly příslušné záměry projektu. Tohoto cíle je dosaženo řízeným procesem přípravy návrhu, v rámci kterého:

Dodavatel musí písemně předkládat PT veškeré nové nebo zpřesňující návrhy řešení. PT musí zajistit řádné připomínkové řízení předložených návrhů a předat připomínky k

zapracování. Po zapracování všech připomínek musí být návrh schválen na úrovni PT (případně na vyšší

úrovni projektového týmu vyžaduje-li to jeho povaha).

Ověřování výstupů projektu

Cílem ověřování výstupů projektu je zajistit předání díla jak v jednotlivých částech tak vcelku v podobě a kvalitě, která je plně v souladu s požadavky základního dokumentu projektu a s požadavky a návrhy specifikovanými a odsouhlasenými v průběhu projektu.

Správa a dokumentace projektu

V této části Metodiky řízení projektu stanoví základní pravidla nakládání a správy dokumentace projektu.

Kategorie dokumentace

Dokumentace projektu je členěna na následně vymezené kategorie:

Řízená dokumentace projektu: Řízenou dokumentací projektu je veškerá dokumentace vyžadovaná smluvní dokumentací nebo metodikou řízení projektu, dokumentace sledovaná na úrovni vedoucích ŘT případně další dokumentace určená na úrovni PT. Jedná se nejen o výstupy projektu, ale také o důležitou podkladovou dokumentaci.

Pracovní dokumentace projektu: Pracovní dokumentací projektu je veškerá dokumentace či materiály zpracovávané účastníky projektu v rámci jim přidělených úkolů či přímo sloužící k plnění těchto úkolů včetně dokumentace jako jsou podklady.

Specifická dokumentace projektu: Specifickou dokumentací projektu je veškerá dokumentace či materiály zpracovávané v rámci projektu, se kterými, vzhledem k jejich charakteru, nelze nakládat výše uvedeným způsobem. Jedná se zejména o databáze, vytvářený programový kód a konfigurace.

Značení dokumentace

Pravidla značení dokumentace se vztahují na řízenou dokumentaci projektu s tím, že by měla být dodržována také pro zbývající typy dokumentace tam, kde je to možné. Značení (identifikace) jednotlivých dokumentů má základní strukturu Identifikator_Verze.Pripona, kde jednotlivé části identifikace mají následující význam:



Strana 174 z 186

Identifikátor: identifikační řetězec dokumentu ve tvaru NavestiUpresneniDoplnek tvořený: o návěštím a upřesněním: specifické řetězce, které charakterizující typ dokumentu,

o doplňkem: obecný text únosné délky dle uvážení autora dokumentu, který slouží ke zlepšení vypovídací hodnoty názvu souboru

Verze: řetězec zajišťující přehled o verzování dokumentu na úrovni názvu dokumentu (pokud má verzování smysl). Verze je standardně uváděna ve tvaru vNN.NN (např. v01.02). V některých případech – např. pracovních meziverzí v rámci pracovní dokumentace lze užívat vhodná rozšíření (např. v01.02a).

Přípona: řetězec dány typem souboru a vázáný především na používané programové vybavení (např. doc, xls, txt).

V rámci identifikace dokumentů (návěští, upřesnění, doplňku) smí být užíváno výhradně:

velkých a malých písmen bez diakritiky číslic 0 až 9 speciálních znaků „_“ a „-“

Je-li předán podklad projektu s daným názvem (např. z externích zdrojů, pak je s ním nakládáno s jeho původní identifikací.

Podrobnější informace o značení jednotlivých hlavních typů dokumentů je uveden v následující tabulce:

Popis Návěští Upřesnění Doplněk Verze Příklad Obecný dokument na který nepatří do žádné z dále uvedených skupin

DleUvážení _vNN.NN Obecny_dokument_v01.02

Šablona dokumentu Sab _DleUvážení _ vNN.NN Sab_priklad_v00.01 Zpráva o stavu projektu ZoS -XX _ vNN.NN ZoS-03_v00.01 Zápis z jednání vedoucích projektu číslo NN ze dne dd.mm.rrrr

ZJ -VP-XX_rrrrmmdd _ vNN.NN ZJ-VP-06_20090202_v01.00

Zápis z jednání Řídící rady číslo NN ze dne dd.mm.rrrr

ZJ -RR-XX_ rrrrmmdd _ vNN.NN ZJ-RR-02_20090202_v01.00

Zápis z jednání - ostatní číslo NN ze dne dd.mm.rrrr

ZJ -Os_ rrrrmmdd _DleUvážení _ vNN.NN ZJ-Os_20090202_Pom_v01.00

Zápis interview ze dne dd.mm.rrrr ZIn _ rrrrmmdd _DleUvážení _ vNN.NN ZIn_20090202_Modul

_v00.12 Zpráva ze dne dd.mm.rrrr Zpr _ rrrrmmdd _DleUvážení _ vNN.NN Zpr_20090202_Info_v01.00

Změnový požadavek číslo Z-XXXXX Z -XXXXX _ vNN.NN Z-00047_v01.02

Akceptační kritéria k akceptaci číslo XX AK -XX _DleUvážení _ vNN.NN AK-05_Ucetnictvi_v00.25

Akceptační protokol k akceptaci číslo XX (dle akceptačních kritérií)

AP -XX _DleUvážení _ vNN.NN AP-05_Ucetnictvi_v01.00

Závěrečný akceptační protokol AP-Z _ vNN.NN APZ_v01.00

Tabulka 3: Značení jednotlivých hlavních typů dokumentů

Nakládání s dokumentací

Pro nakládání s dokumentací jsou stanovena dle vymezených kategorií dokumentace následující zásady:

Řízená dokumentace projektu:



Strana 175 z 186

Řízená dokumentace projektu podléhá řízenému zpracování, verzování, předávání, uložení na určeném řízeném zdroji, zálohování, evidenci a řízení přístupu.

Pracovní dokumentace projektu: Pracovní dokumentace projektu podléhá pravidelnému ukládání na určeném zdroji pracovní dokumentace, zálohování a řízení přístupu.

Účastníci projektu odpovídají za údržbu své pracovní dokumentace na zdroji pracovní dokumentace v souladu s pokyny příslušného vedoucího projektového týmu v takovém stavu, aby tato dokumentace mohla být dále použita v případě nepřítomnosti účastníka nebo při poškození či ztrátě dokumentace na jiných zdrojích (např. lokální pracovní stanice).

Specifická dokumentace projektu: Specifická dokumentace projektu podléhá minimálně pravidelnému zálohování a řízení přístupu. Dále může být žádoucí verzování a další opatření. Veškerá opatření jsou určována a zajišťována specificky dle charakteru dokumentace určenými účastníky projektu.



Strana 176 z 186

Účtenková loterie Jedním z podpůrných nástrojů může být účtenková loterie. Základním účelem loterie je zvýšení známosti systému EET mezi spotřebiteli a podpora občanů – spotřebitelů při implementaci projektu (zavedení elektronické evidence tržeb) a identifikace poplatníků.

Účtenková loterie nebyla v žádné zemi organizována na obdobné podmínky, zejména způsob fiskalizace. Východiska z jiných zemí však mohou posloužit jako ilustrační a pomoci identifikovat klíčové vlastnosti možné loterie v České republice.

V případě loterie na Tchaj-wan šlo de facto o číselnou loterii, kde byla losována výherní čísla (koncovky) čísel účtenek. Účtenky bylo potřebné zaregistrovat jenom v případě výhry. Výhry byly odstupňovány podle počtu čísel (čtyřčíslí bylo nejmenší a šestičíslí nejvyšší z hlediska výhry). Nevýhodou byla náhodnost a možnost obchodníků generovat čísla účtenek z falešných pokladnic s nepravděpodobnými koncovkami, např. všechny stejné číslo 9999 apod.

Loterie v Slovenské republice byla postavena na principu registrované účtenky, kde podstatným registračním a odlišovacím znakem byli čísla registračních pokladen. Registrované účtenky, resp. čísla pokladen, byly porovnávány vůči databázi registračních pokladen a v případě chybného / neexistujícího čísla nebylo možné účtenku zaregistrovat. Bylo možné nahlásit špatně vystavenou účtenku, to však už nebylo odměněno šancí získat nějakou výhru. Z těchto důvodů byly registrovány zejména účtenky z obchodních řetězců, které však nebyly cílovou skupinou pro odhalování podvodných pokladen.

Z výše uvedených zkušeností vyplývá, že je vhodné orientovat účtenkovou loterii na oblast odhalování špatně vystavených účtenek..

Je možné předpokládat následující základní scénáře pro eventuální okruhy slosovatelných účtenek v rámci specifických „sub loterií“:

1. Účtenka je validní – obsahuje číslo účtenky poplatníka a i správný fiskální identifikační kód.

2. Účtenka může být validní, ale neobsahuje fiskální identifikační kód

3. Účtenka obsahuje nesprávný (falešný) fiskální identifikační kód

4. Účtenka obsahuje jiné nesprávné údaje (např. název poplatníka, datum, ičo nebo hodnotu DPH apod.)

Pozn.: Scénář nevydání účtenky vůbec není vzat v úvahu.

Ověření účtenky i její registrace by měla být co nejjednodušší. V naprosté většině případů bude postačovat jako první krok validace fiskálního identifikačního kódu. Po jeho validaci by měli být poskytnuty ověřovateli i doplňkové údaje jako jsou název poplatníka, nebo provozovny, datum a čas.

V případě negativního ověření, by měla být možnost registrace i této účtenky, minimálně pro kontrolní účely.

Právě účtenky, které nejsou validní, by mohly být zařazeny do slosování samostatně (čímž se dramaticky zvýší pravděpodobnost výhry) nebo uplatnit na ně nějaký bonus – žolíka.

Např. účtenky, které nemají fiskální identifikační kód a budou slosovány, mohou mít několikanásobnou výhru. Nebo účtenky, které mají fiskální identifikační kód, ale není validní, tj. je falešný, by mohli být zařazeny do samostatného slosování.



Strana 177 z 186

Preferováním neúplných nebo nevalidních účtenek je možno dosáhnout zvýšeného zájmu na získání právě těchto účtenek a tím vyhledávaní provozoven, které jsou více rizikové.

Je potřeba zvážit riziko falšování účtenek soutěžícími? Jde vlastně o jakýsi los, který ovšem nemá žádné ochranné prvky. Falšovat účtenky, kde je něco špatně nebo údaje chybí, je asi to nejjednodušší. Natisknu si libovolný počet účtenek, které nepůjdou žádným způsobem zkontrolovat (budou obsahovat falešné údaje, případně bude chybět údaj o obchodníkovi). Z pohledu výše uvedeného je ovšem taková účtenka vlastně nejcennější a mám šanci získat žolíka.

Účtenky, které nepůjdou ztotožnit s konkrétním dohledatelným obchodníkem, by neměly být do slosování zařazeny. Otázka je, zda a za jakých podmínek jsme schopni všechny účtenky kontrolovat.



Strana 178 z 186

Harmonogram projektu



Strana 179 z 186

Analýza přínosů a nákladů Analýza přínosů a nákladů je strukturována jako jednoduchá projekce nákladů a přínosů v čase. Některé obvyklé aspekty jako hodnota projektu nebo projekce rizik v čase nebyly do analýzy zahrnuty.

Důvodem použití jednoduchého modelu byl zřejmý převis přínosů na d náklady, kde jsou přínosy řádově vyšší než náklady. Nejedná se tudíž o standardní projekt, u kterého by rozhodování o projektu záviselo na výsledku analýzy nákladů a přínosů.

Uvedení výčtu přínosů a také nákladů však považujeme za důležité z hlediska získání přehledu o přínosech a nákladech a jejich struktuře.

Přínosy

Identifikace přínosů

Identifikace přínosů počítá jenom s jedním přínosem a to zlepšením výběru daní. Ostatní efekty, jako např. kultivace podnikatelského prostředí, snižování negativních efektů šedé ekonomiky apod. nejsou kvantifikovány.

U hlavního přínosu, vyšších příjmů z daní, byla realizována kvantifikace přínosu dvěma metodami. S ohledem na charakter kvantifikace (kvantum jsou samotné peněžní prostředky), se jedná de facto o přímou monetarizaci přínosů.

Kvantifikace byla prostřednictvím metod:

Kvantifikací přínosu prostřednictvím snížení podílu šedé ekonomiky, a

Kvantifikací přínosu prostřednictvím snížení odchylky ve výběru daní, tzv. VAT Gap.

Kvantifikace přes šedou ekonomiku

Friedrich Schneider: „Size and Development of the Shadow Economy of 31 European and 5 other OECD Countries from 2003 to 2013“

15,5% HDP11 za rok 2013, což představuje 596 mld. Kč. Pokles šedé ekonomiky byl v letech 2003 – 2013 cca 6% ročně.

Rozsah šedé ekonomiky není rovnoměrný, ale v jednotlivých odvětvích se liší. Největší podíl (až 25 – 35% z celé produkce) je v sektoru stavebnictví a téměř žádný v hornictví, bankovních službách a distribuci elektřiny. Ostatní sektory jsou nad 10% z celkové produkci v sektorech.

Podle statistického úřadu čtyři sektory, u kterých je podíl šedé ekonomiky nadprůměrný, mají podíl více než 31% na celkovém HDP.

Stavebnictví 7,4%

Obchod, opravy motorových vozidel a spotřební zboží 11,8%

Pohostinství a ubytování 1,9%

Doprava, skladování, pošty a telekomunikace 10,5%

Dá se předpokládat, že šedá ekonomika u těchto sektorů je více než 200 mld.

Samozřejmě, potřeba vzít v úvahu i jiné odvětví, jako jsou služby, zemědělství, výroba - zejména spotřebního zboží atd. Z tohoto důvodu byla jako základ pro výpočet odhadnuta hodnota 400 mld. šedé ekonomiky zasažené projektem EET.

11 3 845,93 mld. Kč za rok 2013



Strana 180 z 186

Propočet předpokládaných příjmů prostřednictvím potlačení šedé ekonomiky je vztaženo na % snížení celkové šedé ekonomiky následovně:

Scénář pesimistický konzervativní optimistický% transferu šedé ekonomiky 1 % 3 % 5 % přínos (navýšené daně) 4 mld. Kč 12 mld. Kč 20 mld. Kč

Kvantifikace VAT GAP

Byl použit propočet podle studie Evropské komise „Study to quantify and analyse the VAT Gap in the EU-27 Member States“ 12; konkrétně poměr („Household consumption VAT Liability“ k „Total VTTL“) a k „VAT Revenues“.

Jedná se tedy o předpokládaný podíl domácností na celkové daňové mezeře vypočtený jako podíl spotřeby domácností (61,7%) na daňové mezeře DPH (3,267 mld. Euro – 84,9 mld. Kč).

Samozřejmě, projekce dokonalého potlačení mezery je nereálná a v nejlepším státě EU (Holansko, Finsko) představuje 5%. Dosažení mediánu zemí EÚ (15%) je pro účely odhadu přiměřené jako maximální dosažitelná hodnota. Za rok 2012 byla hodnota daňové mezery DPH 22%. To zmanená, že v celkovém vyjádření by byla maximální dosažitelná hodnota 27 mld. Kč.

Dosažení této hodnoty jsme odhadli rozloženě v čase na následujících hodnotách v jednotlivých letech:

2016 2017 2018 2019 - 2021 2022 - 2024 % z předpokládané maximální dosažené hodnoty

10% 25% 40% 50% 60%

suma 2,7 mld. 6,75 mld. 10,8 mld. 13,5 mld. 16,2 mld.

Z obou metod vychází střednědobě objem dosažitelných přínosů 10 – 15 mld. Kč. Pro účely projekce přínosů v čase a srovnání s náklady byla použita hodnota 12 mld. Kč.

12http://ec.europa.eu/taxation_customs/resources/documents/common/publications/studies/vat-gap.pdf



Strana 181 z 186

Náklady

Iniciační náklady:

Rozpočet investiční fáze projektu ELEKTRONICKÁ EVIDENCE TRŽEB

Náklady investiční fáze projektu 390 907 355 Kč

Termín realizace investiční fáze 1.1.2015 - 31.12.2015

Název položky Odhadovaný náklad v Kč*

Organizace Projektový tým Způsob

objednávky Datum

dodávky Poradenství, konzultace

241 879 MF Projektový Přímá objednávka 1. 2. 2015

Poradenství PR a komunikace

1 500 000 MF Projektový Veřejná soutěž 2/15 -4/16

Externí právní poradenství, právní zastoupení

1 500 000 FS Právní a admin.

podpora Veřejná soutěž Trvale

Znalecké posudky 300 000 FS

Právní a admin. podpora

Veřejná soutěž Trvale

Implementace pilot 7 086 776 SPCSS Technický 7-12/2015

Správní poplatky, soudní poplatky

100 000 FS Právní a admin.

podpora Rozpočet Trvale

Kreativní agentura 2 000 000 FS PR a komunikace Veřejná soutěž 3/15 -9/16

Realizační a produkční práce

2 000 000 FS PR a komunikace VS a objednávka 4/15 - 9/16

Nákup medií přes agenturu

12 000 000 FS PR a komunikace Veřejná soutěž 8/15 - 9/16

Nákup medií napřímo

1 000 000 FS PR a komunikace Objednávka 8/15 - 9/16

Průzkumy a testy 500 000 FS PR a komunikace Objednávka 2/15 -12/16

Tisky a výroba 3D 1 000 000 FS PR a komunikace VS a objednávka 5/15 - 10/16

Ostatní náklady 500 000 FS PR a komunikace Objednávka 2/15 - 10/16 Osobní vozidla 3 500 000 FS Odborný VS, smlouvy 1. 1. 2016

Vzdělávání, vstupní příprava

175 000 FS Odborný VS, objednávka v limitu

1. 1. 2016

Ostatní věcné výdaje mimo programy

4 825 000 FS Odborný Objednávky,

smlouvy 1. 1. 2016

Jednorázové výdaje ICT (vybavení nových zaměstnanců)


smlouvy 1. 1. 2016

Osobní vozidla 2 800 000 CS Odborný Veřejná soutěž 1. 1. 2016

Mobilní kanceláře 8 000 000 CS Odborný Veřejná soutěž 1. 1. 2016 Vystrojení

3 044 200 CS Odborný Pokryto rámcovými

smlouvami 1. 1. 2016

Technické prostředky

818 500 CS Odborný Veřejná soutěž 1. 1. 2016

Informační technologie:

2 845 000 CS Odborný Veřejná soutěž Rámcová smlouva

CS

1. 1. 2016

1. 1. 2016

1. 1. 2016



Strana 182 z 186

Z toho: 80 chytrých telefonů 40 notebooků 40 přenosných tiskáren + 8x multifunkční tiskárna do mobilní kanceláře

VS - centrální zadávání MF VS - centrální zadávání MF

1. 1. 2016

Vybavení pracoviště 960 000 CS Odborný

VS - centrální zadávání MF

1. 1. 2016

Vybavení pracoviště 720 000 CS Odborný

VS - centrální zadávání MF

1. 1. 2016

Vzdělávání, vstupní příprava

2 365 000 CS Odborný Bez VS 1. 1. 2016

Výzbroj 1 050 000 CS Odborný Veřejná soutěž 1. 1. 2016

Call centrum 2 000 000 FS Front office 15. 10 .2015

Nastavení systémů ČP, procesní ICT

10 000 000 FS Front office Objednávka ČP 1. 6. 2015

Nastavení Call centra ČP Brno


Personální náklady na 2FTE


Mzdové náklady na 1 FTE

1 800 000 SPCSS Front office Existující smlouva 1. 3. 2015

Realizace komunikace (NIX)

24 200 000 SPCSS Technický Veřejná soutěž 1. 11. 2015

Certifikační autorita EET


Frontend vrstva 63 283 000 SPCSS Technický Veřejná soutěž 1. 11. 2015

Aplikační a DB vrstva


Storage a zálohování


ESB 4 235 000 SPCSS Technický Veřejná soutěž 1. 11. 2015

Service desk 1 210 000 SPCSS Technický Veřejná soutěž 1. 11. 2015

Aplikace EET (SW) 27 000 000 FS Technický Veřejná soutěž 1. 11. 2015

Úpravy ADIS 8 000 000 FS Technický JŘBÚ 1. 11. 2015

CELKEM 390 907 355 *včetně DPH



Strana 183 z 186

Provozní náklady:

Rozpočet provozní fáze projektu ELEKTRONICKÁ EVIDENCE TRŽEB

Náklady provozní fáze projektu 417 479 245 Kč

Termín realizace provozní fáze 1.1.2016 - 31.12.2016

Název položky Odhadovaný náklad v Kč*

Organizace Projektový tým Způsob

objednávky Datum

dodávky

Poradenství PR a komunikace

500 000 MF PR a komunikace Veřejná soutěž 2/15 -4/16

Obnova vozidel 2 700 000 CS Odborný VS 1x za 4 roky Trvale

Provoz vozidel 1 800 000 CS Odborný Navýšení rozpočtu Trvale

Vystrojení obnova 806 235 CS Odborný Navýšení rozpočtu Trvale

Obnova technických prostředků

163 700 CS Odborný Navýšení rozpočtu Trvale

Ostatní provozní náklady

2 080 000 CS Odborný Navýšení rozpočtu Trvale


800 000 CS Odborný Navýšení rozpočtu Trvale

Mzdové náklady 64 779 276 CS Odborný Navýšení rozpočtu

kalendářní rok

Provoz systému souvisejících s EET v systémech ČP

1 000 000 FS Front office Navýšení rozpočtuod 1. 1. 2016

Provoz technického callcentra ČP

600 000 FS Front office Objednávka ČP od 1. 1. 2016

Provoz zákaznického callcentra ČP

2 400 000 FS Front office Objednávka ČP od 1. 1. 2016

Kontrolní nákupy 10 000 000 CS Odborný Navýšení rozpočtu

trvale, kalendářní

rok

Výdaje na platy včetně příslušenství 133 979 147 FS Odborný

Navýšení rozpočtové položky

1. 1. 2016

Ostatní IT náklady 4 500 000 FS Odborný

Objednávky, smlouvy

1. 1. 2016

Kontrolní nákupy 20 000 000 FS Odborný Navýšení rozpočtu

trvale, kalendářní

rok Údržba/Obnova hardware


Housing 6 845 251 SPCSS Technický Veřejná soutěž 1. 1. 2016

Service Desk 30 700 346 SPCSS Technický Veřejná soutěž 1. 1. 2016

Aplikace EET (SW) 5 400 000 FS Technický Veřejná soutěž 1. 11. 2015

PR 2 000 000 FS PR a komunikace

Kalendářní

rok



smlouvy 1. 1. 2016

CELKEM 417 479 245

*včetně DPH



Strana 184 z 186

Návratnost projektu v čase

Obrázek 46: Roční náklady na projekt a výnosy z projektu v čase

Obrázek 47: Kumulativní náklady na projekt a výnosy z projektu v čase

0

10 000

20 000

30 000

40 000

50 000

60 000

2015 2016 2017 2018 2019 2020 2021 2022 2023 2024

Kumulativní náklady na projekt a výnosy z projektu v čase (v mil. Kč)

Náklady

Výnosy

0

1 000

2 000

3 000

4 000

5 000

6 000

7 000

8 000

2015 2016 2017 2018 2019 2020 2021 2022 2023 2024

Roční náklady na projekt a výnosy z projektu v čase (v mil. Kč)

Náklady

Výnosy

Přílo

Příloh

DAT

číslopole

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

ohy

a č. 1 – N

OVÁ ZP

o e

pole da

UUID

Datum

Identifizaslání

DIČ

Identifi

Identifi

Pořado

Datum

Způsob

Celková

Celková

Celkový

Celková

Celkový

Celková

Celkový

Celková

Částka v

ávrh obsa

PRÁVA

atové věty

a čas odeslá

kace, zda setržby

kace provoz

kace koncov

vé číslo účte

a čas přijetí

přidělování

á částka tržb

á částka nep

ý základ dan

á DPH s prvn

ý základ dan

á DPH s druh

ý základ dan

á DPH se zák

v DPH režim

ahu datov

ání zprávy

e jedná o pří

zovny

vého zařízen

enky

í tržby

í pořadovéh

by

podléhající D

ně s první sní

ní sníženou s

ně s druhou

hou sníženo

ně se základn

kladní sazbo

mu pro cesto

é věty účt

ípad opětov

ní

ho čísla účte

DPH

íženou sazb

sazbou

sníženou sa

u sazbou

ní sazbou DP

ou

ovní službu

tenky

ného

nky

ou DPH

zbou DPH

PH

typ po

VARCHAR

datum rozš

BOOL

alfanume

VARCHAR

VARCHAR

číseln

datum rozš

CHAR (

číseln

číseln

číseln

číseln

číseln

číseln

číseln

číseln

číseln

ole pozn

R(32)

"Hlasystapliz důstan

šířené DD.

L A/N

erické AAx

R(64) Přid

R(64) Defi

é Čísloprov

šířené

DD.pokse jeodetrže

(1) zobna úOče

é

é vypl

é vypl

é vypl

é vypl

é vypl

é vypl

é vypl

é vypl

námka

avička" datotém EET muskováno i v původu chybyndardní údaj

MM.RRRR H

N

xxxxxxxx, kde

dělováno pro

inuje poplat

o účtenky v vozovny. Ur

MM.RRRR Hud byla vystedná o vystaslání zprávyeb)

razuje způsoúrovni provoekáváme P ‐

lňují jen plát

lňují jen plát

lňují jen plát

lňují jen plát

lňují jen plát

lňují jen plát

lňují jen plát

lňují jen plát

ové zprávy, ksí obsahovapřípadě, že sy při realizacj. Generován

HH.MM.SS.

obsa

e AA je písm

ovozovně v r

tník.

rámci danéhčováno polo

HH.MM.SS. Ptavena dříveavení účtenky o více jak 4

ob přidělováozovny neboprovozovna

tci DPH

tci DPH

tci DPH

tci DPH

tci DPH

tci DPH

tci DPH

tci DPH

hlavička každá zprávat identifikáte jedná o opci při doručení UUID pod

ah datové vě

meno a xxxxx

rámci její re

ho koncovéožkou č. 8. R

Případně dae viz datová ky, neměl by48 hodin (res

ání pořadovéo individuálna, M ‐ poklad

a zaslaná naor té zprávypakované zaní zprávy. Jedléhá patřičn

ěty

xxxx jsou čís

gistraci v IS

ho zařízení nRestart vždy

tum vystavepoložka č. 2y se tento časp. 120 dle r

ého čísla účtně z pokladndní místo)

centrální y. Toto saméaslání této zedná se o nému stand

lice.

EET.

nebo v rámck 1. 1.

ení účtenky,27. V případěas lišit s daterežimu evide

tenky centráního místa.

ověvs

é je právy

ardu.

A

A

A

A

A

ci A

, ě, že em ence

A

álně

A

ěření na stupu

po

ANO Přté

ANO Přté

ANO

Osysh

ANO Přté

ANO Přté

ANO Přté

ANO Přté

ANO Přté

oznámka k o

ři příchodu déto položky.


věření při přyntaxe DIČ, nhodovat s id






Spec

ověřování

datové zpráv

datové zpráv

říchodu datonevaliduje jeentifikátore

datové zpráv

datové zpráv

datové zpráv

datové zpráv

datové zpráv

Minis

cifikace proje

vy se kontro

vy se kontro

ové zprávy peho existencem certifikát

vy se kontro

vy se kontro

vy se kontro

vy se kontro

vy se kontro

sterstvo financ

ktu Elektronic

oluje pouze

oluje pouze

provádí pouci. DIČ se mtu.

oluje pouze

oluje pouze

oluje pouze

oluje pouze

oluje pouze

cí České repu

cká evidence

Strana 185

přítomnost

přítomnost

uze kontrolu musí také

přítomnost

přítomnost

přítomnost

přítomnost

přítomnost

ubliky

tržeb

5 z 186

19

20

21

22

23

24

25

26

27

28

29

30

legend

Částka v

Částka v

Celkem

Celkem

Celkemelektro

Celkemelektro

BKP

Způsob

Idenfikanebo čá

Celkovásubjekt

Typ zas

rezerva

da: položky

v DPH režim

v DPH režim

m za vydané v

m za přijaté v

m za prodej mnické peněž

m za užití munické peněž

platby

ace subjektuásti tržby z ú

á částka tržbtu

lání účtenky

a

y obdobné C

mu pro prode

mu pro inves

vratné obaly

vratné obaly

multi‐purposženky

lti‐purpose ženky

u (DIČ) v přípúčtenky jmé

by inkasován

y

Chorvatském

ej použitého

tiční zlato

y (speciální D

y (speciální D

se voucherů

voucherů ne

padě vydánínem tohoto

na jménem j

mu modelu

o zboží

DPH režim)

DPH režim)

ů, nabití

ebo

í účtenky, o subjektu

jiného

číseln

číseln

číseln

číseln

číseln

číseln

VARCHAR

CHAR (

alfanume

číseln

číselní

XML Elem

é vypl

é vypl

é

é

é

é

R (64) nesm

(1) (hot

erické Příkkdy bud

é

ík Běžn

ment

PolorezeelemTyp

lňují jen plát

lňují jen plát

mí být již po

tovost, karta

kladem je tržúčtenka je ve DIČ obcho

ný/zjednodu

ožka, která servních poloment pro ID (datový typ

tci DPH

tci DPH

oužit dříve, b

a, poukázka,

žba provedevystavena nodu.

ušený režim

se může opaožek. Každá r(číselný uni

p dle číselník

bezpečnostn

,…)

ena na e‐shoa České poš

evidence

akovat v liborezervní polkátní identifku), Hodnota

ní kód popla

op s platbou ště, identifik

ovolném počožka bude ofikátor rezera.

tníka

typu dobírkkace v tomto

čtu podle poobsahovat rvní položky

A

ka, o poli

očtu

y),

ANO Přté


Spec

datové zpráv

Minis

cifikace proje

vy se kontro

sterstvo financ

ktu Elektronic

oluje pouze

cí České repu

cká evidence

Strana 186

přítomnost

ubliky

tržeb

6 z 186

Date post:	13-Apr-2017
Category:	Technology
Upload:	not-andrej-babis
View:	4,407 times
Download:	6 times

EET Specifikace projektu final_v22

Technology