I think it is an excellent idea to increase the commonality between custom reports and report transformation. Doing so leverages on user learning curve in each Manager facility. However I really don’t know the best way to achieve that.
Clearly as measured by the volume of community report transformation contributed, compared to the work NG Software has contributed to in developing the Country specific localisation interface. We have not leveraged community involvement to achieve any significant increase in country specific localisations over what NG Software would have achieved by just doing the currently community submissions themselves. So there is considerable opportunity for improvement.
To be honest I have found there is a significant barrier to entry in contributing to country specific localisations. The main barriers / time investment prior to useful output has been.
-
Lack of clear documentation on what is and is not supported by Managers report transformation interface. The underlying issue is Liquid is an extendable so while there are a variety of online sources which describe how other implementations of Liquid work, reading them only provides hints on how Managers implementation may work. As a result it has basically been necessary to reverse engineer the interface to find out how to use it. A very time consuming task. Trying to reduce this barrier to entry, and help other user avoid wasting their time doing the same, was basically why I wrote Localisation: GST/VAT worksheet programming guide
-
Poor error handling and very limited program development tools. Maybe I’m just old school but I find a non declarative language which hides use of undefined procedure calls (filter) and variables results in far more time wasted in debugging than it saves in initial coding. Similarly Managers report transformation environment has rather spartan program development tools.
-
Lack of fostering programmer interaction. There is a significant learning curve to using Managers more advanced customisation facilities. This has two consequences. Firstly the functionality is beyond the capabilities of many Manager users, so to ensure they do not get the false impression Manager is hard to use, it is necessary to hide this functionality from them (both in the forum and in the software). Secondly for NG Software to effectively harness the abilities of those who are able use advance software customisation / software coding, the programmers need to efficiently communicate among themselves. I suspect a programming subform, not displayed by default maybe the most efficient way of achieving both requirements simultaneously.
Taking a completely different approach to country specific localisations is an alternative. I can see enhancing the functionality of custom reports type interface will help some Manager users. Enhancing functionality is a two edged sword though, as increasing functionality typically also increases learning curve, so is likely to further decrease the number of users who can actually use custom reports to extract information useful to their business.
A graphical interface can be used to generate code. Doing so works best the more tightly defined the application is (not dis-similar to doing accounts in a spread sheet program vs a basic accounting program, the restrictions introduced by the latter make it easier to do basic accounting). The challenge is, the more general purpose the programming application becomes, the less efficient the restrictions introduced by the graphical interface becomes (both to provide the interface and use the interface).
In summary, I agree making significant changes to the country specific localisation interface is worth examining. I worry that replacing it with a fully graphical interface may not be the most efficient way of achieving the desired outcome. The challenges ahead which most concern me are
- Reduce programmer barrier to entry for country specific localisations
- Data entry screen country specific localisations
- Electronic data interchange consistent with country specific requirements
PS this post was moved from Aust localisation inconsistent with ATO requirements - #6 by Patch