Online-Invoice
Online-Invoice copied to clipboard
nav-gov-hu
NAV-ajánlás a számlázó programok fejlesztőinek[DEV support]
A NAV összeállította azt az ajánlást a számlázó programok fejlesztői számára, ami támogatja a programok jogszerű és eredményes működésének kialakítását, valamint az online számlaadat-szolgáltatási kötelezettség teljesítését.
A dokumentum ismerteti a számlázó programok működésével kapcsolatos legfontosabb követelményeket, valamint javaslatokat, tanácsokat, tippeket ad az elvárt és célszerű működés kialakításához is. Mindehhez a NAV figyelembe vette az adózói és fejlesztői kérdéseket, visszajelzéseket, az online számlaadat-szolgáltatás elemzéseinek tapasztalatait és az ellenőrzésekben feltárt hiányosságokat is.
Az ajánlás a következő linken érhető el: link
Az adóhivatal a számlázó programok fejlesztőinek az ajánlásról online konferenciát tart 2021. március 10-én 14 órától.
Az ajánlással kapcsolatban ebben az issue-ban 2021. március 8-ig feltett kérdéseket, észrevételeket, megjegyzéseket áttekintjük és a konferencia során ki fogunk rájuk térni. Ezt azért is fontos addig megtennetek, mivel a konferencián közvetlen hozzászólásra nem lesz lehetőség.
Az online rendezvényt Microsoft Teams alkalmazással a következő linken tudjátok elérni: link
A részvételhez előzetes jelentkezés, regisztráció nem szükséges. Esetleges technikai problémák esetén a GitHub ezen felületén adunk tájékoztatást a továbbiakról.
Az 49. ajánlás b) pontja: Készpénzes fizetés esetén a teljesítés dátuma korábbi, mint a kiállítás dátuma. Kérdésem: Ez ugye csak figyelmeztetés legyen, mert valójában normál számla esetén megengedett a két dátum különbözősége a készpénzes fizetési mód esetén is? Indoklás: Az áfa törvény nem tartalmaz előírást a két dátum egyezőségére. Ez egy elterjedt tévhit, hogy a "készpénzes számlán" meg kell egyezni a két dátumnak. Valójában ez csak a "Készpénzes számla" nevű egyszerűsített számla esetén egyezik, mivel itt nem különül el a két dátum. Példa: Vasárnap dugulás elhárítást végez egy vállalkozó alkalmazottja, a vállalkozó épp nyaral. A vállalkozó 3 nap múlva tudja hozni a készpénzes számlát, ami normál számla (tehát nem egyszerűsített) és teljesítés dátumát 3 nappal korábbra állítja mert 8 napon belül van.
A 30-as ajánlás felvezetőjében szerepel, hogy "..el kell kerülni .. a 0%-os adókulcs használatát a számlaképen...", - mert az áfa törvényben nem létezik 0%-os áfakulcs. - Szeretném megyjegyezni, hogy a törvény szerint nem az adókulcsnak kell megjelennie a számlán, hanem az adó mértékének. A kettő nem ugyanaz. Egy adómentes értékesítésnél az adó mértéke éppen nulla.
Ettől függetlenül jó lenne, ha lenne egy egységes és áttekinthető adótábla, amiből csak a megfelelőt kellene kiválasztani a számlasorokhoz. Tudnátok ilye javaslatot készíteni és közreadni? - Nagyon sok energiánkat emészt fel (és sok hibalehetőséget hoz), hogy folyamatosan figyelnünk kell az adót érintő jogszabályváltozásokat.
Az 50-es ajánlásban szerepel, hogy "ha készpénzes számla végösszege eléri vagy meghaladja 1,5 millió forintot és a vevő áfaalany, így fennállhatnak az Art8. 233. § szerinti mulasztási bírság feltételei". Ez csak részben igaz, mert nem számlánként és fizetési módonként kell nézni az 1,5 millió forint készpénzforgalmat, hanem egy naptári hónapban szerződésenként és számla kiegyenlítésenként. Ld. Art. 114 (3).
Azt szeretnénk kérdezni, hogy lesz-e bármilyen lehetőség arra, hogy a NAV rendszeréből hiteles számlát lehessen készíteni. Sok nagy rendszer képes lenne szabályos XML állományt küldeni, de nem képes számlaíró programként működni. Kézenfekvő lenne, hogy a NAV-nál tárolt szabályos számlákból sztenderd papír alapú számlát lehessen készíteni
Az 58-as pontban a "....az informatikailag általánosan elfogadott normák szerint ne legyen túlterheléses támadásként (DoS vagy DDos) érzékelhető" kicsit tág megfogalamazás.
Mivel a leírásban az 1.6-os pontban nem szerepel korlátozás - kivéve a V1-es verzzió bizonyos kérései - lehetne konkretizálni mit szabad és mit nem? Van e most korlátozás a V2 vagy V3 rendszereken Adott intervallumban mennyi kérést lehet a szerver felé, adott IP címről elküldeni? 1 másodperc, 1 perc, 1 óra, 1 nap.
Mi a hajnali órákban, nagyságrendileg 20-30 ezer számla adatát kérjük le sorban egymás után, ami a megelőző 5 nap adattartalma, önellenőrzés és érvénytelenítés és esetleges utólag kiállított számlák követése miatt. Március 1 óta ezen rendszerünk végrehajtási ideje körülbelül ötszörösére nőtt. A kérések 300ms és 20000ms közötti válaszokat mutattak (ez most normalizálódni látszik, de még mindig lassabb mint volt)
Volt e valami változás szerver oldalon ami korlátozza és/vagy lassítja a lekérdezéseket a V3 rendszeren? Van e valami korlátozás amit követnünk kellene, hogy a kéréseink ne kerüljenek "lassításra"?
@csandazoltan "Mi a hajnali órákban, nagyságrendileg 20-30 ezer számla adatát kérjük le sorban egymás után, ami a megelőző 5 nap adattartalma, önellenőrzés és érvénytelenítés és esetleges utólag kiállított számlák követése miatt." Ennek mi az oka? Mi annyit teszünk, hogy az insDate (NAVhoz történő beérkezés időpontja, nem a számla keltje) alapján kérünk le, mindig tudva, hogy mi volt az utolsó, amit már lekértünk. Ha valaki anulál és újra felad, akkor az insDate miatt bekerül a halmazba, nincs szükség x napra visszamenőleg próbálkozni, hogy vajon mi maradt ki. Tapasztalatunk szerint ez a megoldás teljesen megbízhatóan működik, nem jelezte még senki, hogy a kezébe olyan számla lenne, amit a program nem töltött fel, de ha kézzel adja meg az adatait, akkor megtalálná és le tudná tölteni "pluszban".
@omachtandras A számlázó programunkat ellenőrizzük több szempontból is. Bejövő és kimenő számlák is Szükségünk van egy teljes és pontos képre, hogy mi van a NAV rendszerében, mi nincs és mi módosult.
- Többszörös beküldés - valamilyen okból - figyeljük a MULTIPLE_QUERY_RESULT_FOUND hibaüzenetet (ez data)
- Technikai érvénytelenítés - Azok a számlák amik érvénytelenítve lettek, azok eltűnnek a listáról így a mi le tudjuk tárolni, hogy érvénytelen, nekem itt githubon azt írták a segítők, máshogy nem lehet listázni az érvénytelenített számlákat (ez digest)
insDate nem rossz. de az nem, fedi az érvénytelenített számlákat Ez a rendszer megy nálunk V2 óta, eddig nem volt gond. Most álltunk át V3-ra elsején.
Most a insDate-es is lassú lenne, mert 2-3 ezer számla, a megnöveketett 10mp-es átlagos válaszidővel is 5-8 óra lenne, a másfél helyett Ezért kérdeztem meg, hogy van a korlát és ilyet "nem szabad" mert akkor át kell gondolnunk az önellenőrző rendszert
@csandazoltan értem, csak nem értem. :) Ha a számlázóban változás történik az adatátadás után, akkor arról neki tudnia kellene anélkül is, hogy megkérdezi a NAVtól, hogy mi van a NAVnál, nem? De lehet, hogy valami olyan dolog van Nálatok, amit én el sem tudok képzelni, és indokolt a folyamatos bekérdezés. A dupla beküldést szintén lehet kezelni számlázó program oldalon. Mi okból fordulhat elő, hogy dupla beküldés van:
- a NAV nem adott választ időn belül, nem tudtátok rögzíteni a tranzakció adatokat, ezért újra próbálkoztok. Ilyen nálunk is van, ekkor a hiba észlelésekor rá lehet állni egy lekérdezéssel a kívánt tranzakcióra, ellenőrizni lehet, hogy az számla van-e bent, aminek kellene, rögzíteni lehet, hogy minden ok. Néhány kéréssel ez letudva, ezért nem kell utólag minden számlát ellenőrizni.
- a számlázó valamiért párhuzamosan küldözgeti be a számlákat, ezzel okozva a problémát. Ezt viszont kezelni kellene a Ti oldalatokon, de nem úgy, hogy mindig napokra visszamenőleg kértek le minden adatot.
Az érvénytelenítést nem teljesen értem. Bejövő vagy kimenő számla oldalon van erre szükségetek?
Természetesen nem zárom ki, hogy ezek fontos ellenőrzések Nálatok, de még mindig úgy érzem, hogy feleslegesen stresszelitek a NAV oldalát napokra visszamenő kérésekkel, más megoldásokat kellene találni a problémák azonosítására.
(Mi van például, ha 15 nappal ezelőtti számlát érvénytelenít (és ad fel újra) valaki? Vagy, mint nálunk az egyik ügyfelünk partnere, miután az automata beolvasónk miatt kiderült, hogy a kezdetektől rosszul adja át a számlákat, szépen annuláltak mindent és újra átadták. Ez insDate használatával kiderült egyből, látták az ügyfélnél, hogy 2018as keltezésű számlák jelentek meg, ez a Te általad leírt módszerrel nem jelenik meg.)
Bocs, nem kötözködni akarok, csak megérteni, hogy mit nyertek azzal, hogy napokra visszamenőleg lekéritek mindig mindkét irányból/ba a számlákat.
@omachtandras Ezt szerintem nem itt kellene kibeszélnünk, ez az issue a szerdai értekezletre van fenntartva és publikusban nem írhatok többet
+1 javaslat: a productCode OWN mezőjébe mindig töltsük be a cikk saját kódját. Ha már a NAV fejlesztői biztosítottak egy külön mezőt neki (köszönet érte), lehetőség szerint éljünk is vele. Ha minden program kitöltené ezt a mezőt, sokkal kisebb erőforrással és hibalehetőséggel lehetne a bejövő számlákat beazonosítani. - Ha a konferencián legalább említés szintjén felmerülne ez a javaslat, azt megköszönném.
A 27. ajánlás g) pontja: Az egyéni válalkozó igazolvány számának kezelését ajánlja. A valóságban már 2020.,01.01-től megszűntek az ilyen igazolványok, azokat bevonták, amelyiket nem adták le, azt érvénytelenítették. Viszont - bár nem az Áfa tv által - de jogszabályilag kötelező az egyéni vállalkozás nyilvántartási számának szerepeltetése a számlakibocsátó oldalán (ha relenváns). A jogszabály: "2009. évi CXV. törvény. (Evc. tv) “16. § (4) Az egyéni vállalkozó gazdasági tevékenysége során az „egyéni vállalkozó” megjelölést (vagy annak e.v. rövidítését) és nyilvántartási számát neve (aláírása) mellett minden esetben köteles feltüntetni.“
Az 50. sz. ajánlást meg kellene szüntetni, mert téves képzetelket kelthet a felhasználóban.
@sinick2 már helyesen rámutatott arra, hogy a bruttó összeget nem számlánként, hanem adott hónapon belül partnerenként, azon belül szerződésenként kell értékelni. Annyival viszem tovább @sinick2 által leírtakat, hogy kiemelem azt, hogy az ÁFA tv. 114.§ (3) bekezdésében "készpénzben teljesített fizetések"-ről van szó. Ez pénztári kategária, és vajh mi klevés köze van a számlán szereplő fizetési módhoz. Utalok arra. hogy nem készpénzes fizetési módú számlát is ki lehet készpénzzel egyenlíteni, és készpénzes számla sem biztos, hpgy készpénzzel lesz kiegyenlítve. Továbbá érdekes kérdéseket vet fel a készpénzhelyettesítők esete, amely jogilag készpénznek számít.
Igazából az okozza a legnagyobb problémát, hogyha ilyen ellenőrzést beépítenek a számlázó programokba, akkor nagyon sok felhasználó azt hiheti, hogyha egy adott szerződést 1 hónapon belül több részletben számláznak, akkor mibvel nem kap hibaüzenetet, akkor "belefér", hiszen a számlázó program biztoosan tudja ezt.
Aki pontosan ismeri a jogszabályt, annak a szemében egy iylen üzenet lejáratja a számlázó programot. aki meg nem ismeri a jogszabályt abban pedig fölösleges biztonságérzett kelt.
Nekem lesújtó a véleményem az átlagos számlázók jogszabályismertetéről, amit egy kifejezetten nehéz jogtétel egyszerűsített leképezése csak tovább ront.
Hibás adatokkal kiállított számla esetén mi a teendő, ha a számla már lezárásra került, de az adatszolgáltatás sikertelen volt pl. formailag hibás közösségi adószám miatt? Ilyenkor számla szinten helyesbítő vagy sztornó számlával korrekcióra kerülhet sor, de az adatszolgáltatás hogyan lehetséges, ha az eredeti számláról sikertelen volt a beküldés, tehát nem lehet rá hivatkozni?
A 3. fejezet ajánlása: "A számlázó program kialakításakor fontos szempontnak kell lennie a meghiúsuló számlakiállítás kezelésének. Ha a számlázó program által már lefoglalt számlasorszám alatt létrehozni kívánt számla kiállítása nem sikerül, akkor a lefoglalt, de ténylegesen el nem használt számlasorszámot és az ahhoz tartozó tartalmat (ha az előállt) javasolt a programnak tárolnia, ugyanakkor zárolnia kell az adott sorszámot, azt nem szabad újra kiadnia." Nálunk ilyenkor 'RONTOTT' státuszt kap a sorszám, amihez gyakorlatilag nem tartozik számla, de ez esetben nem sérül a kihagyásmentesség?
A 8. fejezet ajánlása: "A számlázó programban el kell kerülni – akár a számlakiállítási folyamat blokkolásával is – a 0%-os adókulcs használatát a számlaképen és az adatszolgáltatásban akkor is, ha a program működésében használt táblákban esetleg szerepel ilyen." Milyen jelölés javasolt helyette a számlaképen?
Sztornó számlánál mindegy, hogy az eredeti tétel mennyiségét vagy egységárát változtatjuk ellentétes előjelűre?
Sztornó számlánál mindegy, hogy az eredeti tétel mennyiségét vagy egységárát változtatjuk ellentétes előjelűre?
Én csak a mennyiség negálásának látom értelmét. Egyébként ingyen adtál több terméket, aminek lehet áfa-vonzata.
Ajánlás-06: Javasolt a számlán az ügyfél által fizetendő összeget egyértelműen kiemelni a többi számlatartalomból.
Off-topic: ajánlom, hogy a NAV is ezt tegye, amikor kiküld egy határozatot, pl. gépjárműadóról, és fél tucat helyen feltüntet éves és féléves összeget, de egy helyen sem a tényleges fizetendőt, azaz a 1000 forintra kerekített értéket, és annak a felét.
Ajánlás-10: Ha a számlázó programból egyéb bizonylatok (például számviteli bizonylat, felvásárlási okirat stb.) kiállítására is van lehetőség, akkor javasolt a számlázó programban biztosítani, hogy az egyes bizonylatfajták eltérő sorszámtartományt használjanak. Ezen bizonylatokra is vonatkozik a Számlarendelet szerinti folyamatos, ismétlés nélküli és kihagyásmentes sorszámozási kötelezettség.
Ez utóbbi mondat brutális túlszabályozásnak és a rendelet félreértésének tűnik. Pl. ha a számlázó program nyomtat mozijegyet, akkor arra is kiterjesztené az ismétlés nélküli és kihagyásmentes sorszámozási kötelezettség-et.
Az adatexportnak a számla teljes adattartalmát tartalmaznia kell, amit bármely jogszabály kötelező adattartalomként előír.
Erre vonatkozó pontos jogszabályhely-hivatkozást továbbra is szeretnék látni. Lásd bővebben itt.
Ajánlás-32: Javasolt a számlázó programban a kerekítéseket a matematika szabályai szerint elvégezni, a felhasználó igénye vagy a fejlesztő döntése alapján tételsoronként vagy az összesítőben.
Ezt ennél bővebben ki kellene fejteni. Lásd ezt a megválaszolatlan kérdésemet.
Ha az ügylet mégsem jött létre vagy nem a számlán szereplő felek között jött létre, akkor a számlát számlával egy tekintet alá eső okirat kiadásával érvényteleníteni kell.
Eddig az ilyen témákkal ugyan el lettünk hajtva, hogy nem adatszolgáltatási probléma, de mégis csak tisztázni kellene ezt a kérdéskört. Lásd még https://onlineszamla.nav.gov.hu/kerdesek_es_valaszok 31. kérdését, ahol szintén nem lehet egyértelműen értelmezni a választ. Kapcsolódó problémafelvetések, ellentmondások itt és itt (az összes hozzászólás átnézése és megértése kívánatos egy egyértelműbb álláspont közlése érdekében).
A módosító és érvénytelenítő okiratokra is vonatkozik az adatszolgáltatási kötelezettség, ha az a számlára is vonatkozott.
Ez itt egy érdekes dolog. Ezek szerint nem minden számlával egy tekintet alá eső okiratra vonatkozik.
Az áfatörvény ezt írja:
257/G. § Az adóalany a 4/A. számú mellékletben, valamint a 10. számú mellékletben meghatározottak szerint köteles adatot szolgáltatni.
- § (1) E törvény 10. számú melléklete 2020. június 30. napján hatályos 1–4., 12–13. pontjait kell alkalmazni azon számla, számlával egy tekintet alá eső okirat esetén, amely alapján az adóalany 2020. június 30. napját magában foglaló adómegállapítási időszakban gyakorol levonási jogot, veszi figyelembe a módosítás vagy érvénytelenítés hatását. (2) E törvény 10. számú melléklete 2020. június 30. napján hatályos 5. és 7–8. pontját kell alkalmazni a 2020. július 1. napja előtt kibocsátott számla, számlával egy tekintet alá eső okirat esetén. E törvény 10. számú melléklete 2020. június 30. napján hatályos 6. pontját kell alkalmazni a 2020. július 1. napja előtt kiállított számla, számlával egy tekintet alá eső okirat esetén.
- § E törvény 10. számú melléklete 2021. január 3. napján hatályos 1. és 2. pontját kell alkalmazni a 2020. június 30-át követően, de 2021. január 4. napja előtt kibocsátott vagy kiállított számla, számlával egy tekintet alá eső okirat esetén.
Ezt azért nagyon kellemetlen kibogarászni, mert a 10. számú mellékletben két adatszolgáltatás van: eleve Összesítő jelentés-nek hívják, de belecsempészték az online adatszolgáltatást. De különböző változatokban más-más pontokba keverték ezeket. Pl. a régi 6. most a 4.:
- A számlázási funkcióval rendelkező programmal kiállított számla, számlával egy tekintet alá eső okirat esetében az adóalany külön jogszabályban meghatározott elektronikus módon teljesít adatszolgáltatást a számla, számlával egy tekintet alá eső okirat e törvény szerinti adattartalmáról, továbbá az adó alapjának meghatározásakor használt pénznemről, külföldi pénznem esetén a forintra átszámított adatokról és a forintra történő átszámításhoz alkalmazott, 80. § és 80/A. § szerinti árfolyamról. Nem adóalany természetes személy részére kibocsátott számla, számlával egy tekintet alá eső okirat esetében az adatszolgáltatás nem terjed ki a termék beszerzőjének, szolgáltatás igénybevevőjének nevére és címére.
A 338. § (látszólag indokolatlanul elbonyolított) (2) bekezdése és a 339. § nem vonatkozik azon okiratokra, amelyeket eztán bocsátunk ki. A 338. § (1) bekezdés meg látszólag nem az online adatszolgáltatásról szól, bár ide már komoly sakkjogászok kellenek, mert egyszerre vannak érvényben a régi és új törvényváltozat azonos számú, de egész más tartalmú pontjai.
Ha jól értem, akkor nem az számít, hogy a számlára vonatkozott-e a kibocsátásakor az adatszolgáltatási kötelezettség, hanem, hogy most vonatkozna-e. (Ha igen, akkor már csak az lehet a kérdés, hogy a melléklet 1. pontja ad-e kivételt a 4. ponthoz, de ez engem jelenleg nem érdekel.)
A számla módosítása lehetséges egy módosító számlával (számlával egy tekintet alá eső okirattal) vagy két lépésben (az eredeti számla minden tételének ellenkező előjellel történő feltüntetése egy módosító számlán, majd újabb módosító számla kiállítása a helyes adattartalommal). Ajánlás-35: Ha a számla itt leírt, két lépésben történő módosítására a szoftver nem alkalmas, akkor ezt a tényt javasolt egyértelműen közölni a dokumentációban. Ha kétlépéses módosító számla kiállítását támogatja a számlázó program, akkor az első bizonylatnak („nullázás”) az alapszámla és az azt korábban módosító számlák hatását együttesen kell tartalmaznia. A helyes adattartalommal kiállított számla is az eredeti bizonylat módosítása, így ebben is megfelelően hivatkozni kell az eredeti számlára.
Itt vajon miért van kiemelve a két lépéses módosítás mint valami pozitívum? Itt ugye a helyes adattartalommal kiállított számla valójában nem számla, hanem csak azzal majdnem egy tekintet alá eső okirat? Így már legalább három okiratot kell összenézni. Ez miért jobb, mint kettőt?
Kicsit zavaró, hogy első bizonylatnak nevezi a legalább másodikat a számlaláncban.
Ha kétlépéses módosító számla kiállítását támogatja a számlázó program, akkor az első bizonylatnak („nullázás”) az alapszámla és az azt korábban módosító számlák hatását együttesen kell tartalmaznia.
Az, hogy támogatja, még nem jelenti azt, hogy kötelezővé is teszi. De ezen mondat logikája alapján minden módosítást megelőz egy storno a számlaláncban. Ha már fejlesztőknek szól az ajánlás, jó lenne a megfelelő invoiceOperationt is jelölni.
A tételnek nincs előjele. Tisztázni kellene, hogy a mennyiség előjeléről van szó. (Ugyanez igaz az Ajánlás-39-re, amely egyébként a módosítások hatását sem veszi figyelembe.)
Ajánlás-43: Ha a módosító számlán a felhasználó a vevő adatait módosítja, akkor javasolt felhívni a figyelmét arra, hogy a nem megfelelő vevőnek kiállított számlát érvényteleníteni kell. A számla módosítása a vevő adatainál csak az esetleges elírásokat korrigálhatja.
Itt sokkal pontosabban kellene meghatározni, hogy mi a különbség a nem megfelelő vevő és az elírás között. Pl. elcsúszott a sorvezető, és a vevő fele vagy minden adata el lett írva.
@tnagymelinda által felvetett és @jozanesz által megválaszolt előjel problémára reagálok.
Nem minden esetben szerepel a tételsoron sem mennyiség, sem egységágár. Ekkor is kell tudni a negatívságot kezelni. Ilyenkor lehet, hogy van nettó érték, de az egyszerűsített számlán még az sincs, csak tételsor bruttó.
Talán ezért kerül sor általánosabb megfogalmazásra az, hogy "tételsor előjele".
@jozanesz rávilágított arra az esetre, amikor van mennyiség és egységár (ezek párban állnak) . Ilyenkor ahhoz, hogy a tételsor (nettója, vagy bruttója, mikor mi van) negatív legyen, egyértelműen a mennyiség negatívba helyezésének van értelme. Ha a mennyiség pozitív, és az egységár lenne negatív, akkor az eredeti számlán szerepelőnél dupla mennyiség kerülne értékesítésre, 0 áron. Látható, hogy (gazdasági hatását tekintve) így nem lett érvénytelenítve az eredeti számla, mert a mennyiség meg lett duplázva. Pl. ha a számlán 2 db termék szerepel 100 Ft-os nettó áron, és ennek módosító okiratán 2 db termék -100 Ft -os nettó áron, akkor valójában a két bizonylattal kifejezett összesített gazdasági esemény 4 db termék eladása 0 Ft nettó értéken. És ennek ugyebár lehet áfa vonzata is.
De sajnos ekkora kisregényt kellene leírni ahhoz, hogy meg egzaktan lehessen kifejezni egy tételsor ellentettjét, mert annyira túl van szabályozva az egész számlakiállítás, hogy tényleg csodaszámba megy, ha valaki egy számlát helyesen ki tud állítani.
És most ezt a bonyolult értelmezést odalőcsőlik a számlázó programokat fejlesztőkre, akiknek jogértelmezésből kellene kioktatniuk a felhasználókat, miközben maguk sem adójogi szakemberek.
Amúgy egy számlázó programnak is különféle jogértelmezésben hívő felhasználói vannak, ezért különböző jogértelmezéseket is ki kell tudnia szolgálnia. (és akkor még nem beszélve arról, hogy amit ma a NAV, vagy a szakma helyes értelmezésnek tart, az idővel megváltozhat, miközben a jogszabály változatlan marad, amire számos példát láttunk már a számlaadat-szolgáltatás idejében is: eltűnő, vagy megváltozó NAV-PM állásfoglalások, teljesíthetetlen törvényi előírások a 2020.12.31-ig életben lévő ÁFA tv.-ben pl. a végszámla különbözet kérdésében, amit csak a NAV hallgatólagos tudtával lehetett beküldeni, mert a törvényben leírtak teljesíthetetlenek voltak.
Aki pl. vajat, vagy tejet, vagy csavarhúzót árul, az sem kötheti meg a vevője kezét, hogy mire és hogyan kell azt használnia.
- ajánlás, f) pont: "A számlán és az adatexport állományban a vevő adatainak az adatszolgáltatás természetes személyre vonatkozó rendelkezésitől függetlenül is szerepelniük kell."
Az adatexportnál annak fényében is fel kell tűntetni ezeket az adatokat, hogy ha beleteszem, akkor az összeállított xml nem lesz valid a NAV-os xsd-k szerint?
Az adatexportnál annak fényében is fel kell tűntetni ezeket az adatokat, hogy ha beleteszem, akkor az összeállított xml nem lesz valid a NAV-os xsd-k szerint?
Egyébként is van esély rá, hisz az adatszolgáltatásra és az adatexportra vonatkozó kötelező adattartalom eltér: "Az adatexport előállítható a Számlarendelet melléklete szerinti adatstruktúrában, valamint az adatszolgáltatás adatstruktúrájában is. Az adatexportnak a számla teljes adattartalmát tartalmaznia kell, amit bármely jogszabály kötelező adattartalomként előír. Így tehát nem megfelelő megoldás, ha a számlázó program kizárólag az Áfa tv. szerinti kötelező adattartalmat biztosítja adatexportként is."
Kérdés: az XML-ben 3 különböző CustomerVatStatus szerepel: DOMESTIC, PRIVATE_PERSON, OTHER. Ezzel szemben Ajánlás-12 4 db különbözőt határoz meg. Ebből az OTHER típus érdekes. Mi EU-s ország esetén, ha van megadva adószám, akkor a communityVatNumber mezőben szerepeltetjük, ha nem EU-s ország, akkor pedig a thirdStateTaxId-ben. Ajánlástól függetlenül ezt a megoldást elfogadja-e a NAV?
Kérjük, hogy a videót tegyék utólagosan visszanézhetővé, mert nem biztos, hogy részt tudunk venni a holnapi időpontban a tájékoztatón.
Hosszabb tanulmányozás után az ajánlásokban leírtak nem összeegyeztethetőek a CustomerVatStatus-al.
Az ajánlások: a) A vevő magánszemély (nem áfaalany természetes személy) b) A vevő belföldi áfaalany c) A vevő közösségi (EU-s) áfaalany d) A vevő harmadik országbeli (nem EU-s)
CustomerVatStatus: DOMESTIC
- belföldi áfaalany nem természetes személy
- belföldi áfaalany természetes személy
PRIVATE_PERSON
- belföldi nem áfaalany természetes személy
- külföldi nem áfaalany természetes személy
OTHER
- belföldi nem áfaalany nem természetes személy
- külföldi áfaalany nem természetes személy
- külföldi nem áfaalany nem természetes személy
A hiba: "vevő belföldi nem áfaalany nem természetes személy" (OTHER) eset nem feleltethető meg a-b-c-d pontok egyikének sem.
Az online rendezvényen a kérdésemre kapott választ nem tudom elfogadni. Továbbra is állítom, hogy a 49. ajánlás b) pontja tévesen állítja : "Készpénzes fizetés esetén a teljesítés dátuma korábbi, mint a kiállítás dátuma." Ez csak az egyszerűsített számla kibocsátásakor van így. Állítom, hogy normál áfás készpénzes számla a teljesítést követően 8 napon belül is kibocsájtható. Ellenkező véleményt kérném jogszabályi hivatkozással indokolni. A korábbi hozzászólásom: https://github.com/nav-gov-hu/Online-Invoice/issues/796#issuecomment-789815635
@betasofthu Szerintem igazad van. Nem mondtak ennek ellent az előadáson sem, óvatosan kezelték ezt. Arra hivatkoztak, hogy van olyan előírás az áfa tv.ben, hogy készpénzzel történő fizetés esetén a számlát haladéktalanul ki kell állítani. Ezt én úgy értelmezem, hogy a számlát legkésőbb a KP fizetésig ki kell állítani, azaz nem baj, ha korábban állítják ki, csak a fizetés után nem lehet. Ha pénteken eladom a tüzifát az erdőben, amit a vevő elszállít, de az erdőben nincs számlázásra mód, akkor életszerű az, hogy a számlát csak hétfőn állítom ki, amikor a vevő bejön fizetni és a számláért. Ekkor a teljesítési dátum péntek lesz, a kelt dátum pedig a hétfői nap. Én is úgy érzem, hogy picit keverik az egyszerűsített számlával, ahol nemcsak készpénz van. hanem a pénzátadással egyidejű teljesítés is...
@macskafarka: Igen én is úgy gondolom, hogy az egyszerűsített számlával keveri mindenki. Nem szeretném, ha így maradna az ajánlásban. A könyvelők is széltében hosszában terjesztik ezt a tévhitet, mondják a vállalkozóknak. A példában említett esetben a vállalkozó normál áfás kézi számlát állított ki, a teljesítés dátuma egyezett a számla keltével, de a biztosító miatt a megjegyzésbe beírta, hogy valójában 3 nappal korábban volt a teljesítés. Gyakorlatilag meghamisítják a bizonylatot a tévhit miatt.