CO Delta Extraction

With delta extraction, only the data that has changed since the last extraction is loaded into the
BW. Data that has already been loaded and has not changed is not extracted and does not need
to be deleted before a new load. This improves performance compared with periodic extraction of
the entire dataset.

Determining the Delta Dataset

Delta datasets are determined by the selection of CO line items. This is done using the time
stamp (COEP-TIMEST). The time stamp specifies the starting time for determining the delta
dataset. SAP R/3 always logs two time stamps at once. These time stamps delimit a selection
interval for each DataSource (dataset in SAP R/3 or another source system) and each update
mode.
The following update modes are used:
Update Mode

Explanation

Delta init

Determines the beginning inventory; can be run multiple times for

each DataSource with enhanced selection criteria.

Delta update

Determines and loads the delta dataset.

Full update

Determines and loads the entire dataset. You need to delete the
data in the BW before reloading.

The time required to update a line item restricts the timeliness of the data in the delta update and
delta init modes.
SAP R/3 requires a certain amount of time to update line items. Since the time stamp is set when
the update begins rather than when it is completed, there may be a lag between the time stamp
and the actual time of the update event. Because of this lag, some line items may not yet be
updated to the database even though their time stamp is within your selection conditions.
Consequently, they cannot be selected when you create a delta dataset and are not loaded into
the BW.

By specifying a safety time (the time during which line items can be safely updated), you can
ensure that line items are extracted and loaded into the BW despite the lag between the time
stamp and the update event. Two hours is the standard value for the safety time.

You should only reduce the standard value for the safety time if you are sure that
your system can update all line items safely within the new safety time.
You can define the safety time using the BWOM2_V_SAFETY view in the OLTP system as
follows:
You can use different safety times in minutes for each DataSource.
A safety time that does not refer to a DataSource applies to all DataSources for which you
have not made a special entry.

A database index (index 4) is provided for the COEP CO line item table via the time stamp
(COEP-TIMEST). This time stamp is not active in the standard system. In case of performance
problems, you can improve data extraction performance by activating index 4.

COEP line items cannot be changed after they have been created, except for the
document text. If the document text is changed in SAP R/3, the COEP-TIMESTMP
field is not updated. For this reason, changed document texts cannot be transferred
to the BW using delta extraction.
In full update mode, the system cannot select any CO line items based on the time stamp. All line
items that are appropriate for the DataSource and that were selected in the InfoPackage are
transferred to the BW. A subsequent delta update is not possible, as the system does not log a
time stamp.
With commitments, the line items are not simply generated once and then never changed (as with
the costs), but are changed on a continuing basis as the commitment is reduced. For this reason
it is not sufficient to extract just the new records to the BW. Instead, all changed records must be
extracted and the delta against the previously extracted version of each record must be
determined. This delta determination takes place in the ODS objects in the BW. In delta mode,
therefore, the commitments extractors extract all line items that have changed since the last
delta; these line items are extracted in their changed form (after-image). For this reason,
commitments line items can only be analyzed through the use of ODS objects.
Deleted records are a special case. If records are deleted in R/3, they are not extracted. For this
reason, the records are not deleted in the BW. To solve this problem, after the first delta init is
executed all deleted commitments line items are written to a special R/3 table (COOI_PI), and
this table is extracted as well.

Reducing the Fields in the Transfer Structure

You can define a transfer structure in the BW for each InfoSource and source system. The
transfer structure contains the fields you selected by means of transfer rules to load the
corresponding data into the BW.
The transfer structure in the BW corresponds to the extract structure in SAP R/3 or another
source system. The extract structure contains the maximum possible number of fields for which
you can extract data from a source system and load the data into the BW.

To improve performance and minimize the transfer time from the source
system into the BW:
Decide which fields in the extract structure you require for your
reports.
Add only those fields to the transfer structure.
If the standard transfer structures and InfoSources do not meet your
requirements, copy them and then modify them as needed. All delta-update-

compatible DataSources are intended as a basis for defining your own

InfoSources.
If you only want to display aggregated data, do not add the fields document
number, posting row, or document row text to your transfer structure.

Loading Actual and Planning Data into the Same InfoCube

You can load actual and planning data into the same InfoCube. You combine data from
InfoSources that are compatible with delta updates, and with InfoSources that are compatible
with full updates.
SAP provides InfoSources for actual data. These InfoSources contain delta datasets and are thus
compatible for delta updates. Only a full update is possible for the following data:
Plan values
Down payments
Overall plan values
Variances
Accrual calculations

If you load actual and plan data into the same InfoCube, you need to
restrict the value type (0VTYPE) when you create an InfoPackage in the
InfoSources that are compatible with full updates. This prevents actual data
from being loaded from these InfoSources, which would result in the actual
data being duplicated in the InfoCube.
You can load the actual data from the InfoSources that are compatible with
the delta update. This enables you to avoid deleting actual data that already
exists in the BW.
If you want to load actual and plan data into different InfoCubes (for
example, actual data into one InfoCube and plan data into another), you
need to restrict the value type (0VTYPE) in the update rules.
InfoSources that are compatible with the delta update have a larger number
of characteristics. For this reason, they provide more detailed information for
the Actual value type than the InfoSources that are compatible with full
updates.
The additional characteristics provided by the InfoSources compatible with
delta updates (such as the material number) are not filled by the system for
planning values in the InfoCube.