Generic Transaction import discussion

[Benoit Grégoire]

> This is a good intention. However,  I just checked again the design of the
> QIF importer, and I think the way the transaction matching/split creation
> was solved there is a big role model. Have you tried that once?
>
> I think the druid-style import process is much more usable for users. There
> is one step for creating the "other split" in each transaction, and then
> there is another step where each imported transaction can be marked as a
> duplicate of an existing one, hence the imported one is ignored.

I did try it, however, not for very long.  The current druid based qif 
importer is great for a complex import you rarely do, such as importing a 
Quicken export.  That is not surprising, since it was designed for just that 
purpose.  However, in Quicken I used to import my transactions up to 3 times 
a week.  For that kind of use (and from my very limited experience with the 
qif importer), the qif importers felt inadequate.  The amount of keyclicks 
you have to do to import one or two transactions using a multistep process is 
simply ridiculous.

For day to day transaction import, I think the Quicken way of doing things is 
perfect (altough the Quicken implementation isn't).  But then again for most 
daily tasks I just hate druids.

> I see two major differences here: 1. the fact that other-split creation is
> done in a separate window i.e. druid page (and also that it exists at all,
> but of course in generic-import it's still only planned); 2. the fact that
> the choice of what can be done with an imported transaction is limited to
> either "add as a new transaction" or "ignore since it's a duplicate but
> reconcile selected match".
>
> To 1.: For complicated multi-step tasks, I'm definitely a big fan of a
> druid-style GUI. I don't know how you were planning to integrate the
> split-creating GUI features, but to simply add them to the existing window
> IMHO is a bad idea, since that window is already overloaded with GUI
> elements at this point in time. So I would definitely want to propose a
> druid-style GUI, once the split-creation is implemented in generic-import
> as well.

I completely disagree on making it a druid like GUI, unless there is an option 
to chose one or the other.  Also a druid might be fairly hard to implement 
since the matcher was designed not to care about the order of the API calls 
(You can send it accounts and transactions in any order, wether the GUI is 
opened or not).  It was designed that way to make it more generic.

The way I wanted to implement the second split is to simply select the 
destination account from a drop down box if the split isn't balanced.  (In 
the future that selection could be remembered based on the payee) What would 
be great is to actually see the transaction in register view at the bottom of 
the screen, but I don't know if I can embed the register in that window.

> To 2.: I seriously think that these two choices are enough. We currently
> have "reconcile selected match",  "add as new", "replace selected match",
> "ignore".
>
> I think we simply don't need the "ignore altogether" option, since either a
> user wants to get the transactions through importing, in which case he will
> want them all, or he doesn't want them at all, in which case he'll cancel
> the import. This option might be useful for testing, but in real life IMHO
> this happens to seldomly that we can leave it to the user to manually
> delete that transaction in the register afterwards -- that's always
> possible. Again, IMHO users wanting to get the transactions from importing
> will almost surely want them all.

I disagree, a user might want to completely ignore a transaction which is 
irrelevant to his finances (for example when I was studying, I had a joint 
account with my mother.  I was the one using it most of the time, but 
sometimes my mother would move large sums of money thru the checking account 
which had nothing to do with me.  An other reason to ignore completely is if 
you downloaded (by error or because you had no choice) a OFX file containing 
statements for multiple accounts, some of which you didn't care about.

And most importantly, ignore is used by the GUI to tell the user that GnuCash 
was unable to make a decision as to wether the transaction was to be added or 
reconciled.

> Also I think that the "replace selected match" gnomeis even more 
unnecessary. It
> might be useful for testing, but for real bookkeeping, if the transaction
> is there then it's there and no further replacing has to be done.

As for the replace function, the point is that one of the nice thing about 
downloading transaction is that you get the name of the store and address 
always spelled the same way, very nice for reports.  If you previously 
quickly entered the transaction to get rid of the invoice, it's nice to be 
able to replace the transaction with the presumably much more complete and 
consistent info provided by the bank.

But in any event it is trivial to hide the replace action in user prefs (and 
make the default disabled).  Same with the former, however, an replacement 
mechanism would have to be provided to tell the user that the gnucash match 
was inconclusive.


> Therefore IMHO only the two possibilities from the QIF import should be
> there. This would also make it possible to have one "check" bitmap switch
> in each line, instead of the non-intutive GUI with activated buttons that
> we already discussed... so the solution would be quite simple.

Well, the check would preclude having more that two choices, which I find 
unacceptable.  However, if someone can tell me how to make a select popup (I 
don't know the actual term in English) in the left column, I would be more 
than happy to oblige.  That is what was originally planned, but I just didn't 
know how to do it.

> Also I should note that the QIF import "add as new" transactions are added
> with reconcile status "c" (cleared), not with "y", which is a thing I quite
> liked. The "reconcile against a bank statement" is supposed to be done
> against the monthly statement sent by the bank, and only at that point in
> time transactions are actually put into the "y" state. Have you ever tried
> that with QIF downloads? I've done it over several months while my bank
> still sent me the monthly statement letter, and it proved to be *really*
> useful.

I don't really understand what the difference between cleared and reconciled ( 
c and y) really is.  But the info you get from the bank from OFX (here at 
least)  IS what is contained in the monthly statements.  In fact, I don't 
even receive them anymore, since I subscribed to online statements with my 
bank (coop actually, but that is irrelevant).  Could you provide more info 
please?  In any event, it's once again easy enough to provide a user pref 
that tells the matcher if he should reconcile with c or y.

I know the GUI is still far from perfect, but feature freeze is coming quickly 
and for better or worst I decided to prioritize investment transactions for 
this release.  Hopefully there will still be time for improvement before 1.8.  
I DO agree the bottom action selection has to go, but I need help.

Oh, and sorry for spelling and grammar, I just got back from a party and my 
second language migh not be at it's best... ;)

Good night,

-- 
Benoit Grégoire
http://step.polymtl.ca/~bock/