We’ve covered quite a lot of history regarding SAP’s New Asset Accounting solution. Now is the time to cover the technical items and answer some key questions.
Blog Series: S/4HANA New Asset Accounting (Part 1): Introduction S/4HANA New Asset Accounting (Part 2): History of Parallel Valuation S/4HANA New Asset Accounting (Part 3): SAP’s Asset Parallel Valuation Solution FIN_AA_PARALLEL_VAL S/4HANA New Asset Accounting (Part 4): Functional Improvements S/4HANA New Asset Accounting (Part 5): Technical Changes S/4HANA New Asset Accounting (Part 6): Should you Migrate in ECC?
ECC or S/4HANA?
As was discussed earlier, New Asset Accounting can be implemented in ECC but it’s certainly not required to do so. Every customer can choose if they want to remain on Classic FI-AA or migrate to the New Asset Accounting solution. If you want to move forward with New Asset Accounting then you must activate the business function FIN_AA_PARALLEL_VAL and address all of its prerequisites (noted below). Note, that New Asset Accounting can be activated at the client level in this scenario because the activation of the business function is client specific.
As of S/4HANA, only New Asset Accounting is available. Once you’ve crossed over to S/4HANA, Classic FI-AA is no longer an option and no longer exists. This is true for the entire system and is not client specific.
On ECC, in order to activate New Asset Accounting, the following prerequisites have to be dealt with.
- You must be on ECC 6.0, EhP7 SP02. The support level is quite important. You should not activate the FIN_AA_PARALLEL_VAL function in ECC until you’ve applied SP02. If you activate it while you are on SP00 or SP01, you’ll get a series of errors because the functionality was not fully delivered until SP02.
- The NewDCP must be active. SAP delivered the NewDCP in the EA-FIN add-on which can be checked at [SFW5]. We have a 4 part blog series on the NewDCP, its benefits, reasons to upgrade to it, and more. It was released in ~2006 so it’s not really new anymore… it’s a completely stable solution and the de-facto one going forward. SAP has it as a prerequisite for most of their asset related solutions so if you’re not on it now, you need to come up with a plan for it soon.
- The NewGL using the Ledger Approach must be active. New Asset Accounting is not compatible with the older Classic GL at all. If you are on the NewGL, the Account Approach is not supported either but this only applies to ECC. Once you implement/migrate to S/4HANA, either approach will work with the SAP General Ledger and New Asset Accounting. But in ECC the Ledger Approach on the NewGL is the one-and-only option.
There is also a list of other items that New Asset Accounting does not support. I’m referring mostly to integration issues that the other modules have with the New Asset Accounting solution that prevents them from being used if New Asset Accounting is active. If you are using any of the items listed below, you’ll have to account for it prior to migrating to New Asset Accounting. If these aren’t in scope for your usage of SAP, then you can ignore them and just activate New Asset Accounting.
- Lease Accounting Engine (LAE)
- Joint Venture Accounting (JVA) in IS-Oil.
- Real Estate Classic
- Public Sector Management – Funds Management (PSM-FM)
- ALE for Asset Transfers
- GL Classic or NewGL using the Account Approach
Business Functions and Enterprise Add-Ons
Since the focus of this blog is a technical one, let’s dive into the related business functions that are related to New Asset Accounting for both ECC and S/4HANA.
As mentioned earlier, the EA-FIN add-on was used in ECC to deliver the New Depreciation Engine (NewDCP). It is a prerequisite for New Asset Accounting in ECC but in S/4HANA the add-on is no longer required. Why? Because the NewDCP has now become the one-and-only calculation engine delivered for fixed assets. It is delivered separately from the add-on. There is no Old vs. New in S/4HANA, only the NewDCP is delivered. Consequently, EA-FIN is no longer required to be activated and it’s activation status is irrelevant.
This function delivers the parallel valuation posting kernel in FI-AA in ECC. As covered earlier, to get on New Asset Accounting in ECC you have to activate this function. But, similar to EA-FIN above, it is now the one-and-only posting process delivered in S/4HANA so the activation status of the function is now irrelevant.
This function delivered a few improvements to support parallel valuation and with the usage of ledgers in the GL. In this function SAP made a change to the depreciation posting program (and log) so that it could be executed by ledger group. Without FIN_AA_CI_1 the programs could only be run by company code(s). Secondly, it enhanced how we can assign alternative fiscal year variants (FYV) within the subledger. There were some related smaller changes that impacted the Asset Explorer (AW01N) and how posted depreciation is displayed. But the big change was the alternative FYV and how it interacted with the ledger group definition in the GL.
Similar to the above functions, the activation status of FIN_AA_CI_1 at [SFW5] is now irrelevant because the functionality that was previously delivered via the function is now in the standard S/4HANA solution. For these three, SAP isn’t delivering the functionality via add-on or business function anymore.
FIN_GL_REORG_1 and FIN_GL_REORG_SEG
Both of these functions are used by the Profit Center and Segment Reorganization Tools. This is an extremely useful piece of functionality that lets you reassign all related objects in SAP based on a change in the profit center or segment structures. This includes cost centers, materials, orders, projects, assets, and other items that are assigned to a profit center or segment. For fixed assets, the FIN_GL_REORG_1 function (finally!) let us assign assets directly to a profit center and segment. This had very positive reporting implications since we could run asset reports by these objects and do so based on the correct time-dependent assignment of the asset to the profit center / segment. This wasn’t possible previously and required some custom BW work or custom ABAP to meet the requirement.
As of S/4HANA, neither of these functions are supported. They can not be activated in S/4HANA.
What are the implications for New Asset Accounting? SAP was able to carve our the asset specific functionality (i.e., direct assignment to a PRCTR and SEGMENT) from the FIN_GL_REORG_1 function and deliver it separately in a new function called FIN_AA_SEGMENT_REPORTING. This function is new in S/4HANA and is delivered active.
This function delivers new functionality that lets customers automatically manage their inventories in multiple valuations. For fixed assets, there is integration between the different depreciation areas and the CO versions that we can transfer data too. This was delivered with EhP5 for ECC 6.0 and is still supported in S/4HANA.
This function delivered functionality specific to capital purchase orders for low value assets (LVA). This was delivered with EhP5 for ECC 6.0 and is still supported in S/4HANA.
Table Architecture (S/4HANA only)
With the introduction of the Universal Journal (ACDOCA) SAP came full circle by moving away from their dual ledger solution of FI and CO. They were able to arrive at a new singular accounting line item table. This was meant to unify the posting process and reporting for all types of financial areas. Luckily, fixed assets was one of the first modules to be incorporated into ACDOCA which has caused a major change to the underlying tables used to track asset values. To be clear, this only impacts S/4HANA because the universal journal is only delivered in S/4HANA. If you are on New Asset Accounting in ECC, you’ll keep posting to the current tables (shown on the left).
The below image covers the changes in the fixed asset posting data model. Key points to consider:
- The tables on the left will no longer be updated. Going forward, the new tables on the right are used to track asset values.
- Looking at the left side by table…
- The document header information that was posted to ANEK is now posted to BKPF and ACDOCA.
- The line items, both ANEP and ANEA, are now posted to ACDOCA. This applies only to areas that post to the GL. Other areas store there line items in FAAT_DOC_IT.
- ANLP and ANLC are summary/aggregate tables used for reporting purposes. Therefore, there is no specific translation or 1:1 mapping to the new architecture. For instance, the Asset Balances report previously read from ANLC. Now, it can get the same data directly from the original line items stored in ACDOCA which renders ANLC (and ANLP) irrelevant. That said, some of this data is stored on the new FAAT_PLAN_VALUES and FAAT_DOC_IT tables, but some of it is stored on ACDOCA as well.
- Looking at the right side…
- FAAT_PLAN_VALUES stores all planned depreciation and does so per asset, area and fiscal period. This is a big change from the single annual figure we had previously in ANLC. It is also easier to scan if there is any unposted depreciation for a given company or asset at year-end. There is also some data previously stored on ANLP that is now stored in this table.
- FAAT_DOC_IT is a line item table but is used for any asset postings to areas that are not financially relevant. Only the areas that post to the GL are stored in ACDOCA, other non-posting areas store their line items here.
- FAAT_YDDA is a new master data table. In the past, SAP had to store some year dependent data on ANLC because it was the most prominent reporting table that happened to have year in its key. SAP has now removed these master data fields from a transactional/value reporting table and given them their own home on FAAT_YDDA.
Another great source of information on this is SAP note 2270387 – S4TWL – Data Structure Changes in Asset Accounting.
Having covered the changes in the data model at a table level, I have to immediately cover Compatibility Views. What are they and why is SAP using them?
Since the table that is used to store the data has changed… in this case, asset line items previously stored on ANEP are now on ACDOCA… SAP has an issue because they have reports that are still based on ANEP. They could re-code all of the reports and other processes that make reads from ANEP and instead interact with ACDOCA, but they’d also have to re-code the logic itself since that tables are completely different. That would be a major undertaking. The next issue is they know that customers around the world have written custom reports on ANEP. That would force a substantial code-review as part of a customer’s S/4HANA migration. That would be a hard ‘no thank you’ from the customer base.
To rectify this, SAP changed the source or definition of the table itself. The fields weren’t changed… the structure of ANEP is the same in S/4HANA as it was in ECC, but the table is redirected using a proxy object that then points to a view. For ANEP, the compatibility view is FAAV_ANEP. This view has a DDL Source which contains code to select the data from the new source table; ACDOCA in this case. Therefore, all of the existing reports from SAP, any custom reports written by customers, and even basic data viewers such as SE16N will continue to function and, for read purposes only, show data from ANEP… even though there isn’t any data stored physically in the table anymore. The goal of the compatibility views was to reproduce the old table structures within S/4HANA. Or, said another way, make the data stored in the new data model to be available in the format of the older tables.
There has been a large number of changes to the transaction codes for fixed assets but I wouldn’t get too worried about it. As I talked about in the earlier blog (S/4HANA New Asset Accounting (Part 4): Functional Improvements) the changes are mostly minimal. The initial Easy Access menu has had very minor changes. The location of the fixed assets area hasn’t changed and the location of the most of the transactions within the tree is the same. For instance, you’ll find the tcode AFAB in the same location as in ECC.
Here is how I view the changes. Some transaction codes have been removed because they are no longer needed (i.e., obsolete):
- ABST, ABST2 and ABSTL
- ASKB and ASKBN
- ABF1 and ABF1L
- ABB1 and AB02
Some transaction codes are new but most are just replacements to existing transaction codes. For instance, ABAA is no longer available but has been replaced by ABAAL. ABUML has replaced ABUM, ABZOL has replaced ABZON, etc. Also, if you enter in the old tcode such as ABAA, you should be automatically re-routed to the new ABAAL transaction. The full list of new/replaced transaction codes:
- AB01L, ABAAL, ABAKL, ABAOL, ABAVL, ABAWL, ABGFL, ABGLL, ABIFL, ABMAL, ABMRL, ABNAL, ABNEL, ABNKL, ABSOL, ABSTL, ABUML, ABZEL, ABZOL, ABZPL, ABZUL.
Some transaction codes look different because they’ve changed slightly:
There is a large number of changes to the technical programs for S/4HANA.
- SAP has used the introduction of S/4HANA as an opportunity to remove all of the delivered correction programs. Every RACORR* program has been removed… there are over 140 that are no longer delivered by SAP. Is this a bad thing that they’re not pre-delivered anymore? Absolutely not. Unless you can read the code in the program and understand the nature of the updates being performed (and why), gotten specific instructions from SAP Support via the Support Portal (OSS) to run the program, or had prior experience running the reports then they shouldn’t be touched. Personally, I think SAP needs to get a tighter control over these. They’ve already released a few new ones related to ACDOCA and I’m sure there are cases of companies running them without SAP’s consent. Removing them in S/4HANA is justified because most are applicable only to ECC and it’s just a good housekeeping exercise to remove programs of this nature.
- There are a few other programs that have been removed because they are now obsolete:
- Legacy conversion: RAALTD01, RAALTD11, RAALTD11_UNICODE
- Periodic Posting and Depreciation: RAPERB2000, RAPERB2010, RAPOST2000, RAPOST2010
- AA-to-GL reconciliation: RAABST01, RAABST02, FAA_GL_RECON
- FY Change: RAJAWE00
Here’s a quick list of other items that have changed. Most of this is documented between the SAP Help portal, SAP Support portal, and the S/4HANA Simplification Guide.
- This was mentioned in the previous blog but the legacy conversion process has changed. To read more about the changes, head to this link: S/4HANA New Asset Accounting: Changes in Legacy Data Takeover
- The BAPIs have changed. There are a few new ones delivered in S4HANA. Some of the existing ones have changed slightly by adding the Depreciation Area and Accounting Principle fields.
- ALE is not supported (yet) in S4HANA. Surprisingly, New Asset Accounting isn’t supported in Central Finance (cFIN) either.
- The archiving program RAARCH03 is no longer supported. This means it’s not possible to reload archived asset documents.
- This might be worth it’s own blog but it’s not possible to create any batch processes. The GUI has changed such that we can’t do any screen recordings anymore. Any custom BDCs can’t be developed either… but I think this is a very good thing because more people will switch over to using BAPIs.
- A few user exits are no longer supported: APCF_DIFFERENT_AMOUNTS_GET and AFAR0004.
- Recently, in the 1809 OP release of S4HANA, SAP has made changes to the configuration tables for asset company codes. This is most a technical change and impacts how those of us that do the configuration and transports of the solution have to manage it.
If you need to track down other technical changes from the change to New Asset Accounting particularly in S/4HANA, look at the following OSS notes: