Adóhatósági ellenőrzési adatszolgáltatás (online számla)
2015-10-14T14:05:27+02:00
2022-06-22T12:45:08+02:00
2022-06-22T13:00:31+02:00
  • A NAV ilyenkor befogadja a számlát.

    Mindössze figyelmezteti a NAV a kedves fejlesztőt, hogy 1 Ft az árfolyam, aminek lássuk be, kb. 1 a százmillióhoz az esélye. Szól a fejlesztőnek, hogy esetleg nem baltázott-e el valamit.
    Mutasd a teljes hozzászólást!
  • Illetve ezzel az "INFO" type-pal kapcsolatban lenne kérdésem. Mi ez? Ignorálható?
    Mutasd a teljes hozzászólást!
  • De attól még nincs olyan jogszabály, hogy más deviza árfolyama ne lehetne 1 HUF... Ennyi erővel bármilyen ostobaságot ráköthet a NAV kénye kedve szerint?

    Viszont! Sokkal komolyabb problémákat felvet ez: UNINTENDED_MODIFICATION_DELIVERY_DATE
    "Jelez, ha a beküldött módosítás vagy érvénytelenítés az alapszámla teljesítési
    dátumát a módosító számla keltére módosítja. Ez egy többször előforduló hiba
    a számlázó programokban."

    Erre van valami jogszabályi magyarázat? Helyesbítek egy számlát, a teljesítési dátumot beállítom tegnapra, holnapra, nincs az ég világon semmi gond. Aznapra miért nem lehet?

    Vagy vegyük a NAV álláspontját a visszáru számlákról -> azt tolták állandóan, hogy ilyen nincs, számlával egy tekintet alá eső okiratot kell kiállítani. Kiállítom, de ott a teljesítés nyilván "mai". Na most akkor ez a módszer sem jó?
    Mutasd a teljes hozzászólást!
  • Valószínűleg azért van ilyen üzenet, mert felteszem, orrba-szájba küldik be az 1 Ft árfolyamú eurós számlákat. Jómagam is találkoztam már több ilyen számlázó programmal. Kiválasztod, hogy deviza egyenlő euró és ezzel be van fejezve. Se egy árfolyam mező, se semmi (MNB aktuális árfolyamletöltés, vagy ilyesmi).

    Ha az WARN, akkor a számla be van fogadva, csak figyelmeztetéssel. Az egy másik kérdés, hogy a fejlesztők tekintélyes hányada nem dolgozza fel a WARN-okat. Legfeljebb csak bosszankodik miattuk.
    Mutasd a teljes hozzászólást!
  • Mik ezek az új warn-ok? Pusholják, hogy "tisztítsuk" az adatszolgáltatásokat, aztán telerakják marhasággal? Lásd: INCORRECT_HEAD_DATA_EXCHANGE_RATE_1

    "Figyelmeztet, ha az árfolyam 1, de a pénznem nem HUF."

    Tehát a NAV megtiltja, hogy legyen olyan devizanem, aminek nem lehet ugyanaz az árfolyama, mint a forintnak? Vagy ha lesz is ilyen, akkor az számlázási hibának számít? Erre aztán tényleg jól fel lehet készülni... Védjem le egy üzenettel, hogy a NAV álláspontja szerint nem lehet ilyen?
    Mutasd a teljes hozzászólást!
  • Nem vagy vele egyedül, de amíg a NAV fejlesztői nem látja, addig nem létezik ilyen hiba. Ld itt: Indokolatlan INCONSISTENT_MODIFICATION_DATA_VATAMOUNT_NOT_ZERO_HUF figyelmeztetés! · Issue #958 · na
    Mutasd a teljes hozzászólást!
  • Szia.
    Köszönöm a választ.
    Ennél a partnernél nincs módosítási opció, csak create és storno van.
    És ezek egy az egyeben meg is egyeznek csak a storno negatívban.

    Egyéb ötlet esetleg? :)
    Mutasd a teljes hozzászólást!
  • Szia.
    Köszönöm a választ.
    Ennél a partnernél nincs módosítási opció, csak create és storno van.
    És ezek egy az egyeben meg is egyeznek csak a storno negatívban.


    Egyéb ötlet esetleg? :)
    Mutasd a teljes hozzászólást!
  • Nincs véletlenül az érvénytelenítés előtt egy módosító? A queryInvoiceChainDigest-tel le tudod kérdezni a láncot.
    Mutasd a teljes hozzászólást!
  • Sziasztok!
    Bocsi ha volt már, de nem találtam eddig. :)

    Kapott-e már valaki közületek ilyen WARN üzenetet egy storno számlára (Az eredeti szépen bement, mindenféle hiba nélkül):

    WARN->INCONSISTENT_MODIFICATION_DATA_VATAMOUNT_NOT_ZERO_HUF : Érvénytelenítő számla ÁFA összege forintban nem ad nullát az alapszámla módosításaival összesített ÁFA forint összegével összeadva. , INCONSISTENT_MODIFICATION_DATA_VATAMOUNT_NOT_ZERO : Érvénytelenítő számla ÁFA összege nem ad nullát az alapszámla módosításaival összesített ÁFA összegével összeadva.

    Megnéztem az eredeti és a storno számlát is és mind a kettő KBAET-s, azaz  "Közösségen belüli termékértékesítés (EUT)" ezért az áfa mindenhol 0.
    0 + 0 az nálam még mindig 0. :)



    Minden összeg stimmel és megvan a mínuszos párja.
    Akkor mi lehet a gond? Miért kapok WARN-t? :)

    Segítségeteket előre is köszönöm.
    Mutasd a teljes hozzászólást!
  • Köszi, nem ez volt a baja. Hibátlan xml-t teszteltem vele és csodálkoztam, hogy miért nem írja ki a hibát :D
    Mutasd a teljes hozzászólást!
  • Sziasztok!
    Megin én :)
    Van itt olyan valaki, aki XSD alapján validálja az elkészült XML-t beküldés előtt?
    Hogyan lehet elérni a common namespace-t?
    Köszönöm
    Mutasd a teljes hozzászólást!
  • Köszönöm mindenkinek a válaszokat. sikerült meggyőznöm a főnökömet, hogy minden marad, ahogy volt.
    Mutasd a teljes hozzászólást!
  • Szia!

    Most szeretnénk átalakítani, hogy addig nem tudja kinyomtatni, amíg be nem ment a NAV-hoz hiba nélkül, de ez meg időbe telhet.

    Miért akarjátok "elrontani" a most jól működő programot?
    Mutasd a teljes hozzászólást!
  • NAV doksiba leírja hogy tilos a papír alapú nyomtatást blokkolni azért mert a beküldés nem megy. Az általad leírt aszinkron működés az elvárt. Több esztközt kell adni a felhaszálónak hogy feltűnjön neki hogy gond van. Elvégre az Ő érdeke az hogy ne legyen beküldetlen számla, mert Ő lesz agyon büntetve, nem a szoftver szállító.
    Mutasd a teljes hozzászólást!
  • Hát, ezzel az a baj, hogy ha épp kiesik egy köztes elem (pl nav leáll, vagy elmegy az internet), akkor nem fogsz tudni számlázni sem.
    Én ugyanezt a módszert alkalmazom, a beküldést egy háttérfolyamat csinálja, percenkénti ellenőrzéssel, ugyanez a rutin kérdezi vissza a státuszát, ha valamelyik számla nem ment volna be, akkor arról e-mailt küld.
    Nyilván ez sem tökéletes megoldás, nekünk megfelel, mert minimális a helyszínen történő vásárlás, így nem okoz nagy gondot az esetleges hibás számla, nagy valószínűséggel még nálunk lesz minden példány, mikor kiderül a hiba.
    Mutasd a teljes hozzászólást!
  • Sziasztok!
    Nálunk úgy működik a beküldés, hogy percenként megnézi az adatbázisban, hogy van-e beküldendő számla és ha van, akkor megpróbálja beküldeni. Közben ettől függetlenül a felhasználó kinyomtathatja a számlát és rendszerint meg is feledkezik arról, hogy ellenőrizze, vajon bement-e a NAV-hoz.
    Most szeretnénk átalakítani, hogy addig nem tudja kinyomtatni, amíg be nem ment a NAV-hoz hiba nélkül, de ez meg időbe telhet.
    Mik a tapasztalataitok ezzel kapcsolatban? Ti mikor külditek be a számlát?
    Köszönöm
    Mutasd a teljes hozzászólást!
  • Köszönöm mindenkinek a tippeket, hibakezeléssel és a végén újbóli próbálkozással lesz megoldva a dolog, csak reméltem hogy esetleg valamilyen beállítással, vagy paraméterrel áthidalható. Pár hónappal ezelőtt egyébként két-három tucat alkalommal sikeresen futott le ugyanez a kód, nem tudom mi történhetett, de legalább kezelhetőnek tűnik a dolog. Köszönöm még egyszer!
    Mutasd a teljes hozzászólást!
  • Tömeges számla és számlalista lekérdezés esetén nálunk is van ilyen, mikor a könyvelő nekiugrik egy egész év 1-2 ezer darabos szállítói számlaforgalmat lekérdezni. Párszáz ms után 1-2 db újrakérdezés és ha akkor is hiba, akkor félrerakjuk és ugrunk a következő adagra. A végén jelezzük, hogy van pár számla, akar-e újra nekifutni a hiányzó számlákra.
    Mutasd a teljes hozzászólást!
  • Nekem első körben az jutott az eszembe, hogy esetleg valami rate limit lehet beállítva, de arra az Istio HTTP 429-et adna vissza, szóval ez a gondolatom hülyeség volt. Amikor fiddlerezed, a beküldött request-ekben nem látsz anomáliát, amikor HTTP 500 jön vissza (gyanítom, hogy van egy sporadic bug a kódodban)? A response-ban azt is érdemes megnézni, hogy ténylegesen a backend szállt el ("server: Kestrel" header), vagy az Envoy (server: envoy) valami félrekonfiguráció miatt.
    Mutasd a teljes hozzászólást!
  • php-ben nálam néhány ezer, lefutott eddig gond nélkül.
    Mutasd a teljes hozzászólást!
  • Szerintem tedd kisebb csomagokba. Pl.: 10x100.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Adószámok érvényességét szeretném ellenőrizni a queryTaxPayer endpointon keresztül, úgy 1000 adózóról van szó. Viszont öt futásból kb. négyszer néhány perc után 500 Internal Server Error hibát ad vissza az API. Nem konzekvens a dolog, midig más adózónál dobja el magát és ha debuggerben újra ráfutok a sorra, már gond nélkül megy a dolog másodjára. Illetve kb. minden ötödik alkalommal gond nélkül lefut az ellenőrzés. Találkoztatok már ilyen hibával? Mit lenne érdemes kipróbálnom? C#-ban van a kód egyébként.

    Köszönöm előre is a tippeket!
    Mutasd a teljes hozzászólást!
  • Üdv!

    Közben sikerült megválaszolnom a problémát magamnak. Egy kollégának mutogattam és rájöttem hogy ez a batchindex, nem az a batchindex.   Ez nem batchként feltöltött több számla, hanem az "egy számlával több számla módosítása" eset.

    Szóval azt így hozza a digestlist...  Tanulságnak itt hagyom.

    PPSOFT
    Mutasd a teljes hozzászólást!
  • Üdv!

    Segítséget kérek tőletek.  Most futottam bele az alábbi problémába:

    Az ügyfelemnek több fogyasztási helye van. A módosító számlákat, ami hangsúlyozom egyedi önálló számlaszámú számlák, a szolgáltató kötegelve (batch) töltötte fel.   A QueryInvoiceDigest(List) soronként hozza a számlákat. azonban minden egyes számlához, az első számla számát írja, nem pedig a batch-en belül neki megfelelőt.    Így a lekérdezett számlaadatok egyből nem tölthetőnek be a programba...

    Mit lehet róla tudni, ez a kezdetektől így van, vagy egy mostani NAV akció eredménye?
    Lásd képet.

    Üdv. PPSOFT
    Mutasd a teljes hozzászólást!
    Csatolt állomány
  • szeretném megnézni a módosító számla készítését a NAV-os számlázóban
    kiállítottam 1 számlát majd módosítanám, a listában ez az első sor a módosítás gomb inaktív, létrehoztam még1t így a 2. helyre került aktív a módosítás gomb hurrá de nem ez a lényeg

    végre sikerült elérnem a módosítás funkciót :)
    módosítanám a tétel 1ik adatát írja:
    Módosító számla kiállításakor a Számla tételek panelen szereplő mezők tartalma csak az eredeti tétel szerkesztésével és/vagy új tétel rögzítésével módosítható. Tétel módosításához használja a tételhez tartozó szerkesztése (ceruza ikon) gombot. Módosítás esetén a változás mértékét vigye fel.
    ok ceruza ikon rákattintok, megjelenik egy új sor az eredeti tétel adatokkal szeretném mondjuk az árat módosítani de inaktív minden mező

    még meg kell nyomni valamit a tétel szerkesztéséhez?, nem látok csak egy kuka gombot 1tétel módosításának törlése felirattal

    tudja valaki, hogy hogyan kell ezt csinálni
    Mutasd a teljes hozzászólást!
  • meg is oldódott semmit nem csináltam csak rányomtam a mentés gombot a Technikai felhasználó adatai ablakban
    Mutasd a teljes hozzászólást!
  • Sziasztok, hónapok óta nem jelentkeztem be a teszt felületre eddig semmi probléma nem volt most egy nagy piros üzenet fogad az online számlázó programban

    Technikai felhasználó hiba! A megadott adatok nem egyeznek az Online Számla rendszerben szereplő adatokkal. Hibás felhasználónév vagy jelszó!
    Az adatszolgáltatáshoz frissítse a beállításokat a Technikai felhasználó adatai oldalon.

    nem változtattam semmit se felhasználót se jelszót, tudja valaki mi ez mellékelem a képernyőképet is
    Mutasd a teljes hozzászólást!
    Csatolt állomány
  • Számlagyár: a korrupció egyes informatikai projekteknél már nem is versenyelőny, hanem alapelvárás

    "Az állam pedig válogatós, nagyon szereti a közvetlen pénzügyi bevételekkel járó informatikát jól menedzselni, traffipax, útdíj, online számlázás, NAV, ezek jól működnek, ahogyan a kötelezők is (például okmányok kiadása, egészségügyi rendszer)."
    Mutasd a teljes hozzászólást!
abcd