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

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 where several controlling areas that areassigned to one operating concern are to be distributed to severaloperating concerns.

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.
Program RKE_CHACO_PAOBJNR_3 can be used to overcome this problem. Thisprogram copies the profitability segments relating to a controlling areafrom the old into the new operating concern, and consequently makes themavailable there.
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 a controlling area is reassigned, this causes an incorrect operatingconcern to appear in the fields for the CO objects in the Controllingdocuments that have an account assignment to a profitability segment ofthe old operating concern that relates to this controlling area.
    To solve this problem, you can use program RKE_CHACO_PAOBJNR_4 afterhaving previously run program RKE_CHACO_PAOBJNR_3.
    With program RKE_CHACO_PAOBJNR_3, the profitability segments thatrelate to a controlling area are first copied from the old operatingconcern to the new operating concern, and consequently made availablethere. Program RKE_CHACO_PAOBJNR_4 then copies those Controllingdocuments that have an account assignment to a profitability segment forthe old operating concern out of the CO tables listed into temporarytables. There, in the CO objects whose profitability segment relates tothe reassigned controlling area, it replaces the old operating concernwith the new operating concern, and following successful conversionwrites the documents back to the CO tables.
    This program cannot, however, be used to convert costing-basedtransaction data. If you need to do this, use program COPA_COPY.

    Prerequisites
    You must have activated account-based Profitability Analysis in both theold and new operating concern to execute the program.
    The following scenario for changing the assignment between controllingareas and operating concerns is supported: several controlling areasthat are assigned to one operating concern are to be assigned to severalnew operating concerns.
    The following example demonstrates this for the controlling areas1000 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 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, these cop
    ies 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 operatingconcern 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 the old operatingconcern is replaced with the new one. However, the converted CO objectsare initially copied to the additional fields created for the COobjects.
    The data from the 'Z*'-tables can then be written back to the CO tablesCOEP, COEJ, COSP and COSS. In the course of this process, the fields forthe CO objects are filled with the converted data from the additionalfields.
    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 to be converted for the oldoperating concern for each fiscal year, 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 Concern'. Becausedetermination of the data volume can take a while, it must be started inthe 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 savedin 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 bereassigned.

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

    Step 3
    Start program RKE_CHACO_PAOBJNR_4 for each controlling area to bereassigned and each fiscal year with the appropriate old operatingconcern and new active operating concern.
    The following areas of the selection screen need to be filled in thisprocess:

    Organizational units
    Old Operating Concern / New Active Operating Concern:
    Enter the controlling area to be reassigned, the old operating concernand 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 combination2000 (Controlling Area) C001 (Old Operating Concern) and D001 (NewActive 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 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.

    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 ofcontrolling area, 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 controllingarea, old operating concern and new active operating concern, fiscalyear, '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 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 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, COSPand COSS into the corresponding 'Z*' tables in packages of 100,000records.
    All data for the selected fiscal year are copied that coded the oldoperating concern in one of the fields detailed in step A. Each recordis given a unique index in the 'Z*' table field 'INDEXOBJNR'. Noselection according to controlling area is made at this point, as thisis not available as a field in all CO tables.
    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 to 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 the oldoperating concern and 'YYYYYYYYYY' a profitability segment number
    , it reads the values of the characteristic for profitability segmentnumber 'YYYYYYYYYY' in operating concern 'XXXX', the controlling area inparticular. If this matches the controlling area entered in theselection screen of the program, the program replaces the old operatingconcern 'XXXX' with the new active operating concern 'ZZZZ', andwrites 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 theevent of a program termination due, for example, to database problemsyou 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 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 initially reads all data from the 'Z*' tables.
    As the converted CO objects stand in a field 'FIELDNAME' in theadditional field 'NEW_FIELDNAME' appended to the relevant 'Z*' table,the 'Z*' table data still corresponds to the data in the appropriate COtables, with the exception of the 'NEW_*' fields. The program deletesthis data from the CO tables.
    Following this, the field contents of the field 'FIELDNAME' are replacedby those of the fields 'NEW_FIELDNAME', provided a converted CO objectis in the field 'NEW_FIELDNAME'. This converted data is written back tothe relevant CO tables.
    As the program notes the highest converted 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 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 notremoved 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 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 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 ofcontrolling area, old operating concern and new active operatingconcern, fiscal year, and table names of the 'Z*' tables. If the trafficlight 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 Organizational Units, Further Selections,Control Parameters, Processing Steps and Tables.Confirm the confirmation prompt that appears with Yes.