Archiving in Sap Retail
Short Description
Download Archiving in Sap Retail...
Description
Guide to Data Archiving in mySAP Retail Version 1.1
February 2001
Guide to Data Archiving in mySAP Retail
Version 1.1
Copyright © Copyright 2001 SAP AG. All rights reserved. No part of this documentation may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. SAP AG further does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP AG shall not be liable for any special, indirect, incidental, or consequential damages, including without limitation, lost revenues or lost profits, which may result from the use of these materials. The information in this documentation is subject to change without notice and does not represent a commitment on the part of SAP AG in the future. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft®, WINDOWS®, NT® and EXCEL® and SQL-Server® are registered trademarks of Microsoft Corporation. IBM®, OS/2®, DB2/6000®, AIX®, OS/400® and AS/400® are a registered trademark of IBM Corporation. OSF/Motif® is a registered trademark of Open Software Foundation. ORACLE® is a registered trademark of ORACLE Corporation, California, USA. INFORMIX®-OnLine for SAP is a registered trademark of Informix Software Incorporated. UNIX® and X/Open® are registered trademarks of SCO Santa Cruz Operation. ADABAS® is a registered trademark of Software AG. SAP, the SAP logo, mySAP.com, R/2®, R/3®, RIVA®, ABAP/4®, SAPoffice®, SAPmail®, SAPaccess®, SAP-EDI®, SAP ArchiveLink®, SAP EarlyWatch®, SAP Business Workflow®, R/3 Retail® are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. SAP AG assumes no responsibility for errors or omissions in these materials. All rights reserved.
Symbols used Symbol
Meaning Caution Example Note of particular importance
Page 2
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
Table of Contents 1
INTRODUCTION MOTIVATION TYPICAL EXAMPLES OF DATA GROWTH THE AIM OF THIS DOCUMENT OVERVIEW OF IMPORTANT INFORMATION SOURCES WHICH ARCHIVING CLASSES ARE CONSIDERED? PROJECT SET-UP AND DATA ANALYSIS
5 5 6 6 7 10
ARCHIVING OBJECTS: GENERAL INFORMATION
14
1.1 1.2 1.3 1.4 1.5 1.6 2
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 3
MM_MATNR (ARTICLE MASTER RECORDS) MM_HDEL (HISTORICAL VALUATION DATA) MM_MATBEL (ARTICLE DOCUMENTS) MM_INVBEL (INVENTORY DOCUMENTS) MM_REBEL (INVOICE DOCUMENTS FOR COMPONENT MM- INVOICE VERIFICATION) MM_EKKO (PURCHASING DOCUMENTS) MM_EBAN (ORDER REQUESTS) RL_TA (TRANSPORT DOCUMENTS FOR WAREHOUSE MANAGEMENT SYSTEM) RV_LIKP (DELIVERIES) SD_COND (CONDITION RECORDS) SD_VBRK (INVOICES) SD_VBAK (SALES DOCUMENTS) W_SOR (ASSORTMENT MODULES AND DELETING LISTING CONDITIONS) W_PROMO (PROMOTIONS) W_KALK (PRICING DOCUMENT) FI_DOCUMNT (FINANCIAL ACCOUNTING DOCUMENTS) MM_ACCTIT (FOLLOW-UP POSTING FROM MATERIALS MANAGEMENT) SELECTED CO OBJECTS CO_COSTCTR (COST CENTER DATA – ALL DATA INCLUDING MASTER DATA) CO_ITEM (CO LINE ITEMS) CO_ML_BEL (MATERIAL LEDGER DOCUMENTS IN THE COMPONENT ACTUAL COSTING/MATERIAL LEDGER) CO_ML_IDX (MATERIAL LEDGER INDICES FOR COMPONENT ACTUAL COSTING – MATERIAL LEDGER)
INTRODUCTION 1.1 1.2 1.3 1.4 1.5 1.6
2
PRELIMINARY NOTE ON EURO CONVERSION THE MOST IMPORTANT PROGRAMS IN AN ARCHIVING OBJECT ARCHIVE EVALUATION USING THE SAP ARCHIVE INFORMATION SYSTEM DEPENDENCIES BETWEEN ARCHIVING OBJECTS SEQUENCE OF OBJECTS IN ARCHIVING RESIDENCE TIMES ARCHIVING CUSTOMIZING SAMPLE SELECTION IN AGREEMENT WITH THE USER DEPARTMENTS PERFORMANCE IN ARCHIVING SPECIFIC INFORMATION FOR EACH ARCHIVING OBJECT
DETAILED INFORMATION FOR EACH ARCHIVING OBJECT 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22
1
5
14 14 15 16 17 17 18 18 18 19 20 20 21 21 22 22 23 24 24 25 25 26 27 28 28 29 29 30 31 31 32 33 33 4
MOTIVATION TYPICAL EXAMPLES OF DATA GROWTH THE AIM OF THIS DOCUMENT OVERVIEW OF IMPORTANT INFORMATION SOURCES WHICH ARCHIVING CLASSES ARE CONSIDERED? PROJECT SET-UP AND DATA ANALYSIS
4 4 5 5 6 9
ARCHIVING OBJECTS: GENERAL INFORMATION
13
2.1 2.2 2.3 2.4 2.5
© SAP AG
PRELIMINARY NOTE ON EURO CONVERSION THE MOST IMPORTANT PROGRAMS IN AN ARCHIVING OBJECT ARCHIVE EVALUATION USING THE SAP ARCHIVE INFORMATION SYSTEM DEPENDENCIES BETWEEN ARCHIVING OBJECTS SEQUENCE OF OBJECTS IN ARCHIVING
13 13 14 14 15
Page 3
Guide to Data Archiving in mySAP Retail
2.6 2.7 2.8 2.9 2.10 3
Version 1.1
RESIDENCE TIMES ARCHIVING CUSTOMIZING SAMPLE SELECTION IN AGREEMENT WITH THE USER DEPARTMENTS PERFORMANCE IN ARCHIVING SPECIFIC INFORMATION FOR EACH ARCHIVING OBJECT
16 16 17 17 18
DETAILED INFORMATION FOR EACH ARCHIVING OBJECT
19
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22
Page 4
MM_MATNR (ARTICLE MASTER RECORDS) MM_HDEL (HISTORICAL VALUATION DATA) MM_MATBEL (ARTICLE DOCUMENTS) MM_INVBEL (INVENTORY DOCUMENTS) MM_REBEL (INVOICE DOCUMENTS FOR COMPONENT MM- INVOICE VERIFICATION) MM_EKKO (PURCHASING DOCUMENTS) MM_EBAN (ORDER REQUESTS) RL_TA (TRANSPORT DOCUMENTS FOR WAREHOUSE MANAGEMENT SYSTEM) RV_LIKP (DELIVERIES) SD_COND (CONDITION RECORDS) SD_VBRK (INVOICES) SD_VBAK (SALES DOCUMENTS) W_SOR (ASSORTMENT MODULES AND DELETING LISTING CONDITIONS) W_PROMO (PROMOTIONS) W_KALK (PRICING DOCUMENT) FI_DOCUMNT (FINANCIAL ACCOUNTING DOCUMENTS) MM_ACCTIT (FOLLOW-UP POSTING FROM MATERIALS MANAGEMENT) SELECTED CO OBJECTS CO_COSTCTR (COST CENTER DATA – ALL DATA INCLUDING MASTER DATA) CO_ITEM (CO LINE ITEMS) CO_ML_BEL (MATERIAL LEDGER DOCUMENTS IN THE COMPONENT ACTUAL COSTING/MATERIAL LEDGER) CO_ML_IDX (MATERIAL LEDGER INDICES FOR COMPONENT ACTUAL COSTING – MATERIAL LEDGER)
19 19 20 21 21 22 22 23 23 24 25 26 26 27 27 28 29 29 30 30 31 32
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
1 Introduction 1.1 Motivation Within the business context, large quantities of data are often created over short periods of time. Database growth can, regardless of master data, Customizing settings, and business processes, be in the region of several GB per day. You are advised to check all data with a view to prevention, summarization or simply deletion. Data archiving deals with data that cannot be prevented or simply deleted. You are advised to consider your archiving requirements at the business blueprint stage. Regrettably, in practice, many companies do not develop an archiving concept until after the live system’s database shows the first signs of bottlenecks. In such cases, the archiving concept often has to be elaborated under extreme time pressure. Archiving at an early stage enables you to keep the size of your database under control and creates an appropriate environment in which to consider back-up needs and optimal performance.
1.2 Typical Examples of Data Growth
© SAP AG
Name
Size (GB)
Monthly growth (GB)
Description
MSEG
19.9
2.8
Document Segment: Material
MARC
19.7
1.9
Plant Data for Material
COEP
16.5
2.0
CO Object: Line Items (by Period)
MBEW
13.1
1.2
Material Valuation
VBRP
12.9
1.6
Billing: Item Data
MBEWH
8.9
0.8
Material Valuation: History
EKPO
8.7
1.1
Purchasing Document Item
CDCLS
7.7
1.2
Cluster structure for change documents
WLK1
6.9
0.7
Listing conditions SAP Retail Assortments
LIPS
5.8
0.8
SD document: Delivery: Item data
MARD
5.7
0.5
Storage Location Data for Material
VBFA
5.7
0.7
Sales Document Flow
KOCLU
5.2
0.7
Cluster for conditions in purchasing and sales
CDHDR
4.6
0.8
Cluster structure for change documents
RFBLG
3.5
0.4
Cluster for accounting document
EDI40
3.3
0.4
IDoc data records
EKBE
3.2
0.5
History per Purchasing Document
BSIS
2.9
0.1
Accounting: Secondary Index for G/L Accounts
EKET
2.3
0.3
Scheduling Agreement Schedule Lines
VRPMA
2.0
0.3
SD Index: Billing Items per Material
MLIT
2.0
0.1
Material Ledger Document
BKPF
1.8
0.2
Accounting Document Header
Page 5
Guide to Data Archiving in mySAP Retail
Version 1.1
This table contains a selection of fast-growing tables and their monthly growth. The data comes from a system that has been live for about six months. Some tables, such as MARC, grew especially fast in the first few months. Since the distribution changes went live gradually, the monthly growth rates were determined from the average over the last three months.
1.3 The Aim of this Document This document is designed to provide an introduction to archiving in the business context for consultants and customers, and to address issues related to the development of an archiving concept. Typical data, archiving objects, and process examples from SAP Retail have been selected as an illustration. The examples are intended as a guide, and are not intended to be applied directly to specific projects. This document, the selection of archiving objects described, and the recommendations it contains, are not exhaustive. Consequently, it does not cover all archiving objects and Notes. The contents of this document apply to SAP Releases from 4.0. This document complements the information contained in Planning and Implementing SAP Archiving Projects (available in SAP Service Marketplace, for the location, refer to the section Overview of Important Information Sources), which you are strongly advised to read before carrying out an archiving project.
1.4 Overview of Important Information Sources 1.4.1 SAP Notes Check regularly for new SAP Notes in SAP Service Marketplace or in the Online Service System relating to archiving. Enter a search criteria such as “Archiving”, “ADK”, or the name of the relevant archiving object. Unfortunately, SAP Notes do not always list the archiving objects. You are therefore advised to enter the name of the archiving object in combination with the name of the accompanying write, delete, preprocessing or reload program (search with OR operation.) You can find the name of the program in transaction AOBJ by double clicking the archiving object. In some cases, it is advisable to enter the terms “Archiving”, “adk” or “SARA” with an AND operation (for example, the term “IDOC” refers not only to the archiving object, but also IDocs.) When you create customer messages on archiving objects, the assignment restricts the processing to the correct component. Note 102446 lists all archiving objects with their components.
1.4.2 SAP Service Marketplace •
For important information on archiving, refer to: http://service.sap.com/data-archiving. The following documents deal especially with the design and implementation of archiving projects. They are stored under Media Center → Literature.
-
Planning and Implementing SAP Data Archiving Projects This document provides a comprehensive description of the archiving procedure. You can also refer to the Best Practices Model.
-
Data Prevention Checklist This document is of particular relevance to SAP Retail projects. It demonstrates ways in which data can be reduced before archiving. Data that can be prevented in the first place does not need to be archived.
•
For important information on Performance issues, refer to: http://service.sap.com/performancemap
1.4.3 SAP Library For a comprehensive description of each archiving object, refer to the SAP Library, under CrossApplication Components à Archiving Application Data (CA-ARC.)
Page 6
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
1.4.4 Courses SAP offers the following courses on Data Archiving: •
BC 660 Data Archiving This course gives an overview of archiving objects, Customizing for archiving, and the development of archiving projects.
•
BC 670 ADK – Programming Display Functionality This course explains the structure and creation of archiving and delete programs. The SAP Archive Information System (SAP AS) and its use are also discussed.
1.5 Which Archiving Classes are Considered? The following table shows a selection of typical archiving objects that are used in SAP Retail projects. The list is not exhaustive. Archiving object
Description
Read program (Access to archived data)
Component abbreviation
SAP Component
MM_MATNR
Article master records
MMREO120
MM-IM
Inventory Management
MM_HDEL
Archiving program for MBEWH, QBEWH, EBEWH (Historical valuation data)
Access with SAP AS only (see note)
MM-IM
Inventory Management
MM_MATBEL
Article documents
RM07MAAU,
MM-IM
Inventory Management
RM07MAAT MM_INVBEL
Inventory documents
RM07IAAU
MM-IM
Inventory Management
MM_REBEL
Invoice documents
RM08RAAU
MM-IV
Inventory Verification
MM_EKKO
Purchasing documents
RM06ER30
MM-PUR
Purchasing
MM_EBAN
Purchase requisitions
RM06BR30
MM-PUR
Purchasing
RL_TA
Transfer orders
RLRT0001
LE-TRA
Transport
RV_LIKP
Deliveries
S3LIKPAU
LE-SHP
Shipping
SD_COND
Condition records for pricing
Access with SAP AS only (see note)
SD-BF-PR Conditions and Pricing
SD_VBRK
Invoices
S3VBRKAU
SD-BIL
Invoicing
SD_VBAK
Sales documents
S3VBAKAU
SD-SLS
Sales
W_SOR
Assortment modules and listing conditions
Access with SAP AS only (see note)
LO-MD
Basic Data Logistics
W_PROMO
Retail promotions
W_PROMO_ARCH_READ
LO-MD
Basic Data Logistics
W_KALK
Pricing documents
RWVKPAR1
LO-MD
Basic Data Logistics
FI_DOCUMNT
Financial Accounting documents
RFBELJ00, RFEPOJ00, RFKKET00, RFKLET00, RFUSVB10, RFUSVS10, SAPF048A,SAPF048L, SAPF048S, SAPF048Z
FI
Financial Accounting
MM_ACCTIT
Subsequent posting data for accounting I/F
Access with SAP AS only (see note)
FI-GL-GL
G/L Accounting: Basic functions
© SAP AG
Page 7
Guide to Data Archiving in mySAP Retail
PCA_OBJECT
Totals records and line items in EC-PCA
Version 1.1
EC-PCA
Profit CenterAccounting
EC-PCA
Profit CenterAccounting
RGUGLPCT
EC-PCA
Profit CenterAccounting
CO_COSTCTR Cost center - all data (incl.center master)
RKSARCS1
CO-OMCCA
Cost CenterAccounting
CO_ITEM
CO line items
RKCOITS4
CO
Controlling
CO_ML_BEL
Material ledger documents
SAPRCKMX_LESEN
CO-PCACT
Actual Costing/ Material Ledger
CO_ML_IDX
Index entries material document
SAPRCKML_LESEN
CO-PCACT
Actual Costing/ Material Ledger
(up to Release 4.6A) EC_PCA_ITM
Profit ctr. accounting: actual and plan line items
RGUGLPCA RGUGLPCP RGUGLPCT RGUGLPCA RGUGLPCP
(from Release 4.6A) EC_PCA_SUM Profit Center Accounting: Summary Records (from Release 4.6A)
Notes: •
All the archiving objects listed above can, as an alternative, be accessed using SAP AS. SAP AS is particularly useful for analyzing archive files if no read program exists.
•
From Release 4.6A, archiving object PCA_OBJECT replaces EC_PCA_ITM and EC_PCA_SUM.
1.5.1 Archiving Objects Developed for SAP Retail Archiving object
Description
Component abbreviation
Components
W_SOR
Object for listing condition + modules
LO-MD
Basic Data Logistics
WS_ACSITE Retail: Site master record
LO-MD
Basic Data Logistics
W_KALK
Pricing: Pricing documents
LO-MD
Basic Data Logistics
4.0A
W_PROMO
Retail: Promotion
LO-MD
Basic Data Logistics
4.6A (Retrofit possible, see Note 202307)
WBU
Retail: Posting list
LO-AB
Agency Business
X
4.5A
WRECH
Retail: Invoice lists
LO-AB
Agency Business
X
4.5A
WREG
Retail: Payer request lists
LO-AB
Agency Business
X
4.5A
WZR
Retail: Payer request lists
LO-AB
Agency Business
X
4.5A
WLF
Retail: Vendor billing document
LO-AB
Agency Business
X
4.5A
WTADDI
Retail: Additional
LO-ADM
Additionals Management
X
4.5A
W_VKAB
Retail: Sales value change documents
MM-IM
Inventory Management
X
4.5A
Page 8
Not Available from covered in Release this document 4.0A X
4.0A
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
Some of the above archiving objects are not covered in this document for the following reasons: •
WBU, WRECH, WREG, WZR, WLF These objects are only required for an agency business. This is not normally the case in an SAP Retail project. Additionally, the object WLF is relevant for subsequent settlement. If you use subsequent settlement, refer to SAP Note 180434 (Release 3.0D – 4.5B), which activates additional checks for archiving settlement-relevant documents, such as purchase orders and vendor billing documents.
•
WS_ACSITE Site master records usually have a longer retention period. They usually represent a relatively small volume of data (for example, in comparison to article master data and material documents.) Consequently, they only need to be archived at infrequent intervals.
•
WTADDI, W_VKAB These documents do not usually represent large volumes of data. You only require the object WTADDI if you use sales additionals.
1.5.2 What this document does not cover 1.5.2.1 Archiving IDocs, Workitems and Change Documents Large data volumes can arise in all three areas in a SAP Retail system. For example, large numbers of IDocs and workitems are created during the processing of sales data using the POS interface-inbound. A large proportion of this data can be removed from the system after a short period (usually after a few days.) Some data can be deleted, thereby obviating the need for archiving. For more information, refer to the Data Prevention Checklist in SAP Service Marketplace under the alias dataarchiving and in the SAP Library under Logistics à SAP Retail à Distributed Data Processing à POS Interface à POS Interface: General Information à Archiving and Deleting in the POS Interface. Change documents are usually only archived in the application for which they were generated using the archiving class CHANGEDOCU. However, since there are application objects that are required for a particularly long period, or that are never archived or deleted, such as the article master, the object CHANGEDOCU was created, which archives change documents independently of application data. CHANGEDOCU is not supplied with the standard system, but it is available in SAP Note 140255 (Release 3.00 - 4.6A; Application-indep. archiving of change documents.)
1.5.2.2 Data from RIS (Retail Information System) This data is stored in table Snnn. You can no longer delete required data in Copy Management. Whether you delete or archive data is an organizational issue that you need to deal with on an individual basis. You can archive data that is required over longer periods. An archiving object is generated for each structure. The archiving object contains the name of the structure (Object MC_Snnn) You use transaction MCSX (path: Retail → Info systems/Planning → Retail → Environment → Archiving → Statistics) to generate an archiving object for a specific information structure. You must only reload archived data if it was archived incorrectly. Reloading data should not be reloaded into the system for later reporting purposes. For more information, refer to the Data Prevention Checklist (available in SAPNet under the alias dataarchiving.) 1.5.2.3 Customer-Specific Tables In projects, some customer-specific tables are created that are used, if required, for customer-specific archiving objects. This document does not provide detailed information on the customer-specific archiving objects. You can also include customer-specific tables in standard archiving objects.
© SAP AG
Page 9
Guide to Data Archiving in mySAP Retail
Version 1.1
You must not change the archiving objects supplied by SAP. If you want to include customerspecific tables, you must make a cope of the standard archiving object in the customer namespace (for example Z_MM_MATNR.) You can use the Archive Development Kit (ADK) as a development tool for customer specific archiving programs. The ADK consists of function modules that you can use to develop your own archiving solutions. For more information, refer to the SAP Library under Basis Components à ABAP Workbench (BC-DWB) à BC Extended Applications Function Library à Data Archiving – ADK.
1.6 Project Set-Up and Data Analysis 1.6.1 Checklist for Planning an Archiving Project In terms of general planning, there are no retail-specific requirements. A retail project must pay particular attention to performance issues (see also the section Performance and Archiving.) When testing, you should check the performance of archiving sessions as well as the archiving functions themselves. There are various SAP Notes offering information on improving the performance of various objects. Ensure that you consider system utilization when scheduling archiving jobs. Process step
Notes
1. Analysis: Analyze database and identify archiving objects
Analysis clarifies the following issues: (For more information, refer to the section Analysis) •
How large are the tables?
•
What growth rates are involved?
•
How many entries do the tables have?
•
Which archiving objects are to be used?
2. Carry out consistency checks
Resolve analysis inconsistencies between MM and FI to enable the archiving of the relevant objets. If the report RM07MBST identified differences, implement SAP Note 116601 and observe the customer check list for inconsistencies in Note 76926
3. Run house-keeping jobs for data prevention
Refer to the information in the Data Prevention Checklist (in SAP Service Marketplace at http://service.sap.com/data-archiving under Media Center → Literature)
4. Hold kick-off event
Kick-Off items:
a. Determine contact persons
b. Determine system environment
Page 10
•
Present results of analysis to the customer.
•
Discuss the archiving concept with the customer.
•
Clarify points 4a – 4c.
The selection of contact persons must reflect the cross-applicational process changes: •
Project management
•
System administration
•
Application managers
•
Contact persons for audit-specific requirements
Determine the following: •
What R/3 Release is being used?
•
Which support package is available?
•
Which database is being used?
© SAP AG
Version 1.1
c.
Agree time-frame for schedule
5. Define requirements of archived data and archiving objects
Guide to Data Archiving in mySAP Retail
•
What operating system is being used?
•
What hardware upgrades have been carried out?
•
What R/3 upgrades have been carried out?
•
Has a local currency conversion been carried out?
•
Is an external storage system being used?
Agree the project plan •
Documentation concept
•
Business and technical concept
•
Archive management
Business considerations: •
Access requirements for archived data
•
Residence times
•
Authorization concept
•
Local currency conversion
•
Archiving cycle
Technical considerations: •
Selection criteria for archiving sessions
•
Dependencies between data objects
•
Audit-relevant technical settings for each archiving object
•
Postprocessing for archiving objects
•
Type and frequency of access to the storage system or other storage medium
•
Other activities in addition to archiving
6. Develop sequence concept
Establish process sequence for archiving objects
7. Consider SAP Notes
Determine and implement relevant notes
8. Make configuration and Customizing settings
Make the following settings:
9. Carry out archiving in test system
•
Create logical and physical file names (per object) and paths (transaction FILE/SF01)
•
(If an external storage system is used) Set up the interface to the external storage system using ArchiveLink → transaction OA+ carry out checks.
•
Basis Customizing
•
Application-specific Customizing (commit counter, file size, start indicator, variants for delete programs)
Carry out archiving in test environment. You are advised to carry out the entire archiving process (including deletion), as in a live system.
a. Test archiving functions
In transaction SARA, test archiving functions using archiving object EXAMPLE.
b. Run write and delete programs
These tests focus on the following functions:
© SAP AG
•
Create variants for write programs
•
Access and access times (if required, search and include Notes to optimize system performance)
Page 11
Guide to Data Archiving in mySAP Retail
c.
Log archiving results
d. Analyze and process error list and 10. Check technical concept
Version 1.1
•
Backup
•
Authorization concept
Record the following data: •
The number of data objects archived
•
The size of the archive files
•
The runtimes – this provides an approximate guide for runtimes in the live system
Resolve errors in collaboration with consulting team. The concept covers the following areas: •
Reorganizing the database
•
Building an index
•
Including an external archiving solution
11. Determine the archiving cycle and variants
Define variants based on information obtained from the analysis and test results.
12. Prepare live system for archiving
•
Carry out transports.
•
Copy Customizing settings from the test system.
13. Carry out archiving in the live system
Carry out archiving in the live environment
a. Test archiving functions
In transaction SARA, test archiving functions using archiving object EXAMPLE.
b. Release live archiving: Carry out write jobs.
Schedule and run archiving programs. Especially in the Retail environment, job scheduling must take system utilization into consideration.
c.
You are strongly advised to back up archive files before running the delete programs.
Carry out backup
d. Schedule and run delete programs 14. Project documentation
Archiving and deletion should always occur in two distinct steps. A final report should summarize the most important points of the project.
1.6.2 Including the User Departments Obtaining information from the IT department, the user departments and management is essential when creating an archiving concept. Discussions with the key players have to be conducted and carried out systematically. Each business process can affect several user departments due to the dependencies that exist between the process data. Consequently, several departments must work together to decide how archiving is to be carried out for an archiving object. It is important to clarify the lines of responsibility of those involved in the archiving concept. Inter-departmental co-operation and support must be especially emphasized if the customer is operating in more than one location.
1.6.3 Analysis Help The standard system contains various tools for data analysis. These are described in more detail in the following sections.
Page 12
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
1.6.4 Analysis from the Technical View The technical view determines the fastest growing tables and assigns archiving objects to them. A table can be assigned to several archiving objects (for example, table COEP in CO.) If this is the case, you must use application-specific analysis programs to determine the correct object in each case. You can find various tools to analyze the database under Tools à CCMS (Computer Center Management System.) The following transactions are important analysis tools: •
Transaction DB02 This transaction provides an overview of the size of your tables. This information is displayed independently of the type of the database.
•
Transaction DB15 This transaction displays the assignment of tables to archiving objects and vice-versa.
•
Transaction DB20 This transaction enables the database administrator to update the statistics for individual tables, for example, after the number of lines has been substantially reduced.
•
Transaction AOBJ This transaction is used to configure archiving objects. If you have the correct authorization, you can use the maintenance view to display the archiving objects that are available in the system.
•
Transaction ST14 You can use this transaction to create application-dependent analyses using specific functions – this gives an overview of the data volumes involved. In SAP Retail, for example, this enables you to analyze the assortment planning. This transaction analyzes the store-related key figures, that is, the number of articles listed, the number of articles with evaluated/freely available stock, the number of articles with transactions. In Materials Management, for example, you can use this transaction to determine document runtimes.
•
Transaction TAANA From Release 4.6C, you can use this analysis transaction to count table entries. Depending on the analysis type, the number of entries are assigned to specific field value combinations. Example: Analysis type ARCHIVE determines the number of entries in the table BKPF that contain entries in the fields MANDT, BUKRS, GJAHR, and BLART. Transaction SE16 This transaction enables you to count table entries in releases before 4.6C.
1.6.5 Analysis from the Business View Here, the data in the system is analyzed to ensure consistency. Some tables can be edited with analysis tools that are available in the standard system. The following programs are particularly important: •
RARCCOA1/RARCCOA2 - CO Table Analysis - Generate Data Extract The programs RARCCOA1 and RARCCOA2 analyze certain tables in the preparatory phase for archiving CO data. You are advised to use these programs so that you can see easily which of the archiving objects are to be used in each case. You can use SAP Note 138688 (Release 3.0D - 4.6B) to import analysis programs RARCCOA1, RARCCOA2, RARCCOAA, and RARCCOAAP
•
RARCCOAA - CO Table Analysis for Archiving Object CO_ALLO_ST This program analyzes certain CO tables in the preparatory phase for archiving CO data. It is useful if you want to estimate what effect certain selection criteria would have on the number of archived records in certain tables for the archiving object CO_ALLO_ST.
•
RARCCOAP - CO Table Analysis for Archiving Object CO_CCTR_PL
© SAP AG
Page 13
Guide to Data Archiving in mySAP Retail
Version 1.1
This program analyzes CO tables in the preparatory phase for archiving CO data. This program is useful if you want to estimate the effects of your selection criteria on the number of archived records in certain tables. •
RM07MBST – Analysis of Inconsistencies Between MM and FI You can use this program to establish whether your system has inconsistencies regarding stock quantities and values.
•
ZAGLPCA / ZAGLPCA2 – Analysis of Profit Center Data You can use the programs ZAGLPCA1 and ZAGLPCA2 to estimate, within the context of archiving profit center data, the data volume to be archived by activating certain selection criteria, and to determine which archiving objects you can use to archive the data. You can import this program using SAP Note 203545 (Release 3.0F – 4.0B.)
2
Archiving Objects: General Information
2.1 Preliminary Note on Euro Conversion SAP recommends that you carry out analysis of euro conversion before archiving. Some objects are critical to euro conversion. The table ADMI_CRIT (SE16) provides an overview of critical archiving objects and functions that can be used in relation to a planned euro conversion. You must not, in any circumstances, change the settings for the table ADMI_CRIT, otherwise this may lead to inconsistencies in the database. Problems that occur in the analysis phase can, in some circumstances, only be resolved if all the documents remain in the system. If you think that the time frame for the table conversion (system lock period) may not be long enough, you should check whether it is advisable to start an archiving project in advance of euro conversion. For more information on currency conversion, refer to: •
•
Important Notes: -
93697, (Release 3.1I - 4.6B) Euro changeover and archives
-
99059, (Release 3.1I - 4.5B) Critical archiving objects for euro changeover
Overview of local currency changeover see SAP Service Marketplace, Address: http://service.sap.com/euro
•
Guide SAP Data Archiving and the Euro see SAP Service Marketplace, Address: http://service.sap.com/data-archiving, under Media Center → Literature
The Guide SAP Data Archiving and the Euro (Version 3.0) was published in February 2000. It provides detailed information on the most important archiving objects for the individual applications and lists the SAP Notes relevant for an archiving project. You can significantly restrict the search for relevant Notes in line with your project area and release status.
2.2 The Most Important Programs in an Archiving Object •
Preprocessing program (optional) Some archiving objects have a preprocessing program that prepares data, by marking it for deletion, for example. The preprocessing program does not, however, remove any data from the database.
Page 14
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
Note: The preprocessing programs in the SD objects RV_LIKP, SD_VBRK and SD_VBAK are not checking programs. They are similar to test runs in other components and set neither deletion indicators nor deletion flags. They enable you to evaluate the quality of the sales documents for archiving and of the application-specific Customizing. •
Archiving program (Write program) This program writes the data for archiving to newly created archive files. However, the data is not yet removed from the database. In archiving-specific Customizing, you can specify whether the next step (deletion) is to take place automatically after the creation of the archive files.
•
Delete program This program deletes the data from the database that has been replicated to archive files. From Release 4.6C, you can specify a sequence for the transfer of data to the storage system – that is, whether the deletion phase is to occur before storage, or vice-versa. You make this setting in the transaction AOBJ in Customizing settings for the relevant archiving object.
•
Reload program (optional) The reload program is only to be used in emergencies, and is not recommended. You should only reload data immediately after archiving. Not all archiving objects have a reload program.
•
Read program for an archiving object (optional) Some programs have their own read programs (such as SD_VBRK, W_PROMO.) For objects that do not have their own read programs, you can, as an alternative, use the SAP Archive Information System (SAP AS.) You access the read program using the Evaluate function in transaction SARA. For more information, refer to the following section.
2.3 Archive Evaluation Using the SAP Archive Information System From Release 4.5A, SAP AS has been part of the standard system and can also be installed on releases down to 3.0D (see SAP Note 99388, Releases 3.0D - 40B, Preliminary transport of Archive Info. System.) The SAP AS tool is fully integrated into the archiving environment and enables you to carry out searches in R/3 data archives. It supports you as you search for archived data and offers various functions for the display of this data. In addition to the technical view, you can also create a business view of the data. In some circumstances, document flow information is required when searching for an archived document using SAP Archive Information System. When constructing a business view, you should check whether it is possible to display or navigate between all the data relating to a document flow in its original business context. This is known as process-oriented retrieval. From Release 4.6A, SAP AS includes various function modules to enable process-oriented retrieval. For more information, refer to the SAP Library.
In earlier releases, process-oriented retrieval is effected in a different way. For example, business views for the objects RV_LIKP, SD_VBRK and SD_VBAK are realized using SAP Note 140652. This can be applied to release statuses down to 3.0D. Process oriented retrieval for the SD documents customer orders, deliveries, and invoices rd (archiving objects SD_VBAK, RV_LIKP, SD_VBRK) will be replaced in the 3 quarter of 2000 by a modification-free solution. For more information on SAP AS, refer to the following: •
The document Planning and Implementing SAP Archiving Projects (available in SAP Service Marketplace – enter the alias data-archiving.)
© SAP AG
Page 15
Guide to Data Archiving in mySAP Retail
Version 1.1
•
The SAP Library under Archiving Application Data (CA-ARC) à Introduction to Data Archiving(CA-ARC) à Archiving Information System (SAP AS.)
•
Training course BC670
2.4 Dependencies Between Archiving Objects You must observe dependencies between data when planning your archiving project so that information that is required for ongoing business is still accessible. By carefully selecting an appropriate sequence, you can, in some cases, reduce the number of checks that are necessary and thereby optimize archiving performance. For more information on the best archiving sequence, refer to the relevant network graphic for the object (display in transaction SARA) and the SAP Library. You must agree on the archiving sequence with the relevant user departments. It is not possible to describe all the dependencies here. The following is an overview of the main dependencies and conditions: •
Transaction data is to be archived before master data. Master data, such as article master records, can normally only be archived if they no longer occur in transaction data, such as orders. In some archiving objects for master data, such as SD_COND, it is possible to deactivate the check for available transaction data.
•
MM transaction data is to be archived before SD transaction data. In SD archiving, it is possible to activate the check for available MM documents.
•
Deliveries are to be archived before order and invoice documents. When displaying delivery documents, the system accesses order data. It is not possible to display deliveries if the order document is no longer available. The following rules apply for the archiving sequence in SD: 1. First, archive deliveries. 2. Then archive the other SD documents in reverse sequence from the normal business process.
•
SD invoices are to be archived before SD orders. Otherwise, invoices cannot be displayed in future, since the document with the referenced text is missing.
When using SD archiving objects RV_LIKP, SD_VBRK, and SD_VBAK, SAP Note 129310 (Release 3.0D - 4.5B) supports the correct referencing of texts. •
An action, for which there are subsequent documents, cannot be archived until the accompanying subsequent documents have been archived.
•
Usually, FI and CO data can be archived independently of MM and SD data. Exceptions: -
CO commitments are updated from MM. In this case, you should archive MM data before CO data.
-
MM subsequent posting data is updated.
In the standard system, MM subsequent posting data is updated automatically (object MM_ACCTIT.) The MM subsequent posting data should then be archived before the remaining FI data. Note:
Page 16
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
You can also deactivate the creation of subsequent posting data (see also details on object MM_ACCTIT in this document and SAP Note 48009.)
2.5 Sequence of Objects in Archiving The following illustrates the recommended archiving sequence for the archiving objects that have been used as examples in this document:
Groups
Object D in group
Recommended Recommended group group sequence sequence
Object A in group
Object B in group
Object C in group
1
MM_MATBEL
MM_INVBEL
MM_REBEL MM_HDEL
2
MM_EKKO
MM_EBAN
3
RV_LIKP
SD_VBRK
SD_VBAK
4
RL_TA
5
W_SOR
W_PROMO
W_KALK
6
MM_ACCTIT
6 before 7, 6 before 10
7
FI_DOCUMNT
7 before 8
8
PCA_OBJECT
8 before 9
9
CO_ITEM
10
MM_MATNR
A, B
SD_COND
CO_COSTCTR CO_ML_BEL CO_ML_IDX
2 before 3, 2 before 9
A, B, C, D
A, B, C
A, B
Notes: •
Recommended sequence in the group (relevant objects shaded) In this case, you are advised to archive the objects for the relevant group according to the specified sequence. This means that in group 9, for example, CO_ITEM should, if possible, be archived before CO_COSTCTR, whilst the sequence of CO_ML_BEL and CO_ML_IDX can be swapped.
•
Recommended group sequence An entry in this column means that all objects in one group should be archived before the objects of another group. For example, group 2 should, if possible, be archived before group 9.
2.6 Residence Times Residence times of data to be archived differ according to project, and depend on various parameters, such as the available database capacity, system performance, and business processes. The range of residence times can be broad – in projects concerning orders (Object MM_EKKO), residence times were set between 3 and 24 months. The total retention time of data in the archive usually amounts to several years (usually between 5 and 10 years.) The precise time, however, depends on the country, the type of data, and the current statutory requirements. © SAP AG
Page 17
Guide to Data Archiving in mySAP Retail
Version 1.1
2.7 Archiving Customizing From Release 4.0, you can access the relevant Customizing for an archiving object from transaction SARA. For each archiving object, Customizing can consist of the following three parts: •
Application-Specific Customizing For some objects, you can set the residence time in application-specific Customizing. For objects that do not have Customizing settings, you can usually specify the residence time in the variant for the write program. For sample entries, refer to the section Examples for Residence Times.
•
Archiving Object-Specific Customizing Technical settings are made in archiving object-specific Customizing. You specify, for example, the maximum number of archive files that are to be written and the maximum size that the file can have. If one of these limits is reached, the system closes the archive file and opens a new one. Note: 100 MB is an appropriate file size.
•
Basis Customizing In Basis Customizing, you specify the names of the archive files and directories. If an archive file is created by a write program, its physical name is derived from a logical file name. Similarly, the physical path name is determined from a logical path name. For more information, refer to SAP Note 35992 (ReleaseIndependent: File name/directory for application archiving), and to field help in the system.
•
Cross-Archiving Object Customizing From Release 4.6C, there are further settings in cross-archiving object Customizing. These include settings regarding access checks for archive files, the archiving monitor and the verification of archiving files.
2.8 Sample Selection in Agreement with the User Departments For all objects, you should run a sample selection to check the archivability of the data. The resulting logs should be analyzed in collaboration with the user departments. The following options exist for sample selections: •
Sample selection in test run You can run the write program in test mode to create a log. In this case, the system reads the data, but does not create an archive file and does not delete any data from the database. The contents of the log differs according to the archiving object.
•
Sample selection in the preprocessing program Some objects have preprocessing programs that check archivability (for example, RV_LIKP and SD_VBRK.) To determine how many documents are to be archived, you can run these reports in test mode.
2.9 Performance in Archiving It is not possible to make a general statement on the duration of an archiving session. Since the timeframe for running archiving sessions is often very tight, you should take the system’s capacity utilization into consideration. It is possible to schedule write jobs and delete jobs as background jobs outside transaction SARA. (See SAP Note 133707 (release-independent) Data Archiving Outside Transaction SARA, and SAP Note 205585 (Release 3.0D – 4.6C) Scheduling ADK deletion jobs outside SARA.) It also possible to run write jobs in parallel for the same archiving object (see SAP Note 191761 (Release 3.0D – 4.6C) Parallel processing of write phase during archiving.) From Release 4.5, it is possible to make
Page 18
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
Customizing settings in transaction SARA whereby the load distribution on background servers can be restricted to one server group. The performance of the archiving programs depends largely on the following factors: •
Volume of data for archiving (such as the number of line items)
•
Checks that have to be carried out In object-specific Customizing, you should only activate the optional checks that are important for the current project context, since every additional check reduces system performance. Hence, for SD orders, it is advisable to activate the order requirements check for third-party orders, but not for other order types.
•
Hardware specifics
•
The size of the commit counter (archiving object-specific Customizing) – you can make settings under Customizing settings in transaction AOBJ.
•
Size of archive files (archiving object-specific Customizing.)
For more information on performance-related issues in Data Archiving, refer to the document Planning and Implementing SAP Archiving Projects. After archiving, you can, in many cases, improve performance by reorganizing the database using database tools. See SAP Note 53062 (release independent) Database Reorganization and R/3 Archiving.
2.10 Specific Information for Each Archiving Object 2.10.1 Information for each object This section provides information, where required, on individual objects. The following information is provided for each object: •
Main archiving requirements This outlines the most important requirements. For more information, refer to the SAP Library.
•
Notes on the selection This covers basic information on the selection and notes that require special attention. You can see the detailed selection criteria in the system by calling up the relevant write program for the creation of an archive file or by defining a variant for a program in transaction SARA. The criteria vary from object to object.
•
Notes on Customizing This explains whether object-specific Customizing is possible and draws your attention to points requiring special attention. For more information on object-specific Customizing, refer to the documentation on individual objects in the SAP Library.
•
Retail-specific comments This gives information on the business context, for example, relating to mass data processing or performance issues.
•
Important Notes This gives an overview of the most important SAP Notes. Many objects also have additional Notes that are not discussed here. For an overview of all available Notes, refer to Notes in SAP Market Place or the Online Service System.
© SAP AG
Page 19
Guide to Data Archiving in mySAP Retail
Version 1.1
2.10.2 Further Sources of Information 2.10.2.1 SAP Library The SAP Library provides extensive documentation on each archiving object (under CA à Archiving Application Data.) The information available in the SAP Library covers •
Requirements
•
Customizing
•
Dependencies
2.10.2.2 Information in the SAP System The SAP system provides information such as: •
Which archiving object is valid for which table? (transaction DB15)
•
Which tables do an archiving object archive? (transaction SARA, display database tables, or transaction DB15)
•
What selection criteria are available when writing archive files (transaction SARA, set variants for archiving)
3 Detailed Information for Each Archiving Object 3.1 MM_MATNR (Article master records) 3.1.1 Main Archiving Requirements Before an article master record can be archived and deleted, all other objects relating to this article, such as purchase documents, must be archived. Article master records can be archived and deleted individually and in groups for one or multiple organizational levels.
3.1.2 Notes on Selection For archiving purposes, you are advised to create a variant for article master records (Retail) and to run this periodically.
3.1.3 Notes on Customizing •
There is no object-specific Customizing.
•
In Customizing for the article master under Define Article Type Characteristics, you can specify the number of days between the logical and physical deletion of article master records.
3.1.4 Retail-Specific Information Article master data is often kept in the system for a very long period. Consequently, you should check whether change documents for master records can be archived in advance using the archiving object CHANGEDOCU.
3.1.5 Important Notes •
192129 (Releases 4.0A - 4.6B) Collective Note: Archiving Article Master
•
140255 (Releases 3.00 - 4.6A) Application-independent Archiving of Change Documents
Page 20
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
3.2 MM_HDEL (Historical valuation data) 3.2.1 Main Archiving Requirements MM_HDEL archives the historical valuation data for each article and business that is written to the table MBEWH. A new entry is created in the table MBEWH when a new month begins and when the first goods transaction for this article is posted in the system. The system then automatically saves the current transaction data from the table MBEW in a new MBEWH record. Historical valuation data from the two previous months, and from the same month of the previous year is of primary importance for day-to-day business. Historical records that are older than a year are normally no longer required.
3.2.2 Notes on Selection None
3.2.3 Notes on Customizing There is no object-specific Customizing.
3.2.4 Retail-Specific Information This object is not suitable for archiving large volumes of data. Data for archiving is loaded in its entirety to the main memory when read. If the main memory can not import the data, this results in swapping, which increases the runtime considerably. SAP Note 178954 offers a solution to this problem (see below.)
3.2.5 Important Notes 178954 (Releases 4.0A - 4.6C) Corrections for archiving object MM_HDEL (RM07KOHDEL2)
3.3 MM_MATBEL (Article documents) 3.3.1 Important Archiving Requirements The retention period for article documents can be set in Customizing for Inventory Management. The posting date from the article document header is relevant for the retention period.
3.3.2 Notes for Selection You are not advised to make a selection for each retail site since some documents, such as stock transfers, can contain line items with different retail sites The documents should be archived according to year. Since the numbers are only unique within a specific fiscal year, the same number can recur in different years.
3.3.3 Notes on Customizing In Customizing for Inventory Management, you can set the retention period for article documents for each retail site and transaction type.
© SAP AG
Page 21
Guide to Data Archiving in mySAP Retail
Version 1.1
3.3.4 Retail-Specific Information When uploading sales data using the POS interface – inbound, inventory corrections for the goods issue are posted to the stores. This usually results in the creation of many article documents so that the table MSEG grows rapidly. The archiving program for the archiving object MM_MATBEL (RM07MARC) does not permit the targeted selection of documents from the POS interface – inbound. You can use SAP Note 194026 to mark article documents from the POS interface – inbound for subsequent archiving.
3.3.5 Important Notes •
194026 (Releases 4.0B - 4.6B) Advance archiving for POS sale
•
195247 (Releases 3.10 - 4.6B) Large table growth in MM Inventory Management
3.4 MM_INVBEL (Inventory documents) 3.4.1 Main Archiving Requirements An inventory document can only be archived if the inventory differences have already been posted.
3.4.2 Notes on Selection The documents should be archived according to year. Since the numbers are only unique within a specific fiscal year, the same number can recur in different years.
3.4.3 Notes on Customizing There is no object-specific Customizing
3.4.4 Retail-Specific Information None
3.4.5 Important Notes None
3.5 MM_REBEL (Invoice documents for component MM- Invoice Verification) 3.5.1 Main Archiving Requirements Archiving a document is dependent on the status of the document: •
You can archive documents with the status Completed or Deleted.
•
You can not archive documents with the status Unchecked, Verified as incorrect, or Verified as correct.
Financial accounting documents that are created during the posting of invoice documents are not archived by object MM_REBEL. These are archived in Financial Accounting.
Page 22
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
3.5.2 Notes for Selection The documents should be archived according to year. Since the numbers are only unique within a specific fiscal year, the same number can recur in different years.
3.5.3 Notes for Customizing None
3.5.4 Retail-Specific Information None
3.5.5 Important Notes •
139185 (Release 3.10 - 4.5B) RM08RADE:Prblms whn deleting items drng termination
•
150744 (Release 4.0A - 4.5B) Log. inv.verific.: Archiving program terminates
3.6 MM_EKKO (Purchasing documents) 3.6.1 Important Archiving Requirements Purchasing documents are requests, orders, contracts and delivery schedules. Documents in which the deletion indicator is set for all line items, can be archived. Documents that have line items without a deletion indicator are checked for archivability. In the case of an order, for example, it is a requirement for archiving that delivery must have been carried out and invoiced for all line items (within the tolerance limits.) Non-archived documents can also accumulate in the system if there are differences between the volume that has been delivered and the volume that has been charged. If you implement subsequent settlement, you must, if necessary, activate an additional check so that the documents are not activated too early from the perspective of the subsequent settlement. See Note 180434 (Release 3.0D - 4.5B). Orders are to be archived before contracts.
3.6.2 Notes on Selection From Release 4.6A, you can make a selection according to document type (order, contract, delivery schedule.) For releases before 4.6A, you can use SAP Note 142519 to extend selection criteria to include, for example, document type, site, and purchaser group.
3.6.3 Notes on Customizing You can set the residence times for purchasing documents in Customizing for Purchasing. If, during the residence times, changes occur to the documents, or actions affecting the documents take place, such as goods issue, the deletion indicator is not set and archiving does not take place.
3.6.4 Retail-Specific Information Using this archiving object can have long runtimes. It is therefore advisable to create several variants that run in parallel with up to 20,000 documents. From Release 4.6A. you can use the additional selection criteria document date, document type and purchasing group.
3.6.5 Important Notes •
142519 (Release 3.00 - 4.5B) Archiving: Additional selection criteria
© SAP AG
Page 23
Guide to Data Archiving in mySAP Retail
•
194385 (Release 3.00 - 4.6B) Strong table growth in MM Purchasing
•
165586 (Release 3.0A - 4.6A) Performance improvement archiving purchasing docs
•
191124 (Release 3.00 - 4.6B) SARA: Performance w. archiving purchasing documents
Version 1.1
3.7 MM_EBAN (Order requests) 3.7.1 Main Archiving Requests In addition to the residence times, when archiving order requests, the system checks whether the requested amount (or more) was ordered. These checks are run on documents that are not marked for deletion. An order request is only archived once all items fulfil the deletion criteria.
3.7.2 Notes on Selection From 4.6A, you can make a selection according to document type, retail site, and purchasing group. You can use SAP Note 142519 to make these selection criteria available for older releases.
3.7.3 Notes on Customizing In Customizing for Purchasing, the residence times for order requests can be set according to document type and line type. If changes to the order requests or to transactions related to the order requests are made, the deletion indicator is not set, and the archiving is not carried out.
3.7.4 Retail-Specific Information None
3.7.5 Important Notes •
142519 (Release 3.00 - 4.5B) see recommendations on selection
•
123900 (release-independent) Problems with interpreting the logs
•
140505 (Release 4.0A - 4.5B) Archiving: Poor performance
3.8 RL_TA (Transport documents for warehouse management system) 3.8.1 Main Archiving Requirements The write program archives edited records that that have been stored for a specified number of days in the warehouse management system.
3.8.2 Notes on Selection You can use this program to archive several warehouse numbers at the same time.
3.8.3 Notes on Customizing There is no object-specific Customizing
3.8.4 Retail-Specific Information None
Page 24
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
3.8.5 Important Notes •
94977 (Release 3.0A - 4.6B) Archives in stock with repetition
•
169023 (Release 4.6A) Termination during reading of TOs from archive
3.9 RV_LIKP (Deliveries) 3.9.1 Main Archiving Requirements Before archiving deliveries, a range of checks are carried out, for example, against the status of the transport documents or the status of the invoices. The requirements are fully described in SAP Note 138666. Archive deliveries before order or invoice documents.
3.9.2 Notes on Selection There is a preprocessing program that checks the documents for archivability.
3.9.3 Notes on Customizing In application Customizing, you can set the delivery-specific conditions for archiving. If you do not maintain these settings, no documents are archived. To ensure that deliveries are archived correctly, it is essential that you maintain a residence time that is higher than 0 and a generic entry for the sales organization. You are advised to activate only the optional checks that are necessary for your project.
3.9.4 Retail-Specific Information None
3.9.5 Important Notes •
152395 (release-independent) Archiving of deliveries relevant for shipment
•
138666 (Release 3.0D - 4.6B) When can a delivery be archived?
•
140652 (Release 3.0D - 4.6A) SAP AS: Business views SD For more information on this Note, refer to the section Archive Analysis in the SAP Archive Information System.
3.10 SD_COND (Condition records) 3.10.1 Main Archiving Requirements Condition records with deletion indicators and records with a validity period in the past can be archived. The system checks whether there are still documents that link to the condition records for archiving (table KONV.) The document check must be activated in Customizing for SD Data Archiving under Control Archiving for Conditions (table 68ICH.) If the document check is activated, a record is not archived if it is still referenced in a document.
3.10.2 Notes on Selection For each archiving session, you must select a condition type and a condition table. If the document check is activated for applications in Customizing, you can set the maximum number of
© SAP AG
Page 25
Guide to Data Archiving in mySAP Retail
Version 1.1
documents to be checked (KONV.) If this maximum number is exceeded, none of the applications with activated document check are archived.
3.10.3 Notes on Customizing In the system, there are often condition records with an unlimited validity (to-date: 12.31.9999.) These are not archived since the system only archives records that have a validity end date that is the same as that of the archiving session or earlier. It may be necessary to control the archivability of the condition rates not only using the validity data in Customizing, but also by setting the deletion indicator. In this case, irrespective of date, records are marked as deleted in the maintenance and can be archived. In archiving, the corresponding settings are nonetheless necessary (selection of category conditions with deletion indicator.) The validity period for a condition record is stored in the accompanying condition table entries (A tables.)
Note that in the case of a period split, condition records (KONP) may not be archived, although they are older than the date set for the validity check. Records can only be archived once all periods in the period split have elapsed. For example: Period split with validity period 1.1.190012.31.1999 and 1.1.2001-12.31.2010. The record with validity up to 12.31.1999 can only be archived after 12.31.2010, or before then by setting the deletion indicator.
3.10.4 Retail-Specific Information None
3.10.5 Important Notes •
173096 (Release 3.0D - 4.6A) Archiving of KONH- and KONP table without A-tables
•
197112 (Release 3.0F - 4.6B) Archiving of condition tables w/o validity period
•
198117 (Release 3.0F - 4.6B) Performance during archiving of conditions
•
137216 (Release 3.0D - 4.5A) Archiving of change documents of conditions
3.11 SD_VBRK (Invoices) 3.11.1 Main Archiving Requirements This archiving object performs the following checks on invoices before they are archived: •
The residence time refers to the creation date of the document (compulsory.)
•
Flow: If the invoice has a follow-on document (such as a credit memo request with reference to invoice), the system checks whether the follow-on document has the overall processing status Completed (compulsory.)
•
Accounting document: The system checks whether the invoice has been settled in Accounting (optional.)
If you implement subsequent settlement, you must, if necessary, activate an additional check so that the documents are not activated too early from the perspective of the subsequent settlement. See Note 180434 (Release 3.0D - 4.5B).
3.11.2 Notes on Selection There is a preprocessing program that checks the documents for archivability.
Page 26
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
3.11.3 Notes on Customizing In application-Customizing, you can set specific conditions for archiving. If you do not maintain this, documents can not be archived. To ensure that inbound deliveries are correctly archived, it is essential that for this delivery type you maintain a residence time that is higher than 0 and a generic entry for the sales organization. Activate only the optional checks that you require for your project environment.
3.11.4 Retail-Specific Information In the standard system for SAP Retail, invoice documents are updated when POS data is processed in the POS-inbound interface (see also the Data Prevention Checklist.) The invoices are, in this case, posted for the sales revenue realized. You can deactivate the automatic updating of invoices in Customizing. Performance problems can arise, since deleting index entries at document line item level (table VBOX) is very runtime-intensive. SAP Note 171676 offers a solution.
3.11.5 Important Notes •
171676 (Release 3.1I - 4.5B) Long runtime when reorganizing the VBOX
•
48420 (Release 2.1H - 4.5B) Document flow: Display of archived documents
•
140652 (Release 3.0D - 4.6A) SAP AS: Business views SD For more information on this Note, refer to the section Archive Analysis using the SAP Archive Information System.
3.12 SD_VBAK (Sales documents) 3.12.1 Main Archiving Requirements A series of checks are applied to sales documents. One of these checks, for example, checks that the subsequent documents (delivery, goods issue) have the status Completed in line with the document flow. You must archive deliveries before archiving sales documents.
3.12.2 Notes on Selection There is a preprocessing program that checks documents for archivability.
3.12.3 Notes on Customizing In application-specific Customizing, you can set specific conditions for archiving. If you do not maintain these settings, no documents are archived. To ensure that inbound deliveries are archived, it is essential that for this delivery type, you maintain a residence time that is higher than 0 and a generic entry for the sales organization. Activate only the optional checks that you require for your project environment.
3.12.4 Retail-Specific Information None
3.12.5 Important Notes •
150465 (Release 3.0D - 4.6A) Archiving: SD_VBAK – archiving ONR00 ONRVB
•
140652 (Release 3.0D - 4.6A) SAP AS: Business views SD For more information on this Note, refer to the section Archive Analysis using the SAP Archive Information System.
© SAP AG
Page 27
Guide to Data Archiving in mySAP Retail
Version 1.1
3.13 W_SOR (Assortment modules and deleting listing conditions) Archiving object W_SOR archives assortment modules. The accompanying listing conditions are deleted. Change documents relating to assortment modules and listing conditions are not archived (see also SAP Note 192657.)
3.13.1 Main Archiving Requirements Assortment modules can only be archived if, on the date of archiving, they are no longer valid, or if they are marked for deletion. Listing conditions can only be deleted if they are no longer valid on the date of archiving.
3.13.2 Notes on Selection None
3.13.3 Notes on Customizing There is no object-specific Customizing.
3.13.4 Retail-Specific Information When discontinued, the listing condition’s date is reset, for example, from unlimited validity (validity end date 12.31.9999) to the system data. SAP Note 184190 supports subsequent deletion. SAP Note 158001 restricts the number of checks in the case of discontinuation to checking the use of a material in an order to the existence of purchasing information records and to inventory information. The condition listings and purchase orders are deleted for the articles checked. If the check result is correct, deletion indicators are set on the article master segments. In the course of the subsequent archiving, however, all necessary checks are carried out. In SAP Retail, change documents relating to assortment modules, listing conditions, and merchandise category (see SAP Note 192657) should be deleted instead of being archived by the archiving object CHANGEDOCU.
3.13.5 Important Notes •
184190 (Release 4.0B - 4.6B) Deleting expired listing conditions
•
158001 (Release 4.0B - 4.6A) Simplified checks for article discontinuation
•
192657 (Release 4.0B - 4.6B) Deletion of change documents for WLK1, ASMODULE
3.14 W_PROMO (Promotions) 3.14.1 Main Archiving Requirements Promotions can only archived if their validity period has been exceeded. Promotions without follow-on documents can be deleted online. Follow-on documents that were created for a promotion should be archived in advance. This includes assortments, additionals, volume rebate arrangements, and conditions. Follow-on documents such as allocation tables and product catalogs are normally deleted and not archived.
3.14.2 Notes on Selection 3.14.3 Notes on Customizing There is no object-specific Customizing.
Page 28
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
3.14.4 Retail-Specific Information None
3.14.5 Important Notes 202307 (Release 4.0A - 4.5B) Archiving of promotion data The archiving object W_PROMO was supplied with 4.6B. You can use this SAP Note to implement it for earlier releases.
3.15 W_KALK (Pricing document) 3.15.1 Main Archiving Requirements This object checks the status of line items when archiving pricing documents. •
Line item positions with a valid-to date before the archiving key date are archived irrespective of the status.
•
Line item positions with status A or B and that have a valid-to date after the key date for archiving are not archived (since it is still possible to activate the prices.)
•
Line items with status C are only activated if there are no relevant condition records that are still valid after the key date. All condition records for the main condition types (as defined in sales price calculation control) in application V are examined.
•
Line items with status D are usually archived independently of the key date.
•
Canceled line items (status E): If the indicator for date-independent archiving is set, the line items are treated in the same way as positions with status D, that is, independently of the key data. Otherwise they are not archived. This occurs because in the pricing document processing, canceled line items can be transferred to lines with status B.
3.15.2 Notes on Selection None
3.15.3 Notes on Customizing There is no object-specific Customizing.
3.15.4 Retail-Specific Information None
3.15.5 Important Notes •
203397 (Release 4.0B - 4.6C) Archiving pricing docs: WKBK incorrectly deleted
•
213183 (Release 4.0A - 4.6C) Error in deletion program f.archiving object W_KALK
•
304083 (Release 4.0A - 4.6C) Performance problems archiving W_KALK
3.16 FI_DOCUMNT (Financial Accounting documents) 3.16.1 Main Archiving Requirements Documents that were posted to an account with open items can only be archived if they have the status Settled. Since Release 4.0A, you can test the archivability of individual documents using transaction FB99. © SAP AG
Page 29
Guide to Data Archiving in mySAP Retail
Version 1.1
If you implement subsequent settlement, you must, if necessary, activate an additional check so that the documents are not activated too early from the perspective of the subsequent settlement. See Note 180434 (Release 3.0D - 4.5B).
3.16.2 Notes on Selection You should only carry out archiving using company codes that have the same posting period variants. In addition to the compulsory archiving and delete programs, the object also has index build and delete programs. This means that in addition to the reconstruction of archive and secondary index, accounting documents can be searched in the archives. The archive index enables access to an archived document. The secondary index provides an overview over the line items in an account. You can access an archived line item by double clicking it. You must maintain the secondary index in the system as long as rapid access to a document is required.
3.16.3 Notes on Customizing You can make settings for document type life and account type life (residence times) and for managing the index. •
Depending on the company code and the document type, you can specify a residence time in days.
•
Depending on the company code, account type, and account number interval, you can specify a residence time in days.
The validity period check is based on the settings in application-specific Customizing and the settings in the variant. There is no longer an archive index validity period check. FI_DOCUMNT enables you to maintain validity periods in several places. You are advised to work, as far as possible, with wildcards in the Customizing tables and to set the validity periods as short as possible, as agreed by your consultant. You can select closed fiscal years in the variant by making entries under fiscal years and posting periods.
3.16.4 Retail-Specific Information None
3.16.5 Important Notes •
152057 (Release 4.0A - 4.6A) FI doc archiving generates too many archive indexes
•
157998 (release-independent) No evaluation of FI document archives, why ?
3.17 MM_ACCTIT (Follow-up posting from Materials Management) When postings in the application components Inventory Management (MM-IM) and Invoice Verification (MM-IV) are carried out, invoice-relevant data is updated in various table (ACCT*.) The system accesses data in the tables ACCTHD, ACCTIT and ACCTCR when MM data is transferred (using follow-up postings) to the following application components: •
Special Ledger (FI-SL)
•
Profit Center Accounting(EC-PCA)
•
Consolidation (FI-LC)
•
Controlling (CO)
3.17.1 Main Archiving Requirements None
Page 30
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
3.17.2 Notes on Selection When you enter company code, fiscal year, or posting date, all lines belonging to the relevant MM follow-up document are archived, even if this data belongs to a different company code, fiscal year, or posting date. This means that the whole MM follow-up document is archived if one of the document lines matches the criteria selected.
3.17.3 Notes on Customizing There is no object-specific Customizing.
3.17.4 Retail-Specific Information Check whether it is necessary to update the information. If you process POS data using the POS-inbound interface, the data volumes in tables ACCTHD, ACCTIT, and ACCTCR can be very big. If you do not need this data in your system, you can make a program change to deactivate the update (see SAP Note 48009.)
3.17.5 Important Notes •
48009 (Release 3.00 - 4.6C) Size of tables ACCTHD, ACCTIT, ACCTCR increases
•
83076 (Release 3.0C - 4.6C) Archiving tables ACCTIT, ACCTHD, ACCTCR
3.18 Selected CO Objects Several archiving objects are available for archiving master and transaction data for cost centers: •
CO_COSTCTR (Cost center data – all data including master data)
•
CO_ITEM (CO Line items)
•
CO_CCTR_PL (Planning data, summary data and line items)
•
CO_CCTR_ID (Actual data, summary data and line items)
•
CO_CCTR_EP (Line items, planned and actual data)
•
CO_ALLO_ST (Completely cancelled documents, contributions, distribution, periodic repostings))
This document can not deal with all CO objects. The following sections give an overview of a few objects that are used in many projects. For more information on data prevention and archiving in CO, refer to the Data Prevention Checklist and the document Planning and Implementing SAP Archiving Projects.
3.19 CO_COSTCTR (Cost center data – all data including master data) 3.19.1 Main Archiving Requirements Archiving can not be carried out until the fiscal year has closed. In some cases, the data must remain in the system for another year for the purposes of comparison. By archiving, all the cost center master data for the fiscal year is removed. Time-dependent master data is also archived in this way. If all data for a cost center is deleted, the fiscal year to which this data belongs can no longer be archived (cost centers have time-dependent master data.) •
After archiving using this archiving object, the cost center is no longer available as an account determination object or as a planning object.
•
The overall archiving can only be carried out once the cost centers and their data are no longer required for posting or evaluation purposes.
•
Note that once fiscal year data has been archived, it is no longer possible to use this for reporting in fiscal year comparisons.
© SAP AG
Page 31
Guide to Data Archiving in mySAP Retail
Version 1.1
3.19.2 Notes on Selection None
3.19.3 Notes on Customizing There is no object-specific Customizing.
3.19.4 Retail-Specific Information None
3.19.5 Important Notes None
3.20 CO_ITEM (CO Line items) CO_ITEM archives CO line items on a cross-application basis. These can be archived with other line items. CO_ITEM should only be used if overflow in tables COE* (such as COEP, COEJ, COST) can not be resolved by any other means, particularly by archiving cost centers or internal orders. In table COEP, the first two characters of the field OBJNR (object number) specify the object type (see table.) This object can be archived with the relevant archiving object. You can analyze the tables COEP and COEJ using the reports RARCCOAx (see SAP Note 138688.)
3.20.1 Main Archiving Requirements This archiving object does not archive totals records. For each transaction involving an object in the CO component (such as an order or cost center), the system automatically records a CO line item. These line items exist additionally to the settlement or financial accounting documents. When archiving CO objects, line items belonging to the object are also archived. It is therefore not normally necessary to archive CO line items explicitly. The system does not archive CO line items that fulfil the following criteria: •
CO line items that are down payments (Value types 12, 58, 59, 61, 63)
•
CO line items for line-item led investment measures
•
CO line items for the current or future period in the actual system
Planned CO line items for the current of future fiscal year in the planning system
3.20.2 Notes on Selection None
3.20.3 Notes on Customizing In addition to the settings in Basis Customizing for Archiving, you must set the residence times for the write program and the block sizes for the delete program for CO line item archiving.
3.20.4 Retail-Specific Information None
Page 32
© SAP AG
Version 1.1
Guide to Data Archiving in mySAP Retail
3.20.5 Important Notes •
138688 (Release 3.0D - 4.6B) Archiving/Controlling: table analysis
•
200480 (release-independent) Archiving CO_ITEM: Too few or nothing archived
3.21 CO_ML_BEL (Material Ledger Documents in the component Actual Costing/Material Ledger) 3.21.1 Main Archiving Requirements The archiving object contains information on valuation-relevant transaction data for specific articles. The following material ledger document types can be distinguished by the transaction type: •
CL Material Ledger Settlement
•
PC Material Ledger Price Change
•
UP Material Ledger Update
You must observe statutory retention requirements, since this affects valuation-relevant data. Before CO_ML_BEL is used, you must ensure that the data: •
Has no further effect on article prices
•
Is only required for analysis purposes
(Use of this object also has implications for euro conversion.)
3.21.2 Notes on Selection None
3.21.3 Notes on Customizing There is no object-specific Customizing
3.21.4 Retail-Specific Information None
3.21.5 Important Notes None
3.22 CO_ML_IDX (Material Ledger Indices for Component Actual Costing – Material Ledger) 3.22.1 Main Archiving Requirements The archiving object contains entries that make it possible to carry out transactions on the article during the analysis and to display documents. Material ledger indices are also updated you implement Materials Management without the component Actual Costing – Material Ledger. Material Ledger indices can be archived
© SAP AG
Page 33
Guide to Data Archiving in mySAP Retail
Version 1.1
at any time. Check criteria are governed by the variant definition. (Use of this object also has implications for euro conversion.)
3.22.2 Notes on Selection None
3.22.3 Notes on Customizing There is no object-specific Customizing.
3.22.4 Retail-Specific Information None
3.22.5 Important Notes None
Page 34
© SAP AG
View more...
Comments
