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.

[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:

2. 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...