before I dig deep with specifics, I would want to emphasize that the localization is still in the beta phase when we consider requirements of every country.
advanced users can easily grasp how things work but I do not think it would be easier for others. that being said, no one would need to create new tax codes once the localizations are fully implemented. so i guess this is a necessary change for the better.
until something is developed to set which tax codes are selectable on which transaction forms, users will be bombarded with a confusing list of tax codes. the developer is aware of the issue and some tweaks can be expected in the near future.
also, there are improvements which needs to be further improved based on different localization requirements. one such improvement needed is explained here.
users would be willing to have separate records when the taxation requirements change but I do not think they would want separate records because of changes to the program. it raises doubts about the program being a perpetual system. the program is not expected to produce scattered reports based on the time of new feature additions. merging existing tax codes was suggested here which would enable compatibility of old transactions with the new localization features.
@lubos i would also suggest to have a reference log and instructions for every localization when the localization moves to the stable phase. this would help users understand how to use the localization features and to modify them when the requirements change. also, dependency on users who created the localizations initially would be reduced when tax regulations change in the future.
In Australia the annual tax return requires separating a businesses income into may sub categories. In practice this is done mostly by the chart account structure. For small businesses the businesses accountant extracts this information from the businesses accounting records each year. The categories are evolving and may accounting software users entering a line item in an invoice would not know what they are. So while information for the annual tax return could be encoded in tax codes, that’s not how I have seen it done. And doing so would result in a very complicated tax code system.
In Ireland do most accounting system encode information for this annual report in tax codes entered by users on each line item of an invoice. Or is another system used.
I can’t say for most accounting packages, sorry but Sage Accounts have around 60 tax codes to provide the Irish Vat reports.
A businesses tax reports are different and are generally produced from the chart of accounts. There is no defined set of accounts here, unlike some European countries. Each business will design it’s own chart based on their own reporting requirements and the need to submit official accounts
VAT reports are completely separate from your annual accounts
Our VAT 3 report has two fields
T3 = VAT Payable
T4 = VAT Repayable
In all cases one of them is zero, and the other is the value of the tax to be paid or repaid
So the absolute value of the Tax Liability field in Manager is the value that should appear in one but one one of them. It is not possible to do this currently as the value of the Tax Liability field is a +ve or -ve depending on whether tax is payable or repayable
yes, yes and yes. it works perfectly for our govt requirements. and I am sure it would be the same for others.
anyone curious to know how this changes the presentation can check the below post.
I have used a single rate for 13.5% tax code and a multiple rate for 23% tax code
The labels of the tax on a sales invoice are treated differently. The labels in the totals should be the same as the labels used on the lines, I think instead of using the tax code itself
this would not be suitable in cases like ours where we need to consolidate the total tax amounts.
but I agree that the Totals should display data in the Label field when tax codes are defined as Single rate.