Zákon o e-Gov - novela 2017

Zavedenie centrálnej podateľne vymyslelo ešte MF spolu s Nasesom, bolo to tak aj v návrhu zákona o dôveryhodných službách. Podateľne u všetkých OVM robia vlastne úplne tie isté funkcie, veď aj sú tuším dodávané 2 firmami. Keď je plán zavedenia zdieľaných komponentov (viď. NKIVS), tak neviem čím jednoduchším začať ako týmto. Keď budú robiť centrálne účtovníctvo (už je na to projekt), centrálny DMS (plánuje sa), tak sa im pozitívny case-study zíde.

Ku mandátnym certifikátom viď. aj diskusia tu Zákon o dôveryhodných službách / veľké zmeny v ZEP - #18 by Lubor

Čiže zrušme NKÚ? Nie. Z pohľadu konkrétneho úradu je dosť dôležité, na ktorom podúčte peniaze ležia.
Kontrola má zmysel už len tým, že niekto má za_úlohu pozerať u ostatných či/čo robia/nerobia, ako im to ide, vyhodnocovať to atď. A napr. aj také odmeny sa ťažšie schvaľujú pre tých čo sú zodpovední za porušenia zákona, ktoré našiel kontrolný orgán.

Nesúhlasím.

[quote]
Prepísať do štruktúry rozhodnutia z katastra, úradu práce, sociálnej poisťovne, … nemá význam. Všetko sú to v súčasnosti niekoľkostranové voľné texty, z ktorých vyrobiť štruktúru je zbytočná práca. [/quote]

Staré rozhodnutia sa samozrejme nekonvertujú. Pre nové je jedno v akom editore ten text píšeš, práve naopak, ak je to do šablóny, zmenšuje sa priestor na chyby. Veľká výhoda el. formulárov je, že sú ľahko strojovo spracovateľné. Jednak majú metadáta a v rámci štruktúry sú ľahko identifikovateľné a vytiahnuteľné samotné údaje. Zober si napr. list vlastníctva - to je úplne šablónový dokument, kde voľný text nie je žiadny.

Podpísať sa musí rovnako každý el. úradný dokument, bez ohľadu na formát.
Vizualizácia formulára sa v žiadnom prípade nestratí stiahnutím zo schránky.
Súhlasím že na prácu s el. formulárom je treba špeciálny softvér, ale vzhľadom na to že špecifickácia je otvorene dostupná a založená iba na otvorených štanradoch, verím že časom bude dostupných viacero jednoducho použiteľných aplikácií pre koncového používateľa, snáď aj ako FOSS.

Absolútne súhlasím. Formuláre slúžia aj na komunikáciu medzi úradmi (tam kde ešte úrady nedokážu komunikovať priamo dátovo). Rovnako dobre štruktúrovanú formu ocenia systémy pre subjekty (napr. firmy), ktoré spracúvajú množstvá dokumentov. V skutočnosti každý “dokument” je iba súbor dát čitateľný špecializovaným softvérom. Súhlasím že pracujme na tom, aby el.form. veci boli čo najľahšie čitateľné, t.j. na jednej strane dostupnosť softvéru, na druhej strane pracujme s tým formátom aby bol lepší.
Keď trocha popustím uzdu fantázii (ozaj iba trocha), môže napr. s každým el.form. byť automaticky pribalená vizualizačná transformácia automaticky spustiteľná vo www prehliadači. Dnes by toto nakódiť mal zvládnuť bežný absolvent VŠ informatika. Naopak ak to zostanú prezentačné textové dokumenty (napr. PDF), tak sa s tým bude ďalej pracovať veľmi ťažko.

Registrácia do eForm musí byť jednoduchá operácia, cez štandardné API (bez ohľadu na administratívny proces “na pozadí”). Vytvorenie šablóny el.form. musí byť jednoduchá vec, ktorú si zvládne úrad spraviť aj interne ak chce. Ak to tak nie je, pravdepodobne niekto zneužíva svoje postavenie na vendor lock-in.

1 Like

Ako chceš riešiť nevykonateľné ustanovenia zákona eGov? Napr 26 eGov? Začneš pokutou OVM? Potom pokutou PO a nakoniec pokutou užívateľom.

100 bodov!

Ja len pripomínam kauzu elektronická doručenka - pre občana, úradníka ktorý pracuje so systémom absolútne nepoužiteľný dátový objekt

K sankciám:
V odrážke boli uvedené KONTROLY a SANKCIE. Reagoval som na druhú časť. Kontrola musí byť, samozrejme. Ale sankcie medzi úradmi navzájom mi prídu ako veľa kriku pre nič, v konečnom dôsledku len skomplikujú distribúciu finančných prostriedkov. SLA podpisované medzi úradmi, dohody o integračných zámeroch, … našiel si niekde zmienku o sankciách v prípade nedodržiavania podmienok?

K úradným dokumentom:

Nesúhlasim. Prax je úlne odlišná. Rozhodnutia úradov sú niekedy veľkolepé epické diela. Žiaden náznak štruktúry. Podľa správneho konania má rozhodnutie obsahovať: výrok, odôvodnenie a poučenie o odvolaní (https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/1967/71/20160701#paragraf-47). Rozsah niekoľkých strán je v štruktúre vyššie uvedených 3 oblastí. Rozhodnutia sú plné sumarizácie získaných podkladov, citácií zákonov, revízií doterajšieho priebehu konaní, atď. A čo takto obrázky, vzorce, tabuľky, ktoré sú súčasťou úradných dokumentov (v súčasnosti sú v rámci textu, nie ako príloha)?

Vybral si absolútne nereprezentatívny príklad úradného dokumentu a absolútne reprezentatívny príklad na referenčný register/OpenData. LV je jedna zo základných entít, s ktorou kataster pracuje, ale celé konanie okolo, to je zasielanie podkladov (zo strany vkladateľa) a vytváranie stanovísk, správ a rozhodnutí, ktoré so štruktúrou LV nemajú nič spoločné (po formálnej a štruktúrovej stránke).

Ak si stiahneš prijatú správu/podpísaný formulár z eDesk do svojho počítača, skús ho následne otvoriť cez DViewer. Ak sa ti podarí zobraziť transformáciu formulára do akejkoľvek podoby (HTML, PDF, TXT-podpis), pošli návod.

Ak má úrad prostriedky na automatizované spracovávanie elektronických formulárov (išlo by o tisícky rôznych formulárov: počet záujmových úradov x počet rôznych písomností), určite má prostriedky na dátovú komunikáciu. Ak má prostriedky na dátovú komunikáciu, formuláre ako úradné dokumenty sú zbytočné. Ak úrad nemá prostriedky na dátovú komunikáciu, prijaté dokumenty spracováva manuálne, na čo mu stačí PDF a formuláre ako úradné dokumenty sú zbytočné.

Niečo podobné som už zaregistroval tu https://wiki.finance.gov.sk/pages/viewpage.action?pageId=13598857. Jedinú implementáciu tohto som stretol v prípade podpísania XML dokumentu cez CEP (tuším formát ASIC alebo XADES, už si nepamätám). Prečo to nie je aj v eDesku, mi je záhadou.

Ako som snažil naznačiť vyššie, cieľ by mal byť dátová komunikácia medzi úradmi, nie pracovať s PDF alebo s el. formulárom. 99% vydaných písomností štatnou správou nemá zmysel prerábať do formulára (lebo voľný text).

Registrácia je to najmenej. Ale ide o prípravu balíka: vytvoriť HTML transformáciu, vytvoriť trnasformáciu pre podpis, vytvoriť transformáciu na tlač (PDF), plus všetky ostatné povinné náležitosti spojené s vytvorením el. formulára. A nespomínam už požiadavky zo štandardov ISVS. Toto zvládne radový informatik na úrade? Koľko účtujú dodávatelia za dodanie formulárového riešenia (prepočítané na počet registrovaných formulárov)? Neuvažujme všeobecný dizajnér/nástroj (tuším NASES poskytuje) pre tvorbu jednoduchých formulárov.

2 Likes

Z mojej praxe zavadzania elektronizacie na ovm je najvacsi problem to, ze urady nevedia co potrebuju, su malo znale problematiky celej elektronizacie, nepoznaju obmedzenia ZEPu (KEP), nevedia kedy aky podpis pouzit, malokto tusi o potrebe doveryhodneho uloziska, zarucena konverzia je nadavka a nie o anynmizacii vyradenych elektronickych spisov ani nepoculi.
Navyse komunikacia s nasesom je vyslovene tazka, ja nechapem co ten urad robi… ak chcete riesit integracny zamer, tak nemaju ziaden normalny proces s formularmi ale musite im posielat word (.docx). Podporu a komunikaciu pre vsetkych riesia 2 ludia co ani nie su zamestnanci nasesu. Dodavatelia systemov maju este tazsi pristup k informaciam ja osobne na odpoved z nasesu cakam mesiace a problemy si musim riesit sam (ak sa niekto skusal naintegrovat na upvs z javy, tak vie o com hovorim).

Tomuto by pomohlo ak by vzniklo dake velke metodicke usmernenie ako riesit problemy s elektronickym obehom dokumentov. Ku klasickej registrature napriklad existuje.

Pre nas obcanov su tie statne nastoje … odpad, eid klient este dobre, ale preco musim instalovat dalsie 4 baliky aby som mohol podpisovat? preco nespravia jeden so vsetkym? DViewer je vysmech, polovicu rozhodnuti to ani neotvori (veci podpisane cez qsign).

Ja to beriem ako zlyhanie Nasesu, nie je normalne 4/5 zo OVM nevedeli co musia mat a ako sa k tomu dostat.

K eformu, ja som zastanca eformu ale budme realisti, povedat si teraz v 2017, ze v 2020 (alebo kedy konci opii) budu vsetky urady fungovat na eforme je taka ista pravdedobnost ako ta ked nam vraveli, ze dialnica z bratislavy do kosic bude v 2010…

Momentalne maju agendove systemy OVM pripavene sablony pre rozhodnutia, su to stovky word alebo podobnych sablon, integrovane na interne procesy a systemy. Vyvijalo sa to roky a stalo to strasne peniaze. Toto vsetko treba prerobit do xml. Ak by si mal formy definovat len tak informatik na urade, tak sa o tie integracie prijde a len sa pridava chybovost. Navyse eform dizajner sice existuje, aj generuje vizualizacie a schemu, ale je to asi najhorsi softver aky som za moj zivot a kariesu v it pouzi (vid Orbeon to ma jednoducho vyriesene). A to nehovorim o tom, ze vyplnac eformu je uzavrety system a tazko sa integruje do rieseni inych dodavatelov (napr. ciselniky alebo prilohy) - neda sa tam vytvorit formular ako danove priznanie alebo oznamenie pre verejne obstaravenie.

Rozumne riesenie by bolo napriklad vydavat rozhodnutia ako kombinaciu eform+pdf s jednym podpisom, kazdy ma co potrebuje - clovek ma pdf a system xml. Mat normalne prechodne obdobie kde sa moze vydavat iba pdf.

Presne. eGov zákon má riešiť hlavne krátkodobé transakcie - napr. doručovanie, krátkodobú konverziu dokumentov, vzájomnú rýchlu výmenu informácii medzi OVM

Díky, už tomu rozumiem…

Tiež si myslím, že tomuto legislatíva nebráni…

súhlas, politická otázka…ale zase, budú všetci prispôsobovať sa riešeniu centrálnej EP, ktorú navrhoval ditec…

Ľubor toto je na otvorenie procesnej analýzy všetkých predpisov, ktoré upravujú konania pred OVM a stanovujú podpisy osôb oprávnených konať v mene OVM …bude potrebné ich zmeniť (vypustiť podpis ako náležitosť rozhodnutia) a mandátny certifkát bude potom v eGov len ako možnosť využiteľná tam, kde podpis osoby je účelný a odôvodnený zákonom…

Áno, návrh bude obsahovať rozšírenie o možnosť FO/PO autorizovať aj úkonom autentifikovaného používateľa.
To je jedna časť, druhá je metodika podobne ako pri autentifikácii, čiže metodika rozvinie § 23 ods. 1 a určí úrovne možnej autorizácie pre FO/PO/OVM a kritéria ich výberu…

Áno, návrh bude obsahovať rozšírenie aj na FO

[quote=“Lubor, post:18, topic:2979”]
Umožniť použitie autentifikačných schém od externých poskytovateľov. Vzhľadom na to, že už eIDAS nám prikazuje akceptovať “cudzie” identifikačné/autentifikačné schémy, technické riešenie pre takýto otvorený systém musí byť implementované (a už do Nases aj robí). Súčasne sú jasné požiadavky na takéto schémy pre jednotlivé úrovne autentifikácie, viď. naše štandardy ISVS, alebo opäť aj ten eIDAS a súvisiace predpisy. S tým súvisia aj potrebné zmeny v ustanoveniach pre alternantívny autentifikátor.[/quote]
Úrovne autentifikácie sú stanovené výnosom, treba ich len spresniť a zároveň stanoviť kritéria pre výber jednotlivých úrovní…čiže zákon o ITVS…

Kde je naviazaný? konkrétne ustanovenie?

Čiže návrat k pôvodnému textu?
Modul úradnej komunikácie zabezpečuje prostredie pre elektronickú komunikáciu medzi agendovými systémami a inými informačnými systémami pri výkone verejnej moci elektronicky. Správcom modulu úradnej komunikácie je úrad vlády.

Myslíš centrálne miesto na odosielanie vstupov (podaní) alebo výstupov (rozhodnutí) konaní? Alebo ako?

Ja som za sankcie, ale ide o to, že formálne vidím väčší priestor na kontrolu skôr v zákone o ITVS, tu je to skôr o jednoduchej sankcii za porušenie povinnosti (mal pri VVM použiť … - nepoužil) …

§ 28 ods. 3:
Úrad vlády zabezpečuje prístup k elektronickým formulárom pre elektronické podanie a elektronickým formulárom pre elektronický úradný dokument v module elektronických formulárov v rozsahu podľa tohto zákona aj na základe zverejneného komunikačného rozhrania.

To by zákon nesmel byť písaný takto voľne a tým umožňoval spraviť riešenie tak, aby bola registrácia čo najkomplikovanejšia…

Takto to má väčší zmysel?:
(5) Ak zákon ukladá povinnosť predložiť orgánu verejnej moci na účely konania o právach, právom chránených záujmoch alebo povinnostiach dokumenty, údaje alebo preukázať skutočnosti, orgán verejnej moci je oprávnený takéto dokumenty, údaje alebo preukázanie skutočností požadovať od účastníkov konania, len ak
a) na tento účel nie je možné použiť hodnotu referenčného údaja a nie sú známe orgánu verejnej moci z jeho činnosti,
b) je to nevyhnutné pre bezpečnosť informačného systému, alebo
c) vznikne oprávnená pochybnosť o úplnosti hodnoty referenčného údaja alebo o tom, či zodpovedá skutočnosti, alebo ide o konanie o zápise, zmene alebo výmaze hodnoty referenčného údaja v referenčnom registri.

Keďže sú dokumenty ešte stále požadované vo veľkej miere, navrhujeme zahrnúť zmenu kanálu G2B/G2C na G2G aj vo vzťahu k zabezpečovaniu dokumentov, napr. aj ad hoc dopytom cez elektronické schránky OVM.

Alternatívne, sa celý odsek dá postaviť aj opačne, na pozitívnom vymedzení povinnosti pre OVM …
(5) Ak zákon ukladá povinnosť predložiť orgánu verejnej moci na účely konania o právach, právom chránených záujmoch alebo povinnostiach dokumenty, údaje alebo preukázať skutočnosti, je orgán verejnej moci na tento účel povinný

  • použiť dostupné hodnoty referenčných údajov alebo
  • si ich zabezpečiť vlastnou činnosťou.
    Orgán verejnej moci je oprávnený požadovať dokumenty, údaje alebo preukázanie skutočností od účastníkov konania, len - ak je to nevyhnutné pre bezpečnosť informačného systému, alebo
  • vznikne oprávnená pochybnosť o úplnosti hodnoty referenčného údaja alebo o tom, či zodpovedá skutočnosti, alebo ide o konanie o zápise, zmene alebo výmaze hodnoty referenčného údaja v referenčnom registri.

Existuje minimálne jeden pokus o realizáciu rozhodnutia ako elektronického formulára (https://formulare.slovensko.sk/_layouts/eFLCM/DetailVzoruEFormulara.aspx?vid=37870475.VystupnyDokument_dorVRFikcia.sk&vh=1&vl=1). Prikladám sem prázdnu HTML transformáciu:
form.1639.html (1.5 MB)

Síce formulár obsahuje veľké množstvo polí, celá vecná časť rozhodnutia je v jednom poli (vzhľadom na to, čo rozhodnutia a ostatné štnadardné písomností obsahujú, je takáto realizácia pochopiteľná). Ako a kto bude takýto formulár strojovo spracovávať? Podľa tohto vzoru sa zdá, že všetky výstupy daného úradu budú v jednom univerzálnom formulári. Má potom ustanovenie zákona zmysel, aby sa na toto mrhalo úsilím?

Samozrejme, že ustanovenie nemá zmysel, lebo to iste rozhodnutie hoci v PDF bude doručované cez dátovú schránku kde už je raz náhodené do formuláru. Človeka, ktorý prišiel s nápadom vnoriť formulár do formuláru vôbec nezaujímajú koneční “konzumenti” rozhodnutia. Zaujíma ho iba strojové spracovanie rozhodnutia. To, že rozhodnutie nie je určené stroju ale človeku je úplne parciálne.

Zaujimalo by má, kde sa autor myšlienky rozhodnutí vo forme elektronických formulárov inšpiroval?

Existuje ich viac, rozhodnutia sudov, dcom, atd.
To,že niektoré z nich vyzerajú zle, resp. implementátor si nedal námahu s poriadnou vizualizáciou nie chyba samotného formulára.

Tomuto nerozumiem, formular je formular, nie je potrebne do neho nieco vnarat, prave naopak, formular je mozne stiahnut si ako pdf. ziadne dalsie pdf nie je treba, to ze vysledok vyzera takto:Dokument.pdf (32.5 KB)
nie je problem formulara.
to ze na slovensko sk, je potrebne pre stiahnutie pdf kliknut na stiahnut, a pre html kliknut na Tlacit, nehovoriac o tom ze existuje druha akcia stiahnut, ktora stiahne xzep, ktory sa da sice otvorit DViewer, ale ten funguje nejako divne (neviem aku vizualizaciu pouziva) a vobec je potrebne asi poriadny viewer, ktory sa asociuje s xzep priponou a bude vediet normalne zobrazovat to co v sprave je (casto sa podpisuje textova transformacia, a teda sa tam aj zobrazuje, co je podla mna nepochopitelne pre obycajneho usera, ze zrazu nevidi ten pekne formatovany text)

ak by som to mal uzavriet, problem nie je vo formularoch ako takych, tie poskytuju dostatok moznosti aby to fungovalo poriadne, problem je v implementacii.

  • vizualizacie su odflaknute,
  • chyba nam normalny priehliadac formularov,
  • chyba nam poriadny designer na formulare (to co sa vyrobilo v ramci UPVS ako dizajner ma za nasledok sucasny stav - tj. mnozstvo formularov vyzera katastrofalne).
  • je potrebne UX redizajn schranky upvs
1 Like

Je potrebne hlavne vyriesit mobilne platformy (iOS/Android) a nativne aplikacie :smile:

Keď to je odfláknuté, prečo potom štát núti užívateľov tieto služby používať. Prečo nepenalizuje dodávateľov?

Preco nuti? Spekulujem, ze preto lebo nejako zacat musi, ked to nikto nepouziva, neexistuje tlak na produkt.
A preco nepenalizuje? Nema ako, specifikacie boli napisane, diela implementovane a otestovane, dielo akcpetovane a tym padom zmluvy boli splnene.
Ja viem, ze existuje akesi povedomie ze zli dodavatelia, avsak problem je hlbsi. Firmy su dobre, zle, lepsie, horsie. Stat si napr. na zaklade tohto nemoze vyberat (resp. iba teoreticky moze). VO je vacsinou o cene, ked nie je, kricia novinari. Potom je tu zadanie. Vacsinou odflaknute, resp. iba technologicke, tj. povedia budu tam formulare v zmysle zakona a vynosu. Potom ked je analyza hotova, kontroluju sa formalizmy: je podla zakona? a nekontroluje sa, je to dobre? da sa to pouzivat? tak sa to schvali a tak to ide.
Nuz ak robime sw pre komercneho zakaznika, vacsinou mame na strane zakaznika biznis ownera, produktove oddelenie atd., ktore vie co asi chce, resp. blbost do sveta nepusti. Videl niekto nieco take na strane statu? Ma ministerstvo produktove oddelenie? A ako potom chceme aby sa stat robil nejake IT sluzby, ktore su dobre?

2 Likes

Myslim ze vacsinou maju, ale ma to daleko od produktoveho oddelenia sukromnej spolocnosti. Pretoze cielom sukromnej spolocnosti je dosahovat zisk a ked je zisk naozaj dobry spolocnost da produktovemu timu (a marketingovemu timu atd.) velmi pekne odmeny. V statnej sprave je produktom sluzba, a aky ma stat primarny zisk ak sa sluzba poskytuje efektivne (elektronicky)? no predsa nizsie prijmy z poplatkov. A aky ma z toho uzitok uradnik, ktory sluzbu zeefektivnil, velke nic? To ze sa vybere viac dani, lebo dobre sluzby statu vedu k podpore podnikatelskeho prostredia atd, to toho statneho uradnika vobec netrapi, pretoze ci je sluzba dobra alebo zla jeho odmena je ta ista.

velmi smutne a cynicke…ale pravdive

1 Like

Ako mohli byt diela otestované, keď v produkcii sa ukazujú školácke chyby?