[Q&A] Bejövő számlák lekérdezése 2.0 3.0 formátum különbségek

[nbeeps2]

Tervezem megvalósítani, hogy a programban le lehessen tölteni a bejövő számlákat. E kapcsán nem világos számomra, hogy amikor majd fel akarom dolgozni a számlákat, akkor ismernem kell a korábbi sémákat is, vagy van valamilyen lekérdezés, ami a mindig a legfrissebb formátumot használja. Ez utóbbinak örülnék, mert ha nem így van, akkor a bejövő számlák lekérdezésénél mindig foglalkozni kellene olyan régi XML szerkezetekkel, amik már nem aktuálisak.

Tehát a kérdésem, hogy van olyan response, ami mindig az aktuális struktúrában adja a bejövő számlát? Fiktív példa: tehát a 3.2-ben a számlaszámot invoiceNumber mező tárolja, majd a 3.3-ban át lesz nevezve invno-nak. Akkor ha lekérem a 3.3-ban a számlát és ki szeretném olvasni a számlaszámot jó lenne, ha mindig a legújabb séma szerint adná vissza az adatot, hogy ne kelljen felprogramozni több évnyi sémaváltozást visszamenőleg.

[EPluribusUnum]

@nbeeps2 , igen ismerned kell a korábbi sémákat. Abban kapod meg, amiben fel lett töltve. Viszont nem kapsz magasabb verziót, mint amiben kérdezel. 2.0 API-ban jöhet 1.0, 1.1, 2.0 válasz. 3.0 API-ban jöhet 1.0, 1.1, 2.0, 3.0 válasz.

[nbeeps2]

@EPluribusUnum ez nagyon rossz hír. Mi lesz 10 év múlva? :) Ez nem jó megoldás. Egy olyan megoldás kellene, ahol, ha lekérdezem a számla alapadait, azt egy aktuális séma szerint adja vissza mindig. Kicsit úgy, mint ahogy ha belépek a NAV Online számla felületbe és felhasználóként böngészek, akkor tök mindegy számomra, hogy 1.0, 1.1. 2.0, 3.0-ban történt az adatszolgáltatás, látni akarom a számla alapadatait.

[EPluribusUnum]

@nbeeps2 , mi ezzel a probléma? Mindig a legmagasabb API-n megy a számla lekérdezés hogy az összes feltöltöttet le tud szedni. Utána a válaszba lévő verzió +compress alapján megy verzió függeőn a base64/xml feldolgozása. Simán megoldottuk. Hol a buktató?

[nbeeps2]

@EPluribusUnum : Mi a buktató? Sorold fel nekem kérlek tű pontosan, hogy csak a manageInvoice érintő struktúra pontosan hogy változott. Én mindig lekövettem a beküldést a stuktúra szerint, de nem jegyeztem fel, hogy mi-mikor-mire változott. Már ennek utánajárása is óriási feladat. A probléma viszont az, hogy ez rossz elgondolás, mert ha lesz még 20 sémaváltozás, akkor azokkal folyamatosan hízlalod és bonyolítod a forráskódot, ahelyett, hogy a beküldéshez hasonlóan a lekérdezés is mindig a legújabb formátum szerint történjen. Nyilván lehetnek olyan mezők, ahol ez nem lehetséges, pédálul a most bevezetett case/reason esetében, de ott még ha UNKNOWN vagy üres értékkel meg lehetne oldani

[nbeeps2]

@EPluribusUnum A teszt verziókról már ne is beszéljük, hogy ha beküldtem a 3.0-van privaterpersonindicator-os számlát, de a jövőhéten megjelent 3.0-ban már customerVatStatus lesz, de a bejövő számla lekérdezés ezek szerint privaterpersonindicator-t fog visszaadni, mert úgy küldtem be a számlát. Így már érted mi a gondom?

[nbeeps2]

Az én javaslatom, hogy technikai célból maradjon meg annak a lehetősége, hogy az eredeti beküldött XML-t meg lehessen nézni, lehet, hogy valakinek ez fontos valamire, viszont legyen egy olyan lekérdező funkció, ami mindig egy fix strukturában adja vissza azokat a számla adatokat, ami a bejövő számla lekérdezéshez szükséges: kiállító adatai, vevő adatai, fizetési mód, kelt, dátum, fizetési határidő, számlatételek, stb.

[EPluribusUnum]

@nbeeps2 , teszt környezet nem érdekel. Élesbe nincs olyan hogy egy verziószám alatt eltérő séma van. Ne fordítsa át a NAV az xml-t. Azt kell a befogadó oldalon letölteni, amit a másik feltölt különben sérül a számla integritása. Semmit sem ér a HASH, és a NAV bármikor megvádolható számla tartalom manipulációval. És igen, az összes séma benne van a programban és kezeli, folyamatosan hízik. Ezzel együtt kell élni, de ez business requirement és nem technical.

[nbeeps2]

@EPluribusUnum téged a teszt környezet nem érdekel, engem meg a már elavult XML struktúrák, amivel 2 éve küldtek be számlát, minden csak nézőpont kérdése ;)

Semmilyen integritás nem sérül. Bejövő számla letöltésre gondolok alapadatokkal és nem arra, hogy valaki ezzel nézze meg egy számla hitelességét. Ezt az ÚJ funkciót arra használnám, hogy a programba fel tudja tölteni a bejövő számlákat és nem a felhasználónak kelljen azt felrögzíteni.

[EPluribusUnum]

Épp erre használjuk, hogy letöljük és beadjuk szállítói oldalra, erre is van szánva az API. A számla struktúra nem elavult, továbbra is élnek a korábbi verziók és élniük is kell, továbbra is lehet rajtuk számlákat feltölteni, ha dátum határ szerint oda esnek. (anulálás + újra feltöltés, jogi peres számla miatti késői rögzítés, stb...) Ha kidobtadd a kódodból az 1.0, 1.1 verziókat, akkor azzal korlázotatad magadat és nem tudsz lekezelni eseteket, amiket a törvény megkövetel.

[omachtandras]

@nbeeps2 mi is erre használjuk. Ha Téged nem érdekelnek a régi sémák, akkor ne implementáld. Vélhetően 2021. júliusában senki nem fog 2.0-s verziójú számlát kapni, ezért átfordítani sincs értelme 3.0-s változatra, Neked sem kell implementálnod már a 2.0-s változatot. Ha pedig bejön a 4.0-s változat, akkor semmi plusz teendőd nem lesz, a 3.0-s változat már kész van, ha abban jön számla, akkor megy azon az ágon, ha 4.0-ban, akkor meg a másikon.

Mi magunk sem tudnánk megcsinálni a 2.0 -> 3.0 konverziót pl. a mentességi okok változása miatt, és nagyon nem is szeretném, ha a NAV valamilyen módon konvertálgatna. Sokkal jobb, hogy jön 2.0-ra, megvan rá a korrekt kód, tiszta eset.

[nbeeps2]

@EPluribusUnum @omachtandras: Nem győzőm hangsúlyozni, hogy ez egy ÚJ API request igény lenne részemről, természetesen nem kívánom, hogy a már meglévő dolog változzon. Szerintem érthető az igényem és abszolút jövő álló azzal szemben, hogy a program visszamenőleg tartalmaz majd 10 évnyi XML változást. Igen, kidobtam a kódomból az 1.0-t, 1.1-t és a 3.0 megjelentésével a 2.0-t is ki fogom. Nekem erre nem volt eddig szükségem. Amit írtál pár kivételes esetet meg lehet csinálni a NAV Online felületen. Nem vagyok biztos egyébként benne, hogy amit beküldtem 1.1-el, azt ne tudnám 2.0-val anulálni, de lehet, hogy így van, nem próbáltam.

[EPluribusUnum]

@nbeeps2 , nem tudsz magasabb verziós xml-t előállítani régi számlákból, mert a magasabb verziós xml-ek mindig tartalmaztak olyan új kötelező adatot, ami a számla kiállításakor még nem volt tudható, így nincs meg az adat a régi számla mellett, így csak régi formátum előállításához van elegendő adat. Amúgy meg eleve kelt dátumhoz van kötve a verziószám és erre NAV ellenőriz is, egyszereűen nem is enged magasabb verzióba beküldeni, ha dátum alapján nem abba tartozik.

[nbeeps2]

@EPluribusUnum és akkor ez az üzenet mire vonatkozik: "Felhívjuk a figyelmüket, hogy a karbantartás után az Online Számla v1-es végpontja, ami egyébként adatszolgáltatást már nem fogad, elérhetlenné válik." Ha leállították a v1-es végpontot, akkor most hogy tudnál újraküldeni egy 1.0-ás számlát? Ráadásul már eleve úgy fogalmaztak, hogy adatszolgáltatást már eleve nem fogadott akkor sem.

[EPluribusUnum]

@nbeeps2 , nem láttam azt. Az probléma ha kinyírják. Már nyitom is neki az issue-t.

[nbeeps2]

Egyébként még nem teljesen vágom ezt a bejövő számla lekérdezés témát. A QueryInvoiceDigest-nál InvoiceDigestType -ban látok fő adatokat. Akkor csak ha a számlatételekhez akarok hozzáférni, akkor kell nekem a queryInvoiceData?

[EPluribusUnum]

Igen, először insDate (vagy más) adat alapján lekérsz egy listás, abba csak alap és metaadatok vannak, mad után egyesével jön a queryInvoiceData tranzakciónként. (oda kell figyelni arra hogy egy tranzakción akár 100 számla is lehet!)

[csandazoltan]

Egyébként még nem teljesen vágom ezt a bejövő számla lekérdezés témát. A QueryInvoiceDigest-nál InvoiceDigestType -ban látok fő adatokat. Akkor csak ha a számlatételekhez akarok hozzáférni, akkor kell nekem a queryInvoiceData?

Igen. A queryInvoiceDigest az egy "digest" kivonat vagy katalógus. Az az adott időszakra jelentett bejövő vagy kimenő számlákat tartalmazza queryInvoiceData-val kapod a részletes adatot, jelentés állapotában.

Az eredeti gondolathoz hozzászólva: A verziók az épp akkor kötelező adatot szolgáltatják, az adózó és az adóhivatal is eleget tett a kötelességnek. Átalakítani nem kell Ha szeretnél V1, V2 számlákat feldolgozni, akkor meg kell írnod a hozzá tartozó értelmezőt. Minden dokumentáció és xml definíció megtalálható a NAVnál

V1-es számlát újrajelenteni: V1 azt hiszem az 2018, ha ez eddig nem derült ki, akkor esetileg kell megkérdezned mi a teendő, Mivel a digitális rendszer már nem használt, ezért több mint valószínű papíron vagy egyéb digitális formában kell benyújtani a problémás számlát. Az adatoknak meg kell lenni nálad, asszem itt is az 5 év a mérvadó

[nbeeps2]

Na szuper, akkor ez már majdnem az, amit én akarok. :) Mert a QueryInvoiceDigest mindig az aktuális formában adja vissza az adatokat , tehát például a vevő neve invoiceDigest/customerName lesz, független attól, ha mondjuk az 1.0, 1.1, 2.0 alatt valamiért nem így hívták volna. Már csak a tételek hiányoznak ebből a lekérdezésből, ugyanezen logika mentén.

[EPluribusUnum]

Digest-be közel sem az összes számla fej adat szerepel. queryInvoiceData- kell mindenképp, még a fej adatokhoz is.

[csandazoltan]

Na szuper, akkor ez már majdnem az, amit én akarok. :) Mert a QueryInvoiceDigest mindig az aktuális formában adja vissza az adatokat , tehát például a vevő neve invoiceDigest/customerName lesz, független attól, ha mondjuk az 1.0, 1.1, 2.0 alatt valamiért nem így hívták volna. Már csak a tételek hiányoznak ebből a lekérdezésből, ugyanezen logika mentén.

Igen, a digest ebből a szempontból a lényeges adatokat visszaadja. ami kb két adószám és a számlaszám. De utána a data az már verziófüggő

[nbeeps2]

@csandazoltan: nekem ezekre van szükségem: kiállító neve és adószáma, kelt, teljesítés, fizetési határidő, fizetési mód, pénznem, árfolyam, nettó, áfa. Na ebből az árfolyam az egyetlen, amit a data-ból kell kinyerjek, illetve az összes tétel adat.

[csandazoltan]

@csandazoltan: nekem ezekre van szükségem: kiállító neve és adószáma, kelt, teljesítés, fizetési határidő, fizetési mód, pénznem, árfolyam, nettó, áfa. Na ebből az árfolyam az egyetlen, amit a data-ból kell kinyerjek, illetve az összes tétel adat.

Igen pont jól látod, ez van a digestben

Az árfolyamot ki tudod számolni, mert a digestben benne van az idegen pénznem és a magyarban az értéke

[renced42]

Kedves @nbeeps2 Végigolvasva a commenteket, jelenleg minden adatszolgáltatást úgy adunk vissza ahogy

V1-es számlát újrajelenteni: V1 azt hiszem az 2018, ha ez eddig nem derült ki, akkor esetileg kell megkérdezned mi a teendő, Mivel a digitális rendszer már nem használt, ezért több mint valószínű papíron vagy egyéb digitális formában kell benyújtani a problémás számlát.

Ha a2018-ban nem jelentette le a kötelezően lejelentett számlát és erre most jött rá vagy a NAV kötelezte és le akarja/kell jelenteni, akkor az éppen aktuális verzió szerint kell lejelentenie, vagy a papír alapút felklimpírozni a webes felületen.

[NTCA-supporter]

Sziasztok!

Ez már a 2.0-nál is ugyanígy volt, tehát az 1.1-es számla adattartalmát sem a 2.0-ás invoiceData XSD-nek megfelelően adtuk vissza. A számla teljes adattartalmán semmilyen konverziót nem végezhetünk. Sémák között jöhetnek be olyan új kötelező elemek, amiket honnan kellene nekünk megtippelni? A kivonatos lekérdezés teljesen más tészta, az is szintén a 2.0 óta jelen van. A felületen ha megjeleníted a különböző verziójú számlákat, csak hogy reagáljak a webes böngészésre, ott is különböző oldalakat fogsz látni, hiszen más az adattartalmuk.

Üdv

[omachtandras]

"Sémák között jöhetnek be olyan új kötelező elemek, amiket honnan kellene nekünk megtippelni?" Így van. Pont ez a probléma jött elő másik "oldalról". A számlázó szoftver sem tud megtippelni adatokat, ezért érzem én is rossznak a végpontok lekapcsolását. https://github.com/nav-gov-hu/Online-Invoice/issues/609

[csandazoltan]

"Sémák között jöhetnek be olyan új kötelező elemek, amiket honnan kellene nekünk megtippelni?" Nem tippelni kell, a datában benne van, hogy melyik verzió, a szerint a leírás szerint kell értelmezni.

[NyBela]

Kedves @nbeeps2 ! Ügyfeleink több ezer számlát könyveltek már ezzel a módszerrel ebben az évben. Teljesen jól működik. A bejövő számla adatrögzítése - könyvelése töredéke lett. Szinte teljesen automata. A teszt felületen próbáltam a 3.0-t, az is működik, és letölthető a 2.0 adattartalom. Annyit a régebbi verziók problémájához. Napi könyvelés folyik. Folyamatában töltik le az adatokat a felhasználók. Ellenőrző listát is készítettünk az aktuális havi NAV oldali bejövő és a könyvelt számlákról. Nem marad ki számla. Sőt inkább több van néha, mint amit a cégek elszámolnak, mert valaki cég névre vásárol és nem számoltatja el a számlát. De ez is kimutatásra kerül. Miért kellene több hónapra, több évre visszamenőleg adatot keresni a NAV szerveren? Még a kis cégek is legalább havi rögzítést végeznek. Az a cég aki nem könyvel egy hónapon belül, az amúgy is komolytalan, nem érdemes vele foglalkozni. Ő miatta igazán ne törd magad. Ezzel az eljárással az ügyfeleink nagyon meg vannak elégedve.

[nbeeps2]

@NyBela: ez egy technikai kérdés. Értem én, hogy amikor letöltöm a számlát, akkor utána detektáljam, hogy milyen requestversion-nal lett beküldve és aszerint elemezzem az XML-t, ez teljesen rendben van, ha nekem valamiért arra lenne szükségem, hogy lássam az eredeti beküldést, DE nekem nem erre van szükségem. Nem érdekes számomra, hogy az eredeti számla milyen verzióval került beküldésre, és pontosan hogy nézett ki az XML. Mindössze pár alap adatot szeretnék lekérni, pont úgy, ahogy a QueryInvoiceDigest-ben ki van találva. Megadsz egy tól-ig dátumot és máris löki a fontos adatokat, anélkül, hogy tudnom kéne, hogy milyen XML-ben volt az adatszolgáltatás és az akkor XML-ben milyen mezők léteztek.

Tehát, összefoglalva fejlesztési javaslatként szeretném kérni, hogy QueryInvoiceDigest legyen kibővítve a számla tétel adatokkal is. Hangsúlyozom nem az eredeti adatszolgáltatást akarom lekérdezni, csak egy listára (kimutatásra), amiben benne vannak a számlák és számlatételek.

[nbeeps2]

@renced42 "Ha a2018-ban nem jelentette le a kötelezően lejelentett számlát és erre most jött rá vagy a NAV kötelezte és le akarja/kell jelenteni, akkor az éppen aktuális verzió szerint kell lejelentenie"

Ez még jobban azt erősíti bennem, hogy nincs értelme a korábbi implementációknak a számlázó programban, legalábbis nálam nincs benne olyan funkció, ami miatt erre szüksége lenne rá.

[csandazoltan]

@nbeeps2 Értem is meg nem is! Értem, hogy kell és jó lenne, ha lehetne egy helyről kikérni az összes adatot, de ez nem így működik és nem is biztos, hogy úgy kelljen működni. Az adat be lett szolgáltatva, a nav befogadta és adott verziónak megfelelően értelmezi és kérésre az adatot visszadja.

Az adatot megkapjuk azt értelmezni a mi dolgunk, miért a nav dolgozzon helyettünk? A navnak a feladata addig van, hogy befogadja a számlákat.

Ha szeretnéd saját felbozdulásra "önellenőrzés"/"öntájékoztatás" céljából letölteni és megjeleníteni a bejövő számlákat, az igenis a fejlesztők dolga, nem a nav-é. Nem kötelessége az adatszolgáltatás és a tájékoztatás a bejövő számlákról Erre "fejlesztési javaslatot" adni szerintem nem fair.

Vagy be kell korlátozni a programod, hogy csak 3.0-val beküldött számlákkal működik 2020-01-04-től, vagy igenis meg kell csinálni mindhárom verzióhoz az XML térképet, megfeleltetve azokat a programod belső adatbázisával.

(Mi is csinálunk ilyet, töltjük a bejövő számlákat és megvan a 3 értelmező, mivel már 1.0 óta igazodunk az XML rendszerhez)

[nbeeps2]

@csandazoltan Értem is, meg nem is. Persze én is képes vagyok lefejleszteni azt, hogy értelmezzek 1.0, 1.1. 2.0, 3.0 változásokat, DE! Nem sokkal egyszerűbb lenne, ha ezt nem kéne? Különösen annak fényében, amit renced42 írt? Nem sokkal egyszerűbb lenne, ha a program mindig csak a legújabb XML szerint dolgozna? Nem kell a NAV-nak dolgoznia helyettem, és érdekes módon a QueryInvoiceDigest pont "az én elképzelésem" szerint működik, csak nem teljes, ennyi vele a gond, de a NAV-os fejlesztők is gondoltak rá eredetileg, hogy lehessen úgy listázni a rendszerből adatot (QueryInvoiceDigest), ami nem az eredeti adatszolgáltatás visszakódolásán alapszik! Ugyanúgy, amikor lekérdezel egy adószámot a queryTaxPayer funkcióval szintén nem kell vele foglalkozni, hogy korábban milyen adatokat adott vissza, ott is mindig meg van, hogy éppen most miket ad vissza és milyen mezőnevekkel, tehát amit én kérek az egy szimpla lekérdezés, ami QueryInvoiceDigest már most is létezik, csak nem tartalmazza a számlatételeket.

[nbeeps2]

@csandazoltan : és kérlek ne a jelennel foglalkozz, hanem tekints a jövőbe is, most még csak 4 XML sémát tartalmaz a rendszered, és 10 év múlva mennyit fog? Az én megoldásomnak pont az ésszerűség és az egyszerűség a lényege, kérlek ne legyél kocka.

[nbeeps2]

@NTCA-supporter : "A felületen ha megjeleníted a különböző verziójú számlákat, csak hogy reagáljak a webes böngészésre, ott is különböző oldalakat fogsz látni, hiszen más az adattartalmuk." Ezzel vitatkoznék. Tegyük fel, hogy van egy táblázatom az online számlázó programban, ami az alábbi oszlopokat tartalmazza: kiállító neve és adószáma, vevő neve és adószáma, kelt, teljesítés, fizetési határidő, fizetési mód, pénznem, árfolyam, nettó, áfa.

Nem fogok különböző "oldalakat" látni. Egy táblázatot látok, amikbe benne vannak ezek az adatok és mindegy, hogy milyen XML-ből küldték be őket, ahogy az is mindegy, hogy a vevő nevét tartalmazó mező customer, customerName, custName vagy bármi volt...

[renced42]

Kedves @nbeeps2 Értjük a kérésedet, de, ez a funkció nincs a rendszer szkópjában. Két ok miatt: egyrészt nincs rá se kisebb sem nagyobb üzleti igény, másrészt ez iszonyatos erőforrás igényt támasztana a rendszerrel szemben, ha egy ilyen funkciót kiajánlanánk. A webes felületen ugyan van ilyen export funkció, de korlátozott lehetőségekkel. Jelenleg a digest lekérdezést tudjuk ajánlani vagy a teljes számlaadat visszakérdezést.

[nbeeps2]

@renced42:

I. szerintem van rá üzleti igény, mert számla lekérdezéshez sokkal egyszerűbb lenne ezt használni. Jelenleg csak azért nem használja ezt senki, mert nincs ilyen lehetőség. Mindenki megoldotta a kerülő módszerrel. De kérdem én, melyik az egyszerűbb, ha például kíváncsi vagyok ezek az adatokra: kiállító neve és adószáma, vevő neve és adószáma, kelt, teljesítés, fizetési határidő, fizetési mód, pénznem, árfolyam, nettó, áfa. A)

• Lekérdezem, hogy a számlákat tól-ig dátum alapján
• Megállapítom, hogy milyen XML verzióval került be
• Megállapítom, hogy volt-e tömörítve
• Visszakódolom az XML-t
• Majd végül a megfelelő request verzió függvényében a megfelelő request strukrúval kinyerem a nekem szükséges adatot.

B)

• A QueryInvoiceDigest lekérdezem, hogy a számlákat tól-ig dátum alapján és megkapom ugyanezt az eredményt, minden macera nélkül.

Kétlem, hogy ha a kezdetektől fogva lett volna B opció, akkor mindenki az A megoldást választotta volna. Csak azért csinálták meg így, mert nem volt más lehetőségük, de mivel nagyon sokan használják ezt, nem írnám azt rá, hogy nincs rá üzleti igény.

II. "másrészt ez iszonyatos erőforrás igényt támasztana a rendszerrel szemben" Erre nyilván nincs rálátásom, viszont laikusként nem igazán értem, hogy miért is? Hiszen a QueryInvoiceDigest pont ezt csinálja, amit leírtam. Illetve mennyivel terheli jobban a rendszert az, hogy a QueryInvoiceDigest kérném le a tételeket, vagy a a QueryInvoiceData-val most. Ezt nem vágom hol a különbsége performancia szinten.

[renced42]

Illetve mennyivel terheli jobban a rendszert az, hogy a QueryInvoiceDigest kérném le a tételeket, vagy a a QueryInvoiceData-val most. Ezt nem vágom hol a különbsége performancia szinten.

A válasz egyszerű, ezt mutatja a visszaadott adattartalom.

Teljesen más egy rekordból elővenni az adatokat és visszaadni és más sok rekordot összevadászni, mondjuk olyan számláról aminek van 50.000 vagy mégtöbb tételsora.

[nbeeps2]

Ez a baj ezekkel a nagy rendszerekkel, hogy egy átlag felhasználói igénynél is elvéreznek és ezt úgy általánosságban írom, nem csak a NAV Online rendszerre. De nevetséges például, hogy egy banki felületen sem lehet lekérdezni az utalásokat 1 évre vonatkozóan, mint ahogy ez a NAV Online számla rendszerben is akadály a dátum szűrés függvényében. Szóval a performancia prioritása miatt a legegyszerűbb felhasználó igények sem teljesíthetők, mint pl. a bevitt adatok kényelmes(!) lekérdezése. Ez szomorú...

[renced42]

Kedves @nbeeps2

Nem az a baj, hogy az egyszerű igényeket kiszolgálja bármilyen rendszer. Hanem az, hogy ha az 1 tételsoros igényt ki kell vagy lehet szolgálni, akkor joggal ki kell szolgálni a 100e-s tételsor igényt is. Sajnos az ügyféli igények (lekérdezés tekintetében) végtelenek és sok esetben hogy is mondjam - nem ésszerűek. Így nem lehet végtelen erőforrás igényű hardvert és szoftvert pakolni végtelen igények alá. Ezért nem véletlen, hogy a bármilyen nagy forgalmú rendszerben, csak korlátozásokkal lehet lekérdezni az adatokat.

Ha nincs több kérdésed akkor kérlek zárd az Issue-t.

Köszönöm szépen!

[lvitya586]

Teljesen más egy rekordból elővenni az adatokat és visszaadni és más sok rekordot összevadászni, mondjuk olyan számláról aminek van 50.000 vagy mégtöbb tételsora.

Ezt nem értem. Miért kellene összevadászni, ez nincs meg az invoiceSummary-ben?

[renced42]

Kedves @lvitya586

Az invoice summary nem tartalmazza a számla tételeit. De nem is arra avló, mivel, hogy az egy összesítő ág :)

[lvitya586]

Nyilván azt nem tartalmazza, de legutóbb erről volt szó nbeeps2 részéről, ezekhez meg szerintem nem kell vadászni:

De kérdem én, melyik az egyszerűbb, ha például kíváncsi vagyok ezek az adatokra: kiállító neve és adószáma, vevő neve és adószáma, kelt, teljesítés, fizetési határidő, fizetési mód, pénznem, árfolyam, nettó, áfa.

Bár ha jól látom ezeket most is visszaadja a digest.

[nbeeps2]

@lvitya586 , ezeket az adatokat (kiállító neve és adószáma, vevő neve és adószáma, kelt, teljesítés, fizetési határidő, fizetési mód, pénznem, árfolyam, nettó, áfa) a QueryInvoiceDigest visszaadja, e kapcsán volt kérésem a tételek visszaadása is, hogy ne kelljen turkálni az XML-ben...

[nbeeps2]

@renced42 U.I: "Nem az a baj, hogy az egyszerű igényeket kiszolgálja bármilyen rendszer. Hanem az, hogy ha az 1 tételsoros igényt ki kell vagy lehet szolgálni, akkor joggal ki kell szolgálni a 100e-s tételsor igényt is." Ebben az esetben inkább a 100e tételsoros lekérdezéseket korlátoznám és nem azt, hogy a "normál" tételsoros számlákat ne lehessen lekérdezni. Szóval erre is lenne megoldás. Vagyis egy megadott mennyiségű tételsor felett a QueryInvoiceData-t kellene használni, míg egy megadott mennyiségű tételsorig képes lenne visszaadni a QueryInvoiceDigest is a tételeket. Performancia probléma megoldva.

[lvitya586]

e kapcsán volt kérésem a tételek visszaadása is, hogy ne kelljen turkálni az XML-ben...

Ne haragudj, ha nem olvastam végig mind a 40+ kommentet, de nekem ez nem jött le elsőre. Így már más a leányzó fekvése és akkor megkövetem @renced42 -t, mert ez a kérés már tényleg too much.

[nbeeps2]

@Ivitya586 Nem haragszom. Én nem látom too much-nak, egy teljesen mezei igény és leírtam, hogy miért sokkal jobb a queryInvoiceData-s bohóckodásnál.

[omachtandras]

@renced42 U.I: "Nem az a baj, hogy az egyszerű igényeket kiszolgálja bármilyen rendszer. Hanem az, hogy ha az 1 tételsoros igényt ki kell vagy lehet szolgálni, akkor joggal ki kell szolgálni a 100e-s tételsor igényt is." Ebben az esetben inkább a 100e tételsoros lekérdezéseket korlátoznám és nem azt, hogy a "normál" tételsoros számlákat ne lehessen lekérdezni. Szóval erre is lenne megoldás. Vagyis egy megadott mennyiségű tételsor felett a QueryInvoiceData-t kellene használni, míg egy megadott mennyiségű tételsorig képes lenne visszaadni a QueryInvoiceDigest is a tételeket. Performancia probléma megoldva.

Ha jól értem azt mondod, hogy fejlesszünk két megoldást, mert előre úgysem tudja senki, hogy mennyi tételsor lesz maximum a bejövő számlákon. Akkor meg mi értelme az egésznek? Inkább megcsináljuk azt, ami BIZTOSAN minden számlára működik.

[nbeeps2]

@omachtandras : nem, ha szigorúan az eredeti javaslatomat vesszük, akkor nem kellene 2 megoldás. Csak hát jött ez a performancia dolog és akapcsán reagáltam.