Five Q&A on the fiscal year close process

16 Wednesday Dec 2015

Posted by Ludwig Reinhard in General Ledger

Tags

closing sheet, Opening transactions, trial balance

As the end of the year is just around the corner, I thought that it might be helpful for the one or the other writing something on the fiscal year closing process in Dynamics AX. The functionality I would like to focus on in this post is related to the opening transactions form that can be found in the periodic General Ledger (GL) section illustrated in the next screen-print.

In regards to this form respectively the functionalities behind, I would like to answer the following questions:

What is the effect of selecting/de-selecting the parameter „delete close-of-year transactions during transfer”?
What is the effect of selecting/de-selecting the parameter “create closing transactions during transfer”?
What difference does the selection “closing->opening” make in comparison to selecting “reset” in the balance account field of the opening transactions form?
What effect does the selection of a specific financial dimension have on the year-end closing process?
What happens if I enter/select an account in the “opening account” field of a specific main account?

Within the following, I will answer those questions based on sample data recorded in Dynamics AX.

Sample data & process
To answer the questions raised above, I decided to use simplified Balance Sheet and Income Statement data that are initially recorded in Dynamics AX at the beginning of the year (“Step 1”). Thereafter, a single financial transaction (“Step 2”) for the sale of products is recorded before the first periodic year-end closing process is run (“Step 3”). After running the first year-end closing process, the company’s auditor decided that an adjustment needs to be posted (“Step 4”) in the closing sheet. After posting the adjustment, the periodic year-end closing process is run again (“Step 5”). The following flow chart summarizes the process steps described.

The next screen-prints give you a more detailed accounting view on the transactions recorded. To understand the information illustrated in those screen-prints, the following conventions need to be taken into consideration:

The ledger account-financial dimension combination consists of a 4-digit ledger account and a 3-digit financial dimension. As an example, the combination 1000-001 represents the ledger account 1000 (“fixed assets”) and the business unit (“001”).
For illustrative purposes and to keep things as simple as possible, the most generic separation of a company’s Balance Sheet (BS) and Income Statement (IS) is made. That is, the BS is separated into fixed & current assets as well as equity & liabilities and the IS is separated into revenues and costs only. The transactions recorded for the different steps and the resulting BS and IS can be identified in the next two screen-prints.

Question 1: What is the effect of selecting/de-selecting the parameter „delete close-of-year transactions during transfer”?
Once the transactions for step 1 and step 2 are recorded, Dynamics AX generates the following voucher during the first year-end closing process irrespective of whether the parameter “delete close-of-year transactions during transfer” is activated or not.

The voucher in the previous screen-print shows you the transactions recorded in the opening period (“period 0”) of the new fiscal year and illustrates that the profit of the previous year is transferred to the main account-financial dimension combination “2100-001 Profit/Loss current year”.
After the first year-end transfer is posted and the adjustment requested by the auditors is recorded, the year-end closing process is run again. This time a difference in the vouchers recorded can be identified depending on whether or not the parameter “delete close-of-year transactions during transfer” is activated.

Case 1: Parameter “delete close-of-year transactions during transfer” activated
With the parameter activated, Dynamics AX deletes the first closing voucher and creates a new one.

Case 2: Parameter “delete close-of-year transactions during transfer” not activated
Without the parameter activated, Dynamics AX creates an additional voucher and leaves the first voucher unchanged. In other words, a so-called delta transfer and voucher is recorded.

Even though deleting an already posted voucher is against most GAAP, a setup with the parameter activated is often found in practice. In contrast to this “common practice”, “best practice” is not activating the parameter.

Question 2: What is the effect of selecting/de-selecting the parameter “create closing transactions during transfer”?
To identify what effect the activation of the parameter “create closing transactions during transfer” has, the previous transactions are entered again in a different fiscal year before the first year and closing process is run again.

Case 1: Parameter “create closing transactions during transfer” not activated
If the parameter is not activated, a voucher identical to the one illustrated previously is created. This voucher transfers the profit/loss of the current year to the respective account “2100-001 profit/loss current year” of the company’s balance sheet.

Case 2: Parameter “create closing transactions during transfer” activated
On the other hand, if the parameter is activated, additional transactions are created as of 31 December (highlighted in yellow color in the next screenshot).

The additional transactions created ensure that all accounts are posted against the current year’s profit/loss account (“2100-001”) at the end of the year before the opening transactions are posted at the beginning of the next year.
A major effect of activating the parameter “create closing transactions during transfer” is that users cannot identify the closing balance of the ledger accounts in the trial Balance list page anymore. The next screenshot provides an example of this standard behavior.

Due to the additional posting created and its effect on a company’s trial balance, common and best practice from a finance & accounting perspective is not activating the parameter “create closing transactions during transfer”.

Question 3: What difference does the selection “closing->opening” make in comparison to selecting “reset” in the balance account field of the opening transactions form?
Answering the third question is straightforward as selecting “reset” does not create any year-end closing transactions when running the year-end closing process. Rather than having the beginning balances created automatically, users have to enter them manually when selecting “reset”. As one can imagine this something that should not be done in a live environment. For that reason best practice is selecting “closing->opening” when running the year-end closing process.

Question 4: What effect does the selection of a specific financial dimension have on the year-end closing process?
Selecting a specific financial dimension in the financial dimensions tab of the opening transactions form as illustrated in the next screen-print …

… results in a voucher that records the company’s current profit/loss on the selected financial dimension. In the example illustrated in the next screen-print, the company’s current profit/loss is recorded with business unit “002”, while all other transactions are recorded with their original financial dimensions.

Stated differently, selecting a specific financial dimension in the financial dimensions tab of the opening transactions form does only have an effect on the financial dimension used for posting the company’s current profit/loss.
As only balance sheet accounts are affected by the year-end closing transactions, a possible application of this functionality is separating and identifying annual profits for different accounting situations, such as local GAAP, IFRS, etc.

Question 5: What happens if I enter/select an account in the “opening account” field of a specific main account?
If you are entering a specific opening account in the main account form as illustrated in the next screen-print…

..the year-end closing process uses this opening account for recording the opening balance transfer. The example shown in the next screen-print shows that the closing balance of main account 1000 is transferred to the opening account 1001 that is linked to main account 1000.

Entering an opening account in the way illustrated can be useful e.g. in situations where certain accounts are expired and replaced by other (new) ones.

At the end I would like to wish you a Merry Christmas & New Year holiday and hope that you enjoyed reading the posts published over the last months. Hope to see you again next year with more to come on the new Dynamics “AX 7”…

Parallel inventory valuation

09 Wednesday Dec 2015

Posted by Ludwig Reinhard in Inventory

≈ 2 Comments

Tags

Dual warehouse, Inventory valuation, Item model group

It was back in 2011 when I first noticed that Dynamics AX must have some functionality to do a parallel valuation (e.g. FIFO & LIFO) of a company’s inventory.

My assumption was based on a feature that I saw in the item model group setup window and that allowed selecting a second inventory model group. (Please see the next screenshot that was taken from an AX2012 demo system).

I started to google about this “dual warehouse” feature but could not find much and thus decided to test it with some basic item transactions. The outcome looked very promising but at that time, the functionality was embedded into the Eastern European AX2009 layer and I lacked the knowledge to make this feature generally available.

Earlier this year a friend came up with a question how to do a standard cost and weighted average inventory valuation for an item in parallel. I remembered that functionality and came across the following blog post.

Equipped with an AX2012 demo system and enthusiastic about the possibilities that this feature could offer especially for finance users, I initially tried activating the Russian dual warehouse configuration key, hoping that this key would make the dual warehouse feature generally available in my system.

Yet, after synchronizing my database nothing happened and my item model group window still looked the same as before including only one single inventory model.

I thought ok that would have been too easy and had a look at the available shared projects in my development environment and “bingo” I found a shared project with the term “dual warehousing”.

My next thought was having look at the built in country-region codes and modifying them simply by adding the country-code of the company I was operating in.

This was a bit work but I thought if it does the job it was certainly worth the effort. Yet, unfortunately only some functionalities were available and I permanently got error messages once I tried posting a purchase order, inventory adjustment journal and so on. As I did not want to abandon the field, I continued adjusting all other tables, forms, classes, etc. that were incorporated in the “RU_” shared projects without doing a detailed analysis of the code that I made available for users in my demo country “Germany”.

Finally I got through and recorded the following transactions to test the feature:

After recording all transactions, the on-hand item window showed the following data:

My next step was running the inventory recalculation jobs for my test item.

After those periodic jobs finished, the following adjustments could be identified in the item transaction form:

The inventory value report showed – in line with the identified adjustment – the expected inventory value of 450 EUR.

As no dual warehouse inventory value report is available, such a report still needs development based on the available data to show users the inventory value according to the second inventory model.

Summary & evaluation
The possibility to do a parallel inventory evaluation is very interesting especially in cases where tax authorities require a different inventory model.

Even if no immediate need for a second inventory model exists, the data generated by the dual warehouse feature can be very useful as they offer the possibility tracking inventory values in a different currency that allows e.g. identifying the efficiency of foreign currency hedging instruments.

Despite those advantages, the use of the dual warehouse feature goes along with the following issues:

Users can only make use of one single additional inventory model,
No dual warehouse inventory value report exists,
If the reporting currency differs from the accounting currency a parallel inventory valuation is not possible as currency effects will always distort the outcome,
The major issue in my opinion is, however, the “development footprint” that the provision of the dual warehouse feature leaves in your system. The next screen-print shows you some (!) of the tables and classes that are affected by the dual warehouse functionality.

As you can grasp from this excerpt, your whole AX system is basically affected by the dual warehouse functionality, which considerably affects your system’s upgradeability.

What is more, if you are not doing a detailed code analysis before making the dual warehouse feature available, you will end up with additional setup windows, form buttons and functionalities that you probably cannot setup without further investigation.

The last constraints lead me to the conclusion that the risks and potential problems of the currently available dual warehouse feature do by far outweigh its potential advantages especially for those of you that are only interested in a second inventory value figure based on a different inventory model. For the last requirement it seems much easier developing another inventory value report based on mathematical-statistical procedures that calculates the second, third … inventory value for you.

Management Reporter – Reports based on different Chart of Accounts

03 Thursday Dec 2015

Posted by Ludwig Reinhard in Management Reporter

≈ 4 Comments

Tags

Chart of Accounts, Dynamics AX, Financial Consolidation, Management Reporter

When doing a financial consolidation, financial data from different companies need to be combined in a single “consolidation” report. As the data that need to be consolidated are often based on different Chart of Accounts (COA), the question arises how ledger accounts from different COA’s can be combined into a single consolidation report. This question will be answered in the following based on a simplified example.

Example:
The financial data of company DEMF and BRMF need to be consolidated. While the first company (DEMF) uses a “shared” COA, the second company (BRMF) uses a local Brazilian COA. What makes things even more complex is that company DEMF records all transactions in EUR-currency, while company BRMF keeps all its books in Brazilian reals. The next screenshot shows you the COA’s and currencies setup for the two companies.

In order keep the example as simple as possible, only the bank accounts of both companies are considered for the following illustrations.

In company DEMF only one single transaction with a total amount of 10000 EUR has been recorded on bank account (main account) “110200”.

In company BRMF two local currency transactions have been recorded on the bank account (main account) “1.1.1.2.02”.

The exchange rate used for consolidation purposes is 300 BRL / 100 EUR.

Against the background of those data, a financial consolidation report should show a total balance of 50000 EUR or 150000 BRL in the bank accounts line.

To realize this, the following setup has been done in Management Reporter.

Step 1: Setup of the row definition
The first step in setting up the consolidation report is mapping the different main accounts in the row definition of the report. This mapping in done by specifying separate row links that hold the main account information of both companies. Please see the following screenshot for an example.

Step 2: Setup of the reporting tree Definition
The next step is setting up a reporting tree. When doing this setup, you have to make sure that a reference is made between the different companies and the row definition / row links established in the first step.

Step 3: Setup of the column Definition
The third step is setting up a column definition as illustrated in the next screenshot.

Please note that you need to link the different columns with the reporting tree elements if you want to report on the different legal entities.

Step 4: Setup of the report Definition
The last step in the report generation is the combination of all previous elements (row definition, reporting tree and column definition) into a report. Please note that you need to select the reporting currency check box before running the report if you want to do a currency conversion once the report that gets generated.

Result:
Once the report is generated you can have a look at the data in the various currencies setup in Dynamics AX. The next two screenshots show you the EUR-currency and BRL-currency report.