Archive

Author Archive

Experience from a Microsoft Dynamics AX Fixed Assets Implementation

October 9th, 2013 Yogesh Kasat No comments

Last summer I was involved in a complex Fixed Asset implementation project and wanted to share some learning from the project, which would be helpful for companies migrating from FAS to Microsoft Dynamics AX.

Background:

We were implementing Microsoft Dynamics AX Fixed Assets for a company that had around 50 legal entities, all of them in the US. They were using FAS for tracking Fixed Assets.

The way that the companies were created in FAS was totally out of sync from their legal entity structure. Over a period of time they had created companies per function – e.g., there was a company created for land and building kind of assets, and another company for drivers/aircrafts. Obviously their GL system and FAS were out of sync due to these being maintained in different systems and a different company structure.

After converting assets into Microsoft Dynamics AX, the key benefit they had was the GL and Fixed Assets were always in sync – it was one integrated system for GL and Fixed Assets. Fixed Assets was also integrated with their AP, Purchasing, and Inventory modules.

Here are things to watch out for during a typical Microsoft Dynamics AX Fixed Assets implementation:

  1. Data conversion
  2. Transfers across legal entities
  3. Re-class of assets within different groups (e.g. Moving an asset from Development; i.e. WIP to Furniture group)
  4. Mass updates for assets
  5. Difference between Depreciation books vs. Value models
  6. Tax updates
  7. Reporting

Here is how we approached this implementation and turned it into a success story:

  1. Data conversion: This is key for the success of an implementation. You need to start right and make sure you are set up for success.
    1. Try to go live around year-end or quarter-end with a new Fixed Asset system. It will simplify conversion.
    2. Bring over only remaining life values and book value as part of conversion. We converted assets with their acquisition cost and posted one entry for all the depreciation till date. That helped us build book value on the asset.
    3. Do you need to migrate inactive assets? These assets may add a lot of noise for migration with acquisitions, dates for disposals, etc. The best way could be to save some reports for the last few years if you need them for audit purposes. 
    4. You need to consider values for different books – e.g. Federal Tax books may have different values than State Tax books, and values for GL/GAAP purposes may be different.
    5. Understand volume and create import programs accordingly. We had close to 100,000 assets to be migrated; if we had used Excel add-in migration, it would have run for weeks.
  2. Transfers across legal entities:
    1. If you are transferring assets across legal entities often enough, you need to think about building functionality to support that. Standard Microsoft Dynamics AX doesn’t have functionality for transferring assets across legal entities. Microsoft Dynamics AX 2012 supports transferring across different dimensions – e.g., divisions or cost centers.
    2. We made customization which allowed transfer from one company to another. It created a new asset in a company where the asset was being transferred, transferred balances across different value models, depreciation books from one company to another through journals, added fields to keep track of new and existing asset numbers (transferred to and transferred from etc.) for ease of research.
  3. Re-class of assets within different groups (e.g. Moving an asset from Development; i.e. WIP to Furniture group)
    1. Oftentimes assets get created in wrong groups or need to be moved from one group to another – e.g., while a store is being built it needs to be considered 'In Development', that way you are not depreciating it until the store opens; and you may want it to be on different GL account, etc.
    2. Standard Microsoft Dynamics AX has functionality to re-class but it does not bring over information in Depreciation books. We had to make some customization to address it.
  4. Mass updates for assets (e.g. Mass updates of remaining life due to store closing in few months, mass updates to bonus depreciation due to changes in IRS rules)
    1. It's important to understand mass updates to be done on assets upfront. So some of the mass update templates can be defined and developed as part of implementation.
    2. e.g. If you are closing a store in 6 months, you may need to update the remaining life of all the assets you are not planning on moving to another store to 6 months. That way you can depreciate the remaining values evenly in the next 6 months rather than taking a big hit in the last month.
    3. Another example could be, you are into the 5th month of the year and bonus depreciation for the year changes from 100% to 50%. You need a way to mass update bonus depreciation of all the assets acquired during that year.
    4. Updating serial numbers, warranty information could be another classic example of needing mass update functionality.
  5. Reporting: A lot of reporting on fixed assets is needed around year-end and that's when people realize they need reports ;-) . It's always a good idea to identify those requirements and have reports built accordingly upfront as part of implementation. Even though data is there, that may not be enough. Standard Microsoft Dynamics AX may not have the reports you need, but you can use standard reports as a starting point to build what you need.
  6. Difference between Depreciation books vs. Value models:
    1. Depreciation books were introduced in Microsoft Dynamics AX version 4.0. We changed the label to call them ‘Tax books’ to make it easy for users.
    2. You can use Depreciation books functionality for tax books, or use Value models for tax books. Using Value model was way prior to Microsoft Dynamics AX 4.0.
    3. By using Depreciation books functionality, you get bonus depreciation functionality. Also, it is disconnected from GL, so you can use safely delete these transactions in case you have to.
  7. Tax updates: FAS provides tax updates, however in Microsoft Dynamics AX world you need to configure changes yourself. For a lot of businesses this is not a big deal, but if you have a presence across multiple states and are maintaining state/federal/tax/Amt profiles in the system, it could add up work pretty quickly.

If you have questions or would like more information on Microsoft Dynamics AX implementations, please email us at dynamics@ignify.com

Yogesh Kasat is Vice President of Microsoft Dynamics AX at Ignify. Ignify is a technology provider of ERPCRMeCommerce and Point of Sale software solutions to organizations. Ignify has won the worldwide Microsoft Partner of the Year Award in 2013, 2012 and 2011. Ignify has been included as the fastest growing business in North America for 7 years in a row by Deloitte, Inc Magazine and Entrepreneur Magazine from 2007 to 2013.

Categories: Uncategorized Tags:

Customer check payments in Dynamics AX as a two step process of apply payments and deposit checks

November 21st, 2009 Yogesh Kasat 1 comment

For businesses like Ignify that still receive checks from customer (and we are glad that we do), it is important to differentiate the two elements of receiving a customer payment.

1. Applying the payment to an invoice.

2. Depositing the check.
From an accounting perspective this distinction is important as one reduced the customer balance while keeping the check in the undeposited funds GL account while the second step moves the undeposited check into the deposited state.  These could be two different dates and potentially different periods.  I noticed that several consultants implement customer payments as a single step only mechansmis.

Explaining this further – the GL entry looks like this When check is received
Cr – Customer Receivable
Dr – Undeposited funds

When check is realized after deposit (which could be a few days later and another period)
Cr – Undeposited funds
Dr – Bank Account

Dynamics AX has a nice way of handling this through bridging accounts – however it is not the most intuitive and your consultant needs to know this well hidden feature. .
I've outlined the steps to do this.

 

1. Set up of Bridging accounts

Go to AR > Set up > Payment > Method of Payment

1

 

Create a Method of Payment “Check”.

2

 

Go to General Tab > Posting and select Account type as “Bank” and select the Payment account.

Check “Bridging account” and select Bridging account as “Un deposited Funds” (1130)

3

 


2. Posting AR Payments (When the Check is received but not realized in the Bank)

Go to AR > Journal > Payment Journal

4

 

Create AR Payment Journal Header and Click Lines

5

 

On the Journal line, Select Customer, Invoice Number and the Invoice amount will be populated.

Select Method of Payment as “Check “and enter the Check number in the “Payment reference” field.

The Bridging account “Un deposited Funds” (1130) will be automatically populated upon selection of Method of Payment as “Check “.

6

 

Validate & Post the Journal.

3. Posting of Bridging transactions of AR Payments  (When the Check is realized in the Bank)

Go to GL > Journal > General Journal

7

 

Create a new General Journal line and Click Lines

8

 

On the Journal lines Click Functions > Select Bridged transactions

9

 

Following form will open.

Select the relevant Transaction (the Check amount has been realized) and accept it.

10

 

The Date will be the Date of creating the General Journal.

Credit will automatically be the Bridging account “Un deposited Funds” (1130) and Debit will be the Bank.

11

 

Validate & Post the General journal.

Note:

We can use the past dates in AR Payment Journal as well as in GJ Journal.

If the AR Payment Journal is posted on 9/1/2009, when we accept the Bridging transactions in General Journal, the automatically created journal line with bridging transactions will have the AR Payment journal posted date i.e. 9/1/2009.However we can change this to past date i.e. 9/3/2009 before posting it.

Please refer screenshot below which is created & Posted on 10/13/2009 (AR Payment date 9/1/2009, GJ posting date 9/3/2009):

AR Payment journal line:

12


General Journal line:

 13

Now you have achieved the the two step process of applying a payment to a check and then depositing the check to a separate step. Of course more and more businesses are moving to a single step electronic payment process such as lockbox (where the bank codes the deposits for you) or wire transfers and ACH as has Ignify also.

This post is jointly written by Yogesh Kasat and Partha Chattopadhyay. Yogesh is a Senior Manager and Partha is a Senior Business Analyst in the Microsoft Dynamics AX Practice at Ignify . Ignify is a Global Microsoft Dynamics Inner Circle Partner specializing in Dynamics AX for Retail, Distribution, Manufacturing and Chemicals verticals. For help on Microsoft Dynamics ERP email us at dynamics@ignify.com

Categories: Uncategorized Tags: