BI Portal - Processing Delta Records in Accounts Payable

1 of 2

http://www.biportal.org/sap_bi_blog/9403

Processing Delta Records in Accounts Payable

14 Feb 2008 11:53 AM | Sergei Peleshuk

When scheduling delta runs in the process chains one has to pay attention to job dependencies and
sequence of processes in the chain. It may be critical that certain records are loaded prior to other ones,
and, in some cases, simultaneous delta extraction is required. This article gives an example of a business
case when delta extractions from source system and further processing are dependent on each other, and
discusses ways how to address complex data load and scheduling issues in BW.

1. Dependency between AP and FIGL data loads

When we process Accounts payable data in BW we have to apply certain business logic at each processing
step in order to deliver on particular reporting requirements. Let us assume we extract data from R/3 using
standard extractors 0FI_AP_4 and 0FI_GL_4.
Another assumption is that first level DataStore objects (AP lines, FIGL Lines) contain all details delivered
from R/3. When we move data to the infocubes we have to apply certain filters and look up for values that
are delivered with another extractor:

The business logic in this model implies that AP lines have to be split over corresponding FIGL lines in order
to provide a profit center breakdown. Matching documents are looked up by document number, company
code and fiscal year. On the other hand, FIGL lines need to look up for vendor details (vendor codes and
other relevant details) in the corresponding AP documents. Depending on whether the vendor code is found
in the corresponding AP document the FIGL line either gets filtered out or an appropriate vendor code is
assigned.
When these filters are properly applied the AP_C02 and AP_GLC infocubes contain records relevant for
financial reporting, and particularly Accounts Payable reporting.

2. Challenges with data load Sequence

When processing AP delta lines we look up for values in the corresponding FIGL documents. In the
production environment we usually get hundreds of AP and GL lines generated every second. The extractors
delivering records from R/3 bring those delta records that are sitting in the delta queue at the time of
extraction. It is obvious we cannot guarantee that extractions would start at exactly the same moment for
both AP and FIGL lines.
Therefore, it becomes extremely important that all relevant delta records for FIGL are delivered to BW
before AP lines are processed. We may be able to ensure this by first loading AP delta from R/3 and then
subsequently FIGL delta records. This approach guarantees that all AP delta records we extract will
definitely have corresponding FIGL records extracted further on in the process chain.
However, we are facing another challenge here with such approach: the delta records delivered from FIGL
will not necessarily have matching AP records as they were extracted later. And our data model assumes
that we are supposed to have all relevant AP records for FIGL data processing. The main reason is that for
each FIGL document we need to look up a vendor code from a corresponding AP document. If AP delta
records are extracted from R/3 earlier than FIGL delta records we may face a situation when not all relevant
AP entries are available for the lookups at the point of FIGL delta processing.

10/29/2016 11:34 PM

BI Portal - Processing Delta Records in Accounts Payable

2 of 2

http://www.biportal.org/sap_bi_blog/9403

each FIGL document we need to look up a vendor code from a corresponding AP document. If AP delta
records are extracted from R/3 earlier than FIGL delta records we may face a situation when not all relevant
AP entries are available for the lookups at the point of FIGL delta processing.

3. How to implement the right processing sequence

So how do we tackle this sort of data processing issue, when several extractors have to deliver identical
data sets with deltas? The way to solve it would be by using a pseudo delta approach. While we process
AP records in the traditional delta mode, further processing of FIGL records can be done using so called
pseudo deltas or full refreshes for current and previous fiscal periods. This is possible for FIGL records
because we can be sure that with every delta run we are getting records from current and last fiscal periods
only. If the fiscal period is closed we do not get FIGL records extracted from R/3.
The sequence of the processing steps will be as follows:
1. Load AP lines delta records to the first level DSO (AP lines)
2. Load FIGL delta to the first level DSO (FIGL lines)
3. Run further processing of AP delta records from AP Lines DSO to the cube AP_C02
4. Run pseudo delta (2 full requests) from FIGL lines DSO to the cube AP_GLC for current and
previous fiscal periods
5. Delete overlapping full requests from the AP_GLC cube.
With such approach we guarantee that when processing AP delta records we have all corresponding FIGL
records available for the lookup. At the same time, when processing FIGL records we refresh Full requests
for current and previous periods. Therefore, all FIGL records that had AP data missing will be reprocessed
later and populated to the cube with the proper vendor codes.

Related Topics:
Architectural Tips
Automate data loads

Add comment

Comments
04 Sep 2008 3:11 AM | SATYA VENKATA

very good explanation thanks a lot sergei

Link Reply
09 Sep 2008 7:14 PM | Sergei Peleshuk

thanks for your feedback Venkata!

Link Reply
17 May 2010 4:38 PM | Deleted user

Great solution.
Thanks Sergei.

10/29/2016 11:34 PM