Verzia 3.0 (Page 2 of 5)

Ahoj, OK.
Ešte jedna vec. Pri zadávaní Partnera (Payee) mi neumožňuje nechať prázdnu možnosť, musím len vybrať z už zadaných. Ja prázdnu možnosť využívam, najmä napríklad u drobných obchodíkov, stánkov, suvenírov, a pod., kde ma partner netrápi. Udržujem si tak zoznam patnerov v rozumnej veľkosti, aby som nemusel rolovať alebo vyhľadávať v niekoľkých stovkách záznamov.

Slavik zveřejnil podrobný návod, já jsem ho předtím bohužel nepochopil. Podle zveřejněného návodu TRANSFER a všechny související věci fungují bez jediného problému. Takto by to mohlo být a skoro je mi líto, kdyby to měl Slavik předělávat. Je to také jednoduché a funkční. Myslím, že se další k tomu také vyjádří a uvidíme jestli je opravdu nutné to celé překopávat.

Dobrý deň,
plánujem urobiť import dát z verzie 2.x do 3.x, keď bude funkčný základ programu.

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

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?

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.
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.

Ahoj Slavomír,
Otestoval som BETA 4 pôvodné pripomienky a objavil aj pár nových, ktoré mi minule unikli.

1. Vizualizácia
a) Popisy nad poliami  - už sú OK.
b) Možnosť nastavenia farebného odlíšenia debetov podľa preferencie (červeným len sumy alebo celé riadky) -  Fajn.
c) Chápem, že na kraji sú farebné guličky na odlíšenie typu transakcií, ale trošku mi chýba označenie aj sumy inou farbou pre TRANSFERe. Vo verzii 2.x bola zelená a šedá (kredity boli modrou). Pri pohľade na dlhý zoznam transakcií som ihneď vedel, že síce zelené a šedé čísla sú síce väčšie, ale sú to transféry (naše disponibilné peniaze a nie napr. výdavky). Neviem, aký pocit majú ostatní používatelia.
d) Zoznam transakcií sa zatiaľ nedá zoradiť podľa žiadneho stĺpca (podľa popisu, kategórie, sumy,...). Predpokladám, že to formálne pribudne vo finálnejších verziách programu.

2. Kategórie transakcií
Tu mám väčší problém stotožniť sa (až dnes som si to všimol :-) Neviem, či je to len zatiaľ nesprístupnené, alebo zámer.
a) Tabuľka kategórií a podkategórií je spoločná pre všetky typy transakcií (+ aj -).
Toto ma celkom vyrušuje pri práci. Či zadávam debet alebo kredit, stále sa mi vyrolujú všetky dostupné kategórie a miešajú sa mi tak dohromady ich názvy. Musím dávať veľký pozor, či dobre vyberám kategóriu pre kredit alebo debet.
Vo verziách 2.x boli kategórie oddelené pre debetné položky a pre kreditné. (druhy +, -, m, p) Čiže keď som zadával kredit/príjem, vyrolovali sa mi z kombo-boxu IBA kategórie pre kredity. Pre zadávanie debetu/výdavku to isté, IBA kategórie pre debety. Jednoduché, prehľadné, nezameniteľné.

Neviem, prečo sa to takto zmenilo. Zatiaľ mi napadajú iba 2 dôvody
i) Buď to predstavuje nejaké zjednodušenie pre programovanie funkčnosti a výberu
ii) alebo to je kvôli presnejšej sumarizácii výdavkov podľa kategórií. (Skúsim príklad: Urobím nákup v potravinách za 100 € kartou. Z toho nejaké položky za 20€ som kúpil pre svokru, ktorá mi tých 20 € vráti v hotovosti. Ak si jej +20 € dám ako príjem s kreditnou kategóriou napr. PREVODY OD INÝCH alebo VRÁTENÉ OD INÝYCH, tak v sumarizácii výdavkov za POTRAVINY budem mať -100 €, čo nie je pravda. Ale ak zadám debet -100 € ako POTRAVINY a kredit od svokry +20 € tiež s kategóriou POTRAVINY, tak v celkovej sumarizácii budem mať  stav za potraviny -80 €, čo je reálnejšie. Alebo sa mýlim?

Takýchto situácií mám niekoľko, ale je ich málo a sú to relatívne zanedbateľné hodnoty v sumáre oproti výdavkom mojej rodiny v danej kategórii. Mne osobne práca so zmiešanými kategóriami za nepatrné spresnenie hodnoty celkových výdavkov na kategóriu nestojí. Neviem, ako ostatní. Môžu mať iný názor.

b) Nutnosť manuálneho zadania kategórie pri TRANSFERi.
Úplne ma mätie, keď musím manuálne zadávať pri TRANSFERi aj kategóriu! 
Vo verzii 2.x boli automaticky v tabuľke kategórií na konci tabuľky aj  TRANSFER+ (druh pohybu p) a TRANSFER- (pohyb pohybu m). Pri zadaní transferu program automatizovane priradil tieto 2 kategórie (predtým ako druhy "p" a "m") k obom záznamom, čo považujem za absolútne správne. Pri TRENSFERI by mi program nemal dovoliť zadať žiadnu inú kategóriu pohybu (kreditnú, ani debetnú). Nie je to výdavok, ani príjem, je to len presun peňazí z účtu na účet.

Predpokladám, že to je len neduh základnej BETA verzie

3. TRANSFER ako taký.

Áno. Super. Rôzne účty, logické. Rôzne dátumy, OK (používam vždy 1 dátum, nech sú zápisy spolu. Ale áno, z jednej banky odíde a do druhej príde o 1-2 dni). Ale suma? Opakujem sa ako otravný verklík, ale suma sa podľa mňa musí tiež preberať. Neviem si predstaviť situáciu, kde niečo odošlem a príde mi na druhej strane iná suma (prevod z účtu na účet, výber hotovosti z bankomatu,... ).
To už skôr si viem predstaviť rôznych partnerov (Prevod TRANSFER z účtu SLSP na účet MBANK, ale OK, môžem teoreticky zadať debetného partnera SLSP a kreditného MBANK, hoci je to v účtoch. Ja osobne zadávam iniciátora transferu, t.j. SLSP)

Plus časť 2.b)

4. Test importu databázy v2.4.3
Prvotný import zlyhal kvôli šifrovanej databáze. (Error message: TSQLite3Connection:file is encrypted or is not a database / Error class: ESQLDatabaseError / Unit name: SQLDB)
Nešifrovanú databázu naimportoval BEZ CHÝB (databáza so 17600 transakciami, 113 kategóriami, 108 partnerov, 40 účtami)

Pri tlači reportu bude tiež fajn, keď debetné čísla s "-" budú červeným.
Načítalo správne aj stavy účtov (aktívny, pasívny, archívny) s farebným odlíšením.
Len vo filtroch stále figurujú pri výbere všetky účty. Tj. aj archívne a pasívne (v 2.x verzii ich nevidím vo výbere, čo je OK). Predpokladám, že to tak bude aj vo finálnejšej verzii
Sumarizácie a stavy na nejakých účtoch za vybrané obdobie zatiaľ sedia s tým istým výberom s verziou 2.4.3

Zatiaľ toľko.

Zdravím....

import databázy z 2.4.3 prebehol bez problémov, ale neimportovali sa plánované platby "plánovač" a tým pádom zápis plánovaných platieb a kalendár, prvý dojem je fajn, transfer je len o jeden klik viac a dá sa na to zvyknúť.....po zatvorení databázy a znovuotvorení nezostanú zapnuté filtre mesiac, rok, atď, chýbajú mi polia sumarizácia a graf a tie štatistické veci ale to asi bude..... možno napíšem niekedy aj nejakú blbosť pretože neviem úplne v akom stave rozpracovanosti to je......tak mi to prepáčte, ale chcem nejak prispieť...a posledný postreh.....free by som V3  nenechal, je to kopec roboty......ešte sa vrátim k verzii 2.4.3....keby sa dalo nejako opraviť to zálohovanie databázy, ktoré nefunguje, kvôli nevygenerovaniu lic. kľúča po 2000 t....stále sa neviem zmieriť , že som si nemohol zaplatiť aby som mal plne funkčnú verziu RqMoney ....a možno túto starú verziu nechať free plne funkčnú.....nech sa darí

Viem to doplniť, chce to len čas (v prvom rade sa snažím, aby bol program funkčne v poriadku. Grafika ako taká je až na druhom či treťom mieste, i keď viem, že je potrebná. Uvidím, ako to budem stíhať.

Áno, prioritná bola práca s transakciami (pridávanie, oprava, mazanie, kopírovanie, tlač, zobrazenie všetkých údajov správne - aj po importe). Mám v pláne aj radenie stĺpcov, ale až keď bude program OK. Neviem urobiť všetko naraz.

Je to zámer autora. Viem, že viacerí užívatelia budú možno v pomykove, lebo boli zvyknutí na triedenie podkategórií na + a - .
Máš pravdu v tom, že teraz musíš rolovať všetky kategórie a podkategórie pri zadaní príjmu, výdaju či presunu. Vieš sa však rýchlo dostať zadaním prvého písmena k svojej kategórii. Toto viem ale doladiť aj neskôr.
Zrušenie rozdelených kategórií na + a - je kvôli sprehľadneniu a zmene filozofie - uviedol som už predtým, že podkategórie teraz po novom môžu aj nemusia byť, takže užívateľ môže fungovať len na kategóriách (ak nechce ísť do hĺbky evidencie).
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.
Ale ak Ti to nevyhovuje, stále máš možnosť si vytvárať plusové a mínusové kategórie s podkategóriami.:)

Ak máš kategórie s rovnakým názvom pre príjem aj pre výdaj, myslím, že je najvyšší čas ich pomocou hromadnej opravy zreorganizovať. Systém kategórií sa zjednodušil pre užívateľa (má väčšie možnosti variability - čo som vysvetlil vyššie). Na triedenie záznamov podľa príjmu či výdaju máš predsa filter pohybu.

Nie je to neduh . Máš pravdu, že v predošlej verzii bol presun vždy v kategórii TRANSFER (a v príslušnej podkategórii). Nová verzia Ti ponúka väčšiu variabilitu, lebo si môžeš k presunom dávať rôzne kategórie (čo Ti asi nedáva teraz zmysel). Ale ako typ presun naďalej zostáva presunom a môžeš si ho vo filtri kedykoľvek vyfiltrovať. Nič Ti nebráni naďalej používať kategóriu TRANSFER pre presun (len ho zatiaľ treba ručne zadávať). Môžem neskôr doplniť automatické ponúknutie nejakej kategórie pri presune (chce to však čas).

Sú užívatelia (včítane mňa), ktorý používajú dva účty a každý v inej mene. V takom prípade ak prevádzaš z jednej banky (účet napr. v EUR) do druhej banky (účet napr. v CZK), dôjde tam nielen k posunu v dátume, ale aj k rozdielnej sume (vplyvom kurzu, pretože 100 EUR <> 100 CZK).

Šifrovanie databázy som nestihol ošetriť, viac som sa sústredil na bezchybný import (čo sa mi, dúfam, podarilo). Dopracujem.

Dopracujem.

Pre mňa dôležitá informácia, ďakujem. Môžem sa tým pádom venovať iným častiam programu (ktoré som uviedol, že dopracujem).

Musím Ťa upozorniť (a ostatných užívateľov testovacej verzie 3.x), že stále sa jedná skôr o koncept ako o funkčný program. Absolútne neodporúčam viesť si vo verzii 3.x ostré údaje. Určite sa ešte bude meniť štruktúra databázy (ako budem dolaďovať moduly ako plánovač, rozpočet či reporty). Takže by potom museli znovu nahrávať všetko nanovo (iné importy ako z verzie 2.x určite nebudú!).

Takže ešte je skoro reorganizovať kategórie či iné zoznamy vo verzii 3.x. Naďalej odporúčam pracovať vo verzii 2.x.
Zopakujem - verzia 3.x je TESTOVACIA !!!

Jasnačka. Testujem na "testovacích" kópiách ostrej databázy 2.4.3, importovanej do 3.0.
Ostré výdavky pokračujem v 2.4.3. Ale aj tam už mierne reorganizujem a čistím kategórie a iné. O to menej budem mať práce po ostrom prechode na stabilnú v3.0

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.