1

(68 replies, posted in NOVÁ VERZIA)

albertoto:

dovolim si vysvetlit pouzitie transferu. Napr. kupujem nieco pre niekoho a ten mi to preplati. Neni to vydavok, su to peniaze na ceste. Cize vydaj penazi bez toho, aby to ovplyvnovalo nakladovu bilanciu.

Urobim nakup napr. za 100 EUR a firma mi zaplati zajtra napr. 50 EUR v hotovosti a pozajtra doplati 50 EUR na ucet. Cize transfer mam T- a T+, kde v T- je 100EUR s dnesnym datumom, ale prijatie penazi je s inym datumom, napr. zajtrasim T+ 50 EUR. Ano, vznika tam rozdiel a napr. o tyzden vytvorim T- s 0 EUR a T+ 50EUR. Potom T-0 EUR mozem kludne zmazat. Takto mam zapisane datumy, kde som nieco platil a kedy som nieco prijal. A neni to ani vydavok, ani prijem, co by ovplyvnoval bilanciu. Keby som to tak nerobil, tak mi sledovanie obratov vydavkov, prijmov, alebo salda lezie do nepravdivych cisiel.

Proste je to nieco ako v beznom firemnom uctovnictve rozdiel medzi danovym a uctovnym vydavkom a prijmom. Transfer sa tak stava iba evidenciou bez ohladu na realne saldo prijmov a vydavkov.

PetrM

ale nezvyknu si na to, že vidím nedůležité údaje na úkor těch důležitých.

Ciastocne suhlasim. Treba tie dolezite informacie mat viditelne co najskor, ale netreba zabudat, ze tie nedolezite mozu byt zase len z tvojho uhla pohladu a pre niekoho ineho dolezite su.

Uctovnicto moze sledovat ako bilancny stav, tak evidencny. Pre niekoho su dolezite transakcie, pre ineho bilancie. Alebo oboje. Niekto by rad zase i v okne volitelne statistiky za urcite definovane obdobia. Napr. posledny rok, dva, tri, alebo kvartal 1-4, ci sumar iba pre nejake tagovane VIP ucty, ktore su kriticky dolezite a ostatne nemusia byt az take zaujimave.

Tak ostava na Slavikovi najst ten kompromis medzi vypovednou hodnotou, jednoduchostou. Osobne sa mi paci myslienka, ze to uzivatel dostane nejak preddefinovane a vyberie si lahsi rezim, advanced, alebo custom. Tak to moze ostat ako jednoduche a prehladne, ako aj pouzitelne pre zlozitejsie operacie. Imho vela uzivatelov zisti az neskor, ked sa zoznami s programom, co vsetko sa da robit.

Mozno by nebolo zle aj zalozit vlakno na nejake nastavenie ciselnikov, kategorii a podkategorii s cielom podla toho, co chceme v buducnosti sledovat. Ako pri podnikovych systemoch - implementacia je dolezita. Ked si niekto od zaciatku rozvrhne nieco zle a potom chce nieco sledovat, uz ma smolu, ze tie udaje ma usporiadane inak a musel by si to prerabat alebo zacat od zaciatku.

Mozno by defaultne mohlo byt pre noveho uzivatela pri prvotnej inicializacii databazy pouzite nejake predpripravene udaje. Napr. 10 zakladnych kategorii, zakladne ucty typu - hotovost, bankovy ucet, stravenky. Osoby ako manzelka, dieta1, dieta2 atd. Uzivatel si ich uz len premenuje a dotvori dalsie. Imho by vela uzivatelov s jednoduchsim pristupom toto mohlo vyhovovat. Nieco ako "viac učesaná" demo databaza, v ktorej by uzivatel pokracoval.

Napr. niektore banky to maju takto predpripravene na oznacovanie kategorii pre evidenciu vydavkov - zakladne kategorie /tam uz aj s nejakou automatikou, ako to rozozna system/.

PetrM

Ano, případ, že si vyfiltruju jeden konkrétní účet za konkrétní období to smysl má.

Ma to zmysel aj pre viac uctov, alebo skupinu uctov. Ta skupina mozu byt totiz virtualne ucty, ktore tvoria jeden fyzicky ucet. Alebo niekolko fyzickych uctov tvori REZERVU a clovek chce mat prehlad o vsetkom v rezervach. Alebo niekto tam eviduje ucty dietata, ci manzelky. A chce mat odelene, ze transakcia a bilancia je za jeho ucty samostatna a za ucty rodiny zase ina. A inokedy chce mat celkovy pohlad na vsetky rodinne ucty. Tak su to raz ukazuje ako hrusky s jablkami a inokedy ako dobry ovocny kolac big_smile

Vela ludi uvedie len jednu stranku problemu a hovori "to je dolezite". Vychadzaju len zo svojej situacie a nezohladnuju, ze program mava casto sirsie pouzitie a to co sa im zda zbytocne, je dolezite pre ineho. Preto aj preferujem rozne "profily" pre nastavenie typu uzivatela, aby mal kazdy to svoje.

2

(68 replies, posted in NOVÁ VERZIA)

Na zaciatok len, ze uvediem osobne postrehy, komentar a nesnazim sa dehonestovat inak skvelu pracu Slavika. Pisane je to tak, ako mi to pri uvahach prislo na rozum.

Meviem cim to je, ale verzie 2.x mi pripadali intuitivnejsie. Ked som videl verziu 3.x prvy krat pripadala mi ako ine financne programy na domace uctovnictvo, kde som sa trochu stracal a ktore ma vobec neoslovili. Neviem, aky bol hlavny dovod vsetko robit od zaciatku, ked stacilo len vylepsit stavajuce. Mozno tam bolo vela kostlivcov a je to lepsie od zaciatku, ale koncept 2.x bol imho velmi dobry aj s tymi sumarmi a grafmi na obazovke. Stacil pohlad, pripadne klik-dva a podstatne informacie su zobrazene. Ak tam boli nejake technicke dovody, stacilo by zobrat len koncept 2.x a technicky to prerobit do noveho, pripadne dorobit vylepsenia.

Tiez musim povedat ako Petr M., ze ako IT vnimam u rozneho SW po rokoch dnes ako uz celkom bezne, ze SW dospeje do doby, kde uz nevedia, co by zmenili a tak sprehadzaju uplne dobre ovladanie, alebo to urobia v bledomodrom. Velmi je badat v svete SW tento trend s prichodom tabletov a smartfonov - znasilnovat desktopove verzie na dotykove. U verzie 3.x sa to na prvy pohlad trochu podoba starsej verzii, ale bral som to iba ako koncept, ktory sa bude dalej zlepsovat. Ak to ma ostat v podobnej forme, asi zvazim ostanie pri 2.x verzii, kde az na par malickosti to bolo vcelku vyladene.

Z mojho pohladu Slavik /ale ako autor programu to samozrejme mozes vidiet inak/ je efektivnejsie vylepsit a ponechat + rozvijat to dobre, opravit to zle, vylepsit stare, ako uplne nanovo prerabat vsetko od piky a snazit sa postavit opat koleso. Tej prace co to musi dat a nakoniec bude "volant niekde v kufri auta". Na jednej strane neni casu, na druhej strane, co to muselo zozrat casu.... a potom uvedies, ze nemas na to cas. Je to tvoj cas.

Stale tvrdim, ze klobuk dole pred RQ Money a ono sa zle nieco hodnoti, ak sa bavime len o nejakej alfaverzii a konecna moze byt uplne ina. Mozno by to chcelo ujasnit si nejak koncept a drzat sa ho. Zatial je verzia 3.x hodne zjednodusena /alebo ma este vela dorabania/. Imho SW pre osobne financie by mal pocitat s vyuzitim ako jednoduchosti a prehladnosti, tak moznosti vyuzitia aj podrobnejsich nastaveni a dosiahnut aj na podrobnejsie informacie. Co by vyuzili jednak uzivatelia zaciatocnici, tak pokrocili, co maju financie zlozitejsie. Aj zlozite podnikove informacne systemy maju casto osekanie roznych funkcii, ze sa nepotrebne funkcie daju vypnut, aby to nerozptylovalo uzivatela /alebo si clovek zaplne podrobnejsie funkcie/.

V starsej verzii musim chvalit saldo, grafy a statistiky. Ak si to clovek rozumne nastavil, tak nemiesa hrusky a jablka. Ale musi si dobre rozmysliet, ako si nastavi ciselniky, kategorie a co bude skumat, ako casto a kolko toho bude. K tomu by sa vsak hodilo napr. aj to rokmi spominane tagovanie, ci grupovanie uctov. Logicka vytka k starsej verzii je, ze ak clovek pouziva rozne meny, tak scitavanie CZK + USD + EUR, tak su to hrusky + jablka + maliny... Tak isto v dnesnej dobe byva aj rozne pouzitie podielovych fondov, atd - co je podobne cudzim menam a kurzu. Ak by bola hlavna mena a do nej sa prepocitaval kurz podla nejakeho kurzoveho listka /alebo vlastnej nastavitelnej hodnoty/, malo by to vacsiu vypovedaciu informaciu. Nastastie cudzie meny nevediem, tak som ich aspon vyuzil na grupovanie uctov.

Co sa tyka ovladania u V3.x - napr. pridam transakciu, u V2.x a vybehne okno, ktore clovek neprehliadol. U V3.x klikam niekolkokrat a nic... Potom sa lepsie divam a uplne nenapadne to vybieha v pravom menu. Ano, clovek si zvykne, ale ako intuitivne to moc neni pre prvouzivatela. A priznam sa, ze to iste sa mi stalo po 2 dnoch, co som program opat spustil.... Asi starnem a moja intuicia v ovladani SW tiez smile

U V2.x mi to vybehujuce menu v strede obrazovky prislo privetive a intuitivne u V3.x to na mna posobi nejak stiesnene, depresivne, neintuitivne, stroho. Asi bol zamer zmestit viac informacii na obrazovku, ale zase pocas nahadzovania udajov clovek nepatra ocami po dalsich udajoch, ale venuje sa nahadzovaniu transakcie. A opacne, pri pozorovanie salda, ci transakcii je zase zbytocne napravo neaktivny pruh, ktory zmensuje transakcne okno.

Inak, ak by bola k tomu aj demo verzia databazy /ako bolo dobrym zvykom u starsich verzii/, nebolo by to zle, ako ked vidi clovek iba holy program a musi si zo zaciatku nastavit  nejak vsetky ciselniky. Ale bavime sa o alfa verzii, tak sa to aspon snazim zatial vidiet.

Imho, momentalne by mali byt v uvahe 2 varianty:

1/ programova linia je uz premyslena a bude sa podla nej pokracovat, pripadne len odstranovat chyby.
alebo
2/ alfa verzia nema este celkovy koncept a diskusiami sa budu davat podnety na najdenie spravneho postupu, umiestnenia "a vymyslania nove kolesa, nez toho, co bolo vo V2.x verzii".

3

(68 replies, posted in NOVÁ VERZIA)

Zatial postrehy:

- paci sa mi filter kategorie, kde zobrazuje ako hlavne kategorie, tak podkategorie. smile

Co ma vsak zaraza, mozno to neni chyba, len je to nedorobene, ze filter pre menu - CURRENCY nezobrazuje vsetky filtrovane ucty v danej mene, ale je nutne rozkliknut a vybrat si. V starej verzii to bolo prehladne a vyuzival som to na rozne virtualne ucty, alebo skupiny uctov podla logickej hodnoty. Ked sa dalo bud selektivne vyberat ucty, aby sa clovek dozvedel sumar, alebo vybrat cez menu celu skupinu uctov, ak clovek potreboval casto informacie o danej skupine uctov a nemusel tak zakazdym narocne vsetko vyklikavat.

Ad import - pozorujem, ze nie som sam co ma rozsiahlejsiu databazu a som asi o cca 100 transakcii pozadu za uzivatelom albertoto a mam zhruba asi podobnu strukturu. Som rad, ze nie som sam takto "postihnuty" smile Zatial som si len vsimol, ze po importe dat z povodnej databazy do novej prazdnej, sa velkost databazy zvacsila o 35 percent.

Za 7 rokov pouzivania programu - cca 17500 zaznamov, 264 kategorii, 258 partnerov, 11 osob, 31 uctov. Po rokoch su tie statistiky zaujimave, ako clovek zabuda a pozoruje rozne trendy/vyvoj v cenach, nakladoch, ci inflacii. Teraz by som mozno usporiadaval tie kategorie inak, ale uz to nechcem menit a vyhovuje mi to. Ked clovek urobi zasadne zmeny v uz existujucej starsej strukture, tak to rozhasi celu statistiku.

Tagovanie - som rad, ze sa pridava tato funkcia. Uvital by som aj nejake tagovanie uctov, alebo ako extra funkciu. Clovek by nemusel vymyslat rozne neprakticke okluky ako si urobit filtre na rozne skupiny uctov.

Prakticke vyuzitie je napr. rozdelovanie fyzickeho uctu na virtualne ucty /alebo si to niekto nazve na ucely, sporenia/. Pripadne na spajanie viacerych uctov virtualnych, alebo fyzickych, ktore by tvorili istu logicku skupinu. Napr. trebars DOCHODOK alebo niekoho pozicane peniaze/ci zalohy ulozne na roznych uctoch v roznych menach, roznych bankach atd. Bola by to velmi sikovna pomocka. Niektore banky maju takto robene trebars rozne setrenia na nejaky ucel a nemusia na to vytvarat zakazdym nove fyzicke ucty. Pripadne, aby sa nepomiesali peniaze rodiny, ak si ich niekto ulozi na svojom uctre, spravuje, postrazi, atd. Apeloval by som na zvazenie - je to velmi prakticke, ked sa daju ucty rozne grupovat. Pripadne ciastocne by sa dalo riesit aj pridanie kategorie umiestnenia uctu. Ze chcem napr. filtrovat iba EUR alebo CZK ucty a  chcem vediet v ktorych bankach. Alebo vyberiem banku a chcem vediet sumar vsetkych uctov v nej. Toto napr. velmi chyba v 2.x verzii, ked sa musi clovek oklukami dopatrat k celkovemu zostatku v urcitej banke - ak tam ma viacero uctov.

4

(68 replies, posted in NOVÁ VERZIA)

Slavik wrote:
loktibrad wrote:

Verzia 32bit - import sa vobec nepodaril.

32bit verzia mala chybu, dnešná oprava to vyriešila. Skús importovať s dnešnou verziou č. 4.
Predtým som vydával len jednu verziu pre WIN, teraz tri - WIN32, WIN64 aj pre Linux. Bude sranda, ak sa mi podarí zohnať nejaký OSX a preklopiť to aj tam. smile


Tak sa podarilo. Import cez 17000 zaznamov.

5

(68 replies, posted in NOVÁ VERZIA)

pejzlmiloslav wrote:

Ale právě v současném novém TRANSFERU v BETA 3 verze 4 lze sumy měnit, což byl záměr Slavika od počátku. Já jsem nepochopil funkčnost, Slavik zveřejnil podrobný návod a já zjistil, že není třeba celý nový TRANSFER předělávat, což Slavik chtěl. Vyjádřil jsem jen podporu jeho novému návrhu, aby nemusel celý program předělávat. Tak nevím proč Loktibrad nesouhlasí s novým pojetím TRANSFERU.

Pardon, to mala byt reakcia na citaciu textu uzivatela albertoto:

"Predsa keď robím TRANSFER, možnosti programu by nemali umožniť zadať rôzne sumy pre Z nejakého účtu NA nejaký účet."

Bolo to myslene, ze ina suma pre transfer pre prijem a vydaj je praveze vhodna. Ono sa to dalo riesit bez vacsich problemov aj v starsej verzii editovanim prislusneho zaznamu a nenapadlo ma, ze viac ludom by sa hodila tato funkcia, tak som k tomu asi nedaval ani komentar, kedze Slavik mal ine priority a mal som dojem, zeby to bral ako minoritu, alebo ako vacsiu narocnost pre uzivatela. Pre mna je toto rozdelenie viac ako vitana funkcia, nakolko transfery pouzivam celkom casto i ako virtualny prevod v ramci jedneho fyzickeho uctu.

6

(68 replies, posted in NOVÁ VERZIA)

Slavik:

Skús sa na to pozrieť optikou inou ako bolo doteraz v predošlých verziách programu. Dáš si napr. kategóriu PRÁCA a máš v nej ako príjmy (MZDA, možno STRAVA [stravné lístky], možno preplatená DOPRAVA [ak dochádzaš] a INÉ) aj výdavky (STRAVA, DOPRAVA, a INÉ). Takto to všetko môžeš mať v jednej kategórii PRÁCA a v dvoch-troch kategóriách si eviduješ príjmy a výdaje súčasne na STRAVU, DOPRAVU či INÉ. Možno v podkategórii MZDY eviduješ len príjmy. Ale ak si nedáš podkategóriu INÉ, kľudne môžeš tieto iné príjmy či výdavky (ktoré nechceš evidovať osobitne v podkategórii) zapisovať priamo na kategóriu PRÁCA. Týmto spôsobom bude vytvorených oveľa menej kategórií (a hlavne podkategórii) ako doteraz.

To sa zda celkom sikovny napad. Nad niecim takym som uvazoval uz pri 2.x verziach. I ked aj tam sa to dalo riesit, ak si clovek pomenoval rovnako podkategorie, mohol ich tusim potom filtrovat obe naraz.

Napomocne to moze byt trebars pri platbach, ktore sa platia zalohovo a potom dojde napr. jednorazove dorovnanie, ktore moze byt preplatok. Potom su vydavky/zalohy zapocitane aj s preplatkom a vidno tak skutocne naklady po zapocitani vratky.

7

(68 replies, posted in NOVÁ VERZIA)

albertoto wrote:
pejzlmiloslav wrote:

AHOJ, NIKDO SE NEOZVAL PROTI A TAK MÁM ZA TO, ŽE JE SOUHLAS S TÍM, ABY SE PROGRAM NEPŘEDĚLÁVAL DO PŮVODNÍ PODOBY TRANSFER. NOVÁ PODOBA V TESTOVACÍ VERZI 3 JE JEDNODUCHÁ A PLNĚ FUNKČNÍ.

Nenástojím na prerábaní transakcie TRANSFER. Vyjadril som len svoj názor.
Išlo mi najmä o to, aby sa pri zadaní transakcie nemohli nezadaním rovnakých kľúčových parametrov rozísť oba záznamy. Najmä v sume. Predsa keď robím TRANSFER, možnosti programu by nemali umožniť zadať rôzne sumy pre Z nejakého účtu NA nejaký účet. Pri transfere sa nemôže niekam niečo "stratiť", rozdeliť, a pod. smile
Prekliknutie z jednej záložky do druhej mi len pripadalo z používateľského hľadiska  o 1 klik naviac viac ako to bolo vo verzii 2.x. Súčasná funkčnosť v 3.0 samozrejme funguje.
Koniec-koncov, u mňa je tých transférov relatívne málo, najviac je jednoznačne výdavkov/debitov.


Dovolim si nesuhlasit s pojatim transferu. Nie kazdemu to tak musi vyhovovat. Ak nieco poziciavam, alebo pozicia to niekto mne, ci robim niekomu nakup a on to preplaca, tak mozem mat minusovu sumu jednu a viacero sum plusovych. Trebars sa to uhradi na viackrat, alebo roznymi sposobmi.

Samozrejme, ze aj pri transfere sa moze nieco "stratit". Napr. dorazi len cast penazi /manko, sprenevera, nejake prevodne naklady, atd/. Alebo len proste dlh nie je komplet splateny, len ciastocne.

8

(68 replies, posted in NOVÁ VERZIA)

Verzia 32bit - import sa vobec nepodaril.

Hlasi tam

Conn: 8 Values for 7 Columns
Press OK to ignore and risk data corruption.
Press Abort to kill the program.

9

(68 replies, posted in NOVÁ VERZIA)

Skusil som kniznicu, ale nefunguje to. Pockam na 32 bit verziu a potom sa mozem pustit do testovania. Kym sa dostanem k upgradom masin, na to nemam akosi ani casu, ani chuti :-D  Uz sa tesim na novu verziu.

Coze to, ze ta zmena licencneho modelu na freeware? Myslel som, ze pri vyvoji nejaka ta financna kompenzacia aspon trochu pomaha? Nieco sa zmenilo, je viac casu, chuti, motivacie.....?

Pripadne neni v plane vydat nejaku poslednu 2.4.x verziu ako freeware, ak by niekto chcel ostat na nej, zeby mu nova nevyhovovala?

10

(68 replies, posted in NOVÁ VERZIA)

Skoda, ze je to iba 64bit. Este som neupgradol masiny a mam na vacsine stale stare 32bit smile

11

(3 replies, posted in OSTATNÉ)

Vdaka. Databaza je hned o tretinu mensia. smile

Pripravit sa v buducnosti na nejake limity, problemy, ci obmedzenia, kedy to uz zacne robit nejaky problem, alebo je to len vsetko otazka hardware?

12

(3 replies, posted in OSTATNÉ)

Mam v databazi vela zaznamov. Ked sa uctuje medzi viacerymi uctami pouzivam metodu, ze to nauctujem vsetko na jeden ucet a potom to opravim. Cez CTRL+H vidno zmeny v databaze na danom zazname. V podstate tieto informacie nepotrebujem, len za tie roky uz budu zaberat znacne mnozstvo udajov a databaza mi uz "trochu seka".

Akym sposobom je mozne oznacit a zmazat tieto stare a nepodstatne historicky zaznamy, ktore normalne v programe ani na prvy pohlad nevidno a zaberaju tam len zbytocne miesto?

13

(22 replies, posted in OHLÁSENIE CHYBY)

agentsvr wrote:

Příkaz VACUUM jsem rovnou napsal, zobrazilo to prázdné okno, ale po zadání SELECT * FROM DATA se stejně ty smazané transakce zobrazily.

Jiná možnost, jak si ty transakce můžu smazat neexistuje?

Už to vidím, z csv vyexportovaného programem nefunguje zpětný import... Tak se těším na novou verzi.
Zatím tedy budu export obcházet dříve uvedeným způsobem.


Skus si stiahnut   https://sqlitebrowser.org/

Otvoris v nom databazu. Cez "Execute SQL" mozes zadat "delete from data". Vymaze vsetky transakcie v tabulke data. Potom das FILE/Compact database. Naozaj odstrani z databazy uz zmazane.

Alebo pouzijes:

delete from data where d_id < 500

Co zmaze z tabulky data vsetky ID zaznamy mensie ako 500. Podobne si nastavis cisla ID vascie, ci mensie, ako chces. A nakoniec das FILE/Compact database.


Samozrejme nesmies to aplikovat na sifrovanej databaze, tu musis mat desifrovanu.

ALEBO to skusis manualne s pomocou "Browse data". Oznacis si klasicky cez shift + mysi klik na zaciatok a koniec bloku a das  Delete record. Len je to tusim pomalsie ako cez prikaz. Nakoniec das este "Write Changes" a potom FILE/Compact database.

Po pokusoch natiahnes databazu do RQ Money a otestujes si, ci ti hadze chybu.

14

(22 replies, posted in OHLÁSENIE CHYBY)

agentsvr wrote:

Děkuju za radu. Jak ale poznám, jaké znaky jsou nevhodné? Používám všechno možné, ale "•" ne.
SQL příkaz jsem udělal, ale zobrazilo mi to všechny transakce. 7000 transakcí nemám šanci zkontrolovat. Asi jsem neporozuměl postupu, jak nevhodné znaky (které?) vyhledat.

Hezký den

Robi to aj na inom pocitaci? Nemoze byt chyba napr. v hardware, vadna RAMka? Na mojej databaze slo selektovat vsetko, export do XLS vyse 15000 zaznamov.

15

(22 replies, posted in OHLÁSENIE CHYBY)

Mozno by slo urobit aj kopiu celej databazy a potom robit pokusy.

- vymazat prvu polovicu zaznamov, otestovat chybu.
- vymazat druhu polovicu zaznamov, otestovat chybu.

V jednej polovici sa najde chyba a tak ju znova rozdelit, atd, atd. Po par rozdeleniach sa dojde na problemovy usek a najde sa zaznam, ktory vadil.

16

(22 replies, posted in OHLÁSENIE CHYBY)

loktibrad wrote:

Dalsia chybicka:

ked zadavam viacnasobnu transakciu cez F2, tak si program po pridani zaznamu nepamata posledne pouzitu kategoriu. Hadze tam vzdy prvu v zozname.



DOPLNENE - este jedna chybicka, asi to suvisi spolu:

A este v danom menu F2 pri viacnasobnej transakcii - ak je uz nahodeny nejaky zaznam /a neni to ulozene/ a dam kopiu transakcie, urobi chybne duplikat - nehodi tam rovnaku pouzitu kategoriu, ale zase prvu kategoriu v zozname.

DOPLNENE do tretice:
ak dam v danom menu F2 pri viacnasobnej transakcii - ak je uz nahodeny nejaky zaznam, opravu tohoto zaznamu, neukaze tam ulozenu kategoriu, ale hadze tam prvu kategoriu.


Upresnenie k chybam. Zda sa, ze tieto chyby sa neprejavuju vzdy. Len ak bola posledna transakcia v zozname transakcii PRESUN.

Pokial bola posledna transakcia v zozname transakcii, prijem alebo vydaj a clovek chce cez F2 pridat hromadnu transakciu, potom sa chyby neprejavia. Ak bola posledna transakcia v zozname transakci PRESUN, chyby sa prejavia. Tak isto staci po transakciach VYDAJ, alebo PRIJEM v F1 bez ulozenia prepnut typ transakcie na PRESUN a uz to v F2 blbne u kategorii ako bolo pisane.

Este raz DOPLNENIE:

zda sa, ze ta chyba sa viaze viac na F1, jednoduchu transakciu. Ak bola robena cez F1 posledna transakcia ako presun a cez F2 sa mohlo aj niekolkokrat pridavat stale PRIJEM, ci VYDAJ, potom pri zadani novej transakcie, je stale u F1 pouzity ako posledny presun a pokial sa ten nezmeni na nieco ine - napr. VYDAJ, ci PRIJEM, tak to stale blbne, ako bolo popisovane.

17

(9 replies, posted in NOVÁ VERZIA)

Ak nieco pani tvrdite, tak ktoreze moje vylepsenia Slavik akceptoval, pripadne ktore z nich zneprehladnili system? Ak vobec nejake existuju. Daval som viacero navrhov, ale nepamatam sa, zeby bolo nieco akceptovane.  Prosim, budte konkretnejsi.

Mnozstvo funkcii programu ani nepouzivam, som len jednoduchy uzivatel, co ma len niektore zakladne evidencie trosku podrobnejsie.

A suhlasim s vami, ze niektore funkcie su pre pokrocilejsich uzivatelov a kludne tam byt nemusia. Ale z ineho dovodu - pretoze su prakticky nepouzitelne, nie su dobre navrhnute. Riesia nieco ciastocne a vytvaraju problemy nove. Ine zakladne funkcie zase chybaju a inde sa zase miesaju hrusky a jablka do gulasu.

18

(22 replies, posted in OHLÁSENIE CHYBY)

Dalsia chybicka:

ked zadavam viacnasobnu transakciu cez F2, tak si program po pridani zaznamu nepamata posledne pouzitu kategoriu. Hadze tam vzdy prvu v zozname.



DOPLNENE - este jedna chybicka, asi to suvisi spolu:

A este v danom menu F2 pri viacnasobnej transakcii - ak je uz nahodeny nejaky zaznam /a neni to ulozene/ a dam kopiu transakcie, urobi chybne duplikat - nehodi tam rovnaku pouzitu kategoriu, ale zase prvu kategoriu v zozname.

DOPLNENE do tretice:
ak dam v danom menu F2 pri viacnasobnej transakcii - ak je uz nahodeny nejaky zaznam, opravu tohoto zaznamu, neukaze tam ulozenu kategoriu, ale hadze tam prvu kategoriu.

19

(9 replies, posted in NOVÁ VERZIA)

Slavik wrote:

loktibrad, neviem, či to je až taký dobrý nápad.
Ide o to, že si v okne Zápis plánovaných platieb (CTRL+Y) opravíš nejaké platby ešte pred zápisom. Ako dobre vieš, v tomto okne môžeš aktualizovať všetky polia (dátum, sumu, popis, účet, kategóriu, osobu, partnera a pod.). Nezabúdaj, že do tabuľky Platby sa Ti automaticky (t. j. bez toho, aby si toto okno otváral) z týchto zmien zapíšu len dve polia - dátum a suma (nič iné). Nezávisle od toho, či potom platbu určenú na zápis napokon zapíšeš alebo nie.

Ak potom cez novo pridané tlačidlo PLATBY privoláš okno Platby a niečo tam zmeníš, ako má program aktualizovať okno Zápis plánovaných platieb ? Aktualizácia by totiž stornovala všetky Tvoje zmeny, ktoré si si dovtedy v okne Zápis plánovaných platieb urobil.

Snáď mi rozumieš, čo tým myslím... smile

Neviem - napr. reload okna? Alebo reload konkretnych policok platby? Bol to iba taky napad, ak to ma robit problemy, tak kaslat na to.


Inak s planovanymi uhradami ma napadla este jedna vec, ktoru program neriesi. A to su - ciastocne uhrady.

Napr. by pri oprave sumy bolo niekde zaskrtavatko, ci sa jedna o ciastocnu uhradu. Ak by sa to zaskrtlo, tak planovac, by si pridal zvysok sumy do planu - napr. na druhy den, treti den, alebo volitelny den.  Pripadne, by len zapisal uhradu s mensou sumou, ale platba s rovnakymi parametrami /ako rovnaky datum/ a zostavajucou sumou, by ostala v platbach visiet na uhradu.

Ak by sa nezaskrtlao, ze ide o ciastocnu uhradu, bral by to planovac ako plne uhradene, aj keby bola uhradena mensia suma. Pomohlo by to nezabudnut, ze ostava cast sumy este splatit.

20

(9 replies, posted in NOVÁ VERZIA)

Jeden navrh na mini vylepsenie pohodlia -

pri zapise platieb CTRL+Y - Zapis planovanych platieb - by sa ziadalo dostat sa na podokno PLATBY a upravit ich jednotlivo.

Ano, da sa zavriet okno a ist do planovaca, kde je tato funkcia, ale stacilo by v "Zapise planovanych platieb CTRL+Y" len dole medzi ostatne tlacitka OPRAVIT, VYMAZAT, KALENDAR, NASTAVENIA, vsunut aj PLATBY. Clovek by tak nemusel pri zapise platieb, ak chce nieco zmenit, vyskakovat z toho a spustat podobnu funkciu planovaca, ako sa to robilo este volakedy dost programov v dekade pred koncom milenia.

Neni to nic, bez coho by sa nedalo fungovat, ale bolo by to urcite o nieco pohodlnejsie a predpokladam, ze tam nebude velka narocnost na zmenu.

21

(22 replies, posted in OHLÁSENIE CHYBY)

Na rovnakom hardware som nabootoval rozne systemy:

Windows XP-32bit SP3 x86           - obe chyby sa prejavuju.
Windows 10-x64 ver 10.0.10586  - obe chyby sa prejavuju.
Windows 8-x64   ver   6.2.9200    - obe chyby sa prejavuju.

Bez ohladu na nastavenie, ci mam zaskrtnute vzdy nastavit aktualny datum vo filtri, chyby sa prejavuju - ak program ukoncim-zavriem aj  s filtrom, kde je tabulator nastaveny na mesiac a rok, vtedy korektne po spusteni a otvoreni databazy zobrazi ten isty mesiac a rok. Pokial je zapnute nastavit vzdy aktualny datum vo filtri, prepne sa na druhy tab, kde nastavi sa na aktualny datum, ale ked prepnem na tab do filtra mesiac a rok, uz tam nesvieti posledny aktualny mesiac, ale januar 2019.

Vyskusal som to aj na demo databazach, robi to rovnako. Resetoval som aj inicializacny subor, detto.

22

(22 replies, posted in OHLÁSENIE CHYBY)

Nova chybicka - pri zadavani udajov cez viacnasobnu transakciu F2 je vlavo ucet. Nefunguje v nom vyhladavanie podla pismen. Po stlaceni pismena sa filter uctov zavrie. Na jednoduchej transakcii F1 je rozbalovanie uctov s vyhladavanim OK.

23

(22 replies, posted in OHLÁSENIE CHYBY)

Zatial najdena iba drobna chybicka, ked je nastavene ukladanie filtrov. Tyka sa funkcie "Nastavit vsetky naposledy pouzite filtre".

Nastavim si mesiac napr. November 2019. Ked program zavriem, prihlasi ma to spravne nastavene na Novembri. Ak vsak prekliknem napr. miesto mesiaca na Den, kludne mozem medzi nimi prepinat a zobrazuje to spravne bud Den, alebo November. Ked teda nastavim filter na Den a zavriem program, tak po spusteni uz v mesiaci je nastaveny Januar 2019.

24

(118 replies, posted in OHLÁSENIE CHYBY)

pejzlmiloslav wrote:

Patch 7 - okno Nová transakce, jak v systémových barvách, tak v barevném potahu Smokey quartz kamri: POPIS - nedoplňuje po zadání písmena klávesnicí, ostatní doplňuje.

Neni to nahodou v nastaveniach len vypnute?

Neviem, ako dalsim ludom, ale mne to na starom WinXP v popise vyhladava - ak mam zapnute v nastaveniach v Program/Transakcie/Hladat polozku zoznamu, pomocou pisania (nastavit cas na pisanie v milisekundach).

25

(118 replies, posted in OHLÁSENIE CHYBY)

Petr M. wrote:

Loktibrad v tom dělá opět podle mě zbytečný guláš.

Ano, správně je samozřejmě jak píše Slávík SUM ve stylu +- transakcí:
(napr. + 10) výdaje (- 25), takže výsledok SUM = -15.

Nic jiného ani nečekám z hlediska účetního. V předchozích verzích aplikace (myšleno 2.3.x) to tak fungovalo bez problémů. Ten problém, který popisuji je až od verze 2.4.x.
Někde se ale muselo něco změnit, protože mě to teď opravdu počítá špatně (pokud vůbec viz. obrázek). Jen bych rád, aby to fungovalo jako v 2.3.x, což teď není. Rád pomohu s hledáním té chyby, jen nevím, kde začít.


Ano, napriec verziami to bolo rozne a tak isto to bolo uplne ine medzi 242.5 a 242.6.

"Komplikujem" to z jedneho dovodu. Skus pouvazovat, naco ti je prakticky uctovne hladisko? Budes snad uctovat saldo transakcii, ktore budu zauctovane a to saldo sa bude este menit? Nebudes. Nema to zmysel. Ta hodnota je tam iba informacna.

Ze tam mam planovany prijem 10 a planovany vydaj 10, znamena, ze celkovo je tam 0. K comu mi je informacia, ze mam transakcie v hodnote 0??? K nicomu.

A teraz zacni uvazovat prakticky - z praxe:

- chces vediet, ci mozes z uctu uvolnit urcite prostriedky v blizkej dobe. Vies kolko mas na ucte a vidis, ze planovane vydaje maju urcitu hodnotu. S touto hodnotou mozes uz narabat pri vypoctoch, kolko penazi mozes uvolnit. Planovane prijmy sa nemusia predikovat presne, lebo nemusia nastat vobec, alebo nie v danej vyske, ci v dane obdobie.

Takze prakticky dolezita hodnota je, kolko vydajov tam mas v plane na uhrady, ako to, ze bilancia je 0. Uved prakticky priklad vyuzitia bilancie prijmov, vydajov a prevodov pri planovanych platbach.... Mozno taky mas a budem rad, ak sa dozviem, ake je jeho prakticke vyuzitie.

Prave preto som navrhoval zmenu, ze to uctovno-matematicke hladisko je imho len zbytocnost, zatial co nejake sumare samostatne pre prijmy, vydaje, ci prevody, maju prakticke vyuzitie.

Je na Slavikovi, aby si zvazil, ci to chce takouto informacnou hodnotou vylepsit, alebo ma ine priority a necha to tak ako to je, kedze selektivne sa da k tym udajom dostat. Ale nic to nemeni na tom, ze sumar sumarov planovanych prijmov, vydajov a transferov je miesanie hrusiek, jablk a sliviek.