Database Tables for CO-PA Transaction Data

The concepts line item and profitability segment are essential for understanding how data is stored in CO-PA. A line item can be compared, for example, to an item in a billing document from the SD component. The combination of characteristic values stored in a line item is what defines the particular profitability segment to which the line item must be posted.

To improve system performance, you can also restrict the characteristics that make up the profitability segment. For more information, see the Customizing section Define Profitability Segment Characteristics (Segment-Lvl Characteristics). Furthermore, a time-based dimension (the posting period) has to be represented. The CO-PA data basis, which the system creates when an operating concern is generated, reflects how the information is organized logically.

There is the table CE1xxxx for actual line items (where xxxx = operating concern), which contains all the data at the most detailed level. Planned line items are stored in the table CE2xxxx. There is also the segment table CE4xxxx, which is located at a higher level. It is used to assign segment numbers to each combination of characteristic values. For the first summarization to be performed, at least the document number and the billing item are hidden. The characteristics that were deactivated from use in the profitability segment in Customizing are also hidden. Segment table CE4xxxx should therefore be optimized for processing data within Profitability Analysis, such as for the information system. Table CE4xxxx_ACCT contains external account assignment information as well as the characteristics for CE4xxxx and serves as the "interface" to other applications. The segment level CE3xxxx is set up between the segment table and the line items, thereby making a time-based classification possible. Alongside value fields, the segment level also contains the characteristics record type, planned/actual indicator, version, and period, as well as some additional technical details. Several lines from the segment level are attached to a particular profitability segment (that is, to a line in the segment table). These lines all have the same segment number but relate to different posting periods. Each line at the segment level adds together the value fields for a row of line items bearing the same segment number and assigned to the appropriate posting period. The following graphic provides an overview of the tables:

Example
You have invoiced three documents for customer 0815. The first posting occurs in March (posting period 003), and revenues of 100 DEM and 200 DEM are posted respectively for the products ART1 and ART2. The second posting occurs in April. Revenues of 400 DEM and 800 DEM are posted respectively for the products ART1 and ART3. The third posting also

occurs in April. Revenues of 1600 DEM and 3200 DEM are posted respectively for the products ART1 and ART3. When the line items are posted, the segment table and segment level are updated, producing the following table contents: Segment Table (CE4xxxx)Segment number chars 0047 0815ART1... 0048 CustomerProductAdditional 0815ART3... Segment RevenueAdditional value 20

0815ART2... 0049

Level (CE3xxxx)Segment numberPeriod fields0047003.2000 100.00...0047004.2000

2 000.00...0048003.2000

0.00...0049004.2000 4 000.00...Line Item Table CE1xxxx (Planned Data in CE2xxxx)Segment numberPeriodDocumentItemCustomerProductAdditional charsRevenueAdditional value fields0047003.200000000700010815ART1...100.00...0048003.200000000700020815 ART2...200.00...0047004.200000000800010815ART1...400.00...0049004.2000000008 00020815ART3...800.00...0047004.200000000900010815ART1...1 600.00...0049004. 200000000900020815ART3...3 200.00...

Define Profitability Segment Characteristics (Segment-Lvl Characteristics)

In this step, you specify whether a characteristic in CO-PA is used to create profitability segments. Characteristics that are used to create profitability segments are available for the information system and in planning, for example. Characteristics that are not involved in the creation of profitability segments remain in their line item in CO-PA. Frequently occurring characteristics that rarely bear the same value (such as the sales order number for a repetitive manufacturer) can thus be excluded from the creation of your profitability segment. In this way, you can improve the performance of your profitability analysis considerably. Furthermore, you can perform profitability analysis at the customer group level or at the product group level by ceasing to use customers or products in that analysis. Note Before you execute the first transfer of productive data to Profitability Analysis, you should make the appropriate setting specifying which characteristics should be involved in creating profitability segments. The only type of change that you can make subsequently is the deactivation of more characteristics for the determination of a profitability segment. If you later include a characteristic in the determination process, your CO-PA data will then be incomplete for all affected characteristics. Instead of excluding characteristics generally, you have the option of excluding a characteristic under certain conditions and thus define exceptions for how characteristics are used. In this way, make-to-order manufacturers with a spare parts business, for example, can exclude the spare parts business from their analyses, or wholesale manufacturers with a large number of customers can restrict their analysis at the customer level to key customers. The purpose of this function is to reduce the amount of created profitability segments by updating in detail only those values that are relevant for a particular analysis.

Note This function is a purely technical function with which to reduce the number of profitability segments. It is intended for allow users with large data volumes to optimize their system performance. It should be used with caution because it is usually not possible to reverse its effects: these can be undesirable if the function is applied incorrectly. If you want to use the function, you should first read the section Exceptions concerning segment-level characteristics, which contains a detailed description of the function, with examples.

Standard Settings
Along with "sales order", the origin terms "order", "WBS element" and "cost object" should not be used as characteristics in the formation of profitability segments. Thus, when you create a new operating concern, the relevant table is automatically set so that the following characteristics are not used to form the profitability segments: - sales order (KAUFN) - sales order item (KDPOS) - order (RKAUFNR) - WBS element (PSPNR) - cost object (KSTRG)

All other characteristics - including "Customer" and "Product" - are used and therefore are available for profitability reports, planning, and account assignments to profitability segments, for example. No exceptions are defined by default. If you need to make a different setting to these, change the entries accordingly. In this case, you should check the index to the object table, expecially if you exclude the characteristics "Customer" or "Product". By defining an index that is most optimally reconciled to how the segment-level characteristics are to be used, you can improve performance considerably. For more detailed information about indexes, see the application documentation for Profitability Analysis and choose Technical Aspects of Profitability Analysis -> Index Support for Determination of Segment Numbers.

Recommendation
To avoid performance problems, we recommend the exclusion of characteristics that occur frequently, have a different value with each posting (such as "Automobile chassis number") and are thus not relevant for analysis.

Activities
Specify which characteristics of your operating concern should be used to form profitability segments. You do this by choosing the option "costing-based" or "costing-/acct-based". If a characteristic should not be used, select "not used".

Physical Structure of the Data in CO-PA

The following sections describe the detailed physical structure of the data (physical insertion sequence) and the typical accesses of the dataset.

In the section Physical Distribution of the Data in CO-PA, we will propose a way to distribute the data effectively over larger areas (table spaces, hard drives, striping, and so on).

Documents
Actual line items are stored in table CE1xxxx (where xxxx = operating concern). The system inserts into this table on an ongoing basis (sorted according to time stamp of the insertion point). In drilldown reporting, cost center assessment, etc., the system accesses the data by this time stamp. Thus the physical insertion sequence corresponds to the typical read access method. Plan line items are stored similarly in table CE2xxxx and are accessed in the same way. Consequently, this table will not be referred to separately in the following.

Segment Level
The segment level -- CE3xxxx -- contains the data in its first summarized form. The profitability segment number and the period are key fields (along with additional technical fields: plan version, record type, plan/actual indicator, etc.). The data part consists of the value fields. The data in the segment level is typically sorted by period when it is created (INSERT) and updated during the period. That is, the insertion sequence depends on the random order in which the business transactions occurred and is only sorted roughly according to period (or period block PERBL). The typical queries search in the segment level with a few (approximately 100) fixed segment numbers (WHERE PAOBJNR IN <List> ...) and a condition of time (... AND PERBL IN ...). Thus the physical insertion sequence does not correspond to the typical read access sequence! The segment level is always accessed via the primary index CE3xxxx__0.

Segment Table
The segment table CE4xxxx contains a unique profitability segment number (the primary key) for each combination of characteristic values (data part) to which data has been posted. The records are inserted in the order of the profitability segment numbers (albeit only approximately, due to buffering of the segment number assignment on the application servers) and are practically never changed. Selections from the segment table can generally be divided into two groups: 1. Selections of large data volumes for drilldown reporting, planning or cost center assessment Here the system finds all the profitability segment numbers whose combination of characteristic values meets a specified condition (e.g. in a drilldown report). If a suitable index exists, the system uses it to access table CE4xxxx. In that case the access does not correspond to the physical insertion sequence. If no suitable index exists, the system selects using the primary index. To read about how you can improve performance for this type of access, see Physical Distribution of the Data in CO-PA.

2. Determination of a profitability segment number based on the known combination of characteristics In this case the system finds the profitability segment number when the values of all characteristics are known. To read about how you can improve performance for this type of access, see Index Support for Determination of Segment Numbers.

COPA Extraction Steps

The below are the command steps and explanation. COPA Extraction -steps R/3 System 1. KEB0 2. Select Datasource 1_CO_PA_CCA 3. Select Field Name for Partitioning (Eg, Ccode) 4. Initialise 5. Select characteristics & Value Fields & Key Figures 6. Select Development Class/Local Object 7. Workbench Request 8. Edit your Data Source to Select/Hide Fields 9. Extract Checker at RSA3 & Extract BW 1. Replicate Data Source 2. Assign Info Source 3. Transfer all Data Source elements to Info Source 4. Activate Info Source 5. Create Cube on Infoprovider (Copy str from Infosource) 6. Go to Dimensions and create dimensions, Define & Assign 7. Check & Activate 8. Create Update Rules 9. Insert/Modify KF and write routines (const, formula, abap) 10. Activate 11. Create InfoPackage for Initialization 12. Maintain Infopackage 13. Under Update Tab Select Initialize delta on Infopackage 14. Schedule/Monitor 15. Create Another InfoPackage for Delta 16. Check on DELTA OptionPls r 17. Ready for Delta Load LIS, CO/PA, and FI/SL are Customer Generated Generic Extractors, and LO is BW Content Extractors. LIS is a cross application component LIS of SAP R/3 , which includes, Sales Information System, Purchasing Information System, Inventory Controlling.... Similarly CO/PA and FI/SL are used for specific Application Component of SAP R/3.

CO/PA collects all the OLTP data for calculating contribution margins (sales, cost of sales, overhead costs). FI/SL collects all the OLTP data for financial accounting, special ledger 1) Add the fields to the operating concern. So that the required field is visible in CE1XXXX table and other concerned tables CE2XXXX, CE3XXXX etc. 2) After you have enhanced the operating concern then you are ready to add it to the CO-PA data source. Since CO-PA is a regenerating application you can't add the field directly to the CO-PA data source. You need to delete the data source and then need to re-create using KEB2 transaction. 3) While re-creating the data source use the same old name so that there won't be any changes in the BW side when you need to assign the data source to info-source. Just replicate the new data source in BW side and map the new field in info-source. If you re-create using a different name then you will be needing extra build efforts to take the data into BW through IS all the way top to IC. I would personally suggest keep the same old data source name as before. If you are adding the fields from the same "Operating concern" then goto KE24 and edit the dataaource and add your fields. However if you are adding fields outside the "Operating concern" then you need to append the extract structure and populate the fields in user exit using ABAP code. Reference OSS note: 852443 1. Check RSA7 on your R3 to see if there is any delta queue for COPA. (just to see, sometimes there is nothing here for the datasource, sometimes there is) 2. On BW go to SE16 and open the table RSSDLINIT 3. Find the line(s) corresponding to the problem datasource. 4. You can check the load status in RSRQ using the RNR from the table 5. Delete the line(s) in question from RSSDLINIT table 6. Now you will be able to open the infopackage. So now you can ReInit. But before you try to ReInit .... 7. In the infopackage go to the 'Scheduler' menu > 'Initialization options for the source system' and delete the existing INIT (if one is listed)