Right now, when in multi-line mode, the register uses the first line
to represent the "balancing split", the one that applies to the
current account. I think this is probably wrong, or at least needs to
be changed somehow. Here's why.
(Please consider this carefully before just responding based on an
initial dislike of the complexity of the solution. I believe there's
a deep-ish problem here with multi-split transactions that may be
hard to solve in any "naively appealing" way. However, if there is a
naive solution that does TRT, then great.)
Pretend you make a deposit, three checks, all from the same source,
and all going to settle up your asset:my-loans account.[1] That might
look like this from your checking account:
2000-03-04 | |Deposit |checking |n| 200.00| | 200.00
| |good stuff |asset:my-loans | | | 50.00|
| |bad stuff |asset:my-loans | | | 25.00|
| |other stuff |asset:my-loans | | | 125.00|
Now this looks fine from the checking account, but it's going to look
really horrible from asset:my-loans. That's because it'll show up as
three separate transactions there.
[1] Lest you remain unconvinced later that this sort of thing is
likely, imagine other examples like paying for a car with two
checks, or two people, whose accounts are part of the same account
group (like you and your SO) paying for dinner with two checks, so
that you have a check from checking-a, a check from checking-b,
food, and taxes as your splits.
The fact that this transaction shows up three times in asset:my-loans
is an artifact of the "guessing" we do right now that's intended to
try and show a naive user what they "usually" expect. Right now, when
generating the register display, we scan the splits and for each split
that we find that refers to the current account, we generate a
transaction in the register that doesn't include that split as a split
line, but uses its value as the transaction line value.
Unfortunately, this heuristic falls on its face in the example above,
and is also a problem when trying to represent stock splits the way
Linas has suggested (and I agree) is the best approach.
So how do we fix this? Well, for multi-line registers one solution
would be to just show all the splits, dumping the heuristic, and just
make sure to only show each transaction once. This would be more like
a "general ledger". So the previous example would look like this from
the checking account.
2000-03-04 | |Deposit | |n| 200.00| | 200.00
| | |checking | | 200.00| |
| |good stuff |asset:my-loans | | | 50.00|
| |bad stuff |asset:my-loans | | | 25.00|
| |other stuff |asset:my-loans | | | 125.00|
where the transaction line *only* contains information related to the
transaction, not any individual split information.
And the transaction would look something like this from the
asset:my-loans account:
2000-03-04 | |Deposit | |n| | 200.00| -200.00
| | |checking | | | 200.00|
| |good stuff |asset:my-loans | | 50.00| |
| |bad stuff |asset:my-loans | | 25.00| |
| |other stuff |asset:my-loans | | 125.00| |
Though this seems less "intuitive" than our current approach, right
now I can't think of an intuitive approach that's also reasonably
correct.
Of course, the solution above only addresses the display issue. How
you edit one of these things is a trickier matter. For example, in
the above transaction, what happens if you edit the checking split,
say changing it from 200 to 210? Now the transaction is out of
balance, but where do you distribute the extra value? After some
thinking (and some discussions with Bill, Dave, Linas, etc.), I think
that although in many, like where there's only one other split, you
can apply a heuristic, in the general case, you have to pop up a
window (or whatever) and allow the user to distribute the outstanding
balance. Something like this:
You have unbalanced this transaction.
Please distribute the "unaccounted for" total:
checking 210.00
asset:my-loans -50.00
asset:my-loans -25.00
asset:my-loans -125.00
-----------------------
Unaccounted for: 10.00
<OK>
In cases where there are only two splits, you won't need this, but in
all others, strictly speaking, you do.
(Word of warning about any considering suggesting a more "automatic"
approach: I recall that quicken used to handle this problem in a much
more aggravating (to me) way. They'd automatically try and
distribute the total, and 5 times out of 7, they didn't do what I
wanted. Sometimes they'd adjust the transaction total to compensate,
sometimes a split, and sometimes they'd put the balance at the bottom
in the "blank split". I never did really figure out what the
algorithm was, though I didn't try very hard. I can recall many
bouts of financial "whack-a-mole" as I changed one thing only to have
quicken "help me" by changing something else, that wasn't supposed to
change, to compensate.)
Another advantage to exposing the currently hidden split, is that it
allows us to make a cleaner separation between the data associated
with the transaction and the data associated with the splits. For
example, then it's clear where a transaction memo field, or a
transaction "action" field (which I think we probably need, but more
on that in another message) would go.
So you could have
DATE NUM T-ACTION DESCRIPTION MEMO TOTAL-DEBIT TOTAL-CREDIT BALANCE
S-ACTION TRANSFER-FIELD MEMO DEBIT CREDIT
S-ACTION TRANSFER-FIELD MEMO DEBIT CREDIT
S-ACTION TRANSFER-FIELD MEMO DEBIT CREDIT
or similar. Here T-ACTION is the action associated with the
transaction, and S-ACTION is the action associated with the split.
How would this affect the single and double line modes? Well, for
simple transactions, ones that only use two splits, I suppose we could
use the old heuristic and display things the way people expect, though
I'd still like change some fields, which, as I mentioned, I'll justify
shortly.
For double-line:
DATE NUM T-ACTION DESCRIPTION T-MEMO TOTAL-DEBIT TOTAL-CREDIT BALANCE
S-ACTION TRANSFER-FIELD S-MEMO DEBIT CREDIT
For single-line:
DATE NUM T-ACTION DESCRIPTION T-MEMO TOTAL-DEBIT TOTAL-CREDIT BALANCE
For cases where there are multiple splits referring to the account
associated with the current register, in single line mode, the
transaction line would just be a summary of all the splits referring
to the current account.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
