What Happens When You Don’t Activate Your Depreciation Keys

It goes without saying that the depreciation key is the most important configurable item in Asset Accounting (FI-AA) that controls how the subledger calculates depreciation.  There are over 50 different parameters on a depreciation key and it’s associated components such as the multi-level key or cutoff value keys.

Yet one of the parameters that is often mis-understood or not paid full attention to is, surprisingly, the key’s activation status.  The reason for this is that due to the changes made in the 4.6 release of R/3, it is possible for a key to be used yet not be in Active status.  This situation doesn’t make sense to most people and requires further explanation.

This blog will explain the importance of the activation status and provide some other viewpoints too.  I routinely go to customers and see that some of their depreciation keys are not active yet being used in the system.  This will be the central example for this blog.

First, Some History

Prior to the 4.6 release of R/3, the definition of a depreciation key was significantly different than it was today.  The key itself had very little configuration to be maintained that impacted depreciation (or interest) calculation.  That burden was placed on the calculation key which was assigned to each depreciation key.  It was the calculation key that controlled the specifics of depreciation calculation.

The downside to this approach was that the calculation keys were not chart of depreciation dependent.  Once SAP had to account for different legal and country-specific requirements, this global listing of keys often grew to an extremely high number.  Situations like this are difficult to administer over the longterm.

From a technical perspective, the tables that stored this information were T090, T090A, T090C, T090P and several others in this range.

Here is what a calculation key looked like in past R/3 releases.

Changes in R/3 4.6

As of release 4.6 the design around depreciation keys was changed completely.  Calculation keys are no longer part of the FI-AA solution, and more importantly, are no longer accessible.  The functionality has been converted to a series of methods that control much of the same functionality.  These methods are then assigned to each depreciation key to fully define a specific convention.  By breaking up the functionality from a single object (calculation key) to multiple objects (methods), SAP has provided us the opportunity to more flexibly define a specific deprecation convention without defining so many, and often similar, calculation keys.

The main components are the Base Method, Multi-Level Method, Period Control Method, and Declining-Balance Method.  The Cutoff Value Key and Maximum Amount Method are also used but are not required whereas the previous 4 are.

During an upgrade, the ‘old’ tables (T090, T090A, T090P et al) were automatically migrated to their new versions such as T090NA, T090NR, T090NS, etc.  Notice the change in the naming convention of the tables.

The Activation Status

In addition to changing the architecture of the depreciation key, SAP introduced an activation status for each key.  When first viewed after an upgrade the depreciation keys will have a migrated status.  This reflects the fact that the older tables have been successfully migrated to their newer counterparts.  It also indicates that the key does not yet function as shown on the screen…  until the key is active SAP will continue to depreciate the records according to the old calculation key tables.

Here is an example of some keys that are both Active, Inactive, or Migrated.

What’s the Problem?

The problem lies in keys that are inactive or migrated yet are assigned to assets in the subledger.  How does this happen?  Here’s a common scenario that will explain what I routinely see at SAP customers.

• A company goes live with an R/3 release prior to 4.6A on FI-AA.  They have an asset (or most likely, several thousand) assigned to a depreciation key called Z123.
• The company upgrades to a new release of R/3 (or ERP).  The depreciation key has a migrated status at this point and is never activated.
• Over time the key is adjusted via OSS notes or other methods and is still not activated.
• The company continues to depreciate the asset for successive periods/years, all along assuming that what they see in the IMG is the actual definition of the key (which is still inactive).

The problem with this scenario is that both sets of tables are still present in the system after the upgrade.  They also contain many similar values for this particular scenario although keys created after the upgrade will obviously not be present in the older tables.  But if the key is not active, the depreciation will be calculated as defined in the old tables.  As I alluded to earlier, these older tables are no longer maintainable by normal methods because the configuration screens and transaction codes no longer exist.

This situation yields a system that is not transparent and more difficult to support.  It also makes the investigation of depreciation calculations much more difficult.

What To Do Next

If you find a key that is not active but being used you need to either 1) consider changing the key on all affected asset records to a different key that is active, or 2) activate the key.

If the key shouldn’t be used, consider reassigning the asset to a new depreciation key.  If the key assignment is correct, then it is important that you activate the key.

The only thing to consider is that any change in depreciation configuration should be followed up by recalculating values.  This could trigger a significant change in the planned amounts that would have to be posted to the G/L.

Last Point

Are there any times when it makes sense for a key to not be active?  The only benefit is that it won’t appear in any drop-down list for the depreciation key field (AFASL).  If your goal is to provide a concise list of keys so that users will not choose an inappropriate one (such as the many ACRS keys that are still delivered in SAP), then deactivating them might be appropriate.  But if you are considering that approach, go a step further and consider deleting the key entirely. The delivered keys can always be referenced from the standard CoD so there’s little risk in deleting a system delivered key.