Skip to Content

Lesson Learnt – Plan Driven Procurement Issue

PDP Scenario SRM 5.0 Vs SRM 7.0

PDP Issue

____________________________________________________________________________________________________________________________________

PDP SRM 5.0 Configuration Settings :-

Settings on SRM side:

  • Set up RFC Channel in ORG Structure
  • Assign RFC user to this RFC Channel
  • Assign Purchase Group to this RFC Channel
  • Set up Sourcing Configuration

Settings on ECC side:

  • Maintain tables V_T160EX and V_T160PR
  • Schedule the report BBP_EXTREQ_TRANSFER

Note- Communication between SRM and ECC is through RFC.

PDP SRM5.0.jpg

_____________________________________________________________________________________________________________________________________

PDP SRM 7.0 Configuration Settings:-

Note- From SRM7.0 , ECC6.0 (EHP4) ESOA is used so PI will be used for communication between ECC and SRM

Settings on ECC side:

  • Activate Business Function LOG_MM_P2PSE_1
  • Implement Badi  ME_REQ_SOURCING_CUST – controls transfer of the Purchase Requisition from ERP to SRM
  • Activation of workflow in ERP for BUS 2105 WS53800009 for events change, created, sourcingrequested (Tcode SWETYPV)

_____________________________________________________________________________________________________________________________________

PDP Issue- Purchase Requisition is not getting Transferred from ECC to SRM

Landscape- SRM 7.01 and ECC 6.0 ( EHP5)

Solution:

  •   Purchase Requisition data is send from ECC  through Function Module MMPUR_Trigger_Message to SRM. There is a table “T175ESOA_TRIG_C” in ECC which checks for Q registration ie if you want to send manually via SMQ1 then you can mainatin the entry in the table else if you want to send it automatically then do not maintain the entry.
  • BAdi implementations  on ECC side were inactive (Enhancement: PUR_SPOT_SE_PURCHASE_REQUEST, bAdi: PUR_SE_PRERPSOURCINGRQCO_ASYN). So , activated these implementations. This Badi implementation is required for XML message communication as a part of ESOA.
  • Attribute of the PI user – BUK (company code ), BWA ( Movement type – ’101’, ‘201’ ) was missing.
  • PI user should not locked.

Thanks,

Ashish Garg

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