As a lurker on this list, I just wanted to say this "fuzzy QIF import"
with duplicate recognition would be the most *wonderful* feature.
Better even than OFX (ok, about equal to it in importance for me).
I enter all my checks manually, and anything large (so I have a
general idea how I'm doing), but I tend to let the tons of little $20
ATM and EFT-type transactions at the grocery store slide until the
monthly reconcile, then I enter them all from my bank statement
(semi-painful). It would be *terrific* to be able to import them and
not duplicate all the stuff I've hand-entered. I would be very happy
clicking something like "ignore (dup)", "import", "merge with..." or
"edit then import" for each txn.
I would use it weekly (more or less), with Richard's method of not
completing the reconciliation, saving that for the monthly paper
statement; presumably that would be a trivial process since I'd
already have all the right transactions in gnucash!
My bank can create a download qif of an arbitrary transaction period
(up to 3 months) with any amount of overlap from previous downloads.
You specify begin and end date.
(Wow, maybe I could even write guile code to go to my bank's web site,
get the last week's QIF data, and start the import process -- TOO
COOL!)
Fuzzy matching (asking me questions when match is not obvious) will be
important for me. Ideally I could also have a hook to write
transformation rules (e.g. all ATM withdrawals go into "Cash
Withdrawal" subaccount or something like that). The rules should run
before the matcher gets a crack at it, I'd think.
Again, you folks are the greatest! As soon as I get my new machine up
and dual-booting 98/Linux, gnucash is going to be my first install!
>>>>> "RW" == Richard Wackerbarth <[EMAIL PROTECTED]> writes:
RW> On Thu, 11 May 2000, Linas wrote:
>> 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 ... )
RW> Yes, that is generally how I see it working. However, we should
RW> recognize that we may not want to actually finish the
RW> reconciliation. That might need to wait for the printed
RW> statement to arrive.
--
. . . . . . . . . . . . . . . . . . . . . . . . .
Gary Oberbrunner [EMAIL PROTECTED]
GenArts, Inc. Tel: 617-492-2888
8 Clinton Street Fax: 617-492-2852
Cambridge, MA 02139 USA http://web.genarts.com
