1. Introducing the Subject
- Many customers inquire about the possibility of changing the G/L account in the asset configuration throughout the installation process for the following reasons:
- They utilise a false G/L account.
- The incorrect number range is used when they create a new G/L account.
- The G/L account posting should be differentiated based on the asset class, but throughout implementation, they didn’t do so.
The customer wants to alter the G/L account for whatever reason. However, they will see an error message informing them that it is not feasible to alter the general ledger account. This is normal system behaviour since once a posting has been made to the old G/L account, it cannot be changed to the new G/L account. The system is constructed in that way for a good reason: it guards against interference with both the analytical reporting and the input for the asset depreciation calculation. This method is present in SAP S/4HANA and SAP ERP Central Component (Cloud).
First of all, some of us would like to test the G/L account posting in the Q system but are unaware that they cannot alter it any longer. As a result, please bear in mind that this logic exists and will not change in the future as it was intended to do so. When you are certain that the G/L account parameters are accurate, you can post asset posting. Second, once you encounter this issue and realise you need to alter the G/L account, I’d like to demonstrate how to rectify it.
2. Remedy
To move forward with a major asset transfer is the only GAAP-compliant course of action. The asset must be moved from the previous asset class to the new asset class and a new asset class must be created. I’ll demonstrate how to achieve that on the SAP S/4HANA Cloud system in the session that follows.
You want to alter the accumulated depreciation G/L account, according to the business case.
You must first establish new asset classes. In the setting step “assign G/L account,” we build asset class Z2000 by copying 2000, and we construct extra G/L account 17002001 to replace 17002000.
For both individual and bulk asset transfers, we make use of the “Post Transfer inside Company code” software.
Transfer of a single asset
We have the capacity to simultaneously create the new asset and transfer the original asset.
Once the transfer has been completed, a document displaying the old acquisition G/L account’s credit and the new acquisition G/L account’s debit will be uploaded. (In this case, we acquired assets for these two asset classes using the same G/L account.)
Let’s compare the asset values of the new and old assets. You will see that the new asset 200008 has a value of 48 Euros whereas the old asset 200007 has a transfer of -48 Euros.
The accumulated depreciation G/L account has been modified following the depreciation run, and the asset for 2008 now has an actual depreciation value.
Extensive asset transfer
We do not have the option to establish the new asset master record during the mass asset transfer in SAP S/4HANA Cloud, so you must first manually or through data migration construct the new asset master data. The worklist function in SAP S/4HANA on premises allows you to transfer large amounts of assets while also creating asset master data, however as this blog post is focused on the cloud solution, I won’t go into detail about the worklist function in it.
Three old assets in asset class 2000 and three new assets in asset class Z2000 are included in this test case. and we carry out the large-scale asset transfer.
The asset transfer posting is as follows; the change in asset value will be as previously indicated; I won’t show it here.
3. Final Thoughts
While writing the blog post, we didn’t test a lot of the asset. We nevertheless advise being cautious while configuring the asset because, in practise, having a lot of assets necessitates creating a comprehensive plan to track the asset transfer.