[GNC-dev] About 3.9 and reconciliation balances

[Derek Atkins]

Hi,

On Tue, April 7, 2020 10:21 am, Dale Phurrough via gnucash-devel wrote:

> 1.
> This time period of one month is arbitrary and my experience suggests this
> is a symptom of a hack, incomplete solution, or partial workaround. Both
> (a) allowing future/advance reconciliation -and- (b) disallowing something
> "too far ahead" is again arbitrary and is forcing an arbitrary accounting
> policy rather than conservative double-book rules and math.
> Features with rules which are defined by the computer clock
> are troublesome. It makes sense when one needs to transfer money via an
> online API. It doesn't make sense when one is doing core accounting tasks.
> Also this seems (in my shallow understanding of the 3.9 change) to not
> work
> with that 3.9 change. How could someone future reconcile if future-date
> splits wouldn't be valid with respect to the future-target-reconcile
> balance? This suggests a cascade of more workarounds.

I will comment on this, because this came directly from a conversation
that Chris and I had.  Chris originally wanted to ensure that reconciles
could never happen in the future *at all*.  I.e., it would not allow you
to future-reconcile.

I said that I do often future-reconcile.  My use-case is that I keep track
of my reimbursable expenses using cleared/reconciled flags to denote that
I expensed them (cleared), and the expense was reimburned (reconciled). 
So when I file my expense report I mark those items as cleared.  Then when
the reimbursement check comes in, I reconcile down to $0.  My issue is
that I want to do this (enter the reimbursement check and reconcile) on
the day I receive the check, however the check only gets deposited the
next day, so I need to be able to reconcile 1-2 days into the future.

When I proposed this use-case to Chris, he suggested a month leeway, and I
didn't push back saying "that is too much."

If you have an ACTUAL use-case of future-reconciling I would like to hear
it, because this is the only future-reconcile use case I have come across.
 Everything else in my experience is reconciling in the past.

> 2.
> I highly discourage altering any data without explicit disclosure and
> acceptance of each change occurrence. This is not in alignment with the
> ideas of data integrity, data persistence, trust and disclosure, etc.
> Also a similar arbitrary accounting policy with the suggested date>1month
> logic and 1/1/1970.

GnuCash already has several places where is will correct (read: alter)
data entries on the fly, when it Scrubs the accounts.  It does this with
bad strings and invalid dates, among other corrections.  It will already
do these corrections silently when the data file is loaded.  Having said
that, it probably still makes sense to pop up a dialog to warn the user if
it finds this kind of "invalid" data.

> --Dale

-derek
-- 
       Derek Atkins                 617-623-3745
       derek at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant