GNOME Bugzilla – Bug 722140
Cash flow report mishandling split transactions
Last modified: 2018-06-29 23:24:45 UTC
The cash flow report is mishandling split transactions. This appears to be a new issue in GnuCash 2.6.0 - downgrading to 2.4.13 has resolved the issue. As an example, I set up the following transaction in my Checking Account: a cheque for £1,500, which covered payments totalling £1,700 across two categories of expenditure, with a contra of £200 against one category of income (this type of transaction is quite common - I am preparing the accounts for our church, which submits a single cheque to our central office covering the balance of various expenditure and income items). The transaction appears as follows in its entry in the Checking Account: Expenses:Expense type 1 1,000.00 Expenses:Expense type 2 700.00 Assets:Checking Account 1,500.00 Income:Income type 1 200.00 When I then run a cash flow report for the Checking Account, I would expect the following (and this is what previous versions of GnuCash would have displayed): Money into selected accounts comes from: Income type 1 £200.00 Money In £200.00 ---------------------------------------- Money out of selected accounts goes to: Expense type 1 £1,000.00 Expense type 2 £700.00 Money Out £1,700.00 ---------------------------------------- Difference -£1,500.00 Instead, what I am getting is the following: Money into selected accounts comes from: Money In £0.00 ---------------------------------------- Money out of selected accounts goes to: Expense type 1 £882.35 Expense type 2 £617.65 Money Out £1,500.00 ---------------------------------------- Difference -£1,500.00 In other words, the cash flow report is ignoring the income item and is then pro rata-ing down the expense items to total the overall figure. I can confirm that downgrading to GnuCash 2.4.13 resolves this bug.
The behaviour that you experience is a consequence of the fix for Bug 622778 - Miscalculation in cashflow reports which was released with GnuCash 2.6.0. - and it is correct behaviour. With this fix it becomes more important to model the "physical" flow of money. The problem is that the "physical flow" of the 200 from the income account is unspecified in the transaction that you describe. I hope it becomes more clear if you try to look at this transaction from the expense accounts. When you go to one of the expense accounts and open the transaction in split view you will see exactly the same splits. From there you cannot determine whether the 200 really come from the checking account or directly from the income account. Neither it is possible to say how much of the 200 was used for one of the expenses. The CashFlow report is facing the same problem. It can safely determine that 1500 have left the checking account, but it cannot be sure that the 200 are really targeting the checking account. That is why it is ignored. If it does not ignore it then it will have the problem as reported in Bug 622778. You state that this transaction is quite common, but I guess it is a church internal booking procedure, and this scenario would not appear with external bank traffic. I am afraid, in GnuCash you have to enter two distinct transactions. One for 200 coming into the checking account, and one for 1700 leaving the checking account with 1000 going into one and 700 into the other expense account.
Thank you for this prompt and detailed response. I have read the thread on bug 622778 and see what the problem was. However, I would suggest that the solution implemented in 2.6.0 (to solve a situation where the same expense is met by multiple payments from different sources) just creates an equal and opposite problem on the other side of the ledger (where the same payment is covering a number of different transactions). I also realise I made a tactical error in mentioning that this was for our church's accounts, as it may have created the impression that I was describing an idiosyncratic situation applicable in narrow circumstances. In fact, the scenario I am describing - where sale and purchase transactions are contra'd against each other and a net amount paid to cover the balance - is *extremely common* in business settings. Recording such a transaction as two separate transactions in GnuCash (one to deal with the credits, the other to deal with the debits) is possible, but highly counterintuitive and likely to lead to some strained conversations with a confused auditor after our financial year end. In the scenario described in bug 622778 - where (say) a £1,500 expenditure is paid £500 by cheque, £1,000 by credit card - I can see how it was clearly a bug in 2.4 for a cash flow report on the bank account to attribute the whole £1,500 to the bank account. However, the assumption that the way to deal with this /must/ be to split the expenditure proportionately, while it may make sense in the 622778 scenario, is unwarranted and leads to problems in other scenarios - such as that described in this report. I suggest that a better analysis of the 622778 scenario is that the cash flow from the point of view of the bank account is: £1,500 expenditure + (£500) credit card = £1,000 net cash flow from the bank account. This then leaves the user to decide whether to offset the £1,500 and £500 to give the "proportion" of the expenditure that comes from the current account - and if they wish to do that, then that is a manual adjustment they will have to make for themselves. However, the result still addresses the bug in 622778, without creating new problems for the mirror image transactions that I'm now having difficulties with.
(In reply to comment #2) > However, I would suggest that the solution implemented in 2.6.0 (...) just > creates an equal and opposite problem on the other side of the ledger (...). This point I don't get. > I also realise I made a tactical error in mentioning that this was for our > church's accounts Not really, I won't nail you down on this :-) > In fact, the scenario (...) is *extremely common* in business settings. Hard to judge on my end. This might be business and country specific. > Recording such a transaction as two separate transactions is possible, > but highly counterintuitive and likely to lead to some > strained conversations with a confused auditor after our financial year end. This point I do not get, either. What can be clearer than distinct transactions? For me the question is whether the 200 from your scenario have ever been part of your assets at any time. So if this was a taxable item, I would not know if this should be taxed on the sending or receiving side or both. > I suggest that a better analysis of the 622778 scenario is that the cash flow > from the point of view of the bank account is: £1,500 expenditure + (£500) > credit card = £1,000 net cash flow from the bank account. You mean backward calculation of the amount that has already been entered in the account that you would like to create the cash flow report for? I would not recommend that. And in your scenario this would mean 1700 expenditure + (200) income = 1500 net cash flow? Isn't this just what it reports today? Again I might miss your point here ... > This then leaves the user to decide whether to offset the £1,500 and £500 to > give the "proportion" of the expenditure that comes from the current account > - and if they wish to do that, then that is a manual adjustment they will > have to make for themselves. Not understanding the previous point, chances are low to get this point (it sounds like you would like others to accept what you don't like to accept yourself). > However, the result still addresses the bug in 622778, without creating new > problems for the mirror image transactions that I'm now having difficulties > with. I better stop here. Obviously I am not the right person to follow up on this issue. The only constructive hint that I can give is that you might want to copy over the old cashflow report scheme file from GnuCash 2.4 to some dedicated place on the disc and link it into GnuCash 2.6 as customized report. Doing this keeps this linked into your setup even if you upgrade/update GnuCash with future releases. The way to do this is described in http://wiki.gnucash.org/wiki/Custom_Reports#Load_the_report_from_a_user_account Some minor changes are needed to get this working in the scheme file, you cannot use a plain copy. If you need help with this I can try to assist you especially if you are on Linux (as I don't have any Windows machines, assisting for Windows might become difficult).
Hi, thanks for your patience and for your detailed response. Excellent suggestion re setting up the old cashflow report as a custom report in GnuCash 2.6. I'll let you know if I have any difficulties (I use Linux), though the instructions look pretty clear. Happy for this bug report to be closed.
Hello, I seem to be having the same issue, but I guess I still don't understand why this is not being considered a bug. From my perspective, the cash flow report in 2.6.2 (for which I attempted to upgrade from 2.4.13) is incorrect. Using the above example, there is a flow of cash on the Income:Income type 1 account that is not being reported directly but somehow it is ok to spread it across two expense accounts? I just don't see that. The purpose of the cash flow report is to show directly the total of all individual transactions against individual accounts for which the new report does not show. Tim
(In reply to comment #6) Hi Tim, the purpose of the cashflow is to show the flow in and out of selected accounts. In the above example, the selected account is the Checking Account. If you open the Checking Account directly you will see that the transaction line will only show a withdrawal of 1500. There is no deposit of 200. Which means that there is in fact no flow into the account, there is only a flow out of the account. And that is exactly what the report is showing. Again: The transaction in the example above is ambiguous and a transaction with more then two splits does not define a flow. It does not mean that there is a flow from the Income Account into the Checking Account. E.g. it could also mean that first 1500 have been transferred to the Income account, and from there a total of 1700 have been transferred to the expenses ... unlikely, but not excluded when just looking at the transaction.
Hi Carsten, First, please believe that I am trying to understand your point of view, but I am still not seeing it from your perspective. I guess I am wondering if we are arguing semantics here. Here is an assumption that I am making which maybe is the issue. Any transaction is a summation of flows between accounts. When I look at the above transaction, I see two flows out of the account and one flow into the account which again I see as a valid summation of possible flows. When I view the transaction split from the checking account, I see the two flows out as well as the flow in (from Income Type 1). When I view the $1000.00 transaction from the Expense type 1 account, I can see the exact same breakdown as from the Checking account meaning I still see that $200.00 of income coming from Income type 1. Again, a summation of both flows into the transaction as well as flows out. Today, I talked to two different business managers, and they seemed to agree that when you look at the full "cash flow" on the checking account, it should not attempt to spread the income across the expense accounts, but should show the $200.00 in the Money In section because money actually did flow into the checking account from the Income type 1 account (this was corroborated by their Quickbooks). For the sake of argument meaning you are correct, just what stock/standard report would I run to see the $200.00 that did come in under the Income type 1 account?
Hi Tim, no worries, I also had to do a learning curve before I could understand the problem in Bug 622778. In GnuCash a transaction is not a summation of flows, but a grouping of splits. And a split is a withdrawal or deposit that anchors in on dedicated account. I hope you see the difference: For a flow you need two points, a split deals just with a single point. All that the transaction cares about is that the split balance out, i.e. there are as much withdrawals then deposits, it does not care about flows. Maybe this example helps: I just change the above example a bit to Expenses:Expense car 2,000.00 Expenses:income tax 700.00 Assets:Checking Account 1,500.00 Income:Income Gross Salary 1,200.00 What is the flow here? Or maybe this Income:Salary 1 10 Income:Salary 2 10 Asset:Bank 1 20 Asset:Bank 2 20 Asset:Bank 3 20 Asset:Bank 4 20 Expense:Food 10 Expense:Fun 10 Believe it or not, this is a valid transaction because the split balance out. What is the flow for Asset:Bank2 ?
Hi Carsten, Spent some time reading and re-reading so please don't think I am responding in haste. Using your latest example (and assuming you are trying to represent a transaction of $0.00 against some other Asset), the split to me is simple: Bank 2 receives a debit of $20.00 so the report should show that Asset:Bank 2 had $20 reduced and not try to spread that across debit across multiple accounts. I guess I can see the difference as to how you describe a split versus flow, but the semantics don't really change when it comes to cash flow report as I see it. With that, I believe I might see the crux difference in your view versus mine. You seem to state that in essence a single transaction should either have splits out or splits into an asset for the cash flow report to provide an accurate representation of the activity on the account. How close am I? Let me put on my accountant's hat (and note I am not a full-time account but an engineer that plays one for a non-profit group...which could be the problem :-) ) for a moment using the very first example that John gave where a withdrawal against the checking account was made for $1500.00. The resulting report in 2.6 has no real meaning other than the checking account balance was reduced by $1500.00. The numbers being shown that Expense type 1 was reduced by could be or could not be true and this goes to Expense type 2 (as you have stated earlier) so what value does the Cash Flow report bring to the table if it showing me numbers that are arbitrarily calculated to make the transaction balance out from either a debit or credit perspective? The assumption I have always made...and maybe incorrect is that since the Cash Flow report allows me to select which account(s) to use as the source of data, it is basically a subset of the Profit & Loss report. Am I making a false assumption here?
Hi Tim, I think now we are close to getting there. To your first answer "the report should show that Asset:Bank 2 had $20 reduced and not try to spread that across debit across multiple accounts": If you are going that direction than you are not talking about a flow but a balance statement. A cashflow always should have a source and destination.It is not enough for a cashflow to show just the "throughput". The "throughput" (that is my personal term here, don't know if it is a valid financial term) shows how much money has been moved, but does not show from which source to which destination. To your second answer "a single transaction should either have splits out or splits into an asset for the cash flow report to provide an accurate representation of the activity on the account": Hit it. That is what makes up a clean cashflow. Your third point "what value does the Cash Flow report bring to the table if it showing me numbers that are arbitrarily calculated to make the transaction balance out from either a debit or credit perspective?": Well, it is not really arbitrary (the calculation is based on ratios) but I get your point that the figures do not match anything mentioned in the transactions anymore. Yes, you might perceive this as weakness of the cashflow report. But the root cause for this weakness is unclean booking (see comment to your second answer). Alternatively, the cashflow should ignore transaction which are not unambiguous, but I rate this as even more confusing. So the rule is: be careful and clean with multi-split transactions if you want to make use of the cashflow report. To your fourth point "the Cash Flow report ... is basically a subset of the Profit & Loss report": Indeed, that is a false assumption. The Profit&Loss Report deals with "throughput", not with cashflow. It looks only at income accounts for profit, and only on expense accounts for loss, without any source/destination relationship. After all I get the impression that you are not exactly after the cashflow, but rather looking for a summary of throughput of asset accounts (which are not covered by e.g. the Profit&Loss Report). Did you try the Transaction Report already? (Reports->Transaction Report) Try running it with only the desired asset account selected (Accounts Tab), the "Secondary Subtotal for Date Key" set to "None" (Sorting Tab), the preferred time period (General Tab), and the "Other Account Name" option checked (Display Tab).
Hi Carsten, I do believe we have hit the fundamental issue, and that is what you are calling a "clean cashflow". I believe what you are describing is fundamentally a false assumption meaning a transaction should either have flow into an account or flow out. Here is an example from my experiences: I have income to deposit from a sporting event, the deposit if for $500.00. Now that $500.00 is actually a summation from three accounts: Income:Sports:Raffle -> $300.00 Income:Sports:Concessions -> $200.00 Income:Sports:Admission -> $100.00 But I also had to make a payout in cash for the referees that evening for $100.00: Expense:Sports:Referee -> $100.00 Now when I go to the bank to make the deposit, I have only $500.00 and the deposit slip will show $500.00. But, if I understand you correctly, I will have to actually make two transactions at the bank where I withdrawal $100.00 from the checking account and then make a deposit for $600.00 just to make the Cash Flow report happy. Or are you telling me that I should make the $500.00 deposit, then create a second transaction in the software for $100.00 expense and finally a third $100.00 transaction to represent the full income? The first case is burden to impose on the user at the time of the deposit for obvious reason, and the second is a nightmare when it comes to reconciling the account because there will be transactions in the software that don't appear to be on the bank statement. In the end, the restriction being placed now on the transaction meaning it can only hold flows into OR out of an account is a step backwards from the 2.4 version. When I look at the original bug, I believe the that it is actually a "user error" in that when they go to run a Cash Flow report on the checking account that they really needed to include to the credit account as well since there was money flowing between those two accounts to comprise the full amounts.
Hi Tim, to cut long a long answer short, please take a look that following two attachments (see next two comments).
Created attachment 272182 [details] gnucash file for sporting event transactions - version 1 This is a gnucash file showing the transactions from the sporting event as I think you would like to record them.
Created attachment 272183 [details] gnucash file for sporting event transactions - version 2 In this gnucash file I entered the transaction as I think they should be entered - here the cashflow shows the result as you would like to see it, at least that is what I guess.
Hi Carsten, Before I comment any further, may I assume that the Cash Box asset could very easily be the Checking account from my example? Tim
Hmmm, actually not. I was understanding that you had a "cash box" during the sporting event where you collected all cash from the event, and out of which the payment for the referee was taken. And there is only one "real" bank account where you deposit the remaining 500 after the event. So the cash box is just a helper account in GnuCash, modeling the real cash box from the event. Sorry if I was not reading closely enough.
Created attachment 272397 [details] reconcile window
What we can do for the sake of my next items, we can exchange "Event Cash Box" with "Checking Account". Now the headache I expected is shown in the attached screen shot. If I were to go and reconcile the "Checking Account", now I have three transactions to reconcile when the banking statement will only show one for $500.00. I know we have gone around and around on this, but by now requiring each transaction to only have money going into or leaving an account has really placed and larger burden on the user in an effort to "fix" the Cash Flow report which I still don't believe was broken in the 2.4 product. To me, this new behavior is not how other accounting packages I have seen works, and after talking with several accounts, the new functionality is not how they would have expected it to work. At this point, since you are the maintainer of the reports, it is your final say, and I will respect that...plus if you are acting on the direction of the maintainers of the full software, you have to do what they request. All I can say is that from a user's perspective, the changes don't appear to be for the better and actually cause a larger burden on the user. I hope you have not taken offense to anything I have said because that was not my intent.
Hi Tim, first let me say that I do not own a special role as maintainer of the reports in this project. Actually, I do not own any role, I just contribute as an ordinary user. Just by the fact that I needed to do some programmings in the report area to make GnuCash fit my personal needs I got to know this part of the software better than the others (up to now). Neither am I an accountant, and in no way any professional in book keeping. All my learnings stem from the GnuCash documentation, bug reports, and Wikipedia. That means: Even though I have a strong opinion in the matter of cash flow reporting because I worked out a patch for the old bug, I am not the one with the final say to reject this bug report and your concerns. One might say: All I do is "not confirm" and trying to explain why I do not confirm. I agree, that most likely neither one of us will convince the other one, and in this respect we are a bit stuck in the discussion. So this should be my last comment: I do not understand - why you consider the Cash Box as a checking account It is meant to be nothing more then a temporary asset used during the sporting event and has a zero balance in the end (and may be reused for the next sporting event). I do not see a need to reconcile it, but if you do it then I would expect it to look exactly like shown in your screenshot. - why you match the Cash Box with the bank statement. It is the "Asset Bank" account in the "version 2" file that matches the bank statement and which should be reconciled. I would welcome if other people step in to maybe shed some more light into this.
Hi Carsten, If you would indulge me just one more time. I have attached a sample file that contains what I would consider a typical transaction for me. It contains a deposit for $400.00 into my checking account. The money came from two areas: Concessions:50-50 (a raffle) for $100.00 and Concessions:Admission for $500.00. Now at the same time I also had to pay out to the referee's $200.00 in cash from the combined $600.00. With version 2.4, how I entered the transaction everything worked as I hoped in that when I would reconcile the account against the bank statement, I had a single deposit on the statement for $400.00 and that is what I would see in the reconcile window of the application. Also, the Cash Flow report when run against the Checking account would show an Expense of $200.00 against the Expense:Sports:Referee and the Income of $100 for the Income:Concessions:50-50 and $500.00 for Income:Concessions:Admission. Would you mind showing me how I will now have to enter that same transaction to have not only the Cash Flow report the income and expenses on the Checking account but also show me the single $400.00 deposit in the reconcile window when reconciling the account. Tim
Created attachment 272540 [details] sample data file
I have been remotely following this discussion as I don't have time to dig in deep and I'm not using this report myself. From a distance it looks to me both of you are defending a slightly different use case of the report. Tim's use worked well in 2.4, while Carsten's use of the report works well since 2.6 and is influenced by a limitation in the old way as reported in bug 62278. I wonder if the report can't be made more flexible to work in both cases. A second suggestion would be to bring this whole issue up on the gnucash-user mailing lists. So far you only have two opinions on the matter. It would help to get input from more people with accounting experience. There are several on the list.
Created attachment 272636 [details] gnucash file for sporting event transactions - version 3 Hi Tim, see attached file. Did you actually try the Transaction Report as mentioned some comments before? I still think that this gives the info you are after, no matter which booking procedure you choose.
Hi Carsten, I tried making the changes to the options on the report, and the report always showed the same results. After looking at your latest example file, I can where you are using the "Cash in Wallet" as an intermediate account to handle the balancing. To me, it just seems far more work than it should be for what I think a normal user would like or would think to do especially since the 2.4 method matches up with far more accounting packages (what was one transaction in the Checking account now requires three and the intermediate Asset account plus still the Checking account). Personally, I would hope we could make the report an either/or approach, but I am NO expert in Guile so I can't offer even a patch to help start the process...if deemed acceptable. At this point, I am thinking that submitting to the mailing list and let the majority rule is best approach (thanks Geert for the suggestion). Thoughts? Tim
I know I'm weighing in late on this one but since this has rendered GnuCash 2.6.X useless to me I have to try. I just built a new computer and installed the latest version of GnuCash from the Ubuntu Software Center (2.6.1). When I did a Cash Flow report a number of my “Categories”/Accounts were producing numbers that made absolutely no sense. I found this thread and read through it and followed up by reading through the thread on Bug 622778. I would also like to point out that I have been using accounting software since Andrew Tobias' Managing Your Money on my Apple IIe, I have used Quicken, Quick Books, MS Money and since 2010 GnuCash, this is the first time I have run into an issue like this. In reading through the thread on Bug 622778 it appears to me that Mezimezim simply either failed to include or failed to exclude an account that he wanted to be either internal or external to the report. A relatively simple example of this is if I make a cash flow report of my portfolio GnuCash 2.4.X would automatically include ALL my asset accounts, when I run the report I can see numerous transactions are missing. ALL my credit card transactions; however all the checks I write from my checking account to the credit card account WILL be in that report, but that's not what I want to see. If I change the options to INCLUDE my credit card account ALL those transactions now show up correctly in their appropriate categories/accounts. The cash flow report treats all accounts INCLUDED in it as internal and all other accounts as external and therefore the “flow” to or from. To get more specific to the issue I'm having with 2.6.X I have to agree entirely with John and Tim but I would like to present a situation that should be more ubiquitous to users who are using GnuCash for their personal finances: a paycheck. When I enter a paycheck it can have several income categories and MANY expense categories. Debit Credit Checking Account $3,475.00 Health Insurance $250.00 Federal Tax $1,500.00 State Tax $375.00 401k Contribution $1,000.00 Professional Dues $150.00 Taxable Income $5,350.00 Per Diem $250.00 Pre-Tax Income $1,150.00 Now I have seven months worth of data similar to this and this is significantly abbreviated. So I am still trying to sort out exactly what 2.6.X is doing wrong, but I know that it is not handling either the Federal or State Taxes correctly in the cash flow report. GnuCash 2.4.X and earlier handled my finances correctly for the past 3 years and every other financial software package prior to that did as well. I know this is just my opinion but I feel the “fix” that was applied to 2.6.X to fix Bug 622778 has ruined GnuCash, at least regarding the cash flow report and I use that report EXTENSIVELY particularly at the end of the year to verify my data entry, prior to producing a TXF report for my accountant. I (with significant help from my son) have reverted back to 2.4.15 and placed it on “hold” so it won't update. Please revisit this issue. I would much prefer to run an updated version, but the current version is unworkable to me.
I do wish there could be some movement on this bug since I can't upgrade to 2.6.x due to this bug. I submitted this bug to the mailing list, but apparently nobody uses the Cash Flow report to represent the data like I believe it can and should.
I don't think there is a bug here. I do see some accounting issues though and that seems to be the basis of the discussion beween Carten and Tim. I am not an accountant. The way I see it is that on the day of the event Tim took $600 in cash and put it somewhere, the cashbox (bag, pocket, whatever). At some point people were paid $100 out of the cashbox. The next day, presumably Tim went to the bank with the cashbox, made a single deposit of $500. One deposit, one transaction, from cashbox to bank. All were simple transaction, no splits required. I see none of the cash transactons anywhere in the sample account provided by Tim.
Created attachment 281947 [details] Simple event cashflow. Simple event account as I would enter it in GnuCash. But note, I am not an accountant.
Hi Mike, Please note that I don't have anything in GC that represents the cash box: I only have checking and savings accounts to balance against. Your system would work moving forward for me, but I don't believe it would work for John and Charles plus it would require more accounting work. Second, I would have major issues if I wanted to look back over the last 6+ years of data because the transactions have been entered "in the old way" meaning there is no backwards compatibility. Third, the fact that the report attempts to "spread" expenses across income points in a single manor is not what most accountants would like (I have discussed with several). I believe the purpose of the Cash Flow is to just show the summation of flows (income and expense). Basically, GC right now acts differently than other major accounting packages in this manor which is just not good in my opinion. For me, the #2 and #3 are the reasons why I can't upgrade at this point.
Hi Tim I appreciate your very valid points and why you cannot upgrade. If I may make a suggestion then as to how to upgrade and continue to use the old cashflow report. I see the bug is for Linux so I'll assume that's your current OS. The report file is (on my Fedora system) at: /usr/share/gnucash/guile-modules/gnucash/report/standard-reports/cash-flow.scm That's the only file that's been changed as far I can tell. Copy that somewhere safe. Then read http://wiki.gnucash.org/wiki/Custom_Reports Using the relevant part of http://wiki.gnucash.org/wiki/Custom_Reports: Copy the old cash-flow.scm into ~/.gnucash, then modify (or add if doesn't exist) ~/.gnucash/config.user by adding the line (load "cash-flow.scm"). If the GUID of the new and old report are the same you will get warnings so you may need to edit your local cash-flow.scm Just changing a single (hex) digit in the report-guid (near the bottom) usually works for me. The report name (near the top) will also have to edited else you'll see two items with the same name in the menu. The only other issue is that future changes to other parts of GnuCash may make that report unuseable. The usual caveats about making backups before you do anything obviously apply. I hope that's of use.
Hi Mike, Not that it matters, but I am running GC on Windows 7. Funny you should suggest the reuse of the cash-flow report from 2.4.x in 2.6.x because that is pretty much what I did to help isolate the issue I saw after the upgrade so having it as a custom report is not a technical issue for me. With that, what concerns me is that I am the treasurer for a non-profit which means I won't be the treasurer much longer due to the by-laws so having someone else have to go through the process of installing the custom report is not a big issue, but an issue none the less. However, the bigger issue I have is that I do believe the fix for Bug 622778 actually goes against general accounting practices as I know them as well as others that I have discussed this with since I am not an account by trade. I do believe that the behavior in 2.4.x is correct the behavior in 2.6.3 and earlier is incorrect. The submitter of Bug 622778 actually needed a custom report to give him the behavior he desired.
In which case I'll mark the OS as ALL, version = master and bow out, as I do not know enough accounting to contribute further.
Hello Tim, Thank you for your support. Once again I agree with you entirely, the way 2.4.X and prior works, is the way all other accounting software works and is the way most of us who have used accounting software for many years expect it to work. I will continue to monitor the discussion but am losing hope that this issue will be resolved satisfactorily (or at least to our satisfaction). I guess we'll just have to continue using 2.4.X. Good luck.
I have finally found the time to wade through the discussion and try to understand all points of view. I believe that John, Tim and Charles are correct and that the cash flow report is misbehaving in GnuCash 2.6.x. I agree with Charles in comment 26 that bug 622778 is not actually representing a bug but a misunderstanding of how a cash flow report actually works. And I think the motivations in that bug by Mezimezim and Fiable.biz have lead to a wrong interpretation of splits vs flows by Carsten. A single split indeed can't represent a flow. But a split is never alone, it's always part of exactly one transaction. This transaction defines one or more flows depending on the number of splits. Again Charles explains this prettly clearly in comment 26: in a cash flow report you divide accounts in "internal" and "external". Then for each transaction with at least one split in the "internal" group, you report all the splits that are in the "external" group because these splits define the flows to/from the accounts in the "internal" group. And one more aspect that should have hinted early on that the new report is wrong: accounting NEVER guesses or assumes. So the fact that in John's example Income type 1 is not shown and instead distributed over Expense Type 1 & 2 is absolutely not correct. The resulting values of Expense Type 1 & 2 are not in the books. I know a fixed ratio is used here but that's a guess just like any other. Assuming the income should have been substracted in some way from the expenses (it should not!) there is now way that gnucash can know which expense or in which proportion the expenses should be reduced. There is no accounting rule for this, exactly because it's not supposed to happen. The report should show the bare split values, not make sums internally and then map those to some arbitrary account. So I will revert the improper fix for bug 622778 before the next 2.6 release due in September. @Carsten: your patch for bug 62278 actually consisted of 3 patches (see https://bugzilla.gnome.org/show_bug.cgi?id=622778#c6) followed by a few corrections by Mike Alexander. Should I remove all the patches to get the original behaviour or can I keep the restructuring patches ?
*** Bug 730013 has been marked as a duplicate of this bug. ***
Hi Geert, it is safe to keep the restructuring patches - they do not contain functional changes.
Hi Geert, If it helps, I am more than happy to install/test a preliminary build for the next release that would contain the changes and test against my dataset...if that helps. I have virtual machines setup just for this type of scenario.
Well, it seems I jumped the gun on my last comment(34). Thank you Geert for taking the time to go through this discussion. If I can offer any assistance to help Mezimezim and others get the report to properly reflect what they're looking for I would be happy to help. Thank you ALL for your work.
I have just reverted the patches for bug 622778. In the end I had to revert 5 patches: - Two by Mike Alexander which build on Carsten's 3rd patch - All of Carsten's patches Carsten, I tried to revert only your 3rd patch (and Mike's patches which build on it), but while testing the resulting report, I got different results than I got with the report from 2.4. I have tested with the test file from bug 622778. If I run the cash flow report on the bank account only, the resulting report is identical to what appears in GnuCash 2.4. If however I run a cash flow report on the bank account together with the account receivable account, the results are different: the 2.4 report shows a (correct IMO) money out of 1000 while the 2.6 reverted version shows a money out of 2000. So for now I have just reverted all the patches. If you are willing to look into the two restructuring patches for a fix, I'll be happy to apply them again. Tim, Charles, do you know how to build gnucash yourself to test the report as it is now in the maint branch ? If you are on Windows, note that I have just kicked the Windows build server to produce a new installer for this branch. You can expect the installer file to appear on http://code.gnucash.org/builds/win32/maint/ in a couple of hours.
I am running Windows so I have pulled the latest build from today and test over the weekend.
I can load it into Windows as well and test it on my data set, and compare it with the results from the same data set in 2.4.15. I should be able to get back by Monday as well.
Everything worked ok for me. When Ubuntu has the update in its software center I'll download it into Linux. I can access the same data from either operating system. Seems quite versatile to me. I do have a couple of suggestions for improvement what forum should I put that in?
Seems to work for me. The reports generated match archived reports. Many Thanks!!!
(In reply to comment #43) > Everything worked ok for me. When Ubuntu has the update in its software center > I'll download it into Linux. I can access the same data from either operating > system. Seems quite versatile to me. I do have a couple of suggestions for > improvement what forum should I put that in? Thank you for the feedback. You can discuss improvements on the gnucash-user@gnucash.org mailing list. If your suggestions are well received, chances are you will be asked to create an enhancement request here in bugzilla to keep track of its implementation.
(In reply to comment #44) > Seems to work for me. The reports generated match archived reports. > Many Thanks!!! Thank you for testing.
There is one more thing I would like to get some feedback on. I have already brought it up on bug 622778, but I'll repeat it here as the other bug is closed: Mike Alexander had applied a patch on top of Carsten's work to exclude trading accounts from the cash flow report altogether. I had to undo this patch as well, because it depended on Carsten's patches. Alexander is willing to recreate this patch, but I thought it would be useful to learn if excluding the trading accounts at all times is a good thing or not. I don't use trading accounts myself and I don't know how they work so I can't comment. Does any of you have experience with trading accounts and how they are best handled in the context of the cash flow report ?
If you're referring to stock or brokerage accounts please do not exclude them or their transactions. I use brokerage accounts extensively and when they're included in the account list I want their transactions included in the report. Quite frankly there should be no transactions automatically excluded from any cash flow report. The user can then design the report however he/she wants by including or excluding certain accounts or account types to get different views of the various flows. Everything appears to be working correctly now. Thank you for your help.
I personally don't use those type of accounts, but I do have to agree with Charles on topic of excluding accounts automatically. I would think if the user doesn't want to see those transactions then they should remove the account from the report.
*** Bug 734696 has been marked as a duplicate of this bug. ***
Charles: I'm not referring to stock or brokerage accounts. I'm talking about trading accounts. These are special account GnuCash uses to manage exchange rates in an alternative way. As I hinted before I don't use them either so I can't tell. They do have a role that is not typical in accounting so I'm not sure if they add anything to the cash flow report or not and I think this deserves careful consideration. Perhaps Mike Alexander can provide some more details here. I've taken the liberty to cc him in this conversation.
I can't think of any reason to want trading accounts included in cash flow reports, but I just checked in a change on the maint branch that adds an option controlling whether to include them. The default is to not include them, but if someone wants them, then they can get them.
That solution should work for everyone. So I'm closing this report now.
*** Bug 736594 has been marked as a duplicate of this bug. ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=722140. Please update any external references or bookmarks.