-----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----- _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
