Ansicht
Dokumentation

RKE_CHACO_PAOBJNR_4 - Conversion of CO Objects for Account-Based Profitability Analysis

RFUMSV00 - Advance Return for Tax on Sales/Purchases   General Material Data  
This documentation is copyright by SAP AG.

WARNING: This program should only be used in consultation with the SAP development team for CO-PA. You need to ensure that a data backup has been generated for the entire system before the program is used in a production system.

Purpose

The program can be used in cases where the assignment between controlling areas and operating concerns needs to be changed to reflect changes made to the organizational structure of a company.

In particular, it can be used where several controlling areas that are assigned to one operating concern are to be distributed to several operating concerns.

Integration

Within the value flow logic in the ERP system, the profitability segment number for document line items posted in Profitability Analysis (CO-PA) is updated in the document tables of the components SD, FI, MM, and CO in the PAOBJNR field.

The operating concern in which this profitability segment number is valid is determined indirectly from the organizational units stored in the document tables and also from the company structure stored in Customizing.

If the assignment between controlling areas and operating concerns is subsequently changed in a system, this means that the system can no longer correctly interpret any profitability segments stored in the document tables prior to this realignment.

Due to the changed assignment for the controlling areas, the system then erroneously searches for an affected profitability segment in the new operating concern, whereas the profitability segment was originally created in the old operating concern and can only be interpreted in that operating concern.

A distinction can be made between two types of cases in which the system tries to interpret a given profitability segment number with reference to an incorrect operating concern. If the profitability segment number does not exist in the new operating concern, then a short dump is regularly returned with the message number KE499. If, on the other hand, a profitability segment with the same number should happen to exist in the new operating concern, the system then works with the characteristic values for that particular profitability segment. This leads either to follow-up errors during further processing of the document, or, in the worst case, to incorrect data being updated in CO-PA.

Program RKE_CHACO_PAOBJNR_3 can be used to overcome this problem. This program copies the profitability segments relating to a controlling area from the old into the new operating concern, and consequently makes them available there.

A similar problem occurs with activated account-based Profitability Analysis for the Controlling documents that are stored in the following CO tables and that have an account assignment to a profitability segment.

• COEP,,,,(Actual Line Items)

• COEJ,,,,(Plan Line Items)

• COSP,,,,(Totals Records: Primary Cost Elements)

• COSS,,,,(Totals Records: Secondary Cost Elements)

The different fields contain CO objects, which express the account assignment relevant to cost accounting. Account assignments to profitability segments have the form EOXXXXYYYYYYYYYY, where 'XXXX' stands for the operating concern and 'YYYYYYYYYY' stands for a profitability segment number.

If a controlling area is reassigned, this causes an incorrect operating concern to appear in the fields for the CO objects in the Controlling documents that have an account assignment to a profitability segment of the old operating concern that relates to this controlling area.

To solve this problem, you can use program RKE_CHACO_PAOBJNR_4 after having previously run program RKE_CHACO_PAOBJNR_3.

With program RKE_CHACO_PAOBJNR_3, the profitability segments that relate to a controlling area are first copied from the old operating concern to the new operating concern, and consequently made available there. Program RKE_CHACO_PAOBJNR_4 then copies those Controlling documents that have an account assignment to a profitability segment for the old operating concern out of the CO tables listed into temporary tables. There, in the CO objects whose profitability segment relates to the reassigned controlling area, it replaces the old operating concern with the new operating concern, and following successful conversion writes the documents back to the CO tables.

This program cannot, however, be used to convert costing-based transaction data. If you need to do this, use program COPA_COPY.

Prerequisites

You must have activated account-based Profitability Analysis in both the old and new operating concern to execute the program.

The following scenario for changing the assignment between controlling areas and operating concerns is supported: several controlling areas that are assigned to one operating concern are to be assigned to several new operating concerns.

The following example demonstrates this for the controlling areas 1000 and 2000 and for the operating concerns C001 and D001:

Old assignments	New assignments
1000 --> C001	1000 --> C001
2000 --> C001	2000 --> D001

Features

You need to execute the program for each controlling area to be reassigned for each fiscal year.

As a first step, the program can be used to create copies of CO tables COEP, COEJ, COSP and COSS in the customer name space 'Z*' for each fiscal year. For every field that could contain a CO object, these copies contain an additional field in which the converted CO objects can later be written for the time being.

The Controlling documents that relate to a fiscal year and have an account assignment to a profitability segment of the old operating concern are copied to these 'Z*'-tables

In the third step the data is converted, meaning that in the CO objects with account assignment to a profitability segment the old operating concern is replaced with the new one. However, the converted CO objects are initially copied to the additional fields created for the CO objects.

The data from the 'Z*'-tables can then be written back to the CO tables COEP, COEJ, COSP and COSS. In the course of this process, the fields for the CO objects are filled with the converted data from the additional fields.

Finally, the data from the copied 'Z*'-tables can be deleted, and their table definition removed from the ABAP Dictionary.

Activities

Before executing the program, you can first determine the data volume for tables COEP, COEJ, COSP and COSS to be converted for the old operating concern for each fiscal year, so as to give you an idea of the amount of table lines to be copied. For this, choose

,,Extras -> Determine Data Volume

from the menu in the selection screen and confirm the dialog box asking whether you want to continue by selecting Yes. Enter the desired combination 'Fiscal Year' / 'Old Operating Concern'. Because determination of the data volume can take a while, it must be started in the background. The program creates the job ZZRKE_CHACO_CHECK_SIZE_4 and you can specify a start time in the screen that then appears. The job is automatically scheduled and released. The results are saved in the spool list for the job, which you can call up by choosing

,,Goto --> Job Overview.

The steps required for performing the program are described below.

Step 1

Execute program RKE_CHACO_PAOBJNR_3 for each controlling area to be reassigned.

Step 2

Ensure that no documents are posted to the system while program RKE_CHACO_PAOBJNR_4 is being executed.

Step 3

Start program RKE_CHACO_PAOBJNR_4 for each controlling area to be reassigned and each fiscal year with the appropriate old operating concern and new active operating concern.

The following areas of the selection screen need to be filled in this process:

Organizational units

Old Operating Concern / New Active Operating Concern:

Enter the controlling area to be reassigned, the old operating concern and also the new active operating concern.

Example

Old assignments	New assignments
1000 --> C001	1000 --> C001
2000 --> C001	2000 --> D001

In this case, the program only needs to be started for the combination 2000 (Controlling Area) C001 (Old Operating Concern) and D001 (New Active Operating Concern).

Further selections

Fiscal year:

Enter the fiscal year to be converted.

Control Parameters

Test Run:

With this option, the program is executed in a test run for the step selected in the Processing Stepsarea. Processing can be executed in the foreground or in the background. The program generates a log and issues error messages if errors occur. To keep the log manageable, processing ends once the number of errors exceeds 100.

No database changes are made in this mode. The program makes a note of the step for which the test run was started and whether it ran without errors.

Update Run:

With this option, the program is executed in an update run for the step selected in the Processing Steps area. Processing should be started in the background to avoid the risk of a time out.

The program can only be executed in an update run if a test run has already been performed previously with no errors for the selected step.

Here also, the program makes a note of the step for which the update run was started and whether it ran without errors.

Lock Operation Concern (for the Update Run option):

This option is only available for update runs. It locks the old and the new active operating concern against postings. Users trying to post data to these operating concerns receive an appropriate error message.

Tables (see below the Processing Steps area)

Copy of table COEP / Copy of table COEJ / Copy of table COSP / Copy of table COSS:

Enter here the table names selected for the required combination of controlling area, old and new active operating concern and fiscal year in the customer name space 'Z*' . The program proposes the following:

COEP	-->	ZZTKECOEP	(Actual Line Items)
COEJ	-->	ZZTKECOEJ	(Plan Line Items)
COSP	-->	ZZTKECOSP	(Totals Records: Primary Cost Elements)
COSS	-->	ZZTKECOSS	(Totals Records: Secondary Cost Elements)

You can change these table names so that they contain, for example, the fiscal year if you need to convert several fiscal years.

Development Class:

Enter the development class here in which you want to create the copies of tables COEP, COEJ, COSP and COSS. The program automatically proposes the local development class '$TMP'. However, you can also use a development class in the customer name space 'Z*' . This makes good sense particularly if you create the table definition for the copies of tables COEP, COEJ, COSP and COSS in a source system, and want to transport it later into another system.

Processing steps

Execute the program for the selected combination of controlling area, old operating concern and new active operating concern, fiscal year, 'Z*'-tables name and also the corresponding additional options, for the six steps A to F as set out below.

As the steps are dependent on each other, when you execute the program it checks each time whether the previous step has already been successfully carried out in an update run, and if not issues the corresponding error message.

Step A: Copy Table Definition:

In this step, the program creates copies of tables COEP, COEJ, COSP and COSS under the name entered in the customer name space 'Z*'in the area Tables.

For each table field 'FIELDNAME'that could possibly contain a CO object with account assignment to a profitability segment, a new field with the name 'NEW_FIELDNAME' is appended to the relevant 'Z*' table in which the converted CO objects were written in the Convert Datastep.

The table fields for the individual tables are

COEP	-->	OBJNR / PAROB / PAROB1 / USPOB / OBJNR_N1 / OBJNR_N2 / OBJNR_N2 / OBJNR_HK
COEJ	-->	OBJNR / PAROB / PAROB1 / USPOB
COSP	-->	OBJNR
COSS	-->	OBJNR / PAROB / USPOB

Furthermore, an index field 'INDEXOBJNR'is appended to each 'Z*' table, being used for the restart option, and also the field 'UPDATED'is inserted, being used for internal processing.

Step B: Copy Data:

In this step the program copies the data from CO tables COEP, COEJ, COSP and COSS into the corresponding 'Z*' tables in packages of 100,000 records.

All data for the selected fiscal year are copied that coded the old operating concern in one of the fields detailed in step A. Each record is given a unique index in the 'Z*' table field 'INDEXOBJNR'. No selection according to controlling area is made at this point, as this is not available as a field in all CO tables.

Although you can restart the program at this step if, for example, it terminates due to database problems, you should note that if you do so, a restart of the program does not begin at the point it terminated, but starts back at the beginning of the step. The reason for this is that the database does not always return the data in the same order as it was selected, so the program is unable to recognize which data has already been posted to the 'Z*' tables and which has not. Nevertheless, the program does recognize when one of CO tables COEP, COEJ, COSP and COSS has already been copied in its entirety. This is not copied again.

Step C: Convert Data:

In this step, the program checks the fields of the 'Z*' tables detailed in step A in packages of 100,000 records in ascending order according to their index in the INDEXOBJNR field.

If, in field 'FIELDNAME', it finds a CO object in the form 'EOXXXXYYYYYYYYYY', where 'XXXX'designates the old operating concernand 'YYYYYYYYYY' a profitability segment number, it reads the values of the characteristic for profitability segment number 'YYYYYYYYYY' in operating concern 'XXXX', the controlling area in particular. If this matches the controlling area entered in the selection screen of the program, the program replaces the old operating concern 'XXXX' with the new active operating concern 'ZZZZ',and writes the new field content 'EOZZZZYYYYYYYYYY' to the field 'NEW_FIELDNAME'of the corresponding 'Z*' table.

As the program notes the highest converted index from field 'INDEXOBJNR', it is possible to use the restart option, meaning in the event of a program termination due, for example, to database problems you can simply restart it with the same selections.

Step D: Restore Data:

In this step, the program writes back the converted data from the 'Z*' tables to the corresponding CO tables in packages of 100,000 records in ascending order according to their index in the INDEXOBJNR field, so in the above example

ZZTKECOEP	-->	COEP	(Actual Line Items)
ZZTKECOEJ	-->	COEJ	(Plan Line Items)
ZZTKECOSP	-->	COSP	(Totals Records: Primary Cost Elements)
ZZTKECOSS	-->	COSS	(Totals Records: Secondary Cost Elements)

The program initially reads all data from the 'Z*' tables.

As the converted CO objects stand in a field 'FIELDNAME' in the additional field 'NEW_FIELDNAME' appended to the relevant 'Z*' table, the 'Z*' table data still corresponds to the data in the appropriate CO tables, with the exception of the 'NEW_*' fields. The program deletes this data from the CO tables.

Following this, the field contents of the field 'FIELDNAME' are replaced by those of the fields 'NEW_FIELDNAME', provided a converted CO object is in the field 'NEW_FIELDNAME'. This converted data is written back to the relevant CO tables.

As the program notes the highest converted index from field 'INDEXOBJNR', it is possible to use the restart option, meaning in the event of a program termination due, for example, to database problems you can simply restart it with the same selections.

Step E: Delete Data:

In this step, the converted data can be deleted from the 'Z*' tables. Data from the corresponding CO tables COEP, COEJ, COSP and COSS is not removed in this step.

As the program notes the highest deleted index from field 'INDEXOBJNR', it is possible to use the restart option, meaning in the event of a program termination due, for example, to database problems you can simply restart it with the same selections.

Step F: Delete Table Definition:

In this step, the program deletes the table definition of the 'Z*' tables from the ABAP Dictionary. If you execute the program in the background, an error message is generated if a table still contains data. If you start the program online, you receive a dialog box requesting you if the table should still be deleted.

You can only ever execute the individual steps in an update run providing a test run has already been successfully carried out.

The status for each of the steps is displayed on the program selection screen as a traffic light next to the steps. These display the status for the relevant step and a special combination of controlling area, old operating concern and new active operating concern, fiscal year, and table names of the 'Z*' tables. If the traffic light is

• green, an update run has already been successfully carried out.

• yellow, a test run has already been successfully carried out, but not the update run.

• red, no test run has yet been successfully run.

To delete status records you can use the menu path

,,Extras --> Delete Status Information.

On the overview screen that appears, you can select the status records to be deleted as in the program selection screen corresponding to the areas Organizational Units, Further Selections, Control Parameters, Processing Steps and Tables. Confirm the confirmation prompt that appears with Yes.

TXBHW - Original Tax Base Amount in Local Currency   ABAP Short Reference  
This documentation is copyright by SAP AG.

Length: 22284 Date: 20240531 Time: 215653     sap01-206 ( 368 ms )