pozrel som tie ID ZoNFP z excelu…problem je v tom, ze datum prijatia zadava pouzivatel manualne na zaklade prijatia ZoNFP bud do fyzickej podatelne alebo do elektronickej schranky - zadal som poziadavku na implementaciu kontroly
ten nesulad moze byt sposobeny aj tym, ze par ziadatelov vytlacilo, podpisalo a poslalo draft verziu ZoNFP a az nasledne urobili odoslanie z verenej do nevrejnej casti ITMS2014+
-> celkovo som rad, ze API vzniklo, lebo mozu vznikat taketo analyzy, “kontroly”!
Celkom pekny graf. Inak teraz ked uz mame data z ITMS v ekosysteme, nechcel by si taketo nieco vyklikat rovno u nas v https://bi.ekosystem.slovensko.digital/ ? Pristup zriadim ked chces.
Inak toto je bezne. Pamatam si kodera z registra uctovnych zavierok, co vravel, ze API na zmeny ich donutilo urobit trosku iny zivotny cyklus zaznamov a cele sa im to potom vlastne zlepsilo.
Ahoj, rad sa na to mrknem - 17/7 sa vratim z dovolenky. Ak sa ale dobre pamatam tak ASPIRO malo pre UVSR robit nejeke BI nad ITMS datami. To uz je hotove?
Nebol som a ani teraz nie som v tejto aktivite extra zapojeny…z pohladu ITMS2014+ je to pre nas len dalsi IS konzumujuci data a co nad nimi vysklada/vybuduje nam je jedno…prave preto sme robili aj OpenData API, aby sme sa nemuseli zapodievat s kazdou poziadavkou a s kazdym subjektom, ktory si nieco zmysli…
Co ja viem tak sa to nakoniec nerobilo vo forme nejakeho BI. Zaroven teraz vlastnik IS eDemokracie ponuka vyuzitie tohto IS, nakolko tam vraj je je nejaky modul na riadenie rizik a vraj to do urcitej miery splna poziadavky, ktore boli pozadovane v ramci aktivity, na ktorej sa podielalo Aspiro…
Neviem, co ten modul za 3,7 mil. EUR vsetko a presne robi.
Nazov Modulu Open ITMS som x-krat pripomienkoval, ze som zasadne proti, aby sa tak volal, nakolko bude dochadzat k zlej interpretaciii, spajaniu s projektom ITMS a pod. Jedine, co tento modul ma spolocen s ITMS je to, ze nejak spracuva, interpretuje data, ktore su poskytovane z ITMS.
A ci tento modul riesi aj riadenie rizik, co som spominal vyssie v reakcii na Tamasa Szokeho alebo, ci to je iny modul, tak to ja neviem…to vie vlastnik asi
V dohladnej dobe pribudnu na data.gov.sk aj datasety za programove obdobie 2007-2013, nech su info komplexnejsie a da sa vychadzat/porovnavat aj z v podstate “minulosti”
itms.projekty_vrealizacii_schvalenaZonfp - chyba vazba projektu na ZoNFP
Vramci vaseho BI som zatial nenasla moznost priameho zapisu queries v SQL a tak som docasne pouzila trial na spominany https://redash.io/
Zo skusenosti s inymi BI toolmi tipujem ze obdobne queries sa vo vasom BI daju ‘vyklikat’ pomocou custom fieldov, co mi pride pomerne pracne a vzhladom na robustnu strukturu schemy bez normalizacie mi pride praktickejsie pouzit vase BI nad preddefinovanymi ‘Views’ spracovavajucimi vase raw data do citatelnejsej podoby.
itms.zop_uhradene.typ nadobuda viac hodnot nez je popisane v xmind dokumentacii
TYP COUNT(zop_uhradene)
REFUNDACIA 391
PREDFINANCOVANIE 155
ZUCTOVANIE_PREDFINANCOVANIA 128
ZALOHA 175
ZUCTOVANIE_ZALOHY 298
TRANZA 14
ak zapocitam naraz typy ‘PREDFINANCOVANIE’ a ‘ZUCTOVANIE_PREDFINANCOVANIA’ vyjde mi na niektorych projektoch cerpanie az do 200% zazmluvnenej sumy projektu
ak chces zistit kolko penazi poskytlo RO/SO prijimatelovi na realizacie projektu, tak to je atribut “cerpanie RO” na intenzite projektu…ale vypocitas to nasledovne = zaloha + predfinancovanie + refundacia + tranza a pozeras sa na schvalene sumy
ak chces zistit kolko penazi bolo zo strany RO/SO a potom aj MF SR skontrolovanych a schvalenych z tych vyssie poskytnutych, tak to je atribut “cerpanie EU” na intenzite projektu…ale vypocitas to nasledovne = zuctovanie zaloh + zuctovanie predfinancovania + refundacia + tranza a pozeras sa na schvalene sumy
TRANZA je typ ZoP, ktorym sa poskytuju financne prostriedky iba v ramci projektov, cez ktore sa riesia Financne nastroje. Financne nastorje je specificka iniciativa a je to navratna pomoc, urcena pre sukromny sektor a ma sa poskytovat cez sprostredkovatelov (banky a pod.) Výzvy pre finančné nástroje | Partnerská dohoda
Predfinancovanie funguje tak, ze prijimatel posle RO/SO ZoP typu Predfinancovanie na urcitu vysku financnych prostriedkov, ktoru deklaruje konkretnymi zalohovymi fakturami. Tieto faktury RO/SO kontroluje a schvali ich opravnenu vysku. Cize RO/SO moze schvalit menej ako si prijimatel ziadal. V schvalenej vyske su potom tieto financne prostriedky uhradene prijimatelovi a toto je Datum uhrady Predfinancovania. Prijimatel ma povinnost potom tieto finacne prostriedky pouzit iba na vydavky/faktury, ktore mu boli schvalene v priradenom Predfinancovani. Priijimatel nemusi pouzit vsetky financne prostriedky, ale tie, ktore nepouzije musi vratit (toto bude pekne vidiet, ked sa spristupnia endpointy pre Nezrovanlosti a Pohladavky). Ked prijimatel zrealizuje uhrady vydavkov/faktur, tak posle na RO/SO ZoP typu Zuctovanie predfinancovania. RO/SO toto Zuctovanie predfinancovania opat kontroluje. Nasledne ho schvaluje. Nakolko tu uz nedochadza k uhrade financnych prostriedkov smerom k prijimatelovi, tak Datum uhrady zuctovania predfinancovania predstavuje datum, kedy MF SR ako posledny organ v celom retazci schvali ZoP typu Zuctovanie predfinancovania
K realnej uhrade financnych prostriedkov smerom k prijimatrelovi prichdza pri tychto ZoP:
zaloha
predfinancovanie
refundacia
tranza
Pri ZoP typu:
zuctovanie zalohy
zuctovanie predfinancovania
nedochadza k realnej uhrade fiancnych prostriedkov. Tu sa len schvaluje pouzitie financnych prostriedkov, ktore boli prijimatelovi poskytnute typom ZoP Zaloha alebo Predfinancovanie. Preto sa pre tieto typy ZoP do Datumu uhrady naplna datum, kedy boli schvalene v ramci tzv Suhrnnych ziadosti o platbu na urovni MF SR a teda tieto vydavky potom mozu byt vykazane smerom na EK, t.j. vyssie spominane Cerpanie EU.
@Ernest_Walzel niektore z atributov (vacsina) su optional, teda vo vysledku nemusia byt aj ked v example su. Treba pozriet model kde je poznacene ze atribut je optional
