New split proposition

In this proposition, a transaction always has an amount. This amount is the amount of money that is moved. In other words, it's the sum of debits (which is equal to the sum of credits) in the transaction. This amount is a given value. It is not calculated from the splits. In the context of calculated transactions, it is the result of the calculation.

The splits are divided in two: the credit ("from") splits and the debit ("to") splits. Each split can be either a fixed amount or a percentage. To compute the amount of each split, moneyguru first allocates the fixed amounts. The rest is split between the percentage splits. If the percentages don't add up to 100%, the remaining amount is considered "unassigned". The credit splits and the debit splits are processed independently.

I can't find a completely satisfying solution if the total of fixed amounts is greater than the transaction amount, but I suggest that moneyguru allocates the fixed amounts in the order they appear in the transaction and stops allocating when there is no money left.

When an account name is entered directly in the table, it should create a 100% split. I'm not sure of the behavior we should adopt when more than one account is added, but we probably can find some useful defaults.

It's interesting to note that this proposition makes it possible to mass edit splits.

Modified Proposition

The original proposition for this ticket makes things a little to complex for my own taste, but I'd also like to have an Amount field in the info panel to simplify things a little bit. This ticket, instead of introducing a new notation (percentages) for amount fields in split, would simply define an auto-attribution mechanism when the Amount field is changed. This mechanism would be this one below...

The Amount field would contain the total amount of money moved by the transaction (what it currently shows in the transaction table). For 2-splits transactions, modifying the amount field would be like modifying the amount field in the transaction table: it just changes the 2 splits with the new amount. For transactions with more than 2 splits, it would consider the 2 first splits as the "variable" splits. Subsequent splits are considered as invariant, and moneyGuru simply balances the 2 variable splits so that the new amounts fits (note that if the 2 first splits are on the same side, moneyGuru must, of course, the first 2 splits that are not on the same side).

When the splits are edited, transaction balancing tries to preserve the value of the Amount field. For example, if the amount of a transaction is 100$ and that a 3rd split of 10$ is added, rather than adding a new unassigned split for 10$ (what happens now), the "main splits" are re-balanced to fit the 100 amount.

One exception to that is transactions involving more than one currencies. The Amount field would show what the transaction currently shows (a "natified" amount), but the field would be read-only, and a label would explain that multi-currency transactions must be edited through the split table.

Moreover, the transaction info panel would be split in 2 tabs, the split table going in a separate view (there's going to be a 3rd tab with #19 Note field for transactions/accounts). The split tab would also contain an Amount field, allowing the user to directly see the effect changing the Amount field has on the splits.