Adóhatósági (NAV) adatszolgáltatás beküldésének lekérdezése hiba

Adóhatósági (NAV) adatszolgáltatás beküldésének lekérdezése hiba
2020-07-06T15:57:50+02:00
2020-07-10T17:43:24+02:00
2022-10-15T21:26:34+02:00
jonaspeter
Sziasztok!

07.02 óta tapasztalok egy hibát egy a NAV-nak sázmla adatokat szolgáltató programban, ami azelőtt teljesen jól működött. A számla feladás sikeres, a számla látszik a is a NAV rendszerében, azonban a feladkáskor kapott tranzakciós azonosító alapján nem tudom lekérdezni a tranzakció státuszát (az esetek nagy részében).

Példa sikeres lekérdezésre:

<?xml version="1.0" encoding="UTF-8"?> <QueryTransactionStatusRequest xmlns="http://schemas.nav.gov.hu/OSA/2.0/api"> <header> <requestId>RID054831000159403227655535</requestId> <timestamp>2020-07-06T12:44:36.000Z</timestamp> <requestVersion>2.0</requestVersion> <headerVersion>1.0</headerVersion> </header> <user> <login>...</login> <passwordHash>...</passwordHash> <taxNumber>...</taxNumber> <requestSignature>...</requestSignature> </user> <software> <softwareId>...</softwareId> <softwareName>...</softwareName> <softwareOperation>LOCAL_SOFTWARE</softwareOperation> <softwareMainVersion>7.27.6</softwareMainVersion> <softwareDevName>...</softwareDevName> <softwareDevContact>...</softwareDevContact> <softwareDevCountryCode>HU</softwareDevCountryCode> <softwareDevTaxNumber>...</softwareDevTaxNumber> </software> <transactionId>30W3U41VN2HPQR36</transactionId> <returnOriginalRequest>1</returnOriginalRequest> </QueryTransactionStatusRequest>
Erre érkező válasz:

HTTP/1.1 100 Continue Content-Length: 0 \n HTTP/1.1 200 OK Content-Type: text/xml;charset=UTF-8 Content-Length: 7044 Date: Mon, 06 Jul 2020 10:44:15 GMT X-Via: ppsbicxmlapi2.eszamla.local X-Server: backend_invoiceService-v2-queryTransactionStatus/XML_kpx_A2 Strict-Transport-Security: max-age=31536000; includeSubDomains \n <?xml version="1.0" ... >
Példa sikertelen lekérdezésre:

<?xml version="1.0" encoding="UTF-8"?> <QueryTransactionStatusRequest xmlns="http://schemas.nav.gov.hu/OSA/2.0/api"> <header> <requestId>RID049942600159403234974173</requestId> <timestamp>2020-07-06T12:45:49.000Z</timestamp> <requestVersion>2.0</requestVersion> <headerVersion>1.0</headerVersion> </header> <user> <login>...</login> <passwordHash>...</passwordHash> <taxNumber>...</taxNumber> <requestSignature>...</requestSignature> </user> <software> <softwareId>...</softwareId> <softwareName>...</softwareName> <softwareOperation>LOCAL_SOFTWARE</softwareOperation> <softwareMainVersion>7.27.6</softwareMainVersion> <softwareDevName>...</softwareDevName> <softwareDevContact>...</softwareDevContact> <softwareDevCountryCode>HU</softwareDevCountryCode> <softwareDevTaxNumber>...</softwareDevTaxNumber> </software> <transactionId>30W3VOBCN1F72LEF</transactionId> <returnOriginalRequest>1</returnOriginalRequest> </QueryTransactionStatusRequest>
Erre érkező válasz:

HTTP/1.1 100 Continue Content-Length: 0 \n HTTP/1.1 200 OK Connection: close Content-Type: text/xml;charset=UTF-8 Date: Mon, 06 Jul 2020 10:45:29 GMT X-Via: ppsaicxmlapi1.eszamla.local X-Server: backend_invoiceService-v2-queryTransactionStatus/XML_kpx_B1 Strict-Transport-Security: max-age=31536000; includeSubDomains \n \n
További infók:
- bármilyen XSD szerint valid, de amúgy nem létező tranzakciós azonosítóra értelmezhető hibaüzenet jön a NAV szervereitől minden esetben
- ugyanaz a kód állítja elő a számlafeladáshoz, egyéb lekérdezésekhez, annulációhoz, stb. köthető azonosítókat, hash-eket, stb., és azoknál nincs gond
- a PHP curl_* függvényeivel dolgozom, és a curl_exec() hívás előtt bekapcsolom, hogy a header-eket is adja vissza, és én magam bontom szét a választ (a bemásolt példa válaszok a curl_exec visszatérési értékét tartalmazzák, nincs módosítva)
- curl timeout-jai egyöntetűen 100-ra vannak állítva jelenleg, de 1mp-en belül megjönnek a HTTP fejlécek és a válasz (ha van) a NAV szervertől
- a password és a requestSignature mezők értékeit külső online hash-elővel ellenőriztem, hogy megfelelőek-e, és nincs velük gond
- azokat a tranzakciókat, amiket nem sikerült lekérdeznem elsőre, később sem tudom, még napok múltán sem, ugyanígy üres válasz érkezik
- PHP 5.6.33 van használva az adott szerveren
- éles és teszt NAV szerverre kapcsolódva is előáll a hiba

Szerintetek mi lehet ennek az oka? (Feltételezve, hogy nem a NAV szervereiben van hiba).
Más is tapasztalt ilyet?

Okozhatja valami azt, hogy a curl_exec() mégsem adja vissza a teljes választ? (Gondolom a content-length 0 értéke nem tesz jót). 

Köszönöm a segítséget!
Üdv: Péter
Mutasd a teljes hozzászólást!

  • Üdv. Ahogy elnézem ez egy eléggé elavult rendszer ha még 5.6-os PHP alatt fut. Amit kiraktál szerver választ nem sokat mond. Ugyanis hiányzik mind két esetben a body, amiben benne kellene legyen a szerver válasza a hiba vagy a helyes küldés esetén. Ebből sokminden nem deríthető ki, mivel a headerben 200-as kódot ír, nem valalmi beszédesebb státuszt, de még így is kell a body. Egyébként manapság eléggé leterhelt a NAV rendszere az új szabályzat miatt, szóval nem csodálkoznék azon sem, ha náluk lenne gond. Amit ajánlani tudok így hasra csapva, hogy válts át billingóra. Ők is eléggé leterheltek, de sokkal stabilabbak mint a NAV rendszere, ahol még a weboldal sem tölt be napokig. 

    Ha kényes adatokat nem akarsz kirakni ide, amit tejlesen megértek, írj rám a privát e-mail címemen (pihedy@gmail.com), és ráleshetek kicsit komolyabban is.
    Mutasd a teljes hozzászólást!
  • Szia!

    Köszi a válaszod!

    A BODY-k ott vannak: amikor helyes válasz jön, a HTTP fejlécek után egy újsor karajter jön, majd pedig az <xml ....>. Amikor "hibás" válasz jön, akkor nem jön XML, csak egy újsor karakter a teljes BODY. 

    Ha jön XML, akkor az mindig teljes és helyes is. Ha "hiba" van, akkor nem jön XML, csak egy újsor karaktert kapok a BODY-ban.

    Szerintem félreértetted, ez egy vállalatirányítási rendszer egy modulja, a rendszer kiállít egy számlát, akkor ez a modul feltölti a NAV-nak. 

    5.6-os PHP elavult, de tudomásom szerint nincs olyan hibája, hátránya, ami miatt ne kellene működnie a funkciónak. Ráadásul, miért pont 07.02-án romlana el, és 07.01-én még miért menne minden tökéletesen - vetődne fel a kérdés.

    Ha a NAV leterhelt, akkor kellene legyen sok más panaszkodó is, úgy vélem. Illetve ingadoznia kellene a lekérdezések sikerességének eloszlása is, hol több, hol kevesebb sikeres lekérdezés kellene, hogy legyen. Sőt, a válaszidőknek is több, mint 1-2mp hosszúaknak kellene lenniük, valószínűleg. Ezek egyikét sem tapasztalom (heti több ezer számláról van szó). 

    Üdv: Péter
    Mutasd a teljes hozzászólást!
  • Az 5.6 lassú, és már évek óta nem szupportált. Ez azt jelenti, hogy ha van is benne seurity issue, akkor azt már nem fogják frissíteni, perszte ez a te felelősséged.

    A másik meg volt panasz nem is kevés a NAV rendeszeréről, csak ezek szerint elkerülhetett. Elsejétől vezették be azt, hogy minden számlát elektronikusan kell kezelni. Szóval aki eddig nem így csinálta, ezenetúl így kell csinálnia! Lehetett választani, Billingó, Számlázz.hu vagy a NAV rendszere. Nos mivel a NAV rendszere totality free, ezért eléggé sokan oda kezdték küldözgetni a számlákat, amitől a rendszerük napokig nem volt elérhető normálisan, többször össze is omlott, és még a weblapjuk sem jelent meg, vagy csak részleteiben. Szerintem neked is ez lehetett a gond, csak mivel te eddig is így küldted, mint ahogy írtad is, elkerülhetett a hír.
    Mutasd a teljes hozzászólást!
  • Szerintem elbeszélünk egymás mellett.

    Indult egy olyan szolgáltatás a NAV-nál 2018-ban, hogy a 100.000 Ft feletti ÁFA tartalmú számlákat a kiállításukat követően be kell küldeni hozzájuk egy API-n keresztül (E-invoice), most 07.01-től pedig minden belföldi számlát be kell küldeni hozzájuk, ÁFA tartalomtól függetlenül.
    Én erről beszélek.

    A NAV ingyenes számlázóját nem is láttam még, és nem is kapcsolódik ehhez a kérdéshez.
    Mutasd a teljes hozzászólást!
  • Ezek szerint egy kicsit igen, de szerintem egy szerveren futtatják az egészet. Szóval ha az egyik lehal, akkor a másiknak is annyi. Persze ezt jobb lenne élesben látni, meg a másik, hogy ezt a rendszert felfrissíteni, teszteket írni rá, és lefedni hibaüzenetekkel. Mint mondtam az 5.6-os php rég nem szupportált, és a 7.4-es 4-szer 5-ször gyorsabb. Performance szermpontból sokkal előnyösebb. 

    Személy szerint áttenném az egészet Guzzle-re, mivel az jóval verbózabb mint a CURL, és könyebben skálázható is. 

    Azóta előfordult-e a hiba?
    Mutasd a teljes hozzászólást!
  • Igen, folyamatosan fennálll, a tranzakciók 80%-át sem a számlafeladás után, sem később nem tudom lekérdezni, míg a maradékot minden gond nélkül.

    A lekérdezések egymástól csak a tranzakciós azonosítóban, a request ID-ben, a timestamp-ekben, illetve a generált hash-ekben térnek el egymástól.
    Mutasd a teljes hozzászólást!
  • Igen, néztem is, és összediffeltem. Gondoltam, lehet egy tag lett elírva, de nem. Milyen rendszeren fut ez a script? Egy egyéni weboldal, vagy valami wordpress, drupal vagy prestashop?
    Mutasd a teljes hozzászólást!
  • Ez egy kis CLI alkalmazás, egy másik szoftver indítja el, ami egy nagyobb ügyviteli rendszertől kap kérést.
    Kap inputot és visszaad egy kimenetet, nincs semmilyen publikusan elérhető felülete, sem webszerver hozzá, stb.
    Mutasd a teljes hozzászólást!
  • Akkor az alkalmazás fejlesztőjével kell beszélni, hogy lessen rá a problémára, vagy kapcsolatba lépni a NAV szupportjával, hogy ők milyen hibát látnak, mert az hogy a body-ban semmi hibaüzenet, ráadásul még a visszatérés státusza is 200-as még hiba esetén is, eléggé átejtik az ember a palánkon. 

    Persze ha nem jut düllőre, írjon rám, és szívesen segítek.
    Mutasd a teljes hozzászólást!
  • A NAV-nak írtam pár napja, de semmi válasz nem jött tőlük (gondolom le vannak terhelve). :( 

    Az alkalmazást én fejlesztettem, az alkalmazás elég jól le van fedve unit és end-to-end tesztekkel is. 
    Ha nem a NAV-nál van a hiba oka, akkor vagy az adatok rosszak, amit küldök a NAV felé (ez nem valószínű), vagy a curl valamiért nem dolgozza fel a teljes választ (néhány napja).

    Ilyesmit nem tapasztaltam még a curl-al, és a neten sem találtam ilyen hibát vele kapcsolatban.

    Lehet, hogy a NAV-nál csak ennél az ügyfelemnél van ilyen probléma, és egyedi eset... :D Sajnos kifogytam az ötletekből, a NAV-ra várhatok hetekig, mire talán válaszolnak, és az ügyfelem meg rengeteg számlafeladást kénytelen maga ellenőrizni, mert a NAV API-jából nem jön vissza érdemi válasz...
    Mutasd a teljes hozzászólást!
  • Szerintem cseréld ki a CURL-ös részt Guzzle-re, hogy az mit ad vissza. Lehet kapsz egy olyan üzenetet ami alapján ki tudsz már indulni a debugolásból, vagy tényleg kiderül, hogy a NAV-nál van-e a gond. A Guzzle-nél a 6.x-es verziók támogatása a 5.5-ös php-nál indulnak. 

    De én nagyon gyanítom, hogy a NAV-nál nem okés valami. De a legvégső esetben váltani kell másik számlázásra. Ott legalább van rendes support! :D
    Mutasd a teljes hozzászólást!
  • Milyen másik számlázásra gondolsz? :D Tényleg nem értem, hogy mi köze a számlázásnak a számlák NAV-hoz történő beküldéséhez. Nincs más hatóság, ahova a számlákat beküldheted.
    Mutasd a teljes hozzászólást!
  • Amúgy van már erre topik:
    https://prog.hu/tarsalgo/188874-15634/adohatosagi-ellenorzesi-adatsz..

    Nem kell teleszemetelni a prog.hut mindenféle új topikokkal azonos témában, ráadásul ott van egy csomó ember, aki ezzel foglalkozik. 

    Én is azt mondom, ez a részlet nem sokat mond, küldd be a teljes kódot, xmllel együtt, biztos van rá megoldás. Én több ezer szàmlàn vagyok túl, nincs itt semmi gond.
    Mutasd a teljes hozzászólást!
  • Köszönöm a kioktatást! :) 

    Feltettem ott a kérdést, senki sem reagált rá. (Te sem).

    Mivel nem akarom hetente feltenni ott újra, ezért nyitottam neki egy külön topikot. (Valamint egy idő után eluntam a személyeskedő, parttalan vitákat, amivel egyesek tizenegynéhányezerre szaporítják a hozzászólásokat ott. :D )

    Sajnos a teljes kódot nem küldhetem be, mert nem az én tulajdonom. :) 
    Az alábbi kódrészletet tudom megosztani (az eredeti projekt ettől struktúráltabb, de ezzel is tökéletesen reprodukálható):

    $ch = curl_init('https://api.onlineszamla.nav.gov.hu/invoiceService/v2/queryTransactionStatus'); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/xml;charset="UTF-8"']); curl_setopt($ch, CURLOPT_POSTFIELDS, $requestXML); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_HEADER, 1); curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 100); curl_setopt($ch, CURLOPT_TIMEOUT, 100); $result = curl_exec($ch);
    A
    $requestXML
    -ben az első hozzászólásban található XML-ek vannak.
    A
    $result
    változó tartalmának kiírásakor kapom azokat a fejléc és response body adatokat, amiket az első hozzászólásban mutattam.

    (Annyi kiegészítést megemlítek, mert bár triviális, de ki tudja, ki veti a szememre, az $xmlRequest-ben NEM pontosan ugyanazok az XML-ek vannak, mivel a requestId-knek egyedieknek kell lenniük, tehát a kapcsolódó hash-ek minden lekérdezéskor újra vannak generálva, és persze az időbélyegek sem azonosak.)

    Megjegyzem (többedjére), hogy a számlabeküldések mindig működnek, és ugyanaz a kód állítja össze az XML hitelesítéssel kapcsolatos részét, valamint ugyanaz végzi a hálózati kommunikációs részét is. Sőt, nem győzöm elégszer leírni, hogy ugyanaz a XML generáló és hálózaton kommunikáló kód hol jó, hol nem jó választ csikar ki a NAV szervereiből. Sőt, azokat a számlákat, amiket a NAV befogadott, vagy le tudom kérdezni az API-n keresztül, vagy nem. Ha a tranzakciót nem tudom, akkor a számla adatokat sem, és fordítva. Holott a NAV webes felületén látható, hogy a státusz DONE és el rendben be is kerültek az adatok.
    Mutasd a teljes hozzászólást!
  • Üdv, nekem nincs konkrét tapasztalat a problémás service-el. Ami a http válaszokból látszik, hogy két különböző szerver (instance?) szolgálja ki a kéréseket.

    X-Via: ppsbicxmlapi2.eszamla.local X-Server: backend_invoiceService-v2-queryTransactionStatus/XML_kpx_A2 vs. X-Via: ppsaicxmlapi1.eszamla.local X-Server: backend_invoiceService-v2-queryTransactionStatus/XML_kpx_B1
    Nem tudom van-e/tudsz-e más ügyfelek adatai alapján keresni olyan esetet, aminél szintén a problémás szerver a kiszolgáló. Ha van olyan ahol ettől a szervertől jön a válasz és nincs vele gond, akkor elképzelhető, hogy ügyfélspecifikus probléma, ha nincs ilyen, akkor lehet az adott szerver (instance) problémája. Mindkét eset gyanúsan NAV oldali gondnak tűnik a leírtak alapján.
    Mutasd a teljes hozzászólást!
  • curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_0);
    Mutasd a teljes hozzászólást!
  • Köszönöm az ötleteket, de jóval szokatlanabb megoldás lett a vége.

    Privát üzenetben hívta fel a figyelmem egy kedves prog.hu-s kolléga, hogy másnak is vannak hasonló problémái:

    [Q&A] queryInvoiceData nem minden cégnél működik · Issue #305 · nav-gov-hu/Online-Invoice
    [Q&A] queryInvoiceDigest üres válasz · Issue #300 · nav-gov-hu/Online-Invoice

    Curl 7.71-re frissítés után parancssorból és PHP lib segítségével is pöccre megy minden.  Az XML-ekhez nem kellett nyúlni.

    Curl 7.38 és 7.58 verziók esetén egyaránt fennáll a fenti hiba, reprodukálhatóan.

    Nem volt még időm kibogarászni, hogy mi változhatott a kommunikációban, ami miatt 06. 30.-tól előbújt ez a hiba.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd