We are implementing ERPNext for a multinational client with operations in India, Saudi Arabia (KSA), and Egypt. All companies are managed under a single ERPNext site with the following structure:
- Parent Company (holding entity)
- India Company
- KSA Company
- Egypt Company
ERPNext’s multi-company architecture allows this setup natively, and is a key reason why it’s adopted for global operations. However, when enabling country-specific compliance using regional apps (India, KSA, Egypt), we encountered serious limitations that make multi-country deployments unmanageable.
Issue Category 1: Field-Level Conflicts
Several localization modules—like the Egypt compliance module erpnext_egypt_compliance—inject mandatory custom fields into global doctypes like Company, Customer, and Sales Invoice, without any logic that restricts them by country.
Example:
After installing the Egypt module, the following field is made globally mandatory:
{
"dt": "Company",
"fieldname": "eta_default_activity_code",
"reqd": 1,
"fieldtype": "Link",
"options": "ETA Activity Code"
}
This field is part of Egypt’s ETA e-invoicing framework, yet it becomes required for India and KSA companies as well. These companies have no legal or business relevance to this field, yet ERPNext throws validation errors unless these unrelated fields are filled.
Issue Category 2: Workflow-Level Conflicts (More Critical)
Beyond custom fields, these localization apps often include:
- Custom validations
- Print format overrides
- GL mapping logic
- Document event hooks
- Tax invoice formats
- e-Invoice submission logic (client and server)
Currently, none of these are scoped to company or country. For example:
- Sales Invoice validation hooks from Egypt may execute even for India-based invoices.
- Default tax accounts or tax categories set by one country’s localization may override or conflict with another’s.
- Print formats may be globally overridden or prioritized, affecting invoice generation across the board.
This leads to:
- Inaccurate tax reporting
- Broken compliance
- Failed submissions to country-specific e-Invoicing APIs
- Frustrated accounting teams
- High cost of ERP maintenance and patching
Why This Needs Immediate Attention
- Field-level issues break core forms and validation across companies.
- Workflow-level issues silently cause compliance and reporting errors.
- Makes ERPNext unsuitable for any serious multinational deployment without deep code patching.
- Violates modular design principles—localization should not pollute global behavior.
What Should Be Done Immediately (Action Points)
1. Enforce Country-Aware Design in All Localization Apps
-
All validations, required fields, and workflows must check:
if doc.company and frappe.get_cached_value("Company", doc.company, "country") == "Egypt": # run Egypt-specific logic
2. Establish and Document Localization Guidelines
- For both official and community modules
- Include patterns for safely injecting fields, scripts, tax logic, reports
3. Introduce a Localization Isolation Layer
- Allow site admins to explicitly toggle compliance rules per company
- Add a registry where only company-specific localization logic is executed
4. Audit Existing Official Modules
- India, UAE, KSA, Egypt modules should be reviewed for cross-company leakage
Conclusion:
This is not a minor bug—it is a systemic architectural flaw that prevents ERPNext from being used in multi-country businesses effectively. As more enterprises adopt ERPNext globally, the need to fix this becomes urgent.
We request the core team to prioritize this as a critical issue, initiate a review of all localization apps, and publish immediate guidance for multi-country compliance support.
Looking forward to the community’s and core team’s response.