0 evaluări0% au considerat acest document util (0 voturi)
326 vizualizări67 pagini
Best Practice Data Volume Management for retail c)2009 SAP AG - Data Volume Management for retail page 2 / 67 Date Alteration Reason Versi on 22.09.2009 Creation 0. SOLUTION MANAGEMENT PHASE SAP for retail TOPIC AREA SOLUTION MANAGER AREA Business Operations Data Volume Management POS Inbound 7 2 IDocs (EDIDC, EDI40, EDIDS) 8 2.1 Avoidance 8 2.1 Summarization 8 2.1. Deletion 8
Best Practice Data Volume Management for retail c)2009 SAP AG - Data Volume Management for retail page 2 / 67 Date Alteration Reason Versi on 22.09.2009 Creation 0. SOLUTION MANAGEMENT PHASE SAP for retail TOPIC AREA SOLUTION MANAGER AREA Business Operations Data Volume Management POS Inbound 7 2 IDocs (EDIDC, EDI40, EDIDS) 8 2.1 Avoidance 8 2.1 Summarization 8 2.1. Deletion 8
Best Practice Data Volume Management for retail c)2009 SAP AG - Data Volume Management for retail page 2 / 67 Date Alteration Reason Versi on 22.09.2009 Creation 0. SOLUTION MANAGEMENT PHASE SAP for retail TOPIC AREA SOLUTION MANAGER AREA Business Operations Data Volume Management POS Inbound 7 2 IDocs (EDIDC, EDI40, EDIDS) 8 2.1 Avoidance 8 2.1 Summarization 8 2.1. Deletion 8
Dietmar-Hopp-Allee 16 D-69190 Walldorf CS STATUS internal In progress DATE VERSION September 22, 2009 0.1 SOLUTION MANAGEMENT PHASE SAP SOLUTION All project phases SAP for retail TOPIC AREA SOLUTION MANAGER AREA Business Operations Data Volume Management Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 2/67 Date Alteration Reason Versi on 22.09.2009 Creation 0.1 Table of Contents 1 Management Summary 6 2 POS Inbound 7 2.1 IDocs (EDIDC, EDI40, EDIDS) 8 2.1.1 Avoidance 8 2.1.2 Summarization 8 2.1.3 Deletion 8 2.1.4 Archiving 8 2.2 Article Documents (MKPF, MSEG) 11 2.2.1 Avoidance 11 2.2.2 Summarization 11 2.2.3 Deletion 11 2.2.4 Archiving 11 2.3 Billing Documents (VBRK, VBRP) 14 2.3.1 Avoidance 14 2.3.2 Summarization 15 2.3.3 Deletion 15 2.3.4 Archiving 15 2.4 Financial documents (BKPF, RFBLG, FAGLFLEXA) 17 2.4.1 Avoidance 17 2.4.2 Summarization 17 2.4.3 Deletion 19 2.4.4 Archiving 19 2.5 Tables FAGL_SPLINFO & FAGL_SPLINFO_VAL 20 2.5.1 Avoidance 20 2.5.2 Summarization 20 2.5.3 Deletion 20 2.5.4 Archiving 20 2.6 Table BSIS 21 2.6.1 Avoidance 21 2.6.2 Summarization 21 2.6.3 Deletion 21 2.6.4 Archiving 21 2.7 Controlling Documents (COBK, COEP) 22 2.7.1 Avoidance 22 2.7.2 Summarization 22 2.7.3 Deletion 22 2.7.4 Archiving 22 2.8 Profit Center Accounting document line items (GLPCA) 23 Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 3/67 2.8.1 Avoidance 23 2.8.2 Summarization 23 2.8.3 Deletion 23 2.8.4 Archiving 23 2.9 ACCT*-tables 24 2.9.1 Avoidance 24 2.9.2 Summarization 24 2.9.3 Deletion 24 2.9.4 Archiving 24 2.10Table CKMI1 25 2.10.1 Avoidance 25 2.10.2 Summarization 25 2.10.3 Deletion 25 2.10.4 Archiving 25 2.11Tables IDOCREL & SRRELROLES 26 2.11.1 Avoidance 26 2.11.2 Summarization 26 2.11.3 Deletion 26 2.11.4 Archiving 26 2.12Tables WPTST & WPLST 27 2.12.1 Avoidance 27 2.12.2 Summarization 27 2.12.3 Deletion 27 2.12.4 Archiving 27 2.13Info-Structures (RIS/LIS tables Sxxx) 28 2.13.1 Avoidance 28 2.13.2 Summarization 31 2.13.3 Deletion 31 2.13.4 Archiving 31 2.14Application logs (BALHDR, BALDAT) 32 2.14.1 Avoidance 32 2.14.2 Summarization 32 2.14.3 Deletion 32 2.14.4 Archiving 32 2.15Work Items (SWWWI* tables) 34 2.15.1 Avoidance 34 2.15.2 Summarization 34 2.15.3 Deletion 34 2.15.4 Archiving 35 3 Store Replenishment Cycle 37 3.1 Purchase Requisitions (EBAN) 39 3.1.1 Avoidance 39 3.1.2 Summarization 40 3.1.3 Deletion 40 3.1.4 Archiving 40 3.2 Purchase Orders (EKKO, EKPO) 41 Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 4/67 3.2.1 Avoidance 41 3.2.2 Summarization 41 3.2.3 Deletion 41 3.2.4 Archiving 41 3.3 Change Documents (CDHDR, CDCLS) 44 3.3.1 Avoidance 44 3.3.2 Summarization 45 3.3.3 Deletion 45 3.3.4 Archiving 46 3.4 Outbound Deliveries (LIKP, LIPS) 48 3.4.1 Avoidance 48 3.4.2 Summarization 48 3.4.3 Deletion 48 3.4.4 Archiving 48 3.5 Transport Orders (LTAK, LTAP) 49 3.5.1 Avoidance 49 3.5.2 Summarization 49 3.5.3 Deletion 49 3.5.4 Archiving 49 4 Warehouse Replenishment Cycle 50 4.1 Forecast data (PROP, PRON, PROW, PROF, PROH) 51 4.1.1 Avoidance 51 4.1.2 Summarization 51 4.1.3 Deletion 52 4.1.4 Archiving 52 4.2 Vendor Invoices (WBRK, WBRP) 53 4.2.1 Avoidance 53 4.2.2 Summarization 53 4.2.3 Deletion 53 4.2.4 Archiving 53 5 Customer (Sales) Orders 55 5.1 Sales orders (VBAK, VBAP) 56 5.1.1 Avoidance 56 5.1.2 Summarization 56 5.1.3 Deletion 56 5.1.4 Archiving 57 6 POS Download / Assortment List 59 6.1 Change Pointers (BDCP. BDCPS, BDCP2, WIND) 60 6.1.1 Avoidance 60 6.1.2 Summarization 63 6.1.3 Deletion 63 6.1.4 Archiving 65 6.2 Assortment List (WBBH, WBBP) 65 6.2.1 Avoidance 65 6.2.2 Summarization 65 6.2.3 Deletion 65 Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 5/67 6.2.4 Archiving 66 Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 6/67 1 Management Summary This paper describes a few main retail processes and their contributions to data growth in a Retail environment. The main processes considered in this paper are: POS Inbound (aggregated sales using WPUUMS-IDocs) Store procurement cycle Warehouse procurement cycle Sales (customer) orders POS Outbound / Assortment list These main processes are summarized in the figure below: In the following sections, brief descriptions of each process and the different types of documents generated will be given, followed by the possibilities of data avoidance, summarization, deletion, and archiving for each type of document. SAP AG 2007, Data Archiving In SAP Retail / AndrewChew.Walter / 24 Mai n Ret ai l Processes SAP Ret ai l Syst em Vendor DC Del ivery Notes Transport Orders Goods Issues MRP HQ Assortment Pl anning St or e " R/3 St or e" Repl eni shment Planning POS-Interface Outbound Master data, Assortment List POS Interface Inbound Sal es Data, Store Order Purchase Or ders Purchase Orders Goods Receipts Goods Recei pts Stock Transfer Orders Invoi ces Sal es Orders Cust omer Goods Recei pt s Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 7/67 2 POS Inbound The POS Inbound process is not only one of the most runtime-critical processes within a retail environment; it is also one of the largest contributors to the high data volumes created on a daily basis. The figure above is based on a live customer example before optimization took place. The posting of each document type in the POS Inbound process is based on standard settings. Each store sends its sales data at the end of the day to the head office for processing. The sales data is aggregated at article/store/day level. Each IDoc (message type WPUUMS) contained 300 articles and each store sent an average of 25 IDocs per day. The IDocs are stored in tables EDIDC, EDI40 and EDIDS. EDI40 being the line-item table, it is always among the fastest growing tables in a typical retail environment. The posting of each IDoc generates the following main documents: a. article documents (tables MKPF, MSEG) b. billing documents (tables VBRK, VBRP) c. financial documents (tables BKPF, RFBLG; FAGLFLEXA, FAGL_SPLINFO, FAGL_SPLINFO_VAL, BSIS, ...) d. controlling documents (tables COBK, COEP) e. profit centre accounting documents (table GLPCA) f. application logs g. work items Besides the main documents, updates to other tables are also carried out. These other tables are: a. ACCT*-tables SAP AG 2007, Data Archiving In SAP Retail / AndrewChew.Walter / 26 Maj or Cont ri but or To Dat abase Grow t h (Tabl e Ent ri es Due To POS I nbound Process) POS Inbound Process (processing of WPUUMS-IDocs) WPUUMS 300 lines Articl e doc. 100 lines Articl e doc. 100 lines Articl e doc. 100 lines Billing doc. 100 lines Billing doc. 100 lines Billing doc. 100 lines FI doc. 200 lines CO doc. 100 lines PCA doc. 200 lines FI doc. 200 lines CO doc. 100 lines PCA doc. 200 lines FI doc. 200 lines CO doc. 100 lines PCA doc. 200 lines FI doc. 101 lines PCA doc. ~200 lines FI doc. 101 lines PCA doc. ~200 lines FI doc. 101 lines PCA doc. ~200 lines ACCT* 200 lines CKMI1 100 lines ACCT* 200 lines ACCT* 200 lines CKMI1 100 lines CKMI1 100 lines Info-Structures (S012, S031, S032, S033, S083, S084, S121, ....) Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 8/67 b. CKMI1 c. IDOCREL, SRRELROLES d. WPTST, WPLST e. Info-structures (S012, S031, and so on) 2.1 IDocs (EDIDC, EDI40, EDIDS) The table EDI40 is among the fastest growing tables in retail. Therefore, we strongly recommend that daily archiving jobs be scheduled to remove the entries in the IDoc tables. 2.1.1 Avoidance Not possible. 2.1.2 Summarization Not possible. 2.1.3 Deletion IDocs can simply be deleted using program RSETESTD. However, this program is not meant for productive use. The recommended approach is to make use of the archiving object IDOC to remove the table entries. 2.1.4 Archiving Before the archiving is carried out with archiving object IDOC, analysis needs to be done to determine the different message types, statuses und dates of last posting. The analysis is done using transaction TAANA. Virtual fields for MONTH and YEAR based on EDIDC-UPDDAT are necessary. An example of the analysis results is shown in the following table: Status Message Type Month Year No. Entr. 03 ORDERS 04 2008 16.680 18 WP_PLU 04 2008 12.220 53 MBGMCR 04 2008 6.416 02 ZPROFORMA 04 2008 6.036 03 ZPROFORMA 04 2008 5.969 51 WPUUMS 04 2008 4.171 03 DESADV 04 2008 4.038 53 WPUUMS 04 2008 3.401 51 MBGMCR 04 2008 1.097 29 ZPROFORMA 04 2008 890 29 WP_PLU 04 2008 835 18 WP_EAN 04 2008 395 29 WPDSET 04 2008 213 33 ZPROFORMA 04 2008 108 02 ORDERS 04 2008 105 29 WP_EAN 04 2008 36 02 DESADV 04 2008 10 Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 9/67 02 WP_EAN 04 2008 2 03 ORDERS 03 2008 24.159 18 WP_PLU 03 2008 20.619 Next, archiving has to be enabled for the different IDoc statuses. This is done in transaction WE47. Example: IDoc status 29 This setting must be carried out for every IDoc status to be archived. The archiving of IDocs should initially focus on correctly processed IDocs only. Incoming IDocs that are correctly processed have status 53, whereas outgoing IDocs that are correctly sent have statuses 03 or 12, depending on the configuration of the outbound process. As a first step, the setting up of the variant of the archiving object should contain only these statuses (53, 03, and 12). There is no customizing for the residence time for IDocs. The residence times should be considered in the variant by using the posting date as a dynamic variable. In the example below, the variant has been set up to pick up all IDocs with statuses 53, 03 and 12 and whos posting dates are older than or equal to current date minus 8 days. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 10/67 In the case of erroneous IDocs, a second variant should be set up to pick up these statuses. This second variant should select IDocs with posting dates older than 2 months. Note that IDocs with statuses 64 and 30 in the current period and previous period must never be archived. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 11/67 2.2 Article Documents (MKPF, MSEG) The line item table for article documents (MSEG) is among the fastest growing tables in retail. Article documents resulting from POS are easily identified by the field MKPF-BKTXT =POS/xxxx, where xxxx = store number. The following figures are examples from a live customer. The figure on the left shows that only a relatively small percentage of all article documents are from the POS. However, the figure on the right shows that the majority of the line items in the line item table were due to these POS article documents Therefore, the archiving of article documents resulting from POS has to be more aggressive than other types of article documents. 2.2.1 Avoidance Not possible 2.2.2 Summarization Not possible. 2.2.3 Deletion Not possible. Entries can only be removed via archiving object MM_MATBEL. 2.2.4 Archiving The archiving of POS article documents via archiving object MM_MATBEL requires SAP Note 1116598 to be applied first. The archiving object MM_MATBEL requires the set up of residence time of the article documents in customizing. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 12/67 In the example above, the residence times of all article document types in all sites have been set to 14 days. After the residence times of the article documents have been set up, a variant for the archiving runs has to be defined. The example below is from a live customer. The article documents from POS are archived daily, keeping a moving trail of documents for 90 days. In this case, the posting date has been defined as a dynamic variable. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 13/67 Note that some customers are archiving all POS article documents older than 1 week on a daily basis. This measure is necessary to prevent the table MSEG from growing quickly. To archive non-POS article documents, the field POS must not be flagged. The Transaction/Event type field can/should be used to further refine the selection. Avoid using the Plant field as this causes the selection of article documents to be carried out on the line item table. Selection on table MSEG has an impact on the runtime of the archiving job. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 14/67 2.3 Billing Documents (VBRK, VBRP) The line item table for billing documents (VBRP) is normally among the fastest growing tables in retail. The document type relevant for POS is defined in the customizing of the POS Inbound profile used. The standard document type is FP and the line item type is DLN (customizing of POS Inbound profile, see below). The following example is from a live customer. The figure on the left shows that the billing documents from POS accounts for approximately 40% of all billing documents in the system. However, the figure on the right shows that the line items from POS billing documents accounts for almost all the billing document line items in the system. Therefore, the archiving of billing documents should initially focus on billing documents from POS. 2.3.1 Avoidance Billing documents from POS can be avoided through customization of the POS Inbound profile. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 15/67 With field billing set to 1, billing documents are created during runtime for updates to Finance and other modules, but are not saved to the database at the end of the processing. This setting should only be used if the billing documents are not required by the business. 2.3.2 Summarization Not possible 2.3.3 Deletion Not possible. Entries can only be removed by using archiving object SD_VBRK. 2.3.4 Archiving The archiving of billing documents via archiving object SD_VBRK requires the setup of residence times for the different billing document types. The example below shows the set up for document type FP. Here, the residence time has been set to 14 days. After the residence time has been set up, a variant needs to be defined. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 16/67 The example above shows the variant used by a customer for the daily archiving run for billing documents from POS older than 90 days. The variant attributes show that the date has been set up as a dynamic variable. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 17/67 2.4 Financial documents (BKPF, RFBLG, FAGLFLEXA) Financial documents are stored in several tables. The main tables are BKPF, RFBLG and FAGLFLEXA. BKPF is the header table, while RFBLG and FAGLFLEXA are the line item tables. While RFBLG is a cluster containing tables BSEG, BSEC, BSED, BSES, and BSET used for storing the line items of the classical General Ledger, table FAGLFLEXA is a transparent table used for storing the line items of the New General Ledger. The New General Ledger is available as from Release ECC5 (ERP 2004). However, it is not automatically activated when the system is upgraded from an older release to the latest release. The classical GL and the New GL are both active in a new installation. 2.4.1 Avoidance Not possible. 2.4.2 Summarization Summarization of FI document line items is mandatory for every high volume project, especially retail. The summarization is set up using transaction OBCY. Note that summarization is only relevant for the classical General Ledger (table BSEG), and not for the New General Ledger (table FAGLFLEXA). See OSS note 36353 for information concerning summarization via OBCY. Program RSUMSIFI can be used to simulate the summarization of the BSEG entries. With OSS note 1247473, the selection criteria of this program are expanded to allow the selection by period for the simulation. In the case of table FAGLFLEXA, there is no summarization transaction. The FAGLFLEXA profits from the summarization setup for the table BSEG. Furthermore, the data volume depends strongly on the setup of the Ledgers (leading and non-leading ledgers) and the number of characteristics and fields used for updates in customizing of the New GL. Therefore, utmost care must be taken when setting up the New GL. Once the system is productive, it is extremely difficult (even impossible) to revert the settings as this may lead to inconsistencies in FI-posting. In the case of WPUUMS-IDocs, we strongly recommend that each IDoc results in one article document and one billing document, to achieve the best possible summarization in FI. This is done by setting the number of line items in the article and billing documents in the POS Inbound profile to be identical to the number of articles in each IDoc. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 18/67 The figure below shows the documents generated by each WPUUMS-IDoc after the optimization measures were implemented. Through the summarization in FI, the number of line items has been reduced significantly. SAP AG2007, Data Archiving InSAP Retail / AndrewChew.Walter / 27 Changes t o POS I nbound Pr ocess WPUUMS 300 lines Arti cle doc. 300 lines Billi ng doc. 300 lines FI doc. ~10 lines CO doc. 1 line PCA doc. ~35 lines FI doc. ~10 lines PCA doc. ~20 lines Info-Structures (S012, S031, S121) Change to 300 Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 19/67 2.4.3 Deletion Not possible. 2.4.4 Archiving The archiving of financial documents is carried out via archiving object FI_DOCUMNT. Before FI documents can be archived, the set up of the residence times for the different FI document types must be completed in the customizing of the archiving object. From a purely technical perspective, FI documents can be archived when the period is closed. This implies that all FI documents older than 3 months can be archived. This situation applies to all FI documents belonging to accounts that are not open-item managed. Open item managed documents are never closed and as such, can never be archived. These documents need to be closed by the users on a regular basis. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 20/67 2.5 Tables FAGL_SPLINFO & FAGL_SPLINFO_VAL The activation of the document split functionality in the New GL leads to updates of tables FAGL_SPLINFO and FAGL_SPLINFO_VAL. These 2 tables are usually among the top 20 largest tables in a productive system. 2.5.1 Avoidance During the posting of billing documents to FI, high data volumes in FAGL_SPLINFO and FAGL_SPLINFO_VAL due to large number of tax lines were observed. To avoid unnecessary line items in these tables, OSS notes 1137444 and 1157202 must be applied. 2.5.2 Summarization Not possible. 2.5.3 Deletion Not possible. 2.5.4 Archiving The entries of in these tables are archived together with the main FI document tables BKPF, RFBLG, FAGLFLEXA. The archiving object is FI_DOCUMNT. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 21/67 2.6 Table BSIS The data volumes in table BSIS are strongly dependent on the number of accounts with line-item display function switched on. The accounts with this function can be easily identified in table SKB1 with field XKRES =X. 2.6.1 Avoidance We strongly recommend that the line item display functionality be switched on only for those accounts that really require it. According to OSS note 178487, the line item display functionality should be deactivated for the following account types: a. reconciliation accounts (SKB1-MITKZ <>SPACE) b. tax accounts (SKB1-MWSKZ =< or SKB1-MWSKZ =>) c. all sales revenue accounts, if CO-PA is active d. all material stock accounts e. all COGS accounts Refer to note 178487 for further details. 2.6.2 Summarization No direct summarization. The activation of FI summarization via transaction OBCY also leads to less data written into table BSIS. 2.6.3 Deletion Not possible. Entries can only be removed via archiving object FI_DOCUMNT. 2.6.4 Archiving The entries in table BSIS are removed by using archiving object FI_DOCUMNT. The setup of the residence times must be done in the customizing of the archiving object. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 22/67 2.7 Controlling Documents (COBK, COEP) 2.7.1 Avoidance Turn on the CO module only if necessary. Once CO has been turned on, updates are always active. If reconciliation ledger data is not required, the update can be suppressed by implementing the modification described in OSS note 182496. 2.7.2 Summarization Summarization of CO documents is set up via transaction OKBI. Details on OKBI are found in OSS note 147766. To determine the potential of summarization, program RARCCOA5 can be used to simulate the summarization of existing table entries. The simulation can be done for different fields. As such, it is necessary to identify the fields for which details are required. The output of this simulation 2.7.3 Deletion Not possible. Entries are removed via archiving. 2.7.4 Archiving Before the table entries are archived, report RARCCOA1 has to run, to determine the archiving objects to be used. The results of the analysis via RARCCOA1 are displayed via program RARCCOA2. However, the archiving objects shown in the analysis via RARCCOA1 are not always effective in keeping the data volumes down. Example: CO_COSTCTR. This archiving object allows archiving only on an annual basis. In general, it is advisable to use archiving object CO_ITEM on a monthly basis and then use other archiving objects to remove the remaining entries. Before archiving can be carried out, the residence times of the table entries must be set up in the customizing of the archiving objects. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 23/67 2.8 Profit Center Accounting document line items (GLPCA) The profit center accounting document line items are held in table GLPCA. This table is usually among the top 10 largest tables in the system. 2.8.1 Avoidance Do not activate the classical profit center accounting module if the New GL is active. The New GL incorporates the profit center accounting reporting functionalities. If a customer upgrades from an older release to a newer release where the New GL is available, a migration project of classical GL to the New GL can be done. Furthermore, the PCA reporting can be moved to the New GL. Once this is completed, the classical profit centre accounting (GLPCA) can be deactivated. OSS note 178919 provides tips on how to avoid unnecessary data. 2.8.2 Summarization Summarization of document line items (table GLPCA) can be set up via transaction 0KE8. OSS note 198519 provides a program for simulating the summarization of the entries in table GLPCA. 2.8.3 Deletion Not possible. 2.8.4 Archiving The archiving of the entries in table GLPCA is carried out using archiving object EC_PCA_ITM. In older releases, the archiving object is PCA_OBJ ECT. Both archiving objects do not require the definition of the residence time in customizing. The selection is simply defined in the variant used. It is recommended to run archiving of GLPCA entries on a monthly basis. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 24/67 2.9 ACCT*-tables In the standard delivery, the updating of table ACCTIT, ACCTHD and ACCTCR is active. These tables contain entries that are required for the subsequent posting of detailed data from MM to CO, or in some cases, the use of special Ledger. It is extremely seldom that these tables are required by customers for their business processes. Every goods movement line item (table MSEG) has 2 corresponding entries in table ACCTIT. OSS note 48009 provides detailed information on the purposes of these tables and how to deactivate them. 2.9.1 Avoidance The updating of these tables can be deactivated by the modification described in OSS note 48009. A strong indication that the entries are not required by the business can be won by looking at the table call statistics in transaction ST10 for all servers and all previous months (tables that are not buffered). The example below was extracted from a customers productive system and it shows that the tables are written (changes), but never read. This is an indication that the business does not require the entries in these tables. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Syst em: Al l ser ver s Not buf f er ed t abl es Ti me f r ame of anal ysi s : 02 / 2008 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | Tabl e | ABAP Pr ocessor r equest s | DB act i vi t y | | | Changes/ | Tot al | Di r ect | Seq. | Changes | Cal l s | Rows | | | Tot al ( %) | | r eads | r eads | | | af f ect ed | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | *Tot al * | | 10324152666 | 9243407, 722 | 795, 440, 205 | 285, 304, 739 | 3060748, 507 | 4322163, 011 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | ACCTCR | 100. 00 | 88, 003 | 0 | 0 | 88, 003 | 88, 071 | 8, 526, 444 | | ACCTHD | 100. 00 | 88, 003 | 0 | 0 | 88, 003 | 88, 071 | 88, 003 | | ACCTI T | 100. 00 | 88, 003 | 0 | 0 | 88, 003 | 88, 071 | 4, 263, 222 | Further confirmations that the tables are not required can be obtained by transaction ST03N. There, you simply need to check whether the transactions and programs mentioned in OSS note 48009 are in the statistics. 2.9.2 Summarization Not possible. 2.9.3 Deletion See OSS note 48009. 2.9.4 Archiving The archiving of the entries in the ACCT*-tables is done using archiving object MM_ACCTIT. This object does not require the definition of residence times. Due to the potentially high data volume, it is recommended to set up a daily archiving job, using the posting date as a dynamic variable. The selection by posting date should on one hand be held for as short a time as possible; but on the other hand, long enough to satisfy the business requirements. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 25/67 2.10 Table CKMI1 This table is updated for every goods movements carried out in the system. The huge number of entries in this table leads to performance loss during posting of goods movements that are relevant for valuation. 2.10.1 Avoidance The updating of this table can be deactivated by implementing note 1158752. For release <4.6C, apply OSS note 384757. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Syst em: Al l ser ver s Not buf f er ed t abl es Ti me f r ame of anal ysi s : 03 / 2008 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | Tabl e | ABAP Pr ocessor r equest s | DB act i vi t y | | | Changes/ | Tot al | Di r ect | Seq. | Changes | Cal l s | Rows | | | Tot al ( %) | | r eads | r eads | | | af f ect ed | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | CKMI 1 | 100. 00 | 97, 145 | 0 | 3 | 97, 142 | 98, 827 | 2, 480, 522 | If the table is not required by the business, the table call statistics in ST10 should be as above. 2.10.2 Summarization Not possible. 2.10.3 Deletion Not possible. 2.10.4 Archiving The archiving object CO_ML_IDX is used for removing entries in table CKMI1. It is not necessary to define residence time for the table entries. The archiving object allows archiving runs on a monthly basis. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 26/67 2.11 Tables IDOCREL & SRRELROLES These tables contain the links between IDocs and application objects. The table entries are not taken into account during the archiving of IDocs via archiving object IDOC and remain in the system although the IDocs no longer exist in the system. 2.11.1 Avoidance As described in OSS note 574349, links of type IDC4 are created if the partner type LS (logical system) is used for the communication between an external non-SAP and an SAP system. These links can cause major performance problems during the deletion job with report RSRLDREL and/or RSRLDREL2. 2.11.2 Summarization Not possible. 2.11.3 Deletion Entries are deleted with program RSRLDREL and/or RSRLDREL2 (OSS note 853035). A periodic job should be scheduled to delete the table entries regularly. The scheduling of the deletion job should be synchronized with the frequency of the IDoc archiving. For example, if IDocs are archived daily, then the deletion job should also be scheduled to run daily, but after the IDoc archiving and deletion jobs have been completed. Refer to OSS notes 706478, 707820, 505608, and 566765 for further details. 2.11.4 Archiving Not possible. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 27/67 2.12 Tables WPTST & WPLST All success and error messages shown in the POS Monitor (transaction WPER) are stored in these 2 tables. The entries are not considered during the archiving of IDocs with the archiving object IDOC and need to be deleted separately. 2.12.1 Avoidance Not possible. 2.12.2 Summarization Not possible. 2.12.3 Deletion The entries in these tables are deleted by programs RWPUDTST (table WPTST) and RWPUDLST (table WPLST). The scheduling of the deletion jobs should be in sync with the IDoc archiving jobs. If a daily archiving job is scheduled to remove correctly posted IDocs older than 7 days, then the deletion jobs for RWPUDLST and RWPUDTST should also run daily to remove the entries related to the archived IDocs only. 2.12.4 Archiving Not possible. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 28/67 2.13 Info-Structures (RIS/LIS tables Sxxx) xxx =001 to 499 Info-Structures are tables that originated during the time when BI was not available on the market. Tables S001 to S499 are SAP standard tables. Tables S500 and above are custom defined tables. These tables are used primarily for reporting purposes. A few applications require updates to Info-Structures. ApplicationInfo-Structures Perishables replenishmentS160 Open-To-BuyS110 Subsequent SettlementS015, S074, S111 Rough Workload EstimateS150, S152 Picking WavesS159 In a standard delivery, all info-structures are active by default. As such, it is strongly recommended that all info-structures be deactivated at the beginning of a project. This forces project team members to think carefully before they turn on the updating of any info-structures. 2.13.1 Avoidance All info-structures that are not required by the business can be deactivated in customizing. a. /NSPRO F5 Logistics General Logistics Information System (LIS) Updating Updating Control Activate Update Deactivate updates for all info-structures b. Sales and Distribution Sales Support (CAS) Sales Summary Set Document Display Uncheck field Statistics update desired for all line items As mentioned above, all info-structures should be deactivated at the beginning of a project so that team members are forced to knowingly activate each info-structure whenever a real business requirement arises. In the case of live customers, the table call statistics (ST10) for all previous months need to be analyzed. The following table shows that ST10 statistics for info-structures from a live customer. Period Table ABAP/IV Processor requests DB activity Changes/ Total Direct Seq. Changes Calls Rows Total(%) reads reads affected 03 2008 S003 0 4 0 4 0 6 0 03 2008 S004 0 4 0 4 0 7 0 04 2008 S004 0 7 0 7 0 13 0 05 2008 S004 0 2 0 2 0 4 0 06 2008 S004 0 1 0 1 0 2 0 07 2008 S004 0 0 0 0 0 0 0 08 2008 S004 0 1 0 1 0 2 0 09 2008 S004 0 0 0 0 0 0 0 03 2008 S009 50 110.676 55.338 0 55.338 166.257 110.744 04 2008 S009 50 301.842 150.921 0 150.921 453.205 301.966 05 2008 S009 50 271.520 135.760 0 135.760 407.796 271.663 06 2008 S009 50 308.338 154.169 0 154.169 462.916 308.453 07 2008 S009 50 332.842 166.421 0 166.421 499.705 332.971 08 2008 S009 50 314.816 157.408 0 157.408 472.675 314.941 09 2008 S009 50 132.326 66.163 0 66.163 198.688 132.382 Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 29/67 03 2008 S011 100 422.087 0 0 422.087 422.691 414.663 04 2008 S011 100 1.057.076 0 0 1.057.076 1.058.224 1.045.136 05 2008 S011 100 993.760 0 0 993.760 995.219 980.854 06 2008 S011 100 993.807 0 0 993.807 995.092 981.484 07 2008 S011 100 1.153.063 0 0 1.153.063 1.154.441 1.139.966 08 2008 S011 100 979.396 0 0 979.396 980.736 967.244 09 2008 S011 100 471.703 0 0 471.703 472.357 464.713 03 2008 S012 100 7.074.447 0 0 7.074.447 7.075.134 5.493.218 04 2008 S012 100 16.158.095 0 5 16.158.090 16.159.419 12.586.587 05 2008 S012 100 15.351.030 0 1 15.351.029 15.352.705 11.687.130 06 2008 S012 100 16.146.093 0 1 16.146.092 16.147.595 12.416.649 07 2008 S012 100 18.913.429 0 0 18.913.429 18.915.053 14.974.042 08 2008 S012 100 16.033.958 0 0 16.033.958 16.035.563 12.813.630 09 2008 S012 100 7.488.396 0 0 7.488.396 7.489.126 5.962.169 03 2008 S013 63,11 5.388.530 1.987.718 0 3.400.812 7.479.569 3.975.626 04 2008 S013 61,83 13.138.688 5.015.042 0 8.123.646 18.426.829 10.030.205 05 2008 S013 62,18 15.573.005 5.889.761 0 9.683.244 21.697.212 11.779.580 06 2008 S013 61,77 15.040.210 5.749.934 0 9.290.276 21.040.386 11.499.957 07 2008 S013 61,3 13.709.293 5.305.617 0 8.403.676 19.305.953 10.611.344 08 2008 S013 62,14 11.088.481 4.197.755 0 6.890.726 15.530.702 8.395.559 09 2008 S013 62,61 4.964.454 1.856.378 0 3.108.076 6.922.519 3.712.808 03 2008 S014 50 112.212 56.106 0 56.106 168.617 112.278 04 2008 S014 50 308.236 154.118 0 154.118 462.901 308.358 05 2008 S014 50 275.072 137.536 0 137.536 413.264 275.217 06 2008 S014 50 312.866 156.433 0 156.433 469.805 312.977 07 2008 S014 50 337.910 168.955 0 168.955 507.430 338.041 08 2008 S014 50 318.678 159.339 0 159.339 478.577 318.802 09 2008 S014 50 133.796 66.898 0 66.898 200.948 133.853 03 2008 S021 0 4 0 4 0 7 0 03 2008 S031 100 9.067.137 0 3 9.067.134 9.067.518 5.278.814 04 2008 S031 100 29.684.377 0 12 29.684.365 29.685.144 17.166.230 05 2008 S031 100 24.219.918 0 10 24.219.908 24.220.860 14.179.373 06 2008 S031 100 27.740.044 0 11 27.740.033 27.740.929 16.041.116 07 2008 S031 100 31.388.493 0 21 31.388.472 31.389.477 18.173.223 08 2008 S031 100 27.404.836 0 15 27.404.821 27.405.712 15.702.635 09 2008 S031 100 13.475.195 0 0 13.475.195 13.475.622 7.654.844 03 2008 S032 100 16.404.510 0 6 16.404.504 16.405.508 15.399.011 04 2008 S032 99,99 52.518.168 0 3.550 52.514.618 52.520.803 49.092.462 05 2008 S032 100 43.619.090 0 13 43.619.077 43.621.844 41.164.544 06 2008 S032 100 51.409.140 0 12 51.409.128 51.411.810 46.828.317 07 2008 S032 100 54.994.160 0 63 54.994.097 55.006.528 54.838.650 08 2008 S032 100 47.550.964 0 16 47.550.948 47.553.610 45.330.442 09 2008 S032 100 22.895.361 0 0 22.895.361 22.896.421 21.684.869 03 2008 S033 100 5.278.718 0 0 5.278.718 5.278.911 5.278.817 04 2008 S033 100 17.165.948 0 0 17.165.948 17.166.414 17.166.233 05 2008 S033 100 14.178.504 0 0 14.178.504 14.179.026 14.178.794 06 2008 S033 100 16.037.407 0 0 16.037.407 16.037.889 16.037.685 07 2008 S033 100 18.172.898 0 0 18.172.898 18.173.463 18.173.226 08 2008 S033 100 15.702.380 0 0 15.702.380 15.702.870 15.702.657 09 2008 S033 100 7.654.695 0 0 7.654.695 7.654.949 7.654.843 03 2008 S034 100 98.832 0 0 98.832 99.014 95.262 04 2008 S034 100 288.024 0 0 288.024 288.354 278.603 Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 30/67 05 2008 S034 100 374.404 0 0 374.404 374.810 365.394 06 2008 S034 100 258.465 0 0 258.465 258.811 249.457 07 2008 S034 100 329.052 0 0 329.052 329.418 319.176 08 2008 S034 100 292.450 0 0 292.450 292.854 281.852 09 2008 S034 100 119.955 0 0 119.955 120.137 115.155 03 2008 S035 100 13.222 0 0 13.222 13.384 11.105 04 2008 S035 100 41.472 0 0 41.472 41.778 35.145 05 2008 S035 100 39.533 0 0 39.533 39.908 34.572 06 2008 S035 100 38.717 0 0 38.717 39.040 33.261 07 2008 S035 100 46.222 0 0 46.222 46.562 40.359 08 2008 S035 100 44.816 0 0 44.816 45.188 37.743 09 2008 S035 100 19.464 0 0 19.464 19.640 17.157 03 2008 S039 0 4 0 4 0 8 0 04 2008 S039 0 2 0 2 0 4 0 05 2008 S039 0 3 0 3 0 6 0 06 2008 S039 0 0 0 0 0 0 0 07 2008 S039 0 5 0 5 0 9 0 08 2008 S039 42,86 7 0 4 3 13 12 09 2008 S039 0 0 0 0 0 0 0 03 2008 S061 100 249 0 0 249 281 246 04 2008 S061 100 1.987 0 0 1.987 2.076 1.976 05 2008 S061 100 2.204 0 0 2.204 2.296 2.193 06 2008 S061 100 2.324 0 0 2.324 2.407 2.315 07 2008 S061 100 1.848 0 0 1.848 1.948 1.834 08 2008 S061 100 1.813 0 0 1.813 1.907 1.804 09 2008 S061 100 825 0 0 825 887 817 03 2008 S062 100 248 0 0 248 302 270 04 2008 S062 100 1.961 0 0 1.961 2.111 2.033 05 2008 S062 100 2.189 0 0 2.189 2.352 2.264 06 2008 S062 100 2.304 0 0 2.304 2.453 2.375 07 2008 S062 100 1.834 0 0 1.834 2.000 1.912 08 2008 S062 100 1.801 0 0 1.801 1.967 1.880 09 2008 S062 100 818 0 0 818 920 867 03 2008 S066 0 12 0 12 0 26 0 08 2008 S066 0 1 0 1 0 3 0 03 2008 S067 0 12 0 12 0 19 0 08 2008 S067 0 1 0 1 0 2 0 04 2008 S071 0 1 0 1 0 2 0 05 2008 S071 0 0 0 0 0 0 0 08 2008 S091 0 0 0 0 0 0 0 03 2008 S111 100 212 0 0 212 271 2.663 04 2008 S111 100 183 0 0 183 220 1.940 05 2008 S111 100 70 0 0 70 96 503 06 2008 S111 100 157 0 0 157 190 1.390 07 2008 S111 100 211 0 0 211 258 5.103 08 2008 S111 100 124 0 0 124 162 1.435 09 2008 S111 100 69 0 0 69 89 520 03 2008 S123 100 318.975 0 0 318.975 319.266 311.894 04 2008 S123 100 918.040 0 0 918.040 918.608 902.435 05 2008 S123 100 846.579 0 0 846.579 847.216 830.729 06 2008 S123 100 918.570 0 0 918.570 919.079 901.353 07 2008 S123 100 953.979 0 0 953.979 954.552 936.196 Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 31/67 08 2008 S123 100 921.387 0 0 921.387 921.948 903.158 09 2008 S123 100 404.009 0 0 404.009 404.255 392.154 03 2008 S124 100 3.120.258 0 0 3.120.258 3.120.608 2.170.232 04 2008 S124 100 9.045.350 0 0 9.045.350 9.046.031 6.320.454 05 2008 S124 100 8.869.718 0 0 8.869.718 8.870.503 6.100.252 06 2008 S124 100 10.119.952 0 0 10.119.952 10.120.572 6.993.216 07 2008 S124 100 10.720.966 0 0 10.720.966 10.721.719 7.523.487 08 2008 S124 100 10.587.379 0 0 10.587.379 10.588.071 7.359.724 09 2008 S124 100 4.658.581 0 0 4.658.581 4.658.873 3.141.778 03 2008 S135 0 1 0 1 0 3 0 04 2008 S135 50 20 0 10 10 31 14 05 2008 S135 0 2 0 2 0 3 0 06 2008 S135 0 1 0 1 0 2 0 07 2008 S135 58,82 17 0 7 10 23 10 08 2008 S135 0 0 0 0 0 0 0 03 2008 S999 100 8.594.709 0 0 8.594.709 8.595.096 5.249.665 04 2008 S999 100 28.996.466 0 0 28.996.466 28.997.246 17.206.044 05 2008 S999 100 22.848.597 0 0 22.848.597 22.849.531 14.109.766 06 2008 S999 100 26.300.363 0 0 26.300.363 26.301.211 15.963.577 07 2008 S999 100 30.371.134 0 0 30.371.134 30.372.140 18.225.920 08 2008 S999 100 25.828.656 0 0 25.828.656 25.829.529 15.649.537 09 2008 S999 100 13.084.692 0 0 13.084.692 13.085.126 7.672.875 All info-structures with WRITE access only (100% changes) can theoretically be deactivated immediately. Next, check tables MCRSV and MCSI. If info-structures are used for reporting purposes, selection versions are usually created. These selection versions are stored in tables MCRSV and MCSI. If these tables are empty, it is an indication that the info-structures are not used by the business for reporting. Nevertheless, the business needs to provide the necessary information of the reporting requirements. 2.13.2 Summarization Not possible. 2.13.3 Deletion Not possible. 2.13.4 Archiving There are no standard archiving objects for the info-structures. The archiving objects have to be generated via transaction MCSX. The generated archiving objects are MC_Sxxx, where Sxxx is the info-structure name. Use transaction SARA to schedule archiving jobs for the archiving objects MC_Sxxx. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 32/67 2.14 Application logs (BALHDR, BALDAT) Additional warnings and error messages arising from the applications may be written when posting sales IDocs. These messages are stored in tables BALHDR and BALDAT. 2.14.1 Avoidance Not possible. 2.14.2 Summarization Not possible. 2.14.3 Deletion Transaction SLG2 (program SBAL_DELETE) is used for deleting application logs. In the selection screen, the and logs which can be deleted before the expiry date radio button should be flagged because the majority of the logs normally have the expiry date 31.12.9999. In the selection variant, it is recommended to set up the fields creation date: from and creation date: to as dynamic variables, as shown in the example below. Create a secondary index on table BALHDR with fields MANDANT, ALDATE. Due to the potentially high volume of application logs, we recommend that you schedule a daily deletion job. 2.14.4 Archiving If the business requires application logs to be archived, instead of simply deleted, the archiving object BC_SBAL should be used. This archiving object does not require the set up of residence times for application logs in the customizing of this object. The creation dates (from/to) should be set up as dynamic variables Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 33/67 Create a secondary index on table BALHDR with fields MANDANT, ALDATE. Schedule a daily archiving job. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 34/67 2.15 Work Items (SWWWI* tables) As from release 4.6C, all links between IDocs and application data are held in tables IDOCREL and SRRELROLES. Work items are no longer used for this purpose. However, this does not prevent the applications generating work items when problems occur during the creation of the application data. 2.15.1 Avoidance Not possible. 2.15.2 Summarization Not possible. 2.15.3 Deletion Work items can be deleted with program RSWWWIDE. The Creation date field should be set up as a dynamic variable. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 35/67 Depending on the volume of work items generated per day, it may be necessary to schedule a daily deletion job. 2.15.4 Archiving If the business requires work items to be archived, instead of deleted, the archiving object WORKITEM should be used. Archiving object WORKITEM does not require the setup of residence times for work items. It is recommended to set up the fields Creation Date and End Date as dynamic variables. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 36/67 Depending on the volume, it may be necessary to set up a daily archiving job. Note that the archiving of work items only picks up work items with statuses completed and cancelled (logically deleted). It has been observed at several customers that the archiving of work items was ineffective because the work item statuses were never set to completed and/or cancelled. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 37/67 3 Store Replenishment Cycle The above figure shows the typical store replenishment cycle. The cycle begins with the POS Inbound process in which sales data is processed and stock levels are updated. Next, the replenishment planning/calculation are carried out. This results in purchase requisitions and/or purchase orders being created. There are 2 types of purchase orders stock transfer orders and purchase orders. While stock transfer orders are fulfilled by the warehouses, purchase orders are sent to the external vendors. Next, outbound deliveries are created with reference to the stock transfer orders. These outbound deliveries are necessary to inform the warehouse(s) of the requirements of each individual store. Depending on the configuration of the process, transport orders can be created for the goods movements within the warehouse(s) picking and moving the goods to the shipping point(s). The usage of Handling Units is not considered in this simple scenario. Once the goods have been picked and moved to the shipping point, warehouse goods issues are posted. This will reduce the stock levels at the warehouse(s). Finally, when the goods arrive at the stores, store goods receipts are posted. Store goods receipts are posted with reference to the stock transfer orders and purchase orders. SAP AG 2007, Data Archiving In SAP Retail / AndrewChew.Walter / 35 St ore Repl eni shment Cyc l e POS Upl oad Store Repl enishment Pl anni ng Creat e outbound del i veri es Create t ransport orders (opti onal ) Post warehouse goods i ssues Post store goods recei pts Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 38/67 The different documents and their corresponding tables are shown in the following figure. Documents related to, or mentioned in the section POS Inbound are not be considered in this section. The reason for this is that the handling of these documents is similar or identical to the case POS Inbound. SAP AG 2007, Data Archiving In SAP Retail / AndrewChew.Walter / 36 St ore Repl eni shment Cyc l e Document s & Tabl e Ent ri es POS Upload St ore Repleni shment Planni ng Creat e outbound deli ver ies Cr eat e transpor t orders (optional) Post warehouse goods issues Post store goods receipt s IDocs: EDIDC, EDI40, EDIDS Arti cl e doc.: MKPF, MSEG Bi l l i ng doc.: VBRK, VBRP FI-doc.: BKPF, RFBLG, FAGLFLEXA, FAGL_SPLINFO, FAGL_SPLINFO_VAL BSIS, BSAS CO-doc.: COBK, COEP PCA-doc.: GLPCA ACCT*-Tabl es Li nks between IDocs and appl i cat i ons: SRRELROLES, IDOCREL Worki t ems: SWWWIHEAD, .... Appl i cati on l ogs: BALHDR, BALDAT Info-Structures (Sxxx) Purchase requi si ti ons: EBAN Purchase orders: EKKO, EKPO Change document s: CDHDR, CDCLS Appli cati on l ogs: BALHDR, BALDAT Info-Struct ures (Sxxx) Out bound Del iveries: LIKP, LIKPS Change documents: CDHDR, CDCLS Appl icati on l ogs: BALHDR, BALDAT Inf o-Struct ures (Sxxx) Transport orders: LTAK, LTAP Change document s: CDHDR, CDCLS Appl i cat i on l ogs: BALHDR, BALDAT Info-Structures (Sxxx) Arti cle doc.: MKPF, MSEG FI-doc.: BKPF, RFBLG, FAGLFL EXA FAGL_SPLINFO, FAGL_SPLINFO_VAL BSIS, BSAS Change doc.: CDHDR, CDCLS Appl i cat i on Logs: BALHDR, BALDAT ACCT*-tabl es Info-St ructures (Sxxx) Art i cl e doc.: MKPF, MSEG FI-doc.: BKPF, RFBLG, FAGL FLEXA FAGL_SPLINFO, FAGL_SPLINFO_VAL BSIS, BSAS Change doc.: CDHDR, CDCLS Appl i cati on Logs: BALHDR, BALDAT ACCT*-tabl es Inf o-Struct ures (Sxxx) Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 39/67 3.1 Purchase Requisitions (EBAN) Store replenishment planning can result in purchase requisitions being created. It depends strongly on the setup of the replenishment process. 3.1.1 Avoidance If transaction WRP1 is used for the store replenishment, purchase requisitions can be avoided through the customizing of the Store Order. /NSPRO F5 Materials Management Consumption-based Planning Replenishment Control Follow-on Documents (via Store Order) The following figure shows an example of the SAP standard proposal in customizing of the Store Order. There, purchase orders are created instead of purchase requisitions. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 40/67 3.1.2 Summarization Not possible. 3.1.3 Deletion Not possible. 3.1.4 Archiving During the conversion of purchase requisitions to purchase orders via transaction ME59, the field Set Requisitions to Closed should be set to 2. Purchase requisitions are automatically closed when the generation of purchase orders has been successful. This setting is beneficial for the archiving of purchase requisitions because a prerequisite for archiving object MM_EBAN is that the purchase requisitions must be closed. Open purchase requisitions are not archived. Archiving object MM_EBAN requires residence time for each purchase requisition type to be defined in the customizing of the object. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 41/67 The values 10 and 20 in residence time 1 and 2 are default values and should be changed to meet business requirements. It is recommended that the one-step procedure be used. This means that only residence time 1 is required and residence time 2 can be set to 0. The difference between the one-step and two-step procedures is as follows: In the one-step procedure, the system sets the deletion flags for completed and closed purchase requisitions and archives them if the residence time 1 is fulfilled. In the two-step procedure, the system sets the deletion indicator for completed and closed purchase requisitions when residence time 1 is fulfilled. It does not archive the purchase requisitions immediately. These are archived in the next archiving run if the residence time 2 is fulfilled. 3.2 Purchase Orders (EKKO, EKPO) Store replenishment results in stock transfer orders and purchase orders. Stock transfer orders are fulfilled by the warehouses while purchase orders (or vendor orders) are fulfilled by external vendors. 3.2.1 Avoidance Not possible. 3.2.2 Summarization Not possible. 3.2.3 Deletion Not possible. 3.2.4 Archiving The archiving of stock transfer orders and vendor orders is done using archiving object MM_EKKO. Residence times have to be defined for each combination of order type and item category. The default value of all residence times is 30 days, as shown in the example below. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 42/67 The meaning of residence time 1 and residence time 2 is identical to those in archiving object MM_EBAN for purchase requisitions. Again, it is recommended to use the one-step procedure to archive stock transfer orders and purchase orders. The SAP standard order type for stock transfer order is UB, while the standard order type for vendor order is NB. The residence times for UB should be shorter than those for NB. Normally, UBs are fulfilled by the warehouses within a period of about a week. As such, it is sufficient to keep stock transfer orders online for a month. In the case of purchase orders to vendors, the residence times depend strongly on the business processes defined. If for example, subsequent settlement is used and the rebate agreements with vendors are valid for one year, many customers would like to keep the purchase orders until the final rebate settlement is completed. However, the purchase orders are not required for the rebate settlement. These purchase orders are only required to build the statistics relevant for the rebate settlement in table S111. This situation only occurs when a rebate agreement with a vendor is created in the later part of the year, but the validity of the agreement has to be back-dated to the beginning of the year. Therefore, it is strongly recommended that the rebate agreements be created as early in the year as possible to prevent the archiving backlog for purchase orders from becoming too large. The following example shows a variant of archiving object MM_EKKO for archiving stock transfer orders. This variant will pick up all orders with order type UB and document dates less than or equal to current date minus 35 days. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 43/67 The Key Date for Quotation Date field is ignored when archiving purchase orders because this is relevant only for quotations. It is recommended that a daily archiving job be scheduled for archiving stock transfer orders. In the case of vendor orders, it may be necessary to schedule a daily archiving job if the volumes are high. Otherwise, a weekly job should be sufficient. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 44/67 3.3 Change Documents (CDHDR, CDCLS) Change documents are created when a purchase requisition or purchase order is created or updated. Change documents also arise during the creation and update of deliveries, as well as during master data and price maintenance. Table CDCLS is usually among the top 20 fastest growing tables in a Retail environment. 3.3.1 Avoidance The following list shows the different types (OBJ ECTCLAS) of change documents created by a customer. OBJ ECTCLAS #Entries COND_A 83.392.799 ADRESSE 6.815.547 MAT_FULL 4.676.681 EINKBELEG 4.117.305 LIEFERUNG 3.923.894 VERKBELEG 3.166.077 BANF 2.602.251 BELEG 2.315.976 INFOSATZ 1.790.371 ANLA 1.664.961 BELEGR 1.189.519 WLK1 1.154.827 TRANSPORT 689.253 MATERIAL 606.602 ORDERBUCH 453.824 DEBI 371.996 HANDL_UNIT 256.326 KRED 203.982 SACH 137.016 ASMODULE 49.347 PFCG 24.829 BETRIEB 22.383 FAKTBELEG 16.219 SETS 13.270 KOSTL 11.932 BANK 10.744 ADRESSE3 8.361 PRCTR 4.949 WREFA 4.268 BELEGD 3.173 KLASSE 1.715 STUE 893 STUE_V 892 NRINTERVAL 576 WBASISWG 499 KSTAR 496 ALLOCATION 250 PROJ 240 BELEGV 223 INCOMINGINVOICE 66 Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 45/67 EQUI 57 FEATURE 30 RKAUFTRAG 6 CMDT_PC 5 MELDUNG 5 CHARGE 3 NRKROBJ 3 LSTAR 2 LAYOUT_MOD 1 PROJ S 1 While most of the change documents cannot be avoided during normal operations, change documents due to article listing (OBJ ECTCLAS =WLK1, ASMODULE, WBASISWG, LAYMOD) can be avoided if the listing is carried out via transaction WSM3 or WSM8. The selection screens of these 2 transactions have the option for suppressing the generation of change documents. The following diagram shows the selection screen of transaction WSM3. During an initial data load from legacy system to SAP, it is strongly recommended that change documents be avoided. However, this requires minor modifications to certain ABAP programs. Contact SAP for further details since these modifications are not part of standard delivery. 3.3.2 Summarization Not possible. 3.3.3 Deletion Report RWSORT54 is used for deleting change documents due to listing (OBJ ECTCLAS =WLK1, ASMODULE, WBASISWG, LAYMOD). Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 46/67 Program RSCDOK99 can be used for deleting all change documents. 3.3.4 Archiving Change documents are normally archived whenever archiving runs are carried out for the main documents such as purchase requisitions, purchase order, deliveries, and so on. In certain business cases, it may be necessary to use archiving object CHANGEDOCU to archive change documents only (example OBJ ECTCLAS MAT_FULL). The archiving object CHANGEDOCU does not require the set up of residence times for change documents in the customizing of the archiving object. The following example shows the variant for archiving change documents with OBJ ECTCLAS =COND_A that are older than 30 days. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 47/67 Depending on the volume, it may be necessary to schedule a daily archiving run for change documents. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 48/67 3.4 Outbound Deliveries (LIKP, LIPS) Outbound deliveries are created with reference to stock transfer orders. These are purchase orders for stores that are fulfilled by the warehouse. 3.4.1 Avoidance Not possible. 3.4.2 Summarization Not possible. 3.4.3 Deletion Not possible. 3.4.4 Archiving Deliveries are archived using archiving object RV_LIKP. Residence times for the different delivery types have to be set up in the customizing of the archiving object. The pre-processing step of this archiving object sets the deletion indicator for deliveries that are completed and can be archived. The selection screen has the option to use the date of last change for the checking of the residence time. This option is also available in the archiving WRITE-program. Note that deliveries can only be archived when there are no billing documents and transport orders assigned to them. If there are transport orders and billing documents assigned, these documents have to be archived first. Further, if handling units are used in the business process, the handling units must be archived before the transport orders. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 49/67 3.5 Transport Orders (LTAK, LTAP) Transport orders are created with reference to the outbound deliveries. These are required for the picking and packing of the goods to be shipped to the stores. 3.5.1 Avoidance This depends strongly on the set up of the business process. In the case where an external warehouse management system is used, transport orders are optional. 3.5.2 Summarization Not possible. 3.5.3 Deletion Not possible. 3.5.4 Archiving Transport orders are archived using archiving object RL_TA RL_TA does not require the setting up of residence times of transport orders and requirements. All completed and closed transport orders are considered by the archiving object. The residence time must only be specified in the variant of the WRITE-program. The diagram above shows the selection screen of the WRITE-program for archiving object RL_TA. The residence time of 200 days is the system default value and must be changed to meet business requirements. Note that transport orders cannot be archived if related handling units still exist in the system. The handling units must be archived first. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 50/67 4 Warehouse Replenishment Cycle The warehouse replenishment cycle begins with a weekly or daily forecast. Each forecast run creates a new version of the forecast data to be used later for the calculations of the requirements at each warehouse. The calculations of the requirements of the warehouses result in purchase requisitions being created. These purchase requisitions are checked and released by the purchasing department members. After they are released, the purchase requisitions are converted to purchase orders. The term conversion does not literally mean converting a purchase requisition to a purchase order. It simply means that purchase orders are created with reference to the purchase requisitions. The conversion is done via transaction ME59. The purchase orders are then sent to external vendors, either via fax or, in the case of EDI vendors, through IDocs. When the vendors deliver the goods to the warehouses, warehouse goods receipts are posted. The posting is carried out with reference to the purchase orders. Finally, invoice verification is carried out to ensure that the goods and quantities received match the information in the purchase orders. After that, payments are made to the vendors. SAP AG 2007, Data Archiving InSAP Retail / Robert Peebles / 35 War ehouse Repl eni shment Cycl e Forecast (opti onal) Material Requi rement Pl anni ng (MRP) + Pur. Req. Convert Purchase Requi si ti ons to Purchase Orders Send Order to vendors Post warehouse goods receipts Invoi ce Veri fication & Payment Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 51/67 The following figure shows the different types of documents created This section focuses only on documents that have not been mentioned in previous sections. 4.1 Forecast data (PROP, PRON, PROW, PROF, PROH) 4.1.1 Avoidance This depends solely on the definition of the business process. Although it is possible to run replenishment without the use of forecast data, it is normally the case in all projects that forecast data is used for the replenishment. It is recommended that forecast should not be carried out for all article/site combinations on a daily basis. In most cases, a weekly forecast is sufficient to satisfy the business requirements. Each forecast run creates a new version of the forecast data. 4.1.2 Summarization Not possible. SAP AG 2007, Data Archiving In SAP Retail / AndrewChew.Walter / 39 War ehouse Repl eni shment Cycl e doc ument s creat ed Forecast data Purchase requi si tions Change documents Appl i cati on l ogs Info-Structures Purchase Orders Change documents Appli cati on logs Info-Structures IDocs Art icle documents FI-documents CO-documents PCA-documents Change documents Appl ication logs Info-Structures Vendor invoices FI-documents CO-documents PCA-documents Change documents Application logs Info-Structur es Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 52/67 4.1.3 Deletion Old forecast data should be deleted regularly. The frequency of the deletion job should be in sync with the frequency in which forecast is carried out. If for example forecast is carried out weekly, the deletion job should also run on a weekly basis. The deletion should be carried out before the forecast run. Report RMCPMLOE can be used to delete old forecast data. However, it does not delete entries in table PRON. Therefore, it is better to use program RMPR2001 instead. The following diagram shows an example of a variant of report RMPR2001. The above example is used for deleting all forecast data for all sites (stores and warehouses) on a weekly basis. However, the latest version of the forecast data for each article/site combination is left untouched (Delete all versions =BLANK). The field Deletion forecast model 0 only means that only article/site combinations for which forecast is no longer required (forecast model 0) are deleted. The field Display deletion log should be avoided as this has an impact on the runtime of the deletion job. If this field is not flagged, the system will only show the total number of entries deleted from each table. Otherwise, the number of entries for each article/site combination will be displayed. 4.1.4 Archiving Not possible. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 53/67 4.2 Vendor Invoices (WBRK, WBRP) Vendor invoices are captured so the logistics invoice verification process can take place. 4.2.1 Avoidance Not possible. 4.2.2 Summarization Not possible. 4.2.3 Deletion Not possible. 4.2.4 Archiving Vendor invoices are archived using archiving object WLF. This archiving object does not require the definition of residence times for the different vendor billing types in the customizing of the archiving object. The following diagram shows a variant for the WRITE-program of the archiving object. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 54/67 In the above example, all billing types for company code PS01 are taken into consideration if their posting dates are older than or equal to the current date minus 180 days. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 55/67 5 Customer (Sales) Orders The figure shows the typical process chain in a customer ordering scenario. It is based on the assumption that these customer orders or sales orders are fulfilled by the warehouse. Sales orders are created either via transaction VA01, or through IDocs. Next, with reference to these sales orders, outbound deliveries via transaction VL10c are generated. For the picking of the goods at the warehouse, transport orders are created for each outbound delivery. Next, billing documents need to be generated. These billing documents need to accompany the shipping documents included in the deliveries. Finally, when the goods leave the warehouse, warehouse goods issues are posted. SAP AG 2007, Data Archiving In SAP Retail / Robert Peebles / 37 Cust omer (Sal es) Or der s Create Sales Orders Create Out bound Del iveries Create Transport Orders Create Bill ing Documents Post Warehouse Goods Issues Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 56/67 The following figure shows the different documents generated within each step of the process chain. The following section focuses on documents that were not considered in previous sections of this document. 5.1 Sales orders (VBAK, VBAP) 5.1.1 Avoidance Not possible. 5.1.2 Summarization Not possible. 5.1.3 Deletion Not possible. SAP AG 2007, Data Archiving In SAP Retail / AndrewChew.Walter / 42 Cust omer (Sal es) Or ders doc ument t ypes Sales Orders Change documents Applicat ion l ogs Info-Structures Outbound Del iveries Change documents Appl ication logs Info-St ructur es Transport Orders Change document s Application logs Info-Structures Bil ling Documents Application logs Info-Structures Arti cle document s FI-documents CO-document s PCA-documents Change document s Application l ogs ACCT*-tables Info-Structures Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 57/67 5.1.4 Archiving Sales orders are archived using archiving object SD_VBAK. Residence times have to be defined for each sales document type in the customizing of the archiving object. Note that deliveries have to be archived prior to sales orders. The following figures show an example of a variant for the WRITE-program. Additional options in the selection screen are: a. Change date: Residence time If this field is flagged, the calculation of the residence time is based on the date of last change and no longer on the creation date. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 58/67 b. Check Flow Documents Residence If this field is flagged, the calculation of the residence time is based on the creation or change date of the last document in the document-flow. c. Check purchase order If this field is flagged, the system will check whether purchase order and the corresponding purchase requisition still exist on the system. d. Check FI-document If this field is set, the system will check whether all accounting documents belonging to a sales order have been balanced. Note that flagging additional options (b), (c), and/or (d) will increase the runtime of the archiving job. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 59/67 6 POS Download / Assortment List The POS download and assortment list are 2 ways of sending article information, promotion information, and prices from the headquarters down to the stores. Normally, one either uses POS download or the assortment list. However, there are some customers who use both POS download and the assortment list. In these cases, the assortment list is used for specific articles only, due to usage of SAP Retail Store functionalities, and the POS download is used for sending the article/price information to the stores. If Retail Store functions are used, the assortment list must be used. Otherwise, the decision to use POS download or assortment list or both depends strongly on the business processes and the information required by the stores. When POS download is used, IDoc message types WP_PLU and WP_EAN are used. In the case of the assortment list, the assortment list IDoc with message type WBBDLD is used. The following figure shows the steps within the POS download / assortment list process. SAP AG 2007, Data Archiving In SAP Retail / AndrewChew.Walter / 44 POS Downl oad / Assor t ment Li st Arti cl e mai ntenance Pri ce maintenance Promoti on Create outgoing IDocs Create assortment l ists Send IDocs to stores Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 60/67 The following diagram shows the different types of documents created during each step of the POS download / assortment list process. This section focuses on documents that were not mentioned in previous sections. 6.1 Change Pointers (BDCP. BDCPS, BDCP2, WIND) During the maintenance of articles and prices, change documents are generated. These in turn trigger the creation of change pointers. The change pointers are necessary for the creation of the outgoing IDocs in the POS download and for the creation of assortment lists and assortment list IDocs. 6.1.1 Avoidance Change pointers should be activated for message types that are really relevant for the download process. The (de-)activation of change pointers is carried out via transaction SALE. There, change pointers have to be activated in general as the first step. In the next step, change pointers are deactivated/activated for specific message types. SAP AG 2007, Data Archiving In SAP Retail / AndrewChew.Walter / 45 POS Downl oad / Assor t ment Li st document s creat ed Change documents Change poi nters IDocs Assort ment l ist IDoc status entri es Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 61/67 Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 62/67 For certain message types, it is possible to switch the storage of the change pointers from table BDCP and BDCPS to table BDCP2. This switch is due to performance reasons. In the case of price changes, it is possible to activate the direct worklist in customizing. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 63/67 /NSPRO Sales and Distribution POS Interface Outbound Controlling Alternative Condition Change Analyses Using Worklist Direct Entry for Creating Worklist Activation of the Direct Entry for Creating the Worklist Here, the direct entry in the wordlist for document adjustment following condition changes (table WIND) for document category 55 (POS Outbound) is set. In the case of the assortment list, document category 50 is used. Once the indicator is set, price changes with will be written into a worklist in table WIND, instead of the change pointer tables. The advantage of the WIND logic is the performance improvement. Note that the standard assortment list does not work with WIND logic. Only the HPR version of the assortment list works with the WIND logic. 6.1.2 Summarization Not possible. 6.1.3 Deletion Deletion of change pointers is carried out using report RBDCPCLR (transaction BD22). There, you have the option of deleting processed change pointers. However, change pointers are not set to processed during the POS download or the assortment list processing. The status of the change pointers has to be set to processed with program RWDPOSRS (transaction WDSR). Note that report RWDPOSRS also deletes WIND entries. The following diagram shows a variant for report RWDPOSRS to set change pointers for POS download to processed. The Do not delete IDocs field has to be flagged because IDocs are removed using archiving object IDOC. Furthermore, flagging this field has an impact on the runtime of this program. The next diagram shows a variant of report RBDCPCLR to delete change pointers. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 64/67 The fields for date have been set up as dynamic variables. In the case of obsolete change pointers, it has been set to current day minus 8 days. This means that all change pointers older than 8 days are deleted, regardless of their statuses. Even unprocessed change pointers will be deleted. In the case of processed change pointers, the date field has been set to current date minus 1 day. This means that all change pointers older than 1 day with status processed are deleted. The reorganizing of the statuses and the deletion of the change pointers should be scheduled to run daily. The scheduled job should contain 2 steps; with the first step for report RWDPOSRS and a second step for report RBDCPCLR. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 65/67 Running a daily reorganization and deletion job helps in preventing performance degradation of the POS download / assortment list process. 6.1.4 Archiving Not possible. 6.2 Assortment List (WBBH, WBBP) 6.2.1 Avoidance Not possible. 6.2.2 Summarization No summarization. 6.2.3 Deletion Old assortment list versions can be deleted using program RWBBVDEL (transaction WBBR). However, we recommend that you use report RWBBVDEL_HPR instead because it can be scheduled as a batch job. RWBBVDEL does not run in batch. The following diagrams show an example variant of report RWBBVDEL_HPR to delete expired versions of all assortment list types, except for assortment list type D. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 66/67 See also OSS note 863078. In the case where the HPR version of the assortment list is used, WIND entries can be automatically deleted when creating a change version of the assortment list. 6.2.4 Archiving Not possible. Best Practice Data Volume Management for Retail 2009 SAP AG - Data Volume Management for Retail page 67/67 Copyright 2009 SAP AG. All Rights Reserved No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. J ava is a registered trademark of Sun Microsystems, Inc. J avaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warrant.