Raising up user satisfaction for Russian localized version of Dynamics NAV 2017 system: what regular accountant would expect

When Dynamics NAV ERP system is introduced to financial department of Russian company, it is often neglected by the users who got used to a different (local) accounting software. In order to mitigate this risk and increase end-user satisfaction, you should try to meet their expectations, especially if there is very little cost to implement some features that accounting users expect from a “normal” accounting system in Russia. Below you can find the list of the features, usually expected by financial users, and provided out-of-the-box as part of standard Microsoft localization of Dynamics NAV 2017 for Russia.

Automatic update of currency exchange rates (Central Bank) on a daily basis

Russian Central Bank provides web-service for update of currency exchange rates to Russian ruble for those currencies that you will use in your ERP system. Standard Russian localization supports built-in integration with this web0-service, you need just to setup a link to Central Bank and establish automatic update on a daily basis, e.g. schedule NAV service to run this feature every night: normally in Russia the currency exchange rates are known before 16:00 for tomorrow.

There are heavy reasons to make the currency exchange rates upload scheduled on a daily basis. It is inevitable that there will be a currency rate at every day, as by law it is required that currency transactions and transactions in conditional units (https://community.dynamics.com/nav/b/russianerpexperience/archive/2016/04/16/conditional-units-russian-alternative-to-currency) are posted also in Russian rubles at the rate of the posting date. Numerous currency exchange rate differences are calculated automatically based on those daily rates, including realized and unrealized currency exchange rate gains and losses, as well as currency prepayments (https://community.dynamics.com/nav/b/russianerpexperience/archive/2016/06/30/russian-specifics-of-processing-currency-invoices-exchange-rate-differences-and-advance-paymentsand ) related postings.

You can still have an option of manual input of currency exchange rates into your system, but it would be quite unexpected process by Russian accounting team, and there would be a huge risk of mistakes that would result in incorrect postings and even incorrect sales documents to customers, which is a serious issue.

There has been a good post about setup of currency exchange rates upload for Russian localization of NAV: https://community.dynamics.com/nav/b/katsonsnavblog/archive/2017/03/25/how-to-setup-import-of-currency-rates-in-nav2017ru-Russia

Automatic integration with electronic payments banking system

There are over 600 active banks in Russia at the moment. Practically all of them are using the same data format (.XML) for exchange with accounting systems, which is a sort of industry standard for Russian market.
There are three major options of organizing the accounting flow of banking operations:

• Create payment orders in electronic payments banking system, process payments there and then manually input the payment data into NAV financial journals for posting. This method is strongly not supported by Russian accountants, as they very much got used to automated integration. If you would offer them this method, this most likely very much reduce the level of user satisfaction.
• Create payment orders in electronic payments banking system, process payments and then export a daily bank statement from there as .XML file, which you would later on upload to NAV system as a bank statement for future reconciliation, transfer to financial journal and posting.
• The third option, the most preferred one, is to create vendor payment orders in NAV system, and then export them to electronic payment banking software as .XML file. When next day the bank statement is updated, you will export the confirmed bank statement and import it to NAV system back (as there are customer payments received and sometimes payments to vendors are not going through due to some errors in details or lack of money in the account :-) ).

The major issue to solve is to setup NAV in such a way that when importing .XML file, the vendors and customers would appear in the bank statement automatically. This can be achieved by mapping of certain details in Microsoft Framework data import. There are the following customer or vendor details that you can rely on:

• Company registration number (in some other countries also known as VAT registration number). in Russia it is called “individual number of tax-payer”, or “INN”.
• Company location code number, called “KPP” in Russia. If company will have numerous branches all over the country, it will have one VAT registration number but numerous company location codes, depending on the place of the offices. If company has just one office, then just one registration number and one location code number will be assigned.
• Number of bank account(s). Company might have one or multiple accounts in one or several banks. So the information of counterparty’s bank account, used in bank transaction, is also transferred in the bank statement.

So, you can setup the Framework mapping to recognize certain vendor or customer either just by company registration number, or a combination of company registration number and company location code number, or even by adding to this combination also the bank account number. The more detailed is the mapping, the more precise is the uploaded bank statement. However, you also need to ensure that all the payment details and company numbers are entered in NAV system card of vendor or customer in advance.
Normally a combination of company registration number and company location code number is used. Adding the bank account details might result in a fact that some customer will decide to pay you from his different bank account which you are not yet aware of, thus the mapping would fail and accountant would need to process this line of bank statement manually.

Automatic update of Banks details (“BIC”)

When making a payment order in Russia, you need to fill in the following basic information:

• Name, registration code and location code of the payer
• Bank name, bank code, bank corresponding account of the payer
• Bank account of the payer in this bank
• Name, registration code and location code of the receiver
• Bank name, bank code, bank corresponding account of the receiver
• Bank account of the receiver in this bank
• Date
• Payment order number
• Amount
• Payment description, with specific reference to the nature of the payment (e.g., whether it is a payment for the services or the items), as well as with indication of rate(s) and amount of VAT in this transaction.
• Additional details, such as e.g. the preference order of the payment (e.g., salary payments have higher priority than payment to regular vendor).

This is how the printform of the payment order looks like:

So, when accountant is creating payment order in NAV 2017 system, in order to speedup the process of data input there is a special reference table that is filled with bank details – bank full name, it’s official unique code (called “BIC” in Russia, or Bank Identification Code), correspondence account, bank address, etc. If this reference list is filled, accountant would need only to select this BIC number in the field of the payment order when making a payment to new Vendor, and all the rest information will be filled automatically.

In order to have this BICs reference active and always up-to-date, Russian Central bank is providing a special web service, which returns you the list of all active actual banks with their codes and needed details. You can connect to this service and fill in your BIC reference in NAV 2017 system automatically. By setting the integration active e.g. every night, you ensure you always have actual details of all the banks in Russia to speedup the bank accountant’s daily routines and increase user satisfaction of NAV finance module.

Automatic integration with local payroll solution (1C: HR&Payroll)

1C system has been very effective for managing HR information and Payroll calculations, with consequent reporting to state bodies about needed salary duties and taxes. Regardless the fact that Dynamics NAV has its own Payroll module which can be utilized, you will spend obviously much less efforts in implementation of 1C Payroll and integration of that with Dynamics NAV system.

Again, you may have your payroll calculations in this separate software, and manually input the results into NAV finance journal for posting. However it would be quite time-consuming process in the end, as you will have to enter the salary itself plus 5-6 different taxes for each person or cost center (depending on the level of details you need). So it is very recommended to setup an automated integration between local 1C Payroll software and NAV system to be able to make upload to NAV finance journal in automated way, based on pre-defined mapping of needed accounts.

This integration is not coming out-of-the-box for a standard NAV versions, but most Russian partners who implement NAV have the integration connector ready (e.g., ask Awara IT Solutions for that).

Automatic fill of vendor/customer card details by entering only company (VAT) registration number

This feature gives accounting users unique possibility to save a lot of time on entering details of customer or vendor to the vendor/customer card in the system. Tax office in Russia provides a web service, that you can feed with only the company registration number, and it would return you back all the details of the counterparty, e.g. full name and legal address. Setting up this integration will allow users just to enter vendor registration number into new card and get filled all the other details automatically.

Moreover, there is a usual problem for customers. According to Russian legislation, you need to provide your customers printforms of documents that contain certain customer details, such as actual customer legal address. If customer changes its legal address, there is a risk that he will not inform you promptly. This will consequently may result in incorrect sales documents, provided to that customer. Customer would not be able to make this cost deductible and will be unhappy. None needs unhappy customers ?. For that reason, setup this integration to be performed every night, and you will eliminate this risk: all details of your customers and vendors will be always up-to-date.

Automatic update of Russian list of country addresses (“KLADR”)

Another good option is to have a full imported Russian addresses classifier. It is a list that stores all the cities and streets and building numbers with correct zip codes in it. It saves a lot for data input and further analysis of data, e.g. sales by regions, organized by zip codes. All your customers, vendors and contacts would always have correct address details filled in their cards if you will setup this integration.

Summary: Russian accountants and staff from finance department got used to high level of automation. When planning your implementation or roll-out to Russia, do not sacrifice the abovementioned routines as they require only setup or very small investment, but it would bring the user acceptance of the system in Russia to a totally new, better level.