Wishlist: All duplicated imported transactions in one expanded window

[Charles Day]

On Thu, Aug 27, 2009 at 7:49 AM, Derek Atkins <warlord at mit.edu> wrote:

> Daniel Trezub <daniel3ub at gmail.com> writes:
>
> > When importing a QIF file over an existing account, the importer can find
> > some duplicated transactions.
> >
> > The user has, then, to click on the imported transaction on the left
> panel
> > of the window, click on the appropriate transaction on the right panel
> that
> > matches the imported one, and so on for every duplicated imported
> > transaction.
> >
> > When importing a large number of transactions with a large number of
> > duplicates, this work can get very time consuming.
> >
> > One way to make things better is to show all duplicated transactions and
> > their respective guesses in one big scrollable window, so the user can
> see
> > at a glance every imported transaction AND their duplicate guesses,
> clicking
> > on the matching transactions only.
> >
> > Another idea would be import the transactions into a "maybe duplicated
> > transactions" account or something like this. The view for this account
> > would be the transactions list with the imported ones in one line over
> the
> > duplicated guesses in the following lines, with the ability to check the
> > matching transactions. Something like a tree view, but without the need
> to
> > expand it.
> >
> > Am I clear? :P
>
> No....
>
> Let's say you have list 1, the imported list, that has transactions A,
> B, and C.  Transaction A potentially matches F, G, or H, B potentially
> matches M, N, or O, and C potentially matchines X, Y, or Z.  Note that
> I'm supplying a simple example here.  There could be dozens of potential
> matches per transaction, and dozens of transactions that need to be
> matched, so the total list of potential match transactions could reach
> into the hundreds quickly.
>
> But back to my simple example. Lets presume that this is all displayed
> as you say, so you have two columns.  Column 1 has A, B, and C.  Column
> 2 has F, G, H, M, N, O, X, Y, Z.  How would the user perform the
> matching?  You click on A and then click on F, G, or H (scrolling
> through the window to find them, of course)..  Then click on a "Found
> Match" button....  And then repeat for B, and C...
>
> But that's effectively what you're doing now, except the right-hand
> display is limited only to the potential matches for what you've
> selected so you have fewer options to choose from.  Much less confusing.
>
> > What do you think? Give me your ideas so I can file this one in Bugzilla.
>
> I think that I don't understand how this is "better".
>

I'm guessing he imagines it more like one scrolled treeview, with something
like (assuming all rows are expanded:
a
  f
  g
  h
b
  m
  n
  o
c
  x
  y
  z

If another transaction, Q is a potential match for both A and B, then it
would appear underneath each of them.

I definitely prefer the way Quicken does it, though. It completely separates
the import part from the matching part. You import you data, and all the
imported transactions are segregated until they are manually approved by the
user. When the user looks at them, those that are a potential duplicate are
shown as such, and the user can choose to accept the match, or match to a
different transaction, or import as new. There is an "accept all" button if
you just want to accept the displayed defaults on all of them.

This process also allows the application to ask for more information before
a user accepts each transaction. For example there might be one transaction
in which GnuCash needs to ask, "Which lot of XYZ stock are you selling?"
(Assuming we eventually fix lot management for shares.) In this case,
clicking "accept all" would automatically accept all transactions that don't
need additional questions asked.

Just thinking out loud really, as neither way has a reasonable chance of
getting done any time very soon.


> > Thanks, guys! Keep up the great job with GnuCash!
>
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
>
> -derek
>
> --
>       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 at MIT.EDU                        PGP key available
>

-Charles