demo cookbook for sap student lifecycle …...demo cookbook for sap student lifecycle management and...

Demo Cookbook for SAP Student Lifecycle Management and CRM Recruitment Prototype

Applies to: Applies to CRM 2007 and Student Lifecycle Management EHP 3

Summary This document describes how CRM Marketing features of CRM 2007 together with the HER industry solution Student Lifecycle Management can be utilized by universities in the area of Student Recruitment. The description is based on a recruitment prototype demonstration that was presented in February 2008.

Author: Barbara Bluemel

Company: SAP AG

Created on: 24 April 2008

Author Bio Barbara Bluemel has been Developer in the Student Lifecycle Management Development team at SAP AG before moving to new responsibilities (no photo available).

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 1


Table of Contents 1. Introduction .....................................................................................................................................................3 2. Role based UI Adaption for Student Recruitment ..........................................................................................3

2.1. Business Role and Configuration Key .....................................................................................................3 2.2 Change of Navigation Bar Entries and Hiding Content.............................................................................5 2.3 Configuration Tool for Adapting the UI......................................................................................................7

3. CRM objects for Modeling Recruitment Parts ..............................................................................................10 3.1 CRM Leads- Capturing the Interest of a Prospect for an Educational Offering......................................10 3.2 CRM User Status for Recruitment Stages ..............................................................................................14 3.3. CRM Products for Academic Program Information................................................................................16

4. Recruitment Prototype ..................................................................................................................................21 4.1. Introduction and Prerequisites ...............................................................................................................21 4.1.2. Prototype Overview.............................................................................................................................22 4.2. CRM Recruitment Prototype Details ......................................................................................................24

4.2.1. External List Management ...............................................................................................................................24 4.2.2. Mail Form with Questionnaire ..........................................................................................................................25 4.2.3. Mail Form with ISR link ....................................................................................................................................28 4.2.4. Campaign Automation......................................................................................................................................29 4.2.5. “Copying” a whole Campaign...........................................................................................................................32

4.3 SLCM prototype details...........................................................................................................................33 4.3.1. ISR Scenario Definition – Add Campaign Id as Characteristics .......................................................................33 4.3.2. BOR Object Type as Subtype and Delegation from BUS7051.........................................................................33 5.3.3. Workflow ..........................................................................................................................................................35

Creation of Business Partner in CRM...........................................................................................................38 Appendix: Coding Example (4.2.2. Mail Form with Questionnaire) ..............................................................40

Copyright...........................................................................................................................................................42



1. Introduction The goal of the presented material is to show how existing CRM Marketing features (CRM 2007) can be utilized for Student Recruitment. In summary:

• The role based CRM Web Client UI can accommodate many of the needs universities have in the

area of student recruitment • CRM 2007 offers a customizable User Interface which universities can adapt to their needs • Customizable CRM objects (e.g. status, transaction) for representing special recruitment parts • Customers can implement own Business Add Ins, Function modules and workflows if required

A coupling of CRM Marketing functionalities to ERP Student Lifecycle Management is possible without modification.

2. Role based UI Adaption for Student Recruitment

2.1. Business Role and Configuration Key

Terms and labels which are delivered in CRM standard are typically not reflecting universities’ business terminology. For example, instead of “products”, university users would prefer to see “educational offering” or “interests for study” displayed. Instead of “Accounts” or “Business Partners” they use the term “Prospects”. Also users may need to hide certain data or to show additional fields than are visible in CRM Marketing standard.

In CRM 2007 such changes can easily be done based on roles by means of the configuration tool.

The basis for customer defined layout is the customer own business role for CRM Web client UI and the configuration key.

The Business role is defined in IMG:

Customer Relationship Management -> Business Roles -> Define Business Role

Relevant roles for the described recruitment scenarios are:



MARKETINGPRO - CRM standard business role for marketing

ZSLCMRECRUIT - Customer own business role with own configuration Z_SLCM

Similar to a portal role, the business role controls the content a user can see, the layout and the navigation to other objects.

To change settings from the default configuration key <*> you must create your own configuration key – for example Z_SLCM – and assign that configuration key to your business role.

The Configuration key is defined in IMG: Customer Relationship Management -> UI Framework -> UI Framework Definition -> Define Role Configuration Key



Here settings have been changed from the default configuration key to the new configuration key Z_SLCM.

2.2 Change of Navigation Bar Entries and Hiding Content

In order to change navigation bar entries (terms), to hide certain content or to add own new content, an own navigation bar profile must be defined in IMG:

Customer Relationship Management -> UI Framework -> Technical Role Definition -> Define Navigation Bar Profile



The CRM standard Navigation Bar Profile for CRM Marketing can be copied to an own navigation bar profile with all dependent entries. Then work groups and names of logical links and other content can be changed. Based on this the relevant profiles in the below picture are:

MKT-PRO - CRM standard Navigation Bar Profile for CRM Marketing

Z_SLCM - Customer own Navigation Bar Profile

At the end this new Navigation Bar Profile must be assigned to the business role in the same transaction where the business role was defined:

This transaction also allows to hide content. See chapter “Adjust Work Center Group Links” and “Adjust Direct Link Groups”.



2.3 Configuration Tool for Adapting the UI

The UI adaption can be done directly in the UI by a user who has the administration rights. In order to do that, the user must be assigned to the business role s/he wants to adapt. When the UI is called for the first time, option “Personalize” on the top needs to be selected. There the following page is available:

Here click on “Personalize Settings” in the settings area to see the following page:



For the UI adaption the flag “Enable configuration mode” must be switched on.

After that preparation you can go into the component where you want to change something – adding or hiding assignment blocks on the overview page of a component, adding or hiding single fields or changing field labels. There you have to click on the tool icon below the back on the top right side.

On the following screen it is necessary to copy the default configuration to your own configuration key – in this example Z_SLCM – and then you can adapt parts for this configuration.



After that make sure that the line for your configuration is marked and you can change terms and do other changes.



3. CRM objects for Modeling Recruitment Parts For modelling Student Recruitment in CRM Marketing, existing CRM Objects can be used and customized according to the needs of the university.

3.1 CRM Leads- Capturing the Interest of a Prospect for an Educational Offering

For recording results of recruitment campaigns and also for recording interests of prospects which are known from mails, letters or phone calls, the CRM One Order Object LEAD can be utilized.

The CRM One Order Framework in CRM which is also used for Activities, Service Orders, Sales Orders and other objects, is a very powerful tool because a lot of functionalities are available:

• Partner processing and partner finding • Organizational management • Document flow (successor and predecessor relations) • System status and User Status Control • Attachments • Items processing • Actions (post processing framework) that can be triggered at special events for an order instance • Dates Management • and others

Note: A lead is a special one order object for recording the interest of a person or organization in an offering of the company.

For recruitment purposes, a prospect’s interest for a study subject at the university can be recorded in a lead.

The special interest can be entered as item of the lead – i.e., the educational offering must be modelled and defined via the product workbench (see chapter 3.3.). For the different stages of this lead, the transaction user status can be utilized (see chapter 3.2.). There can be more than one open lead for a prospect with different stages as a prospect can be interested in different programs of study at different times.

For customer own settings, an own transaction type should be created by copying the existing transaction type LEAD with all dependent entries.

Transaction types are defined in IMG:

Customer Relationship Management -> Transactions -> Basic Settings -> Status Management



On the following picture an example for an own transaction type ZCM1 is shown which is copied from transaction type LEAD.

Main settings which were changed compared to the original transaction type LEAD, include the name, the description, and the status profile. It is important to change at least the name and description when copying.

Please make sure that the leading business transaction category LEAD (BUS2000108) is kept!

The status profile is described in next chapter.

Here an example for such a lead in the CRM Web Client UI is shown:



For recording the context information for a special educational offering of the university (program of study, year, study) the item processing can be used. The precondition for that is that a product category and appropriate products for the educational offering are maintained in the system. You can see and select the context information in the assignment block “products” (assignment block name can be renamed via configuration tool). For the lead with id 81 above an abstract context (product) was assigned to record a general interest in study of languages in Berlin “INTEREST_FOR_STUDY_LANGUAGE_BERLIN”.

For some hints concerning the usage of products to represent a study offering see chapter 3.4.

Our suggestion is to have always only one item per interest (lead) and to use the document flow if the context develops e.g. from a general interest to a more specialized one.

In this scenario it was done by selecting “Follow-up” and creating another lead with id 82. This follow-up lead – the successor of lead 81 – is displayed in the “Transaction history” of lead 81 with relation type “Next Document”.

The status of lead 81 was set to “replaced” manually afterwards as a more qualified interest replaces the general one.

See successor document 82:



The predecessor of the actual lead 81 is displayed in the assignment block “Transaction history”. There you see the lead for the more general predecessor interest and you can navigate there.

It is important to state that the goal of this scenario is to “win” leads: the recruitment activity has been successful if a prospect’s interest is later followed by an admission application.

Leads in status “won” can be reported in the Analytics part.

3.2 CRM User Status for Recruitment Stages

Every CRM one order object - that means also every lead and every activity – has a system status. The system statuses are delivered by SAP and can be displayed in transaction BS23.

At every time one of the so-called “life cycle system status” is set for a CRM one order object. The life cycle statuses are:

‘I1002’ - Open

‘I1003’ - In Process

‘I1004’ - Released

‘I1005’ - Completed

‘I1008’ - Finished

Besides these life cycle statuses, special other system statuses can be set to a transaction (CRM one order object) at the same time. For leads, e.g., system status ‘I1027’ – Won – for a won lead could be set. This is the system status for recording that the prospect is won as “customer” – here as student at the university.

For customer own status management the user status is available. User statuses are defined in the status profile; afterwards the status profile is assigned to the special transaction type.

The status profile is defined in IMG:

Customer Relationship Management -> Transactions -> Basic Settings -> Status Management



You see here an example for modelling recruitment stages via that user status. Note that the user status is assigned to the object CRM Order header if it is intended to use it for our purpose to control the lead processing.

User statuses are connected with the system status via so called “business transactions”. Setting the user status “Applicant” would trigger the business transaction WINN.

A business transaction is a process which results in a special system and user status. The result of the business transaction WINN is the system status I1027 “Won” as you see in transaction BS33:



We want to set user status “Applicant” also if business transaction WINN is triggered. To define this, you must go to the detail screen of a selected user status – here for user status “Applicant”.

The functionality is used in this prototype for setting the user status “Applicant” from the SLCM system. For that purpose SAP function module CRM_STATUS_CHANGE_FOR_ACTIV_OW is utilized in RFC function module ZBB_LEAD_UPDATE_FOR_ADMISSION2 (see appendix for coding).

3.3. CRM Products for Academic Program Information

It is proposed to use products and the product workbench for representing the educational offering of a university.

At first view this seems not suitable. But considering the programs of studies, courses, etc. as what universities want to offer to prospects in the recruitment process, it is reasonable.

It would not be good to create a new kind of object for educational offerings in the system because in CRM Marketing products (for the offering) and business partners (for the prospects) are the basis of the processes. The product workbench is a powerful means which offers the following functionalities:

• Own set types with own attributes can be created by the user (customizing) • The necessary set types can be assigned to a product category • Hierarchical structure of categories

Products can be searched, displayed and maintained in the CRM Web Client UI.

Search for programs of Category Id BACHELORPRG:



Display of selected program Bachelor English for spring 2008:



In order to create products, a root hierarchy and one or more categories must be created. This can be done in IMG Cross Application Components -> SAP Product -> Product without transfer from backend systems. There select activity “Maintain Categories/Hierarchies” or go to transaction COMM_HIERARCHY. Also other important setting for products can be done below “SAP Products” in the IMG.

Categories can be configured in a hierarchical structure as shown below.

It is possible to create own set types in transaction COMM_ATTRSET. The own set type can be used for the definition of the categories. Here, e.g., an own set type ZCMPROG with the attributes academic program of study, year and session.



Note: that you create own repository objects by creating an own set type (not directly but the system does it for you) – e.g., database tables and dictionary types. Therefore it can be necessary to configure the own set type in another client with appropriate settings.

If the set type is created, you can use and assign it for creating the category:

Then the set type data appears at once for the product maintenance in SAP GUI. For the CRM Web Client UI some additional steps must be done (see relevant CRM documentation).

For the displayed “Bachelor English for spring 2008” above you see these program data on an own assignment block. The set type generation was done.

In the product maintenance in SAP GUI via transaction COMMPR01 the sub screen “Program Data” is created automatically by creating the set type and category without additional effort.



4. Recruitment Prototype In this section a prototype for an integration scenario between student recruitment in CRM and Student Lifecycle Management in ERP is presented.

4.1. Introduction and Prerequisites

Prerequisite for the prototype is a configured replication of business partners according to the CRM-SLCM integration cookbook

It is assumed that all SLCM business partners which belong to students are replicated to CRM. There they are created in role “student record holder”. Other business partners are not replicated.

A business partner in CRM is only replicated to SLCM if s/he has the role “student record holder”. So it is prevented that a lot of prospects which are created in CRM recruitment process are already created in SLCM.

It is also assumed that a proper duplicate check for business partners is configured by the customer.

CRM SLCM

CRM business partners

Other

Business partners

with role

„student record holder“

Business partners

belonging to students

Replication

business partners

Other ERP

For a proper replication it is important that the number ranges and business partner groupings in both systems are maintained in a way that Id’s are identical.

This means that business partners which are created for recruitment purposes in CRM and can “turn” to “student record holders” should already be created in the right number range by means of the grouping.



4.1.2. Prototype Overview

The following two pictures show the realized scenario of the prototype. The first picture shows the recruitment activities in CRM; the second picture shows an ISR application scenario which is a reaction to a recruitment activity and which holds and updates recruitment data.

CRM SLCM

Answer?

No answer „No“

Prospects are no more considered

Mail campaign 2

With ISR link including parameter Campaign 1

Build resulting target group

Create LEAD with status „PROSPECT“ and Campaign 1 link

„Yes“

with survey

Mail campaign 1

Load prospect data

ELM



CRM SLCM

Start workflow

Does student

exist in ERP?

„yes“ „no“

Does BP exist in CRM ?

Duplicate Check of BP in CRM

ISR admission application sent (with campaign id from campaign 1)

„yes“

„no“ Send BP sync trigger

Create role student record holder for BP

Create BP in CRM in role student rec.holder

BP is created, student is created, link between both is created

replication

Send Lead Update to CRM update existing lead (found by BP and campaign 1 id)

Store campaign id as ISR attribute



4.2. CRM Recruitment Prototype Details

4.2.1. External List Management

First it is necessary to load prospect data into the system. One possible way is to use the CRM Marketing External List Management to do that. For that tool it is necessary to define the structure of a file with prospect data and the result is that business partners are created and stored in a target group.

See the following example for an external list:

In this example, the steps “Check Postal Correctness” and “Check for Duplicates” are not flagged and not carried out but in a productive system at least the duplicate check would be necessary. It must be configured with appropriate third party software.

The target group ZBB_EL10_A was created and the 2 business partners were included.



Observe that the type of the external list (“rent”, “bought”) can have an influence on the business partner replication. Normally the replication of a business partner from a rented list to ERP is prevented. Then the presented scenario would not be work completely.

4.2.2. Mail Form with Questionnaire

The first mail form is used for the first contact and contains a questionnaire with some questions (CRM Marketing survey functionality).

The hyperlink “questions” for the questionnaire is taken from the survey URL.

Questionnaires can be maintained and prepared in the survey suite in IMG:

Customer Relationship Management -> Transactions -> Settings for Leads -> Questionnaires for Leads -> Define Questionnaires

The survey Z_STUDENT_SURVEY below the LEAD node was created for the questionnaire in our scenario. Observe especially the last question “Would you like to receive the application form …“. The answer to this question controls if the prospect gets the second mail with the ISR link.



For creating a special lead with own settings as response object after an answer of the prospect the standard PAI function module CRM_SVY_LEAD_PAI of the survey must be copied to a new function module (here it is ZBB_CAMP1_SVY_LEAD_PAI), adapted and entered in the survey attributes of the selected survey (right mouse click).

In the function module some own settings must be coded. See Appendix (Chapter 5) for details.

By this coding some settings for the lead which is created after the response are done. Here the transaction type, the description, the source and the importance are set.

It is important that also the campaign guide is set as shown above. This coding line makes it possible to see the campaign id in the lead and to find the lead afterwards with the business partner Id and the campaign Id.



Note: This is not the campaign itself. It is only the campaign step which is responsible for sending the mail with the survey and so also for creating the lead.

This is a lead which was automatically created as response by these settings:

The user status “Inquirer” was not set here because the starting user status is “Prospect”.

But you see the campaign element Z_CAMP8_SVY in the Lead Details and also in the Transaction History. So you can identify where the lead comes from, navigate to that campaign element and see the essentials– par example the parent campaign Z_RECRUIT8.

This is our leading campaign which defines the campaign automation



4.2.3. Mail Form with ISR link

The second mail form which is used in the campaign automation is a mail with a link to an ISR admission application creation form.

This link is added to the mail form as hyperlink. For later identification the campaign element id which is responsible for the lead creation is added to the URL as ISR characteristics parameter in the following form:

&SCENARIO_PARAMS=CAMPAIGN=Z_CAMP8_SVY

So it is possible to

• see afterwards in the ERP system where the created ISR notification came from • update the lead in CRM remote from ERP because it can be found by the business partner and the

campaign element id Z_CAMP8_SVY

Here we use the fact that we added this in our coding of function module ZBB_CAMP1_SVY_LEAD_PAI (see last chapter).



4.2.4. Campaign Automation

The definition of the campaign is the main part for recruitment and uses all parts described so far as prerequisites.

Another prerequisite is the creation of an empty target group for collecting the positive responders.

The root in the campaign automation stands for the whole campaign.

Here it is possible to release and to start the campaign if the modelling is finished. This can be done by setting the new status “released”, saving and starting the process.

Note: One campaign can only be started once to avoid several equal contacts to same prospects.

See how a whole campaign can be copied in the development phase at the end of this chapter.



The first campaign element Z_CAMP8_SVY “first contact with survey” (on the following picture) is the element which sends the prepared mail with the questionnaire.



Note the following details:

• workflow “send target group to channel” is selected • communication medium “E-mail” is selected • prepared mail form Z_SVY_MAIL2 is used • questionnaire Z_STUDENT_SURVEY is entered for processing • target group Z_EL8_S1 from External List Management is used

The answer – if AND what the prospect answers – to the questionnaire controls the further flow.

This is modelled in the “Answer” node:

The positive answer to the question leads to the following campaign steps. Positive responders are collected in the prepared (empty) target group:



Then the prepared mail with the ISR link is sent to the target group:

4.2.5. “Copying” a whole Campaign

During the development and test phase it can be necessary to “copy” a campaign automation process because it takes some time to model the process.

This can be done by the so called “Advanced Copy” what you can trigger on the search screen:



4.3 SLCM prototype details

4.3.1. ISR Scenario Definition – Add Campaign Id as Characteristics

In order to be able to identify at a later point in time that an ISR application has been initiated by a CRM campaign, an additional characteristic is created in the ISR scenario.

This field is filled automatically when the ISR notification and form are created by submitting the form if the URL is prepared as described in chapter 4.2.3.

4.3.2. BOR Object Type as Subtype and Delegation from BUS7051

The delivered BOR object type for the notification is BUS7051. For the workflow of the prototype this BOR object type was used but an own subtype ZCMBUS7051 was created as well as a delegation of BUS7051 to this BOR object type ZCMBUS7051 (see note 507399 for creation of ZCMBUS7051 and for the delegation).

The following attributes where created additionally for that BOR object type ZCMBUS7051 compared to BUS7051:

• Scenario (ISR-Szenario) • PartnerNo (Number/Id of Business Partner – maybe of CRM Business Partner if not yet existing in

ERP) • Student Number (Student Number) • Campaign (Campaign Element Id which was stored in ISR form) • Student Objid (Student Object Id) •



The following methods where created additionally for that BOR object type ZCMBUS7051 compared to BUS7051:

• Perform Activity • CreateISRApplication • SendBPSyncSignal • Update Applicant Data • Create BP in CRM • Update Lead in CRM



5.3.3. Workflow

The BOR Object type and delegation from the last chapter is used for the workflow. The following workflow multi step task is created by using the standard tasks described below.

ISR Workflow in SLCM

Triggering events:

The creation and the update of an ISR notification are triggering events for that workflow. The basic BOR object type is BUS7051 – here delegated to the extended object type ZCMBUS7051.

First part:



Second part:



The following standard tasks are used in the multi step workflow: Trigger BP Synchronization in CRM

This standard task triggers the synchronization of the BP which exists in CRM but not in SLCM. The synchronization is triggered by creating the role “student record holder” in CRM -> BP is replicated to SLCM.

Update Applicant Data in SLCM



Creation of Business Partner in CRM

This standard task creates a business partner in CRM with a remote function call from the data which were entered into the admission application form.

Generate Object instance in SLCM: This standard task creates an object instance of the BP in SLCM



Create Admission Application in CRM: creates Admission Application in CRM as execution of an ISR activity.

Update the lead in CRM

This standard task updates the lead in CRM with a remote function call. The lead can be identified based on the BP Id and the campaign Id.



Appendix: Coding Example (4.2.2. Mail Form with Questionnaire)

In the function module some own settings must be coded as described below:

WHEN gc_survey_scenario-ca_survey. lv_process_mode = gc_mode-create.

The block

***/// BEGIN activate coding lines ** get the relevant data out of contact tracking table via MIG * IF lv_mig IS NOT INITIAL. * CALL FUNCTION 'CRM_MKTCT_GET_HEAD_ITEM_LINE' * EXPORTING * iv_mail_item_guid = lv_mig * IMPORTING * es_head_info = ls_head_info * es_item_info = ls_item_info * EXCEPTIONS * no_entry_found = 1 * OTHERS = 2. * * IF sy-subrc = 0 AND * ( ls_head_info-project_guid IS NOT INITIAL OR * ls_head_info-task_guid IS NOT INITIAL ). * ** mapping to distinguish between B2B and B2C scenario * CALL FUNCTION 'CRM_MKTCA_BP_CP_MAPPING_INV' * EXPORTING * iv_partner_guid = ls_item_info-partner_guid * iv_add_partner_guid = ls_item_info-add_partner_guid * IMPORTING * ev_bp_guid = lv_bp_guid * ev_cp_guid = lv_bp_guid_cp * EXCEPTIONS * no_partner_guid = 1 * illegal_bp_category = 2 * OTHERS = 3. * IF sy-subrc = 0. * CALL FUNCTION 'BUPA_NUMBERS_GET' * EXPORTING * iv_partner_guid = lv_bp_guid * IMPORTING * ev_partner = lv_bp_id. * * CALL FUNCTION 'BUPA_NUMBERS_GET' * EXPORTING * iv_partner_guid = lv_bp_guid_cp * IMPORTING * ev_partner = lv_bp_id_cp. * ELSE. ** do nothing * RETURN. * ENDIF. * ** fill additional parameters ** change the process type if you don't use the given one * lv_process_type = 'LEAD'. * lv_description = 'enter your description'. * lv_description_language = sy-langu. * lv_campaign_guid = ls_head_info-project_guid. * lv_task_guid = ls_head_info-task_guid. * lv_source = '006'. " Camapign Response * lv_lead_type = 'enter your value for type'. * lv_importance = 'enter your value for importance'. * ls_status-status = 'enter your user status'.



* ls_status-activate = true. * .......... * ENDIF. * ENDIF. ***/// END activate coding lines

must be activated (decommented). The following lines were coded based the special needs of our scenario:

* fill parameters for the LEAD lv_process_type = 'ZCM1'. lv_description = 'interest in study (campaign)'. lv_description_language = sy-langu. lv_campaign_guid = ls_head_info-project_guid. lv_task_guid = ls_head_info-task_guid. lv_source = '006'. " Campaign Response lv_importance = '2'. ls_status-status = 'Z002'. "status 'inquirer' ls_status-activate = true.

The lines

***/// BEGIN de-activate coding lines

LOOP AT it_survey_params INTO ls_survey_params. CASE ls_survey_params-name. WHEN 'CA_bp_id'. * sales prospect lv_bp_id = ls_survey_params-value. WHEN 'CA_cp_id'. * contact person of sales prospect lv_bp_id_cp = ls_survey_params-value. WHEN 'CA_campaign_guid'. lv_campaign_guid = ls_survey_params-value. WHEN 'CA_task_guid'. lv_task_guid = ls_survey_params-value. WHEN 'CA_process_type'. * transaction type lv_process_type = ls_survey_params-value. WHEN 'CA_description'. * description of newly created object lv_description = ls_survey_params-value. WHEN 'CA_description_language'. * language of description of newly created object lv_description_language = ls_survey_params-value. WHEN 'CA_LEAD_source'. * source of newly created object lv_source = ls_survey_params-value. WHEN 'CA_LEAD_type'. * lead type (= group) of newly created object lv_lead_type = ls_survey_params-value. WHEN 'CA_LEAD_importance'. * importance of newly created object lv_importance = ls_survey_params-value. WHEN 'CA_LEAD_status'. * user status of newly created object ls_status-status = ls_survey_params-value. * set status to active ls_status-activate = true. ENDCASE. ENDLOOP. ***/// END de-activate coding lines

are deactivated (commented).




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 the express 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 software components 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, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of 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 trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, 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 technology invented 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 services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated 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 warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials.

SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.

Any software coding and/or code lines/strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.

demo cookbook for sap student lifecycle …...demo cookbook for sap student lifecycle management and...

Documents