Laurent Jacques <[EMAIL PROTECTED]> writes: > 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 ?
No, but the the idea is to make it really simple for someone to re-use this matching code if they want to create a CSV importer. > In some cases, user has only the possibility to have this format from his > webbanking account. Feel free to write the importer code. Patches are always welcome ;) > Thanks, > Laurent. -derek > > 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 -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
