---- Original message ---- >Date: 04 Feb 2003 13:29:48 -0500 >From: Derek Atkins <[EMAIL PROTECTED]> >Subject: Re: Import transactions change proposal >To: [EMAIL PROTECTED] >Cc: Benoit Grégoire <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > >Chris Morgan <[EMAIL PROTECTED]> 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
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
