Rules for Setting Up the Input File 

The following rules for creating the input file for automatic legacy data transfer must be observed.

Identification of Fields Not To Be Transferred Using Slash (/)

There may be fields that should not be transferred (for example, because they are to be supplied with a default value from the asset class, or because they are not supposed to have values). You are not allowed to leave these fields blank. You have to enter the slash (/) symbol in these fields. If, for example, the depreciation key in area 01 is not to be transferred explicitly, enter the slash (/) symbol in AFASL01.

Do not use the hash (#) symbol in the input file (not even in text fields). This symbol is interpreted as a control indicator by the system during processing of the batch input file.

Initial Record Layout

If the program for setting up the input file is an ABAP program, you can use an include to help initialize the fields for batch input. Include RAALTDI0 contains form routine BALTD_INIT. This form routine creates a record in BALTD format that contains a slash (/) symbol in the first position of BALTD fields, in other words, a sort of ‘initial record layout’ for batch input. For performance reasons, the form routine should not be called up for every record to be transferred using the transfer program. Instead, you should create this ‘initial record layout’ once, and then keep it available in a help structure (in the example, it is structure GS_BALTD).

Transfer program
...

TABLES: BALTD.

DATA: BEGIN OF GS_BALTD.
        INCLUDE STRUCTURE BALTD.
DATA: END OF GS_BALTD.

...

PERFORM BALTD_INIT USING GS_BALTD.

...

INCLUDE RAALTDI0.

...

You do not have to adapt include RAALTDI0 if changes are made to table BALTD in the ABAP Dictionary.

Handling of the Key

Enter the transaction, for which the batch input should be created, in transaction code TCODE: AS91 (create legacy asset), AS92 (change legacy asset) or AS94 (create sub-number for legacy asset). Or you can enter transactions AS81, AS82 or AS84 for legacy group assets.

Always enter the asset class in the ANLKL field , evenwhen using transactions AS92 and AS94.

When using transaction AS92, enter the asset class for the asset to be changed in ANLKL. If you are adding a sub-number using AS94, enter the asset class for the asset main number in ANKL.

If the asset class is numeric, transfer it using leading zeros:

·        Asset class 1250 ==> BALTD-ANLKL = 00001250 but

·        Asset class AIB ==> BALTD-ANLKL = AIB    

In the OLDN1 and OLDN2 fields, specify the main number and sub-number of the asset from the legacy system. As long as you are not transferring any transactions, these fields are not actually necessary for the creation of the new asset master record. However, it makes sense to specify them for two reasons:

·        In case of errors, the asset can be identified using the numbers from the legacy system. This is the only way to clearly identify the assets listed in the error log. The numbers from your legacy system are particularly important in case of a termination of the transfer run. The numbers enable you to determine the record with which the run should be restarted (refer to The Transfer Run (Test Possibilities)).

·        If the new asset numbers are to be assigned internally, this takes place in the sequence determined by the old numbers, since the input file must be sorted according to the key before the running of the transfer program.

Specify the record type in the RCTYP field:

·        RCTYP = A for master data (transfer structure BALTD)

·        RCTYP = B for transactions (transfer structure BALTB)

Special Concerns Regarding Transfer of Transactions

If the transfer date set in Customizing does not fall at the end of a fiscal year, you can also transfer acquisition transactions that have taken place since the beginning of the fiscal year. In this case you would transfer not only master data in the BALTD format, but also transaction data in the BALTB format.

It is possible to transfer transactions that were entered after the close of the last fiscal year and before the transfer date. However, you can only transfer acquisition transactions automatically. You have to enter retirements and transfer postings manually after the automatic transfer. You have to keep this in mind when entering the transaction type. You can recognize acquisition transaction types by the transaction type category 1 in the transaction type group. The following rules apply for the transfer of transactions:

·        Legacy asset numbers: In order to ensure the correct assignment of transactions to their assets, it is mandatory to make sure that the BALTD-OLDN1, BALTD-OLDN2 fields are completed.

·        Counter field for transactions: The BALTD-BWCNT field always has to be completed and contain the exact (!) number of transferred transaction records for a legacy asset. For example, if two BALTB records were transferred for a particular asset, the field must be completed BALTD-BWCNT = 0002. If there are no transactions at all transferred for a given asset, complete the field with 0000.

·        Transaction type: Since only acquisition transactions can be transferred, the BALTB-BWASL field can only be completed using acquisition transaction types.

·        The asset value date BALTB-BZDAT has to be in the time period between the beginning of the fiscal year and the transfer date for legacy data (as specified in Customizing).

·        For assets under construction with line items, the following applies with regard to the asset value date:

·         Line items that were acquired in previous fiscal years have to be transferred using the special transaction types for legacy data (900, 910). Do not enter an asset value date in this case. The system automatically sets the value date to January 1 of the current fiscal year.

·         Line items that were acquired in the current fiscal year can be transferred using normal transaction types for acquisitions (such as 100)  You can choose any date between the first day of the fiscal year and the date of the legacy data transfer as the asset value date.

·        No transactions can be transferred for transaction AS92.

Sequence of the Depreciation Areas For Asset Data Transfer

The following is only relevant if more than 4 depreciation areas are being transferred.

You can set up a special sequence, which applies only for the legacy asset data transfer. This sequence defines the order of the depreciation areas in the Cumulative values screen and Transaction screens of the legacy data transfer transactions. You set up the sequences per company code in Customizing for Asset Accounting. For performance reasons, you should arrange the sequence so that depreciation areas that do not adopt APC values from other depreciation areas come first.  Setting up the sequence in this way means that less scrolling is required in the asset data transfer transaction, since those areas defined for transfer of APC values will directly adopt values (either wholly or in part) from other depreciation areas.

Transfer of Net Book Value

For technical reasons, it is not possible to transfer net book values using the batch input interface. If you nevertheless wish to transfer net book values from your legacy system, you have to set up the interface program in your legacy system so that it already calculates accumulated depreciation as the difference between the acquisition value and the net book value. You can then transfer accumulated depreciation and acquisition costs into the ERP System.

Handling of the INVSLnn Fields in Transfer Structure BALTD for Master Data

You can transfer investment support measures into the fields INVSL01, INVSL02,... and so forth. The investment keys can be entered in these fields in any order. However, you have to begin with the INVSL01 field, and follow in an unbroken sequence.

Completing the Blocks for Area-nn in Transfer Structure BALTD for Master Data

It is particularly important to make sure that you only transfer fields in the transfer record that are available for input during the running of the transfer program.

The depreciation area specified in AFABE02 adopts its acquisition values from the depreciation area specified in AFABE01 (the Identical transfer of acquisition values option is set in the definition of the depreciation area). Then the corresponding field for the cumulative acquisition value is not available for input using transaction AS91. That is, the KANSW02 field cannot be transferred (the slash (/) symbol is in the first position of the KANSW02 field, see above).

Therefore, SAP recommends that you look at one transfer transaction online for each company code, asset class and transaction, in order to see the fields that are actually ready for input.

When setting up the transfer record, you can ignore the sequence of the depreciation areas on the depreciation area/value screen of the transfer transaction. For example, area 20 can be in AFABE01, even if area 20 is the fourth area to be supplied with values in the value screen of transaction AS91.

The content of the AFABEnn (depreciation area) field is not allowed to differ from one company code or asset class to another! This is especially important in the following cases:

Within an asset class you can have assets both with and without investment support keys. If the investment area is specified in AFABEnn, then AFABEnn must remain the same, even for assets that do not have investment support keys, although nothing will be transferred into the other fields in the area-nn. If, for example, investment area 51 is transferred in BALTD-AFABE04, then the field AFABE04 = 51 must also be set for assets without investment subsidies. However, all other fields in the block for area-nn should contain a slash (/) in the first position.

The content of AFABEnn also has to remain constant if you wish to change fields using AS92, even if there are no fields from area-nn to be changed in the corresponding record.

In addition, you should observe the following rules when completing the blocks for area-01 to area-08:

If the field AFABEnn = / (slash) is set, then the transfer program expects that no further fields are to be transferred for all following blocks for AFABEmm (where mm >= nn).

The depreciation areas to be transferred must be transferred, therefore, in a consecutive, unbroken sequence of blocks, starting with area-01. The contents of the fields AFABEnn must also remain constant in this instance (per company code and asset class), even if certain depreciation areas are not transferred for certain assets.