Kontakt

Ansicht
Dokumentation

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

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

Vendor Master (General Section)   PERFORM Short Reference  
This documentation is copyright by SAP AG.
SAP E-Book

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 for instances where one or more operating concerns are to be replaced by just one new operating concern.

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.

This problem can be solved by using program RKE_CHACO_PAOBJNR_1. In the document tables of the SD, FI, MM or CO components, the program systematically replaces the profitability segments of the old operating concern with profitability segments of the new operating concern.

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 an operating concern is replaced, this causes an incorrect operating concern as well as a profitability segment number from this operating concern to appear in any Controlling documents that have an account assignment to a profitability segment of this operating concern.

To solve this problem, you can use program RKE_CHACO_PAOBJNR_2 after having previously run program RKE_CHACO_PAOBJNR_1.

With program RKE_CHACO_PAOBJNR_1, the profitability segments from the old operating concern in the document tables for the components SD, FI, MM, and CO are first systematically replaced with profitability segments from the new operating concern. Program RKE_CHACO_PAOBJNR_2 then copies the 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, where it replaces the old operating concern with the new operating concern. The related profitability segment numbers of the old operating concern are replaced by those of the new operating concern. The program summarizes the totals records again, and writes the data back to the CO tables. In doing so, both programs are able to convert the data of several old operating concerns that is to be assigned to the same new operating concern in a single run.

Program RKE_CHACO_PAOBJNR_2 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 operating concern and new operating concern to execute the program.

The following scenarios are supported for changing the assignment between controlling areas and operating concerns:

  1. An operating concern needs to be replaced by another one. All controlling areas assigned to the old operating concern are assigned to a new operating concern.
  2. Multiple controlling areas assigned to multiple operating concerns need to be assigned to a new operating concern.

The following examplesdemonstrate this for the controlling areas 1000 and 2000 and for the operating concerns C001, D001, and E001:

Example 1
Old assignments New assignments
  1000 --> C001 1000 --> E001
  2000 --> C001 2000 --> E001

Example 2
Old assignments New assignments
  1000 --> C001 1000 --> E001
  2000 --> D001 2000 --> E001

Bear in mind that all controlling areas assigned to an old operating concern must always be reassigned, and that all are to be assigned to the same new operating concern.

Features

You need to execute the program for each of the operating concerns 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 concerns 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 of the old operating concerns the old operating concern is replaced with the new one. In addition, the profitability segment numbers of the old operating concerns are replaced by those of the new operating concern. However, the converted CO objects are initially copied to the additional fields created for the CO objects.

The next step reads the converted data from the 'Z*' tables, fills the original fields of the CO objects (if necessary) with the converted CO objects, and writes this dataset back to the 'Z*' tables. In addition, the dataset copied from the totals tables COSP and COSS are summarized again, as it is possible that totals records with different keys receive an identical key as a result of the conversion.

The data from the 'Z*'-tables can then be written back to the CO tables COEP, COEJ, COSP and COSS. The records that were copied originally are then deleted from the CO tables.

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 for each fiscal year for the old operating concerns to be converted, 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 Concerns'. 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_2and 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_1 for the combination of old operating concerns and new operating concern.

Step 2

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

Step 3

Start program RKE_CHACO_PAOBJNR_2 for the combination of old operating concerns and new operating concern for each fiscal year.

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

Operating Concerns

Old Operating Concerns / New Active Operating Concern:

Enter the old operating concerns to be replaced and the new active operating concern.

Example

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

In this case, the program only needs to be started for the combination C001 / D001 (Old Operating Concerns) and E001 (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 Stepsarea. Processing should be started in the backgroundto 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.

Call up Derivation in New Active Operating Concern:

This option makes it possible to derive the converted characteristics vector in the new active operating concern again (see Converting the Profitability Segments below).

Check Characteristics in the New Active Operating Concern:

This option makes it possible to carry out a validity check of the characteristic value for the converted characteristics vector in the new active operating concern (see Converting the Profitability Segments below).

User Exit for Field Assignment:

This option makes it possible to create the characteristic assignment between old operating concerns and a new active operating concern individually using a user exit (see Converting the Profitability Segmentsbelow)

Identification:

This option is only available if you have selected the option User Exit for Field Assignment.It makes it possible to uniquely identify the user exit.

Converting the Profitability Segments:

This section describes the logic applied for transferring a profitability segment created in an old operating concern into a profitability segment in the new active operating concern.

Note that a MOVE-CORRESPONDINGbetween fields of the same name in the old and the new active operating concern is always performed first in this program.

You have the additional option of applying a logic stored in a user exit to transfer CO-PA characteristics from the old operating concern into the new active operating concern. Provided the exit is activated, it is accessed for each profitability segment after the MOVE-CORRESPONDING step. Fields in the new active operating concern that have already been filled using the MOVE-CORRESPONDING logic can be changed subsequently in the exit.

To activate the exit, an entry has to be added to the TKEEXITS table. You can use transaction SE16 to maintain the table in the following way:

EXITID 'KE_CHACO_CE4'
  APPL 'KE'
  SEQNO '001'
  ISACTIVE 'X'
  REPORT Program name of a ZZ... program
  FORM Name of a form routine in program REPORT

For the exit to be accessed at all, the User Exit for Field Assignment indicator has to be set. A three-character abbreviation then needs to be entered in the Identification field adjacent to this indicator.

The exit logic is implemented in the form routine FORM of the program REPORT. The form routine has the following six transfer parameters (in this order):

  • Old operating concern
  • New active operating concern
  • ID for the exit: The exit ID entered in the selection screen is transferred.
  • Indicator specifying whether the exit is active and whether it is to be called up in subsequent program runs: You need to set this indicator in the coding so that the exit is called for the subsequent profitability segments.
  • Characteristics vector for the old operating concern: The characteristics vector is transferred in the structure CE4XXXX, where XXXX designates the old operating concern.
  • Characteristics vector for the new active profitability segment after the MOVE-CORRESPONDING step:
    The characteristics vector is transferred in the structure CE4YYYY, where YYYY designates the new active operating concern.

Example

If

  • 'S001' stands for the old operating concern
  • 'IDEA' for the new active operating concern
  • 'ABC' for the ID of the User Exit

and the characteristic Customer (KNDNR) is always to be set to 0000001001 in the new active operating concern if it had the value 0000001000 in the old operating concern, the exit implementation could appear as shown below:

Entry in Table TKEEXITS:

EXITID 'KE_CHACO_CE4'
  APPL 'KE'
  SEQNO '001'
  ISACTIVE 'X'
  REPORT ZZKE_CHACO_CE4
  FORM MODIFY_CHARACTERISTICS

Implementation of the exit in program ZZKE_CHACO_CE4:

REPORT ZZKE_CHACO_CE4.

....
FORM MODIFY_CHARACTERISTICS
  CHANGING I_ERKRS_OLD   LIKE TKEBB-ERKRS
           I_ERKRS_NEW   LIKE TKEBB-ERKRS
           I_EXITID      TYPE KEDRSTEPID
           I_EXIT_ACTIVE TYPE C
           IS_CE4_OLD    TYPE ANY
          IS_CE4_NEW    TYPE ANY
           I_CE4FLAG     TYPE C
           IS_CE4FLAG_O  TYPE ANY
           IS_CE4FLAG_N  TYPE ANY.

  DATA: LS_CE4S001 LIKE CE4S001,
        LS_CE4IDEA LIKE CE4IDEA.

  CASE I_EXITID.
    WHEN 'ABC'.
      IF I_ERKRS_OLD = 'S001' AND I_ERKRS_NEW = 'IDEA'.
        I_EXIT_ACTIVE = 'X'.,,,,"Activate for further processing
        LS_CE4S001 = IS_CE4_OLD.
        LS_CE4IDEA = IS_CE4_NEW.
        IF LS_CE4S001-KNDNR = '0000001000'.
          LS_CE4IDEA-KNDNR = '0000001001'.
        ENDIF.
        IS_CE4_NEW = LS_CE4IDEA.,,,,"Return characteristics of the</>
,,,,,,,,,,,,,,"new active operating concern
      ENDIF.
  ENDCASE.

ENDFORM.
  ENDCASE.

ENDFORM.
....

If the Call up Derivation in New Active Operating Concernindicator was selected, characteristic derivationis run in the new active operating concern after the exit has been run for the determined characteristics vector.

If an error occurs during characteristic derivation, this is written to the log. During an update run, the non-derived characteristics vector can be used to determine a profitability segment number in the new active operating concern. If necessary, the profitability segments for which an error occurred could be adjusted by realignments in the new active operating concern.

To run a validity check on the characteristic values, the Check Characteristics in the New Active Operating Concernindicator can be set. The validity check is made after calling up the exit and before characteristic derivation. It only makes sense to run a validity check on the characteristic values if the user exit is applied. If characteristic values are changed in the derivation, it checks their existence automatically.

As is the case during derivation, an error message is written in the log. The program continues processing in spite of any error messages.

If you use a user exit for programs RKE_CHACO_PAOBJNR_1 and RKE_CHACO_PAOBJNR_2, it is good practice to use the same exit in order to ensure a uniform conversion of the characteristic values.

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 operating concerns, 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 old operating concerns and new active operating concern, fiscal year, 'Z*'-tables name and also the corresponding additional options, for the seven steps A to G 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 additional key 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 is copied that coded one of the old operating concerns in one of the fields detailed in step A. Each record is given a unique index in the 'Z*' table field 'INDEXOBJNR'.

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 in 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 one of the old operating concernsand 'YYYYYYYYYY' a profitability segment number, it reads the values of the characteristic for profitability segment number 'YYYYYYYYYY' in operating concern 'XXXX'. The program replaces the old operating concern 'XXXX' with the new active operating concern 'ZZZZ'. The profitability segment 'YYYYYYYYYY' is, in accordance with the logic described in the section Converting the Profitability Segmentsabove, converted into profitability segment 'WWWWWWWWWW' of the new active operating concern. After this is stores the new field content 'EOZZZZWWWWWWWWWW'in the field 'NEW_FIELDNAME'of the appropriate'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: Aggregate Data:

In this step the program reads the data converted in step C from the 'Z*' tables, and writes the converted field contents from the fields 'NEW_FIELDNAME' to the original fields 'FIELDNAME'. In addition to this, it sets the indicator 'UPDATED'. At this point, however, the data from the copies of the CO line items tables COEP and COEJ is treated differently from the data of totals tables COSP and COSS:

  • Data for the 'Z*' tables for the CO line item tables COEP and COEJ:
    This kind of changed data is inserted in the corresponding Z*' table. Each record is given a unique index in the 'Z*' table field 'INDEXOBJNR'.
  • Data of the 'Z*' tables for the CO totals tables COSP and COSS :
    This data has to be summarized again. The reason for this is that some of the converted fields are found in the key of these tables. Therefore it is possible that totals records, that prior to the conversion had different CO objects in these fields, have the same CO objects in the new active operating concern following the conversion, and as a result have the same keys. Consequently, they must be summarized to a new record. This can only occur with CO objects for the same operating concern, however, as otherwise the encoding of company code and controlling area in the profitability segment number would lead to the use of different profitability segment numbers in the new active operating concern for the conversion.

    Example

    Table COSP has field 'OBJNR' in the key. Let 'A001' be the old and 'A002' the new active operating concern. Two totals records are under consideration, that both have the same key up to field 'OBJNR', for example,

    MANDT LEDNR OBJNR GJAHR .... PERBL ....
    001 00 EOA0010000000005 2003 .... 001 ....
    001 00 EOA0010000000009 2003 .... 001 ....

    If profitability segments '0000000005' and '0000000009' happen to have similar characteristic values, so that during the conversion profitability segment number '0000000012' is used for both profitability segments in the new active operating concern, this leads to the following result

    MANDT LEDNR OBJNR GJAHR .... PERBL ....
    001 00 EOA0020000000012 2003 .... 001 ....
    001 00 EOA0020000000012 2003 .... 001 ....

    Both of these records would therefore have to be summarized in a new record.
    The newly summarized data is then inserted in the corresponding 'Z*' table. Each record is given a unique index in the 'Z*' table field 'INDEXOBJNR'.

Apart from the field contents of fields 'UPDATED', 'INDEXOBJNR' and 'NEW_FIELDNAME', this data corresponds to the data as it is written back in the following step E to the CO tables COEP, COEJ, COSP and COSS.

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 summarizing across all data must be done in one step, that is, the data must be processed in one package. However, the program notes when the data for a table has already been summarized completely. This table is not processed again.

Step E: 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 first reads all the data copied in step B from the 'Z*' tables, and deletes the corresponding records from CO tables COEP, COEJ, COSP and COSS. This involves all datasets with the initial field 'UPDATED'.

After this, the converted and newly summarized data is read, that is the datasets for which the indicator 'UPDATED' has been set, and these datasets are written back to the relevant CO tables.

As the program notes the highest deleted or inserted 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 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 G: 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 lightnext to the steps. These display the status for the relevant step and a special combination of old operating concerns 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 Operating Concerns, Further Selections, Control Parameters, Processing Stepsand Tables. Confirm the confirmation prompt that appears with Yes.






ROGBILLS - Synchronize billing plans   TXBHW - Original Tax Base Amount in Local Currency  
This documentation is copyright by SAP AG.

Length: 37399 Date: 20240520 Time: 044407     sap01-206 ( 591 ms )