Ak si prečítate zmluvu, v rámci požiadaviek a špecifikácie uvidíte, že licencia je na neobmedzený počet formulárov, podporuje multitennantnosť, je k dispozícii pre každé OVM, ktoré prejaví záujem.
T.j. nejde o 18 licencií tak ako sa to tu interpretuje ale, ide o OPT PER CORE t.j. zalicencovaných je 18 core.
Ahoj Lenka,
dakujem za reakciu! Samozrejme genezu poznam. Viem aj, ze sa v SKITe uz v marci robilo porovnavanie produktov + teraz sa cakalo na rozhodnutie NASES, ktorym smerom teda pojdeme. Ako som vyssie spominal, Adobe ako nastroj nespochybnujem, skor mi vadi, ze sa to vsetko deje tak trochu “poza bucky”.
Kazdopadne som rad, ze si sa rozhodla verejne zareagovat a verim, ze by sa to mohlo v NASESe do budcna stat standardom este pred podpisom podobnych zmluv.
Aj ked sa to mnohym nepaci, osobne som presvedceny, ze len transparentna a otvorena komunikacia moze zmenit tuto spolocnost. Ak to ocakavame od inych organizacii, musime ist sami prikladom.
1 Like
Mozno len mala poznamka:
Ako zamestnanca SKIT ma to velmi netrapi. Je to uplne mimo moje kompetencie a agendu, ktoru riesim (dizajn).
Ako clena tzv. IT komunity ma to vsak zaujima. Tak ako ma zaujima co sa deje okolo myta, NFC OP, soc. poist., podpisu klikom, chatbota pre Bytcu, …
2 Likes
De facto zložka mirri žiada s.d aby pre ňu získalo informácie od inej de facto zložky mirri ?
To už v akom Absurdistane žijem. To už nie je ani zábavné . Aj keby to bolo vo filme, bolo by to od mizerneho scenáristu.
Nič osobné , len celá tá situácia je …aj na slovenské pomery divná .
1 Like
a k tomu
Ja chcem, resp. za urcitych okolnosti by som chcel. 
Ale k veci:
Aj ten Adobe vyzera ako “posun vpred” po tom, ako sa tu dekady potkyname o eForm, ktory sice nie je nijako vynimocny ani skvely, ale aspon je strasne zlozity a drahy, a najma “náš, Slovenský”. Vid napr. Zdielanie definícii eFormulárov a realizácia transformácii
Lebo teda uz len konkretne “ten editor na tie formulare”, tak na to je dopyt napr. v samosprave roky resp. dekady. A kedze nie je, tak si mesta a obce obcas aj kadejako pokutne “kopiruju” hotove formulare a pri tom pripadne narazaju na to, ze ich aj obvinuju z piratstva, lebo “ktosi nam to sice spravil, aj sme mu zaplatili, ale tvrdia, ze maju copyright, cize vraj nemozeme kopirovat uz hotove”.
Ale mozno si zamienam “tie el. formulare” s “tymi el. formularmi”. Uvitam pripadne korekciu od veci znalejsich.
ale tomu, ak tomu dobre rozumiem, nezabrániš ani novým editorom. Aj to sa dá kopírovať.
Nemáme na toto tie vzorové zmluvy, ktoré hovoria, že štát má nakupovať de/licencie tak, aby to vedel minimálne v rámci štátu používať? Keď už teda nie úplne eupl.
Citát z Najčastejšie otázky a odpovede na webe MIRRI k téme elektronické formuláre:
“Zároveň platí, že ak určitý typ už vytvoreného formulára (napr. formulár všeobecného podania v správnom konaní) vyhovuje na účely podaní viacerým oblastiam ústrednej štátnej správy, nemusí každý ústredný orgán vytvárať osobitný formulár, ale môže na “svoje služby” registrovať už existujúci.”
1 Like
registraovať áno, upravovať nie ? Kto je vlastne žalujúci, alebo potenciálne žalujúci ? Štát asi nie… tak dodávateľ ? Už niekto niekoho žaloval ?
Pre obce je potrebné vymyslieť a štandardizovať (ak to už štnadardizované náhodou nie je) prácu s logami a obrázkami. Ak by sa na jednom template dali jednoduchgo vymeniť loga (napr. attachement/logo_organu.jpg), kde by stačilo v stiahnutom balíčku len narábať s jedným logom obce, VÚv, alebo štátnym znakom, tak by sa vyriešilo 80% súčasných ťažkostí. Neviem či niekedy niekto nejakú ulohu definoval takto …
Áno, celé toto je zo strany Nases vedené mimoriadne uzavreto. Je jasné, že v žiadnom prípade neide o “produkt pre projekt MÚPVS”. Súčasná partia v Nases zjavne v participácii nevidí žiadnu pridanú hodnotu.
O téme nových formulárov som zachytil 1 (slovom jednu) diskusiu na pracovnej skupine, tuším to boli Lepšie služby. Téma v žiadnom prípade nebola uzavretá, za mňa je to v rovine “dosť výhrad” ako tu píše @MilanK . Žiadne pokračovanie nebolo, aspoň nie s nami.
Zato teraz som v “novele zákona o ITVS”, ktorá nám bola zo strany Mirri prezentovaná “to sú tie zmeny ITVS čo sme už spolu prebrali” a ktorej MPK začalo 22.12. / končí najbližší pondelok, s úžasom našiel, že sa opäť mení aj zákon o eGov a just aj nejaké veci týkajúce sa el. formulárov. Keď som zisťoval o čo ide, na Mirri som dostal odpoveď “toto nám na poslednú chvíľu poslal Nases, aj nám je to divné”.
Krása! 
No pekne. Nechceš tam ísť robiť nejakého relationships koordinátora? Dosť by to asi pomohlo
nechýba koordinátor, ale skutočný digitálny leader s právomocami, toto čo tu @Lubor popisuje je úplny štandard …
A ministerka, ktorá ma na starosti ešte aj eurofondy a invetície, proste na tejto úrovni do toho nevidí.
Ani nejdem nikoho obviňovať z nekalých úmyslov. Prosto chýbajú kontrolné mechanizmy, chýbajú “enterprise repositories” odkiaľ vieš vyberať vzorové riešenia …
A tak často sa presadzujú veci, čo práve v čase keď sa to dalo, tak niekto bez kontroly pretlačil do legislatívy… Prosto lebo sa mu to zdalo dobré …
1 Like
Tak neviem kto chýba, ale napr. keď sa bavíme o formulároch, sú tu nejaké zásady, ktoré boli dlhodobo formované a následne dodržiavané.
Vo väzbe na zmeny, ktoré sú teraz navrhnuté, povedzme zásada “formulár má byť dobre použiteľný offline”, resp. “celé podanie môžem pripraviť offline” až po “keď pripravujem podanie, nemusím byť v ničom závislý na IT systémoch verejnej správy a v ničom im nemusím dôverovať”.
Návrh Nasesu “vizualizácia sa vytvára online, na ústrednom portáli” toto všetko ruší. Bez fungujúceho ÚPVS si podanie ani nepodpíšem. Pritom aký je na to dôvod? Nakoľko môžeme dôverovať ÚPVS a tomu že zvláda nápory a funguje presne vtedy, keď potrebujem?
Za mňa s týmto v žiadnom prípade nemôžem súhlasiť.
Osobne povazujem za jeden z klucovych problemov to, ze ako formular je vnimane podanie (eGovApplication) ale aj rozhodnutie (eGovDocument).
Oba tieto pripady maju vsak uplne iny ucel:
-
Elektronicke podanie - zber udajov v strukturovanej podobe, tak aby ich v idealnom pripade co najefektivnejsie spracoval agendovy system OVM.
-
Rozhodnutie - jasne a zrozumitelne informovat o vysledku podania, pripadne zaslaneho rozhodnutia.
Aj ked sa jedna o uplne odlisne potreby snazime sa na tvorbu pouzit jeden nastroj. Hladame raketoplan, ktory vo finale dokaze pilotovat par vyvolenych.
Ked sa vsak zamyslime nad tym co je potrebne pre tvorbu podania (formularu na zber udajov) zistime, ze ide viac-menej len o definiciu poli, ktore chcem vyzbierat (plus samozrejme nejake podmienkovanie). Napr. podla nasej analyzy 20 najcastejsie pouzivanych podani, je vyskladanych z 80 dookola sa opakujucich poli.
Preco by nam na toto nestacil nejaky jednoduchy nastroj, ktory dokaze pouzit ktokolvek? Vyriesilo by to mozno 80% beznych formularov(podani). Tych zvysnych 20% superkomplikovanych by sa riesilo “na mieru”. Co sa tyka vizualizacie ta je v tomto pripade nepodstatna:
- Vyplnaciu definuje ID-SK a pravidla tvorby formularov. Ciel je standardizacia zobrazenia
- Pdf nie je vacsinou potrebna, kedze je podanie aj tak strojovo spracovane
Riesenie navrhu rozhodnuti, je za mna ta komplikovanejsia cast. Na to by kludne mohlo sluzit prave Adobe alebo podobne nastroje, ktore dokazu automatizovane vytvarat pdfka.
Pouzitie jedneho nastroja na vsetko mi vsak pride dost obmedzujuce. Cim je nastroj komplexnejsi, tym zlozitejsi a menej zrozumitelny je jeho interface.
povedzme si tu KTO by sa na toto mal pýtať .-… a kto by na toto mal odpovedať.
Lebo ak to nie je digit. líder = minister … tak asi potom jeho štátní tajomníci pre informatizáciu … či ?
V korporáciách je vždy nejaký master (principal) architect, ktorý musí kľúčové rozhodnutia posvecovať a tie musia byť v súlade s platnými korporátnymi metodikami…
a ešte pridám jeden úplne odveci typ a to je Záznam o zaručenej konverzii … To nemá čo byť formulár, lebo je to IBA strojovo spracovávané vo vládnom datacentre. To má byť record v SQL databáze … Hlavne ak k nemu existuje ešte Offline dvojička, ktorá ma 95% údajov rovnakých (osvedčovacia doložka), čo je druhý formulár k tomu istému úkonu (ale tu to asi má zmysel, lebo toto sa zobrazuje a tlačí)… Samozrejme prvý nezmysel je, že k jednému úkony vznikajú 2 dátové štruktúry a každá žije paralelným vlastným životom. A dotiahnutím nezmyslu do dokonalosti je práve to použitie eForm štruktúry na niečo, čo malo ísť do postgresu a len duplikuje dáta z offline doložky …
Ak ešte niekto viete o “zneužití” myšlienky formulára sem s tým …
Áno. Elektronické úradné dokumenty (čoho časť sú rozhodnutia) v absolútnej väčšine prípadov nikto nepotrebuje strojovo spracovávať. (A tam kde potrebuje sú na to skoro vždy iné, efektívnejšie mechanizmy.) Stačí dokument vydať ako obyčajné (autorizované) PDF.
Presne preto sme to v poslednej novele zákona o eGov navrhli my - občianske združenie Slovensko.Digital (pozri Novela 305/2013 + 95/2019 - #9 by Lubor “§26 ods.7”). Proti tejto možnosti bol najmä Nases s tým, že keď rozhodnutie prechádza cez ÚPVS, tak tam chcú podľa dát/metadát rôzne spracovanie. Dopadlo to našťastie “dobre”, dnes už elektronický úradný dokument môže byť iba PDF, pozri §3 písm.k) z.305/2013. …čiže keď sa tu bavíme o elektronických formulároch, do budúcnosti ide najmä o podania.
1 Like
Pošli to sem prosím. Odhadujem, že sú to identifikačné údaje. Idenfiikácia FO/PO v rôznych postaveniach v rámci daného podania. Adresa, parcela, bankový účet. Z toho v podaní stačí, aby zostal identifikátor - ale nedá sa toho zbaviť úplne.
Náš (S.D) návrh je, aby “elektronický formulár”, bola iba schéma+vizualizácia(a čo k tomu treba)+vyplnené údaje XML. Nemusí to “v sebe” mať žiadne aktívne prvky, nápovedy, kontrolné súčty, ani doťahovanie údajov. Tieto v poslednej vete menované veci nech sa robia ako súčasť prípravy podania, ktorá je online a netreba ju nijako špeciálne regulovať. Skrátka je na to elektronická služba, kde je to nejako implementované, jednoduché veci bude stačiť checkbox+potvrdzovacie tlačítko, zložité veci v pohode vývoj na mieru, alebo hoci aj Adobe nástroj. Ale následne na konci prípravy podania to vygeneruje vyplnený elektronický formulár, ktorý vidím, autorizujem a odosielam.
Presne naopak: ja keď podpisujem podanie, tak podpisujem čo presne? Chcem vidieť čo podpisujem a chcem mať záruku že presne to čo som videl je podpísané. Nezaujíma ma čo je v nejakom XML, v tej chvíli ma nezaujíma ako som to naklikal. Pre prípad budúceho sporu chcem mať záruku, ktorá obstojí na súde, že podané bolo presne to, čo som podpísal. Preto je práve vizualizácia super dôležitá.
2 Likes
To vsak nic nemeni na tom, ze aj tie PDFka musi niekto, nejak zvizualizovat … toto bola od zaciatku jedna z klucovych poziadaviek NASESu na dizajner “formularov” - aby sa dali robit viac-menej drag & drop vizualizacie pdf (+ automatizovana doplnanie udajov).
Vnimam to tak, ze toto by mala byt prave ta “killer feature” Adobe. A ja len tvrdim, ze to co je najvhodnejsie na tvorbu rozhodnuti (pdf), nemusi byt najvhodnejsie na tvorbu podani. V NASESe sa vsak hladal jeden raketovy nastroj, ktory urobi vsetko.
Osobne sa vsak obavam, ze “learning curve” tak komplexneho nastroja bude pre niekoho kto chce vytvorit viac menej jednoduchy formular (napr. ehranica) tak dlha, ze to vo finale radsej necha tak ci tak na dodavatela (pokial teda nechcu priamo v NASESe robit vsetky formulare).
Suhlasim, len tvrdim, ze vizualizaciu zobrazenia “checkout” stranky nemusi ten co vytvara formular riesit. Toto by mal vyriesit konstruktor sprav/podani na zaklade jasne definovanych pravidiel ID-SK. Tak isto ako by tvorca vobec nemusel pri tvorbe podania riesit ako vyzera to samotne podanie - to riesi ID-SK. On ma riesit data, ktore potrebuje ziskat. Zvysok ma vyriesit konstruktor.
Ty ako clovek potrebujes vidiet prehladne co ides odoslat. Podobne ako mas v eshope sumar s produktom, dopravou, platbou, osbnymi udajmy, … . Napr. v pripade prepisu auta sme to zatial riesili takto:
Na toto nepotrebujeme aby niekto definoval vizualizaciu. Skor potrebujeme aby na MV povedali ake data potrebuju - udaje o vozidle, udaje o predavajucom, udaje o kupujucom, … ked povedia ake data chcu, pripadne definuju podmienky zobrazenia, kontrolne sucty, … my im formular vygenerujeme v standardizovanej ID-SK podobe.
týmto som si nie istý … .resp. nesúhlasím.
Povolilo sa len to, ze Rozhodnutie môže byť PDF PRÍLOHA k všeobecnému podaniu. Čo je zásadný rozdiel. Prečo, kua, to nemohol byť rovno PAdES ?
To je zase dosť nedorobene…
Riaditeľ strednej školy spraví rozhodnutie - a NASES to rodičovi zabalí do akéhosi všeobecného podania a prílohou bude NEPODPÍSANÉ PDF v podpísanej správe…
Odnes také rozhodnutie do Brna na univerzitu a uvidíš kam ťa s tým pošlú …
Podľa mňa praktické použitie malo byť nastavené tak, že kompletné, autorizované bude PDF (do PAdES) a toto mi už je jedno do čoho sa zabalí a kam sa pošle. Takéto PDF môže byť prílohou všobecného podania a toto podľa mňa nemusí byť podpísané vôbec. Stačí že je zo školy doručené rodičovi do schránky a on následné nakladá s autorizovaným PDF… Toto sa potom dá používať aj medzinárodne aj vnútroštátne.
3 Likes