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
Fejlesztői Szerver
Teszt és oktatói rendszer
Teszt szerver
Oktatási Szerver
Éles rendszer
Alkalmazás Szerver 1
„Concurrent Manager” Szerver
Alkalmazás Szerver 2
Real Application Cluster
Adatbázis Szerver 1. RAC node
Adatbázis Szerver 2. RAC node
Kisegítő szerverek
Storage
Load Balancer
5
Backup rendszer
Oracle Enterprise Manager 10g
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ó Kötelezettségek főkönyvi feladása
Csak pénzforgalmi Standard főkönyvi feladás csak a pénzforgalmi főkönyvbe ad fel a pénzforgalmi szemléletnek megfelelően (kifizetettek)
Üzemgazdasági és pénzforgalmi 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
Üzemgazdasági és pénzforgalmi főkönyv együttes vezetésének előnyei • Előnyök – 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
