APEH újra és újra! És a megoldás?

Iroda

Üdv a népeknek,

Nem tudom, hogy Ti várjátok-e már nagyon az ABEV Linuxos/egyébOS verzióját, de már nagyon nem ártana ha megjelenne. A Wine sajnos még mindig nem viszi.

Tudom, hogy volt már itt téma és sok száz hozzászólás született és egy levél is ment az illetékes helyekre.

Azt az igéretet kaptuk ugyebár, hogy nehéz a kliensnek a barcode kezelését megíratni és portoltatni kell sok pénzért.

Nem tudom, hogy mit és hogyan kellett csinálniuk, de az alábbi dolgokat találtam:

Ezzel a programmal készítettem az alábbi kis képecskét:
https://sourceforge.net/projects/pdf417encode/

Letöltöttem kibontottam és ott a forrás és az előrefordított bináris is. Az examples könyvtárban meg a kezeléshez szükséges kis példa programok.

Érdekes lehet még számunkra ez is:
http://www.kbarcode.net/

Ezekszerint mégis létezik megoldás csak a képünkbe hazudnak? Nem feltételezem, csak hangosan gondolkodom.
Várom a véleményeteket.

ui: nem kellene/lehetne megsürgetni valahogy szervezett formában a dolgokat?

  • 10507 megtekintés

( n0b0dy | 2006. 03. 12., v – 12:24 )

nem azt irta valami apehes ficko, hogy mar portolva van az a vonalkodos valami?

( Botond | 2006. 03. 12., v – 12:47 )

Nem biztos, hogy hazudnak. Lehet, hogy csak nincs Linux-os emberük, ezért nem tudják, hogy nem kell újra feltalálni a kereket. Windows alá valószínűleg sokba került a 2D bárkód kezelés, és azt hiszik, hogy Linux alá is drága lesz.

Ez a babo honnan szerezte az infot? Link? Maganlevelezes? Forum?
Az 53 mar tobb mint a semmi, meg ha csak "tervez biztosítani", de a
"már biztos, hogy támogatott.
- Debian
- UHU
- RedHat "
meg jobb hir.
Tehat a http://www.apeh.hu/cgi-bin/lap.php?id=prog/pr2006 oldalon levok nem lesznek mind megvalositva, csak az SZJA?

Hoppa.
Ugy latom, hogy kovetelozo,destruktiv es serto hangvetelunek tunt a hozzaszolasom.
Ebben az esetben elnezest kerek. Egyaltalan nem olyannak szantam.
Az indito "Ez a babo" tenyleg angolosan udvariatlan lehet. Sajnalom.
Az angolost ugy ertem ahogy a magyar fulnek udvariatlannak tunik a "This is my wife" jellegu mondat.

De szintiszta kivancsisag volt mindegyik kerdo mondatom.
A kijelento mondatom, pedig az oromomet fejezte ki.
A tulzott szuksavusagom, meg az, hogy nem ismerjuk egymast (esetleg az emotikonok hianya?)
okozhatta a kis felreertest.

A "Maganlevelezes?" kerdesem pont arra utalt (eleg ugyetlenul), hogy esetleg nulladik kezbol szerezted az informaciot? Mivel erre mar valaszoltal, ezen tullephetunk. Ennyi eleg.
Csak _kivancsi_ voltam. De jo azt olvasni, amiket irtal!

A masodik dolog amire kivancsi vagyok, hogy csak a *53-as megvalositas a cel?
Ebben sem akartam szemrehanyast,kovetelozest tenni.
Csak informaciogyujto volt a hozzaszolasom.
Mivel ugy latom, hogy mindenki masrol beszelt, gondoltam, hogy
csak en nem vagyok eleg tajekozott es kerdeztem.

Szoval csak egy kerdes maradt szamomra tisztazatlan:
Mi lesz megvalositva Linuxon? Csak az abev2006 es a 0553 (abev2007 - 0653 stb. ), vagy pedig a tobbi nyomtatvany is?
(Ugyanis minalunk jelenleg az abev2005-ben 5, az abev2006-ban 17 nyomtatvany van telepitve.)

Ha szabad tudnom, te most csak a 0553-at teszteled?
Mi a rovid es hosszu tavu celod/celotok? Mire van realis kilatas?
Ugyancsak ha szabad tudnom.

Koszonom

Ja es meg valami, a babo nick-rol eloszor nem tudtam, hogy kit takar,
de a Balsai Péter nev termeszetesen ismert.

Úgy tudom, hogy az idén még csak az 53 lesz.
én nem vagyok fejlesztő, egyszerűen csak felkértek a tesztelésre, mivel tavaly sok emberrel beszéltem (APEH és más helyek), én azonnal úgy értettem a felkérést, hogy az LME és az SzKK aki felkért, hiszen több szem többet lát.

Nem vagyok én sem túl udvarias, és nem sértődtem meg az "angolosságon".
Haladjunk az a cél. Ezért is igyekszem itt válaszolgatni arra amire tudok.

kb. 2 hét lesz nekünk a tesztelésre, aztán megy ki mindenkinek.
Azt mondják az a tapasztalat, hogy amikor az emberek élesben kezdik el használni, rengeteg olyan dolog jön ki, ami a tesztek alatt nem.
Abban azért van logika, hogy a házon belüli tesztek után, egy szűkebb közösség teszteli, majd aztán mindenki.

Persze jobb lenne, ha szabad szoftvert fejlesztenének, de most jelenleg ez van. Ez is egy kis lépés előre.
Ha szabad szoftvert fognak fejleszteni, talán követni fogják annak a fejlesztési modelljét is.

Egy szóval se mondtam, hogy legyen szabad szoft a cucc, bár nem látom annak akadályát sem, mivel itt nem üzleti titkokról van szó, hanem egyszerű összeadás/kivonás műveleteket kell megvalósítani és nyomtatható formában közzétenni.

A tesztelés jogát pedig fenntartom ;-)

--
Az élet harc. Délelőtt az éhséggel, délután az álmossággal.

( gabcsi | 2006. 03. 13., h – 07:12 )

En nem akarok bantani senkit, csak minden koztisztviselos programozonak szuksege van egy nyugodt, meleg helyre az allami szveraban.
Elszomorito, hogy meg mindig klipperes es DOS-os prg.-okat fejlesztenek a kozszveraban allami penzekbol (lasd munkaugyi kozpont).
Tehat vezetovaltas v. az IT-ben begyepesedett embereket el kene zavarni vmi oktatas felere, ahol nem a jopofizas divna, hanem a kemenyen megizzasztanak oket. Megmutatnak nekik, hogy a szamitogep nem azert van. hogy a Windows-t legyen hol futtatni!
A TB-s es NYENYI-s programok is csak szegyent hoznak rank infosokra, de legalabb azok mennek DOS-EMU-val.

Az én véleményem az, hogy Magyarországon sok vezeztő beosztású állami alkalmazott nem igazán ért a számítástechnikához (tisztelet a kivételnek). Ha már van otthon gépe, akkor profnak tekinti magát. Ennek ellenére az ilyen 'NYENYI'-t fejlesztő cégek jól megvezetik őket (és ezzel minket is, mert mint 'érintettek' nincs beleszólásunk), nem kis haszonnal. Ebben az országban sajnos az a nagyobb ász, aki többet tud lenyúlni az államtól.

A DOS-os programoknak én sem vagyok rajongója, bár ezt el tudom fogadni, hogy jobb, ha a Windows DOS 6 terminál ablakában fut valami, stabilan, mintha a Windows alatt bizonytalanul.
Optimális lenne a kereszt-platformos megoldás, mely minél több féle operációs rendszer alatt megy, talán ide is eljutnak a dolgok.
Az is lehet, hogy elmegy a dolog a webes technológia felé, bár országunk internet ellátottsága alapján ez egyenlőre nem nagyon praktikus dolog talán.
Azt, hogy ki mihez ért én nem merem megítélni, mert én keveset tudok hozzá.
Ha te többet mersz és tudsz, és ezeket bizonyítani is tudod, akkor rajta, szurkolni fog a közösség neked.

Az én problémám legfőképpen az, hogy az állami közigazgatással kapcsolatos e-ügyintézések szoftverei adottak. "Ez van, ezt kell használni" alapon.
A kérdésem: létezik e olyan, hogy az e-ügyintézések sw specifikációi meg vannak adva, és azok szerint bárki fejleszthet. A fejlesztett sw-t aztán hatóságilag bevizsgálják.
Így lehetőség lenne több megoldásra...

Még jelenleg nincs. Viszont ha a Linux.hu-n a Synergy-s cikkeket olvasod (LME fordította), akkor látható, hogy az EU-ban az a tendencia, hogy nyílt forráskódú, szabadszoftveres projekteket indítanak a közigazgatásban.
Gondolom, hogy ha vége a választási hajcihőnek és kicsit megnyugszanak a kedélyek, itthon is elindulnak a pilotok.

Megjegyzem, pont az SzJA-hoz csak össze kellene a közösségnek kapnia magát, hiszen az teljes mértékben törvényileg szabályzott, és a jogszabályok nyilvánosak, tehát lehet könnyen programot írni erre a területre.
Mindenképpen valami kereszt-platformos dolog lenne jó. (bár nem kedvencem a JAVA, de akár az is lehet)

Jó 5let ez a közösségi dolog, csakhogy:
-az apeh is ezerszer javítja az abev programokat - valami mégiscsak nem tök egyértelmű
-ha a közösségi fejlesztésű dolog elrontana valamit, akkor aztán reszeltek az egész opensource-jóhírnek. gondold csak el a cikket az apeh.hu/index.hu/akarmi.hu oldalon: "Hibás a linuxos ABEV-klón... kérjük kedves olvasóinkat, hogy... blablabla...".
-másik dolog: igenis legyen már az apeh dolga, hogyha törvényben kötelezi az állapolgárt ilyen-olyan programok használatára (Mert ugye lassan ott tartunk, hogy mari néninek is eBEV kell) akkor legalább ne kötelezze vindóz-megvételre is.

Úgy gondolom, hogy ha lenne egy közösség által fejlesztett megfelelően dokumentált program, és azzal keresnénk meg az APEH-et, hogy íme itt van, szálljanak be ők is a tesztelésbe, az működhetne.
Nem hiszem, hogy céljuk lenne a közösséget bántani, no meg egy megfelelő minőségű program esetén ez nem is könnyű.

Egyébként az a modell is működhetne, hogy az APEH elindítja a fejlesztést és nyilvánossá teszi, akár már a tervezés folyamatát is. Ismétlem a kiindulás (jogszabályok) adottak.Tehát valójában nem kockázat a szoftvert nyilvánosságra hozni már korán. S az együttműködő közösség fejleszt tesztel stb.

Szóval igazából csak félelmeink amik visszatartanak, és mondatnak velünk olyanokat, hogy kinek mi a dolga.

A hivatalokat pedig a tapasztalat hiánya. Az EU-s felmérés szerint jellemzően egyetlen egy intézmény sem szívesen első (lásd Synergy-s cikkek a Linux.hu-n).
Ha akarjuk akkor csinálhatjuk, ha nem akkor nem kell.

S elvileg mi az akadály, hogy idén május 22-ig (illetve hamarabb -> lásd: SZJA) elkészüljön egy tervezet (vagy akár kész program)?

Jómagam nem vagyok programozó, de lenne néhány 10-100 stb. ember, aki esetleg beküldené nyílt forrásaal készült programmal a bevallását...

Arra már gondolni sem merek, hogy Vámosi Nagy Szabolcs és csapata rászállna - "csakazértis" alapon - ezekre a "bevalló" emberekre - mert pl. Linuxon keresztül küldte be az adatait... :-)

Ami a hivatalokat illeti, reménykedem, hogy - a kormányváltás lesz-e vagy sem témától - csökken (szűkül) a szerepük Mo.-on! Szinte minden állami cégnél (hivatalnál) volt az elmúlt években "fogyókúra", de még ez is kevés volt! Hangsúlyozom: szerintem! :-)

Bocs, én egy mezei linux júzer vagyok, és nekem nem folyik titkos csatornán az info.

Szóval használtam volna az 53 nyomtatvány kitöltésére az abev2006 ot.

Ez az egyetlen program, amiért a windózomat még nem hajítottam el nagy ívben. Ha lenne linuxos verzió, akkor használtam volna.

Azt mondod, már idén is kitölthettem volna linuxos programmal.

Én annak idején a nyomtatványkitöltő lapján nem láttam linuxos verziót, megnéztem, szerintem most sincs ott.

http://www.apeh.hu/cgi-bin/lap.php?id=prog/pr2006

Ha van ilyen program, akkor miért nem elérhető egy mezei júzernek? Csak a beavatottak juthatnak (juthattak) hozzá?

Vagy most akkor még sincs?

Csaba

Az a probléma, hogy jelen pillanatban hiába van nyilvános specifikáció http://www.apeh.hu/informacio/art_0608_terv.htm
ha a törvény csak az APEH windowsos programjával elkészített elektronikus aláírást/beküldést engedi meg.

Érdekes módon a nyugdíjpénztári bevallásokat lehet más (nem APEH-es) elektronikus aláírással beadni. (Tehát nincs windows-hoz kötöttség!)

( gabi | 2006. 05. 18., cs – 14:29 )

Hali,

hát ássák el magukat a szakemberek.
Most az hogy van, hogy nem lehet elektronikusan beadni a bevallást (május 22 a határidő), mert a magyarország.hu-n a szolgáltatás nem elérhető?
Felvilágosítás szerint műszaki probléma van, amit nem tudják, hogy mikorra küszöbölnek ki a szakemberek. De adnak egy igazolást. És egyébként is ez még csak teszt rendszer :-O
Hogy van az, hogy tavaly már működött a dolog és 1 év alatt nem tudtak összehozni egy működő rendszert? Miért beadási időszakban tesztelgetik? Pont az lenne a lényeg, hogy a beadási időszakban működjön. Ez olyan, mintha a Kékesen több hónapos megfeszített tesztelés után május végén átadják a sífelvonót.
Ez döbbenet.

( zeller | 2006. 05. 18., cs – 14:56 )

Az egy dolog, hogy te valamilyen adathalmazból generálsz egyfajta 2D vonalkódot. A kérdés az, hogy az ABEV-által generált 2D vonalkód mögötti "üzleti logika" (azaz milyen adatokat tartalmaz a vonalkód a lapra kerülőkön kívül (checksum, idő/dátum/lap tipusa, száma/stb.) illetve hogy az adatok sorrendje, "mixelése" hogyan történik) lehet, hogy szerencsétlen módon nem került az APEH birtokába (lásd "termékcsapda"), és ezért kell plusz pénzt költeni rá.

Az APEH-et, mint felhasználót egy érdekli: A program generáljon egy meghatározott adathalmazból egy olyan 2D vonalkódot, ami az ő 2D-vonalkódleolvasó szoftverük kimenetén ugyanazokat az adatokat produkálja.

Az ABEV-et, ha jól sejtem, egy 100%-ban vagy közel 100%-ban APEH tulajdonú cég fejleszti. Azt hiszem, hogy az ABEV fejlesztésének kezdetén nem volt szempont a multiplatform.
Most a Linuxos verziót hirtelen akarták elkészíteni, úgy hogy Kylix alatt lefordítják az eredeti (windows verzió) forrását.
Ez nem egy egyszerű dolog, már csak azért se, mert maga a Kylix sem egy erősen támogatott fejlsztői eszköz Linux alá.
Természetesen probléma, az is, hogy eredetileg nem tervezték a több platformra lefordíthatóságot, és nem ennek fényében határozták el eszközök könyvtárak használatát.
Ezek csapdák, melyek utólag könnyen kikerülhetőek, de előre látásukhoz nem árt "vátesz"-nek születni.

Az a hír járja, hogy az új ABEV JAVA-s és múlti platformos lesz.

Az elektronikus adó és járulék bevallás sok összetevője közül egy az ABEV és egy másik a sok közül a Magyarország.hu és az ügyfélkapu.
Csak gondoljatok bele a különböző internet szolgáltatók proxyjaiba, a feljhasználók tűzfalaiba, vírus és spam elleni szoftvereibe, stb.
Szóval a dolog nem lehet egyszerűen tökéletes, s mondjuk akáár valaki(k) sportból az egész rendszert meg is támadhatták akár.

Szóval hál istennek haladunk, előre, de sajnos lassan.

Inkább hátra:(
1. Az Abev program szakmai hibáktól hemzseg.
(Ha valakit érdekelnek a részletek, szívesen felsorolok néhányat. Nem szívderítőek.)
2. A hibabejelentésekre nagyívben sz**nak.
3. Az ügyfélkapus azonosítás óriási visszalépés az elektronikus aláíráshoz képest.
Érdekes, hogy a magánnyugdíjpénztári bevallás ebből a szempontból korrektül megoldott.(Nyilvános xml formátum mellett elektronikus aláírással beadható, és az nincsen egy céghez kötve.)

>Segítesz, ha az ABEV szakmai hibáit felsorolod, minnél teljesebben annál jobb.

1. A program állandóan megkérdezi, hogy mentse-e a nyomtatványt, pedig semmit sem változtattam.

2. Több nyomtatvány importja csak parancssorból lehetséges, a menüben nincsen benne ez a funkció. http://hup.hu/node/24648

3. Az import során az adatokat nyomtatványonként beolvassa és _megjeleníti_ (!!!), majd menti. Ezért iszonyat lassú.

3. Ha egy cégben több száz ember van, akkor az apeh sem ajánlja ezt a módszert, hanem az egy nagy xml fájl elkészítését javasolja. Csakhogy azt már nem tudja importálni, ergó a nyomtatványokat csak megtekinteni lehet, javítani az Abev-en belül nem. Mármost mit tegyen a könyvelő, ha a kapott xml-ben valami hiba van. Javítsa az xml fájlt? Nem szerencsés...

4. Egyszerre csak egy nyomtatványt tud kezelni, ez meglehetősen kényelmetlen sok ember esetén.

5. A nyomtatványokat _egy_ könyvtárban tárolja, emberenként és havonta egy fájllal szamolva, akár több ezer is összejöhet év végére egy nagyobb cégnél.

6. Ha többször importálod ugyanannak az embernek a nyomtatványát, mert mondjuk javítottak az átadó külső programban, külön fájlba menti, és később nem tudod megkülönböztetni, hogy melyik is volt az igazi.

7. A 0608* nyomtatványok ellenőrzései sok fals hibaüzenetet produkálnak.

8. A 0608* nyomtatványokon ugyanaz az adat néha más sorban, vagy oszlopban szerepel a havi/1.negyedéves/éves garnitúrában.
Tulajdonképpen elég lenne a havi, az 1.negyedévi és éves tök fölösleges.

9. Némely mezők EAZON-ja nem az xml leírásban deklarált szabály szerint képződik

Hitrelen ennyi.

Legújabb "gyöngyszemek":

1. Ha a 0608M 102. sorában (levont adóelőleg) negatív szám szerepel, abból az importálás szó nélkül(!!!) pozitívat csinál. Így az összesítő (0608A) szerint több adót vallunk be, mint amit ténylegesen utaltunk.

2. Ha a 0608M 136. sorában (adóelőleg levonás elmaradás oka) 2-es kódot adok át (őstermelő), az importáláskor az Abev ezt "lenyeli", sőt a 135. sorba (levont 12%-os adóelőleg) beírja az általa számoltat.
Az ügyfelünk javíthatja át a több száz (!) őstermelő adatait kézzel az Abevben :(

Belül is érdekes dolgok vannak:

fc-vel összehasonlítottam a 0608M 4.3-as és 4.5-ös változatának nyomtatvány (grafikai) adatait:

***** 0608M-4_3.lap
TEX=Az Európai Gazdasági Térség tagállamának joga alapján a {:SS1-22}- {:SS1-13}. és#91 - 93. sorokba tartozó bevétel
TEXT=Az Európai Gazdasági Térség tagállamának joga alapján a 61- 70. és#91 - 93. sorokba tartozó bevétel
W=497
***** 0608M-4_5.LAP
TEX=Az Európai Gazdasági Térség tagállamának joga alapján a {:SS1-22}- {:SS1-13}. és#91 - 93. sorokba tartozó bevétel
TEXT=Az Európai Gazdasági Térség tagállamának joga alapján a 61- 70. és
91 - 93. sorokba tartozó bevétel

W=497
*****

Mintha csak most jöttek volna rá, hogy a 'TEXT' bejegyzést üres sorral kell lezárni, ha már (majdnem) mindenhol így van.

Meg a 'TEX'-ben is érdekesen mutat, hogy bizonyos sorszámokat képlettel számolnak ki, míg más sorszámok literálként szerepelnek.

A vonalkódtechnikában szabványok vannak. A 2D vonalkódoknak is szabványai vannak és nem úgy megy, hogy hasraütésszerűen kitalálja egy fejlesztő cég, hogy mely pötty mit fog benne jelenteni. Van egy bemenete, amit bekódol 2D-be a kiválasztott szabvány szerint. És a vonalkódolvasó sem pöttyöket ad vissza, hanem a dekódolt (vagyis az eredeti) üzenetet. A vonalkódolvasónak meg lehet mondani, hogy milyen szabványok szerint próbálja meg értelmezni a képet és ezek közül automatikusan felismeri.
Tehát az apeh fejlesztője bármilyen vonalkódgenerátort használhatna.
Szerintem inkább arról lehet szó, hogy:
1. teljesen zárt forráskódot akarnak
2. az általuk használt hiper-szuper-csili-vili-iszonyat lassú kódot genelálók fejlesztőkörnyezet alá csak windows-os vonalkód komponens létezett.

OK. Visszaolvastatod a 2D vonalkódot, az kidob egy karaktersorozatot, ami tartalmazza az eredeti adatokat, meg azoknak valamilyen kontroll-összegét pl. Ha ennek a kontroll-összegnek a generálási módja nem ismert, meg vagy lőve. Ha valaki tudja, ugyan olvassa már vissza egy ismert adattartalmú 2D vonalkódot, hogy mi jön vissza belőle...

Ismered a mondást: "Biztos a munkahelyed? Te írtad a kódot, ami biztossá teszi?"

Az fog visszajönni, amit megadtál a vonalkód képét előállító programnak. Semmilyen más ellenőrzőösszeggel nem fogsz találkozni. Az már másik kérdés, hogy a képgeneráló progrinak átadott string hogyan épül fel. Még akár digitális aláírásos újlenyomat is lehet...

Tudom, hogy a vonalkód generálása/degenerálása :-)) során a be/kimenet azonos, és csak a vonalkódba kerül checksum, én azonban az input stream-be pluszban beágyazott "okosságokra" gondoltam, arra, hogy az oldalra kerülő adatokból hogyan lesz "input stream" a vonalkód-generátor számára.

> az oldalra kerülő adatokból hogyan lesz "input stream" a
> vonalkód-generátor számára.

Most épp nem tudom kipróbálni, így egy régebbi levelemből idézek:

(http://hup.hu/node/15011, 2005-02-03 21:49)

"Kipróbáltam egy dekódert: http://sourceforge.net/projects/pdf417decode/

Működik a dekódolás, csak annyi a trükkje, hogy a dekóder által visszaadott szöveg eleje valami kódolatlan fejrész, a vége meg ('BZ' karakterekkel kezdődően) bzip2-vel csomagolható ki.

A fejrész (idézőjelek között):

'17IABEV21dy2lra6y 2004K30 1 15 3 1 1 111 253256'

A kicsomagolt rész meg kb ilyen:

LAPOK=1,1,1
0A0001A003A=cégnév
0A0001A004A=irányítószám
0A0001A005A=cím
0A0001A006A=cég adószáma
0A0001A008A=személynév
0A0001A009A=személy adószáma
0A0001A010A=magyar
0A0001A002A=E
0A0001A001A=1
0A0001B0001DA=3664418

Az ABEV nevű nyomtatványkitöltőhöz letölthetők nyomtatványok pld a '2004K30'. Feltelepítés után ezeket az olvasható szöveges fájlokat találtam:

2004K30.alg -- ellenőrzési szabályok/képletek és hibaüzenet szövegek
2004K30.kvf -- a leadandó fájl mezőinek leírása
2004K30.bev -- 114 karakteres fejrész, és 'BZ'-vel kezdődően a továbbiak bzip2-vel kicsomagolhatók"

Még annyit hogy aki linux alatt szeretné a nyomtatvány fájlok tartalmát nézegetni, az rar-al tudja a nyomtatványok exe-jét kitömöríteni.

Csak annyit akartam az előzőekkel kifejezni, hogy ezek azért nem visszafejthetetlen dolgok, csak elég időt kell rá szánni.

Köszönöm, erre voltam kíváncsi. A "kódolatlan fejléc" pont olyasmi, amire azt írtam, hogy lehet benne valami olyan (is), amiről nem derül ki egyértelműen az, hogy micsoda (na jó, lock in, alias termékcsapda...)
Van egy tippem, hogy ha rá is kérdezne valaki, tutira nem kapna róla információt... :-/

( cln | 2006. 05. 18., cs – 18:15 )

Ez a szerencsétlen APEH sok-sok milliót oszthatott szét a saját programozói között. Miért is ne lenne drága. Nekik így éri meg. Ez egy külön kaszt, eltitkolt jövedelmekkel, hiszen ehhez ők értenek a legjobban hogyan kell ezt csinálni. Az a nyamvadt abev.exe meg legalább 10 évvel ezelőtti technológiával készített program.

( Sea-you | 2006. 05. 18., cs – 21:49 )

Amennyiben ossze tudna jonni egy kis csapat, hogy megmutassuk, miszerint igenis a nyiltforrasu kozosseg kepes egy ilyen multiplatform programot elkesziteni, ugy en ezt szivesen tamogatnam mindenfele szolgaltatassal. Siras helyett ;-)

Ehhez nem kell más mint egy sokat tapasztalt programozó (értsd: openszorszban már letett valamit az asztalra) aki képes egy csapatot irányítani, képes megtervezni a programot és egy halom (< 10) programozó aki viszont gyorsan és pontosan dolgozik. :)

Ha lenne ilyen csapat akkor erőforrással (programozás, szerver) beszállnék én is.

(még valami: egy két jogász aki otthon van a jogszabályokban)

Connor, ekkora baromságot is rég hallottam már.. tiszta gyagya vagy, vagy nem látod, hogy ezt csak egy ember tudja tökéletesen megcsinálni.. egy katona.. aki Kálmán.:)
Egyébként érdekes dolgokat feszegettek.. de a fizika törvényei miatt széllel szemben pisálni nem érdemes.
Fri

Mivel az eddigi megjelenések és tesztek erről a MAGYAR problémáról blackPanther OS-re nézve elég diszkriminatívak voltak, feltétlenül támogatnánk egy fejlesztői csapat felállítását bármilyen formában. Szerintem sem tűr már halasztást, és határozott lépésket igényel, mivel úgy gondolom, hogy mesterséges pénzcsapolás folyik a finanszírozók ereiből. Ennyi idő alatt a Windows-t is újra lehet írni nem egy keretprogramot.

Viszont akkor most a magyarokra jellemző rosszindulatot, és széthúzást félre kellene tenni, mindenki aki tudna tenni a témáért valamit az tegye meg!

Kedves babo: mivel nem volt lehetőség rá, hogy pm-et küldjek kérlek keress fel mail-ben, a [kbarcza()blackpanther|hu] címen, köszönöm.

Sem a blackPanther sem más magyar terjesztés mellőzése nem volt az Én részemről szándékos.
A fejlesztők, ahogy én látom kissé későn döbbentek arra rá, hogy
- a linux nem Windows
- a linux disztribek eltérnek egymástól
- a szerzői jogra figyelemmel kell lenni
Én szorgalmazni fogom azt, hogy egy nyílt forrás-kódú fejlesztés induljon a témában el.
Itt természetesen lesznek / vannak ellenérdekeltek, és technikai és jogi akadályok.
Nem csak az ABEV-et jelenleg fejlesztő cég lehet ennek a projektnek ellenérdekeltje, ilyen vagy olyan okból.
Meglátjuk.

Az egyetlen korrek megoldás szerintem az lenne, ha az adóbevallás, és itt most az összes Abev-vel beadható/beadandó(!) nyomtatványra gondolok, ugyanúgy működne, mint a nyugdíjpénztári bevallás. Nyilvánosan közzétett xml specifikáció, és elektronikus aláírás. Ehhez bárki írhatna akár zárt, akár nyílt forrású programot (természetesen az APEH is), és nem lenne preferálva egyik aláírás-szolgáltató sem.
Ekkor nem lenne platformhoz kötött a dolog.

>Az, hogy van egy program amit bárki használhat az adóbevallásának elkészítéséhez szerintem jó dolog.

Ezzel teljesen egyetértek. Magánszemélyek szja bevallásához nagyon hasznos segítség.
Viszont a probléma az, hogy a könyvelőknek/bérszámfejtőkenek _kötelező_ ezt használni a havi adó és járulék bevallásokhoz. (0608*)
A fenti észrevételeim mind ezzel kapcsolatosak voltak.

( uid_3194 | 2006. 05. 24., sze – 11:19 )

...és a mai napig nem megy a java-s szutyok proxy mögül! A régi ment, szóval tényleg visszalépés ez az új magyarország.hu! Ja és volt 3 telefon 2 E-mail. A válasz:
* Használj egyszerüsített feltöltőt!
* Telepítse újra a böngészőt a java-t és az operációs rendszert!

muhahhaa...

Üdv: G.

http://www.pingit.homelinux.org a megoldás.

( cln | 2006. 05. 24., sze – 13:23 )

Talán feltehetem ide kérdésem...
Létezik-e valamiféle megoldás arra hogy 2 darab abeves, 0608* típusú xml filet valahogy összefésüljek? (merge)

ELaci

Írtam egy perl programot, ami az apeh-es '.XML'-ekből (elvileg bármelyikből) '.imp' fájlokat csinál. Így be lehet tölteni mindkét '.XML' fájl adatait az abev-be, onnan pedig (ahogy a menűben láttam) ki lehet exportálni újra '.XML'-be.

Ide tettem: http://web.t-online.hu/zamboriz/xml2imp.pl

A program futtatása előtt le kell menteni a nyomtatványok könyvtárába (c:/program files/abev 2006/bev/) az adott nyomtatványok (pld: 0608A és 0608M) '.CSV' fájljait. (Abev menűjében: Szervíz/Fejlesztőknek/A meződefiníciós file (CSV) létrehozása)

Ha kérdésed van keress meg nyugodtan.
( http://hup.hu/user/2428/contact )