nav-gov-hu / Online-Invoice

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

[Q&A] Vevő adószámába a felhasználó beírta a magánszemély adóazonosítóját (régi adat) nem tud a számla felmenni emiatt hogyan zárjuk le? #303

Closed Charcsi closed 3 years ago

Charcsi commented 4 years ago

Az a kérdés hogyha fenn áll ez az eset, mi a korrekt megoldás a szoftver részéről? Nem szeretnénk azt hogy nyitott maradjon a számla a rendszeren belül, de sosem tudjuk feltölteni. Valahogy jelölni kellene a szoftverben ezt a helyzetet. Ebben az esetben a szoftverben lezárhatjuk ezt az adatküldést úgy hogy hibás adat miatt a számla nem feltölthető?

Hiszen ez a számla nem is adatszolgáltatás köteles.

Köszi a választ

Amn3s1a2018 commented 4 years ago

Saját tapasztalat az, hogy ilyen már nem fordul elő akkor, ha

A fenti eset abban különbözhet ezektől, hogy az adóazonosító jel formátuma nem egyezik az adószáméval. Későn jött tanács, de erre az a megoldás, hogy az ilyen számlát nem engeded lezárni.

Ha sztornózod a számlát, akkor két olyan számlád lesz ami elvileg beküldős, gyakorlatilag meg error-t kapsz rá. Az első ilyenekről azt mondták, az ellenőrzést végző mérlegelése alapján dől el, hogy jár-e a bírság, ha pl. csak egy van és történtek lépések, hogy ne is legyen több az meglágyíthatja a szíveket.

Én utólag már nem piszkálnék olyan számlához, amit megpróbáltam beküldeni, de pl. itt mintha ilyesmire utalnának: https://github.com/nav-gov-hu/Online-Invoice/issues/290#issuecomment-654044795

A Te eseted még annyival egyszerűbb is, hogy nem kell annulálni semmit, hiszen sikertelen volt a küldés. Csak átrakod az adóazonosítót a helyére (ha van ilyen meződ) vagy jelölöd, hogy magánszemélyes számla (ha inkább ilyened van).

Charcsi commented 4 years ago

Köszi a választ. Én azt gondolom hogy mindíg előfordulhat olyan eset amikor valami hiba keletkezik az adatokban. Hiába ellenőrzöm az adószámot a nav rendszeréből, ha az a visszatérő érték hogy "Adószám nem létezi". !? (Holott a NAV másik adatbázisában ott van az adószám, és élő.) Nem ltező adószám esetében ne engedjek tárolni partner, számlát??? A felhasználó nem fogja szeretni mert Optenben, e-cegjegyzékben, NAv.gov.hu-n látja hogy élő az adószám. Tehát ellenőrizhetek, de tiltani nem tudok emiatt.

Sajnos nem lehet a felhasználót az adatrögzítésből kizárni és rögzíthet "felelőtlenül adatot". Nem tudjuk úgy levédeni az adatbevitelt hogy mindent tiltun, és szabályozunk. Emiatt simán keletkeznek olyan számlák amik nem küldhetőek be.

Logikusan mi azt szoktuk javasolni (hibától függően), hogy stornó, és csinálja meg helyesen a számlát, és igen ebben az esetben ott lóg a két számla feltöltetlenül. De mivel ott az eredeti, és a stornó így számvitelileg üti egymát nincsen jelentősége. Azt gondolom hogy feltöltés szempontjából sincsen jelentősége hogy felvan e ez a páros hiszen javítás céljából csináltam, azért hogy megfeleljek a törvényi elvárásoknak.

De ez az eset másab abból a szempontból hogy tök felesleges stornózni hiszen nem kell a "helyes" számláról adatot szolgáltatni a magánszemély miatt.

Egyenlőre az ilyen fel nem küldhető esetekre nem találtam korrekt jó megoldást.

omachtandras commented 4 years ago

Egyenlőre az ilyen fel nem küldhető esetekre nem találtam korrekt jó megoldást.

Mi erre bevezettünk egy új állapotot: NAV online felületen kézzel rögzítve. Amennyiben a - programban megfelelő jogokkal bíró - felhasználó úgy ítéli meg, hogy a számla teljes mértékben helyes, és az adatszolgáltatás a NAV oldalán fennálló hiba miatt nem teljesíthető, akkor

  1. a NAV felületén kézzel rögzíti a számlát (a webes felület mindent beenged, mondván kézi számlán bármilyen hibát el lehet követni)
  2. átbillenti a rendszerben a számla állapotát erre az állapotra, onnantól nem próbáljuk meg feladni a számlát.

Az ő felelőssége, hogy hogy dönt, elvileg nem teheti meg, hogy gépi számlát kézzel rögzít, de gyakorlatilag láthatjuk, hogy vannak olyan esetek, amikor a számla jó, mégsem szolgáltatható adat a NAV felé.

Kedvenc példám az, amikor 2010. 01. 01. előtti teljesítési dátumú számlát kellett kiállítani, mert peres ügy volt, és a bíróság most mondta ki, hogy jogos a követelés... Ez a dátum már a validáción elakad, mégis egy olyan számla, ami valós, és védhető, hogy miért most állította ki a társaság.

Amn3s1a2018 commented 4 years ago

Nem nem, azthiszem félreérted. Ha üres adószámmal adod fel a számlát, akkor valami ilyesmit kapsz vissza: WARN: MISSING_HEAD_DATA_CUSTOMER: Vevő adószám (első nyolc karaktere) hiányzik.

Nem tudom pontosan Te mit kaptál, de gyanítom, hogy valami ERROR-t, mivel az adóazonosító jel 10 számjegy és nem 8. Ez egyértelműen elkerülhető lett volna, ha az adószám formátumát ellenőrzöd. Még az 1.0 spec nem is volt kint, de már az volt a mondás, hogy amennyiben a számlázóprogram fejlesztője a minimálisan elvárható gondossággal jár el ERROR nem fordulhat elő.

Az adózó lekérdező használata segíthet abban, hogy ritkábban készüljön problémás (WARN) számla, de igazad van 100%ot ezzel sem lehet elérni (ha pl. pont abban a másodpercben törölnek egy adószámot mikor már épp megnézted), és abban is igazad lenne, hogy egy ilyen ellenőrzés (akár számla lezárás előtt, vagy csak az ügyféladat rögzítésekor) túlmutat az elvárható minimumon. Az adószám formátumát viszont a publikált xsd séma (és az áfa tv.) rögzíti. Ettől eltérőt nem engedhetsz meg, ugyanúgy mint pl. név nélküli ügyfelet vagy mínusz 9.4%-os áfakulcsot. (szerintem)

Charcsi commented 4 years ago

@omachtandras Igen mi is ilyen megoldást választottunk, de mint írtad is gépi számlát kézzel feltölteni nem lehet, ezért keresem a megoldásokat.

Charcsi commented 4 years ago

@Amn3s1a2018 Formátum ellenőrzés van 8-1-2 ha hiányos akkor hiba. Ha az adószám ellenőrő összege nem megfelelő figyelmeztetés hogy ez nem adószám biztos akarod? stb stb Tehát mi mindent megtettünk annak érdekébe hogy helyes adat legyen.

De a felhasználó megoldja mert szerinte be lehet írni az adó azonosító jelet a 13 karakterbe csak kell hozzá 1-2 nulla elől hátul itt ott. Kreativitás van. Figyelmeztetés meg félre rakom. Erről van szó.

omachtandras commented 4 years ago

Igen mi is ilyen megoldást választottunk, de mint írtad is gépi számlát kézzel feltölteni nem lehet, ezért keresem a megoldásokat.

Azt írtam, hogy elvileg nem lehet. :) Szó van arról is a rendeletben, hogy ha a technikai akadály x idő alatt nem hárul el, akkor az adózónak a kézi felületen rögzítenie kell a beküldésre váró adatokat, stb., stb., (nincs előttem a pontos szöveg, elnézést érte...)

Ha a gépi adatszolgáltatás az adózó hibáján kívüli okból nem teljesíthető (márpedig, ha a NAVnál egy olyan gátat tettek a validációba, ami meghiúsítja azt), akkor szerintem védhető akár bíróságon is az, hogy az adózó az egyetlen lehetséges utat választotta arra, hogy a jelentési kötelezettségét teljesítse. Szerintem nem várható el, hogy lemondjon azért az árbevételről, mert olyan esemény történt, amelyet valahol valakik egy specifikáció során lehetetlen eseménynek gondoltak....

Az adószám vs. adóazonosító jel problémára: a CDV ellenőrzés hiba esetén nem figyelmeztetés, hanem megszakítás és kész. Ez olyan erős szabály, amit szerintem nem szabad engedni átlépni.

Amn3s1a2018 commented 4 years ago

Azt írod az issue címében, hogy

nem tud a számla felmenni emiatt hogyan zárjuk le

Lehet hogy velem van a baj, de nem értem. A nem tud felmenni azt jelenti, hogy kaptál egy WARN-t az adószámra? Vagy ERROR-t? Végigböngésztem az api dokumentációt, de nem találom mi lehet az.

Charcsi commented 4 years ago

@Amn3s1a2018 Az Ügyfél elmondása alapján ERORR van. Ma meg fogom nézni a pontos üzenetet.

De az alapvető probléma ettől független. Ha erorros egy számla küldés, de a számla alapvetően helyes, akkor hogyan legyen kezelve tovább? Inkább ez a lényeg.

eszel commented 4 years ago

Szerintem is biztosan hibás Áfa tv.-beli adattartalommal nem kell engedni számlát lementeni.. Átírhatja a végösszeget is, mert szerinte úgy jó és nem az jön ki a tételek összegeként? Nem, ugye?

Amn3s1a2018 commented 4 years ago

@Charcsi sikerült megnézni? Nekem minden felhasználónál adószám ellenőrzés volt, de mivel kikapcsolható, már voltak olyan számlák ami hibás adószámra készült és az onlineszámla egy nagy kövér WARNt adott, nem ERRORt. Persze figyelmen kívül is hagyta a juzer. A vevő meg csak akkor szól, hogy akkor kéri szépen a számla javítását, amikor már hívogatják, hogy kéne fizetni. Simán lehet, hogy szándékosan adta meg tévesen.

NTCA-tax commented 3 years ago

Ez az issue egy kicsit háttérbe szorult, elnézést érte...

Adójogi szempontból a magánszemély adóazonosítója nem kötelező adattartalom és jelentős különbség van az adószám és adóazonosító között (nem csupán hossz szempontjából). Amennyiben magánszemélynek kerül kiállításra számla, az jelenleg nem adatszolgáltatás köteles, jövő évtől pedig név és címadat nélkül kell arról adatot szolgáltatni. Tehát helyes az a megoldás, hogy ha a felhasználó valami miatt adóazonosítót ad meg, akkor nem történik meg a riportálás (egyébként validációnál úgyis elbukik ha az adóazonosító az adószám mezőben szerepel).

Nincs olyan jogszabályi kötelezettség, hogy a belföldi adóalany adószámát a számla kiállítását megelőzően ellenőrizni szükséges. Persze ettől még lehetséges, és ezt adóhivatali oldalról próbáljuk megkönnyíteni, de messze nem kötelezettség. A hibázás elkerülése érdekében lehet persze CDV ellenőrzést is végezni a vevői adószámon, be lehet kérdezni az adóhivatali rendszerbe. Ugyanakkor ha a vevő egy hibás adószámot adott meg, és például ha készpénzes vásárlás történik, akkor előfordulhat olyan eset, hogy nem is fog tudni helyes adószámot megadni. Ugyanakkor ettől még számlakiállítási kötelezettsége van az értékesítőnek.

Tehát a gyakorlatban nem lehet kizárni olyan esetet, amikor hibás vevői adószám kerül rá a számlára. Az ilyen adatszolgáltatásokat befogadjuk, maximum warning-al jelöljük a problémát.

NTCA-supporter commented 3 years ago

Sziasztok! Zárom az issuet. Ha van még kérdés nyissátok újra nyugodtan. Üdv