To avoid the misunderstanding of http://bugzilla.gnome.org/show_bug.cgi?id=432072, I rename this to "Edit->Tax
Options"

Well, it is a matter of debate whether VAT tax accounts should be counted as Expense or as Asset. 

However, the enhancement request for offering Asset/Liability accounts in addition to the Expense/Income accounts in this dialog  http://bugzilla.gnome.org/attachment.cgi?id=86758&action=view is perfectly valid. Do you have any suggestions how this should be incorporated into the GUI? Four such radiobuttons instead of two would make this window perhaps too crowded?

Paid_VAT is both, an expense (Ausgabe), which produce an asset, but no cost (kein Aufwand, keine Kosten).

-- In german accounting the terms "Auszahlung" (pay off), "Ausgabe" (expense), "Aufwand"(?), "Kosten" (cost) are all different and I am not always shure about the right translation, but details should be found in any book about cost accounting (Industrielle Kostenrechnung)

Taken_VAT is money only passing through from client to tax office, no yield (kein Ertrag).

I think.
( ) Assets  ( ) Liability
( ) Expense (x) Income
would look fine, according the usual structure of the books.

Income should be the default selection. Most taxes are income related.

If you dont plan to bring Gnucash in your mobile, your will at least have standard VGA resolution.

If you're going to do that, you've pretty much exposed the entire account tree.  There would be no point in filtering anymore.  Just remove the radio buttons and make the whole account tree visible.

I think the handling of VAT, and maybe other kinds of sales taxes, is a very special case of tax handling.

As business man you are a honoray tax man. So you has to manage this money in the name of the tax office. And so this is kept in liabilities.

AFAIK the other kinds of taxes, for which the forms may be later implemented, are mainly income related. There, and general for usability, it is good, if you can filter. In the standardized german "SKR03/04" account frame you can have between 1000 and 10.000 accounts.

Overview of fields in "USTVA" and affected accounts:
Account  Tax form 
class    fields
Assets    7
Liabil.  12
Expense  -
Income   21

From the point of software ergonomy, to be user friendly, the best would be, if you could select the tax form fields in a pop up dialog or selection list direct from register editing instead of a separate dialog in the edit menu.

Usually every few years, at least the german, tax authorities wants to know a little more. So you start creating new accounts and the assign form fields. Why should you walk through the account hierarchy twice for each account?

On long term, it should also be possible to make multiple choices (account a: field x in monthly report and field y in yearly report as example).

Though for test purposes and if it wouldn't disturb american users of this feature, I would agree, to remove/deactivate the filter buttons, so I could continue the tests.

@Frank: Thanks for refreshing this bugreport every now and then. But please keep in mind that such a report is most helpful if you keep the explanations of *other* tasks rather short but instead you should explain this particular enhancement request as precise as possible.

So to recap comment#2, comment#4, and comment#6: We should remove the account type filter radiobuttons completely and instead have the whole tree visible? That should be achieved by removing the lines 749-751 in file src/gnome/dialog-tax-info.c (the call to gnc_tree_view_account_set_filter()), which switches off the filtering.

@Frank: Can you please do this locally and tell us whether this would be an improvement? Thanks.

Created attachment 94427 [details] [review]
Patch for removing the account type filtering

If you prefer a patch to remove the filtering and also its buttons, here you are.

Christian, thank you for the patch.  I will give it a spin.

After applying the patch, the radio buttons are gone and I see only expense accounts. They seem somewhere else be set as default. Knows somebody on the fly, where it can be changed to something like all_accounttypes?

Christian, can you help us out here once more?

I hereby confirm comment 10

Workaround for USt/VSt retrieval with existing tools - till some better solution can be offered:

This workaround applies without (!) extending filters showing assets or liabilities in the Tax Options window.
 

1. Create a new top-level account (expenses) called, e.g., "Vorsteuer"

2. Move the VSt account tree or all VSt accounts into the top-level account "Vorsteuer". Let GnuCash re-assign the attribute "expenses" to all moved accounts.

3. Open Edit > Tax Options and highlight any account(s) you want to assign a tax category to. The tax categories in the window on the right refer to the fields in the VAT declaration ("USt-Voranmeldung") and are needed for the Tax Report.



NB: 
- The technique supplied in this workaround is not meant to be responsive to any accounting issues. 
- Steps 1. and 2. are just preparatory steps for step 3. to work.
- Regularly clear the VSt with by off-setting with USt liability accounts ("USt fällig")
- Exclude non-cleared VSt accounts in the P&L report since VSt/USt does not classify neither as income nor expense according to German GAAP (German: HGB).

(In reply to comment #13)
> Workaround for USt/VSt retrieval with existing tools

I would not call that a workaroud, that is evil hackery.  The accounts jusdt simply are not expense accounts.

(In reply to comment #14)
> (In reply to comment #13)
> > Workaround for USt/VSt retrieval with existing tools
> 
> I would not call that a workaroud, that is evil hackery.  The accounts jusdt
> simply are not expense accounts.

See my first comment NB in comment #13. ;) But it does work like that yielding appropriate results.

... for more information you might want to dig through this bug where some topics on that are brought up. :-)

(In reply to comment #11)
> Christian, can you help us out here once more?

Errr... sorry, no, I have no idea if this doesn't help here.

This would be another potential wontfix candidate if German tax issues were being considered out of scope for gnucash.  At any rate, unfortunately, I don't see a quick resolution for these types of things inside gnucash.  I think for the time being, the SQL backend will yield results much quicker for the kinds of reports that us German business users will be looking for.

Re #4: I assume there are some countries, which have not only income taxes, but also some kind of wealth tax and expect the transmission of the base for the taxation. So I think, having buttons for all 4 categories whould be fine.

Removing the buttons would expose in some german templates over 1000 accounts. It is annoying to scroll through such an amount. 

But probably the best way, would be to auto select the account, which is marked in CoA - despite of his type.

Re #13: Good Idea, needs more creative testing ;)

I just saw, r18413 contains some steps in the right direction, but have no time for testing. Somebody else?

This problem has been fixed in the development version r18413. The fix will be available in the next major software release. Thank you for your bug report.

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=432143. Please update any external references or bookmarks.