Data Archiving in Sales and Distribution

Data Archiving in Sales and Distribution (SD)
Data archiving is used to remove mass data from the database that is no longer required in the
system but must be kept in a format that can be analyzed. For most of the archiving objects, the SAP
data archiving concept is based on the Archive Development Kit (ADK).
For more information, see the SAP NetWeaver Library on SAP Help Portal at http://help.sap.com/nw
. Choose SAP NetWeaver Platform Application Help Function-Oriented View Solution Life Cycle
Management Data Archiving.
For more information about which archiving objects in Sales and Distribution (SD) are enabled for
ILM, see the documentation for the relevant archiving objects.
For more information about managing and destroying archived data, search for SAP Information
Lifecycle Management.
The following table shows the available archiving objects:
Objects in Sales and Distribution Archiving object
Sales documents SD_VBAK
Billing documents SD_VBRK
Sales activities SD_VBKA
Agreements and associated conditions SD_AGREEM
Conditions SD_COND
Revenue recognition data SD_VBREV
INTRASTAT statistics data FT_VEIAV
EXTRASTAT statistics data FT_VEXAV
Customs log data MM_PREF
Customer master data FI_ACCRECV
Pendulum List Indirect Sales

Request data /BEV4/PL01
Converted request table with declaration period /BEV4/PL02
Request table with declaration period /BEV4/PL03
Logs sales pendulum list /BEV4/PL04
Empties Management
Archiving monthly empties stock BEV1_EMBD
Archiving empties update BEV1_EMFD
Business Partner End of Purpose (EoP) Check in Sales and Distribution
Use
Sales and Distribution provides an (EoP) check to determine whether customer, vendor/supplier, and
contact person data is still relevant for business activities in the application or can be blocked.
In addition to the end of purpose, data archiving is required to securely block customer or
vendor/supplier related sales data from being displayed to business users.
Application Name Application Business Partner Type

Description
ERP_SD Sales & Distribution Customer, vendor/supplier, and contact person
Prerequisites
You have activated the business function ILM-Based Deletion of Customer and Supplier Master
Data (ERP_CVP_ILM_1).
Technical Details
ILM Objects
The EoP check evaluates retention policies and data for the following ILM objects:
 SD_AGREEM (Rebate agreements and associated conditions)

 RV_LIKP (Deliveries)
 SD_VBAK (Sales documents)
 SD_VBRK (Billing documents)
 SD_VBKA (Contacts)
EoP Check Implementation
Sales and Distribution provides the following functionality for the EoP check of the customer,
vendor/supplier, and contact person:
 The application searches for the following data with relation to business partners:
 Agreements of various types (KONA)
 Deliveries (LIKP and VBPA)
 Sales documents (VBAK and VBPA)
 Sales activities (VBKA and VBPA)
 Billing documents (VBRK and VBPA)
 One-time customers (that is, a CpD customer)
 The following table explains when end of business is reached:
Area End of Business Determination
Agreements The final settlement of the agreement (table KONA) is already carried
out and the rebate agreement is for sales, promotion, sales deals, or
purchasing.
Delivery The delivery (table LIKP) is completely processed or not relevant.
Sales The sales document (table VBAK) is completely processed or not

relevant.
Sales Activities The sales activity (table VBKA) is completely processed or not relevant.
Billing The billing document (table VBRK) is completely processed or not

relevant and the SD document is a pro forma invoice.
One-time The business transaction-specific address can be blocked (that is, the
customers business transaction finished and the residence period already ended).
 The application returns the following time reference that represents the end of business date
to the EoP check as Start of Retention Time (SoRT). The following table explains start of
retention by area:
Area Start of Retention
Agreements The creation date of the agreement or condition (table KONA;

field ERDAT)
Delivery Creation date of delivery document header or item

(tables LIKP and LIPS; field ERDAT)
Sales Creation or change date of sales document header or item

(tables VBAK and VBAP; field ERDAT)
Sales Activities Creation date of sales activity (table VBKA; field ERDAT)
Billing Billing date (field VBRK-FKDAT)
One-time End of residence for partner

customers
 This EoP check supports the use of application rule variants based on ILM rule groups: If you
want to define differing residence and retention periods for business partner data depending
on application-specific condition fields, you can define application rule variants in
Customizing for Logistics - General under Business Partner Deletion of Customer and
Supplier Master Data Assign Application Rule Variants and Rule Groups for EoP Check.
In this Customizing activity, you assign the application rule variants to ILM rule groups that you have
created in transaction IRM_CUST_CSS (Information Retention Manager - Calling Customer-Specific
Settings). To determine the retention rules, the ILM rule groups must also be entered in the
corresponding retention rules for the ILM objects in transaction IRMPOL (ILM Policies).
 You execute the rebuild of retention information in Customizing under Sales and
Distribution Data Transfer, Data Aging, and Archiving Data Rebuilding of Retention
Information in SD.
You use this Customizing if you activated business function ILM-Based Deletion of Customer and
Supplier Master Data (ERP_CVP_ILM_1) after you already created business transactions.
 You can enhance the EoP check in Customizing under Sales and Distribution System
Modifications Business Add-In BAdI: Enhancements for End of Purpose Check.
 This EoP check calculates the end of residence time (representing the EoP) based on
residence periods maintained for ILM objects FI_ACCRECV, FI_ACCPAYB,
and FI_ACCKNVK that are active for audit area BUPA_DP for the application name ERP_SD
and the existing rule variants.
 ERP_SD uses transparent table CVP_SD_SORT to collect Start of Retention Time (SoRT)
information upfront.
Initial Load Reports
This EoP check offers an initial load report as shown in the following table:
Report Name Use To Be Affected Data

Used
When
CVP_SD_EOP_INDEX_REBUILD Use this report to initially This This report reads data
fill table CVP_SD_SORT with report from the database
EoP-relevant data for can be and writes it to
already existing partners used transparent
and their business only table CVP_SD_SORT.
transactions. once.
Handling of Archived Data
The application does not consider archived data.
Business Partner End of Purpose (EoP) Check in SAP Revenue Accounting and Reporting, Integration
for Sales and Distribution
Use
SAP Revenue Accounting and Reporting, integration for sales and distribution provides an end of
purpose (EoP) check to determine whether customer data is still relevant for business activities in the
application or can be blocked.
Application Application Description Business Partner

Name Type
ERP_SD_BIL_RA SD Integration for Revenue Accounting and Customer

Reporting
Prerequisites
 You have activated the business function ILM-Based Deletion of Customer and Vendor/
Supplier Master Data (ERP_CVP_ILM_1) in your SAP Sales and Distribution system.
 You have activated the business function Simplified Deletion and Blocking (FARR_SDB) in
your SAP Revenue Accounting and Reporting system.
 In order to perform EoP checks and blocking in SAP ERP, you need the authorization to create
revenue accounting items (RAIs) in SAP Revenue Accounting and Reporting.
 For other prerequisites in your SAP Revenue Accounting and Reporting system, refer to SAP
Note 2812171 .
Technical Details
EoP Check Implementation
SAP Revenue Accounting and Reporting, integration for sales and distribution provides the following
functionality for the EoP check of the customer:
 The application searches for revenue accounting items (RAIs), contracts, and performance
obligations (POBs) with relation to business partners.
 The end of business is reached when either of the following conditions applies:
 For active accounting principle/company code combinations (that is, with no End
Date of Usage or with End Date of Usage in the future) the following conditions
apply:
 All RAIs with relation to a specific customer must be in status processed.
 All contracts with relation to a specific customer both directly and via
performance obligations (POBs) must be in status Completed, and the
corresponding reconciliation keys must be in
status Closed (C), Migrated (M), or Replaced (R).
 There are only inactive accounting principle/company code combinations (that is,
with an End Date of Usage in the past or today) with a contract relating to a specific
customer.
 The application returns the later of the following dates as Start of Retention Time (SoRT):
 Latest contract completion date for active accounting principle/company code

combinations
 End Date of Usage for inactive accounting principle/company code combinations
 The EoP check for SAP Revenue Accounting and Reporting, integration for sales and
distribution does not support the use of application rule variants.
 The EoP check for SAP Revenue Accounting and Reporting, integration for sales and
distribution calculates the end of residence time (representing the EoP) based on residence
periods maintained for ILM object FI_ACCRECV that is active for audit area BUPA_DP for the
application name ERP_SD_BIL_RA in your SAP Sales and Distribution system.
Note
After blocking a business partner, the application sets blocking indicators for the corresponding RAIs,
contracts, and POBs.
Initial Load Reports
The EoP check for SAP Revenue Accounting and Reporting, integration for sales and
distribution offers the initial load report CVP_SD_RAR_BLOCK_SYNC in your SAP Sales and
Distribution system. You can use this report to synchronize blocking indicators between customer
and revenue accounting data. For more information, see 2808918 .
Handling of Archived Data
SAP Revenue Accounting and Reporting, integration for sales and distribution considers archived data
for the EoP check of business partners in the following way:
 The application collects SoRT information with relation to business partners during the
archiving runs of archiving object FARR_CONTR in your SAP Revenue Accounting and
Reporting system.
 You can use the initial SoRT retrieval report FARR_DPP_EOP_MIG in your SAP Revenue
Accounting and Reporting system to also consider data for the EoP check that was archived
before business function FARR_SDB has been activated.
Analysis
You can use report FARR_DPP_EOP_SIM_CUSTOMER in your SAP Revenue Accounting and Reporting
system in case a customer cannot be blocked in the sender component/system, although the end of
purpose (EoP) has been reached in the sender component. If the SAP Revenue Accounting and
Reporting, integration for sales and distribution prevents blocking because there are still business
transactions that are not completed or in residence period in SAP Revenue Accounting and
Reporting, this program can help you to analyze why.
See Also
 https://help.sap.com/viewer/product/SAP_ERP SAP Library SAP ERP Cross-Application

Functions Cross-Application Components SAP Information Lifecycle Management
 https://help.sap.com/viewer/product/SAP_ERP SAP Library SAP ERP Cross-Application

Functions Cross-Application Components Data Protection
 SAP Note 2798400
 Customizing for Cross-Application Components under Data Protection
Application-Specific Features (SD)
You can specify which document types are to be archived for the Sales and Distribution component.
The following objects are archived with the documents:
 Texts
 Change documents
 Condition records
The following objects are deleted from the database:
 Matchcodes
 Indices
 Table contents
For additional information on archiving in the Sales and Distribution component, call up Customizing:
1. Call up transaction SPRO and display the SAP Reference IMG.

2. Choose Sales and Distribution Data Transfer, Data Aging, and Archiving Archiving
Data Archiving Control for Sales Documents.
3. Choose Archiving control for sales documents.
Dependencies (SD)
You can archive data in the Sales and Distribution component independently of other application
areas. Before archiving, the system checks whether the Sales and Distribution data is used elsewhere
in the system. If so, a dependency exists and the data cannot be archived.
For example, before archiving a customer master, the system automatically checks whether the
customer master is contained in a customer hierarchy or whether documents still exist for it in Sales
and Distribution or Financial Accounting. If so, the customer master is not archived.
Change documents and texts are archived with Sales and Distribution documents. They do not
influence whether or not a document can be archived.
Two factors determine whether or not a document can be archived, as follows:
 The overall processing status of the document
Documents marked Completed (meaning that the GBSTK field in the VBUK table has the value C or is
blank) can be archived.
 The residence time
echnical Data (SD)
Estimating Runtime
It is difficult to estimate how long it will take to archive data because it depends on so many different
factors such as amount of data, computer capacity, and so on.
The following example presents the results of an archiving run. This will allow you to make a rough
estimate of program runtime and conclude how different factors influence program runtime.
Example
Technical data:
 Sales orders and billing documents
 200,000 items
 25 items per document
 10 condition records per item
 No customer-specific check implemented in the user exit
The total runtime was five hours. About 40,000 items were archived per hour.
Note
If you are testing archiving for the first time, we recommend that you first set the commit counter to
10.
If, for example, you want to archive a lot of sales and distribution documents with configurable
materials or documents that are make-to order, you should consider setting the commit counter to 1.
Otherwise, deadlocks or similar database problems could occur.
If there are no problems during archiving, you can then set the commit counter higher, until database
problems occur. In this way, you can optimize performance.
You set the commit counter in Customizing via Sales and Distribution Data Transfer, Data Aging, and
Archiving Archiving Data Define control parameters for Archiving runs. Select the corresponding
archiving object and enter the value for the Commit counter.
For further information on the commit counter, see the cross-application documentation in CA -
Archiving Application Data under Customizing: Settings for the deletion program.
Carrying Out a Test Run
You can carry out a test run for archiving. You may also do this in a productive system. The system
issues a standard log, just as in a production run.
Note
During the test run no data is deleted and no archive files are created.
For this reason the performance of a test run is better than that of a production run.
Caution
To start a test run, deselect the field Create archive.
Setting Parameters in the Variant for the Archiving Run
You can set certain parameters for the archiving run, for example:
 Whether an archive file is to be created
No archive files are created in test mode.
 Whether a standard or detailed log is to be issued
The log records documents that could not be archived.
 Whether the preceding document is to be checked.
When you start the program, you can carry out one of the following functions:
 Select an existing variant
 Create and use a new variant
Archiving Sales Documents (SD-SLS)
Definition
Archiving object SD_VBAK for archiving sales documents.
Use
 Before using the archiving object for the first time, you should check Application Customizing
(SD-SLS).
 Check whether table VBREVC Revenue Recognition: Worklist of Changed Sales
Documents still contains relevant entries for the documents to be archived and update the
documents concerned.
 You have completed the entire revenue recognition process for the document concerned.
This means that table VBREVK contains only entries with status C Completely processed.
Structure
Tables
When you use the archiving object SD_VBAK, data is archived from the following tables:
Table reference
Table Table name
AUSP Characteristic Values
CMFK Storage Structure for the Error Log Header
CMFP Storage Structure for Errors Collected
FMSU FI-FM Totals Records
FPLA Billing Plan
FPLT Billing Plan: Dates
INOB Link Between Internal Number and Object
JCDO Change Documents for Status Object (Table JSTO)
JCDS Change Documents for System/User Statuses (Table JEST)
JEST Individual Status per Object
JSTO Status Object Information
KANZ Assignment of Sales Order Items - Costing Objects
KEKO Product Costing - Header Data

Table Table name
KEPH Product Costing: Cost Components for Cost of Goods Mfd
KNKO Assignment of Cost Est. Number to Config. Object
KOCLU Cluster for conditions in purchasing and sales
KSSK Allocation Table: Object to Class
NAST Message Status
SADR Address Management: Company Data
VBAK Sales Document: Header Data
VBAP Sales Document: Item Data
VBEH Schedule line history
VBEP Sales Document: Schedule Line Data
VBEX SD Document: Export Control: Data at Item Level
VBFCL Sales Document Flow Cluster
VBLB Sales document: Release order data
VBSN Change status relating to scheduling agreements
VBUK Sales Document: Header Status and Administrative Data
VBUP Sales Document: Item Status
VBUV Sales Document: Incompletion Log

Table Table name
VEDA Contract Data
The following archiving classes are also archived:
 Tables for Archiving Class K_TOTAL
 Tables for Archiving Class TEXT
 Tables for Archiving Class CHANGEDOCU
 Tables for Archiving Class K_UNITCOST
 Tables for Archiving Class CU_CONFIG
Programs
The following programs are delivered with SD_VBAK:
Program Function
S3VBAKWRS Write
S3VBAKDLS Delete
S3VBAKAU Analyze
S3VBAKPTS Check
S3VBAKRL Reload
Write Program
The write program supports the ADK interruption concept, that is, you can interrupt the write phase
and continue at a later point. For more information, see the application documentation for data
archiving under Data Archiving in the ABAP Application System Data Archiving with Archive
Development Kit (ADK) Archive Administration Interrupting and Continuing Archiving Sessions. A
compact log with information about the data processed is written in both the write and delete runs.
Alternatively, you can enable the output of a detailed log containing additional information.
Deletion Program
The standard variants SAP&PROD (production mode) and SAP&TEST (test mode) are delivered for the
delete program. Progress confirmation is output in the job log and in the dialog (status line) at
regular intervals in both the write run and delete run.
ILM-Based Information for the Archiving Object
You can use this archiving object with the SD_VBAK ILM object as part of SAP Information Lifecycle
Management. In order to do so, you must activate the associated business function Information
Lifecycle Management (ILM) (transaction SFW5). The system then also displays the ILM
Actions frame. You can use these actions to archive documents with the retention periods defined in
the Information Retention Manager. You can also make snapshots (copies) of data or delete data
that fulfills the prerequisites.
 For more information about the Relevance business functions for SAP ILM, see Activating
SAP ILM.
 For more information about ILM Enhancements in data archiving, see ILM-Specific
Enhancements in Archive Administration.
The following fields for SD_VBAK are defined in the ILM policy and are visible when processing ILM
policies (transaction IRMPOL):
 Available Time Bases
 End of Year (END_OF_YEAR)
 Available Condition Fields
 Date of Last Change (AEDAT)
 Sales Document Type (AUART)
 Company code to be billed (BUKRS_VF)
 Date on Which Record Was Created (ERDAT)
 Valid-From Date (Outline Agreements, Product Proposals) (GUEBG)
 Valid-To Date (Outline Agreements, Product Proposals) (GUEEN)
 Sales Document Item Category (PSTYV)
 Sales Document Category (VBTYP)
 Sales Organization (VKORG)
 Distribution Channel (VTWEG)
 Plant (WERKS)
 Available Policy Categories
RTP: Retention Rules
For more information, see SAP Information Lifecycle Management.
Call
To call sales document archiving, go to the Sales Screen Environment Archive Documents..
Alternatively, you can call archive administration under Tools Administration Administration Data
Archiving and enter object name SD_VBAK.
Authorization Objects
You need the following authority objects:
Authorization Description
object
V_VBAK_AAT Sales document type
V_VBAK_VKO Sales area (sales organization, distribution channel, division)
More Information
 Analyzing an Existing Archive (SD-SLS)
 Variant Settings for the Check (SD-SLS)
 Variant Settings for Reloading (SD-SLS)
For more information about the archiving object, see the application documentation for data
archiving under Data Archiving Data Archiving in the ABAP Application System Data Archiving with
Archive Development Kit (ADK) Archiving Object.
Special Archiving-Object-Specific Features (SD-SLS)
Archivability Checks
For sales documents, you can use program S3VBAKPTS which carries out an archivability check
before documents are selected.
rchiving of Returns (SD-SLS-RE-SR)
The returns document is based on the standard sales document.The Returns component does not
have its own archiving objects.It is important to ensure the consistency of the data in the returns
documents, however, in connection with the standard archiving object SD_VBAK (sales documents).
If you use the Returns component and want to archive sales documents, the system uses the
following BAdIs to ensure the consistency of the data in all relevant documents:
 ARC_SD_VBAK_CHECK (sales document)
 ARC_MM_MATBEL_CHECK (material document)
 ARC_RV_LIKP_CHECK (delivery note)
Analysis documents play an important role in the Returns component.In the analysis documents, you
record the analysis results that have been determined for the returned goods in the laboratory.The
system archives the results of the analysis documents with the returns document.Since the retention
periods depend on the material and its shelf life, SAP recommends a residence time of two years
before you delete the analysis documents.You need the analysis documents to show how the analysis
result has come about.
See also:
Sales Returns
Archiving Object
reating Additional Customer-specific Checks
Purpose
User exits allow you to integrate additional customer-specific checks into the checking logic. You can
control processing of the enhanced code via Customizing. There, you can configure the combination
of sales organization and sales document type to be used for the additional check. The check routine
is called at the end of the write program.
Process Flow
Implementation of an additional check is carried out in two steps.
1. Definition of the check
2. Definition of preconditions for execution
Definition of the check is also split up into three stages:
1. Select the archiving object for which an additional check is to be carried out.
2. Copy the reference check supplied (or start from scratch).
3. Activate the check.
Related Information
Define a Customer-Specific Additional Check (SD-SLS)
Define Preconditions for Customer-Specific Additional Checks (SD-SLS)
Define a Customer-Specific Additional Check (SD-SLS)
Procedure
1. From the SAP Easy Access menu, choose Tools ABAP Workbench Development ABAP
Editor.
2. Start report SDCLVOFM.
3. For archiving object SD_VBAK, enter class REAK.
To create a customer enhancement for the order, you must enter class REAK. Make sure to select the
change mode.
4. Execute the report.
The first line in the table contains the reference routine which you can copy and modify.
Example
Routine Number Description Active
1 SD_VBAK_SAP_1 √
a. Place the cursor in the routine number field, enter a new number (for example, 999),
and press Enter.
The copied routine appears as follows:
Sample Code

************************************************************
*** Attention: Copied routine ! ***
*** Please note : ***
*** 001 replaced everywhere by 999 ! ***
************************************************************
form sd_vbak_999
using sv_archbar.
endform.
You can enter the customer-specific check in the this routine.
Example
If you do not want the documents created by processor JDOE to be archived, then you need to add
the following coding.
Sample Code

if vbak-ernam = 'JDOE'
sv_archbar = no.
Endif.
The whole check appears as follows:
Sample Code

form sd_vbak_999
using sv_archbar.
if vbak-ernam = 'JDOE'
sv_archbar = no.
endif.
endform.
5. Save the check.

After completing the programming, the check must be activated.
1. Place the cursor on the line containing the name of your check routine.
2. Choose Edit Activate.
The √ symbol appears in the Active column. You routine has now been activated.
Related Information
Procedure
You enter the restrictions for the check in Customizing for the application as follows:
1. Call up transaction SPRO and display the SAP Reference IMG.
2. Choose Sales and Distribution Data Transfer, Data Aging, and Archiving Archiving
Data Archiving Control for Sales Documents.
3. Choose Archiving control for sales documents.
4. Define the sales organization and the sales document type that you want to be considered in
the check. When selecting the routine, you can use the F4 help to list all the activated
routines.
You want to define routine 999 for sales organization 0001 and all sales document types. You make
the following entries:
Sales Sales Document Residence Time Routine

Organization Type (Days) Number
0001 * 999
5. Save your entries.
Checks (SD-SLS)
Use
The following mandatory and optional checks are carried out on sales documents before they can be
archived:
 Residence time (mandatory)
 Flow (mandatory)
 Purchase order (optional)
 Accounting document (optional)
 Check residence of flow documents (optional)
 Residence time change date (optional)

Caution
When make-to-order and individual purchase orders are involved, then the corresponding CO data is
also archived, meaning the individual items that belong to this order. Note that if you reload the
order, then the CO data is not also reloaded.
Residence Time
The residence time is set per sales document type. The residence time for sales documents can be
calculated optionally according to the following:
 Current data minus creation date
 Current data minus last change date
To select the second option, mark Residence Time Change Date. For sales documents that were not
modified, the change date is identical to the creation date.
The system first checks whether the residence time set in Customizing for the sales document has
been exceeded.
You can use the Check Residence Flow Documents checkbox on the selection screen for variants to
set the basis for the calculation of the residence time.
 If the checkbox is not set, then the residence time is calculated on the basis of the creation
date or the change date of the document.
 If the checkbox is set, then the residence time is calculated on the basis of the creation date
of the last flow document.
Flow
The flow check is then carried out. That is, the system checks that all the subsequent documents for
the current sales document have an overall status as completed. The individual stages are as follows:
 Selection of Subsequent Documents in Table VBFA
During selection, the system ignores cancellation invoices, credit memos, and debit memos (as the
sales order has none of these documents as a direct subsequent document).
 Check Selected Subsequent Documents for Overall Processing Status ‘Completed’ (in Table
VBUK)
Note
A standard order is only archived if the goods issue has been posted and billed in the delivery.
A quotation is archived if the corresponding order has been completed. In this case, the delivery is
not checked.
Purchase Order
The selection screen of the variant contains checkboxes in which you can activate or deactivate
further system checks. If the checkbox Check purchase order is selected, then the system carries out
the following:
 Checks existence of a purchase order for current order in table EKKO

 Check existence of a purchase requisition for current order in table EBAN
Note
For direct external procurement (third-party order or individual purchase order) the check should be
activated. Otherwise, there is a danger that the vendor invoice (invoice entry) can no longer be
entered.
Accounting Documents
If the checkbox Check FI document is set, the system checks whether the billing document is settled
in financial accounting (for example, by payment)
More Information
Creating Additional Customer-Specific Checks (SD-SLS)
Variant Settings for Archiving (SD-SLS)
Use
When you schedule the write program, you need to enter an existing variant or create a new one.
The variant contains the selection criteria for the sales documents that you want to archive.
Features
Document Selection Criteria
You can select the sales documents to be archived in both the Sales
Documents and Constraints frame in accordance with the following criteria:
 Sales and Distribution Document Number
 Sales Document Type
 Creation Date
 Sales Organization
Options
 Change Date: Residence Time
If this indicator is set, the residence time is calculated using the date on which the sales document
was last changed, rather than the creation date. (For sales documents that have not been changed,
the change date is identical to the creation date.)
 Check residence of flow documents
 If the indicator is not set, the residence time is calculated on the basis of the creation
date or change date of the sales document.
 If the indicator is set, the residence time is calculated on the basis of the creation
date or change date of the last flow document.
 Check Purchase Order

If you want to check whether the purchase order and the associated purchase requisition still exist,
select this option.
 Check FI Document
If you want to check whether all accounting documents that exist for an order have been cleared,
select this option.
Process Control
 If the write program for the selection criteria you entered is to perform a simulation only,
select Test Mode. The system reads the data but does not generate an archive file. The
system outputs statistics for the number of data records read during the test run. You can
delete the data at a later point in a separate step using the production mode variant of the
delete program.
 If you want to start the write program and generate archive files for the selection criteria you
entered, select Production Mode.
If the automatic start function has been enabled for the delete program in archiving object-specific
Customizing, you can also set the Delete with Test Variant indicator (default setting). This starts the
delete program for the archiving object with the test mode variant defined in archiving object-
specific Customizing. If the indicator is not set, the delete program starts with the production mode
variant; the data is deleted from the database.
Detailed Log
You can use this indicator to define whether a compact or detailed log is to be output when the write
program is executed. In addition to the information in the compact log, the detailed log also contains
all objects processed, including the associated messages.
Archiving Run Comment
Here, you can enter a text describing the content of the archiving run. This makes it easier to select
the archiving run in archive administration at a later point, for example during the delete phase.
See also:
For more information, see the application documentation for data archiving under Data Archiving in
the ABAP Application System Data Archiving with Archive Development Kit (ADK) Archive
Administration Archiving Procedure Create Archive Files.
Variant Settings for the Check (SD-SLS)
Use
When you schedule the check a preprocessing program you must enter an already existing variant or
create a new one. The variant contains the selection criteria for the sales documents you want to
check.
Note
You can also start the preprocessing program directly in the ABAP editor via report S3VBAKPTS.
Features
Document selection criteria
You can choose the following selection criteria for the sales documents you want to check
under Sales Docs and Further Selection Criteria:
 SD document
 Sales document type
 Creation date
 Sales organization
Options
If this indicator is set, the residence time is calculated based on the last change date of the sales
document not the creation date. (For sales documents that were not modified, the change date is
identical to the creation date.)
 Check Flow Documents Residence
 If the checkbox is not set, then the residence time is calculated on the basis of the
creation date of the document.
 If the checkbox is set, then the residence time is calculated on the basis of the
chronologically last flow document.
 Check Purchase Rrder
If you want to check whether the purchase order and the corresponding purchase requisition still
exist, then choose this option.
 Check FI Document
If you want to check whether all existing accounting documents that belong to an order have been
balanced, then choose this option.
Detail log
Set this indicator if you want the system to display the check log for every sales document that is not
archivable. The check log is divided into two sections – the header and the detail display. The header
contains the statistical data of the check; in the detail display shows the check status of each sales
document. By clicking on a line that contains a document number you can call up the order display
transaction.
Variant Settings for Reloading (SD-SLS)
Use
You can set reloading criteria in variant settings for reloading.
Caution
When reloading sales documents, the corresponding CO data is not simultaneously reloaded into the
system. Therefore, you should reload sales documents only in case of emergency, for example, if
documents were wrongly selected.
For this reason, you cannot call this function up with the menu. Please contact your system
administrator.
Features
The following options are available:
Entry Fields
 Document selection
Select the documents to be reloaded
Check boxes
 Test run
Select this option if you only want to simulate reloading, for example, to check possible errors.
Related Information
Reloading Archives
Application Customizing (SD-SLS)
Use
In application-specific customizing, you can set the order-specific requirements for archiving.
Features
The following input fields are available:
 Sales document type
 Residence time for a sales document in days
You use these parameters to set the residence time for every combination of sales organization and
sales document type.
 FORM routine number
If you have defined an additional check routine for a combination of sales organization and sales
document type, you can enter the number of the check routine here.
Entry Options in Application Customizing (V_TVARA)
The following table displays possible value combinations that you can use when maintaining views
V_TVARA:
SOrg SaT Document date

y
1. * *
2. 0001 * 40
3. * OR 20
4. 00* O* 100
5. 0001 OR 1
The examples can be understood as follows:
1. The standard residence time (30 days) is used for all sales document types for all sales
organizations.
2. A residence time of 40 days is used for all sales document types for sales organization 0001.
3. A residence time of 20 days is used for sales document type OR for all sales organizations.
4. A residence time of 100 days is used for all sales document types starting with O for all sales
organizations starting with 00.
5. A residence time of 1 day is used for sales document type OR for sales organization 0001.
Note: If you do not maintain the views, the system cannot archive the documents.
Calling Up Customizing
To call up application-specific customizing, go to Customizing for Sales and Distribution and

choose Data Transfer and Archiving Archiving data Archiving control for sales documents .
Alternatively, you can call up application-specific customizing as follows:
1. In the Sales Screen choose Environment Archive documents.
2. Choose Goto Customizing.
3. Under Application-specific customizing choose Archiving Conditions V_T681H.
See also:
Defining a Customer-specific Additional Check (SD-SLS)
Customizing
Analyzing an Existing Archive (SD-SLS)
Use
The Analyze function allows you to view a list of the most important header and item data for
archived sales documents from a number of archiving runs specified by you.
Entry Fields
Select the documents that you want to display.

Display Function for Archived Sales Documents (SD-SLS)
Use
You can use the Archive Information System (Transaction SARI) to display archived sales documents
in single document display. Other functions for displaying documents is the original document
display via ArchiveLink and other linked documents via the Document Relationship Browser (DRB).
Prerequisites
 Archiving object SD_VBAK has at least one information structure, which is based on the
standard field catalogs SAP_SD_VBARK_001 or SAP_SD_VBARK_002 delivered as part of the
SAP System.
 The information structure was activated and filled.
 The information structure contains the field VBELN as a key field.
Note
For you to be able to display the linked documents via DRB (see below), information structures for
archiving objects RV_LIKP and SD_VBRK have to be active and filled.
 The Authorizations for displaying archived sales documents have been maintained.
Features
Single document display
You can display single documents in the original display transaction (VA03), which is also used to
display documents in the database. The single document display of archived sales documents is no
different from the display of documents in the database. However, archived sales documents can no
longer be modified.
Certain documents, such as WM transport orders or shipping units, do not have a display function
and can therefore not be displayed if they are in the database.
Note
As of SAP R/3 Enterprise (Support Package 08) it is possible for you to directly display archived sales
documents via the transaction VA03. Messages, texts and document flow are not displayed. For
more information see SAP Note 577162.
Displaying linked documents via DRB
Via the Document Relationship Browser (DRB) you can display the entire process chain in which a
specific document is embedded. It does not matter whether the preceding or subsequent document
you want to display is still in the database or was already archived. The following prerequisites must
be fulfilled to display linked documents:
The preceding or subsequent document you want to display must have an online display function.
 § If it has been archived, a preceding or subsequent document must be part of an active

information structure of the archive information system.
For more information see Sales Documents in DRB (SD-SLS) .

Displaying the Original Documents via ArchiveLink
From the single document display you can call up the original document of the archived sales
document by using ArchiveLink via Environment Originals. This is also true for linked Work Items
and IDocs.
Note
You can only display documents via ArchiveLink if you are properly connected to ArchiveLink. This
includes, for example, that the ArchiveLink Viewer has been configured correctly, and that the
function for accessing optical archives has been activated properly. In addition, the link entries in the
corresponding tables for ArchiveLink, Work Item and IDocs have to exist in the database.
From the list of the archive information structure you can call up this function via Original display .
This is also true for linked work items and IDocs.
Note
The same prerequisites apply for displaying original documents as for the individual document
display (see above).
Activities
From the Archive Information System you can call up the functions for single document display
( Sales document ), original document display ( Display originals ) and DRB ( DRB: SD order ) via the
selection screen Display data object , which appears when you select a document from the list of the
archive information structure.
For more information about the Archive Information System see Archive Information System (AS) .
Authorizations (SD-SLS)
To display archived sales documents via the archiving information system, you must have at least the
following authorizations:
1. Reading archives:
Object S_ARCHIVE Value Description
APPLIC SD Application
ARCH_OBJ SD_VBAK Archiving objects
ACTVT 03 Displaying archives
2. Displaying archived sales documents:
Object V_VBAK_AAT Value Description
AUART * Sales document type

Object V_VBAK_AAT Value Description
ACTVT 03 Displaying sales documents
Object V_VBAK_VKO Value Description
VKORG * Sales organization
VTWEG * Distribution channel
SPART * Division
ACTVT 03 Displaying sales documents
3. Displaying documents set up via ArchiveLink:
Object Value Description
S_WFAR_OBJ
OAARCHIV * Access to a physical archive
OAOBJEKTE * Object category access
OADOKUMEN * Document type access

T
ACTVT 03 Displaying archived originals
Note
Any value that is listed as * above can be limited. You can, for example, limit the sales document type
to OR (standard order). This means that the user is only authorized to display archived sales orders,
but not any other sales document types.
Archiving Billing Documents (SD-BIL)
Definition
Archiving object SD_VBRK for archiving billing documents.
Prerequisites
 Before using the archiving object for the first time, check Application Customizing.
 You have completed the entire revenue recognition process for the document concerned.
This means that table VBREVK contains only entries with status C Completely processed.
Structure
Tables
When you use the archiving object SD_VBRK, data is archived from the following tables:
Table reference
Table Table name
EIKP Foreign Trade: Export/Import Header Data
EIPO Foreign Trade: Export/Import: Line Item Data
FPLA Billing Plan
FPLT Billing Plan: Dates
FPLTC Payment Cards: Transaction Data – SD
KOCL Cluster for conditions in purchasing and sales

U
NAST Message Status
VBFCL Sales Document Flow Cluster
VBPA SD document: Partner
VBRK Billing Document: Header Data
VBRL SD document: Invoice List
VBRP Billing Document: Line Item Data
VBUK SD document: Header status and administrative data

Table Table name
The following archiving classes are also archived:
 Tables for Archiving Class TEXT
Programs
The following programs are delivered with SD_VBRK:
Program Function
S3VBRKWR Write
S
S3VBRKDLS Delete
S3VBRKAU Analyze
S3VBRKPTS Check (preliminary)
S3VBRKRL Reload
and continue at a later point. To be able to use this function, the Interruption Possible indicator must
be set in Customizing (transaction AOBJ). This parameter is not set by default. For more information,
see the application documentation for data archiving under Data Archiving in the ABAP Application
System Data Archiving with Archive Development Kit (ADK) Archive Administration Interrupting
and Continuing Archiving Sessions
delete program. Progress confirmation is regularly output in the job log and in the dialog (status line)
in both the write run and delete run.
ILM-Related Information for the Archiving Object
You can use this archiving object with the SD_VBRK ILM object as part of SAP Information Lifecycle
SAP ILM.
The following fields for SD_VBRK are defined in the ILM policy and are visible when processing ILM
 Available Time References
 End of fiscal year (END_OF_FISCAL_YEAR)
 Available Standard Condition Fields
Standard Field Country from Company Code ((BS_COUNTRY_OF_BUKRS))
 Company code (BUKRS)
 Creation date (ERDAT)
 Billing document type (FKART)
 Billing date (FKDAT)
Call
To call SD billing document archiving, go to the Billing Screen and Environment Archive
Documents.
Alternatively, you can also call archive administration

under Tools Administration Administration Data Archiving and enter object name SD_VBKA.
You need the following authority objects:
Authorization End-User Name

object
V_VBRK_FKA Billing type
V_VBRK_VKO Sales organization

Authorization End-User Name
object
Enablement for Information Retrieval
The ILM object SD_VBRK assigned to this archiving object is enabled for use with the Information
Retrieval Framework (IRF). The IRF allows you to search for and retrieve personal data of a specified
data subject, based on a data model you define in your system. To help you get started with the data
modeling process, SAP delivers an implementation of BAdI: Tables Used by an ILM
Object (BADI_DTINF_ILM_OBJ_TABLES) for SD_VBRK. See SAP Note 2743548 for more
information.
Before you can start a search for personal data related to a specified data subject, the following
prerequisites must be fulfilled:
 Assign the ILM object to a purpose for which the data was collected and processed using
Customizing activity Maintain Purposes (transaction DTINF_MAINTAIN_PURP).
If you also want to enable the retrieval of personal data stored in archive files, perform the following
additional steps:
 You use the Customizing activity Maintain Profiles (transaction DTINF_MAINTAIN_PROFILE)

to create a profile for the data collection. In this profile, you define that archived personal
data must be included in the search.
 Ensure that for archiving object SD_VBRK, there is at least one active archive information
structure that contains the following selectable fields:
 Customer (KUNNR)
 Vendor (LIFNR)
These fields are used by the IRF to determine which data should be fetched from the archive.
If you have not defined your own archive information structure in your system, you can use the
standard archive information structure SAP_SD_VBRK_IRF delivered by SAP for this purpose.
For more information, see Information Retrieval Framework (IRF).
Integration
The deliveries should be archived before the billing documents. The sequence results from the
linking of the documents through the flow. There is no dependency to the sales documents.
Further Information
Variant Settings for Writing (SD-BIL)
Variant Settings for the Check (SD-BIL)
Variant Settings for Reloading (SD-BIL)
Analyzing an Existing Archive (SD-BIL)

Billing Documents in the DRB (SD-BIL)
Special Archiving-Object-Specific Features (SD-BIL)
Archivability Checks
For billing documents you can use program S3VBRKPTS, which carries out an archivability check
before documents are selected.
See also:
Checks (SD-BIL)
The following checks are carried out on a billing document before it can be archived:
 Residence time (mandatory)
 Residence time change date (optional)
 Flow (mandatory)
 Accounting document (optional)
Residence Time
The residence time is set per billing document type.
The system first checks whether the residence time set in Customizing for the billing document has
been exceeded. The residence time refers to the creation date of the document.
Residence Time Change Date
If this indicator is set, the system checks whether the residence time based on the last change date
of the billing document, not the creation date, has been exceeded. (For billing documents that were
not modified, the change date is identical to the creation date.)
Flow
If the billing document has a subsequent document (for example, credit memo request with
reference to billing document) then the system checks whether the subsequent document has an
overall status of Completed.
Accounting Documents
In application-specific customizing, if the field Check FI Document is set, the system checks whether
the billing document is settled in Financial Accounting (for example, through payment)
Note
If the documents contain Subsequent Settlement conditions, you cannot archive the documents until
settlement accounting has been performed for the arrangements in question, and the retention
period that you maintained for the document in Customizing for Subsequent Settlement has expired.
For further information see Archiving Agreements (SD-MD-AM).
Variant Settings for Archiving (SD-BIL)
Use
The variant contains the selection criteria for the billing documents that you want to archive.
Features
You can select the billing documents to be archived in both the Billing
Documents and Constraints frame in accordance with the following criteria:
 Sales and distribution document number
 Billing type
 Creation date
 Company code
Options
If this indicator is set, the residence time is calculated using the date on which the billing document
was last changed, rather than the creation date. (For billing documents that have not been changed,
the change date is identical to the creation date.)
 Check residence of flow documents
If this indicator is not set, the residence time is calculated on the basis of the creation date or change
date of the billing document.
If the indicator is set, the residence time is calculated on the basis of the creation date or change
date of the last flow document.
Process Control
 If the write program for the selection criteria you entered is to perform a simulation only,
select Test Mode. The system reads the data but does not generate an archive file. The
system outputs statistics for the number of data records read during the test run. You can
delete the data at a later point in a separate step using the production mode variant of the
delete program.
 If you want to start the write program and generate archive files for the selection criteria you
entered, select Production Mode.
If the automatic start function has been enabled for the delete program in archiving object-specific
Customizing, you can also set the Delete with Test Variant indicator (default setting). This starts the
delete program for the archiving object with the test mode variant defined in archiving object-
specific Customizing. If the indicator is not set, the delete program starts with the production mode
variant; the data is deleted from the database.
Detailed Log
You can use this indicator to define whether a compact or detailed log is to be output when the write
program is executed. In addition to the information in the compact log, the detailed log also contains
all objects processed, including the associated messages.
Archiving Run Comment
Here, you can enter a text describing the content of the archiving run. This makes it easier to select
the archiving run in archive administration at a later point, for example during the delete phase.
See also:
Administration Archiving Procedure Create Archive Files.
Use
When you schedule the check with the preprocessing program, you must enter an already existing
variant or create a new one. The variant contains the selection criteria for the billing documents that
you want to check.
Note
You can also start the preprocessing program directly in the ABAP editor by running report
S3VBRKPTS.
Features
You can select the documents to be archived by using both the Billing Documents and Further
Selection Criteria frames, which offer the following criteria:
 SD document number
 Billing type
 Creation date
 Company code
Options
If this indicator is set, the residence time is calculated based on the last change date of the billing
document, not on the creation date. (For billing documents that were not modified, the change date
is identical to the creation date.)
 Check Flow Documents Residence
 If the checkbox is not set, then the residence time is calculated on the basis of the
creation date of the billing document.
 If the checkbox is set, then the residence time is calculated on the basis of the
chronologically last flow document.
Detail log
Set this indicator if you want the system to display the check log for every billing document that is
not archivable. The check log is divided into two sections – the header and the detail display. The
header contains the statistical data of the check; the detail display shows the check status of each
billing document. By clicking on a line that contains a billing document number, you can call up the
order display transaction.
Variant Settings for Reloading (SD-BIL)
Caution
When reloading billing documents, the corresponding CO data is not simultaneously reloaded into
the system. Therefore you should reload billing documents only in case of emergency, for example, if
documents were wrongly selected.
For this reason you cannot call this function up with the menu. Please contact your system
administrator.
Features
Entry Fields
Select the documents to be reloaded.
Checkboxes
 Test run
Select this option if you only want to simulate reloading, for example, to check possible errors.
Related Information
Reloading Archives
Application Customizing (SD-BIL)
Use
In application-specific customizing, you can set the archiving requirements specific for billing.
Features

 Billing type
 Residence time for a billing document in days
billing type.
 Check completion in Financial Accounting
If you set this parameter, the system checks whether all existing accounting documents have been
cleared.
document type, you can enter the number of the check routine here.
Entry Options in Application Customizing (V_TVARR)
The following table displays possible value combinations that you can use when maintaining views
V_TVARR:
SOrg BillType Document date
1. * *
2. 0001 * 40
3. * F2 20
4. 00* F* 100
5. 0001 F2 1
The examples can be understood as follows:
1. The standard residence time (30 days) is used for all billing document types for all sales
organizations.
2. A residence time of 40 days is used for all billing document types for sales organization 0001.
3. A residence time of 20 days is used for billing document type F2 for all sales organizations.
4. A residence time of 100 days is used for all billing document types starting with F for all sales
organizations starting with 00.
5. A residence time of 1 day is used for billing document type F2 for sales organization 0001.
Note
If you do not maintain the views, the system cannot archive the documents.
Activities
Note
Creation of a customer-specific additional check is identical for billing documents and sales
documents.
Calling Up Customizing

choose Data Transfer and Archiving Archiving data Archiving control for sales documents .
1. In the Billing Screen choose Environment Archive documents.
3. Under Application-specific Customizing choose Archiving Control for Billing Docs
See also:
Customizing
nalyzing an Existing Archive (SD-BIL)
Use
The Analyze function allows you to view a list of the most important header and item data for
archived billing documents from a number of archiving runs specified by you.
Entry Fields
Select the documents that you want to display
isplay Function for Archived Billing Documents (SD-BIL)
Use
You can use the Archive Information System (transaction SARI) to display archived billing documents
in single document display. Other functions for displaying documents is the original document
display via ArchiveLink and other linked documents via the Document Relationship Browser (DRB).
Prerequisites
 Archiving object SD_VBRK has at least one information structure, which is based on the
standard field catalogs SAP_SD_VBRK_001 or SAP_SD_VBRK_002 delivered as part of the
SAP System.
 The information structure was activated and filled.
 The information structure contains the field VBELN as a key field.
Note
For you to be able to display the linked documents via DRB (see below), information structures for
archiving objects RV_LIKP and SD_VBAK have to be active and filled.
 The Authorizations for displaying archived billing documents have been maintained.
Features
Single document display
You can display single archived billing documents via transaction VF07. This corresponds to the
original display transaction for billing documents in the database (VF03). However, archived billing
documents can no longer be modified.
Certain documents, such as WM transport orders or shipping units, do not have a display function
and can therefore not be displayed if they are in the database.
Displaying linked documents via DRB
Via the Document Relationship Browser (DRB) you can display the entire process chain in which a
specific document is embedded. It does not matter whether the preceding or subsequent document
you want to display is still in the database or was already archived. The following prerequisites must
be fulfilled to display linked documents:
The preceding or subsequent document you want to display must have an online display function.
 § If it has been archived, a preceding or subsequent document must be part of an active

information structure of the archive information system.
For more information, see Billing Documents in DRB (SD-BIL) .
Displaying the Original Documents via ArchiveLink
From the list of the archive information structure you can call up this function via Original display .
This is also true for linked work items and IDocs.
Note
The same prerequisites apply for displaying original documents as for the individual document
display (see above).
You can only display documents via ArchiveLink if you are properly connected to ArchiveLink. This
includes, for example, that the ArchiveLink Viewer has been configured correctly, and that the
function for accessing optical archives has been activated properly. In addition, the link entries in the
corresponding tables for ArchiveLink, Work Item and IDocs have to exist in the database.
Activities
From the Archive Information System you can call up the functions for single document display
( Billing document ), original document display ( Display originals ) and DRB ( DRB: SD billing
document ) via the selection screen Display data object , which appears when you select a
document from the list of the archive information structure.
For more information about the Archive Information System see Archive Information System (AS) .
Authorizations (SD-BIL)
To display individual documents from archived sales documents via the archiving information system,
you must have at least the following authorizations:
1. Reading archives:
2.
Object S_ARCHIVE Value Description
APPLIC SD Application
ARCH_OBJ SD_VBR Archiving object

K
ACTVT 03 Displaying archives
3. Displaying archived billing documents:
4.
Object V_VBAK_FKA Value Description
FKART * Billing type; can be specified
ACTVT 03 Displaying the sales documents
Object V_VBRK_VKO Value Description
VKORG * Sales organization; can be specified
ACTVT 03 Displaying the sales documents
5. Displaying documents set up via ArchiveLink:
Object Value Description

S_WFAR_OBJ
OAARCHIV * Access to a physical archive: can be specified

OAOBJEKTE * Object category access; can be specified
OADOKUMENT * Document type access; can be specified
ACTVT 03 Displaying archived originals
Archiving of Empties Management (SD-BIL-EM)
Definition
The following Empties Management business objects can be archived:
Objects Archiving objects
Archiving of Monthly Empties Stock BEV1_EMBD
Archiving of Empties Update BEV1_EMFD
Use
Note
You should coordinate empties data archiving with billing document archiving, since the billing
documents provide basic information for the empties data.
Before you use the archiving objects for the first time, you should check the application customizing.
You can use the archive administration transaction (SARA), or call archiving from the SAP Easy
Access screen by choosing Logistics Sales and Distribution Empties Management Archiving .
For information about how to archive objects, see the descriptions for the individual archiving
objects with the title Archiving of <Object Type>.
Integration
Empties Management takes account of empties for sales documents (SD) and for purchasing
documents (purchase orders, MM). The system determines the assignment of full products and
empties automatically in both cases, for example, the empties that belong to a full product. You use
the archiving object MM_EKKO to archive purchasing documents. When the system archives
purchasing documents, it no longer needs the assignment between full products and empties. The
system uses the BAdI ARC_MM_EKKO_WRITE to delete the link to the tables in Empties
Management.
For more information about the archiving object MM_EKKO, see Archiving of Purchasing Documents
(MM-PUR) .
See also:
Archiving Object
Archiving of Monthly Empties Stock (SD-BIL-EM)
Definition
Monthly empties stocks are archived, deleted, and reloaded using the archiving object BEV1_EMBD.
Use
Monthly empties stocks are only archived if they are not required in the Empties
Management component anymore.
You can display the logs for the write programs in one of two forms:
 Log (summary)
Grouped display based on analog message texts with reference to a sample data record from a
related archiving object.
 Log (detail)
Individual display of all archiving objects belonging to an archiving run, including message texts.
For more information about the logs generated during archiving, see Logs.
Structure
Tables
If you use the archiving object BEV1_EMBD, data is archived from the following tables:
Table Table name
/BEV1/EMLGBSD Customer Empties Stock per Month
Text (archiving class) SAPscript texts
Programs
The following programs are delivered for BEV1_EMBD:
Program Function
/BEV1/EMBSDWR Write
/BEV1/EMBSDRL Reload
/BEV1/EMBSDDL Delete
The write program supports the ADK (Archive Development Kit) interruption concept, which allows
you to interrupt the write phase and continue it at a later point in time. If you want to use this
function, the Interruption Possible indicator must be set in Customizing (transaction AOBJ). This
parameter is not preset. For more information, see Interrupting and Continuing Archiving Sessions.
The standard variants SAP&PROD (production mode) and SAP&TEST (test mode) are available for the
delete program.
During both the write and delete runs, progress messages are regularly issued in the job log
(background processing) and in the status line (dialog processing). For more information, see Logs.
Integration
Displaying monthly empties stock
To display the monthly empties stock using the Archive Information System, you need an archive
information structure and a field catalog.
Note
If you want to display the monthly empties stock, you must define the archive information structure
and field catalog, since they are not part of the standard delivery.
The archive information structure must be set up and active before the system can use it.
For more information about archive information structures, see Using the Archive Information
System .
You can use this archiving object with the ILM objectBEV1_EMBD within SAP Information Lifecycle
Management. A prerequisite for this is that you have activated the corresponding Information
Lifecycle Management (ILM) business function (transaction SFW5). The system then additionally
shows the ILM Actions frame. With these actions, you can carry out an archiving in which the
retention periods defined in the Information Retention Manager are evaluated, for example.
Furthermore, you can make snapshots (copies) of data or destroy data that satisfies the
prerequisites.
SAP ILM.
The following fields for BEV1_EMBD are defined in the ILM policy and in processing for ILM policies
(transaction IRMPOL):
 Start Time (START_DATE)
 Distribution Channel (DIST_CHANNEL)
 Sales Organization (SALES_ORG)

 RST: Residence Rules
 RTP: Retention Rules
ariant Settings for Writing (SD-BIL-EM)
Use
When you schedule the write program, you must enter an existing variant or create a new one.The
variant contains the selection criteria for the monthly empties stock that you want to archive.
Features
The selection criteria for the data records are the characteristics and key figures of the aspect. You
can enter individual values or value intervals as selection criteria.
You can use the selection criterion Period . The system only archives empties stocks within the
interval of the specified period.
Note
Enter the required period or periods in the same month format in which the system posted the
empties record.
See also:
Creating Archive Files
Archiving of Empties Update (SD-BIL-EM)
Definition
The empties update is archived, deleted, and reloaded using the archiving object BEV1_EMFD.
Use
The empties update is only archived if it is not required in the Empties Management component
anymore.
 Log (summary)
 Log (detail)
Structure
Tables
If you use the archiving object BEV1_EMFD, data is archived from the following tables:
Table Table name
/BEV1/EMLGBWDP Empties Movement Account Customer
/BEV1/EMLGFAD Empties Movement - Customer Billing Status
/BEV1/EMLGOFS Empties - Billing Document Without Update
Text (archiving class) SAPscript texts
If you use the archiving object BEV1_EMFD, data is deleted from the following table:
Table Table name
/BEV1/ Linkage Table in the Purchase Order

NELINKTPO
Programs
The following programs are delivered for BEV1_EMFD:
Program Function
/BEV1/ Write
EMFADWR
/BEV1/EMFADRL Reload
/BEV1/EMFADDL Delete
delete program.
Integration
Displaying archived empties update
To display an archived empties update using the Archive Information System, you need an archive
information structure and a field catalog.
Note
If you want to display the archived empties update, you must define the archive information
structure and field catalog, since they are not part of the standard delivery.
System .
You can use this archiving object with the ILM objectBEV1_EMFD within SAP Information Lifecycle
prerequisites.
SAP ILM.
The following fields for BEV1_EMFD are defined in the ILM policy and in processing for ILM policies
 Created On (CREATION_DATE)
Variant Settings for Writing (SD-BIL-EM)
Use
variant contains the selection criteria for the Empties Update that you want to archive.
Features
You can use the following selection criterion:
 Created on
The system only archives empties stocks that were added during the empties update interval.
See also:
Archiving of Pendulum List Indirect Sales (SD-BIL-RB-PL)
Definition
The following Pendulum List Indirect Sales business objects can be archived:
Objects Archiving objects
Request Data /BEV4/PL01
Converted Request Table with Reporting Period /BEV4/PL02
Request Table with Reporting Period /BEV4/PL03
Logs for Pendulum List Sales /BEV4/PL04
Note
The archiving of the pendulum list is split into four archiving objects for easier organization.
Use
Note
Before you use the archiving objects for the first time, you should check the application customizing.
You call archive administration using transaction SARA and enter the relevant archiving object
manually.
For information about how to archive objects, see the descriptions for the individual archiving
objects with the title Archiving of <Object Type> .
See also:
Archiving Object
Archiving of Request Data (SD-BIL-RB-PL)
Definition
Pendulum list request data is archived and deleted using the archiving object /BEV4/PL01.
Use
Pendulum list request data is only archived if it is not required in the Pendulum List Indirect
Sales component anymore.
Note
Request data contains data records in which a wholesaler provides value-based and quantity-based
information about sales with third parties, with the relevant materials or assortments.
 Log (summary)
 Log (detail)
Structure
Tables
If you use the archiving object /BEV4/PL01, data is archived from the following tables:
Table Table name
/BEV4/ Sales Request History

PLDANFABH
/BEV4/PLDANFABS Sales Request - Header
/BEV4/PLDANFART Sales Request - Items
Note
You can archive master data with status 0003 Deleted and 0004 Processed.
Programs
The following programs are delivered for /BEV4/PL01:

Program Function
/BEV4/PLP01 Preparation program
/BEV4/ Write
PLW01
/BEV4/PLD01 Delete
delete program.
Integration
Displaying archived request data
To display archived request data using the archive information system, you need an archive
information structure created on the basis of the following SAP standard field
catalog:/BEV4/PL01_1 (requests header data)
System.
You can use this archiving object with the ILM object/BEV4/PL01_1 within SAP Information Lifecycle
prerequisites.
SAP ILM.
The following fields for /BEV4/PL01 are defined in the ILM policy and in processing for ILM policies
Variant Settings for Writing (SD-BIL-RB-PL)
Use
variant contains the selection criteria for the request data that you want to archive.
Features
Note
You make the required selections in the preparation program. When the system starts the write
program, it copies the result from the preparation program.
Other possible settings
The settings for the flow control, log options, and the note on the archiving run are options that are
also valid for other archiving objects. For more information, see the general archiving documentation
under Variant Maintenance for Archiving Jobs .
See also:
Displaying Archived Request Data (SD-BIL-RB-PL)
Use
You can display specific request data from the archive. The table can be displayed using the Archive
Information System, for example.
Note
The system can only find documents for which there is a suitable archive index.
Features
To display archived request data using the Archive Information System , you need the archive
information structure /BEV4/PL01_1 (requests header), which has been created on the basis of the
SAP standard field catalog /BEV4/PL01_1 (message requests – header).
For more information about using archive information structures, see Using the Archive Information
System .
Archiving Converted Request Table with Reporting Period (SD-BIL-RB-PL)
Definition
The converted pendulum list request table is archived and deleted using the archiving
object /BEV4/PL02.
Use
Only archive the converted pendulum list request table with reporting period data if it is not required
in the Pendulum List Indirect Sales component anymore.
 Log (summary)
 Log (detail)
Structure
Tables
Table Table name
/BEV4/ Converted Request Table with Reporting Period

PLDANFKON
Programs
Program Function

Program Function
/BEV4/ Write
PLW02
/BEV4/PLD02 Delete
delete program.
Integration
Displaying archived converted request tables
To display archived converted request tables using the Archive Information System, you need an
archive information structure created on the basis of the following SAP standard field
catalog: BEV4/PL02_1 (converted requests).
System .
You can use this archiving object with the ILM object/BEV4/PL02 within SAP Information Lifecycle
prerequisites.
SAP ILM.

ariant Settings for Writing (SD-BIL-RB-PL)
Use
variant contains the selection criteria for the Converted Request Table with Reporting Period that
you want to archive.
Features
You can use the following selection criteria under Converted Requests :
 Reporting date
 Distribution channel
 Division
 Wholesaler
 Object number
 Customer
 Material
 External object number
 External customer number
 External article number
 Request status
 Confirmation received
The system only archives pendulum lists if the selection criteria under Converted Requests are
within the selected interval.
also valid for other archiving objects.For more information, see the general archiving documentation
See also:
Displaying Archived Converted Request Tables (SD-BIL-RB-PL)
Use
You can display a converted request table from the archive. The table can be displayed using the
Archive Information System, for example.
Note
Features
To display an a rchived converted request table using the Archive Information System , you need the
archive information structure BEV4/PL02_1 (converted requests), which has been created on the
basis of the SAP standard field catalog BEV4/PL02_1 (converted requests).
System .
Archiving of Request Table with Reporting Period (SD-BIL-RB-PL)
Definition
Pendulum list request tables are archived and deleted using the archiving object /BEV4/PL03.
Use
Pendulum list request tables are only archived if they are not required in the Pendulum List Indirect
 Log (summary)
 Log (detail)
Structure
Tables
Table Table name
/BEV4/PLDANFMEL Request Table with Reporting Period
/BEV4/PLDANFZEIT Request Update
Programs
Program Function
/BEV4/ Write
PLW03
/BEV4/PLD03 Delete
delete program.
Integration
Displaying archived request tables
To display archived request tables using the Archive Information System, you need an archive
information structure created on the basis of the following SAP standard field
catalog: BEV4/PL03_1 (requests with reporting period).
System .

prerequisites.
SAP ILM.
 Start time (START_DATE)
Use
variant contains the selection criteria for the Request Table with Reporting Period that you want to
archive.
Features
You can use the following selection criteria under Requests with Reporting Period :
 Reporting date
 Distribution channel
 Division
 Wholesaler
 Object number
 Customer
 Material
 Request status
The system only archives pendulum lists if the selection criteria under Requests with Reporting
Period are within the selected interval.
also valid for other archiving objects.For more information, see the general archiving documentation
See also:
Displaying Archived Requests Table with Reporting Period (SD-BIL-RB-PL)
Use
You can display a requests table with reporting period from the archive. The table can be displayed
using the Archive Information System, for example.
Note
Features
To display an archived requests table with reporting period using the Archive Information System ,
you need the archive information structure BEV4/PL03_1 (requests with reporting period), which has
been created on the basis of the SAP standard field catalog BEV4/PL03_1 (requests with period).
System .
Archiving of Logs for Pendulum List Sales (SD-BIL-RB-PL)
Definition
Pendulum list logs are archived and deleted using the archiving object /BEV4/PL04.
Use
Pendulum list logs are only archived if they are not required in the Pendulum List Indirect
 Log (summary)
 Log (detail)
Structure
Tables
Table Table name
/BEV4/PLPROT Logs for Pendulum List Sales (Master Data)
/BEV4/PLPROT_2 Log File with Error Messages
/BEV4/PLPROT_ALL Customers and Material Records
Programs
Program Function
/BEV4/PLW04 Write
/BEV4/PLD04 Delete
delete program.
Integration
Displaying archived log for pendulum list sales

To display archived logs for pendulum list sales using the Archive Information System, you need an
archive information structure created on the basis of the following SAP standard field
catalog: BEV4/PL04_1 (logs for pendulum list sales).
System .
prerequisites.
SAP ILM.
 Created On (CREATION_DATE)
Use
variant contains the selection criteria for the Logs for Pendulum List Sales that you want to archive.
Features
You can use the following selection criteria under Logs for Pendulum List Sales :
 Transfer number
 File name
 Default path
 Stored on
 Time
 Simulation
The system only archives pendulum lists if the selection criteria under Logs for Pendulum List
Sales are within the selected interval.
also valid for other archiving objects. For more information, see the general archiving documentation
See also:
Displaying Archived Logs for Pendulum List Sales (SD-BIL-RB-PL)
Use
You can display individual logs for pendulum list sales from the archive. The table can be displayed
using the Archive Information System, for example.
Note
Features
To display archived logs for pendulum list sales using the Archive Information System , you need the
archive information structure BEV4/PL04_1 (logs for pendulum list sales), which has been created on
the basis of the SAP standard field catalog BEV4/PL04_1 (logs for pendulum list sales).
System .
Archiving Sales Activities (SD-CAS-SA)
Definition
Archiving object SD_VBKA for archiving sales activities.
Prerequisites
Before using the archiving object for the first time, you should check Application Customizing.
Structure
Tables
When you use the archiving object SD_VBKA, data is archived from the following tables:
Table Table name
NAST Message Status
VBFA Sales Document Flow
VBKA Sales Activities
VBPA Sales Document: Partner
VBUK Sales Document: Header Status and Administrative Data
VBU Sales Document: Incompletion Log

V
Programs
The following archiving programs are delivered with SD_VBKA:
Program Function
SDVBKAWR Write
SDVBKADL Delete
SDVBKARL Reload
You can use this archiving object with the SD_VBKA ILM object as part of SAP Information Lifecycle
the Information Retention Manager. You can also delete data that fulfills the prerequisites.
SAP ILM.
The following fields for SD_VBKA are defined in the ILM policy and are visible when processing ILM
End of Year (END_OF_YEAR)
 Date on Which Record Was Created (ERDAT)
 Sales Activity Type for Sales Support (KTAAR)
 Transaction Group (TRVOG)
 Sales Office (VKBUR)
Call
To call sales activity archiving, go to the Sales Support Screen Environment Archive Documents..

under Tools Administration Administration Archiving and enter object name SD_VBKA.
Integration
Sales activities can be archived independently of other SD documents.
More Information
Sales Activities in the DRB (SD-CAS-SA)
Variant Settings for Archiving (SD-CAS-SA)
Variant Settings for Reloading (SD-CAS-SA)
hecks (SD-CAS-SA)
The following checks are carried out on a sales activity before it can be archived:
 Residence time
 Sales activity end date

Residence time
The residence time is set per sales activity type.
The system first checks whether the residence time set in Customizing for the sales activity has been
exceeded. The residence time refers to the creation date of the document.
Sales Activity End Date
You can have the system check whether the sales activity has expired (sales activity end-date)
You can make this setting in Customizing for Sales and Distribution under Data Transfer and
Archiving Archiving Data .
Variant Settings for Archiving (SD-CAS-SA)
Use
You can set the archiving criteria in variant settings for archiving.
Features
The following options are available.
Entry Fields
Select the documents to be archived.
Checkboxes
 Create archive
Select this option, if you want to create archive files.
 Deletion program in test mode
If you do not want the archived data to be deleted automatically after the archive files have been
created, select this option.
This option is ignored if the Write archive has been deactivated.
 Issue log texts
Select this option if you need a detailed log.
 Check flow
Select this option if you want to check the document flow.
See also:
Checks (SD-CAS-SA)
Variant Settings for Reloading (SD-CAS-SA)
Use
You can set the reloading criteria in variant settings for reloading.
Features
The following options are available.
Entry Fields
Select the documents to be reloaded.
Checkboxes
 Test run
Select this option if you only want to simulate reloading, to check possible errors, for example.
 Issue log texts
If you need a detailed log, select this option.
See also:
Reloading an Archive
Application Customizing (SD-CAS-SA)
Use
In application Customizing, you can set the archiving requirements specific to sales activities.
Features
 Sales activity type
 Residence time (days)
sales activity type.
activity type, then you can enter the number of the check routine here.
Call
To call application Customizing, go to Customizing for Sales and Distribution and select Data Transfer
and Archiving Archiving data Archiving control for sales documents .
Alternatively, you can call application Customizing as follows:
1. Logistics Sales and Distribution Sales support.
2. Environment Archive documents
3. Customizing
4. Application-specific Customizing
See also:
Defining a Customer-specific Additional Check (SD-SLS)
Customizing
rchiving Agreements (SD-MD-AM)
Definition
Archiving object SD_AGREEM for archiving agreements and associated conditions in purchasing and
sales.
Use
The following agreements can be archived in sales:
 Rebate agreement
 Promotion
 Sales deal
The following agreements can be archived in Purchasing:
 Purchasing agreement
The associated data, such as conditions, indexes, and texts, is also archived.
Structure
When you use the archiving object SD_AGREEM, data is archived from the following tables:
Table Table name
EBOX Index of Settlement Documents for Subsequent Settlement (for purchasing

arrangements only)
EKBO Index of Docs. for Price Determ./Updating, Subsequent Sett. (for purchasing
arrangements only)
KONA Agreements
KONH Conditions (Header)
KONAIND Index: Groups of Conditions/Header Record Conditions

Table Table name
SDKONDARC SD Archiving of Conditions: Object Structure for Condition Tables

H
WAKHIND Promotion header data IS-R: index table for conditions
The archiving class CONDS is also archived:
Functionality
The following functionality is available for SD_AGREEM:
Functionality Report Status
Archive RV130005 Obsolete; do not use
Delete RV130006
Reload RV130007
Archive SD_AGREEM_ARCH_WRITE Current; use is recommended
Delete SD_AGREEM_ARCH_DELETE
You can use this archiving object with the ILM objectSD_AGREEM as part of SAP Information
Lifecycle Management. In order to do so, you must activate the associated business
function Information Lifecycle Management (ILM) (transaction SFW5). The system then also displays
the ILM Actions frame. You can use these actions to archive documents with the retention periods
defined in the Information Retention Manager. You can also make snapshots (copies) of data or
delete data that fulfills the prerequisites.
SAP ILM.
The following fields for SD_AGREEM are defined in the ILM policy and are visible when processing
ILM policies (transaction IRMPOL):
 End of Validity Period (END_OF_VALIDITY)

 Rebate Agreement Type (ABTYP)
 Agreement Type (BOART)
 Purchasing Organization (EKORG)
 Application (KAPPL)
 Division (SPART)
Call
To call agreement archiving, go to the Sales Master Data Screen and Agreements Archiving Create
Archive.
Alternatively, you can call archiving under Tools Administration and then Administration Data
Archiving and enter object name SD_AGREEM.
Integration
Associated conditions may have already been archived when the condition records were archived.
More Information
Related Information
Variant Settings for Archiving (SD-MD-AM)
Variant Settings for Reloading (SD-MD-AM)
Checks (SD-MD-AM)
The following checks are carried out on an agreement before it can be archived:
 Archiving Key Date
 Rebate Agreement - Sales
 Promotion
 Sales Deal
 Purchasing Arrangement
Archiving Key Date
Only agreements whose termination dates fall before the archiving key date are archived.
Rebate Agreement - Sales
Only fully settled rebate agreements are taken into account. The archiving key date is also
considered. Only fully settled agreements can be archived, otherwise settlement with the customer
would no longer be possible.
Promotion
With every promotion that is archived, all assigned sales deals are also archived. No key date check is
made for the assigned sales deals. The validity periods for a promotion and the assigned sales deals
are generally identical.
Sales Deal
Only sales deals that are not assigned to a promotion can be archived.
Purchasing Arrangement
Only fully settled purchasing agreements are taken into account. The archiving key date is also
considered. Only fully settled arrangements can be archived, otherwise settlement with the vendor
would no longer be possible.
Variant Settings for Archiving (SD-MD-AM)
Use
Caution
This information pertains to the obsolete archiving report RV130005. For information on variant
settings for the new SD_AGREEM_ARCH_WRITE report, see Variant Settings for Writing (SD-MD-AM).
You can set the archiving criteria in the variant settings for archiving.
Features
 Comment for archiving session
Enter text to identify your archiving sessions. If you delete or evaluate the data for the archives
created at a later point in time, the existing archives are listed and you can find the respective
archiving session again with the help of this text.
 Program selections
 Agreement
Select the agreements to be archived.
 Agreement type
Enter one or more agreement types to be archived.

 Agreements in Sales
 Sales organization, Distribution channel, Division
Restrict agreements by sales area (sales organization, distribution channel, and division).
 Rebate agreement - Sales, Promotion incl. assigned sales promotions, Sales

promotions without promo assignment
Choose which agreements to archive.
 Agreements in Purchasing
 Purchasing organization
Here you can restrict agreements by purchasing organization.
 Vendor agreement
Here you can choose whether vendor agreements are to be archived in purchasing.
Here you can restrict sales quotes by sales area (sales organization, distribution channel, and
division).
 Sales quote
If you are working with settlement requests and sales quotes (for example, agency business), you can
choose whether sales quotes are to be archived.
 Residence time
Here you can enter a residence time in days.
 Deadline
You can specify your own, alternative key date. In the standard system, the current date is proposed
automatically as the key date.
 Data for Document Creation
 Archiving as test run, no archive file will be created
Select this option if you do not want to create archive files.
 Run Delete Program in Test Mode Only
If you do not want the archived data to be deleted automatically after the archive files have been
created, select this option.
The system ignores this option if the option Archiving as test run, no archive file will be created is
deactivated.
 Create log for archiving session

Related Information
Checks (SD-MD-AM)
Variant Settings for Reloading (SD-MD-AM)
Use
Caution
This information pertains to the obsolete reloading report RV130007. For information on variant
settings for the new SD_AGREEM_ARCH_WRITE and SD_AGREEM_ARCH_DELETE reports, see Variant
Settings for Writing (SD-MD-AM) and Variant Settings for Deleting (SD-MD-AM).
Features
 Program selections
 Agreement
Select the agreements to be reloaded.
 Agreement type
Enter one or more agreement types to be reloaded.
 Agreements in Sales
 Rebate agreement - Sales, Promotion incl. assigned sales promotions, Sales

promotions without promo assignment
Choose which agreements to reload.
 Agreements in Purchasing
 Purch. organization
Here you can restrict agreements by purchasing organization.
 Vendor agreement
Here you can choose whether vendor agreements are to be reloaded in purchasing.
Here you can restrict sales quotes by sales area (sales organization, distribution channel, and
division).
 Sales quote
If you are working with settlement requests and sales quotes (for example, agency business), you can
choose whether sales quotes are to be reloaded.
 Parameters for the program flow
 Test run, data not reloaded
Select this option if you only want to simulate reloading, to check possible errors, for example.
 Enhance log with agreement data
Related Information
Reloading Archives
Variant Settings for Writing (SD-MD-AM)
Information for the SD_AGREEM_ARCH_WRITE report.
Use
When you schedule the write program you must either enter an already existing variant or create a
new one. The variant contains the selection criteria for the agreement master data you want to
archive.
Features
 Agreement
 Sales Agreements
Select to archive sales agreements.
 Purchasing Agreements
Select to archive purchasing agreements.
 Agreement
Select the agreements to be archived.
 Agreement type
Enter one or more agreement types to be archived.
 Restrictions
 Rebate Agreement - Sales, Promotion Incl. Assigned Sales Deals, Sales Deals
without Promotion Assignment
Choose which agreements to archive.

 Residence time
Here you can enter a residence time in days.
 Key Date
You can specify your own, alternative key date. In the standard system, the current date is proposed
automatically as the key date.
 Processing Options
Select to run the archiving write program in test mode (no actual archiving performed) or in
production mode (data is archived). In production mode, select Delete with Test Variant to run the
delete program associated with the archiving object in test mode, otherwise, the delete program will
also run in production mode.
 Detail Log
Specify whether to display the detail log and whether to include success messages in the log.
 Log Output
Select whether to write the log to a list, an application log, or both.
 Archiving Session Note
Describe the content archived during the archiving session.
Related Information
Variant Settings for Deleting (SD-MD-AM)
Variant Settings for Deleting (SD-MD-AM)
Information for the SD_AGREEM_ARCH_DELETE report.
Use
When you schedule the delete program you must either enter an already existing variant or create a
new one. The variant contains the selection criteria for the agreement master data you want to
delete.
Features
 Processing Options
Select to run the delete program in test mode (no actual deletion performed) or in production mode
(archived data is deleted).
 Detail Log
Specify whether to display the detail log and whether to include success messages in the log.
 Log Output
Select whether to write the log to a list, an application log, or both.
Related Information
Variant Settings for Writing (SD-MD-AM)
Archiving of Condition Records (SD-MD-CM)
You can use archiving object SD_COND to archive condition records.
Tables
SD_COND archives data from several tables. To check which tables these are, call up
transaction SARA, enter the archiving object, and choose Database Tables. You can display the
relevant tables in the lower part of the screen.
Archiving Classes
SD_COND may trigger further archiving classes to write additional data, for example change
documents, into the archive. To check which classes these are, call up transaction AOBJ, select your
archiving object and choose Archiving Classes Used.
Programs
To find out which programs this archiving object offers, call up transaction AOBJ and double-click on
your archiving object.
Prerequisites
Recommendation
Before using the archiving object for the first time, refer to chapter Performing Application-Specific
Configuration of this documentation.
The following prerequisites must be fulfilled before a condition record can be archived:
 The condition record must not be in use anymore.
 The deletion flag has been set for the condition.
 The residence time for the condition has been fulfilled.
You can find the available settings and more information about the archiving of condition records in
Customizing for Sales and Distribution under Data Transfer and Archiving Archiving Data Archiving
Control for Conditions.
You can use this archiving object with the SD_COND ILM object as part of SAP Information Lifecycle
Management. In transaction IRMPOL, you can create policies for residence or retention rules,
depending on the available policy category. Here you can also see the available time references and
which condition fields exist, and decide which of them shall be used in which order to define your
rule structure.
The following condition fields are available:
 Application (KAPPL)
 Condition Type (KSCHL)
 Usage of the Condition Table (KVEWE)
The following time references are available:
 End of Validity Period (END_OF_VALIDITY)
The following policy categories are available:
For more information, see the product assistance for SAP Information Lifecycle Management on SAP
Help Portal at https://help.sap.com/viewer/product/SAP_ERP. Choose your SAP ERP release, and
then Application Help SAP Library SAP ERP Cross-Application Functions Cross-Application
Components SAP Information Lifecycle Management.
Performing Application-Specific Configuration
Before you can use the SD_COND archiving object, you must first set the archiving requirements
specific for conditions in Customizing under Sales and Distribution Data Transfer and
Archiving Archiving data Archiving Control for Conditions.
Alternatively, you can call up application-specific Customizing as follows:
1. In transaction SARA, call up archiving object SD_COND.
3. Under Application-Specific Customizing, choose Archiving Conditions V_T681H.
The view V_T681H contains the definition of the residence time in days for each usage and
application. In addition to defining residence times, you can also select a limited document check to
determine whether documents still exist that refer to the conditions to be archived (table KONV).
Defining Write Variants
When you schedule the archiving run, you must enter an existing variant or create a new one. You
can do so in transaction SARA.
A write variant contains the parameters for the condition records that you want to archive.
You can call condition archiving from the SAP Easy Access Screen by choosing Logistics Sales and
Distribution Master Data Conditions Archiving Create Archive or by executing transaction VKA1.
Alternatively, you can call archiving using Tools Administration Administration Data Archiving and
enter object name SD_COND.
SAP delivers the write program SD_COND_ARCH_WRITE with SD_COND.
Features
The report SD_COND_ARCH_WRITE writes all conditions which fulfill the archivability requirements
from a range defined by the user in an archive system.
and continue at a later point. For more information, see Interrupting and Continuing Archiving
Sessions.
Selection
The report SD_COND_ARCH_WRITE gives you the options of restricting the range of conditions to be
archived by selecting the condition number, application, condition type and condition table number.
In addition to the criteria mentioned above, you can choose from the following options for selecting
the condition records to be archived:
 Validity End Before Ret. Time: Whether the deletion indicator is set for a condition record
plays no role in archiving. In this case, the system archives all records whose validity end date
is before the start of the residence time or corresponds to it, irrespective of whether the
deletion indicator is set.
 Deletion Flag Set: All records for which the deletion flag is set are taken into account during
archiving. The system archives all records for which a deletion flag has been set.
 Include Both Criteria: All records that fulfill one of the two criteria mentioned above will be
archived.
Integration
Once the conditions have been successfully written, you can remove archived conditions from the
database using the associated deletion report SD_COND_ARCH_DELETE.
The Customizing settings made in transaction AOBJ define whether this

report SD_COND_ARCH_WRITE triggers access of the associated deletion
report SD_COND_ARCH_DELETE. In other situations, the deletion report is started manually using
transaction SARA for archive files created by a write run..
Output
During write runs, the system writes a compact log with information about the processed data.
Alternatively, you can enable the output of a detailed log containing additional information. The
detailed log provides a list of records that cannot be archived according to the archivability check.
The system also displays the reason why it was unable to archive the condition record.
For more information, execute transaction SARA, enter the technical name of the archiving object,
and choose Goto Logs.
Defining Delete Variants
SAP delivers the delete program SD_COND_ARCH_DELETE with SD_COND.
Features
The report SD_COND_ARCH_DELETE physically deletes all conditions from a file that exists in the
archive system from the database.
Note
Existing condition indices are not deleted during archiving runs. To delete condition indices, use
report RV15F001.
Prerequisites
 Archive files which have been created with the write program SD_COND_ARCH_WRITE must
exist for the archiving object SD_COND.
Selection
You can choose to execute the program in Test Mode. Choosing this option means that there won't
be any changes to the database and no new archive files will be created.
If you choose to execute the program in Production Mode, the archived data will be deleted from
the database and the system will generate statistics about the table entries that were deleted.
Selecting the Detail Log option will display all data records which should be deleted from the
database.
Output
You can choose to display a standard or detailed log. The detailed log also lists all deleted conditions
in table format.
During delete runs, the system writes a compact log with information about the processed data.
Alternatively, you can enable the output of a detailed log containing additional information.
For more information, execute transaction SARA, enter the technical name of the archiving object,
and choose Goto Logs.
Integration
You can remove archived conditions that have been written to the database with the associated
report SD_COND_ARCH_WRITE using this report SD_COND_ARCH_DELETE.
The Customizing settings made in transaction AOBJ define whether the

report SD_COND_ARCH_DELETE is accessed automatically following access of the associated write
report SD_COND_ARCH_WRITE. In other situations, the deletion report is started manually for
archive files created by a write run using transaction SARA.
The deletion scope can be enhanced without making modifications using the integrated BAdI
exit ARC_SD_COND_DELETE in the report SD_COND_ARCH_WRITE to incorporate the enhanced
archiving scope of the associated write report SD_COND_ARCH_WRITE.
Defining Reloading Variants
You can use a reload variant to set the criteria based on which archived condition records are to be
reloaded into the database.
SAP delivers the reload program SD_COND_ARCH_RELOAD with SD_COND.
Features
You can use the report SD_COND_ARCH_RELOAD to reload archived condition records back into the
database. The reload program can be started manually using transaction SARA or transaction SE38.
Caution
The reload function should only be used if absolutely necessary, for example when the wrong data
was archived due to an error in Customizing or data selection.
Archived data should only be reloaded immediately after the incorrect archiving session. If changes
have been made to the database in the meantime, which means that the condition records to be
reloaded cannot be retrieved completely without time overlaps, processing is terminated for this
archiving object. The object is stored in a new archive file, and processing continues for the next
object.
Prerequisites
 Only archive files which have been created with the write
program SD_COND_ARCH_WRITE and physcially deleted with the deletion
program SD_COND_ARCH_DELETE can be reloaded into the database.
Selection
You can choose to execute the program in Test Mode. Choosing this option means that there won't
be any changes to the database and no new archive files will be created.
If you choose to execute the program in Production Mode, the data of the chosen archive sessions
will be inserted into the database according to your selection criteria and the archiving object-
specific checks. Data that could not be or was not reloaded is written to new archive files.
Selecting the Detail Log option will display all data records which should be reloaded into the
database.
Output
You can choose to display a standard or detailed log. The detailed log also lists all conditions to be
reloaded back into the database in table format.
Integration
You can reload archived conditions that have been written to the database with the associated
report SD_COND_ARCH_WRITE and deleted with the associated
report SD_COND_ARCH_DELETE using this report SD_COND_ARCH_RELOAD.
Authorizations for SD_COND
You need the following authorization objects:
Required Authorization
Activity Object
Generating conditions: use and application of the condition V_KONG_VWE

table
Enhancements for SD_COND
The SD_COND archiving object offers the following Business Add-Ins (BAdIs):
BAdI / User Exit Description Used to
ARC_SD_COND_CHECK Archiving Object You can use this BAdI to extend the
BAdI / User Exit Description Used to
SD_COND: Additional archivability check without modification.

Checks
ARC_SD_COND_WRITE Archiving Object You can use this BAdI to extend the archiving
SD_COND: Archive scope of SD_COND to include customer-
Additional Data specific tables without any modification.
For more information about implementing BAdIs in archiving programs, see SAP Note 673030 .
Displaying Condition Records Archived with SD_COND
 To find out the names of the infostructures and field catalogs, proceed as follows:
 Field catalog name: Within transaction SARA, choose Information

System Customizing Environment Field Catalogs.
 Infostructure name: Within transaction SARA, choose Information

System Customizing, then call up the selection help of the Archive
Infostructure field.
Additional Information
See also: SAP Note 838768 .
Related Information
Reloading Archives
SAP Information Lifecycle Management
Executing Data Archiving
Variant Settings for Writing (SD-MD-CM)
Use
The variant contains the selection criteria for the condition records that you want to archive.
Features
Conditions and Constraints
You can restrict the condition records to be archived in both the Conditions and Constraints frame in
accordance with the following criteria:
 Condition record no.
Number that uniquely identifies a condition record.
 Application
Subdivides the usage of a condition (for example, pricing) in individual subareas (for example, sales &
distribution or purchasing).
 Condition Type
Used for various functions. For example, it can be used to define different discounts in pricing,
different message types (such as order acknowledgements or delivery notes) in message
determination, or different search strategies in batch determination.
 Table
A combination of particular fields which form the key of a condition record.
Options
In addition to the criteria mentioned above, you can choose from the following options for selecting
the condition records to be archived:
 Validity End Before Ret. Time
Whether the deletion indicator is set for a condition record plays no role in archiving. In this case, the
system archives all records whose validity end date is before the start of the residence time or
corresponds to it, irrespective of whether the deletion indicator is set.
 Deletion flag set
All records for which the deletion flag is set are taken into account during archiving. The system
archives all records for which a deletion flag has been set.
 Include Both Criteria
With this option, all records are archived that fulfil one of the two criteria mentioned above.
Further Settings Options
In process control, the log options and the archiving run comment are settings options that also
apply to other archiving objects.
Administration Archiving Procedure Create Archive Files or Variant Maintenance for Archiving
Jobs.
See also:
Checks (SD-MD-CM)
Variant Settings for Reloading (SD-MD-CM)
Use
In the reload variant you can set the criteria based on which archived conditions records are to be
reloaded into the database.
Caution
The reload function should only be used if absolutely necessary, for example when the wrong data
was archived due to an error in Customizing or data selection. Archived data should therefore only
be reloaded immediately after the incorrect archiving session. If you reload later you run the risk of
data inconsistencies in your database.
Features
The processing control, log, and archiving session note options are also valid for other archiving
objects. Therefore, the information for these options is available in the general data archiving
documentation under Variant Maintenance for Archiving Jobs .
See also:
Reloading an Archive
Application-Specific Customizing (SD-MD-CM)
Use
In application-specific customizing, you can set the archiving requirements specific for conditions.
Before an archiving session can run successfully, you must make the necessary entry in application-
specific customizing. If this is not the case, the archiving session is terminated and you are requested
to make the necessary entry.
Features
 U (Use of condition table)
Determines the area in which the condition is to be used (currently only for pricing)
 App (Application)
Subdivides the use of a condition (e.g. pricing) into separate areas (e.g. sales and distribution or
purchasing)
 RetPer (Residence time)
You use these parameters to set the residence time for every combination of sales organization
and condition type.
 DocChk (Check against transaction data)
You can have the system check whether documents still exist that refer to the conditions to be
archived (table KONV).
Activities

choose Data Transfer and Archiving Archiving data Control archiving for conditions .
1. In the Sales Master Data Screen choose Conditions Archiving Create archive .
3. Under Application-specific customizing choose Archiving Conditions V_T681H.

This function is also available from within Archive Administration via Customizing Application-
Specific Customizing.
See also:
Customizing
Archiving Revenue Recognition Data with SD_VBREV
Use
Archiving revenue recognition data with the archiving object SD_VBREV
You can use the archiving object SD_VBREV to archive and delete revenue recognition data. The data
in the revenue tables refer to data from sales orders and billing documents (revenue recognition
data).
Prerequisites
Before you archive the revenue recognition data, you must first archive the associated sales
documents with the archiving objects SD_VBAK (except for revenue recognition category D).
Whenever you archive sales documents with the archiving object SD_VBAK, you must take the
following additional checks into consideration:
 Table VBUK (Sales Document: Header Status and Administrative Data) must not contain any
entries for the sales document to be archived where the revenue determination status is not
completely processed or not relevant (VBUK-RRSTA must be C or " ", so that the document
can be archived).
 Table VBREVC (Revenue Recognition: Worklist of Changed Sales Documents) must not
contain any entries for the sales document to be archived.
 Table VBREVK (Revenue Recognition: Control Lines) must not contain any entries for the
sales document to be archived where the revenue determination status is not completely
processed (VBREVK-RRSTA must be C so that the document can be archived).
Whenever you archive revenue recognition data with the archiving object SD_VBREV, you must take
the following additional checks into consideration:
 Table VBUK (Sales Document: Header Status and Administrative Data) must not contain any
entries for the sales document to be archived (revenue recognition categories A and B). This
is not relevant for revenue recognition category D.
 Table VBREVC (Revenue Recognition: Worklist of Changed Sales Documents) must not
contain any entries for the sales document to be archived (revenue recognition
categories A and B) or for the billing document to be archived (revenue recognition
category D).
 Table VBREVK (Revenue Recognition: Control Lines) must not contain any entries for the
sales document to be archived (revenue recognition categories A and B) or for the billing
document to be archived (revenue recognition category D) where the revenue determination
status is not completely processed (VBREVK-RRSTA must be C so that the revenue
recognition data can be archived).
Whenever you archive sales documents with the archiving object SD_VBRK, you must take the
following additional checks into consideration:
 Table VBREVR (Revenue Recognition: Reference Lines) must not contain any entries for the
billing document to be archived (revenue recognition category D) or for the predecessor
sales document (revenue recognition categories A and B)).
Tables
The following table shows the programs that exist for the archiving object SD_VBREV. (You define
archiving objects with transaction AOBJ).
Program Function
S3VBREVPTS Analysis (archivability check)
This report generates a log that shows which documents can be archived.
S3VBREVWR Write
S
S3VBREVDLS Delete
S3VBREVRL Reload
When you use the archiving object SD_VBREV, data is archived from the following tables
(transaction SARA):
Table Table Name
VBREVE Revenue Recognition: Revenue Recognition Lines
VBREVK Revenue Recognition: Control Lines
VBREVR Revenue Recognition: Reference Document Lines
You can use this archiving objects with the ILM objectSD_VBREV as part of SAP Information Lifecycle
Lifecycle Management (ILM) (transaction SFW5). The system than also displays the ILM
SAP ILM.
The following fields for SD_VBREV are defined in the ILM policy and are visible when processing ILM
The retention period for revenue recognition data archived with archiving object SD_VBREV begins
with the posting date of the record (this is the POSTING_DATE in ILM).
 Order Type (AUART)
 Company Code (BUKRS)
 Sales Document (VBELN)
Procedure
You can use the archiving object SD_VBREV (Revenue Recognition Tables: Write Program) to write
the revenue result table entries from the database to archive files.
To launch archive administration from the SAP Easy Access menu,

choose Tools Administration Administration Data Archiving and enter SD_VBREV as the object
name.
Enhancements for SD_VBREV
The following Business Add-Ins (BAdIs) are available for the archiving object SD_VBREV:
 ARC_SD_VBREV_CHECK
You can use this BAdI to check your own archivability criteria.
 ARC_SD_VBREV_WRITE
You can use this BAdI to write and delete data from additional custom tables.
For more information, use transaction se18 in the SAP system.
To use the archiving object SD_VBREV, you need the authorization object V_VBAK_AATSales
Document: Authorization for Sales Documents Types, which checks whether you are authorized to
process the relevant sales documents.
Displaying Archived Revenue Recognition Data

If you use an archive information structure (such as the standard archive information
structure SAP_SD_VBREV_01), you can read data from the archive.
For more information about archive information structures, see the application documentation for
data archiving under Data Archiving with Archive Development Kit (ADK) Archive Information
System Using the Archive Information System.
More Information
Archiving INTRASTAT Statistics Data with FT_VEIAV

Use
Archiving object FT_VEIAV for archiving INTRASTAT statistics data.
You can use archiving object FT_VEIAV (INTRASTAT Receipt/Dispatch) to archive, delete, and reload
the data written to database table VEIAV through the INTRASTAT selection runs.
Prerequisites
 There is no Application Customizing for this archiving object.
 An archivability check is not performed because table VEIAV is simply a temporary store for
creating INTRASTAT notification files and the data records it contains are not dependent on
other data objects.
Tables
The following table shows the programs that exist for the archiving object FT_VEIAV. (You define
archiving objects with transaction AOBJ). To display the programs used, use transaction AOBJ.
Program Function
RVEXAIWR Write
RVEXAIDL Delete
RVEXAIRL Reload
delete program.
You can use this archiving object with the ILM object FT_VEIAV as part of SAP Information Lifecycle
SAP ILM.
The following fields for FT_VEIAV are defined in the ILM policy and are visible when processing ILM
The retention period for INTRASTAT data archived with archiving object FT_VEIAV begins with the
creation date of the record (this is the CREATION_DATE in ILM).
 Reporting year of declaration to authorities (DATUMJAHR)
 Reporting month of declaration to authorities (DATUMMONA)
 Company Code (NUMMBUKRS)
 Sales Organization (VERKAUFOR))
 Declaration to authorities: Country of Plant (WERKSLAND)
Procedure
To call archive administration (transaction SARA) with archiving object FT_VEIAV from the SAP Easy
Access menu, choose Logistics Sales and Distribution Foreign Trade/Customs Periodic
Declarations Periodic Declarations Operative Archiving INTRASTAT.

under Tools Administration Administration Data Archiving and enter object name FT_VEIAV.
Choose Write. Define a variant for the archiving write run. The archiving write run imports all data in
accordance with the selection criteria chosen and writes this to one or more archive files without
further checks.
You can select the INTRASTAT data to be archived in accordance with the following criteria:
 Company code
 Reporting year
 Reporting month
 Declaration country
Choose Delete. Define a variant for the archiving delete run. The archiving delete run selects the file
generated in the write run and deletes the data for the validity periods to be archived.
Choose Goto Reload to access the reload program for FT_VEIAV . We recommend that archived
data be reloaded in exceptional cases only.
More Information
Archiving EXTRASTAT Statistics Data with FT_VEXAV
Use
Archiving object FT_VEXAV for archiving EXTRASTAT statistics data.
You can use archiving object FT_VEXAV (EXTRASTAT Receipt/Dispatch) to archive, delete, and reload
the data written to database table VEXAV through the EXTRASTAT selection runs.
Prerequisites
 There is no Application Customizing for this archiving object.
 The system does not perform an archivability check because table VEXAV is simply a
temporary store for creating EXTRASTAT notification files and the data records it contains are
not dependent on other data objects.
Tables
The following table shows the programs that exist for the archiving object FT_VEXAV (you define
archiving objects using transaction AOBJ). To display the programs used, use transaction AOBJ.
Program Function
RVEXAEWR Write
RVEXAEDL Delete
RVEXAERL Reload
delete program.
You can use this archiving object with the FT_VEXAV ILM object as part of SAP Information Lifecycle
SAP ILM.
The following fields for FT_VEXAV are defined in the ILM policy and are visible when processing ILM
The retention period for EXTRASTAT data archived with archiving object FT_VEXAV begins with the
creation date of the record (this is the CREATION_DATE in ILM).
 Reporting year of declaration to authorities (DATUMJAHR)
 Reporting month of declaration to authorities (DATUMMONA)
 Company Code (NUMMBUKRS)
 Sales Organization (VERKAUFOR)
 Declaration to authorities: Country of Plant (WERKSLAND)
Procedure
To call archive administration (transaction SARA) with archiving object FT_VEXAV from the SAP Easy
Access menu, choose Logistics Sales and Distribution Foreign Trade/Customs Periodic
Declarations Periodic Declarations Operative Archiving EXTRASTAT.

under Tools Administration Administration Data Archiving and enter object name FT_VEXAV.
Choose Write. Define a variant for the archiving write run. The archiving write run imports all data in
accordance with the selection criteria chosen and writes this to one or more archive files without
further checks.
You can select the EXTRASTAT data to be archived in accordance with the following criteria:
 Company code
 Reporting year
 Reporting month
 Declaration country
Choose Delete. Define a variant for the archiving delete run. The archiving delete run selects the file
generated in the write run and deletes the data for the validity periods to be archived.
Choose Goto Reload to access the reload program for FT_VEXAV . We recommend that archived
data be reloaded in exceptional cases only.
More Information
rchiving Customs Log Data with MM_PREF
Use
Archiving object MM_PREF for archiving customs log data.
You can use archiving object MM_PREF to archive and delete the logs written by the preference
determination programs.
Prerequisites
There is no Application Customizing for this archiving object. The system determines whether a data
record can be archived by comparing its time stamp with the date of parameter Archivable until on
the selection screen.
Tables
When you use the archiving object MM_PREF, data is archived from the following tables:
Table Table name
MMPREF_PRO_01 Logging table for archiving object MM_PREF
MMPREF_PRO_01_ Log table - Preference - Information from rules

B
MMPREF_PRO_02 Log table - Main component - Information
MMPREF_PRO_03 Log table - Component - Information
The following table shows the programs that exist for the archiving object MM_PREF. To display the
programs used, use transaction AOBJ.
Program Function
RMPREFW Write
R
Program Function
RMPREFDL Delete
delete program.
You can use this archiving object with the MM_PREF ILM object as part of SAP Information Lifecycle
SAP ILM.
The following fields for MM_PREF are defined in the ILM policy and are visible when processing ILM
Time at which log record was created (CREATION_DATE)
 Material number (MATNR)
 Plant (WERKS)
Procedure
To call archive administration (transaction SARA) with archiving object MM_PREF from the SAP Easy
Access menu, choose Logistics Sales and Distribution Foreign
Trade/Customs Preference Preference Processing Archiving Archive Administration.

under Tools Administration Administration Data Archiving and enter object name MM_PREF.
Write
You can select the customs logs to be archived in both the Preference f. and Constraints frame in
accordance with the following criteria:
 Material
 Plant
 Archiving until date
To display the customs logs from the SAP Easy Access menu, choose Logistics Sales and
Distribution Foreign Trade/Customs Preference Preference Processing Customs Log. You can also
display archived customs logs.
For more information about archive information structures, see the application documentation for
data archiving under Data Archiving with Archive Development Kit (ADK) Archive Information
System Using the Archive Information System.
More Information
Archiving Customer Master Data (FI-AR, SD)
Definition
Archiving object FI_ACCRECV is used to archive and delete customer master data in the Financial
Accounting (FI) and Sales and Distribution (SD) components.
Use
Customer master data is stored and archived in three different areas, as follows:
 General data
 FI data (for a specific company code)
 SD data (for a specific sales organization)
The term customer master data is used in both the FI and SD components.
To archive master data, you must set the deletion flag in the master record. You can set this flag for a
complete customer or for individual company codes and sales organizations.
For more information about how to set the deletion flag, see the following:
 Archiving and Deleting a Customer Master Record
 Application Customizing (FI-AR, SD)
In addition to the deletion flag, a series of other prerequisites must be met so that you can archive
customer master data. For more information about the checks performed by the system during
archiving, see Checks (FI-AR, SD).
Calling the Archiving Function
You can archive customer master data on the SAP Easy Access screen
under Tools → Administration → Administration → Data Archiving.
Structure
Tables
Archiving object FI_ACCRECV is used to archive data from different tables. For more information
about how to display the table names for individual archiving objects, see Tables and Archiving
Objects.
The following table shows the reports available:
Function Report
Write FI_ACCRECV_WR
I
Delete FI_ACCRECV_DEL
Integration
You can use archiving object AM_ASSET in Information Lifecycle Management. You must have
activated the corresponding business functions to do this. The system then also shows the ILM
Actions group box. You can use these actions to carry out archiving, for example, where the retention
periods stored in the Information Retention Manager can be evaluated. Additionally, you can create
snapshots (copies) of data or destroy data that matches the requirements. For more information,
see Activating SAP ILM.
Displaying Archived Customer Master Data
To display individual documents for archiving object FI_ACCRECV using the Archive Information
System, you require an information structure that has been created based on one of the following
standard SAP field catalogs:
 SAP_FI_ACCREC_1 (FI customer master data)
 SAP_FI_ACCREC_2 (SD customer master data)
Each information structure must be active and configured correctly.
For more information about information structures, see Using the Archive Information System.
Related Information
Archive Information System
Checks (FI-AR , SD)
In order for the system to only archive data that is no longer needed in current business processes,
this data must meet certain conditions. To make sure that the data to be archived meets these
conditions, the write program performs several checks.
Master data is only eligible for archiving if you have set the deletion flag in the master record in each
area.
When you archive general data for customer master records, the system automatically checks
whether the following conditions have been met:
 The deletion flag is set.
 The vendor (that is, the supplier) is not locked for deletion.
 Dependent data of the following types no longer exists in the system:
 Business partner of the customer
 Plants of the customer
 Customer / vendor links
 Company code-specific data (Financial Accounting (FI) data)
 Sales data (Sales and Distribution (SD) data)
Additional checks may be implemented in your system using BAdI FI_ACCRECV_CHECK.
When you archive FI data for customer master records, the system automatically checks whether the
following conditions have been met:
 The vendor is not locked for deletion.
 Transaction figures
 Special general ledger transaction figures
 Open items
 Cleared items
 Store items
 Customer / vendor links
 Parked documents
Additional checks may be implemented in your system using BAdI FI_ACCRECV_CHECK_FI.
When you archive SD data for customer master records, the system automatically checks whether
the following conditions have been met:
 Customer hierarchies
 Partner functions
Additional checks may be implemented in your system using BAdI FI_ACCRECV_CHECK_SD.
Related Information
Customer Hierarchies
Partner Functions
Application Customizing (FI-AR, SD)
Use
You can set the deletion indicator for a customer in application Customizing.
Activities
You have the following options for accessing application Customizing:
 To access archive management on the SAP Easy Access screen,

choose Tools Administration Administration Data Archiving. Enter as object
name FI_ACCRECV. Choose Customizing and then Application-Specific Customizing.
 To access archive management on the SAP Easy Access screen under Sales and Distribution,
choose Logistics Sales and Distribution Master Data Business Partner Customer
Archiving. Then choose Customizing and then Application-Specific Customizing.
 To access archive management on the SAP Easy Access screen under Financial Accounting,
choose Accounting Financial Accounting Accounts Receivable Periodic
Processing Archiving Customers. Then choose Customizing and then Application-Specific
Customizing.
Related Information
Archiving Customer Master Data (FI-AR, SD)
ariant Settings for Writing (FI-AR, SD)
Use
When you schedule the write program, you must either enter an already existing variant or create a
new one. The variant contains the selection criteria for the customer master data you want to
archive.
Features
In the Data To Be Archived dropdown list box, you can choose the areas from which you want to
archive master data. You can choose from the following areas:
 General Data
The system archives only general data (not chart of account-specific).
 FI Data
The system archives only company code-specific master data.
 SD Data
The system archives only sales organization-specific master data.
In the Customer Master Data, you can choose the following selection criteria:
 Vendor
The system archives only the master data of accounts that fall within the range covered by the
selection criteria you enter.
 Company Code
The system archives only the master data of company codes that fall within the range covered by the
This selection option is only offered if you are archiving FI data.
 Purchasing Organization
The system archives only the master data of accounts that fall within the range covered by the
This selection option is only offered if you are archiving MM data.
Additional Selections and Options
In the Selections frame you can make the following setting:
 Minimum Number of Days in the System
This function is identical for customers and vendors. For a detailed description of this option,
see Variant Settings for Writing (FI-AP) in the section on vendors.
In the Options frame, you can make the following settings:
 FI Link Validation Off
This function is identical for customers and vendors. For a detailed description of this option,
 SD Document Validation Off
If this flag is set, the system does not check in SD whether sales documents still exist for the master
record that is to be archived. This check generates long runtimes and may not always be necessary.
You can therefore switch off this check and herewith reduce the runtime of the write program. In the
standard system, this check is always switched on.
This option is only relevant if you are archiving SD data.
 Take Deletion Flag Into Account
This function is identical for customers and vendors. For a detailed description of this option
Additional Settings
The settings you make under Processing Options, for Log Settings, and Archiving Session Note are
standard settings that are also valid for other archiving objects. They are therefore described in the
general archiving documentation under Variant Maintenance for Archiving Jobs.
Related Information
LM-related Information for FI_ACCRECV

Use
To create and use policies and rules for the archiving object FI_ACCRECV in Retention
Management of ILM, an ILM object is available. FI_ACCRECV is the ILM object associated with the
archiving object FI_ACCRECV.
For more information, see Archiving Customer Master Data (FI-AR, SD)
Prerequisites
 You have activated the business function Activating SAP ILM (ILM).
For more information, see Activating SAP ILM
 You have activated the business function ILM-Based Deletion of Customer and Vendor
Master Data (ERP_CVP_ILM_1).
Features
Condition Fields and Time References
To define retention rules using ILM policies (transaction IRMPOL), you can use the following
condition fields and time references (start time for determining the retention duration) for the ILM
object.
Condition Fields
Condition Fields Description
APPL_NAME Application Name
APPL_RULE_VARIANT Application Rule Variant
KTOKD Customer Account Group
BUKRS Company Code
VKORG Sales Organization
BS_COUNTRY_OF_BUKRS Country of Company Code
WERKS Plant Table for National (Centrally Agreed) Contracts
Time Reference
Start Retention Time Description

Condition Fields
Condition Fields Description
START_RET_DATE Start Date of Retention
END_OF_FISCAL_YEAR End of Fiscal Year
END_OF_YEAR End of Year
Object Category and Policy Category
You define policies for FI_ACCRECV in the BOR object category (data BUS1007) with the Retention
Rules policy category RST and RTP.
Archiving Object CPE_PRQUOT
Definition
CPE_PRQUOT is used to write price quotation data from the Price Quotation table CPED_PRICEQUOT
to the archive.
Use
You can set the residence timefor price quotations in Customizing under Integration with Other
mySAP.com Components Customer Relationship Management Basic Functions Commodity
Pricing Commodity Pricing Engine Definition of CPE Quotations Define Quotation Name .
The business units using the CPE function define the residence time. Price quotations must not be
archived if there are still references to open sales documents. For example, if the oldest open sales
contract still uses price quotations from last year, you can only archive price quotations from two
years ago. There is no technical tool to check whether or not a price quotation is still in use.
All steps are triggered when you carry out the relevant reports in the Archive Development Kit. To do
this, on the SAP Easy Access screen, choose Tools Administration Administration Data Archiving .
You can also run these reports in the background. To check subsequent changes or problems, use the
application log (on the SAP Easy Access screen, choose Tools Business
Workflow Development Utilities Application Log Application Log: Display Logs ).
Run the CPE_ARC_PRICEQUOT_SAVE report in test mode to check which price quotations will be
archived in the system. If you run the same report in production mode, it will actually archive price
quotation data to data files.
To display archived data, run the CPE_ARC_PRICEQUOT_READ program. Alternatively, you can
activate the SAP_PRICE_QUOT archive infostructure to enable reading of data from archive files
(onthe SAP Easy Access screen, choose Logistics Agency Business Environment Archive Display) .
See also:
Archiving Object
Structure
Archiving object CPE_PRQUOT has the following archiving programs:
Program Name Function
CPE_ARC_PRICEQUOT_SAVE Check program
CPE_ARC_PRICEQUOT_SAVE Write program
CPE_ARC_PRICEQUOT_DELETE Delete program
CPE_ARC_PRICEQUOT_READ Read program
Note
You can run the CPE_ARC_PRICEQUOT_SAVE report program in test mode to check the data.
See also:
Archiving of Price Quotations
Archiving of Price Quotations
Use
You can remove price quotation data that is no longer required from the database and store it in
archive files. This reduces the volume of data and improves performance.
To start archiving of price quotations, chooseon the SAP Easy Access

screen Tools Administration Administration Data Archiving and fill in the archiving object
( CPE_PRQUOT). Before using the archiving object, you should maintain the application-specific
Customizing .
Prerequisites
You must have enabled commodity pricing engine functionality and have used price quotation data
to compute the prices of commodities.
Note
You have to ensure that the price quotations in the ERP system and in SAP CRM are archived at the
same time. If not, the data exchange might recreate the entries you have already archived in one
system.
You must have entered residence times for price quotations in Customizing under Integration with
Other mySAP.com Components Customer Relationship Management Basic Functions Commodity
Pricing Commodity Pricing Engine Definition of CPE Quotations Define Quotation Name. Only
price quotations with valid residence times will be considered for archiving.
Archiving Checklist
Use
This checklist helps to ensure that you complete the necessary archiving steps and that you perform
them in the correct order.
Procedure
Before the first archiving session
1. In Basis Customizing, check that the logical file names are entered.
2. In cross-archiving object Customizing, check that the Central Repository for storage is
maintained using the SAP Content Management Infrastructure.
3. In application-specific Customizing, check that the residence times are defined.
Before using an archiving object for the first time
Check archiving object-specific Customizing settings:
 Was the file name correctly assigned?
 Are the deletion program variants maintained? (Note that the variants are client-specific)
 Is the maximum archive file size correctly set?
 Is the delete program set to run automatically?
 Is index creation scheduled?
For each archiving session
1. Ensure that the user department and system administration coordinate their activities.
2. Check the network graphic to determine whether interdependencies exist (do other data
objects have to be archived first?)
3. Schedule the archiving session (create variant).
4. If the delete program does not start automatically, start it manually.
5. If the archive files are not to be stored automatically by the Content Management
Infrastructure,, trigger storage manually.

Data Archiving in Sales and Distribution

Uploaded by

Copyright:

Available Formats

Data Archiving in Sales and Distribution

Uploaded by

Document Information

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

Data Archiving in Sales and Distribution

Uploaded by

Copyright:

Available Formats

Data Archiving in Sales and Distribution (SD)

The following table shows the available archiving objects:

Objects in Sales and Distribution Archiving object

Sales documents SD_VBAK

Billing documents SD_VBRK

Sales activities SD_VBKA

Agreements and associated conditions SD_AGREEM

Revenue recognition data SD_VBREV

INTRASTAT statistics data FT_VEIAV

EXTRASTAT statistics data FT_VEXAV

Customs log data MM_PREF

Customer master data FI_ACCRECV

Pendulum List Indirect Sales

Request data /BEV4/PL01

Converted request table with declaration period /BEV4/PL02

Request table with declaration period /BEV4/PL03

Logs sales pendulum list /BEV4/PL04

Objects in Sales and Distribution Archiving object

Archiving monthly empties stock BEV1_EMBD

Archiving empties update BEV1_EMFD

Business Partner End of Purpose (EoP) Check in Sales and Distribution

Application Name Application Business Partner Type

ERP_SD Sales & Distribution Customer, vendor/supplier, and contact person

 SD_AGREEM (Rebate agreements and associated conditions)

 SD_VBAK (Sales documents)

 SD_VBRK (Billing documents)

EoP Check Implementation

 Agreements of various types (KONA)

 Deliveries (LIKP and VBPA)

 Sales documents (VBAK and VBPA)

 Sales activities (VBKA and VBPA)

 Billing documents (VBRK and VBPA)

 One-time customers (that is, a CpD customer)

 The following table explains when end of business is reached:

Area End of Business Determination

Delivery The delivery (table LIKP) is completely processed or not relevant.

Sales The sales document (table VBAK) is completely processed or not

Billing The billing document (table VBRK) is completely processed or not

Area Start of Retention

Agreements The creation date of the agreement or condition (table KONA;

Delivery Creation date of delivery document header or item

Sales Creation or change date of sales document header or item

Billing Billing date (field VBRK-FKDAT)

One-time End of residence for partner

Initial Load Reports

Report Name Use To Be Affected Data

Handling of Archived Data

The application does not consider archived data.

Application Application Description Business Partner

ERP_SD_BIL_RA SD Integration for Revenue Accounting and Customer

EoP Check Implementation

 All RAIs with relation to a specific customer must be in status processed.

 Latest contract completion date for active accounting principle/company code

 End Date of Usage for inactive accounting principle/company code combinations

Initial Load Reports

 https://help.sap.com/viewer/product/SAP_ERP SAP Library SAP ERP Cross-Application

 https://help.sap.com/viewer/product/SAP_ERP SAP Library SAP ERP Cross-Application

 SAP Note 2798400

 Customizing for Cross-Application Components under Data Protection

Application-Specific Features (SD)