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

Wed Oct 2 07:22:21 EDT 2019

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.lck at 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 <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.
>>
>