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

Wed Oct 2 07:31:12 EDT 2019

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