Sorry for this perhaps too simple question but, is it planned that this generic importer can handle data in raw CSV format ? Or this is not related to your discussion ?
In some cases, user has only the possibility to have this format from his webbanking account. Thanks, Laurent. On Friday 22 November 2002 16:38, Christian Stimming wrote: > I feel that we are still quite far from actually having the same > objective with the generic importer. Therefore I thought I should > describe more clearly what "the usual case" for the generic importer > would be -- what is "the usual scenario" for when users are going to use > it? > > From my point of view, "The Usual Usage Scenario" is > > * The user regularly (every 1-30 days) imports a number of transactions > (some number between 1 and 100). > * 90% of these transactions are *new* transactions i.e. are *not* a > duplicate of an already entered transaction. > * For 50% of these transactions, payee/description/text is uniform > enough so that the destination account can automatically be correctly > guessed. > > If we now argue about a GUI for the importer, please keep in mind what > our Usual Scenario is. If you think my above description doesn't quite > fit your situation, please send your comments. > > For the HBCI protocol, additional assumptions will hold that narrow down > the usage scenario even more, giving "The Usual HBCI Scenario": > > * *All* transactions have one known originating account. > * The bank account belongs to a German bank (HBCI simply exists only > here), which implies the following two points: > * If an imported transaction is a duplicate of an existing (probably > manually entered) transaction, the amounts will match *exactly* in 99% > of the cases. > * If an imported transaction is a duplicate of an existing (probably > manually entered) transaction, the date will be off by 1-2 days for 50% > of these transactions. > > In the ongoing discussion, I want to achieve a GUI that serves the > user's needs in "The Usual Scenario" as good as possible. Additionally, > I would love it if there is enough configurability to take into account > "The HBCI Scenario" as well, which is currently the case e.g. through > the fact that the hbci-protocol can call the > Transaction-duplicate-matcher without having to call the account-matcher > first. > > Now what kind of GUI matches "The Usual Usage Scenario"? > > As you can see above, I believe that the action of "duplicate detection" > is the *exception* and *not* the rule. Therefore ultimately I would like > to arrive at a GUI where the *exceptions* are marked in a way that they > signal "Here further checking is necessary", and for the 90% rest it > automatically should be obvious that the *don't* require any further > manual checking for duplicates. One example of applying that point of > view is that I strongly oppose any GUI that would require "clicking on > every transaction" just to confirm the fact that they are new ones. > > Also, since I just argued that only a small minority of imported > transactions will turn out to be duplicates, I actually want to arrive > at a GUI that does *not* require the user to ask himself "Is this > transaction a duplicate" for *every* transaction. Again, this question > is only relevant for a small minority of the transactions. That's why I > oppose the integration of the destination-account-choosing into the > existing duplicate-detection GUI: If these two actions appear in the > same window, it means that the user is in fact asked both questions for > each transaction. This IMHO will result unnecessary distraction from the > real task. Therefore I am voting for a seperate window/druid page for > the destination-account-choosing. > > I believe that this is actually a point where the application of the > Inductive UI Guidelines from > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html >/iuiguidelines.asp would make perfectly sense. To quote their four steps in > designing IUI software: > > 1. Focus each screen on a single task. > 2. State the task. > 3. Make the screen's contents suit the task. > 4. Offer links to secondary tasks. > > In that sense, one single task is "Find the [10%] duplicates in the > imported transactions". A different task is "Choose destination accounts > for imported transactions". > > Uh well. Maybe people should first comment on what I've already written. > > Christian > > _______________________________________________ > gnucash-devel mailing list > [EMAIL PROTECTED] > http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
