Student Lifecycle Management Extended Booking Check Cookbook

Student Lifecycle Management: Extended Booking Check
Applies to:
All described functionality is based upon Student Lifecycle Management (SLCM) with ERP6 Enhancement Package 4 (EHP4).
Summary
This document describes how to set up pre-requisite and co-requisite checks for module booking (course registration). Readers of the document are expected to be familiar with the SAP Student Lifecycle Management product and in particular, the module booking process.
Author:
Student Lifecycle Management Development Team
Company: SAP AG Created on: January 2009
SAP DEVELOPER NETWORK | sdn.sap.com 2009 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 1
Table of Contents
1. Introduction .....................................................................................................................................................3 2. Extended Booking Check Maintenance Screen .............................................................................................3 3. Conditional Booking........................................................................................................................................5 3.1 Automatic Conditional Booking .................................................................................................................6 3.2 Manual Conditional Booking .....................................................................................................................7
3.2.1. BAdI Implementations ........................................................................................................................................7 3.2.1.1. Sample Implementation: Condition SAP8 (Pre-requisite Condition) ..............................................................8 3.2.1.2. Sample Implementation: Condition SAP9 (Co-requisite Condition) ...............................................................9 3.2.2 Creating new BAdI Implementations .................................................................................................................10 3.2.2.1 Creating Conditions for Index-Independent Sub-requirements ......................................................................10 3.2.2.1.1 Implementing the EVALUATE Method .........................................................................................................10 3.2.2.1.2 Creating Filters for Index-Dependent Sub-requirements.............................................................................12
4. Message Override Function .........................................................................................................................12 4.1 Providing Override Permission for Messages.........................................................................................13 5. Usage Guide.................................................................................................................................................14 5.1 Examples ................................................................................................................................................14 Copyright ..........................................................................................................................................................22
1. Introduction
As of SAP ECC 6.0, Enhancement Package 4, pre-requisites and co-requisites can be assigned directly to a module. Before it was only possible to define a list of modules as pre-requisites and co-requisites by using the AND relationship. For example, if you specified that modules named Basic Arts 1 and Basic Arts 2 were pre-requisites of the module Advanced Arts 1, the student was required to have completed (or at least booked) both Basic Arts modules before booking Advanced Arts 1. The system did not permit to use the OR relationship to specify that the student must have completed either Basic Arts 1 or Basic Arts 2 before booking Advanced Arts 1. With the extended booking check framework, you can implement complex conditions to be evaluated during module booking. You can have an ORrelationship between modules which allows you to implement conditions such as the one mentioned above. For example, you can set up conditions as follows: OR operator across pre-requisite modules: o Take Math 101 OR Math 102 OR Math 103 to book Math 200 AND operator across multiple OR groupings o Take (Math101 OR Math102 OR Math103) AND Take (Stat 101 OR Stat 102) to book Stat 200 OR operator across multiple AND groupings o Take (Math 101 AND Math 102) OR Take (Stat 101 AND Stat 102) to book Math 201
2. Extended Booking Check Maintenance Screen

To maintain the extended booking condition for a module (SM), a new button and a new menu entry Edit Extended Booking Condition is visible on the Module Catalog screen, which opens a new screen for prerequisite maintenance. You can also execute transaction PIQEXTCHECK to open the Edit Extended Booking Check maintenance screen. From this screen, you can search and select the module for which the pre-requisite is to be maintained. You can view the hierarchy of all requirements and sub-requirements maintained for the booking check. The screen provides a framework to create complex booking conditions, which can be easily used to fulfill real-world scenarios. To achieve this, rule containers (RC) containing rule modules (RM) can be assigned to a module. Relationship Diagram
Module (SM)
Rule Container (RC)
Rule Module (RM)
Complex booking scenarios can be built by combining rule containers and rule modules in the following way: More than one rule container can be assigned to one module. During evaluation, the AND logic will be considered among rule containers. Each rule container can contain more than one rule module. The user can switch between AND & OR logic for the rule modules within a rule container.
Use of AND & OR Logic within Rule Containers and Rule Modules
Rule Module (RM)
AND
Module (SM)
Rule Container (RC)
Rule Module (RM)
AND
Rule Module (RM)
AND
Rule Module (RM)
Rule Container (RC)

OR
Rule Module (RM)
Rule Container (RC)
Rule Module (RM)
OR
Rule Module (RM)
OR
Rule Module (RM)
The Edit Extended Booking Check maintenance screen allows direct maintenance of extended checks for a module. The following functions are available: Create new requirements (RC). Create new sub-requirements (Index-dependent RM and Index-independent RM). Enable the OR logic within the sub-requirements for the selected rule container. Delete a requirement assigned to a module. Delete a sub-requirement linked to a requirement. Select the Conditional Booking button to allow conditional booking for the selected module. Display or change the requirement assigned to the module. Display or change the sub-requirement linked to the rule container. Display the description of the sub-requirement. Display the Object Manager to search and select the desired module for which the extended booking condition is to be maintained.
Maintenance Screen of the Extended Booking Check
3. Conditional Booking
Student Lifecycle Management allows further control over module bookings by providing a function for Conditional Booking. You can conditionally book a student on a module in the following cases: The module and pre-requisite allow conditional bookings. The student has not fulfilled the requirements but is expected to fulfill them, that is, the student has taken but not yet completed a pre-requisite module. To enable conditional booking of a module, click on the Conditional Booking Allowed button on the Edit Extended Booking Check maintenance screen. Fig. 4 Conditional Booking
You can set up a conditional booking at rule container level. When the extended booking check is performed, the system checks the conditional booking status for each of the rule containers attached to a module.
The system will respond as follows: 1. Sub-requirement Evaluation The system checks whether or not the pre-requisite module has been booked and completed. If the prerequisite module is booked and completed then the user can book the module as usual. Otherwise, the system checks whether the pre-requisite module has been booked in the previous session. If it has, the module can be booked conditionally provided conditional booking has been enabled for that requirement. 2. Co-requisite Check The system checks if the co-requisite module has been booked along with the selected module. If the corequisite module is booked along with the selected module, the student can book the module as usual. If the co-requisite has been booked conditionally by the student, then the module booking is conditional. Example: you defined module English 101 as co-requisite of English 102, using the extended booking check function. If English 101 is booked conditionally by students, they are allowed to book English 102 conditionally. Note: If the pre-requisite module has already been booked in previous sessions the selected module can be booked conditionally, if the conditional booking indicator is maintained in the additional data at the relationship between the modules. If the conditional booking indicator is not maintained, the module cannot be booked conditionally. 3.1 Automatic Conditional Booking If the system detects during the evaluation of extended booking checks that a module can be booked conditionally by a student, this module is booked with the conditional booking status: Automatic Conditional Booking. For example, the system assigns Automatic Conditional Booking to a module if the pre-requisite module has been booked in a previous year or session but was not completed. Module is booked by the student with status Automatic Conditional Booking.
Note: The user cannot manually set the Automatic Conditional Booking status during module booking.
3.2 Manual Conditional Booking If the system determines during the evaluation of extended booking checks that the module can be booked conditionally by the student, the user can set the conditional booking status: Manual Conditional Booking. The module is booked by the student with the status Manual Conditional Booking.
3.2.1. BAdI Implementations During the creation of sub-requirements you must choose the condition that applies. Use of Conditions for Sub-requirements
These conditions options are subject to a BAdI implementation. Users must create their own BAdI implementation for different checks or use existing conditions created for pre-requisite or co-requisite checks. Two sample BAdI implementations are provided: SAP8: Pre-requisite Condition. SAP9: Co-requisite Condition.
These conditions are samples. Users can create a new implementation for their business checks. Note: Users are requested not to use the conditions used for audits; you must create separate conditions for extended booking checks. 3.2.1.1. Sample Implementation: Condition SAP8 (Pre-requisite Condition) Condition SAP8 has been provided for pre-requisite check. This condition has the following two parameters: COMPLETED_SM_NUMBER: Number of modules that must be booked and completed out of specified modules. Note: If the value of this parameter is set to 00 then it is assumed that all the modules mentioned in the sub-requirement under the parameter MODULEID, must be completed for the sub-requirement to be fulfilled. MODULEID: Module ID of the pre-requisite module. Use of condition SAP8
Condition SAP8 can be also used for implementing an OR logic across the pre-requisite modules. You can copy the MODULEID parameter to include more pre-requisite modules under the same subrequirement. Accordingly, you can define the value of parameter COMPLETED_SM_NUMBER, which represents the number of modules that need to be booked and completed for the sub-requirement to be fulfilled. Use of the Condition SAP8 to Implement OR Logic across Pre-requisite Modules
The sub-requirement states that the student must book and complete at least one pre-requisite module to fulfill the sub-requirement. 3.2.1.2. Sample Implementation: Condition SAP9 (Co-requisite Condition) Condition SAP9 has been provided for co-requisite check. It has one parameter: MODULEID: Module ID of the co-requisite module.
Note: The Extended Pre-requisite Framework supports uni-directional co-requisites; bi-directional co-requisites are not supported. Users are requested not to create checks that have bi-directional co-requisites.
3.2.2 Creating new BAdI Implementations You must create new filters and conditions for setting up sub-requirements for extended booking checks. If you want to create a new index-independent sub-requirement you can either use existing conditions and filters for the extended booking check or create new conditions and filters. 3.2.2.1 Creating Conditions for Index-Independent Sub-requirements Creating conditions for extended booking checks is similar to creating conditions for audits. You must keep the following things in mind while implementing the Evaluate method to create conditions: You create a condition for the extended check as follows: 1. Make the settings in Customizing for Student Lifecycle Management: Processes in Student Lifecycle Management-> Module Booking-> Extended Booking Checks-> BAdI: Subrequirement Condition. The Business ADD_IN Builder screen for the BAdI Implementation is displayed 2. Choose Create to create a new condition and enter the implementation name. 3. Go to the Interface tab page and implement the EVALUATE method. EVALUATE Method of Interface IF_EX_HRPIQ00RLCONDITION
3.2.2.1.1 Implementing the EVALUATE Method Interface for EVALUATE Method
This method has the following import and changing parameters:
Import Parameters: IT_BOOKING: This parameter contains all academic work details of the student and also the modules added in the Booking Basket. IT_PARAMETERS: This parameter contains the parameter name and value pair that are used for the evaluation of the sub-requirement. This field contains all the parameters assigned to the condition. Additional parameter names and value pairs are provided in this field for evaluation: o MODULE_TO_BE_BOOKED: Object ID of the module that is currently being booked. o EVENT_PACKAGE_ID: Object ID of the Event package that is currently being booked. o ACAD_YEAR: Academic year for which the module is being booked. o ACAD_SESSION: Academic period for which the module is being booked. o PROGRAMTYPE: Program type You can make use of the following parameter names and value pairs for the check: IS_STUDENT: Object ID of the student. IV_STUDY_ID: ID of the study object. Changing Parameter: CV_RESULT: This changing parameter contains the result of the sub-requirement evaluation.
Fixed Value in this field The returned results of the sub-requirement are as follows: P: The sub-requirement condition has been fulfilled and the module can be booked as usual. For example, if the specified pre-requisite module is already booked and completed by the student, the method returns the value indicator P, which represents Fulfilled. U: The sub-requirement has not been fulfilled, but the module can be booked conditionally. For example, if the pre-requisite module has not been completed but the module has already been booked by the student in a previous year or session, the method returns with the value indicator U, which represents In Process. If the method returns with the U indicator, the module can be considered for conditional booking. N: The sub-requirement condition has not been fulfilled and the module cannot be booked. For example, if the pre-requisite module is neither booked nor completed then the method returns value indicator N, which represents Not Fulfilled. If the method returns the N indicator, the module cannot be considered for conditional booking.
3.2.2.1.2 Creating Filters for Index-Dependent Sub-requirements Creating filters for extended booking checks is similar to creating filters for audits. You create filters for the extended check as follows: 1. Make the settings in Customizing for Student Lifecycle Management, under Processes in Student Lifecycle Management-> Module Booking-> Extended Booking Checks> BAdI: Performance Index or Sub-requirement Filters. The Business ADD_IN Builder screen is displayed for BAdI Implementation. 2. Choose the Create button and enter the implementation name. 3. Go to the Interface tab page and implement the FILTER method. Interface for FILTER Method
Importing parameter: IT_ALL_BOOKING: This parameter contains all the academic work details of the student and also the modules added in the Booking Basket. CT_CALC_BOOKINGS: This changing parameter contains all the filtered bookings.
Changing parameter:
Note: You must ensure that you only need to consider the completed academic work while implementing the filter method.
4. Message Override Function

You can override error messages that are generated during evaluation of the extended booking check. This can take place at the module level once the entire extended booking check has been evaluated and a result has been returned stating whether the module can be booked as usual, conditionally or cannot be booked. Depending on this final result, the system generates a message that is displayed in the Module Booking: Message Log. You are authorized to override the overall booking result of the extended check and proceed with the normal booking. Once the entire extended booking check has been performed, the system displays the evaluation result in form of a message log listing all conditions that were not fulfilled. The booking check also shows whether the module can be conditionally booked, booked as normal or cannot be booked at all. The permission for overriding error messages can be maintained in the message control of the rule container.
Depending on the check result, the following actions are possible: If the extended booking check results state that all conditions were fulfilled, you can proceed to book the module. If the extended booking check results state that the module can only be booked conditionally or cannot be booked, the system displays an error message and the log of all the conditions that were not fulfilled in the Module Booking: Message Log.
Message Log
If conditional booking is allowed for the module, you can proceed to book the module conditionally using the Automatic Conditional Booking indicator. If you have overriding permission for the error message that was raised, you can book the module as usual using the No Conditional Booking indicator. If conditional booking is not allowed for the module and you do not have overriding permission, you cannot book the module.
4.1 Providing Override Permission for Messages You can allow overriding permission to a user as follows: 1. Execute transaction PP01. 2. Choose object type RC Rule Container from the dropdown list. 3. Enter the object ID for the rule container that relates to the specific module. 4. Create a new entry for the Message Control infotype. 5. On the Create Message Control screen, select the user name for which the overriding permission is to be given. Under the field Message Class enter the value HRPIQ00EXCHK. Enter the value 001 for the Message field and enter W in the Type field. 6. Choose Save.
5. Usage Guide
The following steps are required before the actual setup: 1. Analyze the checks that need to be set up for booking a module. 2. Convert the checks to a logical form that can be implemented using the extended booking check function. For example, before booking the module Science 200, the student must have completed both Math 201 and Math 202 OR they should have completed Stat 100. This could be converted to Science 200 = (Math 201 AND Math 202) OR Stat 100. This formula can easily be used to create the requirements and sub-requirements necessary to set up the module booking check. 3. Set the conditional booking OR enabling indicator as required for a condition. 4. Set up the message override function as required. 5.1 Examples The following examples demonstrate the extended booking check by showing the implementation of prerequisite conditions, but can also be used in the same way to set up co-requisite checks. Example 1: AND Operator across pre-requisite modules You must set the following check before a student is allowed to book hist.901. Requirement: The student must have completed all of the following modules: hist.902, hist.951, hist.952. You can navigate to the extended booking check maintenance screen in two ways: A. Run transaction PIQEXTCHECK. OR B. Go to the Module Catalog through transaction PIQ_ACCATLG or using the menu path on the SAP Easy Access screen. Click on the Edit Extended Booking Check pushbutton or right-click on the module entry.
Setting up the Condition 1. Create a requirement under hist.901
2. Fill in details of the requirement and save it.
3. Create an index-independent sub-requirement.
4. On the Create Sub-requirement screen, enter a description for the sub-requirement and select condition SAP8from the dropdown list and choose the Insert Condition button.
5. In the table, enter the value 01 for the parameter Number of Modules to Be Completed and in the parameter Module (Object ID) enter the module ID of one of the pre-requisite modules that have to be checked for completion. Save the sub-requirement.
6. Repeat steps 3-5 for the other modules that must be checked. In our example they are hist.902 and hist.951.The extended booking screen is displayed as below once the steps are performed:
The setup of the check is now complete. The changes become effective when a student tries to book module hist.901. Example 2: OR Operator across Pre-requisite Modules Requirement: The student must have completed any of the modules hist.902, hist.951, or hist.952 in order to be able to book hist.901. To achieve this, you must repeat all the steps in Example 1, and then perform the following additional step: Enable the OR indicator at the requirement level so that hist.901 can be booked if hist.902 OR hist.951 has been completed OR hist.952 has been completed.
The OR Indicator in Active Status
The setup of the check is now complete. The changes become effective when a student tries to book module hist.901. Example 3: AND Operator Across Multiple OR Groupings Requirement: To book module hist.901 the student must have completed: (hist.902 OR hist.903 OR hist.951) AND (hist.955 OR hist.956) 1. Go to the extended booking check maintenance screen for module hist.901 and create a requirement. Create one sub-requirement to implement (hist.902 OR hist.903 OR hist.951) and one sub-requirement (hist.955 OR hist.956). 2. To add multiple module IDs as parameters in the sub-requirement, you must copy the parameter by selecting the line and clicking on the Copy button as shown below:
3. In the same way, create the two sub-requirements:

SAP DEVELOPER NETWORK | sdn.sap.com 2009 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 18
The parameter Number of Modules to Be Completed remains as 01.This means that the sub-requirement is met if even one of the module has been completed by the student. With this the required condition is achieved.
Example 4: Take X Modules out of Y Choices
Create a check that requires a student to have taken 3 out of a set of 5 modules to book module hist.901. 1. Go to the extended booking check maintenance screen for the module hist.901 and create a requirement. 2. To implement the condition, enter the value of parameter Number of Modules to Be Completed as 3 and enter the module object IDs in the sub-requirement as shown below:
Example 5: X Earned Credits out of Y Modules Evaluation of index-dependent sub-requirements depends on the calculated value of performance indexes. Create a check where the following condition is checked: To book hist.901, the student must have taken modules from the module group Basic History Modules and should have earned 5 credits in total from the modules to satisfy the condition.
Most of the steps are the same as the earlier examples; the only difference is the creation of the subrequirement. For this check, we create an index-dependent sub-requirement. 1. In the sub-requirement, choose the tab Academic Work Selection and select the value SAP5 from the filter dropdown list. Insert it and enter the object ID of the module group.
SAP DEVELOPER NETWORK | sdn.sap.com 2009 SAP AG BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 20
2. Go to the Performance Indices tab and set up the condition as shown 3. Save the sub-requirement. The required condition has been fulfilled and is checked when the student tries to book hist.901.
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.

Student Lifecycle Management Extended Booking Check Cookbook

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Student Lifecycle Management Extended Booking Check Cookbook

Uploaded by

Copyright:

Available Formats

Student Lifecycle Management: Extended Booking Check

Student Lifecycle Management Development Team

Company: SAP AG Created on: January 2009

SAP DEVELOPER NETWORK | sdn.sap.com 2009 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 1