VIKI Könyvelő Asszisztens RLB és ÁNYK integráció – beállítás, használat, hibák és megoldások
VIKI Könyvelő Asszisztens RLB és ÁNYK integráció – beállítás, használat, hibák és megoldások
Egy könyvelőirodában önmagában az, hogy az RLB, az ÁNYK és a VIKI külön-külön megfelelően működik, még nem jelenti azt, hogy a teljes folyamat megfelelően működik.
A problémák jelentős része éppen az alkalmazások közötti kapcsolatoknál jelenik meg.
Az RLB-ben rendelkezésre állnak a könyvelési adatok.
Az ÁNYK-ban elkészülnek és beküldésre kerülnek a bevallások.
A VIKI pedig ezekből az információkból automatizált folyamatokat, kimutatásokat és ügyféltájékoztatást tud kialakítani.
Ehhez azonban a három rendszer közötti kapcsolatot megfelelően kell felépíteni.
Különösen igaz ez olyan könyvelőirodai környezetben, ahol:
- több könyvelő dolgozik ugyanazon a rendszeren;
- terminálszervert használnak;
- felhasználónként külön ÁNYK-adatkönyvtár található;
- közös RLB-adatbázist használnak;
- több VIKI klienspéldány működik;
- vagy az alkalmazások hálózati megosztásokról érik el az adatokat.
Egy hibás útvonal, jogosultság vagy rosszul kialakított szinkronizáció eredménye sokszor nem látványos rendszerhiba.
A VIKI egyszerűen nem kapja meg azt az adatot, amelyre szüksége lenne.
Ebben a cikkben ezért nemcsak azt nézzük meg, hogy mire használható a VIKI Könyvelő Asszisztens, hanem azt is, hogyan kapcsolódik az RLB-hez és az ÁNYK-hoz, hogyan érdemes kialakítani a környezetet, és hol érdemes keresni a hibát, ha a szinkronizáció nem megfelelő.
Mi a VIKI Könyvelő Asszisztens?
A VIKI Könyvelő Asszisztens alapvetően a könyvelőirodai munkafolyamatok automatizálását és az adminisztráció csökkentését segítő rendszer.
A működésének egyik legfontosabb eleme, hogy képes kapcsolatot teremteni a könyvelőirodában már használt rendszerekkel.
Ilyen lehet például:
- az RLB könyvelőprogram;
- az ÁNYK;
- valamint a VIKI saját szolgáltatásai és adatfeldolgozási folyamatai.
A rendszer többek között használható:
- fizetendő adók kezelésére és kiküldésére;
- bevallások állapotának követésére;
- könyvelési eredmények megjelenítésére;
- pénztáregyenlegek kezelésére;
- tagi kölcsön egyenlegek megjelenítésére;
- vevő- és szállítóegyenlegek összesítésére;
- könyvelési tételszámok kezelésére;
- feladatkezelésre;
- valamint automatizált ügyfélkommunikációra.
A lényeg azonban nem az, hogy még egy alkalmazás kerüljön a könyvelő számítógépére.
A VIKI valódi értéke az integráció és az automatizálható adatáramlás.
Ha az RLB, az ÁNYK és a VIKI megfelelően kapcsolódik egymáshoz, számos olyan információ feldolgozása automatizálható, amelyet egyébként manuálisan kellene kezelni.
Hogyan épül fel a VIKI kapcsolata a könyvelőirodai rendszerrel?
Technikai szempontból fontos megérteni, hogy a VIKI működéséhez helyi komponensek is tartoznak.
Egyszerűsítve az RLB oldaláról az adat útja így képzelhető el:
RLB → VIKI kliens → helyi MySQL-adatbázis → VIKI rendszer
Az ÁNYK oldaláról pedig:
ÁNYK adatkönyvtár → VIKI kliens → VIKI rendszer
A VIKI kliensnek ezért olyan környezetben kell működnie, ahonnan eléri azokat az adatforrásokat, amelyekből dolgoznia kell.
Ilyen lehet:
- az RLB;
- az RLB adatállománya;
- az ÁNYK küldendő állományai;
- az ÁNYK elküldött állományai;
- valamint a VIKI működéséhez szükséges helyi adatbázis.
Ez a hibakeresés szempontjából rendkívül fontos.
Ha egy információ nem jelenik meg a VIKI-ben, nem feltétlenül maga a VIKI a hibás.
Az adat teljes útját végig kell követni.
VIKI és RLB összekötése
Az RLB és a VIKI kapcsolatánál az egyik első kérdés mindig az, hogy a VIKI kliens valóban azt az RLB-környezetet éri-e el, amelyben a könyvelés történik.
Egyetlen munkaállomás esetén ez viszonylag egyszerű.
Egy többfelhasználós könyvelőirodában azonban már egészen más infrastruktúrával találkozhatunk.
Például:
RLB → központi szerver → terminálszerver → könyvelők → VIKI
Ilyenkor pontosan ismerni kell:
- az RLB telepítési helyét;
- az RLB által használt adatállományok helyét;
- a hálózati elérési útvonalakat;
- a VIKI kliens konfigurációját;
- a Windows-felhasználók jogosultságait;
- a VIKI által használt adatbázist;
- valamint azt, hogy melyik komponens melyik felhasználói környezetben fut.
Ez különösen fontos akkor, ha korábban szervercsere, migráció vagy infrastruktúra-átalakítás történt.
Egy régi útvonal ugyanis megmaradhat valamelyik konfigurációban úgy, hogy közben maga az alkalmazás látszólag megfelelően működik.
A könyvelőprogramok szerveres működésével részletesebben a RLB-60, Cashbook, Novitax és VIKI Könyvelő Asszisztens – könyvelőirodai szoftverek telepítése, költöztetése és üzemeltetése témakörében is foglalkozunk.
VIKI és ÁNYK – miért különösen fontos az adatkönyvtár?
Az ÁNYK-integráció többfelhasználós könyvelőirodai környezetben külön figyelmet igényel.
Ennek oka, hogy az ÁNYK által használt adatkönyvtár nem feltétlenül közös minden felhasználónál.
Terminálszerveren például kialakulhat egy ilyen struktúra:
Könyvelő A → saját ÁNYK adatkönyvtár
Könyvelő B → saját ÁNYK adatkönyvtár
Könyvelő C → saját ÁNYK adatkönyvtár
Miközben mindhárom felhasználó ugyanazon a terminálszerveren dolgozik, és ugyanazt a központi RLB-környezetet használja.
Ez nagyon fontos különbség.
A VIKI kliensnek azt az ÁNYK-adatkönyvtárat kell elérnie, amelyben az adott felhasználó tényleges ÁNYK-állományai találhatók.
Ha rossz útvonal szerepel a konfigurációban, előfordulhat, hogy:
- az RLB-adatok megfelelően megjelennek;
- bizonyos szinkronizációs folyamatok működnek;
- az ÁNYK-hoz kapcsolódó információk azonban hiányoznak;
- vagy csak egyes felhasználók adatai kerülnek feldolgozásra.
Ilyenkor nem feltétlenül kommunikációs vagy adatbázishibát kell keresni.
Elsőként mindig azt kell ellenőrizni, hogy a VIKI valóban a megfelelő adatforrást figyeli-e.
Miért lehet szükség több VIKI klienskonfigurációra?
Többfelhasználós terminálszerveres környezetben el kell különíteni a közös és a felhasználóspecifikus komponenseket.
A központi RLB-adatforrás lehet minden könyvelő számára ugyanaz.
Az ÁNYK környezete azonban felhasználónként eltérhet.
Ez azt jelenti, hogy a rendszer kialakításánál nem elegendő azt ellenőrizni, hogy:
„A VIKI telepítve van-e a szerveren?”
A valódi kérdés inkább ez:
„A megfelelő VIKI kliens a megfelelő felhasználó megfelelő adatforrásait éri-e el?”
Ez különösen fontos olyan könyvelőirodákban, ahol egyszerre akár több könyvelő dolgozik ugyanazon a Windows Server vagy terminálszerver környezeten.
Egy MySQL vagy minden felhasználónak külön adatbázis?
Ez az egyik olyan pont, ahol könnyű túlbonyolítani a rendszert.
Attól, hogy több Windows-felhasználó vagy több VIKI klienskonfiguráció található ugyanazon a szerveren, nem következik automatikusan, hogy minden felhasználó számára külön MySQL-kiszolgálóra van szükség.
A helyi adatbázis-kezelés és a felhasználói klienskörnyezet két külön kérdés.
Ezért először a teljes architektúrát kell feltérképezni:
- hol található az RLB;
- hol található a MySQL;
- melyik kliens használja;
- milyen ÁNYK-adatforrás tartozik az egyes felhasználókhoz;
- hogyan történik a szinkronizáció.
Csak ezután érdemes módosítani a konfigurációt.
Tipikus VIKI–RLB–ÁNYK hibák és megoldások
A gyakorlatban sokszor nem az történik, hogy a teljes VIKI-rendszer működésképtelenné válik.
Sokkal gyakoribb a részleges működés.
Ez pedig sokkal megtévesztőbb lehet.
1. Az RLB szinkronizál, de az ÁNYK nem
Ha az RLB-ből származó információk megfelelően megjelennek, de az ÁNYK-hoz kapcsolódó adatok nem, akkor az egyik első vizsgálandó terület az ÁNYK adatkönyvtára.
Ellenőrizni kell:
- melyik könyvtárba dolgozik ténylegesen az ÁNYK;
- ezt az útvonalat figyeli-e a VIKI;
- eléri-e a VIKI kliens ezt a könyvtárat;
- megfelelőek-e a fájlrendszer-jogosultságok;
- a megfelelő Windows-felhasználó környezetében fut-e a kliens.
Terminálszerveren különösen veszélyes automatikusan abból kiindulni, hogy minden könyvelő ugyanazt az ÁNYK-adatkönyvtárat használja.
2. Az ÁNYK működik, de az RLB-adatok nem frissülnek
Ebben az esetben már az RLB és a VIKI közötti adatútvonalat kell megvizsgálni.
Ellenőrizendő többek között:
- az RLB tényleges adatforrása;
- az RLB elérési útvonala;
- a VIKI konfigurációja;
- a hálózati megosztások;
- a fájl- és könyvtárjogosultságok;
- a VIKI kliens működése;
- a MySQL szolgáltatás állapota;
- valamint maga a szinkronizáció.
A hibakeresés során célszerű mindig az adat útját követni:
RLB → VIKI kliens → MySQL → VIKI
Ha meghatározható, hogy melyik pontig jut el megfelelően az adat, a lehetséges hibaforrások köre jelentősen csökkenthető.
3. Egyik könyvelőnél működik, a másiknál nem
Ez tipikus többfelhasználós probléma.
Ha ugyanazon a terminálszerveren az egyik felhasználónál megfelelően működik a VIKI és az ÁNYK kapcsolata, a másiknál viszont nem, akkor fontos információval rendelkezünk:
a közös infrastruktúra legalább részben működőképes.
Ilyenkor elsősorban azt kell megvizsgálni, hogy mi különbözik a két felhasználó között.
Például:
- ÁNYK adatútvonal;
- Windows felhasználói profil;
- könyvtárjogosultság;
- VIKI klienskonfiguráció;
- környezeti változók;
- meghajtócsatolások;
- felhasználói mappák.
A hibakeresés egyik legegyszerűbb, mégis leghatékonyabb módszere ilyenkor:
összehasonlítani a működő és a hibás környezetet.
4. A VIKI régi adatot mutat
Ha a VIKI-ben szereplő információ nem frissül, először azt kell meghatározni, hogy az adatfolyam melyik pontján maradt meg a korábbi állapot.
Ellenőrizni kell:
- az RLB-ben már az új adat szerepel-e;
- a VIKI kliens hozzáfér-e ehhez az adathoz;
- megtörtént-e a helyi feldolgozás;
- megfelelően működik-e a MySQL;
- megtörtént-e a VIKI felé történő szinkronizáció.
Nem érdemes rögtön a folyamat utolsó eleménél keresni a hibát.
5. Szerverköltöztetés után megszűnik a szinkronizáció
Ez különösen érdekes hibaforrás.
Egy szerverköltöztetés során megváltozhat:
- a szerver neve;
- az IP-cím;
- a hálózati megosztás;
- a meghajtóbetűjel;
- az RLB elérési útvonala;
- az ÁNYK adatkönyvtára;
- a Windows profil;
- vagy valamely szolgáltatás jogosultsága.
Az alkalmazások ettől még elindulhatnak.
A háttérben működő integráció azonban továbbra is egy régi elérési útvonalat próbálhat használni.
Ezért migráció után nem elegendő azt ellenőrizni, hogy az RLB és az ÁNYK elindul-e.
Az összes kapcsolódó integráció működését is tesztelni kell.
A szerveres infrastruktúra modernizációjának gyakorlati oldaláról a Miért váltott egy könyvelőiroda NAS-ról Proxmox szerverre? Egy modern IT-infrastruktúra tanulságai című esettanulmányunkban is részletesen írtunk.
Ne telepítsük újra azonnal az egész rendszert
Amikor egy alkalmazás nem megfelelően működik, gyakori első reakció:
„Telepítsük újra.”
Integrált könyvelőirodai környezetben ez nem feltétlenül jó hibakeresési stratégia.
Ha például egy rossz ÁNYK-útvonal okozza a problémát, a VIKI újratelepítése önmagában nem oldja meg a valódi hibát.
Sokkal jobb sorrend:
- adatforrás ellenőrzése;
- elérési útvonal ellenőrzése;
- jogosultság ellenőrzése;
- kliensfolyamat ellenőrzése;
- MySQL ellenőrzése;
- szinkronizáció ellenőrzése;
- naplók és hibaüzenetek vizsgálata;
- csak ezután javítás vagy újratelepítés.
Ez ugyanaz az alapelv, amelyet a teljes vállalati IT üzemeltetésnél is érdemes követni.
Nem a tünetet kell megszüntetni, hanem a kiváltó okot kell megtalálni.
Különösen fontos a helyes kialakítás terminálszerveren
Egy többfelhasználós könyvelőirodai terminálszerver lényegesen összetettebb környezet, mint egyetlen Windows munkaállomás.
Egyszerre lehet jelen:
- központi RLB;
- több Windows-felhasználó;
- felhasználónként eltérő ÁNYK;
- közös MySQL;
- több VIKI klienskonfiguráció;
- hálózati adattárolás;
- jogosultsági struktúra;
- biztonsági mentés.
Itt már nem érdemes egyetlen alkalmazásban gondolkodni.
A teljes könyvelőirodai infrastruktúrát rendszerként kell kezelni.
Egy rosszul kialakított jogosultság, megváltozott meghajtóbetűjel, hibás hálózati útvonal vagy felhasználói könyvtár ugyanis olyan hibát okozhat, amely első ránézésre VIKI-, RLB- vagy ÁNYK-problémának látszik.
Pedig valójában infrastruktúra-probléma.
A biztonsági mentésről sem szabad megfeledkezni
Egy könyvelőirodai rendszerben nemcsak az alkalmazások telepítőit kell védeni.
A kritikus adatok és konfigurációk között lehetnek:
- RLB-adatok;
- ÁNYK állományok;
- adatbázisok;
- konfigurációs fájlok;
- egyedi beállítások;
- felhasználói könyvtárak;
- szerverkonfigurációk.
A biztonsági mentés azonban önmagában még nem elegendő.
Azt is tudni kell, hogy egy meghibásodás után hogyan és milyen sorrendben állítható helyre a teljes könyvelőirodai környezet.
A megfelelő mentési struktúráról részletesebben a 3-2-1 biztonsági mentési stratégia – Így védheti meg vállalkozása adatait témakörében is foglalkozunk.
A teljes rendszerleállásra való felkészülésről pedig a Mennyi ideig működne a cége informatika nélkül? – Így készülhet fel egy teljes IT-leállásra című cikkünkben írtunk részletesebben.
Ez egy könyvelőirodában különösen fontos lehet egy bevallási, bérszámfejtési vagy adófizetési határidő előtt.
Nemcsak működnie kell – észre is kell venni, ha valami megáll
Az integrációs rendszerek egyik veszélye, hogy egy részleges meghibásodás nem feltétlenül jár azonnal látványos hibával.
Lehet, hogy:
- a szerver működik;
- az RLB elindul;
- az ÁNYK használható;
- a felhasználók be tudnak jelentkezni;
miközben valamely háttérfolyamat már nem szinkronizál megfelelően.
Ezért üzleti szempontból nem elegendő kizárólag azt figyelni, hogy egy szerver elérhető-e.
A kritikus szolgáltatások és folyamatok működését is ellenőrizni kell.
Erről részletesebben a Miért fontos a folyamatos szerver- és hálózati monitoring? Így előzhetők meg a váratlan rendszerleállások című cikkünkben írtunk.
Mikor érdemes informatikust bevonni?
Egy egyszerű kliensprogram telepítése nem feltétlenül igényel komplex infrastruktúra-tervezést.
Más a helyzet azonban, ha:
- több könyvelő használja a rendszert;
- az RLB hálózatos környezetben működik;
- terminálszervert használnak;
- felhasználónként külön ÁNYK-környezet található;
- több VIKI klienskonfiguráció működik;
- VPN-en keresztül is dolgoznak;
- több telephely van;
- rendszeresen megszakad a szinkronizáció;
- vagy szerverköltöztetés után jelentkeznek problémák.
Ilyenkor már nem egyetlen program telepítéséről van szó.
Az RLB, az ÁNYK, a VIKI, a MySQL, a Windows Server, a hálózat és a jogosultságkezelés együtt alkotja a működő rendszert.
A SARABEL Informatikánál könyvelőirodai környezetekben többek között RLB-60, VIKI Könyvelő Asszisztens, ÁNYK, Novitax és más üzleti alkalmazások telepítésével, migrációjával, hálózati integrációjával és üzemeltetésével is foglalkozunk.
A cél ilyenkor nem egyszerűen az, hogy minden program elinduljon.
Hanem az, hogy a teljes folyamat stabilan működjön:
könyvelőprogram → adatfeldolgozás → bevallás → szinkronizáció → ügyfélkommunikáció.
Gyakori kérdések a VIKI, RLB és ÁNYK integrációjáról
Mi szükséges a VIKI és az RLB összekötéséhez?
A VIKI és az RLB kapcsolatának működéséhez megfelelően telepített és konfigurált VIKI kliensre, elérhető RLB-adatforrásra, megfelelő jogosultságokra és működő helyi adatbázis-környezetre van szükség.
Többfelhasználós környezetben azt is ellenőrizni kell, hogy a megfelelő kliens a megfelelő adatforráshoz kapcsolódik-e.
Összeköthető a VIKI az ÁNYK-val?
Igen. Az ÁNYK-integrációhoz a VIKI kliensnek hozzá kell férnie azokhoz az ÁNYK-adatkönyvtárakhoz, amelyekből a szükséges információkat feldolgozza.
Terminálszerveres környezetben különösen fontos ellenőrizni, hogy az egyes felhasználók milyen ÁNYK-adatkönyvtárat használnak.
Miért működik a VIKI egyik felhasználónál, a másiknál pedig nem?
Ennek oka lehet eltérő ÁNYK-adatútvonal, Windows-profil, jogosultság, klienskonfiguráció vagy felhasználói környezet.
Ilyenkor érdemes összehasonlítani egy működő és egy hibás felhasználó konfigurációját.
Miért nem jelennek meg az ÁNYK-adatok a VIKI-ben?
Elsőként az ÁNYK tényleges adatkönyvtárát és a VIKI által használt útvonalat érdemes ellenőrizni.
Ha ezek eltérnek, a kliens nem feltétlenül azokat az állományokat dolgozza fel, amelyekkel a könyvelő ténylegesen dolgozik.
Mit ellenőrizzünk, ha az RLB nem szinkronizál a VIKI-vel?
Érdemes sorrendben ellenőrizni:
- az RLB adatforrását;
- az elérési útvonalat;
- a jogosultságokat;
- a VIKI kliens működését;
- a MySQL szolgáltatást;
- a szinkronizáció állapotát;
- a kapcsolódó naplókat és hibaüzeneteket.
Miért jelentkezhet VIKI-hiba szerverköltöztetés után?
Migráció során megváltozhatnak az IP-címek, szervernevek, hálózati megosztások, meghajtóbetűjelek, felhasználói profilok vagy adatútvonalak.
Ezért egy szerverköltöztetés után nemcsak az RLB és az ÁNYK indulását, hanem a teljes VIKI-integrációt is ellenőrizni kell.
Kell minden felhasználónak külön MySQL?
Nem feltétlenül. A többfelhasználós klienskörnyezet és az adatbázis-kezelő architektúrája két külön kérdés.
A megfelelő kialakítást az adott szerver-, RLB-, ÁNYK- és VIKI-környezet alapján kell meghatározni.
Összegzés
A VIKI Könyvelő Asszisztens egyik legfontosabb előnye, hogy több olyan folyamatot kapcsolhat össze, amelyet egy könyvelőirodában egyébként külön-külön kellene kezelni.
Ehhez azonban megfelelő technikai háttér szükséges.
Különösen az RLB és ÁNYK integrációjánál fontos megérteni, hogy:
- honnan származik az adat;
- melyik kliens dolgozza fel;
- milyen útvonalon érhető el;
- melyik felhasználói környezethez tartozik;
- hol történik az adatfeldolgozás;
- és hogyan jut tovább a VIKI rendszerébe.
Ha probléma jelentkezik, ezért nem feltétlenül azt érdemes elsőként kérdezni:
„Miért nem működik a VIKI?”
Sokkal hasznosabb kérdés:
„A teljes adatútvonal melyik pontján áll meg a folyamat?”
Ha ezt sikerül meghatározni, egy látszólag megfoghatatlan VIKI-, RLB- vagy ÁNYK-hiba már konkrétan diagnosztizálható informatikai problémává válik.
Egy megfelelően kialakított könyvelőirodai infrastruktúrában pedig nemcsak az egyes programok működnek.
A teljes rendszer működik együtt.