Generic Import, Usual Usage Scenario

Derek Atkins warlord@MIT.EDU
22 Nov 2002 21:09:48 -0500


Laurent Jacques <ljacques@fyma.ucl.ac.be> 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
> > gnucash-devel@lists.gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnucash.org
> https://lists.gnucash.org/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
       warlord@MIT.EDU                        PGP key available