Megjelent az ABEV nyomtatványok kitöltéséhez szükséges keretprogram JAVA változata

Hír

A www.apeh.hu/bevallasok/nyomtatvany oldalról letölthető az ABEV nyomtatványok kitöltéséhez szükséges keretprogram JAVA változata.

Jelenleg csak a 0753 valamint a kapcsolódó egysza és rendnyil nyomtatványok állnak rendelkezésre a Linux disztribúciókon is futtatható AbevJava programhoz. Üzembe helyezéséhez Java futtatási környezet szükséges, JRE 1.4.2_12 vagy magasabb verzió.

A telepítési útmutató megtalálható itt.

( janusz | 2008. 01. 07., h – 22:09 )

hat mar a telepito is tobb sebbol verzik
csak rootkent lehet telepiteni mert az etc ala akar majmolni
aztan persze meg telepitesskor kell megadni az elmentett dolgok helyet (grrrr),
persze ha ezt a sajat home-omra allitom akkor nem lesznek jok a jogok
persze berakott szepen a root homjaba valami config fileokat (de akkor mi a raknak kellett az etc) emiatt most nem indul userkent....

Folytatom:

java.io.IOException: java.io.IOException: /bin/bash: not found

Ezzel azért még lesznek gondok. Lévén olyan rendszer még van, min fut Java, esetleg még desktopnak is lehet(ne) használni, de nincs /bin/bash.

(És az elindulás után a telepítőablak fejléce a sokat mondó íő szöveget tartalmazza.)

ezeket? :D

nagy bonyolultságú műveleteket végez :P 


 	<file os="lin" filename="{DESTINATIONDIR}/abevjava_main_upgrade" filetype="script" charset="UTF-8">
            <lines>
		<line>#!/bin/bash</line>	               
                <line>cp {DESTINATIONDIR}/upgrade/abevjava.update {DESTINATIONDIR}/abevjava.jar</line>
                <line>rm {DESTINATIONDIR}/upgrade/abevjava.update </line>
            </lines>
        </file>

szerintem az nem paranoia kerdese, hogy linuxon defaultbol nem rootkent hasznaljuk a programokat

foleg hogy ahogy nezem csak kivitelezesi hiba, hogy csak rootkent megy (hozza kell tennem hogy a legutobbi linuxos probalkozas is pont igy inditott, szerencsere ezt a dolgot gyorsan orvosoltak, persze aztan elhalt az egesz project de az mas kerdes)

Én csak a szeparációra, mint lehetőségre mutattam rá. Az implementáció sokféle lehet. A virtuális image mellett az szól, hogy felmásolod az user desktop-jára, az egy duplakattintással elindítja, és bevall. Nem kell a gépet újraindítani, stb. A Linux disztrók nagy részében van virtualbox, qemu, meg amit akarsz. Ha meg nem kell, le lehet törölni.

--
trey @ gépház

Nem csak magányos farkasok vannak akik alternatív oprendszert használnak. Nálunk a szűkebb családban pl. mindenki azt használ. Akkor most a központi gépre csináljak direkt egy APEH group-ot, és abba vegyek fel minden adózót? És annak a group-nak adjam oda ezt a konfigfájlt vagy mi a nyavalyát? Esetleg még jobb, rakjak a fájlra ACL-eket?

( xtonix | 2008. 01. 07., h – 22:19 )

ha már egyszer java, akkor minek ennyi telepítgetés???
Miért kell elkomplikálni az egyszerű dolgokat? :(

( sly007 v | 2008. 01. 07., h – 22:24 )

Hmmm. Java? Vissza lehet fejteni, ha valami gond van vele. :-)

Erdekes lehet ez a program. Tartalmaz apacs licenszu kodot, gpl-es kodot, w3c lincenszu reszletet, stb... Az az ember erzese, hogy fogtak egy rakas free cuccot, osszegyalultak, magyaritottak es kiadtak. Ne legyen igazam.

Amugy ezek alapjan lehet, hogy el lehetne kerni a kodot es javitva visszaadni nekik... :)

( N_and_Y | 2008. 01. 07., h – 22:45 )

Nem vagyok egy nagyon-meki-fan, remélem idén hivatalosan és natívan ejthetem meg az adózási kötelezettségeimet a zubuntummal, de:

Mekintos-on senki nem vall az APEH szerint? Vagy létezik, hogy ez a java nem fut a meki os-ével? És a többi java képes OS?
Persze, csak kötözködöm. De akkor is: olyan nagy kandiscukor lett volna, ha azt írják kb. hogy
"az új program minden java-képes renceren műxik, mint például: , ." ?

ehelyett:

A program az alábbi operációs rendszereken fut:
Windows 98
Windows ME
Windows 2000
Windows XP Home
Windows XP Professional
Windows Vista
Linux-disztribúciók

Én megpróbáltam. Miután kézzel létrehoztam az 

/etc/abevjavapath.cfg

file-t, az installer gond nélkül lefutott. Most az a problémám, hogy se a menübe, se a desktopra nem került fel semmi, amivel elindíthatnám. Mondjuk OS X alatt nem is ismerek olyan menüt, ami programok indítására szolgálna és a desktopon található 

Abevjava.desktop

file se jelent túl sokat az oprendszernek, de ezzel még nincs gondom. Viszont hiányzik az 

/usr/local/abevjava/abevjava_start

file is. Hogy ebben minek kéne lennie?
Így sikerült elindítanom: 

moria:/usr/local/abevjava saabi$ java -jar abevjava.jar 
message = user.home=/Users/saabi
message = KRDIR=
HelpPanelBusiness.updateHelpPanel: file:/usr/local/abevjava/segitseg/enyk_index.html
maxInMemory=19

Ave, Saabi.

Én is így képzeltem, mégse jött létre az indító file az /usr/local/abevjava alatt. Amúgy nem értem, miért hiszik itt néhányan, hogy root-ként kell telepíteni? Én csak annyit csináltam root-ként, hogy létrehoztam az /etc-ben azt a konfig file-t (nem jut eszembe a neve) és megadtam neki a sátán jogát (666). Ezután az installer már az én, egyszerű felhasználói jogosultságommal futott. Különösebb gond nélkül, csak az indítófile maradt le, de arra sincs igazán nagy szükség.
Persze az is igaz, hogy mindezt OSX-en próbáltam, nem Linux-on.

Ave, Saabi.

Ahem, nálad egy konfigurációs file elhegyezése az arra való könyvtárban egyet jelent a root-ként futtatással?
Amúgy minden általam ismert operációs rendszerben illő az alkalmazások telepítését rendszergazdaként elvégezni, majd azokat felhasználóként használatba venni. A /etc éppenséggel a legalkalmasabb helye a rendszerszintű konfigurációs állományoknak és nagyon helyesen csak a root-nak van (kellene hogy legyen) joga azt módosítani.
Amúgy megtekintve a telepítés menetét, nem hiszem hogy különösebben nagy feladat ebből a programból .rpm vagy .deb (vagy ami tetszik) csomagot csinálni. Amit persze szintént rendszergazdaként kell telepíteni, de akkor már senkit se zavarna.

Ave, Saabi.

Engem zavarna.
Nagyon szeretnem, ha az APEH tanusitott oldalarol letoltheto(/letoltodo), tanusitott,
webstartos, vagy veges szamu .jar masolasat - mint telepitest - igenylo alkalmazasrol lenne szo.
(bar buktato, hogy nemelyik rendszerben a "-cp ." nem default opcio!)

Semmi kulso beavatkozast nem szeretnek az alkalmazas
APEH/ugyfelkapu -tol hozzam, mint felhasznalohoz kerulese koze.
(pl. 3. fel altal nyujtott rpm-, deb-be valo csomagolas.)

Mivel a java parancs ilyen sikhulye sajnos igen. Nem minden esetben mukodik a jar-ok felszedese javabol ugyanis. En mar lattam olyant, hogy a tartalmazo mappat megadtam classpath-nak, es az app kozolte, hogy ott nem talalja a libet. Utana kozvetlen a jar-t adtam meg, es lam. Ha lenne config alapu inditas, sokkal egyszerubb lenne az elet. De az ant is csak ugyanezt ganyolja, vajon miert?

Ha "-cp ."-t megeszi, akkor abbol latszik, hogy konyvtarat is. ;)
Csak annak adtam hangot, hogy a parancssorba be kell szurni a classpatht indulaskor, mert nem lesz minden rendszeren beallitva meg, ha a megoldasszallito tesztrendszeren esetleg ugy is lenne. A jelenlegi 'telepito' mukodesebol, pedig nem tunik ugy, hogy ez elvarhato a termektol.

De elsikkadt a lenyeg! A biztos forrasbol megszerezheto, nem modositott es nem telepitendo - mivel csak futnia kell valahol mezei userkent - porgram.
Nem kellene tulbonyolitani egy, vagy tobb .jar es egy parancs esetet.

On Linux prior to kernel 2.6.23, the memory used to store the environment and argument strings was limited to 32 pages (defined by the kernel constant MAX_ARG_PAGES). On architectures with a 4-kB page size, this yields a maximum size of 128 kB.

On kernel 2.6.23 and later, most architectures support a size limit derived from the soft RLIMIT_STACK resource limit (see getrlimit(2)). For these architectures, the total size is limited to 1/4 of the allowed stack size, the limit per string is 32 pages (the kernel constant MAX_ARG_STRLEN), and the maximum number of strings is 0x7FFFFFFF. (This change allows programs to have a much larger argument and/or environment list. Imposing the 1/4-limit ensures that the new program always has some stack space.) Architectures with no memory management unit are excepted: they maintain the pre-2.6.23 limit.

Mire gondolsz ? xargs(1)

Vagy tul lassú ?

saabi:
"Amúgy nem értem, miért hiszik itt néhányan, hogy root-ként kell telepíteni? Én csak annyit csináltam root-ként, hogy"

vs.

saabi:
"Amúgy minden általam ismert operációs rendszerben illő az alkalmazások telepítését rendszergazdaként elvégezni"

Eldönthetnéd, hogy mit is szeretnél mondani, mielőtt nekikezdesz.

Amúgy nem egy szokásos dolog a /etc -ben tárolni egy felhasználói program telepítési helyét.

Ott a pont! :-)

Azt szeretném csak mondani, hogy egyrészt nem kell root-nak lenned ahhoz, hogy telepítsd, megy az root jog nélkül is, ha azt az egyetlen konfig file-t létrehozod elötte kézzel. Vagy ha adsz írásjogot az /etc könyvtáradra. Másrészt én nem látok problémát abban, hogy egy alkalmazást rendszergazdai jogkörrel kelljen telepíteni. Mások sírtak emiatt.

Installáltál már Oracle RDBMS-t? Azt elvileg az oracle:oinstall (vagy oracle:dba) user nevében csinálod, de a telepítés közepén felszólít, hogy futtasd a /mittoménhol/root.sh scriptet root-ként. Hogy miért? Mert bizony elhelyez egy-két konfigurációs file-t a /etc-ben.

Amúgy mi az hogy felhasználói program meg nem felhasználói program? Az általam ismert *nix-os világban van globális konfiguráció és lokális. A globálisnak a /etc-ben, a lokálisnak a $HOME-ban van a helye. Ilyen "felhasználói", "nem felhasználói" marhaságról még nem hallottam.

Ave, Saabi.

1, akkor a felhasználó ne telepítsen. Kérje meg rendszergazdáját, orvosát, gyógyszerészét!

2, Ez már filozófia. Jelen változata a programnak ott keresi, ezért ott kell lennie.

3, Ennek semmi köze ahhoz, hogy egy programot miképpen konfigurálnak. Mint azt írtam, *nix rendszerekben van globális és van lokális konfigurálási lehetőség. A globális helye a /etc, a lokálisé a $HOME. Hogy az adott progam mi célra való, ebből a szempontból érdektelen.

Ave, Saabi.
(ps: ez már elég rövid hogy végigolvassátok?)

Legyen neked. Én ugyan a jar file-t nem root-ként futtattam, de biztos elrontottam valamit. Ugyanakkor nem látnék abban sem problémát, ha ezt root-ként kellett volna megtennem.
Olyan programok elég sokan vannak, melyek a /etc-ből veszik a beállításaikat, még talán felhasználói programok is. :-D Ezek mind bénák. Értem.

Ave, Saabi.

( BaT | 2008. 01. 07., h – 23:09 )

Gondoltam ilyen alkalmak egy évben egyszer vannak, ezért ki kellene próbálni. kdesu-val felraktam /home/tibi alá (gyorsan le lehet törölni ugye :)), aztán egy gyors chmod, hogy a saját könyvtáramban azt csináljak, amit akarok. De sajnos nem fut.

Majd holnap elolvasom a telepítési útmutatót, most csak gyorsteszt volt. Ezt azért nem adtam volna ki 1.0-ként, 0.1-nek elment volna...

Szerk: mv /root/.abevjava /home/tibi/;mv ~/.abevjava/root.enyk ~/.abevjava/tibi.enyk és minden fut jól.

Javaslat:
- Amikor nem tud adott helyre irkálni telepítő, akkor kérdezzen rá a root jelszóra (su -c "amitakarsz").
- A .abevjava alatti file ne a felhasználó neve legyen, hanem valami általános filenév.

Ja, és nézzetek be a license könyvtárba. Hátha bele tudtok kötni. :)

( nagy_peter v | 2008. 01. 07., h – 22:52 )

Én már annak is örülök, hogy végre van egy működő kliensporgoram, amire oda van írva, hogy támogatott: Linuxon.
Lehet, hogy még több sebből vérzik, de legalább már van. Mire eljön az adózás ideje, szerintem már rendesen menni is fog. Én inkább azt mondom, építő jelleggel össze kéne gyüjteni a közösségi észrevételeket, és küldeni a fejlesztők felé. Legalább ne azt lássák, hogy csak szidjuk...

Nagy Péter
www.konquer.org

itt van lent/fent összegyűjtve.
- egy _személyes_ adataimmal garázdálkodó program ne akarjon root-ként települni.
- sehogyse akarjon települni, fusson e nélkül (esetleg legyen leírva a doksijába, h kell neki egy ~/.APEH/abev.cfg
- ne hívogasson már bash -t. Ha egyáltalán, akkor is sh-t, de akkor az már régen rossz.
- ablakkezelő hülyeség kijavítandó. Nem tudom mi akar lenni az íő (mondjuk a telepítő pont jó, de akkor is).
- és í. t.

Egyetértek azzal, aki szerint elírták a verziószámot.

én azt nem értem, hogy miért kell JAVA-t használó programnak települni? Különben meg vannak fasza java installer készítő cuccok. Aki meg azon csodálkozott, hogy miért van egy rakat licenc benne: hát azért, mert nem akartak mindent előről megírni, a különböző libek, keretrendszerek, gui templates dolgok, xml parserek, javadb - ha van benne, gondolom igen, még nem néztem de az értelmes választás lenne adattárolásra - mind más licenccel lett kiadva. Használták az open source dolgokat, ennek örüljünk és kampányoljunk vele! Ha már működő a program. Lássátok hát: mindenhol fut, alig kellett valamit fejleszteniük a saját cuccokhoz képest, itten van minden open source komponensekből.

Ne legyen semmiféle sh vagy bash a scriptekbe. Ha már java-ban csinálják, akkor csinálják platformfüggetlenül, és akkor dobhatják is a windowsos programot, elég egyet karbantartani. Ráadásul úgy egyszerűbb is. Lehet webstarttal, és akkor az update is meg van oldva, vagy meg lehet írni saját maguknak, vagy ha mindenképp installálni akarnak akkor millió+1 akár free, akár fizetős install framework van, ami teljesen platform függetlenül csinálja a dolgát, max. a windows többségnek csinálhatnak egy .exe -t, hogy ne legyen elvárás a telepített jvm.

"elég egyet karbantartani. Ráadásul úgy egyszerűbb is"

Sztem annak szánják, mert a letöltött .jar fájl települ Windowsra is. Most próbáltam, igaz userként, itt is akar szemetelni a Windows könyvtárba (ugye itt jön be az, hogy itt meg illene a registry-t használni, bár egy alkalmazás könyvtárát letárolni, hááát. Legalábbis ha arra szolgál a fájl, amire a neve utalna).

Egyébként vhol érthető, hogy rendszergazdaként kell telepíteni: mezei user miért telepítgessen?

Egyébként vhol érthető, hogy rendszergazdaként kell telepíteni: mezei user miért telepítgessen?

Nem ertheto. Idegen - kulonosen erzekeny adatokat hasznalo -, nem auditalt programot nem futtat a root.
rootkent maximum felmasolni lennek hajlando egy ilyen .jar-t.

A sajat user sem futtatja, csak testuser homokozoban.

APEH-tol eltekintve, user telepithet a sajat $HOME ala, az azert van.
Ahol nem telepithet, ott ha sikerulne is neki bejuttatni nem tudna futtatni - de ez mar nem ide tartozik.

használjnak csak webstartot, az az elterjedtebb op. rendszereken gond nélkül megy (windows, mac, linux), szépen kirakja a desktopra/start menube/stb az ikont és utána frissíti saját magát, amikor kell. A mindenféle beállításokat ne ilyen fos módon tárolják, lehet ezt is platformfüggetlenül (pl preferences api). Az egzotikus operációs rendszerek felhasználói pedig szépen letöltik a .jnlp file-ban felsorolt JAR-okat, és elindítják kézzel.

"Én inkább azt mondom, építő jelleggel össze kéne gyüjteni a közösségi észrevételeket, és küldeni a fejlesztők felé."

Szép dolog ez tényleg, de ez nem egy free project, ezért valaki pénzt kapott, gyaníthatóan nem is keveset.
Miközben olyan tervezési hibákról beszélünk, ami már több (igaz haladó, de mégis csak) felhasználónak feltűnt.

Azt már meg sem említem, hogy mióta készül, illetve miről is beszélünk? Egy űrlapkitöltő szoftverről?

Nézzétek el nekem, hogy nem járok örömtáncot...

(Kérdés azokhoz akik próbálták: az előzetesen beharangozott sebességproblémákat sikerült megoldani?)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

köszönöm a támogatást, én is valami hasonlóra gondoltam. Nyílván nem rosszindulatból kerültek bele a hibák, és (nézzétek el nekem, elsőre jót feltétlezek mindenkiről) biztosan ha megmondjuk, hogy mi nem működik, szívesen kijavítják a hibákat.

Persze lehet szidkozódni, meg írni, hogy milyen működésképtelen, de koréntsem hiszem, hogy azzal kényelmesebb lesz beadni vele az ürlapokat.
Inkább legyen egy működőképes Linuxos kliens, amiben segítünk, hiszen később úgyis nekünk kell majd használni is. Lehet, hogy nem mi kapunk érte pénzt, de mi szívunk vele, ha nem működik rendesen. Viszont amíg nem tudjuk, hogy a fejlesztőkek mi a véleménye, álljunk hozzá úgy, hogy biztosan szívesen javítják, ha megmondjuk, mi nem működik.

Nagy Péter
www.konquer.org

Kb egyetértek, de csak hozzátartozik az igazsághoz az is, h egy fejlesztésnél ha kijön az 1.0.0-s verzió, azt ilyen (a fenti szintű) hibáktól mentesen illik elérhetővé tenni, és nem a felhasználók, hanem a fejlesztőgárda erre rendelt része végzi a bétatesztelést.

És jelzem, hogy nekem speciel semmilyen örömmel nem jár, ha a windows-os mellett előáll egy linuxos verzió - számomra majdnem ugyananyira használhatatlan. Ha már sikerült Java-ban megírni, akkor az legyen platformfüggetlen, azaz a (milliószámú tök különböző) Linux-disztrók mellett fusson azon a 4 db különböző BSD-n amit egyáltalán érdemes megemlíteni, meg fusson makkosikszen is, meg Solarison, meg HP-UX-on, meg. meg. meg. Ha már egyszer platformfüggetlen. Van Java-s fejlesztő haverom, aki egy bankban az elsősorban Windows-t futtató klienseknek FreeBSD-n fejleszti az alkalmazást, amelyet ugyanakkor tesztelnek két másik kollega (asszem) különböző Linuxán, valamint Solarison *is*. És megy. Azaz meg lehet csinálni.

(És nem hívunk /bin/bash-t egy cp vagy mkdir kedvéért.)

Látom flame megy, olvasás nem.
Ne vedd személyeskedésnek, nem te vagy az egyetlen, aki elolvassa ugyan a hozzászólásokat, de nem érti.

A bajom az, hogy úgy sikerült platformfüggetlen kódot írni, ahogy annak semmi értelme. Ha Java, akkor tudjon működni heggesztés nélkül máson is. Nem az a bajom, hogy FreeBSD-n nem ment elsőre. Valószínűleg vagyok azon a szinten, hogy tudnék /bin/bash -t csinálni a gépemre, ha akarnék. De induljunk ki abból, hogy pl. mac-en maga a futtatandó nem lett meg, és az már szerintem Saabi leleményén (nem mintha lenne neki ilyen, tőlem kért tanácsot hozzá) múlik, hogy ki tudta találni, mi kell ahhoz, hogy el tudja indítani. Ezzel szemben ugye azt szokták mondani, hogy a 0 tudású számítógépfelhasználók számára a mac oprendszere az igazán ideális, mert minden megy. Hát ez még nem.

( szimszon | 2008. 01. 07., h – 23:03 )

Nekem a trükközésekkel azért elindult, bár először a
java -jar .abevjava/abevjava.jar -ral indítottam. Mivel a .abevjava könyvtárba telepíttettem _mindent_. De így a telepített nyomtatványt nem találta. Majd rátaláltam az abevjava_start scriptre... :)

( Nyizsa v | 2008. 01. 07., h – 23:30 )

Ahogy nekem sikerült + 1. bug report:

# touch /etc/abevjava.cfg
# chown nyizsa /etc/abevjava.cfg
# chgrp users /etc/abevjava.cfg

$ java -jar abevjava_install_1_0_0.jar

Szó nélkül fel is települt. Telepitettem hozzá a nyomtatványt is, eddig okénak tűnik.
A bug: teljes képernyőre váltva nem működnek a menük. Ha rákattintok, megjelennek, ha felengedem az egárgombot, eltűnnek. Persze nem lehet semmit se kiválasztani belőlük. Visszaváltva "nem teljes képernyőre" megjavul. Sőt, ha az ablak sarkainál fogva nagyitom fel, akkor is működik (ahogy vártam is), csak a Maximize gomb után nem.
Debian Etch, Xfce 4.3.99.2, sun-java6-jre 6-00-2~bpo.1

Ötlet, hogy hova küldhetném? Van egy levélküldő form az apeh.hu-n, de ezért a bug reportért nem fogom megadni a személyes adataimat.

--
Debian - The "What?!" starts not!

> ...nekem megy root ként :)

Root-ként nem próbáltam, és nem is szándékozom. A fenti bugon kivül userként is oké, persze csak kattintgattam ide-oda, nem végeztem stressz-tesztet. Majd saját magamon, március vége felé. :))

--
Debian - The "What?!" starts not!

( szdl | 2008. 01. 08., k – 00:09 )

1. Ez jó hír.

2. Sajnos a kontraszelekció itt is nagy úr volt:

- Miért kell root jog?

- Miért kell XML-be rakni shellscriptet?

- Miért csak bash-ra gondolnak?

- Ha már java, miért nem univerzális? (MacOSX, Solaris, OS/2, OSsatöbbi..?)

A kérdéseidre a válasz ugyanaz. :-) Wines embereket megkértek, hogy csinálják meg java-ban,de azon a linux izén is fusson,mert nagy volt a rinya. Megírták,de mivel ők nem igazán értettek Windows-on kívűl máshoz,ezért ez lett belőle. Most már nem mondhatják, hogy nincs. :-)

( Mico v | 2008. 01. 08., k – 03:27 )

Durva lesz, de aki ezt csinálta, engedte kiadni, azt Dunába kéne lőni. Mi az, hogy root, mi az hogy bash kell neki? Egy JAVA programnál, könyörgöm... ez mélyen alulmúlja bármelyik csakwindowson, csakadminként, BDE engine-es Delphi program készítőjét.

Ez egy:
- fricska a pofánkba: "teljesen mindegy, mit adunk ki, mert úgyis le van zsírozva, józsi elintézte az apeh-nál, most már 2050-ig úgyis mi vagyunk az apeh programozó alvállalkozói"
- "lám, megmondtuk, hogy nem érdemes linuxra fejleszteni" - miután sok gond lesz ezzel a fossal
- szörnyűség, amelyet a saját magát valamire is becsülő ember nem ad ki
- szörnyűség, amelyet egy valamennyire is hozzáértő programozó soha nem követne el
- szörnyűség, amiért egy Java programozó felvágná az ereit
- szörnyűség, aminél innen bárki jobbat sz@rik.

Ez most csak ugye valami vicc?

ah, nem. nem vicc. ez a szomoru benne. legalabb nevetni lehetne rajta...

dehat ez van, nem csak az apehnel, de mindenutt mashol is..

- gyere jozsi, mondd, tudsz programozni?
- hat nem fonok elvtars..
- sebaj, van valami java nevu dolog, ugy hallottam jo, es azzal betomhetnenk a pofajukat ezeknek az ingyenelo linuxfanboyoknak. tanuljad meg, aztan csinaljal benne valamit, aztan felezzuk a penzt. mitszolsz?
- hat jo, ugyis kene mar a futes a kinti medencebe... de meg sosem programoztam...
- az nem baj, majd keresel magad ala par palyakezdot, akik megcsinaljak olcsoan, mert nekemis
kell az uj kocsi
- jolvan batyam, akkor megyunk vadaszni a heten?
- megyunk jozsi, megyunk

( padawan | 2008. 01. 08., k – 07:06 )

De legalabb van. Majd lesz meg jobb is :)

( Polesz v | 2008. 01. 08., k – 07:35 )

Egy kérdés? Nyomtatványt hogy kell bemásolni? ;-)

--
A nyúl egy igazi jellem. Ott ül a fűben, de akkor sem szívja!

( pepo v | 2008. 01. 08., k – 09:53 )

Azért ez durva:

Hiba a paraméter állományok beállításánál(java.io.FileNotFoundException: /etc/abevjavapath.cfg (Permission denied))

Az /etc/abevjavapath.cfg-nak 0666-os a joga...

(Nem root-ként telepítem...)

Szerk: ja, elgepeltem a abevjavapath.cfg nevet. De akkor sem "permission denied", hanem "No such file or directory".

( hrgy84 | 2008. 01. 08., k – 09:44 )

Ahogy elnézem, még mindig nem érdemes azoknak váltani, akik kézen-közön beszerezték a program régebbi, Borland cuccokkal gyártott megfelelőjét, és nincs vele problémájuk. Az legalább rendesen működött.

( pepo v | 2008. 01. 08., k – 10:23 )

Nem kompatibilis az windowsos verzió elmentett állományaival... Lehet, hogy létre kell hozni egy imp állományt a má$ik futtatási környezetben, majd be kell importálni???? (Na, meglesem.)

Szerk.: Ja, a Javas környezetben nincs importálási lehetőség...

( igiboy | 2008. 01. 08., k – 10:32 )

1. ha jolértem a futtátáshoz kell root jog... NA NEHOGYMÁÁÁÁ, azért használok linuxot hogy megkiméljem magamat a rendszergazdaként ügyeskedő programoktól, erre itt van ez. (nemhogy linuxot nem látott aki irta, de szerintem még a pistát sem tette fel a gépére, vagy kikapcsolt benne minden bizbaszt ami megakadályozza a photoshoppatch.exe futtatását, mert ő ért a géphez és rendszergazdaként használja, ja ért...)
2. minek telepíteni egy nyomtatványt??? Nem lehetne megoldaniuk hogy 1 fájl és kész. Esetleg neaggyisten felmenne az abev a netre és letöltené bemésolná az abev program könyvtárába, ami kell.
3. Esetleg a kitöltött nyomtatványt is feltölteni ezen a felületen keresztül, csak név+jelszó kellene hogy hová akarod.

999. minek egyáltalán adózni? :)

( wladek1 | 2008. 01. 08., k – 11:42 )

rootkit magyar módra :) De legalább van. qemu-ban csak nem okoz majd problémát.

__

Zopr miafene

( igiboy | 2008. 01. 08., k – 12:03 )

Na akkor valaki rendesen leirná hogy mégis hogy kell feltenni ezt a csodát. Lehetőleg úgy hogy utánna normál userként tudjam majd futtatni.
Eddig próbáltam, de csak root-ként futtatható volt. Igy meg nem fog futni.

Szerintem fentebb leírt módokon megoldható. De itt van összegyűjtve: (bocs, kicsit szájbarágósan) 


sudo touch /etc/abevjavapath.cfg

vagy:
      sudo chown FELHASZNALONEVED /etc/abevjavapath.cfg
      chgrp FELHASZNALOCSOPORTOD /etc/abevjavapath.cfg
vagy:
      chmod 0666 /etc/abevjavapath.cfg

mkdir ~/AHOVA_LE_AKAROD_TOLTENI
cd ~/AHOVA_LE_AKAROD_TOLTENI
wget http://www.apeh.hu/data/cms36637/abevjava_install_1_0_0.jar
java -jar abevjava_install_1_0_0.jar

Én a telepítéskor a /home/FELHNEVEM/abevjava könyvtárat adtam meg.
Ezzel feltelepíted a keretprogramot.

Kell hozzá a 0753 bevallófelület is, azt is telepíteni kell: 


wget http://www.apeh.hu/data/cms36648/APEH_0753_2_12.jar
java -jar APEH_0753_2_12.jar

Ennyi. A hátrányairól fentebb bővebben olvashatsz, de félig-meddig userként, félig-meddig rootként így lehet telepíteni.

( storeplace | 2008. 01. 08., k – 13:58 )

Sziasztok !

Ide lőjetek! (ne a Dunába :( )

Nem vagyunk teljesen hülyék sem a linuxhoz, sem a java-hoz. Lehet, hogy nem úgy sikerültek a dolgok ahogy akár Ti szeretnétek, akár mi szerettük volna, de nem csaptuk össze a munkát és nem direkt rossz szándék vezetett.
A telepítést nem feltétlenül csak Nektek szántuk, hanem annak a windows felhasználónak is aki a duplaklikknél megállt és sem kedve sem szándéka sincs semmiféle beállításokkal ügyködni.
Ráadásul az sem volt szándékunk, hogy csak rootként menjen a progi, ha így van, valami nem sikerült.
Szívesen fogadunk mindenféle építő kritikát, azért is kértem ide 1 reget.
Szerintem az apeh is támogatna akár 1 rpm-et akár más telepítési segítséget, de ezt persze nem garantálhatom.
Szóval várjuk a javaslatokat és ha kérdésetek van megpróbálunk rá válaszolni.
Minden jót.

> A telepítést nem feltétlenül csak Nektek szántuk, hanem annak a windows felhasználónak is aki a duplaklikknél megállt és sem kedve sem szándéka sincs semmiféle beállításokkal ügyködni.

Hát izé. Ez viccnek gyenge, ha tényleg így gondolod, vicces. Fentebb írták többen a JNLP alapú deploymentről ami egyklikkes telepítési metódus, pontosan az alulművelt Windows/Linux/BSD/Solaris/Mac felhasználók kedvéért. Már ha tényleg az volt a cél, hogy egyszerűen telepíthető és használható program legyen a dologból. Ez így... hogy finoman fejezzem ki magam... eléggé összecsapott munkának tűnik, közel sem igényes programnak. De sebaj, elsőre sose sikerül semmi, második nekifutásra csak sikerül valami használhatóbbat is összehozni.

Nem arról van szó, hogy most kaptunk mi is valamit, és fikázzuk, de ha egy picit is elfogulatlanul megnéznéd a programot, akkor ez már terv állapotában a szemeteskosárba landolt volna. Tényleg olyan érzése van az embernek, hogy felszedtek valakit utcáról, és kapott egy hetet rá.

Más: A régebbi formátumok supportjának dobása ugye azt jelenti, hogy lesznek konverter eszközök? Mert különben innen mondom, hogy egy még nagyobb hőbörgési hullámmal néztek farkasszemet.

Volt egy olyan változata a proginak, amikor annyi mindent kellett olyan sok helyre bejegyezni, meg annyi felé figyelni, hogy jobb ötletenek tűnt, ha amit lehet mi magunk írunk meg. Persze lehet vitatkozni, hogy a mostani változatban ez e a legjobb megoldás, de most már 1 darabig biztosan így marad. Persze a telepítésen mindenképpen javítani fogunk. Tuti, hogy nem root ként is megy/menni fog.

ehhez kapcsolodik, hogy jo lenne automata frissites is minden indulaskor.

nehany ablaknal le van tiltva az atmeretezes es emiatt vizszintesen kell scrollozni, (ez mar a masik abevnel is undorito volt szerintem, foleg az update reszenel,) ezen is kene valtoztatni.

vegul amit sose ertettem, miert nem tudja a progi feltolteni a bevallast a netre egy gombnyomasra?

vízszintes scroll: felvesszük a listára
automata frissítés -lesz

Feltöltés.
Ez nem ilyen 1xű kérdés. Jelenleg a bevallásokat NEM az apeh fogadja közvetlenül, hanem a Mo.hu. Ők írták a feltöltőt, ami adott helyen keres, megnéz pár dolgot és feltölti. Ha már csináltad láttad, hogy elég komoly azonosítás van előtte. Ez azért nem mp3 a haveroknak.
Csak 1 kérdés: Hogyan azonosítanád magadat feltöltés előtt?

aha. az x.y.z.w címről jött a Mol bevallása. Visszakért 4mrd Ft-ot a xxx-xxx számlára. Hát jó, biztos így van, legfeljebb majd kikeressük, hogy melyik ip címről ki is adta be, ha nem stimmel valami.
Azért beláthatod, hogy ez nem ilyen 1xű. Jó, persze a pl. is sántít.

valamit felreertessz, mar miert is ne lehetne valami jol kidolgozott API-n keresztul feltolteni a fajlokat?
persze abbol amit leirtal kovetkezik, hogy a mo.hu-nak kene megterveznie/megcsinalnia a feluletet, te csak hasznalnad.
nem gondolom, hogy ez olyan nagy feladat lenne, ugyanakkor a felhasznaloknak jelentosen konnyitene a dolgat.

ha a hup.hu ugy mukodne, mint az abev, akkor a hozzaszolas elkuldese gombra kattintva pop-up-ba bejonne a freemail belepes oldala, es azon belepve kene uj level formajaban a hozzaszolas @ hup.hu-ra elkuldeni a hozzaszolast, jo kicsit sarkitott a pelda, de ha egyszeru felhasznalo szemmel nezed, akkor pont ez a helyzet.

en velemenyem az, hogy ez a funkcio _nelkulozhetetlen_ alapfunkcioja kene legyen a programnak.

Szia

Korabban irtak ugyfelkapus user/pass, tehat azonositas is van, igy azert eldontheto hogy xy user jogosult-e a Mol bevallasra, vagy csak jatszik. Pl. feltolteshez feldobhat egy ablakot, hogy irja be a felhasznaloi nevet / jelszot, esetleg felhasznalo nevet megjegyezheti.
Semmi tech. akadalyat nem latom annak, hogy a programbol is lehessen feltolteni bevallast.

York.

------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."

Végülis igazatok van. Tulajdonképpen az ebev régebbi verziójában, ami közvetlenül az apeh-hez töltötte a bevallást volt 1 feltöltő applet. Valami hasonló itt is menne.
A döntés az apeh-é. Ha kérnék, biztos bele lehetne tenni valahogy.
Azért ez már asszem 1 kicsit politika is (apeh, korm.portál, ...)

Több, mint 100 nyomtatvány van forgalomban. Ha foldobnánk egy százas listát, akkor meg az lenne a baj, hogy mit érdekel engem az xy nyomtatvány. Automatikus frissítést terveztünk bele, de ehhez szerver oldal is kéne. Az meg sztem nincs. Ráadásul internet nélkül is menni kell a programnak. Nem könnyű megtalálni a helyes középutat.

Én arra gondoltam, hogy van egy olyan ablak, ahol ki lehet választani, hogy milyen nyomtatványokat szeretnék használni egy kis kereséssel megtámogatva. A kiválasztottakat meg letölti -> offline is megy.

Aztán alapból a kiválasztottak közül lehet választani.

Esetleg figyeli, hogy történt-e változás a letöltött nyomtatványokban és ha igen, akkor letölti a frissítést is.

Egy grid-ben megkapod az összes elérhető nyomtatványt, kipipálod mi kell, és tölti.
Illetve, ha van az abev-nek frissebb verziója, akkor kapsz alul egy checkboxot is, amit, ha bejelölsz kapod az ujjabb abevet. Hibája, hogy amíg letöltés tart, nem kapsz semmiféle viszajelzést, először azt hittem nem csinál semmit a progi.

Az automatikus frissitessel is baj van.
Adott verzioval eloallitott bevallas eseten, egy esetleges audit alkalmaval
a program- es adatkornyezetnek egymassal szinkronban kell lenni es maradni, hosszu tavon mondjuk 7 evig.

Ezzel nem rokon gondolat, hogy _automatikusan_ modosit az egyik fel a programon.

Hát az tuti nem a JNLP volt, az ugyanis ha emlékeim nem csalnak, akkor az pusztán a csomagba forrasztott verziószámot veszi alapul. Mindegy.

A jelenlegi telepítőt nagyon sürgősen ki kell dobni az ablakon, nálam tanultabb kollegák picit lentebb leírták miért.

Btw, ha tényleg az egyszerűség a cél, minek telepítő? Ja, igen, tudom hogy elkerüljük a "hol a setup.exe?" kérdést. Más indok?

Szia!

Örülök, hogy itt vagy, és jószándékod jeléül szóba is állsz a HUP-osokkal.

No, akkor egy kis adalék segítségül a fejlesztéshez:

Nem az a legnagyobb baja itt senkinek sem, hogy nem olyan egyszerű az install Linux alatt. (Bár, lehetne, akadnak már desktop Linux userek bőven.) Hanem az a baj, hogy

1, csak root jogokkal lehet a telepítést elvégezni. (Ez nem baj önmagában, ha látjuk a forrsást is.) Szerencsésebb lenne a programot a felhasználói térbe zárni.
2, A telepítési cfg deklarálja a telepítési útvonalat. Ez azt eredményezi, hogy kvázi egyfelhasználóssá válik a program, vagy azt - és ez a legrosszabb -, hogy minden felhasználó egy mappában találja az állományait. Ergo egymás bevallásait is láthatják. A jogosultsági rendszer betartása unix alapú rendszereknél olyan "terminológia", mint a windows-felhasználóknál a "Start gomb": szent és sérthetetlen.
3, Importálási lehetőség hiánya. (Már szóltál róla, hogy lesz.)
4, A 0753-A lap 10. sor, b oszlop. vörösbetűs szövege rálóg az entry formra.
5, És ez má$ik rendszeren is idegtépő: nem működik a vágólap, és egy be nem fejezett adatbeviteli mező tartalmától búcsút vehetünk, ha másik alkalmazásra váltunk, majd vissza.

Ami tetszik:

1, Szkrollozható.
2, Ügyes a nagyítási lehetőség.
3, Keresztplattformos - végre.

Más különösebb észrevételem nincs.

1. A telepítést úgy terveztük, hogy igen, rootként (v. win rendszergazda) felmegy, aztán userként újra futtatva beállítja amit kell. Valami balul sült el, de kijavítjuk, sztem nemsoká fent lesz a javítás.
A továbbiakban tehát tegyük fel hogy ez megoldódott, jó :)
2. Felhasználónként meg lehet adni az adatkönyvtárak helyét, nem látják egymásét.
3. import lesz
4. megnézzük, jelezzük a tervezőknek
5. igazad van -> listába

"2. Felhasználónként meg lehet adni az adatkönyvtárak helyét, nem látják egymásét."

Ezt nem értem. Szerintem nem gondoltad át a választ.

2.1 Ezt úgy kell érteni, hogy ahány user, annyi root telepítés kell? Az /etc/abevjavapath.cfg egyértelműen deklarálja a telepítés helyét.
2.2 A futtatási környezet helyét a futó java program szintén olvassa a /etc/abevjavapath.cfg. Ebből egyenesen az következik, hogy "Csrrrr... Halló, te vagy az, Gyökér? - Igen, mondjad. - Te, én is szeretnék már bevallani. A /etc/abevjavapath.cfg mutasson már az én könyvtáramra, ok?"...
Ugye te is érzed, nem ez a járható út!

OS X Leopard alatt finoman szólva is bugos a program, több képernyő hosszú exception-öket lehet belőle kicsalni akár akkor is, ha a 0753-as űrlapon az első mezőre rákattintok, ami a kezem ügyébe akad. Néha el is felejti, amit a mezőkbe írok. Érdeklődés szintjén: tervezi valaki ezeknek a hibáknak a kijavítását, vagy izzítsam a Parallels-t? ;) Ilyen exception-ökre gondolok (csak a stack trace első néhány sorát másolom be, meg azokat, amik a hu.piller.enykp.gui.*-ra hivatkoznak):

Exception in thread "Thread-4" java.lang.RuntimeException: Invalid border type !
at hu.piller.enykp.gui.component.ENYKCheckBox.setBorder(ENYKCheckBox.java:105)
at apple.laf.CUIAquaButtonLabeled.setThemeBorder(CUIAquaButtonLabeled.java:60)
at apple.laf.CUIAquaButton$CUIAquaHierButtonListener.hierarchyChanged(CUIAquaButton.java:483)
at java.awt.Component.processHierarchyEvent(Component.java:5769)
[...]
at hu.piller.enykp.gui.viewer.PageViewer.change_component(PageViewer.java:235)
at hu.piller.enykp.gui.viewer.PageViewer.access$000(PageViewer.java:34)
at hu.piller.enykp.gui.viewer.PageViewer$3.getDefaultComponent(PageViewer.java:170)
at javax.swing.SortingFocusTraversalPolicy.enumerateAndSortCycle(SortingFocusTraversalPolicy.java:131)
at javax.swing.SortingFocusTraversalPolicy.getComponentAfter(SortingFocusTraversalPolicy.java:244)
[...]
at hu.piller.enykp.gui.framework.MainFrame$EnykGlassPane.setVisible(MainFrame.java:182)
at hu.piller.enykp.gui.framework.MainFrame.setGlassLabel(MainFrame.java:69)
at hu.piller.enykp.gui.framework.Menubar$6.run(Menubar.java:415)
at java.lang.Thread.run(Thread.java:613)

Ez pl egy mentett nyomtatvány betöltésekor jött elő.

Üdv!

Sajnos az én programjaim sem úgy szoktak sikerülni, ahogy azt eredetileg megálmodtam,
így nem vetek rád/rátok követ, (sem az elsőt, sem másikat).
Már annak nagyon örülök, hogy megmozdult valami a "más rendszerek" támogatása terén.
A hibák pedig majd csak fogynak...
Sok sikert!

Szia!

Először szeretnék én is néhány javaslatot megosztani Veletek (néhány dolgot már írtak):

1. Telepítő ne használjon semmilyen platformfüggő futtatási megoldást (bash szkriptet generálni java programból nagyon csúnya)

2. Ennek kicsit ellentmondva: viszont használja ki a FreeDesktop illetve MacOSX specifikus megoldásokat, hogy legyenek szép, kattintható ikonok.

3. Mint azt már többen leírták, a JNLP megoldás lett volna, arról nem is beszélve, hogy a program frissítésének problémája is "magától" megoldódik. Valamint korrekt digitális aláírást is kaphatott volna a program, hiszen mégis a mi pénzünk múlik azon, hogy nem a hackerpistike által "feljavított" változatot használjuk.

4. Ehhez kapcsolódó konfiguráció-menedzsment tanács: érdemes minden, a build rendszeretekből kieső eredményt egyértelműen jelölni a manifestben (pl. buildid). Így követhető, hogy miből lett leépítve. (Egy hasznos eszköz pl. a Hudson http://hudson.dev.java.net, ami ezt tudja automatizálni)

5. Korrekten beletettétek a felhasznált nyílt forrású komponensek licenszeit, viszont számomra nem derült ki (lehet, hogy nem kerestem elég kitartóan), hogy pontosan mely komponensek ezek.

6. Amennyiben nyílt forrású komponenseket használtok, akkor ezeknek a forráskódját elérhetővé kell tennetek. Az nem elég, hogy megadjátok azt a linket, ahonnan letöltöttétek, hanem nektek kell hozzáférhetővé tennetek, beleértve az összes módosítást, amit végeztetek a forráskódokon.

7. Jelenleg egy GPL licenszt is mellékeltetek, ami azt jelentheti, hogy GPL komponenst is használtok, tehát a _teljes_ programot nyílt forrásúvá kellene tennetek. Egyetlen kivétel, ha az adott komponens GPL + "ClassPath kivétel" licenszelésű. Itt feltételeztem, hogy nem a telepítőprogram GPL licenszű, mert ez a licensz már a telepített alkalmazásban található. Sajnos a teljes nyitást, legnagyobb sajnálatunkra, nem tehetnétek meg egyébként, mivel az RBarCode könyvtár licensze ezt nem teszi lehetővé.

8. A nyomtatványok egyenként, kézzel történő letöltögetése már a windowsos ABEVnél is kényelmetlen volt, de egy új fejlesztésű programnál elfogadhatatlan. Jól működő javas plugin kezelő megoldásból rengeteg van, csak válogatni kellett volna. További zavaró elem, hogy nem kompatibilis a windowsos ABEV formátumával. Tényleg érdemes volt egy új formátumot csinálni? Így ráadásul korlátozottan használható csak a program, mivel egyelőre csak az SZJA bevallás formja készült el / lett átkonvertálva. Nagyon remélem, hogy automatikus a konverzió, mert egyébként külön öröm lesz azt lesni, hogy vajon elkészülnek-e a javas űrlapváltozatok. További kellemes mellékhatás lenne, ha az egyes űrlapokban sajnos viszonylag gyakran előforduló hibák, még abban is különbözni fognak, hogy javas vagy windowsos klienshez készültek.

A program integritásának (digitális aláírás, MD5 vagy még inkább SHA hash megadása a letöltésnél) biztosítása mellett a licensz problémák feloldása lenne a legfontosabb, mielőtt valaki bepróbálkozik egy próbaperrel...

És végül egy kérdés: Tervezitek kiadni az űrlapformátum specifikációját (pl. XML séma, függvények leírása)?
Ha igen, mikor? Ha nem, akkor miért nem?

Üdv,
Kis Gergely

Köszi a tanácsokat.
Ebben a licenc dologban 1általán nem vagyunk otthon, most keresünk majd valakit - gondolom - az apehnál aki segít tisztázni ezeket.
hash kitételt megoldjuk, azt 1xűbb.
1ébként a bárkód, eu-s adószám ellenőrző és a titkosításhoz szükséges bouncycastle csomag van benne, ha jól emlékszem.
A telepítőről már írtam, alapjaiban 1 ideig még biztosan így marad, aztán majd meglátjuk...
Nyomtatvány frisítés.
Sztem hiányzik hozzá a megfelelő szerveroldali megoldás. Idővel biztosan megoldódik.
Az űrlapformátum úgy tudom kint van az apehnál, konkrétan asszem a járulékbevallásról (0608A, 0608M), de a többi is pont ilyen. Ehhez ragaszkodtunk mi is. (ha megnézed a belső formátum is hasonló, de az igazából lényegtelen)
függvények - lásd kitöltési útmutató :)
sztem a belső formátum függvényeivel nem sokra mész, de mivel a sablonok is xml ben vannak mostantól, abban megtalálod őket. (tem.enyk)

"Ebben a licenc dologban 1általán nem vagyunk otthon, most keresünk majd valakit - gondolom - az apehnál aki segít tisztázni ezeket."

Na, itt álljunk meg egy szóra!!!!!!

Ugye nem azt akarod mondani, hogy használatra kiadtok egy olyan programot, amivel büntetőjogi következményekkel fognak használni az polgárok, és fogalmatok sincs a benne lévő programok Licenceléseinek jogi következményivel?????
Én a helyetekben azonnali hatállyal levenném a programot az APEH honalpjáról, az emberektől elnézést kérnék, és marha gyorsan utánanéznék, hogy követtetek-e el jogsértést a Licencekkel! Nem biztos, de lehet, hogy éppen jogsértést (bűncselekményt) követtek el!
Bocsáss meg, de ez SZÉGYEN!

Ja, és elnézést a felindultságomon, de ha jól sejtem, akkor pl. az én adóforintjaim is ott landolnak nálatok. Mint adózó magyar állapolgár elvárom ezért, hogy tisztában legyetek a háttérrel!

Mindenki csinál néha ökörségeket.

Az angolszász kultúrában is az a divat, hogy először figyelmeztetnek.

Ha licenszbe ütközik a dolog, akkor vagy kiadod a forrást, vagy eltávolitod az OpenSource részeket. Ha ennek nem teszel eleget, akkor jöhet a per. Nálunk Magyarországon is rá kellene szokni az ilyen toleranciára. Nem kell mindig perrel kezdeni mindent, ha figyelmeztetni is elég.

Ebben a programban 1etlen licences csomag van, a bouncycastle. Ezt a titkosító használja, ami már kb. 2 kint van az interneten. Soha senki még nem tett szóvá ezzel kapcsolatban semmit. Most néztem meg a licencüket - eléggé megengedő. Szóval ebből a szempontból nyugodt lehetsz. Senki nem pazarolta licencekre az adóforintjaidat, azt a hibát 1 másik matrixban keresd!

Csak csendben merek beleszólni. Abban egyetértek, hogy ha licenszes bonyodalom van, akkor még az APEHnek is igazodnia kell a szabályokhoz.

Ugyanakkor szerintem nem az ide írogató, innen elsősorban profik segítségét váró kolléga dolga adott program jogi tisztába tétele.

Véleményem szerint örülni kéne a fogadóképes másik oldalnak, szerintem ez ritkaság egy állami hivatal (esetleg áűllami hivatal által megbízott cég) részéről.

Az együttműködést biztosan nem fogja elősegíteni, ha egyből perrel fenyegetitek meg emberünket. Gondolom a felmerült jogi problémákat éppúgy jelezni fogja az illetékeseknek, mint ahogy a programhibákat. Persze csak szerintem....

Csaba

Sajnos én már nem vagyok ennyire derülátó.
Olyan, mintha az idő - értsd: pénz - sürgette volna a fejlesztőket, nem a minőség. Amúgy meg, ha annyira érdekelte volna őket a reprezentatív felhasználók véleménye, akkor előbb közzéteszik alfa, béta teszttel, és ők kérik ki a segítségünket. Most is ez történt, de 1.0.0 néven...

Ennek ellenere en a hozzaszolasabol azt vonom le, hogy ha a verzio 0.1 lenne, akkor nem fuzte volna hozza postja vegere a "Most is ez történt, de 1.0.0 néven..." sort. Vagy akkor jott volna, hogy "Ez meg a 0.0.1-re sem melto." stb. blabla ertelmes szoveg.

Felreertes ne essek, nem feltetlen ertek egyet azzal a moddal, ahogy kiadtak az elso releaset, de azon szerintem kar fennakadni, hogy itt kerdezik meg megy-e a nyomtatas. A linuxos platform nem kifejezetten az egysegessegrol hires.

Szerintem, kissé túlliheged a dolgot, de attól még igazad van. Egy egész országot foglalkoztató programot nem szabadott volna így kiadni.

A fejlesztésével kapcsolatosan meg annyi, hogy a nagy cégek is megnyitják a programjaik forráskódját, akkor ezt ebben az esetben is meg lehetett volna tenni. Mindenki hasznára vált volna. szvsz

( 2Geza | 2008. 01. 08., k – 14:04 )

Tanulsagos.

Vajon keves volt a penz, keves volt a szakember, tudas, keves volt az ido, vagy gyenge volt a szervezes?

Szakmailag a jelenelegi megoldast keves szempontbol lehet vedeni.

Kar, hogy nem ismerjuk a pontos sztorit.

( connor v | 2008. 01. 08., k – 15:05 )

Tök jól szétrobbantható a progi könyvtárszerkezete. Akár még debet is lehet belőle készíteni (fogok is). Eddig tetszik. (a forráskód is :))

( babo v | 2008. 01. 08., k – 15:57 )

Nagy öröm ez.
Mint SzSzI felvesszük a kapcsolatot az APEH-el és segítséget ajánlunk nekik. Tudjuk, hogy a Pillér Kft fejleszti, megpróbáljuk megkeresni őket is.

( szimszon | 2008. 01. 08., k – 17:14 )

Akár így akár úgy, de köszi a programot.

( gipszjakab | 2008. 01. 08., k – 19:53 )

Hát basszus nekem nem m1:

Java Accessibility Bridge for GNOME loaded.

Registering Application.
org.GNOME.Accessibility._ApplicationStub:
IOR:00bdbdbd0000002249444c3a4163636573736962696c6974792f4
170706c69636174696f6e3a312e3000bdbd0000000100000000000000
6e000102bd0000000a3132372e302e302e3100b714000000164c4d424
900000015a3b99d2a00100000000400000000bdbd00000003000000010
000001800bdbdbd0001000100000001000100200001010000000000494
24d0a0000000800bd00011500000100000026000000020002
Could not obtain object reference for IDL:Accessibility/Registry:1.0
Unable to contact registry
Java Application:0
Just registered Application
IOsHandler.OS_NAME = linux
IOsHandler.OS_NAME = linux
message = user.home=/home/AZENNEVEM
(9000) XML olvasó létrehozási hiba: :
Exception in thread "P=101243:O=0:CT" java.lang.NullPointerException
at jarinstaller.XMLParser.parse(XMLParser.java:66)
at jarinstaller.XMLParser.parse(XMLParser.java:74)
at jarinstaller.gui.MainFrame.loadParams(MainFrame.java:185)
at jarinstaller.gui.MainFrame.(MainFrame.java:112)
at jarinstaller.JarInstaller.exec(JarInstaller.java:55)
at jarinstaller.JarInstaller.main(JarInstaller.java:41)

Na most akkor mi a vihar van?

( storeplace | 2008. 01. 09., sze – 13:49 )

Kérek 1 kis segítséget.
Légyszi' próbáljátok már ki a nyomtatást. Elég sok bug reportot olvastunk java-s fórumokon a linuxos nyomtatásról.
Nálatok mi a helyzet?

Szerintem gyorsban valami egyszerü oldalat hozzatok létre, ahol ottvan mit kell tesztelni és feirhatjuk milyen hibákat tapasztaltunk. Mi mindent szivesen kipróbálunk, kuldunk szöveget+képet.

Pl. Nálam eléggé hülyén látszanak a dolgok, kicsuszik minden mindenhonnan. 600x-os nagyitásban látszanak csak a vonalak, keretek rendesen.
Nomtatás nem megy egyáltalán, bejön egy ablak hogy "Nyomtatás hiba !".
3 nyomtató van a gépemen, 1 hálózati (nincs itt), 1 az sztalomon lévő (LPT), 1 CupsPDF.
A hálózati az alapértelmezett.
Ha csak az alapértelmezetten nyomtat akkor nem éppen jó, mivel cégeknél is átlagosan 3 nyomtató van egy gépen és azon nyomtatnak amelyik szabad, közelebb van, van benne festék.

Szivesen küldök képeket is, csak valami normális helyre kelljen feltölteni. pl ftp

Nálam exception-t dob.

A rendszer:
Ubuntu 7.10, 2.6.22-14-generic #1 SMP i686 GNU/Linux
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)

Csináltam egy 0753-as 0-s nyomtatványt, a nyomtatási kép rendben van. "Kijelöltek nyomtatása" gomb után a következő kivételt dobja:

http://pastebin.ca/849330

( storeplace | 2008. 01. 09., sze – 22:41 )

Köszi a sok építő kritikát!
Hát ezt jól elszúrtuk. Nem jó a licenc politikánk.
Tudjátok mennyit kerestük azt a fontot, ami a legközelebb áll az Arialhoz. Olvastam pár régebbi fórumbejegyzést (nem itt) , ahol a sok okos tipográfus jött ilyenekkel, hogy a Helvetica az pont olyan mint az Arial. Ja, tényleg.
Szóval tényleg nem a licenceléssel kelünk-fekszünk, de nem volt szándékos.
Milyen tesztelés?
A sun fórumán valami 2d graphics vezető fejlesztő olyasmit írt a linux - java nyomtatási problémáról, hogy ők mindent a szabványok szerint csináltak, ghostscript 8.1 (?) probléma, "nothing to do". Most megkérdeztem, hogy Nálatok mi a helyzet. Szerintetek, ha véletlenül nem megy 1-2 helyen, akkor majd mi fogunk tudni "something to do"?
Ha elhasal valamin a program, akkor persze, de biztos lesz olyan hiba amivel bizony 1ütt kell majd élnetek. pl. a fent írt "Nyomtatás hiba !" pont ilyen javítható.

Teszteles: Mar ne is haragudj, de egy ilyen kaliberu programot ugy altalaban teszteles nelkul kiadni... nos... ehhez tenyleg pofa kell. A felhasznalok teljes kizarasa a fejlesztesbol ugyancsak hibas politika. Nem kell bazar modszerrel fejleszteni, az MS sem teszi, de megis kiad alfa, beta, RC verziokat a programjaibol, es eleg sok kommunikacios feluletet ad a bugreportingra. Ehhez nem kell penz. Egy bugzilla akar egy extra.hu tarhelyre is feltolhato, a demok is feltolhatok egy ingyenes tarhelyre.
Ez felhasznalocentrikussag kerdese, amilyennek egy fejlesztonek alapban lennie kellene.

Licencing: Mint oly sokszor hallani, a nem tudas sajnos nem mentesit. Foleg egy jogilag ennyire kenyes programnal oda KELL figyelni a licencekre, nem szabad a dolgot ellazsalni. Most vagy komolyan veszek egy projectet, vagy visszaadom, de ez a hozzaalas szerintem igen kevesse megengedheto. Tudtatok hogy mit fejlesztetek. Innentol erre nincs epkezlab kifogas.

A széles néptömegben most annyi marad meg, hogy "már megint valami linuxos izével van gond". Ez itt a nagyobb probléma.

"APEH a Linux-támogatottság megjelenését emelte ki, "

Szerintem nincs ott kiemelve semmi. Le van írva, hogy mi támogatott. 7-ből egy a Linux, 6 meg valami Windows.

No mindegy, most van ennél nagyobb problémám is.

--
trey @ gépház

Szerintem kár volt azt a cikket megjelentetni. Végre a távoli odafönt meghalják az opensource emberek hangját (?), végre történik valami, erre ilyen cikkek jelennek, meg, a HUPra regisztráló fejlesztőt perrel fenyegetjük meg... Hát ez nem az a konstruktív hozáállás szerintem. Ezek után nyugodtan mondhatják, hogy ők megtették az első lépést a közösség irányába, mire innen csak hőbörgés és köpködés a válasz.
Félreértés ne essék, én is világosan látom, hogy vannak hibák, akár súlyosak is, de szerintem az is látszik, hogy próbálnak valahogy kommunikálni. Ha bajunk van a programmal, el lehet mondani higgadtan is (Persze volt olyan is.). Úgy látszik, van rá fogadókészség.
Szerintem ez nagyjából a nyuszika meg a róka létrája esete. Gyanítom, ha még sok ilyen cikk jelenik meg, akkor megint bedobják a törölközőt, aztán megjelenik egy szép hosszú cikk az indexen/népszabiban, hogy az openszórsz közösség milyen elutasítóan állt a kérdéshez, ezért nem lesz linuxos ABEV.
Csaba

Ok, rendben, hogy kommunikálnak a közösséggel, de az első végleges verzió kiadása után teszik. Ha már itt egy ekkora brutális méretű potenciális tesztközönség, akkor elvárható, hogy felkérnek minket tesztelésre. Nem érzed visszásnak a helyzetet, hogy mi tárjuk fel a hibákat, mint fentebb írtam: utólag. Elbizonytalanító a helyzet, hiszen a számos hiba megjelenése ismeretében mi arra a garancia, hogy a program outpuja korrekt adatokat tartalmaz? Nem szeretném magam kitenni egy APEH büntetésnek csak azért, mert egy hibás programot használtam. (Ez persze lehet paranoia is, bár a tények ismeretében van rá ráció.)

"Mennyivel lenne jobb a helyzet, ha 0.1-nek hívnák?"
Ki beszélt most verziószámról?

> "mi arra a garancia, hogy a program outpuja korrekt adatokat tartalmaz?"
"Miért eddig mi volt?"

Semmi. :) Csakhogy - én legalábbis tudok róla -, nem voltak ilyen bagatel malőrök a wines verzióknál, vagyis a bizalom a helyes kimenetre, megalapozott lehetett.

"aztán megjelenik egy szép hosszú cikk az indexen/népszabiban, hogy az openszórsz közösség milyen elutasítóan állt a kérdéshez, ezért nem lesz linuxos ABEV."

Ez nem lehet kérdés. Nem kötelezhet az állam sem téged, sem másokat, pláne a Linux disztribútorokat, hogy Microsoft terméket vásároljunk, vagy a disztribútorok esetén a konkurenciájuk termékét vásárolják meg. Már több alkalommal is szó volt róla, hogy alkotmányellenes a mostani állapot fenntartása. Ebbe ne menjünk ismét bele.
Ja, és itt nem történt elutasítás, hanem tényfeltárások sora. "Mi" "power userek" megoldjuk a problémát, és használjuk. De nem ez a megoldás. Ugyanolyan jogok illetnek meg minket, mint a Microsoft Windows-felhasználókat. Nem tehet különbséget az állam.

Alapvetően egyetértek veled, de lásd be, ez a szituáció alkotmányellenes már jó régen, osztán mégis eddig az volt a tanács, hogy menjél epontba abevet kitölteni. Nézd, én aztán igazán nagyot szívok, mert ide 2000 km a legközelebbi emagyarország pont (vagy mi a szösz). Szóval a bevallásomat úgy tudom abevvel megcsinálni, hogy beizzítom valahogy linux alatt. (Windowsom nincs.) Szóval abszolút érintett célközönségnek érzem magamat. Ezért nem tartom jó ötletnek leüvölteni az ide tévedt abev fejlesztő haját, még akkor sem, ha mindazon hibák és jogtalanságok igazak, amit írtatok. Csak hát ha mi rugalmatlanok vagyunk, akkor az apeh simán megcsinálja, hogy akkor megint csak winonly abev lesz, én meg szívhatok. (Az állami hivatalok vidáman sz.nak a rájuk vonatkozó szabályokra, erről már vannak keserű tapasztalataim.)
És még azt is vedd figyelembe, hogy az ide írogató abev fejlesztő nem maga az APEH. Az ő arcába zúdítani a sérelmeket (durva hangnemben) az kb olyan, mint amikor üvöltesz a vasúti pénztárossal, hogy hogy képzeli a MÁV, hogy emeli a bérletárat, de ritkítja a járatokat, a vonatok meg koszosak és késnek. Alighanem ő nem tehet róla, legfeljebb jegyzőkönyvbe veheti a panaszodat és továbbíthatja az illetékesnek. Hát csak ennyi. Van itt egy tétova nyitás. Próbáljunk minnél többet profitálni belőle, és legalább ne mi csapjuk be az ajtót. Ennyi.
Csaba

Ha szétüvölteném a fejlesztők fejét, akkor nem próbálnék segíteni nekik. Amúgy meg a Pillér Kft. az APEH tulajdona. Tök fölösleges keresni a párhuzamot pályafelvigyázó segédtiszt - magyarul: bakter - felelősségét a járatritásokban és az Abev fejlesztői és munkái között. A baktert meg igen is le lehet anyázni, ha akkor zárja le a sorompót, mikor a szerelvény elhaladt, ráadásul a bakter csak minimálbért keres. Ennyi pénzért neki meg joga van hülyének lenni.

( xtonix | 2008. 01. 10., cs – 14:44 )

storeplace!

Tényleg nem láttátok még mindig be hogy szükséges, vagy esetleg nem tudtatok eddig létrehozni egy BUG riportoló oldalt?

Ez így követhetetlen, átláthatatlan kuszaság... az már látszik, hogy van még mit csinálnotok a progival (függetlenül, hogy az APECH felé sikerült-e az átadás) A jelen állapot nem a javítást, fejlesztést segíti elő...
Ez kicsit azt sugalja, mintha annyira azért nem lenne érdeketek... (Ebben az esetbe - a licenszeknek elegettéve! - kiadhatnátok a forrást, és szerintem van elég önkéntes hozzá, hogy közösségileg menjen tovább a fejlesztés; egy fejlesztő már biztos lenne)

( storeplace | 2008. 01. 10., cs – 15:51 )

Teszteléshez.
Most mondja a főnökünk, hogy az IVSZ decemberben megkapta tesztelésre a programot. Semmilyen visszajelzés nem érkezett. Kinek kellett volna még elküldeni. Ja, a hup.hu -ra :)

Bug reporthoz:
Ahogy Te is írtad van még mit csinálnunk bőven, de ebben nincs benne egy ilyen portál indítása, készítése.
Tényleg sajnálom, de 1xűen nem fér bele az időnkbe.

Már megbocsáss, de hogy fejlesztetek bugtracker rendszer nélkül? Nagyon kicsi cég lehettek...
ja, és nem kell "csinálni". Rengeteg kész megoldás van a világon, egy olyat kéne kihasználni!
Nem mi oldjuk meg a problémáitokat, de több szem többet lát! És szerintem nagyon sokat számít, ha nagy tesztelő csapata van egy projectnek... főleg, ha még esetleg hozzáértők is vannak benne, mint itt.

Nem egy projectet adtam már át én is... és csak akkor nem kérdezek rá, hogy "No, megnéztétek? Nyomkodjátok már!", ha nincs kedvem foglalkozni vele... - hibátlan programot meg még nem láttam - Ők nem szóltak, nekem nem kell semmit javítani... A határidő után meg fizetnek: ha volt fix, ha nem.
Egyszerű, ugye? :) Már bocs...

Már bocs, de olvasatom szerint a megbízó megapta tesztelésre a progit. Az,hogy nem tesztelte az ő baja - itt kicsit faramuci a helyzet, mert ugye így a mi bajunk is.
Gondolom a szerződésükben nem volt olyan kitétel, hogy teszteltetik a nagyközönséggel.
Megrendelő megkapja a cuccot, megnézi, visszajelzés nincs, lovit megkapom, joggal gondolhatom, hogy megfelelt az igényeinek.

Lehetőleg a problémára keressünk megoldást, ne pedig a probléma megoldhatatlanságát keressük, meg hogy, mit miért.
Pl. nekem érdekem egy kicsit, hogy használható legyen, pedig én nem kasználom, de ismerőseim igen. És ha nem kell állandóan telefonban beszélni velük, akkor már megérte.

Storeplace, kérlek, csináljatok valami normális oldalt, nem igaz hogy sw-t fejleasztettek és nincs egy szaros gép amire fel lehetne tenni egy bugreportos cuccot. Egem pl. egyáltalán nem érdekelne ha valami "gyári" cuccal oldanátok meg, esetleg csak angol lenne, nem lenne kicserélve a logó cégesre benne, stb...
Nem hinném hogy nincs 1-2 óra, vagy ha tényleg nincs akkor keresettek itt rá valakit aki már csinált ilyet, adjatok neki egy kis helyet és biztos megoldja.

> Meglep, hogy erről eddig senki sem írt a hup-on.

Nincs mit írni az e-Bevallás munkacsoportról, mert az ottani történések csak a csoportmunka tagok számára hozzáférhetők.

> Komolyan: tudott erről valaki? Mármint, hogy önkénteseket várnak a teszteléshez?

Szerintem nem várnak önkénteseket.

Így van.
Modern mese képe:

"( IVSZ | 2008. január 11., péntek - 27:62 )

Bocs, hogy idáig csak pislogtunk, mint a South Park Elementary diákjai. Igen, mi teszteltük a programot. Ám semmiféle beszámolási kötelezettségünk nincs a Linux közösség irányába, úgyhogy mondhatnánk azt is, hogy :rofl:. Ám, nem így teszünk.
Kijelentjük, hogy a tesztelési csapatmunkában résztvevő szakértők alapos tesztelések és megfontolás után adták ki azon szakvéleményüket, melyben a program teljesen hibamentes működéséről számoltak be. A Pillér Kft. elfogadta független állásfoglalásunkat. Amennyiben a program mégsem az elvárt szinten működik, úgy arról mi nem tehetünk. Amikor mi néztük még jó volt."

> hogy Te is írtad van még mit csinálnunk bőven, de ebben nincs benne egy ilyen portál indítása, készítése.
> Tényleg sajnálom, de 1xűen nem fér bele az időnkbe.

Ti tényleg ennyire tájékozatlanok vagytok? Vagy a windowson kívül tényleg nem láttatok még soha semmilyen operációs rendszert?
Ki a mennydörgős mennykő mondta, hogy tessék lefejleszteni egy bugtracker rendszert? Senki. Arról volt szó hogy TELEPÍTSETEK ilyent.
Tessék körülnézni, google, van legalább 5-6 féle ingyenes, KÉSZ, TELEPÍTHETŐ bugtracker rendszer (Csak a nagyobbak közül: bugzilla, horde whups, trac). Ezekkel kb. annyi a feladat, hogy egy LAMP szervert fel kell tolni, adatbázist csinálni a mysql-be, felpakolni a webappot és kirakni a netre. Kesz koszonjuk, johetnek a bugok.

Amúgy bárki viszonylag kevés pénzért felhúz nektek egy nap alatt egy ilyen szervert. Nem a ti időtöket rabolja.

Úgy gondolom, mindenre van értelmes megoldás, egyszerűen a kérdés ott eldől, hogy meg akarom oldani a fennálló helyzetet, vagy hagyom hadd pörögjön a téma, mert a negatív reklám is reklám.

Némileg kiegészítettem a csomagot. Kapott egy ikont a menü IRODA (gyk.: Office) kategóriájába (legalább is Gnome alatt sikerült oda tennem, légyszi jelezzetek, hogy KDE és más kezelők alatt is rendben van-e).
Így már azok is könnyűszerrel telepíthetik és indíthatják, akik nem ismerik a terminálból való indítás rejtelmeit.

http://www.dacr.hu/ubuntu

( sly007 v | 2008. 02. 04., h – 19:57 )

Nos az édesanyámmal éppen az előbb teszteltük a programot.
Letöltés, telepítés: Ubuntuban nincs alapból olyan, hogy java program futtatása root felhasználóként. Még szerencse hogy volt egy ügyes kis scriptem a menüben, úgyhogy nem kellet a terminál. Szépen kattintgattam a tovább gombra, sőt még meg is kérdezte, hogy az asztalra és a menübe is akarok e ikont. Még jó! Nos az ikonok sehol. Irány a mappák mélye. Végre sikerült elindítani.

Kitöltés: Teljesen jól használható. Ki is töltöttük. Ellenőriztük és javítottuk a hibákat. Vagyis javítottuk volna, de nem engedte. Más nem maradt, Kézzel szerkesztetem kicsit. Ellenőrzés rendben. Akkor irány a nyomtatás. Hoppá még is van hiba. no itt derült ki, hogy nem igazán élőben számolja a kiszámolandó értékeket. Sőt a lementett fájlban is benne vannak az utólag kiszámolandó értékek. Minek is? Számomra nem logikus. Nem értem minek kell elmenteni, a dinamikusan kiszámolódó értékeket. A jelölőnégyzetekkel kapcsolatosan külön történetünk van. Szóval a felállás: X-el kellet jelölni. Akkor adjunk neki x-et. Semmi. Akkor X-et. Semmi. Enter, alt, tab, 2, S, 4, K, 7, L, w, 5, r, 8. Semmi. Space? Győzelem! Végül is magától értetődik. Vagy nem? Persze másodszorra nem sikerült az akció.
Szóval végre hibátlan volt az egész. Kattintottam egyet a Nyomtatás gombra és ez fogadott: "Nyomtatási hiba!" Nah itt betelt a pohár. Egyébként mi is a baja a nyomtatóval? Mert még egy ******* hibakódot sem közölt velem. Mit csináljak? Fejtsem vissza a programot vagy mi? Lehet hogy jobban járnék. Éppen kicsit benne vagyok Java programozásban (5-ös lett a Java prog. vizsgám az idén :-). Áhhhhh...

sly @ w3m.hu

Szia!
Ha kicsit benne vagy a java programozásban kipróbálnál valamit? Próbálj már 1 konstans Stringet kinyomtatni, úgy, hogy feldobod a nyomtató-választó panelt, vagy ha ez nem jön össze, akkor a default printerre.
Kíváncsi vagyok összejön-e valami. Ha igen kérlek írd már le a java verziót, meg az op.r-edet.
Előre is köszi.

Ha jól sejtem az én rendszeremben lesz a hiba:
PrinterJob printJob = java.awt.print.PrinterJob.getPrinterJob();
printDialog = printJob.printDialog();

printDialog()-ra hibát dob: http://ubuntuforums.org/showthread.php?t=599538

De a sima print()-re nyomtat. Szóval szerintem azt lehetne csinálni, hogy mivel ez a probléma adott, a felhasználóknak lehetne adni egy olyan lehetőséget, hogy egyből nyomtathassanak. Pl.: "A nyomtató beállító ablak megjelenítése problémába ütközött. Megpróbálja ennek ellenére nyomtatni?"

Nálatok itt jött elő a hiba, ha jól sejtem:
...
at sun.print.PSPrinterJob.printDialog(PSPrinterJob.java:421)
at hu.piller.enykp.print.MainPrinter.doPrint(MainPrinter.java:712)
....

Oprendszer:
Ubuntu 7.10 (gusty)
Kerel:2.6.22-14-generic

Java verzió:
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)

sly @ w3m.hu

Szia !
Kösz a segítséget. Sajnos várható volt, de nem akartam lelőni a poént :).
Mondjuk az +, hogy a sima print kinyomta. Nyomtatóra küldted v. valami virtuális eszközre?
Talán már ma lesz kint új változat, de ebben még nem lesz benne. Most az import volt a legfontosabb.
Valami ilyesmire gondoltam én is +oldásként. Sajnos nem számítottam arra, hogy 1 ilyen standard dolog, mint a printer dialog ekkora kihívás...
A PostScript környékén van valahol a hiba. Win alatt pl. nem is PSPrinterJob ami Nálad az exception-ben ven
Vérmesebb bug reporterek 1ébként olyanokat is írtak a sun-on, h. pl. 5-ös java-ból felejtsük is el a nyomtatást linux alatt :(

Minden jót!
(ja, remélem a hibaüzeneted nem licenc köteles :) )

"Vérmesebb bug reporterek 1ébként olyanokat is írtak a sun-on, h. pl. 5-ös java-ból felejtsük is el a nyomtatást linux alatt"

Akkor nem lehetne valami pdf exportot csinálni belőle? És mindenki kinyomtatja a kedvenc pdf nézegetőjével.

Nyomtatványok lesznek ehhez is? :)
(Miért nem valami xml fájl a nyomtatvány?, Miért szükséges ez a telepitős nyomtatvány?)

A pdf export nem rossz ötlet, csak nem olyan triviális, meglátjuk...
A nyomtatványokat az apeh-ben készítik. Tudtommal dolgoznak rajta, de előbb a delphis-hez valókat gyűrik.

xml fájl az, xml. Csak be van csomagolva a jar-ba. + pár más dolog is (pl help). Általában elég a tem.enyk fájlt a sablonok mappába tenni és megy, de néha kell mellé más is. Szóval ezért kell telepíteni.

Ja, igen a többi megjegyzésed:
Ezt nem értem: "Vagyis javítottuk volna, de nem engedte". Valami nem jól működött? Írd már le kérlek pontosan mi volt.
De igen, élőben számol, csak lehet olyan mező, aminek a függősége olyan, hogy pont nem volt benne abban a láncban, ami 1 kitöltött mezőből indul.
Mentés. Persze, tudom, redundáns adatot nem mentünk... Mégis így döntöttünk. Töprengtünk rajta eleget, így látszott a legjobb +oldásnak. Így sokkal gyorsabb, mint minden betöltéskor számolni. (Ne feledd, nem csak a pár oldalas SZJA bevallás van, hanem pl.8000 munkavállaló adatait tartalmazó járulékbevallás is.)
Jelölje X-szel. Ez hagyomány szerint így van a nyomtatványokon. A megvalósítása pedig checkbox. Azt sehol sem lehet x-szel kitölteni. A kinézete pedig azért olyan amilyen, hogy szép legyen :)
De igazad van, azt beletehettük volna, h. az x-re váltson. Az ugye csak vicc volt, hogy K,7,L ...
Elvileg "space"-re es egérrel kattintva (2x) kéne, hogy működjön.

A járulékbevallás nyomtatvány mikorra várható? A kolléganőnek nagyon tetszett a "kitöltési útmutató mezőnkénti help" megoldása. Ez lesz a járulékbevalláshoz is? Nagyon örülnének neki!

A 0808A/0808M ellenőrzésével kapcsolatban kinél lehet hatásosan bugreportolni?

Örülök, hogy tetszett, köszi.

Azt hittem már az is kint van... Nemtom mikorra várható. Nálunk már van teszt változat, de ez Téged gondolom nem dob fel.
A mezőérzékeny Helpet tudtommal csak az SZJA-hoz csinálták még meg (ezt az apeh-ben írják), de a tervekben biztosan szerepel. Persze lehet, hogy úgy gondolják, a könyvelők biztos tudják mit hogyan miért. De ezt tényleg nem tudom.

A java-s verzióval kapcsolatban nálam :)
A régivel kapcsolatban nemtom - talána az apehnél, de ha jól értem azt nem tartod "hatásosnak".
Tényleg nem lenne rossz, 1 hivatalos bug report oldal... Na, majd 1xcsak.

Több helyen, előjött az, hogy módosítani kellet az adatokat. Pl. elírtam a dátumot. Hiába nyomtam bármit, az érték masszívan ott maradt. Újra megnyitás után sem változott a helyzet. Ezért kénytelen voltam az XML-t megszerkeszteni. De úgy néz ki, hogy ez az 1.6-os java problémája. Fent van az 1.5-ös Java is. Alatta jól ment minden, a nyomtatásion kívül. :-S

Checkbox-hoz szerintem állítsátok be, hogy lehessen x-el és is jelölni. Szerintem a jelölésre általában 1x-es kattintást szoktak használni a legtöbb rendszerben.

sly @ w3m.hu

Hali!

Nem vágom, hogy hova kell bökni a HUP fórumon, ezért próbáltam egy nyomtatós megjegyzést folytatni.

Egy szó mint száz, nemkem sem megy a nyomtatás az 1.0.3-al. Sem az 1.5 sem az 1.6 java nem segít. Viszont mindkét jvm-el ugyanazt az eredményt produkálja. Print preview és nyomtatás esetén is ugyanazt. Pl. az első oldal rendesen megjelenik, kivéve, hogy az X-ek helyén számsor (de milyen számrendszerben?) látszik. Pl. 010001B00 meg B002A B003A az első kalickában. A második kalickában C001A és C002A. És így tovább, kalickánként az első betű eggyel nő, a kalickán belüli számoknak jobbról a második számjegye nő. Nekem az a gyanúm, hogy nem a nyomtatás rossz, hanem valaki bent felejtett egy tesztkódot, amikor leellenőrizte, hogy a nyomtatásban a megfelelő nyomtatópozícióra a megfelelő indexű adat íródik-e ki. Szerintem kb. így néz ki a kód a kiadott verzióban:

printToPos(getX(cellaID), getY(cellaID), cellaID.toString());

ehelyett:

printToPos(getX(cellaID), getY(cellaID), getStringFromMemDBByID(cellaID));

Namostan, ha nem jól gondolom, akkor át lehet konvertálni a kitöltött nyomtatványom? (Mert mégegyszer nem akarom végigkínlódni.) Vagy próbáljak meg elektromosan bevallani?

Szia !
Ez nem bug, feature :). Van a programnak 1 olyan szolgáltatása, hogy "közös azonosítók nyomtatása". Ezek a kódok a mezők azonosítói (ha belenézel a mentett enyk fájlba magad is láthatod) A beállítások menüpontban van 1 közös azonosítók nyomtatása checkbox. Azt kapcsold ki, és sztem ok lesz.

Köszi, ez volt a probléma.
Ez tényleg nem bug, de nem is egy egy feature. Igazából ez egy tervezési hiba. Mi köze van a felhasználónak ahhoz, hogy a megvalósításban hogyan azonosítanak egy mezőt? Egyáltalán ahhoz, hogy van olyan fogalom, hogy mező? Soha nem találtam volna meg ezt a kapcsolót, csak ha a forrást nézegetem (vagy így, hogy elárultad a titkot).

Azért ami nem úgy van ahogy szerinted kéne, az nem mind hiba.
Pontosan így van, van olyan akinek szüksége van erre az információra. Ellenőrzésnek mindenképpen jó, hogy melyik mező "hol van".
(régebben asszem a "fejlesztőknek" menüpontban volt).

Egyébként nem titok, Te is megtaláltad, be is jelölted, mert alapból nem nyomtatja a mezőkódokat.

Más.
Nem is tudtam, hogy volt 1 másik fórum is. Látom ott van pár bejegyzés a járulék bevallásról.
Az még nincs kint, de annyit elárulok, hogy jelentősen változni fog a kezelése.

( Botond | 2008. 02. 05., k – 12:14 )

Akad itt Java-s, szabadidővel rendelkező ember?
A fönti nyomtatási hiba a Java JRE és a cupsys-1.3.x inkompatibilitásából adódik. cupsys-1.2.x-szel megy a nyomtatás az abevjava programmal.
A printDialog( ) rutin nyilván parszol valamit, amit a cupsys visszaad, és aminek a formátuma megváltozott cupsys-1.2 óta. Ha valaki nagyon ráér, megkereshetné a printDialog() rutinban a hibás részt, és adhatna rá egy javítást.

( storeplace | 2008. 02. 05., k – 14:43 )

A következő verzióban benne lesz (többek között), hogy ha a nyomtató dialógusablak nem bír feljönni, egy kérdés után megpróbáljuk az alapértelmezett nyomtatóra kiküldeni a nyomtatványt. Remélem menni fog mindenkinél.

( gyrgyvrs | 2008. 02. 07., cs – 18:42 )

A Javas verzióval akartam bevallani a 0753-as nyomtatványt, elektronikusan. Hibát jelzett a titkosításnál. Abszolút path megadásával működött, lehet, hogy helyes relatív path megadásával is menne.

Szia!
A path ok kb így állnak össze: KRDIR + a konfig fájlokban lévő relatív pathok.
Ha a config-ban abszolút megadással megy, akkor valszeg nem sikerült beállítani ezt a KRDIR-t. (üres + abszolút)
Ez így önmagában nem is baj, de tudtommal a Mo.hu feladó appletje is ezt a KRDIR-t használja. (Nekünk is ezért kellett így)
Szóval nézd meg, hogy van-e ilyened, mert különben a beküldéssel is gondod lesz.

( zamboriz v | 2008. 02. 07., cs – 23:05 )

2008.02.06. Verzió 1.0.3

  • Csoportos műveletek kezelése
  • Windows 98 esetén felmerülő környezeti problémák kezelése
  • A 0753-as nyomtatvány 3.5-ös verziójában megszüntetésre került egy mező, ezt a program nem megfelelően kezelte.

2008.02.06. Verzió 1.0.3

  • Csoportos műveletek kezelése
  • Windows 98 esetén felmerülő környezeti problémák kezelése
  • A 0753-as nyomtatvány 3.5-ös verziójában megszüntetésre került egy mező, ezt a program nem megfelelően kezelte.

2008.01.24. Verzió 1.0.2

  • Törzsadatok átemelése az Abev-ből
  • A nyomtatványok nem kitölthető lap füleinek az eltüntetése (elszürkítése)
  • Kontroll kezelése
  • Csatolmányok kezelése
  • A mezőkód kijelzés alapértelmezésben be volt kapcsolva, ez zavarólag hatott. A felhasználói beállítások futtatásakor (telepítő) ez kikapcsolt állapotba kerül.
  • Mezőben állva az F1 gombot lenyomva megjelenik az adott sorhoz tartozó kitöltési útmutató. Ha nincs egyetlen mező sem kiválasztva, akkor az aktuális laphoz tartozó kitöltési útmutató jelenik meg. Az F1 minden esetben a Kitöltési útmutatóra, az F2 a Program Súgóra vonatkozik.
  • A Súgóban (program és Kitöltési útmutató) felvételre került egy cimke ami jelzi, hogy hová kell beírni a keresendő kifejezést. A mezőbe beíródik a "" jelezve ugyanezt. Ha elkezdi kitölteni a mezőt akkor ez a felirat automatikusan törlődik.

2008.01.08. Verzió 1.0.1

  • Felmerült néhány hiba, hiányosság ezeket javítottuk.

2008.01.07. Verzió 1.0.0

( csortu v | 2008. 05. 05., h – 17:20 )

Úgy tűnik ebben a topicban kell bugreportolni.

Abevjaba 1.0.5 verzió
Java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

Nem megy a nyomtatás. Ha kiküldöm simán nyomtatóra, akkor job cancelled lesz, ha fájlba nyomtatok, akkor a postscriptben annyi üres oldal lesz, amennyi oldalnak amúgy lennie kellene. (Nem tudom mennyire számít, de fedora 7 rendszer, 2.6.23.15-80.fc7 kernel, CUPS nyomtató rendszer, sambával megosztott HP Photosmart 7260 nyomtató.)

Jpg fájlok segítségével végül sikerült papírra rakni a bevallást, remélem előbb utóbb a hagyományos metódus is menni fog.

Ja, parancssorból futtatva sok infó mellett egy fia error se volt, szóval nem tudtam tovább nyomozni, hogy mi lehet a baj.

Üdv,

Csaba

Szia!

Ennek a "megoldására" asszem még várni kell. Pont azért, mert ahogy írod semmi exception nincs. Azt írják java-s fórumokon is, hogy valami ghostscript x.y probléma okozza - ha jól figyeltem. Pont ezért tettük fel a jpg készítést, hogy ha végképp nem megy a nyomtatás legalább így lehessen. Ahogy látod, volt más linuxos nyomtatás hiba is, de azt sikerült megoldani.

Sziasztok! Én most nyomtatnám ki az enyémet, de ugyanez a hiba, a postscript, amit generált a linuxos abevjava, hibás. Ubuntu 7.04-en ESP Ghostscript 815.04 (2007-03-14) változattal nem jelenik meg, viszont a régi SuSE 9.0-mon ESP Ghostscript 7.07 (2003-07-12)-vel minden OK. (A JPG-s nyomtatás lehetőségét nem találtam meg az abevjavában.) Ezt aztán PDF-be konvertáltam a régi GS-sel, amit már az ubuntus evince és az acroread is el tudott olvasni (és nyomtatni is tudtam).

Szerintem egyértelműen ghostscript hiba, de lehetne valami workaroundot kitalálni (a PS fájl kis módosításával talán).

( saabi v | 2009. 02. 09., h – 08:09 )

Hol lehet bugreportolni az abevjavaval kapcsolatban? Tavaly még ment Mac OS alatt, idén ilyet kaptam:

java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:401)
at jarinstaller.MainLogic.setRootApplicationDir(MainLogic.java:166)
at jarinstaller.MainLogic.appInit(MainLogic.java:142)
at jarinstaller.MainLogic.(MainLogic.java:69)
at jarinstaller.JarInstaller.exec(JarInstaller.java:57)
at jarinstaller.JarInstaller.main(JarInstaller.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.javaws.Launcher.executeApplication(Launcher.java:1184)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1122)
at com.sun.javaws.Launcher.continueLaunch(Launcher.java:965)
at com.sun.javaws.Launcher.handleApplicationDesc(Launcher.java:518)
at com.sun.javaws.Launcher.handleLaunchFile(Launcher.java:218)
at com.sun.javaws.Launcher.run(Launcher.java:165)
at java.lang.Thread.run(Thread.java:613)

A környezet: Mac OS 10.5.6

moria:Applications saabi$ uname -a
Darwin moria.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386
moria:Applications saabi$ java -version
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-284)
Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing)

Ave, Saabi.

( takitibi | 2011. 02. 25., p – 10:28 )

Sziasztok!
A következő a kérdésem.
Van egy hálózati mappa, benne a hálózatos abevjava program+doksik.
Van 2 kliens, egyik egy P4-es XP-s(32bit) gép, a másik egy CoreDuo 3Ghz-es W7(32bit).
Fel van telepítve a kliensekre az abevjava, meg van a hálózati könyvtár adva, hogy oda szemeteljen, meg onnét nyissa meg a dokumentumokat. 2 fő ikon van, az "ÚJ" és a "Megnyitás".
XP-n ezek megnyitása 3-4 mp-be kerül, teljesen normális még, hálózatról nyalja be a file-listát.

W7 alatt viszont az "új" olyan 1 perc, míg a "megnyitás" olyan 3-4 percbe kerül.
Proci terheltség: java.exe :: 20-30% közötti ebben az időben.
Mindkét kliensen:
- a \windows\abevjavapath.cfg ugyanoda mutat, jó helyre,
- Users\...\.abevjava\.enyk is okés,
- KRDIR körny. változó is jó helyre mutat.

Átrágtam hatszor a szerveren levő\abev2009p\segitseg\abevjava_halozati_telepites.htm file-t is, minden ok.

Az abevjava indításakor a cmd ablakban a "ReadHandedObjectStreamTime" 80 és 300 közötti értéket mutat minden sorban, ami jó, viszont a "FileListTime" bizony 9194-33847 -ig. Ha az "ÚJ" ikonra kattintok.
A megnyitás ikon még lassabb.

És végül működik mindkettőn, csak XP-n gyorsan(régebbi vas) W7-en meg tetű lassú.
Nem értem. Vki találkozott már ilyennel?

---
Üdv: TakiTibi