lafisoft

Iroda

Kiteszek egy sqlite motorra épülő számlázó verziót.

Van valaki aki hajlandó tesztelni vagy maradjon az user desktop piac az ms-é.
Ez már lassan 10 éves kérdés és az ms lenyomja az user appllication szintjén a linuxot.

Nem írok web címet mert kihajítja a hup azzal hogy üzleti céllal írtam. Ez külön téma :-)

  • 5660 megtekintés

( uid_17626 | 2015. 05. 22., p – 08:02 )

Jó tanács, de ne olvasd el, ha bánt a kritika:
Nem töltöttem le (sajátot használok) csak a screenshotokat néztem meg. Azt látom, hogy hangulatában nagyon 1995-ös. Sajnos a weboldalad is. Sokaknak (velem együtt) nehéz elhinnie, hogy emögött valami komoly szakmai tudás áll (pedig tudom, hogy lassan 20 éve csinálod). Javaslom UX-re kicsit a rágyúrást. Legnagyobb hiba szerintem a külső-belső margók rossz használata, mert ez teszi iszonyatosan trehánnyá az egészet.

Amit én javaslok, hogy nézd meg, már csak a móka kedvéért is:
http://960.gs/ <- neked ez nem közvetlen kell, hanem a mögötte lévő tudásra lenne nagy szükséged, ezen keresztül megértheted a külső és belső margók lényegét.
http://www.libri.hu/konyv/dr_susan_weinschenk.100-dolog-amit-minden-ter…
http://www.libri.hu/konyv/robin_williams.tervezz-batran-1.html

Van még sok ilyen könyv ami a témával foglalkozik. Utána kellene járni némi színtannak is, aztán az ikonokról is lehetne beszélni. Van még munka vele így, hogy (gondolom) egyedül csinálod.

UX-ileg nem az a baj vele, hogy nem néz ki szépen... az marketingileg a baja. csomó randa de jól használható programot láttam már (linuxon is)

Két baj van vele:
1) annyira csúnya hogy valószínűleg nem eladható
2) ha eléültetünk egy egyszeri kisvállalkozót, valószínűleg nem fog tudni segítség nélkül számlát kiadni vele.

Ha már mindenképp könyvet kell ajánlani, akkor Krug-tól a Ne törd a fejem (don't make me think).

Nem akarok senkit se illegalitásra buzdítani, de egyfelől out of print, másfelől a könyv címe után PDF-et írva van... tartalmas link hozzá.

És ha lehet angolt is, akkor a Design for Hackers a javasolt szakirodalom a Tervezz Bátran és a 100 dolog mellé. http://www.amazon.com/Design-Hackers-Reverse-Engineering-Beauty-ebook/d…

Kognitív pszichológiai könyv, egy 40 000 éve változatlan processzorról szól, semmi oldschool nincs benne, max az illusztrációk.

De pont emiatt jelent meg tavaly az átdolgozott változata, egyelőre csak angolul.

Amúgy néha a technológiával foglalkozók nem értik, miért nem avulnak a UX könyvek a technológiával együtt - azért, mert ez elsősorban biológia...

Ami nagyon erős benne az a kognitív alapelvek, célhoztervezés, usability testing - ezek ma is stabil elemek, max részletesebb lett a kidolgozásuk szakmán belül, mint ami egy ilyen alapozó könyvben le van írva.

Bocsánat, nem akart személyes lenni, inkább rossz tapasztalat: UX-esként gyakran dolgozunk "régi" könyvekkel (Krug - 2006, Nielsen - 1999, Norman - 1986!), és sokszor kellett megvédenem a fejlesztők előtt, hogy hiába régi a könyv, attól amit ír még igaz.

Ez ellen az írók mostanában példacserés új kiadásokkal védekeznek, de ez az utóbbi 2 év divatja, én meg viszem be a fejlesztőknek ezeket a könyveket 10 éve...

A színek: most elővettem a 2006-os angol kiadás PDF-ét és ctrl-f "color" -t nyomtam. Konkrét színt a 33 találat egyikében sem említ meg, max azt hogy minek kell különböznie.

A minek hol kell lennie: itt elképzelhető, hogy a konvenciókra emlékszel (6. fejezet körül). Krug betegesen kerülte hogy konkretizálja a webes konvenciókat, de természetesen példákban az épp akkor aktuális nagyforgalmú weboldalakat használta, így lehet hogy ez az üzenet félrement.

Biztos nem tudta magát Krug teljesen függetleníteni az aktuális kortól, bármennyire is próbálta, de az alapelvek továbbra is az emberi agy erdőkre és vadállatokra tervezett működéséből fakadnak, ezért mondom hogy nem idejétmúlt, max a magyarban a példái - azóta meg ugye ott az új kiadás.

Nem tudom, rég olvastam, de arra emlékszem, hogy amikor olvastam nem volt olyan érzésem, hogy erre nem gondoltam. Az egész mű nem lép ki a józan ész kereteiből, így azon emberek akik az egyszerűsítésre amúgy alapvetően törekednek, továbbá alkalmazásaik felülete épít a feltételezett felhasználó meglévő tudására nem fognak új információt szerezni a könyvből. Kezdőknek viszont kiváló, mert megspórol pár évet az életükből.

Hát ugye pont erről szólt a könyv második fele, hogy ne a feltételezett felhasználó tudására építsünk, hanem ültessünk le valakit egy kis keretsztorival ("A kovács és társa Bt tagjaként számlát kell kiállítanod Kiss Pistának, 1234 Tápiószecső, Kossuth utca 3"), és nézzük meg ahogy szenved vele.

Kezdőknek való könyv, persze, de elnézve a Lafisoft UI-ját, van hova fejlődni :)

Amikor leültetsz valakit, akkor az már a második ciklus. Előtte azért nem árt ismerni a célpiacot. Különben üres kockákat kellene rakni a felhasználó elé, majd statisztikai alapon elnevezni és ellátni funkciókkal. Szerintem a kiindulás nem lehet más, mint a tapasztalat és az elméleti tudás. A UX fejlesztés második szakasza lehet csak a teszt, amikor már van min tesztelni.

Vissza Lafisofthoz: Egyik hibája, hogy távol van az aktuális közízléstől. Nem kell neki trend teremtőnek lenni, de trend követőnek nem ártana.

Termék szempontból:
Érthetetlen, hogy egy számla oszlopainak és tétel sorainak száma miatt, miért kell másik alkalmazást leszedni. Miért nem lehetne ez mind egyben, majd settingsből beállítani. Ha pedig nagyon hightech akar lenni, akkor TEÁOR-ból (vagy valami másból) kitalálja mi a megfelelő megjelenítés.

Marketing szempontból:
"A választék megöli az üzletet." (Nem tudom ki mondta és mikor.)
Neki igazából egy terméke van. Össze kellene vonni, ami pedig csak vadhajtás és egyedi fejlesztés azt csak megemlíteni egy bemutatkozó oldalon.

A kiindulás általában interjús-megfigyeléses kutatás.

Tesztelni prototípusokon is tesztelünk, de sokszor van az, hogy "megUX-elni" kell már meglévő terméket, itt első körben usability tesztekre visszük azt.

Tervezéshez viszont valóban kell elméleti tudás, tervezési minták, platform konvenciók és vizuális nyelv. A tesztek csak a problémákat jelzik ki, a megoldást nem adják meg.

( Hunger | 2015. 05. 22., p – 09:45 )

Van valaki aki hajlandó tesztelni vagy maradjon az user desktop piac az ms-é.

Lafisoft számlázónak köszönhetően fog eljönni a Linux desktop éve! :)

Engem szórakoztat, de nem tudom, mennyire függ ez attól, hogy milyen oprendszert használok. :)

Ha a linux desktop évének eljöveteléhez "a haladás és a felhasználók igényei" miatt Delphi 6-ban készülő windows-os programok kellenek, I'm on board!

Ami nekem nem tetszett, és ezért is mentem bele a flame-elésbe, hogy az OP-ben megy a szakértés arról, hogy linuxos programokat kell csinálni, közben a honlapjuk szerint a linuxos support az, hogy tölts le Wine-t.

( trey | 2015. 05. 22., p – 13:14 )

"Nem írok web címet mert kihajítja a hup azzal"

#prekoncepció #paranoia

--
trey @ gépház

Alapesetben senki más nem moderál rajtam kívül. Kéréssel bárki élhet a tartalmat illetően. Hogy annak helyt adok-e vagy sem, az rajtam múlik. Vannak esetek, amelyeket megkonzultálok mással is, főleg olyankor, amikor bizonytalan vagyok egy-egy dolgot illetően.

BTW: elég gyakran előfordul a HUP tagok moderálják saját magukat...

(Légy szíves ne itt offolj, ha kérdésed van, tedd fel privátban, vagy nyiss egy topikot a megfelelő helyen.)

--
trey @ gépház

Mindenesetre az, hogy a topiknyitó 48 órája nem volt képes egy mukkot sem hozzászólni a saját maga által nyitott fórumtopikhoz, illetve a segítőkész tesztelők hozzászólásaihoz, az nem jelent túl sok jót a szoftver jövőjének szempontjából.

Ha jól értem, azt sérelmezi, hogy nem kap túl nagy figyelmet a szoftvere. De látszólag nem is sokat tesz azért, hogy ez változzon.

BTW: nekem mindegy. Legyen ez egy up a topiknak, nehogy elsüllyedjen ;)

--
trey @ gépház

( Polesz v | 2015. 05. 22., p – 14:57 )

Szia, engem érdekelne.

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

( khiraly | 2015. 05. 22., p – 19:45 )

Engem erdekel. A mostani (szinten linuxos) szamlazoprogramom is SQlite-os.

Ahogy en hasznalom: Megirom (kezzel:) a .XML fajlomat, azzal megetetem (menupontbol), es kesz a szamla.

Amire szuksegem lenne: parancssorbol meghivhato aminek .pdf a kimenete, vagy nyomtat nyomtatora.
Semmi sallang nem erdekel (raktarnyilvantartas, miegyeb), gui teljes mertekben szuksegtelen (nekem).

Csak a jogszabalyi megfeleloseggel es a jogszabalykovetessel nem szeretnek en sajat magam bajlodni.

Ilyen verziod nincs veletlenul?

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

Igaz, GUI-ról nem ír :)
"2016. január 1-jétől minden számlázó programnak rendelkeznie kell egy olyan önálló, de a programba beépített, „adóhatósági ellenőrzési adatszolgáltatás” elnevezésű funkcióval, amelynek elindításával adatexport végezhető"

Ennyi a feladat. Funkció legyen, oszt' jónapot. :)

A következő lépés meg az lesz, hoyg online jelenti is először negyedévesen, majd havonta, majd minden nap, majd realtime.

De igen, en van ugy, hogy vim-mel elvagyok egesz nap, szoval gui nem letszukseglet ahhoz, hogy munkat vegezzen az ember :)

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

ugy szamlazoprogramom, hogy megvettem, egyebkent semmi kozom hozzajuk.
Easyinvoice egyebkent.

Roluk annyit, hogy megprobaltam megkerni a fejlesztot,
hogy Ctrl-Q vagy W re lehessen mar kilepni, de inkabb meggyozott, hogy az Alt-F4 a standard.

Van meg jopar idegesito bugja, de az ugyis offtopic, meg nem er annyit, hogy sajatot irjak.
Bar ha januartol egyebkent is ujat kene vennem...:)

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

Plusz egy szamlazoprogramot kb. lehetetlen osszekotni a raktarprogrammal/webshop programmal/vallalatiranyito programmal -> mindegyik ilyennek altalaban van egy szamlazo modulja.

Igazabol ezek a szamlazoprogramok kb. semmire nem jok (most ne pont a lafisoftra ertsetek)
Raktarprogramnak gagyik, altalaban egyszemelyesek, tavolrol nem lehet hasznalni oket,
egyedi (rosszul hasznalhato) guijuk van, sajat kis "szemetdombjuk" van, adatot cserelni veluk kb. lehetetlen.

Konkretan az esetek 90%-ara alkalmatlanok.
- penztargeppel es raktarprogrammal nem lehet osszekotni oket.
- kulon gep kell nekik
- van egy "Marika" aki ide *IS* beviszi az adatokat (partnertorzs, miegyeb)
- minden eladott szamlanal *ujra* be kell vinni az adatokat, mivel egyebkent nem ebben tartjak nyilvan a raktarkeszletuket, neadjisten webshop is van.

Ezek a szamlazoprogramok kb. egy olyan egyfos kisboltnak felelnek meg, amelyiknek semmilyen mas raktarkeszletnyilvantarto programjuk nincs, es nem kell masokkal egyutt dolgozni.

Egyebkent tegyuk fel, hogy te minden honapban kiadsz egy szamlat szerzodes alapjan.
Melyik az egyszerubb:
a) fogsz egy .xml fajlt atutod a datumot
b) ujra vegigkattintgatod a guin
Ennel egyszerubb peldat nem tudok...

Az olyan sallangokat mar ne is emlitsem, hogy altalaban EUR szamla eseten siman fogjak es MNB arfolyamot szur be a szamlazok legtobbje, amikor a default az az, hogy sajat bankod devizaarfolyamat kell alapul venned. Az mnb arfolyamot kulon be kell jelenteni a NAV-nal...
De ugye irni egy modult, amelyik kb. 20 bankod le tud queryzni az nem olyan trivialis.
Raadasul delutan 2-ig el se erheto az aznapi arfolyam.

Van meg millio dolog, de szerintem kar folytatni.
En az UNIX filozofiat varnam el. Egy dolgot tudjon, de azt jol:) (sorszamozni).

ui:
Es vim-mel szamlat irni nem elvetemult dolog :))

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

Érdekes, amit írsz :) A "másik" oldal szemszögéből hozzáfűzném a gondolataimat:

"Plusz egy szamlazoprogramot kb. lehetetlen osszekotni a raktarprogrammal/webshop programmal/vallalatiranyito programmal -> mindegyik ilyennek altalaban van egy szamlazo modulja."
A legtöbb esetben ezt azért nem triviális megcsinálni, mert nincs eldöntve, hogy ki az adatgazda és nincs normális adatszinkronizáció a rendszerek között. Amikor pl. egy webshop teljesen más készletinformációt állít, mint ami a szigorú raktárkészlet kezelésben szerepel, akkor jönnek a problémák. Persze szolgáltatások számlázása esetén nincs ilyen probléma... Ha a saját rendszerünk hátteréből indulok ki, akkor műszakilag az az akadálya, hogy minden egyes darab termék egyedi belső azonosítóval rendelkezik, pontosan nyomon követhető az útja a rendszerben: mikor kitől mennyiért lett vásárolva, melyik raktárakban járt, milyen bizonylatokon szerepelt (szállítólevél, munkalap, stb.), mikor kinek lett kiszámlázva, stb. Ez a szigorúság biztosítja a precíz és jól dokumentált készletkezelést, az utólagos lekérdezéseket, statisztikákat, viszont nem egyeztethető össze azzal, hogy egyszercsak megpróbál a felhasználó olyan terméket számlázni, ami előtte nem lett bevételezve.

"Igazabol ezek a szamlazoprogramok kb. semmire nem jok (most ne pont a lafisoftra ertsetek)
Raktarprogramnak gagyik, altalaban egyszemelyesek, tavolrol nem lehet hasznalni oket,
egyedi (rosszul hasznalhato) guijuk van, sajat kis "szemetdombjuk" van, adatot cserelni veluk kb. lehetetlen."
Ezt inkább átfogalmaznám arra, hogy más a célközönségük. Ha nem a megfelelő programot választják a folyamatok támogatásához, akkor az nem a program hibája. Teljesen más igényeik vannak egy egyéni vállalkozónak, egy pár fős cégnek, egy sok telephelyen működő bolthálózatnak, egy multinak. Olyan számlázóprogram szerintem nem létezik, ami mindent le tud fedni, specializálódni kell. Bármilyen rendszer esetében lesz olyan, akinek túl fapados és olyan is, akinek túl pilótavizsgás ugyanaz a rendszer.

"Konkretan az esetek 90%-ara alkalmatlanok.
- penztargeppel es raktarprogrammal nem lehet osszekotni oket.
- kulon gep kell nekik
- van egy "Marika" aki ide *IS* beviszi az adatokat (partnertorzs, miegyeb)
- minden eladott szamlanal *ujra* be kell vinni az adatokat, mivel egyebkent nem ebben tartjak nyilvan a raktarkeszletuket, neadjisten webshop is van."
Pénztárgép összekötésénél nem feltétlenül a szándékkal vagy képességgel van baj. Legtöbb esetben olyan indokolatlanul nagy többletköltséget jelentene az ügyfélnek az engedélyeztetése és üzemeltetése, ami miatt nem éri meg megcsinálni.
Ha valakinek olyan igényei vannak, hogy különböző rendszerek között akar kommunikálni, akkor olyan rendszert kell választani, amivel ezek az igények megvalósíthatóak. Egy ilyen rendszerre viszont a sarki kisbolt fogja azt mondani, hogy pilótavizsgás, használhatatlanul bonyolult, stb. Csak egy példa: ha valaki összesen 5 partnernek állít ki számlát vagy 5 féle terméket tesz egy számlára, annak ideális, ha pl. egy legördülőből lehet közülük választani, de mondjuk többezer partner vagy termék egy legördülőben használhatatlan.
A külön gép is olyan dolog, hogy van, akinek kifejezetten azt szereti, mert akkor nem romlik el minden egy közös szerveren kiadott dist-upgrade esetén :). Van olyan, akit kiráz a hideg attól, hogy divatosan a felhőben legyenek az adatai, más pedig oda van a lelkesedéstől, hogy milyen modern dolog :)

"Egyebkent tegyuk fel, hogy te minden honapban kiadsz egy szamlat szerzodes alapjan.
Melyik az egyszerubb:
a) fogsz egy .xml fajlt atutod a datumot
b) ujra vegigkattintgatod a guin
Ennel egyszerubb peldat nem tudok..."
c) a szerződésnyilvántartásban egyszer felvitt adatok alapján a "Szerződések teljesítése"-re kattintva elkészül akár többszáz szerződés számlája is amit a rendszer e-mailben kiküld a vevőknek. A szerződés mellé a nyilvántartásba automatikusan rögzül a teljesítés időszaka, a kiállított számla adatai, így könnyen látható, hogy melyik szerződés melyik időszakra van már kiszámlázva. A kiállított számla adatai mennek a pénzügyi számlanyilvántartásba, aminek a kiegyenlítettsége bankon vagy házipénztáron keresztül történik, így a pénzügyileg rendezetlen számlákról további humán beavatkozás nélkül e-mailben mehetnek ki a fizetési emlékeztetők, felszólítások. Akár még a könyvelő is kaphat hozzáférést ezekhez... :)

"Van meg millio dolog, de szerintem kar folytatni. "
Nem biztos, hogy kár folytatni, mert a felhasználói visszajelzések alapján azért történhetnek fejlesztések :)

"Es vim-mel szamlat irni nem elvetemult dolog :))"
Ebben egyetértünk! Rám is furcsán szoktak nézni, amikor megmutatom, hogy terminálban w3m-el is teljes értékűen működik a rendszer :D

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Amiket itt felsorolsz az nem a szamlazoprogramnak, hanem a vallalatiranyitasnak a resze.

A szamlazoprogramnak annyi lenne a dolga, hogy megkap egy .xml-t, es kiad egy .pdf-et.
Hogy a NAV-ot is megnyugtassa rogton nyomtatora is kuldi, es torli.
Meg annyi a dolga, hogy lehessen sztorno szamlat kiallitani (szinten .xml a bemenet, pdf a kimenet), lehessen dijbekerot (pro-forma szamlat) kiallitani, ahol nem lenyeg a sorszamozas.

Ez egy kulonallo program lehetne. Es be lehetne integralni mas rendszerekbe, pl. amit te ecseteltel, ami vegzi a keszletnyilvantartast, behajtaskezelest, etc.
De az nem a szamlazo dolga.

Lehet a szamlazoval is osszecsomagolni egy ilyet, meg lehet guit mellecsomagolni, hogy a sarki kozertesnek is jo legyen, de az opcio.

En itt egy piaci rest velek felfedezni :)

A mostani szamlazo, amit hasznalok is ilyesmi, kiveve:
- gui kell hozza, hogy az xml-t "beimportaljam".
- nem lehet xml-bol sztornozni
- nem lehet xml-bol dijbekerot gyartani

Most lehet, megfogom az egeszet es beteszem egy kontenerbe, es leemulalom az egerkattintasokat...
A gond annyi, hogy neha fagyogat.

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

> Miért lenne kötelessége fogadni xml az adatokat?

Nem kotelessege. Erre mondtam, hogy piaci res.

A kerdes az az, hogy fel akarod-e vallalni a hibas formai szamla miatti birsagot (vagy sorszamozas:)), vagy ezt inkabb letolnad egy 3. fel fele, vagy erre csinalnal egy sajat kft-t.

Persze ha borul a bili, akkor boritsa a hoszt ceget, amelyik mondjuk 300 millio/ev nagysagrend.

A kerdes igazabol annyi, hogy erdemes-e sajat magadnak egy kft-t alapitanod erre, vagy pedig inkabb 10e/ev-ert cserebe vennel egy ilyen "konvertert".

Persze lehet hazardirozni, meg sok sikert a 13 eve fejlesztett tokeletes rendszeredhez (komolyan), de van aki szeretne a kockazatot minimalizalni.

Persze nem tisztan konverter, mivel ugyanolyan sorszamu xml-re hibat kell dobnia, es nem pdf-et gyartani :) Bar gondolom ezzel csak tisztaban vagy igy 13 ev utan (ha megse, akkor itt az elso bugreportod, javitsd gyorsan!)

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

Szerintem ma már nagyon kevés helyen van értelme számlázónak. Ahol van, oda elég egy számlatömb is.
Legtöbb helyen az online-bolt készletét szinkronizálni az offline appal meg egyenesen faszság és múltszázadi eljárás. Kizárólag a full integrált alkalmazásokban hiszek, ahol pedig a két app közé kell egy xml ott már baj van, mert ez a technológia kizárja a tranzakciókezelést.

En mar irtam meg 500 szamlat 1 het alatt kezzel. Annyira nem fun.

De hogy egy masik sztorival is szolgaljak:
Multkor belefutottam abba, hogy a 1678930 Ft-u szamla szamlakepe hibas volt (hianyoztak random sorok), ha az osszeget atirtam (45Ft volt a res), akkor normalis szamlat generalt.

Tok ego volt kezzel megirni a szamlat, mivel a szerzodes mar keszen volt, osszeget nem lehetett egyszeruen modositani...

Nesze neked ERP.

(az osszeg fiktiv termeszetesen. Lehet egy nagysagrenddel nagyobb is:)

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

Nem kell félni a számlázó megírásától. Az utóbbi 13 évben (erre van rálátásom) magát az alkalmazást nem kellett módosítanom. Törvényi változás is annyi volt, hogy a számla aljára különböző mondatok felkerültek. Az ÁFA váltásokat és a TEÁOR/VTSZ váltásokat pedig felhasználói felületről kellett módosítani, ami szintén nem érinti az alkalmazást. Egy számlázót megírni szerintem ujjgyakorlat kategória, amolyan ECDL power szint. :)

Könyvelő alkalmazás is hasonló nehézségű (ha tudsz könyvelni). Ami szopó az a bérszámfejtés, ott előfordulhat, hogy karácsony-szilveszter időszakot programozással töltöd, mindezt minden évben. Fasza lehet.

Itt nem 10e a tét. Hanem minimum -10 ember / hó. (Ha éheztettem őket minimálbéren akkor is ez nekem évi 20 millió Ft)
Én ebből élek. Amikor kisebb volt cégem majdnem 50 ember dolgozott nálam, azóta sokat nőttem és most 10 ember végzi el ugyanazt a munkát. Oké kb 30 értékesítő kiszervezve.
Vagyis feleannyi létszámmal üzemeltetek egy nagyobb vállalkozást és mindezt azért, mert kódolok.
Hogy megéri-e? Nem panaszkodom. :)

Két évvel ezelőtti állapot:
http://hup.hu/node/118541?comments_per_page=9999#comment-1590956

Tegyunk kulonbseget akozott, hogy valaki ERP irasabol akar megelni,
es akozott aki mondjuk loszerszamot arul, es a szamlairas egy teher.

Tudod konyvelo es adobevallo kozotti kulonbseg.
Bar mindketto elfer egy soralateten,
az egyik kap erte penzt a masiknak ez tisztan kiadas.

Egyebkent gratula az ERP rendszeredhez.

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

Tehetünk. Ettől függetlenül, ha a jövőt nézzük, akkor mindenképpen az online integrált rendszerekké a jövő. Értem ezalatt:
- számláz
- értékesít (shop vagy más módon)
- beszerez
- raktároz
- nyilvántart
- etc...

Mindezt egyben teszi. Nincs duplikáció, nincs XML, mert nem kell. Ha pedig jövő 2.0-át nézzük, akkor a könyvel is vagy a könyvelővel kompatibilis módot tartalmaz (inkább könyvel is). Így a jövőben sokkal olcsóbb lehet az ügyvitel és a kötelezettségekből adódó feladatok ellátása.

> Most komolyan, hatékonyabb egy xml-t kézzel megírni minden tag-el együtt,

Egyetlen egyszer kell.
Egy atlagceg (mondjuk vizvezetekszerelo ceg) a kimeno szamlait kb. 10 csoportra be tudja osztani. Meg 10 minta XML-lel is gyorsabb vagy.

Viszont .xml-t barmibol ki tudsz tolni. Akar egy Excelbol is...

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

( nagysa v | 2015. 05. 23., szo – 09:51 )

Jövő hét közepén tesztelni fogom.

( Beka v | 2015. 05. 23., szo – 23:28 )

Lafisoft:

Első nekifutásra, egy partner egy számla írása során minden oké (Linux Mint 17.1). Hibaüzenetek terminálban:


TLResourceList.Sort 95 DUPLICATE RESOURCE FOUND: Tfcikkimp:FORMDATA
TLResourceList.Sort 98 DUPLICATE RESOURCE FOUND: Tfcikkimp:FORMDATA

(szamla400:12683): GLib-CRITICAL **: Source ID 335 was not found when attempting to remove it

(szamla400:12683): GLib-CRITICAL **: Source ID 334 was not found when attempting to remove it

(szamla400:12683): GLib-CRITICAL **: Source ID 1506 was not found when attempting to remove it

(szamla400:12683): GLib-CRITICAL **: Source ID 1505 was not found when attempting to remove it

(szamla400:12683): GLib-CRITICAL **: Source ID 1511 was not found when attempting to remove it

(szamla400:12683): GLib-CRITICAL **: Source ID 1510 was not found when attempting to remove it
[WARNING] SetAlphaBlend called without handle for frProgressForm(TfrProgressForm)

(szamla400:12683): Gtk-CRITICAL **: IA__gtk_window_set_focus: assertion 'gtk_widget_get_can_focus (focus)' failed

(szamla400:12683): GLib-CRITICAL **: Source ID 2243 was not found when attempting to remove it

(szamla400:12683): GLib-CRITICAL **: Source ID 2242 was not found when attempting to remove it

(szamla400:12683): GLib-CRITICAL **: Source ID 168 was not found when attempting to remove it

(szamla400:12683): GLib-CRITICAL **: Source ID 167 was not found when attempting to remove it

Illetve az elkészült számla tétele a Pénzügyben megnézve, a listában egységárra 30.000 helyett 3E4-et mutat. :D

( khiraly | 2015. 05. 26., k – 01:36 )

En is megneztem. Igazabol pont ugyanaz a baja, mint amire szamitottam.
Nem lehet semmivel osszekotni, igy csak azoknak jo, akik ezen a programon belul el tudjak kepzelni a vallalatiranyitasukat.

A GUI az tenyleg csucs. Szurke alapon feher betu (menuben, ha aktiv a menu), es sotetkek alapon szurke betu. Egyik se olvashato.

Ha valahol tablazatot kell megjeleniteni, akkor kb. az elso karakter jelenik meg az oszlopban.

Ide is ugy kell felvinni a vevoket egyesevel, es az arukat szinten egyesevel, amit a szamlan akarsz szerepeltetni.
Tenyleg sarki szgepboltnak elegendo igy.

Az egesz hasznalata eleg pilotavizsgas. Kb. kell egy heti oktatatas, es 40 felett havonta ismetelheto:)

A kezdo popup-nal(!) a "Póstacím"-et javitani illene.

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

ugyanott: "A cégh neve" :)

Egyébként ha a helyesírási és az ux hibáktól eltekintünk, nagyon jó kis programocska. Kis, egy emberes boltoknak ideális.

Egy időben én is ilyesmit használtam, de azóta változtak az igényeim és bárhonnan használható online számlázóra váltottam.

--
[ Falu.me | Tárhely | A Linux és én ]

( fefe | 2015. 05. 26., k – 03:41 )

A weboldal kinézete egy dolog, de hogy az ügyfélkapu simán HTTP az nagyobb gond.
SSL/TLS nélküli oldalra soha nem irok be jelszót.