Napr. ZoP uhradene s itms_id 67, 1012.
Podla popisu procesu pre ZoP typu predfinancovanie by ‘schvaleneDeklarovaneVydavky’ mali obsahovat vsetky ZoP typu ‘PREDFINANCOVANIE’ a ‘ZUCTOVANIE_PREDFINANCOVANIA’ (a teda nielen uhradene ZoP).
Ak dane predfinancovanie a zuctovanie predfinancovania bolo schvalene/uhradene, tak ano, mali by mat struktury “schvaleneDeklarovaneVydavky”. Cize tieto struktury maju len ZoP, ktore su v endpointe zop/uhradene.
V endpointe zop/prijate alebo zop/zamietnute najdes len struktury “ziadaneDeklarovaneVydavky”.
Rozumiem uz. Example su generovane z API definicie aby sme vzdy boli 1:1 kod vs dokumentacia. Nie je to tak ze by sa v examploch vynechavali optional fieldy, ale je to bug v generatore swagger dokumentacie. Pozriem co sa s tym da robit. Dik za report.
(OT rypava otazka: Ako sa daju vlastne poriadne urobit ine ISVS, ked ich stret s realitou (zakaznikom = obcanom) nastane velakrat az po spusteni?)
@Ernest_Walzel obdobne teda chybaju ‘ziadaneDeklarovaneVydavky’ na zop/prijate alebo zop/zamietnute:
1 Like
Podla mna sa daju ak sa podari vyhnut chybam ako:
- megalomanske projekty, ktore idu do produkcie po niekolkych rokoch a potom sa zisti ze to nie je to co zakaznik chcel
- nizka anagazovanost zakaznika a nejasne zadanie
- kladenie dorazu na okrajove funkcionality namiesto realnych featur
- nelogicky postup uz od zaciatku projektu, kedy sa najskor nakupi HW, SW a pritom este nie je ani analyza (a vonkoncom nie architektura) a nemozem vediet dopredu povedat ci/kolko/aky budem potrebovat HW, ake SW komponenty a pod.
- technologie vyberane manazermi/ochodnikmi/lobistami miesto ludi co s nimi realne pracovali/budu pracovat
- pyramida dodavatelov a na spodku lacni ludia == slaba kvalita a nizka odbornost
- castokrat chybajuca architektura alebo jej nedodrziavanie
- chybajuce verziovanie projektu alebo neznalost VCS
2 Likes
Moje oči. Nie, toto sa mi sníva.
Nemyslel som tym ze by tie projekty nemali VCS, ale to ze vsetko sa tlaci do mastra a build znamena ze zoberem aktualny HEAD a prehlasim to za verziu. V lepsom pripade to aspon otaguju. Zober si co to potom znamena robit bugfix 
To zas zoberies aktualny HEAD mastra, fixnes bug a zavedies 10 dalsich.
1 Like
keby som teraz zacinal novy projekt, tak by som ovela vacsi doraz kladol na:
- extremne detailne pozbieranie poziadaviek,
- potom prioritizaciu poziadaviek na must have, nice to have,
- must have poziadavky by som si este otestoval na buducich pouzivateloch,
- az potom by som si vydefinoval jednotlive iteracie projektu,
- jedna iteracia by zodpovedala dlzke cca 12 mesiacov s timom max. 15 ludi na strane dodavatela - robit dodanie za 8 mil a za cca 12-14 mesiacov zabije komplet cely tim a ludia projekt znenavidia, plus straca sa moznost “zastavit sa” a pozret sa na projekt z nadhladu a urobit rozumne rozhodnutia, lebo sa riesia a lepia problemy a clovek je v tom potom zacykleny
- BI robit az v takej faze produktu/projektu, ked je vsetko stabilizovane a viem presne co od BI chcem a ci ho vobec potrebujem
- verejny portal poriadne premysliet este pred implementaciou, identifikovat si cielovku, co chcem ktorej skupine pouzivatelov tlmocit cez portal, atd.
- pri navrhu a implementacii premyslat nad tym ako co najjednoduchsie zverejnim data, nakolko zly navrh sa mi potom vrati pri zverejnovani dat
- viac funckionality by som nechal na verejnost/sukromonikov a skor by som vybudoval OpenAPI a OpenData API
-> na toto ale treba mat nad sebou ludi, ktori rozmyslaju rovnako a budu takyto postup obhajovat a nepripustia vynimky
5 Likes
Neznie velmi agilne 
Tak to mame 15 ludi * 240 dni * povedzme 500 eur MD rate = 1.800.000 eur za vyvoj. Kto spravi taky projekt ako prvy?
@Ernest_Walzel obdobne chyba zopar partnerov projektov v realizacii v tabulke subjekty - napr itms_id 102016:
https://app.redash.io/ebalgava/public/dashboards/C9XK4gFzLtKu8rLNeBXugFWeG3UsHy03O65Oolsg
1 Like
Myslel som tym, ze ked nemas sajnu co chces robit, tak to nerob…alebo kym nie je jasne definovana metodika, proces, formular, ktory ma byt podporeny IT riesenim, tak to tiez nema vyznam robit…zmenit papier je jedna vec a zmenit aplikaciu je uz nieco ine
prirucka pre ziadatelov vraj stanovuje limit 740 EUR/MD…aj to by bolo stale ok 15240740 = 2 664 000
Dakujem za vycerpavajuce odpovede.
Novospristupnene data mi otvorili dalsiu sadu otazok:
-
datum prijatia chyba na mnohych prijatych a zamietnutych ZoP (na Uhradenych ZoP je aktualne vzdy vyplneny)
– datum created_at je sice vzdy vyplneny, ale od datumu prijatia sa velmi lisi
— na uhradenych ZoP vidno ze date_diff created voci uhrade nadobuda hodnoty od -447 do 327
— na uhradenych ZoP vidno ze date_diff prijatie voci uhrade nadobuda hodnoty od 0 do 279
– da sa zabezpecit vyssia vyplnenost datumu prijatia aby sa z neho stabilne dalo pocitat trvanie spracovania ZoP? -
datum uhrady chyba na troch uhradenych ZoP typu refundacia
– je uhradena ZoP bez datumu uhrady teda naozaj uhradena? (ich suma schvalena je nenulova) -
flag ‘vyplaca_sa_partnerovi’ na vsetkych zverejnenych ZoP aktualne nadobuda hodnotu false
– na Projektoch vidno ze nejeden Projekt ma viacerych partnerov (napr. projekt 971)
– ak sa ZoP bude vyplacat partnerovi, ako sa dozviem ktoremu? -
mozu sa predlozene ZoP neskor schvalit aj ked su ich projekty uz ukoncene?
-
predlozene ZoP nemaju ziadny limit dokedy by mali byt spracovane? (v zmysle uhradene/zamietnute)
– u mnohych predlozenych ZoP uplynul uz viac ako rok od prijatia
– na uhradenych ZoP vidno ze zatial boli vsetky uhradene max do 279 dni od datumu prijatia
– na uhradenych ZoP vidno ze niektore ZoP su uhradene este v datume prijatia
— jedna sa najma o zalohy, ale vidno aj zalohu ktora bola uhradena 128 dni po prijati
— napr ZoP typu zaloha s id 2 je najdlhsie nespracovanou ZoP (aktualne 600 dni)
Moje pracovne podklady:
- Predlozene ZOP ku Projektom:
https://app.redash.io/ebalgava/public/dashboards/cIv7eUHXW2dcy2ZK45agRfuTGZSt5ctulmWqaRaW
- Uhradene ZOP ku Projektom:
https://app.redash.io/ebalgava/public/dashboards/RjVxZlwd5ejTZobkkcttkovmdR2I7gdqzyQsqMgJ
Pozrel som sa na to a zapol som to. Daj vediet ci funguje ako cakas.
1 Like
daj mi par ID, kde to tak je…mam tusenie, ale chcem si to potvrdit…
…ale uz teraz na 98% to bude sposobene tym, ze do endpointu pre Prijate ZoP idu vsetky ZoP, ktore boli predlozene na RO/SO z verejnej casti a maju stav Importovana…RO/SO caka na dorucenie ZoP bud v pisomenj podobe alebo cez elektronicku schranku a ked ZoP takto obdrzi, tak zacina konat…kontroluje, ci bola dorucene v sulade s definovanymi podmienkami a urobi posun do dalsie stavu, nasledne robi posun do stavu Zaregistrovana na RO/SO a v ramci tohto posunu je povinnost vyplnit aj Datum prijatia na RO/SO…cize tie datumy by mali v case pribudat na kazdej ZoP v ramci endpointu Prijatych ZoP…
…datum created je systemovy datum, kedy ZoP bola vytvorena na verejnej casti prijimatelom…on ju moze vytvorit a kludne aj 3 mesiace spracovavat a az potom predlozit…tu nejake speci pravidla neplatia az na male vynimky v ramci predfinancovani a zaloh, ale tie nejak nehraju dolezitu ulohu…
…toto ideme fixnut…zmenime podmienku, aby to bolo jasne a k tomuto nedochadzalo, ale v podstate problem aktualne je v tom, ze ZoP sa do endpointu Uhradenych ZoP opat dostava na zaklade stavu workflowu a datum uhrady chodi z ineho externeho uctovneho IS…ako som uz predtym pisal, tak ZoP typu zuctovanie zalohy alebo zuctovanie predfinancovania sa povazuje za Schvalene/Uhradene uz schvalenim tzv. Suhrnnej ziadosti o platbu na urovni MF SR, nakolko k tymto typom ZoP sa realna uhrada nerobi…cize do endpointu aktulane natekaju ZoP v 2 stavoch a nebola tato podmienka osetrena este o typ ZoP…ideme to zmenit, ze sa budu zobrazovat ZoP iba, ked budu v stave Uhradena a takto sa zabezpeci, ze kazda ZoP bude mat Datum uhrady…
…aj tie 3 aktualne identifikovane refundacie budu mat v case naplnene datumy uhrady…
…flag vyplaca sa partnerovi hovori o tom, ci sa robi realna uhrada ZoP smerom na bankove spojenie partnera…ale toto nie je nic speci, lebo aj ked sa nerobi uhrada priamo na partnera, tak uhrada ZoP sa zrealizuje na bankove spojenie prijimatela projektu a ten ma potom povinnost rozposlat alikvotne ciastky na jednotlivych partnerov…
…projekt moze mat partnerov a nemusi…ak partnerov ma, tak moze mat takych, ktory maju jasne identifikovany harmonogram aktivit, rozpocet a ukazovatele projektu alebo takych, ktori takto nemaju identifikovane struktury…a ak ma takych s rozpoctom, harmonogramom a ukazovatelmi, tak moze byt este povedane, ci sa uhrady realizuju priamo voci partnerovi alebo nie a teda uhrada ZoP ide cela smerom k prijimatelovi…
…vydavky partnera vies v ZoP identifikovat cez referenciu vydavku na intenzitu a intenzita maju referenciu na subjekt…
…skus popisat detailnejsie pripad, na ktory sa pytas…
…ano maju …trafila si klincek po hlavicke…http://www.partnerskadohoda.gov.sk/zakladne-dokumenty/ System riadenia a System financneho riadenia ESIF definuju casy pre spracovanie…
…tie casy su definovane ovela kratsie ako je realita…ale treba povedat, ze vypocet na zaklade tychto datumov nie je uplne presny, nakolko ak je ZoP predmetom doplnenia zo strany prijimatela alebo predmetom kontroly na mieste, tak tento cas sa nezapocitava do celkoveho casu spracovania ZoP…kontroly by mali byt tiez ako samostatny endpoint a tie doplnenia bude tiez treba nejak poriesit v API…
…inak podla tvojich otazok a nazeraniu na problematiku, vies viac ako cca 70% ludi pracujcucich v eurofondoch podla mojho odhadu…
napr ZoP 1942, 657 (podla created z 2016)
v tom linku na redash si to vies kliknutim na nazov stlpca zoradit napr. podla ‘zop_datum_prijatia’
obdobne uz aj na https://bi.ekosystem.slovensko.digital/dashboard/11
cize moze byt aj rok a pol starsi ako datum uhrady? napr. ZoP 1193
cize ‘vytvorena na verejnej casti’ moze byt aj neskor ako nastane uhrada?
a tie ostatne stavy pokryjete potom novymi endpointami?
zaujimalo by ma ake vsetky este stavy su a ktore sa nezverejnuju a preco
napr ZoP 200, 196, 295, 270, … ktore su predlozene ale ich projekt je uz ukonceny (zorad si moje predlozene ZoP podla ‘projekt_stav’)
a vztahuju sa az od datumu prijatia?
hladam ten spravny datum odkedy uradnikom bezia limity na spracovanie
ID 1942 je presne ten stav, co som popisal
ID 657 je iny stav…prijimatel vyuzil moznost stiahnutia ZoP, t.j. poslal list, ze nechce, aby tato ZoP nebola predmetom kontroly, cize nikdy nepresla stavom workflowu, kde sa vyzaduje Datum prijatia, preto tento datum neexistuje pre danu ZoP a ani nebude existovat
ID 1193 chyba pouzivatela. Chybne zadany datum prijatia.
Plati, ze datum prijatia nesmie byt starsi ako je datum vytvorenia. Datum uhrady nesmie byt starsi ako je datum prijatia. Vsetko ostatne su chybne data.
Zverjnene su vsetky ZoP.
Prijate ti ukaze, co vsetko na RO/SO prislo.
Uhradene ti ukaze, co vsetko bolo schvalene a uhradene.
Zamietnute ti ukaze, co vsetko bolo zamietnute.
Takto su zverejne vsetky ZoP, ziadna nie je nezverejnena.
Sarapatu mozu robit tie Stiahnute ziadatelom, ale to sa musim opytat metodikov, ci to nema koncit v stave Zamietnuta.
…vsetko tieto ZoP su aj Uhradene, cize ot je ok…
…ten endpoint Prijate ZoP sa sprava kumulativne…tam sa kopia vsety ZoP, ktore boli na RO/SO predlozene…ak sa ZoP vyskytne aj v inom endpointe, napr. Uhradena, tak sa nestane, ze zmizne z endpointu Prijate ZoP a uz sa nachadza len enpointe Uhradenych…ostava aj tam aj tam…
…Datum prijatia je ten datum, od ktoreho sa im pocitaju lehoty…
moja chyba - to som si mohla vsimnut uz skor, ale aj teraz mi to usetrilo cas
nechystate taketo kumulativne endpointy na vsetky objekty? vzhladom na DB strukturu v ekosysteme mi presne toto na projektoch chyba
ocakavala by som vsak ze schvalenim plynie nova lehota na uhradenie
na riadny vypocet priemernej dlzky spracovania ZoP v ich aktualnych stavoch mi potom v API chyba datum schvalenia, inak to viem vypocitat prinajlepsom takto:
1 Like