Localisation: GST/VAT worksheet programming guide

{{ due.Date }} is a text sting not a single number unlike a date in a spreadsheet program.
So to do date arithmetic you have to

  • Convert the date string to a single number
  • Do the arithmetic
  • Convert the number back to a date string

Yes this is what I’m trying to achieve with {% assign period.End = report.To | date: '%s' %}

As far as I understand this is supposed to convert the report.To date to Number of seconds since 1970-01-01, but the result I get is 0.

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.

{{ report.to  }}
{{ report.to | date: "%d %m %y" }}
{{ report.to | date: "%+" }}
{{ report.to | date: "%F" }}
{{ report.to | date: "%v" }}
{{ report.to | date: "%s" }}


15 0 19


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.

I am trying another approach, but I don’t know it seems things don’t work as documented.

{% assign month = report.To | date: '%M' %}
{{ month }}
{% assign month = month | plus: 0 %}
{{ month }}

If month is 3 I get 30 at the end. But liquid documentation says that plus: 0 should convert the string to number.

The idea was to use increment afterwards to get to the desired date.

OK. This is solved with opening the .json in a plain text editor, copy/pasting it to another file, and saving that to .json, as explained on SO.

The date: filter appears to have variable parameter interpretation
These appear to work as expected

{{ "now" | date: "%d" }} -> day of month
{{ "now" | date: "%y" }} -> year without century
{{ "now" | date: "%z" }} -> time zone offset

These have a different interpretation

{{ "now" | date: "%M" }} -> month not  minute
{{ "now" | date: "%m" }} -> minute not month
{{ "now" | date: "%s" }} -> seconds not seconds since 1970
{{ "now" | date: "%F" }} -> I think day of the week not ISO 8601 formatted date
{{ "now" | date: "%S" }} -> "S" not seconds
"%b" "%B" "%Z" "%v" "%+" "%a" "%A" "%e" "%w" "%u" "%j" "%Y" "%C"-> similarly all not supported

Which is different to the normal Liquid parameter functions http://strftime.net/
An example of date arithmetic all in one statement which essentially uses the method you suggested https://stackoverflow.com/questions/21056965/date-math-manipulation-in-liquid-template-filter
I’m not sure it is possible with the date: filter as provided in Manager localisation.

This solution looks reasonable https://stackoverflow.com/questions/10714980/locale-specific-date-in-jekyll
A more generic solution (but probably excessive for a localisation) https://freakdesign.com.au/blogs/news/translate-a-liquid-date-string-in-shopify

Aha! This is because Manager is not using liquid, but dotliquid, (because, presumably, this must be done when programming in C#, or maybe it is using liquid with the .NET fromating strings??). Anyway, the time format strings are defined differently

See: https://github.com/dotliquid/dotliquid/wiki/DotLiquid-for-Designers

When using the date filter, DotLiquid supports both Ruby and .NET date format strings (but not both at the same time). By default, it will use .NET date format strings. This can be changed by setting a configuration property:

And the format specifications for .NET: https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings

(Btw, if it realy does use dotliquid that seems to be a dead project for at least 2 years)

This thread demonstrates why this is not a coding forum. :upside_down_face:

Tut, try reading the thread again. More than 90% is Manager specific not general programming information. The forum is for an exchange of ideas to maximise the use and value of Manager. Without Manager specific information in a central place how do you plan to get the 1-4 localisation for 100-200 countries written. The hard part about doing that is a good understanding of local tax laws now an easy to use tool has been built by Lubos. Because of the required local tax knowledge, Manager localisation are best written by local accountants, hence the format of this thread.

I appreciate there a users and moderators more familiar with accounting than Manager customisation. And while all users need to customise Manager, some will never need to use the more advanced customisation features. If the forum traffic for advanced customisation becomes excessive, perhaps a sub forum would be required but I would be surprised if that happened


Thats a great Idea to start a sub forum for it then those that are not interested dont have to look

@Patch, my comment was only meant as a joke. The upside-down smiley face was used to show how I feel reading it. No criticism was intended. I apologize if it was taken that way.

1 Like

Oops, I missed the emoji, thank you for correcting my mistake.

Novica, it is probably sensible to not try too hard at the moment to work around the date format limitations given

From DotLiquid for Designers implementations need to choose Ruby format compatibility or .Net. It appear Manager has been set up to use the latter so wee need to work with https://docs.microsoft.com/en-us/dotnet/standard/base-types/standard-date-and-time-format-strings


As a result of this post it is probably best to not put too much effort into localisation at the moment. I assume the future implementation will enable a larger range of use cases to be addressed and hopefully maintains relative ease of implementation for those with a good understanding of local tax requirements such as local accountants.

In liquid

{{report.To | date: "%s" | plus: 7464960000| date: "%v"}}

In dotLiquid with .Net date format / without the “Seconds since 1970” date filter option, you need something like Microsoft liquid implementation

{{ report.To | date_add_days: 25 }}

Or in .Net Framework

answer = today.AddDays(25);

Yup. I found that too. Just wasn’t sure if i should continue posting after Lubos’s comment and the discussion here about appropriate coding forum.

Why would I have the error Liquid error: Value cannot be null. Parameter name: key on the report is it because of the 0 in the credits on Sales.

do you know @Patch

The liquid error is saying your code is trying to use a null (none existent thing) as an index to access a specific element in a data array.

The easiest way to find out how this could be happening is to print out the internal / intermediate values given your current Manager business. See the post above on debugging such as

More options are shown in that post or the Business information access post
Printing out some of the intermediate values may also help such as used in the code you added
A mistake in copying or changed UUID could produce this error

Thank you I have now found it by using your above suggestion @Patch My NZ GST return is now all correct. and I got the new tax code to work where when you load it into a business for the first time it creates the new tax code

I sure wish we could do this with payslips so we could design our own with custom fields and do adding etc. want to add quantity with a custom field. The layout is all good just want to do a bit more with it

I agree calculations in payslips would be good but that will have to be done differently as it involves writing back to Managers database not just customising the displayed results.

@Patch brilliant work, much respect, keep up the excellent work.

We all bring different skills to the table, whilst Manager forum is not intended as a coding forum, it is near impossible to have a good functioning Manager without some level of customization using coding.

Some users are very skilled in many facets of business, but lack in coding skills, especially the older ones who were not born digital natives.

It is refreshing to have someone willing to share their knowledge to help give these a leg up when needed.

Cheers mate.

1 Like