A magyar Számviteli törvény (Sztv. 169. §) szerint minden könyvelési szempontból releváns adatváltozást meg kell őrizni nyolc évig. Egy ERP audit trail ennek a kötelezettségnek a mérnöki megvalósítása. Megnéztük, hol csinálja jól a legacy Netorigo ERP, és hol hibázik — utóbbi az új moduláris stack tervezési kiindulópontja volt.
A négy kötelező dimenzió
Minden auditálható eseménynek tartalmaznia kell:
- Ki — felhasználói azonosító + szerepkör + bejelentkezési session ID.
- Mikor — UTC timestamp, ezredmásodperc pontossággal.
- Mit — entitás (pl.
invoice,customer,permission), művelet (create,update,delete,read), entitás ID. - Mi előtte, mi utána — change diff: az érintett mezők korábbi és új értékei.
A negyedik dimenzió a legtöbb rendszerben hiányzik vagy hézagos. A legacy ERP a tranzakciós naplót (transaction_journal táblát) tisztán kezeli: minden főkönyvi tételhez van előtte-utána állapot, és ez nyolc évre lekérdezhető. Itt jól van megírva.
Ahol a legacy ERP elcsúszik
Master data változások. Egy ügyfél nevét, adószámát, bankszámlaszámát módosítja egy felhasználó. A legacy ERP loggolja az időpontot, a felhasználót és az új értékeket — de a régi értéket nem. Két éve egy auditori vizsgálat kapcsán két napig kerestünk egy adószám-módosítást, ami megtörtént, csak nem tudtuk, mire volt módosítva korábban. Ezt fix után toldottuk be egy customer_audit táblával, de nem visszamenőlegesen.
Jogosultság-változások. Ki kapta meg az accounting_admin szerepkört, mikor és kitől? A legacy ERP ezt csak a webszerver access logban tárolja, ami 30 nap után rotál. Egy szabványos auditori kérdés („mutassuk meg, ki módosíthatta a számlákat 2024 októberében”) nyolc évre visszamenőleg nem megválaszolható a régi log alapján — fix után igen, de a 2024 előtti adatra nem.
Olvasási események. A read műveletek loggolása sehol nincs. Ez nem feltétlenül baj — a Sztv. csak az adatváltozásokra ír elő megőrzést. De ha valaha jön GDPR audit („ki nézte meg ennek az ügyfélnek a személyes adatait?”), nem tudunk válaszolni. A modern stackben opcionálisan minden read-et loggolunk, tenant-szintű kapcsolóval.
A modern stack négy elve
- Minden mutáció auditálva. Egyetlen entitás-tábla sem létezhet párhuzamos
*_audittábla nélkül. A migrációkban ez egy ellenőrzött constraint. - Read auditálás opcionális. Tenant-szintű kapcsoló. Storage költség jelentős — kis tenantnál általában kikapcsolva, nagyobbnál (50+ fő) bekapcsolva.
- Append-only. Egyetlen audit sor sem törölhető vagy módosítható API-n keresztül. SQL szintű constraint (
DELETEésUPDATEtriggerekRAISE EXCEPTION-nel),audit_adminszerep is csakSELECT-elhet rajta. - Immutable storage tier 5 év után. Lásd alább.
A retention-vs-storage kompromisszum
Nyolc év audit data komoly tárolóköltség. Egy közepes ERP-tenant esetében (50 fő, napi 1 000 mutáció) ez évi 5–8 GB hot storage, nyolc év alatt 50–60 GB — és ez csak az audit, az üzleti adat nélkül. Az aktív SSD-en ezt drága tartani.
Amit csinálunk: az első 5 év hot tier-en (PostgreSQL aktív tábla), az utolsó 3 év cold tier-en (S3-kompatibilis objektumtárolóban, Parquet formátumban, particionálva év szerint). A lekérdezés a régebbi adatra lassabb (5–30 másodperc query helyett percek), de mivel évente 0–2 alkalommal nyúl hozzá bárki, ez vállalható kompromisszum.
A migráció a hot → cold tier között negyedévente fut, automatizáltan, és a migrált adat hash-elve van — bármikor verifikálható az integritása.
Mit kezdjünk a régi ERP audit-hézagjaival
Gyakorlati válasz: nem retroaktívan. Amit nem loggolt a régi rendszer, azt nem tudjuk visszahozni. A migráció pillanatától viszont a modern stack mindent teljesen lefed. Az auditori kérdéseknél a tenantokat oktatjuk: a migráció dátumáig a régi rendszer hézagos auditot ad, utána komplettet.
Ez nem népszerű válasz, de őszintébb mint az alternatíva (utólag hamis adatot generálni). A tenantok elfogadják, a könyvvizsgálók megértik, az alapszabály egyszerű: ma kezdjük rendesen csinálni.