Datavolumemanagementforretail 130318011636 Phpapp02

Best Practice
Data Volume Management for Retail
Dietmar-Hopp-Allee 16
D-69190 Walldorf
CS
internal
DATE
September 22, 2009

SOLUTION MANAGEMENT PHASE
STATUS
In progress
VERSION
0.1
SAP SOLUTION
All project phases SAP for retail

TOPIC AREA
SOLUTION MANAGER AREA
Business Operations Data Volume Management
Best Practice
Date
Alteration Reason
22.09.2009
Creation
Version
0.1
Table of Contents
1 Management Summary
2 POS Inbound
2.1 IDocs (EDIDC, EDI40, EDIDS)
2.1.1 Avoidance
2.1.2 Summarization
2.1.3 Deletion
2.1.4 Archiving
2.2 Article Documents (MKPF, MSEG)
2.2.1 Avoidance
2.2.2 Summarization
2.2.3 Deletion
2.2.4 Archiving
2.3 Billing Documents (VBRK, VBRP)
2.3.1 Avoidance
2.3.2 Summarization
2.3.3 Deletion
2.3.4 Archiving
2.4 Financial documents (BKPF, RFBLG, FAGLFLEXA)
2.4.1 Avoidance
2.4.2 Summarization
2.4.3 Deletion
2.4.4 Archiving
2.5 Tables FAGL_SPLINFO & FAGL_SPLINFO_VAL
2.5.1 Avoidance
2.5.2 Summarization
2.5.3 Deletion
2.5.4 Archiving
2.6 Table BSIS
2.6.1 Avoidance
2.6.2 Summarization
2.6.3 Deletion
2.6.4 Archiving
2.7 Controlling Documents (COBK, COEP)
2.7.1 Avoidance
2.7.2 Summarization
2.7.3 Deletion
2.7.4 Archiving
2.8 Profit Center Accounting document line items (GLPCA)
2009 SAP AG - Data Volume Management for Retail
6
7
8
8
8
8
8
11
11
11
11
11
14
14
15
15
15
17
17
17
19
19
20
20
20
20
20
21
21
21
21
21
22
22
22
22
22
23
page 2/67
Best Practice
2.8.1 Avoidance
2.8.2 Summarization
2.8.3 Deletion
2.8.4 Archiving
2.9 ACCT*-tables
2.9.1 Avoidance
2.9.2 Summarization
2.9.3 Deletion
2.9.4 Archiving
2.10 Table CKMI1
2.10.1 Avoidance
2.10.2 Summarization
2.10.3 Deletion
2.10.4 Archiving
2.11 Tables IDOCREL & SRRELROLES
2.11.1 Avoidance
2.11.3 Deletion
2.11.4 Archiving
2.12 Tables WPTST & WPLST
2.12.1 Avoidance
2.12.3 Deletion
2.12.4 Archiving
2.13 Info-Structures (RIS/LIS tables Sxxx)
2.13.1 Avoidance
2.13.3 Deletion
2.13.4 Archiving
2.14 Application logs (BALHDR, BALDAT)
2.14.1 Avoidance
2.14.3 Deletion
2.14.4 Archiving
2.15 Work Items (SWWWI* tables)
2.15.1 Avoidance
2.15.3 Deletion
2.15.4 Archiving
3 Store Replenishment Cycle
3.1 Purchase Requisitions (EBAN)
3.1.1 Avoidance
3.1.2 Summarization
3.1.3 Deletion
3.1.4 Archiving
3.2 Purchase Orders (EKKO, EKPO)
23
23
23
23
24
24
24
24
24
25
25
25
25
25
26
26
26
26
26
27
27
27
27
27
28
28
31
31
31
32
32
32
32
32
34
34
34
34
35
37
39
39
40
40
40
41
page 3/67
Best Practice
3.2.1 Avoidance
3.2.2 Summarization
3.2.3 Deletion
3.2.4 Archiving
3.3 Change Documents (CDHDR, CDCLS)
3.3.1 Avoidance
3.3.2 Summarization
3.3.3 Deletion
3.3.4 Archiving
3.4 Outbound Deliveries (LIKP, LIPS)
3.4.1 Avoidance
3.4.2 Summarization
3.4.3 Deletion
3.4.4 Archiving
3.5 Transport Orders (LTAK, LTAP)
3.5.1 Avoidance
3.5.2 Summarization
3.5.3 Deletion
3.5.4 Archiving
4 Warehouse Replenishment Cycle
4.1 Forecast data (PROP, PRON, PROW, PROF, PROH)
4.1.1 Avoidance
4.1.2 Summarization
4.1.3 Deletion
4.1.4 Archiving
4.2 Vendor Invoices (WBRK, WBRP)
4.2.1 Avoidance
4.2.2 Summarization
4.2.3 Deletion
4.2.4 Archiving
5 Customer (Sales) Orders
5.1 Sales orders (VBAK, VBAP)
5.1.1 Avoidance
5.1.2 Summarization
5.1.3 Deletion
5.1.4 Archiving
6 POS Download / Assortment List
6.1 Change Pointers (BDCP. BDCPS, BDCP2, WIND)
6.1.1 Avoidance
6.1.2 Summarization
6.1.3 Deletion
6.1.4 Archiving
6.2 Assortment List (WBBH, WBBP)
6.2.1 Avoidance
6.2.2 Summarization
6.2.3 Deletion
41
41
41
41
44
44
45
45
46
48
48
48
48
48
49
49
49
49
49
50
51
51
51
52
52
53
53
53
53
53
55
56
56
56
56
57
59
60
60
63
63
65
65
65
65
65
page 4/67
Best Practice
6.2.4 Archiving
66
page 5/67
Best Practice
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:
Main Retail Processes
SAP Retail System

HQ
DC
Assortment
Planning
Delivery Notes
Transport
Orders
Goods Issues
MRP
Customer
Purchase Orders
Goods Receipts
Vendor
Sales Orders
Invoices
Goods
Receipts
Store
POS-Interface Outbound
Master data, Assortment List
Stock
Transfer
Orders
"R/3 Store"
Replenishment
Planning
Purchase
Orders
Goods
Receipts
POS Interface Inbound

Sales Data, Store Order
SAP AG 2007, Data Archiving In SAP Retail / Andrew Chew.Walter / 24
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.
page 6/67
Best Practice
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.
Major Contributor To Database Growth

(Table Entries Due To POS Inbound Process)
POS Inbound Process (processing of WPUUMS-IDocs)
WPUUMS
300 lines
Article doc.
100 lines
FI doc.
200 lines
CO doc.
100 lines
PCA doc.
200 lines
ACCT*
200 lines
CKMI1
100 lines
Article doc.
100 lines
FI doc.
200 lines
CO doc.
100 lines
PCA doc.
200 lines
ACCT*
200 lines
CKMI1
100 lines
Article doc.
100 lines
FI doc.
200 lines
CO doc.
100 lines
PCA doc.
200 lines
ACCT*
200 lines
CKMI1
100 lines
Billing doc.
100 lines
FI doc.
101 lines
PCA doc.
~ 200 lines
Billing doc.
100 lines
FI doc.
101 lines
PCA doc.
~ 200 lines
Billing doc.
100 lines
FI doc.
101 lines
PCA doc.
~ 200 lines
Info-Structures (S012, S031, S032, S033, S083, S084, S121, ....)

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
page 7/67
Best Practice
b.
c.
d.
e.
CKMI1
IDOCREL, SRRELROLES
WPTST, WPLST
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
03
18
53
02
03
51
03
53
51
29
29
18
29
33
02
29
02
Message Type
ORDERS
WP_PLU
MBGMCR
ZPROFORMA
ZPROFORMA
WPUUMS
DESADV
WPUUMS
MBGMCR
ZPROFORMA
WP_PLU
WP_EAN
WPDSET
ZPROFORMA
ORDERS
WP_EAN
DESADV
Month
04
04
04
04
04
04
04
04
04
04
04
04
04
04
04
04
04
Year
2008
2008
2008
2008
2008
2008
2008
2008
2008
2008
2008
2008
2008
2008
2008
2008
2008
No. Entr.
16.680
12.220
6.416
6.036
5.969
4.171
4.038
3.401
1.097
890
835
395
213
108
105
36
10
page 8/67
Best Practice
02
03
18
WP_EAN
ORDERS
WP_PLU
04
03
03
2008 2
2008 24.159
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.
page 9/67
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.
page 10/67
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.
page 11/67
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.
page 12/67
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.
page 13/67
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.
page 14/67
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.
page 15/67
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.
page 16/67
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.
page 17/67
Best Practice
Change
to 300
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.
Changes to POS Inbound Process
WPUUMS
300 lines
Article doc.
300 lines
FI doc.
~ 10 lines
CO doc.
1 line
Billing doc.
300 lines
FI doc.
~ 10 lines
PCA doc.
~ 20 lines
PCA doc.
~ 35 lines
Info-Structures (S012, S031, S121)
SAP AG 2007 , Data Archiving In SAP Retail / Andrew Chew.Walter / 27
page 18/67
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.
page 19/67
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.
page 20/67
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.
b.
c.
d.
e.
reconciliation accounts (SKB1-MITKZ <> SPACE)

tax accounts (SKB1-MWSKZ = < or SKB1-MWSKZ = >)
all sales revenue accounts, if CO-PA is active
all material stock accounts
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.
page 21/67
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.
page 22/67
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_OBJECT.
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.
page 23/67
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.
-----------------------------------------------------------------------------------------------------------------------------------------------------System: All servers
Not buffered tables
Time 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, 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.
page 24/67
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.
-----------------------------------------------------------------------------------------------------------------------------------------------------System: All servers
Not buffered tables
Time 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
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.
page 25/67
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.
2.11.2
Summarization
Not possible.
2.11.3
Deletion
Entries are deleted with program RSRLDREL and/or RSRLDREL2 (OSS note 853035). A periodic job should
be scheduled to delete the table entries regularly. The scheduling of the deletion job should be synchronized
with the frequency of the IDoc archiving. For example, if IDocs are archived daily, then the deletion job
should also be scheduled to run daily, but after the IDoc archiving and deletion jobs have been completed.
Refer to OSS notes 706478, 707820, 505608, and 566765 for further details.
2.11.4
Archiving
Not possible.
page 26/67
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.
2.12.2
Summarization
Not possible.
2.12.3
Deletion
The entries in these tables are deleted by programs RWPUDTST (table WPTST) and RWPUDLST (table
WPLST).
The scheduling of the deletion jobs should be in sync with the IDoc archiving jobs. If a daily archiving job is
scheduled to remove correctly posted IDocs older than 7 days, then the deletion jobs for RWPUDLST and
RWPUDTST should also run daily to remove the entries related to the archived IDocs only.
2.12.4
Archiving
Not possible.
page 27/67
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
Updating Control
Activate Update
Logistics Information System (LIS)

Updating
Deactivate updates for all info-structures
b.
Sales and Distribution

Sales Support (CAS)
Sales Summary
Uncheck field Statistics update desired for all line items
Set Document Display
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

Changes/
Total
Direct
Total(%)
reads
Seq.
reads
Changes
DB activity
Calls
03 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
S003
S004
S004
S004
S004
S004
S004
S004
S009
S009
S009
S009
S009
S009
S009
0
0
0
0
0
0
0
0
50
50
50
50
50
50
50
4
4
7
2
1
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
55.338
150.921
135.760
154.169
166.421
157.408
66.163
6
7
13
4
2
0
2
0
166.257
453.205
407.796
462.916
499.705
472.675
198.688
4
4
7
2
1
0
1
0
110.676
301.842
271.520
308.338
332.842
314.816
132.326
0
0
0
0
0
0
0
0
55.338
150.921
135.760
154.169
166.421
157.408
66.163
Rows
affected
0
0
0
0
0
0
0
0
110.744
301.966
271.663
308.453
332.971
314.941
132.382
page 28/67
Best Practice
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
04 2008
S011
S011
S011
S011
S011
S011
S011
S012
S012
S012
S012
S012
S012
S012
S013
S013
S013
S013
S013
S013
S013
S014
S014
S014
S014
S014
S014
S014
S021
S031
S031
S031
S031
S031
S031
S031
S032
S032
S032
S032
S032
S032
S032
S033
S033
S033
S033
S033
S033
S033
S034
S034
100
100
100
100
100
100
100
100
100
100
100
100
100
100
63,11
61,83
62,18
61,77
61,3
62,14
62,61
50
50
50
50
50
50
50
0
100
100
100
100
100
100
100
100
99,99
100
100
100
100
100
100
100
100
100
100
100
100
100
100
422.087
1.057.076
993.760
993.807
1.153.063
979.396
471.703
7.074.447
16.158.095
15.351.030
16.146.093
18.913.429
16.033.958
7.488.396
5.388.530
13.138.688
15.573.005
15.040.210
13.709.293
11.088.481
4.964.454
112.212
308.236
275.072
312.866
337.910
318.678
133.796
4
9.067.137
29.684.377
24.219.918
27.740.044
31.388.493
27.404.836
13.475.195
16.404.510
52.518.168
43.619.090
51.409.140
54.994.160
47.550.964
22.895.361
5.278.718
17.165.948
14.178.504
16.037.407
18.172.898
15.702.380
7.654.695
98.832
288.024
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1.987.718
5.015.042
5.889.761
5.749.934
5.305.617
4.197.755
1.856.378
56.106
154.118
137.536
156.433
168.955
159.339
66.898
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
5
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
4
3
12
10
11
21
15
0
6
3.550
13
12
63
16
0
0
0
0
0
0
0
0
0
0
422.087
1.057.076
993.760
993.807
1.153.063
979.396
471.703
7.074.447
16.158.090
15.351.029
16.146.092
18.913.429
16.033.958
7.488.396
3.400.812
8.123.646
9.683.244
9.290.276
8.403.676
6.890.726
3.108.076
56.106
154.118
137.536
156.433
168.955
159.339
66.898
0
9.067.134
29.684.365
24.219.908
27.740.033
31.388.472
27.404.821
13.475.195
16.404.504
52.514.618
43.619.077
51.409.128
54.994.097
47.550.948
22.895.361
5.278.718
17.165.948
14.178.504
16.037.407
18.172.898
15.702.380
7.654.695
98.832
288.024
422.691
1.058.224
995.219
995.092
1.154.441
980.736
472.357
7.075.134
16.159.419
15.352.705
16.147.595
18.915.053
16.035.563
7.489.126
7.479.569
18.426.829
21.697.212
21.040.386
19.305.953
15.530.702
6.922.519
168.617
462.901
413.264
469.805
507.430
478.577
200.948
7
9.067.518
29.685.144
24.220.860
27.740.929
31.389.477
27.405.712
13.475.622
16.405.508
52.520.803
43.621.844
51.411.810
55.006.528
47.553.610
22.896.421
5.278.911
17.166.414
14.179.026
16.037.889
18.173.463
15.702.870
7.654.949
99.014
288.354
414.663
1.045.136
980.854
981.484
1.139.966
967.244
464.713
5.493.218
12.586.587
11.687.130
12.416.649
14.974.042
12.813.630
5.962.169
3.975.626
10.030.205
11.779.580
11.499.957
10.611.344
8.395.559
3.712.808
112.278
308.358
275.217
312.977
338.041
318.802
133.853
0
5.278.814
17.166.230
14.179.373
16.041.116
18.173.223
15.702.635
7.654.844
15.399.011
49.092.462
41.164.544
46.828.317
54.838.650
45.330.442
21.684.869
5.278.817
17.166.233
14.178.794
16.037.685
18.173.226
15.702.657
7.654.843
95.262
278.603
page 29/67
Best Practice
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
08 2008
03 2008
08 2008
04 2008
05 2008
08 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
04 2008
05 2008
06 2008
07 2008
S034
S034
S034
S034
S034
S035
S035
S035
S035
S035
S035
S035
S039
S039
S039
S039
S039
S039
S039
S061
S061
S061
S061
S061
S061
S061
S062
S062
S062
S062
S062
S062
S062
S066
S066
S067
S067
S071
S071
S091
S111
S111
S111
S111
S111
S111
S111
S123
S123
S123
S123
S123
100
100
100
100
100
100
100
100
100
100
100
100
0
0
0
0
0
42,86
0
100
100
100
100
100
100
100
100
100
100
100
100
100
100
0
0
0
0
0
0
0
100
100
100
100
100
100
100
100
100
100
100
100
374.404
258.465
329.052
292.450
119.955
13.222
41.472
39.533
38.717
46.222
44.816
19.464
4
2
3
0
5
7
0
249
1.987
2.204
2.324
1.848
1.813
825
248
1.961
2.189
2.304
1.834
1.801
818
12
1
12
1
1
0
0
212
183
70
157
211
124
69
318.975
918.040
846.579
918.570
953.979
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
4
2
3
0
5
4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
12
1
12
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
374.404
258.465
329.052
292.450
119.955
13.222
41.472
39.533
38.717
46.222
44.816
19.464
0
0
0
0
0
3
0
249
1.987
2.204
2.324
1.848
1.813
825
248
1.961
2.189
2.304
1.834
1.801
818
0
0
0
0
0
0
0
212
183
70
157
211
124
69
318.975
918.040
846.579
918.570
953.979
374.810
258.811
329.418
292.854
120.137
13.384
41.778
39.908
39.040
46.562
45.188
19.640
8
4
6
0
9
13
0
281
2.076
2.296
2.407
1.948
1.907
887
302
2.111
2.352
2.453
2.000
1.967
920
26
3
19
2
2
0
0
271
220
96
190
258
162
89
319.266
918.608
847.216
919.079
954.552
365.394
249.457
319.176
281.852
115.155
11.105
35.145
34.572
33.261
40.359
37.743
17.157
0
0
0
0
0
12
0
246
1.976
2.193
2.315
1.834
1.804
817
270
2.033
2.264
2.375
1.912
1.880
867
0
0
0
0
0
0
0
2.663
1.940
503
1.390
5.103
1.435
520
311.894
902.435
830.729
901.353
936.196
page 30/67
Best Practice
08 2008
09 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
03 2008
04 2008
05 2008
06 2008
07 2008
08 2008
09 2008
S123
S123
S124
S124
S124
S124
S124
S124
S124
S135
S135
S135
S135
S135
S135
S999
S999
S999
S999
S999
S999
S999
100
100
100
100
100
100
100
100
100
0
50
0
0
58,82
0
100
100
100
100
100
100
100
921.387
404.009
3.120.258
9.045.350
8.869.718
10.119.952
10.720.966
10.587.379
4.658.581
1
20
2
1
17
0
8.594.709
28.996.466
22.848.597
26.300.363
30.371.134
25.828.656
13.084.692
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
10
2
1
7
0
0
0
0
0
0
0
0
921.387
404.009
3.120.258
9.045.350
8.869.718
10.119.952
10.720.966
10.587.379
4.658.581
0
10
0
0
10
0
8.594.709
28.996.466
22.848.597
26.300.363
30.371.134
25.828.656
13.084.692
921.948
404.255
3.120.608
9.046.031
8.870.503
10.120.572
10.721.719
10.588.071
4.658.873
3
31
3
2
23
0
8.595.096
28.997.246
22.849.531
26.301.211
30.372.140
25.829.529
13.085.126
903.158
392.154
2.170.232
6.320.454
6.100.252
6.993.216
7.523.487
7.359.724
3.141.778
0
14
0
0
10
0
5.249.665
17.206.044
14.109.766
15.963.577
18.225.920
15.649.537
7.672.875
All info-structures with WRITE access only (100% changes) can theoretically be deactivated immediately.
Next, check tables MCRSV and MCSI. If info-structures are used for reporting purposes, selection versions
are usually created. These selection versions are stored in tables MCRSV and MCSI. If these tables are
empty, it is an indication that the info-structures are not used by the business for reporting.
Nevertheless, the business needs to provide the necessary information of the reporting requirements.
2.13.2
Summarization
Not possible.
2.13.3
Deletion
Not possible.
2.13.4
Archiving
There are no standard archiving objects for the info-structures. The archiving objects have to be generated
via transaction MCSX. The generated archiving objects are MC_Sxxx, where Sxxx is the info-structure
name.
Use transaction SARA to schedule archiving jobs for the archiving objects MC_Sxxx.
page 31/67
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.
2.14.2
Summarization
Not possible.
2.14.3
Deletion
Transaction SLG2 (program SBAL_DELETE) is used for deleting application logs. In the selection screen,
the and logs which can be deleted before the expiry date radio button should be flagged because the
majority of the logs normally have the expiry date 31.12.9999.
In the selection variant, it is recommended to set up the fields creation date: from and creation date: to as
dynamic variables, as shown in the example below.
Create a secondary index on table BALHDR with fields MANDANT, ALDATE.

Due to the potentially high volume of application logs, we recommend that you schedule a daily deletion job.
2.14.4
Archiving
If the business requires application logs to be archived, instead of simply deleted, the archiving object
BC_SBAL should be used.
This archiving object does not require the set up of residence times for application logs in the customizing of
this object. The creation dates (from/to) should be set up as dynamic variables
page 32/67
Best Practice
Create a secondary index on table BALHDR with fields MANDANT, ALDATE.

Schedule a daily archiving job.
page 33/67
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.
2.15.2
Summarization
Not possible.
2.15.3
Deletion
Work items can be deleted with program RSWWWIDE. The Creation date field should be set up as a
dynamic variable.
page 34/67
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.
page 35/67
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.
page 36/67
Best Practice
Store Replenishment Cycle
Store Replenishment Cycle
POS
Upload
Post store
goods
receipts
Post
warehouse
goods issues
Store
Replenishment
Planning
Create
outbound
deliveries
Create transport
orders (optional)
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.
page 37/67
Best Practice
The 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
CO-doc.: COBK, COEP
PCA-doc.: GLPCA
ACCT*-Tables
Links between IDocs and applications: SRRELROLES, IDOCREL
Workitems: SWWWIHEAD, ....
Application logs: BALHDR, BALDAT
POS
Info-Structu res (Sxxx)
Upload
Article doc.: MKPF, MSEG

FI-doc.: BKPF, RFBLG, FAGL FLEXA
FAGL_SPLINFO, FAGL_SPLINFO_VAL
BSIS, BSAS
Chan ge doc.: CDHDR, CDCLS
Ap plication Logs: BALHDR, BALDAT
ACCT*-tables
Info-Stru ctures (Sxxx)
Purchase req uisitions: EBAN

Purchase orders: EKKO, EKPO
Change docu ments: CDHDR, CDCLS
Application log s: BALHDR, BAL DAT
Info -Structures (Sxxx)
Store
Replenishment
Planning
Post store
goods
receipts
Create
outbound
deliver ies
Outboun d Deliveries: LIKP, LIKPS

Ch ange documen ts: CDHDR, CDCLS
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
BSIS, BSAS
Change doc.: CDHDR, CDCLS
Application Logs: BALHDR, BALDAT
ACCT*-tables
Info-Structures (Sxxx)
Transport orders: LTAK, LTAP

Change documents: CDHDR, CDCLS
In fo-Structures (Sxxx)
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.
page 38/67
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
Follow-on Documents (via Store Order)
Consumption-based Planning
Replenishment Control
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.
page 39/67
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.
page 40/67
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.
page 41/67
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.
page 42/67
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.
page 43/67
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 (OBJECTCLAS) of change documents created by a customer.
OBJECTCLAS
COND_A
ADRESSE
MAT_FULL
EINKBELEG
LIEFERUNG
VERKBELEG
BANF
BELEG
INFOSATZ
ANLA
BELEGR
WLK1
TRANSPORT
MATERIAL
ORDERBUCH
DEBI
HANDL_UNIT
KRED
SACH
ASMODULE
PFCG
BETRIEB
FAKTBELEG
SETS
KOSTL
BANK
ADRESSE3
PRCTR
WREFA
BELEGD
KLASSE
STUE
STUE_V
NRINTERVAL
WBASISWG
KSTAR
ALLOCATION
PROJ
BELEGV
INCOMINGINVOICE
# Entries
83.392.799
6.815.547
4.676.681
4.117.305
3.923.894
3.166.077
2.602.251
2.315.976
1.790.371
1.664.961
1.189.519
1.154.827
689.253
606.602
453.824
371.996
256.326
203.982
137.016
49.347
24.829
22.383
16.219
13.270
11.932
10.744
8.361
4.949
4.268
3.173
1.715
893
892
576
499
496
250
240
223
66
page 44/67
Best Practice
EQUI
FEATURE
RKAUFTRAG
CMDT_PC
MELDUNG
CHARGE
NRKROBJ
LSTAR
LAYOUT_MOD
PROJS
57
30
6
5
5
3
3
2
1
1
While most of the change documents cannot be avoided during normal operations, change documents due to
article listing (OBJECTCLAS = 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 (OBJECTCLAS = WLK1,
ASMODULE, WBASISWG, LAYMOD).
page 45/67
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
OBJECTCLAS 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 OBJECTCLAS = COND_A that are older than 30 days.
page 46/67
Best Practice
Depending on the volume, it may be necessary to schedule a daily archiving run for change documents.
page 47/67
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.
page 48/67
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.
page 49/67
Best Practice
Warehouse Replenishment Cycle

Warehouse Replenishment Cycle
Material
Requirement
Planning (MRP)
Forecast
(optional)
+ Pur. Req.
Invoice
Verification
& Payment
Post
warehouse
goods
receipts
Convert
Purchase
Requisitions
to Purchase
Orders
Send Order to
vendors
SAP AG 2007 , Data Archiving In SAP Re tail / Robert Peebles / 35
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.
page 50/67
Best Practice
The following figure shows the different types of documents created
Warehouse Replenishment Cycle documents created
Forecast
data
Purchase requisitions
Change documents
Application logs
Info-Structures
Vendor invoices
FI-documents
CO-documents
PCA-documents
Change documents
Application logs
Info-Structures
Article documents
FI-documents
CO-documents
PCA-documents
Change documents
Application logs
Info-Structures
Purchase Orders
Change documents
Application logs
Info-Structures
IDocs
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.
page 51/67
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.
page 52/67
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.
page 53/67
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.
page 54/67
Best Practice
Customer (Sales) Orders
Customer (Sales) Orders
Create
Sales Orders
Create
Outbound
Deliveries
Create
Transport
Orders
Create
Billing
Documents
Post
Warehouse
Goods
Issues
SAP AG 2007, Data Archiving In SAP Retail / Robert Peebles / 37
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.
page 55/67
Best Practice
The following figure shows the different documents generated within each step of the process chain.
Customer (Sales) Orders document types
Sales Orders
Change documents
Application logs
Info-Structures
Outbound
Deliveries
Change
documents
Application logs
Info-Structures
Transport
Orders
Change
documents
Application
logs
Info-Structures
Billing
Documents
Application logs
Info-Structures
Article
documents
FI-documents
CO-documents
PCA-documents
Change
documents
Application logs
ACCT*-tables
Info-Structures
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.
page 56/67
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.
page 57/67
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.
page 58/67
Best Practice
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 Download / Assortment List
Article maintenance
Price maintenance
Promotion
Create outgoing
IDocs
Create assortment
lists
Send IDocs to stores
page 59/67
Best Practice
The following diagram shows the different types of documents created during each step of the POS download
/ assortment list process.
POS Download / Assortment List documents created
Change documents
Change pointers
IDocs
Assortment list
IDoc status entries
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.
page 60/67
Best Practice
page 61/67
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.
page 62/67
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.
page 63/67
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.
page 64/67
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.
page 65/67
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.
page 66/67
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.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript 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.
page 67/67

Datavolumemanagementforretail 130318011636 Phpapp02

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Datavolumemanagementforretail 130318011636 Phpapp02

Uploaded by

Copyright:

Available Formats

Best Practice

Data Volume Management for Retail

September 22, 2009

All project phases SAP for retail

SOLUTION MANAGER AREA

Business Operations Data Volume Management

2009 SAP AG - Data Volume Management for Retail

2009 SAP AG - Data Volume Management for Retail

2009 SAP AG - Data Volume Management for Retail

2009 SAP AG - Data Volume Management for Retail

Main Retail Processes

SAP Retail System

POS Interface Inbound

SAP AG 2007, Data Archiving In SAP Retail / Andrew Chew.Walter / 24

2009 SAP AG - Data Volume Management for Retail

Major Contributor To Database Growth

Info-Structures (S012, S031, S032, S033, S083, S084, S121, ....)

IDocs (EDIDC, EDI40, EDIDS)

2009 SAP AG - Data Volume Management for Retail

Example: IDoc status 29

2009 SAP AG - Data Volume Management for Retail

2009 SAP AG - Data Volume Management for Retail

Article Documents (MKPF, MSEG)

2009 SAP AG - Data Volume Management for Retail

2009 SAP AG - Data Volume Management for Retail

2009 SAP AG - Data Volume Management for Retail

Billing Documents (VBRK, VBRP)

2009 SAP AG - Data Volume Management for Retail

2009 SAP AG - Data Volume Management for Retail

2009 SAP AG - Data Volume Management for Retail

Financial documents (BKPF, RFBLG, FAGLFLEXA)

2009 SAP AG - Data Volume Management for Retail

Changes to POS Inbound Process

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

2009 SAP AG - Data Volume Management for Retail

Tables FAGL_SPLINFO & FAGL_SPLINFO_VAL

2009 SAP AG - Data Volume Management for Retail

reconciliation accounts (SKB1-MITKZ <> SPACE)

Refer to note 178487 for further details.

2009 SAP AG - Data Volume Management for Retail

Controlling Documents (COBK, COEP)

Not possible. Entries are removed via archiving.

2009 SAP AG - Data Volume Management for Retail

Profit Center Accounting document line items (GLPCA)

2009 SAP AG - Data Volume Management for Retail

See OSS note 48009.

2009 SAP AG - Data Volume Management for Retail

2009 SAP AG - Data Volume Management for Retail

Tables IDOCREL & SRRELROLES

2009 SAP AG - Data Volume Management for Retail

Tables WPTST & WPLST

2009 SAP AG - Data Volume Management for Retail

Info-Structures (RIS/LIS tables Sxxx)

xxx = 001 to 499

Logistics Information System (LIS)

Sales and Distribution

Set Document Display

ABAP/IV Processor requests

2009 SAP AG - Data Volume Management for Retail

2009 SAP AG - Data Volume Management for Retail

2009 SAP AG - Data Volume Management for Retail