Stefano, thanks for your reply. Proposed setup seems to be pretty-much "standard" for this kind of situation. Unfortunately it has some problems (i.e. things that I had referred to as "quircks" and "workarounds" in starting post of this thread) which make it not that perfect for the task. On the other hand I don't know any other way that would be noticeably better
.
So, what are the problems with proposed setup:
1. It makes it hard to quickly answer the main everyday's question: "how much money can I spend at most today if I would need to?"
Answer to this question would be sum of balances left on all "debit" accounts - wallet, debit card (we assume that debit accounts can't have negative balance in normal circumstances) - plus the difference between the credit limit of Tom's credit card and its actual negative balance. There's no such info available on the "Home" screen of MMEx and there are no built-in reports to cover it. Yes it is possible to implement a "user" report to calculate this one but it is a shame that the answer to such an important - I'd say one of the most important questions in personal finances - can't be easily obtained "out of the box".
2. Tom have to produce "fictional" transactions in order to properly track some micro-loans he gives to Jerry. Imagine that Tom had used his credit card to buy groceries both for himself and Jerry. To track that he has to enter two transactions - a withdrawal from CC to the groceries store (Aldi in your example database) for "his" part and a transfer from his CC to account "Jerry" for Jerry's share. It is not convenient but is ok as long as transactions are entered manually. But it is not always the case. Tom's bank might provide him with QIF or CSV files with transactions on a daily or weekly basis. It is really convenient for him as transactions are being entered automagically into MMEx database. The only thing left for him is to review transactions from time to time to make sure everything is fine with automagic. How should he track his groceries purchase for Jerry in this case? Should he manually enter two transactions as you did in the example database? But later on when the real transaction will be fetched into the database from the QIF it would be hard for him to understand the correspondence between two transactions he had entered manually and a real transaction that came from bank's QIF. Basing on my personal experience it might be hard next to impossible to track things like this if you've got 10+ transactions per day. I guess that there are two ways to make tracking things like this more convenient: (a) allow mixed split transactions so one transaction may perform withdrawal to one payee and transfer to another account at the same time or (b) allow to enter deposit transactions to loan-tracking accounts that do not count towards total income figures but still do change the balance of the account they are deposited to. Case (a) is essentially the same as you had done but without splitting real transaction into artificial transactions. Case (b) seems more convenient to me as for the QIF automation case described above Tom would simply add a "granting micro-loan" deposit transaction to the account "Jerry" right at the moment of the actual purchase and he's done. Real CC transaction would appear in his database later on after QIF import without any extra effort.
3. Budgeting. Let's assume that "College Bank" expects repayment of the educational loan to be made in equal quantities (there's a fancy word for this type of loan repayment - annuitant payments), for example $500 per month. Tom is expected to make a payment to loan's account before 10th day of each month and then on 11th day bank processes the payment, withdraw some part of it as a credit interest repayment and rest of the payment counts towards repayment of the loan itself. How should Tom track this keeping in mind that he would also like to do some budgeting? If he would try to use the "reflect what is really happening" approach - a straightforward one - he would enter a transfer transaction from his debit card account to "College Bank" loan account and would set it to category like "Transfer::Loan repayment". But doing so won't be reflected in the budgeting facility of MMEx with default settings. Tom has an option to include transfers into budgeting totals but there's another catch here. If he would specify "Transfer::Loan repayment" as a withdrawal in budget with expected amount equal to 500 then it would make MMEx budgeting to treat this transfer as a withdrawal - which is correct - but it will treat the status for this line in reverse. "Green check" will be displayed even if Tom hadn't performed the payment at all but if Tom would decide that he want's to do an an over $500 payment to the loan account to make full repayment come faster - it would highlight this budget line with a "red cross" due to withdraw amount being greater than expected $500. Second approach to tracking this one would be to treat transfer as two separate transactions: a withdrawal from the debit card account ("Transfer::Departure from the debit account") and a deposit to the loan account ("Transfer::Arrival to the loan account"). This way Tom do not need to enable including transfers into budgeting totals and he can budget on "Transfer::Arrival to the loan account" as a deposit with expected minimum of $500. Paying less than $500 would highlight this line with a "red cross". Payment bigger than $500 will receive "green check" as expected. But the disadvantage here would be that income/expense numbers would be "inflated", i.e. both would be higher that the real value by the amount of loan payments done during budgeting period. Thinking about this one it seems that possible fix would be to implement more flexible budgeting rules like allowing to define conditions for both withdrawals and deposits for determining the status for this particular budget line. For example Tom might want to define that "Transfer::Loan repayment" is a withdrawal with expected minimum monthly amount of $500 and maximum monthly amount of $1000. Either minimum or maximum or both conditions should be defined for budget line to have a status. Another approach is the same as (b) from pt.2. Tom might track this transfer as a pair of withdrawal/deposit transactions and would like to set "ignore when calculating totals for income/expense for budgets and reports" flag so he would still be able to see non-inflated numbers on homepage, reports and budgeting.
Probably there are more quirks and limitations but IMHO three point listed above are enough to start a discussion. Sorry for a wall of text but the subject is a complicated one with a tricky corner cases so extra details might be for the best.
Fixed some spelling mistakes.