030518 quick wins

Claudia Huber Karl Lang Advanced Technology Group Active Global Support Egon Mller CoE Financial Services Active Global Support

Archive-QuickWins for Upgrades Roadmap 19. May 2003

Archive-QuickWins for Upgrades

Table of Contents

Motivation...........................................................................................................................6

1 Quick Win Tables.........................................................................................................7

2 Procedure........................................................................................................................8

2.1 Identify QuickWin Tables ...........................................................................................................................8 Step1 .................................................................................................................................................................8 Step 2 ................................................................................................................................................................8 Step 3 ................................................................................................................................................................8

2.2 Analysis .......................................................................................................................................................8

2.3 Recommendations......................................................................................................................................8

3 Detailed Description Priority 1 ...................................................................................9

3.1 Change documents ( CDHDR, CDCLS )....................................................................................................9 3.1.1 Description ...............................................................................................................................................9 3.1.2 Analysis ....................................................................................................................................................9 3.1.3 Recommendation .....................................................................................................................................9

3.2 IDOCs ( EDIDS, EDIDC, EDI40, EDID30C, EDID3, EDIDOC) ..................................................................10 3.2.1 Description .............................................................................................................................................10 3.2.2 Analysis ..................................................................................................................................................10 3.2.3 Recommendation ...................................................................................................................................10

3.3 Workflow Item ( SWWWIHEAD, SW_CONTOB, SWWLOGHIST) .......................................................10 3.3.1 Description .............................................................................................................................................10 3.3.2 Analysis ..................................................................................................................................................11 3.3.3 Recommendation ...................................................................................................................................12

3.4 Workflow Event Trace ( SWELOG, SWELTS)......................................................................................12 3.4.1 Description .............................................................................................................................................12 3.4.2 Analysis ..................................................................................................................................................12 3.4.3 Recommendation ...................................................................................................................................12

3.5 ALE Change Pointer ( BDCP, BDCPS ) ................................................................................................12 3.5.1 Description .............................................................................................................................................12 3.5.2 Analysis ..................................................................................................................................................13 3.5.3 Recommendation ...................................................................................................................................13

3.6 EC-PCA Items ( GLPCA )..........................................................................................................................14 3.6.1 Description .............................................................................................................................................14 3.6.2 Analysis ..................................................................................................................................................14 3.6.3 Recommendation ...................................................................................................................................14

Seite 2


3.7 Tables BKPF, REGUH, REGUP (Payment program)..............................................................................15 3.7.1 Description .............................................................................................................................................15 3.7.2 Recommendation ...................................................................................................................................15

3.8 Tabelle MHND, MHNK, MGND..................................................................................................................15 3.8.1 Description .............................................................................................................................................15 3.8.2 Recommendation ...................................................................................................................................15

4 Detailed Description Priority 2 .................................................................................16

4.1 Material Mgmt Subsequent posting data ( ACCTHD, ACCTIT )............................................................16 4.1.1 Description .............................................................................................................................................16 4.1.2 Analysis ..................................................................................................................................................16 4.1.3 Recommendation ...................................................................................................................................16

4.2 Secondary Index for G/L Accounts ( BSIS ) ...........................................................................................16 4.2.1 Description .............................................................................................................................................16 4.2.2 Analysis ..................................................................................................................................................17 4.2.3 Recommendation ...................................................................................................................................17

4.3 CATT Protocol Data ...............................................................................................................................17 4.3.1 Description .............................................................................................................................................17 4.3.2 Analysis ..................................................................................................................................................18 4.3.3 Recommendation ...................................................................................................................................18

4.4 CO Items ( COEP )..................................................................................................................................18 4.4.1 Description .............................................................................................................................................18 4.4.2 Analysis ..................................................................................................................................................18

4.5 Change logs ( DBTABLOG, DBTABPRT )...............................................................................................20 4.5.1 Description .............................................................................................................................................20 4.5.2 Analysis ..................................................................................................................................................20 4.5.3 Recommendation ...................................................................................................................................21

5 Detailed Description Priority 3 .................................................................................22

5.1 Error log tables (CMFK, CMFP) and Message Control Records ( NAST ) ...........................................22 5.1.1 Description .............................................................................................................................................22 5.1.2 Analysis of table CMFK..........................................................................................................................22 5.1.3 Recommendation ...................................................................................................................................22

5.2 SAP OFFICE Tables ( SOC3, SOOD ) ......................................................................................................24 5.2.1 Description .............................................................................................................................................24 5.2.2 Analysis ..................................................................................................................................................25 5.2.3 Recommendation ...................................................................................................................................25

5.3 VBFS (Error Log for Collective Processing) ..........................................................................................25 5.3.1 Description .............................................................................................................................................25 5.3.2 Analysis ..................................................................................................................................................25 5.3.3 Recommendation ...................................................................................................................................25

Seite 3


5.4 Material-Ledger Indexes ( CKMI1 ) ..........................................................................................................26 5.4.1 Analysis ..................................................................................................................................................26 5.4.2 Recommendation ...................................................................................................................................26

5.5 Material Documents ( MKPF, MSEG, NAST)...........................................................................................26 5.5.1 Description .............................................................................................................................................26 5.5.2 Analysis ..................................................................................................................................................26 5.5.3 Recommendation ...................................................................................................................................26

5.6 S* Tables .................................................................................................................................................26 5.6.1 Description .............................................................................................................................................26 5.6.2 Analysis ..................................................................................................................................................27 5.6.3 Recommendation ...................................................................................................................................27

5.7 WLK1 (Listing Conditions) Retail ONLY..............................................................................................27 5.7.1 Description .............................................................................................................................................27 5.7.2 Analysis ..................................................................................................................................................27 5.7.3 Recommendation ...................................................................................................................................27

5.8 Table AVIP .................................................................................................................................................27 5.8.1 Description .............................................................................................................................................27 5.8.2 Recommendation ...................................................................................................................................27

5.9 Table COIX, TKEB1 ...................................................................................................................................27 5.9.1 Description .............................................................................................................................................27 5.9.2 Recommendation ...................................................................................................................................27

5.10 Tabelle PAYR (Scheckregister).......................................................................................................28 5.10.1 Description......................................................................................................................................28 5.10.2 Recommendation ...........................................................................................................................28

5.11 Table LWRKSTAT (Translation statistics) .....................................................................................28 5.11.1 Description......................................................................................................................................28 5.11.2 Recommendation ...........................................................................................................................28

5.12 Table LDK00......................................................................................................................................28 5.12.1 Description......................................................................................................................................28 5.12.2 Recommendation ...........................................................................................................................28

5.13 Table TF585.......................................................................................................................................28 5.13.1 Description......................................................................................................................................28 5.13.2 Recommendation ...........................................................................................................................29

5.14 Table T558A ......................................................................................................................................29 5.14.1 Description......................................................................................................................................29 5.14.2 Recommendation ...........................................................................................................................29

5.15 Table COIFT ......................................................................................................................................29 5.15.1 Description......................................................................................................................................29 5.15.2 Recommendation ...........................................................................................................................29

5.16 Table IS-RE Immobilienverwaltung ................................................................................................30

Seite 4


5.16.1 Description......................................................................................................................................30 5.16.2 Recommendation ...........................................................................................................................30

5.17 Further Tables ..................................................................................................................................30

Seite 5


Motivation This document provides a list of tables that can be archived or deleted quite easily without an intensive and time consuming approval process with the business process owners. This is because these tables contain data that is often not needed from a business point of view. This list is based on the experience of many archiving projects and deliveries of the SMO consulting package SAP Data Management (DMA). This document describes how to analyze the content of each table. A thorough content analysis is the prerequisite to provide individual and detailed recommendations on archiving and deletion and to give an estimation of the success of the recommended measures (e.g. gained disk space). In general the tables have to be analyzed with respect to other tables belonging to them from an application point of view as one unit. They are not analyzed as standalone tables. (e.g. tables CDHDR, CDCLS) Before implementing an archiving object or using a reorganization report, the customer should ensure having applied the latest relevant SAP Notes for the archiving object or reorganization report (or having applied the latest Support Packages)

Seite 6


1 Quick Win Tables Quick Wins: Priority 1 Action is necessary if found within the 30 largest DB-tables CDCLS Change documents Archive EDIDS, EDI40, EDI30C, EDID3, EDIDOC IDocs Archive SWWWIHEAD, SW_CONTOB, SWWLOGHIST, SWPSTEPLOG

Workitem Reorg / Archive

SWELOG Event trace (Workflow) Reorg BDCP ALE change pointer Reorg GLPCA EC-PCA Items Archive REGUH, REGUP Data from payment program Reorg MHND, MHNK Dunning data Reorg Quick Wins: Priority 2 - Action is necessary if found within the 20 largest DB-tables BSIS Secondary Index G/L account Reorg / Archive CATN, CATM, CATO, CATX CATT-Data Reorg / Archive COEP CO Items (reconciliation objects) Archive ACCTIT Compressed data from FI/CO document Reorg / Archive DBTABLOG Table change logs Archive Quick Wins: Priority 3 - Action is necessary if found within the 15 largest DB-tables CMFP and NAST Error protocol and message status Reorg SOC3, SOOD, SOFFCONT SAP Office Reorg VBFS Error Log for Collective Processing Reorg CKMI1 Material Ledger Indexes Archive MSEG, NAST Material documents Archive Sxxx, e.g. S033, S741, S-tables for e.g. LIS Reorg / Archive AVIP Payment Advice Line Item Reorg COIX, TKEB1 Reorg PAYR Payrun Archive LWRKSTAT Translation statistics Reorg LDK00 Status WM Communication Records Reorg TF585 Inventory Data Reorg T558A Payroll Account Transfer Reorg COIFT Interface to Activity Allocation Reorg VIMI0x, VIOBx IS-RE Archive If QuickWin tables are found in the top 30 largest customer tables, they should only be analyzed as described in this document.

Seite 7


2 Procedure

2.1 Identify QuickWin Tables Step1 The analysis of QuickWins in Upgrade Checks should only be performed for databases with more than 200 GB of data (without indexes). At this customers the largest 30 tables should be identified. (TA: DB02 -> Details -> sorted Top 30 tables). Step 2 Check whether the Priority 1 QuickWin tables are within the Top 30 tables and are lager than > 1 GB If yes, go ahead with analysis and recommendations concerning the identified Priority1 QuickWin tables. Step 3 Then check whether the Priority 2 QuickWin tables are within the Top 20 tables and are larger than > 3 GB If yes, go ahead with analysis and recommendations concerning the identified Reorganization QuickWin tables. Step 4 Then check whether the Priority 3 QuickWin tables are within the Top 15 tables and are larger than > 5 GB If yes, go ahead with analysis and recommendations concerning the identified Archiving QuickWin tables. Important for the practical use and performance improvement of a reduction of data in Step 3 and 4 is the question whether the identified tables go through a conversions procedure (PCON, XPRA, after import methods) during or after the upgrade process and therefore cause downtime.

2.2 Analysis Analyze identified tables as described in the detailed chapters below.

2.3 Recommendations Depending on the result of the analysis, appropriate recommendations about archiving or deletion as described in the detailed chapters below can be provided. Recommendations for archiving or deletion should only be provided, if the recommended measures do not only have a marginal effect, but reduce the table noticeably, e.g. that at least 20% of the analyzed data is in a state that allows archiving or deletion. If there is no expected effect, the table should not be mentioned at all.

Seite 8


3 Detailed Description Priority 1

3.1 Change documents ( CDHDR, CDCLS ) 3.1.1 Description Change documents are written to tables CDHDR (header) and CDCLS (positions). Normally change documents are archived with the archiving object of the corresponding business-object, e.g. MM_EKKO, MM_MATNR. But especially long term business objects e.g. master data, that is changed quite often, can cause an enormous growth of table CDCLS. To prevent this, there is the possibility to archive older change documents independently and isolated from the corresponding business object with the usage of archiving object CHANGEDOCU. This object has to be implemented first (see SAP Note 140255). In general CHANGEDOCU should only be used to archive change documents for master data. Change documents for transaction data are supposed to be archived with the corresponding transaction data object. Archived change documents can be retrieved via SAP AS (SAP Archive Information System) in a technical and business-oriented (SAP Note 183774) view. From release 4.6B on there is a reload functionality (SAP Note 490988)

3.1.2 Analysis Analysis of creation time of items in table CDHDR regarding object class. CHDHR-OBJECTCLAS, CDHDR-UDATE Example: Client ObjectClass Y2003 Y2002 Y2001 Y2000 Y1999


3.2 IDOCs ( EDIDS, EDIDC, EDI40, EDID30C, EDID3, EDIDOC) 3.2.1 Description IDocs are used to distribute master- and transactional data in distributed system environment as an ALE landscape. Normally IDocs are not used any longer after they were processed successfully in the receiving system.

3.2.2 Analysis Analyze the distribution of IDocs per status over the past years with transaction WE10 or WE05: Example: State Description 2002 2001


3.3.2 Analysis Analyze SWWWIHEAD with the distribution over years for each type (SWWWIHEAD-WI_TYPE) and status (SWWWIHEAD-WI_STAT). Example:

Type 2003 2002 2001


3.3.3 Recommendation If the workitems of type C are not needed from an application point of view, they should be deleted with report RSWWCIDE. If archiving of workitems of type C is necessary, the IDoc archiving programs have to be changed and all related IDocs have to be archived in advance. (this procedure should only be used in exceptional cases).

3.4 Workflow Event Trace ( SWELOG, SWELTS) 3.4.1 Description (Dont mix up with Workflow Trace (TA: SWU8, SWU9, SWU10). In general the event trace should not be activated in production systems due to performance reasons. In certain situations it can be turned on for error analysis, but should be turned off immediately after. Trace data is written to the tables SWELOG, SWELTS, . These tables can be deleted with report RSWELOGD (4.6B).

3.4.2 Analysis The age of the entries can be analyzed with the field SWELOG-EV_DATE, but normally there is no analysis necessary.

3.4.3 Recommendation Delete event trace independently of the age of the entries with report RSWELOGD.

3.5 ALE Change Pointer ( BDCP, BDCPS ) 3.5.1 Description ALE Change Pointers are used to distribute data changes (e.g. on master data) in an ALE system environment. Based on these change pointers IDocs are created (Report RBDMIDOC), that transport the changes to the connected systems. Which kind of changed data the change pointers refer to is coded in the message type. Normally change pointers get the status processed (BDCPS-PROCESSED = X) after the corresponding IDoc was created. These change pointers can be deleted with report RBDCPCLR without any risk.

Seite 12


In some cases the status of a change pointer does not change to processed despite it was processed correctly. These change pointers can also be deleted with report RBDCPCLR as obsolete, after a certain period of time, e.g. 6 months. After this period all regular jobs to process change pointers can surely supposed to having worked successfully.

3.5.2 Analysis The ratio of processed to obsolete change pointers can be analyzed with the field BDCPS-PROCESS. If the amount of unprocessed change pointers is high (> 10% of all), the customer should analyze the message types of these change pointers and make sure, that its processes work correctly. For unprocessed change pointers check the age with the View BDCPV (CRETIME, PROCESS) Example: Client Mestyp < 1 Month < 2 Month < 3 Month < 6 Month Adress DEBI Material

3.5.3 Recommendation Processed change pointers should be deleted with report RBDCPCLR with a retention period of 1 month. Obsolete change pointers can be deleted after e.g. 3 months after the customer has checked the correctness its ALE procedures.

Seite 13


3.6 EC-PCA Items ( GLPCA ) 3.6.1 Description With the archiving objects EC_PCA_ITM and EC_PCA_SUM (> release 4.6A, SAP Note 370299) or PCA_OBJECT (release 3.0D 4.5B) line items and totals records of the Profit Center Accounting can be archived. Line items are archived sorted according to profit centers. According to the selection criteria the archiving includes besides the ledger 8A also data from the average balance export ledger 8Z and the export ledger 8E.

3.6.2 Analysis See SAP Note 203545: (Reports ZAGLPCA1 (Analysis), ZAGLPCA2 (Output)). Output from ZAGLPCA2 should be pasted in the report. Example: Mdt Ld KKrs BuKr Jahr Periode GLPCA % 70 8A 1 2 1998 4 56.697 0,04 70 8A 1 2 1998 2 57.697 0,04 70 8A 1 2 1998 6 68.816 0,05 70 8A 1 3 1998 5 1.898.044 1,25 70 8A 1 2 1998 5 55.015 0,04 70 8A 1 3 1998 6 1.923.026 1,26 70 8A 1 2 1998 1 61.468 0,04 70 8A 1 3 1998 1 1.601.492 1,05 70 8A 1 3 1997 9 1.417.373 0,93 70 8A 1 3 1997 6 2.059.069 1,35 70 8A 1 3 1997 3 1.002.642 0,66 70 8A 1 3 1997 11 1.458.698 0,96 70 8A 1 2 1997 11 76.465 0,05 70 8A 1 2 1997 12 88.679 0,06 70 8A 1 3 1997 2 1.015.840 0,67 70 8A 1 2 1997 7 78.977 0,05 70 8A 1 2 1997 6 91.237 0,06 70 8A 1 3 1997 4 1.072.064 0,7 70 8A 1 3 1997 12 1.513.291 0,99 70 8A 1 3 1997 8 1.262.451 0,83 70 8A 1 3 1997 7 1.192.298 0,78

3.6.3 Recommendation The customer should check the possibility to summarize already existing EC-PCA items or to avoid the creation of new EC-PCA items from an application point of view. The priority should lay on summarization, because only this can reduce the actual amount of data. In addition the customer should check with its application team the possibility of archiving EC-PCA items with the archiving object EC_PCA_ITM with a retention period of 24 months. Calculate from the above analysis the percentage of GLPCA entries that can be archived with a default retention period of 24 months.

Seite 14


3.7 Tables BKPF, REGUH, REGUP (Payment program) 3.7.1 Description Tables BKPF, REGUH, REGUP are converted during upgrade for the industry solutions IS-B, IS-RE, IS-IS, IS-F (for details check SAP Note 125047 and 125116)

3.7.2 Recommendation If possible delete outdated entries from these tables with Transaction F110 (Payment Run -> Reorganization). This decision must be taken from the business owners. (e.g. Finance department)

3.8 Tabelle MHND, MHNK, MGND 3.8.1 Description The data volume of the dunning runs you have carried out is continually increasing. This has a detrimental effect on the runtime. Furthermore, upgrade time is extended if database conversions are necessary.

3.8.2 Recommendation Reorganize (that is, delete) the dunning runs no longer required. You can do this in the automatic dunning initial screen via the menu option 'Dunning notice -> Reorganization'. (Transaction F150) Attention: Deletion of dunning runs has to be discussed with the business owners. They have to define how long this data is still needed. Upgrade 3.x, 4.0 to 4.6 or higher

Seite 15



4.1 Material Mgmt Subsequent posting data ( ACCTHD, ACCTIT ) 4.1.1 Description The tables ACCTHD, ACCTIT, ACCTCR can be archived with the archiving object MM_ACCTIT. Under certain circumstances the content of these tables can be deleted. For details check SAP Note 48009 (Tables ACCTHD, ACCTIT, ACCTCR: Questions and answers). For Release 3.0D 3.1I the archiving object MM_ACCTIT has to be imported from sapservx first. (SAP Note 83076)

Background information:

1. Which data is updated in the ACCT* tables? The documents of MM Inventory Management and MM Invoice Verification do not contain all the information required for an update in Accounting. Certain additional information is only known during the life of the original posting. These documents are unsuitable for subsequent postings. For this reason, when you post goods movements and invoice receipts (reference types MKPF and RMRP), the call of the FI/CO interface is documented in the form of documents in the tables ACCTHD, ACCTIT and ACCTCR. SAP Note 316468 describes how you can ascertain to which organizational units and periods the data of the ACCT tables is assigned. 2. What are these tables required for? This information is stored for applications which are to be supplied with the posting data of MM Inventory Management and MM Invoice Verification at a later date. The following applications are relevant: o Special Purpose Ledger (FI-SL Profit Center Accounting (EC-PCA) o Controlling (CO) o Funds Management Public Sector (IS-PS-FM) The reason for subsequent posting may be: o You plan to use an application later in production and to use data of past periods in this application. You use an application in production but you do not provide the data online. How you can check whether this is the case is described in detail in SAP Note 48009 Apart from the reasons mentioned above, you require the ACCT* tables if errors occurred during the through posting of MM inventory management documents or MM invoice verification documents. You can correct such errors by using the information from the ACCT* tables. For audit purposes, the ACCT* tables are not used by AIS and DART in the standard. The user exit technology in DART allows to increase the data volume according to the customer's wishes, however (i.e. also ACCT* tables).

4.1.2 Analysis Run report RGUANAM1 (SAP Note 316468).

4.1.3 Recommendation Check SAP Note 48009 to decide whether the data in these tables is needed and therefore should be archived or can be deleted. The results form the analysis report helps you to decide which data should be archived.

4.2 Secondary Index for G/L Accounts ( BSIS ) 4.2.1 Description When to analyze:

G/L Accounts with a number of line items > 1 Mio or BSIS > 1 GB or within the top 30 tables.

Seite 16


Table BSIS contains an account oriented listing of FI documents. As the G/L account is a field in the cluster table RFBLG that holds the positions of FI documents, this field cannot be accessed directly or index based. Therefore a copy of certain field is stored in table BSIS to get a fast G/L account based access to FI documents.

4.2.2 Analysis Call transaction ST14 and choose Other Applications -> Financial Accounting -> Transaction Data -> Line Items Update (BSIS). This analysis shows top G/L accounts with the most line items and gives the type of the account. From this analysis you can conclude the potential for avoidance or deletion. (e.g. open items on tax accounts) An analysis tool that shows the distribution of the volume of line items over years and periods is planned for future. From this analysis you can conclude the potential of archiving. The output should be copied to the report.

4.2.3 Recommendation For general recommendations check SAP Note: 178487

Archiving: Customize the retention period of the archiving object FI_DOCUMNT for the secondary index tables, so that the line items corresponding to archived FI documents can be deleted in the post-processing of an archiving run. The table BSIS is not archived, but the entries are deleted during the process of archiving, because in BSIS duplicates of FI-documents for certain accounts are stored. The reason for this may be, that the account is an open item management account. The line items, then, are transferred to BSAS after clearing, where they are deleted during the archiving run. Or the accounts may have a line item display. The line item display is used for reporting and for better performance in accessing the line items of certain accounts.

Avoidance: Avoid inserts on this table by deactivating line item update for certain G/L accounts.

Deletion: o Line items that are not needed any longer can be deleted with report RFSEPA04 (SAP Note

482050). o Automatic Clearing (transaction F.13)

In some cases Automatic Clearing (Transaction F.13) does not work properly. This leads to unnecessary growth of the table BSIS indirectly due to undeleted non-cleared open items. If there are G/L accounts with Open Items Management set which have more than 50.000 items in BSIS this could be a hint, that Automatic Clearing has a problem. Table TF123 should be customized for all accounts with 'Open Item Management' by means of Transaction OB74. This table contains the criteria for grouping documents which can be cleared.

4.3 CATT Protocol Data 4.3.1 Description CATx-Tables CATT Data can be deleted or archived. Report RSCATDEL deletes all CATT protocol data, with an expiration date (CATK-VDAT) < system date and without an archiving flag (CATK-ARCH) = . If CATT protocols are needed for a longer period of time they also can be archived with the archiving object CATPROARCH. Prerequisite: expiration data < system date and the archiving flag set.

Seite 17


4.3.2 Analysis Archive flag (CATK-ARCH = X) means:

archiving necessary (RSCATDEL cannot delete these entries) archiving possible (archiving object CATPROARCH will archive these entries)

Expiration date (CATK-VDAT) Example: Client CATK-ARCH CATK-VDAT Zukunft < 1 Month < 2 Month < 3 Month < 6 Month X 83737 3444 635 124 12555

4.3.3 Recommendation Delete or archive all CATT protocols older than 3 months. The analysis above helps to decide how big the effect of archiving or deletion will be. If CATT protocols must be archived, but have no CATK-ARCH-flag, the only possibility is to set this flag by a customer-owned Z-report.

4.4 CO Items ( COEP ) 4.4.1 Description The most important objects for Quick Wins are reconciliation objects. (type AO). Other CO line items related to e.g. cost centers or internal orders often need discussion with the CO department because they are needed for reporting, whereas reconciliation objects do not carry information, that is needed for reporting.

4.4.2 Analysis Report RARCCOA1 (see SAP Note 138688) analyzes the content of the CO-tables and gives hints with which of the various CO archiving objects which of the entries can be archived. The result is written to DB (table INDX). The report experiences runtimes depending on the data volumes - of up to 15 min. Report RARCCOA2 only prepares the output of the analysis for display. It can be called multiple times without having to update the results with a new RARCCOA1 report run. Example: RARCCOA2 Output

Seite 18


In column OTy, the type of the CO item is given. Reconciliation Objects (AO) If reconciliation objects make more than > 10% of all CO objects and the COEP > 5 GB, then archiving of CO reconciliation objects with archiving object CO_ITEM should be recommended. Normally archiving of reconciliation objects does not cause any loss of information for the CO application department. Besides reconciliation objects the following CO items are also often archived with the archiving object CO_ITEM, but the decision to do so, needs an more intensive approval process with the CO department, because this data is sometimes needed for reporting purposes. CO items on internal orders (OR) CO items on cost centers (KS, KL)

Seite 19


SAP AG 2002, Title of Presentation, Speaker Name 6

KSTKST SumSum ActualActual KSTKST SumSum PlanPlan

KST KST Line ItemLine ItemActualActual

KST KST Line Item Line Item PlanPlan

AUFAUF SumSum

AUF AUF Line ItemLine Item

AUFAUFSettlementSettlementDocumentsDocuments

VBPVBP SumSum

VBP VBP Line ItemLine Item

VBP VBP SettlementSettlementDocumentsDocuments

KSTKST MasterMaster

AUFAUF MasterMaster

VBPVBP MasterMaster

CO_COSTCTRCO_COSTCTR

CO_CCTR_IDCO_CCTR_ID CO_CCTR_PLCO_CCTR_PL

CO_CCTR_EPCO_CCTR_EP

CO_ORDERCO_ORDER SD_VBAKSD_VBAK

CO_ITEMCO_ITEM

CO_KABRCO_KABR

Objects of CO-Archiving

Background information: This slide illustrates how the various archiving objects for CO work together and overlap.

4.5 Change logs ( DBTABLOG, DBTABPRT ) 4.5.1 Description The SAP systems can automatically log all changes that are made to customizing tables. To track who made which changes at which time, you can view the change log. If you want to be able to create table change logs for a table, you must set the corresponding flag in the technical settings for the table. Also the profile parameter rec/client has to be set. Up to Release 4.0 the logs are stored in table DBTABPRT. From Release 4.0 on table DBTABLOG is used and DBTABPRT is no longer supported. Up to 4.0: DBTABPRT: Before Release 4.0, you can archive the table change logs using Transaction SCU3 (RSTBARCH). Since this method does not use the R/3 central archiving, but communicates directly with the file system, it is no longer supported in Release 4.0. There is no display- or reload-functionality implemented for data archived with RSTBARCH -Neither in releases up to 4.0 nor in the following releases.

4.5.2 Analysis Distribution of DBTABPRT entries Change date: DBTABPRT-AS4DATE Example: last 12 months last 12-24 months


4.5.3 Recommendation If the customer needs to keep change logs, it can convert the logs stored in table DBTABPRT to the new table DBTABLOG using report RSDBLOGCONV40. Once you have converted them, you can archive them using the R/3 System central archiving. Then the data can be archived with archiving object BC_DBLOGS. Since the data in table DBTABPRT is not deleted unless the conversion is successful, you cannot lose any data if the report terminates abnormally. If this happens, you simply need to restart the report. Further remarks about RSDBLOGCONV40: You should only run the report as a background job, since the table DBTABPRT can become very large, and the program runtime can be very long if large quantities of data are involved. The report is supplied with two variants: The first converts table DBTABPRT entirely. The second is a template, which you can use to create your own variants if you want to convert entries for a particular period. For technical details about the report (such as the resources it requires), see the report documentation.

If the customer does not need to keep change logs, the logs or a part of them up to a certain date should be deleted with report RSTBPDEL.

From 4.0 on: DBTABLOG You can archive table DBTABLOG using the central archiving in the R/3 System (Transaction SARA) and the archiving object BC_DBLOGS. When you archive the log, the system archives all log entries for a particular period. As it is possible to reload archived change logs, there is no functional disadvantage for the customer caused by archived change logs. The customer should archive change logs and only keep the change logs of the last 12 months.

Seite 21



5.1 Error log tables (CMFK, CMFP) and Message Control Records ( NAST ) 5.1.1 Description These tables are used from various applications. APLID shows the reference to the corresponding application. The most common APLID value found is WFMC (workflow: message control). APLID = WFMC gives a hint, that this item was written from the message control. That means, that there exists a corresponding entry in table NAST. The field NAST-KAPPL shows which application caused the NAST entry. NAST entries incl. the corresponding CMFK-, CMFP-entries are automatically removed when SD- and MM-documents (deliveries, billing documents, sales documents, transports) or retail promotion (W_PROMO) are archived.

5.1.2 Analysis of table CMFK Count the number of CMFK-APLIDs per year and the responsible application (NAST-KAPPL). For each CMFK-entry with CMFK-APLID = WFMC the corresponding application-ID (NAST-KAPPL) has to be identified via NAST-CMFPNR. Example: CMFK - APLID NAST - KAPPL 1995 1996 . 2003 WFMC V1 1,5 Mio 2,0 Mio . 6,5 Mio WFMC EF 0,1 Mio 0,01 Mio . 1,1 Mio KKS ACT .

5.1.3 Recommendation In case there is no corresponding NAST entry for a CMFK-, CMFP-entry, these orphaned logs can be deleted with report RSCLCMFP.

Selection screen: RSCLCMFP

Seite 22


In case there is an enormous and rapid growth of NAST and CMFP (e.g. because there is no archiving in SD implemented), these protocols (CMFP, CMFK) can be deleted with report RSCLNAFP. RSCLNAFP should only be used for applications, which also delete the protocol data during the archiving process of the application objects (deliveries, billing documents, transports). (see table below)

Archiving Object Table NAST Table CMFK Table CMFP MM_EKKO archived ----- ----- MM_REBEL deleted ----- ----- MM_MATBEL deleted ----- ----- CO_COPC ----- archived archived W_PROMO archived archived archived RV_LIKP archived deleted deleted SD_VBAK archived archived archived SD_VBRK archived deleted deleted SD_VBKA archived ----- ----- SD_VTTK archived deleted deleted

Selection screen: RSCLNAFP You have to choose the output application (application which created the messages). It is important to select the field processed by todays date. The value entered here is interpreted corresponding to the Time unit selected below. E.g. 14 days or 14 months! Report RSCLNAFP and RSCLCMPF: available in standard since 4.0B; for other releases implement SAP Note 52114

Seite 23


5.2 SAP OFFICE Tables ( SOC3, SOOD ) 5.2.1 Description When a user deletes documents or mails from folders or recycle bins in the first step only the references from the folders to the documents are deleted. The content of the document itself, including header data and send protocols remain in the database. This remaining data can finally be deleted physically with report RSSORE00. (Tables SOC3, SOST, SOOS, SOES, SOOD, SOFM, ...). Background Information: In addition there are some specific reports for special needs: RSSODLIN (Deletion of inbox entries for individual users), RSSOTRCL (Deletion of shared trash), as of release 4.6 RSSODLWF (Deletion of workflow) and before release 4.6 ZSSODLWF. Also the reports RSSORESN (Reorganization of successful send operations) can be scheduled regularly.

Selection screen: RSSORE00 There is also the possibility to archive the content of documents (table SOC3) with an attached (optical) archive system either online via menu functionality or with the report RSSOAPUT. (document archiving)

Seite 24


Selection screen: RSSOAPUT

5.2.2 Analysis No further analysis necessary

5.2.3 Recommendation Schedule RSORE00 regularly if deletion is possibly. As an alternative archive the documents with RSSOAPUT.

5.3 VBFS (Error Log for Collective Processing) 5.3.1 Description There is no archiving object for table VBFS. There are reorganization reports RVVBSKDL (TA: VASK) and RVVBFSDL for this table. These reports are the only possibility to get rid of old and unnecessary data.

RVVBSKDL (Delete Groups and Logs) This report is necessary if the customer uses picking waves in its Warehouse Management. A picking wave is a group of deliveries. These work packages are processed together in subsequent activities (for example, creation of all picking orders for a picking wave). This report deletes reference numbers in the tables T311, T311A, T311L.

RVVBFSDL (Delete Group Data) This report is used, if no picking wave functionality is implemented in the customers system. In this case tables T311, T311A, T311L are not used.


5.3.3 Recommendation Schedule regular jobs for one of the reports RVVBSKDL or RVVBFSDL

Seite 25


5.4 Material-Ledger Indexes ( CKMI1 ) Table CKMI1

5.4.1 Analysis Distribution of items over years: CKMI1-BDATJ.

Example: 2002 2001 2000


S-tables can be archived. The corresponding archiving objects and archiving programmes are generated in the background when you click on Create archive files in TA: MCSX the first time for an S-table. Then an archiving object is generated. The name of the archiving object is MC_S e.g. for table S033 the archiving object is MC_S033 and also appears in TA: SARA.

5.6.2 Analysis No analysis necessary.

5.6.3 Recommendation The customer should check whether the data of the S-tables is still needed. If yes, it should check if old data can be archived. If not, the data should be deleted via the functionality of the Copy Management.

5.7 WLK1 (Listing Conditions) Retail ONLY 5.7.1 Description The report ZRWSORT53 can be used to delete expired listing conditions.


5.7.3 Recommendation The report ZRWSORT53 should be scheduled regularly in your system to avoid an unnecessary growth of table WLK1. If you did not implement this report already please apply SAP Note 184190 (Deleting expired listing conditions).

5.8 Table AVIP 5.8.1 Description For the items of payment advice notes (table AVIP), the name range extension requires a conversion to 4.0. Payment advice notes are automatically deleted after successful use in clearing transactions.

5.8.2 Recommendation Payment advice notes that might still exist but are no longer needed should be deleted with report RFAVIS20 before the upgrade in order to minimize the quantity of the payment advice note items to be converted.

5.9 Table COIX, TKEB1 5.9.1 Description Due to the namespace extension, tables COIX and TKEB1 need to be converted. If you do not regularly carry out the function 'Edit -> Delete (old) reports' in the technical monitor of the applications, data garbage is collected on the COIX in the course of time, especially after an upgrade.

5.9.2 Recommendation To eliminate the garbage before upgrading to Release 4.0, we recommend that you either carry out the above-mentioned function for all relevant application classes or implement and execute the report from SAP Note 86399.

Seite 27


5.10 Tabelle PAYR (Scheckregister) 5.10.1 Description Due to performance improvement measures for access to the check register (PAYR), a conversion of data has become necessary in Release 4.0A.

5.10.2 Recommendation The check information has a runtime independent from the corresponding documents. The option exists to archive the file PAYR with archiving object FI_SCHECK according to straightforward rules (selection parameter for runtime). For further details you should refer to the program documentation for archiving program RFCHKA00.

5.11 Table LWRKSTAT (Translation statistics) 5.11.1 Description When using the R/3 translation environment starting with R/3 Release 3.0E you can optimize the upgrade runtime to R/3 Release 4.X by reducing the data volume in table LWRKSTAT. If you extend the name space and adjust the translation statistics to the application component hierarchy, you will have to convert table LWRKSTAT as a result.

5.11.2 Recommendation R/3 Release 3.1G and higher: Users with the authorization profile S_ADMI_FCD (administrator authorization for the language environment) can reduce the number of translation statistics with Transaction SLLS. After entering a relevant target language, the user is requested to reduce the number of the stored translation statistics (providing a critical number of entries exists). You must consider all relevant target languages individually. R/3 Releases 3.0E and 3.0F: SAP recommends that you determine the data volume of table LWRKSTAT first (for example with Transaction SE16, with the report ZCOUNT01 (SAP Note 81911) or with non-SAP database functions). If the number of entries exceeds 100,000 and/or a large part of the available entries is unnecessary, use report ZLWRKRED (SAP Note 81911) to delete all out-of-date translation statistics.

5.12 Table LDK00 5.12.1 Description Table LDK00 has to be converted during the upgrade to Release 4.0, due to the general extension of the message identification from 2 characters to 20 characters. Table LDK00 contains the headers of the log records of the R/2 R/3 interface and it is not filled in the integrated R/3 WM.

5.12.2 Recommendation We recommend to reorganize the communication records of the R/2 R/3 interface before the upgrade using program RLREOLDK.

5.13 Table TF585 5.13.1 Description The table TF585 (EC-CS: Inventory data for the elimination of IU profit and loss in inventory) may contain many data records, which need to be converted for an upgrade due to a table change.

Seite 28


5.13.2 Recommendation If the inventory data for the elimination of IU profit and loss inventory contain data which are no longer needed (for example for former periods/years) you can delete these data before an upgrade. (SAP Note 159726) Upgrade from 3.x, 4.0, 4.5 to 4.6 or higher

5.14 Table T558A 5.14.1 Description Table T558A contains a lot of entries (more than 50.000) because a payroll account transfer for payroll accounting was carried out. After payroll account transfer, the table entries are usually no longer needed (Even if you have more than 5,000 entries the table should be checked, however, then the runtime will only become slightly shorter.) As of Release 4.5A table T558A is converted from a pooled table into a transparent table.

5.14.2 Recommendation If you no longer need the table entries and you completed payroll account transfer, delete all entries of the table in your R/3 System before the upgrade. (SAP Note 114000) Upgrade from 3.x to 4.5 or higher

5.15 Table COIFT 5.15.1 Description Because the name space was made longer, table COIFT must be specially converted for Release 4.0. This is relevant if you entered specifications for a cost allocation in CO as additional data with infotypes 2001, 2002 and 2010.

5.15.2 Recommendation Before you upgrade your system to Release 4.0A, it is essential that you 'empty' table COIFT, that is transfer all data into CO, and then reorganize the table (use the option available in report RKIBIHR1). Otherwise, the system may have problems transferring data entered in earlier releases, and the database runtimes during the upgrade may be very long. (SAP Note 85098)

Seite 29


5.16 Table IS-RE Immobilienverwaltung 5.16.1 Description For the upgrade to Release 4.6 some Real Estate Management tables are converted. For this reason, the upgrade to Release 4.6 may take longer for real estate customers with a large data volume. (for details check SAP Note 142907)

5.16.2 Recommendation The conversion of these tables may be time-consuming if the data volume is large. It may be possible to reduce the data volume by archiving data that is no longer required before the conversion. The table below shows the archiving objects RE_* that can be used for the different tables. Table RE_RNTL_UN RE_BUILDING RE_PROPRTY RE_OFFER RE_RNTL_AG RE_STLM_UNVIMI01 X VIMI03 X VIMI08 X VIAK03 X VZZKOPO X X X VIOB40 X X X VIOB41 X X X Check also SAP Note 142580.

5.17 Further Tables If you detect further tables that are critical to downtime during upgrade in your system, that are not described here, you should check with TA DB15 whether an archiving object exists for this table. In addition you can have these tables checked in an SAP Upgrade Downtime Assessment Service.

Seite 30