I-02 Projektový zámer (projektovy_zamer)

Version 66.1 by Markéta Šimoni on 2025/07/24 10:35

PROJEKTOVÝ ZÁMER

Manažérsky výstup  I-02

 podľa vyhlášky MIRRI č. 401/2023 Z. z.  (účinnosť od 1.4.2025)

Povinná osobaNárodná agentúra pre sieťové a elektronické služby
Názov projektuVybudovanie katalógu poplatkov
Zodpovedná osoba za projektTBD
Realizátor projektuNárodná agentúra pre sieťové a elektronické služby
Vlastník projektuMinisterstvo investícií, regionálneho rozvoja a informatizácie

Schvaľovanie dokumentu

PoložkaMeno a priezviskoOrganizáciaPracovná pozíciaDátum

Podpis

(alebo elektronický súhlas)

      
      
  1. HISTÓRIA DOKUMENTU
VerziaDátumZmenyMeno a priezvisko
 8.7.2025Verzia na zverejnenie na META ISPeter Ďuriš
    
    
  1. ÚČEL DOKUMENTU, SKRATKY (KONVENCIE) A DEFINÍCIE

V súlade s vyhláškou MIRRI č. 401/2023 Z.z. v znení neskorších predpisov je tento výstup I-02 Projektový zámer určený na rozpracovanie detailných informácií prípravnej a iniciačnej fázy projektu z pohľadu aktuálneho stavu, budúceho stavu a navrhovaného riešenia.

Dokument Projektový zámer obsahuje manažérske zhrnutie, rozsah, ciele a motiváciu na realizáciu projektu, zainteresované strany, návrh merateľných ukazovateľov a obsahuje aj:

  • detailný opis požadovaných projektových výstupov,
  • detailný opis obmedzení, predpokladov, tolerancií a návrh organizačného zabezpečenia projektu,
  • detailný opis rozpočtu projektu a jeho prínosov,
  • harmonogram projektu,
  • vyhodnotenie rizík a závislostí,
  • architektúru riešenia projektu na úrovni biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy a bezpečnostnej architektúry,
  • vyhodnotenie alternatív riešenia projektu pre každú vrstvu architektúry riešenia,
  • špecifikáciu a klasifikáciu údajov spracovaných v projekte,
  • požiadavky na prevádzku a údržbu výstupov projektu,
  • požiadavky na technologickú infraštruktúru a posúdenie alternatív prevádzky infraštruktúry cloud computingom,
  • požiadavky na zdrojové kódy,
  • opis implementácie projektu a preberania výstupov projektu.

Súčasťou komplexnej projektovej dokumentácie sú aj dokumenty ako I-04 Katalóg požiadaviek, M-05 Analýza nákladov a prínosov a M-06 Evidencia komponentov v MetaIS.

    1. Použité skratky a pojmy
Skratka / PojemPopis
API GWBrána pre prístup k API integračným rozhraniam
APONETInformačný systém Slovenskej pošty pre automatizáciu poštových operácií
CAMPCentrálna API manažment platforma, centrálny API GW štátu
eDeskModul komunikačných schránok
FO eKolok, eKolok FrontOfficeFront Office systém pre službu eKolok, pomocou ktorého sú poprepájané platobné kanály a zariadenia služby eKolok – MASP, kiosky, APONET, POS, pokladne úradov
G2GModul asynchrónnej komunikácie systémov
GUIGrafické rozhranie pre používateľa
IAMModul pre overenie identity a autentifikáciu
ISInformačný systém
JSONFormát vymieňanej správy medzi integrovanými systémami
kioskFyzické platobné zariadenie, prostredníctvom ktorého je možné zakúpiť eKolky
KPKatalóg poplatkov
MASPMobilná aplikácia Slovenskej pošty
MEPModul elektronických platieb
MSPKomponent PEP pre prácu úradníkov s eKolkami
MV SRMinisterstvo vnútra Slovenskej republiky
OEKKomponent PEP pre prácu úradníkov s eKolkami na obslužných miestach MV SR
OVMOrgán verejnej moci
PEPSystém pre evidenciu poplatkov (eKolkov)
POSPlatobný terminál
PnÚPríkaz na úhradu
RESTKomunikačný protokol pre integrované systémy
SOAPKomunikačný protokol pre integrované systémy
SSOSingle sign on
SRSlovenská republika
ÚPVSÚstredný portál verejnej správy
VSVerejná správa
XMLFormát vymieňanej správy medzi integrovanými systémami

Tabuľka 1 Skratky a pojmy

    1. Konvencie pre typy požiadaviek

Z pohľadu definovania požiadaviek v rámci katalógu požiadaviek boli tieto rozdelené na:

  • Funkčné
  • Nefunkčné
  • Technické

Katalóg požiadaviek je neodmysliteľnou súčasťou projektovej dokumentácie

  1. DEFINOVANIE PROJEKTU
    1. Manažérske zhrnutie

Aktuálne je evidencia a správa správnych, súdnych a iných poplatkov v informačných systémoch verejnej správy nejednotná, pričom dominantnú rolu v správe sadzieb zohráva IS PEP prevádzkovaný Slovenskou poštou. Iné poplatky sú evidované v agendových informačných systémov napr. obcí a VÚC. Tento model:

  • neumožňuje centralizovanú a právne záväznú správu sadzieb,
  • neposkytuje štandardizované API pre elektronické služby,
  • spôsobuje duplicity a rozdiely medzi elektronickými a priehradkovými podaniami,
  • obmedzuje rozvoj služieb elektronického podania (MEP, ÚPVS),
  • neposkytuje plnohodnotnú podporu parametrických sadzieb (napríklad v doprave, justícii).

Projekt Katalóg poplatkov je systémovým opatrením na modernizáciu správy sadzieb správnych, súdnych a iných poplatkov vo verejnej správe SR. Jeho cieľom je vytvoriť nový, právne záväzný a centrálne spravovaný informačný systém verejnej správy (ISVS), ktorý bude jednotným zdrojom pravdy pre sadzby poplatkov uplatňované pri všetkých typoch podaní — elektronických aj fyzických.

V súčasnosti je agenda poplatkov spravovaná v rôznych, technologicky i procesne nejednotných systémoch, predovšetkým v IS PEP prevádzkovanom Slovenskou poštou pre správne a súdne poplatky a agendových systémov verejnej správy pre iné typy poplatov. Ten neumožňuje dynamickú parametrizáciu sadzieb, verzionovanie ani právne auditovateľnú evidenciu zmien. Výsledkom je, že medzi rôznymi systémami (napr. IS PEP, MEP, MSP, Kiosky, špecializované portály) vznikajú rozdiely v sadzbách, nejednoznačný výklad práva a riziko nesprávnych úhrad zo strany občanov a podnikateľov.

Projekt Katalóg poplatkov prinesie:

  • centrálne riadený a právne záväzný register sadzieb,
  • určovanie a dynamické výpočty poplatkov podľa aktuálneho stavu legislatívy,
  • verzionovanie a auditovateľnosť zmien,
  • jednotné API pre napojenie IS PEP, IS MEP, MSP a ďalších systémov VS,
  • odstránenie duplicít medzi elektronickými a fyzickými kanálmi,
  • plnú podporu parametrických poplatkov,
  • lepší používateľský zážitok pre občanov aj pracovníkov VS.

Výsledky projektu budú prínosom pre:

  • pracovníkov verejnej správy (priehradkové pracoviská, súdy, SP, obce, VÚC),
  • občanov a podnikateľov (jednotné sadzby, menšia chybovosť, zníženie administratívneho zaťaženia),
  • správcov sadzieb (MF SR, OVM), ktorí získajú kontrolu nad údajmi a ich cyklom života,
  • elektronické služby eGovernmentu (MEP, ÚPVS), ktoré získajú jednotné a právne korektné dáta.

Katalóg poplatkov prinesie zároveň jednotné, transparentné a digitálne spravovateľné prostredie pre poplatky všetkých typov. Každá inštitúcia verejnej správy získa možnosť definovať poplatky zrozumiteľne a v súlade s legislatívou, pričom občania budú mať prehľadné informácie o výške, spôsobe výpočtu a úhrady poplatkov.

Projekt je plne v súlade s cieľmi NKIVS a prioritami OP Slovensko (Priorita 1), a zároveň je v súlade s požiadavkami na zabezpečenie interoperability služieb verejnej správy a modernizáciu dátovej správy.

Predpokladaná doba realizácie projektu je 12 mesiacov. Predpokladaná výška investície je cca 1,734 milióna EUR s DPH. Financovanie je navrhnuté z OP Slovensko – Priorita 1: Zvýšenie kvality eGovernment služieb a interoperability:

  • RSO1.2 Využívanie prínosov digitalizácie pre občanov, podniky, výskumné organizácie a orgány verejnej správy
  • 1.2.1 Podpora v oblasti informatizácie a digitálnej transformácie (B. Podpora v oblasti zvýšenia kvality poskytovaných verejných služieb)

Výstupy projektu budú nasadené do vládneho cloudu (GOV Cloud), čo umožní vysokú dostupnosť a škálovateľnosť riešenia.

Zavedením Katalógu poplatkov sa podstatne zvýši právna istota v oblasti poplatkov, zlepší sa jednotnosť dát a zníži chybovosť pri výbere poplatkov, čo bude mať pozitívny dopad na občanov, podnikateľov aj verejnú správu.

    1. Motivácia a rozsah projektu

Zákonom 238/2017 Z. z. sa zavádza základný číselník poplatkov ako štruktúrovaný zdroj sadzobníka správnych poplatkov, súdnych poplatkov a iných poplatkov verejnej správy s tým, že tento číselník bude záväzný pre všetky systémy (ÚPVS, IS PEP, IS IOM, špecializované portály, systémy obcí a VUC a prípadne ďalšie technické zariadenia) v procese vyberania správnych a súdnych poplatkov.

V  súčasnosti  neexistuje  štruktúrovaná  verzia  sadzobníka  správnych, súdnych a iných poplatkov verejnej správy. Sadzobník správnych poplatkov, ktorý tvorí prílohu Zákona o správnych poplatkoch a sadzobník súdnych poplatkov, ktorý tvorí prílohu Zákona o súdnych poplatkoch má podobu textovej časti bez väzby na konkrétne služby orgánov verejnej moci. Poplatky iných inštitúcií sú často verené v osobitných právnych predpisoch alebo všeobecných záväzných nariadeniach (v prípade obcí a VUC). Transformáciasadzobníkov do podoby základného číselníka je zložitá z hľadiska právnej relevantnosti, nakoľko položky sadzobníkov vrátane vnútorného členenia v písmenách a bodoch majú aj ďalšiu väzbu na ustanovené výnimky zo všeobecných alebo špecifických pravidiel, ktoré sú uvedené v poznámkach alebo oslobodeniach priamo pod jednotlivými položkami sadzobníka alebo v paragrafovej časti zákona (napr. uplatnenie zľavy z poplatku pri elektronickom podaní, stanovenie výšky poplatku pri kasačnej sťažnosti). Okrem toho reálne poskytované služby orgánov verejnej moci alebo organizácii vo verejnej správe mnohokrát nezodpovedajú len jednej z položiek sadzobníka, ale sú kombináciou viacerých položiek alebo sa uplatňujú viaceré variácie položiek a poznámok, takže existuje väčší počet kombinácií ako je položiek, písmen a bodov v sadzobníkoch. V konečnom dôsledku, iba systémová príprava funkcionality a riadenia základného číselníka poplatkov prostredníctvom vybudovania samostatného IS, dáva predpoklad právnej záväznosti a všeobecnej využiteľnosti v informačných systémoch verejnej správy s vylúčením možnej nesprávnej alebo nejednoznačnej aplikácie.

Základná motivačná schéma je na nasledujúcom obrázku:

1751966452334-121.png

Obrázok 1 Vizualizácia motivácie pre realizáciu projektu

Pre naplnenie cieľa projektu je zásadné, aby bola v budúcom stave vytvorená a spravovaná jednotná centrálna evidencia poplatkov vo forme Katalógu poplatkov (KP). Tento katalóg nebude len pasívnym číselníkom, ale dynamickým, parametrizovateľným nástrojom, ktorý umožní riadiť a kontrolovať proces výpočtu, výberu a evidencie poplatkov naprieč verejnou správou.

Základnú kostru KP bude tvoriť štruktúra odvodená z ekonomickej a rozpočtovej klasifikácie, aby bolo možné poplatky a platby správne zatriediť podľa zdroja príjmov, subjektu výberu a účelu použitia.

V rámci projektu bude rovnako vytvorená nultá verzia KP, ktorá bude vychádzať z preparametrizovania existujúceho číselníka poplatkov (aktuálne vedeného v excel formách). V rámci analytickej časti bude realizovaný analýza s cieľom identifikovať základné parametre poplatkov za oblasti správnych a súdnych poplatkov. Tieto parametre môžu zahŕňať:

  • zákonný alebo iný právny základ,
  • typ poplatku,
  • sadzbu alebo výpočet,
  • možné hodnoty a varianty výpočtov (percentá, pevné sumy, kombinované vzorce),
  • matematické operácie a väzby na ďalšie registre
  • a iné parametre.

Každá položka KP bude mať jedinečné ID, pod ktorým sa zoskupujú zodpovedajúce parametre a syntéza logických väzieb. Zároveň bude vytvorená väzba medzi KP a službami, ktorých výkon generuje povinnosť úhrady poplatku. Táto väzba umožní automatizované priraďovanie poplatkov k jednotlivým životným situáciám a elektronickým podaniam.

Súčasťou projektu bude preto komplexný Katalóg platieb (KP), ktorý podľa potreby pokryje:

  • Nielen správne poplatky (podľa zákona o správnych poplatkoch),
  • a súdne poplatky (podľa zákona o súdnych poplatkoch),
  • ale aj iné typy platieb orgánom verejnej moci ako napr.
    • miestne dane a poplatky (napr. daň z nehnuteľností, poplatok za komunálny odpad, daň za psa, daň za užívanie verejného priestranstva),
    • ostatné licenčné, administratívne a iné poplatky, pokuty, penále, sankcie regulované osobitnými predpismi.
    1. Špecifické administratívne a licenčné poplatky, ktoré vznikajú v procese konaní a autorizácii.Zainteresované strany (Stakeholderi)

V nasledujúcej tabuľke sú uvedení dotknutí stakeholderi projektu rozvoja:

AKTÉR / STAKEHOLDERSUBJEKT (NÁZOV / SKRATKA)ROLA V PROJEKTE
Riadiaci orgánMinisterstvo investícií, regionálneho rozvoja a informatizácie SR (MIRRI SR)Riadenie a koordinácia projektu, koordinácia s OVM, vlastník projektu
Riešiteľ projektuNASESZabezpečuje prípravu a schvaľovanie štúdie, príjemca NFP (ak EÚ financovanie), ako aj obstarávania prípadných externých prác a zdrojov.
Gestor legislatívyMinisterstvo financií SR (MF SR)Zabezpečenie legislatívnych zmien, garant právneho rámca poplatkov
Prevádzkovateľ IS PEPSlovenská pošta, a.s. (SP)Spolupráca na integrácii IS PEP, migrácia údajov, zmena interných IS
Prevádzkovateľ IS MEPNASESSpolupráca na integrácii IS MEP, technické zabezpečenie API napojení
Prevádzkovateľ MSPSlovenská pošta, a.s. (SP) / iné OVMPrispôsobenie MSP (Modulu správy poplatkov) na nový Katalóg
Prevádzkovateľ ÚPVSNASESIntegrácia Katalógu s ÚPVS, správa IAM služieb
Gestori sadziebOVM (MF SR, MV SR, MS SR, MZ SR, obce, VUC, iné OVM atď.)Správa údajov v Katalógu, schvaľovanie sadzieb
Technický integrátorExterný dodávateľ systému Katalóg poplatkov (víťaz verejného obstarávania)Vývoj a dodanie ISVS Katalógu poplatkov, implementácia, testovanie
Prevádzkovateľ GOV CloudNárodná agentúra pre sieťové a elektronické služby (NASES)Prevádzka a SLA poskytovanie cloud prostredia pre ISVS
Odborní garanti za OVMZástupcovia OVM (MF SR, MV SR, MS SR, MZ SR, obce, VUC a pod.)Validácia údajov v Katalógu, testovanie
Priehradkoví úradníciZamestnanci OVM a SP (priehradkové pracoviská)Koncoví používatelia FE, pripomienky k UX/FE návrhom
Občania a podnikateliaKoncoví používatelia e-služieb (cez ÚPVS, MEP)Príjemcovia služby (nepriame zapojenie, spätná väzba po spustení)
Dodávateľ IS PEP / MSPAktuálny dodávateľ (dodávateľ SP)Potrebné úpravy IS PEP, MSP (súčasť rozvoja)
Rada vlády pre digitalizáciu VSRVVS / NKIVSOdborný garant súladu s NKIVS, dohľad nad súladom projektu so stratégiami eGov

Tabuľka 2 Zainteresované strany (Stakeholderi)

    1. Ciele projektu

V nasledujúcej tabuľke sa nachádzajú dotknuté ciele projektu, ktoré reflektujú ciele NKIVS a P SK:

Cieľ projektu (S.M.A.R.T.)Väzba na NKIVSKPI (merateľný ukazovateľ)Väzba na špecifický cieľ OP SK (Priorita 1)
Zaviesť centrálny právne záväzný Katalóg poplatkov pre OVM do prevádzky do 24 mesiacovNKIVS 1.2.2 Interoperabilita a referenčné údaje verejnej správySystém v produkcii (GO-LIVE), zápis v MetaISPriorita 1, Špecifický cieľ 1.1 Zvýšenie kvality eGovernment služieb
Integrovať IS PEP, IS MEP a MSP na nový Katalóg do 18 mesiacovNKIVS 2.1.1 Interoperabilné služby VS% integrovaných IS (cieľ = 100 %)Priorita 1, Špecifický cieľ 1.2 Zvýšenie interoperability informačných systémov verejnej správy
Zabezpečiť jednotné používanie sadzieb pre 100 % elektronických podaní do 12 mesiacov od GO-LIVENKIVS 1.3.1 Kvalita údajov a referenčných registrov% e-podaní s údajmi z Katalógu (cieľ = 100 %)Priorita 1, Špecifický cieľ 1.1
Odstrániť rozdiely medzi sadzbami v elektronickom a fyzickom proceseNKIVS 1.3.2 Konzistentnosť údajov naprieč IS VSPočet nekonzistencií (cieľ = 0)Priorita 1, Špecifický cieľ 1.1
Zabezpečiť auditovateľnosť zmien sadzieb v 100 % položiek KatalóguNKIVS 1.3.2 Konzistentnosť a auditovateľnosť údajov% položiek s audit trailom (cieľ = 100 %)Priorita 1, Špecifický cieľ 1.1
Skrátiť priemerný čas aktualizácie legislatívnych zmien sadzieb na < 10 dní od legislatívnej účinnostiNKIVS 2.3.1 Efektívna správa údajovPriemerná doba aktualizácie sadzieb v IS (cieľ < 10 dní)Priorita 1, Špecifický cieľ 1.1
Zabezpečiť 99,5 % dostupnosť služby Katalógu pre všetky integrované ISNKIVS 1.4.1 Dostupnosť a kvalita služieb VSSLA dostupnosti (cieľ ≥ 99,5 %)Priorita 1, Špecifický cieľ 1.1
Zvýšiť podiel elektronických podaní využívajúcich online určenie sadzieb o min. 50 % do 12 mesiacov od GO-LIVENKIVS 2.1.1 Interoperabilné služby VS% nárast podaní (cieľ ≥ +50 %)Priorita 1, Špecifický cieľ 1.

Tabuľka 3 Ciele projektu

    1. Merateľné ukazovatele (KPI)

V nasledujúcej tabuľke sú merateľné ukazovatele projektu:

IDID/Názov cieľaNázov ukazovateľa (KPI)Popis ukazovateľaMerná jednotkaAS IS (aktuálne)TO BE (cieľové hodnoty)Spôsob ich merania a poznámky
KPI-01C1 Zaviesť centrálny právne záväzný Katalóg poplatkovStatus GO-LIVE KatalóguSpustenie Katalógu do produkcieÁno/NieNieÁnoSchválenie v MetaIS, GO-LIVE zápis
KPI-02C2 Integrovať IS PEP, IS MEP a MSP na nový Katalóg% integrovaných ISPodiel IS pripojených k API Katalógu%0 %100 %Reporting z monitoringu API pripojení
KPI-03C3 Jednotné používanie sadzieb pre e-podania% e-podaní využívajúcich KatalógPodiel e-podaní s určením poplatkov z Katalógu%~10 %100 %Reporting z MEP a ÚPVS integrácie
KPI-04C4 Eliminovať duálnosť ID služieb poskytovaných špecializovanými portálmi a na ÚPVS k tým istým poplatkovým úkonom s inými ID pri listinných podaniachPočet duálnych ID služiebZistené duálne ID služiebPočetCca 150 - 2000Porovnávacie kontroly medzi IS
KPI-05C5 Zabezpečiť auditovateľnosť zmien% položiek s audit trailomPoložky so zaznamenanými zmenami (audit trail)%0 %100 %Auditný výstup systému
KPI-06C6 Skrátiť čas aktualizácie legislatívnych zmienPriemerný čas aktualizáciePriemerný počet dní od legislatívnej účinnosti do nasadeniadniDo 10 dní< 5 dníMonitorovanie verzií a release termínov
KPI-07C7 Zabezpečiť dostupnosť službySLA dostupnosť KatalóguMiera dostupnosti služby Katalógu%N/A (neexistuje)≥ 99,5 %SLA monitorovací systém GOV Cloud
KPI-08C8 Zvýšiť podiel e-podaní s online určením výšky% nárast e-podaní s online sadzbouRelatívne zvýšenie počtu e-podaní s použitím Katalógu%odhad ~20 %+50 % oproti AS ISŠtatistiky podaní cez MEP a ÚPVS

Tabuľka 4 Merateľné ukazovatele (KPI)

    1. Špecifikácia potrieb koncového používateľa

V nasledujúcej tabuľke sú uvedené základné skupiny budúcich užívateľov informačného systému, resp. výsledkov projektu rozvoja na koncových zariadeniach alebo v rámci elektronického vybavovania služieb:

Skupina používateľovPopis / charakteristika
Pracovníci verejnej správy (priehradky, MSP, PEP, súdne IS, obce, VÚC a pod.)Úradníci pracujúci s Modulom správy poplatkov (MSP), v systéme PEP alebo na súdoch – hlavne na úrovni okresných úradov, matričných úradov, súdov a klientských centier. Typicky stredná úroveň digitálnych zručností.
Občania a podnikatelia využívajúci e-službyKoncoví používatelia, ktorí realizujú elektronické podania cez ÚPVS/MEP (živnostníci, malé firmy, občania podávajúci žiadosti, povolenia, súdne návrhy). Veľmi široké spektrum vekové, vzdelanostné aj digitálne zručnosti.
Administrátori číselníkov / Gestori sadziebZamestnanci MF SR, MV SR a ďalších OVM (obce, VÚC a pod.) zodpovední za tvorbu a správu sadzieb poplatkov. Pokročilé digitálne zručnosti, vysoká znalosť legislatívy.
      1. Používateľské potreby a ciele

V nasledujúcej časti sú definované kľúčové potreby, ktoré budú projektom rozvoja docielené aj s jasne definovaním používateľským príbehom, tej ktorej skupiny:

Pracovníci VS (priehradky / MSP / PEP, špecializované portály napojené na KP)

Používateľský príbeh:

Ako úradník na priehradke chcem mať k dispozícii vždy aktuálnu verziu sadzieb a možnosť rýchlo zistiť, aký poplatok je platný pre konkrétne podanie, aby som občanovi mohol poskytnúť správnu informáciu a nevystavil mu nesprávny predpis na úhradu.

Kľúčové potreby:

  • jednoduchý výber správneho poplatku,
  • vizuálne zobrazenie aktuálnej sadzby,
  • upozornenie na zmeny sadzieb,
  • garancia právnej platnosti sadzby
  • práca vo vlastnom agendovom systéme
Občania a podnikatelia (verejnosť) - elektronická komunikácia cez UPVS

Používateľský príbeh:

Ako občan podávajúci žiadosť cez ÚPVS chcem, aby systém automaticky určil správny poplatok a aby som mal istotu, že platím presnú sumu, ktorú legislatíva vyžaduje.

Kľúčové potreby:

  • automatické určenie správneho poplatku,
  • zníženie chybovosti v platbách,
  • zníženie potreby fyzických návštev na úradoch.
  • platba v priebehu podania bez dodatočného vyčíslenia výšky poplatku
Administrátori sadzieb

Používateľský príbeh:

Ako pracovník MF SR alebo OVM chcem mať možnosť spravovať a verzionovať sadzby s evidenciou zmien a právnou účinnosťou, aby som mohol garantovať ich správnosť a súlad s legislatívou.

Kľúčové potreby:

  • verzionovanie údajov,
  • validácia sadzieb,
  • audit trail zmien,
  • notifikácia pre integrované IS.

Používateľský príbeh 2 (Elektronická komunikácia cez UPVS):

Ako občan zaujímajúci sa o riešenie svojej životnej situácie chcem vedieť, koľko ma riešenie bude stáť vrátane informácie, koľko stoja jednotlivé služby.

 

Kľúčové potreby:

  • intuitívna navigácia,
  • ponuka možností,
  • informatívne určenie výšky poplatku s rozdelením na položky.
      1. Zdôvodnenie, prečo nebol vykonaný používateľský prieskum

Vzhľadom na to, že projekt Katalóg poplatkov nepredstavuje klasickú elektronickú službu pre občana s verejným grafickým rozhraním (ako portálová služba), ale ide o centrálny ISVS a referenčný zdroj údajov, ktorého cieľom je slúžiť iným ISVS (napr. PEP, MEP, MSP, Kiosky, špecializované portály), používateľský prieskum v zmysle § 8 Vyhlášky č. 547/2021 Z.z. sa neuskutočnil.

Používateľské požiadavky boli identifikované na základe:

  • workshopov s kľúčovými OVM (MF SR, MV SR, MS SR, NASES),
  • spätných väzieb z prevádzky IS PEP a IS MEP,
  • reportovaných incidentov z prevádzky eKolok systému,
  • výstupov z revízie výdavkov (MF SR, 2023),
  • technických analýz a existujúcich požiadaviek OVM.

Toto nahrádza formálny zákaznícky prieskum.

Pre následný návrh rozhrania MSP/Kiosky bude v realizačnej fáze projektu vykonané užívateľské testovanie prototypov (v zmysle § 8 ods. 4 písm. c) Vyhlášky).

    1. Detailný opis obmedzení a predpokladov

V nasledujúcej tabuľke sú uvedené predpoklady (čo musí byť splnené, aby projekt mohol úspešne dosiahnuť cieľový stav architektúry) a obmedzenia (známe faktory, ktoré môžu komplikovať alebo obmedzovať plynulý priebeh projektu):

TypNázov / oblasťDetailný popis
PredpokladSchválenie legislatívnej úpravyPre zovšeobecnenie Katalógu poplatkov na univerzálne druhy platieb orgánom verejnej moci (t. z. nielen pre súčasné vymedzenie legislatívneho ukotveného „číselníka poplatkov“ pre správne a súdne poplatky) je potrebná úprava viacerých právnych predpisov (buď zákon o eGov alebo v legislatívnom zámere prezentovaný zákon o elektronickej verejnej správe a taktiež zákon o správnych poplatkoch a zákon o súdnych poplatkoch).
PredpokladDostupnosť cloud infraštruktúry (GOV Cloud)Dostupnosť kapacít vo vládnom cloude a podpora IaaS/PaaS pre cieľové nasadenie nového systému vrátane požadovaných SLA parametrov.
PredpokladSúčinnosť SP pri migrácii IS PEPSúhlas a súčinnosť Slovenskej pošty (ako prevádzkovateľa IS PEP) pri migrácii údajov, príprave integračných rozhraní a potrebných úpravách v IS PEP.
PredpokladSpolupráca gestorských OVMAktívna spolupráca gestorských OVM (napr. MF SR, MV SR, MS SR a iných) pri validácii, doplnení a priebežnej aktualizácii údajov v Katalógu poplatkov.
PredpokladFunkčné integračné rozhrania existujúcich ISDostupnosť a funkcionalita integračných rozhraní IS PEP, MEP, MSP a Kioskov pre ich pripojenie na nový Katalóg poplatkov.
PredpokladFinancovanie projektuZaistenie financovania projektu cez OP Slovensko, Plán obnovy alebo z iných zdrojov — vrátane rozpočtu na následnú prevádzku.
ObmedzenieČasová synchronizácia legislatívnych zmienLegislatívne termíny (napríklad účinnosť zákonov) nemusia byť v súlade s plánovaným harmonogramom vývoja a nasadenia IS, čo môže viesť k potrebe mimoriadnych releaseov.
ObmedzeniePotreba úprav v IS PEPTechnické a kapacitné obmedzenia na strane IS PEP — nevyhnutné úpravy môžu byť obmedzené alebo spomalené zo strany SP.
ObmedzenieKapacitné obmedzenia integrátorov a správcovObmedzené personálne kapacity na strane správcu IS PEP, MEP a ďalších IS môžu ovplyvniť rýchlosť a kvalitu integrácie.
ObmedzenieZávislosť na dostupnosti integračných kapacít ÚPVS/MetaISDostupnosť integračných kapacít NASES a MetaIS (napríklad IAM služby, synchronizačné rozhrania, referenčné služby) môže ovplyvniť časovú realizáciu projektu.
    1. Vyhodnotenie rizík a závislostí

Z pohľadu najvýraznejších rizík a závislostí, ktoré ovplyvňujú realizáciu projektu boli identifikované nasledovné:

IDNázov rizikaPotenciálny dopadOpatrenie na zmiernenie / prevencia
1Nedostatočná legislatívna podpora pre nový Katalóg a procesy jeho správyNejasne definované kompetencie a povinností na správu a pravidelnú aktualizáciu Katalógu poplatkov, čo môže vyvolať nekonzistenciu v rámci poskytovania služieb občanom a podnikatešomPripraviť novelu zákona o eGovernmente alebo novú právnu úpravu zákona o elektronickej verejnej správe v koordinácii s MF SR, ÚV SR a gestormi pred spustením projektu ako aj aktualizácia dotknutých právnych predpisov, ktoré upravujú povinnosti pri stanovovaní a manažmente poplatkov iných subjektov (obce, VUC a pod.)
2Meškanie úprav IS PEPNeskorá migrácia na nový systém, pretrvanie paralelných číselníkov

Včasné uzavretie dohody so SP o harmonograme a rozsahu integrácií

Vytvorenie dočasnej funkcionality a integračného rozhrania v zmysle AA2

3Nedostatok kapacít na strane OVM na validáciu údajovSpomalenie plnenia Katalógu, nekonzistentné údaje v produkciiZapojiť odborný tím MF SR do prípravy údajov v dostatočnom predstihu (workshopy, pilotné testy)
4Zlyhanie synchronizácie sadzieb medzi Katalógom a IS PEPNesúlad údajov medzi systémami → reklamácie, nesprávne výšky poplatkovImplementovať kontrolu konzistentnosti, monitoring synchronizácie a reporting nezrovnalostí v zmysle AA2
5Odpor systémových integrátorov alebo doterajších dodávateľovSpomalenie alebo blokovanie integráciíAktívne zapojiť všetkých aktérov do prípravných fáz, schváliť integračnú stratégiu na úrovni MIRRI, zaviesť riešenie pre existujúce integrácie v zmysle AA2
6Nedostatok vyškoleného personálu na strane správcu/prevádzkovateľaPredĺženie adaptačného obdobia po nasadeníZabezpečiť plán školení v rámci projektu, pripraviť administrátorské návody

Tabuľka 5 Prehľad najzávažnejších rizík a závislostí

    1. Detailný opis rozpočtu projektu a jeho prínosov

V tejto časti sú uvedené informácie, ktoré sú detailne spracované v rámci prílohy CBA projektu

      1. Sumarizácia nákladov a prínosov

V nasledujúcej tabuľke sú uvedené všetky náklady na realizáciu projektu rozvoja v horizonte 10 rokov.

1751966545371-738.png

 Tabuľka 6 Sumarizácia nákladov a prínosov

Z pohľadu samotných nákladov na projekt sa jedná o nasledovné náklady:

Typ nákladuSuma
013 Softvér1 555 704 €
521 Mzdové náklady65 256 €
907 - Paušálna sadzba na nepriame výdavky podľa článku 54 písm. a) NSU              113 467 €
SPOLU1 734 427 €

V nasledujúcej tabuľke sú rozdelené tieto náklady po „moduloch“:

Označenia riadkovSuma interných pracSuma Externých pracSPOLU
Úpravy MEP5 530 €131 830 €137 359 €
Úpravy MSP7 732 €184 333 €192 065 €
Úpravy PEP6 631 €158 081 €164 712 €
Úpravy SW KIOSK5 530 €131 830 €137 359 €
Katalóg poplatkov34 304 €817 800 €852 104 €
Úpravy MASP5 530 €131 830 €137 359 €
        1. Prevádzkové náklady na Katalóg poplatkov

Prevádzkové náklady boli stanované ako 10% z investičných výdavkov na vybudovanie katalógu požiadaviek. Zároveň bolo stanovaných na rozvoj rovnako 10% z investičných výdavkov. Tieto hodnoty vychádzajú z priemerných hodnôt NASES z realizácie iných projektov. Keďže rozvoj má vplyv na samotnú hodnotu diela, boli prevádzkové náklady zvyšované v každom roku o 7% z hodnoty rozvojových nákladov. Rovnako boli kalkulované aj náklady na zabezpečenie L1 a L2 podpory z interných zdrojov.

        1. Prínosy projektu a vyhodnotenie CBA

Z pohľadu prínosov bol tento kalkulovaný ako ušetrená doba pri vybavovaní podaní a to práve úpravou FE pre jednotlivé dotknuté systémy. Kalkulácia je v samostatnom excelovskom súbore – Príloha č. 3 Projektového zámeru.

V nasledujúcej tabuľke je vyhodnotenie nákladov a prínosov :

 1751966577218-279.png

Z pohľadu kvalitatívneho hodnotenia má projekt nasledovné prínosy:

  • Zníženie administratívnej záťaže zamestnancov verejnej správy vďaka zjednotenému a automatizovanému spracovaniu poplatkov.
  • Skrátenie času venovanému na úhradu platby, napr. poplatku (resp. na splnenie poplatkovej povinnosti)
  • Zvýšenie úspešnosti a efektivity výberu poplatkov vďaka presnejšej evidencii a centrálnej kontrole úhrad.
  • Zníženie počtu chýb pri určovaní výšky poplatkov a obmedzenie duplicít alebo nesprávnych sadzieb.
  • Presnejšie plánovanie a kontrola rozpočtových príjmov cez jednotnú väzbu na rozpočtovú klasifikáciu.
  • Nižšie prevádzkové náklady na správu a kontrolu poplatkov vďaka digitalizácii a centralizácii údajov.
  • Zavedenie jednotného, centrálneho a transparentného zdroja údajov o všetkých poplatkoch a platbách vo verejnej správe.
  • Zvýšenie právnej istoty a predvídateľnosti pre občana aj podnikateľa — každý má jasnú a overiteľnú informáciu o povinnosti a výške poplatku.
  • Zlepšenie používateľskej skúsenosti cez možnosť online výpočtu, predpisu a úhrady poplatku bez zbytočných návštev úradu.
  • Podpora digitalizácie verejných služieb a životných situácií — priame prepojenie Katalógu poplatkov na elektronické podania a IS verejnej správy.
  • Škálovateľnosť riešenia na nové oblasti — možnosť jednoducho rozšíriť Katalóg o ďalšie typy poplatkov a úhrad bez zásadnej zmeny architektúry.
  • Vyššia kvalita a spoľahlivosť kontroly, auditu a zdieľania dát medzi orgánmi verejnej správy.
  • Flexibilná podpora legislatívnych zmien — centrálna evidencia umožní jednoduchšie a rýchlejšie aktualizovať sadzby alebo pravidlá.
      1. Zdroj financovania

Financovanie je navrhnuté z OP Slovensko – Priorita 1: Zvýšenie kvality eGovernment služieb a interoperability:

  • RSO1.2 Využívanie prínosov digitalizácie pre občanov, podniky, výskumné organizácie a orgány verejnej správy
  • 1.2.1 Podpora v oblasti informatizácie a digitálnej transformácie (B. Podpora v oblasti zvýšenia kvality poskytovaných verejných služieb
    1. Harmonogram projektu

V nasledujúcej tabuľke je definovaný predbežný harmonogram projektu

IDFÁZA/AKTIVITA

ZAČIATOK

(odhad termínu)

KONIEC

(odhad termínu)

POZNÁMKA
1.Prípravná fáza a Iniciačná fáza06/202508/2025 
2.Realizačná fáza09/202512/2026 
2aAnalýza a Dizajn01/202602/2026 
2bNákup infraštruktúrnych služieb, programových  a technických prostriedkov  Nepredpokladá sa dodávka HW
2cImplementácia a testovanie03/202610/2026 
2dNasadenie a PIP11/202612/2026 
3.Dokončovacia fáza01/202703/2027 
4.Podpora prevádzky (SLA)01/202712/2029 
  1.  
    1. Návrh organizačného zabezpečenia projektu (projektový tím)

V rámci projektu sa predpokladá so zriadením Riadiaci výbor (RV) realizátora projektu minimálne v nasledovnom zložení:

  • Predseda RV
  • Biznis vlastník
  • Zástupca prevádzky
  • Projektový manažér realizátora projektu (Objednávateľa) (PM)

Projektový tím realizátora projektu bude zložený z nasledovných rolí:

  • kľúčový používateľ,
  • IT analytik alebo biznis analytik,
  • IT architekt,
  • biznis vlastník
  • manažér kvality
  • manažér IT prevádzky
  • manažér kybernetickej a informačnej bezpečnosti

Pre návrh organizačného zabezpečenia vyplňte tabuľku zodpovedných osôb, ktoré budú participovať v projekte:

IDRola v projekteMeno a PriezviskoPracovné zaradenieOrg. útvar
1.kľúčový používateľ,TBDTBDTBD
2.IT analytik alebo biznis analytik,TBDTBDTBD
3.IT architekt,TBDTBDTBD
4.biznis vlastníkTBDTBDTBD
5.manažér kvalityTBDTBDTBD
6.manažér IT prevádzkyTBDTBDTBD
7.manažér kybernetickej a informačnej bezpečnostiTBDTBDTBD

Tabuľka 7 Projektový tím

  1. LEGISLATÍVA

Zákonom č. 238/2017 Z. z. ktorým sa mení a dopĺňa zákon č. 305/2013 Z. z. o elektronickej podobe výkonu pôsobnosti orgánov verejnej moci a o zmene a doplnení niektorých zákonov (zákon o e-Governmente) v znení neskorších predpisov a ktorým sa menia a dopĺňajú niektoré zákony sa okrem iného v zákone o správnych poplatkoch a v zákone o súdnych poplatkoch zaviedol číselník poplatkov ako štruktúrovaný zdroj sadzobníka správnych poplatkov a sadzobníka súdnych poplatkov. Predpokladá sa záväzné používanie číselníka poplatkov v iných IS, ktoré majú priamu alebo nepriamu väzbu na zabezpečenie úkonov a konaní správnych orgánov a súdov, orgánov štátnej správy súdov a prokuratúry (ďalej aj „OVM“) a tiež také, ktoré zabezpečujú (sprostredkovane) výber, evidenciu a zúčtovanie správnych a súdnych poplatkov – t. z. obsah a štruktúru číselníka poplatkov bude využívať napr. IS PEP, MSP, súdny manažment, MEP, špecializované portály, IS IOM, agendové systémy OVM. Je možné uvažovať v budúcnosti o využívaní číselníka poplatkov aj pre obce a VÚC pri ich originálnych kompetenciách. So zohľadnením tejto skutočnosti je potrebné pripravovať návrh číselníka poplatkov tak, aby zachytil všetky situácie pre jeho ďalšie využitie. Zavedenie číselníka poplatkov bude mať dopad aj na koncové platobné zariadenia systému eKolok (napr. kiosky, virtuálny kiosk, SW pokladňa a pod.).

Transformácia oboch sadzobníkov do podoby číselníka poplatkov je zložitá z hľadiska právnej relevantnosti, nakoľko položky sadzobníkov, vrátane ich vnútorného členenia v písmenách a bodoch majú aj ďalšiu väzbu na ustanovené výnimky zo všeobecných alebo špecifických pravidiel, ktoré sú uvedené v poznámkach alebo oslobodeniach priamo pod jednotlivými položkami sadzobníka alebo v paragrafovej časti príslušného právneho predpisu (napr. uplatnenie zľavy z poplatku pri elektronickom podaní, stanovenie výšky poplatku pri kasačnej sťažnosti a pod.). Okrem toho reálne poskytované služby OVM mnohokrát nezodpovedajú len jednej z položiek sadzobníka, ale sú kombináciou viacerých položiek alebo sa uplatňujú viaceré variácie položiek a poznámok, takže existuje väčší počet kombinácií ako je položiek, písmen a bodov v oboch sadzobníkoch. Pri súčasnej situácii, keď neexistuje jednotná väzba poskytovaných služieb na poplatky, nie je možné validovať sumu poplatku za službu, ktorá sa definuje v centrálnom systéme evidencie poplatkov (služba eKolok). V konečnom dôsledku, iba systémová príprava funkcionality a riadenia číselníka poplatkov dáva predpoklad právnej záväznosti a všeobecnej využiteľnosti v informačných systémoch verejnej správy s vylúčením možnej nesprávnej alebo nejednoznačnej aplikácie a maximalizácie pohodlia pre používateľov. Gestorom základného číselníka poplatkov je MF SR, ktoré OVM zabezpečuje funkcionalitu, sprístupnenie a správu spoločných položiek (napr. Položka 2 sadzobníka poplatkov). OVM ako spolugestori aktívne zabezpečujú napĺňanie obsahu s definovanými povinnými a voliteľnými splnomocneniami, poznámkami a účinnosťou zmien. OVM v úlohe gestora zabezpečuje zber aj na úseku podriadených orgánov (napr. FR SR pod MF SR).

    1. Vybrané ustanovenia týkajúce sa číselníka poplatkov v dotknutých právnych predpisoch:

Definícia číselníka poplatkov podľa § 15a ods. 4 Zákona o správnych poplatkoch:

„Ministerstvo financií Slovenskej republiky vedie číselník poplatkov orgánom verejnej moci ako štruktúrovanú verziu sadzobníka. Položkami číselníka poplatkov orgánom verejnej moci sú položky sadzobníka alebo ich nižšia úroveň členenia v písmenách, bodoch alebo s prihliadnutím na iné podmienky ich uplatňovania ustanovené v oslobodení, splnomocnení alebo poznámke položky tak, aby vzniklo toľko položiek číselníka poplatkov orgánom verejnej moci, koľko variácií sadzieb poplatku je prípustných vo všetkých položkách sadzobníka. Položky číselníka poplatkov orgánom verejnej moci môžu mať prepojenie na úroveň životnej situácie alebo služby verejnej správy, ak ich poskytovanie nemožno oddeliť alebo ak je ich poskytovanie na združenom základe vhodné vzhľadom na nastavenie životných situácií alebo služby verejnej správy na ústrednom portáli verejnej správy, špecializovanom portáli alebo integrovanom obslužnom mieste. Správne orgány sú povinné napĺňať do číselníka poplatkov orgánom verejnej moci údaje a udržiavať ho aktuálny, a to v rozsahu údajov, ktoré sa týkajú ich vlastnej pôsobnosti vo vzťahu ku konaniu alebo úkonu, za ktoré sa poplatky platia.“

§ 19l ods. 3 Zákona o správnych poplatkoch, v nadväznosti na vyššie uvedené ustanovuje, že MF SR sprístupní funkcionality číselníka poplatkov orgánom verejnej moci podľa § 15a ods. 4 na účely jeho používania podľa tohto zákona najneskôr od 1.4.2018.

Podľa § 7 ods. 10 Zákona o správnych poplatkoch:

„Ak sa vo veci spoplatneného úkonu alebo konania komunikuje elektronicky prostredníctvom ústredného portálu verejnej správy, špecializovaného portálu alebo integrovaného obslužného miesta, správne orgány, okrem správnych orgánov podľa odsekov 4, 5, 7 a 8, umožnia poplatníkovi zaplatiť poplatok prostredníctvom prevádzkovateľa systému a na účely identifikácie poplatku používajú číselník poplatkov orgánom verejnej moci. Ak ide o poplatky za úkony vykonávané obcami alebo vyššími územnými celkami v rámci preneseného výkonu štátnej správy, správny orgán môže postupovať podľa prvej vety.“

Podľa § 18a ods. 1 písm. b) predmetného zákona prevádzkovateľ systému je povinný:

„zabezpečiť evidenciu platieb poplatkov a na účel identifikácie úkonu alebo konania používať hodnoty z číselníka poplatkov orgánom verejnej moci“.

Podľa § 15a ods. 4 Zákona o súdnych poplatkoch:

„Ministerstvo financií Slovenskej republiky vedie číselník poplatkov orgánom verejnej moci ako štruktúrovanú verziu sadzobníka. Položkami číselníka poplatkov orgánom verejnej moci sú položky sadzobníka alebo ich nižšia úroveň členenia v písmenách, bodoch alebo s prihliadnutím na iné podmienky ich uplatňovania ustanovené v oslobodení, splnomocnení alebo poznámke položky tak, aby vzniklo toľko položiek číselníka poplatkov orgánom verejnej moci, koľko variácií sadzieb poplatku je prípustných vo všetkých položkách sadzobníka poplatkov. Položky číselníka poplatkov orgánom verejnej moci môžu mať prepojenie na úroveň životnej situácie alebo služby verejnej správy, ak ich poskytovanie nemožno oddeliť, alebo ak je ich poskytovanie na združenom základe vhodné vzhľadom na nastavenie životných situácií alebo služby verejnej správy na ústrednom portáli verejnej správy, špecializovanom portáli alebo integrovanom obslužnom mieste. Súdy, orgány štátnej správy súdov a orgány prokuratúry sú povinné napĺňať do číselníka poplatkov orgánom verejnej moci údaje a udržiavať ho aktuálny, a to v rozsahu údajov, ktoré sa týkajú ich vlastnej pôsobnosti vo vzťahu ku konaniu alebo úkonu, za ktoré sa poplatky vyberajú.“

Podľa § 9 ods. 2 Zákona o súdnych poplatkoch:

„Poplatky možno platiť prostredníctvom jednotného kontaktného miesta, akreditovaného platiteľa, integrovaného obslužného miesta alebo prevádzkovateľa systému. Ak sa vo veci spoplatneného úkonu alebo konania komunikuje elektronicky prostredníctvom ústredného portálu verejnej správy, špecializovaného portálu alebo integrovaného obslužného miesta, súdy, orgány štátnej správy súdov a orgány prokuratúry, ktoré sú zapojené do centrálneho systému evidencie poplatkov, okrem § 9 ods. 10

  1. umožnia poplatníkovi zaplatiť poplatok prostredníctvom prevádzkovateľa systému a
  2. na účely identifikácie poplatku používajú číselník poplatkov orgánom verejnej moci.“

Podľa § 16a ods. 1 písm. b) predmetného zákona prevádzkovateľ systému je povinný:

zabezpečiť evidenciu platieb poplatkov a na účel identifikácie úkonu alebo konania používať hodnoty z číselníka poplatkov orgánom verejnej moci“.

§ 18i ods. 2 Zákona o súdnych poplatkoch, v nadväznosti na vyššie uvedené ustanovuje, že MF SR sprístupní funkcionality číselníka poplatkov orgánom verejnej moci podľa § 15a ods. 4 na účely jeho používania podľa tohto zákona najneskôr od 1.4.2018.

Podľa § 5 ods. 6 písm. b Zákona o e-Governmente:

„Správca ústredného portálu, správca špecializovaného portálu a správca informačného systému integrovaného obslužného miesta na účely elektronickej úradnej komunikácie zabezpečia sprístupnenie potrebných technických alebo programových prostriedkov na vykonanie platby správneho poplatku a súdneho poplatku prostredníctvom technického vybavenia právnickej osoby so 100-percentnou majetkovou účasťou štátu, ktoré slúži na platenie poplatkov podľa osobitného predpisu pre všetky orgány zapojené do centrálneho systému evidencie správnych poplatkov a súdnych poplatkov, a to tak, aby bolo možné platbu vykonať samostatne alebo spolu s podaním elektronického podania, a to aspoň platobnou kartou a prevodom z účtu v banke alebo v pobočke zahraničnej banky; ak ide o elektronickú úradnú komunikáciu vo veciach preneseného výkonu štátnej správy, správca špecializovaného portálu a správca informačného systému integrovaného obslužného miesta nie sú toto povinní zabezpečiť.„

V nadväznosti na vyššie uvedené ustanovenie, § 60f ods. 8 Zákona o e-Governmente určuje prechodné obdobie pre správcu špecializovaného portálu a správcu informačného systému integrovaného obslužného miesta:

„Správca špecializovaného portálu a správca informačného systému integrovaného obslužného miesta zabezpečia sprístupnenie podľa § 5 ods. 6 písm. b) najneskôr od 1. apríla 2018.“

    1. Návrh TO BE legislatívneho stavu

Súčasnú definíciu číselníka poplatkov podľa § 15a ods. 4 zákona o správnych poplatkoch a podľa § 15a ods. 4 zákona o súdnych poplatkoch je potrebné z týchto právnych predpisov vyňať a zabezpečiť jeho definíciu ako „katalóg poplatkov“ v nadradenom právnom predpise, ktorý by pôsobil univerzálne voči všetkým platbám, ktoré sa realizujú v prospech orgánov verejnej moci (dane, odvody, poplatky, pokuty, penále rôzneho druhu).

Ako vhodný nosný právny predpis sa javí byť Návrh nového zákona o elektronickej verejnej správe, ktorého legislatívny zámer bol schválený vládou SR dňa 18.12.2024 (https://rokovania.gov.sk/RVL/Material/30223/1). Na strane 22 vlastného materiálu v časti „úhrady orgánom verejnej moci“ je uvedené: „Pri tvorbe novej právnej úpravy je nevyhnutné zohľadniť aj riešenie identifikácie úhrady a algoritmizáciu výpočtu platby v prospech orgánov verejnej moci v širšom spektre platobných úkonov ako sú len správne poplatky a súdne poplatky.“.

Legislatívne znenie návrhu zákona je v štádiu legislatívnej prípravy. Uznesením vlády SR sa uložila úloha ministrovi investícií, regionálneho rozvoja a informatizácie predložiť legislatívny návrh na rokovanie vlády SR do 31.12.2025.

  1. ARCHITEKTÚRA RIEŠENIA PROJEKTU

Cieľom navrhovanej architektúry riešenia je zabezpečiť jednotné, modulárne a škálovateľné prostredie pre správu všetkých poplatkov a platieb vo verejnej správe. V cieľovom stave bude riešenie tvoriť prepojený ekosystém, ktorý podporí celý životný cyklus poplatku — od jeho definície a parametrizácie v Katalógu poplatkov, cez určenie výšky a predpis, až po evidenciu úhrady a reporting.

Architektúra riešenia bude ďalej rozpracovaná v troch vrstvách:

  • Biznis architektúra, ktorá popíše kľúčové procesy a zodpovednosti účastníkov,
  • Aplikačná architektúra, ktorá navrhne hlavné komponenty, ich funkcionalitu a integrácie,
  • Technická architektúra, ktorá špecifikuje infraštruktúru, dátové toky a bezpečnostné princípy.

Navrhovaný model umožní efektívne riadiť poplatky na úrovni štátu, samospráv aj špecializovaných orgánov, s dôrazom na jednotné údaje, interoperabilitu a legislatívnu súladnosť.

    1. Stanovenie alternatív architektúry riešenia

V nasledujúcej kapitole je popísaný výber alternatívy pre navrhované riešenie. Z pohľadu cieľov projektu sa definujú alternatívy na úrovni:

  • Biznisovej vrstvy
  • Aplikačnej vrstvy
  • Technologickej vrstvy
      1. Stanovenie alternatív v biznisovej vrstve architektúry

V nasledujúcej tabuľke sa nachádza popis jednotlivých alternatív. Z pohľadu existujúceho nastavenie procesov je veľmi podstatné povedať, že súčasný IS PEP ≠ katalóg poplatkov – je to systém evidencie a verifikácie úhrad, nie systém pre definovanie, správu a publikovanie poplatkov ako právne záväzného referenčného údaja.

Pre každú alternatívu projekt rozvoja znamená vytvorenie dodatočných funkcionalít, pričom sa jedná o nasledovné alternatívy:

file:///C:/Users/peter/AppData/Local/Temp/msohtmlclip1/01/clip_image004.png1751966610598-998.png

Jednotlivé alternatívy sú popísané v nasledovnej tabuľke:

AlternatívaPopis alternatívy
Alternatíva BA1 – Rozšírenie IS PEP

Alternatíva A znamená realizáciu číselníka poplatkov ako rozšírenie IS PEP. Nová funkcionalita sa implementuje ako rozšírenie existujúcej funkcionality. Takisto je potrebný vývoj GUI pre správu číselníka.

V súčasnosti má IS PEP implementovanú funkcionalitu číselníka poplatkov, ktorá je úzko previazaná s procesmi IS PEP a je vyladená na výkonnosť systému..

Alternatíva A využíva existujúcu infraštruktúru IS PEP, a preto si nevyžiada dodatočné náklady na softvérové licencie, ale vyžiada si rozšírenie diskovej kapacity. Riešenie je možné horizontálne škálovať v rámci existujúcej infraštruktúry IS PEP. Riešenie zároveň nekladie zvýšené nároky na bezpečnosť, keďže využíva bezpečnostné nastavenia a infraštruktúru IS PEP.

Alternatíva BA2 – Vybudovanie samostatného ISVS pre elektronické služby

Alternatíva BA2 predpokladá realizáciu požiadaviek číselníka poplatkov ako samostatný ISVS, pričom tento bude vybudovaný pre zabezpečenie realizácie elektronických podaní.

Funkcionalita PEP ostáva nemenná pre zabezpečenie poskytovania informácií o platbách pre KIOSKy, MASP, MSP, APONET a rezortné platformy resp. informačné systémy.

BA3 – Vybudovanie samostatného ISVS pre všetky služby

Alternatíva BA3 predpokladá realizáciu požiadaviek číselníka poplatkov ako samostatný ISVS, pričom tento bude vybudovaný pre zabezpečenie realizácie všetkých služieb, či už v elektronickom svete alebo „papierovom“.

Tento systém bude jednotným zdrojom pravdy v oblasti služieb a poplatkov, ktoré v ňom budú evidovanie.

        1. Návrh kritérií pre vyhodnotenie alternatív

Z pohľadu posúdenia alternatív boli definované nasledovné kritéria:

#KritériumKO?ZdôvodnenieVlastník
1Architektonická nezávislosť a interoperabilitaASchopnosť fungovať samostatne a prepájať sa so systémami na základe štandardovNASES, MIRRI
2Vybudovanie jednotného systému na správu poplatkovAVytvorenie jednotného systému na správu poplatkov vytvára priestor na centralizované riadenie a poskytovanie informácii pre zabezpečenie služieb verejnej správyMIRRI, MF SR, OVM
3Možnosť rozvoja a škálovateľnostiNRozšíriteľnosť na ďalšie agendy a funkcionality.MIRRI, NASES
4Bezpečnostnosť a auditovateľnosťAMožnosť sledovať a vyhodnocovať prístupy, logovať zmeny, kontrolovať roly a pod.NBÚ, NASES
5Minimalizácia vendor lock-inNNezávislosť od konkrétneho dodávateľa s dopytom na poskytnutie zdrojových kódov pre potreby rozvoja a prevádzkyMIRRI, NASES
7Zníženie prácnosti pri integrácií jednotlivých informačných systémovNJednoduchosť technického napojenia v prípade pribúdania nových ISVS, ktoré budú konzumovať údaje z katalóguNASES, OVM
9Transparentnosť a kontrola nad zmenami číselníkaASledovanie zmien a schvaľovania údajov.MF SR, MV SR, OVM
10Náklady na zmenu a rozvoj do budúcnaNEfektivita pri legislatívnych úpravách.MF SR, MIRRI
11Zabezpečenie kvality dát a dátového modeluAPresnosť, úplnosť a kontrola nad údajmi.NASES, OVM
12Časová náročnosť implementácieNRealistický odhad dodávky funkčného systému.NASES
13Možnosť verzie a časovej účinnosti položiek poplatkovAMožnosť správy viacnásobných verzií a ich platnosti.MF SR, OVM
        1. Vyhodnotenie jednotlivých kritérií vo väzbe na popisované alternatívy
KritériumAlternatívy body
BA1 – Rozšírenie IS PEPBA2 – Nový ISVS pre elektronické službyBA3 – Nový ISVS pre všetky služby
Architektonická nezávislosť a interoperabilitaNIEANOANO
Vybudovanie jednotného systému na správu poplatkovANONIEANO
Možnosť rozvoja a škálovateľnostiCIATOCNEANOANO
Bezpečnostnosť a auditovateľnosťANOANOANO
Minimalizácia vendor lock-inNIEANOANO
Zníženie prácnosti pri integrácií jednotlivých informačných systémovNIECIASTOCNEANO
Transparentnosť a kontrola nad zmenami číselníkaANONIEANO
Náklady na zmenu a rozvoj do budúcnaNIEANOANO
Zabezpečenie kvality dát a dátového modeluCIASTOCNECIASTOCNEANO
Časová náročnosť implementácieANOCIASTOCNECIASTOCNE
Možnosť verzie a časovej účinnosti položiek poplatkovANOANOANO
        1. Popis naplnenia kritérií a slovný popis zvolenej škály

V nasledujúcej tabuľke je základný prehľad naplnení kritérií identifikovanými alternatívami:

KritériumAlternatívaZdôvodnenie
Architektonická nezávislosť a interoperabilitaBA1 – Rozšírenie IS PEPIS PEP má uzavretú architektúru a zložité rozhrania, ktoré komplikujú interoperabilitu.
BA2 – Nový ISVS elektronické službyJedná sa o vybudovanie nového systému, ktorý bude budovaný práve v kontexte architektonickej nezávislosti a interoperability
BA3 – Nový ISVS všetky službyJedná sa o vybudovanie nového systému, ktorý bude budovaný práve v kontexte architektonickej nezávislosti a interoperability
Vybudovanie jednotného systému na správu poplatkovBA1 – Rozšírenie IS PEPVšetky poplatky budú evidované v jednom ISVS
BA2 – Nový ISVS elektronické službyPoplatky budú evidované vo viacerých ISVS
BA3 – Nový ISVS všetky službyVšetky poplatky budú evidované v jednom ISVS
Možnosť rozvoja a škálovateľnostiBA1 – Rozšírenie IS PEPOhraničený rast kvôli technickým a organizačným limitom existujúceho systému.
BA2 – Nový ISVS elektronické službyNeobmedzené možnosti rozvoja a škálovania podľa potrieb OVM a eGov.
BA3 – Nový ISVS všetky službyNeobmedzené možnosti rozvoja a škálovania podľa potrieb OVM a eGov.
Bezpečnostnosť a auditovateľnosťBA1 – Rozšírenie IS PEPVlastné bezpečnostné politiky, riadenie incidentov a plná auditovateľnosť.
BA2 – Nový ISVS elektronické službyVlastné bezpečnostné politiky, riadenie incidentov a plná auditovateľnosť.
BA3 – Nový ISVS všetky službyVlastné bezpečnostné politiky, riadenie incidentov a plná auditovateľnosť.
Minimalizácia vendor lock-inBA1 – Rozšírenie IS PEPZnačný vendor lock-in so Slovenskou poštou.
BA2 – Nový ISVS elektronické službyNavrhnutý od začiatku s dôrazom na otvorené štandardy a minimalizáciu vendor lock-in.
BA3 – Nový ISVS všetky službyNavrhnutý od začiatku s dôrazom na otvorené štandardy a minimalizáciu vendor lock-in.
Zníženie prácnosti pri integrácií jednotlivých informačných systémovBA1 – Rozšírenie IS PEPIntegrácie zložité a často nákladné kvôli previazanosti systému.
BA2 – Nový ISVS elektronické službyČiastočne pre systémy pripájané na IS KP, čo však neodstraňuje duplicitnú prevádzku číselníka a vytvára tak prípadné zvýšené náklady pre zmenách.
BA3 – Nový ISVS všetky službyOtvorené API, podporujúce štandardné integračné vzory pre verejnú správu.
Transparentnosť a kontrola nad zmenami číselníkaBA1 – Rozšírenie IS PEPZmeny riadené Slovenskou poštou, bez priamej správy OVM avšak transparentným systémom
BA2 – Nový ISVS elektronické službyZmeny sa dejú v dvoch systémoch, čo je z pohľadu manažovateľnosti a kontroly veľmi obmedzené riešenie
BA3 – Nový ISVS všetky službyPlnohodnotná rola spolugestora a verzionovanie zmien, audit trail.
Náklady na zmenu a rozvoj do budúcnaBA1 – Rozšírenie IS PEPNízke počiatočné náklady, ale vysoké prevádzkové pri rozvoji.
BA2 – Nový ISVS elektronické službyVyššie investičné náklady, nižšie náklady pri rozvoji v dlhodobom horizonte.
BA3 – Nový ISVS všetky službyVyššie investičné náklady, nižšie náklady pri rozvoji v dlhodobom horizonte.
Zabezpečenie kvality dát a dátového modeluBA1 – Rozšírenie IS PEPNeexistuje robustný dátový model ani dátová validácia.
BA2 – Nový ISVS elektronické službyDátový model riadený pravidlami, verzionovanie, validácia podľa legislatívy avšak údaje sú duplicitné v dvoch systémoch
BA3 – Nový ISVS všetky službyDátový model riadený pravidlami, verzionovanie, validácia podľa legislatívy.
Časová náročnosť implementácieBA1 – Rozšírenie IS PEPNajkratšia doba implementácie, využíva existujúci rámec.
BA2 – Nový ISVS elektronické službyNajdlhšia realizácia, ale s najväčším potenciálom z dlhodobého pohľadu.
BA3 – Nový ISVS všetky službyNajdlhšia realizácia, ale s najväčším potenciálom z dlhodobého pohľadu.
Možnosť verzie a časovej účinnosti položiekBA1 – Rozšírenie IS PEPBez natívnej podpory verzovania, komplikované avšak verzie sú uchovávané prostredníctvom verzií excelov
BA2 – Nový ISVS elektronické službyPodpora verzovania, časovej účinnosti, viacerých režimov paralelne.
BA3 – Nový ISVS všetky službyPodpora verzovania, časovej účinnosti, viacerých režimov paralelne.

Z hľadiska biznisového vyhodnotenia preferujeme variant BA3 a to vybudovanie samostatného ISVS riešenia pre všetky podania. Spôsob realizácie a zdieľania informácií je posúdený v rámci aplikačnej architektúry.

      1. Stanovenie alternatív v aplikačnej vrstve architektúry

V prípade aplikačnej architektúry máme alternatívu AA1, obsahujúcu iba povinné komponenty a alternatívu AA2 aj s pridaným preferovaným komponentom a funkcionalitou.

        1. AA1 – povinné komponenty

Táto alternatíva vybuduje iba povinné komponenty, ktoré zabezpečia:

  • Vznik verejne dostupných aplikačných rozhraní na určenie a podanie
  • autentifikované/autorizované a zabezpečené API pre záväzné určenie výšky poplatkov,
  • konzistentnosť a jednotnosť pre všetky integrované systémy,
  • jeden zdroj pravdy – katalóg poplatkov.

V prípade vybudovania iba povinných komponentov je potrebné:

  • Vykonať zmenu integrovaných systémov eKolok do spustenia projektu do ostrej prevádzky
  • Zmeniť konfiguráciu a napojenie už integrovaných rezortných systémov

Tieto vyvolané činnosti vnášajú nové riziká do projektu najmä z pohľadu dĺžky trvania projektu

        1. AA2 - povinné komponenty s pridaním preferovaného komponentu a funkcionality

Alternatíva AA2 pridáva integračné rozhranie a funkcionalitu pre konverziu tej časti registra poplatkov, ktorá sa týka správnych poplatkov do podoby, aká sa používa v IS PEP a následnú synchronizáciu tohto výstupu s číselníkom poplatkov, ktorý sa v súčasnosti používa v IS PEP. V prechodnom období, ktoré je determinované zmenou IS PEP a ostatných systémov služby eKolok tak budú  ponechané funkcionality služieb a integračné väzby eKolok (IS PEP, FO eKolok, MSP, integrácie na IS PEP). Na druhej strane to znamená veľmi presne vytvoriť konverzný mechanizmus z nového spôsobu vedenia katalógu do štruktúry IS PEP, pridanie kontrolných a bezpečnostných mechanizmov pre zabezpečenie konzistencie a správnosti údajov v IS PEP.

Z dôvodu zníženia rizika závislostí na externých systémoch pri budovaní a nasadzovaní riešenia odporúčame budovanie alternatívy AA2.

      1. Stanovenie alternatív v technologickej vrstve architektúry

V oblasti technologickej architektúry máme nasledujúce alternatívy:

  • TA1 – vybudovanie riešenia na dedikovaných zariadeniach vo vlastnej infraštruktúre
  • TA2 – vybudovanie riešenia výlučne na zariadeniach a infraštruktúre vládneho cloudu
  • TA3 – vybudovanie riešenia na infraštruktúre ÚPVS
  • TA4 – vybudovanie riešenia na infraštruktúre IS PEP

https://mirri.gov.sk/sekcie/informatizacia/egovernment/vladny-cloud/katalog-cloudovych-sluzieb/https://mirri.gov.sk/wp-content/uploads/2023/05/Metodicke_usmernenie-pre_klasifikaciu_ISVS.pdfhttps://mirri.gov.sk/sekcie/informatizacia/dokumenty/vladny-cloud/metodicke-usmernenia/Kritériá pre MKA sú:

  • TK01  - Zabezpečenie priamych integrácií na systémy eKolok existujúcimi prvkami
  • TK02 – Garancia potrebného výkonu
  • TK03  - Zníženie nákladov na prevádzku
  • TK04 – Bez potreby nových pripojení existujúcich integrovaných systémov
  • TK05 – Bez potreby pridania nových komunikačných a bezpečnostných prvkov
  • TK06 – Bez potreby zabezpečenia prístupového bodu pre verejnosť

Porovnanie alternatív je v nasledujúcej tabuľke:

Alternatíva/ KritériumTA1TA2TA3TA4
TK01Nie - je potrebné vybudovať nové prepojenia na systémy eKolokČiastočne - nie všetky lokality vládneho cloudu už majú prepojenia na systémy eKolokČiastočne  - v jednej z dvoch lokalít už existuje prepojenie na systémy eKolokÁno  - integrácie existujú
TK02Áno  - súčasťou dodávky musí byť aj HWMožno  - iba v prípade, že by vládny cloud dedikoval príslušné zariadenia (čo je však alternatíva TA1)Áno  - súčasťou dodávky musí byť aj HW, ktorý sa doplní do infraštruktúry ÚPVSÁno  - súčasťou dodávky musí byť aj HW, ktorý sa doplní do infraštruktúry ÚPVS
TK03Možno  - nie je možné garantovať dodržanie SW technológií dodávateľomMožno  - nie je možné garantovať dodržanie SW technológií dodávateľomÁno - zníženie nákladov na monitoring a logovanie zapojením do pomocných komponentov ÚPVSČiastočne  - zníženie nákladov na monitoring zapojením do pomocných komponentov IS PEP
TK04Nie - je potrebné vybudovať nové prepojeniaČiastočne  - niektoré integrované systémy už sú vo vládnom cloudeÁno - prepojenie systémov na ÚPVS už existuje aj v súčasnostiÁno - prepojenie systémov na IS PEP už existuje aj v súčasnosti
TK05Nie - súčasťou dodávky musí byť aj HW a SW pre komunikáciu a bezpečnosťÁno - vládny cloud má potrebné komunikačné prvky a prvky pre bezpečnosť

Áno - infraštruktúra ÚPVS má potrebné komunikačné prvky a prvky pre bezpečnosť

 

Áno - infraštruktúra IS PEP má potrebné komunikačné prvky a prvky pre bezpečnosť

 

TK06Nie - súčasťou dodávky musí byť aj HW a SW pre zabezpečenie siete pre prístup verejnosťÁno - vládny cloud má potrebné komunikačné prvky a prvky pre bezpečnosť

Áno - infraštruktúra ÚPVS má potrebné komunikačné prvky a prvky pre bezpečnosť

 

Nie – IS PEP nemá rozhranie pre prístup verejnosti
      

Na základe multikriteriálnej analýzy odporúčame alternatívu TA3 - Katalóg poplatkov umiestniť do infraštruktúry ÚPVS ako jeden z modulov ÚPVS.

    1. Biznis vrstva
      1. Popis súčasného stavu biznis architektúry

V súčasnosti je funkcionalita vedenia poplatkov a určenia poplatkov za poskytovanie služieb realizovaná tabuľkou číselníka poplatkov v IS PEP. Týka sa správnych poplatkov a správa tohto číselníka poplatkov ja riešená poskytovateľom služby eKolok, Slovenskou poštou výlučne manuálnym spôsobom. Ďalším súčasným aktérom je MF SR, ktoré spravuje excel súbor s poplatkami, ktoré definuje sadzobník v zmysle Zákona o súdnych poplatkoch a Zákona o správnych poplatkoch. Slovenská pošta spravuje ďalší excel súbor, ktorý obsahuje služby pre technické zariadenia s mapovaním na poplatky v zmysle excel súboru s poplatkami od MF SR. V prípade legislatívnej zmeny poplatkov MF SR zasiela aktuálnu verziu excel súboru poplatkov Slovenskej pošte. Slovenská pošta následne upraví šablónu a referenčné dáta v excel súbore služieb pre koncové zariadenia. Excel súbor služieb pre koncové zariadenia v tejto podobe zasiela jednotlivým OVM na vyplnenie. Každému OVM zašle verziu len s tou časťou, ktorá sa daného OVM týka. OVM vyplní služby pre technické zariadenia do excel súboru podľa pokynov Slovenskej pošty a vyplnený excel súbor zasiela späť Slovenskej pošte vopred dohodnutým spôsobom. Slovenská pošta manuálne konsoliduje získané verzie vyplneného excel súboru služieb od jednotlivých OVM a zlučuje ich do hlavného excel súboru služieb pre koncové zariadenia.

Iniciatíva na zmenu služieb pre technické zariadenia môže prísť aj priamo od OVM, a to aj v prípade, že sa nejedná o legislatívnu úpravu. OVM môže požiadať napríklad o zmenu zobrazovaného názvu služby alebo jej zaradenia v strome služieb na kiosku. V takom prípade Slovenská pošta po dohode s OVM upraví službu v excel súbore služieb pre technické zariadenia.

Do číselníka služieb vedeného v IS PEP sa služby pre technické zariadenia zadávajú manuálne prostredníctvom grafického používateľského rozhrania IS PEP.

        1. Správa číselníka služieb v IS PEP pre platobné zariadenia

Pri vytváraní novej služby absentuje možnosť navolenia poplatkov, z ktorých sa daná služba skladá. Je možné prehlásiť, že v aktuálnom stave v IS PEP neexistuje mapovanie služieb na poplatky. Všetky reporty a štatistiky je možné vygenerovať len na úrovni služieb. T. j. v jednej službe môže byť zahrnutých viacero zákonných poplatkov definovaných  sadzobníkom, avšak neexistuje fyzické prepojenie medzi službou a poplatkami daných Zákonom o správnych poplatkoch a Zákonom o súdnych poplatkoch, z ktorých sa táto služba skladá. Preto nie je možné reporty a štatistiky vygenerovať na úrovni zákonných poplatkov. Absentuje analýza poskytovania poplatkov – počet, spôsob ich poskytovania, parametre, ktoré sa najčastejšie uplatňujú pre daný poplatok (rôzne zníženia a zvýšenia sadzby, atď.).

Pri súčasnej situácii, keď neexistuje fyzické mapovanie služieb na poplatky, nie je možné validovať sumu za službu, ktorú úradník definuje v IS PEP. Služba sa môže skladať z viacerých poplatkov, pričom pre rôzne zníženia alebo zvýšenia sadzieb poplatkov sa vytvárajú samostatné služby. Určenie celkovej sumy za službu preto nie je triviálna záležitosť, naopak je náchylná na chyby, pokiaľ neexistuje žiadna validácia výslednej sumy za poplatky. Princíp číselníkov služieb a kategórií bol pôvodne navrhnutý pre kiosky. Odvtedy sústavne pribúdajú integrácie nových nehomogénnych systémov (agendové systémy, portálové riešenia, mobilné zariadenia), ktoré si pre funkčnú integráciu taktiež vyžadujú synchronizáciu a správu číselníka služieb. Reprezentáciu a funkcionalitu číselníka služieb je potrebné konsolidovať s cieľom zabezpečiť optimálne scenáre používania pre všetky typy integrovaných systémov.

Kvôli zjednodušeniu integrácie je potrebné znížiť počet služieb, ktoré sú často definované duplicitne a líšia sa len rôznymi typmi znížení alebo zvýšení sadzieb. V prípade, ak by sa evidovala väzba služieb na poplatky, bolo by možné parametrizovať poplatky a tým aj služby. Parametrizácia by viedla k zníženiu celkového počtu evidovaných služieb. Príkladom môže byť zníženie sadzby poplatku z dôvodu ŤZP, ktorá by sa definovala na úrovni služby a pri určení výslednej sumy za službu by sa zníženie sadzby poplatku aplikovalo len na poplatky, pre ktoré je toto relevantné.

Správu číselníkov je oprávnený vykonávať len prevádzkovateľ systému eKolok, ktorým je v súčasnosti Slovenská pošta. Prevádzkovateľ má plnú kontrolu nad číselníkmi služieb, je plne oprávnený služby ľubovoľne pridávať, nastavovať ich parametre, parametre ľubovoľne meniť v čase vrátane výšky sadzby. Jednotlivé úrady môžu upravovať položky číselníka prostredníctvom prevádzkovateľa systému eKolok, čo je neželaný stav, nakoľko nastáva záťaž na strane prevádzkovateľa systému. Pri pripájaní ďalších agendových systémov, by táto záťaž vzrástla na neúnosnú hranicu. Preto je nevyhnutné prácu s číselníkom poplatkov a číselníkom služieb optimalizovať.

Vytvorenie novej služby:

Na obrazovke pre manažment služieb si používateľ vyberie kategóriu (alebo podkategóriu), do ktorej si želá službu pridať. V prípade, že požadovaná kategória neexistuje, používateľ ju môže vytvoriť na novej obrazovke pre správu kategórií služieb. Po vytvorení novej kategórie sa vráti späť na pôvodnú obrazovku pre manažment služieb a vyberie možnosť pridať nový záznam. Používateľ do formulára vyplní všetky potrebné údaje a parametre.

Priradenie služby do šablóny:

Aby bolo možné novo vytvorenú službu používať na zariadeniach, je potrebné túto službu priradiť do šablóny. Šablóna určuje rozsah poskytovaných služieb daným zariadením. Používateľ si vyberie šablónu na obrazovke pre manažment šablón. Ďalej používateľ pridá do šablóny novo vytvorenú službu, alebo celú kategóriu. Nakoniec je ešte potrebné, aby používateľ vytvoril nový obraz šablóny. Obraz šablóny vyjadruje jej časovú platnosť. Bez vytvorenia nového obrazu s novou časovou platnosťou sa zariadenia používajúce danú šablónu nedozvedia, že do šablóny bola pridaná nová služba.

Priradenie šablóny ku koncovému zariadeniu:

Nakoniec je potrebné zabezpečiť, aby požadované zariadenie používalo šablónu, ktorá obsahuje novo vytvorenú službu. Používateľ si vyberie požadované zariadenie prostredníctvom  obrazovky  pre  manažment  zariadení.  Ak  požadované  zariadenie neexistuje, tak používateľ požadované zariadenie pridá do zoznamu vytvorením nového záznamu. Následne používateľ priradí požadovanému zariadeniu vybranú šablónu. Ak ide o existujúce zariadenie s nastavenou šablónou, ktorá bola práve upravená, je možné celý tento krok preskočiť.

Dátový model súčasného stavu je zobrazený na nasledujúcom obrázku.

1751966674383-945.png

Služby sú zaradené do stromu kategórií služieb. Služba má určený typ poplatku (správny alebo súdny). Služba má definovanú sadzbu a elektronickú sadzbu. V prípade intervalovej služby je definovaná minimálna a maximálna sadzba. Pri intervalovej službe sa elektronická sadzba nedefinuje. Každá intervalová služba môže byť poskytovaná s elektronickou zľavou. V takom prípade sa na hranice pôvodného intervalu aplikuje 50 % zľava, pričom výška tejto zľavy nesmie presiahnuť 70 €.

Každé koncové zariadenie má priradenú šablónu. Šablóna obsahuje jednotlivé služby alebo celé kategórie služieb. Šablóna má niekoľko časových verzií s definovaným začiatkom a

koncom účinnosti - obraz šablóny. Na základne šablóny zariadenia a jej aktuálneho obrazu sú poskytované služby na koncových zariadeniach.

Scenár vytvorenia novej služby v číselníku až po nastavenie možnosti jej používania na koncovom zariadení je netriviálny, vyžaduje si vysokú používateľskú znalosť systému IS PEP a metodickú znalosť. Scenár nie je používateľsky prívetivý, nakoľko používateľ vykonáva jednotlivé kroky na rôznych obrazovkách a potrebuje si pamätať všetky predchádzajúce kroky. Používateľ je nútený vypĺňať veľké množstvo údajov, ktoré nie sú potrebné alebo môžu byť generované automaticky. Používateľom vytvárané služby častokrát nemusia reflektovať zákonom definované poplatky. Neexistuje kontrola cien služieb. Chýba verzionovanie zmien služieb, ktoré je zabezpečené len pomocou obrazov šablón, avšak zistenie verzií pre konkrétnu službu je náročné.

Z pohľadu funkcionality na koncových zariadeniach biznis proces pri zmene služby funguje tak, že pri synchronizácii číselníkov zariadenia je v čase začiatku platnosti obrazu odoslaný nový obraz šablóny. Obraz šablóny obsahuje vždy všetky informácie o všetkých službách zahrnutých v šablóne. Pri systémoch, ktoré obsluhujú viacero agend a majú šablónu s veľkým počtom služieb, sa posiela obrovský objem dát. Objem dát sa znásobuje počtom obrazov vytvorených do budúcnosti a každý obraz obsahuje všetky služby bez ohľadu na to, či nastala zmena v službe alebo nie.

Pri pridávaní novej služby používateľ nastavuje dátum začiatku jej platnosti. Služba smie byť poskytovaná až od nastaveného dátumu. Ako opisuje scenár vyššie, nová služba musí byť pridaná do šablóny a následne je potrebné vygenerovať šablóne nový obraz. Každý obraz má vlastný dátum začiatku platnosti, od ktorého sú služby z obrazu poskytované na koncových zariadeniach. V prípade, že obraz má nastavený dátum platnosti skôr, ako začína platiť samotná služba, je možné túto službu používať na zariadeniach od dátumu platnosti obrazu. Výsledkom je, že služby, ktoré v danom čase ešte nemajú byť poskytované sú na koncových zariadeniach dostupné, je možné pridávať ich na PnÚ alebo predávať eKolky s takýmito službami.

        1. Agendy

V aktuálnom stave neexistuje samostatný číselník agend. V strome služieb správca vytvára kategórie služieb, pričom najvyššia úroveň kategórií by mala reprezentovať agendy. Správca číselníka služieb ľubovoľným textom definuje kategórie a podkategórie služieb. Spravidla sú hlavnými kategóriami agendy, ktoré správca opäť zadefinuje ako voľný text. Správcom definované agendy nekorešpondujú so záväzným číselníkom agend, ktorý je určený Výnosom MF SR 478/2010 Z. z. o základnom číselníku úsekov verejnej správy a agend verejnej správy.

      1. Návrh riešenia v biznis vrstve architektúry

Biznis architektúra je na nasledujúcom obrázku:

1751966694066-832.png

Aktérmi z pohľadu biznis architektúry sú:

Verejnosť - konzument eGovernment služieb, ktorý v prípade ich spoplatnenia zisťuje výšku poplatkov a prostredníctvom na to určených systémov a zariadení za tieto služby platí

OVM - orgán verejnej moci, ktorý zodpovedá za správnosť výšky poplatkov za jednotlivé služby, ktoré poskytuje, vrátane určenia parametrov a spôsobu výpočtu/určenia výšky poplatku na základe týchto parametrov. V špecifickom postavení pre správne poplatky vystupuje MF SR, ktoré je gestorom zákona o správnych poplatkoch a garantuje správnosť pre tie služby, za ktoré sa platia správne poplatky.

Úradník - určuje výšku poplatkov na priehradke úradu, môže vytvoriť príkaz na úhradu (platobný predpis) a následne môže umožniť platbu cez POS terminál na priehradke. Ku katalógu poplatkov pristupuje sprostredkovane prostredníctvom na to určeného rozhrania a systému (v súčasnosti MSP resp. OEK).

MIRRI/NASES - zabezpečuje správu a prevádzku katalógu poplatkov, pristupuje ku katalógu poplatkov prostredníctvom na to určeného administrátorského rozhrania alebo prostredníctvom pomocných komponentov (tieto môžu byť vlastné alebo zdieľané), ako napríklad monitoring, logovanie alebo analytické nástroje.

Bližší popis koncových služieb je v kapitole 5.4.3.

Bližší popis procesov je v kapitole 5.4.4.

      1. Prehľad koncových služieb – budúci stav (TO BE)

V rámci projektu budú vybudované koncové služby, ktoré sú uvedené v nasledujúcej tabuľke:

Kód KS

(z MetaIS)

Názov KSPoužívateľ KS (G2C/G2B/G2G/G2A)

Životná situácia

(+ kód z MetaIS)

Úroveň elektronizácie KS
ks_381556Určenie predbežnej hodnoty poplatku za službuG2C, G2B, G2AAllúroveň 4
 Záväzné určenie poplatku (ako súčasť iných koncových služieb)G2GAllúroveň 4
ks_381562Manažovanie poplatkovej položkyG2AAllúroveň 5

Tabuľka 11Prehľad koncových služieb - budúci stav (TO BE)

Koncová služba Určenie predbežnej hodnoty poplatku za službu je určená pre verejnosť bez obmedzenia prostredníctvom vlastného Portálu katalógu poplatkov. Na základe vyhľadaných služieb, agend, kompozitných služieb alebo životných situácií, voľby niektorých priradených parametrov, OVM ktoré majú služby poskytovať (najmä v prípade samospráv) a zadania ich hodnôt služba poskytne v interaktívnej podobe (na portáli) výsledný poplatok spolu s jeho rozdelením na jednotlivé služby.

Koncová služba Záväzné určenie poplatku je určená pre verejnosť a úradníkov iba prostredníctvom oprávnených integrovaných informačných systémov verejnej správy. Na základe zadaných služieb, agend, kompozitných služieb alebo životných situácií, hodnôt priradených parametrov, OVM ktoré majú služby poskytovať a zadania ich hodnôt služba poskytne v interaktívnej podobe (na portáli) výsledný poplatok spolu s jeho rozdelením na jednotlivé služby vo forme štandardnej autorizovanej správy.

Koncová služba Manažovanie poplatkovej položky je určená pre OVM, ktoré garantujú jednotlivé položky v registri Katalógu poplatkov. Koncová služba je poskytovaná prostredníctvom na to vytvorených formulárov, prístupných prostredníctvom ÚPVS a v prípade že ide o zmenu a deaktiváciu platieb za služby aj prostredníctvom portálu Katalógu poplatkov. V prípade hromadných zmien (napríklad plošné zvýšenie správnych poplatkov) bude táto služba realizovateľná prostredníctvom import toolu v administrátorskom rozhraní.

      1. Organizačné zmeny a Procesy dotknuté navrhovaným riešením

Riešenie pre OVM, ktoré majú spoplatnené služby, vedené v katalógu poplatkov zavádza novú rolu, gestor poplatkov. Vzhľadom k povahe vedených údajov a závislosti na legislatívnych procesoch je vyťaženosť tejto role veľmi nízka, priemerne v jednotkách človekohodín ročne.

Projekt zavádza nové procesy, ktoré sú uvedené na nasledujúcich obrázkoch:

1751966721274-839.png

 Proces informatívneho určenia poplatku pre verejnosť nevyžaduje administratívne zaťaženie na strane úradníkov.

1751966733190-908.png

 Proces záväzného určenia poplatku pre verejnosť nevyžaduje zvýšené administratívne zaťaženie na strane úradníkov.

1751966750791-310.png

 Proces pridávania nových spoplatnených služieb do katalógu znamená správne vyplnenie na to určeného formulára na ÚPVS, jeho autorizáciu a odoslanie. Výsledok je oznamovaný do eDesk schránky OVM.

1751966763267-201.png

 Proces zmien (zmena parametrov, pridanie OVM a podobne) spoplatnených služieb v katalógu môže byť spustený z portálu Katalógu poplatkov. Môže však byť iniciovaný aj priamo z ÚPVS, čo znamená správne vyplnenie na to určeného formulára na ÚPVS, jeho autorizáciu a odoslanie. Výsledok je oznamovaný do eDesk schránky OVM.

1751966773867-716.png

Obrázok 11

Proces pre import položiek je využívaný pre potrebu hromadného pridávania resp. hromadnej zmeny položiek (napríklad pri migrácii, celoplošnom zvýšení správnych poplatkov a podobne.

      1. Jazyková podpora lokalizácia

Vzhľadom k faktu, že katalóg poplatkov v časti indikatívne určenie ceny je určené pre občanov EÚ, je potrebné, aby rozhranie poskytovalo multijazyčnú podporu. Znamená to aj fakt, že jednotlivé popisné atribúty služieb, na ktoré sa viažu poplatky a parametrov, z ktorých sú odvodené výšky poplatkov (napr. ŤZP, sila motora, váha psa a podobne) mali pre potreby zobrazenia multijazyčný zápis pre rôzne jazyky.

    1. Aplikačná vrstva
      1. Popis súčasného stavu aplikačnej architektúry

V súčasnosti neexistuje komponent katalóg poplatkov. Zoznam poplatkov je vedený vo plochej (flat) tabuľke, ktorej každý riadok obsahuje práve jednu kombináciu služba, parameter, OVM, výška poplatku. Používanie tohto číselníka je v réžii systému IS PEP.

Synchronizácia číselníkov zabezpečuje aktualizáciu číselníkov agendových systémov na najnovšiu verziu, ktorú poskytuje IS PEP. Nižšie uvedené číselníky sú napĺňané cez GUI IS PEP. Agendový systém skontroluje aktuálnosť svojich verzií, čím od IS PEP získa čísla aktuálnych verzií. Ak existujú pre jednotlivé číselníky novšie verzie, tieto číselníky si aktualizuje.

Proces synchronizácie číselníkov:

  1. Volanie služby infra.deviceStateCheck
    1. Na vstupe služby sú verzie číselníkov, ktoré aktuálne používa agendový systém.
    2. IS PEP porovná verzie číselníkov z volania s aktuálnou verziou číselníkov evidovanou v IS PEP
    3. Na výstupe je aktuálna verzia číselníkov evidovaná v IS PEP.
  2. Porovnanie verzií číselníkov z odpovede volania a verzií číselníkov v agendovom systéme.
  3. Aktualizácia číselníkov na novšiu verziu z IS PEP. Vykonáva sa pre tie číselníky, ktoré majú v IS PEP evidovanú novšiu verziu.
    1. Volanie služby pre aktualizáciu príslušného číselníka
      1. Na vstupe služby je príslušné zariadenie, ktoré aktualizuje číselníky.
      2. Na výstupe je aktualizovaná verzia číselníkov.
      3. Agendový systém si číselník služieb prepíše aktualizovanými údajmi z odpovede volania služby.

Webové služby pre synchronizáciu jednotlivých číselníkov:

  • infra.listService - slúži na synchronizáciu služieb, ktoré poskytuje koncové zariadenie alebo agendový systém
  • infra.listParameter - slúži na synchronizáciu parametrov pre kiosky
  • infra.listOffice – slúži na synchronizáciu číselníka OVM za účelom referencovania poskytovateľa služby a príjemcu úhrady na PnÚ
      1. Návrh riešenia v aplikačnej vrstve architektúry

Na aplikačnej úrovni sú dve alternatívy:

AA1 – povinné komponenty

Táto alternatíva vybuduje iba povinné komponenty, ktoré zabezpečia:

  • Vznik verejne dostupných aplikačných rozhraní na určenie a podanie
  • autentifikované/autorizované a zabezpečené API pre záväzné určenie poplatkov,

konzistentnosť a jednotnosť pre všetky integrované systémy,

jeden zdroj pravdy – katalóg poplatkov.

V prípade vybudovania iba povinných komponentov je potrebné:

  • Vykonať zmenu integrovaných systémov eKolok do spustenia projektu do ostrej prevádzky
  • Zmeniť konfiguráciu a napojenie už integrovaných rezortných systémov

Tieto vyvolané činnosti vnášajú nové riziká do projektu najmä z pohľadu dĺžky trvania projektu

Aplikačná architektúra pre AA1 je na nasledujúcom obrázku:

file:///C:/Users/peter/AppData/Local/Temp/msohtmlclip1/01/clip_image012.png1751966794138-305.png

Komponenty a služby katalógu poplatku sú označené modrou farbou. Riešenie predpokladá využitie infraštruktúry Ústredného portálu verejnej správy (ÚPVS) a jeho jednotlivých komponentov, označených bordovou farbou. ÚPVS zabezpečuje autentifikáciu, autorizáciu a prostredníctvom doručovaných formulárov riadenie oprávnenosti zmien a pridávania jednotlivých položiek a parametrov.

Konzumentami služieb sú systémy služby eKolok, Modul elektronických platieb ÚPVS, rezortné portály a v budúcnosti Štátna pokladnica. Integráciu rezortných portálov predpokladáme prostredníctvom systému CAMP (API GW).

Jadrom systému Katalóg poplatkov je samotný register poplatkov. Je to perzistentná vrstva systému, v ktorej sú uložené všetky potrebné číselníky, objekty, ich atribúty a vzájomné závislosti a väzby. Zároveň prostredníctvom administrátorského rozhrania umožňuje povolené zmeny a hromadné importy a exporty dát (vrátane kontroly na správnosť týchto dát).

Aplikačná vrstva nad registrom má dva komponenty:

  • Komponent určenia poplatku
  • Komponent pre pridávanie nových spoplatnených služieb a/alebo parametrov služieb, zadávanie zmien v atribútoch objektov a deaktiváciu objektov

Komponent určenia výšky poplatku na základe vstupných informácií (číslo služby, parametre služby a OVM resp. lokalita pre poskytnutie služby určí výšku poplatku za službu. V prípade kompozitných služieb a životných situácií zároveň vráti rozpočítanie poplatku na jednotlivé poskytnuté služby a OVM. V prípade, že je potrebná zaručená informácia o výške poplatku a rozpočítaní na jednotlivé služby, výslednú správu opatrí elektronickou pečaťou.

Pre príjem požiadaviek na určenie výšky poplatku a zasielanie výsledkov má komponent určenia poplatku dve rozhrania, jedno voľne prístupné pre verejnosť, cez ktoré primárne komunikuje Web portál katalógu poplatkov a sprostredkováva informatívne určenie výšky a rozdelenia poplatku, druhé zabezpečené pre prístup autorizovanými systémami pre poskytnutie zaručenej informácie o výške poplatku a jeho rozdelení.

Pre externé systémy budú rozhrania prístupné prostredníctvom API GW (CAMP). Z dôvodu tesnej integrácie vybraných systémov predpokladáme aj priamu integráciu MEP ÚPVS a IS Štátnej pokladnice.

Priamou integráciou bude riešené aj prepojenie systémov služby eKolok,

V prípade AA2 všetky systémy služby eKolok budú mať priamu integráciu na rozhranie pre záväzné určenie výšky poplatku a budú musieť zmeniť svoje fungovanie (iná štruktúra zadávania požiadaviek na určenie výšky poplatku, autorizovaná odpoveď vyžadujúca overenie a podobne). V súčasnosti integrované rezortné systémy budú musieť takisto prejsť zmenou ako v štruktúre zadávania (volanie) služieb, tak aj zmenou integrácie z IS PEP na API GW.

API pre informatívné určenie by malo podporovať REST/JSON, API pre záväzné určenie by malo byť z dôvodu už existujúcich a plánovaných budúcich systémov pripravené tak, aby podporovalo ako REST/JSON, tak aj SOAP/XML.

Rozhrania pre priamu integráciu by mali byť synchrónne, rozhrania pre API GW a v prípade AA1 aj rozhranie pre IS PEP by mali pracovať v asynchrónnom režime.

Komponent pre pridávanie nových spoplatnených služieb a/alebo parametrov služieb, zadávanie zmien v atribútoch objektov a deaktiváciu objektov vykonáva nasledujúce činnosti:

  • Sťahuje podania z eDesk komunikačnej schránky/ foldra
  • Kontroluje správnosť podania
  • Kontroluje autorizáciu podania a súlad autorizujúceho s obsahom podania
  • Zabezpečuje v prípade akcií, podliehajúcich schváleniu, predloženie akcií na schválenie
  • Umožňuje prostredníctvom takýchto podaní
    • Vytvoriť záznam/položku/parameter v registri poplatkov
    • Zmeniť záznam/položku/parameter v registri poplatkov
    • Deaktivovať (zneplatniť) záznam/položku/parameter v registri poplatkov
  • Zasiela správy o úspešnosti/neúspešnosti do schránky OVM, iniciujúceho zmenu

Ďalším komponentom Katalógu poplatkov je Webový portál katalógu poplatkov, slúžiaci na vyhľadávanie informácií z registra poplatkov a informatívny určenie výšky poplatku za služby resp. životné situácie. Prostredníctvom webového rozhrania bude OVM tiež schopné začať proces zmeny položky v registri, proces je uvedený v samostatnom diagrame.

Súčasťou katalógu poplatkov sú aj pomocné komponenty, ktoré pre zjednodušenie nie sú uvedené na obrázkoch. Tieto zabezpečujú najmä nasledujúce činnosti:

  • Administrácia systému a riadenie oprávnení pre ňu
  • Monitoring
  • logovanie
  • Import/export
  • Zasielanie notifikácií
  • Ďalšie

AA2 - povinné komponenty rozšírené o preferovaný komponent

Alternatíva AA2 pridáva integračné rozhranie a funkcionalitu pre konverziu tej časti registra poplatkov, ktorá sa týka správnych poplatkov do podoby, aká sa používa v IS PEP a následnú synchronizáciu tohto výstupu s číselníkom poplatkov, ktorý sa v súčasnosti používa v IS PEP. V prechodnom období, ktoré je determinované zmenou IS PEP a ostatných systémov služby eKolok tak budú  ponechané funkcionality služieb a integračné väzby eKolok (IS PEP, FO eKolok, MSP, integrácie na IS PEP). Na druhej strane to znamená veľmi presne vytvoriť konverzný mechanizmus z nového spôsobu vedenia katalógu do štruktúry IS PEP, pridanie kontrolných a bezpečnostných mechanizmov pre zabezpečenie konzistencie a správnosti údajov v IS PEP.

Aplikačná architektúra riešenia AA2 je na nasledujúcom obrázku:

file:///C:/Users/peter/AppData/Local/Temp/msohtmlclip1/01/clip_image013.png1751966817000-857.png

Pridaná funkcionalita v Registri poplatkov prostredníctvom integračného rozhrania Zasielanie číselníka poplatkov  do IS PEP bude zasielať (IS PEP si bude synchronizovať) z registra poplatkov tabuľku správnych poplatkov v tvare, aký je využívaný aj v súčasnosti v IS PEP a všetky v súčasnosti zapojené systémy do služby eKolok (vrátane už integrovaných rezortných systémov) budú dočasne používať rozhrania IS PEP ako doteraz.

      1. Rozsah informačných systémov – budúci stav (TO BE)

V nasledujúcej tabuľke sú definované ISVS, ktoré budú projektom dotknuté:

Kód ISVS

(z MetaIS)

Názov ISVS

Modul ISVS

(zaškrtnite, ak ISVS je modulom)

Stav IS VSTyp IS VS

Kód nadradeného ISVS

(v prípade zaškrtnutého checkboxu pre modul ISVS)

isvs_15162Informačný systém Katalóg poplatkovPlánujem budovaťEkonomický a admin. chod inštitúcie 
 IS PEPPrevádzkovaný a plánujem rozvíjaťAgendový 
 IS MEPPrevádzkovaný a plánujem rozvíjaťAgendový 
 IS MSPPrevádzkovaný a plánujem rozvíjaťAgendový 

Tabuľka 12 Rozsah informačných systémov - budúci stav (TO BE)

      1. Využívanie nadrezortných a spoločných ISVS – AS IS

V súčasnosti neexistuje samostatný ISVS

Kód ISVS

(z MetaIS)

Názov ISVSSpoločné moduly podľa zákona č. 305/2013  e-Governmente
  Vyberte jednu z možností.
  Vyberte jednu z možností.
  Vyberte jednu z možností.

Tabuľka 13 Využívanie nadrezortných a spoločných ISVS – súčasný stav (AS IS)

      1. Prehľad plánovaných integrácií na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013 Z.z. o  e-Governmente – budúci stav (TO BE)

V nasledujúcej tabuľke sú uvedené integrácie na nadrezortné ISVS.

Kód ISVS

(z MetaIS)

Názov ISVSSpoločné moduly podľa zákona č. 305/2013  e-Governmente
isvs_15162Informačný systém Katalóg poplatkovModul elektronických schránok
isvs_15162Informačný systém Katalóg poplatkovAutentifikačný modul
isvs_15162Informačný systém Katalóg poplatkovModulu elektronických formulárov
isvs_15162Informačný systém Katalóg poplatkovModul elektronického doručovania
isvs_15162Informačný systém Katalóg poplatkovModul elektronických platieb
isvs_15162Informačný systém Katalóg poplatkovCentrálna API Manažment Platforma
  Vyberte jednu z možností.

Tabuľka 14 Prehľad plánovaných integrácií na spoločné moduly – budúci stav (TO BE)

      1. Prehľad plánovaných integrácií na iné ISVS  – budúci stav (TO BE)

Z pohľadu iných integrácií bude IS KP integrovaný nasledovné informačné systémy

Kód ISVS

(z MetaIS)

Názov ISVS

 

Kód integrovaného ISVS

(z MetaIS)

Názov integrovaného ISVS
 IS PEPisvs_15162Informačný systém Katalóg poplatkov
 IS ŠPisvs_15162Informačný systém Katalóg poplatkov
 Rezortné informačné systémy (cez CAMP)isvs_15162Informačný systém Katalóg poplatkov

Tabuľka 15 Prehľad plánovaných integrácií na iné ISVS  – budúci stav (TO BE)

      1. Aplikačné služby pre Koncové služby – budúci stav (TO BE)

V nasledujúcej tabuľke sú definované navrhované aplikačné služby

Kód AS

(z MetaIS)

Názov  AS

Realizuje ISVS

(kód ISVS, ktorý realizuje AS)

Aplikačná služba slúži KS

(kód KS z MetaIS)

as_67404Informatívne učenie výšky poplatkuisvs_15162ks_381556
as_67405Zaručené určenie výšky poplatku a rozdelenia poplatku na službyisvs_15162 
as_67406Pridanie položky/ parametraisvs_15162ks_381562
as_67407Zmena/ deaktivácia položkyisvs_15162ks_381562
as_67461Sprístupnenie číselníka poplatkovisvs_15162 
as_67538Konzumovanie služieb spoločných modulovIsvs_15162 

Tabuľka 16 Aplikačné služby pre Koncové služby – budúci stav (TO BE)

      1. Aplikačné služby na integráciu – budúci stav (TO BE)

V nasledujúcej tabuľke sú uvedené aplikačné služby na integráciu

AS

(Kód MetaIS)

 

Názov  AS

Realizuje ISVS

(kód ISVS, ktorý realizuje AS)

Poskytujúca alebo KonzumujúcaIntegrácia cez CAMPIntegrácia  IS tretích stránSaaS

Integrácia na AS poskytovateľa

(kód MetaIS)

as_67404Informatívne určenie výšky poplatkuisvs_15162PoskytovanáÁno/NieÁnoNie 
as_67405Zaručené určenie výšky poplatku a rozdelenia poplatku na službyisvs_15162PoskytovanáÁnoÁnoNie 
as_67461Sprístupnenie číselníka poplatkovisvs_15162PoskytovanáÁnoÁnoNie 

Tabuľka 17 Aplikačné služby na integráciu – budúci stav (TO BE)

    1. Dátová architektúra
      1. Logický dátový model

Logický dátový model vychádza z toho, ako a kým je definovaný poplatok.

Poplatok je určený zodpovedným OVM, službou, za ktorú sa poplatok vyberá, relevantných parametrov, na základe ktorých sa poplatok môže počítať (napríklad fyzická osoba, dôchodca, výkon motora, váha psa a podobne). Výška platieb za služby je spravidla ukotvená v príslušnej legislatíve (zákon, vyhláška, všeobecné záväzné nariadene - VZN a podobne), ktoré budú uvedené v rámci príslušných atribútov služby.

Zároveň môže byť poplatok za životnú situáciu (resp. kompozitnú službu), ktorá je sumárom služieb do kompozitnej služby zaradených. Kompozitné služby/životné situácie budú vedené ako samostatné objekty a zoznam služieb kompozitnej služby je súčasť objektu kompozitnej služby.

Rámcový návrh dátového modelu je na nasledujúcom obrázku:

1751966841542-131.png

https://managementmania.com/sk/zalohovanie-backuphttps://www.minv.sk/?np-optimalizacia-procesov-vo-verejnej-spraveÚdaje, uložené v katalógu poplatkov nebudú referencované žiadnym systémom. Nebudú preto sprístupňované iným IS.

Údaje, ktoré sú referenčné, budú synchronizované na zdrojové registre. Týka sa to napríklad identifikátora a základných atribútov OVM, služieb a podobne.

V požiadavke na určenie poplatku ako aj vo výsledku sa budú používať aj číselníkové hodnoty (enumerácie). Tie číselníky, ktoré budú unikátne pre systém Katalóg poplatkov, budú zverejňované v zmysle platnej legislatívy.

      1. Objekty evidencie

https://www.slov-lex.sk/ezbierky-fe/pravne-predpisy/SK/ZZ/2020/78/20240701https://mirri.gov.sk/sekcie/informatizacia/o-sekciach/centralna-datova-kancelaria/interoperabilita/https://mirri.gov.sk/sekcie/informatizacia/o-sekciach/centralna-datova-kancelaria/interoperabilita/Objekty evidencie sú v nasledujúcej tabuľke. Objekty evidencie slúžia nie sú zdrojové ani referenčné údaje a nebudú takto poskytované iným systémom.

ID OEObjekt evidencie - názovObjekt evidencie – popisReferencovateľný identifikátor URI dátového prvku
OE_1Spoplatnená službaObjekt spoplatnenej služby s atribútmi a väzbami potrebnými pre určenie/výpočet poplatku za službu „Nemá“
OE_2Životná situáciaObjekt spoplatnenej životnej situácie, obsahujúci okrem atribútov aj zoznam spoplatnených služieb v rámci životnej situácie„Nemá“
OE_3OVMObjekt orgánu verejnej moci, obsahujúci okrem atribútov aj vázby na služby a poplatky za ne„Nemá“

Tabuľka 18 Objekty evidencie

Vzhľadom k faktu, že jednotlivé objekty sú podpornou evidenciou, slúžiacou k samotnému určeniu resp. výpočtu poplatku za službu alebo životnú situáciu/kompozitnú službu, jednotlivé umiestnenie informácií (vzorce výpočtov, parametre viazané na službu a podobne) budú priradené k objektom až na základe zvoleného riešenia vo fáze Analýzy a návrhu.

Príkladom môže byť služba evidencia psa, kedy poplatok za evidenciu psa môže byť jednorazový, na základe váhy psa pre rôzne obce s rôznymi intervalmi váhy alebo na základe výšky psa v kohútiku, znovu pre rôzne obce s rôznymi intervalmi výšky. Zároveň sú možné parametre, určujúce zľavy, ako vycvičenosť psa, umiestnenie psa a podobne. To, ako budú naviazané poplatky, parametre a vzorce na službu a OVM nie je momentálme bez detailného návrhu riešenia možné určiť.

      1. Referenčné údaje

Projekt nebude evidovať údaje, ktoré by sa mohli stať referenčnými.

ID OE

Názov referenčného registra /objektu evidencie

(uvádzať OE z tabuľky v kap. 5.5.1)

Názov referenčného údaja (atribúty)Identifikácia subjektu, ku ktorému sa viaže referenčný údajZdrojový register a registrátor zdrojového registra
     
     
     

Tabuľka 19 Návrh na vyhlásenie a zmeny referenčných údajov

      1. Poskytovanie údajov z ISVS do IS CPDI – budúci stav (TO BE)

Projekt nebude do IS CPDI poskytovať údaje.

ID OENázov (poskytovaného) objektu evidencieKód ISVS poskytujúceho OENázov ISVS poskytujúceho OE
    
    
    

Tabuľka 20 Poskytovanie údajov z ISVS do IS CPDI – budúci stav (TO BE)

      1. Konzumovanie údajov z IS CPDI – budúci stav (TO BE)

Projekt bude konzumovať z IS CPDI objekty.

ID  OENázov (konzumovaného) objektu evidencieKód ISVS konzumujúceho OEKód zdrojového ISVS v MetaIS
OE_1Údaje o organizáciáchisvs_15162IS RPO
    
    

Tabuľka 21 Konzumovanie údajov z IS CPDI – budúci stav (TO BE)

      1. Identifikácia údajov a subjektov pre konzumovanie alebo poskytovanie údajov do/z CPDI (CSRÚ)
ID OE

Názov referenčného údaja /objektu evidencie

(uvádzať OE z tabuľky v kap. 5.5.1)

Konzumovanie alebo poskytovanie

Subjekt

(organizácia poskytovateľa-konzumenta)

Osobitný právny predpis pre poskytovanie / konzumovanie údajov
 OVMKonzumovanieŠÚSRZákon o RPO
  Vyberte jednu z možností.  
  Vyberte jednu z možností.  

Tabuľka 22 Identifikácia údajov pre konzumovanie alebo poskytovanie údajov do/z CPDI (CSRÚ)

      1. Kvalita a čistenie údajov
ID OE

Názov Objektu evidencie

(uvádzať OE z tabuľky v kap. 5.5.1)

Významnosť kvality

1 (malá) až 5 (veľmi významná)

Citlivosť kvality

1 (malá) až 5 (veľmi významná)

Priorita – poradie dôležitosti

(začnite číslovať od najdôležitejšieho)

 Spoplatnená služba551.
 Životná situácia553.
 OVM552.

Tabuľka 23 Zhodnotenie dátovej kvality objektov evidencie

V rámci projektu nebudú potrebné role uvedené v nasledujúcej tabuľke:

RolaČinnostiPozícia zodpovedná za danú činnosť (správca ISVS / dodávateľ)
Dátový kurátorEvidencia požiadaviek na dátovú kvalitu, monitoring a riadenie procesuDátový kurátor správcu IS
Data stewardČistenie a stotožňovanie voči referenčným údajomPracovník IT podpory
Databázový špecialistaAnalyzuje požiadavky na dáta, modeluje obsah procedúrDodávateľ
Dátový špecialista pre dátovú kvalituSpracovanie výstupov merania, interpretácie, zápis biznis pravidiel, hodnotiace správy z meraniaDátový špecialista pre dátovú kvalitu – nová interná pozícia v projekte
Garant poplatkovBiznis vlastník, schvaľovateľ vybraných zmienSprávca ISVS

Tabuľka 24 Personálne zabezpečenie a roly pri riadení dátovej kvality

      1. Otvorené údaje

Projekt nebude poskytovať otvorené údaje vo forme datasetov.

ID OE

Názov objektu evidencie / datasetu

(uvádzať OE z tabuľky v kap. 5.5.1)

 

Požadovaná interoperabilita

(3★ - 5★)

Periodicita publikovania

(týždenne, mesačne, polročne, ročne)

    
    
    
    

Tabuľka 25 Objekty evidencie, ktoré budú sprístupnené ako otvorené údaje

      1. Analytické údaje

Objekt nebude poskytovať objekty evidencie pre potreby analýz. Bude možné využívať systémové logy pre potreby štatistík záťaže, využívania a podobne.

OE IDNázov objektu evidencie pre analytické účelyZoznam atribútov objektu evidenciePopis a špecifiká objektu evidencie
    
    
    

Tabuľka 26 Objekty evidencie, ktoré budú projektom pripravené pre analytické účely

      1. Moje údaje

Evidencie neevidujú údaje ani o fyzických, ani o právnických osobách.

OE ID

Názov registra / objektu evidencie

(uvádzať OE z tabuľky v kap. 5.5.1)

Atribút objektu evidenciePopis a špecifiká objektu evidencie
    
    
    

Tabuľka 27 Objekty evidencie, ktoré spadajú do kategórie Mojich údajov

      1. Prehľad jednotlivých kategórií údajov
ID

Register / Objekt evidencie

(uvádzať OE z tabuľky v kap. 5.5.1)

Referenčné údajeMoje údajeOtvorené údajeAnalytické údaje
 Služby
 Životné situácie
 OVM

Tabuľka 28 Prehľad jednotlivých kategórií údajov

    1. Technologická architektúra
      1. Návrh riešenia technologickej architektúry

Na základe multikriteriálnej analýzy pre jednotlivé alternatívy technologickej architektúry predpokladáme budovanie Katalógu poplatkov v prostredí ÚPVS ako (z pohľadu technológie a infraštruktúry) ďalšieho modulu ÚPVS.

Riešenie by malo byť nasadené pre lepšiu správu, kompatibilitu s novobudovanými modulmi ÚPVS a prípadnú budúcu migráciu formou kontajnerov. Technologická architektúra je na nasledujúcom obrázku:

file:///C:/Users/peter/AppData/Local/Temp/msohtmlclip1/01/clip_image015.png1751966871882-533.png

  1.  
      1. Požiadavky na výkonnostné parametre, kapacitné požiadavky – budúci stav (TO BE)

V nasledujúcej tabuľke sú uvedené predpokladané výkonnostné a kapacitné požiadavky na systém:

ParameterJednotkyPredpokladaná hodnotaPoznámka
Počet interných používateľovPočet50Bude upresnené po zapojení jednotlivých subjektov
Počet súčasne pracujúcich interných používateľov v špičkovom zaťaženíPočet20Bude upresnené po zapojení jednotlivých subjektov
Počet externých používateľov (internet)Počet6000Počet OVM
Počet externých používateľov používajúcich systém v špičkovom zaťaženíPočet500 
Počet transakcií (podaní, požiadaviek) za minútu v špičkePočet/minúta90počet spotreby kolkov (rok 2023) / 250 pracovných dní / 8 hodín za deň / 60 minút * 3 zvýšenie počtu OVM
Objem údajov na transakciuObjem/transakcia10kB 
Objem existujúcich kmeňových dátObjem10MB 
    

Tabuľka 29 Požiadavky na výkonnostné parametre, kapacitné požiadavky – budúci stav (TO BE)

      1. Využívanie služieb z katalógu služieb vládneho cloudu

Na základe multikriteriálnej analýzy pre alternatívy technickej architektúry nepredpokladáme využívanie služieb vládneho cloudu.

    1. Bezpečnostná architektúra

Bezpečnostná architektúra je definovaná pre systémy UPVS.

  1. PREVÁDZKA A ÚDRŽBA VÝSTUPOV PROJEKTU

Nové riešenie bude súčasťou informačných systémov UPVS, preto sa na neho vzťahujú všetky prevádzkové predpisy a postupy pre UPVS.

    1. Požiadavky na ľudské zdroje potrebné pre zabezpečenie prevádzky

Nové riešenie predpokladá navýšenie počtu expertov, zabezpečujúcich chod nových vybudovaných komponentov riešenia. Požiadavky na expertov, zabezpečujúcich prevádzku ako aj spôsob ich zabezpečenia (interné zdroje, externé zdroje, dodávateľ služby) bude možné určiť až pri spustení projektu pre nové riešenie.

    1. Požiadavky na zdrojové kódy

Manažment zdrojových kódov nového riešenia bude v súlade s postupmi pre systémy UPVS.

  1. OPIS IMPLEMENTÁCIE PROJEKTU A PREBERANIA VÝSTUPOV PROJEKTU

Realizáčná fáza projektu bude v zmysle vyhlášky 401/2023 Z.z. pozostávať z uvedených etáp:

  • Analýza a dizajn,
  • Implementácia a testovanie,
  • Nasadenie a post implementačná podpora
IDPrehľad projektových výstupov
 Výstupy vytvárané PRIEBEŽNE počas celého projektu
M-01Plán etapy/Plán fázy
M-02Manažérske správy, plány, reporty, zoznamy, odporúčania a požiadavky:
 (1) Zoznam otvorených otázok
 (2) Zoznam funkčných zdrojových kódov
 (3) Zoznam licencií
 (4) Správa o stave projektu (Status report)
 (5) Požiadavka na zmenu (CR)
M-03Akceptačný protokol
M-06Evidencia e-Government komponentov v MetaIS, vrátane architektonických modelov*
 PRÍPRAVNÁ A INICIAČNÁ FÁZA
I-02Projektový zámer
I-01Ideový zámer
 Prístup k projektu
 Používateľský prieskum
I-04Katalóg požiadaviek
 REALIZAČNÁ FÁZA
R1ANALÝZA A DIZAJN
R-01Akceptačné kritériá
R1-1

Detailný návrh riešenia (DNR) 
(1) Zámer riešenia, analýza požiadaviek, používateľský prieskum a motivačná architektúra
(2) Popis postupu analýzy a návrhu riešenia
(3) Biznis architektúra*
a. Existujúca a cieľová biznis architektúra
b. Procesy podporované navrhovaným riešením
c. Vytvorenie informačnej architektúry a mapovanie používateľskej cesty
d. Prípady použitia (use case model)
(4) Dátová architektúra
(5) Aplikačná architektúra*
a. Existujúca a budúca aplikačná architektúra
b. Aplikačné komponenty a ich vzťah k biznis komponentom a funkčným požiadavkám
c. Integrácie – Komunikácia medzi komponentami (OpenAPI)
(6) Technologická architektúra*
a. Existujúca a budúca technologická architektúra
b. Technologické komponenty riešenia a ich vzťah k aplikačným komponentom
(7) Softvérové licencie a zdrojové kódy
(8) Požiadavky na úrovne služieb
(SLA) a výkonnosť
(9) Zabezpečenie dostupnosti, zálohovanie a obnova riešenia
(10 Bezpečnosť – riešenie požiadaviek na bezpečnosť
(11) Migrácia dát
(12) Harmonogram realizácie a nasadenia, závislosti
(13) Testovací protokol prototypu používateľského rozhrania

(14) Iniciálny grafický návrh

R1-2Plán a stratégia testovania
 (1) Testovacie prípady (UC/TC)
(2) Testovacie prostredia
(3) Testovacie dáta
(4) Defekt manažment, monitoring a reporting testov
R3IMPLEMENTÁCIA A TESTOVANIE
R3-1Vývoj, migrácia údajov a integrácia
R3-2Testovanie
  1. Testovanie prototypu používateľského rozhrania, aplikačného rozhrania a iniciálneho grafického návrhu
(2) Funkčné testovanie (FAT)
(3) Systémové a integračné testovanie (SIT)
(4) Záťažové a výkonnostné testovanie
(5) Bezpečnostné testovanie (SW/HW a kybernetická bezpečnosť)
(6) Používateľské testy funkčného používateľského rozhrania (UX)
(7) Používateľské akceptačné testovanie (UAT)
R3-3Školenia personálu
R3-4Dokumentácia
1) Aplikačná príručka, vrátane aktualizovanej dokumentácie architektúry v rozsahu podľa položiek 3 až 10 Detailného návrhu riešenia R1-1
(2) Integračná príručka
(3) Používateľská príručka (vo forme kontextovej príručky - z aplikácie, bude priamo dostupný kontextový návod prostredníctvom jedného kliku. Technológia bude určená v rámci realizácie zmenového konania pre ŽS6)
(4) Zdrojové kódy a licencie
(5) Inštalačná a konfiguračná príručka
(6) Prevádzkový opis a pokyny pre diagnostiku, servis a údržbu
(7) Pokyny na obnovu pri výpadku alebo havárii (Havarijný plán)
(8) Bezpečnostný projekt
(9) Údaje o monitorovaní úrovne poskytovaných služieb (SLA) aktív IT
R4NASADENIE a POSTIMPLEMENTAČNÁ PODPORA (PIP)
R4-1Nasadenie do produkčnej prevádzky (vyhodnotenie)
R4-2Akceptácia spustenia do produkčnej prevádzky (vyhodnotenie)
 DOKONČOVACIA FÁZA
M-02Manažérske správy, plány, reporty, zoznamy, odporúčania 
a požiadavky:
 Manažérske správy, plány, reporty, zoznamy, odporúčania a požiadavky:
 (1) Správa o dokončení projektu (etapy/fázy)
  1. ODKAZY

Projekt je popísaný v súlade s projektom rozvoja Prevádzka služby eKolok v rokoch 2024-2034

  1. PRÍLOHY

Príloha 1: Katalóg požiadaviek a CBA projektu

Príloha 2: Register rizík a závislostí

Príloha 3: Kalkulácia prínosov

  

Koniec dokumentu


 [UU1]Upravit motivaciu a rozsah projektu

 [UU2]Aby to bolo na celu verejnu spravu