The management of data is a key consideration in ensuring optimal performance of all applications and components in the SAP system landscape. As a result of the productive use of the SAP system, database size is bound to increase. If the growth of the database is not controlled, it can lead to performance degradation. Performance issues can be in the form of long runtimes during transaction processing or aborted ABAP program runs. This is not to say uncontrolled database growth is the only cause of performance issues in the SAP system landscape. Other factors that can lead to performance issues include poorly tuned ABAP programs, defective network infrastructure, and inadequate hardware capacity planning. However, this article focuses on using data volume management as a strategy for system performance optimization. It is pertinent to note that data volume management entails concepts such as data prevention, data deletion, and data archiving.

Technical users and consultants are often confronted with the challenge of optimal performance of mass data processing, which is usually inhibited by large database tables and fast database growth rate. Also, the reduction of the cost of system maintenance as it relates to increased disk requirement and database maintenance time due to increased database growth rate can be challenging for the IT team. FI/CO functional users and consultants can be of invaluable assistance to the IT team in their quest for ensuring optimal system performance via controlled database growth. This is because the IT team is often not knowledgeable in the different methods of data volume management (except for data archiving) due to data prevention and data deletion being implemented via optimal functional configuration settings and transactions. Suffice it to say that functional users can customize the SAP system appropriately to guarantee controlled database growth and reduced data volume.

I’ll show you some tips and tricks on how FI/CO functional users can use standard customization settings to manage the growth of database tables by adopting data prevention and data deletion strategies in the areas of integrated planning and cost object controlling. I’ll also discuss what functional users, technical users, and system administrators should know about the reduction of data volume through data archiving as it affects the aforementioned controlling processes. This article applies to an SAP ERP Central Component (SAP ECC) 6.0 system.

Integrated Planning

Planning enables organizations to set business goals that can be used to measure and compare actual operating results with the planned figures. It allows the structuring of a company’s future operations for a particular period. Through planning, enterprises can define metrics for monitoring a fiscal year’s business transactions. Planning is performed within a plan version that ensures that a specific version produces consistent results across different components, such as planning integration between cost center accounting and profit center accounting. A version is a unique view of planned costs and revenue based on a particular set of assumptions. The system automatically creates version 0 when you define a controlling area. You need to define default values for some fiscal year-dependent parameters (e.g., integrated planning, lock version, and value date) in a version. You can activate integrated planning in the following ways:

1. Use transaction OKEV and select the Integrated Planning and Integrated planning with cost centers/bus. processes check boxes (Figure 1).

Figure 1

Set indicators to activate integrated planning

2. Use transaction CJ01 or CJ02 and set integrated planning in the project definition by selecting the Integrated planning check box (Figure 2).

Figure 2

Activate integrated planning in project definition

3. Use transaction KO01 or KO02 to set integrated planning in the order type by selecting the Plan-integrated order check box (Figure 3).

Figure 3

Activate integrated planning for internal order

The integrated planning indicator in any of these methods is used to determine whether:

• To transfer plan data from the cost center accounting component or the activity-based costing component to other components such as profit center accounting and special purpose ledger
• To write line items for each change in the plan data

When the integrated planning indicator is activated, the system automatically creates plan line items in tables COEJ, COEJL, COEJT, and COEJR. To control the growth of these tables (especially table COEJ, which usually has the highest data volume), you can use any of the following strategies:

1. Deactivate integrated planning and line item update in versions where you do not need it. It is important to note that the deactivation of integrated planning is done at the beginning of a fiscal year to prevent data inconsistencies as a result of possible deviation between line items and total records. Furthermore, it is possible to activate integrated planning at any time within the fiscal year via transaction KP96 by clicking the Execute button (Figure 4).

Figure 4

Activate line items and integrated planning

When this is done, the system creates and transfers just one line item per total record in the same amount instead of creating and transferring every individual plan posting as line items. The drawback of this approach is that some faulty definitions in integrated planning (e.g., locked profit centers) are not observed until the end of the fiscal year. 

2. Delete plan line items that are no longer needed via transaction KP90 (Figure 5) or KP91 (Figure 6).

Figure 5

Delete integrated planning objects in transaction KP90

Figure 6

Delete integrated planning objects in transaction KP91

These transactions have some key similarities. The programs do not take all business transactions into consideration during deletion. Transaction KP90 only considers business transactions RKP1, RKP5, RKP6, RKP8, RKP9, and RKPZ. In addition to these, transaction KP91 considers business transactions RKP2, RKP3, RKP4, RKP7, RKPW, RKPX, CPPP, KSPB, RKPB, RKPL, RKPU, RKPV, KAZP, KOAM, KOAP, RKPS, KSPO, KSP1, KSP2, KSP3, and KZPP.

Also, transactions KP90 and KP91 only consider account data on cost accounting objects (e.g., internal orders, WBS elements, cost centers, business processes, reconciliation objects, profitability segments, and cost objects), which are integrated in the plan with cost center accounting.

Cost Object Controlling

Cost object controlling is an important component of cost accounting. It helps organizations to determine metrics that can be used to enhance decision making such as:

• The actual cost that was incurred in a unit during a particular period
• The expected cost based on the quantity of goods manufactured
• Whether some material groups are performing better than others
• The factor responsible for variances
• The scrap costs associated with a new production infrastructure

When executing period-end closing in cost object controlling, cost analysis performed is influenced by elements such as work in process (WIP), scrap, variance, target cost, and results analysis. WIP is either determined based on actual costs for full settlement or target cost for periodic settlement. Target costs of an order are determined by variance calculation which forms the basis for target/actual comparison. The scrap value calculated is based on target cost. Results analysis is performed for objects that cannot be delivered to the warehouse instead of WIP and variance. All these different calculations update cost object controlling tables — especially tables COSB, COSP, and COSS — in one way or the other. Table COSB is the repository for total variances and results analysis in cost accounting, table COSP acts a repository for cost total of cost accounting for internal posting, and table COSS is the repository for cost total for external posting. These tables can grow very large to the extent that they negatively affect the performance of the system, especially when it is unnecessarily updated. You can prevent the growth of these tables and enhance system performance by adhering to the following recommendations.

Controlled Use of Material Origin Indicator

You can activate the Material origin indicator via transaction MM02 under the costing view of the material master data (Figure 7). This indicator allows you to analyze material costs because the cost incurred is updated under a primary cost element based on the material number. Consequently, these updates affect the size of some CO database tables such as COSP and COSS. The activation of this indicator should be controlled to prevent unnecessary growth of these tables. Material origin indicators should only be activated for materials that really need the functionality.

Figure 7

Material origin indicator setting for a material

Deactivate the Write Line Items Indicator in the Variance Key

You can deactivate the Write Line Items indicator via transactions OKV0 (Figure 8) and OKV1 (Figure 9). When this indicator is activated, a document containing the following details is created during variance calculation or target cost calculation:

• Who calculated the target cost or variance
• When the target cost or variance was calculated
• The target cost or variance that has changed

Figure 8

Deactivate the Write Line Items indicator in transaction OKV0

Figure 9

Deactivate the Write Line Items indicator in transaction OKV1

If the aforementioned details are not needed (for audit or test purposes), it is a best practice to deactivate the indicator, especially in a production environment.

Deactivate the Generate Line Items Indicator

You can deactivate the Generate Line Items indicator in the results analysis version via transaction OKG9, by deselecting the selected check box in Figure 10.

Figure 10

Deactivate the Generate Line Items indicator

Activating this indicator creates a document containing the following details during WIP or results analysis:

• Who performed the analysis
• When the analysis was performed
• The data that has changed

If the aforementioned details are not needed (for audit or test purposes), it is a best practice to deactivate the indicator, especially in a production environment.

Target Cost Versions

Target cost versions are used to determine the basis for target cost calculation. Target cost versions are used primarily to control the variance type (e.g., total, production, or planning) in variance calculation. They form the basis for calculating variances for a cost center, an order, or a cost hierarchy, and splitting the actual cost posted to a cost object hierarchy to individual product. You can configure target cost versions via transactions OKV5 (Figure 11), OKV6 (Figure 12), and OKV7 for cost centers, orders, and cost object hierarchy, respectively. The screen that transaction OKV7 produces is identical to Figure 12.

Figure 11

Target cost version setting for cost centers

Figure 12

Target cost version setting for orders

The standard target cost used in the SAP system includes:

• Target cost version 0 (total variance)
• Target cost version 1 (production variance)
• Target cost version 2 (planning variance)
• Target cost version 3 (production variance of the period)

A rule of thumb with target cost versions is that the higher the number of target cost versions, the higher the amount of data recorded. To reduce the number of data entries in these tables, it is a best practice to objectively examine if the calculation and analysis of all target cost versions is needed or relevant to your business, especially if the calculation of only target cost version 0 is sufficient for your business needs.

Delete Planned Line Items

As discussed in the integrated planning section, you can use transactions KP90 and KP91 to delete planned line items. The deletion of planned records via these transactions also helps reduce the content of tables COSP and COSS. You can use transaction KP90 to delete defined cost elements, revenue elements, or all planning data and revenue elements in a version, especially when you want to renew the planning of your primary cost elements. On the other hand, you can use transaction KP91 to delete all planning records (e.g., costs and services) for a fiscal year.

Archiving: Integrated Planning and Cost Object Controlling 

To reduce data volume and optimize system performance, consider archiving the contents of tables COEJ, COSB, COSP, COSS, and so on. The archiving functionality for these tables supports a number of archiving objects. You can archive the total records for internal orders, planning records, and actual total data via the archiving objects CO_ORDER, CO_CCTR_PL, and CO_TOTAL, respectively. However, before archiving the data in these tables, you can use some analysis programs to determine the most ideal archiving object to use. You can use the table analysis programs RARCCOA1, RARCCOA2, and RARCCOA3 to achieve this requirement. You can use program RARCCOA1 to analyze the CO tables COEP, COEJ, COSP, COSS, and COST (Figure 13).

Figure 13

Program RARCCOA1: CO tables for analysis

Usually, program RARCCOA1 is first executed and counts the entries in the defined CO tables (Figure 14). It then determines basic values (e.g., the object type or organization type) and creates the data extract.

Figure 14

Entries count when running report RARCCOA1

Program RARCCOA2 is used to generate a report that compares the number of table entries with the archiving object (Figure 15).

The report generated shows a summary of the data extract created by program RARCCOA1. You can obtain additional information by clicking the Total in the Rank column, which brings up the screen in Figure 16.

Figure 16

Additional information based on program RARCCOA2

Program RARCCOA3 displays the number of entries in table COEP that you can archive via the CO_ITEM archiving object (Figure 17). Also, the report provides information about periods that have a table entry assigned.

Figure 17

Program RARCCOA3: Table COEP analysis for archiving object CO_ITEM

Furthermore, program RARCCOAP supports the analysis of tables COEJ, COSP, COSS, and COST (Figure 18). The program displays the entries that can be archived with archiving object CO_CCTR_PL after reading all records in the chosen tables.

Figure 18

Program RARCCOAP: CO tables analysis for CO_CCTR_PL archiving object

SAP recommends that program RARCCOAP should be used if actual data needs to be retained for cost centers and when retaining planning data is not necessary.

Kehinde Eseyin

Kehinde Eseyin is a security architect. He holds a bachelor’s degree in computer science. He has about 12 years of IT security, governance framework, IS risk, and compliance experience gained by working in numerous global organizations. Over the years, he has demonstrated competencies in security design, information assurance, cyber security, data privacy, threat and vulnerability management, penetration testing, business architecture, project management, IT audit, IS controls framework, and identity and access management.
 

You may contact the author at eseyinok@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.