Picking up from the last blog, it’s time to review the functional changes that come with New Asset Accounting.
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?
From an end-user standpoint, a lot of asset functionality is not changed by the FIN_AA_PARALLEL_VAL function in ECC. The master data area is unchanged. Same for the reports and month end processes; both the recalculate values and depreciation posting program are the same. In ECC, the year end roll forward, close, and reversal are also unchanged. There are also no significant changes to any of the underlying tables used in FI-AA (only a few configuration tables were adjusted).
With S/4HANA, we start to see some significant functional and technical changes so the focus for this blog will be primarily on New Asset Accounting in S/4HANA. Why? As outlined in these blogs…
What’s so Simple about SAP Software (Part 1)?
Making SAP Software Simpler (Part 2): The Journey Continues
Making SAP Software Simpler (Part 3): Technical Simplification
… particularly the 3rd one regarding the technical simplification, SAP was able to re-architect the financial accounting interface (RWIN) and introduce a new accounting line item table. This is ACDOCA and relieves a burden on SAP to track line items in an isolated fashion for each financial module. This also alleviates several other burdens for reporting, redundancy, reconciliation, performance, TCO and several other relevant areas that have historically been major enterprise IT pain points.
Now that New Asset Accounting has been incorporated into ACDOCA, SAP has been able to realize a series of significant changes to the asset subledger. For a complete and current list of changes, you can always download SAP’s Simplification List for the relevant S/4HANA release. Read more about that over here: The Best Way to Research S/4HANA Changes
Below is a list of the most important changes that will impact the most customers. If you are migrating to New Asset Accounting or you need to assess the benefit of making the migration, this list should give an overview of the most significant changes and benefits that you’ll see in S/4HANA. I’m focusing on the benefits rather than a complete technical ‘this is what has changed’ listing so not everything is covered here.
Depreciation Area Integration
Probably the most important change in New Asset Accounting from a functional perspective comes down to the increased integration between the asset subledger and the GL. The main juncture for this is the depreciation area. As the GL has shifted the coding block to include ledger, then ledger group, and then accounting principle, FI-AA has had to adjust. Whereas before we had an optional mapping to a ledger, we now have a required mapping to both ledger group and accounting principle. This presents a few benefits.
First, we no longer need any derived areas to account for a valuation. A single depreciation area can be defined and mapped to the appropriate accounting principle which results in a full tracking of that valuation. Delta areas are no longer required for the purpose of parallel valuation. This will significantly reduce the number of depreciation areas which also results in a more transparent and concise listing of areas. This relieves a significant burden in terms of configuration, month end processing, reporting, error correction, and general simplification of the asset solution.
Secondly, we no longer need to post values periodically. The new posting kernel allows for any area to post to the GL in real-time. The number of posting types have been simplified as well. We’ve returned to the same options we had from many years ago where an area either posted realtime or not at all (the other two options will rarely be used).
This also means that each area that maps and posts to the GL will generate its own FI document at the time the asset is posted to. Below is a confirmation message when making a posting to an asset that has two areas that post in realtime to two accounting principles.
Finally, area 01 is no longer hard coded to the 0L ledger; it’s no longer required to be assigned to the leading ledger. In fact, several companies have taken this approach where area 11 tracks the global IFRS valuation which is mapped to 0L, leaving area 01 for a local (usually US GAAP) valuation.
Depreciation Area / Accounting Principle Entry During Posting Transaction
Another major benefit that is related to the change in the posting kernel and increased integration with the GL is a change to the asset posting process. As you can see below, there are new fields to select which depreciation area(s) or accounting principle you want to post to. This shows up on every asset posting screen. The main advantage here is that the user can specify during the posting process which valuation they want to post to. This has always been possible going back to R/3 but it required custom transaction types (TTY). I can’t tell you how many customers have created dozens and dozens… even hundreds… of custom TTY that are area specific and then come close to exhausting the availability of future custom TTY within the customer namespace. We can still (and should) create custom TTY for reporting purposes or other posting requirements but the need to create them purely to post to specific areas is no longer required. This should greatly reduce the need and proliferation of custom TTY and makes it possible to be more responsive to new posting requirements. We don’t have to configure, transport, test, document, etc. for a custom TTY.
Note, in the screenshot below the new fields for Ledger Group and Depreciation Area. This is where the user can directly enter in which area or ledger they want to post to. In subsequent releases, this has changed to Depreciation Area and Accounting Principle.
After you click on the [Area Selection] button, the following pop-up window appears. Self-explanatory.
Asset Explorer
There are two small but welcome changes to the Asset Explorer. SAP has enhanced how the depreciation areas are displayed. Now they are grouped under the appropriate accounting principle in a hierarchical tree view. Secondly, it is now easier to drilldown from an individual depreciation area to the FI document. This is because the new solution is fully realtime and doesn’t require any month-end job to make the necessary postings to the GL.
Fiscal Year Balance Carry Forward
Since ACDOCA is now the one and only source for GL related asset values, the roll forward process that we went through has changed. In Classic FI-AA, the Fiscal Year Change (transaction AJRW, program RAJAWE00) was used to roll forward the balances to the new fiscal year for the asset reporting tables. In New Asset Accounting, AJRW is no longer available. The asset roll forward has been merged with the GL (transaction FAGLGVTR). When the GL balances are rolled forward for the specified company and accounting principle, it is done so for both the GL and the asset values. There used to be some timing issues between the GL and FI-AA teams in the past but that should not be a problem going forward. This new process is simpler and will ensure that both the GL and FI-AA remain in sync for this critical activity.
Note: the year end close and related reversal transactions in FI-AA are not impacted, nor changed.
New Depreciation Posting Program
SAP has completely re-coded the depreciation program with New Asset Accounting in S/4HANA. There are several benefits which we’ve already covered in a separate blog: S/4HANA New Asset Accounting: New Depreciation Posting Program.
Reconciliation
This was documented in the blog on ACDOCA but there should no longer be a need to actively reconcile the asset subledger to the GL. The reason is because every posting to the asset, including the month end depreciation postings, are now posted to the GL first-and-only. In the past in Classic FI-AA, an asset line item was written in the subledger for all areas and only area 01 would generate a posting to the GL. We also had aggregate tables in FI-AA that stored asset balances. All of these usually tied out correctly but for a variety of reasons (cough-cough, incorrect legacy conversion!) they sometimes didn’t which forced us to reconcile and fix the reconciliation issues.
SAP had delivered two transactions to assist with AA-to-GL reconciliation (ABST and ABST2) as well as 3 others that were available (and better) from the SAP Support Portal. There were several other programs available to fix asset specific reconciliation issues. None of these exist anymore in S/4HANA because they are no longer needed. Some customers don’t struggle with this topic but I’ve found others that struggle several times a year trying to fix inconsistencies with reconciliation. In S/4HANA and New Asset Accounting, the entire body of work around reconciliation is no longer needed. This earlier blog gives a more thorough explanation: Making SAP Software Simpler (Part 3): Technical Simplification.
The main benefit of this approach is there is no longer a need to track this issue. It’s done by the system, saves time, and ensures that both sides are in “reconciled permanently… due to the universal journal entry” (SAP Note 2270388).
Smoothing
Thankfully, this functionality has been removed in S/4HANA. I’ve never liked it for a variety of reasons and haven’t implemented it unless it was specifically required. What is it? Take a look at the SAP online help here and here. It reviews what the functionality is as well as shows a nice comparison to the catch-up method of depreciation. Another good resource is SAP note 1562637.
Periodic Posting Program
Since the asset posting kernel has been updated and we have a more trustworthy approach to posting parallel values to the GL in realtime, we no longer require that areas post values periodically. As pointed out earlier, this is a major benefit for SAP customers. Therefore, the Periodic Posting program RAPERB2000 (transaction ASKB, ASKBN) is obsolete. SAP has removed the program entirely.
Account Determination
With the old parallel valuation solution, we had some issues around account determination for derived areas. Now that derived areas and areas that post periodically are no longer required, the account determination for each valuation is far simpler to manage and maintain. We no longer have to manage multiple account determinations per valuation because we no longer have to use derived areas to calculate the full value for a given valuation (i.e., IFRS).
New FI Document Display
With New Asset Accounting there is now a new view available whenever you are viewing an accounting document (i.e., FB03). The new view lets you view the posting per accounting principle which makes it easier to bring together all postings performed in one business transaction.
AIBU/AIAB Settlement
If you are using the AuC settlement process that exists solely in FI-AA… which is completely different than an integrated settlement from a CO object such as an internal order or WBS element… then the functionality has been improved in S/4HANA. The settlement rule maintenance at AIAB now includes depreciation area as part of the settlement rule definition. This gives you more control over how you can settle costs specific to different accounting principles.
There is a new approach to determining how revenue is distributed during a retirement posting. The SAP Help documentation sufficiently describes what this does.
Transaction Codes
I’ll have a more detailed blog out later with technical changes in New Asset Accounting but wanted to highlight a few transaction codes here as well. Because of the significant changes in functionality, SAP had to make some changes to the transaction codes as well. I break them up into the following categories.
- Some transaction codes have been removed because they are no longer needed (i.e., obsolete)
- AJRW
- ABST, ABST2 and ABSTL
- ASKB and ASKBN
- OASV
- AW01_AFAR
- ABF1 and ABF1L
- ABB1 and AB02
- ABSO_OLD
- ABMW
- ABUB
- 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.
- Some transaction codes look different because they’ve changed slightly.
- AS91
- AFAB
- AFAR
- AW01N
- AS01
Programs
There are several program changes but I’ll cover that in a subsequent technical blog.
Fiori
This is another topic that is best handled under it’s own blog because of the changes it presents, not just for the asset or capital accounting areas but for all of S/4HANA. I’ll cover this separately but for now, it’s clear that SAP is putting a lot of emphasis on Fiori and the rest of the frontend solution components. Personas, SAPUI5 et al. are major parts of the SAP value proposition that impact all areas of an organization that touch SAP applications.
What Else?
There are several other changes in New Asset Accounting and while they are justified, I’m not sure that they have a specific customer benefit. For instance, the way that SAP now handles tracking the statistical CO posting for postings made on an asset has changed. This was previously done by specifying CE Category 90 on a cost element. There is now a new parameter for it but it’s still the same approach as before; no extra benefit.
A lot has been made of SAP’s introduction of a Technical Clearing Account but this has been overdone in my opinion. The scenario that uses this is… should be… for a very isolated asset posting. Similar to my statement above regarding AIBU, if the primary way that you are capitalizing costs is by making direct postings to the asset and offsetting them to a vendor (or selling to a customer), then you’ve got a bad design. That’s not the best way (or even 2nd best) to manage capital costs in SAP. Besides, the technical clearing account is a way to balance the entry to support the parallel valuation requirements but it’s not really adding any functional improvement to the user. It’s just what SAP had to do in order to make the journal entry work across valuations and across modules (AP/AR) that may not have separate values per accounting principle but where the asset does.
