MAGISTRSKO DELO Program: Management informacijskih sistemov Smer: Analiza in načrtovanje informacijskih sistemov. eporočanje FINANČNIH PODATKOV OBČIN

Transcription

1 UNIVERZA V MARIBORU FAKULTETA ZA ORGANIZACIJSKE VEDE MAGISTRSKO DELO Program: Management informacijskih sistemov Smer: Analiza in načrtovanje informacijskih sistemov eporočanje FINANČNIH PODATKOV OBČIN Mentor: izr. prof. dr. Robert Leskovar Kandidat: Janez Klemenc Kranj, november 2007

2

3 Zahvala»Vsem, ki si to zaslužijo. Tisti, ki si zaslužijo, že vedo, kdo so, tisti, ki si ne, se tega niti ne zavedajo.«neznani avtor Zahvaljujem se mentorju prof. dr. Robertu Leskovarju, za njegovo pomoč in nasvete pri izdelavi in zagovoru magistrske naloge. Hvala g. Tomažu Dežmanu iz podjetja Aldia d.o.o. za vsa izzivalna vprašanja in konstruktivne predloge, ki so sprožila razmišljanje ter vsem, ki so sodelovali pri razvoju in uvajanju sistema APPrA-O. Študij in raziskovalno delo je finančno omogočilo Ministrstvo za finance Republike Slovenije, v okviru izdelave projekta sistema APPrA-O. Prijateljici Vesni - za vzpodbudo in nasvete, in staršem, brez njih ne bi bil tukaj.

4

5 Povzetek: V nalogi je predstavljen sistem zbiranja, obdelave, kontrole in analize finančnih podatkov in uveden sistem eporočanja, ki nadomešča klasično zbiranje in obdelavo podatkov. Opredeljene so uporabniške zahteve eporočanja s sistemom Aplikacije za Pripravo Proračunov in Analize za občine (APPrA-O). Uveden sistem APPrA-O omogoča podporo postopkom in aktivnostim v fazi priprave proračunov občin, analizo podatkov, povezanih s proračunom ter elektronsko izmenjavo finančnih podatkov o realizaciji med občinami in Ministrstvom za finance (MF). Sistem eporočanja omogoča poenoten sistem priprave, kontrole in posredovanja finančnih podatkov občin ob upoštevanju veljavne zakonodaje s tega področja. Čas posredovanja in obdelave podatkov se je znatno skrajšal, zmanjšale so se možnosti pojava napak, saj je vnos podatkov enkraten. Poenoteni sistem elektronskega poročanja omogoča boljši pregled in kontrolo podatkov, tako dobimo kvalitetnejše podatke. Sistem omogoča boljše odzivne čase pri odpravljanju morebitnih vsebinskih napak in dvosmerno komunikacijo med občinami in MF. Odlikuje ga večja varnost pred vdorom in morebitnimi zlorabami podatkov. Sistem APPrA-O je spremembam prijazno orodje in odlična osnova za nadaljnjo analizo zbranih podatkov. Ključne besede: Objektno modeliranje eporočanje Finančni podatki Občine

6

7 Abstract: The present work presents a system for gathering, processing, control and analysis of financial data. The goal of this MA thesis was the construction of an ereporting system which would completely replace classical reporting and data workout. The thesis defines the basic user requirements of ereporting with a system of Application for Preparing Budgets and of Analyses for Municipalities (APPrA-O). The system APPrA-O is a basic tool for the reporting of municipalities including the accepted budget and reporting of realized budgets in all three parts of the budget (the general and the special part of the budget and the plan of development programs). The system of ereporting enables a unified system of preparing, control and transition of budgets for municipalities, the analysis of budget connected data and the electronic exchange of financial data concerning the implementation between municipalities and the Ministry of Finance (MF). In accordance with the valid legislation a suitable base is provided and so the homogenized preparing of budgets of municipalities is ensured and reporting of the realizations established. Due to the unified entry of data, the time of intervention and the processing of data are considerably shortened and the possibility of the occurrence of mistakes reduced. The homogenized system of ereporting allows better overview and data control, and the obtaining of high quality data. The system allows better response times when it comes to removing possible content mistakes and in the case of bidirectional communication between municipalities and the MF. Greater safety against invasion into data and eventual misuses of data distinguishes the system. The system has brought changes in the type of tool and serves as an excellent base for further analysis of the collected data. Keywords: Object modeling ereporting Financial data Municipalities

8

9 KAZALO 1. UVOD METODOLOGIJA OPREDELITEV PROBLEMA CILJI RAZISKAVE UTEMELJITEV RAZISKAVE METODE DELA OPIS PRIMERLJIVE REŠITVE PROBLEMA PRVOTNI NAČIN ZBIRANJA FINANČNIH NAČRTOV MOTIVI ZA IZDELAVO NOVE APLIKACIJE OPIS ARHITEKTURE SISTEMA UPORABLJENE TEHNOLOGIJE OPIS SISTEMA APPrA OPIS SPLETNE APLIKACIJE SAPPrA POSLOVNI PROCES POTEK RAZVOJA INFORMACIJSKEGA SISTEMA OPIS OBSTOJEČEGA PROCESA ZBIRANJA FINANČNIH PODATKOV RAZLOGI ZA IZDELAVO SISTEMA APPrA-O OPIS APLIKACIJE APPrA-O NAMEN APLIKACIJE APPrA-O IN OPIS MODULOV MODUL ZA PRIPRAVO PREDLOGOV PRORAČUNA MODUL ZA SPREMLJANJE REALIZACIJE SPLOŠNEGA IN POSEBNEGA DELA PRORAČUNA MODUL ZA PRIPRAVO NAČRTA RAZVOJNIH PROGRAMOV (NRP) OPIS ARHITEKTURE APLIKACIJE APPrA-O POSLOVNI PROCES SPECIFIKACIJA ZAHTEV ZA IZDELAVO MODULA ZA SPLETNO eporočanje NAMEN MODULA ZA SPLETNO eporočanje POSNETEK OBSTOJEČEGA STANJA ZAKONSKE IN DRUGE PRAVNE PODLAGE OSNOVNE LASTNOSTI INFRASTRUKTURE SHEMA INFRASTRUKTURE MODULA ZA SPLETNO eporočanje PODATKOVNE ZAHTEVE ODZIVNI ČASI TEHNIČNE ZAHTEVE Odjemalec Strežnik MF - SQL Server UPORABNIŠKE VLOGE STATUSI ODDANIH PODATKOV Uporabniške vloge in sprememba statusov Kriteriji za spremembe statusov FUNKCIONALNE ZAHTEVE Funkcionalne zahteve za modul spletnega eporočanja za splošni (I. del) in posebni (II. del) proračuna Funkcionalne zahteve za modul spletnega eporočanja III. dela proračuna - NRP...34

10 LOGIČNI FUNKCIJSKI MODEL Logični funkcijski model za modul spletnega eporočanja za splošni (I. del) in posebni (II. del) proračuna Logični funkcijski model za modul spletnega eporočanja III. dela proračuna - NRP PREVERJANJE PODATKOV - KONTROLE Preverjanje podatkov - kontrole za modul spletnega eporočanja za splošni (I. del) in posebni (II. del) proračuna Preverjanje podatkov - kontrole za modul spletnega eporočanja III. dela proračuna - NRP NASTAVITVE APLIKACIJE LOGIČNI PODATKOVNI MODEL ZA MODUL SPLETNEGA eporočanja ZA SPLOŠNI (I. DEL) IN POSEBNI (II. DEL) PRORAČUNA Odhodki Prihodki LOGIČNI PODATKOVNI MODEL ZA MODUL SPLETNEGA eporočanja III. DELA PRORAČUNA - NRP Splošni model Atributi projekta Dinamika PV - Lastna sredstva Dinamika PV - Transfer iz državnega proračuna Dinamika PV - Evropska sredstva Dinamika OV - Druge občine Dinamika OV - Posredni proračunski uporabniki Dinamika OV - Domači partnerji Dinamika OV - Tuji partnerji PROCESI Procesa za modul spletnega eporočanja za splošni (I. del) in posebni (II. del) proračuna Procesa za modul spletnega eporočanja III. dela proračuna - NRP TEHNIČNA NAVODILA ZA IZDELAVO MODULA ZA SPLETNO eporočanje PRENOS PODATKOV IZ LS NA STREŽNIK MF ZA SPLOŠNI (I. DEL) IN POSEBNI (II. DEL) PRORAČUNA PRENOS PODATKOV ZA POSODABLJANJE ŠIFRANTOV IZ STREŽNIKA MF NA LS PRENOS PODATKOV IZ LS NA STREŽNIK MF ZA III. DEL PRORAČUNA - NRP PRENOS PODATKOV IZ STREŽNIKA MF NA OBČINO ZA PROJEKTE IZ III. DELA PRORAČUNA - NRP PRENOS PODATKOV IZ STREŽNIKA MF V PODATKOVNO BAZO SPUP ZA PRIPRAVO DRŽAVNEGA PRORAČUNA ANALIZA POTREBNIH SPREMEMB V APLIKACIJI APPrA-O ANALIZA POTREBNIH SPREMEMB V APLIKACIJI APPrA-O ZA SPLOŠNI (I. DEL) IN POSEBNI (II. DEL) PRORAČUNA ANALIZA POTREBNIH SPREMEMB V APLIKACIJI APPrA-O ZA III. DEL PRORAČUNA - NRP ANALIZA POTREBNIH SPREMEMB V PODATKOVNIH BAZAH SPUP in APPrA_EXT ZAKLJUČEK LITERATURA IN VIRI... 73

11 1. UVOD Ideja načrtovalskih vzorcev v svetu razvoja programske opreme nikakor ni nova. Večina strokovne javnosti pripisuje začetke razvoja načrtovalskih vzorcev Christopherju Alexandru in njegovim sodelavcem. Leta 1977 so Alexander in kolegi predstavili delo "A Pattern Language", v katerem so opisali 253 načrtovalskih vzorcev. Vsak od njih naj bi reševal ponavljajoči se arhitekturni problem. Knjiga je imela velik vpliv, ne samo na stavbno arhitekturo, kar je bil njen osnovni namen, pač pa tudi na načrtovanje arhitektur v informacijski tehnologiji. Erich Gamma 1 je leta 1994 nadaljeval Alexandrovo delo s pisanjem in objavo dela "Design Pattern Elements of Reusable Object-Oriented Software". Glavni del knjige je katalog 23 načrtovalskih vzorcev, ki vključuje sedaj že klasični načrtovalski vzorec SmallTalk: Model/Pogled/Kontrola (Gačnik, 2005). Kadar modeliramo sistem, ga lahko opišemo na več načinov. Ena od možnosti je konstruiranje diagramov, ki predstavljajo različne poglede na sistem. Vsak od njih je neodvisen, vendar na neki način povezan z drugimi vidiki (Eriksson in Penker, 2000). Svet okoli sebe modeliramo predvsem zato, ker je delati z modeli veliko lažje kot manipulirati z realnim svetom. Informatiki največkrat modeliramo poslovne sisteme, organizacije, pojave in podobno. Cilj modeliranja organizacije je tako povečati razumljivost poslovanja in ga izboljšati, kakor tudi informatizirati poslovanje. Objektna paradigma predstavlja revolucionaren preobrat na področju gradnje programskih sistemov, saj zagotavlja svojevrstne koncepte za obvladovanje kompleksnosti kot so na primer objekti, razredi, dedovanje, ograjevanje in polimorfizem. Na področju gradnje informacijskih sistemov ima objektna tehnologija vodilno vlogo. Vpliva na vsa področja informatike in ni le predmet akademskih raziskav, temveč je zelo razširjena in uveljavljena v praksi. Čeprav se z objektno orientacijo pogosto povezujejo pridobitve kot so višja produktivnost, lažje vzdrževanje in višja stopnja ponovne uporabe, teh pridobitev ni mogoče pogojevati zgolj z uporabo objektnega pristopa. Objektna tehnologija namreč sama po sebi ne zagotavlja, da je programska oprema, razvita s pomočjo objektnih tehnik, kakovostnejša ter da razvijalci izkoristijo razpoložljive možnosti na najboljši možni način. Iz vsesplošne sprejemljivosti te vrste modela lahko sklepamo, da takšen način modeliranja dobro rešuje problem kompleksnosti, in predvidevamo, da lahko te dobre prakse uporabimo tudi na področju modeliranja v informacijski tehnologiji. 1 Erich Gama in sodelavci so znani tudi kot "Gang of Four" ali "GOF" Janez Klemenc: eporočanje finančnih podatkov občin Stran 1

12 Nova ekonomija in elektronsko poslovanje sta sinonima za dinamično spreminjanje globalnih razsežnosti. Programska oprema je eden ključnih elementov, ki omogoča delovanje organizacije v teh pogojih. Kakovost programske opreme, ki jo poslovni sistemi uporabljajo v novi ekonomiji, dosega spodnjo mejo primernosti (Leskovar, 2000). V nalogi želimo predlagati sistem zbiranja, obdelave, kontrole in analize finančnih podatkov za uvedbo eporočanja, ki bo popolnoma nadomestilo klasično zbiranje in obdelavo podatkov. Pri tem je z ustreznim objektnim pristopom in uporabo sodobne informacijske in komunikacijske tehnologije (IKT) možno doseči novo kvaliteto v pogledu celovite slike finančnega stanja posamezne občine, kontrole in primerjalne analize med posameznimi občinami. Vsebina naloge izhaja iz dosedanjih izkušenj in skupnih sestankov naročnika MF - SSFLS, izvajalca podjetja SRC.SI d.o.o. in nominiranega podizvajalca podjetja Aldia, d.o.o.. Naloga opredeljuje osnovne uporabniške zahteve eporočanja s sistemom APPrA-O. Namen uporabe sistema APPrA-O je podpora postopkom in aktivnostim v fazi priprave proračunov občin, analiza podatkov povezanih s proračunom ter elektronska izmenjava finančnih podatkov o realizaciji med občinami in Ministrstvom za finance (državnim proračunom). Stran 2 Janez Klemenc: eporočanje finančnih podatkov občin

13 2. METODOLOGIJA V okviru metodologije je v nadaljevanju opredeljen problem, ki ga obravnava raziskava, določeni so cilji raziskave ter podan opis metode dela. Sledi pregled in opis primerljive rešitve problema na nivoju državnega proračuna OPREDELITEV PROBLEMA Sodobna IKT predstavlja konkreten izziv za praktično uporabo večpredstavnosti v organizacijskih sistemih (Kljajić 1994; Kaplan 1997). Izrazne in funkcijske možnosti sodobne IKT je smiselno uporabiti tudi v namene zbiranja raznovrstnih podatkov. Zaradi ogromne količine raznovrstnih podatkov iz različnih virov se je pokazala nujna potreba po uvedbi spletnega informacijskega sistema za elektronsko zbiranje, obdelavo, kontrolo in analizo podatkov (eporočanje). Dokler je obdelava podatkov ročna, niso izkoriščene možnosti IKT. Z uvedbo prenosa klasične obdelave podatkov v elektronsko, je smiselno uporabiti objektni pristop (McFadden, Hoffer 1994; Barry 1996), ki omogoča ustreznejše strukturiranje in ločeno obdelavo podatkov v elektronski obliki. Gre torej za strukturiranje obdelave podatkov v smislu objektne usmerjenosti, kjer se klasičnim podatkom pridružijo tudi modeli in postopki za njihovo izvajanje, na primer grafični prikazi numeričnih podatkov (Kaplan 1997). Obenem se pri prenovi obdelave podatkov pokažejo možnosti in potrebe po prenovi osnovnih procesov (Jacobson et al. 1994, Ferioli, Migliarese 1997; Chang 1999) v organizacijskem smislu, v tem primeru na področju obdelave finančnih podatkov na lokalni ravni. Ministrstvo za finance Republike Slovenije (MF) postopno že od leta 1999 dalje izvaja proračunsko reformo, ki zajema uskladitev javne porabe z mednarodno prakso, izboljšanje preglednosti in odgovornosti pri razpolaganju s proračunskimi sredstvi ter vzpostavitev novega pristopa odgovornosti in sodelovanja pri razvoju, spremljanju in ocenjevanju izvajanja proračuna. Cilji reforme so povezani z odgovori na tri ključna vprašanja javne porabe: kdo porablja proračunska sredstva (katere institucije), kako jih porablja oziroma kaj se plačuje iz javnih sredstev in za kaj se porabljajo javna sredstva. Odgovori na navedena vprašanja so zajeti v veljavnih zakonskih in podzakonskih aktih s področja javnih financ, računovodstva, javnih naročil in nadzora državnih pomoči, ki jih mora občina upoštevati pri pripravi predloga in realizaciji občinskega proračuna in finančnih načrtov neposrednih in posrednih uporabnikov občine. Občine so pri oblikovanju proračuna z vidika njegove oblike povsem avtonomne, pri čemer pa so obvezane, da upoštevajo veljavne predpise s področja javnih financ. Pri pregledu proračunov občin za posamezno proračunsko leto MF ugotavlja, da je pristop občin pri oblikovanju tega Janez Klemenc: eporočanje finančnih podatkov občin Stran 3

14 dokumenta zelo neenoten. To pomeni, da dejansko v praksi obstaja 210 različno oblikovanih proračunov občin, čeprav so predpisi za njegovo sestavo enotni. Eden izmed razlogov zakaj je potrebno doseči čim višjo stopnjo primerljivosti med proračuni občin in državnim proračunom je tudi ta, da globalno bilanco javnega financiranja v Republiki Sloveniji sestavljajo bilance štirih javnofinančnih blagajn, med katerimi so tudi občinski proračuni (glej Sliko 1). I. DRŽAVNI PRORAČUN III. ZAVOD ZA POKOJNINSKO IN INVALIDSKO ZAVAROVANJE IZVIRNI PRIHODKI ODHODKI PRIHODKI DRŽAVNEGA DRŽAVNEGA ZAVODA ZA ODHODKI PRORAČUNA PRORAČUNA POKOJNINSKO POKOJNINSKO - ZAVAROVANJE INVALIDSKEGA ZAVAROVANJA TRANSFERI SREDSTEV V TRANSFERNI DRUGE BLAGAJNE PRIHODKI IZ JAVNEGA FINANCIRANJA DRUGIH BLAGAJN PRIMANJKLJAJ JAVNEGA FINANCIRANJA DRŽAVNEGA PRORAČUNA PRIMANJKLJAJ PREJETA VRAČILA Z P I Z DANIH POSOJIL DANA POSOJILA ODPLAČILA DOLGA Z P I Z ZADOLŽEVANJE NETO FINANCIRANJE ODPLAČILA Z P I Z Z P I Z ZADOLŽEVANJE DOLGA SPREMEMBE SREDSTEV NA RAČUNIH ZPIZ DRŽAVNEGA DRŽAVE PRORAČUNA NETO FINANCIRANJE PRORAČUNA SPREMEMBE SREDSTEV NA RAČUNIH PRORAČUNA IV. ZAVOD ZA ZDRAVSTVENO DRŽAVNEGA ZAVAROVANJE II. PRORAČUNI OBČIN IZVIRNI ODHODKI PRIHODKI ZAVODA ZA ZDRAVSTVENO IZVIRNI PRIHODKI ODHODKI ZAVAROVANJE PRORAČUNOV OBČIN PRORAČUNOV OBČIN OBVEZNEGA ZDRAVSTVENEGA ZAVAROVANJA TRANSFERNI PRIHODKI IZ DRŽAVNEGA PRESEŽEK TRANSFERNI PRIHODKI PRORAČUNA PRORAČUNOV OBČIN IZ DRUGIH BLAGAJN PRESEŽEK ZADOLŽEVANJE JAVNEGA FINANCIRANJA Z Z Z S PRORAČUNOV OBČIN ODPLAČILA ZADOLŽEVANJE ODPLAČILA DOLGA NETO FINANCIRANJE DOLGA Z Z Z S Z Z Z S PRORAČUNOV OBČIN PRORAČUNOV OBČIN SPREMEMBE SREDSTEV NA RAČUNIH ZZZS SPREMEMBE SREDSTEV NA RAČUNIH PRORAČUNOV Slika 1: Sheme osnovnih blagajn javnega financiranja v Republiki Sloveniji (Vencelj, 1999) Stran 4 Janez Klemenc: eporočanje finančnih podatkov občin

15 MF je občinam pri pripravi enotno oblikovanih proračunov želelo pomagati, zato je od leta 2001 dalje vsako leto pripravljalo proračunski priročnik, tako da bi bili le-ti v vseh občinah pripravljeni v čim bolj poenoteni obliki in skladni z veljavno sistemsko zakonodajo na področju javnih financ. Za primerljivost med proračuni občin in državnim proračunom je bil v juniju 2005 sprejet predpis, to je programska klasifikacija izdatkov občinskih proračunov. Z uveljavitvijo Pravilnika o programski klasifikaciji občinskih proračunov (Uradni list RS, št. 57/05 in 88/05-popr.) je bila s prvič uvedena programska klasifikacija izdatkov občinskih proračunov, ki poleg ekonomske in funkcionalne klasifikacije omogoča poenoteno pripravo in sestavo občinskih proračunov. Septembra 2005 je bila vsem občinam dana možnost uporabe računalniške aplikacije za pripravo proračunov in analize občin (APPrA-O), in sicer samo za del vsebine, ki se nanaša na pripravo splošnega (1. del) in posebnega (2. del) dela proračuna. Tretji del priprave proračuna predstavlja načrt razvojnih programov, zato je priprava le-tega obvezna. V ta namen je MF aplikacijo APPrA-O nadgradilo in je bila občinam poslana v mesecu marcu 2006, tako da je sedaj s to aplikacijo možna celovita priprava proračuna vključno s pripravo načrta razvojnih programov. Delovna hipoteza zajema proučevanje možnosti izdelave spletne aplikacije za eporočanje. Aplikacija naj bi nadomestila elemente klasičnega poročanja in ga celo nadgradila v smislu uporabe modelov za večpredstavne prikaze, kontrolo in analizo finančnih podatkov CILJI RAZISKAVE Cilj raziskave je izdelava spletne aplikacije za eporočanje. Namen raziskave je proučiti možnosti za prehod iz klasičnega poročanja na eporočanje z objektno usmerjeno organizacijo in uporabo sodobne IKT. Objektni pristop združuje elemente klasične obdelave podatkov v integrirano, poenoteno objektno obliko. Pri tem bomo uporabili razpoložljive tehnološke možnosti (Kaplan 1997; Meystel, Albus 2002) ter nudili pomoč in podporo finančnim službam na lokalni in državni ravni UTEMELJITEV RAZISKAVE Sistem APPrA-O bo služil kot osnova za poročanje občin, tako o sprejetih proračunih kot tudi za poročanje o realiziranih proračunih in sicer vseh treh delov proračuna (splošnega in posebnega dela proračuna ter načrta razvojnih programov). S tem je zagotovljena primerna podlaga, da na osnovi veljavne zakonodaje dosežemo poenoteno pripravo proračunov občin ter omogočimo poročanje o njihovem izvrševanju. V ta namen bo izdan pravilnik ministra, pristojnega za finance, ki bo predpisal vsebino in način poročanja. Izdelana bo spletna aplikacija za poročanje občin o sprejetih proračunih ter njihovi realizaciji (OPPrA), kar bo prispevalo k celovitemu eporočanju. Zbrani podatki bodo predstavljali primerno osnovo za nadaljnje Janez Klemenc: eporočanje finančnih podatkov občin Stran 5

16 analize finančnih podatkov na lokalni ravni ter omogočali primerno in pravočasno poročanje domačim in mednarodnim institucijam ter zainteresirani širši javnosti. Prispevek k razvoju znanosti bo predstavljal nov model organiziranja eporočanja o finančnih podatkih na lokalni ravni v elektronski obliki z upoštevanjem možnosti sodobne IKT. Uporabljen bo objektno usmerjen model, ki omogoča dodatne funkcije poleg arhiviranja in prikazovanja podatkov, npr. statistične analize (Jesenko 2001; Freund, Wilson 2003; Moore et al. 2003). Taka oblika eporočanja omogoča tudi ustvarjanje podatkov v smislu oblikovanja novega odločitvenega znanja (Quintas, Ray 2002; Lavrač, Bohanec, 2003; Lavrač, Grobelnik 2003) METODE DELA Uporabljene bodo metode dela kot so pregled tuje in domače literature in na tej osnovi prototipni razvoj modela ter priprava načrta za testiranje. Omenjene metode so razdeljene v naslednjih pet faz: 1. faza: pregled problematike vsebinske obdelave finančnih podatkov na lokalni ravni v tuji in domači literaturi; 2. faza: posnetek obstoječega stanja v smislu vsebine finančnih podatkov na lokalni ravni; na osnovi ugotovljenih slabosti bodo implementirane metode sodobne IKT; 3. faza: razvoj modela eporočanja ob upoštevanju specifičnosti finančnih služb na lokalni ravni; 4. faza: priprava tehničnih navodil za izdelavo spletne aplikacije za eporočanje; 5. faza: izdelava spletne aplikacije, načrt testiranja in uvajanje v praksi tako po metodološki kot vsebinski plati OPIS PRIMERLJIVE REŠITVE PROBLEMA V tem podpoglavju bo predstavljen proces reševanja primerljivega problema, ki se je pokazal pri procesu priprave državnega proračuna. Od opisa preteklega načina zbiranja podatkov, motivov za spremembo, do opisa obstoječe delujoče rešitve PRVOTNI NAČIN ZBIRANJA FINANČNIH NAČRTOV V preteklih letih je zbiranje finančnih načrtov potekalo s pomočjo distribuirane aplikacije (izdelane z MS Visual Basic 6.0) in podatkovne zbirke (MS Access). Vsak predlagatelj finančnih načrtov in vsak proračunski uporabnik je moral s spletnega mesta MF prenesti namensko aplikacijo in jo namestiti na svojem računalniku. Predlagatelji finančnih načrtov so z elektronsko pošto dobili vsak svojo podatkovno zbirko, ki so jo nato posredovali naprej svojim proračunskim uporabnikom. Proračunski uporabniki so v podatkovno zbirko vnesli podatke o svojem finančnem Stran 6 Janez Klemenc: eporočanje finančnih podatkov občin

17 načrtu, nato pa to zbirko vrnili predlagatelju finančnih načrtov. Ta je zbral podatkovne zbirke svojih proračunskih uporabnikov in jih vnesel v enotno zbirko podatkov, ki jo je nato poslal na MF. Glavne pomanjkljivosti takega sistema so: neaktivna vloga MF v samem postopku (nezmožnost vplivanja na postopek med njegovim potekom in nezmožnost hitrega spreminjanja izhodiščnih podatkov), dolgotrajno usklajevanje med proračunskimi uporabniki enega predlagatelja finančnih načrtov in zaradi tega nastale zamude pri pošiljanju podatkov na MF, ni možno (ali pa je zelo zapleteno) izvajanje postopka v več fazah, dolgotrajno zbiranje, konsolidacija in preverjanje pravilnosti podatkov, ni možno delo na več lokacijah hkrati v okviru enega proračunskega uporabnika (npr.: Ministrstvo za šolstvo ima nekje 15 lokacij, na katerih se vnašajo podatki), zahtevna distribucija popravkov v aplikaciji, zahtevno vzdrževanje aplikacije glede na različne konfiguracije sistemov, otežena tehnična pomoč, saj izvajalci nimajo možnosti spremljati dogajanja v podatkovni zbirki proračunskega uporabnika, večja ranljivost sistema zaradi možnih manipulacij s podatki ali nespoštovanja omejitev, ki jih določi MF MOTIVI ZA IZDELAVO NOVE APLIKACIJE Poleg odpravljanja pomanjkljivosti prejšnjega sistema so glavni motivi za izdelavo nove aplikacije naslednji: Poslovni: priprava sistema, ki bo omogočal tudi druge aktivnosti, v katerih sodelujejo proračunski uporabniki (priprava dinamiziranih projekcij proračuna, priprava zaključnega računa in podobno), priprava sistema, ki bo varen in bo v prihodnje omogočal tudi pošiljanje uradne dokumentacije v elektronski obliki (digitalni podpis), priprava sistema z najsodobnejšo opremo, ki zagotavlja daljši čas izkoriščanja in tako omogoča boljši izkoristek naložbe. Tehnični: ni potrebna distribucija aplikacije, ni potrebno zbiranje in konsolidacija podatkov (podatki se vnašajo v osrednjo podatkovno zbirko), standardizirano okolje za izvajanje aplikacije (edini pogoj je Internet Explorer 5.0 ali novejši), uporaba novejše programske opreme, ki zagotavlja večjo hitrost izvajanja in enostavno razširjanje (performance in scalability). Janez Klemenc: eporočanje finančnih podatkov občin Stran 7

18 OPIS ARHITEKTURE SISTEMA Vpeljan je bil večplastni sistem, ki omogoča enostavno razširjanje in nezahtevno vzdrževanje. Pri tem so upoštevane naslednje sistemske zahteve: aplikacija mora izkoriščati obstoječo infrastrukturo državne uprave (komunikacijsko omrežje HKOM), razvojno okolje: MS Visual Studio.NET, programski jezik: Visual Basic.NET ali/in C#.NET, odjemalec: MS Internet Explorer 5.0 ali višji, aplikacijski strežnik: MS Windows 2000 s spletnim strežnikom IIS 5.0, podatkovni strežnik: MS SQL Server Predstavitvena plast (GUI) ima zaradi spletne narave aplikacije naslednje posebnosti: Implementacija v dveh (pod)plasteh: o strežniška plast (teče znotraj IIS, ASPX strani, ASP.NET kontrole, upodabljanje dinamičnih strani, nadzor nad uporabniško sejo), o odjemalska plast (teče znotraj IE, HTML, JavaScript, lokalne spremenljivke). Zaradi zmanjšanja količine prenesenih informacij je stran razdeljena na tri okvirje (frames), eden je namenjen za prikaz dinamične vsebine, dva pa sta nevidna (sistemska) in poskrbita za izmenjavo podatkov med odjemalcem in strežnikom. Slika 2: Shema arhitekture - koncept (Munda, 2004) Stran 8 Janez Klemenc: eporočanje finančnih podatkov občin

19 Primer: Ko uporabnik v vsebinskem okvirju klikne na vozlišče v drevesu, morajo biti v tabelo vneseni ustrezni podatki. To se zgodi tako, da se v sistemskem okvirju pokliče stran (t.i. "content handler"), katere vsebina so samo osnovni podatki za tabelo (ne pa tudi oblika tabele). Ti podatki se s pomočjo funkcij JavaScript prenesejo v vsebinski okvir in tam prikažejo. Tako se vsebinski okvir ne prenese s strežnika ob vsaki uporabnikovi akciji na novo (kot je to običajno pri spletnih aplikacijah), ampak za vsak obrazec samo enkrat. Uporabljene so strežniške ASP.NET kontrole, narejene po meri. Postavitev in oblikovanje elementov na strani poteka z elementi "DIV" UPORABLJENE TEHNOLOGIJE V razvojnem okolju je bila uporabljena naslednja programska oprema: MS Windows XP z IIS5.1 (in Windows 2000 z IIS 5.0), MS.NET Framework 1.1, MS Visual Studio.NET 2003, MS SQL Server 2000 Developer Edition, MS Visual SourceSafe 6.0, Crystal Reports 9, MS Aplication Center Test. Produkcijsko okolje je bilo vpeljano z naslednjo programsko opremo: MS Windows 2003 z IIS 6.0 in.net Framework 1.1, MS SQL Server 2000 Enterprise Edition, Crystal Reports 9 Advanced Edition. V strežniškem delu GUI-a je bilo uporabljeno: ASP.NET, "custom server web controls", Crystal Reports 9 web viewer, aplikacijske nastavitve s pomočjo datotek XML in web.config. V odjemalskem delu GUI-a so bili upoštevani standardi: HTML 4.0, DHTML in DOM Level 2, SSL 2.0, JScript 1.5 (združljiv z ECMAScript 2.0). Celotna poslovna plast aplikacije je izvedena s programskim jezikom Visual Basic.NET. 2 Element DIV se uporablja za označevanje bloka v dokumentu HTML. Elementi DIV so lahko tudi gnezdeni. Element nima privzetega nikakršnega oblikovanja. Omogoča pa razdelitev dokumenta HTML na bloke. Vsakega od teh blokov pa je mogoče neposredno in neodvisno upravljati. Mogoče je na primer s pomočjo slogovnih predlog vsakemu od teh blokov določiti neodvisno (absolutno) pozicijo v dokumentu, različne obrobe, pisave, barve. (Vir: Janez Klemenc: eporočanje finančnih podatkov občin Stran 9

20 OPIS SISTEMA APPrA MF za zadovoljevanje svojih potreb po informacijah, povezanih z državnim proračunom, uporablja dva večja sistema: za izvrševanje proračuna sistem MFERAC (Ministrstvo za finance Enotno RAČunovodstvo) in za pripravo proračuna ter proračunske analize sistem APPrA, ki je plod sodelovanja med MF in podjetjem SRC.SI. Sistem APPrA (Aplikacije za Pripravo Proračuna in Analize) je na državnem nivoju namenjen podpori postopkom in aktivnostim v fazi priprave proračuna in analizam podatkov, povezanih s proračunom. Vsebuje dve aplikaciji: APPrA in SAPPrA - Spletna aplikacija za pripravo proračuna in analize. Aplikacija APPrA je namenjena Direktoratu za proračun in sestavljena iz naslednjih modulov: Priprava proračuna, ki omogoča pregledovanje in spreminjanje podatkov o proračunu na poljubni ravni; Realizacija, ki nam omogoča različne analitične izpise letne in mesečne realizacije proračuna; Scenariji za izdelavo projekcij prihodkov in odhodkov javnih financ/proračuna ter transakcij odplačil glavnic in plačila obresti; Amandmaji za upravljanje z dopolnili proračuna; Optimizacija dinamiziranih projekcij minimizira medmesečne razlike med prihodki in odhodki proračuna in jih usklajuje z dinamiko zadolževanja; Administracija, ki zagotavlja potrebno upravljanje in nadzor nad sistemom APPrA. Sistem je zasnovan okoli središčne aplikacije APPrA, ki jo v sektorju za proračun MF uporabljajo za zahtevne postopke spreminjanja proračunskih elementov pri pripravi predlogov državnega proračuna. Osrednji aplikaciji se priključujejo moduli, ki so tehnično del te aplikacije ali pa ločene aplikacije, ki uporabljajo isti vir podatkov kot osrednja aplikacija. Zgoraj našteti moduli so vpeljani z MS Accessom, vsi pa uporabljajo podatkovno zbirko na MS strežniku SQL. V začetku leta 2003 so se v razvojni skupini APPrA odločili, da bodo nove aplikacije razvite na temelju MS.NET. Kot posledica te odločitve sta v okviru sistema APPrA nastali dve novi aplikaciji, v celoti razviti z orodjem Visual Studio.NET. Prva se imenuje SAPPrA (Spletna aplikacija za pripravo proračuna in analize) in je mišljena kot osrednja aplikacija sistema APPrA za uporabo zunaj MF. Druga je NRP in jo bodo uporabljali v Sektorju za proračun in Sektorju za investicije za pripravo ter spremljanje razvojnih programov. Stran 10 Janez Klemenc: eporočanje finančnih podatkov občin

21 OPIS SPLETNE APLIKACIJE SAPPrA Spletna aplikacija SAPPrA je namenjena finančnim in strokovnim službam proračunskih uporabnikov za vnos in obrazložitev proračuna ter obrazložitve zaključnega računa proračuna, kasneje pa tudi za druge dejavnosti, povezane z načrtovanjem in pripravo podatkov o proračunu pri njegovih uporabnikih. Ta aplikacija je tisti del sistema APPrA, ki se uporablja zunaj MF, in kot taka ni namenjena uporabnikom osrednje aplikacije APPrA. Deluje v celoti kot spletna aplikacija in je proračunskim uporabnikom celo leto dostopna na spletnem strežniku MF. Aplikacijo sestavljata dva modula: Priprava proračuna za posredovanje finančnih načrtov proračunskih uporabnikov skupaj z obrazložitvami in Zaključni račun za posredovanje obrazložitev zaključnega računa. Slika 3: Shema infrastrukture aplikacije SAPPrA (Munda, 2004) POSLOVNI PROCES Aplikacija SAPPrA v poslovnem procesu priprave proračuna zajema naslednje dejavnosti: posredovanje proračunskih projekcij, ki jih pripravijo na MF, proračunskim uporabnikom; določanje omejitev proračunske porabe v skladu s proračunskimi projekcijami in vladnimi uredbami; Janez Klemenc: eporočanje finančnih podatkov občin Stran 11

22 začetni vnos podatkov o proračunu na najnižji podatkovni ravni (proračunska vrstica) in posredovanje finančnih načrtov proračunskih uporabnikov MF; posredovanje obrazložitev finančnih načrtov proračunskih uporabnikov MF; potrjevanje finančnih načrtov; popravljanje finančnih načrtov in obrazložitev v času proračunskih pogajanj med MF ter ostalimi resornimi ministrstvi. Pri tem je treba vedeti, da priprava finančnih načrtov poteka na dveh ravneh (prek predlagateljev finančnih načrtov) in v več fazah, ki jih imenujemo "stopnje" priprave proračuna. Rezultat zadnje "stopnje" je predlog proračuna, ki ga MF pošlje Vladi RS v potrditev, ta pa Državnemu zboru v obravnavo. Predlagateljev finančnih načrtov je 36, neposrednih proračunskih uporabnikov 256, vseh fizičnih uporabnikov, ki so registrirani za uporabo aplikacije, pa približno 450. Aplikacija SAPPrA zagotavlja podporo na obeh ravneh priprave finančnih načrtov. Slika 4: Vstopna stran aplikacije SAPPrA ( 2007) Stran 12 Janez Klemenc: eporočanje finančnih podatkov občin

23 3. POTEK RAZVOJA INFORMACIJSKEGA SISTEMA V tem poglavju je opisan obstoječi način zbiranja finančnih podatkov in razlogi za nov pristop in izdelavo nove aplikacije za zbiranje podatkov o realizaciji proračunov občin. Sledi opis dosedanjega razvoja rešitve problema v obliki že izdelane aplikacije APPrA-O, ki še ne vključuje modula za eporočanje, kar je predmet naše raziskave OPIS OBSTOJEČEGA PROCESA ZBIRANJA FINANČNIH PODATKOV Obstoječi proces zbiranja finančnih podatkov o kumulativni mesečni realizaciji proračunov občin poteka s pomočjo Excelovih obrazcev, ki jih občine pošiljajo po elektronski pošti ter v pisni obliki s podpisom odgovorne osebe po pošti. Vsebina obrazcev je uradno predpisana in objavljena v Pravilniku o poročanju občin o prejemkih in izdatkih proračunov občin, ki ga je izdal minister pristojen za finance in je bil objavljen v Uradnem listu RS, št. 6/2006 in 14/2007. Sestavni del pravilnika je priloga z naslednjimi obrazci: Obrazec P: Poročilo o prihodkih in odhodkih, računu finančnih terjatev in naložb ter računu financiranja; Obrazec P1: Poročilo o izdatkih po funkcionalni klasifikaciji; Obrazec P2: Poročilo o izdatkih po programski klasifikaciji. Na podlagi tega pravilnika so občine dolžne Ministrstvu za finance mesečno posredovati podatke do 15. v mesecu za obdobje od 1. januarja tekočega leta do konca preteklega meseca. S tem je podana le pravna podlaga. Za tehnično izvedbo pravilnika je bilo potrebno izdelati identične obrazce objavljene v pravilniku z enačbami in ustreznimi zaščitami, ki onemogočajo spreminjanje obrazca (dodajanje in/ali brisanje stolpcev in vrstic). Na tem mestu je potrebno poudariti, da se je vsebina obrazcev letno spreminjala. To je posledično pomenilo vsako letno ponavljanje celotnega postopka objave in pošiljanja obrazcev vsem občinam v RS (s deluje v RS 210 občin), od katerih je tudi terjalo dodatno delo in prilagajanje postopka izpolnjevanja obrazcev. Z uvedbo novega sistema eporočanja bo to vsako letno prilagajanje na eni in drugi strani odpadlo. Naš cilj in namen je pridobiti in spremljati ustrezne finančne podatke od vseh občin v skladu z naslednjimi predpisi, ki urejajo to področje: Pravilnik o enotnem kontnem načrtu za proračun, proračunske uporabnike in druge osebe javnega prava (Uradni list RS, št. 54/2002, 117/2002, 58/2003, 134/2003, 34/2004, 75/2004, 117/2004, 141/2004, 117/2005, 138/2006), ki je podlaga za sestavo Obrazca P; Odredba o funkcionalni klasifikaciji javnofinančnih izdatkov (Uradni list RS, št. 43/2000), ki je podlaga za sestavo Obrazca P1; Janez Klemenc: eporočanje finančnih podatkov občin Stran 13

24 Pravilnik o programski klasifikaciji izdatkov občinskih proračunov (Uradni list RS, št. 57/2005 (88/ popr.), 138/2006), ki je podlaga za sestavo Obrazca P2. Po prejemu obrazcev prejetih v pisni obliki in posredovanih po pošti, se le-ti predhodno pregledajo v smislu globalnih kontrol (seštevki ipd.). Datoteka posredovana po elektronski pošti se shrani v zato pripravljen imenik in preveri se identičnost posredovanih podatkov s papirnato različico. Zaradi nadaljnje obdelave zbranih podatkov je zelo pomembna kontrola kakršnihkoli sprememb strukture obrazcev (dodane vrstice ali stolpci, spremenjene enačbe in podobno). V skladu s predpisi naj bi posredovanje podatkov potekalo od 1. do 15. v mesecu. Zaradi različnih kadrovskih, tehničnih ter vsebinskih težav pri knjiženju in posredovanju podatkov se proces posredovanja podatkov podaljša še za dodatne tri do štiri tedne. Po prejemu vseh obrazcev se le-ti, po določenem postopku s pomočjo makro ukaza, uvozijo v tri v zato naprej pripravljene zbirne datoteke. Uvozi podatkov potekajo ločeno za vsako vrsto obrazca posebej. To v praksi pomeni 3 krat po 210 uvozov. Vsaka zbirna datoteka vsebuje 210 listov za vsako občino svoj list. Poleg tega pa so pripravljeni še dodatni listi za različne zbirne tabele, ki predstavljajo različne poglede na podatke (zbirni obrazec P za vse občine skupaj, prikaz prihodkov, odhodkov, računa finančnih terjatev in naložb ter računa financiranja po občinah). Te zbirne tabele imajo že vgrajene enačbe tipa "VLOOKUP", kar pomeni, da je z vnosom podatkov zadnje občine obdelava praktično končana. Sledi le še sprožitev makro ukaza za kontrolo skupnih seštevkov in kontrola določenih virov prihodkov, ki jih je mogoče primerjati z drugim neodvisnim virom podatkov. Ta vir podatkov so podatki Uprave za javna plačila, ki je organ v sestavi Ministrstva za finance (v nadaljevanju: MF-UJP). Glavne pomanjkljivosti takega načina zbiranja podatkov so: vsakoletno spreminjanje vsebine obrazcev, kar povzroča precej dodatnega dela tako na strani občin kot na strani MF, togost takega sistema zbiranja podatkov v smislu nezmožnosti medletnega spreminjanja vsebine obrazcev glede na spremembe predpisanih klasifikacij, podvojeno posredovanje podatkov (en izvod v pisni obliki po navadni pošti ter drugi izvod po elektronski pošti), večja ranljivost sistema zaradi možnih manipulacij s podatki ali nespoštovanja omejitev, ki jih določi MF, zamudno ročno vodenje evidence že prispelih podatkov, konsolidacija in preverjanje pravilnosti podatkov, proces ugotavljanja nepravilnosti v prispelih podatkih je povsem ročen, prav tako obveščanje uporabnika o napaki, celoten proces odprave napake in posredovanja korigiranih podatkov je predolgotrajen, zaradi zbranih podatkov v formatu Excel je nadaljnja obdelava in analiza podatkov povsem ročna. Stran 14 Janez Klemenc: eporočanje finančnih podatkov občin

25 3.2. RAZLOGI ZA IZDELAVO SISTEMA APPrA-O Poleg odpravljanja ali vsaj zmanjšanja pomanjkljivosti prejšnjega sistema so glavni razlogi za izdelavo nove aplikacije naslednji: Poslovni: priprava sistema, ki bo omogočal tudi druge aktivnosti, poleg pošiljanja podatkov o realizaciji tudi posredovanje sprejetih proračunov, sprememb sprejetih proračunov, rebalansov proračuna ter veljavnih proračunov občin; priprava sistema, ki bo varen in bo v prihodnje omogočal tudi pošiljanje uradne dokumentacije skupaj z obrazložitvami v elektronski obliki (digitalni podpis); priprava sistema, ki bo omogočal dvosmerno komunikacijo in prenos podatkov iz občin na strežnik MF (podatki o realizaciji, proračunih, itd.) in na zahtevo občine iz strežnika MF na občino (posodabljanje predpisanih šifrantov, prenos podatkov iz načrta razvojnih programov države, kjer se sofinancirajo projekti občine); priprava sistema z najsodobnejšo opremo, ki zagotavlja daljši čas izkoriščanja in tako omogoča boljši izkoristek naložbe. Tehnični: distribucija nadgradenj aplikacije ni potrebna. Nadgradnje aplikacije so javno dostopne na spletni strani MF-SSFLS 3 ; zbiranje in konsolidacija podatkov nista potrebna (podatki se pošiljajo v osrednjo podatkovno zbirko); obveščanje uporabnikov o vsebinskih napakah bo avtomatizirano; okolje za izvajanje aplikacije je standardizirano (edini pogoj je Internet Explorer 5.0 ali novejši ter vključenost uporabnika v omrežje HKOM); uporaba novejše programske opreme, ki zagotavlja večjo hitrost izvajanja in enostavno razširjanje (performance in scalability); enostavna nadgradnja in distribucija dodatnih aplikativnih modulov OPIS APLIKACIJE APPrA-O Aplikacija APPrA-O je namenjena podpori pri pripravi proračuna v občinah in posredovanju enotnih podatkov MF. Omogoča enostavno izbiranje vsebine poročil o proračunu, oblikovanje poročil, izbiranje vsebine za spreminjanje proračuna in prenos podatkov v datoteko ter shranjevanje pripravljenih poročil oziroma obrazcev. Izbiranje vsebine in oblikovanje poročil oziroma obrazcev je pripravljeno tako, da lahko končni uporabnik izdeluje poročila oziroma obrazce brez posebnega znanja o relacijskih podatkovnih bazah, poizvedovalnem jeziku SQL in podobnem. Končni uporabnik je pri svojem delu lahko osredotočen na rezultat, ki ga želi dobiti iz programa, pri tem pa ga program ne utruja z izvedbo rezultata. 3 Janez Klemenc: eporočanje finančnih podatkov občin Stran 15

26 3.4. NAMEN APLIKACIJE APPrA-O IN OPIS MODULOV Že v osnovni idejni zasnovi (I. faza) je bila izgradnja sistema APPrA-O zamišljena tako, da se ne zagotovi le sodobnejšega načina spremljanja in poročanja podatkov o realizaciji proračunov občin, ki bi le nadomestil obstoječega. Z objavo pravilnika o programski klasifikaciji izdatkov občinskih proračunov v mesecu juniju 2005 je bila občinam dana pravna podlaga za pripravo programsko usmerjenih proračunov, ki bodo primerljivi tako med seboj kot tudi z državnim proračunom. Ker je šlo za precejšnji miselni preskok v procesu priprave proračuna je MF kot pripomoček za njegovo pripravo razvilo računalniško aplikacijo, ki je omogočila poenotenje priprave vseh proračunov občin v državi. V sled temu je osnovni namen aplikacije APPrA-O informacijska podpora pri pripravi proračuna in analizah podatkov, povezanih s proračunom in spremljanje njegove realizacije. Ob zaključku I. faze je aplikacija APPrA-O vsebovala tri module za: pripravo proračuna (I. splošni in II. posebni del), pripravo načrta razvojnih programov (III. del proračuna) ter spremljanje realizacije proračuna splošnega in posebnega dela MODUL ZA PRIPRAVO PREDLOGOV PRORAČUNA Modul za pripravo predlogov proračuna aplikacije APPrA-O se uporablja kot osnovno orodje za pripravo proračuna. Aplikacija omogoča pregledovanje in spreminjanje podatkov o proračunu na poljubni ravni. Poleg tega aplikacija omogoča izpisovanje poročil po meri ter izvoze v Excel in XML datoteke za nadaljnje analize in obdelave. Možno pa je tudi tiskanje že v naprej oblikovanih standardiziranih poročil, ki so strukturirana po vzoru proračuna na državni ravni. Strukturiran pogled na proračun si vsak uporabnik izbere po svojih potrebah in željah in sicer tako, da definira ravni (nivoje) prikaza in podatkovne stolpce (sprejeti proračun, veljavni proračun, realizacija, ustrezne stopnje priprave proračuna in drugo). Pri tem lahko postavi dodatne omejitvene kriterije za vsako raven in vsak stolpec ter določi obliko nivojev in stolpcev. Potem, ko uporabnik določi vsebino prikaza ali poročila, lahko nastavitve pogleda, shrani in jih kasneje kadarkoli prikliče. Tako ima možnost, da si vnaprej določi nekaj karakterističnih pogledov in izpisov, ki jih po potrebi uporabi. Prav tako lahko uporabnik zbirko zapisov, ki zadoščajo izbranim kriterijem, shrani v Excelovo datoteko MODUL ZA SPREMLJANJE REALIZACIJE SPLOŠNEGA IN POSEBNEGA DELA PRORAČUNA Modul za spremljanje realizacije proračuna splošnega in posebnega dela je poenostavljena različica modula za pripravo predlogov proračuna. Stran 16 Janez Klemenc: eporočanje finančnih podatkov občin

27 Realizacija proračuna dejansko pomeni realizacijo sprejetega in veljavnega proračuna. Vsebina in struktura podatkov naj bi bila povsem identična,kar praviloma tudi je. Če temu ni tako, mora občina izpeljati postopek rebalansa proračuna. Glavna naloga modula je, da uporabniku omogoča več možnih načinov vnosa oziroma prenosa podatkov v aplikacijo APPrA-O iz najrazličnejših računovodskih programov, ki jih uporabljajo občine. Najelegantnejši način uvoza podatkov o realizaciji je preko tekstovne datoteke, s pomočjo katere lahko z enkratnim klikom na ustrezen ukazni gumb [Uvoz prihodkov in odhodkov iz TXT datoteke na izbrano stopnjo ] uvozimo podatke o realizaciji za izbrano obdobje. Seveda mora računovodski program tak izvoz TXT datoteke omogočati, vsebina datoteke pa mora biti sestavljena po natančno določenih pravilih (glej prilogo A) MODUL ZA PRIPRAVO NAČRTA RAZVOJNIH PROGRAMOV (NRP) Modul za pripravo NRP je iz vsebinskega in tehničnega vidika najzahtevnejši modul v aplikaciji APPrA-O. Vsebina in postopek priprave načrta razvojnih programov sta podrobneje opredeljena v 22. in 23. členu Zakona o javnih financah (Uradni list RS, št. 79/99, 124/00, 79/01, 30/02, 56/02-ZJU in 110/02-ZDT-B) ter v 25., 26. in 27. členu Uredbe o podlagah in postopkih za pripravo predloga državnega proračuna in se lahko smiselno uporabi tudi pri pripravi načrta razvojnih programov občinskega proračuna. Navedene pravne podlage so v modulu dosledno upoštevane. NRP tako predstavlja investicije in druge razvojne projekte ter državne pomoči v občini v štiriletnem obdobju oziroma do zaključka projekta v obliki konkretnih projektov oziroma programov skupaj z njihovo finančno konstrukcijo. S tem dokumentom je v proračunsko načrtovanje vključeno večletno planiranje izdatkov za te namene. V načrt razvojnih programov so vključeni odhodki, ki niso že vnaprej določeni z zakoni, temveč odražajo razvojno politiko občine (iz dokumentov dolgoročnega razvojnega načrtovanja). Projekti in programi se v NRP načrtujejo za celotno obdobje njihovega trajanja, s tem da se dopolnjujejo in potrjujejo za naslednje štiriletno obdobje ob vsaki spremembi proračuna (pri pripravi proračuna, sprememb proračuna ali rebalansa proračuna). Poseben segment NRP predstavljajo projekti in programi, za katere je predvideno sofinanciranje iz sredstev skladov kohezijske politike Evropske unije ter drugih virov Evropske unije, ki so namenjeni za posamezne razvojne prioritete. To so projekti, ki izhajajo iz dolgoročne razvojne strategije ter dolgoročnih razvojnih programov države (Državni razvojni program, Nacionalni strateški referenčni okvir, operativni programi, itd.). V NRP se izkazujejo celotne vrednosti projektov z vsemi viri financiranja. NRP izkazuje načrtovane izdatke proračuna za investicije in državne pomoči Janez Klemenc: eporočanje finančnih podatkov občin Stran 17

28 ter druge razvojne projekte in programe v prihodnjih štirih letih, ki so razdelani po: posameznih projektih ali programih neposrednih uporabnikov; letih izvedbe, v katerih bodo izdatki za projekte ali programe bremenili proračune v prihodnjem obdobju in virih financiranja za celovito izvedbo projektov ali programov, ločeno za občinske vire in druge vire (državni proračun, ostali sofinancerji). V NRP občinskega proračuna so zajeti načrtovani izdatki občinskega proračuna za investicije in državne pomoči ter druge razvojne projekte po programski in ekonomski klasifikaciji OPIS ARHITEKTURE APLIKACIJE APPrA-O Aplikacija je zasnovana kot odjemalec/strežnik in deluje na podatkovni bazi MS SQL Server 2000 ali MSDE Izbira podatkovne baze je prepuščena odločitvi posamezne občine. Uporabniški vmesnik je razvit v MS Access-u Večina poslovne logike je vgrajena v aplikacijo APPrA-O, razen nekaterih funkcij in procedur, ki so nujno potrebne na podatkovni bazi. Arhitektura odjemalec/strežnik (Client/Server) je v svoji najbolj enostavni različici sestavljena iz treh fizičnih elementov: Podatkovni strežnik - Server MS SQL server 2000 Odjemalec - Client MS Access 2003 APPrA-O (Windows NT security) APPrA-O Omrežna povezava Obrazci Poročila Občina Moduli Razredi aplikacije Slika 5: Arhitektura odjemalec/strežnik (Dežman, 2006) Podatkovni strežnik - to je zmogljiv računalnik, ki streže zahtevam odjemalcev oz. uporabnikov. Odjemalci - to so običajno osebni računalniki z uporabniškim grafičnim vmesnikom. Omrežna povezava - to so povezave (linije), po katerih se prenašajo podatki od odjemalcev k strežnikom in obratno. Uporabniki se preko LAN omrežja povežejo na podatkovni strežnik. Fizično se pri uporabnikih nahajajo: obrazci (Forms), poročila (Reports), makroji Stran 18 Janez Klemenc: eporočanje finančnih podatkov občin

29 (Macros) in moduli (Modules). V podatkovni bazi so shranjene: tabele (Tables), poizvedbe (Views), procedure (Stored Procedures), podatkovni model (Database Diagrams). Aplikacija APPrA-O uporablja za dostop do podatkovne baze objektni model ADO (ActiveX Data Objects) preko dobavitelja (Provider) OLE DB, saj ta omogoča direkten dostop do SQL strežnika. ADO Slika 6: Shematski prikaz dostopa do podatkovne baze aplikacije APPrA-O (Dežman, 2006) 3.6. POSLOVNI PROCES Poslovni proces priprave proračuna v aplikaciji APPrA-O lahko razdelimo na vsebinski in tehnični del priprave proračuna občine. Vsebinski del: Pri vsebinskem delu so občini lahko v pomoč usmeritve iz proračunskega priročnika za pripravo proračunov občin za posamezno proračunsko leto, ki je tudi javno dostopen na spletni strani MF-SSFLS 4. Le-ta naj bi služil kot delovni pripomoček pri snovanju in pripravi predloga proračuna po programski klasifikaciji, ki vsebinsko predstavlja nov pristop k poenotenju oblikovanja in sprejemanja proračunov občin. Tehnični del: Tehnični del sestave proračuna se prične z vnosom podatkov v že vnaprej pripravljene šifrante, ki so shranjeni v ločenih Excelovih datotekah ali pa kar neposredno v aplikacijo APPrA-O. Vendar se tega lotimo šele, ko nam uspe razrešiti večino vsebinskih dilem priprave proračuna po programski klasifikaciji. Obvezen vnos ali uvoz podatkov v tri šifrante: 4 Janez Klemenc: eporočanje finančnih podatkov občin Stran 19

30 o Šifrant PU (Proračunski uporabniki), o Šifrant PP (Proračunske postavke) in o Šifrant projektov - NRP. Pred pričetkom vnosa prihodkov in odhodkov proračuna je potrebno definirati stopnjo na katere se bodo vnesli podatki. Obvezen vnos ali uvoz podatkov v dve tabeli: o Tabelo Prihodkov in o Tabelo Odhodkov. Po potrebi so možni vnosi še v naslednje tri šifrante: o Šifrant K6 (Podkonti), vendar le na nivoju K7, K8, K9 in K10, o Šifrant SPP (Skupine proračunskih postavk) in o Šifrant SPU (Skupine proračunskih uporabnikov). Za vse ostale šifrante je skrbnik MF in spreminjanje s strani občin ni možno. Sem sodijo naslednji šifranti: Ekonomske klasifikacije o Šifrant K1 (Razredi), o Šifrant K2 (Skupine kontov), o Šifrant K3 (Podskupine kontov), o Šifrant K4 (Konti), o Šifrant K6 (Podkonti), predpisan do nivoja K6 in o Šifrant BLC (Bilance). Programske klasifikacije o Šifrant PPP (Področja proračunske porabe), o Šifrant GPR (Glavni programi) in o Šifrant PPR (Podprogrami). Funkcionalne klasifikacije o Šifrant COFOG2 (Področje funkcionalne dejavnosti), o Šifrant COFOG3 (Oddelek funkcionalne dejavnosti) in o Šifrant COFOG4 (Pododdelek funkcionalne dejavnosti). Institucionalne klasifikacije o Šifrant PPU (Posredni proračunski uporabniki). Načrta razvojnih programov o Šifrant virov. Občine lahko večino navedenih šifrantov posodabljajo preko komunikacije s strežnikom MF v okviru modula "Posodabljanje šifrantov", kar je podrobneje opisano v naslednjem poglavju (glej poglavje 4.3.2). Pri tem je treba upoštevati, da priprava finančnih načrtov lahko poteka v več fazah. Te faze imenujemo "stopnje" priprave proračuna. Rezultat zadnje "stopnje" je predlog proračuna, ki ga župan občine pošlje občinskemu svetu v obravnavo in potrditev. Stran 20 Janez Klemenc: eporočanje finančnih podatkov občin

31 Slika 7: Zaslonska slika vstopne maske aplikacije APPrA-O Janez Klemenc: eporočanje finančnih podatkov občin Stran 21

32 4. SPECIFIKACIJA ZAHTEV ZA IZDELAVO MODULA ZA SPLETNO eporočanje Dokument je nastal na podlagi dosedanjih izkušenj in sestankov naročnika in nominiranega podizvajalca (Aldia, d.o.o.). Opredeljuje osnovne uporabniške zahteve za izdelavo modula za spletno eporočanje, kot jih vidijo sektorji znotraj MF (sektor za proračun, za investicije, za informacijsko tehnologijo in za sistem financiranja LS) NAMEN MODULA ZA SPLETNO eporočanje Namen nadgradnje sistema APPrA-O z modulom za spletno eporočanje je v uvedbi dvosmerne komunikacije med občinami in Ministrstvom za finance. Na eni strani gre za izmenjavo podatkov o sprejetih proračunih in realizaciji le-teh vključno z NRP ter na drugi strani za možnost osveževanja različnih predpisanih šifrantov in prenašanje podatkov iz projektov NRP državnega proračuna, ki se sofinancirajo na lokalni ravni. Modul za spletno eporočanje bo v prvi različici omogočal: pošiljanje vseh treh delov proračuna iz LS na strežnik MF; kontrolo med II. in III. delom poslanega sprejetega proračuna iz LS; kontrolo konsistentnosti podatkov; sprejemanje oziroma prenos NRP iz državnega proračuna, vendar le tistih projektov, katerih sofinancer je tudi LS; sprejemanje NRP iz drugih LS, vendar le tistih projektov, katerih sofinancer je posamezna LS. Modul za spletno eporočanje mora poslovni proces podpreti tako, da: ne posega v tiste poslovne procese proračunskih uporabnikov, ki nastopajo pred posredovanjem NRP; omogoča enakopravno sodelovanje obeh partnerjev (MF in LS); odpravi potrebo po prenašanju podatkov v fizični obliki (izpisi na papirju, diskete, itd.) in večkratnem vnašanju istih podatkov; odpravi potrebo po ročnem konsolidiranju (zbiranju) podatkov več posrednih proračunskih uporabnikov; zagotovi varnost poslovanja (zaščita pred nepooblaščeno uporabo aplikacije, varen - kodiran prenos podatkov, evidentiranje in sledenje aktivnostim); v naslednjih različicah omogoči vključevanje tudi drugih blagajn javnega sektorja (ZPIZ in ZZZS) POSNETEK OBSTOJEČEGA STANJA ZAKONSKE IN DRUGE PRAVNE PODLAGE Področje javnih financ, računovodstva, javnih naročil in nadzora državnih pomoči urejajo številni predpisi. Ti predpisi se uporabljajo tako pri pripravi Stran 22 Janez Klemenc: eporočanje finančnih podatkov občin

33 državnega proračuna kot tudi pri pripravi občinskih proračunov. Njihov celovit pregled je predstavljen na spletni strani MF-SSFLS 5. Pri pripravi predloga občinskega proračuna in finančnih načrtov neposrednih in posrednih uporabnikov občine uporabijo naslednje predpise: zakon o javnih financah (Uradni list RS, št. 79/99, 124/00, 79/01, 30/02, 56/02-ZJU in 110/02-ZDT-B; v nadaljevanju: ZJF); zakon o financiranju občin (Uradni list RS, št. 123/06; v nadaljevanju ZFO-1); pravilnik o določitvi neposrednih in posrednih uporabnikov državnega in občinskih proračunov (Ur.l. RS, št. 46/03); navodilo o pripravi finančnih načrtov posrednih uporabnikov državnega in občinskih proračunov (Uradni list RS, št. 91/00 in 122/00); uredbo o podlagah in postopkih za pripravo predloga državnega proračuna (Uradni list RS, št. 45/02); odredbo o funkcionalni klasifikaciji javnofinančnih izdatkov (Uradni list RS, št. 43/00) in pravilnik o programski klasifikaciji izdatkov občinskih proračunov (Uradni list RS, št. 57/05, 88/05-popr.). Pri pripravi proračuna je potrebno upoštevati tudi podzakonske predpise zakona o računovodstvu (Uradni list RS, št. 23/99; v nadaljevanju: ZR), in sicer: pravilnik o enotnem kontnem načrtu za proračun, proračunske uporabnike in druge osebe javnega prava (Uradni list RS, št. 54/02, 117/02, 58/03, 134/03, 34/04, 75/04, 117/04,141/04 in 117/05). V delu proračuna, ki se nanaša na pripravo načrta razvojnih programov, morajo občine upoštevati: uredbo o enotni metodologiji za pripravo in obravnavo investicijske dokumentacije na področju javnih financ (Uradni list RS, št. 60/06) in zakon o spremljanju državnih pomoči (Uradni list RS, št. 37/04; v nadaljevanju: ZSDrP). Pri pripravi dokumentov proračuna, ki se nanašajo na pripravo kadrovskega načrta so občine dolžne upoštevati zakon o javnih uslužbencih (Uradni list RS, št. 32/06 - uradno prečiščeno besedilo; v nadaljevanju: ZJU-UPB2) OSNOVNE LASTNOSTI INFRASTRUKTURE Osnovne, a za izdelavo modula za spletno eporočanje zavezujoče lastnosti infrastrukture lahko strnemo v naslednje točke: 1. Komunikacijsko omrežje, ki ga bo izkoriščal modul za spletno eporočanje je privatno omrežje javne uprave HKOM. 2. Vse strežniške vire bo zagotovilo MF-SIT. Pri tem se mora modul popolnoma prilagoditi informacijskemu sistemu MF in vanj ne sme 5 Janez Klemenc: eporočanje finančnih podatkov občin Stran 23

34 posegati s tehnološkimi zahtevami, ki niso združljive z obstoječo razpoložljivo opremo. 3. Neposredne povezave med aplikacijo SAPPrA in sistemom APPrA-O z vključenim modulom za spletno eporočanje ne bo. Povezava bo možna le na podatkovnem nivoju. K točki 1: Strukturne in nastavitvene lastnosti omrežja HKOM niso v pristojnosti MF, zato se mora sistem APPrA-O omrežju HKOM popolnoma prilagoditi. Omrežni protokol, ki ga lahko izkorišča aplikacija, je TCP/IP, aplikacijski pa HTTP. To posledično pomeni, da se mora vsa komunikacija med odjemalci na lokalni ravni in strežnikom MF odvijati preko TCP vrat številka 443. Tak način komunikacije zagotavlja neproblematično vključevanje aplikacije v informacijski sistem javne uprave. Na delovnem sestanku z dne je bilo s predstavniki MF-SIT dogovorjeno, da se uporabi protokol HTTP. K točki 2: Za delovanje modula za spletno eporočanje je na voljo obstoječi podatkovni strežnik MS SQL Server 2005 in aplikacijski strežnik na osnovi MS Windows 2003 in MS IIS (Internet Information Server). Na omenjenih strežnikih že od junija 2007 testno teče sistem APPrA-O. Zagotoviti bo potrebno tudi nemoteno povezavo med podatkovnima strežnikoma: na katerem je podatkovna baza APPrA_EXT (sistem APPrA-O) in na katerem je podatkovna baza SPUP (aplikacija SAPPrA, APPrA) To povezavo zagotovi MF - SIT. K točki 3: Za potrebe priprave državnega proračuna se uporablja spletna aplikacija SAPPrA in interna okenska aplikacija APPrA, ki sta povezani na podatkovno bazo SPUP. Neposredne povezave na nivoju aplikacij (sistema APPrA-O, SAPPrA, APPrA) ne bo. Neposredne povezave med podatkovno bazo APPrA_EXT in SPUP ne bo. Za potrebe prenosa podatkov iz podatkovne baze SPUP v APPrA_EXT ali obratno se bodo uporabljale DTS procedure ali SSIS paketi. Povezave med aplikacijami se torej delajo le na nivoju podatkov - podatkovnih baz. Povezavo med podatkovnimi bazami za potrebe DTS procedur ali SSIS paketov zagotovi MF - SIT. DTS procedure oziroma SSIS pakete zagotovi izvajalec. Predvideno je, da se vse izdela z SSIS paketi. Alternativ pri izbiri arhitekture ni! SHEMA INFRASTRUKTURE MODULA ZA SPLETNO eporočanje Shema prikazuje aplikacijsko infrastrukturo, kot tudi lokacijsko delitev posameznih komponent aplikacije. Stran 24 Janez Klemenc: eporočanje finančnih podatkov občin

35 Iz sheme je razvidno, da sta aplikacijska in podatkovna plast aplikacije v domeni MF, medtem ko je odjemalska plast na strani LS. Vsi prenosi podatkov med aplikacijskim nivojem in odjemalcem potekajo v celoti znotraj privatnega omrežja HKOM in s pomočjo protokola HTTP. Slika 8: Shema arhitekture aplikacije PODATKOVNE ZAHTEVE Podatkovne zahteve so zapisane na osnovi izkušenj, ki jih je podjetje Aldia d.o.o. pridobilo v času razvoja in tehnične podpore občinam pri aplikaciji APPrA-O. Janez Klemenc: eporočanje finančnih podatkov občin Stran 25

36 Predvidene podatkovne zahteve so podane z naslednjimi količinskimi ocenami: povprečno število proračunskih vrstic v enem paketu je na posamezni LS okoli 4000; povprečno število proračunskih postavk v enem paketu je 800; povprečno število projektov v enem paketu NRP je na posamezni LS okoli 80; povprečno število proračunskih uporabnikov v enem paketu je 10; povprečno število projektov v državnem proračunu, ki sofinancirajo občinske projekte je 500; povprečno število virov financiranja za posamezni projekt LS je 8; povprečno število virov financiranja za posamezni projekt državnega proračuna je 9; število vseh občin je 210. Glede na to, da lahko dobi dovoljenje za delo več oseb iz posamezne LS, je lahko število hkratnih dostopov do aplikacijskega strežnika teoretično tudi nekoliko večje, vendar v praksi pričakujemo, da tudi v konicah ne bo več kot 100 istočasno prijavljenih uporabnikov ODZIVNI ČASI Pričakovani odzivni časi so naslednji: za shranjevanje sprememb: 10 s (pri tem predvidevamo, da se bo naenkrat shranilo več vrstic - zapisov, ne vsak posamezno); za kreiranje poročila: 30 s; za kreiranje datoteke za izvoz: 30 s; brskanje po drevesni strukturi (treeview): 3 s; prenos paketa podatkov za splošni in posebni del za posamezno občino na MF lahko traja največ 120 sekund, pri hitrosti povezave 128 kbps; prenos paketa NRP za posamezno občino na MF lahko traja največ 120 sekund, pri hitrosti povezave 128 kbps; prenos paketa NRP za posamezno občino iz strežnika MF lahko traja največ 60 sekund, pri hitrosti povezave 128 kbps TEHNIČNE ZAHTEVE Odjemalec Osnovne zahteve na strani odjemalca (občine) so: MS Windows 2000 ali novejši; APPrA-O (MS Access aplikacija); MS.NET Framework 2.0; SQL Server 2000 Client; PC Intel ali kompatibilen (Pentium 166 ali boljši); minimalno 128MB RAM-a; 10 MB prostora na trdem disku; Stran 26 Janez Klemenc: eporočanje finančnih podatkov občin

37 ločljivost ekrana vsaj 1024 x 768; minimalno 15 monitor, priporočljivo 17 monitor; minimalna hitrost omrežja (povezava s HKOM) 128 kbps Strežnik MF - SQL Server Osnovne zahteve na strani strežnika (MF) so: Microsoft Windows 2003 Server ali novejši; Microsoft SQL Server 2005 (Standardna različica); PC Intel ali kompatibilen (minimalno Pentium4 3 GHz 6 ali boljši); minimalno 4GB RAM-a 7 ; potreben prostor na trdem disku za: o Database Engine and data files, Replication, and Full-Text Search, 280 MB, o Analysis Services and data files, 90 MB, o Reporting Services and Report Manager, 120 MB o Notification Services engine components, client components, and rules components, 50 MB, o Integration Services, 120 MB, o podatkovna baza APPrA_EXT, 1 GB, trenutno 100 MB, potreben prostor na trdem disku za potrebe podatkovne baze: o o začetno stanje podatkovne baze 100 MB, predvideno povečanje podatkovne baze na 2GB v roku 2 let: 1,5 GB podatkovna datoteka, 0,5 GB LOG datoteka, ločljivost ekrana vsaj 800 x 600; minimalno 14 monitor. Specifikacija za SQL strežnik je povzeta po Microsoftovi literaturi»installing SQL Server«. 6 Po specifikaciji MS»Installing SQL server«dovolj že Pentium 166 MHz 7 Po specifikaciji MS»Installing SQL server«dovolj že 1GB Janez Klemenc: eporočanje finančnih podatkov občin Stran 27

38 UPORABNIŠKE VLOGE Uporabniške vloge so: Naziv vloge Dejavnosti, ki jih uporabnik opravlja Institucija MF uporabnik To je končni uporabnik posredovanih podatkov. Nima pravice spreminjati podatke, lahko jih le pregleduje. Vidi le tiste podatke, ki jih MF konsolidator potrdi. MF konsolidator To je uporabnik, ki sprejema posredovane podatke iz LS in v primeru ustreznosti naredi njihovo potrditev. Izdela konsolidacijo podatkov 8 iz vseh LS. Določi projekte LS, ki se v času priprave državnega proračuna prikažejo kot informacija v aplikaciji SAPPrA. Določi projekte LS, ki se morajo prenesti na ostale občine. LS uporabnik To je uporabnik sistema APPrA-O. Pripravlja podatke (proračune in realizacije), ne more pa jih pošiljati na strežnik MF. Na MF strežniku lahko pregleduje podatke. LS pošiljatelj To je uporabnik sistema APPrA-O. Pripravlja podatke (proračune in realizacije) in jih lahko pošlje na strežnik MF. Na strežniku MF lahko podatke potrjuje ali že poslane podatke briše, vendar le v primeru, da MF konsolidator še ni potrdil prejema podatkov. Sistem Z vlogo sistem je mišljen modul za spletno eporočanje, ki se nahaja na strežniku MF. MF MF LS LS MF Tabela 1: Uporabniške vloge 8 Konsolidacija podatkov ni predmet te analize in tudi modul za konsolidacijo podatkov bo narejen naknadno. Stran 28 Janez Klemenc: eporočanje finančnih podatkov občin

39 STATUSI ODDANIH PODATKOV Statusi oddanih podatkov so naslednji: Oznaka statusa ST_LS_ODD ST_MF_PRE ST_MF_PDP ST_MF_POP ST_LS_UPA Zaloga Vrednosti 0 - Nepotrjeno 1 - Potrjeno 0 - Nesprejeto 1 - Sprejeto 2 - Zavrnjeno 0 - Podatki niso namenjeni posredovanju v državni proračun 1 - Podatki se prikažejo tudi v državnem proračunu 0 - Podatki niso namenjeni posredovanju drugim LS 1 - Podatki se posredujejo tudi drugim LS 0 - Podatki niso uparjeni z II. delom proračuna 1 - Podatki so uparjeni z II. delom proračuna Namen LS pošiljatelj po pošiljanju podatkov preveri na spletni aplikaciji, če so preneseni podatki v redu. Če oceni, da so podatki pravilni postavi status na»potrjeno«, s tem preda podatke MF konsolidatorju. MF konsolidator s tem statusom označi: da so podatki vsebinsko v redu in, da je podatke prejel, da podatki vsebinsko niso v redu in jih zavrne, da podatkov še ni sprejel. MF konsolidator s tem statusom določi ali se ustrezni podatki prikažejo v aplikaciji SAPPrA v fazi priprave državnega proračuna. MF konsolidator s tem statusom določi ali se ustrezni podatki prenesejo na druge LS. LS pošiljatelj ima nalogo, da po zaključenem posredovanju II. in III. dela proračuna tudi upari podatke (povedati mora katera verzija II. dela proračuna je usklajena z verzijo III. dela proračuna). Če je uparjanje uspešno (ni bilo vsebinskih napak) potem ta status nastavimo na 1. Janez Klemenc: eporočanje finančnih podatkov občin Stran 29

40 Oznaka statusa ST_MF_UPA ST_MF_KON Zaloga Vrednosti 0 - Uparjeni podatki s strani MF konsolidatorja še niso pregledani in potrjeni 1 - Uparjeni podatki so s strani MF konsolidatorja pregledani in potrjeni 0 - Podatki niso primerni za konsolidacijio 1 - Podatki so primerni za konsolidacijo Namen MF konsolidator s tem statusom označi, da so uparjeni podatki pregledani in potrjeni. MF konsolidator s tem statusom pove, ali se podatki lahko konsolidirajo. Tabela 2: Statusi oddanih podatkov Uporabniške vloge in sprememba statusov Status\Vloga LS LS MF MF Sistem uporabnik pošiljatelj konsolidator uporabnik ST_LS_ODD R R/W R R R ST_MF_PRE R R R/W R R ST_MF_PDP R R R/W R R ST_MF_POP R R R/W R R ST_LS_UPA R R R R R/W ST_MF_UPA R R R/W R R ST_MF_KON 0 0 R/W R R Legenda: R - Samo pregled statusa (Read only) R/W - Pregled in sprememba statusa (Read/Write) 0 - Status ni viden Tabela 3: Uporabniške vloge in njihove spremembe statusov Kriteriji za spremembe statusov V navpičnem stolpcu statusov so statusi, ki jih želimo spreminjati. Lahko jih spreminjamo le v primeru, da imajo ostali statusi vrednost kakršna je prikazana pod posameznim statusom. Če vrednost ni vpisana je lahko poljubna. Stran 30 Janez Klemenc: eporočanje finančnih podatkov občin

41 Status\ Status ST_LS _ODD ST_MF _PRE ST_MF _PDP ST_MF _POP ST_LS _UPA ST_MF _UPA ST_MF _KON ST_LS_ODD ST_MF_PRE ST_MF_PDP 1 1 ST_MF_POP 1 1 ST_LS_UPA 1 1 ST_MF_UPA ST_MF_KON 1 1 Tabela 4: Kriteriji za spremembe statusov FUNKCIONALNE ZAHTEVE Funkcionalne zahteve za modul spletnega eporočanja za splošni (I. del) in posebni (II. del) proračuna Oznaka Funkcija Opomba Vrsta F1 Pregled podatkov F1.1 Pregled lastnih podatkov Posamezna LS ima lahko dostop le do svojih poslanih podatkov. F1.2 Pregled LS bodo dostopale do vseh podatkov o šifrantov, ki jih predpiše MF. šifrantih in To so: posodabljanje Šifranti ekonomske klasifikacije, šifrantov na Šifranti programske klasifikacije, zahtevo Šifranti funkcionalne uporabnika klasifikacije. Uporabnik lahko zahteva posodabljanje predpisanih šifrantov, ki se mora izvesti preko WS (Spletne storitve). F1.3 Pregled sporočil MF konsolidator lahko posamezni občini pošlje sporočilo. Občine morajo imeti možnost pregledovanja teh sporočil. F1.4 Pregled prejetih podatkov - MF Uporabniki na MF imajo dostop do vseh podatkov, katere so LS poslale na strežnik MF in jim je MF konsolidator nastavil ustrezne statuse. W, WS, PB W W, WS W PB Janez Klemenc: eporočanje finančnih podatkov občin Stran 31

42 Oznaka Funkcija Opomba Vrsta F1.5 Tiskanje Izpis posredovanih podatkov po standardnih izpisih: Splošni del proračuna in Posebni del proračuna. Pri obeh izpisih mora biti na voljo izbira valute in nivo do katerega želimo podatke izpisati. Nivo do katerega želimo podatke izpisati je lahko; K3 ali K4 ali K6. F2 Prenos iz LS na MF F2.1 Prenos šifranta PU F2.2 Prenos šifranta PP F2.3 Prenos prihodkov F2.4 Prenos odhodkov F2.5 Prenos definicije stopnje F2.6 Prenos ostalih podatkov Prenos podatkov posameznega proračuna ali realizacije iz LS na strežnik MF. Prenesemo šifrant proračunskih uporabnikov iz LS na strežnik MF. Prenesemo šifrant proračunskih postavk iz LS na strežnik MF. Prenos tabele prihodkov za izbrano stopnjo na nivoju: Podkonto (K6) in Vrednost. Prenos tabele odhodkov za izbrano stopnjo na nivoju: Proračunska postavka (PP), Podkonto (K6) in Vrednost. Prenos vseh atributov na izbrani stopnji. Ti atributi so: Identifikacija stopnje, Oznaka stopnje, Naziv stopnje, Valuta v kateri so podatki, Tečaj stopnje (1 EUR = 239,6400 SIT), Stanje sredstev na dan - DATUM, Stanje sredstev na dan - VREDNOST, Obdobje od - DATUM in Obdobje do - DATUM. Prenos ostalih podatkov: Pošiljatelj in Telefonska številka pošiljatelja. W WS, Client WS, Client WS, Client WS, Client WS, Client WS, Client WS, Client Stran 32 Janez Klemenc: eporočanje finančnih podatkov občin

43 Oznaka Funkcija Opomba Vrsta F9 Splošne funkcionalnost i F9.1 SF brisanje Možnost brisanja podatkov: V primeru, da so posredovani podatki potrjeni samo s strani LS pošiljatelja, potem lahko LS pošiljatelj posredovane podatke zbriše. V primeru, da so posredovani podatki potrjeni s strani LS pošiljatelja in MF konsolidatorja, se podatki ne morejo brisati, dokler MF konsolidator ne odstrani statusa prejema podatkov. Posredovane podatke lahko F9.2 SF potrjevanje, statusi Legenda: briše le LS pošiljatelj. Potrjevanje poslanih podatkov in sprememba statusov v skladu s tabelo»kriteriji za spremembo statusov«w - spletna aplikacija WS - spletna storitev Client - klient na strani Windows aplikacije, ki skrbi za pošiljanje podatkov PB - podatkovna baza Tabela 5: Funkcionalne zahteve za splošni in posebni proračuna Primer izpisa posredovanih podatkov Izpis je vedno v ležeči obliki - Splošni del, do nivoja K4: W W Slika 9: Primer izpisa splošnega dela proračuna Janez Klemenc: eporočanje finančnih podatkov občin Stran 33

44 Posebni del do nivoja K3: Slika 10: Primer izpisa posebnega dela proračuna Funkcionalne zahteve za modul spletnega eporočanja III. dela proračuna - NRP Oznaka Funkcija Opomba Vrsta F1 Pregled podatkov F1.1 Pregled lastnih podatkov F1.2 Pregled podatkov drugih LS F1.3 Pregled podatkov državnega proračuna F1.4 Pregled prejetih podatkov - MF Posamezna LS ima lahko dostop le do svojih poslanih podatkov. Posamezna LS ima lahko dostop tudi do tistih podatkov, ki so del sofinanciranja z drugo LS. Posamezna LS ima lahko dostop tudi do tistih podatkov iz državnega NRPja, ki so del sofinanciranja skupnih projektov. Uporabniki na MF imajo dostop do vseh podatkov, katere so LS poslale na strežnik MF in jim je MF konsolidator nastavil ustrezne statuse. W, WS, PB W WS, W WS, W PB Stran 34 Janez Klemenc: eporočanje finančnih podatkov občin

45 Oznaka Funkcija Opomba Vrsta F1.5 Tiskanje Izpis posredovanih podatkov po nivojih: PPP/GPR/PPR/PRJ/Viri Z naslednjimi stolpci: Vrednost projekta, Začetek in konec financiranja, Pred L0, L0... L3, Po L3. Uporabnik mora imeti možnost izbire: L0, Valute: SIT ali EUR. Izpis je prikazan na koncu te tabele. F2 Prenos iz LS Prenos NRP iz LS na strežnik MF na MF F2.1 Prenos iz LS na MF - atributi stopnje F2.2 Prenos iz LS na MF - atributi F2.3 Prenos iz LS na MF - DIN PV pomeni. Prenos atributov o posameznem paketu NRP (ena NRP stopnja). Prenos vseh atributov posameznega projekta. Prenos PV: lastna sredstva, sredstva pridobljena neposredno iz EU, sredstva pridobljena preko transfera iz državnega proračuna, sredstva pridobljena preko transfera iz druge LS. W WS, Client WS, Client WS, Client WS, Client Osnovni nivo prenosa podatkov v dinamiki proračunskih virov je LETO, PRJ, PP, K6 s potrebnimi dodatnimi atributi (kredit, šifra občine, šifra državnega proračunskega uporabnika, itd.). Poleg identifikacije proračunske postavke je potrebno prenesti še: naziv proračunske postavke, identifikacijo podprograma v katerega spada proračunska postavka. Janez Klemenc: eporočanje finančnih podatkov občin Stran 35

46 Oznaka Funkcija Opomba Vrsta F2.4 Prenos iz LS na MF - DIN OV F3 Prenos projekta iz DP v proračun LS F3.1 Prenos projekta iz DP v proračun LS - atributi stopnje F3.2 Prenos projekta iz DP v proračun LS - atributi projekta F3.3 Prenos projekta iz DP v proračun LS - DIN PV Prenos OV: domači partnerji, tuji partnerji, sredstva posrednih proračunskih uporabnikov - PPU, sredstva drugih LS. Osnovni nivo prenosa podatkov v dinamiki ostalih virov je LETO, PRJ s potrebnimi dodatnimi atributi (občina, davčna številka, naziv partnerja, itd.). Prenos atributov o stopnji na kateri so vpisani projekti, ki se bodo prenesli na LS. Prenos vseh atributov projekta. Prenos proračunskih virov. Proračunska sredstva v celoti, ne glede na to, da je lahko skrbnik projekta različen od skrbnika PP. Osnovni nivo prenosa podatkov v dinamiki proračunskih virov je LETO, PRJ, PP, K6 s potrebnimi dodatnimi atributi. Poleg identifikacije proračunske postavke je potrebno prenesti še: naziv proračunske postavke, identifikacijo podprograma v katerega spada proračunska postavka, identifikacijo in naziv proračunskega uporabnika ki je lastnik PP, identifikacijo in naziv tipa proračunske postavke WS, Client WS, Client WS, Client WS, Client WS, Client Stran 36 Janez Klemenc: eporočanje finančnih podatkov občin

47 Oznaka Funkcija Opomba Vrsta F3.4 Prenos projekta iz DP v proračun LS DIN OV F4 Prenos projekta iz LS 1 na LS 2 F4.1 Prenos projekta iz LS 1 na LS 2 - atributi stopnje F4.2 Prenos projekta iz LS 1 na LS 2 - atributi projekta F4.3 Prenos projekta iz LS 1 na LS 2 - DIN PV Prenos ostalih virov: ostali partnerji, transferi posameznim občinam, skladi. Osnovni nivo prenosa podatkov v dinamiki ostalih virov je LETO, PRJ s potrebnimi dodatnimi atributi (občina, davčna številka, naziv partnerja, itd.). Prenos atributov o posameznem paketu NRP (ena NRP stopnja). Prenos vseh atributov posameznega projekta. Prenos PV: lastna sredstva, sredstva pridobljena neposredno iz EU, sredstva pridobljena preko transfera iz državnega proračuna, sredstva pridobljena preko transfera iz druge LS. Osnovni nivo prenosa podatkov v dinamiki proračunskih virov je LETO, PRJ, PP, K6 s potrebnimi dodatnimi atributi (kredit, šifra občine, šifra državnega proračunskega uporabnika, itd.). Poleg identifikacije proračunske postavke je potrebno prenesti še: naziv proračunske postavke, identifikacijo podprograma v katerega spada proračunska postavka. WS, Client WS, Client WS, Client WS, Client WS, Client Janez Klemenc: eporočanje finančnih podatkov občin Stran 37

48 Oznaka Funkcija Opomba Vrsta F4.4 Prenos projekta iz LS 1 na LS 2 - DIN OV Prenos OV: domači partnerji, tuji partnerji, sredstva posrednih proračunskih uporabnikov - PPU, sredstva drugih LS. WS, Client F5 F9 Uparjanje z II. delom proračuna in kontrola podatkov Splošne funkcionalnosti Osnovni nivo prenosa podatkov v dinamiki ostalih virov je LETO, PRJ s potrebnimi dodatnimi atributi (občina, davčna številka, naziv partnerja, itd.). Vloga»Pošiljatelj LS«mora imeti možnost uparjanja podatkov II. dela proračuna in III. dela proračuna. To naredi tako, da izbere paket poslanih podatkov iz II. dela in paket poslanih podatkov iz III. dela proračuna. Aplikacija mora preveriti podatke, kot je to zapisano v kontroli K2. F9.1 SF informacija Prenos posameznega projekta, naj si bo iz državnega NRPja ali iz NRPja druge LS, na LS pomeni, da se prenese le kot informacija in LS, ki prejme podatke o sofinancerskem projektu, teh podatkov ne sme spreminjati. F9.2 SF brisanje Možnost brisanja podatkov: V primeru, da so posredovani podatki potrjeni samo s strani LS pošiljatelja, potem lahko LS pošiljatelj posredovane podatke zbriše. V primeru, da so posredovani podatki potrjeni s strani LS pošiljatelja in MF konsolidatorja, se podatki ne morejo brisati, dokler MF konsolidator ne odstrani statusa prejema podatkov. Posredovane podatke lahko briše le LS pošiljatelj. W W Stran 38 Janez Klemenc: eporočanje finančnih podatkov občin

49 Oznaka Funkcija Opomba Vrsta F9.3 SF potrjevanje, statusi Legenda: W - spletna aplikacija WS - spletna storitev PB - podatkovna baza Potrjevanje poslanih podatkov in sprememba statusov v skladu s tabelo»kriteriji za spremembo statusov«. W Tabela 6: Funkcionalne zahteve III. dela proračuna - NRP Primer izpisa posredovanih podatkov Izpis je vedno v ležeči obliki. Slika 11: Primer izpisa načrta razvojnih programov Janez Klemenc: eporočanje finančnih podatkov občin Stran 39

50 LOGIČNI FUNKCIJSKI MODEL Logični funkcijski model za modul spletnega eporočanja za splošni (I. del) in posebni (II. del) proračuna Slika 12: Logični funkcijski model za splošni in posebni proračuna Stran 40 Janez Klemenc: eporočanje finančnih podatkov občin

51 Logični funkcijski model za modul spletnega eporočanja III. dela proračuna - NRP Slika 13: Logični funkcijski model III. dela proračuna - NRP Janez Klemenc: eporočanje finančnih podatkov občin Stran 41

52 PREVERJANJE PODATKOV - KONTROLE Preverjanje podatkov - kontrole za modul spletnega eporočanja za splošni (I. del) in posebni (II. del) proračuna Oznaka Naziv Opis K1 Sprejemanje podatkov iz LS K1.1 Podvojena proračunska vrstica K1.2 Referenčna integriteta PP K1.3 Referenčna integriteta K6 K1.4 Referenčna integriteta PP- PPR K1.5 Referenčna integriteta PP- COFOG K1.6 Referenčna integriteta PP- PU V enem paketu ne sme biti podvojene proračunske vrstice 9. Vse proračunske postavke, ki jih vsebuje paket odhodkov morajo predhodno biti zapisane v šifrantu PP. Vsi podkonti, ki so uporabljeni v paketu odhodkov ali prihodkov morajo obstajati v šifrantu K6. Kontrola referenčne integritete med šifrantom proračunskih postavk, ki ga sestavlja LS in šifrantom podprogramov, ki ga predpiše MF. Kontrola referenčne integritete med šifrantom proračunskih postavk, ki ga sestavlja LS in šifrantom funkcionalne klasifikacije (COFOG4), ki ga predpiše MF. Kontrola referenčne integritete med šifrantom proračunskih postavk, ki ga sestavlja LS in šifrantom proračunskih uporabnikov, ki ga sestavlja LS. K1.7 Vrednost ODH Vrednost odhodkov mora biti nič ali večja od nič. K1.8 Vrednost PRI Vrednost prihodkov je lahko negativna le na podkontu za dohodnino. Vse ostale vrednosti morajo biti pozitivne ali nič. K1.9 Kontrola ID Občine Preveriti je potrebno če ima občina pravilno vpisano identifikacijo. Ob napačni identifikaciji uporabnika opozoriti o napaki. Preverjanje naj se izvede dvonivojsko: na strani klienta in na strani spletne aplikacije. Na strani klienta preverjamo če je vpisana identifikacija v šifrantu občin. Na strani spletne aplikacije preverimo če ima fizični uporabnik ki pošilja podatke pravice za pošiljanje pod nastavljeno identifikacijo. Opomba: Kontrole lahko imajo naslednje vrednosti: 0 - izključeno, 1 - vključeno, 2 -vključeno kot opozorilo. Tabela 7: Preverjanje podatkov - kontrole za splošni in posebni proračuna 9 Proračunsko vrstico predstavlja par: proračunska postavka (PP) in podkonto (K6) Stran 42 Janez Klemenc: eporočanje finančnih podatkov občin

53 Preverjanje podatkov - kontrole za modul spletnega eporočanja III. dela proračuna - NRP Oznaka Naziv Opis K1 Sprejemanje podatkov iz LS K1.1 Podvojena šifra projekta K1.2 Kratek naziv projekta K1.3 Tip projekta (vrsta) K1.4 Datum začetek V enem paketu ne sme biti podvojene identifikacije projekta (PROJEKT_ID). Kratek naziv projekta je obvezen podatek in ne sme biti daljši od 50 znakov. Tip projekta je obvezen podatek in je lahko le ena izmed vrednosti: INV - Druge investicije, INVG - Investicija z gradnjo, INVV - Investicijsko vzdrževanje, INVVG - Investicijsko vzdrževanje z gradnjo, NINV - Ni investicija. Atribut datum začetek financiranja je obvezen podatek in ne sme biti manjši od DAT_ZAC_FIN_MIN in ne večji od DAT_ZAC_FIN_MAX. K1.5 Datum konca Atribut datum konec financiranja je obvezen podatek in ne sme biti manjši od DAT_KON_FIN_MIN in ne večji od DAT_KON_FIN_MAX. K1.6 Vrednost PRJ Vrednost projekta mora biti vpisana in mora biti nič ali večja od nič. K1.7 Vrednost PV PRJ K1.8 Vrednost OV PRJ K1.9 Preverjanje šifre Vrednost proračunskih virov projekta mora biti vpisana in mora biti nič ali večja od nič. Vrednost ostalih virov projekta mora biti vpisana in mora biti nič ali večja od nič. Identifikacija oziroma šifra projekta, mora biti sestavljena takole: Identifikacija - Leto - Zaporedna občine številka O B X X X - L L - Y Y Y Y OB - Oznaka, da je projekt vpisan na nivoju občine (potrebno zaradi kasnejšega povezovanja z državnim NRP). XXX - Številka (identifikacija) občine. LL - Dvomestna številka leta v katerem je bil projekt vpisan v šifrant. YYYY - Zaporedna številka projekta v letu. K1.10 Dinamika leto Vrednost leta v dinamiki virov je lahko med DIN_LETO_MIN in DIN_LETO_MAX, vključno s tema dvema vrednostma. Janez Klemenc: eporočanje finančnih podatkov občin Stran 43

54 Oznaka Naziv Opis K1.11 Vrednost LETO min Dinamika financiranja ne sme biti vpisana pred leto Datuma začetka financiranja. K1.12 Vrednost LETO max Dinamika financiranja ne sme biti vpisana po letu Datuma konca financiranja. K1.13 Vrednost PRJ Seštevek vrednosti virov v dinamiki financiranja mora biti enak atributu Vrednost projekta. Dopuščamo absolutno napako TOLERANCA_PRJ. K1.14 Vrednost PV Seštevek vrednosti proračunskih virov mora biti enak atributu Vrednost proračunskih virov. Dopuščamo absolutno napako TOLERANCA_PRJ. K1.15 Vrednost OV Seštevek vrednosti ostalih virov mora biti enak atributu Vrednost ostalih virov. Dopuščamo absolutno napako TOLERANCA_PRJ. K1.16 Nosilni PPR Nosilni podprogram je obvezen podatek in mora biti različen od ' '. K1.17 KD1 Datum začetka financiranja mora biti manjši od datuma konca financiranja. K1.18 KD2 Datum DIP je pri vrsti projekta INV obvezen. K1.19 KD3 Datum zaključek programa je pri vrsti projekta INV obvezen, če je vrednost projekta nad KONT_VREDNOST1. K1.20 KD4 Datum investicijskega programa je pri vrsti projekta INV obvezen, kadar projekt presega vrednost KONT_VREDNOST2. K1.21 KD5 Datum predinvesticijske zasnove je pri vrsti projekta INV obvezen, kadar projekt presega vrednost KONT_VREDNOST3. K1.22 KD6 Datum DIP je pri vrsti projekta INVG obvezen, če je vrednost projekta nad KONT_VREDNOST1. K1.23 KD7 Datum začetek del je pri vrsti projekta INVG obvezen, če je vrednost projekta nad KONT_VREDNOST1. K1.24 KD6 Datum končnega obračuna je pri vrsti projekta INVG obvezen, če je vrednost projekta nad KONT_VREDNOST1. K1.25 KD7 Datum investicijskega programa je pri vrsti projekta INVG obvezen, kadar projekt presega vrednost KONT_VREDNOST2. K1.26 KD8 Datum predinvesticijske zasnove je pri vrsti projekta INVG obvezen, kadar projekt presega vrednost KONT_VREDNOST3. Stran 44 Janez Klemenc: eporočanje finančnih podatkov občin

55 Oznaka Naziv Opis K1.27 KD9 Datum DIP je pri vrsti projekta INVV obvezen, če je vrednost projekta nad KONT_VREDNOST1. K1.28 KD10 Datum zaključek programa je pri vrsti projekta INVV obvezen, če je vrednost projekta nad KONT_VREDNOST1. K1.29 KD11 Datum investicijskega programa je pri vrsti projekta INVV obvezen, kadar projekt presega vrednost KONT_VREDNOST2. K1.30 KD12 Datum predinvesticijske zasnove je pri vrsti projekta INVV obvezen, kadar projekt presega vrednost KONT_VREDNOST3. K1.31 KD13 Datum DIP je pri vrsti projekta INVVG obvezen, če je vrednost projekta nad KONT_VREDNOST1. K1.32 KD14 Datum končnega obračuna je pri vrsti projekta INVVG obvezen, če je vrednost projekta nad KONT_VREDNOST1. K1.33 KD15 Datum investicijskega programa je pri vrsti projekta INVVG obvezen, kadar projekt presega vrednost KONT_VREDNOST2. K1.34 KD16 Datum predinvesticijske zasnove je pri vrsti projekta INVVG obvezen, kadar projekt presega vrednost KONT_VREDNOST3. K1.35 KD17 Datum DIP je pri vrsti projekta NINV obvezen, če je vrednost projekta nad KONT_VREDNOST1. K2 Kontrola med II. in III. delom proračuna K2.1 Vrednost SUM K2.2 Vrednost INV Kontov K2.3 Vrednost PP,K6 Vse spodaj naštete kontrole se opravljajo na nivoju posameznega proračunskega leta. Vrednost odhodkov II. dela proračuna mora biti večja ali enaka vrednosti odhodkov III. dela proračuna v posameznem letu. Dopuščamo absolutno napako TOLERANCA_SUM. Vrednost investicijskih kontov (42*, 43* in 410*) mora biti v II. delu proračuna enaka kot v III. delu proračuna. Dopuščamo absolutno napako TOLERANCA_SUM. Vrednost proračunske vrstice II. dela proračuna je lahko večja ali enaka kot je vrednost proračunske vrstice v III. delu proračuna. Opomba: Kontrole lahko imajo naslednje vrednosti: 0 - izključeno, 1 - vključeno, 2 -vključeno kot opozorilo. Tabela 8: Preverjanje podatkov - kontrole III. dela proračuna - NRP Janez Klemenc: eporočanje finančnih podatkov občin Stran 45

56 NASTAVITVE APLIKACIJE Oznaka Opis DAT_MIN Najmanjša dovoljena vrednost za datum, ki je zapisan na definiciji stopnje. DAT_MAX Maksimalna vrednost za datum, ki je zapisan na definiciji stopnje. DAT_ZAC_FIN_MIN Najmanjša dovoljena vrednost za datum začetek financiranja. DAT_ZAC_FIN_MAX Največja dovoljena vrednost za datum začetek financiranja. DAT_KON_FIN_MIN Najmanjša dovoljena vrednost za datum konec financiranja. DAT_KON_FIN_MAX Največja dovoljena vrednost za datum konec financiranja. DIN_LETO_MIN Minimalna vrednost leta v dinamiki financiranja. DIN_LETO_MAX Maksimalna vrednost leta v dinamiki financiranja. TOLERANCA_SUM Maksimalna toleranca, ki jo dopuščamo pri preverjanju podatkov. TOLERANCA_PRJ Maksimalna toleranca, ki jo dopuščamo na posameznem projektu. KONT_VREDNOST1 Vrednost 1 za kontrole datumov. KONT_VREDNOST2 Vrednost 2 za kontrole datumov. KONT_VREDNOST3 Vrednost 3 za kontrole datumov. Opomba: Poleg teh nastavitev so še nastavitve kontrol. Kontrole lahko imajo naslednje vrednosti: 0 - izključeno, 1 - vključeno, 2 - vključeno kot opozorilo. Tabela 9: Nastavitve aplikacije Stran 46 Janez Klemenc: eporočanje finančnih podatkov občin

57 LOGIČNI PODATKOVNI MODEL ZA MODUL SPLETNEGA eporočanja ZA SPLOŠNI (I. DEL) IN POSEBNI (II. DEL) PRORAČUNA Odhodki Slika 14: Logični podatkovni model za splošni in posebni proračuna - Odhodki Janez Klemenc: eporočanje finančnih podatkov občin Stran 47

58 Prihodki Proračunska vrstica (PRIHODKI) K6_ID Podkonto K6_ID Konto K4_ID Podskupina kontov K3_ID Skupina kontov K2_ID Bilanca BLC_ID Razred K1_ID Slika 15: Logični podatkovni model za splošni in posebni proračuna - Prihodki Stran 48 Janez Klemenc: eporočanje finančnih podatkov občin

59 LOGIČNI PODATKOVNI MODEL ZA MODUL SPLETNEGA eporočanja III. DELA PRORAČUNA - NRP Predstavljen je logični podatkovni model, ki ga lokalne skupnosti uporabljajo za Načrt razvojnih programov Splošni model Slika 16: Logični podatkovni model III. dela proračuna - NRP - Splošni model Janez Klemenc: eporočanje finančnih podatkov občin Stran 49

60 Atributi projekta Slika 17: Logični podatkovni model III. dela proračuna - NRP - Atributi projekta Šifrant proračunskih uporabnikov je prikazan dvakrat: proračunski uporabniki (PU_ID); to so proračunski uporabniki znotraj posamezne lokalne skupnosti; šifrant PU DP (PU_DP_ID); to so neposredni proračunski uporabniki državnega proračuna. Stran 50 Janez Klemenc: eporočanje finančnih podatkov občin

61 Dinamika PV - Lastna sredstva Slika 18: Logični podatkovni model III. dela proračuna - NRP - Dinamika PV - Lastna sredstva Janez Klemenc: eporočanje finančnih podatkov občin Stran 51

62 Dinamika PV - Transfer iz državnega proračuna Slika 19: Logični podatkovni model III. dela proračuna - NRP - Dinamika PV - Transfer iz državnega proračuna Stran 52 Janez Klemenc: eporočanje finančnih podatkov občin

63 Dinamika PV - Evropska sredstva Slika 20: Logični podatkovni model III. dela proračuna - NRP - Dinamika PV - Evropska sredstva Janez Klemenc: eporočanje finančnih podatkov občin Stran 53

64 Dinamika OV - Druge občine Slika 21: Logični podatkovni model III. dela proračuna - NRP - Dinamika OV - Druge občine Dinamika OV - Posredni proračunski uporabniki Slika 22: Logični podatkovni model III. dela proračuna - NRP - Dinamika OV - Posredni proračunski uporabniki Stran 54 Janez Klemenc: eporočanje finančnih podatkov občin

65 Dinamika OV - Domači partnerji Slika 23: Logični podatkovni model III. dela proračuna - NRP - Dinamika OV - Domači partnerji Dinamika OV - Tuji partnerji Slika 24: Logični podatkovni model III. dela proračuna - NRP - Dinamika OV - Tuji partnerji Janez Klemenc: eporočanje finančnih podatkov občin Stran 55

66 PROCESI Procesa za modul spletnega eporočanja za splošni (I. del) in posebni (II. del) proračuna Proces pošiljanja podatkov iz LS na MF LS pošiljatelj APPrA-O OPPrA Client LS pošiljatelj Modul za spletno eporočanje MF konsolidator MF uporabnik Izbira stopnje, ki jo pošiljatelj želi poslati na MF strežnik Osnovno preverjanje podatkov na izbrani stopnji in priprava podatkov Pregled poslanih podatkov Pošiljanje na MF strežnik Potrditev ali preklic poslanih podatkov Potrjeno? NE Brisanje poslanih podatkov DA Pregled in potrditev o prejemu Konec Potrjeno MF? Vpisati razlog zavrnitve DA I. Splošni del proračuna II. posebni del proračuna za posamezno lokalno skupnost Slika 25: Proces za splošni in posebni proračuna - Proces pošiljanja podatkov iz LS na MF Stran 56 Janez Klemenc: eporočanje finančnih podatkov občin

67 Slika 26: Proces za splošni in posebni proračuna - Proces posodabljanja šifrantov Janez Klemenc: eporočanje finančnih podatkov občin Stran 57

68 Procesa za modul spletnega eporočanja III. dela proračuna - NRP Proces pošiljanja podatkov iz LS na MF LS pošiljatelj APPrA-O OPPrA Client LS pošiljatelj Spletna aplik. OPPrA-NRP MF konsolidator MF uporabnik Izbira NRP stopnje, ki jo pošiljatelj želi poslati na MF strežnik Osnovno preverje podatkov na izbrani stopnji in priprava podatkov Pregled poslanih podatkov Pošiljanje na MF strežnik Potrditev ali preklic poslanih podatkov Potrjeno? DA NE Brisanje poslanih podatkov DA Pregled in potrditev o prejemu Konec Uparjanje z II. delom proračuna Potrjeno MF? DA NRP lokalne skupnosti Preverjanje II. in III. dela proračuna, ki jih pošiljatelj upari Vpisati razlog zavrnitve Ali obstajajo napake? Izpis napak NE Pregled in potrditev uparjanja I., II. in III. del proračuna lokalne skupnosti Slika 27: Proces III. dela proračuna - NRP - Proces pošiljanja podatkov iz LS na MF Stran 58 Janez Klemenc: eporočanje finančnih podatkov občin

69 Slika 28: Proces III. dela proračuna - NRP - Proces pošiljanja podatkov iz MF na LS Janez Klemenc: eporočanje finančnih podatkov občin Stran 59

70 4.3. TEHNIČNA NAVODILA ZA IZDELAVO MODULA ZA SPLETNO eporočanje PRENOS PODATKOV IZ LS NA STREŽNIK MF ZA SPLOŠNI (I. DEL) IN POSEBNI (II. DEL) PRORAČUNA Postopek: 1. Uporabnik v aplikaciji APPrA-O izbere meni Nastavitve Stopnje II. dela proračuna - Posebni del. 2. Izbere ustrezno stopnjo, ki jo želi poslati na strežnik MF. 3. Klikne gumb»pošlji podatke za izbrano stopnjo na strežnik MF«- kliče se OPPrA_Client z ustreznimi parametri. Slika 29: Zaslonska slika vnosne maske "Stopnje proračunov" Ob kliku na omenjeni gumb se zberejo podatki iz naslednjih tabel: Opis vsebine tabele Naziv tabele Šifrant proračunskih uporabnikov tblpu Šifrant proračunskih postavk tblpp Tabela odhodkov tblprp_odh Tabela prihodkov tblprp_pri Podatki o stopnji I. in II. dela proračuna tbl_sys_stopnje Opomba: Lastnik vseh tabel je uporabnik 'dbo'. Podatkovna baza na lokalni skupnosti je zgrajena na podatkovnem strežniku MS SQL Server Tabela 10: Seznam tabel iz katerih se zberejo podatki splošnega in posebnega dela proračuna za prenos na strežnik MF Podatki iz tabel: prihodkov in odhodkov se morajo filtrirati po atributu STP. Primer: Če uporabnik izbere stopnjo z identifikacijo 2 se morajo tabele filtrirati z WHERE stavkom: SELECT * FROM dbo.tblprp_odh WHERE STP=2 Izjema: Šifranti se ne filtrirajo! Stran 60 Janez Klemenc: eporočanje finančnih podatkov občin

71 ER diagram podatkovne baze na posamezni občini za splošni (I. del) in posebni (II. del) proračuna je prikazan v prilogi B. Zbrani podatki se pošljejo na strežnik MF v naslednje tabele: Opis vsebine tabele Naziv tabele Šifrant proračunskih uporabnikov APPrA_DATA_Obcine.tblPU Šifrant proračunskih postavk APPrA_DATA_Obcine.tblPP Tabela odhodkov APPrA_DATA_Obcine.tblPRP_ODH Tabela prihodkov APPrA_DATA_Obcine.tblPRP_PRI Podatki o stopnji I. in II. dela prorač. APPrA_DATA_Obcine.tblVERZIJE Opomba: Lastnik vseh tabel je uporabnik 'dbo', vse tabele se nahajajo v shemi APPrA_DATA_Obcine. Podatkovna baza na strežniku MF je zgrajena na podatkovnem strežniku MS SQL Server Tabela 11: Seznam tabel na strežniku MF v katere se prenesejo podatki splošnega in posebnega dela proračuna Na strežniku MF se v tabelo [APPrA_DATA_Obcine.tblVERZIJE] doda nova vrstica, da pridobimo novo identifikacijsko številko (ID) v stolpcu [VERZIJA_ID]. Pod to ID shranjujemo vse podatke v omenjene tabele. Funkcije, ki jih opravlja OPPrA_Client pri pošiljanju podatkov na strežnik MF, so: zbere podatke iz ustreznih tabel; posreduje podatke spletnemu servisu, ki je del aplikacije OPPrA. Funkcije, ki jih opravlja spletni servis na aplikaciji OPPrA v zvezi s posredovanjem podatkov iz občine na strežnik MF: zbere ustrezne podatke, ki jih posreduje OPPrA_Client; zapiše zbrane podatke v prej omenjene tabele na podatkovni bazi APPrA_EXT. Funkcije, ki jih opravlja spletna aplikacija OPPrA v zvezi s posredovanimi podatki: pregled posredovanih podatkov; spremembe na statusih posredovanih podatkov; izpis I. in II. dela proračuna, kot je to določeno z Zakonom o javnih financah PRENOS PODATKOV ZA POSODABLJANJE ŠIFRANTOV IZ STREŽNIKA MF NA LS Iz strežnika MF se na LS prenašajo le šifranti predpisani s strani MF. To so šifranti: ekonomske klasifikacije (K1, K2, K3, K4, K6), programske klasifikacije (PPP, GPR, PPR) in funkcionalne klasifikacije (COFOG2, COFOG3, COFOG4). Janez Klemenc: eporočanje finančnih podatkov občin Stran 61

72 Postopek: 1. Uporabnik v aplikaciji APPrA-O izbere meni Nastavitve Komunikacija s strežnikom MF Posodabljanje šifrantov. 2. Izbere katere šifrante želi posodobiti preko strežnika MF, lahko izbere vse ali le posamezne šifrante. 3. Klikne gumb»posodobi šifrante«- kliče se OPPrA_Client z ustreznimi parametri. Slika 30: Zaslonska slika vnosne maske "Posodabljanje šifrantov" Ob kliku na omenjeni gumb se zberejo in posodobijo podatki le iz predpisanih šifrantov MF iz naslednjih tabel: Opis vsebine tabele Naziv tabele Šifrant ekonomske klasifikacije - razredi tblk1 Šifrant ekonomske klasifikacije - skupine kontov tblk2 Šifrant ekonomske klasifikacije - podskupine kontov tblk3 Šifrant ekonomske klasifikacije - konti tblk4 Šifrant ekonomske klasifikacije - podkonti tblk6 Šifrant programske klasifikacije - področja prorač. porabe tblppp Šifrant programske klasifikacije - glavni programi tblgpr Šifrant programske klasifikacije - podprogrami tblppr Šifrant funkcionalne klasifikacije - COFOG tblcofog Opomba: Lastnik vseh tabel je uporabnik 'dbo'. Podatkovna baza na lokalni skupnosti je zgrajena na podatkovnem strežniku MS SQL Server Tabela 12: Seznam tabel oziroma šifrantov v LS, ki se posodobijo na zahtevo uporabnika preko strežnika MF ER diagram podatkovne baze na posamezni občini za posodabljanje šifrantov preko strežnika MF je prikazan v prilogi B. Opis vsebine tabele Šifrant ekonomske klasifikacije - razredi Šifrant ekonomske klasifikacije - skupine kontov Naziv tabele APPrA_DATA_Obcine.tblK1 APPrA_DATA_Obcine.tblK2 Stran 62 Janez Klemenc: eporočanje finančnih podatkov občin

73 Opis vsebine tabele Naziv tabele Šifrant ekonomske klasifikacije - APPrA_DATA_Obcine.tblK3 podskupine kontov Šifrant ekonomske klasifikacije - konti APPrA_DATA_Obcine.tblK4 Šifrant ekonomske klasifikacije - podkonti APPrA_DATA_Obcine.tblK6 Šifrant programske klasifikacije - področja APPrA_DATA_Obcine.tblPPP proračunske porabe Šifrant programske klasifikacije - glavni APPrA_DATA_Obcine.tblGPR programi Šifrant programske klasifikacije - APPrA_DATA_Obcine.tblPPR podprogrami Šifrant funkcionalne klasifikacije - COFOG APPrA_DATA_Obcine.tblCOFOG Opomba: Lastnik vseh tabel je uporabnik 'dbo', vse tabele se nahajajo v shemi APPrA_DATA_Obcine. Podatkovna baza na strežniku MF je zgrajena na podatkovnem strežniku MS SQL Server Tabela 13: Seznam tabel oziroma šifrantov iz katerih se zberejo podatki za posodobitev šifrantov na zahtevo uporabnika v LS Funkcije, ki jih opravlja OPPrA_Client pri procesu posodabljanja šifrantov preko strežnika MF, so: popraviti tiste zapise, pri katerih je bil spremenjen eden od atributov šifranta na MF strežniku; dodati nove zapise v šifrant, če obstajajo na MF strežniku. Pri tem mora OPPrA_Client upoštevati, da so na nivoju podatkovne baze za vse predpisane šifrante vgrajeni posebni tako imenovani sprožilci (trigger), ki preprečujejo spremembe na omenjenih šifrantih. Izjema je le šifrant podkontov (K6), kjer sprožilec dovoljuje vpis 7-10 mestne podkonte, pri čemer se mora seveda prvih šest mest ujemati s predpisanim podkontom. Pred posodabljanjem posameznega šifranta je potrebno sprožilec izključiti in ga po končanem posodabljanju vključiti nazaj PRENOS PODATKOV IZ LS NA STREŽNIK MF ZA III. DEL PRORAČUNA - NRP Postopek: 1. Uporabnik v aplikaciji APPrA-O izbere meni Nastavitve Stopnje III. dela proračuna - NRP. 2. Izbere ustrezno stopnjo, ki jo želi poslati na strežnik MF. 3. Klikne gumb»pošlji podatke za izbrano stopnjo na strežnik MF«- kliče se OPPrA_Client z ustreznimi parametri. Janez Klemenc: eporočanje finančnih podatkov občin Stran 63

74 Slika 31: Zaslonska slika vnosne maske "NRP stopnje" Ob kliku na omenjeni gumb se zberejo podatki iz naslednjih tabel: Opis vsebine tabele Naziv tabele OV - domači partnerji tblnrp_dinamika_ov_domaci_partnerji OV - druge občine tblnrp_dinamika_ov_druge_obcine OV - posredni proračunski tblnrp_dinamika_ov_ppu uporabniki OV - tuji partnerji tblnrp_dinamika_ov_tuji_partnerji PV - druge občine tblnrp_dinamika_pv_druge_obcine PV - evropska sredstva tblnrp_projekt_dinamika_pv_eu PV - lastna sredstva tblnrp_projekt_dinamika_pv_lastna PV - transfer iz državnega tblnrp_projekt_pv_transfer_drzave proračuna Atributi projekta tblnrp_projekt Šifrant projektov tblnrp_sifrant Podatki o stopnji NRP tblnrp_stopnje Opomba: Lastnik vseh tabel je uporabnik 'dbo'. Podatkovne baza na lokalni skupnosti je zgrajena na podatkovnem strežniku MS SQL Server Tabela 14: Seznam tabel iz katerih se zberejo podatki III. dela proračuna - NRP za prenos na strežnik MF Podatki iz tabel se morajo filtrirati po atributu STP. Primer: Če uporabnik izbere stopnjo z identifikacijo 7 se morajo tabele filtrirati z WHERE stavkom: SELECT * FROM dbo.tblnrp_projekt_dinamika_pv_lastna WHERE STP=7 Izjema: Šifrant projektov se ne filtrira. V šifrantu projektov so zbrani vsi projekti, ne glede na stopnjo. ER diagram podatkovne baze na posamezni občini za III. del proračuna - NRP je prikazan v prilogi C. Stran 64 Janez Klemenc: eporočanje finančnih podatkov občin