Bulk transaction mover (was: question about importing .qif files)

[Christopher Browne]

On Mon, 24 Jul 2000 23:46:47 -0400, the world broke into rejoicing as
Jason Rennie <jrennie@ai.mit.edu>  said:
> gjditchfield@acm.org said:
> > This sounds like a restricted sort of "find and replace" operation.
> > It would be a handy thing to have on its own, not just as a part of a
> > QIF importer.  Some day I may want to go into "expenses:misc" and move
> > all of the transactions with "Library" memos to a new "library fines"
> > account. 
> 
> I'd definitely like to see more ways to move/edit large numbers of
> transactions.  e.g. split transactions from one account into two based on
> memo and/or description fields, move a top-level account to be a 
> sub-account of another account, un-reconcile all transactions before
> MM/DD/YY, move all transactions in this account to another account, etc.

It sounds like the world "needs" some form of "transaction filter."

That is, a mechanism whereby you walk through a set of transactions,
with a function that evaluates the contents of each transaction,
transforming it into another transaction as needed.

So, supposing we want to take all transactions that we hit, and
those with a description of "Bank of America" should have the
memo field set to "ATM Withdrawal".

Define functions:
(define (myselection-criteria txn)
   (string=? (gnc:transaction-get-description txn)
             "Bank of America")))

(define (my-update txn)
    (gnc:transaction-set-memo txn "ATM Withdrawal"))

And then walk a transaction tree, applying these, something 
somewhat like:

(define (do-to-all-txns account criteria update)
   (define (thunk txn)
      (if (criteria txn)
         (update txn)))
   (gnc:account-staged-transaction-traveral account #f thunk))
;;; I'm quite sure I'm abusing the transaction traversal...

Anyhoo, the bigger point is that by having some functions inside
that know how to "walk" a tree of transactions, and "do stuff
to them," that is the basic tool to do transaction filtering.

Given that basic tool, there may be _all sorts_ of cool sorts of
filters, and for those that are common, we might build GUIs for
them.

Net result:

There are _two_ things to hash over:

1.  What are good ways of walking across the transactions
    and "doing stuff to them"?

      There may be opportunities for parallelism; rather than
      just evaluating _one_ filter, it might be a good idea to
      have a whole list of them, and evaluate them all at once.

	(define (do-multiple-things-to-all-txns account list-of-actions)
	   (define (thunk-actual txn action-list)
	   ;;; Function that walks through a list of actions looking like
	   ;;; ((match1? action1) (match2? action2) (match3? action3))
	   ;;; and applies all the relevant ones to the transaction...
	     (if actionlist
	       (begin
		(if ((car (car action-list)) txn)
		  ((cdr (car action-list)) txn))
		(thunk-actual txn (cdr action-list)))))
	   (define (thunk txn)
	      ;;; Wrapper for thunk-actual
	      (thunk-actual txn list-of-actions))
	   (gnc:account-staged-transaction-traveral account #f thunk))

2.  Which of those "walks" are worthy of trying to build a GUI
    in order to make them usable to non-Scheme-gurus?

    We can come up with filters more complex than we can make GUIs
    for, but there surely should be some that are worthy of a GUI.

The approach here is to first ask "What abstractions do we need to
do filtering?"

Then, given something sufficiently expressive to cover the cases 
we'd like to cover, it may be time to try to implement and make it
"gooey."

If the set of transactions about to be added to the system are
set up as transactions that aren't rooted in the main body, that
could mean that lots of the QIF import functionality could be
transformed into filters.  

Does that make sense?
--
aa454@freenet.carleton.ca - <http://www.ntlug.org/~cbbrowne/lsf.html>
"... While programs written for Sun machines won't run unmodified on
Intel-based computers, Sun said the two packages will be completely
compatible and that software companies can convert a program from one
system to the other through a fairly straightforward and automated
process known as ``recompiling.''" -- San Jose Mercury News