Sorry for the wordy reply. The TLDR; I think we're on the same page that Balance Assertions are a "nice to have" but I feel I haven't really articulated the scenario/s that I think make this feature quite important, hence why I'm replying again.
> For example, if I enter a > transaction from July 10, 2019 with the incorrect date of July 10, > 2010, This has actually happened to me before, where I'm backfilling some statements and I get the years mixed up, but you could imagine it might happen also if I'm punching in years on a number pad and write the wrong value, or if the user is prone to mixing up numbers (also very common). Now imagine that at the time of this error reconciliation has been done for all months up to June 2019. 9 years worth of balances are now wrong, and GnuCash will quite happily ignore the fact that I've told it on multiple occassions what the balances should be at various dates (hence the missing feature of balance assertions that you should "get for free" with every reconciliation should you want it). I think the premise of your responses is that I should now do a reconciliation to find this issue. > WHY would you ‘clear’ a 9 year old transaction erroneously it it doesn’t appear on *this month’s* statement? (Remember that the transaction will appear on my reconciliation as well as my statement, it's just that the date will be wrong, but I'll try to respond to the core of the question - why would I sign off on something that's wrong?) Firstly I'd say that I shouldn't have to, as GnuCash has at this point been given all the information it would need to point out to the user that there is a discrepency (via the many statement balances I would have given it to do the reconciliations up to this point). Secondly, most of the time I think you're right in that I would catch this issue in a reconciliation but I might not becuse: - Many human errors are not random, but symptomatic of a cognitive bias. For example, I might mix up 9s and 0s, causing me to type "2010" instead of "2019". This would make me prone to missing this problem in reconiliation, or - I might be in a rush or might only check the balances. I might just _happen_ not to check the year because I've been staring at dates all day and I'm starting to get a bit frazzled. Remember, I've already made the mistake by inputting the data incorrectly. There's a good chance I'm confused about the dates at this point, so the likelihood I'm going to stuff it up at reconciliation is larger than it would be for other transactions. In the above example I got the balance, day and month right, so there's literally only a single digit off! But the worst part about this scenario is that there is no mechanism to catch this down the road. If I make a mistake on the date in reconciliation, that's it, it's there forever. Future balances will be correct because only the date is wrong, and I'm now stuck with this mistake forever, and can't know about it even though I've _told_ GnuCash the info it needs to find the mistake. It seems like there are several workarounds that reduce the likelihood of this happening, such as exercising more diligence as Adrien points out, or the various autocompletion features Liz mentioned. David's point about the order of entries might also help. But all of these seem to only partially reduce the likelihood of errors creeping in that really shouldn't be allowed to exist in the first place. I think as a software design philosophy the software really should be making it as easy as possible to get it right. I don't dispute that we should be diligent when reconciling values, but I think it's not ideal that the normal workflow could result in permanent errors from a single mistake (well, two mistakes I suppose, since you'd need to reconcile incorrectly, but it's not out of the question as I've illustrated). So it really wasn't my intention to come off as cynical, and I hope I haven't done that - I'm actually hugely impressed by GnuCash and will continue to use it regardless of whether it has balance assertions or note (I'll just build it myself), but I'm hoping that I've succeeded in articulating why I think it's a worthwhile feature (I know Adrien already acknowledged this but I wanted to give a specific scenario). On Wed, 2 Oct 2019 at 19:49, D via gnucash-user <gnucash-user@gnucash.org> wrote: > Moreover, when next you go to reconcile, that entry for 2010 will display > up at the very top of the reconcile window, and one might wonder at that, > see the incorrect date and fix it. > > [Technically, Gnucash doesn't store the reconciled amount, it calculates > it at each reconcile for all transactions with the reconcile flag set.] > > David > > On October 2, 2019, at 10:17 AM, Liz <ed...@billiau.net> wrote: > > On Wed, 2 Oct 2019 16:19:10 +1000 > Arman Schwarz <armanschw...@gmail.com> wrote: > > > For example, if I enter a > > transaction from July 10, 2019 with the incorrect date of July 10, > > 2010, > > > That is actually harder than you think. > If you do not specify a date, you get today's date. > If you specify a number for the number of the day in the month you get > this month in this year (put in 2 and get 2nd October 2019 > If you specify a number for the day, and a number for the month, you > get this year. > > So the lazy entering of incomplete dates pulls you to the correct year. > (I know this can be changed in preferences, somewhere). > > > Nextly, the system does know the last balance at reconciliation. It > pulls that value in for the next reconciliation. > > You can certainly type in transactions with no value, just a > description, and in that description put "Confirmed balance $123.45" > > Liz > _______________________________________________ > 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. > _______________________________________________ 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.
