[GNC] How can I add statement balances to my accounts as checks?

Wed Oct 2 07:06:26 EDT 2019

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 <armanschwarz at 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 at 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 <edodd at billiau.net> wrote:
> >
> > On Wed, 2 Oct 2019 16:19:10 +1000
> > Arman Schwarz <armanschwarz at 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 at 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 at 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 at 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.
>