Skip to Content

New Ways to Depreciate Fixed Assets in ERP 6.0 (Part 4)

My previous blogs (New Ways to Depreciate Fixed Assets in ERP 6.0 (Part 1), New Ways to Depreciate Fixed Assets in ERP 6.0 (Part 2), New Ways to Depreciate Fixed Assets in ERP 6.0 (Part 3)) introduced the key capabilities of the new depreciation calculation program (New DCP) delivered in ERP 6.0.  This blog will focus on a hidden transaction that is extremely useful when validating the amounts that SAP calculates.


The Upgrade Scenario

As part of an ERP 6.0 upgrade, users who are responsible for Asset Accounting (FI-AA) are going to want to verify that the calculation between the old and new depreciation calculations are in fact the same (or different, depending on the scenario that you are validating).  This is an important step because end users and managers need to have confidence that the subledger is calculating amounts correctly.  The best way to do this is to use the Asset Explorer and “proof” example assets to show that they are depreciating per the system’s configuration.  In the context of an upgrade and the switch to the New DCP, those who work in FI-AA will have the added burden to prove that the calculated amounts have not changed as a result of the switch to the New DCP.

As mentioned in an earlier blog, the system will use either the old or new calculations depending on the status of the EA-FIN extension.  Since the extension can only be active or inactive it is not possible to deactivate the calculation for a single entity (company code, asset, etc.)…  it is either active across the entire SAP Client, or it isn’t.

So how can you compare asset values in an upgraded system with those that existed prior to the upgrade?  How do you prove that a particular asset is depreciating with the New DCP in the same way that it was prior to the upgrade?

I suppose you could investigate records between systems where one has been upgraded and another has not, but that solution is ripe for error.  There is a much more efficient and accurate way to perform this validation.


The Solution

The solution to this scenario is to use transaction code AW01_AFAR.  SAP has delivered this as a hidden transaction code…  “hidden” in the sense that it won’t appear on any menu path or in the IMG yet is fully supported and accessible.  It is a duplicate of the standard Asset Explorer transaction AW01 except that it will always use the old depreciation calculation regardless of the status of the EA-FIN extension. 

Here’s how it works…

As shown in the previous New Ways to Depreciate Fixed Assets in ERP 6.0 (Part 3), the asset below exists in an ERP 6.0 system where the EA-FIN extension is active.  This first image is taken from the standard Asset Explorer transaction AW01.  For those of you who are relatively new to Asset Accounting, the Asset Explorer is a comprehensive transaction that displays the asset values and key master data attributes, provide links to other reports, and key capabilities such as currency translation and simulation functions.  This makes it the single best transaction code in the entire system (naysayers can post below if they are up to it).  Note the title of the screen “Asset Explorer” and the planned depreciation amount of $17,250.


AW01 Asset Explorer New DCP


The second image below is of the same asset but viewed using transaction AW01_AFAR.  Notice the screen’s title and the differeint amount of $9,750. 


AW01_AFAR Asset Explorer Old DCP


Same asset, same system, but with different values because they are each using different depreciation calculation programs.  By utilizing both transactions in an upgraded system you can now compare the values and bring visibility to a calculation problem or gain confidence that your calculations are consistent.

For this particular asset we can now see that there is in fact a difference in the calculated amounts and that it can be attributed to the New DCP.  The reason for this difference is that the old calculation (AW01_AFAR) does not support time dependent depreciation parameters which were reviewed in part 3 of the blog series.  As a result of that limitation it must evaluate the most current entry and use it to calculate the asset’s values for its entire lifetime (which is how the old calculation works).  In this case the difference is justified.



Since this is the last post in the blog series, please post any feedback below regarding your experiences with the New DCP, questions, concerns, upgrade issues, etc.

You must be Logged on to comment or reply to a post.
  • Nathan,

    The four parts were very detailed and informative.  Thanks providing this information.  Sometimes it is difficult to explain these changes and your detailed explanation including screen shots is extremelhy helpful.


  • We are currently in the middle of a worldwide rollout of ECC6.0. The beta site did not have the EA-Fin implementated. Is there any problem with turning this on retroactively?

    Your assistance is appreciated.

  • Hello Nathan

    I have gone trough the complete series on new depreciation calculation issues. I very much appreciate your effort to make this topic more clear and understandable. This is very much helpful for new upgrade customers and for those who face the new depreciation calculation for the first time.

    Thanks a lot.

  • Hello Nathan!

    Thank you for your interesting documentation.
    I have to upgrade system from ECC 5.00 to ECC 6.00. I’d prefer to maintain old depreciation method during a first period after the upgrade and to activate new calculation in a second moment. Is it possible ? Please, do you find any type of problem ?

    Thank you very much.
    Kind regards.
    Elena Passadori

    • Yes, it is possible.  The EA-FIN add-on can be activated at a later point in time.  Many customers that I have worked with (in the US) are taking this approach. 

      Keep in mind that the add-on can not be de-activated so be sure to test it thoroughly including the others items contained in the add-on.


      • Hello Nathan!
        Please, could you help us to deactivate EA-FIN extension ? We have just upgraded our development system to ECC 6.0: as described in your blog, this extension has been activated by default. We are reading this IMG documentation:

        “Note that the changes you make in this IMG activity are critical.
        Once you have activated a Business Function, you can no longer  
        cancel the enhancements it makes in the system.”

        Is it impossible to deactivate EA-FIN extension ?

        Thank you for your help.


  • Nathan – This information is very helpful.  I commend you on your research.  I would like to share my experiences with the new DCP, and solicit feedback from others.

    My company is currently converting from 4.7 to ECC 6.0.  We are activating EA-FIN, and implementing the new DCP accordingly.  In testing, we are finding a lot of assets now having depreciation calculation errors post-conversion.  In our case, the problem appears to be with credits being applied in the year of conversion.  If the credits applied in the current year (whether through credit memo or through project settlement) exceed the NBV at the beginning of the year, the new DCP yields a negative NBV.  The old DCP yielded a NBV of zero.  I believe the difference is the calculation of depreciation tied to the credit being applied.  The new DCP plans more depreciation than the old leading to the negative NBV.

    Based on my knowledge of RAAFAR00, I am expecting that only transactions posted in the current year will be analyzed.  So, credits posted in past years will not be yield errors.  In our case, we are activating the new DCP near the beginning of the fiscal year, which should minimize the impact of the new DCP.  Has anyone else found this implementation timeline to be beneficial?

    Also, most of the assets that are not in error are still yielding changes in the planned depreciation for the current year.  In most cases, the change is one or two pennies due to rounding.  In other cases, the amount is more significant.

    For other companies that have converted, I am wondering how clients have reacted to changes in the planned depreciation after conversion.  Have others found the changes to be material? 

    • Scott,

      RAAFAR00 will analyze the asset’s total value but only for any open year, not the current year.

      Note 965032 covers some of the differences between the old and new DCP and mentions that slight rounding differences are expected.  That’s why SAP recommends to run RAAFAR00 immediately after the technical upgrade.  These penny differences are mostly expected on asset’s with large amounts, particularly in currencies without decimals…  but it wouldn’t shock me if they showed up on much smaller USD assets either. 

      When I’ve worked with this I’ve seen results ranging from no changes on over 100k asset records to a $10-20 on only 30k records (in aggregate).  I haven’t see any material changes as a result of using the New DCP.


      • Nathan – Thanks for the quick response and clarification.  After we convert to ECC 6.0 and run RAAFAR00, I’ll let you know how things turned out.
        • Scott,

          We have also been testing the new depreciation program. Our testing reveals that if the new program is activated in a new financial year before the first depreciation run, the depreciation adjustements are generally rounding differences. However, if the new DCP is activated during the year, unusual large depreciation adjustments occur including depreciation adjustemnts to the non depreciable assets e.g. land and Assets under construction. In our case some config changes appear to address the issues. These changes included allowing only positive or zero NBVs and allowing negative values for AuC asset classses. Some other assets had depreciation calculation errors. In these cases, we had to reverse asset revaluation transactions and repost them after the activation. I would be interested in your experience as we are still in the testing phase.

          Kishor Nangrani

  • Hi Nathan,

    I have reviewed the 4 parts, and find the blog very simple to read and follow. Thanks for the info.

    One scenario (or issue?) I am seeing with the new DCP and the Interval posting is this:

    • When we have an asset with multiple depreciation areas, and make an interval update to areas 01/06/08/09, but do not add an interval for our tax books, 10/12/13/14, the new interval causes a recalculation in the tax books.
    • Area 01 is book, and 06/08/09 are tied to ledgers. The tax books are statistical in nature and do not post.
    • We have a book 70 which is derived by 01 minus 10.

    Have you seen this before? Should we expect the new interval(s) in Area 01 to impact the other areas in such a way?

    Would there be something in the Depreciation key set up to cause this?

    thanks again and hope to hear from you soon.


    • Hey Jerry,

      So, this is one of those situations where we have to interpret if this is a bug or a feature before you get an answer from SAP.  My guess is that… it could go either way.

      On the one hand, I would want each area to recalculate individually.  This is the case if, for example, you change a key on area XX, then only that area is recalculated when you save.  But I’m pretty sure that if the area is part of a derived area, than the other related area gets recalculated as well.  And if that area is posting to a ledger than for consistency reasons they might recalculate the other areas mapped to the same ledger. 

      My guess is that area 10 is recalculating because it’s in the derived area.  I’d remove it from the derived area definition or delete the derived area (you should be able to change it back without any issues) and try making the interval change again to see if 10 isn’t updated.

      As for the other areas… I’m not sure why they would be recalculating.  Either way, I’d raise it to OSS and get their opinion.


      • Hi Nathan,

        I wanted to follow up with our results. As usual, your assumption was correct, we removed the derived area, and that resolved the issue.  We will add it back later in 2015 once we have our Tax adjustments completed. I did not raise to OSS, since removing the area solved the issue.

        I also had another similar question for Bonus/Special deprecation.

        What have you seen folks do when they want to capture Bonus depreciation on subsequent acquistions, when they cross fiscal years?  Do you create a sub-number asset and post in the acquistion value that way? We are preparing a solution to do just that, and I was curious what you have seen or if there are other potential solutions.

        Thanks again and in advance for your reply,


        • Subasset would be easiest to implement and track going forward but it starts to fracture the master data.  What do you do with purchases for future years when there might not be bonus depreciation?  It just doesn’t look all that pretty.

          Another way is to implement a bonus key using the time-dependent functionality on the asset master but a regular key in years when it’s not applicable.  That way, the costs are all on one record.         

          • Hi Nathan,

            I like the idea of keeping the costs all on one record.  I suppose you are talking about adding a new Interval for the Depreciation area, for tax depreciation, and assigning a Bonus key that will calculate for just the assigned year. Then after that year is over, let it sit as is, unless rates change.

            So does the multi-level method need to have explicit years and rates, or can the year be generic with explicit rates, for multiple generic years? Also, what would you use for the base value for the multi-level method – 40 – Acquisitions?

            thanks again,


          • Well, now that we have time-dependent period controls having a year in the ML Method is no longer required in some cases.  This might be one of them.    

          • Yes, I can see that now.  I was able to set up a new key that calculates bonus/special in each year.  I just used the 9999/999 for acquisition year and validity years in the set up in the multi level method. So if the rule changes, we can change the key to suit the need.

            Thanks again,