There is another scenario where the 'balance assertion' could be useful. I sometimes import credit card transactions that accidentally include payments erroneously credited from the wrong bank account. Then I wonder why the bank account is suddenly out of balance.
I have been entering zero-valued transactions for years to accomplish the 'balance assertion' function, usually on the statement dates for some asset or credit card accounts. On Wed, Oct 2, 2019 at 6:32 AM Arman Schwarz <armanschw...@gmail.com> wrote: > Another complimentary feature might be to restrict the date range of > reconciliations - if I'm reconciling a July 2019 statement against my > accounts, why should I be given the option of using a July 1010 transaction > to reconcile against? Maybe I should be able to specify the date range of > the statemetn I'm reconciling against? > > On Wed, 2 Oct 2019 at 21:22, Arman Schwarz <armanschw...@gmail.com> wrote: > > > All the issues I've highlighted really boil down to inserting > transactions > > before already reconciled ones, so if we could prevent that it might make > > my concern moot. > > > > So perhaps an easier route from a software design perspective would be > > just adding a warn dialog whenever you try to insert a transaction that > > comes before any reconciled transactions. You could also warn if the user > > tries to perform a reconciliation that leaves reonciled transactions > > _after_ unreconciled transactions. > > > > If you try to insert a transaction before a reconciled transaction, valid > > responses could be; > > 1) Go ahead anyway > > 2) Go ahead, but un-reconcile all transactions after the inserted > > transaction > > 3) Cancel, never warn again, etc. > > > > Actually before I emberass myself here - does this already exist? > > > > On Wed, 2 Oct 2019 at 21:06, Christopher Lam <christopher....@gmail.com> > > wrote: > > > >> 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. > -- David Carlson _______________________________________________ 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.
