[FEATURE] INCORRECT_HEAD_DATA_SUPPLIER_BANKACCOUNT_MISSING INFO üzenet megszüntetése

[nbeeps2]

Helytelenül új INFO üzenet kerül bevezetésre:

INCORRECT_HEAD_DATA_SUPPLIER_BANKACCOUNT_MISSING Eladó bankszámlaszáma hiányzik.

Jelez, ha a Fizetés módja ki van töltve és értéke banki átutalás (paymentMethod=TRANSFER), de supplierBankAccountNumber nincs kitöltve.

Ez teljességgel felesleges üzenet, ami csak arra jó, hogy utána a felhasználó zaklassa a fejlesztőt, hogy miért írja neki ki a NAV, hogy az eladó bankszámlaszáma hiányzik, amikor ő azt a megjegyzés(!) mezőben szerepeltette!

A NAV fejlesztői nem vették figyelembe, hogy sok cégnek több bankszámla száma van, így nagyon sok esetben a bankszámlaszám nem egy konkrét bankszámlaszám mezőbe kerül feltüntetésre a számlán, hanem a számla alján a fizetendő összegnél látható megjegyzés mezőbe írják bele, például hogy: "Kérjük, a számla végösszegét a 11111111-22222222-33333333 számú bankszámlánkra legyen kedves elutalni"

A kérésem indoklásának másik oka, hogy a supplierBankAccountNumber kitöltése nem kötelező, így indokolatlan ennek kitöltésének ellenőrzése bármilyen szempontból is, akkor is, ha ez nem egy WARN, hanem egy INFO üzenet.

Másik jelzésem, hogy INFO üzenet esetén nem látszik az INFO azonosítója (10021), illetve az INFO kód sem (INCORRECT_HEAD_DATA_SUPPLIER_BANKACCOUNT_MISSING) a NAV válaszásban, csak ez: "Eladó bankszámlaszáma hiányzik". (más INFO üzenetek kapcsán néztem, hogy az INFO üzenetek ilyen szempontból hiányosak)

[omachtandras]

@nbeeps2 : én szeretném megvédeni ezt az info-t. Ahogy a gépi feldolgozások elszaporodnak a kiálllító oldalnak is érdeke, hogy a befogadó automatikusan fel tudja dolgozni, hogy milyen számlaszámra várja a pénzt. Egy szövegből kiszedni az ilyen infot sokkal erőforrás igényesebb (ha egyáltalán a szöveget átadja a szoftvere), mint egy dedikált mezőből kiszedni. Azt pedig az eladó érdeke is, hogy minél előbb és arra a számlára érkezzen meg a pénz, ahová várja, főleg, ha több számlája is van és neki fontos, hogy melyikre kérte.

[nbeeps2]

Pont ez a probléma, hogy én sem tudom kiszedni a szövegből, éppen emiatt nem szerepeltetem a NAV feladásban sem, meg nem is foglalkoztam vele, mert eleve se nem kötelező eleme a feladásnak, se nem kötelező tartalmi eleme a számlának. Viszont most az összes ügyfelünk, összes átutalásos számlájára fogja kapni ezt az INFO-t, aminek nagyon nem örülök!

[renced42]

@nbeeps2 ha valakinek több bankszámlaszáma van akkor azt hogy teszi a megjegyzésbe? Copy paste?

[omachtandras]

@nbeeps2 : értem. Két dolgot tudok elképzelni:

1. az ügyfeleid részéről ez alapján megjelenik egy igény, hogy most már nem szeretnék kézzel beírogatni ezt az infot a számlára, hanem törzsesítve szeretnék tárolni és választani számlázáskor, hogy melyik adat kerüljön a számlára. Ekkor már be tudod küldeni és mindenki boldog. Neked is lett belőle pénzed, jobb lett a programod, a használó meg örül, hogy nem kell pluszba dolgoznia, ráadásul pontosabban is jönnek a pénzek.
2. nem igénylik ezt az ügyfelek, cserébe kizárod ennek a típusú infonak a megjelenítését és mindeni megmarad abban a hitben, hogy de jó neki, hogy kézzel írogatja be mindig a bankszámla adatokat, és néha nem jó helyre kapja a pénzét. (egészen addig, amíg egy erős pozícióban lévő vevő meg nem követeli tőle, hogy adja nevesítetten a bankszámla számát az adatszolgáltatásban.)

[nbeeps2]

@nbeeps2 ha valakinek több bankszámlaszáma van akkor azt hogy teszi a megjegyzésbe? Copy paste?

Az is nem ritka, hogy simán csak feltünteti a számlán a kiállító résznél, pl:

Kiállító Kft. 1111 Budapest, Példa utca 1. Adószám: 11111111-1-11 Bankszámlaszám: 11111111-22222222-33333333 (OTP) Bankszámlaszám: 11112222-22222222-33333333 (K&H) Bankszámlaszám: 11113333-22222222-33333333 (Raif)

De lehet szimplán csak egy bankszámlaszám is, a lényeg, hogy nem feltétlen van dedikált(!) mezője a bankszámlaszámnak, mivel a bankszámlaszámot "ezer" helyen fel lehet tüntetni.... Éppen ezért nem is tudjuk megállapítani és nem is töltjük a bankszámlaszám mezőt egyáltalán.

[nbeeps2]

@nbeeps2 ha valakinek több bankszámlaszáma van akkor azt hogy teszi a megjegyzésbe? Copy paste?

Tudsz alkalmazni sablonokat és a sablonba bele tudod írni a bankszámlaszámot is. A számlán pedig az adott ügyletre vonatkozó sablont választod ki, ilyen egyszerű. Az ügyfelek nagyon sokrétűen használnak egy programot, tehát lássunk azon túl, hogy van egy bankszámlaszám mező. Nincs.

[nbeeps2]

1. Az ügyfelinknek nem kell semmit írogatni, szóval ez az igény ki van pipálva.
2. Nem írogatja be kézzel a bankszámla adatokat természetesen csak egyetlen egyszer.... (viszont nem a bankszámlaszám mezőbe, hanem mondjuk a számla kiállító adatai sablonba vagy a megjegyzés sablon, stb.).

Igen, a legvégső soron azt fogom csinálni, hogy OFF-olom ezt az INFO üzenetet, csak szerettem volna jelezni, hogy ez nem lett rendesen végig gondolva.

[omachtandras]

@nbeeps2 : akkor szerintem javasold nekik, hogy írják be a bankszámlaszám mezőbe és ne a sablonba és mindenki jól jár. Ez nem megoldás? Mondjuk amikor megjelenik az info, akkor mellé kiírod ajánlásnak, hogy ha ezt és ezt az adatrögzítési változtatást eszközöli, akkor nem fog megjelenni az info és még a partner felé is úgy szolgáltat adatot, hogy azt feldolgozva ő pontosabban fog tudni utalni.

[nbeeps2]

A számlán nincs bankszámla mező.... A számlának nincs ilyen információja, hogy bankszámlaszám, mivel a számlának nincs is ilyen kötelező tartalmi eleme. Pont ezért nem is kötelező tölteni a NAV adatszolgáltatásban. Egy számlán akkor sem kell feltüntetni a bankszámlaszámot, ha a fizetési mód netalán átutalás, ilyen mód végképp érdekes, hogy akkor hogy mi a fészkes fenének kell erre INFO üzenetet generálni. Igen, persze, bonyolíthatnám a végtelenségi a programot és átírhatnánk olyan részt benne, ami már tizen éve így működik, de miért is? Az ügyfeleknek tökéletes a jelenlegi megoldás és ez nekik kényelmes. A programban meg van oldva a több bankszámlaszám kezelés, meg van oldva az is, hogy automatán felajánlja a banki adatokat egy kiválasztott számlatömbhöz, egy devizanemhez, illetve a felhasználó azt is meg tudja oldani, hogy az adott ügylethez tartozó számlázási sablont kiválassza, amiben szintén ott a bankszámlaszám. Minden igényt tehát le van fedve, mindezt úgy, hogy a programban egy deka bankszámlaszám mező nincs... Érdekes ugye? Nálunk százmilliószor fontosabb, hogy az ügyfélnek kényelmes és egyszerű legyen a program használata és százmilliomod rangú, hogy arra törekedjünk, hogy 100%-os legyen a NAV feladásunk (nem kötelező mezők kitöltése) és eleget tegyünk az ilyen buta elvárásoknak.

[renced42]

Kedves @nbeeps2, hát nem tudom... Ez tipikusan törzsadat, ami a cégre vonatkozik. Én biztos adnék egy fix mezőt neki, mert hát meg van a helye tulajdonképpen.

[nbeeps2]

Kedves @nbeeps2, hát nem tudom... Ez tipikusan törzsadat, ami a cégre vonatkozik. Én biztos adnék egy fix mezőt neki, mert hát meg van a helye tulajdonképpen.

és hány bankszámlamezőt vezetnél be? A számlán felfüntetett 3 bankszámla esetén melyiket töltsem a NAV mezőbe?

[nbeeps2]

Kedves @nbeeps2, hát nem tudom... Ez tipikusan törzsadat, ami a cégre vonatkozik. Én biztos adnék egy fix mezőt neki, mert hát meg van a helye tulajdonképpen.

Senkit nem érdekel a bankszámlaszám. Az csak a vevőnek érdekes, hogy hova utaljon, de tudom fokozni. A saját cégünknek is 3 bankszámlája van. Csak 1 van feltüntetve a számlán, de napi 5-szor még se arra utalnak, hanem a másik számlánkra

[omachtandras]

De lehet szimplán csak egy bankszámlaszám is, a lényeg, hogy nem feltétlen van dedikált(!) mezője a bankszámlaszámnak, mivel a bankszámlaszámot "ezer" helyen fel lehet tüntetni.... Éppen ezért nem is tudjuk megállapítani és nem is töltjük a bankszámlaszám mezőt egyáltalán.

Mi azt csináljuk, hogy a törzsben több bankszámla száma lehet mind nekünk, mind a partnereknek. A számlázás során meg kiválasztja a felhasználó, hogy az ügylet során melyik az, amit használni / megjeleníteni szeretne. Vannak persze olyan logikák, hogy ha a partnernek egy bankszámla számlát ismerem, nekem meg több van, akkor a program automatikusan ki próbálja találni, hogy melyik bankszámlám az, amelyik a partnerével azonos bankban van, így érdemes azt bekínálni neki, hogy csökkentsük a bankköltségét és szeressen minket :) (Meg ettől el lehet térni millió módon, mert mondjuk szerződésben rögzítettem, hogy milyen számlára fizet ő mindig, akkor az a prioritás, vagy nekem fontos, hogy hova érkezzen a pénz, mert onnan kell utalnom az elkövetkező időben majd a szállító számlákat, esetleg a számla devizaneme húzza magával a bankszámlát, stb. stb. Szóval sok változós a dolog, de ha ügyletenként tudom, hogy hová szeretném kapni a pénzt, akkor ez a mező nagyon logikus. Ha pedig sok számlám van, akkor annak oka van, tehát jó lenne "irányítani" a befolyó pénzeket, hogy ne nekem legyen utána költségem a pénzek mozgatása miatt...)

[omachtandras]

Kedves @nbeeps2, hát nem tudom... Ez tipikusan törzsadat, ami a cégre vonatkozik. Én biztos adnék egy fix mezőt neki, mert hát meg van a helye tulajdonképpen.

Senkit nem érdekel a bankszámlaszám. Az csak a vevőnek érdekes, hogy hova utaljon, de tudom fokozni. A saját cégünknek is 3 bankszámlája van. Csak 1 van feltüntetve a számlán, de napi 5-szor még se arra utalnak, hanem a másik számlánkra

Hát, pont ezért lenne jó, ha átadnád, mert akkor nem a céginfoból meg mindenhonnan próbálná osszekaparni a túloldal az adatot, néha hibásan. (Esetleg, ha törzsben van neki egy korábbi számlaszám ,akkor azt most tudná bővíteni, hogy nini, most már tudom, hogy van neki egy másik és ennek a számlának az összegét pont arra várja...)

[nbeeps2]

Azért tüntetsz fel a számlán egyszerre több bankszámlaszámot (a bank nevével), hogy az adott ügyfélnek a bankon belüli utalás miatt olcsóbb legyen. Ha OTP-s, akkor az OTP-s számlára utal, ha másik, akkor a másikra. Szóval egy számlán elméletileg korlátlan számú bankszámlaszám szerepelhet!

[nbeeps2]

Hát, pont ezért lenne jó, ha átadnád, mert akkor nem a céginfoból meg mindenhonnan próbálná osszekaparni a túloldal az adatot, néha hibásan. (Esetleg, ha törzsben van neki egy korábbi számlaszám ,akkor azt most tudná bővíteni, hogy nini, most már tudom, hogy van neki egy másik és ennek a számlának az összegét pont arra várja...)

Sajnos azt feltételezed, hogy mindenki drága integrált rendszer használ befogadói oldalon, de ez igen ritka. Az átlag vevő (legyen céges vagy magán) megkapja a számlát, majd belép egy internetes bank felületbe és a számlán látható bankszámlaszámra elutalja az összeget. Tökre lényegtelen neki tehát, hogy a NAV feladásban van-e bankszámlaszám vagy sem. ez egyedül csak az integrált szoftvertgyártókat érdekli a "végfelhasználót" a legkevésbé sem.

[nbeeps2]

@omachtandras A megoldást már megírtad. Fixen figyelem ezt az INFO választ a NAV-tól és elnyelem. Viszont e kapcsán meg ez volt a jelzésem, amire még nem jött reakció:

"Másik jelzésem, hogy INFO üzenet esetén nem látszik az INFO azonosítója (10021), illetve az INFO kód sem (INCORRECT_HEAD_DATA_SUPPLIER_BANKACCOUNT_MISSING) a NAV válaszásban, csak ez: "Eladó bankszámlaszáma hiányzik". (más INFO üzenetek kapcsán néztem, hogy az INFO üzenetek ilyen szempontból hiányosak)"

Most kénytelen vagyok ezt vizsgálni: "Eladó bankszámlaszáma hiányzik", de jobban szeretném inkább ezt keresni: INCORRECT_HEAD_DATA_SUPPLIER_BANKACCOUNT_MISSING

[omachtandras]

@nbeeps2 : nem tudhatjuk merre megy a világ. Lehet, hogy 2-3 év múlva már úgy bankolsz, hogy a NAVtól jövő számla adatokból választasz, hogy most utalni akarsz, és nem is pötyögsz, még akkor sem, ha nincs ERP-d, de érkezik a kiállító számlaszáma... Abban viszont szerintem nincs igazad, hogy ez az adat senkit nem érdekel. Szerintem már most is sokan örülnének neki, ha mindig érkezne és ez a jövőben csak még inkább efelé fog változni. És az ügyfél az ügyfél, ha neki fontos, akkor nekem is, mint eladónak fontos lehet, hogy kiszolgáljam.

A nem jön azonosítóra én nem tudok megoldást adni, remélem azt megnézik @NTCA-supporterék és javítják, ha valóban fennáll a hiba.

[Macskafarka]

@nbeeps2 írta: "Senkit nem érdekel a bankszámlaszám. Az csak a vevőnek érdekes, hogy hova utaljon," - Valóban nem kötelező része a számlának a bankszámlaszám, azonban azt is emeljük ki, hogy nem kötelező része a számlának a fizetési mód sem. Csak azt jelenti, hogy a számlakibocsátó mit gondol, a vevő meg azzal egyenlíti ki, amivel akarja. Kompenzál, beszámít, bankból utal, engedményez, Western Union-nal küld pénzt, esetleg kp-val fizet. A NAV üzenete szerintem azt akarja sugallni, hogyha valaki kitölti az egyébként nem kötelező fizetésmód mezőt "átutalás"-sal, akkor adjon meg legalább egy létező bankszámlaszámát, hogy lehessen utalni. Ez szerintem nem zárja ki azt, hogy megjegyzésben sokkal több bankszámlaszám legyen feltüntetve, és abból a vevő válasszon. Amúgy pedig tényleg érdemes lehet törzsesíteni a saját bankszámlaszámokat, ezzel a vevőket terelni arra, hogy melyik bankszámlára várjuk a kiegyenlítést. Nem mindenki örül annak, ha az EUR-ban vezetett bankszámlára érkezik Ft összeg, vagy fordítva.

[nbeeps2]

Lehet, hogy 2-3 év múlva már úgy bankolsz, hogy a NAVtól jövő számla adatokból választasz, hogy most utalni akarsz, és nem is pötyögsz

Ezt azért nem tartom valószínűnek, mivel utalni nem csak számlákat kell, hanem sok minden mást is. Így az SOHA nem fog megszűnni, hogy én belépek a banki felületre és nem tudok akárkinek úgy utalni, hogy tetszőlegesen beírom a bankszámlaszámát. Ha pedig rendszeres partnerem, akkor meg most is el tudom menteni a direktbankban, hogy mi az ügyfélhez tartozó bankszámlaszám.

[nbeeps2]

Amúgy pedig tényleg érdemes lehet törzsesíteni a saját bankszámlaszámokat, ezzel a vevőket terelni arra, hogy melyik bankszámlára várjuk a kiegyenlítést.

Törzsesítve van, sőt, ha EUR-ban számlázol, automatán az EUR-hoz tartozó bankszámlaszámot jeleníti meg és még hosszan sorolhatnám, viszont mindez úgy van megoldva, hogy nincs bankszámlaszám mező. Erre varrjatok gombot :) Azért az senkinek ne legyen meglepő, hogy nem a NAV-nak fejlesztettük a programot, mivel jóval előbb készült, mint maga az adatszolgáltatás és ha nem muszáj (már pedig INFO üzenet esetén nem muszáj), akkor nem fogjuk elbonyolítani a program működésért, ami jelenleg maximálisan kiszolgálja az összes ügyféligényt.

[nbeeps2]

A NAV üzenete szerintem azt akarja sugallni, hogyha valaki kitölti az egyébként nem kötelező fizetésmód mezőt "átutalás"-sal, akkor adjon meg legalább egy létező bankszámlaszámát, hogy lehessen utalni.

A NAV látásmódjával csak az a gond, hogy mindig mindenre azt feltételezik, hogy mindenre van külön dedikált mező, pl. egy újonnan forgalomba helyezett járműnél, hogy motorszám (engineNum), alvázszám (serialNum) vagy repült órák száma (operationHours) és még hosszan sorolhatnám. Hát nincs. Végtelen számú dolgot lehet számlázni egy programban és nincs végtelen számú mező. Viszont van egy megjegyzés mezőt, amit teljesen szabadon lehet használni és például tökéletesen alkalmas bankszámlaszám feltüntetésére is. A felhasználó felvisz több megjegyzés sablont a "Köszönjük a vásárlást"-tól kezdve bármire használható, amiben benne lehet az is , hogy "Kérjük, a számla végösszegét a 11111111-22222222-33333333 számú bankszámlánkra legyen kedves elutalni". Én ebből nem fogom "kikupászni" a bankszámlaszámot, csak azért, hogy kitöltsek egy amúgy nem kötelező mezőt...

[Macskafarka]

Próbáld meg a fizetésmód mezőt nem feladni és nem tölteni, nem lesz hibaüzenet a bankszámlaszámra. Abban teljesen igazad van, hogy a NAV olyan mezőket is kér, amely nem része a számlának. Gondolok itt az áfa összesítő blokkra, vagy a belföldi devizaszámlán mezőnkénti Ft összeg szerepeltetése stb. Súlyos probléma, hogy törvény helyett egy adatszolgáltatás mezőleírása az elvárás. De ezt nem itt, és nem mi tudjuk megoldani. Az alapoknál kellene kezdeni, pl, törvényben kimondani, hogy ami nincs, vagy nem kötelező, azt nem lehet megkövetelni az adatszolgáltatásban sem. Hiányzik a visszacsatolás a számlaadat-szolgáltatás tapasztalatairól a jogalkotó felé. És ott lenne a helye a társadalmi vitának. Most a NAV magára van hagyva a jogalkotó nem kíváncsi a tapasztalatokra, és mi pedig a másik oldalon focizunk.

[omachtandras]

Lehet, hogy 2-3 év múlva már úgy bankolsz, hogy a NAVtól jövő számla adatokból választasz, hogy most utalni akarsz, és nem is pötyögsz

Ezt azért nem tartom valószínűnek, mivel utalni nem csak számlákat kell, hanem sok minden mást is. Így az SOHA nem fog megszűnni, hogy én belépek a banki felületre és nem tudok akárkinek úgy utalni, hogy tetszőlegesen beírom a bankszámlaszámát. Ha pedig rendszeres partnerem, akkor meg most is el tudom menteni a direktbankban, hogy mi az ügyfélhez tartozó bankszámlaszám.

És, ha valaki nem szeret gépelni? Ő vélhetően, ha nem muszáj ,akkor nem is akar. Persze, van olyan eset, hogy kell, akkor meg megteszi. Ok, hogy lementem partnerként a bankszámlaszámot, de az összeget, számlaszámot a hivatkozásba csak be kell írni, és nyilván van olyan, aki ezt sem szeretné. Csak ránézni, hogy jót kínált-e be a bank/erp, és utalni, aztán foglalkozni fontosabb dolgokkal, mint a felesleges adatbevitel.

Vajon miért van már QR kódos csekkbefizető funkció a bankoknál? Ott is csak annyit tud a rendszer, hogy nem kell begépelni a partner számlaszámát (amit el lehet menteni egyébként ugye, de azzal is foglalkozni kellene...), az összeget, meg a hivatkozást/számlaszámot. Aztán mégis használják az emberek, pedig mindezt meg tudnák adni egy kis időráfordítással egy normál utalásnál is...

[nbeeps2]

@omachtandras Ok, értem, de te most egy elképzelt jövőről beszélsz. A valóság jelenleg nem ez. Én magam sem úgy utalom a bejövő számlákat, hogy a hozzánk beérkezett számlák NAV adatszolgáltatásában azt nézem, hogy mi az eladó bankszámlaszáma. Arra a számlaszámra utalok, amit vizulálisan látok a számlán, ilyen egyszerű. Ja és nem gépelek, egy a PDF-ből egy Copy-Paste megoldom...

[omachtandras]

@nbeeps2 : hát, nem tudok arról beszélni, ami már megvan, mert az nem indukál változást a NAV adatszolgáltatásban sem. Én az mellett érvelek, hogy miért lehet hasznos az, ha megadja az eladó azt a bankszámla számot az adatszolgáltatásban, amire a pénzt várja. Nyilván, ha ezt már mindenki megtenné, akkor nem lenne értelme ennek az info bevezetésének.

Amikor elkezdődött ez az egész adatszolgáltatási dolog, akkor azt mondtuk, hogy ok-ok, de ennek az egésznek csak akkor van értelme, ha nem csak egy olyan kötelezettség jön a nyakunkba, amiből a NAV meg az állam profitál, a gazdasági élet szereplői meg csak szívnak vele és semmi hasznuk nincs belőle.

A NAV - számomra teljesen pozitívan - beleállt abba, hogy megpróbálja az adatszolgáltatást olyan irányba terelni, hogy azok a vállalkozások, akik fel akarják azt használni az ügyviteli folyamataikban minél hatékonyabban meg tudják azt tenni. Ez az, aminek haszna van, amit érdemes támogatni és (ki)használni. Lehet, hogy ez ma még senkit nem érdekel, de én azt látom, hogy ez már ma sem így van, a kicsit közt is sokan rájöttek már, hogy mennyi energiát és adatrögzítési hibát lehet megspórolni, ha minőségi adatot kapnak (és adnak).

Nem akarlak meggyőzni, ha úgy gondolod vedd ki akár azt is az adatszolgáltatásodból, hogy utalás a számla fizetési módja.

Azt viszont remélem, hogy az ügyfeleid oldaláról idővel jön majd a nyomás, hogy minél több ilyen hasznos adat kerüljön átadásra, mert akkor az azt jelenti, hogy nekik olyan partnereik vannak, akik már nem akarnak kézi adatrögzítéssel foglalkozni, hanem annál sokkal értelmesebb és hasznosabb dolgokra fordítják az erőforrásaikat.

[nbeeps2]

"Nem akarlak meggyőzni, ha úgy gondolod vedd ki akár azt is az adatszolgáltatásodból, hogy utalás a számla fizetési módja."

A fizetési módot fel fogom adni, mert az egyértelmű és van dedikált mezője. A bankszámlaszámot nem tudom(!) feladni, mert nem ismerem. Egy szöveges mezőből kéne kiszednem, de annak sem a helye, sem a formátuma, sem a nyelve nem fix.

Én nem azt mondtam, hogy a supplierBankAccountNumber ne legyen benne az XML-be. Legyen. Csak ne kössünk már be hozzá se INFO-t, mert aztán még a végén WARN-lesz és most már azt is megértük, hogy bizonyos WARN-okból meg ERROR. Ez ennek az evolúciója. Kompletten az összes INFO-t nem akarom kikötni a programból, mert a többivel nincs bajom (úgy sem érint), viszont ez most kiverte a biztosítékot, mivel a mi ügyfelünk összes olyan számláját érinti, aki átutalásos számlát állít ki és az ügyfeleink éves szinten összesen jelenleg évi másfél millió számlát bocsájtanak ki. El lehet képzelni, hogy ez mekkora telefonforgalmat bonyolítana az ügyfélszolgálaton, hogy mindenki hívogatna, hogy miért kapja a NAV-tól azt az üzenetet, hogy hiányzik az eladó bankszámlaszáma, ami itt és ott konkrétan fel van tüntetve a számlán. Ez a hátunk közepére sem hiányzik. Én kikötöm ezt a INFO üzenetet a programból, a posztom lényege az lett volna, hogy tudassam a NAV-os fejlesztőkkel, hogy ez a dolog nem lett átgondolva, nem vették figyelembe az összes variációt és nincs mögötte 30 évnyi tapasztalat, hanem pusztán egy rendszer szintű gondolkodáson alapszik (mindig mindennek van dedikált mezője) és nem a gyakorlatban használt dolgokon.

[renced42]

Kedves @nbeeps2 tulajdonképpen mindenki úgy csinálja ahogy akarja. Ha az én számlázó programot fejlesztenék, akkor az ügyfélnek lehetőséget biztosítanék, hogy megmondja akar ilyen üzenetet látni vagy sem :)

Másrészt a nem kötelező mezők tekintetében nem értek veled egyet. Ezek a mezők nem azért nem kötelezők mert nincs értelmük, hanem azért mert nem lehet őket megkövetelni, azért mert különböző ágazati vagy EU szabályozások szerint a számla nem kötelező eleme. De nem véletlenül vannak benne az adatszolgáltatás sémában. Pont egy gépjárműves példát írtál. Hát itt egész véletlenül, ha ezeket az infókat nem tudod konkrétan az ÁFA bevallásodat nem tudod kitölteni vagyis a számlán vagy annak mellékletében szerepeltetni szükséges ezeket az információkat, hiába nem kötelező része a számlának. A VTSZ sem kötelező, de ha vas acélt vásárolsz fordított adózásban akkor is ráteszik a számlára mert az is szükséges a könyveléshez és még sorolhatnám. De a bankszámla szám is lényeges lehet bármilyen szempontból.

A digitalizáció útján vagyunk, mindent elektronikusan fogunk intézni és ez csak fokozódni fog. Néhány éven belül el fogunk oda jutni, hogy nem kell PDF-ből copy pastézni, A most számodra haszontalannak tűnő dolgok egyre inkább hasznosak lesznek, főleg, ha nem lesznek PDF-ek amiből copy pastézni lehet :)

A korábbi hozzászólókkal egyetértve ezek a fejlesztések az ügyfelek érdekét is szolgálják, hogy minél hasznosabban és jól tudják az adatszolgáltatásokat üzletileg felhasználni és hasznosítani.

Köszi az észrevételt meg fogjuk nézni, ha esetleg teszten tudod reprodukálni és adsz egy TR ID-t azt meg köszönnénk.

• köszi, hogy jelezted, hogy egy ügyfélnek több számlaszáma is lehet ezt megvizsgáljuk, majd a következő XSD verzió szempontjából.

[renced42]

Másik jelzésem, hogy INFO üzenet esetén nem látszik az INFO azonosítója (10021), illetve az INFO kód sem (INCORRECT_HEAD_DATA_SUPPLIER_BANKACCOUNT_MISSING) a NAV válaszásban, csak ez: "Eladó bankszámlaszáma hiányzik". (más INFO üzenetek kapcsán néztem, hogy az INFO üzenetek ilyen szempontból hiányosak)

Kedves @nbeeps2

Közben megnéztük a működést.

A válaszban az INFO azonosítója nincs és nem is lesz benne. Ez a doksiban egy azonosító szám. A NAV válaszában a validationErrorCode tag-ban szerepel az "INCORRECT_HEAD_DATA_SUPPLIER_BANKACCOUNT_MISSING" a message tagban pedig az "Eladó bankszámlaszáma hiányzik"

Kérlek vizsgáld meg a kódod, hogy a validationErrorCode tag-et kiolvasod e a response-ból.

Ez alapján én úgy látom nincs teendő a mi oldalunkon.

[nbeeps2]

@renced42 A bankszámlás INFO üzenetet még nem tudom tesztelni, mert nincs élesítve nálatok, de más INFO üzenettel kipróbáltam és csak ez jön vissza (nem vágom be a teljes XML-t):

1 DONE INFO Számla kelte több, mint 10 nappal korábbi, mint az adatszolgáltatás dátuma. InvoiceData/invoiceIssueDate2022-01-13 false Tehát csak a message látszik, nincs validationErrorCode , mivel ez egy INFO üzenet, nem ERROR és nem WARN.

[nbeeps2]

@renced42 A számlán lévő adattartalom kapcsán (rendszám, alvázszámszám, repült órák száma, stb) meg félreértettél. Ezek az adatokat a felhasználó adott esetben szerepelteti a számlán, viszont az ilyen speciális mezőknek egy hagyományos számlázó programban NINCS dedikált mezője, mivel ezeket az információkat mindig is a tételes vagy számla megjegyzésbe tüntette fel valaki, ha ilyet számlázott. Mivel ezek annyira speciális esetek, hogy 10 000 ügyfélből jó esetben is max csak 1-et érint, egy épp eszű számlázó program fejlesztő nem bonyolítja el a programját ilyen adatokkal, hogy 1 embernek kedvezzen és a másik 9999 felhasználó életét keserítse, bonyolítsa. Nálunk pont ilyen a bankszámlaszám is. Utalási információ van, amibe beleírhat bármit, ami jól esik és úgy ahogy jól esik: bank neve, iban vagy sima bankszámlaszáma, swiftkód, több bankszámlaszám, bármi és ez az információ meg fog jelenni a számlán. Fel lehet vinni több ilyen sémát is és ő tudja kiválasztani, hogy melyik utalási információ jelenjen meg a számlán. Önmagában a bankszámlaszám tehát nem információ és ahogy említettem valaki nem is akarja, hogy ez a szállító adatainál fel legyen tüntetve és simán csak a fizetendő végösszegnél megjelenő sablonba írják be egyszer(!), a köszönjük a vásárlást szöveg mellé/elé/helyett, hogy XY bankszámlaszámra utaljanak. Ez a GYAKORLAT. Ez már azelőtt is így volt, hogy a NAV-nak lett volna számlázó programja. Ne azt vegyük tehát készpénznek, hogy ami a NAV számlázó programban működik az a szentírás...

Nincs bajom az XML-ben, hogy van bankszámlaszám. Aki tudja ezt, töltse és váljon egészségére, de NE kössünk be már hozzá figyelmeztető szöveget...

"Ha az én számlázó programot fejlesztenék, akkor az ügyfélnek lehetőséget biztosítanék, hogy megmondja akar ilyen üzenetet látni vagy sem" Sajnos ebből a válaszból az látszik, hogy soha nem volt ügyfélszolgálatos tapasztalatod. Ez tipikus fejlesztői hozzáállás. Az ügyfelek nem így működnek, nagyon nem. Kapaszkodj meg, de egy átlag user azt sem tudja, hogy az egérnek van jobb egér gombja, nem tudja mi az, hogy mappa, nem tudja, hogy kell egy mellékletet lementeni egy e-mailből és hosszan sorolhatnám. Végképp nem tudnád neki megmagyarázni, hogy mi az az INFO üzenet, miben tér el a WARN-tól és egyáltalán miért kap olyan üzenetet, hogy hiányzik az eladó bankszámlaszáma, amikor ő a saját szemével látja, hogy rajta van a számlán...

[sinick2]

Tisztelt Fejlesztők!

Nálam is jellemző, hogy egy számlán több eladó bankszámlaszám szerepel. Az eddigi legtöbb 4 darab bankszámlaszám szerepeltetése volt. Nem jelentős, az arány kb. 500-ból 1. Talán leglogikusabb(?) eset az, hogy belföldi ügyletet devizában számláznak és vevő vagy devizában vagy forintban fizet, amit a számlakibocsátó nem tud előre. A többi eset inkább banki költségek "vélt" optimalizálása miatt van.

[NTCA-supporter]

@nbeeps2 igazad van, ami teszt környezeten van, még nem adjuk vissza a validationErrorCode-ot INFO esetén. A 3.17 verzióban, ahol az új INFO üzenetek lesznek implementálva, már ezt is adni fogjuk a könnyebb feldolgozás érdekében. pl.: `

INFO INCORRECT_HEAD_DATA_SUPPLIER_BANKACCOUNT_MISSING Supplier's bank account number is missing. InvoiceData/invoiceMain/invoice/invoiceHead/invoiceDetail/paymentMethod TRANSFER ` Üdv

[sinick2]

@renced42: "[...] A VTSZ sem kötelező, de ha vas acélt vásárolsz fordított adózásban akkor is ráteszik a számlára mert az is szükséges a könyveléshez és még sorolhatnám. [...]"

Sajnos vas- és acélipari illetve mezőgazdasági bevallás elkészítéséhez a séma alkalmatlan, mert 1) nincs dedikált mezője a súlyadatoknak (pl. 2 darab hegesztett háló 2x15 kilogramm), 2) nincs jelölés a hibrid vetőmagra.

(Aki ezt jelenleg jelenti, az tétel megjegyzés adaton keresztül teheti, de ahány cég annyiféle megoldás lehet. Ha már van főkönyvi számlaszámra ajánlott dedikált mező, akkor a súlyra és hibrid vetőmagra is lehetne ajánlott dedikált mező.)

[nbeeps2]

@sinick2 Másrészről meg ugyanez lesz, hogy hiába lesz is erre mező az XML-ben, az illető mondjuk őstermelű használja a legalapabb ingyenes számlázót, amiben nincs kimondottan erre a célra a programban súly kezelés és simán csak fel fogja tüntetni a megjegyzésben az adatokat, a számlázó meg szépen nem tölti ki a NAV adatszolgálatás erre szolgáló mezőit, mert nem ember és nem tudja értelmezni mit lát a megjegyzésben és eljutottunk oda, hogy soha nem fog működni az a fajta automatizálás, amiről egyesek álmodnak.

Tökéletes példa erre a környezetvédelmi termékdíj kezelés. Csak a drága programok tudják, csak a drága programokban van erre dedikált mező. Az olcsóbb programokban ezt a megjegyzésbe töltik és vége is a történetnek...

[renced42]

Sajnos vas- és acélipari illetve mezőgazdasági bevallás elkészítéséhez a séma alkalmatlan, mert 1) nincs dedikált mezője a súlyadatoknak (pl. 2 darab hegesztett háló 2x15 kilogramm), 2) nincs jelölés a hibrid vetőmagra.

Kedves @sinick2 igen ezt már érzékeltük. Sajnos a tételben az van, hogy 6 méter 12-es körcél de az Áfa bevallásban kg-ot kell megadni. A hibrid vetőmag esetében pedig nem kell ebben az esetben a kg-ról nyilatkozni. De meg fogjuk találni a helyét :)

[zonehun]

Sziasztok,

Mi is mostanában vettük ezt észre. Több problémám is van vele:

1. Semmiféle előzetes tájékoztatást nem kaptunk arról, hogy egyszer csak egy nem kötelező mezőre a NAV elkezd üzeneteket dobálni. (tudom, INFO, megteheti, de azért mégis...)
2. Az issue indítójával teljesen egyetértek: az ügyfelek körében ez azonnali ijedelem. Jaj, valami nem jó. Mert ugye a NAV-nak mindenben meg akarnak felelni.
3. Nálunk az ügyfelek 80% több számlaszámot is feltüntet (sőt van aki az összes létező számlaszámát feltünteti) a számlájában. Pl. van OTP, KH és Raffis HUF számlája is. Neki teljesen mindegy melyikre érkezik pénz, csak jöjjön :) A partnereinek azonban nem mindegy, hogy házon belüli utalás vagy teljes Giro körös! Ugye az árazásban eltér.
4. Törzsadat, nem törzsadat, hitvita, stb. Mindegy. Mindenkinek van már egy működő rendszere. Arra kapta - a nyakába újabb púpként - a NAV Online Számlázó szabványt. Nálunk és szerintem sokaknál már egy évek óta működő rendszer volt - nem csak VEVŐI számlákra. Így aztán az nem várható el, hogy a gyártó fogja magát és mondjuk önköltségén az utólagos, NAV kvázi szabvány (mert ugye nincs törvényben) alapján teljesen újra gondolja a rendszerét az alapjaitól. Ami legyünk őszinték eléggé mission critical az ügyfeleink szemében. Tehát csak úgy nem változtatgathatjuk meg, mint ahogyan a sziklaszilárd Alaptörvényünket, előzetes kérdés és szavazás nélkül. Mi legalábbis konzultálunk a felhasználóinkkal, hogy milyen változásnak örülnének és minek nem. És szerencsére az eddig NAV Számlázó előírásoknak meg tudtunk felelni. Valamikor 2010-ben mégicsak jól terveztük a rendszert, de azért mindig bennünk van a félelem, hogy egyszer csak egy olyan változás jön, ami miatt komoly, alapokat kell mozgatni, amit nem szeretnénk.

Ugyanakkor van megoldás!

Mivel INFO típusú az üzenet, így azt nem jelenítjük meg és kész. Az ügyfél pénzügyese meg nyugodtan dolgozhat.

Én az előzetes tájékoztatást hiányolom. Nem hiszem, hogy a NAV oldaláról hatalmas erőlködés lenne a fejlesztőknek egy szerencsételen emailt küldeni - ha már minden egyes kérés fejlécében bekérik, hogy ki állította össze az XML-t és így tovább....

Röhej, hogy ezt a github issue oldalt kell időről időre nézegetni, ha időben akarok tájékozódni. Akár arról is, hogy történ valami, ami mégsem úgy és másként értendő, stb. stb.

[EPluribusUnum]

@renced42 , @NTCA-tax kérném hogy nevezzék át a kódot és az üzenetet.

NEM hiba hogy nincs banszámlaszám , így a kód és az üzenet se utaljon erre. Nem hiányozhat olyan ami nem kötelező, és nem is lehet helytelen. Már előre látom hogy ebből megint mekkora support forgalom lesz... :(

INCORRECT_HEAD_DATA_SUPPLIER_BANKACCOUNT_MISSING -> HEAD_DATA_SUPPLIER_BANKACCOUNT_NOT_PROVIDED "Eladó bankszámlaszáma hiányzik." -> "Eladó bankszámlaszáma nem lett megadva".

Köszönöm.

[TNMarton]

Tisztelt Illetékes,

Arra vonatkozóan van esetleg információ, hogy mikorra megy a módosítás élesbe?

Köszönöm.

[marcipunk]

Ebből a szűkszavú hírből az éles https://onlineszamla.nav.gov.hu/home oldalon arra következtetek, hogy 08.08 este: "Online Számla rendszer karbantartása 2022.08.08. 18:00-20:00 2022-08-04 14:45 Karbantartás miatt az Online Számla rendszert a NAV 2022. augusztus 8-án 18 órától 20 óráig leállítja. Kérjük, elektronikus ügyintézésekor vegye figyelembe a karbantartási időszakot! A karbantartás végeztével frissítést teszünk közzé.

A fenti időpontot követően lépnek életbe a https://onlineszamla.nav.gov.hu/dokumentaciok linken elérhető, az Online Számla rendszer módosított interfészspecifikációjában található változások.

Megértését és türelmét köszönjük!"

@NTCA-supporter : de cáfolj meg, ha tévedek

[NTCA-supporter]

Sziasztok! A mai napon élesedik a 3.17-es verzió, ami tartalmazza ezt az info üzenetet, jelenlegi formájában. A felvetést természetesen már továbbítottuk az illetékeseknek, visszajelzésre várunk. Amint van változás, jelezni fogjuk, és ha szükséges, adunk rá javítóverziót. Üdv

[RvPSc]

Üdv, Ezzel az új "INFO" type-pal kapcsolatban található valahol, valami féle ajánlás? Megfelelő, ha én ezeket olyan szinten elnyelem, hogy sikeresnek jelölöm az adatszolgáltatást, de kiírom, hogy a NAV üzenettel látta el? (és megtekinthető az üzenet) Mind a bankszámlaszám beküldés, mind a UNINTENDED_MODIFICATION_DELIVERY_DATE iszonyatosan sok megkeresést generált 2 nap alatt. Ez így tarthatatlan.

[NTCA-supporter]

Sziasztok!

Átmenetileg inaktiváltuk ezt az INFO üzenetet, teszt rendszeren már tesztelhető. Amíg nem tisztázódik a végleges működés addig kikapcsolva marad, várhatóan jövő héten élesítjük a teszt rendszeren lévő verziót. Üdv

[NTCA-supporter]

Sziasztok!

Élesen is kint van az inaktiválás.

Üdv