archiving assessment sample

8/11/2019 Archiving Assessment Sample

http://slidepdf.com/reader/full/archiving-assessment-sample 1/30

SAP Archiving Benefits Assessment

For

Customer

March 2009



Table of Contents

INTRODUCTION ............................................................................................................................... 1

EXECUTIVE SUMMARY .................................................................................................................... 2 ASSESSMENT APPROACH ............................................................................................................... 4

ARCHIVE STORAGE ........................................................................................................................ 5

DOCUMENTS AND M ASTER DATA ANALYSIS ...................................................................................... 6

RECOMMENDATION FOR THE ANALYSIS OF ARCHIVING OBJECTS FOR THE LARGEST T ABLES .............. 7

4.2.15 GLPCA: Actual Line Items ............................................................................................ 7 4.2.24 PCL2: RP Cluster 2 (Human Resource Management) ................................................. 8 4.2.8 COEP: CO Line Items (by Period) .................................................................................. 9

4.2.3 BKPF, RFBLG, Secondary Indexes (BSIS, BSAS, BSIM): Accounting DocumentTables. For Tables: BSIS, RFBLG and BKPF ....................................................................... 11

4.2.22 MSEG – Document Segments: Material and Articles ................................................. 13

4.2.22 GLFUNCA: – Special Purpose Ledger: Actual line items ........................................... 14

Archiving FI-SL Totals Records and Line Items (FI-SL) .................................................. 14

Definition ................................................................................................................................. 14

Use ......................................................................................................................................... 14

Structure ................................................................................................................................. 15 4.2.5 CKIS: Items Unit Costing/Itemization Product Costing ................................................. 15 4.2.25 PPOIX/PPOPX: Posting Index of Payroll Results ....................................................... 17 4.1.5 CDHDR and CDCLS: Change Documents ................................................................... 18 4.2.23 NAST, CMFP, CMFK: Message and Error Management Tables................................ 19

4.2.20 MARC, MARD, MBEW – Material Master Data (Plant Level) ..................................... 21

Structure ................................................................................................................................. 23

Integration ............................................................................................................................... 23

4.2.35 VBFA: Sales Document Flow ...................................................................................... 24

SEQUENCE OF OBJECTS IN ARCHIVING .......................................................................................... 25

SLIM BI ........................................................................................................................................ 27

Steps: ..................................................................................................................................... 27

Findings: ................................................................................................................................. 27

ABAP OPTIMIZATION .................................................................................................................... 28

Steps: ..................................................................................................................................... 28 Findings: ................................................................................................................................. 28

Archiving Assessment V2_HG Created on 3/18/2009 9:07 PM

http://help.sap.com/erp2005_ehp_04/helpdata/EN/8d/3e5464462a11d189000000e8323d3a/frameset.htm



Introduction

The following are the findings and recommendations related to our SAP Archiving Benefits

Analysis conducted at [CUSTOMER X] during January, 200X.

We wish to thank [CUSTOMER X] for giving us the opportunity, and resources, to complete thisassessment and for the incredible cooperation shown us over the past few weeks. As always, weare available to answer any questions [CUSTOMER X] might have and we look forward toestablishing a mutually beneficial partnership.

Sincerely,

The ICM America Team

Consultant Discipline

Linwood Doty Basis

Ron Grift ABAP

Jeff Halderman FI/CO

Uli Neubert Proj Mgmt

Christine Padmore HR

Anatoly Shevchenko SD

Ron Thompson PP/PS

Archiving Assessment V2_HG Page 1 of 30 Created on 3/18/2009 9:07 PM1



Executive Summary

[CUSTOMER X] requested ICM America to conduct an analysis to determine the right ILM(Information Lifecycle Management) strategy for their ERP environment and SAP Applications

Background : [CUSTOMER X] management required to establish clear documented dataretention periods, define a corporate data architecture scenario, as well as document archivingand retrieval mechanisms for all data, documents, images, emails with special consideration oflegal and SOX compliance requirements. The management recognized that ILM went beyondtechnical and performance reasons and provided sound long-term business benefits.The management was also interested in ILM’s impact in lowering operational costs.

[CUSTOMER X] selected ICM America to conduct an SAP Archiving Assessment to identifyopportunities to increase system performance, optimize ABAP codes, reduce data storage spaceand make specific recommendations on archiving methods and tools used to assure secure datastorage, as well as access and retrieval speed adequate to the expected usage of the historicdata.

The deliverable of this project was to provide an actionable roadmap and a Business Case withclear recommendations for [CUSTOMER X] as to what ILM components require changes with a 3point priority system.

Recommendations:It is our recommendation that [CUSTOMER X] should put an ILM strategy and process in placeand should implement it within the next half year.

Based on this analysis, we can draw the following conclusions:

At tr ibute Status Comments

Data Archiving1 Critical For compliance, performance, reduction on data volumes,

compliance in [xxxxx] .Steps identify data and tables. Some critical tables have beenidentified and are included in the document. Compliance: [Company X] has records in excess of 9 years are required bycompliance. This exposes the company to litigation by the sheer presence ofthe data. It is recommended that all [xxxxx] data be deleted after 9 years asa policy, with no backupOperational Performance: Due to redundant data the overall systemperformance is suffering. It is assumed that the SAP R/3 performance canimprove considerably with a data archiving plan in place.DW Performance: Due to low usage data and redundant data in the Oracleand SAP BI systems the overall performance of the systems is under stress.It is recommended to model the InfoProviders and decrease the datafootprint prior to archiving. This will both enhance performance and optimizearchiving at the same time. ICM uses automation tools to accomplish thistask

ABAP Audit: Part of the ILM strategy is to audit and document ABAP codesfor SOX documentation. [COMPANY X] has some very long and complex

ABAP codes that ‘no one dares to touch’. From a SOX – section 404,compliance it is mandated to generate simplified documentation as to whatthe program does for audit purposes. It is also recommended to periodicallyoptimize all programs and codes in the business systems. ICM usesautomated tools to accomplish this task

•1 Data archiving is most effective in reducing data volumes if it targets specific critical tables with the help of the relevant archiving

objects. Therefore, it is important that [CUSTOMER X] implement the archiving objects that affect the most critical tables, first.Identifying tables are the most critical depends largely on the installation of each individual customer. Therefore, it is notrecommended to generalize an archiving plan without a planned archiving strategy. Once critical tables and data is identifiedarchiving, and data access, can be scheduled based on business needs and strategies.

Archiving Assessment V2_HG Page 2 of 30 Created on 3/18/2009 9:07 PM



The timing of all of the archiving steps is not necessarily immediate.

Interviews were held with Stakeholders, Process Owners and Key personnel, across businessunit functional areas and within multiple business areas, to determine the issues that archivingwould be expected to address. Issues and benefits have been classified into four areas withinthis document:

• Issues that can be addressed without archiving, like direct deletes and data avoidance.• Recommended alternatives for setting up an archiving system.

• High Impact Issues that will be addressed by a small number of the “heavy hitter”archiving objects.

• Compliance and Legal issues that need to be considered in the ILM strategy.

In the Quick Hit section, this document also includes an analysis of the technical environment andurgent maintenance recommendations necessary for the continued stability and performance ofthe system.

The SAP Archiving Analysis offers [CUSTOMER X] the opportunity to utilize knowledge gainedthrough an independent view of the organization, analyze the issues and improvement potential,

and take the opportunity to leverage our recommendations to maximize the overall success ofefforts in the future.




Assessment Approach

ICM’s archiving assessment is part of ICM’s performance and Storage Optimization suite ofservices. ICM offers a suite of services.

The list below defines what components were selected by [CUSTOMER X] for this project

Type Attr ibute Selected

Archiving Assessment

Anal ysi s of the current archiving s ituati on Yes Anal ysi s of the ex isting s torage solut ions in place and recommendati on o fstorage options

Yes

Set up and demo of archiving and retrieval options (opt ional) No80/20 Analysis of Table-space usage and growth

Anal ysi s and recommendati on o f Archiv ing ob jects t o use

Anal ysi s of custom developments and thei r impact on archiving

Break-out workshops with business on retention periods YesRecommendation on retention periods for different documents

Recommendation on archiving approach to take

Landscape Assessment

TDMS AssessmentTransport Assessment

BW Assessment

Data Analysis NoInfoCube Analysis YesInfoCube Slimming Yes

Archivin g Analysis No

RBE Analysis

RBE or RBE Plus check

RBE Analysis

ABAPOptimization

ABAP Programs / code reviews YesSOX Compliance documentation review YesSample ABAP Optimization Yes




Archive Storage




Documents and Master data Analysis

Table Table Content Kbytes

GLPCA Actual line items in ProfitCenter Accounting 53,944,360

PCL2 RP Cluster 2: different HR data (mainly payroll and time

evaluation data)

29,611,560

COEP CO object: Line items (by period) 28,852,280

BSIS G/L accounts – open items secondary index 26,562,600

MSEG Article Document Items 24,668,200

GLFUNCA Special Purpose Ledger: Actual line items for FI 22,077,480

CKIS Items Unit Costing/Itemization Product Costing 21,331,160

RFBLG Cluster for FI documents 16,821,800

PPOIX Posting index of payroll results 12,559,456

CDCLS Cluster structure for change documents 11,116,400

CMFP Message and error management tables 9,576,520

NAST Message and error management tables 9,416,840

MSTA 7,864,360

MARC Material master data at plant level 6,901,800

BKPF RFBLG = Cluster for FI documents (BSEG = Document

Header)

6,215,720

VBFA Sales Document Flow 5,775,400

BALDAT Application log: Log messages 5,232,656




Retention PeriodDue to the lack of legal guidelines, there is no defined retention period for the transaction data(totals records and line items) in Profit Center Accounting.

SAP recommends that [CUSTOMER X] only archive the totals records when they are

no longer required (for example, to compare data from different years). It is oftenuseful to have the totals records of the last three years in the system.

Arch iv ing Per iods[CUSTOMER X] can archive actual line items whenever [CUSTOMER X] need to. For example,if [CUSTOMER X] database contains a large number of actual line items, [CUSTOMER X] canarchive these records within a given period.

If performance problems occur during the archiving of individual periods, create asecondary index in table GLPCA. This secondary index should contain all of thefields of the secondary index number 1 PCA-Oriented Index . Add the field POPER forthe period as the last field.

However, if [CUSTOMER X]r system has enough storage capacity, [CUSTOMER X] should onlyneed to archive records once a year.When [CUSTOMER X] archive plan line items, note that the system always archives and (ifcalled for) deletes the data for the entire year. [CUSTOMER X] cannot specify periods, since aplan line item record contains information from all periods.

4.2.24 PCL2: RP Cluster 2 (Human Resource Management)

PCL2 is a cluster table (RP Cluster 2) from Human Resource Management (HCM). The table isused to store several different record types, of which the largest group are Payroll AccountingResults (cluster ID based on countries) and Time Evaluation Results (Cluster B2).

4.2.24.4 Arch iving

Payroll accounting results (country-specific clusters)The payroll accounting results of the different countries are saved in country-specific clusters. Forthe US the cluster is RU, for Germany RD and for Mexico, MX, for example. To archive payrollaccounting results use archiving object PA_CALC.

Cluster B2:Cluster B2 is used to save time evaluation results. They are archived using archiving objectPA_TIME.[CUSTOMER X] can find a detailed description of the archiving process in HR and informationabout the different archiving objects in the SAP Library under SAP R/3 Enterprise, Scenarios in

Applications→ Data Archiving (CA ARC)→ Human Resources.[CUSTOMER X] can find additional information about HR archiving in the document “Archivingwith SAP HR: Overview” in the SAP Service Marketplace under /data-archiving → Media Library→

Literature & Brochures.4.2.24.4.1 Table AnalysisIf [CUSTOMER X] want to run a table analysis (transaction TAANA) before data archiving, theanalysis variant called ARCHIVE is offered for table PLC2.


http://help.sap.com/erp2005_ehp_04/helpdata/EN/35/26b53cafab52b9e10000009b38f974/content.htm

http://help.sap.com/erp2005_ehp_04/helpdata/EN/35/26b53cafab52b9e10000009b38f974/content.htm



4.2.8 COEP: CO Line Items (by Period)

The system automatically creates a CO line item for every process in which an object belongingto Controlling (for example, a sales order or cost center) is used. The line items are created inaddition to the documents for settlement or financial accounting.

See SAP Notes:

• 178921 (release-independent) gives an overview of what [CUSTOMER X] can do if tableCOEP experiences a rapid increase in the volume of data it contains.

• 138688 (SAP R/3 Release 3.0D - 4.6C) can be used to upload analysis programsRARCCOA1 and RARCCOA2 in [CUSTOMER X]r system. The two programs allow[CUSTOMER X] to do the following:

o The programs can tell [CUSTOMER X] how much data exists for an object type,a controlling area and a fiscal year.

o [CUSTOMER X] can define which archiving object should be used to remove COdata. The entries in the CO tables (COEP, COSP, COEJ...) are counted andclearly assigned to an archiving object.

Even if the results of the analysis performed with programs RARCCOA1 or RARCCOA2also include the archiving object CO_COSTCTR, [CUSTOMER X] should not use thisarchiving object to archive line items that belong to cost centers. Use the archiving

object CO_ITEM instead. CO_COSTCTR is not a good option for reducing the sizeof table COEP (also true for table COEJ).

4.2.8.1 Performance-Critical ProcessesUpdating can therefore be triggered by various processes, such as goods receipts and invoices.Depending on the settings in Customizing, at least one entry is generated in table COEP for eachdocument item in the original document.

4.2.8.2 Prevention

• It is possible to deactivate the updating of line items and totals records of reconciliationobjects to tables COEP or COSP. See SAP Note 182496.

• When [CUSTOMER X] carry out variance or WIP calculations for a new period, a largenumber of new data records is updated in CO for every production order. [CUSTOMERX] can avoid this by removing several configuration indicators, as is described in SAPNote 393686. This will also improve the performance of the archiving object forproduction orders , PP_ORDER. Records that have already been written can be deletedvia a special delete program. See SAP Note 310089.

4.2.8.3 Aggregation[CUSTOMER X] can activate aggregation for line items (see SAP Note 147766, SAP R/3 Release3.1I - 4.0B). Aggregation does not have an immediate effect on data as it only refers to futurepostings. Old documents are not affected, so archiving may still be required.[CUSTOMER X] can use line item aggregation to ensure that the system does not generate anoriginal document (for example, a material posting) for every line item in CO. Line itemaggregation ensures that selected fields no longer appear in the line item report. No other effectscan be expected as the fields do not directly affect cost accounting.

[CUSTOMER X] cannot use line item aggregation if [CUSTOMER X] use transfer

prices.

SAP Note 195480 (SAP R/3 Release 3.1I - 4.70) contains a program that simulates documentaggregation, thereby enabling [CUSTOMER X] to establish whether it is worthwhile aggregatingdocuments or not.Using inappropriate characteristics in the hierarchy definition can increase the size of tablesCOSP and COSS unnecessarily. Especially the key fields of the aggregation objects, such as“order number”, can influence table size. That is why before each aggregation [CUSTOMER X]should check which fields are actually needed in the hierarchy. Only the fields that are really




needed should be part of the aggregation. In some cases [CUSTOMER X] may also be able toremove entire hierarchy levels from the hierarchy.

4.2.8.5 Arch iving[CUSTOMER X] can use the analysis programs in SAP Note 138688 to define which archivingobjects can be used to archive the entries in table COEP. Proceed as follows:

1) Only use the archiving objects that cover the largest amount of data. Under normalconditions, 2-3 archiving objects will cover 90% of the relevant data.2) One of the relevant objects is already used (regularly). If this is the case, [CUSTOMER X]

should proceed as follows:a) Repeat the table analysis after using this object for archiving. To do this, run program

RARCCOA1 again. This should mean that considerably less data for this object willappear in the list for program RARCCOA2.

b) If, however, the same amount of data appears for the object in the list forRARCCOA2, [CUSTOMER X] should try to enhance archiving by using the object inquestion. Change some data, for example, by reducing the residence time or extend[CUSTOMER X]r selection criteria. Before doing this, however, [CUSTOMER X] mustcontact the departments concerned.

c) If the previous point does not improve the situation and [CUSTOMER X] no longerrequire the CO line items for the relevant object type, [CUSTOMER X] should markthe object type for archiving with CO_ITEM.

3) If required, [CUSTOMER X] could schedule archiving for one of the objects. Bearing thedata in table COEP in mind, [CUSTOMER X] should give this archiving job greaterpriority. Using CO_ITEM would probably be more time consuming.

4) If archiving object CO_COSTCTR appears, [CUSTOMER X] should also considerarchiving object CO_ALLO_ST. Proceed as follows:1. Schedule the program RARCCOAA as a background job to run at a time with a low

posting load.2. RARCCOAA generates a list of the entries in table COEP and COEJ. The entries

refer to allocation documents that have been cancelled. If the system returns aconsiderable number of entries, [CUSTOMER X] should use archiving objectCO_ALLO_ST.

CO_ALLO_ST can also be used when processing recent data. The archived documentsare canceled cost accounting documents. They do not influence [CUSTOMER X]r data inany way. These documents are created when, for example, data is redistributed or re-assessed.

5) If a considerable number of entries remains in the list for program RARCCOA2 or if[CUSTOMER X] have selected object types for running archiving with CO_ITEM,[CUSTOMER X] could consider implementing this archiving object.

Create a list of object types that can be archived using CO_ITEM. [CUSTOMER X] canuse the list for program RARCCOA2 when generating the list of object types, excludingeverything that has already been covered by different archiving objects.

4.2.8.5.1 Table AnalysisIf [CUSTOMER X] want to run a table analysis (transaction TAANA) before data archiving (seeChapter 2), the following analysis variants are offered for the corresponding tables:

Table Analysis Variant

COEP BUSINESS_TRANSACTION

COBK REFERENCE

See SAP Notes: •

• 200480 (release-independent): Provides help if, when using CO_ITEM, too little ornothing was archived because, for example, the wrong object type or the wrong logicalsystem was set in Customizing.




• 200513 (release-independent): Explains when entries are deleted from table COBK. Incontrast to Financial Accounting, line items in CO are archived by object rather thandocument. It can therefore occur that many document line items (such as COEP andCOEJ) were deleted, but not a single record from table COBK.

Notes on performance when using object CO_ITEM to archive data:To achieve maximum performance in the write program:

1. Start the write program for a single object type only. Enter the object type in the selectionscreen.

2. Start the write program for a single object type only.3. Archive as many periods as possible during one archiving session. We would

recommend that [CUSTOMER X] do not specify any data for “periods to” or “fiscal yearsto”. This means that only the residence times are used. We do not recommend that[CUSTOMER X] run more than one archiving session for different “periods to” or “fiscalyears to”. Restricting the period and fiscal year does not significantly improve the runtime.

If [CUSTOMER X] only want to archive plan line items (table COEJ) then it wouldnot make sense to enter a period. Plan line items are always maintained on ayear level and are only archived for fiscal years that fall into the selectioncompletely. If, for example, [CUSTOMER X] enter 2002 in period to and 6 in

posting period then the system only archives plan line items up to fiscal year2001, because 2002 does not completely fall into the selection.For more information about data management for table COEJ see Chapter 4.2.8“COEP: CO Line Items (by Period)”.

4. Do not run an archiving session parallel to CO_ITEM. Furthermore, do not start archivingsessions for CO_ITEM in parallel to runs for other archiving objects that appear in the listfor RARCCOA2.

Define the runtime according to “groups” or “sets”.If the runtime for the write program is too long (for example, it exceeds a specified time range),[CUSTOMER X] can further reduce the runtime by using the Group or set parameter. For moreinformation, see the following documentation: (Depending on the release of the system inquestion, not all options may be available in the system). F1 help for the Group or set field, on theinitial screen of the write program

• Documentation for archiving object CO_ITEM

• PDF documentation, as detailed in SAP Note 148273

It is important that [CUSTOMER X] have sufficient information about the business impact thedifferent groups or sets may have for each object type. For more information, contact the relevantdepartments.See SAP Note 148273 (SAP R/3 Release 3.0D - 4.5B): Archiving CO_ITEM: Alternative write

4.2.3 BKPF, RFBLG, Secondary Indexes (BSIS, BSAS, BSIM): AccountingDocument Tables. For Tables: BSIS, RFBLG and BKPF

FI accounting document data is stored in different tables. The most important of these are thefollowing:

• BKPF: Contains the head data of the accounting document

• RFBLG: In this table cluster the data for the document items are stored. The clusterincludes the following tables:

o BSEG (document line items and preliminary data)o BSEC (CPD data)o BSED (bill of exchange fields)o BSET (tax data)




• Secondary indexes for rapid data access:o BSIS (G/L accounts – open items)o BSAS (G/L accounts – cleared items)o BSIM (article documents in retail)

Other secondary indexes for customers (BSID, BSAD) and vendors (BSIK, BSAK) will not beconsidered further here.

BSEG and the secondary indexes are particularly affected by data growth. Document items areopen line times in table BSIS and are converted into entries for table BSAS after incomingpayment for example. This, however, is only true for entries for which the indicators Display LineItems and Open Item Management were set in the accounts master record. Table BSIS containsredundant data that is also found in table BSEG and which is processed in transaction FBL3.The performance of automatic account balancing (program SAPF124) can be improved.

See SAP Notes:

• 124560 (SAP R/3 Release 3.1H - 4.5B)

• 180595 (SAP R/3 Release 4.0A - 4.6B)

4.2.3.1 Prevention[CUSTOMER X] can counteract the marked increase in data volume in tables BSIS and RFBLGby deactivating updating for line items in G/L accounts, as the line items they contain do not need

to be updated: For example, for tax accounts, bank accounts, reconciliation accounts, all revenueaccounts (if CO-PA is used) and all balance sheet accounts.

Aggregating RFBLG also aggregates BSIS. SAP recommends that [CUSTOMER X] activate ordeactivate the updating of line items display AND the administration of open items at the sametime, if this is possible within [CUSTOMER X]r business context. See SAP Note 178487 (release-independent).Transaction OBCY can be used to activate the aggregation of FI documents depending on theprocedure used, as stated in SAP Note 36353.

4.2.3.2 Aggregation[CUSTOMER X] can only aggregate data if the FI document is not the outbound document. Datais not updated to table BSIM if aggregation has been activated. FI aggregation (of an articledocument, for example) is possible if ACCTIT is maintained at the same time.

[CUSTOMER X] can use program RSUMSIFI to simulate document aggregation. Based oncurrently available documents, it calculates what the effect of aggregation in the past would havebeen. This approximation is not useful if [CUSTOMER X]r business processes have changed(see SAP Note 310837).

See SAP Notes:

• 310837 (release-independent): Simulation for document summarization in FI

• 36353 (release-independent): FI document items are only totaled if this has been set upin Customizing for the sending application, and if the items are the same in all accountassignments. See SAP Note 117708 (see below).

4.2.3.4 Arch ivingBefore archiving, [CUSTOMER X] can use the analysis transaction FB99 to check thearchivability of individual documents. See SAP Note 99620 (release-independent).

Data is archived using archiving object FI_DOCUMNT. FI documents can still be analyzed in theirtechnical and business contexts. Secondary indexes are not archived. The data that is archived isthe head data (table BKPF) and the items data (cluster RFBLG). Data from the secondaryindexes are not archived. The post-processing program for FI_DOCUMNT, FI_DOCUMNT_PST(as of SAP ECC 6.0), deletes the secondary index tables for financial accounting and the archiveindexes for financial accounting documents. Prior to SAP ECC 6.00 the post-processing programSAPF0481 was used.BSAS entries can be deleted as soon as one of the line items from the settled item has beenarchived. BSIS entries can only be deleted if the line item indicator, but not the open itemadministration indicator has been set for the related accounts.




In the case of archiving in the context of local currency conversion, [CUSTOMER X] shouldensure that [CUSTOMER X] only archive correct open item management documents for G/Laccounts with open line item management. See SAP Note 164481 (release independent).

Appl ication-Specif ic Archive IndexFor the single document display of archived FI documents the application-specific archive index

ARIX_BKPF is used up to and including SAP ECC 5.00. As of SAP ECC 6.0 indexing occurs via

an info-structure of the Archive Information System. The latter offers considerably more benefitsthan the previous archive index option. However, it is still possible to access documents indexedwith ARIX_BKPF from earlier releasesFor older releases SAP recommends that [CUSTOMER X] use the Archive Information Systeminstead of ARIX_BKPF. For information on the prerequisites and how to switch to the ArchiveInformation System, see SAP Note 807726 (SAP R/3 4.6C, SAP R/3 Enterprise 4.70, SAP ECC5.00).4.2.3.4.1 Table AnalysisIf [CUSTOMER X] want to run a table analysis (transaction TAANA) before data archiving, theanalysis variant called ARCHIVE is offered for table BKPF.

4.2.22 MSEG – Document Segments: Material and Art icles

Table MSEG contains material document items. The document headers reside in table MKPF.

4.2.22.1 PreventionIt is not usually possible to deactivate the updating of documents. [CUSTOMER X] can, however,restrict the growth of document data in MM-Inventory Management.

4.2.22.4 Arch ivingMaterial documents are normally archived using archiving object MM_MATBEL.

Accounting documents, which are created when material documents are posted, are not archivedwith object MM_MATBEL. They are archived in Financial Accounting.

If [CUSTOMER X] archive MM documents using archiving object MM_MATBEL,[CUSTOMER X] cannot subsequently reset the MM number range if [CUSTOMER X]have not deleted or archived the corresponding data from the ACCT* tables. Otherwise,

this could lead to inconsistent data when a new MM document is created, if the ACCT*tables in which the MM document information is updated already contain an entry withthis document number (see SAP Note 83076, SAP R/3 Release 3.0C – 4.6C).

4.2.22.4.1 Table AnalysisIf [CUSTOMER X] want to run a table analysis (transaction TAANA) before data archiving, theanalysis variant called STANDARD is offered for table MSEG.

Tables[CUSTOMER X] use the archiving object MM_MATBEL to archive data from the following tables:

• MKPF (material document header)

• MSEG (material document item) A material document always consists of an MKPF record and at least one MSEG record. A

material document has no more than 500 items.If a goods receipt/issue slip or a mail message is created when a document is posted, NASTrecords (messages) also exist for the material document. NAST records are not archived, but aredeleted.

Which tables are assigned to MM_MATBEL can be viewed in transaction DB15. See Tablesand Archiving Object.

ProgramsMM_MATBEL has the following programs:


http://www.aaa.com/

http://help.sap.com/erp2005_ehp_04/helpdata/EN/8d/3e4e0c462a11d189000000e8323d3a/frameset.htm




http://www.aaa.com/



Program Function

RM07MARCS Write

RM07MADES Delete

Write programThe write program supports the ADK interruption function, which allows [CUSTOMER X] tointerrupt the write phase and start it at a later point in time. To use this function the indicatorInterruption Possible has to be set in customizing (transaction AOBJ). This parameter is not set

as a default. For more information about this function see Interrupting and Continuing Archiving Sessions.The output list of the write program also contains an output log listing the archived materialdocuments. If [CUSTOMER X] choose the parameter Detail Log in the selection screen, theprogram lists the individually selected material documents in the output log. If [CUSTOMER X] donot select this parameter, [CUSTOMER X] will get a standard summarized log. Documents thatwere selected, but not archived, because they were not completed yet, are also listed in the joblog. They are flagged accordingly.Delete programThe delete program contains the standard variants SAP&PRO (production mode) andSAP&TEST (test mode). During write and delete phases the system produces regular progressmessages in the job log and in the status line.

4.2.22 GLFUNCA: – Special Purpose Ledger: Actual line items

Archiv ing FI-SL Totals Records and Line Items (FI-SL)

Definition

[CUSTOMER X] can use archiving object FI_SL_DATA to archive totals records and line items inthe Special Purpose Ledger (FI-SL) application component.

UseWhen [CUSTOMER X] select the menu path Accounting → Financial Accounting → Special

Purpose Ledger → Periodic Processing → Archiving, FI_SL_DATA is displayed automatically and[CUSTOMER X] do not have to set this value. If [CUSTOMER X] access Archive Administrationfrom elsewhere in the system, [CUSTOMER X] need to enter the name of the archiving object.[CUSTOMER X] can use archiving object FI_SL_DATA to archive or delete totals records andline items according to [CUSTOMER X]r own specific requirements. For example, if [CUSTOMERX]r database contains a large number of journal entries, [CUSTOMER X] can archive theserecords regularly. If [CUSTOMER X]r system has enough storage space, [CUSTOMER X] needonly archive the journal entries once per fiscal year.The archiving object also enables [CUSTOMER X] to evaluate archived data. Reloading archiveddata is also possible, although this should only be done in exceptional cases.

After [CUSTOMER X] have performed a local currency changeover in [CUSTOMERX]r system it is no longer possible to reload data archived before this changeover.

Because the fiscal year is part of the totals record key, [CUSTOMER X] cannot archive totals records during the current fiscal year. If, for example, [CUSTOMER X]were to archive a totals record in May and then make new system postings in June,a new totals record would be created. This would lead to inconsistencies with thetotals record that has already been archived.


http://www.aaa.com/

http://www.aaa.com/

http://help.sap.com/erp2005_ehp_04/helpdata/EN/1f/489e3a85166506e10000000a114084/frameset.htm




http://help.sap.com/erp2005_ehp_04/helpdata/EN/8d/3e5464462a11d189000000e8323d3a/frameset.htm

http://www.aaa.com/



Structure

TablesThe archiving object FI_SL_DATA is used to archive data from different tables. In transactionDB15 [CUSTOMER X] can find out which tables are affected.

Programs

The write program supports the ADK interruption function, which allows [CUSTOMER X] tointerrupt the write phase and restart it at a later point in time. For more information about thisfunction see

Displaying a Hierarchy of FI-SL Tables[CUSTOMER X] can display a hierarchical listing of all FI-SL tables for which [CUSTOMER X]can archive data records by choosing Periodic processing > Archiving > Hierarchy on the SpecialPurpose Ledger screen.

Executing Archive ReportsIn archive reporting, [CUSTOMER X] can execute reports that evaluate archived data and/ordatabase data. [CUSTOMER X] access archive reporting by choosing Periodic processing >

Archiving > Archive reporting from the Special Purpose Ledger screen.SAP provides report programs for some of the standard tables delivered with the Special Purpose

Ledger application component (for example, GLT1, GLS1, GLP1, GLFUNCT, GLFUNCA,GLFUNCP). These generated programs allow [CUSTOMER X] to output summary reports andactual and plan line item reports. In archive reporting, [CUSTOMER X] can execute both thesegenerated programs and the reports contained in report groups that [CUSTOMER X] havecreated.

4.2.5 CKIS: Items Unit Costing/Itemization Product Costing

Table CKIS stores items unit costing or itemization product costing data. It has several dependenttables: CKIT, KEKO, KEPH and CKHS. Any SAP Notes or recommendations also pertain tothese tables.

4.2.5.1 PreventionIf [CUSTOMER X]r company works with a large number of materials for which [CUSTOMER X]do not need to create cost estimates and therefore no cost component split, then make sure that[CUSTOMER X]r system only creates cost estimates for materials which require cost componentsplitting. For example, [CUSTOMER X] only need cost estimates for material type ROH ormaterial type HAWA, if the transportation costs should be included via info records. [CUSTOMERX] have the following options to prevent the creation of cost estimates for materials:

• In Customizing, set the corresponding material type so that the system does not create acosting view for this material.

• In the material master (transaction MM02, View: Cost Estimate 1) set the indicator do notcost for raw material. This excludes the raw material from the selection and structureexplosion, and prevents a cost component split at the time of the cost estimate. If thematerial becomes part of another cost estimate as a valuation-relevant component, thevaluation price will be determined via the valuation variant if a cost estimate with thesame key does not exist for the material.

• Make sure that the corresponding materials do not enter a cost estimate run. The resultalso affects CKIS’ dependent tables mentioned above.

4.2.5.3 Deletion[CUSTOMER X] can delete cost estimates via transaction CKR1. [CUSTOMER X] can alsoarchive them, although experience has shown that it is not necessary to archive this data,because it is usually not needed anymore.




4.2.5.4 Arch ivingCKIS table entries can be archived via several archiving objects, which mainly belong to CO. Tofind out which archiving objects will be the most useful to [CUSTOMER X], analyze the table tofind out the reference objects, because the object type to which a cost estimate (and as a resultthe CKIS records) belongs, is coded into a reference object. For CKIS this reference object isCKIS-BZOBJ. [CUSTOMER X] can find a short text to the reference objects in table TCK23.

Find out which reference object has the most entries. The following table shows the referenceobjects with the most likely archiving objects that will archive or delete the entries in question:

Ref.Obj Short Text Archiving Object

0 Product Costing CO_COPC

1 Base Planning Object CO_BASEOBJ

2 Cost Center (all data) CO_COSTCTR, CC_CCTR_PL

3 Internal Order CO_ORDER

4 Customer Order/Offer SD_VBAK

6 Project PS_PROJECT

7 CO Production Order CO_ORDER

9 Cost Object CO_KSTRG

B Customer Order/Offer SD_VBAK

C Cost Center Split CO_CCTR_PL

D Component PS_PROJECT

E General Costs Activity PS_PROJECT

F Production Lot SD_VBAK, PS_PROJECT

H Message CM_QMEL, QM_QMEL

4.2.5.4.1 Table AnalysisIf [CUSTOMER X] wants to run a table analysis (transaction TAANA) before data archiving, theanalysis variant called ARCHIVE is offered for table CKIS.

Also see SAP Notes:• 559255 (release-independent): Explains what to do when [CUSTOMER X] get the error

message “Cost estimates not in archive“.




4.2.25 PPOIX/PPOPX: Posting Index of Payrol l Results

Tables PPOIX and PPOPX belong to the index that is updated when the payroll results areposted to financial accounting. The index creates a link between the employee-related payrollresults and the data of the settlement document. The index information is necessary for thedescription of the posted items. Moreover, during the posting of retroactive accountingdifferences, the index information helps [CUSTOMER X] determine what was posted originally.

Both tables can grow quite large, depending on the number of employees being processed, thenumber of payroll results per employee, the number of postings per payroll result, and the postingprocedure (number of simulation runs, number of deleted production runs).

4.2.25.1 PreventionIf production runs are executed and deleted often, a lot of index information is created. If theindex information is not deleted when the runs are deleted, because a description may be neededlater on, the index entries remain in the system. To keep the number of unnecessary productionruns as low as possible, we recommend that [CUSTOMER X] check the correctness of thedocuments through one or several simulation runs, which [CUSTOMER X] should then delete. ASof SAP R/3 4.5 it is possible to delete the index information of deleted runs using a special deleteprogram (see below).

Simulation Runs A reason for the strong growth of tables PPOIX and PPOPX could be the large number ofsimulation runs, because index information is updated during these runs. Because the run is onlya simulation, however, this index information is not used for the determination of retroactiveaccounting differences. It is only used in the short term to explain posted items. Therefore werecommend that [CUSTOMER X] delete simulation runs that [CUSTOMER X] no longer need,using program RPCIPQ00 (see below). This deletes both the document line items and the indexinformation.

Posting Runs that Are No Longer NeededPosting runs that [CUSTOMER X] no longer need can be deleted from within transaction PCP0(display of posting runs) by choosing Edit→ Delete run. Keep in mind that the deletion takesplace via the posting and that [CUSTOMER X] may encounter performance problems or evenprogram dumps, during the deletion of mass data. If [CUSTOMER X] have large amounts of data

to delete use program RPCIPDEL (see also SAP Note 161985). This does not generate anyupdate processes and should only be run in the background. After the deletion of the posting runs, [CUSTOMER X] should delete the detail information, asdescribed in the next session. Otherwise this data would remain in the database.

Detail Information for Posting RunsDetail information for simulation runs or deleted production runs can be deleted with programRPCIPQ00. This will help reduce the size of tables PPOIX and PPOPX. If [CUSTOMER X] try todelete a large number of posting runs using RPCIPQ00 [CUSTOMER X] may encounterperformance problems. To avoid this, follow the recommendation in SAP Note 428767.

4.2.25.4 Arch ivingEntries in table PPOIX and PPOPX are archived using the following archiving objects:

Archiving Object Archived Applicat ion Data

PA_PIDX HR: Index files for posting to accounting

Index files can only be archived after the payroll results have been archived using archivingobject PA_CALC. After that index files can be archived up to the retroactive accounting date.

Another archiving objects that is relevant in this context is PA_PDOC. It is used to archive thesettlement documents for posting to accounting (tables PPDIT, PPDIX, PPDMSG and PPSDST).

Archiving with PA_PDOC is very quick, because no checks are run; however, it is not possible toprocess large amounts of data with this archiving object. In terms of the archiving sequence of thedifferent data, keep in mind, that if [CUSTOMER X] archive payroll results early, [CUSTOMER X]may encounter performance problems when [CUSTOMER X] display the index data later on,because this kind of display always requires the document data, also.




Recommendation: Only archive with PA_PDOC if the indexes that belong to this session arealso being archived with PA_PIDX.

See also SAP Notes: •

• 25622: (release-independent): Archiving in HR

4.1.5 CDHDR and CDCLS: Change Documents

Change documents are used to log changes to master records, tables and documents. Allchanges in an article master, for example, are automatically updated in change documents. Allchanges to article master records during each process step are stored in the same changedocument. Changes that are made sequentially, but at different points in time, are stored indifferent change documents. Change documents are stored in tables CDHDR (header data) andCDPOS (items data). CDPOS is part of Cluster CDCLS .

4.1.5.1 Performance-Critical ProcessesExample: Listing for stores using quantity and value based Inventory ManagementChange documents for listing conditions are created for all functions in which listing conditions

are created or changed. Up to 50% of change documents can belong to listing conditions (objectWLK1) in a Retail system.

A lot of documents can also be generated when articles are changed (object MM_MATNR).

4.1.5.4 Deletion[CUSTOMER X] can delete change documents using report RSCDOK99, selecting the dataeither via Object Type or To Date. Before [CUSTOMER X] use this report, make sure[CUSTOMER X] read the corresponding program documentation.

As of SAP R/3 4.6C the report SD_CHANGEDOCUMENT_REORG is available. This report canbe used to remove change documents of already deleted sales documents from the system.

See the following SAP Notes:

• 183558 (release-independent): Change documents for sales and distribution documents

4.1.5.5

Arch iv ingChange documents are normally only archived using archiving class CHANGEDOCU togetherwith application data for which they have been generated.However, some application objects exist for a long time or are never deleted or archived (such asmaterial masters). Therefore [CUSTOMER X] can use the archiving object CHANGEDOCU if[CUSTOMER X] need to archive change documents separately from the application data.The archiving object CHANGDOCU should only be used to archive the change documents ofmaster data. Change documents of transaction data records should still be archived together withthe appropriate archiving object.4.1.5.5.1 Table AnalysisIf [CUSTOMER X] want to carry out a table analysis (transaction TAANA) before data archiving,the following analysis variants are available for use with change document tables (see also SAPNote 689036):

Table Analysis Variant

CDHDR ARCHIVE

CDPOS STANDARD1

With the field OBJECTCLAS (change document object) in table CDHDR [CUSTOMER X] can findout for which application object, for example delivery or material master, a change document wasgenerated. The corresponding plan text for an OBJECTCLAS entry can be determined usingtransaction SCDO. By choosing Change document object → Display, [CUSTOMER X] can list theaffected tables and from there deduce the archiving object. The table name is also listed in




CDPOS. If it is possible to use several archiving objects for this table, [CUSTOMER X] can usefield TCODE (transaction code) in CDHDR to trace the application in question and thecorresponding archiving object.

4.2.23 NAST, CMFP, CMFK: Message and Error Management TablesTable NAST is used to save the status records from message management. Messagemanagement is used by the SD application (for example sales, shipping, invoicing, transportationand handling units), and MM (for example inventory and purchasing), among others.[CUSTOMER X] can see which application created a message in the field NAST-KAPPL.[CUSTOMER X] can view the plain text for the application ID via transaction NACE.Tables CMFK (memory structure for the head of the error log) and CMFP (log data) are used tostore processing logs for message management and error logs from the applications. Thetable entries are organized according to their application IDs. Error logs in this table are updatedby the applications material ledger (AT), material calculation (CK), price updating (CKPF), productcost accounting (KKP), controlling summarization (KKR), among others. [CUSTOMER X] can seewhich application created the error log in the field CMFKAPLID. Data records that have APLID =WFMC originate in message management and generally appear the most frequently.

Often times tables NAST and CMFP are two of the largest and fastest growing tables in the R/3system.

To maintain data consistency these tables may only be emptied in conjunction with thecorresponding application objects. This means that when the application objects arearchived or deleted, the corresponding NAST, CMFK, and CMFP records are alsoarchived or deleted.

The following table is an overview of which archiving objects archive or only delete NAST, CMFKor CMFP records:

Archivingobject

Application NAST CMFK CMFP

Write Delete Write Delete Write Delete

MM_EKKO3 EA, EV, EF,

ELx X x X

MM_MATBEL M1, ME, MD X X X X X

MM_REBEL MR X X X X XRV_LIKP V2 X X

SD_VBAK V1

SD_VBRK V3 X X

SD_VBKA V4 X X X x

SD_VTTK V7 X X

LE_HU V6 X X X X

W_PROMO W* X x X X

CO_COPC x x

NAST records with KAPPL = V5 (SD collective processing) can only be deleted with the programfor deleting collective processing data. CMFK and CMFP records with APLID # WFMC arearchived together with the archiving object CO_COPC (product costing).

4.2.23.1 PreventionTo avoid unnecessary growth of tables CMFP and CMFK, [CUSTOMER X] can prevent thecreation of processing logs by following these steps:

2 Is defined via the parameter KAPPL‐ID in table NAST. 3 When purchasing documents are archived the status records (table NAST) are also archived. However,

the corresponding error logs remain in the database and as a result tables CMFK and CMFP could become

very full. It is possible to delete these log records using the program RSCLCMFP (see SAP Note 52114, SAP

R/3 3.0 – 4.70). [CUSTOMER X] can find the program correction in SAP Note 617634 (SAP R/3 4.6B – 4.70).




1. Call up transaction NACE (“Conditions for Output Control”).2. Choose the desired applications and then “Output Types”.3. Double click on the output type to go to the detail view where [CUSTOMER X] can

make the necessary settings. To make the settings [CUSTOMER X] must enter thechange mode.

4. Set the indicator “do not write processing log” and save [CUSTOMER X]r settings.

This setting is only applicable to the individual application and output type. If it is set, processinglogs will be collected in the main memory, but they will not be written to the database. Otheroutput types are not affected by this setting. [CUSTOMER X] have to repeat the aforementionedsteps for each output type individually. It is not possible to switch off the processing log for alloutput types at the same time. For more information on the setting “do not write processing log”see the corresponding documentation.

4.2.23.3 DeletionTo delete table entries in tables NAST or CMFK/CMFP we recommend that [CUSTOMER X]follow these steps:

1. Archive or delete the application as usual, using the relevant archiving objects or deleteprograms. This usually includes the corresponding NAST and CMF* records (for theexception see above).

2. If the NAST or CMF* tables are growing rapidly or if the application data cannot bearchived or deleted due to business-related reasons, [CUSTOMER X] can also deleteNAST and CMF* records independently from application data. The following sectiondescribes the different options for deleting these records separately:

RSCLNAST:[CUSTOMER X] can use this program to explicitly delete NAST records and the correspondingCMF* records. First [CUSTOMER X] should analyze the NAST table to see which records existfor which applications. [CUSTOMER X] should concentrate on those applications that only deletetheir NAST data during archiving. For all other applications [CUSTOMER X] should only use thedelete program if the data growth is such that deletion is unavoidable.

RSCLNAFP:[CUSTOMER X] can use this program to delete [CUSTOMER X]r log entries if [CUSTOMER X]r

CMF* table (APLID = WMFC) is growing rapidly. The corresponding NAST records remain intact.This mainly affects applications that only delete their CMF* data (transport, invoices, deliveries)during archiving. For all other applications the delete program should only be used if deletion isabsolutely necessary.Log entries are usually only deleted during the reorganization of the message status records(table NAST). This is part of the reorganization of the application documents that use messagemanagement. Independently of this reorganization, however, we recommend that [CUSTOMERX] delete the log entries regularly using program RSCLNAFP, to keep table CMFP small.

RSCLCMFP:[CUSTOMER X] can use this program to delete logs that should have a NAST record (APLID =WFMC), but for unknown reasons do not (“Phantom Logs”). This can best be tested by runningthe program in test mode.See SAP Note:

• 52114 (SAP R/3 3.0 – 4.70): Table CMFP has too many entries for APLID = WFMC

The entries in table CMFP are linked with the application object in which they originate, forexample production orders, calculations, or deliveries. When these objects are archived using therelevant archiving objects the corresponding entries in table CMFP are also archived.

Z_CMF_KKS_DELETE:Tables CMFK and CMFP are not linked to archiving objects CO_ORDER, PR_ORDER,PP_ORDER and CO_KSTRG. Therefore, log entries from applications (APLID =) KKS (variancescollective processing), KKS1 (variances individual processing) and KKP (product cost accountingand repetitive and process manufacturing) are not archived nor deleted. However, [CUSTOMER




X] can delete these entries manually using the delete program Z_CMF_KKS_DELETE. To usethe program follow the instructions in SAP Note 627257 (SAP R/3 4.6B – 4.70). Make sure that[CUSTOMER X] take the restrictions that are listed in this SAP Note into account!

SAPKKA05[CUSTOMER X] can use this program to delete CMFK and CMFP records with APLID = KKA(Unit Costing: Analysis of Results), which are not archived by either of the archiving objects,

CO_ORDER, PR_ORDER, PP_ORDER or CO_KSTRG. These table entries originate from errorlogs for results and WIP calculations.

4.2.23.4 Arch ivingEntries in table CMFP are assigned to the archiving object in which they were created, such asproduction orders, cost estimates or deliveries. When [CUSTOMER X] archive these objectsusing the corresponding archiving object, their entries in table CMFP are also archived.

Archiving Object Archived Application Data

CO_COPC Product Costing

RV_LIKP Deliveries

SD_VBAK Sales Documents

SD_VBRK Invoices

SD_VTTK SD Transports

CO_COPC Product Costing Data

4.2.23.4.1 Table AnalysisIf [CUSTOMER X] want to run a table analysis (transaction TAANA) before data archiving, theanalysis variant called STANDARD is offered for table NAST.See also SAP Notes:

• 540266 (SAP R/3 4.0B – 4.70): A solution for improving poor performance when[CUSTOMER X] run RSCLCMFP with large data sets.

4.2.20 MARC, MARD, MBEW – Material Master Data (Plant Level)

All the information a company needs to administer a material is organized in a data record in thematerial master, according to different criteria. The tables that have the potential for the strongestgrowth in this context are the following:

• MARC (plant data of material)• MARD (storage location of material)• MBEW (material valuation)• MSAT (material status)

4.2.20.1 Performance-Criti cal Processes

Listing for stores using quantity and value based Inventory Management(Retail)Use the following formula to calculate the expected volume of data:Total number of listed articles x total number of stores

(for example, 100,000 x 1000 = 100,000,000).

Note:

• If separate valuations are run, there may be more than one MBEW record assigned tothe MARC record in question.

4.2.20.5 Arch ivingMaterial master records are archived using the archiving object MM_MATNR.To archive material master records, the master record has to first be marked for deletion (“logicaldeletion”). When [CUSTOMER X] run discontinuation, deletion indicators are set in the material




master (at the appropriate level, such as plant or sales organization). When [CUSTOMER X] arerunning article discontinuation, however, [CUSTOMER X] must ensure that [CUSTOMER X] keepin mind the constraints for data integrity, for example, ensuring that [CUSTOMER X] delete all therecords in table MARD that relate to table MARC. Records that have been marked for deletioncan then be archived (“physical deletion”).Material masters (industry) do not have a residence time.

Archiving material masters is a complex task that has to be planned carefully. It is, for example,necessary to archive all other objects (such as purchasing documents) that refer to the material tobe archived, due to existing dependencies between these documents. When correcting errors,viewing the log may be a helpful task. When a material master on a specific organizational levelcannot be archived or deleted, the cause is noted in the log (for example because an order stillexists for the material). The log also contains technical data, such as the number of read ordeleted material master records.

See SAP Notes:

• 547867 (release-independent): FAQ: MM_MATNR archiving of materials• 548268 (release-independent): FAQ: Performance MM_MATNR

Steps: All the information [CUSTOMER X]r company needs to manage a material is stored in a data

record in the material master, sorted by various different criteria. When a material is no longerrequired in a company or plant, [CUSTOMER X] can archive and delete the material masterrecord. [CUSTOMER X] have the following options:

Flagging the material master record for deletionThis is known as logical deletion. Before a material master record is physically deleted by thearchive and delete program, the program checks whether the record can be deleted. Theprocedure is different for industry material master records:

1. Industry material master records

For more information on flagging material master recor ds for deletion, and the

organizational levels at which they can be deleted, see Flagging Material MasterRecords for Deletion in the SAP library documentation LO Material Master .There are no residence times for industry material master records.

Archiving and deleting the material master record directHere too, the archive and delete program first checks whether the record can be deleted.

[CUSTOMER X] can display archived data, but not reload it.

To access archiving for material master records, choose Logistics → Materials management →

Material master → Other → Archiving→ Material .

[CUSTOMER X] now have the following options (for information on procedures, see ArchivingProcedure):

Archive/delete Display archive

By selecting individual objects and choosing Continue, [CUSTOMER X] can display a list ofthe archived or deleted material master records. By further selecting individual objects,[CUSTOMER X] can display the following archived data in detail:

2. Tables

3. Long texts

4. Change documents


http://www.aaa.com/

http://www.aaa.com/

http://help.sap.com/erp2005_ehp_04/helpdata/EN/ff/515e5449d811d182b80000e829fbfe/frameset.htm


http://www.aaa.com/

http://help.sap.com/erp2005_ehp_04/helpdata/EN/8d/3e4f1d462a11d189000000e8323d3a/frameset.htm






http://www.aaa.com/

http://www.aaa.com/



Structure

TablesThe archiving object MM_MATNR is made up of all material master tables. With this archivingobject, data records are archived and deleted in these tables. For information on how to display

the names of these tables, see Tables and Archiving Objects.

ProgramsMM_MATNR contains the following programs:

Program Function

MMREO050N Write

MMREO110N Delete

Write programThe write program supports the ADK interruption function, meaning that [CUSTOMER X] caninterrupt the write phase and restart it at a later point in time. For more information on this

function see Interrupting and Continuing Archiving Sessions.In the selection screen of the write program [CUSTOMER X] can select the documents to bearchived according to material number under Materials. Under Options [CUSTOMER X] can

further restrict the selection of documents. [CUSTOMER X] can find information about thedifferent indicators in the field help. In Processing Options [CUSTOMER X] can determinewhether the write job is to start in the test mode or in the production mode. If in archiving-object-specific customizing [CUSTOMER X] set the indicator for the automatic start of the deleteprogram, [CUSTOMER X] can also indicate here that the delete program of the archiving objectshould be started with the test mode variant [CUSTOMER X] entered in archiving-object-specificcustomizing.During the write and delete runs the program produces a standard log with information about theprocessed data. In the selection screen of the programs [CUSTOMER X] can indicate that[CUSTOMER X] want a detail log. In addition to the information contained in the standard log, thedetail log also contains a list of the objects that were processed and the correspondingmessages.In the field Archiving Session Note [CUSTOMER X] can enter a short text about the archiving

session, which will help [CUSTOMER X] find and identify the session in archive managementlater.Delete programThe delete program has the standard variants SAP&PROD (production mode) and SAP&TEST(test mode). During the write and delete phases the system produces regular progress messagesin the job log and in the status line.

Integration

Before a material master record can be archived and deleted, other objects (such as purchasingdocuments) that refer to this material must themselves be archived. [CUSTOMER X] can seewhich objects these are and the dependencies between them in the network graphic.If a material master record cannot be archived and deleted at a given organizational level, thereason is given in the log (for example, a purchase order exists for the material). The log also

contains technical data such as the number of material master records read and the numberdeleted.

Other than the general settings to be made in Customizing (see Customizing), no application-specific settings are required for archiving, except the possible definition of a residence time forretail article master records (see Use above).Since material master records can be archived and deleted individually or in groups for one ormore organizational levels, it is not possible to make any general statements on runtimes andmemory requirements. The deletion run should take place as soon as possible after the archiving


http://www.aaa.com/

http://www.aaa.com/


http://www.aaa.com/

http://www.aaa.com/


http://www.aaa.com/

http://help.sap.com/erp2005_ehp_04/helpdata/EN/8d/3e4ea8462a11d189000000e8323d3a/frameset.htm

http://help.sap.com/erp2005_ehp_04/helpdata/EN/8d/3e4ea8462a11d189000000e8323d3a/frameset.htm



http://www.aaa.com/

http://www.aaa.com/

http://www.aaa.com/



run to avoid problems resulting from the materials concerned being changed or used in otherfunctions (such as goods movements) between runs.

4.2.35 VBFA: Sales Document Flow

Table VBFA contains the links between the preceding documents and follow-on documents withina sales process, such as contract, release orders, purchase order, delivery, goods issue, or billingdocuments.

4.2.35.1 Performance-Criti cal ProcessesIf a document, such as a contract or an offer, is referenced by many follow-on documents, thedocument flow can get very large. This can also negatively affect performance during theprocessing of the document and its follow-up documents.

4.2.35.2 PreventionWe recommend that [CUSTOMER X] make the appropriate customizing settings for the copycontrol for sales documents via transaction VTAA, to avoid the document flow and as a result tokeep table VBFA from growing too much. For more detailed information on how to do this, seeSAP Note 105512 (release-independent). Although this note was written for contracts, the

solution it presents can be used for all sales document types, whose direct follow-on document isneither a billing document nor a delivery.

4.2.35.5 Arch ivingEntries from table VBFA are archived via archiving objects SD_VBAK, SD_VBKA, RV_LIKP andSD_VBRK. A sales document does not only have a links record to its immediate follow-ondocument, but to all follow-on documents in the document chain. Because document flow recordsare archived together with their preceding documents, the archiving of orders has the biggesteffect on the document flow.

See also SAP Note:

• 131051 (release-independent): VBFA records remain in the system after archiving




Sequence of Objects in Archiving

For each project, [CUSTOMER X] need to determine the relevant archiving objects individually.Which archiving objects are relevant, will depend on how [CUSTOMER X]r business processesrun and how [CUSTOMER X] portray these processes in SAP. The growth of data in individualtables can vary considerably from production system to production system.

Once [CUSTOMER X] have determined the relevant archiving objects, [CUSTOMER X] need toestablish the order of the objects for [CUSTOMER X]r project. There is no set method for doingthis. [CUSTOMER X] must always agree the order [CUSTOMER X] decide on with thespecialist departments concerned.

The following table shows some sample archiving objects together with the recommended orderfor archiving:

Grp Object A ofthe Group

Object B of theGroup

Object C ofthe Group

Object D ofthe Group

Rec.d Orderof the Grps

1 MM_MATBEL MM_INVBEL MM_REBEL MM_HDEL

2 MM_EKKO MM_EBAN 2 before 3,2 before 9

3 RV_LIKP SD_VBRK SD_VBAK SD_COND

6 MM_ACCTIT 6 before 7,6 before 10

7 FI_DOCUMNT 7 before 8

8 PCA_OBJECT 8 before 9

9 CO_ITEM CO_COSTCTR CO_ML_BEL CO_ML_IDX

10 MM_MATNR

Notes:

• Suggested order within the group (objects affected are underlined).

In the case of groups in the table containing objects which are underlined, werecommend that [CUSTOMER X] archive the objects in the order they areshown. In group 9, for example, CO_ITEM should, if possible, be archived beforeCO_COSTCTR, whereas the order of CO_ML_BEL and CO_ML_IDX isinterchangeable.

• Recommended Order of the Groups




An entry in this column means that all the objects in a group should be archivedbefore the objects of another group. Therefore group 2 should, if possible, bearchived before group 9.




Slim BI

[CUSTOMER X] selected conducting a Slim BI sample POC. The duration of the task was agreedand finished in 2 days.

Check consisted of taking a Production InfoCube and slimming it down using ICM automationtools.

Steps:

• Copy selected InfoCube in Dev environment, (T-Infocube)

• Load same data into T-InfoCube

• Run Statistics on original and T-InfoCube

Findings:

• Information content: 0 loss of information data, i.e. the reports still ran with the samenumbers

• Footprint impact: 48% decrease in InfoCube footprint, decrease in InfoCube size

• Data Load impact: 47% improvement in data load time, we dropped a full load of 10million records from 2 hours and 36 minutes down to 1 hour and 22 minutes

• Query performance Impact: 38% improvement in query performance time

From an ILM point of view we managed to reduce the amount of data that required to be archivedby 48%. This correspondingly reduced administration, load and retrieval times by around 48%




ABAP Opt imization

[CUSTOMER X] selected a complex ABAP code for SOX documentation and optimization.

Steps:

[CUSTOMER X] picked a sample ABAP program that was written 6 years ago and was complex,to the point that very few developers touched it any more. The program was a finance ABAPprogram. The code was a complex 1,200 line program, with sub routines.

Findings:

Using our automated ABAP Optimizer we accomplished our task in the planned 4 hour windowand provided

1. An Optimized ABAP program. Tests indicated that1. There was ‘0’ programming compromise and components of the program

worked in accordance to the original programming.2. The program efficiency improved by 42% in performance time3. We identified 27 breaks to ‘ABAP Standards’ in the program that were

rectified automatically4. We also provided a ‘User friendly’ compliance document detailing what

the ABAP program was accomplishing at each step.2. A simple to read SOX Program audit document3. From a ILM point of view this ascertained the data integrity of all transforms and

changes as conforming to business needs and compliance requirements4. The process provided the ABAP team with an re-written ABAP program that they

reviewed and implemented in their production environment.

5. A plan was put into place to support with a strategic optimization of all ABAPprograms in the SAP landscape.