- SAP Managed Tags:
Introduction
A company's fixed assets are often insured against possible damage or loss. For these insurance policies, it is necessary to manage insurance values and various information on the insurance contracts in the system on an asset-specific basis.
In SAP ERP, the insurance values could be managed in the asset master record or in a separate depreciation area. It was possible to increase or decrease the insurance value using index series. Using the report RAVERS_ALV01 (S_ALR_87012030), the insurance values could then be evaluated considering characteristics from the master record such as the insurance company.
In SAP S/4HANA, only the option using the depreciation area is available. The fields in the master record, the ANLV and ANLW tables and the previous reporting via RAVERS_ALV01 are no longer supported. The fields in the master record must be defined as customer-specific fields if still needed.
Further information can be found in the SAP Help Portal under SAP S/4HANA > Asset Accounting (FI-AA) > Special Valuations > Insurance Values: FAQ | SAP Help Portal
Scenario
The client insures fixed assets using value as-new insurance. For this purpose, the client manages the insurance values in the asset master record, posts revaluations and evaluates the insurance values using the report RAVERS_ALV01 according to criteria such as insurance company and asset insurance type, which are managed in the asset master record (Insurance tab). The fields have a search help. These evaluation options must continue to be provided. It should also be possible to adapt the search help in the future with reasonable effort. The fields must be considered as part of the data migration.
First, I will describe the general customizing for the solution using the depreciation area. I will then continue to explain customer-specific fields, correction postings and reporting. Finally, I will give some insights on migrating the legacy data.
01 Customizing a depreciation area for insurance values
Financial Accounting -> Asset Accounting -> General Valuation -> Depreciation Areas -> Define Depreciation Areas (OADB, OADC)
A separate depreciation area is created for the insurance values, here 30. As the insurance values are generally only evaluated for information purposes for the insurers and have no relevance for the balance sheet, no postings need to be created in the general ledger. The depreciation area therefore does not post resp. only posts in asset accounting. Adjustment postings in asset accounting and for the depreciation area itself are generally possible. The update takes place in table FAAT_DOC_IT instead of table ACDOCA.
For value maintenance, it depends on whether insurance policies are concluded at as-new value or current market value. The current market value is the amount that an insured object has at the time of the claim. The as-new value, on the other hand, is the amount that would have to be spent to replace items of the same type and quality in as-new condition.
As-new value insurance considers revaluations, while current market value insurance also takes into account depreciation.
In our scenario, as-new value insurance is considered. The depreciation area therefore carries acquisition values, it carries net book value (the replacement value or insurance value) and revaluations. The revaluations can be positive or negative depending on the asset/index series.
For the depreciation the valuation category 05 for insurance valuation is used.
Financial Accounting -> Asset Accounting -> General Valuation -> Depreciation Areas -> Specify Transfer of APC Values (OABC)
The acquisition values are transferred from the leading depreciation area via acquisition postings.
Financial Accounting -> Asset Accounting -> General Valuation -> Depreciation Areas -> Specify Transfer of Depreciation Terms (OABD)
In the case of current market value insurance, depreciation must be taken from the leading depreciation area as well.
Financial Accounting -> Asset Accounting -> Master Data -> Screen Layout -> Define Screen Layout for Asset Depreciation Areas (AO21)
It makes sense to create a separate field structure for the depreciation area for asset class valuation. Depending on the insurance type, index series for replacement values or for depreciation must be ready for input. If adjustment postings with a negative sign are to be made in order to achieve results comparable to those of manual updating in SAP ERP, the checkmark for negative values must also be ready for input.
Financial Accounting -> Asset Accounting -> General Valuation -> Determine Depreciation Areas in the Asset Class (OAYZ)
Default settings can be made for the depreciation area in the asset class valuation. For example, the depreciation area can be deactivated for asset classes that are not insured. Furthermore, index series can be entered as default values or, depending on the settings made in the field structure, can also be fixed.
Financial Accounting -> Asset Accounting -> General Valuation -> Amount Specifications (Company Code/Depreciation Area) -> Specify Rounding of Net Book Value and/or Depreciation (OAYO)
If you use an index series to automatically calculate a replacement value in a depreciation area, you can use this indicator to specify if you want to round the decimals in the currency for the area.
Financial Accounting -> Asset Accounting -> Special Valuations -> Revaluation of Fixed Assets -> Indexed Replacement Values -> Determine Depreciation Areas (OABW)
Depending on the type of insurance, the corresponding checkmarks must be set for the depreciation area. (1) APC: Set this indicator, if you want the system to revalue (index) acquisition and production costs of the assets in this depreciation area. In this way, you can have the system calculate depreciation on the basis of replacement values. (2) Depreciation: Set this indicator, if you want the system to use not only the acquisition value when determining the replacement value, but to also index (revaluate) the value adjustments made to the asset in the past.
Financial Accounting -> Asset Accounting -> Special Valuations -> Revaluation of Fixed Assets -> Indexed Replacement Values -> Define Index Series (OAV5)
In this step, you define the index series and the historical index figures for the index series. Assign the index series to an index class. The index class specifies
- whether it is an age-dependent or a year-dependent index series
- age-dependent index points refer to the nth year in which a fixed asset belongs to the business assets. They represent an annual rate of change at the time of acquisition of the asset. Year 1 has a score of 100.
- Year-dependent index scores refer to specific financial or calendar years and represent a rate of change from a specific base year. The base year has a score of 100.
- Whether the calculation is based on the previous year or historically
- when calculating from the previous year, the system determines the current replacement value based on the previous year's replacement value.
- in the case of historical indexing, the system determines the current replacement value based on the historical APC. This calculation variant should be selected if no replacement values from the previous year are available after the legacy data transfer.
The difference between historical calculation and calculation from the replacement value of the previous year (standard) is evident in the treatment of subsequent additions to an asset. With historical calculation, the replacement value is determined as if the subsequent acquisition had taken place in the year of capitalization.
Relevance for data migration
In SAP-standard, the current revaluation of a financial year is always determined at the beginning of the year. This means that revaluation only takes place on the opening balance of the year. Movements in the current year are not revalued.
- With a historical index series, you can adopt the original acquisition value and then have the system automatically calculate the revaluation in the first year. This gives you the current insured value at the end of the year. With this approach, however, you do not have the insured value at the beginning of the year. In addition, there may be differences compared to the values in the old system if the entire acquisition value was not posted at the time of capitalization. If this option is selected, you must maintain the index points from the time of acquisition of the oldest asset with the index series up to the time of the legacy data transfer.
- In the case of a non-historical index series, you must enter the revaluation at the time of the transfer. The revaluation is then calculated as the difference between the current insured value at the end of the previous year and the acquisition value.
In our scenario, we select index class 1 for all index series and enter the difference between the acquisition value and the insured value as a revaluation to obtain the net book value.
Maintaining the index point numbers is not particularly convenient, especially if a large number of different index series are provided. It is therefore advisable to write the index point numbers directly to table T094P using a custom-specific program.
02 Custom fields
The Insurance tab in the asset master record has been removed without replacement. This therefore also applies to the selection features previously available there, such as asset insurance type and insurance company. The fields that are still required must be implemented as customer-specific fields. Two scenarios are available to achieve this:
- activate a customer enhancement project with the enhancement AIST0002.
- extend the asset master record using the Fiori-app “Custom Fields and Logic” (F1481).
I would like to briefly outline both variants below:
Enhancement AIST0002
To have a search help available, a customer-specific table is required for each customer-specific field. The tables are created using transaction SE11. A parameter-transaction for maintaining the tables is created using transaction SE93. Transaction SM30 (skip initial screen) is used to access the table. The parameters are VIEWNAME = name of the table, UPDATE = X. A search help is created for each field based on the respective table using transaction SE11. The selection method is the table. The customer field is specified as a parameter.
The user exit is implemented using transaction CMOD. An enhancement implementation is created here. For the asset master record, this is AIST0002.
The following coding must be maintained in the includes of the function modules:
- ZXAISU05: e_anlu = I_anlu
- ZXAISU03: anlu = i_anlu
- ZXAISU04: e_anlu = anlu
The customer-specific fields can then be created in the include table. The search help must be specified in the Input Help/Check tab.
The fields must now be included on a screen of the asset master record. To do this, call up transaction SE80 and the XAIS function group. Create a screen under Screens, here 9001. The fields can be arranged on the screen via “Layout”.
Finally, the screen is integrated into the screen layout of the asset classes via the transactions AOLA and AOLK. A description can be found after I outlined the use of Fiori app “Custom Fields and Logic”.
Fiori-App „Custom Fields and Logic“
In the Fiori-App “Custom fields and Logic” (F1481), customer-specific fields can be created within business contexts. The business context for the asset master record is “FAA_ASSET_MASTER_DATA”. In our case the fields are created with the type “Code List”. This enables the maintenance of a search help as shown below.
In the “UIs and Reports” tab, the customer-specific field is activated in the relevant Fiori-Apps. The “Asset Balances” App (F1617) is particularly suitable for evaluating the insurance values.
For transport within the system landscape, the fields must be assigned to a workbench request and a package via the Fiori-App “Register Extensions for Transport” (F1589).
Financial Accounting -> Asset Accounting -> Master Data -> Screen Layout -> Specify Tab Layout for Asset Master Record (TA AOLA, AOLK)
The standard SAP layout is copied to include the fields in the asset master record.
When using the enhancement AIST0002, the screen, in this case U9001, is integrated as a group at the desired position in the relevant tab.
If the Fiori app “Custom Fields and Logic” was used, group S0050 must be included.
The layout must then be stored in the relevant asset classes.
The fields are now available in the asset master record.
03 Adjustment postings
In SAP ERP, it was possible to adjust the insurance values via the option manual updating. In order to be able to maintain an acquisition value that deviates from the leading depreciation area for the revaluations and the resulting insurance value, it must be possible to make adjustment postings that only affect the depreciation area for insurance values.
Two movement types can be created for this purpose, for example on the basis of movement type 400 post-capitalization. Customizing is carried out via transaction SM30 and maintenance dialog TABW_ALL. The sign is controlled via the Debit/Credit checkmarks. Debit leads to a posting with a positive sign, credit leads to a posting with a negative sign. For postings with a negative sign, the checkmark for negative postings must be set in the asset master record for the depreciation area. Asset history sheet group is not really relevant if you report insurance values through Fiori-App "Asset Balances" (F1617).
The transaction types can be restricted to the depreciation area for insurance values if required.
Postings are possible via transaction ABSOL or the Fiori app “Post Miscellaneous Transactions”. It must be taken into account that the postings are posted with the corresponding revaluation if an index series is assigned in the master record. If the adjustment posting is to be made without revaluation, the index series for the posting must be temporarily removed from the master record.
* 30 should be insurance values here on the screenshot for the depreciation area. It's just a missing translation.
04 Reporting
The “Asset Balances” app (F1617) is suitable for evaluating the insurance values. Here, the acquisition value, revaluation and net book value provide exactly the key figures required. The net book value corresponds to the insurance value.
If the “Custom fields and Logic” app was used, the fields are available as dimensions. Ideally, you create your own bookmarks. Note 3194844 should be considered regarding showing the description of the assets.
05 Year-end-closing activities
The revaluations are posted for the (still open) previous financial year by performing a recalculation via transaction AFAR or the Fiori-App Recalculating Values (F1376) for the depreciation area after the new index point figures have been imported.
Only after the revaluations have been posted and checked for consistency year end close in asset accounting should be performed.
05 Migration
Insurance values
Data Migration is performed via Data Migration Cockpit in most cases.
There are several possible scenarios for the depreciation area. (1) The depreciation area is created in the legacy system (report: RAFABNEW). The values are transferred as part of the legacy data migration. (2) The depreciation area is created in SAP S/4HANA only. The values are then transferred as part of the legacy data migration. (3) The depreciation area is subsequently introduced in SAP S/4HANA (report: RAFAB_COPY_AREA). The restrictions according to the program documentation must be considered. This scenario is particularly relevant if the index series have not yet been determined at the time of the legacy data migration.
I would like to take a closer look at scenario 2 below. The approach using staging tables is discussed.
If there is not yet a depreciation area for insurance values implemented in the legacy system, it does not necessarily have to be created there but also can be created in Excel as part of data consolidation. The relevant tables for the depreciation area are ANLB and ANLC. After the data has been exported from the legacy system to Excel, the rows of the leading depreciation area could be copied. The values in the AFABE field are adjusted accordingly. The data can then be consolidated and mapped, e.g. enriching the index series (ANLB-WBIND).
To obtain the insurance values, the insurance report RAVERS_ALV01 (S_ALR_87012030) can be exported to Excel. The difference between the acquisition value and the insured value is transferred as a cumulative revaluation (ANLC-KAUFW).
Custom fields
The fields can be found in table ANLV. Data Migration is carried out in the standard system via the migration cockpit or via LSMW.
A LSMW is no problem for custom fields that were created via user exit. In the Data Migration Cockpit, however, the fields cannot be added to the target structure without further ado if a BAPI is the basis. The Fixed asset migration object (incl. balances and transactions) is based on the BAPI BAPI_FIXEDASSET_OVRTAKE_CREATE. The BAPI would have to be copied, adapted and a new migration object set up in transaction LTMOM. This effort is rarely justified in my opinion.
Customer-specific fields of certain business contexts are automatically transferred to the migration objects. This applies, for example, to the migration object "Fixed asset - Master data" in case Universal Parallel Accounting (FINS_PARALLEL_ACCOUNTING_BF) is used.
Alternatively, migration is possible via LSMW. However, fields generated via the "Custom Fields and Logic" app have the same field name SAPLCFD* on the screen for LSMW. If there is more than one custom field on the screen, LSMW always fills the last field on the screen whether it was recorded or not. A workaround is to temporarily deactivate the fields below the top custom field and run the LSMW for each field individually. After each run, the next field must be activated. If a field with data is deactivated, the data is initialized. This must be taken into account for subsequent mass changes.
1 Comment
