FWIW I do think it's a nice feature to have. It's not terribly difficult to implement either. Allow user to add a special entry with some metadata stating the balance should be X dollars, and if the user tries to input a transaction which will fail the balance assertion, pops a warning "Error - this transaction cannot be entered because it will invalidate balance on d/m/y which should be $amount.".
As always the devil is in the details: this will be a brand-new error condition that only triggers upon user input. Should this trigger when user imports transactions via CSV/OFX/QIF? What about with custom scripts whereby a book has been modified but the balance assertions are no longer valid? What about a book modified externally whereby the assertions now fail? Should GnuCash fail to open the book because it's now "invalid"? Should there be a framework/central mechanism to capture all these sanity checks? It's really difficult. Software development is hard. For that matter I don't think any current developer has found this issue particularly high priority, so, it has never been done. On Wed, 2 Oct 2019 at 10:41, Arman Schwarz <armanschw...@gmail.com> wrote: > 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. > _______________________________________________ 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.
