NAV-figyelmeztetés: összeférhetetlen a nyomtatványkitöltővel az új JAVA

HUP cikkturkáló

"Nem kompatibilis a 2017. szeptember 21-én kiadott, Oracle új JAVA (Java SE 9, platform JDK, JRE) verziója a jelenlegi ÁNYK programmal (v2.77) – figyelmeztet honlapján a Nemzeti Adó- és Vámhivatal (NAV).

Az ÁNYK program működéséhez továbbra is a korábbi JAVA (Java Run Time (JRE) környezet 1.8-as) verzió szükséges, így a NAV azt javasolja, hogy a módosított ÁNYK keretprogram publikálásáig ne telepítsék a felhasználók a JAVA 9-es verziót.

Amennyiben valaki már frissítette a JAVA környezetét, akkor távolítsa el azt a gépéről, és térjen vissza az 1.8-as Java (JRE) környezethez."

Szósz:http://adozona.hu/adozas_rendje/NAVfigyelmeztetes_osszeferhetetlen_az_u…

  • 18994 megtekintés

( bandy | 2017. 09. 25., h – 16:07 )

Olyan hirtelen adták ki az új JAVA-t hogy nem volt idejük felkészülni

Én ányktól függetlenül bizonytalan vagyok, mi legyen az 1.9-el. Eléggé meglep hogy már annyian telepítették hogy egész nap csörög a telefon hogy nem megy az ányk.

A java.com -ról még mindig az 1.8 telepíthető. Ahol adminisztrálok, erről az oldalról telepítenek. A java.oracle.com-on nem találom a JRE 32 bites változatát, az oracle nem is fogja kiadni? Van a látókörömben még win7 32 bites, jó lenne ha a java miatt nem kellene OS-t cserélni, nem is igen lehetne.

OpenJDK JDK 9 GA releaset csak linux 64 bitest látok, azt írják más platformok majd valamikor később jönnek. Nem írják mikor. JRE-t nem is látom. A linuxos openjdk installer bináris láthatóan nem ugyanaz mint az oracletől letöltött. Legalább van a fájlnévben build szám, egyből 181, de az oracle release ennyit sem ad meg.

Most nézem, nálam az 1.8 control panelen az update fülön sem ajánlja fel az 1.9 upgradet, hanem azt mondja hogy az 1.8 u144-et az ajánlott verziót használom.

Nem lesz 32 bites később sem? Látok nap mint nap ügyfeleknél laptopot/desktopot amin 32 bites windows van. Remélem az 1.8 is marad még sokáig, az is fájó volt hogy az xpket kiszóratták, értem az indokokat de sok helyen pont megfelelt. Remélem jönnek laptop beszerzés pályázatok, nyáron is volt, egy ügyfél sikeresen tudott is fejleszteni.

Az Oracle-s linkek egyik sem jre és 32bites nincs köztük. Ezeket így sztem semelyik automatikus frissítés nem fogja leszedni. Igen, lehetett volna tesztelni, de eddig még sosem volt komoly gond, ez az első, hogy nem is indul el az ányk. Ebben igazad van, ez tényleg hiba. Eddig maga a program tudta magát frissíteni. Ezért a figyelmeztetés a NAV oldalán.

Tisztában vagyok vele, de nem egyről beszélünk. Én azt hiányolom, hogy nincsen kint a 32 bites 1.9 jre, egyébként is egy fos a letölések oldal, a java.com és a updater szerint meg a legfrissebb verziót használom (1.8u144). Nem az a bajom hogy most egyelőre az 1.9 nyelvi verziót megvalósító jvm ÁLLÍTÓLAG nem futtatja az ÁNYK-t. Bár vilmos.nagy hozászólása szerint fut. De nem ez érdekel, ezt megoldják ha jól értem minimális módosításokat kell tenni sok évvel ezelőtti kódokban, nem érdekes. De itt valahol felemerült hogy elvetették az 1.9-ben a 32 bites architektúrát? Hát erről nem volt szó

https://web.archive.org/web/20170913215655/http://jdk.java.net/9/suppor…

https://docs.oracle.com/javase/9/install/installation-jdk-and-jre-micro…

https://web.archive.org/web/20170710132851/http://jdk.java.net/9/

Lehet osztani az észt, és meglepőket mondani.

Nem is fogja. A java update tool szerencsére (legalábbis tapasztalatok szerint) úgy van kitalálva, hogy ha pl 7-es java-d van akkor annak a leguccsó frissítését keresi, ha 8as, annak, stb. Verzió váltásokat nem ugrik. Legalábbis ilyet én még nem láttam.

Ezzel valahol a komment tömegben igazat is adok, hogy nem lehet "csak úgy" java9re frissíteni. Céges policy ide vagy oda. Magán szféra ide vagy oda. Java6 Java6 frissítést keres, a Java7 Java7 frissítést keres.. stb.. Nem fog verziót ugrani az autoupdate. ez 99%.

LoL.

Egyrészt, a fél Oracle-ös Java csapat azon standuplot az elmúlt egy évben, hogy vannak EA buildek, tessék elkezdeni tesztelni!

Másrészt hányszor láttunk olyat (nemállami környezetben), hogy:
- nincs a fosZTEmre friss Android, nem tudtam tesztelni, dögöljmeg!
- ugyanez iOSszel
- frissült a böngésző, el sem indul semmi, állj vissza!
- etc.

valamiért csak az állami szférában engedheti meg magának valaki ezt...
--
blogom

> A NAV szólt előre, h. ne telepítsék
ezt nem engedheti meg magának senki.

Kérlek linkelj már olyat a nem-állami szférából, hogy:
- ne frissítsem a mobil OS-emet (ugyanúgy egy dinamikusan, alkalmazástól függő frameworköt hoz)
- ne frissítsem a Google Play Services-t (szintúgy!)
- ne frissítsem a böngészőmet
- etc.

A legutolsó emlékem trey blogjából ugyancsak valami állami tréség, ami a friss Firefoxra sírt...
--
blogom

Hát így hirtelen:
http://hvg.hu/tudomany/20150410_nehogy_frissitse_az_iphonejat
http://hvg.hu/tudomany/20140818_fontos_ne_frissitse_a_windowst

Kis formátumú vacak kis garázscégek, de azért velük is megesik.

De nem egyről beszélünk. Még 1x mondom a java nem frissíti automatikusan magát a 9-re. A figyelmeztetés azoknak szólt akik már alig várták, h. végre feltehessék az 1.9-es javát. Nyilván a könyvelők nagy többsége ilyen. Ráadásul csak annyi kényelmetlenség lenne az ányk frissítésével, h. újra föl kellene menni a nav oldalára és letölteni. Ezt megelőzendő van a közlemény.

> Hát így hirtelen:
Ez azért erősen almát a körtével eset...
De igen, a mondatot ki lehet ragadni a kontextusából, s akkor ezek valid példák.

Szándékosan-félreérthető-mentesen megfogalmazva:
Kérlek linkelj már olyat a nem-állami szférából, hogy:
- (...)
, mert egy, a keretrendszer használó program nem készült fel az új verzióra

Az, hogy egy előre bejelentett, nem dokumentált featureökre támaszkodó tákolmányt nem készítenek fel a hónapok óta várható friss framework-re. Ott erősen el lett baszva valami.

És ne mentegessük a fejlesztőcéget/megrendelőt ennek a problémának az elkenésére. Főleg, ha az én pénzemből tákolják ezt a szart.

szerk.:
> Még 1x mondom a java nem frissíti automatikusan magát a 9-re. A figyelmeztetés azoknak szólt akik már alig várták, h. végre feltehessék az 1.9-es javát.
Ha egyszer azt választották, hogy nem csomagolnak hozzá egy JRE-t, akkor tessék ennek a következményeit viselni, s csak dokumentált Java dolgokat használni. Lehetett volna mellécsomagolni.

> Ráadásul csak annyi kényelmetlenség lenne az ányk frissítésével, h. újra föl kellene menni a nav oldalára és letölteni.
wut? Én most töltöttem le a NAV oldaláról az ÁNYK-t, s az verzióban stimmel azzal, ami nem megy a java kilenccel.
Ha jól sejtem, a NAV szerint most (legalább ma ebben a pár órában*) van egy támogatott java - támogatott ÁNYK nem megy felállás. Ejj.

* nyilván, ha csak pár óra lenne, akkor nem közleményt adnának ki öt nappal a GA után, hanem javítást...
--
blogom

Igazad van! Sz@r az egész, vacak. 9 éve porosodik, nem is használja senki. Emellett számos fejlesztő cég mozdult rá a piaci résre, h. ehelyett a te adódból gányolt 'nemistudommi helyett 1 sokkal jobb alkalmazást készítsenek.

Egyébként a közlemény előbb ment ki, mint a kiadás. A javítás készen van, tesztelik. A sun... csomagok pedig dokumentáltak és nem nevezném tákolmánynak őket.

"A sun... csomagok pedig dokumentáltak "
Igen? Hol?
Itt: http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html
"The sun.* packages are not part of the supported, public interface.
A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform."

De hát tudjuk, a fejlesztők okosabbak, mint a Java SE specifikálói.

Nem az API a fő gond szerintem, hanem az ÁNYK koncepciója.

Konkrétan ha megnézitek a formok formátumát, akkor látszik, hogy a canvas pozíciók vannak megadva benne, ahova a saját custom widgeteket kell kirakni. És természetesen nem önleíró formátum, hiába XML, mivel az egyes mezők dokumentációja (és labelje) nem a mezőhöz van kötve, hanem a mező mellé egy tök független widgettel van kirakva.

Ez szerintem amiatt van így, mert valamikor, amikor ezt az egészet elkezdték, volt a helyi fontos embernek egy olyan követelménye, hogy a "digitális" formnak ugyanúgy kell kinéznie, mint a régi papír alapúnak. Ebből ez a (hogy finoman fogalmazzak) "naív" implementáció egyenes úton következik.

Ha valaki ehelyett saját kitöltőt akar csinálni, akkor gyakorlatilag ugyanezt az agyrém rendering engine-t le kell implementálnia, vagy kézzel minden egyes formot értelmes formára kell hoznia (ami viszont felveti a felelősség kérdését, ha hiba kerül a konvertált formba).

Ne legyenek illúzióid... :)

...nem láttál még olyan email-t, aminek a végére odaírták, hogy lehetőleg ne nyomtasd ki? Na, ez azért volt... mostanában már kezdenek leszokni róla, valószínűleg kikopott az a vezetői réteg, aki még az írógépes Mancikán és a tárcsás telefonon szocializálódott és soha nem értette igazán a számítógépet. :)

Mire gondolsz? Az ÁNYK plaintext formátumban tárolja a nyomtatványba beírt adatokat, ezt pedig simán elő lehet állítani 3rd party alkalmazásban is – azaz egy cégen belül elég lehet akár 1 db működő ÁNYK.

Kellően elvetemült emberek akár egyedi kitöltőszoftvert is készíthetnek, elég, ha a könyvelő telepíti magának a alkalmazást.

Offtopik: érdekes módon a digitális analfabéta ismerőseimnek is sikerül feltelepíteni az ÁNYK-t, ez inkább a hup közönségének szokott problémát okozni. :)
Lehetne jobban csinálni? Igen. Használható a mostani állapotában? Szintén igen.

Most látom, hogy te tényleg az ÁNYK-n dolgozol :).

Ebben a hozzászólásban leírtam, hogy miért nem triviális kiváltani az ÁNYK-t egy saját megoldással:

https://hup.hu/node/155506?comments_per_page=9999#comment-2144875

Nagyon érdekelne, hogy egyrészt miért így csináltátok meg (a papír - kompatibilitás nem jó indok, mert attól még lehetne önleíró a formátum), másrészt van-e terv arra, hogy ezt a nyilvánvalóan szükségtelen vendor lock-int megszüntessétek? Nektek is jobb lenne, ha lenne egy publikus API, amire mindenki rá tudja integrálni a saját könyvelőrendszerét.

Az is érdekelne, amit a másik fórumtárs felvetett, hogy miért nem modernizáljátok a felhasználói felületet.

A webes szja bevallás UI szempontból OK, viszont az üzleti logikán még van mit csiszolni, nekem pl. elrontotta a bevallást, pedig semmi bonyolult nem volt benne.

Amikor elkezdődött az ányk fejlesztése már volt használatban egy delphi-s nyomtatványkitöltő ABEV néven. Az APEH-nek akkor már volt forgalomban 1 csomó nyomtatványa és elég sokan használták is. 3 fontos szempont volt: tudja használni a korábbi sablonokat és adatállományokat (ha hiszed ha nem, máig be lehetne importálni az abev állományait), a menüje a lehető legjobban hasonlítson az abevre (az ikonok is onnan valók) és legyen platformfüggetlen. Emlékszem még volt olyan állapot, amiben lehetett "skint" váltani, mert azért nekünk is van ízlésünk :) De aztán ez kikerült belőle. Szóval tipikusan igaz, h. történelmileg így alakult ki. Az hogy pl. egy mezőnek nincs promptja, hanem gyakorlatilag független cimke van hozzá rengeteg gondot okozott a fejlesztésben, sokkal 1xűbb lett volna máshogy, de ez volt és kész. Vagy egy másik dolog. A külső xml formátum. Ezerszer módosítani kellett volna, de nem szabad. Rengetegen állítanak elő programozottan xmleket amit tolnak az ányk-ba és ellenőrzik, küldik be vele.
Az hogy mit hoz a jövő nem tudom. Ez az ellenőrző api lehet, h. egyszer még napirendre kerül. A felhasználói felület meg ahogy én látom nem prioritás. Nem tudom a profi felhasználókat (könyvelőket) zavarja-e, szerintem nem, mert akkor már keresztül vitték volna a változtatást. Az évi egyszeri - szja - bevallóknak meg szerintem a NAV részéről inkább az webes kitöltő a fontos. Arra szeretnék terelni a felhasználókat. Ez érthető, hiszen az ajánlaton és magán a kitöltőn is nagyon sokat dolgoztunk/dolgoztak. Szerintem egyébként, aki beleesik a hatálya alá nincs annál egyszerűbb. Mégis csak kevesen regisztrálnak az ÜK-n, h. használhassák.

De ezek csak az én gondolataim, nem látok rá a dolgokra. Mi igazából nem tervezünk soha fejlesztést - amit megrendelnek azt csináljuk meg.

Ezt az elrontotta dolgot nem igazán értem. Nem kéne hibáznia. De elárulom pl. h. az én ajánlatom is hibás volt (a hibásat úgy értem, h. nem úgy kellett volna kitölteni) de ott kiderült pl., h. a bankom rossz forrás adatot küldött be. Szóval, hogy hibás bevallást gyártottunk volna - ez elég nagy baj.

"Mégis csak kevesen regisztrálnak az ÜK-n, h. használhassák."

Csak par szosszenet hogy ezt mik "segitik" elo.
Elso fejezet: Par honapja felmerult bennem lehet jo lenne kerni ugyfelkapu hozzaferest, mondom gugli ugyfelkapu regisztracio, elso talalat https://ugyfelkapu.magyarorszag.hu/regisztracio , mondom oke, regi szemelyim van (mint ahogy meg szerintem sokaknak, hisz nincs 2 eve hogy bejott az uj fajta) igy marad az idopontfoglalas, kivalasztom milyen ugyben meg budapest es elso meglepetes hogy osszesen 6 helyszint hoz fel erre, de mondom biztos ilyen sokan akarnak regisztralni. Sebaj valasztok egyet azokbol, ekkor jon a masodik meglepetes hogy azt mondja ezen a heten mar nincs szabad idopont, valasszak masik hetet, vegigkattingatok elore vagy 6 hetet (mert tobbet nem enged) es ugyanaz az uzenet mindig, oke akkor nezzunk masik helyszint de pofara kell esni mert mindegyiknel ez volt, nem volt opcio arra egy ugyfelkapus regisztraciohoz online foglaljak egy idopontot Budapesten. Mondom akkor mindegy, ugyis jovore lejar a szemelyi, adnak uj fajtat es akkor vagy megigenylem akkor vagy utana tudok online is kerni majd.
Masodik fejezet: Voltak hirek arrol mult heten hogy konvektor tamogas igenyles ugyfelkapuval, hat mondom megnezem megint ezt az ugyfelkapu regisztraciot, tortenet akkor is ugyanaz mint elso fejezetben, de mondom megnezem mar hogy uj szemelyi igenylesre tudnek-e idopontot foglalni vagy mennyire elore kell (megha ugyse lett volna meg konvektor palyazat lejarata elott, csak kivancsisagbol), rakeresve megint kikotok az https://ugyintezes.magyarorszag.hu/okmanyiroda/idopontfoglalas oldalon, kivalasztom szemelyi csere, keruletemben egyik okmanyiroda, erre kozli hogy ho-ho az mar masodik generacios fajta, atiranyit masik oldalra konkretabban a https://idopontfoglalo.kh.gov.hu -ra (kiegeszitve a mar kivalasztott okmanyiroda azonositojaval). Mondom bejelentkezes tovabbra is ugyfelkapu nelkul, erre 1 opciot hoz fel, hogy ugyfelkapu regisztracio. Hat mondom no fene, masik oldal miert nem mutatja hogy itt is lehetne ilyet, meg itt miert csak arra lehet idopontot foglalni, meg ha mar itt is lehet idopontot foglalni akkor hogyhogy itt csomo szabad idopont is feljon, mig masik oldalon meg utalas sincs arra hogy lehet probalkozz meg az uj fajta idopontfoglalassal, hatha ott talalsz helyet, vagy ha mar ennyi szabad idopont van akkor miert nem lehet idopontot foglalni mas ugyre is ugyfelkapu nelkul, most akkor kerhetek idpontot ugyfelkapura, majd ha az meglett kerhetek masik idpontot szemelyire, netan vannak olyan rendesek elintezik mindkettot egyszerre?
Ezzel csak azt akarom mondani, hogy nem csak az hianyzik hogy koztudatba be lenne vezetve mik lehetnek a hasznai egy ugyfelkapu regisztracionak (thread-et olvasva sokaktol ez jon le, koztuk magamat is beleertve) es igy rohannanak a tomegek elintezni, de azzal sincs megkonnyitve hogy legalabb jo tajekoztatas lenne az igenyles meneterol (aztan ha mar van neki talan be tud lepni vele es fogja latni vagy ott szajbaragni hogy mit es hogy tud csinalni vele) vagy egyertelmuen lenne feltuntetve hivatalos oldalakon.

Szerintem nem jó kormányablakokat néztél, vagy nem tudom. Így élből, pl. a 17. kerületbe már hétfőn reggel mehetnél, meg úgy ez egész hét üres, de még a 9-be a tescóba is lehet akár hétfőn menni, stb.

Meg vagy 28 kormányablakoz hoz Budapesten: https://idopontfoglalo.kh.gov.hu/kormanyablak-valasztas#budapest

Neked nem sikerült a weboldalon írtakat megérteni: "A személyes ügyfélkapus azonosító létrehozása egy regisztrációs eljárás, amelyet az ügyfél kezdeményezhet a regisztrációs szervnél (bármelyik okmányirodában, kormányhivatali ügyfélszolgálati irodában, adóhatóság ügyfélszolgálatán vagy külképviseleten)"
A fentiek közül bármelyikbe besétálsz és elintézed. (A Gvadányi úti NAV ügyfélszolgálaton januárban kemény 4 percet kellett várnom egy hétköznap délután.)

Mit nem ertek abban, ha ott van hogy idopont foglalas az ugyintezesre online feluleten es azt szeretnem, de nem lehet mert nincs szabad idopont, vagyis csak szerinte mert hibas a tajekoztatas?
Nem azt mondtam hogy online akarom elintezni hogy legyen ugyfelkapum, csak egy idopontot akartam volna ra foglalni, amire nem telefonszam van megadva hanem egy nyamvadt online felulet, eleve azt fogom megprobalna a nap barmelyik szakaban hogy ott kerek egy szamomra idealis idopontot, nem pedig hogy besetalok valahova ahol ki tudja mikorra adnak egy idopontot hogy egy masik napon menjek vissza vagy azt a napot toltsem el ott a varakozassal.
Nem mindenki annyira raeros hogy na akkor en szerdan bemegyek elintezni, lehet negyed ora lesz, lehet ott ulok fel napot mire sorra kerulok, vagy akar azt mondjak 5 perc utan hogy jojjek vissza ket het mulva csutortok delutan 2-re.

Mondom, hogy nem érted: besétálsz, húzol egy sorszámot, és ha szólítanak, 2 perc múlva van ügyfélkapud.
De ha ráér valamire hónapokig várni, hogy majd egyszer találsz egy szabad időpontot az online felületen, ahol valamilyen okból kifolyólag max. negyed- (de van, hogy fél-) órás intervallumokra osztanak be ügyfeleket, akkor is, ha kétperces műveletről van szó, akkor ne panaszkodj, hogy nincs időd arra, hogy akár egy órát is várhatsz, ha időpont nélkül sétálsz be. Egyszerűen nem volt fontos, és most megindoklod, hogy az idióta időpontfoglalós rendszer miatt nem csináltattad meg.
Nekem fontos volt, besétáltam a NAV-hoz, felkészülve három napi hideg élelemmel, aztán tényleg, leülni nem volt időm, és már hívtak is.

Nem panaszkodni akarok, hanem ravilagitani a lenyegre, hogy ez is lehet egyik oka amiert sokaknak nincs. Az emberek tobbsegenek nem fontos hogy legyen ugyfelkapuja, mert nem kotelezi oket erre semmi es sokan azt se tudjak mit lehet vele kezdeni. Ezen felul benne van a tobbsegukben ahogy te is ugy indultal neki, hogy ugyintezes egy hosszu folyamat, nem 10 percet fogsz ott tolteni, akkor pedig ha mar lehet megprobalna az ember egy idopontot foglalni, egyreszt hogy ne varjon addig ott, masreszt hogy ne hiaba menjen (regebben jartam ugy csak besetalltam okmanyirodaba reggel es kozoltek hogy ma mar ugyse kerulok sorra, menjek vissza holnap).
Ha pedig egy idopont foglalasra azt javasolja hogy online igenyeljem akkor elvarhato lenne hogy ott egyertelmu es pontos infok legyenek, nem pedig egy elavult oldal amibol annyi latszik csak par helyen lehet ilyet intezni es azokban sincs szabad hely (nyilvan azert nincs ott szabad hely, mert sokan masok megtalaljak azt az oldalt es ott foglalnak), ez pedig elveszi a kedvet azoknak akik igenyelni akarnanak de valoban nem kritikus nekik, igy hatraltatva hogy gyorsan elterjedjen.

A szál arról szól, hogy az embereknek általánosságban miért jó, vagv miért problémás az ügyfélkapu regisztráció, illetve Blackluck azon gondolatmenetére reagáltam, hogy sokaknak miért nincs, vagy miért nincs szüksége rá. Hogy jön ehhez, amit írtál?

Rosszul tartod!

Ugyfelkaput ugy celszeru csinaltatni, hogy amikor barmilyen ugyben arra (kormanyablaknal) jarsz, akkor megemlited, hogy egyebkent ezt is szeretnel, es max. 5 perccel tovabb tart az ugyintezes.

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

"hogy amikor barmilyen ugyben arra (kormanyablaknal) jarsz"
kb 7 eve voltam utoljara lakcim valtozast intezni, akkor orultem hogy szerencsere kevesen voltak kora reggel igy hamar sorra kerultem, beertem idoben munkahelyre annelkul hogy magyarazkodni kellett volna. Nem az volt az elsodleges, de eszemben se volt hogy rakerdezzek ugyfelkaput lehet-e igenyelni vagy arra huzzak uj sorszamot mert masik ablak, egyaltalan az 5 perc vagy fel ora.

Az ügyfélkapu valamikor jó volt. Sikerült elrontani azt is. Belépsz az anno megigényelt felhasználó/jelszó párosoddal (amit az okmányirodán papír formátumban őriznek is!) és amint valamit csinálni akarsz, megjelenik az azonosítási ügynök és kér egy felhasználó/jelszó párost. Basszus! Ráadásul nem azt, amit az okmányirodán igényeltél, legalábbis nálam nem. Én azóta nem használom, hogy ez az ügynökösdi települt. 

Nekem a lecserélt, legfrissebb jelszót fogadta el a kaü - illetve amióta van e-személyim meg kártyaolvasóm, azt használom bejelentkezésre - azzal még nem volt problémám - sőt, logout+a kárta kivétele után a session sem "ragadt bent" a böngészőben.

Utánam csinálnád a következőket:

magyarorszag.hu belépés -> ügyfélkapu belépés  -> gate.gov.hu/sso -> magyarorszag.hu

Tárhely adminisztráció -> tarhely.gov.hu -> kau.gov.hu/proxy/saml -> KAÜ belépés -> Ügyfélkapu név és jelszó újra -> idp.gov.hu/idp/saml -> tarhely.gov.hu

a, tarhely.gov.hu kijelentkezés -> mo.hu belépve marad

b, magyarorszag.hu kilépés -> gate.gov.hu/sso/ap/logout -> magyarorszag.hu kilépve -> tarhely.gov.hu belépve maradsz.

Megpróbálhatod elmagyarázni, hogy ez milyen fasza SSO működés és hogy a magyar állami SSO több különálló SSO, de szerintem te is érezni fogod közben, hogy ez így miért faszság. Egyszerűen ez így fos és ha bármelyik szolgáltató így működne, akkor tele lenne kiabálva minden szakmai fórum azzal, hogy ez így mekkora biztonsági rés az, hogy egy SSO bekéri többször is ugyanazt a credential-t és kilépésnél nem léptet ki mindenhonnan.

https://iotguru.cloud

Csak tipp, de gondolom azért nem globális logout történik, mert több a különböző szolgáltatás/alkalmazás gazda van, és nem diktálhatják neked, hogy minden (más) szolgáltatás használatát is fejezd be, ha tőlük kilépsz - ellentétben a Google, Facebook vagy más szolgáltatóval.

Hogy miért kell többször authentikálni: az valami zavar/hiba lehet a rendszerben?

Azért SSO, hogy ha kilépek, akkor az összes *.gov.hu lépjen ki, különben nem SSO, hanem mindössze különálló rendszerek azonos realm-ból való authentikációja. Ha az én rendszerem Google SSO-t használ, akkor bizony ki lesz a user léptetve tőlem is, ha bárhonnan kilép. Mert SSO. Ez a dolga.

De felőlem lehet az is, hogy ne lépjen ki, de akkor legyen következetes, a valóság viszont az, hogy több realm van, amelyek kicsit átfedik egymást és részben más credential van használva, amelyek időnként nem kerülnek szinkronba.

Hogy miért kell többször authentikálni: az valami zavar/hiba lehet a rendszerben?

Ez az üzemszerű működés. A zavar és a hiba ott van, hogy irdatlan nagy káosz van, mindenki kiskakas akar lenni a saját szemétdombján és mivel ráadásul nem is szabványosak az SSO megoldások, ezért nem lehet egyszerűen integrálni vagy implementálni azt dobozos termékekbe, ezért nem mindenki vállalja be, csak ha nagyon szükséges (és kerül rá pénz valahonnan) vagy ha amúgy is nulláról írnak egy egyedi rendszert.

https://iotguru.cloud

"Pontosan mit is engedhet magának az állami szférában valaki?"
Azt, hogy nem készül fel arra, hogy az ügyfelek Java 9-et fognak használni, mikor az Oracle már kb. két éve felhívta a figyelmet rá, hogy lehet tesztelni a Java 9-es feature-öket.

Attól, hogy nincs automatikus Java 1.9 frissítés Java updaterrel, attól még akár egy cégnél is, policyból fel lehet tenni a Java 9-et.
"Szereztek egyet valahonnan"
Mármint az Oracle hivatalos kiadási oldala az a valahonnan?

Hadd tippeljek amúgy: ÁNYK fejlesztő vagy? :D

Igen, eleve így regeltem 9 év 37 hete :) Basszus, de rég volt. Azt hiszem óriási aránytévesztésben vagytok itt. Persze ki lehet forgatni a szavakat, de mindketten tudjuk, hogy mire gondoltam a valahonnan-nal. Aki otthonról, könyvelőként használja az ányk-t az a legtöbbször csak az auto dolgokat csinálja meg. Ha nem "szól" neki a java akkor nem frissít. Céges policy-t nem hiszem hogy ilyen módú java-s telepítésre alapozzanak, de persze elképzelhető. Akik utána mennek pl. az új 32 bites jre-nek - szakemberek, "szuperjúzerek" - azoknak nem hiszem, hogy gond lehet beállítani a 8-as jre-t az ányk-nak. (Már ha akar vele dolgozni és adott esetben pénzt keresni) Nem tudok egyébként komoly fennakadásról. Érdeklődők voltak inkább + 1 szervezet jelezte, h. tesztelés közben belefutott. Szóval vihar ez a biliben, de tudom bénák vagyunk, összecsaptuk, szar az egész :)
A webes szja-ról persze kevesebb szó esik - vagy az nem szar? ;)

Az aránytévesztésről annyit, hogy nektek lenne feladatotok a kompatibilitás biztosítása, és nem a felhasználókat kéne hülyének nézni.
Ez az aránytévesztés. A program van afelhasználóért, nem a felhasználók a programért. Ez az aránytévesztés.

A webes SZJA-val nincs is nagyobb gond. A vihar a biliben az, hogy ezt a szofvert közel 10 éve készítitek, és nem volt észben az, hogy bazmeg, nem kéne properietary, nem dokumentált API-t használni, mert ez még visszaüthet. Vissza is ütött, és persze ilyenkor is a userek a hülyék. Na ne már bazmeg. Ez az aránytévesztés.

Nem! Az aránytévesztés az, amikor milliós felhasználói körből néhány 10 embert érintő késedelem miatt bazmegelsz nekem.
Ki néz hülyének kit? Kiment a figyelmeztetés, mert nem készült el a frissítés, ráadásul pechünk volt mert az induláskor használtunk olyan kódot, ami 10 év után kikerült a java-ból. Ez tényleg égbekiáltó! Azt kívánom, hogy ennél soha nagyobb hibát ne kövess el egyetlen projektedben sem. Az miből jött le, h. a userek hülyék?

"ráadásul pechünk volt mert az induláskor használtunk olyan kódot, ami 10 év után kikerült a java-ból"

Nézd, pont 10 év volt rá, hogy kiszedjétek az összes olyan dirty hack típusú megoldást, amiről már 10 éve közismert, hogy dirty hack... most meg már muszáj lesz. :)

> Azt hiszem óriási aránytévesztésben vagytok itt.
várjál már, most én érezzem magam megtiszteltetve, hogy létezik az ÁNYK?

> de tudom bénák vagyunk
ilyet én nem mondtam, de szerintem itt senki se. az állami projekteknek megvannak a különböző rákfenéi...
de azt azért hadd említsük már meg, hogy ez a megoldás így szar.

(Főleg, hogy évek óta lehetett tudni, hogy a Java 9 jön!)

szerk.: najó, tévedtem, a persicsb által említett nem dokumentált API-k használata tényleg gáz.
--
blogom

Én momentán egyet értek veled Java 9 témában, tényleg vihar a biliben, még ha okádék is a szoftveres megoldás, ami miatt van.

De ha már témánál vagyunk, régóta foglalkoztat az a kérdés, hogy miért olyan ótvar, okádék az ÁNYK felülete? És itt most nem a kinézetre gondolok, az nem izgat (default Swinges kinézet, ez van), sem az űrlapok kitöltésére magára, azt nyilván a papír alap határozza meg. Hanem a menübárra/menüsorra a logikátlan menüpontjaival, ez az egész manuális frissítgetés, űrlap-letöltősdi, az elképesztően tróger "mentési" rendszer... És nem lehet azzal jönni, hogy "régi szoftver", mert ezek elszabott megoldások lettek volna 20 éve is...

Ki találta ezt így ki? Kinek kell az anyját szidni, amikor évente leülök ezen szoftver-csoda elé hajat tépkedni? Bevallani azt, amiből kifizetik azokat, akik miatt ott ülök és csapkodom a billentyűzetet, kaparom a falat.

Megírnád konkrétan mi a baj a mentés rendszerrel? Arra úgy nehéz válaszolni, h. szar az egész :) Űrlap letöltősdi? Azt hogyan képzelnéd el "szépen"? X db szervezet Y db nyomtatványával? Komolyan érdekelne, ha van kedved leírni?
Évente 1x - akkor gondolom az szja-t akarod kitölteni. Javaslom a webes lehetőséget, az szebb és egyszerűbb is, ráadásul ott megvan az ajánlatod is. Azt pl. teljesen megértem, h. az átlag embernek fogalma sincs róla, h. ha be akarja vallani az éves adóját, akkor az adott év 53-as bevallását kell letölteni frissítések menüpontból. Sajnos nem nagyon volt ötletünk, h. hogyan lehetne ezt kivédeni. (persze sose felejtsük el, h. ez nem szja kitöltő)

Kezdődhetne pl úgy, hogy:

1. Elindítod a progit, és:
1a. Ha még nincs user mentve, bekéri az adataidat. Itt eldől, hogy magánszemély/EV/KATA/Bt/Kft/Lófasz/könyvelő vagyok-e.
1b. Kiválasztod az egyik usert.
2. Megkérdezi, hogy mit akarsz csinálni? Itt egy kurvanagy lista, ami az időszak/napszak/épp belépett user típusa alapján rendezi. Tehát pl nekem, mint magánszemélynek, a január..május időszakban az SZJA bevallást teszi legelölre, egy könyvelőnek mást. Érted. FONTOS: NEM ÉRDEKEL AZ ŰRLAP KÓDSZÁM-REJTJEL-LÓFASZA.
3. Magától(!!) letölti az adott űrlap legfrissebb változatát. FONTOS: NEM AKAROK EZZEL FOGLALKOZNI. A KÖNYVELŐM, MARISKA SE.
4. NEM a papírt majmolja, hanem megkérdezi szépen (ahogy más is leírta már), hogy: mennyi a jövedelmed? írd ide --> [input]. mennyi adóelőleget fizettél már be? írd ide --> [input]. Adtál e ki lakást? Y [input]/N. etc etc... Ilyen workflow-kkal az esetek 95%-át le lehetne fedni.
5. MOST mutatni az egészet a papírformátumban.

Ennyire nehéz lenne ilyet megcsinálni?
Vagy legalábbb egy UX designert felkérni?

Angliában pl. úgy megy, hogy az esetek nagy részét lefedi az itt leírt módon működő webes nyomtatványkitöltő. A különböző speciális esetekben szenvedő kisebbség meg beadhatja papíron (amit akár kézzel, akár 3rd party által fejlesztett programmal kitölthet)

A lényeg, hogy az adóhivatal a 95%-ra lő csak fejlesztéssel. Az 5% kedvéért nem költenek el egy halom pénzt.

> A lényeg, hogy az adóhivatal a 95%-ra lő csak fejlesztéssel. Az 5% kedvéért nem költenek el egy halom pénzt.

Oké, de az ÁNYK továbbra sem csak adóbevallásra való. Van ebben a threadben beavatott hupper, ő lehet, hogy meg tudja mondani, mekkora az adóbevallás vs minden más aránya. Így lehet, hogy az a 95% valójában csak 20.

Nem voltam katona és nem is szeretnék az lenni, de úgy tűnik nekem, hogy sosem az volt a cél, hogy 0 veszteséggel kerüljenek haza a csapatok, hanem az, hogy elérjék az akármilyen célt.

Láttunk már olyan esetet, amikor az emberveszteséggel egyáltalán nem törődve tolták be a szerencsétleneket a darálóba, remélve, hogy a másik oldalon több pusztul, és majd jól felőrlődnek (pl. az I. világháborúban elég sok helyen ez ment).
Vagy a géppuskafészkek ellen indított gyalogos rohamok?

Ahja, régen más volt a dolog... mostanában azért már kifejezett cél szokott lenni, hogy épségbe hazahozzák az embert a harctérről. De az része a munkakörnek, hogy az ember esetleg nem jön haza...

...de ez egy nagyon hülye analógia annak kapcsán, hogy egy feladatkör mekkora részét oldják meg és mekkora részét hagyják úgy, ahogy volt.

Értem.

Szerintem a katonaság nem jó példa, de értem, hogy mire gondolsz. De a szoftverfejlesztés tipikusan nem ilyen gondolkodásmódot kíván (legalábbis a versenyszférában).

Ha van egy kis időd, olvass utána a 80 - 20-as szabálynak.

Több féle módon, több féle dologra használják szoftver projekt tervezésekor is.

Vásárlók 20%-a hozza a bevétel 80%-át. Felhasználók 80% számára a program lehetőségeinek 20%-a elegendő.

Az üzleti döntéshozók pl. simán meghozzák azt a döntést, hogy a felhasználói bázis utolsó 20%-át nem próbálják a költségek 80%-ával magukhoz édesgetni.

(Persze nem a pontos számok az érdekesek itt, hanem az arányok)

Pl. a ti webes SZJA kitöltő programotok is csak azoknak a magánszemélyeknek jó, akik évente egyszer SZJA-t vallanak be. Legyen ez a 80%
Pont te írtad, mennyivel nagyobb erőfeszítés lenne a maradék 20% felhasználó igényeire is felkészíteni a webes rendszert.

Leírom az ellenérveimet - de nem lepattintásból, csak mert 1 csomó dologról gondolkud(t)unk mi is az évek során
1.a - ez ügyfélkapus azonosítás nélkül nem tűnik kivitelezhetőnek, és itt sajnos mindjárt ki is esik a felhasználók elég nagy része.
Tfh. megkérdezzük a felhasználót, h. melyik NAV-os kategóriába esik bele.
1.b mindjárt kezelni kellene, h. pl. meghatalmazott vagy e, eljárhatsz e hivatalosan valaki nevében. lásd fent, de itt már a hivatalos megbízáshoz mindenképpen kell azonosítás + ellenőrzés a NAV-tól ill. attól a szervezettől, akinek a nyomtatványát a 2. pontban ki akarod majd választani.
2. itt a "kurvanagy" a gond :) Gyakorlatilag csak a NAV-nak van vagy több száz nyomtatványa + a többi szervezet, de tulajdonképpen ez megoldható lenne. Az elnevezések is érdekesek, egy könyvelő sokkal jobban eligazodik a kódszámokkal mint a megnevezésekkel. Szerintem simán megfúrnák az ilyen fajta választási lehetőséget.
Egyébként magánszemélyként teljesen jogos felvetés - a NAV is 16SZJA-nak hívta már az idei bevallást 53-as helyett.
3. Na igen, az automatizmusok. Sajnos ez sem ennyire triviális. Nem mindenhol közvetlenül a felhasználó frissít, van 1 csomó hely ahol hálózatban dolgoznak és központi helyen vannak a sablonok. Vagy látod pl. az egyik bejegyzést a frissítő url hibájáról. Mondjuk van 1 szervezet aki kitett 50 nyomtatványt és elrontotta az url-t. Ez azt jelentené, h. minden egyes alkalommal, amikor az ő nyomtatványát akarnák használni, ki kellene várni, amíg kiderül, h. nem jó az url, v. jó, csak nem tud válaszolni a szerver.
4. Ilyen az eSzja, legalábbis ilyen akar lenni. A workflowt kialakítani rohadt nehéz, rengeteg mező van. 1400 körüli. És ahogy már írta is valaki az 5% -ot (sztem több) sem engedhetjük el.

Különben abban szerintem is igazad van, h. el kellene szakadni a papír alaktól és az adatok megszerzésére koncentrálni nem a formátumra. De hát van aki tollal tölti ki a nyomtatványt. Azzal mi legyen?

Azt kell lapvetően látni, h. az évi 1xi szja-t kitöltő és a heti rendszerességgel könyvelő, bevalló "szuperjuzerek" között hatalmas az igény különbség. Ezt próbálja meg kompenzálni az eSzja. (vagy webNyk)

Különben nekünk is az lett volna a legjobb, ha lett volna egy fórum, ahol a könyvelők meg az egyszeri felhasználók között kialakult volna 1 kompromisszum, h. mit, hogyan kéne és úgy csináltuk volna. Szerinted lehet ilyet? Hidd el nem könnyű nekünk sem... Nyilván van 1 csomó dolog, amit lehetne máshogy, de akkor meg másoknak nem tetszene - lehet olyanoknak akiknek adott esetben erősebb az érdekérvényesítő képessége.

1.b nem kéne túl sok ilyennek lennie...
2. Ok, akkor a "könyvelői loginnál" a kódszámot látja :-) Vagy legyen konfigurállható! :D
3. Automatikus +n nap a határidőre :)
4. szopó

Aki papírozik, annak minek az ányk? Ő maradjon papíron akkor.

Csináljunk rá nemzeti konzultációt :D

Biztos van valami szakmát képviselő tömörülés, aki párbeszédet kezdeményezhetne...

Minden gengszterváltás alkalmával szétverik az előző által szervezett rendszert, akár jó akár nem. Már vagy 3 féle "mindent egy helyre" weblap csontváza van a neten. Ha nem figyelsz eléggé. akkor lehet egy elavult helyen keresed az információkat. A legjobb, hogy a régi űrlapok nyomtatvány sablonjait le is törlik, így aki újratelepítette azóta, az többé már nem tudja megnyitni a régi dokumentumait, mert nincs meg hozzá a sablon. Hol az apeh/nav oldalon volt, hol megyei weblapokra szétszórva, most meg webes felületen.

Sok olyan programot telepitettem mar, ahol volt egy egyszerusitett, es egy advanced felulet. Telepiteskor megkerdezi melyiket kered, es utana is a beallitasok kozt valthatsz.
A motor alatta lehet kozos, kicsit tobb macera fejleszteni, de minden megoldhato.

A masik megoldas, amikor kulon-kulon lenyithatsz/megjelenithetsz kulonbozo reszeket egy-egy urlapon. Itt a "default nyitva" lenne a fenti advanced mod. Ha pl. kipipalod, hogy konyvelokent mas neveben toltod ki, akkor megjelenik az a mezo, hogy megis kinek a neveben.

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

>Megírnád konkrétan mi a baj a mentés rendszerrel?

Láttál már alternatív szoftvert, amiben menteni lehet? BÁRMILYET. Ha még nem volt elmentve a fájl, feldob egy ablakot a mentés gombra ált. az alkalmazás, hogy hová, milyen néven szeretném, hogy kerüljön a fájl. És van egy mentés másként, ahol már egyszer mentett fájlt máshová, más néven is elmenthetek.

Ehhez képest ennek a csodának van egy beégetett mentési tárhelye, amit telepítéskor kellett megadni és default nem triviális helyre mutat (rég használtam Windowson, rémlik, hogy az appdata alatt kellett turkálni). Oda ment default névvel, a mentés máskénttel max a fájl nevét tudod átírni. Ez így wtf?

>Űrlap letöltősdi? Azt hogyan képzelnéd el "szépen"?

Egy értelmes megoldás lenne, hogy rányomok, hogy új űrlapot akarok kitölteni, ott a listája az eddig használtaknak (mint most), és egy gomb, hogy egyéb sablonok letöltése. A letöltés ablakban meg KÜLÖN KERESŐ, az űrlapok pedig TAGEKKEL VANNAK ELLÁTVA, amik alapján szintén keresni lehet rájuk.

Ha nem könyvelő az ember, minden nyomtatvány kitöltés új sablon letöltésével kezdődik (mert kb. mindenből évente új van, ugye...), szóval elég fontos funkció a sablon letöltése. Ehhez képest baromira el van dugva az isten háta mögé. (Szerviz -> Frissítések -> Tovább -> 'Újdonságok 2' tab)

Ha meg véletlenül eltalál oda az ember, akkor meg jön az, hogy a kismillió űrlap között kell vadászni a tökre nem triviális, kódnévvel azonosítható neki szükséges szart, az egyetlen segítség amit ad neki a szoftver, hogy a KÓDNEVEKET név szerint tudja rendezni és jöhet a humán lineáris/bináris keresés, a scrollbart rángatva...

>Megírnád konkrétan mi a baj a mentés rendszerrel?

Láttál már alternatív szoftvert, amiben menteni lehet? BÁRMILYET. Ha még nem volt elmentve a fájl, feldob egy ablakot a mentés gombra ált. az alkalmazás, hogy hová, milyen néven szeretném, hogy kerüljön a fájl. És van egy mentés másként, ahol már egyszer mentett fájlt máshová, más néven is elmenthetek.

Ehhez képest ennek a csodának van egy beégetett mentési tárhelye, amit telepítéskor kellett megadni és default nem triviális helyre mutat (rég használtam Windowson, rémlik, hogy az appdata alatt kellett turkálni). Oda ment default névvel, a mentés máskénttel max a fájl nevét tudod átírni. Ez így wtf?

Most had vegyem védelmembe azt, aki ezt így kitalálta.

ÁNYK esetén ha kiválasztom azt, hogy megnyitás, akkor az összes régi bevallásomat látom. Ilyen-olyan szempontok alapján kereshetek is közöttük. A fájl neve nem is érdekes, nem is látom. Metaadatok alapján találok meg és választok ki valamit.

Ezzel szemben, láttam én már több olyan "titkárnőt", akik elmentettek pl. Word-ben egy fájlt, valahová, valamilyen néven, aztán kb. sohasem találták meg újra.

Igen, más, mint a szokásos. De tapasztalt felhasználónak nem okoz gondot (tudom menteni, tudom új gépre átvinni), az egységsugarú felhasználók számára meg bolondbiztos.

>Ezzel szemben, láttam én már több olyan "titkárnőt", akik elmentettek pl. Word-ben egy fájlt, valahová, valamilyen néven, aztán kb. sohasem találták meg újra.

Inkább magánszemély userekkel jöhettél volna, akinek ez a _munkája_ az tudja már ellátni azt...
Ahol egyébként ilyeneket alkalmaznak, ott az abevjavás könyvtár szerinted mennyire van backupolva pl.? Mert ha hálózati meghajtóra dolgozik, ott még lehetne is rá esély.
Tudom hogy meg lehet oldani, de legyünk őszinték...

>ÁNYK esetén ha kiválasztom azt, hogy megnyitás, akkor az összes régi bevallásomat látom. Ilyen-olyan szempontok alapján kereshetek is közöttük.

Lehet ezt ám úgy is, hogy ki tudsz választani egy gyökérkönyvtárat, amit scanneljen, alapból oda dobjon mentésnél és akkor navigálj el csak, ha el akarsz. Sőt, úgy is, hogy ezt a könyvtárat runtime a beállításokban lásd, módosítani tudd, ellenben a jelenlegi "megoldással" (lehet csak én nem találom). Nem példa nélküli, különböző okosabb, az ÁNYK-val bőven egy korú média lejátszó alkalmazások simán tudják kezdetektől fogva ezt.

Na látod, már ennyi ember között is van olyan aki szerin jó ötlet fix helyre menteni és a fájok fejléceit parsolni és az alapján választani közülük.
A fix helynek az az oka, hogy a sablonokat, adatállományokat, temp mappát, egyéb leírókat egy helyen lehessen tárolni. + az archiválás, visszatöltés is ok legyen. Ráadásul a nyomtatványok státusza is erősen kötődik a fájlrendszerhez, más fájlokhoz. Ha 1-1 fájlt akárhová is el lehetne menteni, akkor elég körülményes lenne a mostani adatokat megmutatni a nyomtatványokról. Az lehet, h. neked nem tetszik, de attól még nincs az elrontva.
Azt azért ne feltételezd már, hogy nem tudtunk volna minden mappát külön beállíttani és oda menteni.

Ahogy fent is írtam, szerintem jobb ez a mentés, de amit fent írt valaki, hogy Windows alatt el van dugva a könyvtár, az rossz.

Nem emlékszem, hogy Linux alatt alapból jó helyre kerül vagy nekem kellett-e választanom, de az összes ÁNYK által mentett cucc a ~/abevjava könyvtár alatt van, ami elég egyértelmű és könnyen megtalálható - és így könnyen menthető is.

Ha Windows alatt is könnyen látható és egyértelmű lenne a helye, talán kevesebben akarnák megváltoztatni.

Amúgy én azt hittem, hogy ez a szoftver azért ilyen, mert megkapta anno az IT-analfabéta kormányzati haver garázscége a melót és gombokért, mindent kispórolva gányoltatta össze egyetemista gólyákkal meg OKJ-s szerencsétlenekkel, ahogy az közbeszerzéseknél lenni szokott. Azóta meg senki bottal se meri piszkálni a UI kódot, a motorban néha bugfixelnek valamit, reszelnek a hibákon, de ennyi. Ha azt mondanád, hogy hát sry, történelmileg így alakult, te csak egy hangya vagy és nem tehetsz róla, simán elfogadnám.

Ehhez képest te itt full őszintén próbálod védeni ezt az adófizetők pénzéből összegányolt csoda felületet, mintha ez teljesen normális lenne. Te milyen egyéb programokat használsz, amiben ehhez hasonló megoldások vannak, amit az előző hsz-emben írtam? Mert nekem leginkább az az érzésem ha más szoftver után az ÁNYK elé leülök, hogy ezt valami Szíriuszról jött űrlény tervezte, aki egyszer előtte ült már windowsos progi előtt és megpróbálta azt emlékezetből lemásolni.

"Mert nekem leginkább az az érzésem ha más szoftver után az ÁNYK elé leülök, hogy ezt valami Szíriuszról jött űrlény tervezte, aki egyszer előtte ült már windowsos progi előtt és megpróbálta azt emlékezetből lemásolni."

EZ

+1

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Leírtam fentebb, hogy nem emlékezetből másoltuk, hanem ott volt előttünk az ABEV meg a megrendelő, hogy úgy nézzen ki. :)
Nézd, tudom, hogy nem egy 2017-es felület az ányk. Mi sem vagyunk vakok, sőt esztétikai érzékünk is van. Védeni sem akarom. Egész egyszerűen nem prioritás. A webnyk kapcsán végig éltem milyen egy korszerű felület kitalálása, megtervezése. Ez egy külön szakma, erre nincs erőforrásunk. Ad hoc jelleggel meg nem lehet egy ilyenbe beleugrani ha egyszer megfogalmazza az igényt a NAV. Leírok 1 példát: a nyomtatás ikon és a menüpont. Tudom, az a szokás, hogy az ikonnal gyakorlatilag egyből nyomtatunk a beállított paraméterekkel, a menüből meg állítgathatunk. De kifejezett kérés volt, h. az ikonra kattintva ez a mostani választó ablak jöjjön fel az adott feliratokkal, hogy kiemeljük a kivonatolt nyomtatás lehetőségét. Van egy csomó olyan prioritás a programban amit kértek, függetlenül attól, h. szép v. nem.

Nézd, tudom, hogy nem egy 2017-es struktúra a hálózatunk. Én sem vagyok vak. Védeni sem akarom. Egész egyszerűen nem prioritás (ha a prioritás érdekel kérdezd meg a tartótisztem, vagy a sajátod hisz neked is van és egy csapatban nyomják :P). A költségvetésünk kapcsán végig éltem milyen egy korszerű hálózat kialakítása (wait 15+ éve nincs elkülönítve semmi az IT kiadásokra), megtervezése. Ez egy külön szakma, mások eldöntötték, hogy erre nincs erőforrásunk. Ad-hoc jellegel meg nem lehet ilyenbe beleugrani ha egyszer megfogalmazta az igényt a NISZ. Leírok egy példát: megnyertél egy tizenpármilliárdos pályázatot aminek a megvalósítását rajtunk akarod elverni. :P

"Nézd, tudom, hogy nem egy 2017-es felület az ányk."
De sajnos még csak nem is 2009-es :)

Nem hiszem, hogy az a nagy problémája mindenkinek, hogy nem reszelgetitek az aktuális trendeknek megfelelően az UI-t, hanem az, hogy ez a felület már 2009-ben is iszonyatosan gány volt. (Igen, tudom, a döntéshozó nem értett hozzá/sz*rt bele.)

Szerintem már épp elegen leírták, hogy a nyomtatványok kvázi pontos leképezése halandó ember (értsd: nem könyvelők, hanem pl. én) számára kifejezetten kényelmetlen.
Ami pl. konkrétan idegesítő: a checkboxokra kétszer kell klikkelni a mai napig, illetve nem pirossal jelöli vagy hasonló a hibás mezőket, hanem állandóan ugrálnak fel a hibaablakok, amelynek tartalma a halandóknak egy csomó esetben nem mond semmit (tudom, nem a programozók hibája).

Tipikusan az a nagy céges mentalitás, amikor valaki, nem szakmabeli kitalálja szerinte hogy kéne megvalósítani valamit, a szakemberek pedig csinálják meg.
Gondolkodásnak, szakmai egyeztetésnek helye nincs. Bármekkora hülyeség, akkor is úgy kell megcsinálni. Majd, ha végigment a folyamat és hónapok, évek múlva kibukik, hogy butaság az egész, akkor mutogatás a fejlesztőre, aki pedig a specifikációra mutat, hogy attól nem térhet el. Kezdik előről, quasimodo 2.0 néven. A kör bezárul, így születnek ezek a pénznyelő szörnyszülöttek.

( KGer | 2017. 09. 25., h – 16:16 )

lemaradtam dolgokról mostanában, de eredetileg nem úgy volt hogy visszafele kompatibilisnek kell lennie minden java major verziónak?

tudom hogy az élet más, de nem is törekedtek rá?

CSTINFO egy csoda, de ottani cuccokat lehet alkalmazni KIRA-ra is! :) pl a java promtba megadni a -DJSUNJava*... mittudomén mi a pontos cucc, de hogy ezt a java vezérlőpultban kell elvégezni. Amit egy esetleg automata java frissítés úgy b.sz ki a kukába hogy öröm nézni :D Minor upgrade is.. :)

Üdv a klubban! :)

De, elvileg igen. Sőt, nekem többnyire sikerült, de valahogy nem ez az elterjedt az iparban. Van több tippem, hogy mi az oka ennek, és ezen okok nagy része véleményem szerint fejlesztői inkompetenciára vezethető vissza - és itt nem a JRE/JDK fejlesztőire gondolok, hanem a nagyszámú Java nyelvet használó fejlesztőre.

( hardhead | 2017. 09. 25., h – 20:04 )

Jó nyelv ez a JAVA. Minden új verziónál hozzá kell nyúlni a programokhoz. Az, hogy elkészülsz egy programmal, letesztelve átadod és a a felhasználó használhatja az idők végezetéig már elavult dolog. Hiába fizette ki, izélheti. :) Soha véget nem érő bevételi lehetőség... Ügyes! :)

Ezt úgy mondod, mintha kötelező lenne mindig feltenni az új verziót, pedig ez sokaknál csak berögződés.

.NET-tel is főleg azért nincs gond, mert hiába teszed fel az új verziót, fennmarad a régi is. (De egyébként is úgy érzem, hogy a .NET főverziók között kevesebb a breaking change.)

Hogy ne legyen félreértés: .NET-nél nem marad fent a régi is. Pl. ha 4.0-ról frissítesz 4.x.y -ra, akkor az lecseréli a 4.0-t, és nem tudod már pont ugyanazt futtatni. (A 2.0-ra épülő verziók az más tészta, azokból létezhet egy párhuzamos installáció, de azon belül szintén cseréli a korábbi 2.0-ra épülőt, pl. ha 3.5-re frissítesz.)

A kevesebb gond oka valószínűleg az, hogy jobban figyelnek a kompatibilitásra.

"De egyébként is úgy érzem, hogy a .NET főverziók között kevesebb a breaking change."

Bocsánat, de a .NET az szinte csak kizárólag breaking change... :)

Java esetén kettő breaking change volt eddig nyelvi szinten: bejött az enum, mint védett kulcsszó, illetve most a Java 9 kapcsán nem lehet az _ önállóan változónév. Ezen túl a publikus API nem változott. Ami változott, az vagy bug volt, vagy pedig a tisztelt fejlesztő olyan dolgokat használt, amit amúgy nem lett volna szabad.

> bejött az enum, mint védett kulcsszó
+strictfp :-)

de egyébként +1, a .NET-esek sokkalta bátrabban dobnak ki deprecated dolgokat...
juniorként szembejött egy .NET-es projekt, amit állítólag halál volt 3->4-re migrálni - aztán valami lib/os támogatás miatt utána meg jött a 4->3 migrálás...

én csak az utóbbit néztem végig, de hát...
--
blogom

"Minden új verziónál hozzá kell nyúlni a programokhoz."

Ha jól írod meg, akkor nem. Ha balfasz módon írod meg, például azért, mert olyan osztályokat használsz, amelyeket nem lehetne, mert vendor specifikusak (lásd com.sun.*), akkor nem kell sírni, ha később ezeket kiveszik vagy elérhetetlenné teszik. Ugyanilyen dolog a két verzióval korábban @Deprecated annotált metódusok használata, majd amikor 10 (azaz tíz!) évvel később tényleg kiveszik, akkor sem kell sírni.

"Az, hogy elkészülsz egy programmal, letesztelve átadod és a a felhasználó használhatja az idők végezetéig már elavult dolog. Hiába fizette ki, izélheti. :)"

Azzal a korbeli JVM-mel gond nélkül használhatja, amivel kapta.

( sz332 v | 2017. 09. 26., k – 09:36 )

Ezek a kiváló fejlesztők simán megoldhatnák, hogy egy JRE-t is hozzácsomagolnak az ÁNYK-hoz, aztán annyi.

Miért hülye ötlet? Amúgy meg elég 32 bites változat, amíg a Windows része a WoW64. Linux alatt persze megint más a helyzet.

Felmerült a webalkalmazás, akkor viszont a nulláról kellene újrafejleszteni, mert a java a böngészőben már bukta. Gondolom inkább maradnak az asztali kliensnél.

Akkor egyértelműbben fogalmazok. Szerintem nem jó ötlet - pláne 9 és fél éve nem lett volna jó - egy 7 MB-os alkalmazáshoz egy 100 MB-os jre-t csomagolni. Tuti kellett volna egy kisebb változat is, aztán burjánzottak volna világba a verziók. Eddig nem nagyon volt semmi gond az átállással 1. a 9-es ami gondot okozott a néhány kimaradt sun... os csomag miatt. Ezzel persze lehet vitatkozni.
webalkalmazás. Az szja idén március 17-től weben is elérhető java nélkül, csak browserben. A linken a díj van amit kapott.

"Szerintem nem jó ötlet - pláne 9 és fél éve nem lett volna jó - egy 7 MB-os alkalmazáshoz egy 100 MB-os jre-t csomagolni. "
Szerintem meg nem jó ötlet proprietary API-kat reflectionnel basztatni, főleg, hogy évek óta lehet tudni, hogy a Jigsaw miatt a proprietary API-k elérhetetlenek lesznek, de hát a fejlesztők basznak ám rá.
Java SE API-ban nincs Sunos csomag. Azt KELL használni, ami Java SE API-ban van. Minden más proprietary szar, nem szabad használni.

Meg kell írni Java 9 modulrendszerben és akkor elég az első bootstrap modult odaadni a felhasználónak, aztán a bootstrap majd lehúzza mindazt, ami futásidőben kell. :)

Egyébként meg ~50 MBájt a JRE... az ÁNYK meg 16 MBájt, nem mondod, hogy 66 MBájt bárkinek is gondot okoz, amikor egy heti oprendszerfrissítés ennek többszöröse...

Én azt nem értem, miért kell java, kitöltőprogram, nyomtatványok és dokumentációk letöltögetésével telepítésével szórakozni ahelyett, hogy az egész egy webalkalmazás lenne, amit az ember az ügyfélkapuból elérne és tudna használni kényelmesen.

Monjuk ott meg arra nem lennének felkészülve, ha frissül a böngésző

Mindegy...

"Nem tudom pontosan mit értesz web alkalmazás alatt"

Ne haragudj, nem tudom elolvasni most a cikket. Valami weboldalról van szó, ami pont azt valósítja meg, amit hiányolok?

Webalkalmazás alatt egy alkalmazást értek, ami a böngésződben fut. Lásd például gmail, vagy egy random online rajzprogram, vagy mondjuk a facebook messenger.

Konkrétan jelen esetben egy olyan honlapra gondolok, ami az abevjava által kínált funkciókat valósítja meg a weben telepítgetés nélkül.

Nem értelek, és nem értem ezt a "azon megy a sírás" dolgot. Ki sírt? Nem emlékszem, hogy hullattam volna könnyet, vagy nyavalyogtam volna, szimplán kifejeztem, hogy számomra ésszerűbb lenne webes felületen intézni a nyomtatványok kitöltését/beküldését.

Jelen példa (szopás a java 1.9-cel) mutatja, hogy ami van most, az nem annyira jó, miért is sírás az, ha az ember egy kicsit jobbat remél?

Avagy: F*szom, hogy nem lehet itt semmiről véleményt formálni, mert az "sírás"

A könyvelők még jobban utálják a webes cuccokat, mert sajnos sokkal kevesebb dolgot tud, mint egy desktop alkalmazás.
És az ÁNYK-t nem csak SZJA-ra használják az emberek :) Beszélj egy könyvelővel, vagy államigazgatásban dolgozóval nyigodtan.

A webes böngészős "6 hetente jön az update, ami elbaszhatja a dolgokat" jobb ennél?

Csakhogy tisztázzuk az elképzelésem: Egy ilyen webes technológiákra építő alkalmazás elérhető lenne sima weboldalként is, integrálva az ügyfélkapuval, használható volna anélkül is, és onnantól, hogy megvan, nem volna nehéz offline működő alkalmazásba csomagolva letölthetővé tenni.

Kábé mindenkinek a kívánságát le lehetne így fedni, azét is aki nem akarja frissíteni a böngészőjét, azét is, aki csak fel akar menni adóbevallást csinálni, és a könyvelőét is, aki utálja a webes cuccokat, ugyanis:

Senki nem mondja, hogy fogyatékosnak kell lenni az webes verziónak a desktophoz képest, csak azért, mert ez a trend. Nézhet ki ugyanúgy, működhet ugyanúgy, és innentől csak pluszokról beszélhetünk, pl automatikus frissítés, nyomtatványok keresése ahelyett, hogy kézzel töltögeted/telepíted, adatok tárolása az ügyfélkapus tárhelyeden, beleértve a félkész nyomtatványokat, stb, stb.

Én tényleg csak az adóbevallás részét láttam, úgyhogy szívesen várom az észrevételeket mi az ami tényleges korlátot jelentene?

Ha ez az alkalmazás tud mindent, amit a mostani tud, ugyanúgy, vagy közel hasonlóan néz ki, akkor innentől már csak plusz funkciókról beszélhetünk, és nem hiszem, hogy sok kifogása lehet akárkinek.

Vagy van olyan funkciója a mostaninak, ami nem volna megvalósítható?

nem kötelező kevesebbet tudnia csak azért, mert webes alapon van elkészítve (az csak egy hülye trend, nem minden esetben a platform hibája), és ha vizuálisan is ugyanúgy néz

a weben mondjuk egy anyk.hu szintű domain megnyitásával, de működhetne becsomagolva electron appként is, offline módon. Ha ez megvalósul, és egyébként minden funkciót ellát, amit egyébként a mostani ellát, akkor innentől csak pluszt ad, mert azt már fedeztük is, amit a mostani tud.

, ügyfélkapus bejelenkezéssel, vagy anélkül. Tudna lemezre menteni, de dolgozhatna az online privát tárhelyeden is, ami az ügyfélkapuval jár, így akár több gépen is használható lenne (

1) Csakhogy nem a webes cuccok hiányosságáról beszélünk, hanem egy trendről, amit nem volna muszáj követni. A webes ányk akár nézhetne úgy ki, mint a javás, és működhetne teljesen megegyezően a mostanival.

Tud valami olyat az ÁNYK, amit nem lehetne megoldani, ha az webes technológiákra építene?

2) Tiszta sor, hogy nem csak SZJA-ra használják. Mondd el, hogy milyen szempontokra nem voltam tekintettel, ami miatt nem volna megvalósítható.

3) Olyan helyeken, ahol kritikus, hogy elérhető legyen

Ha észrevetted, az ANYK kinézetre is utánozza a papíros nyomtatványokat. Tartozik hozzá egy tervező szoftver, mely segítségével a használatára kötelezettek elkészíthetik nyomtatványikat, definiálva a belső összefüggéseket.
Igen pilótavizsgás. De valamikor valaki ezt kérte, s valakik a saját tudásuk szerint így valósították meg. Erőböl elterjedt.
Sajnos keveredik a belső formátumában a kinézet és a tartalom, így simma átmenettel könnyen nem kiváltható webes alkalmazással.
Nézzd meg, hány nyomtatvány van az ÁNYK alá definiálva.

"Ha észrevetted, az ANYK kinézetre is utánozza a papíros nyomtatványokat."

Ahja, alapvetően ez a probléma gyökere, hogy egy elektronikus rendszer megpróbálja utánozni a nyomtatványokat.

"Sajnos keveredik a belső formátumában a kinézet és a tartalom, így simma átmenettel könnyen nem kiváltható webes alkalmazással."

Nem webes alkalmazással kellene kiváltani, hanem jól dokumentált API-val. Az alkalmazást majd megírja mindenki magának vagy vesz egyet, amit valaki megírt.

Nem értem mit akarsz ezzel mondani, én arról beszélek, hogy az ÁNYK mint szoftver lehetne webalkalmazás. Nincs összefüggés aközött, hogy milyen nyelven/platformban van implementálva, és aközött, hogy hogy rajzolom ki a nyomtatványt. Weben is meg lehet oldani ugyanazt, amit a javás felület csinál.

Sőt, szerveroldalon is összebaszhatná a pdf-et akkor már, amit ki kell majd nyomtatnom. Mert ugye nincs nyomtatóm, hanem elviszem egy ilyen print shopba, vagy mi a tök az, pendriveon...

Meg felejtsük már el azt a fos űrlapot, nekem csak azt a sort mutassa, amiben van is adat.

Ha észrevetted, az ANYK kinézetre is utánozza a papíros nyomtatványokat.

Ez, meg a kitöltési útmutató a két legnagyobb hibája szerintem.

Egy ideje Angliában élek. Az itteni SZJA bevallás webes. A kinézete teljesen más, mert az összes angol állami weboldal úgy van felépítve, hogy vakok is használhassák felolvasó programmal.
Oldalanként van néhány kérdés, és nem olyanok, hogy Bevallás jellege [H,O], Bevallás típusa [F,V,D,A,S,E,M,B], amihez aztán lehet a kitöltési útmutatót bújni, hogy azt mondja önellenőrzés esetén "O". Ismételt önellenőrzés tényét nem a főlapon, hanem a 03-01-es lapon az O blokkban kérjük jelölni.
Az első kérdést nem kérdeznék, mert látnák, hogy még nem adtam be korábban, tehát ez nem javítás.
A másodiknál meg megkérdeznék, hogy megszűnt vagy szünetel a cég? Aztán ha igent mondok, akkor feltennék a megszűnés típusára vonatkozó kérdéseket, de nem zaklatnának vele, ha nem szűnt meg a cég.

A végén persze az egészből egy olyan pdf keletkezik, ami úgy néz ki, mint egy papír nyomtatvány - gondolom még most is használnak papírt bizonyos esetekben, és így azonos lesz a kinézet.

A help pedig nem jogszabályok kitekert nyelvén ír, pl:

„Jelölje, ha a Tbj. 56/A. § rendelkezéseivel érintett” mező kitöltése
1-es kód, ha külföldi vállalkozásként közvetlenül, vagy képviselője [fióktelep (2003. évi
XCII. törvény 8. §), pénzügyi képviselő (2003. évi XCII. törvény 9. §)] útján nyújtja
be,
kód, ha a külföldi vállalkozás munkavállalójaként nyújtja be.

Hanem lefordították emberi nyelvre.

Egyébként ez egy hatalmas különbség UK és HU között... most kaptam levelet a Companies House-tól, hogy októberben le kell zárnom az üzleti évemet, egy darab törvényi hivatkozás nincs benne, de teljesen érthetően leírják, hogy mit kell tennem, mikorra kell azt tennem és ha nem teszem meg addigra, akkor mennyi büntetésre számíthatok.

Ha melléteszek egy tetszőleges NAV levelet, akkor ordít a különbség.

+1 Hatalmas.

Angliában a bevallást úgy töltöm ki, hogy a legtöbb kérdésnél nem kell a helpet néznem, mert egyértelmű a kérdés és a válasz lehetőségek. 2-3 esetben kell. Az ott leírtakat megértem, és mehet tovább.

ÁNYK esetén meg ha új (még ismeretlen) nyomtatványt kell kitöltenem, akkor azért elég gyakran kell a kitöltési útmutatót néznem, és sokszor a segítség kb. az, hogy az x törvény alapján töltse ki, kedves felhasználó.
Többször előfordult már, hogy egy új nyomtatvány kitöltése során elakadtam valahol, és aztán mentem a helpet követve a jogszabálykeresőbe, és aztán pár órán keresztül bújtam az releváns törvényeket, hogy megtaláljam, hogy akkor az én konkrét esetem minek is számít, hogyan is kell értelmezni, és mit válaszoljak oda.

Nem. Az első számú oka az a fos hozzáállás.

Igen, le van írva valami a törvényben. Jól, vagy rosszul, mindegy.

Aki érti (mert ez a dolga), az le tudja fordítani akár emberi nyelvre, akár egy szép kis folyamatábrára, ahol az elágazásokban egyszerű és érthető kérdések vannak.

Ebből a kettőből pedig egy szuper webes alkalmazást össze lehet rakni (vagy akár offline alkalmazást, ha valakinek az kell).

Hát ebben nagyon nem értünk egyet! Nem tudja lefordítani "emberi" nyelvre. Tudod miért, mert a második legnagyobb félelem, hogy nem pontosan fogalmaznak és a 10 millió jogász országában máris megjelennek az értelmezések, csűrés csavarások, perek. Ez az oka a bonyolult fogalmaknak. Szerintem is bonyolult a cimkék szövege, de megértem a nav-osok érveit.

Lefordítani folyamatábrára? Tudod mit jelentene ez? Jelenleg - ha jól tudom - kb. 600 nyomtatvány van forgalomban. Ez emberfeletti munka lenne. Nézd meg pl. az szja bevallást. A teljes változata 30 oldal. És ez csak 1. Ezen kívül nem tudom, hogy sokat segítene e ilyen kérdés pl.: Jogosult-e ön az ..... kedvezmény igénybe vételére. Leírom a kedvencemet is: Már nemtom melyik nyomtatványon van, de nyilatkozni kell, hogy ha idén felszámoltad a vállalkozásodat és volt pénztárgéped akkor mit csináltál vele.
Az meg hogy bonyolultak az adótörvények... Sok más helyen azok. De meg lehetne nézni, hogy hány féle kedvezmény van pl. az szja-ban. Lehet, hogy több, mint extra kötelezettség - de ezt tényleg nem tudom.
Egyébként meg pont az szja-ban a webes formában elindult a nav ebben az irányban és egész jók a visszajelzések. A profi felhasználókat meg szerintem inkább csak hátráltatná ez a fajta bevitel.
Ja, kipróbálhatnál egy kis játékot egyszer - csak úgy elméletben. Vegyél egy tetszőleges adótörvény paragrafust - azért ne 3 szavas legyen - és próbáld meg egyszerű kérdésekkel lefedni. Aztán a kérdéseket posztold be valamilyen jogász v. adó szakmai fórumra. Szerinted hány perc alatt szednék ízekre? Igen írtad, h. "aki érti", de az a helyzet, h. aki érti, az ezeket a buktatókat is érti benne.

Nem hinném, h. egy programozó feladata lenne adótörvényt mezőcimkékre fordítani - ebben talán egyetértünk. És nem lepattintottam az igényt csak tolmácsoltam - fogadatlan prókátorként - a nav érveit. Jogászkodásba meg kár belemenni, mert pont az UK rossz példa, hiszen az angolszász jogrend gyökeresen eltér a kontinentálistól - ha jól tudom.

"Nem hinném, h. egy programozó feladata lenne adótörvényt mezőcimkékre fordítani - ebben talán egyetértünk."

Nem. Nem a programozó feladata. De a programozónak lehet véleménye, ami eltérhet attól, amit a megbízója képvisel.

"És nem lepattintottam az igényt csak tolmácsoltam - fogadatlan prókátorként - a nav érveit."

Hagyd a NAV-ra a NAV érveit.

"Jogászkodásba meg kár belemenni, mert pont az UK rossz példa, hiszen az angolszász jogrend gyökeresen eltér a kontinentálistól - ha jól tudom."

Oszt ettől nehezebb a jogi csűrés-csavarás?

Ők a NAV, az ő dolguk ezt megcsinálni. FELADATUK megcsinálni. hisz az állami apparátus értem van, nem én értük.
Ha hatékonyabban tudnak adót beszedni, javulni fog az adózási morál is. S ennek ez az _egyik_ előfeltétele.
A bérből és fizetésből élők 90%-a (saját becslés) annyit csinál az adóbevallással, hogy a cégtől kapott M30-ról átmásolja az értékeket. Na, erre lehetne egy egyszerűsített processz. 4 perc alatt adóbevallhatnék. De nem, töltsek le egy programot, baszkodjak űrlapTELEPÍTÉSSEL (minden évben), és még el se kezdtem magát a bevallást.

Hisz' megcsinálták. eszja-nak hívják. Megcsinálták az ajánlatot, csak meg kellett nézni és jóváhagyni ill. javítani ha nem volt teljes. Annyit kellett volna tenni, hogy regisztrálunk az ÜK-n, hogy mindez elérhető legyen. Ezt a minimumot szerintem mindenki elvégezhetné, ha érdekli egyáltalán ez az egész. A többséget nem érdekli még ennyire sem. De ha jól tudom, akkor még ennyit sem kell már tenni, mert az ajánlat automatikusan bevallássá válik ha nem csinálunk semmit.
A 90% túl magas szám, de az a helyzet, h. az ányk-nak 100%-ot kell lefedni. Mindenkinek minden adóbevallási kötelezettségét meg kell tudni csinálni vele.

ÁNYK-val nyomtatványokat beküldeni.

Az érkező leveleket ott elolvasni

Megnézni pl. a TB történetedet, hogy lásd, nem éltek-e vissza a kártyáddal.

Ellenőrizni, hogy fizeti-e a biztosítást utánad a munkahelyed.

Tulajdoni lap másolatot kérni.

Anyakönyvi kivonatot lehet kérni.

Nem elég?

Úgy emlékszem, jármű nyilvántartásból is lehet adatot lekérni (ha pl. venni akarsz valamit), meg úgy láttam, vannak ügyek, amiket ott el is lehet indítani (nekem ezekre nem volt szükségem, ezért nem 100%).

Nem azt mondom, hogy nem lehet nélküle meglenni, és azt se, hogy minden héten használom. De semmiképp se tartom értelmetlennek. Ha valami kell, sokkal egyszerűbb a weben elintézni, mint elmenni valahová, várni, és kikérni vagy beadni ugyanazt.

miért érdekelne, hogy visszaéltek e a tb kártyámmal :))
pontleszarom :))

én fizetem a biztosításomat:)

tulajdoni lapot előbb kapsz a földhivatalban, ugyanis kong az ürességtől.

amikor utoljára kértem adatot anyk-val, történetesen, hogy hány évem van a nyugdíjbiztosítónál, visszaküldtek egy hónap (30 nap) után valamit, amivel aztán el kellett mennem a fiumeire, hogy ugyan magyarázzák el nekem, hogy mi a fax ez, és miért másodpercben adják meg a nyugdíjjogosultságom időtartamát.

egyszerűbb lett volna szimplán odamenni, sorszámot húzni oszt annyi.
azóta is utalják vissza a 'nemmondommeghányszáz' ezer forintomat, kamatokkal. vagyinkábnem. ennek már majdnem egy éve.
költsék gyógyszerre:)

-1

Pont van értelme (ritka az ilyen) nagyon sok mindent el tudsz intézni online. Pl. a nemzeti konzultációs levelekről is leiratkozhatsz :)

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Amikor a magyar hivatalok és szervezetek nem hajlandóak hivatalos és jogilag hivatkozható értelmezést közzétenni, akkor nem lehet mit tenni. Pofára és kedv szerint lehet értelmezni így, hogy éppen kell-e a pénz, vagy ki van útban.

Ahogy lentebb írják, az angolszász rendszerben lehet hivatkozni létező értelmezésre. Itthon pedig ugyanaz büntethet meg, aki esetleg utasít, hogy csináld, azért mert másnap már másképp gondolja.

azért van itt más probléma is:
- szja-nál miért kell külön bepipálni hogy visszakérem a túlfizetésemet?
- miért nekem kell a családi adókedvezményt számolnom? ha webes lenne akkor alapból tudná hogy vannak gyermekeim és már számolná is
- az családi adókedvezménynél a bruttó összeget kell beírni, míg az nyp és ep-be befizetett összegeknél meg a nettót, és ott is külön be kell jelölni ha kéred vissza ami jár

egyébként pedig miért kell nekem kitöltenem egy a munkáltatótól kapott adatok alapján egy másik okmányt arról amit a NAV már alapból tud?

Az egész egy nagy vicc, a mi pénzünkből idióta vezetők minket akarnak sz*patni, gusztustalan.

Okmányirod/ügyfélkapu
- nagyon jó, ha egy okmányom lejár jön az értesítés pl forgalmi (mert ugye előzetesen bent voltam adtam meg nevet, emailcimet meg telefont)
- de az hogy az autóhoz regisztráljam a telefonszámomat hogy értesítsenek ha valami gond van valahol a kocsimmal (elszállítás, tilosban parkolás) ahhoz sorszám kell az okmányirodában meg 2500 ft, miközben minden adatom ott van.

--
ESET és Synology hivatalos viszonteladó

( vilmos.nagy | 2017. 09. 26., k – 13:13 )

Na, most megnéztem... 


WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by hu.piller.enykp.gui.framework.MainFrame (file:/tmp/abevjava/abevjava.jar) to field sun.print.ServiceDialog.messageRB
WARNING: Please consider reporting this to the maintainers of hu.piller.enykp.gui.framework.MainFrame
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Állítólag ez már az 1.2-es JDK Docsban is benne volt.

Egyébként nálam elindult.
--
blogom

Nem.
Direktben hív egy előre definiált Resource Bundle-be a sun-os implementációja a Print Dialognak.
http://www.oracle.com/technetwork/java/javase/javase7locales-334809.htm…

De hát ismerni kéne a Javat ehhez.

A megoldás persze az, hogy PrintService API-k segítségével cusotm Print Dialogot csinál az ember, ha nem elég az, amit a beépített tud. De nem, inlább proprietary, nem specifikált, dokumentáltan nem kompatibilis API-kat használjunk :D :D :D

Gondolom aki csinálta abba egyszer valahol beleverték, hogy "nem írunk újra semmit, amit más már megcsinált". Továbbgondolás meg már nem sikerült, hogy ha szar, vagy sokat kell hekkelni, akkor mégis inkább írjunk sajátot.

Ilyen még amikor 1-2 megás libek bekerülnek a jarba, mert van bennük egy darab metódus, ami megspórol két sort, és milyen lenne már saját utility-be megírni. Hogy amúgy limitált nettel pusholunk fél óránként külföldi szerverekre? Ez van.

Nyilván egy fejlesztő (és gondolom nem egy one man project-ről van szó), nem fog nekiállni a saját szakálára refactorálgatni, ha a javac kiírt egy warningot valahol. Jól is teszi amúgy, mert bármilyen triviális a javítás okozhat vele egy kritikus hibát.

Ha az adott osztályban kell valamit fejleszteni, akkor illik kódtakaritást is végezni, tudván hogy utána a tesztelőkön fennakad egy nagyobb baki.

Amúgy meg már túl lett lihegve ez a téma, lapozzunk.

Most utána néztem, hogy hol is van a fenti példa használatban. Egy rendkívül releváns helyen. Elektronikus nyomtatványkitöltőről beszélünk - ezt ne felejtsük el. Tehát a boríték nyomtatásához kell és csak azért, hogy ne 3 kattintással lehessen a papírméretet beállítani. Igazad van, nem vizsgáltuk meg ennek a megoldásnak minden aspektusát. Egyébként ez pl. az egyik olyan funkció, amire mindig is kíváncsiak voltunk, vajon hányan használják...

( azs | 2017. 09. 27., sze – 11:29 )

Amennyiben valaki már frissítette a JAVA környezetét, akkor NE távolítsa el azt a gépéről. :-)
Egyszerűen fel kell telepíteni a régi verziót egy külön könyvtárba, majd
a "setenv.bat" fájlban az "abevjava" könyvtárban az elérési utat megadni (ABEV_JAVA_HOME) a régi verzióhoz és az ÁNYK (abevjava_start.bat) azt fogja használni.

( ssikiss | 2017. 09. 27., sze – 12:43 )

HUP közösség - így szeretlek bazmeg!

( MGy v | 2017. 09. 27., sze – 17:02 )

Offtopic ÁNYK frissítés

Úgy látom sokan összegyűltetek akik értenek az ÁNYK lelkivilágához.
Kérdezek egyet, hátha találkozott vele valaki, sőt a megoldást is tudja.

Az indítás után szorgosan keresi a nyomtatvány update-eket, de van kettő amit valószínű az online tárhelyről elmozgattak emiatt exception lesz és jó sok idő múlva adja csak fel a program a keresést és megy tovább.
Hogyan tudom lebeszélni, hogy ne keresse ezeket. (stringekre már kerestem mindenféle fájlban)
Az excteption-ök:
hu.piller.enykp.alogic.upgrademanager_v2_0.UpgradeTechnicalException: Olvasási hiba, vagy frissítés leíró file nem található ezen az URL-en: http://kozbeszerzes.hu/letoltesek/letolt/918/
at hu.piller.enykp.alogic.upgrademanager_v2_0.versiondataproviders.downloadablecomponents.DownloadableVersionDataProvider.collect(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.components.reader.OnlineDownloadableComponentsReader.getComponents(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.components.DownloadableComponents.(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.lookupupgrades.LookUpUpgrades.lookUpUpgrades(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.lookupupgrades.LookUpUpgrades.run(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.UpgradeManager.buildCacheAndNotifyWhenHasUpgrade(Unknown Source)
at hu.piller.enykp.gui.framework.MainFrame$6.doInBackground(Unknown Source)
at javax.swing.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at javax.swing.SwingWorker.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
hu.piller.enykp.alogic.upgrademanager_v2_0.UpgradeTechnicalException: Olvasási hiba, vagy frissítés leíró file nem található ezen az URL-en: http://hkp.oep.hu/nyomtatvanyok
at hu.piller.enykp.alogic.upgrademanager_v2_0.versiondataproviders.downloadablecomponents.DownloadableVersionDataProvider.collect(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.components.reader.OnlineDownloadableComponentsReader.getComponents(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.components.DownloadableComponents.(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.lookupupgrades.LookUpUpgrades.lookUpUpgrades(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.lookupupgrades.LookUpUpgrades.run(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.UpgradeManager.buildCacheAndNotifyWhenHasUpgrade(Unknown Source)
at hu.piller.enykp.gui.framework.MainFrame$6.doInBackground(Unknown Source)
at javax.swing.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at javax.swing.SwingWorker.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
hu.piller.enykp.alogic.upgrademanager_v2_0.UpgradeTechnicalException: Olvasási hiba, vagy frissítés leíró file nem található ezen az URL-en: http://static.onyf.hu/kiertesites/anyk/update.xml
at hu.piller.enykp.alogic.upgrademanager_v2_0.versiondataproviders.downloadablecomponents.DownloadableVersionDataProvider.collect(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.components.reader.OnlineDownloadableComponentsReader.getComponents(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.components.DownloadableComponents.(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.lookupupgrades.LookUpUpgrades.lookUpUpgrades(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.lookupupgrades.LookUpUpgrades.run(Unknown Source)
at hu.piller.enykp.alogic.upgrademanager_v2_0.UpgradeManager.buildCacheAndNotifyWhenHasUpgrade(Unknown Source)
at hu.piller.enykp.gui.framework.MainFrame$6.doInBackground(Unknown Source)
at javax.swing.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at javax.swing.SwingWorker.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

1.) Bejegyzés a host fileba -> 0.0.0.0-ra (fails more fast :P)
2.) Az eroforrasok mappába kikeresed kedvenc szervezeted .jar állományát és az orginfo.xml-be átírod a updateurl-t. (el is küldheted a NISZ-nek auditra, hátha úgy működik mint a perkapu ahol mindenki az akinek mondja magát ;))
3.) Amúgy a miénk is hibát lök, úgy tűnik az SSL redirect/maga az SSL egy leküzdhetetlen feladatnak tűnik az ÁNYK számára... (de holnap ránézek)

A frissítések elérésekor az ssl tényleg nem támogatott. Hivatalosan nem jelezte semmilyen szervezet, nem rendelték meg, ezért nincs benne.
Amit írsz, a frissítés kikerülése egyébként működik ügyesen? Sajnos nem nagyon van mit tenni a hibásan publikált frissítő url-ekkel...

Én most vettem észre és nem zavar (bár kétlem, hogy baromi nehéz lenne implementálni).
Átírtam a webszerver konfigját, hogy az ÁNYK linkjeit ne dobja SSL-re. (így problem solved :))
Amikor én próbáltam a kikerülésre működött pl. üres updateurl-nél dob egy MalformedURLExceptiont de nem keresgél a nem létező linken. (persze, ha a nyomtatványban is definiálva van az url akkor onnan is ki kell szedni).

( bzs v | 2017. 09. 28., cs – 08:26 )

"összeférhetetlen a nyomtatványkitöltővel az új JAVA"

agymosó cím. Mintha a JAVA tehetne mindenről meg az Oracle.

Kiigazítom:

"Összeférhetetlen a nyomtatványkitöltő az új JAVA környezettel."

Kérem a NAV dolgozóit, hogy igazítsák ki a hírt :(

( Nyosigomboc v | 2017. 09. 28., cs – 15:47 )

Plusz adalek:
E-Letet pont a 9-es Javaval megy csak, mert ok mar frissitettek. Ugyvedek mindkettot hasznaljak. :)
(ja, es nem, nekik nem eleg az adobevallasos, webes leegyszerusitett rendszer, mert nekik joreszt nem az adoval kapcsolatos urlapok kellenek)

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

Exemnek emlitettem korabban a topicot, mert tudtam, hogy sokat hasznalja a nyomtatvanykitoltot.
O mondta tegnap, hogy jo, hogy szoltam, mert sok ugyvedi irodaban az E-Letet miatt frissitettek, es mennyire megszivtak. Eleg sok ugyveddel tartja a kapcsolatot.

En E-Letetet sose hasznaltam, gondolom rollbackeltek.

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

( persicsb | 2019. 12. 30., h – 12:11 )

Thread nekromanta leszek: az LTS Java 11-es verzióval nem kompatibilis az ÁNYK. Betöltené a java.se.ee modult, ami Java 9-ben deprecated lett egyből, amint a Java Module Systemet bevezették, majd Java 11-ben ki is vezették ezt a modult, ahogy az a Release Notes-ban le van írva.

Frissíteni kellene Java 11-re az ÁNYK-t, de gondolom jön majd storeplace és megmagyarázza, ezt miért nem lehet megtenni, miért felesleges, miért értelmetlen és különbenis.

Azért milyen csodálatos, hogy mennyi szívás van éveken keresztül új verziókkal és az openjdk támogatással. Nem értem miért ilyen nehéz. (igazából értem, ott is az megy mint mindenhol, összehányják működőre, tesztek írására, több platformon tesztelésre már nincs idő, úgyhogy egyszerűbb szimplán azt mondani, hogy nem működik, nem támogatjuk ilyen-olyan okokból, stb)

Ez teljesen technikai dolog, amit a legalján döntenek el az "okos" programozók, akiknek a szintje addig terjed, hogy azokat az osztályokat, függvényeket használja, amiket felajánl az IDE.
Honnan jön (melyik lib), ad-e warningot, deprecated-e, mit ír a doksija, ezek már nem érdekesek annyira.
Azt már egy szinttel feljebb kellene eldönteni (vezető programozó), hogy mely lib-eket lehet használni, ne lehessen a kódban warning vagy deprecated.

Az pont nem szubszidiaritás, hogyha a szoftverfejlesztő csapat nem döntheti el, hogy lecseréli a nem dokumentált és ellenjavallt sun.* packageket, vagy a deprecateddé vált java.se.ee modult. Hanem várnia kell arra, hogy majd egy biztosan bekövetkező jövőbeni hiba által erre fény derüljön és eldöntsék felettük n szinttel, hogy eljött az idő, lehet csinálni.

Ha ebben sem dönthet, akkor azon el sem fog gondolkodni, hogy https-sel lehet nem fog menni a nyomtatvány frissítés, pedig arról van szó már 5 éve a hupon is, hogy kvázi kötelező lett manapság a https a weben.

A frissítések elérésekor az ssl tényleg nem támogatott. Hivatalosan nem jelezte semmilyen szervezet, nem rendelték meg, ezért nincs benne.

Felettük n szinttel meg nyilván nem is tudják miről van szó, de nem is az ő dolguk ezt tudni.

Továbbá, ha azon sem gondolkodik el a csapat, ami a szakmájukhoz tartozik, akkor abból biztos nem lesz minőség.

És ebben ami a legrosszabb, hogy ott van x okos, kreatív fejlesztő és nem hagyják nekik, hogy jól végezzék a munkájukat, hogy használják a kreativitásukat, és ezek miatt nem is fogják magukat jól érezni.

A szubszidiaritás alapvetően az, hogy megmondják fentről, hogy mit kell csinálni és azt mikorra kell megcsinálni, lenn meg eldöntik, hogy azt hogyan és mivel csinálják meg addig.

Nagy céges környezetben ez úgy szokott deformálódni, hogy fenn nem tudják egyértelműen megmondani, hogy mit is kell csinálni, de azt megmondják, hogy azt mikorra, hogyan és mivel kell megoldani, mert azt úgy és azzal szokták csinálni.

Ennek a folyamatnak a végterméke egy olyan torzszülött dolog, mint az ÁNYK és az Ügyfélkapu vagy bármilyen nagyobb cég bármilyen terméke.

https://iotguru.cloud

A probléma abból áll, hogy amikor a Java runtime-ot modularizálták (ami egy nagyon jó dolog), eldöntötték, hogy bizonyos, a Java 8-ban a Java SE részét képező osztályokat tartalmazó modulok nem lesznek részei az alapértelmezett runtime-nak. Ez a döntés 2017 októberében született meg (mármint az, hogy el fogják távolítani a java.se.ee modult). A modul Java 9 óta deprecated és azon alkalmazásoknak, amelyek Java 9+ kompatibilisek, azoknak fel kellett volna készülniük arra (ha future-proof módon működnek), hogy a deprecated feature-öket nem használják, a deprecated modulokat pedig helyettesítik.

Amikor az ÁNYK Java 9 kompatibilis lett, erre nem készültek fel.

Minden szavad aranyat ér!

Ebből még a laikus számára is világossá válik, hogy miért a C az egyetlen platformfüggetlen és hordozható nyelv. :-D

Régen egy nyomtatvány kitöltéséhez csak tintaceruza és némi nyál kellet. A 21. század űrtechnikájával ugyan kevesebb tintaceruza fogy, de sokkal több nyál szükséges hozzá. Ami egy nagyon jó dolog.

Ráadásul jól elszórakoztatja a fejlesztőket, programozókat és a népet.

itt szó nincsen nyelvről, csak a runtime-ról. Amely C esetén is sokféle képességekkel bír. Például standard C runtime, GNU libc, POSIX stb. Rendszerfüggő, hogy mi érhető el. Sőt, vannak ugye a standard C runtime-on belül is opcionális komponensek, nem minden érhető el (pl. threads.h, stdatomic.h). Ott feature test makróznod kell, ha ellenőrizni akarod, hogy valami nem elérhető. 

A C11 eltávolította a C99 óta obsolete gets() függvényt, így a visszafelé kompatibilitás ott is sérült, helyette van az opcionális get_s. Szóval aki future-proof kódot írt 99 óta, nem használta a gets()-et. Pont ugyanaz a szituáció, mint a java.se.ee modul Java 9 óta.

Nyilvánvalóan runtime, mégpedig ugyanazon a rendszeren. Miközben a java még rendszerfüggetlen is.

A C aranyköpés ugyan nem is tőlem származik, csak egyetértek vele. ;)  Egyszerű kódot azért 20 éven keresztül sikerült úgy "hordoznom", hogy csak egyszer kellett két betűt átírni, mivel a POSIX változása miatt átneveztek egy pthread hívást. Igaz, az AIX volt, ahol a libc mindent is  tartalmaz.

Az obsolete gets() kiváló példa az okostojások bemutatására. Egyszerűen deklarálják, hogy veszélyes és aki használja az hülye. Ehhez foghatót csak egy viszonylag új bash fícsörben láttam! Ha string változónak étéket adsz egy asciiz stringből, így asciiz string keletkezik. Ez fél évszázadig működött, de nemrég már warning lett belőle. Eközben az rpm rendszert (is) borították vele. Jöhet a workaround a hülyeségre!

De javára fordítva a szót - illetve mendegy mire - van két változónk: fejlesztők és programozók.

Ha egyik sem hülye, akkor nincs gond.

A maradék három esetben - amikor egyik, másik vagy mindkettő hülye - akkor van a gond.

Tehát tényleg olyan bonyolult funkciók kellnek egy egyszerű táblázat kitöltéséhez és/vagy az ehhez szükséges funkciók nincsenek benne az alap runtime-ban? Hiába látod át "szakmailag", hogy ez így helyes, mert egy táblázat nem marsjáró.

Tehát felhasználók milliót képes szopatni ez a nagy fejlődés.

Szerintem meg lehetne ezt már oldani simán HTML5+Javascript segítségével. Át kéne írni az egészet így, ügyfélkapun keresztül mehetne minden űrlap.

Most ugye fülekre van osztva egy hosszú, komplex űrlap az ÁNYK-ban. De gyakorlatilag minden ÁNYK nyomtatvány egy hosszú űrlap. Az egész mehetne egy oldalra, és el lehet rejteni azokat a mezőket, amire nincs szükség (részekre lenne osztva az űrlap, és a nem szükséges részek csukva lennének).

Egyszerűbb felrakatani a felhasználóval a legújabb böngészőt, mint a Java-val szivatni.

Szerintem nem volt rossz döntés a Java, pláne az akkori viszonyokat nézve (A böngészők akkor amikor ezt elkezdték még nem álltak úgy mint ma. Plusz egy Java vs JS fejlesztés között a technológiából adódóan van egy jókora szorzó. Ráadásul aki Javában is gányol az képzeld el mit alkotna JS-ben???), amikor ezt elkezdték fejleszteni.

Egyszerűen arról van szó, hogy a kód karbantartására és szupportjára nagyon kevés erőt allokálnak. Ha meglenne a vezetői akarat, és 1-2 embernyi pénz, akkor simán kifaraghatnák ezeket az inkompatibilitási problémákat, vagy alternatívaként csinálhatnának JRE-vel integrált telepítőt Windowshoz és Linuxhoz. Nem egy nagy kunszt, az Oracle JRE licensze megengedi, OpenJDK-val is meg lehet csinálni, és mindenki boldog volna. Meg lehetne tehát ezt a problémát ma is oldani a jelenlegi technológiai stack felett is.

Egyébként az új SZJA bevallós/ellenőrzős rendszer már böngészőben működik, nem? Valamit kattingattam-kavartam benne tavaly a határidő környékén. Szóval az általad javasolt út is létezik, csak nem tudnak mindent egyszerre átállítani. Ha van eszük, akkor az adatok ábrázolására ugyanazon engine-t használja, csak tettek a tetejére egy webes UI-t. Ha így van, akkor könnyű lesz a meglévő ABEV formokat portolni webre, és akár párhuzamosan is működhet majd az ABEV és a webes rendszer. Én például offline párti vagyok, azt mondom, hogy amihez nem kell azonnali központi adatbázis hozzáférés, azok a folyamatok igenis működjenek offline módon is.

Az ÁNYK szándékosan lett olyan,mint egy írógéppel kitölthető "okos" nyomtatvány: Elég egy "kinézetet" megismerni/megtanulni úgy felhasználói, mint támogatói oldalon, ami egyszerűsíti a papíros és az elektronikus verzió párhuzamos használatát.
Az új ebev már "okosabb", de a párhuzam a papír alapon készíthető bevallással ott is megvan, hogy 1:1 megfeleltethető legyen egymásnak a két dolog támogatói és felhasználói oldalon egyaránt.

Aham. Megkérdezném azért, hogy mennyi munkaórát voltál amúgy az ÁNYK közvetlen közelében? Mert az ügyfélkapu integrációnál én ott voltam és a közvetlen feltöltés szerver oldalát én csináltam. Maradjunk annyiban, hogy amit írtál, az egy nagy halom bullshit.

https://iotguru.cloud

Az infó olyantól származik, aki anno az első verziók környékén közel volt a fejlesztéshez. Az, hogy te az üf.kapus résznél, sok-sok évvel később ott voltál, az a dolgok egy másik része.

Aham, nyilván. Tehát közöd nem volt az ÁNYK-hoz, de most már van egy rejtélyes ismerősöd, aki közel volt. És ki lenne az?

https://iotguru.cloud

Az AbevJava és az ÁNYK technikailag ugyanaz.

Az AbevJava elődje az Abev.exe volt, ami nagyjából 2006-ban múlt ki emlékeim szerint, ennek a működésmódját, kinézetét és funkcióit vette át az AbevJava.

Az ÁNYT az ÁNYK párja, ezzel lehet nyomtatványokat tervezni.

Az AbevTerv.exe volt az ÁNYT elődje, az Abev.exe párja.

https://iotguru.cloud

Töltsd le a legújabb ÁNYT-t a MoHu-ról és AbevTerv.exe lesz a futtatható állomány neve ;) Ebből én azt tippelem, hogy az alap az Abev lehetett , csak a kitöltő részét jobban fejlesztették mint a tervezőjét (ami ránézésre még most is az Abevra hajaz, kész időutazás :)).

Én ezért kétlem, hogy JAVA-ra váltáskor sokat agyalhattak a világmegváltáson :)

Tudtommal az ÁNYT nem lett Java alapú, egyszerűen csak átnevezték, amikor az AbevJava ÁNYK lett.

Akkor volt ez a váltás, amikor már nem csak az APEH lehetett a nyomtatványok címzettje, hanem lehetett mindenféle egyéb hivatalnak is nyomtatványokat küldeni, valamikor 2008-09 körül, ekkor került bele a hivatali kapu például a mo.hu portálra, az is eléggé elbaszottul, mert be kellett lépned, mint állampolgár, aztán kiválasztani a hozzád rendelt hivatalt és megadni hozzá a jelszót, na, erre kellett valami SOAP API-t írni, saját authentikációs réteggel... valahogy az ilyen helyekre a kontraszelektált balfaszok kerülnek, amikor ötletelnek, hogy egy feladatot hogy kellene megvalósítani, aktuális kormánytól függetlenül.

https://iotguru.cloud

Angliában kb. így is működik, ahogy mondod. Van egy weblap, van rajta néhány kérdés, a válaszok alapján jön egy lista, amin végig kell menni. Mező szinten is eltüntetik azt, ami nem kell, de oldal szinten is, vagyis a listába nem kerülnek be olyan oldalak, amik teljes egészében irrelevánsak.

Viszont valahol azt olvastam, hogy Magyarországon kötelező (feltételezem valami törvényben előírt kötelezettség lehet ez), hogy az elektronikus felületen ugyanúgy nézzen ki a nyomtatvány, mint a papíron.

Angliában elég az, hogy a kitöltés után a weboldal el tud készíteni egy olyan pdf-et, ami úgy néz ki, mint a papír alapú nyomtatvány.

A magyar rendszert logikailag úgy lehetne javítani, ha vagy a törvényt megváltoztatják, hogy a webes felületen ne legyen követelmény, hogy ugyanúgy nézzen ki mint papíron, vagy valaki meglépi azt, hogy csinál egy webes "varázslót", ami végigmegy kérdéseken, és ez alapján az eredményt generálja le (vagyis a felhasználó nem a webes nyomtatványt tölti ki, azt a szoftver csinálja).

Plusz, ami még nagy különbség, az a súgó nyelvezete. A magyar nyomtatvány mellé papíron is és elektronikusan is olyan szöveg tartozik, ami törvényeket idéz, referenciákkal teli, és igazából a válasz gyakran nincs ott (pl. azt mondja, hogy ebbe a mezőbe az XY törvény n cikkelye alapján meghatározott módon kell kiszámolni az akármit). Az angol verzióban valaki elolvasta a törvényt, és csak a konkrét kalkuláció lenne ott.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Online Nyomtatványkitöltő Alkalmazás A szolgáltatás 2019 óta érhető el.

https://onya.nav.gov.hu/

 

mondjuk komolytalan, mert csak 1-1 teljesen random beadvány érhető el mind magánszemélyként, mind cégként, de gondolom majd lesz egy kritikus pont

~ubuntu, raspbian, os x~

Talán igazad van, mert szarba nem nyúlok. (A gyengébbek kedvéert: java.)

Annyit azért én is tudok, hogy ez a topic tök felesleges, mert elég régen több java verziót is fel lehet rakni párhuzamosan - pont az ilyen inkompatibilitások miatt. Vajon a sok hozzászólás azért keletkezett, mert ezt mindenki tudja?

Nem nyúlsz hozzá, de szakértő vagy? :) Halkan jegyzem meg, hogy a hunyó a NAV, hiszen az ő felelőssége lenne könnyen használható disztribúciót csinálni az ÁNYK-ból, aminek része az is, hogy az user a letölt kattint használ metódussal működésre tudja bírni a cuccost. Ez az egyik része a dolognak, a másik meg, hogy a több lépésben kivezetett (deprecated majd törölt) függőséget meg kellett volna szüntetni. Az itt felsorolt hibák egyikse sem a Java hibája. Olyan programnyelvet meg runtime -t meg nem tudsz nekem mondani, amiben soha semmi nem változik, semmit sem törölnek ki belőle, és ne kapna helyette más újdonságokat. Mert ugyanez megtörténik a .NET -nél, meg a Pythonnál, meg a mindenhol, csak azokat az end user progikat nem a NAV gondozza, hanem hozzáértők, ezért kevésbé találkozol velük.

(és halkan jegyzem meg hogy felröhögtem a C-s megjegyzéseden. Ugye tudjuk hogy vendor és platform függően mennyire szét van forgácsolva az a világ, meg hogy a szabvány hemzseg a definiálatlan viselkedéstől, ellentétben a Java-val, ahol van a lang meg a VM spec, meg az OpenJDK, és csöcs (igen, az Oracle JDK is ott van, de az egy bővített OpenJDK, a legtöbb usernek megfelel az OpenJDK)).

Hááát, sokmindennek a szakértője vagyok, se hálistennek a listából a java kimaradt. :-)

Azt meg igazán nem tudtam, hogy az adóellenőrök programoznak. :-D

Nem tudom, melyik C-s megjegyzésemen röhögtél. Most inkább röhögj a java tökéletességén:

Jó tizenéve, amikor az MQ Series Integrator a 6.00 verzióról a 6.01-re lépett...egy messzi galaxisban...mindenki jól be volt szarva. Éppen akkoriban nekem is fel kellet adnom üzemszerűen két küldeményt MQ-n keresztül. Egyszer csak kaptam egy akkora levélkét, hogy majdnem felborult a gépem tőle. Pedig csak egy jóindulatú manáger küldte el az előbbihez szükséges update csomagot.

Nosza, elmentem az IBM ezzel foglalkozó oldalára és láss csodát! C esetében: do nothing.

Bizonyára kitaláltad, az irdatlan mennyiségű update a java klienshez kellett.

Innentől még a laikus számára is világos, hogy a java egy univerzális kalapács. Minden szeget minden falba be lehet vele verni!

Ehhez ugyan oda kell vinni a falat is meg a szeget is a kalapácshoz, de nem árt, ha a falhoz, a szeghez, meg a kalapácshoz is odarendelsz néhány szakértőt - mivel sikerült jól elbonyolítani. Ha nem így lenne, akkor ez a topic is rövidebb lenne. ;)

Legább van a lang meg a VM spec. Hurrá! Sőt, ha eléggé future proof vagy, akkor egy egyszerű táblázatkitöltő fut majd száz év múlva még a marsjárón is - bár ehhez a 30 éve deprecated dBase 2 is nagyágyú lenne. :-D

De a kérdésem örök: Milyen űr-rendszer kell egy táblázat kitöltéséhez?

Vajon a sok-sok - nem olyan mint én - SZAKÉRTŐ miért készít olyan dolgokat, amiknek időtállónak kellene lennie? Biztosan elrontják, hogy legyen később is munkájuk. :(

Aztán egyszer csak jön a következő okostojás, aki kitalálja: Baromarcú, aki a putchar() függvényt használja. És attól kezdve a C sem lesz "hordozható".

Nézd, az hogy fel kellett raknod  egy nagy update-t az MQ Series verzióváltás miatt magadnál, az ugye barátok között sem azért történt, mert véletlenül Java-ban írták meg.. A többi része elég homályos nekem. Igen, a NAV-nál van informatikai osztály (ha akarod megmutatom az épületüket is, a Lajos utcában van). Náluk kell kopogtatni, ha hülyeségeket csinálnak.

Nyilvánvalóan az én hibám, ti. nem kellett felraknom. Csak egy linuxra írt C forráskódot kaptam, amit AIX alatt lefordítottam. A ponén csak annyi, hogy ehhez a jóindulatú - mihez sem értő - ember a Windows java klienst küldte át.

Ami nem jött át, ezért szó szeritnt elmagyarázom:

A verzióváltás miatt a C kliens semmit nem változott, míg a java klienst komplett cserélni kellett. Ez bizonyára az időjárás és a globális felmelegedés miatt lehetett, vagy tán azért, mert én nem vagyok java szakértő. :-D

Halkan jegyzem meg, hogy a hunyó a NAV, hiszen az ő felelőssége lenne könnyen használható disztribúciót csinálni az ÁNYK-ból, aminek része az is, hogy az user a letölt kattint használ metódussal működésre tudja bírni a cuccost. Ez az egyik része a dolognak, a másik meg, hogy a több lépésben kivezetett (deprecated majd törölt) függőséget meg kellett volna szüntetni. Az itt felsorolt hibák egyikse sem a Java hibája.

Képzeld csak el ugyanezt a "deprecated putchar()" esetével. Megírod jóhiszeműen a programot, de nem vagy éléggé szemfüles (bocsika: szakértő). Aztán két év múlva újra kell írni a programot, lecserélni a libeket és az operációs rendszert. Vagy nem így van?

Nem hiszem, hogy a java választása a NAV informatikai osztály felelőssége lenne. Lássuk be, az informatikusok túlnyomó többsége abból él, hogy a szakmában folyó ámokfutások szakértője. Nevezheted akár munkának is. ;)

A lényegi kérdésre még nem válaszoltál, de senki sem: Milyen űrtechnika kell egy táblázat kitöltéséhez?

Off: van valami terv, hogy még mi mindent fognak kiszerelni a Java SE-ből profiltisztításilag? Azt meg is értem, hogy a JAXB meg a JAXWS olyan hihetetlenül enterprise eszközök [az előbbi XML elemző, az utóbbi WebService-hívó], amikre egy SE-felhasználók nincs és nem is lehet szüksége (lásd jelen topik tárgyát), de mi lesz a következő? Talán a JDBC-ODBC-híd? (Ja nem, azt a nyolcasban vették ki))

( kbalint v | 2020. 01. 07., k – 19:37 )

bocs, melyik kib**** JAVA-t rakjam fel MOST (2020-01-07)? új gépre kell telepítenem. köszi!

~ubuntu, raspbian, os x~

Nekem legutóbb a 8-as OpenJDK-val működött, én azzal kezdeném a próbálkozást.

Van egy funkció, amihez openJFX is kell (irat KAÜ-n keresztüli beküldése a programon belülről), az még trükkösebb, mert a legtöbb disztróban (Ubuntu-t és Manjaro-t próbáltam) az openjfx külön csomag, és egy frissítés óta csak a 11-es javával működik, a 8-assal nem. Ezért ezt a csomagot downgradelni és pinnelni kellett nálam. Ide leírtam, hogy ez milyen parancsokkal megy Ubuntu esetén: https://pastebin.com/d7aUrvKj

Más disztrón valahogy rá kell jönni, hogy hogy lehet a régi JFX-et feltenni, és ennek mi a verzió azonosítója az ő rendszerükben. Ésszerű megközelítés lehet virtuális gépbe telepíteni az ABEV-et, és az csak akkor piszkálni ha muszáj :-).

Az Oracle JRE-nek viszont beépítetten része volt a JFX még a 8-as időkben, legalábbis Windowson biztos, IMHO Linuxon is. Azzal tehát nincs probléma, felrakod a 8-ast és jóvan.

:D Ezt a kedves fejlesztőtől kérdezd (ÁK).

Volt már nem egy ilyen történet, elég csak elővenni az ÉTDR nevű "csodát".. vagy a KIR-t, utána KIR3-at mostmár KIRA-t... ÉTDR-be külön poén volt, hogy megadták hogy
márpedig Firefoxal + Java 1.6 -al megy csak .... Jah ezzel is ment csak mással se... 

Eltelik egy év.. nem megy az ÉTDR.. sorra jön a telefon.. Ja hogy a program "készítője" elfelejtette közölni a hivatalokkal hogy, jaa már Java1.7 Java7* kell! És már nem csak firefoxal megy!!!...

Csoda fejlesztések mennek odafenn állami szinten ....

Szóval rakd fel az _összes_ java-t is :D

( MGy v | 2020. 01. 08., sze – 10:20 )

Nem is nagyon fognak sportolni rajta, mert az utolsó ingyenes Oracle Java runtime a 1.8.0_201. 
Az elég gáz lenne, ha az állam olyan programot adna ki ingyen, amihez a használónak sok pénzért
kellene licencet venni az Oracletől, főleg hogy eddig nem így volt.

Ha jól emlékszem a linkelt java runtime esetén is kell licence.

Personal use , mivel a könyvelők begyűjtötték az ügyfelek ügyfélkapujait, így nem a könyvelő jár el mint könyvelő (értsd felelőség nuku), hanem megtestesítik az ügyfelet. :D

Amúgy a NISZ-es álláshirdetést miért nem lehet kommentelni? :D 

Regen rossz, hogyha a konyvelodnek megadod a sajat felh nevedet es jelszavadat.

Azzal rengeteg egyeb dologra is ralat/intezhet.

Lehet neki jogosultsagot is adni, es akkor nyomulhat a sajat nevevel. Ez a normalis hozzaallas.

 

Szoval akkor az eredeti kerdesemre a valasz? A konyveloiroda az personal vagy development use?

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Miért ne használhatná?

Csak ki kell fizetnie a licenc díját. :-)

Vagy futtathatja másik java-val.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Persze, hogy működik. Tegnap kb. 20 sec. alatt naprakészre hoztam (ennyi volt frissíteni a 3 éve el nem indított példányt a gépemen) Ubuntu alatt, pedig évek óta nem használtam. Majd a könyvelőm foglalkozik vele.

trey @ gépház

Pontosan. Szerintem az OpenJDK-val meg lehet csinálni szabályosan, hogy mellécsomagolják, vagy rosszabb esetben automatikusan mellétöltik működő konfigurációban. És nem csak MSI-t, hanem Linuxos kicsomagolom-működik telepítőt, neadjisten a népszerűbb Linuxokhoz repót is lehetne csinálni. 1 emberrel simán meg lehetne csinálni, ha valakinek ez lenne a dedikált dolga, és megspórolhatnánk az összes szellemi erőfeszítést mindenki másnak.

Ha muszáj óvodás szinten: akik nem szórakozásból akarnak mindenféle szarokat telepítgetni, hanem valamilyen egyesek által elképzelhetetlen okból tényleg szükségük van a magyar közigazgatási alkalmazásfejlesztés állatorvosi lovára, az ÁNYK-ra, azok vélhetően legalább 95%-ban valamely Windows verzió alatt szeretnék használni. Ugyanezen emberek jelentős részének nincs szüksége más okból a JRE-re. Az ő számukra a legegyszerűbb lenne, ha a fejlesztők közzétennének egy (két) msi-t, amiben benne van a JRE is, és akkor nincs inkompatibilitás, nincs hiányzó ez+az.

De ha arra gondolsz, hogy az SZJA-hoz nem kell az ÁNYK, akkor ennyi erővel azt is mondhatod, hogy a legtöbb usernek még saját magának bevallást sem kell készítenie, mert megcsinálja a munkáltató/NAV, szóval nekik még webböngésző sem kell.

Letöltöd, kitömöríted, rákattintasz és megy 100-ból 100-szor akárhogy van telepítve a Windows. Mitől lenne ez gányolás?

Maximum kicsit helypazarlás, de annak aki spórolni akar még mindig oda lehet adni a nyers jar-t a leírással, hogy mik a függőségei.

Egyetértek. Elég lenne egy link arra a bináris disztribúcióra amivel tesztelték is. Linux alatt tényleg könnyű 20 másodperc alatt felenni, frissíteni. Windowsra nem triviális lefordított 8-as OpenJdk-t találni, legalábbis nekem nem volt az - valami azul.com címen találtam.

( x-daemon | 2020. 01. 08., sze – 20:03 )

nem akarom a kedveteket elvenni a bevallastol, de debian 10.2-alatt elindul:

~/abevjava$ ./abevjava_start
java.util.Arrays.useLegacyMergeSort = true
main args
0. |cfg=cfg.enyk|
1. ||
2. ||
3. ||
Operációs rendszer = linux,unknown
Java verzió = 11.0.5
abevjava 2.94.0-01
file.encoding = UTF-8

# apt-show-versions |grep jdk
openjdk-11-jre:amd64/buster 11.0.5+10-1~deb10u1 uptodate
openjdk-11-jre-headless:amd64/buster 11.0.5+10-1~deb10u1 uptodate

neked aztan fura humorod van...