Online-invoice: [Q&A] Mi ez az új levél? És miért küldi a NAV?

[pvmon]

@NTCA-developer
@NTCA-supporter
Mellékeltem egy képet a mai nap kapott NAV levélből. Miért jött ez??
Minden számla feltöltve és VISSZAKÉRDEZVE. Logjaink a feldolgozási eredmény lekérdezésről le vannak tárolva.
Miért írnak és küldözgetnek ilyet és hibáztatják a számlázó programokat?

Amennyiben lehetséges, szeretnék egy gyors választ kapni erre a kérdésre, mert a prog.hu-n mások is írták, hogy ügyfeleknek is küldözgetik ezt a sablon szöveget.

(Egyébként a levélben említett lekérdezési oldal meg nem működik. Megpróbáltam lekérni a szeptemberi adatokat.
Kiírja alul pirossal hogy "A kért statisztika elkészítése folyamatban, kérjük várjon!"
Viszont 30 perc alatt sem készül el semmi...meddig kellene rá várni? De ez annyira nem érdekes számomra.)

[csaszko]

295

Feltételezem, ez a hiba miatt van, ami elméletileg javítva volt, gyakorlatilag nem (jelezve is lett korábban újra, hogy nem megy, csak nem reagált rá már senki)
Bízom benne, hogy kiküldenek egy újabb köremailt amiben elismerik a hibájukat.

[EnokhSys]

Kedves pvmon!

Kíváncsi vagyok, hogy mit fognak válaszolni a NAV informatikusai, de amennyiben te vagy a szoftver fejlesztője, azt javaslom, hogy mindenképp vedd fel a kapcsolatot a NAV ügyfélszolgálatával egy hivatalos, de barátságos hangú levélben.

Ez azért fontos, mert amennyiben valamely partnered kapta az általad bemásolt levelet, az nagyon veszélyes lehet az együttműködésetekre. Tapasztalatból tudom, hogy a társadalomban, ill. a könyvelőkben és a cégek menedzsmentjeiben eleve van egy félelem az adóhatóságtól, amelynek az az egyik alapja, hogy "a világon Magyarországon vannak a legbonyolultabb jogszabályok, ha a NAV vizsgálódni kezd, előbb-utóbb csak talál valamit, amiért megbüntethet, jobb nem felhívni magunkra a figyelmet". Egy ilyen levél pedig megingathatja a cégvezetés bizalmát a szoftveredben, és a mai világban keserves dolog elveszteni ügyfelet, főleg, ha az nagyrészt rajtad kívül álló ok miatt következik be.

Ezért azt javaslom, hogy 2020 júl.1-ig visszamenőleg csomagolj össze minden OnLine Számlával kapcsolatos log-filet egy tömörített állományba, és mellékeld a leveledhez. A leveledben pedig mindenképp kérd azt, hogy a válaszlevelüket a partnerednek is címezzék, amelyben elismerik a tévedésüket.

Nekem az utóbbi évtizedben pozitív tapasztalataim vannak a NAV ügyfélszolgálatával kapcsolatban, normálisan és nagyon segítőkészen állnak az emberhez, úgyhogy szinte biztos, hogy - amennyiben valóban ők tévedtek -, el fogják ismerni a hibát. Viszont, ha a mellékelt bizonyítékok ellenére ezt nem fogják megtenni, akkor már küldhetsz ügyvédi felszólítást, mivel ez már hitelrontásnak minősül.

Üdv.

[pvmon]

Nem hiszem, hogy más elkerüli ezt. Már cikket is találtam róla. Az MKOE egyszerűen "levélszemétnek" nyilvánítja a NAV levelét...

https://www.napi.hu/magyar_vallalatok/nav-szamla-hiba-konyvelok.715508.html

[EnokhSys]

@pvmon Akkor itt úgy néz ki, hogy valami tömeges elkefélés történt a NAV-nál. Egyébként, ahogy látom, pont az történt, amit én is éreznék egy ilyen levél esetén, azaz, hogy minden vérbeli szoftverfejlesztő felhördült, hogy alaptalanul megingatják az ügyfelek bizalmát a szoftverjükben.

[NTCA-developer]

Nem tudom srácok mi ez. Azt nyilván értitek hogy nem tudhatunk mindenről ami a projekt körül történik. Engem jelenleg sokkal inkább érdekel, hogy a kapcsolódó javítás jól működik-e vagy sem.

Ha az miatt van hogy ez a hiba még mindig fennáll, akkor ezért szívesen elviszem a balhét. Lássuk meg először azt, hogy mit látunk a saját szemünkkel.

[nbeeps2]

@NTCA-developer Ez egy levél, amit a NAV küld célzottan az adott szoftver felhasználójának, hogy a számlázó program ROSSZUL, NEM A JOGSZABÁLYOK szerint működik, mivel nem kérdezi le az adatszolgáltatás sikerességét, csak beküldi a számlát. Nos a mi szoftverünk mindig lekérdezi, ami naplózva is van. Egy ilyen levél súlyosan befolyásolja egy szoftver megítélését és mivel nekünk az ügyfelünk többsége ajánlás útján jön, 1 ilyen ügyfél eset is több leendő vásárlás meghiúsulását hozza magával, ha pedig felszorozzuk ezt több száz, több ezer ilyen levéllel, akkor több tíz millió üzleti haszon elmaradása következhet be, amit könnyen perrel végződhet a NAV irányába, ha nem áll le az ilyen (alaptalan) levelek kiküldésével.

[nbeeps2]

@NTCA-developer Valószínűleg a csaszko által is említett #295 miatt van és a NAV úgy érzékeli, hogy nem kérdeztük le a számlát, közben pedig lekérdeztük és nálunk a programban már Sikeres a beküldés státusza, ezért nem is kérjük le újból. A helyzet tisztázása érdekében kérjük, hogy az összes érintett ügyfélnek, aki ezt a levelet megkapta menjen egy újabb levél, hogy a korábbi levelet tévesen küldte a NAV és a számlázó program JOGSZABÁLYOKNAK MEGFELELŐEN működött, abban HIBA NEM VOLT és tévesen küldték a levelet. Ezzel visszaállíthatnánk a renoménkat.

[pvmon]

@NTCA-developer Leginkább azt nem értem, hogy egy meghirdetett türelmi időszakra vonatkozóan egyáltalán miért megy ki egy ilyen levél?!

[alaplap]

Nekünk is van olyan ügyfelünk, aki kapott ilyen tájékoztatót. Most próbáljuk kisilabizálni a rendelkezésre álló adatokból, hogy mivel lehet a probléma. Egyébként ugyan arra hívja fel a figyelmet, mint @pvmon a ti esetetekben, azaz _"számlázóprogramja „nem győződött meg” az adatszolgáltatás feldolgozásának sikerességéről"_ és hogy _"vegye fel a kapcsolatot a számlázóprogramjának fejlesztőjével, és intézkedjen a hibás működés mielőbbi javításáról"_.

Most azt tapasztaljuk, hogy borzasztóan nehéz visszaellenőrizni és kikeresni a rendelkezésre álló információk alapján a hibákat. Az alábbi problémákkal találkoztam idáig:

• A tájékoztató alapján "2020. július 1-jét követően" beküldött számlákat vizsgálták, ami 3 és fél hónap adata. Tehát az egyik probléma azzal van, hogy a vizsgált időszak túl nagy.
• Az ügyfél több számlázóprogramot is használhat és a tájékoztató nem tér ki arra, hogy melyik számlázó program esetében tapasztaltak hibás működést.
• Próbáltuk a tájékoztató alapján javasolt módon lekérdezni a _Szolgáltatások → Használati statisztika_ menüpontban az _interfész statisztikákat_, valamint lekérdezni a _Számlák → Adatszolgáltatások_ menüpontban az adatszolgáltatásokat. Ott is azt tapasztaltuk, hogy nem lehet egy adott számlázó programra lekérdezni a statisztikákat.
• A _Szolgáltatások → Interfész napló_ menüpontban ugyan lehet számlázó program alapján is leszűrni adatokat, viszont ott kötelezően bekéri a "Kérés azonosítóját". Normál esetben 1 számlához 3 darab request (kérés) tartozik: TokenExchangeRequest, ManageInvoiceRequest, QueryTransactionStatusRequest. Mindegyiknek van egy requestId-ja a head tag-ben. Továbbá mindegyiknek van egy softwareId-ja a software tagben. Sajnos semelyik korábbi kérés requestId - softwareId párosára sincs megjeleníthető adat, tehát ez a menüpont - tapasztalataim szerint - nem működik.
• A lekérdezések sajnos sok esetben nem adnak eredményt. Erről közzéteszek egy képet is és a böngésző konzoljában látható adatokat, hátha segít. A kérés 1 percen belül (kb. 40 mp.) kerül elutasításra, nem az 1 perces timeout-tal függ össze.

A javaslatom az lenne, hogy:

• ha a jövőben is lesznek hasonló ellenőrzések, akkor sűrűbben tegyék azt meg, hogy a hibák kivizsgálása egyszerűbb legyen felhasználóknak/szoftverfejlesztőknek - minél kevesebb adatot kell átnézni, annál egyszerűbb megtalálni a hibát;
• legyen mód arra, hogy a _Szolgáltatások → Használati statisztika_ menüpontban az _interfész statisztikákat_ számlázóprogramonként meg lehessen tekinteni; és/vagy
• legyen mód arra, hogy a _Számlák → Adatszolgáltatások_ menüpontban számlázóprogramonként le lehessen kérdezni az adatszolgáltatásokat;
• továbbá ha megoldható, akkor a legtisztább az lenne, ha a tájékoztató e-mailben eleve fel lenne tűntetve, hogy mely számlázóprogram(ok) esetében tapasztaltak hibákat.

Ha van másnak egyszerű megoldása az ilyen e-mail kapcsán megtalálni, hogy mely számlák lekérdezésével lehet probléma, úgy szívesen várom a tanácsát.

-- Csatolmány: --

POST /rest/invoiceService/invoiceRequest/query undefined
Host: onlineszamla.nav.gov.hu
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0
Accept: application/json, text/plain, */*
Accept-Language: hu-HU,hu;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Content-Type: application/json
Content-Length: 298
Referer: https://onlineszamla.nav.gov.hu/szamlak/adatszolgaltatasok
Pragma: no-cache
Cache-Control: no-cache
x-language: hu
X-Version: 2.12.1
sessionToken: 8aa58963-4390-4db0-85da-75ba60191bc634UX514216Y8
login: ■■■■■■■■■■■■■■
Origin: https://onlineszamla.nav.gov.hu
Connection: keep-alive
Cookie: _ga=GA1.2.2091159764.1552567125; cookie-accept-did-show=true; _gid=GA1.2.711287577.1602598434; BIGipServer~PROD~PROD_k8s=rd2o00000000000000000000ffffac18822ao80; BIGipServer~PROD~PROD_fe=!2iYkLil4bZRngsJhHw8mNMUpFFR0w7R93ejlEwE4ESAbbvErwdHj+OeC4SxO4FB9gxMxAwKH2NYYzvk=

[EnokhSys]

Nem tudom srácok mi ez. Azt nyilván értitek hogy nem tudhatunk mindenről ami a projekt körül történik. Engem jelenleg sokkal inkább érdekel, hogy a kapcsolódó javítás jól működik-e vagy sem.

Ha az miatt van hogy ez a hiba még mindig fennáll, akkor ezért szívesen elviszem a balhét. Lássuk meg először azt, hogy mit látunk a saját szemünkkel.

@NTCA-developer Nyugi, gondolom senki sem akar keresztre feszíteni, csak gondoltuk, hátha ti onnan bentről többet tudtok ennek a levélnek a hátteréről. :-)

[nbeeps2]

Nyilván automata rendszer küldi, ha érzékeli, hogy nem kérdezték le az adatszolgáltatást, csak hát a robot téved...

[NTCA-tax]

Köszönjük a jelzéseiteket és észrevételeiteket. Egy olyan dologra hívtátok fel a figyelmet, ami szerintem mindegyik oldal számára fontos. 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.

Amennyiben valami problémát látunk az adatszolgáltatással kapcsolatban, akkor egy tájékoztató levéllel tudjuk az adózókat leghatékonyabban értesíteni, hogy mit lát az adóhivatal. Ebben az issue-ban leírt javaslataitokat mindenképpen felhasználjuk a következő hasonló levélkampányainkhoz.

Azt is látjuk ugyanakkor, hogy sajnálatos módon kapott olyan adózó is levelet, akinél nem áll fenn feltétlenül ez a probléma. Ezért úgy döntöttünk, hogy a jelenleg tőlünk tájékoztató levelet kapott adózóknál október hónapra megismételjük az elemzésünket és annak eredményéről tájékoztatást fogunk küldeni. Ez azt jelenti, hogy ha egy adózó által használt programban október hónapban nem áll fenn a státusz lekérdezés problémája, akkor erről is tájékoztatjuk, illetve természetesen arról is, hogy ha még továbbra is fennáll.

[csaszko]

@NTCA-tax
Ezt láttad? #295

[NTCA-tax]

@csaszko igen, láttam. Ez vonatkozik az utolsó bekezdésemre és nem véletlen, hogy október hónapban akarjuk megismételni az elemzést. Ugyanakkor azt is fontosnak látom, hogy az adózók kapjanak erről pozitív megerősítést is, amennyiben a levélben leírt probléma ténylegesen nem látszik.

[csaszko]

@NTCA-tax Sejtettem, hogy arra vonatkozik, viszont nagyon furcsállom a hozzáállásotokat. Biztosan van olyan aki nem kérdezi le, büntessétek ok. teljesen egyetértek és szerintem mindenki más is így van ezzel, aki normálisan akarja csinálni.
De abban is biztos vagyok, hogy a tegnapi leveletek kapcsán olyanok is érintettek akik lekérdezik rendesen és a Ti rendszeretekben lévő 09.30-ig fennálló hiba miatt, ragadtak bent az email által taglalt státuszban.
Most konkrétan sárral dobálóztatok olyan cégekről is akik nem érdemelték meg, és az a "kijavítása" ennek a dolognak az, hogy ha októberben nem lesz ilyen akkor talán mondotok pár jó szót a következő emailben...
Véleményem szerint az lenne a legkevesebb, hogy azokat a cégeket(adózókat) AZONNAL értesítitek, hogy a hiba nálatok volt és tévesen mentek ki a levelek, akinél nem az összes számla volt feldolgozva státuszban.

[floreagyorgy]

@NTCA-developer , @NTCA-tax
A #295 szerint tehát ez a hiba 2020.09.30 18:19 óta ki van javítva. A kérdésem az, hogy mi lesz az addig a NAV-nál be nem jegyzett Lekérdezett státuszokkal? Ezek mikor lesznek átállítva Feldogozva státuszról Lekédezett-be?

[csaszko]

@floreagyorgy
Nem lesznek, hacsak nem kérdezed le újra azokat még egyszer.
https://github.com/nav-gov-hu/Online-Invoice/issues/295#issuecomment-708193503

[pvmon]

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.

@NTCA-tax Ha már úgyis mindenről levelet küldözget a NAV az adózóknak, miért nem küldi közvetlenül számukra a warningot is? Miért nekünk kell ezzel foglalkozni? Minket terhel feleslegesen ez is, ránk van sózva.
Hogy érthető legyen miért írom ezt bemutatom mi történik egy warning esetén a valóságban. Egy igen gyakori szituáció:

Az Alkalmazott negatív számlát készít, a program szól neki, hogy előzményt nem adott meg és figyelmeztetést fog kapni a NAV-tól. Ő ezt figyelmen kívül hagyja és akkor is elkészíti a számlát, ahogy eddig csinálta.
A program feltölti és letölti hozzá a Warningot, majd ezt jelzi is, hogy figyelmeztetés van a számlára.
Jön a Főnök látja a program üzenetét. Ha ügyesebb tudja hogyan kell megnézni, ha kevésbé akkor már itt telefonál nekünk. Elmondjuk, hogy tudja megnézni, ügyesebbnél kimarad ez a lépés.
Megnézi -> negatív számlára figyelmeztetés - ez mi?
Újra felhív minket, elregéli 10-20 percben, hogy nekik miért is kellett ezt így csinálniuk és hol van erre törvény, hogy nem lehet negatív számla stb.
Nekünk pedig ezt mind végig kell hallgatni a NAV ügyfélszolgálata helyett és nem tudunk és nem is akarunk rá mit mondani, csak azt hogy forduljon a NAV-hoz. (Persze nem fog.)

Már azon is gondolkoztunk, hogy a warningokat nem fogjuk külön jelezni a felhasználóknak, megnézi ha akarja a programban ott lesz lekérve.
Talán nincs előírva, hogy ezt a lekérdezésen kívül, riasztással a programnak jeleznie kell az adózó felé, ha mégis javítsatok ki.

[NyBela]

Én azt javasolom minden ügyfélnek, aki ezt a levelet kapja, hogy tételes kimutatást kérjen, a NAV-tól, mert így általánosságban nem kezelhető a probléma. Pontosan melyik számú számla [számlák] az, amire hivatkozva a levelet kiküldték.
Ez esetben tudunk válaszolni a megkeresésre és a számlák mellett tárolt visszajelzési adatok alapján bizonyítani lehet a lekérdezés tényét.
"Egyes esetekre" hivatkozni értelmetlen. "Intézkedni a hibás működés kijavításáról" csak tények alapján lehet, valamint bizonyítani, hogy melyik oldalon van a hibás működés.

[EnokhSys]

Azt is látjuk ugyanakkor, hogy sajnálatos módon kapott olyan adózó is levelet, akinél nem áll fenn feltétlenül ez a probléma. Ezért úgy döntöttünk, hogy a jelenleg tőlünk tájékoztató levelet kapott adózóknál október hónapra megismételjük az elemzésünket és annak eredményéről tájékoztatást fogunk küldeni. Ez azt jelenti, hogy ha egy adózó által használt programban október hónapban nem áll fenn a státusz lekérdezés problémája, akkor erről is tájékoztatjuk, illetve természetesen arról is, hogy ha még továbbra is fennáll.

@NTCA-tax De ugye érzed Te is, hogy csak így Jocky Ewing módjára nem lehet elintézni ezt az ügyet? :-) Ti nem a fejlesztőknek küldtetek levelet, hanem a partnereiknek azzal a nem is burkolt megállapítással, hogy "köhhöm haver, gáz van a számlázóprogramoddal". Akik pedig alaptalanul kapták meg ezeket a leveleket, azoknak a társadalmi szokás/etika alapján kijár egy "elnézést, elkeféltünk valamit" tárgyú levél, nem utolsó sorban azért, hogy a partnernek ne az legyen a hátsó gondolata, hogy "hümm-hümm, lehet, hogy szar az a számlázóprogram, amit vettem??". Gondolom érzékeled a stílusbeli különbséget a Jocky és Bobby közötti NAV-vezetés között... :-)

[pvmon]

Kedves @NTCA-tax
Akkor kellene leveleket küldözgetni, ha Önök folyamatosan, leállás és hiba nélkül tudnak majd működni egy hónapig. Nem úgy mint ahogy most sem.

[floreagyorgy]

Miután a NAV hibás nyilvántartása szerint a felhasználóink továbbra is folyamatos jogszabályszegésben vannak, joggal elvárható a NAV-tól, hogy ebben az ügyben részletes tájékoztatást adjon ki mind a felhasználók, mind a fejlesztők felé arról, hogy milyen módon és mikorra szünteti meg ezt az állapotot, azaz mikorra fejezi be a számlázó programok által rendben beküldött lekérdezések teljes feldogozását és állítja be a saját nyilvántartásában is a Feldolgozott státuszú számlákat, Lekérdezett státuszúvá. Elfogadhatatlan, hogy ebben az ügyben az egyetlen hivatalos kommunikáció a felhasználóink felé kiküldött, a fejlesztőket kompromittáló levél legyen.

[vajayattila]

Helló!

A tegnapi nap során programunk beküldött egy számlát az éles 2.0-ás rendszerbe, amelynek a sikeres átadásáról nem kaptunk vissza információt (a háttérben a következő tranzakciós ID-t kapta: 35MBTQ4F90JR53FQ ). Mivel a szerver oldalon kiosztott tranzakciós azonosítót nem kaptuk vissza (vagy akár az adatbázisba rögzítés is meghiúsulhat ez most mindegy is), ezért a mi rendszerünk megpróbálta újra beküldeni (tranzakciós ID:35MC6P6ZQSWZJ1M4 ), amelynek eredménye egy "INVOICE_NUMBER_NOT_UNIQUE" hiba volt.

Nos mivel az eredeti tranzakciós ID-ről fogalmunk sincsen, ezért az automatikus javításra esély sincs.
Ilyenkor mi puskázni szoktunk a webes felületről és az ott rögzített valid tranzakciós ID-t rendeljük a számlához a kliens oldalon, amely így ellenőrzési állapotba kerül és a következő ütemezés alkalmával rá fog ellenőrizni a számla státuszára.

Viszont ez így nagyon nem jó, és gyanítom, hogy ez okozhatja a nem ellenőrzött számlák felhalmozódását, hiszen a javításhoz manuális beavatkozásra van szükség.

Mindenképpen szeretném javasolni, hogy a INVOICE_NUMBER_NOT_UNIQUE hiba esetén kapjuk vissza az eredeti, elsikkadt tranzakciós ID értékét is. Ennek az lenne az előnye, hogy az ilyen jellegű hibánál automatikusan tudnánk, hogy mi a számla valid tranzakciós ID-je, ezáltal a számla ellenőrzése automatizálhatóvá válhatna, nem kéne az ügyfél könyvelőjén keresztül megérdeklődni a valid tranzakciós ID-t.

A segítséget előre is köszönöm.

[szako]

Ígéretet kaptunk arra, hogy megvizsgálják ennek a lehetőségét: https://github.com/nav-gov-hu/Online-Invoice/issues/386#issuecomment-700664708 és https://github.com/nav-gov-hu/Online-Invoice/issues/386#issuecomment-700674260

[vajayattila]

Ígéretet kaptunk arra, hogy megvizsgálják ennek a lehetőségét: #386 (comment) és #386 (comment)

Én nem szeretnék feleslegesen új szolgáltatás hívást kezdeményezni, hiszen a INVOICE_NUMBER_NOT_UNIQUE hiba tökéletesen megfelelne a valid transaction ID visszaadására.

[pvmon]

Pontosan ez történik utána meg megy a NAV levél, hogy a program hibás...nem kérdezi vissza a számlákat.
Felmegy de nincs ID. Mi rákérdezünk a számlaszámra is, ott se jön, hogy fent lenne, ezért újra küldjük. Akkor kapjuk, hogy már fent van. Itt be is fejezzük, mert ha hibás lenne, nem lenne fent. ID-t nem kapunk itt sem. Megjelöljük hogy vége. Max figyelmeztetés lehetne rajta, de azt tapasztaltuk, hogy a felhasználók 80%-t az nem is érdekli.
Nem volt még olyan hónap, hogy ne generált volna ilyen helyzeteket leállás miatt a NAV szervere, Sajnos a levélküldőjük viszont mindig vígan működik és nem hangolják össze azzal, hogy mikor van ilyen helyzet a leállásuk miatt.

[vajayattila]

Szerintem az is a valid tranzakciós ID visszaadását indokolja, hogy a szervert ne terheljük feleslegesen lekérdezésekkel. Nem lehet hogy a időkorlátozások bevezetésére pontosan ezek miatt a felesleges hívások miatt van szükség?

Részemről azt az érvet nem tudom elfogadni (ha bárki felvetne ilyet), hogy egy tranzakciós ID visszaadása (amire egyébként is megy egy select, hiszen ellenőrizni kell a számlaszámot), több erőforrásba kerülne, mint hogy az összes kliens kétségbeesett lekérdezéseket indít, hogy a tranzakciós ID-t kisajtolja valahogy a szerverből.

[NTCA-supporter]

Sziasztok!
Az interfész dokumentáció tartalmaz logikai referencia implementációt.
Az issuet zárom, ha van még kérdés nyissátok újra.
Üdv