Introduction

What is mySAP SRM

mySAP SRM Integration Technology

mySAP SRM Business Processes

mySAP SRM System Landscape

I.     Introduction

     mySAP SRM is SAP’s solution for Supplier Relationship Management. mySAP SRM covers a wide range of functionality:-

•      From simple self-service procurement of MRO* goods
•      To strategic sourcing and supplier enablement
•      Plus complementary services like content management

     mySAP SRM is build upon a set of business application components and leverages SAP NetWeaver as integration and application platform.

mySAP SRM at a Glance

• One solution covering a wide range of customer requirements related to procurement, strategic purchasing, and supplier relationship management
• Flexible deployment options
• Optimal scaling along multiple directions
  •      Functionality (simple e-procurement to strategic sourcing)
  •      Volume (small to large number of suppliers, products, ..)
  •      Product categories (MRO, services, direct goods)
• Leverage of existing SAP services through tight integration
• with existing SAP backend systems
• Openness towards non-SAP systems based on open Internet standards
• Flexible supplier enablement

Figure: Standard Procurement Process

Figure:Plan Driven Procurement

Figure: Sourcing Process

Figure:Supplier Enablement process

Figure: Content Management

Figure: my SAP SRM Architecture

Figure: mySAP XI

my SAP Exchange Infrastructure

SAP XI is used for:-

• Integration with supplier systems
• Integration of SRM application components
• Partly for backend system integration

Open Catalog Interface (OCI):

• OCI is used for catalog integration from SAP EBP
  • Via OCI a user can select products from a catalog and transfer the entire shopping cart back to SAP EBP
• Via OCI SAP EBP can also be integrated with
  • a hosted catalog on a marketplace
  • a supplier catalog running at supplier side
• OCI is an HTTP based interface and works cross firewalls

Open Partner Interface (OPI):-

• OPI is used for searching new suppliers and uploading of new suppliers in SAP EBP
  • Via OPI a user can search for new business partners in an external supplier directory and transfer new entries to SAP EBP
• OPI is an HTTP based interface and works cross firewalls
• OPI will be part of Interface Software Certification at SAP
  • First certified partner product “Hoppenstedt Firmeninfo”

RFC (Remote Function call):-

RFC is used:

• for synchronous communication between SAP EBP and SAP R/3 backend systems
• direct integration of SAP BW with the mySAP SRM application components SAP EBP and SAP SUS

Process Scenarios:

• Standalone
  • Only in EBP
• Classic
  • EBP and Backend R/3 or non-R/3
• Extended Classic
  • EBP and Backend R/3 or non-R/3
• Dual Coupling

For the fast ROI Return on Investment, deploy mySAP SRM.

From RBEI

Snehal

Overview of Two Bid  Envelope Process:

Purpose: Two-envelope RFx responses are used to collect and evaluate technical RFx response information separately from price RFx response information. This allows the purchasing organization to evaluate RFx responses based on factors such as technical capabilities before viewing the price information. RFx respondents submit a technical RFx response and a price RFx response. You can influence the way in which technical RFx responses are stored, accessed, opened, and evaluated.

Overview of Multi- Party Verification Process:

  Purpose: We can use this process to allow multiple users to approve the RFx response opening process by simultaneously logging on to the system within a given time period. This allows you to introduce multi-party verification into the RFx response opening process. By default, simultaneous logon is only available for RFxs with two-envelope RFx responses.

       Before starting the simultaneous logon process, the purchaser must assign participants the necessary permissions for their role in the process.The purchaser then initiates the simultaneous logon process. After initiation, the approvers, in this case, the RFx response openers, must approve the opening process by logging on to the Simultaneous Logon Application. Only after all RFx response openers have verified the process by logging on, is it possible to view and evaluate the RFx responses

Process:

1. Purchaser selects Two envelope RFx Transaction type.

2. System automatically creates a collaboration room in SAP cFolder for RFx and folders with the name:a) Collaboration, b)External Area, c)Internal Area is created within this Collaboration room.

3. Purchaser uploads the Collaborative document in Collaboration folder and Technical RFx in External Area .

4. Purchaser fills the remaining RFx and define permissions for Technical Opener, Price Opener, Technical Evaluator. By default, Bid-Floor admin right is with the owner of the RFx.

5. Purchaser Publish the RFx.

6. Supplier view the RFx and access the cfolder( Technical RFx) through Technical Bid Button. Supplier Collaborate with the Buyer through Collaboration folder, download the Technical RFx from External Area.

7.Supplier show his intention to participate in RFx by clicking over Participate button and clicks over Create response which result in automatic creation of Tech_Bid folder with Supplier name  in C folder.

8. Supplier uploads his technical response and submit his price bid.

9. Bid Floor admin initiates the Technical Bid Response opening process. All Technical opener gets email notification to open Technical RFx Response by Simultaneous logon.

10. Once Technical RFx Response opening process is done,Technical Evaluators receive email containing  URL to evaluate the Technical RFx Response.

11. Evaluation folder with Evaluator name automatically gets created in Cfolder, where Evaluator uploads his evaluation document and Comments.

12. Depending upon the Evaluation Comments the Purchaser accept/reject Technical Responses.

13. Bid Floor Admin initiates the Price Response opening process for Suppliers whose technical Response have been accepted.

14. Price opener receives notification and price opening process is done by simultaneous logon process.

Settings Need to be done in SPRO:

Prerequistes: SRM_SOURCING_1 must be activated.

Basic Setting:

Activate the two-envelope RFx response function in Customizing for SAP Supplier Relationship Management under:  SRM SRM Server>>RFx>>Extended RFx Process>>Two-Envelope RFx Response>> Activate/Deactivate Two-Envelope RFx Response

Click Over Activate/Deactivate Two-Envelope RFx Response:

  Steps to Configure Simultaneous Logon:

1. Activate simultaneous logon in Customizing for SAP Supplier Relationship Management under: SRM Server>>RFx>>Extended RFx Process>>Simultaneous Logon>>Activate/Deactivate Simultaneous Logon at RFx Response Opening

The system sends an e-mail to participants notifying them that the simultaneous logon session was completed successfully.

2. We must configure the duration of the process and specified when you require an e-mail notification to be sent to participants in Customizing for SAP Supplier Relationship Management under  SRM Server >> RFx >> Extended RFx Process  >>Simultaneous Logon  >>Define Basic Data for Simultaneous Logon.

Success:

Failure: The system sends an e-mail to participants notifying them that the  simultaneous logon session has failed and must be repeated.
Initiation: The system sends an e-mail to participants notifying them that the s    simultaneous logon session has been initiated by the purchaser and that they must go to the simultaneous logon application and approve the process.

 

Steps to Activate Two Bid Envelope Process:

Activate the simultaneous logon function for the required transaction and publication type in Customizing for SAP Supplier Relationship Management under
SRM Server >>RFx >>Extended RFx Process >>Tendering Options >>Define Tendering Options

Define Transaction Type and Select the Option Two Envelope and Sim Logon:

Define Basic data for Two envelope RFx Response:

Check TbidE-Mail - To send an Email notification to the Bidders informing them about whether there Bids has been accepted or Rejected by the evaluation panel.
Check Reject Pr.- To Specify that the price RFx Response should be automatically rejected when technical RFx Response is rejected.

Define basic Settings for Technical RFx Response Folders:

Create Entries as below if not created already:

Reference: http://help.sap.com

Overview of RFx:

An RFX can be thought of as a general mechanism that allows buyers and sellers to conduct business. often the exchange of specific items or services for a specific price, but also the exchange of information, such as capabilities or willingness.

RFx is a general term used to represent different types of RFx:

1. Request for Information:

Generally used to elicit information from market on a requirement.

2. Request for Proposal:

Used for complex requirement and project where buyer outlines the requirement in an RFP and Supplier submit the Detail response for the same.

3. Request for Quotation:

Used for Standard items and services where both buyer and supplier are clear about the specifications of the product.

Implementing RFx Functionality:

Assumption: All Basic Settings of SAP SRM has already been done.

1. Number Range: Mainatain the number ranges using the menu path SPRO>>SAP Implementation Guide>>Supplier Relationship Management>>SRM Server>>Cross Application Basic Settings >>Number Ranges>>SRM Server Number Ranges>>Define Number Ranges for Local RFxs.

2. Define Transaction Type: Maintain Transaction types using menu path SPRO>>SAP Implementation Guide>>Supplier Performance Management>>SRM Server>>Cross Application Basic Settings>>Define Transaction Types.

3. Define Transaction type for RFx in organizational Plan: Using Transaction PPOMA_BBP, define the Transaction type for RFxs in the Organizational plan and assign the attributes TEND_TYPE to the responsible user.

4. Define Output settings:

In order to emable the user to Print RFx, send them by email, and Fax them to bidders:

>> Maintain Printer settings for the users in your system.
>> Mainatin email-address and fax number of your bidders in the web interface of SAP Supplier Relationship management.
>> Define processing types and forms that are used to output documents.

Make Printer Settings:

a) Run Tcode : PPOMA_BBP
b) Select the users you require.
c) Add value a PRI for Attribute "default Printer".

Make Email address and fax numbers of bidders:

a) on the Web interface of SAP SRM, Choose Manage Business partner.

b) Search for the bidders and enter their Fax number and Email-address.

Define the processing types and forms that are used to output documents:

Menu Path:

SRM Server>>Cross Application Basic Settings>>Set output Actions and Output Format>>Define Actions for Document output.

5. Define Sourcing for Product Categories: Sourcing rules applicable for each product category is defined in menu path : SPRO>>SAP Implementation Guide>>Supplier Relationship Management>>SRM Server>>Sourcing>>Define Sourcing for Product Categories.

Sourcing Rules available in Settings:

1. Sourcing is never Carried out: if Source of Supplier does not exist in the requirement,then an incomplete Purchase order is created.

2. Sourcing is always carried out: All requirement are transferred to sourcing cockpit.

3. Sourcing is carried out for items without a source of supply:  In absence of Source of supply, the requirement is transferred to the sourcing cockpit.

4. Sourcing Via automatic bid invitation for items without a source of supply: System create a bid invitation for all requirements that do not have a source of supply.

Adjust Roles:

a) Adjust Roles for Internal Employees:

In order to maintain the bidding functions of SAP Bidding Engine, one should maintain the roles responsible for RFx and RFX responses.

Roles:
/SAPSRM/OP_Purchaser -- Operational purchaser
/SAPSRM/ST_Purchaser -- Strategic Purchaser

b.) Adjust roles for External Business Partner:

we can create companies and bidder contacts and assign them the role /SAPSRM/SUPPLIER. if we want to allow those external users to participate in strategic Sourcing events such as RFx and Auction we must assign them the role: /SAPSRM/BIDDER.

Some Important Application Controlled workflow:

WS79000002: One-Step approval for bid.
WS14500026: Without approval for publication of RFx and its change version.
WS14500027: One-Step approval for publication of RFx and its change version.

Overview: Supplier preselection workcenter enable the Purchaser to display, edit, accept or reject Potential Suppliers. Purchaser can also add attachments to the potential supplier data.Using POWL we can also transfer Potential Supplier to the backend System to create a business partner with Supplier role in these systems. The workcenter is a new feature which is available from SAP SRM 7.0 EHP 1 onwards.

Prerequisite For Using Supplier Preselection Workcenter:

1. Business Function : SRM_SUCO_1 Must be activated.

2. Activate the Customizing Switch SRM_701_SUCO_SUP_REG in the path:

SPRO>>IMG>>SAP Supplier Relatioship Management>>Supplier Collaboration>>Supplier Self Registration>>Activate Supplier Self Registration .

Impact on ROS process:

1. Once the revertible Customizing Switch SRM_701_SUCO_SUP_REG is activated, BSP Application ROS_SELF_REG cannot be used anymore for registration. The New Webdynpro based Registration Application WDA_E_SUCO_SREG must be used.

2. Supplier Will fills the New Registration Form and Click send.

Glimpse of New Registration Page:

4. Supplier receive Separate questionnaire URL in Single Email for all Product category for which he has opted at time of Filling registration form.

5. Strategic Purchaser accessing new Registration Request of Supplier.

   Strategic Purchaser must be provided with /SAPSRM/SUCO_PROCESSOR role.

Strategic Purchaser goes to Supplier preselection workcenter.

6. Strategic Purchaser can Transfer suppliers and even add Attachments to the Potential Supplier profile.

Note: Transfer Settings needs to be define for Transferring Supplier from Supplier Self Services.

In Transfer Settings We can define the back-end systems to which supplier data can be transferred from supplier self-services (SUS). We can also define whether XML, e-mail, or both should be used to transfer the supplier data.

Summary

In ECC during purchase order creation, it is possible to have different order unit and price unit with conversions maintained (directly while PO creation or in material master). For ex: PO with quantity 5 EA and net price of 10 EUR/1 KG.

The standard SRM SUS (Supplier Self Service) can handle only two cases below:

• Order unit same as price unit
• Order unit and price unit are of the same dimension (for ex: order unit = CM and price unit = M and where the conversions are available in transaction CUNI)

The above example of a PO where order unit and price unit belong to different dimensions are not handled in standard SUS solution. The enhancement described in this document enables this functionality in SUS. The enhancement basically converts all the quantity into one unit before sending it to SUS and when the order response/ASN is being created, it will be converted back to order unit.

Applies to:

SAP SRM 7.0 and above

Overview of the enhancement:

Customer fields at SUS PO

Three new customer fields are added to SUS PO – the following three fields are added into the include structures INCL_EEW_PD_ITEM_CSF_SUSPO and INCL_EEW_PD_ITEM_CSF. This is same as mentioned in the SAP Note 672960.

The following values are transferred from ECC to SRM/SUS for these 3 CUF fields:

• ZZCON_BASE  will hold EKPO-BPUMN (Denominator for Conv. of Order Price Unit into Order Unit)
• ZZCON_PRICE  will hold EKPO-BPUMZ (Numerator for Conversion of Order Price Unit into Order Unit)
• ZZBASEUOM  will hold EKPO-MEINS which is the order unit of PO item

Proxy Enhancements in PI

The following proxies are used for PO transmission from ECC to SRM/SUS:

• PurchaseOrderERPRequest_Out_V1 of namespace http://sap.com/xi/APPL/Global2 in ECC
• PurchaseOrderERPRequest_In_V1 of namespace http://sap.com/xi/SRM/SE/Global in SRM

The proxy enhancement is carried out like the normal PI data type enhancements and the steps are as mentioned below:

• Create a customer SWCV and a customer namespace
• Add standard SWCV SAP APPL 6.06 and SRM SERVER 7.01 as underlying SWCV for the customer SWCV
• Create a data type enhancement for ECC:
  • Standard data type PurOrdERPReq_V1Itm of namespace http://sap.com/xi/APPL/Global2
  • Add the 3 CUF fields ZZCON_BASE, ZZCON_PRICE and ZZBASE_UOM

• Create data type enhancement for SRM:
  • Standard data type PurOrdERPReq_V1Itm of namespace http://sap.com/xi/SRM/SE/Global
  • Add the 3 CUF fields ZZCON_BASE, ZZCON_PRICE and ZZBASE_UOM

• Generate the data type enhancement in ECC and SRM in transaction SPROXY
• Check the standard proxy structure and verify that the proxy enhancement fields are available ECC proxy enhancement:

• Check the standard proxy structure and verify that the proxy enhancement fields are available SRM proxy enhancement:

Implementation of BADI PUR_SE_POERPREQOUT_ASYN in ECC

The above BADI method IF_PUR_SE_POERPREQOUT_ASYN~OUTBOUND_PROCESSING is implemented in ECC where the values for these 3 CUF fields are filled when the order unit and price units differ. And the quantities are modified based on the conversion factors maintained from order unit to price unit.

For ex: consider a PO item with quantity = 10 EA, net price = 100 EUR/2 KG, 2 EA = 3 KG. The values sent to SUS are as below:

The values for the CUF fields will be:

Implementation of BADI /SAPSRM/BD_SOA_MAPPING in SRM

This BADI is implemented in SRM and the method that needs to be implemented is /SAPSRM/IF_BADI_SOA_MAPPING~MAP_XI_TO_BACKEND. In this BADI which is the mapping from the incoming XML to PD structures, the customer field values will be mapped:

Implementation of BADI BBP_SAPXML1_OUT_BADI in SRM

In this BADI implementation, the values are converted back to order unit based on the values specified by vendor while creating order response and ASN creation.

Method PURCHASEORDER_SUS:

The schedule lines and confirmed schedule lines in the PO response sent from SUS to ECC is modified to convert values back to order unit:

LOOP AT cs_purchase_order_message-purchase_order-item INTO cs_xml_item.
LOOP AT it_item INTO cs_item.
*       Only proceed if PO contained different UoMs
CHECK NOT cs_item-zzbaseuom IS INITIAL.

IF cs_item-number_ext EQ cs_xml_item-id-value.
*         Convert Schedule Line (original PO values)
ct_sched = cs_xml_item-schedule_line.

LOOP AT ct_sched INTO cs_xml_schedule.
CALL FUNCTION 'UNIT_OF_MEASURE_SAP_TO_ISO'
EXPORTING
sap_code    = cs_item-zzbaseuom
IMPORTING
iso_code    = cs_xml_schedule-quantity-unit_code
EXCEPTIONS
not_found   = 1
no_iso_code = 2
OTHERS      = 3.
IF cs_item-zzcon_price IS NOT INITIAL.
cs_xml_schedule-quantity-value = cs_xml_schedule-quantity-value * cs_item-zzcon_base / cs_item-zzcon_price.
ELSE.
cs_xml_schedule-quantity-value = cs_xml_schedule-quantity-value * cs_item-zzcon_base.
ENDIF.

MODIFY ct_sched FROM cs_xml_schedule.
ENDLOOP.

cs_xml_item-schedule_line = ct_sched.

*         Convert Confirmed Schedule line (confirmed values)
ct_sched_conf = cs_xml_item-confirmed_schedule_line.

LOOP AT ct_sched_conf INTO cs_sched_conf.
CALL FUNCTION 'UNIT_OF_MEASURE_SAP_TO_ISO'
EXPORTING
sap_code    = cs_item-zzbaseuom
IMPORTING
iso_code    = cs_sched_conf-quantity-unit_code
EXCEPTIONS
not_found   = 1
no_iso_code = 2
OTHERS      = 3.

IF cs_item-zzcon_price IS NOT INITIAL.
cs_sched_conf-quantity-value = cs_sched_conf-quantity-value * cs_item-zzcon_base / cs_item-zzcon_price.
ELSE.
cs_sched_conf-quantity-value = cs_sched_conf-quantity-value * cs_item-zzcon_base.
ENDIF.
MODIFY ct_sched_conf FROM cs_sched_conf.
ENDLOOP.

cs_xml_item-confirmed_schedule_line = ct_sched_conf.
ENDIF.
MODIFY cs_purchase_order_message-purchase_order-item FROM cs_xml_item.
ENDLOOP.

Method ASN_SUS:

This Document provides an overview of the steps which need to be performed for Transferrring Supplier from ROS to MM System. 

Related Document: http://scn.sap.com/docs/DOC-35480

Transferring Supplier from ROS/SUS to ECC

Assumption: Basic Settings has already been done. ( eg: Defining  Logical System, RFC Destination )

SUS Configuration:

Prerequisites:

The ECC System Should be defined in the System Landscape of SUS System.

Define Transfer Settings:

Path:

SPRO>>IMG>>SAP Supplier Relationship Management>>Supplier Collaboration>>Supplier Self Registration>>Settings for supplier Relication and Transfer>>Define Transfer Settings.

Click over New Entries and Add the Backend System to which you want to transfer Supplier from Supplier Self Services.We can also define whether XML ,Email

or both Should be used to transfer Supplier data.

We can also Specify whether product categories should be used to determine which back-end systems supplier data is transferred .

User Management and Role Assignment:

Assign /SAPSRM/SUCO_PROCESSOR to Strategic Purchaser.

Tcode: SU01

MM Configuration:

Assumption: Basic Settings like defining Logical System , RFC Destination has already been performed.

Settings Up IDOC:

Creating Reduced Message Type:

Path:

SPRO>>IMG>>SAP NetWeaver>>Application Server>>IDOC Interface/Application Link Enabling>>Modeling and Implementing Business processes>>Master Data Distribution>>Scope of Data for Distribution>> Message Reduction>>Create Reduced Message Type

Create Message Type: Z_CREMAS_SUSMM

Create Partner Profile of Type LS for SUS System in ECC System:

Tcode: WE20

Click over create Option:

Maintain Inbound Parameter : Z_CREMAS_SUSMM

Maintain Account group in table T077k Which you are using while transferring supplier from SUS.

Details about XI  Configuration:

PI Scenario : Supply_Base_management will be used

Operational Mapping : SUSSupplier2MM

Message Mapping: SUSSupplierPortal2MM will be used.

This Document Provides the overview of the Steps involved in ROS Configuration for SAP SRM 7.0 EHP 2.

Supplier Self Services Configuration:

Prerequisite:

Activate the Business function:

SRM_SUCO_1

Path:

SPRO>>IMG>>SAP Supplier Relationship Management>>SRM Server>>Activate Business Functions.

Activate the Customizing switch:

SRM_701_SUCO_SUP_REG

Path:

SPRO>>IMG>>SAP Supplier Relationship Management>>Supplier Collaboration>>Supplier Self-Registration>>Activate/Deactivate Supplier Self-Registration.

Category and Hierarchy Settings:

Maintain Categories and Hierarchies:

Create Hierarchy “R3MATCLASS”

ReplicateProduct Category under this Hierarchy from ECC

By Selecting New Category Tab

Assign Hierarchy to Application:

Tcode: COMM_PRAPPLCAT

Path:

SPRO>>IMG>>Cross-Application Component>>SAP Product>>Product category>>Assign Category hierarchy to Applications.

Questionnaire Settings:

Create Questionnaire:

Path:

SPRO>>IMG>>SAP Supplier Relationship Management>>Supplier Collaboration>>Supplier Self-Registration>>Questinnaire Settings>>Create/Change Questionnaire.

Assign Questionnaire and Language to product Category:

Path:

SPRO>>IMG>>SAP Supplier Relationship Management>>Supplier Collaboration>>Supplier Self-Registration>>Questionnaire Settings>>Assign Questionnaire and Language to Product Category

Select Product Categories for Registration:

Self – Registration Screen:

Path:

SPRO>>IMG>>SAP Supplier Relationship Management>>Supplier Collaboration>>Supplier Self-Registration>>Supplier Self-Registration Screen

Define Welcome Area Text– The Welcome Text which will appear on the Supplier – Self Registration Page.

Creation and assign an anonymous User ID for Supplier Registration in SUS:

Go to transaction SU01 and create a “Service” user. Do not forget to mention the mail ID. This mail ID will be used to send the questionnaires to newly registered vendors.

Assign Role:

1. ) SAP_EC_BBP_CREATEUSER ,

2. ) SAP_EC_BBP_CREATEVENDOR and

     3. ) /SAPSRM/SUCO_ANON_REG

Activate services and maintain the user in the services in SUS:

1.   ROS_SELF_EDIT 

2. ROS_PRESCREEN

3. WDA_E_SUCO_SREG

4. WDA_E_SUCO_POWL

5. WDA_L_FPM_OIF

Maintain a table entry in the Table “BBP_MARKETP_INFO” in SUS:

Maintain the Vendor root organizational unit and Dummy Purchase organization unit in the table

Maintain the Following table entry in SUS

Go to SE16 Transaction and enter table name as UXB_APPL and make following entry

Make settings for Business Partners in SUS:

Administrator can be used as the Service user created for all the SICF services Maintain the same Document object as maintained below in the screen shot

Path:

SPRO>>IMG>>SAP Supplier Relationship Management>>Supplier Self Services>>Master Data>> Make settings for Business Partners.

Configuration on EBP Server:

Entry in Table “BBP_MARKETP_INFO” in EBP

Make the table entry of the Organizational Units for Vendors created in EBP

Define External Web services in EBP

Assign this Web service to the users in the Organization plan ( T.Code : PPOMA_BBP ) for the attribute CAT ( Catalog )

Related Docs:

http://scn.sap.com/docs/DOC-35480  - Supplier Preselection WorkCenter - Supplier Self Services.

http://scn.sap.com/docs/DOC-39159  - Supplier Preselection Workcenter -Transferring Supplier from ROS to ECC

SAP Supplier Relationship Management (SAP SRM):

SRM in SAP stands for Supplier Relationship Management. It is one of the parts of SAP Business Suite Software. It is based on the SAP NetWeaver platform hence it also known as SAP NetWeaver SRM. It is for strengthening the procurement processes of an organization by automating, accelerating of procure-to-pay processes for goods and services. It introduced many facilities for better co-ordination between the suppliers and business activities. SAP SRM will examine and forecast purchasing behavior, it also shorten the procurement cycles, and work with your partners in real time. So it helps for building long-term relationships with the suppliers. The efficient processes in SAP SRM enable you to cut down your procurement expenses and to work more intensively with more suppliers than ever before.

SAP SRM mainly deals with

• Self-Service Procurement
• Plan-Driven Procurement
• Service Procurement
• Strategic Sourcing
• Operational Contract Management
• Supplier Qualification
• Supplier collaboration
• Catalog Content Management
• Analytics

Three types of multilevel hierarchy structures are used in SAP SRM master data

• Product category hierarchies
• Supplier hierarchies
• Central contract hierarchies

SAP SRM Lifecycle:

The following lifecycle is followed in SRM. This starts with creation of Shopping Cart. Once a shopping cart is created, a corresponding Shopping Cart number is generated. This will be sent for approval. Once the shopping cart is approved, a purchase requisition number will be generated and this will lead to generation of various process purchasing documents. This will also give rise to a Purchase Order along with a unique number. Once the PO is created, the goods are supplied at the ship-to address and goods recieipt will be given. Goods receipt will be verified and an invoice will be created. Once the invoice is created, the buyer will process the payment. Below diagram  (Figure 1) depicts the entire SAP SRM lifecycle structure.

Figure 1: SAP SRM Technical Life cycle

However, based on the system availability and generation of various documents, SRM have four different types of deployment scenarios.

SAP SRM Deployment Scenarios:

SAP SRM enables organizations to efficiently source and procure all categories of products, that is, direct materials, indirect materials, and services, and can be integrated with any backend planning, inventory, and accounting systems. SAP SRM provides four deployment scenarios, including the classic, extended classic, standalone, and decoupled scenario, and companies can decide on the level of integration with backend planning and accounting systems by implementing the appropriate deployment scenario.

It provides an integrated enterprise procurement platform that enables integration of procurement with design, planning, inventory, and financial applications. SAP SRM is seamlessly integrated with the SAP ERP application and can be integrated with other non- SAP backend ERP applications as well. Depending on the system that you want to be the main purchasing application, there are four scenarios of integration with backend ERP applications.

Local Scenario or Standalone Scenario:

In a standalone scenario, all procurement processes are executed in SAP SRM, and shopping carts and other procurement documents are processed in SAP SRM. Only final invoice data is sent to the backend accounting system. Account assignments are checked locally with accounting data defined in SAP SRM.

Applicability:

This is applicable for the following customer types:

• Customers who do not have an operational and/or productive backend system for materials management and have only financial accounting systems.
• Customers who want to move all procurement activity for selected categories to the SAP SRM system. This enables companies to reduce the load on the backend procurement (MM) system by transferring buyers who deal in these selected categories.
• Customers who do not have their own product data, those who want to maintain only minimal product data, and those who want to rely on supplier catalogs.
• Customers who want to use procurement card functionalities.
• Customers who want to use all of the functionalities in the service procurement scenario.
• Customers who want to involve suppliers in procurement transactions using Supplier Self- Service (SUS) integration with SAP SRM.

Process Flow:

Below diagram (Figure 2) depicts the process flow for Standalone scenario where Enterprise Buyer is the SRM system (or Portal) and the backend can be any system either SAP or non-SAP. Except the invoice posting, all other documents are created in SRM system.

Figure 2: Process Flow for Local or Standalone Scenario

Process Flow is as follows:

• An employee searches the catalogs and creates an online shopping cart for his requirements.
• The system triggers an approval workflow based on the workflow start conditions defined in the configuration settings. The workflow is routed to the mailbox of the approving manager, who approves or rejects the shopping cart.
• If the shopping cart is approved, the system creates a purchase order in the SAP SRM system. If the data is incomplete, the shopping cart is moved to a purchaser’s work list in sourcing (commonly referred to as the sourcing cockpit) from where the purchaser creates the purchase order.
• The goods receipt for materials or service entry sheet for services is created in the SAP SRM system as confirmation.
• An invoice is created in the SAP SRM system, which creates an accounting document in the backend system.

Go for Standalone scenario, if . . .

• Product categories are created in SAP SRM directly, that is, local product categories.
• The SAP SRM system is defined as the local system in the configuration setting Define Backend Systems.
• An accounting system is defined as the backend system in the configuration setting Define Backend Systems.
• The target system for the product category should be the SAP SRM system in the configuration setting Define Backend System for Product Category. You can also use the standalone scenario using backend product categories with this setting. Optionally, BAdI BBP_DETERMINE_LOGSYS is implemented to determine the target system as the SAP SRM system.

Classic Scenario:

In a classic scenario, the SAP SRM system is used mainly to capture procurement requisitions from employees in the form of shopping carts. All other procurement activities take place in the backend materials management system.

Applicability:

This is applicable for the following customer types:

• Customers who have a strong backend procurement system and where buyers do not want to use multiple systems for their operations.
• Customers who want to involve suppliers in procurement transactions using SUS integration with Materials Management (MM).
• Customers have a large user base in the SAP ERP system.
• Customers have their professional purchasers using SAP MM Purchasing application and want to continue using it.
• Customers have established supplier document collaboration mechanisms in SAP ERP (e.g. EDI) and want to continue using them.

Process Flow:

Process Flow is as follows:

• An employee searches the catalogs and creates an online shopping cart for his requirements. The employee can also view the stock status for the material.
• The system triggers an approval workflow based on the workflow start conditions defined in the configuration settings. The workflow is routed to the mailbox of the approving manager, who approves or rejects the shopping cart.
• If the shopping cart is approved, the system creates a follow-on document in the backend system. The settings in the configuration setting 'Define objects in backend system' determine the type of follow- on document. The following settings are possible for each product category:
• If stock for the material is available on the requested date in the backend system, you can specify that a reservation (material issue requisition) is created.
• § Settings can be configured in such a way that the system always creates a reservation if the material belongs to a material type that is subjected to inventory management in the backend system.
• Settings can also be configured in such a way that the system never creates a reservation and always creates either a purchase requisition or purchase order.
• § Settings can be configured to always create purchase requisitions in the backend system.
• § The system can be configured to create a purchase order, if the shopping cart data is complete. If the data is not complete, the system creates a purchase requisition.
• Optionally, you can use customer- specific rules to determine the backend object by implementing BAdI BBP_TARGET_OBJTYPE.
• If the system creates a purchase requisition in the backend system, purchasers need to process the requisition and create a purchase order in the backend system.
• The purchase order is available only in the backend system. However, requisitioners can check the status of the shopping cart and view the essential purchase order information in the SAP SRM system, also.
• The goods receipt for materials or service entry sheet for services is created directly in the backend system. Alternatively, users can also create the confirmations in the SAP SRM system and the system automatically creates a goods receipt in the backend system.
• The invoice can be entered directly in the backend system. Alternatively, users can create an invoice in the SAP SRM system, which creates an invoice document in the backend system.

Figure 3: Process Flow for Classic Scenario

Go for Classic Scenario, if . . .

• At least one backend materials management system and accounting system is connected to the SAP SRM system and defined in the configuration setting Define Backend Systems.
• Product categories from the backend procurement system are replicated and used in the SAP SRM system.
• The target system for each product category is the backend system in the configuration setting Define Backend Systems for Product Category. Optionally, BAdI BBP_DETERMINE_LOGSYS is implemented to determine the backend system based on shopping cart data.
• The extended classic scenario should not be activated in the configuration setting Activate Extended Classic Scenario. If the extended classic scenario is activated, then BAdI BBP_EXTLOCALPO_BADI should be implemented to enable the classic scenario based on customer- defined rules.

Extended Classic Scenario:

In an extended classic scenario, the procurement process takes place in the SAP SRM system. The purchase order is created in the SAP SRM system and a read-only copy of the purchase order is replicated to the backend system. Goods receipts and invoices can be entered either in the backend system or in the SAP SRM system.

Applicability:

This is applicable for the following customer types:

• Purchase order response from the vendor can be captured in SAP SRM. Differences between purchase order and purchase order response, if any, can be approved by the purchaser in an interactive user interface.
• The full sourcing capabilities of SAP SRM are available in the extended classic scenario.
• Direct material procurement is enabled in the extended classic scenario only.
• Sophisticated workflow functionality is available in SAP SRM.
• Entry of confirmation is easier in SAP SRM compared to backend ERP. In SAP ERP, goods receipt for materials and service entry for services are done in two different transactions whereas in SAP SRM both goods receipts and service confirmations are done in the same transaction. In addition, SAP SRM also provides approval workflow for confirmations.
• Procurement card functionality is available in the extended classic and standalone scenarios only.
• Want their professional purchasers to work primarily in SAP SRM.
• Want to utilize complete sourcing capabilities of SAP SRM.
• Want to use out-of-the-box new communication methods with their suppliers (e.g. XML).
• Do not have the need to create SAP MM Purchase Requisition or Stock Reservation from the SAP SRM Shopping Cart.

Process Flow:

Process Flow is as follows:

• An employee searches the catalogs and creates an online shopping cart for his requirements. The employee can also view the stock status, if the material used is a stock material.
• The system triggers an approval workflow based on the workflow start conditions defined in the configuration settings. The workflow is routed to the mailbox of the approving manager, who approves or rejects the shopping cart.
• If the shopping cart is approved, the system creates a purchase order in the SAP SRM system. If the data is incomplete, the shopping cart is moved to the sourcing cockpit for further action from the purchaser.
• In the extended classic scenario, purchase orders can be created in the following ways:
• From a shopping cart
• From an external requirement created in the backend system and transferred to SAP SRM
• Directly in SAP SRM from the Transaction “Create purchase order”
• From the winning bid in a bidding or reverse auction process
• The purchase order is created in the SAP SRM system. A copy of the purchase order is replicated to the backend system. The purchase order in SAP SRM is the leading purchase order, and any changes to the purchase order can only be made in SAP SRM. The data replicated to the backend system can be influenced by implementing BAdI BBP_ECS_PO_OUT_BADI. For example, a purchasing organization in SAP SRM can be mapped to a purchasing organization in SAP ERP using this BAdI.
• The purchase order response from the supplier can be entered directly in SAP SRM or updated automatically via XML communication. The supplier may indicate a different delivery date or a different price in the response. The differences can be approved or rejected by the purchaser in an interactive user interface. A workflow can also be activated for purchase order response approvals.
• The goods receipt for materials or service entry sheet for services is created directly in the backend system. Alternatively, users can also create the confirmations in the SAP SRM system and the system automatically creates a goods receipt in the backend system.
• Invoices can be entered directly in the backend system. Alternatively, users can create invoices in the SAP SRM system, which in turn creates an invoice document in the backend system.

Figure 4: Process Flow for Extended Classic Scenario

Go for Extended Classic Scenario, if . . .

• At least one backend materials management system and accounting system is connected to the SAP SRM system and defined in the configuration setting Define Backend Systems.
• Product categories from the backend procurement system are replicated and used in the SAP SRM system.
• The target system for each product category is the backend system in the configuration setting Define Backend Systems for Product Category. Optionally, BAdI BBP_DETERMINE_LOGSYS is implemented to determine the backend system.
• The extended classic scenario is activated in the configuration setting Activate Extended Classic Scenario. Alternatively, BAdI BBP_EXTLOCALPO_BADI is implemented to control the extended classic scenario based on customer defined rules.
• If the backend system is an SAP R/3 version lower than 4.6B, you must define local purchasing organizations and purchasing groups.
• If the backend system is an SAP R/3 version 4.6B or higher, you need to map the purchasing group used in the purchase order to the backend purchase group in one of the following ways:
• Use a backend purchasing organization and purchasing group in the shopping cart and purchase order.
• Use BAdI BBP_PGRP_FIND to determine a backend purchasing group in the shopping cart.
• If a local (created in SAP SRM without reference to a backend system) purchasing group and purchasing organization are used, then a valid backend purchasing group is assigned to the RFC user that created the backend purchase order. This assignment is made in the backend system using user parameter EKG in Transaction code SU01.
• Implement the user exit of the BAPIs BAPI_PO_CREATE1 (EXIT_SAPL2012_001 and EXIT_SAPL2012_003), and BAPI_PO_CHANGE (EXIT_SAPL2012_002 and EXIT_SAPL2012_004) to determine the purchasing group with a customer- specific logic.

Decoupled Scenario:

SAP SRM officially does not have a scenario called decoupled. However, this scenario name is loosely used to indicate the ability to use the other three scenarios in parallel. SAP recognizes that the procurement strategy for each category of purchases can be different and any procurement solution should offer flexibility during implementation to cater to all requirements. Hence, SAP SRM provides the flexibility to implement all three scenarios in parallel, based on customers’ requirements.

Applicability:

Companies that wish to fully leverage the flexibility offered by SAP SRM use the decoupled scenario. For example, a company might want to use the standalone scenario for certain indirect materials and routine services, the classic scenario for stock materials so that inventory and planning capabilities of backend materials management system can be utilized, and the extended classic scenario for purchases where flexibility and greater collaboration with suppliers is required in purchase order responses.

Process Flow:

The process is as follows:

• An employee searches the catalogs and creates an online shopping cart for his requirements. The employee can also view the stock status for the material.
• The system triggers an approval workflow based on the workflow start conditions defined in the configuration setting. The workflow is routed to the mailbox of the approving manager, who approves or rejects the shopping cart.
• Alternatively, an external requirement from the backend system is received in the SAP SRM system.
• The system verifies whether the product category used is a local SAP SRM product category. If the product category is a backend product category, the system verifies whether the target system defined in the configuration setting Define backend system for product category is a local SAP SRM system. Processing of such shopping cart items is handled in SAP SRM as a standalone scenario. On approval of such a shopping cart, the system creates a purchase order in the SAP SRM system. If the data is incomplete, the shopping cart is moved to the sourcing cockpit from where the purchaser creates the purchase order. Goods receipts or service confirmations and invoices are created in SAP SRM. Accounting documents from invoice postings are updated in the backend accounting system.
• If the shopping cart does not belong to a standalone scenario, the system verifies whether the extended classic scenario is activated in the configuration setting Activate extended classic scenario. If the setting is activated, the system processes the shopping cart as described in the extended classic scenario.
• If the extended classic scenario is not activated, the system checks whether the BAdI to control the extended classic scenario (BBP_EXTLOCALPO_BADI) is implemented. If the BAdI is implemented, then the system verifies the shopping cart data with the conditions specified in the BAdI. If the conditions in the BAdI are met, then the system processes the shopping cart as described in the extended classic scenario.
• If the extended classic scenario does not apply to the shopping cart, then the system processes the shopping cart as per the classic scenario process.

Figure 5: Process Flow for Decoupled Scenario

Illustration for Extended Classic Scenario:

Below illustration takes you through the creation of various documents in an Extended Classic Scenario.

This scenario starts with creation of shopping cart from portal. Below snapshot depicts the creation of shopping cart. We can also see that we can create other documents like Purchase Order, Confirmation and Invoice also from portal.

Click on Shopping Cart. Enter the required details in the shopping cart. Below snapshot depicts the 'Create Shopping Cart' window entered with required details. Shopping Cart number is also proposed in the window.

Click on 'Order' to create a shopping cart. This will trigger a workflow for approval. Below diagram shows the status as 'Awaiting Approval' which tells that the workflow is triggered and shopping cart is created successfully. The header is also changed from 'Create Shopping Cart' to 'Display Document'.

Once the shopping cart is approved, we can see the status updated as given in the below snippet. Here, the approval process is automatic and done by the system.

As supplier is assigned to Shopping Cart, Purchase Order will be automatically created because of auto sourcing. Below snippet depicts the link.

Refer to below snippet gives a look at the Purchase Order that is created in Portal (in ordered status) with the same supplier.

Once Purchase Order is created, we can see the details of the PO in the backend system also.

Now, confirmation needs to be created in the portal. Below snippets flow you through creation of confirmation.

Step 1: Enter the PO Number and click on 'Search'.

Step 2: Select the PO in the list and click on 'Start'.

Initially, confirm quantity will be 0 and outstanding quantity will be the total quantity available. Enter the Confirm Quantity and click on Confirm button.

Step 3: Once the invoice is confirmed, Confirmation will be posted and status changes to 'Awaiting Approval' Status.

Step 4: Once approved, the Confirmation will be displayed as below. The quantity in Outstanding will be subtracted with the Confirm Quantity.

Step 5: Data is replicated in the backend system as shown below:

Goods Receipt is captured in ECC (backend system) as shown below.

Invoice can be created from Purchase Order using the transaction MIRO.

A simulation screen appears in process on which we need to click the 'Post' button.

Once clicked on Post, an invoice with a document number will be created.

Invoice can be verified in MIRO as shown below.

This completes life cycle for Extended Classic Scenario in SRM.

Take-away:

• Various Deployment Scenarios
• Illustration of Extended Classic Scenario

During my time working, I have noticed that in many cases the solution has enhancing directly on the BSP page codes or within the Webdynpros controller, being unnecessary having a standard tool to do it.

In this document I will explain how to change SRM OTR alias text from the ABAP box by the most simply way.

Introduction.

Every field label in the Webdynpro or BSP interface is linked to an OTR alias text. That makes possible to correct translation problems, or perhaps user needs to texts for understanding, that are not entirely clear.

Execution.

To make the changes there are few steps to do. I will translate the next portuguese text in Sourcing Cockpit screen:

1. Call transaction SOTR_EDIT in your SRM GUI.

2. Search for the text you want to translate by writing the exactly text you want to edit then click in Display:

3. Select the text you want referred to the Webdynpro/BSP that uses it.

3. In the menu choose: Edit -> Context -> Change:

(Sometimes transaction does not work well, so you must click first on Display and then accept on the language box of next step, try your own workaround)

4. Accept the Country/Industry box with the fields in blank.

6. Change the text with your needed text.

7. Save it in a request an transport.

Result:

Hope it help you all.

Sebastián Garófalo

This document explain customizing needed to implement without any development a N-step workflow using the "SLAPPROVER" attribute, to clarify the explanation the whole document is based on a fake business case described below.

Business Case: customer establishes that the SC will need to be approved by line managers depending on SC total value with the follow criteria:

User1 -> Approval Limit $0

Manager  of Org Unit 3 -> Approval Limit $200

Manager  of Org Unit 2 -> Approval Limit $500

Manager  of Org Unit 1 -> Approval Limit $1000

Solution Detail

Step 1) Create Organizational Units in Organizational Plan

TIP: a purchasing group must be responsible for the root organizational unit.

Step 2) Complete SLAPPROVER attribute

This attribute indicates which user will approve in case of exceed the own approval limit. The value must be US+<USER ID OF APPROVER> Ex: USAPROB3 and is completed at Position level.

For this example the SLAPPROVER attribute was customized as shown below:

Step 3) Definition of Approval Limit Values 

The Approval limit values could be defined at PFCG Role Level or at Position Level in "Extended Attributes" tab.

Definitions for the Sample:

In case you choose to maintain the approval limit at PFCG role, go to "Personalization" tab

Step 4) Worklfow Configuration

TIP : Create a BRF Rule in order to run the right process schema. 

SPRO->Cross Application Basic Settings -> Business Workflow-> Process Controlled Worklfow -> Define Process Level

Process Level Configuration

In case the system cannot determine the approver ( i.e Shopping Cart with ammount $2000 ) will run automatic approval.

Hope This Help !!

Celeste

This document contains information on “how to access MDM from SRM using custom APIs” from the scratch. Screenshots have been provided to understand with ease.

To access from MDM into SRM, there are three major steps.

1. MDM server configuration
2. SRM server configuration
3. Custom FM/ class to fetch the data

1. MDM Server Configuration

First check if you have the MDM add on installed on your SAP SRM system. If it is not installed, contact your Basis/ Infrastructure administration team to install it.

You can find it via System -> Status -> SAP System data -> component version -> component information

You should be seeing MDM_TECH software component along with it version information

Then, check if your SRM system is allowed to connect to MDM server. This information can be found on MDM installation path. The file “allow.ip” will contain the information of the IP address that can connect to MDM, whereas the file “deny.ip“ will contain the blocked list of IP address. They are just the files containing IP address and no other information.

Most of these configurations will be taken care by MDM system’s Infrastructure team.

2. SRM server configuration

Go to transaction MDMAPIC. And ABAP Implementation for MDM Version Support.

You can find all the MDM Provider classes supporting different versions of SAP. Check if your SRM system has supporting provider class for connecting to your MDM system. If the respective patch is installed, it would reflect here.

     Creating DBMS Host

Now, Double click on MDM DBMS Hosts. You can find a list of MDM DBMS Hosts maintained.

For adding a new Host, click on New Entries-> Enter a logical name for the new host, database type, and IP address / host’s domain name. Save the data.

Creating Server Connection

After that, Double click on MDM Server Connections to see the list of MDM Server connections available.

For creating a new connection, Click on New entries , enter logical name for your MDM Connection, IP address or name of DBMS host and port of DBMS (which is 20005, by default) and save the connection. An RFC destination is created by default.

You can check for it in SM59 under TCP/IP connections.

Creating MDM Repository

Double click on MDM Repositories, to see the list of MDM repositories if any.

To create a new repository, click on “New Entries”.

Enter any object name, The repository that you are connecting to (MDM repository), MDM connection that you created in the previous step, MDM DBMS host created, MDM Provider (depending upon the version). Save it (repository connection object).

Now you are done with the configuration steps. The rest is the coding part.

3. Code To Operate On Data Using The Connection Object

Data:

lw_language          TYPE mdm_cdt_language_code,

lo_mdm_connection    TYPE REF TO cl_mdm_generic_api.

lw_language-language = 'eng'.
lw_language-country  = 'US'.
lw_language-region   = 'USA'.

*-- Create instance

      CREATE OBJECT lo_mdm_api
EXPORTING
iv_log_object_name = <<object_name_created>>.

*-- Connect to MDM
lo_mdm_api->mo_accessor->connect( lw_language ).

*-- Retrieve record ids set from MDM table
CALL METHOD lo_mdm_api->mo_core_service->query
EXPORTING
iv_object_type_code      = <<mdm_table_name>>
        iv_start_with            = lv_start_position
        iv_hits_max              = lv_no_of_records
        it_query                 = lt_query
is_sort_information      = lw_sort

      IMPORTING
et_result_set            = lt_query_result_set
ev_result_size           = lv_total_size.

lt_query will contain anywhere conditions that you want to apply on the table. The table lt_query_result_set will contain the resultant record IDs. Using the record ids/keys, we retrieve the record data.

LOOP AT lt_query_result_set INTO lw_query_result_set.
      APPEND LINES OF lw_query_result_set-record_ids TO lt_keys.
   ENDLOOP.

    CALL METHOD po_mdm_api->mo_core_service->retrieve
      EXPORTING
      iv_object_type_code = <<mdm_table_name>>
      it_keys             = lt_keys
      IMPORTING
      et_result_set       = lt_result_set.

*-- Disconnecting from MDM
lo_mdm_api->mo_accessor->disconnect( ).

Note: Don’t forget to include   “TYPE-POOLS mdmif.” in your report.

            Handle all possible exceptions by looking into the respective classes.

Appendix

• Building the where condition to the “query” method – sample code.

lw_qualifier_query-value = lr_data_ref.
lw_qualifier_query-qualifier_field_code = <<table_name>>.*Eg:'MDMSRM_CATALOG_ITEMS'.
lw_query-parameter_code  =   <<Field_name>>.

"Eg: 'MDMSRM_SORTABLE_PRICE'.
lw_query-operator        = <<relational_operator>>.

"Eg: 'GE',’CS’,’SW’ etc.,
lw_query-dimension_type  = <<dimension_type>>.

"Eg: mdmif_search_dim_field.
lw_query-constraint_type = <<constraint_type>>.

"Eg: mdmif_search_constr_text, mdmif_search_constr_num etc.,
GET REFERENCE OF lv_price_from INTO lw_query-value_low.
APPEND lw_query TO lt_query.

• For more operations on MDM tables using the APIs look out for the interface IF_MDM_CORE_SERVICES. All these methods are already implemented for you. You need to consume them.

• MDM Language keys   

Please post your valuable comments on any updations, correction or your reviews. Thanks in advance.

Idea

Add catalog links to the header area.

Enhancing header component.

first you need to determine, which component to enhance. Right mouse click, select "More field help". 

So WDC is /SAPSRM/WDC_UI_SC_DOFC_HD, WDCC is /SAPSRM/WDCC_FPM_SC_HD_PR.

Go to transaction SE80, open WebDynpro component /SAPSRM/WDC_UI_SC_DOFC_HD and click on "Enhance".

Create new enhancement

Enter Enhancement name and choose a package for developments

Enter following values.

Now a new reference to catalog list WebDynpro is created. Navigate to View V_SC_BOFC_HD, and enter enhancement mode, if needed.

Right click on Root element container and select "Insert element"

Enter following properties.

Now right click on TCO_CATALOGS -> "Insert element"

Enter view container name.

save and activate the changes.

Embedding view

Navigate to window IV_L_FPC_CA_HDR, enter enhancement mode (if neccessary).

Right click on view container and select "Embed View"

Select view to embed via search help.

Save and activate changes.

Enhancment for WD configuration

Goto Repository information system and search for WebDynpro Component Configuration /SAPSRM/WDCC_FPM_SC_HD_PR.

Start configurator

Click on "Create enhancement" in the opened window.

Enter Enhancement Name and Package

Change created enhancement.

Add new usage definition.

Add component /SAPSRM/WDC_UI_SC_DODC_CC for created usage ZSRM_CATALOG_LIST and save the changes.

Enhance Initialization

Go to Component controller properties of /SAPSRM/WDC_UI_SC_DOFC_HD,  enter enhancement mode and add a component usage.

Double click on interface controller.

Save and activate the changes.

Go to Component Controller methods and enter enhancement mode. Then add post exit for method L_FPC_GENERAL__INIT.

Click on "WD Wizard"

Select Component use via Wizard.

Adopt code as following.

Save and activate the changes.

Result

You have catalog links under your header data

P.S.:  English language is not my native language, and any person is not insured from mistakes and typing errors. If you have found an error in the text, please let me know - I'll correct the post.

P.P.S.: If you have some ideas, how to correct/improve this post - please don't hesitate to leave a comment.

Issue - Shopping Cart approved, But PO is not created and the shopping cart is stuck in "item in transfer status".

1. Run function module BBP_REQREQ_RESUBMIT. Enter shopping cart number in reqno field and execute.

If the issue still persists then follow the below steps:

1. Go to transaction BBP_PD and get details for the shopping cart –

2.      Check if Inactive Flag is not set for status “Item in Transfer Process” - I1111

3. Put “transfer” into the command window & enter –

4. Put break point at FM BBP_PD_SC_TRANSFER_INTERNAL

5. Then go inside function module

6.  Get details for internal table “it_status”-

7. Change INACT field for row with STAT  = ‘I111” to ‘X’ and then execute (F8).

8. In BBP_PD the status changes to “Follow-on document created” and PO gets created.

You can define your own mass change parameters for the Mass Changes function in Contract Management. 

For developing additional customer fields for the Contract Mass Change in SRM, the sap help document can be used:

Implementation:

For contract mass changes, the following packages are provided:

• /SAPSRM/PDO_AO_CTR_MASS for business logic
• /SAPSRM/CH_WD_UI_AO_CTR_MASS for UI

SAP Help Documentation:

http://help.sap.com/saphelp_srm70/helpdata/en/8d/3a9442bf2d1031e10000000a1550b0/content.htm

• User performs all the steps according the guideline.
• User maintains new z entry in table view BBPV_CTR_MASSOP
• User creates a z structure and z table type in the ABAP Dictionary and includes components to store old values and new values for mass change.
• As given in the guideline user creates webdynpro component ZWDC_UI_* and a view V_AO_CTRM* .
• User has given the UI information in the method CTR_DEFINE_UI of BADI “/SAPSRM/CTR_MC_BADI”.
• User copies the code as in  sap help documenation Point 5 c)

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

point 5 c)

                            c.      Implement the interface methods above as per the desired logic and activate the methods and BAdI.

See the Incoterm implementation class /SAPSRM/CL_CTR_MC_HI_INCOTERM.

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

   E.g. of copied code snippet:

Z implementation is completed with the help of sap document.

Perform Contract Mass Change for Customer Specific Field:

• User logs in to the SRM portal as a strategic purchaser and goes to Strategic Purchasing -> Contract Management -> Select Contracts -> Click on Mass Change Button -> Define Mass Change
• User selects the Parameter for mass change by selecting z field and system gives a dump as below:

Solution:

• Login to SRM GUI.
• Go to transaction se18.
• Give enhancement spot /SAPSRM/CTR_MASS_CHANGE .
• Go to your z enhancement implementation .Go to your implementation class z* method  /SAPSRM/IF_EX_CTR_MASS_BADI~CTR_DEFINE_UI

The copied code from standard is passing plug name that is perfect for Standard, but in case of z mass change,

the parameter you need to pass is window name that you have to copy from your wd component

eg class 'ZCL_CTR_HDR_MASS_CHANGE' method:

/SAPSRM/IF_EX_CTR_MASS_BADI~CTR_DEFINE_UI,

ls_params-name = /sapsrm/if_pdo_ctr_mc_c=>gc_abap_wd_plug.

ls_params-value = 'I_V_*'

replace this code with

ls_params-value = ‘ZW_*'.

( The parameter you are passing is inbound plug, which is wrong and you

need to pass window name instead ).

• Save and activate your changes.

Once changes are activated, to perform mass changes for newly added z field, go to SRM portal, Strategic Purchasing -> Contract Management -> Select Contracts -> Click on Mass Change Button -> Define Mass Change and select custom defined z field for mass changes.

Additional Information:

Once you have performed the above mentioned steps, if you plan to use more than one z custom parameters, and to navigate

from one z parameter to another z parameter Note: 1875269 short text 'Multiple custom mass paramaters not possible in mass change' should help.

Release Information for this functionality: SRM 70 and higher releases.

Summary:

Supplier registration process is a mandatory process for sourcing activity. For any new prospect suppliers to participate in a bid, they must exist in SRM system. We can bring these bidders into system using Supplier registration process. SAP does provide a standard form for registration but most of the customers has their custom requirement which requires enhancements in it.

Process to activate standard Form:

In SRM 7.0 SAP has provided ABAP WebDyn Pro form for Registration of supplier.

Step 1: Activate SRM_SUCO_1 switch and then active Supplier Self-Registration node (@ RoS Client).

Step 2:- Under Node Questionnaire Settings maintain below configuration (RoS Client).This configuration is required to send Questionnaire after submitting registration from.

Create/Change Questionnaire

Select Product Categories for Registration

Language Selection for Questionnaire

Assign Questionnaire and Language to Product Category

Step 3:- Activate SICF service for supplier form at RoS Client. Test this service & it will open a standard form.

Enhancement section

SAP main form consists of a main component which holds multiple view containers; each view container is linked with a webdynpro component.

Step 1:-  In this exampleCustomer wants to add custom fields at General Company data component which is one of the webdynpro component linked with main form (I will be showing here for few fields for a single view).

• Go to transaction SE80 and open webdynpro component /SAPSRM/WDC_SUCO_SREG_GEN for General data.

• Add a append structure in INCL structure  INCL_EEW_BP_CSF_COMPANY_DATA. Here we are adding a custom field ZZ_SUP_TYPE. This INCL is associated with the above webdynpro view.

• Now we want to make sure that data of this custom field should also store into data base table BUT000 (Master table for business partner).
• For this we need to enhance BUT000 INCL structure INCL_EEW_BUT000 with the similar fields, add a custom append structure here as well.

• Create an UI element and bind it with custom field inserted into INCL structure.

Step 2:

Meta data settings; Go to transaction SM30 and maintain meta data  view /SAPSRM/V_MDF_S1 for RoS

Step 3:- Test Service, it will open the form, now you will able to view custom field on the screen.

Test the changes:

A Questionnaire email should have floated to Supplier provided address.

You can find that data has been saved in business partner table BUT000 (@RoS client)

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 .

Summary

1. This guide is intended to demonstrate how we could do some  changes in Standard SAP SRM  and a ref on how we could use simple code to help match up to customer requirement . These have been asked by most of the customers I have worked with so incase currently these are still not a requirement for your client you can anyway read through and ask them to incorporate it in your system and get some extra billing

From my experience I have started to develop a series of such documents which have been asked by most of the clients and in order to reduce efforts on researching on SDN, Understanding the BADIs , doing hit and trial. I intend to make life simpler by providing a Easy to use guide for the same and this is one of the first of its kind series to begin with . Do take time and check all the documents published .

Current Scenario :  Shopping cart currency is often picked from the users attributes whereas the PO is created in the backend and hence the amount in PO is calculated as per the currency conversion from user currency to PO currency which becomes cumbersome  for the requestor to correctly gauge the price involved . We cannot make the SC currency same as PO currency since it defeats the purpose of using SRM since it  has to be requestor specific however we could give user idea on what the currency of the PO would be rather them leaving them to guess it on their own .

We would make simple changes and help the Requestor  to understand the alignment .

Please go through the document and do let me know your view on the same !!

SRM WIKI

http://wiki.scn.sap.com/wiki/display/SRM/SAP+SRM

SAP SRM - INSTALLATION  ★

http://service.sap.com/srm-inst

SRM Forum  ★

http://scn.sap.com/community/srm/content

SRM Help

http://help.sap.com/srm

--SRM 7.0 Help

http://help.sap.com/saphelp_srm70/helpdata/en/

--SRM  role definition SRM 7.0官方文档

http://help.sap.com/saphelp_srm70/helpdata/en/0b/66e697e71548ee84394e7cc3424673/frameset.htm

http://help.sap.com/saphelp_srm70/helpdata/en/

--SRM 5.0 help

http://help.sap.com/saphelp_srm50/helpdata/en/37/4b4b3c99c53c33e10000000a11405a/frameset.htm

--SRM Basic Settings:

http://help.sap.com/saphelp_srm70/helpdata/en/8d/3a9442bf2d1031e10000000a1550b0/frameset.htm

PAM 

See the available SAP/SRM product version

http://service.sap.com/PAM

SAP Product Availability Matrix