Generic Transaction import discussion

[Christian Stimming]

-----BEGIN PGP SIGNED MESSAGE-----

On Mittwoch, 16. Oktober 2002 01:12, Benoit Grégoire wrote:
> > * Currently imported transactions are created as transactions with one
> > split. 
>
> There are placeholders in the GUI for showing the "other" side of the
> transaction (the othe splits).  What is planned is that once this is
> implemented the user would be presented with the opportunity to create
> another split (filing in as much default data as possible, eventually
> memorising defaults like the QIF account) or dump it in a default "Misc"
> account.  

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 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.

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. 

Also I think that the "replace selected match" is 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. 

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.

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.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iQCVAwUBPbHygGXAi+BfhivFAQGIawQAjsgz+CX5kaWIfF7bsYkoOBCU9hzZ7oJe
LdUf7KrKLFjZ8SQ8apq2zsDWU/RpxYOS2W9EhtaN3uMix5hNglM7Yg+zIvhGC7Vw
Yz1LoOgdvWpsG1o8v/91QdeEAFY1fZrGR4myqJ36jIpd5GkWSapyCY5wxd3lKZZ0
s1qb6P96xb8=
=TpKE
-----END PGP SIGNATURE-----