Christopher, Those are all very good points. I do think that the goals are laudable, and I think Dale's call for further analysis is a good approach. The question of what reconciliation is supposed to be, and what it's supposed to do (beyond the most rudimentary textbook descriptions) are not yet clearly defined in theoretical or practical ways, and they should be.
The original developer model, I believe, was that reconciliation was a one time, forward moving progression that never deviates. You get a statement from your bank, check off those entries in your books that match, and if they balance, you are done until the next month, when you repeat the process with the next batch, etc. The need for a date of reconciliation is secondary in this model. Unfortunately, real life doesn't always match that, and when a fat finger problem arises, it becomes exceedingly difficult to track down the source. I've been known to revert more than a year's transactions and reconcile them all over again in some situations. So, a mechanism that would allow me to isolate that variation would be fabulous. But, I am also one who will reconcile an account for a year or more in one pass, simply because it's an account with one or two monthly transactions. So, that is a complication... I will also add in here that the developers have muddied the waters on this whole situation with the decision to de-reconcile transactions when the user edits it later-- even if the changes are not related to an account's balances. In addition to the challenges these changes may cause to your reconcile model, they go straight to the question of what reconciliation means in the GnuCash realm. If reconciliation is an established regular process to compare against a statement always, then allowing an edit to change this status needs reevaluation. But if status is always malleable by later actions, then your model is doomed to failure, since you can't rely on the date of reconciliation to remain set to the actual statement date. The aqbanking issue (that imported transactions get the current date in reconciliation date) requires further consideration as well. Looking this over, it seems to me that your goals could only be achieved by adding a statement date data element to each transaction, which would tie that transaction to a specific statement. This field would have much more limited purpose and modification avenues. It would also help with generation of reconciliation reports. The existing reconciliation date field would then be freer to be considered a last-edited date, which might have benefits in other ways-- for example, one might be able to identify a transaction in a reconciliation set that has a significantly different last edited date. Or a user could be notified in the popup when they change the value of a reconciled split that they should revisit the mm-dd-yyyy reconciliation to be sure that their books are still accurate. David T. -------- Original Message -------- From: Christopher Lam <christopher....@gmail.com> Sent: Sat Apr 11 03:41:01 GMT+05:30 2020 Cc: gnucash-devel <gnucash-devel@gnucash.org> Subject: Re: [GNC-dev] About 3.9 and reconciliation balances The "purpose" for the "fix" was to allow future features: 1. allow manual reconciliation of an account, using past reconciled_date and relevant past ending_balance. If my "fix" were applied, it would serve *me* very well: (a) If an account, properly reconciled, had an errant split hiding somewhere caused by fat-finger, I could reconcile from any past bank statement, verify the balance is correct (or not) and narrow down to the exact period that contains the errant split. (b) This was also useful to fix cases where a past split was unreconciled and needed to be rereconciled -- you could reconcile latest statement and change the field 'n' to 'y' but its reconciled date would *not* be accurate anymore because it'd be the latest statement; I meant to reset the split reconciled_date to be the statement_date. 2. a natural extension of allowing past reconciliation is to store the list of statement_date and ending_balance somewhere in the account metadata and retrieve the list in reconcile_window. Hence https://github.com/Gnucash/gnucash/pull/667 is born. https://user-images.githubusercontent.com/1975870/77246245-5a1e2d80-6c1d-11ea-8fc3-b2ec34fdb5f9.png is possible. In my testing, rereconciling past statements is nicely upgraded. 3. a benefit of maintaining old reconciled_data is that we can now compare an account's reconciled balances at periodic dates against the stored list, and loudly report if a balance discrepancy is found. See https://user-images.githubusercontent.com/1975870/78035104-2c8d5e80-7358-11ea-95bc-feba7f9f2bba.png -- note the first two lines show reconciliation and account balances match; the third section show unequal balances and show the relevant splits which contain an extra one. So, (1) and (2) are not possible -- rereconciling past statement cannot currently take place (unless code sets/queries a book property "use strict reconciled dates"), but I believe (3) is still possible. It won't happen until 4.x though. On Fri, 10 Apr 2020 at 18:51, Dale Phurrough via gnucash-devel < gnucash-devel@gnucash.org> wrote: > Yes JR and DA 😄 > Nothing bad or sinister, rather a future opportunity to virtually > whiteboard the concepts and events surrounding "reconciliation", then > reviewing what gnucash currently does to see the gaps. > > It's comforting to see that it works for so many scenarios, and the > discussion on this was hardy for change/regression. > With it reverting to 3.8 behavior, I see all this as a healthy outcome with > a opportunity for the future. I'll gladly participate in it as I'm a > regular qif, ofx, manual, multiple currencies reconciler. > > On Fri, Apr 10, 2020, 6:43 PM Derek Atkins <de...@ihtfp.com> wrote: > > > Dale, > > > > On Fri, April 10, 2020 12:37 pm, John Ralls wrote: > > > > > > > > >> On Apr 10, 2020, at 8:22 AM, Dale Phurrough via gnucash-devel > > >> <gnucash-devel@gnucash.org> wrote: > > >> > > >> This feels like a separation of accounting logic -- separate from > > >> storage > > >> field -- has broken down. From what you wrote, it seems each of these > > >> sources have direct access to core fields without any > > >> accounting/business > > >> logic to control the transaction of reconciliation nor to validate the > > >> input into that reconciliation. > > > > > > Unfortunately there is very little such separation anywhere in GnuCash. > > > > Even moreso, in many cases (e.g. Import) the data just isn't there! QIF > > has a reconcile flag but does not contain a reconcile date field. So if > > you're importing reconciled data, what should you use for the reconciled > > date? Over time, different developers working in different parts of the > > code made slightly different decisions, because at the time the actual > > date didn't matter because nothing used it. > > > > -derek > > > > -- > > Derek Atkins 617-623-3745 > > de...@ihtfp.com www.ihtfp.com > > Computer and Internet Security Consultant > > > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
