Specifikace p edm tu pln ní a technické požadavky

Transkript

1 íloha. 1 k Rámcové smlouv Specifikace pedmtu plnní a technické požadavky

2 Obsah 1 Úvod Pedmt veejné zakázky Dokumentace APV POJ Popis modul APV POJ Standardy IKT SSZ Výkonnostní požadavky Rozvoj aplikace APV POJ Projektové ízení Analytická ást Vývojová ást Testovací ást Školení Nasazování do produkce Požadované souinnosti ešení vybraných požadavk Pehled pokladních knih Úprava stavového modelu zpracování bankovního souboru Sestava plátc s nepimeným dluhem Možnost filtrace vyhledávání operací kont podle správce konta Úprava rekapitulace výkazu nedoplatk v pípad promíjení penále Ošetení dávek s výhradn nulovými operacemi pi integraci s EKIS (SAP) Úprava výstup do MIS ZPPOHLED Pokladní kniha s nulovým obratem Aprobace splátkového kalendáe Úprava implicitního zobrazení vyhodnocení konta zamstnavatele Možnost zobrazení konta plátce pi útování Pehledu zamstnavatele Zobrazení seznamu operací a specifických symbol Integrace s KOC Úprava zadávání intervalu druhé sazby pojistného zamstnavatele

3 Umožnní útování na všech pracovištích PSSZ Zmna výpotu sborník a rekapitulací Porovnání dat POJ a VZT Evidence splátek v SPR Plátce bez povinnosti pedkládat pehledy Nezneplatování titulu požadavkem z VZT Možnost opravit uloženou poznámku Storno pazení okresu referentovi Insolvence v sestav zaútovaných pedpis a plateb Informace o vráceném peplatku NP OSV Zajištní aplikaní podpory APV POJ Pevzetí do servisu Rozsah pevzetí do servisu Poskytování aplikaní podpory APV POJ Návrh SLA Algoritmus vyhodnocení aplikaní podpory Rozsah služeb aplikaní podpory

4 1 Úvod Závazné podmínky: 1.1 Smyslem a úelem Pílohy. 1 Rámcové smlouvy o vývoji a údržb aplikaního programového vybavení pro oblast výbru pojistného od zamstnavatel a nemocenského pojištní OSV II (dále jen Rámcová smlouva ), uzavené v souladu s ustanovením 89 a následujícími zákona. 137/2006 Sb., o veejných zakázkách, ve znní pozdjších pedpis (dále jen ZVZ ), ustanovením 1746 odst. 2 zákona. 89/2012 Sb., obanský zákoník, ve znní pozdjších edpis (dále jen obanský zákoník ), a v souladu s ustanovením 2358 a následujícími obanského zákoníku, je zejména: a) podrobn a pehledn vymezit pedmt plnní Rámcové smlouvy, oddlen od ostatních ustanovení Rámcové smlouvy, b) stanovit technické specifikace pedmtu plnní, c) vymezit pedmt plnní prostednictvím návrh Zhotovitele. 1.2 Obchodní a technické podmínky a podmínky plnní dle Rámcové smlouvy stanovené Objednatelem není Zhotovitel oprávnn upravovat. 1.3 Zhotovitel je oprávnn a zárove povinen specifikovat v rámci této Pílohy. 1 Rámcové smlouvy edmt plnní v rozsahu, který je mu dán Objednatelem (viz grafické znázornní a upozornní na povinnost doplnní píslušných informací, návrh apod.). 3

5 2 edmveejnézakázky Závazné podmínky: Aplikaní vybavení pro správu výbru pojistného (APV POJ) bylo nasazeno do produkního prostedí k Aplikace podporuje agendu výbru pojistného pro oblasti pojistného zamstnavatel (dchodové pojištní, nemocenské pojištní, píspvek na státní politiku zamstnanosti) a dobrovolného nemocenského pojištní osob samostatn výdle inných a zahraniních zamstnanc. Aplikace je modulárnlenna na ásti Platby (zpracování píchozích bankovních výpis ve formátu NB, zpracování soubor s poukázkami od eské pošty, pokladna OSSZ, vytváení platebních píkaz pro pevody plateb), NP OSV/ZAZA (konto plátce pro dobrovolné nemocenské pojištní, umístní plateb, vyhodnocování výše vymovacího základu, vyhodnocení zániku nároku na nemocenské pojištní), Zamstnavatel (konto plátce zamstnavatele, evidence a výpoet rzných typ pedpis pojistného, penále a pokut, umisování plateb na pedpisy) a Jádro (podprné funknosti, pedútování plateb a pedpis, tiskové sestavy, aplikaní framework). Aplikaci využívá cca 3000 uživatel na všech okresních správách sociálního zabezpeení. Aplikace byla vytvoena dodavatelsky (zakázkový vývoj). Aplikace je vytvoena primárn v prostedí MS.NET (.NET framework 2.0) s využitím jazyka C#. Tenký klient aplikace pracuje v prostedí Internet Explorer. Pro persistentní uložení dat je využíván databázový stroj Oracle 10g. Aplikace POJ je integrována na další APV v rámci informaního systému SSZ prostednictvím webových služeb, bu napímo nebo s využitím integraní platformy MS Biztalk. Integrace se týká pedevším systém Kmenové evidence, Pojistné vztahy, Nemocenská a SAP. Vzhledem k tomu, že Zadavatel již dlouhodob využívá APV POJ a v nm zabudované moduly, je nutné metody, postupy a nástroje pi zavádní dalších zmn pizpsobit stávajícímu software pi dodržení stanovených standardssz. Zadavatel požaduje ešení, které bude brát ohled na co nejnižší náklady jak i implementaci zmn, tak i pro vlastní provoz a údržbu aplikace za jednozna definované kvality, bude minimalizovat náklady na vývoj systému, jeho údržbu, minimalizovat náklady na integraci s již zavedenými systémy a predikovat možnosti budoucí funkcionality s ohledem na nástup nových technologií a zaízení s podporou Windows server 2012 a IE8. Objednatel požaduje zajištní komplexních služeb, které zajistí Zadavateli stabilní rozvoj APV POJ, dále podporu stávající aplikace POJ i nov dodaných produkt a poskytnutí souinnosti pi nasazování nových verzí aplikace do systém Zadavatele. Plnní bude sjednáno na dobu 4 let. Dodávka a služby musí tvoí: Poskytování aplikaní podpory o evzetí do servisu o Poskytování podpory APV POJ 4

6 Rozvoj APV POJ o Zapracování úprav do stávajícího APV POJ (legislativní zmny, úpravy v aplikaci POJ na základ požadavk metodik a návrh uživatel), vývoj a sestavení nových komunikaních rozhraní se stávajícími i nov vytvoenými aplikacemi a vypracování íslušné dokumentace 2.1 DokumentaceAPVPOJ Existující dokumentace k píslušným aplikacím, je pedána v elektronické podob na CD/DVD jako píloha k Zadávací dokumentaci. 2.2 PopismodulAPVPOJ Níže uvedená tabulka popisuje pehled aplikací a modul, které jsou pedmtem pedpokládaného plnní. Aplikace ZAME NP Moduly Správa kont ZAME Vyhodnocení konto ZAME Platby a pedpisy ZAME ehledy E-podání Platební výmry Výkazy nedoplatk Splátkové kalendáe eplatky zamstnanc Transformace Pohledy na konto ZAME Sborníky Tiskové sestavy Správa kont NP Vyhodnocení kont NP Platby a pedpisy NP Umísování plateb eplatky NP Zproštní úhrady Pohledy na konto NP Tiskové sestavy Sborníky 5

7 SDK DOP (pozn. Tento modul bude vytvoen v rámci Rozvoje APV POJ) Banka Pošta Pokladna Zútovací konta Závrky Platební brána Sborníky Tiskové sestavy evody plateb, ástek Aprobace ZD Správa kont DOP Vyhodnocení kont DOP Platby a pedpisy DOP Umísování plateb Pohledy na konto DOP Tiskové sestavy Sborníky 2.3 StandardyIKTSSZ Závazné podmínky: Vývoj, rozvoj a údržba aplikaního programového vybavení realizovaného v rámci pedmtného plnní musejí být provedeny v souladu se standardy IKT SSZ platnými v dob realizace. Seznam aktuáln platných standard je uveden v následující tabulce:. Název souboru Název dokumentu Verze 1. std_db_060803_v0.91.doc Standard databází std_inet_1-10.doc Standard pipojení k Internetu std_pošta_1-00d.doc Standard poštovního systému SSZ std_ad_dns_dhcp_ntp_1-34.pdf Standard AD DNS DHCP std_avo1-10.doc Standard Antivirové ochrany Standard systémové konfigurace pracovní Standard systémové konfigurace pracovní 2.20 stanice 2.20 stanice 7. Std_mgmt_v.0.54.doc Standard Management std_metodikavyvoje_apv_1_0_19.doc Standard metodiky vývoje 1_0_ std_pravidlareleasemanagementu_apv_1_ edávání APV a repase 1_2_6 2_6.pdf etn formulá 10. std_net_1-92d.doc Standard síové infrastruktury 1.92d 11. Programatorskekonvence_1_0_17.doc Programátorské konvence.net 2.0, 3.0. a 3.5 1_0_ BizTalkDevelopmentStandard.v1.00.doc Standardy pro tvorbu aplikací pro Microsoft BizTalk server

8 13. AAA_Pozadavky_na_aplikace_v8.doc Požadavky na nové aplikace pi integraci do AAA portálu 14. Standard_pro_tvorbu_skriptu_db_Oracle_0 Standard pro tvorbu, pedávání a spouštní.2.doc skript v databázích Oracle CSSZ_DMS_WS_API_DMA_v3_3_ doc API ROZHRANÍ SYSTÉMU DMA: WS_API_DMA - Standard rozhraní pro ukládání dokument do DMS 16. CSSZ_DU_STD_V011.1.doc Standard provozu databáze Oracle std_srv_0.23.doc Standard systémové konfigurace 0.23 aplikaních server 18. std_pki.pdf Standard pro PKI Výkonnostnípožadavky Závazné podmínky: Níže jsou popsány standardní výkonnostní požadavky na fungování aplikace. Tato pravidla jsou obecnými standardy, pro konkrétní píklady je možné definovat delší doby odezvy, tyto výjimky ovšem musí být vždy definovány ve funkní specifikaci a podléhají schválení Objednatele. Obecné požadované výkonnostní požadavky jsou: Výkonnostní požadavek Uživatelská odezva z front-endu aplikace (odezva pro jednu konkrétní aktivitu vyhledání, založení, ) Odezva online rozhraní (doba zpracování ) Požadovaná doba odezvy Požadované procento splnní 1 sekunda 95% 5 sekund 99% 0,5 sekund 95% 3 sekund 99% V pípad rozvoje aplikace musí všechna nov vznikaná rozhraní i uživatelská volání splovat tyto požadavky. Potencionální nová rozhraní musí zaznamenávat dobu bhu konkrétních volání (staí zápisem do logu). U uživatelských volání musí být Zhotovitel schopen na požádání zmit a prokázat plnní výkonnostních parametr. 7

9 3 RozvojaplikaceAPVPOJ Úvod: V rámci rozvoje aplikace Objednatel pedpokládá poskytování služeb na implementaci rozvojových požadavk a požadavk na zmny v APV POJ. Závazné podmínky: V rámci této innosti musí Zhotovitel pro každou rozvojovou aktivitu, zajistit následující oblasti: Popis ešení a ocenní požadavk definovaných Objednatelem: o Zhotovitel se zavazuje dodat návrh ešení a ocenní konkrétních požadavk do 10 pracovních dní od data pedání požadavku Objednatelem. o Zhotovitel se dále zavazuje, že je schopen dodat kapacity potebné pro implementaci rozvojového požadavku okamžit po schválení návrhu ešení. Zajištní projektového vedení. Vytvoení funkní dokumentace, pípadn aktualizace stávající funkní dokumentace, pokud existuje. Zajištní implementace schváleného požadavku. Aktualizace technické dokumentace. íprava testovacích scéná a testovacích dat. Provedení test systémové, integraní, akceptaní, výkonnostní a penetraní: o Pro konkrétní požadavek nemusí být po dohod provádny všechny typy test. o V pípad, že velikost požadavku pesáhne 50 D, budou navíc provedeny regresní testy aplikace, pokud nebude dohodnuto jinak. o Objednatel mže rozporovat pechod mezi jednotlivými koly test, v pípad že kvalita dodávky nebude splovat dohodnutá kritéria. Aktualizace automatizovaných test (pokud existují). íprava reportu o provedení test. Aktualizace provozní dokumentace. íprava produkního balíku a postupu nasazení. Podpora nasazení do produkce. Zvýšená podpora bezprostedn po nasazení do produkce. 8

10 3.1 Projektovéízení Závazné podmínky: Zhotovitel zajistí ešení všech disciplín projektového ízení celého projektu, vetnízení potencionálních subdodávek dalších aplikací SSZ, které budou dodávat zmny vynucené projektem. Zhotovitel pedloží závazný popis projektového ízení dle výše uvedeného. Popis projektového ízení musí minimáln obsahovat: Metodiku projektového ízení; Metodiku ízení rizik; Metodiku ízení zmn; Metodiku release managementu; Organizaní strukturu projektu. 9

11 3.2 Analytickáást Závazné podmínky: V rámci analytické ásti projektu Zhotovitel zajistí: Katalog požadavk a jeho aktualizaci; Konsolidace a ukotvení zadání; Ocenní pracnosti jednotlivých požadavk; Provedení analýzy požadavk; Návrh architektury jednotlivých úprav APV; Vytvoení detailního návrhu ešení úprav APV vetn návrhu dopad do aplikaní i databázové vrstvy (v závislosti na rozsahu požadavk a dopad realizovaných úprav aktualizace píslušných dokument popisujících procesní a funkní specifikaci, datovou architekturu, architekturu HW a SW, rozhraní a integraci s okolními APV a systémy) a zapracování zmn do stávající dokumentace; Analýza a návrh integrace dotených APV a systém do IS SSZ; ípravu a popis testovacích scéná pro jednotlivé typy test. Zhotovitel pedloží závazný popis plnní dle výše uvedeného. Zhotovitel minimáln popíše: Metodiku tvorby dokumentace; íklady všech pedpokládaných výstup. 10

12 3.3 Vývojováást V rámci vývojové ásti projektu Zhotovitel zajistí: Okomentovaný programový kód požadovaných zmn, se zapracováním požadovaných úprav ve zdrojových kódech píslušných APV (aplikaní i databázová vrstva); ízení a koordinace participace dotených a souvisejících tým a aplikací Proces vývoje a pípravy nasazení, vytvoení instalaních balí pro cílovou platformu Instalaní skripty; Návrh úpravy konfigurace veškerého ástí dodávky; Zapracování zmn v technické/programátorské dokumentaci (pípadn vytvoení); Zapracování zmn v uživatelské dokumentaci (pokud existuje); Poskytovat pípadné konzultace návrhu ešení na úrovni, architektury proces odborných agend, analýzy, designu, implementace, integrace a testování; Zajištní a zpráva vývojového prostedí; V pípad poteby provedení revize zdrojových aplikaních (programových) a databázových kód. Zhotovitel pedloží závazný popis plnní dle výše uvedeného. Zhotovitel minimáln popíše: Metodiku vývoje; Metodika pípravy nasazovacích balí pípadn používané nástroje; íklady pedpokládaných výstup. 11

13 3.4 Testovacíást V rámci testovací fáze Zhotovitel minimáln zajistí: Podporu pi píprav testovacích prostedí; Funkní testy; Integraní testy; Akceptaní testy (provádí Zhotovitel, Objednatel akceptuje na základ akceptaního ízení); Technické testy (penetraní, výkonnostní); ípravu zpráv z testování. Objednatel plnní dle tohoto lánku (3.4 Testovací ást) akceptuje na základ akceptaního ízení. Zhotovitel pedloží závazný popis plnní dle výše uvedeného. Zhotovitel minimáln popíše: íklady pedpokládaných výstup; Úvodní návrh testovací strategie; Obecnou metodiku jednotlivých typ test. 12

14 3.5 Školení Závazné podmínky: V pípad poteby Objednatele musí Zhotovitel zabezpeit vyškolení všech urených pracovník pracujících s aplikací. Objednatel plnní dle tohoto lánku (3.5 Školení) akceptuje na základ akceptaního ízení. Zhotovitel jako souást své nabídky pedloží závazný podrobný popis plnní dle shora uvedeného: Zhotovitel minimáln popíše: Návrh zpsobu školení; íklady školících materiál. 13

15 3.6 Nasazovánídoprodukce Závazné podmínky: Zhotovitel musí zajistit následující aktivity: Naplánování nasazení do produkce; ípravu instalaního postupu; Úpravu provozní dokumentace; Definovat finální konfiguraci pro produkní prostedí; Podporu finálního produkního nasazení. Objednatel plnní dle tohoto lánku (3.6 Nasazování do produkce) akceptuje na základ akceptaního ízení. Zhotovitel pedloží podrobný závazný popis plnní dle výše uvedeného. Zhotovitel minimáln popíše: Návrh zpsobu nasazování do produkce; íklady relevantní dokumentace; Popis provozní dokumentace. 14

16 3.7 Požadovanésouinnosti V rámci této kapitoly Zhotovitel závazn definuje požadované souinnosti ze strany SSZ pro vývoj a nasazení nového aplikaního vybavení. Zhotovitel definuje potebnou souinnost v následující struktue: Popis souinnosti; Popis role na stranssz; Rozsah oekávané souinnosti (v D). Další popis souinností ípadné další požadavky na souinnost. 15

17 3.8 ešenívybranýchpožadavk Úvod: Objednatel požaduje vypracovat detailní návrh ešení všech níže uvedených vybraných požadavk. Zhotovitel popíše ešení pro každý jednotlivý vybraný požadavek, uvede maximální poet lovkodn dle jednotlivých rolí potebných na realizaci daného požadavku. Souhrnnou cenu za tyto vybrané požadavky pak uvede v Píloze. 2 této Smlouvy. Objednatel se dle aktuálních poteb mže rozhodnout pro realizaci jen nkterých nebo žádných vybraných požadavk. Zhotovitel se pak zavazuje realizovat takový požadavek za podmínek uvedených v této Smlouv. Zhotovitel se zavazuje popsat návrh ešení vybraných požadavk uvedených v odstavcích až 0 této ílohy. 1. Objednatel se nezavazuje k realizaci tchto požadavk. Cena za realizaci tchto požadavk bude splovat cenová ujednání uvedená v Píloze. 2 platná pro rozvoj APV POJ ehledpokladníchknih Zadání: Vytvoení funknosti zobrazující pro daný bankovní úet pehled jednotlivých pokladních dn s možností echodu na výpis transakcí vybraného pokladního dne (pokladní knihu). Funknost zajistí vytvoení tiskové sestavy, obsahující souhrnné údaje (otevený/uzavený pokladní den, poty transakcí podle jednotlivých ú, bilance zstatk a sald za daný msíc (úetní období)). Samostatné generování sestavy pro jednotlivé podporované bankovní úty a jednotlivá pracovišt v souladu se standardy pro tvorbu sestav v aplikaci a s možností exportu do Excelu. Filtraní kritéria sestavy zohlední pracovišt a úetní období. Sestava bude rozlišovat uzavená a otevená úetní období. Sestavu není možné zobrazovat pro budoucí úetní období. Zaazení sestavy do nabídky sborník a dalších úetních sestav. Vytvoení nové fyzické role pro zajištní pístupových práv. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 16

18 3.8.2 Úpravastavovéhomodeluzpracováníbankovníhosouboru Zadání: Úprava stavového modelu zpracování bankovního souboru s výpisy z ú. Rozlišení situace, kdy po provedení identifikací plateb, které nebyly automaticky pazeny, je možné soubor pedat k dalšímu zpracování (zaútování). Informování uživatele aplikace o novém stavu zpracování souboru. Zajištní echodu do stavu manuální identifikace plateb v pípad, kdy uživatel provede optovné volání této funknosti. Obdobná úprava se týká zpracování výpis pijatých poštovních poukázek zasílaných eskou poštou. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 17

19 3.8.3 Sestavaplátcnepimenýmdluhem Zadání: Vytvoení funknosti, která umožní zjištní plátc podle zadaných kritérií za vybrané uzavené úetní období (za vybrané pracovišt nebo celou republiku). Funknost bude pracovat nad ukonenou inventarizací kont zamstnavatel. Kritéria umožní minimáln výbr pracovišt, uzaveného úetního období a výši pohledávky od do. Sestava umožní také zobrazení celkového dluhu plátce v pípad, kdy má více mzdových útáren (agregace inventarizací). Sestava bude obsahovat údaje o plátci variabilní symbol, název plátce, místní píslušnost. Sestava bude obsahovat zadaná filtraní kritéria. Zaazení sestavy do nabídky centrálních sestav. Vytvoení nové fyzické role pro zajištní pístupových práv. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 18

20 3.8.4 Možnostfiltracevyhledáváníoperacíkontpodlesprávcekonta Zadání: Rozšíení funknosti Vyhledávání operací kont o volbu správce konta, která zajistí, že budou zobrazeny pouze výsledky pro konta pazená zvolenému uživateli. Ošetení uživatel, kteí pracují na úrovni kraj nebo centrály. Ošetení vyhledávání nad zútovacími konty, kde nejsou správci konta definováni. Úprava souvisejících výstupních sestav peformulování textací filtraních kriterií. Rozšíení datového modelu aplikace o nové položky na entitách reprezentujících operace nad konty plátc tak, aby související dotazy nezpsobovaly výkonnostní problémy. Zajištní automatického pepoítání hodnot v pípad zmny správce konta. Obdobným zpsobem ešit problematiku vyhledávání pomocí aktuáln píslušného pracovišt konta plátce. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 19

21 3.8.5 Úpravarekapitulacevýkazunedoplatkípadpromíjenípenále Zadání: Úprava komplexní tiskové sestavy prhu výpotu vyhodnocení a výkazu nedoplatk tak, aby v pípad operace promíjení penále zobrazovaly kladné hodnoty. Doplnit do vysvtlivek tiskové sestavy prhu výpotu vyhodnocení operaci prominutí penále. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 20

22 3.8.6 OšetenídávekvýhradnnulovýmioperacemiintegraciEKIS(SAP) Zadání: Ošetit situaci, kdy pi automatickém odesílání úetních dávek do EKIS (SAP) mže dojít k tomu, že jsou odesílány dávky obsahující pouze nulové doklady. Zmna se netýká pípad, kdy doklad obsahuje nulové i nenulové ástky. Zmna se netýká pípad, kdy je celková ástka dávky nulová, ale obsahuje doklady s nenulovými ástkami (typicky doklad a jeho storno, kdy se ástky vyruší ). Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 21

23 3.8.7 ÚpravavýstupdoMISZPPOHLED Zadání: Rozšíení sestavy splátkových kalendá o nové údaje tak, aby byly zohlednny všechny operace, které mohou ovlivovat stav pohledávek na splátkových kalendáích na okrese. Tzn., že výstup bude rozšíen o položky transformace, pevod mezi OSSZ, prominutí penále, odpisu dluhu. Je požadováno zavést úetní evidenci ukonení splátkových kalendá pro všechny typy ukonení, tj. uhrazení porušení splátek neplacení bžného pojistného jiný dvod 20a odst. 6 písm. b) zákona. 589/1992 Sb., v platném znní Je požadována implementace kontroly, která vyhodnotí stav splátkových kalendá konta pi pevodu konta mezi okresy. Na základ výsledku tohoto vyhodnocení aplikace zamezí pevodu mezi okresy. Je požadováno upravit algoritmus provádjící výpoet odpisu dluhu dle 123a. 582/1991 Sb., v platném znní tak, aby tento odpis nebyl realizován z podkont splátkových kalendá. Je požadováno rozšíit sestavy ZPPOHLED A ZPPOHLED2 o data ze splátkových kalendá zaútovaných na okres transformací z lokálních aplikací a pevodem mezi okresy. Sestavy je požadováno rozšíit o poty splátkových kalendá a vypotené dlužné ástky. Je požadováno implementovat rozšíené rozhraní webových služeb pro pedávání dat ze sestav do externích systém. Doplnní soutových kontrol v sestavách ZPPOHLED a ZPPOHLED2 je požadováno zmnit zpsob výpotu po splátkových kalendá tak, aby bylo možné provádt definované soutové kontroly, tj. aby 1) celkový poet a ástky splátkových kalendá v daném msíci v sestav ZPPOHLED odpovídaly soutu z minulého msíce + pírstky v daném msíci, 2) celková ástka nedobytných pohledávek v daném msíci v sestav ZPPOHLED odpovídala soutu z minulého msíce + pírstky v daném msíci, 3) souet položek Poet odhlášených se splátkovým režimem a Poet souasných se splátkovým režimem v sestav ZPPOHLED2 odpovídal celkovému potu splátkových kalendá na konci období v sestav ZPPOHLED. Je požadováno, aby ob sestavy uvažovaly jako poet splátek poet otevených podkont SK na konci daného úetního období namísto potu plátc s dluhem ve splátkovém režimu. Za tím úelem je nutno 22

24 epracovat datový model evidence otevení a uzavení podkont, tak aby zohledoval aktuální úetní období. Je požadováno vytvoit sestavu pro zobrazení výsledk soutových kontrol pro uživatele s centrální rolí. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 23

25 3.8.8 Pokladníknihanulovýmobratem Zadání: Je požadováno doplnit novou obrazovku, která umožní zobrazit výpis pokladní knihy i za pokladní den, který ve skutenosti v databázi neexistuje, protože nebyla pijata žádná platba. Zárove je požadováno vytvoit tiskovou sestavu pro výpis pokladní knihy za neexistující pokladní den. Aplikace v souasné dob knihu nevytvoí, jen napíše, že nebyla pijata žádná platba, pípadn napíše, že pokladní den neexistuje. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 24

26 3.8.9 Aprobacesplátkovéhokalendá Zadání: Rozšíit zpracování procesu schvalování splátkového kalendáe o možnost zrušení navrženého splátkového kalendáe jeho autorem. Zajistit, aby v takovém pípad nedošlo k navýšení íselné ady sankcí splátkových kalendá pro dané konto plátce. Zajistit, aby se takto zrušený splátkový kalendá nezobrazoval v pohledech na konto plátce. Zohlednit, aby se takto zrušený splátkový kalendá neprojevil v úetnictví / závrkách. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 25

27 Úpravaimplicitníhozobrazenívyhodnoceníkontazamstnavatele Zadání: V rámci funknosti vytváení ad-hoc vyhodnocení bude automaticky zaškrtnuta volba "Zaokrouhlit edepsané penále", algoritmus vyhodnocení bude zaokrouhlovat spotené penále. Úprava nesmí mít vliv na žádný jiný typ vyhodnocení (vetn fiktivního vyhodnocení nebo vyhodnocení za období). Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 26

28 Možnostzobrazeníkontaplátcetováníehleduzamstnavatele Zadání: i manuálním zadávání pehledu plátce zamstnavatele je poteba umožnit uživateli náhled na konto plátce (tzv. agregovaný pohled na konto plátce). Pedpokládá se zobrazení konta plátce do nového okna, resp. v pípad zobrazení do stejného okna prohlížee je nutné zajistit pechod zpt k formulái Pehledu, aniž by se ztratila již zadaná data. Ošetení situace, kdy v rámci formuláe pehledu zatím není zadán variabilní symbol plátce. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 27

29 Zobrazeníseznamuoperacíspecifickýchsymbol Zadání: Doplnit do aplikace novou funknost umožující zobrazit seznam úetních operací pedpis. Doplnit do aplikace novou funknost umožující zobrazit seznam úetních operací plateb. Doplnit do aplikace novou funknost umožující zobrazit seznam definovaných íselných ad pro konta zamstnavatel (id sankcí). Rozšíení konfigurace aplikace o seznam vybraných speciálních specifických symbol a doplnní funknosti pro zobrazení tchto specifických symbol. Vytvoení nové fyzické role pro zajištní ístupových práv. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 28

30 IntegraceKOC Zadání: Zajištní integrace s APV KOC (Kontrolní innost). Umožnní automatického pedání platebního výmru nebo pokuty z KOC do POJ. Umožnní automatického pedání storna platebního výmru nebo pokuty z KOC do POJ. Zajištní jednoznanosti uloženého dokladu. Zstane zachována možnost manuálního zaútování dokladu. Vytvoení asynchronního procesu, který bude pijaté doklady zaútovávat a vytváet íslušné tituly na kont plátce zamstnavatele. Vytvoení funknosti pro manuální pehled pedaných doklad, umožnní manuálního zpracování pedaného dokladu v rámci této funknosti v pípad, že pi automatickém zaútování došlo k chyb. Umožnní odložení pedaného dokladu, pi jehož zpracování došlo k chyb. Indikace na kont plátce v pípad, že k tomuto plátci existuje zatím nezpracovaný doklad platebního výmru nebo pokuty, který není zaútován. Vytvoení služby, která umožní z POJ pedat informaci o tom, zda byl daný doklad úspšn zpracován a zaútován. Vytvoení nové fyzické role pro zajištní pístupových práv. Zaútování dokladu musí být provedeno tak, aby bylo zajištno umísování plateb na jednotlivé tituly dle preference plátce nebo na základ pravidel stanovených zákonem. 589/1992 Sb. Je nutné upravit algoritmus automatického umisování plateb tak, aby v pípad nezaútovaného platebního výmru byla platba umístna na zvláštní zútovací konto, ze kterého bude možné po zaútování titulu platbu manuáln pevést. Vytvoení služby, pomocí které bude APV POJ pijímat informaci o kontrolovaném období z poslední kontroly plátce (datum do), které bude využito pro kontrolu ped zápisem opravného pehledu do konta. Vytvoení služby, pomocí které bude APV POJ pijímat informaci o stavu probíhající kontroly u plátce. Vytvoení funknosti pro evidenci aktuálního stavu kontroly a manuální zmny stavu. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci Úpravazadáváníintervaludruhésazbypojistnéhozamstnavatele 29

31 Zadání: V aplikaci POJ je možno plátci zamstnavateli nastavit pro rzné msíce dv rzné sazby pojištní. Standardn má každý plátce nastavenu sazbu 1. Sazbu 2 má plátce pro daný msíc nastavenu v pípad, že je tento msíc obsažen v intervalu zadaném pomocí funknosti Nastavení sazby pojistného. Interval lze zadat pouze tak, že zaíná prvním dnem v msíci a koní posledním dnem v roce. Nov bude umožnno nastavit sazbu tak, že interval bude zaínat bu první den v msíci, nebo v den pihlášení plátce v pípad, že plátce byl v daném msíci pihlášen. Konec intervalu bude nastaven vždy bu k poslednímu dni v roce, nebo k datu pedcházejícímu datu pihlášení plátce. Plátci bude pazena sazba 2 pro daný msíc práv tehdy, když bude existovat alespo jeden den v daném msíci, který je obsažen v intervalu, zadaném pomocí funknosti Nastavení sazby pojistného. Budou upraveny kontroly nastavení intervalu tak, aby ke každému intervalu nastavení sazby 2 existoval maximáln jeden interval registrace Algoritmus rozpoítání je navržen tak, že pedpokládá nastavení sazby 2 pouze v intervalech po celých sících. Algoritmus bude upraven, aby správn akceptoval intervaly nastavení sazby 2, pestože mohou zaínat i konit v prhu msíce. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 30

32 UmožnnítovánínavšechpracovištíchPSSZ Zadání: Vybraným pracovníkm Územních pracoviš PSSZ bude umožnno provádt vybrané operace s dopadem do úetnictví, pestože místní píslušnost pracovníka se neshoduje s kontem, na kterém je útováno. Tyto operace bude možno provádt na všech ÚP PSSZ na kontech plátc píslušných PSSZ nezávisle na íslušnosti konta k jednotlivým ÚP. Aplikace umožní manuáln zmnit okres/pracovišt, na který je referent pihlášen. Výbr okres, na které bude možno pepnout, bude dán interním íselníkem POJ. Pepnutí lokality bude probíhat výhradn manuáln, v pípad neinnosti v aplikaci bude po uritém ase (cca 20 minut) nastavena zpt dle místní píslušnosti referenta. Logické role pazované AAA portálem budou rozšíeny o novou sadu logických rolí, které budou pi standardní práci s aplikací ignorovány. Primárn bude uživatel pihlášen na okres dle jeho místní íslušnosti a bude mít nastavena práva dle nastavených logických rolí z pvodní sady. V pípad uživatelského pepnutí na jinou místní píslušnost budou uživateli nastavena práva pouze dle nové sady logických rolí. Tato nová sada logických rolí bude oznaena postfixem a bude použita pouze tehdy, pokud uživatel zmní místní píslušnost. íselník popisující rozsah okres, na které je možno uživatelsky pepnout, bude koncipován tak, aby umožnil konfiguraním zásahem doplnit nový balík logických rolí s dalším novým postfixem. Logické role s novým postfixem by pak umožovaly uživateli zmnit svoji místní píslušnost na rozšíený rozsah okres, na kterém by ml uživatel nastavená práva dle logických rolí s novým postfixem. Takový konfiguraní zásah by pak umožnil pepínat na jiný okres napíklad v rámci celé R. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 31

33 Zmnavýpotusborníkrekapitulací Zadání: Aplikace POJ bude upravena tak, že úetní sestavy sborník a rekapitulací, které jsou aktuáln poítány ad-hoc pi vyvolání, budou vypoteny asynchronn v rámci krok msíní úetní Závrky. Pi zobrazení výsledk v rámci funknosti Sborníky a sestavy se již budou nabízet a následn zobrazovat uložené sestavy. Technický mechanismus uložení sestav bude souástí navrženého ešení. V pípad, kdy dojde ke zrušení píslušných krok úetní závrky, musí dojít ke zrušení pedpipravených sestav. Pro neuzavená úetní období resp. úetní období, u nichž zatím neprobhla závrka, budou nadále k dispozici pedbžné sborníky a rekapitulace, poítané ad-hoc. Zmna aplikace se týká jak agendy Nemocenského pojištní OSV a Zahraniních zamstnanc (11 sestav), tak Zamstnavatel (36 sestav). Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro každý tento požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 32

34 PorovnánídatPOJVZT Zadání: Provedení analýzy rozdíl mezi daty o pojistných vztazích v DB VZT a DB POJ. Vytvoení nového uživatelského rozhraní pro monitoring komunikace VZT - POJ. Zobrazení informací o aktuálním stavu požadavk na zmnu pojistných vztah NP OSV a historie stav Zamstnavatele. Bude vytvoena skupina pehled pro kontrolu prhu komunikace systém POJ a VZT. Skupina bude zahrnovat: ehled požadavk, které nebyly provedeny z dvodu chyby, ehled požadavk na založení konta, ehled kont založených v období, ehled kont ukonených v období, ehled zmn píslušnosti k SSZ. Tyto pehledy umožní jak tiskový výstup, tak export do MS Excel. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 33

35 EvidencesplátekSPR Zadání: Komunikaní rozhraní POJ se SPR bude rozšíeno o sadu nových služeb, která umožní výmnu dat o splátkových kalendáích. Pro komunikaci iniciovanou ze SPR budou poskytnuty následující služby: 1. Služba pro poskytnutí výstup z vyhodnocení služba zajistí vyhodnocení konta ke zvolenému datu. Budou vyhodnoceny zstatky na všech podkontech, vypoten dluh na penále, pojistném a pokutách s ohledem na 22a zákona.589/1992 Sb. a data budou pedána pomocí webové služby do SPR. Algoritmus musí ovit, že na kont nechybí nkterá data nutná pro úplné vyhodnocení, v pípad, že takový pípad nastane, bude vrácena odpovídající chyba a data nebudou pedána. V APV POJ bude implementována evidence vyhodnocení, která byla pedána do SPR. 2. Služba pro založení splátkového kalendáe na základ požadavku SPR zajistí založení podkonta splátkového kalendáe ve vztahu k platnému vyhodnocení pedanému do SPR a provede požadované vyvedení pohledávek na takto založené podkonto. Do SPR pak služba pedá specifický symbol nov založeného splátkového kalendáe. Tituly vyvedené do splátkového kalendáe pak budou vypuštny z pedávání k vymáhání, dokud píslušný splátkový kalendá nebude uzaven. 3. Služba pro schválení splátkového kalendáe zpsob schvalování splátkových kalendá bude rozšíen o možnost schválení ze SPR pro kalendáe založené ze SPR. POJ umožní schválení jak standardní cestou, tak pijetím odsouhlasení elektronicky ze SPR. 4. Služba pro ukonení splátkového kalendáe SPR bude moci prostednictvím této služby ukonit splátkový kalendá, který byl ze SPR založen a schválen. Ukonení bude respektovat aktuáln platné zpsoby ukonení. Do POJ bude implementován nový algoritmus pro vyvedení zbývající ásti dluhu na pvodní tituly a vyešení rozdíl v pípad vymáhaných titul. Bude vytvoena asynchronní úloha, která bude na msíní bázi ovovat, zda bylo konto již vyhodnoceno k poslednímu dni pedchozího msíce a tato skutenosti bude evidována. Dále bude v POJ vytvoena funkcionalita notifikace o vybraných událostech do SPR. Notifikace budou zahrnovat tyto pípady: Zneplatnní vyhodnocení pedaného do SPR; Zmna specifického symbolu podkonta splátkového kalendáe; Splátkový kalendá byl stornován; Na kont bylo zaútované msíní vyhodnocení; Na kont nebylo vytvoeno msíní vyhodnocení do 15. dne následujícího msíce; Ukonení splátkového kalendáe bylo stornováno; 34

36 Titul odeslaný do SPR byl stornován; Interval výkonu rozhodnutí byl manuáln upraven. Historie komunikace POJ a SPR bude zaznamenávána v DB POJ a bude umožnn náhled na tyto záznamy. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 35

37 Plátcebezpovinnostiedkládatehledy Zadání: Bude pidána funkcionalita umožující zaznamenávat a mnit informaci o povinnosti plátce podávat ehledy formou historie stav plátce. Záznamy tohoto typu budou následn využity v nov implementované automatické funkci pro vytváení nulových pehled, která bude navázána na dávkové zpracování a podmínna uzavením msíce. Tato funkce vytvoí nulové pehledy pro všechna konta, která v daném msíci nemají povinnost podávat ehled. Pro pípad zptné zmny stavu budou vytvoeny mechanismy pro stornování již vytvoených nulových ehled a všech navazujících operací. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 36

38 NezneplatovánítitulupožadavkemVZT Zadání: Nov bude zavedeno uložení dvodu zneplatnní vyhodnocení a detail zneplatnní bude rozlišen na kolika základních úrovních, respektive v nkolika základních business procesech. V pípad, že v systému POJ dojde z jakéhokoliv dvodu ke zneplatnní platného vyhodnocení, bude daná informace uložena u zneplatnného vyhodnocení. Tato nová funkcionalita rozliší, zda bylo vyhodnocení zneplatnno požadavkem z VZT nebo z dvodu zásahu uživatele. Informace o dvodu zneplatnní bude pidána do uživatelského rozhraní do pehledu Seznam vyhodnocení konta a do detailu vyhodnocení. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 37

39 Možnostopravituloženoupoznámku Zadání: POJ umožní "vymazat" i editovat vlastní poznámku všem uživatelm píslušné OSSZ, pod kterou je konto aktuáln zaazeno. Bude implementována logika pidlení práv na vybrané záznamy (podle autora záznamu). Autor poznámky pak bude mít právo editovat i mazat. Zárove bude takto umožnno omezit práva jen pro vybrané role. Nkteré role tedy budou omezeny filtrem na vlastní záznamy a jiné role budou moci editovat nebo mazat všechny záznamy bez omezení. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 38

40 Stornoazeníokresureferentovi Zadání: Aplikace POJ bude rozšíena o možnost stornování pazení okresu referentovi. Bude rozšíeno uživatelské rozhraní o pehled pazení referent okresm a pidána funkcionalita pro zneplatnní a ípadné obnovení tchto záznam. Na tento pehled bude vytvoena samostatná fyzická role a implementována funkcionalita práv podle filtru na záznamy. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 39

41 Insolvencesestavzaútovanýchedpisplateb Zadání: Sestava pro výpoet dluhu dle 11 odst. 2 zákona. 155/1995 Sb. bude rozšíena o zobrazení informace o stavu insolvence a datum platnosti od podle aktuálního stavu plátce zaznamenaném prostednictvím historie stav plátce. Pro penos této informace do lokálních aplikací bude pipravena služba poskytnutí informace o stavu insolvence navázaná na službu penosu dat pedpis a plateb. Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 40

42 InformacevrácenémeplatkuNPOSV Zadání: Uživatelské rozhraní pehledu umístní plateb NP OSV bude rozšíeno o informace o výši jednotlivých eplatk, zpsobu a stavu jejich vypoádání. Krom záznam samotných peplatk tak bude možné sledovat kompletní vazby i pi mnohoetném vypoádání (více plateb vypoádaných najednou nebo naopak rozdlení zpsobu vypoádání jedné platby). Zhotovitel pedloží podrobný závazný popis plnní výše uvedeného zadání. Zhotovitel pro tento typový požadavek minimáln popíše: Detailní návrh ešení typového požadavku; Maximální poet lovkodní dle rolí na realizaci. 41

43 4 ZajištníaplikanípodporyAPVPOJ Úvod: Poskytování aplikaní podpory zahrnuje následující dílí plnní: evzetí do servisu; Poskytování podpory APV POJ. 4.1 evzetídoservisu Závazné podmínky: V rámci pevzetí aplikaní podpory do servisu se Zhotovitel seznámí s APV POJ a proškolí své leny realizaního týmu ped zaátkem poskytování aplikaní podpory APV POJ takovým zpsobem, aby byl schopen zajistit poskytování veškerých služeb dle pedmtu plnní této Smlouvy. Zhotovitel v rámci této oblasti pedloží podrobný návrh, jak bude pevzetí do servisu realizovat. Zárove v této ásti vydefinuje požadavky na souinnost Objednatele. Objednatel není povinen pi pevzetí do servisu zajistit souinnost 3. stran nap. dodavatel Objednatele Rozsahevzetídoservisu V rámci této kapitoly Zhotovitel závazn popíše: Podrobný návrh pevzetí do servisu; Potebnou souinnost v následující struktue: o Popis souinnosti; o Popis role na stranssz; o Rozsah oekávané souinnosti (v D). Organizaní zajištní. 4.2 PoskytováníaplikanípodporyAPVPOJ Závazné podmínky: 42

44 Podpora aplikace bude zajištna na odstraování chyb na základ SLA definovaných níže. Zhotovitel eší všechny nalezené chyby v aplikaci pod domluvenými SLA (všechny asy jsou poítány na pracovní dny a as v eské republice): o Zodpovídá za analýzu, opravu a test chyb. o Zodpovídá za plánování oprav do balí v návaznosti na SLA finální termín nasazení potvrzuje SSZ. o edává opravenou chybu s prvodkou popisující kdo, jak provedl test, jak byla chyba opravena a co bylo její pinou. o Je povinen opravovat pinu i následek chyby (opravy pouze následk a neopravování in budou negativním kritériem hodnocení). o Je povinen dodat testovací data pro pípadný retest chyby Objednatelem. o Je povinen dodržovat standardy vývoje definované Objednatelem. Zodpovídá za úplnost a korektnost opravných balíku dodávaných na provoz. Zodpovídá za vasné informování SSZ o možných dopadech opravy na souinné aplikace. Zodpovídá za aktualizaci automatizovaných test (pokud existují). Musí poskytnout plnou souinnost pro nasazení oprav na produkci a zvýšenou podporu po nasazení pro provoz IT. Zodpovídá za aktualizaci veškeré dokumentace ovlivnné opravou. Zajišuje podporu uživatel eší management defekt v nástroji na sledování chyb a eskalaci problém. ipravuje podklady na status meetingy. Reportuje plnní SLA na msíní úrovni (pipravuje podklady pro vyhodnocení kontrolních parametr). astní se a vede aktivity v procesech problém managementu. Poskytuje souinnost pro opravy v ostatních aplikacích. Školení uživatel: o íprava školících materiál pro školení uživatel. o íprava dat a prostedí pro školení uživatel. o Realizace školení uživatel. o Vyhodnocení zptné vazby. edání aplikaní podpory v pípad ukonení Smlouvy se ídí ustanovením Smlouvy NávrhSLA Závazné podmínky: 43

45 Zhotovitel se zavazuje dodržovat definovanou úrove služeb pro ešení chyb (incident): Oblast Kategorie A Kategorie B Kategorie C ekávaná doba Reakce Odstranní Reakce Odstranní Reakce Odstranní 1 hod 12 hod 6 hod 50 hod 20 hod 100 hod Reakní dobou v tomto pípad Objednatel rozumí pevzetí chyby, provedení úvodní analýzy problému a edání informaci o dvodu chyby a pedpokládaném ešení. Pro úely dodržování výše uvedených parametr reakní doby a doby odstranní závady (dobou pro odstranní závady se rozumí doba, která zapone bžet asem pedání incidentu Zhotoviteli a bude ukonena v ase pedání vyešeného incidentu zpt Objednateli) je dále uvedeno rozdlení závad do kategorií: za závady kategorie A budou považovány kritické chyby, kterými se rozumí zejména havárie, poruchy, chyby, vady vedoucí k perušení provozu nebo jeho kritickému omezení a znemožující používání a využívání APV nebo databází nebo systémového vybavení nebo hardware k úelu, k muž je ureno, za závady kategorie B budou považovány hlavní chyby, kterými se rozumí poruchy, chyby, vady, které zpsobují provozní problémy, ale neznemožují používání a využívání APV nebo databází nebo systémového vybavení nebo hardware k úelu, k nmuž je ureno, a lze je doasnešit organizaními nebo technickými opateními, za závady kategorie C budou považovány vedlejší chyby, kterými se rozumí mén závažné poruchy, chyby, vady nebo diference APV, které nemají vliv na používání a využívání APV nebo databází nebo systémového vybavení nebo hardware k úelu, k nmuž je ureno. Lhty se ve vcech reakních dob pro ešení incident poítají v rámci pracovní doby Objednatele, tedy h lhty se pozastavuje na konci každého pracovního dne a obnovuje na poátku pracovní doby následujícího pracovního dne. Pracovní doba se pro tento pípad definuje od 7:00 do 17:00. Pozastavení poítání lhty s koncem pracovní doby neplatí pro ešení chyby kategorie A. Není-li vzájemn dohodnuto jinak, lhta pro mení doby reakce a doby odstranní incidentu zapone žet asem pedání incidentu Zhotoviteli a bude ukonena v ase pedání vyešeného incidentu zpt Objednateli. Celková doba odstranní je pak souet všech asových dob, po které byl incident v ešení na stran Zhotovitele. Z celkové doby odstranní incidentu jsou vyloueny asové doby, kdy Zhotovitel prokazateln nemohl pokraovat v ešení incidentu z dvod, které nebyly jím zpsobené (nap. Zhotovitel eká na doplnní relevantních informací k incidentu od Objednatele apod.). Pro výpoet lht jsou urující asové záznamy v systému Helpdesk Objednatele k danému incidentu. 44

46 edávání incident bude probíhat dle požadavku Objednatele prostednictvím helpdesku Objednatele, emž Zhotovitel je povinen incidenty z helpdesku Objednatele automaticky pijímat Dodatenémetriky Závazné podmínky: Hodnocení aplikaní podpory musí dále zohledovat následující kritéria: Vyhodnocení procenta chyb, u kterých nebyla opravena pina. Vyhodnocení opravy chyb, kde nedošlo k úspšné oprav, nebo byla zavleena nová chyba. Vyhodnocení potu nekorektních balí chybn dodané balíky, nebo balíky které vyžadovaly nestandardní zásah provozu IT (nešli nasadit podle dodaného postupu). Vyhodnocení dodržování vývojových standard Algoritmusvyhodnoceníaplikanípodpory Úvod: Tato kapitola popisuje zpsob, jakým bude vyhodnocována definovaná úrove služeb v oblasti aplikaní podpory. Závazné podmínky: Vyhodnocování bude probíhat na msíní bázi. V pípad neplnní vyhodnocovaných kritérií, mžou být uplatnny definované sankce na platbu za aplikaní podporu. V pípad hrubého neplnní SLA je možné odstoupení od Rámcové smlouvy nebo Dílí smlouvy. Hrubým neplnním SLA je napíklad neplnní definované úrove služeb v oblasti aplikaní podpory u kategorie závady A, a to v rozsahu minimáln dvakrát v kalendáním msíci nebo napíklad opakované nedodržování dodatených SLA metrik.sla reakní doby pro ešení chyb A, B, C je definováno v kapitole Pro úely hodnocení se vyhodnocuje splnní reakní doby a doby vyešení chyby pro každý jednotlivý pípad a penalizace za nesplnní asových limit probíhá dle ustanovení Rámcové smlouvy. Vyhodnocení dodatených metrik: V pípad, že procento chyb, u nichž nebude opravena pina, pesáhne 10%, bude v meném období nastaven parametr SLApina = -5%. V pípad, že procento chyb, u nichž po nasazení do produkce bude konstatováno, že nedošlo k oprav, nebo že došlo k zavleení další chyby, pesáhne 20%, bude v meném období nastaven parametr SLAzavle = -5%. V pípad, že poet nekorektních produkních balí pesáhne poet jednoho nekorektního nasazení za msíc, bude nastaven parametr SLAbalíek = -5%. 45

47 V pípad, že ze strany Objednatele bude v rámci hodnocení aplikaní podpory eskalováno nedodržování vývojových standard a tato situace se nezmní ani následující msíc, bude nastaven parametr SLA standardy = -5%. Celkový parametr vyhodnocení aplikaní podpory definujeme jako: = 100% Spoítané bude využito ke snížení msíní ceny za aplikaní podporu podle pravidel popsaných v Píloze. 2 Cena plnní Rozsahslužebaplikanípodpory V rámci této kapitoly Zhotovitel závazn popíše: Metodiku ízení aplikaní podpory; Definici pedpokládaných proces aplikaní podpory; Popis nabízených služeb v rámci aplikaní podpory; Popis požadované souinnosti v rámci aplikaní podpory; Návrh pedání aplikaní podpory a rozvoje pípadnému novému dodavateli; Organizaní zajištní. 46