[Localization] Making Country Specific Features in ERPNext

Over the last couple of days, I have been working on the implementation of GST specific features for India. In the first cut, all the features were implemented without much consideration that they have to be effectively hidden for other countries.

Here is how we managed to separate things:

1. Module “Regional”

We created a new module in ERPNext called “regional”. All country-specific doctypes, pages, reports, scripts can go here.

Note: All doctypes, reports and pages must have no default permissions so they remain effectively hidden.

Why regional? Because the words “internationalization” and “localization” had long and ambiguous spellings! Also customization does not have to be based on nations only, in a federated setup, even local governments can have their regulations

2. Put your setup script in: erpnext.regional.[country].setup

You can add your country’s setup script in the country folder for your country and in setup.py. Here you can create the custom fields and add permissions on reports and doctypes

Here you can:

  1. Add custom fields with frappe.custom.doctype.custom_field.custom_field.create_custom_field
  2. Add Custom Role for reports
  3. Add DocType permissions for frappe.permissions.add_permission
  4. Create other fixtures like tax defaults etc

3. Use hooks for automation in forms

Once you have setup custom fields, you can use the standard hooks.py system to extend functionality of forms.

4. Make reports, forms extensible where needed.

If you find that the reports and forms you want are not extensible, you should break them up so that they can be imported in your custom reports with additional columns.

Example: See how GST for India was implemented



Maybe enforce some naming conventions for Regional Doctypes.

For example, Regional Doctypes applicable to India should be prefixed with “IN”. Using the GST prefix may limit development in other countries where GST is also present.


More specifically, here is an idea.

Regional doctypes that are created at the country level should use prefixes as specified in ISO 3166-1

Regional doctypes that are created at the region/district/state level should use prefixes as specified in ISO 3166-2

Regional doctypes that are created at a level that is not specified in either of the ISO standards above can be evaluated on a case-by-case basis.

Is it possible to use a similar approach for industry/domain specific features?
like for separating schools from manufacturing/service?

1 Like

The first phase of schools separation is pushed by the Domain contribution.

This Issue will completely close out Schools DocTypes