GNOME Bugzilla – Bug 338604
'Complex' split transaction misunderstood by cash flow report
Last modified: 2018-06-29 21:01:38 UTC
'Complex' split transaction are misunderstood by cash flows report Seen in 1.8.10 and in 1.9.4 on a Debian testing. Best demonstrated by an example easy to reproduce : Example of split transaction : Debit Credit 4/13/06 Achats K-Rouf Expenses:E1 31.45 Expenses:E2 2.09 Assets:A1 13.54 Assets:A2 20 Corresponding Cash Flow report : Cash Flow - 04/10/06 to 04/15/06 for Selected Accounts Assets:A1 Money into selected accounts comes from Assets:A2 EUR 20.00 1/ this is WRONG, no money goes from "Assets:A2" to "Assets:A1" 2 payment methods have been used simultaneously for this transaction 2/ the question raises : how much of the 13.54 should go to "Expenses:E1" and "Expenses:E2" ? I suggest to use the proportion of the contribution. For example here : Money out of selected accounts goes to Expenses:E1 EUR 31.45*13.54/(13.54+20)=12.7 instead of 31.45 Expenses:E2 EUR 2.09*13.54/(13.54+20)=0.84 instead of 2.09 There is the same problem for the "Assets:A1" account. For Expenses account, it is better, because it chooses A2. But it should select from A1 and A2 it proportion to (31.45+2.09) (symmetrical behaviour)
Bug present in version 1.9.7 too
Bug present in version 1.9.8 too
Bug present in version 2.0.0 also
Created attachment 85658 [details] gnucash file I think I am having this same problem. Although I am convinced this problem must be resolved, I do not agree with your proposed solution. Your solution suggests something that could not be the truth. Why only select two out of the three possible accounts for the partioning of the money? I think it would be better to introduce a dummy account in the report ("Unknown", or "Split" or something like that). An enhancement to this solution could be to introduce several dummy accounts in the report and (at the end of the report) summarize what accounts are involved in each of these dummy accounts. The problem I have seen is even worse: When I make the cash flow report and only choose one account (in the attachment it is the account "suspense"), the totals do not match te actual amounts: Account suspense is only 100 in and 100 out. But the report also counts the other splits and reports 800. This makes this report useless. Carl van Denzen.
Good to know that for someone else, the report as it is now is wrong. Carl, I selected only 2 accounts for partitionning the money because in my example, only 2 accounts have been debited. Of course I could write another example like this : Debit Credit 4/13/06 Achats K-Rouf Expenses:E1 2 Expenses:E2 2 Assets:A1 5 Assets:A2 1 In this case, the 5 would be partioned between 3 accounts. But in a more general example, the sum of the credits (C=sum(ci)) is partitioned in different debits (D=sum(di)), with C=D. There is no "truth" in the case of a single split transaction, no notion of "this credit #2 contributes to debit #3". If there was, then one should have used a different transaction. There is only a contribution of each debit/credit to the amount (C=D), that _is_ proportional. This justifies my suggestion to use the formula : contrib(account i in cashflows of account i0 for transaction T) = if (i and i0 have the same type debit/credit , 0, contrib(i for T) * contrib(i0 for T) / sum(contrib(j),account j with j and i0 same type debit/credit) ) Yes we could use special account in the reports, but if the account has a large number of split transaction, it does not gives any information. My proposal is informational and intuitive. I think the problem you talk at the end of your message is related to this one, ie it would be solved if this one is solved. Laurent
*** This bug has been marked as a duplicate of bug 622778 ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=338604. Please update any external references or bookmarks.