S/4HANA New Asset Accounting: Changes in Legacy Data Takeover

S/4HANA is SAP’s next generation ERP platform. Much has been written about it and the changes it has delivered. In the finance area, the biggest change has been the introduction of the Universal Journal, aka ACDOCA. There have been many other improvements… Central Finance, RAR, Fiori, Smart Cash Management… but if I had to rank them all, the universal journal has been the biggest change.

Why? For starters, it’s the central repository for nearly all financial line item details and therefore impacts all of the feeding posting processes as well as the reporting for those processes. As a side note, it’s extremely interesting to see how SAP moved away from their long standing dual-ledger solution (FI and CO) and coming back to a single repository coding block. They’ve come full circle but no one seems to talk about it in that sense.

For this blog I’m going to bring attention to the changes that S/4HANA and ACDOCA have had on the fixed asset legacy conversion process. I could cover the entire A-to-Z scenario but there are many stops along the legacy conversion road that have not changed. Just as with the simplification lists that SAP publishes, it’s best to focus on the changes instead.

AS91

Where to start? Well, when you talk about the asset conversion process, the first thing that most of us think about is ‘AS91’. Let’s start there.

The good news is that AS91 still exists and is the same as it was in ECC. The only change… and it’s a big one… is that we no longer maintain the asset values while creating the asset at AS91. The [Takeover Values] button which was used to maintain both legacy aggregate balances and line items is no longer available. Otherwise, it’s the same process. AS91 is used to create the asset shell and is identical to AS01 except that SAP requires a capitalization date.

As a reference, below is a screenshot of AS91 in ECC.

The image below is from S/4HANA. Note the absence of the old [Takeover Values] button.

ABLDT Posting Process

Since it’s not possible to enter in the asset’s financial values at AS91, we’ve reached the big change in the conversion process in S/4HANA. With the introduction of ACDOCA, SAP has chosen this opportunity to enforce that the legacy asset values are maintained via a common posting process. i.e., the asset values, whether it’s a transactional line item for a mid-year takeover or a balance value for an end-of-year takeover, must be maintained with a posting to ACDOCA. A journal entry is required for the recording of the asset’s initial legacy balance. This is the big new thing with the asset conversion process. There is no longer a way to make a direct ANLC update, which is fine because ANLC is no longer used. The good news about this process… and it’s one of the reasons why SAP chose this route… is that it is no longer necessary to subsequently record the balances in FI. With ABLDT, both the asset in FI-AA and the corresponding GL account in FI-GL are updated with the same amount. I can tell you from experience that 95% of the time when customers have a reconciliation issue between the GL and the asset subledger, it’s because the legacy conversion process wasn’t done correctly. That won’t be an issue going forward.

The actual steps to use this tcode are self explanatory. Specify the asset and enter in the values per area and value type.

When you save the data, you’ll get confirmation about the documents that were created. It’s the same confirmation as when you create any other asset posting.

For other asset conversion processes, ABLDT_OI is available for the migration of AuC open items and AB01L can be used for current year postings for a mid-year takeover.

Options to Load in Mass

AS91 and ABLDT will create a single legacy asset with it’s appropriate value. How do we do that for multiple assets? Millions of records?

Well, we can use the same programs we’ve used for decades, right? Nope, not in S/4HANA. RAALTD01, RAALTD11, and RAALTD11_UNICODE are no longer delivered.

Next option; LSMW. Is it still available in S/4HANA for conversion purposes? Yes, and no. Below are some excerpts from SAP Note 2287723 v8 (emphasis added):

The LSMW (Legacy System Migration Workbench) tool (transaction code LSMW) is still available within SAP S/4HANA on-premise but not considered as the migration tool.

The Legacy System Migration Workbench (LSMW) is an SAP NetWeaver tool for data migration that was first introduced with R/2 to R/3 migrations. It uses standard interfaces like BAPIs, IDocs, Direct Input and Batch Input programs and recordings. Due to this nature, the use of LSMW is for migrations to SAP restricted S/4HANA.

The use of LSMW for data load to SAP S/4HANA is and at the not recommended customer's own risk.

Expect restrictions around transaction recording (as this is not possible with the new SAP Fiori screens) and changed interfaces (for instance the Business Partner CVI). Standard Batch Input programs may also no longer work as transactions may have changed functionality or may be completely removed within some areas.

There is some strong language in there. The one that catches my eye the most is the third statement… the usage of LSMW is at our own risk.

In earlier versions of the note (back circa S/4HANA 1509), SAP stated that LSMW wasn’t supported at all except for RE and FI-AA conversions. SAP has other conversion tools that they prefer such as the SAP Migration Cockpit (LTMC), SLT, or Data Services so this communication wasn’t a big surprise. However, with the updated simplification list SAP states that LSMW is a supported method for the conversion process.

That means we can continue using LSMW for the asset conversion process but I wouldn’t assume that this will be the case going forward. I think that LSMW will eventually be removed from S/4HANA so it is a solution that Serio Consulting no longer recommends for asset legacy data takeover.

That said, if you’re a frequent user of LSMW don’t assume that you’re home free. If you read the excerpts above, you’ll see that you can’t consistently use LSMW’s recorder feature. If you look at the ABLDT screenshot, it uses an ALV grid to enter in the data. This type of screen input can not be recorded by LSMW or the BDC recorder (and most likely eCATT but I haven’t tested it). SAP Note 311440 has the technical justification for why it’s not possible to batch a screen that uses an ALV grid for data input.

The good news, in my opinion, is that if you are going to use LSMW, you have to use the BAPI for creating and posting legacy assets; BAPI_FIXEDASSET_OVRTAKE_CREATE. I like this approach for the reasons that a BAPI is far superior to a batch screen recording. I’ve been using BAPIs instead of screen recordings for years and would highly encourage everyone to use them whenever they are available. BDCs, SM35, recorders are error prone, not stable, and the error correction process is a nightmare for a large set of data.

To be clear, you don’t have to use LSMW if you want to use the BAPI. You could use Data Services or a z-program. The choice is up to you. If you use LSMW and the BAPI, here is a screenshot of the BAPI structure that you’ll be working with. It looks intimidating at first but I prefer the detail.

Another option is to use transaction AS100. AS100 has been around for a long time. This lets you load asset data directly from Excel and calls the same takeover BAPI. It is fully compliant with ACDOCA and can be used productively. However, there are a few reasons why I don’t recommend it even for a small set of data. AS100 was intended for very small legacy conversion processes because SAP customers had (for years) been requesting a direct path from Excel-to-SAP for legacy conversion of assets since so many of them maintained their asset data in Excel. The solution is a bit crude, hasn’t been enhanced for S/4HANA, can’t be transported so you have to maintain the mappings in every system-client and the error correction isn’t easy. It’s OK for a small merger/acquisition load but for the type of customers that we deal with (i.e., large capital intensive multi-nationals), this isn’t an option.

Here are some other comments on the BAPI:

When S/4HANA first came out, only BAPI_FIXEDASSET_OVRTAKE_CREATE was available. It would both create the asset shell and post/valuate it as well. It was not possible to use it to post a value to an already (manually?) created legacy asset.
Because of this shortcoming, BAPI_FIXEDASSET_OVRTAKE_POST was released and is documented in SAP Note 2481644. As the name applies, this BAPI can be used to post to an already existing asset. It requires that the asset already exist and that it be a legacy asset (not a normal asset). It also requires that there be no other existing postings on the asset unless they’ve been reversed (i.e., the asset value is 0.00).
Sometimes, there are problems with the asset conversion and the values have to be changed. This is still not possible in S/4HANA. We have to first reverse the original asset posting and then re-record it correctly. SAP has now released a new BAPI to facilitate this; BAPI_ASSET_REVERSAL_POST.

Lastly, while the _OVRTAKE_POST and REVERSAL_POST BAPIs provide options to work around a complex legacy conversion, I can’t stress enough how critical it is to get the values right the first time. It’s difficult to fix these values post go-live so you’ll want to have multiple mock loads validated before proceeding to production.

What Else is Different?

[OAMK] is still available and useful but I’m not sure it will be used anymore as part of the legacy takeover process since we’re making the FI entry by posting to the asset directly. There is no need to turn off the reconciliation status for the asset GL accounts.

To account for this new posting process, SAP has delivered a few new transaction types. In addition to these, you’ll see TTY 500 for the current year posted depreciation in a mid-year takeover.

How Does it Look?

Once you’ve create the asset, this is how it looks at [AW01]. This is a simple year-end takeover so you’ll see different results for a mid-year takeover where the asset has current year posted depreciation and additional line items.

Here is the accounting document that was posted. This is the end result of the load process in the sense that valuating the asset was done via an FI document, thus guaranteeing that the asset subledger and GL are in sync.

Back at the Asset Explorer, moving the fiscal year forward shows the aggregate balances are properly shown.

Configuration

The first change is that we have to specify the offsetting GL account to be used as part of the legacy takeover posting. While all of the asset GL accounts are specified at an account determination level as part of normal FI-AA configuration, this singular account is specified as part of the FI automatic postings (T030).

In S/4HANA we now get the chance to specify a document type for these postings.

Another new option is to “Calculate Planned Values”. This setting stops the asset posting process from calculating the plan values for the fiscal year (FAAT_PLAN_VALUES). If it’s active, the FAAT_PLAN_VALUES table won’t be populated and you’ll have to execute a recalc to determine the current year depreciation. The only reason to use this feature would be for loading performance. If you have an extremely large dataset, then use this feature to stop SAP from calculating current year depreciation as part of the posting process and control it yourself separately.

The last item is that SAP has changed some of the customizing settings in S/4HANA 1703 for the company code. I’ll cover these in a separate blog.

Reference

If you need even more information, here is a list of SAP Notes that I reference when working with asset conversions:

S/4HANA New Asset Accounting: Changes in Legacy Data Takeover