[GNC-dev] About 3.9 and reconciliation balances

[D.]

Christopher, 

I understand your frustration at trying to help and getting a negative response. In trying to fix one problem, you have unwittingly waded into a bigger one. 

Your message raises a couple of points. First, this rollback need not be forever. It could wait until such time as the reconcile date issues can be more effectively addressed-- for example, by creating an interface to allow users to view or correct them. Your own advice to use the reconciliation report to track down the errors might point a way toward such a solution. 

Second, your changes have made a set of books that were completely functional in earlier versions no longer functional-- all without any changes to the underlying data. I have significant problems with that, and I can't believe that you would even suggest arbitrarily changing data in a user's books without considering ways to allow the user to make those fixes consciously, themselves. 

I've mentioned that you've done this before with the reports; I suggest you reconsider your approach to development of Gnucash tools. Screwing up reconciliation and then looking for a slap dash post hoc fix is not the way to win over users. 

David T.


-------- Original Message --------
From: Christopher Lam <christopher.lck at gmail.com>
Sent: Thu Apr 09 12:55:18 GMT+05:30 2020
Cc: gnucash-devel <gnucash-devel at gnucash.org>
Subject: Re: [GNC-dev] About 3.9 and reconciliation balances

Regarding reverting:

It is too difficult to create a UI to modify reconciled dates. Options to
fix this are:

1. roll back this change and tolerate the invalid data. This means any
progress on that matter is hindered forever.

2. allow this change depending on a user-selectable book property "Use
strict reconcile date balances".
Pros: This means the book can be read/written by any recent version. See
"Use split action for num" as a similar example.
Cons: The toggled property can be a confusing option for new users.

3. allow this change depending on a non-user-selectable book feature "Use
strict reconcile date balances".
Pros: This feature can be set by a menu item. It triggers one-time
verification of all reconciled dates, instructing users to
correct/re-reconcile previous reconciled-dates, and sets the book feature
if all dates seem correct.
Cons: This means the book can only be read by 3.10 onwards.

On Thu, 9 Apr 2020, 11:29 am Christopher Lam, <christopher.lck at gmail.com>
wrote:

> Thank you David.
>
> Further work for tighter safeguards is planned in
> https://github.com/Gnucash/gnucash/pull/685 -- no scrubbing is currently
> on the table but a warning during reconciliation if future splits are
> detected.
>
> On Thu, 9 Apr 2020, 9:59 am David Cousens, <davidcousens at bigpond.com>
> wrote:
>
>> I am now happy that there is no problem with the starting balance
>> calculation
>> in 3.9  and the problem was caused by a previously undetected finger
>> problem
>> on my part  and withdraw my previous qualms about retaining it for the
>> future.
>>
>> I still think it is excessive to restrict the reconciliation date entry in
>> any way but agree that a warning should be displayed if either a statment
>> date in advance of "today" is entered, perhaps with the option for the
>> user
>> to confirm that they either want to retain the advance date or reenter it
>> in
>> a popup dialog.
>>
>> Also agree with a warning if any reconciled transactions with reconcile
>> dates  in advance of today are detected in the file. I am less sure about
>> assigning them to an arbitrary past date however.
>>
>> If a procedure for correcting them is developed it might be helpful if it
>> could display data for transactiions with reconciled splits which have the
>> advance date. The information that I found most useful to determine when I
>> made the error were the transaction date posted and the transaction date
>> entered into GnuCash and the reconciliation date and the account name or
>> at
>> least the account guid to confirm that all the affected splits are to a
>> single account. This was particularlyuseful to me because i append an "_R"
>> to statement pdf files I have reconciled and the file modified time allows
>> me to determine the date I did a recociliation. In future I will append
>> "_Ryyyymmdd" so i don't have to look up the modified times for the files
>> as
>> well.
>>
>> Bug797668 is now marked as resolved
>>
>>
>>
>> -----
>> David Cousens
>> --
>> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
_______________________________________________
gnucash-devel mailing list
gnucash-devel at gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel