Lehet, hogy működik az elképzelésem. Most néztem meg, egy adóazonosító jelet kérő lap 2.1 MB lett pdf-ben. Fizikai nyomtatóra nyomtatva ezt a pdf file-t, úgy emlékszem, nem volt lassú.
Van egy ötletem, persze nem tudom, segít-e. Az lehet a gond, hogy nagyon nagy file-t generál. Ezt onnan tudom, hogy cups-pdf-fel nyomtatva 10 MB fölötti lett a pdf file. Szerintem nyomtasd pdf file-ba, ugye a memória- illetve fileművelet gyors. Utána ezt a file-t nyomtasd ki mondjuk evince alól a fizikai nyomtatóra. Ha az USB porton, hálózaton nem kell megabyte-okat átnyomnia, nyilván gyors lesz a nyomtatás. Azt nem tudom, hogy egy nagy pdf file konvertálása hol történik, még a gépen - ekkor gyors lesz -, vagy már a nyomtatóban - ekkor nem fog segíteni az ötletem. Mindenesetre egy próbát megér.
Kartaaacsak! Nekem az uj abevajava eddig rohattlassan nyomtatott. Ubuntu + Lexmark Optra K1220. Úgy értem, hogy 3-6 perc volt egy azaz egy oldal!!! Nem a nyomtatóm rossz + még gyári driver is telepítésre került! Próbáltam VirtualBoxban win alól is, de ott egyáltalán nem nyomított. Nemtom mért, nem bírtam rájönni. Most beszéltem az apek ugyfelszolgával. Aszonta - meg kell mondani, hogy rendkívül udvariasan, -hogy tuggyák, javítva lesz a köv. verzióban. A bajom csak az, hogy ezt már ígérték az előző verziónál is........... Oszt a hab a tortán, hogy a wines abev2006 nekem szuperul dolgozott wine alatt. üdv. izgaga
egy erdekes megfigyeles: linux alol futtatva a linuxos javaval az abevjavat az kimondottan lassabb, mint ugyanazon vason ugyanazon linux alatt vindozos virtualis gepben (virtualbox) futtatni a vindozos javaval az abevjavat. ehh:-(((
Nálam telepítéskor rákérdez, hogy hol legyen az adatkönyvtár: "Felhasználói beállítások, adat könyvtár megadása Adja meg, hogy hová kerüljenek az elkészített bevallások" Következő lépésben pedig: "Adja meg, hogy hová kerüljenek az elektronikus feladásra szánt állományok"
Próbáltad már úgy, hogy minden felhasználónak ugyanazokat a könyvtárakat választod ki?
Hekkelés az AbevJava SZJA bevallásban (0853 v5.0):
[GIRO] Alszámla szám CDV-re hibás (Hibakód=<24639/s008>) (Lap: 0853-C, Sorszám: 2, Belső azonosító=számlaszám, Import azonosító=18535, Közös azonosító=0D0001H002A)
Hiba oka: az idióta túlfizetett programozó csak 8+8 jegyű bankszámlaszámot kezel, 8+8+8-as kombinációra elhasal.
Megoldás1: nyiss OTP-s számlát, ott 8+8 jegyű a számlaszám Megoldás2: Panasz az APEHnál, várakozás a 6. verzióra Megoldás3(elegáns): Törlendő a következő ellenőrzés a nyomtatvány fájljából:
Ennek a programnak az inputját egyes ügyviteli rendszerek már képesek generálni. A problémádat általánosítva: kérdés, hogy mit kell egyáltalán off-line csinálni és mit on-line.
Az alapprobléma terminálszerveres környeztben életszerű feltételek szerint: Minden usernek defaultban a %HOMEPATH% alá betesz egy könyvtárat. Ez nem életszerű. Egy cégnél csak egy (pár - kevés) ember jogosult rendszerint beküldeni, a többi csak előállít. Ezek a könyvtárak nem kommunikálnak egymással.
Meg fogom próbálni meghackelni a cuccot valamilyen tesztuserekkel. Korántsem vagyok biztos benne, hogy a nagy fejlesztés közepette nem tesznek nekem keresztbe. A gyalog megoldás egy batch lesz, ami ki fogja lopni Buddha szemét. A beíró userektől egyszerűen ellopja az adatokat és átmozgatja a feladó könyvtárába. Nem túl elegáns, viszont nem is függ a fejlesztőktől (hacsak a könyvtárstruktúrán nem változtatnak).
Egy nyomtatvány teljes adatmennyisége és logikája egyáltalán nem jelent nagy terhelést, ráadásul az ellenőrzések nagyrész JavaScripttel a kliens oldalon is működnének. De fontosabb, hogy egy nyomtatványnak csak a töredékét töltjük ki, sokkal barátságosabb és átláthatóbb (és papírtakarékosabb) lenne egy magyarázatokkal bőven ellátott varázslószerű folyam amiből a fölöslegek kimaradnak.
Viszont az online változatnál a hibajavítások azonnal megjelennének. Nem kellene hyperdinamikus oldalakkal megcsinálni. Legyen egy sima form egy oldal, és annyi.
Szerintem sok user inkább ezt választaná a telepítés helyett.
Anélkül, hogy végiggondoltam volna, az nem megoldás, hogy egy közös helyre kimásolod az egyik profilt, s a konfigurációs állományokat, környezeti változókat úgy szerkeszted át, hogy az elérési utak ide mutassanak?
Most ki fog derülni, hogy nem értek a terminálszerverhez - tényleg nem. Ha jól értem, az a gond, hogy lokálisan nem szeretnél semmit tárolni. Azt nem lehet, hogy a szerveren van sok profil, s erre jelentkeznek be távolról a népek? Teszem azt, akár VNC kliensen keresztül.
Inkább az eredeti ötlet életszerűségét kellene felülvizsgálni, hogy mire kell egyáltalán az offline, nyomtatványra teljesen hasonlító, asztali program manapság. Tipikus webes feladat inkább.
A fejlesztők mintha nem számítottak volna rá, hogy terminálszerververes környezetben is használná némely ügyfél. A program defaultban multiuseresként települ. A Documents and Settingusernév könyvtárba berak minden usernek egy könyvtárat. Némely programok meg szokták kérdezni hogy csak az adott usernek telepítsenek-e (ilyenkor egyetlen központi helyre pakol mindent), vagy minden usernek legyen saját környezete (például böngésző).
A neten található dokumentációból látható, nem foglalkoztak a terminálszerveres kuncsaftokkal. A 189 és az APEH Call Centere a valódi hálózatos telepítést erőltetné. Terminálszerveres környezetben azonban a user gépeken szinte semmi sincs, és nem is érdemes tartani (védelem, karbantartás, TCO).
