Release 2009

SAP SRM 7.0Migration Guide

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.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript 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 ofany kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. Theonly 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 Migration Guide

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 11

2.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 15

3.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 Migration Guide

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 19

3.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 23

4.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 29

7 Item Hierarchy 30

SAP SRM 7.0 Migration Guide

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 31

7.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 Migration Guide

SAP SRM 7.0 6

0 IntroductionThis 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 SupplierRelationship 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

SAP SRM 7.0 Migration Guide

SAP SRM 7.0 7

1 High Level Architecture

1.1 Solution OverviewWith the release of SAP Supplier Relationship Management (SAP SRM) 7.0, SAP SRM architecture hasbeen revised to include new functions, and to improve existing functions. An approximate description ofSAP SRM and related components in a typical customer landscape has been given below.

Database

SAP SRM Server (ABAP)

CatalogManagement

Catalog Data

OCI/XI

SAP ERP

SAP NetWeaver Enterprise Portal

Catalog UI

iView Integration

Internet PricingConfigurator

Supplier SelfServices (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.0A 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. Withthis change, and improved extensibility features, it is easier to modify and extend the behaviourof delivered SAP SRM standard functions.

SAP SRM 7.0 Migration Guide

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.

Wor

kflo

w

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

SAP SRM 7.0 Migration Guide

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. Forpurchase 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 storethem for repeated use.

Workflow New process-controlled workflowframework 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 ofhierarchical 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 Migration Guide

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 Migration Guide

SAP SRM 7.0 11

2 Portal

2.1 Overview2.1.1 Purpose of this chapterThis 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 groupThis 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 Preparation2.2.1 Installation of SAP SRM 7.0For 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 Information2

2.2.2 Business PackagesBusiness 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 Optimizer3.

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 Java 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

1 https://service.sap.com/srm-inst2 https://service.sap.com/releasenotes3 https://service.sap.com/mopz

SAP SRM 7.0 Migration Guide

SAP SRM 7.0 12

2.3 System ObjectsFor 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_BW

SAP 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.0Here 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

SAP SRM 7.0 Migration Guide

SAP SRM 7.0 13

2.5 Single Sign-OnIn 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/portal2. https://portal.wdf.sap.corp/irj/portal

Even though URL 1 can be resolved correctly on the IP level, it can cause problems with SSO, as 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 ManagementWe 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:

SAP SRM 7.0 Migration Guide

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 Universal

Worklist & 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/httpsThe 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 installationIn 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 informationSee http://help.sap.com/srm.

SAP SRM 7.0 Migration Guide

SAP SRM 7.0 15

3 SAP SRM 7.0 User Interface – ITS to Web Dynpro

3.1 Overview3.1.1 Purpose of this chapterUp 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 groupThis 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 thetopic.

3.2 Screen Layout and Fields3.2.1 General methods of modifying Web Dynpro ScreensNote: This list of methods is not exhaustive. For more information, refer to the official Web Dynpro forABAP documentation.

3.2.1.1 Screen modificationYou 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 Migration Guide

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 PersonalizationThe 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 ofchanging 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 CustomizationWhile 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 the Web Dynpro Applications menu, choose Test -> Execute in Admin.Mode

SAP SRM 7.0 Migration Guide

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 ConfigurationUsing 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 Implicit Configuration

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 ofthe 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 Explicit 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 HandlingThe 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 Migration Guide

SAP SRM 7.0 18

3.2.2 Special methods of altering Web Dynpro ViewsThis 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 ofthese 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 Migration Guide

SAP SRM 7.0 19

3.2.3 Fields3.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 viaenhancement 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 FieldsYou 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 FieldsYou 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 Migration Guide

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 Messages3.3.1 TextsIn addition to the known text elements of classes and message texts, Web Dynpro uses the Online TextRepository. For further information, please refer to the official documentation.

3.3.2 Adding System messagesWhen 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 TypesThere are two different types of Floorplans:

SAP SRM 7.0 Migration Guide

SAP SRM 7.0 21

3.4.1.1 Object Instance FloorplanThe 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 Migration Guide

SAP SRM 7.0 22

3.4.1.2 Guided Activity FloorplanThe 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 handlingEach 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 Migration Guide

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 FieldsThe 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 BOheader or item.

SAP SRM 7.0 Migration Guide

SAP SRM 7.0 24

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

4.3 Enhancing the data structure of a business objectFor 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 Migration Guide

SAP SRM 7.0 25

Implementing a customer extension field or table requires two steps1. 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 DataThe 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 thevisibility 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 ofSAP 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 NotesFor the component SRM-EBP-CA-DEX, the following SAP notes are available:

SAP Note 1103956 “Meta Data Handling in SRM 6.0 ”

SAP SRM 7.0 Migration Guide

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.

SAP SRM 7.0 Migration Guide

SAP SRM 7.0 27

6 POWL

6.1 Overview/Introduction

POWL – What it is

The Personal Object Worklist (POWL) is a tool offered in the Enterprise Portal. It delivers an overview ofthe 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

POWLResult Tableof 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 Migration Guide

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_FEEDERYou 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 Migration Guide

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_OBJECTS 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_AGENTThe 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_FEEDERFor 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_OBJECTS.

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_AGENTYou must enhance the search logic in the Search Agent class. For the fields to appear on the UI, youmust adapt the customizing for the POWL with transaction /SAPSRM/POWL_CUST.

6.5 Adding New Action to POWLYou 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 viewIn 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 Migration Guide

SAP SRM 7.0 30

7 Item Hierarchy

7.1 IntroductionAs service procurement is often seen as more complex and less standardized than procurement ofgoods, 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 implemented4. 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 ObjectsThe new item hierarchies can be used in the following SAP SRM business objects5:

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

4 This 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 )5 In Procurement for Public Sector 2.0 more business objects can be enabled, such as : Purchase Order andShopping Cart of Transaction Type SHP and Contract.

SAP SRM 7.0 Migration Guide

SAP SRM 7.0 31

RFx

RFx Response

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

7.3 Types of ItemsThe 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 itemsInteractions 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 NumberingThe system assigns item numbers to the hierarchical structures automatically. You can also choose tomanually 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 maintenance0001.AA Exchange Oil

0001.AA.01 - Remove Oil

0001.AA.02 - Replace Filter

0001.AB Check Brakes

0001.AB.01 - Check Brake Pads

0001.AB.02 - Check Disks

0002 Oil 4 Liters

0003 Filter

7.4.1 PrerequisitesTo 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 Migration Guide

SAP SRM 7.0 32

7.4.2 Item Hierarchies in SAP ERPItem 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.

<Fun

ctio

n>

Overview of Interfaces between SAP SRM and SAP ERP

7.5 Technical Aspects7.5.1 Hierarchy principles – Important Fields in SAP SRM DocumentsIn 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 followon activities of a document ( BBP_PDISS-PS_CTRL_KEY )

SAP SRM 7.0 Migration Guide

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 notdelivered 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 ofolder documents, it is ensured that the new document created will be based on the PPShierarchy 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 Migration Guide

SAP SRM 7.0 34

8 BAdI Availability List for SAP SRM 7.0The following list shows which BAdIs are still valid for SRM 7.0Node Description Tech Name avail. for 7.0

Input Values for TemporaryContact 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 andpurchasing document layer, critical: SY-UCOMM SY-TCODE, etc.

Rounding of Quantity Fields BBP_ROUNDING_BADI yes, Purchase DocumentsChanges to Purchasing Groupand Purchasing OrganizationAssignments 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 DocumentsDetermine Driver FunctionModules BBP_DRIVER_DETERMINE yes, meta bapiDisplay Worklists and SearchResults Lists BBP_WF_LIST yesDefinition of Separators forMultiple Entries in Search BBP_SEARCH_SEPARATOR only InvoiceDefine Questionnaire for VendorEvaluation in SRM BBP_VE_QSTN_DET_BADI yesControl E-Mail in Global OutlineAgreement BBP_CTR_MAIL_BADI no obsolete,, not used since 5.0Define Grouping Criteria for LocalPurchase Orders BBP_GROUP_LOC_PO

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

Define Assignment Logic ofDocument Items BBP_ITEMS_COMPLETE_BADI yes, invoice and xml mappingDefine External Print Formattingfor Office Documents BBP_DOC_PRINTPROC output DocumentDefinition 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 SRMDocuments BBP_PD_DOWNLOAD yesFurther Authorization Check forSRM Documents BBP_AUTHORITY_CHECK yesActivation of Vendor Monitor BBP_BADI_SUPP_MONI yesCreate 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 AdditionalCharacteristics to SAP CCM BBP_CCM_CHAR_MAINT no obsolete, only for ccmAlerts/Messages and Events inSRM Alert Management BBP_ALERTING yesDefault Settings for DeliveryDate and Selection Criteria BBP_CHANGE_DEFAULT yes, Shopping Card

Purchasing Document CheckCheck Purchasing Document BBP_DOC_CHECK_BADI yes, Purchase DocumentsPurchasing Document Check forItem BBP_ITEM_CHECK_BADI yes, Purchase Documents

Control Extended Classic ScenarioActivate Extended Classic BBP_EXTLOCALPO_BADI yes

SAP SRM 7.0 Migration Guide

SAP SRM 7.0 35

Scenario

Transfer Purchase Order Data toLogistics Backend BBP_ECS_PO_OUT_BADI yes

MasterData

Changing of Vendor HierarchyTypes BBP_BUHI_VEND yesAdaptation of Product CategoryHierarchy BBP_PRODCAT_HIER yesCustomer Field Replication inVendor Master Data BBP_GET_VMDATA_CF yes, report for vendor master data upload

Shopping Carts and Requirement ItemsShopping Cart: DetermineResponsible Purchasing Group(s) BBP_PGRP_FIND yesDetermine Backend System /Company Code BBP_DETERMINE_LOGSYS yesDetermine Target Object in BESystem BBP_TARGET_OBJTYPE yesMonitor Einkaufswagen:Objektanpassung /SAPSRM/BD_PDO_MONITOR_SC yesShopping Cart Monitor: AdjustUser-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 fromCatalog BBP_CATALOG_TRANSFER yesTransfer Additional Parameters BBP_CAT_CALL_ENRICH yes

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

Follow-On Document Generation in theBackend System

Grouping of Shopping Cart Itemsfor Follow-on Documents BBP_BS_GROUP_BE yes, shopping cardPurchase Order in BackendSystem BBP_CREATE_BE_PO_NEW yes, meta bapiPurchase Requisition in BackendSystem BBP_CREATE_BE_RQ_NEW yes, meta bapiReservation in Backend System BBP_CREATE_BE_RS_NEW yes, meta bapiCreate Contract in BackendSystem BBP_CTR_BE_CREATE yes, transfer multi

SourcingRedetermination of the ContractTo Be Used (QuotaArrangement) BBP_QA_REDETERM_CTR yes, Quota ArrangementDefine Execution of Sourcing BBP_SRC_DETERMINE yesDefine Sourcing via Vendor List BBP_AVL_DETERMINE yesChange Bid Invitation DataBefore Transfer to BiddingApplication BBP_CREAT_RFQ_IN_DPE yes, tansfer multiFind and Check Sources ofSupply BBP_SOS_BADI yesDo not Allow Requirements to beMet Through Contracts BBP_SOURCING_BADI yes, Purchase Documents save, soco

Contract ManagementInitial Upload BBP_CTR_INIT_UP yesChange Contract Status BBP_CTR_STAT yes, reportImplementation of Methods forMaking Mass Changes BBP_CTR_MASS_BADI no obsolete, contract mass change

Event Control and AlertingAlerts/Messages and Events inSRM Alert Management BBP_ALERTING yes

RFxDynamic Attributes in the BidInvitation BBP_DETERMINE_DYNATR yes, depending objectsDetermine Bid Invitation BBP_BID_DET_PROCTYPE yes

SAP SRM 7.0 Migration Guide

SAP SRM 7.0 36

Transaction TypeControl of Bid InvitationPublication BBP_SAVE_BID_ON_HOLD yesSubsequent Split of Grouping BBP_TRANSFER_GROUP yesControl for Collaboration Folders BBP_CFOLDER_BADI yesInterface Control Settings for BidInvitations and Bids

Account AssignmentChange Account AssignmentCategory when Creating BackendDocuments BBP_ACCCAT_MAP_EXP yesChange Account AssignmentCategory when ImportingBackend Documents BBP_ACCCAT_MAP_IMP yesDetermine G/L Acct BBP_DETERMINE_ACCT yesDeactivate Automatic BudgetCheck BBP_BUDGET_CHECK yes

Tax CalculationDetermine Tax Code BBP_DET_TAXCODE_BADI yesChange Tax Data BBP_TAX_MAP_BADI yesCalculate Tax for Freight Costs BBP_FREIGHT_BADI yes

PricingSwitch On Simplified Pricing(Classic Scenario) BBP_PRICEDATA_READ yes

Confirmation and Invoice VerificationDefine Target System forSending of Confirmation BBP_XML_CONF_LOGSYS yesSend Confirmation via XML BBP_XML_CONF_SEND yesControl Default Values for TimeRecording BBP_TREX_BADI yesControl Entry Options forUnplanned Items BBP_UNPLAN_ITEM_BADI yes

Component PlanningDefine Default Values forComponent Planning BBP_PM_DEFAULT_VAL yesCheck and Complete ComponentData BBP_PM_COMP_CHK yes

Direct Material and Plan-Driven ProcurementControl Direct MaterialProcurement BBP_DP_PROD_CHK_BADI yesSend XML Document to PlanningSystem BBP_XML_DET_SYSTEM yes

SAP Business WorkflowAuthorization to Change DuringApproval BBP_WFL_SECUR_BADI yesDetermine Approver(Administrator) BBP_WFL_ADMIN_APPROV yesDetermination of Approver for n-Step Dynamic Approval Workflow BBP_WFL_APPROV_BADI yesControl Workflow for StochasticDocument Check BBP_STOCH_CUST_BADI yesAllow Changes to Approvers BBP_CHNG_AGNT_ALLOW yesSelect Users whenCreating/Changing Approvers BBP_CHNG_AGNT_GET yesCustomer Enhancement ofOffline Approval BBP_OFFLINE_APP_BADI yesDetermine Shopping Cart Valuefor Purchasing Budget Workflow BBP_SC_VALUE_GET yes

SAP Business Workflow (New)

Define Agents /SAPSRM/BD_WF_RESP_RESOLVER yesDefine 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 Migration Guide

SAP SRM 7.0 37

Adjust Search Help for Ad HocAgent /SAPSRM/BD_WF_ADHOC_AGENT_F4 yes

Customer Fields

Customer Field Control BBP_CUF_BADI

Replaced by SRM extension fields andextension tables framework plus metadataframework

Customer Fields with StandardTable Control

(Obsolete - ITS Technology)BBP_CUF_BADI_2

Replaced by SRM extension fields andextension tables framework plus metadataframework

SAP XML InterfacesChange SAP XML InboundMapping BBP_SAPXML1_IN_BADI yesChange SAP XML OutboundMapping BBP_SAPXML1_OUT_BADI yes

Document OutputChange Forms for DocumentOutput BBP_OUTPUT_CHANGE_SF outputPrint Preview in VersionComparison BBP_CHANGE_SF_VERS no, obsolete

Interface ConfigurationInput 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 PurchasingDocument

(Obsolete - ITS Technology)BBP_UI_CONTROL_BADI

Replaced by extension framework andmetadata framework

Appearance of Priorities BBP_PRIO_DISPLAYDigital Signature

Define Customer-SpecificDocument Preview /SAPSRM/BD_SIG_DOC yes

NewBadis

Customer Enhancement ofDocument Search Functionality /SAPSRM/BD_DOCUMENT_SEARCH yesHandle Update of CustomerTable Extension for BP Suppli /SAPSRM/BD_DP_TE_BP_SAVE yesSRM@FPM Extensibility: SubviewDefinition on OIF /SAPSRM/BD_FPM_IDR_OIF_EXT yesaction handling for customers /SAPSRM/BD_MVC_ACTION yescontrol of IDR /SAPSRM/BD_MVC_IDR yesSRM MVC Architecture: MetadataExtensibility (Customer) /SAPSRM/BD_MVC_METADATA yesSRM MVC Architecture: WD DataExtensibility (Customer) /SAPSRM/BD_MVC_WD_DATA yesHandle Field Extensions on PDOLayer /SAPSRM/BD_PDO_FIELD_EXTENSN yesCustomer extension for SCmonitor object adoptions /SAPSRM/BD_PDO_MONITOR_SC yes

Customer Table Extension /SAPSRM/BD_PDO_TABLE_EXT_CHNG yesEnhancement Spot For DigitalSignature BAdi /SAPSRM/BD_SIG_DOC_ES yesSRM Workflow EngineConfiguration: BAdIs for AgentDeter /SAPSRM/BD_WF_AGENTS yes

SAP SRM 7.0 Migration Guide

SAP SRM 7.0 38

SRM Workflow: Dynamic ProcessLevel Configuration /SAPSRM/BD_WF_PROCESS yesInternal BAdIs for Enhancementof the Context Navigation /SAPSRM/BDI_CH_WD_CNP yes

/SAPSRM/BDI_CLL_ACTION_EXT yesEnhancement to filer out databefore passing it into cli /SAPSRM/BDI_CLL_COPY_CLIPBOARD yesInternal BAdIs for extending thePOWL Feeder /SAPSRM/BDI_CLL_POWL_FEEDER yesEnhancement of DocumentSearch Functionality /SAPSRM/BDI_DOCUMENT_SEARCH yesHandle Update of TableExtension for BP Supplier /SAPSRM/BDI_DP_TE_BP_SAVE yesFPM Extensibility for IDR andOIF /SAPSRM/BDI_FPM_IDR_OIF_EXT yesChanges to Handling of ItemProcess Types in SRM /SAPSRM/BDI_ITEM_PROCESS_TYPE yesInternal Action Definitions forFPM /SAPSRM/BDI_MVC_ACTION yesidr control /SAPSRM/BDI_MVC_IDR yesSRM MVC Architecture: MetadataExtensibility /SAPSRM/BDI_MVC_METADATA yesSRM MVC Architecture: WD DataExtensibility /SAPSRM/BDI_MVC_WD_DATA yes

/SAPSRM/BDI_PDO_ACTION_EXT

/SAPSRM/BDI_PDO_FIELD_EXTENSN yesFiltering of Items retrieved fromPDO Layer /SAPSRM/BDI_PDO_ITEM_FILTER yesBAdI for Contract Mass Changes /SAPSRM/CTR_MASS_CHANGE yesES for SOA Mapping /SAPSRM/ES_SOA_MAPPING yes

/SAPSRM/BD_CLL_MONITOR_SC yes/SAPSRM/BD_CLL_POWL_FEEDER yes