Skip to Content

Custom fields in standard extractors –

making a mixed marriage work!


SAP has done an excellent job in
providing standard extractors for most all data coming from R/3.
  But, it can never match the collective ‘style=’mso-bidi-font-style:normal’>ability’ of R/3 customers of creating
customized data models and enhancing standard R/3 functionality.

So, as SAP rolls out newer and
enhanced extraction components in successive releases of PI, often times the
developers find that their data fields are not available in standard
extractors. There was an excellent weblog on options regarding enhancing the
standard extractors sometime back. In this weblog series, I am going to explore
the ‘custom fields in standard extractors’ scenarios in detail.

Intent of this document is to
provide readers of a practical example and also list out the
constraints/pre-requisites when mixing custom fields with standard extractor
fields. Examples, wherever mentioned in this document refer to R/3 46C with PI
release 2002.1 and BW 3.0B.

Issues in detail

In an ideal scenario of pulling
data from R/3 to BW, we have standard extractors/data sources that fulfill the
business requirements. At times though we will have one (or more) custom field
(these can be standard SAP fields, but not available in standard extractor; for
sake of simplicity we will call all such fields as custom fields) that we need
to bring along with the standard extractor fields.

SAP gives us quite a few options to
realize this. The complexity lies in capturing the true ‘delta’ for such custom
fields, and in providing them ‘in order’ to BW. In the weblog by Roberto Negro
mentioned earlier above, these options are mentioned. I am going to walk
through an example of purchasing data (PO Item – 2LIS_02_ITM datasource) and
provide you the process followed in making this work.

Let us try to categorize different
scenarios (based on technical constraints of the underlying system)

Custom field available in extract structure enhancement
option (i.e. the field is part of the standard communication structure
underneath the extractor)


Custom field appended in extract structure and updated
using customer exit.


Custom field updated through standard LIS events (Using
LIS enhancements).


Custom field updated through other events not captured
by LIS.


Other options – Generic datasource/ODS combo, custom
delta mechanism


First of these is straightforward,
and I will straightaway jump to other scenarios. In this first part of weblog, I
will mostly be talking around what and how of the second scenario (enhancing
the extract structure by using APPEND).

In the second (and third) part of this weblog series, I will talk
about the remaining scenarios.

Enhancing the extract structure

In the latest release of PI, SAP
apparently doesn’t allow extending the extract structure. I am however going to
show a step-by-step process for doing this based on an earlier PI release, and
you may be able to do the same even on later PI.

Example scenario:

Customer has added an additional
field ‘Partner profit center’ to capture the contract manufacturer’s partner
profit center (note there is already a partner profit center in EKPO. This
custom field is added to EKPO table using standard purchasing exit MM06E005 and
is maintained using standard
font-family: transactions (ME21N, 22N…).

Extract structure 2LIS_02_ITM is
extended (RSA6, option enhance extract structure). In the append structure
(Z*), I added field KOPPRCTR.

Little pieces we forget that severely impact the


Before talking of the steps
involved, let me dwell on the delta related issues. There are essentially two
categories of data we need to consider. One – when historical data is brought
over to BW using setup tables, and second – when delta updates are being
brought over to BW periodically. For the initial load, the code in user-exit
can assign values for this custom field relatively simply, however
complications arise in case of delta.

For 2LIS_02_ITM, there are two
records sent to communication structure for each change (Old, and new image).
The user-exit (or BADI) will need to assign correct values for the custom field
for each such record.

In our case, we store the custom
field data in a custom field in EKPO, hence we can do a ‘select’ on this table
to get the new data for our field and provide this to the extract structure.
However, how do we capture/determine the value before the change (before
image)? This is where the complexity comes in.

(You could have had the values for the custom field coming from some
other table or logic; the delta issue would still have been the same.

Another distinction to remember is
that the user-exit runs when the extraction from BW is triggered, while the
delta might have happened much earlier (or worse, many times for the same
record since the last delta extraction). This means my logic in the user-exit
is fetching me the value of the custom field as it is at the time of
extraction, and not when the ‘delta’ (change via the application transaction
e.g. ME22N) happened. Also it means that the user-exit is executed only if
there is a delta captured (any of the standard communication structure fields
have changed).  

Back to our scenario….

To enable the delta functionality, we
need to capture the delta of the custom fields somewhere. We used change
document tables for this. (You can use some Z tables akin to BIW1 and BIW2
tables of LIS to capture delta of your custom fields).


Custom field must be based on a data
element that is change log enabled, and is part of a table which is included in
a change document object (or you can create a custom change document object).

The logic

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Anshu Lilhori


    nclude structure cdpos.

    types: udate like sy-datum,

    utime like sy-uzeit,

    end of str_cdpos.

    data   : num_lines     like sy-dbcnt,

    zkopprctr     like ekpo-kopprctr,

    zkocapvalue   like ekpo-kocapvalue,

    l_s_icctrcst1 like mc02m_0itm,

    it_timestamp  type table of ztimestamp with header line,

    it_cdpos      type table of str_cdpos  with header line,

    it_cdhdr      type table of cdhdr      with header line,

    ldate         like sy-datum,

    ltime         like sy-uzeit,

    tabkey        like cdpos-tabkey,

    logic_flag    type n value ‘0’. “Indicator whether

    ” Logic for finding old value of custom field is

    ” needed

    data: l_s_icctrcst like s001biws,


    l_s_icctract like icctract,

    l_s_icctrsta like icctrsta,

    l_tabix      like sy-tabix,

    w_value      like ekpo-kopprctr.

    data : begin of itab occurs 1,

    ebeln like ekpo-ebeln,

    ebelp like ekpo-ebelp,

    end of itab.

    case i_datasource.

    when ‘2LIS_02_ITM’.


    **** logic for delta transfer



    * To create the initial entry in the Z timestamp table if it is not a

    * delta extraction run.


    if i_updmode eq ‘C’ or i_updmode eq ‘I’ or i_updmode eq ‘F’.

    it_timestamp-ztime       = sy-uzeit.

    it_timestamp-zdate       = sy-datum.

    it_timestamp-zdatasource = ‘2LIS_02_ITM’.

    append it_timestamp.

    insert ztimestamp from table it_timestamp.





    if i_updmode eq ‘D’ .

    * Get the timestamp value of last extraction run



    sort it_timestamp by zdate ztime.

    read table it_timestamp index sy-dbcnt.

    refresh it_timestamp.


    loop at c_t_data into l_s_icctrcst1.

    logic_flag = ‘0’.

    w_value = ”.

    l_tabix = sy-tabix.

    sort itab.

    * Insert ‘before image’ value only if this is the first occurance of the

    * PO-ITEM, and it is a cancellation record. For all other records,

    * original logic (same as historical data setup) will be followed for

    * both ‘before’ and ‘after’ image records.

    read table itab with key ebeln = l_s_icctrcst1-ebeln

    ebelp = l_s_icctrcst1-ebelp.

    if sy-subrc ne 0 and l_s_icctrcst1-rocancel = ‘X’.


    refresh it_cdhdr. clear it_cdhdr.

    select * from cdhdr into table it_cdhdr


    objectid = l_s_icctrcst1-ebeln

    and objectclas = ‘EINKBELEG’

    AND ( udate > it_timestamp-zdate or

    (  udate = it_timestamp-zdate

    and utime > it_timestamp-ztime ) ).

  2. Former Member

    Hi Ajay,

    The points what you touched is regularly we  will use ๐Ÿ˜‰ ๐Ÿ˜‰ , thank u very much for sharing ๐Ÿ™‚ ๐Ÿ™‚ and pls check it once the format of data is showing in html readers can’t understand. ๐Ÿ˜› ๐Ÿ˜›



    1. Anshu Lilhori

      Hi Giri,

      I doubt if ajay is really active these days in forums..He wrote this blog 8 years ago.I am facing issue regarding enhancing filed in LO so needed some documents which really speaks about it.

      This is very useful information..So i formatted the program so that other people can understand it..

      I am still trying to understand the efforts he must have put to debug that functionality and eventually to come up with this code.

      Hats off to him.



        1. Anshu Lilhori

          Hi Rajiv,

          This blog was created by someone else..I have just converted the code in understable format so that someone can refer and use it for their reference.

          Hope you understand.




Leave a Reply