The need for SAP ERP Central Component (SAP ECC) partner functions in SAP NetWeaver BW arises when there is a business reporting requirement to identify the concerned people or companies involved on the sales document line. It can be a quote, inquiry, sales order, or contract. An additional complexity is to provide only the sales documents needed by affected people or an organizational hierarchy.

As of version 6.0 of SAP NetWeaver BW with Support Package 17, there is no Business Content delta extractor available to pull the partner functions from a sales document in SAP ECC. Through a generic data source based on a view of partner functions table VBPA, you can obtain partner function data via full loads to SAP NetWeaver BW. However, doing daily full loads on table VBPA is not a sustainable approach. It requires large data loads with an ever increasing sales volume. Also, the partner functions in SAP ECC are designed such that if a partner function on a sales document line doesn’t exist in table VBPA, the presentation logic in SAP ECC substitutes a partner from the sales document header. It then appears to the user as if the header level partner exists on the sales document line. This is significant because you can’t perform the substitution logic at run time due to performance reasons, so you have to build that information in the extraction and loading time.

Behind the scenes, table VBPA contains partner functions of the header and the partner function at the sales document line only if a user overwrites the partner function at the sales document line. You can use the approach I developed to design a pseudo delta extraction mechanism and derive the partners at the sales document line from the header if a partner function doesn’t exist at the sales document line.

The Process: End-to-end Data Flow

Let’s look at the process to build a data source that facilitates a delta mechanism of sales document partner functions. Using transaction RSA1, build standard DataStore (DSO) object (DSO) ZSD_O17 with the sales document, document item, and partner function as the primary keys. Then add the rest of the table VBPA data fields that you are interested in as data fields to the DSO. In my example I use 0CUSTOMER, 0DOC_DATE, 0DOC_CATEG, 0SALESORG, 0CREATEDON, 0DOC_TYPE, 0HG_LV_ITEM, 0PERSON, and 0BPARTNER.

Next, using transaction RSA1, create InfoSource Z_IS_PF with the respective data fields from DSO ZSD_O17 and the fields that are in scope depending on the need for InfoPackage selections. For example, in my case I select sales document, document category, document type, document date, and created on date. Create data source Z_DS_PF in SAP ECC based on the view this brings in the initial load from SAP ECC to SAP NetWeaver BW. Create a second data source in SAP ECC for Z_DS_PF_DLTA based on a function module that brings the daily delta from SAP ECC to SAP NetWeaver BW. I provide details on the data source logic later in the article.

Figure 1 shows the data source on the right side (Z_DS_PF), which brings the full partner functions. The data source on the left side (Z_DS_PF_DLTA) brings changes, new records, and deletions from the last successful execution date to the current execution date. The delta logic is driven by change pointer tables CDHDR and CDPOS in SAP ECC.

Figure 1

Data source Z_DS_PF brings the initial full loads and data source Z_DS_PF_DLTA brings the daily delta loads

Step 1. Design the Initial Load

Create a database view called ZBW_PF containing sales document header VBAK and line table VBAP in SAP ECC using transaction SE11 (Figure 2). Click the Table/Join Conditions tab to view join conditions. You can’t join partner function table VBPA in this view because not all the sales document lines have partner functions. In these cases, SAP ECC replaces the line item partner functions from the header partner functions in the presentation layer. However, there won’t be any partner function records for those respective lines at the database level (table VBPA).

Figure 2

View definitions in SAP ECC for join conditions

Click the View Flds tab (Figure 3) to select the fields from the underlying view tables.

Figure 3

Various fields supplied by SAP for the database view

Next, create a generic data source for the view ZBW_PF using transaction RSO2 (Figure 4). This generic data source is used to do a one-time initial full load.

Figure 4

Generic data source Z_DS_PF on view ZBW_PF

The SAP system automatically generates an extractor structure (in my example, ZOXCR20022). From there, enhance ZOXCR20022 using transaction SE11 to add partner function PARVW, customer KUNNR, number of contact person PARNR, and personal number PERNR (Figure 5).

Figure 5

System generated extract structure ZOXCR20022 enhanced with partner function, customer, contact person, and personnel number

Now use transaction RSA6 to change the settings on the data source to allow the info-package selections for data loading based on your needs and requirements (Figure 6). The ZZ fields only get populated in the user exit at run time, so deselect the new ZZ fields from the Hide field and Field only columns. Check the necessary boxes for data load selection under the Selection column. In this case I mark Sales Document Type, Document Date, Date on which the record was created, Sales Document, SD document category, and Sales Organization.

Figure 6

Data source settings and selections

Figure 6 Then write the user exit code to populate the ZZKUNNR, ZZPARNR, ZZPARVW, ZZPERNR fields — these are the partner function fields you need to derive in the user exit. In the code, include custom substitution logic to replicate the partners from the header in the event no partner exists for that partner function at the sales document line. Modify user exit ZXRSAU01 in SAP ECC using transaction SE38 to include a subroutine pool call to ZBW_Z_DS_PF. Do this by adding the code shown in Figure 7.

Figure 7

SAP ECC transactional data source user exit call to ZBW_Z_DS_PF

Next, add the code, which is available by clicking this link, to the subroutine, using transaction code SE38. You have to replace the structure zoxcr20022 with your own system-generated structure name.

Map data source Z_DS_PF to InfoSource Z_IS_PF and map InfoObjects. In the following a list, which shows mapping from SAP ECC to SAP BI, the data source fields are on the right and InfoObjects are on the left:

0DOC_NUMBER      =          VBELN

0S_ORD_ITEM         =          POSNR

0DOC_CATEG         =          VBTYP

0DOC_DATE            =          AUDAT

0HG_LV_ITEM         =          UEPOS

0DOC_TYPE            =          AUART

0CREATEDON         =          ERDAT

0SALESORG            =          VKORG

ZPTRFUNC               =          ZZPARVW

0CUSTOMER            =          ZZKUNNR

0BPARTNER             =          ZZPARNR

0PERSON                 =          ZZPERNR

Map InfoSource Z_IS_PF to DSO ZSD_O17 with the overwrite option in the update rules. To load the initial data, create a full repair InfoPackage, then load and activate the data in DSO ZSD_O17. If the initial volume is high, you can use document ranges to break down the loads in parallel for faster completion. 

Step 2. Design for Delta Load

Create structure ZBW_DS_PF_DLTA in SAP ECC using transaction SE11 with the fields you are interested in bringing to SAP NetWeaver BW for partner functions. In my example, I select the fields shown in Figure 8 based on previously described business requirements.

Figure 8

Define the structure using transaction code SE11 in SAP ECC

Next, using transaction code RSO2, create a custom data source called Z_DS_PF_DLTA in SAP ECC based on the function module Z_PF_DLTA and the extract structure ZBW_DS_PF_DLTA that you created in previous step (Figure 9). The logic in the function module works on change pointer tables and derives the data from the last initial and delta execution.

Figure 9

Data source Z_DS_PF_DLTA defined

Check the Selection box for the UDATE field and any other fields you want as shown in Figure 10. This is necessary because you need those selections to select the data from change log tables in SAP ECC. It is the driver for further logic.

Figure 10

Checking off the Selection box for fields

Then create function module Z_PF_DLTA in SAP ECC using transaction SE37 and add the code available at this link.

Map data source Z_DS_PF_DLTA to InfoSource Z_IS_PF. Create a transfer rules start routine using the code at this link. At a high level, the code recreates all the partners for the sales document that are changed, created, and deleted.

Finally, create a full repair InfoPackage for data source Z_DS_PF_DLTA to load and activate the data in DSO ZSD_O17. Write an InfoPackage routine using the code from this link to check the last run date and select the changes from that date onwards to the current date. The InfoPackage routine also checks the last run date of the InfoPackage on Z_DS_PF.

Loaded Sales Partners Data for Header and Line Items

In Figure 11 you can see the first initial load from Z_DS_PF_ PSEUDO_INIT that contained 303626 records, and then you can see how the selection conditions are generated for the InfoPackage Z_DS_PF_PSEUDO_DLTA. The InfoPackage code derives those dates from system tables based on when the last initial load or delta load occured. Then the data-source user exit logic in SAP ECC takes these dates, reads the data from change log tables, and builds the partners on the sales document for both header and line items.

Figure 11

Selection conditions are auto-generated based on the logic in the InfoPackage routine

Raja Cherukuri

Raja Cherukuri has 15 years of technical and functional experience in SAP ERP, BI,  IP/BPS/SEM, BusinessObjects, logistics, supply chain, procurement, project systems, finance, and controlling. He has led various full lifecycle implementations and upgrade projects, and performed as project, technical, and COE lead to meet aggressive project timelines.

You may contact the author at Cherukuri_rs@hotmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.