Closed Charcsi closed 3 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).
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.
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
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.
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)
@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.
@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ó.
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.
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.
@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.
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?
@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.
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.
Sziasztok! Zárom az issuet. Ha van még kérdés nyissátok újra nyugodtan. Üdv
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