This blog assists those who are struggling to set up some aspect of printing in D365 for Operations due to the limited documentation in circulation.
We had 2 scenarios at our customer site:
– Barcode printing.
– FollowMe printing.
Barcode printing is not meant to be complex, but when printing to screen or printer, it did not work. The reason was that the machine which generated the report must have the barcode font installed. When printing to screen a webpage is generated that contains the following content.
style=”word-wrap:break-word;white-space:pre-wrap;font-family:’BC UPC HD Wide’;”>
Recently we had a challenge to read uncommitted data from the Dynamics 365 for Operations database. Usually this is not required as you may retrieve dirty data. When using a business application, you should rely on correct and committed data as otherwise reporting might provide you incorrect data. However, if you find a very good reason to change the isolation level temporary, this post will guide you how to achieve this. (meer…)
In the past, I had written two blog posts about personalizations in Microsoft Dynamics 365 for Operations (at that time still called Dynamics AX). Some features are already enhanced and expanded in the past year. With the release of Platform update 5, Microsoft added the option to centrally upload a saved personalization file to multiple users at once. Before this update, each user had to import a smart personalization done by a user manually. In this post, I will guide you through the new options.
LCS is your friend in Dynamics 365 as long it is up-to-date. And I have seen it is not always the case. So I will share some tricks to force it.
There are some things you should know LCS is only updating 1 time a day and that is 10 o clock in the evening. But when you look in LCS you see it is not updated for a couple of days. So what’s next?
Last year I was creating an interface for products and their attributes. The funny thing was that the attributes did not appear in the interface, but on opening the form, all the attributes were there. So one begins to think what is going on! Where are my missing attributes?
Recently I wrote about 2 posts about localizing Microsoft Dynamics 365 for Operations. The first post was a general reading about supported countries and languages. The second blog did tell you how to add new languages in existing and new label files. In this post, I will tell you what effect a country can have on visible functionality in Dynamics 365 for Operations and how to create new country/regions.
As mentioned in an earlier post there were some restrictions in previous versions of Microsoft Dynamics AX. This would prevent an ISV or partner creating a correct localization for certain countries. The list with supported countries/regions was maintained in the kernel. New countries/regions were not maintained in the list. You could create a new country in the setup table, but it was not possible to use the new Country for localized content.
In the development environment, it is possible to add one or a list with countries/regions as property on development objects. the purpose is to have these elements only visible for content in legal entities for such a country. For example, there is a Bank revaluation feature available for Russia and Poland. Only in legal entities where the country is Russia or Poland you would be able to see menu items for this feature.
Country/region properties are supported on e.g. fields, menu items and form controls. The next example shows how a menu item is linked to three countries.
In Microsoft Dynamics AX2012 the list with possible values were limited and checked at the time of saving the application object. When the country was not in the supported list, you got an error message: “‘FA’ is not defined as a value in the Country Region Codes list.”
Luckily Microsoft did a good job and now we are able to setup our own Countries.
Create a new country
Now back to Dynamics 365 for Operations… In this version the countries are not limited anymore. In fact it looks at the Country/Region table which is setup in your environment. So, if a certain country was not provided in the default list with countries you can add it in this table.
I will show how to create a new localized element for a new fictive story. In my previous post, I revealed that Frisian is an official second language in the Netherlands. Looking at the history, you might learn that Frisia used to be independent in the past. At the end of the linked Wikipedia article you will read that there is a group of people which strives to have Frisia as a recognized independent country. Assume this group reaches their goal, there will be a new country with their own regulations. So possibly a Frisian ISV partner would like to create a localization for Frisia.
The first information you would need is the ISO country codes for a country to be setup in Dynamics 365. Assume the ISO alpha-3 value will be ‘FRI’ and the ISO alpha-2 value will be ‘FA’. The default country list within Dynamics 365 is setup where the Country/Region ID is filled with the ISO alpha-3 value. There is a separate field (ISO) for the ISO-2 value. So, to create the new country I will follow this pattern in my example.
To create a new language you have to open the Address setup form which can be found using the next menu path: Organization administration > Global address book > Addresses > Address setup. On the tab Country/Region you can create a new record like the screenshot below:
Use the country in developments
What is the importance of the ISO field on the country/region table? This field is the key value for managing the country specific features in the CountryRegionCodes property. To have e.g. a menu item only visible in Frisian legal entities, you need to provide the value FA in this property. To illustrate this example a new menu item was created and linked in the General ledger menu. It will be places just below the Ledger menu item in the next path: General ledger > Ledger setup > Ledger. Note that the menu item is created without considering best practices like using a label instead of a fixed value. In your solutions you should do it correctly. I only did it this way to have the label readable in the properties of the menu item.
If you enter a value in the Country Region Codes property which is not setup in the Country/Region table, the development environment is not raising an error. This is intended as it could be the case that some developers in a team does not have an actual database with the correct countries.
When the solution was build, we can test the behavior initially in another country. The USMF company is a legal entity in the United States. When you look at the menu, you will notice that the new menu item is not visible.
Now we have to create a new legal entity. You can do this using the next menu path: Organization administration > Organizations > Legal entities. When this form is opened, click the new button to create an additional legal entity.
In a new dialog you can provide the Name, Company code and the Country/Region. The last mentioned field is a mandatory field as features should be dependent on the provided country.
If we change the legal entity to the new created Contoso Consulting Frisia, we can look again at the General ledger menu. Now you will notice that the new menu item is visible.
If it is not working initially, you probably forgot to build the model and all referenced models if you are using a development machine.
There is more…
If you create localizations for new countries, be aware that electronic files are now created and maintained with a new framework called Electronic Reporting. In previous versions of Dynamics AX e.g. outbound payment files were created using classes or Application Integration Framework. Now the creation of those files is configurable. Many configurations are provided and maintained by Microsoft, but you can extend them or create your own. There are also reporting requirements which are not related to bank accounts, but related to government regulations. An example of this is the EU Sales list for the Netherlands. To be sure this file is limited to the Netherlands only, also the Electronic reporting supports country/region configuration.
Also here you have to use the ISO alpha-2 coding for specifying countries. It would be possible to add more than one country for a certain Electronic reporting configuration.
Note that the SEPA payment file formats are also slightly different per country. As it is possible to have bank accounts from other countries in your organization, there is usually no limitation on the country codes for payment file formats.
Although it will not be a daily business to deal with new countries, you will for sure have an overview on the country specific options in Microsoft Dynamics 365 for Operations.
That’s all for now. Till next time!
Some weeks ago I wrote a post about the supported countries/regions and languages in Microsoft Dynamics 365 for Operations. This post is having technical information how to create a new language. While reading this post, you will also get more background information about do’s and don’ts and you will learn more about my country like my previous post. Also, if you are not a developer, it would be an interesting read. Then just ignore the technical details you don’t understand.