I think we are talking about different things.
If I understand you correctly, you are suggesting the user selects the axes of a tax code rather than having an enumerated list of tax codes eg the axis values could be
- Sales, purchase
- 23%, 13.5%, 9%, 4.8%, 5.4%, 0%
- Domestic, EU, non-EU
- For resale, not resale
As resultant any combination could be selected using only a list of a few items for each dimension. The total combinations selectable being the product of each dimensions size (in the above example 2 x 6 x 3 x 2 = 72)
Lubos is currently looking at the other extreme ie
- Create tax codes for each coordinate (in the above example 72 tax codes)
- Merge any points where separate identification is not need to fill out that jurisdictions official VAT report. Or looking from the opposite perspective, only retain individual tax codes where the subdivisions effects a reportable quantity, otherwise group them.
- the end result is the user only needs supply information essential to filling out their VAT return, so minimizing data entry complexity.
The optimal approach depends on the length of resultant lists the user has to select values from. Last time I looked a list length of about 7 was thought to be near optimal for the average human brain.
What I was proposing was separate to the this. Manager often has contextual information which could be used to dynamically reduce the list length. For example on a sales invoice
-
In a line item with a positive amount, the tax code will be a sale tax code. So purchase tax codes could be completely hidden.
-
Most line items will have a positive amount. So purchase tax codes could be less accessible.
-
For negative amount line items users preferences for Sale/purchase will vary depending on individual work flow. So both must be capable of being accessed however as this is a relatively rare occurrence for all uses, how the list is presented is not critical.
-
Edit: In theory a double negative is possible ie a negative line item in the counter trade. In practice this would be extremely rare. However for user and program simplicity it would probably be cleaner to display sales / purchase codes as listed here at the top level and have the contra tax codes in a sub menu at the bottom of the list. For journal entries displaying all tax codes at the same level would preferable.
The same logic can be applied to other screens. What I was proposing is partially hiding tax codes users are unlikely to want to select. For example putting them at the bottom of the list or better still in a sub menu at the bottom of the list.
In summary, as long as all valid options are available, Manager optimizing selection of the most likely option is an excellent design feature.
In my opinion adding explicit support at the transaction level for Counter trade and Recipient-created tax invoices transaction would be better again. Doing so would more clearly display the underlying transactions to the user and this could be shown on invoices Manager generates. It is however a larger risk as it is different to other software packages, and I assume would involve more of your time to implement. Perhaps it maybe a later enhancement at which time it would enable further trimming of the tax codes displayed to the user.