The first version is finished but Idk when it will appear in the settings.
See
But Iām not sure this is the right way yet. Iām a bit worried Tax Codes are getting a bit too complicated.
Wouldnāt tax categories be enough without custom fields? I mean normal tax codes are composite tax codes with 1 component, or isnāt it?
Yes. Thatās correct. The idea is to eliminate need for custom fields on tax codes and the connection between tax codes and report transformations to be driven by tax reporting categories.
1 Like
Mmm
Does this also address jurisdictions with many tax collecting authorities? It may work.
Another scheme which may cover more jurisdictions tax requirements is
-
Multi part tax code consisting of as set of single part tax code
-
Single part tax code has an optional calculation group / evaluation order. Only relevant for multi part tax codes. Single part tax codes continue to have an account associated.
-
Localisation report for each tax authority to address the reporting requirements.
-
Where a jurisdiction has many tax authorities users could just load the tax localisations relevant to their use case (eg common Federal plus relevant states etc). Each containing the required tax codes, accounts and localisation reports. For countries with only few tax authorities, the countries localisation would include all tax authority tax codes and reports.
In summary this would use
-
only single component tax codes for accounting functions each applies to only one tax authority. Multi competent tax codes use underlying single component tax codes
-
the localisations generated for each jurisdiction to group the relevant components.
The principal reasons for using multi rate tax codes consisting of a group of single rate tax codes:
-
if a tax authority changes a tax rate the changes in Manager are relatively localised. The old single rate tax code is inactivated, a new single rate tax code is created. The new single rate tax code is added to the report transformation for communication with the tax authority. No changes are required to report transformations to other tax authorities in that jurisdiction. (Many solutions will be ok initially however in time after multiple changes have occurred, some may become less elegant)
-
multi rate tax codes are very simple, merely a way of entering multiple tax codes by selecting one item from a list. As a result in jurisdictions with a large number of possible combinations, the multi rate tax codes can be created by the user not as part of Managers localisation. Doing so then enables Manager to support and automate reporting in jurisdictions with many tax authorities and an inordinate number of theoretical multi rate tax codes.
-
different data entry options for groups of tax codes could be added in the future if desired. Such as user selected combinations at data entry.
PS
Calculation group / evaluation order would allow
- Calculation group 1 ā Taxes are calculated as a percentage of the untaxed amount (group 0)
- Calculation group 2 ā Taxes are calculated as a percentage of the amount after including group 1 taxes
- Calculation group 3 ā Taxes are calculated as a percentage of the amount after including group 2 taxes
With this information, Manager could then model the tax authorities requirements directly allowing it to convert between before and after tax amounts, and used the tax percentages stipulated by the tax authority.
Please donāt remove custom fields. They are a fundamental part of the Italian customization Iām working on.
I was considering this but for now, there is no need for it. Also, tax codes cannot come from localizations because I want localizations to be āread-onlyā layer on top of the business data. This means bug in localization would translate into a bug in country-specific report at most. It would never spill into your generic financial statements.
@Davide, Iām making decisions based on observation what I see that is happening in localizations and what issues are being discovered. Why do you believe you require custom fields on tax codes and that it cannot be solved using reporting categories. If Iād see how you are using custom fields, I could adjust my direction better. In the end, Iām seeking the lowest common denominator that works for all countries.
Iām not aware of any other ways of achieving automated reporting requirements in jurisdictions with many tax authorities.
I appreciate trying to support those countries or not is a business decision. Personally it makes no difference to me as Australiaās requirements are relatively simple.
In my opinion having
- separate ādumbā tax codes for sales/purchases accounting functionality. Combined with smart logic to for user interface / restricted tax code subset selection.
- āSingle rateā tax codes programmed to reflect a singe tax authorities taxation behaviour
- single rate tax code grouping to describe how successive taxes are combined in a jurisdiction.
- line items allowing a group of āsingle rate tax codesā. Starting with a simple multi rate group option.
The down side of the above is thatās a major change and Iām unsure how much back end work it implies.
The upside is it would be a more capable foundation which would be more intuitive to us.
Your call of course
How will reverse charging work with the new Tax Reporting categories?
@lubos would it be possible to assign tax codes to Expense accounts?
this would be helpful where the tax on items are ineligible for input credit.
1 Like
I am getting lost withe current implementation of taxes. I see that now there are report categories. What are they for?
My current implementation of tax codes uses custom fields since each tax code have many different attributes that are needed for tax declarations and for e-invoices:
Maybe a couple of them could fit the new implementation but I hardly doubt that I can fit everything in standard fields.
Welcome to the new world.
Basically you will need to match each tax code to a specific Tax Reporting Code.
It is a bit unwieldy but I have it working for the tax reports we need in Ireland.
But you need to separate tax codes for inputs and supplies plus all the EU reverse charging structure.
Best of luck
For exampleā¦ here in Italy, as you can see, there is a mess of codes and subcodes for 0% VAT that are needed for e-invoices.
So basically you have the main tax code, and if the main tax code is 0%, a group and a subgroup. How this can be implemented without custom fields?
@Davide I canāt take into consideration what are your requirements if you do this privately and not at localizations.manager.io because I canāt see what are you working on. You can continue using custom fields on tax codes if this data needs to be available for some purpose. Itās just that for the purpose of creating report transformations, it needs to be done through reporting categories.
@eko Iām improving the model based on the requirements I see. As of now, all the requirements seem to be handled.
Iām not working on this privately. It is something that I did a long time ago with one of the previous implementation of localized tax codes (the one with the possibility to export and import settings for which you created an online environment).
I havenāt had time this days to reproduce it in the new localization implementation. However I would like to understand the use of reporting categories to understand if one or more of them can be used instead of custom fields.
@Lubos, you re using agile program development approach and therefore you can not conclude that all requirements seem to be handled as more needs and wants will appear. I actually agree with such program development approach as it will quicker lead to desired results as long as programming keeps up with the pace. However, I would advise you to be transparent about this approach to avoid people expecting the program to be completed.