Best Practice: Data Volume Management For Retail

Best Practice
Data 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
Best Practice
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.3 Deletion 11
2.2.4 Archiving 11
2.3 Billing Documents (VBRK, VBRP) 14
2.3.1 Avoidance 14
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.3 Deletion 19
2.4.4 Archiving 19
2.5 Tables FAGL_SPLINFO & FAGL_SPLINFO_VAL 20
2.5.1 Avoidance 20
2.5.3 Deletion 20
2.5.4 Archiving 20
2.6 Table BSIS 21
2.6.1 Avoidance 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.3 Deletion 22
2.7.4 Archiving 22
2.8 Profit Center Accounting document line items (GLPCA) 23
Best Practice
2.8.1 Avoidance 23
2.8.3 Deletion 23
2.8.4 Archiving 23
2.9 ACCT*-tables 24
2.9.1 Avoidance 24
2.9.3 Deletion 24
2.9.4 Archiving 24
2.10Table CKMI1 25
2.10.1 Avoidance 25
2.10.3 Deletion 25
2.10.4 Archiving 25
2.11Tables IDOCREL & SRRELROLES 26
2.11.1 Avoidance 26
2.11.3 Deletion 26
2.11.4 Archiving 26
2.12Tables WPTST & WPLST 27
2.12.1 Avoidance 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.3 Deletion 31
2.13.4 Archiving 31
2.14Application logs (BALHDR, BALDAT) 32
2.14.1 Avoidance 32
2.14.3 Deletion 32
2.14.4 Archiving 32
2.15Work Items (SWWWI* tables) 34
2.15.1 Avoidance 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.3 Deletion 40
3.1.4 Archiving 40
3.2 Purchase Orders (EKKO, EKPO) 41
Best Practice
3.2.1 Avoidance 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.3 Deletion 45
3.3.4 Archiving 46
3.4 Outbound Deliveries (LIKP, LIPS) 48
3.4.1 Avoidance 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.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.3 Deletion 52
4.1.4 Archiving 52
4.2 Vendor Invoices (WBRK, WBRP) 53
4.2.1 Avoidance 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.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.3 Deletion 63
6.1.4 Archiving 65
6.2 Assortment List (WBBH, WBBP) 65
6.2.1 Avoidance 65
6.2.3 Deletion 65
Best Practice
6.2.4 Archiving 66
Best Practice
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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.
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
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
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
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
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.
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
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.
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
Create a secondary index on table BALHDR with fields MANDANT, ALDATE.
Schedule a daily archiving job.
Best Practice
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.
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
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
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
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.
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
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.
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
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
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
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
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
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
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
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
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
Depending on the volume, it may be necessary to schedule a daily archiving run for change documents.
Best Practice
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
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
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
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.
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
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
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
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
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
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.
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
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
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
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.
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
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.
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
Best Practice
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
/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
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
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
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
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.

Best Practice: Data Volume Management For Retail

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Best Practice: Data Volume Management For Retail

Încărcat de

Drepturi de autor:

Formate disponibile

Best Practice

Data Volume Management for Retail

S-ar putea să vă placă și