…linkovanie VO na vyzvu je nezmysel…VO realizuje konkretny subjekt (verejny obstaravatel) a vyzvu vyhlasuje a spravuje vyhlasovatel vyzvy, co je subjekt verejnej albo statnej spravy…ked sa robi kontrola VO, tak sa nerobi voci zadaniu vyzvy a pod., ale sa kontroluje procesna stranka VO a potom sa kontroluje obsahova stranka VO, ale voci konkretnym aktivitam projektu…
…VO vyhlasit verejny obstaravatel alebo dat na kontrolu na RO/SO moze subjekt aj ked este nie je ani vyzva vyhlasena…
…ako som uz pisal vyssie…VO a ZoNFP a Projekt su samostatne objekty…z metodickeho hladiska kontrola VO a kontrola ZoNFP, pripadne kontrola ZoP su samostatne procesy…zamestnanci RO/SO maju povinnost pri kontrole VO nalinkovat VO bud na:
ZoNFP (ak uz pocas kontroly VO existuje),
projekt (ak uz pocas kontroly VO existuje),
UD (ak vydavky, ktore su zaradene do predlozenej ZoP vyplyvaju z VO),
…rovnako linkovat vie aj ziadatel/prijimatel…pri predlozeni VO na kontrolu vie povedat, ktorej ZoNFP a projektu sa tyka…zaroven ked vytvara ZoP a vydavky ramci ZoP, tak tie tiez vie nalinkovat na kontretne VO…
…cize ludia zapojeni do implementacie eurofondov su zodpovedni za vytvaranie tychto vazieb, nakolko z metodickeho hladiska tu je roznych alternativnych scenarov…nasledne dalsi ludia kontroluju pracu ludi na RO/SO, cize ti co kontroluju su kontrolovani a teda pocitam s tym, ze aj datova kvalita by mala byt korektna
…keby UVO malo jasne definovane pravidla pre vyplnanie udajov a nejakym rozumnym sposobom by publikovali data, tak by sa dala robit krizova kontrola a cistit informacie…
…ak budu k dispozicii informacie o vratkach na DPH vo vhodnej strukture, tak by sa vedelo kontrolovat aj to, ci si nahodou subjekt ako platitel DPH a zaroven prijimatel nenechal z eurofondov preplatit DPH…
ked si pozeram cez API napr. projekt 1008 (“Informačný systém výskumu a vývoja – prístupy do databáz pre potreby výskumných inštitúcií”) tak v uctovneDoklady sa mi cez projektid=1008 ukazuju zvlastne a predpokladam aj s tymto projektom nesuvisiace polozky (napr nejaka dialnica zaplatena cez NDS).
Môže poskytovateľ doručovať žiadateľovi (obec) výzvu na doplnenie do elektronickej schránky, ktorá je mu zriadená ako orgánu verejnej moci a používať spôsob a počítať lehoty doručovania podľa zákona o eGov?
Neviem nájsť nikde “systémovo” upravený spôsob doručovania (zákon o ešif, systém riadenia), lebo príručky na úrovni výzvy mi moc systémove neprídu.
Zaviesť sme issue tracking hlavne z dôvodu, aby sa riešili problémy a konzultácie rýchlejšie, v budúcnosti sa zachovala kontinuita a nebolo potrebné komplikované hlásenie problémov cez nášho prevádzkovateľa (DataCentrum MFSR).
Súčasťou issue trackingu by mal byť aj info portál s knowledge base. Zavádzať info do portálu budeme postupne.
K dokumentácii API: Zodpovednosť za dokumentáciu bola rozdelená medzi zadávateľa a dodávateľa. Chceli by sme zlepšiť jej kvalitu. Hľadáme riešenie tak, aby sa doplnenie dokumentácie zrealizovalo čo najskôr.
Konečne sa nám po licenčných a bezpečnostných útrapách podarilo nastaviť issue tracking pre zadávanie chýb a konzultácie k téme OpenData ITMS2014+. Na komunikáciu je potrebné mať vytvorený účet. Postup registrácie je v priloženom dokumente: Vytvorenie účtu pre prístup do JIRA a Confluence.pdf (228.4 KB).
Po registrácii je k dispozícii samotný issue tracking (JIRA) + informačný portál s knowledge base (Confluence).
V issue trackingu bude možné zatiaľ zadať issue typy:
Fault - chyba v API alebo dátach
Service - bude k dispozícii servisná požiadavka typu konzultácia - akékoľvek otázky k fungovaniu API, štruktúre dáta a pod.
Ešte doplním k dokumentácii, aby to bolo jasnejšie (@peter_k ďakujem za upozornenie).
dokumentácia je v swaggeri čo je myslím v poriadku
čo je potrebné zlepšiť je informačná báza resp. rozšíriť popis atribútov
Od začiatku bola koncepcia zvolená tak, že jednak API a aj dokumentáciu budeme dopĺňať postupne.
Cieľ je doplniť čo najskôr popis najpoužívanejších atribútov v swaggeri, zakreslenie modelu a referencií medzi objektami.
kukol som prilozene pdf, v request detail by mal byt uvedeny projekt. Moze do confluence dostat pristup aj bezny smrtelnik, ktory nerobi ani na jednom z uvedenych projektov?
Stačí zažiadat o konto. Pre opendata máme k dispozícii pool licencií. Prístup je k dispozícii automaticky do JIRA a confluence. Externé konto sa zriaďuje aktuálne len pre ITMS2014+ opendata.
Voľný prístup bez konta nie je možný.
na PROD je uz verzia 9.5.16, cize mali by byt fixnute chyby:
oprava nazvu atributu aktivit v ramci schvalenych ZoNFP - hodnoty sa naplnali spravne, iba nazov atributu bol nie korektny,
oprava vazieb medzi ZoP, UD, projektom - napr. tento problem ZoP ID 721 ku projektu ID 54 ukazuje v API cez deklarovane vydavky na uctovne doklady IID 3381 a ID 3383. Uctovne doklady ID 3381 a ID 3383 ukazuju v ich detaile v API na projekt ID 207, co bola chyba,
do listu a detailu pohladavky bol doplneny atribut stav pohladavky,
oprava skutocnych meranych hodnot ukazovatela projektu - zobrazuje sa posledna merana hodnota s datumom merania,
má teraz prístup API nejaké oneskorenie oproti výsledkom vyhľadávania vo verejnej časti ITMS?
Vo výzve id=201 v prehľade cez ITMS - neschválené projekty, je vidieť projekty s dátumom zamietnutia 25.9.2017 a cez API mi ukazuje len s dátumom zamietnutia 11.9.2017.
Cez web aj cez swagger ich vidím všetky. Keď pristupujem k db cez SQL API Datahubu tak v ňom vidím len zamietnuté do 11.9.2017. Tie čo boli zamietnuté 25.9. sú bez informácie o zamietnutí.
