Skip to Content

The requirement I am going to describe is the following (taken out from this guide):

A Cloud user creates the prospect 123. When the Cloud team is ready to convert them to an account, an email is sent to the master data governance team. The master data governance team manually creates customer 9001 and references the Cloud prospect 123 in a text field. By entering (and persisting) the customer ID of Cloud in the ERP customer master, it is guaranteed that the IDoc that is send out from ERP identifies the corresponding Cloud instance, does not create a duplicate but updates the existing prospect instance and finally remove the prospect flag.

When I set up this requirement, I did not find a detailed instruction how to do so. I only found this Documentation – which actually helped me. But the instrutions of note 577502 to get the new field on the account screen are in my point of view not detailed enough. That’s why I am creating this detailed blog now to share my learning.

First of all, it is necessary to bring a custom own text field on the customer master screen in ERP. In this field, the C4C prospect ID should be entered. This value is then send to C4C and will trigger to remove the prospect flag. Here is a preview Screenshot how this will look after executing all the steps I am going to describe:

To get this field on the screen, as mentioned, note 577502 was helpful but for my taste note detailed enough. So I am trying to describe this in more detail:

  • The screen field we want to add, should be linked to an append in database table KNA1.
  • Due do this, first this Append needs to be created. To create it, got transaction SE11. Enter KNA1 for ‘Database Table’ and press Display.
  • Press the create append Button and choose a name for your new append.
  • Enter the field which should contain the C4C prospect ID as a 10-character text field:
  • Save and activate the Append. Now this field should be available in table KNA1.

As a next step, the new tab in the customer master screen which should contain this additional field should be created. These are the necessary steps:

  • Goto transaction SPRO, path Logistics->General->BusinessPartner->Customers->Control->Adoption of Customer’s Own Master Data Fields->Prepare Modification-Free Enhancement of Customer Master Record
  • Add a new entry like on the screenshot
  • Select this line and click on ‘Label Tab Pages’. Enter a function code and a Description
  • Save.
  • To have the new screen group visible on the screen, an active implementation of BADI CUSTOMER_ADD_DATA must be created. It is only necessary to implement one method, CHECK_ADD_ON_ACTIVE. That’s my coding for the new screen group ZC:
    METHOD if_ex_customer_add_data~check_add_on_active.
         IF i_screen_group = 'ZC'.
           e_add_on_active = 'X'.
  • Don’t forget to activate your BADI implementation.
  • Now the screen group and tab are ready, next a sub-screen which can be embedded there has to be created
  • For this a new function-pool needs to be created. Goto transaction SE80, choose Function Group in the dropdown list and choose a name.
  • Navigate in the new function group to Screens and create a new subscreen (right mouse-click). Any number is ok, I chose 9000.
  • On the subscreen, add your field which should contain the prospect ID (e.g. the field should link to the dictionary field which you created as append to table KNA1).
  • The screen field should only be ready for input in transaction XD01 and XD02, in XD03 of course it should be read only. So, I added a Module status_9000 with the following coding logic for the screen:

*&      Module  STATUS_9000  OUTPUT
*       text
MODULE status_9000 OUTPUT.
*  SET PF-STATUS 'xxxxxxxx'.
*  SET TITLEBAR 'xxx'.
IF sy-tcode EQ 'XD03'.
screen-input = '0'.
ELSEIF sy-tcode EQ 'XD01' OR sy-tcode EQ 'XD02'.
screen-input = '1'.
  • The next step is to create an implementation for BADI CUSTOMER_ADD_DATA_CS. This implementation will contain the application logic to be able to access the field and save it’s value on the database.
  • Goto transaction SE18 and enter the BADI CUSTOMER_ADD_DATA_CS. In the BAdI display screen, click on Enhancement Implementation ‘Create’ and create a new implementation.
  • First, this implementation should only be called for our screen group ‘ZC’. That’s why first we set a filter Values. To do so, got the properties tab in the new implementation and add a new filter for screen group ‘ZC’
  • Next implementations for methods GET_TAXI_SCREEN, SET_DATA and GET_DATA must be created. See below my coding for these methods.
        if flt_val = 'ZC' and i_taxi_fcode = 'ZC4C'.
       e_Screen = '9000'.
       e_program = 'SAPLZC4C_ENH'.
        iv_zc4cprospid       = s_kna1-zc4cprospid
           EV_ZC4CPROSPID       = S_KNA1-ZC4CPROSPID
  • In this implementation I call my created screen 9000, in case the screen group is ZC. So, this will bring the field on the screen. In method SET_DATA the data entered in the new screen field will be transported to table KNA1 to make sure the data will be saved on the database. Method GET_DATA in contrary will retrieve the data in our Z-field to have the value available on the screen field. Both these methods call a Z-Function module, Z_GET_C4C_DATA and Z_SET_C4C_DATA which are created in our new function group ZC4C_ENH. In the top Include of this function group (LZC4C_ENHTOP) I added the statement TABLES: KNA1. Through this statement, inside the function modules access to runtime structure KNA1 is provided. Due to this, by setting the data to KNA1, the standard application logic will then update our field for the prospect ID to the database.
  • The following is the coding for my mentioned Z-function module and top Include
    FUNCTION-POOL ZC4C_ENH.                     "MESSAGE-ID ..
    * INCLUDE LZC4C_ENHD...              
    *"*"Local Interface:
    ev_zc4cprospid = kna1-zc4cprospid.
    *"*"Local Interface:
    kna1-zc4cprospid = iv_zc4cprospid.

With those steps, the new Z-field is on the customer master screen and our logic makes sure that the value will be persisted and changed on the database.

The next step now is to get the content of this field in the IDOC which is send to Cloud for Customer.

For this purpose, an implementation of BADI CUSTOMER_ADD_DATA_BI must be created.

In this implementation method FILL_ALE_SEGMENTS_OWN_DATA is the right one to implement. The content of the Z-field must be mapped to IDOC segment E1KNA1H (of IDOC DEBMAS_CFS), with TDOBJEKT ‘SOD_ID’, TDNAME must get the value of the Z-field (ZC4CPROSPID). These data must be appended to the IDOC data structure to add it to the IDOC. Please see my coding below how I achieved this which speaks more than much explication.

  METHOD if_ex_customer_add_data_bi~fill_ale_segments_own_data.
    DATA: ls_idoc_data TYPE edidd.
    DATA: zc4cprospid TYPE char10.
    FIELD-SYMBOLS: <ls_data> TYPE kna1.
    DATA: ls_e1kna1h TYPE e1kna1h.

    IF i_segment_name = 'E1KNA11'.
      ASSIGN i_data_ref->* TO <ls_data>.
      SELECT SINGLE zc4cprospid FROM kna1 INTO zc4cprospid WHERE kunnr EQ <ls_data>-kunnr.
      IF zc4cprospid IS NOT INITIAL.
        ls_e1kna1h-tdobject = 'SOD_ID'.
        ls_e1kna1h-tdname = zc4cprospid.
        ls_idoc_data-segnam = 'E1KNA1H'.
        ls_idoc_data-sdata = ls_e1kna1h.
        APPEND ls_idoc_data TO t_idoc_data.


In HCI, there is a standard mapping on these fields, which makes sure the prospect will be converted to an account on Cloud for Customer side.

That’s basically it.

Summarized, with these changes the Prospect ID maintained in the customer master on ERP side will be send to Cloud for Customer. In Cloud for Customer, it will be checked whether this Prospect exists. In this case, the prospect flag will be removed and the prospect in Cloud for Customer is converted into an account.


To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply