Data volume management for retail

Best Practice

Data Volume Management for Retail

Dietmar-Hopp-Allee 16D-69190 Walldorf

CS STATUSinternal 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 PracticeData Volume Management for Retail

© 2009 SAP AG - Data Volume Management for Retail page 2/67

Date Alteration Reason Version

22.09.2009 Creation 0.1

Table of Contents1 Management Summary 62 POS Inbound 7

2.1 IDocs (EDIDC, EDI40, EDIDS) 82.1.1 Avoidance 82.1.2 Summarization 82.1.3 Deletion 82.1.4 Archiving 8

2.2 Article Documents (MKPF, MSEG) 112.2.1 Avoidance 112.2.2 Summarization 112.2.3 Deletion 112.2.4 Archiving 11

2.3 Billing Documents (VBRK, VBRP) 142.3.1 Avoidance 142.3.2 Summarization 152.3.3 Deletion 152.3.4 Archiving 15

2.4 Financial documents (BKPF, RFBLG, FAGLFLEXA) 172.4.1 Avoidance 172.4.2 Summarization 172.4.3 Deletion 192.4.4 Archiving 19

2.5 Tables FAGL_SPLINFO & FAGL_SPLINFO_VAL 202.5.1 Avoidance 202.5.2 Summarization 202.5.3 Deletion 202.5.4 Archiving 20

2.6 Table BSIS 212.6.1 Avoidance 212.6.2 Summarization 212.6.3 Deletion 212.6.4 Archiving 21

2.7 Controlling Documents (COBK, COEP) 222.7.1 Avoidance 222.7.2 Summarization 222.7.3 Deletion 222.7.4 Archiving 22

2.8 Profit Center Accounting document line items (GLPCA) 23



2.8.1 Avoidance 232.8.2 Summarization 232.8.3 Deletion 232.8.4 Archiving 23

2.9 ACCT*-tables 242.9.1 Avoidance 242.9.2 Summarization 242.9.3 Deletion 242.9.4 Archiving 24

2.10 Table CKMI1 252.10.1 Avoidance 252.10.2 Summarization 252.10.3 Deletion 252.10.4 Archiving 25

2.11 Tables IDOCREL & SRRELROLES 262.11.1 Avoidance 262.11.2 Summarization 262.11.3 Deletion 262.11.4 Archiving 26

2.12 Tables WPTST & WPLST 272.12.1 Avoidance 272.12.2 Summarization 272.12.3 Deletion 272.12.4 Archiving 27

2.13 Info-Structures (RIS/LIS – tables Sxxx) 282.13.1 Avoidance 282.13.2 Summarization 312.13.3 Deletion 312.13.4 Archiving 31

2.14 Application logs (BALHDR, BALDAT) 322.14.1 Avoidance 322.14.2 Summarization 322.14.3 Deletion 322.14.4 Archiving 32

2.15 Work Items (SWWWI* tables) 342.15.1 Avoidance 342.15.2 Summarization 342.15.3 Deletion 342.15.4 Archiving 35

3 Store Replenishment Cycle 373.1 Purchase Requisitions (EBAN) 39


3.2 Purchase Orders (EKKO, EKPO) 41




3.3 Change Documents (CDHDR, CDCLS) 443.3.1 Avoidance 443.3.2 Summarization 453.3.3 Deletion 453.3.4 Archiving 46

3.4 Outbound Deliveries (LIKP, LIPS) 483.4.1 Avoidance 483.4.2 Summarization 483.4.3 Deletion 483.4.4 Archiving 48

3.5 Transport Orders (LTAK, LTAP) 493.5.1 Avoidance 493.5.2 Summarization 493.5.3 Deletion 493.5.4 Archiving 49

4 Warehouse Replenishment Cycle 504.1 Forecast data (PROP, PRON, PROW, PROF, PROH) 51


4.2 Vendor Invoices (WBRK, WBRP) 534.2.1 Avoidance 534.2.2 Summarization 534.2.3 Deletion 534.2.4 Archiving 53

5 Customer (Sales) Orders 555.1 Sales orders (VBAK, VBAP) 56


6 POS Download / Assortment List 596.1 Change Pointers (BDCP. BDCPS, BDCP2, WIND) 60


6.2 Assortment List (WBBH, WBBP) 656.2.1 Avoidance 656.2.2 Summarization 656.2.3 Deletion 65



6.2.4 Archiving 66



1 Management Summary

This paper describes a few main retail processes and their contributions to data growth in a Retailenvironment.

The main processes considered in this paper are:

POS Inbound (aggregated sales using WPUUMS-IDocs) Store procurement cycle Warehouse procurement cycle Sales (customer) orders POS Outbound / Assortment 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 generatedwill be given, followed by the possibilities of data avoidance, summarization, deletion, and archiving for eachtype of document.

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

Main Retail Processes

SAP Retail System

Vendor

DCDelivery Notes

TransportOrders

Goods IssuesMRP

HQAssortment

Planning

Store "R/3 Store"Replenishment

PlanningPOS-Interface Outbound

Master data, Assortment List

POS Interface Inbound

Sales Data, Store Order

Purchase Orders

PurchaseOrders

GoodsReceipts

GoodsReceipts

StockTransferOrders

Invoices

Sales Orders

CustomerGoods Receipts



2 POS Inbound

The POS Inbound process is not only one of the most runtime-critical processes within a retail environment; itis also one of the largest contributors to the high data volumes created on a daily basis.

The figure above is based on a live customer example before optimization took place. The posting of eachdocument type in the POS Inbound process is based on standard settings.

Each store sends its sales data at the end of the day to the head office for processing. The sales data isaggregated at article/store/day level. Each IDoc (message type WPUUMS) contained 300 articles and eachstore sent an average of 25 IDocs per day.

The IDocs are stored in tables EDIDC, EDI40 and EDIDS. EDI40 being the line-item table, it is alwaysamong the fastest growing tables in a typical retail environment. The posting of each IDoc generates thefollowing main documents:

a. article documents (tables MKPF, MSEG)b. billing documents (tables VBRK, VBRP)c. financial documents (tables BKPF, RFBLG; FAGLFLEXA, FAGL_SPLINFO,

FAGL_SPLINFO_VAL, BSIS, ...)d. controlling documents (tables COBK, COEP)e. profit centre accounting documents (table GLPCA)f. application logsg. work items

Besides the main documents, updates to other tables are also carried out. These other tables are:a. ACCT*-tables


Major Contributor To Database Growth(Table Entries Due To POS Inbound Process)

POS Inbound Process (processing of WPUUMS-IDocs)

WPUUMS300 lines

Article 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

CKMI1100 lines

ACCT*200 lines

ACCT*200 lines

CKMI1100 lines

CKMI1100 lines

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



b. CKMI1c. IDOCREL, SRRELROLESd. WPTST, WPLSTe. Info-structures (S012, S031, and so on)

2.1 IDocs (EDIDC, EDI40, EDIDS)

The table EDI40 is among the fastest growing tables in retail. Therefore, we strongly recommend that dailyarchiving jobs be scheduled to remove the entries in the IDoc tables.

2.1.1 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 productiveuse. 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 thedifferent message types, statuses und dates of last posting. The analysis is done using transaction TAANA.Virtual fields for MONTH and YEAR based on EDIDC-UPDDAT are necessary. An example of the analysisresults is shown in the following table:

Status Message Type Month Year No. Entr.03 ORDERS 04 2008 16.68018 WP_PLU 04 2008 12.22053 MBGMCR 04 2008 6.41602 ZPROFORMA 04 2008 6.03603 ZPROFORMA 04 2008 5.96951 WPUUMS 04 2008 4.17103 DESADV 04 2008 4.03853 WPUUMS 04 2008 3.40151 MBGMCR 04 2008 1.09729 ZPROFORMA 04 2008 89029 WP_PLU 04 2008 83518 WP_EAN 04 2008 39529 WPDSET 04 2008 21333 ZPROFORMA 04 2008 10802 ORDERS 04 2008 10529 WP_EAN 04 2008 3602 DESADV 04 2008 10



02 WP_EAN 04 2008 203 ORDERS 03 2008 24.15918 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 arecorrectly processed have status 53, whereas outgoing IDocs that are correctly sent have statuses 03 or 12,depending on the configuration of the outbound process.

As a first step, the setting up of the variant of the archiving object should contain only these statuses (53, 03,and 12). There is no customizing for the residence time for IDocs. The residence times should beconsidered in the variant by using the posting date as a dynamic variable.

In the example below, the variant has been set up to pick up all IDocs with statuses 53, 03 and 12 and who’sposting dates are older than or equal to current date minus 8 days.



In the case of erroneous IDocs, a second variant should be set up to pick up these statuses. This secondvariant should select IDocs with posting dates older than 2 months.

Note that IDocs with statuses 64 and 30 in the current period and previous period must never be archived.



2.2 Article Documents (MKPF, MSEG)

The line item table for article documents (MSEG) is among the fastest growing tables in retail. Articledocuments resulting from POS are easily identified by the field MKPF-BKTXT = ‘POS/xxxx’, where xxxx =store number.

The following figures are examples from a live customer.

The figure on the left shows that only a relatively small percentage of all article documents are from the POS.However, the figure on the right shows that the majority of the line items in the line item table were due tothese POS article documents

Therefore, the archiving of article documents resulting from POS has to be more aggressive than other typesof 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 beapplied first.

The archiving object MM_MATBEL requires the set up of residence time of the article documents incustomizing.



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 bedefined.

The example below is from a live customer. The article documents from POS are archived daily, keeping amoving trail of documents for 90 days. In this case, the posting date has been defined as a dynamic variable.



Note that some customers are archiving all POS article documents older than 1 week on a daily basis. Thismeasure is necessary to prevent the table MSEG from growing quickly.

To archive non-POS article documents, the field “POS” must not be flagged. The “Transaction/Event type”field can/should be used to further refine the selection. Avoid using the “Plant” field as this causes theselection of article documents to be carried out on the line item table. Selection on table MSEG has animpact on the runtime of the archiving job.



2.3 Billing Documents (VBRK, VBRP)

The line item table for billing documents (VBRP) is normally among the fastest growing tables in retail. Thedocument type relevant for POS is defined in the customizing of the POS Inbound profile used. The standarddocument type is FP and the line item type is DLN (customizing of POS Inbound profile, see below).

The following example is from a live customer.

The figure on the left shows that the billing documents from POS accounts for approximately 40% of all billingdocuments in the system. However, the figure on the right shows that the line items from POS billingdocuments accounts for almost all the billing document line items in the system.

Therefore, the archiving of billing documents should initially focus on billing documents from POS.

2.3.1 Avoidance

Billing documents from POS can be avoided through customization of the POS Inbound profile.



With field billing set to “1”, billing documents are created during runtime for updates to Finance and othermodules, but are not saved to the database at the end of the processing. This setting should only be used ifthe billing documents are not required by the business.

2.3.2 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 forthe different billing document types.

The example below shows the set up for document type FP. Here, the residence time has been set to 14days.

After the residence time has been set up, a variant needs to be defined.



The example above shows the variant used by a customer for the daily archiving run for billing documentsfrom POS older than 90 days.

The variant attributes show that the date has been set up as a dynamic variable.



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 lineitems of the classical General Ledger, table FAGLFLEXA is a transparent table used for storing the line itemsof the New General Ledger.

The New General Ledger is available as from Release ECC5 (ERP 2004). However, it is not automaticallyactivated when the system is upgraded from an older release to the latest release. The classical GL and theNew GL are both active in a new installation.

2.4.1 Avoidance

Not possible.

2.4.2 Summarization

Summarization of FI document line items is mandatory for every high volume project, especially retail. Thesummarization is set up using transaction OBCY. Note that summarization is only relevant for the classicalGeneral Ledger (table BSEG), and not for the New General Ledger (table FAGLFLEXA).

See OSS note 36353 for information concerning summarization via OBCY.

Program RSUMSIFI can be used to simulate the summarization of the BSEG entries. With OSS note1247473, the selection criteria of this program are expanded to allow the selection by period for thesimulation.

In the case of table FAGLFLEXA, there is no summarization transaction. The FAGLFLEXA profits from thesummarization setup for the table BSEG. Furthermore, the data volume depends strongly on the setup of theLedgers (leading and non-leading ledgers) and the number of characteristics and fields used for updates incustomizing of the New GL. Therefore, utmost care must be taken when setting up the New GL. Once thesystem is productive, it is extremely difficult (even impossible) to revert the settings as this may lead toinconsistencies in FI-posting.

In the case of WPUUMS-IDocs, we strongly recommend that each IDoc results in one article document andone billing document, to achieve the best possible summarization in FI. This is done by setting the number ofline items in the article and billing documents in the POS Inbound profile to be identical to the number ofarticles in each IDoc.



The figure below shows the documents generated by each WPUUMS-IDoc after the optimization measureswere implemented. Through the summarization in FI, the number of line items has been reducedsignificantly.


Changes to POS Inbound Process

WPUUMS300 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)

Changeto 300



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 documentscan be archived, the set up of the residence times for the different FI document types must be completed inthe customizing of the archiving object.

From a purely technical perspective, FI documents can be archived when the period is closed. Thisimplies that all FI documents older than 3 months can be archived. This situation applies to all FIdocuments belonging to accounts that are not open-item managed. Open item manageddocuments are never closed and as such, can never be archived. These documents need to beclosed by the users on a regular basis.



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_SPLINFOand FAGL_SPLINFO_VAL. These 2 tables are usually among the top 20 largest tables in a productivesystem.

2.5.1 Avoidance

During the posting of billing documents to FI, high data volumes in FAGL_SPLINFO andFAGL_SPLINFO_VAL due to large number of tax lines were observed. To avoid unnecessary line items inthese tables, OSS notes 1137444 and 1157202 must be applied.

2.5.2 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.



2.6 Table BSIS

The data volumes in table BSIS are strongly dependent on the number of accounts with line-item displayfunction switched on. The accounts with this function can be easily identified in table SKB1 with field XKRES= ‘X’.

2.6.1 Avoidance

We strongly recommend that the line item display functionality be switched on only for those accounts thatreally require it.

According to OSS note 178487, the line item display functionality should be deactivated for the followingaccount types:

a. reconciliation accounts (SKB1-MITKZ <> SPACE)b. tax accounts (SKB1-MWSKZ = ‘<’ or SKB1-MWSKZ = ‘>’)c. all sales revenue accounts, if CO-PA is actived. all material stock accountse. 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 datawritten 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 residencetimes must be done in the customizing of the archiving object.



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 modificationdescribed 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 note147766.

To determine the potential of summarization, program RARCCOA5 can be used to simulate thesummarization of existing table entries. The simulation can be done for different fields. As such, it isnecessary to identify the fields for which details are required. The output of this 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 beused. The results of the analysis via RARCCOA1 are displayed via program RARCCOA2.

However, the archiving objects shown in the analysis via RARCCOA1 are not always effective in keeping thedata volumes down. Example: CO_COSTCTR. This archiving object allows archiving only on an annualbasis. In general, it is advisable to use archiving object CO_ITEM on a monthly basis and then use otherarchiving objects to remove the remaining entries.

Before archiving can be carried out, the residence times of the table entries must be set up in the customizingof the archiving objects.



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 thetop 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 GLincorporates the profit center accounting reporting functionalities.

If a customer upgrades from an older release to a newer release where the New GL is available, a migrationproject of classical GL to the New GL can be done. Furthermore, the PCA reporting can be moved to the NewGL. Once this is completed, the classical profit centre accounting (GLPCA) can be deactivated.

OSS note 178919 provides tips on how to avoid unnecessary data.

2.8.2 Summarization

Summarization of document line items (table GLPCA) can be set up via transaction 0KE8. OSS note 198519provides a program for simulating the summarization of the entries in table GLPCA.

2.8.3 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 olderreleases, the archiving object is PCA_OBJECT.

Both archiving objects do not require the definition of the residence time in customizing. The selection issimply defined in the variant used. It is recommended to run archiving of GLPCA entries on a monthly basis.



2.9 ACCT*-tables

In the standard delivery, the updating of table ACCTIT, ACCTHD and ACCTCR is active. These tablescontain entries that are required for the subsequent posting of detailed data from MM to CO, or in somecases, the use of special Ledger. It is extremely seldom that these tables are required by customers for theirbusiness processes. Every goods movement line item (table MSEG) has 2 corresponding entries in tableACCTIT.

OSS note 48009 provides detailed information on the purposes of these tables and how to deactivate them.

2.9.1 Avoidance

The updating of these tables can be deactivated by the modification described in OSS note 48009. A strongindication that the entries are not required by the business can be won by looking at the table call statistics intransaction ST10 for all servers and all previous months (tables that are not buffered).

The example below was extracted from a customer’s productive system and it shows that the tables arewritten (changes), but never read. This is an indication that the business does not require the entries in thesetables.

------------------------------------------------------------------------------------------------------------------------------------------------------System: All servers Not buffered tablesTime frame of analysis : 02 / 2008------------------------------------------------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------------------------------------------------------| Table | ABAP Processor requests | DB activity || | Changes/ | Total | Direct | Seq. | Changes | Calls | Rows || | Total (%) | | reads | reads | | | affected |------------------------------------------------------------------------------------------------------------------------------------------------------| *Total* | | 10324152666 | 9243407,722 | 795,440,205 | 285,304,739 | 3060748,507 | 4322163,011 |------------------------------------------------------------------------------------------------------------------------------------------------------| ACCTCR | 100.00 | 88,003 | 0 | 0 | 88,003 | 88,071 | 8,526,444 || ACCTHD | 100.00 | 88,003 | 0 | 0 | 88,003 | 88,071 | 88,003 || ACCTIT | 100.00 | 88,003 | 0 | 0 | 88,003 | 88,071 | 4,263,222 |

Further confirmations that the tables are not required can be obtained by transaction ST03N. There, yousimply need to check whether the transactions and programs mentioned in OSS note 48009 are in thestatistics.

2.9.2 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 objectdoes not require the definition of residence times. Due to the potentially high data volume, it is recommendedto set up a daily archiving job, using the posting date as a dynamic variable. The selection by posting dateshould on one hand be held for as short a time as possible; but on the other hand, long enough to satisfy thebusiness requirements.



2.10 Table CKMI1

This table is updated for every goods movements carried out in the system. The huge number of entries inthis table leads to performance loss during posting of goods movements that are relevant for valuation.

2.10.1 Avoidance

The updating of this table can be deactivated by implementing note 1158752. For release < 4.6C, apply OSSnote 384757.

------------------------------------------------------------------------------------------------------------------------------------------------------System: All servers Not buffered tablesTime frame of analysis : 03 / 2008------------------------------------------------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------------------------------------------------------| Table | ABAP Processor requests | DB activity || | Changes/ | Total | Direct | Seq. | Changes | Calls | Rows || | Total (%) | | reads | reads | | | affected |------------------------------------------------------------------------------------------------------------------------------------------------------| CKMI1 | 100.00 | 97,145 | 0 | 3 | 97,142 | 98,827 | 2,480,522 |

If the table is not required by the business, the table call statistics in ST10 should be as above.

2.10.2 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 defineresidence time for the table entries. The archiving object allows archiving runs on a monthly basis.



2.11 Tables IDOCREL & SRRELROLES

These tables contain the links between IDocs and application objects. The table entries are not taken intoaccount during the archiving of IDocs via archiving object IDOC and remain in the system although the IDocsno longer exist in the system.

2.11.1 Avoidance

As described in OSS note 574349, links of type IDC4 are created if the partner type “LS” (logical system) isused for the communication between an external non-SAP and an SAP system. These links can cause majorperformance problems during the deletion job with report RSRLDREL and/or RSRLDREL2.


Not possible.

2.11.3 Deletion

Entries are deleted with program RSRLDREL and/or RSRLDREL2 (OSS note 853035). A periodic job shouldbe scheduled to delete the table entries regularly. The scheduling of the deletion job should be synchronizedwith the frequency of the IDoc archiving. For example, if IDocs are archived daily, then the deletion jobshould also be scheduled to run daily, but after the IDoc archiving and deletion jobs have been completed.

Refer to OSS notes 706478, 707820, 505608, and 566765 for further details.

2.11.4 Archiving

Not possible.



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 bedeleted 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 (tableWPLST).

The scheduling of the deletion jobs should be in sync with the IDoc archiving jobs. If a daily archiving job isscheduled to remove correctly posted IDocs older than 7 days, then the deletion jobs for RWPUDLST andRWPUDTST should also run daily to remove the entries related to the archived IDocs only.

2.12.4 Archiving

Not possible.



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. TablesS001 to S499 are SAP standard tables. Tables S500 and above are custom defined tables.

These tables are used primarily for reporting purposes. A few applications require updates to Info-Structures.

ApplicationInfo-Structures Perishables replenishmentS160 Open-To-BuyS110 Subsequent SettlementS015, S074, S111 Rough Workload EstimateS150, S152 Picking WavesS159

In a standard delivery, all info-structures are active by default. As such, it is strongly recommended that allinfo-structures be deactivated at the beginning of a project. This forces project team members to thinkcarefully before they turn on the updating of any info-structures.

2.13.1 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 teammembers are forced to knowingly activate each info-structure whenever a real business requirement arises.

In the case of live customers, the table call statistics (ST10) for all previous months need to be analyzed. Thefollowing table shows that ST10 statistics for info-structures from a live customer.

Period TableABAP/IV Processor requests DB activityChanges/ Total Direct Seq. Changes Calls RowsTotal(%) reads reads affected

03 2008 S003 0 4 0 4 0 6 003 2008 S004 0 4 0 4 0 7 004 2008 S004 0 7 0 7 0 13 005 2008 S004 0 2 0 2 0 4 006 2008 S004 0 1 0 1 0 2 007 2008 S004 0 0 0 0 0 0 008 2008 S004 0 1 0 1 0 2 009 2008 S004 0 0 0 0 0 0 003 2008 S009 50 110.676 55.338 0 55.338 166.257 110.74404 2008 S009 50 301.842 150.921 0 150.921 453.205 301.96605 2008 S009 50 271.520 135.760 0 135.760 407.796 271.66306 2008 S009 50 308.338 154.169 0 154.169 462.916 308.45307 2008 S009 50 332.842 166.421 0 166.421 499.705 332.97108 2008 S009 50 314.816 157.408 0 157.408 472.675 314.94109 2008 S009 50 132.326 66.163 0 66.163 198.688 132.382



03 2008 S011 100 422.087 0 0 422.087 422.691 414.66304 2008 S011 100 1.057.076 0 0 1.057.076 1.058.224 1.045.13605 2008 S011 100 993.760 0 0 993.760 995.219 980.85406 2008 S011 100 993.807 0 0 993.807 995.092 981.48407 2008 S011 100 1.153.063 0 0 1.153.063 1.154.441 1.139.96608 2008 S011 100 979.396 0 0 979.396 980.736 967.24409 2008 S011 100 471.703 0 0 471.703 472.357 464.71303 2008 S012 100 7.074.447 0 0 7.074.447 7.075.134 5.493.21804 2008 S012 100 16.158.095 0 5 16.158.090 16.159.419 12.586.58705 2008 S012 100 15.351.030 0 1 15.351.029 15.352.705 11.687.13006 2008 S012 100 16.146.093 0 1 16.146.092 16.147.595 12.416.64907 2008 S012 100 18.913.429 0 0 18.913.429 18.915.053 14.974.04208 2008 S012 100 16.033.958 0 0 16.033.958 16.035.563 12.813.63009 2008 S012 100 7.488.396 0 0 7.488.396 7.489.126 5.962.16903 2008 S013 63,11 5.388.530 1.987.718 0 3.400.812 7.479.569 3.975.62604 2008 S013 61,83 13.138.688 5.015.042 0 8.123.646 18.426.829 10.030.20505 2008 S013 62,18 15.573.005 5.889.761 0 9.683.244 21.697.212 11.779.58006 2008 S013 61,77 15.040.210 5.749.934 0 9.290.276 21.040.386 11.499.95707 2008 S013 61,3 13.709.293 5.305.617 0 8.403.676 19.305.953 10.611.34408 2008 S013 62,14 11.088.481 4.197.755 0 6.890.726 15.530.702 8.395.55909 2008 S013 62,61 4.964.454 1.856.378 0 3.108.076 6.922.519 3.712.80803 2008 S014 50 112.212 56.106 0 56.106 168.617 112.27804 2008 S014 50 308.236 154.118 0 154.118 462.901 308.35805 2008 S014 50 275.072 137.536 0 137.536 413.264 275.21706 2008 S014 50 312.866 156.433 0 156.433 469.805 312.97707 2008 S014 50 337.910 168.955 0 168.955 507.430 338.04108 2008 S014 50 318.678 159.339 0 159.339 478.577 318.80209 2008 S014 50 133.796 66.898 0 66.898 200.948 133.85303 2008 S021 0 4 0 4 0 7 003 2008 S031 100 9.067.137 0 3 9.067.134 9.067.518 5.278.81404 2008 S031 100 29.684.377 0 12 29.684.365 29.685.144 17.166.23005 2008 S031 100 24.219.918 0 10 24.219.908 24.220.860 14.179.37306 2008 S031 100 27.740.044 0 11 27.740.033 27.740.929 16.041.11607 2008 S031 100 31.388.493 0 21 31.388.472 31.389.477 18.173.22308 2008 S031 100 27.404.836 0 15 27.404.821 27.405.712 15.702.63509 2008 S031 100 13.475.195 0 0 13.475.195 13.475.622 7.654.84403 2008 S032 100 16.404.510 0 6 16.404.504 16.405.508 15.399.01104 2008 S032 99,99 52.518.168 0 3.550 52.514.618 52.520.803 49.092.46205 2008 S032 100 43.619.090 0 13 43.619.077 43.621.844 41.164.54406 2008 S032 100 51.409.140 0 12 51.409.128 51.411.810 46.828.31707 2008 S032 100 54.994.160 0 63 54.994.097 55.006.528 54.838.65008 2008 S032 100 47.550.964 0 16 47.550.948 47.553.610 45.330.44209 2008 S032 100 22.895.361 0 0 22.895.361 22.896.421 21.684.86903 2008 S033 100 5.278.718 0 0 5.278.718 5.278.911 5.278.81704 2008 S033 100 17.165.948 0 0 17.165.948 17.166.414 17.166.23305 2008 S033 100 14.178.504 0 0 14.178.504 14.179.026 14.178.79406 2008 S033 100 16.037.407 0 0 16.037.407 16.037.889 16.037.68507 2008 S033 100 18.172.898 0 0 18.172.898 18.173.463 18.173.22608 2008 S033 100 15.702.380 0 0 15.702.380 15.702.870 15.702.65709 2008 S033 100 7.654.695 0 0 7.654.695 7.654.949 7.654.84303 2008 S034 100 98.832 0 0 98.832 99.014 95.26204 2008 S034 100 288.024 0 0 288.024 288.354 278.603



05 2008 S034 100 374.404 0 0 374.404 374.810 365.39406 2008 S034 100 258.465 0 0 258.465 258.811 249.45707 2008 S034 100 329.052 0 0 329.052 329.418 319.17608 2008 S034 100 292.450 0 0 292.450 292.854 281.85209 2008 S034 100 119.955 0 0 119.955 120.137 115.15503 2008 S035 100 13.222 0 0 13.222 13.384 11.10504 2008 S035 100 41.472 0 0 41.472 41.778 35.14505 2008 S035 100 39.533 0 0 39.533 39.908 34.57206 2008 S035 100 38.717 0 0 38.717 39.040 33.26107 2008 S035 100 46.222 0 0 46.222 46.562 40.35908 2008 S035 100 44.816 0 0 44.816 45.188 37.74309 2008 S035 100 19.464 0 0 19.464 19.640 17.15703 2008 S039 0 4 0 4 0 8 004 2008 S039 0 2 0 2 0 4 005 2008 S039 0 3 0 3 0 6 006 2008 S039 0 0 0 0 0 0 007 2008 S039 0 5 0 5 0 9 008 2008 S039 42,86 7 0 4 3 13 1209 2008 S039 0 0 0 0 0 0 003 2008 S061 100 249 0 0 249 281 24604 2008 S061 100 1.987 0 0 1.987 2.076 1.97605 2008 S061 100 2.204 0 0 2.204 2.296 2.19306 2008 S061 100 2.324 0 0 2.324 2.407 2.31507 2008 S061 100 1.848 0 0 1.848 1.948 1.83408 2008 S061 100 1.813 0 0 1.813 1.907 1.80409 2008 S061 100 825 0 0 825 887 81703 2008 S062 100 248 0 0 248 302 27004 2008 S062 100 1.961 0 0 1.961 2.111 2.03305 2008 S062 100 2.189 0 0 2.189 2.352 2.26406 2008 S062 100 2.304 0 0 2.304 2.453 2.37507 2008 S062 100 1.834 0 0 1.834 2.000 1.91208 2008 S062 100 1.801 0 0 1.801 1.967 1.88009 2008 S062 100 818 0 0 818 920 86703 2008 S066 0 12 0 12 0 26 008 2008 S066 0 1 0 1 0 3 003 2008 S067 0 12 0 12 0 19 008 2008 S067 0 1 0 1 0 2 004 2008 S071 0 1 0 1 0 2 005 2008 S071 0 0 0 0 0 0 008 2008 S091 0 0 0 0 0 0 003 2008 S111 100 212 0 0 212 271 2.66304 2008 S111 100 183 0 0 183 220 1.94005 2008 S111 100 70 0 0 70 96 50306 2008 S111 100 157 0 0 157 190 1.39007 2008 S111 100 211 0 0 211 258 5.10308 2008 S111 100 124 0 0 124 162 1.43509 2008 S111 100 69 0 0 69 89 52003 2008 S123 100 318.975 0 0 318.975 319.266 311.89404 2008 S123 100 918.040 0 0 918.040 918.608 902.43505 2008 S123 100 846.579 0 0 846.579 847.216 830.72906 2008 S123 100 918.570 0 0 918.570 919.079 901.35307 2008 S123 100 953.979 0 0 953.979 954.552 936.196



08 2008 S123 100 921.387 0 0 921.387 921.948 903.15809 2008 S123 100 404.009 0 0 404.009 404.255 392.15403 2008 S124 100 3.120.258 0 0 3.120.258 3.120.608 2.170.23204 2008 S124 100 9.045.350 0 0 9.045.350 9.046.031 6.320.45405 2008 S124 100 8.869.718 0 0 8.869.718 8.870.503 6.100.25206 2008 S124 100 10.119.952 0 0 10.119.952 10.120.572 6.993.21607 2008 S124 100 10.720.966 0 0 10.720.966 10.721.719 7.523.48708 2008 S124 100 10.587.379 0 0 10.587.379 10.588.071 7.359.72409 2008 S124 100 4.658.581 0 0 4.658.581 4.658.873 3.141.77803 2008 S135 0 1 0 1 0 3 004 2008 S135 50 20 0 10 10 31 1405 2008 S135 0 2 0 2 0 3 006 2008 S135 0 1 0 1 0 2 007 2008 S135 58,82 17 0 7 10 23 1008 2008 S135 0 0 0 0 0 0 003 2008 S999 100 8.594.709 0 0 8.594.709 8.595.096 5.249.66504 2008 S999 100 28.996.466 0 0 28.996.466 28.997.246 17.206.04405 2008 S999 100 22.848.597 0 0 22.848.597 22.849.531 14.109.76606 2008 S999 100 26.300.363 0 0 26.300.363 26.301.211 15.963.57707 2008 S999 100 30.371.134 0 0 30.371.134 30.372.140 18.225.92008 2008 S999 100 25.828.656 0 0 25.828.656 25.829.529 15.649.53709 2008 S999 100 13.084.692 0 0 13.084.692 13.085.126 7.672.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 areempty, it is an indication that the info-structures are not used by the business for reporting.

Nevertheless, the business needs to provide the necessary information of the reporting requirements.


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 generatedvia transaction MCSX. The generated archiving objects are MC_Sxxx, where Sxxx is the info-structurename.

Use transaction SARA to schedule archiving jobs for the archiving objects MC_Sxxx.



2.14 Application logs (BALHDR, BALDAT)

Additional warnings and error messages arising from the applications may be written when posting salesIDocs. These messages are stored in tables BALHDR and BALDAT.

2.14.1 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 themajority of the logs normally have the expiry date 31.12.9999.

In the selection variant, it is recommended to set up the fields “creation date: from” and “creation date: to” asdynamic variables, as shown in the example below.

Create a secondary index on table BALHDR with fields MANDANT, ALDATE.

Due to the potentially high volume of application logs, we recommend that you schedule a daily deletion job.

2.14.4 Archiving

If the business requires application logs to be archived, instead of simply deleted, the archiving objectBC_SBAL should be used.

This archiving object does not require the set up of residence times for application logs in the customizing ofthis object. The creation dates (from/to) should be set up as dynamic variables



Create a secondary index on table BALHDR with fields MANDANT, ALDATE.

Schedule a daily archiving job.



2.15 Work Items (SWWWI* tables)

As from release 4.6C, all links between IDocs and application data are held in tables IDOCREL andSRRELROLES. Work items are no longer used for this purpose. However, this does not prevent theapplications generating work items when problems occur during the creation of the application data.

2.15.1 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 adynamic variable.



Depending on the volume of work items generated per day, it may be necessary to schedule a daily deletionjob.

2.15.4 Archiving

If the business requires work items to be archived, instead of deleted, the archiving object WORKITEMshould be used.

Archiving object WORKITEM does not require the setup of residence times for work items. It isrecommended to set up the fields “Creation Date” and “End Date” as dynamic variables.



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 ineffectivebecause the work item statuses were never set to “completed” and/or “cancelled”.



3 Store Replenishment Cycle

The above figure shows the typical store replenishment cycle. The cycle begins with the POS Inboundprocess in which sales data is processed and stock levels are updated. Next, the replenishmentplanning/calculation are carried out. This results in purchase requisitions and/or purchase orders beingcreated.

There are 2 types of purchase orders – stock transfer orders and purchase orders. While stock transferorders are fulfilled by the warehouses, purchase orders are sent to the external vendors. Next, outbounddeliveries are created with reference to the stock transfer orders. These outbound deliveries are necessaryto inform the warehouse(s) of the requirements of each individual store. Depending on the configuration ofthe process, transport orders can be created for the goods movements within the warehouse(s) – picking andmoving the goods to the shipping point(s). The usage of Handling Units is not considered in this simplescenario.

Once the goods have been picked and moved to the shipping point, warehouse goods issues are posted.This will reduce the stock levels at the warehouse(s). Finally, when the goods arrive at the stores, storegoods receipts are posted. Store goods receipts are posted with reference to the stock transfer orders andpurchase orders.


Store Replenishment Cycle

POSUpload

StoreReplenishmentPlanning

Createoutbounddeliveries

Create transportorders (optional)

Postwarehousegoods issues

Post storegoodsreceipts



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. Thereason for this is that the handling of these documents is similar or identical to the case “POS Inbound”.


Store Replenishment Cycle – Documents & Table Entries

POSUpload

StoreReplenishmentPlanning

Createoutbounddeliver ies

Create transpor torders (optional)

Post warehousegoods issues

Post storegoodsreceipts

IDocs: EDIDC, EDI40, EDIDSArticle doc.: MKPF, MSEGBilling doc.: VBRK, VBRPFI-doc.: BKPF, RFBLG, FAGLFLEXA, FAGL_SPLINFO, FAGL_SPLINFO_VAL

BSIS, BSASCO-doc.: COBK, COEPPCA-doc.: GLPCAACCT*-TablesLinks between IDocs and applications: SRRELROLES, IDOCRELWorkitems: SWWWIHEAD, ....Application logs: BALHDR, BALDATInfo-Structures (Sxxx)

Purchase requisitions: EBANPurchase orders: EKKO, EKPOChange documents: CDHDR, CDCLSApplication logs: BALHDR, BALDATInfo-Structures (Sxxx)

Outbound Deliveries: LIKP, LIKPSChange documents: CDHDR, CDCLSApplication logs: BALHDR, BALDATInfo-Structures (Sxxx)

Transport orders: LTAK, LTAPChange documents: CDHDR, CDCLSApplication logs: BALHDR, BALDATInfo-Structures (Sxxx)

Article doc.: MKPF, MSEGFI-doc.: BKPF, RFBLG, FAGLFLEXA

FAGL_SPLINFO, FAGL_SPLINFO_VALBSIS, BSAS

Change doc.: CDHDR, CDCLSApplication Logs: BALHDR, BALDATACCT*-tablesInfo-Structures (Sxxx)

Article doc.: MKPF, MSEGFI-doc.: BKPF, RFBLG, FAGLFLEXA

FAGL_SPLINFO, FAGL_SPLINFO_VALBSIS, BSAS

Change doc.: CDHDR, CDCLSApplication Logs: BALHDR, BALDATACCT*-tablesInfo-Structures (Sxxx)



3.1 Purchase Requisitions (EBAN)

Store replenishment planning can result in purchase requisitions being created. It depends strongly on thesetup of the replenishment process.

3.1.1 Avoidance

If transaction WRP1 is used for the store replenishment, purchase requisitions can be avoided through thecustomizing of the “Store Order”.

/NSPRO F5 Materials Management Consumption-based Planning Replenishment 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.



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 “SetRequisitions to Closed” should be set to “2”.

Purchase requisitions are automatically closed when the generation of purchase orders has been successful.This setting is beneficial for the archiving of purchase requisitions because a prerequisite for archiving objectMM_EBAN is that the purchase requisitions must be closed. Open purchase requisitions are not archived.

Archiving object MM_EBAN requires residence time for each purchase requisition type to be defined in thecustomizing of the object.



The values 10 and 20 in residence time 1 and 2 are default values and should be changed to meet businessrequirements.

It is recommended that the “one-step procedure” be used. This means that only residence time 1 is requiredand residence time 2 can be set to 0.

The difference between the one-step and two-step procedures is as follows:

In the one-step procedure, the system sets the deletion flags for completed and closed purchase requisitionsand archives them if the residence time 1 is fulfilled.

In the two-step procedure, the system sets the deletion indicator for completed and closed purchaserequisitions when residence time 1 is fulfilled. It does not archive the purchase requisitions immediately.These are archived in the next archiving run if the residence time 2 is fulfilled.

3.2 Purchase Orders (EKKO, EKPO)

Store replenishment results in stock transfer orders and purchase orders. Stock transfer orders are fulfilledby the warehouses while purchase orders (or vendor orders) are fulfilled by external vendors.

3.2.1 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 valueof all residence times is 30 days, as shown in the example below.



The meaning of residence time 1 and residence time 2 is identical to those in archiving object MM_EBAN forpurchase requisitions. Again, it is recommended to use the one-step procedure to archive stock transferorders and purchase orders.

The SAP standard order type for stock transfer order is “UB”, while the standard order type for vendor order is“NB”. The residence times for UB should be shorter than those for NB. Normally, UBs are fulfilled by thewarehouses within a period of about a week. As such, it is sufficient to keep stock transfer orders online for amonth.

In the case of purchase orders to vendors, the residence times depend strongly on the business processesdefined. If for example, subsequent settlement is used and the rebate agreements with vendors are valid forone year, many customers would like to keep the purchase orders until the final rebate settlement iscompleted. However, the purchase orders are not required for the rebate settlement. These purchase ordersare only required to build the statistics relevant for the rebate settlement in table S111. This situation onlyoccurs when a rebate agreement with a vendor is created in the later part of the year, but the validity of theagreement has to be back-dated to the beginning of the year.

Therefore, it is strongly recommended that the rebate agreements be created as early in the year as possibleto prevent the archiving backlog for purchase orders from becoming too large.

The following example shows a variant of archiving object MM_EKKO for archiving stock transfer orders.This variant will pick up all orders with order type UB and document dates less than or equal to current dateminus 35 days.



The “Key Date for Quotation Date” field is ignored when archiving purchase orders because this is relevantonly for quotations.

It is recommended that a daily archiving job be scheduled for archiving stock transfer orders. In the case ofvendor orders, it may be necessary to schedule a daily archiving job if the volumes are high. Otherwise, aweekly job should be sufficient.



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 andprice 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 # EntriesCOND_A 83.392.799ADRESSE 6.815.547MAT_FULL 4.676.681EINKBELEG 4.117.305LIEFERUNG 3.923.894VERKBELEG 3.166.077BANF 2.602.251BELEG 2.315.976INFOSATZ 1.790.371ANLA 1.664.961BELEGR 1.189.519WLK1 1.154.827TRANSPORT 689.253MATERIAL 606.602ORDERBUCH 453.824DEBI 371.996HANDL_UNIT 256.326KRED 203.982SACH 137.016ASMODULE 49.347PFCG 24.829BETRIEB 22.383FAKTBELEG 16.219SETS 13.270KOSTL 11.932BANK 10.744ADRESSE3 8.361PRCTR 4.949WREFA 4.268BELEGD 3.173KLASSE 1.715STUE 893STUE_V 892NRINTERVAL 576WBASISWG 499KSTAR 496ALLOCATION 250PROJ 240BELEGV 223INCOMINGINVOICE 66



EQUI 57FEATURE 30RKAUFTRAG 6CMDT_PC 5MELDUNG 5CHARGE 3NRKROBJ 3LSTAR 2LAYOUT_MOD 1PROJS 1

While most of the change documents cannot be avoided during normal operations, change documents due toarticle listing (OBJECTCLAS = WLK1, ASMODULE, WBASISWG, LAYMOD) can be avoided if the listing iscarried out via transaction WSM3 or WSM8. The selection screens of these 2 transactions have the optionfor suppressing the generation of change documents. The following diagram shows the selection screen oftransaction WSM3.

During an initial data load from legacy system to SAP, it is strongly recommended that change documents beavoided. However, this requires minor modifications to certain ABAP programs. Contact SAP for furtherdetails since these modifications are not part of standard delivery.

3.3.2 Summarization

Not possible.

3.3.3 Deletion

Report RWSORT54 is used for deleting change documents due to listing (OBJECTCLAS = WLK1,ASMODULE, WBASISWG, LAYMOD).



Program RSCDOK99 can be used for deleting all change documents.

3.3.4 ArchivingChange documents are normally archived whenever archiving runs are carried out for the main documentssuch as purchase requisitions, purchase order, deliveries, and so on. In certain business cases, it may benecessary to use archiving object CHANGEDOCU to archive change documents only (exampleOBJECTCLAS MAT_FULL).

The archiving object CHANGEDOCU does not require the set up of residence times for change documents inthe customizing of the archiving object. The following example shows the variant for archiving changedocuments with OBJECTCLAS = COND_A that are older than 30 days.



Depending on the volume, it may be necessary to schedule a daily archiving run for change documents.



3.4 Outbound Deliveries (LIKP, LIPS)

Outbound deliveries are created with reference to stock transfer orders. These are purchase orders forstores that are fulfilled by the warehouse.

3.4.1 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 typeshave to be set up in the customizing of the archiving object.

The pre-processing step of this archiving object sets the deletion indicator for deliveries that are completedand can be archived. The selection screen has the option to use the date of last change for the checking ofthe residence time.

This option is also available in the archiving WRITE-program.

Note that deliveries can only be archived when there are no billing documents and transport orders assignedto them. If there are transport orders and billing documents assigned, these documents have to be archivedfirst. Further, if handling units are used in the business process, the handling units must be archived beforethe transport orders.



3.5 Transport Orders (LTAK, LTAP)Transport orders are created with reference to the outbound deliveries. These are required for the pickingand packing of the goods to be shipped to the stores.

3.5.1 Avoidance

This depends strongly on the set up of the business process. In the case where an external warehousemanagement system is used, transport orders are optional.

3.5.2 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. Allcompleted and closed transport orders are considered by the archiving object. The residence time must onlybe specified in the variant of the WRITE-program.

The diagram above shows the selection screen of the WRITE-program for archiving object RL_TA. Theresidence time of 200 days is the system default value and must be changed to meet business requirements.

Note that transport orders cannot be archived if related handling units still exist in the system. The handlingunits must be archived first.



4 Warehouse Replenishment Cycle

The warehouse replenishment cycle begins with a weekly or daily forecast. Each forecast run creates a newversion of the forecast data to be used later for the calculations of the requirements at each warehouse.

The calculations of the requirements of the warehouses result in purchase requisitions being created. Thesepurchase requisitions are checked and released by the purchasing department members. After they arereleased, the purchase requisitions are “converted” to purchase orders. The term “conversion” does notliterally mean converting a purchase requisition to a purchase order. It simply means that purchase ordersare created with reference to the purchase requisitions. The “conversion” is done via transaction ME59.

The purchase orders are then sent to external vendors, either via fax or, in the case of EDI vendors, throughIDocs. When the vendors deliver the goods to the warehouses, warehouse goods receipts are posted. Theposting is carried out with reference to the purchase orders. Finally, invoice verification is carried out toensure that the goods and quantities received match the information in the purchase orders. After that,payments are made to the vendors.

SAP AG 2007, Data Archiving In SAP Retail / Robert Peebles / 35

Warehouse Replenishment Cycle

Forecast(optional)

MaterialRequirementPlanning (MRP)

+ Pur. Req.

ConvertPurchaseRequisitionsto PurchaseOrders

Send Order tovendors

Postwarehousegoodsreceipts

InvoiceVerification& Payment



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 replenishmentwithout the use of forecast data, it is normally the case in all projects that forecast data is used for thereplenishment.

It is recommended that forecast should not be carried out for all article/site combinations on a daily basis. Inmost cases, a weekly forecast is sufficient to satisfy the business requirements. Each forecast run creates anew version of the forecast data.

4.1.2 Summarization

Not possible.


Warehouse Replenishment Cycle – documents created

Forecastdata

Purchase requisitionsChange documentsApplication logsInfo-Structures

Purchase OrdersChange documentsApplication logsInfo-Structures

IDocs

Article documentsFI-documentsCO-documentsPCA-documentsChange documentsApplication logsInfo-Structures

Vendor invoicesFI-documentsCO-documentsPCA-documentsChange documentsApplication logsInfo-Structures



4.1.3 Deletion

Old forecast data should be deleted regularly. The frequency of the deletion job should be in sync with thefrequency in which forecast is carried out. If for example forecast is carried out weekly, the deletion jobshould also run on a weekly basis. The deletion should be carried out before the forecast run.

Report RMCPMLOE can be used to delete old forecast data. However, it does not delete entries in tablePRON. Therefore, it is better to use program RMPR2001 instead. The following diagram shows an exampleof a variant of report RMPR2001.

The above example is used for deleting all forecast data for all sites (stores and warehouses) on a weeklybasis. However, the latest version of the forecast data for each article/site combination is left untouched(“Delete all versions” = BLANK).

The field “Deletion forecast model 0 only” means that only article/site combinations for which forecast is nolonger required (forecast model 0) are deleted.

The field “Display deletion log” should be avoided as this has an impact on the runtime of the deletion job. Ifthis field is not flagged, the system will only show the total number of entries deleted from each table.Otherwise, the number of entries for each article/site combination will be displayed.

4.1.4 Archiving

Not possible.



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 thedefinition of residence times for the different vendor billing types in the customizing of the archiving object.

The following diagram shows a variant for the WRITE-program of the archiving object.



In the above example, all billing types for company code PS01 are taken into consideration if their postingdates are older than or equal to the current date minus 180 days.



5 Customer (Sales) Orders

The figure shows the typical process chain in a customer ordering scenario. It is based on the assumptionthat these customer orders or sales orders are fulfilled by the warehouse.

Sales orders are created either via transaction VA01, or through IDocs. Next, with reference to these salesorders, outbound deliveries via transaction VL10c are generated. For the picking of the goods at thewarehouse, transport orders are created for each outbound delivery. Next, billing documents need to begenerated. These billing documents need to accompany the shipping documents included in the deliveries.Finally, when the goods leave the warehouse, warehouse goods issues are posted.

SAP AG 2007, Data Archiving In SAP Retail / Robert Peebles / 37

Customer (Sales) Orders

CreateSales Orders

CreateOutboundDeliveries

CreateTransportOrders

CreateBillingDocuments

PostWarehouseGoodsIssues



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.


Customer (Sales) Orders – document types

Sales OrdersChange documentsApplication logsInfo-Structures

OutboundDeliveriesChangedocumentsApplication logsInfo-Structures

TransportOrdersChangedocumentsApplicationlogsInfo-Structures

BillingDocumentsApplication logsInfo-Structures

ArticledocumentsFI-documentsCO-documentsPCA-documentsChangedocumentsApplication logsACCT*-tablesInfo-Structures



5.1.4 Archiving

Sales orders are archived using archiving object SD_VBAK. Residence times have to be defined for eachsales 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 timeIf this field is flagged, the calculation of the residence time is based on the date of last changeand no longer on the creation date.



b. Check Flow Documents ResidenceIf this field is flagged, the calculation of the residence time is based on the creation or changedate of the last document in the document-flow.

c. Check purchase orderIf this field is flagged, the system will check whether purchase order and the correspondingpurchase requisition still exist on the system.

d. Check FI-documentIf this field is set, the system will check whether all accounting documents belonging to a salesorder have been balanced.

Note that flagging additional options (b), (c), and/or (d) will increase the runtime of the archiving job.



6 POS Download / Assortment List

The POS download and assortment list are 2 ways of sending article information, promotion information, andprices from the headquarters down to the stores.

Normally, one either uses POS download or the assortment list. However, there are some customers whouse both POS download and the assortment list. In these cases, the assortment list is used for specificarticles only, due to usage of SAP Retail Store functionalities, and the POS download is used for sending thearticle/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 businessprocesses 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 theassortment 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 maintenancePrice maintenancePromotion

Create outgoingIDocsCreate assortmentlists

Send IDocs to stores



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 thecreation of change pointers. The change pointers are necessary for the creation of the outgoing IDocs in thePOS 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 aredeactivated/activated for specific message types.


POS Download / Assortment List – documents created

Change documentsChange pointers

IDocsAssortment list IDoc status entries





For certain message types, it is possible to switch the storage of the change pointers from table BDCP andBDCPS 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.



/NSPRO Sales and Distribution POS Interface Outbound Controlling Alternative ConditionChange Analyses Using Worklist Direct Entry for Creating Worklist Activation of the Direct Entry forCreating the Worklist

Here, the direct entry in the wordlist for document adjustment following condition changes (table WIND) fordocument category 55 (POS Outbound) is set. In the case of the assortment list, document category 50 isused.

Once the indicator is set, price changes with will be written into a worklist in table WIND, instead of thechange 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 theassortment 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 theoption of deleting “processed” change pointers. However, change pointers are not set to “processed” duringthe 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.



The fields for date have been set up as dynamic variables. In the case of obsolete change pointers, it hasbeen 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. Thismeans 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 forreport RBDCPCLR.



Running a daily reorganization and deletion job helps in preventing performance degradation of the POSdownload / 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, werecommend 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 allassortment list types, except for assortment list type “D”.



See also OSS note 863078.

In the case where the HPR version of the assortment list is used, WIND entries can be automatically deletedwhen creating a “change version” of the assortment list.

6.2.4 Archiving

Not possible.



© 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 theexpress 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 ofother 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, Systemz10, 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 ofAdobe 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 orregistered trademarks of Citrix Systems, Inc.HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide WebConsortium, 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 inventedand implemented by Netscape.SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP productsand services mentioned herein as well as their respective logos are trademarks or registered trademarks ofSAP AG in Germany and other countries.Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, WebIntelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as theirrespective logos are trademarks or registered trademarks of Business Objects S.A. in the United States andin other countries. Business Objects is an SAP company.All other product and service names mentioned are the trademarks of their respective companies. Datacontained 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 itsaffiliated companies ("SAP Group") for informational purposes only, without representation or warranty of anykind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The onlywarranties for SAP Group products and services are those that are set forth in the express warrantystatements accompanying such products and services, if any. Nothing herein should be construed asconstituting an additional warrant.