Online-invoice: számlaszám végén szóközök??? [Q&A]

[macokkk]

3.0 tesztben (valszeg élesben is) az a jelenség, hogy ha a beküldött számla tagjében a számlaszám végén valahány szóköz is megy a küldéskor, akkor ez így tárolódik, és a digestresponseban is szóközökkel jön vissza, és szóköz nélkül lekérve a queryinvoicedatarequest nem ad választ. A probléma kiállított és kapott számlákra is igaz.
Tehát ha csak a számlaszámot (és szállítónál az adószámot) ismerem, nem tudom lekérni a számla xml-t? Ez hatalmas bugnak?/problémának/csapdának néz ki, ami talán csak azért nem jött elő eddig, mert értelmesebb programozók a számlaszámot kezdő és záró szóközök nélkül küldik.
Az elég rosszul hangzik, hogy ha nem kapok egy számlaszámra választ, akkor addig biggyesszek a végére szóközöket és kérjem le újra, amíg a mező hossza tart...
Ezt szerintem javítani kéne.

[renced42]

Ez hatalmas bugnak?/problémának/csapdának néz ki, ami talán csak azért nem jött elő eddig, mert értelmesebb programozók a számlaszámot kezdő és záró szóközök nélkül küldik.
Az elég rosszul hangzik, hogy ha nem kapok egy számlaszámra választ, akkor addig biggyesszek a végére szóközöket és kérjem le újra, amíg a mező hossza tart...
Ezt szerintem javítani kéne.

Igen mindenképpen, a beküldő oldalán
Ezzel együtt megnézzük azt is, hogy NAV oldalon mit lehet tenni.

[macokkk]

Köszönöm. Bejövő oldalnál ugye semmilyen befolyásunk nincs a küldésre...
Ami még rendkívül fontos lenne, hogy most akkor NAV oldalon mikor azonos két számlaszám?
Különbözik a '21-001' és a '21-001 ' egymástól? Mert ha igen, az a problémák végtelen tárházát nyitja meg...

[renced42]

Kedves @macokkk

Minden bizonnyal különbözik.

[macokkk]

Valóban. Ugyanannak a kimenő számlaszámnak (akár különböző adatokkal történő) jelentését is simán DONE-al befogadja, ha az egyik számlaszám végén van egy szóköz. Azért ez szerintem nem ok. Ügyvitelben egy adat ugyanaz az adat a záró szóközöktől függetlenül. (Utána webes felületen Technikai érvénytelenítést indítottam az elsőként beküldött szóköz nélküli számlán állva, és a másikat, a később küldött szóközös jelentését törölte. Ez se tűnik szupernek)
Ezek szerint kaphatok, letölthetek a NAV rendszerből egy szállítótól két ugyanolyan számlaszámú beérkezett számlát (a végükön különböző számú szóközzel), de az M lapon ezt pl. nem is jelenthetem.
Ezt valahogy tényleg meg kéne oldani!

[Macskafarka]

@macokk Teljesen igazad van! Még lelkes vagy, de itt már elhangzottak korábban olyanok, hogy ez a fórum nem a xx65M lapról szól, azt tessék máshol intézni. Meg az is, hogy még az ÁFA tv. sem nagyon számít. Szóval én drukkolok, hogy a kérdésedben szereplők megoldódjanak.
Amúgy az xx656M lapra a NAV-nak nincs szüksége, mert a számlakibocsátó adatot szolgáltat. Az is sokat elárul, hogy 2021.07.01-től ÁFA bevallás tervezetet fognak készíteni, tehát világos, hogy fölösleges az M lap, a nélkül is menni fog.
Az xx65M lapot úgy kell felfogni, mint pusztán egy szívatást: Mennyire tudod kitalálni azt, hogy ni van a NAV adatbázisában. Milyen dátummal, milyen számlaszámmal, milyen összeggel. Nehezítésképpen a számlázó programokkal készített számláknak csak egy részét mutatja meg, és teszi lekérdezhetővé a NAV Online felülete. Mert akárhogy is nézzük, a pénztárgéppel készült számlák a törvény szerint "számlázó programmal" készítettnek minősülnek, mégis engedélyt kaptak a NAV-tól arra, hogy megszegjék a számla NAV Online adatszolgáltatási kötelezettséget. Legalábbis nem hallani arról, hogy intézkednének a törvény betartatására a számla adatszolgáltatási kötelezettség telesíttetésére.

[topybear]

Amit a számlakibocsátó szolgáltat, az kevés, abból ugyanis nem derül ki, hogy melyik számla kerül be a könyvelésbe, illetve mennyit helyez levonásba a befogadó.

[csandazoltan]

Most mondanám azt, hogy itt mindenkinek igaza van. A szóköz az egy érvényes string karakter, nincs kitiltva. Ez igen félreértésekre adhat okot emberi szemmel.
De "gépi" szemmel pedig teljesen érvényes

A számlázó programban kell lekezelin ezt, ha engedve van a kézi adatbevitel, akkor vagy trimmelni kell, vagy szólni a felhasználónak, hogy "biztos biztos?"

[nbeeps2]

@csandazoltan : Szerintem ez nem a dolog, ami miatt szólunk a felhasználónak, ez tök alap, hogy trimmelni illik. Valamelyik fejlesztő ezt elmulasztotta, így ment be ilyen számla a NAV-hoz, emiatt elég nagy gond, ha ez úgy működik, ahogy @macokkk leírta. Itt szerintem a fogadó oldal (NAV) is hibázott, mert én minden adatbevitelnél és importálásnál mindent trimmelek, szerintem ez is tök alap.

[csaszko]

A fenti NAV logikát követve ('21-001' és a '21-001 ' "Minden bizonnyal különbözik.")
értelmezzük már ezt a problémát papír alapon, tehát akkor az állítás szerint ez két különböző számlaszám... Sok sikert a papíron megállapítani a szóközöket!!
Amellett, hogy ezt igen csak le kellene kezelni kliens oldalon, ezt a navnak is legalább egy warn-al kellene jutalmaznia, de inkább aborttal.
Ez így rossz mindenkinek, a NAV az egyetlen aki érdemben tehetne is valamit, hogy ne így legyen, de már számtalanszor belefutottam, hogy egyszerűen nem érdekli őket - ha hibás vagy értelmetlen adat kerül be hozzájuk-, vagy mindenféle jogszabály hivatkozási indokkal vitába szállnak. Amikor nekik jó akkor persze nem számít, hogy megköveteli-e a kérdéses infót bármilyen törvény...

[topybear]

Vékony jég... Ha a törvényalkotó nem rendezte ezt a kérdést, akkor azért felmerül, hogy a NAV-nak van-e bármilyen jogosítványa megkötéseket tenni a számlaszám formátumát illetően. Mondjuk vszeg nem lenne nagy iparági tiltakozás, ha az eleji/végi szóközöket a formátumban tiltaná.

[csaszko]

Vékony jég... Ha a törvényalkotó nem rendezte ezt a kérdést, akkor azért felmerül, hogy a NAV-nak van-e bármilyen jogosítványa megkötéseket tenni a számlaszám formátumát illetően. Mondjuk vszeg nem lenne nagy iparági tiltakozás, ha az eleji/végi szóközöket a formátumban tiltaná.

Ha csak azt nézed, hogy db=PIECE-t is minden további nélkül lenyomták, szerintem nem sokban különbözik a téma.

[omachtandras]

Véleményem szerint egy warningot megérne. Segítené a fejlesztőket és az ügyfeleket is. Mind számla adatszolgáltatás, mind számla befogadás oldalán.

[macokkk]

WARN nem old meg semmit.

[macokkk]

Ami megoldás lenne, ha a NAV a beküldött invoiceNumber tagből mostantól egyszerűen lenyelné a kezdő és záró szóközöket (a számlaszámban belül lehet szóköz!). Amikor meg esetleg eredeti számlaszámra hivatkozik, aki ilyet tett, akkor meg nem. Így nem kell nyúlni a már bent levő adathoz, de a gond mégis megoldódik.

[topybear]

Az szerintem biztos, hogy informatikai oldalról teljes az egyetértés, hogy jó lenne tiltani az eleji-végi szóközöket. A NAV-os kollégáktól kellene vélemény, hogy egy ilyen megszorításra van-e jogosítványuk.

[topybear]

Ami megoldás lenne, ha a NAV a beküldött invoiceNumber tagből mostantól egyszerűen lenyelné a kezdő és záró szóközöket (a számlaszámban belül lehet szóköz!). Amikor meg esetleg eredeti számlaszámra hivatkozik, aki ilyet tett, akkor meg nem. Így nem kell nyúlni a már bent levő adathoz, de a gond mégis megoldódik.

Ezzel csak az a baj, hogy akkor már belenyúlnának a szolgáltatott adatokba (eszámla esetén eleve kizárt), amit nem fognak megtenni, érthető okokból. Beengedni nem lenne szabad, és akkor nincs ilyen probléma, ami meg eddig bement így, az már sajnos így marad. :(

[NTCA-supporter]

Sziasztok!

Hétfőn egyeztetünk nagyobb körben a témáról, addig türelmeteket kérem.
Mindenképp foglalkozunk vele, mert volt már több ilyen github issue is, ami ebből a problémából fakadt.
Beküldött adatokon konverziót biztosan nem fogunk végezni :)

Jelezni fogok, ha van további info.

Üdv

[NTCA-supporter]

Sziasztok!
A INVALID_INVOICE_NUMBER validátor lesz erre bevezetve, az ionteréfsz dokumentáció már tartalmazza.
Majd a 3.5 verzióban lesz tesztelhető.
Üdv

[NTCA-supporter]

Sziasztok!
Itt minden meg lett beszélve, a héten kerül ki a 3.5 verzió teszt és éles rendszerre, ami tartalmazza az új validációt.
Üdv