New register action: forward the current transaction.

[Edward J. Huff]

I am about to implement a "Forward Transaction" command 
in the split register.  I hope you would incorporate it,
but I'm doing it because I want to have it myself.  

The name comes by analogy to "Reverse Transaction":  the
new transaction will reverse the effect on the account
of the original, but the amount is not returned where it
came from.  Instead it is forwarded to a different account.

First, I explain what I need it for.

I have a "gross receipts" asset account to which I 
debit parking rent checks as they arrive, and a quarterly 
report which (will) calculate a gross receipts tax based 
on debits to that account.  I record the check number, 
date on the check, amount, maker, and memo in the "Gross 
Receipts" ledger, credited to the customer's accrued
rent income account.  I really don't want to type this
data more than once.

Ok, now I want to mail in the deposit.  I need to debit
checking and credit Gross Receipts with the total amount, 
and I need to print out a deposit slip listing all of the 
checks with all of the details.  This is somewhat painful 
to accomplish with GnuCash now (cvs HEAD), but it does work.

I made a giant split transaction with all the splits 
crediting Gross Receipts except for one which makes a 
balancing debit to checking.  I put the customer's 
check number in the "action" field, the customer's 
check date and name in the "memo" field, Gross Receipts 
in the account, and the check amount in the credit field.

In "simple ledger" mode the account window has what I would
call a bug:  it shows each split as a separate transaction
in the ledger, but when you click on the "split" toolbar
button, every one of those transactions seems to contain
all of the other splits.  The impression is that there are
N copies of the transaction, each with all the splits in
it.  I think "simple ledger" should never show any given
transaction more than once.  The debit field should show
the total of all debits to the displayed account, the
credit field should show the total of all credits to the 
displayed account, and the account field should be "split
transaction." 

Getting the splits in the order I wanted was not easy since
I didn't notice that planning ahead was essential for that.
Also it is easy to get the split moved to the top if you
forget to put a value in the credit field before clicking
somewhere else to copy data.  So I made a bunch of
splits with the credit field already filled in so they 
wouldn't move.  At the end, I had a bunch of blank splits 
I wanted to delete, so I selected the split, clicked delete, 
answered the dialog, selected the next split, clicked delete, 
answered the dialog, clicked delete, answered the dialog... 
oops!!  I deleted the whole transaction.  So I got to do it 
twice.  (There ought to be a small change which would make
that less likely ... but I don't know what it would be).

I used the single transaction report to print the deposit
slip.  There is something wrong with that report.  It
reports a nonzero "net change" for which I see no cause.
For today, I fixed it by editing the html and printing it 
from Mozilla, but I plan to investigate.

To make it easier next time, I plan to implement a "forward"
command which will let me create the deposit transaction with
one or two keystrokes per check (using a menu accelerator key).

It will work like this.  First I create the empty deposit
transaction, with date, description "deposit to checking 
acct #...," account "a:c:checking," and an amount in the
debit field.  Then I do "cut transaction."

Next, I repeatedly select one of the checks (the transaction
from a:c:accrued:customer to a:c:gross receipts), do a
forward transaction command (with one keystroke), and if
necessary, press the down arrow to get to the next check, etc.

At the end, I go to the blank transaction and do "paste 
transaction."  The result will be the giant split transaction
described above.

Each "forward transaction" command results in the addition
of one split to the "copied transaction."  The account field
is always the current account of the register.  The amount
is the negative of the amount of the selected transaction.
The "action," "memo," and "reconciled" fields are filled in
as specified in the "forward transaction preferences" tab
of the global preferences, using data from the selected 
transaction.


-------------------------
Here is an earlier idea, in which I would be
creating separate deposit transactions for each check.
That has the disadvantage of not matching the bank's
version of the checking account.  

/*
Forward the current transaction, i.e., create a new
transaction which in a sense reverses the current
transaction: the amount debited (credited) to the current
account by the current transaction is credited (debited)
by a new transaction.  However, the amount is not
returned where it came from, but instead is sent on to an
account specified by the last transaction which was
copied using the "Copy Transaction" command.

There must be a copied transaction, and the current
transaction must be already saved.

Some fields of the new transaction derive from the copied
transaction, specifically, the date, number (incremented
if numeric), and all splits whose account field does not
specify the current account.  The action, memo, and
account fields of those splits are copied.  The amount
fields of the splits, and all other fields of the copied
transaction, are ignored.

The rest of the data of the new transaction derive from
the current transaction.  The new description comprises
the date, number, and description from the current
transaction.  The date is formatted according to the
global preferences, and is stored as text in the
description field, followed by the number and
description.  The "notes" field is carried over to the
new transaction.

The action, memo, and amount fields of the "native" split
of the new transaction derive from the "native" split of
the current transaction, except the sign is reversed.
All other data from the current transaction are ignored.

Finally, the transaction is balanced by adjusting the
amount field of the second split.

The next transaction after the current transaction will
be selected.  The new transaction will not necessarily be
visible.
*/