[GNC] Smarter dating of account reconcile

David G. Pickett dgpickett at aol.com
Mon Feb 4 14:20:12 EST 2019


 The statement date is also in the past, so the default date is pretty much never right.  In a busy account, my date would match.  While the statement date might be later than the last included transaction, there is no value in the later date, since no transactions exist in the intervening time span.

I date my checking transactions to the check date, not the clearing date, as that is the earliest date for the life of that check.

I guess you are presenting some sort of CPA religion argument on dates in books, accounts.  I just want fewer motions in the process. 
 
-----Original Message-----
From: Geert Janssens <geert.gnucash at kobaltwit.be>
To: gnucash-user <gnucash-user at gnucash.org>; DGPickett <dgpickett at aol.com>
Sent: Mon, Feb 4, 2019 12:52 pm
Subject: Re: [GNC] Smarter dating of account reconcile

Op maandag 4 februari 2019 18:19:24 CET schreef DGPickett via gnucash-user:
> It's be smart if, when I hit the reconcile button, it selected the date of
> the 1) oldest transaction 2) not in the future 3) n set to c or y.  After
> all, one cannot hope to reconcile the future, and why set the reconcile date
> any later than the last included transaction?

Why? Because reconciling normally happens against a bank statement and the 
reconcile date should be the bank statement's date which is not necessarily 
the date of the last included transaction.

The current algorithm will calculate the number of days between the last and 
second to last reconcile and will project that period to guess the next 
statement date (and this logic has a couple of flaws so even this doesn't work 
reliably). This of course assumes bank statements are provided at regular 
intervals. That may be a completely flawed assumption, but now at least you 
know how it currently works.

Geert




More information about the gnucash-user mailing list