Migration Guide POWL SAP SRM 7.0

7/16/2019 Migration Guide POWL SAP SRM 7.0

http://slidepdf.com/reader/full/migration-guide-powl-sap-srm-70 1/38

Re lease 2009

SAP SRM 7.0

Mig rat i on Gui de

https://service.sap.com/mopz

https://service.sap.com/releasenotes

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



SAP SRM 7.0 Migration Guide

SAP SRM 7.0 2

Copyright

©Copyright 2008 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without theexpress permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary softwarecomponents of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390,OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli,Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarksof IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarksof Adobe Systems Incorporated in the United States and/or other countries.Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarksor registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide WebConsortium, Massachusetts Institute of Technology.

J ava is a registered trademark of Sun Microsystems, Inc.

J avaScript is a registered trademark of Sun Microsystems, Inc., used under license for technologyinvented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and servicesmentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG inGermany and in several other countries all over the world. All other product and service namesmentioned are the trademarks of their respective companies. Data contained in this document servesinformational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and itsaffiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The

only warranties for SAP Group products and services are those that are set forth in the express warrantystatements accompanying such products and services, if any. Nothing herein should be construed asconstituting an additional warranty.




SAP SRM 7.0 3

Contents

0 Introduction 6

1 High Level Architecture 7

1.1 Solution Overview 7

1.2 Comparison of SAP SRM 5.0 and SAP SRM 7.0 7

2 Portal 11

2.1 Overview 11

2.1.1 Purpose of this chapter 11

2.1.2 Target group 11

2.2 Preparation 11

2.2.1 Installation of SAP SRM 7.0 112.2.2 Business Packages 11

2.3 System Objects 12

2.4 Roles 12

2.5 Single Sign-On 13

2.6 User Management 13

2.7 Universal Worklist 14

2.8 Further information 14

2.8.1 Http/https 14

2.8.2 Checking the installation 14

2.8.3 More information 14

3 SRM 7.0 User Interface – ITS to Web Dynpro 15

3.1 Overview 15

3.1.1 Purpose of this chapter 15

3.1.2 Target group 15

3.2 Screen Layout and Fields 15

3.2.1 General methods of modifying Web Dynpro Screens 15

3.2.1.1 Screen modification 153.2.1.2 Personalization 16

3.2.1.3 Customization 16

3.2.1.4 Configuration 17

3.2.1.4.1 Implicit Configuration 17

3.2.1.4.2 Explicit Configuration 17

3.2.1.5 Meta Handling 17

3.2.2 Special methods of altering Web Dynpro Views 18

3.2.2.1 Move fields 18

3.2.2.1.1 Standard fields 18




SAP SRM 7.0 4

3.2.2.1.2 Table 18

3.2.2.1.3 Header area 18

3.2.2.1.4 Dynamic fields 18

3.2.3 Fields 19

3.2.3.1.1 Add fields 193.2.3.1.2 Passing values 19

3.2.3.2 Default Values for Fields 19

3.2.3.2.1 Predefined Default Values 19

3.2.3.3 Mandatory Fields 19

3.2.3.3.1 Check for mandatory fields 19

3.2.3.4 Limit/ extend field options (dropdown, radio button) 19

3.2.3.5 Tables 19

3.3 Texts and Messages 20

3.3.1 Texts 20

3.3.2 Adding System messages 20

3.4 Floorplan Manager (FPM) 20

3.4.1 Floorplan Types 20

3.4.1.1 Object Instance Floorplan 21

3.4.1.2 Guided Activity Floorplan 22

3.4.2 Action handling 22

4 Extensibility 23

4.1 Changes Needed Due to UI Technology Change from ITS to Web Dynpro 234.2 Introduction to Customer Extension Fields 23

4.3 Enhancing the data structure of a business object 24

4.4 Controlling the UI: Web Dynpro Meta Data 25

4.5 Obsolete BAdIs from the old enhancement framework of SAP SRM 5.0 25

4.6 Related SAP Notes 25

5 Workflow 26

6 POWL 27

6.1 Overview/Introduction 27

6.2 Enhancing POWL coding 28

6.3 Adding New Search Field to POWL Selection Criteria 28

6.3.1 Feeder Classes from /SAPSRM/CH_POWL_FEEDER 28

6.3.2 Feeder Classes from /SAPSRM/CH_POWL_FEEDER_AGENT 29

6.4 Adding New Result Field to POWL 29

6.4.1 Feeder Classes from /SAPSRM/CH_POWL_FEEDER 29

6.4.2 Feeder Classes from /SAPSRM/CH_POWL_FEEDER_AGENT 29

6.5 Adding New Action to POWL 29

6.6 Special Case: Item / Header based view 297 Item Hierarchy 30




SAP SRM 7.0 5

7.1 Introduction 30

7.2 Relevant SAP SRM Business Objects 30

7.3 Types of Items 31

7.3.1 Dependencies between hierarchical items 31

7.4 Item Numbering 317.4.1 Prerequisites 31

7.4.2 Item Hierarchies in SAP ERP 32

7.5 Technical Aspects 32

7.5.1 Hierarchy principles – Important Fields in SAP SRM Documents 32

7.5.2 Upgrade Aspect of Item Hierarchies from Older SAP SRM Releases 33

8 BAdI Availability List for SRM 7.0 34




SAP SRM 7.0 6

0 Introduction

This document is aimed at consultants, partners and customers who are upgrading from SAP SRM 5.0 toSAP SRM 7.0.

With SAP SRM 7.0, SAP delivers a product with more technology changes than usual in a new release. This document outlines these changes, and provides information on dealing with existing modifications,BAdI implementations and migrating SAP SRM 5.0 enhancements to SAP SRM 7.0.

The main technology changes in SAP SRM 7.0 are:

- Upgraded User Interface, from ITS to WebDynpro- Portal- New process-controlled Workflow- POWL (Personal Object Worklist)- Item Hierarchies for Service Procurement- New and obsolete BAdIs

- New SOA communication

The upgrade of the User Interface from ITS to WebDynpro can cause migration problems if the SAPSRM system has been enhanced and/or modified. See chapter 4 for more details.

In addition to this Migration Guide, we recommend you read the following documentation:

TICM Guides and Configuration Guides on the SAP Service Marketplace atwww.service.sap.com/srm-inst ->SAP SRM Server 7.0

Master Guide Upgrade Guide

Installation Guide Security Guide

Consultant Documentation: http://help.sap.com ->SAP Business Suite ->SAP Supplier Relationship Mgmt.

System Documentation: Customizing documentation, and related field help and message longtexts.

Release Notes on the SAP Service Marketplace at www.service.sap.com/releasenotes

http://help.sap.com/

http://www.service.sap.com/releasenotes

http://www.service.sap.com/releasenotes

http://help.sap.com/




SAP SRM 7.0 7

1 High Level Architecture

1.1 Solution Overview

With the release of SAP Supplier Relationship Management (SAP SRM) 7.0, SAP SRM architecture has

been revised to include new functions, and to improve existing functions. An approximate description of SAP SRM and related components in a typical customer landscape has been given below.

Database

SAP SRM Server (ABAP)

Catalog

Management

Catalog Data

OCI/XI

SAP ERP

SAP NetWeaver Enterprise Portal

Catalog UI

iView Integration

Internet PricingConfigurator

Supplier Self Services (SUS)

Firewall

Live AuctionCockpit

SAP NW BI

Database

RFC

RFC,iDOC,

SOAP/HTTP

Database

User Interface (Web Dynpro ABAP )

RFC

XI

RFC

XI

Figure 1: SAP SRM in relation to different important components

SAP SRM 7.0 now uses state-of-the-art NetWeaver Webdynpro User Interface technology, along withthe Netweaver Enterprise Portal, instead of the ITS User Interface technology used in SAP SRM 5.0. TheNW Enterprise Portal is a mandatory component of SAP SRM 7.0. Apart from the changes in UItechnology, there are many significant changes in SAP SRM 7.0 in the following areas:

Code architecture

Extensibility

Workflow Processes

Business Content

Catalog Integration

Business Reporting

1.2 Comparison of SAP SRM 5.0 and SAP SRM 7.0

A brief overview of the changes between SRM 7.0 and older releases is given below:

The new SAP SRM 7.0 architecture is completely object-oriented and modular in nature. With

this change, and improved extensibility features, it is easier to modify and extend the behaviourof delivered SAP SRM standard functions.




SAP SRM 7.0 8

The new User Interface and Portal environment makes it easier for employees to personalize theUser Interface content; for example, by using WebDynpro’s inbuilt personalization functions andPersonalized Object Work List (POWL). For your IT department, it is easier to control the usageof applications based on roles in the SAP Enterprise Portal.

The new Process-Controlled Workflow Framework makes it easier for you to introduce andcustomize complex approval processes. Older workflow frameworks from SAP SRM 5.0 andearlier releases are also supported.

In the area of Procurement and Sourcing, significant changes have taken place with the additionof new features to better support sourcing processes.

Changes in BI content and new Personalized Object Work Lists offer better reporting forBusiness Users.

Figure 2 describes the changes which have been introduced in SAP SRM 7.0.

W o r k f l o w

Figure 2: Overview – New and Changed components i n SAP SRM 7.0




SAP SRM 7.0 9

A brief description of all the changes and additions to SAP SRM 7.0 are given in the following table:

Component Description

Portal Business Content Completely new Portal Business Contenthas been introduced in SAP SRM 7.0,offering full role-based access foremployees. The new Business Contentintegrates SAP ERP user interfaces andSAP SRM user interfaces in a seamlessfashion.

Universal Work List (UWL) The new Universal Work List allowsBusiness users to see their consolidatedtask list from SAP SRM and other systems,for example, ECC.

Supplier Self Service (SUS) SUS has been enhanced to handle ECCpurchase orders with services. For

purchase orders with services, the ‘CreateConfirmation’ option replicates as a ServiceEntry Sheet in ECC.

User Interface (WD ABAP) The old ITS UI in SAP SRM 5.0 and earlierreleases has been replaced by a newABAP WebDynpro UI in SAP SRM 7.0. Thisnew UI offers numerous personalizationand customization options.

POWL, Enterprise Search, AdvancedSearch

The new Enterprise search, advancedsearch and Personalized Object Work Listallows business users to generate basicreports from personalized criteria, and store

them for repeated use.Workflow New process-controlled workflow

framework has been introduced in SAPSRM 7.0. However, the old application-controlled workflow is still supported in thisnew release.

BI Content BI content has been migrated from SAPBW 3.5 to SAP BI 7.0, which results inimproved performance and end userexperience. In SAP SRM 7.0, supplierevaluation reports have also been added.

OCI New fields, which handle the transfer of hierarchical data, have been added to theOpen Catalog Interface (OCI).

Extensibility In SAP SRM 7.0, the new WD ABAPtechnology provides modification-freeenhancements and adoptions for the UI.New fields can be easily introduced, andthe visibility of existing fields can be easilycustomized based on the document status.

To modify business logic, various newBAdIs have also been introduced in thisnew release.

Live Auction Cockpit SAP SRM 7.0 introduces a new auctiontype called Dutch Auction, and various




SAP SRM 7.0 10

small improvements have been made inother Auction types also.

Enterprise Services With SAP SRM 7.0, new EnterpriseServices have been released for:

Purchase requisitions

Contract Management

Purchase orders

Service acknowledgement

RFx

ECC There is better integration with ECC fortransferring:

Purchase requisitions

Services

Confirmations Purchase orders

Contracts

Procurement Document Layer Performance improvements have beenimplemented to improve the end userexperience.




SAP SRM 7.0 11

2 Portal

2.1 Overview

2.1.1 Purpose of this chapter This chapter outlines the most important changes for the Enterprise Portal in SAP SRM 7.0. In previousversions of SAP SRM, the portal was always optional, which means that most of the tasks could also beprocessed with the ITS. In SAP SRM 7.0, the use of the Enterprise Portal is mandatory, as it is fullyintegrated into the solution.

2.1.2 Target group

This chapter targets customers planning to introduce SAP SRM 7.0 who want to determine the effortrelated to the Enterprise Portal. This chapter does not cover every aspect of the topic.

2.2 Preparation

2.2.1 Installation of SAP SRM 7.0

For information concerning the installation of SAP SRM 7.0, and associated software units, depending onthe business scenario, refer to the following:

Master Guide – SAP SRM 7.0 – Chapter 2.2 Software Component Matrix1

Installation Guide – SAP SRM 7.01

Note 1276845 - Installation and Upgrade of SAP SRM 7.0 Note 1223493 – SAP SRM 7.0 Support Package Stack 1 SAP SRM 7.0 Release Information

2

2.2.2 Business Packages

Business packages are predefined content, comprising entire business applications and solutions, whichare used for completing business tasks. In order to download and deploy Business Packages, customersmust have installed Maintenance Optimizer

3.

In SAP SRM 7.0, the following Business Packages are relevant:

BP for SRM 7.0 (mandatory) BP ERP Common Parts (mandatory) BP Enterprise Buyer (only for harmonized scenario Procure-to-Pay) BP for Supplier Collaboration (optional)

BP for J ava Toolbox (mandatory)For further information regarding the Business Packages for SAP SRM 7.0, refer to:

Note 1232945 - BP for SAP SRM 7.0: Installing the Business Packages Notes: 731386, 1178469, 1178470

1https://service.sap.com/srm-inst

2

https://service.sap.com/releasenotes3https://service.sap.com/mopz




SAP SRM 7.0 12

2.3 System Objects

For each system that you want to integrate with the Business Package for SAP SRM 7.0, you mustcreate a system object. When doing this:

You must logon as system administrator. The system objects should be created in the customer namespace.

Object-ID: <Object ID>

System Type: SAP_R3

Description:

System name:

Authentification: SAP Logon Ticket

Message-Server: <msg_server>

SAP Client: <Client>

System-ID: <SID>

Port: <port>

Alias: See table below

Authorization:

Regarding the system alias, you must use the following naming conventions:

Backend Alias

SAP SRM Server SAP_SRM

SAP Business Information Warehouse SAP_BWSAP ERP (in Procure-to-Pay-Scenario) SAP_ECC_Procurement

SAP Records Management SAP_RM

Furthermore, we strongly recommended that you maintain the table BBP_BACKEND_DEST in the SAPSRM Server back-end system that lists all the systems connected to the Enterprise Portal.

2.4 RolesFor 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 likeHarmonized Procurement for SAP ERP & SAP SRM, SAP SRM Procurement for Public Sectoror 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.0and SAP SRM 7.0

http://help.sap.com/saphelp_srm70/helpdata/en/74/344c430fab4d0bbc30996d56cc293a/frameset.htm







SAP SRM 7.0 13

2.5 Single Sign-On

In general, the authentication for single sign-on (SSO) is set with a Logon Ticket that is generated at thefirst logon to a specific Enterprise Portal, and which must be uploaded into each target system that needsto 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 qualifieddomain names. An example:

1. https://portal/irj/portal

2. https://portal.wdf.sap.corp/irj/portalEven though URL 1 can be resolved correctly on the IP level, it can cause problems with SSO, as thebrowser 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

2.6 User Management

We recommend using single sign-on (SSO) for User Management. Therefore, the usernames in bothSAP SRM and the Portal must be the same. In order to determine which actions are necessary, thefollowing decision tree can be a help:

https://portal/irj/portal

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

http://help.sap.com/saphelp_nw70/helpdata/en/42/ea2fd5b2201bdae10000000a11466f/frameset.htm




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

https://portal/irj/portal




SAP SRM 7.0 14

Note: We recommend using ABAP only if the portal is used for SAP SRM exclusively. If the portal is notused for SAP SRM exclusively, we recommend using LDAP.

2.7 Universal Worklist

To configure the Universal Worklist for the Business Package for SAP SRM 7.0, you must create asystem connection to the SAP SRM back-end.

1) Create the UWL system: System Administration System Configuration Universal Worklist &Workflow Universal Worklist Administration Newa) Create the WebFlow Connector (for the Tasks pane)

(a) Set the System Alias as the one used for configuring the back-end system.

(b) Set the connector type as WebFlowConnector.

b) Create the Alert Connector (for the Alerts pane)

(a) Set the System Alias as the one used for configuring the back-end system.

(b) Set the connector type as AlertConnector.

2) Register the UWL system under: System Administration System Configuration UniversalWorklist & Workflow Universal Worklist Administration

For more information on the UWL, see http://uwl.pal.sap.corp:1080/uwl/index.html.

2.8 Further information2.8.1 Http/https

The decision whether to use http or https is important, as once you make this decision, it is not possibleto change the protocol in a system landscapeIf you have decided to run the portal with http, then thesystems connected to the portal must run with http as well. The same applies with https.

2.8.2 Checking the installation

In order to verify if the installation has been successful, you must navigate to the Portal Content. This canbe done in Content Administration and System Administration:

2.8.3 More information

See http://help.sap.com/srm.

http://uwl.pal.sap.corp:1080/uwl/index.html


http://help.sap.com/srm

http://help.sap.com/srm





SAP SRM 7.0 15

3 SAP SRM 7.0 User Interface – ITS to Web Dynpro

3.1 Overview3.1.1 Purpose of this chapter

Up to SAP SRM 5.0, the user interface was based on the ITS technology. This chapter providesinformation on migrating SAP SRM modifications from ITS to the new Web Dynpro technology used inSAP SRM 7.0.

3.1.2 Target group

This chapter targets customers planning to migrate to SAP SRM 7.0 who want to determine the effortrelated to their current modifications / enhancement. This chapter does not cover every aspect of the

topic.

3.2 Screen Layout and Fields

3.2.1 General methods of modifying Web Dynpro Screens

Note: This list of methods is not exhaustive. For more information, refer to the official Web Dynpro forABAP documentation.

3.2.1.1 Screen modification You can modify Web Dynpro Screens directly in transaction SE80. To determine which component andview you need to edit, right-click on the item you want to change, and select ‘More Field Help’. Thisdisplays the technical information for the field.




SAP SRM 7.0 16

After activating your changes in SE80, your modifications will be visible as soon as you restart theapplication.

Note: This does not work for FPM header fields and dynamically-added UI elements.

3.2.1.2 Personalization

The user of a Web Dynpro application can influence, to a certain degree, the appearance of a screen asdisplayed in the browser. The Web Dynpro framework provides, for each single UI element, the option of changing part of configuration (see the chapter on Component Configuration), although at the momentthis modification option is limited to the property Visibility. Without any additional effort for an applicationdeveloper, therefore, the user of an application can hide or display individual UI elements on thecurrently-displayed view.

To open the dialog box, the user positions the cursor on the UI element in question and right-clicks it.

3.2.1.3 Customization

While a single user – during a personalization process – can manipulate his or her own settings, anadministrator has the option of executing customizing settings for a larger range of users. Technically,this procedure is not different from personalization; both take place at runtime of an application. Thedifference lies in the range of the settings. In addition, an application for group settings must run in aspecial administration session. This is always automatically the case if an application was started in theportal in the preview session.

Independently of the portal, you can start an application in the following manner from within theworkbench in administration mode:

1. Double-click the name of the application in the object list.2. In theWeb Dynpro Applications menu, choose Test ->Execute in Admin.Mode




SAP SRM 7.0 17

The configuration mode then passes to an application as URL parameter SAP-CONFIG-MODE=X. Alladjustments made by the administrator in admin mode are stored as client-specific.

3.2.1.4 Configuration

Using Component Configuration, you can control the behavior of each individual component within aWeb Dynpro application. For each component, several records of configuration data can be created. Thiskind of data record contains two different types of attributes.

Implicit configuration

Explicit configuration

3.2.1.4.1 Implic it Configu ration

Each UI element has a set of attributes defined by the framework. Their values are set when a view isdesigned. Therefore, almost every UI element has the attribute Visibility. In the View Editor of the ABAPWorkbench, an application developer sets the value, for example, to ‘Yes’. Within a special application of

the component, precisely this UI element, however, should not be visible. The application developer thencreates a configuration for the component in which the value for the attribute Visibility is set to ‘No’. Whenthe respective application is called, it will also require information on which existing configuration data isto be used.

The value of the attribute Visibility is an example of a possible implicit configuration style. The attribute ispreset by the Web Dynpro Framework, and the value set by the application developer is editedautomatically. There is no additional programming effort required by the component developer for implicitconfiguration.

Note: Many, but not all, of the attributes of UI elements can be overridden with the help of configurationdata.

3.2.1.4.2 Expli cit Configuration

This is only possible if the component contains a Configuration Controller. This can contain severalcontext elements, which are set in the explicit configuration of a component. This does not necessarilyaffect the screen directly.

3.2.1.5 Meta Handling

The SAP SRM Meta Handling framework controls whether a field is read-only, whether it is visible, andwhether it is marked as a required field. This is done via entries in a Database Table.

You use the following Views to access the data:

View Description

/SAPSRM/V_MDA_HC Customer Meta Data Configuration for Actions at Header Level

/SAPSRM/V_MDA_IC Customer Metadata Configuration for Actions on Item Level

/SAPSRM/V_MDASBC Customer Action Meta Data Configuration at Set Level

/SAPSRM/V_MDF_HY Customer Meta Data Configuration for Header Fields

/SAPSRM/V_MDF_IY Customer Metadata Configuration of Item Fields

/SAPSRM/V_MDFSBY Customer Configuration Table for Metadata of Set Fields

/SAPSRM/V_MDS_HC Customer Meta Data Configuration for Header Set Types

/SAPSRM/V_MDS_IC Customer Meta Data Configuration of Set Types at Item Level




SAP SRM 7.0 18

3.2.2 Special methods of altering Web Dynpro Views

This chapter describes some common methods of screen altering.

3.2.2.1 Move fields

There are different ways of moving Web Dynpro Elements, depending on the type and the source of these fields.

3.2.2.1.1 Standard fields

If you want to move standard fields, you must modify the corresponding Web Dynpro view.

3.2.2.1.2 Table

For buttons in the table toolbar, you must do the same as for standard fields. For table columns, you do itin the same way, but you can also personalize the table. Please see chapter 3.2.3.5 for details.

3.2.2.1.3 Header area

This area is defined in the Floorplan Manager. Please see chapter 3.4 for details.

3.2.2.1.4 Dynamic fields

If you want to edit the order of dynamic fields (for example, the list of catalogs in the shopping cart), thenyou might need to change the order in the source (for example, customizing), or you might have tomodify the coding accordingly.

Header area

Standard fields

Table




SAP SRM 7.0 19

3.2.3 Fields

3.2.3.1.1 Add fields

You cannot add fields via personalization, configuration or customization, unless you have removed thefield in question previously. You can add fields as a modification and, in some cases, also via

enhancement of structures; for example, you can use customer fields to enhance the item structure of ashopping cart. However, to display these fields as well, meta handling must be enabled and thecorresponding database tables must be filled with the values for the new fields.

3.2.3.1.2 Passing values

If the fields are added by structure enhancement, their values are usually passed as well. If not, thecoding must be modified to enabling passing of the values of the new fields.

3.2.3.2 Default Values for Fields

You enter default values for fields in all the standard ways. In addition, it is possible to restrict the userfrom overwriting the default value.

3.2.3.2.1 Predefined Default Values

Some objects (for example, a shopping cart) offer a set of default values. These vales are storedaccording to each individual user.

3.2.3.3 Mandatory Fields

You can mark fields as mandatory, which determines that the document will not be processed until theuser inputs data in the field. Marking fields as mandatory can be done as modification, in a componentconfiguration, or via meta-handling framework.

3.2.3.3.1 Check for mandatory fields

The check whether a mandatory field is filled must be done in the coding. There is no general rule whereto do this, but we recommend doing it during the UPDATE method of the mapper class of the WebDynpro view.

Alternatively, you can use the method cl_wd_dynamic_tool=>check_mandatory_attributes by passing alist of nodes, elements and attributes. However, SAP SRM coding does not use this check, so the resultsof this check may differ from standard SAP SRM behavior.

3.2.3.4 Limit / extend field options (dropdown, radio button)

These fields can have several sources:

Domain fix values Customizing tables Source code

The field options can be maintained depending on their type. For domain fix values and source code, amodification is required to add or remove options from these fields. For tables, the options can bechanged in customizing.

3.2.3.5 TablesNote: The personalization menu for tables is different than that for other UI elements:




SAP SRM 7.0 20

In this menu, you set the number of visible rows, add / remove columns, and set the order of columns.

In many tables in SAP SRM, there is a link to the Settings menu in the upper right corner of the table. This Settings menu may contain the standard menu as well as blank line settings, if applicable. Bothmethods of accessing the menu lead to the same result.

3.3 Texts and Messages

3.3.1 Texts

In addition to the known text elements of classes and message texts, Web Dynpro uses the Online Text

Repository. For further information, please refer to the official documentation.

3.3.2 Adding System messages

When logging on to SAP GUI, after entering your user details, a popup might appear which displayssystem messages. However, this is not supported in SAP Enterprise Portal. To have this at start of anapplication would also require a modification of the application framework.

If you want to display a message to users when they log on, we recommend placing an iView on thestarting tab of the Portal, which is displayed to all users when logging on. In this area, the portal contentadministrator can maintain the latest news; for example, application system downtimes and deadlines forbookings.

3.4 Floorplan Manager (FPM)

The Floorplan Manager, based on Web Dynpro ABAP, is the Business Suite UI framework for easy,efficient and highly-configurable application development and adaptation. Unfortunately, at the momentthere is no modification-free enhancement strategy for FPM in connection with SAP SRM architecture.

3.4.1 Floorplan Types

There are two different types of Floorplans:




SAP SRM 7.0 21

3.4.1.1 Object Instance Floorplan

The Object Instance Floorplan provides a complete overview of an object. It consists of the followingareas:

Header Area. This contains the title of the document and some basic information. Top toolbar and bottom toolbar: These contain available actions for this object. The bottom

toolbar is a copy of the top toolbar. Tabstrip area (optional). If an object has several subscreens, these can be accessed via this

tabstrip Content area. This contains the actual content, made from standard Web Dynpro components.

All the elements can be maintained in the FPM component configuration, but the content is only linkedthere. The content Web Dynpro components are maintained in ABAP Workbench (transaction SE80).

Header area

Content area

Top toolbar

Bottom toolbar

Tabstrip area




SAP SRM 7.0 22

3.4.1.2 Guided Activity Floorplan

The Guided Activity Floorplan contains a roadmap with several steps to guide the user through theprocess. The screen is built up as follows:

Header Area: Contains the step description. Roadmap: Provides an overview of the steps. Top toolbar and Bottom toolbar: These contain the same buttons. Content Area: Web Dynpro Components are embedded here.

The areas can be maintained in the Component Configuration of the Floorplan manager. The link to thecontent is maintained there as well; however, the component is a usual Web Dynpro component, and ismaintained in ABAP Workbench.

3.4.2 Action handling

Each floorplan application has a class that handles the actions triggered from the top or bottom toolbar.

Header area

Roadmap

Top toolbar

Content area

Bottom toolbar




SAP SRM 7.0 23

4 Extensibility

4.1 Changes Needed Due to UI Technology Change from ITSto Web Dynpro

If you have extended and/or modified your SAP SRM system in SAP SRM release 5.0 or lower, you mayneed to migrate the extension/modification so that it is compatible with the new UI technology. Take thefollowing measures to avoid any potential migration issues:

If you have defined extension fields for SAP SRM documents, then you need to specify metadata for them using the new SAP SRM meta data framework. For more information, see section4.4.

BAdIs implemented in SAP SRM 5.0 or lower in order to set field meta data, like visibility andeditability, are SAPGUI-specific. You must replace them with entries in the new SAP SRM metadata framework. For more information, see section 4.4.

If you used SY-TCODE and/or SY-UCOMM in BAdI implementations or other coding, then thatcoding is dependant on UI technology. With the new Web Dynpro UI, these fields are not set andcannot be used anymore. You must adapt the the coding to the new UI technology. See SAPnote 1334202 for details.

If you used information in BAdI implementations that is not provided in the interface, like readingdata using dynamic assigns, or storing data in static variables for use in other BAdIs or later callsof the same implementation, be aware that this may not work any more.

You must migrate any extended and/or modified coding that relates to SAPGUI UI functiongroups and changes to ITS templates.

The list above may be incomplete. You must review all the extensions and modifications to yourSAP SRM system, and determine if they are dependant on UI technology. If they are, you mustmigrate them.

4.2 Introduction to Customer Extension Fields

The following business objects (BO) in SAP Supplier Relationship Management (SAP SRM) can beenhanced by the Enhancement Framework for Customer Fields and Tables:

Shopping Cart (SC) Purchase Order (PO) Purchase Order Response (POR) Confirmation Bid invitation (RFx) Bid (RFx response) Contract (CTR) Auction

Customer extension fields can be added to the BO header or BO item structures, and appear afteractivation on the UI, on the Basic Data tab of the header or item. The extension fields are distributedequally on the left and right field container of this Basic Data tab.

Furthermore, a BO header or item can be enhanced by customer-added tables. The content of theseextension tables is displayed on a separate tab, provided by the enhancement framework, on the BO

header or item.




SAP SRM 7.0 24

Note: There is no BO header provided for Shopping Carts.

4.3 Enhancing the data structure of a business object

For more information on implementing customer extension fields and tables, see Customizing for SAPSupplier Relationship Management under SRM Server Cross-Application Basic SettingsExtensions and Field Control (Personalization)




SAP SRM 7.0 25

Implementing a customer extension field or table requires two steps

1. DDIC declaration for field definition2. UI meta data configuration for field activation and control

For both steps, detailed documentation is attached in Customizing for SAP SRM. The DDIC declarationis guided by the customizing tool, which ensures the selection of the correct DDIC to be enhanced, andproposes a proper naming convention.

The new fields can be defined as database-persistent, or only for display; for example, numbers whichare derived from other persistent data.

In the case of a display-only field, the data supply is handled by BAdIs which are accessible by.a link inthe Customizing documentation.

4.4 Controlling the UI: Web Dynpro Meta Data

The visibility of the extension fields and tables is controlled dynamically at runtime by the meta data-handling framework. There are two types of meta data:

Static meta data. This is maintained directly by a set of customizing maintenance views. Thismeta data can be overwritten by dynamic method calls.

Dynamical meta data. This can be modified at runtime by customer-added coding, whichdirectly controls the visibility of the new, customer-added UI elements.

The customer-added coding is implemented in methods of classes in customer name space. Thesemethods are then to be added to the meta data customizing which is assigned to the fields or tables tobe controlled.

Note: With these methods, you can only restrict the visibility of a field. For example, you can set the

visibility of a field which is ‘Editable’ to ‘Display only’, but you cannot set a page which is ‘Display only’ to‘Editable’.

4.5 Obsolete BAdIs from the old enhancement framework of SAP SRM 5.0

As of SAP SRM 7.0, the following BAdIs are no longer used:

BBP_CUF_BADI

BBP_CUF_BADI_2

BBP_UI_CONTROL_BADI

These BAdIs were used for defining additional screens which displayed extension fields and tables, andfor controlling field meta data, such as visibility and editability. They are replaced by the new extensionfield and extension table framework, and the new meta data framework. For a list of BAdIs from SAPSRM 5.0 or lower that are still valid,,see chapter 8.

4.6 Related SAP Notes

For the component SRM-EBP-CA-DEX, the following SAP notes are available:

SAP Note 1103956 “Meta Data Handling in SRM 6.0 ”

http://c/l

http://c/l




SAP SRM 7.0 26

SAP Note 1115579 “How to create SRM Web Dynpro field enhancements” SAP Note 1334202 “How to get current action ID and transaction group”

5 Workflow

SAP SRM 7.0 provides a smooth transition for upgrade customers with respect to approval workflows. This is true for upgrade customers upgrading from SAP SRM 6.0, but also for those upgrading from SAPSRM releases 5.0 and below.

Approval workflows which have been implemented based on SAP SRM releases 5.0 and below can beused, to a large extent, after the upgrade to SAP SRM 7.0 without having to perform a disruptivemigration procedure.

In particular, workflows based on BAdI implementations (BBP_WFL_APPROV_BADI) are still supported,and thus potentially high investments are preserved.

More details can be found in the following documents:

Upgrade Guide (chapter 6.22 SAP SRM Server: Workflow Upgrade):

http://service.sap.com/~sapidb/011000358700001880282008E

Workflow in SRM7.0http://service.sap.com/~form/sapnet?_SHORTKEY=01100035870000712945&_SCENARIO=01100035870000000202&

Both documents can be found on the SAP Service Marketplace at http://service.sap.com/srm-inst SAPSRM SRM Server 7.0.


http://service.sap.com/~form/sapnet?_SHORTKEY=01100035870000712945&_SCENARIO=01100035870000000202&


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

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







SAP SRM 7.0 27

6 POWL

6.1 Overview/Introduction

POWL – What it i s

The Personal Object Worklist (POWL) is a tool offered in the Enterprise Portal. It delivers an overview of the objects the user is working with, and provides him or her with the ability to access individual objectsfor further processing.

Although there is already a generic worklist tool, called the Universal Work List (UWL), offered inEnterprise Portal, this does not provide satisfactory user-definable work lists. The UWL shows the userthe objects he or she is obliged to process; for example, workflow items and alerts from an attached SAPSRM system, but not any other objects that the user may wish to review. The creation of a custom querythat delivers a comprehensive list of objects is therefore not in scope of the UWL.

This is where the Personal Object Worklist (POWL) comes in: It is aimed at providing the user with aportal-based interface that he or she can use to define (and, optionally, store) personal queries by meansof selection parameters. Moreover, it is possible to flag such queries as “activated” so their results areimmediately visible when navigating to a portal page/work set containing the respective POWL iView.

This way, the user has his or her custom “workload” right at hand .

The POWL screen consists of the name of the POWL, and two sections. The first one shows theavailable POWL queries ordered by POWL category. The second one displays the results of the chosenPOWL query with corresponding action buttons.

Name of POWL

POWLCategory

POWL Query

Actions forchosen Query

FirstSection

SecondSection

POWLResultTable

of chosenQuery

chosenQuery

In SAP SRM, Context POWL is a Web Dynpro application for displaying the documents and executingactions on it. It replaces the search screens such as ‘check status’ from SAP SRM 5.0.




SAP SRM 7.0 28

All queries in POWL are represented by feeder classes.

For the business objects Contract, Purchase Order, Confirmation and Shopping Cart, you can enable anembedded search, based on TREX. The rest is based on the old search functions; for example, FM FMBBP_PROCDOC_GETLIST).

The feeder classes with the embedded search enabled are using the new Search Agent, and can befound in the package /SAPSRM/CH_POWL_FEEDER_AGENT. The other feeder classes are found inthe package /SAPSRM/CH_POWL_FEEDER.

6.2 Enhancing POWL codingIf you need to enhance the coding of a feeder class, we recommend using the OO functionality. Create anew Z Feeder Class, inherited from the SAP-delivered class, and redefine corresponding methods bycalling the SUPER method. Implement the enhancements before or after this call.

6.3 Adding New Search Field to POWL Selection Criteria

6.3.1 Feeder Classes from /SAPSRM/CH_POWL_FEEDER

You can only add new search fields to the selection criteria of the POWL if the new fields are supportedby the search classes. When enhancing the search fields for business objects, the new fields must be




SAP SRM 7.0 29

supported by the search FM BBP_PROCDOC_GETLIST, or the coding of the corresponding feederclass method IF_POWL_FEEDER~GET_OBJ ECTS must be enhanced. If an additional mapping of thenew search values is required, this must be done there also.

For the new selection criteria to appear on the UI, the methodIF_POWL_FEEDER~GET_SEL_CRITERIA of the corresponding class must be enhanced accordinglywith UI meta data.

6.3.2 Feeder Classes from /SAPSRM/CH_POWL_FEEDER_AGENT

The enhancements must be done not in the feeder class, but in the search agent class itself. The newselection criteria can then be customized in the transaction /SAPSRM/POWL_CUST.

6.4 Adding New Result Field to POWL

6.4.1 Feeder Classes from /SAPSRM/CH_POWL_FEEDER

For new result fields, you can enhance the result structures accordingly. The new result values must bedelivered by the method GET_RESULT of the business object-specific search class, or by theimplementation in the class IF_POWL_FEEDER~GET_OBJ ECTS.

For the fields to appear on the UI, you must adapt the customizing for the POWL with transaction/SAPSRM/POWL_CUST.

6.4.2 Feeder Classes from /SAPSRM/CH_POWL_FEEDER_AGENT

You must enhance the search logic in the Search Agent class. For the fields to appear on the UI, you

must adapt the customizing for the POWL with transaction /SAPSRM/POWL_CUST.

6.5 Adding New Action to POWL

You must implement new actions for POWL in the business object- specific implementation for themethod IF_POWL_FEEDER~HANDLE_ACTION..

For the new actions to appear on the UI, you must adapt the customizing for the POWL with transaction/SAPSRM/POWL_CUST.

6.6 Special Case: Item / Header based view

In SAP SRM 7.0, an item-based view has been introduced. The user has the option of using either this orthe header-based feeder classes, which can be found in the packageSAPSRM/CH_POWL_FEEDER_AGENT.

To use these header-based classes, the user must introduce the new feeder type (transactionPOWL_TYPE) and register it on the required application (transaction POWL_TYPER). After that, thequeries based on this feeder type must be customized and registered (transaction POWL_QUERY andPOWL_QUERYR). The field, catalog, selection criteria and actions must also be customized via/SAPSRM/powl_cust. Before doing this for this feeder type, the result structure must be registerd viaview /SAPSRM/V_PWL_FS.




SAP SRM 7.0 30

7 Item Hierarchy

7.1 Introduction

As service procurement is often seen as more complex and less standardized than procurement of

goods, customers have asked SAP to enhance service procurement capabilities, particularly in the areaof structured services. This has resulted in major enhancements in SAP SRM 7.0.

Advanced sourcing for structured external services procurement (MM-SRV)

Collaborative end-to-end-process for structured services

In order to enable structured services in SAP SRM 7.0, a new item hierarchy concept - configurablehierarchies - has been implemented

4. This function is used in SAP Supplier Relationship Management

(SAP SRM) to support sourcing of purchase requisitions for service items from SAP Enterprise ResourcePlanning (SAP ERP), including service item hierarchies. This allows you to support service structureswith a maximum depth of four outline levels. In addition, hierarchies are supported in Supplier Self-Services (SUS), allowing supplier collaboration for back-end purchase orders containing service itemhierarchies.

The following example shows a service structure:

7.2 Relevant SAP SRM Business Objects

The new item hierarchies can be used in the following SAP SRM business objects5:

Shopping Cart, when processing imported MM-SRV structures from SAP ERP (Transaction Type “EXTR”).

4This hierarchy approach has originally been developed in SAP SRM 6.0 PPS 2.0 for the extended classic scenario

( Shopping Cart, RFx, RFx Response, Purchase Order and Contract )5In Procurement for Public Sector 2.0 more business objects can be enabled, such as : Purchase Order and

Shopping Cart of Transaction Type SHP and Contract.




SAP SRM 7.0 31

RFx

RFx Response

Note: In Sourcing, hierarchical item structures are grouped together, and cannot be split into several

individual documents.

7.3 Types of Items

The following types of items are supported in documents with item hierarchies:

Outlines (In the example shown above, Car Maintenance, Check Brakes). Outline items arepurely informational, and serve as a kind of folder in order to group subline items. Up to fourlevels of outlines can be defined. There must be at least one lower level item. (Example:Remove Oil).

Materials (Example: Filter).

Services (Example: Check Disks)

On the UI, the user can choose which type of item / subline item will be added.

7.3.1 Dependencies between hierarchical items

Interactions between higher level and lower level items can be:

rolling down values, from higher to lower level item

aggregation of values and quantities to the next higher item

7.4 Item Numbering

The system assigns item numbers to the hierarchical structures automatically. You can also choose to

manually assign numbers to your procurement document, in which case the system checks whether thenumbers are valid according to the configuration. Even more complex numbers (for example,alphanumeric sequences) are supported on every level of the hierarchy.

Example:

0001 Car maintenance

0001.AA Exchange Oil

0001.AA.01 - Remove Oil

0001.AA.02 - Replace Filt er

0001.AB Check Brakes

0001.AB.01 - Check Brake Pads0001.AB.02 - Check Disks

0002 Oil 4 Li ters

0003 Filter

7.4.1 Prerequisi tes

To use this function, you must have defined settings in:

Customizing for SAP Supplier Relationship Management under SRM Server ->Cross-Application Basic Settings ->Configurable Item Numbering ->Define Configurable ItemNumbering Scheme

Customizing for SAP Supplier Relationship Management under SRM Server ->Cross-Application Basic Settings ->Service Procurement ->Activate Service Procurement




SAP SRM 7.0 32

7.4.2 Item Hierarchies in SAP ERP

Item hierarchies have been available in SAP ERP in previous releases. In SAP SRM 7.0, new SOAinterfaces have been enabled to transmit the hierarchical structures (MM-SRV structures) from SAP ERPto SAP SRM. In the classic scenario, the hierarchical structures are transmitted from SAP ERP purchaserequisitions to SAP SRM purchase orders.

The diagram below shows the most important interfaces and the document flow of the integratedbusiness objects.

< F u n c t i o n >

Overview of Interfaces between SAP SRM and SAP ERP

7.5 Technical Aspects

7.5.1 Hierarchy principles – Important Fields in SAP SRM Documents

In SAP SRM 7.0, new fields are introduced on the header and item level of the Shopping Cart, RFx, RFxResponse and Contract (technically, the Purchase Order in SAP SRM 7.0 contains the same fields).

Hierarchy template (Header Level) : Documents which own hierarchies have a hierarchytemplate assigned on header level . The hierarchy template is a 10-digit identifier whichpoints to a hierarchy model in customizing. The aim of the template is to define which itemtypes can be inserted on the highest item level in a document, and defines which item typecan occur beneath the higher level item types. Hierarchy templates can be assigned to atransaction type. Whenever a new document is created with a transaction type assigned to ahierarchy template, the template is copied into the header of the document ( BBP_PDHSS-PS_HIER_TEMPL )

Item type (Item Level) specifies wether the item is an outline, product, service or infoline (BBP_PDISS-PS_IPT )

Control key ( Item Level , derived attribute from the item type ) which influences the follow

on activities of a document ( BBP_PDISS-PS_CTRL_KEY )




SAP SRM 7.0 33

Item process type ( Item Level, derived attribute from the item type ) which influences themeta data handling ( BBP_PDIGP-ITEM_PROCESS_TYP )

Higher level item ( Item Level ). This field points from a subitem to the higher level item (BBP_PDIGP-PS_HL_ITEM )

7.5.2 Upgrade Aspect of Item Hierarchies from Older SAP SRMReleases

The following matrix displays the hierarchy architecture used for newly-created SAP SRM documents inolder releases. In SAP SRM 6.0 and below, item hierarchies have been supported as ProcurementDocument Layer Hierarchies (indicated as PD Hierarchies in the table; The new (SRM 7.0) hierarchiesare indicated as Configurable Hierarchies).

Document Transaction Type/Description

SRM6.0 , SRM 5.0 andbelow

SRM 7.0

ShoppingCart

SHP (local) PD hierarchies PD hierarchies

ShoppingCart

EXTR (PurchaseRequisition)

Not delivered Configurable hierarchies

RFx All PD hierarchies Configurable hierarchies

RFxResponse

All PD hierarchies Configurable hierarchies

PurchaseOrder

All PD hierarchies6

PD hierarchies

Contract All Not supported Not supported

When upgrading to SAP SRM 7.0, existing documents from older systems are treated the following way:

Shopping cart – transaction type – EXTR7: A document with the EXTR process type was not

delivered in SAP SRM 6.0. If follow-on documents need to be created from an olderpurchase order, the transfer logic (SOA) ensures that both old and new hierarchies arehandled.

RFx – The RFx user interface supports both PD and PPS hierarchies. For RFx documentscreated in older releases, the UI will display the items as before. Additionally, the follow-onRFx response will also be created using the same architecture as the RFx. For copies of older documents, it is ensured that the new document created will be based on the PPS

hierarchy concept by performing the relevant mapping. No new documents will be createdusing the PD hierarchy concept.

RFx response – Follow-on documents created from an RFx response from an older releasewill be the same as those from SAP SRM 7.0. Copy of RFx response is not available tousers in all releases and hence does not need to be handled.

Contract – Contract documents in all lower releases supported only flat items.

In general, documents from older releases do not have a hierarchy template assigned, and are notactivated for item hierarchies.

6

PD Hierarchies in a Purchase Orders could exist in case that the predecessor document has been created with PDHierarchies7 This transaction type has been introduced in SRM 7.0 to identify external requirements




SAP SRM 7.0 34

8 BAdI Availabili ty List for SAP SRM 7.0 The following list shows which BAdIs are still valid for SRM 7.0

Node Description Tech Name avail. for 7.0

Input Values for Temporary

Contact Person Creation FILL_DUMMY_CONTACTPERSON no obsolete, only for BidInv

Changes to PurchasingDocument Data BBP_DOC_CHANGE_BADI

Yes, but call logic and filling of parametersmight have slightly changed due todifferent communication between UI and

purchasing document layer, critical: SY-UCOMM SY-TCODE, etc.

Rounding of Quantity Fields BBP_ROUNDING_BADI yes, Purchase Documents

Changes to Purchasing Groupand Purchasing Organization

Assignments BBP_PGRP_ASSIGN_BADI yes

Carry Out Activity When Saving BBP_DOC_SAVE_BADI

yes, Purchase Documents, could behaveslightly different dependant on workflow,

new update logic Version Control BBP_VERSION_CONTROL yes, Purchase Documents

Determine Driver Function

Modules BBP_DRIVER_DETERMINE yes, meta bapi

Display Worklists and SearchResults Lists BBP_WF_LIST yes

Definition of Separators forMultiple Entries in Search BBP_SEARCH_SEPARATOR only Invoice

Define Questionnaire for VendorEvaluation in SRM BBP_VE_QSTN_DET_BADI yes

Control E-Mail in Global Outline Agreement BBP_CTR_MAIL_BADI no obsolete,, not used since 5.0

Define Grouping Criteria for LocalPurchase Orders BBP_GROUP_LOC_PO

yes, called in transfer multi, check impactof new back-end communication logic

Define Assignment Logic of Document Items BBP_ITEMS_COMPLETE_BADI yes, invoice and xml mapping

Define External Print Formatting

for Office Documents BBP_DOC_PRINTPROC output Document

Definition of Language and Ctryfor E-Mail and PDF for InvoiceExceptions BBP_IV_IMS_MAIL_LAN Business Objects IMS

Archive SRM Documents BBP_ARCHIVING_BADIyes, archiving (Purchase Documents andreports)

Upload/Download SRM

Documents BBP_PD_DOWNLOAD yes

Further Authorization Check forSRM Documents BBP_AUTHORITY_CHECK yes

Activation of Vendor Monitor BBP_BADI_SUPP_MONI yes

Create Skills Profile BBP_SKILLS yes

Calculation of Phased Deliveries BBP_PD_SDLN_BADIyes, transfer multi: not used in PurchaseOrder

Long Texts in SRM Documents BBP_LONGTEXT_BADIyes, conf/po: not used in DependingObjects Text

Transfer of Additional

Characteristics to SAP CCM BBP_CCM_CHAR_MAINT no obsolete, only for ccm

Alerts/Messages and Events inSRM Alert Management BBP_ALERTING yes

Default Settings for DeliveryDate and Selection Criteria BBP_CHANGE_DEFAULT yes, Shopping Card

Purchasing Document Check

Check Purchasing Document BBP_DOC_CHECK_BADI yes, Purchase Documents

Purchasing Document Check forItem BBP_ITEM_CHECK_BADI yes, Purchase Documents

Control Extended Classic Scenario

Activate Extended Classic BBP_EXTLOCALPO_BADI yes




SAP SRM 7.0 35

Scenario

Transfer Purchase Order Data toLogistics Backend BBP_ECS_PO_OUT_BADI yes

Master

Data

Changing of Vendor HierarchyTypes BBP_BUHI_VEND yes

Adaptation of Product CategoryHierarchy BBP_PRODCAT_HIER yes

Customer Field Replication in Vendor Master Data BBP_GET_VMDATA_CF yes, report for vendor master data upload

Shopping Carts and Requirement Items

Shopping Cart: Determine

Responsible Purchasing Group(s) BBP_PGRP_FIND yes

Determine Backend System /Company Code BBP_DETERMINE_LOGSYS yes

Determine Target Object in BESystem BBP_TARGET_OBJTYPE yes

Monitor Einkaufswagen:Objektanpassung /SAPSRM/BD_PDO_MONITOR_SC yes

Shopping Cart Monitor: Adjust

User-Interface Content /SAPSRM/BD_CLL_MONITOR_SC yes

Change Display in Shopping Cart(Obsolete - ITS Technology)

BBP_SC_MODIFY_UI yes

External Web Services (Catalogs, SupplierLists and so on)

Transfer Shopping Cart from

Catalog BBP_CATALOG_TRANSFER yes

Transfer Additional Parameters BBP_CAT_CALL_ENRICH yes

Deactivate Cross-Catalog Search(Obsolete - ITS Technology)BBP_WS_AGENT_SEARCH yes

Follow-On Document Generation in the

Backend System

Grouping of Shopping Cart Itemsfor Follow-on Documents BBP_BS_GROUP_BE yes, shopping card

Purchase Order in BackendSystem BBP_CREATE_BE_PO_NEW yes, meta bapi

Purchase Requisition in BackendSystem BBP_CREATE_BE_RQ_NEW yes, meta bapi

Reservation in Backend System BBP_CREATE_BE_RS_NEW yes, meta bapi

Create Contract in Backend

System BBP_CTR_BE_CREATE yes, transfer multi

Sourcing

Redetermination of the ContractTo Be Used (Quota

Arrangement) BBP_QA_REDETERM_CTR yes, Quota Arrangement

Define Execution of Sourcing BBP_SRC_DETERMINE yes

Define Sourcing via Vendor List BBP_AVL_DETERMINE yes

Change Bid Invitation Data

Before Transfer to Bidding

Application BBP_CREAT_RFQ_IN_DPE yes, tansfer multiFind and Check Sources of Supply BBP_SOS_BADI yes

Do not Allow Requirements to beMet Through Contracts BBP_SOURCING_BADI yes, Purchase Documents save, soco

Contract Management

Initial Upload BBP_CTR_INIT_UP yes

Change Contract Status BBP_CTR_STAT yes, report

Implementation of Methods forMaking Mass Changes BBP_CTR_MASS_BADI no obsolete, contract mass change

Event Control and Alerting

Alerts/Messages and Events inSRM Alert Management BBP_ALERTING yes

RFx

Dynamic Attributes in the BidInvitation BBP_DETERMINE_DYNATR yes, depending objects

Determine Bid Invitation BBP_BID_DET_PROCTYPE yes




SAP SRM 7.0 36

Transaction Type

Control of Bid InvitationPublication BBP_SAVE_BID_ON_HOLD yes

Subsequent Split of Grouping BBP_TRANSFER_GROUP yes

Control for Collaboration Folders BBP_CFOLDER_BADI yes

Interface Control Settings for BidInvitations and Bids

Account Assignment

Change Account Assignment

Category when Creating BackendDocuments BBP_ACCCAT_MAP_EXP yes

Change Account AssignmentCategory when Importing

Backend Documents BBP_ACCCAT_MAP_IMP yes

Determine G/L Acct BBP_DETERMINE_ACCT yes

Deactivate Automatic BudgetCheck BBP_BUDGET_CHECK yes

Tax Calculation

Determine Tax Code BBP_DET_TAXCODE_BADI yes

Change Tax Data BBP_TAX_MAP_BADI yes

Calculate Tax for Freight Costs BBP_FREIGHT_BADI yes

PricingSwitch On Simplified Pricing(Classic Scenario) BBP_PRICEDATA_READ yes

Confirmation and Invoice Verification

Define Target System forSending of Confirmation BBP_XML_CONF_LOGSYS yes

Send Confirmation via XML BBP_XML_CONF_SEND yes

Control Default Values for Time

Recording BBP_TREX_BADI yes

Control Entry Options forUnplanned Items BBP_UNPLAN_ITEM_BADI yes

Component Planning

Define Default Values for

Component Planning BBP_PM_DEFAULT_VAL yes

Check and Complete ComponentData BBP_PM_COMP_CHK yes

Direct Material and Plan-Driven Procurement

Control Direct Material

Procurement BBP_DP_PROD_CHK_BADI yes

Send XML Document to PlanningSystem BBP_XML_DET_SYSTEM yes

SAP Business Workflow

Authorization to Change During Approval BBP_WFL_SECUR_BADI yes

Determine Approver(Administrator) BBP_WFL_ADMIN_APPROV yes

Determination of Approver for n-

Step Dynamic Approval Workflow BBP_WFL_APPROV_BADI yes

Control Workflow for Stochastic

Document Check BBP_STOCH_CUST_BADI yes Allow Changes to Approvers BBP_CHNG_AGNT_ALLOW yes

Select Users when

Creating/Changing Approvers BBP_CHNG_AGNT_GET yes

Customer Enhancement of Offline Approval BBP_OFFLINE_APP_BADI yes

Determine Shopping Cart Value

for Purchasing Budget Workflow BBP_SC_VALUE_GET yes

SAP Business Workflow (New)

Define Agents /SAPSRM/BD_WF_RESP_RESOLVER yes

Define Deadlines for Events /SAPSRM/BD_WF_DEADLINES yes

Configure Process Levels /SAPSRM/BD_WF_PROCESS_CONFIG yes

Manage Process Restarts /SAPSRM/BD_WF_PROCESS_RESTART yes




SAP SRM 7.0 37

Adjust Search Help for Ad Hoc Agent /SAPSRM/BD_WF_ADHOC_AGENT_F4 yes

Customer Fields

Customer Field Control BBP_CUF_BADI

Replaced by SRM extension fields and

extension tables framework plus metadataframework

Customer Fields with StandardTable Control

(Obsolete - ITS Technology)BBP_CUF_BADI_2

Replaced by SRM extension fields and

extension tables framework plus metadataframework

SAP XML Interfaces

Change SAP XML InboundMapping BBP_SAPXML1_IN_BADI yes

Change SAP XML Outbound

Mapping BBP_SAPXML1_OUT_BADI yes

Document Output

Change Forms for DocumentOutput BBP_OUTPUT_CHANGE_SF output

Print Preview in Version

Comparison BBP_CHANGE_SF_VERS no, obsolete

Interface Configuration

Input Helps and Search Helps

(Obsolete - ITS Technology)BBP_F4_READ_ON_ENTRY no, obsolete

(Obsolete - ITS Technology)BBP_F4_READ_ON_EXIT no, obsolete

(Obsolete - ITS Technology)BBP_F4_MEM_UPDATE no, obsolete

(Obsolete - ITS Technology)

BBP_F4_SAVE_DB no, obsolete

BDetermine Screen Variants(Obsolete - ITS Technology)BBP_SCREENVARIANT no, obsolete

Field Control in Purchasing

Document

(Obsolete - ITS Technology)

BBP_UI_CONTROL_BADI

Replaced by extension framework and

metadata framework

Appearance of Priorities BBP_PRIO_DISPLAY

Digital Signature

Define Customer-SpecificDocument Preview /SAPSRM/BD_SIG_DOC yes

NewBadis

Customer Enhancement of Document Search Functionali ty /SAPSRM/BD_DOCUMENT_SEARCH yes

Handle Update of CustomerTable Extension for BP Suppli /SAPSRM/BD_DP_TE_BP_SAVE yes

SRM@FPM Extensibility: Subview

Definition on OIF /SAPSRM/BD_FPM_IDR_OIF_EXT yes

action handling for customers /SAPSRM/BD_MVC_ACTION yescontrol of IDR /SAPSRM/BD_MVC_IDR yes

SRM MVC Architecture: MetadataExtensibility (Customer) /SAPSRM/BD_MVC_METADATA yes

SRM MVC Architecture: WD DataExtensibility (Customer) /SAPSRM/BD_MVC_WD_DATA yes

Handle Field Extensions on PDOLayer /SAPSRM/BD_PDO_FIELD_EXTENSN yes

Customer extension for SC

monitor object adoptions /SAPSRM/BD_PDO_MONITOR_SC yes

Customer Table Extension /SAPSRM/BD_PDO_TABLE_EXT_CHNG yes

Enhancement Spot For Digital

Signature BAdi /SAPSRM/BD_SIG_DOC_ES yes

SRM Workflow EngineConfiguration: BAdIs for AgentDeter /SAPSRM/BD_WF_AGENTS yes




SRM Workflow: Dynamic ProcessLevel Configuration /SAPSRM/BD_WF_PROCESS yes

Internal BAdIs for Enhancementof the Context Navigation /SAPSRM/BDI_CH_WD_CNP yes

/SAPSRM/BDI_CLL_ACTION_EXT yes

Enhancement to filer out databefore passing it into cli /SAPSRM/BDI_CLL_COPY_CLIPBOARD yes

Internal BAdIs for extending thePOWL Feeder /SAPSRM/BDI_CLL_POWL_FEEDER yes

Enhancement of DocumentSearch Functionality /SAPSRM/BDI_DOCUMENT_SEARCH yes

Handle Update of TableExtension for BP Supplier /SAPSRM/BDI_DP_TE_BP_SAVE yes

FPM Extensibility for IDR and

OIF /SAPSRM/BDI_FPM_IDR_OIF_EXT yes

Changes to Handling of ItemProcess Types in SRM /SAPSRM/BDI_ITEM_PROCESS_TYPE yes

Internal Action Definitions for

FPM /SAPSRM/BDI_MVC_ACTION yes

idr control /SAPSRM/BDI_MVC_IDR yes

SRM MVC Architecture: Metadata

Extensibility /SAPSRM/BDI_MVC_METADATA yesSRM MVC Architecture: WD Data

Extensibility /SAPSRM/BDI_MVC_WD_DATA yes

/SAPSRM/BDI_PDO_ACTION_EXT

/SAPSRM/BDI_PDO_FIELD_EXTENSN yes

Filtering of Items retrieved from

PDO Layer /SAPSRM/BDI_PDO_ITEM_FILTER yes

BAdI for Contract Mass Changes /SAPSRM/CTR_MASS_CHANGE yes

ES for SOA Mapping /SAPSRM/ES_SOA_MAPPING yes

/SAPSRM/BD_CLL_MONITOR_SC yes

/SAPSRM/BD_CLL_POWL_FEEDER yes