Skip to Content
Author's profile photo Former Member

Update SRM SC Requestor from ECC PR Requestor in PDP via SAP PI or ESOA.

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 1st 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 2nd 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 EBANERNUM) 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 EBANERNUM (it will be different as per the

                                      requirement).

Below is the snapshot of BADI details.

ECC  BADI.jpg

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

ECC BADI  Method.png

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

ECC Strcture .jpg

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.

SOA in SRM .jpg

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

SRM Method.jpg

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


Strcture at SRM Side.jpg

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) .

update context .jpg

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.

Result .jpg


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  .

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo M H Jani
      M H Jani

      i am not getting solution after implemented BD_SOA_MAPPING badi in ECC system break point triggered on PI RFC user and NOT ANY BREAK POINT triggred in ECC system after implement PUR_SPOT_SE_PURCHASE_REQUEST BADI. Requested to share document with me.