Irritating

[Terry Boldt]

On Tuesday 06 May 2003 20:23, Derek Atkins wrote:
> Terry Boldt <tboldt at attglobal.net> writes:
> > I have now been using gnucash 1.6.8 on RH 8.0 for several months and have
> > two idiosyncacies that are really irritating. I don't know if the newer
> > gnucash "fixes" these problems or not. I have been relunctant to upgrade
> > due to trouble I had in getting 1.6.8 to compile and do not know what
> > libraries will have to change if I try the newer version.
>
> If you can compile 1.6, then you can compile 1.8.  The _ONLY_ changed
> dependency is g-wrap; you need g-wrap-1.3.4 for gnucash-1.8, whereas
> you need g-wrap-1.2.x or 1.1.11 for gnucash-1.6.  Other than that, there
> are no new dependencies.
>
> All my answers below are with respect to 1.8.  You should upgrade.

I'll try

>
> > Anyway, the two things that I find really irritating after some use:
> >
> > 1. in reconciling an account, I open the reconcile dialog and expect the
> > current date or at least some reasonable date to be the default. What I
> > find is that the date that the dialog defaults to seems to be choosen
> > totally at random. sometimes it is anywhere from today's date to a month
> > in the future. Sometimes just the reverse, up to a month in the past. I
> > recently reconciled one account and the date posted when the dialog
> > opened was 3 months in the past. This is irritating because then not only
> > the date must be changed, but also the balance figure. I have tried to
> > determine whether there is a pattern to the date choosen and have been
> > unable to discern a pattern. It appears the date is choosen totally at
> > random. Instead of trying to get really intelligent in choosing the date,
> > why not just use the current date? If I'm reconciling an account, I
> > rarely, if ever, reconcile an account for sometime in the futre or for a
> > date 3 months in the past. 99% of the time it is for today's balance from
> > the statement I just downloaded from the financial institution.
>
> I know that this has been worked on..  The reconcile dialog tries to
> choose a reasonable reconciliation date based on the last two
> reconciliation dates.  It basically intuits the reconciliation
> interval and then defaults to that.  So, if you always reconcile at
> the end of the month, after two months it should always "guess" the
> end of the month, one month at a time.
>
> Note that reconciliation is supposed to be for PRINTED,
> end-of-the-month statements.  It is _NOT_ supposed to be a "this is
> what the bank says today" process.  If you're just looking at your
> list of transactions from your financial institution, you're obtaining
> the list of cleared transactions.  That is NOT reconciliation.  If you
> want to mark the transactions that have cleared your finanacial
> institution, you should 'clear' the transactions in the register
> window by clicking on the RECN column and change the 'n' to a 'c'.

I'll consider myself strictly repimanded for not following strict gnucash or 
accounting practices. Meanwhile I will continue do that which I find most 
sensible, as I am sure most consumers who are non-accountants will do, i.e., 
follow that methodology which best suits their way of doing things. I have 
found the humans are good at that and really, really resist having to change 
their habits or practices to follow that of some s/w written by somebody that 
knows very little about their lifestyle.

Yes, the financial institutions are very fond of saying that the online 
information "may not be" the same as the printed end-of-month statements.

Meanwhile they are trying hard to get me to accept e-statements and forego the 
printed monthly statements. That leads me to believe they really and truely 
consider the online information as accurate as their printed statements 
(which by the way are derived from the same database as the online 
information (or a daily replication thereof, or more likely, judging by how 
fast ATM transactions get posted online, hourly replication)). 

As for waiting for the monthly statement to reconcile - I like to use the 
computer and internet to reduce my workload not just to change it and 
maintain it at the same level. At an average daily transaction load of say 4 
transactions/day, at the end of 30 days, I have to track through at least 1/2 
of those, or 60 transactions (if I'm lucky and not the full 120) to find the 
usual entry error (which by the way gnucash does _NOT_ eliminate - as I have 
maintained before, gnucash is _NOT_ double-entry, double-posting, but not 
double-entry. I enter each transaction exactly once and once only, gnucash 
then replicates my entry error in double-posting - I know I am kicking a dead 
horse here since double-entry is too deeply rooted in the gnucash developers 
psyche to let go). I read an article once, several years ago, where they 
interviewed an executive at Intuit. The executive said that they do not sell 
Quicken to accountants as a double entry system, since they found that 
accountants who have used true double entry systems absolutely 
hate/detest/abhore the system for the double work they have to perform to do 
"true" double-entry (this, of course, is not something they readily admit to 
- Intuit only found out by digging deeper as to why they had so much trouble 
selling to accountants).  They love the way it catches entry errors, but they 
would not invest in a "true" double-entry system on a computer.

If, however, I follow my (more sensible to me) practice of checking the 
account information online every 1, 2 or 3 days, I then have 2, 4 or 6 
transactions through which I will usually have to track down the entry error.

At one time I used your practice of "checking off" the transactions and 
reconciling later. Again, this lead to double the work with no benefit. 
Changed the process and gave me more work - not what I consider the ideal 
argument for using a computer in the first place.

No, I will continue my process of reconciling every 3 or 4 days and consider 
myself duly and truely reprimanded for my truely horrible non-accountant and 
non-gnucash ways.

I'l still wish that gnucash would stop trying to impose somebody else's view 
of the world on me and just accept my own view and use the current date as 
the default date in the reconcile dialog. Hint - maybe you could make this a 
choice in one of the "preference" tabs.


>
> > 2. When creating a new transaction in the register window of an account,
> > the auto-complete function will complete the "description" field,
> > normally the first field (after the date field if not for today) that I
> > complete. This is great, but then the auto-complete function goes even
> > further. As soon as I change to another field for the new transaction,
> > the auto-complete function picks a transaction from the past in the
> > register and completes the remaining fields. Again I have been unable to
> > determine which past transaction is duplicated. sometimes it is the last
> > transaction for the particular matching for the "description" field,
> > sometimes it skips back a few transactions for that "description" and
> > picks a transaction. Sometimes it doesn't complete the
>
> This has been fixed; it should complete the most recent transaction
> that matches the description.

By "should" I take it to mean that it "does". Right?

>
> > transaction at all. Sometimes it will swap the amounts in the deposits
> > and withdrawl column (for a checking account for example), i.e., it will
> > take the amount in the deposit column and put it into the withdrawl
> > column and vice versa.  I assume that the assumption being that the next
> > transaction is supposed to "pay-off" the prior transaction. This action
> > again seems to be random. The action in completing the transaction would
> > be great if all of my transactions for all transactions for a given
> > "description" field were the same (e.g., monthly mortgage payments,
> > etc.), but this is not the case. They are all unique. Invariably my
> > "work" in creating the transaction is doubled, because I must now change
> > all of the fields automatically created. I have looked in vain through
> > the preferences dialogs for a way to turn this feature off (and retain
> > the ability to complete fields based on my input). If the ability to turn
> > off this feature is there, it is well hidden from my view.
>
> I do not believe that you cannot turn off autocompletion.

The double negative means that I can - yes??? 

How? any hints would be appreciated.

>
> > Again, if these "features" have been changed/fixed in the lastest
> > version, accept my apologiers for raising the issue here.
>
> Accepted.
>
> > Another question, does anybody have experience in compiling the latest
> > stable version under RH 8.0 and which libraries/packages need to be
> > updated? If so, please update the mailing list so that I can attempt the
> > update.
>
> Um, there are pre-compiled RPMs already available for RH8.  You can
> find them at http://www.gnucash.org/pub/ As I implied earlier, you
> will need not only the Gnucash RPM but also an updated g-wrap RPM.
> Make sure you pull down the RH8 RPMs.

I had to stop using RPMs. RPM on my system is really badly broken - it 
considers its own database corrupted in some manner. All attempts by both 
myself and the vendor's experts have failed to "uncorrupt" or rebuild the 
database. Even before this I have found RPM to be a rather "fragile" system 
for upgrading application s/w.

Thanks for a really good accounting package. What I say here is not meant as 
criticism - just my way of feedback to improve gnucash.


>
> -derek