What are you trying to achieve? You cannot create a transaction report by account, list the amount in it as 100 and drop parts of it in the details (should not be shown).

Another option for you would be to create a 'transaction report by category' where you can select the account and deselect certain categories.

Transaction by Account actually has the same behaviour. Checking them all, I found:

Sums category: Category, Top Categories, Payee
Sums transaction: Accounts, Top Accounts, Month, Week


Australia has weird taxation rules on foreign income that basically state that the taxable amount is not the amount remitted to Australia but instead is the amount of foreign currency converted at the average rate of the period in which the work was actually done. (That was a mouthful!)

Basically, what I'm doing is to split the deposits into my account into a "taxable amount" category and a "remainder" category. I then want to have a sum of those taxable amounts by month - by quarter actually. I could do this with Transactions by Category, but I'd need to change the report's options for each period total I need.

Hmm.. Another way to look at this bug is that changing the "organise by" option shouldn't change the grand total.

I still don't get it. Why use a transaction report when you need a sum by period?
Use an income and expense report, and filter out the categories you don't need.

I use that report too, which is perfect for grabbing the totals that are needed on the tax statements. Using a transaction report is useful to make sure I have all (or haven't missed any) receipts and how the totals are arrived at. Having a wrong total on that report is not such an issue when it's just me looking at it, but it'd be better that the totals match should I be audited.

I've also started using split transactions on the expense side as well. A purchase that has items for personal use as well as business use gets split into "personal", "business (pre-gst)" and "business (gst)". "business (gst)" is reported under business taxation and "business (pre-gst)" is claimable on personal income tax, with the "personal" amount not being applicable to either. Transaction reports are just as useful for these as on the income side.

Conversely, is there any reason that deselected categories that are part of split transactions should be included in the totals on a transaction report?

Regarding your last question, let me tell you why not:

You have a transaction A with 2 splits:
account A1
category C1

You can tell that all money coming in/out of A1 is due to category C1.

Now, you have a little more complicated transaction, yet a pretty normal one:
transaction B, with 4 splits:
accounts A1 and A2
categories C1 and C2.

Now, you want a report for A1, but you filter category C1.

It will still show the same total for A1. The application cannot tell whether the amount of category C1 was coming out of A1 or A2, or even C2, in some cases. So it does not intend to do that, instead of providing half-baked solutions that don't work in many common cases.

I was unaware that transactions could be split by anything other than categories... Is that an upcoming feature? I can understand the problem of not known which amount flowed to where in the case of transaction B.

> Now, you want a report for A1, but you filter category C1.
> 
> It will still show the same total for A1.

My testing shows different... Simplifying and giving values to your example:

Transaction A
category C1 $50

Transaction B
category C1 $50
cateogry C2 $50

Filtering category C1 in a transactions by account report will exclude transaction A and include both categories from transaction B giving a total of $100. You seem to be stating that transaction A should also be included, giving a total of $150?

Not to say there isn't one, but I can't think of a use case for the current behaviour.

> So it does not intend to do that, instead of providing half-baked
> solutions that don't work in many common cases.

This seems a little indignant... Even if you think that my use of categories is incorrect, I don't believe it should factor into this bug report at all.

As I said in comment #3, changing the "organise by" setting shouldn't change the grand total. At minimum, the wording should change. On the other end of the scale, having a (default on) checkbox in the category selection tab that enables the inclusion of deselected categories on split transactions, which would support both the current behaviour as well as what I think to be the correct behaviour.

The latter is probably not so easy to implement, though. If you think it to be an acceptable solution but feel that this bug is not worth the effort, I'll implement it and submit a patch.

> So it does not intend to do that, instead of providing half-baked
> solutions that don't work in many common cases.

This seems a little indignant... Even if you think that my use of categories is
incorrect, I don't believe it should factor into this bug report at all.

----
By it, I meant the application. This has been discussed a couple of times before. It always results in a very long discussion, and a final self-slap on the forehead when the other end realizes how double-entry works and how there might be more than 1 account-to-categories use-case.
For most cases, we try to hide double-entry accounting. This is one of those situations where you have to grasp it to understand what's really going on.

And the case I stated is not an upcoming feature, it's how me, and many other users, enter our salaries every month, just to mention a very common case.

-----------------------


For your case, you have to use the "Transactions by Category" report.

----------------------

You can still send me a patch. But I'd rather you bare with me and trust me as the reports maintainer when I tell you it's working ok.