Developing GST/VAT Worksheet: Step3 Correct the Tax codesUUID
Open a Manger window in your browser (so it shows the page address bar). How to do this varies with operating system. In windows right click on a link and choose open in a new window)
Go to the tax code page in Manger in you business
Edit the page address to add “.json” (at the end of the address but before the parameters)
In your localisation, for each tax code create a variable named identical to each tax code (spaces replace by under score) and assigned the appropriate UUID.
Developing GST/VAT Worksheet: Step4Create arrays of all your tax code totals
This is done by the following code which is likely to be the same for all VAT calculation work sheets, so you can leave it unchanged (or delete the lines your worksheet never uses).
What it does, from the “objects” passed to the localisation, it creates variables containing an array which use each tax codes UUID as an data label and the relevant total as a value. Array elements being of the format [TaxCodeUUID, amountInDollars]
These arrays can then be used to easily access specific totals for each tax code.
For example the following code will now display the net sales for the tax code GST 15%
Developing GST/VAT Worksheet: Step5Perform your countries VATcalculation
This mostly requires an understanding of your countries VAT legislation. It is country specific. It maps the tax codes used in a Manager business to your countries tax reporting requirements. The calculations done here should essentially be the same as you are currently doing manually for each VAT return. Examples from other countries VAT calculation worksheet may provided some guidance particularly if similar tax regimes apply, however the details are likely to be different for each country.
Developing GST/VAT Worksheet: Step7Testing the calculation worksheet
This is most rapidly done by printing out all input and intermediate values.
A rough way of printing the input data is
{% for objectRow in objects %}
{{ objectRow.TaxCode.name }}
{{ objectRow }}
{% endfor %}
This displays the tax code name then the tax code information lubos has provided to the localisation. Most of which is readable except the UUID (the array entry showing as [taxCode, DotLiquid.Hash])
Intermediate values common to most Tax Summary localisations can be displayed as follows (but you will probably find this unnecessary as the above rough listing is relativity easy to read when see what it is displaying)
Other intermediate calculation variables will vary for each countries worksheet. Displaying them would be useful if the results are not as you expect.
Then enter a single transaction and check the worksheet results, comparing it to what you manually calculate. Test cases should be for legitimate transaction covering the use of each of the tax codes for
Developing GST/VAT Worksheet: Step8Create a localisation for general use
Transformation description field; In your report add text to guide other users in the correct use of your report transformation. Information to assist other users may include; what it is designed to be used for, when it should be run, and assumptions on how tax codes are used for particular situations in the Manager business. This text will appear at the top of your report transformations user guide.
Backup the “My VAT Worksheet business” and/or export the report transformation.
Import the report transformation into an new blank business or restore your “My VAT Worksheet business” back up.
From this interim Manager business, delete all development / debug code. Delete any other customisations not required for this report transformation such as custom fields or tax codes not used or not appropriate.
Export your final report transformation.
Contact Lubos (or other designated moderator) to discuss hosting it on the main manager site for general use / distribution.
So, I’ve followed Patch’s instructions to create a new localization, but my report fails with
DotLiquid.Exceptions.SyntaxException: Syntax Error in 'assign' tag - Valid syntax: assign [var] = [source]
at DotLiquid.Tags.Assign.Initialize(String tagName, String markup, List`1 tokens)
at DotLiquid.Block.Parse(List`1 tokens)
at DotLiquid.Template.ParseInternal(String source)
at DotLiquid.Template.Parse(String source)
at ManagerServer.HttpHandlers.Businesses.Business.Reports.Report2.Get()
at ManagerServer.HttpApplication.ProcessRequest(HttpRequest request, HttpResponse response)
I cannot see where my error is. Anyone willing to review the .json file I made?
Some date routines have a language parameter. I haven’t seen it in liquid.
Other localisations just use a numeric date format which ovoids the problem.
A filter could be used to replace each English month with it’s translation but there is probably a better way.
If you look at the .json file with a text editor, does it look similar to other localisation files (ie not an empty file or otherwise grossly wrong). Note I have found saving the .json file with a text editor has stopped it from being usable in Manager (I assume the file uses non printable characters do define the document parts).
If it looks reasonable @lubos may need to help. I suspect he will need to be involved soon to consider adding it to the main web site.
Yes. it looks like it should I guess It’s working in the one demo company that I set up.
Another question, any idea how to achieve date calculation? I was following liquid documentation, but cannot get the wanted date. I want to be able to calculate the due date for submission of the report which is 25 days after the report.To date.
Sorry I didn’t look closely enough.
Your code looks fine.
Tried myself and very limited date: filters work. (no month print out but “now” does work)
Perhaps date: time zone and language need to be set in Manger localisation.
Thinking about it, I suspect lubos is already aware the date: filter is non standard. That would explain why financial year period as well as report period is separately entered in all localisation. Liquid date: filter appears to not support languages other than English, so Lubos may have a custom modification to circumvent this limitation.
Probably should look to see what date localisation data is stored in the “business” variable.
