WARNING: This program should only be used in consultation with the SAPdevelopment team for CO-PA. You need to ensure that a data backup hasbeen generated for the entire system before the program is used in aproduction system.

Purpose
The program can be used in cases where the assignment betweencontrolling areas and operating concerns needs to be changed to reflectchanges made to the organizational structure of a company.
In particular, it can be used for instances where one or more operatingconcerns are to be replaced by just one new operating concern.

Integration
Within the value flow logic in the ERP system, the profitability segmentnumber for document line items posted in Profitability Analysis (CO-PA)is updated in the document tables of the components SD, FI, MM, and COin the PAOBJNR field.
The operating concern in which this profitability segment number isvalid is determined indirectly from the organizational units stored inthe document tables and also from the company structure stored inCustomizing.
If the assignment between controlling areas and operating concerns issubsequently changed in a system, this means that the system can nolonger correctly interpret any profitability segments stored in thedocument tables prior to this realignment.
Due to the changed assignment for the controlling areas, the system thenerroneously searches for an affected profitability segment in the newoperating concern, whereas the profitability segment was originallycreated in the old operating concern and can only be interpreted in thatoperating concern.
A distinction can be made between two types of cases in which the systemtries to interpret a given profitability segment number with referenceto an incorrect operating concern. If the profitability segment numberdoes not exist in the new operating concern, then a short dump isregularly returned with the message number KE499. If, on the other hand,a profitability segment with the same number should happen to exist inthe new operating concern, the system then works with the characteristicvalues for that particular profitability segment. This leads either tofollow-up errors during further processing of the document, or, in theworst case, to incorrect data being updated in CO-PA.
This problem can be solved by using program RKE_CHACO_PAOBJNR_1. In thedocument tables of the SD, FI, MM or CO components, the programsystematically replaces the profitability segments of the old operatingconcern with profitability segments of the new operating concern.
A similar problem occurs with activated account-based ProfitabilityAnalysis for the Controlling documents that are stored in the followingCO tables and that have an account assignment to a profitabilitysegment.

• 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 accountassignment relevant to cost accounting. Account assignments toprofitability segments have the form 'EOXXXXYYYYYYYYYY', where 'XXXX'stands for the operating concern and 'YYYYYYYYYY' stands for aprofitability segment number.
If an operating concern is replaced, this causes an incorrect operatingconcern as well as a profitability segment number from this operatingconcern to appear in any Controlling documents that have an accountassignment to a profitability segment of this operating concern.
To solve this problem, you can use program RKE_CHACO_PAOBJNR_2 afterhaving previously run program RKE_CHACO_PAOBJNR_1.
With program RKE_CHACO_PAOBJNR_1, the profitability segments fromthe old operating concern in the document tables for the components SD,FI, MM, and CO are first systematically replaced with profitabilitysegments from the new operating concern. Program RKE_CHACO_PAOBJNR_2then copies the those Controlling documents that have an accountassignment to a profitability segment for the old operating concern outof the CO tables listed into temporary tables, where it replaces the oldoperating concern with the new operating concern. The relatedprofitability segment numbers of the old operating concern are replacedby those of the new operating concern. The program summarizes the totalsrecords again, and writes the data back to the CO tables. In doing so,both programs are able to convert the data of several old operatingconcerns that is to be assigned to the same new operating concern in asingle run.
Program RKE_CHACO_PAOBJNR_2 cannot, however, be used to convertcosting-based transaction data. If you need to do this, use programCOPA_COPY.

Prerequisites
You must have activated account-based Profitability Analysis in both theold operating concern and new operating concern to execute the program.
The following scenarios are supported for changing the assignmentbetween controlling areas and operating concerns:
An operating concern needs to be replaced by another one. Allcontrolling areas assigned to the old operating concern are assigned toa new operating concern.
Multiple controlling areas assigned to multiple operating concerns needto be assigned to a new operating concern.
The following examples demonstrate this for the controlling areas1000 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 operatingconcern must always be reassigned, and that all are to be assigned tothe same new operating concern.

Features
You need to execute the program for each of the operating concerns to bereassigned for each fiscal year.
As a first step, the program can be used to create copies of CO tablesCOEP, COEJ, COSP and COSS in the customer name space 'Z*' for eachfiscal year. For every field that could contain a CO object, thesecopies contain an additional field in which the converted CO objects canlater be written for the time being.
The Controlling documents that relate to a fiscal year and have anaccount assignment to a profitability segment of the old operatingconcerns are copied to these 'Z*'-tables
In the third step the data is converted, meaning that in the CO objectswith account assignment to a profitability segment of the old operatingconcerns the old operating concern is replaced with the new one. Inaddition, the profitability segment numbers of the old operatingconcerns are replaced by those of the new operating concern. However,the converted CO objects are initially copied to the additional fieldscreated for the CO objects.
The next step reads the converted data from the 'Z*' tables, fills theoriginal fields of the CO objects (if necessary) with the converted COobjects, and writes this dataset back to the 'Z*' tables. In addition,the dataset copied from the totals tables COSP and COSS are summarizedagain, as it is possible that totals records with different keys receivean identical key as a result of the conversion.
The data from the 'Z*'-tables can then be written back to the CO tablesCOEP, COEJ, COSP and COSS. The records that were copied originally arethen deleted from the CO tables.
Finally, the data from the copied 'Z*'-tables can be deleted, and theirtable definition removed from the ABAP Dictionary.

Activities
Before executing the program, you can first determine the data volumefor tables COEP, COEJ, COSP and COSS for each fiscal year for the oldoperating concerns to be converted, so as to give you an idea of theamount 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 askingwhether you want to continue by selecting "Yes". Enter the desiredcombination 'Fiscal Year' / 'Old Operating Concerns'. Becausedetermination of the data volume can take a while, it must be started inthe background. The program creates the job ZZRKE_CHACO_CHECK_SIZE_2and you can specify a start time in the screen that then appears. Thejob is automatically scheduled and released. The results are saved inthe 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 oldoperating concerns and new operating concern.

Step 2
Ensure that no documents are posted to the system while programRKE_CHACO_PAOBJNR_2 is being executed.

Step 3
Start program RKE_CHACO_PAOBJNR_2 for the combination of oldoperating concerns and new operating concern for each fiscal year.
The following areas of the selection screen are to be filled in thisprocess:

Operating Concerns
Old Operating Concerns / New Active Operating Concern:
Enter the old operating concerns to be replaced and the new activeoperating 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 combinationC001 / D001 (Old Operating Concerns) and E001 (New Active OperatingConcern).

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 stepselected in the Processing Steps area. Processing can be executedin the foreground or in the background. The program generates a log andissues 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 ofthe step for which the test run was started and whether it ran withouterrors.
Update Run:
With this option, the program is executed in an update run for the stepselected in the Processing Steps area. Processing should bestarted 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 hasalready been performed previously with no errors for the selected step.

Here also, the program makes a note of the step for which the update runwas 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 oldand the new active operating concern against postings. Users trying topost data to these operating concerns receive an appropriate errormessage.
Call up Derivation in New Active Operating Concern:
This option makes it possible to derive the converted characteristicsvector in the new active operating concern again (see Converting theProfitability Segments below).
Check Characteristics in the New Active Operating Concern:
This option makes it possible to carry out a validity check of thecharacteristic value for the converted characteristics vector in the newactive operating concern (see Converting the Profitability Segments
below).
User Exit for Field Assignment:
This option makes it possible to create the characteristic assignmentbetween old operating concerns and a new active operating concernindividually using a user exit (see Converting the ProfitabilitySegments below)
Identification:
This option is only available if you have selected the option UserExit for Field Assignment. It makes it possible to uniquelyidentify the user exit.
Converting the Profitability Segments:
This section describes the logic applied for transferring aprofitability segment created in an old operating concern into aprofitability segment in the new active operating concern.
Note that a MOVE-CORRESPONDING between fields of the same name inthe old and the new active operating concern is always performed firstin this program.
You have the additional option of applying a logic stored in a user exitto transfer CO-PA characteristics from the old operating concern intothe new active operating concern. Provided the exit is activated, it isaccessed for each profitability segment after the MOVE-CORRESPONDINGstep. Fields in the new active operating concern that have already beenfilled using the MOVE-CORRESPONDING logic can be changed subsequently inthe 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 Assignmentindicator has to be set. A three-character abbreviation then needs to beentered in the Identification field adjacent to this indicator.
The exit logic is implemented in the form routine FORM of the programREPORT. The form routine has the following six transfer parameters (inthis 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 inthe coding so that the exit is called for the subsequent profitabilitysegments.

• Characteristics vector for the old operating concern: The
characteristics vector is transferred in the structure CE4XXXX, whereXXXX 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 to0000001001 in the new active operating concern if it had the value0000001000 in the old operating concern, the exit implementation couldappear 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 derivation is run inthe new active operating concern after the exit has been run for thedetermined characteristics vector.
If an error occurs during characteristic derivation, this is written tothe log. During an update run, the non-derived characteristicsvector can be used to determine a profitability segment number in thenew active operating concern. If necessary, the profitability segmentsfor which an error occurred could be adjusted by realignments in the newactive operating concern.
To run a validity check on the characteristic values, the CheckCharacteristics in the New Active Operating Concern indicator can beset. The validity check is made after calling up the exit and beforecharacteristic derivation. It only makes sense to run a validity checkon the characteristic values if the user exit is applied. If characteris
tic values are changed in the derivation, it checks their existenceautomatically.
As is the case during derivation, an error message is written in thelog. The program continues processing in spite of any error messages.
If you use a user exit for programs RKE_CHACO_PAOBJNR_1 andRKE_CHACO_PAOBJNR_2, it is good practice to use the same exit in orderto 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 / Copyof table COSS:
Enter here the table names selected for the required combination ofoperating concerns, old and new active operating concern and fiscal yearin the customer name space 'Z*' . The program proposes thefollowing:
,,COEP,,-->,,ZZTKECOEP,,(Actual Line Items)
,,COEJ,,-->,,ZZTKECOEJ,,(Plan Line Items)
,,COSP,,-->,,ZZTKECOSP,,(Totals Records: Primary CostElements)
,,COSS,,-->,,ZZTKECOSS,,(Totals Records: Secondary CostElements)
You can change these table names so that they contain, for example, thefiscal year if you need to convert several fiscal years.
Development Class:
Enter the development class here in which you want to create the copiesof tables COEP, COEJ, COSP and COSS. The program automatically proposesthe local development class '$TMP'. However, you can also use adevelopment class in the customer name space 'Z*' . This makesgood sense particularly if you create the table definition for thecopies of tables COEP, COEJ, COSP and COSS in a source system, and wantto transport it later into another system.

Processing steps
Execute the program for the selected combination of old operatingconcerns and new active operating concern, fiscal year, 'Z*'-tables nameand also the corresponding additional options, for the seven steps A toG as set out below.
As the steps are dependent on each other, when you execute theprogram it checks each time whether the previous step has already beensuccessfully carried out in an update run, and if not issues thecorresponding error message.
Step A: Copy Table Definition:
In this step, the program creates copies of tables COEP, COEJ, COSP andCOSS under the name entered in the customer name space 'Z*' inthe area Tables.
For each table field 'FIELDNAME' that could possibly contain a COobject with account assignment to a profitability segment, a new fieldwith the name 'NEW_FIELDNAME' is appended to the relevant 'Z*'table in which the converted CO objects were written in the ConvertData step.
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 additionalkey field 'UPDATED' is inserted, being used for internalprocessing.
Step B: Copy Data:
In this step the program copies the data from CO tables COEP, COEJ, COSPand COSS into the corresponding 'Z*' tables in packages of 100,000records.
All data for the selected fiscal year is copied that coded one of theold operating concerns in one of the fields detailed in step A. Eachrecord is given a unique index in the 'Z*' table field 'INDEXOBJNR'.
Although you can restart the program at this step if, for example, itterminates 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, butstarts back at the beginning of the step. The reason for this is thatthe database does not always return the data in the same order as it wasselected, so the program is unable to recognize which data has alreadybeen posted in the 'Z*' tables and which has not. Nevertheless, theprogram does recognize when one of CO tables COEP, COEJ, COSP and COSShas already been copied in its entirety. This is not copiedagain.
Step C: Convert Data:
In this step, the program checks the fields of the 'Z*' tables detailedin step A in packages of 100,000 records in ascending order according totheir index in the INDEXOBJNR field.
If, in field 'FIELDNAME', it finds a CO object in the form'EOXXXXYYYYYYYYYY', where 'XXXX' designates one of the oldoperating concerns and 'YYYYYYYYYY' a profitability segmentnumber, it reads the values of the characteristic for profitabilitysegment number 'YYYYYYYYYY' in operating concern 'XXXX'. The programreplaces the old operating concern 'XXXX' with the new activeoperating concern 'ZZZZ'. The profitability segment 'YYYYYYYYYY'
is, in accordance with the logic described in the sectionConverting the Profitability Segments above, converted intoprofitability segment 'WWWWWWWWWW' of the new active operatingconcern. After this is stores the new field content'EOZZZZWWWWWWWWWW' in the field 'NEW_FIELDNAME' of theappropriate '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 aprogram termination due, for example, to database problems you cansimply 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'. Inaddition to this, it sets the indicator 'UPDATED'. At this point,however, the data from the copies of the CO line items tables COEP andCOEJ is treated differently from the data of totals tables COSP andCOSS:


• 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 someof the converted fields are found in the key of these tables. Thereforeit is possible that totals records, that prior to the conversion haddifferent CO objects in these fields, have the same CO objects in thenew active operating concern following the conversion, and as a resulthave the same keys. Consequently, they must be summarized to a newrecord. This can only occur with CO objects for the same operatingconcern, however, as otherwise the encoding of company code andcontrolling area in the profitability segment number would lead to the u
se of different profitability segment numbers in the new activeoperating 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 underconsideration, that both have the same key up to field 'OBJNR', forexample,
MANDT LEDNR OBJNR GJAHR .... PERBL ....
001 00 EOA0010000000005 2003 .... 001 ....
001 00 EOA0010000000009 2003 .... 001 ....
If profitability segments '0000000005' and '0000000009' happen to havesimilar characteristic values, so that during the conversionprofitability segment number '0000000012' is used for both profitabilitysegments in the new active operating concern, this leads to thefollowing 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 newrecord.
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 backin 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, itterminates 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, butstarts back at the beginning of the step. The reason for this is thatsummarizing across all data must be done in one step, that is,the data must be processed in one package. However, the program noteswhen the data for a table has already been summarized completely. Thistable 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 inascending order according to their index in the INDEXOBJNR field, so inthe above example
,,ZZTKECOEP,,-->,,COEP,,(Actual Line Items)
,,ZZTKECOEJ,,-->,,COEJ,,(Plan Line Items)
,,ZZTKECOSP,,-->,,COSP,,(Totals Records: Primary CostElements)
,,ZZTKECOSS,,-->,,COSS,,(Totals Records: Secondary CostElements)
The program first reads all the data copied in step B from the'Z*' tables, and deletes the corresponding records from CO tablesCOEP, COEJ, COSP and COSS. This involves all datasets with theinitial field 'UPDATED'.
After this, the converted and newly summarized data is read, that isthe datasets for which the indicator 'UPDATED' has been set, and thesedatasets 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 theevent of a program termination due, for example, to database problemsyou 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 isnot 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 aprogram termination due, for example, to database problems you cansimply 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 thebackground, an error message is generated if a table still containsdata. If you start the program online, you receive a dialog boxrequesting you if the table should still be deleted.
You can only ever execute the individual steps in an update runproviding a test run has already been successfully carried out.
The status for each of the steps is displayed on the programselection screen as a traffic light next to the steps. Thesedisplay the status for the relevant step and a special combination ofold 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 recordsto be deleted as in the program selection screen corresponding to theareas Operating Concerns, Further Selections, ControlParameters, Processing Steps and Tables. Confirm theconfirmation prompt that appears with Yes.