Admissions Cookbook for Pre- Configured Student Lifecycle

Admissions Cookbook for Pre-Configured Student Lifecycle Management

Applies to: This document applies to Student Lifecycle Management EHP 3

Summary This document explains how to set up a Program of study for which the admission process is valid properly. It describes how to make use of Admissions Scenarios, Admissions Audits, Online Applications, and Admissions Workflow Processing, all functionalities that are available in EHP 3.

Author: Michael Fan

Company: SAP AG

Created on: 05 May 2008

Author Bio Michael Fan is Solution Architect at the IBU for Higher Education and Research, SAP AG.

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


Table of Contents 1. Introduction .....................................................................................................................................................4 2. Glossary of Key Terms ...................................................................................................................................5 3. Basic Admissions Configuration .....................................................................................................................6

3.1 IMG Area: Student Lifecycle Management Student Lifecycle Management Processes Admission, Registration, and De-Registration...................................................................................................................6

3.1.1 IMG Path: Admission Set Up Admission Categories ......................................................................................6 3.1.2 IMG Path: Admission Set Up Program Choices .............................................................................................6

4. Admissions Audits ..........................................................................................................................................7 4.1 IMG Area: Student Lifecycle Management Student Lifecycle Management Processes Academic Records Assessments ...........................................................................................................................7

4.1.1 IMG Path: General Settings Define Assessment Categories..........................................................................7 4.1.2 IMG Path: General Settings Scheduled Assessments Set Session Group ................................................7 4.1.3 IMG Path: General Settings Scheduled Assessments Assign Session Groups to Audit Types .................7

4.2 IMG Area: Student Lifecycle Management Student Lifecycle Management Processes Audits ..8 4.2.1 IMG Path: Basic Settings Define Audit Types ................................................................................................8 4.2.2 IMG Path: Basic Settings Assign Callup Points to Audit Types ......................................................................8 4.2.3 IMG Path: Basic Settings Define Requirement Profile Types .........................................................................8 4.2.4 IMG Path: Basic Settings Define Execution Modes ........................................................................................8 4.2.5 IMG Path: Basic Settings Define Number Ranges for Rule Modules .............................................................8 4.2.6 IMG Path: Requirements Requirement Patterns Define (Abstract) Requirements.....................................9 4.2.7 IMG Path: Requirements Requirement Patterns Define Requirement Patterns.......................................10 4.2.8 IMG Path: Requirements Requirement Patterns Define Structure of Requirement Patterns ...................10 4.2.9 IMG Path: Requirements Requirement Patterns Define Requirement Selections....................................10 4.2.10 IMG Path: Requirements Requirement Patterns BADi: Requirement Selection.....................................10 4.2.11 IMG Path: Requirement Catalogs Define Version Statuses .......................................................................10 4.2.12 IMG Path: Requirement Catalogs Define Requirement Catalog Versions..................................................11 4.2.13 IMG Path: Requirement Catalogs Define Version Sets ..............................................................................11 4.2.14 IMG Path: Requirement Catalogs Define Structure of Version Sets...........................................................11 4.2.15 IMG Path: Requirement Catalogs Define Requirement Catalogs ...............................................................11 4.2.16 IMG Path: Requirement Catalogs Assign Requirement Patterns to Requirement Catalogs.......................12 4.2.17 IMG Path: Audit Runs Define Allowed Requirement Profile Types for Execution Modes ...........................12 4.2.18 IMG Path: Audit Runs Define Default Execution Mode for Audit Types......................................................12

5. Function Modules for ISR Action Box Processing........................................................................................13 6. Notifications ..................................................................................................................................................16

6.1 IMG Path: Notification Creation Notification Type Define Notification Types ................................16 6.2 IMG Path: Notification Creation Notification Type Define Number Ranges ..................................16 6.3 IMG Path: Notification Creation Notification Type Define Screen Templates Define Screen Areas and Tabs.............................................................................................................................................17 6.4 IMG Path: Notification Processing Task Definition Define Followup Functions for Tasks ............18 6.5 IMG Path: Notification Creation Notification Content Maintain Catalogs.......................................19 6.6 IMG Path: Notification Creation Notification Content Define Catalog Profiles...............................20 6.7 IMG Path: Notification Creation Notification Content Catalog and Catalog Profiles for Notification Type ..............................................................................................................................................................21 6.8 IMG Path: Notification Creation Partners Define Partner Determination Procedure.....................21



6.9 IMG Path: Notification Creation Overview of Notification Type..........................................................22 7. Scenarios......................................................................................................................................................23

7.1 Scenario Version Details.........................................................................................................................23 7.2 Scenario Characteristics .........................................................................................................................24 7.3 Action Box Tasks ....................................................................................................................................26

8. Workflow .......................................................................................................................................................29 8.1 Basic Workflow Customizing Settings.....................................................................................................29

8.1.1 IMG Path: SAP NetWeaver Application Server Business Management SAP Business Workflow Maintain Standard Settings ........................................................................................................................................29 8.1.2 IMG Path: SAP NetWeaver Application Server Business Management SAP Business Workflow Basic Settings Maintain Prefix Numbers................................................................................................................29

8.2 Workflow Template .................................................................................................................................29 8.3 Workflow Steps and Agents....................................................................................................................32 8.4 Workflow Container.................................................................................................................................33

8.4.1 Campus Notification Object PIQBUS7051 ........................................................................................................33 8.5 Linking Workflow to Notifications/Scenarios ...........................................................................................34 8.6 Workflow Processing Behavior and Related Customizing......................................................................38 8.7 Creating/Changing a Notification ............................................................................................................39

9. Admissions Correspondence........................................................................................................................40 9.1 Enrollment Confirmation Card.................................................................................................................40

9.1.1 Time Limit Configuration ...................................................................................................................................40 9.1.2 Use of the Form ................................................................................................................................................40

10. Admission Audit Conditions and Filters ......................................................................................................41 11. Admissions Application Status (and Missing Materials) Self-Service ........................................................42

11.1 System Configuration............................................................................................................................42 11.2 Web Dynpro Information .......................................................................................................................44

12. External Transcript Entry ............................................................................................................................46 12.1 External Transcript Configuration .........................................................................................................46 12.2 Quick-entry Web-based User Interface ................................................................................................47

A1. Appendix: Customizing the Admissions Process.......................................................................................49 A1.1 Setting up the Programs and Rules for Admissions Audits..................................................................49 A1.2 Copying and Extending the Scenario ...................................................................................................54 A1.3 Copying and Extending the Workflow...................................................................................................54

A1.3.1 Copying and Replacing Standard Workflow Tasks.........................................................................................54 A1.3.2 Inserting Steps to Call Action Box Items.........................................................................................................55

Copyright...........................................................................................................................................................56



1. Introduction The undergraduate admissions processing in the system is based upon specific Programs of Study. In other words, you do not technically admit students to a College or School; you admit them to a Program that is offered by the College or School. (e.g. Bachelor of Arts Program at the College of Liberal Arts) This cookbook explains how to set up this Program properly in order to make use of Admissions Scenarios, Admissions Audits, Online Applications, and Admissions Workflow Processing.

The scope of the configuration covered by this cookbook is for an admissions process that handles a single Admissions Record with a single Program of Study and a single choice of Major (specialization). There are also certain entries created for eventual handling of multiple Programs and multiple Majors, but they are not fully implemented at this time. Entry of the admissions application data is initially fully supported via a provided Remote Function Call (RFC), with a template Adobe form also available.

It is strongly recommended that you read this entire document and familiarize yourself with the content before attempting to customize the delivered processes to your institution. At the end of the document is an Appendix which describes the steps necessary to create and maintain your own customized admissions processes.

Please note that this represents a work-in-progress. Although this document represents a good-faith, best-effort to standardize and deliver configuration settings for SAP Student Lifecycle Management, it is subject to additions, changes, and deletions. This document does not represent the availability of additional delivered or supported functionality.



2. Glossary of Key Terms This document will make frequent reference to the following terms that carry specific meaning within the SAP Student Lifecycle Management Framework:

Notification A Notification is the object for modeling an individual application form

and its processing. For practical purposes, the term can be used interchangeably with ‘application’. For example, when an applicant submits an application for admissions, the system creates a ‘Notification’ with an identification number that can be used to retrieve and process that application data in the future.

Form The Form is the actual graphical representation of a ‘Notification’. This is the interface that is presented to an actual applicant. It can be implemented using a wide variety of technologies

ISR Scenario Each ‘Notification’ created in the system is done so in the context of an ISR Scenario (or ‘Scenario’). The Scenario defines a number of key attributes about the notifications created in its context. The specific data fields that are used by an admissions process are defined as ‘Characteristics’ of the Scenario. The tasks that can be executed for an admissions process are defined as ‘Action Box Tasks’ for the Scenario. A typical scenario is ‘Undergraduate Admissions’, which defines the data that is captured on the undergraduate application form, as well as data that is used internally by the University during the processing.

Action Box The Action Box is the library of tasks that can be performed for a ‘Notification’ of a given ‘Scenario’. The Action Box is displayed as a list of executable tasks when a ‘Notification’ is displayed via the SAP graphical user interface.

Applicant Record An Applicant Record is actually a Student Master Record in SAP Student Lifecycle Management. Once an ‘Admissions Record’ is created for a Student Master Record, the system automatically assigns a system status of ‘Applicant’ to the record.

Admissions Record The Admissions Record is not the same as the admissions application form (‘Notification’). The Admissions Record represents the official status of an applicant with respect to a particular Program of Study. Admissions Records are always specific to a Program of Study and an Academic Year/Session. An Admissions Record in a ‘Created’ status indicates that the admissions decision is still pending.

Workflow Template SAP Business Workflow is used to automate the admissions process. Each Workflow Template is linked to one or more ‘Scenarios’, and it defines the ‘Action Box Tasks’ that should be automated. The Workflow Template also defines other steps (such as manual decisions, courtesy notifications, etc.) that are not known to the ‘Scenario’.



3. Basic Admissions Configuration For basic processing of admissions through the Student File, the following IMG settings must be maintained, in addition to the settings previously described in the Base IMG Configuration Settings document. Most notably, please refer to Section 6 of the Base IMG Configuration Settings document. Section 6.1 describes the Transcript Categories that should be set up. For Undergraduate Admissions, it is highly recommended that different categories be set up to represent the high school that an applicant graduates from, aside from other miscellaneous high school transcripts. The assumption is that the graduating transcript is the one that carries the greatest significance when checking for application completeness and admissions criteria.

See Section 12 of this document for more details.

3.1 IMG Area: Student Lifecycle Management Student Lifecycle Management Processes Admission, Registration, and De-Registration

3.1.1 IMG Path: Admission Set Up Admission Categories

BC Set: ISHERCM_IAP_ADMISSION

Admissions Categories are intended for high-level reporting purposes, and should not be used to maintain very granular distinctions between admission types. For example, it is not necessary to attempt to capture all attributes (such as Resident/non-Resident, Full-time/Part-time, etc.) within this field. This field is meant to represent how the student was admitted; it is not meant to capture attributes about the actual student. Generally, these values should be items that otherwise would not appear on a student’s record, or would be convoluted to derive/discover.

Maintain the following entries:

U1 New UG, non-transfer X

U2 New UG, transfer U3 Returning UG, new degree U4 Current UG, program change U5 Current UG, addt'l program

3.1.2 IMG Path: Admission Set Up Program Choices

BC Set: ISHERCM_IAP_ADMISSION

Maintain the following entries:

1 1st choice 2 2nd choice 3 3rd choice



4. Admissions Audits Admissions Audits allow for a structured set of requirements that must be met prior to admitting an applicant. When a Program of study is set up for Admissions Audit, a successful Audit must be executed before an applicant can be admitted in the system. It is recommended that Admissions Audits be used for all but the most basic admissions processes, even if the only purpose is to verify application completeness (i.e. receipt of supporting materials aside from the application form itself).

Admissions audits require setup of Assessments and Audits within the IMG. Here we set up the framework for two different types of admissions audits. The first type checks for the basic admissions requirements (which will be separated into requirements for application completeness and minimum requirements for applicant admissibility). The second type of audit will be for the purpose of evaluating applicants that meet a higher standard for automatic acceptance.

Once the setup in this section is complete, it will be possible to create Admissions Audit Sub-requirements and assign them to the appropriate objects in the Academic Structure. These sub-requirements will then be assembled into a Requirement Profile for each applicant.

4.1 IMG Area: Student Lifecycle Management Student Lifecycle Management Processes Academic Records Assessments

An Assessment is an object in the system that represents the completion of a process. It is used to model graduation from an academic program, a final examination for a course, or a thesis defense, for example. The result of an assessment might be positive or negative. In the context of admissions, it is used to represent the evaluation of the final admissions requirements for an applicant before he/she can be admitted/denied.

4.1.1 IMG Path: General Settings Define Assessment Categories

BC Set: ISHERCM_IAP_ACAD_ASSESS

Create the following entry:

A1 Admissions Assessment

4.1.2 IMG Path: General Settings Scheduled Assessments Set Session Group


The assumption here is that admissions are performed on a term-by-term basis, where the terms are the same as the enrollment terms. (e.g. Your institution admits for the Fall and then the student registers for the Fall. You do not admit for the Fall and then register for the year, or vice versa.)


EXAM PERGROUP 1 Session Group for Assessments

4.1.3 IMG Path: General Settings Scheduled Assessments Assign Session Groups to Audit Types


This step must be completed after step 4.2.1. Create the following entries:

4000 1 4500 1



4.2 IMG Area: Student Lifecycle Management Student Lifecycle Management Processes Audits

4.2.1 IMG Path: Basic Settings Define Audit Types

BC Set: ISHERCM_IAP_AUDITS


4500 Admissions Auto-Admit

This Audit Type will be used to determine whether an individual should be automatically admitted to a program, without human intervention. The full use and configuration of Admissions Auto-Admit is not included with this cookbook version, but is described in the Appendix.

4.2.2 IMG Path: Basic Settings Assign Callup Points to Audit Types



4000 Completion of Process 1 0080

4.2.3 IMG Path: Basic Settings Define Requirement Profile Types


Create the following entries:

OFFI Official Profile X X SIMU Simulation Profile

4.2.4 IMG Path: Basic Settings Define Execution Modes



OFFI Official Audit X X SIMU Simulation Audit

4.2.5 IMG Path: Basic Settings Define Number Ranges for Rule Modules

Note: This step is not delivered via BC Sets.


02 20000000 29999999 0



4.2.6 IMG Path: Requirements Requirement Patterns Define (Abstract) Requirements

BC Set: ISHERCM_IAP_REQ_PATTERNS

An Abstract Requirement is best thought of as a kind of ‘requirement category’. Here we define the elements needed for a full admissions audit profile. The assumption is that there are General Requirements set at the Organization Unit Level (School, College, or even University-wide) for Undergraduate admissions. Each Program of Study may then have its own specific requirements. Finally, based upon the proposed Major, there may be yet additional requirements. The requirements themselves fall into three categories: application completeness, minimum admissions criteria, and automatic acceptance criteria.

The Requirement Selections described in section 4.2.9 must be defined prior to this step. Also, the Module Group Category of ‘MAJ’ (Undergraduate Major) described in Base IMG Configuration Settings section 5.5 must be configured.

4000 Overall Admissions Result Consolidation X

4100 Admissions Application Complete

Consolidation X

4105 General Completeness Requirements

Variable Requirement

X PIQCSSCO

4110 Program-specific Completeness


X SCRQ

4120 Major-specific Completeness Variable Requirement

X CGRQ X MAJ

4200 Admissions Minimum Criteria Consolidation X

4205 General Admissions Min.Criteria


X PIQCSSCO

4210 Program Admissions Min. Criteria


X SCRQ

4220 Major Admissions Min. Criteria


X CGRQ X MAJ

4500 Overall Auto-Admit Consolidation X

4505 General Auto-Admit Criteria Variable Requirement

X PIQCSSCO

4510 Program Auto-Admit Criteria Variable Requirement

X SCRQ

4520 Major Auto-Admit Criteria Variable Requirement

X CGRQ X MAJ

The Evaluation Path ‘PIQCSSCO’ is delivered. It is used to find Sub-requirement Rule Containers that are attached to any Organizational Unit that is ‘up the chain’ from the Program of Study. You can substitute other Evaluation Paths, if needed. Evaluation Paths used in this step have the following characteristics:

• They must always start with the Study (CS) object, not the Program of Study (SC) • The objects returned via the evaluation path will then be used to look for related Rule Containers

with the proper audit information (e.g. Audit type, Requirement) defined via the Relationship Additional Data. It is not necessary to actually include Rule Containers in the evaluation path.



4.2.7 IMG Path: Requirements Requirement Patterns Define Requirement Patterns



4000 UG Admissions Requirements 4500 Auto-Admit Criteria

4.2.8 IMG Path: Requirements Requirement Patterns Define Structure of Requirement Patterns



UG Admissions Requirements 10 Overall Admissions Result

UG Admissions Requirements 20 10 Admissions Application Complete

UG Admissions Requirements 21 20 General Completeness Requirements

UG Admissions Requirements 22 20 Program-specific Completeness

UG Admissions Requirements 23 20 Major-specific Completeness

UG Admissions Requirements 30 10 Admissions Minimum Criteria

UG Admissions Requirements 31 30 General Admissions Min. Criteria

UG Admissions Requirements 32 30 Program Admissions Min. Criteria

UG Admissions Requirements 33 30 Major Admissions Min. Criteria

Auto-Admit Criteria 50 Overall Auto-Admit

Auto-Admit Criteria 51 50 General Auto-Admit Criteria

Auto-Admit Criteria 52 50 Program Auto-Admit Criteria

Auto-Admit Criteria 53 50 Major Auto-Admit Criteria

4.2.9 IMG Path: Requirements Requirement Patterns Define Requirement Selections



CGRQ CG(ReqType-Specific) SCRQ SC(ReqType-Specific)

4.2.10 IMG Path: Requirements Requirement Patterns BADi: Requirement Selection

Ensure that the following implementations are active: • HRPIQ00_SCRQ : Selects Rule Containers (Sub-requirements) of a specific type from a specific

Program of Study • HRPIQ00_CGRQ : Selects Rule Containers (Sub-requirements) of a specific type from a specific

Specialization

4.2.11 IMG Path: Requirement Catalogs Define Version Statuses


01 Approved/Active X



4.2.12 IMG Path: Requirement Catalogs Define Requirement Catalog Versions


2004 Entry Year 2004-05 Approved/Active2005 Entry Year 2005-06 Approved/Active2006 Entry Year 2006-07 Approved/Active2007 Entry Year 2007-08 Approved/Active2008 Entry Year 2008-09 Approved/Active2009 Entry Year 2009-10 Approved/Active

You will need a version for each Academic Year. Each year, as you define the admissions requirements for the upcoming year, you should create a new version.

4.2.13 IMG Path: Requirement Catalogs Define Version Sets


10 Entry Year Versions

4.2.14 IMG Path: Requirement Catalogs Define Structure of Version Sets


Entry Year Versions 10 Entry Year 2004-05 Entry Year Versions 11 Entry Year 2005-06 Entry Year Versions 12 Entry Year 2006-07 Entry Year Versions 13 Entry Year 2007-08 XEntry Year Versions 14 Entry Year 2008-09 Entry Year Versions 15 Entry Year 2009-10

Each year, set the Default Version to be the upcoming Admissions Year.

Note: The last column indicates which Version is the Default. Set this to whatever the active upcoming Admissions year happens to be. You will change this setting every Academic Year.

4.2.15 IMG Path: Requirement Catalogs Define Requirement Catalogs


UGAD Undergraduate Admissions Entry Year Versions



4.2.16 IMG Path: Requirement Catalogs Assign Requirement Patterns to Requirement Catalogs

Here we set up the Requirement Catalogs for the next few admissions years. Create the following entries:

Undergraduate Admissions

Entry Year 2007-08

Admission Audit Completion of Process

UG Admissions Requirements


Entry Year 2007-08

Admissions Auto-Admit

Completion of Process

Auto-Admit Criteria


Entry Year 2008-09




Entry Year 2008-09



Auto-Admit Criteria


Entry Year 2009-10




Entry Year 2009-10



Auto-Admit Criteria

4.2.17 IMG Path: Audit Runs Define Allowed Requirement Profile Types for Execution Modes

BC Set: ISHERCM_IAP_AUDIT_RUNS


Official Audit Official Profile Simulation Audit Simulation Profile Simulation Audit Official Profile

4.2.18 IMG Path: Audit Runs Define Default Execution Mode for Audit Types

BC Set: ISHERCM_IAP_AUDIT_RUNS


4000 Completion of Process Official Audit Official Profile4500 Completion of Process Official Audit Official Profile



5. Function Modules for ISR Action Box Processing Tasks in the Action Box of a Scenario are always linked to a Function Module. The Function Module takes in a data structure from the Notification, and generally performs some or all of the following activities:

• Reads/compares data values stored in the Notification • Changes data values stored in the Notification • Creates/updates applicant (student) master data • Creates/updates admissions records for applicants

The following ISR-specific function module pairs are delivered and used in the Undergraduate Admissions scenario:

Function Module Description Comments HRIQ_ISR_STUDENT_CREATE_CAM Attempts to create a new student

record from the data in the notification; after the student is created, the notification data is updated with the student identifiers, and a relationship is created between the notification and the student; if any possible duplicate records are found, then no record is created; when run directly from the Action Box, the possible duplicates are presented to the user so that the user can decide if there is really a match.

The algorithm for determining possible duplicates is re-used from the Student Master Data transaction.

HRIQ_ISR_STCA_CREATE Forces the creation of a Contract Account for a student; normally this occurs asynchronously after the student master record is created; this function is necessary to ensure that the Contract Account exists prior to creating any admissions record that requires an admissions audit.

Admissions audits can make use of ‘inbound correspondence’ for handling missing documents, and a Contract Account is required for that purpose; without a Contract Account, the creation of the admissions record will fail.

HRIQ_ISR_STUDENT_USER_CREATE Creates a user ID for a student record and assigns that user as the ‘Initiated by’ user for the notification; if a user ID already exists for the student, then only the ‘Initiated by’ assignment is performed.

It is necessary to ensure that the IMG configuration is complete for generating user IDs from student records.

HRIQ_ISR_VISA_CREATE Creates/updates visa data for the student from the notification data.

HRIQ_ISR_UPDATE_EMP Creates/updates employment data for the student from the notification data.

HRIQ_ISR_STRELPERSON_CREATE Creates/updates related persons data for the student from the notification data.



HRIQ_ISR_ADM_APPLIC_CREATE Creates an admissions record for the student for the primary program of study.

The relevant scenario characteristic is ‘SC_OBJID’ in structure ‘PIQAPP_ADMISSION’.

HRIQ_ISR_MODULEGROUPS_BOOK Creates an academic specialization (module group) assignment for the program of study.

The relevant scenario characteristic is ‘CG_OBJID’ in structure ‘PIQAPP_MODGRP’.

HRIQ_ISR_UPDATE_ADDR Updates the address data on an already existing student from the notification data.

If no address data exists for the student, this function creates new data.

HRIQ_ISR_TRHEADER_CREATE Creates transcript headers for a student master record from the notification data.

HRIQ_ISR_FEE_WAIVED Changes the notification data to indicate that the admissions fee has been waived.

The scenario characteristic updated is ‘FEEWAIVED’ in structure ‘PIQAPP_ADDTL_ISR_DATA’.

HRIQ_ISR_FEE_MARKPAID Changes the notification data to indicate that the admissions fee has been paid.

The scenario characteristic updated is ‘FEEPAID’ in structure ‘PIQAPP_ADDTL_ISR_DATA’.

HRIQ_ISR_ADM_AUDFORM_RECREATE Re-generates an admissions audit profile for a student for a particular program of study and admissions period; any prior existing profiles for the same criteria are removed; this function will only run if no admissions audit run has occurred for the old profile.

This is necessary because a profile is first created automatically when the admissions record is created for a program. After that point, a major is usually assigned to the program. If the major has specific admissions requirements, they need to be included in the admissions audit profile (which previously had no information about the major).

HRIQ_ISR_ADM_APPLIC_APPROVE Changes the admissions status for the primary program of study to ‘1’ (accepted).

This function expects that there is only one admissions record created from the notification. If the ‘PROGRAM2’ characteristic is utilized to create an admissions record, this function module cannot be utilized.



HRIQ_ISR_ADM_APPLIC_REFUSE Changes the admissions status for the primary program of study to ‘5’ (rejected/withdrawn).

This function expects that there is only one admissions record created from the notification. If the ‘PROGRAM2’ characteristic is utilized to create an admissions record, this function module cannot be utilized.

HRIQ_ISR_STUDENT_CHANGE Provides GUI navigation to the Student Master Data record for the student.

This is meant to be performed directly from the Action Box; it has no relevance for automated workflow.

HRIQ_ISR_REPROCESSFLAG_CLEAR Changes the notification data to clear the field which indicates the notification should be re-processed through workflow.

The scenario characteristic updated is ‘REPROCESS’ in structure ‘PIQAPP_ADDTL_ISR_DATA’.

HRIQ_ISR_STUDENT_LINK Notification data is updated with the student identifiers, and a relationship is created between the notification and the student;

This is called from the workflow when it is determined that the notification data is a confirmed match for an existing student.

HRIQ_ISR_STUDENT_DUPE_VIEW Currently provides the same functionality as ‘HRIQ_ISR_STUDENT_CREATE_CAM’.

This function is provided as an alternate method for resolving duplicates, meant to be accessed solely from the Action Box.

HRIQ_ISR_AUDIT_ADMISSION Executes an admissions audit for the applicant.

After this function is called, it is possible to separately check the results of specific audit requirements and sub-requirements.

HRIQ_ISR_STUDENT_MASTER_VIEW Launches a session with the Student Master Data transaction in ‘view’ mode.

This is used during the workflow steps that help a user search to find a possible duplicate student record.



6. Notifications Notifications are the construct within SAP to allow for web-based requests and request processing. Admissions applications are treated as Notifications. Therefore, before any actual admissions application forms/submissions can be handled, it is necessary to set up Notifications. Otherwise, all processing of admissions and admissions audits must be handled via the Student File.

Before setting up any admissions-specific configuration for online applications, it is necessary to create a notification type that is appropriate for admissions. This is accomplished in the IMG under the path Cross-Application Components Notification.

6.1 IMG Path: Notification Creation Notification Type Define Notification Types

BC Set: ISHERCM_IAP_NOTIFICATION_TYPE


6.2 IMG Path: Notification Creation Notification Type Define Number Ranges

Note: This step is not available via BC Sets.

Use the ‘Change Groups’ icon to access number range group maintenance. In the menu, select Group Insert (F6). Create a group called ‘Student Lifecycle Management (CM)’ with the following range:

100000000000 199999999999 0

Assign the notification type element ‘CM’ to this range.



6.3 IMG Path: Notification Creation Notification Type Define Screen Templates Define Screen Areas and Tabs

Note: This step is not available via BC Sets.

Assign the following ‘Notification Header and Screen Areas’ to Notification Type ‘CM’:

Assign the following to ‘Simplified View: Screen Areas’:



Assign the following entry to ‘Extended View: Tabstrips and Screens’. This allows you to view the Notification data fields and values when you open a Notification in the Extended View:

6.4 IMG Path: Notification Processing Task Definition Define Followup Functions for Tasks


Define the following Follow-up Actions for Tasks:

CMNOTIFC 1 Task for the notification Change Notification CMUSERUD 1 Task for the notification Update Notification 'Initiated by' user



6.5 IMG Path: Notification Creation Notification Content Maintain Catalogs


Choose ‘Edit Catalogs’. Select Catalog ‘2’, with Code Group ‘*’. Press ‘Enter’. On the subsequent ‘Code Groups’ screen, create a new code group:

CM-ADM Campus Management Admissions Released

Create the following codes for the new Code Group. Each Code represents a task that might be performed as part of the admissions processing. Each Code will be linked to a follow-up action, as defined previously.

ADC1 Create Admissions Record for Program 1 CMNOTIFC

ADH1 Create Conditional Holds for Program 1 CMNOTIFC

ADM1 Conditionally Accept to Program 1 CMNOTIFC

ADN1 Reject Applicant from Program 1 CMNOTIFC

ADR1 Calculate Overall Admissions Rating 1 CMNOTIFC

ADUP Update Address Data for Applicant CMNOTIFC

ADY1 Admit Applicant to Program 1 CMNOTIFC

AUA1 Evaluate Auto-Admit for Program 1 CMNOTIFC

AUD1 Perform Admissions Audit for Program 1 CMNOTIFC

CACR Create Contract Account for Applicant CMNOTIFC

AUC1 Check for Application Completeness CMNOTIFC

DUPE Duplicate Record Check CMNOTIFC

EMCR Add Employment Data to Applicant CMNOTIFC

FEEM Mark application fee as paid CMNOTIFC

FEEP Post Application Fee CMNOTIFC

FEEW Waive application fee CMNOTIFC

MAJ1 Add Major to Program 1 CMNOTIFC

NPR1 Re-generate Audit Profile for Program 1 CMNOTIFC

RPCR Add Related Persons to Applicant CMNOTIFC

STCR Create New Applicant Record CMNOTIFC



STLK Link Student to Application CMNOTIFC

STRC Goto Student Record CMNOTIFC

TRHC Create Transcript Header for Applicant CMNOTIFC

USCR Create User ID for Applicant CMUSERUD

VSCR Add Visa Data to Applicant CMNOTIFC

6.6 IMG Path: Notification Creation Notification Content Define Catalog Profiles

BC Set: ISHERCM_IAP_NOTIFICATION_CONTENT

Create the following new entry:

Assign the following ‘Catalogs / code groups’:

2 CM-ADM



6.7 IMG Path: Notification Creation Notification Content Catalog and Catalog Profiles for Notification Type


Assign the following to the Notification Type ‘CM’:

6.8 IMG Path: Notification Creation Partners Define Partner Determination Procedure




Assign the Partner Determination Procedure to the Notification Type ‘CM’

6.9 IMG Path: Notification Creation Overview of Notification Type


Here, you can view the overall setup of the Notification Type ‘CM’, and make the following additional setting.



7. Scenarios The Scenario defines how admissions data is captured, presented, and processed for different academic programs. In this example, we set up an Undergraduate admissions scenario which allows the applicant to apply to a single program with a single application form. This is accomplished in the IMG under the path Cross-Application Components Internet/Intranet Services Internal Service Request (ISR) Scenario Definition.

BC Set: ISHERCM_IAP_SCENARIOS

7.1 Scenario Version Details

The following Scenario/Version is delivered via the BC Set:

Note: The ‘Entry Type in Web’ field is set to ‘Entry Using ITS Service’. The purpose of this setting is so that backend admissions processors can easily view the application form data from the standard notification processing screens. It is intended that the actual admissions applications will be created and entered via an Adobe Interactive Form or a Web Dynpro application.



7.2 Scenario Characteristics

Each Characteristic refers to a Structure Data Type in the Data Dictionary. Each structure has one or more components. Each component must have a unique field name across all of the structures referenced in a Scenario. Create the following Characteristics for the Scenario Version:

1 PERSONAL_DATA Dictionary

Type PIQAPP_PERSONAL Personal Data

2 ADDITIONAL_PERSONAL_DATA Dictionary Type

PIQAPP_ADDPERSONAL Additional Personal Data

3 RESIDENCY_DATA Dictionary Type

PIQAPP_RESIDENCY Residency Data

4 ACADEMIC_PROGRAM_DATA Dictionary Type

PIQAPP_ADMISSION Academic Program Data

5 CAMPUS_DATA Dictionary Type

PIQAPP_CAMPUS Campus Data

6 IND_STUDY_DATA Dictionary Type

PIQAPP_STUDYDATA Individual Study Data

7 MAJOR_DATA Dictionary Type

PIQAPP_MODGRP Intended Major Data

8 TRANSCRIPT_DATA Dictionary Type

PIQAPP_TRHEADER Transcript Header Data

9 VISA_DATA Dictionary Type

PIQAPP_VISA Visa Data

10 TEST_SCORE_DATA Dictionary Type

PIQAPP_TRTESTRESULTS Test Score Data

11 PHONE_DATA Dictionary Type

PIQAPP_ADTEL Phone Contact Data

12 ADDRESS_USAGE_DATA Dictionary Type

PIQAPP_ADDRESSUSAGE Address Usage Data

13 ADDRESS_DATA Dictionary Type

PIQAPP_ADDRESSZAV Address Data

14 EMAIL_DATA Dictionary Type

PIQAPP_ADSMTP E-mail Data

15 RELATED_PERSON_DATA Dictionary Type

PIQAPP_RELPERSON Related Person Data

16 RELATED_PERSON_ADDRESS_DATA Dictionary Type

PIQAPP_RELPADDR Related Person Address Data

17 RELATED_PERSON_PHONE_DATA Dictionary Type

PIQAPP_RELPADTEL Related Person Phone Data

18 RELATED_PERSON_EMAIL_DATA Dictionary Type

PIQAPP_RELPADSMTP Related Person E-Mail Data

19 ADDITIONAL_ADMISSIONS_DATA Dictionary Type

PIQAPP_ADDTL_ISR_DATA Additional Admissions Data

20 RELATED_ALUMNI_DATA Dictionary Type

PIQAPP_RELATED_ALUMNI_DATA

Related Alumni Data

21 STUDENT_DATA Dictionary Type

PIQAPP_STUDENT Student Data

22 EMPLOYMENT_DATA Dictionary Type

PIQAPP_EMPLOYMENT_DATA Employment Data



You will need to create each one individually, as shown in the screenshot:

Note: The Structure ‘PIQAPP_ADDTL_ISR_DATA’ is delivered in manner that allows each customer to create an ‘Append Structure’ for it. This is the mechanism for adding additional data fields to the scenario. Alternatively, a new custom structure can be created to handle the additional fields. Please refer to the Appendix for details.



7.3 Action Box Tasks

Each Scenario has certain actions that can be performed, either by the end user or by automated workflow. These actions must each be defined in the Action Box for the Scenario. When the Action Box maintenance screen appears, all actions are displayed for all Scenarios. The actions for which there is no entry in the ‘Scenario’ column are applicable to all Scenarios. Others may be Scenario-specific. To create an entry, they following screen must be filled out, as an example:



The following table summarizes the information that should be created for each action. Aside from the Sort number, the Control data will be identical for each action. The Code Group will always be ‘CM-ADM’, and the Quick Info for the User Interface will always match the Function Text:

Function Function Text Sort Function Module Code Icon UGA1 Create New

Student Record 10 HRIQ_ISR_STUDENT_CRE

ATE_CAM STCR ICON_INCOMING_EMPLO

YEE UGA2 Create

Contract Account for ST

20 HRIQ_ISR_STCA_CREATE CACR ICON_CONVERT

UGA3 Create User ID for Student

30 HRIQ_ISR_STUDENT_USER_CREATE

USCR ICON_CREATE_POSITION

UGA4 Add Visa Data to Student

40 HRIQ_ISR_VISA_CREATE VSCR ICON_INCOMING_TASK

UGA5 Add Employment Data to Student

50 HRIQ_ISR_UPDATE_EMP EMCR ICON_INCOMING_TASK

UGA6 Add Related Persons to Student

60 HRIQ_ISR_STRELPERSON_CREATE

RPCR ICON_PARTNER

UGA7 Post Application Fee

70 <See Note> FEEP

ICON_PROFIT_CENTER

UGA8 Create Admission for Program 1

80 HRIQ_ISR_ADM_APPLIC_CREATE

ADC1 ICON_CREATE

UGAA Add Major to Program 1

100 HRIQ_ISR_MODULEGROUPS_BOOK

MAJ1 ICON_INSERT_ROW

UGAC Update Student Address

15 HRIQ_ISR_UPDATE_ADDR ADUP ICON_CHANGE_NUMBER

UGAD Add Transcript Headers

65 HRIQ_ISR_TRHEADER_CREATE

TRHC ICON_JUSTIFIED

UGAE Waive Application Fee

71 HRIQ_ISR_FEE_WAIVED FEEW ICON_TE_DEDUCTION

UGAF Mark Fee as Paid

72 HRIQ_ISR_FEE_MARKPAID FEEM ICON_PROPOSITION

UGAG Re-generate Audit Profile for Program 1

111 HRIQ_ISR_ADM_AUDFORM_RECREATE

NPR1 ICON_MODIFY

UGAH Admit to Program 1

117 HRIQ_ISR_ADM_APPLIC_APPROVE

ADY1 ICON_ALLOW

UGAI Reject from Program 1

120 HRIQ_ISR_ADM_APPLIC_REFUSE

ADN1 ICON_REJECT

UGAJ Goto Applicant Record

5 HRIQ_ISR_STUDENT_CHANGE

STRC ICON_OBJECT_FOLDER

UGAK Re-set Reprocessing flag

3 HRIQ_ISR_REPROCESSFLAG_CLEAR

RSRP ICON_ACTIVE_INACTIVE

UGAL Link Student to Application

7 HRIQ_ISR_STUDENT_LINK STLK ICON_CONNECT

UGAM Duplicate Record Check

1 HRIQ_ISR_STUDENT_DUPE_VIEW

DUPE ICON_EMPLOYEE



UGAN Perform Admissions Audit for Program 1

115 HRIQ_ISR_AUDIT_ADMISSION

AUD1 ICON_CHECK

UGAO Search Student Master Records

2 HRIQ_ISR_STUDENTMASTER_SEARCH

STMV ICON_SEARCH

Note: Function ‘UGA7’ is a placeholder, as no Function Module is assigned to it. The posting of admissions fees can be handled in a variety of mechanisms. One possible mechanism is to post the fee to the Student’s account, and then process payment via Biller Direct. A few simple FI-CA function modules may be utilized to perform this, once the determination of certain Contract Accounting and General Ledger settings has been made. The function module needs to be ‘wrapped’ as described in the Appendix. The key function modules to call are:

PMIQ_BUPA_READ_ST_ACCOUNT_DATA Gets the Contract Account data for a Student CMAC_ST_ACCT_DATA_READ_OPTION Gets the Contract Object number for a

specific Contract Object Type BAPI_CTRACDOCUMENT_CREATE Creates the Fee Posting to a Specific

Contract Object

Note: Function ‘UGAO’ must be also be made available in ‘Display’ mode, where other functions are only needed in ‘Change’ mode. This Function is used to launch the Student Master Display transaction (PIQSTD). When a possible duplicate is detected, the workflow process described in Section 8 takes the duplicate processor to the ‘Extended View’ display mode of the Notification. Here, it is useful to have the Action Box item to search for matching students. Note that the Control Data for this function differs from the other functions defined. Most notably, the Documentation must be set to ‘None’, or it will not appear in the Action Box in ‘display’ mode.



8. Workflow Admissions processing is handled via SAP Workflow. In order to process admissions via workflow, certain basic workflow settings must first be made in the IMG.

8.1 Basic Workflow Customizing Settings

8.1.1 IMG Path: SAP NetWeaver Application Server Business Management SAP Business Workflow Maintain Standard Settings

Simple Execute this step and review the log for errors that must be manually corrected. This step should be executed by a user with high authority levels to minimize errors.

8.1.2 IMG Path: SAP NetWeaver Application Server Business Management SAP Business Workflow Basic Settings Maintain Prefix Numbers

Create a prefix number for newly-created workflow objects in your System and Client. You will need this for copying and adjusting delivered workflows.

8.2 Workflow Template

Admissions processing handled via a Workflow template. The delivered template is called ‘HRIQ_ADM_UG’. Before making any adjustments to the workflow process, be sure to copy this template to a Workflow Template (as described in the Appendix) in the customer namespace. The delivered Workflow Template includes the following flow:







8.3 Workflow Steps and Agents

Although most of the workflow steps are executed automatically by the system, there are a number of workflow steps within the delivered template that are designed to be routed to users or ‘agents’ for interactive processing. The delivered tasks are routed according to ‘Work Centers’. A Work Center is an HR Object that is used to group individuals, positions, and organizations working on a common task. The Work Centers themselves are not delivered with the system, but can easily and quickly be created and assigned using transaction ‘PO01’. Simply create a Work Center (such as ‘Admissions Processing’) and create a ‘Holder’ relationship between the Work Center and the Users who will perform the work. Although you can also perform work item assignment using other HR objects, such as ‘Position’, the ‘Work Center’ is especially convenient when you have not yet fully configured Human Capital Management in SAP. It is also not as rigid as using direct User ID agent assignment within the workflow steps. The following workflow steps in the delivered template require Agent Assignments:

Step Number Description 287 Display Application for Duplicate 325 Confirm/Deny Possible Duplicate 332 Enter Duplicate Student ID Number 367 Confirm automatic rejection 382 Admissions decision for applicant

Step 431 is a special ‘dummy’ step that is inserted for the sole purpose of introducing a delay in the processing. This step has no agent assigned, and therefore cannot be completed. The deadline monitoring on the work item will trigger the continuation of the workflow. This delay is necessary for the ‘loop’ processing in ‘Admissions Completion’ portion of the workflow, as it makes no sense to re-evaluate the completion conditions (such as ‘Transcript received’) until a reasonable amount of time has passed. The setting in the delivered step is for a 1 day delay between checks.



8.4 Workflow Container

The Workflow Container contains data that is persistent across multiple Workflow Steps. The key Container Element is based upon the General Notification object. However, that object itself has a Sub-Type called ‘PIQBUS7051’. This additional object type includes additional data (such as Student Number) that is useful for the workflow. In addition to the standard container elements that are included with every workflow, the following workflow container elements are included:

• Application – This represents the unique application form/data that is associated with each admissions process. It is based upon the delivered business object type ‘General Notification’ (BUS7051).

• Student Numbers – This element is based on the data structure ‘PIQAPP_STUDENT’. It is used primarily for the duplicate resolution process. It is not intended to be consistently populated with all of the relevant student data. The persistent student data is stored in the Notification itself.

• ActivityResult – This element is used to store return codes from Business APIs. It is available for customer-specific error-handling, but not actively used in the delivered workflow template.

• DuplicateFlag – This ‘Flag’ type container element is filled with an ‘X’ if it is determined (by the system or by the admissions processor) that the notification data entered should be attributed to an already existing student record.

8.4.1 Campus Notification Object PIQBUS7051

The processing of the Notification via Workflow relies on a new Business Object Type ‘PIQBUS7051’. This is a sub-type of Business Object Type ‘BUS7051’. Objects of type PIQBUS7051 contain all the methods, attributes, etc. of type BUS7051, along with other attributes and methods that are necessary for the admissions processing. In order to make use of the new methods and attributes, it is necessary to perform the appropriate object type delegation:

In transaction ‘SWO1’ (Business Object Builder), enter Object Type ‘BUS7051’. Then, in the menu, select ‘Settings -> Delegate). Create a new entry with the following fields (set the Person Responsible to your user ID):



8.5 Linking Workflow to Notifications/Scenarios

The Workflow Template simply defines the actions that should be performed automatically by the system, along with required approval tasks. However, each admissions Scenario and it Notification Creation must be linked to a Workflow Template.

This is done via transaction ‘SWETYPV’. Make sure you are in ‘Change’ mode, and create the following entries that link the Notification BOR Object (BUS7051) to your Workflow Template:





The checkboxes for ‘Enable Event Queue’ are used when you anticipate high-volumes of applications to be created over a short time frame. When this is unchecked, each application creation will trigger a workflow task immediately. When it is checked, the event is placed in a queue, which is periodically evaluated via a background job. The job will process items out of the queue in small bundles to manage the load. However, in this case, there will always be a delay from when an application is submitted until it is evaluated by a workflow.

The ‘Check Function Module’ is using ‘SWB_CHECK_FB_START_COND_EVAL’. This means that the assigned Workflow Template will not be triggered for all notifications, but only for those that meet a defined Start Condition. This allows you to have different workflow templates for different admissions Scenarios.

First, make sure that the Event Creator is activated in the ‘Triggering Events’ tab within your Workflow Template (transaction ‘PFTC_CHG’).

You need to set the Start Condition for the workflow template using transaction ‘SWB_COND’. Make sure you enter ‘Create’ mode. Create Start Conditions for your Workflow Template. You will need to create Start Conditions for the ‘Create’ event and ‘Back in Processing’ event. Check for the right Scenario.



Upon completion, you should have the following Start Conditions defined:



8.6 Workflow Processing Behavior and Related Customizing

The delivered Workflow Template is designed with the following attributes which are integral to the proper processing of admissions:

• Submitted Flag – The notification being processed must have a characteristic called ‘SUBMITTED’. This has been delivered as part of the structure ‘PIQAPP_ADDTL_ISR_DATA’. If this flag is not set to ‘X’, then the workflow will bypass all meaningful steps. This capability allows applicants to save a partially-completed application form. A report can be written to extract data from ‘non-submitted’ application forms for follow-up purposes.

• Reprocess Flag - The notification being processed must have a characteristic called ‘REPROCESS’. This has been delivered as part of the structure ‘PIQAPP_ADDTL_ISR_DATA’. When the data for a notification is changed, the workflow will only re-trigger if this flag is set to ‘X’. Therefore, when an applicant re-opens a previously saved application form and submits it, this flag should always be set. The workflow then be triggered and will re-set this flag as its first execution step. Note that the delivered RFC (see section 8.7) for creating the notification is not the same one you will need to call during a re-submission. Here, a separate RFC needs to be defined. Also, an RFC should be defined to retrieve the data from a previous notification.

• Academic Specialization Combinations – Workflow step 190 adds academic specializations to the applicant’s admissions record. In order for this step to be successful, valid Academic Specialization Combinations must be maintained for each Program of Study via the Program Catalog.

• ‘ADMA’ Time Limit – Workflow step 401 checks to see if the admissions deadline has passed. This is done via a check for a specific time limit in the academic calendar for the relevant program of study. Time limit ‘ADMA’ must be defined.

• ‘Admissions Application Complete’ Abstract Requirement – Workflow step 201 is a processing loop that continues until the application materials have all been submitted by the applicant. This is achieved by verifying the result of a specific Admissions Audit requirement (4100 – Admissions Application Complete).



8.7 Creating/Changing a Notification

An RFC is provided in order to simplify the creation of a new application. The RFC is called ‘HRIQ_SCM1_NOTIF_CREATE_RFC’. This RFC may be triggered from any number of form technologies, including Adobe Interactive Forms, Business Server Pages, and Web Dynpro applications. The RFC can also be triggered via a batch process or interface program, which may be desirable in many cases.

The direct creation of a notification by an applicant requires one of two scenarios:

• The applicant needs a user ID in the back-end Student Lifecycle Management system. • The RFC is called using a generic user ID or an ‘open’ web service, with no authentication required.

Neither case is ideal. For security purposes, it is not generally recommended to create an open channel directly to the back-end system. Also, you generally would not want to create a User ID for each applicant before they even fill out an application.

Therefore, it may make sense to call the back-end RFC indirectly via one of the following mechanisms:

• The online form passes its data to a ‘staging’ server in the DMZ. That server then makes a synchronous call to the back-end RFC through a firewall, which allows a notification number to be immediately communicated to the applicant.

• An Adobe Form utilizes the ‘submit via e-mail’ capability to generate an XML data file which is then received at a designated e-mail address which auto-replies a confirmation of receipt. The XML files are subsequently processes in batch, and notification numbers are e-mailed to the applicants.

• The online form saves data to a separate database (or to local files) on a ‘staging’ server in the DMZ. A separate process periodically pulls this data to call the back-end RFC.

Delivered with CMIAP Support Package 2 are two additional RFCs:

• HRIQ_SCM1_NOTIF_READ_RFC – This RFC retrieves the data from a previously created notification

• HRIQ_SCM1_NOTIF_CHANGE_RFC – This RFC updates an existing notification with the data passed to it.

Note: When you wish to allow a user or applicant to update an existing application form, you must call both the ‘READ’ RFC and the ‘CHANGE’ RFC. If you simply call the ‘CHANGE’ RFC and pass it the changed values, then you will also be updating all of the unchanged fields with initial values! You must pass the unchanged field results of the ‘READ’ RFC back into the ‘CHANGE’ RFC.



9. Admissions Correspondence To generate an admissions-related correspondence for a student (or a group of students), use the transaction ‘PIQCORADMC’ (Generate Admissions Correspondence). The Selection Method ADM2 will provide you with flexible admissions-specific selection fields for identifying students.

9.1 Enrollment Confirmation Card

The Enrollment Confirmation Card is a piece of Admissions Correspondence that allows a student to confirm that he/she is planning to enroll in your institution. Pre-printed on the Enrollment Confirmation Card is information such as the Organizational Unit, the Program of Study, the Student Identification Data, and the deadline for responding.

9.1.1 Time Limit Configuration

BC Set: ISHERCM_IAP_CORR_TIMELIMIT

This relies on having a Time Limit defined in your Academic Calendar. This Time Limit is used to indicate the deadline you wish to print on your Enrollment Confirmation Card correspondence. You can define an appropriate Time Limit via the IMG path Student Lifecycle Management Student Lifecycle Management Master Data Academic Calendars Define Time Limits.

ECNF Enrollment Confirmation Deadline

BC Set: ISHERCM_IAP_ENROLL_CONFIRM

Once you have created this Time Limit, you need to assign it as the Enrollment Confirmation Time Limit. This is done via the Transaction ‘SIMGH’. Here, you need to access the IMG Structure called ‘Student Lifecycle Management IAP’. Here, the path Enrollment Confirmation Create Time Limit for Enrollment Confirmation Fee allows you to set the value to the Time Limit you previously defined.

ACADCAL CONF_DATE ECNF

9.1.2 Use of the Form

The delivered Application Form for Enrollment Confirmation is ‘ISHERCM_SAMPLE_ADMISSION_CARD’. It is an Adobe PDF form that can be copied and edited via transaction ‘EFRM’. To make changes, you should first copy the Form, making changes only to the copy.



10. Admission Audit Conditions and Filters An important part of the admissions process is the admissions audit. The admissions audit allows you to define criteria that must be evaluated before an application can be considered complete, or before an admissions candidate can be considered acceptable. Examples of audit criteria are:

• the applicant must have submitted an official SAT test result • the applicant must have paid an application fee • the applicant must have a minimum high school GPA of 2.5

Each audit rule (Subrequirement) is based upon a Subrequirement Condition and one or more Filter values. Conditions and Filters for Subrequirements are defined via BADi implementations in the IMG path Student Lifecycle Management Student Lifecycle Management Processes Audits Requirements Subrequirements. The following useful Subrequirement Conditions (and filters) are delivered as part of the IAP Add-on. Mandatory filter parameters are in italics.

Condition Filter parameters Description SAP3 Credits,

Operand (EQ, GT, LT, GE, LE), Transcript Category, Transcript Status

Verifies that an External Transcript for the applicant has the requisite number of overall credits. Therefore, if you are trying to verify that the applicant has at least (greater than or equal to) 20 credits from a final high school transcript, set the CREDITS = 20, OPERAND = GE, TRNSCRT_CATEGORY = HS, and TRNSCRT_STATUS = FIN.

SAP4 Rank, Operand (EQ, GT, LT, GE, LE), Transcript Category, Transcript Status

Verifies that the applicant’s class rank form the external transcript is sufficient. The comparison can either be performed against the ‘absolute rank’ or the ‘percentage rank’. The default behavior is to use ‘absolute ranking’. However, if you wish the system to use ‘percentile ranking, then you must make an entry in customizing switch table ‘V_T7PIQSWITCHVALUE’ (via transaction ‘SM31’). Here you set the value of TRANSCRIPT-PROC_RANK to ‘X’.

SAP5 External Average, Calculation Point, Grading Scale, Operand (EQ, GT, LT, GE, LE), Transcript Category, Transcript Status

Verifies that the applicant’s external transcript GPA is sufficient. Here, the parameter ‘Calculation Point’ is used to indicate which external GPA type you wish to compare against. The supported calculation points are ‘TR01’, ‘TR02’, and ‘TR03’. Please refer to section 12.1 to ensure that you have properly configured the calculation points for external transcripts.

SAP6 Test Type, Subtest, Score, Operand (EQ, GT, LT, GE, LE)

Verifies that the applicant has an external test result with a particular score. If the Operand parameter is not filled in, then the system just checks for the existence of a test result, not for a specific score. Also, only test results that are classified as ‘official’ are considered.

SAP7 Characteristic, Characteristic Value, Operand (EQ, GT, LT, GE, LE)

Verifies that a Characteristic in the applicant’s Notification is a particular value. For example, to check that the Application Fee has been paid, use CHARACTERISTICS = FEEPAID, CHARACTERISTICS VALUE = X, OPERAND = EQ.



11. Admissions Application Status (and Missing Materials) Self-Service A Web Dynpro application is delivered which allows applicants to view the status of their admissions applications. An additional Web Dynpro application is provided which shows the applicant whether or not all of the required admissions materials have been received by the institution. The ‘missing materials’ portion of the self-service application is based upon the use of Admissions Audits.

The Web Dynpros can also be deployed such that an admissions officer could use the web applications to check on missing requirements for applicants through an admission officer portal role.

11.1 System Configuration

Prior to using the Web Dynpro application, it is necessary to make certain configuration settings that control the behavior.

Student Lifecycle Management Role-Based Web UI Cross Role Settings Maintain Profile Views for Admissions Audit.

Define Profile Views:

APPL Applicant View ADMO Admissions Officer View

Assign Requirements to Profile Views:

APPL Applicant View 4100 Admissions Application

Completeness X 4000 UG Admissions

Requirements ADMO Admissions Officer

View 4000 Overall Admissions Result X 4000 UG Admissions

Requirements



When you set up your Audit Subrequirements via your Requirement Catalog or via your Requirement Templates, you need to specify which subrequirements should appear to users in the ‘missing materials’ Web Dynpro. This is done by setting the checkbox called ‘Reminder’ for the relevant Rule Container. If the checkbox is not checked, then the subrequirements of the Rule Container will not appear in the Web Dynpro view of the audit results. Note that the setting of the ‘reminder’ flag is global for all Profile Views. That means that you cannot use this flag to decide whether a requirement is shown to only the admissions officer but not to the applicant.

In the figure above, you can see how to turn on the ‘Reminder’ flag for a selected Rule Container in a Requirement Catalog.



11.2 Web Dynpro Information

The provided Web Dynpro component for viewing a student’s admissions application data via a browser is ‘PIQ_ST_ADMAPPLICATION’. The Web Dynpro application within the component is named ‘piqib_st_admapplication’. When this Web Dynpro is run by a user with a Student/Applicant record attached, the applicant’s admissions application(s) will appear. The applicant can then expand each entry to view specific data fields from the notification itself.

The applicant can directly navigate to the ‘Admission Audit’ Web Dynpro from here. The Web Dynpro Component is named ‘PIQ_ST_ADMAUDIT’. The Web Dynpro application is named ‘piq_st_admaudit’. The application has a Parameter called ‘PRFVIEW’ that should be set to ‘APPL’ (as described in step 11.1) for Student Self-Service usage. If you wish to deploy a separate version for an admissions officer, then you need to create an additional application with the Parameter ‘PRFVIEW’ set to ‘ADMO’. Alternatively, you can just pass the appropriate view name via the URL you use to launch the application (by adding PRFVIEW=APPL, for example).

Two different configurations for the application are provided: ‘PIQAC_ADM_AUDIT_FULL’ and ‘PIQAC_ADM_AUDIT_RESTRICTED’. Through the Web Dynpro Configurator, you can hide certain fields from the ‘restricted’ view if desired.



Below is a sample view of the Web Dynpro screen:



12. External Transcript Entry

12.1 External Transcript Configuration BC Set: ISHERCM_IAP_EXT_TRANS

Please make the following basic settings for external transcripts:

IMG Path: Student Lifecycle Management Student Lifecycle Management Master Data Educational Background External Academic Work External Transcripts

Set Up Transcript Categories:

HS High School (grad.) Highest StatusHS2 High School (other) Highest StatusUG Undergraduate Highest Status

Set Up Transcript Statuses:

FIN Final/Official 10 X PREL Preliminary 5 SELF Self-reported 2 UNK Unknown 1

Create New Descriptions for Averages:

AVGGRADE01 Manually entered GPA

In order to handle GPA calculations for External Transcripts, the following customizing is required:

IMG Path: Student Lifecycle Management Student Lifecycle Management Master Data Performance Indices Average Grades for External Academic Work

BADi: Average Grade Calculation:

Ensure that the implementation ‘GTR1’ is Active.

Combine Calculation Points with Average Grade Calculations:

TR01 Ext. Transcript:

Calculated Average 1 01/01/1950 12/31/9999 GTR1 Average Based on

Grades in Transcript GPA GPA



12.2 Quick-entry Web-based User Interface

A Web Dynpro application is provided to allow an admissions officer or other administrative user to quickly and easily add transcript data to a student record. Data can added or changed for an existing transcript (even when there is only a header, such as might be created by the admissions processing workflow), or data can be created for an entirely new transcript. The Web Dynpro component is ‘PIQ_MAINTAIN_TRANSCRIPT’. The Web Dynpro application is ‘piq_maintain_transcript’. A sample screen appears below:



When entering the ‘Subjects’ information for an external transcript via the quick entry, it is possible to quickly assign many external subjects for a single academic session. The list of offered subjects will appear on the left-hand side of the screen. While holding down the ‘CTRL’ key on the keyboard, a user can them ‘multi-select’ various subjects and move them to the right-hand side of the screen.

Also, when entering the ‘Credits’ data, it is not necessary to enter ‘Graded’, ‘Earned’, and ‘Attempted’ credits, unless the values differ from one another. If you enter only ‘Graded’ credits, then the ‘Earned’ and ‘Attempted’ credits will be automatically set to equal the ‘Graded’ credits.



A1. Appendix: Customizing the Admissions Process

A1.1 Setting up the Programs and Rules for Admissions Audits

In order to utilize Admissions Audits, it is necessary for each Program of Study to have an Assessment Process defined and scheduled for each admissions session. In the Program Data, make sure that you have indicated ‘Use Assessment Process’:



Then create a relationship of type ‘Comprises Assessment’. The assessment should have assignments of:

From the Program Catalog main screen, right-click on your created assessment, and enter ‘Change’ mode to assign sessions of offering:



Degree Audit sub-requirements are created directly within rule containers in the Requirement Catalog. Once created, each rule is then assigned to part of the academic structure with the proper audit context.

Rules that should apply to multiple programs should be assigned to organizational units. For example, if all undergraduate programs within the College of Liberal Arts requires a high school transcript for admissions application completeness, then the rule container with that sub-requirement should be attached to the organizational unit for the college – not to each individual program. It will be automatically inherited by all the programs of study that are offered by that organizational unit (or offered by ‘children’ organizational units). An example of the proper context assignment is shown below:



For rules that are specific to a Program of Study, the rule container should be directly attached to the Program. Again, it is important to assign the proper context of the rule container during the assignment:



For rules that are specific to Major, the rule container should be directly attached to the Program. Again, it is important to assign the proper context of the rule container during the assignment:



A1.2 Copying and Extending the Scenario

In order to handle additional admissions processes (such as graduate programs, international studies, adult learning, etc.), it is necessary to create a Scenario for each process. The copying of a Scenario can be easily performed directly in the IMG. (Cross-Application Components Internet/Intranet Services Internal Service Request Scenario Definition Define Scenarios) Choose the delivered template scenario ‘SCM1’, and use the ‘Copy As…’ function (F6).

You can now add Characteristics to extend the data model for you admissions scenario, and you can define additional Action Box items for processing your admissions scenario. You will want to define a workflow template specific to your scenario, as described in the next section.

A1.3 Copying and Extending the Workflow

Before making any changes to your admissions process, make a copy of the delivered Workflow Template ‘WS29800001’ (HRIQ_ADM_UG). Transaction ‘PFTC_COP’ can be used to copy the template. Refer to Section 8.5 to review the process for linking your Scenario to your Workflow Template.

A1.3.1 Copying and Replacing Standard Workflow Tasks

The delivered template makes use of a number of delivered Standard Tasks. Some of these should also be copied (mainly so you have the freedom to change message texts). Once copied, you should change your workflow template copy so that the steps which refer to standard delivered tasks now refer to your own copies of those tasks. The tasks that should be copied, and the steps in which they are referred are:

Task ID Task Description Workflow Step TS29800009 Sends a confirmation e-mail when the notification is

saved, even if not in a ‘Submitted’ status 176

TS29800011 Sends a message when there is a problem with the creation of the applicant

282

TS29800004 Sends a confirmation e-mail when the application has been submitted and an applicant ID number has been created for the applicant

85

TS29800007 Sends an e-mail to the applicant when they have been accepted into a program

163

Do not forget to ‘Activate’ your Workflow after you make changes!



A1.3.2 Inserting Steps to Call Action Box Items

To automatically execute an Action Box item from within your workflow, simply insert an item which refers to Standard Task ‘TS29800003’. This is a generic task that simply invokes an Action Box code for the notification. The simplest method is to copy one of the existing steps (such as ‘Create New Student Record’) and change the Binding data so that your Action Box code is passed to the ‘Activity’ container element:




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.

Documents

Admissions Cookbook for Pre- Configured Student Lifecycle