search

nav-gov-hu / Online-Invoice

Public repository of the Online Invoice System
Other
139 stars 52 forks source link

[Q&A] hibás számlaadat-szolgáltatásról októbertől levelet küld a NAV #912

Closed nbeeps2 closed 2 years ago

nbeeps2 commented 3 years ago

A mai napon jelent meg ez a hír: "A Nemzeti Adó- és Vámhivatal (NAV) a jövőben rendszeresen tájékoztatja az online számlaadat-szolgáltatást küldő adózókat sikertelen vagy figyelmeztetést kiváltó adatszolgáltatásaikról." "Az adózók megkeresése előtt a NAV külön, elektronikus tárhelyre küldött levélben tájékoztatja azokat a szoftverfejlesztőket..."

Ezt a kezdeményezést minden fejlesztő nevében kérem visszavonni vagy újragondolni! A Sikertelen adatszolgálatás rendben van, arról küldjön levelet, akár az adózónak, akár a fejlesztőnek, de a WARN-t ne vegyük már ebbe bele!!! A WARN-os adatszolgálatás sikeres és nem hibás adatszolgáltatást. Leggyakoribb ilyen WARN-os üzenet az adószám kapcsán van, ilyen a felhasználói körünk nagyságát tekintve a havonta több száz is előfordulhat. Nem kívánom, hogy a NAV teleszemetelje a NAV tárhelyünket az ezekről szóló üzenetekkel! Pl. ha valaki egy mai napon alakuló cégnek/egyéni vállalkozásnak számláz, akkor gyakran kap WARN üzenetet az adószámra vonatkozóan, miközben éles/működő adószámról van szó, csak még nincs szinkronizálva a NAV Online számla által vizsgált adatbázissal.

A kérésem, hogy a WARN-okra ne küldjön a NAV üzenetet, csak az ERROR-orokról. Ha van olyan WARN, amit szeretne teljesen elkerülni a NAV, akkor minősítsék át ERROR-nak. Pl. mínuszos végösszegű számlák kiállításának esete, ami nem tiltott, nem kap ERROR-t csak WARN-t, a programban figyelmeztetés mellett ilyen kiállítható, de én ezekről, mint fejlesztő nem kívánok tájékoztatást kapni, engem ne SPAM-eljen a NAV, nem járultam/járulok hozzá!

omachtandras commented 3 years ago

Sziasztok!

Jó lenne mintát látni. Ez egy aggregált levél lesz, vagy minden ügyfelünk esetében külön kapunk, ha az éppen kiszemelt hibát / warningot ő előidézi. Azt is jó lenne tudni, hogy milyen hibák vannak a fókuszban. Az pl. pozitív kommunikáció lehetne az ügyfeleink felé, hogy ha tudnánk, hogy most ezek a fókuszok, és lám, ha Te nem kaptál levelet, akkor biztos lehetsz benne, hogy jól csinálod a dolgokat, jó a szoftvered. Nálunk az ügyfél maga kap visszajelzést a szoftverünktől (ha a normál lekérdezési lehetőség mellett ezt kéri) e-mail-ben, ha error vagy warning egy adatszolgáltatás. Ez alapján nyilván megkeres és egyeztetünk, hogy szoftver hiba vagy ő csinál valami olyat, amit nem feltétlenül kellene. De, ha ez warning, akkor nincs semmilyen jog korünk arra, hogy azt mondjuk neki, hogy ne csináld, ha ő az törvényesnek gondolja...

Biztos sokan nem így járnak el, és vannak tömeges típushibák, ezt nem kétlem, de pl. a közüzemi cégeink még mindig negatív elszámoló számlát állítanak ki, mert megakadt az általunk jelzett probléma NAV oldalon és még mindig nincs rá megoldás, így élesíteni sem tudjuk náluk a fejlesztést. Igazán nem szeretnénk ez miatt (sem) a szőnyeg szélére kerülni. :)

sinick2 commented 3 years ago

Ha végigolvassátok, akkor

"Az adózók megkeresése előtt a NAV külön, elektronikus tárhelyre küldött levélben tájékoztatja azokat a szoftverfejlesztőket, akiknek adószáma a 2021. augusztusi sikertelen adatszolgáltatási kísérletekben a fejlesztő adószámaként (softwareDevTaxNumber[1] elem) megjelenik."

nbeeps2 commented 3 years ago

" De, ha ez warning, akkor nincs semmilyen jog korünk arra, hogy azt mondjuk neki, hogy ne csináld, ha ő az törvényesnek gondolja..." Pontosan!!!

"Igazán nem szeretnénk ez miatt (sem) a szőnyeg szélére kerülni. :)" Dettó! Én sem akarom, hogy a NAV lejárasson minket a felhasználók előtt!!!

nbeeps2 commented 3 years ago

Ha végigolvassátok, akkor

Az adózók megkeresése előtt a NAV külön, elektronikus tárhelyre küldött levélben tájékoztatja azokat a szoftverfejlesztőket, akiknek adószáma a 2021. augusztusi sikertelen adatszolgáltatási kísérletekben a fejlesztő adószámaként (softwareDevTaxNumber[1] elem) megjelenik.

sinick2, ha végigolvasod, amit írtam, akkor pont ez a bajom. Engem ne SPAM-eljen a NAV a WARN-ok miatt!!!

sinick2 commented 3 years ago

@nbeeps2: Na, akkor még egyszer ...

"sikertelen adatszolgáltatási kísérletekben"

Azaz WARN-okért nem kapsz!

nbeeps2 commented 3 years ago

sinick2: Akkor fussunk neki még egyszer ;)

"A Nemzeti Adó- és Vámhivatal (NAV) a jövőben rendszeresen tájékoztatja az online számlaadat-szolgáltatást küldő adózókat sikertelen vagy a figyelmeztetést kiváltó adatszolgáltatásaikról."

Ez alapján megy a levél az ERROR-ról és a WARN-ról, és a "adózók megkeresése előtt a NAV külön, elektronikus tárhelyre küldött levélben tájékoztatja a szoftverfejlesztőket", tehát kapok belőle én is.

Macskafarka commented 3 years ago

Szerintem is értelmezgetni kell a NAV kinek mit küld. A közlemény többféleképpen érthető. Az első része az adózók felé küldendő üzenetről szól, a második fele pedig a szoftverfejlesztőknek küldendőről, de ez utóbbi csak egyszeri alkalmat takar, a 2021 augusztust. Ha kiderülne, az, hogy WARN-ról is küldenek a szoftverfejlesztőknek, akkor azt a leghatározottabban visszautasítom, mivel sikeres az adatszolgáltatás, és a WARN mögött sok esetben a NAV adóértelmezése áll. Nekünk NEM feladatunk jogértelmezésben tanácsokat adni az ügyfeleinknek.

topybear commented 3 years ago

Akkor fussunk neki ismét :)

"A Nemzeti Adó- és Vámhivatal (NAV) a jövőben rendszeresen tájékoztatja az online számlaadat-szolgáltatást küldő adózókat sikertelen vagy a figyelmeztetést kiváltó adatszolgáltatásaikról."

Azaz a hibáról és a figyelmeztetésről az adózókat. Ebből a fejlesztő nem kap.

"Az adózók megkeresése előtt a NAV külön, elektronikus tárhelyre küldött levélben tájékoztatja azokat a szoftverfejlesztőket, akiknek adószáma a 2021. augusztusi sikertelen adatszolgáltatási kísérletekben a fejlesztő adószámaként (softwareDevTaxNumber[1] elem) megjelenik."

Azaz csak egy levél és csak akkor, ha a sikertelen adatszolgáltatások közt megjelenik az általa fejlesztett szoftver.

Szerintem :)

Macskafarka commented 3 years ago

A NAV közleményekről korábban már bebizonyosodott, hogy hajlamosak "megváltozni". Amúgy érdekes lenne, ha egy szoftverfejlesztő cég erről példát véve rendszeren tájékoztatná az ügyfelei arról, hogy a NAV üzeneteit ő hogyan értékelte. Pl. valós, vagy csak a NAV által generált műprobléma.

nbeeps2 commented 3 years ago

topybear: Legyen így, de az is lehet, hogy az egyszerűbb megfogalmazás végett már nem tették be a közlemény másik részébe a figyelmeztetéseket, mert az első részében már szerepelt. Ugyanakkor az sem mindegy, hogy a WARN kapcsán a felhasználónak milyen megfogalmazású levelet küld majd a NAV és mennyire sugallja vele, hogy hibásan működik a program...

omachtandras commented 3 years ago

A NAV közleményekről korábban már bebizonyosodott, hogy hajlamosak "megváltozni". Amúgy érdekes lenne, ha egy szoftverfejlesztő cég erről példát véve rendszeren tájékoztatná az ügyfelei arról, hogy a NAV üzeneteit ő hogyan értékelte. Pl. valós, vagy csak a NAV által generált műprobléma.

Szerintem ilyenekbe ne menjünk itt bele, mert nem viszi előre a dolgokat.

nbeeps2 commented 3 years ago

Idézet a NAV márciusban kiadott számlázó program ajánlása kapcsán: "A figyelmeztetések a számlázó szoftver legkörültekintőbb kialakításával sem előzhetők meg teljeskörűen (ellentétben a hibákkal)" ...

DrotosTot commented 3 years ago

Nekünk ma megérkezett a cégkapus tárhelyünkre a hivatalos levél is a NAV-tól, mely szerint: "Ezt a levelet azért kapta, mert az Ön adószáma szerepelt a számlázóprogram fejlesztőjének adószámaként (softwareDevTaxNumber elem) a 2021. augusztus 1. és 31. közötti sikertelen online számlaadat-szolgáltatási kísérletek legalább egyikében."

@nbeeps2: "Az eddigi tapasztalatok azt mutatják, hogy az adatszolgáltatás sikertelensége döntő többségében a számlázószoftver programozási hibájára vagy hiányosságára vezethető vissza."

nbeeps2 commented 3 years ago

@DrotosTot "Az eddigi tapasztalatok azt mutatják, hogy az adatszolgáltatás sikertelensége döntő többségében a számlázószoftver programozási hibájára vagy hiányosságára vezethető vissza." Ezzel egyet is értek. Nekem az elejétől kezdve a WARN-okkal van a bajom... Viszont létezik egy nagyon gyakori sikertelenségi ok, ami NEM a számlázó program programozási hibája, ez pedig a több helyen feltelepített program vagy újratelepített program mentés visszatöltés nélkül, ahol a számla kiállítója megsérti a számlasorszámozást, mert kiállít mondjuk egy 14-es számlát úgy, hogy már előtte állított ki 14-est. A számlázó program gyorsabb működése érdekében nem elvárható, hogy minden számla kiállításakor ellenőrizze a NAV rendszerben az utolsó sorszámot és ez nem is lenne feltétlen mindig pontos (üzemszünet, lassulás, stb.). Szóval a felhasználó felelőssége, hogy ha újratelepíti a programot és nem volt mentése vagy friss mentése, akkor megfelelően állítsa be a számla kezdősorszámát vagy másik számlatömbben számlázzon.

sinick2 commented 3 years ago

@NTCA-supporter: Kérdésem az lenne, hogy akkor is megy a figyelmeztetés, ha a számla először el lett utasítva, majd később be lett küldve?

Ezek tipikusan azok az esetek, amikor a technikai felhasználó csak lekérdezhet vagy csak bizonyos vevő adószámokat küldhet be vagy számla módosításkor a készítés és küldés között az alapszámlára technikai érvénytelenítést indítottak.

DrotosTot commented 3 years ago

@nbeeps2 : Szerintem mindenben egyetértünk. A NAV márciusi ajánlására reflektáltam, hogy az akkori és a mostani levelükben foglaltak kissé eltérnek egymástól.

nbeeps2 commented 3 years ago

"A NAV először várhatóan 2021. október végén személyre szóló levelet küld az adózóknak elektronikus tárhelyükre a 2021. szeptemberi számlaadat-szolgáltatásukban előfordult hibák miatt létrejött jelzésekről és figyelmeztetésekről. Emiatt kérjük, számítson arra, hogy ügyfelei keresni fogják Önt, illetve Társaságát"

nbeeps2 commented 3 years ago

A fenti üzenet kapcsán kérném, hogy a NAV vágja be ide azt a levélsablont, amit a felhasználóknak ki fog küldeni. Ugyanis semmiképpen nem szeretném, hogy a NAV lejárassa a céget, pl. azzal, hogy programhibának állítja be a sikertelen adatszolgáltatást, pl. egy ehhez hasonló szöveggel, amit egyelőre nekünk szántak: "Az eddigi tapasztalatok azt mutatják, hogy az adatszolgáltatás sikertelensége döntő többségében a számlázószoftver programozási hibájára vagy hiányosságára vezethető vissza"

Ahogy már feljebb kifejtettem egyáltalán nem csak olyan vezet ERROR-hoz és WARN-hoz, ami programozási hiba lenne, szóval nem kellene ezzel dobálózni, mert ezt ha így ebben a formában az ügyfélnek küldik el, az ki fogja meríteni a hírnév rontást, ami jogi következményekkel jár!

Macskafarka commented 3 years ago

@nbeeps2 Mintha a nevemben szóltál volna!

nbeeps2 commented 3 years ago

Nem - minden esetben - programozási hibából blokkoló validáció hibakódok: SUPPLIER_TAX_NUMBER_MISMATCH INVOICE_NUMBER_NOT_UNIQUE INVALID_INVOICE_REFERENCE INVOICE_TYPE_MISMATCH INVOICE_LINE_ALREADY_EXISTS ANNULMENT_IN_PROGRESS CUSTOMER_NOT_ASSIGNED LINE_NUMBER_REFERENCE_NOT_UNIQUE MODIFY_WITHOUT_MASTER_MISMATCH

A fenti hibakódok esetén NE küldjön a NAV levelet az adózónak vagy legalábbis semmiképp ne utaljanak arra, hogy ez programozási hibára vezethető vissza!

A fenti kódok nagy része előhozható az alábbi szituációban egy TÖKÉLETESEN működő programban. Felhasználó számláz: 1-100-ig sorszámtartományban, ezek közül vannak normál számlák, helyesbítők, stornók, minden. Majd az ügyfélnek ellopják a laptopját vagy vírusos lesz, mindegy. Újratelepíti a programot, visszatölt egy korábbi mentést, amiben 72-nél járt a sorszámozás. Elfelejt beállítani új számlatömböt. Vagy teljesen üresen kezdi meg a program használatát egy másik telephelyen és szintén nem állít be számlatömböt, Vagy teljesen üresen kezdi meg a program használatát az új laptopján és nem állít be nyitó sorszámot. Elkezd számlázgatni , stornózni, helyesbíteni és szépen kapja majd a fenti üzenetek közül nagy részét (de természetesen nem mindegyiket ez eset alapján írtam, de mindegyiknek oka van és bármelyik - főleg offline/dekstop - programban előhozhatók).

A kérésem tehát az lenne, hogy csak olyan esetben küldjenek levelet a felhasználónak, ahol egyértelműen programhiba van (pl. nem sémavalid XML).

A WARN-okat is jól át kell gondolni. A mi saját rendszerünkben a legtöbb ilyen WARN-t a vevő adószáma alapján kapjuk. A vevő adószáma érvényes, ezt ellenőrzik a kollégák minden számla kiállításakor külsős/hivatalos nyilvántartásokban, de NAV még nem frissített, nem naprakész adatbázis WARN-t ad az adószámra, hogy pl. nem érvényes, holott az. Ez legtöbbször az aznap alakul vállalkozásoknál figyelhető meg. A másik pedig a negatív előjelű normál Create számla, amire eleve figyelmeztetést küld a program, hogy nem kéne, de a felhasználó a saját felelősségére kiállíthat ilyen számlát. Továbbra is az a véleményen, hogy ha NAV valamit el akar kerülni, akkor a WARN-t minősítse át ERROR-ként és akkor be lehet építeni ellene védelmet, de ameddig WARN egy WARN, addig azzal SENKI nem fog foglalkozni, mert az adatszolgáltatás sikeres lesz.

Szóval erősen szelektálni kellene, hogy milyen ERROR-ok és milyen WARN-okról szóljon a tájékoztatás és ne így nagy általánosságban beszéljünk erről a két csoportról, hanem szűkítsük le őket.

omachtandras commented 3 years ago

Nem tudom, hogy ki hogy van vele, mi kaptunk levelet az ügyfélkapun, hogy volt hibás adatszolgáltatás a szoftverünkkel. A levélben SEMMI KONKRÉTUM nem volt. Sem az, hogy mely adószámon történtek hibás adatszolgáltatások, sem az, hogy milyen hibák voltak, ha mondjuk az adószámokat valamilyen oknál fogva nem akarta megadni a NAV.

Tudomásunk szerint az érintett időszakban egyetlen hiba volt a NAV felé, ami kezelői hiba volt, de ez most mellékes is, mert NEM TUDTUNK MEG SEMMIT A LEVÉLBŐL, amivel tudtunk volna kezdeni valamit. Javítani a programot, ha tényleg hibás (vagy legalább elgondolkodni rajta, hogy vajon hogy idézhette elő bárki azt a hibát, ha mi azt gondoljuk róla, hogy elvileg van ellene védelem a programban...), vagy egyeztetni az ügyfelekkel, hogy mit is csinálnak, mint módosítsanak a számlázási folyamatukon, stb. stb.

Ez így semmit nem ért, ettől a fejlesztőknek küldött levéltől semmit nem tudott javulni az adatszolgáltatás minősége, még akkor sem, ha erre mondjuk az adott fejlesztőnél a szándék meglenne.

nbeeps2 commented 3 years ago

@omachtandras Ez így van, én is ezt tudom alátámasztani. Nálunk az INVOICE_NUMBER_NOT_UNIQUE mindennapos eset az ügyfélszolgálaton a fent vázolt eset miatt. Így e kapcsán biztosan kaphattuk a levelet, de amúgy meg semmi konkrét nem volt benne, mondjuk ilyen esetben úgyis az ügyfél keres minket. Itt ami felesleges sz*rkavarás a NAV részéről az a WARN-okkal való szivatás, hogy ráuszítják a felhasználókat a programozókra.

renced42 commented 3 years ago

Kedves @nbeeps2, szerintem a kontextusból kiragadott bekezdést követő bekezdést is be kellene ide vágni :) , szerintem úgy kerek a történet. A WARNOK-ról biztos nem küld a NAV semmit, Az ERROR-ok esetében pedig biztos szelektálni fognak a kollégák. Amiket itt leírtál azzal a NAV is tisztában van, de valahogy muszáj csökkenteni a hibás adatszolgáltatásokat is. A javaslatokat mindig szívesen fogadjuk, azt is amit most leírtál. Köszönjük szépen :)

nbeeps2 commented 3 years ago

@renced42: hogy érted, hogy a WARNOK-ról biztos nem küld a NAV semmit? Ez egyértelműen benne van, hogy küldenek azokról is. "A Nemzeti Adó- és Vámhivatal (NAV) a jövőben rendszeresen tájékoztatja az online számlaadat-szolgáltatást küldő adózókat sikertelen vagy figyelmeztetést kiváltó adatszolgáltatásaikról"

Ez a következő bekezdés: "Kérjük, a következő időszakban kísérje kiemelt figyelemmel az Ön által fejlesztett vagy forgalmazott számlázószoftverben az Online Számla rendszer által küldött visszajelzéseket, ha ezekre az adatokra rálátása van. "

Nincs rálátásunk. Nem látok rá az ügyfelek adatára. Szerintem ott a gond, hogy a NAV saját magából indul ki, viszont nem veszi figyelembe, hogy Magyarországon sokkal több az offline számlázó/készletező rendszer, mint az online.

renced42 commented 3 years ago

hogy érted, hogy a WARNOK-ról biztos nem küld a NAV semmit? Ez egyértelműen benne van, hogy küldenek azokról is.

Úgy értem, hogy egyszer biztos lesz ilyen, de ha már csak Warningok lesznek a rendszerben :) . Logikusan az ERROR-kat kell először megszüntetni vagy lecsökkenteni.

NTCA-tax commented 3 years ago

Még egy régebbi levélkampánynál fejlesztőktől kaptunk olyan visszajelzést, hogy jó lenne ha egy nagyobb ügyfélszámot érintő kampányt megelőzően küldenénk Nektek előzetes tájékoztatást. Nem néztem most vissza a GitHub-on, de előfordulhat, hogy itt is van nyoma ilyen felvetésnek, ugyanakkor ez a javaslat nagyon megragadt a mi oldalunkon.... A fő érv akkor az volt, hogy Nektek is fel kell készülni arra, ha az ügyfeleitek Titeket esetleg a szokásosnál nagyobb érdeklődéssel keresnek. A Nektek szóló előzetes tájékoztató levélnek épp ez az üzenete. Ezt követően pedig az érintett vállalkozásokat tájékoztatjuk a konkrét hibaokokról.

A jelenlegi levélkampányban kizárólag a manageInvoice művelet error szoftver problémára visszavezethető eseteit néztük meg 2021. szeptember hónapra. Ahol találtunk ilyen problémát és a szoftver azonosítók alapján azonosítani tudtuk a fejlesztőt, őket meg is tudjuk közvetlenül szólítani, ahol nem, számukra pedig ott a sajtóhír. Október végén az ügyfelek megkapják a tájékoztató leveleinket, melyben részletesen bemutatjuk nekik milyen error-al érintettek és ennek mi lehetett az oka.

A cél nem a bünti, hanem a problémák kijavítása. Később megvizsgáljuk az érintett vállalkozásokat, hogy a probléma még továbbra is fennáll-e, és nagyon reménykedünk benne, hogy ezek az érintett error-ok a statisztikai hibahatáron belül fognak akkor már maradni. Biztosan fogtok találni olyan esetet, amit mi programhibának gondoltunk, Ti pedig részletesen leírjátok miért felhasználói hiba, de ennek aránya remélhetőleg nagyon elenyésző lesz. Itt ténylegesen azokra az error-okra fókuszáltunk, amelyeket nem vagy iszonyatosan nehéz felhasználói oldalon előállítani, hanem sokkal inkább szoftverprobléma lehet.

omachtandras commented 3 years ago

@NTCA-tax : én / a mi cégünk maximálisan az mellett van, hogy legyenek a hibák javítva. Ha nálunk vannak, akkor nálunk is (azért régebben nálunk is volt olyan, hogy ügyfél fél év után vette észre, hogy van nem teljesített adatszolgáltatása, hiába kapott róla naponta levelet a rendszertől....), ha máshol, akkor meg máshol, mert az ügyfeleink szeretnének jó minőségű adatokból automatikusan számlákat feldolgozni.

A levélből: "Ezt a levelet azért kapta, mert az Ön adószáma szerepelt a számlázóprogram fejlesztőjének adószámaként (softwareDevTaxNumber elem) a 2021. augusztus 1. és 31. közötti sikertelen online számlaadat-szolgáltatási kísérletek legalább egyikében. "

Tehát, augusztusban volt valami, nem szeptemberben. Lehet, hogy az ügyfelek szeptemberről kapnak. De ez nem is annyira fontos.

Az előzetes tájékoztatás jó lehet, csak legyen benne a levélben, hogy mivel volt baj ÉS, ha lehet KINÉL (adószám). Hogy tudjunk vele valamit kezdeni. Esetleg, mire kiküldenétek ki is derülne, hogy azt a hibát mégsem kellene bevenni a halmazba, ahogy @nbeeps2 írta.

Mert ezzel a levéllel, most semmit nem tudtunk sajnos.

Köszi!

NTCA-tax commented 3 years ago

Bocs, az időgépemet lelassítom :)

Amit írtál egy előzetes levél volt, hogy tudjál a problémáról. A szeptemberi elemzésnek az eredményét is meg fogod kapni, no én erről értekeztem az előbb... Ebben a levélben benne lesz az error kódja, valamint az érintett softwareID vagy softwareID-k.

omachtandras commented 3 years ago

@NTCA-tax : ha lehet még egy beküldő adótörzsszámot is csapjatok hozzá. :)

Köszi! :)

NTCA-tax commented 3 years ago

A felvetés teljesen jogos, de erre sajnos nem látok reális esélyt, mivel ennek jogi problémái vannak...

nbeeps2 commented 3 years ago

Jó hír akkor, hogy ezek szerint a WARN-ról nem kapnak külön ilyen levelet a felhasználók, mert ezek generálnák a több megkeresést felénk, mivel erre rálátásunk sincs, hogy mennyi WARN-t produkál az ügyfél, mondjuk a fentebb említett adószám vagy negatív számla esetekből. Az ERROR-okról eddig is tudtunk, mert ilyen esetben a felhasználó szinte azonnal hív minket, hogy mi a gond és akkor derül ki a szintén fent említett számlasorszámozási eset, hogy ő volt a figyelmetlen.

Nekem csak egy nagyon fontos kérésem van, hogy a megfogalmazás semmiképpen ne ez legyen, mint amit nekünk fejlesztőknek küldtetek: "Az eddigi tapasztalatok azt mutatják, hogy az adatszolgáltatás sikertelensége döntő többségében a számlázószoftver programozási hibájára vagy hiányosságára vezethető vissza"

Ha én lennék a felhasználó egyből azt gondolnám, hogy hibás a programom, egy bugos valamit használok, majd jól lecserélem. Negatív marketing. Szóval kérlek fogalmazzatok óvatosabban, pl. hogy "Az adatszolgáltatás hiba a program nem rendeltetésszerű használatából is adódhat, így amennyiben még nem tette, úgy vegye fel a szoftverkészítőjével a kapcsolatot, hogy a későbbiekben elkerülje a hasonló üzeneteket."

Macskafarka commented 3 years ago

@NTCA-tax viszont így nincs sok értelme. Kb. annyit lehet megtudni, hogy a szoftverünk használói közül valakinek valami problémája van. Kinek és mi?

NTCA-tax commented 3 years ago

@Macskafarka a mitre a választ meg fogod kapni a szeptemberi adatok alapján, a kinekre a választ nem tőlünk, hanem az ügyfeleidtől.

@nbeeps2 a javaslatodat továbbítom.

sinick2 commented 3 years ago

@NTCA-tax: 12 napja kérdeztem, de még nem kaptam választ, ezért szeretném újra megkérdezni azt, hogy akkor is megy a figyelmeztetés, ha a számla először el lett utasítva, majd később be lett küldve?

peacefuldev commented 3 years ago

@NTCA-tax itt is jelezni szeretném, hogy hiába valósítottuk meg a dokumentációban leírtakat, továbbra is időről időre belefutunk az INVOICE_NUMBER_NOT_UNIQUE duplikált bejelentésből eredő hibába, amit nagyon nehéz debug-olni! A 735-ös Issue-ban jelzett kérdésre (https://github.com/nav-gov-hu/Online-Invoice/issues/735), ami szerintünk lehet a probléma oka, majd egy éve nem válaszoltak. Ennek fényében nagyon inkorrektnek tartom hasonló levelek kiküldését az ügyfeleknek, miközben szupportot nem adnak egy hibás tervezésből eredő problémára!

betasofthu commented 3 years ago

A 891-es Issue-ban jelzett kérdésemre (#891) még én sem kaptam kielégítő választ, ami szintén az INVOICE_NUMBER_NOT_UNIQUE duplikált bejelentésből eredő hibával kapcsolatos. A queryInvoiceData a NAV szerver üzemzavara esetén hibásan működik emiatt küldi be újra a program az adatszolgáltatást. Normál esetben jól működik.

nbeeps2 commented 3 years ago

@peacefuldev @betasofthu : erre megoldást nyújt(hat) @renced42 válasza: "Az ERROR-ok esetében pedig biztos szelektálni fognak a kollégák. Amiket itt leírtál azzal a NAV is tisztában van, de valahogy muszáj csökkenteni a hibás adatszolgáltatásokat is."

Az INVOICE_NUMBER_NOT_UNIQUE-ot tehát ki kell szedni azok közül az ERROR-ok közül, amikről értesítik a felhasználót. A felhasználót a számlázó program így is értesíti a sikertelen adatszolgáltatásról és ott látja ennek okát is. A NAV-os figyelmeztetőnek akkor lehet valós szerepe, ha olyan ERROR keletkezik, ami kifejezetten a számlázó program hibájából jön elő, pl. XML séma hiba. Mondjuk ezekről is értesül a felhasználó a számlázó programból és ilyenkor így is, úgy is felveszi a kapcsolatot a fejlesztővel, így nem tudom van-e értelme a NAV-nak bármiről is levelet küldeni...

omachtandras commented 3 years ago

@nbeeps2 : szerintem van. Élek a gyanúperrel, hogy van jó néhány olyan szoftver, ami nem jelzi, ha hiba van. Sőt, simán lehet az is, hogy jelzi / jelezné, csak éppen senki nem foglalkozik vele az adott cégnél. Mi jártunk úgy, hogy a felhős környezetünkben kaptuk a riasztást, hogy nem él már az ügyfél e-mail címe, amit beállított az errorok/warningok esetén. Megkerestük őket, kiderült, hogy a kolléga már jó ideje nem dolgozik ott, csak most törölték az e-mail címét. A korábbi levelek meg ott pihentek a postafiókjában, senki nem emlékezett már rá, hogy ő kezelte ezt a területet. És még biztos rengeteg olyan eset van, amiről nem tudunk.

A több irányból történő figyelmeztetés jó dolog, csak tényleg az a fontos, hogy ne a fejlesztők legyenek megjelölve, mint a hiba oka. De erre kaptunk ígéretet.

NTCA-tax commented 3 years ago

Utána érdeklődtem a kollégáknál, a INVOICE_NUMBER_NOT_UNIQUE nem fog szerepelni az ügyfeleknek menő error tájékoztatásban.

nbeeps2 commented 2 years ago

Na ma volt egy érdekes eset, ami kapcsán javasolnám kiegészíteni a NAV tájékoztató levelét, amit a felhasználónak(!) küld, hogy szerepeljen benne a szoftver fejlesztő és a program neve!

Minden NAV adatszolgáltatásnak ugyanis kötelező tartalmi eleme a következő:

Az eset pedig a következő volt. Felhasználó megkeresett minket és átküldte, hogy milyen levelet kapott a NAV-tól. Ebben az szerepelt, hogy több mint 1000(!) alkalommal ERROR-ra futott az adatszolgáltatás szeptemberben, ami viszont azért tart érdekesnek, mert ő a programban mindent rendben lát, annyira, hogy még idén nem is hívta fel az ügyfélszolgálatunkat, tehát soha semmi gondja nem is volt a beküldéssel SOHA. Megvizsgáltuk az állományát és azt láttuk a logokban, hogy egyetlen egy alkalommal sem(!) volt számla adatszolgáltatás hibája az ügyfélnek, nem hogy 1000...

Ezzel bebizonyosodott, hogy nem a mi programunk generálta ezeket az ERROR-okat, viszont az ügyfél azért minket keresett meg, mert a mi programunkat használja. Két magyarázat létezik:

Összegezve sokat segítene, ha a NAV az ilyen levelében tájékoztatná a felhasználót, hogy MILYEN programról van szó, mi annak és a fejlesztőnek a neve, mivel ez minden számla adatszolgáltatásban benne van. Szerencsére sikerült meggyőzni a felhasználót, hogy nem a mi programunk a hibás, de nem szeretnénk, ha mindig bizonygatni kéne az igazunkat, szóval jó lenne konkrét programnevet és fejlesztőnevet beleírni, hogy melyik programmal lehet a gond, mert az sem ritka, hogy egy cég akár többféle rendszerrel is dolgozik.

EPluribusUnum commented 2 years ago

További hasznos dolgok amik mehetnének a levélbe :

omachtandras commented 2 years ago

@nbeeps2 : azt meg tudod mondani, hogy mi volt a konkrét error?

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

nbeeps2 commented 2 years ago

@nbeeps2 : azt meg tudod mondani, hogy mi volt a konkrét error?

(#922)

INVALID_INVOICE_REFERENCE

A cégnek amúgy 4 stornó/módosító számlája volt, mind a 4-nek sikeres lett az adatszolgáltatása... Viszont a NAV levélében 1000-nél is több INVALID_INVOICE_REFERENCE hibát írnak... Aminek semmi nyoma nincs a programban, szóval ezt valami mást generálta, csak az ügyfél azért nekünk továbbította a NAV levelet, mert a mi programunkat használja. Ezért kár, hogy nincs benne a NAV-os levelében a program neve, mert akkor látta volna az ügyfél már elsőre is, hogy nekünk ehhez semmi közünk.

nbeeps2 commented 2 years ago

Közben kiderült - amit mi is sejtettünk -, hogy egy teljesen másik program generálta ezeket a hibákat, még pedig a felhasználó cég könyvelő programja, amiben szintén volt számlázási funkció. Szóval ezért is lenne jó, ha a NAV-os levél kiegészülne azzal, hogy melyik program generálta a hibákat és akkor elkerülhetők ezek a félreértések és gyanúsítgatások.

NTCA-supporter commented 2 years ago

Sziasztok! Ezt zárom, kérdés esetén nyissatok újat kérlek. Üdv