Russian Localization of NAV 2016 for General Ledger: Correspondence of accounts

One of the difficulties to make Russian accountant work with modern ERP system of international vendor, such as e.g. Microsoft Dynamics NAV, comes from the difference of how the accounting transactions are recorded in the General Ledger. Nevertheless the major principle (debit equals credit per transaction) stays the same, there is a significant variation that requires a mind-break. Thus, going to implement an ERP system in Russia, you would need to prepare yourself to a tough discussion with local accounting team.

For many ERP systems it is common to use so-called "balancing" principle of transactions recording, where there might be numerous debit transactions, balanced just by one summarized credit transaction. E.g., for making a purchase of service from a vendor with VAT of 18% there will be a common transaction:

• Dt "Cost Account": 1,000 eur
• Dt "VAT Account": 180 eur
• Cr "Accounts Payable": 1,180 eur

But, the typical transaction for Russian accountant should always be recorded double-sided:

• Dt "Cost Account": 1,000 eur - Cr "Accounts Payable": 1,000 eur
• Dt "VAT Account": 180 eur - Cr "Accounts Payable": 180 eur

or, speaking by NAV G\L terms:

• Dt "Cost Account": 1,000 eur
• Cr "Accounts Payable": 1,000 eur
• Dt "VAT Account": 180 eur
• Cr "Accounts Payable": 180 eur

In order not to spoil W1 version of NAV and not put to G/L Entries four records instead of three in our sample, the standard G/L Entry table logic has been kept the same in Russian localized version of NAV. However, to satisfy the needs of Russian accountants who got used to the double-sided style of recording transactions, few new special tables have been introduced to localization:

• Table 12400 "G/L Correspondence"
• Table 12401 "G/L Correspondence Entry"
• Table 12402 "G/L Corresp. Posting Buffer"

The "G/L Correspondence" table contains the combinations of debits and credits of the accounts, used in all posted transactions. It is filled automatically and users do not interact with that.

The main table that we are interested in is "G/L Correspondence Entry" table. It contains the records of "G\L Entry" table, represented in a special double-sided fashion:

It contains "Debit Account No." field and "Credit Account No." field and amount for that transaction. This table allows us to see the transactions exactly as it is commonly used in Russia:

• Dt "Cost Account": 1,000 eur - Cr "Accounts Payable": 1,000 eur
• Dt "VAT Account": 180 eur - Cr "Accounts Payable": 180 eur

This table is showed in Navigator when you want to see the major books your record has been posted to, if G/L Entry has been made:

Depending on the setup, this table can be either filled every time the posting has been made or afterwards using a batch job for non-processed entries. To enable automatic posting of G/L Correspondence, go to General Ledger Setup and activate "Automatic G/L Correspondence" flag:

To run a batch job, go to ***/Departments/Financial Management/General Ledger and select "Create G/L Correspondence" task:

Enter the number or range of transactions (note, not the Entry No. for G/L Entry, but the Transaction No.) from which you want the process to start:

and press OK. To start from scratch, enter "0.." as a value. If you want to rebuild fully the table, just first delete all the transactions from 12401 table and run batch job with "0.." value of transaction No. Note that it might be time-consuming and it is recommended to be done as a night activity - users will not be able to post transactions to G/L Ledger during this batch process.

This is basically all about tables. Next time I'll show you more nice localized functionality based on financial correspondence, used in Russia. Stay tuned!