Sorry, newest not oldest! -----Original Message----- From: Dale Alspach <alspac...@gmail.com> To: David G. Pickett <dgpick...@aol.com> Cc: geert.gnucash <geert.gnuc...@kobaltwit.be>; Gnucash Users <gnucash-user@gnucash.org> 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 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@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.gnuc...@kobaltwit.be> To: gnucash-user <gnucash-user@gnucash.org>; DGPickett <dgpick...@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@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. _______________________________________________ gnucash-user mailing list gnucash-user@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.
