Localizations are country-specific starting points which provide localized chart of accounts, tax codes, custom fields, report transformations and extensions when creating new business.
I hope this is more streamlined approach. Eventually I hope to have all countries added. If you’d like to work on a country which does not exist yet, please let me know and I’ll add it.
@ASEGC1725 i can see the COA for India being updated. but there is no standard COA provided by the government. therefore, i do not think personal preferences should be updated as localizations. COA is the user choice.
the point of having localizations is for the contributors to have Manager setup in a way which complies with the local laws while keeping Manager look fresh like a new installation for a new user. while it is okay to enable tabs so that some localization features can be added, it is not okay to leave the tabs enabled after adding the features. a new user will be provided with a lot of tabs and features irrelevent to their business. it should be noted that Manager preserves the custom fields and form defaults for tabs that have been disabled. this is great for users who contribute and for new users who utilize the localizations.
@lubos i personally preferred the old method to contribute where users had the opportunity to discuss and review the changes being proposed. i hope the new way to contribute has something similar or this is going to get out of hand very quickly in my personal opinion.
Imo the best way of doing this is open a thread on this forum to discuss a countries localisation. Such as “Localisation - India”. Manager users with expertise in a particular localisation / jurisdictions accounting / legal requirements can then readily contribute.
I do suspect it would be difficult to make a localisation for the USA as Manager’s tax code architecture does not sensibly accommodate the many tax authorities in USA tax system. Multiple rate tax codes consist of a set of ordinary single rate tax codes would be required.
Edit, actually I would defer to @Tut greater knowledge of Manager customisation and the USA taxation system.
this would just become a nuisance for other members on the forum.
anyway the point was to have the developer involved in implementing the localizations where he had the authority to decide whether a proposed change should be implemented and suggest changes. the old method had this and I am not sure about this new method.
when there is an interaction with the developer you will know whether the proposed changes will have an impact on future versions of Manager where the program design concept might change. it keeps the localizations implementation inline with the core Manager development.
No the point of community contributions is to have the community involved in generating the localisations.
Community support relies on community discussion where those with expertise in particular areas contribute. A healthy community relies on the concept of paying forward. By which I mean: User A helps user B. In turn user B repays by helping a different user in the future. All of this requires active discussion accessible by all users with the time an local knowledge required to contribute.
The fact that several users are trying to contribute with this new approach is excellent news.
This is not a problem. Keep those tabs enabled. Manager will cherry-pick from localizations only relevant data. For example, feel free to create test transactions and other test data to demonstrate how custom fields are used or that report transformations and extensions are working.
I found out it won’t work. Too high barrier of entry. A lot of users are keen to work on this but understanding Git workflow and JSON diffs is too much to ask. Also, it’s important we all work in real-time. If you work on report transformation and something is not right, I can have look into the same database you are working with. Much easier to reproduce issues as we should see the same thing.
Eventually, I will branch United States per state. So it will be possible to create United States (California), United States (Oregon) etc.
This new method has it too. There is approval model baked in. I will review daily all the changes and either accept or decline.
It’s this but also helping themselves. Fixing / improving report transformation in localization will benefit all users who have the given country set under Business Details. For example, if there is an improvement to Single Touch Payroll Worksheet in Australia, the improvement will be rolled out to everyone with Australia set as their country in their business.
but it was easier for other contributors too to check what changes were proposed. now we have to rely on the History feature to track every proposed change individually. but I like the fact that the new method is simpler and will get more users to contribute.
that was my main concern. thanks for clarifying that.
Having “Multiple rate tax codes” consist of a set of ordinary “Single rate tax codes” would enable a localisation for tax jurisdiction which spans more than one localisation eg federal tax for multiple states or a state tax used with multiple county taxes. Users in USA could then just load the localisations applicable to their use case.
But I’m off topic here and I’m sure you are already aware of the challenges, so will find a workable solution.
What do we need exactly to add Saudi Arabia Localization Arabic file?
Accounts in the COA are translated into Arabic besides adding Arabic VAT Returns Report then what else?
Manager Forum this link gives the same error as above unless you are already logged in the forum which will automatically signin using your login credentials.
after you hit logout, the login page is displayed with your username prefilled (sharpdrivetek in my case). hitting the login button after entering the password shows an error page below.
