[Q&A] QueryTaxpayerResponse hiányos XML struktúra

[cycle20]

Sziasztok!

QueryTaxpayerResponse-al kapcsolatban kérdezném az alábbiakat:

• Hogyan lehetséges az, hogy sémának nem megfelelő XML-t kapok válaszként? Ha kötelező adat nincs nyilvántartásba véve, akkor is megkapom a részleges választ minden esetben? Erre a jövőben is számíthatok? (kaptam olyan response-t, amiben nincs publicPlaceCategory)
• Ezek szerint szerver oldalon küldés előtt nincs XSD validálás?

Üdv, Csongor

[NTCA-developer]

Szia @csgerdan !

Ez számunkra is ismert hiba, már folyamatban van a javítása. A probléma azért jelentkezik mert vannak olyan címadatok, amelyek nem tartalmaznak kis szemcsés, bontott címadatot, hanem csak konkatenált, bontatlan címet. A javítás a 2.8.3-as verzióban fog élesedni (a teszten most a 2.8.2 van) és úgy fog működni, hogy:

• ha van bontott cím, akkor a street és a publicPlaceType tagekben megkapot a kis szemcsés adatot
• ha csak bontatlan cím van, akkor azt megkapod egyben a street-ben, a publicPlaceType pedig az 'N/A' stinget fogja tartalmazni
• ha sem street sem publicPlaceType nincs, akkor mindkét tag az 'N/A' stinget fogja tartalmazni (de ebben az esetben az opcionális tagek közül lesz helyrajzi szám)

A lekérdezésekkor a fenti logikára számíthatsz.

[cycle20]

Köszönöm szépen a gyors választ. Már csak egy extra kérdés kíváncsiságból:

Milyen technikai/fejlesztési akadálya van annak, hogy a taxpayerAddress AddressType típusú legyen, így ha nincs elég adat DetailedAddressType-hoz, akkor SimpleAddressType-ot adna vissza a lekérdezés?

Egyelőre nem látom át az egész API-t teljes egészében, az is lehet, hogy történeti/jogszabálybeli háttere van annak, hogy itt mindenképpen DetailedAddress-nek kell visszajönnie.

[NTCA-developer]

Nincs akadálya, sőt pont ez volna a leguniverzálisabb. Hogy most nem cseréljük le a típust a sémában annak az az oka, hogy túl sokan függenek a válasz formájától (Online Számlázó, mobilapp) és jelenleg nem tudjuk a meglévő feladatok mellett úgy ütemezni, hogy mindenkinek jó legyen. A másik ok valóban egy üzleti döntés, hogy amennyiben lehet akkor mindig adjunk detailedAddress-t. A frontend is ennek megfelelően működik, csak ugye ott van ember, aki szétbontja a címet.

A harmadik oka (és ez már csak metodika) hogy jót tenne a sémának, ha a choice-ok kikopnának belőle, vagy legalább a számuk csökkenne, mert segíti az átláthatóságot és könnyebb is erre programozni.

Majd kérlek zárd le ha nincs több kérdésed.

[cycle20]

Köszönöm szépen. Részemről lezárva.