UPA & Asset Accounting in S/4HANA (Part 2): Fixed Asset Overview

Blog Series:
UPA & Asset Accounting in S/4HANA (Part 1): Introduction

In the last blog I gave a not-so-brief introduction about UPA.  In this blog I’ll introduce SAP’s new solution for fixed assets.  This new solution is a complete replacement to the current S/4HANA Fixed Asset Accounting solution, formerly known as New Asset Accounting.  SAP refers to the new-new solution as just UPA & Asset Accounting but you’ll sometimes see the phrase Intelligent Asset Accounting (IAA) online as well.  The official online documentation doesn’t mention ‘IAA’ and uses the familiar phrase Asset Accounting.  I suppose it’s better to juse keep the original phrase of Asset Accounting than for us to keep up with another acronym… but I have had conversations with customers where I’ve had to refer to this as the 3.0 solution to fixed assets. 

In this blog I’ll give an overview of what has changed but a lot of the specifics that the new solution delivers will come in subsequent blogs.  Why?  There really is a lot to cover and I want to do more than just provide a bulleted list of new features in one blog.

For this introduction I’ll cover the history and evolution of the asset solution, SAP’s goals, and touch on a configuration topic to give you an example of the degree of change that SAP is undertaking.  But I’ll first lead off with SAP’s…

 

Design Principle

SAP is constantly touting their goal to bring innovation to the customer base.  To do this, they have to make changes… big giant changes… to S/4HANA in order to accomplish this goal.  The Universal Journal was released back in S/4HANA 1610 (nearly 8 years ago) and yet I’m not sure this gets enough credit for 1) just how big of an undertaking it was and 2) how good of a job SAP did in making the transition so smooth.  They made the change and we’ve seen a host of benefits ripple throughout the finance solution because of it.  It’s important to understand both 1) what SAP is trying to accomplish, 2) their over-arching principles that they use to get there in order, and 3) understand both how the new solutions work as well as why certain decisions might have been made.

The first principle for the new fixed asset solution is that it is connected to the UPA solution mentioned in the previous blog.  Activating UPA will activate all of the new features in fixed assets as well.  There is no possibility where a customer could run UPA without the new asset solution or vice versa.  They are joined at the hip and can’t be separated. 

 

The second is around the basic idea that the process for SAP to deliver innovation… real, maximum innovation… inherently requires disruption.  Without the freedom to re-architect its solutions (sometimes in a dramatic fashion) SAP would only be able to provide incremental improvements.  With the old way that SAP would deliver release updates, we’d get a few small improvements but processing and reporting wouldn’t materially improve.

This makes me think about the famous quote from the American owner/founder of Ford Motor Company.  This quote used to focus on user groups and how they play a role in your product development.  But I now read it as more from a disruption vs. innovation angle.  If you want to make a big jump forward, you have to be willing to make an equally big change away from from what you’re doing currently.

 

With this in mind, we can now discuss the…

 

Mission Statement

SAP has several objectives and goals for the new UPA & Asset Accounting solution.  Some of them are motivated by the usual desire to improve areas that haven’t been touched in awhile, while others are required based on the changes in Finance because of UPA.

The first item to discuss is configuration.

Since UPA positions the Ledger as the lead valuation object, Asset Accounting now has to do something similar.  SAP has had to re-code numerous items in fixed assets so that the Ledger is the main object used for valuation.  After all, as the solution changes so too does the configuration.

In addition to those inherent changes in configuration as required by UPA, there are others that were optimized.  You may not have noticed but there are several redundancies within FI-AA configuration particularly in the areas that have to do with FI or CO integration.  These have now been rectified.  I’ll have an example of this later.  

Next is master data.  You may not know this but the last meaningful change we had on the master record was tab layouts in R/3 release 4.0b.  That was definitely nice to see and brought FI-AA in-line with the other prominent FICO master data records that had it, but that wasn’t a change in functionality.  Minimal benefit was had from this feature.  In my entire consulting carear (which goes back to 1996 on my first SAP implementation), the only new changes to the asset were the Super Number, tab layouts, and maybe a handful of user exits such as AIST0002.  Basically, SAP hasn’t touched the asset master in decades.

Now with UPA, SAP has released an entirely new asset master record.  100% new.  New master data tables, new design, new frontend UI, and new configuration.  Below is a quick screenshot and a highlight of some features.  I’ll cover more of this in a subsequent blog.

 

Another key objective was to improve reporting.  Similar to the history of master data, SAP has delivered only a few changes.  They’ve re-coded a few reports such as the depreciation simulation report (RASIMU01 was replaced by RASIMU02), they made them ALV compliant, and there are quite a few localization reports for India, Japan, Russia and probably some other countries that I’m not familiar with.  With those few exceptions there hasn’t been a meaningful change in the reporting solution, it’s technical architecture, or the types of reports that SAP has delivered. With UPA & Asset Accounting, SAP has set an objective to revamp all of the delivered asset reports.

The last major (to me) objective was to come up with a new approach for Unit of Production (UOP) depreciation.  The old solution required a separate depreciation key per depletable unit which at some Oil&Gas companies was the individual well level.  This could require thousands of depreciation keys which unnecessarily pollutes the depreciation key listing.  I’ll cover the details of this change in a subsequent blog.

 

Here are some additional items worth noting that will get blogged about later:

  • Improved CO settlement.  It’ll be possible to settle project costs by ledger without resorting to the capitalization key approach talked about in the first blog.
  • Support for SAP’s new unified planning solutions (ACDOCP)
  • Refreshed Fiori interface
  • Support for shifted / alternative fiscal year variants within fixed assets per ledger
  • De-coupling of company status tables from the asset financial value tables
  • And lastly…

Simplified Configuration

The configuration to support FI-AA hasn’t changed much over the years.  From R/3, to ECC, to New Asset Accounting, to S/4HANA OP, the configuration model has been largely the same.  There has definitely been small additions of isolated configuration for new features but the fundamental building blocks haven’t changed.  As an example, the most prominent objects used for valuation in the past were:

  • Company Code
  • Chart of Depreciation
  • Depreciation Area

This has changed with UPA & Asset Accounting.  A lot.  Now, most of the valuation relevant configuration is done at the Accounting Principle or Ledger level.  Let’s take a look at how SAP does this.

With UPA & Asset Accounting, SAP has introduced an item called the Valuation View.  This is a new configuration object and exists only in FI-AA.  The primary purpose of the valuation view is to account for the valuation requirements as specified by a country, other local tax organization, or an accounting regulatory group.  Examples would be US GAAP, IFRS, German GAAP, various US tax requirements such as MACRS or AMT, and possibly FERC, etc.  This valuation view is later assigned to an accounting principle so that a total valuation solution can be provided per accounting principle.

 

Within each valuation view we can see the traditional set of value types and the allowed sign treatment for each one.  This is similar to how we defined a depreciation area prior to UPA but it’s not configured there anymore.

 

In the below screenshot, you can see how the accounting principle USAP for US GAAP is composed of the different valuation views. 

 

Another benefit of this new design is that once a specification is made in a particular area on the Ledger or Accounting Principle level up in FI, those settings are automatically relevant within fixed assets (after the the necessary mapping is done down to the asset subledger). Here’s how that works in the area of currencies.

Prior to UPA, we had to go through the below process to properly configure parallel currencies just in FI-AA (the GL had its own steps).  These steps will create a new area 02 using group currency EUR based on the values in area 01.

  1. Create new depreciation area 02.
  2. Maintain the APC value takeover rules to copy from area 01 with identical values.
  3. Maintain the depreciation value takeover rules to copy from area 01 with identical values.
  4. Specify the currency EUR on area 02.
  5. Specify the currency type 30-group currency on area 02.
  6. Add the area to all of the asset classes.

In UPA & Asset Accounting the process has totally changed.  Now the currency is configured at the ledger level at [FINSC_LEDGER] (and usually assigned to the accounting principle at the same time).  Once the accounting principle is assigned to the valuation view (let’s assume that has already been done), then that principle is immediately burdened with all of the currencies as configured at [FINSC_LEDGER] and passed down to the valuation view.  That’s all it takes!  We just have to make a single mapping and get the benefits of all of the currency configuration that has already been done in FI so there is no need to duplicate it again in the subledger.  There is also no need for SAP to code checks between the GL and FI-AA to ensure that both have the same consistent currency settings.

Here’s another example regarding the GL account determination.  In the past, most of the GL Account Determination was maintained at [AO90] but there were a few exceptions where configuration was handled elsewhere.  Also, the [AO90] screen itself required a lot of navigation.  You had to double-click on different account determinations, areas, then the correct folder (I refer to them as account categories) to then specify the GL account.  If you were changing something like a single account (ex. fixed asset clearing) and you had multiple posting areas and 20+ account determinations… well, it could take someone 30 minutes to make that change.  SAP even came out with a simpler way to handle this because [AO90] could be so tedious (A New Way to Maintain GL Account Determination).  All of this was required because of the view cluster used to maintain the account determination.  Now in UPA & Asset Accounting,they’ve taken a fresh approach and everything is basically in a single large table that is COA dependent. 

This is easier and simpler to work with now in UPA.

 

Solution Evolution

Now that I’ve covered the basics, let’s go back for a quick review of the history of SAP’s Asset Accounting solution.

  • Classic Asset Accounting
    • This was the original FI-AA solution within the traditional FI module.  Many parts of it date back to R/2 though most of us were exposed to it in R/3 or ECC.
  • New Asset Accounting
    • This was released in ECC but pretty late in its lifecycle.  We’ve covered this solution extensively in a multi-part blog series (S/4HANA New Asset Accounting (Part 1): Introduction).
    • The fundamental change in functionality was a redesign of the asset posting kernel to support the NewGL.  This was required to be more compliant with IFRS and other parallel accounting requirements.  This was a growing time for SAP Finance when they released the NewGL and introduced the Ledger directly in the accounting code block. 
    • Similar to EA-FIN and the NewDCP, every customer could choose whether or not they wanted to remain on their existing Classic Asset Accounting solution and the work-arounds required to interact with the NewGL, or activate the FIN_AA_PARALLEL_VAL switch and move to New Asset Accounting.  This was also the case between the Classic GL and NewGL solutions.
    • When SAP first began the transition away from ECC and released S/4HANA OP 1506, New Asset Accounting was the only option available.  In ECC you could choose what option you wanted to run but as of S/4HANA, only the New solution was available (same for the NewGL and NewDCP too).
    • SAP finally dropped the usage of “new” from most of their solutions in S/4HANA 1709 since the old/classic solutions weren’t available in S/4HANA.  You can read more about this here:  Dropping the “New” Designation in S/4HANA Finance
  • UPA & Asset Accounting (IAA)
    • Similar to the rollout of New Asset Accounting, every S/4HANA OP customer can choose what solution they want to run.  They can stay with the ‘base’ Asset Accounting solution (formerly ‘new’) or move up to UPA & Asset Accounting.  This is a far bigger jump considering the amount of functional changes in both FI-AA and general finance that UPA requires.  So the decision warrants more time and thought for those customers that want to migrate.  However, the argument to use it as their starting point in SAP for new customers is, to me, a far easier decision.  It would be riskier to implement the ‘legacy’ solutions in my opinion.

 

One More Comment

Once we get to the end of the blog series and cover all of the changes, you’ll see just how massive of a change that UPA & Asset Accounting presents to the SAP customer base.  But it’s important to note that it’s not entirely all new.  Some of the elements in it have been in S/4HANA Cloud for several years now.  One example is the new fixed asset master which was rolled out in S/4HANA Cloud 1911 (that’s 2019).  The point being that there is plenty of reason to have some confidence switching to a new solution in the OP (Private Cloud) version that has had some time maturing from other customer implementations in the Public Cloud.

For the next blog I’ll dive into the new master data solution.