Section  1.1:Overview & Purpose of Document : We create a Purchase Requisition with an outline having  service hierarchy it goes to the sourcing application where we can assign the Supplier .  However the standard behavior says as below

“In SAP SRM 7.0, if the item you want to source is a hierarchical service that originates from the SAP ERP system (MM-SRV), the system automatically creates a back-end contract. As of enhancement package 1 for SAP SRM 7.0, if you have activated the business function SRM, Service Procurement Innovations (SRM_SERVICE_PROC_1) and the Customizing switch Central Contract Management (SRM_701_SERV_PROC_CCM), a central contract is created by default in SAP SRM. In the central contract, the strategic purchaser can define to which back-end system or systems the contract is replicated. This means a contract is created in a back-end system with reference to the central contract in SAP SRM”^[Ref1]

However the client requirement was it should use an existing source of Supply and a central contract which is already created should be assigned to the line item and not to create a contract in an attempt to assign .

Example: We create a SC with line items seen as hierarchy . 

001 Outline level Hierarchy

002 Line items 3000012

003 Line item 3000013

In this case for the services there is already an existing contract in SRM which is not defined in backend so it was picking up the choices and giving in Source of Supply tab . Remember incase of hierarchy you can only assign to the outline level and not to each line item as you wont get the source of Supply tab for each line item but only for the outline level .

Now as seen in figure I we see the below list of contracts having materials as follows .

7000001251     :  3000012

7000001268     :  3000012 , 3000013

7000001238     : 3000000 , 3000012 , 3000013

SC line items    : 3000012 , 3000013

NOTE : ** Is it correct that Contract marked in red be displayed in Source of Supply tab ? We can only assign contracts at header level and since if it doesn’t contain all line items why should it be applied ?

When a contract is proposed as a SoS in service procurement scenario, the price of the outline will be shown for all items. This is because, price determination for individual services from the contract is not done in Sourcing application^[Ref2]

Now we try to assign the contract shown in the SOS tab by clicking on Assign Supplier and get the error

Line 1.2: Product '' deviates from product '0000000000000000000000000000000003000012' in corresponding contract item

Reason : Because the nature of the contract  has to be same as SC item^{[Ref2 ]} which is hierarchy and it is trying to match the line item hierarchy and contract and getting the error . And if you debug you would realize that it is assigning the first level item to the hierarchy item and the reason why it gets an error since there becomes a line mismatch .

Section 1.2 :Issue Faced : Hence there are 2 issues with the existing functionality .

Issue 1 : Contracts not covering all line items are also shown . why should the contract 7000001251 be displayed since it only pertains to one item and if we assign the same it would not help as only one item would be included in contract .

Issue 2 : Contracts created in SRM are not been able to assign to hierarchy line items . Also rem we cannot create hierarchy type of contracts in SRM hence there is no way where we can match the TYPE of contract and SC line item incase hierarchy . It gives the Error message 179 Class bbp_pd  in SRM .

Suggested Solution  : We will make changes at 2 places :

CHANGE 1 : Source of Supply Tab to display only those Contracts which match and have all line items as that of SC .

CHANGE 2 : To assign the correct line item of contract to outline Line item .

SECTION 2.1 [CHANGE 1] : Go to the BADI BBP_SOS_BADI and to the method METHOD if_ex_bbp_sos_badi~bbp_sos_check.
Note : This method is called when you click on SOS Tab of the SC the first time and it will get the list of contracts based on the code here . Thus we make the changes incase of services hierarchy items it should run and should fetch only those contracts which have all items of SC . Also remember this would be done when the Approver is a SRM user with a Sourcing role . This wont run for Requestor since the requestor cannot create a Hierarchy item in SRM .

IF ct_found_contract[] IS NOT INITIAL    " If contarcts exists for the vendor material combination then go ahead
AND sy-uname <> ls_tvarvc-low.

“When User is not DE1 Remote to ensure it is run only when the user is approving and not creating a SC in which case it would be system user .

    CALL FUNCTION 'BBP_PD_SC_ITEM_GETDETAIL'
EXPORTING
i_guid = is_search_criteria-pos_id
IMPORTING
e_item = ls_sc_item.                        " Getting a list of all SC items .

IF ls_sc_item IS NOT INITIAL AND
ls_sc_item-product_type = c_service.                    " Only to be run incase of services .

CALL FUNCTION 'BBP_PD_SC_GETDETAIL'          “ To get SC item details
EXPORTING
i_guid   = ls_sc_item-header
IMPORTING
e_header = ls_sc_header
TABLES
e_item   = li_sc_item.
IF ls_sc_header-subtype = c_er.
DELETE li_sc_item WHERE parent NE ls_sc_item-parent .
IF li_sc_item IS NOT INITIAL.
LOOP AT ct_found_contract INTO ls_found_contract.
l_index = sy-tabix.
CLEAR li_ctr_item.
CALL FUNCTION 'BBP_PD_CTR_GETDETAIL'
EXPORTING
i_object_id = ls_found_contract-ctr_hdr_number
TABLES
e_item      = li_ctr_item.
IF li_ctr_item IS NOT INITIAL .
SORT li_ctr_item BY ordered_prod.
LOOP AT li_sc_item INTO ls_item.     “Comparing SC item and Contracts Item
READ TABLE li_ctr_item TRANSPORTING NO FIELDS WITH KEY ordered_prod = ls_item-ordered_prod  BINARY SEARCH.
IF sy-subrc <> 0.     “If an item is not found in the contract and it found in SC                   DELETE ct_found_contract INDEX l_index.  “ delete the contract
ENDIF.
ENDLOOP.
ENDIF.
ENDLOOP.
ENDIF.
ENDIF.
ENDIF.

SECTION 2.2 : CHANGE 2:In Doc change BADI we make the below changes in code :

It will be called when the user clicks on “Assign Supplier” button in the SC it will help assign the contract to the outline item

Where it will make   <fs_item_u>-ctr_item_number = ls_item_ctr-number_int and resolve the error

ELSEIF es_header-subtype = c_er                                         " Only if External Requirment
AND ls_processdecisionset_list[] IS NOT INITIAL “Only for Approvers not for requestor
AND sy-uname NE ls_tvarvc_rfc-low
AND iv_mode = c_mode_u                          " Update Mode
AND iv_save NE c_x.
READ TABLE et_item INTO ls_item_serv INDEX 1.
IF sy-subrc EQ 0 AND ls_item_serv-product_type EQ c_service AND ls_item_serv-ctr_hdr_number IS NOT INITIAL.   " When contract is assigned and service product type
CALL FUNCTION 'BBP_PD_CTR_GETDETAIL'
EXPORTING
i_object_id = ls_item_serv-ctr_hdr_number
TABLES
e_item      = li_item_ctr.
IF li_item_ctr IS NOT INITIAL .  
SORT li_item_ctr BY ordered_prod .
LOOP AT et_item ASSIGNING <fs_item_u> WHERE product_type = c_service.
READ TABLE li_item_ctr INTO ls_item_ctr WITH KEY ordered_prod = <fs_item_u>-ordered_prod BINARY SEARCH.
IF sy-subrc EQ 0.
<fs_item_u>-ctr_item_number = ls_item_ctr-number_int.
ENDIF.
ENDLOOP.
ENDIF .
ENDIF.

REFERENCES :

Ref 1http://help.sap.com/saphelp_srm701/helpdata/en/ba/c346a35c2e4aa78bfeb99f60a40266/frameset.htm

Ref 2 : http://www.stechno.net/sap-notes.html?view=sapnote&id=1476447

Objective :

Deactivate the User Settings in the Context menu from Webdynpro Applications Globally in SAP System.

Procedure :

     > Go to Transaction Code SICF.

     > Enter WD_GLOBAL_SETTING in the service.

     > Select the WD_GLOBAL_SETTING node and right click on it.

     > Select the Test Service from the menu.

     > Select the Check box "Do Not Allow Personalization by User"

     > Press "Save Data".

This will Deactivate the User Settings in the Context menu from Webdynpro Applications Globally in SAP System.

Hello Gurus,

Recently I have encountered an error as mentioned in the subject line.

Since SRM 7 EHp1 SAP has provided a Switch where on activating Switch : SRM_701_SHIP_TO_ADDRESS_SC users can maintain there Ship to Address from Portal it self.

Personalization>>>My Address

On maintaining Address number gets saved in table : BBPD_ES_EEWA with the combination of Address number and Person number but it is also mandatory system should also maintain the entry in ADCP table like of BUT020 and BUT052.

Entry was missing for user in table ADCP in reference to BBPD_ES_EEWA.

Address consistency checks BP address number maintained in BUT020, BUT052 and BBPD_ES_EEWA "if switch is activated" and compare the entries in ADCP for the three table, if it is not there then give error.

Please find the attached code for correct the ADCP entries in reference for BBPD_ES_EEWA.

Report : zdelimit_address_data find an attachment.

Feel free to revert, if there are any concerns.

Regards,

Neeraj Dua

References

• Note:1287412 - Prerequisites for OCI integration in SRM 7.0
• Open Catalog Interface 5.0, OCI5, Specification: http://scn.sap.com/docs/DOC-35441 by Michael Judd (including the link where to find it on SAP Service Market Place) – OCI 5.0 is not an evolution, but more a revolution from OCI 4.0, they can co-exist though.
• Forum post: Is it possible to change/delete the hidden parameter sap-client of the OCI-Call?

General

This document is related to Punchout Catalogs, also known as OCI 4.0. I referenced the OCI 5.0 document as it is more up to date with the latest additions to the OCI 4.0 specification.

For a better view of the possibilities of OCI 5.0 the above mentioned document will be of further help.

The information is mainly aimed at SRM consultants seeking a better understanding of OCI 4.0, debugging the interface itself and at suppliers wanting to make their catalog OCI 4.0 enabled. SRM 7.0 EhP1 using the inbuilt HTML-NWBC is the SRM server version that is used as reference.

I won’t get into any detail regarding the return parameters as they are documented enough in the OCI 5.0 document.

The OCI interface is a simple protocol that launches a supplier catalog using a simple HTTP get or post command, also the return from the catalog is a simple post back to SRM.

OCI call

SRM customizing

The call to the external catalog is maintained in SPRO customizing, from SRM 7.0 onwards you should always use the standard call structure option. You can find it under:

SPRO -> SAP Supplier Relationship Management -> SRM Server -> Master Data -> Content Management -> Define External Web Service

In the call structure you define which parameters should be send to the external catalog, the above example (a call to Ariba Procurement Catalog) is one with a lot of variables. The simplest variant that works (but might not be completely up to the standard ;)) is a simple:

Outbound handler

The outbound handler is a new addition in SRM7, what it does is that it doesn’t call the external catalog directly, but opens it in a window using an iframe and a back link and adds some processing that wasn’t done anymore due to the change of using WebDynpro technology from the older ITS:

You can disable it in the call structure in the customizing using the parameter “BYPASS_OUTB_HANDLER” and set the value to X so that the old logic is used.

For the inbound handler the same procedure can be used but then the parameter is called “BYPASS_INB_HANDLER”.

Call sequence

Before the actual call to the external catalog is made SRM goes through a few more routines, getting some more variables using the BBP_CAT_CALL_ENRICH badi, creating the iframe and finally calling the catalog.

In the above screenshot the POST entries are the most interesting. The first 3 are calls to the SRM system itself (or portal).

To find the classes that handle these posts you will have to check transaction SICF and find the corresponding handlers of the called URL.

• The first POST is an internal call to the shopping cart webdynpro when pressing on the link to open the external catalog.
• The 2^nd POST is handled in class CL_NWBC_HTTP (remember this document was created with the HTML-NWBC client).
• The 3^rd POST is handled in class /SAPSRM/CL_CH_WD_OUTBOUND_HDLR, if you want to see how the HTML data is created this is the class that you want to check out. See for some more information the thread on the forum which is mentioned in the references at the top.
• And finally the last POST which is the actual call to the external catalog, the data that is used here is actually the same that was used in the 3^rd POST.

For debugging purposes you can place external breakpoints in each of those classes, another good spot to put a breakpoint is function module /SAPSRM/CLL_WSI_CALL (or WSI_CALL in SRM5.0).

If we take the most basic catalog call structure the final HTML form contains the following parameters:

As you can see, SRM makes the call OCI 4.0 compliant itself!

BBP_CAT_CALL_ENRICH

If you need to dynamically enrich the catalog call you can implement the BBP_CAT_CALL_ENRICH badi, for example if you want to add an attribute that is maintained in the organizational model for the user that calls the external catalog for instance. In SRM a standard implementation is available (BBP_BUSINESSCARDS), to take a look at this go to SE18, in the Badi name fill in the BBP_CAT_CALL_ENRICH and click on Enhancement implementation -> Overview in the menu.

Below a small example of the main thing to do from the example badi:

" Tel-No
 READ TABLE it_data_tel INDEX 1 INTO wa_data_tel.
 wa_post_values-fieldname = 'Telephone'.                   "#EC NOTEXT
 wa_post_values-fieldcont = wa_data_tel-tel_no.
 APPEND wa_post_values TO ct_post_values.

OCI return

The OCI return is again a simple HTML form, containing all the item data that the user selected during his stay in the external catalog. The main thing to keep in mind here is that when you receive the HOOK_URL parameter that you have to save it in a session/cookie or database as-is. Whatever you do with it – don’t change it! You will need the exact string again when the shopper wants to return SRM.

Example taken from note 1287412:

b. Target

Specifies the frame to which a catalog is to return data in a frame-based environment.

Catalog providers must ensure that they post to a specific target which is defined and supplied by SRM. This can be verified in the "form tag" in the HTML that is sent by the catalog:

 

<form action="<Hook URL sent by SRM>" target="<value of returntarget sent by SRM>" method="POST">

#

</form>

Complete example:

<form action="@ViewBag.hook_url" method="post" target="_top">    <input type="hidden" name="~caller" value="CTLG" />    <-- Item 1 -->    <input type="hidden" name="NEW_ITEM-DESCRIPTION[1]" value="Article number 1">    <input type="hidden" name="NEW_ITEM-QUANTITY[1]" value="1">    <input type="hidden" name="NEW_ITEM-UNIT[1]" value="EA">    <input type="hidden" name="NEW_ITEM-PRICE[1]" value="250">    <input type="hidden" name="NEW_ITEM-PRICEUNIT[1]" value="1">    <input type="hidden" name="NEW_ITEM-CURRENCY[1]" value="EUR">    <input type="hidden" name="NEW_ITEM-LEADTIME[1]" value="10">    <input type="hidden" name="NEW_ITEM-VENDORMAT[1]" value="5433334">    <input type="hidden" name="NEW_ITEM-MANUFACTCODE[1]" value="AN1">    <input type="hidden" name="NEW_ITEM-EXT_QUOTE_ID[1]" value="">    <input type="hidden" name="NEW_ITEM-EXT_PRODUCT_ID[1]" value="">    <input type="hidden" name="NEW_ITEM-EXT_SCHEMA_TYPE[1]" value="UNSPSC">    <input type="hidden" name="NEW_ITEM-SERVICE[1]" value="X" />    <input type="hidden" name="NEW_ITEM-EXT_CATEGORY_ID[1]" value="43100100">    <input type="hidden" name="NEW_ITEM-MATGROUP[1]" value="43100103">    <input type="hidden" name="NEW_ITEM-PARENT_ID[1]" value="">    <input type="hidden" name="NEW_ITEM-ITEM_TYPE[1]" value="">    <-- Item 2 -->    <input type="hidden" name="NEW_ITEM-DESCRIPTION[2]" value="Article Number 2">    <input type="hidden" name="NEW_ITEM-QUANTITY[2]" value="1">    <input type="hidden" name="NEW_ITEM-UNIT[2]" value="EA">    <input type="hidden" name="NEW_ITEM-PRICE[2]" value="250">    <input type="hidden" name="NEW_ITEM-PRICEUNIT[2]" value="1">    <input type="hidden" name="NEW_ITEM-CURRENCY[2]" value="EUR">    <input type="hidden" name="NEW_ITEM-LEADTIME[2]" value="10">    <input type="hidden" name="NEW_ITEM-VENDORMAT[2]" value="5433335">    <input type="hidden" name="NEW_ITEM-MANUFACTCODE[2]" value="AN2">    <input type="hidden" name="NEW_ITEM-EXT_QUOTE_ID[2]" value="">    <input type="hidden" name="NEW_ITEM-EXT_PRODUCT_ID[2]" value="">    <input type="hidden" name="NEW_ITEM-EXT_SCHEMA_TYPE[2]" value="UNSPSC">    <input type="hidden" name="NEW_ITEM-EXT_CATEGORY_ID[2]" value="43100100">    <input type="hidden" name="NEW_ITEM-SERVICE[2]" value="X" />    <input type="hidden" name="NEW_ITEM-MATGROUP[2]" value="43100103">    <input type="hidden" name="NEW_ITEM-PARENT_ID[2]" value="">    <input type="hidden" name="NEW_ITEM-ITEM_TYPE[2]" value="">    <center>    <input type="submit" value="Transfer shopping cart" id="submit1" name="submit1">    <br></center></form>

BBP_CATALOG_TRANSFER

The BBP_CATALOG_TRANSFER badi is called after coming back from the external catalog. The most common usage for this badi is to do a mapping from a general product category classification like UNSPSC to a company specific category classification. Other uses are the transfer of the CUST_FIELD1-5 fields to specific shopping cart item (customer) fields.

It is possible that you want to start debugging in case of problems before the badi is called. In that case take a look at the /SAPSRM/CL_CH_WD_INBOUND_HDLR class (if enabled) or in function module WSI_IMPORT_DATA.

Extensibility

It is possible to extend the OCI interface beyond the 5 customer fields that SAP provides, to enable this you have to create an append for structure CI_OCI_CUSTOMER_EXTENSION. The field that you maintain here for example ZEXTRA_FIELD can then be transferred with the extra hidden field NEW_ITEM[n]-ZEXTRA_FIELD. This is more useful if you have also control of the “external” catalog as most suppliers will want to have one single OCI form to work with (although it would be great if suppliers could add fields when the customer asks for it). Things that typically are asked for:

1. Indicator if the item should be handled as a free-text item
2. Tax code
3. …

In the OCI documentation a reference is made to include CI_BBP_SC_ITEM, I have never used this include and have always taken the more common INCL_EEW_PD_ITEM_CSF(_SC) to add customer fields to the shopping cart item data and fill those fields in the transfer badi.

Restrictions

The newly added hierarchy fields can only be used in a sourcing process using RFQ (wouldn’t it be great if you could add a hierarchy into a shopping cart to group certain items together!).

As per standard when a purchase order is created from SOCO or RFx response the status in ERP is "Order". Sometimes purchasers want to review or modify the document after release for authorization.

SRM 7.02 in Classic Scenario offer a easy customizing in order to control the purchase order status in ERP depending on purchasing group and backend.

1) Activate  business function SRM_SERVICE_PROC_1

2) In transaction SPRO will appear the following menu.

3) Run "Define Status for Purchase Orders in Back-End System"

4) Fill the table with the values according to your business model and Save. You can select between status "Park" "Hold" and "Save" .

From this moment onwards your Purchase Orders will be created with the status selected in the customizing below.

Hope This Help !

Celeste

It becomes difficult sometimes when functional consultants are asked to work with SAP over issues which require them to deactivate enhancements or

Deactivate implementation of BADI's,  for which they generally seek help from a technical consultants . The work typically is only of a few mins  and takes more than that so I thought I ll prepare a first hand guide to help them sail through making the changes smoothly . A more detailed one I would be creating soon ,

The below TOPICS would be covered :

SECTION 1. Deactivating Enhancements : If a SAP standard class features needs to be over written we create an enhancement for it .

SECTION 2. Deactivating BADI implementation

SECTION 3 . Sending transport from development to quality system after making the changes as above .

*******SECTION 1 ***************************************

1. Go to se19 and type in the enhancement name

2. You would see the Enhancement name for the standard object and double click on the program

3. If you would like to change the code in the enhancement click on the spiral Icon and  not on the display/ change one .

4. Once you do so the code would come in the change mode . However to edit it further you would need to Right click on the Enhancement Key word and select “ Change implementation” Once done ,you can comment the part of the code which is not needed .

*****************************************************************SECTION 2 ***************************************

SECTION 2 : Deactivating a BADI is not the same as commenting All the code . Remember it should have no existence in the system else it would give an error only if the code is commented ..

1. Open the BADI through se18 .
2. Click on Implementation >> Overview and it would take you to all the implementations of the BADI .

3. Click the relevant one for your object type and also note it should be highlighted in yellow .

4. Now you would see the Implementation and also the various methods associated with it .

The Run time behavior is a standard text filed which describes  whether the BADI implementation is active or not . As seen in Blue : “ Implementation will be called “

5. Now to deactivate the BADI . Click on the pencil display / Change  and you would see the “Deactivate” button would appear next to the Activate button . This is how the BADI should be deactivated if you do not want the custom implementation to work .

********************************************************SECTION 3**********************************************************************************

1. You must have made changes in developement system and created a transport now to have this in quality you need to Go to STMS transaction in quality system

2. In the transport system you would get development / Production / Quality landscape

  Since We generally move from Development into quality so we should do the changes in development and send the same to Quality. Thus click on the quality system .

3.  You would see the history of transports. Click on Refresh and you would see the latest transport with a discolored Rhombus figure as the last entry :

marked in yellow at the bottom of the screen . Keep cursor on the  same transport Number SRDK900686 and click on Half truck symbol  marked in Yellow at the top of the screen

4. As soon as we click on the half truck it will open another dialog box : Press the Ok green Tick button and it will get the transport to your system .

Now the entry for transport would be marked in Green and the changes in transport from Development would be carried on to the quality system .

Hope this document Helps I am creating an advanced guide as well on a few technical concepts and would share the same as well in some time .

Please leave your comments below and let me know your feedback as well .

There are some critical customer requirements which sometimes do not fall in line with the SAP Standard like in this case there could be some messages treated as Warning and let the requestor place the cart or create a contract when actually this is Critical to Quality for Business and need to be be changed to error to not let the requestor place the cart .

Or  for example there is a check which is SAP mandated as Error however the client’s business would treat this as an exception in their case and demand the check to be passed as warning .

So we all are aware of this whats new in here ? We generally check for the message in the code going to class se93 where it appears and then try to either overwrite it by our own custom code etc . However there is a SPRO path which we could use to make this change from Error to warning and thus it would meet the necessary checks as per the Clients need . 

Please check the below few examples based on client scenarios in production which demanded a change from error to warning if it has still not been an area of concern for your client you could anyway check with them if they would like to incorporate the same ?

1. SPRO Design changes  with some common example scenarios .

Below is the SAP SPRO path where we would make the changes :

  SAP Supplier relationship Management > >SRM server > >Cross Application basic settings >> Message control >> Influence Message control

Select BUS2121 Business object Row and Click on message control . Then you may click on New entry and enter the message details to change from Error to Warning or vice versa .

As per the below Table make changes in TYPE : (Make changes here from E to W or vice versa as per business need )

Below Listed are some most commonly changes Messages  Options in TYPE would be as below :

And standard messages could comprise something from the list : E : Error , W : Warning , I : Information

Examples :

• Making delivery date in the past : For requestor , Incase of approver for completion step etc allow this to be done make the message as warning where the user would be able to create and approve the SC with a delivery date of past the standard behavior in this case is in being error .
• Incase of creating a contract the vendor currency should be same as Contract currency this should be changed to error while standard being warning .

OTHERS :

If you haven't checked this as yet do touch base with your client specially in a new implementation project and you would be also  including this as a requirement soon .

Applies to:

All SAP’s Supplier Relationship Management version (technical) upgrade

Summary

This paper outline the basic aspects of an SRM upgrade any organization should know when considering or evaluating such projects. This will help facilitate a better overall approach to upgrade, reduce the hurdles, significantly plan well ahead to mitigate any risk and incorporate contingency.

Author(s):    Sachin Rao

Created on:  March 1^st, 2013

Author Bio

Sachin a Mechanical Engineer by education has been in the field of SAP consulting for over 8 years, having core expertise in the modules of SRM, MM and WM. He has worked on several projects in SAP comprising implementation, roll-outs and support engagements. He has a good understanding of the business and its drivers especially in Automobile, Chemicals and Petroleum and Banking Domain. He is also the author of the whitepaper ‘Need of Post Implementation Audits for ERP Implementation’ & ‘Due Diligence & ERP’

Introduction

From the stakeholder perspective there is a basic requirement for understanding the various aspects of an SRM upgrade. The purpose of this document is to provide this understanding and also outline the approach an organization has to / can take when considering upgrade to their existing versions of SAP SRM system. This also provides some insight on the impact from the technical and business process perspective. Although majority of the points covered will be part of any / many SRM upgrade project, however this may vary to the extent of emphasis each aspects may have based on the business, the client is involved in and how integrated the procurement function of indirect procurement is embedded within the organization.

Evolution SAP SRM since inception

The companies having SRM are on various versions ranging from BBP to EBP to SRM as listed below, the latest version being SRM 7.0 = SRM2008

SAP BBP 2.0B = SAP EBP 1.0 Basis 4.6C                 

SAP BBP 2.0C = SAP EBP 2.0 Basis 4.6D                    

SAP EBP 3.0 = SRM 1.0   Basis 610 (BBPCRM 3.0)          

SAP EBP 3.5 = SRM 2.0   Basis 620 (BBPCRM 3.5)                      

SAP EBP 4.0 = SRM 3.0   Basis 620 (BBPCRM 4.0)          

SAP EBP 5.0 = SRM_SERVER 5.0= SRM 4.0                   

SRM_SERVER 550= SRM 5.0                                 

SRM_SERVER 600= SRM 6.0 = SRM2007

All the SRM versions up till EBP 4.0 (SRM3.0) if upgraded then it has to be a 2 step process, one to upgrade it to SRM5.0 and then to SRM7.0. For all latter version a single step upgrade to SRM7.0 is possible.              

Context for Upgrade

To understand why an organization think of investing time and money in upgrading an existing system when an equal if not less cost has been invested in implementing the system.

There are some important factors which drives an organization to consider the upgrade of their existing system. The below are the list of factors majorly considered but not confined to these

• The support for the existing version of the system is running out in the near future, in which case the premium support will/may cost more than upgrading the existing system
• The existing system has been customized to such an extent that it had become difficult to support , add new standard updates to the system and due to this the cost of maintaining this system is high
• The existing version is not compatible with some of the latest interfaces of the business application

If any one of the above points fits into the consideration of any organization then there is a need to take the next steps in the direction of approach to upgrade.

Myth about Upgrade

Any SRM technical upgrade will not be a purely technical upgrade, this will come along with some functional changes which will impact the process to a certain extent like

• User Interface change because of the change from ITS to Webdynpro
• Change in the authorization objects impacting the roles defined in the previous version
• Migration of custom objects from the previous version to the new version may need some workaround in the new version to be embedded

Thus it will be worthwhile to start engaging with the business or process owners as early in the project as possible, this will reduce any noise coming from business and also help build a more efficient version of SRM with early collaboration.

Approach to Upgrade

• Before you get into making a plan for an upgrade, the first step to be taken is understanding if the upgraded version provides enough capabilities to support the existing business functionality
  • For doing this it will be worthwhile to have a workshop with Business and IT along with the expertise of the application/service providers to demonstrate the capabilities of the upgraded system
  • The outcome will give an indication if the techno-functional upgrade of the existing system will satisfy the existing business process with minor customization  or a new implementation of the latest version will be suitable
• Based on the decision that comes out of the above exercise then the vendor should be asked to do a technical assessment to get an overview of the Order of Magnitude (OoM), to get a ballpark estimate how much budget should be set aside for the upgrade project
• After the organization has the understanding of the OoM and agree on the budget then the relevant project can be initiated incorporating all aspects of the project at high level
• Once the project is initiated there has to be a Quick Upgrade Evaluation (QUE) done to understand the scope, pre-requisites, technical objects, dependencies, assumptions & effort estimate. In this stage a detail analysis of all
  • Scope – clearly demarking what entails in the technical upgrade like for ex- whether data migration is a part of the upgrade
  • Pre-requisites required for the upgrade is listed out like the database version, Operating system, etc
  • Technical objects – the details of the technical objects which will have to be migrated to the new version as part of the upgrade XXX
  • Dependencies for the upgraded version in terms of any new infrastructure ex – SRM MDM should be in place for catalogues
  • Assumption which will have an impact of not clearly mentioned has to come out in the scope
  • Project Estimate – this should give a clear breakdown of the activity list and the efforts for each of the activities
• At this point there may be some open questions which may still need to be probed into like the existing hardware is sufficient enough for the upgrade or additional sizing needs to be done to accommodate the requirements of the new version
• Once we have complete the above activities and have answered some or all of the open questions then the next step will be to come up with a detailed project plan
• When developing a detailed project plan the following additional points has to be considered and listed in the plan
  • Number of infrastructure components requirement and the elapsed time to procure them
  • Time and effort for building a temporary BAU landscape as the upgrade will be done in the existing Business- As- Usual landscape
  • Time and effort for building the training material for the new version and catalogue management tool SRM-MDM in this case
  • Training of the users in the new version and catalogue management tool SRM MDM
• After the detailed project plan is developed assigning roles against each of the activities the relevant resources must be mobilised to work in the direction of the plan
• Effective and elaborate Change Management Framework should be developed in order to manage the change of the upgrade on the business
• Extensive Training Strategy should be developed keeping in mind the extent of the changes in terms of localization and how it will be managed in training the users communities
• In some cases the change management framework can be embedded within a Training strategy if the upgrade is not impacting any of the core business processes

Points for Consideration

Any SRM technical upgrade will bring with it additional features and pre-requisites to be incorporated in order to leverage the benefit that comes with any improvement in versions. Some are mandated by the technological improvement and some with the vendors product strategy  in this case SAP.

The following points are to be considered and integrated with the project plan which will require additional resource and expertise as well as participation from Business/Process owners

Technology Consideration

• Migration from application controlled workflow to process controlled workflow

This is a technical component to implement and maintain workflow where the move in the new version is more towards functional maintenance rather than technical one.

Product Strategy

• Implementation of SRM-MDM as the catalogue management tool

As all future releases of the new version will only be aligned with SRM-MDM for all its catalogue management, it becomes mandatory sooner or later to adopt this tool. Having said that SRM 7.0 can still be integrated with the current catalogue management tool like Requisite as long as it is OCI compliant.

Conclusion

The success or failure of any upgrade project depends on how thoroughly the upgraded system has been unit, integration, regression and user tested and how effective has been the communication and training strategy adopted and implemented. The more effort goes into the testing and training of the system the less are the chances of the project getting into red. It should also be noted that the involvement from the top management in driving this at all levels also matter in the success of the project. The upgrade project also should derive potential improvements in terms of the procurement cost of indirect material from business perspective and/or the reduction in the TCO from the technical perspective of the on-going cost.

Glossary

BBP     -           Buyer Business Procurement

EBP     -           Enterprise Buyer Professional

SRM     -           Supplier Relationship Management

ITS       -           Internet Transaction Server

BAU     -           Business As Usual

MDM    -           Master Data Management

OoM     -           Order of Magnitude

OCI      -           Open Catalogue Interface

TCO     -           Total Cost of Ownership

The GRN or SES is created on the Portal in SRM under the receiving role. Once created it routes into the ECC backend and creates the relevant document. Depending on configuration the Document numbers between the ECC SES/GRN and SRM 7 could be different. Sometimes the GRN/SES is referred to as a ‘Confirmation’

The quickest way to check is on the portal go to Receiving, then fill in the PO number and it will show you the GRN/SES for that PO as well as you created it. See below:

1. Go to the receiving role and fill in ECC PO number

2. After clicking apply you will see all the Confirmations (SES/GRN’s) for this PO

3. To confirm we are looking at the correct confirmation we open the document and look at the tracking tab to see the reference documents

Addresses would normally be replicated from ECC into your SRM 7 back-end. We have found that at some points on SRM we like adding additional information in specific fields that is not required on ECC or delete certain addresses that should not be used in SRM. So how does one go about doing this. We found doing it through the Portal is the easiest. It will require you to have access to the SRM Administrator role. The below print screens outline the steps to edit or delete an address.

1. Navigate to SRM Administration on the Portal, then under Work Overview on the left you will find "SRM Administration". Then click on External Business Partner - Purchasing companies. Select the Purchasing company where the address is found and select Display.

2. Then click 'Edit' and once in edit mode select the Address Data tab.  (It could take a while because it finds all the addresses in that Purchasing Company)

3. Using filter find the address you wish to edit, and then highlight the address and click 'Details' (If you wish to delete the address  then you click 'delete')

4. All the address details will be shown below, you can now edit or change the address details as needed and then click 'Save'

Roles

For information on roles in SAP SRM 7.0, refer to the following:

http://help.sap.com/saphelp_srm70/helpdata/en/74/344c430fab4d0bbc30996d56cc293a/frameset.htm --> Business Packages --> Business Packages for SAP SRM 7.0

Here you will find the relevant roles in Sap sRM 7.0, based on different requirements like Harmonized Procurement for SAP ERP & SAP SRM, SAP SRM Procurement for Public Sector or SAP SRM on One Client in SAP ERP

SAP Note 1261825. Here, you will find a comparison of PFCG and portal roles in SAP SRM 6.0 and SAP SRM 7.0

The new User Interface and Portal environment --- makes it easier for employees to personalize the User Interface content; for example, by using WebDynpro’s inbuilt personalization functions and Personalized Object Work List (POWL). For your IT department, it is easier to control the usage

of applications based on roles in the SAP Enterprise Portal.

Portal Business Content --- Completely new Portal Business Content has been introduced in SAP SRM 7.0, offering full role-based access for employees. The new Business Content integrates SAP ERP user interfaces and

SAP SRM user interfaces in a seamless fashion.

Single Sign-On

In general, the authentication for single sign-on (SSO) is set with a Logon Ticket that is generated at the

first logon to a specific Enterprise Portal, and which must be uploaded into each target system that needs

to communicate with the portal.

You do this in transaction STRUSTSSO2:

1. Add to Ticket List (known within the complete system)
2. Add to ACL (valid for the client)

In transaction RZ10, you must ensure that the following two parameters are set correctly:

• Login/accept_sso_ticket: 1
• Login/create_sso_ticket: 2

A general recommendation, in order to avoid problems with single sign-on, is to always use fully qualified

domain names. An example:

1. https://portal/irj/portal
2. https://portal.wdf.sap.corp/irj/portal

Even though URL 1 can be resolved correctly on the IP level, it can cause problems with SSO, as the

browser does not know that the cookie stored as the logon ticket for URL 2 can also be used for URL 1.

The only reason that URL 1 can be resolved at all is that the name portal is already unique for this portal.

For further information about Single Sign-On refer to:

• http://help.sap.com/saphelp_nw70/helpdata/en/42/ea2fd5b2201bdae10000000a11466f/frameset.htm (Technology Consultant's Guide --> Authentication and Single Sign-On)
• SAP Note 1257108

User Management

We recommend using single sign-on (SSO) for User Management. Therefore, the usernames in both

SAP SRM and the Portal must be the same. In order to determine which actions are necessary, the

following decision tree can be a help:

Note: SAP recommends use of ABAP only if the portal is used for SAP SRM exclusively. If the portal is not used for SAP SRM exclusively, we recommend using LDAP.

Roles for SAP SRM

The following sections describe the PFCG roles available for SAP Supplier Relationship Management 7.0 (SAP SRM 7.0).

Questionnaire -----

1. What will be the ECC, NW-Portal and MDM version at the time of the SRM upgrade?
2. Components in SRM Landscape

Please list which of the following Components are currently implemented (Y/N) and their release versions :

a) EBP

b) SUS

c) Live Auction

d) Requisite Catalog

e) CCM

f) MDM Catalog

f) IPC

b) XI / PI

h) Enterprise Portal

i) BW (SRM Analytics)

j) ITS

k) CRM Middleware

l) HR Integration

m) Supplier self-registration

n) Others

Are you considering implementing additional SRM components?  If so, please list the components.

3. SRM Scenarios currently implemented and To-be-Implemented ( or upgrade )

1) Self Service Procurement

2) Service Procurement

3) Plan Driven Procurement

4) Contract Management

5) Supplier Self Services

6) Strategic Sourcing - RFx, Live Auction

4. Shopping cart --- Will the internal and external catalogue be same as present ?
5. The number of product catalogue and Product Data --- Will it be the same ?
6. Any new Custom Developments, BADI / User Exits , Screen modifications ?
7. What is the actual scope of the SRM 7.01 upgrade project, like Technical UG, Functional UG, User training, Preparation of the documents like As –Is, user manuals, UAT, Technical specifications, Functional specification, etc ?

We were requested to verify variance on RFx's. The Basic concept is to check that prices supplied by suppliers does not jump massively between RFx's and PO's.

So the requirements:

-> Validate at the point of the accept button being pushed on an RFx Response if the price is X% more than the average for the previous 3 months prices of PO's.

-> If it is more than X% then throw an error so that the RFx response cannot be accepted.

-> The user accepting the response must then type in the reason for the increase in price (such as fuel increase, weak currency ect) into the header text field.

-> The error must then change into a warning so that the RFx response can be accepted yet still show there was an error.

Our consideration:

-> We firstly thought of using an RFC call to find the last 3 months average price in real time. The issue with this is that you are reading ECC tables such as EKKO for ECC PO's

-> We do not want to slow down the process by having slow RFC validations done multiple times a day

-> We needed to consider the currency to compare, you cannot compare USD and EUR directly there needs to be a conversion

-> What proof is there that the custom validation is working in terms of ROI to business

-> We considered reading the last 3 months RFx prices in SRM for the material but realised that if a contract just expired there would not be any RF'x in the last three months so we needed the PO price.

-> The validated time period and the X% would need to be changeable to ensure we can tweak the process as needed to ensure the right validations and not pick up general inflation.

Our decisions

So what did we decide. Firstly we did not make use of an RFC instead we made use of a report in ECC. We wrote a quick report to pull out all the materials we require validations to be done on. This report then generates a 'csv' file output onto an SFTP. We then wrote an upload program in SRM to retrieve the information out of the file and store it in a custom table in SRM. Now when someone clicks accept it is a quick validation into this custom table in SRM to check the average price for the last three months. At this point when the validation is done it also does the necessary conversions so that EUR is compared to EUR and so on.Then to ensure there was some way to ensure ROI we logged all errors produced due to fluctuating prices and then also logged all reasons provided so that business could have a report on these. We also did a quick easy maintainable table to activate and deactivate the validation as well as the x% to validate Below is a very short and simple overview of how it was implemented:

Advantages of this design:

1. Any material not in the custom table in SRM would not be validated so the report in ECC could be filtered to ensure only those materials we want validation to be done for could be.

2. No Slow RFC calls in real time

3. Easy changing x% and activation and deactivation

4. Provides easy access to reports

5. Can be scheduled so no manual report running, and EKKO table reads could be done outside work hours

6. The time period for averaging can easily be be changed by changing the variant in the ECC report with no impact on the SRM side.

Disadvantages of this design:

1. The design requires an SFTP server to be available

2. Only daily averages not real time averages

3. A large amount of customization

4. Use of only the header text for reasons, so it is not per line item and if the header text field is used for anything else it would by-pass the validation

5. Manager responsible for seeing the warning and checking an acceptable reason has been provided.

This really was a nice implementation there are some flaws and places the design could be improved such as maybe using an RFC but not real time on a scheduled basis. So schedule an RFC in SRM to fetch the lastest averages directly from ECC every hour lets say. This would also remove the SFTP server portion.  Also validating per line item and requiring a reason per line item could be advantageous but in our implementation business did not require per line because the reasons would typically affect all line items. Another nice improvement would be to have a dropdown with common reasons not just free text . Have around 5 common reasons and then have an other with free text. This way much better reports could be generated. This validation protects the company from both finger trouble when prices are entered as well as from suppliers over charging.

I hope this helps someone else and that you feel it is a worthwhile effort.

POWL architecture in SAP is bit complex, but once you understood the concept how to configure and modify it , it is pretty cool and easy.With the help of this document you would be able to identify the POWL feeder class and other details and control the action for POWL.

1. Login to screen and Rigt click on the POWL query and select technical details.

2. Scroll down the technical details and go to URL start parameter section and get the application id (applid)

3. Now go to the transaction POWL_QUERYR and get query id from the application id . If there are multiple queries check the description and the sequence number. In screen it will appear in the order.Look for query sequence no to get the order of queries

4 Get the Query ID and go to the transaction POWL_QUERY. From this you will ger POWL type ID.

5. Now go to the transaction POWL_TYPE. Here you can see the Feeder class  which will supply the details to this POWL. You can copy to Z* and modify for customer specific requirement and modify customization accordingly.

6. To get the actions configured for the POWL and get the field catalog details go to the transaction /SAPSRM/POWL_CUST and give the POWL type id.

to enable or disable actions for the POWL double click on "Actions"

7. To refresh the POWL we  modified on the screen do run the report POWL_D01 for the specific user or group of users.

I hope with this you will be able handle POWL requirements in much better way.

Sometimes you may find indicator source_rel_ind is not set 'X' correctly in SC after ECC PR is transferred.

In order to judge the root cause, I will introduce the coding desing for this process and possible reason for the failure.

Usually source_rel_ind should be set as 'X' if it is configured as below in customizing path:

t-code SPRO..->

     SAP Supplier Relationship Management

         SRM Server

           Sourcing

             Define Sourcing for Product Categories

Category ID           SourceSyst             Sourcing

     *                                                       Sourcing Always Carried Out

Please note if you set 'Category ID' as '*', source system should be blank since no unique assignment is possible.

However some users refused to keep this as blank, instead they set it as one backend system. This will not update source_rel_ind correctly in some special case.(I will explain this later)

First let us find how this indicator is set during PR transfer:

The key function module is BBP_PDC_SRC_DETERMINE in SRM side. If you want to debug the transfer process, you may set external breakpoint at this function module for RFC user.

In this function module, it will check if the category_id and logsys_source in ls_src_det_key is matching with the entry in the customizing:

==========

.......

DO.

                  lv_count = lv_count - 1.

                  IF lv_count LT 0.

                    EXIT.

                  ENDIF.

                  lv_catmask+lv_count(1) = '*'.

                  ls_src_det_key-category_id = lv_catmask.

                  ls_src_det_key-logsys_source = lv_logsys_source.

*                     Try reading the table with the masked category ID

*                     and the logical source system

                  READ TABLE st_src_det

                       INTO ls_src_det

                       WITH KEY ls_src_det_key

                       BINARY SEARCH.

                  IF sy-subrc EQ 0.

                    MOVE ls_src_det-sourcing TO lv_bbp_src_det_type.

                    EXIT.

*     jz/ ----------------------------------------------------------------------------

                  ELSE.

*                       Try reading the table only with the masked category ID

                    CLEAR ls_src_det_key-logsys_source.

                    READ TABLE st_src_det

                         INTO ls_src_det

                         WITH KEY ls_src_det_key

                         BINARY SEARCH.

                    IF sy-subrc EQ 0.

*                       Yes, take the logsys and exit the DO...WHILE loop.

                      MOVE ls_src_det-sourcing TO lv_bbp_src_det_type.

                      EXIT.

*     jz/ ----------------------------------------------------------------------------

                    ENDIF.

                  ENDIF.

============

So if the entries are not matching, source_rel_ind will not be set correctly.

Here you might confuse how the category id and source system in ls_src_det_key is determined. This is another story which I will tell next step.

How to determine the category guid during PR transfer:

Category id is 'Material group' that is assigned to ECC PR. After category id is transferred to SRM, it will try to find the corresponding category guid which is another identification in SRM side.

At first, it will get category guid from table comm_category in the following coding (Program LBBP_BD_VALUE_MAPPINGF0N ):

====

* ProductCategory

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

MOVE-CORRESPONDING is_item TO ls_category_in.

  IF NOT ls_category_in IS INITIAL.

    CALL FUNCTION 'BBP_CATEGORY_TO_SAP_MAPV'

      EXPORTING

        is_category_in   = ls_category_in

      IMPORTING

        ev_category_id   = lv_category_id

        ev_category_guid = lv_category_guid.

====

Then it will get the category guid again if product id is also set in ECC PR (Program LBBP_BD_VALUE_MAPPINGF0N ):

====

* Product

***********

  lv_ordered_prod = es_item-ordered_prod(40).



  IF cs_header-object_type EQ c_suspo AND es_item-product_src_sys IS INITIAL

    AND is_item-catalogid IS INITIAL AND cs_header-src_logsys IS NOT INITIAL.

    es_item-product_src_sys = cs_header-src_logsys.

  ENDIF.



  CALL FUNCTION 'BBP_PRODUCT_REF_FROM_EXT_MAPV'

    EXPORTING

      iv_product_type    = is_item-product_type

      iv_product_gtin    = is_item-product_gtin

      iv_partner_prod    = is_item-partner_prod

      iv_partner_guid    = iv_vendor_guid

      iv_catalog_id      = is_item-catalogid

      iv_unit            = es_item-unit

    CHANGING

      cv_product_no      = lv_ordered_prod

      cv_product_src_sys = es_item-product_src_sys

      cv_product_guid    = es_item-product

      cv_category_id     = es_item-category_id

      cv_category_guid   = es_item-category.

====

If you go inside this FM BBP_PRODUCT_REF_FROM_EXT_MAPV, you will find the category guid is determined in deeper level at Form READ_WITH_PRODUCT_CURRENT:

====

SELECT * FROM (gc_set_table)

               INTO CORRESPONDING FIELDS OF TABLE et_set   "note 437424

               WHERE product_guid = iv_product_guid.

====

Here (gc_set_table) is table COMM_PRPRDCATR, and category guid will be determined by the product via this table.

From my understanding, if you only set material group in ECC PR, then the first place will determine the category guid. If you set both product and material group in PR, then the latter one will take first priority.

In conclusion, in order to make indicator source_rel_ind update correctly, you should check the customizing place first.

If the indicator failed to be set only for specific product or category, you should check both tables comm_category and comm_prprdcatr to see if the data is consistent.

Hope this will help you find the root cause for source_rel_ind update during PR transfer.

1.    Purpose of this document

This option paper provides an approach or guidelines when deciding if either remaining with the current catalogue management tool (Keeping the name anonymous for ensuring no harm for the products reputation) or implementing  SAP’s SRM MDM for catalogue management during the upgrade of the SRM system to version 7.0  . The implementation of SRM MDM is not a mandatory requirement for upgrade but recommended as per SAP as the non-SAP is/may not supported by SAP anymore or in the future releases. The document provides the analysis and options considered , the recommendations made based on the options and the rationale justifying it.

2.    Context

The analysis for each of the options are detailed below, this is a tabular form highlighting the pros and cons along with any associated risk with each of them. These are in turn derived based on the architectural impact, ease of delivery and business process perspective. The recommendations and the final decision should be validated based on each of the above aspect keeping the impact on the overall upgrade project in terms of complexity, risk on the project timelines and the additional cost implications.

The factors considered for the options evaluation is not an exhaustive list and may vary to the extent of its significance based on the organization evaluating the options. However majority of the factors will still hold good for evaluating any options detailed below.

3.    Analysis and Options

3.1. Option 1 - Remain with the existing Catalogue Management Tool

The first option is to remain with the existing catalogue management tool integrated with the upgraded SRM 7.0 application and not considering the implementation of the SRM-MDM.

3.2. Option 2 - Implement SRM MDM

The second option is to go for a fresh implementation with SRM-MDM catalogues parallel to the upgrade project to leverage enhanced functionality of the combined system.

4.    Decision Matrix

The matrix below provides the information on what factors are impacted and which are not. However the weightage with each of them may vary based on the organizational relevance and priority associated with them. The impact factor is/may not be limited to the ones mentioned below,

5.    Recommendation Consideration

The recommendation should be made on the criteria that any option considered should also take into account the below

• Impact on the time and resources to the current project should be minimal 
• Ensure that this decision should not be in the critical path of the project, else will have to consider additional risk on the other timelines
• Should be aligned to the IT strategy defined by the organization
• Aligned with the SAP’s roadmap to ensure future scalability of the system to leverage the new functionalities and capabilities within SRM

6.    Conclusion

With the above recommendation points one can go for either staying with the existing Catalogue Management Tool or deploy a new SRM-MDM during the upgrade. It should be kept in mind that for any SAP suite it is always good to go with the relevant applications within the suite so as to ensure total seamless integration between them. This also helps in leveraging the additional capability and features which keeps getting enhanced with each of SAP’s suite.

However there may be many other constraints which need to be considered and influence the final decision an organization may take. However the final future end state should be an alignment with the SAP’s suite.

Very often our customers ask to add a custom field in SOCO, here you'll find a step by step guide to do it

Step 1 -  Add Custom field to Shopping Cart by following the standard add metadata procedure.

Go to SPRO->SRM Server->Cros-Application Basic Settings-> Extension and Field Control (Personalization)

Create the customer fields at item level for Shopping Cart

Add the field both for Database and Shopping Cart

Configure field control in order to enable the fields.

Step 2 - Add custom fields to search structure

Add custom fields to structure /SAPSRM/S_SEARCH_FIELDS_PR include /SAPSRM/INCL_EEW_CSS_SEARCH_FD.

Step 3 - Enhance SOCO Webdynpro to add Custom Fields.

Add the custom fields to webdynpro with the following technical details

Webdynpro: /SAPSRM/WDC_DO_SOCO_GAF_1

View: V_AO_SOCO_GAF_1

Context Element : SEARCH -> SEARCH_FIELDS

Layout

ROUTUIELEMENTCONTAINER-> SEARCH_FIELD_CONTAINER -> MAIN_CONTAINER

If necesary implement a post exit in method WDDOMODIFYVIEW in order to control fields behavior and attributes.

Hope this help !

Purpose:

            User wants to add custom fields to the carry out sourcing( sourcing cockpit ) search screen and also in result table.

Procedure:

    Step 1:  We need to configure that custom field through SPRO. 

    Step 2: Then we need to add our custom field in search structure and result structure of SOCO( sourcing cockpit ).

                  Component : /SAPSRM/WDC_DO_SOCO_GAF_1

                  Context node -> Search -> Search_fields  -> /SAPSRM/S_SEARCH_FIELDS_PR

                  Context node -> Search -> Result_fields  -> /SAPSRM/S_CLL_WD_SOCO_WORKAREA

    Step3 : Need to change the layout according to the requirement.

   Search screen:

     Output result screen:

     Step 4: Write the code needed to restrict the output based on the input given by the user for the applicaiton type.

     Sample code:     

**** Restricted the ouput entries y apllication type:              

     CALL METHOD ls_element->get_attribute

     EXPORTING

          name = 'YYAPP_TYPE'

     IMPORTING

          value = lo_app_type.

     IF NOT lo_app_type IS INITIAL.

     LOOP AT mt_displayed_list ASSIGNING <fs> WHERE yapp_type NE lo_app_type.

     DELETE mt_displayed_list WHERE guid = <fs>-guid.

     ENDLOOP.

     ENDIF.

**** Code displeaed fro Error message :

     DESCRIBE TABLE mt_displayed_list LINES lv_elem.

     IF lv_elem = 0.

    MOVE '037' TO ls_messages-msgno.

    MOVE '/SAPSRM/AO_SOCO' TO ls_messages-msgid.

    MOVE 'W' TO ls_messages-msgty.

    CALL METHOD mo_cll_message_handler->add_message

      EXPORTING

        is_message = ls_messages.

    ENDIF.

Appreciate your queries and comments!

Thanks,

Eswari.