Pécs Megyei Jogú Város Önkormányzata. Kontrolling (vezetői információs) rendszer rendszerterve

LOGO-VIR Rendszerterv Pécs MJV Önkormányzata - Kontrolling (vezetői információs) rendszer terve

LOGO-VIR Rendszerterv

Pécs Megyei Jogú Város Önkormányzata Kontrolling (vezetői információs) rendszer rendszerterve

Daten-Kontor Számítástechnikai Fejlesztő és Szolgáltató Kft. Telefon: 1/279-3400; 72/552-928 Fax: 1/365-2167; 72/256-070

1/193


Alapadatok

Dokumentum neve LOGO-VIR Rendszerterv Dokumentum azonosítója LVT-0002

Dokumentum verziókövetése Verzió v01

Dátum 2010.02.26

Szerző Simon Csaba

Megjegyzés Első verzió

Ellenőrizte Csongor Eszter

Szűcs Gábor

Simon Csaba

Vida Ágnes

Szűcs Gábor Vida Ágnes

Projekt információ Szállítói projekt azonosító LOGO-VIR PMVJ projekt/pályázati azonosító ÁROP-2007-1-A-2/B


2/193


Tartalomjegyzék Alapadatok ................................................................................................. 2 Tartalomjegyzék .......................................................................................... 3 1.

Vezetői összefoglaló ............................................................................. 6

2.

Bevezetés ........................................................................................... 7

2.1. Előzmények...................................................................................... 7 2.2. Célok............................................................................................... 8 2.3. Fogalomtár ...................................................................................... 8 2.4. Felmérés során készült feljegyzések .................................................. 13 3.

Eljárások elemzése ............................................................................ 15

3.1. Bevezetés ...................................................................................... 15 3.2. Általános megállapítások.................................................................. 15 3.3. Intézményi terület .......................................................................... 17 3.3.1.

Intézmény nyilvántartás........................................................... 18

3.3.2.

Beszámoltatás, adatforrások ..................................................... 26

3.3.3.

Riportok, mutatószámok .......................................................... 30

3.4. Oktatási terület – vezetői információs nézete...................................... 31 3.4.1.

Oktatási intézmények nyilvántartása ......................................... 31

3.4.2.

Ellátotti adatok ....................................................................... 31

3.4.3.

Foglalkoztatotti adatok............................................................. 33

3.5. Szociális terület – vezetői információs nézete ..................................... 35 3.5.1.

Szociális intézmények nyilvántartása ......................................... 35

3.5.2.

Ellátotti adatok ....................................................................... 36

3.5.3.

Foglalkoztatotti adatok............................................................. 37

3.6. Kulturális terület ............................................................................. 40 3.6.1.

Kulturális intézmények nyilvántartása ........................................ 40

3.6.2.

Dolgozói adatok ...................................................................... 42

3.6.3.

Gazdálkodási adatok ................................................................ 43

3.6.4.

Tevékenységi adatok ............................................................... 45

3.7. Gazdasági társaságok ...................................................................... 48


3/193


3.7.1.

Gazdasági társaságok nyilvántartása ......................................... 48

3.7.2.

Gazdasági társaságok beszámolói ............................................. 52

3.7.3.

Riportok, mutatószámok .......................................................... 79

3.8. Pályázat nyilvántartási és monitoring................................................. 84 3.8.1.

Pályázatok nyilvántartása ......................................................... 84

3.8.2.

Pályázatokhoz kapcsolódó beszámolók ....................................... 89

3.8.3.

Riportok, kimutatások .............................................................. 89

3.9. Helyben központos közbeszerzés ...................................................... 90

4.

3.9.1.

Szabályozási háttér ................................................................. 91

3.9.2.

A helyben központosított közbeszerzések résztvevői .................... 92

3.9.3.

A helyben központosított közbeszerzések tárgyi hatálya ............... 92

3.9.4.

A helyben központosított közbeszerzés folyamata ....................... 95

3.9.5.

Nyilatkozattételek a rendszerben, adatok kezelése, közzététele .. 102

3.9.6.

Támogató technikai háttér...................................................... 103

3.9.7.

Támogató hivatali szervezet ................................................... 103

3.9.8.

Összegzés ............................................................................ 104

Informatikai rendszerterv ................................................................. 105

4.1. Követelmények elemzése ............................................................... 105 4.1.1.

Szakmai követelmények......................................................... 105

4.1.2.

Nem funkcionális követelmények............................................. 110

4.2. Szakmai rendszerfunkciók .............................................................. 113 4.2.1.

Használati esetek .................................................................. 113

4.2.2.

Törzsadat funkciók ................................................................ 125

4.3. Adatmodell................................................................................... 125 4.3.1.

Adattípus domének................................................................ 126

4.3.2.

Adatdefiníciók ....................................................................... 129

4.4. Informatikai rendszerfunkciók ........................................................ 140 4.4.1.

Felhasználói felület ................................................................ 140

4.4.2.

Rendszerbiztonság ................................................................ 148

4.4.3.

Hardver és szoftver architektúra ............................................. 153

4.4.4.

Fejlesztési módszertan ........................................................... 160

4.4.5.

Üzemeltetési terv .................................................................. 173


4/193


4.5. Integrációs terv ............................................................................ 181

5.

4.5.1.

A rendszer illesztési módjának leírása ...................................... 181

4.5.2.

Érintett adatkörök ................................................................. 184

4.5.3.

Az adatkommunikáció módja .................................................. 191

Melléklet ......................................................................................... 192


5/193


1. Vezetői összefoglaló Jelen projekt keretében Pécs Megyei Jogú Város Önkormányzatának Kontrolling (vezetői információs)

rendszerét

alakítjuk

ki

a

meglévő

LOGO

rendszer

infrastruktúra

környezetében. A kialakítandó funkcionalitás a LOGO-VIR modul (rendszerkomponens) keretei között kerül implementálásra. Projekt és ennek megfelelően a vezetői információs rendszer

(VIR)

meghatározó

területei,

melyeket

a

Koncepciókészítési

valamint

Rendszertervezési fázisban vizsgáltunk, az alábbiak: Intézményi terület működésének és gazdálkodásának fenntartói szempontú beszámoltatása, vizsgálata, különös tekintettel az alábbi szakterületekre: o

Oktatási intézmények

o

Szociális intézmények

o

Kulturális intézmények

Gazdasági társaságok beszámoltatása – PMJV tulajdonosi érdekeinek, ellenőrzési jogkörének támogatása céljából Pályázat nyilvántartási és monitoring megoldás kialakítása Helyben központosított közbeszerzés informatikai támogatása

Az igényfelmérési és tervezési fázis folyamán a fenti területek feltérképezése során az Önkormányzat

és

IGSZ

képviselő

valamint

a

DK

szakértői

megbeszélések

és

egyeztetések keretében alakították ki közösen a jelen Rendszerterv szakmai és műszaki kereteit. Alkalmazott projektmódszertan alapján valamennyi megbeszélésről emlékeztető készült, mely minden érintettnek véleményezésre elküldésre került. Amennyiben érkezett korrekció,

pontosítás

az

adott

emlékeztetőhöz,

akkor

azokat

beépítettük

jelen

Rendszerterv által lefedett szakmai és műszaki specifikációs halmazba. Amennyiben nem érkezett észrevétel, akkor az emlékeztető eredeti megállapításai képezik a javasolt megoldás alapjait. A Rendszertervben külön kiemeljük azon részterületeket, melyek az igények és megoldási lehetőségek szintetizálása során felülvizsgálatra és adott esetben elvetésre kerültek. A Megrendelőnek természetesen lehetősége van a Rendszerterv véleményezésére,

ez

fontos

elvárás

is,

hiszen

csak

konszenzusosan

elfogadott

Rendszerterv képezheti a megvalósítás alapját. Általánosságban elmondható, hogy területenként eltérő specifikációs hajlandósággal


6/193


találkoztunk a felmérés, tervezés során, ennek megfelelően az igények részletezettsége is

eltérő

volt.

Ennek

ellenére

jelen

dokumentumban

igyekeztünk

területenként

„egyenszilárdságú” szakmai és műszaki javaslatokat adni. Rendszerkoncepcióban definiáltuk, hogy jelen projektben és a szállított LOGO-VIR megoldásban a tanácsadási és rendszerfejlesztési tevékenység integráltan jelentkezik. A szállított megoldás a kialakított kontrolling funkcionalitás informatikai bázisán, vezetői információs módszertani és belső szabályozási változásokat indukál. Ezen módszertani és szabályozási

(jellemzően

beszámoltatáshoz

kapcsolódó)

változásokat

az

Önkormányzatnak kell kezdeményeznie és végrehajtania, a Szállító támogatásával.

2. Bevezetés 2.1. Előzmények Pécs Megyei Jogú Város Önkormányzata pályázatot nyert el az Államreform Operatív Program - A polgármesteri hivatalok szervezetfejlesztése című pályázati felhíváson (ÁROP-2007-1-A-2/B) „Szervezetfejlesztési célok megvalósítása, kontrolling rendszer bevezetése Pécs Megyei Jogú Város Önkormányzatánál” címmel. Pécs Megyei Jogú Város Önkormányzata, mint ajánlatkérő 2009. 10. 01-én „Ajánlatkérő számára kontrolling (vezetői információs) rendszer kifejlesztése, integrálása a jelenlegi eönkormányzati rendszerbe és ehhez kapcsolódó rendszerfejlesztési és tanácsadói és oktatási szolgáltatás ellátása” tárgyban nyílt közbeszerzési eljárást indított. PMJV Önkormányzata a közbeszerzési ajánlatban benyújtott ajánlatokat megvizsgálta és döntését a Pécs Megyei Jogú Város Közgyűlésének 587/2009 (12.17) határozata alapján 2009.12.17-én kihirdette. A közbeszerzési eljárásban hozott döntés szerint a nyertes ajánlattevő a Daten-Kontor Kft. lett. Pécs Megyei Jogú Város Önkormányzata és a Daten-Kontor Kft. 2009.december 29-én vállalkozási szerződést (02-2/332-65/2009) kötöttek kontrolling (vezetői információs) rendszer fejlesztésére. 2009. december 29-én megkezdődött hivatalosan a projekt a szerződő felek között. 2010. január 14-én került sor a közös projektindító értekezletre a két fél között. A projekt eddigi (tervezési) szakaszában szakmai konzultációkra került sor. Felmérésre, összegyűjtésre

és

elemzésre

kerültek

az


Önkormányzat

jelenlegi

tervezési

és

7/193


beszámoltatási

folyamatai

és

gyakorlatai.

Az

összegyűjtött

információk

alapján

kialakításra került egy rendszerkoncepció, melyet az Önkormányzatnak átadtunk. A leadott

rendszerkoncepció

képezi

az

alapját

eme

rendszertervnek,

az

abban

megfogalmazott irányvonalak mentén haladt tovább a projekt.

2.2. Célok Rendszerterv alapvető célja a Rendszerkoncepcióban megfogalmazott alapvető igények és megvalósítási koncepció további, részletes szakmai és műszaki kiterjesztése. A Rendszerkoncepcióban vizsgált feladatcsoportok mellett újabb területek kerültek – szociális és kulturális intézményekkel kapcsolatos vezetői információs igények

–

bevonásra. Így alakult ki jelen Rendszerterv szintjén lehetőségekhez pontosan behatárolt feladathalmaz. Rendszerterven megfogalmazott szakmai és műszaki javaslatok jelentik a megvalósítás alapjait, határozzák meg pontosan a kialakítandó LOGO-VIR rendszer funkcionalitását. Ezért fontos, hogy a Megrendelő véleményezésével, visszajelzéseivel segítse a Rendszerterv véglegesítését, elfogadását. Rendszerterv 3. fejezetében a feladatkör szakmai (üzleti) vetületével foglalkozunk elsődlegesen, míg a 4. fejezetben a kialakítandó funkcionalitás műszaki (informatikai) dimenziója kerül előtérbe.

2.3. Fogalomtár

Adatforrás

Egy egyesített dokumentumba beillesztendő információkat tartalmazó fájl.

Adatszolgáltatás

Bizonyos kért adatoknak felkérésre az illetékes felsőbb szervvel való közlése.

Adattörzs

Törzsadatok halmaza.

Beszámoló

Egy szervezet által egy másik felettes vagy valamilyen felügyeleti

joggal

bíró

szervezet

számára

nyújtott

adatszolgáltatás.


8/193


DMZ

A személyes vagy vállalati hálózatok megbízhatatlan külső, és a

megbízott

belső

része

között

elhelyezkedő

A DMZ a benne elhelyezkedő hálózati erőforrásokhoz,

mind

a

megbízott

terület.

eszközökhöz és belső,

mind

a

megbízhatatlan külső területről engedélyezi a hozzáférést, de megakadályozza, hogy a külső területről bármilyen kérés vagy hozzáférési kísérlet eljusson a belső hálózatra. Elektronikus

Informatikai rendszer vagy állomány, mely számítástechnikai

adatforrás

eszközökkel elérhető és manuális adatbevitel nélkül szolgáltat adatokat.

Forrás SQL

A FORRÁS-SQL rendszer modulokból - alrendszerekből - álló windows-os kezelői felületű, SQL adatbázisra épülő integrált ügyviteli és bonyolítási rendszer. A rendszerben lévő modulok egymásra építkeznek, számuk tetszőlegesen bővíthető. Egy adott gazdálkodó szervezet adminisztrációja alapvetően két jól elkülöníthető részre osztható. Az egyik a felhasználó tevékenységeinek bonyolítása, amely magában foglalja a rendelések nyilvántartását, előkalkuláció készítését, árajánlat készítését, anyag- vagy árubeszerzést, termék előállítást, valamint az áruértékesítést. Az adminisztráció másik része az ügyviteli elszámolások köre.

Főkönyv

A könyvviteli számlák összességét, a valamennyi könyvviteli számlát

tartalmazó

feljegyzést

főkönyvnek

nevezzük;

a

főkönyvhöz tartozó számlák pedig a főkönyvi számlák. IGSZ

Intézmények Gazdasági Szolgálata A

hozzárendelt

részben

önálló

rendelkező intézmények pénzügyi

gazdálkodási

jogkörrel

– gazdasági, műszaki

intézményellátó és egyéb szolgáltató tevékenységét végzi. Interfész

Két funkcionális egység együttműködését biztosító adatcsere, ill. ennek technikája, a különböző adatátviteli berendezések és

adatátviteli

vonalak

összekapcsolásának

és

együttműködésének módja.


9/193


Intézmény

Az

önkormányzat

által

fenntartott,

helyi

önkormányzati

költségvetési szerv, valamint önként csatlakozott szervezet. Kettős

A

gazdálkodó

könyvvitel

eszközökről

és

a

kezelésében, azok

illetve

forrásairól,

tulajdonában

továbbá

a

levő

gazdasági

műveletekről olyan könyvvitel nyilvántartást köteles vezetni, amely

az

eszközökben

(passzívákban)

(aktívákban)

bekövetkező

és

a

forrásokban

változásokat

a

valóságnak

megfelelően, folyamatosan, áttekinthetően mutatja. KIR

Közoktatási Információs Rendszer

KIR-IMI

Kincstár Központosított Illetményszámfejtő Rendszere (KIR) részeként elérhető Intézményi munkaügyi információs (IMI) modul

LOGO

Integrált Önkormányzati Rendszer

Magiszter

Magiszter Iskolaadminisztrációs Rendszer

Normatíva

A normatíva hazai gyakorlatunkban azt mutatja meg, hogy a kötelező

feladatokhoz

kapcsolódóan

a

feladatmutató

egységének éves teljesítéséhez mekkora pénzügyi forrást biztosít a központi költségvetés állami támogatásként, illetve átengedett személyi jövedelemadóból. Pl. 100 %-ban állami támogatás a forrása az alapfokú művészetoktatásnak, a fogyatékos

tanulók

kollégiumi

ellátásának,

a

középfokú

nevelés-oktatásnak. A normatíva folyó kiadásokat finanszíroz, deklaráltan csak részben biztosítja a feladat ellátásához szükséges pénzügyi forrást, a helyi önkormányzatnak más forrásokkal is ki kell azt egészíteni. Önkormányzat

A helyi közakaratot kifejező, helyi érdekű közügyekben demokratikus módon, a széles nyilvánosság bevonásával eljáró szerv.


10/193


PIR

A

költségvetési

intézmények

Pénzügyi

Információs

Rendszere. PIR szám

A

költségvetési

intézmények

PIR-ben

meghatározott

törzsszáma. Saját előadás

Olyan színházi alkotás, amelynek előadásához szükséges szerzői

jogokkal

meghatározott

a

időre

felhasználási vagy

szerződés

előadásszámra

a

alapján színház

rendelkezik, az előadás a színház által szerződtetett alkotóés előadóművészek művészi tevékenységével jön létre, és a színház szervezésével, a színház költségvetéséből kerül a nyilvánosság elé. Tájelőadás

Az előadó-művészeti szervezet alapító okiratában megjelölt székhely településen kívül játszott előadás.

Taninform

Iskolai adminisztrációs és ügyviteli szoftver. A költségvetési törvényben meghatározott informatikai normatíva lehetőséget biztosított arra, hogy az intézmények és fenntartóik által végzett

iskolai

használatával

adminisztrációs

könnyebben

munka

tervezhetővé

a és

program egyszerűen

elvégezhetővé váljon. Törzsadat

Olyan több folyamat, modul, komponens által használt közös alapadat.

Tűzfal

Olyan szoftveres és/vagy hardveres technika, amellyel az intézmények

a

helyi

hálózatukat

megvédhetik

a

külső

hálózatról (jellemzően az Internetről) érkező betörések ellen, a bejövő és kimenő adatforgalom figyelésével, megszűrésével és korlátozásával.


11/193


VIR

Vezetői információs rendszer A vezetéstámogató rendszerek egyik fajtája, mely a felső- és középvezetés múltbeli

számára

nyújt

teljesítményéről,

a

információt pillanatnyi

az

intézmény

állapotáról

és

a

jövőbeni céljairól. Legfőbb feladata a napi és a stratégiai döntéshozatal támogatása külső és belső információkkal egyaránt.


12/193


2.4. Felmérés során készült feljegyzések A rendszertervezési tanácsadás keretein belül az előkészítés, felmérés során a heti előrehaladásról

haladásjelentések,

a

lefolytatott

interjúkról

pedig

emlékeztetők

készültek:

Haladásjelentések: LOGO_VIR_03_haladásjelentés_20100122.xls LOGO_VIR_04_haladásjelentés_20100129.xls LOGO_VIR_05_haladásjelentés_20100205.xls LOGO_VIR_06_haladásjelentés_20100212.xls LOGO_VIR_07_haladásjelentés_20100219.xls LOGO_VIR_08_haladásjelentés_20100226.xls

Emlékeztetők: Emlékeztető_LVM0001_2010_01_14.doc Emlékeztető_LVM0002_2010_01_15.doc Emlékeztető_LVM0003_2010_01_15.doc Emlékeztető_LVM0004_2010_01_20.doc Emlékeztető_LVM0005_2010_01_22.doc Emlékeztető_LVM0006_2010_01_25_v2.doc Emlékeztető_LVM0007_2010_01_26.doc Emlékeztető_LVM0008_2010_01_27_v2.doc Emlékeztető_LVM0009_2010_01_28.doc Emlékeztető_LVM0010_2010_01_29.doc Emlékeztető_LVM0011_2010_01_29.doc


13/193


Emlékeztető_LVM0012_2010_01_29.doc Emlékeztető_LVM0013_2010_02_04.doc Emlékeztető_LVM0014_2010_02_10.doc Emlékeztető_LVM0015_2010_02_11.doc Emlékeztető_LVM0016_2010_02_15.doc Emlékeztető_LVM0017_2010_02_19.doc Emlékeztető_LVM0018_2010_02_22.doc Emlékeztető_LVM0019_2010_02_23.doc Emlékeztető_LVM0020_2010_02_23_v2.doc Emlékeztető_LVM0021_2010_02_24_v2.doc

Az emlékeztetőket a rendszerterv mellékletként tartalmazza.


14/193


3. Eljárások elemzése 3.1. Bevezetés

Rendszertervezési

fázis

igényfelmérési

és

tervezési

tevékenységei

az

átadott

Rendszerkoncepció bázisán és kijelölt, lefeketett logikájában folytatódtak. Elfogadott, konszenzusos megközelítés volt, hogy az eljárásokhoz kapcsolódó felülvizsgálati és átalakítási javaslattételi tanácsadói tevékenységek valamint a kontrolling informatikai rendszer kialakítása nem független projekt tevékenységek, hanem egy közös célt szolgálnak:

3

önkormányzati

eljárás

(továbbiakban

terület

vagy

feladatcsoport)

tekintetében a kialakítandó LOGO-VIR rendszerkomponens biztosítson informatikai támogatást az eljárás (terület) egészének vagy bizonyos kritikus részeinek, ezzel jelentősen átalakítva a jelenlegi folyamatokat. Ez elmúlt hónap felmérési és tervezési tevékenységei alapján pontosan meghatározható és

behatárolható

az

a

vezetői

információs

igényhalmaz,

melyet

a

LOGO-VIR

funkciócsoport támogatásával kívánunk lefedni. A Koncepciótervben meghatározott önkormányzati

területek

(feladatcsoportok)

pontosítása

megtörtént,

eredeti

koncepcióban megfogalmazottak mellé további területek kerültek bevonásra. Jelen fejezetben az igényfelmérési és tervezési fázis eredményeként pontosított szakmai igényeket és javasolt üzleti megoldásokat ismertetjük. Technikai szintű ismertetésre a 4. fejezet biztosít keretet. Ebben a fejezetben a kontrolling célú valamint üzleti logikai megközelítés

az

elsődleges,

a

vezetői

információs

rendszerrel

kapcsolatban

megfogalmazott szakmai igények és azokra adott megvalósítási válaszok ismertetése.

3.2. Általános megállapítások

Vezetői információs témakörben több feladatcsoportot és területet is vizsgáltunk. Eltérő jellegük ellenére azonban számos közös jellemzővel bírnak, mely hangsúlyok a LOGO-VIR


15/193


megoldás gerincét is jelentik. Ezen meghatározó dimenziók: Nyilvántartások: nincs az adott területre jellemző adatkörök vonatkozásában egységes, informatikai támogatottságú nyilvántartás, vagy ha van is, az nem teljeskörű, információtartalma nem kielégítő, területenként eltérő szerkezetű. Területenként

egységes

szerkezetű

nyilvántartások

kialakítása

kiemelt

jelentőségű. Új központi törzsek jellegükből fakadóan átvehetik és kiválthatják az eddigi szétdarabolt nyilvántartások szerepét (intézmény: kulturális, oktatási, szociális); azok funkcionalitását kiterjeszthetik (pályázatok kezelése) illetve eddig nem létező területeknek biztosíthatnak nyilvántartást (gazdasági társaságok, egyéb önkormányzati intézmények). További nélkülözhetetlen eredménye az egységesített

nyilvántartásoknak,

társaságokhoz,

pályázatokhoz

hogy

az

rendelt

intézményekhez,

egyedi

gazdasági

azonosítók

segítségével

valósíthatóak meg az alapvető LOGO-VIR funkcionalitások, belső és külső integrációs kapcsolatok, hivatkozások. Beszámoltatás, adatforrás: intézményekkel és pályázatokkal kapcsolatos irányítói, fenntartói jogok, hatáskörök, akárcsak az intézmények működésének és gazdálkodásának szabályai (az önállóság keretén túl) jogszabályokkal (törvények, rendeletek, szakágazati előírások, helyi szabályozás) pontosan definiáltak. Ezen, rendkívül szabályozott kereten belül a vezetői információs rendszerben a hangsúlyok

az

alapinformációk

irányítási

és

begyűjtésén,

fenntartói valamint

feladatok

az

ellátásához

intézmények

szükséges

működésének

és

gazdálkodásának átláthatóságán vannak. Az irányítói és fenntartói feladatok hatékony gyakorlása mellett bizonyos intézményi alapadatok beszámoltatása a fenntartó

szakterület

által

végzett

további

adatszolgáltatás

(Pénzügy

Minisztérium, Magyar Államkincstár, stb.) alapjait képezik. Hasonló a helyzet a gazdasági társaságok tekintetében, ahol a tulajdonosi jogok gyakorlásához és tulajdonosi

érdekek

érvényesítéséhez

szükséges

naprakész

gazdálkodási

alapinformációk bekérése az első, kiemelt jelentőségű feladat. Megállapításunk szerint a beszámoltatási, adatbekérési terület, akár az intézményi, akár a gazdasági társasági területet is tekintjük, eddig a feladat fontosságához és súlyához mérten nem kapott elégséges módszertani és informatikai támogatást. Riportok, képzett mutatószámok: intézményi szinten kiemelkedő jelentőségű vezetői információs igényt fog a rendszer kielégíteni azáltal, hogy az egyes intézményegységektől

bekért

ellátotti

és

létszámadatokat

strukturáltan

elérhetővé teszi – elemi (tag)intézmény (telephely) szinttől kezdve, intézmény


16/193


szinten át, az önkormányzati szintig. Teszi mindezt a szakfeladati dimenzió mentén, amennyiben a fenntartó ilyen bontást ír elő a beszámoltatás során. Látható, hogy korábbi pontban említett beszámoltatási hiányosságok orvoslásával praktikusan az eddigi elégtelen információk (nem, vagy csak hiányos, részlegesen elérhető, egységesen nem tárolt adatok) is teljeskörűvé tehetők. Bizonyos esetekben már az adatbekérés informatikai szemléletű strukturálása, tárolása és felhasználó igényeinek megfelelő megjelenítése is jelentős előrelépés a jelenlegi helyenként gyakorlathoz (email vagy papíralapú) képest. Természetesen a LOGOVIR-ben kialakított funkcionalitás többre is vállalkozik, mint egy egyszerű adatbekérés-tárolás-publikálás

folyamat

informatikai

támogatása.

Eltérő

adatforrásokból származó adatok előredefiniált mutatószámok képzésében is szerepet játszanak. Kiemelt jelentőségű az intézmények közgazdasági- és funkcionális

bontottságú

költség/kiadás

adatainak

elemzése

ellátotti

létszámadatok mentén. Forrás SQL főkönyvi adataiból kinyert költség/kiadás adatok lesznek a fajlagos mutatószámok alapja.

Továbbiakban részletesen áttekintjük a projekt keretében vizsgált 4 feladatcsoportot (eljárást): Intézményi terület o

Oktatási,

o

Szociális és

o

Kulturális részterületek

Gazdasági társaságok Pályázati nyilvántartás és monitoring Helyben központosított közbeszerzés

3.3. Intézményi terület

Koncepcióterv szintjén csak az oktatási terület előzetes igénye lett vizsgálva és koncepcionálisan informatikai megoldással lefedve LOGO-VIR keretében. A Megrendelő kérésének megfelelően az oktatási terület a szociális valamint a művelődési (további humán) területekkel egészült ki – területenként eltérő szakmai igényekkel.


17/193


Intézményi terület költségvetési súlyát (bevétel és kiadási oldal), foglalkoztatotti és ellátotti

létszámadatait,

valamint

közszolgálati

feladatait

tekintve

is

kiemelkedő

jelentőségű az Önkormányzat gazdálkodásában, működésében. Súlya és jelentősége révén kiemelten vizsgálandó vezetői információs szempontból. Intézményi terület LOGOVIR-be történő bevonásával az Önkormányzat irányítói, fenntartó szerepköre erősödhet, gazdasági és szakmai kontroll mértéke növelhető, rendszerből származó adatokkal az intézményi

tevékenységek

ellenőrzése

és

azokra

alapuló

vezetői

döntések

előkészítésének hatékonysága növekedhet. Következőkben áttekintjük a korábban nevesített

3

dimenzió

riportok/mutatószámok)

mentén

(nyilvántartások/törzsek, az

intézményi

beszámoltatás

területtel

kapcsolatos

és

általános

igényeket, javasolt üzleti megoldásokat, először egységes intézményi szinten, majd az önálló területeket (oktatási, szociális, kulturális) azok specialitásaival összegezzük.

3.3.1.

Intézmény nyilvántartás

Korábbiakban már rámutattunk egy egységes, önkormányzati szintű, ágazatfüggetlen, teljeskörű

intézménytörzs,

nyilvántartás

kialakításának

időszerűségére.

Egységes

nyilvántartás indokai, előnyei: Valamennyi önkormányzati intézményt tartalmazza, közös felületen Kezeli

az intézményi

tagozódást

(főintézmény, tagintézmény/telephely,

intézményegység) – hierarchiák. Intézmények adatai nyilvánosak, alapító okirat rögzíti, így azok strukturáltan tárolhatóak, ábrázolhatóak, megjeleníthetőek. Leíró adatok körének döntő többsége független az adott ágazattól (területtől) ahová az intézmény tartozik, így közös nyilvántartásban foglalhatóak. Intézményre jellemző kiemelt adatok egységes szemléletben tölthetőek (kapcsolódó nyilvántartás, előredefiniált értékkészlet -> ágazat, közfeladat, szakágazat, intézmény típus, stb.). Intézmények számos egyedi azonosítóval rendelkeznek, melyeket célszerű nyilvántartani szakfeladat,

(PIR

azonosító/törzsszám,

elszámolási

egységcsoport,

OM

azonosító,

elszámolási

szakágazat,

egység,

stb.).

Nyilvántartásokban lesznek fenntartott azonosítók, melyek pl. szakterületi szabályozás

későbbi

módosulásából


származó,

új

intézményazonosítók

18/193


rögzítését teszik lehetővé. Intézményekhez egyedi LOGO-VIR azonosító rendelődik, mint minden további informatikai logika és hivatkozás alapja. Intézményhez leíró

jelleggel

(ez

különböző,

mint

a

beszámoltatásból

származó adat) eltárolható az alapító okiratban szereplő maximális (ellátotti) létszám kapacitás (oktatási és szociális ágazatban), költségvetési rendeletből az intézményi dolgozói létszámadat. Intézményi nyilvántartás a különböző jogosultsági beállítások és publikálási nézetek

mentén

folyamatosan

élőntartható

és

kielégítheti

a

belső

(önkormányzati) és külső (képviselői, civil) igényeket is. Publikálási nézetek lehetővéteszik, hogy csak az ágazatfüggetlen adatok egy meghatározó köre illetve az adott nézetre jellemző ágazatfüggő adatok jelenjenek meg. Megjelenítés során lehetőség van meghatározó adatokra szűrni (ágazat, közfeladat, főintézmény, stb.), így az egységes, közös nyilvántartásból csak az igénynek megfelelő intézményhalmazt elérni. Intézmény szinten lehetőség van dokumentumokat csatolni (alapító okirat, működési engedély, egyéb)

Összefoglalva: ezzel az egységes LOGO-VIR nyilvántartással az intézményekre jellemző valamennyi adat karbantartható, tárolható. A későbbiekben ismertetendő adattartalmat tekintjük kiinduló alapnak, melynek módosítására a Megrendelőnek a Rendszerterv véleményezése során lehetősége van. Egységes intézmény nyilvántartásban átadáskor csak a PMJV irányítású és fenntartású intézmények szerepelnek. A Megrendelően a későbbiekben lehetősége lesz nem önkormányzati intézmények felvételére is, azzal a megszorítással,

hogy

a

nyilvántartás

adatbeviteli

logikája

az

önkormányzati

intézményekre van testreszabva (kötelező mezőtöltöttség, referencia értékek, stb.). Az új egységes intézmény nyilvántartás létrejöttével vizsgálni kell a meglévő, szegmentált egyedi nyilvántartások kiváltását, megszüntetését. Amennyiben ez nem történik meg, egy fenntartott azonosító illetve az ágazat besorolás segítségével egyértelmű hivatkozás tehető az egységes intézménytörzs egy eleme és a szeparált nyilvántartásban szereplő bejegyzés között.


19/193


Intézmény nyilvántartás – javasolt adattartalom

Címke

Leírás

Intézmény azonosító

Intézmény egyedi LOGO-VIR azonosítója

Intézmény rövid neve


Intézmény hosszú neve


Ágazati besorolás

Ágazat

Önkormányzati intézmény

’I’ vagy ’N’ érték - induláskor default 'I'

Szakágazati alapbesorolás

Alapító okirat szerint, szakfeladat név

Gazdálkodás típusa

Feladatellátáshoz kapcsolódó besorolás

Intézmény típusa

Főintézmény, tagintézmény

Besorolás

Közszolgáltató, közintézmény

Közfeladat, alaptevékenység

Jogszabályban meghatározott közfeladat

Tevékenységek

Tevékenységek

Szakfeladatok

Szakfeladatok tevékenység típusonként

Intézmény irányító szervezet

Alapító okirat szerint: PMJV Alapító

Fenntartó szervezetek

okirat

szerint:

PMJV

és

egyéb

szerint:

PMJV

és

egyéb

önkormányzat Alapító

okirat

Működési kör

önkormányzat

Székhely címe

Székhely címe

Levelezési címe

Levelezési címe


20/193


Tényleges

telephelyek

(nem

főintézmény

Telephelyek címe

tagintézményei)

Intézmény telefon, fax


Email

Email

Honlap

Honlap

Alapító okirat, jogszabály

Hivatkozás a dokumentum azonosítójára

Működési engedély

Hivatkozás a dokumentum azonosítójára Vezető neve, beosztása (esetleg javadalmazási

Vezető neve, beosztása

adat)

Telefon, fax

Telefon, fax

Email

Email

Kapcsolattartó neve, beosztása


Telefon, fax

Telefon, fax

Email

Email

Leíró mező

Általános leíró mező

Főintézmény

VIR

egyedi

azonosító

Főintézmény egyedi LOGO-VIR azonosítója

Elszámolási egység csoport kód Elszámolási

Csak főintézmény esetén töltendő - Forrás SQL egység

elsődleges Elszámolási másodlagos

Forrás SQL egyedi azonosító egység IGSZ esetén szükséges 2. elszámolási egység is ANK

Ügyletkód

esetén

szükséges

(intézményegység)

–

Forrás SQL


21/193


Adószám

Főintézmény alapító okiratban szereplő adószáma

PIR azonosító

Törzsszám

OM azonosító

Oktatási ágazat esetén releváns intézmény kód

Szakágazat

Szakfeladat kód az alapító okiratból

Fenntartott azonosító1






Ellátotti létszám

Tájékoztató jelleggel

Férőhelyi kapacitás

Alapító okiratból és/vagy működési engedélyből

Dolgozói létszám - álláshely

Költségvetési rendeletben meghatározott szám Oktatási (fő)intézmények esetén a költségvetés

Pedagógus

alapján Oktatási (fő)intézmények esetén a költségvetés

Nem pedagógus

alapján

Fenti táblázatban kiemelt adatok értékei kötöttek (lásd törzsek), többi mező a felhasználó által szabadon tölthető leíró adat. Az intézmény nyilvántartás a következő alfejezetekben ismertetett törzsekből építkezik.

3.3.1.1. Intézmény törzsek

Intézménytörzs: intézmények leíró adatait, azonosítóit tartalmazó törzs. Az intézmény nyilvántartás alapja, kapcsolódó törzsekből építkezve, azokkal együtt biztosítja a felhasználó számára az egységes nyilvántartási felületet adattartalmát.


22/193


Gazdálkodás típusa: feladatellátáshoz kapcsolódó funkció szerinti besorolás: önállóan gazdálkodó és működő, önállóan működő.

Intézmény típusa: főintézmény, tagintézmény (telephely)

Elszámolási

egység

csoport

és

elszámolási

egység

törzsek:

ForrásSQL-ből

származtatott törzs. Jelenlegi tervezési koncepció értelmében az intézmény törzsben tárolt érték (egy elemi intézményhez vagy telephelyhez 1 csoport és 2 elszámolási egység rögzíthető), hivatkozva jelen törzsre. Amennyiben ez az intézményszempontú összerendelési megközelítés nem megvalósítható, külön intézmény-csoport vagy csak külön intézmény-elszámolási egység összerendelő logikát kell kialakítani.

3.3.1.2.

Ágazat, tevékenység, szakfeladat törzsek

Az intézményeket feladataik szerint csoportosítani, osztályozni szükséges. Továbbá tevékenységük a hatályos szabályozás szerint elemi szakfeladatokkal reprezentálható. LOGO-VIR-ben szükséges intézmények vonatkozásában létrehozni ezen törzseket, hogy: azok intézmények szintjén hivatkozhatóak legyenek o

csoportosítási, kategorizálási ismérv

o

leírják az adott intézmény alapfeladatait

azok intézményekhez rendelésükkel beszámolási és riport struktúrákat definiálnak

Ágazat: belső LOGO-VIR törzs, alapvetően az intézmény önkormányzati logikájú ágazat besorolását támogatja -> oktatási, szociális, kulturális, sport, egyéb

Tevékenység:

szintén

belső

LOGO-VIR

törzs,

lehetőséget

teremt

az

elemi

részletezettségű szakfeladat struktúra átfogóbb, önkormányzati terminológia szintű ábrázolására, csoportosítására, például az alapító okiratokban szereplő közfeladat, alaptevékenység értékek vagy más elfogadott besorolás mentén -> közoktatás; óvoda, általános iskola, alapfokú művészeti oktatás, szociális alap és szakosított ellátás;


23/193


Családsegítés, gyermekjóléti szolgáltatás; Gyermekjóléti alapellátás és gyermekvédelmi szakellátás; Gyermekjóléti alapellátás és gyermekvédelmi szakellátás; stb.

Tevékenység típus: Szakfeladatok csoportosítását szolgálja a tevékenység típus -> alap, kiegészítő, kisegítő, vállalkozási tevékenység.

Szakfeladat: PM tájékoztatója szerinti államháztartási szakfeladatok rendjében található elemi feladat. Államháztartás valamennyi alrendszerének, így az önkormányzatok tevékenységét is teljesen lefedő feladatstruktúra. LOGO-VIR rendszerben kiemelt jelentőségű törzs, mely beszámolók adatbekérési dimenziót, valamint a kiadások funkcionális

bontását

biztosítja.

Törzs

kialakításakor

külön

figyelmet

érdemel

a

szakfeladati rend éves költségvetéssel összhangban történő változásának kezelése. Minden elemi szakfeladathoz kötelezően meg kell adni a Tevékenység azonosítóját (önkormányzati logikájú csoportosítás).

Normatív jogcímek: az önkormányzat, döntően az intézményein keresztül végzett feladatai

egy részéhez normatív hozzájárulást és normatív, kötött felhasználású

támogatást kap a központi költségvetésből. Az intézményfinanszírozás során a normatív támogatást egészíti ki az Önkormányzat saját forrásaival (bevételek). Normatív jogcím elemzési dimenzió beemelését a LOGO-VIR rendszerbe elvetettük. Ennek megfelelően, mint törzsadat sem lesz leképezve. Ábrázolás elutasításának okai az alábbiak: Normatív támogatási jogcímek igénylésének alapja – a jelent tárgykörben releváns oktatási és szociális ágazatban – döntően az ellátotti létszám. Mint mennyiségi egység a normatív kvótával (fajlagos érték) együtt határozza meg a támogatás összegét. Költség/kiadási oldalon nincs normatív jogcímbontás, hanem csak szakfeladati. Amely szakfeladati bontás bármennyire is hasonlóságot mutat a normatív jogcímbontással, mégsem feleltethetőek meg egymással egy-az-egyben. Minden

évben

változó

besorolású

struktúra,

ezért

összerendelési

logikák

karbantartását költségessé teszi. Csak bevételi oldal egy részét fedi le, míg jelen kontrolling megközelítés a költségek/kiadások pontos és teljeskörű feltérképezésére fókuszál. Intézmények szolgáltatnak alapadatokat a normatív támogatás igényléséhez (tervezés, évközi módosítás -> lemondás, pótlás) és év végi beszámoláshoz


24/193


intézmény

illetve

utóbbi

esetben

telephely/tagintézmény

szinten.

Tehát

intézményenként és telephelyenként/tagintézményenként rendelkezésre áll az ellátottak kapcsán illetve egyéb mutatószám mentén igényelt és kapott normatív támogatás mértéke. Ez utólag összevethető a LOGO-VIR-ből származó intézmény (telephely/tagintézmény)

és

vagy

szakfeladat

szintű

tényleges

és

teljes

költség/kiadás adatokkal, akár fajlagos (ellátotti) szinten is. Ehhez azonban a LOGO-VIR

csak

költség/kiadás

oldalt

tudja

biztosítani

intézményi

és/vagy

szakfeladati bontásban.

3.3.1.3. Összerendelések Intézmény – tevékenység típus - szakfeladat összerendelés: alapító okirat szerinti főintézmény szintű tevékenység típus (alap, kisegítő, stb.) és elemi szakfeladat összerendelés.

A

főintézményre

tagintézményekre/telephelyekre

is

megadott

összerendelés

automatikusan,

de

érvényes lehetőség

a van

tagintézmény/telephely szintű szűkített (kevesebb, csak az adott tagintézményre jellemző) összerendelésre is. Ezen összerendelés alapján jeleníthető meg az intézmény nyilvántartásban az adott intézményhez tartozó tevékenységek (elemi szakfeladat -> tevékenység) és szakfeladatok. Természetesen ezen összerendelés nem csak az intézmény nyilvántartáshoz szolgáltat adatokat, hanem a későbbiekben ismertetett beszámoltatási funkciónál határozza meg adott intézmény vonatkozásában a releváns szakfeladati adatbekérési dimenziókat.


25/193


3.3.2.

Beszámoltatás, adatforrások

A vezetői információs rendszer egyik meghatározó alappillére, a nyilvántartások mellett. Adatforrások két típusra oszthatóak: LOGO-VIR által biztosított web-es adatbekérő felületen rögzítettek Automatikus adatbeolvasás – jelenleg csak a Forrás SQL adatbázis kapcsolat

LOGO-VIR keretében kialakított web-es adatbekérők terület- és ágazatspecifikus tartalmi részeivel az adott terület ismertetésekor foglalkozunk, míg technikai vonatkozásait a műszaki részben ismertetjük. Általánosságban elmondható, hogy azok – még ha azonos adatkörökre is vonatkoznak, mint pl. ellátotti adatok, dolgozói létszám – mindig az adott terület igényeinek megfelelő struktúrában érhető el. A web-es felületen történő beszámoltatást, adatrögzítést segíti, hogy az előző beszámolás során felvitt adatok egy körét (jellemzően a statikus értékek) a rendszer felajánlja, így azokat nem kell újból rögzíteni, ha az adott érték nem változott.

Forrás SQL rendszerrel történő integrációról, azokkal kapcsolatos integrációs alaplogikai (tehát nem műszaki) elképzelésekről, azok általános érvényessége miatt itt, az átfogó intézményi szinten foglalkozunk. A rendszerintegrációnak nincs területspecifikus vonása, az általános érvényű mind az oktatási, mind a szociális valamint művelődési (kulturális) területre. Forrás SQL az Önkormányzat számviteli és könyvviteli rendszere. Az Önkormányzatot illetve – ami esetünkben fontos – intézményeit vagyoni, pénzügyi és jövedelmi szempontból érintő valamennyi gazdasági eseményről bizonylat készül és azt rögzítik a Forrás SQL-ben. Az Önkormányzatnál, mint államháztartási/költségvetési szervnél módosított

teljesítés

szemléletű

információs

szempontból

az

(pénzforgalmi)

előirányzat

könyvvitelt

teljesítési

számlákon

folytatnak. a

Vezetői

pénzforgalmak

elszámolása, a kiadások fajtája és neme szerinti ún. közgazdasági osztályozás (költségnem) szerint, valamint a kiadások szakfeladatonkénti ún. funkcionális osztályozás szerint történnek.


26/193


Az általánosabb megfogalmazás érdekében a szorosan vett pénzforgalmi szemléletű kiadások

helyett,

a

költség/kiadás

illetve

helyenként

a

költségnem

fogalmakat

használjuk. LOGO-VIR szempontból tehát költségek/kiadások közgazdasági osztályozása szerinti 5-ös (kiadások előirányzat teljesítése) számlaosztályon valamint a funkcionális osztályozás szerinti 7-es (tevékenységek kiadási előirányzat teljesítése) számlaosztályon lekönyvelt bizonylatok jelentik az alapadatokat az intézményi gazdálkodásának. Látható,

hogy

a

Forrás

SQL-ben

található

gazdálkodási

pontossága,

teljessége

alapvetően határozza meg a LOGO-VIR lehetőségeit. A pontosság és teljesség ebben az esetben

nem

egy

zárt

számviteli

rendszerre

jellemző,

számviteli

alapelvekkel

hivatkozható elvárások. Esetünkben ezen fogalmak az alábbi kritikus területeken ragadhatóak meg: elvárás, hogy minden közvetlenül a tagintézményen/telephelyen jelentkező költség/kiadás

az

adott

tagintézmény/telephely

elszámolási

egységéhez

rendelődjön (ANK esetén az intézményegységeket/telephelyeket reprezentáló ügyletkódhoz) amennyiben ez az elsődleges könyveléskor nem így történik, akkor az intézményszinten jelentkező egyéb költségekkel/kiadásokkal együtt felosztásra kerüljenek -> költségfelosztás elvárás, hogy valamennyi költség/kiadás a valódi szakfeladathoz rendelődjön, amennyiben ez az elsődleges könyveléskor nem lehetséges (nincs, vagy nem a megfelelő szakfeladat), akkor szükséges még funkcionálisan nem besorolt (elsődlegesen a 6-os közvetett /általános/ kiadások számlaosztályhoz rendelet) vagy

funkcionálisan

elsődlegesen

nem

a

végleges

helyre

sorolt

költségek/kiadások felosztása -> költségfelosztás

A

pontosság

és

költségfelosztásban

teljesség

tehát

érhető

tetten.

az

elsődleges

Vannak

könyvelésben

azonban

olyan

illetve

elsődleges

a

későbbi

könyvelési

elvárások, melyek be nem tartása már nem, vagy csak rendkívül nehezen orvosolhatóak a költségfelosztás szintjén. Az intézménystruktúrához illesztett jelenlegi elszámolási egység struktúra ellentétes


27/193


szempontok mentén is koncepcionális nehézségeket hordoz: egyik oldalról már eleve, előre kódoltan hordoz bizonyos korlátokat -> egy többcélú intézmény csak egy elszámolási kódot használ, így elszámolási egység szinten nincs lehetőség az intézményegységek elkülönítésére, míg másik oldalról bőségével teremt nem egyértelmű helyzetet -> IGSZ alatti nem önállóan gazdálkodó szervezetek (fő)intézményenként is használnak egy 00ás végű elszámolási egységet, míg az intézményközpontot szolgáltató dedikált tagintézmény/telephely is rendelkezik saját (01-es végű) elszámolási egységgel. Így

az

intézményközpont

szintjén

jelentkező

(központi

adminisztrációs)

költségek/kiadások, akár két elszámolási egységen is megjelenhetnek, egységes gyakorlat hiányában. Intézményenként eltérő könyvelési logikákat egységesíteni kell. Ennek megfelelően a megvalósítási szakaszban, illetve tesztelési időszak valamint a próbaüzem tapasztalatai alapján az IGSZ munkatársaival közösen ki kell alakítani egy egységes, valamennyi intézményre jellemző költség/kiadás könyvelési előírást.

A későbbiekben, területenként ismertetett vezetői információs riport javaslatok alapvető kiindulási alapja tehát, hogy a lehetőségekhez képest pontosan és teljeskörűen elszámolási egységekre és szakfeladatokhoz rendelődtek az intézményre jellemző költségek/kiadások. Megvalósítás során kell vizsgálni a Forrás SQL-ben jelenleg is kialakítás alatt álló költségfelosztási módszer LOGO-VIR-re gyakorolt hatását. Jelen állapotban azzal a vélelmezéssel élünk, hogy a kialakítandó módszertan jó közelítéssel képes a pontos és teljes költség/kiadás profil kialakítására, és Forrás SQL oldali informatikai támogatottságával a költségfelosztás a főkönyvi feladásokhoz (és záráshoz) kapcsolódóan havonta is megtörténik.

Ezek alapján a LOGO-VIR – Forrás SQL integrációs logikai meghatározó elemei az alábbiak: LOGO-VIR adatbázis view-n keresztül, dedikált felhasználóval olvasási joggal on-line kapcsolódva éri el a Forrás SQL adatbázis központi törzseit, illetve önálló gazdálkodású intézményeinek tételes főkönyvi adatait. LOGO-VIR a Forrás SQL főkönyvi adataiból dolgozik alapvetően – innen nyeri ki a riportokhoz és mutatószámokhoz szükséges költség/kiadás alapadatokat,


28/193


kiegészülve pár törzs adatkörrel. Főkönyvi feladások az intézmények könyvelésében folyamatosak, azonban a főkönyvi

zárások

függetlenül,

időzítése,

tudomásul

„technikája”

véve

a

intézményenként

nyitott

főkönyvi

eltérő.

időszakok

Ettől

jelentette

bizonytalanságot (ami igazából lezárt időszak újranyitásával is tettenérhető), mindig az adott tárgyév valamennyi főkönyvi időszakának adatát beolvassa a LOGO-VIR. Integrációs szempontból a lezárt év jelent konkrét adatbeolvasási feltételt. Előzőekből fakadóan minden beolvasáskor – melynek frekvenciája jelenleg még nem ismert – az adott nyitott pénzügyi év valamennyi adatát áthozza a LOGO-VIR és ezzel felülírja a korábbi beolvasást -> tehát mindig az aktuális állapot lesz elérhető a rendszerben. Így tehát, ha egy nyitott főkönyvi időszakhoz az előző beolvasás óta az integrációban érintett főkönyvi számlák tekintetében változás volt, akkor az megjelenik a LOGO-VIR-ben és ezen időszakra futatott riport vagy mutatószám származtatás is már az aktuális adatokra történik. Főkönyv(ek)ből az integráció szempontjából érintett főkönyvi számlák, melyek közgazdasági és funkcionális osztályozásban tartalmazzák a költség/kiadás adatokat a már említett 5-ös és 7-es számlaosztályban találhatóak. Főkönyvi

adatok

(főkönyv

és

napló)

fontosabb

dimenziói

integrációs

szempontból: o

Főkönyvi számlaszám – elsődleges, közgazdasági osztályozás szerinti költség/kiadás könyvelés -> 5-ös számlaosztály (beolvasás csak a számlaosztály meghatározott számla tartományaira történik)

o

Másodlagos számla szám – másodlagos, funkcionális azaz szakfeladat alapú osztályozás szerinti könyvelés -> 7-es számlaosztály (beolvasás csak a számlaosztály meghatározott számla tartományaira történik)

o

Elszámolási egység kód – intézményt, mint a költség felmerülésének helyét egyértelműen beazonosító kód

o

Pénzforrás kód – IGSZ esetén jellemzően a közüzemi költségek felosztásához használ kód, értékei a felosztás során érintett valódi elszámolási

egységek

(közüzemi

költségek

IGSZ

szintjén,

IGSZ

elszámolási egységére terhelődnek, de azok tagintézmény/telephely szinthez rendelhetőek a pénzforrás kód használatával) o

Ügylet

kód

–

ANK

által


használt

intézményegység/telephely

29/193


megjelenítési

dimenzió, mivel

ANK csak egy, közös elszámolási

egységgel rendelkezik, így az ügylet kód használatával biztosítható a költség/kiadás megbontás o

Analitikus kód – szakfeladatokat ábrázoló kód

o

Pénzügyi év – nyitott pénzügyi év

o

Időszak – főkönyvi időszak

o

Egyenleg – (elsődleges) főkönyvi számlaszám egyenlege

Elszámolási egység struktúra jelentette korlátokat pontosan fel kell térképezni és az alternatív költségmegosztási dimenziók (pl. pénzforrás kód – IGSZ alatti intézmények, valamint ügylet kód – ANK) mentén a lehetőségekhez képest maximálisan kiaknázni. Adatbeolvasás frekvenciája jelenlegi terv szintjén még nem ismert. Elvi szinten

a havi

gyakoriság lenne az ideális, gyakorlati

téren

azonban

figyelembe kell venni a Forrás SQL-ben kialakított költségfelosztási módszer technikáját

és

frekvenciáját,

valamint

a

lehetőleg

intézményenként

egységesített költség/kiadás könyvviteli gyakorlat kialakítását.

3.3.3.

Riportok, mutatószámok

Riportok és mutatószámok – akárcsak a beszámoltatás és adatforrások – jellemzően területspecifikusak, így azokat az adott terület ismertetésénél tekintjük át, még ha kiemelésre érdemes közös jellemzőjük is van. Értelemszerűen az adott terület által specifikált beszámoló formájában, az előírt rendszerességgel bekért adatforrások, valamint a Forrás SQL-ből beolvasott gazdálkodási adatok

által

kifeszített

koordinátarendszerben

helyezkednek

el

a

riportok

és

mutatószámok. Az adatbekérés teljessége, struktúrája, gyakorisága és a Forrás SQL-ből beolvasható

előirányzat

teljesülési

költség/kiadás

adatok

pontossága

(lásd

költségfelosztási kérdéseket) határozza meg a riport vagy mutatószám által biztosított eredmény korrektségét. A riportot és/vagy mutatószámot elemezve, annak eredményeit intézményi tevékenységek ellenőrzéséhez vagy döntéselőkészítéshez felhasználva, az elemzőnek tisztában kell lennie az adatforrások „minőségével” és azok korlátaival. LOGOVIR rendszerben nem lehet cél a beszámoltatásban lévő módszertani hiányok valamint az


30/193


intézmények könyvelésben lévő diszharmóniák feloldása, kiküszöbölése. Az „alapanyag” minősége alapvetően meghatározza a termék (riport, mutatószám) minőségét.

3.4. Oktatási terület – vezetői információs nézete Rendszerkoncepcióban kiemelten tárgyaltuk az oktatási terület vezetői információs igényét, azok specialitásait melyek túlmutatnak az előzőekben ismertetett részeken. A tervezési szakaszban ezen igények pontosultak, megvalósítás keretei konkretizálódtak. Következőkben

áttekintjük

az

oktatási

területtel

kapcsolatos

üzleti

megvalósítási

javaslatokat.

3.4.1.

Oktatási intézmények nyilvántartása

Mint korábban ismertettük LOGO-VIR-ben egységes szerkezetű, önkormányzati szinten közös intézmény nyilvántartást tervezünk kialakítani. Nyilvántartás tartalmazza az oktatási

ágazathoz

ágazatspecifikus

tartozó

adatait.

intézményeket,

Intézményi

rögzíti

struktúrában

azok az

ágazatfüggetlen

oktatási

illetve

intézmények

a

legszámosabb adatkör. Jellemzőjük, hogy egy intézmény (főintézmény) több telephellyel (tagintézmény) rendelkezik és tevékenységüket tekintve a közoktatási közfeladaton belül több alaptevékenységet is ellátnak (több célú intézmények, iskolaközpontok). Az oktatási intézmények fenntartói szervezetei és működési köre bővebb is lehet, mint a PMJV Önkormányzata is közigazgatási területe. A kialakítandó nyilvántartásnak természetesen reflektálnia kell ezen ábrázolási, adattárolási igényekre -> ez már a korábbi fejezetben ismertetésre került.

3.4.2.

Ellátotti adatok

Közoktatási alaptevékenység illetve a kapcsolódó kisegítő tevékenységek egyik alapvető mutatója az ellátotti létszám, az oktatási intézményekben tanuló, képzésben részesülő


31/193


gyerekek és felnőttek száma. Leegyszerűsített közgazdasági és kontrolling megközelítés szerint az oktatási intézmények tevékenységének „humán készterméke, eredménye” az ellátottak, melynek „előállítása” (oktatása, képzése) érdekében a költségek/kiadások döntő többsége közvetlenül vagy közvetetten felmerült. Ellátottak jellemző mutatója a létszám. Az ellátotti létszámadatok képezik a normatív támogatási jogcímek igénylésének az alapját. Mint ismertettük a normatív dimenzió helyett a szakfeladati dimenzió leképezése, támogatása az elsődleges szempont a LOGO-VIR rendszerben, ez a kontrolling koncepciónk alapja. Ennek

megfelelően

a

vezetői

információs

rendszerben

az

ellátottakat

(csak

létszámadatok, nincs szó személyes ellátotti nyilvántartásról) az alábbi struktúrában kell az intézményeknek beszámoló formájában rögzíteni (beszámoltatás/adatforrások): Feladat ellátási helyenként -> ez gyakorlatilag az intézményi szint (főintézmény > tagintézmény/telephely) Ezen belül szakfeladatonként -> adott intézményhez tartozó szakfeladatokhoz rendelni az ellátotti létszámot Ellátottak maximált száma – alapító okirat, engedély szerint Beszámolás tervezett gyakorisága egyszeri -> október 1-i állapot rögzítése legkésőbb október 31-ig. Jelen tervezési fázisban még nyitva hagyjuk egy esetleges, a Taninform rendszerből származó elektronikus, file alapú adatbeolvasás lehetőségét, azzal a megszorítással, hogy elsődleges adatbekérési forma az ismertetett LOGO-VIR web-es felületén elérhető beszámoló adatrögzítési felület.

A berögzített ellátotti létszámok, mint vezetői információs alapadatok felhasználásának területei (riportok/mutatószámok): Alapinformáció az irányítói és fenntartói funkciók gyakorlásához -> ellátotti adatok: o

tagintézményenként/telephelyenként (feladat ellátási hely),

o

főintézményenként

(alapító

okiratban

nevesített

intézmény,

OM

azonosítóval) o

önkormányzati szinten

o

mindezt tevékenységenként és/vagy szakfeladatonként

o

tényleges ellátotti szám viszonyítva az engedélyezett maximális számhoz > kapacitáskihasználtság


32/193


Vetítési alap fajlagos mutatók számításához -> o

1 dolgozóra (vagy azok valamilyen foglalkozás szerinti besorolására pl. szakirányú felsőfokú végzettségű, pedagógus, stb.) jutó ellátottak száma, mindez tevékenységenként és/vagy szakfeladatonként

o

egy

tagintézmény/telephelyen

(feladat

ellátási

hely)

jelentkező

közgazdasági költségek/kiadások vetítése (összköltség vagy költségnemi bontásban) ellátottakra o

funkcionális, azaz szakfeladatonkénti költség/kiadás adatokból ellátotti létszám

alapján

képzett

fajlagos

mutatók:

tagintézmény/telephely,

főintézmény vagy Önkormányzat szintjén.

Természetesen ezen megközelítés alapja a korábbiakban rögzített feltételezés a Forrás SQL-ben történő költségallokáció teljességéről

(elszámolási

egység szintre illetve

szakfeladatra), valamint az elvárás, hogy valamennyi feladat ellátási hely rendelkezik önálló elszámolási egység kóddal a Forrás SQL-ben.

3.4.3.

Foglalkoztatotti adatok

Oktatási intézményekre alapvetően jellemző, hogy összes költségük/kiadásuk mintegy 80%-át a személyi juttatások és azokat terhelő járulékok teszik ki. Az előző analógiánál maradva az oktatás és képzési tevékenység érdekében közvetlenül vagy közvetve felmerült költségek/kiadások döntő többsége az intézmény dolgozói által reprezentált „humán erőforrás” költsége. Humán erőforrás jellemző mutatószáma a foglalkoztatotti létszámadat. LOGO-VIR-ben kialakítandó vezetői információs módszertan alapján a létszámadatokat (csak létszámadatok, nincs szó személynyilvántartásról) az alábbi struktúrában kell intézményenként rögzíteni (beszámoltatás/adatforrások): Feladat

ellátási

helyenként

->

tagintézmény/telephely), kezelni

intézményi

kell

tudni

szint

(főintézmény

a részmunkaidős illetve

-> több

tagintézményben is foglalkoztatott létszámokat Szakfeladatonként -> adott intézményhez tartozó szakfeladatokhoz rendelni a dolgozói

létszámot.

Jelenleg

ez

a


bontás

az

alapja

a

KIR-IMI

havi

33/193


beszámolásnak is. Mivel az intézmények önálló bérgazdálkodást folytatnak (intézményszintű költségvetési keretek között, kiemelt előirányzat szabályai szerint),

a

Kincstár

Központosított

Illetményszámfejtő

Rendszere

(KIR)

részeként elérhető Intézményi munkaügyi információ (IMI) modul keretében havonta

szolgáltatnak

béradatokat

a

szakfeladati

bontásban

a

Magyar

Államkincstár felé. Forrás SQL automatikus interfész formájában fogadja a havi feladásokat

és

bérköltségeket

átvezeti

saját

könyvelési

rendszerében.

Intézmény a kinevezési okiratban nevesített szakfeladatok mentén kezeli az adott dolgozó bérköltségét – legalább is ez az elvárás. Ez a logika lenne a LOGO-VIR adatszolgáltatás alapja is. Foglalkozási kategóriánként -> képzettség és/vagy tevékenység szempontjából képzett kategóriák. Ezt az adott ágazatra jellemző csoportosítást a fenntartó szabadon alakíthatja ki a bevezetési fázisban (eddig konkrét kategorizálási igény csak a szociális és művelődési ágazatoktól érkezett). Mivel a kialakítandó foglalkoztatotti beszámoltatási struktúra a fix, rögzített dimenziókon túl, dinamikus besorolási dimenziókkal kombinálhatóak, így az oktatási terület által elvárt besorolások későbbiekben is kialakíthatóak. Beszámoltatás gyakorisága – illeszkednie kell Forrás SQL-ból kinyert főkönyvi adatok

gyakoriságához.

Azt

természetesen

alapvetően

befolyásolja

a

korábbiakban ismertetett, a szükséges és elvárt költségallokációs (elszámolási egység szintre illetve szakfeladatra) kérdések megoldása.

A beszámoltatás során rögzített dolgozói adatok, mint vezetői információs alapadatok felhasználásának területei (riportok/mutatószámok): Alapinformáció az irányítói és fenntartói funkciók gyakorlásához -> dolgozói létszámadatok: o

tagintézményenként/telephelyenként (feladat ellátási hely),

o

főintézményenként

(alapító

okiratban

nevesített

intézmény,

OM

azonosítóval) o


o



1 dolgozóra (vagy azok valamilyen foglalkozás szerinti besorolására pl. szakirányú felsőfokú végzettségű, pedagógus, stb.) jutó ellátottak száma,


34/193


mindez tevékenységenként és/vagy szakfeladatonként egy

o


közgazdasági

besorolás

(feladat

szerinti

ellátási

személyi

jellegű

hely)

jelentkező

költségek/kiadások

vetítése dolgozókra releváns funkcionális, azaz szakfeladatonkénti költség/kiadás adatokból

o

dolgozói

létszám

alapján

képzett

fajlagos

mutatók:

tagintézmény/telephely, főintézmény vagy Önkormányzat szintjén.

3.5. Szociális terület – vezetői információs nézete Rendszerkoncepcióban még nem szerepelt a szociális intézményi terület. Szakmai igényeit csak a tervezési fázisban ismertük meg. Következőkben áttekintjük a szociális területtel kapcsolatos üzleti megvalósítási javaslatokat. Kiemelten rögzítendő, hogy az Egészség- és Szociálpolitikai osztály eltekint az Egyesített Egészségügyi Intézmények LOGO-VIR

alapú

beszámoltatásától,

vezetői

információs

módszertanba

történő

bevonásától. Természetesen mint intézmény, telephelyével együtt szerepelni fog az egységes intézmény nyilvántartásban, de további funkciókban nem kap szerepet.

3.5.1.

Szociális intézmények nyilvántartása

Korábbi

fejezetekben

önkormányzati

ismertettük,

szinten

közös

hogy

a

intézmény

LOGO-VIR-ben nyilvántartást

egységes

szerkezetű,

tervezünk

kialakítani.

Nyilvántartás értelemszerűen tartalmazza a szociális ágazathoz tartozó intézményeket, rögzíti azok ágazatfüggetlen illetve ágazatspecifikus adatait. Intézményi struktúrában a szociális intézmények a második legszámosabb adatkör. Jellemzőjük, hogy az Egyesített Egészségügyi Intézményeken kívül, valamennyi intézmény gazdálkodás szerint az IGSZ alá

tartozik,

valamint

hogy

egy

intézmény

(főintézmény)

több

telephellyel

(tagintézmény) rendelkezik. Bizonyos szociális intézmények fenntartói szervezetei és működési köre bővebb is lehet, mint a PMJV Önkormányzata is közigazgatási területe.


35/193


3.5.2.

Ellátotti adatok

Szociális ágazathoz tartozó intézmények alaptevékenységeinek egyik jellemző alapvető mutatója az ellátotti létszám. Ellátottak jellemző mutatója a létszám illetve a gondozási nap. Gondozási napokból származtatható kalkulált létszámmutató -> gondozási napok száma osztva az ellátási napok számával. Az ellátotti létszámadatok (adott esetben az előbb ismertetett módon gondozási napokból kalkulálva) képezik a normatív támogatási jogcímek igénylésének az alapját. Ezek alapján azon szociális intézményeknél, ahol értelmezhető az ellátotti dimenzió, pontos alapadatok állnak rendelkezésre, hiszen azok a normatív támogatások megalapozásához (tervezés) és kapcsolódó beszámoláshoz is szükségesek. Ennek megfelelően a vezetői információs rendszerben az ellátottakat (csak létszámadatok illetve gondozási nap, nincs szó személyes ellátotti nyilvántartásról) az alábbi

struktúrában

kell

az

intézményeknek

beszámoló

formájában

rögzíteni

(beszámoltatás/adatforrások): Feladat ellátási helyenként -> ez gyakorlatilag az intézményi szint (főintézmény > tagintézmény/telephely) Ezen belül szakfeladatonként -> adott intézményhez tartozó szakfeladatokhoz rendelni az ellátotti létszámot és/vagy gondozási napot Ellátottak

maximált

száma

–

alapító

okirat,

működési

engedély

szerint

férőhelyszám Beszámolás tervezett gyakorisága havi, de intézményenként változhat

A berögzített ellátotti létszámok, gondozási napok, mint vezetői információs alapadatok felhasználásának területei (riportok/mutatószámok): Alapinformáció az irányítói és fenntartói funkciók gyakorlásához -> ellátotti adatok: o

tagintézményenként/telephelyenként,

o

főintézményenként (alapító okiratban nevesített intézmény)

o


o


o

tényleges ellátotti szám viszonyítva az engedélyezett maximális férőhely számhoz -> kapacitáskihasználtság


36/193



1

dolgozóra

(vagy

azok

valamilyen

besorolására

pl.

szakdolgozó,

technikai, stb.) jutó ellátottak száma (és/vagy gondozási nap), mindez tevékenységenként és/vagy szakfeladatonként o

egy


(feladat

ellátási

hely)

jelentkező

közgazdasági költségek/kiadások vetítése (összköltség vagy költségnemi bontásban) ellátottakra o

funkcionális, azaz szakfeladatonkénti költség/kiadás adatokból ellátotti létszám

alapján

képzett

fajlagos

mutatók:

tagintézmény/telephely,

főintézmény vagy Önkormányzat szintjén.

Itt is meg kell említenünk a korábbiakban ismertetett Forrás SQL vonatkozású kötöttséget (pontos és teljes költségallokáció).

3.5.3.

Foglalkoztatotti adatok

Akárcsak az oktatási intézményekre, úgy a szociális intézményekre is alapvetően jellemző, hogy összes költségük/kiadásuk jelentős részét a személyi juttatások és azokat terhelő járulékok teszik ki. LOGO-VIR-ben kialakítandó vezetői információs módszertan alapján a létszámadatokat (csak létszámadatok, nincs szó személynyilvántartásról) az alábbi struktúrában kell intézményenként rögzíteni (beszámoltatás/adatforrások): Feladat

ellátási

helyenként

->

tagintézmény/telephely), kezelni

intézményi

kell

tudni

szint

(főintézmény

a részmunkaidős illetve

-> több

tagintézményben is foglalkoztatott létszámokat Szociális intézmények bizonyos köre esetén értelmezhető a szabályozásból fakadó, ellátotti kapacitáshoz kötött tevékenység ellátásához szükséges dolgozói létszám -> ez az ellátotti létszámhoz (működési engedélyben szereplő férőhely szám) rendelt, előírt dolgozói létszám Szakfeladatonként -> adott intézményhez tartozó szakfeladatokhoz rendelni a dolgozói

létszámot.

Jelenleg

ez

a

bontás

az

alapja

a

KIR-IMI

havi

beszámolásnak is. Mivel az intézmények önálló bérgazdálkodást folytatnak


37/193


(intézményszintű költségvetési keretek között, kiemelt előirányzat szabályai szerint),

a

Kincstár

Központosított

Illetményszámfejtő

Rendszere

(KIR)

részeként elérhető Intézményi munkaügyi információ (IMI) modul keretében havonta

szolgáltatnak

béradatokat

a

szakfeladati

bontásban

a

Magyar

Államkincstár felé. Forrás SQL automatikus interfész formájában fogadja a havi feladásokat

és

bérköltségeket

átvezeti

saját

könyvelési

rendszerében.

Intézmény a kinevezési okiratban nevesített szakfeladatok mentén kezeli az adott dolgozó bérköltségét – legalább is ez az elvárás. Ez a logika lenne a LOGO-VIR adatszolgáltatás alapja is. Foglalkozási kategóriánként -> Ezt az adott ágazatra jellemző csoportosítást a fenntartó szabadon alakíthatja ki a bevezetési fázisban. Szociális területtől származó bontási igény: o

Intézményvezető

o

Szakdolgozó

o

Technikai

o

Egyéb (alapfeladaton túli tevékenységet lát el)

Beszámoltatás gyakorisága – illeszkednie kell Forrás SQL-ból kinyert főkönyvi adatok gyakoriságához.

A beszámoltatás során rögzített dolgozói adatok, mint vezetői információs alapadatok felhasználásának területei (riportok/mutatószámok): Alapinformáció az irányítói és fenntartói funkciók gyakorlásához -> dolgozói létszámadatok: o

tagintézményenként/telephelyenként,

o

főintézményenként (alapító okiratban nevesített intézmény)

o


o



1

dolgozóra

(vagy

azok

valamilyen

besorolására

pl.

szakdolgozó,

technikai, stb.) jutó ellátottak száma (és/vagy gondozási nap), mindez tevékenységenként és/vagy szakfeladatonként o

egy tagintézmény/telephelyen jelentkező közgazdasági besorolás szerinti személyi jellegű költségek/kiadások vetítése dolgozókra

o

releváns funkcionális, azaz szakfeladatonkénti költség/kiadás adatokból


38/193


dolgozói

létszám

alapján

képzett

fajlagos

mutatók:

tagintézmény/telephely, főintézmény vagy Önkormányzat szintjén.


39/193


3.6. Kulturális terület A Rendszerkoncepcióban a kulturális intézményeket nem tárgyaltuk, azonban Pécs igen gazdag kulturális élettel rendelkezik, és az idei évben Európa Kulturális Fővárosa címet viseli, így jobban előtérbe kerültek a város kulturális intézményei. A kulturális intézmények munkája ebben az évben megnövekedet, azonban ezzel arányosan a számukra

folyósított

támogatások

és

hozzájárulások

is

jelentős

mértékben

növekedtek. Így felmerült az igény a Humán Főosztály Művelődési csoportja részéről, hogy a kulturális intézmények életének pontosabb nyomon követhetősége érdekében szeretnék, ha kialakításra kerülne egy kontrolling felület, ahol látnák az egyes szervezetek működési adatait. Mivel a kontrolling rendszer kialakításában már előtte is tervben volt az Önkormányzat intézményeinek beszámoltatása, így a Művelődési csoport igénye könnyen beilleszthető volt a kialakítandó LOGO-VIR funkcionalitásba, így jelen rendszertervben már a kulturális intézmények is teret nyertek.

3.6.1.

Kulturális intézmények nyilvántartása

A kulturális intézmények jelenleg évente kötelesek beszámolni az Önkormányzat felé. A beszámolásra nincsen egy egységesen kialakított forma, ezért elég nehéz a beérkező adatokat rendszerezni és belőlük következtetéseket levonni, statisztikákat készíteni. Az intézmények az Önkormányzaton belül a Humán Főosztálynak és a Pénzügyi Osztálynak is szolgáltatnak adatokat, ezért célunk egy a mindkét fél részére hasznos

felület

kialakítása,

mely

mindkét

érintett

munkáját

jelentősen

megkönnyítené. Az intézmények és az Önkormányzat között nincsen állandó közvetlen kapcsolat, csak valamilyen

probléma esetén

van

esetleges kapcsolat

az intézmények és az

Önkormányzat között. A Művelődési csoport számára fontos, hogy naprakész információkkal rendelkezzen a kulturális intézményekről, mivel ők tartoznak irényítási és

fenntartói

felelősséggel

az

egyes

intézményekért

és

a

város

tőlük

vár

információkat a pécsi kulturális életről. A rendszer segítségével könnyen tájékoztatni lehet majd a lakosokat, hogy hány embert sikerült megszólítani az egyes kulturális programokkal. Az intézmények gazdaságossági adatain és alaptevékenységén felül a


40/193


szervezetek rendezvényeiről is szeretnének adatokat kapni, hogy ezáltal is pontosabb képhez jussanak az egyes intézményekről. A városban sok kulturális intézmény található, melyek igen szerteágazó feladatokat látnak el, és működésükben eléggé eltérőek (színházak, galériák, múzeumok). Egyesével nehezen kezelhetőek, így 3 fő csoport alá lehet besorolni őket, mely megkönnyíti a kezelésüket. A kulturális intézmények három csoportja: o

Művelődési intézmények (Kulturális központ, Ifjúsági központ)

o

Művészeti intézmények (Pécsi Nemzeti Színház, Pécsi Galéria, Horvát Színház)

o

Közgyűjtemények (Pécsi Városi Könyvtár)

A készülő rendszerben is eme három csoport alá lennének besorolva az egyes intézmények, így ez által nem csak intézmény szintű, de csoportszintű adatok is kinyerhetőek lesznek. A közgyűjtemények csoport azonban meg fog szűnni, mivel ott csak

egyetlen

intézmény

van

a

Pécsi

Városi

Könyvtár,

amely

a

megyei

társintézménnyel és a PTE Egyetemi Könyvtárral együtt Tudásközpontban fog egyesülni. Így a másik két csoport a mérvadó dimenzió. Az egyes szervezetek eléggé eltérőek mind tevékenységüket, mind működésüket tekintve, azonban a projekt során cél egy egységes struktúra kialakítása, mely minden intézmény számára egyaránt egyszerűen értelmezhető, tölthető és a szükséges adatok egyértelműen rendelkezésre állnak. Az Önkormányzat szeretne havonta beszámolót kapni az intézményektől, hogy folyamatosan értesüljön a szervezetek tevékenységeiről. Az egyes intézmények önkormányzati

támogatásban

részesülnek,

mely

támogatás

igényléséhez

a

kiadásokat tervezniük kell a szervezeteknek. A színházaknál a havi beszámoló mellet évad végén is igényelhetne beszámolót az Önkormányzat, hisz a kialakításra kerülő egységes felület erre lehetőséget ad. A rendszerben ugyancsak kialakításra kerül egy egységes foglalkoztatotti struktúra, amelyben a kulturális intézmények is rögzíteni tudják az alkalmazotti adataikat.


41/193


A kulturális intézményeken belül 3 fő beszámolói adatkört különböztetnénk meg, ezek a következők lennének: Dolgozói Gazdálkodási adatok Tevékenységgel kapcsolatos adatok Így már strukturáltabban állnának elő az adatok, és jobb áttekinthetőséget biztosítanának.

3.6.2.

Dolgozói adatok

A rendszerben ugyancsak rögzítésre kerül majd a foglalkoztatottak száma. Mivel vannak intézmények melyek működési költségük jelentős hányadát az alkalmazottak bérköltsége teszi ki, így hasznos, ha az Önkormányzat rendelkezik a szervezetek létszámadatával. Az egyes intézményeknek az alábbi bontásban kell majd adatot szolgáltatniuk: Mező

Leírás

Teljes

munkaidőben

Az adatszolgáltató kulturális intézménynél teljes munkaidőben

foglalkoztatott létszám

foglalkoztatottak száma.

Részmunkaidőben

Az adatszolgáltató kulturális intézménynél rész munkaidőben

foglalkoztatott létszám

foglalkoztatottak száma.

Átmeneti humán erőforrás

Nem aktív foglalkoztatott

Az

adatszolgáltató

kulturális

intézménynél

átmenetileg

foglalkoztatottak száma. Az

adatszolgáltató

kulturális

intézménynél

a

nem

aktív

foglalkoztatottak száma. (GYES, GYED, Táppénz) Felsőfokú

végzettséggel

rendelkezők száma

Szakirányú végzettséggel száma

Az

adatszolgáltató

kulturális

intézménynél

felsőfokú

végzettséggel rendelkezők száma. felsőfokú rendelkezők

Az adatszolgáltató kulturális intézménynél szakirányú felsőfokú képzettséggel rendelkezők száma.


42/193


Középfokú

végzettséggel

Az

rendelkezők száma

Szakirányú

kulturális

intézménynél

középfokú

intézménynél

szakirányú

képzettséggel rendelkezők száma.

középfokú

végzettséggel

adatszolgáltató

Az

rendelkezők

adatszolgáltató

kulturális

középfokú képzettséggel rendelkezők száma.

száma

Az adatszolgáltató kulturális intézménynél azon alkalmazottak száma, akik a felső kategóriákban nem tartoznak, de az

Egyéb

intézmény tevékenységéhez közvetlenül kapcsolódó munkát végeznek.

Az adatszolgáltató kulturális intézménynél azon alkalmazottak száma, akik a felső kategóriákban nem tartoznak, de az

Egyéb támogató

intézmény

tevékenységéhez

közvetlenül

NEM

kapcsolódó

munkát végeznek. (pl. takarító)

Az adatszolgáltató kulturális intézménynél az alkalmazottak

Átlag létszám

3.6.3.

átlag létszáma.

Gazdálkodási adatok

Ezen a részen az egyes intézmények gazdálkodási adatai kerülnek nyilvántartásra. A Humán Főosztály számára fontosak a gazdálkodási adatok, hogy lássák, hogy az alájuk tartozó egyes intézmények hogyan boldogulnak. A Pénzügyi Osztálynak a művészeti támogatás igénybevételéhez adatokat kell szolgáltatniuk a Kulturális és Örökségvédelmi Hivatal számára. A kialakításra kerülő rendszer

segítségével

már

nem

kellene

külön

adatot

bekérni

az

egyes

intézményektől, hisz a havi beszámolásnak köszönhetően a szükséges adatok már előállnak majd a rendszerben. A következő adatok kerülnének bekérésre az egyes intézményektől: Mező

Leírás


43/193


Önkormányzati

támogatás

mértéke

adatszolgáltató

kulturális

intézmény

önkormányzati

támogatásának mértéke.

Tervezett bevétel összesen

Tervezett kiadás összesen

Az adatszolgáltató kulturális intézménynél az adott hónapban tervezett bevétel összesen. Az adatszolgáltató kulturális intézménynél az adott hónapban tervezett kiadás összesen. Az adatszolgáltató kulturális intézménynél az adott hónapban

Bevétel összesen

a bevétel összesen. Az adatszolgáltató kulturális intézménynél az adott hónapban

Kiadás összesen

a kiadás összesen.

Belépőjegyet fizetők száma

Saját előadások nézőszáma

Fogadott

Az

előadások

nézőszáma

Az adatszolgáltató kulturális intézménynél az adott hónapban a belépőjegyet fizetők száma. Az adatszolgáltató kulturális intézménynél az adott hónapban a székhelyen játszott saját előadások fizető nézőinek száma. Az

adatszolgáltató

kulturális

intézménynél

a

fogadott

előadások fizető nézőinek száma. Az adatszolgáltató kulturális intézménynél az adott hónapban

Tájelőadás nézőszáma

a székhelyen kívül játszott saját előadások fizető nézőinek száma.

Belépőjegy bevétel összesen

Bérletes látogatók száma

Az adatszolgáltató kulturális intézménynél az adott hónapban a belépőjegy bevétel összesen. Az adatszolgáltató kulturális intézménynél az adott hónapban a bérletes látogatók száma. Az adatszolgáltató kulturális intézménynél az adott évadban a

Bérlet bevétel összesen

bérlet bevétel összesen. (Ez csak évadról való beszámolás esetén.)

Tájelőadás bevétele

Az adatszolgáltató kulturális intézménynél az adott hónapban tájelőadásból származó bevétel. Az adatszolgáltató kulturális intézménynél az adott hónapban

Egyéb bevételek

a

nem

önkormányzati

finanszírozásból

származó

egyéb

bevételek


44/193


Összes előadás száma

Saját előadások száma

Fogadott előadások száma

Tájelőadások száma

Ezen

adatok

alapján

Az adatszolgáltató kulturális intézménynél az adott hónapban az összes előadás száma.

Az adatszolgáltató kulturális intézménynél az adott hónapban a székhelyen játszott saját előadások száma.

Az

adatszolgáltató

kulturális

intézménynél

a

fogadott

előadások száma.

Az adatszolgáltató kulturális intézménynél az adott hónapban a székhelyen kívül játszott saját előadások száma.

átfogó

képet

lehet

kialakítani

az

előadások

átlagos

látogatottságáról és gazdaságosságáról, valamint az egyéb gazdasági mutatók is hasznos információkat szolgáltatnak a fenntartó számára.

3.6.4.

Tevékenységi adatok

A tevékenységekről, rendezvényekről szolgáltatott adatokkal egy átfogóbb kép tárul az ember elé a város kulturális életéről. A szervezetek tulajdonában levő előadó termek, kiállítótermek is fontos információt hordoznak az Önkormányzat számára, hisz gyakran tartanak rendezvényeket az egyes szervezetek más városi intézmény termeiben is. A szervezetek működésével, telephelyével

és rendezvényeivel kapcsolatban a

következő adatok kerülnének bekérésre: Mező

Leírás

Szervezeti egységek

Az adatszolgáltató kulturális intézmény alá tartozó szervezeti egységek, telephelyek.


45/193


Szezonálisan

működő

Az adatszolgáltató kulturális intézmény alá tartozó szezonálisan

szervezeti egységek

működő szervezeti egységek, telephelyek.

Rendezvény helyszínek

Az adatszolgáltató kulturális intézmény alá tartozó intézményi kezelésben lévő rendezvény helyszín (helyszínek). Az adatszolgáltató kulturális intézmény alá tartozó intézményi

Befogadóképesség

kezelésben

lévő

rendezvény

helyszín

(helyszínek)

befogadóképessége. Az adatszolgáltató kulturális intézmény alá tartozó intézményi Alapterület helységenként

kezelésben lévő rendezvény helyszín (helyszínek) alapterülete helységenként.

Tevékenységek

Rendezvény

Az adatszolgáltató kulturális intézmény alaptevékenységei.

típusa

kategóriákra bontva

Az Rendezvény helyszínek

adatszolgáltató

rendezvényeinek

a

kulturális színhelye.

intézmény

adott

havi

(Jelenleg

létezik

egy

rendezvényhelyszíni lista, abból kiindulva.) Az adatszolgáltató kulturális intézménynél működő művészeti Művészeti csoportok száma

csoportok, klubok, körök, szakkörök, művelődési-alkotó körök száma. Az adatszolgáltató kulturális intézménynél működő művészeti csoportok, klubok, körök, szakkörök, művelődési-alkotó körök

Művészeti csoportok típusa

típusa kategóriákra bontva. (zenei, képzőművészeti, filmművészeti, táncművészeti, egyéb) Az adatszolgáltató kulturális intézménynél működő művészeti csoportok, klubok, körök, szakkörök, művelődési-alkotó körök

Korösszetétel

látogatóinak megoszlása korösszetétel alapján. 0-6, 7-14, 15-18, 18-30, 30-60, 60-


46/193


Az adatszolgáltató kulturális intézménynél működő művészeti Látogatói taglétszám összesen

csoportok, klubok, körök, szakkörök, művelődési-alkotó körök látogató létszáma összesen.

Ezen adatok alapján kimutatást lehet készíteni, hogy az egyes intézmények milyen kihasználtsággal

működnek,

az egyes

kulturális

csoportok

az

emberek

mely

szegmentumát tudják megszólítani. Egy átfogóbb képet lehet adni a városi kulturális életről.


47/193


3.7. Gazdasági társaságok A Koncepciótervben nevesített második feladatcsoport az Önkormányzat által részben vagy

teljesen,

közvetve

beszámoltatása.

A

Koncepciótervben

már

vagy

közvetlenül

feladatcsoport részleteztük.

tulajdonolt

vonatkozásában Jelen

fejezetben

gazdasági

releváns a

társaságok

kérdéseket

Koncepcióterv

a

bázisán

továbbgondolt megvalósítási terv részleteit ismertetjük.

3.7.1.

Gazdasági társaságok nyilvántartása

Mint azt az általános megállapítások fejezetben is rögzítettük, az Önkormányzat nem rendelkezik

gazdasági

társaság nyilvántartással, melyben

a társaságok

egységes

szerkezetben, valamennyi leíró adatukat tartalmazva szerepelnének. Nyilvántartás nyilvánvaló előnyei: Valamennyi PMJV tulajdonú gazdasági társaságot tartalmazza, közös felületen Kezeli a tulajdonosi tagozódást (Holding -> elismert vállalatcsoport) – hierarchiák. Gazdasági társaságok adatainak nagy része nyilvános, cégkivonat formájában lekérhető, így azok strukturáltan tárolhatóak, ábrázolhatóak, megjeleníthetőek. Leíró adatok körének döntő többsége független a társasági formától és a társaság tevékenységétől, így közös nyilvántartásban foglalhatóak. Gazdasági

társaságok

számos

egyedi

azonosítóval

rendelkeznek,

melyeket

célszerű nyilvántartani (adószám, cégjegyzékszám, statisztikai számjel, stb.). Nyilvántartásokban lesznek fenntartott azonosítók, melyek jelenleg még nem ismert igény vagy előírás esetén releváns azonosítók rögzítését teszik lehetővé (pl. későbbi lehetséges integráció a Holding saját, belső kontrolling rendszerével). Gazdasági társaságokhoz egyedi LOGO-VIR azonosító rendelődik, mint minden további informatikai logika és hivatkozás alapja. Gazdasági

társaságokhoz

leíró

jelleggel,

nyilvántartás

szinten

(emellett

természetesen beszámolók alapján is) eltárolhatóak/megjeleníthetőek a dolgozói létszámadatok (összesen), mérlegfőösszeg valamint az alaptőke/törzstőke. A nyilvántartás a különböző jogosultsági beállítások és publikálási nézetek mentén


48/193


kielégítheti a belső (önkormányzati) és külső (képviselői, civil) igényeket is. Nyilvántartásban lehetőség van dokumentumokat csatolni (társasági szerződés, cégkivonat, közszolgáltatói szerződés, egyéb)

Összefoglalva: ezzel az egységes LOGO-VIR nyilvántartással a gazdasági társaságokra jellemző valamennyi adat karbantartható, tárolható. Az alábbiakben ismertetendő adattartalmat tekintjük kiinduló alapnak, melynek módosítására a Megrendelőnek a Rendszerterv véleményezése során lehetősége van.


49/193


Gazdasági társaság nyilvántartás – javasolt adattartalom

Címke

Leírás

GT azonosító

GT azonosítója

GT rövid neve

GT rövid neve

GT hosszú neve

GT hosszú neve

Társasági forma

Társasági forma

Székhely címe

Székhely címe

Levelezési címe

Levelezési címe

Telephelyek címe

Telephelyek címe

Központi telefon, fax


Email

Email

Honlap

Honlap

Cégjegyzékszám

Cégjegyzékszám

Adószám

Adószám

Statisztikai számjel


Számlavezető

bank

és

pénzforgalmi Lehetőség

több

bank

és

számlaszám

jelzőszám

megadására

Cégjegyzés dátuma


Főtevékenység

Főtevékenységek (TEÁOR 08)

További tevékenységek felsorolása

Tevékenységek felsorolása (TEÁOR 08)

Leíró mező


Közszolgáltatói szerződés és időtartama


Vezető neve és beosztása



50/193


Telefon, fax

Telefon, fax

Email

Email

Kinevezésének dátuma


Javadalmazás

Javadalmazás

Vezetőség felsorolása, díjazásuk


Igazgatóság (név, megbízás, díjazás)

Igazgatóság (név, megbízás, díjazás)

Felügyelő

bizottság

(név,

megbízás,

díjazás)

Felügyelő bizottság (név, megbízás, díjazás)

Kapcsolattartó neve és beosztása


Telefon, fax

Telefon, fax

Email

Email

Könyvvizsgáló (név, jogviszony, díjazás)

Könyvvizsgáló (név, jogviszony, díjazás)

Tulajdonosi struktúra


PMJV Önkormányzat tulajdonhányad


Tulajdonlás formája

Közvetlen vagy Holdingon keresztüli

Tulajdonosi jogok gyakorlásának formája

Utalás pl. szindikátusi szerződésre

Tulajdonos

társaság

VIR

egyedi

azonosító

GT azonosítója - közvetett tulajdonlás esetén







Dolgozói létszám

Dolgozói létszám

Mérlegfőösszeg

Mérlegfőösszeg

Pénznem

Jelenleg HUF


51/193


Alaptőke, törzstőke


Pénznem

Jelenleg HUF

Normatív állami támogatás

Szakfeladat szintű felsorolás

Önkormányzati támogatás mértéke

Aktuális év eredeti költségvetése

A két azonosító típusú kódmezőt leszámítva, valamennyi leíró mező a definiált mezőhosszig szabadon tölthető, nincs tartalmi megkötés, sem értékválasztó lista.

3.7.2.

Gazdasági társaságok beszámolói

Gazdasági

táraságoktól

szabályozott

elvárt

beszámolók,

míg

beszámolók egy

egy

másik

része

részük

az

a számviteli

törvény

önkormányzati

által

igényeknek

megfelelően lett kialakítva. LOGO-VIR rendszer feladata, hogy a definiált beszámolói formátumokat a webes adatrögzítő felületen elérhetővé tegye, az ott rögzített adatokat alapvető számszaki ellenőrzéseket követően adatbázisában eltárolja. Terveink szerint a részletesebb dolgozói létszámadatokra vonatkozó beszámolást a gazdasági társaság, a már intézményeknél ismertetett beszámolóval elégíteni ki (természetes a gazdasági társaságokra jellemző dimenziók és besorolások mentén) – így azt jelen fejezetben külön nem

említjük.

A

beszámoló

sablonok

kialakításánál

az

egységes

szerkezetek

megfogalmazására törekedtünk, mely egységes formátumok támogatni tudják az egyszerűsített és konszolidált beszámoló struktúrákat. Az egységes formátumokban a konszolidációs specialitásokat külön színekkel jelöljük.


52/193


Éves beszámoló mérlege „A”

A tétel megnevezése A.

Befektetett eszközök

I.

IMMATERIÁLIS JAVAK

1.

Alapítás-átszervezés aktivált értéke

2.

Kísérleti fejlesztés aktivált értéke

3.

Vagyoni értékű jogok

4.

Szellemi termékek

5.

Üzleti vagy cégérték

6.

Immateriális javakra adott előlegek

7

Immateriális javak értékhelyesbítése

II.

TÁRGYI ESZKÖZÖK

1.

Ingatlanok és a kapcsolódó vagyoni értékű jogok

2.

Műszaki berendezések, gépek, járművek

3.

Egyéb berendezések, felszerelések, járművek

4.

Tenyészállatok

5.

Beruházások, felújítások

6.

Beruházásokra adott előlegek

7.

Tárgyi eszközök értékhelyesbítése

III. 1.

BEFEKTETETT PÉNZÜGYI ESZKÖZÖK Tartós részesedés kapcsolt vállalkozásban


53/193


2.

Tartósan adott kölcsön kapcsolt vállalkozásban

3.

Egyéb tartós részesedés

4.

Tartósan adott kölcsön egyéb részesedési viszonyban álló vállalkozásban

5.

Egyéb tartósan adott kölcsön

6.

Tartós hitelviszonyt megtestesítő értékpapír

7.

Befektetett pénzügyi eszközök értékhelyesbítése

8.

Befektetett pénzügyi eszközök értékelési különbözete

9.

Tőkekonszolidációs különbözet leányvállalalatokból társult vállalkozásokból

B.

Forgóeszközök

I.

KÉSZLETEK

1.

Anyagok

2.

Befejezetlen termelés és félkész termékek

3.

Növendék-, hízó- és egyéb állatok

4.

Késztermékek

5.

Áruk

6.

Készletekre adott előlegek

II.

KÖVETELÉSEK

1.

Követelések áruszállításból és szolgáltatásból (vevők)

2.

Követelések kapcsolt vállalkozással szemben

3.

Követelések egyéb részesedési viszonyban lévő vállalkozással szemben

4.

Váltókövetelések


54/193


5.

Egyéb követelések

6.

Követelések értékelési különbözete

7.

Származékos ügyletek pozitív értékelési különbözete

8.

Konszolidációból adódó (számított) társasági adó követelés

III.

ÉRTÉKPAPÍROK

1.

Részesedés kapcsolt vállalkozásban

2.

Egyéb részesedés

3.

Saját részvények, saját üzletrészek

4.

Forgatási célú hitelviszonyt megtestesítő értékpapírok

5.

Értékpapírok értékelési különbözete

IV.

PÉNZESZKÖZÖK

1.

Pénztár, csekkek

2.

Bankbetétek

C.

Aktív időbeli elhatárolások

1.

Bevételek aktív időbeli elhatárolása

2.

Költségek, ráfordítások aktív időbeli elhatárolása

3.

Halasztott ráfordítások Eszközök összesen

D.

Saját tőke

I.

JEGYZETT TŐKE ebből: visszavásárolt tulajdoni részesedés névértéken

II.

JEGYZETT, DE MÉG BE NEM FIZETETT TŐKE (-)

III.

TŐKETARTALÉK


55/193


IV.

EREDMÉNYTARTALÉK

V.

LEKÖTÖTT TARTALÉK

VI.

ÉRTÉKELÉSI TARTALÉK

1.

Értékhelyesbítés értékelési tartaléka

2.

Valós értékelés értékelési tartaléka

VII.

MÉRLEG SZERINTI EREDMÉNY

VIII.

LEÁNYVÁLLALATI SAJÁT TŐKE VÁLTOZÁS (±)

IX.

KONSZOLIDÁCIÓ MIATTI VÁLTOZÁSOK (±) adósságkonszolidálás különbözetéből közbenső eredmény különbözetéből

X.

KÜLSŐ TAGOK (MÁS TULAJDONOSOK) RÉSZESEDÉSE

E.

Céltartalékok

1.

Céltartalék a várható kötelezettségekre

2.

Céltartalék a jövőbeni költségekre

3.

Egyéb céltartalék

F.

Kötelezettségek

I.

HÁTRASOROLT KÖTELEZETTSÉGEK

1.

Hátrasorolt kötelezettségek kapcsolt vállalkozással szemben

2.

Hátrasorolt

kötelezettségek

egyéb

részesedési

viszonyban

lévő

vállalkozással szemben 3.

Hátrasorolt kötelezettségek egyéb gazdálkodóval szemben

4.

Tőkekonszolidációs különbözet leányvállalatokból

II.

HOSSZÚ LEJÁRATÚ KÖTELEZETTSÉGEK


56/193


1.

Hosszú lejáratra kapott kölcsönök

2.

Átváltoztatható kötvények

3.

Tartozások kötvénykibocsátásból

4.

Beruházási és fejlesztési hitelek

5.

Egyéb hosszú lejáratú hitelek

6.

Tartós kötelezettségek kapcsolt vállalkozással szemben

7.

Tartós kötelezettségek egyéb részesedési viszonyban lévő vállalkozással szemben

8. III. 1.

Egyéb hosszú lejáratú kötelezettségek RÖVID LEJÁRATÚ KÖTELEZETTSÉGEK Rövid lejáratú kölcsönök ebből: az átváltoztatható kötvények

2.

Rövid lejáratú hitelek

3.

Vevőktől kapott előlegek

4.

Kötelezettségek áruszállításból és szolgáltatásból (szállítók)

5.

Váltótartozások

6.

Rövid lejáratú kötelezettségek kapcsolt vállalkozással szemben

7.

Rövid

lejáratú

kötelezettségek

egyéb

részesedési

viszonyban

lévő

vállalkozással szemben 8.

Egyéb rövid lejáratú kötelezettségek

9.

Kötelezettségek értékelési különbözete

10.

Származékos ügyletek negatív értékelési különbözete

11.

Konszolidálásból adódó (számított) társasági adó tartozás

G.

Passzív időbeli elhatárolások


57/193


1.

Bevételek passzív időbeli elhatárolása

2.

Költségek, ráfordítások passzív időbeli elhatárolása

3.

Halasztott bevételek Források összesen

Jelmagyarázat:

Jel sárga kiemelés

Jelentés csak a konszolidált beszámolóhoz szükséges


58/193


Éves beszámoló eredménykimutatása - Összköltség eljárás "A"

A tétel megnevezése 1.

Belföldi értékesítés nettó árbevétele

2.

Exportértékesítés nettó árbevétele

I.

Értékesítés nettó árbevétele (01+02)

3.

Saját termelésű készletek állományváltozása ±

4.

Saját előállítású eszközök aktivált értéke

II.

Aktivált saját teljesítmények értéke (±03+04)

III.

Egyéb bevételek ebből: visszaírt értékvesztés

III/A.

Adósságkonszolidálás miatt keletkező – eredményt növelő – konszolidációs különbözet

5.

Anyagköltség

6.

Igénybe vett szolgáltatások értéke

7.

Egyéb szolgáltatások értéke

8.

Eladott áruk beszerzési értéke

9.

Eladott (közvetített) szolgáltatások értéke

IV.

Anyagjellegű ráfordítások (05+06+07+08+09)

10.

Bérköltség

11.

Személyi jellegű egyéb kifizetések

12.

Bérjárulékok


59/193


V.

Személyi jellegű ráfordítások (10+11+12)

VI.

Értékcsökkenési leírás

VII.

Egyéb ráfordítások ebből: értékvesztés

VII/A.

Adósságkonszolidálás miatt keletkező – eredményt csökkentő – konszolidációs különbözet

A.

ÜZEMI (ÜZLETI) TEVÉKENYSÉG EREDMÉNYE (I±II+III+III/A-IVV-VI-VII-VII/A)

13.

Kapott (járó) osztalék és részesedés ebből: kapcsolt vállalkozástól kapott

13/a.

Kapott osztalékok társult vállalkozástól

13/b.

Kapott osztalékok egyéb részesedési viszonyban lévő vállalkozástól

14.

Részesedések értékesítésének árfolyamnyeresége ebből: kapcsolt vállalkozástól kapott

15.

Befektetett pénzügyi eszközök kamatai, árfolyamnyeresége ebből: kapcsolt vállalkozástól kapott

16.

Egyéb kapott (járó) kamatok és kamatjellegű bevételek ebből: kapcsolt vállalkozástól kapott

17.

Pénzügyi műveletek egyéb bevételei ebből: értékelési különbözet

VIII. 18.

Pénzügyi műveletek bevételei (13+14+15+16+17) Befektetett pénzügyi eszközök árfolyamvesztesége ebből: kapcsolt vállalkozásnak adott

19.

Fizetendő kamatok és kamatjellegű ráfordítások


60/193


ebből: kapcsolt vállalkozásnak adott 20.

Részesedések, értékpapírok, bankbetétek értékvesztése

21.

Pénzügyi műveletek egyéb ráfordításai ebből: értékelési különbözet

IX.

Pénzügyi műveletek ráfordításai (18+19±20+21)

B.

PÉNZÜGYI MŰVELETEK EREDMÉNYE (VIII-IX)

C.

SZOKÁSOS VÁLLALKOZÁSI EREDMÉNY (±A±B)

X.

Rendkívüli bevételek

XI.

Rendkívüli ráfordítások

D.

RENDKÍVÜLI EREDMÉNY (X-XI)

E.

ADÓZÁS ELŐTTI EREDMÉNY (±C±D)

XII. XII/A.

Adófizetési kötelezettség Konszolidálásból adódó (számított) társasági adókülönbözet (±)

F.

ADÓZOTT EREDMÉNY (±E-XII±XII/A)

22.

Eredménytartalék igénybe vétele osztalékra, részesedésre

23.

Jóváhagyott osztalék, részesedés

G.

MÉRLEG SZERINTI EREDMÉNY (±F+22-23)

Jelmagyarázat:

Jel


Jelentés

61/193


sárga kiemelés

csak a konszolidált beszámolóhoz szükséges

kék kiemelés

a konszolidált beszámolónak nem része

(piros betűszín)

a

konszolidált

eredménykimutatásra

értelmezendő


62/193


Éves beszámoló eredménykimutatása – Forgalmi költség eljárás "A"

A tétel megnevezése 1.

Belföldi értékesítés nettó árbevétele

2.

Exportértékesítés nettó árbevétele

I.

Értékesítés nettó árbevétele (01+02)

3.

Értékesítés elszámolt közvetelen önköltsége

4.

Eladott áruk beszerzési értéke

5.

Eladott (közvetített) szolgáltatások értéke

II.

Értékesítés közvetelen költségei (03+04+05)

III.

Értékesítés bruttó eredménye (I-II)

6.

Értékesítési, forgalmazási költségek

7.

Igazgatási költségek

8.

Egyéb általános költségek

IV.

Értékesítés közvetett költségei (6+7+8)

V.

Egyéb bevételek ebből: visszaírt értékvesztés

V/A.

Adósságkonszolidálás miatt keletkező – eredményt növelő – konszolidációs különbözet

VI.

Egyéb ráfordítások ebből: értékvesztés

VI/A.

Adósságkonszolidálás miatt keletkező – eredményt csökkentő – konszolidációs különbözet


63/193


A.

ÜZEMI (ÜZLETI) TEVÉKENYSÉG EREDMÉNYE (-+III-IV+V+V/A-VIVI/A)

9.

Kapott (járó) osztalék és részesedés Ebből: kapcsolt vállalkozástól kapott

9/a.

Kapott osztalékok társult vállalkozástól

9/b.

Kapott osztalékok egyéb részesedési viszonyban lévő vállalkozástól

10.

Részesedések értékesítésének árfolyamnyeresége Ebből: kapcsolt vállalkozástól kapott

11.

Befektetett pénzügyi eszközök kamatai, árfolyamnyeresége Ebből: kapcsolt vállalkozástól kapott

12.

Egyéb kapott (járó) kamatok és kamatjellegű bevételek Ebből: kapcsolt vállalkozástól kapott

13.

Pénzügyi műveletek egyéb bevételei ebből: értékelési különbözet

VII.

Pénzügyi műveletek bevételei (9+9/a+9/b+10+11+12+13)

14.

Befektetett pénzügyi eszközök árfolyamvesztesége Ebből: kapcsolt vállalkozásnak adott

15.

Fizetendő kamatok és kamatjellegű ráfordítások Ebből: kapcsolt vállalkozásnak adott

16.

Részesedések, értékpapírok, bankbetétek értékvesztése

17.

Pénzügyi műveletek egyéb ráfordításai ebből: értékelési különbözet

VIII.

Pénzügyi műveletek ráfordításai (14+15+-16+17)


64/193


B.

PÉNZÜGYI MŰVELETEK EREDMÉNYE (VII-VIII)

C.

SZOKÁSOS VÁLLALKOZÁSI EREDMÉNY (±A±B)

IX.

Rendkívüli bevételek

X.

Rendkívüli ráfordítások

D.

RENDKÍVÜLI EREDMÉNY (IX-X)

E.

ADÓZÁS ELŐTTI EREDMÉNY (±C±D)

XI. XI/A.

Adófizetési kötelezettség Konszolidálásból adódó (számított) társasági adókülönbözet (±)

F.

ADÓZOTT EREDMÉNY (±E-XI+-XI/A)

18.

Eredménytartalék igénybe vétele osztalékra, részesedésre

19.

Jóváhagyott osztalék, részesedés

G.

MÉRLEG SZERINTI EREDMÉNY (±F+18-19)

Jelmagyarázat:

Jel

Jelentés

sárga kiemelés

csak a konszolidált beszámolóhoz szükséges

kék kiemelés

a konszolidált beszámolónak nem része

(piros betűszín)

a

konszolidált

eredménykimutatásra

értelmezendő


65/193


Cash-flow kimutatás

A tétel megnevezése I.

Szokásos

tevékenységből

származó

pénzeszköz-változás

(Működési cash flow, 1-13. sorok) 1.

Adózás előtti eredmény ±

2.

Elszámolt amortizáció +

3.

Elszámolt értékvesztés és visszaírás ±

4.

Céltartalék képzés és felhasználás különbözete ±

5.

Befektetett eszközök értékesítésének eredménye ±

6.

Szállítói kötelezettség változása ±

7.

Egyéb rövid lejáratú kötelezettség változása ±

8.

Passzív időbeli elhatárolások változása ±

9.

Vevőkövetelés változása ±

10.

Forgóeszközök (vevőkövetelés és pénzeszköz nélkül) változása ±

11.

Aktív időbeli elhatárolások változása ±

12.

Fizetett, fizetendő adó (nyereség után) -

13.

Fizetett, fizetendő osztalék, részesedés -

II.

Befektetési

tevékenységből

származó


(Befektetési cash flow, 14-16. sorok) 14.

Befektetett eszközök beszerzése -

15.

Befektetett eszközök eladása +

16.

Kapott osztalék, részesedés +


66/193


III.

Pénzügyi

műveletekből

származó


(Finanszírozási cash flow, 17-27. sorok) 17.

Részvénykibocsátás, tőkebevonás bevétele +

18.

Kötvény, hitelviszonyt megtestesítő értékpapír kibocsátásának bevétele +

19.

Hitel és kölcsön felvétele +

20.

Hosszú lejáratra nyújtott kölcsönök és elhelyezett bankbetétek törlesztése, megszüntetése, beváltása +

21.

Véglegesen kapott pénzeszköz +

22.

Részvénybevonás, tőkekivonás (tőkeleszállítás) -

23.

Kötvény és hitelviszonyt megtestesítő értékpapír visszafizetése -

24.

Hitel és kölcsön törlesztése, visszafizetése -

25.

Hosszú lejáratra nyújtott kölcsönök és elhelyezett bankbetétek -

26.

Véglegesen átadott pénzeszköz -

27.

Alapítókkal szembeni, illetve egyéb hosszú lejáratú kötelezettségek változása ±

IV.

Pénzeszközök változása (±I±II±III. sorok) ±


67/193


Szolgáltatások

Információk szolgáltató(k) / szállító(k)

a szolgáltatás,

2009. I-III.

2009. évi

megállapodás

negyedévi

becsült

tartalma

költsége

költsége

szolgáltatások, beszerzések Könyvvizsgálat Gazdasági adminisztráció/könyvelés Bér és munkaügyek Jogi feladatok ellátása Közbeszerzési feladatok ellátása Épületek, gépek karbantartása


68/193

szerződés(ek ) lejárta

megjegyzés


Őrzés-védés Takarítás Informatikai

szolgáltatások,

karbantartás Honlap üzemeltetése Informatikai

eszközök

beszerzése Reklám, marketing Nyomdaipari szolgáltatások Gáz Áram Víz, szennyvíz Irodaszerek beszerzése Telekommunikáció

(telefon,

internet szolgáltatások)


69/193


Irodai berendezések (bútorok) beszerzése Járművek beszerzése Járművek karbantarása Üzemanyagbeszerzés Reprezentáció Egyéb szolgáltatások Vagyonbiztosítás

biztosított vagyon értéke,

Gépjárműbiztosítás

biztosított vagyon

értéke,

járművek száma, fajtája Hitelek

hitelfajta, hitelösszeg, törlesztés módja,


70/193


Számlavezetés,

egyéb

banki

szolgáltatások


71/193


Likviditási terv

Társaság neve:

Likviditási terv 2010 évre (eFt-ban) 2010. évi terv

I. n.évi terv

II.

n.évi

terv

terv

EREDMÉNYKIMUTATÁS PÉNZMOZGÁSSAL

JÁRÓ

TÉTELEI: BEVÉTELEK (Eredménykimutatásból) állami

normatív

támogatás önkormányzati támogatás


III.

72/193

n.évi

IV. terv

n.évi


értékesítés

nettó

árbevétele bef.

eszközök

eladása pénzügyi

műv.

bevételei pályázati támogatás egyéb bevételek BEVÉTELEK ÖSSZESEN KIADÁSOK (Eredménykimutatásból) Anyagi jellegű kiadások


73/193


igénybe vett szolgáltatások költségei (utazási,

szállásköltségek,

bérmunka;

javítási

fenntartási

és

költségek;

postaköltség;

pályázati

díjak; reklámköltség stb.) Egyéb szolgáltatások egyéb

szolgáltatások

költségei (banköltség;

hatósági,

igazgatási, biztosítási díjak) Személyi

jellegű

kiadások Ebből: Bérköltség Személyi

jellegű

egyéb

kifizetések


74/193


Bérjárulékok Egyéb ráfordítások Késedelmi

kamat,

kártérités, kötbér stb. Költségvetéssel, önkormányzattal elszámolt adók Pénzügyi ráfordítások -

fizetett

kamatok,

-

tőketörlesztés - egyéb Rendkívüli ráfordítások Véglegesen nem fejlesztési célra adott támogatás, stb. KIADÁSOK ÖSSZESEN


75/193


EREDMÉNYKIMUTATÁS PÉNZFORGALMI EGYENLEGE Nyitó pénzkészlet 2010. 01.01-én (várható) -

2009. évben kapott előlegek 2010. évi teljesítésre

Egyéb

pénzforgalmi

bevételek +

Fejlesztésre

kapott

támogatás +

Hitelfelvétel

+

Törzstőke emelés

+

Egyéb

Egyéb

pénzforgalmi

kiadások


76/193


-

2009.

évről

áthúzódó

lejárt

szállítói kötelezettségek -

2009. áthúzódó

évről egyéb

kötelezettségek (Áfa,

illeték,

bérjárulékok, stb.) -

Rövidlejáratú

hitel,

kölcsön visszafizetése -

Beruházási

hitel,

lízing tőketörlesztése -

Tervezett beruházások


77/193


-

2010.

évi

vagyonszerzési illeték kötelezettség -

Egyéb kötelezettségek

-

társasági

adó,

általános

forgalmi

adó -

egyéb

TERVEZETT

PÉNZÜGYI

EGYENLEG


78/193


3.7.3.

Riportok, mutatószámok

Önkormányzat tulajdonosi jogainak megalapozott gyakorlásához szükséges vezetői információk forrása kettős. Részben maga a berögzített beszámoló önmagában mutat valós és aktuális képet a meghatározott időszak gazdálkodási eredményeiről, vagyon, eszközök és források alakulásáról (hiszen ez a számviteli beszámolók elsődleges funkciója), másrészt a beszámolóban rögzített egyes tételek képezhetik különböző mutatószámok alapjait, melyek egyes gazdálkodási részterület (vagyoni, pénzügyi, jövedelmi) célzott vizsgálatát segítik. Vagyoni helyzet vizsgálata

Mértékegység Tárgyi eszközök aránya

%

Számítási mód Tárgyi

eszközök

Összes eszköz

Adatok forrása /

Mérleg:

A.II

Mérlegfőösszeg

Jelentés /

A működő eszközökön belül mekkora hányadot képviselnek a több éven keresztül eszközök.


79/193

használatos

tárgyi


Tárgyi

eszközök

%

fedezettsége

Saját

tőke

/

Mérleg: D / A.II

A

Tárgyi eszközök

befektetett

tárgyi

eszközökön

eszközök

belül

a

finanszírozására

-

közvetlenül a termelésben résztvevő tartósan befektetett eszközökre - a saját tőke milyen mértékben nyújt fedezetet. Forgóeszközök aránya

%

Forgóeszközök

/

Összes eszköz

Mérleg:

B

/

Mérlegfőösszeg

Az

összes

arányt

eszköz

képvisel

között

milyen

rövid

távon

a

befektetett eszközök értéke. Tőkeellátottsági mutató

%

Saját

tőke

/

Összes forrás Kötelezettségek aránya

%

%

D

Kötelezettségek

/

Kötelezettségek

/

Mérleg:

Ft

F

eszközeit

milyen

/

Az összes forráson belül mekkora a

Mérlegfőösszeg

kötelezettségek aránya.

Mérleg: F / D

A saját tőke a kötelezettségek hány

-

Mérleg: B - F.III

lejáratú

Van-e

elég

forgótőke

kötelezettségek teljesítésére.

kötelezettségek


vállalkozás

százalékát fedezi.

Forgóeszközök Rövid

A

arányban finanszírozza a saját tőke.

Saját tőke Forgótőke

/

Mérlegfőösszeg

Összes forrás Eladósodottság

Mérleg:

80/193

a


Pénzügyi helyzet vizsgálata Mértékegység Likviditási mutató

Számítási mód

Adatok forrása

Forgóeszközök / Rövid lejáratú

Mérleg: B / F.III

kötelezettségek

Jelentés A

likvid

eszközök

értékpapírok, készletek)

(követelések,

pénzeszközök a

kötelezettségek

és

rövid

lejáratú

mekkora

hányadára

nyújtanak fedezetet. Likviditási gyorsráta

(Forgóeszközök-Készletek)

/

Rövid lejáratú kötelezettségek

Mérleg: (B-B.I )

A

gyorsan

pénzzé

tehető

/ F.III

forgóeszközök

a

rövid

lejáratú

kötelezettségek

mekkora

hányadára

nyújtanak fedezetet. Dinamikus likviditási

Pénzeszközök / Rövid lejáratú

Mérleg:

ráta

kötelezettségek

F.III

B.IV

/

A

pénzeszközök

kötelezettségek

a

rövid

mekkora

lejáratú

hányadára

nyújtanak fedezetet. Szállítófedezeti hányad

%

Követelések

áruszállításból

szolgáltatásból /Kötelezettségek

és

(vevők) áruszállításból

Mérleg: F.III.4

B.II.1/

Az

esedékes

bevételek

mekkora

arányban fedezik az esedékes szállítói számlákat.

és szolgáltatásból (szállítók)


81


Jövedelmi helyzet mutatói Mértékegység Árbevételarányos

%

jövedelmezőség

Számítási mód Adózás

előtti

eredmény

/

Értékesítés

Adatok forrása

Jelentés

Eredménykimutatás: E /

Az értékesítés nettó árbevételével a

I

vállalkozás

nettó

fajlagosan

mekkora

eredményt ért el.

árbevétele Eszközarányos

%

jövedelmezőség

Adózás

előtti

eredmény / Eszközök

Eredménykimutatás E /

Az

Mérlegfőösszeg

mekkora

hányada

mutató

alakulását

összesen

eredményből

az

eszközök

térül

meg.

részben

A a

jövedelmezőség, részben az eszközök fogási sebessége befolyásolja. Tőkearányos

%

jövedelmezőség

Adózás eredmény

/

előtti

Eredménykimutatás E /

Az

Saját

Mérleg D

növekedéséhez

tőke Élőmunka

Ft / fő

termelékenysége


Értékesítés

eredmény

a

milyen

saját

tőke

mértékben

képes hozzájárulni. nettó

Eredménykimutatás I /

Az 1 fő által megtermelt árbevétel

árbevétele / Átlagos

Átlagos

nagysága.

állományi létszám

létszám

állományi

82


Eszközarányos árbevétel

Értékesítés

nettó

(eszközök

árbevétele

/

forgási

sebessége)


Az eszközállományban megtestesülő

Mérlegfőösszeg

erőforrásokkal mennyi árbevétel jött

Eszközök összesen

létre, vagyis adott periódus alatt az átlagos

eszközállomány

hányszor

térült meg az árbevételben. Tárgyi eszközök forgási

Értékesítés

sebessége

árbevétele

nettó /

Tárgyi


A tárgyi eszközökben megtestesülő

Mérleg A.II

erőforrásokkal mennyi árbevétel jött

eszközök

létre, vagyis adott periódus alatt az átlagos

tárgyieszköz-állomány

hányszor térült meg az árbevételben. Saját

tőke

forgási

sebessége

Értékesítés árbevétele

/

nettó


A saját tőke egységére jutó árbevétel

Saját

Mérleg D

nagysága.

tőke


83


3.8. Pályázat nyilvántartási és monitoring A Rendszerkoncepcióban nevesített harmadik feladatcsoport az Önkormányzat által ellátandó feladatok és a fejlesztések megvalósításához jelentős kiegészítő anyagi forrást biztosító különböző pályázatoknak az egész Önkormányzat szintjén egységes szabályozási háttérrel, egyetlen közös rendszerben történő kezelése. Jelen fejezetben a Rendszerkoncepció bázisán továbbgondolt megvalósítási terv részleteit ismertetjük.

3.8.1.

Pályázatok nyilvántartása

A LOGO-VIR projekt indulása előtt, attól függetlenül a Tisztségviselői Kabinet Stratégiai

Tervezési

Osztálya

kidolgozott

egy

a

pályázás

rendjéről

szóló

szabályzatot, amelyet a közgyűlés 2010. január 21-én elfogadott, 2010. január 25-én

életbe

lépett.

A

szabályzatban

megfogalmazott

eljárási

rendhez

kapcsolódóan az Önkormányzat LOGO rendszerének keretein belül egyszerű nyilvántartásokat alakítottak ki. Ez is jelzi, hogy markáns igény jelent meg az Önkormányzaton belül egy a pályázatok teljes körének nyilvántartását lehetővé tévő központi adattörzs kialakítására, amelynek a következő nyilvánvaló előnyökkel jár: Valamennyi olyan pályázat, amelyben a PMJV saját szervezetein kívül gazdasági társaságai érintettek, szerepelhet és karbantartható egy közös felületen. Központi tárolás, kereshetőség lehetővé teszi, hogy ez egyes projektek kapcsán érkező vagy keletkező iratok mielőbb beazonosíthatók legyen, az egyes pályázatok gazdáival együtt. A

pályázatok

alapadatainak

karbantartására,

keresésére,

lekérdezésére

alkalmas, egységes nyilvántartást, amelyet az egyes érintett szervezetek (főosztályok, intézmények, gazdasási társaságok) felelős szereplői, mint felhasználók megfelelő jogosultsági szintek mellett elérhetnek. A nyilvántartásban kezelt pályázati projektek között kapcsolat definiálható, a több ütemből álló „ernyőprojektek” kezelése is lehetővé válik. A fontos, kisebb terjedelmű vonatkozó dokumentumokat csatolása is lehetséges,


84


ugyanakkor a LOGO rendszerben fellelhető, kapcsolható dokumentumokat (határozatok, szerződések) hivatkozhatók. A

pályázatok

életciklusának

szakaszait

státuszokkal

kezelni

lehet,

az

előrehaladás egyes lépéseit dátumokkal követhető, ahol értelmezhető, ott megfelelő pénzügyi és műszaki eredményeket lehet rögzíteni és lekérdezni. A támogatói előrehaladási

szerződésben riportok

definiált

készítésével

ütemtervvel

párhuzamba

biztosítható a pályázatok

állított

megfelelő

követése, lehetőség nyílik a pénzügyi források ütemes kezelésére, az esetleges problémák proaktív kezelése.

A pályázatok jellemző életciklusa a következő: 1. Előkészítés A pályázó főosztály figyeli a megpályázható támogatásokat. A pályázó főosztály jelzi és rögzíti pályázati igényét, ehhez a közgyűlés vagy az illetékes bizottság jóváhagyását megszerzi. Kötelezettségvállalások rögzítése mellett elindul az előkészítés. 2. Pályázat elkészítése, beadása Ez előkészítés eredményének ismeretében a közgyűlés dönt a pályázat beadásáról, a vállalt kötelezettségekről, az esetlegesen szükséges partneri megállapodásokról. Megtörténik a pályázat beadása. 3. Pályázat eredményének kezelése, támogatói szerződés megkötése Mind nyertes, mind nem nyertes esetben közgyűlés elé kell vinni a pályázat eredményét, amely nyertes esetben tartalmazza a megkötendő támogatói szerződés tervezetét is. A nyertes pályázat esetén is az időközben megváltozott körülmények, illetve a ténylegesen elnyert támogatás mértékének függvényében a közgyűlés vagy megfelelő felhatalmazás birtokában az illetékes bizottság dönt a támogató szerződés aláírásáról polgármesteri felhatalmazással, erről határozat születik. A támogatói szerződést a Jogi és a Pénzügyi Főosztálynak is jóvá kell Daten-Kontor Számítástechnikai Fejlesztő és Szolgáltató Kft. Telefon: 1/279-3400; 72/552-928 Fax: 1/365-2167; 72/256-070

85


hagynia – akárcsak a többi lépéshez kapcsolódó közgyűlési határozat előterjesztését. A támogatói szerződés aláírásra kerül. 4. Kivitelezéshez kapcsolódó közbeszerezések előkészítése, lefolytatása A közbeszerzések a vonatkozó eljárási rend szerint zajlanak. A közbeszerzési pályázatok kiírásának műszaki tartalmát, az ajánlati dokumentációt, a bíráló bizottság összetételét a közgyűlés hagyja jóvá, erről egy vagy több határozat születik. A közbeszerzéssel kapcsolatos folyamatokban a Jogi és a Pénzügyi Főosztály is érintett. Sikertelen közbeszerzés esetén újabb, módosított kiírásra lehet szükség, esetleg szükséges lehet a támogatói szerződés módosítása is. Sikeres közbeszerzés esetén is szükséges lehet a támogatói szerződés módosítása,

amely

irányulhat

az

összeg,

a

műszaki

tartalom

megváltoztatására, esetleg átcsoportosításra. 5. Kivitelezői szerződések megkötése Sikeres közbeszerzési eljárás után a kivitelezői szerződések a közgyűlés jóváhagyása után kerülnek aláírásra. 6. Kivitelezés, előrehaladás követése A kivitelezés során a támogatói szerződésben rögzített időközönként vagy a felhasznált összeghatáronként előrehaladási jelentéseket kell készíteni. Az előrehaladási jelentéseket a pályázó főosztály készíti, a jelentések a kivitelezés

pénzügyi

és

műszaki

állapotára

vonatkozó

adatokat

tartalmaznak, többnyire a támogatói szerződésben megjelölt ütemeknek megfelelően. Az előrehaladásról az Egységes Monitoring Információs Rendszerben (EMIR) elektronikus jelentés készül. A kivitelezés során az előrehaladásnak megfelelően önálló kifizetési kérelmekkel a támogatási szerződésben rögzítettől eltérő ütemben is lehet támogatási összegeket lehívni.


86


7. Kivitelezés lezárása A kivitelezés következő lépésekben kerül lezárásra: o

Használatba vétel

o

Műszaki átadás

o

Birtokba vétel

o

Aktiválás – pl. vagyonkataszterbe átvezetni

Projektzárási dokumentáció készül. Megtörténik a támogatás utolsó résznek lehívása, a záró kifizetés, amely általában 20%. Támogató levelet küld, melyben lezártnak nyilvánítja a szerződést. 8. Fenntartás A támogatói szerződésben meghatározott ideig a fenntartási kötelezettsége van a pályázónak, ez az időszak általában 3, 5 vagy 10 év. Évente, 05.31-i határidővel követési jelentést kell készíteni. Az eseti ellenőrzéseket támogatni kell. 9. Fenntartási időszak lezárása A fenntartási időszak leteltével a pályázati projekt végleg lezárható.

A fenti életciklus követéséhez használandó státuszok és mérföldkő dátumok pontos köre a részletes specifikációs időszakban során még pontosítandó.

Pályázatok nyilvántartása – javasolt adattartalom: Adatmező

Leírás

Projekt neve

Projekt egyedi neve, természetes azonosítója

Projekt címe

Projekt címe, hosszabb elnevezése

Projekt kapcsolat

Kapcsolat más projekttel, azaz az adott rögzített projekt kapcsolódik-e egy másik projekthez részprojektként vagy főprojektként


87


Projekt leírás

A projekt tartalmának rövid ismertetése

Projekt akcióterülete

A projekt akcióterülete, a projekt megvalósulásának földrajzi vagy szervezeti helyszíne.

Projekt státusza

A státusz a projekt megvalósulásának fázisa: előkészítés alatt, értékelés alatt, megvalósítás alatt, fenntartási időszak alatt, elutasított

Kötelező önkormányzati feladatot támogató projekt

Igen vagy Nem

Pályázat finanszírozásának forrása

A forrást, amelyből a projekt finanszírozása történik. (pl.: ROP, TÁMOP, GOP, stb.)

Támogatás mértéke %

Támogatás mértéke %-ban (Ebből származtatható az önerő)

Pályázati azonosító

A forrás,amelyből a projekt finanszírozása történik. (pl.: ROP, TÁMOP, GOP, stb.)

Támogatási szerződés kódja

A pályázati felhívásban szereplő pályázati azonosító

Projektbefogadó intézmény megnevezése

A közreműködő szervezet (intézménytörzsből)

Irányító hatóság megnevezése

Irányító hatóság

Projektgazda neve

A pályázó intézmény (intézménytörzsből)

Projektlebonyolító szervezet

Az a szervezet vagy szervezeti egység, ahol a projekt menedzselése folyik

Projektvezető neve

Projektvezető személy neve

Projektbe bevont partner(ek)

Amennyiben a projekt előkészítésébe, lebonyolításába a kedvezményezetten túl más szervezet(ek) partnerként közreműködtek, azok nevét(eit) kell itt feltüntetni

Projektpartnerként a lebonyolító szervezet

Partner szervezet csak Pécs M. J. Város önkormányzatára vonatkozóan

Projektpartnerként a projektfelelős neve

Projektpartner oldaláról felelős személy neve

Projekt tervezett kezdése

Tervezett kezdési dátum

Projekt tervezett befejezése

Tervezett befejezési dátum

Projekt kezdése

Tényleges kezdési dátum

Projekt tényleges befejezése

Tényleges befejezési dátum

Önerő összege

Származtatott összeg a támogatás arányából az összköltség alapján


88


Önerőt jóváhagyó Közgyűlési Határozat száma

Ha van ilyen

Projektelszámolás pénzneme

Pénznem (általában forint vagy euró)

Projekt tervezett költsége

Projekt tervezett összköltsége az elszámolás pénznemében

Projekt tényleges költsége

Projekt tényleges összköltsége az elszámolás pénznemében az elszámoláskor

Fenntartási időszak

Kötelező fenntartási időszak (év)

Projekt fenntartási költsége

Tervezett fenntartási összeg Pl. vonatkozó önkormányzati határozatok

A projekthez kötődő elektronikus dokumentumok csatolhatók az adatbázishoz

3.8.2.

Pályázatokhoz kapcsolódó beszámolók

Az érintett szervezetek erre delegált felhasználóinak számára biztosítani kell az elektronikus adatszolgáltatás lehetőségét a jelenleg meghatározott adatlap sablonok

tartalmi

elemeivel

(igénybejelentő,

adatlap,

pályázati,

igény,

előrehaladás, pénzügyi adatok, eredmény beszámoló). Rendkívül fontos, hogy a beszámolók struktúrája kizárólag olyan adatokat követeljen meg az adatszolgáltatóktól, amelynek kitöltése sem mennyiségben, sem bonyolultságban nem jelent riasztó akadályt, ugyanakkor kellő mélységben leírják a pályázatot, illetve annak státuszait. Kiemelt fontosságú a pályázatok életciklusának kezdetén használandó igénybejelentő, hiszen ezen keresztül valósulhat meg az a kívánatos cél, hogy az egységesen azonosított pályázatokról mielőbb valamennyi érintett szervezet és szereplő értesüljön. Az vonatkozó önkormányzati rendelet mellékletében meghatározott tartalomban a következő adatszolgáltatási űrlapok, beszámolók kerülnek kialakításra: Pályázati igénybejelentő (egyszer, az igény felbukkanásakor) Pályázat alapadatai (csak új projekt vagy változás esetén) Előrehaladási adatlap (indikátorok és pénzügyi adatok a szabályzatnak megfelelő periódusban)

3.8.3.

Riportok, kimutatások

Az Önkormányzat pályázatokról szükséges vezetői információk köre alapvetően


89


két részre osztható: A projektek beazonosítása alapadataik alapján - szervezeti, személyi függőségeik feltárása, határidő és volumen szerinti rangsorolása A projektek előrehaladásának monitorozása, tervezett és valós időbeli forrásfelhasználásuk követése A specifikációs időszakban pontosan kell definiálni a pályázatokkal kapcsolatos riportok pontos tartalmi és formai elemeit, a következő néhány alapvető lekérdezési lehetőséget a rendszer biztosítja: Költségvetési évfordulón áthúzódó projektek Futó/lezárt projektek Támogatás/teljes költségkeret -> finanszírozási lefedettség Forrásfelhasználás időbeli eloszlása

3.9. Helyben központos közbeszerzés A kontrolling (vezetői

információs) rendszer kialakítása projekt keretében

áttekintettük Pécs Megyei Jogú Város Önkormányzatának helyben központosított közbeszerzési folyamatait és szabályozását, valamint az ezt támogató szervezeti és technológia hátteret. Jelen fejezet ennek a vizsgálatnak az eredményeit foglalja össze. A helyben központosított

közbeszerzés áttekintésekor nem tértünk

ki

az

Önkormányzat általános közbeszerzési folyamataira. Csak magának a helyben központosított közbeszerzésnek a speciális elemeivel foglalkoztunk. Megvizsgáltuk ennek jelenlegi menetét, szabályait, gyakorlatát, valós megrendelői igényeket és elemeztük

a

folyamatok

esetleges

módosításának,

optimalizálásának

lehetőségeit, az ezekből származó esetleges előnyöket vagy nehézségeket. Vizsgálatunk eredményeként a Helyben központosított közbeszerzést nem vonjuk be a LOGO-VIR feladatkörébe, informatikai támogatását jelen projekt keretében nem biztosítjuk.

A

helyben

központosított

közbeszerzések


elrendelésének,

szabályozásának

90


alapvető célja a segítségével elérhető kedvezőbb alkupozíciók lehetőségének biztosítása valamint az egyes intézmények és önkormányzati tulajdonú gazdasági társaságok beszerzési tevékenységeinek koordinálása volt. Az Önkormányzat a kedvezőbb

alkupozíciókkal

olcsóbb

és/vagy

bővebb

műszaki

tartamú

beszerzéseket kívánt elérni a helyben központosított beszerzések rendszerében (továbbiakban Rendszer) lebonyolítandó nagyobb mennyiségű beszerzések révén.

3.9.1.

Szabályozási háttér

Az Önkormányzat helyben központosított közbeszerzéseinek folyamatát a Pécs Megyei Jogú Város Önkormányzata Közgyűlésének 22/2008. (06.02.) rendelete (továbbiakban Rendelet) szabályozza, figyelembe véve a közbeszerzésekről szóló 2003. évi CXXIX. törvény (továbbiakban Kbt.) előírásait. Ezeken túl az Önkormányzat általános közbeszerzési folyamatainak szabályait Pécs Megyei Jogú Város Közbeszerzési Szabályzata tartalmazza. Áttekintettük a Közbeszerzési Szabályzatot is, de azt csak a helyben központosított közbeszerzési folyamatra gyakorolt hatása mentén vizsgáltuk. Ahogy arra a bevezetőben is kitértünk,

elemzésünkben

nem

foglalkozunk

az

Önkormányzat

általános

közbeszerzési folyamataival, gyakorlatával.

Az

Önkormányzatnál

központosított intézmények

közbeszerzéseket. körét,

központosított

részletesen amelyek

és Így

pontosan

meghatározták

kötelezően

közbeszerzésekben,

szabályozták

illetve

részt

azon

kell,

lehetőséget

hogy

a

helyben

önkormányzati vegyenek

biztosítottak

a

egyéb

szervezeteknek is a csatlakozásra. Pontosan meghatározták azon áruk és szolgáltatások körét, melyek beszerzésére vonatkozóan a helyben központosított közbeszerzés szabályait kell alkalmazni. Emellett

részletesen

szabályozták

a

helyben

központosított

közbeszerzés

folyamatát, a folyamathoz csatlakozó intézmények, valamint az Önkormányzat feladatait, a feladatokhoz rendelt határidőkkel együtt.

A

további

fejezetekben

részletesen

ismertetjük


a

helyben

központosított

91


közbeszerzés résztvevőit, tárgyi hatályát, a beszerzés folyamatait és szabályait.

3.9.2.

A helyben központosított közbeszerzések résztvevői

A helyben központosított közbeszerzések résztvevői az alábbiak: Pécs Megyei Jogú Város Önkormányzata, melynek adminisztratív feladatait Pécs Megyei Jogú Város Polgármesteri Hivatala (továbbiakban Hivatal) látja

el.

Az

tekintetében

Önkormányzat, -

a

Hivatal

illetve

a

-

helyben

az

adminisztratív

központosított

feladatok

közbeszerzési

rendszerben az ajánlatkérésére kizárólagosan feljogosított szervezet, amely működteti a Rendszert, valamint lefolytatja az ennek keretében megvalósítandó közbeszerzéseket. A Rendszerben részt vevő intézmények: a Rendszerhez kötelezően vagy önkéntesen csatlakozó szervezetek. Ide tartoznak: o

A Rendszerhez kötelezően csatlakozó, az Önkormányzat által fenntartott

költségvetési

szervek.

Ezen

költségvetési

szervek

listáját jelen dokumentum 1. számú Melléklete tartalmazza. o

A helyben központosított közbeszerzési rendszerhez önkéntesen csatlakozó szervezetek. Ezen szervezetek: 

A Kbt. hatálya alá tartozó egyéb gazdálkodó szervek, melyek felett az Önkormányzat meghatározó befolyást képes gyakorolni. A Rendszerhez – közbeszerzésenként történő csatlakozásról az Önkormányzattal megállapodást kötnek.



Az előbbi szervezeteken kívül más szervezet is csatlakozhat önkéntesen a rendszerhez, egyedi megállapodások alapján.

Áruszállítók Rendszerben

vagy az

szolgáltatást

nyújtók:

Önkormányzattal

azon

áruszállításra

felek, vagy

amelyek

a

szolgáltatás

nyújtására szerződtek.

3.9.3.

A helyben központosított közbeszerzések tárgyi hatálya


92


Az Önkormányzat pontosan meghatározta azon áruk és szolgáltatások körét, melyekre vonatkozóan a helyben központosított közbeszerzések kiterjednek. Ezen áruk és szolgáltatások listáját alábbi táblázat tartalmazza.


93


A helyben központosított közbeszerzések tárgyi hatálya - cikktörzs

Sorszám

Megnevezés

Közös közbeszerzési szószedet szerinti CPV-kód

Áruk 1.

Élelmiszer-feldolgozás termékei és italok

15.00.00.00-8

2.

Munkaruházat, különleges munkaruha és kiegészítők

18.10.00.00-0

3.

Különféle fapép, papír és papírtermékek

21.00.00.00-3

4.

Különféle nyomtatott anyagok és nyomdai áruk

22.00.00.00-0

5.

Étkezési utalvány (Ebédjegy)

22.86.70.00-5

6.

Kőolajtermékek és tüzelőanyagok

23.00.00.00-7

7.

Tisztítószerek

24.51.30.00-3

8.

Gyógyszerészeti áruk

25.12.23.20-1

9.

Irodai és számítástechnikai gépek, berendezések és kellékek

30.00.00.00-9

10.

Gyógyászati és laboratóriumi eszközök, optikai és precíziós eszközök, órák, gyógyszerészeti és kapcsolódó gyógyászati fogyóeszközök

33.00.00.00-0

11.

Megmunkált áruk, bútorok, kézműipari és különleges célú termékek és kapcsolódó fogyóeszközök

36.00.00.00-1

12.

Villamos áram

40.10.00.00-3

Szolgáltatások 13.

Távhőszolgáltatás

40.34.00.00-7

14.

Javítási, karbantartási és szerelési szolgáltatások

50.00.00.00-5

15.

Villamos elosztó- és vezérlőberendezéssel kapcsolatos beszerelési szolgáltatások

50.91.12.00-6

16.

Villamos elosztóberendezéssel kapcsolatos beszerelési szolgáltatások

50.91.12.10-9


94


17.

Villamos vezérlőberendezéssel kapcsolatos beszerelési szolgáltatások

50.91.12.20-2

18.

Étkezdei és élelmezési szolgáltatások

55.50.00.00-5

19.

Szárazföldi utasszállítási szolgáltatás

60.11.00.00-2

20.

Szárazföldi áruszállítási szolgáltatás

60.12.00.00-5

21.

Távközlési Szolgáltatások

22.

Közművek, közhasznú szolgáltatások

65.00.00.00-3

23.

Pénzügyi közvetítő szolgáltatások

66.00.00.00-0

24.

Jogi szolgáltatások

74.11.00.00-3

25.

Jogi tanácsadási és képviseleti szolgáltatások

74.11.10.00-0

26.

Jogi tanácsadási szolgáltatások

74.11.11.00-1

27.

Jogi képviseleti szolgáltatások

74.11.12.00-2

28.

Áramszolgáltatás

74.23.14.10-4

29.

Villamosenergia-rendszerekkel tervezési szolgáltatások

30.

Őrzési szolgáltatások

74.61.30.00-9

31.

Irodatakarítási szolgáltatások

74.75.00.00-1

32.

Iskolatakarítási szolgáltatások

74.76.00.00-4

33.

Telefonkezelői szolgáltatások

74.83.11.10-7

3.9.4.

(2) 64.20.00.008(2)

kapcsolatos

mérnöki

74.23.23.10-0

A helyben központosított közbeszerzés folyamata

I. Igények összegyűjtése

A Rendszerben levő intézmények minden év március 30-ig, vagy ha ez nem munkanap, az azt követő első munkanapig írásban leadják a Hivatal részére a tárgyévi beszerzési igényeiket. Ennek során az alábbi adatokat meg kell adniuk: intézmény adatai (név, székhely, bankszámlaszám, adószám, képviselő),


95


kapcsolattartó neve, az áru vagy szolgáltatás pontos megnevezése, az áru vagy szolgáltatás mennyisége (az egyirányú esetleges eltérés %-os megadásával), a beszerzés becsült értéke, teljesítés kívánt ideje, áruszállítás megkezdésének időpontjai; szolgáltatás megkezdésének időpontjai. Amennyiben van keretszerződés a beszerzési igényben foglalt árura vagy szolgáltatásra, ez legkorábban az adott beszerzési igény bejelentésének határidejét követő 30. nap, amennyiben nincs, 90. nap lehet. teljesítés helye.

Amennyiben a leadott beszerzési igényekben időközben változás áll be, vagy új igény merül fel, az intézményeknek legkésőbb a megjelölt első teljesítési időpontot megelőzően a Hivatalnak ezt írásban be kell jelenteniük.

Igények benyújtásának elmulasztása

Az Önkormányzatnál részletesen szabályozták az intézményi igények leadásának elmulasztása esetén a tennivalókat, szankciókat. Ennek értelmében amennyiben az intézmények a tárgyévi beszerzési igényeiket a március 30-i határidőre nem küldik meg, akkor a Hivatal az érintett szerv vezetőjének figyelmét erre a mulasztásra felhívja, és határidőt tűz ki a nyilatkozat benyújtására.

Mindemellett

figyelmezteti

az

intézményt

az

esetleges

jogkövetkezményre is. Amennyiben ez a felhívás sem hozott eredményt, vagyis a szervezet továbbra sem nyújtja be a beszerzési igényeit, a Hivatal az adott szervezet következő évi beszerzéseit a megelőző évivel megegyezően állítja be a tervbe, kivéve, ha a rendelkezésére álló adatok annak módosulását alátámasztják. A szervezet ezeket a beszerzési tárgyakat köteles lesz beszerezni. A felszólítás eredménytelensége esetén a Hivatal értesíti a fegyelmi eljárás megindítására (egyéb rendszerben részt vevő szervezet esetén a kinevezésre illetve visszahívásra) jogosult szervet.


96


II. Beszerzési igények összesítése központi szinten

Az intézmények tárgyévi beszerzési igényeit a Hivatal összesíti egy külön nyilvántartásban. Majd, figyelembe véve a hatályos önkormányzati költségvetési előirányzatokat, összeállítja a Hivatal közbeszerzési tervét a tárgyév április 15-ig.

A beszerzési igényeket tartalmazó adatbázist a Hivatal folyamatosan aktualizálja, karbantartja, és ennek figyelembevételével megtervezi és előkészíti a Rendszer keretén belül megvalósítandó közbeszerzéseket.

III. A rendszerhez történő önkéntes csatlakozás folyamata

A Hivatal az összesített közbeszerzési tervről minden év április 20-ig, illetve a közbeszerzésekről

hozott

közgyűlési

döntést

követően

tájékoztatja

azon

szervezeteket, melyek önkéntesen csatlakozhatnak a Rendszerhez. Az önkéntes csatlakozásra az adott közbeszerzésről hozott közgyűlési döntéstől számított 30. napig van lehetőség.

A csatlakozás iránti kérelmet a csatlakozni szándékozó szervezeteknek a Hivatalhoz kell benyújtaniuk. A kérelem elfogadásáról a Gazdasági Bizottság dönt. Az egyedi megállapodások alapján csatlakozási kérelmüket benyújtó szervezetek csatlakozási kérelméről a Polgármester dönt. A Hivatal a csatlakozást elutasíthatja, ha a már megkötött szerződések alapján nem látja biztosítottnak valamennyi, a rendszerben kötelezően részt vevő, illetve korábban önkéntesen csatlakozott szervezet addig bejelentett igényeinek a teljes kielégítését.

Kilépés a Rendszerből


97


Az önkéntesen csatlakozott szervezet a rendszerből kiléphet. A kilépésre minden év december 31. napjával van lehetőség. A kilépési szándékot legalább 60 nappal korábban írásban kell bejelenteni a Hivatal felé. Kivételt képez ez alól, ha az adott önként csatlakozott rendszerben részt vevő szervezetet a tulajdonos megszünteti, vagy az egyéb módon megszűnik, vagy az Önkormányzat közvetlen vagy közvetett tulajdoni részesedése az adott, rendszerben részt vevő szervezetben teljes egészében megszűnik.

IV. A közbeszerzések lebonyolítása

A beszerzési igények alapján a szükséges közbeszerzéseket a Hivatal folytatja le. Ennek során mind a Kbt. rendelkezéseit, mind az Önkormányzat Közbeszerzési Szabályzatát figyelembe kell vennie. Amennyiben szükséges, az esetleges jogorvoslati eljárásokban is a Hivatal jár el. Speciális esetekben, szakmai ismereteket is igénylő beszerzések esetén a Hivatal külső

szakértőt,

bonyolító

céget

is

megbízhat

a

közbeszerzési

eljárások

lebonyolításával.

A Hivatal a helyben központosított közbeszerzési eljárás megindítását megelőzően legalább 5 munkanappal tájékoztatja az intézményeket: a közbeszerzési eljárás megindításának napjáról, a közbeszerzési eljárás tárgyáról és megnevezéséről, a közbeszerzési eljárás becsült értékéről, a közbeszerzési eljárás eljárásrendjéről és eljárási típusáról, a szerződéskötés tervezett időpontjáról.

A Hivatal a beszerzésekhez kapcsolódó alábbi eseményekről is tájékoztatja az


98


intézményeket: az ajánlatok bontásáról, az eredményhirdetésről, illetve annak hiányában az összegezésről, az esetleges jogorvoslati eljárásról, a szerződés megkötésének időpontjáról.

Beszerzések lebonyolítása saját hatáskörben

Az intézmények a Rendelet hatálya alá tartozó áruk és szolgáltatások beszerzését a Hivatal előzetes írásbeli engedélye alapján saját hatáskörben is lefolytathatják, különösen azokban az esetekben, ha az összesített beszerzési igény nem közbeszerzésköteles, a

beszerzési

igényben

szereplő

árura

vagy

szolgáltatásra

nincs

keretszerződés vagy a beszerzési igény sürgőssége miatt a Rendeletben előírt határidők nem lennének tarthatók.

A saját hatáskörben történő beszerzés megvalósulását követően az Intézmény legkésőbb a szerződéskötést vagy megrendelést követő 5 munkanapon belül az alábbi adatokat közli írásban a Hivatallal: intézmény adatai (név, székhely, bankszámlaszám, adószám, képviselő), kapcsolattartó neve, az áru vagy szolgáltatás pontos megnevezése, az áru vagy szolgáltatás mennyisége (az egyirányú esetleges eltérés %-os megadásával), a beszerzés becsült értéke, teljesítés kívánt ideje, áruszállítás megkezdésének időpontjai; szolgáltatás megkezdésének időpontjai. Amennyiben van keretszerződés a beszerzési igényben foglalt árura vagy szolgáltatásra, ez legkorábban az adott beszerzési igény bejelentésének határidejét követő 30. nap, amennyiben nincs, 90. nap lehet. teljesítés helye.


99


A helyben központosított közbeszerzés szerződései, megállapodásai

A Hivatal a helyben központosított közbeszerzési eljárások eredményeképpen közvetlen szerződést, keretmegállapodást, vagy keretszerződést köthet.

A keretmegállapodás fogalmát a Kbt. 4.§ 12. pontja határozza meg. Eszerint: „keretmegállapodás: meghatározott egy vagy több ajánlatkérő és egy vagy több ajánlattevő között létrejött olyan megállapodás, amelynek célja, hogy rögzítse egy adott időszakban közbeszerzésekre irányuló, egymással meghatározott módon kötendő szerződések lényeges feltételeit, különösen az ellenszolgáltatás mértékét, és ha lehetséges, az előirányzott mennyiséget;”.

A keretszerződés a Rendelet értelmében a megrendelési jogot az intézményre engedményező, de a Kbt. előírásainak megtartásának kötelességét ezzel együtt átruházó szerződés. Az intézmények a keretszerződések terhére kibocsátott megrendelésekkel közvetlenül szerezhetik be a beszerzési igénnyel előre jelzett árut, illetve a szolgáltatást. A keretszerződés megkötésének szabályai: a

helyben

központosított

közbeszerzési

eljárás

eredményeképpen

legfeljebb 4 évre köthető, legalább a következőket kell tartalmaznia: o

a szerződő felek megnevezését,

o

a

keretszerződés

előzményeinek

(lefolytatott

közbeszerzési

eljárás), a közbeszerzés tárgyának, továbbá mennyiségének a Kbt. 50. §-ának (2) bekezdése szerinti meghatározását, o

a keretszerződés tárgyára vonatkozó minőségi követelményeket,

o

a szerződés hatályát,

o

az ellenszolgáltatás mértékét,


100


o

arra

vonatkozó

intézmény

kikötést,

egyoldalú

megrendeléssel) szolgáltatást

a

hogy

a

keretszerződés

jognyilatkozattal

jogosult

a

kívánt

keretszerződés

(a

áru

szerinti

alapján

az

továbbiakban:

mennyiséget

szerződéses

vagy

partnertől

megrendelni, o

a megrendelések kezdeményezésével, ezek visszaigazolásával, valamint a teljesítésekkel kapcsolatos határidőt és a teljesítésekre vonatkozó (szállítási és pénzügyi) részletes feltételeket,

o

a szerződésszegésért való felelősség szabályait,

o

az intézményeknek és a szállítóknak a keretszerződéssel és annak teljesítésével

kapcsolatos

adatszolgáltatási

kötelezettségére

vonatkozó, valamint az ennek végrehajtási módját szabályozó rendelkezéseket, o

annak rögzítését, hogy az intézmény előleget nem adhat.

A szerződés, keretmegállapodás, valamint a keretszerződés aláírására Pécs Megyei Jogú Város Címzetes Főjegyzője, valamint Pécs Megyei Jogú Város Polgármestere együttesen jogosult. A megrendeléseket az intézmények vezetői írhatják alá.

V. Az intézményi beszerzési igények teljesítése

Az intézmények a beszerzési igényeik teljesítéséről, részteljesítéséről, késedelmes teljesítéséről, hibás teljesítéséről írásban tájékoztatják a Hivatalt az eseményt követő 5 munkanapon belül. Több éven át tartó teljesítés esetén az adott évi teljesítésről a szerződéskötés évfordulói előtt 10 nappal kell a tájékoztatást megtenni. A tájékoztatásnak az alábbi adatokat kell tartalmaznia:


101


az igényelt és a leszállított áru / teljesített szolgáltatás megnevezése, a beszerzési igény benyújtásának ideje, a mennyiség, az érték, a teljesítés ideje és a teljesítés minősítése (kiváló/megfelelő/nem megfelelő).

A fenti adatokat kell az intézményeknek írásban közölniük a Hivatallal abban az esetben is, ha az áruk, szolgáltatások beszerzését saját hatáskörben folytatják le.

A Hivatal az intézményi adatszolgáltatás alapján figyelemmel kíséri a beszerzési igények teljesítését.

3.9.5.

Nyilatkozattételek a rendszerben, adatok kezelése, közzététele

A rendszerben részt vevő szervezeteknek, illetve az Önkormányzatnak miden egymás felé tett nyilatkozatát írásban kell teljesítenie. Az Önkormányzat szabályozása értelmében a nyilatkozatokon az átvétel idejét és tényét is jelölni kell. Az emailben illetve faxon történő nyilatkozattételnél a küldő félnek igazolnia kell az üzenet vételét. A személyesen tett nyilatkozatokról jegyzőkönyvet kell felvenni és abból minden jelenlevőnek 1-1 példányt kell juttatni.

A Hivatal a Rendszer működtetése körében az alábbi adatokat kezeli: az intézmények adatai, a szállítók és szolgáltatók adatai, a szerződések, keretmegállapodások, keretszerződések és a közvetlen intézményi megrendelések adatai. Ezekhez kapcsolódóan az intézményeknek az adatszolgáltatást negyedévente, minden negyedév 15. napjáig kell megtenniük.

A Hivatalnak a keretszerződések, szerződések, keretmegállapodások hatályos


102


szövegét az intézmények számára elérhetővé kell tennie. Továbbá gondoskodnia kell ezen szerződések adatainak a www.pecs.hu honlapon történő közzétételéről is.

A Hivatal vezetője minden év április 30-ig beszámol a Közgyűlésnek a helyben központosított közbeszerzési rendszer működéséről.

3.9.6.

Támogató technikai háttér

Jelenleg a helyben központosított közbeszerzések lebonyolítását nem támogatja semmilyen informatikai alkalmazás. A Hivatal, valamint a Rendszerben résztvevő intézmények közti információáramlást hagyományos levelezés, email illetve fax vagy személyes átadások biztosítják. A beszerzési igények begyűjtése, összegzése, a közbeszerzési terv elkészítése, illetve

a közbeszerzések

egyszerű

Office

folyamatának

alkalmazások

figyelemmel

használatával,

Excel

kísérése

a Hivatalban

táblázatok

vezetésével

történnek.

3.9.7. Az

Támogató hivatali szervezet

Önkormányzat

helyben

központosított

közbeszerzéseinek

kezelése,

lebonyolítása kapcsán az összegyűjtött igények kapcsán, a közbeszerzési terv összeállítása a Tisztségviselői Kabinet feladata és felelőssége. A közbeszerzési eljárások előkészítése, lebonyolítása a beszerzés tárgya szerint érintett főosztály feladata. A Hivatal külső szakértőt, bonyolító céget is megbízhat a közbeszerzési eljárások lebonyolításával.

Az eljárások lefolytatásának törvényességét és szakszerűségét az Ellenőrzési Osztály

évente

ellenőrzi.

Az

ellenőrzésekről


készült

jelentést

a

címzetes

103


főjegyzőnek és a közbeszerzés tárgya szerint érintett főosztályvezetőknek megküldi.

A

közbeszerzések

ellenőrzésének

tapasztalatairól

beszámol

a

Gazdasági Bizottságnak és az Önkormányzati Bizottságnak

3.9.8. A

Összegzés

fentiek

alapján

áttekintettük

az

Önkormányzat

helyben

központosított

közbeszerzéseinek folyamatát, szabályozását. A Rendelet 2008. június 3-i hatálybalépése ellenére a helyben központosított közbeszerzés érdemben nem valósult meg az Önkormányzatnál. Vizsgálatunk alapján az alábbi LOGO-VIR funkciók mentén lenne értelmezhető a helyben központosított közbeszerzés informatikai támogatása: Cikktörzs nyilvántartás, beszerzési igények nyilvántartása (benyújtott és összesített -> közbeszerzési terv, teljesítések követése) Beszámoltatás, adatbekérés: beszerzési igények benyújtása, tejesítések követése Riport funkciók: vezetői adatlekérdezések

Megrendelői igényekben történt hangsúlyok módosulása mentén, tekintettel a terület által jelentett jelenlegi „súlytalanságra” (csekély befolyás a gazdálkodásra) a helyben központosított közbeszerzési eljárás további vizsgálatától, informatikai támogatásától eltekintünk.


104


4. Informatikai rendszerterv 4.1. Követelmények elemzése A fejezetben rendszerezésre és áttekintésre kerülnek a kialakítandó informatikai rendszerrel

szemben

megfogalmazott

követelmények.

A

követelmények

alapvetően két csoportba sorolhatóak: 

A projekttel szemben támasztott szakmai funkcionális követelmények, tulajdonképpen

ezek

kiszolgálására

hivatott

az

implementálandó

informatikai rendszer. 

Nem funkcionális, egyéb informatikai követelmények, melyek elsősorban a kialakítandó informatikai alkalmazás technikai aspektusait befolyásolják.

4.1.1.

Szakmai követelmények

4.1.1.1. Stratégiai célok azonosítása Az alábbiakban összefoglaljuk azokat a azonosítható

követelményeket,

felmérés során stratégiai

melyek

teljesülését

az

célként

Megrendelő

a

kifejlesztendő rendszertől várja.

Költségvetés-tervezés támogatása A kialakítandó rendszerrel szemben elvárás, hogy támogassa a stratégiai célokból levezetett

költségvetés-tervezést,

a

tervteljesítés

nyomon

követését.

A

költségvetés tervezés támogatása elsősorban a korábbi, illetve az aktuális költségvetési időszakokban tetten érhető teljesítések (kiadások, költségek) az adott szakmai területen releváns bontásban történő követésével történhet meg.

Közérdekű adatok publikálása, elérhetőségük biztosítása A

szűkebb

és

tágabb

értelemben

vett


közérdekű

adatok

publikálása,

105


elérhetőségének biztosítása részben a LOGO webes felületén keresztül, részben az Önkormányzat részéről a civil szféra rendszeres tájékoztatásban aktív szerepet játszó szereplők információval történő ellátásán keresztül valósulhat meg. Tehát e tekintetben elsősorban nem a lakosság közvetlen tájékoztatása a fő cél, hanem a nyilvánossággal több-kevesebb rendszerességgel érintkező vezetők,

képviselők

részére olyan információs rendszer létrehozása, amellyel a korábbiakhoz képest sokkal hatékonyabban és pontosabban juthatnak a rendszer által lefedett területek alapadataihoz, beszámolóihoz, kimutatásaihoz. Döntési mechanizmusok segítése A kialakítandó rendszer használatával, a rendszer által szolgáltatott információk birtokában az Önkormányzat az alább megfogalmazott célok megvalósulását, vagy a megvalósulásnak a rendszer általi támogatását várja: általános döntési kompetenciák, eljárások korszerűsítése A hivatal belső szervezeti egységei közötti együttműködés javítása Hivatalon belüli koordinációs funkció színvonalának növelése Önkormányzati

intézmények

felügyeletének

javítása,

döntési

jogosultságok átstrukturálása Az önkormányzati intézményekkel való rendszeres információáramlás folyamatának korszerűsítése A

közintézmények

költséghatékonyabb

és/vagy

eredményesebb

működésére irányuló szervezet-átalakítási programok kidolgozása A

források

felhasználásának

eredményességét

mérő

mutatószámok

bevezetése

Költségvetési gazdálkodás eredményességének növelése A kialakítandó rendszer által szolgáltatott információk, valamint a kialakítandó rendszer funkciói lehetővé kell, hogy tegyék az alábbiakat: Pénzügyi és gazdálkodási felelősségvállalás szabályozása Stratégiai tervezés és éves költségvetés összekapcsolása A költségvetés készítés és elfogadás folyamatának támogatása


106


Pénzügyi és költségvetés végrehajtási ellenőrzés javítása

Partnerség erősítése A

kialakítandó

rendszerből

munkafolyamatok

származó

megváltoztatásában

adatoknak történő

az

önkormányzati

felhasználása,

valamint

meghatározott kontrolling adatköröknek a nyilvánosság számára hozzáférhetővé tétele a következő célok elérését kell szolgálnia: A

források

felhasználásáról

bevezetése

a

lakosság

naprakész

és

folyamatos tájékoztatásának javítása Döntések és hatásuk eredményeinek nyilvánossá tétele a hivatali és intézményi munka átláthatóbbá tétele nyilvános információk közzétételének lehetővé tétele a költségvetés alakulásáról

Kontrolling (vezetői információs) rendszer kialakítása Szükségesek

a

Megrendelővel

együttműködve,

tanácsadási,

konzultációs

tevékenység keretében megismert, informatikai megoldással javítható eljárások kapcsán a következő lépések: Megtervezni azokat a mérőszámokat és kontrolling outputokat, melyek az elérni

kívánt

célhoz

illeszkedve

írják

le,

teszik

értelmezhetővé

a

monitorozott folyamatokat. A tanácsadási, konzultációs tevékenység tapasztalatainak, információinak birtokában a kitűzött cél szerinti módon működő számítógépes rendszer megtervezése olyan mélységig, hogy

a rendszer implementálásával

megbízott szakembereknek a majdani rendszer működésével kapcsolatos minden

információ

a

rendelkezésére

álljon,

további

felhasználói

adatszolgáltatásra a lehető legkisebb mértékben legyen szükség.

Csak ezek után kerülhet sor a tanácsadási tevékenység során feltárt információk, illetve

a

Rendszerterv

birtokában

a


tulajdonképpeni

rendszerfejlesztési

107


tevékenység megkezdésére, mely a következő lépésekből áll: A rendszer kifejlesztése: az elkészített Rendszerterv alapján a részletes programspecifikációk kidolgozása és a rendszer programozása. Műszaki és felhasználói dokumentációk elkészítése Megrendelő oldali tesztelés (funkcionális, rendszer-, és integrációs tesztek) elvégzése

A rendszerfejlesztési fázist a rendszer bevezetési fázisa követi, mely keretében az alábbi tevékenységek elvégzésére kerül sor: A

kifejlesztett

rendszer

illesztése

Megrendelő

jelenlegi

informatikai

környezetébe Szervezetfejlesztési eredmények és a kontrolling rendszer bevezetésének támogatása Megrendelő oldali tesztek elvégzése Kontrolling rendszer integrálása a LOGO rendszerbe Próbaüzem

A rendszer bevezetésével párhuzamosan kerül sor a rendszer oktatására, mely felhasználói oldal, illetve üzemeltetői oldal oktatására terjed ki.

4.1.1.2. Általános szakmai követelmények

Az eljárások elemzése során feltárt, és a projekt keretében informatikai megoldással

optimalizálható

eljárások

támogatásának

megvalósításához

kapcsolódóan követelmény szinten a következő igények merültek fel:

Nyilvántartások kezelése A rendszer szempontjából kiemelt fontosságú adattörzsek és kódok kezelése


108


Intézmények nyilvántartása Gazdasági társaságok nyilvántartása Pályázatok nyilvántartása

Adatforrások kezelése Intézményi, társasági és hivatali szereplőktől származó adatok bevitelének és összegyűjtésének támogatása rendszeres, elektronikus beszámolók formájában Külső

elektronikus

forrásokból

(pl.

Forrás

SQL)

kinyerhető

adatok

beemelése a rendszerbe

Publikáció Nyilvántartások és beszámolók megjelenítése, kereshetőségnek biztosítása megfelelő jogosultági szintek mentén Nyilvántartások

és

beszámolók,

illetve

az

azokból

levezetett

mutatószámok és statisztikák riportolása, olyan kimutatások, riportok, szűrések

készítése,

önkormányzati

mely

tulajdonú

az

önkormányzati

gazdasági

intézmények,

társaságok

valamint

gazdálkodását

teszik

értékelhetővé, átláthatóvá Olyan, a felsővezetők számára készülő riportok, kimutatások, analitikák, az

Önkormányzat

egy-egy

területének

egészét

teszik

átláthatóvá,

elősegítve a stratégiai költségvetés-tervezés és a költségvetésre alapozott működés alakulásának folyamatközi követését, szükség esetén az ily módon

és

eszközökkel

biztosított

adatokra

alapozva

a

különböző

költségvetést befolyásoló döntések meghozatalát A civil szféra felé publikálandó információk megjelenítése nyilvános webes felületen,

a

költségvetést

érintő

főbb

mutatóknak

a

rendszeres

nyilvánosságra hozatala, melynek egyik eszköze a LOGO publikus webes portálja,

melyen

rendszeres

időközönként

publikálni

lehet

a

fenti

adatköröket érintő riportok, kimutatások eredményeit.


109


Adminisztráció A felhasználókhoz, szervezetekhez, adatcsoportokhoz és funkciókhoz kapcsolódó jogosultsági rendszer kezelése Naplózás, a rendszerben

végrehajtott

adatmódosítási

tevékenységek

naplózása Külső elektronikus adatforrásokhoz kapcsolódó interfészek vezérlése és monitorozása Beszámolók

kiajánlásához

és

töltöttségéhez

kapcsolódó

státuszok,

figyelmeztetések kezelése, az ehhez kapcsolódó riportok megjelenítése

4.1.2. Az

Nem funkcionális követelmények

alábbiakban

a

rendszer

működésével

kapcsolatos

informatikai

tárgyú

követelményeket rendszerezzük.

4.1.2.1. Rendszer környezetével szemben támasztott követelmények Az alábbiakban felsoroljuk azokat a követelményeket, melyek a rendszer működési

környezetével, a tágabb értelemben

vett

működést

befolyásoló

tényezőkkel kapcsolatosak.

Jelenlegi infrastruktúra használata A

kifejlesztendő

rendszernek

alapvetően

az

Önkormányzat

már

létező

informatikai infrastruktúráját kell használnia. Az kialakítandó rendszer a már meglévő

LOGO

rendszerbe

szoftverinfrastruktúrájára,

integrálva,

felhasználói

annak

felületére,

hardveraz

és

alkalmazott

szoftvermegoldásaira kell, hogy támaszkodjon.

A jelenlegi rendelkezésre állási mutatók megtartása Mivel a kialakítandó rendszernek a LOGO-ba integráltan, annak infrastruktúráját, megoldásait,

felhasználói

felületét

alkalmazva


kell

megvalósulnia.

Ebből

110


következik, hogy a rendelkezésre állási mutatók tekintetében sem rendelkezhet rosszabb paraméterekkel, mint a LOGO rendszer.

Rendszer továbbfejlesztésének biztosítása A Megrendelő a kifejlesztett rendszer továbbfejlesztésének a jogát fenn kívánja tartani. Ez azt jelenti, hogy a fejlesztés lezárultával át kell adni mindazon jogokat, melyek szoftver Megrendelő általi továbbfejlesztéshez szükségesek. A fejlesztés során harmadik fél által fejlesztett szoftverekhez kapcsolódó jogok közül csak azokat a jogokat tudja a fejlesztő a Megrendelőnek átadni, mely jogokat a szóban forgó

szoftver

jogtulajdonosától

ő

is

megkapott,

valamint

ezen

jogok

továbbadását a külső szoftver jogtulajdonosa a szoftver licencében nem tiltja. Mivel a LOGO-VIR rendszer a LOGO-val nemcsak közös üzemeltetési, de fejlesztési környezetben kerül implementálásra, a továbbfejlesztés szempontjából a LOGO rendszer korábban kifejlesztett és átadott moduljaihoz hasonlóan kerülnek átadásra a szoftverelemek.

4.1.2.2. Egyéb általános informatikai követelmények

Ergonómia Az adatok feldolgozását, megértését segítő módon kell a rendszer funkciói által előállított kimeneteket létrehozni. Beszédes, könnyen értelmezhető grafikonokra, táblázatokra, kimutatásokra van szükség. A rendszer kialakítása során a már meglévő környezet által biztosított lehetőségekre kell építeni. A "felhasználói élmény" szempontjából a rendszernek egységesnek, integráltnak kell lenni.

LOGO rendszerben megszokott kezelőfelület Az Önkormányzat LOGO rendszerében használt felületi elemek, megoldások használata, az ott megszokott kezelési mód és megjelenés alkalmazása válik szükségessé a LOGO-VIR rendszerben is, mint például: menük, képernyők,


111


táblázatos karbantartók, űrlapok, súgó, riportoló eszközök, stb.

A LOGO szoftver infrastruktúrájának használata A rendszer fejlesztése során támaszkodni kell a LOGO rendszer által biztosított szoftver-infrastrukturális háttérre: felhasználó-kezelés jogosultsági rendszer hozzáférések szabályozása nyilvántartások kezelése csatolt állományok tárolása

A LOGO hardver infrastruktúrájának használata A rendszerrel szemben támasztott követelmények ismeretében kijelenthető, hogy a rendszer üzemeltetése összességében akkor a leggazdaságosabb, ha a már létező LOGO hardverinfrastruktúrára kerül telepítésre. Ez egyben nevesített Megrendelői követelmény is, hiszen feltétel a rendszer integrálása a már működő LOGO rendszerbe.


112


4.2. Szakmai rendszerfunkciók A

fejezet

célja

átfogó

képet

adni

a

kifejlesztésre

kerülő

rendszer

követelményekhez és a kitűzött célokhoz igazodó működéséről. Bemutatásra kerülnek: a rendszer felhasználói a felhasználó szemszögből történő rendszer használatának jellemző esetei a rendszer által a cél megvalósítása érdekében támasztott bemenő adatigények (adatkörök), valamint a rendszer kimenő adatkörei a rendszer által támogatni kívánt folyamatok elvi kifejtése a rendszer elvi működése a felhasználói felület kialakításánál használt elvek, és ezek gyakorlati alkalmazása A funkciók kialakításánál kiemelt figyelmet szenteltünk a következő ajánlatkérői igényekre: a rendszer funkcionalitása a lehető legjobban illeszkedjen a helyi és megrendelői igényekhez, rendszer a lehetőségekhez mérten testre szabható, paraméterezhető és bővíthető legyen.

4.2.1.

Használati esetek

A használati esetek a rendszer használatának jellemző módjai a felhasználó szemszögéből nézve. Segítségükkel azonosíthatóak a rendszer azon funkciói, melyeket a rendszer az implementálása után nyújt, emellett a laikus olvasók számára is könnyen érthető módon mutatja be a rendszer majdani viselkedését. A használati esetek feltérképezése, feltárása a követelményekhez illeszkedő módon történik.


113


4.2.1.1. Szereplők A szereplők (aktorok) a modell azon elemei, melyek a rendszer egy jellemző felhasználóját testesítik meg.


114


uc Szereplők

Rendszer

LOGO

Gazdasági társasá g

Intézmény

Forrás SQ L

Taninform

Felhasználó

Adminisztrátor Intzéményi felhasználó Gazdasági társaság Hiv atali felhasználó Képv iselő Civ il felhasználó felhasználója

Rendszer Az összes, nem humán szereplő absztrakt, közös őse.

LOGO Az önkormányzat integrált, a hivatali

munkavégzést

segítő, bonyolító e-

önkormányzati informatikai rendszere.


115


Forrás SQL A Forrás SQL az önkormányzat és az önkormányzati intézmények pénzügyikönyvelési adatait tartalmazó rendszer.

Taninform Az önkormányzati kezelésben álló oktatási intézmények oktatási, és az oktatással összefüggő pénzügyi, személyügyi adatait nyilvántartó informatikai rendszer. A Taninform integrációja csak közvetett, a hivatali felhasználók ennek outputjai alapján szolgáltatnak adatot a LOOG-VIR rendszer részére.

Intézmény A feladatai ellátásához, működéséhez részben vagy egészben önkormányzati pénzügyi forrásokra támaszkodó, önkormányzati fenntartásban üzemelő önállóan vagy nem önállóan gazdálkodó intézményesített szervezet.

Gazdasági társaság A feladatai ellátásához, működéséhez részben vagy egészben önkormányzati pénzügyi forrásokra támaszkodó, önkormányzati tulajdonrésszel bíró gazdasági társaság.

Felhasználó A rendszer humán felhasználóinak közös őse.

Adminisztrátor A LOGO-VIR rendszer adminisztrációs feladataival

megbízott felhasználója.

Feladata a rendszer működtetése, üzemeltetése, karbantartása.

Hivatali felhasználó A LOGO-VIR rendszert a hivatali munkájához használó felhasználó. Feladata lehet


116


pl.: rendszer által biztosított kimenetek alapján döntés-előkészítő munka végzése a rendszer adataira támaszkodva költségvetési tervezési munka végzése a

teljesítményértékelési

tevékenység

a

rendszer

által

biztosított

alapadatok alapján a terv/tény adatok ismeretében beavatkozás

Intézményi felhasználó Az intézmény részéről a rendszer használatára delegált felhasználó.

Gazdasági társaság felhasználója A gazdasági társaság részéről a rendszer használatára delegált felhasználó.

Képviselő Az önkormányzat közgyűlésének tagja, választott képviselő vagy polgármester. Feladata lehet pl.: a rendszer összegző kimutatásainak felhasználása a politikai döntésekben, döntések előkészítésében rendszer kimeneteinek megismerésével nyomon követni a korábban hozott döntések pénzügyi, költségvetési alakulását bizottsági

munkában

támaszkodni

a

rendszer

által

biztosított

információkra.

Civil felhasználó A felhasználó reprezentálja a pl. város egy polgárát, azaz minden olyan, a rendszer működése szempontjából a nyilvánosságot jelentő felhasználót, mely a rendszer kimeneteit a LOGO webes felületére publikálva ismerheti meg.


117


4.2.1.2. Használati esetek A rendszerre jellemző felhasználási módok, és az egyes használati módokhoz köthető szereplők kapcsolatának kifejtésére kerül sor ebben a fejezetben.


118


uc Használati esetek

Adatszolgáltatás Forrás SQ L Forrás SQ L

Adatszolgáltatás LOG O

Intzéményi felhasználó

LOGO

Adatszolgáltatás – intézmény, gazdasági társaság

Gazdasági társaság felhasználója

Taninform Hiv atali felhasználó Riportok futtatása

Intézmény

Képv iselő Riportok, űrlapok adminisztrációj a

Rendszeradminisztráci ó Gazdasági társasá g Adminisztrátor

Webes adatpublikáció

Webes felületre publikált adatok megtek intése Civ il felhasználó

Adatszolgáltatás - Forrás SQL


119


sd Adatszolgáltatás - Forrás SQL Forrás SQL

Start Forrás SQL adatok lev álogatása

LOGO-VIR rendszer Adatok betöltése

Adatfeldolgozás

Az

forrásrendszer-oldali

adatszolgáltatás

folyamattal

az

Adminisztrátor

felhasználó találkozik. A folyamat a következő lépésekből áll: Forrásrendszer adatbázisából egy a LOGO-VIR rendszer részeként szállított oldalán szinkronizáló modul a forrásrendszer (Forrás SQL) adatbázisából rendszertervezési elvégzi.

Ezen

fázis

során

leválogatások

meghatározott logikája,


adatkörök

algoritmusa

leválogatását

elkészítésük

után

120


jellemzően nem, vagy csak ritkán változnak annak a függvényében, hogy a LOGO-VIR rendszer bővítésekor (új lekérdezések definiálása) szükséges-e a forrásrendszerekből új adatköröket biztosítani. az áttöltések az adatáttöltési időközönként

manuálisan,

vagy

preferáltan

automatikusan,

időzítve

futtathatóak. A forrásrendszerekből származó adatok LOGO-VIR rendszer átmeneti tárterületére (Stage), dedikáltan e célt szolgáló táblákba kerülnek. Az átmeneti tárterületre előzőleg betöltött adatok szerkezetének átalakítása megtörténik

a

LOGO-VIR

rendszer

adattárolási

szempontjainak

megfelelően, majd a kimutatások, analitikák frissítése az új adatokkal.


121


Adatszolgáltatás – LOGO A LOGO rendszerrel történő integráció jellegénél fogva olyan, hogy időszakos automatikus vagy manuális adatáttöltési szintén adminisztrátori folyamatot nem generál attól eltekintve, hogy a LOGO-VIR kapcsán megjelenő új jogosultsági beállításokat kezelni kell.

Adatszolgáltatás – intézmény, gazdasági társaság

sd Adatszolgáltatás – intézm...

Kézi adarögzítés LOGO felületén

Bev itt adatok formális ellenőrzése

Adatfeldolgozás

Az intézmények és gazdasági társaságok adatszolgáltatása folyamattal az intézmény, illetve gazdasági társaság felhasználója kerül kapcsolatba. A folyamat végrehajtásával kerül sor a érintett szervezet gazdálkodásával kapcsolatos adatszolgáltatására az adott szervezetre szabott adatkörben, mely a következő lépésekből áll: A szervezet a LOGO-VIR rendszerben testre szabottan kialakított és paraméterezett elektronikus űrlapok kitöltésével. A felhasználó a bevitt adatokat tartalmilag és formálisan ellenőrzi, ebben az


122


űrlpokba épített alkalmazás logika is segíti. A kézi adatbevitel lezárultával az adatok a LOGO-VIR adatbázisában kerülnek eltárolásra.

Rendszeradminisztráció A rendszer működtetésével, üzemben tartásával kapcsolatos tevékenységek, melyek zömében az adminisztrátorok feladata: felhasználók adminisztrációja (felvétel, törlés, módosítás, hozzáférések biztosítása, megvonása, módosítása) ütemezett feladatok monitorozása rendszerfelügyelet adatkarbantartás biztonsági mentések készítése

Riportok futtatása Előre definiált riportok, kimutatások, analitikák futtatása.

Riportok, űrlapok adminisztrációja A rendszer által biztosított kimenetek adminisztrációja. A rendelkezésre álló adatokból új lekérdezések, riportok definiálása (felhasználói igények alapján), vagy a meglévők módosítása.


123


Webes adatpublikáció A rendszer kimenetei közül az Önkormányzat által publikálásra szánt adatok felelős döntéshozó jóváhagyását követő - nyilvánosságra hozatala a LOGOo rendszer nyilvános webes portál felületén.

sd Webes adatpublikáció Start

Publikálandó tartalom meghatározása

Publikálandó tartalom előállítása

Publikálandó tartalom j óv áhagyatása

Nyilv ános közzététel a LOGO w ebes portálon

Vége


124


A publikálandó tartalom meghatározása a hivatali felhasználó feladata. Ezek többnyire a LOGO-VIR rendszer eszközeivel előállított riportok, kimutatások, nyilvántartások, melyek köre részletesen a rendszer specifikációs és fejlesztési fázisában kerülnek meghatározásra. A

publikálandó

tartalom

tulajdonképpeni

előállításában

az

adminisztrátor

felhasználó is bevonható, ez a webes portálon történő publikáláshoz szükséges formátum előállítását jelenti. A publikálandó tartalom csak akkor kerülhet ki a LOGO webes portálra, ha előzőleg azt egy felelős hivatali felhasználó igazolható módon jóváhagyta.

Webes felületre publikált adatok megtekintése A publikált közérdekű adatok megtekintése, a hivatali munka, az önkormányzat tevékenységének figyelemmel kísérése a lakosság, a nyilvánosság, azaz a civil felhasználók által.

4.2.2.

Törzsadat funkciók

A LOGO-VIR funkcionalitásához szükséges leíró, katalógus adatok karbantartó, áttekintő felülete. A felmérés során több adatkör vonatkozásában fény derült arra, hogy a rendszerben már létező nyilvántartások formájában részben rendelkezésre állnak adatok. Elkerülendő a párhuzamos adatkarbantartást, meglévő nyilvántartások lecserélésével, illetve migrációjával kívánja a LOGO-VIR rendszer a problémát, mert vannak olyan adatkörök, ahol a LOGO-VIR-ben is ki kell alakítani struktúrákat, mivel a releváns adattartalom eltér, a karbantartási és tárolási filozófia különböző, akárcsak a felhasználás jellege. Ugyanakkor a felhasználókra, felhasználói szervezetekre kialakított, illetve a technikai működést elősegítő adatszótárak és törzsek használata változatlan módon integrálható a LOGO-VIR rendszerben.

4.3. Adatmodell A

fejezet

célja,

hogy

átfogó

és

részletes

képet

adjon

azon

logikailag

csoportosítható adatkörökről, adatkör-igényekről, melyek a rendszer kimeneteit


125


és bemeneteit fogják képezni. A jelen rendszertervben szereplő adatbázis struktúrák nem feltétlenül véglegesek, illetve

nem

teljesen

részletezettek,

ezeket

az

egyes

funkciók

részletes

specifikációs fázisában tudjuk pontosan meghatározni. Nem cél továbbá a jelenlegi LOGO rendszertervi részek bemutatása még a LOGO-VIR rendszerrel közös területek esetén sem, hiszen azok működő rendszerként a jelenlegi LOGOban működnek.

4.3.1.

Adattípus domének

Az adatmodell fizikai szintjén az egyes elemi adatmezők típusait az egyszerűbb kezelés és kommunikáció céljából ún. adattípus doménekbe soroljuk, így téve egységessé, áttekinthetőbbé az adatbázis struktúráját. További előnye a típusok ilyen kezelésének, hogy rugalmasabbá teszi a struktúrát, a későbbi módosítások kötegelve, igen hatékonyan végezhetők el doménenként. Az adattípus doméneket az adatmezők használati módja szerint néhány alapvető kategóriába soroljuk: Azonosító Karakteres leíró Numerikus leíró Numerikus mennyiség Dátum jellegű

Az egyes domainek definíciója kategóriánként:

Azonosító Kód

Típus

Hossz

Leírás

VIR_ID

NUMBER

18

Technikai azonosító, általában szekvenciából

töltődik,

kötelezően kitöltendő


126


VIR_KOD1

VARCHAR2

10

Kód max 10 karakteren

VIR_KOD2

VARCHAR2

20


VIR_KOD3

VARCHAR2

30


Karakteres leíró Kód

Típus

Hossz

Leírás

VIR_NEV

VARCHAR2

50

Rövid név

VIR_TELJES_NEV

VARCHAR2

200

Teljes név

VIR_ROV_LEIRAS

VARCHAR2

200

Rövid leírás

VIR_LEIRAS

VARCHAR2

2000

Leírás

VIR_FLAG

VARCHAR2

1

Egy karakteres flag

VIR_IN

VARCHAR2

1

’I’ vagy ’N’ érték

VIR_PENZNEM

VARCHAR2

3

Pénznem (HUF, EUR, stb.)

Numerikus leíró Kód

Típus

Hossz

Leírás

VIR_HIER

NUMBER

2

Hierachia szint

VIR_SORSZAM

NUMBER

18

Sorszám

Numerikus mennyiség Kód

Típus

Hossz

Leírás

VIR_LETSZAM

NUMBER

10,2

Létszám adatok

VIR_DARAB

NUMBER

18

Darabszám


127


VIR_MENNYISEG

NUMBER

18,2

Mennyiség

(műszaki

vagy

egyéb) VIR_OSSZEG

NUMBER

18,2

Pénzösszeg (HUF vagy egyéb pénznemben)

VIR_SZAZALEK

NUMBER

18,2

Százalék

Dátum jellegű Kód

Típus

Hossz

Leírás

VIR_DATUM

DATE

-

Dátum

VIR_EV

VARCHAR2

4

Év (YYYY formátumban)

VIR_NEGYEDEV

VARCHAR2

5

Negyedév

(YYYYQ

formátumban) VIR_HONAP

VARCHAR2

6

Hónap

(YYYYMM

formátumban)

A domének definíciója a specifikációs fázisban még pontosításra kerülhet, illetve új domének is kialakíthatók szükség szerint.


128


4.3.2.

Adatdefiníciók

VIR_INTEZMENY Címke

Kód

Leírás

Intézmény

VIR_INTEZMENY

PMJV tulajdonolt gazdasági társaságok egységes szerkezetű nyilvántartása

Címke

Kód

Domain típus

Leírás


INT_ID

VIR_ID



NEV

VIR_NEV



TELJES_NEV

VIR_TELJES_NEV


Ágazati besorolás

AGAZAT_ID

VIR_ID

Ágazat egyedi azonosítója

Önkormányzati intézmény

ONK_STATUS

VIR_IN

’I’ vagy ’N’ érték - induláskor default 'I'

Szakágazati alapbesorolás

SZAKFELADAT_NEV

VIR_NEV

Alapító okirat szerint, szakfeladat név

Gazdálkodás típusa

GAZD_TIPUS

VIR_ID

Feladatellátáshoz kapcsolódó besorolás

Intézmény típusa

INT_TIPUS

VIR_ID

Főintézmény, tagintézmény

Besorolás

INT_BESOROLAS

VIR_ROV_LEIRAS

Közszolgáltató, közintézmény

Közfeladat, alaptevékenység

TEVEKENYSEG_ID

VIR_ID

Jogszabályban meghatározott közfeladat

Intézmény irányító szerv

IRANY_SZERV

VIR_ROV_LEIRAS

Alapító okirat szerint: PMJV

Oszlopok/mezők

Alapító okirat szerint: PMJV és egyéb Fenntartó szervezetek

FENT_SZERV


VIR_LEIRAS

önkormányzat

129


Alapító okirat szerint: PMJV és egyéb Működési kör

MUKOD_KOR

VIR_LEIRAS

önkormányzat

Székhely címe

SZEKH_CIM

VIR_ROV_LEIRAS

Székhely címe

Levelezési címe

LEV_CIM

VIR_ROV_LEIRAS

Levelezési címe Főintézmény esetén nem tagintézmények

Telephelyek címe

TELEP_CIM

VIR_LEIRAS

felsorolása


KZP_TEL

VIR_ROV_LEIRAS


Email

KZP_EMAIL

VIR_ROV_LEIRAS

Email

Honlap

HONLAP

VIR_ROV_LEIRAS

Honlap

Alapító okirat, jogszabály

ALAPITO

VIR_ROV_LEIRAS

Hivatkozás a dokumentum azonosítójára

Működési engedély

MUKENG

VIR_LEIRAS

Hivatkozás a dokumentum azonosítójára Vezető neve, beosztása, esetleg

Vezető neve, beosztása

VEZETO

VIR_ROV_LEIRAS

javadalmazási adat

Telefon, fax

VEZETO_TEL

VIR_ROV_LEIRAS

Telefon, fax

Email

VEZETO_EMAIL

VIR_ROV_LEIRAS

Email


KAPCSOLAT

VIR_ROV_LEIRAS


Telefon, fax

KAPCSOLAT_TEL

VIR_ROV_LEIRAS

Telefon, fax

Email

KAPCSOLAT_EMAIL

VIR_ROV_LEIRAS

Email

Leíró mező

LEIRAS

VIR_LEIRAS


Főintézmény VIR egyedi azonosító

FO_INT_ID

VIR_ID

Főintézmény egyedi LOGO-VIR azonosítója Csak főintézmény esetén töltendő - Forrás

Elszámolási egység csoport kód

EECSOP

VIR_KOD3

SQL

Elszámolási egység elsődleges

F_EEK

VIR_KOD3

Forrás SQL egyedi azonosító


130


IGSZ esetén szükséges 2 elszámolási Elszámolási egység másodlagos

F_EEK2

VIR_KOD3

egység ANK esetén szükséges,

Ügyletkód

F_UGYLET

VIR_KOD3

intézményegységekhez Főintézmény alapító okiratban szereplő

Adószám

ADOSZAM

VIR_KOD3

adószáma

PIR azonosító

PIR_ID

VIR_KOD3

Törzsszám Oktatási ágazat esetén releváns intézmény

OM azonosító

OM_ID

VIR_KOD3

kód

Szakágazat

PM_SZAKFELADAT_ID

VIR_KOD3

Szakfeladat kód az alapító okiratból


FKOD1

VIR_KOD3



FKOD2

VIR_KOD3



FKOD3

VIR_KOD3


Ellátotti létszám

LETSZAM

VIR_LEIRAS

Tájékoztató jelleggel Alapító okiratból és/vagy működési

Férőhelyi kapacitás

LETSZAM

VIR_LEIRAS

engedélyből Költségvetési rendeletben meghatározott

Dolgozói létszám - álláshely

LETSZAM

VIR_LETSZAM

szám Oktatási (fő)intézményeknél a költségvetés

Pedagógus

LETSZAM

VIR_LETSZAM

alapján Oktatási (fő)intézményeknél a költségvetés

Nem pedagógus

LETSZAM


VIR_LETSZAM

alapján

131


VIR_AGAZAT Címke

Kód

Leírás VIR szintű és szempontú ágazati besorolás, mely alapvetően osztályozza az

Ágazat

VIR_AGAZAT

intézményeket

Címke

Kód

Domain típus

Leírás

Ágazat azonosító

AGAZAT_ID

VIR_ID

Ágazat egyedi azonosítója

Ágazat rövid elnevezése

NEV

VIR_NEV

Ágazat rövid neve

Ágazat hosszú elnevezése

TELJES_NEV

VIR_TELJES_NEV

Ágazat hosszú neve

Kód

Leírás

Oszlopok/mezők

VIR_GAZD_TIPUS Címke

Feladatellátáshoz kapcsolódó funkció szerinti besorolás: önállóan gazdálkodó Gazdálkodás típusa

VIR_GAZD_TIPUS

és működő, önállóan működő

Címke

Kód

Domain típus

Leírás

Gazdálkodás típus azonosító

GAZD_TIPUS

VIR_ID

Gazdálkodás típus egyedi azonosítója

Gazdálkodás típus elnevezése

NEV

VIR_NEV

Gazdálkodás típus rövid neve

Gazdálkodás típus hosszú elnevezése

TELJES_NEV

VIR_TELJES_NEV

Gazdálkodás típus hosszú neve

Oszlopok/mezők


132


VIR_INT_TIPUS Címke

Kód

Leírás Önkormányzati intézmény típusa (főintézmény, tagintézmény,

Intézmény típusa

VIR_INT_TIPUS

intézménygazda)

Címke

Kód

Domain típus

Leírás

Intézmény típus azonosító

INT_TIPUS

VIR_ID

Intézmény típus egyedi azonosítója

Intézmény típus elnevezése

NEV

VIR_NEV

Intézmény típus rövid neve

Intézmény típus hosszú elnevezése

TELJES_NEV

VIR_TELJES_NEV

Intézmény típus hosszú neve

Címke

Kód

Leírás

Tevékenység

VIR_TEVEKENYSEG

VIR szintű és szempontú tevékenységtörzs

Címke

Kód

Domain típus

Leírás

Tevékenység azonosító

TEVEKENYSEG_ID

VIR_ID

Tevékenység egyedi azonosítója

Tevékenység rövid elnevezése

NEV

VIR_NEV

Tevékenység rövid neve

Tevékenység hosszú elnevezése

TELJES_NEV

VIR_TELJES_NEV

Tevékenység hosszú neve

Oszlopok/mezők

VIR_TEVEKENYSEG

Oszlopok/mezők


133


Közfeladat státusz

KOZFEL_STATUS

VIR_IN

Kód

Leírás

’I’ vagy ’N’ érték

VIR_TEVEKENYSEG_TIPUS Címke

Tevékenységtípusok (alap, kiegészítő, kisegítő, vállalkozói, technikai Tevékenység típus

VIR_TEVEKENYSEG_TIPUS

szakfeladatrendi osztályozás)

Címke

Kód

Domain típus

Leírás

Tevékenység típus azonosító

TEV_TIPUS_ID

VIR_ID

Tevékenység típus egyedi azonosítója

Tevékenység típus rövid elnevezése

NEV

VIR_NEV

Tevékenység típus rövid neve

Tevékenység típus hosszú elnevezése

TELJES_NEV

VIR_TELJES_NEV

Tevékenység típus hosszú neve

Oszlopok/mezők


134


VIR_INT_SZAKFEL_TEVTIPUS Címke

Kód

Leírás

Intézmény szakfeladat és tev.típus

VIR_INT_SZAKFEL_TEVTIPUS Intézmények szakfeladati besorolása tevékenységtípus hivatkozással

Oszlopok/mezők Címke

Kód

Domain típus

Leírás


INT_ID

VIR_ID


Tevékenység azonosító

VIR_SZAKFELADAT_ID

VIR_ID


Tevékenység típus

TEV_TIPUS_ID

VIR_ID

Tevékenység típus egyedi azonosítója

Érvényesség kezdete

ERV_KEZD

VIR_DATUM

Dátum

Érvényesség vége

ERV_VEGE

VIR_DATUM

Dátum

Címke

Kód

Leírás

Szakfeladat

VIR_SZAKFELADAT

VIR szempontjából releváns szakfeladati struktúra törzs

VIR_SZAKFELADAT

Oszlopok/mezők


135


Címke

Kód

Domain típus

Leírás

Szakfeladat egyedi VIR azonosító

VIR_SZAKFELADAT_ID

VIR_ID

Szakfeladat VIR belső egyedi azonosítója

Szakfeladat PM kód

PM_SZAKFELADAT_ID

VIR_KOD3

Szakfeladat PM egyedi azonosítója

Szakfeladat rövid elnevezése

NEV

VIR_NEV

Szakfeladat rövid neve

Szakfeladat hosszú elnevezése

TELJES_NEV

VIR_TELJES_NEV

Szakfeladat hosszú neve Hierachia szint (jelenleg 5, elemi

Hierarchia szint

HIERARCHIA_SZINT

VIR_HIER

szakfeladat az 5.) Felettes szakfeladat VIR belső egyedi

Felettes szakfeladati azonosító

FO_VIR_SZAKFELADAT_ID

VIR_ID

azonosítója Szakfeladat szinten kötelező Forrás SQL

Analitikus kód

F_ANK

VIR_KOD3

hivatkozás

Tevékenység kód

TEVEKENYSEG_ID

VIR_ID


Érvényesség kezdete

ERV_KEZD

VIR_DATUM

Dátum

Érvényesség vége

ERV_VEGE

VIR_DATUM

Dátum


136


VIR_TARSASAG Címke

Kód

Leírás PMJV tulajdonolt gazdasági társaságok egységes szerkezetű

Gazdasági társaság

VIR_TARSASAG

nyilvántartása

Címke

Kód

Domain típus

Leírás

GT azonosító

GT_ID

VIR_ID

GT azonosítója

GT rövid neve

NEV

VIR_NEV

GT rövid neve

GT hosszú neve

TELJES_NEV

VIR_TELJES_NEV GT hosszú neve

Társasági forma

GT_FORMA

VIR_NEV

Székhely címe

SZEKH_CIM

VIR_ROV_LEIRAS Székhely címe

Levelezési címe

LEV_CIM

VIR_ROV_LEIRAS Levelezési címe

Telephelyek címe

TELEP_CIM

VIR_LEIRAS


KZP_TEL

VIR_ROV_LEIRAS Központi telefon, fax

Email

KZP_EMAIL

VIR_ROV_LEIRAS Email

Honlap

HONLAP

VIR_ROV_LEIRAS Honlap

Cégjegyzékszám

CEGJSZAM

VIR_KOD3

Cégjegyzékszám

Adószám

ADOSZAM

VIR_KOD3

Adószám


STATSZAM

VIR_KOD3


Oszlopok/mezők

Számlavezető bank(ok) és pénzforgalmi

Telephelyek címe

Számlavezető bank(ok) és pénzforgalmi

jelzőszám(ok)

BANK


CEGJ_DATUM


Társasági forma

VIR_LEIRAS

jelzőszám(ok) Cégjegyzés dátuma

137


Főtevékenység

FOTEVEKENYSEG

VIR_ROV_LEIRAS Főtevékenységek (TEÁOR 08)

További tevékenységek felsorolása

TEVEKENYSEG

VIR_LEIRAS

Tevékenységek felsorolása (TEÁOR 08)

Leíró mező

LEIRAS

VIR_LEIRAS



KOZSZOLG

VIR_LEIRAS



VEZETO

VIR_ROV_LEIRAS Vezető neve és beosztása

Telefon, fax

VEZETO_TEL

VIR_ROV_LEIRAS Telefon, fax

Email

VEZETO_EMAIL



VEZETO_KINEV

VIR_ROV_LEIRAS Kinevezésének dátuma

Javadalmazás

VEZETO_JAVAD

VIR_LEIRAS

Javadalmazás


VEZETOSEG

VIR_LEIRAS


Igazgatóság (név, megbízás kezdete, díjazás)

IGAZGATOSAG

VIR_LEIRAS

Igazgatóság (név, megbízás kezdete, díjazás)

Felügyelő bizottság (név, megbízás kezdete, díjazás)

FEB

VIR_LEIRAS

Felügyelő bizottság (név, megbízás kezdete, díjazás)


KAPCSOLAT

VIR_ROV_LEIRAS Kapcsolattartó neve és beosztása

Telefon, fax

KAPCSOLAT_TEL

VIR_ROV_LEIRAS Telefon, fax

Email

KAPCSOLAT_EMAIL


Könyvizsgáló (név, jogviszony kezdete és vége,

Könyvizsgáló (név, jogviszony kezdete és vége,

díjazás)

KONYVVIZSG

VIR_LEIRAS

díjazás)


TULAJD_STRUK

VIR_LEIRAS



PMJV_TULAJD

VIR_LEIRAS


Tulajdonlás formája

TULAJD_FORMA

VIR_NEV

Közvetlen vagy Holdingon keresztüli

Tulajdonosi jogok gyakorlásának formája

TULAJD_JOGOK

VIR_LEIRAS

Utalás pl.szindikátusi szerződésre

Tulajdonos társaság VIR egyedi azonosító

TULAJD_GT_ID

VIR_ID

GT azonosítója - közvetett tulajdonlás esetén

Fentartott azonosító1

FKOD1

VIR_KOD3



138



FKOD2

VIR_KOD3



FKOD3

VIR_KOD3


Dolgozói létszám

LETSZAM

VIR_LETSZAM

Dolgozói létszám

Mérlegfőösszeg

MERLEGFO

VIR_OSSZEG

Mérlegfőösszeg

Pénznem

MERLEGFO_PENZNEM

VIR_PENZNEM

Jelenleg HUF


TOKE

VIR_OSSZEG


Pénznem

TOKE_PENZNEM

VIR_PENZNEM

Jelenleg HUF

Normatív állami támogatás

NORMATIV_TAM

VIR_LEIRAS

Szakfeladat szintű felsorolás

Önkormányzati támogatás mértéke

ONKORM_TAM

VIR_LEIRAS

Aktuális év, elfogadott eredeti költségvetése alapján


139


4.4. Informatikai rendszerfunkciók 4.4.1.

Felhasználói felület

A LOGO-VIR rendszer kifejlesztése során támaszkodik a meglévő LOGO rendszer biztosította hardver-és szoftver infrastruktúrára. Az egyes funkciókat a LOGO rendszerbe

integrálva,

annak

eszközeivel,

felhasználói

felületén

kerül

megvalósításra. A LOGO rendszer a vékonyklienses technológiából fakadóan a rendszer felhasználóinak számítógépein egy webes böngészőben, weblapokként kerül megjelenítésre, minden felhasználói interakció a kliens számítógépén futó böngészőben történik.


140


Háromrétegű alkalmazásmodell A LOGO környezetében kifejlesztendő rendszer egy úgynevezett háromrétegű alkalmazásmodellt realizál megjelenítés, üzleti logika, adattárolás tagolódásban.


141


Megjelenítés A felhasználói interakcióért felelős réteg. Az alkalmazás képernyőkön, nézeteken keresztül

kommunikál

a

felhasználóval.

A

LOGO-VIR-ben

megvalósított

felhasználói réteg az úgynevezett MVC-pattern szerint implementált felhasználói keretrendszer.

Üzleti logika Az alkalmazás azon rétege, melyben az alkalmazás működése, funkciói, az üzleti logika kerül implementálásra. Az előző fejezetekben vázolt működést leíró funkciók

(a rendszer tulajdonképpeni

magas szintű

működési

logikájának

megfelelő funkciók) az alkalmazásmodell LOGO-VIR realizációjának e rétegében kerülnek kifejlesztésre.

Adattárolás A

rendszer

adatainak

fizikai

tárolásáért

felelős

alkalmazásréteg.

Ez

a

gyakorlatban többnyire egy vagy több adatbázist jelent. Az előzőekben kifejtett rendszerfunkciók

közül

az

adatáttöltés,

adattisztítás,

adat

transzformáció,

valamint a riportok, leválogatások, szűrések, kimutatások, analitikák adatbázisszintű komponensei a modell LOGO-VIR realizációjának e rétegében kerülnek kifejlesztésre, definiálásra.

Keretrendszer A felhasználói rétegnek a LOGO rendszerben is használt, a Megrendelő által által kifejlesztetett implementációja az előzőekben említett MVC-mintát követi. A Web Application Framework (WAF) egységes, testre szabható és felhasználóbarát megjelenítést,

alkalmazás-interakciót

biztosít.

A

felhasználót

konzekvensen

megtervezett, intuitív, könnyen használható felületek biztosításával segíti az alkalmazás funkcióinak (az üzleti logikának) a használatában.


142


Model-View-Controller A felhasználói felület elvi működését leíró modell elnevezése, rövidítése az összetevők kezdőbetűinek alapján: MVC. Ennek implementációja az előzőekben említett WAF, melyre a LoGo felhasználói felülete is épül.

Model A

felhasználói

felület

működési

modelljét

leíró

komponens.

Itt

kerülnek

definiálásra azok az összetevők, melyek az alkalmazás üzleti logika rétegével tartják a kapcsolatot, "használják az alkalmazást".

View A felhasználói felület egyes állapotait (nézeteit, jellemzően a funkcionalitásnak megfelelő képernyőket) leíró komponens. Az alkalmazás tulajdonképpeni látható felhasználói felülete, ezzel a komponenssel találkozik a felhasználó pl. a LoGo


143


használata során is.

Controller A 'Modell' komponensben definiált szabályok mentén a felhasználói felület egyes állapotátmeneteit (nézetváltásait) vezérlő komponens.

Képernyőtervek Az előbb említett riport modul, melyre a feladat megoldása során támaszkodni kívánunk,

a

következőkben

bemutatásra

kerülő

képernyőkön

keresztül

használható. A cél a működési elv megértésnek segítése, a LOGO-VIR rendszer kialakítása során az itt ismertetett felületek tartalma a rendszertervezési fázisban kerül meghatározásra.

Előre paraméterezett riportok Az Adminisztrátorok által előzőleg felparaméterezett riportok indítóképernyője a jelenlegi

LOGO

e-önkormányzati

rendszer

Ingatlanvagyon-kataszer

modul

Riportok képernyőjén, mint szemléltető példán keresztül.


144


Riport szűrőfeltételeinek beállítása Az

alábbi

ábrán

egyes

ad-hoc

lekérdezések

összeállításához

használható

lekérdező felület látható (szintén az Ingatlangyon-kataszteri modulból). A LOGOVIR rendszer keretein belül ugyanilyen technikai

megoldással kívánjuk a

felhasználók számára biztosítani az ad-hoc lekérdezések előállítását.


145


Csoportosítási feltételek A szűrőfeltételek megadása után lehetőség nyílik a lekérdezés eredményének (találati listának) meghatározott feltételek szerinti, több szintű csoportosítására (pl.

rendezési

szempont,

részösszegek

összegzése,

stb.).

A

LOGO-VIR

rendszerben kialakítandó megoldást itt is az Ingatlanvagyon-kataszer modul riport-képernyőjén keresztül mutatjuk be.


146


Lekérdezés találati képernyő Az előzőleg összeállított lekérdezés találati képernyője képezi a riport kimenetét. Itt lehetőség van a találatok több szintű csoportosítására az áttekinthetőség javítása érdekében. Szintén lehetőség van az eredmények táblázatos formában történő exportjára, mely a rendszerből kinyert adatok további feldolgozásának lehetőségét biztosítja. A LOGO-VIR rendszerben kialakítandó megoldást itt is az Ingatlanvagyonkataszter modul riport képernyőjén keresztül mutatjuk be, azzal a megjegyzéssel, hogy a jelenlegi export formátumok körének bővítését, valamint a riportok alfanumerikus

adataiból

képzett

diagramkészítés

lehetőségét

a

LOGO-VIR

rendszer fejlesztése során kívánjuk elvégezni. Ennek során kerül sor a jelenleg a rendszer által nem teljességében támogatott export formátumok (pl. xls), valamint a különféle, elsősorban a vezetői információs rendszer által biztosított riportok esetében használt diagramtípusok (pl. oszlop, torta, trend, stb.) implementálására.


147


4.4.2. A

Rendszerbiztonság

fejezet

célja

megoldásokat.

ismertetni Ezek

az

a

rendszerbiztonsággal

implementáció

során

kapcsolatos

tervezés

elveket,

folyamán

még

természetesen minimális mértékben változhatnak, pontosításra kerülhetnek. Abból az elvből indulunk ki, miszerint a LOGO jelenlegi teljes biztonsági rendszere szigorúbb követelmények mentén épült, és a kialakítandó LOGO-VIR rendszer teljes egészében átveszi a LOGO biztonsági rendszerét. Bemutatjuk azokat a célokat, amelyek mentén a biztonsági rendszer kialakításra fog kerülni, majd a konkrét alapot adó keretrendszert, illetve a rendszerbiztonság elvi alapjait adó hozzáférési modellt, melyben konkrétabban megfogalmazzuk az egyes részekhez történő hozzáférés elvi szabályozását. Mindezek után kitérünk a rendszer ún. fizikai, hálózati szintű védelmére is.

4.4.2.1. Elvek, célok Fontosnak tartjuk tisztázni azokat a célokat, amelyek rávilágítanak arra, hogy a rendszerbiztonság nem öncélú dolog, hanem számos fontos cél elérése érdekében került kialakításra, amelyek egyenként és összességében is nagyon fontos tényezők. A rendszerbiztonság feladata biztosítani, hogy a rendszerben tárolt adatokhoz történő hozzáférés korlátozva legyen; az adatok módosíthatósága csak megfelelő jogosultságoknak megfelelően történhessen; mindenféle adatmódosítás naplózásra kerüljön; a rendszerben tárolt adatok biztonságos tárolása, és rendszerhiba esetén visszaállítása megfelelően szabályozott legyen; A rendszerben többféle típusú adat kerül eltárolásra: belső adatok, amelyekhez korlátozott módosítási és megtekintési hozzáférés adott. publikus adatok, amelyekhez a nyílt internetes felületen bárki, felhasználói azonosítás nélkül hozzáférhet.


148


4.4.2.2. LOGO jogosultsági rendszere A LOGO-VIR rendszer védett, és publikus felületei is a jelenleg üzemelő LOGO rendszer

megfelelő

felületein

kerülnek

kialakításra,

a

LOGO

jogosultsági

rendszerét felhasználva teljes egészében. Ezzel a következő előnyökhöz jutunk: meglévő, működőképes jogosultsági rendszer használata meglévő üzemeltetői tudás felhasználása, ezáltal oktatási költségek csökkentése, illetve az üzemeltetői személyzet munkájának egyszerűsítése nem szükséges a jogosultsági rendszert kifejleszteni, olcsóbb lesz a fejlesztés a karbantartási és követési költségek nagymértékben csökkennek, illetve a LOGO rendszer költségeivel összevonásra kerülhetnek.

Az összes jogosultággal kapcsolatosan felmerült igény lefedhető a LOGO jogosultsági rendszerével, mivel az összetettebb, mint a LOGO-VIR rendszer számára szükséges, tehát hátrányokat a javasolt megoldás ellen nem lehet felsorakoztatni. Tehát összességében elmondható, hogy a következő komponenseket kívánjuk újra felhasználni: bejelentkező felület LOGO-SSO (egypontos bejelentkezés, és autentikációs címtár) felhasználó és jogosultság karbantartó felület jogosultságok lekérése

4.4.2.3. Hozzáférési modell A fejezetben azokat az elveket rögzítjük, amelyek mentén az egyes hozzáférési módok, jogosultságok, szerepkörök pontosan definiálásra kerülnek majd a rendszertervezés fázisa során. Nem funkcionális bontást adunk, hanem egy olyan jellegű megkülönböztetést, amely

a

felhasználói

hozzáférés

tekintetében

eltérő

módon

kezelünk

a

rendszerben, így megpróbálunk minden, a rendszerben előforduló, tipikus esetet lekezelni.


149


A rendszerben lesznek felhasználói azonosítás nélkül elérhető (publikus), illetve felhasználói azonosítással, illetve jogosultsági szűréssel elérhető funkciók.

Ezen felül adat szintű szűrést is biztosítunk az intézmények, gazdasági társaságok és pályázatok nyilvántartásához kapcsolódó adatrögzítő felületen, ahol egy adott adatkört csak az adott szervezet adatainak kezelésével felhatalmazott személy módosíthat/láthat.

Interfészek A forrás rendszerek egy speciális területet jelentenek, mert itt felhasználói azonosítás nem kerül szóba, mivel mind a forrás-, mind a célrendszer csak, mint automatikus folyamat jelenik meg, azonban az adatok biztonsága, illetve módosíthatatlansága itt is szerepel célként. A LOGO rendszer felől érkező adatinterfészt az adatbázison belül alakítjuk ki, így az adatok sértetlensége és védelme az illetéktelen hozzáférések ellen biztosított már az adatbázis védelmi rendszere miatt. Az egyéb forrásrendszerek közvetlen elérésekor a kapcsolat felépítése belső, hálózati határvédelem eszközeivel védett csatornákon történik. Az

egyéb

forrásrendszerekből

származó

fájlok

továbbításakor,

amelyeket

titkosított protokollon javasolunk áttölteni a LOGO-VIR rendszerbe, ezáltal biztosítható lesz az adatok sértetlensége, és az átviteli csatornán történő hozzáférés védelme is. Ez a protokoll jellemzően valamely SSL alapú titkosított átvitel (scp, sftp, https, stb.)

Önkormányzati felület Az önkormányzati felület, úgynevezett fő alkalmazásfelület, a legösszetettebb jogosultsági szintekkel védett terület.

Felhasználói azonosítás után érhető el

bármely funkciója. Különböző jogosultsági szinteket alakítunk ki, amely segítségével az egyes rendszerfunkciók szintjén tudjuk az elérést korlátozni, ez az egyes funkciók esetén lehet


150


a funkció korlátozott elérése (csak olvasható) a funkció teljes elérése (olvasható, módosítható adatok) a funkció tiltása, ekkor egyáltalán nem érhető el a felhasználók számára az adott funkció. Mindezek miatt a felület elérése titkosított (https) protokollon keresztül is lehetséges.

Önkormányzati intézmények hozzáférése A felület nem a belső felhasználók számára szolgál funkciókkal, a feladata, hogy az

egyes

önkormányzati

szervezetek

bizonyos

adatrögzítő,

karbantartó

felületeket érjenek el. Ezek szintén csak felhasználói azonosítás alapján érhetők el, biztosítjuk a belső, önkormányzati felülethez hasonlóan a funkciószintű korlátozásokat, illetve ezen felül adatrekord szintű korlátozásokat is. Ennek célja, hogy egy adott szervezet felhasználója csak a saját szervezetére vonatkozó adatokat láthassa. Az önkormányzati szintű, tehát az összes szervezet adatát kezelő, lekérdező funkciók az önkormányzati belső felületen lesznek csak elérhetőek, így elegendő ezen funkció esetén az szervezetekre vonatkozó adatszűrés alapértelmezetten. Ezen a felületen, mivel külső felhasználók használják jellemzően, a funkció szintű korlátozásokat is a lehető legszűkebbre kívánjuk venni, csak a legszükségesebb adatrögzítő és ellenőrző funkciók elérését biztosítva. Mindezek miatt a felület elérése titkosított (https) protokollon keresztül is lehetséges.

Publikus felület A publikus felület felépítése a legegyszerűbb az adatbiztonság szempontjából, mivel itt felhasználói azonosítás nem szükséges. A felület elérése megfelelő a http protokoll is, nem szükséges titkosítás. A publikus felületen megjelenő adatok nyilvánossá tétele előtt az önkormányzati belső felületen biztosítunk egy felhasználói jogosultságtól függő feltöltési funkciót, tehát a publikus felületre csak jóváhagyott anyagok kerülhetnek.


151


4.4.2.4. Felépítés A rendszerbiztonság számos eszközzel érhető el, ennek elemeit mutatjuk be a fejezetben. Ezek mind a fenti elvek és célok elérése érdekében alkalmazandó eszközök.

Felhasználói jogosultsági rendszer A LOGO felhasználói azonosítási és jogosultsági rendszerét vesszük alapul, ez kerül felhasználásra a kialakítandó LOGO-VIR rendszer esetében is. Nem a modul újrafelhasználásról beszélünk, hanem teljes rendszer szintű integrációról, tehát a LOGO-VIR rendszer és a LOGO felhasználó kezelése, címtára, stb. ugyanaz lesz, nem több elkülönült modul.

Hálózati határvédelem Fontos megemlíteni a rendszerbe történő behatolás védelmet is, mely a rendszer szerverparkja körüli tűzfalakat takarja, szintén a LOGO által alkalmazott eszközök használatával. A LOGO rendszer tűzfal kialakítása megfelelő a LOGO-VIR rendszer számára is, így ezzel kapcsolatosan fejlesztésre, bővítésre nincs szükség. A LOGO által használt hálózati struktúra kialakítása lesz a LOGO-VIR rendszer esetében

is

mérvadó,

mivel

teljes

rendszerintegráció,

és

az

közös

hardvereszközök használata révén ezt, mint adottságot is kezelhetjük. A

feladat

csupán

arra

koncentrálódik,

hogy

a

megfelelő

LOGO-VIR

komponenseket a LOGO megfelelő komponensei mellé helyezzük, tehát a publikus felületeket a DMZ-be, az egyéb és az rögzítő felületeteket és a belső modulokat a védett szerver területre. Mindezek okán a hálózati struktúra a következőképpen fog kinézni: A tűzfal DMZ lábára kötve helyezkedik el a LOGO-WEB szerver, ezzel lesz kapcsolatban a külvilág, ezen fog elhelyezkedni a publikus felület. A tűzfal szerver oldalán helyezkednek el az egyéb felületek, illetve az adatbázis szerver.


152


4.4.3.

Hardver és szoftver architektúra

Az ábrán a jelenlegi LOGO rendszer komponensei láthatóak. Alapvetően a rendszer logikailag két részre osztható: a hivatali back-office tevékenységet integráltan támogató vékonyklienses technológiát alkalmazó LOGO-APP, és a webes publikációkért, a rendszer szolgáltatásainak egy részét a külvilág felől elérhetővé tevő LOGO-WEB alrendszerekre. A LOGO-APP alrendszer 3 specifikus szerverre van telepítve. Fizikailag különálló szerverre került telepítésre a LOGOWEB alrendszer. A LOGO-APP mind a hivatali intranet felől, mind a külvilág felől tűzfallal védett. Külön szeparált tűzfalzónába került elhelyezésre a LOGO-WEB alrendszer, ily módon akadályozva meg az illetéktelen hozzáférést. A hivatali intraneten keresztül hozzáférhető a ForrásSQL rendszer adatbázisát futtató adatbázis szerverek. Szintén a hivatali intranet részét képezik az infrastruktúra

(hálózat)

működéséért

felelős

szerverek

(Active

Directory,

Fájlszerver). Az

ábrán

feltüntetett,

jelenlegi

állapotot

tükröző

hardver-

és

szoftverinfrastruktúra véleményünk szerint megfelelő lesz a LOGO-VIR rendszer számára. További hardver, és alapszoftver beszerzését nem indokolt, ezért nem szükséges hardver vagy alapszoftver fejlesztés.


153


4.4.3.1. Active Directory Típus: COMPAQ ML370 DNS név: ATHOS IP cím: 192.168.1.2 Operációs Rendszer: Windows 2000 Server SP4

Konfiguráció Processzor: 2 x 3,2 Ghz Xeon RAM: 2 GB


154


HDD: 4x72,8 GB SCSI LAN: HPNC 7781 Gigabit

Alkalmazások: Proxy szerver, DNS szerver, Samba szerver

4.4.3.2. Forrás SQL Típus: COMPAQ DL380G5 DNS név: ALBERT IP cím: 192.168.1.16 Operációs Rendszer: Windows 2003 Server SP2

Konfiguráció Processzor: 2 x 3 GHz Xeon Dual Core RAM: 4 GB HDD: 8x72 GB SCSI LAN: HPNC 373i Gigabit

Alkalmazások: Microsoft SQL 2005, Forrás adatbázis szerver

4.4.3.3. Fájlszerver Típus: COMPAQ ML370 DNS név: TERMINATOR IP cím: 192.168.1.14 Operációs Rendszer: Windows 2000 Server SP4


155


Konfiguráció Processzor: 2 x 2,4 GHz Xeon RAM: 2 GB HDD: 4x72,8 GB SCSI, 2x36,4 GB SCSI LAN: HPNC 7781 Gigabit

Alkalmazások: Active Directory backup, file szerver

4.4.3.4. Hivatali kliensek A hivatali munkatársak számítógépek. Általános irodai munkavégzésre alkalmas PC-k, operációs rendszerük Windows XP, és internet böngészővel (Internet Explorer, Firefox, stb.) felszereltek.

4.4.3.5. Ügyfélkapu központi rendszer A LOGO-WEB alrendszer súlyponti eleme bizonyos ügytípusok Ügyfélkapus regisztráció birtokában történő online intézése. Ennek érdekében az Ügyfélkapus azonosítás integráltan van jelen a LOGO-WEB alrendszerben, ehhez az alrendszer két

kommunikációs

csatornát

használ

a

központi

Ügyfélkapu

rendszerrel,

egyidejűleg VPN-nen, és https protokollon is kommunikál.

4.4.3.6. LOGO

4.4.3.6.1. Adatbázisszerver Típus: IBM System X 3650 DNS név: LoGoDB4 IP cím: 192.168.34.15 Operációs Rendszer: Red Hat Enterprise Linux


156


Konfiguráció Processzor: 2 x 3 Ghz Xeon QuadCore RAM: 20GB HDD: 8x146,8 GB SAS LAN: Integrated Dual Gigabit Ethernet

Alkalmazások: Oracle Database Standard Edition ONE 2 db processor licence

4.4.3.6.2. Alkalmazásszerver Típus: IBM System X 3650 DNS név: LoGoIAS IP cím: 192.168.34.10 Operációs Rendszer: Red Hat Enterprise Linux

Konfiguráció Processzor: 2 x 3 Ghz Xeon QuadCore RAM: 4 GB HDD: 3x73,4 GB SCSI LAN: Integrated Dual Gigabit Ethernet

Alkalmazások: Apache Tomcat 6.0.14 alkalmazásszerver (webkonténer)

4.4.3.6.3. GIS szerver Típus: IBM System X 3650 DNS név: LoGoTESTGIS


157


IP cím: 192.168.34.8 Operációs Rendszer: Windows 2003 Server Standard Edition 32bit

Konfiguráció Processzor: 1 x 3 Ghz Xeon RAM: 4 GB HDD: 2x36,4 GB SCSI LAN: Integrated Dual Gigabit Ethernet

Alkalmazások: Autodesk MapGuide 6.5

4.4.3.7. LOGO-WEB DNS név: LoGoWEB1 IP cím: 192.168.35.11 Operációs Rendszer: Red Hat Enterprise Linux 3 Konfiguráció Processzor: 1 x 3 GHz Xeon Dual Core RAM: 1 GB Alkalmazások: PostgreSQL Adatbázis szerver Apache PHP webszerver

4.4.3.7.1. Adatbázisszerver PostgresSQL adatbázisszerver


158


4.4.3.7.2. Webszerver Apache webszerver PHP modul-kiterjesztéssel.


159


4.4.4.

Fejlesztési módszertan

Az alábbiakban bemutatjuk az Szállító Daten-Kontor Kft. munkavégzésének kereteit

meghatározó

minőségirányítási

rendszerét,

melynek

része

a

szoftverfejlesztési módszertan bemutatása. A Daten-Kontor Kft. az ISO 9001:2008 szabvány és a szoftverfejlesztő cégekre vonatkozó ISO 9000-3

ajánlás alapelveihez illeszkedő -

minőségirányítási

rendszert üzemeltet, melyet az SGS Magyarország Kft már több ízben tanúsított. A szoftvertermékek tervezése és előállítása a fenti szabványok és ajánlás irányelvei

alapján

felépített

minőségügyi

rendszer

keretében

történik.

Az

általános követelményeket a Minőségügyi Kézikönyv és a kapcsolódó eljárások rögzítik. Cégünk alaptevékenysége egyedi vevői igényeket kielégítő szoftvertermékek tervezése, fejlesztése, telepítése, adaptálása, illetve üzemeltetése, támogatása, gondozása, továbbfejlesztése (karbantartása). A fejlesztési folyamatba beépített ellenőrzési

pontok

és

mechanizmusok

követelményeinek

teljesülését

életciklusa

Minden

során.

az

biztosítják

adott

informatikai

a minőségügyi

szoftvertermék fejlesztésünk

teljes

rendszer fejlesztési

szabványosítottan

és

dokumentáltan valósul meg a minőségirányítási rendszer keretei között.

Új projekt előkészítése Új projekt előkészítésére –a pályázat megírására - az ügyvezető igazgató Projektvezetőt (továbbiakban: PV) jelöl ki. A PV információt gyűjt a megoldandó feladatról, annak céljairól, terjedelméről, a megoldásban érintettek várható köréről, szerepéről, az érdekeltek előzetes várakozásairól (határidők), stb. az összegyűlt információkat rendszerezi, mert nyersanyagul fognak szolgálni a projekt hivatalos indítása után készítendő ún. Projekttervhez. A PV feladata közreműködni a szerződés előkészítésében, lehetőség szerint projekt-módszertani szempontokkal, ötletekkel segítve azt. A PV feladata továbbá a szerződés műszaki melléklete elkészítésében való közreműködés, majd - az aláírást megelőző - szakmai felülvizsgálat is.


160


Projekt indítása, a projekt-terv kidolgozása Sikeres előkészítés után, a pályázat eredményhirdetésekor, a cég vezetői szintjén döntés születik a projekt tényleges indításáról. Erről a döntésről egy rövid jegyzőkönyv készül. A

projekt

hivatalos

indítását

követően

meg

kell

kezdeni

a

projekt-terv

(továbbiakban: PTD = Projekt-Terv Dokumentum) készítését. A PTD készítéséért a PV felel, a tervezési munkát irányítja, maga is részt vesz a kidolgozásában, de igénybe a veszi a projekttagok segítségét is. A PTD kidolgozása során már figyelembe kell venni a szerződésbe foglalt követelményeket is. A Projektterv készítésének alapcélja a projekt teljesülés, előrehaladás nyomonkövetéséhez szükséges követelményoldal áttekinthető és mérhető módon történő létrehozása, megteremtve ezzel a projekt menedzsment jellegű ellenőrzésének eszközeit és lehetőségeit. A Projektterv készítésének másik célja, hogy a projektmunkában résztvevők számára szabványos kereteket határozzon meg a munka végzéséhez. Járulékos célja a projekttervnek, hogy a projekt munkáját felügyelő vezetők (mind a Megrendelő, mind az Ajánlattevő oldalán) általa ellenőrizni tudják, hogy a projektmunkát határokat

közvetlenül

(időben,

irányítók

helyesen

erőforrásokban),

értelmezték-e

világosak-e

a

a

projekt

célokat, elé

a

állított

követelmények, és elvárások. A PTD főbb tartalmi elemei röviden a következők: A projekt céljainak, tartalmi és szervezeti kereteinek meghatározása A

feladatok

megvalósításának

ütemterve

és

az

ahhoz

szükséges

minőségirányítás

elemeinek

erőforrások felmérése Minőségügyi

terv,

a

projekten

belüli

meghatározása A projekt működési környezetének és szabályainak definiálása A projektkövetés és ellenőrzés szabályainak összefoglalása A projekttervet, elkészülte után – célszerűen a szerződés véglegesítését, aláírását követően – felül kell vizsgálni.


161


Vevői követelmények összegyűjtése Egy szoftverelem fejlesztési ciklusa a vevői követelmények összegyűjtésével, az ún.

Vevői

Követelmény-specifikáció

(VKS)

megfogalmazásával

indul.

A

követelmények tárgyukat tekintve lehetnek funkcionális, interfész-, teljesítmény-, és egyéb (pl. biztonsági) követelmények. A fejlesztési feladat végrehajtása csak akkor kezdődhet meg, ha a követelmények tekintetében teljes – és bizonylatolt egyetértés alakul ki a vevő és a DK között. A VKS többnyire egy szabad formátumú szöveges dokumentum, amelyben a vevő megfogalmazza szoftverelemek fejlesztésére vagy meglévő elemek módosítására vonatkozó elvárásait, követelményeit. Ha a VKS formátumát szerződés írja elő, úgy e formátum használata kötelező. Mivel a VKS a vevő szemszögéből írja le a feladatot, szakmai felülvizsgálatra és elemzésre van szükség a megvalósíthatóság felmérése és a követelményeknek fejlesztési feladatokra való lefordítása érdekében. A VKS egy gyűjtőfogalom, amely nem egy rögzített szerkezetű dokumentumot takar. VKS-ként szolgálhat például egy tenderkiírás műszaki melléklete, a vevő által küldött levél, vagy egy követelmény-definíciós megbeszélés emlékeztetője is. A

VKS

elektronikus

vagy

nyomtatott

dokumentum,

melyet

a

projektdokumentumok között kell megőrizni.

Műszaki tervezés A vevői követelmények meghatározását követően, elfogadott követelménylista alapján kezdődik meg a fejlesztési feladat végrehajtása, azaz egy fejlesztési ciklus indítása. Ennek első szakasza a vevői igények (követelmények) lebontása műszaki jellemzőkre, azaz a terméktervek elkészítése. E szakasz során a munkacsoport tervező szakemberei elkészítik "Rendszerterv"-et alkotó

dokumentumokat.

A

terveket

felülvizsgálatnak

vetjük

alá,

majd

megfelelőség esetén következik a kivitelezés, ami legtöbb esetben valamilyen programozási feladat végrehajtását jelenti.


162


Rendszertervezés A szoftvertermék elkészítésének alapja, a vevői követelmények részletes műszaki tervekké való leképezése a Rendszerterv. A

Rendszerterv

általában

egy

dokumentumcsoport,

amely

a

termék

elkészítéséhez szükséges valamennyi technikai részletet tartalmazza, s amelynek minősége a végtermék minőségének kulcstényezője. A Rendszerterv a szoftverterméket ún. tervezési egységekre bontva írja le. A tervezési egységek meghatározását úgy kell végezni, hogy együttesen a megvalósítási javaslatban rögzített teljes követelményrendszert lefedjék. Minden tervezési

egységről

egyértelműen

el

kell

tudni

dönteni,

hogy

mely

követelményhez kapcsolódik. Az elkészült terveket szakmai felülvizsgálatnak vetjük alá a specifikációs hibák lehető legkorábbi kiszűrése érdekében. A felülvizsgálat a teljes Rendszertervre együtt, vagy az egyes tervrészekre önállóan végezhető. A választott megoldást a feladat jellege (bonyolultság, határidő stb.) szabja meg. A felülvizsgálat célja annak megállapítása, hogy az elkészült tervek eleget tesznek-e az előzmény-dokumentumokban megfogalmazott követelményeknek, valamennyi (rész)követelmény műszaki specifikációra való leképezése megtörtént-e, nincs-e ellentmondás az egymásra épülő vagy hivatkozó tervrészek között, nem tartalmaz-e a terv nyilvánvalóan felesleges elemeket, nem tartalmaz-e a terv az ismert korlátok (műszaki, idő, költség stb.) között nem megvalósítható elemeket, azaz: rendelkezésre állnak-e a szükséges erőforrások. A felülvizsgálatot lehetőség szerint a tervrészek elkészítésében közvetlenül nem érintett munkatárs végzi. A vizsgálat tényét a későbbi igazolhatóságot lehetővé tevő módon kell megőrizni. A felülvizsgálat által feltárt hiányosságok, nemmegfelelőségek javításáról intézkedni kell. A tervezés – felülvizsgálat - javítás ciklus mindaddig ismételendő, míg a maradó hibák száma az elérhető minimális szintre nem csökken. A felülvizsgálat tényének regisztrálása csak a szükséges


163


javítások elvégzése után, a végleges tervváltozaton történik meg. Mielőtt az adott rendszertervet a vevőhöz továbbítanánk, belső felülvizsgálatnak vetjük alá.

Rendszerterv jóváhagyása A rendszerterv célja, hogy elősegítse a tennivalók pontosítását, a feladat azonos értelmezését, csökkentse a félreértésből származó tervezési hiba valószínűségét. Ebből kifolyólag szükséges a rendszerterv Vevő oldali megismerése, ellenőrzése, véleményezése, jóváhagyása. A

követelmények

véglegesítése

érdekében

a

fentiek

szerint

elkészített

rendszertervet a vevő átvizsgálja, és egyetértése esetén ezt – lehetőleg írásban, pl. e-mail formájában – jelzi. Véleményeltérés esetén további pontosítás történik, melynek eredményeként végül előáll egy elfogadott, megvalósításra bocsátható rendszerterv. A vevővel való egyeztetést és a rendszerterv véglegesítést a feladat megoldásának – projekttervben rögzített - felelőse végzi. A megfogalmazott követelmények teljesítése akkor kezdődhet meg, ha a vevő és a DK között egyetértés alakult ki a megoldandó feladatok és a megoldás módja tekintetében. A

rendszerterv

elfogadását

követően

a

projektvezető

vagy

a

tervező

kezdeményezi a feladat végrehajtását.

A terv módosítása A szoftverfejlesztési folyamat jellemzője, hogy a felülvizsgált, jóváhagyott és kivitelezési fázisban lévő terveken – esetenként – utólag változtatást kell végezni. Ennek oka részben az, hogy a vevői igények változhatnak, és ennek a változásnak a tervekben is meg kell jelennie, másrészt pedig az, hogy a tervezést követő megvalósítási fázisokban felmerülő kisebb – szükségszerű vagy célszerű – módosítási (javítási, pontosítási) igényeket is vissza kell csatolni a tervekbe. A tervek aktualizálása bizonyos esetekben csak késéssel követi a kivitelezést (programozást). Ez az állapot átmenetileg megengedett, azonban törekedni kell az összhang mielőbbi helyreállítására.


164


A Rendszerterv elemeinek módosítását bizonylatolt módon kell végezni. A módosított tervrészeket ismételt felülvizsgálatnak kell alávetni. A terv módosítása és aktualizálása a tervező feladata.

Kivitelezés A felülvizsgált és jóváhagyott tervek alapján történik a kivitelezés, ami a gyakorlatban programok, adatszerkezetek elkészítését vagy módosítását, vagy adattartalom módosítását jelenti. A kivitelezés általános lépései: Feladat kiadása. Feladat elfogadása (vagy visszautasítása). Feladat végrehajtása. Fejlesztői teszt – A feladat kivitelezőjének kötelessége, hogy - a kivitelezés utolsó lépéseként – elvégezze munkájának első ellenőrzését. Bár a fejlesztési ciklus következő szakaszában a szoftverterméket módszeres, átfogó és bizonylatolt ellenőrzésnek vetjük alá, minden feladatvégzőnek kötelessége meggyőződni munkája eredményének helyességéről. Feladat lezárása. A DK gyakorlatában a feladatok kiadása, elfogadása, készre jelentése többnyire elektronikus csatornákon, e-mail-ek formájában történik, a projekteken belüli munkamódszerek részleteiről a projekttervek rendelkeznek.

Tesztelés A kibocsátandó termék megfelelőségének biztosítása érdekében a fejlesztési folyamatnak a projektterv által rögzített pontjain bizonylatolt tesztelést kell végezni. Valamennyi teszttel szemben általános követelmény a tárgyilagosság, az egyértelműség és a reprodukálhatóság. A teszt megfelelő módon történő, eredményes végrehajtása érdekében a teszteket pontosan meg kell tervezni, teszttervet kell készíteni, és a végrehajtás tényét és eredményeit megfelelő módon bizonylatolni kell.


165


A tesztek tervezése a terméktervezési és fejlesztési munkákkal párhuzamosan, több

szinten

(tesztterv,

teszt-specifikáció)

történik,

és

a

követelmények

meghatározásától a tesztek végrehajtásáig a teljes fejlesztési ciklust végigkíséri. Az önálló tesztterv készítési kötelezettség az új termékek előállítását, vagy meglévő termékek új környezetbe történő telepítését (adaptációját) célzó projektek esetében áll fenn. A már éles üzemben működő szoftvertermékek karbantartási, támogatási (gondozási) feladataihoz, azok nagy számossága és jellemzően kisebb mérete miatt általában nem szükséges külön tesztterv készítése (a módosítandó funkciók ellenőrzését célzó teszt-specifikációinak elkészítése azonban itt is szükséges). Kivételes esetekben, a karbantartási szerződések keretében zajló, jelentősebb mértékű módosítások esetében itt is célszerű lehet külön tesztterv készítése, ezekről az esetekről adott téma vezetője dönt. A tesztek fajtái Az ellenőrzés szintje alapján az alábbi tesztfajtákat különböztetjük meg: Komponensteszt – Célja annak megállapítása, hogy a szoftverelemek egyedileg kielégítik a tervekben rögzített követelményeket. (Általában maga a fejlesztő / programozó végzi, bizonylatolási kötelezettség nem terheli.) Rendszerteszt

–

A

szoftvertermék

mint

rendszer

vizsgálata

annak

megállapítására, hogy a szoftverelemek képesek a Rendszertervben specifikált módon együttműködni, a terv követelményei teljesülnek. Integrációs teszt – A fejlesztett rendszer és a felhasználó informatikai környezetét alkotó társrendszerek együttműködésének vizsgálatát célozza. Feladata annak megállapítása, hogy a szoftverelem beilleszthető-e a majdani üzemi környezetbe. Átvételi teszt – Célja annak megállapítása, hogy a szoftvertermék mint rendszer,

kielégíti-e

vevői

követelményeket,

megfelel-e

a

vevő

elvárásainak. Terhelési

teszt

-

A

rendszer

terhelhetőségének

vizsgálatát

célozza

(működés vizsgálata nagy adatmennyiségekkel, nagy felhasználószámmal stb.).


166


Tesztterv készítése A megvalósítási javaslat elfogadását követően (de legkésőbb a részletes tervek elkészültének

időpontjára)

a

fejlesztendő

szoftvertermékre

vonatkozóan

teszttervet kell készíteni. A tesztterv feladata, hogy meghatározza az elvégzendő tesztek fajtáját, nagyvonalú ütemezését, az elvégzendő tesztek tárgyát (funkciócsoportok, nagyobb modulok szintjén), a teszt végrehajtásához szükséges környezeti feltételeket (szükséges hardver- és szoftvereszközök stb.), a kritikus szoftverelemeket (amelyeknél kötelező a tesztspecifikáció felülvizsgálata), a teszt lefolytatásához esetlegesen szükséges külső feltételeket (pl. integrációs tesztben részt vevő környezeti rendszerek, külső partnerek), a tesztadatokkal szembeni követelményeket (az adatok biztosításának felelősei, határidő, mennyiség, forrás, stb.), a tesztelési tevékenység bizonylatolásának módját, a teszt-specifikációs és végrehajtási feladatok felelőseit és ütemezését. A tesztterv az alapja a műszaki tervezéssel párhuzamosan (ill. a kivitelezés során) készülő teszt-specifikációs tevékenységnek. Teszt-specifikáció készítése A teszttervben meghatározott szoftverelemekre, a műszaki tervek (Rendszerterv, FSP) alapján részletes teszt-specifikációt (TSP) kell készíteni. A TSP – a feladat kiterjedésétől függően egy vagy több – gyűjtő dokumentum, amely összefogja a termék megfelelőségének ellenőrzéséhez szükséges lépéseket és a vizsgálandó eseteket. A TSP feladata meghatározni: a teszt tárgyát (a vizsgálandó szoftverelem egyértelmű és pontos meghatározását), az elvégzendő teszt típusát (pl. modulteszt, rendszerteszt, átvételi teszt), a használandó eszközöket (teszt-szoftver), a tesztelendő jellemzőket és szempontokat (teszteseteket),


167


a végrehajtás során követendő lépéseket. A teszt-specifikációt (az egyedi teszteseteket, és szükség esetén az eljárásokat) lehetőleg a teszt tárgyát képező szoftverelem kivitelezésének végéig (de legkésőbb a tesztek megkezdésének időpontjára) el kell készíteni. Készítése a részletes terveket készítő tervezőnek, vagy a projekttervben, illetve teszttervben meghatározott projekttagnak a feladata. A

részletes

teszttervezés

szintjén

történik

a

termék

megfelelőségének

ellenőrzésére alkalmas egyedi tesztesetek kidolgozása. E

munka

során

a

részletes

feladat-specifikációkban

(FSP)

rögzített

követelményekből kell kiindulni. A teszteset leírásának tartalmaznia kell az alábbiakat: a teszteset egyedi azonosítóját, a teszt tárgyának egyértelmű meghatározását (program, modul, eljárás stb.), a szükséges beállításokat (előfeltételek, beállítások), az elvárt viselkedést (kimenetek), paraméterek (a reprodukálhatóságot szolgáló konkrét értékek stb.). A

teszt-specifikációs

fázisban

összegyűjtött

teszteseteket

az

ellenőrzés

végrehajtása során további, előre nem látott tesztesetek egészíthetik ki. Ezeket az eseteket a tesztet végrehajtó személy a tesztnaplóban rögzíti. Az új tesztesetekkel a teszt-specifikáció utólag kiegészítendő. A tesztesetek terjedelme a feladat bonyolultságától függően az egysorostól akár a több oldalasig terjedhet. A teszt-specifikáció felülvizsgálata A

tervező

által

készített

teszt-specifikációkat

a

vevői

követelmények

szempontjából kritikus szoftverelemek esetén felülvizsgálatnak vetjük alá. Hogy melyek ezek a szoftverelemek, azt a tesztterv rögzíti. A tesztek végrehajtása és bizonylatolása (tesztnapló) A teszt-specifikáció alapján, a szoftverelemek kivitelezési fázisának végén el kell végezni a teszt-specifikációban előírt ellenőrzéseket. A teszt-specifikációban meghatározott tesztesetekből, mint teljes készletből, a tesztelést végző személy állítja elő azt a részhalmazt, amit egy tesztfutás során vizsgálni kíván. A


168


kiválasztott teszteset-listával mint induló tartalommal készül el a tesztnapló. A végrehajtás során a Tesztnaplóban szereplő valamennyi tesztesetet végre kell hajtani. A végrehajtás igazolására a Tesztnapló megfelelő bejegyzései szolgálnak. A tesztek értékelése, az eredmények visszacsatolása A teszt lezárását követően sor kerül a tesztnaplók kiértékelésére, a tesztnaplóban regisztrált eredmények és a specifikációban felállított elfogadási kritériumok (elvárt

eredmények)

összevetése.

Ha

a

teszt

eredménye

megfelelő,

a

szoftverelem a konfiguráció-kezelési eljárásba beilleszthető. Ellenkező esetben a talált nem-megfelelőségek okát fel kell deríteni, a javításról intézkedni kell. A javítást célzó módosításokat a fejlesztési ciklus megfelelő pontjain (követelmény-specifikálás, tervezés, kivitelezés) el kell végezni. A javítások elvégzése után - az eredeti specifikáció használatával - ismételt tesztelést kell végezni. Az ismételt tesztelésnek alávetett elemeknél ez egyes tesztelési menetek bizonyítékát meg kell őrizni (pl. külön tesztnapló-sorok vagy külön tesztnaplók formájában), hogy így követhetővé váljon a hibák kijavításának folyamata. A teszt során nem megfelelőnek minősített szoftverelemet "fejlesztés alatt" státuszban kell tartani mindaddig, amíg egy tesztnaplóval nem igazolható a megfelelőség elérése. A teszteredmények értékelését a tesztelést végző személyek és a tesztspecifikációt

készítő

tervező

végzik,

a

témavezető

által

kijelölt

személy

vezetésével. Az értékelést vezető személy feladata a vizsgált elem sorsáról dönteni. Szükség esetén e ponton döntés születhet a hibák ismételt előfordulását megakadályozó helyesbítő-megelőző tevékenység indításáról. Termékdokumentumok előállítása A DK által fejlesztett szoftvertermékekhez – a termék jellegétől, felhasználói körétől, az üzemeltetés és használat körülményeitől függően – különböző kísérő dokumentumok

tartozhatnak.

Ezek

közül

egyesek

minden

termék

esetén

elkészítendők, mások viszont csak bizonyos feltételek teljesülésekor. A dokumentumok elektronikus formában készülnek, és terjesztésük is jellemzően elektronikus

csatornákon

megállapodástól

függően

történik. –

a

Az

esetek

dokumentumok

egy

részében

nyomtatott

–

a

vevői

formában

is

megjelennek.


169


A terméktámogatási dokumentumok körébe az alábbi írásos anyagok tartoznak: Felhasználói (kezelési) leírás; Üzemeltetési leírás; A termékdokumentumok rendszerét az alábbi szempontokat szem előtt tartva kell megtervezni: A szoftvertermék jellege (architektúra, infrastruktúra, használat módja, telepítés módja, üzemeltetés körülményei stb.). A

megcélzott

közönség

(felhasználói

kör,

felhasználók

száma,

felkészültség, előképzettség stb.). A

dokumentumok

használatának

módja

(tankönyv,

referencia-

dokumentum stb.). A szerződés, vagy a projektterv rendelkezik arról, hogy a szoftvertermékhez a felsoroltak közül mely dokumentumok elkészítése kötelező. Termékdokumentumok ellenőrzése, jóváhagyása Akárcsak maga a szoftvertermék, a terméket kísérő dokumentumok is csak megfelelő ellenőrzés után bocsáthatók ki. Az elkészült dokumentumokat ezért projekten belüli felülvizsgálatnak vetjük alá. A felülvizsgálatot lehetőleg a munkacsoportnak a dokumentumok készítésében közvetlenül nem érintett tagjai végzik, aki azonban megfelelő mélységben ismerik a dokumentumok tárgyát, és akik képesek az anyagok megfelelőségéről dönteni.

Oktatási terv A

szoftvertermék

zökkenőmentes

használatba

vételéhez

szükséges

a

végfelhasználói és üzemeltetői személyzet kiképzése, felkészítése. Amennyiben ez a feladat az Ajánlattevőre hárul, az ebből származó tevékenységeket és az elkészítendő “termékeket” oktatási tervben kell rögzíteni. Ennek keretében célszerű rendelkezni az alábbi szempontokról: Az oktatások tematikájáról. A felhasználói “célcsoportokról” (szerepkörökről). Az oktatások helyszínéről és időpontjáról.


170


Az oktatást végző személyekről, a velük kapcsolatos elvárásokról. A hallgatóságtól elvárt felkészültségről, alapképzettségről. A visszacsatolás, ellenőrzés módjáról (vizsga, teszt stb.). Az oktatások bizonylatolási módjáról (jelenléti ív stb.). A szervezés felelősségi kérdéseiről. A szükséges infrastruktúráról és annak biztosítási módjáról (felelősök). A szükséges oktatási anyagokról (tartalom, elkészítés, sokszorosítás, felelős). Az

oktatási

anyagok

és

a

termékben

bekövetkező

változások

összehangolásának módjáról (a Változáskezelési tervvel összhangban). Az oktatások ellenőrzéséről, kiértékeléséről.

Átadás, telepítés, üzembe helyezés A szoftvertermék fejlesztésének utolsó fázisa az elkészült termék és a kapcsolódó kísérődokumentumok átadása. A vevői megállapodás (szerződés) rendelkezik arról, hogy a termék telepítése a vevő telephelyén, és a termék integrálása a vevő üzemi környezetébe a Vevő, vagy a Szállító feladata-e. Az átadás-átvételi eljárás lépéseit, főbb jellemzőit célszerű a szállítási szerződésekben rögzíteni. Amennyiben – a megállapodás alapján – a telepítés, éles üzembe állítás nem szállítói feladat, akkor az átadási-átvételi eljárás keretében általában az alábbi termékek átadása szükséges Az elkészült és a tesztelés során megfelelőnek minősített programelemek telepítő készletének átadása. Az éles adatbázis-környezet létrehozásához / új verzióra való átállásához szükséges ún. adatbázis-scriptek átadása. A termékkísérő dokumentumok átadása. Amennyiben

szállítói

feladat

volt,

az

átadás-átvételt

megelőzően

megtörténik az érintett felhasználók / rendszergazdák oktatása (termék használata ill. üzemeltetése). Amennyiben a termék telepítése, éles üzembe helyezése szállítói feladat, akkor az


171


a telepítési eljárás keretében történik: Az elkészült és a tesztelés során megfelelőnek minősített programelemek telepítése a vevő által meghatározott környezetbe. Az új programelemek működéséhez szükséges, ún. „éles” adatbáziselemek kialakítása. A szoftvertermék és a környezeti rendszerek közti interfész-kapcsolatok beüzemelése/módosítása. A szoftverelemek működésének ellenőrzése az üzemi környezetben (üzemi teszt). Az éles üzem indítása.

Teszt és oktatási tervek átadása A Szállító a LOGO-VIR rendszer kialakítására tett ajánlatában részletesen ismertette a fejlesztés során alkalmazott módszertant. Mivel a jelen Rendszerterv néhány

kérdésben

nem

bocsátkozik

részletes

specifikációs

szintre,

a

módszertanban megjelölt teszt és oktatási tervek elkészítésére és átadására a projektindító megbeszélésen a részletes specifikációra és fejlesztésre kijelölt rendszerfejlesztési szolgáltatás fázisban kerül sor.


172


4.4.5.

Üzemeltetési terv

4.4.5.1. Körülmények A fejlesztendő LOGO-VIR rendszert a jelenlegi LOGO rendszerbe integrálva annak hardver- és szoftvereszközeit felhasználva kerül kialakításra. Ezért a kialakítandó rendszer üzemeltetési igényeit megpróbáljuk mindenben a jelen LOGO rendszer üzemeltetési rendszeréhez igazítani. Üzemeltetési terv szempontjából meg kell vizsgálni az üzemeltetéssel kapcsolatos feladatokat és követelményeket és körülményeket, melyek többek között a következőek: rendelkezésre állás mentés archiválás és archivált adatok elérhetősége, biztonságtechnika

Ezen körülmények figyelembevételével a rendszertervezési fázisban előzetesen, majd az átvételi-átadási tesztek során javaslatot teszünk a jelenleg alkalmazott mentési és archiválási tervek módosítására, mennyiben az szükséges, illetve bármely szempontból nem elégíti ki az új rendszer igényeit.

4.4.5.2. Személyi feltételek Mivel az új rendszer a LOGO rendszer jelenlegi hardver és alapszoftver architektúráján üzemel, új eszközök nem kerülnek telepítésre, ezért az új rendszer üzemeltetés és felhasználás területén sem igényel új tudást, illetve az üzemeltetéséhez nem lesz szükség több, esetleg új emberi erőforrásra. Az üzemeltető személyzettől elvárt, a LOGO üzemeltetésében jelenleg is használt ismeretek a következők: Web kezelési ismeretek SQL ismeret


173


4.4.5.3. A rendszer rendelkezésre állása A rendszer rendelkezésre

állása biztosítani

fogja a munkaidőben történő

zavartalan és folyamos munkavégzés lehetőségét. A hivatali felület rendelkezésre állása 5*10 óra. A publikus felületnek 7*24 órában elérhetőnek kell lenni, hogy az ügyfelek tértől és időtől függetlenül bármikor el tudják érni a rendszert. Abban az esetben, ha bármilyen oknál fogva nem lehet minden funkcionalitást elérni, akkor a rendszer tájékoztatni foga a felhasználókat a csökkentett funkcionalitású üzemmódról és a teljes funkcionalitás helyreállásának várható időpontjáról. A magas rendelkezésre állás esetén is szükségessé válhat leállás karbantartás, verzió

frissítési

céllal.

Ezeket

előre

tervezett

időpontokban

szükséges

végrehajtani. A rendszer magas rendelkezésre állását a gondosan összeválogatott, megfelelő redundanciával bíró eszközpark és a kifejlesztendő szoftverek megbízható működése, alaposan tesztelt volta fogja garantálni. Meghibásodás alapvetően a következő féleképpen kategorizálhatók, illetve a következőképpen védekezünk ellenük: Kliens oldali meghibásodás Védekezés: Megbízható PC-ket kell használni. Kiesés esetén a munka másik kliensről folytatható. Adatvesztést nem okoz, csak a meghibásodáskor függőben lévő tranzakciókat kell megismételni. Adatbázis szerver meghibásodás Védekezés: Redundáns háttértár, fürtözéses technológia alkalmazása Kiesés esetén az adott alkalmazás elveszti funkcionalitását A meghibásodás okozhat adatvesztést, amelyek az alább ismertetendő mentési módszerekkel minimalizálhatók. Alkalmazás szerver meghibásodás Védekezés: Több alkalmazásszervert fogunk használni, mely részben terheléselosztást is megvalósít. Kiesés esetén teljes funkcionalitással, de csökkentett teljesítménnyel


174


üzemképes marad a rendszer Adatvesztést nem okoz, csak a meghibásodáskor függőben lévő tranzakciókat kell megismételni. Hálózati meghibásodás Védekezés:

Megbízható

hálózati

elemek

alkalmazása.

A

kritikus

helyekre (topológia csomópontjai, szerverek közötti összeköttetés) redundáns kapcsolatokat kell kiépíteni. Kiesés esetén bizonyos területekről nem elérhető a rendszer. "Szerver közeli" meghibásodás esetén az alkalmazás elveszti funkcionalitását. Adatvesztést nem okoz, csak a meghibásodáskor függőben lévő tranzakciókat kell megismételni. Alkalmazás meghibásodás Védekezés: Ellenőrzött, szabályozott keretek között történő fejlesztés, tesztelés, verzió és konfiguráció kezelés. Az alkalmazás meghibásodása esetén teljes vagy részleges funkció vesztés lép fel. Adatvesztést, adat inkonzisztenciát okozhat. Meghibásodás esetén vissza kell térni az előző, üzemképes verzióra. Felül kell vizsgálni az esetleges adatvesztést, inkonzisztenciát. Az alkalmazás javítása után lehet áttérni a javított verzió használatára.

4.4.5.4. Javasolt mentési eljárások A rendszer relációs adatbázist és operációs rendszer szintű adatállományokat használ az adatok tárolására. A mentési rendszer fog gondoskodni a rendszer adatbázisának és az egyéb adatállományoknak a mentéséről. A mentések gyakoriságát és módját úgy kell meg megválasztani, hogy szükség esetén a mentésből az adatbázis a lehető legrövidebb időn belül helyreállítható legyen. A mentés módja a LOGO jelenlegi mentési módszere marad. Ennek tükrében a különböző állománytípusokra a következő mentési gyakoriságot javasoljuk:


175


Paraméterállomány A paraméterállományok az adatbázis elindításához szükséges, az adatbázissal illetve az adatbázis-példánnyal kapcsolatos információkat tartalmazó szöveges állomány. Minden változás esetén el kell menteni.

Vezérlőállományok Kis méretűnek mondható bináris adatállomány. Biztonsági okokból egy adatbáziskonfiguráció több vezérlőállományt tartalmaz. Használható vezérlőállomány nélkül az adatbázis is használhatatlan. A vezérlőállomány tartalmazza - többek között a fizikai adatbázis-konfigurációt. A vezérlőállományokra a paraméterfile-ban történik hivatkozás. A vezérlőállományokat az adatbázis-kezelő folyamatosan és párhuzamosan módosítja. Mentésük naponta indokolt.

Online naplóállományok Az

adatbázis-kezelő

információkat

az

adatbázison

folyamatosan

naplózza

végezett az

tranzakciókkal

online

kapcsolatos

naplóállományokban.

Egy

naplócsoportot alkotnak azok az online naplóállományok, amelyek írása – adatbiztonsági okokból - párhuzamosan történik. Amikor egy naplócsoport megtelik,

az

adatbázis-kezelő

automatikusan

„átkapcsol”

a

következő

naplócsoportra, és ha az adatbázis-kezelő archivelog módban fut, akkor a megtelt naplóállományt archiválja. Az online naplóállományok felhasználása ciklikus, ami azt jelenti, hogy amikor az utolsó naplócsoport is megtelt, akkor a naplócsoportok újra felhasználásra kerülnek. A működésből következik, hogy egy adatbáziskonfigurációban

legalább

kettő

online

naplócsoport

található.

Az

online

naplóállományok biztosítják azt – az archív naplóállományokkal együtt -, hogy az adatbázis megsérülése esetén az adatbázis egy mentett állapotából az online és szükség

esetén

az

archív

naplóállományok

felhasználásával

az

utolsó

adatbázismentés és az adatbázis megsérülése között végzett és így elveszett tranzakciókat előre görgessük, és a sérülést megelőző konzisztens adatbázist előállítsunk.

Archivált naplóállományok Az archivált naplóállományok az online naplóállományok archivált változatai. A megtelt online naplóállományok archiválásra kerülnek, ha az adatbázis-kezelő


176


ARCHIVELOG módban fut. Ezek az állományok – az online naplóállományokkal együtt – teszik lehetővé azt, hogy az adatbázis megsérülése esetén annak egy korábbi mentett állapotából kiindulva a naplóállományokban tárolt információk alapján az adatbázis mentése és meghibásodása között eltelt időszakban végzett és elveszett tranzakciókat előregörgessük, és így a meghibásodást közvetlenül megelőző konzisztens adatbázist előállítsuk.

Az adatbázis szerver mentése Az adatbázis mentése napi ciklusokban történik. A napi munka befejezése után (célszerűen éjszaka) adatbázison.

kell

elkészíteni

Naponta

az adatbázis mentését

(munkanapokon)

menteni

kell

zárt

állapotú

az

archív

naplóállományokat. A zárt adatbázis és az archív naplóállományok mentése az operációs rendszer mentő szoftverével történhet. A napló állományok és a zárt adatbázismentés

biztosítja,

hogy

az

adatbázis

egy

megadott

időpontig

konzisztensen helyreállítható legyen.

Alkalmazás szerverek mentése Az alkalmazásszerverek nem tartalmaznak "éles" adatot. Itt a mentésnek arra kell korlátozódni, hogy egy kiesett alkalmazásszerver esetén egy üres gépre minél előbb telepíthető legyen az alkalmazás a megfelelő konfigurációval. Az

alkalmazásszerver

konfigurációs

állományait

minden

módosításkor

kell

menteni. Az alkalmazás telepítéséhez pedig rendelkezésre kell állni minden verzió telepítőkészletének. Ennek biztosítása a fejlesztő feladata

4.4.5.5. Archiválás Míg a rendszeres mentés a rendszer mindenkori lehető leggyorsabb teljes mértékű legutolsó pillanatbeli helyreállítását szolgáltatott biztosítani, addig az Archiválás

feladata

a

rendszer

kívánt

időpontbeli

állapotában

történő

visszaállíthatósága. Míg a mentésnél a legfontosabb a gyorsaság a rendszer visszaállíthatósága érdekében, addig az archiválásnál oda kell figyelni az adatbiztonságra és a várhatóan

nagy

mennyiségű

adatok

minimálisan

szükséges

hosszú

idejű

redundáns online illetve offline tárolására, míg a kívánt időpontnak megfelelő


177


rendszerállapot visszaállítására megfelelő idő áll rendelkezésre. A kontrolling és vezetői információs rendszerben a szükséges elemzési adatok pont a hosszú távú elemezhetőség érdekében visszamenőleg historikusan el vannak tárolva több évre visszamenőleg. Ezért a legutolsó rendszerállapot visszaállíthatósága biztosítja az adatok több évre való visszaállíthatóságát, sőt kívánt időpont szerinti lekérdezhetőségét is. Ezrét megállapíthatjuk, hogy jelen esetben a kifejlesztendő rendszer nem támaszt újabb igényeket a meglévő LoGo rendszer mentésén és archiválásán túl.

4.4.5.6. Biztonságtechnika

Tűzfal alapú védelem A tűzfal alapú védelem alapját a biztonsági zónák alkotják. Minden eltérő biztonsági szintű hálózatrész külön tűzfal zónában kerül kialakításra. Az egyes zónák átlépésénél minden esetben az az alapelv érvényesül, hogy a magasabb biztonsági zónába tartozó rendszer kezdeményezheti a kommunikációt. Ez a rendszerek összekapcsolásának tipikus esete. Alacsonyabb zónából csak erős authentikáció esetén kezdeményezhető kapcsolatfelépítés. Ez a felhasználói hozzáférés tipikus példája. A következő biztonsági zónák kerülnek kialakításra: Authentikációs zóna Intranet Internet Remote access zóna Integrációs platform Dokumentum tár Tudás bázis Web portál publikus rész Web portál authentikált rész Munkafolyamat kezelő


178


Szakterületi modulok

Authentikációs modul (SSO)

Integrációs platform

Web portál védett

Dokumentum tár

Workflow Web portál publikus

Internet

Szakterületi Szakterületi modulok Szakterületi modulok modulok

Ügyfelek RAS szerver

ISDN/PSTN Intranet

Távoli bejelentkezők Ügyintézők

Az Hiba! A hivatkozási forrás nem található.Hiba! A hivatkozási forrás nem található.i ábrán a tűzfalak és biztonsági zónák elvi vázlata látható. Az egyes elemek nem feltétlenül külön gépet jelentenek, hanem az önkormányzati rendszer egyes doménjeit. A tűzfal rendszer nagy megbízhatóságú redundáns hardver és szoftver platformon lesz megvalósítva. A tűzfalak konfigurálását a "csak a minimálisan szükséges szolgáltatások" elve alapján kell elvégezni.

Protokollok A protokollok védelme az "osztott" hálózati szegmenseken indokolt. Ilyenek a felhasználók intranetes és internetes szegmensei. A rendszer a publikus adatok kivételével SSL-be ágyazott protokollokat fog használni (https, ldaps, ssh). A "dedikált" szegmenseken nem indokolt a titkosítás. Tipikusan ilyen egy


179


szerverfarmon a szerverek összeköttetése. Ott a védelmet a szerverfarm fizikai védelme adja, ami a hálózattól függetlenül is rendkívül fontos.

Távoli hozzáférés Távoli hozzáférés ISDN-es, PSTN-es behívással és Interneten keresztüli VPN-nel lesz megoldható. A behívásokat kezelő access szerver a központ authentikációs adatbázis segítségével végzi el a felhasználó azonosítását. A sikeres azonosítás után a felhasználó gyakorlatilag egy belső IP címet kap és minden olyan tevékenységet

elvégezhet,

amit

a

belső

hálózatról.

Azonban

a

központi

jogosultságkezelőben beállítható lesz az is, hogy bizonyos modulok elérhetők-e távoli hozzáférés segítségével vagy sem. A távoli elérés is megbontható a dial-in és az IP VPN-es szintre. A távoli elérés csak certificate-es authentikáció mellett lesz lehetséges.


180


4.5. Integrációs terv A fejezet bemutatja, hogy a LOGO logikai felépítésébe, illetve környezetébe hogyan

illeszkedik

az

új

LOGO-VIR

rendszer,

mely

rétegekbe,

milyen

interfészekkel, mik az integráció lépései a kívánt cél elérése érdekében.

4.5.1.

A rendszer illesztési módjának leírása

Lenti ábra mutatja a rendszer egyes elemei közötti kapcsolatot. Az ábrán vörössel jelzett elemek az új, LOGO-VIR rendszer által érintett elemeit. Az egyéb elemek a már az Önkormányzatnál létező LOGO és egyé b rendszerbéli elemek.


181



182


4.5.1.1. LOGO WEB

Lakossági tájékoztató felület A lakosság számára publikus eleme a LOGO rendszernek. Jelen projekt keretében a LOGO-WEB portál lesz a helye a civil szféra tájékoztatásának.

4.5.1.2. LOGO Alkalmazásszerver A rendszerben alkalmazott Apache Tomcat alkalmazásszerver és az abban működő felhasználói alkalmazások, valamint a felhasználói azonosítást végző LDAP adatbázis.

Riport modul A Riport

modulban lesz kialakítva a vezetői

információs rendszer, mely

segítségével az új rendszerben tárolt adatok teljes egészében lekérdezhetőek lesznek.

Általános nyilvántartó modul Az általános nyilvántartó modul részeként lesz kialakítva a szervezetek adatainak (intézmények, gazdasági társaságok, projektek) rögzítésére szolgáló felület, interfész.

4.5.1.3. LOGO Adatbázis szerver A

rendszert

kiszolgáló

ORACLE

adatbázis-kezelő,

és

az

abban

működő

háttérfolyamatok, funkcionalitások.

Adatkommunikációs interfész A Forrás rendszerből generált adatok rendszeres betöltésére szolgál. Az adatok a Forrás SQL adatbázis szerveréről automatikusan betöltésre kerülnek, illetve a


183


felületen biztosítunk a betöltéshez megfelelő funkcionalitást.

Adatpiac A lekérdezésekhez, riportokhoz generált adatok tárterülete.

LOGO rendszer adatai A jelenlegi LOGO rendszer és moduljainak adatai, adattáblái

Stage Nyers betöltött adatok ideiglenes tárolóhelye. Az adatok a LOGO-VIR rendszerbe való betöltés után a Stage-ből törlésre kerülnek.

Adatfeldolgozó modul Feladata a betöltött adatok megfelelő formátumba konvertálása, transzformálása, napi,

heti,

havi

változások

számítása

és

transzformálása

a

definiált

mutatószámok rendszere szerint.

4.5.2.

Érintett adatkörök

A felmérés során a LOGO-VIR környezetéből valamilyen módon integrálandó adatkörök a következő módon kerültek meghatározásra.


184


4.5.2.1. Adatkörök A rendszerek adattartalmának és a támogatott funkciók ismeretében a LOGO-VIR rendszer adatterületeit az alábbiakban felsorolt rendszerek moduljaiban található adatokból fog táplálkozni.


185

LOGO-VIR Rendszerterv Pécs MJV Önkormányzata - Kontrolling (vezetői információs) rendszer rendszerterve

4.5.2.2. LOGO A LOGO rendszer ismeretében például az alábbi táblázatokban, nézetekben lévő adatok rendszeres áttöltését vagy közvetlen használatát javasoljuk.

Adminisztrációs modul Az adminisztrációs modul a rendszer adminisztrálását végzi. Mivel a LOGO-VIR rendszer a LOGO rendszer részeként kerül kifejlesztésre, ezért jelen fejezetben nem a LOGO-VIR rendszer szempontjából érintett adatköreiről írunk, hanem a LOGO rendszer adminisztrálásában betöltött szerepéről. Az adminisztrációs modul három fő funkciója a következő: felhasználók felvitele, felhasználói jogok adminisztrálása nyilvántartások adminisztrálása riportok adminisztrálása A

LOGO-VIR

rendszer

keretében

is

a

fenti

funkciókat

fogja

ellátni

az

adminisztrációs modul.

Felhasználók felvitele, felhasználói jogok adminisztrálása A modul részeként lehet felhasználókat (jelszóval) rögzíteni a LOGO részeként telepített LDAP directoryba. A felvitel után a felhasználó a jogok megadása után azonnal használható, nincs szükség az adatok áttöltésére. Felhasználói jogok két módon adhatók egy felhasználónak. Lehetőség van egyes felhasználók számára egy rendszerelemhez jogot biztosítani, vagy pedig a felhasználók egy csoportjának is adható jog. Ez utóbbihoz a rendszer részeként kialakításra került egy hierarchikus, duplikálható szervezet modell. Ez egyrészt leképezi az Önkormányzat valós szervezeti hierarchiáját fastruktúrában, a leveleken felhasználókkal. E mellett azonban tetszőleges új csoport, vagy csoporthierarchia is kialakítható az Önkormányzaton belül vagy azon kívül. Utóbbi lehetőségnek a LOGO-VIR rendszerben is jelentősége van, így adható egyszerűen jog az egyes szervezetek felhasználóinak a rendszer bizonyos elemeinek elérésére. Ekkor ők az Önkormányzaton belül általánosan, mindenki számára Daten-Kontor Számítástechnikai Fejlesztő és Szolgáltató Kft. Telefon: 1/279-3400; 72/552-928 Fax: 1/365-2167; 72/256-070

186/193


elérhetőnek definiált elemeket sem látják, csak azokat a menüket, adatköröket érik el, ami az ő csoportjuknak ki lett osztva. Látszik, hogy a rendszerben abszolút preferált a jogok csoportra, szerepkörökre történő kiadása, pont a menedzselhetőség miatt.

Nyilvántartások adminisztrálása A

nyilvántartások

a

LOGO

rendszer

részeként,

annak

önálló

elemeként

működnek. Jelenleg nem tartalmaznak egyedi funkciókat az adatkarbantartás és a fájlcsatolás lehetőségén kívül. Alapvetően az Önkormányzatnál régebben Excelben vagy Access-ben tárolt adatokat tárolják ezekben a nyilvántartásokban. Az adminisztrációs felületén lehetőség van nyilvántartás létrehozására úgy, hogy az adatbázis táblát is létrehozzuk, valamint úgy is, hogy az adat először külső eszközzel be lett töltve az adatbázisba és a létrehozáskor csak ezt kell leképezni a LOGO rendszer számára. Első esetben értelemszerűen üres adattáblával nyílik meg a nyilvántartás, míg utóbbi esetben (többé-kevésbé) jól feltöltött adatokkal. A

nyilvántartás

karbantartó

ezután

elhelyezhető

a

menüben,

és

erre

a

menüpontra a felhasználói jogok adminisztrálásán keresztül jogot is lehet adni a kívánt csoportoknak, felhasználóknak.

Riportok adminisztrálása Riportokat a LOGO rendszerben mind a rendszer részeként átadott adattáblákra, mind a nyilvántartásokban tárolt adatokra lehet definiálni, sőt a kétféle adatkör vegyesen is felhasználható a riportokban. A

riport

adminisztrálás

során

a

riportot

egy

SQL

lekérdezéssel

lehet

meghatározni, ez biztosítja a fenti működést. A riportok alapfunkciói a következők: szűrés csoportosítás összegzés exportálás


187/193


Mindezeket a funkciókat Megadható

tehát,

definiálhatók

hogy

szűréri

szintén mely

minták,

az adminisztrálás során lehet

mezőkre

definiálni.

(akár lista alapján) lehet

csoportosítási

minták.

Továbbá

szűrni,

a fentiekhez

hasonlóan a riport elhelyezhető a menüben, és erre a menüpontra a felhasználói jogok adminisztrálásán keresztül jogot is lehet adni a kívánt csoportoknak, felhasználóknak.

Dokumentumtár A dokumentumtár a LOGO rendszer alaprendszere és mint ilyen, a LOGO-VIR rendszerben is használatos lesz, ezért jelen fejezetben nem a LOGO-VIR rendszer szempontjából érintett adatköreiről írunk, hanem a LOGO-VIR rendszerben betöltött szerepéről. A dokumentumtár API-n keresztül lehetővé teszi dokumentumok csatolását tetszőleges tábla tetszőleges sorához. Az API alapfunkciói a következők. dokumentum mentés dokumentum módosítása dokumentum lekérdezése dokumentum törlése Az

így

tárolt

dokumentumok

nem

az

adatbázisban,

hanem

fájlszervizen

tárolódnak, ahonnan a lekéréskor az alkalmazás hatékonyan, gyorsan elő tudja emelni a dokumentumot.

Általános nyilvántartó Az általános nyilvántartó modul tetszőleges, a LOGO rendszertervezés során nem definiált adatkörök egyszerű nyilvántartására szolgál. Egyszerű

nyilvántartás

alatt

értjük

az

olyan

egy

vagy

több

táblás

nyilvántartásokat, ahol egyedi funkciók használatára nincs szükség, és mint ilyenek,

a

LOGO

rendszer

bevezetése

előtt

xls

táblákban

vagy

Access

adatbázisokban vezették őket. Ezen nyilvántartások rendszerbe emelése több szempontból is hasznos:


188/193


egyszerűen riportolhatók a riport modullal egyszerűen publikálható a LOGO-WEB-en közös adatterületen tárolt, így automatikusan mentésre kerül, valamint bárki, aki jogosultsággal rendelkezik, hozzáférhet Ezek az adatok dinamikusak olyan értelemben, hogy az adatkörök is változhatnak az

Önkormányzat

igény

változásainak

megfelelően.

messzemenőkig támogatja, a nyilvántartások

Ezt

bővíthetők

a

rendszer

új mezőkkel, de

törölhetők is. A LOGO-VIR rendszer szempontjából ez azért érdekes, mivel az Adatkommunikációs interfész módosítható a rendszer használata során, így igény esetén ezek a változások a LOGO-VIR rendszerben is lekövethetőek. A jelenleg a nyilvántartásokban tárolt adatok a LOGO-VIR rendszerbe részben betölthetők részletesebb

lesznek,

részben

a

nyilvántartásokkal

LOGO-VIR

kiváltásra

keretében

kerülnek,

kialakított

így

azok

bővebb,

elemzésekre

felhasználhatóak lesznek.

4.5.2.3. Forrás SQL A megvalósítandó LOGO-VIR rendszer célkitűzéseinek megfelelő működéséhez szükséges adatok egy része a jelenleg működő Forrás-SQL integrált ügyviteli rendszerből származik. Ebből a rendszerből az önállóan és nem önállóan gazdálkodó költségvetési intézmények gazdálkodásával kapcsolatban nyerhetünk adatokat. A Forrásban az egyes intézmények a LOGO-VIR szempontjából releváns főkönyvi tételei technikailag elkülönülten, külön adatbázisokban találhatók meg, de a főkönyvi

könyvelés

logikája

megegyezik,

a

számlatükör

közös

az

egyes

intézményeknél. Közös törzsek (pecsktorzs) külön adatbázisokból nézeteken keresztül is elérhetőek. Mivel az egyes intézmények adatai külön adatbázisban vannak, így önkormányzat szintű legyűjtések végrehajtásához az összes adatbázist közvetlenül el kell érni, s azokból egyesével kell az adatokat kinyerni. Az adatbázisok a következők:


189/193


pecsapacza pecsegyeui pecsgaleri pecshiv pecshorvat pecsifju pecsigsz pecskultur pecsktorzs pecsmdrava pecspannon pecspszszt pecssport pecsszinfo pecsszinh pecstuzolt Az integráció során az alábbi táblákból történik adatáttöltés:

Tábla

Táblából kinyert releváns adattartalom

FOKONYV Főkönyvi adatok NAPLO

Pénzügyi év és főkönyvi időszak

ANAL

Analitikus kód - szakfeladatok

EGYCSOP Elszámolási egység csoport EGYSEG

Elszámolási egység

ROVAT

Pénzforrás kód (pecsigsz)

SZAKFEL

Szakfeladatok


190/193


SZAMLA

Főkönyvi számlaszámok

UGYLET

Ügylet kód (pecsapacza)

A főkönyvből (FOKONYV) gazdasági tranzakciók főkönyvi számlákon történő jelentkező egyenlegei a relevánsak, míg többi tábla a főkönyvi hivatkozások feloldásához

szükséges

törzs

jellegű

adatok.

Adatbeolvasások

valamennyi

intézmény adatbázis sémáját érintik, a két specialitást (IGSZ és ANK) külön jelöltük. A végleges integrációs logika a specifikációs fázisban véglegesítődik.

4.5.3. Az

Az adatkommunikáció módja

adatkommunikáció

gyakoriságtól információs

rendszeressége

függ,

amelyet

igények

jellege,

az

kizárólag

egyes

illetve

az

a

szükséges

adatkörökkel

adatfrissítési

kapcsolatos

adatszolgáltatói

oldalon

vezetői meglévő

képességek határoznak meg.

LOGO A LOGO adatai, mivel a LOGO adatbázisa egy adatbázisban van a LOGO-VIR rendszerrel, direkt elérhetőek. Ez esetben tulajdonképpen nem is beszélhetünk külső kommunikációról, az áttöltés gyakorisága sem értelmezhető.

Forrás SQL A Forrás SQL adatait a forrás rendszer lehető legkisebb terhelése mellett, annak megváltoztatása nélkül kell elérni. A Forrás SQL-ben jelenleg használt intézményi adatbázisokat a LOGO-VIR rendszer egy dedikált, csak olvasási joggal rendelkező adatbázis felhasználóval fogja elérni. A közös törzsadatokat a pecsktorzs adatbázisból,

míg

az

egyéb

tranzakciós

adatokat

az

egyes

intézményi

adatbázisokból egyesével fogja rendszer a LOGO-VIR MS-SQL adatbázisából a LOGO Oracle adatbázisába áttölteni. A főkönyvi feladás ciklusának megfelelően havonta célszerű adatokat áttölteni. Minden nap este 9 óra körül indul a szokásos mentési procedúra, amelynek


191/193


általában hajnali 3 óra körül van vége, így az ezt követő hajnali időszakra kell időzíteni az interfész futását.

5. Melléklet A melléklet tartalmazza a felmérés során lefolytatott interjúkról készült következő emlékeztetőket: Emlékeztető_LVM0001_2010_01_14.doc Emlékeztető_LVM0002_2010_01_15.doc Emlékeztető_LVM0003_2010_01_15.doc Emlékeztető_LVM0004_2010_01_20.doc Emlékeztető_LVM0005_2010_01_22.doc Emlékeztető_LVM0006_2010_01_25_v2.doc Emlékeztető_LVM0007_2010_01_26.doc Emlékeztető_LVM0008_2010_01_27_v2.doc Emlékeztető_LVM0009_2010_01_28.doc Emlékeztető_LVM0010_2010_01_29.doc Emlékeztető_LVM0011_2010_01_29.doc Emlékeztető_LVM0012_2010_01_29.doc Emlékeztető_LVM0013_2010_02_04.doc Emlékeztető_LVM0014_2010_02_10.doc Emlékeztető_LVM0015_2010_02_11.doc Emlékeztető_LVM0016_2010_02_15.doc Emlékeztető_LVM0017_2010_02_19.doc Emlékeztető_LVM0018_2010_02_22.doc Emlékeztető_LVM0019_2010_02_23.doc Emlékeztető_LVM0020_2010_02_23_v2.doc


192/193


Emlékeztető_LVM0021_2010_02_24_v2.doc


193/193

Pécs Megyei Jogú Város Önkormányzata. Kontrolling (vezetői információs) rendszer rendszerterve

Recommend Documents