Import transactions change proposal

[Chris Morgan]

---- Original message ----
>Date: 04 Feb 2003 13:29:48 -0500
>From: Derek Atkins <warlord at mit.edu>  
>Subject: Re: Import transactions change proposal  
>To: cmorgan at alum.wpi.edu
>Cc: Benoit Grégoire <bock at step.polymtl.ca>,
gnucash-devel at lists.gnucash.org
>
>Chris Morgan <chrismorgan at rcn.com> writes:
>
>> Of course, to recap the prior thread and the start of this one
>> the goal is to be able to move multiple transactions into an
>> account with a single move either based on clicking or a
>> keyword search.
>
>Ok: show of hands..  How many people really think they need this
>feature?  I don't think I'd use it/want it.  I would
CERTAINLY use the
>"re-run the automatcher at every change" features.
>

I'm skeptical of the quality of the auto matcher, both as a
user and a developer.  I suppose I still like the idea of
being able to manually identify and move transactions if I
choose to.  I'm ok with not going this route right now but I
do think users will find it useful.

>I admit the importer still needs some work, but I'm not
convinced that
>we need to deal with multiple transactions at once.  For one
thing,
>the rest of the code doesn't deal with it, yet, either.  If
you want
>to handle multiple transactions, may I suggest you get the
register to
>handle operations on multiple transactions?
>
>> I'd rather not force the auto sorter on anyone, giving them a
>> choice between manual and automatic seems like a good decision.
>
>The auto-sorter is already "forced" on everyone.  The only
problem is
>that it's not iterative within an import process.  Try
splitting up
>your OFX import into a number of smaller imports and you'll
see what I
>mean.  Similar transactions in "future" imports are all handled
>automagically.
>
>Also, as Benoit has said, there are a number of choices to be
made on
>a per-transaction basis.  I don't know how you plan to
support on that.
>

This one is pretty simple.  If you have multiple transactions
selected and want to process them in a batch then you'll have
to settle for having each choice made apply to the entire
batch.  I don't think this is an unreasonable requirement.


>May I recomend that you first work on the iterative
account-matching
>and then, after that's done, you look at other multiple selection
>processing?  I think you'll find that the iterative
processing will
>remove a vast majority of issues you have with the importer.
 So, why
>don't you do that first and then we'll see.  Might as well
spend your
>time on something that everyone agrees needs to be
implemented, no?
>

I wouldn't mind working on the interative processing of the
transaction list.  I'm at a loss as to how this would be
implemented.  Is is as simple as just calling the auto matcher
routine after any transaction has been assigned to an account?

Chris