Folyamatos vagy eseményalapú adatküldés? – hogyan kommunikál az e-pénztárgép a háttérrendszerekkel

A legfontosabb tudnivalók az e-pénztárgépes megoldásról

Az e-pénztárgép kiválasztásánál a készüléket, az adatszolgáltatást, az integrációt és a későbbi támogatást egyetlen rendszerként kell vizsgálni. Sokan még mindig úgy képzelik el az e-pénztárgépet, mintha az folyamatosan „csörögné” a NAV-ot , állandó adatfolyamot küldene, „élő kapcsolatban” lenne a háttérrendszerekkel.

Hogyan kommunikál valójában az e-pénztárgép a háttérrendszerekkel

Ez nem így van – és jó okkal nem. Az e-pénztárgép kommunikációja eseményvezérelt, nem folyamatos. Ez tudatos tervezési döntés, nem technikai hiányosság.

Mit jelent a folyamatos adatküldés – és miért nem ez a modell?

A folyamatos adatküldés elméletben azt jelentené, hogy:

• állandó, nyitott kapcsolat van

• minden változás azonnal továbbításra kerül

• a rendszer „streamel”

Ez viszont pénztárgépnél nem üzembiztos:

érzékeny az instabil hálózatra folyamatos kapcsolatot igényel mobilneten különösen sérülékeny jogilag nehezen kezelhető megszakadás esetén

Egy megszakadt „folyam” adatvesztési kockázatot jelentene.

Az eseményalapú adatküldés lényege

Az e-pénztárgép nem beszél feleslegesen.

Adatküldési esemény csak akkor indul, ha:

• nyugta készül

• pénztárzárás történik

• rendszeres státuszadat keletkezik

• jogszabály által előírt esemény történik

Minden adatküldés konkrét eseményhez kötött.

Ez: kiszámítható naplózható újraküldhető bizonyítható

Mi történik egy eseménynél?

Vegyünk egy egyszerű példát: nyugta kiállítása.

Az e-pénztárgép: 1⃣ adatot gyűjt 2⃣ adatcsomagot épít 3⃣ helyben eltárolja 4⃣ elküldi a háttérrendszernek 5⃣ vár visszajelzésre

Ha nincs kapcsolat:

• az adat nem vész el

• pufferbe kerül

• később kerül továbbításra

Ez a működés nem lassúság, hanem védelem.

Kik a „háttérrendszerek”?

Fontos pontosítani, mert nem csak a NAV-ról van szó.

Az e-pénztárgép kommunikálhat:

• a NAV rendszerével

• felhőalapú menedzsmenttel

• könyvelési rendszerrel

• készletkezelővel

• riporting és monitoring modulokkal

Ezek nem egy csatornán, és nem azonos logikával működnek.

Az eseményalapú modell ezt teszi lehetővé.

Mi történik kapcsolatmegszakadáskor?

Ez a kritikus pont.

Eseményalapú működésnél:

• nincs „elszakadt folyam”

• nincs fél adat

• nincs bizonytalan állapot

Csak ez van: esemény létrejött adat eltárolva küldés késik

A kockázat kezelhető és mérhető.

Miért tűnik mégis „folyamatosnak” kívülről?

Mert jól működő rendszernél:

• az események gyakoriak

• a küldés gyors

• a visszajelzés automatikus

Ettől folyamatos érzetet kelt, de technikailag nem az.

Ez fontos különbség NAV-ellenőrzésnél.

Miért előny ez az üzemeltetőnek?

Az eseményalapú adatküldés:

jobban tűri az instabil hálózatot mobilneten is működőképes visszakereshető naplózható jogilag védhető

A korszerű e-pénztárgépek – például az ACLAS megoldásai – erre az elvre épülnek:

• nem tartanak fenn felesleges kapcsolatot

• nem veszítenek adatot

• pontosan megmutatják, mely esemény mikor ment el

Ez nem technológiai divat, hanem üzemi kényszer.

Mit érdemes megjegyezni a témáról?

Az e-pénztárgép nem folyamatosan beszél, hanem akkor szól, amikor kell.

esemény keletkezik adatcsomag készül továbbítás történik visszaigazolás érkezik

Ez az egyetlen modell, ami:

• hálózati hibák mellett is működik

• jogilag értelmezhető

• és bizonyítható a NAV felé

A kérdés tehát nem az, hogy „folyamatos-e az adatküldés?”, hanem az, hogy eseményenként bizonyítható-e, mi történt az adattal?