On Mon, 4 Feb 2019 11:19:24 -0600 (CST)
DGPickett via gnucash-user wrote:
> 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 reco
Sorry, newest not oldest!
-Original Message-
From: Dale Alspach
To: David G. Pickett
Cc: geert.gnucash ; Gnucash Users
Sent: Mon, Feb 4, 2019 3:37 pm
Subject: Re: [GNC] Smarter dating of account reconcile
> 1) oldest transaction 2) not in the future 3) n set to c or y.The old
On Mon, Feb 4, 2019 at 1:22 PM David G. Pickett via gnucash-user <
gnucash-user@gnucash.org> wrote:
> 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 include
t 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
> To: gnucash-user ; DGPickett
> Sent: Mon, Fe
-
From: Geert Janssens
To: gnucash-user ; DGPickett
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
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 reconc
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?
--
Sent from: http://gnu
