On Thu, 11 May 2000, Hendrik Boom wrote:
> > 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
>
> That's right. Only I like to add a note to each candidate and reconciled
> transaction to pair it
I'm not sure that I would allow you to alter the entry while it is
"reconciled". However, I would assume that you are happy to do it in the
"candidate" state.
> > >From a user's POV, it is convenient to be able ...
> Except that when I reconcile, I match up the transactiuons with the
> statement one at a time and check them off on the paper statement. If I
> Converted I would lose track of which lines on the paper statement had been
> matched.
Then you should not use the "shortcut". In my case, my bank statement has
cheque numbers in sorted order. I can quickly scan the list and locate any
exceptions. As a result, assuming that all cleared items are candidates is
much quicker for me.
>
> > 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.
>
> Except a lot of the transactions I get don't have meaningful numbers on
> the bank statement -- whether .qif or paper.
OTOH, I'll bet that the "new" items are "appended" to the previous list.
Therefore, as long as I can find a "Cleared" item of the correct amount, I can
declare that it is not new and skip it. That may not be perfect, but I'll bet
it is very close.
