Generic Import, Usual Usage Scenario

[Laurent Jacques]

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
> gnucash-devel@lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel