Online-invoice: [FEATURE] A /queryTaxpayer válasza legyen kisbetűs

[veerede]

Az ügyfeleink kérik, hogy queryTaxpayer szolgáltatás ne nagybetűsen adja vissza az adózó adatait (név, cím). Illetve örömmel látjuk, hogy az új sémadefinícióban szerepel az adószám és csoportos adószám adóalanyiság és megyekód elemei. Ezek az információk meg is jelennek a 2.0-ás verzióban?

[NTCA-developer]

Szia @veerede !

A nem uppercases válaszról szóló kérésedet nem tudjuk teljesíteni, ez DB konvenció a tárolásnál. (és nagyon jó szolgálatot tesz nekünk és általánosságban minden nagy rendszernek is, ezért megváltoztatni sem akarjuk) Ha neked másmilyen válasz kell, akkor tegyél rá az XML-re response konvertert, onnantól szabad kezed van hogyan alakítod az adatokat. (Bár megjegyzem, hogy a bejövő számla adatoknál mi az interfész dokumentációban leírtak szerint ugyanúgy elvégezzük az uppercase konvenciót, szóval még ha kisbetűsre is alakítod a címadatot és úgy küldöd be, a számla adatainak lekérdezésekor már ismét nagybetűs lesz.)

A kérdésere vonatkozóan a felsorolt adatokból egyedül a megyekód az amit jelenleg mindig nullosként adunk vissza, a többit most is tudjuk szolgáltatni.

[veerede]

Szia!

Köszi a választ.

1. (UPPERCASE)
   Gondoltam, hogy valami technológia korlát miatt döntöttetek így. Én is döntöttem régebben Oracle adatbáziskezelő esetén így de később felül kellett bírálnom ezt.

Sajnos nincs algoritmusom arra, hogy 100 százalékosan átírjam az UPPERES nevet, címet a cégjegyzékben találhatóra.
pl.
_MKB_-Euroleasing Autólízing Szolgáltató Zártkörűen Működő Részvénytársaság.
_infoMátrix_ Informatika Fejlesztő _és_ Szolgáltató Zártkörűen Működő Részvénytársaság
A mozaikszavak és kötőszavakkal adódik probléma. A címek tekintetében is hasonló a helyzet.

1. Megyekód
   A megyekód értelmét én sem látom már (felőlem ki is vezethetné a NAV). Ám jelenleg mi az ügyfeleinktől azt kérjük, hogy az adószámot/csoportos adószámot teljes hosszában rögzítsék, mivel néhány NAV-os adatszolgáltatás is igényli ezt.
   pl. Partner felvitel/módosítás közben akartunk nekik adatrögzítésben segíteni megszerezni a csoportos adószámot a queryTaxpayer szolgáltatás használatával, ám jelenleg nem jön vissza annak megye kódja sem.

Köszi
Ede

[NTCA-developer]

Amikor lekérdezel egy adózót, akkor a vatGroupMembership tagban visszaadjuk hogy melyik ÁFA csoportnak a tagja. Ekkor kell a folyamatba egy ismételt lekérdezés az ÁFA csoport 8 hosszú törzsszámára is amit a vatGroupMembership tartalmazott.

Ekkor megkaphatod a vatGroupMembership ÁFA kódját, és amint elkészül a megyekód áttöltése is hozzánk, akkor onnantól kezdve automatikusan tudjuk adni a megyekódot is. A sémába azért tettük bele most, hogy később már ezért ne kelljen változtatni.

[veerede]

OK, köszi az infót

[nbeeps2]

"A nem uppercases válaszról szóló kérésedet nem tudjuk teljesíteni, ez DB konvenció a tárolásnál" Ne haragudjatok de ez tipikus KOCKA hozzáállás. Nem a fejlesztő érdekét kell nézni egy alkalmazás fejlesztésénél, hogy neki mi hogy jobb vagy kényelmesebb, hanem a FELHASZNÁLÓÉT. Felhasználói szempontból pedig

1. ocsmány, ha minden csupa nagybetűvel van
2. sokkal több helyet foglal a kiírás mind a felületen, mind a nyomtatásban
3. megmásítja az adatokat, mivel sok cég nevében szándékosan vannak kis- és nagybetük.

A jelenlegi queryTaypayer funkció használhatatlan emiatt! Ráadásul az egyéni vállalkozók lekérdezésére is teljesen alkalmatlan, mert nem adja vissza azt, hogy "e.v." vagy "egyéni vállalkozó", így képtelenség megállapítani, hogy egy adószámos magánszemélyről vagy egy egyéni vállalkozóról van szó!

[NTCA-developer]

Szia @nbeeps2

Nem haragszunk. Akkor fussunk neki még egyszer.

Az adatokat a NAV is így kapja az adatgazda állami szervektől. Bármennyire meglepő, az adózói adatok nem a NAV-nál, hanem a cégbíróságnál keletkeznek. Hozzánk csak terítik azokat. Ha @veerede -nek sincs 100% biztos algoritmusa a konverzióra, akkor jó lenne ha nem tőlünk várnátok ugyan ezt.

Nem látom be, hogy ez miatt miért tekintesz egy funkciót használhatatlannak. Adószámos magánszemélyt pedig tudomásom szerint nem ez az adatbázis tartalmaz, ezért a személynév mindig EV-t takar.

[nbeeps2]

"nagyon jó szolgálatot tesz nekünk és általánosságban minden nagy rendszernek is, ezért megváltoztatni sem akarjuk"
Ebből gondoltam, hogy ha azt írtad, hogy nem akarjátok megváltoztatni, akkor ez rajtatok múlik. Ha így kapjátok, akkor Ti nem tehettek róla, de ez mindenképpen egy hülye ötlet volt bárki is találta ki. Nem véletlen vannak kis- és nagybetűk, miért kell elrontani az adatokat egy uppercase képzéssel...

Oké, legyen így, hogy ebben az adatbázisban a személynév csak EV-t akar. Ezzel sajnos még nem vagyok előrébb. Honnan tudom, hogy személynevet ad vissza a rendszer? Az adatbázis tartalma botrányos, csak példaképp a Kft. ennyi féleképpen látható, ami eddig én láttam:
KFT.
KFT
KORLÁTOLT FELELŐSSÉGŰ TÁRSASÁG
KORLÁTOLT FELELŐSSÉGÜ TÁRSASÁG
KORLÁTOLT FELELÖSSÉGÜ TÁRSASÁG
KORL. FEL. TÁRS.
KORL.FEL.TÁRS.
A legszebb gyöngyszem pedig: "KORLÁTOLT FELELŐSSÉGŰ" csak így magában...
Ki tudja még hány variáció létezik, csak 400 db adószámra futtattam rá, de volt "BETÉTI TÁRSASÉG" is.
Vagyis a név feldolgozhatatlan, nem tudok vele mit kezdeni, hogy ha pl. nem találok benne "Bt."-t, "Kft."-t, egyéb cégformát, akkor egyéni vállalkozást írok ki a fentiek miatt. Hogy tudnék meggyőződni arról, hogy biztosan egyéni vállalkozót ad vissza a rendszer? Mert akkor a neve mögé oda tudnám írni, hogy "e.v.".

[Rossi73]

Hát ja... De akkor közelítsük meg a másik oldalról: Esetleg utónév (férfi/női) adatbázis? :-)

A http://www.nytud.hu/oszt/nyelvmuvelo/utonevek/ oldalon van txt-ben letölthető férfi és női lista...

[Rossi73]

Egyébként visszakérdeznék azért még egyszer erre az "akitől kapjuk, így adja át" részre: Ki adja át így? A cégbíróságon bejegyzett nevek kis-nagybetűket tartalmaznak, az e-cegjegyzek.hu-n is úgy jelennek meg. Ha a NAV a cégbíróságtól kapja, akkor érdemes lenne kideríteni, hogy hol történik az nagybetűsre alakítás. Ne adj' isten még az is előfordulhat(na), hogy aki így adja a NAV-nak, az tudná adni a nagybetűs mellett eredeti formában is, és a NAV ezt valamilyen csatornán fogadná, és ebből az adatbázisból adná vissza nekünk az adatot... Feltéve, ha a NAV ennek utánajárna, és hivatalból kezdeményezné...

[lvitya586]

Teljes mértékben egyetértek @nbeeps2 -el. Ezek az adatok sok esetben hibásak és teljesen mindegy, hogy honnan származnak. Azért ne mondja senki, hogy olyan sokféle cégforma létezik, hogy nem lehetne erre egy szótárat összerakni. Nem akarom elhinni, hogy a Cégbíróságon Gizike kézzel pötyögi be a cégformát. 2020-ban még létezik ilyen?

[NTCA-developer]

Az segítség, ha a cégeket és az egyéni vállalkozókat elválasztjuk egymástól egy minősítő jelöléssel?

[Rossi73]

Hogyan gondolod? Kapunk egy plusz mezőt, ami ezt jelzi? Egyébként teljesen mindegy, milyen formában kerülne be a "minősítő jelzés", mivel bármit fel tudunk dolgozni fogadó oldalon, amit ledokumentáltok. Ha külön mező, az is jó. Ha a név "@@EV@@" karakterekkel kezdődik, az is jó. Teljesen mindegy, ha szét tudjátok választani, és megjelölni, szerintem kaptok egy naaaaagy piros pontot mindenkitől. :-)

[NTCA-developer]

Még nem tudom, nem gondoltam végig, de első blikkre mindenképpen külön tagban, típusosan. Valami ilyesmire gondolok:
taxpayerType = ORG - akkor cég taxpayerType = ENT - akkor EV

Egy ilyen szétválasztás szerintem megtehető.

[lvitya586]

Ez jól hangzik, de második blikk az lehetne, hogy az adatszolgáltatóval szemben is keményen fellépnétek az adatminőség érdekében, nem csak a fejlesztőkkel szemben.

[NTCA-developer]

Ez jól hangzik, de második blikk az lehetne, hogy az adatszolgáltatóval szemben is keményen fellépnétek az adatminőség érdekében, nem csak a fejlesztőkkel szemben.

És mégis miben állna ez a fellépés, amit szerinted meg kellene tennünk?

[szecsenyizoltan]

Van olyan vevőm, aki csak annyit szeretne a számlára íratni: "Magyar Állam" se cím, se semmi. Náluk a parlament címét szoktuk felrakni a számlára. Ilyen típusú vevőknél, mi lenne a helyes eljárás?

[Rossi73]

"az adatszolgáltatóval szemben is keményen fellépnétek"
"Van olyan vevőm, aki csak annyit szeretne a számlára íratni"

Úgy érzem, kezdünk kicsit messze kerülni a vezérfonaltól... Inkább annak örüljünk, hogy van egy értelmes felvetés, ami, ha megvalósul, annak mindenki örülni fog! @NTCA-developer: Tökéletes megoldás a megkülönböztetésre a típusos megadás lehetősége, mert adott esetben tovább is bontható, ha bármikor szükséges lenne.

Az, hogy a NAV hogyan oldja ezt meg, kivel "lép fel" milyen keménységben, az legyen a NAV dolga. Elvégre, ha az egészről nem tudtunk volna, csak a NAV eleve megvalósítja mondjuk egy előzetes egyeztetést követően, akkor sem lenne a mi dolgunk ebben véleményt mondani.

Annak pedig, hogy a Magyar Állam "nevű" vevők esetében mit kell a számlára írni, nincs köze ahhoz, hogy az adószám lekérdezésekor megtudjuk, hogy az illető egyéni vállalkozó-e, vagy sem, ez Rajtad (sajnos) nem fog segíteni.

@NTCA-developer: Inkább azt írd meg légy szíves, hogy a július 1-jei határidőig látsz rá reális esélyt, hogy ezt bevezessétek? Gondolom van nyilvántartásotok arra, hogy melyik adóalany melyik kategóriába tartozik. Ha van, akkor ezt mennyi idő alatt tudjátok bevezetni a rendszerbe? Mert akkor július 1-ig erre fel tudnánk készülni, be tudnánk vezetni a rendszerekbe. Jó lenne. Köszönjük!

[lvitya586]

Úgy érzem, kezdünk kicsit messze kerülni a vezérfonaltól... Inkább annak örüljünk, hogy van egy értelmes felvetés, ami, ha megvalósul, annak mindenki örülni fog!

Én meg úgy érzem mindenféle személyeskedés nélkül, hogy Te valamiért egyfajta "moderátori" szerepet akarsz betölteni, de kérlek ne tedd. Hagyjuk meg egymásnak a jogot, hogy szabadon eldöntsük milyen problémát, ötletet, vágyálmot vetünk fel és minek örüljünk.

Nyilván örvendetes, ha fejlődik a rendszer, de az adatminőséget ne csak tőlünk várják el, mert így nem lesznek automatizált folyamatok, nem lesz szolgáltató állam.

@NTCA-developer remélem nem volt komoly a kérdés, hogy én mondjam meg mit kellene tennetek. Az állampolgárokkal szemben elég kreatív szokott lenni a NAV, gondolom azt is el tudja érni, hogy egy adatbázisban megfelelő adatok legyenek még akkor is, ha nem hozzá tartozik. A korábbi NAV vezér például azt is elintézte, hogy kövesden olcsóbb legyen a benzin. :)

[janisoft]

A NAV EBEV rendszerben az adófolyószámla nyilvántartásban a cégnevek helyesen jelennek meg. A NAV-hoz beküldött bevalllásokra kapott email üzenetekben (átvételi értesítő, stb.) is helyesen szerepel a cégnév (legalábbis amiket én kapok). Úgy gondolom a NAV folyószámla kezelő rendszerében szerepel valahol a helyes cégnév információ.

[NTCA-developer]

@lvitya586

Én viszont köszönöm @Rossi73-nak hogy leírta amit én is gondolok, szerintem te összekevered ezt a fórumot egy másik hellyel. A kérdésem csak arra irányult hogy eldöntsem, te naív vagy demagóg vagy-e. A választ köszönettel megkaptam, és ezzel ezt a témát itt és most zárjuk le.

@szecsenyizoltan

A vevőd azt ír a számlájára amit akar. Hogy az adószakmailag helyes-e, mi fejlesztőként nem tudjuk elbírálni.

@Rossi73

Ezen gondolkozom én is azóta. Sémát és doksit nyilván tudunk publikálni előbb is, de addigra még meg kell tudnom hogy release függésben vagyunk-e másokkal, ugyanis action szinten ezt a lekérdezést használja még a frontend (több helyen is), az Online Számlázó a számlakiállításkor és még a hamarosan megjelenő mobilappok is. Az elem kötelezősége sem világos még a válaszban ezen függőségek miatt. Visszajelzek!

@janisoft

Erre rá fogok kérdezni. Attól tartok hogy ott konverzió van, és akkor meg majd olvashatom egy következő ticketben hogy a NAV nem tud helyesen írni. (DÉL-DUNÁNTÚLI és hasonló problémák)

[nbeeps2]

@Rossi73: "Esetleg utónév (férfi/női) adatbázis", ez nem megoldás, mivel van mondjuk ilyen, hogy Tamás és Társa Korl. Fel. Társ.

@lvitya586 "Nem akarom elhinni, hogy a Cégbíróságon Gizike kézzel pötyögi be a cégformát. 2020-ban még létezik ilyen?": Pedig az elgépelésekből adódóan (amit fent be is idéztem) nagyon így néz ki!

@NTCA-developer "Az segítség, ha a cégeket és az egyéni vállalkozókat elválasztjuk egymástól egy minősítő jelöléssel?" Abszolút, igen. A lényeg, hogy tudjam, hogy egyéni vállalkozóról van szó, hogy a kinyert név után oda tudja minősíteni az "e.v." -t a neve mögé. A másik megoldás, ha NAV lekérdező funkciója már eleve így adja vissza a nevet, hogy ezt mögé rakja automatán, mert a háttérben tudja úgyis, hogy e.v. vagy nem e.v. és akkor még a sémához sem kell hozzányúlni.

[clapygeza]

A NAV-nak tudnia kell a vállalkozások statisztikai jelzőszámát ( a NAV törzsadatban benne van). Ebben a végéről visszafelé a második tag az un. GFO kód, ami a cégtipust adja meg pl. 113 Kft, 117 Bt, 231 EV, stb. Ez sztem nagyon megfelelne a célra.

[KMGY100]

@NTCA-developer : """A másik megoldás, ha NAV lekérdező funkciója már eleve így adja vissza a nevet, hogy ezt mögé rakja automatán, mert a háttérben tudja úgyis, hogy e.v. vagy nem e.v. és akkor még a sémához sem kell hozzányúlni."""
EZ A MEGOLDÁS !!!
Egyébként: egy adott vállalkozást nem név szerint azonosítjuk hanem adószám szerint,
akkor is ha helyesírási hiba kerül a névbe.

[Rossi73]

@nbeeps2, @KMGY100: """A másik megoldás, ha NAV lekérdező funkciója már eleve így adja vissza a nevet, hogy ezt mögé rakja automatán, mert a háttérben tudja úgyis, hogy e.v. vagy nem e.v. és akkor még a sémához sem kell hozzányúlni."""

Én inkább @NTCA-developer megoldását támogatnám, azaz ne a NAV szolgáltatására "bízzuk rá", hogy módosítsa a nevet bármilyen algoritmus alapján. A név szerintem legyen a név. Ha valaki e.v., azt majd mi odatesszük, ha akarjuk. Jelenleg sem kötelező ugyanis szerintem a vevő nevében feltüntetni ezt az adatot. Jobbnak érzem, ha kapok egy mezőt, ami egyértelműen megmondja, mit kezdjek a hozzá tartozó adattal. Ha akarod, ez alapján odateszed a név végére, hogy "e.v.", letárolod az adatbázisodban egy mezőben, hogy EgyeniVallalkozo=TRUE, stb.

Az igaz lenne a Te megoldásod szerint, hogy nem kell a sémához hozzányúlni, de a NAV-nak így is, úgy is hozzá kell nyúlni (a queryTaxPayer-ben kell egy IF ... THEN APPEND(Name, " e. v." vagy hasonló), Neked is mindenképp hozzá kell nyúlni (IF UPPER(SUBSTR(Name, LEN(Name)-4, 6)) = " E. V." vagy hasonló), én azt érezném jobb megoldásnak, hogy az adatot (nevet) ne alakítsa a NAV A-ról B-re, amit Te adott esetben visszaalakítasz B-ről A-ra. Inkább legyen egy plusz mező, amit mindenki úgy kezel, ahogy az ő rendszerének a legjobban megfelel.

[NTCA-developer]

Sziasztok!

Közben egy update. Én továbbra is a szép megoldás felé hajlok, ne csináljunk antipattern dolgot. Ha egy adat típusos akkor legyen meg a dedikált helye, főleg hogy az adatok megváltoztatás ellen az érintett szakmai területnek is lenne pár keresetlen szava. Szóval én az XSD módosítással (is) haladtam ma és szerencsére lazy validáció van a válaszokra, így nem vagyunk függésben más rendszereinkkel.

Úgyhogy hamarosan döntünk róla. Szerintem menni fog július 1 előtt, de még ne vegyétek készpénznek, nem csak tőlünk függ.

[KMGY100]

@NTCA-developer
""Szóval én az XSD módosítással (is) haladtam ,,,,Szerintem menni fog július 1 előtt,""

A 2.0 XSD változtatása csak úgy történhet, hogy a jelen pillanatban érvényes 2.0 XSD ugyanúgy működjön a változtatásotok után is.
Szerintem már több fejlesztő kiadta a 2.0 verziót és -gondolom- nem szeretnének hozzányúlni a következő évre tervezett 3.0 verzió bevezetéséig.
Vagyis: ha változik a 2.0 verzió akkor majd jövőre, a 3.0 verzióban legyen amit gondoltatok.

[NTCA-developer]

@KMGY100

Te használsz a programodban response validációt? Mert én feltételeztem hogy felvesszük az új taget a 2.0-ba opcionálisként és akkor mindenki boldog lesz. A 3.0-ban meg majd felkeményítjük kötelezőre, mert ezt az adatot egyébként mindig tudjuk adni. Ez nem lenne jó neked?

[KMGY100]

@NTCA-developer
"" Ez nem lenne jó neked?""
Nem az a mértékadó hogy nekem jó lenne vagy nem, hanem az hogy akik már kiadta
ák a 2.0 verziót a használóknak, azoknál semmi probléma ne merüljön fel a gondolt változtatás miatt.
( Szerintem hagyjátok jövőre a 3.0 bevezetéséig, addig még csiszoljátok a gondolatot)

[NTCA-developer]

Ezt ugyan így gondoljuk, de ha nincs eager validáció kliens oldalon a válaszra akkor egy optional tagnak ott nem szabadna hogy problémát okozzon. Igazából erre vártam volna megerősítést, mert így mindkét tábor nyerne.

Sőt, van aki még az értékhatár eltörlés miatt is releaselni fog, szóval ha mégis probléma a kiegészítés akkor ennek a lekezelése már nem nagy probléma.

[KMGY100]

Nem tudlak megerősíteni.
""Sőt, van aki még az értékhatár eltörlés miatt is releaselni fog, .""
Sőt (szerintem) sokan vannak akik már értékhatár nélkül beküldik. a számlákat, vagy beépítésre került a 2020.07.01 dátum, melytől kezdve küldi az áfamentes számlákat is.
Vagyis: nem kell hozzányúlni a 3.0 bevezetéséig.
Azt mondod: ""ha mégis probléma a kiegészítés akkor ennek a lekezelése már nem nagy probléma.""
Lehet hogy sokaknak nagy probléma.
Ezt mindenképpen kerüljük el.

Még annyit hozzáteszek: Gyanítom sokkal többen vannak akik az eredeti határidőig (04.01.) elkészültek úgy hogy biztosították az áfamentes beküldési kötelezettséget is.

[szako]

Én is a séma változtatás ellen vagyok, mert pl. SAP-ban nem olyan rugalmas az XML kezelés és egy ilyen jellegű változtatás (valószínűleg) hibás parsolást von maga után, ami miatt új verziót kellene kiadni. Ez számunkra nem lenne túl szerencsés.

Szerk: Nem vagyok a fejlődés ellen, csak az önös érdek beszél belőlem! :)

[pvmon]

Üdv! Én nem látom jól vagy a megígért rövid vállalkozás név átadása továbbra sem történik meg ebben a lekérdezésben?

[bakter80]

"A nem uppercases válaszról szóló kérésedet nem tudjuk teljesíteni, ez DB konvenció a tárolásnál. (és nagyon jó szolgálatot tesz nekünk és általánosságban minden nagy rendszernek is, ezért megváltoztatni sem akarjuk)"

Hát ez nemcsak, hogy kocka válasz, de még elég béna kocka válasz is.
Nem tudom milyen őskövület megoldásokat használtok, de nem hiszem hogy nem lehet egy upper(xyz) indexet rakni egy mezőre. Totál felesleges és gusztustalan eldeformálni az adatokat.
Ez a konvenció a 80-as évek óta nevetséges.
2020 van!

[NTCA-developer]

Szia @bakter80

Köszönjük az észrevételt. Jár neked a részinformációkból konstruktív hozzászólás gyártása díj.

[NTCA-developer]

Sziasztok!

Akkor kéréseteknek megfelelően az adózó típusának visszaadása beütemezve a 3.0-ba.