search

nav-gov-hu / Online-Invoice

Public repository of the Online Invoice System
Other
139 stars 52 forks source link

[FEATURE] modificationIndex meghatározása/lekérése #71

Closed skovacs70 closed 4 years ago

skovacs70 commented 5 years ago

Az igény összefoglalása / Summary of the request Az új modificationIndex miatt nagyon jó lenne (sokat segítene), ha le lehetne kérni adott számla módosítóinak darabszámát/következő módosító indexét, számlaszám alapján egyszerűen. Mert számlázó szoftver váltásnál ezt az adatot elég nehéz bemigrálni, főleg, hogy korábban nem kellett ezt nyilvántartani.

Az általam javasolt megoldás / The solution I propose Jó lenne erre valami lekérő operáció, esetleg valamelyik jelenlegibe plusz visszaadott adatként hozni. Pl. a queryInvoiceCheck-be ezt is visszaadhatnák.

hamvasgy commented 5 years ago

A fenti megoldást mi is nagyon hasznosnak tartanánk, és ez a felvetés a lineNumberReference meghatározásában is sokat segítene. Gyakori, hogy egy másik számlázó rendszerben kiállított számlát kell módosítani, s módosításkor körülményes megállapítani, hogy egy új tétel felvétele hányadik tétel az eredeti tétel folytatásaként. Az általam javasolt megoldás / The solution I propose A queryInvoiceCheck ez eredeti számlát lekérdezve megadhatná a következő lineNumberReference értékét.

NTCA-developer commented 5 years ago

Sziasztok!

A /queryInvoiceDigest listában ezt az információt visszaadja nektek, erre mi is gondoltunk, hogy kelleni fog. A kötelező kereső paraméterek között az alapszámla számlaszámára kell keresni, a válaszban pedig vissza fog jönni az erre a számlaszámra hivatkozó minden módosító és stornó számla modificationIndex értéke. Találtok az API sample XML-ek között példa kérést is erre az esetre.

Azt viszont hozzá kell tennem, hogy szerver oldalról valójában sosem fogjuk tudni mi a következő modificationIndex az adott időpillanatban. Mivel semmi nem tiltja, hogy ugyan azt az alapszámlát kézzel és géppel is módosítsák, a gépi számláról az adatszolgáltatás azonnal itt lesz nálunk, míg a kézi számlás adatszolgáltatás mindig később fog bejönni, a jelenlegi szabályozás szerint akár napokkal is később. Ezért ha azt látom, hogy van 1, 4, 6 modificationIndex az adott alapszámlára, ebből csak maximum következtethetek arra, hogy logikailag a 7-es fog következni, de ez csak egy vélelem marad mindig is a kézi számlák miatt. Ezt minden időpillanatban nézve mindig csak a kiállító fogja tudni, vagy kellene tudnia.

Van még kérdésetek ehhez a témához, vagy lezárhatom?

skovacs70 commented 5 years ago

Szia,

A /queryInvoiceDigest mint írtad, a láncban szereplő minden számla sok-sok adatát vissza adja (persze, benne van a modificationIndex is). De csak a modificationIndex max értékének kiolvasásához ez a nagy adatforgalom teljesen felesleges. Ezért is ajánlottam megoldásként pl a queryInvoiceCheck -et, ahol az invoiceCheckResult mellett pl egy maxModificationIndex (0..X) elemben ez visszaadható minimális adatforgalommal. Ennyiben módosulna az eredeti kérés, hogy elég lenne ez a max érték.

Abban igazad van, hogy ez egy vélelem, de ez a feladathoz tökéletesen elég lenne.

Az API sample XML-ek között melyik példára gondolsz, mert egyikben sem találtuk, amit keresünk.

NTCA-developer commented 5 years ago

Szia!

Erre a sample-re gondolok: https://github.com/nav-gov-hu/Online-Invoice/blob/master/sample/API%20sample/queryInvoiceDigest_inbound_invoice_chain.xml

A check ilyen irányú módosítását nem támogatjuk. Nem azért, mert ne csinálnánk meg szívesen ha ez segít másnak, hanem azért, mert a funkció hosszú távú fenntarthatóságának nem tesz jót. Most ugye van egy funkcionálisan tiszta operációnk az invoiceCheck esetében, ami érdemben csak egy boolean értéket ad vissza. Beletehetnénk a modificationIndex maximumát is, de milyen jó lenne pl arra is használni az operációt, hogy adja mondjuk a transactionId értékét is. (Így amikor timeoutol a beküldés, elég csak ezt meghívni és máris tudjuk, hogy bement-e a számla kérése van nem.) De ezzel igazából mit értünk el? Csak azt, hogy szétbarmoltunk egy tiszta operációt és a digest mellé csináltunk egy mini-digestet. Én ennek nem látom az értelmét, mivel a bővítendő adatok köre kb. örökké folytatható, mindig különböző okok miatt.

Persze abban igazad van, hogy csupán a kérdéses szempontból nézve a digest válaszának többi része nem szükséges, de még mindig karcsúbb így a fetchelt adatmennyiség, mintha egyesével a lánc teljes tartalmát le kellene kérdezned csak azért, hogy a modificationIndex maximuma meglegyen.

Szerintem a digest pont erre lett kitalálva, maradjunk ennél. Mit gondolsz?

hamvasgy commented 5 years ago

Sziasztok, Részemről elfogadom, hogy nem tiszta megoldás, ha ezek az adatok az invoiceCheck-be kerülnek. Igen, értjük, hogy a modificationIndex ilyen módon meghatározható, csak így minden adatszolgáltatónál meg kell valósítani a számlák végignézését. Egyszerűbb lenne, ha fejszintre ki lenne emelve a legutolsó érték és (akár a teljes számlalánc lekérése nélkül) egyszerűen megkapható lenne. A lineNumberReference aktuális értékének meghatározása még bonyolultabb, mert a legnagyobb modificationIndex értékű a számla adatait is le kell kérdezni queryInvoiceData operációval, és abból meghatározni a legnagyobb beküldött tétel értékét. Ez az adat is fejszinten elérhető kellene legyen.

hamvasgy commented 5 years ago

... a /queryInvoiceDigest operációban

NTCA-developer commented 5 years ago

A lineNumberReference-es kérésen hadd gondolkozzam kicsit. Önszámlázáshoz kérdezed, amikor csak a módosítót állítod ki te?

skovacs70 commented 5 years ago

Az invoiceCheck csak egy példa volt a megoldásra.

A gond a digest-el az, hogy ha paraméterezem, olyan halmazt is vissza tud adni, amiben nem biztos, hogy benne van a legnagyobb modificationIndex. Ez miatt nekem az adott számla teljes halmazát (láncát) le kell kérjem, hogy meghatározzam a max modificationIndex-et, ami idő mind lekérésben, mind feldolgozásban.

Már az is könnyítés lenne, ha mint @hamvasgy írta, ki lenne emelve ez az érték a fej szintre.

skovacs70 commented 5 years ago

A lineNumberReference is hasonló problémákat okoz, mert nem csak ösnszámlázásnál gond a meghatározás, hanem szoftverváltásnál is.

hamvasgy commented 5 years ago

Nálunk a számlázas egy része kiköltözött a német anyavállalat SAP rendszerébe, illetve további rendszerből is várható költözés. Ebből a SAP-ból történik a mi rendszereinkben kiállított számlák módosítása. A német oldalon nem akarják a standard SAP felületen lehetővé tenni ilyen adatok manuális bevitelét (más leányok is használják). A NAV-os beküldéshez lokalizációs fejlesztés készül, ezért lekérdezéssel tudnánk kezelni ezeket az eseteket. Másik halmaz, amikor egy jogelőd vállalat számláira bocsátunk ki módosító számlákat.

hamvasgy commented 5 years ago

(megvásárolt cégek beolvasztása után)

NTCA-developer commented 5 years ago

Másik halmaz, amikor egy jogelőd vállalat számláira bocsátunk ki módosító számlákat. (megvásárolt cégek beolvasztása után)

OFF: ilyenkor mindig olyan kellemes meleg érzés fog el, amikor egy cégvezetés fúzióra tud költeni, de adatmigrációra már nem. (és nagyon nem egyedüli az eset)

ON: megpróbálunk kitalálni valamit, csak egyeztetni kell hozzá, szóval lassú víz.

skovacs70 commented 5 years ago

ON: megpróbálunk kitalálni valamit, csak egyeztetni kell hozzá, szóval lassú víz.

Ugye, ebben mind a kettő (modificationIndex és lineNumberReference) benne van? :) Mindkét elem külön lekérdezhetősége könnyítené, és gyorsítaná is a munkát.

hamvasgy commented 5 years ago

Milyen megoldáson gondolkodtok? Elérhetőek lehetnek a (modificationIndex és lineNumberReference) abban az esetben, ha saját, de más rendszerből történt az eredeti számla kiállítása, illetve akkor is, ha jogelőd vállalat rendszerében? Elérhetőek lehetnek ezek az adatok akkor is, ha az eredeti számla nem lett beküldve, csak módosító volt már beküldve?

hamvasgy commented 5 years ago

(Minden esetben az eredeti számlára kiadva a /queryInvoiceDigest-et)

skovacs70 commented 4 years ago

Szia @NTCA-developer, Ebben az ügyben történt valami előrelépés? Van esetleg valami új információ?

NTCA-developer commented 4 years ago

Szia @skovacs70

Előrelépés még nem történt, mivel a december egy nehéz hónap az időpont egyeztetések szempontjából. De a mi részünkről támogatjuk az ötletet és van egy megoldási javaslatunk is. Egy felelősségi kérdést kell csak tisztázni, és utána indulhat is a fejlesztés a mi oldalunkról. Jelentkezem ha van update.

skovacs70 commented 4 years ago

Szia @NTCA-developer,

Köszönöm a választ. Várjuk az update-et.

NTCA-developer commented 4 years ago

Sziasztok!

Befogadjuk az igényt. A 2.0-ás API-ban létrehozunk egy új operációt. Az operáció kiállítói oldalról és vevői oldalról is igénybe vehető lesz. Az operáció üzleti bemenetként az alapszámla számlaszámát és opcionálisan a kiállító adószámát várja. A válaszban lapozható listában visszaadjuk:

Ezzel akár önszámlázóként is tudsz új módosító számlát kiállítani az nélkül, hogy felolvastad volna a teljes láncot felépítő számlák tartalmát.