Budapesti Műszaki és Gazdaságtudományi Egyetem, BME
A BME ORACLE-alapú gazdálkodási rendszere R12 upgrade egyetemi környezetben Dr. Remzső Tibor Igazgató 2014
A szerződés története (2010-ig) 2007. február Közbeszerzési pályázat kiírása 2007. július Szerződéskötés a nyertes Synergon Nyrt-vel 2008. február A helyzetfelmérés lezárása 2008. november A rendszertervezés lezárása, az éles indulás kereteire vonatkozó megoldások keresése 2009. március Megállapodás a 2010. január 1-i éles indulásról 2010. január A tervek szerinti éles indulás 3
Az MGR alrendszerei, és egyéb kapcsolódó rendszerek ORACLE EBS integrált gazdaságirányítási alkalmazás nexonbér bérügyviteli szoftver NEPTUN egységes tanulmányi rendszer Poszeidon Ügyviteli és Iktatási Rendszer VIR Vezetői Információs Rendszer 4
Az MGR hardver szerkezete IGIR - ERP rendszer Virtualizált szerver park Fejlesztői rendszer Teszt és oktatói rendszer Éles rendszer Fejlesztői Szerver Teszt szerver Oktatási Szerver Alkalmazás Szerver 1 Alkalmazás Szerver 2 Concurrent Manager Szerver Real Application Cluster Adatbázis Szerver 1. RAC node Adatbázis Szerver 2. RAC node Kisegítő szerverek Storage Load Balancer Backup rendszer Oracle Enterprise Manager 10g 5
Az MGR rendszer méretezése Éles rendszer Éles rendszer - adatbázis szerverenként 2*3GHz Intel vagy AMD processzor (2 magos processzor), 5 GB RAM, 20 GB Belső háttértárterület az operációs rendszer számára, Éles rendszer - alkalmazás szerverek 2*3GHz Intel vagy AMD processzor (2 magos processzor), 6 GB RAM, 20 GB Belső háttértárterület az operációs rendszer számára, Éles rendszer Concurrent Manager szerver 2*3GHz Intel vagy AMD processzor (2 magos processzor), 5 GB RAM, 20 GB Belső háttértárterület az operációs rendszer számára, 6
Az MGR rendszer méretezése egyéb rendszerek Fejlesztői szerver 10 egyidejű felhasználóra méretezve Teszt szerver 20 konkurens tesztelőre méretezve Oktatási szerver 30 egyidejűleg oktatott személyre tervezve A szerverek virtualizációval kerültek kialakítáásra, a host szerver mértezése: 2*3 GHz Intel vagy AMD alapú processzor (2 mag) 8 GByte RAM 20 Gbyte belső tár az operációs rendszer számára 7
Az MGR rendszer méretezése Backup, Storage Backup szerver Napi 50-100 GByte mennyiségű adat biztonságos mentése ORACLE Enterprise Management Server 2GHz Intel vagy AMD processzor (2 magos) 15 Gbyte belső háttértár az operációs rendszer számára Storage kapacitás 600 Gbyte tárterület induláskor 300 Gbyte évenkénti tervezett növekmény Teljesítmény elosztó Load Balancer 8
Korán felmerülő igény az R12 használata Kettős szemléletű gondolkodás Realizációs elv Összemérés elve Időbeli elhatárolás elve Elsődleges feladat biztonságos pénzforgalmi szemléletű főkönyv kialakítása Ezzel egy időben az üzemgazdasági szemlélet megvalósításának elkezdése Az ORACLE R12 verzió használata 9
Az R12 átállás kezdetei Külön ágon, mindkét szemléletben könyvel A korai döntés eredményeképpen már a rendszertervezés időszakában meg kellett/lehetett változtatni az eljárásokat A már rögzített adatokkal indultunk, ezek szolgálhattak az üzemgazdasági szemlélet alapjául is (csak más kontír szabályokkal) Az üzemgazdasági könyveléshez viszonylag kevés gazdsasági esemény esetében kellett a pénzforgalmihoz képest plusz analitikus könyvelés 10
Pénzforgalmi vs Pénzforgalmi és Üzemgazdasági Főkönyv Készült egy összehasonlító táblázat a BME-nél bevezetendő modulokkal kapcsolatban, hogy a funkciók mennyiben térnek el egymástól egy csak pénzforgalmi főkönyv alapú és egy elsődleges üzemgazdasági főkönyv és másodlagos pénzforgalmi főkönyv esetben. (Néhány példa) Funkció Csak pénzforgalmi Üzemgazdasági és pénzforgalmi Kötelezettségek főkönyvi feladása Standard főkönyvi feladás csak a pénzforgalmi főkönyvbe ad fel a pénzforgalmi szemléletnek megfelelően (kifizetettek) Standard, a kötelezettség modul főkönyvi feladása mindkét főkönyvbe felad, két különböző szemléletben. A számla kontírsorában a kiadásnak megfelelő főkönyvi számlának kell szerepelnie (tárgyi eszköz, készlet kapcsolat miatt). Az üzemgazdasági főkönyvben a számla, a pénzforgalmi főkönyvben a kifizetés kerül könyvelésre. Kintlévőségek főkönyvi feladása Standard főkönyvi feladás csak a pénzforgalmi főkönyvbe ad fel a pénzforgalmi szemléletnek megfelelően (befolyt bevételek) Standard, a kintlévőség modul főkönyvi feladása csak az üzemgazdasági főkönyvbe. A pénzforgalmi főkönyvbe párhuzamos feldolgozás indításával kerülnek át a pénzforgalmi adatok (standard feldolgozás, automatizálható). Az üzemgazdasági főkönyvben a számla, a pénzforgalmi főkönyvben a befolyt bevétel kerül könyvelésre. 11
Előnyök Üzemgazdasági és pénzforgalmi főkönyv együttes vezetésének előnyei A szabályozási környezet változása esetén amennyiben a módosított teljesítményszemléletű könyvvezetés helyére a költségvetési szervek részére is az üzemgazdasági könyvvezetést írják elő a rendszer igazítása, a jogszabályok követése lényegesen egyszerűbb lehet. 12
Üzemgazdasági és pénzforgalmi főkönyv együttes vezetésének kockázatai, hátrányai A rendszertervezés időszakában nem volt ismert a költségvetési szervek üzemgazdasági szemléletű könyvvezetésére vonatkozó szabályozástervezet. Az Oracle Kormányzati megoldásában az elsődleges főkönyv az üzemgazdasági (nem megváltoztatható), erre a főkönyvre koncentrálódnak elsősorban a tranzakciós rendszerek is (tárgyi eszköz, készlet, kötelezettség, kintlévőség, stb). A pénzforgalmi főkönyv tranzakciók, vagy főkönyvi naplók transzferálásával jön létre, amit legalább naponta ellenőrizni kell mindaddig, amíg a pénzforgalmi főkönyv vezetését el nem törlik. A BME számára ez plusz feladatot jelent nap mint nap - még akkor is, ha informatikailag maximálisan támogatjuk az ellenőrzést. Nem volt lehetséges úgy bevezetni a BME rendszerét, hogy az itt dolgozók ne szembesüljenek valamilyen szinten az üzemgazdasági főkönyvvel. Az üzemgazdasági könyvelésnek a költségvetési szervek körében akkoriban nem volt kultúrája. Speciális BME kockázat: a standard ORACLE rendszerben sok változtatásra volt szükség, amelyeket mindkét főkönyvhöz illeszteni kellett az idők folyamán, az átvett rendszerek tesztelése dupla ráfordítást igényelt 13
Az MGR rendszer fő moduljai Jogosultságkezelési rendszer Adatbiztonsági rendszer kezelése Törzsadat kezelő rendszer Költségtervezés, keret- és kötelezettségvállalás nyilvántartás Főkönyv Szállító Vevő ÁFA analitika Pénztár Beszerzés Készletgazdálkodás Vevői rendelés-nyilvántartás Befektetett eszközök gazdálkodása Létesítménygazdálkodás Pályázat- és projektkezelés Hallgatói alrendszer Interfészek más kapcsolódó rendszerekkel (Nexon, Neptun, KIR, Poszeidon) A gazdálkodás teljes területét lefedi a rendszer 14
Elmaradt fejlesztések, nehézségek 2011-2014 VIR2 fejlesztés Helyette Saját Kimutatás Készítő A Fővállalkozó alvállalkozói struktúrájának változásai komoly csúszások a projektben 2011-2012-ben Új alvállalkozó belépése, a fejlesztések gyorsulása (2013) A jogszabályi környezet lényeges megváltozása KIR rendszer belépése 2013 elején, a NEXON alapú eljárások alapvető átalakítása NEPTUN rendszer változásai A számviteli szabályok 2014-es gyökeres megváltoztatása 15
A 2014-es számviteli változások hatásai a rendszer befejezésére A költségvetési szervek által eddig alkalmazott módosított pénzforgalmi szemléletű könyvvezetést kötelezően felváltja egy más alapú költségvetési/pénzforgalmi szemléletű számvitel, és ezt kiegészítve a pénzügyi/eredmény szemléletű számvitel 1988 óta a legnagyobb méretű átszervezés a költségvetési szervek könyvelési rendszerének tekintetében A korábbi fejlesztési döntés (R12-re átállás) igazolása: Az MGR rendszerrel eleget tudunk tenni mindkét szemléletű számvitel szerinti könyvvezetési és beszámolási kötelezettségnek, természetesen az egyéb jogszabályi változásokkal összefüggő feladatok elvégzését követően. Ilyen jogszabályi változásból nagyon sok van, ezeket jelentős fejlesztésekkel tudjuk megvalósítani. 16
Néhány jelentős változás a számvitelben (nem teljes felsorolás L ) A gazdasági események könyvelése az egységes rovatrendnek megfelelően történik. A kincstári kapcsolatokban a KTK kódokat az ún. egységes rovatrend azonosító (ERA) váltja fel. Ezek új kapcsolati rutinokat jelentenek a kincstári kapcsolatban, új nyomtatványokat utalások, kötelezettségvállalások esetén, stb. Követelmény, hogy minden kiadást megelőzően történjen meg a kötelezettségvállalás nyilvántartásba vétele, bevételeknél pedig a követelésé. A Magyar Államkincstár banki interfésze jelentősen változott, a MÁK szabad keretek figyelése rovatkód mélységben kell történjen. A kormányzati funkciók szerinti mérésekben a COFOG (Classification of Functions of Government) szabványt kell alkalmazni, a kiadásokat és bevételeket ennek megfelelően is ki kell tudnunk mutatni Ezen változások következménye: a rendszerünkben rögzíthető okmányokon, bizonylatokon, kimutatásokon, lekérdezéseken az összes változtatást át kell vezetnünk, új kimutatásokat, lekérdezéseket kell elkészítenünk: PLUSZ IDŐ, PLUSZ KÖLTSÉG, PLUSZ MUNKAERŐRÁFORDÍTÁS 17
Köszönöm a figyelmet! Budapest University of Technology and Economics, BME www.bme.hu