[GNC-dev] About 3.9 and reconciliation balances

Adrien Monteleone adrien.monteleone at lusfiber.net
Fri Apr 17 10:49:28 EDT 2020


+1 on your idea of the statement as a separate object.

If a closing date is later realized to be erroneous, it only needs to be corrected in one place, not every transaction involved. And I hazard the guess that the UI that allows a user to edit a statement object data would be simpler and more straightforward than walking through every transaction looking for suspected bad dates and then making changes.


Regards,
Adrien

> On Apr 15, 2020 w16d106, at 6:14 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> I agree this is useful extra information and also what Christopher Lam has been playing with.
> 
> From an implementation point of view I'd structure this slightly differently:
> 1. instead of adding an account property with a list of reconciliation history, I would introduce a 
> new object, like a "statement" This object would have the fields you mention before (date of 
> reconciliation, statement start date, statement starting balance, statement end date) and some 
> more:
> *statement id* - most bank statements has a unique number which may be helpful to track
> *statement ending balance* - particularly useful to verify manual transaction entries. If you 
> explicitly enter a start and ending balance in addition to the transactions themselves, amount 
> typos will be caught by the numbers no longer adding up.
> *account" - the account this statement refers to.
> 
> Lastly each split should get an additional field "statement id" referring to the statement which 
> includes it. The split "reconciliation date" field would no longer be necessary. That info is 
> encapsulated in the associated statement.
> 
> This mapping would be much closer to the real world order of things:
> * during reconciliation a split is matched to a line on a statement
> * each split can be linked to only one statement
> * in case of reconciliation trouble in the past, the extra statement details make it easier to dig 
> up the related external source (there's a statement id in addition to a reconciliation date).
> * it is more clear which splits were reconciled together - they are tied to the same statement, 
> where in the past there was only a reconciliation date, which may have been wrong for various 
> reasons.
> 
> Regards,
> 
> Geert



More information about the gnucash-devel mailing list