In the recent times clients with whom I have worked are having the PDP Scenario where ECC PR will be to converted to SRM SC or SRM RFx via PI / ESOA as middleware.

So in this blog, I am sharing some technical details on the flow between ECC to SRM, i.e.   ECC PR -> SRM SC.  I will be sharing the general details, after which will share the specific custom requirements implemented for this flow .

Note:

1) This is my first blog on SCN and I have mainly written this from a SAP SRM Technical Consultant perspective, so if you find any issues/concerns. ,

      kindly share with me, so that I can learn and correct it.

2) This blog is applicable only if PI/ ESOA is used as Integration component.

  ME_REQ_SOURCING_CUST – Customize your sourcing requirements.

    As a part of this flow, the customizing BADI “ME_REQ_SOURCING_CUST” which is belong to the Spot “ES_BADI_ME_REQ” to be implemented, which will help to decide if the ECC PR should move to SRM as external requirement or should be processed in ECC itself or if the PR should move automatically to SRM or it should be moved Manually using SPPR/CPPR application.

Below is the SPOT and BADI details.

This BADI has two important methods, which will control the ECC to SRM flow.

Method: IF_EX_ME_REQ_SOURCE_CUST~CHECK_EXTERNAL_SOURCE.

This method used to activate the “External Sourcing” in ECC, which automatically trigger the SC Proxy message when a PR get saved/ released.

Method: IF_EX_ME_REQ_SOURCE_CUST~ACTIVE.

  This method is mainly used when Manual/ Automatic RFx/ SC  needs to be created in SRM using SPPR / CPPR applications, as its not required in this scenario , So I will explain in details when writing on SPPR/ CPPR applications.  Below is the screenshot which shows the method Signature.

PI/XI Messages used for the flow.

PurchaseRequestERPSourcingRequest_Out - ECC Side.

PurchaseRequestERPSourcingRequest_In - SRM side.

BADI “PUR_SE_PRERPSOURCINGRQCO_ASYN” to handle custom changes at ECC side.

If PI message will be used as communication channel between ECC and SRM systems, to carry out custom changes, SAP has provided BADI in Enhancements Spots, both at ECC and SRM.

    For the scenario considered, we need to use the BADI “PUR_SE_PRERPSOURCINGRQCO_ASYN”.

  Enhancement Spot : PUR_SPOT_SE_PURCHASE_REQUEST.

In this BADI we have to leverage the method “OUTBOUND_PROCESSING” to change the outbound data. This method will have “Purchase Requisition” Header and Item data as “Importing parameter” and Proxy data as “Changing Parameter”.

BADI “/SAPSRM/BD_SOA_MAPPING” to handle custom changes at SRM side.

   To handle the custom changes at SRM Side, SAP has provided BADI “/SAPSRM/BD_SOA_MAPPING”, which is the Enhancement Spot “/SAPSRM/ES_SOA_MAPPING”.

BADI “/SAPSRM/BD_SOA_MAPPING” is generic in nature with filter. i.e, This BADI can be used for Shopping Cart or RFx, at Header Level or at Item level, depending upon our requirements.

Below is the Filter settings. BO_TYPE will decide the  “OBJECT TYPE “ like SC , RFx..etc and “SET_TYPE” defines Header or Item level .

Ex : BO_TYPE = ‘BUS2121’ (Shopping Cart).

        SET_TYPE = ‘06’ (Item).

In this BADI we have to leverage the method “MAP_XI_TO_BACKEND” to receive and update the inbound data to SRM system. This method will have the Proxy Data as  “Importing Parameter” and SRM Backend data as “Changing Parameter” so that on the basis of incoming ECC data , programmer can change the SRM Data.

Note: As we are aware this is a generic BADI, because of which “type” of the parameters are dynamic, which means, the types will be decided at the run time .

For our scenario i.e, from ECC PR to SRM SC , the system will take the type “/SAPSRM/PUR_REQ_ERPSRCG_REQ_I1” .

With this much information , am ending my first ever blog on SCN   and will share an example of custom requirement "Changing SRM Shopping Cart  "Requester" from ECC PR creator via SAP PI / ESOA" ,which can be achieved by using the above details.

As mentioned before , its my first blog , any issues/ concerns. kindly share your thoughts , so that I can correct myself .

To monitor the POs that become inconsistent, we can have a report that looks for four types of inconsistencies, such as,

• Change lock
• Ordered in SRM but did not replicate to SAP
• POs error in process
• Workflow lock

We can use FM BBP_PD_PO_GETLIST to get the list of POs that are changed today, it will include the POs that are created today as well since the newly created POs have changed date as today's date only.

Case 1: Change lock

When a newly created PO is changed, a change lock is set to the original (active) version of PO until the change version is closed. Once change version is closed, original version will take the changes from change version and lock will be cleared.

Sometimes, change lock will not be cleared from original version, hence purchaser will no longer be able to change the PO as system pops up message "Action not possible because change versions exist" when purchaser clicks EDIT button.

We will have to use FM BBP_PDHGP_DB_DIRECT_UPDATE to clear the lock from active version of PO.

Case 2: Ordered in SRM but did not replicate to SAP ECC

Sometimes newly created PO in SRM in Ordered status does not replicate to SAP due to various reasons and when we try to make some dummy change in order to replicate it, we get the following pop up.

System status ITRE is active

This is due to status 'I1080’ is being active, we will have to push the PO via FM BBP_PD_PO_TRANSFER_EXEC, after which PO would have been replicated to SAP ECC.

Case 3: Error in process

We can find the POs that went error in process on a particular date by executing FM BBP_PD_PO_GETLIST by inputting change date as that date and check which POs have status 'I1132' active.

Case 4: Workflow lock

When an approver actions the approval workitem of a PO, a workflow lock entry is created in BBP_WFLOCK table which does not get cleared. Hence, the PO cannot be processed anymore as the system will pop up below message.

Document still being processed in background. Try again later.

We will have to clear the lock by executing standard report BBP_DEL_WFLOCK with PO GUID.

If we execute this report for current date, it will fetch the POs with aforesaid issues and it clears change lock and displays the PO numbers under the respective issues. We will have to take action.

****************************************************************

REPORT  zsrm_process_po.

DATA: ls_pdlist TYPE bbp_pds_pdlist,

       hs_pdlist TYPE bbp_pds_version_list_internal,

       ls_status TYPE bbp_pds_status,

       ls_wflock TYPE bbp_wflock,

       ls_header TYPE bbp_pds_po_header_d,

       lt_pdlist TYPE TABLE OF bbp_pds_pdlist,

       ht_pdlist TYPE TABLE OF bbp_pds_version_list_internal,

       lt_messages TYPE TABLE OF bbp_pds_messages,

       lt_status TYPE TABLE OF bbp_pds_status,

       lt_wflock TYPE TABLE OF bbp_wflock,

       lt_header TYPE TABLE OF bbp_pds_po_header_d.

DATA lv_guid LIKE crmd_orderadm_h-guid.

PARAMETERS date TYPE dats.

CALL FUNCTION 'BBP_PD_PO_GETLIST'

   EXPORTING

     i_change_date = date

     i_change_lock = 'X'

   TABLES

     e_pdlist      = lt_pdlist

     e_messages    = lt_messages

     e_status      = lt_status.

WRITE 'POs with change lock'.

LOOP AT lt_pdlist INTO ls_pdlist.

   CALL FUNCTION 'BBP_PD_PO_GETDETAIL'

     EXPORTING

       i_object_id = ls_pdlist-object_id

     IMPORTING

       e_header    = ls_header.

   IF ls_header-change_lock EQ 'X'.

     CALL FUNCTION 'BBP_PROCDOC_VERSION_GETLIST'

       EXPORTING

         iv_header_guid              = ls_pdlist-guid

         iv_read_all_change_versions = 'X'

       TABLES

         et_pdlist                   = ht_pdlist.

     SORT ht_pdlist BY version_no DESCENDING.

     DELETE ADJACENT DUPLICATES FROM ht_pdlist COMPARING version_type.

     LOOP AT ht_pdlist INTO hs_pdlist WHERE version_type EQ 'C'.

       IF hs_pdlist-doc_closed EQ 'X'.

         WRITE:/ ls_pdlist-object_id.

        CALL FUNCTION 'BBP_PDHGP_DB_DIRECT_UPDATE'

          EXPORTING

            iv_guid                  = ls_pdlist-guid

            iv_change_lock = 'N'.

       ENDIF.

     ENDLOOP.

   ENDIF.

ENDLOOP.

CLEAR: lt_pdlist, lt_messages, lt_status.

CALL FUNCTION 'BBP_PD_PO_GETLIST'

   EXPORTING

     i_change_date = date

   TABLES

     e_pdlist      = lt_pdlist

     e_messages    = lt_messages

     e_status      = lt_status.

IF sy-subrc IS INITIAL.

   WRITE:/ 'POs with ITRE status active'.

   LOOP AT lt_pdlist INTO ls_pdlist.

     READ TABLE lt_status INTO ls_status WITH KEY p_guid = ls_pdlist-guid stat = 'I1080' inact = ' '.

     IF sy-subrc IS INITIAL.

       WRITE:/ ls_pdlist-object_id.

     ENDIF.

   ENDLOOP.

   WRITE /'POs error in process'.

   LOOP AT lt_pdlist INTO ls_pdlist.

     READ TABLE lt_status INTO ls_status WITH KEY p_guid = ls_pdlist-guid stat = 'I1132' inact = ' '.

     IF sy-subrc IS INITIAL.

       WRITE:/ ls_pdlist-object_id.

     ENDIF.

   ENDLOOP.

ENDIF.

SELECT * FROM bbp_wflock INTO TABLE lt_wflock WHERE obj_type EQ 'BUS2201' AND lock_cdate EQ date.

IF sy-subrc IS INITIAL.

   WRITE:/ 'POs with workflow lock'.

   LOOP AT lt_wflock INTO ls_wflock.

     lv_guid = ls_wflock-obj_guid.

     CALL FUNCTION 'BBP_PD_PO_GETDETAIL'

       EXPORTING

         i_guid   = lv_guid

       IMPORTING

         e_header = ls_header.

     IF sy-subrc IS INITIAL.

       WRITE:/ ls_header-object_id.

     ENDIF.

   ENDLOOP.

ENDIF.

In SRM we cannot use many functional modules which we have used in ECC ( GUI_UPLOAD / ALSM_EXCEL …) to read excel data to internal table .

I will show the coding where we can pass excel date to internal table by reading column by column and row by row .

DATA : gv_fname1 TYPE string.

CONSTANTS: tabu TYPE x VALUE 9.
FIELD-SYMBOLS: <pointer>.
DATA: sep(1).
DATA : v_len TYPE i,
v_uscore TYPE c VALUE '_',
v_bukrs_chk TYPE string,
v_bukrs_len TYPE string,
v_cat_strlen TYPE i,
cnt TYPE i VALUE 0,
v_char TYPE c,
v_flag TYPE i,
v_delimit(50) TYPE c VALUE '~!@#$%^&*()_+-={}|[]\:"/;<>?,.',
v_deliv_pad(10) TYPE n,
v_asset(8) TYPE n,
v_sep(1) TYPE c VALUE '/',
v_message TYPE string,
v_temp TYPE sy-tabix,
lx_user TYPE usr02,
lv_htype LIKE dd01v-datatype.

SELECTION-SCREEN  BEGIN OF BLOCK b1 WITH FRAME TITLE text-001.
SELECTION-SCREEN SKIP 1.
PARAMETERS:  p_file1 LIKE rlgrap-filename OBLIGATORY.
SELECTION-SCREEN  END   OF BLOCK b1.

AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_file1.
PERFORM get_filename USING p_file1.

START-OF-SELECTION.
IF NOT p_file1 IS INITIAL.
gv_fname1  = p_file1.
PERFORM call_excel TABLES lt_data USING gv_fname1 1 1 9999 100.
ENDIF.

*&---------------------------------------------------------------------*
*&      Form  GET_FILENAME
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*      -->P_P_FILE1  text
*----------------------------------------------------------------------*
FORM get_filename  USING    lv_file . "p_p_file1.

CALL FUNCTION 'WS_FILENAME_GET'
EXPORTING
def_filename     = space
def_path         = space
mask             = ',*.*,*.*.'
mode             = space
title            = space
IMPORTING
filename         = lv_file
*          RC               =
EXCEPTIONS
inv_winsys       = 1
no_batch         = 2
selection_cancel = 3
selection_error  = 4
OTHERS           = 5.
ENDFORM.                    " GET_FILENAME

*&---------------------------------------------------------------------*
*&      Form  CALL_EXCEL
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*      -->P_LT_DATA  text
*      -->P_GV_FNAME1  text
*      -->P_1      text
*      -->P_1      text
*      -->P_9999   text
*      -->P_100    text
*----------------------------------------------------------------------*
FORM call_excel  TABLES   lt_data
USING value(arch)
value(fila_1)
value(col_1)
value(fila_2)
value(col_2).

DATA: excel_line(4096) OCCURS 10 WITH HEADER LINE.
DATA: app TYPE obj_record,
workbook TYPE obj_record,
worksheet TYPE obj_record,
cell_1  TYPE obj_record,
cell_2 TYPE obj_record,
range TYPE obj_record.

CREATE OBJECT app 'EXCEL.APPLICATION'.
IF sy-subrc NE 0.
" error.
EXIT.
ENDIF.

CALL METHOD OF app 'WORKBOOKS' = workbook.
CALL METHOD OF workbook 'OPEN' EXPORTING #1 = arch.

IF sy-subrc NE 0.
WRITE:/ 'Error en excel'.
ENDIF.

GET PROPERTY OF app 'ACTIVESHEET' = worksheet.

CALL METHOD OF worksheet 'Cells' = cell_1
EXPORTING
#1 = fila_1
#2 = col_1.

CALL METHOD OF worksheet 'Cells' = cell_2
EXPORTING
#1 = fila_2
#2 = col_2.

CALL METHOD OF worksheet 'RANGE' = range
EXPORTING
#1 = cell_1
#2 = cell_2.

CALL METHOD OF range 'SELECT'.
CALL METHOD OF range 'COPY'.

CALL FUNCTION 'CLPB_IMPORT'
TABLES
data_tab   = excel_line
EXCEPTIONS
clpb_error = 1
OTHERS     = 2.
ASSIGN sep TO <pointer> TYPE 'X'.
<pointer> = tabu.

PERFORM delimit_columns TABLES excel_line lt_data USING sep.

SET PROPERTY OF app 'CutCopyMode' = 0.

CALL METHOD OF app 'QUIT'.
FREE OBJECT app.

ENDFORM.                    " CALL_EXCEL
*&---------------------------------------------------------------------*
*&      Form  DELIMIT_COLUMNS
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*      -->P_EXCEL_LINE  text
*      -->P_LT_DATA  text
*      -->P_SEP  text
*----------------------------------------------------------------------*
FORM delimit_columns   TABLES excel_line itab USING sep.
DATA: BEGIN OF xls OCCURS 5,
value(1024),
END OF xls.
DATA: len TYPE i.
LOOP AT excel_line.
SHIFT excel_line LEFT DELETING LEADING sep.
SHIFT excel_line LEFT DELETING LEADING ' '.
CONDENSE excel_line.
len = STRLEN( excel_line ).

IF len EQ 0.
CONTINUE.
ENDIF.

SPLIT excel_line AT sep INTO TABLE xls.
LOOP AT xls.
ASSIGN COMPONENT sy-tabix OF STRUCTURE itab TO <pointer>.
<pointer> = xls-value.
ENDLOOP.
APPEND itab.
CLEAR itab.
REFRESH xls.
*  ENDIF.
ENDLOOP.

ENDFORM.                    " DELIMIT_COLUMNS

Many times while creating confirmation document, I have noticed that Classic/Extended Classic PO's still appearing in Open for confirmation list even after confirming all the items, then executing the below report would help in refreshing the same.

BBP_GET_STATUS_2

CLEAN_REQ_REQ_UP

In my first blog - http://scn.sap.com/community/srm/blog/2016/01/25/ecc-pr-to-srm-sc-flow-in-pdp-scenario-a-technical-perspective  , have explained some basic technical details of ECC PR to SRM SC flow in general, so in this blog, am sharing a general implementation GAP in all ECC to SRM PDP Scenario during ECC PR to SRM SC conversion .

Scenario:  In ECC user will create the Purchaser Requisition and transfer the requirement to SRM Shopping Cart as a part of Plant Driven Procurement.

Challenge / GAP : When the “Shopping Cart” get created in SRM from the ECC Purchase Requisition via SAP PI / EOSA, then the Shopping Cart requester name will be the “PI background user” instead of the ECC PR requester.

This behavior is the SAP standard in ECC to SRM flow. To correct this we have couple of methods as below.

1. Once Shopping Cart got created in SRM , make a RFC call to ECC , get the PR details and update the Requester.
   
   
2. Update the ‘Requester Name” during PR transfer from ECC to SRM using SOA BADI’s.

If we use the 1^st method, where calling the ECC PR details from SRM system via RFC/ BAPI  post SC creation and updating the “Requester Name” using the custom field is a time consuming and performance hit, so in this blog,  am going to share my knowledge on the 2^nd method, where we will change the “Requester Name” during ECC PR to SRM SC transfer only, which we have implemented successfully.

Details in ECC side.

PI message used in ECC: PurchaseRequestERPSourcingRequest_Out.

   SAP has provided a filed “REQUESTER_PERSON_NAME“which will be in the ITEM level of PI Message “PurchaseRequestERPSourcingRequest_Out”. By default this field will be empty, i.e. means SAP will not fill this field with any value in standard flow, but we can use this field to fill up the “Requester Name “as per our requirement (Ex: we can fill the EBAN-ERNUM) by leveraging the BADI PUR_SE_PRERPSOURCINGRQCO_ASYN in ECC.

Below are the details of the Enhancement Spot and BADI. 

Enhancement Spot       : PUR_SPOT_SE_PURCHASE_REQUEST

BADI Definition Name   :  PUR_SE_PRERPSOURCINGRQCO_ASYN

Method                        : OUTBOUND_PROCESSING

Mapping Parameter       : “REQUESTER_PERSON_NAME” in the ITEM of “CH_PR_PROXY”, the Value will be EBAN-ERNUM (it will be different as per the

                                      requirement).

Below is the snapshot of BADI details.

We have to change the value in the “Changing Parameter – CS_PR_PROXY’.

  The “Requester name” will be passed to the “REQUESTER_PERSON_NAME” which is shown in the below screen.

This is the change required at ECC side and no changes at PI system as we are using SAP standard PI field for transfer.

Changes at SRM Side

PI message used in SRM: PurchaseRequestERPSourcingRequest_In.

  Even though we are mapping the “Requester Name” to SAP standard field, SRM system will not consider this during Shopping Cart creation, this is because of SRM system is fetching the Requester Name , from “USER Context “, as a result of which the "SC Requester" will be  “PI Background User” instead of “Requester Name” which we sent from ECC. 

So to achieve our functionality, we have updated the “Requester Name” which we are passed from ECC to User Context by leveraging the BADI “/SAPSRM/BD_SOA_MAPPING “.

Below are the details of the Enhancement Spot and BADI.

Enhancement Spot      :   /SAPSRM/ES_SOA_MAPPING

BADI Definition Name   :  /SAPSRM/BD_SOA_MAPPING

Method                       :   MAP_XI_TO_BACKEND

Filter Values                :   BO_TYPE = ‘BUS2121’ (Shopping Cart) & SET_TYPE = ‘06’ (Item).

Below is the snapshot of BADI details.

Below is the snapshot of parameter “IR_MSG_INTF_DATA “of the method “MAP_XI_TO_BACKEND” which holds the “ECC Requester Name”.

Below is the snapshot of structure “/SAPSRM/PUR_REQ_ERPSRCG_REQ_I1”, which is populated during runtime.

In the implementation of above BADI method - MAP_XI_TO_BACKEND, we have to perform below steps.

a) Extract the “Requester Name” which was passed from ECC  he “IR_MSG_INTF_DATA” parameter.

b) Fetch the Partner GUID number of the Requester using the FM “BBP_CENTRALPERSON_GET” by passing “Requester ID “.

Note:  Please note, that, method “/SAPSRM/IF_PDO_US_CONTEXT_PROV~SET_DEF_REQUESTER”  to update the “Default Requester” to user context will take the “Business Partner” as the Importing parameter, instead of user id , because of which before updating, we have to convert the “ Requester User id” to corresponding  BP Number ( Business Partner) .

c) Fetch the BP number using the FM BUP_BUT000_SELECT_WITH_GUID by passing the Partner GUID.

d) Now fetch the reference of “User Context” using the method "/SAPSRM/CL_PDO_FACTORY_USER=>GET_BUFFERED_USER_CONTEXT".

e) Update the “Requester” to the user context using the method /SAPSRM/IF_PDO_US_CONTEXT_PROV~SET_DEF_REQUESTER by passing the “Requester

    BP number”.

By this time ,ECC PR "Requester Name"  will be set in the “User Context”, which will be taken from SRM system as Shopping Cart " Requester" instead “PI Background "user.

Once all the development is completed, create the SC from ECC PR and check the “Requester name” in the SOCO, it will be the requester from ECC.

By this  information , am ending this blog . Please note that above solution , which I have found during  analysis myself , there may be better solution than this to achieve the same with more efficiently , if you have such a solution , kindly share the same  .

This is follow-up blog for Some Tips in Translation of SRM content - Part 1.
I received some feedbacks regarding to Topic 2 Translation in SRM documents, such as how can we judge if the field has OTR text?
This really makes a lot of people confused, and now I would like to share my experience about this.

Scenario 1:Some buttons do not have OTR referred

For example, while translating button 'Responses and Awards' in RFx, you may right click the button to display technical details.
Here the Webdynpro Component for this button is FPM_OIF_COMPONENT, not in the form of '/SAPSRM/...'

The text of such field is directly inserted without OTR text referred as below:

In this scenario, you can only change the text in transaction se80 and the translation will take effect.

Scenario 2: Some buttons/columns have OTR referred

For example, in 'Responses and Awards' screen, to change the text of  'Last Changed on' column, right click the columns and the WebDynpro component used is /SAPSRM/WDC_AODC_BEV_ACT.

Meanwhile, if you checked the 'text' property of this column, you will see OTR text is used.

In such scenario, please go to my blog Some Tips in Translation of SRM content - Part 1 to check the solution in Topic2.

Welcome to any feedback regarding to translations issue in SRM application:)

SAP provided standard translation for buttons, fields, etc, in different languages. However you may still want to adjust it according to your understanding.
Here in this blog, I would like to introduce some ways to do translation in SRM application.

1. Translation in POWL area
   In POWL, it is divided into three parts:

• Active Query
  
  For this part, you may find the corresponding query in t-code POWL_QUERY, and go to path 'Goto -> Translation'
  to select the target language for translation.
  
• Search Criteria
  
  For this part, please go to method SET_MY_SELCRITERIA of corresponding class, such as /SAPSRM/CL_CLL_POWL_BO_RFQ.
  And then Goto -> Text Elements to choose the field and do translation.
  
• POWL button and result table
  
  For this part, please refer to the solution in the following note to check and maintain the translation:
  KBA 2158920 Translation Issues in SRM POWL

    2.  Translation in SRM Documents
         If you would like to translate some fields or buttons in SRM documents, such as RFx, SC, etc, please try the following method:

• Get wendynpro component, view name and element name of the field or button and search property value in table WDY_UI_PROPERTY.
  
• If no entry for this field/button in table WDY_UI_PROPERTY, then search the text directly in t-code sort_edit to get the package, alias and concept.
  
• Go to se63, and navigate to menu Translation --> ABAP Objects --> Short Texts --> A5 --> SOTR.
  
  
  For 'object name', please insert both package and the concept of the text using F4 help:
  For example:
  
  You may also refer to KBA 1739292 - Use of the Online Text Repository (OTR) to correct translation issues for the second method.

   3.  Translation for Dropdown Texts
        For some dropdown texts, it can only be found in specific method. So the translation has to be done in the method itself.
        For example, in RFx, while adding lines, there is option 'add item from SC'.
        To translate it, go to method /SAPSRM/IF_CLL_DOTM_RFQ_I_BD~INIT_CATALOG_ENTRIES(Class /SAPSRM/CL_CH_WD_DOTM_RFQ_I_BD).
        Then Goto --> Text Elements to do such kind of translation:
       

   4.    Translation for Buttons without OTR
          For some buttons, they have no OTR maintained, so it has to be translated in t-code se80.
          For example, 'Award' button in Responses&Awards page:

• Go to SE80.
• Enter FPM_OIF_COMPONENT in Web dynpro Comp./ Intf.
• Expand Component Configurators.
• Select /SAPSRM/WDCC_FPM_BEV_RFQ under Component Configurations.
• Click on Start Configurator.
• Click on change in the new window Component Configuration /SAPSRM/WDCC_FPM_BEV_RFQ.
• Click on "Award" Button.
• Change the Label as what you want
• Change the tool tip as what you want
• Save your changes.

Hope this would be of help, and welcome any other ideas about translation methods in SRM.

  In this blog, am discussing basic details of MM-SUS scenario, post which will present a custom requirement to transfer ECC PO fields to SRM SUS PO as custom fields which we have implemented.

MM-SUS Scenario: This scenario will be implemented to enable Supplier Collaboration, where purchasing documents will be exchanged between ECC and SRM SUS systems via PO / IDOC interfaces.

MM-SUS Architecture Overview:

Interfaces:

Below are the commonly used interface flows (As per my experience).

1) Purchase Order Replication (ERP ->SUS) – ERP PO will be replicated to SRM SUS.

2) Purchase Order Confirmation (SUS ->ERP) - ERP PO Confirmation replicated will be replicated to ECC from SRM   SUS.

3) Purchase Order Change (ERP ->SUS) – ERP PO Change replicated to SRM SUS.

for the above interfaces SAP PI will be used as Integration Component.

Transfer of ERP PO fields to SRM SUS PO as custom fields.

      As Supplier will not be able to see most of the Purchasing info like “Company Code”, “Purchasing Group” ,”Tracking Number” , “Status” .etc, in the SRM SUS PO , to provide this purchasing info on the PO to Supplier, we need to transfer these fields to SRM SUS via PI message.

Below are the technical implementation details for transferring the fields from ERP to SRM SUS via PI.

Step1: Generation of ABAP proxy’s for the message PurchaseOrderERPRequest_Out_V1 in ECC.

     The PI message “PurchaseOrderERPRequest_out_V1“should be enhanced by PI team to add the custom fields at the HEADER or ITEM level as per particular requirement.

  Once the PI message got enhanced in PI system, we need to generate the ABAP Proxies in ERP system using the tcode SPROXY.

Below is the link from help.sap.com on generating the ABAP proxies.

ABAP Proxy Generation - General Procedure - Working with ABAP Proxies - SAP Library

Step2: Map the ERP fields to outgoing PI message custom fields by leveraging the BADI PUR_SE_POERPREQOUT_ASYN.

       Once the PI fields got added into the PI message, map the ERP backend fields to outgoing PI custom fields by implementing the method “OUTBOUND_PROCESSING” of the BADI " PUR_SE_POERPREQOUT_ASYN".

Below are the technical details.

SPOT: PUR_SPOT_SE_PURCHASE_ORDER

BADI : PUR_SE_POERPREQOUT_ASYN.

Method: OUTBOUND_PROCESSING.

   In the  method "OUTBOUND_PROCESSING"  fill up the custom fields in the changing parameter “CS_PO_PROXY” from the details in the Importing parameters.

Step3: Generation of ABAP proxy’s for the message PurchaseOrderERPRequest_In_V1 in SRMSUS.

  As mentioned in the first step, need to generate the PI ABAP Proxies at SRMSUS, once the PI team has enhanced the PI message to accommodate the custom fields.

Step4: Addition of custom fields to SRM SUS PO Header and Item structure.

    In SRM SUS we need to add the custom fields to the PO Header and ITEM structure using SRM MDF concept.

  Below are the Header and Item structures to be enhanced to accommodate the custom fields.

    INCL_EEW_PD_HEADER_CSF_SUSPO – SUS PO Header.

    INCL_EEW_PD_ITEM_CSF_SUSPO        - SUS PO Item.

    INCL_EEW_PD_HEADER_CSF                – Common Doc Header Structure.

    INCL_EEW_PD_ITEM_CSF                     - Common Doc Item Structure.

You can refer the SAP note “672960 - User-defined fields 2” for more details on the custom field addition.

Step5: Map the incoming PI custom fields to SRM SUS PO fields by leveraging the BADI “/SAPSRM/BD_SOA_MAPPING”.

      In this step we need to map the incoming PI custom fields to SRM SUS PO fields by using the method MAP_XI_TO_BACKEND of the BADI /SAPSRM/BD_SOA_MAPPING.

Below are the technical details.

SPOT: /SAPSRM/ES_SOA_MAPPING

BADI: MAP_XI_TO_BACKEND.

Method: OUTBOUND_PROCESSING.

Filter: BO_TYPE (Business Object Type) = BUS2230 (SUS PO).

   In the method fill up the custom fields in the changing parameter “CR_BACKEND_DATA” from the details in the Importing parameter(IR_MSG_INTF_DATA).

Step6: Add the custom fields to SRM SUS BSP views.

   By now the custom fields will be transferred to SRM SUS, but these will not be displayed in the SRM SUS which is BSP page.

   To make it display on the SRM SUS page, SAP has provided a Customization view ,which we can update  either by SPRO or directly in view BBPV_SUS_TABDEF.

   You can refer the SAP Notes “762984 - SRM40-SUS: Implementation of customer enhancement fields” for the detailed information.

Note:  Please follow the above note only for adding the custom fields at ABAP level and in the UI level. But not regarding mapping the fields, whatever SAP mentioned for fields mapping is only for SRM 5.0 not for SRM7. So kindly ignore that part, in case of SRM7 we are using BADI “/SAPSRM/BD_SOA_MAPPING” to achieve the same.

Note: For more information you can refer to the SAP note: 783460 - SRM40-SUS: Redefine settings of UI.

  Once all above 6 steps are executed, the custom fields will be displayed at the SRM SUS from the ECC system.

   If any comments , kindly share.

In this blog and future blog’s am sharing some functional / technical  details on SAP SLM / SAP SLC module.

   Before proceeding further, let me clarify one question, which will come to every consultant, who will start working with this module, i.e. 

Why two names SAP SLM or SAP SLC? When I done some R & D on this , found that ,   SLC stands for  "Supplier Lifecycle Collaboration "   and SLM standards for "Supplier Lifecycle Management",so initially  the product name was SAP SLM , but  with the same name there is one more module  “Software Lifecycle Management” already present with SAP , so to avoid naming  conflict , SAP SLC has been chosen.  So SAP SLM and SAP SLM are represent same module.

      Initially when I was asked to start working with SAP SLM / SAP SLC, was totally blank about its functionality and processes, even when searched over net found very minimal documentation in help.sap.com - https://help.sap.com/slc , other than this found some config documentation from SAP Market Place.  So here am sharing very basic information on the SAP SLC / SAP SLM, which I have got during the implementation of SAP SRM and SAP SLM.

so lets start  ..

    SAP Says ,

  “SAP Supplier Lifecycle Management is a holistic approach to managing supplier relationships. It deals with the supply base as a whole to constantly determine the right mix of suppliers. It covers the lifecycle of individual supplier’s ‒ from on boarding to a continuous development”.

           So in common terms SAP SLM is the module which deals with “Supplier” life cycle. Unlike SRM SUS, this module is purely developed by making “Supplier” as a central.“. "From the day a Supplier is started business to the day Supplier end the relationship“, this whole lifecycle will be monitored / controlled / powered by SAP SLM.

      So now question comes why a separate module is needed to manage the Supplier?  , answer for above question can by find below …

• With SAP SLM, company can manage end to end Supplier Life cycle efficiently, from Supplier Registration to Supplier Phase-out.
• With SAP SLM, Company can manage “Supplier Qualification“efficiently, as many automated processes are available.
• With SAP SLM Company can manage “Supplier Performance” efficiently, as many automated processes are provided by SLM.
• With SAP SLM company can trust a single centralized supplier source of information.
• SAP SLM has SAP ABAP WD – at Buyer Side and BSP at Sell Side, which makes the UI very rich to use, which intern enables Business people to use the application efficiently.
• SAP SLM can be connected to multiple backend systems, so company can maintain the data as “Centralized”.
• SAP SLM is “Deployment Flexible”, which means, it’s not only deployed with SAP SRM, but also has flexibility to deeply on ECC or standalone.
• SAP SLM usages tools like “Score Cards”, “Questionnaires”...etc for Supplier Evaluation & Supplier Qualification, which intern helps in Reporting.

    Below is the snapshot of Supplier lifecycle in SAP  SLM.

High level architecture of SAP SLM.

     Below is the high level architecture of SAP SLM. 

              In SAP SLM Buy Side represents the Company (Buyer / Purchaser) and Sell Side represents the Supplier/Vendor.             

SAP SLM Processes.

       Below are the processes of SAP SLM.

• Registering Suppliers.
• Maintaining Supplier Data.
• Qualifying Suppliers.
• Managing the Supplier Portfolio.
• Classifying Suppliers.
• Evaluating Suppliers Based on Events.
• Evaluating Supplier Peer Groups.

By this information , am ending this blog , in the next blog will try to discuss on the SAP SLM Processes.  Any comments or suggestions are welcome , as always.

In this blog post, I would like to share some experience while handling catalog transfer issue and SRM-MDM catalog UI issue.

Part One:

This story is about 'dropdown list' for search criteria in SRM-MDM search UI. As you could see, even if I set the search field as 'Dropdown menu', it still use 'Extended Value Selector'.

Why dose it behave inconsistently with the setting in Config UI? This is more related to one parameter in WebDynpro JAVA.

There is a parameter which can control this behavior, called "sap.valuesetlimit.maxondemand".
It defines the maximum size of a simple type value set which is displayed as a Simple Value Selector (DropDownByKey UI element with dropdown list).
When the value set size exceeds the  configured sap.valuesetlimit.maxondemand value, the dropdown list is replaced by an Extended Value Selector (EVS) popup dialog.

So this is a feature, and we may adjust it as mentioned in SAP note:

1013227 - Using Drop Down List Boxes in ZCI Style Interactive Form

Check the section "How to change the maximum number of items allowed in the Value Help DDL**:"

Meanwhile on 730 you find the webdynpro properties here:
http://help.sap.com/saphelp_nw73/helpdata/en/4c/2319ca35285791e10000000a15822b/frameset.htm

This page also mentioned the parameter "sap.valuesetlimit.maxondemand".

Part Two:

Another story is about transferring Z-field from SRM-MDM catalog to SRM Shopping Cart.

Some customers are complaining that some Z-field can be transferred, but some can not, which is very tricky.

One possible cause is as below: The definition of Z-field name is too long.

Let's have a look at the following case:

For example, if you define the Z-field as 'ZZ_CONTRACT_ITEM_TOLERANCE'. Usually we will never define the field name with so long a name.

Originally, it has this name in LS_STRUCTURE_INFO-FIELDNAME.

However table LT_ITS_CONTEXT won't allow such long name, and it is cut off as 'ZZ_CONTRACT_ITEM_TOLE'

Hope these stories will give you some inspiration while handling such tricky problems

This blog is to introduce a new xSearch engine called 'Best Bets' and also a open discussion room for you all.

Best Bets are pages that show up ahead of other results when particular keyword(s) are chosen. They are displayed in a box at the top of the xSearch results page.

In order to show this vividly, let me show you one example:

• Access support portal https://support.sap.com/home.html
• Type keywords such as 'srm sus' or 'sus' if you have interest in some knowledge in SRM-SUS area
• Then SCN wiki SUS Troubleshooting Guide will be highlighted in Best Bets part.

Until now, we already have 289 Best Bets published in support portal including many areas, such as SRM, MM, HCM, JAVA, EP, etc.
Usually the best bets are Troubleshooting Guides (wiki pages), Popular KBA, FAQ note or helpful document.

You are welcome to make use of this search engine to get technical help from SAP.

Welcome to your feedback on experiencing this and we will improve it according to your advice!!

Well, the reason why I creaete this blog is to mark all the questions reagrding to user data, such as language, email, timezone, etc, to be synchronized in all places. I will constantly update the content of this blog to include all related topics.

Today, I will talk about language in user settings and su01 data.

In su01, there is two languages, one language under 'Address' tab and one logon language under 'Defaults' tab.

However in SRM User Settings, we only have one language under 'User Account' tab.

This is hard-coded in the method /SAPSRM/IF_PDO_MO_USER_ACCOUNT~GET_USER_ACCOUNT_DETAILS.

Here it takes ls_defaults-langu instead of ls_address-langu.
For language in default tab, it is mainly used for user logon. The language in address tab might be used in business processing such as email notification.

Of course, if you have your own business requirement, you may consider using enhancement to change this behavior, which is also quite easy.

To Be Continued...

With the launch of SAP Supplier life cycle management, SAP has addressed a long pending business need for a full-fledged supplier management application. This has been on the wish list of most of the procurement executives working with SAP solutions, however SAP did not have very solid offer in this area earlier.  Customers using SAP SRM, had the option of using Supplier Registration functionality which is delivered as part of Supplier collaboration solution in SAP SRM. However, Supplier Registration functionality till SAP SRM 7.0 (EHP1) was offered at a very basic level with limited functionality. It lacked critical features such as approval workflow for potential suppliers, seamless integration with backend systems, upload of attachments etc.. Due to such obvious gaps, this functionality was not much used by customers or needed extensive customization and development to get the desired functionality.

With the launch of SAP Supplier life cycle management, SAP has addressed a long pending business need for a full-fledged supplier management application. This has been on the wish list of most of the procurement executives working with SAP solutions, however SAP did not have very solid offer in this area earlier.  Customers using SAP SRM, had the option of using Supplier Registration functionality which is delivered as part of Supplier collaboration solution in SAP SRM. However, Supplier Registration functionality till SAP SRM 7.0 (EHP1) was offered at a very basic level with limited functionality. It lacked critical features such as approval workflow for potential suppliers, seamless integration with backend systems, upload of attachments etc.. Due to such obvious gaps, this functionality was not much used by customers or needed extensive customization and development to get the desired functionality.

Through another product SAP Sourcing, SAP offered a more advanced supplier management functionality than SAP SRM.  This contained approval workflows and integration of supplier performance management within supplier management application. But still it did not offer a complete holistic approach to supplier management.
However with the launch of SAP SLM, SAP has taken a giant leap in supplier management functionality and presented a complete and dedicated solution in this area. Even though in its first version SAP SLM 1.0, SAP has only come out with limited set of supplier processes, it spells of a grand vision and clear roadmap in realizing full scale supplier lifecycle management through versions 1.1 and 1.2 which would come in later part of the year.

As of SAP SLM version 1.0, following business processes are covered:

1. Supplier Registration
2. Supplier Qualification
3. Supplier Portfolio Management
4. Supplier  Order Collaboration

Supplier Qualification and Supplier Portfolio Management are two very important processes which have been significantly enhanced in comparison to earlier offerings of SAP SRM supplier management functionality.

Supplier qualification process is workflow driven and provides a much needed control in managing supplier qualification. Purchasers or Category Managers can create qualification requests either for a potential supplier or for qualified suppliers based on specific projects. Suppliers receive notification in email and respond by submitting qualification response through portal. After receiving supplier responses, Category Manager can approve the supplier status to be changed based on response review.

Supplier Portfolio management provides an advanced supplier data management platform where different dimensions of supplier data can be stored under different sections e.g.  Classification, Financial data, Qualification data etc.  Suppliers can also do self service data maintenance, which can be routed through approval workflow and gets synchronized in backend systems upon approval.

Going further, versions SAP SLM versions 1.1 and 1.2 promises even more exciting features, like supplier evaluation , content tagging and third party integration, Supplier development and Supplier phase out.

Above, I had given an overview of functionalities in SAP Supplier Lifecycle Management.
Now I am going to write briefly about architecture and various deployment options, that comes with SAP SLM version 1.0.
At a high level architecture, SAP SLM is based on SAP NW 702 platform. It is basically composed of two components - Buy Side and Sell side. Buy Side is the component, which is accessed within buying company by purchasers, category managers and other internal stakeholders. Buy side is located within the firewall of company and is available on intranet.
Sell side is accessed by suppliers for various external processes and is located outside the firewall of the company. Sell side is available on open internet for registered and potential suppliers.

Broadly following processes are executed on the two sides:

Sell Side:
  Supplier self registration
  Supplier data maintenance
  Supplier qualification response submission

Buy Side:
  Supplier registration approval
  Supplier portfolio maintenance
  Supplier qualification

The two components are connected via RFC connection for data exchange. There could be a little concern from security standpoint here, as RFC connections may not be encouraged via supplier systems to customer secured systems and even SAP recommends asynchronous communication using SAP PI or middleware.

SAP SLM - Buy side is connected further to a backend system, which can be an SAP SRM server or SAP ECC server. This is basically to synchronize supplier data to backend systems.

Overall, SAP SLM V1.0 can be deployed in multiple flexible variants as below:

1. Integrated Deployment:

Under this, SAP SLM is installed as an add-on to SAP SRM (Version 7.0, EHP1) server. On the sell side, SAP SLM is installed as an add-on component to SUS (Supplier self services), which is supplier collaboration solution for SAP SRM v1.0.

On the buy side, SAP SLM is installed as an add-on to SAP SRM procurement component. The backend system is SAP ECC server(>= version 6.0) in this case.

The benefit with this deployment is that, it allows 'Order collaboration' along with Supplier data management on one platform. Using Portal, both SUS and SLM can be accessed uniformly. Of course, this requires a pre installation of SAP SRM(version 701) and SUS to capitalize upon.

2. Standalone Deployment:

Under this, SAP SLM is installed as an standalone server with Buy side and sell side as two  independent components. The backend in this case could be SAP SRM server (version 5.0 to 701) or SAP ECC (>= 6.0).

The benefit with this deployment is that, SAP SLM can be used with lower SRM versions like SRM 5.0.

3. Mixed deployment:

This is basically hybrid deployment, wherein either the buy side or sell side is standalone and the other component is installed as an add-on to SAP SRM (701) server. The backend system can be SAP SRM server or SAP ECC server.
This deployment variant could be useful, where either only SUS component or only SAP SRM procurement (EBP) component is used by a company. For e.g. in MM-SUS scenario, this deployment can be useful.

Finally, the decision for a deployment option would depend upon the existing landscape components and the business scenarios applicable. SAP SLM in future releases would also be provided with option of installation as an ECC add-on. So this would provide another flexible option for customers to decide upon the deployment variant.

A lot of users might be interested in report HRALXSYNC, and also confused about its usage in different scenarios.

Today I would like to show my experience on this report, which should be of help to you.

Topic One:
Early Watch Report is a popular report to evaluate all the risks a system client might have. Sometimes it might raise an error alert as below:

However this recommendation is not accurate for all the scenarios.
Scheduling report HRALXSYNC as a background job is to synchronize the changes from HR side to SRM system.

If HR replication is not active, it is not mandatory to schedule this report.

Topic Two:

Address column is always showing red light while using report HRALXSYNC to check organizations.

This check is done in form PROVE_VALIDITY_ORGOBJECT:

This check only happened when you set OADRE as X which means address is necessary.

At this time, if the address is incomplete, such as email is not maintained for organization, it will show red light in address column.
If you do not want this check, just remove X for indicator OADRE.

To be continued...

I believe most of you are already aware of deleting entries in normal tables. However I will repeat this again in this blog:

1, go to se16 to display the table(For example VENMAP which is allowed for maintenance)

2, double click the entry to display it;
3, write /h in the command field and press Enter on your keyboard;

4, press Enter again to access debug mode, and change 'code' field to 'DELE';

5, 'Delete Entry' button is shown and you may delete this inconsistent entry.

However this method is only working fine for tables which are allowed for maintenace.
What about table with read-only access? Such as HRV1222A. Let me show you an example how to delete the entry in such tables.

If you encountered the following error while editing attributes in user settings, it means that you have inconsistency entries in table HRV1222A.

For attribute 'SCENARIO', it should never have entries with object S. The only way to solve this is to delete the entry in table HRV1222A.
But it is read-only table, and the method above is not working for it.

We also tried to create Z-report using SQL statement to delete such entries, but still failed.

So the only possible way is to delete the entry in the linked table. For HRV1222A, it is linked with HRP1222 and HRT1222.

For HRP1222, it is linked with too many attributes for the same object, so this should not be deleted.
For HRT1222, there is only one entry linked to same object and same attribute 'SCENARIO'.

So deleting the corresponding entry in HRT1222 is enough. After this, the corresponding entry in HRV1222A will also be deleted.

Do you have any opinion on this? Welcome to share your experience with me!

REQUIREMENT: Configure a notification (acceptance/adjust) to the requester of the document in case a document is been rejected by approver.

STEPS TO BE FOLLOWED:

1. Go to Transaction (T-code): /SAPSRM/WF_PROCESS.

    2. Select the concerned business object in our case it is the shopping cart (BUS2121) and double click on the process schema definition.

  3. The following screen appears with all the schema’s for the business object.

     4. Now select a process schema and double click on acceptcance by contact person, the following screen appears we need to select the process schema and the evaluation ID and task id(40007994 always the same) .

     5. In our case we created a custom evaluation ID with the custom expression.

6. For the custom expression we selected the expression type as 0FB001 (CL_FORMULA_BRF).

  7. Click on the Formula Editor to create the formula and maintain the formula 0V_WF_CURRENT_DECISI = 'REJECTED'.

Whenever a document is rejected by the approver it will notify the requester with Accpet/Adjust workitem and he will make the concerned changes and resend it for the approval.

With so much hullabaloo about HANA, what is in there for Clients who are currently using SRM?

Where are the business benefits envisaged? Is it just ‘improvement in performance’ or are there any process improvements just on account of HANA?

Performance perspective:

Firstly, with HANA’fication of SRM, SAP has clearly promised substantial performance improvement in areas where SRM 7.0x has historically been blamed for being painfully slow, as much as 6 to 8 times in various scenarios. For instance, the Personalized Object Work List (POWL) refresh and search speed for SRM Shopping carts and Purchase orders are indicated to go up by 7 times and those for SRM Contracts go up by 5 times, and Sourcing cockpit search speed goes up by 7 times.

Process perspective:

Secondly, from a process perspective, the one ‘strategic’ pointer we see coming from SAP now is that they are bringing in ‘shopping cart requisitioning’ within S/4 HANA itself (though there is no news about a road map on the rest of the functionality). The grand vision, from what one hears is that processes currently running out of SRM (and other external SAP boxes like CRM, SCM) would eventually get merged into S/4 HANA. However, this is possibly expected to happen in few years from now though it is not known how soon in the future.

Database perspective:

Thirdly, it is important to note ‘SRM on HANA’ does not involve ‘data model’ optimization as in the case of Simple Finance or Simple Logistics where SAP has optimized the number of database tables. In other words, it simply means SRM, instead of running on Oracle, SQL Server or other databases, once migrated, would then run on HANA database with the table structures remaining AS-IS.

All of the above perspectives in mind, as trusted partners to the global SRM clientele, how do we brace ourselves for a Client query on this important emerging topic?

At the outset, SRM can be HANA’fied only with SRM 7.03. In other words, if Clients are currently running SRM 7.02 or earlier version, there will be need for an upgrade to SRM 7.03 with migration to HANA.

Finally, on compatibility of an 'SRM 7.0x with or without HANA’ system with ‘back end’ SAP systems? Depending on the Client's current circumstances and immediate future plans, the following combinations will be fine:

• ‘SRM 7.0x’ (w/o HANA) integration to ‘SAP ECC EhPx on HANA’

        (or)

        'SRM 7.0x (w/o HANA)' integration to ‘SAP S4 HANA’ system

• ‘SRM 7.03 on HANA’ integration to 'SAP ECC EhPx (on other databases)'

        (or)

        ‘SRM 7.03 on HANA’ integration to 'SAP ECC EhPx (on HANA)'

        (or)

        ‘SRM 7.03 on HANA’ integration to ‘SAP S4 HANA’ system

• ‘SRM 7.03 on HANA’ integration to a mix of multiple back end systems, ‘ECC EhPx (on HANA or on other databases)’ and ‘S4 HANA’ systems

Make your recommendations accordingly - I hope the above note helps clarify some of the haziness in your minds!!!

This document will describe the transfer of data from ECC PR Customer fields present in EBAN to SRM SHC Customer fields present in BBP_PDISC table.

For this i assumed the below prerequisites should be completed.

1. Enhance the relevant structure through SPRO Extensions and Field Control (Personalization)->Define Customer Fields on Item Level in SRM.

2. Append the structure of customer fields in EBAN in  ECC.

Solution:

To achieve we need to complete only below 2 steps.

Step 1:

Structure to be enhanced in SRM - BAPI_SC_ITEM_CUST_C

Structure to be enhanced in ECC Side - BBPS_ER_SC_ITEM_CUST_C_PI

Step 2:

Map the data from EBAN customer field to structure( of type BBPS_ER_SC_ITEM_CUST_C_PI) fields in BADI BBP_BADI_EXTREQ_OUT in ECC.

Now the data will be transferred automatically as per the configuration described in below analysis section.

Analysis:

RFC FM BBP_BC_EXTREQ_INB is called from ECC BADI (BBP_BADI_EXTREQ_OUT) in SRM during PR Transfer.

During this RFC FM call, internal table ITEM_CUST_IMP from ECC BADI has been mapped to SRM RFC FM table I_ITEMS_CUST.

ITEM_CUST_IMP is of type BBPT_ER_SC_ITEM_CUST_C_PI (in which customer fields are added in ECC)

I_ITEMS_CUST  is of type BAPI_SC_ITEM_CUST_C (in which customer fields are added in SRM)

Till now data from customer field has been transferred to SRM but still not mapped to shopping cart custom fields, for that Inside the below path there is move corresponding statement to SC item level custom field.

RFC FM BBP_BC_EXTREQ_INB -> FM BBP_EXTREQ_INBOUND -> FM BAPI_SCEC_CREATE -> Perform map_bapisc_to_sc

MOVE-CORRESPONDING bapi_items_cust to bbp_sc_item.

bbp_sc_item is of typebbp_pds_sc_item_icu.

bapi_items_cust is of typebapi_sc_item_cust_c.

Let me know in case any further information is required for clarification.

Regards,

Arpit

Few weeks before I have been put into SAP SRM UI5 implementation and I was very excited to say the least. I finally got a chance to work on UI5 in real project. My first task was to add a custom field in UI5 screen, to be more specific on Minicart view.

I took the Extensibility cook provided by SAP and followed the instructions (Although I would say the document is not up to the level of “SAP” documentation in terms of quality of content). I finally managed to complete the task and everything was working fine. Below is the entry in customizing

Everyone was happy except me

The question that was making me uncomfortable is this.

We have add some metadata related to custom field in SPRO (in ABAP) and we see the field in UI5 (which is built HTMLS5 and JavaScript etc.).  If this was done in ABAP webdynpro, I wouldn’t have written this blog, because we have UI rendering classes in webdynpro which takes all the pain of converting webdynpro layout into something that browser understands. But in case of UI5 that is not the case. The communication between UI5 and ABAP happens through OData (at least pertaining to the case that I am talking here). So, how on earth the data entered in configuration is read from SPRO and taken into JavaScript code and used to build required controls (control here means UI element) and added to the layout. This was the big question???

This blog is a small answer to it. So if you don’t care to know how this is achieved in SAP code, you can stop here. Otherwise you can proceed and get ready for some cool stuff

First step that I did was to keep HTTP trace for the logged on user in ST05 to see what Odata calls happens when we click on “Shop” from the UI.

In transaction /IWFND/MAINT_SERVICE execute service GETDEFUSRSET for entity set “DefaultUserSettings”. Here I see in field ‘FIELD_EXT_JSON’, contains all the information that we maintain in SPRO. You can go through the class /SRMNXP/CL_DA_DEF_USER_SETTING method GET_EXT_FIELD_FILEP_JSON to know exactly how this data is extracted.

For better understanding, same data is shown here in another editor

This data comes to shopping cart UI5 application /SRMNXP/SHOPPINGCART ( you check different JS files available for this application in SE80 by selecting BSP application) and here by some magic (I will reveal the secrets shortlyJ).  I have installed “UI5 Inspector” add-on to my chrome browser. You can get this from below link

https://chrome.google.com/webstore/detail/ui5-inspector/bebecogbafbighhaildooiibipcnbngo?hl=en

Now login to shopping cart UI5 application either directly from SICF or from NWBC, then click F12 to open debugger and go to UI5 tab at the top right corner of the debugging window. Here you can select the row at right hand side and browser highlights the related UI element on left. I can see there is a label created with id “wi_common_miniSC_hd_DESCRIPTION_L” and input field with id “wi_common_miniSC_hd_DESCRIPTION”.

The view Js file corresponding to minicart is MiniCart.view.js. You can look at the code of this file in SE80 by going to BSP application /SRMNXP/SHOPPINGCART.  From within this view calls go to different methods in different Js file. Below I mentioned the important methods in the call stack

Call stack

Below I have explained in more detail about the important methods in Extensibility.js

Method getControlDefinitionByJSON

Inside this method Configuration data that is sent as JSON data is analysed. In each JSON element, VFD node is checked. For every entry in VFD node, method generateIdForViewField method is called. Inside this ID of the new control is built by concatenating “view name”, “_” and “field name”. In our case view_name is “wi_common_minisc_hd” and field name is “DECSCRIPTION”. Also based on the values entered in the configuration, different properties of the control are assigned

• ontrol.controlType =  json[i].VFD[j].CONTROL_TYPE;

        control.text = json[i].VFD[j].TEXT;

        control.tooltip = json[i].VFD[j].TOOLTIP;

        control.bindingPath = json[i].VFD[j].BINDING_ELEMENT;

        control.maxLength = json[i].VFD[j]['MAX_LENGTH'];

Here the search help assignment and search help field mapping is also done. So in short the control in its full avatar is ready once we come out of this method.

Method generateLayout

Next method that gets called is generateLayout.  In this method based on the import parameter format, different methods get called. ‘ML’ stands for Matrix layout etc.  In our case minicart view is built using MatrixLayout

switch(format)
{
case "ML":
return(this.generateMatrixLayout(controls, sectionHeading, format, bindMetadata, style));
break;
case "VL":
return(this.generateVerticalLayout(controls, sectionHeading, format, bindMetadata, style));
break;
case "RAW":
return controls ;
break;
default:
return(this.generateMatrixLayout(controls, sectionHeading, bindMetadata, style));
}

In generateMatrixLayout method we have another important method called generateControl. In this method, based on the control type (this is entered in configuration), different methods are called. In our case we have maintained ‘TF’ in configuration, which means an Input field.

switch (controlDefinition.controlType)
{
case "TV":
return(this.LG.createTextView(controlDefinition.id ,controlDefinition.text,controlDefinition.tooltip, controlDefinition.bindingPath, format, bindMetadata, style));
case "TF":
return(this.LG.createInputField(controlDefinition.id, controlDefinition.text,controlDefinition.tooltip, controlDefinition.bindingPath, format, bindMetadata, style, controlDefinition.maxLength));

case "CB":
return(this.LG.createCheckBox(controlDefinition.id, controlDefinition.text,controlDefinition.tooltip, controlDefinition.bindingPath, format, bindMetadata, style));

Inside createInputfield method, input field along with label is created (for label ‘_L’ is added at the end of the id to differentiate it from input field ID). So we have label control with ID “wi_common_miniSC_hd_DESCRIPTION_L” and input field control with id “wi_common_miniSC_hd_DESCRIPTION”.

After method generateLayout call comes back to buildcontent method and then createcontent method of MiniCart.view.js. So we came back to the place where we started

In my Next blog I will try to write about CUSTOM_PRE_EXIT and CUSTOM_POST_EXIT

Keep sharing and keep reading…

I often heard of someone complaining about why material middleware needs to do so many customizing, or someone would say that they could make material replication run well without setting all the customizings. I ever had the same feelings whenever helping customers to check all the customizings one by one.

However, if we could understand the functionality of each customizing, it would become easier to find the key point in your material middleware to recognize the root cause.

Now I would like to share my understanding about these customizing places and give you some useful tips if your middleware is not working suddenly.

First I will list all the important SAP notes, KBA notes, important transactions and settings. Some of you might already be aware of them:

A, Useful notes:

720819 - Middleware consumer entry for SRM in OLTP system

1498111 - No authorization for data selection in initial load

1501685 - Table CRMATAB is empty

B, Useful KBA notes:

KBA 1553940 - First checks to Material and Product Category transfer errors

KBA 1717049 - Material Master Basic data text not replicated to SRM

KBA 1823682 - Material description is not transfer to SRM or characters are appearing as #

C, Useful t-codes:

R3AM1 - check the status of all the objects

R3AS  - do initial upload of material from ECC to SRM

SMOEAC- check CRM RFC-destination and Consumer

SMW01 - check errors

SMW02A- check errors

R3AC3 - filter for different objects and also check consumer set

SMQ1 - check outbound queue in ECC side

SMQ2 - check inbound queue in SRM side

D, Useful tables:

ECC table NDBSMATG16 : store guid of material

ECC table NDBSSRVG16 : store guid of service master

SRM table comm_product: store product id and guid of material(01) and service master(02)

ECC table CRMPRLS : store system guid

SRM table CRMMLSGUID : store system guid

Then let me give you some tips in making use of the above information:

Tip1:

Sometimes, you might encounter dump MESSAGE_TYPE_X in ECC side while replicating materials. First you will check if ECC table CRMATAB is empty or RFC user has MW_ADMIN role in ECC side according to 1501685 & 1498111. However sometimes this still doesn't work after this.

At this time, I suggest you check if you maintained such an entry in ECC table CRMRFCPAR:

Both 'Object Name' & 'Load Type' are set as * which will introduce such kind of issue.

So please strictly follow the steps in note 720819 to maintain entries in this table.

Tip2:

If r3am1 shows red light for some objects, you should first check the SMQ1(ECC side) and SMQ2(SRM side) to see if there are some sysfail entry there.
If so, check the specific error reported. If it is an exception, usually it will be raised in ECC side in t-code st22.

If no stuck entries in outbound and inbound queues, then you should go to SMW01 or SMW02A to check if there is any specific error for materials in SRM system. With the error information and simple guide, you will find the root cause.

Tip3:

Sometimes material middleware is not working suddenly after system upgrade or system copy.
The first thing is to check if the guid in SRM table CRMMLSGUID and ECC table CRMPRLS is identical.

To correct this, use Z-report in SAP note 765018 to make them consistent.

Tip4:

For SM59 RFC connection, you must be already aware of some points, such as RFC user should have MW_ADMIN role assigned, language should be blank for RFC user. However sometimes, unicode setting will also affect material replication.

How can we judge if ECC system is a unicode system? Go to System => Status

After judgement, you may read note 1155841 to maintain all the parameters.

Tip5:
All the places to set 'Consumer' should be consistent, or else the material replication can't find the target system.

In ECC side, you have to make sure all the 'consumer' or 'user' fields have consistent name, such as 'SRM'.
CRMCONSUM

CRMSUBTAB

CRMRFCPAR

CRMPAROLTP

In SRM side, you have to make sure all the following places are having the same consumer name such as 'SRM'.

SRM table: SMOFPARSFA

t-code SMOEAC: please make sure the name is the consumer name

t-code R3AC1: please make sure consumer is set correctly for both material and service

t-code R3AC3: please make sure consumer is set correclty for other objects, such as DNL_CUST_PROD0

Tip6:

The last point I would like to remind is the filter settings. Some of you might forget you ever set some filters in ECC or SRM side.
ECC side: table CRMFILTAB is used to store filter settings
SRM side: R3AC1 & R3AC3 have filter tab to synchronize filter from R3

I will update this blog if I have more good experience to share with all of you.

Welcome to any feedback if you are interested in this topic.