Segregation of Duties: Dynamics AX meets the financial auditor (part 3)

In the previous parts the present way of handling Segregation of Duties in AX was covered. In this final part some improvements or if you prefer some open topics will be commented on.

Date dependancy or versioning

When looking at the form where Segregation of duties rules are setup and maintained and one thinks of the importance of such rules it is a pity that these rules don’t have versioning or a date of when it became active or something similar. In other AX functionality in many cases a rule or version must be activated but for Segregation of duties rules none of these things are present. I hope that in future versions of AX (Dynamics 365 for Operations) this will change and some thought would be put in versioning (and store the old versions of a rule) .

Maybe Microsoft wanted to add this functionality already because when looking in the AOT one can notice that there are two date fields that could be used for versioning. These fields are not standard shown on the form of the Segregation of duties rules, but they are part of the table anyway. So maybe in the future there will be functionality added  These fields are shown in the frame below.

Clean Up table containing resolved conflicts

As mentioned earlier when conflicts are resolved the resolution of the conflict is stored for future use. This can be both  wanted  or unwanted depending on how you look at it.

It is wanted because it shows that the Segregation of Duties in in place and working. It can be unwanted when a conflict is allowed, to resolve an issue for which temporarily more access rights where necessary. However this resolution is kept and can’t be deleted from AX using one of the forms. When the role is assigned again no conflict will be shown! To avoid this it can be useful to clean the table from these resolutions using the AOT (or an X++ or SQL script).

Changes to functionality of AX

As an AX environment is a dynamic environment changes to this environment will occurr on a regular basis, will it be an upgrade by Microsoft, installing an add-on or changes created by the organization itself or its implementation partner. When additional functionality is added, or existing functionality is changed, being the introduction of new buttons, new duties or new privileges or changing existing ones, the Segregation of Duties must be evaluated to determine if changes are necessary in the setup of the rules (are new rules necessary, can we dispose of rules, must we change existing rules).

To keep it short, once you start using Segregation of Duties in AX it must be maintained and be a part of a change procedure of an organization.

Standard roles and standard AX

When looking at the standard AX roles in regard to Segregation of Duties it becomes clear that Microsoft created AX and the AX standard roles that support business processes, but not always had a keen eye for Segregation of Duties. As an example I would point out that creating negative purchase (RMA-orders) and creating normal purchase orders are processes that you would normally split, because inbound and outbound inventory tranactions shouldn’t be handled by one role. In the standard roles these processes are not separated. Also in the security elements this is not or not reflected. These anomalies will be encountered when a Segregation of Duties policy must be setup in AX.

So when a Segregation of Duties must be implemented it might well be, depending on the goals to achieve, that security elements must be added (privileges, duties, roles) in order to be able to ensure that it will work.

Kaya Consulting and Segregation of Duties

As one can understand is the above a result of coping with Segregation of Duties issues at various customers, working in various branches that have to deal with their own risks. It is also observed that this important issue is not always covered during the initial setup of AX at a customer. However it is an issue that should be addressed during an implementation or upgrade of AX.

When struggling with issues regarding Segregation of Duties and when help is needed give us a call.

Kaya Consulting has several consultants available who can assist with the setup of a Segregation of Duties policy (the SoD Matrix), implementing it in Dynamics AX (consisting of reviewing the existing security roles, creating new security roles and new security elements, setup of the Segregation of duties rules in AX) and documenting it, so the financial auditor gets a clear insight of what is going on in an organization for a Segregation of Duties point of view and IT-support staff knows how the Segregation of Duties can be maintained.

Segregation of Duties: Dynamics AX meets the financial auditor (part 2)

Setup and validation of Segregation of Duties rules in AX

Prior to the setup of the Segregation of Duties rules in AX itself they should be determined by the organization (create an SoD matrix). Next step is to determine which Duties contain access to the functionality that must be checked when given access to. In this step the standard Security Development Tool of AX can be used. When all this has been done the actual setup of the Segregation of Duties rules can be undertaken.

Setting up all Segregation of Duties rules can be a time consuming, depending on the amount of duties that need to generate a conflict. This can especially be the case when Duties have been copied  to be used in various roles, but the prime entries are still present in this Duty (for instance sales order related access is still present in the copied duty whereas simultaneous access to purchase and sales information must be prevented). When a rule is setup it might look like below (this is a complete fictional example). The fields First duty and Second duty are of course the most important fields and for that reason these fields are mandatory. All other fields are more or less of an informational level.

We advice to add some fields to this form in order to make setup easier and to be able to check if proper duties have been used for the setup. For that reason it is very useful to add the AOT name tot he form to both duties; this can be done by personalizing this form.

Once all setup has been done it is time to use rules for what they are intended for, namely to validate if users have received too much access to functionality of AX. However this validation can also be used to verify if a role grants in itself  too much access to AX. Validation can and is performed at various moments.

With the button on above form the validation can be performed. In this way a check is performed on the existing roles if they are in conflict with the rules setup. Be aware that all rules must be executed one by one (!) and that roles present in AX are validated, so also roles that are not used or will not be used (because new roles are created that must be used to assign to users). In case validation errors are shown appropiate action can be undertaken. i.e. change roles in order to resolve to conflicts.

When a user gets a new (additional) role assigned the validation of segregation rules is performed automatically. In case conflicts are present a message is shown indicating what rule is violated.

Apart from this automatic validation there is also an option present in order to establish a periodic validation. This can help to ensure that no violations of the Segregation of Duties creep in without being noticed and evaluated.

Go to System administration > Setup > Security > Segregation of duties > Verify compliance of user-role assignments

1. The validation can be executed as a batch-process (1)
2. Use button “OK” to execute the validation (2)

 

When the validation is completed AX will display an Infolog with all validation errors showing below information per conflict:

• User id;
• SoD validation rule name;
• Role 1 in conflict;
• Duty in conflict within role 1;
• Role 2 in conflict;
• Duty in conflict within role 2.

 

An example of such a message would like shown below.

When conflicts arise these have to be resolved. The person responsible fort he Segregation of Duties should be informed and he/she should take appropiate action like assigning user(s) to other roles, reassigning roles to users, change configuration of user roles or SoD rules or accept the violation of the conflict. We will now have a look at how conflicts can be resolved.

Resolve Segregation of Duties conflicts in AX

When a user gets an additional role assigned and there is a Segregation of Duties conflict a message will be displayed.

After pressing Yes AX will display an Infolog with details as well as the form “Resolve segregation of duties conflicts”:

Find all SoD conflicts in AX

All conflicts identified by AX are listed in the form “Segregation of duties conflicts” (path: System administration > Setup > Security > Segregation of duties > Segregation of duties conflicts):

Note that all conflicts that occurred remain in AX and SoD rules related to conflicts cannot be deleted from AX. This gives an auditor an overview of all conflicts that have appeared in the past. However actions undertaken due to a conflict have to be retrieved from other parts of AX.

The field resolution (not listed in the screen print above) contains information regarding the status of the conflict.

Status can be:

• None: conflict to be resolved (buttons Deny assignment and Allow assignment are available)
• Override: conflict resolved (buttons Deny assignment and Allow assignment are not available).

 

Find unresolved SoD conflicts in AX

To find only unresolved SoD conflicts follow the path System administration > Setup > Security > Segregation of duties > Segregation of duties unresolved conflicts:

This resembles the form where all conflicts are shown. Only records with field resolution populated with “None” are shown. In this form a filter can be applied to find the conflict on hand, usually a filter is applied on UserId, like shown in the example above.

Allow SoD conflict

Based on the actual Segration of Duties policy it can be decided that a conflict can be allowed. It might seem strange to allow a conflict, but bear in mind that it can occurr that in some cases some staff members must be allowed access rights that they normally would not be granted. In these cases an exception can be made by allowing the conflict.

In order to do so, select the record containing the conflict and click the button “Allow assignment” (1).

When the button “Allow assignment” is activated AX will display a dialog where a reason for override can be entered.

 

It would be helpful to populate this field with a note that make sense. Some suggestions might be:

• Direct based on the SoD policy of the organization (known conflict)

Date of approval

“Known conflict” + communicated to person responsible for SoD policy

• Based on approval by person responsible (unknown conflict)

Date of approval

Name of person who approved the conflict

Additional text as determined by the approver

Important! After assignment is allowed one must return to the user form and assign oncemore the security roles that were not allowed initially. The system will now allow the role assignment.

Note: Once a SoD conflict has been allowed for a user, there will be no future conflicts displayed for this user and SoD rule combination. So in case a new conflict must be shown tables in the AOT have to be edited!

Deny SoD conflict

On the same form where SoD conflicts are allowed they can also be denied, so follow the path System administration > Setup > Security > Segregation of duties > Segregation of duties unresolved conflicts.

In case a conflict is not allowed, select the record with conflict and click the button “Deny assignment” (1).

The role with validation errors is not assigned to the user. However, if you were assigning two roles with a conflict in between these roles, one of the two was properly assigned while the other not. In case the SoD validation conflict is not approved, you must ensure that the correct role from the conflicting pair is assigned to the user. This may require unlinking the assigned role and linking the other role to the user instead. In case you were assigning one role in which a SoD conflict exists this role is not assigned and can’t be assigned by trying again (same SoD conflict will be reported.

Make sure that roles  that are known to contain a SoD conflict are listed in a SoD Matrix and can be assigned to users.

Segregation of Duties: Dynamics AX meets the financial auditor (part 1)

Organizations at risk

Every organization has to deal with the risk that staff might be able to undertake fraudulent actions whilst at work. This can be actions like direct theft, paying out fake invoices, paying out actual invoices to “wrong” bank accounts. But as mankind is creative there are lots of other cases known where employees took advantage of there employers in an illegal way. In order to assess these risks and to decrease these risks financial auditors check work processes and to what extent they contain risks at fraudulent actions and advice companies how to improve their work processes in this area. As work processes are nowadays often supported by (ERP) software the audit performed usually extends to the way work processes are configured in this software. As Dynamics AX is also used to support work processes often configuration of Dynamics AX is checked by and commented on by financial auditors.

Financial auditor at work

As financial auditors not only check the financial well being of an organization but also check the administrative organization and the way an organization has guarded itself to prevent fraudulent actions of its staff and to what extent risks are present in the way work processes are configured in Dynamics AX. Given this,  financial auditors will check the configuration of security roles of Dynamics AX in an organization and will pose questions in what way this configuration helps to prevent fraudulent actions of staff. Usually employees of Financial or Accounting department(s) will receive these questions. Segregation of Duties is in common part of the answer to such questions.

Often also an authorization matrix is present in an organization. This will of course also periodically be audited by the financial auditor. The financial auditor will have a look at the way security roles are set up and to what extent they are covered by the authorization matrix and to what extent they are in line. This also helps them to get an idea if a Segregation of Duties is in place at an organization.

Apart from security roles usually at organizations there are also mandates in place. Usually they are used in workflows in order to establish who has to approve a purchase order or a received invoice. The financial auditor will for this reason also have a look at the way workflows are setup in order to determine if mandates are properly used.

Financial auditors, especially working at larger accounting firms, often have a keen eye for users with Administrative access rights. These access rights are not only handed out to actual users, like system administrators and application managers but also to service accounts. This will lead to questions like why has helpdesk employee X an administrative like account in AX, why has interface Y an administrative like account in AX. As it turns out in these cases is it not always necessary to grant these administrative rights. So in order to avoid to answer these ackward questions, it is better to create roles that exactly grant what is necessary to perform tasks at hand.

Security roles and Segregation of Duties

The above questions posed by Financial Auditors can usually be answered by showing an overview of roles assigned to users. With some effort these data can be retrieved from Dynamics AX.

When must be demonstrated in Dynamics AX how a Segregation of Duties is achieved it gets more troublesome. Not only are employees of Financial or Accounting departement(s) in common not the people that have setup the security roles in Dynamics AX but also it is difficult to exactly demonstrate in what way the setup of security roles helps to minimize the risk on fraudulent actions. Just showing the content of a role on a form is insufficient and doesn’t prove that the setup was exactly the same during the fiscal year that is audited. Even additional logging on various tables like vendor bank accounts is just additional evidence, but not conclusive evidence.

When a Segregation of Duties has to be demonstrated to a Financial Auditor one has to bear in mind that in general there are two approaches to setup security in Dynamics AX:

• Grant more than sufficient access rights to roles to perform their activities (overgranting)
  • Usually there are a limited amount of roles containing lots of duties or sub-roles
  • Users have often just one role
  • Specific privileges are not often used
  • Users don’t ask or just in few cases for more access rights after start of configuration; when this happens this is often resolved by granting a role containing even more access rights
• Grant just enough access rights to perform their activities (undergranting)
  • Usually there are various roles containing some duties and privileges
  • Users have often multiple roles
  • Specific privileges are regularly used
  • Users ask frequently for more access rights after start of configuration, this is often resolved by adding one or a few privilege(s) to a role or create a new role with limited access rights and add this new role as a sub-role.

Both approaches have their pro’s and con’s. In case of overgranting business processes won’t stop, but there is a risk that the scale of the access rights of the available roles is too large in order to speak of roles that support Segregation of Duties. There are cases known that warehouse workers were allowed to post packing slips, change addresses and could create sales invoices as well. This is very usefull to speed up a business process, but is of course quite tricky from a Segregation of Duties point of view.

In case of undergranting there is a risk that if a business process is not completely tested, especially when only the happy flow is tested, a business process can’t be completed. As more roles are necessary to complete a business process this means that more cooperation between Dynamics AX users is necessary, unless users get several roles assigned (that can lead to the same effect as overgranting). Undergranting leading to problems with completing business processes can easily arise when workflows are used. At a customer where security roles with limited access rights where used workflows stopped due to insufficient access rights, so some vendors couldn’t get paid in a normal way because invoices couldn’t be processed in case of a mismatch between invoice and purchase order (for the handling of mismatches a separate sub workflow was used) or due to missing date necessary to assing a workflow step properly (in the past when a lot of access rights were granted such data could easily be corrected, but in the new situation that was not possible anymore).

As one might understand already from a Segregation of Duty point of view undergranting is the approach that helps best to be in control, but it also implies that business processes must be tested more thoroughly, especially the way exceptions or data errors are handled. This is even more important when workflows are used.

In real live it can also occurr that an organization starts with one approach (overgranting) and switches to another approach (undergranting). This can lead to all kinds of complaints of users that they can’t do their work anymore. When the switch is made from undergranting to overgranting usually there are no complaints of users, but controllers and financial auditors are usually not very fond of such a switch as they increase the risk that fraudulent actions can be undertaken. So in general such a switch is quite uncommon.

Another consideration is that standard AX roles are not (all) created to support an organization where Segregation of Duties is vital. A lot of standard roles contain access rights to both Inbound and Outbound activities. Usually this is something that financial auditors disapprove of, so a proper setup of security roles involved leads in a lot of cases to the creation of new roles where inbound and outbound duties are split or even to splitting duties that contain too many access rights. In various cases it might even be necessary to create additional duties and privileges in order to achieve a proper Segregation of Duties.

Segregation of Duties in AX

In order to ensure that the setup of security in AX is compliant with Segregation of Duties as the organization it intents, adviced or not by the financial auditor,  it is possible to actually configure a Segregation of Duties in AX. In the module System administration (system administration – setup – security – segregation of duties) is a form present where the Segregation of Duties can be setup. In this form the Segregation of Duties rules can be defined.

Access to this to functionality is controlled by the privilege SysSecSegregationOfDutiesMaintain which is part of the standard Security Administrator role. So according to Microsoft the setup of the Segregation of Duties should be performed by an AX Security Administrator. But given his or her IT background the setup of these Segregation of Duty rules can’t be done by by a AX Security Administrator alone. Usually input from the Financial Department is necessary as this department is usually responsible for internal control and auditing, so Segregation of Duties is their cup of tea. So what often can be noticed is that Segregation of Duties is setup and maintained as a result of close cooperation of Financial and IT department. This is even more true as the setup of security roles is an activity where the AOT and security development tool of Dynamics AX are used, these are usually the play ground of the IT department, but they lack usually the business insight necessary to establish a proper Segregation of Duties.

As mentioned the term used is Segregation of Duties. This means exactly what it says only a Segregation of Duties can be configured in Dynamics AX. Where-as in Dynamics AX in the end access to entry points (menu-items) is controlled by privileges it is not possible to configure a Segregation of Duty rule based on privileges, this can only de done on duty level. The standard roles present in Dynamics AX are setup in order to ensure that business processes of organizations are supported, however these roles are not always (or one could say quite often) not compliant with requirements that a proper Segregation of Duties demands. In these cases an additional Duty has to be created (it can be useful to name these SoD_XXXXX, so it is clear that these duties are specifically created for Segregation of Duties purposes).

How to solve Microsoft Office Add-in authentication error in Dynamics 365 for Operations

However I’m currently extremely busy on several projects and also preparing some speaker sessions for a local Dynamics community and also the Summit EMEA 2017, I would like to share a solution to solve an authentication error when using the Microsoft Office Add-in. You will probably not face this issue when you are using machines in your own domain.

(meer…)

How to educate your ERP system

What kind of child do you have?

Your ERP system is a living, breathing thing and much like employees and your children: you only get the best out of them based on the effort you put in them, the attention you give them, the treatment you give them and what education you give them.
The innocent teen-girl artificial intelligence chat robot named Tay that Microsoft launched, turned into a Hitler-loving sex robot based on tweets received from the weirdos on Twitter in just 24 hours. (Source: Telegraph). If you still have an old on premise ERP system, locked away sound and safe, that only has the occasional chats with other business applications, you don’t have anything to worry about, or do you?

If you are running your business on the latest cloud based ERP system, having business intelligence and machine learning capabilities, mashing your trusted data with all kinds of information received from the internet (of things), you might have a lot to worry about, or don’t you?

 

Who is teaching?

To answer those questions, we have to answer two other questions first. The first question is “who is talking?”. In other words, do we trust the source of the information and where does that source gets his information from?
The second question is “what does your Intelligent ERP system do with the information received?”. If the information received is corrupt and your ERP system is taking actions based on that information, you have something bad going on. An example: your ERP systems prints an aging report of your customers that owe you money. Wouldn’t it be nice to mash your aging report with data telling if any of your regular, well trusted, customers are subject to a lawsuit or are even filed for bankruptcy?
Probably the answer is yes, but is this something that your ERP system should process automatically, or should a human being be the interpreter of the information received? Is it even possible for human beings to process all the information coming from private databases or the internet?
And on top of this all, your ERP system is also getting information from hundreds of employees entering data. Will they input all data correctly or are mistakes made? And will your ERP system behave irregular because of those mistakes?

 

The pattern

The answer to all questions above and the reason why Tay got twisted can be explained in one word: “patterns”. If enough entities do or say the same thing, that thing becomes the truth. The one not acting accordingly is an anomaly.
The only point in monitoring all your data coming in into your (ERP) system is to detect the anomaly. Since it is undoable for most human beings to detect the anomaly in terabytes of (external) data or in any of the thousands of tables used by your ERP system, you need an anomaly monitoring system doing so.

Goodbye KPI, Hello Continuous Anomaly Monitoring

The old way of detecting anomalies is to define a KPI and everything exceeding the boundaries is an anomaly. For example, your revenue is between 1.5M and 2.5M each month. Everything outside these boundaries should be investigated. When the company grows the boundary values of each KPI should be adjusted accordingly. In our example to maybe 2M to 3.5M each month. With the company growing each year, this will become an iterative process.
This way of detecting anomalies is fine, but your BI is now mashing up data from your CRM system, your ERP system with machine learning capabilities and whatever it finds on the internet and you need hundreds of KPI’s to measure all that, or simply be happy with the few KPI’s that really define your business, ignoring the rest.
The alternative here is to use a continuous monitoring system that simply processes any data and find the anomaly for you. Such an anomaly detecting system can tell you that employee X for the first time in 12 year didn’t show up, it can tell you that revenue in the BFSI sector in the UK is down but goes up in The Netherlands and it adjusts the KPI boundaries for you based on the values interpreted.

 

Kaya Consulting tools

Kaya consulting has build a variety of tools helping you to make sense of your data. From anomaly monitoring systems to dashboards where you can define your own KPI’s. From continuous auditing systems to tools enforcing your data in a certain pattern. Our BI Analytics team is here to help you make sense of it all, give us a call to help you to unleash the potential of your data.

Please, Connect me if I’m Wrong!

After implementing Microsoft Dynamics AX and now Dynamics 365 already for years, there are features in the product that are missing or there are things wrong or not supported. There are some ways to provide feedback to Microsoft. This post is intended to get you familiar with Microsoft Connect. Also some of my thoughts on this tool will be described which should be picked up by partners, customers but also Microsoft themselves. (meer…)

5 reasons to join the Summit EMEA 2017

If you haven’t heard already, there will be a Summit EMEA 2017 coming April 4-6 in RAI, Amsterdam. This is a community-driven conference around Microsoft Dynamics products. Information about this event can be found on the next website: http://www.summitemea.com. Attendees can learn from other customers and product experts to excel their daily work. I will also be present and will act as speaker during multiple sessions.

But… why should you join this 3-day event? I noted 5 reasons:  (meer…)

NewYear = 2016 + 1; Info(“Happy new year!”);

On the last day of the year 2016 I was looking back at the past year.  It has been an extremely busy year. Business wise I was mainly working for two customer projects, managed to get our Data Validation Framework ISV solution into “AX7” and did some smaller tasks in between. In private I coached 2 baseball teams of my sons. In addition, I did contribute quite a lot on answering questions on forums and writing some blogs. Together this felt like having work weeks of 60-70 hours. It was the year where I reached 20 years of work experience (all in ICT). In this blog, I will quickly look back at the 20 years and also look back at the year 2016. (meer…)

How to create a new country for localizing Dynamics 365 for Operations

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.

The background

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!

How to create a new language in Dynamics 365 for Operations

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.

(meer…)