[EMAIL PROTECTED] wrote:
>
> Bill, see the note below.
>
> I take all of the points you made in an earlier message; you're right,
> reconcileing with QIF files is a potentially ill-defined, dangerous
> process. And yet, we still have the note below.
>
> It's been rumoured that Randolph Fritz said:
> >
> > On Tue, May 09, 2000 at 12:50:09AM -0500, Linas Vepstas wrote:
> > >
> > > I was talking to someone about on-line banking & gnucash. I hadn't
> > > thought about ti much, but a large part of on-line banking is
> > > reconciling statements against what the bank has. Now, many 'online
> > > banks' use QIF export as a way of sending statements to users. Sooo
> > > (sound of lightbulb turning on) isn't the right way to import QIF files
> > > is to run them through a reconcile-like dialogue?
> > >
> > > Anyone out there using gnucash and also looking at thier bank-staements
> > > on-line? What do y'all think?
> > >
> >
> > That's exactly what I am currently doing manually, once a week. My
> > Credit Union can provide transaction records in QIF format, but there
> > doesn't seem to be a good way to use them with GnuCash. One of the
> > things I like about this combination of services is the amount of work
> > it saves; errors are caught early, and there is no need to laboriously
> > drag through a month or more of transactions to unsnarl mistakes.
>
> If I understand this correctly, and we did qif-based reconciliation,
> it would work as follows:
>
> -- randolph goes to bank web site, makes note of the banks current balance,
> and downloads a qif.
> -- he powers up gnucash, and picks 'reconcile-qif' from the menu.
> -- we suck in the qif file, and try to find any transactions in it that
> are not already recorded in the register. we pop up a window, saying
> 'do you want to add these transactions to your account?' and allow
> user to add them one by one, or regject them one by one, till they're
> done. We may want to help them idntify potential duplicates (e.g.
> dates, amounts which are identical, but payee feild is different, or
> dates that are same, payee field slightly misspeled, and amounts
> slightly off ...)
> -- when they're done with above, then we pop up the reconmcile window,
> and from there, things proceed as normal reconciles do ...
> with one 'minor' difference: instead of having 'y/n' in the reconcile
> column, we might have a yellow 'm' for 'maybe' or 'c' for
> candidate/confirm', and the 'c's' got marked that way because
> we marked them when the QIF came in. randolph has only to click on
> yellow c's to turn them into green y's to get full reconciled.
> (and there would be a yellow subtotal, showing hopefully yellow $0.0
> which turns green at the end ... )
>
> Linas.
Linas,
When I read your E-mails about this I thought it was a great idea (I also
agree with Bill's concerns). After thinking about your idea for a while,
the concept of using a piece of paper for a statement sounded a hundred years
old, yet we're still doing it. Can we just get rid of the paper statement,
just like we replaced the paper register?
Your method is almost exactly the same as replacing a paper statement with
an electronic one, but a quick overview of the process sounds like you're
trying to change the methods used to import and reconcile. Is there a way
to present your method to the user so it's more obvious that you're just
replacing the paper statement with an electronic version, and then adding a
few obvious features?
For example:
- Download the qif data into a "bank statement" display.
- Display this next to the real register in a "diff" format where Gnucash
tries to match transactions as best as possible.
- Now the user can manually reconcile everything from here and it's just
like the process we use now, and no one feels like anything has changed.
- Now with our existing reconciling methods still obviously unchanged, what's
the first feature a user would want? They would want a way to just copy
a transaction from the statement into the register, with a few tweaks to
change the account names, payee, and memo fields before the copy. This
is useful for those transactions where you know they are valid, but you
forgot to enter them into the register. This is still just like what we
do manually.
- After a while we realize that if we're lazy and don't enter a transaction
into the register before reconciling, then we just enter them while we're
reconciling the account. Sometimes we do this now as well, except with your
idea, typing is reduced. For every transaction I enter after downloading
the statement, I have less typing to do.
After a while using this feature, I would change the way I work. Instead
of entering transactions on a regular basis and reconciling once a month,
I would "reconcile" every time I use the program. I would download the
statement _before_ each time I sit down to enter transactions. Then copy
over most of them as I go to enter them, since this is faster than entering
them by hand.
The net result is that I end up doing what you described, but I never feel
like I'm changing my methods along the way, just like I never felt like
I was changing my methods when I went from a paper register to an electronic
one.
Gerald
