> On Oct 2, 2019 w40d275, at 5:39 AM, 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).
What ‘balances’ do you suppose are wrong? The previous reconciliations were allegedly correct, else they should not have been completed in the first place. They involved matching paper (or pdf) statements to GnuCash. Either that matching was successful at the time it was done (each month for 9 years) or it wasn’t. Entering a transaction for 2010 in 2019 when it should have been 2019, doesn’t magically make all of those 108 reconciliations somehow flawed or ‘off’. You just end up with an unreconciled transaction dated 9 years ago. Yes, your running balance will be off by that amount, going back 9 years, but you’ll eventually catch this, at the very latest, when you do the next reconciliation and you see it at the top of the window to be cleared. > > I think the premise of your responses is that I should now do a > reconciliation to find this issue. That should catch the error, sure. You might first notice it however looking at the running balance and noticing it doesn’t match what it should at some point in the past. > >> 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?) And you should notice that date is wrong. Checking dates is part of reconciliation. If you aren’t checking dates, you aren’t reconciling correctly. This is now starting to sound like you want the software to take over the manual process of auditing itself against another set of records. That is entirely the point of reconciliation - *manually* verifying the data, meticulously. > > 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). GnuCash can’t presume you really didn’t need to enter that transaction in 2010 and then re-reconcile it. Otherwise, the software would prevent any historical editing. Certainly there is a case for that, and some people would prefer it lock the past, but that isn’t what the devs want for the software. > 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. Software can’t fix you. Only you can fix you. You shouldn’t do the reconciliation till you have time not to rush it. The software won’t explode if you don’t reconcile by a certain date. > > 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. Nope, you’ll see it one day. This has happened to me. (rather, I’ve done this to myself) I caught it when looking over some older transactions and noticed that a cash account went negative at some point. Since that is impossible, I started searching for the error. It took some time, but I was able to spot the transaction and figure out where it belonged. This scenario might not happen quickly, and it might be something else that highlights the error, but you’ll eventually catch it. Note, that this did not happen from entering a present day transaction as something in the past erroneously. I was already entering historical data, thus I had to type in years. Normally, there is no reason to type in years, and with my normal workflow of entering transactions each morning over a cup of joe, at worst, a day or two later, I generally don’t even type any date. I just enter the transaction as the date is already set. I understand you don’t care for the present situation, but how do you imagine this new feature working? What do you want to see happen when you enter a 2010 date in 2019? Where do you think it best to store the asserted balance and how to retrieve it? Regards, Adrien _______________________________________________ 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.
