Az adatkapcsolati hibák nem kivételek, hanem törvényszerűségek.
A különbség nem az, hogy előfordulnak-e, hanem az, hogy:
👉 észrevétlenül termelnek NAV-kockázatot,
vagy
👉 kontroll alatt maradnak.
A „jó pénztárgépes rendszer” nem az, ami soha nem hibázik, hanem az,
👉 ami fel van készítve a hibára. ⚠️

Ez triviálisnak hangzik – mégis itt bukik el a legtöbb rendszer.
🔌 elsődleges, vezetékes kapcsolat
📶 automatikus tartalék (mobilnet)
📡 Wi-Fi csak kontrollált környezetben
🔄 kiszámítható útvonal a NAV felé
✔️ Internet önmagában nem elég
❌ „ami épp van” megoldás nem elfogadható
👉 A NAV-adatküldés nem tolerálja az improvizációt.
Meglepően sok adatküldési hiba nem a pénztárgép hibája, hanem a hálózaté.
NAV-végpontok nem szűrhetők 🔥
proxy-kényszerítés kerülendő
DNS-feloldás stabil legyen
NAT-tábla ne teljen meg csúcsidőben
📌 Ha a router „csak böngészésre van hangolva”,
📌 akkor a pénztárgép csendben el fog vérezni.
A SIM-kártyás kapcsolat nem ördögtől való, de nem mindegy, hogyan használod.
✔️ megfelelő APN
✔️ ismert szolgáltatói korlátok
✔️ nem egyedüli főkapcsolat
✔️ automatikus visszaváltás LAN-ra
👉 A mobilnet tartalék, nem stratégia.
Aki erre épít mindent, az nem tervez, hanem reménykedik.
Ezek azok a hibák, amik nem jeleznek, csak következményt okoznak.
Figyelni kell:
⏰ pontos időszinkron
🔑 érvényes tanúsítvány
🔄 friss firmware és szoftver
📜 aktuális NAV-protokollok
👉 Ezek hiányában lehet „kapcsolat rendben”,
de adatküldés nem lesz.
A puffer nem biztonsági háló, hanem átmeneti megoldás.
✔️ látni kell a puffer állapotát
✔️ tudni kell az utolsó sikeres küldés idejét
✔️ riasztani kell torlódás esetén
❌ napokig „csendben gyűjtögetni” nem elfogadható
📌 A puffer célja az áthidalás – nem a halogatás.
A legtöbb bírság oka nem technikai, hanem észlelési hiba.
Szükséges:
📊 valós adatküldési státusz
⏱️ NAV-visszaigazolás figyelése
🚨 egyértelmű riasztások
🧠 különbségtétel hálózati és NAV-hiba között
👉 Amit nem látsz, azt nem tudod kezelni.
Nem minden pénztárgép alkalmas üzemszerű, hibatűrő működésre.
A korszerű e-pénztárgépek – például az ACLAS megoldásai – már:
több adatkapcsolatot kezelnek
nem fedik el a hibát „zöld” státusszal
pontosan jelzik a késleltetett adatküldést
segítik a NAV-megfelelő üzemeltetést
Ez nem kényelmi funkció, hanem működési minimum. 🚀
Az adatkapcsolati hibák nem megszüntethetők,
de megelőzhetők abból a szempontból, hogy:
❌ ne legyenek rejtettek
❌ ne legyenek tartósak
❌ ne váljanak jogsértéssé
👉 A kérdés tehát nem az, hogy
„lesz-e hiba?”,
hanem az, hogy
👉 fel vagy-e készülve rá rendszer szinten?
Aki ezt komolyan veszi, az nem tűzolt –
hanem biztonságosan üzemeltet.