Požadavek na změnu (RfC) i A – VĚCNÉ ZADÁNÍ 1 Základní informace ID SD MZe ii : Z22476 ID ShP MZe iii : 2016_0031_187 ID PK MZe iv : 347 Název změny v : MZK – Soubor drobných úprav webových služeb a funkcionalit MZK Datum předložení požadavku: Požadované datum nasazení: 31.3.2018 Kategorie změny vi : Normální ☒ Urgentní ☐ Priorit a vii : Vysoká ☒ Střední ☐ Nízká ☐ Oblas t: Aplikace ☒ Kód viii : MZK Verze : Typ požadavku : Legislativní ☒ Zlepšení ☒ Reklamace ☐ Bezpečnost ☐ Infrastruktu ra ☐ Typ požadavku : Nová komponenta ☐ Upgrade ☐ Bezpečnost ☐ Role Jméno Organizace /útvar Telefon E-mail Žadatel: … … … … Metodický / věcný garant: … … … … Change koordinátor: … … … … Poskytovatel / dodavatel: … … … … Smlouva č. ix : 353-2015-13310 /1, 2 (S2016- 0118) KL: HR-001 Stupeň důvěrnosti: Veřejné Strana 1 z 1
Transcript
Požadavek na změnu (RfC)i
A – VĚCNÉ ZADÁNÍ1 Základní informace
ID SD MZeii: Z22476 ID ShP MZeiii: 2016_0031_187 ID PK MZeiv: 347
Název změnyv: MZK – Soubor drobných úprav webových služeb a funkcionalit MZKDatum předložení požadavku: Požadované datum nasazení: 31.3.2018
Kategorie změnyvi: Normální ☒ Urgentní ☐ Prioritavii: Vysoká ☒ Střední ☐ Nízká ☐
Oblast:Aplikace ☒
Kódviii: MZK Verze:
Typ požadavku: Legislativní ☒ Zlepšení ☒ Reklamace ☐ Bezpečnost ☐
Infrastruktura ☐ Typ požadavku: Nová komponenta ☐ Upgrade ☐ Bezpečnost ☐
Předmětem požadavku jsou následující úpravy systému MZK: úprava webové služby MZK_CC_03G. Webová služba MZK_CC_03G předává z IS
dozorových orgánů seznam žadatelů ke kontrole po provedení aktualizace (přidání či odebrání kontrol) do dB MZK, kde je očekáván příchod Zprávy o kontrole (ZODK) popř. Zprávy o osvědčení parametrů (ZOP). V případě zrušení plánované kontroly se aktualizace projeví snížením počtu plánovaných kontrol na žadatele a směrnici. Při zrušení plánované kontroly ze strany SZIF pak dochází k situacím, kdy je odplánována i kontrola, která je ze strany dozorových orgánů již provedena, uzavřena a byl doručen ZODK popř. ZOP do MZK. Na základě požadavku dozorových orgánů je třeba webovou službu MZK_CC_03G upravit tak, aby v případě, kdy je v MZK detekován vyšší počet doručených ZODK popř. ZOP než je počet naplánovaných kontrol zaslaných na žadatele v request webové služby MZK_CC03G byl nový plán kontrol pro tento subjekt odmítnut.
Stupeň důvěrnosti: Veřejné Strana 1 z 1
Vnitřní rozlišení počtu plánovaných kontrol dle autora plánu – v rámci plánu kontrol dojde na úrovni MZK k úpravě datového modelu a počty plánovaných kontrol budou evidovány nově k: Podoblasti Roku Subjektu Dozorový orgán Typ kontroly (CC, DK,NK) Forma kontroly (1 - Řádná (plánovaná), 2 - Mimořádná (neplánovaná)., 3 - Následná) Výběr kontroly (1 = Náhodný výběr, 2 = RA, 3 = Manuálně) Autoru plánu Následně bude tato skutečnost zohledněna v nové verzi služby MZK_CC13D.
úpravy nápočtu rizikovosti lesnických opatření – zahrnutí opatření LESOENVI do výpočtu a zajištění, že u těchto opatření se budou brát v doplňkové rizikové analýze údaje z roku N-1 neboť údaje z roku N nejsou k dispozici a data by nebyla srovnatelná
úprava služby APA_CC14B ve smyslu rozšíření o atribut OPAKOVANI, který bude datově vyhodnotitelný a následná sestava Kontrol a porušení CC bude nově obsahovat údaj o tom, zda při výpočtu sankce bylo zohledněno opakování nebo nikoliv
úprava služby APA_CC06B (InfoOMoznemVyhodnoceniCC) z důvodu poskytnutí přesnějších dat k tomu, aby SZIF mohl efektivně stáhnout ZOK a realizovat následnou administraci dotací.
úprava šablony ZOK - Předmětem požadavku jsou úpravy šablony ZoK v systému MZK, které byly částečně navrženy dozorovými organizacemi podílejícími se na provádění kontrol podmíněnosti nebo iniciovány změnou hodnotícího systému CC. Všechny úpravy byly společně s dozorovými organizacemi projednány a mimo jiné mají dopad do služeb MZK_CC_04 a MZK_CC_05
Zajištění možnosti vyhledávání ZoK, které byly v MZK zrušeny – jedná se o neplatné ZoK, které byly oprávněně zrušeny a které dnes nelze standardním způsobem vyhledat
úprava chování IZR tak, aby odesílání ZoK/ZoDK přes EPO zasílalo v samostatných transakcích sériově – tímto opatřením dojde k eliminaci problému vzniku technických chyb při paralelním odesílání ZoK z IZR přes EPO do MZK.
2.2 Odůvodnění požadované změny (legislativní změny, přínosy)Nová verze služby MZK_CC03V současnosti webová služba MZK_CC_03G umožňuje při zrušení plánované kontroly ze strany SZIF odplánovat kontrolu, přestože je ze strany dozorových orgánů tato kontrola již provedena, uzavřena a byl doručen ZODK popř. ZOP do MZK. Tímto vznikají nekonzistence. V nové verzi je cíl doplnit validace, které to ošetří.
V současnosti webová služba nepředává registrační číslo žádosti a termín, dokdy má být kontrola zrealizována. Registrační čísla žádostí jsou předávána mezi SZIF a ČPI prostřednictvím excelovských souborů a ručně přepisována do OLK ČPI. Úpravou dojde k eliminaci chyb v číslech žádostí, která jsou doplňována do tiskopisů předávaných kontrolované osobě a do ZODK.
Vytvoření nové verze D služby MZK_CC13Pokud jde o rozčlenění počtu kontrol dle autora plánu je toto opatření nutné, aby nedocházelo ke křížovým mazáním počtu kontrol zpravidla mezi SZIF a některým dozorovým orgánem
Úprava nápočtu rizikovosti lesnických opatřeníZ důvodu zajištění srovnatelnosti údajů při výpočtu standardní RA a doplňkové RA musí být u lesoenvi opatření brány v potaz údaje z roku N-1, protože údaje z roku N nejsou k dispozici
Úprava služby APA_CC14B a sestavy Porušení CC
Stupeň důvěrnosti: Veřejné Strana 2 z 1
Cílem je doplnění informace o opakování porušení, aby následná sestava vyhodnocení CC pro Mze byl úplná.
Nová verze C služby APA_CC06Důvodem je nemožnost efektivně vyhodnocovat informace o doručených ZOK, ZODK a ZOP. Struktura služby neodpovídá dosavadním potřebám. Ve službě navíc chybí informace o doručených zpráv o kontrole.
Úprava obsahu ZOKa. Nutnost uvádět typ kontroly
V případě zjištění porušení požadavků CC z jakékoli kontroly je záznam veden v šabloně ZoK CC. Šablona ZoK dále obsahuje informaci o formě kontroly nebo výběru kontroly nikoliv již o typu prováděné kontroly. Zjištění pak nelze správně evidovat pro účely statistky kontrol, přičemž šablona ZoK CC je v tomto případě správně použita, neboť se jedná o zjištění porušení CC. V poli bude zobrazen typ kontroly, pod kterým byla kontrola zavedena v plánu např. NK, Kontrola delegovaná ze SZIF na ÚKZÚZ, v případě plánované kontroly CC bude uvedeno typ kontroly CC.
b. Popis nálezu úmyslného porušení Uvedení informace, z jakého důvodu je zjištěné porušení považováno za úmyslné je nezbytné pro informování kontrolovaného subjektu zejména s ohledem na skutečnost, že v rámci kontroly národní legislativy není kritérium úmyslu používáno. Informaci o hodnocení úmyslného porušení v rámci CC bude uváděna v samostatném poli protokolu a z něj přenášena do ZoK.
c. Stržené body V souvislosti se změnou systému vyhodnocování nedodržení požadavků CC, kdy byl bodový systém nahrazen transparentnějším systémem hodnocení každého požadavku zvlášť, není pole v ZoK Stržené body využíváno a proto bude vyřazeno
d. Důvod neuložení nápravného opatřeníSe změnou systému vyhodnocování souvisí i změna používání institutu nápravných opatření, který vylučuje alternativu uváděnou v poli Důvod neuložení nápravného opatření, kde byly zaznamenávány okolnosti nemožnosti uložení nápravného opatření v případě odstranitelného porušení.Vyhledávání ukončených zpráv v aplikaci MZK Z důvodu nutné evidence zpráv o kontrole i po ukončení jejich platnosti v řádně odůvodněných případech je potřeba připravit vyhledávání těchto zpráv v MZK. V současné době po ukončení platnosti ZoK na základě požadavku organizace, která ZoK vystavila, není dále ZoK v systému MZK zobrazená a vyhledatelná. Jejich evidence je vedena externě, ale vhodnější způsob je její vedení v rámci systému MZK.Zajištění odesílání zpráv z IZR/ČPI v samostatných transakcích Důvodem k realizaci tohoto kroku jsou dosavadní zkušenosti, kdy v současné době dokázaly odejít podepsané totožné zprávy o kontrole ve shodné verzi díky tomu, že byly podepisovány dvěma vedoucími současně.
2.3 Rizika nerealizaceÚprava služby MZK_CC03V případě, že nebude požadavek realizován, bude nadále docházet k odplánování již provedených kontrol a následné nekonzistenci plánu a nutnosti zadávat jednotlivé incidenty, které tyto nekonzistence ručně řeší na úrovni DB, což je nežádoucí stav.
Vytvoření nové verze D služby MZK_CC13Obdobným rizikem je nerozdělení počtu plánovaných kontrol dle autora plánu, protože stávající stav vede na nepřiměřené množství manuálních řešení úprav plánu v důsledku vzniklých nekonzistencí.
Úprava nápočtu rizikovosti lesnických opatření
Stupeň důvěrnosti: Veřejné Strana 3 z 1
V případě, že nebude úprava realizována, bude rizikový koeficient u subjektů žádajících o lesoenvi napočítán zavádějícím způsobem.
Úprava služby APA_CC14B a sestavy Porušení CCV sestavě vyhodnocení CC z MZK bude nadále chybět podstatná informace o opakování porušení.
Nová verze C služby APA_CC06V případě nerealizace bude přetrvávat stav, kdy SZIF není schopen efektivně využívat informace ze služby o možném vyhodnocení kontrol a je nucen subjekty posuzovat manuálně.
Úprava obsahu ZoKV případě nerealizace nebudou naplněny závěry z jednání s dozorovými orgány, čímž bude přetrvávat nevyhovujcí stav.
Zajištění odesílání zpráv z IZR/ČPI v samostatných transakcích V případě nerealizace bude přetrvávat stav, kdy může dojít k nekorektnímu odmítnutí zprávy na EPO se shodným ID a verzí a nutnost realizovat následné ruční zásahy do stavu zprávy.
3 Podrobný popis požadavkuVytvoření nové verze H webové služby MZK_CC_03 PutPlanKontrolDOD
3.1.1.1 Vytvoření nové kontroly na počet doručených ZOK, ZOP a ZoDKV MZK bude vytvořena nová kontrola na počet doručených ZOK, ZOP a nová kontrola na počet doručených ZODK. Počet naplánovaných kontrol za subjekt zaslaný v request webové služby MZK_CC_03H bude v MZK porovnáván s počtem doručených ZODK a s počtem doručených ZOP. V případě, že je v MZK detekován vyšší počet doručených ZODK popř. ZOK, ZOP než je počet naplánovaných kontrol zaslaných v request webové služby MZK_CC_03G, bude nový plán kontrol pro tohoto žadatele a směrnici odmítnut, čímž bude zabráněno odplánování kontroly (validace bude na celkový počet doručených ZoDK/ZOK/ZOP, nebude reflektovat od jakého autora byla pochází plán). Nová verze webové služby bude oproti původní verzi upravena v části response tak, aby v odpovědi předala seznam žadatelů, u nichž je nový plán kontrol odmítnut, včetně kódu a textu chyby obsahující důvod odmítnutí nového plánu kontrol – viz datová struktura response.
3.1.1.2 Doplnění nového atributu pro určení nejzazšího data kontroly naplánované kontroly pro ČPI
Do struktury web. služby MZK_CC_03H bude doplněná do atributu DoplnkoveInfo nová hodnota výčtu „ZKONTROLOVAT_DO_DATA“ a v poli DoplnkoveInfo v atributu HodnotaString bude uvedená datumová hodnota, kterou bude plnit IS SZIF při odeslání plánu do MZK. Následně se tato informace bude přenášet do systému IZR/LPIS.
3.1.1.2.1 Dopad do GUI aplikace MZKV aplikaci MZK v sestavě MZK> Plán kontrol budou doplněné nové sloupce:
Zkontrolovat do - který bude plněn datem uveden na v vstupu web. služby. Opatření ID/Název Opatření ID/Název - pokud bude víc titulů, tak odděleno čárkami
Datová struktura request MZK_CC_03H:XML Element (@atribut) Typ Výskyt Omezení Popis
Data 1 - 1 Předávaná data
Request 1 - 1 Element označující data požadavku, předávaná konzumentem zdrojovému systému.
Stupeň důvěrnosti: Veřejné Strana 4 z 1
RokPlanovaneKontroly int 1 - 1 Počet platných číslic: 4
Rok N, vztahující se k období, na něž žadatel o dotaci žádá.
KodDozorovyOrgan int 1 - 1 Počet platných číslic: 5
Identifikace IS dozorového orgánu, ze kterého je posílán seznam plánovaných kontrol (z číselníku DozorovyOrgan).
KodOss int 1 - 1 Počet platných číslic: 5
Identifikace OSS (resp. dozorového orgánu), který kontrolu naplánoval (KOD z číselníku OSS).
SeznamZadatelu 1 - 1 Seznam žadatelů.
Zadatel 0 - N Opakující se element pro jednoho žadatele.
VyberKontroly int 1 - 1 Počet platných číslic: 1Hodnoty: { 1, 2, 3, 4, 5 }
Označuje, jak byla plánovaná kontrola vybrána. Enum s hodnotami 1 = Náhodný výběr 2 = RA 3 = Manuálně
DatumPlanu date 1 - 1 Datum, pro který byl plán kontrol poprvé vytvořen.
TerminKontroly int 0 - 1 Počet platných číslic: 1Hodnoty: { 1, 2 }
Tabulka PlanovanyZadatelKeKontroleDO, atribut TerminKontroly 1 - kontrola před podáním žádosti/v průběhu retenčního období, 2 - kontrola po podání žádosti/po retenčním období.
DoplnkoveInfo 0 - N Opakující se element dodatečných informací
KodInfo string 1 - 1 Varchar Kód doplňkové info - bude definováno výčtem v enum WSDL (dosavadní hodnoty OMEZENI_DT a DUVOD_VYBERU a ZKONTROLOVAT_DO_DATA)
HodnotaString string 0 - 1 Varchar Hodnota doplňkové info - string (zatím bude používáno pro výčet rizikových faktorů, které způsobily výběr subjektu ke kontrole anebo plnění nejzazšího data)
HodnotaInt numeric 0 - 1 Integer Hodnota doplňkové info – číslo. Zatím bude využíváno pro plnění hodnot pro Info OMEZENI_DT, a to ID dotačního titulu, na který má být kontrola omezena dle primárního číselníku SDB.
RegCisloZadosti string 0 - 1 Varchar Registrační číslo žádosti dle dat SZIFOpatreniNazev string 0 - 1 Varchar Název opatření
OpatreniID numeric 0 - 1 Integer ID opatření
Stupeň důvěrnosti: Veřejné Strana 5 z 1
Tituly 0-1 Opakující se poleTitulNazev string 1 - 1 Varchar Název tituluTitulID numeric 1 - 1 Integer ID titulu
Kontrola na straně MZK Pokud nebude souhlasit vazba PodoblastEU v MZK a ID Opatření/Titulu uvedené ve
webové službě dle externího číselníku v SDB, bude řádek plánu odmítnut. Tvrdá validace.
Datová struktura response MZK_CC_03H:XML Element (@atribut) Typ Výskyt Omezení Popis
Data 1 - 1 Předávaná data
Response 1 - 1 Element označující data odpovědi, která vrací zdrojový systém konzumentovi.
Kód chyby int 1 - 1 Počet platných číslic: 1
1 – v MZK je více doručených ZODK2 – v MZK je více doručených ZOP
Text chyby string 1 - 1 Max. délka: 100 Pro kód 1 - Pro subjekt nelze naplánovat nižší počet kontrol než je počet doručených ZODK v MZKPro kód 2 - Pro subjekt nelze naplánovat nižší počet kontrol než je počet doručených ZOP v MZK
SeznamZadateluChyba 1-1 Seznam žadatelů, u nichž bylo v MZK detekováno více doručených ZODK popř. ZOP než je počet naplánovaných kontrol zaslaných v request
Zadatel 0 - N Opakující se element pro jednoho žadatele.
VyberKontroly int 1 - 1 Počet platných číslic: 1Hodnoty: { 1, 2, 3, 4, 5 }
Označuje, jak byla plánovaná kontrola vybrána. Enum s hodnotami 1 = Náhodný výběr 2 = RA 3 = Manuálně
DatumPlanu date 1 - 1 Datum, pro který byl plán kontrol poprvé vytvořen.
Stupeň důvěrnosti: Veřejné Strana 6 z 1
TerminKontroly int 0 - 1 Počet platných číslic: 1Hodnoty: { 1, 2 }
Tabulka PlanovanyZadatelKeKontroleDO, atribut TerminKontroly 1 - kontrola před podáním žádosti/v průběhu retenčního období, 2 - kontrola po podání žádosti/po retenčním období.
3.1.1.2.2 Dopad do ostatních informačních systémů dozorových orgánůZe strany LPIS a IZR je nezbytné zajistit:
Implementaci kleinta nové verze web. služby MZK_CC_03H Zajistit na své straně konzumaci odpovědi služby, kdy některé položky plánu mohou být
odmítnuty Úprava zobrazení plánu (zohlednění nového pole „zkontrolovat do data“)
3.1.1.3 Úprava response služby MZK_CC13 nové verze EÚprava odpovědi spočívá v následujících změnách:
zpřesnění elementu počtu plánovaných kontrol dle autora plánu rušení atributu PVPSkot a PVPOvceKozy a TerminKontroly – tyto informace budou
předávány standardně v poli DoplnkoveInfo doplnění nového výčtu ZKONTROLOVAT_DO_DATA v poli DoplnkoveInfo doplnění nové struktury návaznosti na číselník opatření:
a. RegistracniCisloZadostib. OpatreniNazevc. OpatreniIDd. Pole Tituly (0..N)
TitulNazev TitulID
Typ Výskyt Omezení PopisResponse 1 - 1 Element označující data
odpovědi, která vrací zdrojový systém konzumentovi.
SeznamZadatelu 1 - 1 Seznam žadatelů.Zadatel 0 - N Opakující se element pro
VyberKontroly int 1 - 1 Počet platných číslic: 1Hodnoty: - 1- 2- 3- 4- 5
Označuje, jak byla kontrola vybrána. Enum s hodnotami 1 = Náhodný výběr 2 = RA 3 = Manuálně
Stupeň důvěrnosti: Veřejné Strana 7 z 1
DatumPlanu date 1 - 1 Datum, pro který byl plán kontrol poprvé vytvořen.
PoctyKontrol 0 - N Pole
AutorPlan int 1 - 1 Autor plánu dle hodnoty inquer uložené v MZK
Autor plánu
PocetPlanKontrol int 1 - 1 Počet platných číslic: 2
Počet plánovaných kontrol.
PocetZOK int 1 - 1 Počet platných číslic: 2
Počet platných ZOK již v MZK uložených - k danému žadatelerok pro podoblastEU/typplankontroly/ formakontroly/výběr; v případě, že se jedná o podoblastEU pro DK, bude zde počet ZoDK.
RegCisloZadosti string 0 - 1 Varchar Registrační číslo žádosti dle dat SZIF
OpatreniNazev string 0 - 1 Varchar Název opatřeníOpatreniID numeric 0 - 1 Integer ID opatřeníTituly 0-1 Opakující se pole
TitulNazev string 1 - 1 Varchar Název titulu
TitulID numeric 1 - 1 Integer ID tituluPVP_Skot int 0 - 1 Počet platných
číslic: 1Hodnoty: - 0- 1
Tabulka PlanovanyzadatelKeKontroleDO, artibut PVP_Skot: 0 - Kontrola PVP Skot ANO 1 - Kontrola PVP Skot NE (nepovinný)
PVP_OvceKozy int 0 - 1 Počet platných číslic: 1Hodnoty: - 0- 1
Tabulka PlanovanyzadatelKeKontroleDO, artibut PVP_Ovce:0 - Kontrola PVP Ovce ANO1 - Kontrola PVP Ovce NE (nepovinný)
TerminKontroly int 0 - 1 Počet platných číslic: 1Hodnoty: - 1- 2
Tabulka PlanovanyZadatelKeKontroleDO, atribut TerminKontroly 1 - kontrola před podáním žádosti/v průběhu retenčního období, 2 - kontrola po podání žádosti/po retenčním období.
AutorPlanu string 1 - 1 Autoro plánu.SeznamDoplnkoveInfo 0 - 1 Seznam elementu
DoplnkoveInfoDoplnkoveInfo 0 - N Opakující se element
Kód doplňkové info - bude definováno výčtem v enum WSDL (dosavadní hodnoty OMEZENI_DT a DUVOD_VYBERU a ZKONTROLOVAT_DO_DATA)
Stupeň důvěrnosti: Veřejné Strana 8 z 1
HodnotaString string 0 - 1 Hodnota doplňkové info - string (zatím bude používáno pro výčet rizikových faktorů, které způsobily výběr subjektu ke kontrole anebo plnění nejzazšího data)
HodnotaInt int 0 - 1 Hodnota doplňkové info – číslo. Zatím bude využíváno pro plnění hodnot pro Info OMEZENI_DT, a to ID dotačního titulu, na který má být kontrola omezena dle primárního číselníku SDB.
SeznamDoplnkoveInfoZOP 0 - 1 Seznam elementu DoplnkoveInfo ZOP
DoplnkoveInfoZOP 0 - N Opakující se element dodatečných informací pro ZOP.
Hospodarstvi string 1 - 1 CZ HospodářstvíZmena boolean 0 - 1 Údaj, zda se jedná o změnu
proti předchozímu roku – pokud true, žadatel vloni na daný objekt žádal a chce změnu, jinak false
SeznamObjektu 1 - 1 Seznam elementu DoplnkoveInfo ZOP
Objekt 1 - N Opakující se element dodatečných informací.
KodObjektu int 1 - 1 Kód objektu dle LPISZmena boolean 0 - 1 Údaj, zda se jedná o změnu
proti předchozímu roku – pokud true, žadatel vloni na daný objekt žádal a chce změnu, jinak false
Vybeh boolean 1 - 1 Je součástí objektu výběh nebo ne.
VybehCtverec string 0 - 1 Čtverec DPB, na kterém může být výběh (není-li vyplněno, není výběh realizován na DPB)
VybehKod string 0 - 1 Zkrácený kód DPB, na kterém může být výběh (není-li vyplněno, není výběh realizován na DPB).
string 1 - 1 Hodnoty: - xml- base64
Typ datového obsahu (xml - data jsou ve formátu XML s vlastním jmenným prostorem; base64 - data jsou předána jako řetězec kódovaný pomocí base64)
3.1.1.3.1 Dopad do ostatních informačních systémůLPIS a IZR musí na své straně zajistit:
Implementaci klienta nové verze web. služby MZK_CC13 nové verze E (příjem plánu)
Stupeň důvěrnosti: Veřejné Strana 9 z 1
Současně na své straně zajistí úpravu dat. modelu uložení plánu kontrol tak, aby byl zřejmý počet plánovaných kontrol od příslušného autora a vazba na opatření/titul
Na straně LPIS/IZR bude doplněná funkcionalita zobrazení data uvedeného v položce ZKONTROLOVAT_DO_DATA a RegistracniCisloZadosti včetně následného plnění tohoto čísla do ZoDK
3.1.1.4 Úprava nápočtu rizikovosti lesnických opatřeníPro CC jsou relevantní následující opatření (O=opatření, T=titul):
LES-PAN-E – Péče + Náhrada EAFRDo ID 339 Oo ID 352 To ID 353 T
Péče o lesy P15o ID 404 Oo ID 407 To ID 408 T
LESOENVI a spol. F6, F8, F26, F27o ID 301 Oo ID 303 To ID 304 To ID 316 To ID 401 T
V SDB budou mít všechny výše uvedené tituly a opatření nastaveny parametr MZK_VISIBLE = ANO. V MZK při stanovení rizikového koeficientu SZIF pro výpočet doplňkové rizikové analýzy v roce N v případě opatření LESOENVI (ID 301, 303,304,316, 401) budou použita data roku N-1, z důvodu nedostupnosti dat za aktuální rok.
3.1.1.4.1 Dopad do ostatních informačních systémů: Bez dopadu na IS DO
3.1.1.5 Rozšíření response služby APA_CC14B o atribut opakováníRozšíření služby je znázorněno v následujícím response. Návazně na toto rozšíření bude upravena sestava „porušení“ v MZK tak, aby přebírala hodnoty porušení doručené službou.Úprava sestavy „Sestava dle požadavku“:
V sestavě zobrazené v tabulce v aplikaci nedojde k žádné změně (sloupec v tabulce v aplikaci není a nebude nově přidán, sloupec je zobrazena v XLS výstupu a bude i nadále ponechán, ale plněn jiným způsobem)
V tabulce exportované do CSV dojde k této změně:o Sloupec „Opakování“ u jednotlivých řádku požadavku bude plněn hodnotou z
webové služby APA_CC_14Bo Pokud služba nevrátí žádnou hodnotu anebo dojde k chybě při volání web.
služby, tak sloupec pro tento požadavek bude prázdnýESBServerEnvelopeResponse 1:1 Obálka datové komunikace pro
odpovědiData 1:1 Předávaná data
Response 1:1Element označující data odpovědi, která vrací zdrojový systém konzumentovi.
Celkové procento snížení dotací pro dotační tituly přímých plateb.
Stupeň důvěrnosti: Veřejné Strana 10 z 1
SeznamKrokuVypoctu 0 - N
Seznam jednotlivých kroků výpočtu sankcí v textové podobě
PopisKrokuVypoctu string 1:1 Popis jednoho kroku výpočtu sankce.
PocetOpakovani 0 - N Počet opakování porušení
KodPozadavku int 1:1 Kód požadavku
PocetOpakovani int 1:1
Počet opakování v rámci požadavku.1 – 1x2 – 2x a vícekrát
Interně v MZK se při uložení ZOKu v tabulce HodnoceniPoruseniPozadavku nový sloupec, který bude plnit ze služby z položky „PocetOpakovani“
3.1.1.5.1 Dopad do ostatních informačních systémů: Bez dopadu na IS DO
3.1.1.6 Specifikace nové verze služby APA_CC06B (vytvoření nové verze APA_CC06C)
Služba doposud funguje tak, že MZK volá SZIF a předává informace o možném vyhodnocení kontrol. Data jsou zasílána v requestu, response je na úrovni statutu http 200 x 500.Cílem je změnit strukturu tak, aby
- Byla obecná, t.j existoval násobný element s typem kontroly, počtem plánovaných kontrol, doručených zpráv a seznamem platných verzi zpráv
- Bylo odstraněno zbytečné zesložitění ve formy množení informací přes dimenzi formy kontroly.
Nově bude taktéž změněna logika volání služby a ta bude volána vždy poté, co k danému subjektu v MZK dojde nějaká změna (nová verze zprávy, změna plánu, zrušení zprávy apod.) – toto bude zajišťovat noční job.V následujícím textu je uveden stávající request ze služby APA_CC06B a nový request ze služby APA_CC06C.
Struktura stávajícího request.Název pole Typ Výskyt Omezení PopisRequest 1 - 1 Element označující data požadavku,
předávaná konzumentem zdrojovému systému.
RokKontroly int 1 - 1 Počet platných číslic: 4
Rok N, vztahující se k období, na něž žadatel o dotaci žádá (Tabulka ZadatelRok, atribut rok).
SeznamZadatelu 1 - 1 Seznam žadatelů, kteří mají všechny ZoK již uloženy v MZK.
Zadatel 0 - N Opakující se element pro jednoho žadatele, který má všechny ZoK již uloženy v MZK.
IdSzr string 1 - 1 Max. délka: 10
Jednoznačný identifikátor žadatele ze Společného zemědělského registru.
PlanNKP int 1 - 1 Počet platných číslic: 4
počet plánovaných kontrol typu „národní“ a formy „plánovaná“
PlanNKM int 1 - 1 Počet platných číslic: 4
počet plánovaných kontrol typu „národní“ a formy „mimořádná“
Stupeň důvěrnosti: Veřejné Strana 11 z 1
PlanNKN int 1 - 1 Počet platných číslic: 4
počet plánovaných kontrol typu „národní“ a formy „následná“
PlanCCP int 1 - 1 Počet platných číslic: 4
počet plánovaných kontrol typu „CC“ a formy „plánovaná“
PlanCCM int 1 - 1 Počet platných číslic: 4
počet plánovaných kontrol typu „CC“ a formy „mimořádná“
PlanCCN int 1 - 1 Počet platných číslic: 4
počet plánovaných kontrol typu „CC“ a formy „následná“
PlanDKP int 1 - 1 Počet platných číslic: 4
počet plánovaných kontrol typu „delegovaná“ a formy „plánovaná"
PlanDKM int 1 - 1 Počet platných číslic: 4
počet plánovaných kontrol typu „delegovaná“ a formy „mimořádná“
PlanDKN int 1 - 1 Počet platných číslic: 4
počet plánovaných kontrol typu „delegovaná“ a formy „následná“
PlanOPP int 1 - 1 Počet platných číslic: 4
počet plánovaných kontrol typu „osvědčení“ a formy „plánovaná"
PlanOPM int 1 - 1 Počet platných číslic: 4
počet plánovaných kontrol typu „osvědčení“ a formy „mimořádná“
DorucZOKCC int 1 - 1 Počet platných číslic: 4
počet doručených ZOK typu CC
DorucZODK int 1 - 1 Počet platných číslic: 4
počet doručených ZODK z delegovaných kontrol
DorucZOP int 1 - 1 Počet platných číslic: 4
počet doručených ZODK z delegovaných kontrol
UkonceneSR int 1 - 1 Počet platných číslic: 4
počet pravomocně ukončených správních řízení
CelkemZOKVcetneVerzi int 1 - 1 Počet platných číslic: 4
celkový počet ZOK - CC, NK i DK - včetně starších verzí
Struktura request upravené služby APA_CC06CNázev pole Typ Výskyt Omezení PopisRequest 1 - 1 Element označující data požadavku,
předávaná konzumentem zdrojovému systému.
Zadatel 1 - 1 Opakující se element pro jednoho žadatele, který má všechny ZoK již uloženy v MZK.
IdSzr string 1 - 1 Max. délka: 10
Jednoznačný identifikátor žadatele ze Společného zemědělského registru.
RokKontroly int 1 - 1 Počet platných číslic: 4
Rok N, vztahující se k období, na něž žadatel o dotaci žádá (Tabulka ZadatelRok, atribut rok).
Stupeň důvěrnosti: Veřejné Strana 12 z 1
StavKontrol Pole 0 - N ElementTypKontroly String 1 - 1 Typ kontroly – Enum (NK, CC, DK,
OP,SR)
PocetPlanovanychKonrol Int 1 - 1 Počet naplánovaných kontrol
PocetDorucenyZprav Int 1 - 1 Počet doručených zpráv (součet všech doručených zpráv v poslední verzi)
DoruceneZpravy Pole 0 - N ElementZokId string 1 - 1 Max. délka:
20Jednoznačný identifikátor Zprávy
FormaKontroly int 1 - 1 Počet platných číslic: 1Hodnoty: - 1- 2- 3
Rozlišení Typu kontroly: 1 - Řádná (plánovaná) 2 - Mimořádná (neplánovaná) 3 – Následná (pokud je kontrola „následná“, je vyplněn element CisJednPrimarniKontroly)
VerzeZok int 1 - 1 Počet platných číslic: 5
Doplněk k ZokID, který pomáhá s jednoznačnou identifikací znovuotevřené ZOK, která byla z IS DO poslána přes EPO do MZK a SZIFu.Vždy bude uvedená poslední verze
DatumDoruceni datetime 1 - 1 Počet platných číslic: 4
Timestamp doručení zprávy do MZK
3.1.1.6.1 Dopad do ostatních informačních systémů: Bez dopadu na IS DO
3.1.1.7 Změna struktury a šablony ZOK V níže uvedených podkapitolách jsou specifikované měny obsahu ZOK. Z důvodu těchto změn je potřeba provést tyto úpravy na straně MZK
Vytvoření nové verze web. služby MZK_CC_04 – vytvoření verze M Úprava šablony XSLT Doplnění/odstranění položek v GUI v detailu ZOK v MZK Vytvoření nové verze web. služby MZK_CC_05 – vytvoření verze J
Současně bude zajištěna jednoznačná transakčnost operací při komunikaci mezi IS dozorových orgánů a EPO a následně mezi EPO a MZK (viz první podkapitola níže)Informační systémy dozorových orgánů musí přejít postupně na verzi MZK_CC_04.
3.1.1.8 Zajištění transakčnosti komunikace mezi IS DO – EPO – MZKTransakčnost musí být zajištěna na 3 úrovních:
1. Na straně dozorového orgánu při odesílání zprávy na EPO – tento systém musí zajistit, že zpráva se shodným ID a verzí je odeslána na EPO právě 1x a nesmí být odeslána znovu, dokud není předchozí transakce dokončena.
2. Systém EPO bude nově kontrolovat a odmítat ZoK (obecně i ZoDK, ZoP) v situaci, kdy IS DO zašle ZOKID a verzi v intervalu, kdy dosud nebyl předchozí ZoK předán úspěšně do MZK nebo dokud není od MZK business chyba (viz bod 3 níže). Tato nová kontrola zajistí, že nedojde k odeslání stejného ZOKID a verze u kterého ještě nebyl zjištěn výsledek MZK. Odmítnutí ze strany EPO bude např.dokud nebude ověřen elektronický podpis nebo v případě, že předání do MZK zatím neproběhlo. Pokud již bude mít EPO informaci o stavu zpracování na straně MZK tak EPO povolí další stejný ZOKID i verzi. Samotné odmítnutí na duplicitu již bude v režii MZK jako cílového systému. Toto opatření se bude týkat ZoK, ZoDK, které jsou přes EPO (tj. nikoliv ty, které zasílá SZIF přímo do MZK). Do
Stupeň důvěrnosti: Veřejné Strana 13 z 1
doby úspěšného doručení musí EPO zajistit prostřednictvím služby EPO_CC_07 správné informování klienta, tj.:
a. Propagace business chyba od MZK,b. OK výsledek přijetí ZOK,c. Nedokončené zpracování ZoK na EPO – EPO odmítne další stejný ZOKID a verzi,d. Neprovedené doručení ZoK do MZK (nový stav) – EPO odmítne další stejný
ZOKID a verzi.3. Při předávání zprávy z EPO přes BUS/ESB do MZK – v případě, že se EPO pokusí
doručit zprávu službou MZK_CC_04, 10 a 16 a dostane CRITICAL odpověď (BUSINESS chyba od MZK je pro zpracování a uložení na EPO bez problémů) od ESB pokusí se v určitých cyklech (např. každou hodinu) opakovat znovu volání (max. po dobu 24 hodin). Opakované volání bude obsahovat stejnou identifikaci zprávy na EPO (unikátní SID), ZOKID a dále verzi ZoK. Cílem této úpravy je zajistit, aby v případě uložení ZoK do MZK a chybě ve zpětné komunikaci bylo možné zajistit úspěšné zpracování na straně EPO a propagaci stavu vůči IS DO. Na straně MZK bude upraveno zpracování volání služeb MZK_CC_04, 10 a 16 tak, že si bude u každého předání ZOKID a verzi ukládat nově i SID od EPO. Pokud EPO bude provádět opakované volání uvedených služeb tak MZK ověří, zda již kombinace ZOKID, verzi a SID není v DB MZK uložena. Pokud je tak MZK došlý ZOK neukládá, ale vrátí vůči EPO odpověď o výsledku původního zpracování (OK nebo BUSINESS chyba). Pokud, ale kombinaci ZOKID, verzi a SID nenajde tak provede standardní vyhodnocení ZOKID a verze. Výsledkem tedy bude stejný průběh jako dnes. Ve zkratce: MZK musí umět vyhodnotit opakované volání se stejným SID a tyto neukládat a nezpracovávat, ale vůči EPO pouze vrátit původní vyhodnocení příjmu ZOK.
3.1.1.9 Změna struktury a šablony ZOK z důvodu doplnění nového atributu pro typ kontroly
Specifikace úprav:Do detailu ZOK v aplikaci MZK a v XSLT šabloně bude doplněná nová položka „Typ kontroly z plánu kontrol“. Tato položka může nabývat hodnot typu plánované kontroly (CC/NK) uvedené ve struktuře ZOK v položce „OidPlanKontrolaTyp“. V nové verzi položka OidPlanKontrolaTyp bude povinná.
3.1.1.9.1 Dopad do ostatních informačních systémů:Bez dopadu na IS DO
3.1.1.10 Změna struktury a šablony ZOK z důvodu doplnění nového atributu Popis nálezu úmyslného porušení
Specifikace úprav:Do detailu ZOK bude doplněná nová položka „Popis nálezu úmyslného porušení“.
Vytvoření validace: v případě vyplnění úmyslného porušení v rámci porušeného požadavku, musí být vyplněn
text v položce „Popis nálezu úmyslného porušení“. Tvrdá validace.
3.1.1.10.1 Dopad do ostatních informačních systémůNa straně IS DO se zajistí plnění a validace před odesláním ZOK do MZK, kdy v případě vyplnění úmyslného porušení v rámci porušeného požadavku, musí být vyplněn text v položce „Popis nálezu úmyslného porušení“.
3.1.1.11 Změna struktury a šablony ZOK z důvodu odebrání bodového hodnocení
Specifikace úprav:V detailu ZOK v části detailu požadavku a v celkovém hodnocení ZOK budou odebrány tyto položky:
Body v položce pro rozsah, závažnost, trvalost, úmysl
Stupeň důvěrnosti: Veřejné Strana 14 z 1
Položka Stržené body a Stržené body celkemNíže jsou zvýrazněné položky, které se budou odebírat:Detail požadavku:
Celkové hodnocení ZOK
Úprava validací ve web. službě MZK_CC_04M:Ve verzi M web. služby budou upravené tyto validace:
38Nesouhlasí počet stržených bodů celkem. V hlavičce je vyplněno x, skutečný počet je y. Validaci odebrat.
48
Nesouhlasí počet stržených bodů požadavku. V hodnocení požadavku je vyplněno x, skutečný počet je y.Validaci odebrat.
54
V předaném požadavku je vyplněna chybná hodnota pro stržené body dílčího porušení s názvem stupně porušení. Očekáváno je bodů …Validaci odebrat.
60V předaném požadavku v dílčím porušení nesmí být vyplněna položka Stržené body.Validaci odebrat.
64Dílčí porušení musí obsahovat Stržené body.Validaci odebrat.
3.1.1.11.1 Dopad do ostatních informačních systémů:Bez dopadu. Bodové hodnocení bylo zrušeno od 1.1.2017
3.1.1.12 Změna struktury a šablony ZOK z důvodu odebrání položky Důvod neuložení nápravného opatření
Úprava validaci ve web. službě MZK_CC_04M:Ve verzi M web. služby budou upravené tyto validace:208 Položku Důvod neuložení nápravného opatření, nelze vyplnit pokud je vyplněno
Nápravná opatření splněná na místě = ANO anebo Nápravná opatření uložena = ANO anebo Bezpředmětné
Stupeň důvěrnosti: Veřejné Strana 15 z 1
Validaci odebrat.209 Nelze vyplnit pouze Nápravná opatření bez vyplnění položky Důvod neuložení
nápravného opatření.Validaci odebrat.
3.1.1.12.1 Dopad do ostatních informačních systémů:V IS DO se musí zajistit soulad, kdy v detailu ZOK bude odebrána položka Důvod neuložení nápravného opatření.
3.1.1.13 Úprava struktury ZoDK (doplnění odkazu více kontrolních listů v jedné ZoDK v položce URL PoKZ ke stažení a odkaz na registrační číslo žádosti)
Ve struktuře ZoDK budou provedeny následující úpravy: Aktuálně struktura ZoDK a šablona xslt má navrženou strukturu pro zobrazení jednoho url
pro stažení kontrolního listu z kontroly dozorového orgánu. Nově je návrh na rozšíření více url v ZoDK. Pro zajištění zobrazení url obou kontrolních listů (pro druh zvířat tuři + ovce/kozy) z protokolu ČPI v MZK je potřeba upravit strukturu web. služby MZK_CC_10G a MZK_CC_11E (rozšířit velikost na 4000 znaků pro položku URL PoKZ ke stažení).
Doplnění pole REGCISLOZADOSTI, které bude přebírané z plánu kontrol.Následně je nutné upravit šablonu ZoDK na EPO upravit GUI v MZK
3.1.1.13.1 Dopad do ostatních informačních systémůDopad bude řešen jen u IZR, a to v ohledu plnění více url kontrolních listů, ostatní IS DO pouze aktualizují klienta WSDL u MZK_CC_10G a v případě SZIF iimplementace změny totožné změny u služby MZK_CC_11E, kdy v poli URLPOKZ budou řetězeny odkazy na stažení kontrolních listů.
3.1.1.14 Evidence ukončených ZOK a ZoDKSpecifikace úprav:V MZK v obrazovce pro vyhledání ZOK bude doplněná nová filtrační položka „Pouze ukončené ZoK/ZoDK:“. Bude nabývat hodnot ANO/NE (defaultně nastaveno) „-„.V případě výběru hodnoty ANO, se zobrazí pouze zprávy, které jsou ukončené tj. nemají další vyšší verzi doručenou v MZK a mají vyplněnou Platnost Do.
3.1.1.14.1 Dopad do ostatních informačních systémůBez dopadů.
3.1.1.15 Validace na příjmu ZOK pro plnění systému včasného varováníV rámci příjmu ZOK webovou službou MZK_CC_04H bude doplněná validace, že systém včasného varování v ZOK je vyplněn pouze pro kombinaci porušení - rozsah: malý, závažnost: malá, trvalost: odstranitelná, úmysl: ne, protože tento text se plní do společné položky Seznam uložených nápravných opatření v ZOK a nejde oddělit, jestli se jedná o text nápr. Opatření a nebo včasného varování. Toto ošetření se musí provést na úrovní IS DO.
3.1.1.15.1 Dopad do ostatních informačních systémůNa straně IS DO je nutno zajistit plnění včasného varování do protokolu a ZOK dle povolené kombinace porušení
3.1.1.16 Úprava sestavy Kontroly pro statistiky EK
Stupeň důvěrnosti: Veřejné Strana 16 z 1
V rámci detailu sestavy Statistky kontrol pro EK, upravit strukturu zobrazení žadatelů. Podklady pro žadatelé se v této sestavě zobrazují dle původních tabulek Podklady pro RA a nově je potřeba tuto vazbu změnit na podklady žadatelů ze SDB.
3.1.1.16.1 Dopad do ostatních informačních systémůBez dopadů.
Specifikace dopadů změn v MZK do IZR
3.1.1.17 Implementace nové verze web. služby MZK_CC_03 a dopady do aplikace IZR
Na straně IZR bude provedená implementace nové verze služby MZK_CC_03H, kdy je nezbytné změnit jak strukturu requestu (nové pole REGCISLOZADOSTI a vazba na OPATRENI) a současně přizpůsobit se novému chování response, kdy v odpovědi se mohou vracet nepřijaté naplánované subjekty
3.1.1.18 Odebrání informace o PVP kontroláchNa straně IZR bude dále zajištěno, že informace o PVP kontrolách budou přebírány z elementu DoplnkoveInfo.Změna validace:„Stažení plánu kontrol web sl. MZK_CC_13 pro rok XXXX selhalo. Plán kontrol nebyl aktualizován.Popis chyby: U kontrol PVP (kód podobasti 70) musí být vyplněn alespoň jeden z atributů PVP_Skot a PVP_OvceKozy hodnotou 1 (zadatel YYYYY).“
3.1.1.19 Implementace nové verze web. služby MZK_CC_13E a dopady do IZR z důvodu úpravy logiky fungování této služby
V IZR budou provedené níže uvedené změny z důvodu vytvoření nové verze MZK_CC13E
3.1.1.19.1 Vytvoření nového mechanizmu plnění nejzazšího data kontroly a čísla žádosti do IZR
Sestava plánu kontrol dotacíV sestavě plánu kontrol dotací (KontrolyDotaci/SubjektyKeKontrole.aspx) budou doplněné nové sloupce:
Zkontrolovat doo Plněno z dat web. služby MZK_CC_13D z pole DoplnkoveInfo z atributu Hodnota
string pro výčet KodInfo Registrační číslo žádosti
o Plněno z dat web. služby MZK_CC_13D z položky RegCisloZadostDoplnění položek do detailu kontroly
Do detailu kontroly v LK IZR a v OLK budou doplněné položky Zkontrolovat do a Registrační číslo žádosti
Doplnění hodnoty do tiskového výstupu Do tiskového výstupu Výsledky v offline klientu pro všechny druhy kontrol dotací bude
systém plnit hodnotu registračního čísla uvedenou v detailu kontroly. Součásti této změny je úprava 11 tiskových výstupů
3.1.1.19.2 Úprava zobrazení plánu kontroly v IZR z důvodu rozdělení plánu dle autora plánuV IZR budou provedené níže uvedené změnySestava plánu kontrol dotacíV sestavě plánu kontrol dotací (KontrolyDotaci/SubjektyKeKontrole.aspx) bude doplněn nový sloupec „Autor plánu“, který bude plněn z MZK_CC13 nové verze E. Pokud bude k jednomu subjektu a podoblasti více autorů plánu, tak kontroly budou zobrazené ve více řádcích plánu kontrol v IZR.
Stupeň důvěrnosti: Veřejné Strana 17 z 1
3.1.1.20 Dopad do IZR z důvodu změny struktury ZOK3.1.1.20.1 Dopad do IZR z důvodu doplnění nového atributu Popis nálezu úmyslného
porušení v ZOK Na straně IZR se zajistí plnění a validaci před odesláním ZOK do MZK, že v případě
vyplnění úmyslného porušení v rámci porušeného požadavku, musí být vyplněn text v položce „Popis nálezu úmyslného porušení“.
Validace bude doplněná v LK IZR a v offline klientu (měkká validace při uložení konceptu v OLK, tvrdá validace při uzavření konceptu v OLK)
3.1.1.20.2 Dopad do IZR z důvodu změny struktury a šablony ZOK z důvodu odebrání položky Důvod neuložení nápravného opatření
V detailu ZOK bude odebrána položka Důvod neuložení nápravného opatření. Bude odebrána validace v OLK.
3.1.1.21 Úprava plnění systému včasného varování do ZOK v IZR dle porušení požadavku.
V rámci plnění ZOK webovou službou MZK_CC_04H bude doplněná validace, že systém včasného varování v ZOK je vyplněn pouze v případě kombinace porušení:
rozsah: malý závažnost: malá trvalost: odstranitelná úmysl: ne
Úprava v IZR je na dvou úrovních:- plnění informace včasného varování do ZOK v případě výše uvedené kombinace- plnění informace včasného varování tiskopisu Protokolu v případě výše uvedené
kombinace
3.1.1.22 Implementace aktualizace web. služby MZK_CC_10GDopad do IZR:
implementovat aktualizaci web. služby MZK_CC_10G nastavit v IZR plnění dvou záznamů url kontrolních listů do struktury ZoDK začít plnit pole REGCISLOZADOSTI
Specifikace dopadů změn v MZK do LPIS
3.1.1.23 Implementace nové verze web. služby MZK_CC_03HNa straně LPIS bude provedená implementace nové verze služby MZK_CC_03H, kdy je nezbytné změnit jak strukturu requestu (nové pole REGCISLOZADOSTI a vazba na OPATRENI) a současně přizpůsobit se novému chování response, kdy v odpovědi se mohou vracet nepřijaté naplánované subjekty
3.1.1.24 Implementace nové verze web. služby MZK_CC_13E V LPIS budou provedené níže uvedené změny z důvodu vytvoření nové verze MZK_CC13E
3.1.1.24.1 Vytvoření nového mechanizmu plnění nejzazšího data kontroly a čísla žádosti do LPIS
Sestava plánu kontrol dotací
Stupeň důvěrnosti: Veřejné Strana 18 z 1
V plánu kontrol budou doplněné nové sloupce: Zkontrolovat do
o Plněno z dat web. služby MZK_CC_13D z pole DoplnkoveInfo z atributu Hodnota string pro výčet KodInfo
Registrační číslo žádostio Plněno z dat web. služby MZK_CC_13D z položky RegCisloZadosti
Doplnění položek do detailu kontroly Do detailu kontroly budou doplněné položky Zkontrolovat do a Registrační číslo žádosti
Doplnění hodnoty do tiskového výstupu Do protokolu o kontrole pro všechny druhy kontrol dotací bude systém plnit hodnotu
registračního čísla uvedenou v detailu kontroly.
3.1.1.24.2 Úprava zobrazení plánu kontroly z důvodu rozdělení plánu dle autora plánuV LPIS bude upraven přehled plánovaných delegovaných kontrol, do kterého níže uvedené bude doplněn nový sloupec „Autor plánu“, který bude plněn z MZK_CC13 nové verze E. Pokud bude k jednomu subjektu a podoblasti více autorů plánu, tak kontroly budou zobrazené ve více řádcích plánu kontrol v LPIS.
3.1.1.25 Dopad do LPIS z důvodu změny struktury ZOK3.1.1.25.1 Dopad do LPIS z důvodu doplnění nového atributu Popis nálezu úmyslného
porušení v ZOKNa straně LPIS se zajistí plnění a validaci před odesláním ZOK do MZK, že v případě vyplnění úmyslného porušení v rámci porušeného požadavku, musí být vyplněn text v položce „Popis nálezu úmyslného porušení“.
3.1.1.25.2 Dopad do LPIS z důvodu změny struktury a šablony ZOK z důvodu odebrání položky Důvod neuložení nápravného opatření
V detailu ZOK bude odebrána položka Důvod neuložení nápravného opatření. Bude odebrána kontrola na plnění tohoto pole..
3.1.1.26 Úprava plnění systému včasného varování do ZOK dle porušení požadavku.
V rámci plnění ZOK webovou službou MZK_CC_04H bude doplněná validace, že systém včasného varování v ZOK je vyplněn pouze v případě kombinace porušení:
rozsah: malý závažnost: malá trvalost: odstranitelná úmysl: ne
3.1.1.27 Implementace aktualizace web. služby MZK_CC_10GDopad do LPIS:
implementovat aktualizaci web. služby MZK_CC_10G začít plnit pole REGCISLOZADOSTI
Specifikace dopadů změn v aplikaci data ke stažení
3.1.1.28 Úprava klienta Data ke stažení – služba LPI_AZP01CData ke stažení jsou tzv. branou k datům, která poskytují registry MZe prostřednictvím Webových služeb SW třetích stran. Jednou z těchto služeb, kterou Data ke stažení konzumují je LPI_AZP01C. Průměrně se jedná o desítky volání za týden. Úprava bude spočívat v zapracování nového WSDL do klientské části Data ke stažení, aby aplikace Data ke stažení uměla stahovat nové data ze služby. Druhou úpravou je poskytnutí údajů z AZZP i do výstupů aplikace Data ke stažení.Přehled úpravy výstupu Data ke stažení:
Stupeň důvěrnosti: Veřejné Strana 19 z 1
Do tabulkového výstupu v GUI
Do excelového výstupu, který aplikace Data ke stažení nabízí
Do XML výstupu, který aplikace Data ke stažení nabízí
3.1.1.28.1Odůvodnění požadované změny (legislativní změny, přínosy)Požadovaná změna přinese snížení zvyšující se chybovosti aplikací a přechodu na novější a modernější operační systém.Přínosem navrhované změny je také vyšší bezpečnost systému.
Odůvodněním úpravy klientské části služby LPI_AZP01C je úprava na straně LPIS, kde dochází k úpravě uvedené WS a bez úprav na klientské části Data ke stažení přestane být tato funkčnost dostupná, protože Data ke stažení nebudou korektně zpracovávat odpověď a poskytovat data.
Stupeň důvěrnosti: Veřejné Strana 20 z 1
3.2 Dopady na IS MZeTechnické aspekty implementace – dopady na Agribus
Nezbytné zajistit na AGRIBUS: vystavení nové služby MZK_CC_03H a autorizovat k ní totožné konzumenty jako k verzi G vystavení nové verze služby MZK_CC_13D a autorizovat k ní totožné konzumenty jako
k verzi C vystavené nové verze služeb MZK_CC_04M a autorizovat k ní totožné konzumenty jako
k verzi K (verze L vynechána kvůli možné záměně L a I) vystavené nové verze služeb MZK_CC_05J a autorizovat k ní totožné konzumenty jako
k verzi I vystavené nové verze služeb MZK_CC_10G a autorizovat k ní totožné konzumenty jako
k verzi F vystavené nové verze služeb MZK_CC_11E a autorizovat k ní totožné konzumenty jako
k verzi D vystavení nové verze služby APA_CC06C autorizovat k ní totožné konzumenty jako k verzi B vystavení nové verze WSDL služby APA_CC14B bez změny verze služby
Není vyžadováno sladění nasazení služby na Agribus s nasazením na straně zdroje MZK. U služby APA_CC14B je nezbytné zajistit koordinaci nasazení na Agribus s MZK !Zajištění součinnosti
Je nezbytné zajistit na straně IS SVS součinnost pro napojení na novou verzi MZK_CC13DÚprava plnění dat do nové změněné struktury ZOK ze strany IS DO.Implementace nových web. služeb ze strany IS DO.
3.3 Dopady na agendux – ano ☒ / ne ☐ 3.4 Dopady na aplikace – ano ☒ / ne ☐ 3.5 Dopady na data – ano ☒ / ne ☐ 3.6 Dopady na síťovou infrastrukturu – ano ☐ / ne ☒ 3.7 Dopady na serverovou infrastrukturuxi – ano ☐ / ne ☒ 3.8 Dopady na bezpečnost – ano ☐ / ne ☒
(Pozn.: V případě, že má změna dopady na síťovou infrastrukturu, doplňte tabulku (otevřete dvojklikem): Pokud má požadavek dopady do dalších požadavků MZe, uveďte je též v bodu 3.3.)
3.9 Seznam měněných komponent nebo funkcionalit (vycházející z ArchiMate modelu architektury)xii
3.10 Obecný návrh nové architektury v Sparx EA projektuxiii (Pozn.: Uveďte v případě implementace nových systémů, modulů, nebo funkcionalit a komunikace.)
3.11 Dotčené konfigurační položkyxiv
ID Název položky Předpokládaný dopad 1 LPIS Úprava2 EPO Úprava3 MZK Úprava4 Data ke stažení Úpava
3.12 Rizika implementace změnyKdyž se PZ nezrealizuje bude
a. Nutné nadále řešit manuálně rozdílné stavy v plánech kontrol DO u podoblastí, kde může plánovat kontroly více subjektů
b. Zůstane nevyvážený způsob výpočtu RA u lesnických opatření mezi běžnou RA a doplňkovou RA
c. Nebude v sestavě porušení dostupný údaj o počtu opakovaných porušení.
Stupeň důvěrnosti: Veřejné Strana 21 z 1
d. Nebude upravena služba APA_CC06 a SZIF bude muset vyhodnocení řešit polomanuálně.
3.13 Požadavek na podporu provozu naimplementované změnyPodpora je standardní součástí PRAIS.(Pozn.: Uveďte, zda zařadit změnu do stávající provozní smlouvy, konkrétní požadavky na požadované služby, SLA.)
4 Požadavek na dokumentacixv
ID Název položky Zpracovat(ANO/NE)
Formát výstupu (elektronické úložiště / CD / listinná forma)
1. Analýza navrhnutého řešení NE – součást zadání NE/NE/NE
2. Dokumentace dle specifikace Závazná metodika návrhu a dokumentace architektury MZexvi ANO ANO/ANO/NE
3. Testovací scénář, protokol o otestování ANO ANO/ANO/ANO4. Uživatelská příručka ANO ANO/ANO/NE5. Systémová příručka NE NE/NE/NE6. Aktualizace provozní dokumentace ANO ANO/ANO/NE
5 Akceptační kritériaPlnění v rámci požadavku na změnu bude akceptováno, jestliže budou akceptovány dokumenty uvedené v tabulce výše v bodu 4 a budou předloženy protokoly o uživatelském testování podepsané garantem, který je uveden ve sloupci Akceptuje.
ID Akceptační kritérium Způsob verifikace Akceptuje1.2.
Stupeň důvěrnosti: Veřejné Strana 22 z 1
B – NABÍDKA ŘEŠENÍID SD MZexvii: Z22476 ID ShP MZexviii: 2016_0031_187 ID PK MZexix: 347ID PRO KOMUNIKACI S DOD.: PZ_PRAIS_2017_NO196_MZK_SOUBOR_DROB_UPRAV
1 Návrh konceptu technického řešení Viz část A, body 2 a 3 tohoto RfC
2 Uživatelské a licenční zajištění pro ObjednateleDle podmínek smlouvy 353-2015-13310 /1, 2
3 Dopady do systémů MZeV rámci každého bodu týkajícího se aplikace MZK je samostatná kapitola „Dopad do ostatních informačních systémů dozorových orgánů“, která specifikuje dopady do systémů MZe.
4 Požadavky na součinnost Objednatele a třetích stranMZe / Třetí strana Popis požadavku na součinnost
IS SVS/SZIFSoučinnost dle popisu dopadu do ostatních systémů MZe uvedených v jednotlivých kapitolách
SZIF + BUSImplementace nových webových služeb na BUS (+ autorizace konzumentů). Implementace zdrojových služeb na SZIF.
MZe/ČPI/SZIF Součinnost při testování a akceptaciOstatní systémy konzumující MZk služby – ÚKZÚZ, SZPI, SZIF, SVS
Bude zachováno pravidlo, že MZK udržuje 2 verze webových služeb zpětně. S nasazením nových služeb budou starší verze odregistrovány na BUS a EPO.
(Pozn.: K popisu požadavku uveďte etapu, kdy bude součinnost vyžadována.)
5 Harmonogram plněníxx
Popis etapy TermínImplementace řešení v rámci aplikace MZK– testovací prostředí 28.2.2018Implementace řešení v rámci aplikace IZR– testovací prostředí 31.3.2018Implementace řešení v rámci aplikace LPIS– testovací prostředí 31.3.2018Opravy z testování - část MZK 15.3.2018Opravy z testování - část IZR 15.4.2018Opravy z testování - část LPIS 15.4.2018Nasazení do provozního prostředí - část MZK 30.4.2018Nasazení do provozního prostředí - část IZR 30.4.2018Nasazení do provozního prostředí - část LPIS 30.4.2018Dokumentace řešení 31.5.2018 */
*/ Výše uvedený harmonogram je platný pouze v případě, že dodavatel obdrží objednávku do 15.1.2018.
6 Pracnost a cenová nabídka navrhovaného řešení
včetně vymezení počtu člověkodnů nebo jejich částí, které na provedení poptávaného plnění budou spotřebovány
Oblast / rolexxi
Popis Pracnost v MD/MJ
v Kč bez DPH: v Kč s DPH:
Viz cenová nabídka v příloze č. 01 129,25 1 088 414,25 1 316 981,24
Celkem: 129,25 1 088 414,25 1 316 981,24
(Pozn.: MD – člověkoden, MJ – měrná jednotka, např. počet kusů)
ID SD MZexxiii: Z22476 ID ShP MZexxiv: 2016_0031_187 ID PK MZexxv: 347
1 Specifikace plněníPožadované plnění je specifikováno v části A a B tohoto RfC.
Uživatelské a licenční zajištění pro Objednatele (je-li relevantní):
2 Harmonogram realizacexxvi
Popis etapy TermínImplementace řešení v rámci aplikace MZK– testovací prostředí 28.2.2018Implementace řešení v rámci aplikace IZR– testovací prostředí 31.3.2018Implementace řešení v rámci aplikace LPIS– testovací prostředí 31.3.2018Opravy z testování - část MZK 15.3.2018Opravy z testování - část IZR 15.4.2018Opravy z testování - část LPIS 15.4.2018Nasazení do provozního prostředí - část MZK 30.4.2018Nasazení do provozního prostředí - část IZR 30.4.2018Nasazení do provozního prostředí - část LPIS 30.4.2018Dokumentace řešení 31.5.2018 */
3 Pracnost a cenová nabídka navrhovaného řešení
včetně vymezení počtu člověkodnů nebo jejich částí, které na provedení poptávaného plnění budou spotřebovány
Oblast / rolexxvii
Popis Pracnost v MD/MJ
v Kč bez DPH: v Kč s DPH:
Viz cenová nabídka v příloze č. 01 129,25 1 088 414,25 1 316 981,24
Celkem: 129,25 1 088 414,25 1 316 981,24(Pozn.: MD – člověkoden, MJ – měrná jednotka, např. počet kusů)
Oprávněná osoba dle smlouvy: Schvaluji ☐ / Neschvaluji ☐…
Jméno a příjmení Datum Podpis
Stupeň důvěrnosti: Veřejné Strana 2 z 2
Vysvětlivky
Strana 1 / 1
i Formulář RfC je tvořen třemi částmi, A - Věcné zadání, B – Nabídka řešení, C - Potvrzení realizace požadavku. První část (Věcné zadání) je předložena poskytovateli/dodavateli jako pobídka k předložení nabídky řešení. Druhou část, tj. část B použije dodavatel řešení k vypracování nabídky, kterou předloží MZe. Třetí část (Potvrzení realizace požadavku) se po vyplnění přiloží k první a druhé části a předloží se ke schválení osobám uvedeným v části C RfC. Poskytovateli/dodavateli se poté vyplněný formulář RfC předkládá v příloze objednávky na realizaci změnového požadavku. Pouze tato podepsaná objednávka je pokynem pro dodavatele/poskytovatele k realizaci změny.
ii ID SD MZe – identifikátor požadavku přidělený v ServiceDesku MZeiii ID ShP MZe – identifikátor projektu k požadavku přidělený v projektovém portálu MZe ivID PK MZe – identifikátor požadavku přidělený v pomocné evidenci projektové kanceláře MZev Předmět změny – stručná informace, název požadavkuvi Kategorie změny – kategorie urgentní se využije v naléhavých případech, kdy je třeba vyřešit nedostupnost zásadní funkcionality systému vzhledem ke zpracování agendy, pro jejíž podporu systém slouží.vii Priorita – vyjadřuje důležitost zapracování požadavku z pohledu časového. Vyplní se v případě volby kategorie „Normální změna“.viii Kód – zkratka aplikace (viz „kód služby“ v katalogu služebix Smlouva č. – uvede se, pokud existuje smlouva, v rámci níž se požadavky předkládají, totéž platí pro KL (katalogový
list).x Agenda – jedná se o postupy a činnosti, které provádí uživatel.xi Systémy – myšleno servery, operační systémy, standardní software a jimi tvořené clustery, geografické clustery atd.xii Nepovinná položka při zpracování RfCxiii Nepovinná položka při zpracování RfC xiv Vyplňte ve spolupráci s provozním garantem.xv Vyplní Change koordinátor s Provozním garantem.xvi Rozsah požadované dokumentace uveďte pod tabulkou.xvii ID SD MZe – identifikátor požadavku přidělený v ServiceDesku MZe, zkopíruje se z věcného zadání.xviii ID ShP MZe – identifikátor projektu k požadavku přidělený v projektovém portálu MZe, zkopíruje se z věcného zadání. xixID PK MZe – identifikátor požadavku přidělený v pomocné evidenci projektové kanceláře MZe, zkopíruje se z věcného zadání. xx Uvede se datum zahájení a ukončení realizace, příp. další etapy.xxi Role se vyplní pouze v relevantních případech, např. u požadavku na infrastrukturu.xxii Oprávněná osoba – smluvně určená osoba oprávněná k předkládání požadavku na předložení nabídky.xxiii ID SD MZe – identifikátor požadavku přidělený v ServiceDesku MZe, zkopíruje se z věcného zadání.xxiv ID ShP MZe – identifikátor projektu k požadavku přidělený v projektovém portálu MZe, zkopíruje se z věcného zadání. xxvID PK MZe – identifikátor požadavku přidělený v pomocné evidenci projektové kanceláře MZe, zkopíruje se z věcného zadání. xxvi Uvede se datum zahájení a ukončení realizace, příp. další etapy.xxvii Role se vyplní pouze v relevantních případech, např. u požadavku na infrastrukturu.xxviii Změna smluvních podmínek - vyplní se v případě, že dohodnuté podmínky realizace požadavku se liší od smluvních.xxix Jméno a příjmení vyplní Change koordinátor, zbývající údaje podepisující. Ve volbě schvaluji/neschvaluji se zaškrtne hodící se volba.
