On Thu, 11 May 2000, Hendrik Boom wrote:
> Last time I looked, my bank's qif imports give me all the transactions
> since the last statement, not since the last qif import.
You should also be able to get the bank to export other periods.
In general, I think that we must assume no correlation between importing data
and reconciliation. All that we know is that each entry imported from the
bank must appear in the ledger and that it has cleared the bank.
A JE must progress through the following "reconciliation states"
1) Entered
2) Cleared
3) Candidate
4) Reconciled
The act of reconciliation is that of selecting candidates so that they match
the statement to which they are being reconciled. When it is complete, the
"commit" operation moves all the candidates to the reconciled state.
>From a user's POV, it is convenient to be able to invoke a function which
moves all "Cleared" entries to the "Candidate" state if they are on or before
the closing date of the statement. The user can then manually select
exceptions.
> If gnucash were to remember the complete text of the qif-version of the
> transactions, it could easily and reliably eliminate duplicate
> qif-transactions. Matching them with the manually entered ones
> should not be automatic -- except, of course if gnucash recognizes
> that a new qif transaction is identical to a previously matched
> qif-transaction.
I don't think that it is necessary to attempt to remember the complete text.
Transaction(cheque) identifier(number) and amount should be adequate to
identify most transactions once they have been matched the first time.
> Reconciling with monthly bank statements is a separate issue
Agreed. However, downloading from the bank and then selecting all "cleared"
items is likely to produce something very close to the correct set.
