On Wed, 17 May 2000, Rob Browning wrote:
> 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.
I think that that is the mistake. It is ONE TRANSACTION. When displaying a
transaction we should show each of the JEs and sort them so that those
applying to the current account are sorted first.
If you collapse the transaction, then all JEs applying to the same account
should appear as a single total.
>
> [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.
I would drop the separate line for the transaction and just show the JEs.
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|
> And the transaction would look something like this from the
> asset:my-loans account:
2000-03-04 | |good stuff |asset:my-loans |n| 50.00| | -50.00
| |bad stuff |asset:my-loans | | 25.00| | -75.00
| |other stuff |asset:my-loans | | 125.00| | -200.00
| | |checking | | | 200.00|
> What happens if you edit the checking split?
I would ALWAYS make data entry a multi-line mode.
When you make any entry in the amount columns, the system would automatically
add another JE which balances the transaction. To complete the transaction, I
simply enter the account to which it gets posted. If I edit an amount, the
balancing JE is adjusted/created.
Provide a "button" that adjusts the "total" (the first line of the transaction
which is always "this account") and removes the need for a balancing entry.
While a transaction is being edited, always provide an extra JE line which
does not have any account.