SAP: COPA: Defining new characteristics

You can also manually define new characteristics that you only want to use in Profitability Analysis. Since these characteristics have no table of origin, their values are not automatically derived from other characteristics. You therefore need to define derivation steps for them. The name of new characteristics must begin with "WW" and consist of 4 or 5 characters. Depending on the desired attributes, you must choose one of the following variants:

With own value maintenance - In most cases, you will define new characteristics with their own value maintenance. In this case, the system creates a check table and text table. In the Customizing activity Maintain characteristic values , you can then enter characteristic values and texts for these. Only those values maintained here are permitted values for that characteristic.

Without value maintenance - This option lets you define characteristics with no check table. This means that there is no set of allowed characteristic values and texts. Consequently, no validity check takes place for values of these characteristics. These characteristics cannot be used as receiver characteristics for period-based allocations.

With reference to existing values - This type of characteristic is only required in special cases. Here you assign the characteristic to a data element that already exists in the system. The characteristic takes on the attributes of that data element (texts, length, check table, text table).

source: help.sap

SAP COPA: Deleting Characteristics/ Value Fields from an Operating Concern

You can delete characteristics and value fields retrospectively from an operating concern that you have already activated. However, you should only use this deletion function for operating concerns that have not yet been used productively. You should also note that some database systems require the operating concern tables to be converted (database conversion) after the deletion has taken place if data had already been posted to the operating concern. Depending on the data volumes involved, the database conversion can take a matter of seconds or indeed several hours. Moreover, you cannot post data or run reports during the conversion. Due to integration, other applications are also affected when data is postedwith an assignment to profitability segments (such as settlement and direct assignment from FI/MM). If the operating concern has been transported to another system (such as the productive system), then the database conversion must also occur in that target system.

To delete characteristics or value fields, perform the following activities:

1. Delete the corresponding characteristics and value fields from Customizing in all clients (this includes forms, reports, planning layouts, and so forth). To locate characteristics and value fields, use the appropriate where-used list in the Customizing Monitor . You can access it by choosing Tools -> Analysis -> Check Customizing Settings. You can jump directly from the where-used list to the relevant Customizing transaction and then delete the appropriate field there.

2. Switch to the screen for maintaining the data structure of an operating concern (Maintain operating concern).

3. If you need to effect other changes to the datastucture for the operating concern before making any deletions, effect those changes and save the data structure.

4. In order to be able to select the fields of the data structure, choose Extras -> Characteristics (or Value fields) -> Unlock.

5. Select the characteristics and value fields to be deleted and remove them from the data structure with the "Reset fields" function.

6. Reactivate the operating concern. The system starts by checking whether the operating concern contains any data and whether the fields to be deleted are still being used in any Customizing settings.

7. If none of the fields are still in use, the system then starts the re-activation. If the operating concern does not contain any data or does not require the database system to be converted, the tables are activated. You are then able to activate the environment for the operating concern. In this case, the following activities no longer apply.

If the operating concern already contains data, a system message tells you that the database needs to be converted. If you proceed, an activation log appears (at the top of the list).

8. Analyze the activation log. If it only contains error messages telling you to convert the tables, proceed with the next activity.

You must otherwise remove the cause of the errors before the tables can be converted. In this case, you should answer "No" to the next prompt, which asks whether the conversion transaction should start.

9. If you still only receive error messages telling you to convert the tables, choose "Back" and start the conversion.

10. Plan a job for the conversion. A list of the tables to be converted is shown for this. If the tables only contain a small amount of data (less than 10 000 records), then all the tables can be converted in one job. In that case, you can select all the tables.

For larger tables, conversion should take place in several jobs. However, you should ensure that table CE4xxxx (where xxxx = operating concern) is the last table to be converted.

Warning. No other changes can be made to the operating concern during the conversion.

A copy of the table is generated during the conversion. The database system should have sufficient memory available for this copy.
To schedule conversion as a job, use the "Schedule selections" function. You can display the current status of the conversion by selecting the "Refresh" icon. Tables disappear from the list once they have been converted sucessfully. If a conversion is taking a while, it is also possible to leave the transaction. You can then continue the conversion using DB requests -> Mass processing in one of the following ways:

With the job overview. You access this by choosing System -> Services -> Jobs.

Using the database utility transaction. You access this by choosing Utilities -> Database Utility in the ABAP Dictionary menu.

You can use the status function to call up the status of the operating concern during operating concern maintenance. You need to activate all tables after conversion.

11. To analyze errors that have occurred during the conversion, you can use the database utility transaction by choosing Extras -> Logs. The log has the same name as the conversion job: TBATG-date. You can also restart the conversion with this transaction.
For more information on the database utility, choose Help -> Application help while still in the above transaction.

12. Once you have activated all the tables in the operating concern, generate the operating concern environment from within operating concern maintenance.

You can then use the operating concern again.

SAP: COPA :Tables

When you activate the data structures of your operating concern, the system creates the following objects in the ABAP Dictionary.

 

Type	Name	Description
Structure	CE0xxxx	logical line item structure
Table	CE1xxxx	actual line item table
Table	CE2xxxx	plan line item table
Table	CE3xxxx	segment level
Table	CE4xxxx	segment table
Table	CE4xxxx_KENC	realignments
Table	CE4xxxx_ACCT	account assignments
Table	CE4xxxx_FLAG	posted characteristics
Structure	CE5xxxx	logical segment level
Structure	CE7xxxx	internal help structure for assessments
Structure	CE8xxxx	internal help structure for assessments

ABAA - AFAR : Unplanned Depreciation - Recalculation of Depreciation

ABAA - Unplanned Depreciation

 

There is an unexpected permanent reduction in the worth of the asset that you have to post as unplanned depreciation.

 

As a rule, the system automatically determines the planned depreciation for the current fiscal year by means of the depreciation keys entered in the master record. If you need to specifically set the amount of depreciation, the system offers a manual unplanned depreciation forecasting option. This means you can manually increase the planned values managed for the asset.The G/L accounts in Financial Accounting are not initially affected by this posting transaction. Asset line items are created, but no FI posting documents. The general ledger accounts are updated and the corresponding FI documents are created by the periodic depreciation posting run. The system then determines the depreciation to be posted up to a specific period, and creates the accompanying posting documents.

 

Transaction type - 640 : Unplanned depreciation on prior year acquistions

 

During posting system automatically calcualtes the depreciation in different amounts for different depreciation areas.

 

After posting you can see the same in AW01N in Planned values section under 'change' column against Unplanned depreciation

 

AFAR - Recalculation of Depreciation

 

This might be necessary if:

 

· You have changed depreciation keys.

· You have made mass changes that you programmed yourself, and these changes affected data relevant to depreciation.

· You want to calculate subsequent revaluation (after the legacy data transfer is closed) using current index figures. In order to correctly calculate replacement values, however, you can only use index series that calculate historically.

 

This program enables you to recalculate planned annual depreciation using the depreciation terms that are valid at the time that you start the report. You can also run the report in test mode. However, you can only recalculate planned depreciation for fiscal years that are still open. After the system recalculates the planned annual depreciation, it creates a statistical log with the total number of assets processed and the number of assets with errors. You can check the assets with errors using the asset value display transaction.
 

SAP: Transfer of Legacy Asset Data Methods

How is depreciation entered during old assets data takeover?

 

Answer:

 

Asset Accounting always manages the values related to the fiscal year.

Depreciation values for previous fiscal years are always entered as cumulative values.

 

Estimated annual depreciation values for the current fiscal year with an old assets data takeover during the fiscal year cannot be entered because they are calculated automatically by the system. Differences from the estimated annual depreciations can therefore only be adjusted as manual value corrections, that is, by entering an asset transaction.

However, if you use a a depreciation key which does not automatically calculate the depreciation, for example depreciation key MANU, the manual depreciation must be entered during the transfer with a 6xx transaction type.

 

If depreciations have already been posted for the takeover year in the legacy system, these values must also be entered into the SAP System sothat they can be used by the posting program.

 

Source: OSS 50607

 

What are the legacy data transfer methods available in Asset Accounting and how are they different?

 

Answer:

 

The following is an overview of the legacy data transfer methods with additional information on the transferring legacy assets R/3 library.

 

1. Manual transfer with Transaction AS91 - This works with Transaction AS01 and is suitable for transferring smaller datasets.

 

2. RAALTD01 transfer via batch input - This is suitable for the mass processing of larger datasets. The batch input session fills the fields of Transaction AS91 up to and including Release 4.0B or of Transaction AT91 for subsequent R/3 releases. Therefore, only the data fields of these transactions can be filled.

 

3. RAALTD11 Transfer via direct input - This is suitable for transferring very large datasets. It transfers the same fields as RAALTD01 does, however it only carries out limited field checks. So that you do not receive any incorrect datasets as a result, first test at random the assets to be transferred in AS91 or as of Release 4.5B with Transaction AT91.

 

Furthermore, bear in mind that value fields are not converted. If, for example you specify a value field for an amount of money in euro in the BALTD-structure, you must consider the format. If, for example the value field has the format ###,## and you only enter 10 as a value, this value is interpreted as 0,10. Therefore you must specify 10,00 as value in BALTD.

 

To achieve the high performance of RAALTD11, the writing of change documents was also dropped. When you go into the change document display of an asset that was created with this report, the system generates the message "Asset created with Transaction AS02" or " ... AS92" by mistake.

 

Both RAALTD01 and RAALTD11 have not been enhanced since Release 4.5B.As of Release 4.6B, the legacy data transfer therefore is recommended via BAPI BAPI_FIXEDASSET_OVRTAKE_CREATE since this offers all of the transfer options of the new Transaction AS91 (as of Release 4.5B).

 

The following methods use this BAPI.

 

1. Transaction AS100 data transfer with Microsoft Excel - This is suitable for the transfer of smaller datasets (limited by the line count of your Excel version). This transaction is suitable in particular if you have mapped your Asset Accounting prior to R/3 using Microsoft Excel. However, you can create only main asset numbers. More restrictions are described in Note 303710.

 

2. Transfers via Workbench LSMW or SXDA - BAPI_FIXEDASSET_OVRTAKE_CREATE is used by Business Object Method BUS1022->Create Incl Values, message type FIXEDASSET_CREATEINCLVALUES and IDoc type FIXEDASSET_CREATEINCLVALUES01.You can also call it for the legacy data transfer even from your own program. You can find more information in the documentation of the function module in Transaction BAPI.