[Q&A] Tömeges techn.érvénytelenítés jóváhagyása elsődleges felhasználó által.

[EnokhSys]

Elnézést a kérdésekért, próbáltam kideríteni a választ a neten, de nem jártam sikerrel.

Tegyük fel, hogy technikai érvénytelenítésre be kell küldeni 1.200 db. számlaszámot, amely az elmúlt negyedévre vonatkozik (2024 jan-már) . Ezeket beküldheti a vállalatirányítási rendszer egyesével is, de beküldheti százasával is.

A két kérdésem pedig a következő lenne:

1. Van-e arra lehetősége az Elsődleges Felhasználónak, hogy a webes felületen lekérdezze a 2024.01.01-2024.03.31 közötti technikai érvénytelenítési kéréseket, és ezt az 1.200 Db.-ot egyetlen gombnyomással jóváhagyja?

2. Ha az első variációra nincs lehetőség, akkor milyen más lehetősége van az Elsődleges Felhasználónak arra, hogy ne kelljen az 1.200 db. számlának a technikai érvénytelenítését egyenként jóváhagynia?

Előre is köszönöm!

[EnokhSys]

Rég jártam erre, már nem emlékszem, hogy meg kell-e jelölnöm valakit, akitől választ várok, de biztonságból beírom: @NTCA-developer , @NTCA-supporter.

[Volfid]

Szia,

Emlékeim szerint tud az érvénytelenítés megerősítésénél dátumra/beküldő felhasználóra szűrni, és egyben 50 tranzakciót jóváhagyni. Mivel ezek már beküldésre kerültek, más opciót nem látok sajnos, jövőben érdemes ezeket 100-as batchekben küldeni, és akkor csak 12 tranzakciót kell jóváhagynia.

[renced42]

Kedves @EnokhSys Batch-ben 100-at tudsz beküldeni és ezeket tudod jóváhagyni ez a legkevesebb.

[EnokhSys]

Kedves @Volfid,

köszönöm szépen. Tehát, ha jól értem: ha egyesével kerülnek beküldésre a technikai érvénytelenítési kérések, akkor az Elsődleges Felhasználónak lehetősége van arra, hogy ezeket ötvenesével hagyha jóvá? (Azt értem, hogyha 100-as csomagban kerülnek beküldésre, akkor az Elsődleges Felhasználó 100-asával, azaz csomagonként tudja ezeket elfogadni.)

[Volfid]

Kedves @EnokhSys

Mindkét esetben lehet 50-esével elfogadni őket, csak ha 100-as csomagokban vannak beküldve, akkor ez 5000 tételt jelent. Át tudja állítani a megjelenítési listát, hogy 50 sort mutasson egyszerre, és bal oldalt a kijelölés négyzetek felett van egy legördülő lista, amivel minden kijelölte ugyan azt az akciót nyomhatja a felhasználó (elfogadás/elutasítás), szóval ha mindet kijelöli a táblázat tetején a négyzettel, egyben elfogadhatja mindet.

[EnokhSys]

Kedves @renced42,

köszönöm a választ, de akkor pontosítok a kérdésemen: amennyiben egy negyedévre vonatkozóan, egyesével vannak beküldve az érvénytelenítési kérések, akkor az Elsődleges Felhasználónak mennyi a legtöbb, amit egyetlen gombnyomással jóvá tud hagyni? (Ha jól értem @Volfid válaszát, akkor 50?)

[EnokhSys]

Kedves @Volfid

értem, nagyszerű, köszönöm szépen! Akkor még egy utolsó kérdés: amikor az Elsődleges Felhasználó lekérdezi a technikai érvénytelenítési kéréseket, akkor mekkora lehet a max időtartomány (pl. 30 nap, 180 nap?), illetve kötelezően meg kell adja a technikai felhasználó kódját is, amellyel be lett küldve az 1200 db kérés?

[renced42]

Kedves @EnokhSys itt látod #1069 :)

[Volfid]

Kedves @EnokhSys Nem tudok róla, hogy lenne max időtartam, de sose próbáltam több mint 2 napot lekérdezni. Nem kötelező megadni a felhasználó kódját, csak hasznos lehet, ha esetleg több technikai felhasználó is érvénytelenít.

[EnokhSys]

Kedves @renced42

nagyon köszönöm, ez most már világos. Időközben felmerült egy kérdés a dokumentációval kapcsolatban is, a 65-ik oldalon ez áll.

"_8) Az annulmentVerificationStatus jelzi az egyes technikai érvénytelenítésekre vonatkozó adatszolgáltatások jóváhagyási állapotát. NOTVERIFIABLE = az annulment kérés aszinkron feldolgozásakor bármely index ERROR értéket kapott (ilyen esetben a teljes technikai érvénytelenítés elutasításra kerül a többi indexre is, a beküldést meg kell ismételni a szükséges javítások után)."

Nézzük a gyakorlatban:

1. • Beküldök a ManageAnnulmentRequest -el egy 100-as csomagot.
2. • Visszakapok a ManageAnnulmentResponse -ban egy transactionID-t.
3. • A QueryTransactionStatusRequest -el lekérdezem a visszakapott transactionID-t.
4. • Tegyük fel, hogy az 1-es lépésben beküldött 100-as csomagban van egyetlen olyan számla, amellyel valami hiba van (pl. hiányzik a NAV-nál, vagy az adatszolgáltatás önmagában a számla). Jól értelmezem-e, hogy ebben az esetben azt a választ fogom visszakapni mind a 100 indexre, a "annulmentVerificationStatus" tagban, hogy "NOT_VERIFIABLE"?

Tehát ebben az esetben, ki kell vennem ezt a hibás számlát a 100-as csomagból, majd ismételten végre kell hajtanom az 1-4-es lépéseket, míg végül vissza nem kapom a 4-ik lépésben a "VERIFICATION_PENDING" jelzőt? (A vállalatirányítási rendszer, ezen válasz alapján küld értesítést az elsődleges felhasználónak, hogy jóváhagyhatja a technikai érvénytelenítési kéréseket, mert azok megjelentek a NAV-nál.)

[EnokhSys]

Értem kedves @Volfid, köszönöm szépen a segítséget!

[EnokhSys]

Kedves @renced42 és @NTCA-developer!

Elkészítettem a számlák technikai érvénytelenítésére vonatkozó programot, de a ManageAnnulmentRequestre, a NAV tesztben az alábbi hibaüzenetet kapom. A requestSignature-t leellenőriztem az SHA3-512 szerint, az is renben van. A TokenExchangeRequestre a tokent rendben megkapom, ami azt jelenti, hogy a header, user és software szekciók rendben vannak.

`

ERROR INVALID_REQUEST Érvénytelen kérés!

`

Háromszor átnéztem az egész XML-t, azt is, amit BASE64-ben adok át, és semmi hibát nem látok. Hová tudnám elküldeni ezt a tesztállományt elemzésre a fejlesztőcsapatnak?

[EnokhSys]

Tulajdonképpen betehetem ide is a kódot, mert ezek mind tesztadatok:

<exchangeToken>fea3fa44-1b83-477a-9a1c-d42f9e362cc74LNA1W16ZTH9</exchangeToken>

  <annulmentOperations>
    <annulmentOperation>
      <index>1</index>
      <annulmentOperation>ANNUL</annulmentOperation>
      <invoiceAnnulment>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIiA/Pgo8SW52b2ljZUFubnVsbWVudCB4bWxucz0iaHR0cDovL3NjaGVtYXMubmF2Lmdvdi5odS9PU0EvMy4wL2FubnVsIj4KCiAgPGFubnVsbWVudFJlZmVyZW5jZT5QSDI0MDEzNzU1PC9hbm51bG1lbnRSZWZlcmVuY2U+CgogIDxhbm51bG1lbnRUaW1lc3RhbXA+MjAyNC0wNi0wNFQwNjoyMzoyMy4wMDBaPC9hbm51bG1lbnRUaW1lc3RhbXA+CgogIDxhbm51bG1lbnRDb2RlPkVSUkFUSUNfREFUQTwvYW5udWxtZW50Q29kZT4KCiAgPGFubnVsbWVudFJlYXNvbj5IacOhbnl6w7Mgc3rDoW1sYSB0w6l0ZWxlay48L2FubnVsbWVudFJlYXNvbj4KCjwvSW52b2ljZUFubnVsbWVudD4K</invoiceAnnulment>
    </annulmentOperation>
    <annulmentOperation>
      <index>2</index>
      <annulmentOperation>ANNUL</annulmentOperation>
      <invoiceAnnulment>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIiA/Pgo8SW52b2ljZUFubnVsbWVudCB4bWxucz0iaHR0cDovL3NjaGVtYXMubmF2Lmdvdi5odS9PU0EvMy4wL2FubnVsIj4KCiAgPGFubnVsbWVudFJlZmVyZW5jZT5QSDI0MDEzNzU2PC9hbm51bG1lbnRSZWZlcmVuY2U+CgogIDxhbm51bG1lbnRUaW1lc3RhbXA+MjAyNC0wNi0wNFQwNjoyMzoyMy4wMDBaPC9hbm51bG1lbnRUaW1lc3RhbXA+CgogIDxhbm51bG1lbnRDb2RlPkVSUkFUSUNfREFUQTwvYW5udWxtZW50Q29kZT4KCiAgPGFubnVsbWVudFJlYXNvbj5IacOhbnl6w7Mgc3rDoW1sYSB0w6l0ZWxlay48L2FubnVsbWVudFJlYXNvbj4KCjwvSW52b2ljZUFubnVsbWVudD4K</invoiceAnnulment>
    </annulmentOperation>
    <annulmentOperation>
      <index>3</index>
      <annulmentOperation>ANNUL</annulmentOperation>
      <invoiceAnnulment>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9Im5vIiA/Pgo8SW52b2ljZUFubnVsbWVudCB4bWxucz0iaHR0cDovL3NjaGVtYXMubmF2Lmdvdi5odS9PU0EvMy4wL2FubnVsIj4KCiAgPGFubnVsbWVudFJlZmVyZW5jZT5QSDI0MDEzNzU3PC9hbm51bG1lbnRSZWZlcmVuY2U+CgogIDxhbm51bG1lbnRUaW1lc3RhbXA+MjAyNC0wNi0wNFQwNjoyMzoyMy4wMDBaPC9hbm51bG1lbnRUaW1lc3RhbXA+CgogIDxhbm51bG1lbnRDb2RlPkVSUkFUSUNfREFUQTwvYW5udWxtZW50Q29kZT4KCiAgPGFubnVsbWVudFJlYXNvbj5IacOhbnl6w7Mgc3rDoW1sYSB0w6l0ZWxlay48L2FubnVsbWVudFJlYXNvbj4KCjwvSW52b2ljZUFubnVsbWVudD4K</invoiceAnnulment>
    </annulmentOperation>
  </annulmentOperations>

Ennél egyszerűbb már nem is lehetne ez az XML, mégis elakad. Pedig most ismét átnéztem a dokumentációt, és mindenben megegyezik az abban leírtakkal.

[EnokhSys]

Kedves @renced42 és @NTCA-developer,

közben megtaláltam a probléma okát, így az előző két bejegyzésem tárgytalan.

[somkuti]

Kedves @EnokhSys,

megkérdezhetem, hogy mi volt a probléma? Szintén ugyan ez a probléma nálam is.

[renced42]

Sziasztok!

Ezen hiba esetén általában az XML formátuma nem megfelelő. De ezt írja is a specifikáció. Érdemes XSD validálni az előállított xml-t szintaktikailag és szematikailag is.

[somkuti]

Sziasztok,

mellékeltem a XML-t, próbáltuk mindenhogy, de nem találjuk benne a hibát.

<?xml` version="1.0" encoding="utf-8"?>
<invoiceAnnulment xmlns="http://schemas.nav.gov.hu/OSA/3.0/annul"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://schemas.nav.gov.hu/OSA/3.0/annul invoiceAnnulment.xsd"
xmlns:common="http://schemas.nav.gov.hu/NTCA/1.0/common"
xmlns:base="http://schemas.nav.gov.hu/OSA/3.0/base"
targetNamespace="http://schemas.nav.gov.hu/OSA/3.0/annul">
<annulmentReference>2024-123456</annulmentReference>
<annulmentTimestamp>2024-06-05T14:02:21.000Z</annulmentTimestamp>
<annulmentCode>ERRATIC_DATA</annulmentCode>
<annulmentReason>Technikai érvénytelenítés</annulmentReason>
</invoiceAnnulment>

[renced42]

Kedves @somkuti

Ez az XML ránézésre nem jó. A <?xml után van egy aposztróf. Aztán érdemes lenne megnézni a boríték XML-t is. Mert abban is lehet hiba.

[somkuti]

Kedves @renced42 Az XML valójában nem tartalmazza azt az aposztrófot, csak amikor átmásoltam ide, akkor sikerült valahogy belekeverni.

[renced42]

Kedves @somkuti akkor a borítékot nézzétek még meg, magát a request xml-t.

[somkuti]

mellékelem a request xml-t is

<ManageAnnulmentRequest xmlns:common="http://schemas.nav.gov.hu/NTCA/1.0/common" xmlns="http://schemas.nav.gov.hu/OSA/3.0/api">
  <common:header>
    <common:requestId>S000032021D210002E2</common:requestId>
    <common:timestamp>2024-06-06T13:13:59.000Z</common:timestamp>
    <common:requestVersion>3.0</common:requestVersion>
    <common:headerVersion>1.0</common:headerVersion>
  </common:header>
  <common:user>
    <common:login>xxxxxxx</common:login>
    <common:passwordHash cryptoType="SHA-512">xxxxxxx</common:passwordHash>
    <common:taxNumber>xxxxxxx</common:taxNumber>
    <common:requestSignature cryptoType="SHA3-512">xxxxxxx</common:requestSignature>
  </common:user>
  <software>
    <softwareId>xxxxxxx</softwareId>
    <softwareName>xxxxxxx</softwareName>
    <softwareOperation>xxxxxxx</softwareOperation>
    <softwareMainVersion>xxxxxxx</softwareMainVersion>
    <softwareDevName>xxxxxxx</softwareDevName>
    <softwareDevContact>xxxxxxx</softwareDevContact>
    <softwareDevCountryCode>xxxxxxx</softwareDevCountryCode>
    <softwareDevTaxNumber>xxxxxxx</softwareDevTaxNumber>
  </software>
  <exchangeToken>ce8d5e79-a329-4c81-9875-ddf32a0855464LP0APZSCRSY</exchangeToken>
  <annulmentOperations>
    <annulmentOperation>
      <index>1</index>
      <annulmentOperation>ANNUL</annulmentOperation>
      <invoiceAnnulment>xxxxxxx</invoiceAnnulment>
    </annulmentOperation>
  </annulmentOperations>
</ManageAnnulmentRequest>

[EnokhSys]

Kedves @somkuti,

nálam az volt, hogy rossz feldolgozási motornak küldtem a requestet: nem ManageAnnulment-nek címeztem a küldeményt, hanem ManageInvoice-nek, miközben a requester XML -ben helyesen, végig a /ManageAnnulmentRequest szerepelt. Ezért volt megtévesztő a visszakapott hibaüzenet XML formátuma, mert ebből úgy tűnt, hogy magában az XML-en belül kell keresnem a hibát, holott az azon kívül volt.