Setup and process for intercompany trade in Microsoft Dynamics AX 2012 R3

Dynamics AX 2012 R3 allows for the capability to handle intercompany trade transactions. Intercompany trade transactions allow organizations to sell products and services to other business units or legal entities within the organization for fulfillment of a customer order. This blog will outline the setup and process of creating a sales order for an external customer with the help of intercompany trade process.

For example, we have an organization with two legal entities, GCCI and USMF. GCCI receives the order from a customer, but does not have inventory to fulfill order. Therefore USMF will fulfill the order with their inventory and deliver directly to the customer on behalf of GCCI. For this to occur, GCCI will use the intercompany trade transactions process.

1. The first step is to create a vendor in GCCI in the USMF entity. A new vendor can be create by navigating to Accounts payable > Common > Vendors > All Vendors.
2. Next, let’s create a customer record in USMF for the GCCI intercompany customer. To create a new customer, navigate to Accounts receivable > Common > Customers > All Customers. Once the customer record has been created, open the customer record and open the miscellaneous FastTab. Then check the create intercompany orders option.
3. Then go to the general tab in the action pane and select Intercompany.
   
   Once in the intercompany menu, check Active to setup trading relationship. Under Purchase relation, select the vendor company and specify the intercompany vendor record created in GCCI.
4. In the purchase order policies tab, a set of options will be available for a user to select. These options dictate how the intercompany purchase orders and intercompany sales orders will behave. To fully understand the various options available for intercompany trade relation setup, refer to this TechNet article: Set up intercompany trade [AX 2012]. In this example, Post invoice automatically under Original sales order (direct delivery) and Post invoice automatically  under Intercompany purchase order (direct delivery) are checked.
5. In the sales order policies tab, the intercompany sales order tab lists options that dictate how the intercompany sales will function. In our example, the sales order numbering and customer payment journal is specified.
   
6. Once the trading relationship setup is completed, close the intercompany form and go to the GCCI company to begin creating the intercompany sales order. Keep in mind that after the intercompany trade setup is activated, the intercompany vendor account in GCCI will be automatically setup. To process an intercompany sales order, navigate in the GCCI entity to Accounts receivable > Common > Sales orders > All sales orders. Create new sales order and specify the customer for which the order will be fulfilled. Then proceed to fill the necessary information like item, quantity, site and warehouse, and etc. After the sales order is filled, select Header view in the action pane.
7. In the intercompany FastTab, check the Autocreate intercompany orders’ and Direct delivery options.
   
8. Then in the action pane, select Direct delivery. Specify the intercompany vendor account and then flag the Include flag. Then select OK.
9. An infolog will then appear indicating that a purchase order and an intercompany sales order have been created. Then close the sales order form.
10. Now the user will go to the USMF entity and navigate to Accounts receivable > Common > Sales orders > All sales orders. Locate the sales order that corresponds to the sales order created in GCCI. In this example, the intercompany sales order can be identified by number sequence.
    
11. Open the sales order and process the order as normal. At the end of the process, the sales order should show the status as Invoiced.
12. After successfully invoicing the sales order in USMF, go to the GCCI company and navigate to the intercompany purchase order. It can be noticed that the purchase order was invoiced automatically. Keep in mind that the status of the purchase order will appear as invoiced because we had set the option in the intercompany relation setup.
13. Navigating to the original sales order, you’ll notice that the status of that order will also show as Invoiced. Upon completion of the transaction, users can make and receive payments by using the AP and AR payment journals.
    

Module access level – specify which users can post to a period in AX 2012

In AX 2012, it is possibly to specify which user groups are allowed to post accounting transactions to a certain period for a given module by using the Ledger calendar form. The form is found in General Ledger>>Set up>>Ledger>>Ledger Calendar>>Module access level (please see screen shot below). Here, you can specify if All, None or specific user groups should be able to post to this period via the specified module. If there is a need to specify access for a group of users, the user group must be set up first. This is managed in System administration > Common > Users > User groups.

Below is a summary of the postings controlled by each module’s parameter in the above form:

Ledger

This parameter controls the posting of all journals in the modules General ledger, Accounts receivable, Accounts payable, Project and the posting of the periodic Exchange adjustment jobs in the modules General ledger, Accounts receivable and Accounts payable to the general ledger.

Customer

This parameter controls the ledger updates of Free Text Invoices and the exchange adjustment ledger postings caused by manual settlements via “Open transaction editing”.

Vendor (Supplier)

This parameter controls the exchange adjustment ledger postings caused by manual settlements via “Open transaction editing”.

Sales order

This parameter controls the ledger postings caused by sales order updates.

Purchasing

This parameter controls the ledger postings caused by purchase order updates.

Inventory

This parameter controls the inventory posting to general ledger via the journals Movement, Profit/Loss, Counting, and Inventory to fixed assets and also from the periodic job “Closing and adjustments”.

Production

This parameter controls all ledger updates from production journals.

Project

This parameter controls ledger updates posted by project invoice and on account invoice.

Payroll

Will be updated.

Sales tax

This parameter controls the posting of the periodic job “Sales tax payment” to the general ledger (when selecting “Update”).

Fixed assets

This parameter is currently without any function.

Bank

This parameter controls the posting to general ledger during bank account reconciliation when bank transactions are created.

Cost accounting

Will be updated.

Expense

This parameter controls ledger updates posted by expense reports.

Scenario based implementation using CRP Approach

A key consideration of choosing enterprise solution packages like Dynamics AX and Dynamics CRM over custom development is to accelerate time-to-value. Organizations are looking for extremely fast concept-to-cash realization cycles which require rapid value driven delivery. 

Package solutions offer high percentage of generic industry scenarios out of the box, which can be deployed rapidly to delight customers and realize business value quickly. While more complex and business specific scenarios can get injected later in a phased effort.
Idea in brief: Use Conference Room Pilots (CRP) to model business scenarios starting with ‘Out Of the Box’ solution and progressively refine scenarios through a series of CRP workshops to gain business SME acceptance. Deploy and release the solution to business in rapid cycles. 


  Considerations for CRP success:

1. Focus on modeling business scenarios rather than individual requirement fit-gap.
2. CRP iterations are short sprints demanding business decisions and execution in much shorter cycles than traditionally done.
3. CRP workshops bring business, IT and delivery teams in sync with solution. Hence these are best executed by consultants with advance capabilities in business understanding, application knowledge and delivery skills.
4. Rapid value driven delivery with tight change control & governance.

Benefits of Scenario driven delivery using Conference Room Pilots:

• Speed and quality – better, faster and cheaper delivery
• Opportunity for innovating, learning and improving in between delivery cycles
• With rapid iterative cycles, IT service providers can move beyond implementation to support users in technology adoption and consuming value from IT investments.

Microsoft Dynamics AX and IFRSS

Native Support for Parallel Accounting for transition to IFRS

Microsoft Dynamics AX have posting layers in the General Ledger and for consolidation that allow it to be one of the unique ERPs that allow for parallel accounting that is needed as part of a transition to IFRS. Microsoft Dynamics AX has 3 layers – one primary and two adjustment layers. The layers are Current, Operations and Tax. For example, the diagram below represents a USA public company listed in the United States that has a public holding company in Europe and needs to report in 3 formats: Tax for the IRS, US GAAP for the SEC and public filings in the United States and IFRS as adopted by the EU for group external reporting. Layer 1 is the ‘Current’ Layer in Microsoft Dynamics AX holds the US GAAP postings. Layer 2 is the Operations Layer and has any IFRS Delta postings. Fixed Asset can be posted in full for all layers so those do not require any deltas as they can automatically post into multiple layers by setting up a dependency through Value models. Effectively this allows the Fixed Asset Sub Ledger to have a full US GAAP, IFRS and Tax set of books in it. Any Tax adjustments or other Tax posting are made in the Tax Layer e.g. Section 179 accelerated depreciation for qualifying assets.

Figure: Microsoft Dynamics AX provides support for multiple posting layers such as current, operations and tax that provide it with unique capability to have native support for parallel accounting. Source of this screen shot is Microsoft Corporation.

Microsoft Dynamics AX has the ability to have different journals post to different layers. For example, I can have a regular GL Journal that posts to the Current (US GAAP layer in our example) and an IFRS General Ledger Journal that posts to the Operations (IFRS Layer in our example)

Figure: Microsoft Dynamics AX support the transition to IFRS with ability to support parallel accounting with different posting layers. In this screenshot, the IFRS GL Journal is posting to the Operations Layer for any IFRS Delta postings

The reporting structure in Microsoft Dynamics AX then allows you to define on the report where you would like the numbers to come from. We can setup a report for US GAAP by choosing the layer as Current and then we can use the same report or a copy of it by setting the source posting layer as Operations plus current and it would show us the IFRS numbers.

Figure: Cash Flow report in Microsoft Dynamics AX showing that the posting layer can be selected on the report definition allowing the same report definition to be used to get numbers in different accounting standards such as US GAAP, IFRS and Tax thus simplifying accounting and reporting greatly.

First Time adoption of IFRS (IAS 1)

IAS 1 requires that businesses adopting IFRS maintain a comparative year and also requires that an ERP system should be able to load or post manual adjustments for the IFRS opening balance in either the last period before the transition date and then roll-forward the IFRS opening balance or in the period of the transition date with a specific identifier in order to track and distinguish the opening balance adjustments for IFRS from regular transactions.

From a Financial system stand-point this requires the following

- Recording of opening balances

- Multiple year over year reporting required

- Adjusting of opening balances under IFRS

- Ability to separately identify normal accounting transactions from those for IFRS adjustments

In Microsoft Dynamics AX 2012, the opening transactions can be posted to a unique period (the opening period) of the fiscal year through import of transactions of by transferring prior year ending balances. Prior year ending balances are transferred to the opening period. The opening period is a special period compared with the normal transaction periods. The opening period is usually the first period of a new fiscal year (for example,it covers only the first day).

Microsoft Dynamics AX 2012 alsohas a closing periodwhere the closing transactions can be posted. A closing sheet can be created to create closing transactions. When creating the closing sheet, manual adjustments can be created and posted. Multiple closing sheets can be created for different purposes, and each can be uniquely identified. E.g. you can have a regular closing sheet and then another one to record the IFRS transition adjustments. For example, the screen shot below shows that the GAAP Closing sheet is posted in the current layer while the IFRS Closing sheet with relevant adjustments is posting to the Operations Layer.

Figure: The Closing Sheet in Microsoft Dynamics AX can post to different layers to record adjusting transactions for the IFRS and be able to identify them separately

In addition IAS1 specifies the need for two statements of comprehensive income, two separate income statements, two statements of cash flows, two statements of changes in equity, related notes, including comparative information. All of this is achieved by having the different layers and running reports either via Management Reporter or the Dynamics AX Financial Statements and selecting the appropriate layer or combination of layers as illustrated in the Cash flow example above.

XBRL Support:

The IFRS has adopted the XBRL Taxonomy as its standard for electronic exchange of financial data prepared in accordance with the IFRSs. TheIFRS Foundation XBRL Team is responsible for developing and maintaining the XBRL representation of the IFRSs, known as the IFRS Taxonomy. Both IFRSs and XBRL are intended to standardize financial reporting in order to promote transparency and to improve the quality and comparability of business information, therefore the two form a perfect partnership. As shown in the screen shot below, Microsoft Dynamics AX has native support for XBRL with the ability to natively to import an XBRL taxonomy and use it very quickly. The IFRS in March 2011 published 12 sample XBRL samples including Statements of Financial Position,Comprehensive Income, andChanges in Equity, Statement of Cash Flows, Employee benefits obligations, Consolidated and separate Statements of Financial Position. Microsoft Dynamics AX 2012 can very quickly allow you to take these examples and start reporting in XBRL.

Figure: Microsoft Dynamics AX provides native support for XBRL

In addition Microsoft Dynamics AX 2012 provides support for drag and drop type editors for the presentation of reports, calculations, labels etc. that make XBRL a fairly straight forward process.

Figure: XBRL Taxonomy details for the Presentation of Financial Statements in Microsoft Dynamics AX 2012

Figure: Formulas in XBRL Taxonomy for Calculation for Financial Statements in Microsoft Dynamics AX 2012

The imported XBRL Taxonomy works with the Microsoft Dynamics AX Reports Structure Designer and the Management Reporter Tool that can be used to generated reports. The screen shot below shows the native structure designer with the XBRL Income Statement.

Figure: Microsoft Dynamics AX Report Row Structure Designer showing the XBRL Taxonomy that was imported from the xbrl.org. The first screen shot shows the row definition and the second one show the simulation with the row labels (notice the simulate check box is checked which forces it to simulate the structure of a published report)

Posting layer AX 2012

There are three posting layers for transactions.

• Current is the default layer. This is used for transactions that are part of the periodic financial reporting.
• Operations is used for other transactions that are part of the periodic financial reporting for internal purposes.
• Tax is used for transactions that are not part of the external or internal reporting, but that are for recording special tax transactions, such as tax depreciation for fixed assets.

You can post only one transaction type in a journal. You can select a posting layer in the Posting layer field on the General tab in the Journal names form to create at least one journal name for each posting layer that you use.

In the Value models form, the posting layer is displayed for each value model that is attached to the fixed asset. You cannot change the posting layer.

You can record fixed asset transactions in journals only for value models that use the same posting layer as defined for the journal name. For example, if the journal name is for theTax posting layer, the value models for the Current or Operations posting layers are not displayed for the journal because they cannot be posted in this journal.

‘Advanced rule structures’ feature explained AX 2012

One of the most underutilized features of AX 2012 is the advanced rule structure. Many end-users neglect to track additional financial dimensions for fear of cluttering the account structure with additional dimensions that will only be used for one or a few accounts or not wanting to create excess structures resulting in cumbersome setup for other processes (ledgers, budgets, etc.) just to accommodate the financial reporting desires. However, the advanced rule structure functionality circumvents these problems with simple setup and targeted impact which doesn’t affect the account structures themselves but basically appends to them.

For example, let’s assume that a company wants to track their various Notes Receivables but without having to make their chart of accounts too detailed, adding a financial dimension to the balance sheet structure which would unnecessarily complicate every posting in that range, or creating an entirely structure just for this desire. A “catch-all” Purpose dimension could be created and the various Notes could be created and assigned a unique number.

Under General Ledger→ Setup → Chart of accounts→ Advanced rule structures, create a new rule structure, give it an appropriate name, and assign it the allowed values just as you would if setting up an account structure.

You can even choose to allow blanks, if desired. Then Activate the structure.

In the Configure account structures form (under General Ledger→ Setup → Chart of accounts), select the structure that you want to add the advanced rule to and click the Advanced rule button in the action pane.

Create New and give the Advanced rule a name. You can then set the criteria for the rule. In this case, the rule will only apply when a user attempts to post to the 1130, Notes Receivable, account. Then click Add and attach the rule structure previously created. The Advanced rule tells the system when to apply the structure and the structure defines the allowed values when the rule is applied.

When a journal entry or anything else attempts to post to the Notes Receivable account, the structure is appended, and the allowed values (and only the allowed values) will appear as options in the drop down.

If another account that doesn’t meet the advanced rule’s structure is chosen, then the regular account structure is applied. This allows users to track a large amount of financial dimensions without complicating unrelated postings with unnecessary dimensions or cluttering the chart of accounts.

foreign currency revaluation

The foreign currency revaluation periodic function is used to recalculate currency amounts based on a new exchange rate. At the time of the transaction, the system uses the spot rate setup in the currency exchange rate table. At month end, the currency amounts should be reevaluated based on the month end rate (for BS accounts) or the monthly average rate (for P&L accounts).

Also, if your company is setup with a reporting currency, this function must be used to recalculate correctly the reporting currency amounts. One example is to reevaluate the open balances with the correct exchange rate (see previous post on this blog to understand why the open balances are not properly translated).

Before the function can be executed, the exchange gain/loss accounts must be setup. Ensure those accounts are setup properly before executing the function otherwise the adjustments will be posted to the same account as the original transaction. This will not adjust the balance of your trial balance and also the adjustments will not be updated if the setup is changed after the fact, you would have to do a manual reclass. There are two areas to setup those accounts:

- General Ledger > Setup > Ledger: this setup is company wide and not specific to a currency. Specify the realized gain and loss accounts for transactions that are fully settled and setup the unrealized gain and loss accounts for transactions that are open (invoices not paid for example).

- General Ledger > Setup > Currency > Currency revaluation accounts. First select the currency you want to setup the accounts for, this will override the setup on the ledger form (see above).

The next step is to setup the exchange rate that the function will use to reevaluate. By default, the rate used is the one setup in the table selected on the ledger form. For BS accounts, it will use the last rate setup for the period so nothing should be changed, however for P&L we need to calculate the average of the period.

You will need to calculate your average off system and manually add it to the currency exchange rates type table found under General Ledger > Setup > Currency > Currency exchange rates. 

Create a new exchange rate type to make sure the spot rates are not overridden and manually add the rate for the period and the currency in that new exchange rate type.

The last step is to setup the number sequence that the system will use to post the adjustments entries. This is important for audit purpose since those transactions are system generated.
Go to General Ledger > Setup > General ledger parameters > Number Sequences and select the Foreign currency revaluation number sequence. I used "GL-FCR-" as a prefix so I can easily identify those transactions on the account.

Once the setup is completed you can then execute the revaluation. The function is located under General Ledger > Periodic > Foreign currency revaluation:
   - The function can be executed either for a specific account or for the entire chart of account. You will want to select a single account when you reevaluate bank accounts for example, this will prevent foreign transactions posted to other accounts to be reevaluated.
However, if you want to reevaluate the reporting currency, you can select the entire chart of account (select the first account of your COA in the from main account and the last account of your COA in the To main account field).
   - The from and to dates are used to only reevaluate transactions that have been posted in that period.
   - The currency code will be the currency you want to reevaluate. For bank account it would be the currency of the original transaction posted as opposed to reporting currency would be the reporting currency setup on the company and not the currency of the transaction.
   - Select which account type you want to reevaluate BS or P&L. This is an extra filter if you enter a range of accounts in the from and to main account but only want to reevaluate the P&L accounts for example. If you want to reevaluate the entire COA then you will check both check boxes.

Before you click Ok make sure the correct exchange rate type is selected on the ledger form so the correct exchange rate will be used. Also, keep in mind that if you modify the default exchange rate type on the ledger form, it will impact the rest of your business if they post transactions, so you might need to run this reevaluation outside of business hours to prevent errors.

Once the function has been executed, you can verify the posted transactions in the account being reevaluated and in the account setup for exchange gain/loss. The voucher of those transactions will be based on the setup of your number sequence previously done.