Your SlideShare is downloading. ×
Best PracticeData Volume Management for Retail                  Dietmar-Hopp-Allee 16                    D-69190 Walldorf ...
Best PracticeData Volume Management for RetailDate                Alteration Reason                       Version22.09.200...
Best PracticeData Volume Management for Retail   2.8.1 Avoidance                                        23   2.8.2 Summari...
Best PracticeData Volume Management for Retail   3.2.1 Avoidance                                        41   3.2.2 Summari...
Best PracticeData Volume Management for Retail     6.2.4 Archiving                                      66© 2009 SAP AG - ...
Best PracticeData Volume Management for Retail1                          Management SummaryThis paper describes a few main...
Best PracticeData Volume Management for Retail2                        POS InboundThe POS Inbound process is not only one ...
Best PracticeData Volume Management for Retail      b.     CKMI1      c.     IDOCREL, SRRELROLES      d.     WPTST, WPLST ...
Best PracticeData Volume Management for Retail02       WP_EAN             04      2008 203       ORDERS             03    ...
Best PracticeData Volume Management for RetailIn the case of erroneous IDocs, a second variant should be set up to pick up...
Best PracticeData Volume Management for Retail2.2               Article Documents (MKPF, MSEG)The line item table for arti...
Best PracticeData Volume Management for RetailIn the example above, the residence times of all article document types in a...
Best PracticeData Volume Management for RetailNote that some customers are archiving all POS article documents older than ...
Best PracticeData Volume Management for Retail2.3               Billing Documents (VBRK, VBRP)The line item table for bill...
Best PracticeData Volume Management for RetailWith field billing set to “1”, billing documents are created during runtime ...
Best PracticeData Volume Management for RetailThe example above shows the variant used by a customer for the daily archivi...
Best PracticeData Volume Management for Retail2.4               Financial documents (BKPF, RFBLG, FAGLFLEXA)Financial docu...
Best PracticeData Volume Management for Retail                                                                            ...
Best PracticeData Volume Management for Retail2.4.3             DeletionNot possible.2.4.4             ArchivingThe archiv...
Best PracticeData Volume Management for Retail2.5               Tables FAGL_SPLINFO & FAGL_SPLINFO_VALThe activation of th...
Best PracticeData Volume Management for Retail2.6               Table BSISThe data volumes in table BSIS are strongly depe...
Best PracticeData Volume Management for Retail2.7               Controlling Documents (COBK, COEP)2.7.1             Avoida...
Best PracticeData Volume Management for Retail2.8               Profit Center Accounting document line items (GLPCA)The pr...
Best PracticeData Volume Management for Retail2.9                     ACCT*-tablesIn the standard delivery, the updating o...
Best PracticeData Volume Management for Retail2.10                    Table CKMI1This table is updated for every goods mov...
Best PracticeData Volume Management for Retail2.11              Tables IDOCREL & SRRELROLESThese tables contain the links ...
Best PracticeData Volume Management for Retail2.12              Tables WPTST & WPLSTAll success and error messages shown i...
Best PracticeData Volume Management for Retail2.13                Info-Structures (RIS/LIS – tables Sxxx)xxx = 001 to 499I...
Best PracticeData Volume Management for Retail03 2008     S011     100           422.087          0           0       422....
Best PracticeData Volume Management for Retail05 2008     S034     100           374.404          0   0    374.404   374.8...
Best PracticeData Volume Management for Retail08 2008     S123     100           921.387          0      0       921.387  ...
Best PracticeData Volume Management for Retail2.14              Application logs (BALHDR, BALDAT)Additional warnings and e...
Best PracticeData Volume Management for RetailCreate a secondary index on table BALHDR with fields MANDANT, ALDATE.Schedul...
Best PracticeData Volume Management for Retail2.15              Work Items (SWWWI* tables)As from release 4.6C, all links ...
Best PracticeData Volume Management for RetailDepending on the volume of work items generated per day, it may be necessary...
Best PracticeData Volume Management for RetailDepending on the volume, it may be necessary to set up a daily archiving job...
Best PracticeData Volume Management for Retail3                        Store Replenishment Cycle        Store Replenishmen...
Best PracticeData Volume Management for RetailThe different documents and their corresponding tables are shown in the foll...
Best PracticeData Volume Management for Retail3.1               Purchase Requisitions (EBAN)Store replenishment planning c...
Best PracticeData Volume Management for Retail3.1.2             SummarizationNot possible.3.1.3             DeletionNot po...
Best PracticeData Volume Management for RetailThe values 10 and 20 in residence time 1 and 2 are default values and should...
Best PracticeData Volume Management for RetailThe meaning of residence time 1 and residence time 2 is identical to those i...
Best PracticeData Volume Management for RetailThe “Key Date for Quotation Date” field is ignored when archiving purchase o...
Best PracticeData Volume Management for Retail3.3               Change Documents (CDHDR, CDCLS)Change documents are create...
Best PracticeData Volume Management for RetailEQUI                     57FEATURE                  30RKAUFTRAG             ...
Best PracticeData Volume Management for RetailProgram RSCDOK99 can be used for deleting all change documents.3.3.4        ...
Best PracticeData Volume Management for RetailDepending on the volume, it may be necessary to schedule a daily archiving r...
Best PracticeData Volume Management for Retail3.4               Outbound Deliveries (LIKP, LIPS)Outbound deliveries are cr...
Best PracticeData Volume Management for Retail3.5               Transport Orders (LTAK, LTAP)Transport orders are created ...
Best PracticeData Volume Management for Retail4                                  Warehouse Replenishment Cycle      Wareho...
Best PracticeData Volume Management for RetailThe following figure shows the different types of documents created        W...
Best PracticeData Volume Management for Retail4.1.3             DeletionOld forecast data should be deleted regularly. The...
Best PracticeData Volume Management for Retail4.2               Vendor Invoices (WBRK, WBRP)Vendor invoices are captured s...
Best PracticeData Volume Management for RetailIn the above example, all billing types for company code PS01 are taken into...
Best PracticeData Volume Management for Retail5                         Customer (Sales) Orders        Customer (Sales) Or...
Best PracticeData Volume Management for RetailThe following figure shows the different documents generated within each ste...
Data volume management for retail
Data volume management for retail
Data volume management for retail
Data volume management for retail
Data volume management for retail
Data volume management for retail
Data volume management for retail
Data volume management for retail
Data volume management for retail
Data volume management for retail
Data volume management for retail
Upcoming SlideShare
Loading in...5
×

Data volume management for retail

2,507

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,507
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
133
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Data volume management for retail"

  1. 1. Best PracticeData Volume Management for Retail 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
  2. 2. Best PracticeData Volume Management for RetailDate Alteration Reason Version22.09.2009 Creation 0.1Table of Contents1 Management Summary 62 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© 2009 SAP AG - Data Volume Management for Retail page 2/67
  3. 3. Best PracticeData Volume Management for Retail 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.10 Table CKMI1 25 2.10.1 Avoidance 25 2.10.2 Summarization 25 2.10.3 Deletion 25 2.10.4 Archiving 25 2.11 Tables IDOCREL & SRRELROLES 26 2.11.1 Avoidance 26 2.11.2 Summarization 26 2.11.3 Deletion 26 2.11.4 Archiving 26 2.12 Tables WPTST & WPLST 27 2.12.1 Avoidance 27 2.12.2 Summarization 27 2.12.3 Deletion 27 2.12.4 Archiving 27 2.13 Info-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.14 Application 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.15 Work Items (SWWWI* tables) 34 2.15.1 Avoidance 34 2.15.2 Summarization 34 2.15.3 Deletion 34 2.15.4 Archiving 353 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© 2009 SAP AG - Data Volume Management for Retail page 3/67
  4. 4. Best PracticeData Volume Management for Retail 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 494 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 535 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 576 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© 2009 SAP AG - Data Volume Management for Retail page 4/67
  5. 5. Best PracticeData Volume Management for Retail 6.2.4 Archiving 66© 2009 SAP AG - Data Volume Management for Retail page 5/67
  6. 6. Best PracticeData Volume Management for Retail1 Management SummaryThis paper describes a few main retail processes and their contributions to data growth in a Retailenvironment.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 listThese main processes are summarized in the figure below: Main Retail Processes SAP Retail System HQ DC Assortment Delivery Notes Planning Transport Orders Purchase Orders Goods Issues MRP Goods Receipts Customer Sales Orders Vendor Invoices Goods Stock Receipts Transfer Orders Store "R/3 Store" POS-Interface Outbound Replenishment Purchase Goods Planning Orders Receipts Master data, Assortment List POS Interface Inbound Sales Data, Store Order SAP AG 2007, Data Archiving In SAP Retail / Andrew Chew.Walter / 24In the following sections, brief descriptions of each process and the different types of documents generatedwill be given, followed by the possibilities of data avoidance, summarization, deletion, and archiving for eachtype of document.© 2009 SAP AG - Data Volume Management for Retail page 6/67
  7. 7. Best PracticeData Volume Management for Retail2 POS InboundThe POS Inbound process is not only one of the most runtime-critical processes within a retail environment; itis also one of the largest contributors to the high data volumes created on a daily basis. Major Contributor To Database Growth (Table Entries Due To POS Inbound Process) POS Inbound Process (processing of WPUUMS-IDocs) Article doc. FI doc. CO doc. PCA doc. ACCT* CKMI1 100 lines 200 lines 100 lines 200 lines 200 lines 100 lines Article doc. FI doc. CO doc. PCA doc. ACCT* CKMI1 100 lines 200 lines 100 lines 200 lines 200 lines 100 lines Article doc. FI doc. CO doc. PCA doc. ACCT* CKMI1 100 lines 200 lines 100 lines 200 lines 200 lines 100 lines WPUUMS Billing doc. FI doc. PCA doc. 300 lines 100 lines 101 lines ~ 200 lines Billing doc. FI doc. PCA doc. 100 lines 101 lines ~ 200 lines Billing doc. FI doc. PCA doc. 100 lines 101 lines ~ 200 lines Info-Structures (S012, S031, S032, S033, S083, S084, S121, ....) SAP AG 2007, Data Archiving In SAP Retail / Andrew Chew.Walter / 26The figure above is based on a live customer example before optimization took place. The posting of eachdocument 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 isaggregated at article/store/day level. Each IDoc (message type WPUUMS) contained 300 articles and eachstore 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 alwaysamong the fastest growing tables in a typical retail environment. The posting of each IDoc generates thefollowing 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 itemsBesides the main documents, updates to other tables are also carried out. These other tables are: a. ACCT*-tables© 2009 SAP AG - Data Volume Management for Retail page 7/67
  8. 8. Best PracticeData Volume Management for Retail 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 dailyarchiving jobs be scheduled to remove the entries in the IDoc tables.2.1.1 AvoidanceNot possible.2.1.2 SummarizationNot possible.2.1.3 DeletionIDocs can simply be deleted using program RSETESTD. However, this program is not meant for productiveuse. The recommended approach is to make use of the archiving object IDOC to remove the table entries.2.1.4 ArchivingBefore the archiving is carried out with archiving object IDOC, analysis needs to be done to determine thedifferent 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 analysisresults is shown in the following table:Status Message Type Month Year No. Entr.03 ORDERS 04 2008 16.68018 WP_PLU 04 2008 12.22053 MBGMCR 04 2008 6.41602 ZPROFORMA 04 2008 6.03603 ZPROFORMA 04 2008 5.96951 WPUUMS 04 2008 4.17103 DESADV 04 2008 4.03853 WPUUMS 04 2008 3.40151 MBGMCR 04 2008 1.09729 ZPROFORMA 04 2008 89029 WP_PLU 04 2008 83518 WP_EAN 04 2008 39529 WPDSET 04 2008 21333 ZPROFORMA 04 2008 10802 ORDERS 04 2008 10529 WP_EAN 04 2008 3602 DESADV 04 2008 10© 2009 SAP AG - Data Volume Management for Retail page 8/67
  9. 9. Best PracticeData Volume Management for Retail02 WP_EAN 04 2008 203 ORDERS 03 2008 24.15918 WP_PLU 03 2008 20.619Next, archiving has to be enabled for the different IDoc statuses. This is done in transaction WE47.Example: IDoc status 29This 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 arecorrectly 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 beconsidered 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 who’sposting dates are older than or equal to current date minus 8 days.© 2009 SAP AG - Data Volume Management for Retail page 9/67
  10. 10. Best PracticeData Volume Management for RetailIn the case of erroneous IDocs, a second variant should be set up to pick up these statuses. This secondvariant 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.© 2009 SAP AG - Data Volume Management for Retail page 10/67
  11. 11. Best PracticeData Volume Management for Retail2.2 Article Documents (MKPF, MSEG)The line item table for article documents (MSEG) is among the fastest growing tables in retail. Articledocuments 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 tothese POS article documentsTherefore, the archiving of article documents resulting from POS has to be more aggressive than other typesof article documents.2.2.1 AvoidanceNot possible2.2.2 SummarizationNot possible.2.2.3 DeletionNot possible. Entries can only be removed via archiving object MM_MATBEL.2.2.4 ArchivingThe archiving of POS article documents via archiving object MM_MATBEL requires SAP Note 1116598 to beapplied first.The archiving object MM_MATBEL requires the set up of residence time of the article documents incustomizing.© 2009 SAP AG - Data Volume Management for Retail page 11/67
  12. 12. Best PracticeData Volume Management for RetailIn 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 bedefined.The example below is from a live customer. The article documents from POS are archived daily, keeping amoving trail of documents for 90 days. In this case, the posting date has been defined as a dynamic variable.© 2009 SAP AG - Data Volume Management for Retail page 12/67
  13. 13. Best PracticeData Volume Management for RetailNote that some customers are archiving all POS article documents older than 1 week on a daily basis. Thismeasure 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 theselection of article documents to be carried out on the line item table. Selection on table MSEG has animpact on the runtime of the archiving job.© 2009 SAP AG - Data Volume Management for Retail page 13/67
  14. 14. Best PracticeData Volume Management for Retail2.3 Billing Documents (VBRK, VBRP)The line item table for billing documents (VBRP) is normally among the fastest growing tables in retail. Thedocument type relevant for POS is defined in the customizing of the POS Inbound profile used. The standarddocument 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 billingdocuments in the system. However, the figure on the right shows that the line items from POS billingdocuments 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 AvoidanceBilling documents from POS can be avoided through customization of the POS Inbound profile.© 2009 SAP AG - Data Volume Management for Retail page 14/67
  15. 15. Best PracticeData Volume Management for RetailWith field billing set to “1”, billing documents are created during runtime for updates to Finance and othermodules, but are not saved to the database at the end of the processing. This setting should only be used ifthe billing documents are not required by the business.2.3.2 SummarizationNot possible2.3.3 DeletionNot possible. Entries can only be removed by using archiving object SD_VBRK.2.3.4 ArchivingThe archiving of billing documents via archiving object SD_VBRK requires the setup of residence times forthe different billing document types.The example below shows the set up for document type FP. Here, the residence time has been set to 14days.After the residence time has been set up, a variant needs to be defined.© 2009 SAP AG - Data Volume Management for Retail page 15/67
  16. 16. Best PracticeData Volume Management for RetailThe example above shows the variant used by a customer for the daily archiving run for billing documentsfrom POS older than 90 days.The variant attributes show that the date has been set up as a dynamic variable.© 2009 SAP AG - Data Volume Management for Retail page 16/67
  17. 17. Best PracticeData Volume Management for Retail2.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 lineitems of the classical General Ledger, table FAGLFLEXA is a transparent table used for storing the line itemsof the New General Ledger.The New General Ledger is available as from Release ECC5 (ERP 2004). However, it is not automaticallyactivated when the system is upgraded from an older release to the latest release. The classical GL and theNew GL are both active in a new installation.2.4.1 AvoidanceNot possible.2.4.2 SummarizationSummarization of FI document line items is mandatory for every high volume project, especially retail. Thesummarization is set up using transaction OBCY. Note that summarization is only relevant for the classicalGeneral 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 note1247473, the selection criteria of this program are expanded to allow the selection by period for thesimulation.In the case of table FAGLFLEXA, there is no summarization transaction. The FAGLFLEXA profits from thesummarization setup for the table BSEG. Furthermore, the data volume depends strongly on the setup of theLedgers (leading and non-leading ledgers) and the number of characteristics and fields used for updates incustomizing of the New GL. Therefore, utmost care must be taken when setting up the New GL. Once thesystem is productive, it is extremely difficult (even impossible) to revert the settings as this may lead toinconsistencies in FI-posting.In the case of WPUUMS-IDocs, we strongly recommend that each IDoc results in one article document andone billing document, to achieve the best possible summarization in FI. This is done by setting the number ofline items in the article and billing documents in the POS Inbound profile to be identical to the number ofarticles in each IDoc.© 2009 SAP AG - Data Volume Management for Retail page 17/67
  18. 18. Best PracticeData Volume Management for Retail Change to 300The figure below shows the documents generated by each WPUUMS-IDoc after the optimization measureswere implemented. Through the summarization in FI, the number of line items has been reducedsignificantly. Changes to POS Inbound Process Article doc. FI doc. CO doc. PCA doc. 300 lines ~ 10 lines 1 line ~ 35 lines WPUUMS Billing doc. FI doc. PCA doc. 300 lines 300 lines ~ 10 lines ~ 20 lines Info-Structures (S012, S031, S121) SAP AG 2007 , Data Archiving In SAP Retail / Andrew Chew.Walter / 27© 2009 SAP AG - Data Volume Management for Retail page 18/67
  19. 19. Best PracticeData Volume Management for Retail2.4.3 DeletionNot possible.2.4.4 ArchivingThe archiving of financial documents is carried out via archiving object FI_DOCUMNT. Before FI documentscan be archived, the set up of the residence times for the different FI document types must be completed inthe customizing of the archiving object.From a purely technical perspective, FI documents can be archived when the period is closed. Thisimplies that all FI documents older than 3 months can be archived. This situation applies to all FIdocuments belonging to accounts that are not open-item managed. Open item manageddocuments are never closed and as such, can never be archived. These documents need to beclosed by the users on a regular basis.© 2009 SAP AG - Data Volume Management for Retail page 19/67
  20. 20. Best PracticeData Volume Management for Retail2.5 Tables FAGL_SPLINFO & FAGL_SPLINFO_VALThe activation of the document split functionality in the New GL leads to updates of tables FAGL_SPLINFOand FAGL_SPLINFO_VAL. These 2 tables are usually among the top 20 largest tables in a productivesystem.2.5.1 AvoidanceDuring the posting of billing documents to FI, high data volumes in FAGL_SPLINFO andFAGL_SPLINFO_VAL due to large number of tax lines were observed. To avoid unnecessary line items inthese tables, OSS notes 1137444 and 1157202 must be applied.2.5.2 SummarizationNot possible.2.5.3 DeletionNot possible.2.5.4 ArchivingThe entries of in these tables are archived together with the main FI document tables BKPF, RFBLG,FAGLFLEXA. The archiving object is FI_DOCUMNT.© 2009 SAP AG - Data Volume Management for Retail page 20/67
  21. 21. Best PracticeData Volume Management for Retail2.6 Table BSISThe data volumes in table BSIS are strongly dependent on the number of accounts with line-item displayfunction switched on. The accounts with this function can be easily identified in table SKB1 with field XKRES= ‘X’.2.6.1 AvoidanceWe strongly recommend that the line item display functionality be switched on only for those accounts thatreally require it.According to OSS note 178487, the line item display functionality should be deactivated for the followingaccount 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 accountsRefer to note 178487 for further details.2.6.2 SummarizationNo direct summarization. The activation of FI summarization via transaction OBCY also leads to less datawritten into table BSIS.2.6.3 DeletionNot possible. Entries can only be removed via archiving object FI_DOCUMNT.2.6.4 ArchivingThe entries in table BSIS are removed by using archiving object FI_DOCUMNT. The setup of the residencetimes must be done in the customizing of the archiving object.© 2009 SAP AG - Data Volume Management for Retail page 21/67
  22. 22. Best PracticeData Volume Management for Retail2.7 Controlling Documents (COBK, COEP)2.7.1 AvoidanceTurn 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 modificationdescribed in OSS note 182496.2.7.2 SummarizationSummarization of CO documents is set up via transaction OKBI. Details on OKBI are found in OSS note147766.To determine the potential of summarization, program RARCCOA5 can be used to simulate thesummarization of existing table entries. The simulation can be done for different fields. As such, it isnecessary to identify the fields for which details are required. The output of this simulation2.7.3 DeletionNot possible. Entries are removed via archiving.2.7.4 ArchivingBefore the table entries are archived, report RARCCOA1 has to run, to determine the archiving objects to beused. 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 thedata volumes down. Example: CO_COSTCTR. This archiving object allows archiving only on an annualbasis. In general, it is advisable to use archiving object CO_ITEM on a monthly basis and then use otherarchiving 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 customizingof the archiving objects.© 2009 SAP AG - Data Volume Management for Retail page 22/67
  23. 23. Best PracticeData Volume Management for Retail2.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 thetop 10 largest tables in the system.2.8.1 AvoidanceDo not activate the classical profit center accounting module if the New GL is active. The New GLincorporates 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 migrationproject of classical GL to the New GL can be done. Furthermore, the PCA reporting can be moved to the NewGL. 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 SummarizationSummarization of document line items (table GLPCA) can be set up via transaction 0KE8. OSS note 198519provides a program for simulating the summarization of the entries in table GLPCA.2.8.3 DeletionNot possible.2.8.4 ArchivingThe archiving of the entries in table GLPCA is carried out using archiving object EC_PCA_ITM. In olderreleases, the archiving object is PCA_OBJECT.Both archiving objects do not require the definition of the residence time in customizing. The selection issimply defined in the variant used. It is recommended to run archiving of GLPCA entries on a monthly basis.© 2009 SAP AG - Data Volume Management for Retail page 23/67
  24. 24. Best PracticeData Volume Management for Retail2.9 ACCT*-tablesIn the standard delivery, the updating of table ACCTIT, ACCTHD and ACCTCR is active. These tablescontain entries that are required for the subsequent posting of detailed data from MM to CO, or in somecases, the use of special Ledger. It is extremely seldom that these tables are required by customers for theirbusiness processes. Every goods movement line item (table MSEG) has 2 corresponding entries in tableACCTIT.OSS note 48009 provides detailed information on the purposes of these tables and how to deactivate them.2.9.1 AvoidanceThe updating of these tables can be deactivated by the modification described in OSS note 48009. A strongindication that the entries are not required by the business can be won by looking at the table call statistics intransaction ST10 for all servers and all previous months (tables that are not buffered).The example below was extracted from a customer’s productive system and it shows that the tables arewritten (changes), but never read. This is an indication that the business does not require the entries in thesetables.------------------------------------------------------------------------------------------------------------------------------------------------------System: All servers Not buffered tablesTime frame of analysis : 02 / 2008------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| Table | ABAP Processor requests | DB activity || | Changes/ | Total | Direct | Seq. | Changes | Calls | Rows || | Total (%) | | reads | reads | | | affected |------------------------------------------------------------------------------------------------------------------------------------------------------| *Total* | | 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 || ACCTIT | 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, yousimply need to check whether the transactions and programs mentioned in OSS note 48009 are in thestatistics.2.9.2 SummarizationNot possible.2.9.3 DeletionSee OSS note 48009.2.9.4 ArchivingThe archiving of the entries in the ACCT*-tables is done using archiving object MM_ACCTIT. This objectdoes not require the definition of residence times. Due to the potentially high data volume, it is recommendedto set up a daily archiving job, using the posting date as a dynamic variable. The selection by posting dateshould on one hand be held for as short a time as possible; but on the other hand, long enough to satisfy thebusiness requirements.© 2009 SAP AG - Data Volume Management for Retail page 24/67
  25. 25. Best PracticeData Volume Management for Retail2.10 Table CKMI1This table is updated for every goods movements carried out in the system. The huge number of entries inthis table leads to performance loss during posting of goods movements that are relevant for valuation.2.10.1 AvoidanceThe updating of this table can be deactivated by implementing note 1158752. For release < 4.6C, apply OSSnote 384757.------------------------------------------------------------------------------------------------------------------------------------------------------System: All servers Not buffered tablesTime frame of analysis : 03 / 2008------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| Table | ABAP Processor requests | DB activity || | Changes/ | Total | Direct | Seq. | Changes | Calls | Rows || | Total (%) | | reads | reads | | | affected |------------------------------------------------------------------------------------------------------------------------------------------------------| CKMI1 | 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 SummarizationNot possible.2.10.3 DeletionNot possible.2.10.4 ArchivingThe archiving object CO_ML_IDX is used for removing entries in table CKMI1. It is not necessary to defineresidence time for the table entries. The archiving object allows archiving runs on a monthly basis.© 2009 SAP AG - Data Volume Management for Retail page 25/67
  26. 26. Best PracticeData Volume Management for Retail2.11 Tables IDOCREL & SRRELROLESThese tables contain the links between IDocs and application objects. The table entries are not taken intoaccount during the archiving of IDocs via archiving object IDOC and remain in the system although the IDocsno longer exist in the system.2.11.1 AvoidanceAs described in OSS note 574349, links of type IDC4 are created if the partner type “LS” (logical system) isused for the communication between an external non-SAP and an SAP system. These links can cause majorperformance problems during the deletion job with report RSRLDREL and/or RSRLDREL2.2.11.2 SummarizationNot possible.2.11.3 DeletionEntries are deleted with program RSRLDREL and/or RSRLDREL2 (OSS note 853035). A periodic job shouldbe scheduled to delete the table entries regularly. The scheduling of the deletion job should be synchronizedwith the frequency of the IDoc archiving. For example, if IDocs are archived daily, then the deletion jobshould 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 ArchivingNot possible.© 2009 SAP AG - Data Volume Management for Retail page 26/67
  27. 27. Best PracticeData Volume Management for Retail2.12 Tables WPTST & WPLSTAll 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 bedeleted separately.2.12.1 AvoidanceNot possible.2.12.2 SummarizationNot possible.2.12.3 DeletionThe entries in these tables are deleted by programs RWPUDTST (table WPTST) and RWPUDLST (tableWPLST).The scheduling of the deletion jobs should be in sync with the IDoc archiving jobs. If a daily archiving job isscheduled to remove correctly posted IDocs older than 7 days, then the deletion jobs for RWPUDLST andRWPUDTST should also run daily to remove the entries related to the archived IDocs only.2.12.4 ArchivingNot possible.© 2009 SAP AG - Data Volume Management for Retail page 27/67
  28. 28. Best PracticeData Volume Management for Retail2.13 Info-Structures (RIS/LIS – tables Sxxx)xxx = 001 to 499Info-Structures are tables that originated during the time when BI was not available on the market. TablesS001 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 WavesS159In a standard delivery, all info-structures are active by default. As such, it is strongly recommended that allinfo-structures be deactivated at the beginning of a project. This forces project team members to thinkcarefully before they turn on the updating of any info-structures.2.13.1 AvoidanceAll 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 itemsAs mentioned above, all info-structures should be deactivated at the beginning of a project so that teammembers 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. Thefollowing table shows that ST10 statistics for info-structures from a live customer. ABAP/IV Processor requests DB activityPeriod Table Changes/ Total Direct Seq. Changes Calls Rows Total(%) reads reads affected03 2008 S003 0 4 0 4 0 6 003 2008 S004 0 4 0 4 0 7 004 2008 S004 0 7 0 7 0 13 005 2008 S004 0 2 0 2 0 4 006 2008 S004 0 1 0 1 0 2 007 2008 S004 0 0 0 0 0 0 008 2008 S004 0 1 0 1 0 2 009 2008 S004 0 0 0 0 0 0 003 2008 S009 50 110.676 55.338 0 55.338 166.257 110.74404 2008 S009 50 301.842 150.921 0 150.921 453.205 301.96605 2008 S009 50 271.520 135.760 0 135.760 407.796 271.66306 2008 S009 50 308.338 154.169 0 154.169 462.916 308.45307 2008 S009 50 332.842 166.421 0 166.421 499.705 332.97108 2008 S009 50 314.816 157.408 0 157.408 472.675 314.94109 2008 S009 50 132.326 66.163 0 66.163 198.688 132.382© 2009 SAP AG - Data Volume Management for Retail page 28/67
  29. 29. Best PracticeData Volume Management for Retail03 2008 S011 100 422.087 0 0 422.087 422.691 414.66304 2008 S011 100 1.057.076 0 0 1.057.076 1.058.224 1.045.13605 2008 S011 100 993.760 0 0 993.760 995.219 980.85406 2008 S011 100 993.807 0 0 993.807 995.092 981.48407 2008 S011 100 1.153.063 0 0 1.153.063 1.154.441 1.139.96608 2008 S011 100 979.396 0 0 979.396 980.736 967.24409 2008 S011 100 471.703 0 0 471.703 472.357 464.71303 2008 S012 100 7.074.447 0 0 7.074.447 7.075.134 5.493.21804 2008 S012 100 16.158.095 0 5 16.158.090 16.159.419 12.586.58705 2008 S012 100 15.351.030 0 1 15.351.029 15.352.705 11.687.13006 2008 S012 100 16.146.093 0 1 16.146.092 16.147.595 12.416.64907 2008 S012 100 18.913.429 0 0 18.913.429 18.915.053 14.974.04208 2008 S012 100 16.033.958 0 0 16.033.958 16.035.563 12.813.63009 2008 S012 100 7.488.396 0 0 7.488.396 7.489.126 5.962.16903 2008 S013 63,11 5.388.530 1.987.718 0 3.400.812 7.479.569 3.975.62604 2008 S013 61,83 13.138.688 5.015.042 0 8.123.646 18.426.829 10.030.20505 2008 S013 62,18 15.573.005 5.889.761 0 9.683.244 21.697.212 11.779.58006 2008 S013 61,77 15.040.210 5.749.934 0 9.290.276 21.040.386 11.499.95707 2008 S013 61,3 13.709.293 5.305.617 0 8.403.676 19.305.953 10.611.34408 2008 S013 62,14 11.088.481 4.197.755 0 6.890.726 15.530.702 8.395.55909 2008 S013 62,61 4.964.454 1.856.378 0 3.108.076 6.922.519 3.712.80803 2008 S014 50 112.212 56.106 0 56.106 168.617 112.27804 2008 S014 50 308.236 154.118 0 154.118 462.901 308.35805 2008 S014 50 275.072 137.536 0 137.536 413.264 275.21706 2008 S014 50 312.866 156.433 0 156.433 469.805 312.97707 2008 S014 50 337.910 168.955 0 168.955 507.430 338.04108 2008 S014 50 318.678 159.339 0 159.339 478.577 318.80209 2008 S014 50 133.796 66.898 0 66.898 200.948 133.85303 2008 S021 0 4 0 4 0 7 003 2008 S031 100 9.067.137 0 3 9.067.134 9.067.518 5.278.81404 2008 S031 100 29.684.377 0 12 29.684.365 29.685.144 17.166.23005 2008 S031 100 24.219.918 0 10 24.219.908 24.220.860 14.179.37306 2008 S031 100 27.740.044 0 11 27.740.033 27.740.929 16.041.11607 2008 S031 100 31.388.493 0 21 31.388.472 31.389.477 18.173.22308 2008 S031 100 27.404.836 0 15 27.404.821 27.405.712 15.702.63509 2008 S031 100 13.475.195 0 0 13.475.195 13.475.622 7.654.84403 2008 S032 100 16.404.510 0 6 16.404.504 16.405.508 15.399.01104 2008 S032 99,99 52.518.168 0 3.550 52.514.618 52.520.803 49.092.46205 2008 S032 100 43.619.090 0 13 43.619.077 43.621.844 41.164.54406 2008 S032 100 51.409.140 0 12 51.409.128 51.411.810 46.828.31707 2008 S032 100 54.994.160 0 63 54.994.097 55.006.528 54.838.65008 2008 S032 100 47.550.964 0 16 47.550.948 47.553.610 45.330.44209 2008 S032 100 22.895.361 0 0 22.895.361 22.896.421 21.684.86903 2008 S033 100 5.278.718 0 0 5.278.718 5.278.911 5.278.81704 2008 S033 100 17.165.948 0 0 17.165.948 17.166.414 17.166.23305 2008 S033 100 14.178.504 0 0 14.178.504 14.179.026 14.178.79406 2008 S033 100 16.037.407 0 0 16.037.407 16.037.889 16.037.68507 2008 S033 100 18.172.898 0 0 18.172.898 18.173.463 18.173.22608 2008 S033 100 15.702.380 0 0 15.702.380 15.702.870 15.702.65709 2008 S033 100 7.654.695 0 0 7.654.695 7.654.949 7.654.84303 2008 S034 100 98.832 0 0 98.832 99.014 95.26204 2008 S034 100 288.024 0 0 288.024 288.354 278.603© 2009 SAP AG - Data Volume Management for Retail page 29/67
  30. 30. Best PracticeData Volume Management for Retail05 2008 S034 100 374.404 0 0 374.404 374.810 365.39406 2008 S034 100 258.465 0 0 258.465 258.811 249.45707 2008 S034 100 329.052 0 0 329.052 329.418 319.17608 2008 S034 100 292.450 0 0 292.450 292.854 281.85209 2008 S034 100 119.955 0 0 119.955 120.137 115.15503 2008 S035 100 13.222 0 0 13.222 13.384 11.10504 2008 S035 100 41.472 0 0 41.472 41.778 35.14505 2008 S035 100 39.533 0 0 39.533 39.908 34.57206 2008 S035 100 38.717 0 0 38.717 39.040 33.26107 2008 S035 100 46.222 0 0 46.222 46.562 40.35908 2008 S035 100 44.816 0 0 44.816 45.188 37.74309 2008 S035 100 19.464 0 0 19.464 19.640 17.15703 2008 S039 0 4 0 4 0 8 004 2008 S039 0 2 0 2 0 4 005 2008 S039 0 3 0 3 0 6 006 2008 S039 0 0 0 0 0 0 007 2008 S039 0 5 0 5 0 9 008 2008 S039 42,86 7 0 4 3 13 1209 2008 S039 0 0 0 0 0 0 003 2008 S061 100 249 0 0 249 281 24604 2008 S061 100 1.987 0 0 1.987 2.076 1.97605 2008 S061 100 2.204 0 0 2.204 2.296 2.19306 2008 S061 100 2.324 0 0 2.324 2.407 2.31507 2008 S061 100 1.848 0 0 1.848 1.948 1.83408 2008 S061 100 1.813 0 0 1.813 1.907 1.80409 2008 S061 100 825 0 0 825 887 81703 2008 S062 100 248 0 0 248 302 27004 2008 S062 100 1.961 0 0 1.961 2.111 2.03305 2008 S062 100 2.189 0 0 2.189 2.352 2.26406 2008 S062 100 2.304 0 0 2.304 2.453 2.37507 2008 S062 100 1.834 0 0 1.834 2.000 1.91208 2008 S062 100 1.801 0 0 1.801 1.967 1.88009 2008 S062 100 818 0 0 818 920 86703 2008 S066 0 12 0 12 0 26 008 2008 S066 0 1 0 1 0 3 003 2008 S067 0 12 0 12 0 19 008 2008 S067 0 1 0 1 0 2 004 2008 S071 0 1 0 1 0 2 005 2008 S071 0 0 0 0 0 0 008 2008 S091 0 0 0 0 0 0 003 2008 S111 100 212 0 0 212 271 2.66304 2008 S111 100 183 0 0 183 220 1.94005 2008 S111 100 70 0 0 70 96 50306 2008 S111 100 157 0 0 157 190 1.39007 2008 S111 100 211 0 0 211 258 5.10308 2008 S111 100 124 0 0 124 162 1.43509 2008 S111 100 69 0 0 69 89 52003 2008 S123 100 318.975 0 0 318.975 319.266 311.89404 2008 S123 100 918.040 0 0 918.040 918.608 902.43505 2008 S123 100 846.579 0 0 846.579 847.216 830.72906 2008 S123 100 918.570 0 0 918.570 919.079 901.35307 2008 S123 100 953.979 0 0 953.979 954.552 936.196© 2009 SAP AG - Data Volume Management for Retail page 30/67
  31. 31. Best PracticeData Volume Management for Retail08 2008 S123 100 921.387 0 0 921.387 921.948 903.15809 2008 S123 100 404.009 0 0 404.009 404.255 392.15403 2008 S124 100 3.120.258 0 0 3.120.258 3.120.608 2.170.23204 2008 S124 100 9.045.350 0 0 9.045.350 9.046.031 6.320.45405 2008 S124 100 8.869.718 0 0 8.869.718 8.870.503 6.100.25206 2008 S124 100 10.119.952 0 0 10.119.952 10.120.572 6.993.21607 2008 S124 100 10.720.966 0 0 10.720.966 10.721.719 7.523.48708 2008 S124 100 10.587.379 0 0 10.587.379 10.588.071 7.359.72409 2008 S124 100 4.658.581 0 0 4.658.581 4.658.873 3.141.77803 2008 S135 0 1 0 1 0 3 004 2008 S135 50 20 0 10 10 31 1405 2008 S135 0 2 0 2 0 3 006 2008 S135 0 1 0 1 0 2 007 2008 S135 58,82 17 0 7 10 23 1008 2008 S135 0 0 0 0 0 0 003 2008 S999 100 8.594.709 0 0 8.594.709 8.595.096 5.249.66504 2008 S999 100 28.996.466 0 0 28.996.466 28.997.246 17.206.04405 2008 S999 100 22.848.597 0 0 22.848.597 22.849.531 14.109.76606 2008 S999 100 26.300.363 0 0 26.300.363 26.301.211 15.963.57707 2008 S999 100 30.371.134 0 0 30.371.134 30.372.140 18.225.92008 2008 S999 100 25.828.656 0 0 25.828.656 25.829.529 15.649.53709 2008 S999 100 13.084.692 0 0 13.084.692 13.085.126 7.672.875All 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 areempty, 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 SummarizationNot possible.2.13.3 DeletionNot possible.2.13.4 ArchivingThere are no standard archiving objects for the info-structures. The archiving objects have to be generatedvia transaction MCSX. The generated archiving objects are MC_Sxxx, where Sxxx is the info-structurename.Use transaction SARA to schedule archiving jobs for the archiving objects MC_Sxxx.© 2009 SAP AG - Data Volume Management for Retail page 31/67
  32. 32. Best PracticeData Volume Management for Retail2.14 Application logs (BALHDR, BALDAT)Additional warnings and error messages arising from the applications may be written when posting salesIDocs. These messages are stored in tables BALHDR and BALDAT.2.14.1 AvoidanceNot possible.2.14.2 SummarizationNot possible.2.14.3 DeletionTransaction 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 themajority 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” asdynamic 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 ArchivingIf the business requires application logs to be archived, instead of simply deleted, the archiving objectBC_SBAL should be used.This archiving object does not require the set up of residence times for application logs in the customizing ofthis object. The creation dates (from/to) should be set up as dynamic variables© 2009 SAP AG - Data Volume Management for Retail page 32/67
  33. 33. Best PracticeData Volume Management for RetailCreate a secondary index on table BALHDR with fields MANDANT, ALDATE.Schedule a daily archiving job.© 2009 SAP AG - Data Volume Management for Retail page 33/67
  34. 34. Best PracticeData Volume Management for Retail2.15 Work Items (SWWWI* tables)As from release 4.6C, all links between IDocs and application data are held in tables IDOCREL andSRRELROLES. Work items are no longer used for this purpose. However, this does not prevent theapplications generating work items when problems occur during the creation of the application data.2.15.1 AvoidanceNot possible.2.15.2 SummarizationNot possible.2.15.3 DeletionWork items can be deleted with program RSWWWIDE. The “Creation date” field should be set up as adynamic variable.© 2009 SAP AG - Data Volume Management for Retail page 34/67
  35. 35. Best PracticeData Volume Management for RetailDepending on the volume of work items generated per day, it may be necessary to schedule a daily deletionjob.2.15.4 ArchivingIf the business requires work items to be archived, instead of deleted, the archiving object WORKITEMshould be used.Archiving object WORKITEM does not require the setup of residence times for work items. It isrecommended to set up the fields “Creation Date” and “End Date” as dynamic variables.© 2009 SAP AG - Data Volume Management for Retail page 35/67
  36. 36. Best PracticeData Volume Management for RetailDepending 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 ineffectivebecause the work item statuses were never set to “completed” and/or “cancelled”.© 2009 SAP AG - Data Volume Management for Retail page 36/67
  37. 37. Best PracticeData Volume Management for Retail3 Store Replenishment Cycle Store Replenishment Cycle Store POS Replenishment Upload Planning Post store goods Create receipts outbound deliveries Post warehouse goods issues Create transport orders (optional) SAP AG 2007, Data Archiving In SAP Retail / Andrew Chew.Walter / 35The above figure shows the typical store replenishment cycle. The cycle begins with the POS Inboundprocess in which sales data is processed and stock levels are updated. Next, the replenishmentplanning/calculation are carried out. This results in purchase requisitions and/or purchase orders beingcreated.There are 2 types of purchase orders – stock transfer orders and purchase orders. While stock transferorders are fulfilled by the warehouses, purchase orders are sent to the external vendors. Next, outbounddeliveries are created with reference to the stock transfer orders. These outbound deliveries are necessaryto inform the warehouse(s) of the requirements of each individual store. Depending on the configuration ofthe process, transport orders can be created for the goods movements within the warehouse(s) – picking andmoving the goods to the shipping point(s). The usage of Handling Units is not considered in this simplescenario.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, storegoods receipts are posted. Store goods receipts are posted with reference to the stock transfer orders andpurchase orders.© 2009 SAP AG - Data Volume Management for Retail page 37/67
  38. 38. Best PracticeData Volume Management for RetailThe different documents and their corresponding tables are shown in the following figure. Store Replenishment Cycle – Documents & Table Entries IDocs: EDIDC, EDI40, EDIDS Article d oc.: MKPF, MSEG Billing doc.: VBRK, VBRP FI-doc.: BKPF, RFBLG, FAGLF LEXA, FAGL_SPLINFO, FAGL_SPLINFO_VAL BSIS, BSAS Purchase req uisitions: EBAN CO-doc.: COBK, COEP Purchase orders: EKKO, EKPO PCA-doc.: GLPCA Change docu ments: CDHDR, CDCLS ACCT*-Tables Application log s: BALHDR, BAL DAT Links between IDocs and applications: SRRELROLES, IDOCREL Info -Structures (Sxxx) Workitems: SWWWIHEAD, .... Application logs: BALHDR, BALDAT Store Info-Structu res (Sxxx) POS Replenishment Upload Planning Article doc.: MKPF, MSEG FI-doc.: BKPF, RFBLG, FAGL FLEXA FAGL_SPLINFO, FAGL_SPLINFO_VAL Post store Outboun d Deliveries: LIKP, LIKPS BSIS, BSAS goods Create Ch ange documen ts: CDHDR, CDCLS receipts outbound Chan ge doc.: CDHDR, CDCLS Application logs: BALHDR, BALDAT deliver ies Ap plication Logs: BALHDR, BALDAT Info-Stru ctures (Sxxx) ACCT*-tables Info-Stru ctures (Sxxx) Post warehouse goods issues Cr eate transpor t orders (optional) Article doc.: MKPF, MSEG FI-doc.: BKPF, RFBLG, FAGLFL EXA FAGL_SPLINFO, FAGL_SPL INFO_VAL Transport orders: LTAK, LTAP BSIS, BSAS Change documents: CDHDR, CDCLS Change doc.: CDHDR, CDCLS Application logs: BALHDR, BALDAT Application Logs: BALHDR, BALDAT In fo-Structures (Sxxx) ACCT*-tables Info-Structures (Sxxx) SAP AG 2007, Data Archiving In SAP Retail / Andrew Chew.Walter / 36Documents related to, or mentioned in the section “POS Inbound” are not be considered in this section. Thereason for this is that the handling of these documents is similar or identical to the case “POS Inbound”.© 2009 SAP AG - Data Volume Management for Retail page 38/67
  39. 39. Best PracticeData Volume Management for Retail3.1 Purchase Requisitions (EBAN)Store replenishment planning can result in purchase requisitions being created. It depends strongly on thesetup of the replenishment process.3.1.1 AvoidanceIf transaction WRP1 is used for the store replenishment, purchase requisitions can be avoided through thecustomizing of the “Store Order”./NSPRO F5 Materials Management Consumption-based Planning Replenishment ControlFollow-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.© 2009 SAP AG - Data Volume Management for Retail page 39/67
  40. 40. Best PracticeData Volume Management for Retail3.1.2 SummarizationNot possible.3.1.3 DeletionNot possible.3.1.4 ArchivingDuring the conversion of purchase requisitions to purchase orders via transaction ME59, the field “SetRequisitions 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 objectMM_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 thecustomizing of the object.© 2009 SAP AG - Data Volume Management for Retail page 40/67
  41. 41. Best PracticeData Volume Management for RetailThe values 10 and 20 in residence time 1 and 2 are default values and should be changed to meet businessrequirements.It is recommended that the “one-step procedure” be used. This means that only residence time 1 is requiredand 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 requisitionsand archives them if the residence time 1 is fulfilled.In the two-step procedure, the system sets the deletion indicator for completed and closed purchaserequisitions 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 fulfilledby the warehouses while purchase orders (or vendor orders) are fulfilled by external vendors.3.2.1 AvoidanceNot possible.3.2.2 SummarizationNot possible.3.2.3 DeletionNot possible.3.2.4 ArchivingThe 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 valueof all residence times is 30 days, as shown in the example below.© 2009 SAP AG - Data Volume Management for Retail page 41/67
  42. 42. Best PracticeData Volume Management for RetailThe meaning of residence time 1 and residence time 2 is identical to those in archiving object MM_EBAN forpurchase requisitions. Again, it is recommended to use the one-step procedure to archive stock transferorders 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 thewarehouses within a period of about a week. As such, it is sufficient to keep stock transfer orders online for amonth.In the case of purchase orders to vendors, the residence times depend strongly on the business processesdefined. If for example, subsequent settlement is used and the rebate agreements with vendors are valid forone year, many customers would like to keep the purchase orders until the final rebate settlement iscompleted. However, the purchase orders are not required for the rebate settlement. These purchase ordersare only required to build the statistics relevant for the rebate settlement in table S111. This situation onlyoccurs when a rebate agreement with a vendor is created in the later part of the year, but the validity of theagreement 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 possibleto 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 dateminus 35 days.© 2009 SAP AG - Data Volume Management for Retail page 42/67
  43. 43. Best PracticeData Volume Management for RetailThe “Key Date for Quotation Date” field is ignored when archiving purchase orders because this is relevantonly for quotations.It is recommended that a daily archiving job be scheduled for archiving stock transfer orders. In the case ofvendor orders, it may be necessary to schedule a daily archiving job if the volumes are high. Otherwise, aweekly job should be sufficient.© 2009 SAP AG - Data Volume Management for Retail page 43/67
  44. 44. Best PracticeData Volume Management for Retail3.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 andprice maintenance. Table CDCLS is usually among the top 20 fastest growing tables in a Retail environment.3.3.1 AvoidanceThe following list shows the different types (OBJECTCLAS) of change documents created by a customer.OBJECTCLAS # EntriesCOND_A 83.392.799ADRESSE 6.815.547MAT_FULL 4.676.681EINKBELEG 4.117.305LIEFERUNG 3.923.894VERKBELEG 3.166.077BANF 2.602.251BELEG 2.315.976INFOSATZ 1.790.371ANLA 1.664.961BELEGR 1.189.519WLK1 1.154.827TRANSPORT 689.253MATERIAL 606.602ORDERBUCH 453.824DEBI 371.996HANDL_UNIT 256.326KRED 203.982SACH 137.016ASMODULE 49.347PFCG 24.829BETRIEB 22.383FAKTBELEG 16.219SETS 13.270KOSTL 11.932BANK 10.744ADRESSE3 8.361PRCTR 4.949WREFA 4.268BELEGD 3.173KLASSE 1.715STUE 893STUE_V 892NRINTERVAL 576WBASISWG 499KSTAR 496ALLOCATION 250PROJ 240BELEGV 223INCOMINGINVOICE 66© 2009 SAP AG - Data Volume Management for Retail page 44/67
  45. 45. Best PracticeData Volume Management for RetailEQUI 57FEATURE 30RKAUFTRAG 6CMDT_PC 5MELDUNG 5CHARGE 3NRKROBJ 3LSTAR 2LAYOUT_MOD 1PROJS 1While most of the change documents cannot be avoided during normal operations, change documents due toarticle listing (OBJECTCLAS = WLK1, ASMODULE, WBASISWG, LAYMOD) can be avoided if the listing iscarried out via transaction WSM3 or WSM8. The selection screens of these 2 transactions have the optionfor suppressing the generation of change documents. The following diagram shows the selection screen oftransaction WSM3.During an initial data load from legacy system to SAP, it is strongly recommended that change documents beavoided. However, this requires minor modifications to certain ABAP programs. Contact SAP for furtherdetails since these modifications are not part of standard delivery.3.3.2 SummarizationNot possible.3.3.3 DeletionReport RWSORT54 is used for deleting change documents due to listing (OBJECTCLAS = WLK1,ASMODULE, WBASISWG, LAYMOD).© 2009 SAP AG - Data Volume Management for Retail page 45/67
  46. 46. Best PracticeData Volume Management for RetailProgram RSCDOK99 can be used for deleting all change documents.3.3.4 ArchivingChange documents are normally archived whenever archiving runs are carried out for the main documentssuch as purchase requisitions, purchase order, deliveries, and so on. In certain business cases, it may benecessary to use archiving object CHANGEDOCU to archive change documents only (exampleOBJECTCLAS MAT_FULL).The archiving object CHANGEDOCU does not require the set up of residence times for change documents inthe customizing of the archiving object. The following example shows the variant for archiving changedocuments with OBJECTCLAS = COND_A that are older than 30 days.© 2009 SAP AG - Data Volume Management for Retail page 46/67
  47. 47. Best PracticeData Volume Management for RetailDepending on the volume, it may be necessary to schedule a daily archiving run for change documents.© 2009 SAP AG - Data Volume Management for Retail page 47/67
  48. 48. Best PracticeData Volume Management for Retail3.4 Outbound Deliveries (LIKP, LIPS)Outbound deliveries are created with reference to stock transfer orders. These are purchase orders forstores that are fulfilled by the warehouse.3.4.1 AvoidanceNot possible.3.4.2 SummarizationNot possible.3.4.3 DeletionNot possible.3.4.4 ArchivingDeliveries are archived using archiving object RV_LIKP. Residence times for the different delivery typeshave 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 completedand can be archived. The selection screen has the option to use the date of last change for the checking ofthe 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 assignedto them. If there are transport orders and billing documents assigned, these documents have to be archivedfirst. Further, if handling units are used in the business process, the handling units must be archived beforethe transport orders.© 2009 SAP AG - Data Volume Management for Retail page 48/67
  49. 49. Best PracticeData Volume Management for Retail3.5 Transport Orders (LTAK, LTAP)Transport orders are created with reference to the outbound deliveries. These are required for the pickingand packing of the goods to be shipped to the stores.3.5.1 AvoidanceThis depends strongly on the set up of the business process. In the case where an external warehousemanagement system is used, transport orders are optional.3.5.2 SummarizationNot possible.3.5.3 DeletionNot possible.3.5.4 ArchivingTransport orders are archived using archiving object RL_TARL_TA does not require the setting up of residence times of transport orders and requirements. Allcompleted and closed transport orders are considered by the archiving object. The residence time must onlybe specified in the variant of the WRITE-program.The diagram above shows the selection screen of the WRITE-program for archiving object RL_TA. Theresidence 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 handlingunits must be archived first.© 2009 SAP AG - Data Volume Management for Retail page 49/67
  50. 50. Best PracticeData Volume Management for Retail4 Warehouse Replenishment Cycle Warehouse Replenishment Cycle Forecast Material (optional) Requirement Planning (MRP) + Pur. Req. Invoice Convert Verification Purchase & Payment Requisitions to Purchase Orders Post warehouse goods Send Order to receipts vendors SAP AG 2007 , Data Archiving In SAP Re tail / Robert Peebles / 35The warehouse replenishment cycle begins with a weekly or daily forecast. Each forecast run creates a newversion 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. Thesepurchase requisitions are checked and released by the purchasing department members. After they arereleased, the purchase requisitions are “converted” to purchase orders. The term “conversion” does notliterally mean converting a purchase requisition to a purchase order. It simply means that purchase ordersare 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, throughIDocs. When the vendors deliver the goods to the warehouses, warehouse goods receipts are posted. Theposting is carried out with reference to the purchase orders. Finally, invoice verification is carried out toensure that the goods and quantities received match the information in the purchase orders. After that,payments are made to the vendors.© 2009 SAP AG - Data Volume Management for Retail page 50/67
  51. 51. Best PracticeData Volume Management for RetailThe following figure shows the different types of documents created Warehouse Replenishment Cycle – documents created Purchase requisitions Forecast Change documents data Application logs Info-Structures Vendor invoices FI-documents CO-documents Purchase Orders PCA-documents Change documents Change documents Application logs Application logs Info-Structures Info-Structures Article documents FI-documents CO-documents PCA-documents IDocs Change documents Application logs Info-Structures SAP AG 2007, Data Archiving In SAP Retail / Andrew Chew.Walter / 39This 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 AvoidanceThis depends solely on the definition of the business process. Although it is possible to run replenishmentwithout the use of forecast data, it is normally the case in all projects that forecast data is used for thereplenishment.It is recommended that forecast should not be carried out for all article/site combinations on a daily basis. Inmost cases, a weekly forecast is sufficient to satisfy the business requirements. Each forecast run creates anew version of the forecast data.4.1.2 SummarizationNot possible.© 2009 SAP AG - Data Volume Management for Retail page 51/67
  52. 52. Best PracticeData Volume Management for Retail4.1.3 DeletionOld forecast data should be deleted regularly. The frequency of the deletion job should be in sync with thefrequency in which forecast is carried out. If for example forecast is carried out weekly, the deletion jobshould 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 tablePRON. Therefore, it is better to use program RMPR2001 instead. The following diagram shows an exampleof a variant of report RMPR2001.The above example is used for deleting all forecast data for all sites (stores and warehouses) on a weeklybasis. 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 nolonger 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. Ifthis 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 ArchivingNot possible.© 2009 SAP AG - Data Volume Management for Retail page 52/67
  53. 53. Best PracticeData Volume Management for Retail4.2 Vendor Invoices (WBRK, WBRP)Vendor invoices are captured so the logistics invoice verification process can take place.4.2.1 AvoidanceNot possible.4.2.2 SummarizationNot possible.4.2.3 DeletionNot possible.4.2.4 ArchivingVendor invoices are archived using archiving object WLF. This archiving object does not require thedefinition 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.© 2009 SAP AG - Data Volume Management for Retail page 53/67
  54. 54. Best PracticeData Volume Management for RetailIn the above example, all billing types for company code PS01 are taken into consideration if their postingdates are older than or equal to the current date minus 180 days.© 2009 SAP AG - Data Volume Management for Retail page 54/67
  55. 55. Best PracticeData Volume Management for Retail5 Customer (Sales) Orders Customer (Sales) Orders Post Create Create Create Create Warehouse Outbound Transport Billing Sales Orders Goods Deliveries Orders Documents Issues SAP AG 2007, Data Archiving In SAP Retail / Robert Peebles / 37The figure shows the typical process chain in a customer ordering scenario. It is based on the assumptionthat 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 salesorders, outbound deliveries via transaction VL10c are generated. For the picking of the goods at thewarehouse, transport orders are created for each outbound delivery. Next, billing documents need to begenerated. 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.© 2009 SAP AG - Data Volume Management for Retail page 55/67
  56. 56. Best PracticeData Volume Management for RetailThe following figure shows the different documents generated within each step of the process chain. Customer (Sales) Orders – document types Article documents Transport Outbound FI-documents Orders Deliveries Billing CO-documents Sales Orders Change Change Documents PCA-documents Change documents documents documents Application logs Change Application logs Application Application logs Info-Structures documents Info-Structures logs Info-Structures Application logs Info-Structures ACCT*-tables Info-Structures SAP AG 2007, Data Archiving In SAP Retail / Andrew Chew.Walter / 42The following section focuses on documents that were not considered in previous sections of this document.5.1 Sales orders (VBAK, VBAP)5.1.1 AvoidanceNot possible.5.1.2 SummarizationNot possible.5.1.3 DeletionNot possible.© 2009 SAP AG - Data Volume Management for Retail page 56/67

×