Hírlevél - 2024 február

Tartalom

1. SaaS szolgáltatás szerver kapacitás bővítés
2. MegApex új 24 típusjelű változat
3. NAV XML számlák automatikus könyvelése 2.0.
4. Bér (HR) új fejlesztések
5. Főkönyv, pénzügy új fejlesztések

1. Saas szolgáltatás szerver kapacitás bővítés

Idézet a 2023. februári Hírlevélből: "....A SaaS szolgáltató szerverünket már több, mint 12 éve helyeztük üzembe. Eddig jól teljesített, csak egyszer kellett részleges tároló csere. Napközben 110 – 130 munkaállomással dolgoznak. (Lásd napközben: https://megaora.hu:8443/apex/f?p=210:7:::::: ) A fizikai kopás is napról napra növeli a meghibásodás kockázatát. Ez már önmagában indokolja új gép beállításának igényét. Elindítottuk az új, gyorsabb, nagyobb szerverek beszerzését..."

Örömmel tudjuk jelenteni a Felhasználóinknak, hogy a többször nagyobb kapacitású szerver beszerzése és üzembe állítása sikeresen megtörtént. Ezzel egyidőben, (bár ez a Felhasználókat nem nagyon érdekli, de fontos, hogy) az Oracle tíz évvel korábbi verziót is lecserélte rendszergazda munkatársunk, a legújabb Oracle verzióra. Ez a működés, szolgáltatás biztonságát erősíti.

A rendszer leállások, lista „bedugulások” száma is jelentősen csökkent. A MegApex listázásnak, a húsz évvel korszerűbb fejlesztő eszköz jóvoltából, sokkal kevesebb erőforrást igényel, mint a MegaORA programok. A MegaORA az ezred forduló idején az akkor még legkorszerűbb eszközzel készült. De az Oracle által már húsz éve (tovább) nem fejlesztett eszközök lassan elavultak. Az egyik fő probléma, hogy a MegaORA programok listázó megoldása „hajlamos a bedugulásra”, amikor több tucat kezelő valamelyike, esetleg többször is, nagy oldalszámú listát indít. A MegApex listázó működése minden kezelő feldolgozásában önálló életet él, más kezelők listázási feladatai, esetleges problémái, nem befolyásolják a működést. Ezért a további javulás attól várható, ha a felhasználók többsége, sőt mind, áttérnek a MegApex programok használtára.  

2. MegApex új 24 típusjelű változat

Mind az operációs rendszerek (Windows), adatbázis kezelő (Oracle), mind a fejlesztő eszközök (Apex) folyamatosan, évenként új és új változatokat bocsájtanak ki. Így a NAV, a kötelező adatszolgáltatásokhoz, a legkorszerűbb programok használatát igényli. Bár a korábbi változatok – egy ideig – használhatók, de idővel muszáj követni a változásokat. Például a NAV az online számla jelentéshez a Java fejlesztő eszköz legújabb verzióját használja, amely nem volt része az általunk használt Oracle 11. verziónak. Félő volt, hogy nem tudjuk elkészíteni, illetve követni a NAV online számla készítés előírásait. A NAV XML képzés létrehozása nagyon nagy munkával történt. Az új Oracle verzió tartalmaz olyan segédeszközt, amivel ezek a programozási feladatok negyed – tized idő alatt megoldhatók.

Ez a verzió követési kényszer a már több éve használt fejlesztő eszközt, az Apex-et is elérte. Közel egy éve az ügyviteli szempontból új és bővebb fejlesztést, a MegApex 2.0, készítése közben kijött új és sok tekintetben hatékony eszköz megoldásait alkalmazzuk-e? Mi fontosabb, a felhasználóknál a látszólagos változatlanság, vagy a hatékonyabb fejlesztési és program működési lehetőség. A kérdés eldöntésében szerepet játszott, hogy az új MegApex rendszert csak néhányan, a felhasználók kevesebb mint 10 százaléka, vette használatba. (Igen! Tudjuk, a másféle kezelés megtanulása munkaigényes!)

Az a döntés született, hogy az Apex eszköz jobb és hatékonyabb lehetőségeit hasznosítva, külsőjében is új, de működésében azonos - MegaORA azonos feladatai, adati szerint azonos - új rendszert készítünk. Ennek a megnevezése - MegApex 24.

A szerver és Oracle adatbázis csere után a befejező lépés, átállás a MegApex új programokra. Jelenleg a SaaS szolgáltatásban még a MegApex 1.0. változat működik.

Várhatóan a közeli hetekben kiadásra kerül az új MegApex 24. változat. Erről, az átálláshoz szükséges leállásról, a Felhasználókat értesítjük.

3. NAV XML számlák automatikus könyvelése 2.0.

Elkészült a NAV számlák automatikus könyvelési lehetőségének 2.0. verziója. Ez az új fejlesztés az 1.0. verzió lehetőségeit megtartva készült el. Az 1.0. verzió mind a MegaORA, mind a MegApex változattal működik. Az új 2.0. változat csak a MegApex 24. verzió része, azzal a változattal kerül kiadásra.

Az 1.0. verzióról a Megastar Hírlevelekben több folytatásban volt leírás és a működő programokban dokumentáció és két éve már használható. Napjainkban 30 – 40 könyvelő rendszeresen használja. A SaaS szolgáltatásban februárig több mint 120 ezer (!) ilyen könyvelési tételt képeztek a felhasználók. Ebből több mint 8 ezer könyvelési tétel, ún. „bemódosított” készpénzes tétel volt. (Erről részletesen később.) Elmondhatjuk, hogy az 1.0. verzió lehetőségeit a könyvelők előszeretettel használják, mert már ez is jobb, hatékonyabb munkavégzést biztosít.

Az új 2.0.-ás verzió az 1.0. verzió lehetőségeire épült, tovább fejlesztett, több lehetőséget biztosít, és a két változat kombináltan is használható. Az 1.0. verzió egyes lépései – letöltés, kontírozás, könyvelés – kezelő által indított menü lépésekkel történik, Ezzel szemben a 2.0. változat, egy paraméter sorozattal vezérelve, az összes lépést automatikus gépi futással végzi, mégpedig éjszaka, az előző (egy) napon beküldött Bejövő/Kimenő számlákkal.

Ha egy cég feldolgozásában érvényesen ki van töltve az ezt vezérlő paraméter, akkor éjfél után egy automatikusan induló eljárás, a paraméter szerinti feladatokat végzi el az alábbi lehetőségekkel:

Letöltés        Minden / Csak bejövő számlák / Csak kimenő számlák / Nem kell letöltés

Kontírozás   Minden / Csak bejövő számlák / Csak kimenő számlák / Nem kell kontírozás

F.biz.képzés Minden / Csak bejövő számlák / Csak kimenő számlák / Nem kell tét.képzés

Könyvelés    Minden / Csak bejövő számlák / Csak kimenő számlák / Nem kell iktatás

 Amint látható, az igények szerint hangolható az Automatikus működés! Alapeset, hogy mindegyik pararaméter „Minden” beállításon áll. A paraméternek megfelelő működésről, éjfél utáni folyamatról, letöltésről, képzésekről lista készül, amely lista tartalmazza a történések, hibák, javítási igények jegyzékét.

Miért szükséges a lépésenkénti beállítás lehetősége? A kezelő saját igénye szerint, átlátható munkavégzést alakíthat ki. Például javasolt, hogy kezdetben ne fusson végig az automatizmus, az iktatásnál álljon meg a folyamat. (Könyvelés: „N” – nem). A kezelő ellenőrizze a képzett könyvelési tételeket, esetleg javítson, átkontírozzon, majd a jónak minősített tételekkel indítsa el a forgalmi terület iktatását. Vagy lehet egy másik működési séma, amikor csak a letöltés történik naponta éjszaka, (amikor a NAV szerver terhelése kisebb). A többi lépést, a saját gépen, esetleg több nap adataival összevontan végezheti a kontírozást, tétel képzést és így ellenőrzött, javított adatokkal indíthatja az iktatást a kezelő.

A valóságban számos olyan fejlemény történhet, ami az automatikus lépésekben zavart okoz. Például a NAV szerver napközben, néha akadozva tölt le számlákat, vagy kimaradnak számlák vagy a saját gép hibásodik meg, vagy a kezelő szabadságra megy / beteg lesz stb. Ilyenkor rendelkezésre áll az 1.0. verzióban már működő, használt lehetőség, „letöltés Dátum -TOL, -IG” szerint, majd ellenőrizhetők a tételek. A programok mind a letöltést, mind az iktatást - könyvelést ellenőrzik, egy adott tétel nem tölthető le, nem iktatható - könyvelhető kétszer.

Amint a korábbi ismertetőkben és a dokumentációban látható, a gépi kontírozás valószínűségi alapon történik. Lehetséges, hogy a kezelő számára a kontírozás nem megfelelő. Hiszen a kezelő a gazdasági eseményről és az azt kódoló kontírozásról olyan információkat is tudhat, amely nincs a programban. Ilyen esetben a kezelő dönthet úgy, hogy a tételt átkontírozza. Alap esetben a kontírozás módosítása történhet tétel soronként kézi javítással. Azonban a 2.0. programban van jóval hatékonyabb lehetőség is, amikor a kezelő a már rendelkezésre álló kontír változatokból kiválaszthat másik kontírozást és egy gombnyomással átállítja a tételt. Az ilyen változtatást a program megjegyzi és a következő ilyen számlánál már az új kontír változattal képződik a tétel. (Önjavító mechanizmus!)

A már említett „Készpénzes számlák” megoldása. (A készpénzes számlákat lehet egyetlen Pénztári bevétellel/kiadással könyvelni, nem keletkezik Folyószámla, és az Áfa jelentésben a számla szerepel.) Míg az 1.0. verzióban a kezelők ezrével átalakították a képződött könyvelési tételeket, az új változat ezt a lehetőséget automatikusan kezeli. A gond az, hogy bár az XML tartalmaz a Fizetési módra információt, „CASH” készpénzes a számla, de ezt a beküldött XML adatokba az egyes számla készítők nem töltik ki. (Mert nem kötelező adat.) Viszont a korábban említett Önjavító mechanizmus idővel érzékeli ezt a kontírozási változatot, ha van jelzés az XML-ben, ha nincs. Első esetben, ha készpénzes számla 100 / 200 (bejövő/kimenő) naplóra készül, akkor az átkontírozási lépéssel „jó útra terelhető”, áttehető 300/400-as (Bank/Pénztár) naplóra. Majd a következőkben a program automatikus kontírozása követi a kezelő által megadott sémát.

A Megastar könyvelő program számos, tétel soronkénti „Automatizmus” lehetőségét tartalmaz, amelyek a kézi adatbeviteli munkát megkönnyítik. Például a Pénzforgalmi Áfa, a Fordított Áfa, Skontó képzés, Aktív – Passzív időben elhatárolás, 5-ös számlához 6/7 számla képzése stb. Ezek közös jellemzője, hogy a kézi bevitel bizonyos pontján a program (valamely beállítás hatására) automatikusan könyvelési tételsorokat képez. A képzett sorok tartalmát esetenként bonyolult számításokkal kell előállítani. A program így megkíméli a kezelőt a számításoktól és a sorok billentyűvel történő bevitelétől. Kérdés, ezek a soronkénti automatikus lehetőségek hogyan működnek a NAV XML számlák képzésénél? A működés alapelve az, hogy a NAV XML könyvelési tételképzés, mint a kézi bevitelnél, úgy történik. Majd a további sorok képzését a soronkénti automatizmusok hozzák létre. Tehát a kezelőt kímélő soronkénti automatizmusok a gépi könyvelési tétel képzésnél teljes értékűen segítik a kezelőt.

A Megastar a NAV XML számlák automatikus könyvelés képzés lehetőséget – külön díjazás nélkül – a MegApex 24. program változat részeként biztosítja a Felhasználóknak.

4. Bér (HR) új fejlesztések

Az elmúlt években jelentősen megváltozott a munka világa, amely részben a technológia fejlődés részben a világjárvány egymást is befolyásoló kihívásaira adott válaszként lett szükségszerű.

A programunkkal az otthoni munkavégzés nem ütközött akadályokba, hiszen a felhő alapú rendszer bárhol elérhető internet segítségével. A változó gazdasági környezet a kormányzati illetve hivatali adatszolgáltatásokban is jelen van. Fontos változás, illetve fejlesztés az EPELL adatszolgáltatás, amely a társadalombiztosítási kifizetőhelyek számára kötelező, minden táppénz illetve anyasági ellátással kapcsolatos kifizetésre vonatkozik.

A felhasználóink a nagyobb átláthatóság, és gyorsabb adatfeldolgozás igényével fordultak hozzánk. Az egyik partnerünknél jelenlét rögzítésével kapcsolatos adatátadás feleslegessé tette a távollétek kézi rögzítését így jelentős időt takaríthatnak meg és a hibalehetőség is kisebb. Egyébként bármelyik már meglévő időadat, jelenlét vagy kártyás beléptető rendszerből tudunk adatátadást kiépíteni az ügyfél igényeinek megfelelően. A számfejtés előkészítő lépései a Felhasználók által megfogalmazott igények alapján mindenhol a saját problémák megoldását segítik.

Az új fejlesztések közé tartozik a munkavállalókhoz szorosan köthető munkaalkalmassági vizsgálat, valamint a munkavállaló részére átadott eszközök (szerszámok, telefon, laptop), munkaruhák dátummal ellátott rögzítésének lehetősége, amelyekről riport is készíthető, így könnyebb figyelni az orvosi vizsgálat idejét és pl. a munkaruha kihordási időt, valamint a munkavállaló kilépésekor is egy helyen megtalálható azon eszközök listája, amivel el kell számolni.

A munkaügyi dokumentumok - melyek lehetnek szerződések, tájékoztatók - elkészítésére is van új lehetőség a MegApex rendszerben. Ezek akár a már meglévő Word formátum bemásolásával, akár újak létrehozásával is készíthetők úgy, hogy a dolgozó kívánt adatai a személyi és jogviszony adatok közül kerülnek rá a nyomtatványra.

Egyedi fejlesztési igényként oldjuk meg azokat a kéréseket is, amelyek a főkönyvi könyvelés további dimenzióit szolgálják ki. Konkrétan: ha a főkönyvben a költségeket el kell különíteni költséghelyre, munkaszámra, projektekre, stb., akkor a bérfeladás előkészítési fázisában minden erre igényt tartó felhasználónak az általa megfogalmazott kritériumok alapján egyedi előkészítés zajlik.

5. Főkönyv, pénzügy új fejlesztések

Aktív és passzív időbeli elhatárolás

Az egyik ügyfelünk jelezte, hogy nagy számossággal fordulnak elő több évet érintő gazdasági eseményekről szóló számlák. Ennek a problémának figyelése, mind a tárgyévben, mind a következő években igen munkaigényes, ezért igényelte, hogy gépi automatizmus segítse a könyvelők munkáját.

A kiinduló számlán lévő -TOL -IG dátumok meghatározzák az összes napok számát, amely a számla teljes összegére vonatkozik. Az év kezdet (január 1.) vagy év vége (december 31.) szakaszolja, hogy a számlán szerepelő összeg a napok arányában számítható, könyvelhető.

Első közelítésben a tárgyévet csak a dátumok által meghatározott napok számával arányosan szabad terhelni. A tárgy éven túl történő teljesítést egy ún. Elhatárolási számlára kell könyvelni. Ha ez az Elhatárolási számla (Megastar program kategóriák szerint) egy ún. „Analitikus számla”, akkor az erre a számlára könyvelt tételek az éves zárás – nyitás folyamán a következő évben vagy években tételesen is hozzáférhetők. (Ha nem Analitikus típusú az Elhatárolási számla, akkor az éves zárási – nyitási eljárás összevonja a tételeket és csak az egyenleg, mint nyitó kerül a következő évben könyvelésre.) Analitikus típusnál mód van, mint a pénzügyi teljesítések rendezettségének figyelését, akképpen figyelni, hogy egy - egy időszakban mely teljesítéseket kell az Elhatárolási számlákról átvezetni a tárgyidőszak (bevétel vagy költség) számláira.

A leírt mechanizmus az Elhatárolási számlák megadásával indul be, ha a számlán lévő vonatkozási időszak -TOL és -IG a tárgy éven túl terjed.

Pénztár napló használata Egyszeres könyvelésnél

Az Egyszeres könyvelés (pl. Naplófőkönyv) könyvelése az ún. Esemény kódokkal történik, mikoris a gazdasági eseményekhez kódokat rendelnek és az Esemény kódhoz megadhatók Tartozik – Követel számlák, Áfa kódok.
A kód és összeg megadással történik a könyvelési tétel képzése. Egyszerű és gyors mechanizmus, hátránya, hogy csak egyszerű kontírozású események könyvelhetők.

Az ilyen típusú könyvelésnek nem része a kettős könyvelés ún. Házipénztár modul használata. Még akkor sem, ha csak egyszerű gazdasági esemény, pénz befizetése, befizetési dokumentum kinyomtatása szükséges. A Házipénztár forgalombevitelt, a kontírozást az ún. Jogcímkód törzsadat vezérli, ahol egy kód megadásával lehet a kontírozást, Áfa számítást programmal automatikusan képezni.

Tehát az Egyszeres könyvelésnél használt Eseménykód és kettős könyvelés Házipénztár modul adat bevitelét a Jogcímkód hasonló mechanizmussal vezérli.

Ezek a megfontolások akkor kerültek előtérbe, amikor egy könyvelő iroda ügyfele, kihasználva, hogy a Megastar SaaS szolgáltatását, rendezvényre kihelyezett munkaállomással (laptop, nyomtató) Házipénztári befizetést és bizonylat kiíratást akar végezni. Mindezt Egyszeres könyvelést végző ügyfélnél. Miért? Mert a rendezvényen a befizetés és a kiíratható befizetés igazolása, mintegy részvételi igazolás dokumentum használható. Az eseményre kihelyezhető munkaállomások és a helyszíni munkavégzés igényét a nagy számosságú befizetés indokolja. Ügyviteli szempontból, a pénztári befizetés ily módon közvetlen könyvelhető tételeket eredményez.

A könyvelő iroda ügyfelének igényére olyan program módosítást végeztünk, hogy a Házipénztári működés lehetséges Egyszeres könyvelési feldolgozásban. Az ilyen környezetben a Házipénztári tételeknél, ha a Jogcímkód megegyezik valamely Esemény kóddal, akkor a könyvelési feladás automatikusan az Esemény kód kontírozása szerint történik. Ha nincs egyezés, akkor a kezelő a tétebe beviheti a szükséges Esemény kódot. Ily módon a Házipénztári befizetés, bizonylat nyomtatás használható Egyszeres könyvelési, kihelyezett gépi környezetben.