+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.gnuc...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
