David T, Christopher, Dale et al
In accounting terms a reconciliation is always a confirmation of the details of the splits to an account against some external record independent of the particular set of books records are kept in. This is generally done in a set of contiguous periods over which that external record is available. A statement like a bank statement which is issued periodically is the most common example and probably the most systematic. (I have in the past had to reconcile a statement from a supplier of credit dealings against A/P and Payments for example and many similar processes for a business a process not necesarily as easily automated or defined as against an account but I don't think reconciliation in this wider sense is what we are dealing with here.) I don't see any problem with the reconcile status at present as implemented in the QIF, OFX imports or even the AQbanking import of transactions and balances, provided the bank accepts that record is a statement of the account on their part. With AQbanking and OFX directconnect import of records, the process. If the process of querying the bank server for records can provide a starting balance at the end of any past downloads of data, the transaction split details for the account and relevant details and the bank's record of the ending balance at the end of that group of transaction splits then it should be in principle be reconciled using an instance of the current procedure where the date entered for the transaction = reconcilation date of the split = end date of the statement=date at which reconciliation was carried out. In the more general case there are multiple relevant properties and dates associated with a reconciliation cuirrently recorded: *date entered* - a transaction property *date posted* - also a transaction property *reconciliation status* split property ["n","c","y" ] only the "y" indicates reconciliation. being cleared is different from being reconciled. *reconciliation date* - split property - currently set by the reconciliation process to the end date of the statement as the date to which that split is reconciled AFAIK. and some which are currently not recorded AFAIK but could be useful if maintained in a reconciliation history for the account as a list: *date of reconciliation* - date at which a reconciliation was carried out -limited use but may be of some use in tracking down errors *statement start date* *starting balance>* *statement end date>*. This would obviously need additional data structures, data file modifications, ie not short term. If we are going to try and verify the integrity of the account and reconciliation process we need to to > Looking this over, it seems to me that your goals could only be achieved > by adding a statement date data element to each transaction, which would > tie that transaction to a specific statement. David the problem with this is that reconciliation (and its parameters like reconciliation date and status) are the property of a particular group of splits to a particular account so any data elements that record whether a record is reconciled or not and to what statement period it is reconciled properly belong with the split where they are now. If one is recording the end date of the last reconciliation period and any associated balances which pertain to the whole group, these really should be properties of the account that was reconciled rather than a transaction which has links to two or more accounts and can be independently reconciled in each of those accounts. David Cousens ----- 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
