[GNC-dev] About 3.9 and reconciliation balances

[Dale Phurrough]

Hi. I do have feedback on the 3.10 change suggestions. Meanwhile, I'll not
comment on the feature change "3.9 comes with a new method for calculating
reconciliation starting balances". I defer to others on this list for that.

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.

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.

--Dale

On Tue, Apr 7, 2020 at 9:32 AM Christopher Lam <christopher.lck at gmail.com>
wrote:

> Release 3.9 comes with a new method for calculating reconciliation starting
> balances.
>
> Previously, the account reconciled balance was considered the starting
> balance. This includes any splits previously reconciled with an invalid
> (e.g. future) reconciliation statement date.
>
> From 3.9 onwards, the starting balance is calculated by adding all account
> splits whose *previous *reconciled date the *current* reconciliation date.
> This means any past reconciliation with an invalid (ie future) reconciled
> date would be ignored. The benefit is to allow re-reconciliation of a past
> statement.
>
> So, anyone with difficulties reconciling an account with 3.9 onwards should
> check the account Reconciliation Report, Start Date = today, End Date =
> 31/12/9999 to seek these splits. To fix it manually, you can unreconcile
> them and re-reconcile with any past date or today. Or modify the XML/SQL to
> fix these dates.
>
> To prevent future issues there are several safeguards being planned for
> 3.10:
>
> 1. any reconciliation must have a statement date of TODAY + 1MONTH. This
> allows some leeway for users who wish to reconcile in advance, yet
> disallows reconciliation too far ahead.
>
> 2. a datafile with splits with reconciled_date in the future *may *be
> repaired; e.g. if reconciled_date > 1 month from today, then it is
> evidently an error and can be changed to an arbitrary old date eg 1/1/1970.
> This will allow them to be counted when calculating modern reconciled
> balances.
>
> I think 1 is acceptable. Any particular votes for 2?
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>