Geert > 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.
I also agree that this is a good way to implemnet the idea. It meets what i had in mind for a reconciliation history much better. David ----- David Cousens -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
