Online-invoice: Forgalomkorlátozás + felhő problémakör

[EPluribusUnum]

A forgalomkorlátozás az betesz a felhőszolgáltatásnak. Több száz cég fut egyetlen IP alatt és az egyes cégek egymástól függetlenül szolgáltatnak adatot, nem tudnak egymásról. Ezzel a szűréssel viszont valahogy koordinálni kellene már a NAV felé a kommunikációt a cégek között, ami horror. Az IP alaú szűrés az kevés, valahogy IP + adószám alapján kellene korlátozni.

[NTCA-developer]

Szia @EPluribusUnum

Az miért probléma, hogy csak a v2-es státusz lekérdezések késleltetve vannak? Az esetleges kitiltás is csak a státusz lekérdezést érinti. Adatszolgáltatás beküldését ez a szűrés nem fogja meg.

[peterkulik]

Infó mindenképpen kellene, hogy mi lesz a működés. GeneralError, vagy csak a szerver elutasítja a kérést?
Jó lett volna ezt a teszten kipróbálni, mert le kellene kezelni ezt az állapotot. Holnap meg már élesben megy ez a fajta működés, leírás meg, ha jól látom nincs frissítve.

[NTCA-developer]

Hamarosan a teszten is ki lehet próbálni. Egyébként ez layer3 működés, szóval oprendszertől függ hogy mit fogsz látni. De az mindenképpen közös, hogy valamilyen connection reset lesz. Erre viszont szerintem mindenki fel kell hogy legyen készülve, alap try-catch működés.

[omachtandras]

Szia @EPluribusUnum

Az miért probléma, hogy csak a v2-es státusz lekérdezések késleltetve vannak? Az esetleges kitiltás is csak a státusz lekérdezést érinti. Adatszolgáltatás beküldését ez a szűrés nem fogja meg.

Sziasztok!

Mi a helyezte mondjuk egy közüzemi szolgáltatónál, aki egy számlázási pillanatban akár 100.000 olyan számlát is érvényesít január 1-től (magánszamély), amelyet be kell küldeni.
Ezek a beküldések egy ip címről fognak megtörténni, és mivel nincs erre az ágra korlátozás, ezért "azonnal be is fognak menni"
A lekérdezés is ugynarról az ip címről történik majd, de ott már meglesz a korlátozás.
A 100.000 lekérdezés 100.000 mp-et fog igényelni?

Nálunk olyan az infrastruktúra, hogy erről az ip címről párhuzamosan több száz olyan céggel kapcsolatban is indul(hat) lekérdezés, amelyek 1-1 számlát állítanak ki egy adott pillanatban, de ha jól értem, akkor ők mostantól konkurensek lesznek (a NAV szempontjából), tehát rossz esetben nekik is meg kell várni a 100.000 mp-et, mire sikeresen választ kaphatnak az egyetlen számlájukra

Értem az alap problémát, ami miatt a korlátozás mellett döntöttetek, de jelenleg bizonytalan vagyok, hogy ez a mi infrastruktúránkban milyen következményekkel jár. (A sikertelen lekérdezések logolásra kerülnek, nem örülnék, ha több tíz vagy százezer log rekordunk lenne ez miatt.)

[NTCA-developer]

@omachtandras

A közüzemi szolgáltatók kötegelve küldenek, tehát oszd el százzal a kéréseik számát.

[omachtandras]

Lehet, hogy úgy küldik, de mi biztosan nem. És ez nem is volt előírás soha, hogy kötegelten kell küldeni.
Hogy miért történt ez a döntés annak idején, azt nem szeretném részletezni, jogászokkal történt egyeztetés, stb., de ez adottság, és nem is hiszem, hogy középtávon ezen változtatni fognak / fogunk.
De, ha kötegelten is menne, akkor is 1.000 kötegről beszélünk.

[EPluribusUnum]

Szia @EPluribusUnum

Az miért probléma, hogy csak a v2-es státusz lekérdezések késleltetve vannak? Az esetleges kitiltás is csak a státusz lekérdezést érinti. Adatszolgáltatás beküldését ez a szűrés nem fogja meg.

Az adatszolgáltatás teljesítéshez a queryTransactionStatus-nak DONE-t kell visszaadnia, és pont azt korlátozzátok le. Ráadásul olyan limitet adtatok meg ami nem cég szintű, így koodinálni kell a cégek közötti lekérdezést, hogy ne fussanak egymásra a hívások, ne kezdjenek növekedni a késleltetések. A hír szerint minden egyes egymásra futás további +4sec-el növeli a késletetést, és koordináció nélkül így potenciálisan nagyon gyorsan meg tud hízni a késletetés.

• Van még az eset amikor egy cég állít ki tömegesen számlát, még csak felhő sem kell. Akkor ott is minden egyes számlához 1 sec-es várakozást kellene beépíteni a lekérdezések közé fixen, hogy ne legyen probléma?

[szako]

@NTCA-developer Az újraküldés időpontját a válasz visszaküldésétől vagy az eredeti kérés küldésétől számítja a rendszer? Ha szinkron fut egy process és mindenképp megvárja az első 4 másodperces késleltetést, a következő küldés várakoztatva lesz vagy befogadja a rendszer?

[NTCA-developer]

@omachtandras, @EPluribusUnum
Ha jól számolom, akkor 1 másodpercen belüli időablakot nézve a másodiktól indul a késleltetés, tehát egy sec alatt egy forrás IP-ről 15+1 párhuzamos lekérdező szálat tudsz fenntartani. Szerintem ez az elégségesnél bőven több, igaz, hogy a válaszidő lineárisan egyre magasabb lesz. Lássuk meg hogy mit hoz az élet. Az azonnaliság követelménye a beküldésre vonatkozik, a lekérdezésre nem, ezért async a működés. Ha egy nap múlva dolgozzuk csak fel a számla adatokat, akkor egy nap múlva kaphattok csak választ. Semmiféle problémát nem látunk ezen a téren, hogy nem azonnal, hanem X perc múlva kapjátok csak meg a feldolgozási eredményt.

@szako

Másodpercenkénti ablakokat vizsgálva már a második beérkező státusz lekérdezés elindítja a késleltetést. Ennek a lehűlési ideje a max késleltetés időtartama, tehát legfeljebb 1 perc után mindig tiszta lappal indulsz.

[nbeeps2]

@NTCA-developer : egyáltalán nem támogatom ezt a működést! Célzottan vegyétek fel a kapcsolatot az érintett fejlesztő cégekkel, akik miatt erre az intézkedésre szükség volt!

[nbeeps2]

Az meg végképp elfogadhatatlan, hogy élesben ez csak úgy bumm belekerül, anélkül, hogy erre fel lehetne készülni. A teszt rendszerben kellett volna ez betenni, hogy mindenki le tudja tesztelni, hogy ez a korlátozás hogy érinti a saját programját. Utána időt hagyni az átállásra és ezt követően élesíteni...

[NTCA-developer]

@nbeeps2 és mi erre a konkrét indok? Ismételni nem akarom magam, de ez semmilyen jóhiszeműen működő adózót vagy számlázó programot nem befolyásol hátrányosan.

[szako]

@NTCA-developer Csak arra akarok kilyukadni, hogy ha minimális késleltetéssel (pl. 0,1s) működik jelenleg a rendszer kliens oldalon jelenleg és egy process küldi be a számlákat (a párhuzamosítást kikapcsoljuk), akkor az élesítés után 4 másodpercre fog változni beküldések közötti időtartam?

[csaszko]

Van még az eset amikor egy cég állít ki tömegesen számlát, még csak felhő sem kell. Akkor ott is minden egyes számlához 1 sec-es várakozást kellene beépíteni a lekérdezések közé fixen, hogy ne legyen probléma?

Lehet, hogy nem lesz rá példa.. de.. ha egy külső IP-t több/sok cég használ (pl. wifis-s,( de telekom is csinálja..szóval.) szolgáltató natol és nincs külön ip) és egyszerre indítanak, akár tömeges számlázást, akár csak szeretné tudni, hogy mi milyen státuszban van mert ki volt tiltva pénteken és hetfő reggel indítják újra 8 kor a gépeket....
Ebben az esetben aztán optimalizálhatsz kliens oldalon bármit.. nem is tudsz róla, hogy adott IP miért van tiltva és folyamatosan összeakadnak a lekérdezések.

[nbeeps2]

@NTCA-developer : csaszko épp most fogalmazta meg. IP cím alapján ilyet összevonni óriási butaság. A számlázó program teljesen megfelelően működik, de a működési környezetre nincs rálátásunk. A mi programjainkat használják több céges környezetben, vagyis egy számlázó program egy gépről és IP-ről több cég nevében is küldhet, kérdezhet adatokat...

[csaszko]

Én is értem a problémát, és kell is tenni ez ellen, hogy tudjon működni rendesen, de miért nem azokat büntetitek ezzel, ahonnan érkeznek a kérések? Csak be lehet határolni, hogy ki/kik azok...

[nbeeps2]

@NTCA-developer : ha jól emlékszem ez a gitHub pont azért lett létrehozva, hogy mielőtt bármi be lenne vezetve meg lehessen vitatni a fejlesztői társadalommal. Én nem emlékszem, hogy ez a téma fel lett volna dobva a mi megkérdezésünkkel, és ez durván kihathat az amúgy jól működő programok működésére is! Már várom a telefonrohamokat ismét....

[NTCA-developer]

Kérlek, olvassatok is, ne csak írjatok. A beküldések intervallumára NINCS rate limiting. Csak a feldolgozási eredmények lekérdezésére van a v2-ben. Ezért ezzel ne érveljetek.

[nbeeps2]

@NTCA-developer pontosan értjük, hogy a számlabeküldést nem érinti, csak a státusz lekérdezést, de akkor ezek szerint Te nem érted, amit mi írunk.

[csaszko]

Kérlek, olvassatok is, ne csak írjatok. A beküldések intervallumára NINCS rate limiting. Csak a feldolgozási eredmények lekérdezésére van a v2-ben. Ezért ezzel ne érveljetek.

Ezt írtam:
Ebben az esetben aztán optimalizálhatsz kliens oldalon bármit.. nem is tudsz róla, hogy adott IP miért van tiltva és folyamatosan összeakadnak a lekérdezések.

[szako]

@NTCA-developer: _számla beküldést_ írtam helyett _státusz frissítés_, elnézést. A kérdésem a státusz lekérdezésre vonatkozik.

[nbeeps2]

@NTCA-developer : IP cím esetén, ha helyi hálózatban használják a szoftvert mondjuk 10 munkaállomáson, és a lekérdezést a munkaállomások végzik (nem a szerveren futó job), akkor ez nektek 10 féle IP lesz a lekérdezésben vagy 1?

[nbeeps2]

@NTCA-developer: @EPluribusUnum által felvetett esetben mi a megoldás? Össze fog akadni neki a statuslekérdezés rendesen...
Ez így nagyon nem jó, ezt nem gondoltátok át, ezért kellett volna minket megkérdezni, hogy milyen aggályok, problémák merülhetnek fel...

[nbeeps2]

@NTCA-developer "Ha jól számolom, akkor 1 másodpercen belüli időablakot nézve a másodiktól indul a késleltetés, tehát egy sec alatt egy forrás IP-ről 15+1 párhuzamos lekérdező szálat tudsz fenntartani. " Bocs ez nekem magas... Most egy sec alatt 1-et kérdezhetek vagy 15+1-et? Érti ezt valaki?

[rgform]

Ez úgy jött ki hogy 60 másodperc után tilt teljesen. 4 másodperceként emeli az időt 15 x 4 = 60, a plusz 1 az első még nem számolt... Vagyis elinditasz 16 ot azok sorban 0, 4 ,8, 12.... 60 késleltetést kapnak... a 17 már nem játszik...

[nbeeps2]

@rgform És meddig tart a tiltás vajon? ;)

[csaszko]

Szintén nem tudom mennyi számlát érinthet, de az előzőekkel együtt nézve, plusz egy dolog ami viszont az adatszolgáltatást befolyásolhatja. Módosító/sztornó számláknál meg kell várni amíg az eredeti feldolgozva van és done... Tehát nem csak azt kell most már esetleg megvárni, amíg feldogozott lesz, hanem azt is, hogy le tudd kérdezni... tehát folyamatosan valami logika alapján futtatod a lekérdezést amit Ti most (akármennyire is) de kontrolláltok. (Nem akarom folytatni az azonnali, nem azonnali értelmetlen vitát.. de ez okozhat érdekes helyzeteket.. )

[EnokhSys]

@NTCA-developer Az ég szerelmére, ezt így nehogy bevezessétek holnap, mert ebből megint közbotrány lesz!! Gondolkozzatok: csak a forrás IP-cím szűrés nem elég, hiszen fentebb is sokan jelezték, hogy több száz cég egy ip-címről kommunikál. Tegyétek hozzá a usert is, és ez így már rendben lesz.

[NTCA-developer]

@nbeeps2 Ez egy sürgős intézkedés. Nézd meg a válaszidőket. Nincs idő egyezkedni. Ez nem azt jelenti, hogy nem vagyunk partnerek veletek vagy hogy nem gondoltuk át ez mit okoz. Szerintünk semmit. De nem borulhatunk be csak azért, mert már annyi potyautasunk van, hogy nem bírunk velük, miközben egyre nő azoknak a kényelmi szolgáltatásoknak a használata, amiket pont az miatt építettük hogy használják.

Az a matek, hogy 15 másodpercenként beérkezik 5000+ token kérés és 3500+ státusz lekérdezés, miközben a legnagyobb csúcsban ebben a 15 másodpercben legfeljebb 1500 számla adatszolgáltatás érkezik. És a token meg a státusz lekérdezések ömlenek csúcsidőn kívül is. A tokenkéréseket korlátozni felesleges mivel lehetetlenül olcsó, nem nyerünk vele. A státusz lekérdezések se annyira drágák, de azon már lehet értelmes kapacitást nyerni.

@rgform 1 percig. Utána tiszta lappal indulsz ismét.

@csaszko Ez igaz, viszont /queryInvoiceCheck-el lehet kezelni. Meg úgy általában ez egy szűk réteg, hogy azonnali módosító számlát akarsz kiadni.

@EnokhSys Akkor holnap megállhat az éles, abból nem lesz? Mint mondtam ez L3-as megoldás, az L7 adatok számára nem hozzáférhetőek. Nincs lehetőség semmilyen üzleti adatra szűrni, legalább is ez a megoldás nem képes erre.

[csaszko]

Akkor az a javaslatom, hogy az ügyfelek felé a lejárató emailek küldözgetését (akármelyik kezetek is csinálja) szintén sürgős intézkedésként állítsátok le, ameddig "kiderül mit hoz az élet"!

[NTCA-developer]

@csaszko Sajnálom, de ennek a megbeszélése most nem segít a témán.

[nbeeps2]

@csaszko Nyissunk ennek külön topikot, mert amit írt az is óriási probléma és valótlan dolgokat állít a NAV, amit ha nem hagy abba, akkor mi már peren is gondolkozunk. Kimeríti a rossz hírnév keltés, márka rontás fogalmát.

[NTCA-developer]

@nbeeps2 Van már neki.

[szako]

@NTCA-developer: Ha minimális késleltetéssel (pl. 0,1s) működik jelenleg a rendszer kliens oldalon és egy process kérdezi le a számlák státuszát (a párhuzamosítást kikapcsoljuk és megvárja a process a választ), akkor az élesítés után 4 másodpercre fog változni kérések közötti időtartam, jól gondolom?

[csaszko]

Ezt, hogy érted? Változtattok valamit az éles rendszeren, - végig gondoltatok biztosan nagyon sok mindent-, de aminek még Ti sem láthatjátok a pontos működését (gyakorlati oldalát). Ezért gondoltam, hogy célszerű lenne ezt is meglépnetek. Ezért szerintem segít a témán, mert ha még levelezgetni is fognak a kollégáid, az mindenkinek csak még inkább megnövekedett terhet fog jelenteni.

[NTCA-developer]

@csaszko Sry, erre nem válaszoltam, gyorsan elmászott.

Ha 0,1 secenként küldesz lekérdezést, akkor a második kérés (nálad 0,2 secnél) már csak 4200,02 msnél érkezik meg a szerverhez. Mire eljutsz 0,17 sec-ig magadnál ezzel a logikával már a 17-ik kérésed timeoutra fog futni. Egészen addig, amíg 1 perc csendet nem hagytál a lekérdezésekben. Így érthető?

[EnokhSys]

@NTCA-developer Nem az 1 mp-es limittel van a gond, sőt, ez akár 2 mp is lehetne. Hanem a +4 sec-es halmozódó késleltetéssel és az 1 perc utáni kitiltás az aggályos, ezeket nagyon át kellene gondolni, mert nagyon ad-hoc jellegű, és - még akkor is, ha technikailag igazatok van -, az adózók törvényi kötelezettséget gátoljátok ezzel.

[NTCA-developer]

A kitiltás 1 perc után mindenképpen megtörténik, a külső hálózati eszköz elvágja a kapcsolatot. Szóval ebből a szempontból mindegy hogy a rate limiting maga terminál-e kapcsolatot, a külső eszköz mindenképpen már most is, kezdetektől fogva ezt megteszi. De egyébként ha nem is tenné, akkor a rate limiting semmit sem ér. Csak annyit csináltunk hogy a szinkron időhöz képest 4 másodperccel később ömlik ránk a forgalom. De akkor is ránk ömlik.

[balintdozsa]

@NTCA-developer A kitiltás meddig él?

[nbeeps2]

@balintdozsa 1 percig. Utána tiszta lappal indulsz ismét.

[nbeeps2]

Erre a korábban feltett kérdésemre még nagyon érdekelne a válasz:

@NTCA-developer : IP cím esetén, ha helyi hálózatban használják a szoftvert mondjuk 10 munkaállomáson, és a lekérdezést a munkaállomások végzik (nem a szerveren futó job), akkor ez nektek 10 féle IP lesz a lekérdezésben vagy 1?

[Rossi73]

Semmiféle problémát nem látunk ezen a téren, hogy nem azonnal, hanem X perc múlva kapjátok csak meg a feldolgozási eredményt.

Kedves @NTCA-developer! Ha péntek délután, munkaidő végén eddig megtörténhetett az x db beküldött számla státuszának lekérdezése, ami után a dolgozó megnyugodva hazament, de ezt követően lehet, hogy hosszabb időt kell túlóráznia, mert egy másik cég az irodaházban épp akkor küldi be és kérdezi le a tömeges számláit, akkor bizony ő joggal érezheti azt, hogy ez neki problémát okoz. Azt pedig ne felejtsük el, hogy az NGM rendelet ezt mondja:

"(3) A számlázó programmal történő adatszolgáltatás akkor minősül teljesítettnek, ha az (1) bekezdés szerint történt a benyújtása, és a sikeres feldolgozást az állami adó- és vámhatóság rendszere visszaigazolta."

Tehát, nem elég a beküldés, meg kell győződni a sikerességéről is. Ha ez most akadályba ütközik, akkor neki (jóhiszeműen) meg kellene várnia. Mert ha nem várja meg (mert nem tudja), csak hétfőn kérdezi le, és hétfő már másik hónap, akkor az előző hónapban nincs lekérdezve, a NAV pedig majd küldi megint a dörgedelmes levelet, hogy nem kérdezte le, hibás a számlázó program, javíttassa a fejlesztővel!

Tegnap csak azzal borzolta a NAV a kedélyeket, hogy a NAV saját hibáját kente rá a fejlesztőkre, most pedig bevezeti ezt a szabályt, minden előzetes értesítés nélkül. Inkább vegyétek fel a kapcsolatot azzal a 10-20 (nem tudom, mennyi) fejlesztő céggel, és utasítsátok őket a megfelelő használatra! Vagy, ha megvan az a 200 IP cím, amiről jönnek a "szabálytalan" működések, akkor korlátozzátok be azt, ne pedig a többi több 100 ezer felhasználót...

Előre is köszönjük!

[EnokhSys]

@NTCA-developer Értsd meg a lényeget: nem tilthatjátok ki az ip-címet a törvényi kötelezettség miatt. Még 1 percre sem. Értem én, hogy informatikailag ez a megoldás a kézenfekvő, de a törvényi előírás a magasabb.

[Rossi73]

Utóirat: arról nem beszélve, hogy ez "csak" egy hírben jelent meg a NAV online számla oldalán. Nem kellett volna erről más csatornán értesítést küldeni? Vagy a NAV elvárása, hogy ezek szerint napi szinten olvasgassa mindenki a Hírek oldalt is? (Igen, "a fejlesztők sose mennek szabadságra, tudom, tehát akár idejükbe bele is fér"...)

[nbeeps2]

@EnokhSys : erre az lesz a válasz, hogy a számla beküldésben nem vagy korlátozva (mert csak a státusz lekérdezést érinti), a lekérdezés meg ráér 1 perc után is.

[EnokhSys]

@NTCA-developer igaza van Rossi73-nak, egy ip-filter listát kellene beállítani a kérés-bombázós ip-címekkel, és csak azokat bekorlátozni, ill felvenni velük a kapcsolatot.

[nbeeps2]

@EnokhSys erre ez volt a válasz: "Ez egy sürgős intézkedés. Nézd meg a válaszidőket. Nincs idő egyezkedni. "

[EnokhSys]

@EnokhSys : erre az lesz a válasz, hogy a számla beküldésben nem vagy korlátozva (mert csak a státusz lekérdezést érinti), a lekérdezés meg ráér 1 perc után is.

@nbeeps2 NEM, én nem erről írtam, hiszen a törvény nem csak a beküldést írja elő, hanem a lekérdezést a számla feldolgozás sikerességéről.

[EnokhSys]

@EnokhSys erre ez volt a válasz: "Ez egy sürgős intézkedés. Nézd meg a válaszidőket. Nincs idő egyezkedni. "

Nanee! Egy ip-filter listát összeállítani akár 1000 ip-címre egy ip-log file alapján, nehogy már ne lehessen 1 óra alatt megcsinálni.

[nbeeps2]

@EnokhSys ezt én értem, hogy csak akkor teljes a beküldés, ha ellenőrizted és sikeres, de @NTCA-developer szerint ez hogy 1 perccel később tudod csak lekérdezni az adatszolgáltatás sikerességét, az nem gátol téged, csak késleltet, hogy ennek eleget tegyél. De persze én sem értek egyet ezzel az egésszel (késleltetés bevezetése), amit fent már több ízben megfogalmaztam.

[nbeeps2]

@EnokhSys itt gondolom arra gondolt, hogy egy ilyen bürökratikus szervezetneél, mint a NAV, mire megfogalmaznak egy ilyen levelet, meg egyeztetnek a fejlesztőkkel, meg azok lefejlesztik és elküldik a felhasználóhoz az mind idő és ez nem akarják kijárni/kivárni.

[csaszko]

Erre a korábban feltett kérdésemre még nagyon érdekelne a válasz:

@NTCA-developer : IP cím esetén, ha helyi hálózatban használják a szoftvert mondjuk 10 munkaállomáson, és a lekérdezést a munkaállomások végzik (nem a szerveren futó job), akkor ez nektek 10 féle IP lesz a lekérdezésben vagy 1?

@nbeeps2
Szerintem (bár nem vagyok benne 100%-ig biztos) , de a saját routered, nem küldi ki a csomagban a belső címet(átírja a külső címre), csak a kapcsolatot(port,ip, belső ip) menti el. Ezért nem is tudják a másik oldalon megnézni, így csak a szolgáltatód által biztosított külső cím amit látnak. De tényleg sok szolgáltató nem ad rendes külső címet(kevés van, olcsóbb stb..) csak 1-et xxx ügyfélnek...
KOBAK-nál akartak valami ilyen megoldást, hogy fix ip címről lehessen csak bejelentkezni...

[nbeeps2]

@csaszko én is ettől tartok, pont azért kérdeztem, mert egy szimpla több felhasználós helyi hálózatnál már bele lehet majd futni az ilyen késleltetésekbe...

[nbeeps2]

"A forgalomkorlátozás életbe lépése után az említett végpontokon egy forrás IP-cím 1 másodperc alatt csak 1 kérést lesz képes beküldeni a szervernek. A limit túllépése esetén minden további kérés +4000 milliszekundum késleltetést kap az előző kéréshez képest. 60 másodperces késleltetés elérését követően az új kéréseket a rendszer nem szolgálja ki."

Itt a "halmazati büntetés" :) kapcsán nekem valami nem világos. Azt értem, hogy ha egyszerre 1 másodpercen belül 17 lekérdezést indítok, akkor a 17. elhal, a többi meg 0,4,8,12, stb. alatt válaszol.

Hogyan működik ebben az esetben?
12:27:01 mp -> lekérdezés -> válasz jön
12:27:01 mp -> újabb lekérdezés > válasz késleltetéssel 12:27:05 mp
12:27:02 mp -> újabb lekérdezés -> ITT MI A VÁLASZ? 12:27:02 vagy 12:27:05 vagy 12:27:09?

[EnokhSys]

@EnokhSys ezt én értem, hogy csak akkor teljes a beküldés, ha ellenőrizted és sikeres, de @NTCA-developer szerint ez hogy 1 perccel később tudod csak lekérdezni az adatszolgáltatás sikerességét, az nem gátol téged, csak késleltet, hogy ennek eleget tegyél. De persze én sem értek egyet ezzel az egésszel (késleltetés bevezetése), amit fent már több ízben megfogalmaztam.

Nézd, van igazság abban amit mond @NTCA-developer. de csak technikailag. Mind próbálom megvilágítani azt, hogy itt törvényi kötelezettségről van szó, és ezt nem lehet szándékosan, általánosan blokkolni akár csak 1 percig is, mert ebben az esetben a NAV egy széles társadalmi csoportot kényszerhelyzetbe hoz a törvényi kötelezettséggel szemben. CSAK(!) célzott megoldást lehet alkalmazni, azok ip-címek kiszűrésével, akik folyamatosan bombázzák kérésekkel a NAV-ot .

[EnokhSys]

@EnokhSys itt gondolom arra gondolt, hogy egy ilyen bürökratikus szervezetneél, mint a NAV, mire megfogalmaznak egy ilyen levelet, meg egyeztetnek a fejlesztőkkel, meg azok lefejlesztik és elküldik a felhasználóhoz az mind idő és ez nem akarják kijárni/kivárni.

@nbeeps2 Kénytelenek lesznek rá.

[Macskafarka]

Botrány ez az egész, jó lenne, ha a NAV is komolyan venné a kötelezettségét, és nem önkényeskedne, és nem keltené másoknak a rossz hírét.
Aki számláz, az NEM mehet haza, ameddig meg nem győződött arról, hogy teljesült az adatszolgáltatása. Ha ezt a NAV akadályozza, lassítja, akkor azzal jogszabályt szeg.
A 24/2013 NGM rendelet 13/A§ (3) bek: A számlázó programmal történő adatszolgáltatás akkor minősül teljesítettnek, ha az (1) bekezdés szerint történt a benyújtása, és a sikeres feldolgozást az állami adó- és vámhatóság rendszere visszaigazolta."
Tessék visszaigazolni. Azonnal. nem másnap, nem büntető idő után.

[alaplap]

Akkor jól értem, hogy ha egy adott IP-ről a kérések gyakorisága nagyobb, mint 1 másodperc, akkor sosem fog "büntető időt" kapni?

[pvmon]

@Macskafarka Bekövetkezett az amit már egyszer leírtál:
Ha a NAV azt mondja, hogy holnaptól kötelezően kell valami módosítás, akkor abban nem korlátozza semmilyen előírás, vagy törvény.

[alaplap]

[...] Egészen addig, amíg 1 perc csendet nem hagytál a lekérdezésekben.

@NTCA-developer Jól gondolom, hogy az "1 perc csendet" nem kell lekódolni, mivel a szerver által kapott tiltás eredményeként úgyis eltelik az 1 perc csend? Vagy ha a tiltás alatt is érkeznek kérések, akkor az 1 perc timeout mindig újraindul?

[EnokhSys]

Akkor jól értem, hogy ha egy adott IP-ről a kérések gyakorisága nagyobb, mint 1 másodperc, akkor sosem fog "büntető időt" kapni?

Persze! A leírás szerint itt azokkal van probléma, akiknek szarul müxik a programja, és folyamatosan nyomatják a requesteket. Viszont ez problémát okozhat olyan ip-címek esetén, amelyeken számos cég "osztozik", mert, amikor éppen mindenki számláz, akkor 1 mp-en belül több request is érkezhet be ugyanarról a címről.

[Macskafarka]

@pvmon Igen, szabadon megteheti akár azt is, hogy nem IP címre állít be korlátot, hanem szolgáltatóra. Pl. UPC-től, vagy a TELKOM hálózatából egy időegység alatt csak X forgalmat enged.

[NTCA-developer]

@csaszko

IP cím esetén, ha helyi hálózatban használják a szoftvert mondjuk 10 munkaállomáson, és a lekérdezést a munkaállomások végzik (nem a szerveren futó job), akkor ez nektek 10 féle IP lesz a lekérdezésben vagy 1?

1 akkor ha a default gateway címéről éri el mindenki a szervert. Ez a valószínűbb setup, hogy az alállomások egy címről lépnek ki a belső hálózatból.

@macskafarka Ezt ugye te sem gondolod komolyan. Miért ne mehetne haza? (és ahogy a példa mutatja, sokan haza is mennek) Az azonnaliság a beküldésre vonatkozik. Az eredmény feldolgozására nincs klauzula. Sosem volt! Műszakilag adódik, hogy ha 3 nap múlva lesz feldolgozva az adatszolgáltatás akkor 3 nap múlva lesz eredményed róla. Addig jogszabályt sért az adózó? Ne már.

@alaplap Jól érted. Azzal a kiegészítéssel, hogy ez is csak a státusz lekérdezésekre vonatkozik. A többi végponton egyáltalán semmilyen tiltás nincs, akármilyen gyakoriság mellett sem.

[alaplap]

Akkor jól értem, hogy ha egy adott IP-ről a kérések gyakorisága nagyobb, mint 1 másodperc, akkor sosem fog "büntető időt" kapni?

Persze! A leírás szerint itt azokkal van probléma, akiknek szarul müxik a programja, és folyamatosan nyomatják a requesteket. Viszont ez problémát okozhat olyan ip-címek esetén, amelyeken számos cég "osztozik", mert, amikor éppen mindenki számláz, akkor 1 mp-en belül több request is érkezhet be ugyanarról a címről.

Persze. A NAT-olt hálózat mögül érkező kérések ugyan arról az IP-ről érkezik és sok szolgáltató használ NAT-olt hálózatot. Másrészről a mi megoldásunk számlánként küldi a kéréseket, nincs "tömeges számlázás". Viszont egy (pl. tervezett) üzemszünet alatt felgyűlt adatszolgáltatások után előfordulhat, hogy egyszerre sok számla kerül benyújtásra, majd egyszerre sok számla státusza kerül lekérdezésre.

[pvmon]

@NTCA-developer Azt hiszem mi a tegnapi NAV email után nem adunk ki erre semmilyen frissítést, mert azt fogja gondolni az esetleg tegnapi emaillel megszólított ügyfél, hogy lám-lám mégiscsak a számlázó programban volt a hiba!
Abszolút rossz időzítés ez a korlátozás is!

[alaplap]

@NTCA-developer írta:

Ha jól számolom, akkor 1 másodpercen belüli időablakot nézve a másodiktól indul a késleltetés, tehát egy sec alatt egy forrás IP-ről 15+1 párhuzamos lekérdező szálat tudsz fenntartani.

@alaplap írta:

a mi megoldásunk számlánként küldi a kéréseket, nincs "tömeges számlázás". Viszont egy (pl. tervezett) üzemszünet alatt felgyűlt adatszolgáltatások után előfordulhat, hogy egyszerre sok számla kerül benyújtásra, majd egyszerre sok számla státusza kerül lekérdezésre.

Akkor ezek szerint ha felgyűlne pl. 100 számla, a jelenlegi programunk 2 percenként 16 számlát tudna lekérdezni, hiszen 16 lekérdezést tud lefuttatni 1 perc alatt, ami után jön az 1 perc csend. A 100 számla lekérdezése így zajlana:

1. perc: 16 számla
2. perc: csend
3. perc: 16 számla
4. perc: csend
5. perc: 16 számla
6. perc: csend
7. perc: 16 számla
8. perc: csend
9. perc: 16 számla
10. perc: csend
11. perc: 16 számla
12. perc: csend
13. perc: 4 számla

[Macskafarka]

@NTCA-developer r: "Az eredmény feldolgozására nincs klauzula. Sosem volt! "
-Ez igaz, és ez elég nagy baj. Az egyik oldalnak előírnak a jogszabályok valamit a másiknak meg nem. Aztán a másik ezt kihasználja.
Ma még nincs korlátozva a beküldés. Mondom "ma még". Az sincs benne a törvényben, hogy ne lehetne korlátozni azt is. A törvényeknek az lenne a célja, hogy szabályozzák az állam (hatóságok) és a gazdaság szereplőinek viszonyát. Éppen ez van kifordulva, az egyiknek a teendőit aprólékosan körülírt szabályok vonatkoznak a másikra nem.

[csaszko]

@alaplap
Ha nem párhuzamosan futtatod a lekérdezéseket, és arról az ip ről más gép/gépek nem kavarnak be, valamint 1mp megvan a lekérdezések között akkor nem fog korlátozni így 1 perc alatt 60 számlát tudsz lekérdezni. (ha párhuzamosan fut akkor az van kb amit írtál) .. szerintem.

[EnokhSys]

Akkor jól értem, hogy ha egy adott IP-ről a kérések gyakorisága nagyobb, mint 1 másodperc, akkor sosem fog "büntető időt" kapni?

Persze! A leírás szerint itt azokkal van probléma, akiknek szarul müxik a programja, és folyamatosan nyomatják a requesteket. Viszont ez problémát okozhat olyan ip-címek esetén, amelyeken számos cég "osztozik", mert, amikor éppen mindenki számláz, akkor 1 mp-en belül több request is érkezhet be ugyanarról a címről.

Persze. A NAT-olt hálózat mögül érkező kérések ugyan arról az IP-ről érkezik és sok szolgáltató használ NAT-olt hálózatot. Másrészről a mi megoldásunk számlánként küldi a kéréseket, nincs "tömeges számlázás". Viszont egy (pl. tervezett) üzemszünet alatt felgyűlt adatszolgáltatások után előfordulhat, hogy egyszerre sok számla kerül benyújtásra, majd egyszerre sok számla státusza kerül lekérdezésre.

@alaplap Én ezt úgy oldottam meg az egyik nagy partneremnél, akinél havonta több mint tízezer számla készül, hogy már 2018-ban beállítottam egy háttérszervert, ami éjjel-nappal müxik. Minden számlacsomag (tehát token-számlabeküldés-státuszlekérdezés) között legalább 10 mp delay van, ezzel percenként 6 számla beküldése és státusz-ellenőrzésére van lehetőség, ami óránként 360 számlát jelent. Amikor üzemszünet van, akkor ugyanilyen tempóban, óránként egyszer minden nem beküldött vagy nem befejezett számlát megpróbál elintézni, és csak akkor küld riasztást a helyi informatikusoknak (ők pedig nekem), ha 16-20 óra alatt sem sikerült valamely számlát beküldeni, vagy annak státuszát lekérdezni. A törvényi kötelezettség is 24 órát ír elő.

[Macskafarka]

Nekünk is hatékonyabb ügyfélkommunikációba kell kezdenünk. Elmondani az ügyfeleknek, hogy mi történik a háttérben.
A nyilvánosság lehet a megoldás.

[nbeeps2]

"IP cím esetén, ha helyi hálózatban használják a szoftvert mondjuk 10 munkaállomáson, és a lekérdezést a munkaállomások végzik (nem a szerveren futó job), akkor ez nektek 10 féle IP lesz a lekérdezésben vagy 1?"

1 akkor ha a default gateway címéről éri el mindenki a szervert. Ez a valószínűbb setup, hogy az alállomások egy címről lépnek ki a belső hálózatból.

@NTCA-developer : na itt a baj. Van egy jó, megfelelően megírt számlázó program, ami nem floodol, nem hívogatja 1 mp-nél sűrűbben a kérdéses végpontot, CSAKHOGY a programot több munkaállomáson is futtatják, és ahogy te is megírtad a NAV felé egy IP címen kommunikál az összes munkaállomás, így egy sima ilyen felállásnál is lassítva lesz (feleslegesen) a program működése a NAV által, mert 4-8-12-16-20-stb másodpercre befagyasztja majd a programot, míg az a NAV válaszra vár... Illetve szintén probléma még, hogy mondjuk az adott irodában (pl. könyvelőiroda) sok cég számlázását végzik a programmal, külön adatbázisokkal, több munkaállomáson. Itt is lassítva lesz a program működése a NAV által az IP blokkolás miatt...

Ez így semmiképpen nem jó, ne vezessétek be, kell legyen más megoldás.

[Rossi73]

@alaplap
Ha nem párhuzamosan futtatod a lekérdezéseket, és arról az ip ről más gép/gépek nem kavarnak be, valamint 1mp megvan a lekérdezések között akkor nem fog korlátozni így 1 perc alatt 60 számlát tudsz lekérdezni. (ha párhuzamosan fut akkor az van kb amit írtál) .. szerintem.

... mármint akkor, ha figyeled minden számla lekérdezésekor (és ugye figyelned kell), hogy az előzőt mikor küldted be, és ha már eltelt pontosan 1 mp, akkor indítod csak a következő lekérdezést. És ugye feltételezzük azt is, hogy a NAV válaszolt 1 mp-en belül. Mert ha az első lekérdezés csak 2 mp alatt zajlik le, akkor máris csak 30-at kérdezhetsz le...

Aztán azt se felejtsük el, hogy a NAV a saját rendszerébe való kérés beérkezési idejét veszi alapul. Ha közben a net sebessége vagy bármilyen terhelés/probléma miatt a második kérésed gyorsabb átfutási idővel ér be, mint az első, akkor máris bukott a mutatvány. Például:

1. lekérdezés:
   Indítod: 18:00:00.000-kor
   Beérkezik a NAV-hoz 140 ms alatt: 18:00:00.140-kor
   NAV feldolgozza 500 ms alatt
   NAV visszaküldi a választ 18:00:00.640-kor
   Válasz megérkezik 100 ms alatt: 18:00:00.740-kor

A ciklus (timer, bármi) vár (és ugye ennek a működését is optimalizálni kell...), amíg 18:00:01.000 lesz, majd indítja a következő lekérdezést:

1. lekérdezés:
   Indítod: 18:00:01.000-kor
   Beérkezik a NAV-hoz 139 ms alatt: 18:00:01.139-kor
   NAV észleli, hogy 1000 ms-on belül volt másik kérés, ezért a választ majd 4000 ms múlva adja vissza
   NAV feldolgozza 500 ms alatt
   NAV visszaküldi a választ az eredeti 18:00:01:639 helyett 18:00:05:639-kor
   Válasz megérkezik 100 ms alatt: 18:00:05:739-kor

@NTCA-developer : Ez a gyakorlatban tehát valahogy így fog történni?

[nbeeps2]

@Rossi73 hát ha ez így van, már pedig logikus, akkor jobb inkább 2 másodpercet várni és kizárni a msec "utazó" sebességet a képletből :)

[nbeeps2]

A gond az, hogy mindez a jelenlegi ismeretek alapján holnap élesedik és fogalmunk sincs, hogy a gyakorlatban ez majd kinél-mit fog okozni, így hétfőn majd rettegek bemenni a munkahelyre, hogy mi vár ránk...

[EnokhSys]

A gond az, hogy mindez a jelenlegi ismeretek alapján holnap élesedik és fogalmunk sincs, hogy a gyakorlatban ez majd kinél-mit fog okozni, így hétfőn majd rettegek bemenni a munkahelyre, hogy mi vár ránk...

Nézd, ahogy többen is írták, itt csak a közös külső ip-cím használóknál lehet gond, az 1 mp-es késleltetés a normálisan működő szoftverek esetében nem jelenthet gondot. Amúgy meg ne rettegj, vasárnap este igyál egy-két pohár pálinkát. :-))

[nbeeps2]

@EnokhSys én nem ezt vettem ki @NTCA-developer válaszából. Ha egy programot több munkaállomáson is használnak az egy IP címnek számít, már pedig ez igen gyakori felhasználás. A téma indító EPluribusUnum meg kvázi meg fog állni a teljes rendszere...

[EnokhSys]

Egyébként itt igazán a NAV fejlesztői csapatnak lehet ebből gondja, mert ezzel az "általános módszerrel" jogilag támadási felületet nyitnak maguk ellen, és ahogy elnézem az MKOE viszonyulását, akár ki is használhatják ezt egy kis jogi csatározásra.

[EnokhSys]

@EnokhSys én nem ezt vettem ki @NTCA-developer válaszából. Ha egy programot több munkaállomáson is használnak az egy IP címnek számít, már pedig ez igen gyakori felhasználás. A téma indító EPluribusUnum meg kvázi meg fog állni a teljes rendszere...

Igen, ez is benne van, a lényeg az egy külső ip-címről, de különböző belső hálózaton működő cégektől/felhasználóktól/számlázóprogramoktól érkező egyidejű requestek.

[nbeeps2]

@EnokhSys több ezer ilyen felhasználónk van...

[nbeeps2]

Ha NAV nem biztosítja a megfelelő felkészülési időt (már pedig, ha szerdán kijelentik, hogy csütörtökön bevezetnek valamit az bőven kimeríti ezt) és emiatt a meglévő szoftver a felhasználóknál tömegesen nem megfelelően fog működni (pl. hosszú másodpercekre lefagy vagy várakoztatja az ügyfeleket) és emiatt ebből nekünk kárunk keletkezik (pl. az ügyfél elmegy máshová, lecseréli a programot vagy megbénítják az ügyfélszolgálatot a hívásaikkal stb.), akkor az ügyet jogi útra fogjuk terelni.

[EnokhSys]

@EnokhSys több ezer ilyen felhasználónk van...

Nem tudtok csinálni egy olyan scriptet a külső routernél/tűzfalnál/stb., hogy a NAV felé irányuló kérések 1 mp.-es késésekkel kerüljenek kiküldésre?

[nbeeps2]

A program megfelelően van megírva, nem szükséges azt átírni, ez kliens oldalon nem leprogramozható. A program önmagában nem komminukál egy másodpercnél sűrűbben a NAV-val.

[EnokhSys]

A program megfelelően van megírva, nem szükséges azt átírni, ez kliens oldalon nem leprogramozható.

Nem a kliens programról beszélek, hanem a kimenő hálózati forgalomról, amit a hálózati rendszergazda állítana be a NAV-szerver ip-címére.

[nbeeps2]

@EnokhSys : nem járható út. Nem végzünk IT feladatokat, nem konfiguráljuk az ügyfelek hálózatait, több ezer ügyfélnél lehetetlen is lenne ráadásul mindezt holnapig megoldani. Az ügyfelek többségének sincs rendszergazdája.

[EnokhSys]

@EnokhSys : nem járható út. Nem végzünk IT feladatokat, nem konfiguráljuk az ügyfelek hálózatait, több ezer ügyfélnél lehetetlen is lenne ráadásul mindezt holnapig megoldani. Az ügyfelek többségének sincs rendszergazdája.

Oké értem, tehát nem hozzátok, egy központi szerverre futnak be a számlák, amelyeket továbbítani kell a NAV felé.
Akkor, hogy tisztán értsem a problémát: a több ezer ügyfélből hány olyan ügyfeletek van, akiknél egyszerre több felhasználó számláz egyidőben?

[Macskafarka]

Igaza van @nbeeps2 -nek. Ha a számlázó program nem kommunikál 1 mp-nél gyakrabban, akkor a NAV lesz a ludas. Aztán majd jöjjön az IP címmel. Tudtommal a vonatkozó jogszabályokban adóalanyok vannak és nem IP címek!

[nbeeps2]

@EnokhSys : nem több ezer ügyfelünk van, hanem jóval több ;) A több ezer ügyfél az, aki hálózatosan használja egyidőben...

[Macskafarka]

@EPluribusUnum eredeti felvetésében is benne volt az elfogadható megoldás: IP cím + Adószám.
Ezek után nincs miről beszélni, ezt kell támogatni.

[nbeeps2]

@Macskafarka igen, az IP cím + Adószám az neki megoldás lehet, számomra viszont az sem elegendő. Ez a több ezer ügyfél akiről beszélek, úgy használják a programot, hogy 1 adószám alatt számláz 10 munkaállomás. A munkaállomások egymástól független kérdezgetik küldik be a számlákat és kérdezgetik le a státuszokat, nyilván mindegyik csak azt, ami még nyitott, tehát nem küldenek be többször ugyanazt a számlát és nem is kérdezik le többször ugyanannak a státuszát. Viszont az simán előfordulhat és a mi logunkban belenézve elő is fordul, hogy több státuszlekérdezés mondjuk 10 munkaállomás miatt pont egymásodpercen belül esik. Ez ebből az egyik mondjuk a 32/2020-as számla a másik meg a 33/2020-as számla, tehát én azt mondanám, hogy az 1mp-en belüli IP+ADÓSZÁM+SZÁMLASZÁM lenne max az elfogadható blokkolás.

@NTCA-developer : szóval ezt miért kell blokkolni?
MUNKAÁLLOMÁS1: IP: 111.111.1.111 , Adószám: 12345677, Számlaszám: 1/2020, státusz lekérdezés: 14:53:01
MUNKAÁLLOMÁS2: IP: 111.111.1.111 , Adószám: 12345677, Számlaszám: 2/2020, státusz lekérdezés: 14:53:01
MUNKAÁLLOMÁS3: IP: 111.111.1.111 , Adószám: 12345677, Számlaszám: 3/2020, státusz lekérdezés: 14:53:01

[Macskafarka]

Az adószámot nem lehet kihagyni, ez az alapja az adatszolgáltatásnak! Az IP cím, meg a bolygó @@együttállások, meg a prímszámok belekeverése csak parasztvakítás.

[Macskafarka]

@nbeeps2 Igazad van IP+ADÓSZÁM+SZÁMLASZÁM lenne max az elfogadható blokkolás

[EnokhSys]

@EnokhSys : nem több ezer ügyfelünk van, hanem jóval több ;) A több ezer ügyfél az, aki hálózatosan használja egyidőben...

@nbeeps2 Még akkor is, ha egyszerre két-három-...-tíz felhasználó 1 mp-en belül kérdez le két számlát, kicsi a valószínűsége annak, hogy ez 4 mp múlva megismétlődjön. Tehát még húsz felhasználónál is csekély annak az esélye, hogy abba a FOLYAMATOS 4-mpes láncolatba beessen az adott ip-cím, és eljusson az 1 perces tiltásig. Tehát érted, mire akarok kilyukadni, a veszélyt itt nem abban látom, ha egyszerre tíz-húsz felhasználó számláz, mert, ha elő is fordul 1 mp-ben belüli kérés, a 4 mp-es folyamatláncba kevés az esély, hogy beleesnek.

[Macskafarka]

Ezért lenne jó szélesebb körben megbeszélni, és nem önkényesen azonnal bevezetni valamit.

[nbeeps2]

@EnokhSys hát én remélem, hogy neked lesz igazad.

[Rossi73]

@nbeeps2 Igazad van IP+ADÓSZÁM+SZÁMLASZÁM lenne max az elfogadható blokkolás

Azt mondta a NAV részéről valaki, hogy a problémát az okozza, hogy egy IP címről ugyanarra a tranzakcióra végeznek lekérdezéseket 1 mp alatt többször, amíg nem lesz pl. "DONE"? Mert ha igen, akkor a felvetésetek rendben, de ha a NAV-ot "csak" az zavarja, hogy egy IP címről 1 mp alatt egy csomó lekérdezés érkezik, és nem az, hogy konkrétan egy adott tranzakcióra kérdeznek le többször 1 mp alatt, akkor a fenti ötlet is bukta sajnos. :(

[nbeeps2]

@Rossi73 értem, amit akarsz ezzel mondani, viszont én is konkrét példákkal alátámasztottam, hogy egy IP címről 1sec alatt érkezhet "legálisan" (nem flood) több status lekérdezés is, és ezeket jó lenne szétválasztani a flood felhasználóktól, e kapcsán ötleteltünk. A valódi megoldást továbbra is abban látom, hogy nem vezetnek be semmilyen ilyen késleltetést, hanem a softwareID alapján megkeresik a (flood) gyártókat és felszólítják őket a program átírására egy megadott határidővel.

[EnokhSys]

Azt mondta a NAV részéről valaki, hogy a problémát az okozza, hogy egy IP címről ugyanarra a tranzakcióra végeznek lekérdezéseket 1 mp alatt többször, amíg nem lesz pl. "DONE"?

Olyan ez mint a Cola-automata: addig püföli, amíg ki nem adja. :-))

[tkelemen73]

Van olyan ügyfelünk, ahol augusztus 11 óta van PROCESSING státuszban egy tranzakció azonosító, abban 100 db számla. A státusz lekérdező job futásakor ez az első tranzakcióazonosító, amire rákérdez a program, most már több, mint 2 hónapja. ERP rendszer, így a központi szerver IP címéről fogja indítani a státusz lekérdezést, egymás után, több szálon indítva az előző státusz lekérdezés óta elkészült, akár 3-400 tranzakció azonosítóra is. Mivel a 2 hónapja még mindig PROCESSING stáruszban lévő tranzakcióra már rákérdeztünk, ezért a többi szálon érkező státusz lekérdezéseket nem fogjuk tudni megkapni munkaidőben, csak munkaidőn kívül, ha jól értelmezzük a leírtakat. Amennyiben ezek között, az elkaszált státusz lekérdezések között olyan tranzakció azonosítóval beküldött számla van, aminél a felhasználó rájött, hogy téves, ezért azt stornózza vagy akár helyesbíti is, a módosító számla már nem fog tudni bemenni, mivel az eredetinél nincs visszaigazolt DONE státusz, ezért a módosító számla már ABORTED státusszal fog visszajönni, már amikor a státusz lekérdezés le fog tudni futni. Akkor tudna működni biztonsággal, ha a módosító számláknál a státusz lekérdezés helyett valamelyik számla lekérdezést használnánk, de azzal nem nagyobb terhelést okoznánk odaát? Minden kérés/válasz letárolásra kerül, így a munkaidőben indított minden státusz lekérdezés gyakorlatilag felesleges szemetet termel a szerveren a logokban, és majd csak a munkaidő végeztével lesz hasznos. Nem tűnik túl hatékonynak. A tesztrendszeren mikor lesz elérhető ez a verzió, mert nagyon hasznos lenne mindenki számára (mindkét oldali fejlesztő számára), hogy tapasztalatokat gyűjtsön. Sokat segítene az is terhelés szempontjából, ha nem lenne olyan tranzakció, amire 2 hónap után is PROCESSING státusz jön csak vissza...

[Macskafarka]

@tkelemen73 Hiszen az @NTCA-developer megmondta azt, hogy az adatszolgáltatásra van határidő, viszont a feldolgozásra nincs. És ez nekik így jó.
Ebből az következik, hogyha a módosító vagy érvénytelenítő számlát nem küldi be a számlázó program az jogilag a számlázó program hibája, vagyis pellengérre lehet állítani, kidobolni, az ügyfeleket e-mailekkel értesíteni stb.
Ezért lenne jó jogszabállyal szabályozni a feldolgozási időt is, netán szankcionálni az idő túllépést.

[rgform]

Azért NTCA Developer néha beszélhetne NTCA TAX-al. Mert Ő meg ezzel indokolja válaszát egy másik esetben:

"A státusz lekérdezés egy olyan jogszabályi kötelezettség, amely bármely adatszolgáltatás jogszerű teljesítéséhez szükséges. A státusz lekérdezés nélkül nem jutnak el például a warning jelzések az adózókhoz."

De arról nem szól, hogy ezt lehet akár 3 nap műlva is...

[Rossi73]

Szerintem akkor tegyük fel a kérdést a másik NAV-os kollégának:

Kedves @NTCA-tax ! Mi a NAV hivatalos álláspontja azzal kapcsolatban, hogy a tranzakcióadatok lekérdezésének mennyi időn belül kell megtörténnie? Elfogadható, ha bármilyen okból nem "azonnal", hanem csak x egység múlva (egység = másodperc/perc/óra/nap/hét)? A NAV által bő 24 óra múlva bevezetendő működés miatt fontos lenne tudni, hogy mi az, amit megvalósíthatunk, ami még belefér (megfelel) mind a NAV-nak, mind a jogszabálynak, mind az ellenőröknek.

Egyúttal az is felmerül kérdésként, hogy a jogszabály szövegét szigorúan alapul véve, valóban megbüntethet a NAV egy olyan adózót, akinek van bent pl. havi 200 számlája, mind OK státusszal, de ezek közül mondjuk 10-et nem kérdez le? (Félreértés ne essék: természetesen nem azt erősítem, hogy "hagyjuk a lekérdezést a fenébe, úgyis mindig DONE jön vissza").

Ehhez kapcsolódik: ha a korábban említett statisztikai oldalon, ha azt látja egy adózó, hogy volt 200 számlája egy hónapban, és 10 olyan, amit "nem kérdezett le" (nekünk is volt ilyen - szept. 7. előtt!), akkor úgy jár el helyesen, ha ismét lekérdezi az összes számla státuszát, ezzel mind a 200 megfelelő státuszt kap? Ez a helyes eljárás ilyenkor? Ha nem, akkor mi? Esetleg: meg lehet tudni valahonnan azt, hogy melyik az a 10 számla, amelyiket - a NAV szerint - "nem kérdezett le"?

A válaszokat előre is köszönjük.

[Macskafarka]

Jó kérdések! Érdeklődéssel várom @NTCA-tax válaszait.

[bcdel]

Az alap performanciaproblémák és a hibás elven működő programok problémáját alapvetően értem.
De azért próbálok olvasni, mielőtt írok:

'...60 másodperces késleltetés elérését követően az új kéréseket a rendszer nem szolgálja ki...'

És miután ez lenne a dokumentált működés. Arról nincs info, hogy lesz-e valaha ennek a 'nem szolgálja ki' állapotnak bármikor bármilyen feltétel szerinti feloldása, vagy a számlázóprogram keressen magának másik IP címet.

Ezt a feloldási feltételt (időt) dokumentálni kellene. Pontosan, egyértelműen hogy ez alapján a fejlesztők eldönthessék, hogy a programjuk hogyan fog működni az új környezetben. Eddig az volt nagyjból a dokumentált működés, hogy 200 msec, de maximum 5 sec (üzemzavaroktól és leállásoktól eltekintve). Amíg ez nincs dokumentálva, addig ezt úgy lehet értelmezni, hogy az ilyen IP címek disqualifikálva lesznek az adatszolgáltatás státuslekérdezésének lehetőségétől. Végleg.

Dokumentáció alatt megfelelő közleményt értek, a github nem tekinthető ilyen értelemben a megfelelő fórumnak.

---

Ez az IP cím alapján történő döntés megoldhatatlan helyzet elé állítja a párhuzamosan működő (elosztott) rendszereket. (Akár egy vagy több ügyfél vagy software). Nem nagyon van olyan technologia amivel hatékonyan lehetne egy random REST klienst rábeszélni arra, hogy közös IP címen működő más REST kliensekkel közös timeout erőforrással gazdálkodjanak.
Elég komoly biztonsági kockázatot is hordoz magában, csak a gondolat, hogy különböző rendszerek egymással (akárcsak ilyen célból is) együttműködjenek.

---

Néha teljesen normálisan akár egy kisebb cég is számlázhat egyszerre néhány tucat számlát (pl. Havi díj) Ekkor a lekérdezés is nagyjából egyszerre fog jelentkezni. Erre a specifikáció 1.0-1.1-2.0 vonulatán átívelő REST-API dokumentációk esetén nyomokban sem tartalmazott semmiféle terhelésenyhitő törekvést az ilyen operációk esetén, ezért a fejlesztők elfogadhatóan nem optimalizáltak erre semennyire. Nyilván ennek a spektumnak a rosszabbik vége az ami túlterheli a NAV-ot.

Illetve ebből a szempontból irreleváns, hogy 20 számlát kérdeznék le egyenként egymás után, vagy 2000-et (20 tranzakcióból)
Mindkettő üzemszerüen fog megakadni.

[Macskafarka]

1. A lekérdezés az adatszolgáltatás része a NGM rendelet szerint.
2. A NAV-nak az a kötelessége, hogy ezt kiszolgálja
3. A "nem szolgálja ki" és a lassítás nem más, mint szabotázzsal fenyegetés
4. A számlázó programok nem gazdálkodnak IP címekkel, azok hatáskörén kívül helyezkedik el.
5. Az IP címekre vonatkozó feltételek támasztása túllépi a törvényben írt lehetőségeket
6. A gyors bevezetés nem más, mint hatósági önkény.
7. A dokumentálás, amit @bcdel említ, csak jogszabályban fogadható el. Ha a NAV leír valamit, azt bármikor meg is változtathatja (ahogy ezt folyamatosan meg is teszi). Itt két fél viszonyáról van szó, amit külső eszközökkel kell szabályozni. Ezen eszközt hívják jogszabálynak.
8. A jogszabály változás esetére van felkészülési idő, az soha nem az egyik fél ultimátuma

[rgform]

Üdv!
Egy darabig gondolkodtam, hogy ide való-e, de egy bejegyzés meggyőzött róla. A doksiban megjelent - különösebb magyarázat nélkül - a queryTransactionList - ben a requestStatus. Amiről először azt hittük hibás, mert pl. DONE helyett FINISHED van.
Ez viszont - ha valóban így kell értelmezni megvilágosított:
https://github.com/nav-gov-hu/Online-Invoice/issues/440(url)

Ezek szerint, ha pl. óránként lekérdeznék a beküldött számlák (tranzakciók) listáját, elég lenne a FINISHED státuszukról queryTransactionStatust kérni az invoiceStatus - DONE válaszhoz? Vagyis ez egy "kvázi értesítés" a NAV-tól, hogy lehet lekérdezni, már van feldolgozási státusza?

Ha így van miért nem ezt publikálják, a lassítás helyett? Ugyanis ez a végpont pl. nincs tervezve lassítani?!

UPDATE:közben itt is megtaláltam, jól titkolják

https://github.com/nav-gov-hu/Online-Invoice/issues/412(url)

[Macskafarka]

@rgform Szerintem nagyon is ide való, és előrébb viszi a gondolkodásunkat.
Viszont jó lenne ezt intézményesíteni, mivel a jogszabályilag a számla adatszolgáltatás a kötelezettsége a számlázó programoknak, de mintha a NAV ezt úgy értelmezné, hogy a számla invoiceStatus=DONE státusz mellett a transaction/requestStatus -nak a megfelelő állapota való eljuttatása is kötelezettség lenne.
Ha jól értem akkor lényegében erről szólt az az e-mail, amit a NAV minap küldözgetett a felhasználóknak.
Még egyszer mondom: Azt, hogy mi a feladat, azt nem nekünk kellene kitalálnunk, és nem a GitHub-on elcsípett megjegyzésekből kiokoskodnunk, hanem világos, egyértelmű szabályok kellenek!

[nbeeps2]

Nem emlékszem, hogy bármelyik github topik ekkorát ment volna hozzászólásokban és mivel úgy látom, hogy az összes fejlesztő ellene van és nagy a tiltakozás, így nagyon remélem, hogy ez az IP-s dolog nem kerül ma bevezetésre.

[szecsenyizoltan]

Kifejezetten örülök a kezdeményezésnek, mert így nem kell mások miatt szívni. Ezzel egyidejűleg sokkal jobb lenne, ha nem kellene egyből beküldeni a számlát, hanem megkapná egy helyi sorkezelő/ütemező.

[rgform]

Tudom naivság részemről azt hinni, hogy a javaslataink bekerülnének a rendszerbe, de ha a NAV már megcsinálta ezt a - tulajdonképpeni csoportos - státusz lekérdezést, akkor már csak egy kicsit kéne szerveznie rajta.

Mi lenne ha a DONE invoicestatusu számlak pl. FINISHED_DONE státuszt kapnának? Akkor azokat nem kérdezném már le, az automatikusan befogadott, lekérdezett lenne? NTCA-TAX szerint úgyis elsősorban a WARN miatt kell lekérdezni. Akkor máris elég lenne egy listás lekérdezés, és a pár darab "sima FINISHED"-re kellene csak queryTransactionStatus. Ez ugye csökkentené a terhelést, vagy rosszul gondolom?

Tudom ez túl logikus, ahhoz hogy bevezethető legyen.. :-)

[rtoth0407]

Olyan jogszabályt kell alkotni amely lehetővé teszi a tömegesen felesleges kéréseket generáló számlázó programokat használó adózók büntetését. A NAV ugyanis pontosan látja, hogy mely cégektől érkeznek ezek.

Nem azokat kell büntetni akik jogkövető módon és performancia szempontok figyelembe vételével jó rendszert készítettek. Ne felejtsétek, hogy jövőre még sokkal több számlát kell beküldeni, és el fognak indulni a vevő oldali számla lekérdezések is, vagyis a terhelés egyre nagyobb lesz a NAV rendszerén. A lassítás nem modern megoldás.

[EnokhSys]

Nem emlékszem, hogy bármelyik github topik ekkorát ment volna hozzászólásokban és mivel úgy látom, hogy az összes fejlesztő ellene van és nagy a tiltakozás, így nagyon remélem, hogy ez az IP-s dolog nem kerül ma bevezetésre.

Én mindig megpróbálom igazságosan szemlélni a dolgokat, ezért csak részben vagyok ellene. Egyetértek pl. azzal, hogy ugyanarról az ip.címről csak egy kérést lehessen kiszolgálni 1 mp. alatt, és bizonyos mértékig a 4 mp-es lassítással is. Az 1 perc utáni 1 perces tiltással viszont csak úgy értenék egyet, ha az nem automatikusan történne, hanem konkrét emberi vizsgálat után egy "fekete-listára" kerülne az ip-cím.
Tehát látni kell azt, hogy a NAV-nak is kezdenie kell valamit a nem megfelelően megírt programokkal, mert, ha jól értem a közlésükből, a legutóbbi két napos leállás ennek a felesleges túlterhelésnek volt köszönhető. Ezt pedig az egész ország megszívta.

[Macskafarka]

Aggasztó, hogy rendszerszinten bele van helyezve egy olyan csapda is, hogy nem tudja teljesíteni az adatszolgáltatási kötelezettségét a számlázó egy módosító vagy érvénytelenítő bizonylatról, ameddig nem kapta vissza az eredeti számla státuszát. A feldolgozásra meg ugyebár nincs határidő, ergo korlátlanul elhúzható. Közbe a cég meg is szűnhet, vagyis mire megvan a feldolgozás, már nem él az adószáma.
Erre ki kellene térni a jogszabályban.

[EnokhSys]

Aggasztó, hogy rendszerszinten bele van helyezve egy olyan csapda is, hogy nem tudja teljesíteni az adatszolgáltatási kötelezettségét a számlázó egy módosító vagy érvénytelenítő bizonylatról, ameddig nem kapta vissza az eredeti számla státuszát. A feldolgozásra meg ugyebár nincs határidő, ergo korlátlanul elhúzható. Közbe a cég meg is szűnhet, vagyis mire megvan a feldolgozás, már nem él az adószáma.
Erre ki kellene térni a jogszabályban.

Lehet, hogy elvétve előfordul olyan, hogy valamely számla nem kapja meg a "DONE" vagy az "ABORTED" státuszt, de én a két év alatt, a partnereim által több mint százezer beküldött számlánál nem emléxem, hogy lett volna ilyen.
Viszont az általad említett ritka esetre is van szükségmegoldás: létre kell hozzon a felhasználó egy negatív számlát (azaz számlával egy tekintet alá eső okiratot) hivatkozás nélkül (erre mindenképp jönni fog egy warning üzenet), és a számla megjegyzésbe szövegesen kell beírja azt, hogy milyen számlát stornóz, helyesbít.

[Macskafarka]

@EnokhSys Ha kezdeni kell valamit ezzel a helyzettel, azt jogszabályba kell tenni, Olyan NINCS, hogy a NAV elkezd önkényesen szabotálni valamit. Adójogilag elég nehezen kezelhető az IP cím fogalma. Lehetetlen olyant előírni a számlázó programoknak, amelyre nincs ráhatásuk.

[Macskafarka]

Példával illusztrálva: Ha nincs szabályozva a gyorshajtás jogilag, akkor nem dönthet úgy a boltos, hogy akit látott tegnap gyorshajtani, annak nem ad el kenyeret. Előbb jogszabályba kell foglalni a gyorshajtás tilalmát, majd fel kell állítani egy ellenőrző szervet, akinek az a dolga, hogy megkeresse, azonosítsa a gyorshajtót. Először figyelmeztetéssel.
Most a NAV a túlbuzgó boltos szerepében tündököl, és ez a baj.

[rtoth0407]

Nem lehet egyetérteni az IP címenként és másodpercenként 1 kérés kiszolgálásával. Felhő alapú rendszereknél ez egyszerűen kivitelezhetetlen.
A másik probléma a gyors bevezetés. 2 napos határidővel nem lehet a rendszereket átírni. Egy ilyen léptékű változtatáshoz több hónapnyi időt kell adni.

[Macskafarka]

Figyelmen kívül lett hagyva, hogy a számlázó programok forgalmazói és felhasználói között polgárjogi szerződések vannak. Ha a feltételek megváltoznak, akkor ez a szerződéses viszonyt is érinti. Pl. ha a felhasználó elvárja a gyors adatszolgáltatás és a lekérdezést, és a számlázó prg forgalmazó ismeri a számlák nagyságrendjét, és a IP címre vonatkozó megszorításokat, akkor mondhatná azt a szerződésben a vevőjének, hogy akkor tudom biztonsággal teljesíteni az adatszolgáltatásodat, ha ehhez X db IP címet biztosítasz.

[nbeeps2]

@rtoth0407 Igen, kíváncsi vagyok a szamlazz.hu nál mi fog történni ma este 6 után... 385 ezer felhasználónál mire minden számla státuszát le tudják kérni az IP késleltetés, blokkolás mellett....

[csaszko]

@nbeeps2 nem baj, majd a nav küldözgetheti a leveleket újra... előbb utóbb csak spammerként jelöli meg minden szolgáltató őket...

[EnokhSys]

Példával illusztrálva: Ha nincs szabályozva a gyorshajtás jogilag, akkor nem dönthet úgy a boltos, hogy akit látott tegnap gyorshajtani, annak nem ad el kenyeret. Előbb jogszabályba kell foglalni a gyorshajtás tilalmát, majd fel kell állítani egy ellenőrző szervet, akinek az a dolga, hogy megkeresse, azonosítsa a gyorshajtót. Először figyelmeztetéssel.
Most a NAV a túlbuzgó boltos szerepében tündököl, és ez a baj.

@Macskafarka van igazság abban amit írsz, de én nem annyira túlbuzgóságot érzek a NAV részéről, hanem ideges kapkodást. Ez a gyors-, a közléstől számítva alig több mint 1 napos bevezetés arra utal, hogy nagyon gyorsan kezdeni akarnak valamit a helyzettel, nehogy megismétlődjön az a két napos leállás. Őket is meg lehet érteni, az ő s.ggüket fogják rugdosni. Mindannyian informatikusok/fejlesztők vagyunk, legalább mi próbáljuk meg jobban megérteni egymás problémáit. Biztos vagyok benne, hogy ezt az agyatlanságot, hogy július 1-től minden számlát be kell küldeni, nem egy NAV informatikus találta ki, hanem fentről jött ukáz-jogszabályba... ahelyett, hogy az értékhatárt csökkentették volna tovább, betartva a fokozatosság aranyszabályát. Na ennek isszuk mi-, azaz felhasználói szoftverfejlesztők és NAV informatikusok a levét.

[nbeeps2]

Akkor egy kis matek: a szamlazz.hu havi cirka 3.500.000 számla keletkezik, vagyis naponta kb. 140 000 (25-el osztottam, mert hétvégén nyilván kevesebbet számláznak). Az ügyfelek külön számláznak a többiektől, tehát nem batch-be mehet be a legtöbb számla. Ha csak másodpercenként lehet lekérni ezek státuszát és el akarják kerülni a késleltetést, akkor ez 140 000 másodperc = 2333 perc = 39 óra...

[szako]

@NTCA-developer: Teszteljük a javításunkat a késleltetésre a teszt-ben és tapasztalunk néha 4 másodperces válaszidőket és ritkábban 503-as hibákat (No server is available to handle this request). Esetleg már bekapcsoltátok vagy csak ingadozik a válaszidő?

[NTCA-developer]

@szako

EDU-n már tegnap óta be van kapcsolva, igen. Közben állunk az élessel, nézzük.

[EnokhSys]

Akkor egy kis matek: a szamlazz.hu havi cirka 3.500.000 számla keletkezik, vagyis naponta kb. 140 000 (25-el osztottam, mert hétvégén nyilván kevesebbet számláznak). Az ügyfelek külön számláznak a többiektől, tehát nem batch-be mehet be a legtöbb számla. Ha csak másodpercenként lehet lekérni ezek státuszát és el akarják kerülni a késleltetést, akkor ez 140 000 másodperc = 2333 perc = 39 óra...

@nbeeps2 Nade gondolom nem a szamlazz.hu ip.címéről mennek a számlák a NAV felé, hanem mindenkinek a saját ip.címéről, nem?

[nbeeps2]

@EnokhSys azt én nem tudhatom. Lehet központilag küldik, mert a felhő alapú rendszer intéz mindent. Erről szól a topik nyitó is.

[csaszko]

@EnokhSys
Ebben én is biztos vagyok amit írsz, hogy nem ők találták ki. Az ő feladatuk az lett volna, hogy szólnak és harcolnak ha kell... emberek ezt talán mégsem így kellene kezdjünk már értelmes dolgokat csinálni és a jogszabályokat alakítani a valósághoz, nem pedig valóságot az torzítani a hülyeséghez.. Amikor minden egyértelműen minden számára ugyanúgy értelmezhető szabályokkal le van fedve akkor lehet nekiállni.. jaaa vagy akkor nem minket szórakoztatnának évek óta és teszteltetnék a messze nem kész rendszereket, hogy ezt most így adjuk meg... azt meg úgy... ja mégsem inkább amúgy... de most akkor emeljük ki... de majd nem most majd a következő verzióban már így lesz.. stb stb.. már nagyon unom az egészet.

[pvmon]

Megint lehaltak. Ezért akarnak korlátozni...Nincs más választásuk. Nem tudják fogadni amit kértek.
Aztán megint megy a levél az ügyfeleknek, amiben persze nem fog szerepelni, hányszor állt a NAV szervere októberben.

Már jönnek is telefonok, készülhetünk rá.

[EnokhSys]

@EnokhSys azt én nem tudhatom. Lehet központilag küldik, mert a felhő alapú rendszer intéz mindent. Erről szól a topik nyitó is.

@nbeeps2 szerintem azt biztos jelezték volna a NAV-nak, hiszen ekkora párhuzamos felhasználószámmal, még akkor is, ha 100 ip.címről mennének be a lekérdezési kérések, beleütköznének az új szabályba.

[csaszko]

Akkor egy kis matek: a szamlazz.hu havi cirka 3.500.000 számla keletkezik, vagyis naponta kb. 140 000 (25-el osztottam, mert hétvégén nyilván kevesebbet számláznak). Az ügyfelek külön számláznak a többiektől, tehát nem batch-be mehet be a legtöbb számla. Ha csak másodpercenként lehet lekérni ezek státuszát és el akarják kerülni a késleltetést, akkor ez 140 000 másodperc = 2333 perc = 39 óra...

@nbeeps2 Nade gondolom nem a szamlazz.hu ip.címéről mennek a számlák a NAV felé, hanem mindenkinek a saját ip.címéről, nem?

Nem ismerem a rendszert, de biztos nem a kliensekre bízzák az adatszolgáltatást.. hogyan is tehetnék, elkészül a számla akkor bezárja a böngészőt és akkor adatszolgáltatással mi van... 100%, hogy 1 vagy max 1-2 címről küldik ők is. központosítva

[MiskaPista]

Akkor egy kis matek: a szamlazz.hu havi cirka 3.500.000 számla keletkezik, vagyis naponta kb. 140 000 (25-el osztottam, mert hétvégén nyilván kevesebbet számláznak). Az ügyfelek külön számláznak a többiektől, tehát nem batch-be mehet be a legtöbb számla. Ha csak másodpercenként lehet lekérni ezek státuszát és el akarják kerülni a késleltetést, akkor ez 140 000 másodperc = 2333 perc = 39 óra...

Tegnapelőtt 75000-et kérdeztek le... szóval fő a fejük ott is :/

[csaszko]

Ezt az ip blokkolást, mindenkire nézve nagyon gyorsan el kellene felejteni...biztos nem lenne nehéz megállapítani, hogy milyen címekről jön a rengeteg kérés... és csak azokra alkalmazni ezt a csodamegoldást.

[NTCA-developer]

Nyugi urak. Most épp ezt jól kezeljük. A helpdesk már fel lett hívva, nem mondják hogy megy a rendszer falsba. Hír is lesz kint mindjárt a felületen. Letörés van, ez épp nem forgalom okozta terhelés miatt történik.

[EnokhSys]

@EnokhSys
Ebben én is biztos vagyok amit írsz, hogy nem ők találták ki. Az ő feladatuk az lett volna, hogy szólnak és harcolnak ha kell... emberek ezt talán mégsem így kellene kezdjünk már értelmes dolgokat csinálni és a jogszabályokat alakítani a valóságot, nem pedig valóságot az torzítani a hülyeséghez.. Amikor minden egyértelműen minden számára ugyanúgy értelmezhető szabályokkal le van fedve akkor lehet nekiállni.. jaaa vagy akkor nem minket szórakoztatnának évek óta és teszteltetnék a messze nem kész rendszereket, hogy ezt most így adjuk meg... azt meg úgy... ja mégsem inkább amúgy... de most akkor emeljük ki... de majd nem most majd a következő verzióban már így lesz.. stb stb.. már nagyon unom az egészet.

@csaszko Nem az én tisztem megvédeni a NAV informatikusokat de, ha dolgoztál nagyvállalatnál/szervezetnél, akkor tisztában vagy azzal, hogy amikor felülről jön egy parancs, hogy mikor, hogyan, mit kell bevezetni, akkor néha az (értelmes) informatikai legfelső vezető is veri a fejét a falba, és eldöntheti, hogy felmond, vagy bevállalja a hülyeséget. (Ezt úgy mondom, hogy fogalmam sincs mi és hogyan müxik a NAV-nál, viszont tudom azt, hogy más "mammutoknál", hogy megy ez.)

[nbeeps2]

@EnokhSys az IP blokkolás ötlete szerintem nem felülről jött, aki felül van az sem tudja mi az az IP ;)

[EnokhSys]

@EnokhSys az IP blokkolás ötlete szerintem nem felülről jött, aki felül van az sem tudja mi az az IP ;)

@nbeeps2 De én most nem erről az esetről beszéltem, hanem általánosságban. Arra válaszoltam, amit csaszko írt.

[jozanesz]

ezt az agyatlanságot, hogy július 1-től minden számlát be kell küldeni, nem egy NAV informatikus találta ki

Na de jövőre be kell ám küldeni a magánszemélyek számláit. Számoljátok ki, hogy az 1 nap alatt százezres nagyságrendben kiállított számláknál ez mit jelent a közüzemek esetében, ahol az elszámoló számlákat egyesével kell beküldeni. Ha ennek a tervezésében nem vett részt informatikus, az a baj. Ha részt vett, és mégis ilyen lett, akkor meg az.

[EnokhSys]

ezt az agyatlanságot, hogy július 1-től minden számlát be kell küldeni, nem egy NAV informatikus találta ki

Na de jövőre be kell ám küldeni a magánszemélyek számláit. Számoljátok ki, hogy az 1 nap alatt százezres nagyságrendben kiállított számláknál ez mit jelent a közüzemek esetében, ahol az elszámoló számlákat egyesével kell beküldeni. Ha ennek a tervezésében nem vett részt informatikus, az a baj. Ha részt vett, és mégis ilyen lett, akkor meg az.

@jozanesz Na itt jön be az amit @csaszko írt, hogy valakinek fel kellene kiabálni legfelső- vagy akár minisztériumi szintre, hogy be kellene húzni a kéziféket, és lassabb tempót diktálni.

[csaszko]

Megint lehaltak. Ezért akarnak korlátozni...Nincs más választásuk. Nem tudják fogadni amit kértek.
Aztán megint megy a levél az ügyfeleknek, amiben persze nem fog szerepelni, hányszor állt a NAV szervere októberben.

Már jönnek is telefonok, készülhetünk rá.

@EnokhSys
Ebben én is biztos vagyok amit írsz, hogy nem ők találták ki. Az ő feladatuk az lett volna, hogy szólnak és harcolnak ha kell... emberek ezt talán mégsem így kellene kezdjünk már értelmes dolgokat csinálni és a jogszabályokat alakítani a valóságot, nem pedig valóságot az torzítani a hülyeséghez.. Amikor minden egyértelműen minden számára ugyanúgy értelmezhető szabályokkal le van fedve akkor lehet nekiállni.. jaaa vagy akkor nem minket szórakoztatnának évek óta és teszteltetnék a messze nem kész rendszereket, hogy ezt most így adjuk meg... azt meg úgy... ja mégsem inkább amúgy... de most akkor emeljük ki... de majd nem most majd a következő verzióban már így lesz.. stb stb.. már nagyon unom az egészet.

@csaszko Nem az én tisztem megvédeni a NAV informatikusokat de, ha dolgoztál nagyvállalatnál/szervezetnél, akkor tisztában vagy azzal, hogy amikor felülről jön egy parancs, hogy mikor, hogyan, mit kell bevezetni, akkor néha az (értelmes) informatikai legfelső vezető is veri a fejét a falba, és eldöntheti, hogy felmond, vagy bevállalja a hülyeséget. (Ezt úgy mondom, hogy fogalmam sincs mi és hogyan müxik a NAV-nál, viszont tudom azt, hogy más "mammutoknál", hogy megy ez.)

Ebben teljesen igazad van, de pont ezért vannak a felső vezetők (nem azoknak szól akik a végén szenvednek a hülyeségtől, ugyan úgy mint mi is) akiknek ki kellene állniuk a saját embereikért és mindenki másért.. egy problémára szinte biztosan nem egy megoldás létezik. (nem véletlen a legtöbb esetben nem egy nyugdíjas állás)... Azt biztos nem mondták meg, hogy pontosan hogyan is kell megvalósítani... a célt mondták el, fehérítsünk és több adó legyen ez a cél.. Az meg, hogy most mindent beáldozunk annak, hogy (8nap alatt számlázás, azonnali küldés m-lapok stbstb) lehessen a mellünket verni és elmondani, hogy a nav készíti az adóbevallást... de milyen áron?????

[NTCA-developer]

Kérnék szépen egy kis rádiócsendet. Már mindenről is beszélünk. Adjatok 1 órát és írni fogok a rate limiting megoldásról.

FYI, közben kiszolgálunk 10:40 óta.

[szako]

@szako

EDU-n már tegnap óta be van kapcsolva, igen. Közben állunk az élessel, nézzük.

@NTCA-developer: Nem tudom mi az az EDU, gondolom a teszt rendszer.. Annak ellenére kapunk 4 másodperceket, hogy a kérések között 1,1s-et hagyunk. De úgy látom az 1 percig legalább nem jutunk el.

[Rossi73]

@szako
EDU-n már tegnap óta be van kapcsolva, igen. Közben állunk az élessel, nézzük.

@NTCA-developer: Nem tudom mi az az EDU, gondolom a teszt rendszer.. Annak ellenére kapunk 4 másodperceket, hogy a kérések között 1,1s-et hagyunk. De úgy látom az 1 percig legalább nem jutunk el.

Lehet, az következik be, amit korábban írtam, és a második kérés esetleg több, mint 0,1 mp-cel gyorsabban ér be, mint az első, és így a NAV úgy érzékeli, hogy nem telt el 1 mp a két kérés között?

[EnokhSys]

Kérnék szépen egy kis rádiócsendet. Már mindenről is beszélünk. Adjatok 1 órát és írni fogok a rate limiting megoldásról.

Kedves Hallgatóink, most a süketnémáknak szóló 1 órás kívánságműsorunk következik! :-))

[NTCA-developer]

Sziasztok!

Először is, köszönjük mindenkinek az észrevételeit, talán ez a topic ment a legnagyobbat a Github eddigi történetében.

Most kicsit furcsán fog kinézni a ma 10 óra körüli letörés árnyékában amit írok, de úgy tűnik, hogy a tegnapi hír megtette a hatását: akik eddig elérhetetlenek voltak direkt megkeresések során, most hirtelen jó útra tértek vagy eltűntek a forgalmi statisztikákból. Ezért ma este csak a v1-es API forgalmára vezetünk be korlátozást. A v2-es /queryTransactionStatus limitálást készenlétbe helyeztük, és ha valami rossz irányba alakulna, akkor a következő két hétben időlegesen életbe léptetjük, de erről feltétlenül fogunk kommunikálni, ha ez bekövetkezett. Az időlegességet alá kell húznom, ugyanis a november elején bekapcsolt timestamp validáció óriásit fog tehermentesíteni rajtunk, ezért utána a limitálás már nem feltétlenül szükséges. Hozzáteszem, hogy ilyen formában, mert valamilyen szabály azért kell.

Azt mi is láttuk már amikor felmerült az ötlet, hogy ez egy vis maior megoldás. De azt is lássátok hogy az üzembiztonságot előbbre tartjuk mint hogy valaki beüti a fejét egy új korlátozásba, de cserébe tudunk szolgáltatni. A műszaki aggályait tudjuk és értjük, leírtátok ti is. Hosszútávon mindenképpen olyan megoldás kell, ami adószámra is képes forgalmat számolni. A v3-as XML API korszakra megpróbálunk behúzni egy ilyen megoldást, látszik hogy muszáj lesz.

A ticketet még egy darabig nyitva hagyom, ha hozzá akarnátok szólni. A fenti bejegyzés tartalmára hamarosan hír is jelenik meg az Online számla felületen.

Köszönjük a munkátokat!

[pvmon]

Ez egy jó hír! Főleg az tetszik, hogy eltűntek akik generálták ezt. Reméljük így marad.

[EnokhSys]

Naugye, hogy van értelmes élet ezen a bolygón! :-)
Mindig mondtam: a szépségkirálynőkhőz hasonlóan, nekünk is hinnünk kell a világbékében. Ámen! :-))

[EnokhSys]

Hosszútávon mindenképpen olyan megoldás kell, ami adószámra is képes forgalmat számolni. A v3-as XML API korszakra megpróbálunk behúzni egy ilyen megoldást, látszik hogy muszáj lesz.

Bölcs döntés. Vagy felhasználónévre, ezt érdemes megvizsgálnotok. Ugyanis egy nagyvállalat esetén (pl. áram-, gáz-, telekom szolgáltató cég) ugyanazzal az adószámmal tömegesen fogják lekérdezni a magánszemélyek számláit jövőre egyazon ip.címről, viszont ip.cím+felhasználónév esetén maga az adózó dönthet úgy, hogy nyit annyi "technical user"-t, ahány szükséges, hogy ne legyen probléma az egyidejűségből.

Köszönjük a munkátokat!

Mi is köszönjük az együttműködést!

[vectorkovacspeter]

@NTCA-developer arra esetleg van lehetőség, hogy megtudjuk a saját szoftverünk érintett lenne-e jelenleg a tiltások kapcsán? Mert ilyen szintű telemetriával gondolom nem sokan rendelkeznek, még saját termékükről sem.

[csaszko]

@NTCA-developer
Köszönjük az infókat, mindamellett, hogy teljesen egyetértek ezzel:

De azt is lássátok hogy az üzembiztonságot előbbre tartjuk mint hogy valaki beüti a fejét egy új korlátozásba, de cserébe tudunk szolgáltatni.

Azért kíváncsi lennék, hogy egy ilyen szituációban miért a "mindenkit tiltunk"(értsd foglalkoztatunk a témával)-ot választjátok a "túlbuzgókat tiltjuk"-al szemben?

[NTCA-developer]

@EnokhSys Arra kell limitálni, aminek a számosságára a kliensnek nincs ráhatása. Elsőként én is tech userre gondoltam, de utána rögtön jön a felismerés hogy ha erre limitálsz akkor csak annyi előfeltételt szabtál a floodolni vágyóknak, hogy előtte a felületen kell kattintania kettőt meg beírni egy jelszót. Szóval lyukas megoldás lenne, és ki szeret olyat csinálni? :)

@vectorkovacspeter írj a NAV helpdesknek, ha gondolod. De szerintem a működési logikából ki kell tűnnie a te oldaladon is.

@csaszko Azért, mert csak layer3 megoldásunk van készen késznél. Ez a réteg csak IP címet tud számolni, más információ nem hozzáférhető számára. Kell fejlesztenünk layer7-es megoldást, ami a HTTP-ben utazó üzleti adatokkal is képes számolni.

[nbeeps2]

@NTCA-developer "Azért, mert csak layer3 megoldásunk van készen késznél. Ez a réteg csak IP címet tud számolni, más információ nem hozzáférhető számára." Ez ok, de kicsit "beljebb", ahol látjátok a queryTransactionStatus kérések tartalmát ki tudjátok nyomozni, hogy melyik softwareId küldi ezt a sok-sok api hívást és akkor velük fel lehetne venni a kapcsolatot.

[csaszko]

@NTCA-developer
Igen, ezt írtad, ez világos is ez teljesen érthető és elfogadható.
Szeretném megérteni a döntéseteket :)
Csak láttátok azokat az ip címeket, amelyikekről érkezett ez a rengeteg kérés, és ezt össze lehet vetni azzal, hogy valóban melyik floodol (a többi aki meg sokat forgalmaz az csak rendesen küldi/kérdezi le az adatokat, de ennyi van neki..)
Ez alapján meg kell egy blacklist azokra IP-kre és mehet is arra layer3-ban a ratelimit.
Ami vagy resetelődik 12/24 óránként vagy megfordítva... ki lehet belőle kerülni ... ha ezen idő alatt nem történt flood..
Szerintem...

[csaszko]

@NTCA-developer "Azért, mert csak layer3 megoldásunk van készen késznél. Ez a réteg csak IP címet tud számolni, más információ nem hozzáférhető számára." Ez ok, de kicsit "beljebb", ahol látjátok a queryTransactionStatus kérések tartalmát ki tudjátok nyomozni, hogy melyik softwareId küldi ezt a sok-sok api hívást és akkor velük fel lehetne venni a kapcsolatot.

@nbeeps2
Szerntem is az lehet a megoldás kulcsa amit írtál (lásd fenti hasonló kommentem), de @NTCA-developer írta, hogy:

akik eddig elérhetetlenek voltak direkt megkeresések során,

csak nem érdekelte az érintetteket a téma... ezért mindenki elő lett véve

[nbeeps2]

@csaszko bocs, ez a mondatrész nekem kimaradt. értem. :)

[csaszko]

@nbeeps2 elég aktív volt valóban ez a szál.. nem csoda :)

[EnokhSys]

@EnokhSys Arra kell limitálni, aminek a számosságára a kliensnek nincs ráhatása. Elsőként én is tech userre gondoltam, de utána rögtön jön a felismerés hogy ha erre limitálsz akkor csak annyi előfeltételt szabtál a floodolni vágyóknak, hogy előtte a felületen kell kattintania kettőt meg beírni egy jelszót. Szóval lyukas megoldás lenne, és ki szeret olyat csinálni? :)

@NTCA-developer A mérleg egyik serpenyőjében van az a néhány tíz/száz amatőr, akik szinte biztos, hogy nem szándékosságból floodolnak, hanem lámerségből. A mérleg másik serpenyőjébe viszont jövőre bejön az a néhány-tíz multicég, amelyek fordulónapokon százezres-példányszámú számlákat állítanak elő. Ők a résztvevői egy-egy gazdasági szektor felpörgött versenyszférájának - nem csupán Magyarországon, hanem akár régiós szinten is -, ahol minden perc-, minden másodperc késést számszerűsített veszteség, és amely szektorokból a magyar államháztartás százmilliárdos bevételre tesz szert; - amely bevétel többek között nem csupán a tan-, egészségügyi stb. intézmények fenntartásához járul hozzá, hanem olyan neves hatóság fenntartásához is, mint a NAV. Fel sem teszem a kérdést, mert gondolom számodra is evidens, hogy a mérleg nyelve merre lendül ki...
De ezen túlmenően, az elmúlt két évben nem lehet azt mondani, hogy komoly problémák merültek volna fel a NAV OnLine Számla koncepciójával/rendszerével/működésével kapcsolatban, úgyhogy nem kellene egy ekkora blamát magatokra húznotok. Persze mindig van a társadalomban a NAV-val szemben egy ellenérzés (Jézus korában is utálták a vámszedőket), főleg, ha ezt politikai-izomból kényszerítik az emberekre, de azért akik józanul szemlélik a dolgokat, azok tisztában vannak vele, hogy nincs más út. Nem tudom, hogy Európában mely országban van még ennyire szigorúan bevezetve a számlák adóhatósági nyilvántartása, de 100%-ban biztos vagyok, hogy számos ország, ahol magas a csalás és a korrupció, kénytelen követni Magyarország példáját. (Tudtommal Románia jövőre fogja elkezdeni az ottani on-line számla rendszer bevezetését.)
És persze nem akarom tovább folytatni a sort, de törvényszerű, hogy amikor valamely ország belekezd egy ilyen projektbe, Magyarország mintául szolgálhat, és a projekt sikere esetén megkeresi azokat a szakembereket akik részt vettek benne, szóval csak azt tudom mondani, hogy szinte csak rajtatok múlik minden, avagy "don't fuck up the landing". :-)

[RuszinZsolt]

A Magyar Könyvelők Országos Egyesülete elutasít mindenféle forgalomkorlátozást. Kérjük, hogy az adóhatóság haladéktalanul állítsa vissza a lekérdezési jogokat és a forgalmazási problémáit célzottan oldja meg, ne pedig mindenkit büntessen!

Ezzel egyidejűleg érdeklődöm, hogy a korlátozásban van kivétel. Van olyan cím, amiről a NAV enged korlátozás nélkül lekérdezni? Ha igen, akkor kérjük ezt a listát az [email protected] címre megküldeni, 2020.10.20-án, 16.00-ig.

Jó munkát, jó egészséget kívánva,
Maradok Tisztelettel

Ruszin Zsolt
MKOE alelnök

[vectorkovacspeter]

Elég furcsa irányba megy ez a szál...
Nem igazán értem, az itt méltatlankodókat, hiszen ha az ő rendszerük nem küld több kérést, mint a szükséges, akkor eleve nem érinti őket a tiltás, ha pedig igen, akkor javítaniuk kell. Technikai kivételek persze vannak pl a felhő alapú megoldások és a közös szervert használó cégek esetén például.
De rendszer szempontjából az a jó, ha ezt egy rendszer szintű megoldás garantálja, pl a tiltás.
Az elején voltak releváns értelmes visszajekzések, amik célt is értek, hiszen végül nem aktiválták a tiltás ilyen módját.
Szóval tessenek olvasni, megnyugidni, és érdemi, konstruktív hozzászólásokkal segíteni a NAVos fejlesztők munkáját.
Magam részéről nagyon meg vagyok elégedve minden kommunikációjukkal és maximális segítő szándék jellemzi őket itt a guthubon, bízom benne, hogy találnak megfelelő megoldást erre a problémára is.
Peace

[EnokhSys]

Kedves @RuszinZsolt,

nem szeretnék beleavatkozni a nagyok dolgába (pedig most épp ezt teszem), de jó lenne végre tiszta lappal újrakezdeni a NAV-val a párbeszédet, és nem támadólag fellépni, hanem megérteni azt, hogy a NAV informatikai csapata sem jókedvében veti be az ilyen jellegű korlátozásokat. Mivel gondolom az okok Önök előtt is ismertek, és mivel az MKOE amúgy is egy országos szervezet, amelynek védőszárnyai alá több ezer könyvelő tartozik, felajánlhatnák a segítségüket.

• Például egy levéllel:
  "Kedves NAV Informatikai csapat, amennyiben küldenek nekünk egy listát azon cégek informatikai rendszereiről, amelyek a túlterheléseket okozzák, megpróbáljuk felvenni velük a kapcsolatot az együttműködés elősegítésének céljából."

• vagy egy nyilatkozattal:
  "Az MKOE szeretné elősegíteni a NAV OnLine Számla rendszerének túlterhelését okozó probléma megoldását, ezért felkérünk minden cégvezetőt, hogy szíveskedjenek felülvizsgálni a számlázóprogramjuk működését, és amennyiben szükséges, annak kommunikációját a NAV szervere felé másodpercenként egy kérésben (requestben) korlátozzák az informatikai munkatársaik, partnereik által."

Szóval vannak lehetőségek... s ha már a lehetőségeknél tartunk, szeretném emlékeztetni egy 900 éves bölcs öreg szavaira: "a harc senkit sem tesz naggyá".

Üdv.

[celeburdi]

Az aszinkron feldolgozás eredményének poll-os lekérdezése nem optimális tervezési elgondolás.
Ez mindig felesleges forgalmat fog generálni.
A klienseknek regisztrálniuk kellene az eseményváltozásokra a NAV szerverén és csak az állapotváltozáskor
kapott üzenetekre kellene a lekérdezést végrehajtaniuk.

[vectorkovacspeter]

@celeburdi sajnos ez viszont az ügyfelekre róna nem kívánt terhet, mert neki kellene fenntartania egy olyan rendszert, ami képes a nav-os callback-et.
Ez mondjuk online számlázók és ügyvitelek esetén semmiség, de minden más esetben meglehetősen sok extra lépéssel, fejlesztéssel, költséggel jár, pláne, ha az SLA is olyan (vagy nincs is), hogy nem folyamatosan elérhető.

[csaszko]

, de jó lenne végre tiszta lappal újrakezdeni a NAV-val a párbeszédet, és nem támadólag fellépni, hanem megérteni azt, hogy a

NAV informatikai csapata sem jókedvében veti be az ilyen jellegű korlátozásokat.

@EnokhSys
https://www.napi.hu/magyar_gazdasag/adozas-nav-konyvelo-online-szamlazas.715898.html?utm_source=index.hu&utm_medium=doboz&utm_campaign=link

Nem tudom mi a helyzet ezzel az egésszel, de a cikk alapján próbálkoztak.

[EnokhSys]

, de jó lenne végre tiszta lappal újrakezdeni a NAV-val a párbeszédet, és nem támadólag fellépni, hanem megérteni azt, hogy a

NAV informatikai csapata sem jókedvében veti be az ilyen jellegű korlátozásokat.

@EnokhSys
https://www.napi.hu/magyar_gazdasag/adozas-nav-konyvelo-online-szamlazas.715898.html?utm_source=index.hu&utm_medium=doboz&utm_campaign=link

Nem tudom mi a helyzet ezzel az egésszel, de a cikk alapján próbálkoztak.

@csaszko Próbálkoztak?? Várj csak, idézek a cikkből: :-)

"_Az alelnök a következő eseményre emlékeztet: a mai napon felhívtam Mizsányi Attilát, aki a NAV Központi Irányításán ezért az informatikai területért (is) felel. Azt kérdeztem tőle, hogy egyeztethetünk-e néhány percben az online számla kapcsán. Közölte, hogy "Nem". Megkérdeztem, hogy "Ne beszéljünk?". Közölte, hogy "Ne." Ezt követően letette a kagylót._"

Ühüm, ez a telefon kb. olyan volt, mint amikor ezelőtt 100 éve, dédnagyapáink átkiabáltak a szembenálló lövészárokba:

• Héé Fritz, áthajítsak egy nyeles gránátot? Feldobódnál tőle...
  Ha komolyan szeretnének beszélni egymással, valahogy így kellene kezdeni:
• Hali, van nálam egy flaska pálinka, meg egy indián békepipa, nincs kedved csevegni pár szót, hogy miben tudnánk segíteni?

Egyébként van igazság abban, amit a cikk állít, hogy a NAV, a két napos leállást követő kapkodásban szűkszavúan és rosszul kommunikált, na meg még erre rá is tett egy lapáttal a szoftvermószerolással, szóval ott belül is eléggé szétszaladt a ménes.
De ezt igazán jól meglovagolta a napi.hu csupa jóindulat, Pulitzer-díjas újságírója... már a cikk címe is sokatmondó: "Őrjöngenek a könyvelők". Vizuális típus vagyok, rögtön el is képzeltem a könyvelő-ismerőseimet, amint habzó szájjal, zombi módjára püfölik a számítógépet... :-))

[pvmon]

"Őrjöngenek a könyvelők". Vizuális típus vagyok, rögtön el is képzeltem a könyvelő-ismerőseimet, amint habzó szájjal, zombi módjára püfölik a számítógépet... :-))

El tudom hinni azoknál, akik hozzászoktak ahhoz, hogy így importálják a számlákat a NAV oldaláról,
Ezt áfa bevallási határidőben későn észrevéve lehet tényleg püfölik a billentyűt kínjukban :-))

[nbeeps2]

Hmmm, lehet akkor nem is a számlázó programok felelősek a túlterhelésért, hanem a könyvelő programok...? (mondjuk azok pont nem végeznek státusz lekérdezést)

[EnokhSys]

"Őrjöngenek a könyvelők". Vizuális típus vagyok, rögtön el is képzeltem a könyvelő-ismerőseimet, amint habzó szájjal, zombi módjára püfölik a számítógépet... :-))

El tudom hinni azoknál, akik hozzászoktak ahhoz, hogy így importálják a számlákat a NAV oldaláról,
Ezt áfa bevallási határidőben későn észrevéve lehet tényleg püfölik a billentyűt kínjukban :-))

Mert három hónapja, mióta kötelező minden számlát beküldeni, sikerült átállítani a könyvelőprogramokat arra, hogy a könyvelők már csak a NAV-tól kérdezzék le a számlákat az ÁFA-bevalláshoz... :-)

[pvmon]

"Őrjöngenek a könyvelők". Vizuális típus vagyok, rögtön el is képzeltem a könyvelő-ismerőseimet, amint habzó szájjal, zombi módjára püfölik a számítógépet... :-))

El tudom hinni azoknál, akik hozzászoktak ahhoz, hogy így importálják a számlákat a NAV oldaláról,
Ezt áfa bevallási határidőben későn észrevéve lehet tényleg püfölik a billentyűt kínjukban :-))

Mert három hónapja, mióta kötelező minden számlát beküldeni, sikerült átállítani a könyvelőprogramokat arra, hogy a könyvelők már csak a NAV-tól kérdezzék le a számlákat az ÁFA-bevalláshoz... :-)

Nem ezt mondtam, hogy mindenki, de sok helyen lehet használni.
Akár csak ha azt az excelt importálják be, ami a NAV-tól szintén letölthető manuálisan.
Amit esetleg Te nem tudsz, az még attól létezhet :-)))

[EnokhSys]

"Őrjöngenek a könyvelők". Vizuális típus vagyok, rögtön el is képzeltem a könyvelő-ismerőseimet, amint habzó szájjal, zombi módjára püfölik a számítógépet... :-))

El tudom hinni azoknál, akik hozzászoktak ahhoz, hogy így importálják a számlákat a NAV oldaláról,
Ezt áfa bevallási határidőben későn észrevéve lehet tényleg püfölik a billentyűt kínjukban :-))

Mert három hónapja, mióta kötelező minden számlát beküldeni, sikerült átállítani a könyvelőprogramokat arra, hogy a könyvelők már csak a NAV-tól kérdezzék le a számlákat az ÁFA-bevalláshoz... :-)

Nem ezt mondtam, hogy mindenki, de sok helyen lehet használni.
Akár csak ha azt az excelt importálják be, ami a NAV-tól szintén letölthető manuálisan.
Amit esetleg Te nem tudsz, az még attól létezhet :-)))

Jówan-jówan, én is tudom... :-), mondjuk arra kíváncsi lennék, hogy folyamatosan lassú a lekérdezés ahogy a cikk sugallja, vagy csak akkor, amikor egyébként a számlabeküldés és tranzakciólekérdezés is belassul.

[csaszko]

@EnokhSys
Amikor en próbáltam akkor lassú volt mindig.
onlineszámla webfelület:
Ami céggel most megnéztem, 160 db bejövő számla, kilistázás gyors.
Export excel.. 1 percig pörög és "hiba történt" nem túl beszédes, de gondolom leidőzít.

50 számlánál idő, de működik.. szóval ez így eléggé használatlan és idegőrlő jelenleg.

Korábban is ez volt... de lehet én próbálom rossz időben.. csak akkor mondják meg mikor lehet :)

[pvmon]

Igen az látható minden hónapban hogy 20-a környéke nagy terhelést kap és az extra rész lehet a könyvelőktől is érkezik. De ezt a NAV-os fejlesztők - üzemeltetők jobban tudhatják, a részemről csak találgatás.

[EnokhSys]

Sziasztok,

@csaszko jól értem, hogy ugyanarra a cégre, lekérdezve képernyőre a 160 db számla pillanatok alatt megtörténik, de ugyanarra a cégre, pontosan ugyanaz a 160 db. számla excel exportja már lassú? Az excelbe listázott adatok jóval részletesebbek, mint a képernyőn megjelenített adatok?

@pvmon, amit leírtatok, abból úgy tűnik, hogy ez nem ugyanaz a típusú lassulás, mint amiről korábban szó volt, itt a "vas fogy el" 20-a környékén ilyen rekordszámú adatbázis országos lekérdezéséhez. De ezt tényleg csak ők tudnák pontosan megmondani, viszont most nagyon csendben vannak... :-) szerintem egymás közt fogadásokat kötnek, hogy rájövünk-e a "tünetekből", hogy mi a gáz. :-))

[csaszko]

@EnokhSys
Igen, jól.
Ha belepsz a felületre, akkor bejövő számláknál van első körben szűrés (fej adatok) utána egy export gombbal tudod excelbe lekérni. Excel táblában pedig két lap van az egyiken a fejadatok a másiban a részletek.
Nálam a korábban 51 számla fejadatai és összesen 114 sor tételadat ami éppen, hogy belefért a limitbe (hibajelzés), de most miközben ezt írom, már azt sem sikerült letölteni.

Kollégámat is megkérdeztem, 10.08-án volt amikor szintén napközben próbáltuk (ezt a dátumot tudtuk behatárolni) és nem ment. (nem tudom akkor milyen határidó volt az előző havi folyamatos telj. számlák kiállításán kívül)

[pvmon]

Kollégámat is megkérdeztem, 10.08-án volt amikor szintén napközben próbáltuk (ezt a dátumot tudtuk behatárolni) és nem ment. (nem tudom akkor milyen határidó volt az előző havi folyamatos telj. számlák kiállításán kívül)

Lehet a "KATA"-sok számlázzák a fizujukat :-))

[renced42]

@pvmon Nem hallgatunk, csak olvassuk a csodálatos és végnélküli hozzászólásokat (meg közben dolgozunk is), amit köszönünk is, mert kapunk belőle hasznos infókat :)
Két fele kell választami a dolgokat:
1.) Felületi lekérdezés probléma
2.) API lekérdezés

1.) Ezt a problémát már láttuk és készül rá javítás. De itt kettő lehetőség van:

• szinkron letöltés
• zip-es megoldás ami aszinkron -> ezt nem használjátok?
  Utóbbi jól működik, előbbi nem annyira ezt a bejelentésekből látjuk is. @pvmon, @csaszko Kérlek segítsetek megérteni a problémát, hogy 50 vagy 160 számlát miért akartok ki exportálni, (miért nem gépi interfészen töltitek le?) illetve, ha szükséges az export, akkor elégséges-e csak a táblázat exportja vagy csak a fej adatoké vagy általában mihez kell az export, vagy mi kell belőle? Mit csinálnak vele a felhasználók? Milyen adatok kellenek a számlákból? 1,2-5 számla tételes ki exportálást még megértem, de többet nem. Webes felületek általában nem tömeges adatkinyerésre vannak optimalizálva, sehol sem a világban, (Persze ez nem kifogás, a cél hogy működjön a funkció mindenki megelégedésére.)
  @csaszko Igen az adatok az excelben lényegesen részletesebbek, ezért a lekérdezés is lényegesen drágább és lassab is.

2.) Amint látható, minden lekérdező funkció működik és kiszolgál az API-n. (Kivéve a V1-es interfészek) Azt azért látni kell, hogy ezekre a kényelmi szolgáltatásokra sokan rákaptak. Pl.: mondjuk gondol egy nagy cég egyet (több milliós számlával) és azt az adatmennyiséget, amit egy év alatt betolt, azt mondjuk le akarja húzni azonnal a rendszerből, mert most könnyvizsgálat van vagy bármi más (nincs jelentősége). És akkor ebből nem egy van és nem is tíz és nem egyszer, mert hogy ott is hibáznak a programok.
Szóval ez csak egy aprócska szelet abból a probléma halmazból, amit említettem.
Nehéz azt a balanszt megtalálni, hogy mindenkit is kiszolgáljunk értelmes időn belül, de közben ne lehetetlenítsük el azokat sem akik egyébként nem az elvárt módon működnek, de szisztematikusan le akarják abálni az erőforrásokat. Természetesen törekszünk arra, hogy ne legyen üzemszünet és szolgáltatás kiesés a nap 24 órájában és az érintettekel általában célzottan fel is vesszük a kapcsolatot.

[pvmon]

@renced42 Én nem mondtam, hogy hallgattok valamit félre olvastál. Más volt.
Programból mi nem kérünk le excelt, csak tudjuk, halljuk miket csinálnak a könyvelők...mert általában van hozzáférésük a céges online számla adatokhoz.
A sima excel listát kértem le amikor írtam. Harmadszorra le is jött. Általában ezt használják a könyvelők is a "gyors" áfa bevalláshoz, nem a tételest.
Néha megnézzük mi működik és mi nem. Például a múltkori NAV-os levélben írt lekérdezéseket is megnéztük, hogy működik-e, mert jelezték felénk hogy nem és tényleg nekünk sem ment akkor. jeleztem, de azóta nem is néztük.
Csak akkor fejlesztünk valamilyen irányba, ha az már stabilan elérhető. mert ha bekerül nyilvánosan a programba, akkor jön hogy miért nem működik és az nem jó, ha nem miattunk, mert azzal nem tudunk mit kezdeni, csak magyarázkodni, amire jelenleg nekünk sincs időnk....

[renced42]

@renced42 Én nem mondtam, hogy hallgattok valamit félre olvastál. Más volt.

@pvmon, amit leírtatok, abból úgy tűnik, hogy ez nem ugyanaz a típusú lassulás, mint amiről korábban szó volt, itt a "vas fogy el" 20-a környékén ilyen rekordszámú adatbázis országos lekérdezéséhez. De ezt tényleg csak ők tudnák pontosan megmondani, viszont most nagyon csendben vannak... :-) szerintem egymás közt fogadásokat kötnek, hogy rájövünk-e a "tünetekből", hogy mi a gáz. :-))

[csaszko]

@renced42
En most tesztelési célból töltöttem. De könyvelőnk szerette volna leszedni korábban az áfa bevalláshoz az összehasonlítás miatt. A zip-es megoldást nem láttam, de nem is kerestem. Szűrés es export szemet szúr ezt találtam.
A bejövő számla lekérdezés fejlesztését jegeltem, nem fejeztem be, jeleztem is akkor problémákat, hogy ne engedjetek kézi számlát rögzíteni úgy, hogy köszönő viszonyban nincsenek a számok egymással. Sajnos nálunk továbbra is előfordulnak, olyanok (bejövő), hogy vagy számolni nem tudnak vagy rosszul értelmezik (nem kutattam miért) mit hova kell beírni es ezért használhatatlan adok kerülnek bele, azt ellenőrizni kell embernek úgyis... valakit egyszerűen nem lehet meggyőzni, hogy felejtse már el a papírt...

[csaszko]

@renced42 Én nem mondtam, hogy hallgattok valamit félre olvastál. Más volt.

@pvmon, amit leírtatok, abból úgy tűnik, hogy ez nem ugyanaz a típusú lassulás, mint amiről korábban szó volt, itt a "vas fogy el" 20-a környékén ilyen rekordszámú adatbázis országos lekérdezéséhez. De ezt tényleg csak ők tudnák pontosan megmondani, viszont most nagyon csendben vannak... :-) szerintem egymás közt fogadásokat kötnek, hogy rájövünk-e a "tünetekből", hogy mi a gáz. :-))

Ezt @EnokhSys irta :)

[csaszko]

@renced42 erre nem válaszoltam:
Nem tudom pontosan mik kellenek vagy kellettek volna, de szerintem ha a fej adatokat ki lehetne exportálni (ami már szűrés után is rendelkezésre áll) az biztosan elég lenne időnként. (Számla bruttó vagy nettó vegösszeggel, most nincs előttem a lista nem.tudom benne van-e)

[EnokhSys]

@EnokhSys
Igen, jól.
Ha belepsz a felületre, akkor bejövő számláknál van első körben szűrés (fej adatok) utána egy export gombbal tudod excelbe lekérni. Excel táblában pedig két lap van az egyiken a fejadatok a másiban a részletek.
Nálam a korábban 51 számla fejadatai és összesen 114 sor tételadat ami éppen, hogy belefért a limitbe (hibajelzés), de most miközben ezt írom, már azt sem sikerült letölteni.

Kollégámat is megkérdeztem, 10.08-án volt amikor szintén napközben próbáltuk (ezt a dátumot tudtuk behatárolni) és nem ment. (nem tudom akkor milyen határidó volt az előző havi folyamatos telj. számlák kiállításán kívül)

@csaszko Így már gyanítható, hogy miért lassabb az excel, hisz képernyőn te csak a fejadatokat kérdezed le. Míg excel-ben a tételadatok is benne vannak, ami one2many viszonyt jelent, sőt, ha az áfa részletező is lejön, az is egy újabb one2many viszony. Csodák nincsenek, akármilyen adatbázis-kezelés/szervezés mellett, excel esetén minden számlához el kell indítani legalább egy tételszűrést (hacsak nem vállalták be a redundáns adatkezelést, de az kizárt, mondhatni vörös posztó). Ilyen hatalmas, országos szintű "ügyfélkörrel", érthető, hogy lelassul az adatszerver működése, még, akkor is, ha csak kevesen listáznak excelbe, mert azért az adatbázis-kiszolgálásban nem a lekérdezések élveznek magas prioritást.

Nade mindez csak okoskodás, látom megjött az informatikai csapat, biztosan majd elmondják, hogy mi a helyzet.

[EnokhSys]

Kollégámat is megkérdeztem, 10.08-án volt amikor szintén napközben próbáltuk (ezt a dátumot tudtuk behatárolni) és nem ment. (nem tudom akkor milyen határidó volt az előző havi folyamatos telj. számlák kiállításán kívül)

Lehet a "KATA"-sok számlázzák a fizujukat :-))

Köhhöm, ne bántsd lécci a KATA-sokat, mert nekem a t@köm tele van azzal, hogy ezt olyanok is kihasználják, akiknek semmi joguk rá, valójában munkaviszonyban dolgoznak. És persze ez további szigorításokhoz vezet majd, amit megint mi, becsületes kisadózók fogunk megszívni, akik évtizedek óta megpróbálunk önállóan talpon maradni.

[Macskafarka]

Az adóbevétel 90%-a nem a KATA-s adózóktól van.
Jó pár nagy cég társasági adóalapja kevesebb, mint a KATA-soké, mégsem büntetik meg őket.
Válság alatt a kicsiket szivatni, nem vall erős jellemre.
Van megoldás a KATA helyett is.

[EnokhSys]

@pvmon Nem hallgatunk, csak olvassuk a csodálatos és végnélküli hozzászólásokat (meg közben dolgozunk is), amit köszönünk is, mert kapunk belőle hasznos infókat :)

@renced42 Olyan ez mint egy kocsma: megváltjuk a világot a törzsasztal mellett... gyere máskor is. :-)

[EnokhSys]

@renced42 Én nem mondtam, hogy hallgattok valamit félre olvastál. Más volt.

@pvmon, amit leírtatok, abból úgy tűnik, hogy ez nem ugyanaz a típusú lassulás, mint amiről korábban szó volt, itt a "vas fogy el" 20-a környékén ilyen rekordszámú adatbázis országos lekérdezéséhez. De ezt tényleg csak ők tudnák pontosan megmondani, viszont most nagyon csendben vannak... :-) szerintem egymás közt fogadásokat kötnek, hogy rájövünk-e a "tünetekből", hogy mi a gáz. :-))

@renczed42 Ezt én írtam, nem @pvmon.

[csaszko]

@renced42
Most kerestem a webfelületen a zip-es megoldást amit mondtál... én nem találom. Szerintem logikus helye ugyan azon a felületen lenne az export gomb mellett.

Előző témához még egy kis adalék:
Van akinek nem jelent gondot, van akinek eléggé, nekünk sem idő, és energia nincs arra, hogy mikor változtattok valamit akkor mindent mi is lekövessünk, átgondoljunk, átírjunk, bevezessünk.. ezért ameddig nem látjuk a végét ezeknek a változtatásoknak, addig biztosan mi is csak a minimumra törekszünk. (És használjuk az általatok biztosított manuális eszközöket))
Ezért is lett létrehozva a #438 topic.

[pvmon]

@renced42 Én nem mondtam, hogy hallgattok valamit félre olvastál. Más volt.

@pvmon, amit leírtatok, abból úgy tűnik, hogy ez nem ugyanaz a típusú lassulás, mint amiről korábban szó volt, itt a "vas fogy el" 20-a környékén ilyen rekordszámú adatbázis országos lekérdezéséhez. De ezt tényleg csak ők tudnák pontosan megmondani, viszont most nagyon csendben vannak... :-) szerintem egymás közt fogadásokat kötnek, hogy rájövünk-e a "tünetekből", hogy mi a gáz. :-))

Most ez komoly, hogy engem megszólítva írt valaki nekem választ és benézed, hogy én írtam és nem a Hszt-t író @EnokhSys ???
Mert ha ez így van akkor most adom fel...

@renced42 most téged ide írtalak akkor ez Te írtad??

[pvmon]

Köhhöm, ne bántsd lécci a KATA-sokat, mert nekem a t@köm tele van azzal, hogy ezt olyanok is kihasználják, akiknek semmi joguk rá, valójában munkaviszonyban dolgoznak. És persze ez további szigorításokhoz vezet majd, amit megint mi, becsületes kisadózók fogunk megszívni, akik évtizedek óta megpróbálunk önállóan talpon maradni.

Nem bántom őket. Belekényszerítik őket a munkaadók ebbe. 2-3 cég felé számláznak de egy a tulajdonos érdekeltség. Ez van. Én csak sajnálom őket azt sem tudják, hogy nem számít 100%-ban a nyugdíjba egy évük. Nem eggyel beszéltem már és fogalmuk sincs mit csinálnak, csak azt tudják egy kicsivel több pénzt kapnak mint előtte.

[EnokhSys]

Most ez komoly, hogy engem megszólítva írt valaki nekem választ és benézed, hogy én írtam és nem a Hszt-t író @EnokhSys ???
Mert ha ez így van akkor most adom fel...

@renced42 most téged ide írtalak akkor ez Te írtad??

Szerintem csak véletlen volt a megszólítás, amúgy meg úgy tűnik, hogy mindenkinek írta. :-)

[pvmon]

@renced42 Én nem mondtam, hogy hallgattok valamit félre olvastál. Más volt.

@pvmon, amit leírtatok, abból úgy tűnik, hogy ez nem ugyanaz a típusú lassulás, mint amiről korábban szó volt, itt a "vas fogy el" 20-a környékén ilyen rekordszámú adatbázis országos lekérdezéséhez. De ezt tényleg csak ők tudnák pontosan megmondani, viszont most nagyon csendben vannak... :-) szerintem egymás közt fogadásokat kötnek, hogy rájövünk-e a "tünetekből", hogy mi a gáz. :-))

HA véletlen lett volna, akkor ezt nem idézte volna le ide még egyszer, mintha én nem tudnám mit írok,...
Ha visszanézi, akkor ezt a fentit nem vágja be ide újra. Na ez a gáz számomra.
Feladtam.

[EnokhSys]

Köhhöm, ne bántsd lécci a KATA-sokat, mert nekem a t@köm tele van azzal, hogy ezt olyanok is kihasználják, akiknek semmi joguk rá, valójában munkaviszonyban dolgoznak. És persze ez további szigorításokhoz vezet majd, amit megint mi, becsületes kisadózók fogunk megszívni, akik évtizedek óta megpróbálunk önállóan talpon maradni.

Nem bántom őket. Belekényszerítik őket a munkaadók ebbe. 2-3 cég felé számláznak de egy a tulajdonos érdekeltség. Ez van. Én csak sajnálom őket azt sem tudják, hogy nem számít 100%-ban a nyugdíjba egy évük. Nem eggyel beszéltem már és fogalmuk sincs mit csinálnak, csak azt tudják egy kicsivel több pénzt kapnak mint előtte.

@pvmon Azt még elfogadom, hogy egy kezdő vállalkozó (mondjuk az első 5 év) még nincs tisztában a különböző adózási formákkal. De azt nem fogadom el, hogy akik már legalább 5-7 éve vállalkoznak, ne tudnák, hogy mit csinálnak. Szóval hagyjuk... kötve hiszem, hogy az illegális KATA-sok akár csak 20%-a kezdő vállalkozó lenne.

[EnokhSys]

@renced42 Én nem mondtam, hogy hallgattok valamit félre olvastál. Más volt.

@pvmon, amit leírtatok, abból úgy tűnik, hogy ez nem ugyanaz a típusú lassulás, mint amiről korábban szó volt, itt a "vas fogy el" 20-a környékén ilyen rekordszámú adatbázis országos lekérdezéséhez. De ezt tényleg csak ők tudnák pontosan megmondani, viszont most nagyon csendben vannak... :-) szerintem egymás közt fogadásokat kötnek, hogy rájövünk-e a "tünetekből", hogy mi a gáz. :-))

HA véletlen lett volna, akkor ezt nem idézte volna le ide még egyszer, mintha én nem tudnám mit írok,...
Ha visszanézi, akkor ezt a fentit nem vágja be ide újra. Na ez a gáz számomra.
Feladtam.

@pvmon Nemáá', egy ilyen kis hiba miatt felesleges megorrolnod. Vedd észre, hogy most nincs semmilyen kritikus helyzet, csak úgy egyszerűen beszélgetünk. :-)

[renced42]

HA véletlen lett volna, akkor ezt nem idézte volna le ide még egyszer, mintha én nem tudnám mit írok,...
Ha visszanézi, akkor ezt a fentit nem vágja be ide újra. Na ez a gáz számomra.
Feladtam.

Elnézést, hogy 16 óra munka után benéztem, hogy nem te írtad azt amire azt gondoltam, hogy te írtad és még erre rá is tromfoltam. :( :( :( . Mégegyszer elnézést... már ha nem gáz az, hogy elnézést kérek.

[RuszinZsolt]

A határidő lejárt, válasz nem jött. Így nem zárható ki teljes bizonyossággal, hogy a korlátozások terén van (volt) kivétel, tehát van olyan cím, hely, amiről a NAV enged korlátozás nélkül lekérdezni és az nemcsak a v1-es API forgalma terén van így.

Az interfészen keresztüli lekérdezés korlátozás önmagában is nagyon rossz jel. A NAV informatikusai arra panaszkodtak, hogy ezek a fölös forgalmat generáló lekérdezőket nem tudták elérni. Ahelyett, hogy célirányosan keresték volna a megoldást, némi (értsd: csekély) elhárítási próbálkozás után az egész jogkövető szoftveres kört - egyeztetés nélkül - megbüntették.

A jövőben nem szeretnénk ilyen "vis maior" megoldások statáriális alkalmazását meglátni a NAV részéről!

UI: az onlineszamla.nav.gov.hu oldalon továbbra se lehet listákat lekérdezni, de amúgy is a szűrés paraméterezése - az adóhatósághoz méltatlanul - primitív. Erről itt a videó: https://tinyurl.com/onlineszamla-lekerdezesi-hiba

Az "online számla" sikeres működtetéséhez (is)
Jó munkát, jó egészséget kívánva,
Maradok Tisztelettel

Ruszin Zsolt
MKOE alelnök

[pvmon]

Elnézést, hogy 16 óra munka után benéztem, hogy nem te írtad azt amire azt gondoltam, hogy te írtad és még erre rá is tromfoltam. :( :( :( . Mégegyszer elnézést... már ha nem gáz az, hogy elnézést kérek.

Köszönöm szépen! Megértettem. Mindenki hibázik, főleg ha kimerült. Elmúlt, csak felizgatott....

[renced42]

Kedves @pvmon @csaszko, köszi az infót az excel exportról.
Az aszinkron letöltés lehetőségéről az Online Számla rendszer felhasználói kézikönyv 16.2 Kimenő számlák és a 16.8 Bejövő számlák fejezetében lehet olvasni.
Érdemes lenne ezt a funkciót is esetleg kipróbálni, használni.

[pvmon]

@renced42 Köszönöm az infót, bár mi ezt nem használjuk, csak tesztelésből néztem.
A könyvelőkhöz kellene ezt eljuttatni.
Abból indult ki az egész, hogy 20-a (ÁFA bevallás) körül általában lassulás tapasztalható. Erre mondtam, sok könyvelő szedi le ezeket a listákat. Meg jött MKOE beírás ami erre engedett következtetni.
De ti tudjátok monitorozni igaz lehet-e.
Csak egy tipp volt részemről miért van ebben ez időszakban ez.
Lehet teljes félre gondoláson alapul.
Ötletnek, segítségnek szántam csak. ha téves gondolat elnézést!

[csaszko]

Kedves @pvmon @csaszko, köszi az infót az excel exportról.
Az aszinkron letöltés lehetőségéről az Online Számla rendszer felhasználói kézikönyv 16.2 Kimenő számlák és a 16.8 Bejövő számlák fejezetében lehet olvasni.
Érdemes lenne ezt a funkciót is esetleg kipróbálni, használni.

@renced42
Köszi így megtaláltam, nem jelöltem ki számlát így inaktív volt a gomb. Ezért a felső exportot használtam (feltételezem nem én voltam az egyetlen. Igaz valóban nem olvastam a felhasználóit. Nem hiszem, hogy mostanában sokan szoktak.. persze nem mentség, de ez a valóság :) )

Megnéztem, szerintem (számomra biztosan nem lenne az) ez a formátum nem segítség azoknak akik egyeztetni akarnak, hiszen minden számla külön excelben van. Ha egy táblában vannak az adatok akkor lényegesen egyszerűbb listázni, szűrni ahogy csak szeretnének.
Biztos van létjogosultsága ennek is, de így elsőre nekem a sok tételes számla átláthatatlan.

Továbbra is a voksom arra adom, hogy a sima lista használhatóbb, csak fej valamint fej/részletek, esetleg hasonló aszinkron
módon működjön itt is a letöltés lehetősége. (a 100 tételes limit nagyobbra emelésével)

[EPluribusUnum]

Mivel olyan megoldás született ami nem problémás a felhőnek, ezért zárom. Elmentek már nagyon másfelé a comment-ek.