Online-invoice: [FEATURE] lineNatureIndicator elvetése

[vankcuf]

Az igény összefoglalása:
lineNatureIndicator kötelező kitöltése nem jó, vagy opcionálissá kell tenni vagy ki kell vezetni az XSD-ből

Rövid és tömör leírása a problémának, amiből az igény származik:
lineNatureIndicator az XSD szerint 4 értéket vehet fel. Ez az információ jelenleg nem elérhető egyik számlázó programban sem. A meglévő számlázó programok már rendelkeznek cikktörzsekkel, így esetleges szoftverfrissítésnél gondoskodni kellene az új "oszlop" értékének kitöltéséről, azonban ez nem megoldható, mivel a program nem képes automatikusan eldönteni egy adott tételről, hogy a 4 közül melyik érték vonatkozik rá. Ráadásul előfordulhat olyan helyzet is, amikor az adott tételre egyik esetben az egyik besorolás, másik esetben a másik besorolás vonatkozik. Ebből adódóan a felhasználónak egy 50 tételes számlán is egyesével kell elbírálnia azt, hogy mi az adott számlatétel besorolása. Ez így elfogadhatatlan! További probléma még, hogy a 4 besorolás között nagyon vékony a határ és a felhasználó szinte egészen biztosan téves besorolást fog alkalmazni, aminek a következménye az lesz, hogy felhasználhatatlan arra a célra ez az információ, amire tervezték.

Az általam javasolt megoldás:
lineNatureIndicator megszüntetése, kivezetése az XSD-ből

Elfogadható alternatívák:
lineNatureIndicator opcionálissá tétele az XSD-ben

Egyéb tartalom:
A jövőben semmi olyan kötelező tartalom ne kerüljön bele az XSD-be, ami nem képezi a számla kötelező tartalmi elemét és vizuálisan nem látszik a számlán!

[pelach]

Csatlakozom a fentiekhez.
Főleg akkor probléma ha a felhasználónál csak egy gyűjtő van.
A számla elkészítése pedig úgy működik, hogy a fejléc kitöltése után a gyűtjőből jönnek a tétel adatok amit pároztat a törzsbe lévő adatokkal (tétel értéke, kedvezmény)
Ilyenkor lezáráskor minden tételre kérdezzen rá?
Ez nonszensz!
Egyből elhajt a kedves felhasználó ami nekem meg keresetkiesés.
Másképp ugye meg nem lehet megoldani. (Vagy még mindent mindig beküldök default értékkel)
Ez esetbe meg okafogyottá válik a mező, mert ugyse lehet belőle statisztikát kinyerni.

Elfogadható alternatíva:
lineNatureIndicator kivezetése.

[WittmannWien]

Èn is csatlakozom az elöttem felszólalókhoz. Nehezen automatizálható folyamat, nincs éles határvonal a kategóriák között.
A legjobb megoldás szerintem is az elem kivezetése lenne.
Köszönöm.

[darmalost]

Szintén csatlakozom. Csak egy adószakértő könyvelő tudja helyesen megadni a 4 besorolást között , hogy adott esetben mikor melyiket kell alkalmazni. A számla kiállítója ehhez nem ért.

Technikailag probléma még a helyesbítés is. Hogy tud lehelyesbíteni egy ilyen számlát, ahol elrontja a besorolást? A számlán minden rendben lesz, csak a háttérben nem, viszont a vevő csak azt látja, amit a számlán lát. Nem érti majd, hogy kap egy olyan helyesbítőt, amin semmi nem változik.

lineNatureIndicator kivezetése egyértelműen!!!!

[btibiri]

Maximálisan egyetértek!

"A jövőben semmi olyan kötelező tartalom ne kerüljön bele az XSD-be, ami nem képezi a számla kötelező tartalmi elemét és vizuálisan nem látszik a számlán!"

A lineNatureIndicator is ilyen... durva hiba lenne a NAV részéről, ha erre hagyatkozva akarna bármilyen ÁFA analitikát automatán megcsinálni!!!

[saintarpy]

Csatlakozom a többiekhez, a lényeget már mindenki elmondta. Ez a lineNatureIndicator nem lett jól végiggondolva! Termék vagy szolgáltatás, ez a két érték mindenki számára emészthető. Ha ez nem elég, akkor nincs értelme a lineNatureIndicator mezőnek.

[csaszko]

Csatlakozom én is a többiekhez annyi kiegészítéssel:

Legyen megfelelően kitalálva, leegyeztetve az ágazatokkal majd ennek megfelelően módosítva, egyértelműsítve minden jogszabály ami a számla kötelező tételeit írja elő és ahhoz igazodjon a NAV, ne pedig ad-hoc jellegű megbeszéléseken eldöntött dolgokhoz igazodjon az egész ország. Nem gondolom, hogy ilyen módon tovább kellene erőltetni a 3.0 4.0 stb... verziókat.
Valamint javaslom, hogy jól átgondolt xsd-k kerüljenek a jövőben kiadásra és ne a programozói közösségtől várja a NAV a megoldásokat.
Az általam javasolt megoldást:
Törvény, jogszabály egyeztetésekkel való módosítása, utána a fejlesztések folytatása.

Elfogadható alternatíva:
További számlán nem található egyéb információk bekérésének leállítása, csak a jelenlegi jogszabályok szerinti számla kötelező adatainak bekérése.

[czbhu]

csatlakozom.
Illetve kiemelten támogatom azt az ötletet, hogy a számlázó csak adatot küldjön be, úgy mintha csak egy papír alapú számlának lenne az egyik példánya. A NAV meg ezt dolgozza fel. Illetve, ha akar valamilyen statisztikát saját magának, akkor jutalmazza azokat a cégeket, akik úgy küldenek be adatokat, hogy azt már a NAV statisztikailag is fogadni tudja.
Nem látom az értelmét ennek a túl bonyolításnak. Sokkal több a veszteség, mint a haszon. Ha az a sok programozó, aki ezen dolgozik, helyette valódi terméket hoz létre, esetleg exportra is, az a nemzetgazdaságnak sokkal nagyobb hasznot jelentene, mint a fél évente értelmetlen változtatások leprogramozása.
Gondolom az online beküldés eredeti célja a gazdaság fehérítése, az adóelkerülés csökkentése. Ez teljesen rendben van, és egy jó törekvés. CSAK ehhez elég lett volna egy sima, egyszerű beküldés. Azaz, hogy az adott számla szövegesen milyen tételeket tartalmaz, azoknak mennyi az értéke, és mennyi az ÁFA-ja, és kész. Majd vizsgálni, hogy mindegyik oldalon ez bevallásra, megfizetésre került-e. Összegszerűen.
Igazából úgy is az a lényeg, hogy meg legyen fizetve az összes adó. Ha ez megtörtént, akkor senkinek az érdeke nem sérül. Az államkassza jól lakik, a programozók nem tépik a hajukat, a userek boldogak.
Ha tévedek sorry, javítsatok ki.
Igazából ezt kellene valami szinten "nemzeti konzultálni". A NAV részéről tök jó megközelítés lenne, ha nyitna egy fórumot, társadalmi vitaközösséget, ahol ezeket a problémákat meg lehetne vitatni. Van itt egy csomó jó fej, nem troll, programozó, user csoport, akik szerintem érdemben tudnának nyilatkozni ezekben az ügyekben.
Személy szerint nekem elég rosszul esik, hogy a kis számlázó programomat, amit kb. 5-6 cég használ, mert egyedi vállalatirányítási rendszer része, félévente 3 hetet ülünk rajta, hogy a szükséges módosításokat elvégezzük.
Szép napot mindenkinek!

[PistikeSzoftver]

Nehéz újat írni a témáról már majdnem mindent leírtatok miért kell ezt visszavonni. Szinte teljesen egyetértek az előző hozzá szólásokkal. VISSZA KELL VONNI !!!! Rossz elképzelés.

[vastaliga]

Abban a felettébb kellemetlen esetben, ha a lineNatureIndicator megmaradna, felvetődik a kérdés, hogy vajon a hatósági díjak hová tartoznak. Mert hogy az se nem szolgáltatás se nem termék.

[nbeeps2]

Ügyesen el lett ez dugva, vhogy elkerülte ez eddig a figyelmen. A changelog-ba a DATA sémaleíróban (2.2-es fejezet) egyáltalán nem is említik, hogy bekerülne egy ilyen mező...

[akikari]

Mindenkivel egyetértek. @czbhu-hoz hasonlóan én is vállalatirányítási rendszert fejlesztek, aminek századrésze a számlázás. Ehhez képest aránytalanul sokat kell foglalkozni vele, és nincs rá elegendő kapacitás.

Költői kérdés, hogy nem tartanak-e attól, hogy az éveken keresztül egyre bonyolultabbá váló szabályozás annyira megkeseríti a gazdasági szereplők életét, hogy egyre többen alternatív megoldásokat kezdjenek keresni? Mert akkor visszafeketedik a gazdaság, és az senkinek sem lesz jó.

[betasofthu]

Csatlakozom, nem szabad bevezetni. Nem szabad diszkriminálni az adatszolgáltatást beküldőket, épp elég plusz terhet viselnek.

[NTCA-developer]

Sziasztok!

Köszönjük a felvetéseket. Olvastuk a prog.hu-s szálat és az itteni hozzászólásokat is. Előzetesen kicsit szeretném hűteni az indulatokat.

Az e-ÁFA tervezés és az Online Számla fejlesztés párhuzamosan futnak egymás mellett, előbbi június 20-án ért oda arra a pontra, amikorra láthatóvá váltak azok az adatok, amikek a bázisidőszaki "beállására" szükség van ahhoz, hogy a szolgáltatás elindulhasson. Ugyan ezen a napon publikáltuk GitHub-on az ÁFA analitikás kiegészítést, aminek része a szóban forgó lineNatureIndicator is, hiszen a két rendszer értelemszerűen hat egymásra.

Ugyan eltelt több mint egy hónap azóta, de nyitottak vagyunk a szakmai vitára és nem gördítünk akadályt a kérdés újramelegítése elé, mint ahogy eddig is tettük itt a GitHubon jónéhány másik kérdésben is, elég csak a lezárt jegyeket megnéznetek.

Jelenleg egy olyan módszertani segédlet összeállításán (is) dolgozunk, amely segítségével a lineNatureIndicator kitöltése algoritmizálható addig a szintig ami nekünk elégséges, ezért lehetséges hogy nagyon csak az egyik oldalát látjátok a kérdésnek. Ezt követően szeretnénk megmutatni nektek, hogy milyen okból került be a sémába a kérdéses elem, és utána vitázhatunk.

Hamarosan reagálunk, a türelmeteket kérem.

[nbeeps2]

NTCA-developer: E kapcsán két dolgot nem értünk:

1. Az ÁFA-t csak akkor lehet megmondani, ha minden számla bekerül a NAV rendszerébe. Addig, amíg csak a 100 ezer ÁFA-t elérő számlákat kell beküldeni nincs értelme ÁFA analitikát számolgatni, így a lineNatureIndicator mező is értelmetlen.

1. Ha szerintetek algoritmizálható a dolog, akkor miért mi algoritmizáljunk a 200 féle különböző programjainkban és miért nem ti oldjátok ezt meg központilag a túloldalon? Mi is pont annyit tudunk megítélni a számlatételeiből, mint ti ott a fogadó oldalon. Tudjuk a nevét és a mennyiségi egységet. Feltételezhetjük, hogy az óra mennyiségi egység szolgáltatást takar, a kg meg terméket, kb. ennyi.

[csaszko]

NTCA-developer: E kapcsán két dolgot nem értünk:

1. Az ÁFA-t csak akkor lehet megmondani, ha minden számla bekerül a NAV rendszerébe. Addig, amíg csak a 100 ezer ÁFA-t elérő számlákat kell beküldeni nincs értelme ÁFA analitikát számolgatni, így a lineNatureIndicator mező is értelmetlen.
2. Ha szerintetek algoritmizálható a dolog, akkor miért mi algoritmizáljunk a 200 féle különböző programjainkban és miért nem ti oldjátok ezt meg központilag a túloldalon? Mi is pont annyit tudunk megítélni a számlatételeiből, mint ti ott a fogadó oldalon. Tudjuk a nevét és a mennyiségi egységet. Feltételezhetjük, hogy az óra mennyiségi egység szolgáltatást takar, a kg meg terméket, kb. ennyi.

A százezres határ nem a probléma, mert azt majd egy tollvonással ki lehet tolni mindenre. (meg már most is beküldheted).
A második felvetésnél én is valami ilyesmit szerettem volna írni. Ha algoritmizálható akkor miért is kell kliens oldalon megoldani?
A módszertani segédlet összeállítása helyett, lehet érdemesebb lenne a belső megoldására koncentrálni.

[nbeeps2]

A unitOfMeasure is pont ilyen volt. Én azt láttam, hogy a felhasználó megadta, hogy db és feltöltöttem, hogy PIECE. Ezt az összehasonlítás és értékadás dolgot is központilag meg lehetett volna csinálni, amikor a rendszer központilag befogadja az adatokat.

Most viszont egy elképzelni se tudom, hogy mi alapján fogja az algoritmus megmondani, hogy a termék tartozik a szolgáltatáshoz vagy a szolgáltatáshoz tartozik a termékhez mondjuk egy olyan számlán, amin csak 1 termék és 1 szolgáltatás van.

[csaszko]

Sziasztok!

Köszönjük a felvetéseket. Olvastuk a prog.hu-s szálat és az itteni hozzászólásokat is. Előzetesen kicsit szeretném hűteni az indulatokat.

Az e-ÁFA tervezés és az Online Számla fejlesztés párhuzamosan futnak egymás mellett, előbbi június 20-án ért oda arra a pontra, amikorra láthatóvá váltak azok az adatok, amikek a bázisidőszaki "beállására" szükség van ahhoz, hogy a szolgáltatás elindulhasson. Ugyan ezen a napon publikáltuk GitHub-on az ÁFA analitikás kiegészítést, aminek része a szóban forgó lineNatureIndicator is, hiszen a két rendszer értelemszerűen hat egymásra.

Ugyan eltelt több mint egy hónap azóta, de nyitottak vagyunk a szakmai vitára és nem gördítünk akadályt a kérdés újramelegítése elé, mint ahogy eddig is tettük itt a GitHubon jónéhány másik kérdésben is, elég csak a lezárt jegyeket megnéznetek.

Jelenleg egy olyan módszertani segédlet összeállításán (is) dolgozunk, amely segítségével a lineNatureIndicator kitöltése algoritmizálható addig a szintig ami nekünk elégséges, ezért lehetséges hogy nagyon csak az egyik oldalát látjátok a kérdésnek. Ezt követően szeretnénk megmutatni nektek, hogy milyen okból került be a sémába a kérdéses elem, és utána vitázhatunk.

Hamarosan reagálunk, a türelmeteket kérem.

Szia,
/OFF
Ha megengeded a véleményem, ezzel nem gondolom, hogy hűteni fogjátok az indulatokat:
"Ugyan eltelt egy hónap"... konkrétan azt várjátok el mindenkitől (teljesen mindegy igazából, hogy melyik évszakban, de a nyár közepén amikor sokan próbálnak szabadságra menni) az ide-oda publikált, beszúrt soraitokat bogarássza mindenki és úgy nézze át, tudja hogy mit is kell keresni és átlássa mint Ti akik ezzel a projekttel foglalkoztok folyamatosan???? Szerintem nagyon rossz a megközelítés, az egyszerűsítésen kellene dolgozni és nem a további bonyolításon (mind az információ átadás és mind pedig az adatbeküldés területén)

[darmalost]

csaszko-val értek egyet! Ez a GitHub-os felület nehezen emészthető. Én is onnan tudtam meg, hogy változott ez a dolog, hogy egy sima leírást elolvastam, hogy mi változik a 2.0-ban. Nem bogarászom az XSD-t, le lehet írni sorról-sorra, hogy mi fog változni, minek változik meg a típusa, a hossza, milyen mezők jöttek létre, mik szűntek meg. Erre elég lett volna a hivatalos online számla teszt felület, egy sima PDF, stb.. Abban is biztos vagyok, hogy még így is egy szűk réteg vagyunk itt és a prog.hu fórumon és a nagy többségnek még fogalma sincs pl. a lineNatureIndicator-ról.

[NTCA-developer]

@csaszko, @darmalost

/OFF

Iratkozzatok fel a projektre, látom hogy még nem vagytok rajta. Onnantól kaptok emailt minden változtatásról. (Watch opció)

A lineNatureIndicator itt került be, lehet látni a változásokat: https://github.com/nav-gov-hu/Online-Invoice/commit/35ac370baa238fe3751e894af67027e2f12fa387

A changelog is változik a sémával együtt, ebben le van írva mi változott. Ha szabin vagy, akkor megnézheted utána is. Ennél jobbat a világ jelenleg nem kínál verziókezelésre.

[vastaliga]

Lehet, hogy nem leszek népszerű :) , de a github pontosan remek eszközt ad a forráskód változásának követésére, csak úgy mint bármelyik verziókövető rendszer. Így most már csak az sem kell, hogy a saját TFS-re/VSTS-re/akármire feltöltve nézegessem, mi változott.
Mondjuk én konkrétan eddig sem kézzel bogarásztam a változásokat. De ha már itt tartunk, akkor a PDF veziók összehasonlítására is van egy eszköz, bele is raktam két külön verziójú PDF-et: https://draftable.com/compare/LTMWhXZrHoZf

Ezek szerintem megkönnyítik a munkánkat.

[csaszko]

@csaszko, @darmalost

/OFF

Iratkozzatok fel a projektre, látom hogy még nem vagytok rajta. Onnantól kaptok emailt minden változtatásról. (Watch opció)

A lineNatureIndicator itt került be, lehet látni a változásokat: 35ac370

A changelog is változik a sémával együtt, ebben le van írva mi változott. Ha szabin vagy, akkor megnézheted utána is. Ennél jobbat a világ jelenleg nem kínál verziókezelésre.

Köszönöm, de sajnos nem értettél meg.
Nem azért van a kérdés vagy vita közöttünk, hogy verziókezelésre mi a legalkalmasabb eszköz.

• Elkezdtetek publikálni az online számla oldalon.
• Pdf
• Létrehoztátok a a teszt oldalt is ami elvileg a fejlesztőknek van, ezután
  létrejött az rss ami működik vagy nem nem tudom nem használom.
• GITHUB

Költői kérdés: hogy fér az össze, hogy a titkosítást meg jó pár dolgot nemzetgazdasági érdekekre hivatkozva ismételten módosítanunk kell, - mert elsőre nem sikerült kitalálnotok mit is szeretnétek. vagy az elődjeitekének, teljesen mindegy - Aztán minden lényeges információt kitesztek egy amerikai vagy nem tudom hol lévő szerverre. (Feltételezem nem nálatok van). Ha majd véletlenül nem lesz elérhető x ideig mint pl a nem kell messze menni a face vagy bármi más.. akkor honnan fogunk információhoz jutni?

Nem fogok most semmit kiemelni, mert már mindennel kapcsolatban elhangzottak pro és kontra érvek, de a probléma azzal van, hogy olyan dolgokat vártok el, teljes természetességgel, amik messze túl vannak sokszor azon, hogy mindenki szeretne megfelelni a törvényeknek, jogszabályoknak és azok szerint cselekedni. Már számtalan olyan adatot nekünk kell megadni vagy "kitalálni" amit szerver oldalon elő tudnátok állítani. Mert mi sem logikusabb annál, hogy sok 100 vagy 1000 számlázó programot kelljen módosítani és több száz ember dolgozzon vele, amikor Nektek annyiból állna, hogy írtok akár az offline adatbázisra néhány lekérdezést vagy akármi más megoldás.
Továbbra is mint már számtalanszor leírtam, az elképzelés jó lenne nagyon hiszen valóban mindenkinek az az érdeke, hogy fehéredjen a gazdaság, de továbbra sem gondolom, hogy azoknak kellene folyamatosan még többet szívni akik megszeretnének felelni a jogszabályi előírásoknak! (Nem a NAV-nál dolgozó döntéshozóknak!)
És persze ezek sem segítenek a kisembernek:
"Tájékoztatjuk, hogy a válaszlevél tartalma szakmai véleménynek minősül, kötelező jogi erővel nem bír."

[csaszko]

Lehet, hogy nem leszek népszerű :) , de a github pontosan remek eszközt ad a forráskód változásának követésére, csak úgy mint bármelyik verziókövető rendszer. Így most már csak az sem kell, hogy a saját TFS-re/VSTS-re/akármire feltöltve nézegessem, mi változott.
Mondjuk én konkrétan eddig sem kézzel bogarásztam a változásokat. De ha már itt tartunk, akkor a PDF veziók összehasonlítására is van egy eszköz, bele is raktam két külön verziójú PDF-et: https://draftable.com/compare/LTMWhXZrHoZf

Ezek szerintem megkönnyítik a munkánkat.

Komolyan nem a Github-bal van a problémám, vagyis nem azzal, hogy van... meg kellene tanulni rendesen használni persze.. de minek is? Hogy tudjak "dolgozni" a nav-nak? Miért is nem volt jó a pdf, kiemelve az egyes változtatásokat egy külön szekcióban? Ahogy az volt az elején? (Ha már mindenképpen követnünk kell a változásokat, aminek soha nem lesz vége)

[KimmerGy]

Nem vagyok könyvelő sem adószakértő ezért próbáltam
pontosan utánanézni a "" ÁFA analitika"" fogalomnak.
A számlatétel minősítésének a 4 lehetősége (szerintem) befolyásolja
a tételhez rendelt ÁFA kulcsot, illetve szinkronban kell lennie a kettőnek.
Ember legyen a talpán az a számlakiállító aki nem ütközteti
a minősítést az ÁFA kulccsal.

Ráadásul, az ÁFA analitikával kapcsolatosan max. ezt találtam,
(amiben nem szerepel tétel minősítés).

""""_Jó esetben az ÁFA-analitikád tartalma így néz ki:
számla sorszáma
számla kiállítója
számla szerinti teljesítés időpontja
számla nettó értéke
számlában szereplő ÁFA-kulcs
számla ÁFA-tartalma
számla bruttó összege
összegző rovatok az oszlopok alatt (vagyis az összes nettó érték, az összes ÁFA-tartalom, az öszes bruttó érték mindenképpen meg kell, hogy legyen)_""""

[csaszko]

/OFF

Elnézést kérek azoktól, akik esetleg csak és kizárólag a szakmai dolgok miatt jöttek ide (valamint akiknek nem ingük) és a felháborodásomat "kellett" olvasniuk ... de már sokadszorra kapunk ilyen-olyan nesze semmi fogd meg jól magyarázatot, hogy miért is nekünk kell megoldani és nem bírtam szó nélkül. Mert az biztos, hogy nem látjuk minden oldalát a feladatnak, de aki egy kicsit is foglalkozott a témával az biztosan látja, hogy mik azok a dolgok amiket laza egyszerűséggel a számlázó programokat fejlesztő programozókra/cégekre hárítják.

[darmalost]

A changelog is változik a sémával együtt, ebben le van írva mi változott. Ha szabin vagy, akkor megnézheted utána is. Ennél jobbat a világ jelenleg nem kínál verziókezelésre.

Nem vagyok NAV fejlesztő. Nem az én tisztem kitalálni és megírni a rendszert. Én fejlesztem a saját termékem, azzal is rengeteg munka van. Oké, hogy lehet véleményezni, amit Ti kitaláltok (ezt itt és most meg is tettük páran), de nyilván sokan voltunk vele úgy, hogy majd akkor hozzászólunk a rendszerhez, ha már kezd véglegesedni/letisztulni a kép. Nem sokan lehetünk, akiknek van arra kapacitása, hogy ingyen tanácsadósdit játsszon a NAV-val. Szóval én sem követtem az elejétől a changelog-ot és az sem érdekelt, hogy napról-napra mi változott. Én végig egy olyan listára vártam, ahol jól áttekinthetően le van írva, hogy mi mire változott. Ez pedig nem kell GitHub sem...

De térjünk vissza a lényegre: Azt szeretnénk, ha a 07.31-én publikálni kíván verzióban már NEM lenne benne a lineNatureIndicator mező! Ha pedig mégis benne maradna, akkor konkrét válaszokat várunk a témaindító és az azóta által felvetett példákra, hogy mi a konkrét megoldása a NAV-nak! Azt gondolom, hogy nem igazán érdekel minket, hogy miért van erre a mezőre a NAV-nak szüksége. Ez számunkra nem vigasz.

[NyBela]

Sok éve dolgozunk azon, hogy a számlázók munkáját lehetőség szerint automatizáljuk, vonalkóddal, adatgyűjtőkkel, adatimportokkal és mindenféle egyéb módon.
A Számlázáskor már ne kelljen dönteni, hanem csak számlázási feladatot végrehajtani. A Számlázási adatokat, beállításokat, besorolásokar, stb. a számvitelhez értő és az adott rendszerben megfelelő joggal rendelkező felhasználók állítják be. (pl. könyvelők, számviteli szakemberek).
Adott esetben két-három személy kiszolgálja a 30-40 számlázót.
A számlázó ne döntsön, ő a végrehajtó személy. Ne legyen lehetősége téves információt közölni.
Ha most döntésre kényszerítik a számlázó személyeket, akkor sajnos adott esetben nem lesznek alkalmasak a feladat ellátására. Már most is határeset, amit számlázás címen végre kell hajtani.
Persze lehet azt mondani, hogy akkor más, képzettebb munkaerő számlázzon.
De egy termelő, kereskedő cégnél ez nem így működik.
Azt a szakembert, aki jó kereskedő 30 éve, azért kelljen "lecserélni", mert a munkájának egy töredékét, a számlázást nem érti? Számviteli szakembert kell képezni egy eladóból?
Ő készíti elő ezen logika szerint az ÁFA bevallást? Ne komolytalankodjunk.
Ezek nem csak számítástechnikai kérdések.
Milyen felelősséggel fogja kiválasztani ezeket a besorolásokat?
Ki fogja ellenőrizni?
Hogyan lehet felelősségre vonni? Munkaszerződés tartalma stb. stb..
Értem, hogy ez minden cég magánügye, hogy hogyan oldja meg.
De kérem, mit fognak kezdeni egy értelmetlen adathalmazzal?

[vankcuf]

Hozzáteszem, hogy sok egyszerű számlázó programban még azt sem tudni, hogy mi a termék és mi a szolgáltatás, mivel nincs benne készletkezelés, így ez sokszor az adott program szempontjából nem is érdekes és nem feltétlen van benne ilyen csoportosítás. A készletkezelő rendszereknél már van ilyen elkülönítés, onnan tudja a rendszer, hogy melyik terméknél kell kezelni készletet és melyiknél nem (pl. szolgáltatásnál nincs értelme).

[vajayattila]

Jelenleg egy olyan módszertani segédlet összeállításán (is) dolgozunk, amely segítségével a lineNatureIndicator kitöltése algoritmizálható addig a szintig ami nekünk elégséges, ezért lehetséges hogy nagyon csak az egyik oldalát látjátok a kérdésnek. Ezt követően szeretnénk megmutatni nektek, hogy milyen okból került be a sémába a kérdéses elem, és utána vitázhatunk.

Nem gondolom, hogy az Online számlázó fejlesztése kedvéért át kéne tolni a számlázó program fejlesztőinek nyakába olyan feladatokat, amit a szerver oldalon kéne megoldani. Ha ez marad a szemlélet az csak azt eredményezheti, hogy a fejlesztés soha nem fog megállni. Ez mondjuk minket, a számlázó program fejlesztőit nem érdekli, amíg ez a NAV-on belül marad. Azért van a beküldő interface, hogy a törvényben minimumként meghatározott adatokat beküldjük rajta. Az, hogy ezzel mi lesz, az nem számlázó programok fejlesztőinek felelőssége. Nem szeretnénk évi két alkalommal számla beküldő intefacet fejleszteni, mert a NAV kitalált valami jó/rossz ötletet. És ez szerintem nem kéne, hogy vita tárgya legyen.

[darmalost]

A készletkezelő rendszereknél már van ilyen elkülönítés, onnan tudja a rendszer, hogy melyik terméknél kell kezelni készletet és melyiknél nem (pl. szolgáltatásnál nincs értelme).

Igen, azonban ez sem feltétlen 100%-osan megbízható. Mert nem biztos, hogy szolgáltatás az, aminek ki van kapcsolva a készletkezelése, mert lehet az is egy termék, csak épp nem vagyok kíváncsi a készletére.

Elég csak "házon belül" maradni a példáért:

Szoftvert értékesítesz, mint termék, de mivel nincs értelme készletre venni, mert nem tud kifogyni, mivel online letölthető, így nem kapcsolod be a készletkezelését, de mégse szolgáltatásról van szó, kivéve, ha online program/SaaS konstrukciót nézzük.

[kabelnet2]

Én is megérdeklődtem hozzáértőtől, minek is ez az egész. A válasz:
"Ez ÁFA törvény és ehhez kapcsolódó állásfoglalás miatt van.
Ha valami például termékértékesítéshez kapcsolódó szolgáltatásnyújtás, akkor az ÁFA besorolása ugyanaz mint a termékértékesítésnek.
Ez főleg az EU-s értékesítéseknél fontos, hiszen ott külön jelentjük a nyújtott szolgáltatásokat és nyújtott termékértékesítéseket.
Mondjuk azokat még pont nem jelentjük online De gondolom készülnek a jövőre , amikor már minden kimenő számlát be kell jelenteni."

[csaszko]

Én is megérdeklődtem hozzáértőtől, minek is ez az egész. A válasz:
"Ez ÁFA törvény és ehhez kapcsolódó állásfoglalás miatt van.
Ha valami például termékértékesítéshez kapcsolódó szolgáltatásnyújtás, akkor az ÁFA besorolása ugyanaz mint a termékértékesítésnek.
Ez főleg az EU-s értékesítéseknél fontos, hiszen ott külön jelentjük a nyújtott szolgáltatásokat és nyújtott termékértékesítéseket.
Mondjuk azokat még pont nem jelentjük online De gondolom készülnek a jövőre , amikor már minden kimenő számlát be kell jelenteni."

Mit értünk áfa besorolás alatt azt írták? % vagy egyéb dolog?

[kabelnet2]

Re: [nav-gov-hu/Online-Invoice] [FEATURE] lineNatureIndicator elvetése (#58)

Felteszem a %. Mivel nálunk minden 27%, nem igazán érdekelt tovább. Üdv.

Én is megérdeklődtem hozzáértőtől, minek is ez az egész. A válasz:
"Ez ÁFA törvény és ehhez kapcsolódó állásfoglalás miatt van.
Ha valami például termékértékesítéshez kapcsolódó szolgáltatásnyújtás, akkor az ÁFA besorolása ugyanaz mint a termékértékesítésnek.
Ez főleg az EU-s értékesítéseknél fontos, hiszen ott külön jelentjük a nyújtott szolgáltatásokat és nyújtott termékértékesítéseket.
Mondjuk azokat még pont nem jelentjük online De gondolom készülnek a jövőre , amikor már minden kimenő számlát be kell jelenteni."

Mit értünk áfa besorolás alatt azt írták? % vagy egyéb dolog?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/nav-gov-hu/Online-Invoice/issues/58?email_source=notifications\u0026email_token=AL6YQHK7YJ7NHRQYEGZUW3LQB4EDLA5CNFSM4IHBCHEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3BCO2A#issuecomment-516040552", "url": "https://github.com/nav-gov-hu/Online-Invoice/issues/58?email_source=notifications\u0026email_token=AL6YQHK7YJ7NHRQYEGZUW3LQB4EDLA5CNFSM4IHBCHEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3BCO2A#issuecomment-516040552", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[vajayattila]

Felteszem a %. Mivel nálunk minden 27%, nem igazán érdekelt tovább. Üdv.

27%, 18%, 5% vagy 0%. Így első felindulásból :)
De most így fejből nem vagyok biztos benne.

[czbhu]

szerintem ami nagyon lényeges lenne, hogy válasszuk külön az eÁfa-t és a számlázást. Mi nem könyvelő programot akarunk fejleszteni, és jó lenne, ha erre nem is kényszerítenne a NAV, hanem egy sima számlázó modult. pont. ennyi.
illetve ha valamit kitalálnak, és azt végig akarják vinni rajtunk, akkor tegyenek közzé olyan nyílt forráskódú APIkat, ami az adott problémát lekezeli. lehetőleg az összes ismertebb programnyelvben (java, c#,C++,PHP).
legyenek működő példák MVCben, és akkor csak a Viewet kell módosítani, és készen is vagyunk. nincs hiba forrás, kevesebb a nyitott kerdes, stb...

[darmalost]

Szeretném megkérdezni a tisztelt NAV-tól, hogy végeztek-e a gyakorlatban konkrét felmérést az átlagos számlakiállítók között, hogy 100 (de inkább 1000) átlagos számlázó emberből (nem könyvelő, nem adószakértő, hanem őstermelő, villanyszerelő, építőiparban dolgozó, stb.) egy 10 különböző feladatból álló teszten hányan sorolták be megfelelően az adott számlatételeket a megfelelő lineNatureIndicator helyre?

Egy ilyen horderejű számlázási kérdésben az a minimum, hogy végeznek egy előzetes "piackutatást" és nem csak úgy bevezetünk egy mezőt és utánunk a vízözön.

[nbeeps2]

:) Hát ja, nálunk ha egy brainstormingon ilyen felmerülne fejlesztési javaslatként kb. fél perc alatt leszavazzuk az illetőt. Aki ismeri a felhasználókat, az tudja, hogy ez egy elvetélt ötlet!

[vankcuf]

NTCA-developer: türelmesen várjuk majd azt az algoritmust is, ami automatán megmondja egy számlatételről, pusztán azt csak, hogy szolgáltatásról vagy termékről van szó (a másik 2 dolgot most hagyjuk is). Gondolom, hogy a NAV Online számla kifejlesztésekor felmérték a hazai számlázó programok működését és tisztában vannak azzal, hogy számos számlázó programban lehet úgymond "törzs nélkül" számlázni (a felhasználók nagy kedvenc funkciója!), vagyis olyan terméket/szolgáltatást kiszámlázni, ami nincs elmentve a cikktörzsben. Természetesen VTSZ nem áll rendelkezésre, mivel nem kötelező, szóval pusztán a neve, áfa%, és mennyiségi egységéből kéne megmondja az algoritmus, hogy termék vagy szolgáltatás. Az algoritmus fejlesztéséhez rögtön adok példát is:
1 db LCD monitor
1 db Házhozszállítás

Vitatkozhatunk azon, hogy a 2. tételnél, mint szolgáltatás mennyire helyes a db mennyiségi egység alkalmazása, de hát ilyenek a felhasználók... Jó munkát kívánok!

[czbhu]

vankcuf:
ez viszonylag egyszerű példa :) inkább legyen a számlán:
100 db toll
1 db LCD monitor
1 db házhozszállítás
1 db beállási költség
1 db kommissziós költség
1 db telefon javítás

[czbhu]

NTCA-developer: egyébként arról lehet tudni valami információt, hogy milyen sűrűn kell változtatnunk a számlázó programunkat? Ki se jött a 2.0, de már a 3.0 emlegetve van.
Szerintem sokan úgy vagyunk, hogy ügyfél megtartása érdekében még nyeljük a plusz munkát, és a veszteségeket, de ez nem fog menni a végtelenségig. Jelen helyzetben elég bizonytalanul állok én is ahhoz, hogy egyáltalán megéri ezzel foglalkoznom vagy nem. Mondjuk ha az a cél, hogy a "kicsiket" kisöpörjék és csak a nagyok maradjanak, akkor nem rossz az irány.

[csaszko]

NTCA-developer: egyébként arról lehet tudni valami információt, hogy milyen sűrűn kell változtatnunk a számlázó programunkat? Ki se jött a 2.0, de már a 3.0 emlegetve van.
Szerintem sokan úgy vagyunk, hogy ügyfél megtartása érdekében még nyeljük a plusz munkát, és a veszteségeket, de ez nem fog menni a végtelenségig. Jelen helyzetben elég bizonytalanul állok én is ahhoz, hogy egyáltalán megéri ezzel foglalkoznom vagy nem. Mondjuk ha az a cél, hogy a "kicsiket" kisöpörjék és csak a nagyok maradjanak, akkor nem rossz az irány.

NAV csinálja meg a számlázóját, úgy ahogy akarja olyan adatokat kérjen be pluszba amit akar és ahhoz biztosítson egy adatfeltöltő api-t. (import funkciót valami módon) Törvény tegye kötelezővé annak a használatát mindenki számára, az adatokat amiket átküldenek a programok: megnevezés, mennyiség, mennyiségi egység, egységár áfa%, vevo adoszam,elado adoszam,3 datum, szamla tipus. esetleg megjegyzés. (ami a legtöbb számlaképen van) Ez csak annyira legyen elég, hogy a navos számlázót feltöltik utána a user átnézni bekattintja számlánként vagy soronként egyesével, hogy mikor éppen mit kér az adóhivatal. És majd mikor mindez megtörtént már neki is állhat a következő időszaki számlák átnézésének és kattintgatásának.

[RvPSc]

Üdv!

1. Először is köszönöm, hogy egy 20. platformon is regisztrálhattam és nyomon kell követnem
2. A fentiekkel általában egyet értek, de ne lineNatureIndicator-nak nevezzük a témát, hanem általánosan olyan adatnak, aminek a kötelezőségére nincs törvényi háttér! (tudom, az NGM rendelet a számlázók adatszolgáltatásáról homályosan fogalmaz és elvileg diktatúra van)
3. Melyik szervnél lehet ezekre a dolgokra panaszt tenni? Felülvizsgálatot kérni? Esetleg ez van a hierarchia tetején? Vagy tényleg csak annyi lehetőségünk van, hogy pl. traktorok és taxik helyett "laptopokkal" blokkoljuk a NAV székház előtt a forgalmat? De tényleg... Mikor lesz ennek vége?

Minden adatot beküldünk ami egy számlán van. A titkosítást elrontottátok, oké, ezt módosítjuk. Apró javítások, oké hozzáigazítjuk. De azért mert nem vagytok képesek a beérkező adatot feldolgozni, ne nekünk kelljen már minden második hónapban átírni a szoftverünket. Azt látom, hogy van a NAV-nál "két fejlesztő" és ahelyett, hogy bővítenék a csapatot, mindent a számlázó fejlesztőkre hárítanak át. Ajánljatok fel állást, zsíros pénzért megyünk és kijavítjuk a "sok jó dolgot", amit kitaláltatok, csak a megvalósításhoz már nem volt elég "agy" (piackutatás, igényfelmérés -> javaslom járjatok utána ezeknek a fogalmaknak is, mielőtt újabb jóságokon gondolkodnátok -> google / fogalomtár)

[czbhu]

én is szívesen megyek zsíros pénzért szakérteni :)
De szerintem sok fejlesztő örömmel segítene szakmai hiúságból is, hogy egy jól átgondolt rendszer legyen a vége.
Mondjuk itt is és a prog.hu-n is leírták már a legegyszerűbb változatát ennek: a számlázó ne legyen könyvelő progi (ha valaki könyvelő progit szeretne, az majd lefejleszti, ha akarja OPCIONÁLISAN), EDI szabvány, egy feltöltő API, ami csak a trv. szerinti kötelező elemeket kéri.

[NyBela]

Visszatérek arra, amit már egyszer megírtam, de nincs rá válasz.
Nem azzal van probléma, hogy fejleszteni kell a számlázó programokat.
Megtesszük, eddig is megtettük, igaz nem nagy kedvvel, mert óriási költség növelő, gyakorlati haszon nélkül.
A probléma, hogy olyan személyek fognak dönteni egy - egy számla tételről, akinek nem feladata, nincs hozzá képzettsége, felelőssége stb. Ez alapján szeretnének e-ÁFÁt- készíteni.
Azt kellene megérteni, hogy nem könyvelők, adószakértők számláznak. Egy nagy cégnél a számlázás már csak a folyamat vége, sok esetben teljesen automatikus. Elvégzi pl. a raktáros. Most képezzük át a raktárosokat? A vállalatirányítási folyamatokkal kellene tisztában lenni.
Minden szabályozás stb. akkor működik, ha betartható, számonkérhető.
A számonkéréssel nem is lesz majd probléma, de a betarthatóság az esélytelen.
Ki lesz az a számviteli szakember egy cégnél, aki fel meri vállalni a felelősséget az ilyen formán kiállított számlákért és az ebből készített ÁFA bevallásért?

[RvPSc]

Ez a NAV szerint roppant egyszerű. Végezzen gazdasági egyetemet a fagyis kocsin dolgozó diák! :)
(extrém példa, de nagyjából ezt várják el)

[darmalost]

Rákerestem NTCA-Developer által említett "e-ÁFA tervezés" projektre:
Google: Nincs találat a következőre: "e-ÁFA tervezés". Pontosan mi is ez?

A jelenlegi bonyolult ÁFA törvény mellett csak a jelenlegi model működhet: vagyis a felhasználó számláz, a könyvelő meg egyesével elbírálja a számlákat, lekönyveli és megállapítja az ÁFA-t.
e-ÁFA tervezés és automata ÁFA kitalálás/kitöltés csak akkor játszhat, ha valami triviális egyszerűségűre lefaragják az ÁFA törvényt, aminek 0% az esélye.

Elég csak egyébként a bejövő számlákból kiindulni. Azzal, hogy kapok én egy bejövő számlát, egyáltalán nem vagyok köteles azt költségként elszámolni, megtehetem azt is, hogy széttépem és nem számolom el költségként. Ilyen lehet, amikor a tudatlan vállalkozó olyan dolgot vásárol mondjuk készpénzben a cége nevére, amit nem számolhat el költségként. Számla széttép, a házipénztárból ilyenkor nem lehet kivenni pénzt és a vállalkozó a saját pénzével fizeti a számlát.

[kabelnet2]

Azt azért nem pontosan értem, miért írják sokan, hogy ez nem tartozik a számlázó programra. Ha jól értem, ez az érték hat(hat) az ÁFA százalékra, ami meg igencsak a számlázó programra tartozik. Az egészről az ÁFA törvény rendelkezik.
Az, hogy eddig nem volt vele gond, azért lehet, mert szinte minden 27% volt. De mondjuk ha sertéshúst szállítasz házhoz? (Nem vagyok érdekelt ilyesmiben, csak felvetem. Meg gondolom, nem is lehet házhozszállítani. Csak példa.)

[darmalost]

kabelnet2: A válasz egyszerű. Az ÁFA törvény nem változott. A számlázás nem változott. A példád alapján eddig is állítottak ki ilyen számlákat. Az ÁFA %-os eddig sem hasraütésre állították be a számlán. lineNatureIndicator-ra a felhasználónak nincs szüksége, a számlázó programnak sincs szüksége.

[czbhu]

kabelnet2: ezért van az, hogy odaírod, hogy minek mennyi az áfája. %-ban és értékben.

[RvPSc]

kabelnet2: ahogy írtad hat(hat)... Tehát semmikép sem kötelező. Ha Te ezt rá akarod pusholni az ügyfeleidre, akkor szíved joga, de ne vezessünk be új jogszabályokat hasraütésre és ne kötelezzünk rá mindenkit önkényesen.

[KimmerGy]

A számla kiállítója elkészíti a számlát, az áfa kulcsokat
előírás szerint és helyesen adja meg, majd a tételt is minősíti egy elem kiválasztásával.
Mielőtt rögzíti a számlát megtekinti a számla képét és látja hogy
nem szerepel sehol a tétel minősítése.
Ezek után vajon mit fog gondolni ?

• Ha nem látom a tétel minősítését és üzenetet sem kapok ha
  helytelenül választom meg, akkor nem tök mindegy, hogy
  milyen minősítést adok a tételnek ? - Így is gondolkozhat a számla kiállítója.
  (és szerintem így is fog gondolkozni)

Vagyis: retorzió várható ha a számlában a tételek áfa kulcsa helyesen lett
megválasztva, de a tétel minősítése hibás ?

Más :
Ha az adóellenőrnek beküldhető adott időszak számlái az online küldés
által előállított XML állományokkal akkor az adómentes tételeknél is
szerepeltetni kell a minősítést ? (mert ha nem, hibás az XML)

[darmalost]

"Ezek után vajon mit fog gondolni ?"
"Ha nem látom a tétel minősítését és üzenetet sem kapok ha
helytelenül választom meg, akkor nem tök mindegy, hogy
milyen minősítést adok a tételnek ?"

Ennél még nagyobb baj, hogy a legjobb szándékát és az összes IQ-ját beleveti sem fogja tudni jól megadni a besorolást, mert nem ért hozzá és nem adószakértó, és nem fogja minden számlánál felhívogatni a könyvelőt, hogy ez most minek számít, nem beszélve arról, hogy a könyvelők sincsenek sokszor képben...

Számla helyesbítés szintén problémás, éppen amiatt, mert egy láthatatlan önkényes elemről beszélünk.

Persze, ha megadhatjuk a "feltaláló" magán mobilszámát a programban, hogy az összes magyar számlázó felhasználó keresse meg, ha nem ért valamit e kapcsán...

[KimmerGy]

Valamint:
A Fordított Áfás számláknál mi a helyzet ?
Nem kell beküldeni.
A számla befogadója az Áfa befizető.
Ő minősíti a számla tételeit ?
Ha igen akkor hogyan ?

[Rossi73]

NTCA-developer: "Jelenleg egy olyan _módszertani segédlet_ összeállításán (is) dolgozunk, amely segítségével a lineNatureIndicator kitöltése _algoritmizálható_ addig a szintig _ami nekünk elégséges,_"

Tehát, ha jól értem, nem a NAV fog algoritmizálni, hanem a számlázó programoknak kellene.

Elképzelni sem tudom, hogy mi lehet az a módszertani segédlet, amivel algoritmizálható egy olyan adathalmaz, amiről mi, fejlesztők semmit sem tudunk. Mivel a lehetséges számlatételeket, megnevezéseket, áfa kulcsokat, árakat, stb. mind-mind a felhasználók hozzák létre, ezért szerintem kivitelezhetetlen egy olyan algoritmus, ami be tudná lőni a megfelelő kategóriákat. De, lehet, hogy csak én vagyok túl szűk látókörű, és meg fogok lepődni. A mesterséges intelligencia ma már sok mindenre képes... :-)

Viszont én is támogatom, mint már többen is írták előttem: ha lesz egy algoritmus, akkor _a NAV alkalmazza_ az abban foglalt szabályokat, és ne nekünk, sok-sok-sok-sok órai munkával kelljen most megírni, majd, amikor a NAV "gondol egyet", módosítgatni...

Az általam javasolt megoldás:
Az eredeti felvetéssel egyetértve, a lineNatureIndicator megszüntetése, kivezetése az XSD-ből

[NTCA-developer]

Sziasztok!

Még mindig nem kaptunk választ a kérdéseinkre mi sem, a türelmeteket kérem, dolgozunk a megoldáson. Szerencsére bőven időben vagyunk, mert kb a hónap közepén kezdünk hozzá a 2.0-ás számla beküldés fejlesztéséhez, és még akkor is a funkció teljes vertikuma hátravan, bőven bele fog férni adott esetben az XSD változtatása is.

Jelentkezni fogok, amit van valami.

[pelach]

És nekünk mennyi időt adtok a fejlesztésre? Mert gondolom arra is kellene időt hagyni nem mikor kint az XSD elvárni, hogy egyből működjön mindenkinél...

[NTCA-developer]

Szia @pelach!

Úgy tudom fél év van betervezve onnantól hogy mi elkészültünk. Még semmi hivatalos, de nagyjából ez az irány.

[darmalost]

Online számla hivatalos oldal:
"A korábban jelzett 1.2-es és 1.3-as verziót nem adjuk ki, helyettük a 2.0-ás interfész verzió fogja leváltani az 1.1 XSD-t az éles környezetben 2020. január 1-től kezdődően. "

Na most ehhez képest:
"kb a hónap közepén kezdünk hozzá a 2.0-ás számla beküldés fejlesztéséhez"
"Úgy tudom fél év van betervezve onnantól hogy mi elkészültünk. Még semmi hivatalos, de nagyjából ez az irány."

Segítsetek számolni. Ha fél év van betervezve, akkor hogy fog elindulni január 1-től? Mondjuk én inkább a fél évet támogatom, mint a január 1-et, ha már lehet választani.

[NTCA-developer]

@darmalost

Nem tudom mire számítasz, de nem tudok többet hozzátenni mint amit írtam. Ha lehetne kérnem ne szórakoztassuk egymást felesleges kérdésekkel. Idővel megkapod a választ, hidd el.

[darmalost]

NTCA-developer:

1. Szerintem nem volt felesleges kérdés, hanem inkább költői.
2. A kérdést nem direkt neked szántam, hanem a többieknek, ezért is volt többesszámban fogalmazva.
3. Pelach is már megfogalmazta: mi onnantól tudunk elkezdeni fejleszteni, ha már minden végleges és nem változik folyton valami menet közben, ezért nekünk is kell időt hagyni.

Szummázom: A fél év és a január 1 üti egymást.

"Nem tudom mire számítasz"
Pl. egy olyan mondatra, hogy: "A jelenlegi állás szerint nem várható január 1-től indulás, ezért mindenki nyugodjon meg, kitaláljuk az XSD-vel hogy legyen, lefejlesztjük, és szép nyugisan, teszteléssel együtt lesz rá fél évetek bevezetni."

Nem kell válaszolni erre a bejegyzésemre, nem akarlak feleslegesen szórakoztatni.

[NTCA-developer]

Hidd el, szeretnék nektek ilyet írni, de ez nem egy one-man show, a NAV sem egy személyes szervezet. Itt vannak felhatalmazási kérdések. De véleményem szerint nagyjából így lesz, ahogy te is írod, szóval köszönöm. :)

[czbhu]

Igen, azért azt vegyétek figyelembe, hogy NTCA-developer is gondolom "csak" egy fejlesztő, vagy egy fejlesztő csapat "szóvivője". Ne legyetek vele ellenségesek, inkább próbáljunk meg ész érveket (habár ezt már szerintem elég jól megtettük) felhozni, hogy tolmácsolni tudja az illetékeseknek.
Tőle (NTCA-developer) meg azt kérnénk, hogy tájékoztasson minket a legapróbb fejleményekről (pl. "megvitatjuk, a .... véleményt") is, illetve őszintén nyilatkozzon, hogy ha ez a fórum tök felesleges, azaz hiába mondunk itt ész érveket, ha azt úgy sem veszitek figyelembe. Hidd el, elég lehangoló és lázító tud lenni, hogy ha a tiszta, logikus érveket, véleményezés nélkül diktatórikusan lesöpritek, mintha sose léteztek volna. Legalább egy-egy mondatot megérdemelnénk, hogy ez meg ez nem került bevezetésre, mert....
A pozitív elbírálást úgy is észrevesszük.
Szép világ lenne, ha a NAV a felhasználók véleményét figyelembe véve, logikusan fejlesztené a rendszerét. Kérdezhettek nyugodtan tőlünk a fórumon, az inkább erősebbé tesz Titeket, mint gyengébbé. Szerintem senki sem fogja azt gondolni, hogy "na a NAV ezt se tudja egyedül megoldani", sőt inkább azt, hogy "na a NAV milyen jó fej, userfriendly".

[NTCA-developer]

Szép világ lenne, ha a NAV a felhasználók véleményét figyelembe véve, logikusan fejlesztené a rendszerét. Kérdezhettek nyugodtan tőlünk a fórumon, az inkább erősebbé tesz Titeket, mint gyengébbé. Szerintem senki sem fogja azt gondolni, hogy "na a NAV ezt se tudja egyedül megoldani", sőt inkább azt, hogy "na a NAV milyen jó fej, userfriendly.

Köszönjük szépen, pont ezen dolgozunk és ez a fórum is pontosan ezért jött létre, jó sok munka árán. A GitHub egyáltalán nem felesleges, már önmagában csak azért is hasznos lenne, ha csak úgymond ütközőzóna volna közöttünk, ahol meg lehet a véleményeket osztani egymással.

Látok rá esélyt hogy közös nevezőre hozzuk ezt a kérdést is ahogy a mennyiségi egységek esetén történt. De ehhez nagyon sok eltérő igényen keresztül vezet az út. Tesszük a dolgunkat és meglátjuk mi lesz.

[btibiri]

NTCA-developer: "Látok rá esélyt hogy közös nevezőre hozzuk ezt a kérdést is ahogy a mennyiségi egységek esetén történt."

/off

A teljesség igénye nélkül(!) a mennyiségi egységnél kb. ennyi történik a számlázó programokban:

if ((s='DARAB') or (s='DB')) then s:='PIECE' else
if ((s='KG') or (s='KILO')) then s:='KILOGRAM' else
if ((s='NAP') or (s='DAY')) then s:='DAY' else
if ((s='M3') or (s='KOBM')) then s:='CUBIC_METER'
else s:='OWN';

Ezt a NAV online számla feldolgozó rendszer ugyanígy meg tudta volna tenni, ráadásul nálatok sokkal több minta áll rendelkezésre a gyakorlatban előforduló összes beküldött mennyiségi egységből.

Szóval a unitOfMeasure is teljesen feleslegesen most is, mivel a unitOfMeasureOwn mezőből ezt meg tudjátok állapítani.

/on

Nagyon jó lenne, tehát ha nem ez lenne a követendő példa és nem kapnánk több ilyen "kreált" mezőt, aminek tartalmát nekünk kell kalkulálgatni.

[NTCA-developer]

Sziasztok!

Flash news: ma megegyezés született, hogy a lineNatureIndicator - a felvetésetekkel összhangban - opcionális lesz a 2.0-ás sémában. Szeretnék majd többet írni róla, hogy elmondjam az érveitek közül melyeket tudtuk a legjobban felhasználni, és kicsit reflektálnék is a történtekre, de ez sajnos nem most lesz, mert nyakig úszok az interfész dokumentációban.

A héten adni fogok fel PR-t a séma változásokkal, de addig is akartam szólni nektek hogy tudjatok a történésről. Még jelentkezem.

[WittmannWien]

Remek hírek. Köszi szépen.

[NTCA-developer]

Sziasztok!

Ígértem visszajelzést. Azt hiszem kicsit hosszú leszek. Kezdem a konkrétumokkal, és utána kicsit másról is szeretnék írni.

Az Online Számla rendszer a mérete és komplexitása okán adózási szempontból több szakmai területen átível. Ebből fakadóan több szakmai terület fogalmaz meg vele kapcsolatosan szakmai igényeket, elvárásokat. Ez teljesen természetes folyamat, a business concept így halad előre minden szervezet esetében és a NAV sem kivétel ez alól.

A korábbi DEV diary bejegyzésekben már írtunk arról a transzparenciáról, amit ebben a projektben el szeretnénk érni. Ez kiterjed arra az esetre is ha projekt szinten hibázunk, ezt is tudni kell exponálni. Ennek jegyében ki lehet mondani azt, hogy lineNatureIndicator esetében egy tévesen gondolt szakmai álláspont vezetett a tag kötelezővé tételhez, aki pedig ezt a kötelezőséget kifogásolta, annak igaza volt.

Fejlesztőként minden új igénynél igyekszünk megvizsgálni kért módosítást, például hogy az mennyire koherens a rendszer többi funkciójával, hogyan és miként lehet bekérni, kezelni, feldolgozni, az adatmodellbe illeszteni és még sorolhatnám. Valójában pontosan azt tesszük, amit minden más fejlesztő is ilyenkor, segítünk a megrendelőnek egységesen és rendszerben gondolkodni, hogy az általa elérni kívánt célt hogyan lehet a legjobban, IT szakmai szempontok szerint helyesen megvalósítani. Természetesen van amikor egy igény megvalósítása esetén van mozgástér, és van amikor ez nincs. Első körben úgy tűnt, hogy a lineNatureIndicator által hordozott adatra mindenképpen szükség lesz.

Azon érvek közül, amiket kaptunk tőletek kettőt tudtunk nagyon jó hatásfokkal felhasználni:

• egyszer, aki nem törzsből számláz, ott a kézi bevitel miatt a felhasználóra túlságosan nagy terhet ró a tag kitöltése és az értékének helyes meghatározása
• másszor, a klasszikus aránytalansági elv, mi szerint szabályozási szempontból nézve a mező kötelezőként való előírása és az abból származó haszon aránytalan ráfordítással jár

Ezen két érv vezetett végül ahhoz a felismeréshez, hogy az elérni kívánt célhoz nincs elengedhetetlenül szükség a lineNatureIndicator tagre. Annyiban mindenképpen van haszna, hogy aki számára ez fontos információ, akkor ennek a 2.0-ban már van egy intézményesített helye, nem kell megegyezés alapján az additionalInfo tagek közül kibogarászni. De akinek erre nincs szüksége, annak a taget egyáltalán nem kell használnia.

Ennyit a konkrét kérdésről. Szeretnék még kicsit írni a visszajelzésekről, amiket adtatok. Mi úgy látjuk, hogy a közös kommunikációban még tudnánk javulni. Attól hogy észérveket is belekevertek egy hozzászólásba, ami egyébként semmi másról nem szól mint öncélú indulatokról, a közvetített tartalom ettől még csak az indulat marad. (ez főszabályként nem is a githubos hozzászólásokra vonatkozik, bár a puskaporszag itt is érződött néhol) Azon kívül hogy ez senkinek sem használ, még hátráltatja is az együtt gondolkodást. Úgy gondoljuk, hogy már többször is tanúbizonyságát tettük annak, hogy meghallgatjuk az ellenvéleményeket is (és ha még szakmailag helyesek is, akkor meg is változtatjuk az álláspontunkat), ezért teljesen felesleges az első kritikai ingerre leakasztani a szögről a géppuskát. A magunk részéről nagyon örülünk, hogy van a rendszer felett egyfajta külső kontroll, ettől csak jobb lesz a végeredmény, és nekünk ez a legfontosabb.

Summázva a fentieket, köszönet mindenkinek aki kapacitálta magát arra, hogy időt és energiát szánjon a témára és megfogalmazza az aggályait. A ticketet még nyitva hagyom most hét péntekig, hogy aki esetleg még szeretne -szigorúan puskapormentesen- reagálni a témára az megtehesse.

[czbhu]

Köszönjük a tájékoztatást!
A puskapor talán azért volt, mert érvelhettünk, de nem kaptunk érdemi választ.
Így, hogy van valami kommunikáció, szerintem jöhetnek az értelmes szakmai viták, felvetések is.
szép napot mindenkinek!

[vajayattila]

A puskaporos levegőn nem érdemes nagyon csodálkozni. Ha valakinek a micsodájával püfölöd a csalánt, ne várd, hogy jó képet vágjon hozzá.
Mindenesetre emberi és szakmai nagyvonalúságra utal, hogy képesek voltatok átgondolni az ellenérveket és módosítani az elképzeléseteken. Ez szerintem mindenképpen jövőbe mutató hozzáállás. Részemről nagy piros pötty.

[Rossi73]

@NTCA-developer: _"Jelenleg egy olyan módszertani segédlet összeállításán (is) dolgozunk, amely segítségével a lineNatureIndicator kitöltése algoritmizálható addig a szintig ami nekünk elégséges, ezért lehetséges hogy nagyon csak az egyik oldalát látjátok a kérdésnek."_

Most, hogy a NAV részéről elvetettétek a lineNatureindicator kötelező kitöltését, a segédletet ettől függetlenül elkészítitek, ami segít az algoritmizálásban annak, aki kitöltené ezt a mezőt? Nem magam miatt kérdezem, hanem, mivel az elem maradt, csak nem kötelező, ezért nyilván a kitöltésének ott és akkor van értelme, ha ebben olyan adatokat kap a NAV, amilyet szeretne.

[NTCA-developer]

Szia @Rossi73

Az ANCILLARY-s értékekre tudtunk volna adni determinisztikus megoldást, de azok - szintén irrelevancia miatt - kikerültek az értékkészletből ugyan abban a körben, amikor az OTHER belépett. A társterület arra jutott, hogy a fő kérdés (termék vs szolgáltatás) nem dönthető el minden esetben emberi beavatkozás nélkül. Az IF doksi 2.3.17 pontja írja le a lineNatureIndicatort, de az ANCILLARY kiesése után már csak a módszertani ajánlások, példák maradtak abban a leírásban is. Úgyhogy sajnos ilyen leírással nem szolgálhatunk, de a kérdésed jogos volt.