Improving the Transaction Filter Report
This very suggestion was made over 10 years ago (not by me) but it was never acted upon. Let's try again!
request: allow the user to specify transaction tags that should be EXCLUDED from the report. The current interface only allows specifying tags to be INCLUDED.
TL;DR
Within the very useful Transaction Filter Report it is possible to select categories to include in the report. A key feature of this capability is that a category that is NOT selected does not appear in the report. This allows very fine grained control over transactions by category.
Unfortunately, transactions have at most one category. But the criteria for inclusion in a report may not be related to a category. For example, a large expense such a property tax bill may be paid from a separate escrow account. Contributions to the account occur monthly. When the actual tax must be paid the correct amount is transferred to a working account like a checking account and the payment proceeds normally. Many people are familiar with this type of arrangement but it's just one useful example.
In the tax example, I may want the contribution to the escrow account to be recognized in the report as a monthly expense. The payment of the taxes clearly belongs in a category like "Taxes:property". If the escrow contributions are recognized monthly, including the actual tax payment would be counting the same expense twice (depending on what the report is for). To exclude an expense like this, it's currently necessary to assign a unique category to the transaction and make sure it is turned off in the category list.
That would be fine if the property tax is the only type of transaction that needs this treatment. In reality, there is no limit on the number and variety of payments that may be included in an 'escrow' budgeting scheme (or similar situation). And some of these 'excludable' expenses share categories with other expenses so one must either exclude them all (wrong) or devise an artificially unique category for every excludable expense.
The problem cries out for the semantics of a TAG -- something that can be attached to transactions singly or in combination. And they may be sparse -- that is every transaction is not expected to have tags. They are perfect for solving the above problem and a host of others as well.
Except that they are currently only used to include transactions in a report. Allowing a user to exclude transactions that have a given tag provides an enormous amount of flexibility with a very small degree of logical change in the program's interface or structure.
Please consider implementing this feature soon.
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
System closed this discussion on 02 Feb, 2023 03:10 AM.