What is the Localisation Strategy for D365 Business Central?
Local functionality and localisation strategy for D365 Business Central – How it works
Localisation can be referred to as the process of adapting software solutions to meet country-region specific laws and regulations. Microsoft have vast amounts of global customers who operate businesses in multiple locations and sites. Out of the box ERP global capabilities and functionality is the ideal ERP software solution for such companies who operate in multiple jurisdictions – and where Dynamics 365 business central delivers on this! – you can quickly and easily set up all your companies / locations in Business Central and run your end-to-end business operations on one connected platform.
Dynamics 365 Business Central currently has a localised version for 156 countries, enabling organisations who operate in multiple jurisdictions run their businesses on one connected platform.
This recent blog from Microsoft provides an update on the descriptions of functionality, regulatory compliance and other local functionality that currently applies by region.
D365 Business Central has a combined localisation strategy inclusive of both Microsoft-led and partner-led models. The following updates from Microsoft shows that Dynamics 365 Business Central is always global ready and where localisation strategy is key to its ongoing research, development and innovation.
What is the Localisation Strategy for D365 Business Central?
Dynamics 365 Business Central currently has a localised version for 156 countries, if your company operates in multiple jurisdictions, you can set them all up in Business Central and run your businesses on one connected platform.
Business Central has a combined localization strategy inclusive of both Microsoft-led and partner-led models. In this section, you can see descriptions of functionality that applies to the countries/regions where Microsoft provides the regulatory compliance and other local functionality.
For a list of currently supported markets, go to Country/Regional Availability and Supported Translations.
Dynamics 365 Business Central Local functionality
The following table provides links to articles where you can learn about the local functionality for each country/region.
|Austria||Austria Local Functionality|
|Belgium||Belgium Local Functionality|
|Czechia||Czech Local Functionality|
|Denmark||Denmark Local Functionality|
|Germany||Germany Local Functionality|
|Finland||Finland Local Functionality|
|France||France Local Functionality|
|Iceland||Iceland Local Functionality|
|Italy||Italy Local Functionality|
|Netherlands||Netherlands Local Functionality|
|Norway||Norway Local Functionality|
|Spain||Spain Local Functionality|
|Sweden||Sweden Local Functionality|
|Switzerland||Switzerland Local Functionality|
|United Kingdom||United Kingdom Local Functionality|
|Canada||Canada Local Functionality|
|Mexico||Mexico Local Functionality|
|United States||United States Local Functionality|
|Australia||Australia Local Functionality|
|India||India Local Functionality|
|New Zealand||New Zealand Local Functionality|
What is the Localisation Strategy for D365 Business Central? – Other countries/regions
Business Central is also available in other markets through localisation apps. If a Microsoft partner has developed a localisation app for your country/region, you can find it in AppSource.
Why Choose D365 BC for your Development of a Localisation Solution?
If you want to bring the capabilities of the Dynamics 365 Business Central to your local market, then there are several reasons why you would want to choose Dynamics 365 Business Central:
- Easy to translate and strong base capabilities ready for localization.
- Reach more customers by showcasing your localization apps on Microsoft AppSource.
- Dynamics 365 Business Central provides a proven ERP platform and application for your localization apps, which adapts functional areas to the requirements of the local market.
Localisation apps are simply apps for Dynamics 365 Business Central – learn more about getting onboarded as an app publisher here: Get Started with Building Apps.
Localisation apps functionality
Localisation apps contain a set of functionalities addressing local requirements that fall within one of the categories below. Make sure to split up your localization apps at minimum according to these categories:
- Regulatory requirements– local functionality that helps businesses fulfil their legal requirements, such as tax reporting, local GAAP, and other regulatory requirements.
- National standards requirement– local functionality that addresses local standards, such as banking and payment formats, address formats, or local interpretations of global standards.
- Market requirements– nice-to-have, competitive requirements – local functionality beneficial to the productivity business processes in a country and thereby adding value to business but aren’t required from a regulatory perspective.
Service availability in other countries
Follow this page for information about planned country and regional expansions of Dynamics 365 Business Central.
Product scope for localisation apps
Apart from fulfilling the technical checklist for your app, the minimum viable product scope for localisation app is:
- Local Regulatory Features.
- Tests for Local Regulatory Features.
- Upgrade code for localisation apps.
- Set up data Rapid Start package for the localization app.
- Translation of a localization app to local language(s)and base app if you’re the first partner enabling localization for the country (Learn more about Dynamics Translation Services).
- Translation of the localization app’s documentation. For more information, see Translate the Help and Translate documentation files.
- National Standard Features (local part) are recommended to be built as an app– separate from the localization app.
- Market Required and Local Competitive Features are recommended to be built as an app– separate from the localization app.
- Using .NET assemblies in your localization app will fail in the technical validation of an app. Instead, contribute to C/AL Open Library GitHub repository with requests you have for .NET.
- It’s recommended to logically break down the full local functionality set at a minimum within the above categories. This approach provides optimal flexibility for customers to choose what they really need in terms of local functionality. And it makes sure that critical pieces of local functionality don’t break upgrade processes nor are upgrade heavy.
- Most customers in the local market will need most of the local regulatory features. In the category of local regulatory features there will be some features that, even though they’re legally required, apply to companies of a certain size, revenue threshold etc. Such situations are opportunities to further logically breakdown localization apps into smaller focused-functionality sets.
- Consider separating localization functionality by the frequency of changes to smaller localization apps. If for example, your local feature contains one part that is stable and one part that is frequently changed based on regulation changes, make sure to keep the stable part as one app and the changing part a separate localization app. This approach ensures better test coverage, faster response to changes and fewer upgrade issues.
- Use worldwide frameworks available in Dynamics 365 Business Central (W1) when building features for, such as VAT reports, banking formats, data exchange, and others where most functionality is common to all countries but there are some local rules or business formats that are extensions of global frameworks or formats. Make sure to familiarize yourself with such frameworks to reduce effort, reuse code, and properly utilize extensibility points and integration events. If you notice opportunities for improvements in such frameworks or missing extensibility points, make sure to contact us to work together in improving this.
- Consider rethinking local reports by categorizing the reports that you want to include in your localization app(s) in following categories: reports printing lists could be converted to list pages and offer more functionality using Excel add-in, reports providing insights or aggregating data could be converted to Power BI reports and dashboards, frequently customized reports (local document reports like invoices, credit memos…) could utilize Word document layouts so customer’s power users can easily customize them, for all others fall back to RDLC reports
- Prepare a setup data RapidStart package for the production company and translate to local language(s).
- Consider preparing a local demo data RapidStart package for the evaluation company and translate it to local language(s).
- Prepare setup guides (wizards) for areas that are complex to set up to help users enable, discover and have a good first experience using your localization app.
- Fork the Dynamics 365 Business Central documentation from public GitHub repository. Such an approach to documentation can help when other partners or ISVs take dependency on your localization app. For more information, see Configuring the Help Experience.
- Consider converting field-based documentation to task-based documentation using tooltips and Dynamics 365 Business Central documentation GitHub repository. Rulesets can help you ensure, for example, that no fields or actions are missing tooltips.
- If your localization app(s) are extending Business Central data model with new tables and/or fields, you must set the DataClassification property correctly. Localization apps with fields having the DataClassification property set to ToBeClassified will be rejected. Read more on Classifying Data in Business Central here.
- If you’re converting an existing localization (developed in C/AL) to localization apps (check this video(requires PartnerSource access)), as described in technical checklist for your app, you’ll need to set the ApplicationArea property on UI elements that you want to make visible in Business Central. To help you with that use NAVApplicationAreaHelper PowerShell command let to do this in bulk.