Folyamatos vagy eseményalapú adatküldés? – hogyan kommunikál az e-pénztárgép a háttérrendszerekkel
🔄 Folyamatos vagy eseményalapú adatküldés?
Hogyan kommunikál valójában az e-pénztárgép a háttérrendszerekkel
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.
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.
🧠 1. 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.
⚡ 2. 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ó
📦 3. 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.
🌐 4. 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é.
🔁 5. 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ő.
🚨 6. 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. 🚀
🧾 Összegzés
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?