[GNC-dev] About 3.9 and reconciliation balances

[Dale Phurrough]

Thanks for inquiring. I've hinted at top-level concepts and ideas in my
thread "reconciliation concept from top view"
https://lists.gnucash.org/pipermail/gnucash-devel/2020-April/044863.html
and in particular the relationship between a "shared truth" and the GnuCash
"reconciliation" process. I am not aware of any must-fix/change now/bug or
die situation with GnuCash reconciliation. Instead, it seems to just be an
envogue topic. Someone got excited and so there's chatter and coding on it.
Nothing wrong with that...do what makes one happy. :-)

Caveat -- the following ideas haven't yet due diligence. I volunteer it
only as you inquired. I need more time before deep review though I'm very
open to discussion/input.

Some of the ideas I have on shared truths and reconciliation might
eliminate data duplication, increase reconciliation integrity, increase
auditable records, etc. I think the envogue conversations around
reconcilation dates/autofixes/future/past are minimized. And, some auditing
wants from the German users (that I read months ago) become possible. For
example, one concept I'm noodling is the idea of a shared truth called a
"reconciliation certificate". Referencing my "top view" thread and
pseudocode there and here:

  vector<vector<fact>> facts;  // e.g. vector<fact> from the GnuCash user's
data entry,  vector<fact> from the bank statement, vector<fact> from
auditor, etc.
  const reconciliation_certificate = reconciliation_process(facts);

   - reconciliation_certificate is unchangeable; its input was hashed and
   therefore later changes in facts are detected; digitally signed; digital
   timestamps like RFC 3161; etc.
   - reconciliation_certificate can be exported to a file to be given to a
   3rd party, archived, etc. An audit can use that exported cert to validate
   the books haven't changed. These external certs (or the internal copies of
   them) could be used to validate the integrity of gnucash data itself to
   detect changes to transactions due to gnucash bugs, bitrot, HD failures,
   etc.
   - All the tech needed to do this is stable and readily available today.
   I have experience coding C++, node, and python with them all. While the
   underlying math is complex, the coding with APIs is generally
   straight-forward.
   - reconciliation_certificate is an entity in itself. GnuCash would have
   one for each time reconciliation_process() was successful. So it is
   possible to re-reconcile by simply making a new reconciliation_certificate
   with reconciliation_process(facts). Since each reconciliation_certificate
   is saved, now we have an ongoing record of current and past reconciliations.
   - reconciliation_process() has validation in it. Validation on the input
   facts, validation on the equality/compatibility of the facts to each other,
   validation with a pluggable set of rules by country's laws/regs,
   GAAP, IFRS, etc.
   - a transaction and a split both have no attribute "reconciled date".
   Instead, a split has/not a pointer to a reconciliation certificate. It is
   that certificate which has the reconciliation timestamp.
   - This is all deep in implementation. How it is exposed to end-users in
   the GnuCash UI could be seamless and uneventful. Yet, new features/UI can
   be built with capabilities granted by a fresh implementation.

With more diligence, ideas with be refined or eliminated...more coherent. I
want people to be able to understand my thinking even if they disagree with
it. I'm approaching "reconciliation" from a perspective of what are needs,
what fresh tech is available to meet them, and how do those fit together.
Trying to avoid the good-enough, legacy, or long-timers pitfalls while at
the same time eliminate ideas which have already been tried elsewhere
(including outside GnuCash). Add in conversations on feature/benefit/effort
given the existing GnuCash codebase.

Given my workload, the ideas I already have, diligence and the discussions
needed to answer "is this wanted/needed/useful?"...I think any
potentially-related coding is most likely 2021 or later. I hope others will
involve themselves, so I don't consider this a solitary effort by me. :-)

--Dale


On Sat, Apr 18, 2020 at 11:15 PM David Cousens <davidcousens at bigpond.com>
wrote:

> Dale,
>
> While that was the main thrust of the thread, it is inevitable that it will
> bring attention to other issues so no real dramas. The advent of electronic
> clearing almost immediately  and OFX direct connect connections to at least
> some banks (mine won't cooperate) is also changing the game. An OFX
> directConnect query may have the status of a statement in some
> circumstances
> and an import in that can already trigger the reconciliation processand
> reconcile in some circumstances as John described in another post. This is
> still consistent with the manual reconciliation process.  The discussion
> did
> encompass improvements to recording the reconciliation process, i.e a
> reconciliation history if you like to help with automatic checking of the
> account and Geert outlined an approach to that by including a statement
> data
> structure which links to the account being reconciled and has essential
> information about each statement which would make what I have in mind much
> easier down the track.  I wasn't objecting to issues you raised but was
> more
> concerned that we were on the same page in terms of terminology.
>
> Not sure what an alternative approach to reconciliation would look like. As
> an accounting process, reconciliation is about checking your books records
> against those maintained by another entity and ensuring agreement. From an
> accounting perspective GnuCash's reconciliation process is already very
> good. How would you do it differently?
>
> David
>
>
>
> -----
> 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
>