[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