[GNC] Smarter dating of account reconcile

[Dale Alspach]

> 1) oldest transaction 2) not in the future 3) n set to c or y.
The oldest transaction would presumably be the first transaction in the
account so I assume you mean the most recent transaction.
If someone does not frequently mark transactions c or y, the date you are
advocating could be as early as the previous reconcile date. Think of
someone who examines the transactions only when a new statement is received.
In my case what you are advocating would almost always be wrong. Currently
the software usually suggests the same day of the next month after the
previous reconcile. That is often the correct statement date for my
accounts.

Dale

On Mon, Feb 4, 2019 at 1:23 PM David G. Pickett via gnucash-user <
gnucash-user at 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 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
>
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>