Hi,
armanschwarz <armanschw...@gmail.com> writes:
> The problem is that the current process only checks an error once. Coming
> back to my July 2019/2010 example, if I mistake 2019 for 2010 and don't
> catch it at reconciliation (not because I'm not careful, but because, as you
> say, we're all fallible), then future reconciliations won't catch this,
> despite almost a decade of balances being now incorrect.
You are correct, you need to make the mistake twice.
I'll also note that GnuCash does have a feature that will prevent you
from entering transactions too far in the past. So if you set this
feature, GnuCash will prevent you from entering a transaction dated 2010
while we're here in 2019.
> Supposing that GnuCash had instead kept the balance value I gave it during
> reconciliation, then I would suddenly see 10 years worth of balance
> assertions being triggered. If I make a mistake inputting a balance
> assertion, I'd notice immediately because it would be incongruent with the
> transactions. Even if I make a mistake and accidentally input an incorrect
> transaction _and_ incorrect balance assertion such that the assertion
> matched the incorrect balance, it would still be caught during the next
> reconciliation as the incorrect transactions would throw off the future
> balance assertions (whereas the reconciliation will never catch this as the
> transactions are already reconciled).
I'm not sure exactly how this would happen. I think it would be very
expensive to run this check every time a new transaction is entered. I
think the "better" approach would be to just remember the most recent
reconcile date for an account and warn if a transaction tries to use a
date prior to that date.
This is very similar to the existing feature.
> I hope I've made this point but I'll reiterate it; this isn't just an extra
> check. The current reconciliation requires that the user makes the same
> mistake no more than twice, otherwise you end up with a permanent error.
> Balance assertions don't have this defect.
Sure they do. Users can ignore warning boxes.
There are other ways to break the "balance assertions", too. A user
could go back and change the balance of a reconciled transaction. This
would be even HARDER to detect!
> The system is more robust against error and doesn't permit drift in accuracy
> over time the way Reconciliation does.
I wouldn't say it "doesn't permit drift". I would say it's another
tool, albeit an expensive tool as you've described it.
> The salt in the wound here is that this data is literally given to GnuCash
> at reconciliation, it just discards it.
Patches always welcome! :)
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
-derek
--
Derek Atkins 617-623-3745
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
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.
