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.
