I H E1 02 - SAP St ude nt Lifec yc le M anagem e nt
I H E1 0 2
SAP Student
Lifecycle Management
SAP for Industries
SAP for Higher Education & Research
2009/Q2
© SAP 2009 / Page 1
SAP for Industries
Version 92
Material number: 50096641
Copyright
Copyright 2009 SAP AG. All rights reserved.
Neither this training manual nor any part thereof may
be copied or reproduced in any form or by any means,
or translated into another language, without the prior
consent of SAP AG. The information contained in this
document is subject to change and supplement without prior
notice.
All rights reserved.
© SAP 2008
Trademarks:
Microsoft ®, Windows ®, NT ®, PowerPoint ®, WinWord ®, Excel ®, Project ®, SQL-Server ®,
Multimedia Viewer ®, Video for Windows ®, Internet Explorer ®, NetShow ®, and HTML Help ®
are registered trademarks of Microsoft Corporation.
Lotus ScreenCam ® is a registered trademark of Lotus Development Corporation.
Vivo ® and VivoActive ® are registered trademarks of RealNetworks, Inc.
ARIS Toolset ® is a registered Trademark of IDS Prof. Scheer GmbH, Saarbrücken
Adobe ® and Acrobat ® are registered trademarks of Adobe Systems Inc.
TouchSend Index ® is a registered trademark of TouchSend Corporation.
Visio ® is a registered trademark of Visio Corporation.
IBM ®, OS/2 ®, DB2/6000 ® and AIX ® are a registered trademark of IBM Corporation.
Indeo ® is a registered trademark of Intel Corporation.
Netscape Navigator ®, and Netscape Communicator ® are registered trademarks of Netscape
Communications, Inc.
OSF/Motif ® is a registered trademark of Open Software Foundation.
ORACLE ® is a registered trademark of ORACLE Corporation, California, USA.
INFORMIX ®-OnLine for SAP is a registered trademark of Informix Software Incorporated.
UNIX ® and X/Open ® are registered trademarks of SCO Santa Cruz Operation.
ADABAS ® is a registered trademark of Software AG
The following are trademarks or registered trademarks of SAP AG; ABAP/4, InterSAP, RIVA, R/2,
R/3, R/3 Retail, SAP (Word), SAPaccess, SAPfile, SAPfind, SAPmail, SAPoffice, SAPscript,
SAPtime, SAPtronic, SAP-EDI, SAP EarlyWatch, SAP ArchiveLink, SAP Business Workflow, and
ALE/WEB. The SAP logo and all other SAP products, services, logos, or brand names included
herein are also trademarks or registered trademarks of SAP AG.
Other products, services, logos, or brand names included herein are trademarks or registered
trademarks of their respective owners.
I H E1 0 2 St ude nt Life c yc le Ma na ge me nt :
1. Aca demic St ruct ure and Curriculum M ana ge m ent
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009
© SAP AG
IHE102
1-1
1 . T he st ude nt ’s ac ade m ic life c yc le
Through its comprehensive features, SAP Student Lifecycle Management streamlines
Student information management
Academic information management
Student Account management and
Academic services
The student is at the centre of this solution which supports the administration of a university by consolidating
various business processes into one, end-to-end process, leading to improved services and student retention.
© SAP 2009
© SAP AG
IHE102
1-2
I H E1 02 St udent Lifec yc le M anagem ent :
1 . Ac ade m ic St ruc ture and Cla ss Scheduling
Content:
1. Academic Structure and Class Scheduling
Objects and their Business Context in Student Lifecycle
Management
Introduction to relevant Terminology and Definitions
Organizational Units
Program of Study
Module Catalog
Study Modules and Module Groups
Business Events and Business Event Types
Validity Period and Key Date
Staged and Stageless Programs of Study
© SAP 2008
© SAP AG
IHE102
1-3
1 . Ac ade m ic St ruc ture – Busine ss Sc enario
This chapter describes scenarios relevant for
Members of the academic staff
Academic advisors who are familiar with the University's academic
rules and course offerings
Staff members who are responsible for setting up and
administering programs of study and class schedules
© SAP 2009
© SAP AG
IHE102
1-4
1 . Ac ade m ic St ruc ture – T opic Obje c tives
At the conclusion of this topic, you will be able to:
Set up academic structure objects like
Programs of study (object type SC)
Internal qualifications (object type CQ)
Module groups (object type CG)
Modules (object type SM)
Business event types (object type D)
Define the content of an academic program using the program catalog
and module catalog
Distinguish between staged programs and stageless programs of study
© SAP 2009
© SAP AG
IHE102
1-5
1 . St udent Life c yc le M a na ge me nt Objec t s a nd
Busine ss Cont ex t e s
Academic Structure
Event Planning
Neue s
n Abt
a us de
eil un ge
n
Idee nm ar kt
Die Gesc hä fts leitu ng i nf or mier t
Aus Ver k auf
un d P r od ukti on
im Gespr
I hr e Fr
age
Neue
Pr odu kte
Pr odu kti ons er geb nis se
Ver kauf sber ich te
Program Regulations
Unser e
Ant w or
t
äc h
Neues
aus den
Pr oj ekt
t eam s
Resources
•
•
•
Qualification
© SAP 2009
© SAP AG
IHE102
1-6
1 . St udent Life c yc le M a na ge me nt Objec t s
Student Lifecycle Management uses
Object types
Infotypes
Relationships
Student (ST)
takes
Module (SM)
Relationship
Object
Type
Object
Type
Infotype
© SAP 2009
Student Lifecycle Management is developed within the Personnel Development environment which
belongs to SAP HR. It therefore uses an object-oriented approach based on the following elements:
• Object types
• Infotypes (which describe the object types)
• Relationships between the object types
For general information on the technical HR framework please refer to the respective course
offering (e.g. HR technical aspects).
© SAP AG
IHE102
1-7
1 . Ove rvie w –
St udent Lifec yc le M anage me nt Objec t s
Organizational Unit- O
(University)
Academic
Calendar (CA)
Organizational Unit - O
(Faculty, etc.)
ST
Applicant/
Student
BP
Degree (CQ)
Business
Partner
SC
Program of Study (SC)
Module Groups (CG)
Modules (SM)
External Educational
Institution (EO)
Bus. Event Type (D)
External Subject (SU)
Events (E)
External
Qualification (EQ)
Individual Work (CI)
Bus. Event Package (SE)
RC
Rules
© SAP 2009
The following object types are used in Student Lifecycle Management, some of them originating
from other applications:
• Organizational unit (O, origin: HR core functions – Organizational Management)
• Academic calendar (CA)
• Program of study (SC)
• Module groups (CG)
• Modules (SM)
• Event packages (SE)
• Event types (D, origin: HCM – Training & Event Management (TEM))
• Events (E, origin: HCM – Training & Event Management (TEM))
• Internal qualification (CQ, not the same as the qualification in HCM!)
• Student (ST)
• Business partner (BP, origin: Financial Contract Accounting (FI-CA))
• External organization (EO)
• External subject (SU)
• External qualification (EQ)
• Rule container (RC)
© SAP AG
IHE102
1-8
1 . Ove rvie w – Ac a de m ic Progra m Ca t a log
Academic Structure = All Degree Programs offered by the University
Organizational Unit
(O)
University of Student Lifecycle Management
School of Business Administration
Faculty of Physical Sciences
Physics, BSc Honors
Program of Study
(SC)
Physics, MPhys Honors
Mathematics, MMath Honors
Computer Science, BSc Honors
College of Liberal Arts
Faculty of Arts
© SAP 2009
The organizational structure of an institution is reflected by its organizational units which can be
arranged in a hierarchy. Degree programs (Programs of study) are offered by departments, faculties,
colleges, etc.
Each program of study can be attached to at least one organizational unit. This organizational unit is
responsible for the program.
You can define more than one organizational unit as responsible unit for a program.
Every program has its own academic regulations.
Student Lifecycle Management delivers a report to extract the academic structure and Module and
event offerings in XML files in order to display them on the web. Generated XML files can be
downloaded to any file system if the report is executed in dialog mode (GUI download). If the report
is executed in batch mode, the files must be created on the application server first and must then be
copied to another file system. SAP menu Path: Student Lifecycle Management Menu Academic
Structure
PIQ_XML00 - Generate XML Files.
© SAP AG
IHE102
1-9
1 . St udent Life c yc le M a na ge me nt Objec t s a nd
T e rm inology
Object
Object Name
Academic Structure
Definition
Curriculum
SC
Program of study
A program of study represents an approved combination of modules in one or
more subjects which fulfill the requirements for a degree.
Universities offer programs of study with different qualification levels.
Students register for one or several programs of study.
CG
Module Group
There are two types of module groups:
1. Module groups refer to a combination of modules and represent, for
example, a structure for a catalog or set of modules for a degree requirement.
2. Module groups refer to specializations within a program of study such as
major and minor.
CQ
Internal
Qualification
(Internal) Qualifications can be conferred with the following uses on a student:
Qualification for a program (program completion), Qualification for stage
completion, or Qualification without a program reference
SM
Module
Academic unit in which students learn a defined content and can acquire
credits. Most modules are offered as courses but they can also represent a
more generic type of academic work (e. g. a thesis). They can be offered as
one event or as a number of events.
CO
Cohorts
Cohorts refer to a group of students for whom certain administrative activities
(e.g. module booking) are performed together.
© SAP 2009
© SAP AG
IHE102
1-10
1 . St udent Life c yc le M a na ge me nt Objec t s a nd
T e rm inology
Object
Object Name
Definition
D
Event Type
An event type describes a template which is used for planning
different events.
O
Organization
An organizational unit offers study programs and events.
CA
Academic Calendar
The academic calendar contains the different dates related to
business processes of the university.
RC
Rule Container
Rule containers support the control of the different business
processes at the university.
Additional Student Lifecycle
Management Terminology (no objects)
Definition
Module Booking (also: Course
Registration)
Registration for a module
Module Catalog
A catalog containing all the modules within the organizational
structure of the institution
Registration
Assignment to a program of study at a university
Re-registration
The process by which a student's enrollment at a university/
college is extended for another academic period
© SAP 2009
© SAP AG
IHE102
1-11
1 . Ac ade m ic St ruc ture – Orga niza t iona l U nit s
Organizational Unit
(O)
HR Object
offers
Program of Study
(SC)
offers
Module Group
(CG)
offers
Module
(SM)
© SAP 2009
Before you can create academic structures, you must set up an organizational structure. You set up
this organizational structure in the HR system. To create the required objects, select from the SAP
menu:
• Student Lifecycle Management
Environment
Organizational Management
Organizational Plan
Organization and Staffing Create
• Transaction PPOCE
Then:
• Define the top organizational unit. You must define a top organizational unit in each client.
• Define the institution's complete organizational structure (schools, departments, etc.) by setting
up a hierarchical structure consisting of organizational units (O) and linking them to the top
organizational unit (relationship 003 "belongs to“ between O and O).
Note: Organizational units do not have to be connected to the Top Org Unit.
© SAP AG
IHE102
1-12
1 . Ac ade m ic St ruc ture – Progra m Ca t a log
O – Organizational Unit (Academic School or College)
SC – Program of Study
CQ – Degree
CG – Major
CG – Compulsory
CG – Emphasis
CG – Specialization
SM – Module A
SM – Module B
CG - Minor
O – Organizational Unit (Department)
© SAP 2009
Programs of study are set up and administered in the program catalog from the SAP menu:
Student Lifecycle Management
Academic Structure (Curriculum)
Study Planning
Program
Catalog,
or transaction PIQ_ACSTRUC
The program catalog has two different views:
• Tree structure of the program of study: This gives you an overview of all objects included in the
program of study and shows their relation to each other. When you select a program of study or
an organizational unit via the object manager, the system displays the selected objects top down.
• Graphical overview: Here you see the program as a program plan. If the program is subdivided
into stages, only this view will show you which module or module group is offered for which
stage. To start the graphical overview, you have to select a program of study within the tree
structure and then choose `overview´.
Start with organizational units and use the program catalog to:
• Define programs of study as object types SC and link them to an organizational unit.
• Link qualifications (CQ), such as the final degree, to the program of study.
• Define rules like prerequisites by linking the modules or qualifications which serve as
prerequisites for the program of study or object within the program.
• Example: You have pre-requisite requirements for a module where the student must have
completed 3 out of a list of 5 possible modules. You can use the Extended Booking Check to
assign pre-requisites and co-requisites directly to a module (see topic Extended Booking Check
in Chapter “Course Registration”).
• For more complex rules, you have to set up rules defined in a rule container (VSR) and link the
rule container to an object within the academic structure.
• Attach module groups and modules to the program of study and structure them according to
stages if it is a program with stages.
© SAP AG
IHE102
1-13
1 . Ac ade m ic St ruc ture – Progra m of St udy
Program
Catalog
Program of Study
(SC)
imparts / has a prerequisite
consists of
Internal Qualification
(CQ)
Module Group
(CG)
consists of
consists of
Module
(SM)
© SAP 2009
After setting up the organizational structure, use the Program Catalog to:
Define the module groups within the program of study (to combine related modules or offer
specializations such as major) as part of the program content (relationship 500 "consists of“).
Link modules to the associated module groups within the program of study as part of the program
content (relationship 500 "consists of“).
Link modules directly to the program of study as part of the program content (relationship 500
"consists of“).
Define the internal qualifications (= degrees) awarded upon completion of the program of study
(relationship 528 "imparts“).
Define the internal qualifications which are prerequisite for the program of study (for example, the
undergraduate degree required for a postgraduate program) (relationship 529 "is prerequisite of“).
Link a rule container to the program of study (relationship 509 "is used by“).
You can use the Program Catalog and Module Catalog to:
• Create the objects which are directly related to the organizational structure and interlink them by
means of the relationships
– “offers“ (501) program of study (SC)
– “offers“ (501) module group (CG)
– “offers“ (501) modules (SM)
© SAP AG
IHE102
1-14
1 . Ac ade m ic St ruc ture – Progra m of St udy
At t ribut e s (1 )
A program of study
Is an academic offering of a university
Leads towards a degree
Combines content and academic rules
Important attributes of programs of study (object type SC):
Attributes must be maintained in the program infotypes.
Some attributes are essential in the configuration of student
administration processes.
All attributes must be set up in customizing before you can create a
program of study.
© SAP 2009
A program of study (SC) is an approved combination of academic activities that satisfies the
requirements of the University’s degree programs (Bachelor of Arts, Bachelor of Science, etc.),
certificate programs, and non-degree offerings.
The Student Lifecycle Management system contains data catalogs for programs of study, modules,
business events, and business event types. In these data catalogs, you can create and maintain the
associated data objects.
When you create a program of study, you take elements from the different catalogs and include them
in the new program:
• Each element is reusable and can be included in different programs.
• The reusability of elements enables you to maintain programs with a minimum amount of effort
because data only has to be changed once it is in the relevant catalog.
To create a program of study or change its attributes, go to:
• SAP menu
Planning
Student Lifecycle Management
Program of Study
Academic Structure (Curriculum)
Study
• SAP menu
Planning
Student Lifecycle Management
Program Catalog
Academic Structure (Curriculum)
Study
• Transaction PIQSC or PIQ_ACSTRUC
© SAP AG
IHE102
1-15
1 . Ac ade m ic St ruc ture – Progra m of St udy
At t ribut e s (2 )
When setting up a program of study, you define different attributes:
Program of Study (SC)
Related Process/Function:
Program Plan (= w. stages/stageless)
Progress Classification
Academic Structure + Others
Registration, Progression
Program Type
Session Variant
Progression
Event Planning, Registration
Program Duration
Admission Restriction (Yes/No)
Full-Time/Part-Time/Both
Progression
Admission
Registration
© SAP 2009
You create the program attributes which are offered as input help when you create a program of
study in Customizing for Student Lifecycle Management under: Student Lifecycle Management
Master Data
Academic Structure
Programs of Study.
• The progress classification is used to subdivide your program types according to the promotion
process for each program.
• You define the program type (undergraduate, postgraduate, law, etc). The program type
definition is directly related with the progression process (see chapter “Progression”.)
• You can define the type of session or session variant into which your academic year is divided
(semesters, trimesters, year, etc.). The session variant defines at which intervals within the
academic year students have to register and re-register (see chapter “Program Registration”).
• Program duration / max. program duration: You can specify the (maximum) number of years
students can study a program. You can check program duration by means of a rule.
• If the admission restricted flag is set, the system will not allow you to register a student for a
program if you have not completed the admission process.
• The fulltime/part-time flag determines whether the program is offered for full-time and/or parttime study. You can choose between full-time, part-time, and both.
© SAP AG
IHE102
1-16
1 . Ac ade m ic St ruc ture – Progra m of St udy
At t ribut e s (3 )
Furthermore, you can define ...
Program of Study (SC)
Related Process/Function:
Capacity
Admission (Manual)
Fee Calculation Data
Student Accounting
Disciplines (CIP Codes)
Selection Criteria (Reporting)
Program Credits (Total, Per Stage)
Progression
Evaluation
Currently Not Used (Grading)
Relationships:
Academic Structure
Organizational Structure
Attach module groups and modules offered
within the program
Attach program to org. unit(s)
Weighting factor for relationship
© SAP 2009
The capacity determines the minimum, optimum, and maximum number of places in a program. It
can be stored in the system, but it is currently not used in any process.
The fee calculation data enables you to set different prices for different program categories, for
example, for graduate and undergraduate programs.
The discipline defines the field of study of a program. You can assign your programs of study,
module groups, modules and external subjects to one or more disciplines. One discipline can be
defined as the “primary” discipline and used for reporting purposes. The discipline table supports
the use of CIP (Classification of Institutional Programs) taxonomy (US-specific).
• A CIP Code Data Load program is available in the IMG for Student Lifecycle Management
Master Data in Student Lifecycle Management Academic Structure Modules Upload CIP
Codes from File
You can define the minimum and maximum number of program credits students must complete
before they are allowed to graduate. The required number can be checked against the total earned
credits for a program based on a set of rules. You can also define the minimum and maximum
number of credits students must complete in one stage if your progression rules require this.
Evaluation: You can attach an appraisal template to the program of study. Usually during the
grading process, the appraisal template is used to enter grades for a student’s module booking within
a module. Together with the appraisal template, you can specify the scale in which grades should be
entered (see chapter “Grading”).
If more than one organizational unit offers a program (relationship 501 “offers”), you can define a
weighting factor which determines the contribution of each organizational unit towards the program
(in %).
© SAP AG
IHE102
1-17
1 . Ac ade m ic St ruc ture – I nt e rna l Qua lifica t ion
Qualifications represent the outcome of a student’s academic career
Degree
Certificate
Language Skills
Student Lifecycle Management distinguishes between
Internal Qualifications:
Which a student receives from
your institution
External Qualifications:
Which a student received from
other institutions
Important attributes of internal qualifications (object type CQ)
Attributes must be maintained in internal qualification infotypes.
Some attributes influence other student administration processes.
All attributes must be set up in Customizing before you can create an internal
qualification.
© SAP 2009
A qualification represents the successful outcome of a student’s academic career. An internal
qualification (CQ) represents the degrees, diplomas and certificates awarded at the educational
institution. These are associated with the programs that students are pursuing (via relationship
“imparts”) and are awarded during graduation processing (see Confer Degree in chapter
“Graduation”).
To create an internal qualification or change its attributes, go to the SAP menu Student Lifecycle
Management
Academic Structure (Curriculum)
Study Planning
Internal Qualification.
© SAP AG
IHE102
1-18
1 . Ac ade m ic St ruc ture – I nt e rna l Qua lifica t ion
At t ribut e s
To set up an internal qualification, you can define the ...
Related Process/Function:
Internal Qualification (CQ)
Academic Structure, Rules
Reporting
Qualification Group
Qualification Discipline
Degree Type and Level
Grading Scale
Admission, Graduation
Graduation
© SAP 2009
You can define internal qualification attributes which are offered as input help when you create an
internal qualification in Customizing: Student Lifecycle Management Master Data
Qualifications.
You can set up qualification groups by combining different sets of internal and external
qualifications, e.g., you can combine the internal qualifications “Bachelor of Science” and “Master
of Business Administration” in the qualification group “Academic Degrees”. Diplomas and
certificates can also be part of qualification groups.
• Related process: You can use a qualification group to define rules, e.g., by specifying program
requirements using a qualification group - “Applicants must have high school diploma”.
The qualification discipline describes the field of study in which the internal or external qualification
was acquired.
• Note: The qualification discipline table refers to the same table as the disciplines for other
academic objects.
The degree type defines the type of diploma awarded by the institution or external institutions. The
degree type links a degree with a degree level. Possible degree types are Bachelor, Master, PhD,
Associate, high school diploma, etc.
The degree level indicates the standing of a degree offered by the institution and external institutions
(high school, college, university). Possible degree levels are UG, G, high school, etc. A degree level
must be assigned to each degree type.
Related process: You can use the degree level and degree type to define rules. For example, you can
specify program requirements using the degree level and degree type – “Applicants must have a
high school diploma”.
You can select a predefined scale to rate the qualification.
© SAP AG
IHE102
1-19
1 . Ac ade m ic St ruc ture – M odule Groups (CG)
Program
Catalog
Module Group
(CG)
consists of
Module Group
(CG)
consists of
consists of
Module
(SM)
© SAP 2009
Module groups (CG) are used to structure the module (= course) requirements for a program of
study into one or more reusable components. Module groups can be built with a hierarchy:
• For example, major component, college core component, general studies component, where
students have to take all modules belonging to that module group.
• Logical groupings or bundling of different modules like “all language modules” etc. where
students can select from the modules within that module group (“take 2 out of module group X”).
© SAP AG
IHE102
1-20
1 . Ac ade m ic St ruc ture – M odule Group
At t ribut e s
Module Groups (CG) are used to group modules together and can be used for:
Grouping:
Specialization:
SM’s are grouped together to allow
better selection and maintenance
definition of rules for a group of
SM’s
Module groups can represent
specializations which
are part of the options within a
program of study
a student can register for
CG
SM
SC
CG
© SAP 2009
To create a module group or change its attributes, go to:
• SAP Menu
Student Lifecycle Management
Planning Module Group
Academic Structure (Curriculum)
Study
• SAP Menu
Student Lifecycle Management
Planning Program Catalog
Academic Structure (Curriculum)
Study
Important attributes of module groups (object type CG):
• Attributes must be maintained in the module group infotypes.
• Some attributes impact other student administration processes.
• All attributes must be set up in Customizing before you can create a module group.
© SAP AG
IHE102
1-21
1 . Ac ade m ic St ruc ture – M odule Group
At t ribut e s
To set up a module group, you define...
Module Group
(CG)
Related Process/Function:
Module Group Category
Registration
“Specialization” (Flag)
Number of Stages
Discipline (CIP Codes)
Selection Criteria (Reporting)
© SAP 2009
The module group category enables you to categorize your module groups. You can specify whether
students can select the module groups of a particular module group category as an academic
specialization which represents mandatory components of a student’s degree requirements. Students
can only register for module group categories defined as “specializations” (major, minor,
concentration/emphasis, etc.).
Categories, which only serve to combine module groups or modules, are not considered academic
specializations and cannot be booked. The module group variant can contain an OR statement (for
example, students must select “2 majors” OR “1 major + 1 minor”) and an undefined number of
module groups for registration.
• Related process: You define module group variants by combining module groups identified by
their category. This is an attribute of the program of study which controls the assignment of
academic specializations.
Discipline
© SAP AG
see Program of Study
IHE102
1-22
1 . Ac ade m ic St ruc ture – M odule Group
V a ria nt s
Program of Study
(SC)
CG A
e.g. Major
CG B (spec.)
e.g. Economics
CG C (spec.)
e.g. Comp. Science
CG D (spec.)
e.g. Major in ...
CG E (spec.)
e.g. Minor in ...
Students can choose
1 Major + 1 Minor
CG F (spec.)
e.g. Minor in ...
© SAP 2009
The module group variant enables you to define the academic specializations available to students
(in the registration dialog or student file) based on the program they are currently pursuing. Before
you can offer specializations, you must perform the following preparatory steps:
• 1. Set up module group variant/category combinations.
– For example, the University offers programs in which students can choose either one major
(module group category “Major”) and one minor (module group category “Minor”), or one
major and two minors. You have to define a module group variant for each of these options.
• 2. Define the relevant module group categories as a “specialization” (by setting the flag in the
customizing table).
• 3. Assign a module group variant to the program of study (Program data tab page of the object
SC).
• 4. Link module groups to the program of study which reflects the required module group
categories.
When you have performed the above steps, you can maintain the allowed combinations of module
groups in the SLCM Menu
`Environment`
Maintain acad. specializations in the `program
catalog`.
• This function allows you to define the rules for valid and invalid specialization combinations for
each of your programs of study. For example, you may have a B.A. program that requires
students to select a major and a minor: With this function, you can explicitly define the
major/minor combinations that are not permitted (e.g. Math Major and Math Minor).
Note: You do not have to explicitly define all allowed combinations.
© SAP AG
IHE102
1-23
1 . Ac ade m ic St ruc ture – M odule s (SM )
Modules are combined to programs of study
Program of
Study
Program of
Study
Physics, BSc
Module C
Module B
Module A
Chemistry
mandatory
Module C
optional
optional
mandatory
optional
Module C
Module 3 – Exp. Physics I
Module 2 – Theor. Physics I
Module 1 – Math. Skills I
© SAP 2009
Modules are academic courses (classes, tutorials, lectures, examinations, etc.) which define the
content of a program of study. They can be either mandatory or optional.
Modules (SM) are courses a student can
• Book (register for)
• Prebook (preregister for)
• Get grades for
• Get credits for
Students can receive grades and credits only for modules.
Attributes of modules (object type SM)
• Attributes must be maintained in the module infotypes
• Some attributes impact other student administration processes
• All attributes must be set up in Customizing before you can create a module
To create a module or change its attributes, go to:
• SAP Menu
Student Lifecycle Management
Academic Structure (Curriculum)
Study
Planning Module
• SAP Menu
Student Lifecycle Management
Academic Structure (Curriculum)
Study
Planning Module Catalog
• Transaction PIQSM or PIQ_ACCTLG
You can define the module attributes which are offered as input help when you create a module in
Customizing for Student Lifecycle Management under:
• Student Lifecycle Management Master Data
Academic Structure
Modules
© SAP AG
IHE102
1-24
1 . Ac ade m ic St ruc ture – M odule At t ribut e s
To set up a module, you define ...
Module (SM)
Related Process/Function:
Module Booking
Capacity
Discipline (CIP Codes)
Module Data:
Reporting
Module Booking Rules
Academic Level
Category
Repetition Type
Program Type Assignment
Progression
Pattern
Event Planning
Teaching Emphasis
Reporting, Audits
Number of Credits
Booking, Grading
Fee Calculation Data
Student Accounting
“Show in Catalog” Flag
Attendance Calculation Rules
© SAP 2009
The academic level refers to the learning content’s level; e.g. 1st year, 2nd year, graduate, preuniversity, 100 level, 200 level, etc. You can use this information for rules definition.
The category is also used for business event types and can refer to lecture, workshop, etc.
Repetition type: If you want to control the booking procedure for the repetition of a module, you
must define VSR rules for the module booking process using this attribute.
Program type assignment: You can assign the module to a program type, e.g. Level 100 course =
Undergraduate, Level 500 = Postgraduate. You can assign a module to different program types
concurrently.
Pattern for sessions of offering: Specifies the academic sessions and the interval at which a module
is offered. You need to set up patterns and maintain them (= combine pattern with academic
sessions)
Teaching emphasis: Specifies the main method used to teach specific skills.
You can define the minimum, optimum, maximum number of credits for the module. When a
student books the module, the attempted credits are derived from the module credit value. You can
assign students any number of module credits within the credit range.
Fee calculation data enables you to set different prices for different module categories, for example,
full-time course, part-time course.
The ‘Show in catalog’ flag can be evaluated when displaying the University's academic catalog (not
in the ERP system).
Attendance calculation rules must be maintained at the module (or organization unit) level.
The Special Assessment Method for modules is used for module booking. It defines if students are
awarded credits for the module or if the method differs from the normal procedure.
© SAP AG
IHE102
1-25
1 . Ac ade m ic St ruc ture – M odule Ca ta log
O – Organizational Unit (Department etc.) offers
SM – Module A
SM – Module B
SE – Event Package
SM – Module C
D – Event Type A
EL – Academic Unit w/o Dates
D – Event Type C
E – Event 1
E – Event 2
D – Event Type B
CI – Individual Work
CI – Individual Work
CE – Assessment
© SAP 2009
You can maintain modules and objects below the program level using the module catalog which is
accessed via:
• Student Lifecycle Management
Academic Structure (Curriculum)
Module Catalog from the SAP menu, or transaction PIQ_ACCTLG.
Study Planning
Start with organizational units and use the module catalog to:
• Define the modules as object types SM which are offered by a particular organizational unit (for
example, all courses offered by the Department of Biology) and link them directly to the
organizational unit (relationship 501 "offers“).
• Create business event types connected to modules, which describe the offerings per module.
• Start the event planning process and administer the academic offerings per session, that is, define
which module is offered in which session. The planning process also includes the creation of
academic units w/o dates and individual work.
• Combine different events to an event package or create an event package for a module without
planning the events.
Two different catalogs enable you to distinguish between authorizations, access academic data and
define the different persons and departments who are responsible for catalog maintenance. You can
keep the maintenance authorizations for different structures separately by using the two different
catalogs:
• 1) Program catalog for defining program content
• 2) Module catalog for defining module content
Pre-Requisite Checks can be maintained directly in the Module Catalog (see chapter Course
Registration.
© SAP AG
IHE102
1-26
1 . Aca de m ic St ruc t ure – Business Eve nt T ype s
Business Event types can be grouped within a Module
Bus. Event Types
Module 3 – Exp. Physics I
1.
Lectures in Exp. Physics III
2.
Exercises in Exp. Physics III
3.
e-learning in Exp. Physics III
Bus. Event
Package (SE)
Business event packages
represent a combination of
academic events.
© SAP 2009
Modules contain the business event types which serve as templates for event planning. You must
create the required business event types in the module catalog before you begin event planning.
• A business event type can be used in different modules. A module can be used in different
programs of study. Note that one event type should not be shared across multiple modules, unless
students are actually attending shared events!
• Each business event type attached to a module reflects a compulsory academic event which
students who book the module must attend. A student must attend one event for each business
event type in a module in order to complete the module.
• Business event packages represent a combination of academic events. A business event package
can be part of a module as well as of business event types. The event package can either be a
reusable, long-lived object or a short-lived object which is used only for one event planning
session. The business event itself is created a new in each event planning period.
• When you plan events for a certain time period, you use the data stored in the business event
types as a template.
© SAP AG
IHE102
1-27
1 . Ac ade m ic St ruc ture Sum ma ry: M odule
Module (SM)
Module Catalogue
A528 imparts
A529 needs prerequisite
Internal Qualification
(CQ)
A507 consists of
Bus. Event Type
(D)
A529 is prerequisite of
A 511 refers to
Module
(SM)
A 544 is Exam Coverage of
B 548 Comprises Assessment
A 509 is used by
Assessment
(CE)
Rule Container
(RC)
© SAP 2009
You can use the module catalog to create the required objects and relationships. In the module
catalog you can:
• Define the business event types that a module consists of. A business event type is the general
description or blueprint on which the actual teaching event is based (business event types for
lectures, tutorials, etc.) (relationship 507 "consists of“)
• Define the internal qualifications which are imparted by a module (relationship 528 "imparts“).
(These qualifications are usually not at the degree level. The final degree is imparted by the
program of study).
• Define the internal qualifications which are prerequisite for a module (relationship 529 "is
prerequisite of“).
• Define the modules which are prerequisite for a module (relationship 529 "is prerequisite of“).
• Define the modules which complement each other (modules which must be booked together)
(relationship 533 "is corequisite of“).
• Define module crosslistings (relationship 511 "refers to“).
• Link a rule container to a module (relationship 509 "is used by“).
• Purpose: Map different types of assessment examinations within module program completion
(graduation) and stage completion assessment.
• Assessments can be linked to programs, stages and modules.
© SAP AG
IHE102
1-28
1 . Ac ade m ic St ruc ture Sum ma ry: Program of
St udy
A program of study is structured as follows:
Program of Study -> contains Modules grouped by Module Groups
Program of
Study (SC)
Physics, BSc - Module 3 (SM)
Fundamental
Physics (CG)
Physics, BSc - Module 2 (SM)
Physics, BSc - Module 1 (SM)
Modules (SM) -> contain Business Event Types
D
1.
Physics, BSc - Module 3
Lectures in Exp. Physics III
(E)
D
2.
Exercises in Exp. Physics III
(E)
Bundled to
Event Packages
(SE)
D
3.
Examination in Exp. Physics III (E)
Business Event Types -> Basis for Event Planning
Lectures in Exp. Physics III
Lectures in Exp. Physics I (E)
Monday, 01/05 10 a.m. - 11.15 a.m.
Mr. Smith, Lecture Room 4
Monday, 01/12 10 a.m. - 11.15 a.m.
Mrs. Brown, Lab 1
© SAP 2009
A program of study consists of structural elements:
• Specializations, such as majors, minors, etc., which are called module groups (CG)
• Courses which are called modules (SM)
• Academic events, such as classes, tutorials, labs, etc., which are business events (E)
– Module groups are used to map business, logical and organizational relationships within a
program of study. They enable you to combine related modules and build a hierarchy of
module groups. In addition, module groups allow you to map program specializations such as
majors, minors, and the like in the system.
– Business events and business event types refer to teaching events, such as classes, tutorials,
and lectures. They are part of a module and are attended by the students who booked the
module.
– Business event packages represent a combination of academic events. When a student books
an event package, she/he books all the events within the package in one step.
© SAP AG
IHE102
1-29
1 . Ac ade m ic St ruc ture Sum ma ry: Ex a mple
Org. Unit
(O)
Degree
Program (SC)
e.g. Dept. of Chemistry
Major (CG)
(Specialization)
Chemistry
Degree (CQ)
e.g. Bachelor of Science in
Chemistry
Minor (CG)
(Specialization)
e.g. Bachelor of Science,
type Bachelor
General
Studies Set (CG)
Degree Program =
Program of Study (SC)
Internal Qualification (CQ)
College
Specific Set (CG)
Specializations +
Module Groups
= Module Groups (CG)
Organic
Chemistry
Courses,
= Module SM
Course (SM)
e.g. CHM101
Introductory ...
Course
Components (D)
e.g. 3 hr lecture +
Course
Components (D)
Labs (E)
Lab: 1:40 – 3:30, T, Cjones
Lecture (E)
e.g. 01694 CHM 101
Lecture: 8:40 – 9:30, MWF,
Cjones, start Jan., 5th 2008
Individual Work
(CI)
Thesis
Assessment
(CE)
Exam: Mathematic
Bus. Event Type
=D
Bus. Event
Package = SE
Bus. Event
=E
© SAP 2009
Example of an academic structure of a University which can be created in Student Lifecycle
Management. When setting up the academic structure, you “design” the appropriate structure by
putting the relevant objects (such as organizational units, module groups, module,…) in relationship
with one another:
Customizing Examples:
• Example 1: you link objects to a Program of Study (SC) in the Program Catalog. The following
relationships are available in standard:
– Relationship 548 (comprises assessment)
– Relationship 500 (consists of)
– Relationship 528 (imparts)
Object CG (Module Group)
Object CQ (Internal Qualification)
– Relationship 529 (needs prerequisite)
– Relationship 500 (consists of)
Object CE (Assessment)
Object CQ (Internal Qualification)
SM (Study Module)
• Example 2: You maintain program data for a program of study. The program plans (e.g. 4 stages)
which you have defined in Customizing will be available in the drop down list on the program
data tab of the program of study. Customizing path:
• IMG
Student Lifecycle Management
Master Data in Student Lifecycle Management
Academic Structure
Program of Study: Set Up Program Plans
• Example 3: You maintain attributes of a Module Group in the Program Catalog. The drop down
list in the Module Group Data tab displays only those module group categories (e.g. Major,
Minor) which you have maintained in the Customizing for module groups.
• IMG
Student Lifecycle Management
Academic Structure
Module Groups
© SAP AG
Master Data in Student Lifecycle Management
Set Up Module Group Categories
IHE102
1-30
1 . Ac ade m ic St ruc ture :
V a lidit y Pe riod a nd K e y da t e
Validity Period
Each infotype record uses a start and end date to specify the validity date of infotype data.
The validity period enables the user to evaluate key data or periods in the past, present or future.
The validity of an object’s relationships and attributes can exist only within the life span of the object
defined in the Object infotype.
Key Date
Contains the key date and describes how the system derives this date.
Dependencies: The key date description depends on how the system derives the key date:
1. System date
2. Start date of the academic period (year and session)
The system derives the key date from the start date of the academic session in the given
academic year.
3. User-specific selection date
4. Current academic year
The system derives the key date from the start date of the current academic year.
Keydate = 01.10.1950
Object is visible
Keydate = Systemdate (today)
Object is not visible
Validity period of infotype (Object):
01.01.1950 – 31.12.2008
© SAP 2009
In the program and module catalog the system creates objects with the start date equal to the key
date.
•
To create an object with the start date 01.01.1950, the key date has to be set to 01.01.1950.
To select and maintain objects, the correct key date has to be set in order for the system to derive
this date:
• The key date has to be in the life span of the object. Otherwise it is not visible that the object
exists.
© SAP AG
IHE102
1-31
1 . Ac ade m ic St ruc ture – St a ge d Progra ms of
St udy
CE 1
CG 1
Stage-1
SM 1
CE 2
SM n
SC
CG 2
Stage-2
SM A
SM Z
CE a1
CE a2
When you create a program of study using the program catalog, you must
specify whether it has different stages.
Stages structure a program according to a time line. Students in this type of
program have to start with stage 1.
© SAP 2009
When you create a module group in a program of study with stages, you must specify the first
relevant stage:
• This is the first stage in which students can take the module group.
• Modules within this module group may not be taken by students in lower stages (e.g. the module
group "Major in Finance“ contains only modules from stage 3 and higher).
The modules within a module group and module groups can be assigned to one or more stages.
Students in these stages can book the modules and/or module groups.
This slide illustrates the concept of programs of study with stages: The modules within a module
group and module groups can be assigned to one or more stages. Students in these stages can book
the modules and module groups. Stage audit and progression rules determine when students are
allowed to continue with stage 2 (See Chapters Progression and Degree Audit).
You can define the number of stages a module group covers within a staged program. If you attach
module groups to staged programs, you can define the first relevant stage. Together with the stage
information stored in the module group, the system can determine for which stages the module
group is relevant.
Note: The specialization registration screen does not filter offered module groups based on the stage
the student is registered in. But when you book a specialization, you can use a BADI to check
whether the student is allowed to register for the module group in the current stage or not:
• IMG for Student Lifecycle Management
Processes in Student Lifecycle Management
Academic Specialization Booking
BAdI: Derive Stage-Dependent Module Group Variant
© SAP AG
IHE102
1-32
1 . Ac ade m ic St ruc ture – St a ge d Progra ms of
St udy
Step 1 (Create Program of Study)
Create object
O
SC
Program plan: with stages/stageless
Step 2 (Create Modules)
Create object
O
SM
Step 3 (Assignment)
Create object
SC
Create relationship
CG
First stage (rel.)
SM
First stage (rel.)
Last stage (rel.)
Mandatory/Core item
© SAP 2009
© SAP AG
IHE102
1-33
1 . Ac ade m ic St ruc ture – St a ge le ss Progra m of
St udy
In a stageless program of study, modules are not structured according to a time
line such as stages.
The order in which students have to take modules is defined by the level of the
module, course prerequisites, etc. It can be stored in rule containers or defined by
creating relationships between the modules (SM is prerequisite or corequisite of
SM).
Note: The attribute “with stages” or “stageless” (defined within the program plan)
cannot be changed once it is set!
© SAP 2009
© SAP AG
IHE102
1-34
1 . Ac ade m ic St ruc ture – T opic Sum m a ry
You are now able to:
Set up academic structure objects like
Programs of study (object type SC)
Internal qualifications (object type CQ)
Module groups (object type CG)
Modules (object type SM)
Event types (object type D)
Define the content of an academic program using the program catalog
and module catalog
Distinguish between staged programs and stageless programs of
study
© SAP 2009
© SAP AG
IHE102
1-35
© SAP AG
IHE102
1-36
I H E1 02 St udent Lifec yc le M anagem ent :
2 . Ac ade m ic Ca lenda r
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009
© SAP AG
IHE102
2-1
I H E1 02 St udent Lifec yc le M anagem ent :
2 . Ac ade m ic Ca lenda r
Content:
2. Academic Calendar
Basic Concept: Academic Structure, Academic Calendar,
and Evaluation Path
Academic Years and Sessions
Time Limits: General Concept und Customizing
Time Limits in Module Booking and Student Accounting
Factory Calendar
© SAP 2009
© SAP AG
IHE102
2-2
2 . Ac ade m ic Ca lenda r – U nit Obje c t ive s
At the conclusion of this unit, you will be able to:
Explain the concept of Academic Years, Sessions, Session Groups,
Time Limits, Time Limit Sequences, and Priority Registration Windows
Set up Academic Years and Sessions in preparation for using the
Academic Calendar
Create and maintain an Academic Calendar
Integrate an Academic Calendar in the Academic Structure
© SAP 2009
© SAP AG
IHE102
2-3
2 . Ac ade m ic Ca lenda r – Busine ss Sce na rio
You are
A member of the academic staff who is responsible for
setting up and administering academic years and sessions
Responsible for maintaining dates and time limits for
activities at the University
© SAP 2009
© SAP AG
IHE102
2-4
2 . Ac ade m ic Ca lenda r – Busine ss Sce na rios
Academic Calendars can be used for ...
1
Planning processes
Academic year and Session setup (sessions, days of classes,
holidays ...)
Module offerings and Event Planning
Scheduling of Assessments
2 Academic processes during the lifecycle of a student
Admission and Registration per Session or Academic Year (depends on
primary unit)
Module and Event Booking
Assessment Processes
Program Type progression per session
Conferment of Qualifications
© SAP 2009
Student Lifecycle Management uses academic calendars to:
• Define the start and end dates of each academic year and session (for example, Fall Semester
2009 starts on 08/16/2009 and ends on 12/31/2009).
• Define the start and end dates of periods in which academic events (lectures, classes, exams, etc.)
are offered. These predefined periods are used in event planning as default values for the event
planning period.
• Specify time limits for academic and administrative processes like start dates and deadlines.
• Specify time limits for fee calculation purposes, for example, add/drop periods for module
booking which influence the fees and the refund a student gets when canceling the module
booking.
Note: The definition of start and end dates for academic years and sessions is mandatory for all
processes. All other time limits are optional. If no specific time limit is maintained, the processes
always refer to the academic year and session.
© SAP AG
IHE102
2-5
2 . Ac ade m ic Ca lenda r – Busine ss Sce na rios
Academic Calendars can also be used for ...
3
Checking deadline rules
Admission deadlines
Registration, re-registration and de-registration deadlines
Module and Event Booking deadlines
etc.
4
Fee Calculation
Fee payment per session or full Academic Year
Add or drop periods
Due date schedules
© SAP 2009
Module Booking deadlines refer to concrete time periods (so called booking windows) in which
specific student groups are allowed to book modules.
Remote Function Calls (RFC’s) are available to allow other systems/applications to read the
academic calendar:
• HRIQ_READ_TIMELIMITS_CA: provides dates for academic periods without regard to a
specific context (i.e. if for module booking other periods are relevant than for registration).
• HRIQ_ACAD_DEFAULT_CA_GET: Reads Top Calendar
• HRIQ_ACAD_READ_TIMELIMITS: Reads data from source/top calendar
• If HRIQ_ACAD_READ_TIMELIMITS is called without start object, it will go to the top org
unit automatically.
• RFC HRIQ_CAL_INSERT_TIMELIMITS_RFC maintains/writes time limits of an existing
calendar. Together with its objects it can be used as template for writing reports that are used for
generating time limits. It is not possible to change or delete time limits with this function module,
only new lines are inserted in infotype 1750.
© SAP AG
IHE102
2-6
2 . Ac ade m ic Ca lenda r – De adline Chec k ing
The system uses the Academic Calendars to check the timely receipt of
incoming applications, bookings, etc. (deadline checking).
Academic Calendar Sessions
2008/
2009
Fall
Spring
Full Summer
First Summer Second summer
…………
…………
In time?
"I want to
register."
Deadline Rule Checking:
Use Academic Calendar +
Rules & Regulations
accepted
yes
no
rejected
© SAP 2009
A university sets various deadlines for academic and administrative processes, such as:
• Admission deadlines
• Registration deadlines
• Re-registration deadlines
• De-registration deadline
• Module and event booking deadlines
• Fee calculation (e.g. different module booking periods)
If you want the system to automatically check the deadlines in your student administration
processes, you have to create a rule (in a rule container) to check the time limit which depicts the
deadline. Prior to this, you have to define the time limit (= customer-defined time limit).
Exception: For time limit 0300 (module booking), the check is already implemented in the module
booking application.
© SAP AG
IHE102
2-7
2 . Ac ade m ic Ca lenda r Ba sic Conc ept –
Ac adem ic Ca lenda r a nd Acade m ic St ructure
Organization
Organization
(O)
(O)
Module
Module
(SM)
(SM)
Programof
ofStudy
Study
Program
(SC)
(SC)
AcademicCalendar
Calendar
Academic
(CA)
(CA)
Misc.Academic
Academic
Misc.
Work
Work
(CW)
(CW)
Location
Location
(F)
(F)
Bus.Event
EventPackage
Package
Bus.
(SE)
(SE)
Assessment
Assessment
(CE)
(CE)
© SAP 2009
The Academic Calendar (CA) is part of the HR-PD framework. It contains infotypes in which you
can:
• Enter a description
• Add a factory calendar
• Maintain dates
An academic calendar can be assigned to other objects in Student Lifecycle Management. For
example, you can assign an academic calendar to an organizational unit. The programs and modules
assigned to this organizational unit use the attached academic calendar. The relationship used to
assign an academic calendar directly to other objects of the academic structure is always 510.
© SAP AG
IHE102
2-8
2 . Ac ade m ic Ca lenda r Ba sic Conc ept –
Ac adem ic Y ea rs a nd Se ssions
1
An Academic Year describes an annual period to which academic processes refer.
2
Academic Years can be subdivided in several Sessions. Student Lifecycle
Management supports a variety of Sessions (Fall, Spring, Summer, etc.).
Academic Year 2008/2009
Session Variant 1
Fall
Spring
Summer
Start date----End date
Start date----End date
Start date----End date
Session Variant 2
Fall
Spring
Start date----End date
Start date----End date
© SAP 2009
Before you can create an academic calendar, you must make the following settings in Customizing
for Student Lifecycle Management:
• Perform all IMG activities in the section: Master Data in Student Lifecycle Management →
Academic Calendar → Academic Years and Sessions.
– Academic years often reflect calendar years (2008, 2009 or 08/09, etc.).
– Academic sessions subdivide an academic year into intervals that represent the periods of
instruction at a college or university, for example, Fall, Spring, Winter, Summer, 1st
Trimester, 2nd Trimester).
– Each session is unique within an academic year.
– Students can be required to register for each academic year, or for each session within an
academic year.
• Define the top organizational unit in the IMG section: Management Master Data in Student
Lifecycle Management → Academic Structure → Organizational Structure → Define Top
Organizational Unit.
• Define the time limits and time limit sequences that apply for each academic calendar in Master
Data in Student Lifecycle Management → Academic Calendars (see following pages).
• You must have also created a program catalog and mapped the organizational units and programs
in this program catalog.
© SAP AG
IHE102
2-9
2 . Ac ade m ic Ca lenda r Ba sic Conc ept –
Se ssion H ie ra rc hy
A
A session hierarchy can be defined for Academic Sessions.
B
Each higher-level Academic Session can be subdivided into several
lower-level Academic Sessions.
C
Each lower-level Academic Session can have only one
higher-level Academic Session:
Fall Session
Spring Session
Full Summer Session (1st + 2nd Summer S.)
A sequence can be given to lower-level sessions:
Each session which is assigned to one higher-level session can be assigned a
sequence number, e.g., for sorting sessions and lower-level sessions independently of
the academic calendar for printouts, reports etc.
© SAP 2009
The session hierarchy is used to map academic sessions which are used in different contexts, e.g. a
student is allowed to book a module for a lower-level session (1st Summer Session) if (s)he has a
sessional registration for the higher-level academic session (Full Summer Session). This is referred
to as "bottom-up" session mapping, where lower level sessions are assigned to higher level sessions
to create a hierarchy.
In other cases, a resolution of a higher-level session is required in the lower-level sessions assigned
to it. For example, if you want to list the modules booked in an academic session (Full Summer
Session), the modules booked in lower-level sessions (1st Summer Session and 2nd Summer
Session) are included as well.
Optionally, you can assign a sort sequence number to each academic session which you can use for
easy sorting in smart forms. The sort sequence is currently not evaluated in the standard system.
Note: Sequence numbers are not required for Academic Years since the key is numeric and can be
used for sorting directly.
© SAP AG
IHE102
2-10
2 . Ac ade m ic Ca lenda r Ba sic Conc ept –
Se ssion T ype s
Session types are of descriptive character only and have been
replaced by the Session Group
Semester
Fall Semester
Spring Semester
Session
Spring Session
Fall Session
Subsession Summer
1st Summer Session
2nd Summer Session
Examination Period
Summer Examination Period
Fall Examination Period
© SAP 2009
Session types are used to:
• Describe the different kinds of academic sessions (semester, trimester, etc.)
• Each academic session can belong to one session type only.
© SAP AG
IHE102
2-11
2 . Ac ade m ic Ca lenda r Ba sic Conc ept –
Se ssion Group
Definition of Session Groups
Session Groups consist of several sessions that are relevant for
performing a specific process (e.g. Module Booking).
Session Group for Sessional Registration
Spring Session
Full Summer Session
Fall Session
Session Group for Module Offerings
Spring Session
Full Summer Session (1st Summer Session, 2nd Summer Session)
Fall Session
Session Group for Assessment Periods
Summer Assessment Period
Fall Assessment Period
© SAP 2009
Session Groups can be …
• used in Session Variants to define the academic periods for which you can create sessional
registration records for a given Program of Study (=> IMG activity
Processes in Student
Lifecycle Management
Admission, Registration, and De-registration
Basic Settings
Define Session Variants)
• assigned to program types to define the academic sessions for which you can run program type
progression for a given program type (=> IMG activity Processes in Student Lifecycle
Management
Program Type Progression Assign session Groups to Program Types“ for
program type progression).
• used to define in which sessions modules can be booked, if different from the registration session
(=> IMG activity
Processes in Student Lifecycle Management
Module Booking
“Define
session group for Module Booking“. Modules can be scheduled for existing academic sessions.
• created to contain all the sessions for which assessments can be scheduled
(=> IMG activity
Processes in Student Lifecycle Management
Academic Records
Assessments
Scheduled Assessments
“Set Session Group“).
Notes:
• Each academic session can be assigned to several different session groups.
• The sessions of different session types can be assigned to the same session group.
• A session group can consist of higher-level sessions and lower-level sessions (see hierarchy of
sessions).
Business Example: You need to map a program of study with the academic calendar so that a
student can get admission in a particular session in a particular program of study. Approach: You
define a 'Session Group' in the IMG for Registration Periods and assign the session variant to the
relevant Program of study.
© SAP AG
IHE102
2-12
2 . Ac ade m ic Ca lenda r Ba sic Conc ept –
Se ssion V a riant s a nd Se ssions
Examples of Academic Years and Sessions:
Academic year 2008 divided into
Fall Semester
Spring Semester
A
Session Group A -> Session Variant
1
1st Summer
2nd Summer
B
Session Group B -> Session Variant
2
1st Assessment Period
2nd Assessment Period
C
or
or
Session Group C -> Assessment Schedules
3
© SAP 2009
The academic year is the annual period of instruction at an institution. Academic sessions are used
to define the different recognized study periods of the institution.
The academic year and session control various Student Lifecycle Management processes such as
admission, registration, and class scheduling. The primary unit, which is either the academic year or
academic session, specifies the unit of time on which Student Lifecycle Management administrative
processes are based. It controls the registration process, which means:
• If you define the session as the primary unit, the student has to re-register each session.
• If you define the academic year as the primary unit, the student can re-register for each session or
each year.
You can set up different session variants in one client and use them concurrently in different
programs. You must define one session variant per program.
© SAP AG
IHE102
2-13
2 . Ac ade m ic Ca lenda r – T im e Lim it s (1 )
Time limits are
date ranges that indicate the allowed time period (start and end date/time or single dates for
deadlines) for academic and administrative university processes
Time limit sequences are
groups of time limits that form a sequence to be evaluated together (without overlapping of
the time limits within a sequence)
mainly used for student accounting purposes
Priority registration windows are
periods within a time limit in which defined student groups are allowed to book modules
A factory calendar is
used to define country-specific public or university-specific holidays
© SAP 2009
The start and end times of a time limit refer to an academic year and session. It represents a specific
interval of time including date and time, which can be customized.
Time limits can be used for different purposes such as administrative deadlines or the definition of a
start and end dates for an academic year and session.
• Example: Academic year 2008/2009 with the academic sessions fall semester and spring
semester:
Time limit sequences are time limits that form a sequence to be evaluated together without
overlapping.
• Note: Time limit sequences are mainly used in fee calculation.
You can create priority registration windows to allow module booking for defined student groups
within different time periods. After defining a priority registration window in the academic calendar,
you have to assign it to the student in master data to allow a check during Module booking.
• Example: You want students in higher stages or progress classifications (sophomores) to book a
Module before students from lower stages or progress classifications (freshmen) are allowed to
book the module.
You define time limits in IMG at: Student Lifecycle Management
Master Data in Student
Lifecycle Management
Academic Calendars
Define time limits. Time limits which you add
here are included into the drop down list that is available when setting up Academic Calendar data
in the SAP menu.
© SAP AG
IHE102
2-14
2 . Ac ade m ic Ca lenda r – T im e Lim it s (2 )
SAP delivers predefined time limits with a specific meaning:
0100 is a predefined time limit for standard duration of academic sessions. It is used
to define the start and end date of a session or an academic year.
0200 is a predefined time limit for standard lecture time. It is used for event planning.
0300 is a predefined time limit for standard module booking. It is used for evaluation of
priority registration windows during module booking.
The use of time limits (time limit 0100):
Start:
End:
Start:
End:
dd.mm.yyyy
dd..mm.yyyy
dd.mm.yyyy
dd.mm.yyyy
Start and end of session
(0100) Fall Session
Start and end of session
(0100) Spring Session
Academic Year
Academic Session I
Academic Session II
© SAP 2009
Student Lifecycle Management contains the following standard time limits:
Time limit 0100 (mandatory):
• You have to create this time limit for all processes to define the start and end dates of academic
years and sessions. All other time limits are optional. If no specific time limit is defined,
processes always refer to the standard duration of the academic year and session.
• The system determines the time limit through the evaluation path of the academic calendar
(inheritance is possible). You have to define at least one time limit 0100 for each academic year
and session in an academic calendar and attach this academic calendar to the top organizational
unit and other objects in the academic structure.
Class period (0200):
• You use this standard time limit to define the class periods during which the University offers
teaching events. The class period of an academic session can differ from the standard duration of
this academic session. For example, the class period can begin after and end before the academic
session itself. If you do not define any class periods, the system assumes that teaching events can
be scheduled throughout the entire academic session.
Module booking with priorities (0300):
• Some university procedures require different booking periods (= same time limit) for different
groups of students. Example: With priority registration windows, students are assigned to several
groups and each group is allowed to book during a different time window within the same time
limit. In this way, the system ensures that the modules offered in a specific academic session
(defined by the standard duration of the academic session) are booked within the time period
specified in the module booking with priorities time limit. You can also combine the dates and
periods of this time limit with time windows for different student groups. In standard you can use
priority registration windows only for time limit 0300.
© SAP AG
IHE102
2-15
2 . Se t U p Ac a de m ic Ca le nda r – M a int a in
Ca lenda r
Academic Year/
Session
(Preselected)
Enter Time Limit
Sequence
Time Limit
Sequence
Module booking
Time Limit
Prio. Reg.
Window
100% refund for
add/drop
001
Year
2008
Session
Fall
Define Time Limit
Dates (Absolute)
StrtD
ate
End
Date
Ref.
Detail
F2
F1
Select Time Limit
Define Relative
Time Limit
Create Window in Student Lifecycle
Management Student Master Data
© SAP 2009
You can specify whether the start and end dates of a time limit may overlap other time limits of the
same type within the same academic year, or whether a time limit must be continuous within one
session. Example of a non-continuous time limit (time limit with interruption within one session):
• Class period for the Fall session takes place from 08/15/2008 to 08/30/2008 and then again from
09/14/2008 to 09/30/2008.
The settings you make in Customizing define time limits as continuous or with no overlap:
• Continuous time limit
• You may create only one set of start and end dates for this time limit in each academic year and
session. Only the dates of continuous time limits may be used as a reference for relative dates.
Example: Time limit 0100 is a continuous time limit. The start and end dates of the session must
be defined without interruption within a session.
• The system allows interruptions between the 0100 time limits for different sessions. Example:
The summer session starts on 01.03.2005 and goes until 30.10.2005. The winter session starts on
01.12.2005. Note: This configuration is not recommended because errors may occur when the
system attempts to find the appropriate time periods.
• No overlap
• Time limits of the same type may not overlap in all academic sessions specified in one academic
calendar. Example: The two registration periods for the first semester and the second semester
may not overlap in one academic calendar.
© SAP AG
IHE102
2-16
2 . Se t U p Ac a de m ic Ca le nda r – Cust om ize
T im e Lim it
TL..
Time Limit Text
No Overlap
ContTL
0100
Standard Duration of Session
X
X
0200
Class Period
X
0300
Module Booking (With Priorities)
Ref1
Refund Period 1 with 100%
Ref2
Refund Period 1 with 75%
Ref3
Refund Period 1 with 50%
Ref3
Refund Period 1 with 25%
Session (Fall Semester)
Continuous Time Limit
Definition of
Continuous Time
Limit
Non-Continuous TL
Non-Overlapping TL
Definition of No
Overlapping
Overlapping TL
© SAP 2009
Options for setting continuous time limit:
• If you set the ContTL indicator, you may create only one set of start and end dates for this time
limit in each academic year and session. Only the dates of continuous time limits may be used as
a reference for relative dates in the Time Limits/Sequences infotype (1750).
• If you do not set the ContTL indicator, you can create more than one set of start and end dates for
this time limit in each academic year and session. In this case, you may not use the dates of this
time limit as a reference for relative dates.
As mentioned before, SAP delivers three standard time limits (0100, 0200, 0300). The ConTL
indicator is set by default for time limit 0100.
Set the No overlapping indicator if the start and end dates of the time limit must not overlap other
time limits of the same type across all academic sessions or years specified in one academic
calendar.
© SAP AG
IHE102
2-17
2 . Aca de m ic Cale ndar – De fining Tim e Limits
To specify start and end dates for time limits, you
Define the start and end dates as
An absolute date
A date relative to another date
Define the start and end times as
An absolute time
A time relative to another time
Assign time limit start and end dates to an academic session
Link the time limit to a time limit sequence (optional)
Define whether a time limit
May overlap time limits in other academic sessions of the same academic year
Must be continuous within one academic session
Define priority registration windows for time limits
© SAP 2009
You maintain time limits and define their start and end dates in the academic calendar maintenance
transaction (PIQCAM). You can either define absolute time limits or relative time limits. Every time
limit or sequence you create is based on the selected academic year.
To define time limits for a full academic year:
• Enter time limit 0100 in the academic calendar of the top organizational unit for the academic
session that the system should use for full academic years
• In IMG, define the academic session from which the system should derive the start and end dates
when you use full academic years. The system uses this setting if your university allows module
bookings and fee calculations only for full academic years and not for individual academic
sessions:
• IMG for Student Lifecycle Management –> Student Lifecycle Management Master Data –
Academic Calendars – Academic Years and Sessions – Define default session for full academic
year). Note: The academic session you define in this IMG activity is not used in registration
activities.
• If you do not specify an academic session in this IMG activity, the system derives the start and
end dates of full academic years (for module bookings) from the start date of the first session of
an academic year and the end date of the last session of an academic year.
The system also uses the default session for full academic years in Student Accounting. If you use
only full academic years in Student Accounting, you must assign the relevant academic session and
year combinations to the fee calculation periods.
• The fee calculation application uses this academic session to derive the time limits for registered
students, for example, when it determines the due date.
• When you run grant evaluation for full academic years, the system uses this academic session to
determine the dates.
© SAP AG
IHE102
2-18
2 . Ac ade m ic Ca lenda r – Re la t ive T im e Lim its
Relative Time Limits:
A time limit can be defined relative to the start or end date of another time limit (or a
business event or business event package).
Example of a relative time limit:
The add/drop period for a given session begins 4 weeks before the start date of the
session and ends 5 days after that.
The time limit for the add/drop period is defined relative to the start date of the
session.
Reference:
start date of
spring session
Spring Session
Start date
End date
Time
4 weeks before start date
Add/drop period
(Relative start and end date)
5 days
after
start
date
© SAP 2009
You can also enter relative dates for time limits. With relative time limits, you refer to the start and
end dates of another time limit (with absolute dates) or of the start date for a business event or
business event package.
Note: Reference to an event or event package is mainly used for fee calculation, e.g. time limits for
module booking refund - “50% refund if event is canceled 5-10 days before start of event.“
When you define a relative time limit, you:
• specify the number of
– Days
– Weeks
– % of duration (including part day if % result has decimals)
– % of duration (excluding part day if % result has decimals)
• choose a reference for the start date of a relative time limit:
– Start date or end date
– Time limit or event or event package
– Define specific time limit or event or event package
• choose a reference for the end date of a relative time limit:
– Same as for start date
© SAP AG
IHE102
2-19
2 . Ac ade m ic Ca lenda r: Absolut e T im e Lim it s
Example Implementation of
Absolute Time Limits
Time Limit
Time limit
Acad. Year
Valid From
0003 Re-registration
Acad.Year 2008/2009
08/16/2008
Acad.Session
00:00:00
0001 Fall Session
08/30/2008
Valid To
24:00:00
Relative Time Limits
Time Limit (Reference Data)
Start Date
- 4,00
Weeks
1.Start Date
End Date
5,00
Days
1.Start Date
Reference
Time Limit
Time Limit
0100 Period Start and End
© SAP 2009
When you enter absolute time limits in an academic calendar, you have to specify the start and end
dates for each time limit. The start and end dates must be defined as absolute dates:
• Start date (yyyy/mm/dd)
• End date (yyyy/mm/dd)
• Start time (hh.mm.ss)
• End time (hh.mm.ss)
Note:
• The time in relative time limits must be an absolute value.
• Time limits 0100 must be absolute.
Example implementation of relative time limits:
• Time Limit: Add/drop for a given year/session
• Start time: 08:00:00
• Number (start): -4
• Unit (start): weeks
• Reference point for period (start): Start date
• End time: 17:00:00
• Number (end): 5
• Unit (end): days
• Reference point for period (end): Start date
• Reference time limit: 0100: Standard duration of the same year/session
© SAP AG
IHE102
2-20
2 . Ac ade m ic Ca lenda r – T im e Lim it Se que nc e s
for St udent Acc ount ing
Academic
Calendar X
Module 1
TIME LIMIT SEQUENCE = Add/Drop Module Bookings
Academic Year – Session - from date (yyyy/mm/dd) to date (yyyy/mm/dd)
Time Limits:
start date
end date
Time Limit 1:
100% refund
start date
end date
Time Limit 2:
80% refund
start date
end date
Time Limit 3:
50% refund
start date
end date
Time Limit 4:
20% refund
> date
Time Limit 5: no
refund
© SAP 2009
A time limit sequence is a time period which is subdivided into separate but continuous time limits.
Time limit sequences are automatically evaluated in Student Accounting. You can use them for fee
calculation. When the system calculates fees, it reads the time limit sequences to determine the time
limit within which a specific date falls.
Time limit sequences group several different time limits into one logical group. The time limits
within a sequence are evaluated in the order specified. No interruptions are allowed between the
time limits of one sequence.
You can set up time limit sequences according to your individual requirements. A time limit can be
assigned to one time limit sequence only once. Examples for time limit sequences and time limits
within fee calculation are:
• Time limit sequence: Add/drop modules (during this period, module bookings are allowed)
• Time limits within this sequence:
– Add/drop: 100% refund if a module is dropped
– Add/drop: 80% refund if a module is dropped
– Add/drop: 50% refund if a module is dropped
– Add/drop: 20% refund if a module is dropped
– Add/drop: no refund if a module is dropped
• The system calculates the refund amount according to the time limit during which the student
cancels the module booking.
© SAP AG
IHE102
2-21
2 . Ac ade m ic Ca lenda r – T im e Lim it 0 3 0 0
(M odule Book ing)
Priority registration windows are used to define different
module booking periods for different groups of students.
W1
ALL
W2
W3
Time Limit
Window
Year
Session
Start Date
End Date
Priority Reg.
W1
2008/2009
Fall
.yyyy/mm/dd
yyyy/mm/dd
Priority Reg.
W2
2008/2009
Fall
yyyy/mm/dd
yyyy/mm/dd
Priority Reg.
W3
2008/2009
Fall
yyyy/mm/dd
yyyy/mm/dd
Priority Reg.
....
2008/2009
Fall
yyyy/mm/dd
yyyy/mm/dd
© SAP 2009
Dates of different priority registration windows may overlap. If you use a window in other time
limits than 0300, the priority registration window must be evaluated via VSR or customer
enhancement during module booking.
The priority registration window in which modules can be booked is assigned to the student in his or
her master data (infotype 1705, “Individual Study” data tab). These priority registration windows
need to be maintained in the time limits of the academic calendar.
You can activate and deactivate the check for priority registration windows in Customizing for
Student Lifecycle Management under Student Lifecycle Management Processes
Module Booking
Configure Check for Observance of Booking Periods. You can activate this check for the
following callup points:
– Callup point 0001 (module booking (general))
– Callup point 0003 (module booking (single))
• The priority registration windows are assigned to time limit 0300 (module booking). The system
automatically checks the priority registration window only for time limit 0300 when students
book modules.
• Priority registration windows can overlap or have interruptions within an academic session in one
calendar. A time limit 0300 with a blank window is considered as applicable for all students
• You can define as many priority registration windows for a time limit as required.
If you use priority registration windows, you must define time limits for the whole booking period,
otherwise periods in which no priority registration windows are defined are not open for booking.
Note: Booking windows for registration can be assigned via the report “Mass Assignment of
Booking Windows“: SAP Menu
Student Lifecycle Management Student Administration
Mass Processing Functions PIQBKGWINDOW - Assign Booking Window to Student.
© SAP AG
IHE102
2-22
2 . Ove rview : T im e Lim it s a nd T im e Lim its
Se que nc e s
Calendar with Time Limits
TLSq
...descrip
tion
TLmt
...text
Session
...name
Start date
End date
From
To
0100
Start and end
of session
1
Fall
Semester
Oct/01/08
Mar/31/09
00:00
24:00
0100
Start and end
of session
2
Summer
semester
Apr/01/09
Sep/30/09
00:00
24:00
0100
Start and end
of session
1
Fall
Semester
Oct/01/08
Mar/31/09
00:00
24:00
...
...
...
...
...
...
Calendar with Time Limit Sequences
TLS
q
...description
ADR
Add/Drop Refund
ADR
Add/Drop Refund
ADR
Add/Drop Refund
ADR
Add/Drop Refund
TLm
t
...text
ADR1
Add/Drop Refund-100
ADR2
Add/Drop Refund-75
Session
...name
Start date
End date
From
To
1
Fall
Semester
Oct/01/08
Oct/31/08
00:00
24:00
1
Fall
Nov/01/08
Nov/31/08
00:00
24:00
Dec/01/08
Dec/31/08
00:00
24:00
Jan/01/09
Jan/31/09
00:00
24:00
Semester
ADR3
ADR4
1
Add/Drop Refund-50
Add/Drop Refund-25
Fall
Semester
1
Spring
Semester
© SAP 2009
© SAP AG
IHE102
2-23
2 . Ac ade m ic Ca lenda r – Eva lua tion Pa th
Note:
Top Org Unit
The calendar
assigned to the
Top Org Unit
must have TL
0100 defined for
all sessions!
Org. Unit 1-n
Program of Study
Module
Module
Section A
Section B
Top-down inheritance of academic calendar dates
Higher-level (time limit) entries can be overridden by lower-level entries
When looking for an applicable calendar (time limits), the system searches bottom up
using the defined evaluation path
Delivered evaluation path contains the following options according to the lowestlevel start object:
Event Package – Module – Org. Unit – Org. Unit
Assessment - Module – Org. Unit – Org. Unit
Assessment - Program of Study – Org. Unit – Org. Unit
Misc. Acad. Work - Org. Unit – Org. Unit
© SAP 2009
You should never change evaluation paths created by SAP! You create (customer-specific)
evaluation paths in the Customizing for Student Lifecycle Management
Master Data
Academic Calendars
Maintain Evaluation Paths for Academic Calendar.
When you create evaluation paths, do not set any skip flags, and enter * as the priority. Evaluation
paths should have a bottom-up structure, for example, module program organizational unit.
• Skip: In this field, you specify that a certain relationship in an evaluation path is to be used to
proceed to other objects without evaluating the intermediate objects themselves.
Avoid creating evaluation paths where a given object has relationships to objects of different types
(except the CA object type) as the system only takes into account the objects of the first object type.
If the system finds several objects with the same object type at one level, it uses the object with the
priority “1” in the evaluation path. If none of the objects have the priority “1”, the system uses the
first object it finds.
After creating the evaluation paths, you have to assign the evaluation paths to call up points. You
can use different evaluation paths to determine academic calendar objects at each of the given call
up points. Note: The standard evaluation path is used if no call up point is assigned.
SAP currently provides three different call up points for evaluations paths (defined in table
T7PIQCHECKTP in transaction se16):
• 0001 - Module booking (general)
• 0003 - Module booking (single)
• 0201 - Calendar determination in event planning
© SAP AG
IHE102
2-24
2 . Aca de m ic Cale ndar– Sta nda rd Eva lua t ion Pa t h
Other evaluation paths will
likely be necessary for specific
academic structures and
processes. Therefore, you can
define customer-specific
evaluation paths.
O
O
O
O
CW
SC
CE
CE
CE
CE
SM
SC
v
v
SE
FF
© SAP 2009
Academic calendars are evaluated for a given start object (SE, SM, CW, CE, SC, F or O) along the
defined evaluation paths depending on the process.
If the system does not find the time limit required by the process, it derives the next available
academic calendar (CA) along the evaluation path.
The dates (time limits) specified in the academic calendar are inherited by the lower-level objects.
When you create a new academic calendar for a lower-level object, you override the time limits for
the same academic year and session of the higher-level object.
The evaluation path which you can define in Customizing is used to derive the relevant academic
calendar for a certain process and object. The evaluation path can also include object types to which
you cannot directly assign an academic calendar object (e.g. module groups).
In the IMG activity Customizing for Student Lifecycle Management
Master Data
Academic
Calendars
Define General Evaluation of Academic Calendars you can make a setting that ONLY
the top-org calendar is used. Please view the documentation at this IMG activity for more details.
Usually the evaluation path itself should be set to PIQCASTD. Depending on the object in the
context of the activity and/ or call-up point it will then derive the time limits in the calendars in an
hierarchical order starting from the program of study, module, event package, CE, ...).
• Business example: for a student registration to a program, the calendar evaluation will start with
the program of study and then evaluate the organizational hierarchy below the program.
© SAP AG
IHE102
2-25
2 . Ac ade m ic Ca lenda r – Fa c tory Ca le ndar
Use of the Factory Calendar within the Academic Calendar:
The Factory Calendar is used to determine the days off.
The system evaluates the first Factory Calendar it finds in the evaluation path.
If it does not find a Factory Calendar in the specified evaluation path, it uses
the default calendar for the client/system.
Acad.
Acad. Calendar
Calendar
How to maintain the Factory Calendar:
The ID of the Factory Calendar can be stored in the Site-Dependent
infotype (1027) of the Academic Calendar.
The Factory Calendar can be defaulted for the client.
© SAP 2009
The SAP standard factory calendar (from HR) can be used for academic calendars.
The factory calendar is used to define public or university-specific holidays which in turn can be
recognized by event planning.
Factory calendars can, e.g., be used for lengthier interruptions within a given time limit.
Example: The “teaching time” time limit for the 2008/2009 fall session goes from 08/16/2009 to
12/31/2009. Christmas holidays from 12/23/2009 to 01/07/2010 are maintained in the factory
calendar.
The system uses the first factory calendar it finds in the evaluation path to determine the days off. It
does not take into account the factory calendars assigned to higher-level objects of the academic
structure. If the system does not find a factory calendar in the specified evaluation path and no
factory calendar is assigned to the top organizational unit, it uses the default calendar for the client
(administered by Training and Event Management - TEM).
© SAP AG
IHE102
2-26
2 . Ac ade m ic Ca lenda r – Sum m a ry Ove rvie w
To create a new Academic Calendar you:
•1
Set up Academic Years and Sessions
•2
Create the Academic Calendar object
•
Define the relationships between the Academic calendar and other
objects (Organizational Unit, Program of Study, Module or Event
Package)
3
•4
Enter a brief description
•5
Choose site-dependant info to define a relevant Factory Calendar
•6
Specify the Time Limits and (if required) Time Limit Sequences
•7
Enter dates for each time limit or Academic Session combination
© SAP 2009
SAP SLCM includes BC sets which support the implementation of an Academic Calendar. Please
refer to the cookbook stored in the BPX for details: https://www.sdn.sap.com/irj/bpx/highered
Student Lifecycle Management Best Practices, Implementation Guidelines, and Tutorials
Base
IMG Configuration Cookbook.
To create an academic calendar, you first have to make the required customizing settings and assign
the academic calendars to allowed objects:
• Define standard evaluation path: You must define the standard evaluation path for the academic
calendar. You can use different evaluation paths to determine academic calendar objects. The
system uses the standard evaluation path delivered by SAP if no other evaluation path is assigned
to the predefined callup points.
• Maintain evaluation paths: You assign evaluation paths to callup points. You can use different
evaluation paths to determine academic calendar objects at each of the given callup points. You
can only assign evaluation paths to the callup points which are designated as relevant for the
academic calendar in table T7PIQCHECKTP in transaction se16.
2. Create the academic calendar. Relevant BC Set which includes settings for steps 1-6:
ISHERCM_IAP_ACAD_CALENDAR (see link for cookbook given above).
• Define academic years. IMG Path: Academic Years and Sessions
Define Academic Years.
• Define session types: IMG Path: Academic Years and Sessions
Define Session Types.
• Define academic sessions. IMG Path: Academic Years and Sessions
Define Academic
Sessions
• Set up session groups. IMG Path: Academic Years and Sessions Set Up Session Groups.
• Assign Academic Sessions to Academic Years. IMG Path: Academic Years and Sessions Assign Academic Sessions to Academic Years.
• Define time limits and time limit sequences in the academic calendar: Maintain concrete start and
end dates, start and end times per time limit and optionally per window. IMG Path: Define Time
Limits.
© SAP AG
IHE102
2-27
2 . Ac ade m ic Ca lenda r – U nit Sum m a ry
You are now able to:
Explain the concept of Academic Years, Sessions, Session Groups,
Time Limits, Time Limit Sequences, and Priority Registration Windows
Explain the concept of Academic Calendars
Set up Academic Years and Academic Sessions in preparation for using
the Academic Calendar
Set up Session Groups for use in different contexts
Create and maintain an Academic Calendar
Integrate an Academic Calendar in the Academic Structure
© SAP 2009
© SAP AG
IHE102
2-28
I H E1 02 St udent Lifec yc le M anagem ent :
3 . Eve nt Pla nning and Cla ss Scheduling
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009
© SAP AG
IHE102
3-1
3 . Eve nt Pla nning
Content:
3.1 Fundamentals of Event Planning
3.2 Event Planning Processes
3.3 Templates for Event Planning
3.4 Teachers’ Workload
3.5 Event Planning with Cohorts
© SAP 2009
© SAP AG
IHE102
3-2
3 . Eve nt Pla nning – U nit Obje c t ive s
At the conclusion of this unit, you will be able to:
Understand the correlation between Academic Structures and
Event Planning
Use the Event Planning tools
Set up different planning scenarios
(Regular – Irregular, Time-Independent Events)
Simplify the regular Event Planning process
(Templates and Copy of Schedules)
Monitor the Teaching Workload of your staff
Provide clash-free timetables for groups of students
(Event Planning with Cohorts)
© SAP 2009
© SAP AG
IHE102
3-3
3 . Eve nt Pla nning – Busine ss Sc ena rio
You advise academic planners on how to map academic
schedules in the system by using Event planning objects
You help to plan Events and schedule resources
You build and test planning scenarios
© SAP 2009
© SAP AG
IHE102
3-4
3 .1 Funda me nt a ls – T opic Obje c t ive s
At the conclusion of this topic, you will be able to:
Understand the basic concepts and settings of Event Planning
See the correlation between objects of the Academic Structure and
the resource objects in Event Planning
Understand the function of the different Event Planning scenarios
© SAP 2009
© SAP AG
IHE102
3-5
3 .1 Funda me nt a ls – Ove rvie w
Event Planning with Student Lifecycle Management allows you to:
Create and store planning-relevant data of permanent character:
Include planning data into the Academic Structure
Work with templates and copy timetables
Schedule Events with various schedule patterns:
Regular schedule and irregular schedule,
Regular schedule with exceptions,
Events without a schedule
Integrate Resource Management
Integration with Room Reservation
Track teachers‘ workload and integrate with HR – Funds and Position Management
© SAP 2009
Student Lifecycle Management Event Planning functions are tailored to the needs of universities.
The planning tool focuses on the academic structure of Student Lifecycle Management and provides
a specific user interface for the planning procedure.
The Training and Event Management component provides the basic functionality to plan Events.
Furthermore, universities often need to reserve rooms for purposes other than teaching Events. The
room reservation component enables you to reserve rooms without having to plan Events.
Note: Room Reservation can be used in Event Planning only if integration is activated between
room reservation and Training and Event Management.
• Several switches influence Event Planning. All switches can be set in Customizing using the
menu path: SLCM
Master Data in SLCM
Academic Structure Integration of Training
and Event Management
Training and Event Management.
• The possibility to maintain the teachers’ workload helps to better plan and allocate staff
resources.
© SAP AG
IHE102
3-6
3 .1 Funda me nt a ls – Da t a M ode l Event Pla nning
Business Event
Type (D)
is a generalization of
is held by
External Person
(H)
is held by
Person
(P)
Event
(E)
takes
place in
Location
(F)
belongs
to
requires
Resource Type
(R)
Resource
(G)
is a generalization of
© SAP 2009
The Student Lifecycle Management Event Planning process uses some of the master data of
Training and Event Management (TEM), e.g. Event Types, Events, Resource Types and Resources
such as rooms, external instructors, materials, etc. It shares some master data with Room
Reservation Management
The Event Type (D) and Event (E) objects are used both in Student Lifecycle Management Event
Planning and in Training and Event Management.
The Resource Type (R), Resource (G), and Location (F) objects are used in three applications:
Room Reservation Management, Training and Event Management, and Student Lifecycle
Management Event Planning.
Although it is possible to plan Events in TEM and in Student Lifecycle Management, you should
never plan Student Lifecycle Management Events using the TEM functionality! Use the Event
Planning function in Student Lifecycle Management to plan and schedule your Events. Events you
create in TEM are automatically valid for the whole client (TEM and Student Lifecycle
Management Event objects are the same), but Events created in TEM are not visible in the Student
Lifecycle Management Academic Structure.
Student Lifecycle Management offers two planning views:
• The first planning view focuses on “permanent objects” within the Event Planning process.
Relevant for this view is the academic structure with Study Modules (SM). The next level is the
Business Event Type which keeps all relevant data for the scheduling. In addition, Event
Packages can be created as permanent objects. This planning view focuses on a long-term data.
• The second planning view focuses on the scheduling which takes place in every Academic
Session. It works with the creation of Events or Time-independent Events.
• The Student Lifecycle Management system supports your scheduling work with features like
copy roll forward functions, templates or offering patterns, which are blueprints for the planning
process.
© SAP AG
IHE102
3-7
3 .1 Funda me nt a ls – Eve nt s
1)
The Business Event Type (Object Type D)
serves as the blueprint for Events (Object
Type E). You can create one or more
Events from one Business Event Type.
D
E
2)
The Business Event Type (D) also serves as
blueprint for Time-independent Events (EL).
These Events do not have a schedule and can be
used to plan Self-Study offerings.
E
E
D
EL
3)
A Time-independent Event can also be used
to map Event offerings which do not yet have
a time schedule. The Event is first created as
a Time-independent Event (EL) and later
changed to a Event (E) when a schedule and
resources are assigned.
D
EL
E
E
© SAP 2009
1) Business Event Types serve as blueprints for:
• Events
• Time-independent Events
Different Business Event Types must be created to map different Event aspects, such as:
• Resources
• Time Schedule
• Delivery Mode
Example:
• An Event is an academic offering (e.g. lecture) with set start/end dates and can be held on a
single date
• or a set of fixed dates. A Business Event Type serves as blueprint for the following Event:
Lecture A
• is held on Monday 8-10 a.m. and Wednesdays 1-3 p.m. at different locations in the fall semester,
and
• uses different resources (on Monday: Room WD100 and instructor Miller, on Wednesday: Room
• MA100 and instructor Brown).
2) The Time-Independent Event does not have schedules or resources, however, an instructor can be
assigned. It can be used in two ways:
• a) To create a self-study course (e.g. distance learning course).
• b) To create a “temporary“ course where the schedule is undetermined. Once the schedule is
confirmed the dates may be added. The object changes from EL to an E and the relevant
resources can be assigned.
Note 1: To create a time independent Event for self-study purposes, the relevant delivery mode (e.g.
distance learning) must be specified on the Business Event type. Once this delivery mode has been
assigned it is not possible to change the time-independent Event to a “normal” Event. Therefore:
Ensure that a time-independent delivery mode is not assigned to these “temporary“ EL Objects.
© SAP AG
IHE102
3-8
3 .1 Funda me nt a ls – Eve nt Pa cka ge s
Event Packages are used to bundle several Events.
Events
Module 3 – Exp. Physics I
1.
Lectures in Exp. Physics
2.
Event Types
Lectures in Exp. Physics
Exercise in Exp. Physics
SE
Event
Package
Exercise in Exp. Physics (1)
Exercise in Exp. Physics (2)
3.
e-learning in Exp. Physics
© SAP 2009
Event Packages bundle Events together and can be part of a module or a Business Event Type. The
Event Package can either be a reusable, long-lived object or a short-lived object which is used only
for one Event Planning session. The Event itself is created anew in each Event Planning period
In the example above, the Business Event Types (1) and (2) are blueprints for compulsory Events
which students must attend when the Module is booked. A student must therefore attend one Event
assigned to each Business Event Type in order to complete the Module.
Example: a student must attend the “Lectures in Exp. Physics” and “Exercise in Exp. Physics” in
order to fulfill the requirements of the Module. The Lecture and Exercise are represented by two
different Event objects.
Event Packages are generally assigned to Modules and inherit the Sessions of Offerings specified at
the Module level.
Through Event Packages you can do the following:
• Book several academic offerings at once instead of having to book each separately.
• Organize academic offerings (e.g. tutorials, lectures, exams, etc.) for different learning objectives
or for different instructors.
• Set tuition fees for the offerings listed under Modules. They therefore make it possible to define
different fees for different Event Packages.
• Define booking rules in Rule Containers per package.
• Define the Campus at which an Event Package is held.
• Maintain an Academic Calendar for the Event Package.
• Maintain capacities per Event Package.
• Maintain a pattern per Event Package.
© SAP AG
IHE102
3-9
3 .1 Funda me nt a ls – M odule & Eve nt T ype
At t ribut e s
Attributes for Modules (SM) or Business Event Types (D) and their impact on
related processes:
Attribute
Function
Capacity
Checked during Module “& Event booking
Session Pattern
Blueprint for future offerings (SM level). Example: “every Spring“
Sessions of Offering
Prerequisite for current offerings (SM level). Example: “Spring 2008“
Schedule Category
Manages scheduling (D level). Example: “Regular Schedule – Irregular Schedule“
Category
Defines type of Event offering, such as Teaching Method, Delivery Mode.
Example: “Category“ = Lecture. “Teaching Method“ = Teacher Centered, “Delivery
Mode“ = Classroom Instruction
Teaching Workload
Specifies Contact Hours and Teaching Effort (D level).
“
Attendance Tracking
If flagged, student attendance for that specific Business Event is tracked.
© SAP 2009
Capacity: Important for booking procedures. Messages are sent if capacity limits are exceeded.
Session Pattern: The session pattern is a blueprint used to create the academic sessions in which
modules and business Event types are offered (for example, summer session pattern for all modules
offered in the summer semester). A pattern can be assigned to one or more academic sessions and
have a specific validity start date for the Module or Business Event type.
Session of offering: The session of offering needs to be maintained before Events can be scheduled
or Modules can be booked. It refers to the academic sessions maintained in the Academic Calendar.
Schedule Category: When scheduling an Event, you can predefine the type of schedule: Choose
between regular – irregular – without schedule. The system offers you various ways to enter data.
Category (D): controls how the content of Modules, Business Event Types, and Individual Work is
offered.
Category (SM): Category of a Event, such as lecture, tutorial, lab, seminar, etc.
Teaching Method: The teaching method describes the learning architecture of Business Event Types
(classroom instruction, distance study, project work, etc.).
Delivery Mode: The delivery mode describes how the content of an academic offering is organized
and whether you need to create an Event or a time-independent Event in the system.
Teaching Workload: You can specify contact hours and allocate teaching effort to various instructor
activities, for example, class preparation, research project, lecture teaching.
IMG path for customizing settings of the above data: SLCM Master Data in SLCM
Structure
Modules / Business Event Types / Individual Work / Teaching Workload
© SAP AG
IHE102
Academic
3-10
3 .1 Funda me nt a ls – Capac it y
CAPACITY: Minimum / Optimum / Maximum may defined at different levels.
Modules (SM)
Evaluated during Module Booking. Triggers Waitlisting.
Event Packages (SE)
Evaluated during Module Booking. Message if capacity exceeded.
Event Types (D)
Default for capacity at Event level.
Events (E)
Evaluated during Event Booking. Message if capacity exceeded.
Rooms
Taken into account during Event Booking.
Default Names of
Events or Event
Packages
Event Planning BADI is provided to set e.g. default abbreviation and
description
User-Defined
Validation
Event Planning BADI is provided for User-Defined Validations (e.g.
to check if Room and Event capacities are compatible).
Module Capacity
Check
Switch is provided in customizing to exclude Module capacity check.
© SAP 2009
Optimum and maximum capacity is taken into account primarily during the booking process. If the
optimum or maximum capacity is exceeded for Events, Event Packages or Modules, the system will
generate an information, warning or error message to the user. The minimum capacity of all objects
has a minor impact and it is not evaluated by the system.
Modules: The capacity values at the SM are used in cases where booking limits are required on the
SM level. The waitlist functionality evaluates the SM capacity (see chapter “Module Booking“).
Event Packages: The capacity values at the SE are evaluated during SE booking.
Event Types: The capacity maintained at the Event Type is defaulted to the relevant Events (E).
Events: Optimum and Maximum capacities are used for Event booking. The capacity is determined
using the minimum value of the Event and the room.
Via the “Booking Priority“ (value kept on the booking relationship) you can allow or prevent
bookings above the optimum capacity.
Rooms: Capacity may affect the number of potential bookings for the Event assigned to that room.
Note: In the advanced resource allocation, the system also uses the optimum capacity to find the
“best“ room for a Event. The system proposes the available rooms first which have a similar
optimum room capacity as the optimum Event capacity.
Default Names of Events or Event Packages: IMG for SLCM
Master Data in Student Lifecycle
Management
Academic Structure
Event Planning Business Add-Ins (BAdIs)
BAdI:
Default Names of Events or Event Packages.
User-Defined Validation: IMG for SLCM
Master Data in Student Lifecycle Management
Academic Structure
Event Planning Business Add-Ins (BAdIs) BAdI: User-Defined
Validations for Event Planning.
Module Capacity Check: IMG for SLCM
Processes in Student Lifecycle Management
Module Booking
Exclude Capacity Check at Module Level
© SAP AG
IHE102
3-11
3 .1 Funda me nt a ls – De live ry M ode s
The Delivery Mode of the Business Event Type (D) determines whether the
system creates:
Time-independent Events (EL) or
Events (E)
TIMEINDEPENDENT
Events
Events
Take place on specific dates
Do not have a schedule
Require Resources
Do not require resources
Object validity is influenced
by a schedule
Object validity is not influenced
by a schedule (long-lived object)
Do not have capacity limits
Have capacity limits
Are location-independent
Take place at specific locations
Have content changes over time
© SAP 2009
The academic offerings of a university consist of Events and time-independent Events. You create
and schedule Events and time-independent Events when you set up Event offerings. Students can be
booked for both offerings once they are available in the system.
When you create an offering (E or EL), the system proposes only those Business Event Types that
have the appropriate delivery modes. Apart from the Business Event Type data, which the system
uses as a blueprint when you create an offering, you must enter additional data such as location,
schedule, required resources, etc. if you are creating an Event.
You maintain the delivery modes in Customizing for Student Lifecycle Management using the path:
SLCM
Master Data in SLCM
Academic Structure
Business Event Types
Create
Delivery Modes.
© SAP AG
IHE102
3-12
3 .1 Funda me nt a ls – T opic Sum m a ry
You are now able to:
Understand the basic concepts and settings of Event Planning
See the correlation between objects of the academic structure
and the resource objects in Event Planning
Understand the function of the different Event Planning scenarios
© SAP 2009
© SAP AG
IHE102
3-13
3 .2 Eve nt Pla nning Proc e ss – T opic Objec t ive s
At the conclusion of this topic, you will be able to:
Understand the different aspects of the Event Planning process
Use the Event Planning transaction
Select and assign Resources to Events
Cancel Events
© SAP 2009
© SAP AG
IHE102
3-14
3 .2 Eve nt Pla nning Proc e ss –Proce dure s
SM
1
D
E
2
D
EL
D
E
D
E
SE
3
4
D
SE
E
© SAP 2009
The system offers different procedures for Event Planning.
Business Event Types are required to plan Event offerings.
The Module (SM) is always used as the basis for Event Planning.
There are different ways of creating academic offerings:
• You can create an Event Package only (Note: Business Event Types are not required for this
option).
• You can create Event Packages with Events or time-independent Events. This procedure is
preferable to the others because the system automatically creates a relationship between the SE
and E Objects.
• You can create Events only directly from Business Event Types, with or without resource
allocation. If you do not select a schedule, the system automatically creates a time-independent
Event representing an Event w/o a schedule. When you enter a schedule at a later time, the
system changes the time-independent Event to a scheduled Event.
• You can create Events without a schedule.
• You can create time-independent Events.
© SAP AG
IHE102
3-15
3 .2 Eve nt Pla nning Proc e ss – Sc he dule Type s
Event Planning with different types of schedules:
1. Regular Schedule
each Friday 8-10, start 5th of May 2009, duration 10 weeks, room PE.01, Prof. Scott
2. Irregular Schedule
Irregular
Regular with exceptions
Fr. 5/5 8-10 am,
Fr. 5/12 11-12 am,
….
Every Friday 8-10, starts 5/5,
but not on 5/12/2009
3. Without Schedule
Schedule is added later
Event does not need a schedule
E-Learning exercise for self study
Object Type EL
Event name, description etc.;
Object Type EL => E
© SAP 2009
SLCM supports the planning of Events with different schedule types in order to allow easy
maintenance. The difference between schedule types is reflected by the attribute “Schedule
category”.
1) Regular Schedule: For regular Events, the dates that characterize the schedule are stored in a way
that minimum data has to be entered. You have to enter
• Week day, time, start date (relative to an academic session or exact date), no. of occurrences. The
system will create a timetable from this data.
• Resources can be assigned for each occurrence.
2) Irregular schedule: these are Events with irregular schedules or with exceptions.
• Example: an Event takes place on specified days during a term at varying times in varying
rooms. Every date needs to be entered manually. When creating such an Event, you specify that
it is an irregular Event.
• To create regular Events with exceptions: You use the schedule category for “regular schedules”.
Enter exceptions from the automatically created timetable.
3) Without schedule
• 3a) Schedule is added later as it is not known yet:
– If you plan the Event before the schedule is known, choose category “Business Event without
schedule” when creating the Event. The schedule is added later with the editing mode of the
Event planning transaction by choosing the Schedule Business Event pushbutton. Technically,
first an Object Type EL is created. Once a schedule is added, EL is turned into an Event
(object type E).
• 3b) Event does not need a schedule as it is a Time-independent Event:
– Select schedule category “time-independent Event”. Make sure an appropriate delivery mode
is maintained at the Event Type (e.g. e-learning). In this case, object type EL does not turn
into an E.
© SAP AG
IHE102
3-16
3 .2 Eve nt Pla nning Proc e ss – T ra nsac t ions
Create and
Edit Event
Templates
Object Type
for Event
Selection
Filters for
Event display
Worklist
Modules, Event Types, Events and
Packages corresponding to the selected
Access Object are displayed using the
[Find] pushbutton
Working Options
•Schedule Events
•Create, Edit, Delete and Cancel Event
Offerings.
© SAP 2009
The Event Planning transaction offers a single point of access to perform all tasks around Event
Planning after the necessary preparations, such as Customizing entries and creation of the Academic
Structure have been completed.
• Events may be selected for various Object Types, such as Modules (SM), Program of Study (SC),
Event Type (D), etc.
• Various parameters and filters are provided for data selection, such as “Processing Status”,
“Campus”, “Firmly Booked”, “Planned Event”.
• The “Processing Status” is a customer-defined and can be used to indicate the progress of the
Event Planning process. This status does not affect any Student Lifecycle Management functions.
Notes:
• You can edit Event offerings in the specially designed transactions: Student Lifecycle
Management → Event Planning → Edit Event Offering (PIQACADOFFER00) and Edit Event
Offerings for Cohorts (PIQACADOFFER01), as well as in the Module Catalog
(PIQACCATLG). Note that not all functions are available in the Event editing interface of the
Module Catalog. For example, in the Module Catalog you can not edit the schedule description.
Furthermore, the Module Catalog does not offer list display or mass processing functions.
• You can access an alternative Event Planning view via the Module Catalog using the Icon “Edit
Event Offering”.
• You can link the Module Catalog to the ‘expert’ event planning view with the following IMG
setting: SLCM Master Data in SLCM Academic Structure Event Planning Use
Expert Mode from Module Catalog. In standard, transaction PIQACADOFFER00 is called by the
system.
© SAP AG
IHE102
3-17
3 .2 Eve nt Pla nning Proc e ss – Furt he r
I nform a t ion
Create Events with status Planned – Firmly Booked
You can decide to create an Event either in status “Planned“ or “Firmly Booked.“
Follow-up processing is only possible for firmly booked Events.
Once an Event is firmly booked, it cannot be changed back to Planned.
Options for creating Events and Event Packages:
© SAP 2009
You can create an Event in one of two statuses: “firmly booked“ or “planned“. If you do not intend
to use the planned status, create the Event directly in “firmly booked“ status:
• The status “firmly booked“ applied to Events corresponds to the “active status“ applied to
Objects and infotypes in Personnel Management.
• The Event must be in “firmly booked“ status before you can carry out follow-up processing, or
use activity allocation and billing functions for it.
• When you create an Event with the “planned status“, the following functions are available when
you later change the status to “firmly booked“:
– In Customizing for Training and Event Management, in the step “Control Data“, you can
specify whether unplaced bookings on the waiting list are converted into prebookings for the
Event Type or remain on the waiting list as rebookable attendees.
– When an Event is “firmly booked“, you can specify that this action automatically triggers the
output of a final confirmation to the attendees booked for the Event.
• If you have created an Event Package, you can afterwards choose the line which contains the
Event Package to create an Event. In this case, the Event will be related to the Event Package.
• If you do not want the new Event to be related to the Event Package, you have to select a line
without a Package.
© SAP AG
IHE102
3-18
3 .2 Eve nt Pla nning Proc e ss – Re source
Assignm ent s
Resources can be assigned to Events in two ways:
Planned Resources:
Temporary Resources:
The Event Type stores the
required Resource Types.
The Resource Type contains the
necessary Resources for the
Event.
Concrete resources are selected
when planning the Event.
Temporary Resources (which are
not defined by the Resource
Types) can be assigned directly
to an Event.
Temporary Resources can be
assigned by using the userdefined ”Free Search“ when
selecting Resources.
=>Example: all persons related to a
business Event type via relation
”is held by.“
=>Example: the Event Type has no
assigned Instructors. But in this
case, you wish to add an
Instructor directly to the Event.
See customizing settings!
© SAP 2009
Event Types define required resources via Resource Types. These resources are assigned during the
Event planning process.
• To allow User-defined search for Resources and define standard Resource Types for rooms and
instructors go to the Customizing section for Student Lifecycle Management under: Student
Lifecycle Management Master Data
Academic Structure
Event Planning Integration of
Training and Event Management
Training and Event Management
Business Event
Preparation.
Resource Assignment:
• In order to see the resource assignment,
– click “Show Resources” in the worklist of the Event editing screen, or
– go to the detailed screen by editing the Event or displaying the Event. Then you can see the
assigned instructor for a particular date and period.
For more information about resources and resource assignment, please refer to course HR515
“Training and Event Management”.
© SAP AG
IHE102
3-19
3 .2 Eve nt Pla nning Proc e ss – Cance l a n Eve nt
When you need to cancel an Event:
Do not delete! Instead cancel the Event to keep track of the history
Use the Event Planning transaction to cancel the Event
It is not possible to cancel an Event if student bookings exist. They
must be cancelled before.
=> Resources will be unassigned
=> Status of the Event will be set to cancelled
When you cancel an Event Package or Module:
Related Events are deleted (not cancelled!)
© SAP 2009
You can cancel an Event via the Event planning transaction PIQACADOFFER00 or SAP menu
Student Lifecycle Management → Academic Structure (Curriculum) → Event Planning → Edit
Event Offering in the Student Lifecycle Management menu.
When you cancel an Event, the Event is set to status “cancelled”.
When you cancel an Event Package or a Module, all Events related to the Event Package or Module
are deleted – not cancelled! – and the Session of Offering is removed.
A report is available to transfer bookings from one Event to another (or mass cancel the bookings)
which you can perform before you cancel an Event: SAP Menue Student Lifecycle Management
Student Administration
Mass Processing Functions
PIQMPMODBKG - Transfer Student
Bookings
© SAP AG
IHE102
3-20
3 .2 Eve nt Pla nning Proc e ss – H ow t o
Event Planning is carried out via several steps:
Part I: Preparation
Long-living objects and planning data is defined: You create Modules and Event
Types within the Academic Structure after you have completed the appropriate
customizing. Academic Calendars must be prepared and Modules must be offered
before the scheduling can start.
Part II: Scheduling
In this part, you use the Event Planning transaction to create Event Packages,
Events with or without schedule and bundle them in Event Packages.
Part III: Permanent Scheduling information
Scheduling details may be kept for future planning. You may use the copy function or
templates to store basic information for scheduling with the Event Planning
transaction.
© SAP 2009
Before you can plan an Event, you have to prepare for the following:
• Maintain Event Planning customizing (category, delivery mode, teaching method, processing
status)
– Master Data in Student Lifecycle Management Academic Structure Event Planning
– Master Data in Student Lifecycle Management Academic Structure Event Packages
– Master Data in Student Lifecycle Management Academic Structure Business Event
Types
• Set up Event Types, schedule Events or create Event Packages
– Student Lifecycle Management menu under: Event Planning Edit Event Offering.
• Maintain the Academic Structure and create Event Types for Modules.
– Student Lifecycle Management menu: Academic Structure Study Planning Program
Catalog.
• Create Resource Types and Resources in Customizing
• Create Location in Customizing
• Maintain Academic Calendar and Academic Sessions in Customizing
Notes:
1. When you create objects, select choose the correct “Start“ and “End“ dates. (Validity dates).
2. To change the validity dates of an existing Event use the “Edit Event Offering” function from the
Module Catalog. The associated Event Packages and bookings are automatically matched to the new
dates.
3. You can define whether the system should include event packages when it processes event
offerings. Per default, the event packages are included. You can remove Event Package from Event
Offerings in the IMG at SLCM Master Data in SLCM
Academic Structure
Event Planning
Set Processing to Include Event Packages.
© SAP AG
IHE102
3-21
3 .2 Eve nt Pla nning Proc e ss – T opic Summ a ry
You are now able to:
Understand the different aspects of the Event
Planning Process
Use the Event Planning transaction
Select Resources for Events
Cancel Events
© SAP 2009
© SAP AG
IHE102
3-22
3 .3 Eve nt T e mpla t e s – T opic Obje c t ive s
At the conclusion of this topic, you will be able to:
Simplify the regular Event Planning process for Academic
Sessions
Create reusable Event Planning templates
Explain the copy functionality for schedules
© SAP 2009
© SAP AG
IHE102
3-23
3 .3 Eve nt T e mpla t e s – Ove rvie w
Generating templates from Events
The schedule descriptions of regular Events are
used to generate templates
Creating new Events from templates
New Events with a regular schedule will be
created using the schedule description from the
templates
© SAP 2009
The Student Lifecycle Management Event Planning functionality allows to create reusable Event
offering templates.
Event offerings of a particular session hardly change from one academic year to the next. Many
universities therefore want to use the previous session’s offerings as a basis when planning offerings
for the upcoming academic year.
You can use templates when planning Events; they save you from having to create and maintain
Event offerings from scratch for each academic session. You can also use these templates when
copying Event offerings, create templates from existing Event offerings, and create the templates
before you create the Events.
© SAP AG
IHE102
3-24
3 .3 Eve nt T e mpla t e s – Sc ena rios
SM
1
D
E
Create templates
from existing Events
with regular schedule
2
D
E
Create templates
without Event offering
3
D
E
Copy Event
offerings
© SAP 2009
You can either create new templates or create templates from existing Event schedules. The
schedules you create for an academic session are reusable.
To create templates from existing offerings (=automatically), go to the:
• SAP menu Student Lifecycle Management → Academic Structure (Curriculum) → Event
Planning → Edit Event Offering.
• Select an Object Type and display existing Events.
• If you want the system to automatically create Event offering templates, choose the template
button or choose Goto → Edit Templates.
• Enter the required selection criteria in the dialog box if you have not already done so in the Event
Planning screen.
• Select the Event offerings from which you want to create templates and choose [Save]. The
system generates templates from the selected Event offerings.
To create and generate Event offering templates manually, go to the:
• Module Catalog, choose Environment → Edit Event Offering → Goto → Offering Templates →
Maintain templates for Event offerings. The Create Templates for Event Offerings screen
appears.
• Enter the required template data and save your entries.
Note:
• A template is created for each single instance of an Event.
• The templates are attached to the Module or the Event Package you selected.
• If you want to maintain the templates, you have to choose the Module or Event Package first
before the available templates are offered by the system.
© SAP AG
IHE102
3-25
3 .3 Eve nt T e mpla t e s – Ove rvie w of Proce dure
Template for Event offering ENG101 Lecture 01
Module
Abbrev.
Event
Abbrev.
Engl.
101
Eng101
LEC01
M
o
Year: 2008
Period: Fall
Tu
We
Th
x
FR
Preparation
Start
End
Location
Room
ID
PERSID
8:00
13:00
Mannheim
CE.06
000014
08/16/2008 – 12/31/2008
Mannheim
Event
ENG101 Lec 01
Realization Parameters:
Every Thursday in this
period
New Events
08/16/2008
Room CE.06
08/16/2008
Person 00000014
© SAP 2009
A reusable template is created for long-living objects, such as Modules, Event Types, Event
Packages. Only the basic Event data but not concrete dates are used in the templates. The following
functions or data are relevant for the creation of templates:
• If Modules are offered in alternating sessions such as “Summer Semester only” or “only every
two years“, you can create a session pattern and use this to create templates. The session pattern
can be attached to Modules (SM) and Event Packages (SE). Session Patterns are used for
templates, but NOT for Events.
• You can attach the session pattern to a Module as well as to an associated Event Package. You
can thus create schedule templates per Event Package and not only per Module. This allows you
to specify resources, dates, and session patterns for each Event Package.
• A planning status can be used in templates.
• Template processing is protected by special authorizations.
When a template has been created, this means a master plan is stored in the system. You can create
new Event offerings for different sessions from the master plan. The master plan itself is not
changed and can be used to plan upcoming academic years and sessions. The master plan can
contain Events with regular schedule and Time-independent Events.
To create a template, start the Event Planning transaction from the Student Lifecycle Management
menu; choose Event Planning > Edit Event Offering. Then use the edit template button to create or
edit a template. You can select the Events the template should be created from by the Access
Objects, such as Modules or Program of Study and the Academic Session.
© SAP AG
IHE102
3-26
3 .3 Eve nt T e mpla t e s – Cre a te Eve nt s from
T e m pla te or Copy
Copy Function for Events:
The Modules (for which Events
are to be created) are determined
via a Selection Method
Session patterns are evaluated
Test Run function is provided.
Parallel processing is supported
© SAP 2009
You use this procedure to create Event offerings from existing templates or to copy Event offerings
of one academic session to another.
• Before you can copy an Event offering, you either require Event offering templates or the Event
offerings of a previous academic session.
• We recommend that you execute a test run before each update run.
• The copy report program requires considerable system resources. We therefore recommend that
you schedule a background job for the update run, and copy only small units of data at once (for
example, single Organizational Units).
From the SAP menu, choose Student Lifecycle Management → Event Planning → Create Event
Offering from Template or use transaction PIQCOPY2. The Copy Event Offering screen appears
(report program RHIQACADOFFER_COPY). You can copy (parts) of your academic offerings to
another academic year and session by choosing:
• The relevant selection method.
• The academic year and session from which you want to copy the Events, for example Fall 2008
• The academic year and session to which you want to copy the Events, for example Fall 2009
• Whether you only want to create planned or firmly booked Events.
Note: If you use the copy function to create Event offerings, any changes you make in the schedule
(you are copying) will appear in the new schedule. However when you use a template, the changes
you make in the schedule do not alter the template. In the copy function, the system creates a
template in the background (which you cannot see) and deletes it after it has copied the Event
offerings. We recommend you use a template when creating Event offerings as you can view the
template before copying it.
© SAP AG
IHE102
3-27
3 .3 Eve nt T e mpla t e s – T opic Sum m a ry
You are now able to:
Simplify the regular Event planning process for
Academic Sessions
Create reusable Event planning templates
Explain the copy functionality for schedules
© SAP 2009
© SAP AG
IHE102
3-28
3 .4 T e ac hing Work load – T opic Objec tives
At the conclusion of this topic, you will be able to:
Explain what Teaching Workload means
Maintain planned and actual Teaching Workload
Configure Teaching Workload
Explain the Faculty Workload report and explain the usage of
queries.
© SAP 2009
© SAP AG
IHE102
3-29
3 .4 T e ac hing Work load – Ove rvie w
Student Lifecycle Management is
integrated with Training and Event
Management and Organization
Management:
O
Department
Functionality HCM.:
S
Personal master data, processes
Position
Supports time recording for all types
of activities, effort reporting, ...
P
Person
Obligation for teaching load are
stored within the personell/ position
master data.
planned
resource for
Functionality SLCM:
Scheduling of Events for courses
using teachers which are managed in
the Personal Master Data
SM
D
Course
Event Type
Tracking of activities which are
related to Teaching (Teaching
Workload)
conducts
E
E
Event
Event
© SAP 2008
The organizational structure of the Human Capital Management is integrated to Student Lifecycle
Management. When planning an Event, you are able to plan instructor resources by referring to
teachers managed in the Human Capital Management as Personal Master Data.
HCM supports a time-based effort tracking for all personnel. When a teacher is planned for events
of the University business, which are managed with Student Lifecycle Management, then Student
Lifecycle Management supports a more refined workload tracking which does not match 1:1 with
time.
The Teaching Workload in Student Lifecycle Management describes the time and effort which is
needed to prepare and conduct a teaching Event, such as lecture, tutorial, etc. It allows to distinguish
different types of activities which need to be performed for the Event. Student Lifecycle
Management also offers rules for the final calculation of Teaching Workload.
Workload of faculty members can be tracked for the following reasons:
• Resource planning in teaching activities
– Load (free resources, covering the Event offering, ...)
• Controlling
– Performance / contractual obligations
– Costs (cost of teaching activities / revenues)
• Compensation
– Determination of the amount of money that has to be paid
– Determination of overload for faculty members
• Strategic planning
– Analysis of trends
– Analysis of profitability
Rules to define and measure faculty workload depend on:
• State regulations
• Wage agreement of the University with union
• Individual contracts with employees
• Frequent changes
© SAP AG
IHE102
3-30
3 .4 T e ac hing Work load – Component s of t he
St udent Lifec yc le M anage me nt Solut ion
The following components for teaching workload tracking are delivered with
Student Lifecycle Management:
Definition of teaching obligations (mandatory teaching hours)
Teaching hours per position
Reduction of teaching hours ((non-)contractual, permanent – temporarily)
Definition & tracking of teaching load
Define required teaching workload on the Event Type / Event Level
Define rules how to summarize all aspects of workload for an Event
Monitoring, Reporting, Analyzing of teaching load
Web-Based Faculty Workload Query
Teaching workload information is maintain in the HR infotype for
positions (object type „P“)
© SAP 2009
Teaching hours: Teaching obligations describe the amount of teaching time which is required from a
certain position. This can be a standard value which is individually altered in case a person has
additional tasks to his or her teaching tasks, such as administrative tasks. These additional tasks may
reduce the amount of teaching hours.
You keep the information about teaching obligations of a staff member on the position which you
have created for a staff member within Human Capital Management. The Position – Object Type S
– offers an (extendable, standard) infotype where you can enter the following information:
• Mandatory teaching hours – can be defaulted by certain attributes
• Reductions of the standard teaching hours and reasons for this (example: administrative tasks in
addition to teaching obligations)
The infotype can be extended or even replaced in an implementation if, for example, a contract with
a union needs different definitions.
You maintain required customizing in the IMG for SLCM > Master Data in Student Lifecycle
Management
Academic Structure
Administration of Teaching Hours (HR Funds & Position
Mgt)
• Define Default Values for Mandatory Teaching Hours
• Define Reasons for Reducing Teaching Hours for Positions
Reasons for Reduction of teaching hours:
• Contractual / non-contractual reassigned times
– Department chair
– Coach of sport team or cheerleaders
– Member of committees
• Temporarily / permanent reduction
– Individual agreements
– Disability
=> Impact on Compensation / Overload become visible in Payroll and Invoice.
© SAP AG
IHE102
3-31
3 .4 T e ac hing Work load – De finit ion of
T e ac hing Load
Student Lifecycle Management offers the following attributes to describe the
Teaching Workload after Event Packages (SE) and Events (E) are created:
Units for measuring teaching load, e. g.
Semester Hours
Preparation Units
Teaching Activity Groupings (Workload Types) with units, e. g.
Teaching – Semester Hours
Preparation – Preparation Units
Teaching Activities, e. g.
Prepare a course – belongs to preparation
Teach a class – belongs to teaching
Co-teach a class – belongs to teaching
Calculation Rules for Teaching Activities, e. g.
“Teach a class“ is counted per contact hour of an Event
“Prepare a course“ is counted per Event Type
Weighting Factors per category, e. g.
Teaching a lecture count with factor 1 per contact hour, while teaching an exercise only counts
for half.
© SAP 2009
To maintain Faculty Workload, you need to complete the following steps:
• Add expected workload to the HR Faculty Position
• Add planned workload to the business event type
• Create the events in PIQACADOFFER00
• Maintain actual workload effort for each event in event planning
You can maintain expected workload at each faculty position as follows:
• Transaction: PP01
• Object Type: Position (S)
• Scroll down list of infotypes. Select “Teaching Hours” (1507).
• Teaching Hours are specified in the field: “Hours Per Week”
You maintain teaching workload for Events and Event Packages in the Event Planning transaction:
• Transaction: PIQACADOFFER00
• Select [Edit Teaching Workload] to maintain the teaching effort.
When only one instructor is assigned to the event you can default Teaching Workload Data by
pressing the ‘Teaching Workload’ button. Then the workload from the Event Type is defaulted. It
can be edited and changed individually.
Default workload is maintained at Business event type (D), infotype 1753. You can define the
planned effort per activity:
• Enter Number of Contact hours
• Enter Activity
• Enter Teaching Effort
© SAP AG
IHE102
3-32
3 .4 T e ac hing Work load – Configura t ion
Activities, related teaching activity grouping and rules for calculation
Rules for Counting
Activity
Description
Unit
Unit
description
Teaching
Activity
Grouping
T001
Teach a class
CH
Contact
Hours
Teaching
P001
Prepare a
class
PREP
Preparation
Unit
Preparation
T002
Co-teach a
class
CH
Contact
Hours
Teaching
Per
event
type
Per
event
Per student
Per
contact
hour
X
X
X
X
X
In this example, an instructor teaching the same Event several
times will only get preparation effort counted once!
© SAP 2008
Go to the IMG for Student Lifecycle Management
Master Data in Student Lifecycle Management
Academic Structure
Teaching Workload. The following may be maintained:
• Define Units for Teaching Effort and Contact Hours:
• It is best to use a single Unit (e.g. SWH, Semester Work Hours). If you use any other unit create
a BAdI implementation to handle it. Convert all other usages to this Unit in your Badi. The
expected workload for the Position is always in units SWH, and is not configurable.
• Define Teaching Activity Groupings and Assign Units
– Defined unit applies to all teaching activities in this grouping.
– Can be used in customer-specific programs to analyze data
– For non-teaching activities, use the flag in the last column. This allows teaching vs. non-teaching
workload to be separated during reporting.
• Define Teaching Activities
– Teaching activities can be assigned to the business event type and will default when that business event
type is selected
– They are assigned to the object (E or EL) in the Teaching Workload infotype (1753).Both Teaching and
Non-Teaching activities should be defined here
– NON-TEACHING activities should also be defined here.
• Define Calculation Rules for Teaching Activities (e.g. see above: someone who is teaching the
same type of event several times will only get the preparation effort counted once) .
– Can be used to analyze data in customer specific programs
– Four calculation rules are provided. A combination of the rules can be used as well.
– Delivered BAdI implementation for workload calculation reads these settings
• Weight Teaching Activities by Category (optional). The delivered BAdI implementation for
calculating weighting of workload reads these values.
• From here you can also access the setting “Administration of Teaching Hours (HR Funds and
Position Management)“ to administer the teaching obligations (mandatory teaching hours +
reductions)
© SAP AG
IHE102
3-33
3 .4 T e ac hing Work load – We ight ing Fa c tor
Weighting factor for workload value of a specific category / activity
combination
Category
Cat. Description
Activity
Activ. Description
Weighting
factor
0001
Lecture
T001
Teach a class
1
0001
Lecture
P001
Prepare a class
1
0001
Lecture
T002
Co-teach a class
0,5
0002
Laboratory
T001
Teach a class
0,75
0002
Laboratory
T002
Co-teach a class
0,75
0002
Laboratory
P001
Prepare a class
1
© SAP 2009
This customizing entry is optional. To maintain Weight Teaching Activities by Category
• Assign one or more Event Type categories to every teaching activity
• Define a weighting factor for each combination of teaching activity and category.
Customizing Path: IMG for Student Lifecycle Management
Management
Academic Structure
Teaching Workload
Category.
© SAP AG
IHE102
Master Data in Student Lifecycle
Weight Teaching Activities by
3-34
3 .4 T e ac hing Work load – Report ing
A RFC is provided to retrieve the faculty workload data for a faculty member. A
web-based query tool allows for reporting on the workload of all instructors of a
particular department. This web-based faculty workload query is integrated in
the Event Planning user interface and can be viewed there.
© SAP 2009
The Teaching Workload Report can be viewed directly from Event Planning as follows:
• Transaction: PIQACADOFFER00
• Select a Module (with Events/Event Packages already created)
• Specify the Academic Year and Session.
• Click on the [Find] Icon.
• Highlight an Event Package, click on [Display] and select [Display Academic Event].
• Select the Icon [Teaching Workload] to view the on-line report.
• Select [Define New Query]. (See next slide for procedure to create Queries).
© SAP AG
IHE102
3-35
3 .4 Fac ult y Work loa d – De fine N e w Que ry
Define New Query
Step One:
Select Object type
Three choices available
Define New Query
Step Two
Maintain required information
(Academic Year and
Session)
Step Three
Finish
© SAP 2009
The Faculty Workload report allows to create own queries.
‚Instructors for courses of a department‘ will return all workload for all instructors who have
workload for the courses offered by the selected department
‘Instructors of a department‘ will return all workload for the instructors assigned to that department,
regardless of the activity.
Web Dynpro: PIQ_FACWLOAD
Function Module: HRIQ_RFC_FACWLREP_DATA_GET
© SAP AG
IHE102
3-36
3 .4 T e ac hing Work load – Report ing Re sult s
Details of the
report result
are displayed
by double
clicking on
any line
© SAP 2009
In the result list standard ALV features are available.
Example of a query result by instructor
• Teaching effort is displayed by teaching unit (teaching activity grouping)
• Teaching vs. Non-Teaching load is shown
• Double click on any line to see the detail
Detailed Workload and Expenses result (Teaching effort by activity):
• The “Delivery Side Cost“ shows the Cost Center distribution of the Instructors
• The “Receiving Side Cost“ shows the Cost Center distribution of the Events
© SAP AG
IHE102
3-37
3 .4 T e ac hing Work load – Que ry Fea t ure s
Use these links to Change/Define/
personalize your queries
Use these links to set filters or
change query settings
Note: Only ONE workload unit (SWH)
should ever be used so that the reports
produce a meaningful result.
© SAP 2009
The following BADI’s are delivered to help in customer reporting (Customizing Path: IMG for
Student Lifecycle Management
Master Data in Student Lifecycle Management Academic
Structure
Teaching Workload Business Add-Ins (BAdIs).)
BAdI: Determine Cost Distribution (SET_COSTDIST): Use this if you need to derive cost
distribution for faculty members in a way other than using the position definition and Academic
Object definition (delivered implementation)
BAdI: Calculate Teaching Workload (CALC_TEACHLOAD): Use this if you want to utilize the
‘Reduction in Workload’ defined at the position; Also use this if your calculation rules cannot be
modeled fully in configuration table T7PIQACTIVWLTYPE (delivered implementation) in se 16.
BAdI: Determine Weighting Factor (SET_WFACTOR_DEFAULT): Determine Weighting Factor –
Use this if you need to use more complex weighting factors other than those stored in configuration
table T7PIQWEIGHTFACT (delivered implementation)
Note: If you have used any units other than ‘SWH‘ for Workload, you must implement BAdI:
Calculate Teaching Workload for unit conversion!
© SAP AG
IHE102
3-38
3 .4 T e ac hing Work load – T opic Sum m a ry
You are now able to:
Explain how Teaching Workload can be used to
manage teaching activity efforts
Understand how Student Lifecycle Management
helps to manage the Teaching Workload
Explain the Faculty Workload report and explain the
usage of queries.
© SAP 2009
© SAP AG
IHE102
3-39
3 .5 Cohort s – T opic Objec t ive s
At the conclusion of this topic, you will:
Understand the purpose of the Cohort functionality in
Student Lifecycle Management
Know how to use Cohorts for Event Planning
Be prepared for using Cohorts in the context of course
registration (Chapter 6)
© SAP 2008
© SAP AG
IHE102
3-40
3 .5 Cohort s – Ove rvie w a nd Cha ra c te rist ic s
In Student Lifecycle Management, students can be grouped together to perform
certain administrative activities for them. These groups are called “Cohorts”
and students are assigned to them.
Cohorts can be created for
Students taking the same lessons during a certain academic period. In this case a
clash-free timetable can be created for the students of the Cohort
Mass Module Booking for groups of Students
International students
Characteristics of Cohorts:
When creating and/or changing a cohort, a ‘context’ is selected to describe the
administrative process for which the Cohort is used.
Attributes must be assigned to each cohort
Capacity, sessions of offering and context are checked during the set-up of the
cohort
© SAP 2008
A Cohort is a group of students for which common administrative processes must be performed.
Students are selected and assigned to the cohort
• Manually
• Via selection methods
The context of a cohort describes the administrative process/activity for which it is set up/valid for.
A Cohort may have several contexts.
In the context of Module booking, context objects can be study Modules (object type SM), Event
Types (D), Events (E ), etc. You can assign selected objects of these types to this Cohort then.
Student Lifecycle Management delivers the context “0001“ Module booking. This is used if you
want to work with the Cohort in Event Planning. The Cohort will group all those students together
who are to be booked onto the same Modules or Events.
Example: A Cohort is built to provide a clash-free timetable for students taking part in the same
courses in a particular Academic Year. The study modules to be booked by those students are
assigned to the Cohorts as Context Objects. For these study modules, Events (with no overlapping)
are created in order to produce a clash-free timetable.
Note: The planner has to make sure that no overlapping Events are planned for one Cohort – the
system does not check for overlapping Events!
© SAP AG
IHE102
3-41
3 .5 Cohort s - T e rm inology
A Cohort
is defined via Attributes :
Capacity limits
Session of offering
can be assigned to via Relationships to:
Organizational units
Programs of study
Program types
Cohorts can be organized in Hierarchies
Context Objects
can be assigned to a cohort to specify the relevant process
Refer to study Modules or Events if the context is Module Booking
© SAP 2008
Cohort attributes determine characteristics of the cohort (e.g. the cohort is only valid in a certain
session)
Relationships allow to relate cohorts to organizational units (Relationship 502) as well as programs
of study (522). Students which are members of a cohort are related to the cohort via relationship
519.
Context Objects: Objects relevant for a certain context of the cohort are called context objects. The
activities related to the context often need specified “target objects” like specific study modules for
the context module booking, etc.
© SAP AG
IHE102
3-42
3 .5 Cohort s – Cohort H ie ra rc hy
a nd Subc ohort s
Cohorts can be organized hierarchically and Subcohorts can be created for
them:
A Cohort can have several Subcohorts
A Subcohort can also have Subcohorts (several levels of hierarchy)
All students of a Subcohort are part of the main Cohort as well
A function is available for distributing the students of a cohort amongst its subcohorts.
All context objects of the main Cohort are used by the Subcohorts as well
Subcohort and main Cohort must have at least one context in common
Note: Applying a naming convention is useful for later data maintenance in order to
reflect the hierarchy level of the various cohorts.
© SAP 2008
Note the following relation between a Cohort and a Subcohort:
• All students of the Subcohort are part of the (main) Cohort as well. The main Cohort inherits the
students from the Subcohort. In the student list of the main Cohort the inherited students appear
with an icon in the Inheritance column.
• The inherited students are not saved to the database. They are taken into account for all processes
using Cohorts as if they were assigned directly to the main Cohort.
• Subcohort and main Cohort must have at least one context in common.
• All context objects of the main Cohort belong to the Subcohort, too; the Subcohort inherits the
context objects from the main Cohort. Inherited context objects are shown in the context object
list of the Subcohort with an icon in the Inheritance column.
• Attention: The inheritance of context objects may be context-dependent
The Cohort Builder main screen (Transaction PIQCOH00) offers the following capabilities:
• New cohorts and sub-cohorts can be created directly in the ALV tree control (ABAP List
Viewer), using the right mouse button or highlighting the main cohort and right clicking on
mouse.
• Leading cohorts can be changed by double-clicking on a sub-cohort or main cohort in the ALV
tree.
• The sessions of offering of a Subcohort must be a subset of the set of offerings of the main
Cohort. They can have the same or a shorter lifetime than the parent cohort.
• Technically, a relationship is created between the connected Cohorts (519).
© SAP AG
IHE102
3-43
3 .5 Cohort s – Busine ss Sce na rio for St ude nt
Dist ribut ion
Assume there are 180 new students who have registered for the first stage of
the program “Computer Science”. Every student has to take certain training
lessons, which are scheduled for groups of 20 students.
Consequently, the students should be grouped in cohorts with 20 students in
every cohort:
Main Cohort
Subcohorts
180 beginners of Computer Sciences
1 & i 2 & ii
3 & iii
4 & iv 5 & v 6 & vi 7 & vii 8 & viii 9 & ix
Exercises: Mathematics:
1–9
Exercises: Theoretical Infomation Techn.:
group
20 students per group
i – ix
20 students per
etc.
© SAP 2008
To create Cohorts you need to complete the required customizing (IMG – Student Lifecycle
Management – Student Lifecycle Management Processes – Cohorts). Afterwards you can use the
“Cohort Builder“ to create Cohorts and assign context objects and students:
Go to the SAP Easy Access Menu: → Student Lifecycle Management → Tools → Cohort Builder:
• You can assign students to Cohorts via the Cohort builder or student file.
• You can also edit those Cohorts with a Module booking context to a limited extent using Event
Planning functions. In the ‘Edit Event Offerings for Cohorts’ transaction, you can assign Events
to Cohorts as context objects and remove them again.
Cohorts cannot be maintained by standard HR Infotype maintenance transactions.
Notes regarding the Evaluation Path:
• Students get inherited bottom-up
• Attributes get inherited top-down
• Context objects get inherited top down
© SAP AG
IHE102
3-44
3 .5 Cohort s – Eve nt Pla nning w it h Cohort s
How to use Cohorts for Event Planning:
1. Preparation
Create cohorts with context “Module booking“
Assign cohorts to Modules/Event Packages/Events as Context Objects
2. Event Planning
Use transaction “Edit Event Offerings for Cohorts” to create Events
Select Cohort and create Events/Event Packages for an academic session
The new Events are automatically assigned to the Cohort as a context object
Sessions of Offering and Context Objects assigned to the main cohort are
inherited by sub-cohorts.
Note:
You cannot assign an existing Event, Event Package or Module to a Cohort in
the Event Planning transaction.
You must assign these objects to the Cohort as context objects in the Cohort
Builder.
© SAP 2008
In order to use the Cohorts in Event Planning processes, you have to do the following:
Prerequisites: You have created the required Cohort and assigned this Cohort the relevant Module as
context object. You can also assign Event Packages and Events to a Cohort as context objects.
From the Student Lifecycle Management menu choose “Edit Event Offerings for Cohorts”
(PIQACADOFFER01). In the selection screen, you can enter the following data:
• Cohort, Academic Period, Key Date
• You can now create a new Event or Event Package for Cohorts. The Event can be:
– Event with regular schedule, Event with irregular schedule, Event without a schedule, Timeindependent Event.
Cohorts can be selected from existing ones in the object manager if the validity period of the new
cohort corresponds to the chosen key date.
Tip: When you choose a Cohort as starting object, all the Events and Packages which are assigned to
this Cohort as context object for the specified Academic Year and Session should be shown in the
worklist. Additionally, you can also create or delete the objects and this will either add the context
objects or delete the context objects of the Cohort.
Note: Cohorts cannot be deleted. The key date controls their availability in the object manager
© SAP AG
IHE102
3-45
3 .5 Eve nt Pla nning – Cust om izing Ex a mple s
Integration between TEM and Event Planning:
Example 1: In order to have rooms and locations available in SLCM Event
Planning transaction you need to maintain the respective resources in TEM
Example 2: In order to have different event type categories available in the
Event Planning maintenance screen (Tab: Category) you need to set them up
in the customizing of Student Lifecycle Management.
Example 3: You need to maintain attributes of cohorts in the cohort builder tool.
The values that shall be available for selection in the drop down menue on the
tab “categories” of the cohort (e.g. Main Cohort, Cohort Fall, Cohort Summer)
must be maintained in the IMG of Student Lifecycle Management.
© SAP 2008
You maintain resources for Event Planning in IMG Training and Event Management
Room
Reservation Management
Master Data Reservation
Create Location and Create Room
You maintain event type categories in the IMG Student Lifecycle Management
Master Data in
Student Lifecycle Management
Academic Structure Business Event Types
Define
Categories.
You access the Cohort Builder in the SAP Menu
Cohort Builder or via transaction PIQCOH00.
Student Lifecycle Management
Tools
Important: Note that every change you make in the cohort builder takes effect from the Key Date on
(i.e. valid from the key date until 12/31/9999), except for the events and the module bookings, which
take effect for the specified academic period.
You set up customizing for cohorts in IMG
Student Lifecycle Management
Cohorts
Student Lifecycle Management
Define Cohort Categories.
Processes in
In addition, there are several BADI’s available in IMG for customization of Cohorts: Student
Lifecycle Management
Processes in Student Lifecycle Management
Cohorts.
• BAdI: Override Pushbuttons in the Cohort Builder
• BAdI: Distribute Students from Cohort to Subcohorts
© SAP AG
IHE102
3-46
3 .5 Cohort s – T opic Sum ma ry
You are now:
Able to explain the Cohort functionality in Student
Lifecycle Management
Knowledgeable to use Cohorts for Event Planning
Prepared for using Cohorts in the later context of
course registration (Chapter 6)
© SAP 2009
© SAP AG
IHE102
3-47
3 . Eve nt Pla nning – U nit Sum m a ry
You are now able to:
Understand the correlation between Academic
Structures and Event Planning
Use the Event Planning tools
Set up different planning scenarios
(regular – irregular, time independent events)
Simplify the regular Event Planning process
(templates and copy of schedules)
Monitor the Teaching Workload of your staff
Provide clash free timetables for groups of students
(Event Planning with Cohorts)
© SAP 2008
© SAP AG
IHE102
3-48
I H E1 02 St udent Lifec yc le M anagem ent :
4 . St udent Da t a M a int enance
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009 / Page 1
© SAP AG
IHE102
4-1
4 . St udent Da t a M a int enance
Content:
4.1 Student Record
Student as Object
Business Partner
4.2 Student Master Data
4.3 Student File
Functions of the Student File
Visiting Studies
Data Privacy Warning
4.4 Customizing
© SAP 2009
2008 / Page 1
© SAP AG
IHE102
4-2
4 . St udent Da t a M a int enance : U nit Obje c t ive s
After completing this unit, you will be able to:
Understand how a student record is created
Explain and use student master data
Describe the features of the Student File
Use functions of the Student File and student master
data
Create student notes
Maintain exchange program information
Use specific Student File functions such as data
privacy warning
© SAP 2009 / Page 1
© SAP AG
IHE102
4-3
4 . St udent Da t a M a int enance – Busine ss
Sc ena rio
You work in the Registrar's office
You have access to the administrative system and can
display student personal data
You are responsible for entering or changing student master
data
You want to access student data and study related processes
(administrative and academic)
It is your responsibility to define the characteristics of student
master data records
© SAP 2009 / Page 1
© SAP AG
IHE102
4-4
4 .1 St ude nt Rec ord: T opic Objec t ive s
After completing this topic, you will be able to:
Explain the characteristics of the object types
representing a person in the role “student” and others
Describe how the student administration and student
accounting applications are integrated
Explain features of the Business Partner relevant for
student administration
Describe the different students statuses
Explain the concept of student numbers
Create a student record
© SAP 2009 / Page 1
© SAP AG
IHE102
4-5
4 .1 St ude nt Rec ord – Cre a t e Student Rec ord
You can create a Student Record
Manually
via Student File
Automatically
via the Admission Application or other interfaces (like external
systems (UCAS), Financial Aid, )
Create Master Data or transaction PIQSTC
When you create a Student Record, the system
- creates an object of the type ST
- creates a Business Partner
- creates a Contract Account
© SAP 2009 / Page 1
You use the master data maintenance transaction to create, display, and change student master data.
You can access it from the SAP Menu by choosing Student Lifecycle Management Student
Administration
Master Data
Create, or via the [Create] Icon in the Student File:
• If you use the external number assignment, enter the student number.
• Enter the student data on the respective tab pages.
• To undo creation of a student master record, choose undo create. Else save the record.
When you create master data for a student, the system automatically creates a HR object of the type
ST and an SAP Business Partner.
The system stores the student’s personal data and study data in infotype data records. Bank and
payment card information and address data is stored in the Business Partner master record.
Student personal data is copied from the student to the Business Partner. You must schedule an
update program daily to copy any changes you make to student personal data
(RHIQ_ST_PERS_SYNC_CURR).
Student Business Partners (ST+ BP) are used to administer students in different roles:
• Applicants
• Students
• Deregistered students
• Alumni
Business Partners are used to administer persons relevant in Student Administration:
• Related Persons
• Sponsors …
© SAP AG
IHE102
4-6
4 .1 St ude nt Rec ord – Busine ss Pa rt ne r
I nt egra t ion
Student Lifecycle Management
Student
Administration
Student
Accounting
Object Student (ST)
SAP Business Partner (BP)
Student Lifecycle Management
Student Business Partner
© SAP 2009 / Page 1
Student Lifecycle Management is based on two different frameworks, the HR–PD development
framework and Public Sector Contract Accounting (IS-PS-CA).
Administrative and academic processes for students mainly use functions of the HR-PD framework
(object types, relationships, infotypes, etc.). The student accounting processes use IS-PS-CA.
When you create master data for a new student, the system always creates:
• A student object (object type ST), which is based on the HR-PD framework, using object types,
infotypes, and relationships. The ST object contains personal and academic data.
• A Business Partner (BP) with the roles “contract partner” (MKK) and “student” (PSCM10).
• An entry in table CMACBPST which internally links the student object ST with the BP.
Student administration processes mainly use the student object (ST), and student accounting
processes mainly use the BP.
If you wish to create student master records automatically from data stored in a legacy system, you
must use function module BAPI_STUDENT_CREATEFROMDATA3.
Note 1: In the Student Lifecycle Management system you cannot create a student object without
creating the respective BP. You cannot create a BP in the role “student” without a student object.
Note 2: You first have to perform the required basic customizing steps before you can create
students.
Note 3: if you have implemented a CRM system to support student recruitment, the CRM
middleware will automatically keep the BP records between CRM and SLCM synchronized, so that
when the prospect record is replicated to SLCM, any BP ID number in the CRM BP record will
automatically be replicated into the SLCM BP record. Clearly, your BP configuration in CRM and
SLCM must be the same for the middleware to replicate the data.
© SAP AG
IHE102
4-7
4 .1 St ude nt Rec ord – Conve rt Busine ss
Pa rt ne rs t o St udent s
Student Lifecycle Management allows you to
Convert existing Business Partners (who are not students yet) into students
Create a new student from an existing Business Partner
Business example:
A student within the university is assigned to a related person, e.g. a relative designated as an
emergency contact. The related person submits an application to study at the university.
Instead of creating a new student, the related person Business Partner can be converted to a
Student Record.
© SAP 2009 / Page 1
© SAP AG
IHE102
4-8
4 .1 St ude nt Rec ord – Cre a t e Student from
Busine ss Pa rtne r
Category:
Person
Business
Partner
Role:
General
Create
Student
Category:
Person
Student
Roles:
PSCM10
MKK
© SAP 2009 / Page 1
Student Lifecycle Management provides the ability to create a new student by using an existing
Business Partner as source for the creation of the new student.
This function is accessible via the maintenance transaction for Student Master Data and Student File
or via BADI (IMG for Student Lifecycle Management
Student Lifecycle Management
Master
Data in Student Lifecycle Management
Students
Student Numbers and Object IDs
BAdI:
Student Number Assignment)
• Step 1: Choose SAP Menu Student Lifecycle Management
Master Data
Change (PIQSTM) or Student File (PIQST00).
• Step 2: Choose Student
Student Administration
Create for Business Partner.
• Step 3: Enter the Business Partner number in the popup window or use the search function.
• Step 4: Enter a number within the range defined in Customizing. If the BADI has been
implemented, this step is omitted and the student number will be generated from the imported
Business Partner number.
• Step 5: Save the student record (Additional master data may be added to the record as required).
Students may be created from Business Partners under the following conditions:
• The Business Partner must exist in the category: Person.
• The Business Partner must not already be a student.
• The fields that are mandatory for creation of the Student Master must be maintained on the
Business Partner.
After creation of the student, the following attributes are adopted:
• Business Partner role is extended to: Contract Partner (MKK) and Student (PSCM10).
• The Business Partner name and personal data are copied to the student Infotypes 1000 and 1702.
© SAP AG
IHE102
4-9
4 .1 St ude nt Rec ord – St udent N um be r
There are three identifiers for the Student
Object ID
Student Number
Business Partner Number
Technical Key
Main identifier in Student
Lifecycle Management
Main Identifier in FI-CA
Internal Assignment
External and/or
internal assignment
Created automatically with a student
8 digits
12 digits
10 digits
Note:
The object ID is a key field of database tables for the ST object type. It is not visible in
Student Lifecycle Management dialog transactions.
The student number is the key identifier for students (applicants / alumni). You work with the
student number in all Student Lifecycle Management dialog transactions.
The BP number is the main identifier and technical key for the BP object and cannot be
changed once it is assigned.
© SAP 2009 / Page 1
Object ID:
• When you create a student in the dialog mode, the system supports only internal assignment of
the object ID for the student object (ST). The object ID cannot be changed once it has been
assigned.
Student Number:
• The student number is valid for the entire validity period of the student object. The standard
student maintenance transactions ensure that the student number is unique.
• The standard system supports only numeric student numbers. You can use alphanumeric student
numbers if you implement the required BAdI: IMG for SLCM Master Data in SLCM
Students
Student Numbers and Object IDs BAdI: Student Number Assignment
(HRPIQGB_ST_NUMBER).
Business Partner Number:
• There are several methods for setting up BP numbers. You can keep the student number and the
BP number identical by maintaining appropriate customizing settings for both number ranges and
implementing BADI HRPIQ_ST_BP_EQUAL (Definition: PSCM_PARTNER). You find it in
the IMG at: SLCM>Master Data in SLCM>Students> Students as Business Partners>The
Business Partner in Student Administration>Student Business Partner Numbers>BAdI: Business
Partner in Student Lifecycle Management
• The BP number is visible in BP and FI-CA transactions.
• You can see all three identifiers using the menu path Utilities Technical information.
• Note: The student number can be changed after a student is created. This is required for countries
where the student number is assigned by a central institution. If your business processes do not
require number changes after creation of the master record, you must make sure that users are not
authorized to use transaction PIQSTU1. If you allow student numbers to be changed, you cannot
use an identical Student Number and BP number.
© SAP AG
IHE102
4-10
4 .1 St ude nt Rec ord – St udent St a t us
The Student Status specifies the student’s position within the university and Program of Study. It
is displayed in the header of the Student File.
Predefined statuses are:
Applicant
Admitted applicant
Rejected applicant
Attending
Non-attending
Student
De-registered
Alumnus
Deceased
Additional customer statuses can be defined.
Note:
System statuses are automatically derived from administrative activities that are done during
the student lifecycle.
© SAP 2009 / Page 1
The student status is stored for object type ST. The system derives the student status from admission
and registration data. The following relationships and infoypes determine the student status:
• Relationship 530: applies for (ST – CS) => the system derives the student status "applicant“,
"admitted applicant“, or "rejected applicant“ depending on the status of the relationship.
• Infotype 1771: Sessional Registration = > the system derives the student status "attending“ or
“non-attending“.
• Relationship 513: pursues (ST – CS) => the system derives the student status "registered student“
or "de-registered student“ depending on the status of the relationship.
• Relationship 541: is alumnus of (ST – O) => the system derives the student status "alumnus“.
• You can maintain student statuses in your system (see “Holds & Statuses”):
– Switch off display of statuses which are not needed at your institution.
– Change the description associated with a status and/or change the order of the statuses on the
screen.
– Create your own status(es). In this case, you have to provide a customer-specific status
determination for the status.
Note: The student status displayed in the student header also shows the student group entered in the
student master. If no relationship exists, only the student group is shown. If one of the abovementioned relationships exists, the derived student status and the student group are displayed in the
header.
© SAP AG
IHE102
4-11
4 .1 St ude nt Rec ord – T opic Sum ma ry
You are now able to:
Explain the characteristics of the object types representing
a person in the role “student”
Describe how the student administration and student
accounting applications are integrated
Explain features of the Business Partner relevant for
student administration
List the statuses which reflect the different roles of persons
studying at a university
Explain the concept of student numbers
Create a student record
© SAP 2009 / Page 1
© SAP AG
IHE102
4-12
4 .2 St ude nt M a st e r Da t a – T opic Obje c t ive s
At the conclusion of this topic, you will be able to:
Explain the features of the student master data record
Enter and maintain student personal data
Work with the student master data record
© SAP 2009 / Page 1
© SAP AG
IHE102
4-13
4 .2 St ude nt M a st e r Da t a – Ove rvie w of St udent
M a st e r Da t a T a b Pa ge s
Student Master Data
Personal Data
Study Data
Fee Calculation Data
Address Overview
External Achievements
Payment Transactions
Standard Address
Employment
Contract Objects
Additional Data
Challenge Data
Grant Assignment
Visa/Residence Data
Related Persons
Alumnus
Identification numbers
Infotype Screens
BDT Screens
© SAP 2009
2008 / Page 1
The system offers transactions for creating, maintaining, and displaying student master data. These
can be accessed directly from the Student File using the “Create”, “Change” or “Display” buttons
(next to the student name). Alternatively, you can use the transactions PIQSTC, PIQSTM, or
PIQSTD, or in the SAP menu choose Student Lifecycle Management
Student Administration
Master Data
Display or Create or Change.
You set up basic Customizing for Student Master Data in the IMG: Master Data in Student Lifecycle
Management
Students
Students as Business Partners and all others. Customizing tables for
some of the field entries are cross-application tables (e.g., used by HCM).
BP data can also be maintained with transaction “BP”. Select the appropriate tabs to display and
maintain the data. Changes will immediately appear in the student master data as well.
Student master data comprises different tab pages. Master data is entered into the infotype screens
for the student object ST and on BDT screens for the BP object.
Each infotype has a validity period which is defined by a start and end date. Whether only one or
several infotypes may exist on a specific date (time dependency) is defined for each infotype.
If you change a record of infotypes which may contain only one valid record at a time, the system
will delimit the old record and create a new one. You can display old records using the Display
periods function on each tab page. The system indicates if an infotype has several validity periods.
(i.e. existence of historical records).
Note: Some data is only available in the BP view. For example, you can store information about
business hours such as, calling hours, goods receiving hours, visiting hours for a BP. This data is not
visible on the student master data screens.
To archive student data look at the SAP User Menu: SLCM Tools
Data Archiving
PIQSTMD_ARCH. You can extract the data to an archiving file (which you don't have to import to
any place) and then delete.
To delete student data you can use report RHIQ_STUDENT_DELETE.
© SAP AG
IHE102
4-14
4 .2 St ude nt M a st e r Da t a – Pe rsona l Da ta
Personal Data: Name, birth date, nationality, etc.
Standard Address: Address data, phone numbers, and e-mail
Additional data:
Category classifications, e.g. religion
Individual data, e.g. service status
Privacy level => protected access to master data
Visa/Residence data: Resident status, country, state and county, Visa Details
Employment: Person’s job history prior to becoming a student
Challenge: Data to provide challenged students with special assistance
© SAP 2009 / Page 1
On the tab “Personal Data” you can enter basic information. The system determines the default
communication language from the user logon language.
Address data is stored in the SAP BP using the SAP Business Address Services. You can:
• Store several addresses per student, define a standard address and different address types (term
address, billing address, etc.) as well as assign addresses to address type (address usage).
• Maintain address-independent and address-dependent communication data, such as several
telephone numbers, SMS-capable mobile numbers and e-mail addresses.
• Use address checks and input help via the regional structure and maintain international address
versions or define a user-specific address format in the user parameter ADDRESS_SCREEN
(001 Europe, 004 USA).
• Maintain start/end date for each address and address usage => change address data retroactively.
• Store data for Payment Transactions (Bank Details/Payment Cards)
If the above data is created/changed via Transaction BP the Student Master is automatically updated
so there is no danger of missing/inconsistent data. However, it is recommended to create/maintain
data via the Student Master Data.
Students can manage their addresses (and usages) via web self service (Web Dynpro Application
PIQ_ADDR_MAINT). Configurable alerts are provided to notify users when students made changes
to specific address types and fields that may impact their residency, tuition status, and aid eligibility.
Additional Data Tab Page – some important information:
• The Job field is used to store the job the student holds or held prior to the academic study. It is
used in the UK to store the jobs of students (or parents) transferred by the UCAS interface.
• If a student wants her data to be kept confidential (e.g., based on FERPA rules (US)), you can
specify this in the privacy level field. Then the user knows that student's data is private.
Visa/Residence Data tab page: SAP recommends that you do not use the passport number field.
Instead you can set up a BP ID number (IMG: Business Partner Basic Settings
ID Numbers).
© SAP AG
IHE102
4-15
4 .2 St udent M ast er Da t a – I ndividual St udy Da t a
Study Data (1705)
Student Group = Logical grouping of students for further business
processes and academic rules (e.g. regular vs. special students)
Time Window = Restrict module booking to defined times for a group
of students
Addnl ID Number = Legacy Student Number (for example)
Organizational Unit Assignment =
a) Derived from the main Program of Study
b) Assigned manually
Campus = Main location of study
© SAP 2009 / Page 1
In order to be able to assign a student to a specific student group in the Student Master Data you
need to maintain this information in IMG for Student Lifecycle Management
Master Data in
Student Lifecycle Management
Students
Individual Study Data Define Student Groups.
Students can be grouped according to specific criteria, e.g., if regular students and exchange students
are charged different fees at an institution, the students have to be grouped accordingly.
The Time Window represents a link between a group of students and one or more module booking
periods in the Academic Calendar.
You can assign one or more students to a Time Window. For each window, you can enter different,
non-overlapping booking periods in the Academic Calendar. During module booking, the system
checks whether or not the booking for the respective student was made within the limits of the
specified Time Window (see Chapter Academic Calendar for details).
SAP recommends that new customers should not use the “Additional Student Number” field. If you
record identification data such as student numbers from your legacy system, you can set up an”
Identification Type” and store this number as a Business Partner identification number (see topic
Identification Numbers in this chapter).
If students have an academic advisor at the institution, the person’s name can be stored in the
advisor field. Alternatively, the student can be linked to a position in the university‘s organizational
hierarchy. In this case, the system determines the person‘s name.
There are two ways of assigning students to organizational units: explicitly (manual) and implicitly
(automatic). Algorithms for automatic derivation of the organizational unit can be customized
according to the institution’s needs. In standard, the organizational unit assignment is derived from
the program of study the student is registered in if no explicit assignment is maintained.
You can make the respective Customizing settings in the IMG of Student Lifecycle Management:
Student Lifecycle Management
Master Data in Student Lifecycle Management Students
Derived Student Attributes
BAdI: Determine/Derive Organizational Unit of Student.
If an institution has many locations, the student’s main campus can be stored as his/her campus.
© SAP AG
IHE102
4-16
4 .2 St udent M ast er Da t a – Ex t erna l Ac hie vem e nts
External Achievements
(1719, 1721)
Educational History (High School, etc.)
Input for the admission process
Achievements from other institutions (former higher education)
Input for equivalency determination process
Results from external testing institutions
(for example, if test results are an admission requirement)
Input for the admission process + academic career
Upload program for TOEFL Test score files is available.
Note: a Transcript Quick Entry form allows to create and edit transcript
data for students and applicants.
© SAP 2009 / Page 1
The tab “Ext. Achievements” is used to store information from external educational institutions.
You can store external transcripts, external test results, and calculate average grades.
Transcript Quick Entry form: A web-based application is provided to allow admissions officers and
other users to quickly and easily create and edit transcript data (including subjects and
qualifications) for students or applicants:
• Allows editing existing transcript information
• Application: Web Dynpro component PIQ_MAINTAIN_TRANSCRIPT
Uploading TOEFL test score files: Program RHIQ_US_TEST_SCORE_UPLOAD is provided to
upload and attach the test scores to an existing student master record, where it can determine a
definitive match.
• Possible duplicate entries are passed to a separate file for future reprocessing, as are scores for
non-existent students.
• Student records are not created during the upload.
• The uploaded scores should match existing submitted applications.
US Localization: Report RHIQ_US_NCAA_INTERFACE is available to upload student data to the
National Collegiate Athletics Association (NCAA) website as an XML file. The XML file complies
with the NCAA file format specifications.
© SAP AG
IHE102
4-17
4 .2 St udent M ast er Da t a – I de nt ific at ion N um be rs
Identification numbers (BP)
Standard ID Numbers shall be entered on the tab “Identification
numbers” and not on the tab “Personal Data”.
Different ID-Number types can be defined (e.g. Social Security Number)
ID-Number
Institution, validity dates and address (e.g. Ministry of Social
Services)
BP number can be set as unique to prevent that the same ID can be
assigned to Business Partners twice (cross-client).
© SAP 2009 / Page 1
The Business Partner ID numbers are integrated into the Student Master Data display on the tab
“Identification Numbers”. It is recommended that you use these numbers to enter the standard
identification number rather than using the “ID Number” on the Personal Data tab, or the
“Additional ID Number” on the Study Data tab. The additional ID number on the Study Data tab
should be used if you need to store old student numbers in the system, for example.
Different ID types can be defined for the BP ID number field. To define Business Partner ID Types
go to IMG: SLCM
Master Data in SLCM
Students as Business Partners Basic Business
Partner Settings
SAP Business Partner>Business Partner
Basic Settings
Identification
Numbers
Define Identification Types:
• Enter an ID Type and Description
• Select an ID Category
• Select the flag ‘Persons’
• Select [Save] to complete.
Note: Only one ID Type may be assigned to an ID Category.
The Student’s ID Number is held on the Student Master data as follows:
• Infotype Name: Personal Data
• Infotype Number: 1702
• Field Name: ID Number
• Technical Field Name: PRDNI
General note: you can set the Business Partner ID as unique in order to prevent that the same ID can
be assigned to Business Partners twice (cross-client). In order to make this setting go to IMG SLCM
Students
Student as Business Partners
The Business Partner in Student Administration
Define Identification Categories. Flag the option “ID unique”. This functionality is a general BP
feature and independent of the SLCM duplicate check.
© SAP AG
IHE102
4-18
4 .2 St udent M ast er Da t a – Conve rsion of pe rsona l
I D numbe r and the BP ide nt ific at ion num ber
Conversion Report to synchronize the SLCM Personal ID number field with a
BP Identification Number
The report synchronizes the BP ID Number and the ID Number on the Personal
Data tab (infotype 1702)
Different ID types can be defined, e.g. Social Security Number
Data ranges can be maintained (allows for multiple values based on the date).
Use case example: The report is useful in integration scenarios, e.g. with a
CRM system. Prospects are generally first created in CRM as ‘Business
Partners’. The SSN is usually stored as BP ‘ID Number’. When the prospect
applies and gets transferred to a ‘Student Record’ in SLCM, the SSN should be
automatically populated in the ‘Personal Data’ tab.
Prerequisite for running the report is that Customizing to define which BP ID
number should be synchronized with the Personal data has been completed!
© SAP 2009 / Page 1
The report is available in the IMG for Student Lifecycle Management
Master Data in Student
Lifecycle Management
Students Students as Business Partners The Business Partner in
Student Administration
Synchronization of Personal and Business Partner ID Numbers.
Prior to using the conversion report, the following customizing steps must be completed:
• Define Business Partner Identification Types
• Define ID Type in IMG for SLCM
The BP in Student Administration
Master Data in SLCM
Students
Define ID Type for Synchronization
Student as BP’s
– Enter an ID Type and Description
– Activate the Flag “Maint. Date” if required (see Notes 1 and 2 below)
– When this Flag is activated, the ‘PRDNI’ field becomes READ-ONLY, and is automatically
updated from the BP ID Number.
It is NOT recommended to use the ‘Maint. Date’ Flag for this synchronization. The intent is for this
to be used for a PERMANENT identifier (such as a Social Security Number). Any data change for
these numbers is generally treated as a data correction, and should be valid for all time periods. If
you choose flag ‘Main. Date’, you must enter date ranges when entering data in the BP ID tab.
Running the Conversion Report:
• Go to transaction SA38 or SE38
Report Name: ‘RHIQ_CONVERT_SSN_1702_BP’ (allows
to perform a data conversion on existing data after making the settings) Choose ‘Selection
Method’ STNS and enter a Student Number Select your BP ID Category Select [Execute]
The report may first be run in “Test” mode.
The report populates the BP ID Number from historical ‘PRDNI’ field contents – not the other way
around! Benefit: historical data is kept; BP can be used in Search Help, RFCs, Duplicate Search
Only records without time gaps for field ‘PRDNI’ in Infotype 1702 will be converted.
© SAP AG
IHE102
4-19
4 .2 St ude nt M a st e r Da t a – Alumnus
Alumnus
Alumnus = A student's status after leaving the institution
Alumnus data
Student's organizational unit (for example, faculty)
for which the former student is counted as alumnus
Start and end dates of the student's academic career
© SAP 2009 / Page 1
When students are de-registered from the university, that status can be maintained in the Business
Partner data of the student. Students can become an alumnus of the organizational unit to which they
belonged. The student status in the student header changes to alumnus.
A student becomes a member of the alumni if:
• You set the alumnus flag on the de-registration screen. The system updates the data field on the
alumnus page automatically.
• You maintain the alumnus data manually using ‘Insert relationship’ and create relationship 541
"is alumnus of" between the student and an organizational unit.
In both cases, the system status Alumnus is written and can be displayed in the student header.
Note: To support business processes in the area of alumni management and fundraising, SAP offers
a fundraising management software. This solution is not part of the SAP for Higher Education and
Research Solution Map. To find out details go to www.sap.com/services/customdev.
© SAP AG
IHE102
4-20
4 .2 St ude nt M a st e r Da t a – Re la t e d Pe rsons
Related Persons
Persons related to the student (for example, mother, father, etc.)
Relationship type (for example mother, father, etc.)
Legal responsibility
Emergency contact
Related persons are represented as Business Partners
and linked to the Student.
© SAP 2009 / Page 1
On the Related Persons tab page, you can maintain data of student relatives or other contact persons.
If the related person is a student of the institution, use “Create the Relationship’. You can search for
the BP record.
If the related person is an external person, create the related person using ‘with new related person’.
The Related Person Data screen appears and you can maintain all necessary data for the new related
person.
When you maintain related person data for students:
• A BP is created for every new related person.
• Relationship 521 between the student (object) and the related person (BP) is created.
Whenever a BP has a relationship ‘is related to a student’, the BP role Related Person (PSCI10) is
automatically assigned to this BP.
© SAP AG
IHE102
4-21
4 .2 St ude nt M a st e r Da t a – T opic Sum ma ry
You are now able to:
Explain the features of the Student Master Data
record
Enter and maintain Student Master Data
Work with the Student Master Data record
© SAP 2009 / Page 1
© SAP AG
IHE102
4-22
4 .3 St ude nt File – T opic Objec t ive s
At the conclusion of this topic, you will be able to:
Explain the content and use of the Student File
Know which functions are available in the Student File
Adapt the Student File layout to your needs
Create notes for students
Enter information on a student’s death
Enter information about exchange programs or exchange
students
Install a data privacy warning to appear before student data is
accessed
© SAP 2009 / Page 1
© SAP AG
IHE102
4-23
4 .3 St ude nt File – Ove rvie w
The Student File is the access point to all student and study-related data:
University
Structure
(HR)
Academic
Structure
Student File
Events
Resources
Alumn i
Recr uitm ent
Student
Account
ing
Stud
ent
Adm ission
Equiv alen cy
Deter min atio n
Student
Administr
ation
Registr ation
App
licat
ion
Rep
orti
Aca
ng
dem
ic
Cale
nda
r
Course
Regi str ation
Exami nat ion
&
Grading
Mast
er
Data
De-registration
Aca
dem i
c
Stru
Rule
ctur
s&
e
Reg
ulati
ons
Even
ts
Acade mic
History
of
Study
Reso
urc
es
Event
Plannin
g
Re-registration
Graduat ion
Teachin
g&
Study
Degr ee
Aud iting
Chang e
of
Progr am
Progr ession
Academic
Admission
Registration
Bookings
Grading
Progression
Academic work overview
etc.
Background
Student Lifecycle
© SAP 2009 / Page 1
The results of all student lifecycle processes are kept in the student file.
You may access the student file in two ways:
• SAP Menu
Student Lifecycle Management
Student File
• Transaction PIQST00
© SAP AG
IHE102
4-24
4 .3 St ude nt File – Re la t ionships c rea t ed w it hin
a dm inist ra t ive proce sse s
Organizational Unit
(University)
Academic
Calendar
Organizational Unit
(Faculty, etc.)
Application
Applies to
Accepts
Earns
Business
Partner
Degree
Program of Study
Pursues
Applicant/
Student
Module Groups
Is booked on
Transcript
External Educational
Institution
Modules
Passes
Event Package
Events
External Subject
External Qualification
Rules
© SAP 2009 / Page 1
The relationships above are created during student administration processes.
To display relationships:
• Enter transaction code SE16, table name "T777V“, and choose Table
Table contents.
The names of relationships which originate in Student Lifecycle Management start with 5xx. Check
this in Customizing by choosing: SLCM Master Data in SLCM
Academic Structure
Organizational Structure
Organizational Management
Basic Settings
Data Model
Enhancement Relationship Maintenance Maintain Relationships.
Some of the relationships used in Student Lifecycle Management originate in other applications (e.g.
relationships between organizational units
OM).
Note that this is not a complete overview of relationships that can exist in Student Lifecycle
Management but only a selection.
© SAP AG
IHE102
4-25
4 .3 St ude nt File – Cust ome r-De fine d Ta b Pa ge
La yout
SAP Title
Customer
Title
Change tab page
sequence
Add customerspecific subscreens to
SAP tab pages
Add new customerspecific tab pages
© SAP 2009 / Page 1
The Student File and Student Master transactions can contain up to twenty tab pages with
information on the student. You can adjust the student file layout to the institution's requirements by
changing the tab pages using the customizing path: Master Data in Student Lifecycle Management
→ Students → Customizing Tab Pages in the Student File: In this IMG section you can:
• Replace standard tab page titles with customer-specific titles
• Change the sequence of tab pages within a tab page group
• Hide tab pages which you do not need
• Add new customer-specific tab pages
• Add new subscreens to SAP tab pages
Whether or not a tab page allows program selection is defined in the system for all tab pages. For
example, on the registration tab, program selection is allowed, on the status tab, it is not.
© SAP AG
IHE102
4-26
4 .3 St ude nt File – St udent N ot e s Conce pt
Basic Concept:
Each note is assigned to a note type. There are two note type categories:
User-defined notes
Predefined notes
For both categories, you can set up the following note type references:
Reference to an academic period (year/session)
Reference to a program
Reference to a stage (program dependency)
Reference to a program type
Student Note Maintenance Dialog
The screen attributes of the reference fields are determined by note type attributes.
Items in the stage list box refer to the program specified in the Program field.
The text of predefined note types can only be displayed.
You can enter the note text for a user-defined note.
© SAP 2009
2008 / Page 1
User-defined notes: Users enter the note text when they create notes for students.
Predefined notes: The note text is predefined in Customizing.
The Student File contains a Note Overview. Notes are stored in infotype 1707 for the student (object
type ST), or for the study object (object type CS) when the note refers to a program.
Menu Path:
• From the Student File or Student Master Data select: Goto
© SAP AG
IHE102
Note Overview (Ctrl+F12).
4-27
4 .3 St ude nt File – St udent N ot e s
I m ple me nta t ion
Examples
Possible Note Types are:
Appraisal Notes
Graduation Notes
Disciplinary Notes
Progression Notes
You can set up these Note Types as follows:
Note Type
Note Category
Note Reference
Disciplinary note
User-defined note
(no note reference allowed)
Academic honors
Predefined note
Program type (optional)
Acad. period (required)
© SAP 2009 / Page 1
There are no Note types defined in the standard system. Customers set up their own notes.
You can restrict user access to Note types using PLOG authorizations.
Note types are subtypes of infotype 1707.
© SAP AG
IHE102
4-28
4 .3 St ude nt File – St udent ’s Dea t h
If you need to record the death of a student in the Student File:
Enter death data in Student File
Student status is set to “deceased”
Activity document is created
The status “deceased” can be used to block other processes in the same
way as holds.
© SAP 2009 / Page 1
Information on a student’s death can be entered in the Student File as follows:
1. Enter the death data via the menu path: Student Death
• Date of death (optional)
• Date on which death was entered (mandatory)
2. System Reaction
• The system sets and displays the status deceased (infotype 1728 - Status Indicators)
– Start date of status deceased = date of death
– If no date of death is available, the start date = entry date
– An activity document is created.
3. It is possible to change the deceased date (e.g. in case of an entry error)
• New activity document is created
• Student status is updated
• If death data was deleted, the status deceased is set to inactive.
Notes:
You cannot enter the death date directly in the student master data. Data can only be entered in a
separate dialog because a deceased status is written.
No Customizing is necessary. The deceased status, which is displayed in the student header, can be
customized using the path: Student Lifecycle Management Master Data in Student Lifecycle
Management
Students
Status Display.
The deceased status can be used to block Student Lifecycle Management activities in the same way
as holds. Use Customizing path: Student Lifecycle Management
Processes in Student Lifecycle
Management
General Settings
Statuses
Assign Status Types to Callup Points.
© SAP AG
IHE102
4-29
4 .3 St ude nt File – Addit iona l Func t ions
1 Duplicate check
Identifies existing records when you create a new Student Master Record
2
Search help in the Student File via Object Manager offers several options
3 Personalization
Personalized default search criteria (student status)
Default tab page for student file and master data
Default compressed student header in student master data
4 Show technical information of student data
Student File – Utilities – Technical Information => shows student number, BP
number, accounts, studies (CS), etc.
© SAP 2009 / Page 1
The system automatically performs a duplicate check when a student master record is created to
avoid the creation of two identical records. When performing the duplicate check, the system
determines potential identical records based on the following subsets (always for the current system
date):
• All students with the same identification number
• All students with the same birth date, similar first names, last or birth names
• All students with the same first and last name
Note: Institutions can adapt duplicate checks to their requirements by using BADIs from the Central
Address Management. Modifications can be made but these represent a change of the standard.
You can search for students using the search functions in the Object Manager (search term,
structural search, free search):
• Each time you access the Student File, the Object Manager repeats the last search. This can be
time-consuming in large databases. If you wish to deactivate the last search, you can set the User
Parameter OM_OBJM_NO_LAST_SEAR to ‘X’ (Follow the instructions in CSN notes 410865
and 403526.)
• The validity concept for the status determines which students the system looks for when you
conduct a search. When you select students based on personal data and the status, the system
displays only those students for whom the required status is active.
• To create your own search variant, choose Create Search Variant in the Object Manager.
You can store personalized student file settings. In addition to the default student file and student
master data tab pages, you can store the student statuses you want to use as default criteria. To enter
personalized settings, go to Student File and choose: Settings
Personalization.
© SAP AG
IHE102
4-30
4 .3 St ude nt File – Ac ade m ic Work Ove rvie w
Academic Work
includes
Transferred
Work
Module Work
Transferred or
Completed
Completed
Work
Miscellaneous
Academic Work
Transferred or
Completed
A record of all academic work a student has
achieved can be displayed with the
Academic Work Overview function in the
Student File:
Module work and miscellaneous academic work,
both completed and transferred, can be
displayed.
Selection criteria can be used to filter academic
work records.
Different performance indices can be calculated
dynamically and displayed for a selected
academic work record (see Performance
Indices).
Details can be displayed for each record.
© SAP 2009 / Page 1
All academic work records of a student can be viewed with the Academic Work Overview function
(Ctrl + F11) in the Student File. The following processes can be the source of this data:
• Module Booking and Grading: completed and booked modules are shown in the academic work
overview.
• Equivalency Determination: transferred academic work = academic work from external
institutions which has been accepted as internal and marked as “transferred” (modules,
qualifications etc.) are shown.
• Graduation / Qualification Conferment: other academic work which is shown as qualifications
are displayed.
The Academic Work Overview can also be accessed directly outside the Student File:
• Menu: SLCM
Student Administration
Academic Work
• Transaction ‘PIQSTAW00’
When Academic Work needs to be maintained directly, validations can be performed via BAdI
‘HRPIQ00AW_VALIDATION’ . All academic work fields are available there. Example: you need
to verify that credit values match module credits. IMG for Student Lifecycle Management Master
Data in Student Lifecycle Management Students
Adjustment of the Student File BAdI:
Academic Work Validations.
Default values for Academic Work can be populated once a Module is selected via BADI
‘HRPIQ00AW_DEFAULT_DATA’. IMG for Student Lifecycle Management
Master Data in
Student Lifecycle Management Students
Adjustment of the Student File BAdI: Default
Academic Work Data.
Credit Derivation rules can be defined in the IMG (previously this had to be done via the BAdI for
Credit Derivation in Appraisals. IMG for SLCM Processes in SLCM
General Settings
Derivation of Credits.
© SAP AG
IHE102
4-31
4 .3 St ude nt File – Ex t e nded M a int enance
Dia log
The Student File contains two dialog transactions:
The “standard” student file dialog transaction (PIQST00)
Extended maintenance dialog transaction PIQST10 offers additional maintenance functions
The Extended Maintenance dialog transaction contains additional expert
functions for editing academic work records:
You need special authorization to access the extended maintenance.
The extended maintenance dialog should only be used in exceptional cases; e.g., to correct
errors or change data which cannot be changed with standard functions.
Warning:
Academic work records which are edited in the extended maintenance dialog
can no longer be edited in the module booking or appraisal dialog!
© SAP 2009 / Page 1
Most users at the university will be authorized to use the standard student file transaction. Only a
few expert users will be entitled to create and maintain data using the extended maintenance dialog
of the student file; for example, to correct errors, enter missing data, etc.
You can access the Extended Maintenance Dialog in different ways:
• Menu: Student Lifecycle Management
Extended Maintenance Dialogs
Student File
(Extended Maintenance), or
• Student File (PIQST00): Edit
Switch Maintenance Dialog
• Transaction PIQST10 (Requires authorization)
Functions in the Extended Maintenance Dialog for Academic Work:
• Create and edit academic work records (activity documents are created)
• Physically delete academic work records from the system (an activity document is created)
• Create and edit module work and miscellaneous academic work, both completed and transferred
• Edit certain appraisal data (see Appraisal unit)
• Perform checks which guarantee technical and data model consistency (always executed).
Business checks (like VSR checks, checks in customer exits, capacity checks and booking time
limits for module work) are not executed
• Note: Academic work that was changed in transaction PIQST10 can only be displayed in the
module booking or appraisal dialogue. Further changes can only be made in the Extended
Maintenance dialog.
• You can access Academic Work in the Extended Maintenance transaction directly:
– Menu: SLCM
Extended Maintenance Dialogs
Academic Work
– Transaction ‘PIQSTAW10’
© SAP AG
IHE102
4-32
4 .3 St ude nt File – V isit ing St udie s
Visiting Studies is the term used in Student Lifecycle Management to refer to students who
spend part of their studies at an external institution. Universities usually administer related
administrative processes within “Exchange Programs”.
Data on visiting studies in the Student File may include:
Information on exchange students who come from another Higher Education institution
Information about the exchange programs a student attended during his or her studies
© SAP 2009 / Page 1
Main characteristics of Exchange Programs:
• Represented by object type SX
• Can be offered by multiple institutions which can be either external or internal Organization
Units (Object Type EO or O)
• Can offer several Programs of Study (object type SC)
• Can be linked directly to an Academic Calendar
You can maintain information about the academic periods that students spent at another institution,
e.g. as part of an exchange program between Universities.
Business Scenario: As part of a three-year Undergraduate program, a student is required to spend
one year studying at another institution as an exchange student.
Furthermore, you can maintain data about exchange students who come from other higher education
institutions to study at your institution. These students records are maintained with a different
student status (e.g. exchange student) which allows to set different rules, fees, etc. for them. Within
the Student File, you can maintain information about their home university with the Exchange
Program function.
© SAP AG
IHE102
4-33
4 .3 St ude nt File – V isit ing St udie s: Ac a de m ic
Da t a
EXCHANGE
STUDENTS
Maintained in the student file
Incomi
ng/
Outgoi
ng
University Name
Ex. Program
Name
From
Acad. Yr
From
Acad.
Session
To
Acad.
Year
To Acad.
Session
IN
Univ. of Paris
BA
Languages
2008
Spring
2008
Autumn
OUT
Unv. of Madrid
BA
Languages
2009
Winter
2009
Spring
© SAP 2009 / Page 1
Exchange Programs are administered in the Student File using the tab [Visiting Studies].
Two detail screens are provided for maintaining internal and external study data.
The ALV is defaulted to sort by incoming and outgoing studies.
Click the Icon [Create Visiting Studies] – the following two options will be presented:
• “Create Visiting Studies“ (incoming students)
• “Create Visiting Studies“ (outgoing students)
The Exchange Program information is kept in the following infotypes of the Object ”Exchange
Program“ (SX):
• Exchange Program Data (1713)
• Description (1002)
• Requirement Catalog (1778)
• Relationships: Uses Calendar (A510), is Offered by EO/O (A534), contains Program (B535)
Customizing:
The IMG settings for defining Exchange Program attributes are as follows:
• Student Lifecycle Management
Master Data in Student Lifecycle Management
Structure
Exchange Programs
Academic
• Student Lifecycle Management
Master Data in Student Lifecycle Management
Background External Organizations
Educational
© SAP AG
IHE102
4-34
4 .3 St ude nt File – M ult iple Advisors (1 )
Advisors are employees of the University who are, in most cases, assigned to a department
as a teacher or professor.
Several advisors can be assigned to a student, e.g. as Employees, External Persons,
Senior Students or Business Partners.
Different functions like Major advisor, Honors advisor, Athletic advisors are available to
categorize the advisor assignment according to their role. In addition, customers can
maintain their own advising functions.
Person(P)
Person
External
person
Advisor
Functions
Student
Advisors
Student
Student/Advisors
Relationship
Position
Business
partner
© SAP 2009 / Page 1
Advisor (s) Tab in the Student File
• The advisor assignment is/are created via Relationship/Subtype A515
• Functionality allows for assignments to be delimited or deleted.
Note: In order to maintain relationships between ST (Student) and P (Advisor) after the student left
the university, the Post Processing Framework can be used: a function module
(HRIQ_ADV_ADVASSGNMT_DELETE_RFC) can be called via PPF to maintain the relationship
upon de-registration.
Note: If you have maintained an advisor prior to EHP3, you should write and run a report that
transfers that advisor relationship to the ‘Main’ advisor function. If not, the ‘Old’ advisor
relationship is still available in the ‘Study Data’ tab.
© SAP AG
IHE102
4-35
4 .3 St ude nt File – M ult iple Advisors (2 )
Academic Advisor Data Maintenance
Advisors are assigned via the “Advisor” tab in the Student File.
Only one Main Advisor is allowed per student.
The name of the Advisor is listed in the header of the Student Master
Available on Study Data Tab in the Master Data in display mode only
The Advising Context describes the context of the advising
The Advising Function describes the roles or objective of the Advising Assignment
© SAP 2009 / Page 1
Assignment of Advisor:
• 1. Select the tab [Advisors].
• 2. Select the ‘Create Advisors’ button in the advisors overview (ALV) display.
• 3. A new screen pops up for creating advisor assignment.
• 4. Select advisor type for “Person” from the drop down or list box.
• 5. Select the advisor (advisor ID).
• 6. Select an advisor function and automatically the advising context type is selected.
• 7. Select the advising context object (Program, major, etc.).
• 8. Save the advisor assignment.
Customizing: IMG for Student Lifecycle Management
Master Data in Student Lifecycle
Management
Students
Several Advisors
• 1. Define Advising Context:
• You can define different PD (Personal Development) objects like Program of Study (SC) or
Specialization (CG), for example.
• You can define table values as a context, such as “Sport Types”. You then have to specify the
table name and key fields.
• 2. Define Advisor Functions:
• Create an advising function (e.g. Major Advisor) and attach the context type.
• You can set an advising function as main function, but it must be then assigned to the main
advisor as well.
• 3. BADI: Customer Defined Checks for advisor assignment (see IMG link above):
• You can maintain own business checks via this BADI: It allows for a customer-defined check
that would result in an error if the incorrect advisor is assigned to the student.
© SAP AG
IHE102
4-36
4 .3 St ude nt File – Da t a Priva c y Wa rning
Data Privacy Warning
When a student requests a privacy agreement, the university must prevent information on the
student from being released externally.
The system displays a warning message (= data privacy warning) when users access private
data of students who have a privacy agreement with the university.
Details of the data privacy warning:
Different privacy levels => different messages for each level
When the warning is to be displayed (based on transactions)
Which students have requested data privacy
Note: Warning message does not block access to data!
© SAP 2009 / Page 1
Regulations, or a request by students, may oblige you to treat student data with special
confidentiality. For example, not giving any student information to third parties if they fall under a
special privacy agreement.
A data privacy level can be assigned to the student to trigger a warning message when users access
their data. This allows to map the data privacy agreements between students and the university in the
system.
You assign the student a data privacy level (which determines the relevant privacy warning) on the
Additional Data tab page (student master data).
Privacy levels and the corresponding privacy warnings can be customized. You make these settings
in Customizing using the menu path: Student Lifecycle Management Master Data → Students →
Data Privacy Levels and Warnings.
You can also choose the transaction(s) in which the privacy warning should be displayed. A warning
is not mandatory.
When a user accesses a transaction which is subject to a privacy warning, the system displays a
dialog box containing the relevant warning. This warning must be confirmed before continuing. The
warning does not stop the user from displaying or changing data.
Note: If you want to hide data from users, you must use the authorization concept.
© SAP AG
IHE102
4-37
4 .3 Ove rvie w St ude nt File – T opic Sum ma ry
You are now able to:
Explain the content and use of the Student File
Know which functions are associated with the student
file
Adapt the student file layout to your needs
Create notes for students
Enter information on a student’s death
Enter information about exchange programs or
exchange students
Describe the role of a data privacy warning in regards
to accessing student data
© SAP 2009 / Page 1
© SAP AG
IHE102
4-38
4 . St udent Da t a M a int enance – U nit Sum m a ry
You are now able to:
Understand how a student record is created
Explain and use student master data
Use the student file
Describe the features of the student file
Use functions of the student file and student master data
Create student notes
Maintain exchange program information
Use specific student file functions such as data privacy
warning
© SAP 2009 / Page 1
© SAP AG
IHE102
4-39
© SAP AG
IHE102
4-40
I H E1 02 St udent Lifec yc le M anagem ent :
5 . Adm issions
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009
© SAP AG
IHE102
5-1
5 . Adm issions
Content:
5.1 Overview of the Admissions process
5.2 Admissions Audit Introduction
5.3 Web Application
© SAP 2009
© SAP AG
IHE102
5-2
5 . Adm issions – U nit Obje c tive s
At the conclusion of this unit, you will be able to:
Explain an Admission process for new students
Outline how the Admissions process is implemented in
Student Lifecycle Management
Explain the principles of a web application using SAP's
generic web application concept (Internet Service
Request tool) & Adobe Forms
Process Admission applications in the Student File
Understand the automation of the Admissions process
with Admission audits
Understand how you can use dunning for outstanding
requirements like missing documents
© SAP 2009
Relevant terminology in this chapter:
• Online Form: HTML, Adobe, or other input form for data entry
• Remote Function Call: Secure mechanism for passing data from the form to the back-end system
• Notification: ‘Data container’ for application processing
• Workflow Template: ‘Master controller’ for admissions process
• ISR Scenario: Defines characteristics (data) and actions related to application processing
• Applicant Record: Same as a ‘Student Master Record’ (new or existing)
• Admissions Record: Specific admissions status for a Program of Study
• Assessment Process: Handles any Admissions Audit
© SAP AG
IHE102
5-3
5 .1 Adm issions Ove rvie w – Applying for
Adm ission
Options to apply for Admission:
Indirectly via a central institution (e.g. UCAS, ZVS)
Directly by means of a paper application
Directly by means of a web application
Who processes the application?
University
Checks minimum prerequisites
Checks additional prerequisites if seats are restricted
Central institution
Informs the University about results of Admissions processing
© SAP 2009
The Admission process is based on Programs of Study.
• Students can apply for Admission in the following ways:
– Indirectly through a central institution (UCAS in the UK, ZVS in Germany). These
institutions process the Admission applications and the university decides about the
Admission of the student based on their policy.
– Directly to the University by means of a paper or web application form.
• When students apply to a University, an Admission approval process is started. During the
approval process, the application is checked and a decision is made.
• The Admission process can take place as result of recruitment activities of a University. The
recruitment process begins when a prospective student first contacts the institution and ends with
the enrollment of the student at the University.
© SAP AG
IHE102
5-4
5 .1 Adm issions Ove rvie w – T opic Objec t ive s
At the conclusion of this topic, you will be able to:
Explain the Admissions process and its different process steps
in general
Understand how the admission process is managed in Student
Lifecycle Management
Explain the concept of Admission Audit
© SAP 2009
© SAP AG
IHE102
5-5
5 .1 Adm issions Ove rvie w – Adm ission Proce ss
The Admission process represents the approval procedure for applicants and
can be handled in a variety of ways:
Manually: Admissions officers check applications and enter results into system
(Partly) Automated: the system supports Admissions officers in application
checking
Automated: the system executes Admission steps in the background
Interfaces are needed between the Student Administration System and
External Institutions (e.g. clearing institutions for applications, schools and
other higher education institutions for transcripts )
Recruitment systems
© SAP 2009
The automation of the Admission process allows the University to process straightforward cases
automatically with the system performing the Admission checks.
Integration of web-based Admission applications allows an easy application procedure for
applicants and less effort for administrative staff.
Cases in which general Admission criteria are not fulfilled are directed to an Admissions officer
who handles them manually
Admission records can have Assessment Processes attached (i.e. mandatory admissions audits,
Audit Type ‘4000’)
Student Lifecycle Management supports the automation of Admission processes and execution of
Admission steps in the background through a workflow. A workflow template is delivered for
handling the undergraduate admissions process, including resolution of possible duplicate records.
If an automation of the Admission process is required, you have to take care for the interfaces to
other systems. This might for example be relevant for interfaces which receive standard Admission
tests such as SAT in the US. External systems may be country-specific, for example, for clearing
institutions such as UCAS in the UK. Furthermore, it might be required that the system supports
transcript exchange between schools and higher-education institutions.
Student Lifecycle Management delivers the following interfaces:
• UCAS interface (country-specific)
• Transcript exchange (see information about Student File – external transcript)
BC sets are provided to accelerate the configuration of admissions-related processes. For details
regarding this and the Admissions workflow in Student Lifecycle Management please check the
Admissions Cookbook which is available on the Business Process Expert (BPX) platform for Higher
Education: www.sdn.sap.com/irj/bpx/highered > Knowledge Center -> Key Topics -> Student
Lifecycle Management Best Practices, Implementation Guidelines, and Tutorials -> Admissions
Cookbook for Student Lifecycle Management.
© SAP AG
IHE102
5-6
5 .1 Adm issions Ove rvie w – Adm ission Proce ss
St e ps
Tasks During the Admissions Process:
Receive application and enter data in administrative system
Receive updates on application or withdrawal from applicant
Perform formal and academic checks of the application:
Check completeness of application
Check if all relevant data has been received
Check if all required documents have been received
Check deadlines
Check minimum (academic) prerequisites
Check program or program type prerequisites
Check program capacity restrictions
Execute selection procedure if program is restricted
Send notifications to students (correspondence)
Request additional information
Deny Admission
Approve Admission and send registration documentation
© SAP 2009
During the Admission approval procedure, various checks must be performed:
Formal checks:
• Has the application been received in time?
• Does the application contain all required information?
• Has the applicant submitted all necessary documents?
• Has the applicant’s identity been validated?
Academic checks:
• Does the applicant fulfill the minimum Admission prerequisites for a University (for example,
does the applicant’s academic history meet the prerequisites and has the applicant passed the
required Admission tests)?
• Does the applicant fulfill the additional prerequisites for the requested program or program type
(for example, special assessments, interviews, grades, etc.)?
Check capacity restrictions: If the capacity of a program is limited, not all applicants who fulfill the
prerequisites can be admitted:
• Check whether the capacity of the program of study is limited / not full yet.
• Define selection criteria and sort the list of applicants accordingly.
• Define due dates when students are selected and additional due dates to fill in free seats.
Before creating an Admission application, the system checks if other applications for the same
student or Program and period exist.
The system runs a duplicate check for existing students when it creates a new record from the
application. Function module HRIQ_STUDENT_SIMILAR_POPUP2 checks name, birth date, and
student number.
© SAP AG
IHE102
5-7
5 .1 Adm ission Ove rvie w – Support of
Adm issions Proce ss
How Student Lifecycle Management supports the Admission process:
Receive application and store application as XML file
Create an applicant record:
Create ST and BP with status “applicant”
Create a Study Object (CS):
Create relationship “applies for” between CS and ST in status “planned”
Create relationship between CS and applied SC
Initiated by
Admission
Officer
Triggered by
applicant
automated steps in
Admission workflow
Check application data:
Create assessment process
Perform Admission audit
Check applicant data against rules (Rule containers attached to the academic structure)
Approve or reject the application
Status of relationship (applies for) is changed to “active”/“rejected”
Student status is changed to “admitted applicant” or “rejected applicant”
© SAP 2009
An attribute in the master data of the programs of study indicates if the program is admissionrestricted or not. If it is admission-restricted the registration process checks if the student has an
Admission to the program of study. If this is not the case, registration will fail.
Attributes referring to the Admission process are maintained in: relationship 530.
Student Lifecycle Management supports the Admission process from beginning to the end. The ISR
(Internet Service Request) is used within the application. If a workflow has been set up, different
activities can be triggered when an application is received and/or when the Admissions officer
executes different tasks. For example, these activities can start a transaction to create applicant
master data in the Student File.
When a student’s application for Admission and the required documents are received, Admissions
officers can create the student master record using the Student File. External achievements that
students have accomplished at other educational institutions can be entered. Documents can be
attached to the Student File using SAP Records Management.
Admission requirements will be checked against the applicant data if rules have been defined. For
administering the check of requirements, the concept of audits and assessments can be used. In the
[Admissions Tab] on the Student File’s, an Admission audit can be performed. The result then leads
to the “approval” or “rejection” of the Admissions application.
© SAP AG
IHE102
5-8
5 .1 Adm issions Flow Dia gra m
© SAP 2009
Note: Application (notification) Processing is separate from the admissions record (although they
can be linked).
You must create and assign a number range to your Notification Type before you can save a
notification. Use IMG Path: Cross-Application Components Notification Notification Creation
Notification Type Define Number Ranges.
Also you need to set up screen areas/layouts for notification processing via IMG Path: CrossApplication Components Notification Notification Creation Notification Type Define
Screen Templates Define Screen Areas and Tabs.
You can check the contents of your notification with RFC HRIQ_SCM1_READ_RF.
© SAP AG
IHE102
5-9
5 .1 Adm issions Ove rvie w – U se r I nt e rfa ce
Functionality:
An applicant can apply for different programs of study for certain sessions offered
by the University.
The University can admit or reject the applicant.
The Admission Application or Admission offer can be accepted or declined by the
applicant.
The program of study, the session or the application data of the Admission
application, Admission or rejected-admission application can be changed.
User Interface:
Web interface for the Admission Application
View application (Admission officer), withdraw application, accept or decline offer of Admission
(applicant)
Directly in the Student File, Admission tab
Create, change and delete Admission Application
Execute Admission (admit, reject) and undo Admission
Withdraw / decline / reverse decision (initiated by applicant)
© SAP 2009
If an appropriate Self-Service has been set up, the applicant can:
• Change Admission application
• Withdraw Admission application
• Accept an Admission offer
• Decline an Admission offer
• Reverse decision of withdrawal or declination
In the Student File, the admission officer can process Admission applications and work on the
Admission process directly from the [Admission Tab]:
• Create, change and delete Admission application
• Execute Admission, such as “reject” or “approve” an Admission application
• Undo “rejected” admission application
• Change Admission (change of program in Admission, undo Admission)
• Actions initiated by the applicant can also be performed directly in the Student File, such as
“Withdrawal of Admission Application“, “Declination of Offer“ and reversal of these decisions.
The cancellation of the Admission application is supported
© SAP AG
IHE102
5-10
5 .1 Adm issions Ove rvie w – St a t us a nd
Ac t ivit ie s
Admission Status:
The admission application status reflects the decisions made on the Admission:
Admitted, rejected
Status + status supplement (for certain status, the supplement gives further information)
The applicant status reflects the status of the applicant and corresponds with the
Admission application status.
Example: Admitted applicant
Activities:
An activity represents a process step made within the Admissions process.
Example: approve application, reject application, withdraw application
An activity document is created for each activity to keep a change history.
For each process step, call up points are available, which can be used to start a
VSR rule-check or block the process.
© SAP 2009
When an Admission application has been denied (rejected by the University or declined by the
student), the status of this Admission application is set to “rejected/withdrawn”. To differentiate
whether the rejection was initiated by the University (reject application) or by the applicant
(withdraw application or decline offer), the status supplement field is used. This field will only be
filled if the Admission application was withdrawn or the Admission was declined: In case of status
“rejected/withdrawn” + field status supplement =
• ‘empty’: the University has rejected the Admission
• ‘Admission application withdrawn’: the application was withdrawn by the student
• ‘Admission declined’: the Admission offer was declined by the applicant
An activity is provided for each process step, e.g. “Withdraw Admission Application” (AD13).
When an activity is performed, an activity document is created.
Activities permitted by the system depend upon the Admission application status:
• Created status: Withdraw Admission application activity
• Approved status: Decline offer of Admission activity
A self-service Web Dynpro is available for applicants to see the overall status of submitted
admissions applications (PIQ_ST_ADMAPPLICATION). You can allow the system to
automatically determine the applicant from the User ID. This Web Dynpro links to the Admissions
Audit Self-Service Web Dynpro and only shows admissions data that is based upon a Notification.
Admissions entries created directly in the Student File will not appear.
Enrollment Confirmation: SLCM contains an Adobe PDF-based form, that can be included in an
applicant's acceptance packet. The correspondence form allows accepted applicants to confirm their
upcoming enrollment at the University by paying a deposit. In that case you need to maintain the
Time Limit for the Enrollment Deadline via SLCM Processes in SLCM Admissions,
Registration, and De-registration Admission Create Time Limit for Enrollment Confirmation
Fee. Note that you must handle the actual fee processing on your own.
© SAP AG
IHE102
5-11
5 .1 Adm ission Audit – Adm ission Audit
Business Scenario:
A Student is applying for Admission to a Program of Study. The Program of study
has specific requirements which must be fulfilled by the applicant.
Admissions Audit compares Master Data of the applicant (such as External Academic
Work from transcripts, etc.) with the requirements for admission to the Program.
The checklist shows which elements have been met or not met.
The identified missing documents can be requested from the student if the relevant
checklist element is not met (dunning). For this case, you set the “reminder” flag.
Once requirements are met the Admission can be executed – (or otherwise).
© SAP 2009
The Admission audit is explained in detail in the: “Audits”.
Overview:
• The Admission Audit functionality has to be activated explicitly per program of study by setting
the indicator Use Assessment Process.
• You can perform admission audits by creating an assessment process with the requirements for
each admission application. Customer status can be used for each step within the application
processing.
– Assessment processes link requirement profiles and audit runs for process step „completion“.
– Checklists are represented by requirement profiles
If an assessment process has been defined, the system can automatically recognize and dun
outstanding requirements (missing documents) by marking requirement elements as „relevant for
dunning for Audit Type 4000” (Admission).
You can create a dunning notice with the dun inbound correspondence function which is available in
the Print Workbench. You can also use all of the other setting options that this tool offers.
The integration with Records Management offers institutions the possibility to create a file for
students in SAP Records Management to manage inbound and outstanding documents. The process
to generate such a file is started in the student file of Student Lifecycle Management. In Records
Management, documents can be associated directly via „Load Local File“, or scanning etc.
Records Management has to be activated separately in customizing and must be explicitly activated
per program of study. If it is not activated in customizing, there won’t be any impact.
© SAP AG
IHE102
5-12
5 .1 Adm ission Ove rvie w – T opic Summ a ry
You are now able to:
Explain the Admissions process and its different
process steps in general
Understand how the Admissions process is
managed in Student Lifecycle Management
© SAP 2009
© SAP AG
IHE102
5-13
5 .2 Web Applic a t ion – T opic Obje c t ive s
At the conclusion of this topic, you will be able to:
Briefly describe the Internet Service Request (ISR)
tool which provides a technical basis for different types
of application
Describe the concept of using Interactive Forms (PDF)
for Admissions application
© SAP 2009
© SAP AG
IHE102
5-14
5 .2 Web Applic a t ion – Online Adm ission
Applica t ion Proce ss
He submits an
application for admission
via the web
Andrew wants to study at a
specific university and decides
on a program of study
Study
information
and
documents
are sent to
Andrew
Application status
tracking
Online and system-supported
Admission process
in Student Lifecycle Management
Admissions Officer
approves application
Application
approval workflow
is started
Correspondence
is triggered for
the applicant (via
workflow)
Automatic
notification of
application receipt
Admissions Officer
receives application
in the inbox
Admission
Rules are
checked
automatically
© SAP 2009
Example Scenario of an admissions process via online Admission application:
Andrew wants to study at the University of his choice. On the University website he finds the
Admissions office page with a web application form. He fills out the form and sends it to the
University. He receives an e-mail reply confirming receipt together with a link to his application. He
checks the application again and finds an error, which he corrects and sends it back.
The University’s Admissions officer gets a notification in his workflow inbox informing him about a
new application. He opens the application data, takes a look at the original web application (already
the corrected version) and sees that the applicant forgot to specify the school from which he received
his final diploma. Within the application scenario, he sends an e-mail note to the student asking him
to provide the missing information. Then he creates an applicant record, which is supported by the
system, i.e., data from the application is used to create the application record as master data in the
system. When he receives the missing information, he starts the automatic rule checking process. He
immediately receives a message according to which the grade on the final diploma is below the set
minimum for the program the student applied for. He rejects the application, but sends the applicant
a note saying he could apply for another program with less stringent Admission requirements.
Andrew receives the rejection letter. He decides to apply for a different program and creates a new
web application.
The Admissions officer receives the new application. While attempting to create a new master
record, the system detects that a master record already exists for this applicant. A duplicate check
identifies the original (first) application of Andrew. The Admission officer has to decide if the
existing master record belongs to Andrew. If it does, no other student master record is created. If the
officer decides the existing applicant master record does not belong to Andrew, the system creates a
new record.
The remaining activities are done as described above.
© SAP AG
IHE102
5-15
5 .2 Web Applic a t ion – I nte rne t Se rvic e
Re que st
Applicants fill in and submit web application form (e.g. PDF based) within the
ISR scenario.
The application is
processed via
workflow
During the approval process
staff can execute tasks using
predefined actions within the
ISR scenario, such as:
• call ERP transactions
• send generated e-mail
• etc. )
Create master data and processing data in
Student Lifecycle Management ISR scenario
© SAP 2009
The Internet Service Request (ISR) is a toolset for creating web-based applications that integrate
directly with SAP ERP.
The Admission application is delivered as Interactive Form (Adobe). You can use the Adobe Forms
for ISR scenarios. Student Lifecycle Management includes an example form for Adobe PDF Forms
(ISHERCM_ISR_ADM_TMPL_PDF).
Prerequisites:
• The relevant ISR Customizing and form creation must have been completed.
• Assign your form to the entry type in the web “Adobe PDF”.
Use of Interactive Forms (Adobe PDF)
• Design application form
• Publish it on the web via ITS
Define ISR scenario:
• When you define ISR scenarios, you can specify that an Adobe Form should be used to enter
application data. You define the ISR scenario in Customizing for Internet/Intranet services under:
Cross-Application Components
Notification Notification Processing on the Intranet
Define Scenarios.
• The entry type in the Web is ‘Entry using Adobe PDF’. You assign your form against this.
• Student Lifecycle Management also contains an HTML page with an example ISR Admission
(Scenario PIQCMADM_DE). Customers will need to define their own HTML.
© SAP AG
IHE102
5-16
5 .2 Web Applic a t ion – I T S T e chnic a l V iew
SAP ITS
Internet
Services
SAP ERP
BADIs, BAPIs, RFCs
Business Document Service
Business Workplace
Student Lifecycle
Management
SR Scenario
Notifications
Workflow
(generated from
ISR Scenario)
End User
(Client)
Web Browser
© SAP 2009
Business Add-Ins (BADIs), Business Application Programming Interfaces (BAPIs), and Remote
Function Calls (RFCs):
BADIs are used to generate selections that retrieve content from SAP ERP and to perform data
validation in the web application.
BAPIs and RFCs allow for the exchange of data between the BDS and Student Lifecycle
Management. These are used to implement notification actions and tasks.
Business Document Service (BDS)
• In-progress applications are stored as XML files in the BDS.
Student Lifecycle Management
• Application content is transferred from the BDS to Student Lifecycle Management as part of
notification processing.
Internet Transaction Server (ITS)
• ITS hosts the Internet Service that makes the web application available to the public.
ISR Scenarios
• ISR Scenarios are created in SAP ERP using the transaction ‘qisrscenario’ and are published in
the ITS.
• The HTML templates that comprise the web application are defined here.
Notifications
• A notification is created when an application is submitted.
• The notification type is defined in the IMG. It specifies post-processing of the application,
including who receives the notification, the layout of the SAP Business Workplace screens, etc.
SAP Business Workplace
• Application processing takes place in the context of the Business Workplace.
Workflow
• A generic ISR workflow is triggered when the notification is created. It is also possible to use a
customer workflow.
© SAP AG
IHE102
5-17
5 .2 Web Applic a t ion – T opic Sum ma ry
You are now able to:
Briefly describe the Internet Service Request (ISR)
tool which provides a technical basis for different
types of application
Describe the concept of using Interactive Forms
(PDF) for Admissions Application
© SAP 2009
© SAP AG
IHE102
5-18
5 . Adm ission – U nit Sum m a ry
You are now able to:
Explain an Admission process for new students
Outline how the Admission process is realized in
Student Lilfecycle Management
Explain the principles of a web application, using
SAP's generic web application concept (Internet
Service Request tool) & Adobe Forms
Describe the process of handling admission
applications in the Student File
© SAP 2009
© SAP AG
IHE102
5-19
© SAP AG
IHE102
5-20
IHE102 Student Lifecycle Management:
6. External Work and Equivalency Determination
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009
© SAP AG
IHE102
6-1
6 . Ex t e rna l Work a nd Equiva lenc y
De t e rm ina t ion
Content:
6.1 External Achievements
6.2 Equivalency Determination
Transfer Agreements
Transfer Articulation
6.3 Customizing
© SAP 2008
© SAP AG
IHE102
6-2
6. External Work and Equivalency Determination –
Unit Objectives
At the conclusion of this unit, you will be able to:
Maintain external achievements in student master data
Maintain the required customize settings to store students’ external
achievements
Enter external institutional academic offerings in the system
Perform equivalency determination and maintain transfer agreements in the
system
Evaluate transfer work (transfer articulation) for a student based on external
transcripts
© SAP 2009
© SAP AG
IHE102
6-3
6. External Work and Equivalency Determination –
Business Scenario
You maintain and evaluate external educational achievements of applicants
seeking admission and of students
It is within your responsibility to maintain the offerings of other institutions in
the system and define the characteristics of external achievements
You need to maintain transfer agreements in the system
Your work involves evaluating student transfer work and determining internal
equivalencies with/without reference to transfer agreements
© SAP 2009
© SAP AG
IHE102
6-4
6.1 External Achievements – Topic Objectives
At the conclusion of this topic, you will be able to:
Understand the concept of external transcripts and external tests
Create external transcripts and external test results for a student in the
student master data transaction
Understand grade averages for external transcripts
Make the necessary settings before entering transcript and test result data
© SAP 2009
© SAP AG
IHE102
6-5
6.1 External Achievements – Student Master Data
Information stored in student master data:
Previous educational results provided by the applicant
High school information
Previous higher education results
Test results (e.g. admission tests)
External educational results can serve as a basis for admissions and equivalency
determination. They are
evaluated against admissions rules
the basis to determine equivalencies for transfer students
A Web Dynpro application allows Admissions Officers and other users to create
and maintain transcript data for applicants/students through self-service.
The following transcript data can be maintained:
Basic Data
External Subjects
External Qualifications
© SAP 2009
You can store the external educational history of applicants entering from high school as well as
those transferring to your institution from post-secondary institutions.
The external educational history can be used as input for:
• Admissions requirements: Admissions requirements can include school degrees, specific school
subjects or results from a former higher educational career.
• You can use the equivalency determination tool to acknowledge academic work done at external
institutions for your internal academic requirements.
• Detailed process steps to maintain transcript data via WebDynpro
PIQ_MAINTAIN_TRANSCRIPTS:
– Select student
– Display transcripts (incl. EO, category e.g. Undergraduate, issue date, status)
– Edit transcripts
– Edit basic data
– Edit subjects
– Edit qualification
– Edit transcript
– Review and save
– Completed
Note: External Organizations, External Subjects and External Qualifications must already exist in
the system or be created prior to entering the transcript data.
© SAP AG
IHE102
6-6
6.1 External Achievements – External Academic
Structure
Limited academic structure of an External Organization:
Object type EO:
High schools and transfer
institutions that students attended
prior to coming to the university.
Object type EQ:
External qualifications (EQ) are
qualifications students have
acquired during prior studies
(e.g. high school certificate,
degrees).
Object type SU:
External subjects (SU)
represent the subjects students
have taken at external
educational organizations or
previous school results.
© SAP 2009
External Organizations can also refer to testing agencies from which universities receive the test
score results of prospective students.
Transcript data that can be stored in the system includes:
• Issuing and transmitting organizations (object type EO)
• Transcript category, status, issue date
• Registration period of student at the ext. organization
• Grade averages as shown on original transcript
• Credit totals as shown on original transcript
• Additional academic information (e.g. rank in class)
• Degrees and/or qualifications attempted and earned, including grade (EQ)
• Specialization or program as discipline (CIP codes)
• Academic sessions the student was registered for (registration record)
• Stages the student was registered for
• Subjects taken, including original grades and credits
• Session in which subjects were taken
• Coded notes (e.g. disciplinary record)
• Free comments
© SAP AG
IHE102
6-7
6.1 External Achievements – External Organization
To set up an External Organization (EO), you have to...
Select the Category (and classification) of the EO
External Organization Data
Enter Unique Codes (for internal and external reporting)
External Organization Data
Indicate whether the institution is accredited
Define the Grading Scales and the Credit Types to be used by the EO
Scales/Credits
Maintain the Address (including country)
Address (Infotype 1028)
Enter Contact Persons
Contact Persons (Infotype 1756)
Link the Subjects and External Qualifications to an EO (Relationship – “offers”)
© SAP 2009
Customizing paths for maintaining data of External Organizations:
• Master Data in Student Lifecycle Management -> Educational Background -> External
Organizations-> Set Up Category Classifications and Set Up and Classify EO Categories.
Coding Systems: Many countries have one or more directories listing the schools, universities, and
other academic institutions within the country. These institutions each have their own unique
identification code and are required to report according to different systems (FICE, IPEDS, DUNS,
in the US). In Student Lifecycle Management, this is referred to as a coding system. You can assign
up to 2 codes referring to different coding systems to an EO. You can use the codes associated with
your primary coding system to uniquely identify each EO by placing it in the object abbreviation.
Additional codes can be assigned in the External Organization Data infotype (1757).
• IMG for Student Lifecycle Management -> Master Data in Student Lifecycle Management
Educational Background -> External Organizations-> Set Up Coding Systems.
Accredited external organization: You can indicate if the institution is accredited by your university.
This may be a requirement of your institution’s equivalency determination rules. Go to SAP Menu
for Student Lifecycle Management -> Academic Structure -> External Academic Structures ->
External Organization.
Maintain Grading Scales and Credit Types: Go to SAP Menu for Student Lifecycle Management ->
Academic Structure -> External Academic Structures -> External Organization.
Address Data: The external organization object is assigned to a country in the address data, which
can be used for derivation of grading scales. The EO does not use central address management. The
address is stored in the Address infotype (1028) of the EO. The country specified in the address data
is used if grading scales are derived via the country assignment. Go to SAP Menu for Student
Lifecycle Management -> Academic Structure -> External Academic Structures -> External
Organization.
Contact Person: You can maintain a contact person and assign up to three communication types in
the Contact Persons infotype (1756) at SAP Menu for Student Lifecycle Management -> Academic
Structure -> External Academic Structures -> Select External Organization -> “Contact Person”.
© SAP AG
IHE102
6-8
6.1 External Achievements – External Subject
To set up an External Subject (SU), you have to...
Define the Level of Difficulty (academic level)
External Subject Data
Define the Method of Instruction (category)
External Subject Data
Define the Discipline
Disciplines
Attach to External Organizations
Specific subject => attach to EO which is offering the course
Generic subject => attach to all EOs which could be offering such a subject
In the EO – SU relationship, define
The Grading Scale if not inherited from the EO (optional)
-
Additional Data of Relationship EO – SU (for overwrite)
Whether the subject should be defaulted to the transcript
-
Additional Data of Relationship EO - SU
© SAP 2009
Customizing Path: Master Data in Student Lifecycle Management -> Educational Background ->
External Subjects.
Academic level (infotype 1760): Determines the level of difficulty of the subject’s learning content level 1, 2, 3, 1st year, 2nd year, 3rd year, graduate, pre-university, etc. (compare to module level).
Categories (infotype 1760): Categories for the method of instruction used for external subjects –
seminar, workshop, high school subject, technical subject, etc. (compare to module category).
Disciplines (infotype 1744): Used to define all possible fields/areas of study that you want to assign
to the external subject (The use of CIP - Classification of Institutional Programs - taxonomy for
disciplines used in North America is supported). The same disciplines are assigned to CQ, EQ, SM,
CG and SC.
Relationship 508 “offers” between EO – SU: You can enter a special grading scale for external
subjects as additional data of the relationship. This grading scale overrides the general grading scale
defined for the EO’s (infotype 1755). You can set a "default flag“ on the relationship between SU
and EO. When you enter a transcript which has been issued from this specific EO in the student
master data, the flagged subjects can automatically be defaulted to the transcript (useful e.g. for high
schools and their set of subjects).
Note regarding Generic EO and SU:
• You can set up ‘dummy’ external institutions (EO)/subjects (SU) for certain scenarios:
– International students for whom you don’t have to store detailed external data
– High schools for which you can use standardized subjects
– You can define a default set of subjects for an EO. When entering a transcript from this EO,
those subjects are automatically defaulted. In this case, it can be appropriate to define generic
school subjects and attach those as default sets to the EO’s.
© SAP AG
IHE102
6-9
6.1 External Achievements – External
Qualification
To set up an External Qualification (EQ), you have to...
Define the Group to which the qualification belongs to
Define the Qualification Discipline
Define the Level and Type of Qualification (degree)
Define the Grading Scale on relationship EO – EQ
Attach to the External Organizations
Specific qualification => attach to EO which is offering the degree
Generic qualification => attach to all EO’s which could be offering such a degree
© SAP 2009
External qualifications (EQ) are qualifications that students have acquired from external
organizations. External qualifications can be considered equivalent to modules or internal
qualifications (see Equivalency Determination).
They are designed similar to the internal qualifications. Attributes you can maintain are:
• Qualification group: Defines the group to which the internal or external qualification belongs
• Qualification discipline: Defines the discipline (field of study) assigned to the internal or external
qualification
• Degree type: Type of degree, for example High School Certificate, Bachelor, Master, PhD, etc.
• Degree level: Defines the standing of a degree, for example undergraduate, graduate
• Academic scales: Defines the academic scales used to rate the qualification in relation to the EO
Before you can create external qualifications, you have to maintain the necessary settings in
Customizing for Student Lifecycle Management under:
• Master Data in Student Lifecycle Management
© SAP AG
IHE102
Qualifications
6-10
6.1 External Achievements – Functionality (1)
Available features in the student master data transaction:
Store external transcripts and test results
Store issuing institution
Store programs, degrees and courses the student completed at external institution
Store credits and external grades for courses
Store results of external qualifications (e.g. earned degrees)
Convert external grades and credits to equivalent internal ones
Convert external grading scales to internal grading scales
Convert external credits to equivalent internal credits
Calculate grade averages for external grades
To check if minimum admission requirements are fulfilled
© SAP 2009
The student file can store the following master data related to external educational history:
Detailed information about any school history of an applicant as well as detailed information about
any higher education pursued can be stored in infotype External Transcripts (1719).
Detailed information about any test results (standard tests) of an applicant can be stored in infotype
External Tests (1721).
Further information about former work experience can be stored in infotype Employment (1718)
To enter the external educational history, go to:
Student File from the SAP Student Lifecycle Management menu. Select a student from the object
manager and then choose Student
Maintain Master Data from the menu.
Student Administration
Master Data
Change from the SAP Student Lifecycle Management
menu, and select a student from the object manager.
Transaction PIQST00 (Student File), select a student and choose Student
from the menu.
Maintain master data
Transaction PIQSTM (Maintain Student Master Data) and select a student.
Information about external transcripts and tests is accessed from the Ext. Achievements tab.
© SAP AG
IHE102
6-11
6.1 External Achievements – Functionality (2)
The external educational history consists of:
¦
An overview of all existing transcripts and test results
¦
A detailed view of single transcripts or single tests
External Transcripts:
Single
Transcript
High school certificate | High School X | Preliminary version
High school certificate | High School X | Final version
University transcript
| University Y
| Final version
External Test Results:
TOEFL test
Single Test
|Transmitted by High School X
Overview of average grades (calculated)
University GPA
3.0
High School GPA
2.3
University
Transcript
University
Transcript
High School
Transcript
© SAP 2009
The external educational history within the student master record contains three tab pages:
• Overview of transcripts
• Overview of test results
• Calculated average grades across transcripts
From the tab pages, you can access individual transcripts or test results and
• Create data
• Change data
• Display data
The External Academic Achievements infotype in the student master allows you to:
• Enter and maintain the external educational history of a student by entering external transcripts
and test results
• Automatically calculate performance indicators per transcript like
– Average grade per transcript
– Sum of earned credits per transcript
• Automatically calculate performance indicators across transcripts like
– High School total average grade (across all high school transcripts)
– Total credits earned in higher education institutions (across all university transcripts)
If you do not want to store all the information defined in the transcript concept in the system, you
can hide certain tab pages. For example, if you do not need to store grade averages, you can hide the
average overview tab page.
If you want to change the layout of tab pages, you must set a new transaction or screen variant.
More information can be found in the Online Help documentation: https://help.sap.com SAP
Library
SAP NetWeaver by Key Capability
Application Platform by Key Capability
ABAP Technology
ABAP Workbench (BC-DWB)
Changing the SAP Standard (BC)
Transaction Variants and Screen Variants
© SAP AG
IHE102
6-12
6.1 External Achievements – External Transcripts
(1)
A transcript is described and identified by:
= Transcript Header
Transcript category (High School Certificate)
Transcript status (interim, final)
Issuing organization (object type EO)
Issue date
Registration period at the external organization
Transcripts can be entered:
Manually
Via web admissions application, filled in by student (see ISR for details)
Via interface for electronically transmitted transcripts, transmitted by issuing or transmitting
institution
To enter external transcript data per student, select the following objects:
The issuing External Organization
The (external) Subjects the student has taken
The External Qualifications the student has attempted and earned
© SAP 2009
To enter transcript data follow the SAP Menu path: Student Lifecycle Management
or transaction PIQST00/PIQSTM:
Student File,
• Select the Ext. achievements tab page. On this tab page, select the Ext. transcripts tab page and
choose Create. Enter the transcript data in the dialog box which appears.
Student Lifecycle Management offers an RFC-enabled function module for entry of transcripts for
existing or new students via an electronic interface:
• HRIQ_TRANSCRIPT_CREATE in function group HRPIQ00TRANSCRIPTRFC. You can use
this function module to create new transcripts.
SLCM also offers an RFC-enabled function module and a BAPI for entry of transcripts for students
who do not exist in the system or whose data do not match the input data:
• BAPI_STUDENT_CREATEFROMDATA3 in function group HRPIQ00STUDENTBAPI for
creating new student master records. Set up your external educational structure via the menu
path: SLCM Academic Structure
External Academic Structures.
You can use the following relationships to define the specified activities:
• EO belongs to EO (003): define a hierarchy of EO’s
• SU is offered by EO (508): define which subjects are offered by which EO
• EQ is offered by EO (508): define which qualifications/degrees are offered by which EO
© SAP AG
IHE102
6-13
6.1 External Achievements – External Transcripts
(2)
When you enter subject information, you can:
Add Subjects (SU) to the transcript manually
Default predefined Subjects into the transcript (SU) automatically (per EO)
Enter grades and credits in external and internal scales
Preparatory work:
High School X
-Math
-English
-Physics
-Music
-Sports
Flag
x
x
x
To automatically import subjects into a
transcript, you have to:
¦
Create Subjects (SU) and attach them to
an External Organization (EO).
¦
Flag the Subjects which should
automatically be entered on each transcript
of this EO
Transcript for Student A from School X:
Imported automatically
-Math
Imported automatically
-English
Imported automatically
-Physics
-Music
Entered manually
© SAP 2009
You can either:
• Create specific subjects for each course and link these to only one external organization (for
example, a university course for which you require the exact title and code)
• Create subjects which serve as a generalization and can be linked to several external
organizations (for example, a school subject for which you do not require the original title, code,
etc.)
The automatic transfer flag which can be set for the relationship between subject and external
organization (508: is offered by) defines whether a subject can be defaulted automatically into a new
transcript from a certain EO.
To enable easy retrieval of external institution data and classification of transcripts, you must
maintain an EO category and a category classification.
• For example, Category = Public University
Classification = University
You can report on external educational data via the issuing external institutions (EO). When
defining EO’s, you can enter two different codes based on different coding systems. You can define
your internal coding system and the one you require for legal reporting (for example, FICE code).
See also the Chapter: Academic Structure and Class Scheduling.
© SAP AG
IHE102
6-14
6.1 External Achievements – External Transcripts
(3)
Information the system derives from an external transcript:
Converted grades
Conversion from external, original grading scale to
internal grading scale
Converted credits
Conversion from original credit type to internal credit type
Displayed on
single transcript
Calculated averages per transcript (GPA)*
Displayed
as overview
Calculated grade averages across transcripts
You can overwrite converted grades and credits
* calculations points for GPAs, delivered by SAP
© SAP 2009
The conversion of grades from one grading scale to another is based on the SLCM grading scale
concept (see Grading unit) and is performed automatically. The credit type conversion from external
to internal format is also done automatically.
If you want to overwrite a converted grade or credit, you have to activate the overwrite flag in the
transcript. When a grade or credit has been overwritten, it is displayed and stored as overwritten and
cannot be automatically converted again unless you deactivate the overwrite flag.
The grade point average (GPA) is calculated at defined calculation points, delivered by SAP. You
have to implement a BADI to calculate grade averages for external transcripts. The BADI has to be
attached to one of the available calculation points which are:
• 3 calculation points for display of GPAs on single transcripts under results total
• 6 calculation points for display of GPAs on the Average Grades tab page of the Ext.
Achievements tab page in the student master data
SLCM delivers BADIs for calculation of averages (weighted average per transcript, weighted
average across all transcripts, average based on a defined set of external grades, such as all EOs with
same classification, all subjects, etc.). Customizing Path: IMG for Student Lifecycle Management ->
Student Lifecycle Management -> Master Data in Student Lifecycle Management -> Performance
Indexes -> Average Grades for External Academic Work -> BAdI: Average Grade Calculation.
In the additional data of the subject/external organization relationship (508: is offered by), you can
set the core subject flag. This flag can be evaluated during GPA calculation. When you flag a
subject as core, you define that this subject should be included in the GPA. Non-core subjects can
then be excluded
© SAP AG
IHE102
6-15
6.1 External Achievements – Grading Scale
Derivation of Grading Scales for External Achievements
5. Standard Scale for External Achievements
Country
4.
3.
External Organization (EO)
External Organization (EO)
2.
Overwrite Scale
1.
1.
External Subject (SU)
External
Transcript
External Qualif. (EQ)
© SAP 2009
Academic scales which are used to rate grades can differ from one institution and country to
another. SLCM supports flexible derivation of academic scales for the grades entered in an external
transcript. When you enter an external transcript in SLCM, you first have to choose the external
organization from which the transcript was obtained:
• If the external organization is assigned (relationship A508 ”offers") an external subject (SU) or
an external qualification (EQ), the system checks if an academic scale is assigned to SU or EQ. If
it is, the system uses this scale to rate the grade.
• If no scale is assigned, the system determines whether an academic scale is assigned to this
external organization. If it is, the system uses this scale to rate the grade.
• If the system finds no academic scale for the external organization in question, it determines
whether the higher-level external organization is assigned an academic scale. If it is, the system
uses this scale to rate the grade.
• If no scale is assigned here, the system determines whether a country-specific scale is assigned to
this external organization. If it is, this scale is used to rate the grade.
• If a country-specific scale is not assigned, the system determines whether a standard scale is
specified for the external organization in table T7PIQSWITCHVALUE. If it is, this scale is used
to rate the grade. If it is not, the system scale is used (0-100.000)
The grading scale which the system derives can be overwritten at the subject or qualification level
within the transcript. In the transcript, the grades and credits are displayed in the original grading
scale and credit type and in the internal grading scale and credit type. The system automatically
converts from one scale and credit type to another.
© SAP AG
IHE102
6-16
6.1 External Achievements – Credit Conversion
Credit type concept
You can define different types of credits
Semester credits, quarter credits, ECTS credits, etc.
You can define a conversion factor for credit types
E.g., conversion factor 1.3 for converting quarter credits into semester credits
Not every credit type must be convertible into another one
The type of credit is defined per EO
It is defaulted for all subjects
It can be overridden per subject entered in a transcript
Credits can be converted from the externally used credit types into the internally used
credit types (if conversion factors exists).
Credits entered on external transcripts are entered with the original credit type
Automatic conversion of external credits into internal credit type if a conversion factor
exists
© SAP 2009
You can define internal and external credit types.
• The credit type “CRH credit” is defined as standard credit type for internally offered objects.
• You can define as many credit types as you want for external results.
• You can assign a credit type to each external organization, which is then defaulted for subjects
offered by the EO. You can also enter the credit type when entering a subject from an external
transcript.
• You can define the factor for conversion between the standard internal credit type and external
credit types.
• You define credit types and conversion factors in Customizing using the IMG path: SLCM
Master Data in Student Lifecycle Management Credits
Set Up Credit Types.
Note: Different credit types are only supported for external results. For internal objects, you have to
use one standard credit type CRH.
Grade Symbols, Grading Scale, Credit Types: You can enter the grade symbols (I – Incomplete, IP –
In Progress, W – Withdrawn, A – Audit, etc.) used by the EO, and assign an equivalent symbol
which you use internally to these. Additionally, you can attach the grading scale (with numeric
values) which is normally used by the EO (for example, grade 1 – 4). Both values will be available
when you enter results (=grades) within a transcript. Finally, you can define the credit type the
institution generally uses for its courses (for example, semester credits).
© SAP AG
IHE102
6-17
6.1 External Achievements – Test Results (1)
A test is described and identified by:
Test type (for example, TOEFL test)
= Test Header
Issuing organization (object type EO)
Test date
End date of the test’s validity
Optionally you can enter year and session, entry date and source of
data
Tests can be entered
Manually
Via web admission application, filled in by student (see ISR for details)
Via interface for test results electronically transmitted by other
institutions
© SAP 2009
Test results are stored in student master data in the External Test Results tab (infotype 1721)).
Explanation of the test header:
• A test can be redone by the student several times; therefore the student may submit several test
results for the same test. You must create a new test result for each result the student submits.
You can identify the different test results by the test date.
• Some tests have a limited validity (for example, admission tests). Optionally, you can also store
year and session for which a test is valid.
• You can enter total test results, two total test percentiles and flag the test as passed, if applicable.
• For each test, you can also enter subtest results and percentiles. The subtest types allowed per test
type are customizable.
To enter a new test result for an existing student manually, go to the menu > Student Lifecycle
Management
Student File, or transaction PIQST00/PIQSTM) and:
• Select the Ext. Achievements tab page. On this tab page, select the Ext. test results tab page and
choose Create. Enter the relevant test result data in the dialog box.
SLCM offers RFC-enabled function modules for entry of test results for existing or new students via
an electronic interface (Function group HRPIQ00TESTRESULTSRFC. Use them to create new test
results, delete and display existing test results.
© SAP AG
IHE102
6-18
6.1 External Achievements – Test Results (2)
Preparatory work (IMG):
To enter external test results in a
student's file:
Set up test types
Select the test type => The test layout is
predefined
Enter optionally a transmitting
organizational unit (the responsible ext.
organization is defaulted)
Enter the test dates and results
Design the layout of the test
Type of test, test elements, subtests,
grading scales...
ACT admission test
Results:
- Composite Score
Subtests:
- Algebra
- Geometry
ACT admission test from School X
Results:
- Composite Score
33 98%
Subtests:
- Algebra
17 99%
- Geometry
15 96%
Scale A
Scale B
Percentile
Scale B
Percentile
© SAP 2009
Test results can be submitted by students themselves or by testing agencies which transfer the test
score results of applicants or issue standardized tests such as TOEFL tests or Admissions tests like
ACT/SCT.
Before you can enter a test result, make the required settings for maintenance of external test results.
You set up the different types of external tests you want to maintain in the system by defining the
layout of each test type in Customizing for Student Lifecycle Management -> Student Lifecycle
Management Master Data
Educational Background External Academic Achievements
External Test Results.
• Define the test types you need so that you can enter test results for students (ACT Test, TOEFL
Test, etc.).
• You can assign subtests to the test types, that is, the elements which are graded on a test (subtests
= elementary Algebra, and Trigonometry).
• Define the composite/total scores (= results) by attaching grading scales appropriate to each test
type and/or subtest type.
• Link each test type to the source testing agency (external organization), for example ACT
Organization for ACT Test Type.
Maintain the sources of external test results under …
Set Up Sources of External Test Results.
• Define the ways in which external test results can be submitted (manual input, electronic feed,
etc.)
When you enter a new test result for a student, you specify the test type. The system displays the test
layout you defined for this test type.
© SAP AG
IHE102
6-19
6.1 External Achievements – Topic Summary
You are now able to:
Understand the concept of external transcripts and tests
Create external transcripts and test results for a student
within student master data
Explain grade averages for external transcripts
Make the necessary settings before entering transcript and
test result data
© SAP 2009
© SAP AG
IHE102
6-20
6.2 Equivalency Determination – Topic Objectives
After completing this topic, you will be able to:
Understand the concept of equivalency determination
Maintain transfer regulations
Perform transfer articulation
© SAP 2009
© SAP AG
IHE102
6-21
6.2 Equivalency Determination – Example
The University of Europe (UE) discussed the acknowledgement of courses with the
University of Mannheim, and negotiated certain transfer agreements.
Andrew London’s case:
Andrew London began his studies at the University of Mannheim and then changed
to the University of Europe after 3 semesters. His transcript was transferred to the
UE.
Andrew London’s Academic Advisor at the University of UE ran a Transfer
Articulation which is system-supported. The system evaluated the transcript and, as
a result, suggested that some Math courses be acknowledged.
Andrew showed his advisor a programming certificate which he had also earned but
which was not shown on his external transcript. His advisor then gave him an
equivalent qualification for this certificate.
© SAP 2009
© SAP AG
IHE102
6-22
6.2 Equivalency Determination – Terminology
Equivalency Determination comprises:
Transfer Agreements =
Transfer Articulation =
Determine if external subjects or
qualifications can be accepted as
equivalents of internal modules
or qualifications
Store this information with time
dependency, related to the
external institution
Transfer agreement contains
transfer regulations
Basis:
Student Master External
Achievements
Evaluate the external
achievements of a student for
equivalencies
Define number of credits which
are accepted as transfer work
by institutions
Transfer agreements can be inherited
by external organizations (top down)
Student
Master Data
University
Master Data
© SAP 2009
You can store university regulations, that is, store which external work can be accepted as transfer
work, either:
• with equivalent internal work
• without equivalent internal work (only accepting the credits)
The regulations depend on the external institution which offers the external work. When performing
transfer articulation, you can access input from the regulation table. The content of a transfer
agreement are transfer regulations.
Inheritance:
• You can only maintain agreements for the EO from which the agreement originates. The
agreement maintenance screen shows which transfer regulations are maintained directly at the
selected EO and which are inherited.
• All transfer regulations which are found at an EO or higher-level EO are taken into consideration
in transfer articulations.
© SAP AG
IHE102
6-23
6.2 Equivalency Determination – Transfer
Agreement
Transfer agreement is
an agreement between your institution and
an external institution
Your Institution
External Institution
providing rules for transfer articulations
not shown in system (only logical term)
te
otia
neg
Transfer regulation is
a description of which external work is
equivalent to which internal work (one set
of external – equivalent internal work)
Transfer Agreement
Content of a transfer agreement
Transfer Regulation a
Evaluated during transfer articulation =
automation of transfer articulation
process:
Transfer Regulation b
contains
....
Evaluation of external transcripts for a student
University
Master Data
Default of existing regulations for the student’s
transcript
© SAP 2009
To maintain transfer agreements, you:
Select an external organization (EO) with which the agreement has been negotiated.
Enter agreement details:
• Choose external work: subjects (SU) or external qualifications (EQ)
• Choose equivalent internal work: SM, CQ or credited work (CW)
• Combine both to a transfer regulation (n:m relation)
Define details for each transfer regulation:
• Name and 2 different search values (fields with free text)
• Priority (in case of agreement conflicts, that is, if more than one transfer regulation is possible)
• Validity date of transfer regulation
• Period in which external work has to be taken
Details for the external work (source):
• Minimum grade (must be obtained by external work or agreement is not applied to student)
Details for the internal work (target):
• Program type (optional => will be used for program type progression)
• Choose if credits are transferred and if grade is transferred
• Define the default credits to be transferred and if graded credit is transferred
© SAP AG
IHE102
6-24
6.2 Equivalency Determination – Relations
between Source and Target Work
Equivalencies are defined between..
Source
Target
Internal Program Offerings
Internal modules (SM)
Internal qualifications (CQ)
Credited work (CW)
External Achievements
and
External subjects (SU)
External qualifications (EQ)
Transfer regulation = One set of external work and internal equivalencies with
the following relations between source and target:
1:1
1:n
Subject 1
n:1
Subject 2
Module 1
m:n
© SAP 2009
The modules and qualifications offered by the program a student is registered in, provide the initial
“target” list of internal modules and qualifications that can be defined as equivalent to external
subjects or qualifications. You can also access the complete module catalog and look for target
modules or qualifications outside the registered program.
The external academic achievements which are stored within a student transcript as external subjects
or qualifications provide the external “source” list of external subjects or qualifications for which an
equivalency can be determined.
It is possible to create the following equivalency combinations:
• Subject (1-n) to module (1-n)
• Subject (1-n) to internal qualification (1-n)
• External qualification (1-n) to internal qualification (1-n)
• External qualification (1-n) to module (1-n)
© SAP AG
IHE102
6-25
6.2 Equivalency Determination – Transfer
Articulation
Transfer Articulation:
Automatic evaluation of external achievements of a student
Manual acknowledgement of external work
Define number of externally achieved credits which are accepted as transfer credit
Can be uploaded via report
System-Based Transfer Articulations include all external transcripts maintained in
the student master data (“external achievements”):
Regulations are automatically compared with student’s external work
System proposals can be overridden
Conflicts have to be solved manually
System-Based
Transfer Articulation
Transfer work can be maintained without
referring to a regulation
Non-System Based Transfer Articulations include transcripts or certificates which
are submitted by the student on paper, but not stored in the system:
Only manual maintenance
No regulation stored
Non-System-Based
Transfer Articulation
© SAP 2009
Load Transfer Articulations (=Regulations) and External Subjects
• A report is delivered which takes as input a tab-delimited file and creates external subjects and
transfer articulation rules as a result.
• The file allows for one-to-one, many-to-one, one-to-many, and many-to-many rules.
• It also allows for minimum grades, completion date range requirements, credit transfer, and grade
transfer.
Load Transfer Regulations and External Subjects
• Maintain Data in Excel File
• Excel File DES_TransferAgreementUploadFile_V05.xls
• Save as tab delimited text file
To run report: RHIQ_AGM_DT
• Select EO to be loaded
• Select tab delimited File
• Execute
To automatically handle complex (many-to-many) articulation rules, a BadI is offered: IMG ->
SLCM -> Processes in Student Lifecycle Management -> Equivalency Determination-> BAdI:
Grade Conversion for Complex Transfer Agreement.
© SAP AG
IHE102
6-26
6.2 Equivalency Determination – Transfer
Articulation Portal View
An anonymous web interface is delivered which allows an external user to select an
External Organization and view all regulations maintained from that institution.
Search capabilities by:
External Organizations
Internal Academic Achievements
External Academic Achievements
© SAP 2009
Web Dynpro for portal view on transfer regulations: PIQ_AGM_SEARCH
EO: Shows all regulations for that EO
SM,CW or CQ: Shows specific regulations by object selected
SU or EQ: Shows specific regulations by object selected
Selecting the Advanced Link on the far right allows for more detailed search criteria
© SAP AG
IHE102
6-27
6.2 Equivalency Determination – Credited Work
and Transfer Credits only
If the ‘Transfer credits only’ rule applies to external academic work,
Students are able to transfer externally earned credits to internal ones
No internal module or qualification is equivalent to the external work
To maintain transfer credits only, you use object type “Credited Work” (CW):
CW is used to store the transfer credits for a student
SU = source, CW = target
CW is structured similar to SM (subset of SM Infotypes)
You can define categories for the transfer credits by creating different CW’s with different
attributes
You can assign a CW to an organizational unit for transfer credits which are counted
towards a certain faculty
CW can be evaluated for processes
e.g. progression
CW is not visible within the academic structure
= cannot be booked
© SAP 2009
Credits as “transfer credits:”
• Transfer credits can be categorized, for example, based on a discipline: “Humanity credits”
• Transfer credits can count for progression, degree audit and prerequisite checking
Possible relationships for the credited work object (CW):
• CW – O 501 is offered
• CW – SC
500 belongs to
• CW – CG
500 belongs to
• CW – ST
506 is completed by
© SAP AG
IHE102
6-28
6.2 Equivalency Determination – Results of
Transfer Articulation
Results of transfer articulation
Transferred work is recorded as completed internal modules + qualifications and is indicated as
“transferred”
Transfer credits are recorded as “credited work”
Transferred work results can be:
Included or excluded in average grade calculations, progression ....
Subject to additional rules like max. amount of external work acceptable per Program
Results are logged in activity documents and can be archived
Student A (ST)
Module 1 (SM)
Successfully
Completed
Module 2 (SM)
Successfully
Completed
Module 3 (SM)
Successfully
Completed
Program I (CS)
Transfer
x
Externally achieved
Internally achieved
© SAP 2009
You can use the standard module booking or academic history overview to display the work which
has been transferred by external achievements.
Transfer articulation results can be displayed in detail via transfer articulation transaction:
• All details are stored for the transfer articulation
• No history log
An overview of all transfer articulation runs (which includes header and administrative information)
is stored and available on the ‘Activity Documents’ tab page in the student file.
The activity documents which contain the ED results can be archived:
• ED results should be archived only after the student’s main record has been archived.
• Archived activity documents can be reloaded.
• When an ED result has been archived, it should not be changed before the archived activity
documents are reloaded as the change would overwrite the previous result.
© SAP AG
IHE102
6-29
6.2 Equivalency Determination – Technical View
Transfer Articulation - Prerequisite:
Student master data is created with or without external achievements
Results
Input
(optional)
Rel. 506 completes
Grade, Credit
Add. Data = transfer flag
GUID
Subject (SU)
(SU)
Subject
Ext.Qual.
Qual.(EQ)
(EQ)
Ext.
External Achievements
infotype 1719
Student (ST)
(ST)
Student
Pursues (513)
Study (CS)
(CS)
Study
Rel. 532 fulfills
Add. Data = transfer flag
GUID
Rel. 506 completes
Add. Data = transfer flag
Appraisal to keep credits
GUID
Module(SM)
(SM)
Module
Int.Qual.
Qual.(CQ)
(CQ)
Int.
Creditedwork
work
Credited
(CW)
(CW)
© SAP 2009
The results of the transfer articulation are kept in the following way:
1) If you determined equivalent internal modules (SM) for the external work:
• The module booking relationship 506 is created. The transfer flag is set in the additional data
indicating that the module was acknowledged via transfer work and not taken at the current
institution.
• Booking details are stored, similar to what is stored in the additional data of relationship 506
which is created when the module is booked internally.
2) If you determined equivalent internal qualifications for the external work:
• Relationship 532 "fulfils" is created between the student (ST) and one or more internal
qualifications (CQ).
• As additional data, it carries the transfer flag, indicating that this qualification was acknowledged
via transfer work.
3) If you determined only transfer credits without any internal equivalent for the external work:
• Relationship 506 “completes" is created between the student (ST) and the selected credited work
object (CW).
• As CW is structured similar to SM, the number of transferred credits is entered in an appraisal
which is created for that purpose in the background for the CW.
© SAP AG
IHE102
6-30
6.2 Equivalency Determination –Web Self Service
Equivalency Determination Simulation on the Web
An anonymous web interface allows external users to select an external organization and
enter the external coursework they completed at that institution.
Only external organizations with valid transfer agreements and external subjects that are
attached to a valid transfer agreement are listed.
The web interface returns results which are counted as equivalent internal coursework.
The tool offers the following features:
Two views are delivered: for students and Academic Advisors
Evaluation of equivalency is performed real time in the system
Results can be saved locally (as static HTML), or printed.
No data is created or saved in the system
© SAP 2009
The external qualification must be attached to external organization or inherited from a higher-level
organization
Users can enter year and session of when they attended the external organization (optional)
User mark those subject(s) they have taken and add the grade they received
ED simulation with manual input can be done with Web Dynpro: PIQ_EDS_EXTW
Two ED views are available
• Student Mode: PIQ_EDS_EXT_STUDENT
• Advisor Mode: PIQ_EDS_EXT_ADVISOR (linked to advisor portal)
– The Advisor view contains an extra step for entering an external qualification
– Advisor mode allows to manually resolve conflicting transfer regulations
Calculation point EDSM is delivered for total transferred work to be displayed in the portal
User Interface offers high flexibility: Via right mouse click columns which are not needed can be
hidden.
© SAP AG
IHE102
6-31
6.2 Equivalency Determination – Customizing Steps
Prepare the structure for maintaining external academic work:
Customize external academic structures including external subjects, external academic
work, and external organizations
Customize details of transcript data (e.g. categories, statuses, etc.)
Define details of the actual equivalency determination processing
Define priorities of transfer agreements based on customer needs. When a transfer
equivalency is run for an external course the system will compare the priority level of
the transfer agreements. If conflicting regulations exist, the system will automatically
return the regulation with the highest priority, if found.
Example: In order to have a drop down list of testing agencies (e.g. TOEFL)
available for selection in the Student Master Data transaction you need to
maintain and classify the external organizations in customizing accordingly.
© SAP 2009
External academic structures are customized in the IMG of Student Lifecycle Management
Master Data in Student Lifecycle Management Educational Background.
Transcript settings are customized in the IMG at Student Lifecycle Management
Master Data in
Student Lifecycle Management
Educational Background -> External Academic Work -> External
Transcripts.
Equivalency Determination is customized in the IMG of Student Lifecycle Management ->
Processes in Student Lifecycle Management -> Equivalency Determination.
Priorities of Conflicting Regulations can automatically be compared via IMG:
• Customers can build their own BAdI implementation or activate one of the defaults provided by
SAP
• IMG: Student Lifecycle Management
Processes in Student Lifecycle Management
Equivalency Determination Automatically Compare Priority of Transfer Agreements
• Use a Default BaDI
– 1. IHRPIQ00ED_AGMPRIO_COMP_NUM01
– Numeric Priority: Larger number has lower priority.
– 2. HRPIQ00ED_AGMPRIO_COMP_NUM02
– Numeric Priority: Larger number has higher priority.
• Build your own BaDI
• NOTE: You must NOT activate more than ONE implementation!
© SAP AG
IHE102
6-32
6.2 Equivalency Determination – Topic Summary
You are now able to:
Determine equivalencies for external academic work
completed by students
Describe the technical concept of “equivalency determination”
Understand how to create transfer agreements in the system
Understand the process “transfer articulation”
© SAP 2009
© SAP AG
IHE102
6-33
6. External Work and Equivalency Determination –
Unit Summary
You are now able to:
Maintain the external achievements in the student
master data
Make the settings you require to store students’ external
achievements
Enter external institutional academic offerings in the
system
Describe how to perform equivalency determination and
maintain transfer agreements in the system
Evaluate transfer work (transfer articulation) for a
student based on the external transcripts
© SAP 2009
© SAP AG
IHE102
6-34
Appendix: Performance Indices –
Concept of Performance Indicators
Performance indicators are
Calculated at defined calculation points that refer to
One external transcript (max. 3)
GPA overview in the external academic achievement record (max. 6)
Based on results within external transcripts
External subjects, grades and credits
Identify core subjects
Calculated according to different calculation rules
Generated dynamically
© SAP 2009
Performance indicators are calculated and displayed at defined calculation points. Student Lifecycle
Management provides calculation points which can be used by performance indicators. These are:
• 3 calculation points for calculation and display of performance indicators on single transcripts
under "results total“
• 6 calculation points for calculation and display of performance indicators on the Average Grades
tab page of the Ext. Achievements tab page (infotype 1719) in the student master
• The calculation points of the SAP standard system are predefined and are not extendable. You
can create new calculation points for customer enhancements. Calculation points may be used
only once in a program. Multiple use of calculation points is not possible.
Student Lifecycle Management delivers BAdIs for calculation of averages:
• Weighted average per transcript, weighted average across all transcripts, average based on a
defined set of external grades, such as all EO’s with same classification, all subjects, etc.
• In the BAdI, you must select the required data ( academic performance indices: input data is
provided by the application which calls the academic performance index).
• You can change the name for a performance indicator displayed on the transcript/average grade
tab in the BAdI.
• You can define your own calculation algorithms in customer enhancements.
© SAP AG
IHE102
6-35
Appendix: Performance Indices –
Preparatory Steps Performance Indicators
To calculate performance indicators for external transcripts, you have to:
Set up calculation rules within a BADI
Decide where the performance indicator should be displayed (= choose calculation point)
On a single transcript, or
On the average overview of the external educational history in the student master record
Attach the BADI to selected calculation point
Optional: Define subjects as “core” and evaluate this flag within the calculation
© SAP 2009
To set up performance indicators, you have to perform the IMG activities under the path: Master
Data in Student Lifecycle Management
Average Grades:
Implement the calculation algorithm using a business add-in (BAdI) in Set Up Average Grade
Calculation. SAP delivers sample implementations for:
• Grade point averages (GPA)
• Total number of credits
Note: Only use the BAdIs that refer to data in the external transcript.
Attach the calculation BAdI to a calculation point in Combine Calculation Points with Average
Grade Calculations
• You can define the calculation and display scale. If no scale is defined, the system uses the
standard scale defined in the IMG view: Master Data in Student Lifecycle Management
Academic Scales
Define Standard Scales.
In the additional data of the relationship 508 “is offered by/offers” between the subject and external
organization, you can flag a subject as “core” to include it in the calculation of performance
indicators.
• When you flag a subject as "core“, you define that this subject should be included in the
performance indicator. Non-core subjects are not included.
© SAP AG
IHE102
6-36
I H E1 02 St udent Lifec yc le M anagem ent :
7 . Progra m Regist ra t ion
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009
© SAP AG
IHE102
7-1
7 . Progra m Regist ra t ion
Content:
7.1 (Re)-registration
7.2 Technical Background
7.3 Booking Specializations
7.4 Change of program
7.5 De-registration
7.6 Extended maintenance dialog (for registration and
specialization data)
© SAP 2008
© SAP AG
IHE102
7-2
7 . Progra m Regist ra t ion – U nit Obje c t ive s
After completing this unit, you will be able to:
Register new students for a program of study
Re-register returning students for the next academic session
Keep a leave of absence record
Switch between the two different (re-)registration modes (explicit
or in the background)
Register students for a specialization
Change the program registration to another program
De-register students from a program of study
Use the extended maintenance dialog for correcting registration
and specialization data
© SAP 2009
© SAP AG
IHE102
7-3
7 . Progra m Regist ra t ion – Busine ss Sce na rio
You are employed in the registrar's office
Your tasks involve registering, re-registering and de-registering students
to/from programs, and changing their program selections
You are a student advisor in a college or faculty
You support students in assigning academic specializations (minor,
major) within their programs
© SAP 2009
© SAP AG
IHE102
7-4
7 .1 (Re -)re gist ra t ion – T opic Obje c t ive s
After completing this topic, you will be able to:
Explain the purpose of registration
Outline the two different registration modes that Student Lifecycle
Management offers
Explicitly (re-)register a student for a program in a specific academic
year
Describe the data you can enter during registration and re-registration
Create a leave of absence for a student
Understand how a student is implicitly registered for a program of study
via module booking
© SAP 2009
© SAP AG
IHE102
7-5
7 .1 (Re -)re gist ra t ion – De finit ion
Initial Registration:
Change an admitted applicant or prospect to an active student
Register the student for one or more programs in order to graduate from the
university
Indicate that the student is pursuing studies, i.e. choosing specializations,
booking modules, achieving results in one academic period
Re-registration
Indicate that the student will continue studying in the next academic period
Sessional Registration
The record created for students in both cases described above, which refers
to an academic period
© SAP 2009
Registration is the process by which applicants become students and are permitted to pursue their
studies for an academic period. The academic period represents an academic year and session
combination.
Re-registration is the process by which students are allowed to continue their studies in a subsequent
academic period.
A sessional registration is the student record which is created for a specific academic period.
In Student Lifecycle Management, students can choose one or more programs of study. Depending
on university regulations, students may pursue more than one program concurrently or sequentially.
Students can select specializations such as majors, minors, options, etc. as well as modules and
events.
There can be an admission process prior to registration. Student Lifecycle Management allows you
to create new master data records either directly during registration, or during the admission process.
For your programs of study, you can define whether students have to be admitted before registration
or if you allow direct program registration.
© SAP AG
IHE102
7-6
7 .1 (Re -)re gist ra t ion – Se ssion Va ria nt s
When you register a student, you must specify an academic period – a specific
combination of academic year and session.
The session variant of the program of study determines the academic periods for
which registration is possible.
A session variant consists of a session group and a primary unit.
SC
Program of Study
Session Variant
Session Group
Primary Unit
Fall Semester
Academic Year or
Session
Summer Semester
© SAP 2009
The specified start and end dates for registration determine the student's active registration within
the program for this period.
The session group determines the sessions into which the academic year for the given program is
subdivided
The primary unit (which can either be academic year or academic session) indicates whether the
student may only (re-)register for individual academic sessions or also for full academic years. If
“academic year” is specified as primary unit, registration is allowed for an academic year as well as
for a session. If “session” is specified, registration is only allowed for a single academic session.
Start/end dates of academic sessions are determined by time limits in the academic calendar which is
used for this program. If registration for full academic years is allowed, the system determines dates
from the start date of the first academic session in the session group and the end date of the last
academic session in the session group.
After the session end date, the student still has the "registered student" status but no longer has an
active sessional registration. This means the student is not allowed to book any modules until (s)he
has re-registered for the next academic session.
You define session variants and specify the session group and primary unit per session variant in the
IMG for SLCM: Processes in Student Lifecycle Management Admission, Registration, and Deregistration
Basic Settings
Define Session Variants.
© SAP AG
IHE102
7-7
7 .1 (Re -)re gist ra t ion – Ex am ple s for Se ssion
V a ria nt s
Re-registration is required for all subsequent academic periods in which
students continue their studies.
Program of Study 1:
Student has to (re-)register each year
Primary unit of the session variant =
Academic Year
Program of Study 2:
Student has to (re-)register every trimester
Primary unit of the session variant =
Session
Event planning and module offerings
within this program are semester-based.
Event planning and module offerings
within this program are trimester-based.
Session Group includes Fall and Summer
Semesters
Session Group includes Trimesters 1, 2
and 3
© SAP 2009
If the primary unit of the session variant is “academic year”, students are allowed to register either
for full academic years (the session field is left blank) or for academic sessions determined by the
session group.
If the primary unit is “session”, the session field in the sessional registration record may not be left
blank.
© SAP AG
IHE102
7-8
7 .1 (Re -)re gist ra t ion – Regist ra t ion Rec ord
The student registration record (tab page in student file) contains...
An overview of all registered programs for the student
Detailed registration information for each program:
– Overview of sessional registrations, including stage (if program is divided into
stages), full-time/part-time status, registration type (degree or non-degree
seeking), registration classification, completed length of study in selected program
– Current registration status (attending, non-attending) and state (active or cancelled
record)
– Specializations booked can be found on an additional tab
1
Master Data
Incl. External
Educational
History
2
Student
Account
9
Progression
Record
8
Booking
Record
Student File
Student File
Student File
7
Registration
Record
3
Student Notes
4
Requests
6
Holds, Status
5
Activity
Documents
© SAP 2009
All information related to a program of study and a student is stored in the student’s study object
(CS). The study object contains administrative information such as the registration details for the
student and program (sessions, status, etc.). Students who pursue multiple programs concurrently
have one study object per program.
A sessional registration record is created for each academic period for which the student is
registered for a program. There will be such a record for the initial registration, and for all following
program re-registrations.
Student study information can be accessed from the Student File transaction: SAP menu: Student
Lifecycle Management
Student File
© SAP AG
IHE102
7-9
7 .1 (Re -)re gist ra t ion – Ex plic it Re gist ra t ion
To re-register a student in the explicit
mode, you have to:
To register a student in the
explicit mode, you have to:
Re-register the student via the Student
File [Registration] tab page
Select a registered program
Select academic year and session
Register the student via the student file
[Registration] tab page
Select a new program of study
Choose the academic year and session
Default: subsequent academic session
based on last registration record
You can also enter data on the study mode:
These registration details are defaulted :
Registration type
Full-time or part-time
Stage (if applicable)
Classification
Main/additional program
Completed length of study
Registration type
Full-time or part-time
Stage (same stage as before)
Main/additional program
Completed length of study (+1)
Status: Student + Attending
Academic period "Summer 2008"
Stage 1
Status: Attending
Academic period “Fall 2008/09"
Stage 2
© SAP 2009
When setting up Student Lifecycle Management, you have to specify which registration variant you
want to use in your system. The system is designed to support two different registration variants:
Explicit (re-)registration for a specific academic session: You must create the sessional registration
for the corresponding academic period in the student file before the student can book a module for
this or other related periods. This variant is usually used in European universities and universities
following the same approach.
Implicit (re-)registration after a module booking is made. You do not have to create the sessional
registration before the student can book a module. In this mode, the student books a module first.
The system then (re-)registers the student for the corresponding academic period (in the
background). This model is mainly used in North American universities and those following a
similar learning model.
The system settings are found in Customizing: Student Lifecycle Management
Processes in
Student Lifecycle Management
Admission, Registration, and De-registration
Sessional
Registration
Define Mode for Registration/Re-registration.
If you want to use the background mode for registration and re-registration, you have to set the
REREG MODE to US1, otherwise leave it blank. This setting tells the system that it should
automatically create sessional registration records as a by-product of the student’s module booking
activity. In the explicit mode, registration is a separate process.
Table V_T7PIQSWITCHVAL is the central switch table for Student Lifecycle Management.
• Explicit registration : REREG MODE = blank
• Registration in the background: REREG MODE = US1
© SAP AG
IHE102
7-10
7 .1 (Re -)re gist ra t ion – Lea ve of Abse nc e
For the explicit registration, you can distinguish between:
Mandatory
Re-registration
Optional
Leave of absence
Student is not returning for one session
but is taking a leave of absence
Returning student is re-registered
for the next academic session
To keep an uninterrupted record of
registrations for the student
To control the time a student is absent
Status “attending”
Status “non-attending”
Cancel Sessional Registration
Cancellation reason
Record is kept as “inactive”
© SAP 2009
When you re-register a student, you have to decide between normal re-registration or Leave of
Absence.
You can determine whether the student is to be re-registered or granted leave of absence by
choosing Registration or Leave of absence on the registration screen.
It is not mandatory to create a leave of absence. The student can have an interrupted registration
record, for example, register for fall session 2008, not re-register for the following session (Spring
2009) but re-register again in Fall 2009.
If you want to cancel the registration record, you can enter a cancellation reason. The record will not
be deleted, but set to inactive.
© SAP AG
IHE102
7-11
7 .1 (Re -)re gist ra t ion – Bac kground
Re gist ra t ion
I mplic it Re gistra t ion
To re-register a student in the
background mode, you have to:
To register a student in the
background mode, you have to:
Book returning students on modules
at the beginning of the academic
period
=> First module booking for the
academic period triggers
background sessional registration
Define relevant registration details
during admission
Book new students on modules at
the beginning of the academic
period
=> First module booking triggers
background sessional registration
Details for the sessional registration
are automatically created:
Date of the registration
Registration status
Full-time/part-time status
Status: Student + Attending
Academic year "Summer
2008"
Stage 1
Status: Attending
Academic year “Fall 2008/09”
Stage 2
© SAP 2009
When a student registers for a course the first time after he has been admitted or at the beginning of
a new academic period, the system automatically creates a new sessional registration record for the
student.
You can view the sessional registration records on the Registration tab page in the Student File.
Students can also book modules using a self-service function; how modules are booked does not
influence the process.
When you book modules, you have to specify the academic period. The first module booking for
this period triggers the automatic creation of a sessional registration record.
Further registration details are taken from the admission record or from the latest record, both of
which contain the required data.
The same procedure is used for returning students. When the student books the first module for the
new academic period, the student is automatically re-registered.
© SAP AG
IHE102
7-12
7 .1 (Re -)re gist ra t ion – Se ssion M apping
Academic sessions can be ordered in a session hierarchy – e.g. the full
summer session is subdivided into two lower-level sessions, 1st summer
session and 2nd summer session
Seasonal
registration is
possible for Full
Summer 2008
A higher-level session can
consist of many lower-level
sessions (top-down).
A lower-level session belongs
to one unique higher-level
session (bottom-up).
Mapping
Full Summer
Module to be booked is
offered in 1st Summer
2008
1st Summer
2nd Summer
© SAP 2009
Relationship between registration and module booking:
The session variant of the program of study determines for which academic years and sessions a
sessional registration record can be created.
Modules can sometimes be offered in academic sessions which are not assigned to the session group
of the program’s session variant. In this case, the system tries to map between the sessions used in
the two contexts – module booking and sessional registration – making use of the session hierarchy.
Students are then allowed to book modules for lower-level sessions if they are registered for higherlevel sessions or for the whole academic year. The session hierarchy must be properly customized in
the IMG (see Academic Calendar). The default session mapping using the session hierarchy is thus
always “bottom-up”.
If the background mode for sessional registration is activated and the student tries to book a module
for a lower-level session for which sessional registration is not allowed, the system will create a
registration record for the first higher-level session allowed by the session variant of the program.
With the implicit registration mode you can specify the academic sessions for which a re-registration
is to be created in the background if the academic sessions of the module bookings do not
correspond with those of re-registration. It is only necessary if standard session mapping using the
session hierarchy is not sufficient.
© SAP AG
IHE102
7-13
7 .1 (Re -)re gist ra t ion – Cust om izing St eps
Registration – Basic Preparatory Steps
Define Session Variants
Set Up Registration Types
Set Up Activity Reasons + Assign Reasons to Activities
Customizing Sessional Registration
Define Mode for Registration/Re-registration
Explicit (re-)registration for a specific academic session
Implicit (re-)registration after a module booking is made
Set Up Default Values for Registration
Only for explicit registration mode
Set Up Registration Classifications (Grouping that can be used for reporting)
Business Add-Ins (BAdIs) available for:
Conversion of Academic Sessions to customer specific requirements
Overwriting default values for registration the system proposes in the sessional registration
application with own values.
Additional Admission Check at Registration to allow students to apply for admission to restricted
programs of study even if they have no admission record for that period.
Subsequent Activities for Registration Dialogs
© SAP 2009
Customizing path for basic settings: Processes in Student Lifecycle Management Admission,
Registration, and De-registration Basic Settings.
The registration type classifies the students registered in a program of study. You create registration
types under Basic Settings
Set Up Registration Types. For each registration type, you can specify if
the student is pursuing Degree studies. You can also define a default registration type. The system
automatically defaults to this value when you assign a registration type to a student. Examples: regular
student (degree), exchange student (non-degree).
You define reasons for the activities within the student life cycle and assign these to specific activities
under Basic Settings Set Up Activity Reasons and Assign Reasons to Activities: You can assign
several reasons to each activity. The reasons determine the cause of the process (activity). Examples of
reasons for the leave of absence activity are study abroad or internship.
Customizing path for sesional registration: Processes in Student Lifecycle Management Admission,
Registration, and De-registration Sessional Registration
Default values for registration are set at Set Up Default Val. for Registration
Academic year/ session: In standard the system defaults to the next academic year/ session based on
system date. To default to the current academic year/ session, specify the number of days during which
the system should default to this value.
Completed length of study: time a student spent in the chosen program to date, counted in academic
sessions/ years. If you activate the default mechanism, the completed length of study is defaulted (1 for
initial registration unless admission contains other data, incremented by 1 for each re-registration,
unchanged by leave of absence).
Registration classification applies to a specific program within the registration period. Other processes
are not impacted. Create classifications at: Set Up Registration Classifications.
To convert acad. sessions go to: BAdIs Conversion of Acad. Sessions
Make default value settings at: BAdIs Default Values for Reg. You can adapt the system default
values for stage, semester of study, or leave of absence.
Make default value settings at (BAdIs) Add. Admission Check at Registration
For default value settings go to BAdIs Subseq. Activities for Registration Dialogs to trigger a
subsequent dialog for selected dialog functions in the student file (e.g. call the module booking dialog or
specialization maintenance transaction after initial registration).
© SAP AG
IHE102
7-14
7 .1 (Re -)re gist ra t ion – T opic Sum m a ry
You are now able to:
Explain the purpose of registration
Outline the two different registration modes that Student Lifecycle
Management offers
Explicitly (re-)register a student for a program
in a specific academic year
Describe which data you can enter during registration and reregistration
Create a leave of absence for a student
Understand how a student is implicitly registered in a program via
module booking
© SAP 2009
© SAP AG
IHE102
7-15
7 .2 T e chnic a l Bac kground – T opic Object ive s
After completing this topic, you will be able to:
Understand the technical background of registration
processes
Explain the data model for registration
Understand the concept of study segments
Describe which status changes are triggered by the
registration process
Understand the role of activity documents in
registration processes
© SAP 2009
© SAP AG
IHE102
7-16
7 .2 T e chnic a l Bac kground – Da t a M ode l for
Re gist ra t ion
When you register a student for the first time, the system:
Creates a study object (object type CS), if this was not already created during admissions and creates
relationships 517: has study between student (ST) + study (CS) and relationship 514: is specialization of
between study (CS) + program (SC).
Creates relationship 513: pursues between student (ST) + study (CS)
Creates a Sessional Registration record for CS
Creates a General Data record for CS
Creates a Study Segment record containing data from relationship 513
Sets student statuses
Writes activity documents
530 applies for
Student (ST)
513 pursues
517 has study
Study (CS)
514 is a specialization of
Program of Study (SC)
Sessional Registration and
General Data Infotypes
Academic year and session
Stage
Registration date
Registration status (e.g.
attending)
Registration type (e.g.
degree)
Full-time or part-time
Registration classification
Completed length of study
© SAP 2009
During admissions, the system creates a student master record (object type ST), BP master record
(object type BP), a study object (object type CS), and relationship 530: applies for between student
and study (ST – CS) in status active for admitted applicants. The Student status (infotype 1728) is
set to admitted applicant.
When you register an applicant, the system creates relationship 513: pursues between student and
study (ST – CS) with the start date of the registered period as the relationship start date and
12/31/9999 as the relationship end date. It sets the status student which has an unlimited validity.
The system creates a study segment record (infotype 1769) for the initial registration but not for a
re-registration.
At the same time, the system creates the registration details in infotypes 1770 and 1771 of the study
object (CS) and sets the status attending; the validity of this status coincides with that of the
registered period. The validity of the General Data record (infotype 1770) begins on the start date of
the registered period and ends on 31.12.9999 (if you do not overwrite these values). It contains:
• Part-time study (flag)
• Registration type (degree or non-degree student, etc.)
The validity of the Sessional Registration record (infotype 1771) corresponds with that of the
academic period the student is registered in. It contains the following information:
• Academic year and session
• Registration status (attending for registration, non-attending for leave of absence)
• Reason
• Stage
• Completed length of study
• Classification
• Registration date (NOT the start date of the registration record!)
• Technical fields: sessional registration state (active, or inactive for cancelled records)
© SAP AG
IHE102
7-17
7 .2 T e chnic a l Bac kground – Da t a M ode l for Re re gist ra t ion
When you re-register a student, the system:
Creates a new Sessional Registration record (infotype 1771) for the study object (object type
CS) in the subsequent academic year and session and updates the registration details
Sets the registration status to attending for a re-registration and to non-attending for a leave of
absence (= student status)
Writes an activity document
When you cancel or withdraw from a sessional registration, the system:
Changes the status of the sessional registration record to inactive
Writes an activity document
530 applies for
Student (ST)
513 pursues
New
records /
Update
Sessional Registration Infotype
Academic session
Stage
Registration date
514 is a specialization of
Registration status (e.g.
attending)
Registration type (e.g.
Program of Study (SC)
degree)
Registration classification
Completed length of study
Study (CS)
© SAP 2009
When you re-register a student (or create a leave of absence), the system creates a new Sessional
Registration record (Infotype 1771) for the study object (CS) with the start and end dates of the
registered academic session.
The General Data record (Infotype 1770) remains unchanged unless you change details of the
registration record, like part-time/full-time status. The system would then delimit the first record and
create a second one.
When you create a re-registration, the registration status is set to attending. When you create a leave
of absence, the registration status is set to non-attending.
Note: You cannot create a leave of absence before the initial program registration or following deregistration.
When you cancel or withdraw a sessional registration record, the record is not deleted but delimited.
Cancellation data is also stored in Infotype 1771.
The State of sessional registration record field of Infotype 1771 is changed to inactive (for other
records it is active).
Details such as the activity that cancelled the registration (de-registration or change of program), and
cancellation reason and date.
You can only create one sessional registration record for a specific time period. Therefore, when you
create a registration, then cancel it and create a new registration for the same period, only the new
registration record remains. The registration history, however, is not lost but stored in activity
documents (currently without details).
© SAP AG
IHE102
7-18
7 .2 T e chnic a l Bac kground – T he St udy Obje c t
(CS)
Study object (CS) plays a central role in Student Lifecycle Management as it is in
this object that the system stores all information related to the studies of a student.
The Study object:
Is linked to the student (ST) via relationship 517 and to the program (SC) via
relationship 514
Is created via the admission or registration process
Stores all program-related data for a student
Is the (only) instance of a program (SC) for one student (ST)
When a student registers for a program and then cancels the registration, the CS
object is not deleted
When a student withdraws from program SC1 in 2006 and is admitted to or
registers for this program again in 2008, the registration data of both activities
(two different study segments) is tied to the same CS object
A change of program always involves two CS objects
© SAP 2009
This object type represents the student's program (refers to SC via relationship 514 is specialization
of) and is individualized by storing the relevant student/program information.
All information related to a program of study and the student is stored in the student’s study object
(CS). The study object contains administrative information such as the admission and registration
details for the student and program (sessions registered, status, etc.). Students who pursue multiple
programs concurrently have an active study object per program.
Note: Module bookings are represented as a relationship 506 ST – completes - SM between the
student object ST and the module object SM in the data model of Student Lifecycle Management.
There is no direct relationship to the study object. When modules are booked in the context of
programs of study, the identification of the module booking relationship can be stored in infotype
1724 (“Where-Used List” of the study object CS). When modules are booked in the context of
program types, the identification of the module booking relationship can be stored in infotype 1725
(“Where-Used List” of the student object ST).
© SAP AG
IHE102
7-19
7 .2 T e chnic a l Bac kground – St udy Se gme nt s
When a student is first registered on a program, the system creates a study object
(CS) and opens the first study segment. When the student de-registers from this
program, the system closes this study segment.
When a student
registers for a program for the first time
re-registers for following sessions
de-registers from the program
and registers again
1. Study Segment
(closed)
2. Study Segment
(open)
Two study segments are created, CS remains the same.
All data for the student and program is attached to the same CS object, but there are
two study segments (Infotype 1769)
Study segments allow to distinguish between the first registration interval (first
registration until de-registration) and the second registration interval for the new
registration
© SAP 2009
The study segment is a technical structure which is not visible to the user. The user sees only the
sessional registration record, but not the study segment. The combination of study segment records
and sessional registration records enables you to distinguish between:
• Students who have registered for the next academic year or session
• Students who have not yet registered for the next academic year or session, but are expected to
re-register (because the study segment is still open)
• Students who are not expected to register for the next academic year or session because they have
de-registered (ended their study segment)
The study segment is an infotype of the study object (CS) which is created when you create a
registration. The study segment contains the additional data from relationship 513 (ST – SC). The
study segment is closed (= delimited) when the student de-registers from the program.
The system stores the activity that opens a study segment for a program of study (e.g. initial
registration or change of program for the student’s new program of study) and the activity that
closes a study segment (e.g. dismissal from program, withdrawal from program, or change of
program for the student’s old program of study).
© SAP AG
IHE102
7-20
7 .2 Tec hnica l Ba ckground – Ex tending Study Se gme nt s
If the registration mode is set to ‘US1’ in the IMG
Seasonal registrations to be created for sessions in any order
The study segment can be extended if necessary
Activity RA02 ‘Extend Study Segment’ -> activity document is created
There must still be a valid admission for the earliest sessional registration created (if
the program of study is admission-restricted)
Summer 2008
2. Registration
Fall 2008
Spring 200
1. Registration
Study segment
© SAP 2009
If you activate the Background Mode (US1) of registration, the system allows you to create
sessional registrations for academic sessions in any order.
The system always creates a study segment for the student’s first sessional registration for a
program. If the student later has to be registered for a session starting before the validity start of the
study segment, the system must extend the study segment to cover the new sessional registration as
well. Activity RA02 (Extend Study Segment) is used for this purpose, and writes an activity
document.
© SAP AG
IHE102
7-21
7 .2 T e chnic a l Bac kground – Change of St udent
St a t us
=>The student object (ST) is used to administer persons in different roles (e.g.
applicants, de-registered students, and alumni) whereas the student status is
used to determine the student’s role at the university:
=> Admission sets the status admitted applicant (ADMA).
=> Registration sets the status attending (CS01) and student (CS03).
=> Re-registration renews the status attending for an academic session.
=> De-registration sets the status de-registered (CS04) and optionally alumnus
(ALUM).
© SAP 2009
Object type ST is used to administer not only active students, but also applicants, de-registered
students, and alumni.
The student status represents the person's current role based on the relationship with the university
or a program of study. You can view the student status in the student header of the student file or on
the Status tab page of the student file.
When an applicant is admitted/rejected (= admission process), the system derives the status
applicant, admitted/rejected applicant (from relationship 530: applies for (ST – CS)).
When an applicant is registered, the system derives the status student (from the new relationship
513: pursues (ST – CS)). This expresses that the person is a student of the university now. The status
has unlimited validity. The system only deactivates this status if a student is de-registered from the
program.
When you create an initial registration, the system sets the status student. Because an active
sessional record is created during registration, it also sets the status attending. The status attending is
only valid for the time period within the registration specified as academic session.
The student has to re-register for each session to renew the status attending.
When a student is de-registered, the system sets the status de-registered student (related to one
program of study) because relationship 513: pursues (ST – CS) and the corresponding study segment
are delimited.
When you register a student for more than one program, the system sets a student status for each
program, e.g.: Student is in status attending for program 1 and de-registered for program 2.
Customize the student header display according to your institution’s needs in the IMG for SLCM
under Student Lifecycle Management Master Data
Students Status Display.
© SAP AG
IHE102
7-22
7 .2 T e c hnic al Ba c k ground – Ac t ivity Doc um ent s
ACTIVITY DOCUMENTS are used to:
Keep a record of all registration-related activities for a student such as
Registration
Re-registration
Leave of absence
Change of program
De-registration
Cancellation of each actions
Display activity documents within the student file => overview of history log
The system automatically writes the activity documents
A document is stored and displayed in the Student File for every activity. This document
contains:
−
The activity
−
Student and program identifier
−
Date, time, and user (as well as other fields)
© SAP 2009
Activity documents are used to log processes of the student lifecycle. They contain a history of the
changes and can be displayed as an overview on the Activity Documents tab page in the student file:
• Example: When you create a program withdrawal and then cancel it again immediately
afterward, the Activity Documents tab page shows both the Withdrawal and Cancel End of
Program activity documents, the date on which they were created, and the user who created them.
© SAP AG
IHE102
7-23
7 .2 T e chnic a l Bac kground – T opic Summa ry
You are now able to:
Understand the technical background of registration
processes
Explain the data model for registration
Understand the concept of study segments
Describe which status changes are triggered by the
registration process
Understand the role of activity documents in registration
processes
© SAP 2009
© SAP AG
IHE102
7-24
7 .3 Book ing Spe c ia liza t ions – T opic Objec t ive s
After completing this topic, you will be able to:
Select specializations for students
Explain the concept program specializations
Define rules for program specializations
© SAP 2009
© SAP AG
IHE102
7-25
7 .3 Book ing Spe c ia liza t ions – M odule Group
Re gist ra t ion
You can register students for module groups which reflect specializations within a
program of study like
Majors, minors
Options
Program A (SC)
Module group registration is
Offered during registration via the program
Accessible any time during student file processing
Option 1 (CG)
Module x (SM)
Or
Module x (SM)
Option 2 (CG)
It provides registration options based on the
Module group variant
Module groups attached to a program
Module x (SM)
Module x (SM)
Module x (SM)
© SAP 2009
Programs of study may offer different specializations (streams, options, concentrations, majors,
minors, etc). You can assign specific academic specializations directly to your students in the
context of the program they are pursuing.
• ST -> CS (->= Relationship 516: has academic specialization) CG
When you register the student for a module group of the program, the Specializations tab page in the
student file can be used to:
• Display module groups which are available for registration per program
• Show the registered module groups per program
• Register additional module groups per program
The system takes into account the module group variant assigned to the program and any
specialization combination rules defined for this program.
You can set up module group variant/category combinations (for example, one major and one minor
OR one major and two minors).
You can register students only for module group categories flagged as a “specialization”.
You can restrict the allowed module group combinations offered in the program (for example, you
may not want to allow the combination of “Finance Major” with “Finance Minor”).
© SAP AG
IHE102
7-26
7 .3 Book ing Spe c ia liza t ions – We b Se lf Se rvic e
Web Self Service for requesting a Change of Specialization
Students request a change to their academic specializations (such as major
or minor) within a program of study.
A workflow template is delivered which handles the routing and approval of the
request to the appropriate staff members.
Steps to submit form request:
1
2
Program
Selection
3
Modify
Specializations
4
Review and
Submit
Complete
© SAP 2009
Web Dynpro Application for change of specialization request: PIQ_ST_COS
Specializations are customized in IMG at SLMC-> Master Data in Student Lifecycle Management > Academic Structure -> Module Groups.
The module group variant defines the number of majors and minors within a program. It enables you
to map the academic specializations of a student within the chosen program
Define the relevant module group categories as a specialization by setting the Specialization flag in
Customizing under SLCM Master Data
Academic Structure
Module Groups
Set Up
Module Group Categories.
2. Assign a module group variant to the program of study (SC)
3. Link the appropriate module groups to the program of study.
4. After setting up the module group variants, you can maintain the valid and invalid module group
combinations at Environment
Maintain Acad. Specializations in the Program Catalog.
5. You can define explicit rules for valid and invalid specialization combinations for each of your
programs of study (e.g. a BA program requires students to select a major and a minor; with this
function, you can explicitly define the major/minor combinations that are not permitted.
Note: You do not have to explicitly define all allowed combinations.
6. Note: A program is available which shows all students who have either entered or left specific
specializations during a specified time period: Transaction PIQSPECS_CHANGE and program
RHIQ_SPECIALIZATION_CHANGE.
© SAP AG
IHE102
7-27
7 .3 Book ing Spe c ia liza t ions – T opic Summ a ry
You are now able to:
Assign program specializations to students
Perform the preparatory steps for specialization booking
Define rules for program specializations
© SAP 2009
© SAP AG
IHE102
7-28
7 .4 Cha nge of Progra m – T opic Objec t ive s
After completing this topic, you will be able to:
Change a student’s program registration
Understand the technical background of a
change of program
Perform the preparatory steps for a change of
program
© SAP 2009
© SAP AG
IHE102
7-29
7 .4 Cha nge of Progra m – Func t iona lit y
Program registrations can be changed.
A registered student can change his/her registration to another program of study
The student is de-registered from the program
The student is registered for the second program. You can either:
Register the student for the new program but not for an academic period
(= start of attendance is not defined yet)
Register the student for the new program and for one academic period
(= start of attendance is defined)
Transfer sessional registrations that are cancelled at the old program of study to
the new program of study, if applicable (possible when there are valid sessional
registrations for the old program of study after the change of program date)
A change of program is created in the student file
X
© SAP 2008
When you perform a change of program, you de-register the student from the program the student is
currently registered in and create a registration for the new program. You can also create a sessional
registration for the new program or transfer sessional registrations from the old to the new program
of study.
© SAP AG
IHE102
7-30
7 .4 Cha nge of Progra m – Proc edure
How to create a change of program:
Go to the Registration screen
VariantC:
C:Transfer
Transferregistration
registration
Variant
recordstotothe
thenew
newprogram
programofof
records
study
study
Enter a new program
Choose Change of program
Enter date and reason
VariantA:
A:Do
Donot
notcreate
createaa
Variant
registration
record
foran
an
registration record for
academic
year
academic year
newregistration
registration
VariantB:
B:Create
Createaanew
Variant
record
for
an
academic
period
record for an academic period
Set Create sess. Registration
indicator
Enter registration data
Active study segment for the
program, but no sessional
registration
Active study segment for the
program + new sessional
registration
© SAP 2009
You create a change of program on the Registration tab page in the student file.
To create a change of program, select Program and enter the program the student has decided to
withdraw from. In the New program field, enter the program the student wants to change to.
Choose Change of program and enter the required data in the Change of Program dialog box.
If you set the Create registration indicator, the system creates a new study segment as well as a
sessional registration. If you set the Transfer registrations indicator, the system transfers all sessional
registrations that are cancelled in the old program of study to the new one. In the latter case the two
programs of study must be ‘compatible’, e.g. they should use the same academic sessions or the
same stages (see also next slide).
© SAP AG
IHE102
7-31
7 .4 Cha nge of Progra m – T ec hnica l Aspec ts
When you create a change of program, the following occurs in the system:
The student is de-registered from old program (via the “change of program”
activity ).
Activity documents are created.
A study segment CS is opened for the new program in each variant A and B and
C of previous slide.
Relationship 513 ST-CS is created in the active status.
Start date of new program is recorded
Student status is updated.
In new and old program
One or several new sessional registration records are created .
Only for variant B (if create registration is chosen) and C (if transfer
registrations is chosen)
© SAP 2009
When the student is de-registered, the validity of the old registration record ends on the day before
the validity of the new registration record starts.
The activity documents that are created include:
• 3 activity documents for the change of program – one main document for the change of program
itself, two documents referring to the main one for the de-registration from the old program and
the registration for the new program
• activity documents for all sessional registrations that are cancelled at the old program of study
• activity documents for all sessional registrations that are created at the new program of study
The Activity Documents tab page in the Student File contains an overview of the activities for which
the system has created activity documents. When you create a change of program, the system creates
several new activity documents. It also delimits the open study segment of the old program and
starts a study segment for the new program.
The system sets the start and end dates for the old and new registration if you do not enter these
dates.
Date of the change of program = Start date of the new program (date as of which the student is
registered for the new program)
Date of the change of program minus 1 = End date of the old program
• Example:
• The 2009/2010 academic year starts on 08/16/2009. A student has decided to change to another
program at the beginning of this academic year. You create a change of program and enter the
date 08/16/2009.
• When you create the change of program, the system opens a study segment in the new program
with the start date 08/16/2009 and closes the study segment of the old program on 09/30/2009.
© SAP AG
IHE102
7-32
7 .4 Cha nge of Progra m – Se lf Se rvice
The Change of Program functionality is available as backend functionality but Student
Lifecycle Management also provides a self service which allows universities to offer
students the online option for requesting a change to his/her program of study.
The delivered workflow template handles the routing and approval of the request to the
appropriate staff members.
Steps to submit form request:
Select registered program
Chose new program
Chose specialization
Review and submit
Complete
1
2
Select
Registered
Program
3
Choose New
Program
4
Choose
Specialization
5
Review and
Submit
Complete
© SAP 2009
General customizing steps for the change of program activity:
Maintain reasons for the change of program
Link reasons to the change of program activity
Optionally you can implement a customer exit to default values and settings for the change of
program like key date, reason for change of program, create or transfer sessional registrations
Requirement: You have completed the customizing for the registration activity.
To assign reasons to the Change of Program Activity (RQ01) go to Customizing: Student Lifecycle
Management
Processes in Student Lifecycle Management
Admissions, Registration, Deregistration
Basic Settings
Assign Reasons to Activities.
The above mentioned Change of Program Self Service functionality can be accessed through Web
Dynpro Application name: PIQ_ST_COP.
© SAP AG
IHE102
7-33
7 .4 Cha nge of Progra m – T opic Sum ma ry
You are now able to:
Change a student’s program registration
Understand the technical background of a
change of program
Perform the preparatory steps for a
change of program
© SAP 2009
© SAP AG
IHE102
7-34
7 .5 De -regist ra t ion – T opic Obje c t ive s
After completing this topic, you will be able to:
Understand the de-registration process
Outline the consequences of de-registration
De-register a student
Change a student to an alumnus
Perform the preparatory steps for de-registration
Use the mass de-registration report
© SAP 2009
© SAP AG
IHE102
7-35
7 .5 De -regist ra t ion – De finit ion
De-registration ends the relationship between a student and a program of study
It is created with the activities:
Data Model
Withdrawal
Dismissal
O
Organizational
Unit
Change of program
541 is
alumnus of
University(O)
(O)
University
ST
Student
513 pursues
CS
Study
X
514 is a
specialization of
ProgramAA(SC)
(SC)
Program
Program
ProgramBB(SC)
(SC)
Relationship is delimited
SC
Program of
Study
© SAP 2009
You de-register students at graduation or when the student or university requests de-registration at
any other time.
If a student is registered in more than one program, you must de-register the student separately from
each program.
© SAP AG
IHE102
7-36
7 .5 De -regist ra t ion – Proc e ss & Conseque nc e s
Students who have been de-registered from a program...
...cannot book modules for this program
...require a new admission in order to register again
...are given the status "de-registered student“ for this program
...can become an alumnus of the university or department
Automatically, depending on the de-registration reason
Manually
Activity:
Activity:
Reasons for de-registration:
Student has graduated
Withdrawal
Student wanted to de-register
Student did not re-register in due time
Student has a poor academic standing
Dismissal
Disciplinary reasons....
© SAP 2009
When you de-register a student, you can choose the withdrawal or dismissal activity. Both of these
activities lead to the same result. The de-registration reason depends on the activity you choose.
Note: If the de-registration date is set in the future, the student will still be able to register for
academic sessions up to the de-registration date.
© SAP AG
IHE102
7-37
7 .5 De -regist ra t ion – Proc e ss St e ps
To de-register a student, you use the Registration tab in the student file to...
De-register the student from a registered program of study
You can choose between “withdrawal” and “dismissal”
Specify the end date of program registration
Specify the last day on which the student attended classes
Define if the student should become an alumnus (flag)
Define whether module bookings should be cancelled (flag)
Define whether the study segment should be cancelled (flag)
Reason for de-registration
You can change the reason and key date of the de-registration or cancel a deregistration
De-registered student of program X
Alumnus of department X
Registered student of program y
De-registered student of University
Alumnus of University X
© SAP 2009
To de-register a student, go to the student file and select a student:
• Then select a program of study from the Registration tab, choose De-registration and select the
de-registration activity you want to perform. You can choose between:
– Withdrawal: Student has completed studies or has applied for de-registration.
– Dismissal: University triggers de-registration (against the student’s will).
Enter the de-registration details in the dialog box:
• You can de-register the student for a specific date, also in the future. The student remains
registered until the specified date.
• You can keep a date of last attendance.
• Enter a reason.
• Enter the de-registration date.
• Decide if module bookings should be cancelled automatically.
• When you de-register a student, you can determine whether the student should become an
alumnus of the university (or a faculty, etc.).
– If your customizing settings define that the alumnus relationship should be set for certain deregistration reasons, the system will automatically create the relationship.
– If you set the alumnus flag on the de-registration screen, the system automatically updates the
data field on the Alumnus tab page.
– If you do not set the alumnus flag, maintain the alumnus data manually by using the Insert
relationship function in student master data on the Alumnus tab page.
• You can decide whether you want to keep the study segment, which will be delimited through the
de-registration (=standard), or cancel (=delete) the study segment altogether.
© SAP AG
IHE102
7-38
7 .5 De -regist ra t ion – M a ss De -re gist ra t ion
You can perform mass de-registration for a list of students via a report. This
program for automatic de-registration selects and de-registers a list of students
according to criteria selected by the user.
The program allows you to:
Create a list of students
For example, to select those students who did not re-register by the given deadline
Select the de-registration activity (dismissal, withdrawal)
Set the de-registration reason
Specify the “de-registration” and “registered until” dates
De-register the selected students with or without canceling modules
© SAP 2009
With the program available in transaction code PIQREG_MASS_DEREG) you can:
• Use selection methods and variants to select a list of students
• Enter de-registration details like activity, reason and date
• Perform follow up functions like cancellation of module bookings automatically
• Output a list of the de-registered students
• Execute a test run
You can use the selection method tool to select students.
• You can determine which students are registered in a specific program on a given key date but
are without a sessional registration using selection method DE00 (students without sessional
registration). With this selection method, you can automatically de-register all those students who
have not re-registered for the next academic session on time.
• You can use other selection methods and create your own selection variants.
You can specify the parameters you want to evaluate in the selection variant. For example, in
selection method DE00 you can define the following:
• Academic session
• Key date
• Programs of study
• Program types
© SAP AG
IHE102
7-39
7 .5 De -regist ra t ion – T e c hnic a l Aspec ts
When you de-register a student from a program, the system:
Delimits the study segment of the study object (CS) or cancels it
Delimits relationship 513 “pursues” between ST and CS or cancels it
Saves the de-registration date and reason in both study segment and relationship 513,
unless they are cancelled (=deleted in this context)
Sets statuses for the student and study of the student (alumnus, de-registered)
Writes an activity document
It performs the following actions automatically:
Cancels all sessional registration records which are still active after the de-registration
date
Delimits registration of academic specializations when the program ends
It can perform the following actions optionally:
Cancel all module bookings which are still active
Create relationship 541”is alumnus of” between ST and O
© SAP 2009
When a de-registered student returns to the university and registers for the program he/she was last
registered in, the system uses the same study object and creates a new study segment.
You can cancel the entire study segment when you de-register a student. Example: On 08/01/2009
you register a student for the 2009/2010 fall semester which begins on 08/16/2009. Then on
08/10/2009, you receive a letter informing you that the student is unable to take up studies due to
personal reasons. You create a withdrawal and set the Cancel study segment indicator. The entire
study segment is cancelled.
The system automatically sets the status “de-registered” and, if an alumnus relationship exists for
the student, also the status “alumnus”.
The system writes an activity document for the selected activity:
• Withdrawal, dismissal, change of program
• Change dismissal, change withdrawal, cancel de-registration
Note: When you cancel a de-registration, the cancellation of sessional registrations or module
bookings or specializations is not automatically reversed. You must do this manually. The validity
of the study segment and the 513 relationship, as well as the statuses, are adjusted accordingly
automatically.
© SAP AG
IHE102
7-40
7 .5 De -regist ra t ion – Cust om izing
Before you can create a de-registration, you must perform the
following preparatory steps:
Create reasons for the de-registration activities
Link reasons to the “dismissal”, “withdrawal” and “cancel de-registration” activities
Define when an alumnus relationship should be created automatically
Depends on the de-registration reason
Customer Enhancements can be implemented via BAdI.
© SAP 2009
Perform the preparatory steps in Customizing under Student Lifecycle Management Processes
Admission, Registration, De-registration:
• Reasons: Create de-registration reasons and assign them to activities.
• Alumnus relationship: You can specify the de-registration reasons for which you want to create
relationship 541 “is alumnus of”. The system creates this relationship between the de-registered
student and an organizational unit and designates the student as an alumnus of this organizational
unit (De-registration > Define Alumnus Relationship for De-registration Reasons).
– Set the Alumnus indicator for the activity/reason combinations for which the system should
create an alumnus relationship between the de-registered student and an organizational unit.
– Example: You want graduated students to become alumni of their organizational unit. You do
not want to create this relationship for students who have withdrawn from the program or
transferred to another university.
You can implement the business add-in (BAdI) HRPIQ00_ALUMNUS_ORG if you want to change
the standard organizational unit assignment for alumnus relationships (De-registration BAdI:
Organizational Unit of Alumnus). You can use this BAdI to:
• Assign an alumnus to a different organizational unit than was derived by the system
• Always use the same organizational unit or do not to create an alumnus relationship at all
© SAP AG
IHE102
7-41
7 .5 De -regist ra t ion – Ex t e nded M a int e nance
Dia log
Two Dialogs of the Student File:
The ‘standard’ student file dialog – transaction code PIQST00
Extended maintenance dialog, offering additional maintenance functions –
transaction code PIQST10.
In the extended maintenance dialog, additional expert functions are
available:
on the Registration tab page
on the Specializations tab page
© SAP 2009
In addition to the standard dialog, the system offers an extended maintenance dialog with additional
expert functions (see Chapter “Student Date Maintenance).
The majority of users will be authorized to use the standard mode. Few expert users will be entitled
to create/maintain data in the extended mode of the student file e.g. for error correction.
Access to the extended maintenance dialog:
• Menu Path: Student Lifecycle Management
(Extended Maintenance), or
• Student File (PIQST00): Edit
Extended Maintenance Dialogs
Student File
Switch Maintenance Dialog
Access to the extended maintenance dialog of the student file requires authorization for transaction
PIQST10 .
Functions for extended maintenance on Registration tab:
• Maintain Registration Data’: Edit sessional registrations and study segments – create new
sessional registrations, change or delete sessional registrations, generate study segments
• Maintain Study Object’: Call standard maintenance dialog for the study object (object type CS)
of the selected program of study
Functions for extended maintenance on Specialization tab:
• Create, display, change or delete direct relationships 516 ‘has academic specialization’ between
the study object (object type CS) and the module group (object type CG)
© SAP AG
IHE102
7-42
7 .5 De -regist ra t ion – T opic Sum ma ry
You are now able to:
Understand the de-registration process
Outline the consequences of de-registration
De-register a student
Use the mass de-registration report
Change a student to an alumnus
Perform the preparatory steps for de-registration
Understand the purpose of the extended
maintenance dialog for registration and
specialization data
© SAP 2009
© SAP AG
IHE102
7-43
7 . Progra m Regist ra t ion – U nit Sum m a ry
You are now able to:
Register new students in the University or a program of
study
Re-register returning students for the next academic
session
Keep a leave of absence record
Switch between the two different (re-)registration
scenarios (implicit and explicit)
Register students for a specialization
Change the program registration to another program
De-register students from a program of study
Use the extended maintenance dialog for registration
and specialization data
© SAP 2009
© SAP AG
IHE102
7-44
I H E1 02 St udent Lifec yc le M anagem ent :
8 . Course Re gist ra t ion
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009
© SAP AG
IHE102
8-1
8 . Course Re gist ra t ion
Contents
8.1
8.2
8.3
8.4
8.5
8.6
8.7
Modules and Events
Booking Procedure
Extended Booking Check
Extended Maintenance Dialogue
Composite Modules
Cohorts
Waiting Lists
© SAP 2009
© SAP AG
IHE102
8-2
8 . T opic Objec t ive s
At the conclusion of this topic, you will be able to:
Understand the technical concept of course booking
Understand features such as the external maintenance dialog and
composite modules
Describe and understand cohorts and mass registration
© SAP 2009
© SAP AG
IHE102
8-3
8 . Course Re gist ra t ion – Busine ss Sc enario
As an Academic Advisor, you advise students on which modules to
book and go with them through the booking process if required.
In your role as instructor you define academic work including individual
work like term papers and theses.
Your University offers web self-service for course booking via the web.
The course registration (module booking) scenario at the University
may include Special course booking approval processes and the
offering of Composite Modules.
Students can be grouped into cohorts and registered for courses
through mass processing.
© SAP 2009
© SAP AG
IHE102
8-4
8 .1 M odule s a nd Eve nt s – Da t a M ode l
ST
Student
513 pursues
506 completes
Add. Data: GUID
CS
Study
SM
Study Module
Store SE
information
in ST – SM
relationship
SE
Event Package
D
Business
Event Type
025 takes part in
040 has
cancelled
GUID
E
Business Event
EL
Time-Independent
Event
520 is assigned to
547 completes
© SAP 2009
When a module (SM) is booked, relationship 506 "completes" is created between the module (SM)
and the student (ST) with the status "booked“.
Additional data is stored in relationship 506:
• Academic year/session, cancellation reason and date, booking date, assessment method (if
individual per student), transfer course (equivalency determination), whether or not free of
charge
• A unique booking ID (GUID) is created. It allows to differentiate between several bookings of a
student to the same module. Different applications use the GUID when referring to the booking.
When an event package (SE) is booked with the SM:
• The event package ID is stored in the module booking relationship 506 ST – SM.
When a business event (E) is booked:
• The relationship 025 "takes part in “ is created between ST and E.
Technical view of preselection, prebooking and cancellation:
• When a module (SM) (and event package) is preselected, prebooked or cancelled:
– Relationship 506 "completes" (ST – SM/CI) is created with the status "preselected",
"prebooked“, or the status is changed to "cancelled" (event package number is entered in the
relationship).
When a business event type (D) is prebooked/cancelled:
• Relationship 027 "has a prebooking for“ is created between ST and E or EL. If the prebooking is
cancelled, the relationship 027 is deleted.
• A business event (E) or time-independent event (EL) cannot be prebooked.
When a business event (E) is cancelled:
• The relationship 040 "has cancelled“ is created between the student and the cancelled event.
© SAP AG
IHE102
8-5
8 .1 M odule s a nd Eve nt s – Book ing Opt ions
Student Lifecycle Management allows for various booking options:
Students can be booked on SM and E/EL, and if applicable, also SE.
Each booking option can be performed in one step.
You can choose from which object you start your bookings.
EL
Book SM + SE + E
SM
SE
Book SE + SM + E
SE
E
Book SM + E
SM
E
For
non-academic
events:
Book E only
SM
E
E
E
E
Book SM only
SM
© SAP 2009
Student Lifecycle Management allows for various booking options:
You can book modules, then select an event package and book the student on the events belonging
to the package.
You can also start from the event package, for example when you work with course codes. Then the
module to which the event package belongs and the events are automatically booked.
If you do not offer event packages, you can book students only on the modules and events offered
by the module.
You can book students only on modules.
Events which are not attached to modules are not provided for the booking options in Student
Lifecycle Management. You can book students only on events via TEM.
Note: This should not be the standard case because study data is stored at the module level. If you
book events only, you will not be able to store results (grades and credits) for student work. The
booking is not stored as academic history of students and will be not available for fee calculation.
If you want to store results for students, you have to book students at least on modules. If you want
to offer students a timetable or check whether their timetable is clash-free, you have to book them on
events, too. You do not need to offer event packages.
© SAP AG
IHE102
8-6
8 .2 Book ing Proce dure – Rule s (1 )
University business rules define booking prerequisites and corequisites, such as:
Minimum/maximum number of modules/credits
Deadlines
Co-requisite modules, Prerequisite modules
Event Packages (Sections) for specific groups of students
Rules are checked at various steps in the process once a
student has registered for a course:
?
yes
no
When you enter the module booking dialog (Call-Up Point 0001)
When you book a list of modules (Call-Up Point 0002)
When you book a single module (Call-Up Point 0003)
SLCM supports the following types of rules:
Simple Prerequisites and Corequisites as relationships in the academic structure
Flexible Rules (VSR). Rule containers are either assigned to callup points directly (general rules)
or linked to the academic structure (rules applying only for specific obj. down to SE).
Booking Time Limits and Windows for Priority Registration
Holds
Most flexible use of Business Add-Ins (BADIs) in booking
Extended booking checks
© SAP 2009
During the module booking process, rules may be applied to check if the booking is allowed. These
can be academic checks such as prerequisites, or administrative checks (deadline and active
registration).
Depending on what the rule is assigned to, SLCM checks rules when:
• The module booking screen is called => to check general module booking eligibility of the
student
• A single module booking is performed => to check prerequisites for the single module
• A list module booking is performed => to check rules applied to a selection of modules
Prerequisite and corequisite rules can be set up within the academic structure:
• Relationships between SM and SM (529 “is prerequisite of” or 533 “is corequisite of”)
• These rules are checked when module bookings (single and multiple) are performed. They can
allow for a conditional module booking if not all of the prerequisites and corequisites are
fulfilled.
Extended Booking Checks or the rules and regulations tool (VSR) framework can be used to define
rules. Callup points define at which time points of the module booking process these rules are
checked.
Four module booking callup points exist:
• 0001 Module Booking (General) – This is the first check to be processed when a module is
booked. This callup point can be used to enforce overall student booking eligibility rules.
• 0002 Module Booking (Set) – This check includes information on all of the student’s past and
current bookings. This is the last check to be processed.
• 0003 Module Booking (Single) – This check is processed for each module currently selected in
the booking screen.
• ‘0090’ for Extended Booking Checks
© SAP AG
IHE102
8-7
8 .2 Book ing Proce dure – Rule s (2 )
You cannot book a student on a Module and/ or Event Package if rules are
not fulfilled, such as:
Student is not admitted for the session (indirect registration) or (non-US business mode)
Student is not registered or re-registered for the session (direct registration)
Module and/ or event package is not offered in the session
Student has not fulfilled the prerequisites or other rules, such as
not taken prerequisite modules
not booked during booking period
These rules can be overridden by authorized users
You can book a student on a module conditionally if the
Module and prerequisite allow conditional bookings and if the
Student has not fulfilled the requirements but is expected to fulfill them
The student has taken but not yet completed a prerequisite module
A rule designated as an “extended check” has not been fulfilled, meaning that a
conditional booking is possible even if the rule check fails
© SAP 2009
You can book a student on a module or event package only if the study object (CS) exists for the
student in question. The study object is created
• during admissions or
• during registration
You can book a student on a module only if it is offered in the selected session
You cannot book a module if rules are not fulfilled / the booking is against the rules. The following
rules are delivered by SAP (hard-coded within the applications):
• Check if student is registered on session for which modules should be booked
• Check if module capacity is not exceeded
• Check module booking periods (time limit 0300)
• Note: Even those rules can be overridden using the rule overriding concept.
Additionally, you can define your own rules, using rule containers, holds and statuses, or customer
enhancements (BADIs), such as prerequisites:
• You can book a student on a module only if the student fulfills the given prerequisites or the
prerequisites or rules allow conditional bookings. The prerequisites can be defined per module or
in general. Conditional bookings are allowed if the “conditional booking allowed” indicator is set
for the co-requisite/prerequisite relationships (529, 533) and for rule containers (509). In the
latter case, the indicator must also be set at the rule module level to define “extended rules”.
© SAP AG
IHE102
8-8
8 .2 Book ing Proce dure – I ndividua l Work
How to book / create individual work:
Prerequisite:
Module or an attached business event type must be from a category defined as
“individual work”
Booking steps:
Start module booking, and select a module into the single booking screen
Book the module and business event (if CI attached to D)
=> Use individual work function to book / create CIs:
Displayed within tab page (if module is assigned CI) or
Displayed next to business event (if event type is assigned CI)
Select an existing individual work object:
Assign student to the CI
=> CI is booked for student
(relationship 547 “completes”)
Enter CI details
Create a new individual work object for
student:
Enter CI details
=> CI is booked for student
(relationship 547 “completes”)
© SAP 2009
You can assign an individual work object to a student in the module booking process. If the lecturer
or instructor has created several individual work objects for a module (representing different term
paper topics), the student can choose the topic (individual work object) (s)he intends to submit.
You can also create an individual work item during the module booking process.
When a lecturer or instructor creates individual work for a module or business event type, (s)he can
create a new individual work object for each topic. This would be the case if a term paper has
different topics.
Note: You cannot book a student on an individual work object without booking the associated
module and business events (if applicable).
© SAP AG
IHE102
8-9
8 .2 Book ing Proce dure – Pre pa ra t ory St e ps
You have to maintain the following Module Bookings settings in Customizing
Maintain booking and cancellation reasons
Maintain cancellation indicator for module cancellation
Configure check for observance of booking periods (time limit 0300)
Assign status and hold types to module booking callup points
To block module booking processes
Customer enhancements for module booking callup points:
Allow for further checks during module booking
Define mode for withdrawal
Customer enhancements for cancellation reason during withdrawal
To set reason dependent on cancellation date
Define module booking environment
Define whether module booking should relate to a program, program type or both (see
progression)
© SAP 2009
In Customizing, choose Processes in Student Lifecycle Management
Module Booking.
1) Details: Define Cancellation Indicators for Module Bookings: You can assign a cancellation
indicator to a module booking record in the module booking activity. Cancellation indicators define
when the system should take a module booking record into account:
• In the prerequisite check for module booking, in progression, in appraisal
2) Details: Configure Check for Observance of Booking Periods
• You define whether or not the system should check if the booking date is within the booking
period (time limit 0300). You can perform this check for the following callup points:
– Callup point 0001 (module booking (general)), callup point 0003 (module booking (single))
3) Details: Define Mode for Withdrawal from Module Dialog
• The system offers the ‘withdrawal from module’ function (cancellation of all modules) in the
module booking dialog. You can set one of the following three values as system response for
withdrawal from modules:
– 'D' = The system cancels booked modules and terminates the dialog. You can set cancellation
reason.
– 'P' = The system displays the booked modules in list form. You can edit the list. The system
sets the default cancellation reason, which you can overwrite.
– 'F' = The system displays the booked modules in list form. You can edit the list. The system
sets the default cancellation reason, which you cannot overwrite.
You also have to make the required Customizing settings for modules, event packages, business
event types and business events within the academic structure. In the academic structure you need to
define for which modules and prerequisites a conditional booking is allowed.
© SAP AG
IHE102
8-10
8 .2 Book ing Proce dure – U se r Ac ce ss
Module Booking is initiated from the Student File transaction
Student ID
Program/Level
Student
File
Module
Booking
Academic
Year/Session
(Re-)registration
Choose from
University Module
Catalog
Choose from Program
Content
© SAP 2009
To access the module booking dialog, navigate to the student file as follows: SAP menu
Lifecycle Management
Student File (Transaction PIQST00).
Student
• Select a student. On the Registration tab page, select the Program you want to enter bookings for.
Then choose the Icon: [Program Content].
• When you enter the program content, the module booking screen is displayed.
You can select the modules you want to book either:
• From the module catalog or you can select only those modules which are offered in the selected
program of study.
• The module booking does not restrict students to modules within the program.
© SAP AG
IHE102
8-11
8 .2 Book ing Proce dure – Book ing Dia log
Ove rvie w
Se le c t
M odule s
From
module
catalog
Book ing
Dia log
Book ing
H ist ory
M odule
De t a ils
Se le c t ion
List of Modules
Overview
Details per
Module
Select
Book module
(SM)
Book event
package (SE)
Book business
event (E)
Select modules
according to
selection
criteria
Predefine a list
and enter in
shopping
basket
From
program of
study
Store modules as
preselection
Book list of
modules
Cancel module
bookings
Booked modules
Filter for booking
history
Graphical
statistics
Object Manager
= Shopping Basket
= Single Booking
© SAP 2009
The module booking screen offers four sections (tab pages) where you can perform different steps of
the booking process. On the left side, modules are selected using the object manager and its search
tools. To locate modules via the Object Manager, you can:
• Use the Structure Search option to access the institution’s complete organizational structure and
view the modules that are offered by each organizational unit (module catalog view)
• Use the Search Term option to locate modules by name (e.g. math*) to locate modules directly
linked to a particular organizational unit (e.g. Math Department), or to locate modules that are
indirectly linked to a particular organizational unit (e.g. Faculty of Sciences that includes the
Math Department).
The Booking dialog tab page is the "shopping basket" for module bookings:
• It is filled in by the selections chosen under Module details (for one module and its event
packages/events) and under Selection (choose a list of modules by defining filter criteria).
• It offers the possibility to preselect, prebook, book or cancel modules. You can also change the
status of the module booking, for example from preselect to book.
• The preselected list of modules is stored within the Booking dialog tab page. It shows the number
of booked modules and attempted credits.
• You can access all booked events belonging to the module bookings by choosing Business
events.
The Booking history tab page shows an overview of all booked modules.
The Module details tab page is used for single module bookings: Here you can select a single
module, view the module details, and select event packages or business events.
The Selection tab page offers various selection possibilities for selecting a list of modules which
fulfill certain criteria in one step and copying it to the Booking dialog tab page.
© SAP AG
IHE102
8-12
8 .2 Book ing Proce dure – M odule De ta ils T a b
Pa ge (1 )
How to use:
1) Select the module from the Object Manager
2) Module details are shown
3) Scheduled event packages and business events are displayed for the specified academic
year and session
4) If module category is “individual work”, the system offers a function for booking of
individual work
Object Manager
English Department
...
History Department
...
Mathematics
Department
Math200
Math201
Math210
Math211
Math261
...
Module Details
Math261 Calculus & Analytic Geometry I
Credits = 3
Grading Scale = ABC
CI
Level = 200 Level
Discipline = Mathematics
____________________________________________________
Academic Year = 2008 Session = Fall
Event Package 1
Lecture
MWF 9-10 / Main Campus / Bryant Hall Rm 201 / Prof.
Smith
Tutorial
Wed 10-11 / Main Campus/ Bryant Hall Rm 300 / D.
Jackson
Event Package 2
© SAP 2009
To select a module, you locate it via the Object Manager and select it (double-click) in order to
commence booking.
The selected module will then be copied over to the Module details tab page, where the available
business events/event packages/individual work for the current academic year and session (based on
today’s date) will be displayed.
If this module has not been scheduled for the current academic year/session, the system indicates the
next academic year/session in which business event/event packages are scheduled for this module.
If you use any of the booking modes, a detail screen on which you can specify booking details
appears:
• You can change the default academic year/session if it is necessary to book students for future
academic year/session combinations.
• You can select event packages, business events or individual work if offered
• You can define booking details for the module, such as:
– For ‘variable credit’ modules, you can specify the number of credits to be attempted (a value
that falls between the module minimum and maximum credit values).
• You can specify the assessment method (used for grading).
• If the module should be booked free of charge (yes/no)
© SAP AG
IHE102
8-13
8 .2 Book ing Proce dure – M odule De ta ils T a b
Pa ge (2 )
How to use:
Selecting the event package/business events
Single booking option processes one event package/business event at a time
Copy option supports “shopping basket” processing of all selected event
packages/business events to be booked
Module Details
Math261 Calculus & Analytic Geometry I
Academic Year = 2008
Session = Fall
Section 1
Lecture
Tutorial
MWF 9-10 / Main Campus / Bryant Hall Rm 201 / Prof. Smith
Wed 10-11 / Main Campus/ Bryant Hall Rm 300 / D. Jackson
Section 2
Section 3
COPY
SINGLE
Multiple Bookings
BOOKING
Individual Bookings
(Shopping Basket)
© SAP 2009
You can decide whether you want to make a single booking or copy the selected module/event
package/business event to the Module dialog tab page.
If you copy it to the Module dialog tab page:
• You are able to book the module as part of your shopping basket. The advantage is that rules
defined for the shopping basket can be applied (i.e. taking into account a list of modules)
• The module will get the status “book”, and you cannot select the booking mode.
• You are not able to enter any booking details. They will be defaulted by the module details.
If you decide on a single booking:
• You can select the booking mode
• You can specify module details
• You are not able to apply rules for a list of modules (such as minimum or maximum number of
attempted credits necessary or allowed during one session).
© SAP AG
IHE102
8-14
8 .2 Book ing H ist ory a nd Ac t ivit y Doc ume nt s
The Booking History tab provides an overview of the student’s complete booking history
for a program of study including academic history information (grades, attempted and
earned credits, booking status)
Program of Study X
Booking History
Academic Year = 2008
Booking Status = Booked
ENGL200
GER356
MATH261
MATH300
PHYS257
...
Section 1
Section 5
Section 1
Section 3
Section 2
3 credits
4 credits
3 credits
6 credits
3 credits
Session =
Stage =
A
3
ABC grading scale...
4 point scale...
ABC grading scale...
ABC grading scale...
P/F grading scale...
Each time you create a new module booking or change an existing one, activity
documents and change documents are written to the database.
The activity document dialog box shows a list of the existing documents with information
on the activity, the person who created the document, key date and time, and changes
made to the module booking including fields and content that were changed
© SAP 2009
You can view a student’s booking history on the Booking History tab page. You can show the whole
history, or you can apply different filter criteria to limit the displayed bookings, such as:
• Academic year and session
• Booking status
• Stage
You can also display statistical information on all bookings (Show statistics), counting the total
number of modules and attempted credits which have been:
• Successfully completed (result of grading)
• Unsuccessfully completed (result of grading)
• Booked
• Cancelled
You can display activity documents by choosing a module booking on the Booking Dialog or
Booking History tab page and double-clicking the selected booking. The detail module booking
screen appears. There, choose the menu item :
• Extras
•
Activity Documents
© SAP AG
IHE102
8-15
8 .2 Book ing Proce dure – Priorit y Re gist ra t ion
Window s
The priority window attribute is set in the Student Master Data
ST
Student
Booking Window:
Academic Calendar
Time Limit 0300: Booking Window
UG05
UG05 10/01/2008 8:00 – 10:30
Check
Books at date/ time
10/01/2008, 8:45
SM
OK:
Not OK:
Module
Student is
booked to the
Module
Error message
(overridable)
© SAP 2009
© SAP AG
IHE102
8-16
8 .2 Book ing Proce dure :
We b Course Re gist ra t ion
Components
The Web Course registration Web Dynpro application (PIQ_MBSS_OIF) corresponds to the
module booking function in the back-end system with no difference in the framework. Its high
flexibility offers customers the option to configure the User Interface according to their
preferences.
Due to the separation of frontend and backend, the UI layer and the business logic layer
are totally separated. Therefore the application can be ‘de-coupled’ from the backend
system for better performance and security.
From a role perspective module booking in the back-end is designed for registrars, while the
course registration function is designed for the Student role as a Web application.
The web course registration UI provides the following functions:
Creating own customer messages, mapping system messages to student-friendly messages and
suppressing any system message from being displayed
Defining special categories for modules (e. g. ‘honors’ classes)
Definition of default cancellation reasons if students shall not be allowed to choose any cancellation
reason
Definition of default booking reason if students shall not be allowed to define any booking reason.
For details go to: http://www.sdn.sap.com/irj/bpx/highered
Student Lifecycle Management Best
Practices, Implementation Guidelines, and Tutorials -> SLCM Web Registration Cookbook
© SAP 2009
BAdIs allow to define specific system behavior in customizing
• Filtering search query results
• Defining precheck conditions based on a filter
• Setting booking level (M/E/SE). Default implementation is provided
• Filter academic periods that are shown on initial screen (HRPIQ00MBSS_PERIOD_FILTER)
• Filter values in the dropdown boxes in the Advanced Search (e.g. based on Subject Area)
• Map search criteria values selected by the student to internal values (e.g. Subject Area->
Discipline)
For using the above mentioned default cancellation reason function, a default cancellation reason
must be specified (from any of the existing cancellation reasons). Various cancellation reasons can
be specified for bookings includ. waitlisted bookings.
The special module category cannot be created within the Academic Structure. The special category
allows to classify courses through the category assignment. Users can define what Module Group
Category will be used, create Module Groups of these categories and assign modules to them.
Customers can add a firewall between the frontend and install layers on different servers. An
authorization check at application level and data level ensures that users can perform permitted
actions only. Students are permitted to only access the front-end servers that are outside the firewall.
Their operations are filtered and limited by the firewall. All the productive servers are inside the
firewall and are protected, also in case of e.g. a front-end system overload or crash.
Authorizations that are checked during Course Registration include:
• MB01: Create New Module Booking
• MB02: Change Module Booking
• MB03: Cancel Module Booking
• MB04: Display Module Booking (Basic authorization: If the user does not have this
authorization, he or she cannot navigate from the initial page to subsequent pages.
© SAP AG
IHE102
8-17
8 .2 M odule Booking Proc e dure : Com pa rison of
Ba c k e nd Fe at ures a nd We b Course Re gist ra tion
The backend checks for module booking are included in 3 check points:
0001: General Check
0002: Basket Check
0003: Individual Check
Students need to pass the checks for all 3 check points before booking/cancelling a module.
The Web Course Registration follows the same checking concept, i.e. all the checks (point)
done in the backend transaction are also performed in course registration. But here, the
concept of ‘Pre-check’s is introduced. Pre-checks are done before a user tries to perform
actions, e.g. start booking, cancel booking, or add new booking, etc.
These Pre-checks offer the following advantages:
Improved usability
Early warning: certain warnings are necessary in order to inform students about the
possible consequences of certain actions before they actually execute them.
Increased transparency
© SAP 2009
The Web Course Registration offers the following options:
• Determine which academic sessions should be displayed in the drop-down
• Assist students to select their modules and define the module group category which will be used
• Restrict Search Drop-Down-Lists
• Mapping Search: Allow the single search drop-down value to match against multiple system
values, e.g., Subject Area ’01’ should match against back-end values ’01’, ’01.01’, ’01.02’, etc.
The general Business Add-in HRPIQ00MBSS_PRECHECK allows to add your own
rules/messages. Default implementations for different filter values are offered in the system. You
can create BadI implementation with one of the following Filter Values:
• BOOK_OFFER: Book Module and Section
• MOVEUP_WAITL: Move up a module from waitlist
• SWAP_SECTION: Swap/Change booked section
• CANCEL_BOOKED: Cancel a booked course
• CANCEL_WAITL: Remove a course from waitlist
• ESTIMATE_FEE: Tuition Estimation
IMG path: SLCM
Role-based Web UI
Student Role
Course Registration UI.
Available import parameters are Student Object, Booking Context, Modules booked/cancelled, and
Events booked/cancelled
© SAP AG
IHE102
8-18
8 .3 Ex t ende d Book ing Chec k
The Extended Booking Check framework allows Universities to implement complex conditions to
be evaluated during module booking. This option meets a business need as module booking
scenarios oftentimes require an ‘OR’ relationship among pre-requisites for courses besides
‘AND’ relationships as the following examples demonstrate:
‘Credited Work’ fulfills pre-requisite
Take Math101 OR equivalent credited work
‘OR’ operator across pre-requisite modules
The Extended Booking Check
functionality allows to assign prerequisites and co-requisites
directly to a module and therefore
permits to map these examples in
the system.
Take Math101 OR Math102 OR Math 103
‘AND’ operator across multiple ‘OR’ groupings
Take Math101 OR Math102 OR Math103
AND
Take Stat101 OR Stat102
‘OR’ operator across multiple ‘AND’ groupings
Take Math101 AND Math102
OR
Take Stat101 AND Stat102
Take X modules out of Y choices
Take any 2 of the following: Math101, Math102, Math103, Math104
© SAP 2009
Without the availability of the flexible Extended Booking check (based on the ‘old pre-requisite
rules), a list of modules would have to be defined as pre-requisites and co-requisites by using the
‘AND’ relationship. Example: If you specified that modules named Basic Arts 1 and Basic Arts 2
are pre-requisites of the module Advanced Arts 1, the student is required to have completed (or at
least booked) both ‘Basic Arts’ modules before booking Advanced Arts 1. In that case the system
does 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.
If VSR-based workarounds are used to map the above example which represents a simple prerequisite check, this would result in a huge volume of VSR rules. Details of the Validation,
Substitution, and Rules (VSR) framework are described in the Chapter ‘Tools’.
With the availability of the Extended Booking framework, VSR validation rules may be applied in
specific cases. The majority of rules can be mapped with the Extended Booking check framework.
‘Old’ pre-requisite rules in the system will not be affected by the Extended Booking framework.
The following slides provide an overview on the Extended Booking Check. For details on this
functionality please refer to the following documentation: https://www.sdn.sap.com/irj/bpx/highered
-> Knowledge Center -> Student Lifecycle Management Best Practices, Implementation Guidelines
and Tutorials -> BPX Extended Booking Check Cookbook.
© SAP AG
IHE102
8-19
8 .3 Ex t ende d Book ing Chec k
Graphical Description of Relationships
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
Extended Booking Rule Containers can be flagged as ‘conditional’ and/or ‘OR’ operator
© SAP 2009
Transaction PIQEXTCHECK (Student Lifecycle Management Menu-> Academic Structure->
Rules-> Extended Booking Checks opens the Edit Extended Booking Check maintenance screen:
• To maintain extended booking conditions, go to button and menu entry Edit Extended Booking
Condition on the Module Catalog screen to open the pre-requisite 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. To achieve this, rule
containers (RC) containing rule modules (RM) can be assigned to a module.
The following detailed functions are available in transaction PIQEXTCHECK:
• Create new requirements (RC).
• Create new sub-requirements (Index-dependent RM/‘Booking Check’ and Index-independent
RM ‘Booking Check’).
– Requirements are called index-dependent if they are represented by a specific index (e.g.
grade). Example module has to be completed with a specific grade or better.
– Requirements are index-independent if no specific index is assigned to them. Example:
student must select module from a specific discipline.
• 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. You can use the existing conditions created for pre-requisite or co-requisite checks or create own
BAdI implementation for different checks.
• 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.
© SAP AG
IHE102
8-20
8 .3 Ex t ende d Book ing Chec k
Rule Containers Characteristics
Use of ‘AND’ & ‘OR’ Logic within Rule Containers and Rule Modules
Multiple Rule Containers
© SAP 2009
Use of ‘AND’ & ‘OR’ Logic within Rule Containers and Rule Modules
• When multiple subrequirements are included in a RC, they are by default joined by ‘AND’. In
this case, the ‘worst’ subrequirement result becomes the overall result of the Rule Container.
• When the ‘Logical OR’ flag is activated for the RC, the RC receives the ‘best’ result of the
included subrequirements.
Multiple Rule Containers
Each Module can have multiple Rule Containers for Extended Booking Checks. The logical
operator across multiple Rule Containers is ‘AND’. It would be used in cases where you want to
combine different modules on the level of a rule container.
The ‘worst’ Rule Container result becomes the final result of the Extended Booking Check.
© SAP AG
IHE102
8-21
8 .3 Ex t ende d Book ing Chec k : Condit ional
Book ing
You can conditionally book a student on a module in the following cases:
The module and pre-requisite allow conditional bookings
conditional booking is active
Student has booked but not yet completed a pre-requisite module.
If the system detects during the evaluation of extended booking checks that a module can be
booked conditionally by a student, then
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.
the user can set the conditional booking status in the module booking dialog via the student file:
Manual Conditional Booking.
Each Rule Container can be flagged as ‘Conditional’.
Each subrequirement sets its individual result. Possible values, from ‘best’ to ‘worst’, are:
– P – Passed
– U – Undefined
– N – Not Passed
SAP delivers two conditions:
SAP8 Pre-requisite condition: To indicate the number of SM/CW that must be completed.
SAP9 Co-requisite condition: To include the module ID of the co-requisite module (only one value).
© SAP 2009
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 and will respond as follows:
• Sub-requirement Evaluation: The system checks whether or not the pre-requisite module has
been booked and completed. If the pre-requisite 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.
• Co-requisite Check: The system checks if the co-requisite module has been booked along with
the selected module. If the co-requisite 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.
Note: The user cannot manually set the Automatic Conditional Booking status during module
booking.
For Index-Dependent subrequirements in a ‘Conditional’ Rule Container, the result is always ‘P’ or
‘U’. (i.e. ‘N’ becomes ‘U’)
For Index-Independent subrequirements, SAP delivers two BAdi’s which must set the results:
• SAP8: Pre-requisite Check
• SAP9: Co-requisite Check
© SAP AG
IHE102
8-22
8 .3 Ove rride of Ex t ende d Book ing Che ck
Override of Extended Booking Check:
You can override error messages that are generated during module booking and 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.
© SAP 2009
The Message Log will state whether a module can be conditionally booked, booked as normal or
cannot be booked at all. Messages shall be overwritable e.g. by a Registrar.
You are authorized to override the overall booking result of the extended check and proceed with the
normal booking. The permission for overriding error messages can be maintained in the message
control of the rule container. Override of any RC provides override of the entire Extended Booking
Check.
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.
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.
If a student has a Special Approval for the booking, callup point 0090 is skipped altogether (i.e.
Extended Booking Check is not carried out).
© SAP AG
IHE102
8-23
8 .3 Ex t ende d Book ing Chec k : Se t U p
The following steps are required before the actual setup:
Analyze the checks that need to be set up for booking a module.
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.
Set the conditional booking OR enabling indicator as required for a condition.
Set up the message override function as required.
© SAP 2009
Please refer to the examples and scenarios described in the Extended Booking Check Cookbook
which you find in the BPX for Higher Education.
© SAP AG
IHE102
8-24
8 .4 Ex t . M a int e na nc e Dia log for
Ac adem ic Work – T opic Obje c t ive s
At the conclusion of this topic, you will be able to:
Explain the concept of academic work
Use the extended maintenance dialog for academic work
© SAP 2009
© SAP AG
IHE102
8-25
8 .4 Ex t . M a int e na nc e Dia log for Ac ade m ic
Work – Ove rvie w
Scope of Internal Academic Work
Academic Work
includes
Transferred Work
Module Work
Transferred or
Completed
Completed Work
Miscellaneous
Academic Work
The Elements of Internal Academic Work
Name
Description
Academic
Work
Academic work includes module work
and miscellaneous academic work,
both of which can be completed or
transferred.
Transferred
Work
Academic work which the equivalency
determination application (transaction
PIQED) acknowledged as equivalent to
internal academic work.
Completed
Work
Academic work completed at the
university. Completed academic work
can have different booking and
appraisal statuses.
Module Work
Module work includes both completed
and transferred module work.
Completed module work includes the
modules that a student has booked.
Miscellaneou
s Academic
Work
Any type of academic work completed
by the student which does not relate to
a specific module.
Transferred or
Completed
© SAP 2009
© SAP AG
IHE102
8-26
8 .4 Ex t . M a int e na nc e Dia log for Ac ade m ic
Work – T ra nsac t ions
The extended maintenance dialog transaction contains additional expert functions for
editing academic work records
You can access these by choosing “Academic Work Overview” in the student file (extended
maintenance dialog)
The Student File contains two dialog transactions:
The “standard” student file dialog transaction (PIQST00)
The extended maintenance dialog transaction (PIQST10) which offers additional
maintenance functions
You can access Academic Work in the Extended Maintenance transaction directly:
Menu: SLCM
Extended Maintenance Dialogs
Academic Work
Transaction ‘PIQSTAW10’
© SAP 2009
The system contains a standard maintenance dialog and an extended maintenance dialog with
additional expert functions.
Normally, many users in the system will be authorized to use the standard student file transaction.
However, only a few expert users will be entitled to create and maintain data using the extended
maintenance dialog of the student file, for example to correct errors, enter missing data, etc.
You can access the extended maintenance dialog in two ways:
• Menu path: Student Lifecycle Management
(Extended Maintenance), or
Extended Maintenance Dialogs
Student File
• Student File (PIQST00): Edit – Switch Maintenance Dialog
You require an authorization for transaction PIQST10 to access the extended maintenance dialog of
the student file.
© SAP AG
IHE102
8-27
8 .4 Ex t . M a int e na nc e Dia log for Ac ade m ic
Work – Func t ions
Functions in the extended maintenance dialog for academic work:
Create and edit academic work records (activity documents are created)
Physically delete academic work records from the system (an activity document is
created)
Create/edit module work and miscellaneous academic work, both completed and
transferred
Edit certain appraisal data (see Appraisal unit)
Perform checks which guarantee technical and data model consistency (always
executed). Business checks (like VSR checks, checks in customer exits, capacity checks
and booking time limits for module work) are not executed
Note:
Academic work records which are edited in the extended maintenance dialog can no
longer be edited in the module booking or appraisal dialog. These records can only
be displayed there. Further changes can only be made in the extended maintenance
dialog
© SAP 2009
The extended maintenance dialog should only be used in exceptional cases, for example to:
• Correct errors
• Change data which cannot be changed with standard functions
© SAP AG
IHE102
8-28
8 .4 Ex t . M a int e na nc e Dia log for Ac ade m ic
Work – T opic Sum m a ry
You are now able to:
Explain the concept of academic work
Use the extended maintenance dialog for academic work
© SAP 2009
© SAP AG
IHE102
8-29
8 .5 Composit e M odule s – T opic Obje c t ive s
At the conclusion of this topic, you will be able to:
Explain the concept of composite module
Use the concept of composite module for academic work
© SAP 2009
© SAP AG
IHE102
8-30
8 .5 Composit e M odule s – Busine ss Ex ample
For some scenarios, the appropriate grade for a module must take into
account the grades that were received in other related/included modules.
This may be the case especially for year-long courses, where the grade
earned in the Fall session is one of the factors for Spring grading.
© SAP 2009
© SAP AG
IHE102
8-31
8 .5 Wha t is a Com posit e M odule ?
Appraisal transaction
PIQSMFU allows to
view Appraisals of
included modules
Composite
Module
SM
CRS101
(Year Long Course)
A composite module:
- has other ‘included’ modules
- factors the appraisals of ‘included’
modules into its final appraisal
Infotype 1764 Included in
Appraisal
SM
CRS10F
(Part 1)
SM
CRS10S
(Part 2)
© SAP 2009
Business Example for a composite module scenario:
• A year-long Course (CRS101) is taken in two parts (CRS101F and CRS101S)
• Student books CRS101 and CRS101F in the Fall Semester
• Student receives an ‘interim’ grade for CRS101F
• Booking for CRS101 is continued into the Spring
• Student books CRS101S in the Spring Semester
• Student’s grades for CRS101S and CRS101F are ‘rolled up’ into the appraisal for CRS101, along
with any other elements, such as an overall exam
Module infotype for ‘included’ Modules is IT 1764. To maintain it via transaction PIQSM:
• Select the tab [Include in Appraisal]
• Select the radio button [UD Selection]
• Select the pushbutton [Add Modules] to select relevant modules.
• Select [Save] to complete.
OPTION for the above example: You could additionally put CRS101, CRS101F, and CRS101S into
a Module Group together to further document the Composite Module. The Module Group is
available as a field in the Academic Work display, for example.
Note: If you use Module Groups to encapsulate Composite Modules, these modules should not be
directly included in other Module Groups.
To include a Module in multiple Composite Modules use the ‘Cross-Listing’ option of Modules.
• Appraisals Templates can reference Appraisals of included Modules (as Appraisal elements with
automatic calculation).
• Various RFCs and BAdI implementations are available to help manage the specific process for
an institution (via a customer report).
© SAP AG
IHE102
8-32
8 .5 Composit e M odule s – Defining a n
Appropria t e Appra isa l T e mpla t e
1. Define Performance Index and assign appropriate PI Calculation
2. Create Key Figure and assign Performance Index
3. Create an Appraisal Type
4. Assign your Appraisal Type to a new Appraisal Template and use your new Key Figure
Composite Module
SM comp
KeyFigure: Incl.SM
SM Part 1
Weighting 50
SM Part 2
Weighting 50
© SAP 2009
You need a Key Figure for this purpose:
• First, create a PI Calculation that returns a grade average and attempted credits (similar to
calculation ‘GRAD’, but with credits)
• Next, create a Performance Index using that PI calculation
• Next, create a Key Figure that uses that Performance Index
• Next, create an Appraisal Type for ‘Included Module Grades’
© SAP AG
IHE102
8-33
8 .5 Composit e M odule s – T opic Sum ma ry
You are now be able to:
Explain the concept of composite modules
Use the concept of composite modules for academic work
© SAP 2009
© SAP AG
IHE102
8-34
8 .6 Cohort s – T opic Objec t ive s
At the conclusion of this chaper you will be able to:
Understand where and how cohorts can be used for mass registration
© SAP 2009
© SAP AG
IHE102
8-35
8 .6 Cohort s – Busine ss Sce na rio
You have a group of incoming Students who all share similar academic
attributes (e.g. first-year law students). You wish to administer their course
registrations as a group, so that they all are booked into the same
Courses/Sections.
For a general introduction into cohorts please also refer to Chapter 3:
“Event Planning with cohorts”
© SAP 2009
© SAP AG
IHE102
8-36
8 .6 Cohort s – Short Re pe t it ion
Cohorts are created via the cohort builder (PIQCOH00):
When you create a cohort you also maintain:
The cohort context (e.g. module booking)
Attributes:
Capacity
Organizational Unit
Program of Study
sessions of offering at main cohort level
Context Objects:
E.g. Study modules, events
Cohort Hierarchy
© SAP 2009
Access the Cohort Builder using either of the following methods:
Transaction: PIQCOH00
Menu Path: Student Lifecycle Management>Tools>Cohort Builder
Note:
• Every change you make in the Cohort Builder takes effect from the Key Date (until 12/31/9999),
except for the Events and Module Bookings, which take effect from the specified Academic
Period.
Note:
• Sessions of Offering and Context Objects assigned to the main Cohort are inherited by SubCohort.
© SAP AG
IHE102
8-37
8 .6 Cohort s – Distribut ion of St udent s
Busine ss Exa mple
At some Universities, Students are placed into the Main
Cohort and then randomly distributed to the Sub-Cohorts.
For example, all incoming Freshmen for a College may be
in the same Main Cohort, but also placed in Sub-Cohorts
and then booked into a set group of Sections (based on the
Sub-Cohort).
© SAP 2009
© SAP AG
IHE102
8-38
8 .6 Cohort s – St udent Dist ribut ion
Students can be distributed via using a Pushbutton Function
Student Distribution Features
Students are only distributed to the next lower Cohort level
After distribution, students will be DIRECT members of the Sub-Cohort
Students will remain members of the Main Cohort but by inheritance only
Students will be distributed according to the capacity of the Sub-Cohorts (i.e. if
you have more Students in the Main Cohort than the sum of all the capacities in
the Sub-Cohorts, then not all students will be distributed.)
© SAP 2009
Student Distribution via Pushbutton Functionality:
• Use a Selection Method to add students to the Main Cohort for distribution. (e.g. all incoming
Freshmen)
• After all students are added to the Main Cohort, use the push button [Students] or the Function
Key [F9] to distribute them to the Sub-Cohorts
• A Pop-up window with traffic light log display will be presented with the list of students to be
distributed.
Students are distributed in ‘Round Robin’ fashion according to the following algorithm:
• Take the students in the appropriate order from the list of the Main Cohort to the first Sub-Cohort
until its optimal capacity is reached.
• Continue in order with the list to the second Sub-Cohort, until again its optimal capacity is
reached
Cohort assignments can be viewed on the [Cohort] tab in the Student File.
Note: The order of the main cohort list is controlled by the user with the ALV grid. The student
distributor button respects the order of the main cohort list
The algorithm for the distribution of the students can be changed by implementing a delivered
BAdI:
• BAdI: Distribute Students from Cohort to Sub-cohorts (ES_HRPIQ00COHORTS_DIST)
• Method: DISTRIBUTE_STUDENTS
• IMG Path: Student Lifecycle Management > Processes in Student Lifecycle Management >
Cohorts
© SAP AG
IHE102
8-39
8 .6 Cohort s – M a ss Book ing Pre pa ra t ion
Context Objects in Cohorts:
Context Objects
Module bookings should always be
handled by Cohorts that have the context
Module Booking (0001).
Main Cohort | SM
The context object Modules (SM) should
be added to the main cohort.
The context objects of the Main Cohort are
inherited by the Sub-Cohorts.
If Event Packages (SE) or Events (E) are
involved, add the Event Packages and/or
Events into the Sub-Cohorts.
Sub Cohort [SM]
SE
E
© SAP 2009
The Cohort Builder is used as a planning and reporting tool for Module Bookings.
Module bookings can be performed in the Cohort Builder, but in reverse, the Cohorts are not
updated by the Module Booking application. All existing data related to Module bookings, Sessional
Registrations and Where-Used Lists is affected if the Cohort Builder application is used.
The Module Study Plan application (in the Academic Advisor UI) also uses Cohorts. Module Study
Plans are Cohorts for one single student, and have the Context 0002. Since many Study Plans may
exist in a productive system, it is suggested that you hide Context 0002 Cohorts in the Object
Manager in the Cohort Builder UI.
If new bookings disappear after a change of the Cohort’s context objects in the “Complete Module
Bookings Mode”, they will nevertheless be saved to the database when you hit the <Save> button.
This enables you to run mass module bookings for several different sets of offerings before saving
all the changes of the context objects finally to the database.
You can use Cohorts either hierarchically or flatly. If you use them hierarchically, Module bookings
are taken into account for all students and context objects, whether they are inherited or not.
In a Cohort-hierarchy the result of a “Missing Bookings Analysis” depends on the hierarchy level.
© SAP AG
IHE102
8-40
8 .6 Cohort s – M a ss Book ing Proce ss
Mass Booking Process – Steps:
First, assign students to the Sub-Cohort that you wish to book.
Enter the Cohort context of ‘Event Package’, ‘Module’, or ‘Event’
Select the Push Button: [Module Booking]
Result:
If a Student belonging to the Sub-Cohort has already booked this offering with exactly the
set of SM, SE, E, EL, which define an offering in this booking period, bookings are shown
on the [Bookings] tab.
If Event Packages are part of the Cohort, but Events are not, all Module bookings of the
SM-SE in question will be shown, regardless of the Event. If Events are part of the Cohort,
the Module booking will be shown, only if it consists of the exact set of objects SM-SE-E
After changes of the context object content, push <Refresh> on the Bookings tab in order
to see the correct Module bookings.
© SAP 2009
Mass Booking Process – Steps:
• Assign students to the Sub-Cohort that you wish to book.
• Enter the Cohort context of ‘Event Package’, ‘Module’, or ‘Event’ via tab [Context Objs]
• Select the Push Button: [Module Booking] or (CTRL+SHIFT+F9)
• Select an Academic Year and Session in the pop-up window. The message “Mass Update is
available for Module Booking” and will be displayed at the bottom of the screen.
Note: The context object of the Main Cohort (Module) must exist and be inherited by the SubCohort (or be entered directly) in order for the for Mass Booking to work.
Hints and Remarks:
• If new bookings disappear after a change of the cohort’s context objects in the “missing booking
mode”, they will nevertheless be saved to the database when you hit the <Save> button. This
enables you to run mass module bookings for several different sets of offerings before saving all
the changes of the context objects finally to the database.
• You can use cohorts either hierarchically or flatly. If you use them hierarchically, module
bookings are taken into account for all students and context objects, whether they are inherited or
not.
• In a cohort-hierarchy the result of a “missing booking analysis” depends on the hierarchy level.
• The mass module booking functionality is available for cohorts of the context “0001” (Module
Booking) and “0002” (Module Plan) only. Customer contexts “Z***” cannot be used for mass
module bookings.
© SAP AG
IHE102
8-41
8 .6 Cohort s – M a ss Book ing Proce ss
Analyze Outstanding Bookings
After mass booking has been initiated, complete Module bookings by selecting the “Complete
Module Bookings” Icon
Specify the Module Booking Context if necessary
A pop-up shows for which students of the Cohort and for which offerings a new Module
booking could not be created
The required additional Module bookings are shown together with the already existing ones.
SAVE your Bookings
All data is held in a buffer but not completely booked.
Press the SAVE button.
© SAP 2009
SAVE YOUR WORK! After switching to the “Complete Module Bookings Mode”, all required
module bookings will be done, but they are not yet saved to the database. The data is held in the
buffer and the slots of the courses are reserved in a special buffer.
The affected students are locked until the Module bookings are saved to the database.
When the Module bookings are saved, no more business checks (e.g. checks at the call-up points)
are performed. All business checks are done during the “Missing Booking Analysis”.
As soon as you have switched to the “Complete Module Bookings Mode”, changes of the Context
Objects can lead to new bookings automatically. They will be saved after hitting the <Save>-button.
Notes:
• Even the activity documents, the registrations in background and so on are saved only after
pushing the <Save>-button in the Cohort Builder.
• Leaving the Cohort transaction without saving will lead to a data loss!
• You can use this feature to run test mass bookings. These bookings are absolute valid bookings
with all business checks and most of the technical checks already done, but without being saved
to the database.
© SAP AG
IHE102
8-42
8 .6 Cohort s – T opic Sum ma ry
Now you are able to:
Create Sub-Cohorts directly from the main cohort
Distribute Students from a Main Cohort to its Sub-Cohorts
Mass book Students from a Cohort (or Sub-Cohort) into a specific Module or
Event Package
© SAP 2009
© SAP AG
IHE102
8-43
8 .7 Wa it ing List – T opic obje c t ive s
After completing this topic, you will be able to:
Understand the concept of waiting List for module and event booking
Understand the move up funcitonality within the waiting list
Capture how capacity checks are being used and applied to waiting lists
© SAP 2009
© SAP AG
IHE102
8-44
8 .7 Wa it ing List s – Busine ss Sc ena rio
For courses with limited capacity and more demand than places, students
should be allocated to all available seats. Waiting lists enable you to fill the
places in case students cancel their booking.
Furthermore, a University may want to give some students priority to
access a course before other students. For example, seats should be kept
free for students who have to take this course as a mandatory part of their
studies.
© SAP 2009
© SAP AG
IHE102
8-45
8 .7 Wa it ing List s – M odule Book ing Ove rvie w
Waiting lists for module bookings are supported as follows:
Students can be booked on Waiting lists
Waitlisted students can be moved up to regular seats as soon as they become available
Controlled by booking priority or booking date and time
Students can accept the offer and move up via self-service
Module XYZ:
capacity: 20
waitlisted students: 2
booked students: 20
Waiting list bookings are necessary when the capacity and resource limit of a course is reached
Waiting list bookings are done either manually
or in an automated way
© SAP 2009
Students can be booked on waiting lists for courses and be moved up to regular seats as soon as they
become available. That can be controlled by booking priority or the booking date and time or by
customer defined details.
Students can be moved up automatically or can accept the offer and move up in a self-service.
During the module booking process capacity and availability of courses are checked. Once the
capacity and resource limit of a course is reached the student can be booked on a Waiting list, either
manually or in an automated way.
For maintaining waiting lists a report is available. With this, waiting lists can be viewed and the
process to fill up available seats can be started.
© SAP AG
IHE102
8-46
8 .7 Wa it ing List s – Eve nt Pa c ka ge s and Eve nt s
Waiting lists can be created for
Modules (SM)
Event Packages (SE)
Events (E)
A waiting list is created when students are booked beyond the optimum number of
available seats of a module, event package or event.
automatically by the system
manually within the booking dialogue
for events, only manual waiting list booking is possible
To use the waiting list functionality, you have to define in customizing:
the standard waiting list level (on which object type (SM, SE or E) you usually create
waiting lists
the capacity of waiting lists (globally)
booking priority ranges for module, event packages and events
the eligibility to move up
Your own sorting criteria for waiting lists (BADI Implementation)
© SAP 2009
You can define for which of the object types SM, SE or E the system should allow waiting lists.
This is done by defining the waiting list level. This can either be done
• Globally for all study modules in the system (via Customizing, Student Lifecycle Management
Processes in Student Lifecycle Management Module booking Waiting lists)
• Per study module (in Infotype 1746 – study module data of the study module SM)
Without the customizing settings for waiting lists, the system will only create module bookings
without waiting lists.
Note: it is recommended that you use the same booking priorities in Student Lifecycle Management
as you do in Training and Event Management. You can find the booking priorities for TEM under
the Customizing for Training and Event Management – Booking Priorities.
Automatic booking: the system books students on waiting lists when the capacity of a module or
event package is exceeded
Manual Booking: you can always book students manually on waiting lists within the module
booking dialogue
For events: waiting list booking must always be done manually
If you want to book a student on the waiting list for a module even if there are still seats available,
you have to change the booking priority for this booking adequately (see next slides for information
about booking priority).
© SAP AG
IHE102
8-47
8 .7 Wa it ing List s – Book ing Priorit y
A waiting list booking is determined as:
A module booking relationship between Student and Module (506)
With a lower booking priority (infotype 1001 of relationship 506)
Booking Priority is a range between 0-99; different ranges for different booking types
are supported:
Booking priority range for essential bookings
(e.g. 0-10)
Booking priority range for normal bookings
(e.g. 11-70)
Booking priority range for waiting list bookings (e.g. 71-99)
© SAP 2009
You can define the booking priority range, depending on the booking type, in Student Lifecycle
Management Customizing under waiting list settings.
Note: Make sure that booking priorities set for module bookings and event package bookings under
Student Lifecycle Management are synchronized with those made for event bookings under
„Training and Event Management“. When a module with event is booked, the Training and Event
Management settings apply for the event booking, while the SLCM settings for booking priority
apply for the modules.
IMG path: TEM
© SAP AG
Day-to-Day Activities
Booking
IHE102
Booking Priorities
8-48
8 .7 Wa it ing List s – Ca pa c it y a nd Se a t s
You can define the capacity of a Module / Event Package / Event:
Optimum capacity:
Normal bookings can be made
until the optimum capacity of
the object is reached
Maximum capacity:
If the optimum capacity is
reached, you can still add
essential bookings until the
maximum capacity is reached
You can also define the number of places on the waiting list for one of the objects
above:
globally in customizing
Capacity is defined as percentage of the optimum capacity of the object
On each object directly
e.g. module data: define number of waiting list places as percentage of optimum capacity
of the object
© SAP 2009
You can distinguish between capacity for available seats and waiting list capacities. The capacity for
available seats for a module, event package or event is defined as optimum and maximum capacity:
• The optimum capacity allows to book students with normal booking priority.
• The maximum capacity allows to book students with essential booking priority. These bookings
have a higher booking priority number. Please note that the waiting list functionality always
considers the optimum capacity of the object! It does not check against the maximum capacity.
The number of waiting list places defines how many students can be booked on a waiting list. It can
either be defined globally in customizing (as percentage of the optimum capacity of the object in
question) or locally at the object, e.g. module itself. This will overrule the global definition.
An IMG task is available to completely suppress any checks against module capacity during
booking: SLCM Processes in SLCM Module Booking Exclude Capacity Check at Module
Level.
© SAP AG
IHE102
8-49
8 .7 Wa it ing List s – Ca pa c it y Chec k
When a student is booked to a Module / Event Package / Event, the system checks:
is the optimum capacity reached (in case of a normal booking)
is the maximum capacity reached (in case of an essential booking)
if not
a booking is made
if yes
a waiting list booking is made
until:
optimum capacity + waiting list capacity is
equal to the number of booked places +
number of students on waiting list
it is not the waiting list capacity alone
which is checked to decide whether further
waiting list bookings are possible
© SAP 2009
The check for capacity works as described in the following example:
A module called „Training“ has an optimum capacity of 10 seats, max. capacity of 20 seats and a
waiting list capacity of 5 seats
For some of the students who are booked on the module, it is mandatory. Therefore they are booked with
essential bookings (= highest priority). Others are booked as normal bookings.
We have at the current status:
• 12 students are booked on the module, 5 of them with essential bookings
• The optimum capacity is exceeded, normal bookings are not possible any more. The maximum
capacity is not exceeded yet, essential bookings are still possible.
• Any further normal booking will be booked as waiting list bookings. Important: once a waiting list
has been started for this module, and the optimum capacity is exceeded, you cannot add further
essential bookings! They will also be added to the waiting list.
Now 3 students have canceled their bookings. This means:
9 students are booked on the SM now, the optimum capacity is no more exceeded.
Another student is going to book the module (normal bookings).
The student will be transferred to the waiting list, though the optimum capacity is not exceeded any
more. But once a waiting list has been created by the system, it is not allowed for further students to fill
up empty spaces until the waitlisted students are moved up. This is done during booking the module.
Further students try to book the module. Now the situation is as follows:
5 further students tried to book the module as normal booking. They will be booked on the waiting list
because a waiting list already exists as the optimum capacity of the module has been exceeded before.
Now 9 students are booked on the module, 5 of them with essential bookings. There are 6 students on the
waiting list.
=> Why are 6 students on the waiting list if the waiting list only has 5 places?
Because the system adds the available seats on the module until the optimum capacity + the available
waiting list places are reached and compares it to the current bookings + the current waiting list
bookings. This results in a total booking capacity of 15 (including waiting list), which is reached by 9
bookings on the module + 6 waiting list bookings. Essential bookings will always also count towards
these figures! If another student wants to book the module, it will not be allowed, nor is the student
transferred to the waiting list, because the capacity including waiting list has been exceeded.
© SAP AG
IHE102
8-50
8 .7 Wa it ing List s – M ove U p
The so-called “Move Up” process turns waiting list booking of students into normal bookings
according to the order on the waiting list either by
sorting according to booking priority and booking date and time
sorting according to individually defined rules
The Waiting list report is used to start the move up process.
Two different procedures are available:
1. Simple move up:
2. Eligibility to move up:
- the waiting list is sorted
- every student on the waiting list can
move up to a normal booking as
long as seats are available
- only students which are marked as eligible
are able to move up to a normal booking
- you have to mark a student as eligible to
move up during the booking process
Technical background:
- Customizing entry „eligibility to move
up“ is activated
- Waiting list bookings are stored with
e.g. booking priority >90, eligible
students with 90
- Customizing entry „eligibility to move
up“ is deactivated
- Waiting list bookings with e.g. priority
90 – 99 are considered to be moved up
© SAP 2009
Move up processes may take place when booked students have cancelled their bookings and seats
are freeing up. Or the process may be started at a point in time when the normal booking period is
closed and students which had to „wait“ for seats on the waiting list are moved to normal seats in
case there are some left.
To start the move up process, go to the waiting list report under Student Lifecycle Management
Student Administration Reports. There you have to access the module, event package or event for
which you have created a waiting list via the selection method.
Students are moved up from the waiting list to available seats according to the order of the waiting
list which is defined by:
• booking priority
• booking date and time
• other criteria (as implemented in a BADI)
Eligibility to move up:
You would choose this process variant if, e.g., you want to let the students turn their waiting list
bookings into normal bookings via a self service scenario, e.g.:
• A student is booked on the waiting list
• At a certain point of time, a course administrator checks the number of available seats and marks
the student as eligible to move up
• A message is sent to the student to inform him/her that he is eligible to move up
• The student enters the student self service and books the course s/he is waitlisted for (= turns the
waiting list booking into a normal booking)
Note: The rule checks during a waitlist move-up can be bypassed (e.g. for performance reasons).
The Waitlist move-up report offers checkbox to bypass VSR (for Callup Point 0003), pre-requisite,
co-requisite, and extended booking checks.
© SAP AG
IHE102
8-51
8 .7 Wa it ing List s – Eligibilit y t o M ove U p
“Eligibility to move up“ is defined by the booking priority:
eligible to move up = those students who have stored the minimum priority for
waiting list bookings in their module booking relationship
Example:
minimum priority of a waiting list booking = 90.
eligibility to move up is activated (value X).
Booking with priority 90:
Booking with priority >90:
Eligibility to move up
Normal waiting list booking
© SAP 2009
Technical Background:
• If the eligibility to move up is activated, the system uses the minimum priority for waiting list
bookings when it flags the eligibility to move up. This means:
• You defined the minimum priority of a waiting list booking as 90. You also activated the
eligibility to move up (value X). The system then interprets
– the booking priority value 90 as the eligibility to move up,
– a booking priority value over 90 as a regular waiting list booking.
Technical Background (examples):
• Waiting list bookings are stored with priority 91 or higher
• Once a waiting list booking is marked as eligible to move up, the booking priority is turned into
90 (which is defined as the minimum booking priority for waiting lists)
• The system recognizes all bookings made with booking priority 90 as waiting list bookings
which are eligible to move up.
© SAP AG
IHE102
8-52
8 . Course Re gist ra t ion – Conc lusion
You are now able to:
Use the booking functionality
Understand and use the booking priority functionality
Understand the external maintenance dialog
Make use of composite modules
Understand the cohort functionality
Use the waiting list functionality
© SAP 2009
© SAP AG
IHE102
8-53
© SAP AG
IHE102
8-54
I H E1 02 St udent Lifec yc le M anagem ent :
9 . Gra ding, Asse ssm ent s, a nd Exa m ina t ion
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009
© SAP AG
IHE102
9-1
9 . Gra ding, Asse ssm ent s a nd Ex a m ina t ion
Content:
9.1 Scales
9.2 Appraisals
9.3 Performance Indices
9.4 Assessments
9.5 Examination
© SAP 2009
© SAP AG
IHE102
9-2
9 . Gra ding, Asse ssm ent s a nd Ex a m ina t ion
After completing this unit, you will be able to:
Define and understand academic scales
Use appraisal templates and their components
Create appraisals for students in modules
© SAP 2009
© SAP AG
IHE102
9-3
9 . Gra ding, Asse ssm ent s a nd Ex a m ina t ion –
Busine ss Sce na rio
You are a member of a faculty or department, or of the academic staff
and need to evaluate students' work at the end of sessions and
determine their results.
You require information on a student's current academic results.
A student would like to look up his/her grades.
© SAP 2009
© SAP AG
IHE102
9-4
9 .1 Sc a le s – T opic Obje c t ive s
After completing this topic, you will be able to:
Understand the concept of scale definition in Student Lifecycle
Management
Understand how scales are used in Student Lifecycle Management
© SAP 2009
© SAP AG
IHE102
9-5
9 .1 Sc a le s - I nt roduc t ion t o Gra ding
Academic work that students complete during their studies is evaluated by grades and credits:
Grades
Grades express the qualitative assessment of students’ work.
Grades are defined by a grading scale (1, 2, 3 ) or additional grade symbols
(I = incomplete, W = withdrawal...).
Grades are assigned to modules using appraisals.
Grades are the basis for student academic standing at the university.
–
Calculate performance indicators, input for progression
Credits
Credits express the quantity of work a student has to do or did for a module.
Credits are earned by the student if a module has been passed.
Credits are given with a unit. The number of credits a student can earn is determined by
the module (range between min, opt, max).
Credits can be transferred to the student academic work record from externally achieved
academic work.
© SAP 2008
Grades are the outcome of the grading process during which the work of each student is evaluated.
Credits are expressed in the hours of course work in a week.
Credits are assigned at module level. A range of credits for a module allows some flexibility in
delivering the number of credits. You can distinguish between attempted credits, graded credits and
earned credits:
• Attempted credits: A student can book modules with a credit value between the minimum and the
maximum number of credits specified for the module. This reflects the attempted number of
credits.
• Graded credits: If the student is graded for the work done within the module, the number of
attempted credits is the number of graded credits. If the student does not receive a grade for some
reason, the number of graded credits is 0. Graded credits are most used for weighting a grade in
the average grade calculation.
• Earned credits: Only if a student has passed the module (depends on the grade) is the number of
attempted credits earned by the student and transferred to his/her academic record.
Credit Units:
• For internal modules (academic work) the system supports only the credit unit specified in the
IMG.
• For external transcripts, you can customize and use different credit units (for example, semester
and quarter credits). Automatic conversion between different credit types is supported. All credit
units must be defined as units of measurement with no dimensions.
© SAP AG
IHE102
9-6
9 .1 Sc a le s Conc ept
Grading scale concept in Student Lifecycle Management:
Grading scales are customizable
Customize grading scales (1-4; 1-100)
1.0 (Excellent)
Customize grade symbols for external grades (W, I, F...)
W
(Withdrawal)
Additional grade symbols are available via BADI
Grading scales can be attached to objects
Grading scales for internal qualifications, modules
Grading scales for countries, external organizations, subjects, external qualifications
Grading scales can be inherited from higher-level objects in the external ac. Structure
© SAP 2009
Scales express the format in which a grade is stored. They also contain the conversion logic for
converting from one scale to another.
SAP does not deliver any grading scales. The system works internally on a system scale which is not
intended for screen display. You therefore have to define customer scales before you can use grades.
Different scales can be used in different applications. For grading this means that: When you enter
grades for module appraisal, the system stores the grading scale to be used for the appraisal in the
appraisal structure (see next topic).
When you enter a grade for module appraisal, the scale which defines the format of the grade is
taken from the scale defined in the booking relationship or it is inherited from the Evaluation
Infotype (1710) of the module or program of study (not in use yet):
• Starting from the program of study (SC) and following to the module (SM).
• If neither has a scale in this infotype, the system uses the default scale for modules defined in
Customizing for Student Lifecycle Management under: Student Lifecycle Management Master
Data Academic Scales Define Standard Scales (variable CAMPU SCLSM = Universal
Module Scale (SM)).
Additional grade symbols for grading can be controlled via BADI in the appraisal dialog: IMG for
Student Lifecycle Management under: Student Lifecycle Management Master Data Academic
Scales Business Add-Ins (BAdIs) -> BAdI: Additional Grade Symbols.
© SAP AG
IHE102
9-7
9 .1 Gra ding Sc a le s – Conve rsion of Gra de s t o
ot he r Sca le s
Automatic conversion of scales
For automatic conversion of grades within academic work records
Changes of actual grading scale is supported
External grades and grade averages are automatically converted into the internal grading
scale
1.0
(Excellent)
Is equivalent to
A
(very good)
Is equivalent to
100
(outstanding)
Basically you need at least three scales:
Scales representing grades value (00.00 – 20.00) for the grade point average
Scales representing real discrete grades (A,B,C...F A-,B+,...)
Passed / failed grades
© SAP 2009
Scales contain the conversion logic for converting from one scale to another. The conversion logic is
maintained within the definition of the scale.
The storage of the grade on the universal reference scale allows you to convert grades to any other
grading scale to another scale.
This allows you, for example, to maintain different grading scales within one system (for different
programs of study, different organizations, etc.). Furthermore, you are able to support grading scale
changes over the time without loosing the grades for existing work in the system.
All kinds of external grades and grade averages (e.g. from other universities, schools, tests, etc.) can
automatically be converted according to internal grading scales.
© SAP AG
IHE102
9-8
9 .1 Sc a le s - T e rm s & De finit ions
Format of Grades
Grading Scale
Grade Symbols
Letters
(W, I, F…)
Scale Types
Quality scale
Linear quantity scale
Partially linear quantity scale
Quantity scale (with conversion via a function
module)
With definition of:
System scale values
Base value
© SAP 2009
In Student Lifecycle Management you can set up the following grading scale types:
• Quality scale: Examples of this type of scale include a 4 point scale (0,1, 2, 3, 4), alpha scales (A,
B, C, D, F or A+, A, A-, B+, …). When you create a quality scale, you must enter a scale ID and
description, the scale type quality scale, the base value (see below) and a sort order.
• Linear quantity scale: A numeric 0 to 100 point scale is an example of this scale type. When you
create a quantity scale, you must enter a scale ID and description, the scale type linear quantity,
the base value, highest and lowest values of the scale, and the scale step interval (e.g. 1).
• Partially linear quantity scale: Example - 0 to 100 with intervals that refer to sections of the
system scale.
• Quantity scale (with conversion via a function module): A function module is an algorithm which
converts the specified scale to the system scale.
Notes:
• External grade symbols are customizable
• Internal grade symbols are defined via BADI
© SAP AG
IHE102
9-9
9 .1 Sc a le s: Corre la t ions Am ong Sc a le s
Scale 1
(%; linear;
quantitative)
Base value
54.5
Customer
defined
(0/4 pt; qualitative)
100
55,000.00
System
SystemScale
Scale
Scale 2
0
0
100,000.00
Base value
D-
Customer
defined
E
A+
Lowest “passed” value
© SAP 2009
Student Lifecycle Management is built and delivered with a system scale with a value range from
0.00 to 100,000.00, the lowest value being 0.00 and the highest 100,000.00. When you set up your
own institutional scales in the system, you define a mapping between these scales and the system
scale. This information is used to convert values from one scale to another. For example, once this
mapping between scales is defined, the system can automatically convert the grades a student
received from an external institution to their equivalents in your institution’s academic scale.
This slide shows how different scales are correlated after defining all relevant parameters (see next
slide):
• Lowest “passed” value on system scale
• Base value
• Grading scale values (linear, quantitative, etc.)
• Value description
© SAP AG
IHE102
9-10
9 .1 Ex a mple s for Sc a le s
Scale
Scale Type
Base Value
A-F
(Standard)
Quality Scale
0,00
Lowest
Value
Highest
Value
Linear quantity 55,000.00
scale
Value
Scale
Value
Standard
Value
A
4.00
B
Highest ->
Lowest
Highest ->
Lowest
GPA Scale Linear quantity 50,000.00
(4.0)
scale
ACT Scale
Interval
1.000
Passed
5.0000
0.0001
Highest ->
Lowest
36.0000
1.0000
Highest ->
Lowest
Lower
Limit
Upper
Limit
90,000.00
85,000.00
100000.00
3.00
80,000.00
75,000.00
84999.99
C
2.00
70,000.00
65,000.00
74999.99
D
1.00
60,000.00
55,000.00
64999.99
F
0.00
50,000.00
X
54999.99
© SAP 2009
The base value represents the lowest grade that a module or qualification is considered as
successfully completed. It must be set in a way that all scales used for internal and external grades
can be converted correctly to the standard scale. Usually this value is not very critical. A value of
50.000 to 60.000 is applicable in most cases. To be sure one should set up all required grading scales
and check whether the value works.
Note: In the following example the value is always set to 55000.
© SAP AG
IHE102
9-11
9 .1 Gra ding Sca le s – Gra ding w it h Pass/Fa il M ode
Institutions can define a pass/fail mode for booking a course and use a different
scale than the standard scale. They can define this generally in the IMG, at the
module level or on the level of organizational units inherited to the assigned
modules.
When you are starting the grading process, all students booked on a
module will get a result within the module appraisal:
Normal bookings:
Pass/Fail bookings:
students will get a grade and
credits according to the grading
scale of the module
you can only enter pass or fail for
those students booked with pass /
fail mode.
© SAP 2009
Student Lifecycle Management allows you to define a scale which only consists of two possible
values: pass and fail.
You need to define in the Customizing settings if the pass/fail result will transfer credits (in case it is
a fail) and will be counted toward the GPA or other index calculations.
© SAP AG
IHE102
9-12
9 .1 Gra ding Sca le s – Pa ss/Fa il Sc a le for M odule s
Example for pass/fail scales:
Students who are attending a module as auditors are not getting a grade, but they
may get a note that they passed or failed and credits for the attended course.
The pass/fail scale ”mode“ can be selected at module booking
Students can pursue courses with a regular grading system or select a pass/fail grading
system
You can maintain ”normal“ grading scales and a pass/fail scale at the module or on higher
entities
Students booked with the pass/fail scale will not receive a grade but a pass or a fail for the
module
© SAP 2009
During module booking, you can decide whether a student should be graded according to the
standard grading scale used for this module (= default) or if the student should only get a pass or fail
for the module. Depending to the settings made in Customizing, this can include the transfer of
credits or not.
When the students booked on the module are graded, students with a booking on pass/fail scale can
only receive a pass or fail, while the others are graded according to the standard grading scale (e.g.
4, 3, 2 or 1).
In order to use pass/fail modes, you have to maintain pass/fail scales in Customizing (Enter a
grading scale which has only two entries: pass and fail (see Customizing of Student Lifecycle
Management: Student Lifecycle Management Master Data → Academic Scales. You can use a
quality scale for this.)
Then you have to maintain the pass/fail scale for a module – in addition to the standard grading
scale! Alternatively, you can maintain it on a higher level, such as program of study or
organizational unit. Then, the module will inherit the pass/fail scale.
© SAP AG
IHE102
9-13
9 .1 Sc a le s - T opic Sum m a ry
You are now able to:
Understand the concept of scale definition in Student Lifecycle
Management
Understand how scales are used in Student Lifecycle Management
© SAP 2009
© SAP AG
IHE102
9-14
9 .2 Appra isa ls - T opic Obje c t ive s
After completing this topic, you will be able to:
Understand how appraisals are used to maintain information about the
academic performance of a student
Create an appraisal for a student and format its layout
© SAP 2009
© SAP AG
IHE102
9-15
9 .2 Appra isa ls – Ove rvie w
A student’s academic performance can be measured by grades and credits. The
starting point for grading is the module.
An appraisal template is the hierarchical structure in which the system stores all the
grades of the student for a specific module booking.
Module ABC
Final
The appraisal can collect grades for every academic
work connected to the module, such as:
exams (= assessments)
Class
Period 1
individual work for the module (= CI)
Period 2
attendance of the module or events
academic work performed for the module or related
events
Period 3
Final Exam
© SAP 2009
The appraisal can be structured in such a way that it collects grades and credits which the student
receives in context of the module. The origin of the grade can also come from events or other kind
of academic work which are related to the module as objects, such as exams (which are represented
by assessments) or individual work or events belonging to the module.
A final grade as overall result for the module can be calculated taking into account all results
received for parts of the module. All this information is stored and calculated within an appraisal.
As a student may attend a module several times, you will have an appraisal for each module booking
of a student.
Technically speaking, an appraisal is related to a module through the additional data of relationship
506 “is completed/completes”.
Each module booking generates a unique booking ID (HRPAD506-VARID). This booking ID is
used to relate each module booking to its corresponding appraisal.
© SAP AG
IHE102
9-16
9 .2 Appra isa ls – T e m pla t e Components
Appraisal Template
Final
Appraisal Type
Class ( 20 )
Project 1 (30)
Additional
Appraisal Elements
Project 2 (30)
Participation (40)
Exams ( 80 )
Exam 1 (30)
Exam 2 (30)
Exam 3 ( 40 )
Exam
3 (40)
Weighting
Grade
Date
Elem.1
Grade
40
A
17.06.08
Content
B
© SAP 2009
Grading: Describes the process used to evaluate student performance in a booked module. Students
getting grades for achievements for their work in modules (e. g. A+ or 1,0).
Appraisal: Store grades, credits and further detailed information about the evaluation results of a
student’s work in a module. Appraisals can be attached to modules (SM) but not to business events
(E). You can create as many appraisals for a module as you need. You can store credits only for the
top appraisal.
Appraisal template: You can arrange the appraisal types hierarchically in appraisal templates. You
can define the appraisal template to be used by default or select a different template in the
Evaluation Infotype (1710) of each module (templates are not inherited).
Appraisal types: You use appraisal types to categorize appraisals. By organizing appraisal types
hierarchically you can create a grading tree.
Appraisal element: Appraisal elements enable you to evaluate additional components like class
attendance for informative purposes. *
Weighting: You can define a weighting factor for each appraisal type in an appraisal template except
for the top appraisal. The weighting factor is used to calculate the aggregation result. The weighting
factor for the top appraisal is always set to its initial value.
Key figure: You can also define a key figure for each appraisal type in an appraisal template. The
key figure is used to define the performance index and scale which are used to calculate the
aggregation result.
© SAP AG
IHE102
9-17
9 .2 Appra isa ls – Diffe rent Appra isa l T ype s
You can navigate within the structure through each of the defined appraisal types and enter the
results per student in the tables:
Final
Name
Student No.
John Smith
1000010001
Final
78
4
Jose Perez
1000010002
Final
90
4
Jim Brown
1000020045
Final
56
3
Appraisal type
Grade
Credits
Class (20)
Period 1 (30)
Period 2 (30)
Period 3 (40)
Name
Student No.
Appraisal type
Grade
Weighting
John Smith
1000010001
Period 3
91
40
Jose Perez
1000010002
Period 3
88
40
Jim Brown
1000020045
Period 3
50
40
Final Exam (80)
© SAP 2009
You can maintain credits only for the top appraisal. For all other dependent appraisal types, you can
enter grades and a weighting factor. The overall result, kept on the top appraisal, is calculated from
all grades and weighting factors maintained for the dependent appraisal types.
To maintain grades for exams, individual work, etc., you have to customize an appraisal type for
each type of grade. Then you can enter the grade within the grading dialog. You can find the
customizing steps for appraisals in the IMG under Student Lifecycle Management → Student
Lifecycle Management Processes → Appraisal
Prerequisite is always that the student is booked to the module!
© SAP AG
IHE102
9-18
9 .2 Appra isa ls – Ca lc ula t ion
The result (grade) of each appraisal level is calculated from the results
of its lower-level appraisals and their weighting factors.
An appraiser enters only the grades of the appraisals he is responsible
for. The final appraisal is automatically calculated from the lower-level
appraisals.
Final
Class (20)
Calculation Attributes:
Calculation Depth
With subnodes: All the lower-level appraisals of the selected appraisal are
recalculated automatically
W/o subnodes: Only the result of the selected appraisal is recalculated
Automatic Calculation
Switched On: If a grade is entered at any level, the results of the respective
higher levels are automatically recalculated
Period 1 (30)
Period 2 (30)
Period 3 (40)
Final Exam (80)
Switched Off: If a grade is entered at any level, the results of the respective
higher levels are not recalculated
Lock and Unlock Calculation
Calculation can be locked and unlocked for one or more students.
© SAP 2009
The system can automatically calculate the “class” appraisal grade from the grades for “period”
appraisals 1 to 3. The “final” appraisal grade is calculated from the “class” and “final exam”
appraisals.
The weighting factor, grade and scale of the lower-level appraisal are inputs for calculation. The
calculation result is used in the higher-level appraisal.
The appraiser can enter a weighting, grade and scale for the appraisal. The weighting factor defined
in the appraisal template is used as the default value. This weighting factor can be overwritten.
Different cases of calculation exist:
• Calculate grade, one appraisal level, one student: Select an appraisal level and a student. Set the
calculation depth “w/o subnodes”, and run the calculation function.
• Calculate grades, one appraisal level, n students: Select an appraisal level and several students.
Set the calculation depth “w/o subnodes”, and run the calculation function.
• Calculate grades, one appraisal level and all sublevels, one student : Select an appraisal level and
a student. Set the calculation depth “with subnodes”. The system recalculates the grades for the
appraisal level and all of its sublevels for the selected student.
• Calculate grades, one appraisal level and all sublevels, n students : Select an appraisal level and
several students. Set the calculation depth “with subnodes”. The system recalculates the grades
for the appraisal level and all of its sublevels for the selected students.
© SAP AG
IHE102
9-19
9 .2 Appra isa ls – K e y Figure s
The Student Lifecycle Management key figures tool enables you to calculate a final
grade for the appraisal:
All grades and credits from lower-level appraisals and the weighting factor are taken into
account to calculate a final grade
You can calculate grades using key figures on each appraisal element
Key Figures are used to calculate academic performance of students in terms of
Grade averages
Weighted grade averages
Total credits
Number of courses
The input for academic performance indices are booked modules, grades and
credits and other academic work of students
© SAP 2009
When you create an appraisal for modules, you use key figures to calculate the grades within an
appraisal template.
You can assign a key figure to each appraisal element you insert in the appraisal template. You can
also define the default key figure the system should use for an appraisal element which has not been
assigned a key figure.
• The input to the key figures are booked modules, grades and credits. It can be selected with the
help of parameters and filters.
• The output of a key figure is a grade on a defined grading scale.
Performance indices are special key figures which are based on module bookings. You can therefore
use a performance index as a reference when you define a key figure.
GPA calculation rules are delivered that you can use to include or exclude transfer credits or grades.
• BAdI definition HRPIQ00SI2_P and BAdI implementation HRPIQ00_FIL_GPATYP
• Sub-requirement filter SAP8
© SAP AG
IHE102
9-20
9 .2 Appra isa ls – Book ing St a t us
The booking status is a system status. It can be:
01 - booked, 02 - completed with success, 03 - completed unsuccessfully,
04 – booking cancelled, 05 -preselected, 06 – prebooked, 8 – will be continued
Grade/ Grade
symbol
Std. Value
Compl
.
Booking
Status
Booking status description
Appraisal
status
A
=
92.424,24
01
Booked (initial status when SM has
been booked)
pending
A
=
92.424,24
02
Completed with success
completed
F = failed
=
39.393,94
01
Booked (initial status when SM has
been booked)
pending
03
Completed unsuccessfully
Completed
08
will be continued
completed
01
Booked (initial status when SM has
been booked)
In process
04
Booking Cancelled
completed
F = failed
X
=
39.393,94
X
I = incomplete
IP = in
process
W=
Withdrawal
X
X
© SAP 2009
The booking status can be combined with an appraisal status and appraisal remarks to extend the
status information (e.g. appraisal pending, appraisal completed).
The booking status reflect the status of booking. Options “prebooked” and “selected” (05 – 07) are
only used within booking. “Booked” modules (01) will be considered in grading as well as
“cancelled” modules (04) with a “cancellation reason” marked as relevant for grading.
Grading itself should set the following status:
• 02 – Completed with Success: This status should reflect the successful completion of a module.
This status is not allowed in combination with a grade below the lowest passing value.
• 03 - Completed Unsuccessfully: This status should be used if a student fails a module. It is not
allowed in combination with a grade above the lowest passing value.
• 08 – Will be Continued: For module bookings which will be completed in a following session.
For cancelled modules, which are graded with a “W”, the status should stay “cancelled”. To keep
track of the cancellation process (e. g. for fee recalculations) the status should not be changed.
Note: Only one combination of booking status and grade symbol is usually not sufficient. It is part
of the implementation concept to determine the necessary status in combination with grade symbols.
BADI HRPIQ00_GRADING: To update the booking status and other data on the booking
relationship a BADI can be used. It is only available in the grading interface and is not called in the
RFC’s. See IMG: Student Lifecycle Management → Student Lifecycle Management Processes →
Appraisal → Customer Enhancements for Appraisal → Control Credit Assignment
© SAP AG
IHE102
9-21
9 .2 Appra isa ls – Re pe t it ion
Lower-level appraisals can be repeated:
If a student has failed a lower-level appraisal and is given a chance to repeat it, a
repetition of the failed lower-level appraisal can be created.
An appraisal can be repeated more than once. The appraiser can define a
weighting factor for each repetition. For example, the weighting factor of an exam
appraisal is 30 and the exam is repeated once. If the average of the original and
repeated appraisal should be taken into account, the appraiser can define a
weighting factor of 15 for both the original and repeated appraisal. If only the
repeated appraisal should be taken into account, the appraiser can define a
weighting factor of 0 and 30 for the original and repeated appraisal respectively.
© SAP 2009
There is no limit to the number of repetitions in the technical view.
The top appraisal refers to the appraisal for the root node of the appraisal template tree; this is the
final result of a grading run.
The part appraisal refers to the appraisal for the non-root node of the appraisal template tree.
Performance indexes which represent repeated courses are delivered. This allows the easy inclusion
or exclusion of repeated courses in GPA calculations. A particular performance index is included in
this functionality, which tracks the total number of repeated courses.
• BAdI definition HRPIQ00SI2_P and BAdI implementation HRPIQ00_FIL_CG_REP
• The relevant sub-requirement filter is SAP3.
Archiving:
Lower-level appraisals can be archived and deleted from the system. The top appraisal cannot be
deleted.
The archived lower-level appraisals of a module can be displayed in the grading dialog just as they
were before archiving, but they cannot be edited.
© SAP AG
IHE102
9-22
9 .2 Appra isa ls – Pe rform Gra ding Proc e ss
Steps for Grading
Define an appraisal template for modules per default or per module
Preparatory steps for Grading:
Use the object manager to select an appraisal using modules, event packages or events
Select the academic year and session
Filter objects by event package or module booking status
Credits are
The result is a spreadsheet showing the students who match the selection
maintained for
Top-appraisal
criteria
ONLY
Name
Student No.
John Smith
+
Name
John Smith
=
Student No.
1000010001
Jose Perez
1000010002
Arnold Braun 1000020045
Appraisal Type
Grade
Credits
1000010001
Final
78
4
Jose Perez
1000010002
Arnold Braun 1000020045
Final
Final
90
56
4
3
Appraisal
type
Period 3
Grade
Weighting
91
40
Period 3
Period 3
88
50
40
40
Weighting for
lower-level
appraisal
© SAP 2009
To create module appraisals, go to: SAP Menu -> Student Lifecycle Management
Examination Module Appraisal
Teaching and
You can create an appraisal for a student only if the student is booked for the module you are
appraising; relationship 506 “completes” must exist between the module (SM) and the student (ST).
You must also assign an appraisal template to the module, either directly (in the Evaluation record
of the module) or indirectly (by defining it in Customizing).
Select the students you want to assess by entering the module, academic year and academic session.
The event package and booking status are optional parameters for student selection.
The appraiser, who can be an internal person (P) or a student (ST), is defined by relationship 518 “is
appraised by/appraises” between the module (SM) and appraiser (P or ST).
Note:
• You can add relationships for objects using the object modeler.
• You can maintain credits only for the top appraisal.
• You can overwrite the weighting factor of lower-level appraisals.
© SAP AG
IHE102
9-23
9 .2 Appra isa ls – Cust om izing
Steps to Customize Appraisals in Student Lifecycle Management:
Create Appraisal Types
Create Appraisal Elements
Assign Appraisal Elements to Appraisal Types
Define Appraisal Templates
Define Default Key Figure
Build Appraisal Template
Define Default Appraisal Template
Define Default Appraisal Element
Create Appraisal Statuses
Define Appraisal Remarks
© SAP 2009
IMG Path: Student Lifecycle Management
Appraisal.
Processes in Student Lifecycle Management
Create Appraisal Types: You use appraisal types to categorize appraisals. By organizing appraisal
types hierarchically, you create a grading tree.
Create Appraisal Elements and Assign Appraisal Elements to Appraisal Types: Appraisal elements
allow to evaluate individual aspects of academic work (content and style), and components e.g. class
attendance. You can create appraisal elements and assign appraisal elements to appraisal types.
Define Appraisal Templates and Build Appraisal Template: You can arrange the appraisal types
hierarchically in appraisal templates. You can build an appraisal template by specifying the appraisal
types which are used in the appraisal.
Define Default Key Figure: You can define a default key figure for the appraisal template.
Define Default Appraisal Template: You can define the appraisal template to be used by default or
select a different template for each module in the Evaluation record (Infotype 1710) of the module
(templates are not inherited).
Define Default Appraisal Element: You can define a default element for an appraisal.
Create Appraisal Statuses: You can create different appraisal statuses to monitor the grading
process.
Define Appraisal Remarks: You define the appraisal remarks which control the subsequent
activities.
© SAP AG
IHE102
9-24
9 .2 Appra isa ls – Se lf Se rvic e for Gra de Change
Re que st
Grade Change - Request
Students request a change to the recorded grade for a course.
The system contains a workflow template that handles the routing of the request to the
appropriate staff members.
Web Dynpro Application: PIQ_GRADECHANGE
Steps to submit request:
1
2
Select
Academic
Work
3
Enter
Requested
Grade
4
Review and
Submit
Complete
© SAP 2009
Grade Change – Approval Workflow Details
Workflow: PIQ_GCR (29800014)
Agents: Responsible Instructor, Program Dept Head, Registrar
Processing Steps:
• Approve Gade Change
• Mail, Grade Change Denied
• Mail, Grade Change Approve
• Execute the Grade Change Request
• Check if Error Table is empty
• Resolve Errors/Inconsistencies
• Set Approved_Denied
• Approved grade different to requested grade
© SAP AG
IHE102
9-25
9 .2 Appra isa ls – Appra isa l Se lf Se rvice
Appraisal Self Service
The Appraisal Self-Service is a Web Dynpro application which enables appraisers
to record results (e.g. Exam marks) for their students. The relevant students are
selected via a user-defined query and the results are entered into the Appraisal
Worksheet.
Pre-requisites for performing Appraisal Self-Service:
Each appraiser must have a Portal User
The Portal User should be assigned to the role “University Instructor“
© SAP 2009
Web Dynpro application ‘PIQUIBB_APPR_SELF_SERVICE_APP
Prior to using the Self-Service function there are four steps that are required to set up the necessary
master data and one optional step for implementing applicable BADI‘s:
• Assign Appraisers to Appraisal Objects: This assignment permits the appraiser to record results
for the students registered to the relevant objects (scheduled assessment, event, event package,
individual work, module).
• Assign Appraisal Types to Appraisal Objects. Appraisal Types are assigned to the Objects:
Assessment (CE) and Event Type (D). The Event (E) inherits the Appraisal Type assigned to the
Event Type.
• Create and Assign Authorization Profiles in the IMG for Student Lifecycle Management>Student
Lifecycle Management Processes>Appraisal>Authorizations
• Assign Scales to Appraisal Objects
• Implement BADIs (Optional) which are available in IMG: Student Lifecycle
Management>Student Lifecycle Management Processes>Appraisal>Define Add-Ins for
Appraisal Self-Service
– HRPIQ00AGR_US_APPSER: Determine Appraiser from User
– HRPIQ00AGR_COMAPPOBJ: Assign Appraisal Type to Appraiser
– HRPIQ00AGR_PERIOD: Determine Academic Session for Appraiser
– HRPIQ00AGR_APPOB: Additional Information for Academic Offerings
© SAP AG
IHE102
9-26
9 .2 Appra isa ls – T opic Sum ma ry
You are now able to:
Understand how appraisals are used to maintain information on the
academic performance of a student
Create an appraisal for a student and format its layout
© SAP 2009
© SAP AG
IHE102
9-27
9 .3 Pe rforma nc e Inde xe s – T opic Objec t ive s
After completing this topic, you will be able to:
Describe which tools are used to set up the calculations for average
grades and other performance indicators
Describe the concept of performance indicators
Understand how to set up performance indices
Differentiate between performance indicators and performance indices
Understand how to set up performance indicators
© SAP 2009
© SAP AG
IHE102
9-28
9 .3 Pe rforma nc e Inde xe s – Ove rvie w
The academic performance index tool enables you to calculate indices which are
used to measure the academic performance of students
You can use the academic performance index tool to calculate averages, weighted
averages, credit totals, or the number of modules a student has booked.
Input parameters for academic performance indexes are booked modules and the
academic work of students.
An academic performance index consists of the following elements:
Calculation method: Calculation algorithm for the academic performance index
Filters: Filters restrict the module bookings used in the calculation
Parameters: Parameters control the filters
Unit or scale for the result
Unit or scale in which the performance index is calculated
Unit or scale in which the resulting performance index is output
© SAP 2009
Performance Indexes can relate to parameters such as session, all programs, specific program.
The quantity of input data (selected module bookings and appraisals) which an application transfers
to the calculation tool for academic performance indexes can be controlled by filters. Filters
themselves are controlled by parameters which are transferred by the application and customizing.
The data the system selects based on given filters and parameters is the input for performance index
calculation.
Example:
• An application like progression transfers a set of module bookings to a calculation point.
• The system filters this set of module bookings. Each filter can be controlled by means of
parameters. The filtered bookings are the calculation basis, e.g. the bookings for program type
undergraduate and progression category academic standing with check-to date 1.1.xxxx.
• The remaining set of module bookings is transferred to the calculation.
Filters restrict the input quantity (number of module bookings) for the calculation based on given
filter criteria. Filter criteria are parameters which you define in Customizing or which the
application transfers to the academic performance index. The progression application can filter all
module bookings which are subject to the defined progression run (for example, only undergraduate
modules) and provide this filtered list of values as input to the academic performance index.
Parameters can either be transferred by the application or defined in customizing.
The calculation method is based on the filtered values which serve as the input for the calculation
tool. Examples are:
• Sum of the input values (for example, total number of credits)
• Weighted average (for example, GPA)
• Number of booked modules
Unit or scale for the result: Depending on the input values and the calculation algorithm, you can
define the unit or scale in which the result output is delivered, such as unit “credits“ or scale “1-4“.
© SAP AG
IHE102
9-29
9 .3 Pe rforma nc e Inde xe s – Ca lcula t ion Point s
To activate an academic performance index for an application, you have to attach the
academic performance index to a calculation point
Calculation points:
A calculation point defines the point within the respective Student Lifecycle Management
application at which the assigned academic performance index is calculated
You can assign one or more academic performance indexes to a calculation point
Application
Calculation Point
Performance Index 1
Performance Index 2
© SAP 2009
An academic performance index can be used in an application only if it is attached to a calculation
point.
You can assign one or more academic performance indices to a calculation point (IMG → Student
Lifecycle Management Master Data → Academic Performance Index → Assign Academic
Performance Indices to Calculation Points).
You can either use existing calculation points or define your own: SAP delivers set calculation
points in the standard system. You can find the calculation points in the IMG for Student Lifecycle
Management Master Data → Academic Performance Index → Display Calculation Points.
You can define new calculation points for your own applications. In this case, you have to create the
calculation point and implement it in the user-defined applications which are not part of the Student
Lifecycle Management standard system. Before you can calculate the academic performance index
for user-defined calculation points, you must enter them in the calculation points table (IMG →
Student Lifecycle Management Master Data → Academic Performance Index → Define Calculation
Points).
Example:
• The progression application contains a separate calculation point for each progression category.
You can therefore calculate a specific set of academic performance indices for each progression
category. These performance indices can then be used in VSR rule checks.
• With EHP 4, the option to store performance indexes is introduced. The new calculation point
SI01 is available for this. The post processing framework is used to realize the scenario.
© SAP AG
IHE102
9-30
9 .1 – 9 .3 Sc a le s, Pe rforma nc e Inde xe s and
Appra isa ls – T opic Sum ma rie s
You are now able to:
Describe which tools are used to set up the calculations for average
grades and other performance indicators
Describe the concept of performance indicators
Understand how to set up performance indicators
Differentiate between performance indicators and performance indexes
Understand how to set up performance indexes
Define and understand academic scales
Use appraisal templates and their components
Create appraisals
© SAP 2009
© SAP AG
IHE102
9-31
9 .4 Asse ssm ent s: T opic Obje c t ive s
After completing this topic, you will be able to:
Understand the concept of assessments and assessment processes in
Student Lifecycle Management
Know how to set up and schedule assessments
Explain how you can use assessment processes
Know how to register students to assessment processes
Know how to use and change the assessment process status
Explain how audits can be embedded into an assessment process
© SAP 2009
© SAP AG
IHE102
9-32
9 .4 Asse ssm ent s: Busine ss Sce na rio
Business Scenario:
You set up the academic structure and plan assessments
for those modules where an exam is offered
You are responsible to maintain the system set up for
graduation and stage completion
You have to schedule exams or maintain registration
deadlines for graduation and stage completion
You register students for exams, start a stage completion
process or register students for graduation
© SAP 2009
In Student Lifecycle Management, this scenario is supported by the concept of assessments to:
• Plan and schedule assessments
• Register students on assessments
• Grade completed assessments
• Define a final status of the assessment process
© SAP AG
IHE102
9-33
9 .4 Asse ssm ent s – Ove rvie w (1 )
Assessments are used for different processes in Student Lifecycle Management:
Admissions to a program
Examinations
You can use an
assessment process to
manage admissions to a
program.
A module booking can
relate to an assessment
which is representing the
module exam.
Stage completion
Graduation
An assessment for
a program stage is
used for the stage
completion
process.
An assessment for
a program is used
for the Graduation
process.
© SAP 2009
Assessments and assessment processes related to them are used in different ways and business
processes:
• Assessments are used as „exams“ or module completion assessments: In this case, assessments
are created and attached to the respective module. Students booking the module can register for
the module assessment. This is an explicit step and must be done either during module booking
or via a student self-service.
• An assessment process is used for the graduation process: An assessment attached to the program
of study is the starting point for registration to graduation. The assessment process is opened
automatically when a student is registered for graduation.
When the university requires a stage audit after each stage within a program of study, the stage
completion process is started by opening an assessment process. This can be done automatically as
follow-up activity after re-registration (because these students are all candidates for the stage
completion process of this registration period) or manually.
If a student applies for admissions to a program, an assessment process is opened automatically by
the system in case you want to use assessment processes for admission. The admission process is
administered through the assessment process and admission checks are done through an audit
embedded in the assessment process.
© SAP AG
IHE102
9-34
9 .4 Asse ssm ent s – Ove rvie w (2 )
Assessments within the academic structure:
Assessment (CE)
“Admission”
Example: Admission through assessment process
Assessment (CE)
“Stage 1”
Program of Study
“Law - 3 Stages”
Assessment (CE)
“Stage 2”
Example: Stage
completion assessments +
assessment for graduation
Assessment (CE)
“Stage n”
Assessment (CE)
“Program Completion”
Module (SM)
Assessment
(CE)
Example: Module exam
© SAP 2009
When you set up the academic structure, you plan assessments everywhere where students have to
go through an assessment process to complete a program or a stage of a program, or where students
have to take exams.
• Assessments are reflected by a new object type „CE“ (Assessment).
• They can be linked to modules (SM) or programs of study (SC) using relationship 548 – “is
assessment for”:
– Attach CE to programs of study for admission process = attach one assessment to program of
study and flag program for “use assessment processes” (flag on infotype “program data”)
– Attach CE to programs of study for graduation procedures = attach one assessment to
program of study for program completion
– Attach CE to stages of a program (= parameter on the relationship to programs) to support the
stage completion process
– Attach CE to a module for examination of this module
To create an assessment for a module (similar for program), you have to start the Edit Assessment
transaction (PIQEVALM) under Student Lifecycle Management → Teaching and Examination →
Academic Records → Edit Assessments. Choose the module by means of the object manager, or
enter or search the module name. Choose Create Assessment, edit the attributes and save.
© SAP AG
IHE102
9-35
9 .4 Asse ssm ent s – Ove rvie w (3 )
Attributes for the assessment:
Assessment “Law – Stage 1”
Repetition Type
Define how often an assessment can be repeated by students.
Requirement Catalogue
Assessments are assigned to a requirement catalog and an audit
type if an audit is to be linked to the assessment process.
Audit Type
In case an audit should be linked to the assessment process, e.g.
stage audit or degree audit
Assessment Category
Define the relevance of an assessment. Example: Placement test,
Midterm exam, Final exam
Exam Plan
Define further organizational details for the exam which may be
checked by rules
Example: Single-student exam, Multiple-student exam (mass
exam), Group exam (4 students per group)
Assessment (CE)
“Stage 1”
Offering
pattern
“Every summer
semester”
Sessions of
offering
Summer 2006,
summer 2007,
summer 2008,
Audit type
Stage completion
Stage
Stage 1
Requirement
catalog
Exam regulations
for Law
Repetition
type
“1 repetition
allowed”
Relationship to CG, D, SC, SM : relate
assessment to content of these objects
(544 “has assessment coverage”)
© SAP 2009
Overview of assessment attributes:
• Session of offering: academic year and academic session (sessions of offering during which
assessment can be scheduled).
• Requirement Catalog: Refers to requirement catalogs used for audits. You can link audits to the
assessment process for checks and evaluations.
• Audit Type: necessary attribute when an audit is linked to the assessment, e.g. for the stage
completion process (“Stage Progression”) or the program completion process (“graduation”).
– If the audit type is “stage completion”, the number of stage within the program for which the
assessment has been created must be defined.
• Assessment Category: an informative detail about the assessment, depends for which process the
assessment is used
• Repetition Type: define how often the assessment can be repeated by a student. This must be
checked within a BAdI when registering the student on an assessment.
• Scale ID and Appraisal Type: used for grading of the assessment; the same concept as for module
grading is used (“appraisals”)
• Exam Plan: You can define specific details if the assessment is used as examination.
• In order to define the content for the assessment, you can create a relationship “has assessment
coverage” from the assessment to an object type in the academic structure which represents the
“content” of the assessment. Please note that this is only information and not evaluated in
processes. Example: One 2-hour exam is scheduled which covers the content of a specialization
which students can choose within their program of study.
© SAP AG
IHE102
9-36
9 .4 Asse ssm ent s – Ove rvie w (4 )
Assessment Scheduling
Once you have created assessments within the academic structure, you have to
offer them in order to register students on them. You can also schedule an
assessment with date and time:
Assessment
1) Session of offering
uses
Infotype 1739
of CE
Scheduled Assessment
2) Date
Time
Location
….
Academic Calendar
Table Entry
© SAP 2009
Assessments can be offered as scheduled assessment: it can either represent a concrete examination
(event), or it is the offering of stage or program completions where students can register for. In this
case, the scheduled assessment is only used to determine and check registration and withdrawal
deadlines for the students.
Scheduling of assessments can be compared to scheduling of events: the assessment (CE) is the
permanent object, from which a scheduled assessment is created. Before an assessment can be
scheduled, the session(s) of offering must be maintained – similar to the session of offering at
module level. In difference to the event scheduling process (the scheduled event is another object
(E), the scheduled assessment is not reflected by a new object, but stored in an application table.
Offering of assessments: Assessments (either scheduled or not) can be offered in different sessions
or in the same session as modules are offered or students are registered for. An academic session can
comprise one or more assessment periods: Example:
• One at the end of the lecture period (regular examination period),
• One (for repeated exams) before the start of the next academic session
• Note: Assessment sessions can coincide with lecture periods (= session where modules are
offered). If this is the case, separate assessment periods do not have to be defined.
You can create separate assessment periods, e.g. examination periods as time limits in the academic
calendar. Then, the assessment can be linked to an academic calendar using relationship 510 between
CA – CE to find an appropriate time limit.
To schedule an assessment, enter the Edit Assessment transaction, select an assessment, and create a
new scheduled assessment. Now you can choose Generate Scheduled Assessments. Then you have
to define the attributes for generation.
© SAP AG
IHE102
9-37
9 .4 Asse ssm ent Proc e sse s – Ove rvie w
Registration for an assessment takes place in an “assessment
process”. An assessment process is always linked to one student and
one assessment, but can also refer to a specific scheduled assessment.
The assessment process carries the student through various steps until the completion
of the assessment or the cancellation of the process.
Assessment
Session of Offering
Assessment
Process
Scheduled Assessment
You can create repetition attempts and monitor the number of attempts for one
student on an assessment (attribute: Attempt number)
© SAP 2009
When a student registers for an assessment or scheduled assessment, the assessment process is
started. In Student Lifecycle Management, this is called open an assessment process.
Assessment processes reflect the complete process of performing examinations, completion of a
program of study, or completion of a stage within a program of study. The steps (status) of the
process are customizable and reflect registration to the process, checking of admission requirements,
completion of the needed academic work and finally checking the completion requirements and
assigning a “result”.
For each student – assessment combination, an own assessment process is opened. The status of an
assessment process for an individual student can be accessed through the student file.
All registrations for assessment processes for all students are stored within an application table. For
each assessment process the assessment (or the scheduled assessment) is stored.
An attempt number is stored for each assessment process registration. It represents the number of
times the student has attempted the assessment. All attempts, including unsuccessful ones, are taken
into account.
• Repetition attempts can only be created for completed procedures, that is, for ones whose status
is not opened.
• Note: If the system is to check the maximum number of allowed attempts when you create a new
attempt (= open a new process), you have to implement this check with a BAdI.
For any changes within an assessment process, a reason can be maintained.
If the assessment is a module exam, the module booking ID of the related module is kept.
© SAP AG
IHE102
9-38
9 .4 Asse ssm ent Proc e sse s –
Proc e ss-Depe ndent Audit s
Audits can be embedded in an assessment process
For admission to a program of study
For stage completion
= process dependent audits
For program progression (=graduation)
If an audit is embedded in an assessment process, you can divide between two
different audits for different process parts:
Admission audit – completion audit
Assessment (CE)
Admissions Audit Run
= „fulfilled“
Assessment process
status:
„open“
Completion Audit Run
= „fulfilled“
„completed successfully“
© SAP 2009
Assessment processes, which are guiding the process of admissions, stage completion and
graduation, can include audits. The result of the audits can be used to move a student from one
status in the process to another, for example: audit result = all requirements for degree are met =>
assessment process status = student has successfully completed the graduation process.
If you link an audit to an assessment process, the audit is called “Process-dependent”.
In the system, you will use different transactions to run a process-dependent or process-independent
audit.
For any assessment process there may be two different audits involved. One audit to decide on the
admission to the assessment process (not to be confused with the process “admission to a
program”!) and one audit to decide if the assessment process is finished successfully. In Student
Lifecycle Management, this is called “process part admission audit” and “process part completion
audit”.
• The audit settings include a parameter to indicate the process part. If you run a process-dependent
audit, you have to select the process part for which the audit is to be run.
• The result of the audit affects the assessment process status. This can be updated manually or via
a report.
• Since universities should not be forced to use the procedures, audits can be executed with or
without relation to assessment processes.
For more information, see the chapter “Audits”.
© SAP AG
IHE102
9-39
9 .4 Asse ssm ent Proc e sse s – Proc e ss Flow
1.
Create Assessments
within Academic Structure
2. Offer / Schedule Assessments
(Session, Date, Time, Location)
4.
3. Open Assessment Process
(= register Student on Assessment)
5.
Assessment grading
Assessment evaluation:
set final status for ass. process
© SAP 2009
1) In the first step you link the assessment to programs of study (admissions, graduation, stage
completion) or to modules (module examinations).
2) Afterward you offer the assessment for specific sessions. If applicable, you may also schedule the
assessment and maintain date, time, resources, and deadlines.
3) Assessment processes are opened as soon as a student is registered to an assessment.
Registration can be maintained manually, or be triggered automatically in the background, using a
function module which can be used within customer reports or linked into a triggering process. With
the assessment process status, the assessment process is managed through different steps. The final
process status leads to the end of the assessment process.
Manual Registration:
• 1) From Student View: Within the student file, go to the Display Assessment Process screen.
Choose the Expected Process tab page. Select the entries and choose Open Assessment Process.
The assessment processes are created with the system status opened. The system automatically
switches to the Assessment Process tab page.
• 2) From Assessment View: Go to the Edit Assessment Process screen (SAP Menu → Student
Lifecycle Management → Teaching and Examination → Academic Records → Edit Assessment
Process).
– Variant A: Like in the Student View, on the Expected Process tab page, choose Open
Assessment Process.
– Variant B: From the toolbar, choose Open Process. In the dialog box which appears, choose
the students individually or use selection methods. Save the settings made. The assessment
processes are created with the system status opened.
© SAP AG
IHE102
9-40
9 .4 Asse ssm ent Proc e sse s – Ex pec t ed
Asse ssm ent s
The system can inform you about expected assessments:
for (re-) registrations on programs
with stages: stage completion
for module booking assessments
When the modules are booked,
the system lists the students
who have not yet booked the
assessment for the given
module as Expected
Assessment Processes.
For graduation and admission,
no expected assessment
processes are available. The
system always opens the
process automatically.
For stage completion, all (re-)
registered students for a
program or stage which have
not registered for stage
completion are displayed as
expected assessment
processes.
© SAP 2009
Two scenarios are supported by the expected assessment functionality:
• First, the system creates a list of students who are expected to book a certain module exam.
These are all students with a module booking in a given session but no assessment booking on
the assessment (exam) related to the module.
• Second, you can get a list of all students who have (re-)registered for a certain session and a
program with stages. These students are expected to start the stage completion process in order to
check whether they have fulfilled the stage requirements.
Expected assessments allow you to:
• Easily book a list of students onto assessments, e.g. all students registered to a module should
attend the module exam at the end of the year
• Get an overview of how many students may have to attend the exam, e.g. schedule assessments
only after knowing how many students may have to attend the exam
• Easily register students for the stage completion process
Note regarding Assessment periods: their actual dates are taken from the Academic Calendar,
however the IMG views “Define Assessment Sessions” and “Set up Session Groups” must also be
completed.
© SAP AG
IHE102
9-41
9 .4 Asse ssm ent Proc e sse s – Asse ssm ent
Proc e ss St a t us
Customer Status
System Status
The SAP standard system delivers
the following status to describe the
assessment process steps:
- opened
- canceled
- completed successfully
- completed unsuccessfully
Next to the SAP status, an
additional customer status can
define more details for the
assessment process steps to
reflect the customer business
process
Example: SAP Status: + Customer Status
„Opened“
+ „to be approved“ / „approved“ / „not approved yet“
Make sure you change the assessment process status when required:
Manually and per single assessment process
With a mass activity, started manually
Automatically by the system (background mass activity)
© SAP 2008
The SAP system status “drives” the assessment process and determines its end by a final status:
• Open: status when a student is registered for an assessment. Initial status, record is valid and in
work.
• Cancel: Final status means this record is closed and invalidated, neither successful nor
unsuccessful. A canceled assessment process does not count toward the assessment attempts of
the student.
• Completed successfully: Final status, record is valid and closed and the attempt counts as
successful.
• Completed unsuccessfully: Final status, record is valid and closed and attempt counts as
unsuccessful.
The customer status can be defined in Customizing and can be used to refine the SAP status and
map more steps within the assessment process: Examples: You can create a customer status to
express that an attempt should not be taken into consideration for follow-up process
You have to make sure that the system and customer status are changed according to the process
steps. The result of the status can be influenced by the result of an audit embedded to the assessment
process or the grades maintained for the assessment appraisal. You are able to:
• Change system and customer status manually using the assessment process transaction (SAP
Menu
Student Lifecycle Management Teaching & Examinations
Assessment Processes )
• Change both status using a mass report in order to change many assessment processes in one step
after an audit has been run (SAP Menu
Student Lifecycle Management
Teaching &
Examinations
Academic Record
Change Process Status (Admission) / (completion). )
• Define a background mass processing activity to change the status automatically. The system
allows you to update the assessment process status for a module exam based on the grades
entered for the exam in the module appraisal.
© SAP AG
IHE102
9-42
9 .4 Progre ssion by St a ge Comple t ion
Business Process (Assessment Process) flow in a progression model based
on stages:
1. Register student for stage completion
Open assessment process for stage completion
Optional: Register on exam (-> Register on scheduled assessment)
2. Exam
3. Evaluation of academic work (Courses, Majors, other study results,
Individual work, stage exams)
Perform process-dependent stage audits (admission / completion)
4. Determine result of stage audit
Change status of assessment process, depending on audit result
5. Confer qualification for stage; allow student to proceed to next stage
Confer qualification
© SAP 2008
The start of the assessment processes is referred to as ”open assessment process“. In the SAP Menu
go to Teaching & Examinations Academic Record Edit assessment processes.
• To open assessment processes, you can select students directly or use selection methods to find
the students for whom you want to open an assessment process for the selected assessment.
• Another option is to use the ”expected processes“ function. On the corresponding tab, you find
all students who do have a valid registration for the chosen program, stage and academic year,
but do not have an open assessment process for the stage completion assessment yet.
• Or you open the assessment process automatically triggered by a registration to a program
(BAdI)
• You can open a stage completion assessment process with reference to a scheduled assessment.
In this case, registration and withdrawal deadlines are stored by the scheduled assessment.
Once you have opened the assessment process(es), you can start the first audit: process part
”admission“ to check whether students are eligible to be submitted to the stage completion process.
• You can do this in transaction SE80, BSP application “PIQ_AUDIT” or
• Use the mass report for process-dependent audit runs in the SAP Menu: Teaching &
Examinations Academic Record Audit (process-dependent).
After the admissions audit run has been completed and a result has been returned, you must change
the customer assessment process status accordingly e.g. Audit result = ”Fulfilled“ => set customer
status ”admitted“. You do this using the report to change the assessment process status, to be found
under Teaching & Examinations Academic Record Change Process Status (Admission).
Then you can start the completion audit run in the same way as the admissions audit run. The
assessment process should be finished now, therefore you have to set a final system process status,
such as ”completed successfully“. Additionally, you can also set a customer status. You do this
again by means of the mass report for status change, but now for the process part “completion”
(Change Process Status (Completion)).
© SAP AG
IHE102
9-43
9 .4 Asse ssm ents: T opic Sum ma ry
You should now be able to:
Understand the concept of assessments and assessment
processes in Student Lifecycle Management
Know how to set up and schedule assessments
Explain how you can use assessment processes
Know how to register students to assessment processes
Know how to use and change the assessment process status
Explain how audits can be embedded into an assessment process
© SAP 2009
© SAP AG
IHE102
9-44
9 .5 Ex a m ina t ion: T opic Objec t ive s
After completing this topic, you will be able to:
Understand the process of examination in Student Lifecycle
Management
Explain how to set up examinations
Know how to schedule exams and offer them to students
Describe how the plausibility check for exam scheduling works
Know how to register students to exams
© SAP 2009
© SAP AG
IHE102
9-45
9 .5 Ex a m ina t ion: Busine ss Sce na rio
You have to set up the academic structure at your institution
and advise faculties on how to define their exam periods
You schedule assessments in case students have to take
exams in order to complete a module
You start the examination process by registering students to
exams
You monitor the grading and completion of the examination
process
© SAP 2009
© SAP AG
IHE102
9-46
9 .5 Ex a m ina t ion – Conte nt of a M odule
(Ex a m ple )
Sample content of a module:
Module 3 – Exp. Physics I
1.
Lectures in Exp. Physics III (E)
Event
Package (SE)
2.
Exercises in Exp. Physics III (E)
3.
Examination in Exp. Physics III (E)
Assessment (CE)
© SAP 2009
A module is the object which is booked by students and for which a grade and credits can be earned.
It usually consists of several sub-elements, such as lectures, exercises, tutorials, excursions, etc. One
of those sub-elements are exams which often need to be attended and passed by the students in order
to successfully finish the module.
When a student books a module, he or she is expected to take part in all sub-elements. Every subelement can be graded individually. The final module grade is then calculated from the input of the
sub-elements. Please refer to the chapter „Grading“ to learn more about grading of exams.
© SAP AG
IHE102
9-47
9 .5 Ex a m ina t ion – Ex a m Profile
Assessment Data Attribute: Exam Profiles
You can define exam profiles. An exam profile is a reusable set of the following
assessment attributes:
will be considered by the system
when scheduling an assessment
Exam duration: in hour or minutes
Exam mode: modes your university offers for exams
Example: Written, Oral, Practical
will help to choose the responsible
people or organizations for the
exam procedure
Functions, Activities and number of resources:
Functions: define object types, such as persons, organizational units etc. which are taking
over functions within the assessment process.
Activities: Assign an activity to each function to determine what they are responsible for.
Available activities:
–
Conduct exam
–
Prepare exam
–
Evaluate exam
Number of resources per function: Objects can be assigned, such as a concrete person
as examiner to conduct the exam and two co-examiners.
© SAP 2009
An exam profile is used as default when creating a scheduled assessment, but the attributes can be
overwritten.
Example for an exam profile: According to a university’s exam regulations, midterm exams are 30minute, single-student oral exams which are held by an examiner and a co-examiner.
You create an exam profile with the following attributes:
• Duration 30 and Unit MIN
• Exam mode: oral
• Functions: examiner and co-examiner
For assessment processes, you define functions for editing exams in the academic records
application:
• First, you define the functions and then you assign relevant activities to these functions. You
finally assign the responsible person, external person or organization to each activity.
• When you enter an exam profile for an assessment, you can choose whether the exam profile
should be defaulted when scheduling an assessment or not. It can be overwritten if required for
the scheduled assessment.
© SAP AG
IHE102
9-48
9 .5 Ex a m ina t ion – Sc heduling Ex am s
Sessions of Offering
Assessments can be offered:
in different sessions than the respective module
in the same lecture period as the module, i.e. session.
A scheduled assessment refers to a specific assessment and assessment period (=session of
offering).
The sessions in which a module is offered (lectures are held) and the assessment period for
each assessment (object type CE) are defined in the infotype Sessions of Offering (1739).
Key Fields:
Assessment (object CE: plan version, object type, object ID)
Academic year
Academic session
Scheduled assessment number
Module (SM)
548
Assessment
(CE)
CE – SM: 548 (is assessment for)
© SAP 2009
The session in which a module is offered can comprise one or more assessment periods:
Example 1:
• one at the end of the lecture period (regular examination period),
• one (for repeated exams) before the start of the next academic session
Example 2:
• 1st assessment period at the end of the Fall semester lecture period
• 2nd assessment period at the end of the Spring semester
• Semester lecture period (June)
• 3rd assessment period for repeated exams (September)
Note: Assessment sessions can coincide with lecture periods (= session where modules are offered).
If this is the case, separate assessment periods do not have to be defined.
© SAP AG
IHE102
9-49
9 .5 Sc he duling Exa m s – Sc he duling De t ails
Scheduled Assessment: Module Exam
Module
“Math 1“ (SM)
Sessions of Offering;
Session Group for
Module Offering
Assessment
“Math 1 Exam” (CE)
Sessions of Offering;
Session Group for
Assessment Periods
Fall 2008
Fall 2008
“Regular Exam”
Fall 2009
Fall 2010
Fall 2008
“Repeat Exam”
Sched. Asmt 1
for Fall 2008
Sched. Asmt 2
for Fall 2008
Sched. Asmt
“Repeat Exam”
for Fall 2008
Location and room
Date and time
Duration and breaks
Registration
deadlines
Withdrawal deadlines
Activities and
responsible persons /
organizations
© SAP 2009
To schedule an assessment, go to the Edit Assessment transaction (PIQEVALM) under Student
Lifecycle Management
Teaching and Examination Academic Records
Edit Assessments.
Choose an assessment: a) using the object manager or b) select the module via the “object type” and
“object name”.
In the Scheduled Assessments group box, choose the assessment period. Choose ‘Find Scheduled
Assessments’. The system displays the existing scheduled assessments. Choose ‘Create Scheduled
Assessment’ or ‘Edit Scheduled Assessment’. Edit the attributes on the Dates/Deadlines and Exam
Profile tab pages and save the settings made.
Additional attributes of scheduled examinations to the ones above are:
• Exam Mode (Written, Oral, Practical, etc.), Exam plan (single, mass, group), Duration (x Hours /
Minutes, Breaks), Registration and withdrawal periods, Activities (Prepare Exam, Conduct
Exam, Evaluate Exam and Functions: Examiner, Co-examiner, Supervisor, etc.)
Business Case:
• Students who attend the module ”Math1“ must pass an exam at the end of the module session.
The exam can be repeated once. For this purpose, the exam is offered at two different dates, one
directly after the module has finished, which is the regular exam, and one a view weeks later, as
repeat exam for those who did not pass or those who could not attend the first exam.
• The regular exam takes place in two different classrooms, because during the exam, they should
not sit in rows together, but more space is necessary between. Therefore, the number of students
participating in the exam is too big to locate them in one room. The university therefore
schedules three assessments altogether:
– assessment 1 and 2 for the regular exam, same date and time, but different location
• assessment 3 for repeating students with different date
© SAP AG
IHE102
9-50
9 .5 Ge ne ra t ing Schedule d Exa m s in one St e p
Generate similar scheduled assessments in one step
The system enables you to create several scheduled assessments in
one operation if they have the same attributes (date, duration, location,
exam mode, exam plan, registration and withdrawal period), are
successive, and only differ in their start and end times.
Business Case: An examiner conducts “n” assessments in succession in
the same room. The examinees are assigned available time slots or can
choose a time slot themselves via Self Service.
Sched. Asmt 1 for Student
Group 1: 9-10 am
Fall 2008 “Biology 1: Oral Exam”
Sched. Asmt 2 for Student
Group 2: 10-11 am
3 Students together, one Hour
altogether 12 Students
Sched. Asmt 3 for Student
Group 3: 11-12 am
Sched. Asmt 4 for Student
Group 4: 2-3 pm
© SAP 2009
Within the “Edit Assessment”-transaction, you select an assessment and create a new scheduled
assessment. Now you can choose “Generate Scheduled Assessments”. Then you have to define the
attributes for generation, in particular:
• the duration of the room reservation
• the maximum number of scheduled assessments
• and the number of parallel assessments (exams offered simultaneously)
The required assessments will be generated automatically. The systems takes into account the
information about the duration of the assessments as given within the exam profile. The scheduled
time will be corresponding to the duration of the assessment. The system takes into account:
the duration of the room reservation, which is the maximum time frame during which assessments
can be scheduled,
the duration of an assessment in hours or minutes the number of parallel sessions: if more than one
parallel sessions are allowed, the system schedules x assessments at the same time, same location.
You can use this functionality if several students are examined in the same room at the same time,
but different scheduled assessments should be created for them.
the maximum number of assessments: the system will not schedule more than this amount of
assessments even if the room reservation is longer than the occupied time with the scheduled
assessments.
© SAP AG
IHE102
9-51
9 .5 Sc he duling Exa m s – Dura t ion a nd Room
Re source s
Plausibility Check for exam duration:
The system will warn you if the exam duration derived from the beginning and the end time of
the scheduled exam does not match the duration attribute of the used exam profile.
Prerequisite:
The assessment must be used for examinations (assessment with audit type “module
completion”).
Maintain exam profile: Mark exam profile as “default” => information from exam profile will
be defaulted for exam scheduling
Room reservation functionality for scheduling exams
Room resources (locations, building, rooms) from Training and Event Management / Event
scheduling can be booked directly from the assessment scheduling screen.
Prerequisites:
Assessment has to be assigned to an event type object which serves as master for the
exam to be created.
© SAP 2008
Plausibility Check:
• When scheduling an exam, a plausibility check for the exam duration is performed by the system.
A warning message will be sent if the exam duration derived from the beginning and the end
time of the scheduled assessment does not match the duration attribute of the used exam profile,
which is maintained in the assessment attributes.
• When maintaining the exam profile, you can define whether it should be used as default data for
the scheduling process or not.
Benefit:
• Correct data entry is supported.
• Administrative staff is supported in their daily work.
Room Reservation:
• Student Lifecycle Management offers the link to resources such as location, building and rooms,
known from Training and Event Management. Room reservations can be done within the
assessment function.
• A room reservation check box appears when an assessment, such as an exam, is assigned to an
event type object.
Note: The room reservation check box only appears when an assessment (object type CE) is
assigned to an event type object (D) which is then used as master for the event (object type E)
created during room reservation. This function is only available for module completion assessment
(= exams).
© SAP AG
IHE102
9-52
9 .5 Ex a m ina t ion Proc e ss – Asse ssme nt
Proc e ss
The examination process is managed by the assessment process type
”module completion“ in Student Lifecycle Management. Assessments are
created and attached to the respective module.
Business Scenario
System Support
1) Student books module exam
open assessment process
2) Student attends module exam
outside system
3) Examiner evaluates module exam
outside system
4) Examiner sets grade for module exam
module grading
5) Examiner sets final result for module exam
close assessment process with status
”completed successfully / unsuccessfully“
Note: Repetition attempts of the same exam can only be created if the previous
attempt has been completed (= assessment process completed). To create a new
attempt of the same exam, you open a new assessment process for a different
scheduled assessment of the assessment.
© SAP 2008
Once you have created and scheduled module exams as assessments in the Student Lifecycle
Management system, you can start to register students on the assessments via the assessment process
transaction at Student Lifecycle Management → Teaching and Examination → Academic Records
→ Edit Assessment Processes.
You can also open the assessment process via the module booking dialog at Goto
Assessment
Process. If you choose this process variant, scheduled assessments must be created before modules
are booked so that the student (or advisor) can choose the appropriate scheduled assessment when
s/he books the modules. Only students booked on the module can register for the module
assessment.
When you register the student for an exam (which can be either scheduled or not, but at least need to
be offered for the selected session), you select the assessment, the number of the scheduled
assessment if existing and the session. An assessment process is opened for each student as soon as
the registration is saved. Using the assessment process status you can keep track of the steps in the
examination process.
Once the exam is over, a grade is determined and entered as appraisal into the system. You close the
assessment via the assessment process transaction by setting a final system status.
The exam may not be the only task for the student within a module to ”complete“ the module. Other
tasks, such as delivery of a paper, grades for lecture attendance, etc. may influence the final module
grade and therefore module result. The term ”Module completion“ assessment process does
therefore not correspond with the final module completion which sets the final module grade.
Repetition Attempts: The attempt number is stored for each assessment process
• The maximum number of allowed attempts can be checked with a customer rule via BAdI when
CE is called
• The attempt number represents the number of times the student attempted the exam (assessment).
All attempts, including unsuccessful ones, are taken into account. The check is done via BADI
when the CE is called.
• If the system is to check the maximum number of allowed attempts when you create a new
attempt, only the relevant attempts may be counted. This has to be defined in the BADI to check
rules for assessment registration.
© SAP AG
IHE102
9-53
9 .5 Ex a m ina t ion Proc e ss – Gra ding
After a student has registered for a module exam (= open module completion assessment
process), the student will attend the exam and usually receive a grade for it.
The grade for an assessment process is maintained within the module appraisal
Appraisal Template
uses
Module (SM)
Appraisal Type “Module Appraisal”
Lecture (D)
Appraisal Type
“Lecture”
Tutorial (D)
Appraisal Type
“Tutorial”
Assessment (CE)
Appraisal
Type for
Assessment
Appraisal Type
“Assessment”
© SAP 2009
If an assessment is graded (e.g. in case it is representing an exam), you use appraisals to maintain
the assessment grade. The grade for an assessment process is displayed in the list along with other
appraisal attributes.
Prerequisites:
• The assessment process is assigned to a module booking and
• The assessment (CE object) is assigned an appraisal type and
• The appraisal type assigned to the assessment is part of the appraisal template assigned to the
module and
• An appraisal of this (appraisal) type exists for the student
How to do:
• Enter the appraisal dialog and choose the module the assessment is related to. The system uses
the appraisal type of the module as the default value. Select the students and enter the appraisal
type for the assessment. Then you can enter the assessment grades and save.
• To support multiple attempts for an exam within the same module completion and to store the
different grades within the same appraisal scheme, it is necessary to identify the exam attempts
via increasing sequence number of the same appraisal type. The appraisal dialog supports this
functionality.
1. Navigation to the Appraisal Dialog
• From the exam dialog choose “Goto”
“Module Appraisal” (transaction PIQSMFU). The
system uses the appraisal type of the assessment as the default value for the “Appraisal View”
and automatically flags the appraisal of the selected student.
2. Single Screen
• “Display Appraisal Data”: The detailed data of the appraisal appears in a dialog box. The system
only displays the part appraisal which is to be assigned to the assessment (via the appraisal type
of the CE object).
© SAP AG
IHE102
9-54
9 .5 Ex a m ina t ion Proc e ss – Syst e m St a t us
Change System Status
The system status can be: opened, cancelled, completed successfully, completed unsuccessfully
The system status can be changed only by persons who are authorized to use the respective
activities. This table shows which status changes can be made and which activity authorization is
checked in each case:
Original Status
Target Status
Activity
Key
Opened
Cancelled
Cancel Process
CO11
Opened
Completed successfully
Complete Process Successfully
CO12
Opened
Completed unsuccessfully
Complete Process
Unsuccessfully
CO13
Cancelled
Opened
Reopen Process
CO10
Completed successfully
Opened
Reopen Process
CO10
Completed unsuccessfully
Opened
Reopen Process
CO10
© SAP 2009
Note: The system does not support direct status changes from statuses other than “opened”.
However, you can change from one status to another via the status “opened”.
© SAP AG
IHE102
9-55
9 .5 Ex a m ina t ion – T opic Summ a ry
You are now able to:
Explain the most important terms and definitions for exams
(assessments) in Student Lifecycle Management
Know how to setup scheduled exams
© SAP 2009
© SAP AG
IHE102
9-56
9 . U nit Sum m a ry: Gra ding, Asse ssm e nt s a nd
Ex a m ina t ion
You are now able to:
Define academic scales
Use appraisal templates and their components
Create appraisals for students in modules
Schedule Assessments and Exams
© SAP 2009
© SAP AG
IHE102
9-57
© SAP AG
IHE102
9-58
I H E1 02 St udent Lifec yc le M anagem ent :
1 0 . At t e ndance T ra ck ing
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009
© SAP AG
IHE102
10-1
1 0 . At t e ndance T ra ck ing: U nit Obje c t ive s
After completing this unit, you will be able to:
Understand how attendance of students is tracked within Student
Lifecycle Management
Understand the role of calculation rules and IO semantics
Define attendance reasons and calculation rules
Maintain substitutes
© SAP 2009
© SAP AG
IHE102
10-2
1 0 . Business Sc e na rio for At te nda nc e T ra c k ing
You wish to record attendance for students to certain events. Furthermore,
you wish to incorporate the attendance results into the module appraisal so
that they can be used as a pre-requisite for the successful completion of
modules.
© SAP 2009
© SAP AG
IHE102
10-3
1 0 . At t e ndance T ra ck ing Ove rvie w
Overview
Attendance Tracking can be switched on globally or it can be activated at the
Event Type. It can also be controlled at the individual student level via a BADI.
Attendances and absences are recorded via a Web UI in the following steps:
1. Select academic year and session
2. List events
3. Record attendance
A traffic system is used to indicate the status of the attendance record
Reasons for Attendance Tracking are defined in customizing. SAP does not
deliver absence reasons as they are customer specific.
Pre-excused absences are recorded in the Student File. These absences
then update the attendance records for the relevant events.
The appraisal aggregation engine incorporates the attendance result in the
overall grade.
© SAP 2009
Attendance tracking can be activated at the Event Type or globally as follows:
• 1. Event Type
Activate the flag “Att. Compulsory” in the Infotype “Category”.
Note: Event types have the same validity date as the module (SM) does which is basically no end
date. In contrast, events have a validity of one semester.
2.Global Switch
IMG path: SLCM>Processes in SLCM>Attendance Tracking>Switch on Attendance Tracking
Globally. Enter “X” for the Setting Value to activate Attendance Tracking globally.
A “Blank” value means that attendance can only be tracked for Events that belong to Event Types
where the Attendance Compulsory flag is set.
You maintain unexpected absences directly in the Attendance Tracking UI.
The following BADIs are provided for Attendance Tracking functions: -> Processes in SLCM ->
Attendance Tracking -> Business Add-Ins:
• Get Attendance Rules
• Check Student’s Relevance for Attendance
• Student Attendance Calculation
• Substitution Derivation for Attendance
IMG Path for BADI’s IMG for Attendance Reasons SLCM>Processes in SLCM>Attendance
Tracking>Define Absence and Tardy Reasons. They are used by the Instructor to cancel a class or
by students to specify reasons for not attending a class. Reason types are as follows:
• E. Excused Absence.
• U. Unexcused Absence.
• T. Tardy Reason (Note: A Tardy Reason cannot be used as a Withdrawal Reason)
© SAP AG
IHE102
10-4
1 0 . At t e ndance T ra ck ing: Ca lc ula t ion Rule s
Calculation Rules
Different rules can be used for calculating the Appraisal based on attendance.
These rules are maintained at the Module or Organization Unit level. For more
flexibility you maintain rules on the SM level.
A sample coding for defining Attendance Calculation Rules is delivered
IO Semantics
IO Semantics is used to identify the Attendance Appraisal Type in the PI
calculation.
IO Semantics must be defined in customizing for the Attendance Appraisal Type
and should exist once the Appraisal Type is being used for Attendance Tracking.
© SAP 2009
IMG Navigation Path Calculation Rules:
• SLCM>Processes in SLCM>Attendance Tracking>Define Calculation Rule.
IMG Navigation Path IO Semantics:
• SLCM>Processes in SLCM>Attendance Tracking>Define IO Semantics for Att. Tracking.
Overview on required steps:
• Define IO-Semantics for Attendance (APPR)
• Define Attendance Appraisal Type
• Define on SM level the used calculation rule, scale, and threshold. Define under which condition
the attendance requirement is fullfilled.
A BADI can be implemented to derive the rules for Attendance calculation. The default
implementation reads the calculation rule from Infotype 1723 at the Module, if nothing is found,
from the offering Org. Unit.
The calculation performed by the sample coding is as follows: The number of attended Events is
divided by the number of event occurrences and compared with the Threshold Value. If the
calculated value is lower than the Threshold, then the grade is set to Failed, otherwise to Passed.
Customers can use this sample to set up their own rules.
IMG Navigation Paths:
• BADIs: SLCM>Processes in SLCM>Attendance Tracking>Business Add-Ins>Get Attendance
Rules/Student Attendance Calculation
• Scale: SLCM>Master Data in SLCM>Academic Scales.
Note: Calculation rules must be defined to transfer Attendance data to the Appraisal framework.
© SAP AG
IHE102
10-5
1 0 . At t e ndance T ra ck ing: Gra de a nd Appra isa l
Grade Symbol for Attendance
A special grade symbol must be defined in customizing to represent a failed grade based
on insufficient attendance.
The BADI ‘Additional Grade Symbols’ must be implemented in order for the system to
accept a grade symbol which is not part of the Academic Scale.
Appraisal Type and Appraisal Template for Attendance
A specific Appraisal Type must be defined for the Attendance and should be assigned
directly below the top Appraisal.
The results of the Attendance calculation is stored in this Appraisal Type.
You assign the Appraisal Template to where Attendance is tracked at the organizational
level.
No weighting needs to be assigned to the Attendance Appraisal Type.
A key figure must be assigned to the Top Appraisal to evaluate the Appraisal Result.
© SAP 2009
IMG Navigation Paths Grade Symbol:
• Grade Symbol: SLCM > Processes in SLCM >Attendance Tracking >Define Default Grade
Symbol for Attendance.
• BADI: SLCM > Processes in SLCM>Appraisal > Business Add-Ins > Additional Grade Symbols
IMG Navigation Path Appraisal:
• Appraisal:: SLCM>Processes in SLCM>Appraisal
• Note: The Attendance Appraisal Type must be maintained in the “Setting Value” for the group
APPR. IMG: SLCM > Processes in SLCM >Attendance Tracking >Define Appraisal Type for
Attendance
IMG Navigation Path Key Figure:
• SLCM>Master Data in SLCM>Key Figures
© SAP AG
IHE102
10-6
1 0 . At t e ndance T ra ck ing: Subst it ut ion
Defining Substitutions:
You define in customizing how substitutions should be handled for Attendance Tracking.
The following options exist:
The substitution is not considered
All substitutions are considered
Filtering is active. Only Users with a profile containing the category ATTR are
considered as substitutes.
Maintaining Substitutes:
1. Maintain a substitute at transaction: PIQ_MAINT_SUBSTITUTE
2. Maintain the relevant profile (e.g. ATTR) for users
3. In the Profile field, choose a substitution profile (The substitution profile may or may not
contain the attribute 'ATTR‘).
© SAP 2009
Possible values to define subsitutions:
• ‘blank’: The substitution is not considered.
• ‘*’: No filtering – all substitutions are considered.
• ‘ATTR’: Filtering is active. Only Users with a profile containing the category ATTR are
considered as substitutes.
A BADI is provided to derive substitutes for a User. A default implementation to derive the personal
substitution is provided.
You have to maintain a specific person as substitute for a person.
IMG Navigation Paths:
• Substitution Task: SLCM>Processes in SLCM>Attendance Tracking>Maintain Substitution
Task Setting.
• Substitution Derivation: SLCM>Processes in SLCM>Attendance Tracking>Business AddIns>Substitution
• Derivation for Attendance.
• Attribute ‘ATTR’ is set up in the IMG at: SAP Netweaver -> Application Server -> Business
Management --> SAP Business Workflow -> Basic Settings -> Substitute Profile -> Define
Substitute Profile
© SAP AG
IHE102
10-7
Sum m a ry
Now you are able to:
Explain how attendance of students is tracked within Student Lifecycle
Management
Understand the role of calculation rules and IO semantics
Define attendance reasons and calculation rules
Maintain substitutes
© SAP 2009
© SAP AG
IHE102
10-8
U nit Sum m a ry: Gra ding, Asse ssm e nt s and
Ex a m ina t ion
You are now able to:
Define academic scales
Use appraisal templates and their components
Create appraisals for students in modules
Explain how Attendance of students is tracked
© SAP 2009
© SAP AG
IHE102
10-9
© SAP AG
IHE102
10-10
I H E1 02 St udent Lifec yc le M anagem ent :
1 1 . Audit
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009
© SAP AG
IHE102
11-1
1 1 . Audit s
Contents:
11.1 Audits Overview
11.2 Requirement Catalog
11.3 Requirement Pattern
11.4 Requirements and Subrequirements
11.5 Requirement Profile Template
11.6 Audit Run
11.7 Admissions Audit
© SAP 2009
© SAP AG
IHE102
11-2
1 1 . U nit Obje c t ive
After completing this unit, you will be able to:
Understand the concept of audits in Student Lifecycle Management
Explain the functionality of:
Requirement Catalogs and Versions
Requirement Patterns
Requirements and Subrequirements
Requirement Profile Templates
Derive a Requirement Profile for a Student
Run Audits for Students
Understand the Admissions Audit
© SAP 2009
© SAP AG
IHE102
11-3
1 1 .1 Ove rvie w : T opic Objec t ive s
After completing this topic, you will be able to:
Give a general introduction to the audit concept
Differentiate between stage and degree audit
Know about the different elements of the
requirement set up in Student Lifecycle
Management
© SAP 2009
© SAP AG
IHE102
11-4
1 1 .1 Audit s - I nt roduc t ion
Audit process in Student Lifecycle Management supports the student and the faculty in
auditing the requirements a student needs to fullfill.
Audits can be used in different processes defined by audit type:
Admissions Audit
Stage Audit
Degree Audit
Audits are performed with an audit run based on a requirement profile.
Requirement profiles are generated individually for each student.
Business Scenarios:
A university uses the Student Lifecycle Management to do degree audit for their students.
Individual academic work of each student is taken into account and compared to the degree
requirements prescribed by the program of study.
The requirement profile collects all rules which a student needs to fulfill in order to achieve the
degree as final qualification of a certain program of study.
Some programs of study are structured by stages that have their own completion rules.
Students‘ academic progress is checked for each stage with a stage completion process. A
stage audit informs about the students‘ progress within one stage of a program of study.
© SAP 2009
© SAP AG
IHE102
11-5
1 1 .1 Ove rvie w – St a ge and De gre e Audit
In Student Lifecycle Management an audit functionality is provided to compare
students’ achievements with rules & requirements defined by the institution.
Two audit types are delivered regarding progression and graduation:
Degree Audit for auditing
requirements to complete a
program and achieve a
degree
Stage Audit for auditing
requirements per stage within a
program
Module Bookings
Remaining
Work
Degree / Stage
Results
Degree / Stage
Audit
Progression
Basket
Initial stage
Eligibility to
Graduate
Eligibility to
pass a stage
© SAP 2009
Audits can be performed at many times during the student lifecycle. An audit can have an advisory
function to help the student e.g. to complete module bookings in order to achieve the required
degree. It may also have a monitoring function when, for example, minimum study requirements
need to be fulfilled in order to let the student continue with his or her studies. And it helps to assess
students‘ work at points in the student lifecycle where results are needed to comply with study
requirements, e.g. at the end of a stage or in order to receive a degree.
Student Lifecycle Management distinguishes between two different audits: degree audit and stage
audit.
• Degree audit is performed in order to graduate a student or to advise the student to receive a final
degree.
• A stage audit is monitoring the efforts a student has done during a stage. The result might affect
the student‘s eligibility to progress to the next stage.
The results of an audit can be used for different purposes, not only for graduation or stage
completion, but also e.g. to define the initial stage of a program which a transferring student can
enter.
© SAP AG
IHE102
11-6
1 1 .1 Ove rvie w – Adm issions Audit
A student is applying for admissions to a program of study. The
program of study has specific requirements which must be fulfilled
by the applicant for admission
You can perform admissions
audits to check admissions
requirements automatically.
The system automatically
recognizes and duns
outstanding requirements
such as missing documents.
An assessment process is
created and rules of the
requirement catalog are
checked with an audit.
You can manage inbound and
outstanding documents by
connecting to SAP Records
Management (RCM).
Advantages: transparency, tracking options, reduced paper
processing, improved response times
© SAP 2009
© SAP AG
IHE102
11-7
1 1 .1 Ove rvie w – Proc e ss-Depende nt Audit s
Audits can be embedded in an assessment process = process dependent audits
for stage completion
for program progression
If an audit is embedded in an assessment process, you can distinguish between two
different audits for different process parts:
admissions audit
completion audit
Admissions Audit Run
= ”fulfilled“
Completion Audit Run
= ”fulfilled“
Assessment process
status:
”open“
”completed successfully“
© SAP 2009
The result of audits can be used to move a student from one status in the process to another, for
example: audit result = all requirements for degree are met => assessment process status = student
has successfully completed the graduation process.
If you link an audit to an assessment process, the audit is called “Process-dependent”. There are
different transactions to run a process-dependent or process-independent audit.
For any assessment process there may be two different audits involved. One audit to decide on the
admission to the assessment process and one audit to decide if the assessment process has been
finished successfully. In Student Lifecycle Management, this is called “process part admission
audit” and “process part completion audit”.
The audit settings include a parameter to indicate the process part. If you run a process-dependent
audit, you have to select the process part for which the audit is to be run.
The result of the audit will influence the assessment process status. This can be updated manually or
by means of a report.
Since universities should not be forced to use the procedures, audits can be executed with or without
relation to assessment processes.
For more information, please see the chapter about assessment processes.
© SAP AG
IHE102
11-8
1 1 .1 Audit – Se t up of Audit Rule s
1
Requirement Catalog
Student
Program Completion Requirements
Set by the University
is registered for a program
and has booked a
specialization
B.A. : General requirements
B.A. : Specialization requirements
(e.g. Major requirements)
Requirement
Pattern
B.Sc.: General requirements
B.Sc. : Specialization requirements
2
Requirements & Subrequirements
Rule containers
and rule modules
Concrete rules e.g. Minimum credits per stage,
Mandatory modules, minimum semester credits
3
Compare = Audit
5
Individual profile
4
Audit Run
Academic work
taken by the student
© SAP 2009
First, the audit requirements need to be defined.
• Rules for degree audit are maintained in requirement catalogs.
• Requirement catalogs are assigned to students.
• For each catalog, a requirement pattern is defined to structure the requirements. The requirement
pattern also contains the information where to collect the audit rules from.
• Audit rules are maintained as rule containers and rule modules which are attached to a
requirement catalog.
• When an audit is going to be performed, first an individual requirement profile needs to be
generated for the student.
• The profile collects all applicable audit rules for a specific student in a particular audit process
(e.g. degree audit). The registered program of study and selected specializations are taken into
account to retrieve the right rules.
© SAP AG
IHE102
11-9
1 1 .2 Re quire m ent Ca t a log: T opic Objec t ive s
After completing this topic, you will be able to:
Understand the functionality of requirement catalogs
Explain the concept of catalog versions, version sets
and version status
Assign requirement catalogs to students
© SAP 2009
© SAP AG
IHE102
11-10
1 1 .2 Audit – Re quire m ent Ca t a log
1
Requirement Catalog
Student
Program Completion Requirements
Set by the University
is registered for a program
and has booked a
specialization
B.A. : General requirements
B.A. : Specialization requirements
(e.g. Major requirements)
Requirement
Pattern
B.Sc.: General requirements
B.Sc. : Specialization requirements
2
Requirements & Subrequirements
Rule containers
and rule modules
Concrete rules e.g. Minimum credits per stage,
Mandatory modules, minimum semester credits
3
Compare = Audit
5
Individual profile
4
Audit Run
Academic work
taken by the student
© SAP 2009
© SAP AG
IHE102
11-11
1 1 .2 Re quire m ent Ca t a log – Ove rvie w
For the audit process a catalog in a
certain version is assigned to each
student.
Requirement
Catalog 1
Version 2005
Organizational Unit 1
A requirement catalog is
owned by an organizational
unit.
Requirement Pattern
Requirement 1
Requirement 2
Version 2007
Version 2008
A requirement catalog has a version
management to cover changes of rules
within the requirement catalogs.
© SAP 2009
When you set up the program regulations (exam rules, degree requirements, stage requirements,
etc.) which are published in the university catalog, you are maintaining requirements catalogs in the
Student Lifecycle Management system. You can differentiate between active and passive versions.
Note: The requirement catalog is NOT an object type!
You edit requirement catalogs with the requirement catalog editing transaction from the SAP Easy
Access screen by choosing SAP Menu → Student Lifecycle Management → Academic Structure
(Curriculum) → Requirement Catalogs → Edit Requirement Catalog.
© SAP AG
IHE102
11-12
1 1 .2 Re quire m ent Ca t a log – Cont e nt s
Faculty 2
FacultyRequirement
1
RequirementCatalog
Catalog
University
Requirement Catalog
Gen. Education Req.
Major Requirements
Gen. Graduation Req.
Major Requirements
Minor Requirements
Competency Req.
Minor Requirements
Competency Req.
Competency Req.
Requirement Catalog:
Contains requirements which are under the same organizational
responsibility (even if they belong to different audit processes)
© SAP 2009
Definition of “Requirement Catalogs”:
You use requirement catalogs to maintain the general and special requirements on which your
university bases its audits. A requirement catalog is an abstract entity that groups together the
requirements one organizational unit is responsible for.
Requirements that a student must satisfy can come from a single requirement catalog. They can also
come from different requirement catalogs. A university’s general academic requirements can be
specified in one requirement catalog while the special program requirements of each faculty can be
outlined in separate requirement catalogs. Example:
• University – General Education Requirement:
- Take 3 credits in Physical Education
- Take 2 courses in Arts
• Faculty – Graduation Requirements for Program of Study:
- A thesis must be completed
• Faculty – Stage completion Requirements for Major:
- At least 2 level-500 courses
You enter the responsibility for a requirement catalog by defining a responsible organizational unit
(O) or person (P).
© SAP AG
IHE102
11-13
1 1 .2 Re quire m ent Ca t a log – Require me nt
Ca t a log V e rsions
Requirement Catalog A:
Version V1
Requirement Catalog A:
Requirement 3-1
Requirement 3-1
Requirement 3-2
Requirement 3-2
A consistent set of requirements
within a requirement catalog
contains the requirements 3-1
and 3-2
Version V2
Requirement 3-3
A year later, requirement 3-2 is
replaced by requirement 3-3.
A change of requirements over the time can be mapped
with requirement catalog versions.
© SAP 2009
Rules are actually always defined in a requirement catalog version. For a student different versions
for different requirement catalogs can apply. Example:
• For the “General Education Requirements” the student needs to follow the rules defined in the
year he or she was admitted to the university, i.e. the catalog version of academic year 2002.
• For her major he or she selects between all valid catalogs versions, e.g. from 2000 to 2006.
Requirement catalog versions allow you to manage a change of requirements over the time and to
keep different versions of the same rule at the same time.
© SAP AG
IHE102
11-14
1 1 .2 Re quire m ent Ca t a log –
Assign Ca t a log t o Stude nt
A student
follows
a program of study
One or more requirement catalog(s) +
version are assigned to the student / study
One catalog is defined as
”main requirement catalog“
for this student / study
© SAP 2009
You assign the main requirement catalog and catalog version to each student on the Requirement
Catalogs tab page in the Student File (PIQST00).
• A function module is provided to automate the assignment of requirement catalogs to a student.
• You also have to identify a specific version of the requirement catalog for the student when
assigning a requirement catalog or you maintain a default version instead of maintaining the
version for each student.
By reading the main catalog’s requirement pattern, the system derives the concrete requirements and
subrequirements. The system chooses only those subrequirements which are contained in the main
requirement catalog version assigned to the student.
© SAP AG
IHE102
11-15
1 1 .3 Re quire m ent Pa t t e rn: T opic Objec t ive s
After completing this topic, you will be able to:
Understand the functionality of requirement patterns
Explain how a requirement pattern is set up
© SAP 2009
© SAP AG
IHE102
11-16
1 1 .3 Audit – Re quire m ent Pa t t e rn
1
Requirement Catalog
Student
Program Completion Requirements
Set by the University
is registered for a program
and has booked a
specialization
B.A. : General requirements
B.A. : Specialization requirements
(e.g. Major requirements)
Requirement
Pattern
B.Sc.: General requirements
B.Sc. : Specialization requirements
2
Requirements & Subrequirements
Rule containers
and rule modules
Concrete rules e.g. Minimum credits per stage,
Mandatory modules, minimum semester credits
3
Compare = Audit
5
Individual profile
4
Audit Run
Academic work
taken by the student
© SAP 2009
© SAP AG
IHE102
11-17
1 1 .3 Re quire m ent Pa t t e rn – Struc t ure of
Re quire m ent Pa t t e rn
A requirement pattern consists of abstract requirements. The concrete audit rules
(requirements and subrequirements) are NOT content of the requirement pattern.
Abstract
Requirement:
Element of the
requirement pattern
General Education Requirements
Competency Requirements
Program Requirements
1st Major Requirements
A requirement pattern can be arranged
in hierarchical order:
In order of appearance of the
abstract requirements:
Requirement Pattern A
Requirement Pattern A
(Abstract) Requirement 1
(Abstract) Requirement 1.1
(Abstract) Requirement 1.2
(Abstract) Requirement 1
(Abstract) Requirement 2
(Abstract) Requirement 3
(Abstract) Requirement 2
© SAP 2009
A requirement pattern gives a structure to a set of audit rules belonging to one type of audit process,
for example:
• Requirements for undergraduate degree audit
• Requirements for Admissions Audit to postgraduate programs
Requirement patterns serve as templates for individual requirement profiles.
A requirement pattern consists of abstract requirements. These are created by the customer and
assigned to a requirement pattern (Customizing)
You can:
• Create abstract requirements
• Assign a category to the abstract requirements
• Define the requirement pattern, and create a structure by assigning abstract requirements to this
pattern
© SAP AG
IHE102
11-18
1 1 .3 Re quire m ent Pa t t e rn – Assign t o Cat a log
You assign a requirement pattern to a specific version of a requirement catalog
per audit type.
Example:
Requirement catalog
Version Audit type
Requirement pattern
University catalog
2005
Degree audit
Undergraduate
University catalog
2006
Degree audit
Undergraduate
University catalog
2007
Degree audit
Undergraduate
University Requirement Catalog
Gen. Education Req
Requirement Pattern
Undergraduate Degree Audit
Gen. Graduation Req
© SAP 2009
The requirement pattern is assigned to a requirement catalog and depends on the catalog version:
You can assign a requirement pattern to a specific version of a requirement catalog per audit type
(degree or stage audit) and process part (admission or completion of process → links to the
assessment process).
Different audit processes are reflected by different requirement patterns assigned to a requirement
catalog.
From the requirement pattern, an individual requirement profile is created for a student. The valid
requirement pattern which applies for a student is derived from the version of his or her main
catalog.
In the requirement catalog customizing activities, you:
• Define requirement catalogs
• Assign a requirement pattern to each catalog
IMG Path: Processes in Student Lifecycle Management-> Audits
© SAP AG
IHE102
11-19
1 1 .3 Re quire m ent Pa t t e rn – Require me nt
Se le c t ion
The requirement pattern serves as template for the individual requirement profile for
a student. To fill the requirement profile with “content”, the system must derive the
concrete requirements:
Organizational Unit
Requirement Pattern
Abstract Requirement 1
Abstract Requirement 2
Abstract Requirement 3
Where do I find the
concrete requirements
(= rule container) for
my abstract
requirement?
Requirement Profile
Abstract Requirement 1
Program of Study
Rule Container
(= Requirement)
Rule Module 1
(= Subrequirement 1)
Rule Module 2
(= Subrequirement 2)
- Subrequirement 1
- Subrequirement 2
Abstract Requirement 2
Abstract Requirement 3
© SAP 2009
The individual requirement profile for a student usually consists of several independent areas, which
we have described as structure of the audit requirements and mapped by a requirement pattern. (For
example, general university requirements and specific program requirements). The requirement
pattern will serve as a template for the individual requirement profile.
The individual requirement profile can be individualized per student by defining exceptions.
Subrequirements (= concrete rules) are NOT directly assigned to a requirement pattern but retrieved
by the system using selection rules. To fill the requirement pattern with concrete rules, you define
requirement selection rules for the abstract requirements in the requirement pattern. The (concrete)
requirements are stored in rule containers as rule modules and attached to the academic structure or
audit callup points.
Selection rules can be defined per
• Requirement selections: IMG-> Processes in Student Lifecycle Management -> Audits ->
Requirements -> BAdI: Requirement Selection
• Evaluation Path
© SAP AG
IHE102
11-20
1 1 .4 Re quire m ent s & Subrequire me nt s:
T opic Objec t ive s
After completing this topic, you will be able to:
Explain how to maintain concrete audit rules in the system
Understand the function of ”requirements“ and
”subrequirements“
Know about the function of ”auxiliary conditions“
© SAP 2009
© SAP AG
IHE102
11-21
1 1 .4 Audit – Re quire m ent s & Subrequirem e nt s
1
Requirement Catalog
Student
Program Completion Requirements
Set by the University
is registered for a program
and has booked a
specialization
B.A. : General requirements
B.A. : Specialization requirements
(e.g. Major requirements)
Requirement
Pattern
B.Sc.: General requirements
B.Sc. : Specialization requirements
2
Requirements & Subrequirements
Rule containers
and rule modules
Concrete rules e.g. Minimum credits per stage,
Mandatory modules, minimum semester credits
3
Compare = Audit
5
Individual profile
4
Audit Run
Academic work
taken by the student
© SAP 2009
© SAP AG
IHE102
11-22
1 1 .4 Re quire m ent s & Subrequire me nt s –
Re quire m ent s in Re quire m ent Ca t a log
Rule containers are the requirements which the system retrieves for individual
requirement profiles. Rule Containers:
contain rule modules (= subrequirements)
maintained for a requirement catalog version
rule modules are assigned for a catalog version
Requirement Catalog
Rule Container
-
Rule Module
Rule Module
Rule Module
(concrete) requirements are
represented by rule containers
and
Subrequirements
Rule Container
-
Rule Module
Rule Module
Rule Module
© SAP 2009
Rule containers:
• Are retrieved via an evaluation path or a BAdI, defined within the requirement pattern
• Contain rule modules
• Can link to the academic structure
• A requirement must be linked to a callup point for audits in order to retrieve it
Rule containers are maintained for a requirement catalog version:
• You first have to create the required rule containers. To create a rule container, you can use the
Requirement catalog maintenance transaction (PIQRLCATM or choose SAP Menu → Student
Lifecycle Management → Academic Structure (Curriculum) → Requirement Catalogs → Edit
Requirement Catalog.)
• Here, you can:
- Create and change requirements (= rule containers)
- Create, change and attach subrequirements to rule containers. You use the Subrequirement
Manager to assign existing subrequirements and auxiliary conditions
• You may only assign a requirement (rule container) to one requirement catalog.
For more information about Rule Containers, please see chapter about Rules & Regulations (VSR).
© SAP AG
IHE102
11-23
1 1 .4 Re quire m ent s & Subrequire me nt s –
Re quire m ent s Re la t ed t o Aca de m ic St ruc t ure
Requirements:
College of Liberal Arts (O)
General Grad.
Req. (RC)
Department of History (O)
M.A. in History (SC)
Major in History (CG)
Program Req.
(RC)
Major Req. (RC)
Minor in History (CG)
Minor in History (CG)
Department of Biology (O)
Minor in Biology (CG)
Minor Req. (RC)
Requirements can belong to different levels in the academic structure.
© SAP 2009
Link the rule containers with respective academic objects (for example, link the rules for a biology
major with a module group (CG)).
Therefore, you create a relationship 509 between academic structure objects and rule containers and
define the relevant callup point (e.g. “completion of degree audit”).
If required, you can also define relevant parameters, such as stage of a program.
You can also assign a rule container only to a callup point (such as „degree audit – completion“). In
this case, the requirement is valid for the degree audit process, independent from any program of
studies, etc.
© SAP AG
IHE102
11-24
1 1 .4 Re port for Cre a t ion of Audit Rule
Conta ine rs
You can use a report (transaction ‘PIQRCGENERATE’) to automatically create Rule Containers
and have them attached to objects in the academic structure.
Use case: During the initial implementation of degree audit, you generate rule containers for each
academic program that will be included within a requirement catalog.
Rule Containers can be created and assigned only to the academic objects:
Internal Qualification (CQ)
Organizational Unit (O)
Program of Study (SC)
Module Group (CG)
Requirement Elements to Objects
You can assign the requirement elements to the rule container, based on the selected object. The system
creates and assigns new rule containers for objects that do not already have one
Validity Dates
To use the start/end dates of the selected object as dates for the RC select Implicit Validity Dates.
To specify your own start/end dates, select Explicit Validity Dates. Enter your dates in the fields below.
© SAP 2009
Note: When using this report, an Audit type has to be selected. Depending on the entry, the
parameter field is hidden/displayed.
Object Selection: Enter the following mandatory data (the Object Name is visible after data entry):
• Object Type
• Object ID
• Evaluation Path: selects the objects to which the rule container is assigned.
Optional: If you enter ‘module group category’ as selection option, then RC’s will only get created
for the module groups that fit that Module Group Category.
Rule Container-Related Data
• Enter an audit type. For certain audit types, a Parameter field is displayed. This field is
mandatory.
• Enter the process part. The process part Completion of Process is selected by default.
• Enter the requirement catalog and version you want to assign to the rule container (optional).
© SAP AG
IHE102
11-25
1 1 .4 Re quire m ent s & Subrequire me nt s –
De finit ion of Subre quire m ent s
A subrequirement is created as rule module within a rule container:
Educ. Requirements
6 Credit Hours in English
Rule Module
Rule Container
(RC)
6 Credits in History
You can define two types of subrequirements:
1. Index-dependent subrequirements:
In your rule you use a performance index to define the subrequirement
Example: Student has to book at least 30 credits
2. Index-independent subrequirements:
You use a condition to define the subrequirement
Example: Student has to pass module “Biology 100”
© SAP 2009
A subrequirement describes the prerequisites students have to fulfill to pass a (concrete) audit rule.
This is checked during an audit run. A subrequirement is defined by
Rule Module:
• One rule container can contain several rule modules
• A rule module describes the audit rule. To implement the rule logic, you can use the following:
- Performance index (in case of an index-dependent subrequirement): A subrequirement can
use the Performance Index tool to calculate figures, such as “Amount of credits received”,
“Number of modules booked”
- Selection Method: If you want the SAP system to generate module proposals for a
subrequirement, you can use the Selection Methods tool to select the right modules.
Examples: Only modules from discipline “ART”
- Conditions (in case of an index-independent subrequirement): A condition can be used to
determine a certain work the student has to do. Example: Student has to submit a thesis
- Parameters for performance indices, filters and conditions
On the requirement catalog maintenance screen, you can assign existing subrequirements to catalog
versions or create new subrequirements. You can also access this dialog transaction from
Customizing.
© SAP AG
IHE102
11-26
1 1 .4 Re quire m ent s & Subrequire me nt s –
T a sk of a Subrequire me nt
Subrequirements help to fulfill two functions of the audit:
The audit rule which needs to be compared to the student’s work is defined
During the audit, student’s existing academic work is compared against the
audit rule.
Modules which are required to fulfill the subrequirement are proposed
If a subrequirement is not fulfilled yet by the student, suitable academic work
can be proposed.
© SAP 2009
During an audit, subrequirements are compared with the student’s academic work:
• All academic work is selected (= “academic work selection”)
• Only work is counted which is suitable to fulfill the requirement
• A decision is taken whether the subrequirement is fulfilled, not fulfilled or still in progress
A subrequirement can help advising the student by proposing missing modules:
• Modules are selected and proposed by the system which are suitable to fulfill the subrequirement
(= “module proposal”)
• The student or the advisor is able to book the outstanding modules
An Audit Filter for External Transcript GPA is available. This filter allows audit sub-requirements
to be easily created that check that an applicant's external GPA is sufficient.
• BAdI definition HRPIQ00RLCON and BAdI implementation HRPIQ00_CON_GPACHK.
• Sub-requirement condition SAP5.
In addition, an Audit Filter for Ext. Transcript Class Ranking is provided. It allows audit subrequirements to be easily created. Audit sub-requirements check that an applicant's class ranking or
percentile is sufficient.
• BAdI definition HRPIQ00RLCON and BAdI implementation HRPIQ00_CON_RANK
• Sub-requirement condition SAP4.
The Audit Filter for Ext. Test Score Comparison allows audit sub-requirements to be easily defined.
Audit sub-requirements check that an applicant has an external test score (or sub-score) that falls
within a desired range.
• BAdI definition HRPIQ00RLCON and BAdI implementation HRPIQ00_CON_SCORECHK.
• Sub-requirement condition: SAP6.
© SAP AG
IHE102
11-27
1 1 .4 Re quire m ent s & Subrequire me nt s –
Aux ilia ry Condit ions
An auxiliary condition is used to define rules depending on the aggregration of
subrequirement results. It can aggregate performance indexes from the lower levels or
calculate new indexes from all academic work assigned to lower levels of the requirement
profile.
University Req.
Auxilliary
conditions
GPA 2.0
Prog.Req.
Group I
6 Credits
in residence
Take ENG101
3 Credits in X
6 CRH in Hist.
Major Req. 80 % fulfilled
© SAP 2009
In some cases rules on the requirement level need to be fulfilled in order to complete the audit
successfully, e.g. a major requires a minimum average grade or a total number of earned credits.
With auxiliary conditions, you can also define rules on requirement levels. You can create rules
which consider subrequirement rules. The rules on requirement levels can be defined using indices
which are calculated e.g. from grades and credits from the students academic work.
Technically, auxiliary conditions are represented by rule modules. They do not have filters nor do
they have selection methods. No academic work is assigned to them directly in an audit run.
Auxiliary conditions use a tool called Key Figures:
• Key Figures uses calculation methods (like Performance Indices does) for the calculation.
• In contrast to performance indices key figures are not dependent on academic work. In case you
need an academic work dependent key figure, you refer the key figure to the performance index
created before. The performance indices can be seen as a special key figure as they enable you to
perform calculations only for module bookings.
• Output of Key Figures can be used as input for Key Figures on higher levels
• Possible calculations with Key Figures:
- Percentages of fulfilled subrequirements
- Other indices, such as GPA including weighting; GPA totals
- Conversion of Credits Points, Percentages to Grades (with help of scales)
Example 1: Module ENG101 is used for “Take ENG101”, MATH100 and MATH101 are used for
“3 credits in X”, and HIST100 and HIST101 are used for “6 CRH in Hist.”. At Group I an auxiliary
condition is defined: 6 CRH out of all these modules must be earned in residence.
Example 2: 2 of 3 subrequirements of a requirement have to be fulfilled
© SAP AG
IHE102
11-28
1 1 .4 Re quire m ent s & Subrequire me nt s –
Re sult s on Aggrega t ion Le ve ls
You may not only need rules on aggregation levels, but also results. Auxiliary
Conditions can be used to calculate results on aggregation levels:
Results of subrequirements are evaluated and a result on requirement level is derived.
Example:
”A requirement is fulfilled if x % of the subrequirements below are fulfilled.“
Standard implementation:
100 % of subrequirements
must be fulfilled
A result per requirement can be
derived by the system (fulfilled,
failed). A requirement is only fulfilled
if all (100%) of the subrequirements
below are fulfilled by the student.
Customer implementation with
Auxiliary conditions and key figures
to define a rule like:
x % (x < 100) of subrequirements must
be fulfilled
Not 100% of all subrequirements must be
fulfilled to fulfill the requirement, but only 4
of 5 subrequirements have to be fulfilled.
© SAP 2009
An audit result is usually positive if all subrequirements and requirements are fulfilled. A
requirement is fulfilled if all requirements or subrequirements below are also fulfilled.
If an automated audit process is executed (e.g. for assessment processes), also the results of the
requirements (fulfilled, failed …) have to be determined by the system.
To calculate results on aggregation levels, Student Lifecycle Management distinguishes between
two different cases:
• 1) The result on the aggregation level is positive (= fulfilled) if all (= 100%) of all
subrequirement or requirements below this level are fulfilled.
• 2) The result on the aggregation level is positive (= fulfilled) if a certain percentage (e.g. 80%) of
all subrequirement or requirements below this level are fulfilled.
The implementation provides two concepts for this check:
• 1) In case 100% of all lower level rules must be fulfilled, you can use the standard
implementation provided within a rule container on the Rule Module tab. This is called “implicit
additional condition” and checks if 100% of all rules below are fulfilled.
• 2) In case only x% of lower level rules must be fulfilled, you use the Auxiliary Conditions. They
can be defined and integrated to requirement catalogs. They will be checked if the implicit
additional condition is switched off.
© SAP AG
IHE102
11-29
1 1 .4 Inc rem ent a l Assignme nt of Ac ademic
Work
Typically universities want to restrict the usage of the academic work during the
evaluation by the Degree Audit. Reason:
If an index-dependent subrequirement (e.g. module x has to be completed with a
minimum grade) treats all academic work of a student as required, any “extra”
academic work is also used by this subrequirement and is no more available for
usage by other subrequirements. This would lead to a wrong audit result.
Therefore, if academic work can be ‘used’ only once, it is essential that no subrequirement ‘uses’ more work than it actually needs:
Student has taken 6 Biology level 100 courses
Sub-requirement is for 3 Biology level 100 courses
Without incremental assignment all courses that fit into the criteria of the requirement will
be assigned to it (i.e. all 6 courses in this case).
Through incremental assignment, only the first 3 courses which the system finds are
assigned which leaves the other 3 courses available for other sub-requirements.
Incremental assignment is only relevant for Index-Dependent subrequirements
and must be activated in the IMG.
© SAP 2009
Business scenario relevant for incremental assignment of academic work:
• When an index dependent subrequirement is evaluated in a system without incremental
assignment of academic work, all academic work done by the student is used.
• Incremental assignment means that the system uses academic work one by one. Once the
subrequirement is fulfilled, it stops further assignment of academic work.
• Once the concept of incremental work assignment is used, it is necessary to determine whether or
not particular sub-requirements can share assigned academic work.
© SAP AG
IHE102
11-30
1 1 .4 Re -usabilit y of Ac a de m ic Work
Preparatory Steps:
1. define various reuse groupings via transaction ‘PIQSUBREQGRP’
2. Possible settings for individual subrequirements
U (Unlimited Reuse) – Academic work assigned to the subrequirement can be used by
other subrequirements. Academic work assigned to other subrequirements can be used
by this subrequirement. This is the default behavior (subrequirements with no reuse
setting will be treated as type ‘U’).
Z (Zero Reuse) – Academic work assigned to the subrequirement cannot be used by
any other subrequirement (except those of type ‘U’)
G (Reuse Within Grouping) –Academic work assigned to this subrequirement can only
be shared with other subrequirements in the same group, or those of type ‘U’. If no
specific group value is assigned, the subrequirement is treated as type ‘Z’. An additional
assignment with the specific group value needs to be done.
3. Assign resuse groups to subrequirements via Requirement Catalog Maintenance
© SAP 2009
© SAP AG
IHE102
11-31
1 1 .4 Re -usabilit y of Ac a de m ic Work
w /Priorit iza t ion
Once incremental work assignment is
introduced, it is necessary to determine
whether or not particular sub-requirements can
share assigned academic work. Options are:
Some sub-requirements should not allow academic
work to be shared
Some sub-requirements should allow academic
work to be shared
There are hybrid models as well
Overall Result
B.S. Program Requirements
90 CRH
1 Level 100 Biology Course
1 Level 100 Chemistry Course
Biology Major Requirements
3 Level 100 Biology Courses
3 Level 200 Biology Courses
Unlimited re-usability
3 Level 300 Biology Courses
Zero re-usability
Chemistry Minor Requirements
Re-usability within grouping
2 Level 100 Chemistry Courses
Re-usability within grouping
2 Level 200 Chemistry Courses
© SAP 2009
Business scenario example 1: you have sub-requirements in which the assignment of academic work
should not interfere with other subrequirements:
‘Total Earned Credits > 90’. In this case, academic work assigned to the subrequirement should still
be available for assignment to other subrequirements.
Business Scenario example 2: You have subrequirements that should not share any academic work:
2 subrequirements:
• Programm requirements: Complete 1 course of the Biology course level 100
• Biology Major Requirements: Complete 3 courses of the Biology course level 100
2 subrequirements:
• Programm requirements: Complete 1 course of the Chemistry course level 100
• Chemistry Minor Requirements: Complete 2 courses of the Chemistry course level 100
2 subrequirements:
• Biology Major Requirements: Complete 3 courses of the Biology course level 200
• Chemistry Minor Requirements: Complete 2 courses of the Biology course level 200
Usually, the rules of an institution would not allow a single course to be used for two different
subrequirements, even when a single course is part of two different Module Groups. See below the
explanations for the displayed subrequirements:
• Subrequirement ‚90 CRH‘ checks if the sum of filtered academic work achieves at least 90 CRH.
The used academic work can be reused by other subrequirements with unlimited re-usability as
the maintained category is ‘unlimited re-usability.
© SAP AG
IHE102
11-32
• Courses like ‚Biology 101‘ can be used to fulfil the subrequirements ‚1 Level 100 Biology
Courses‘ or ‚3 Level 100 Biology Courses‘ as both are maintained with the category ‘Reusability within grouping’ and have assigned the same group.
• Courses like ‚Chemistry 101‘ can be used to fulfil EITHER the subrequirement ‘1 level 100
Chemistry Courses’ OR ‘2 Level 100 Chemistry Courses’ as one is maintained with the category
‘Re-usability within grouping’ and the other one with the category ‘Zero re-usability’.
• The course ‚Biochem 201‘ can be used to fulfil EITHER the subrequirement ‚3 Level 200
Biology Courses‘ OR ‚2 Level 200 Chemistry Courses‘ as both are maintained with the category
‚Zero re-usability‘.
• How about the course ‚Biology 301‘?
- This course will be used for subrequirement ‚3 level 300 Biology Courses‘ and no other
subrequirement as the maintained category is ‚zero re-usability‘. No other subrequirement on
this slide would be fulfilled by the usage of this course as the requirement is to complete a
course with level 300.
© SAP AG
IHE102
11-33
1 1 .4 Priorit iza t ion of Ac ade m ic Work
To give a sequence for the assignment/ use of the academic work it is possible to prioritize
the subrequirements
the valid values for the prioritization are in the range bettweeen 1 - 9999.
Priority can be maintained in the header of a subrequirement via requirement catalog
maintenance
Preparation for Prioritization in Customizing (SLCM
Requirements
Subrequirements):
Processing in SLCM
Audits
Set a default priority level for subrequirements. Subrequirements with no specific priority
setting will use this value.
Sort Order for Subrequirements: Specify whether priority is “low to high” or “high to low”.
No value (default setting) – Higher number priorities are evaluated first
‘X’ – Lower number priorities are evaluated first
© SAP 2009
© SAP AG
IHE102
11-34
1 1 .4 Audit s - Link Abst ra c t & Conc re te
Re quire m ent s
CUSTOMIZING /
SAP EASY ACCESS
CUSTOMIZING
Overall Result
Abstract Requirement:
Univ. Requirements
Rule
Container
Ex. Check for degree
Audit or admission
requirement
Abstract Requirement
Program Requirements
Sub Requirement
Ex. Fullfillment of
Mathematics prerequisites
Abstract Requirement
Major Requirements
Abstract Requirement
Major Requirements
Index-dependent
subrequirement
Index-independent
subrequirement
Auxuliary
Condition
Requirement
Pattern
© SAP 2009
© SAP AG
IHE102
11-35
1 1 .5 Re quire m ent Profile T e m pla te s:
T opic Objec t ive s
After completing this topic, you will be able to:
Understand the usage and benefits of requirement profile templates
Create requirement profile templates for the generation of individual
requirement profiles
© SAP 2009
© SAP AG
IHE102
11-36
1 1 .5 Re quire m ent Profile T e m pla te s –
Busine ss Sce na rio
In order to perform an audit (stage audit, degree audit, etc.) for a student,
an individual requirement profile needs to be created beforehand.
You can create the individual requirement profile
either by evaluating the requirement
pattern found in the requirement catalog
for the student and retrieving audit
requirements with help of derivation rules
or from a requirement profile template
which contains all applicable rules
directly as (sub-) requirements
+ easy definition and maintenance
+ definition of different profile structure
for different programs of study
- Flexibility in rule definition is limited
+ high flexibility for rule definition
- Complex maintenance
© SAP 2009
In order to allow easier maintenance of audit rules, Student Lifecycle Management allows you to
create requirement profile templates. They collect all rules which are applicable for a certain audit
(e.g. degree audit) and a program of study. Requirement profile templates are somehow a static
template for individual requirement profiles, but allow a flexible derivation of requirements for
booked specializations.
If there is the case where
• Programs are clearly structured and only few choices are possible
• Requirement structures differ from program to program
• Audit requirements are more or less fixed (for example, admission audit: requirements for
admission (missing documents, etc.) are clearly defined and do not offer much flexibility)
For these cases an easier way to build up requirement profiles is offered by the requirement
profile templates:
• You can see what a requirement profile for a certain student (registered for program P with
specialization S) or a certain audit task (admission audit) will looks like.
• The requirement structure can be different for each program of study, while the requirement
profile structure is always the same if you use one requirement pattern to retrieve the individual
requirement profile.
© SAP AG
IHE102
11-37
1 1 .5 Re quire m ent Profile T e m pla te s –
Ove rvie w
Requirement profile templates can be created for programs of studies. They collect
all requirements (requirement elements and subrequirements) which describe the
rules for a certain audit process.
Requirement
profile
template
Program of
study
When individual requirement profiles for students are created, the requirement profile
templates can be used to generate the individual requirement profiles.
Requirement
profile
template
Requ.
Profile
Requ.
Profile
Requ.
Profile
© SAP 2009
When individual requirement profiles for students are created, the system evaluates depending on
the program of study if requirement profile templates should be used or not.
If templates are used, the system takes them over into individual requirement profiles. You can
structure the requirement profile templates you create like you want the personal requirement
profiles of students to be structured.
In contrast to profile generation by derivation from requirement catalogs, no derivation of
requirements (rule containers) and subrequirements occurs, because requirements and
subrequirements are already included in the requirement profile templates.
Example:
• During the generation of requirement profiles for students without requirement profile templates,
requirements may be picked out of several catalogs and the requirements may even belong to
different versions. This generation is very complicated and it is not possible to see how a
requirement profile for a certain student will look like. There are programs of study which may
need this flexible derivation. But there are other cases where programs are clearly structured and
only few choices are possible. The checklist in the admissions audit is also more or less fixed.
For these cases an easier way to build up requirement profiles is provided with the requirement
profile templates.
© SAP AG
IHE102
11-38
1 1 .5 Re quire m ent Profile T e m pla te s – Progra m
a nd St udent At t ribut e s
Program of Study:
You must define per program of study if requirement profile templates should be
used:
Flag in the Requirement Catalogs infotype
Student attributes for requirement profile templates:
You can restrict the use of a template to specific students
Specify student attributes in the requirement profile template and thus restrict it
to certain students
Use BAdI to compare requirement profile templates with student attributes
© SAP 2009
If you want the system to use templates and not the standard derivation when it generates individual
requirement profiles, you must specify that a template should be used for a certain program of study:
• Use the program catalog transaction to edit the programs of study in order to define usage of
templates (Requirement Catalogs infotype (1778) of the program of study).
During the generation of individual requirement profiles this attribute is taken into account.
© SAP AG
IHE102
11-39
1 1 .5 Re quire m ent Profile T e m pla te – Feat ure s
Program of study
RPT should
be used
With the requirement profile template, you can
Change the requirement structure = Add or
change requirement elements
Add or create subrequirements
Create subtemplates for specialization
Requirement
Profile
Template
Student
attributes
Evaluate student attributes and maintain different
requirements
Sub
Template
© SAP 2009
The transaction for creating and editing requirement profile templates can be found in the SAP
Menu under Student Lifecycle Management
Academic Structure Requirement Catalogs
Edit Requirement Profile Templates.
Requirement profile templates consist of the same elements as an individual requirement profile:
• Requirement elements to structure the profile
• Subrequirements which are the concrete rules. They belong to a requirement element.
When you create the templates for requirement profiles, you can specify student attributes in the
template and thus restrict use of a template to specific students, such as international students. These
student attributes are filter-dependent implementations of the business add-in Requirement Profile
Templates Based on Student Attributes. (See audit Customizing.)
Furthermore, Student Lifecycle Management allows you to maintain subtemplates, i.e. templates
within a template. With subtemplates, you are able to achieve flexibility for the definition of
requirements for specializations, as students are usually allowed to select their specialization. In this
case, only those requirements which belong to the selected specialization(s) are derived for the
individual requirement profile.
Student attributes can also be considered for the creation of requirements profile templates. This
allows you to define different rules for different student categories, like international students.
Preparation: Ensure that basic customizing for audits is available. You can find the audit
Customizing under Student Lifecycle Management
Student Lifecycle Management Processes
Audits . Please complete Customizing for Requirement Profile Templates and for maintenance of
requirement elements under Requirements
Requirement Patterns
Define (Abstract)
Requirements.
© SAP AG
IHE102
11-40
1 1 .6 Audit Run: T opic Objec t ive s
After completing this topic, you will be able to:
Understand how an audit run works
Create an individual requirement profile
Explain how the audit run result is derived
Use different audit run user interfaces
© SAP 2009
© SAP AG
IHE102
11-41
1 1 .6 Audit Run – Ove rvie w
Requirement Profile:
First you define the requirements that the student must fulfill within a certain program of study.
This is done by creating a requirement profile for the student and registered program of study.
Create requirement profile (based on standard rules)
Adapt requirement profile for student
Audit Run:
Second, you determine if the academic work completed by the students meets the
requirements. This is called audit run.
You can start several audit runs for the same profile. Each audit run result can be stored.
Use different profile types and execution modes for audit run to support different types of
audit runs, such as simulation audit runs for advising students and final audit runs.
© SAP 2009
In an audit run, all subrequirements (= rule modules) from the requirement profile are checked
against the student’s academic work. All module bookings with a specific status are selected as input
for the audit check. Example:
• Module booking statuses considered: Booked, Completed with success, Preselected
• Module booking statuses not considered in the audit run: Failed, Canceled
You can determine which subrequirements the student satisfies or not, and which subrequirements
the student is still working on. You can have the SAP system support the evaluation procedure or
you can evaluate the data manually.
The audit execution mode determines the significance of an audit result. You can use the execution
mode to distinguish between official audit results and the results of audit simulation runs. The
execution mode defines allowed requirement profile types for execution modes and module booking
statuses relevant for execution modes.
For example, you use a simulation audit run to advise your student how his or her standing is toward
a degree. In this case, you may not only take all modules which have been completed successfully
into account, but also modules which are only booked.
You can find the Customizing activities in the Student Lifecycle Management IMG under Student
Lifecycle Management Processes → Audits → Audit Runs.
© SAP AG
IHE102
11-42
1 1 .6 Audit Run – I ndividua l Require me nt
Profile
Individual Requirement Profile:
You need to create a requirement profile before you execute an audit.
An audit run is based on a requirement profile which is generated individually for each
student.
1) You generate profiles from the requirement pattern of the main requirement
catalog assigned to the student.
2) If you want to simplify your maintenance of requirement profiles, you create
requirement profile templates in order to create individual requirement profiles.
© SAP 2009
The profile combines all concrete subrequirements which are valid for
• The program the student is registered in (= degree which should be reached)
• The chosen audit execution mode
• The requirement profile type
• Requirements (= rule containers) as created for the requirement catalog are not displayed in the
requirement profile!
A student can have several requirement profiles.
• Further audit runs for this student can be based on one profile.
• Every requirement profile must be assigned to a specific requirement profile type. The profile
type represents the purpose of a requirement profile. For example, you can create a different
profile type for official audits and simulation audits.
To create an individual requirement profile, you
• Start the report program for assessment processes: Transaction PIQAUD_MP_CP if the audit is
related to an assessment process
• Requirement profiles which are not related to assessment processes can be generated via
Transaction PIQAUD_MP_CS.
• You can also create requirement profiles manually using the BSP application. In this application,
you can create exceptions and adapt the profiles to your individual requirements.
© SAP AG
IHE102
11-43
1 1 .6 Audit Run – Cre a t e Re quire m ent Profile
Requirement Catalog A
Version 2005
Main catalog for student/study
Requirement Pattern
Structure of Pattern: Bachelor Degree
Element 1: General Requirements of University
Element 2: Program Requirements
Assigned to
student or
derived by
system
- Requirement selection
- Evaluation path
ST,CS,
Specializations
Academic Structure
- Org. Units
- Program ...
Rule Container (= requirement)
Rule Modules (= subrequirement)
Requirement Profile for:
Student “Harry”, Program “BSc in Biology”
Structure of Pattern: Bachelor Degree
Element 1: General Requirements of University
Subrequirement 1.1
Subrequirement 1.2
Subrequirement 1.3
Element 2: Program Requirements
© SAP 2009
Requirement profiles are created according to the following logic:
• First, the system determines the requirement pattern for the main requirement catalog defined for
the student in the student file.
• If the student is not assigned a main requirement catalog, the system searches for one using the
evaluation path assigned to the audit type in question.
• Then, by reading the requirements of this requirement pattern, the system derives the rule
containers (concrete requirements) and rule modules (subrequirements) for the assigned
requirement selections and evaluation paths. Subrequirements can differ in the different
requirement catalog versions. The system therefore chooses only those subrequirements which
are contained in the main requirement catalog version assigned to the student. If the student is not
assigned a main requirement catalog, the system uses the standard version of the main
requirement catalog it derived.
• In this way, the system assembles the concrete requirements and subrequirements for a student in
the requirement profile.
In case you are using requirement templates, the content of the template is directly used as input for
requirement profiles. Please see the next topic for more information.
© SAP AG
IHE102
11-44
1 1 .6 Audit Run – St a t us for I ndividua l
Re quire m ent Profile s
Status for individual requirement profiles
The individual requirement profile of a student can have the status
Complete
or
Complete =
An individual requirement profile is
complete if the conditions for
incomplete do not apply.
Incomplete
Incomplete =
A requirement element is of category
”subrequirement“
+ no subrequirement exist when the
individual requirement profile is
generated.
No audit run can be performed
© SAP 2009
A status is set for the individual requirement profile which is generated for a student when an audit
is to be performed.
The status tells you whether you can perform the audit if the requirement profile is complete, or the
requirement profile of the student could not be completed. If it is incomplete, there is apparently a
rule (i.e. a subrequirement) missing. The system determines an individual requirement profile as
“incomplete“ if there is a requirement element in the profile which has the requirement category
“subrequirement“, but no subrequirement has been added to it. The system would expect a
subrequirement (= concrete rule) to be part of the individual requirement profile for this requirement
element.
You are not allowed to run an audit if the individual requirement profile for the student is
incomplete.
Since the status of the requirement profile depends on the attribute requirement category (which is
maintained for a requirement element), you should check your Customizing for requirement
elements under Student Lifecycle Management → Student Lifecycle Management Processes →
Audits → Requirements → Requirement Patterns → Define (Abstract) Requirements.
Note: Individual requirement profiles which have been created in releases >SLCM 6.00 are
automatically set to status complete.
© SAP AG
IHE102
11-45
1 1 .6 Audit Run – Re sult
An audit run is performed either
as part of an
assessment process
in a mass run
in a single run
Result of Audit
A result is defined for each audit rule (subrequirement level)
Results can be defined on aggregation levels (requirements)
An overall result can be calculated automatically (fulfilled, failed)
The overall audit result can be used as input to an assessment process
The result can also be set or changed manually
© SAP 2009
The audit function evaluates each subrequirement against the student academic work and returns a
result if the subrequirement is fulfilled or failed.
An overall result for an audit run can be determined automatically by evaluation of the
subrequirements and auxiliary conditions of the requirement profile. Therefore rules must be
maintained for the top requirement to evaluate the results of all dependent subrequirements or
requirements.
If audits are used within an assessment process the audit runs have to deliver exactly one overall
result which can be interpreted.
To start an audit run, you have the following options:
• 1) If the audit is embedded into an assessment process, start the process-dependent audit
transaction (SAP Menu → Student Lifecycle Management).
• 2) If the audit is process-independent, you can start an audit as mass processing run from the SAP
Menu → Student Lifecycle Management).
• 3) You can start a single audit run using a web frontend. In this case, you start the BSP
application PIQ_AUDIT (see next slide).
© SAP AG
IHE102
11-46
1 1 .6 Audit Run – We b U se r I nt e rfa ce
Student Lifecycle Management offers a web user interface based on business server
pages for administrative staff, advisors (experts) or students which supports
The creation and maintenance of requirement profiles
Maintenance of exceptions
Execution of audit runs (degree audit, stage audit)
Different views depending on the audit type and role (expert, student)
Different actions are available to different persons and roles, e.g. requirement profile
editing, audit editing, display only
© SAP 2009
If you wish to run a single audit run, you would also use the BSP Application (with EHP 5, this
functionality will become delivered as Web Dynpro application):
• In Customizing for Student Lifecycle Management choose Student Lifecycle Management
Processes → Audits → Adjustment of to set up the web interface
• User Interfaces -> Set Up Views of BSP Applications
• Use transaction SE 80 to start the BSP Application “PIQ_AUDIT”.
• The user interface for audits (run a single audit) supports different views which enable you to
adapt it to various roles, e.g. student in self service, advisor, staff. Different actions are available
for different persons and roles (students, experts, extended maintenance mode).
• A view is displayed for each audit type, process reference and role.
• The standard system contains “degree audit”, “stage audit” and the above mentioned roles
• A view contains a set of actions and exceptions: The exceptions and actions refer to requirement
profile editing, audit editing or are independent of these.
• Example: You can allow a student to display an official audit through the web but not to change
it.
© SAP AG
IHE102
11-47
1 1 .7 Adm ission Audit – T opic Obje c t ive s
At the conclusion of this topic, you will be able to:
Explain the concept of Admission Audit
Show how an application can be checked against
admission requirements
Understand the integration between Student Lilfecycle
Management and Records Management
Explain how missing documents can be requested
automatically from the applicant
© SAP 2009
© SAP AG
IHE102
11-48
1 1 .7 Adm ission Audit – Ove rvie w
A student is applying for admissions to a Program of Study. The Program
of Study has specific requirements which must be fulfilled by the
Applicant for admissions.
You can perform admission
audits to check admissions
requirements automatically.
The system automatically
recognizes and duns
outstanding requirements
such as missing documents.
An assessment process is
created and rules of the
requirement catalog are
checked with an audit.
You can manage inbound and
outstanding documents by
connecting to SAP Records
Management (RCM).
Advantages: Transparency, Tracking Options, Reduced Paper
Processing, Improved Response Times
© SAP 2009
The admission process supports the decision process with automatic checks.
Administrative or academic prerequisites can be checked via an “admissions audit”. Regulations
which apply to the admission of an applicant for a certain Program of Study can be kept as rules
within a Requirement Catalog. These are checked against the applicant data within an admission
audit, which is embedded within an assessment process (also see Chapters: “Assessments,
Examination & Grading).
Furthermore, integration with Records Management allows you to automatically check the
application for outstanding requirements, such as missing documents.
Note
• The Admission Audit functionality has to be activated explicitly per Program of Study.
• Records Management has to be activated separately in Customizing and explicitly per Program
of Study
• Process flows can be defined for each customer individually
© SAP AG
IHE102
11-49
1 1 .7 Adm issions Audit – Proc e ss Flow
Complete customizing for
-Requirements
-Audits
-Assessment processes
Complete customizing for
-Dunning inbound
correspondence
-Integration with
Records Management
Create assessment
Preparation / Customizing
Student applies for
Program of Study
Admissions Audit process flow
Optional – Dunning run to
remind student of
missing requirements
If conditions (checklist) are
met => execute
Admissions
Update student
test scores, transcripts,
assign documents from
Records Management
Etc.
Perform Audit
© SAP 2009
Preparation:
• You have made the required customizing settings using the path: Student Lifecycle Management
→ Processes in Student Lifecycle Management Processes → Admissions, Registration, and Deregistration
• Complete customizing settings for Dunning Inbound Correspondence using the path: Student
Lifecycle Management → Processes in Student Lifecycle Management → General Settings →
Correspondence → Inbound Correspondence.
• Complete the customizing settings for Admission Audits using the path: Student Lifecycle
Management → Processes in Student Lifecycle Management → Audits.
• Before you can use SAP Records Management, you must activate the component and make the
necessary settings. You make these customizing settings using the path: Student Lifecycle
Management → Master Data in Student Lifecycle Management → Students → Integration of
Records Management.
• You activate the Assessment Process Function for each Program of Study by setting the “Use
Assessment Process” indicator. An assessment for Audit Type “Admission” is created and linked
to the Program of Study.
• Once a student has applied for a Program of Study the Admissions Audit can begin.
© SAP AG
IHE102
11-50
1 1 .7 Adm issions Audit – Assessm e nt Proc esse s
a nd Audits
How to check requirements during the Admissions process:
“Assessment processes” are used to integrate admission audits into the process of
admissions
Assessment processes link requirement profiles and audit runs for admissions
You can track the assessment process via a status
Admissions Audits are performed to check requirements
Checklists are created for each application
Automatic dunning of outstanding requirements is supported
Status administration of the application
the application processing
customer status
can be used for each step within
Example:
Checklist / Audit result = “requirements are all met”
Admissions application status
= “admitted”
© SAP 2009
An Assessment Process is based on an Assessment. The Assessment is represented by the Object
Type CE and linked to a Program of Study (or another Object within the Academic Structure) via a
relationship. In order to prepare an Admissions Audit, it is necessary to create and link an
Assessment for Admissions Audit.
An Assessment Process is always linked to one student and one assessment.
When you activate the admissions audit function for a Program of Study, the system automatically
creates an Assessment Process for admissions audit with the requirements that have been defined for
this Program.
You can display the Assessment Process via the [Assessment Processes Tab] in the Student File.
This allows you to monitor the status of the Assessment Processes.
You use the “Edit Admission” function in the Student File, and not the “Edit Assessment”
transaction for Admissions.
Note: Not all functions of the assessments can be used for admissions audits:
• You do not use scheduled assessments
• You do not create registrations for admission audit assessments in the Edit Assessment Process
transaction. Registrations are created automatically within the Admissions Process.
© SAP AG
IHE102
11-51
1 1 .7 Adm ission Audit – Chec k list s
How to check requirements for the admissions process:
Checklists are represented by requirement profiles
A requirement profile is the collection of all applicable rules for this applicant and program
of study for admission
The requirement profile is derived from a requirement pattern and requirements within a
requirement catalog or a requirement profile template
–
Example: the requirement profile consists of general requirements for admission to this
university, and requirements specific to the program of study the applicant applied for
Requirements can be made relevant for dunning => e.g. missing documents can be
requested from the applicant
Checklists can be edited by several persons
© SAP 2009
Requirement Profile:
• The (individual) Requirement Profile has to be derived for each applicant for the purpose of an
Admissions Audit. It is built from the Requirement Pattern, which maps a specific set of
academic requirements in a rough structure and serves as templates for the individual
Requirement Profiles. According to derivation rules, the concrete requirements (rules) are
retrieved from a Requirement Catalog.
• Another way to build an individual Requirement Profile is to use the requirement template
function. In this case, the template is built as sample a Requirement Profile, and requirements or
rules are directly attached to the template, instead of being retrieved via an Evaluation Path. The
template is then adopted when a Requirement Profile is generated for an Applicant or Student.
Checklist: Working steps of checklists depend on the customer status.
• You can manually check an element of the checklist.
• You can let the system audit define which element has been met and which has not.
• The User can “override” the system result (i.e. waiving a requirement).
© SAP AG
IHE102
11-52
1 1 .7 Adm issions Audit – Link t o Rec ords
M a nagem ent
© SAP 2009
You can manage the documents you receive and the ones that are missing by connecting to SAP
Records Management. Documents relevant for the admissions application, or later during the
student’s lifecycle, can be scanned and stored there.
If you wish to use SAP Records Management, you must configure the system accordingly.
You can use transaction ORGANIZER to access SAP Records Management.
In Records Management, documents can be associated directly via Load Local File, or scanning etc.
The integration with Records Management offers institutions the possibility to create a file for
students in Records Management. The process to generate such a file is started in the Student File of
Student Lifecycle Management.
Managing the documents around the Admission Process (e.g. Transcript of high school, Certificates
of further qualifications…) with Records Management allows you to check for outstanding
documents needed to complete the Admissions Process and to track the document history of an
application.
© SAP AG
IHE102
11-53
1 1 .7 Adm ission Audit – Adm ission Audit &
Dunning
Admissions Audit compares Master Data of the
Applicant (such as External Academic Work from
Transcripts, Test Results, etc.) with the
requirements for admission to the Program.
The checklist shows which elements have been
met or not met.
Missing documents can be requested if the
relevant checklist element is not met (dunning).
For this case, you set the “reminder” flag.
Once requirements are met the Admission can be
executed – (or otherwise).
© SAP 2009
With an Admissions Audit Run, the Admissions Officer checks if all requirements are fulfilled and
if a certain document is stored in the student record in Records Management. Requirements may be
documents, a minimum grade or a certain test result.
Admissions Officers can send information to students for requirements which they do not fulfill or
for documents that are missing. Automated dunning processes can be defined. The Print Workbench
can be used for this purpose.
The system automatically recognizes and duns unfulfilled requirements such as missing documents.
You can create reminders for missing requirements with the Correspondence Dunning Run Function
(transaction FPCODU). As these reminders are created with the Print Workbench, all the tool’s and
other setting options are also available to you.
Note: Usage of FI-CA Correspondence Dunning Run
• You can set the reminder flag to notify applicants e.g. to send outstanding documents. The
indicator, for sending reminders, is the incoming date. When there are no negative requirement
results (Audit Run), which are relevant for dunning, the incoming date is set. If the incoming date
is “initial” the student will be reminded during the FI-CA Correspondence Dunning Run.
© SAP AG
IHE102
11-54
1 1 .7 Adm issions Audit – Re quire ment Pa t t e rn
Requirement Pattern for Admissions
Audits are delivered in standard.
4000 Overall Admissions
Result
4100 Admissions Application
Completeness
A similar Pattern is delivered for ‘AutoAdmit’ (Audit Type 4500).
Admission Audits are performed by way of
Assessment Processes for a specific
Program of Study.
4105 General Completeness
Requirements
4110 Program-specific
Completeness
If you enable Admissions Audits for a
Program, you cannot admit a student
without a successful audit result!
4120 Major-specific
Completeness
4200 Admissions Minimum
Criteria
4205 General Admissions
Min. Criteria
4210 Program Admissions
Min. Criteria
4220 Major Admissions
Min. Criteria
© SAP 2009
Abstract Requirements 4000, 4100, and 4200 are defined as ‘Consolidation’ requirements. The
others are defined as ‘Variable Requirements’.
‘Variable Requirements’ may or may not contain sub-requirements (i.e. they may be empty). In
order to prevent generated profiles from containing empty sub-requirement containers, use the
following IMG path: Student Lifecycle Management Processes in Student Lifecycle Management
Audits Requirements Requirement Patterns Prevent Storage of Requirements without
Subrequirements. Set the value to ‘V’.
© SAP AG
IHE102
11-55
1 1 .7 Adm issions Audit –Audit Condit ions
SAP3 – Checks overall Credits earned in an external transcript
SAP4 – Checks class rank as an absolute number in an external transcript
SAP5 – Checks GPA in an external transcript
SAP6 – Checks for a minimum external test score (or sub-test score)
SAP7 – Checks against a characteristic value in the notification
© SAP 2009
SAP4: If you wish to check class rank as a percentile rather than an absolute number, you need to set
TRANSCRIPT-PROC_RANK = X in table V_T7PIQSWITCHVALUE (via transaction SM31)
For all conditions with the filter ‘OPERAND’, valid values are: EQ, GT, LT, GE, LE
© SAP AG
IHE102
11-56
1 1 .7 Adm ission Audit - Se lf Se rvic e s
Missing Admissions Materials
A web-based self-service view is provided for applicants to view the status of their admissions
applications, along with a view of the admission audit results for application completeness.
Web Dynpro Application: PIQIB_ST_ADMAUDIT
© SAP 2009
You should have two different configurations: one for applicants, and one for Admissions Officers.
In your admissions audit catalog, you must maintain the ‘Create Reminder’ flag for the
Requirements you wish to expose in the Web Dynpro!
For each configuration (applicant vs. admissions officer), you need to maintain the Requirement
Pattern Elements that should be exposed:
• IMG Path: Student Lifecycle Management Role-Based Web UI
Edit Profile Views for Admissions Auditing
Cross-Role Settings
• Create one Profile for each Web Dynpro configuration
• You can assign Requirements with the recursion flag on to easily use an entire portion of a
Requirement Pattern
Note:
• This Web Dynpro is navigated to from Web Dynpro PIQIB_ST_ADMAPPLICATION
© SAP AG
IHE102
11-57
1 1 .7 Adm ission Audit – T opic Sum ma ry
You are now able to:
Explain the concept of Admission Audit
Show how an application can be checked
against admission requirements
Understand the integration between Student
Lilfecycle Management and Records
Management
Explain how missing documents can be
requested automatically from applicants
© SAP 2009
© SAP AG
IHE102
11-58
1 1 . Audit s: U nit Sum m a ry
You should now be able to:
Understand the concept of audits in Student Lifecycle Management
Explain the functionality of:
Requirement Catalogs and Versions
Requirement Patterns
Requirements and Subrequirements
Requirement Profile Templates
Derive a Requirement Profile for a Student
Run Audits for Students
© SAP 2009
© SAP AG
IHE102
11-59
© SAP AG
IHE102
11-60
I H E1 02 St udent Lifec yc le M anagem ent :
1 2 . Progre ssion
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009
© SAP AG
IHE102
12-1
1 2 Progre ssion
Contents:
12.1 Progression Concept Overview
12.2 Program Type Based Progression
12.3 Progression by Stage Completion
© SAP 2009
© SAP AG
IHE102
12-2
1 2 Progre ssion – U nit s Obje c t ive s
After completing this unit, you will be able to:
Understand the difference between two different
concepts of progression in different learning cultures
Understand the concept of program type based
progression supported by Student Lifecycle
Management
Understand the concept of progression in staged
programs supported by Student Lifecycle Management
© SAP 2009
© SAP AG
IHE102
12-3
1 2 Progre ssion – Busine ss Sc ena rio
You evaluate the quantitative and qualitative aspects of students’
academic progress
You classify students according to their progress
You use Student Lifecycle Management to enter progression or stage
completion results
You use Student Lifecycle Management to calculate progression and
stage completion results automatically
© SAP 2009
© SAP AG
IHE102
12-4
1 2 .1 Progre ssion Ove rvie w : T opic Obje c tive s
After completing this topic, you will be able to:
Explain the difference of the student life cycle in
two different academic models or learning cultures
Understand the concept of program type-based
progression
Understand the concept of progression based on
stage completion
© SAP 2009
© SAP AG
IHE102
12-5
1 2 .1 Progression Ove rview : Diffe rent Progression
Conc e pt s in Diffe re nt Ac a de m ic M ode ls
Student Lifecycle Management supports different types of ”Progression“ models.
Program progression by
stage completion
Program type progression
(non-staged programs)
1.Program Type-based Progression
Common for undergraduate and
graduate programs in the US
Students are promoted based on the
program type, such as undergraduate
or postgraduate. Different steps of the
promotion are, e.g., for
undergraduates: freshman,
sophomore, junior, senior
A
combination
of both
concepts is
possible as
well.
2. Progression by Stage Completion
The second model is typical for European
universities and for professional programs in the
US.
A staged program of study requires the completion
of a stage before students can progress to the next
stage.
Each stage may set requirements which have to be
fulfilled to complete the stage.
The stage completion process is part of the
progression of the students through their studies.
© SAP 2009
Two audit types for measuring academic progression are delivered for Student Lifecycle
Management: “Degree audit” (for Program Type-based Progression) and “stage audit” (for Stage
Completion). You can use the audit type to classify the different kinds of audit processes at your
university.
© SAP AG
IHE102
12-6
1 2 .1 Ove rvie w : Progre ssion Conc ept –
Progra m t ype ba sed Progre ssion
START:
Student is admitted to
university at beginning
of semester
Conferment of
Degree
Final Degree
Audit
1. Registers for modules
(Implicit program
registration)
Option B:
Preliminary Degree
Audit
If studies are continued
student registers for more
courses
2. Module Examination
(Assessments, optional)
3. Grading and
Module Completion
Completion of
remaining
course work
Option A: Application for
Graduation
4. Program Type
Progression
5. Academic
Standing: Ok
Admitted to
continue
© SAP 2009
Main aspects of a program type driven Student lifecycle:
• After the student has been admitted to the university, the lifecycle starts with module booking.
The first module booking for an academic session initiates an implicit registration for a program
– including program type and degree.
• While studying, the student can choose from offered courses which count towards the degree.
The student is advised, e.g. by the Academic Advisor, which courses to take and in which order
in order to progress.
• At a determined point in time (e.g. after an academic session is finished) a progression evaluation
is done. The progress of the student is evaluated taking earned credits and grades into account.
• The result of the progression determines whether the student is allowed to continue studies.
• Note: The progression exercise is not a degree audit! To measure the ”real“ progress toward a
degree a degree audit is required. Only then the student’s academic work is evaluated against
degree requirements.
© SAP AG
IHE102
12-7
1 2 .1 Progre ssion Ove rvie w : Progra m T ype
Ba sed Progre ssion
Program:
Program Type:
Bachelor of Business Administration
Undergraduate
After the progression exercise, the student
- is classified into a progression
category for this program
dependent on earned credits
+
Freshman (0-23 credits)
- receives a classification dependent
on GPA (grade point average)
Good Standing: GPA > 2.0
On probation: GPA > 1.6
Sophomore (24-47 credits)
Junior (48-71 credits)
Good Standing: sessional GPA >
2.4, GPA > 2.0
Senior (more than 72 credits)
On probation: GPA > 1.8
Quantative Evaluation
Qualitative Evaluation
© SAP 2009
1. Program Type-based Progression
The progress of a student is measured for a certain program type (e.g. undergraduate and graduate)
rather than a specific program of study.
Progression uses different categories to determine the ”quantitative“ progress (progress
classification = freshman, sophomore, …) and the “quality“ of students’ work (academic standing =
good, on probation, …)
• Progression is based on “performance indices“ (various types of GPAs, totals for credits, …)
calculated from the academic work used for the program type
• Academic work (courses, etc.) is assigned to program types
• Rules for program type progression can be defined by the customer and implemented with the
VSR tool
• The result of the program type based progression can be calculated automatically and modified
manually
• The values used are stored in activity documents
• Student Lifecycle Management tracks the progress in the various categories per program type as
a time dependent Infotype at the student
© SAP AG
IHE102
12-8
1 2 .1 Progre ssion w it hin St udent Lifec yc le :
Progre ssion by Sta ge Com ple t ion
START:
Student admitted
to program,
Stage 1
Student registered
to program
Option A:
When last stage has
been reached
Confer Qualification
7. Stage 1 completed
successfully
Option B: Moving on
to Stage 2
6. Stage Audit:
Completion of
Stage 1
1. Register for Stage
completion
2. Module Selection
/Booking
Progress to
Stage 2 possible
3. Stage Audit:
Admission to
Stage completion
4. Module
Examination
(Assessments)
5. Grading &
Module Completion
Steps of the progression process by „Stage Completion“
© SAP 2009
The stage completion process is a progression of the student through the program of study which is
organized by stages.
• It requires an explicit registration to the program and re-registration each academic session
(triggered by an application)
• For each stage, a stage completion process is started at the beginning of the stage. After the
student has booked modules, the first step is initiated: stage audit to check whether the student is
admitted to stage completion. Mainly, the audit checks whether the student has booked all the
modules or enough credits in order to be able to complete the stage successfully at the end. If the
audit fails, an advisor can help the student to adjust his or her module bookings.
• After the module examination period when grades are known, the stage audit for the stage
completion takes place. The student acquired work (e.g. passed courses, number of credits,
GPA…) is checked against stage requirements.
• If all stage requirements are fulfilled, the student can proceed to the next stage and the process
starts again with re-registration.
The graphic describes one example of how the stage completion process can be integrated within the
student lifecycle. In this case, the student lifecycle refers to only one stage and not to the full study
duration.
© SAP AG
IHE102
12-9
1 2 .1 Progre ssion Ove rvie w : Progre ssion by
St a ge Com ple t ion
Stage 1
Requirements for Stage 1:
Mandatory & Optional Courses: Finance I, Economics I, etc.
Stage 2
Requirements for Stage 2:
Mandatory & Optional Courses: Finance II, Economics II, etc.
Stage 3
Program of Study
Student Lifecycle Management program progression supports the promotion of the
student through stages. The requirements for a degree are divided onto these
stages.
After each stage, a stage completion check is being done as part of the program
progression. Therefore this process is called ”Stage Completion“.
Requirements for Stage 3:
Mandatory & optional courses: Finance III, Economics III, etc.
Further requirements: Overall stage GPA > 2.0
Further requirements: Overall stage GPA > 2.0
Further requirements: Overall stage GPA > 2.0
© SAP 2009
If a program is organized in stages which also connect to rules and requirements the student has to
fulfill for a particular stage, the promotion of the student will follow the stages. In this case, the
progression model is a stage completion.
The staged program of study offers courses for students in each stage which need to be passed.
Otherwise, the stage needs to be repeated.
The stage model may be used for different academic models:
• For example, programs are structured into years which correspond to stages and the content of
the program is predefined with options for the student. An individual study plan may exist for the
student.
• In another example, the stages are used to structure the programs into two parts which do not
necessarily correspond to academic years. Only if the first part is passed, a student can start the
second part.
© SAP AG
IHE102
12-10
1 2 .1 Progre ssion Ove rvie w :
Curric ulum Plan vs. Sta ge s
Program: Bachelor of Business and Administration Program Type:
Undergraduate
Curriculum Plan:
Stages:
Course
100
Course
101
Course
102
Session 1
Stage 1:
Course
200
Course
201
Course
202
Session 2
Stage 2:
Course
300
Course
301
Course
302
Session 3
Stage 3:
Course
100
Course
101
Course Course
200
201
Course
300
Course
301
Course
102
Course
202
Course
302
Degree requirements are split up into parts
according to the “units” of the program of study
(=stages).
A student has to complete a stage before
progressing to the next stage.
Defines the modules or the requirements and
proposes the order in which they should be taken.
A student can take a course A with level 2 if the
course A with level 1 has been finished.
© SAP 2009
Please note the difference between a curriculum plan and stages:
• 1. Curriculum Plan:
- The University defines the modules or more general the requirements a student has to
complete in the stage or program. Within a curriculum plan an order is proposed in which
they can be completed. This plan is divided into sessions, and contains the courses required in
the first session (Freshman year, 1st), second session (Freshman year, 2nd), third session
(Sophomore year, 3rd), etc. The plan is used for advising as well as for planning the
University offerings and seen as a commitment to the students to provide the modules they
need to complete the program or stage in time.
- Audits of requirements do not always have to be performed at set intervals. They can also be
run at any time during the program or at the end of the program. The audit determines if the
student fulfills the (degree) requirements and, if not, specifies which requirements are
outstanding.
• 2. Stages:
- Degree requirements are split up into parts according to the “units” of the program of study
(=stages).
- An audit of requirements is run in each stage of the program – Students’ work is evaluated
based on requirements of the respective stage. The audit result determines whether or not the
student is allowed to progress to the next stage (=progression). The student is awarded a
degree upon successful completion of all stages.
© SAP AG
IHE102
12-11
1 2 .1 Progre ssion Ove rvie w : T opic Sum ma ry
You are now able to:
Understand the student lifecycle in both educational models Degree and Stage Audit
Explain the difference of the student lifecycle in two different
academic models or learning cultures
Understand the concept of program type based progression
Understand the concept of progression based on stage completion
© SAP 2008
© SAP AG
IHE102
12-12
1 2 .2 Progra m T ype Progre ssion: T opic
Obje c t ive s
At the conclusion of this topic, you will be able to:
Understand the concept of program type-based
progression in Student Lifecycle Management
Understand the data model for program type-based
progression
Understand how program type progression results are
derived and stored for students
Understand how to implement program type-based
progression in Student Lifecycle Management
© SAP 2009
© SAP AG
IHE102
12-13
1 2 .2 Progra m T ype Progre ssion – Business
Sc ena rio
An institution monitors the progress of its students at the end of each term
It classifies Undergraduate students according to the number of credits they have earned:
Freshman: 0-23 credits
Sophomore: 24-47 credits
Junior: 48-71 credits
Senior: 72 and more credits
To determine the academic progress of students, the academic committee has decided that
undergraduate freshmen and sophomore students should have an overall GPA of 1.8 in their
undergraduate courses. Juniors and seniors need 2.0. If they fail to achieve this average, the
students are put on probation. In order to achieve a good standing, they have to fulfill certain
conditions, for example, have a sessional GPA of 2.2 or better. If they fail to achieve this
grade, they may be dismissed.
Graduate students must meet a higher standard. They must have a GPA of at least a 2.5 in
their courses.
Students also have to fulfill certain standards to be eligible for financial aid. A GPA of 2.0 is
required.
Undergraduate students with a GPA of 3.0 or higher and graduate students with a GPA of 3.5
or higher are placed on dean’s list.
© SAP 2009
© SAP AG
IHE102
12-14
1 2 .2 Progra m T ype Progre ssion –Progre ssion
Re sult s
You want to calculate and monitor progression in Student Lifecycle Management:
Progression results:
Can be calculated automatically or set manually with the mass processing
transaction for program type progression
Can be edited in the student file (single processing)
Can be edited automatically during the admissions process, or manually from
the application
Process Steps:
Define program types
Assign a program type to each program of study
Define progression category
© SAP 2009
© SAP AG
IHE102
12-15
1 2 .2 Progra m T ype Progre ssion – Program
T ype
Program Types: You execute a program type-based progression run for a certain
program type
Preparation / Data Model:
Define program types (Customizing)
Assign a program type to each program of study
A student is automatically assigned to a particular program type if s/he is
registered/admitted to a program which belongs to this program type
Study A
(CS)
Program of Study A (SC)
Program Type Undergraduate
Study B
(CS)
Program of Study B (SC)
Program Type Graduate
© SAP 2009
Program types are defined in Customizing for Student Lifecycle Management under Student
Lifecycle Management → Student Lifecycle Management Processes → Progression → Program
Type Progression → Create Program Types.
You can assign a program of study to a program type via an attribute of the Program Data Infotype
(1730). A program can only be assigned to one program type.
Note: We recommend that all programs of the same type have the same session variant.
Examples for program structures:
• A university offers programs which belong to the program type “undergraduate”, “graduate”, and
“law”.
• A Bachelor degree program belongs to the undergraduate program type, Master and PhD
programs are graduate program types, and the professional law program belongs to the law
program type.
• A student can be registered in programs of several types simultaneously, e.g. he or she is
registered in a Bachelor of Science program and is taking a major in Mathematics. Following an
interest in management studies, he or she enrolls in a Business Administration program to earn an
MBA. The student is now both an undergraduate and a graduate student.
© SAP AG
IHE102
12-16
1 2 .2 Progra m T ype Progre ssion – Progression
Ca t egory
Progression Category:
Students are classified according to the progression categories in a program type.
Student Lifecycle Management offers five progression categories:
Progress Classification:
Classify students based on quantity of work, e.g. total number of credits (e.g. Freshman,
Sophomore, Junior, Senior)
Academic Standing:
Classify students based on quality of work, e.g. GPA. Rules determine the academic
standing of a student (e.g. Good Standing, On Probation, Dismissed)
Progress Classification for Financial Aid:
Allows to calculate and set a separate classification for financial aid if institutional rules for
academic work differ from those for financial aid
Academic Standing for Financial Aid:
Special classification for Financial Aid
Academic Honors:
Category that allows to assign a special distinction to students (e.g. )deans list
© SAP 2009
Customizing Paths:
• Progression categories for each program type:
- Student Lifecycle Management Processes
Progression
Program Type Progression
Create Program Types.
• Settings for “progress classification” and “progress classification for financial aid”
- Student Lifecycle Management Processes
Progression
Program Type Progression
Set Up Progress Classifications.
• Values for “progress classification” and “progress classification for financial aid”
- Student Lifecycle Management Processes
Progression
Program Type Progression
Create Program Types. There select the program type and choose Progress Assignment. Here,
you can also define a sort sequence for the progress classifications.
• Values for “academic standing”
- Student Lifecycle Management Processes
Progression
Program Type Progression
Create Program Types. There, select the program type and choose Academic Performance.
• Values for “academic standing for financial aid”
- Student Lifecycle Management Processes
Progression
Program Type Progression
Create Program Types. Select the program type and choose Academic Performance for
Financial Aid.
• Values for “Academic honors”
- Student Lifecycle Management Processes
Progression
Program Type Progression
Create Program Types. There, select the program type and choose Academic Distinctions.
© SAP AG
IHE102
12-17
1 2 .2 Progra m T ype Progre ssion – Progression
Re sult s
The results of a program type progression run include:
Value for each progression category
Freshman, good standing, etc.
Activity document for progression run with header and details
The details provide information on how the result is calculated (e.g.
performance indices which led to the progression result)
Status of the progression result
Final results are valid results based on complete data
A result is pending if not all modules have been graded when the result is
calculated
A projected result is determined on the assumption that booked modules will
be completed
© SAP 2009
Progression results are stored in the student file (tabs ‘program type progression’ and ‘activity
documents’).
Activity documents are created for progression results – either in the automated calculation or in
dialog. Details include Modules used in progression and performance indices and their values as
calculated in the progression run
Progression results (= values per progression category) are stored for the student (object ST) in the
progression Infotype (1737). This Infotype includes a link (GUID) to the activity document.
Infotype 1737 (Header Section) includes the following detail information:
• Program Type
• Progression Category
Infotype 1737 (Table Section) includes:
• Check Period (Check From - Check To)
• Valid-From Date
• Real Validity Period (Valid From - Valid To)
• Result (Result and Result Status)
• Academic Year and Session
The system derives a status for the progression result, depending on the completeness of the
progression run. The completeness is measured by the completeness factor and is based upon the
status of the module bookings (booked – graded – completed …):
• Projected or Pending if completeness factor < 100%, dependent on check-to date
• Final (completeness factor = 100%): All required data is available (e.g. all relevant modules have
been graded)
Note: Performance indices (average grades, credit totals, ...) are saved in an activity once the related
processes (change of module booking, grading, change of academic work in extended maintenance)
are completed successfully.
© SAP AG
IHE102
12-18
1 2 .2 Progre ssion H olds and Cust ome r St a tus Configura t ion
Business Scenario:
When the progression run results as Academic probation, an advisor hold
should be set on the student so that they must talk to their advisor before
booking any more courses. In addition, when the progression run results in a
value of DISM (dismissed), the advisor hold should be deactivated and a
dismissed hold activated. If the student becomes ‘in good standing’, both holds
(if activated), should be deactivated.
Progression Holds
An IMG configuration table is available, allowing the system to automatically
activate or de-activate holds or customer statuses for a student, based on the
results of a program type progression.
If Search help is used for settings holds, available customer statuses will
appear on the holds tab in the student file as additional selection option
beside holds.
© SAP 2009
Use Cases:
• Advising hold 9079 is set when the Progression run has a result of PROB; this hold is
deactivated if the Progression run has a result DISM or GOOD. In the same way, the Dismissal
Hold 9715 is set if the progression run returns a result of DISM and it is deactivated when the
result is GOOD.
• If a hold is defined as study-specific, it will be activated/deactivated for all programs of the same
Program Type. The activation/deactivation date range should be the same as the progression
result date range.
IMG Path to activate or de-activate holds or customer statuses: Student Lifecycle Management >
Processes in Student Lifecycle Management > Program Type Progression > Business Add-Ins > Set
Holds and Customer Status in Program Type Progression
Requirements for using Progression Holds and Statuses
• Holds to be activated/de-activated (and customer statuses) are already defined
• Progression values/rules for academic standing are already created
• You have implemented the BaDI: HRPIQ00_SET_STATIND
The configuration table is read by an implementation of the previously available Progression BAdI.
You need to create and activate an implementation of the BAdI which properly reads the
configuration table. Function module HRIQ_HS_PROG_HOLD_MAN is provided for this.
The BAdI is Filter-Dependent, based upon the Progression activities that should automatically
manage the holds. The available filter values are:
• PG3C – Reset Program Type Progression
• PG2M – Program Type Progression (Manual)
• PG1A – Program Type Progression
© SAP AG
IHE102
12-19
1 2 .2 Progra m T ype Progre ssion – Da t e s
Dates which are important for a progression run:
Valid-from date: date on which a progression result becomes valid
Check-to date: date until which academic work of student is considered for
calculation of progression
Check-from date (internally): day after the check-to date of the last
progression run.
Check Period: Period between check-from date and check-to date which is
relevant for the selection of academic work
Note: You can assign a progression result directly to an academic year and session.
This function can be used for academic history and reporting purposes.
© SAP 2009
Valid-From Date: This is the date as of which the progression is valid for the student
Check- to-date:
• date up to which academic work is included in the progression run
• defines the academic work which is relevant for progression.
• is used by the program when calculating performance indices.
• influences the execution category of the program.
• is specified in the calculation and stored together with the progression result.
Note: Often, the “check-to” date is the last day of the previous session and the “valid-from” date is
the first day of the next session.
(Internal) Check-From Date: The SAP system uses an internal check-from date. The check-from
date is the day after the check-to date of the last progression run.
Check Period: The period between the check-from date and the check-to date. The SAP system
includes all the academic work objects whose valid-from date is within the check period in the
progression run.
Note that some Universities determine progress in certain progression categories for shorter time
periods while others store progression results only if a specific prerequisite is fulfilled (for example,
completion of at least 12 credits). Student Lifecycle Management enables you to map both of these
scenarios in the system.
© SAP AG
IHE102
12-20
1 2 .2 Progra m T ype Progre ssion – U sa ge List s
Progression is calculated on the basis of the modules the student has completed.
Note: Not all modules count toward progression. Student Lifecycle Management
“needs to know” which modules (bookings) in a student’s academic history count
toward progression.
Solution: The bookings are directly related to a student. In addition, Student
Lifecycle Management provides a “usage list” for program type progression
(generated automatically or manually).
Usage List for Program Type A
506
ST
Infotype 1725: Module Usage
SM
GUID
GUID 1
Module Usage List: store booking
GUID of booing relationship.
Infotype 1725: Module Usage
GUID 2
The “usage list” is stored at the student
object and is built upon infotypes
(Where used list – students, 1725
Infotype 1725: Module Usage
GUID 3
© SAP 2009
Usage lists are generated either manually using transaction pp01 (which is not the usual case) or
automatically during the module booking process: based the selected program in module booking
(booking context) and the program type assignment of the module.
For each item on the usage list, the system stores:
• Program type
• Activity, user, date
• Progression category assignment: flag which includes or excludes a booking in or from a
progression category
• Valid-from date: key date as of which the module booking is to be included in progression
An academic work object is included in program type progression if the following conditions apply:
• The academic work object is assigned to the program type
• The relevant progression categories are active (flagged)
• The valid-from date of the module booking is before or identical to the check-to date (and is after
the internal check-from date)
© SAP AG
IHE102
12-21
1 2 .2 Progra m T ype Progre ssion – Aut oma t e d
De t e rm ina t ion
Student Lifecycle Management can automatically determine the results for the
program type progression categories based on the quantitative and qualitative
assessment of academic work. To do this, program type progression uses
Performance Indices
To evaluate the quality and quantity of student academic work (e.g. GPA, credit
totals, etc. )
Calculation points
Determined points in the system where a calculation is started
VSR – Rules and Regulations
Rules for the calculation of progression categories
Substitutions
Automatic update of progression values dependent on result of rule check
© SAP 2009
When you have identified the figures to calculate in order to perform a progression evaluation, you
build them in the system using the performance indices function. With these tools, you can build
calculation rules upon credits, grades, number of modules, etc. This allows you to calculate GPA,
total credits, semester credits, etc. You can define performance indices for each progression category
(IMG: Student Lifecycle Management Master Data → Academic Performance Indices)
After this, the performance indices are attached to a calculation point for each category of program
type progression (PRG 1 – 5). Each time the SAP system reaches one of the calculation points
defined for progression, it starts the performance index calculation assigned to the calculation point
and transfers a specific set of academic work objects. These are the module bookings with the
appropriate module usage.
Furthermore, you use the VSR tool (Validation, Substitution and rules) for implementing your
program type progression process:
• University’s program type progression regulations need to be mapped in the VSR rules. This is
done by creating a rule container and linking this rule container to non-academic callup point
0053.
• In the IMG section Student Lifecycle Management Processes → General Settings → Rules, you
create substitutions in the VSR rules and assign them to callup point 0053 (progression). This
allows the system to automatically update students’ progression categories depending on the
result of the performance indices (e.g. GPA = 2.0 => academic standing is set to “good
standing”)
For more information, please see the chapter about “General concepts”.
Note the difference between “performance indices” (as described above) and “performance
indicators” used for the calculation of GPAs etc. within the external transcript of a student.
© SAP AG
IHE102
12-22
1 2 .2 Progra m T ype Progre ssion – Proce ss Flow
Example: Progress Classification for
Undergraduate Student
Callup Point 0053: Progression
Progression Hold?
Hold Manager: Check Hold
Total Earned Credits
Calculation of Performance
Indices<
Program Type:
Undergraduate, Progress
Classification. Rules to
Determine Freshman (0-24
cr), Sophomore (25-47 cr), ...
Rules (VSR)
Substitutions (VSR)
Progress Classification Set
According to the Result
Store Progression Result
For freshmen, a “see
advisor” booking hold is
set. Freshmen need to
contact an advisor before
booking.
Hold Manager: Set/ Reset
Hold or Status
© SAP 2009
Callup point 0053 is used to perform checks for automatic determination of the progression
category.
• The system first calls the hold manager. If a program type progression hold is set, processing is
terminated.
• For each progression category, the system calls a calculation point for the performance indices. It
transfers the list of module bookings (determined from the usage list and check-to date). Then it
calculates the performance indices.
• The system calls the (VSR) rule machine. The rules can use the performance indices (e. g. overall
GPA >= 2.0).
• If a rule is successfully checked, the system sets the result (progression category value and result
status) with a substitution in VSR.
Note: The rules are called only once per student. Substitutions are called sequentially for all program
types and progression categories. There is only one callup point for program type progression.
• The rule machine returns the result and the result is stored for the student.
• When program type progression has been determined, the system calls the hold manager. A hold
or status can be set according to the progression result.
Implementation Steps:
• 1.) Definition of program types and assigned progression categories
• 2. Definition of values for the various categories
• 3.) Build performance indices:
- Calculation algorithm (e.g. grade average, number of earned credits)
- Filter (e.g. sessional, resident, ...)
- Assign them to the calculation points for each category
• 4.) Build progression rules in VSR
- Prerequisite + substitution to set the result for each progression category; e.g. Earned credits
greater than 72 => Progress Classification = Senior
• 5.) Implement rules for module usage (if other than standard)
• 6.) Define schedule for progression runs
© SAP AG
IHE102
12-23
1 2 .2 Progra m T ype Progre ssion: M a ss
Proc e ssing a nd Single Proc e ssing
Mass processing for automated progression can be done via a report:
1. Students for whom program type progression is to be done are selected by program of
study via selection method and variant
2. Program type(s), valid-from date and check-to date are entered
3. Program is started by choosing an execution type.
Single processing is done in the student file
The system automatically determines the execution type
The system proposes the progression result
Two dialog transactions are available
“Edit” for one program type and all progression categories
“Create/Edit/Edit/Display” a single progression result
Note: In program type based progression, you are only allowed to edit the last progression result!
© SAP 2009
You can calculate progression results automatically using report program
RHIQ_PROG_GR_PROGRESSION. You can run the program in the dialog mode using transaction
PIQPROGGR (SAP menu: Student Lifecycle Management Teaching and Examination
Program Type Progression) or in a batch job.
• To select the students for the report, use a selection method and variant. The system selects the
students by study or program.
• Enter the program type(s), valid-from date and check-to date.
• The report program offers six execution types:
- Initialize: No progression results are available for the program type or student
- New: No progression results are available for the check-to date => new result
- Repeat: Progression results are available for the check-to date => the system repeats (redoes)
the existing calculation (only last progression result)
- Automatic: The system determines the execution type for each student or program type
automatically
- Manual: New progression value is entered manually
- Reset: The system resets all program type progression results whose check periods overlap
with the check-to date or are after the check-to date
© SAP AG
IHE102
12-24
1 2 .2 Progra m T ype Progre ssion: T opic
Sum m a ry
You are now able to:
Understand the concept of program type based progression
in Student Lifecycle Management
Understand the data model for program type-based
progression
Understand how program type progression results are
derived and stored for students
Understand how to implement program type based
progression in Student Lifecycle Management
© SAP 2009
© SAP AG
IHE102
12-25
1 2 .3 Progre ssion by St age Com ple t ion
At the conclusion of this topic, you will be able to:
Understand the concept of progression based on stage
completion
Explain the concept of assessment processes for stage
completion
Explain the concept of stage audit within the stage completion
process
Conduct mass processing for the stage completion process
Understand the conferment of qualification within staged
programs
© SAP 2009
© SAP AG
IHE102
12-26
1 2 .3 Progre ssion by St age Com ple t ion –
Busine ss Sce na rio
A stage as part of a program of study requires its successful
completion before the student moves on to the next stage.
Academic work is evaluated or a stage exam is done and the
result determines whether stage has been completed successfully
or not. Depending on the rules, a university may stop the student
from succeeding if the stage requirements have been failed.
A stage completion may also be used when qualifications are
conferred during the study to show that the student has achieved
a certain status.
© SAP 2009
© SAP AG
IHE102
12-27
1 2 .3 Progre ssion by St age Com ple t ion:
Ove rvie w a nd Link t o Audit s
For Stage Completion the progress of a student is measured for a specific program of study
and the requirements for the program are split onto different stages.
Audits are embedded in the assessment process to perform checks for completion of a stage.
Program of Study
Stage Completion
Stage 1
Assessment Process: stage
completion
check if stage 1 requirements have
been fulfilled
Stage 2
Admission Audit
Completion Audit
Assessment Process: stage completion
check if stage 2 requirements have been fulfilled
Stage 3
Assessment Process: stage completion
check if stage 3 requirements have been fulfilled
Graduation
© SAP 2009
In contrast to program type progression, progression by stage completion focuses on the program of
study and not on the program type. If requirements which a student has to fulfill in order to progress
to the next study level are defined per stage, the progression process is performed by stage
completion. In the above example, audits (stage audit) are embedded in the assessment process to
support the requirements check.
Note: You can select between stage audits which are connected to an assessment process (= process
dependent audit, here: stage audit within a stage completion process) or audits without an
assessment process (= process independent audit). For a streamlined stage audit process, a stage
audit should be linked to assessment processes (assessment processes for stage completion).
For any assessment process there may be two different audits involved: One audit to decide on the
“admission rules” to the assessment process and one audit checking “completion rules” to decide if
the assessment process is finished successfully. In Student Lifecycle Management, this is called
“process part: admissions audit” and “process part: completion audit”. Both “admission audit“ and
“completion audit“ are two separate steps within the stage completion assessment
• Call up points “Stage Audit“ and “Admission to stage audit“ are used depending on the process
step in the assessment process
Audit requirements are attached to the relevant stage by a relationship between rule container (object
type RC) and program of study.
Two callup points allow the attachment of rule containers to stage audits:
• Callup point 0061: ”Stage Audit“
• Call up point 0071: ”Admission to stage audit“.
This allows to perform two different stage audits for different process parts.
The stage completion process is based on the evaluation of stage results. Is the stage audit result
positive, the stage counts as ”completed“.
© SAP AG
IHE102
12-28
1 2 .3 Progre ssion by St age Com ple t ion –
Conc ept
The generic framework of the assessment processes is used for the stage completion process.
Assessment Object CE is related to a program of study via relationship 548 with parameter “stage”
Program of Study (SC)
comprises assessment (548), stage 1
Assessment (CE)
The stage completion is driven by the assessment process status. It indicates the different steps of the
process and is used it to track the process flow.
Admissions Audit Run = ”fulfilled“
Completion Audit Run= ”fulfilled“
Status: ”open“
System Status
“open”
“canceled”
“completed succes.”
“completed unsuc.”
Status: ”completed successfully“
start stage completion process
cancel stage completion process
finish stage completion process, progress to next stage possible
finish stage completion process
The customer status is used to manage further steps within the stage completion process.
© SAP 2008
You will open an assessment process for each student who will go through the stage completion
procedure. There is one assessment process per student and stage.
Go to SAP Menu Teaching & Examinations
Academic Record
Edit assessment processes:
• To open an assessment process for specific students, you can select them directly or find them
using selection methods. Maintain the necessary selection methods in the selection method group
”completion audit“ to allow the selection of students for the report.
• Another option is to use the ”expected processes“ function. On the corresponding tab, you find
students who do have a valid registration for the chosen program, stage and academic year, but
do not have an open assessment process for the stage completion assessment yet.
• You can open the process automatically triggered by a registration to a program (BAdI)
• You can open a stage completion assessment with reference to a scheduled assessment. Then
registration and withdrawal deadlines are stored by the scheduled assessment.
The customer status should be used to manage further steps within the process. After the admissions
audit run has been completed and a result has been returned, you must change the customer
assessment process status accordingly e.g. Audit result = ”Fulfilled“ => set customer status
”admitted“. You do this using the report to change the assessment process status, to be found under
Teaching & Examinations
Academic Record
Change Process Status (Admission).
• Example: A student is ”invited“ to the stage completion process. Admission requirements are
checked (”admitted“/”rejected“) before the actual check for completion is performed.
• Other customer status examples: “Registered for stage”, “Initial audit submitted”,
Afterwards you can start the completion audit run in the same way as the admissions audit run. The
assessment process should be finished now, therefore you have to set a final system process status,
such as ”completed successfully“. Additionally, you can also set a customer status. You do this
again by means of the mass report for status change, but now for the process part “completion”
(Change Process Status (Completion)).
© SAP AG
IHE102
12-29
1 2 .3 Progre ssion by St age Com ple t ion –
Proc e ss Flow
Business Process
Example in SLCM for one stage
1. Register student
for stage completion
Open assessment
process for stage completion
Register on exam (optional)
Register on scheduled
assessment
Assessment Process
2. Exams
3. Evaluation of
academic work
Courses, Majors,
other study results
Process-dependent stage
audits (admission / completion)
Individual Work
Stage Exam
4. Determine result
of stage audit
Change status of assessment
process based on audit result
Confer Qualification
5. Confer qualification for
stage; allow student to proceed
© SAP 2009
The stage completion process requires an explicit registration to the program and re-registration
each academic session (triggered by an application).
Once you have opened the assessment process(es), you can start the first audit: process part
”admission“ to check if the students are eligible for stage completion. You can either do this in a
single student transaction using transaction SE80, BSP application “PIQ_AUDIT” or use the mass
transaction (see next slides)
Assessment Process Flow:
• Students have to apply for stage completion (= open assessment process)
• They submit their academic work to be checked (= stage audit for admission to stage completion)
• Submitted work is checked against requirements (= stage audit for completion of the stage)
• A result, depending on the requirement check, is defined (= e.g. stage completion successfully
finished, assessment process is closed)
© SAP AG
IHE102
12-30
1 2 .3 Progre ssion by St age Com ple t ion –
M a ss Proc e ssing
Mass processing transactions are available for:
Mass processing for mass stage audits
Mass processing for assessment processes - status change
Available reports to support mass processing:
Admissions Audit Run for Stage Completion
Requirements are checked. Audit result are ”fulfilled“ or “failed“
Update Status of assessment process after Admission Audit Run
Updates customer assessment process status (e.g. customer status = admitted
Stage Final Completion Audit Run
Checks completion requirements. Audit results are ”fulfilled“ or ”failed“
Update Status of assessment process for the Stage Completion after Final Completion Audit
Run
updates system process status = ”completed successfully“ if audit result = fulfilled
update customer process status
© SAP 2009
Student Lifecycle Management provides several mass activities to support background mass
processing of audits and assessment processes.
1) Admissions Audit Run for Stage Completion
• Based on submitted audit forms (courses assigned to requirements) the system checks in this
mass activity whether a student has fulfilled the defined requirements for being admitted to the
stage completion process.
• The report calculates the key figures for the admission audit, it does not change the assessment
process records. Result of the audit is ”fulfilled“ or ”failed“. The assessment process status has to
be updated with a second mass activity.
• Mass report for process-dependent audit runs in the SAP Menu: Teaching & Examinations
Academic Record
Audit (process-dependent).
2) Update Status after Admission Audit Run
• Based on an admission audit run the customer status of the stage assessment process is set
according to the result of the run. In this activity, you are not able to change the system status.
3) Stage Completion – final Audit Run for completion
• As for the admission audit run for the final audit run within a completion a mass activity is
provided.
4) Update Status of the Stage Completion after Final Completion Audit Run
• As for the update of the status after the admission audit run a mass activity is provided to update
the status of a stage completion assessment process after a final audit run. In this activity, you are
able to change system and customer status.
© SAP AG
IHE102
12-31
1 2 .3 Progre ssion by St age Com ple t ion – Sta ge
Audit
Business Scenario: A student “registers” for stage 1 of a program but does not book any modules. At the
beginning of the session, the student must select the modules he or she wants to take so the university can
monitor completion of the stage requirements. The student therefore has to fill out an “audit form”: This means
he or she chooses modules and assigns them to subrequirements. Technically speaking, the student performs
an audit for the “admission” process part.
To run a stage audit within the stage completion process you need to:
1. Start process dependent audit transaction
2. Select audit type ”stage audit“
3. Select process part ”completion“ (or: ”admission“)
Define stage parameter
4. Create requirement profile
Profile Generation for student depends on:
Program stage requirements
Requirement pattern for stage
Process part
5. Execute audit run -> The students academic work is checked against the audit rules.
Audit run result is set automatically by the system if
Implicit additional condition is switched on or *
Auxiliary condition is defined
6. Repeat the audit run if necessary.
© SAP 2009
Start audit run:
• Use the transaction for process-dependent audits (mass report) to start a mass run for stage
completion or run single audit run (BSP Application)
• Before you can execute the audit, you have to create the requirement profile first. It collects all
requirements which are applicable for this student.
For profile generation, the parameter value (to distinguish between e.g. stage 1 requirements and
stage 2 requirement) and process part (admission to the process or completion of it) have to be
considered. This is true for the requirement pattern definition as well as for the derivation of the
concrete requirements and subrequirements.
Or use a requirement profile template from which the individual requirement profiles are built. In
this case, make sure that you flag the program of study to use requirement profile templates. You
can create templates per program of study, requirement catalog, catalog version and audit type.
The Requirement Profile for the student is generated stage dependent, e.g.:
• Assume in stage 1 only basic modules have to be completed by the student. In that case the
requirement pattern for stage consists of university requirements only.
• Beginning with stage 2, the student has to choose a specialization. Thus requirements to complete
the stage also depend on specific rules of the chosen specializations.
• The overall requirement pattern therefore consists of at least two elements: university
requirements and specialization requirements.
• You maintain the stage for the requirement pattern in the IMG for Student Lifecycle
Management -> Processes in Student Lifecycle Management-> Audits -> Requirement Catalogs > Assign Requirement Patterns to Requirement Catalogs
If you repeat the audit and use the ”check audit“ function, the indices are recalculated and the
system checks whether the audit run result will be changed in the order of the different indices. Most
audit rules are based on performance indices, such as GPA, earned credits, etc. If you rerun an audit,
the student might have added more module bookings or completed modules.
© SAP AG
IHE102
12-32
1 2 .3 Progre ssion by St age Com ple t ion –
St a ge Qua lific a t ions
In staged programs the student
usually achieves a degree after
successful completion of all stages.
Degree
In addition it is possible to confer
qualifications for the successful
completion of a stage.
4
3
2
1
© SAP 2009
In addition to the information stored on the assessment process in some cases for a completion of a
stage you need to track additional information, such as:
• When was the result of the completion of the stage ”officially“ established?
• What was the overall result of the stage which is taken into account for follow up processes?
• Who is accountable for the final result of the stage?
• Was the stage completed with a certain distinction?
In these cases after the successful completion of a stage a qualification should be assigned to the
student and the information is stored together with the qualification.
© SAP AG
IHE102
12-33
1 2 .3 Progre ssion by St age Com ple t ion –
Confe rme nt of Qua lific a tions for St a ge s
Object Type
Student (ST)
532 fulfills
SC
Program of
Study
imparts
CQ Degree
B. S. Biology
Biology
imparts
CQ Qualification for
Stage 1 in Biology
532 fulfills
With flag:
”pursues“ qualification
CQ Qualification for
Stage 2 in Biology
CQ Qualification for
Stage 3 in Biology
© SAP 2009
You have to create an internal qualification for each stage for which a stage completion is required.
The qualifications must be related to the program and the stages.
The qualification which corresponds to the stage will be derived for the conferment of qualifications
after stage completion. The degree type of the qualification has to have usage attribute “Stage
Completion” (see next slide). If several qualifications are derived a popup asking to choose a
qualification appears.
The conferment of the stage qualifications is done in the student file – tab qualifications: create
button -> confer qualification for stage completion.
An RFC interface is delivered which can also be used by reports. A report could be created by
customers conferring qualifications automatically as follow-up activity of stage completion. Stage
qualifications can be derived if they are maintained in the academic structure.
Grade and academic honor are defaulted if you e.g. calculate a stage percentage within stage audit
runs. This percentage is used as grade when a qualification is conferred. Moreover the stage
percentage is used to determine Academic Honors.
Information for stage completion process that is kept as additional data on the relationship ST-CQ:
• Stage
• not completed flag:
- I = pursue: means the student is in the process of achieving the qualification (used for the
graduation process)
- F = Failed: you can also maintain the qualification for the student even if the grade is a fail. It
can be useful to manage several attempts of the student to achieve the qualification
- space = achieved
© SAP AG
IHE102
12-34
1 2 .3 Progre ssion by St age Com ple t ion – U sa ge
of Qua lifica t ions
Usage of Qualifications:
Degree Type
to distinguish between qualifications used for
Usage of Qualification
(allowed values:)
graduation
usage = program completion (P)
Examples
stage completion
usage = stage completion (S)
Bachelor
P
for other use
usage = without program reference (W)
Doctoral Degree
P
Master
P
Assistant
S
Train the Trainer
Certificate
W
© SAP 2009
You have to maintain the usage in Customizing for degree types. Depending on the usage, the
qualification is used for the graduation process, stage completion or simple conferment of
qualifications.
© SAP AG
IHE102
12-35
1 2 .3 Progre ssion by St age Com ple t ion –
T opic Summ a ry
You are now able to:
Understand the concept of progression based on stage
completion
Explain the concept of assessment processes for stage
completion
Explain the concept of stage audit within the stage
completion process
Conduct mass processing for the stage completion process
Understand the conferment of qualification within staged
programs
© SAP 2009
© SAP AG
IHE102
12-36
1 2 Progre ssion: U nit Sum m a ry
You should now be able to:
Understand the difference between two different concepts
of progression in different learning cultures
Understand the concept of program type-based
progression supported by Student Lifecycle Management
Understand the concept of progression in staged programs
supported by Student Lifecycle Management
© SAP 2009
© SAP AG
IHE102
12-37
© SAP AG
IHE102
12-38
I H E1 02 St udent Lifec yc le M anagem ent :
1 3 . Gra dua t ion
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009
© SAP AG
IHE102
13-1
1 3 Gra dua t ion
Contents:
13.1 Graduation Process
13.2 Confer Qualifications
13.3 Graduation Application Self Service
© SAP 2008
© SAP AG
IHE102
13-2
1 3 Gra dua t ion: U nit Obje c t ive s
After completing this unit, you will be able to:
Perform the graduation process with SLCM
Maintain and track graduation results
Confer qualifications depending on the graduation results
Maintain qualifications
Confer qualifications outside of the graduation process
© SAP 2009
© SAP AG
IHE102
13-3
1 3 .1 Gra dua t ion Proce ss: T opic Obje c tive s
After completing this topic, you will be able to:
Explain the process flow of the graduation process
Understand how Student Lifecycle Management manages
the graduation process from beginning to end
Start a graduation process as assessment process
Know how to relate degree audits to the graduation process
Confer a degree
Know how to track the graduation process
Understand the basics of implementing the graduation
process
© SAP 2009
© SAP AG
IHE102
13-4
1 3 .1 Gra dua t ion Proce ss – Busine ss Scena rio
After completing a set number of years, stages or credits, students
are eligible to graduate in order to receive a degree.
1. First, a student has to apply for graduation.
2. The university will check whether he or she has fulfilled
the necessary prerequisites in order to graduate.
Degree
3. If yes, results of the student, like credits, GPAs, results of
graduation exams, theses, etc. are taken into account
and checked against degree requirements.
4. If the degree requirements are fulfilled, the student will
be conferred the degree as a qualification.
4
3
2
1
© SAP 2009
© SAP AG
IHE102
13-5
1 3 .1 Gra dua t ion Proce s - Ove rvie w
Student Lifecycle Management supports the full graduation process for students:
Control the graduation process from beginning to end
Register, withdraw, reject students for graduation
Offer graduation exams
Do automatic evaluation of graduation results
Support advising by finding outstanding courses for graduation
Enter results for degrees
Confer degrees depending on results (grades)
Support graduation ceremony
© SAP 2008
The graduation function in Student Lifecycle Management seamlessly integrates the complete
graduation process. Users can access one framework where they have all required functionalities
available: Conferment of qualifications, assessment processes, and audits.
Different parts of the graduation process are supported: Student withdrawal, registration, rejection
and completion. Related processes like repetition of graduation, deregistration and the graduation
ceremony are supported as well.
Requirements for graduation are checked with the audit functionality. A student or advisor can use
simulation audit runs to find out whether a student is able to graduate. Outstanding courses which
are required for graduation can be determined.
Attributes like diploma names, academic honours and qualifying work can be maintained.
© SAP AG
IHE102
13-6
1 3 .1 Gra dua t ion Proce ss – T e c hnic a l Solution
The following technical solutions are used to track the graduation process in Student
Lifecycle Management:
Assessment process: to control and follow graduation as a process
Registration to graduation = open an assessment process
Assessment process status to track graduation processes
Degree audit: automatic evaluation of results
Link of degree audit to assessment process (status depends on audit results)
Conferment of degree:
Degree is implemented as an ”internal qualification“ (object type CQ)
Conferment of the degree is connected to assessment process
Failure or passing of degree is recorded and can be determined by grade
Degree is conferred automatically as soon as graduation process is completed
© SAP 2009
The technical solution to support graduation as a streamlined process is to link several functions
together and to ensure that relevant data will be available throughout the process:
• The assessment process function tracks graduation as process, collects process data and manages
the admission and registration to the process. The assessment process status contains the
information on the student’s status within the graduation process (opened = process is not
finished, graduated = student has successfully completed the graduation process, etc.)
• The degree audit function is used if you want the system to do an automatic degree audit. The
result of the audit influences the assessment process status.
© SAP AG
IHE102
13-7
1 3 .1 Gra dua t ion Proce ss – Proc e ss Pa rt s
Degree (= CQ)
Program of study
Graduation
Assessment Process: Program completion
Degree Audit
- apply for graduation
- check if sufficient requirements are fulfilled to start admissions degree audit
graduation process
- check if all degree requirements have been fulfilled
- set final process status: successful/ unsuccessful (completion) degree audit
Confer Qualification
- deliver degree to student => add qualification to
academic record of student
Deregistration
© SAP 2009
The graduation process consists of two parts:
1) Assessment process ”program completion“
2) Confer qualification
The assessment process ”program completion“ can include two different audit steps:
Admissions audit to check whether the student is allowed to be admitted to the graduation process.
Completion audit which checks the final degree requirements. This is also called degree audit.
You can include degree audit within an assessment process ”program completion“ which allows you to
manage the whole process of graduation, including an application and checking admissions
requirements.
For graduation, assessment processes for audit type 1000 (degree audit) are used.
The confer qualification function will be run after the program completion has been finished and a final
status has been set. This is done automatically.
© SAP AG
IHE102
13-8
1 3 .1 Gra dua t ion Proce ss – Confe rm ent of
Qua lific a t ion
Confer Degree = Confer a Qualification:
Object Type CQ = internal qualification is used to map a degree or other qualifications
A relationship is created between ST and CQ (532 - fulfills)
Information is stored as additional relationship data
532 fulfills
Object Type
Student (ST)
Additional Data (not complete list):
Not completed flag:
I
= pursue
F
= Failed
space = achieved
Degree
or other
Qualification
Object Type
Internal
Qualification (CQ)
© SAP 2009
Qualification object type CQ is used as degree. This is conferred to the student within student file by
creating a relationship between student and qualification.
When you register a student for graduation, the system creates a relationship between the student
and the respective qualification. Qualifications which have not been definitively conferred are
flagged as “are being pursued” on the “not completed flag”. This enables you to create and edit all
conferment data before you actually confer the qualification. Qualifications of this type are also
displayed in the student file on the qualifications tab page. However, these qualifications can only be
changed in the graduation application.
Process to run the assessment process for a student:
• Register one or more student on the assessment / scheduled assessment via the transaction „Edit
graduation per program“ (PIQGRAD) – „create graduation record“. You can use a selection
method to e.g. get the list of all registered students for a certain year. Within this transaction, the
button “Create Graduation Record” is available.
• The result of the qualification (which depends on the status of the assessment process) is stored
in the system: this can be a ”pass“ in case the assessment process has been completed
successfully. In this case, the qualification has been conferred. It can also be a ”fail“. In this case,
the relationship between student and qualification is still kept, but the ”not completed flag“
shows an ”F“ for failed.
• The start date of relationship is interpreted as “Valid from” date of the qualification conferment.
The end date of relationship is usually high date 12/31/9999.
© SAP AG
IHE102
13-9
1 3 .1 Gra dua t ion Proce ss – Furthe r I nform a t ion
When a qualification is conferred, the following information can be
entered and is stored as additional data on relationship ST-CQ:
Stage
Academic session and year
Study duration
Grade
Academic honor
Additional data for qualification work
Functions + assigned persons
Comment or note
© SAP 2009
Grade – a reference to the appraisal where the grade is maintained is stored
Academic honor: depending on the grade, a distinct academic honor can be awarded
Additional data for qualification work can include: Diploma name, title of qualification work etc. if
qualification refers to such kind of work
Functions + assigned persons refer to awarding bodies and activities a responsible person / body is
performing (awarding bodies = e.g. conferring institution; activity a responsible person / body is
performing = e.g. confer degree, functions + assigned persons, e.g. Supervisor = Mr. X, Graduation
officer Mr. Y
You need the functions for qualification conferment to map them in the system. This function must
be assigned the confer qualification activity (CQ01) and one or more allowed object types in
Customizing for Student Lifecycle Management. When you create a conferment, you can only
assign objects which belong to these object types to the functions.
Note: Customizing settings must be maintained for:
• Awarding bodies: Define functions for awarding bodies, Assign relevant activities, Define
allowed object type per function (= object type of the awarding body)
• Qualifications Academic scales
© SAP AG
IHE102
13-10
1 3 .1 Gra duat ion Proc ess – Gra duat ion Cerem ony
Details about the graduation ceremony can be maintained when
conferring a degree:
You can choose locations,
buildings and rooms from your
event planning master data
Date and Time
Event Location
Building and Room
Note: there is no availability check
for the resources
© SAP 2009
When conferring the qualification within the graduation process (transaction for graduation), you
can maintain detailed data about the graduation ceremony on the graduation ceremony tab.
The data about graduation ceremony is stored as infotype data in the study object (object type CS).
© SAP AG
IHE102
13-11
1 3 .1 Gra dua t ion Proce ss – Proc e ss Flow
Business Process (Assessment Process) flow for Graduation:
1. Register student for Graduation
Open assessment process for program completion
Register on graduation exam
Register on scheduled assessment
2. Exam
3. Evaluation of academic work (Courses, Majors, other study results,
Individual work, Graduation exam)
Perform process-dependent degree audit
4. Determine result of graduation
Change status of assessment process, depending on audit result
5. Confer qualification degree
Confer qualification depending on degree grade
© SAP 2009
The graduation function is the point of entry for the graduation process. (From the SAP Menu
choose Student Lifecycle Management → Teaching &Examinations → Graduation → Edit
Graduation per Program OR Edit Graduation per Student.
To start the graduation process, an assessment process is opened for each student you want to
graduate.
Within the assessment process, degree audits can be linked in order to check the graduation
requirements against the students academic work.
Depending of the degree audit result, the assessment process status is determined and set. The final
status of the assessment process is either a ”completed successfully“ or ”completed unsuccessfully“.
Now, the qualification is conferred to the student, and the result (which depends on the status of the
assessment process) is stored in the system.
In the student file, you can always track the graduation process. Any degree the student is about to
pursue is defaulted from the assessment process for graduation. Thus, an advisor gets a complete
overview of all qualifications achieved by the student, or qualifications which the student currently
intends to achieve or has already failed to achieve.
© SAP AG
IHE102
13-12
1 3 .1 Gra dua t ion Proce ss – Pre pa ra t ion
Preparations for implementing a graduation process:
Qualification settings:
Create an internal qualification and attach it to the program of study
Use degree type with ”program completion“ usage assigned
Assessment Process settings:
Create an assessment with audit type “degree audit” and assessment category = ”program
completion“
Attach it to the program of study
Schedule assessments
Degree Audit settings:
Maintain requirement catalog, requirement pattern, requirements or requirement profile
templates
Attach rule containers to call up point ”degree audit“ or ”admission to degree audit”
Attach requirement catalog or requirement profile templates to students
© SAP 2009
Preparation: (Please maintain the customizing settings for all three areas)
1) Set up an internal qualification (CQ) reflecting the degree of the program of study,
Use the transaction for maintaining the program catalog from the SAP menu choose Student
Lifecycle Management → Academic Structure (Curriculum) → Study Planning → Internal
Qualification.
2) Create an assessment for graduation and link it with the program of study; from the SAP menu
choose Student Lifecycle Management → Teaching & Examinations → Academic Record → Edit
assessments. Optionally, you can schedule a graduation exam.
3) Set up a degree audit; from the SAP menu choose Student Lifecycle Management → Academic
structure → Requirement Catalogs.
4) Make the settings for graduation in Customizing for Student Lifecycle Management under
Student Lifecycle Management Processes → Academic Records → Graduation.
Note: In order to be able to use all graduation functions, the following settings are required in
addition to the customizing settings for graduation:
Maintain grading scales in Customizing for Student Lifecycle Management under Student Lifecycle
Management Master Data → Academic Scales.
Define the required grade calculation methods in Student Lifecycle Management Master Data →
Qualifications → Grade Calculation Methods.
© SAP AG
IHE102
13-13
1 3 .1 Gra dua t ion Proce ss – Pe rform Gra dua t ion
Assessment process
Process steps:
Register students for graduation
= opened
Perform degree audit and change
Assessment process status
Complete graduation process
= closed
Display qualifications (also during the process) in student file
© SAP 2009
Register students for graduation; from the SAP menu choose Student Lifecycle Management→
Teaching &Examinations→ Graduation → Edit Graduation per Program. Once you have registered
the students, you can maintain graduation details using the Edit Graduation per Student transaction.
Note: You cannot create registrations for assessments with audit type “graduation” in the Edit
Assessment Process transaction. These registrations must be created in the graduation process!
The system opens an assessment process for each registered student and the relationship between
student and qualification is created with status pursues. The graduation process can be tracked using
the graduation transaction.
Perform degree audit (optional; you can also enter the result of the graduation process manually):
Use process-dependent audits for graduation (either as mass report: SAP menu → Teaching &
Examinations→ Academic Record → Audit (process-dependent) or as single student processing:
transaction SE80, BSP application “PIQ_AUDIT”) (see below).
Complete, withdraw or deny the graduation process for students:
• Enter graduation details (grade, customer status, responsible bodies, graduation ceremony)
• Set final assessment process status (graduated, withdrawn, denied, canceled) either manually or
using mass report by choosing Teaching & Examinations → Academic Record → Change
Process Status (Completion).
• Degree (qualification) is transferred automatically as a result of graduation process. Note:
Degrees cannot be conferred directly (by means of the student file) if a graduation process exists!
Degrees can only be conferred if the assessment process has the final status completed
successfully. Display qualifications by means of the student file.
© SAP AG
IHE102
13-14
1 3 .1 Gra dua t ion Proce ss – M a ss Proc e ssing
Student Lifecycle Management supports:
Mass processing for degree audits, process part admission and completion
Mass processing for assessment processes - status change
Available reports to support mass processing:
Admissions audit run for program completion
check requirements, audit result: fulfilled or failed
Update status of assessment process after admission audit run
update customer assessment process status, e.g. admitted if audit result is fulfilled
Program completion audit run
check requirements, audit result fulfilled or failed
Update status of assessment process for the program completion after final completion audit
run
update customer assessment process status
© SAP 2009
For mass processing within the program completion process, you can use the same reports as for
stage completion:
• 1) Admission Audit Run for Stage and Program Completion
- The system checks whether a student has fulfilled the defined requirements for being
admitted to the stage or program completion.
• 2) Update Status after Admissions Audit Run
- Based on an admission audit run the status of the program or stage assessment process is set
according to the result of the run.
• 3) Program and Stage Final Completion Audit Run
- As for the admission audit run for the final audit run within a completion a mass activity is
provided.
• 4) Update Status of the Program or Stage Completion after Final Completion Audit Run
- Similar to the update of the status after the admission audit run, a mass activity is provided
to update the status of a program or stage completion assessment process after a final audit
run.
© SAP AG
IHE102
13-15
1 3 .1 Gra duat ion Proc ess – Result s in St ude nt File
The results of the graduation process are kept in the student file. You
can use the following information to track them:
1) The qualification is part of the academic record of the student
Qualifications
Conferred, failed or pursued qualifications
Activity
Documents
2) Activity Documents
The system writes an activity document each time a qualification is conferred,
changed or deleted
3) Assessment Process status
The assessment process status can be displayed to track the status of the
graduation process
Assessment
Processes
4) Graduation status
Graduation Candidate
Graduation Withdrawn
Graduation Denied
Graduated
Display by means of student file – tab pages
© SAP 2009
On the Qualifications tab page, the SAP system lists the qualifications that were conferred on and
transferred to the student, as well as the qualifications which the student failed to achieve or is in the
process of achieving.
The system writes an activity document each time a qualification is conferred, changed or deleted.
These activity documents help you keep track of the qualification conferment process.
Four different activities are provided for graduation:
• CQ01: Confer qualification
• CQ02: Change conferred qualification
• CQ03: Delete conferred qualification
• CQ04: Display conferred qualification (no activity document is written)
The assessment process status (system and customer status) provides information about the status of
the graduation process.
The system creates a graduation status, such as graduation candidate, graduation withdrawn,
graduation denied and graduated, which is stored as infotype data in the study object (object type
CS). If the student is a graduation candidate, this can be shown in the student header data.
© SAP AG
IHE102
13-16
1 3 .1 Gra dua t ion Proce ss: T opic Sum ma ry
You should now be able to:
Explain the process flow of the graduation process
Understand how Student Lifecycle Management manages the
graduation process from beginning to end
Start a graduation process as assessment process
Know how the degree audits relates to the graduation process
Confer a degree
Know how to track the graduation process
Understand the basics of implementing the graduation process
© SAP 2009
© SAP AG
IHE102
13-17
1 3 .2 Confe r Qua lific a t ions: T opic Objec t ive s
After completing this topic, you will be able to:
Understand the concept of qualifications
Confer qualifications to students outside the graduation
process
Maintain further information for qualifications
Confer qualifications conditionally
© SAP 2009
© SAP AG
IHE102
13-18
1 3 .2 Confe r Qua lific a t ions – Da ta M ode l
SC
Program of
Study
Biology
CQ
imparts
Degree
Qualification group = University
degrees
Degree Type = Bachelor
B. S. Biology
has
prerequisite
CQ
Qualification
© SAP 2009
Qualifications are objects from type CQ. There is a difference between internal qualifications (CQ)
and external qualifications (EQ) which are used for external transcripts to map qualifications
transferred by other institutions.
Qualifications are maintained within the academic structure and attached to programs of study. They
can be used to map
• Degrees for a program or program type
• Stage qualifications
• Other qualifications
You can either use qualifications as prerequisites to an object within the academic structure, or use
the qualification as the result of the program, module, etc. In the latter case, you attach it using
relationship imparts to the object in question.
To create an internal qualification or to change its attributes, from the SAP menu choose Student
Lifecycle Management → Academic Structure (Curriculum) → Study Planning → Internal
Qualification.
© SAP AG
IHE102
13-19
1 3 .2 Confe r Qua lific a tions – Qualific at ion
Att ribut es
To set up an internal qualification, you can
define the ...
Related Process/Function:
Internal Qualification
(CQ)
Academic Structure, Rules
Reporting
Admission, Graduation
Graduation
Qualification Group
Qualification Discipline
Degree Type and Level
Grading Scale
© SAP 2009
You can define internal qualification attributes which are offered as input help when you create an
internal qualification in IMG for Student Lifecycle Management Master Data → Qualifications.
You can set up qualification groups by combining different sets of internal and external
qualifications. For example, you may combine the internal qualification “Bachelor of Science” and
“Master of Business Administration” in the qualification group “Academic Degrees”. Diplomas and
certificates are other examples of qualification groups.
A qualification group can be used to define rules. For example, you can specify program
requirements using a qualification group - “Applicants must have a high school diploma”.
The qualification discipline describes the field of study in which the internal or external qualification
was acquired. The qualification discipline table refers to the same table as the disciplines for other
academic objects.
The degree type defines the type of diploma awarded by your or external institutions. The degree
type links a degree with a degree level. Possible degree types are Bachelor, Master, PhD, Associate,
high school diploma.
The degree level indicates the standing of a degree offered by your institution and external
institutions (high school, college, university). Possible degree levels are undergraduate, graduate,
high school, college, etc. You must assign a degree level to each degree type.
Related process: You can use the degree level and degree type to define rules, e.g., you can specify
program requirements using the degree level and degree type – “Master students must have an
undergraduate degree”.
You can select a predefined scale to rate the qualification.
© SAP AG
IHE102
13-20
1 3 .2 Confe r Qua lific a t ions – U sa ge
Usage of Qualifications:
You have to define the purpose of qualifications in order to distinguish the processes
they are used for:
graduation => usage = program
completion (P)
stage completion => usage = stage
completion (S)
for other use => usage = without
program reference (W)
You maintain the usage in the customizing
settings for the degree type
Degree Type
Usage of Qualification
(allowed values:)
Examples
Bachelor
P
Doctoral Degree
P
Master
P
Assistant
S
Train the Trainer
Certificate
W
© SAP 2009
© SAP AG
IHE102
13-21
1 3 .2 Confe r Qua lific a t ions – Busine ss Sce na rio
Business scenario for conferment of qualification:
A student has improved his or her written English competency. A
qualification representing this competency is conferred to the student.
This qualification is awarded by a professor in the English department.
© SAP 2009
You can also confer a qualification (outside of the graduation process) for example for:
• The successful completion of a module (=> attach qualification to module as ”imparts“)
• The successful completion of a stage (=> see stage completion process)
• Other acquired competencies, which may be related to a certain program or without program
reference
© SAP AG
IHE102
13-22
1 3 .2 Confe r Qua lific a t ions – Ove rvie w
Student Lifecycle Management offers the possibility to confer qualifications to
students outside of the graduation process:
You can
Confer internal qualifications to a student
The qualification is linked to the student with or without a program reference
Confer the qualification conditionally
Note: external qualifications are transferred using the equivalency determination
process
© SAP 2009
In order to confer a qualification
• Go to the student file (PIQST00) – Qualifications tab page
• Create a qualification conferment:
- Enter details
- Enter a comment and a comment or note if required
- Enter functions …
- Save
External qualifications:
• You can transfer an external qualification. This is done in the “equivalency determination”
process.
• These qualifications are indicated by the transferred flag.
- In the student file, you can change conferred qualifications but not transferred qualifications.
There are further qualifications which are stored when a qualification is conferred to a student.
• This information is stored as additional data on the relationship
- Transfer flag: If a qualification has been transferred from external institutions
- Conditional booking flag: See next slide
- Stage: If the qualification refers to a stage (e.g. for stage completion)
Data file export for 'Diplomas on Demand‘:
• Program RHIQ_DIPLOMA_EXTRACT is provided to export conferred qualification data in a
format that is compatible with the Diplomas on Demand software offered by SCRIP-SAFE
International.
• Customizing path in IMG -> Student Lifecycle Management Master Data -> Qualifications ->
HyperLink: SIMG.CM_XX_QUAL01 Function for Conferring Institution
© SAP AG
IHE102
13-23
1 3 .2 Confe r Qua lific a tions – Confe r Qua lific at ion
Condit ionally
You can confer a qualification conditionally. This means:
The Qualification is not yet conferred or achieved by the student
and
The Qualification is handled as an open prerequisite for module booking
You can allow conditional bookings for open prerequisites = you can make a module
booking even if the specific prerequisite is not fulfilled
Prerequisite:
Qualification is prerequisite for the module
Conditional booking must be allowed
Set conditional booking indicator for relationship between SM and CQ
Remove condition when qualification is finally conferred
Change value to no pending prerequisite
© SAP 2009
Prerequisites (e.g. qualifications) which are defined by means of relationship 529 (needs
prerequisite/is prerequisite of) or 533 (is corequisite of) contain a conditional booking option. This
option enables you to book modules conditionally.
In cases where a prerequisite or corequisite is open (unfulfilled) when a module is booked, the
module can be booked conditionally by setting the conditional booking indicator.
Effects on qualification conferment:
• To confer a qualification conditionally, maintain the “conditional booking” flag and set it to
“manual conditional booking” on the additional data of the qualification conferment screen.
• The system handles this qualification then as an open prerequisite for module booking. You can
allow conditional bookings for open prerequisites. Then you can make a module booking even if
the specific prerequisite is not fulfilled.
- When you set a condition for qualification conferment manually, the system automatically
sets a condition for module booking if this qualification is the prerequisite for a conditional
booking. In this case, the conditional booking indicator must be set for relationship 529
between the qualification and module.
- When you finally confer the qualification, you must remove the manually set condition by
changing the value to no pending prerequisite and thus enable the system to execute module
booking unconditionally.
© SAP AG
IHE102
13-24
1 3 .2 Confe r Qua lific a t ions: T opic Summ ary
You should now be able to:
Understand the concept of qualifications
Confer qualifications to students outside the graduation
process
Maintain further information for qualifications
Confer qualifications conditionally
© SAP 2009
© SAP AG
IHE102
13-25
1 3 .3 Gra dua t ion Applic a t ion: T opic Objec tive s
After completing this topic, you will be able to:
Understand the term graduation readiness
Explain how students can apply for graduation via selfservice
© SAP 2009
This chapter provides an overview on this subject. You find details about the Graduation
Application Self Service in the relevant cookbook which is available on the Business Process
Platform (BPX) https://www.sdn.sap.com/irj/bpx/highered ->Student Lifecycle Management Best
Practices, Implementation Guidelines and Tutorials -> Graduation Cookbook.
© SAP AG
IHE102
13-26
1 3 .3 Gra dua t ion Applic a t ion Se lf Se rvic e
Graduation Application
A web-based self-service application allows a student to view their graduation
readiness (as determined by the institution) and apply for graduation.
The student can create a graduation application, change the data for an existing
application (such as Diploma Name) and cancel a graduation application.
The end result of the process is that a graduation fee is posted to the student‘s
account and a graduation assessment process is opened for the student‘s program
of study.
Each program of study for which you wish to support this process must have an
appropriate assessment object associated with it.
Each assessment object must also have the appropriate sessions of offering.
© SAP 2009
Web Dynpro Application: PIQ_GRADUATION_REQUEST
• To activate Web Dybpro applications, use transaction SICF and execute the report. Navigate to
the service via the following menu path: Default/host Sap BC Webdynpro Sap
Service (ex: piq_st_cos, Change of Specialization)
• Right click on the name of the service and select „Activate Service“.
• This menu also includes the option to test a service. Before portal iViews/roles are created, use
this option or transaction se80 to test the Web Dynpro applications.
© SAP AG
IHE102
13-27
1 3 .3 Gra dua t ion Applic a t ion Configura t ion
Required Configuration Settings for Graduation Process
Set Configurations and Configuration Requests:
For each Configuration Type you must enter Configuration parameters.
Identify the criteria to determine whether a student is ready to graduate
Define Fee Mode for Graduation Request
Determines how often graduation fees can be posted per academic session, per
student, per program type
Define Attributes for Individual Fees
Defines the accounting information necessary to post a Graduation Fee
Derive Fee Type for Graduation Requests
Assign the Fee Type as the Graduation Fee
© SAP 2008
Go to Processes in Student Lifecycle Management Academic Records Graduation
Application for Graduation Set Configuration and Configuration Requests
In order to utilize the Configuration Types, you must have activated the associated BADi
implementations. Refer to the Graduation Cookbook for further details.
All active configuration types will be automatically combined with the ‚AND‘ operator. If you do
not need certain criteria, do not activate those configuration types.
Enter Configuration Parameters for each active Configuration Type, e.g. Configuration Type
‚AGD‘, the following parameter is needed: OFFSET_DAYS – If a student‘s recorded Anticipated
Graduation Date is within this number of days, then the criteria is passed/true.
The Badi implementation for Audit Results is NOT supported for use with this self-service!
To define fee mode for Graduation Request go to the IMG of SLCM:
• Processes in Student Lifecycle Management
Academic Records Graduation
Application for Graduation Define Fee Mode for Graduation Request
• This configuration is necessary if the student is to be charged only one fee per session, regardless
of the number of Programs of Study. If a separate fee must be assessed for each Program of
Study, leave this entry blank. Note: In either case, separate fees will be charged if the student
applies for graduation for programs of different Program Types (e.g. Undergraduate and
Graduate), even if both are for the same academic session.
To define attributes for individual fees go to the IMG of SLCM:
• Student Accounting Fees
Other Fees Define Attributes for Individual Fees.
• Create a four-character abbreviation (such as „GRAD“) and enter the accounting information
(such as Main/Sub transaction) needed to post this fee to the student‘s account.
To derive fee type for graduation requests go to the IMG of SLCM:
• Processes in Student Lifecycle Management
Academic Records Graduation
Application for Graduation Define Fee Type for Graduation Requests.
• Use Goto Select Keys... To enable the Program Type and Program ID fields for derivation.
© SAP AG
IHE102
13-28
1 3 Gra dua t ion: U nit Sum m a ry
You should now be able to:
Perform the graduation process with SLCM
Maintain and track graduation results
Confer qualifications depending on the graduation results
Maintain qualifications
Confer qualifications outside of the graduation process
Explain the Graduation Application Self Service
© SAP 2009
© SAP AG
IHE102
13-29
© SAP AG
IHE102
13-30
I H E1 02 St udent Lifec yc le M anagem ent :
1 4 . St ude nt Acc ount ing
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009
© SAP AG
IHE102
14-1
1 4 . Ove rvie w St ude nt Ac count ing
Content:
14.1 Account Master Data
14.2 Fee Calculation Process
14.3 Audit of Fee Calculation and Invoicing
14.4 Grants and Grant Evaluation
14.5 Application Fees
14.6 General Information on Student Accounting
© SAP 2008
© SAP AG
IHE102
14-2
1 4 . St ude nt Acc ount ing – U nit Obje c tive s
At the conclusion of this unit, you will be able to:
Describe the Fee Calculation process and the audit
of fee calculation
Explain the parameters and data that influence the
Fee Calculation
Derive due dates and use different periods for Fee
Calculation and Posting
Understand the concept for Grants their evaluation
Get an overview on general information regarding
Student Accounting
© SAP 2009
Please note that details including the customization of Student Accounting are treated in the course
IHE203 Student Accounting. This chapter provides an overview on this topic only.
© SAP AG
IHE102
14-3
1 4 .1 Ac count M a st e r Da t a – T opic Objective s
After completing this topic, you will be able to:
Understand the Business Partner within Student
Accounting
Get an overview of Contract Accounts, Contract
Objects and their attributes
© SAP 2009
© SAP AG
IHE102
14-4
1 4 .1 Acc ount ing M a st e r Da t a
Student Accounting Uses Master Data From:
Student Lifecycle Management
Contract
Accounting
Student
Business Partner
Organization Unit
Contract Account
Program of Study
Contract Object
Module
Event Package
© SAP 2009
© SAP AG
IHE102
14-5
1 4 .1 Ac count M a st e r Da t a : St ruc t ura l
Ele m e nt s
Business
Partner
Contract
Account
Contract
Object
Natural person(s) or
organizations
Holds accounting information
Procedures per Business Partner that
are used for further processing of line
items.
© SAP 2009
SAP Business Partner can be represented by a Person or an Organization.
Contract Account: contains financial data (e.g. tuition and accommodation fees)
Contract Object: can be divided into two categories as follows:
• Tangible Contract Objects: may include a person, e.g. children, or property, e.g. house.
• Intangible Contract Objects: may represent specific fee categories, e.g. Tuition, Housing.
Examples for Contract Object Fee Types are Tuition and Insurance.
© SAP AG
IHE102
14-6
1 4 .1 St udent M a st e r Da t a
Student Lifecycle
Management
Contract
Accounting
Student
Business Partner
Student
Account
Contract Object X
Contract Object Y
When creating a
student Business Partner...
Contract Object Z
... accounting master data is
generated automatically
© SAP 2009
For every Student Business Partner the roles Student and Contract Partner are assigned
automatically.
Every student can have one Student Account. The student is related to the account as ”student
account holder“. You can define a sample Student Account by maintaining automatic derivations in
Customizing:
Student Lifecycle Management
Master Data
Student
Student as Contract
Partner.
The number and type of Contract Objects are generated is determined by Customizing. You have to
maintain the Contract Objects in Contract Accounting Customizing and flag them as automatically
created in Student Lifecycle Management Customizing..
Student and Business Partner data have to be mapped so that they can update each other regularly.
You do this in the Customizing:
Student Lifecycle Management Master Data
Student
Student as Business Partner.
© SAP AG
IHE102
14-7
1 4 .1 Cont rac t Ac count : St ruc ture a nd Func t ion
Contr. Acc. Category
Contract
Account
= Grouping for:
1. General Data
CA name
Account Management Data (Interest,
Clearing)
2. Payments
Payer
Incoming/Outgoing: Bank, Card,
Payer, Lock
3. Dunning/Correspondence
Invoicing
Dunning
Correspondence control/dunning/lock
Add./alt. recipients
© SAP 2009
For posting a document a contract account must be assigned to a business partner.
A contract account within IS-PS-CA represents a sub-ledger account and is necessary for open-item
accounting within IS-PS-CA. It is also a unit to group postings for the business partner.
The contract account category determines the following contract account attributes:
• Whether you are allowed to assign only one business partner or more than one to a contract
account
• Whether you are allowed to assign only one contract or more than one
• Whether you are allowed to maintain a contract account online
• The number range that is allowed for external or internal number assignment
• Whether it is a one-time account
The editing screens or data fields that you can use to edit the contract account.
Cross-partner data: The key under which the contract account is managed in the R/3 system and
under which it may have been managed in an operational system.
You can use the method “BAPI_CTRACCOUNT_EASYCREATE” to create a contract account
with sample values for external creating of contract account.
© SAP AG
IHE102
14-8
1 4 .1 Cont rac t Obje c t: M a st e r Da t a Struct ure
Business Partner/Contract Account
Accounts
payable/Accounts
receivable
1.
2.
3.
4.
Contract Object
1. Administration Data
Object Number
Object Type
Short Text
Relationship Data
Payment Data
Correspondence
Inbound Correspondence
2. Basic Data
Contract Object Category
Business Partner-independent
BDT
© SAP 2009
In the Business Data toolset you define the data structure of a contract object type. This is called the
contract object category. In the context of the BDT application object "contract object", the term
"category" is used as a synonym for "business partner role" (BP role).
SAP delivers three contract object categories ("PAAC with access to business partner and contract
account" , "PSOB without access to business partner and contract account", "PSDD only by Student
Lifecycle Management with access to business partner, contract account and due date schedule") .
Contract Accounting data are not compulsory. But NOTE: As soon as postings have been made
these data cannot be changed anymore.
© SAP AG
IHE102
14-9
1 4 .1 St ude nt M ast er Da t a – St ude nt Acc ount Dat a
Student account data
One contract account
Several contract objects
Student account data is created and updated automatically
When the student is created
When student Infotypes are changed
Customizing setting for automatic account update:
SPACE: Creation and update deactivated
X: Creation and update active
C: Creation active, update deactivated
© SAP 2009
You can maintain the setting for automatic account update in the IMG using the path: Student
Lifecycle Management
Master Data in Student Lifecycle Management Student Contract
Account
(De)Activate Automatic Student Account Creation and Update.
The following tab pages are provided in the student’s master data for entering student accounting
data:
• Fee Calculation Data
• Contract Objects
• Payment transactions
© SAP AG
IHE102
14-10
1 4 .1 Ac count M a st e r Da t a – T opic Ove rvie w
You are now able to:
Understand the Business Partner
within Student Accounting
Get an overview of Contract Accounts,
Contract Objects and their attributes
© SAP 2009
© SAP AG
IHE102
14-11
1 4 .2 Fe e Ca lc ulat ion Proc e ss – T opic Obje ct ive s
After completing this topic, you will be able to:
Describe the fee calculation process and audit the
results
Know how to set up a fee calculation process in the
system and define due dates
Understand the use of fee calculation documents and
delta postings
Understand application fees
© SAP 2009
© SAP AG
IHE102
14-12
1 4 .2 Fe e Ca lc ulat ion Proc e ss - Business Scena rio
Your university charges tuition fee. The amount depends
on the booked credit hours. Additionally, students of
physics have to pay for course material.
Employees get a discount of 10 % on tuition fees but not
on additional fees for consumption material that is used
during courses.
There is a meal plan.
© SAP 2009
© SAP AG
IHE102
14-13
1 4 .2 Fe e Ca lcula t ion Proc e ss - Ex a m ple
Tuition Fee: 2000
= 20 crh * 100
+
Course Mat:
= if SC = Physics
+
Employee:
+
Meal Plan:
300
= 5 meals per week
___________________________________
=
Total:
50
-200
= 10 % disc. of tuition
2150
© SAP 2009
© SAP AG
IHE102
14-14
1 4 .2 Fe e Ca lcula t ion Proc e ss - Ove rvie w
Academic data (student attributes, registrations, modules ...) is
read.
This data is passed to the pricing machine.
Pricing is done and the result is passed back to the fee
calculation.
FI-CA documents are posted to the contract account of the
student.
Academic
Data
DB
Pricing
FI-CA
document
Pricing result
© SAP 2009
© SAP AG
IHE102
14-15
1 4 .2 Fe e Ca lcula t ion Proc e ss - T ra nsa c t ion
Relevant Period/
Session
Student
File
study-related
post as
real open item ?
Master Data
Stdt Group
Fee Calc Trigger
Stdt
ID
Fee Fee
Group
Date Date
Student
Group
Process Mode
calculate/post !
calculate/post !
Stdt Fee Cat
Stdt Org ID
Fee Calc Proc
© SAP 2009
Student ID: Enter a single student or a range of students. Then the booking data are retrieved:
program of study, modules, etc.
Fee Group: Admission-related or study-related (hard-coded); expected re-registration is „studyrelated“. The fee calculation process mode is used only to calculate study-related fees. If you
calculate other fees (for example, administration fee) the SAP system ignores the process mode you
specified. This means: At the moment the fee calculation run only calculates and posts study-related
fees. For admission fees you have to use the ISR-related postings.
Process mode: Triggers Data Selection for Study-Related Fee Calculation. You can assign the
selection in Customizing (IMG Fees
Set Up Fee Calculation Process Modes for Study-Related
Fees). The SAP system provides three standard data selections as follows:
• Registration, re-registration data, or module booking data
• Admission data
• Expected re-registration data
Date: Derives all time-dependent data. When calculating a fee, the system automatically chooses the
period that is valid on the date of calculation. The calculation period might differ from the duration
of the session. If the system finds more than one active period it will execute and display all
calculations.
© SAP AG
IHE102
14-16
Fee Group
Stdt Org ID
Stdt Fee Cat
Stdt Group
1 4 .2 Fe e Ca lc ulat ion Proc e ss - Com pa re /Add Results
get
Fee Calc Proc
Fee
Calculation
Procedure
Pricing
Procedure
ADD
MIN
MAX
Pricing
Procedure
ADD
MIN
MAX
Pricing
Procedure
© SAP 2009
Student Group = Four-character alphanumeric key that defines a student group. For example:
• 0001 = Regular students
• 0002 = Exchange students
You enter it in the Student Master Data tab Individual Data
Student Fee Category = up to four characters alphanumeric key that uniquely identifies different fee
types for the students, e.g.
• RES = Resident Student
• NRES = Nonresident Student
You assign student fee categories to the students in the student master data maintenance tab Fee
Calculation Data. And you maintain the condition records for each student fee category in all pricing
procedures. Then the SAP system can derive the different tuitions or fees for each student according
to the student's fee calculation procedure.
Student Org ID = each student must be assigned directly or indirectly to an organizational unit.
Fee Group = admission-related or study-related (see above)
© SAP AG
IHE102
14-17
1 4 .2 Fe e Ca lcula t ion: Pe riods and Proc esse s
Fee Calculation Period
Time reference for fee calculation, posting and processing
You calculate a fee with reference to a certain period in the Academic Calendar. Therefore,
you define a
Fee Calculation Period
any four digit key
and assign to it:
Academic Year
2008/2009
Academic Session
Fall Semester, Summer Session
You can assign one or several years and sessions to a period. Usually you will assign one
year and one session to it.
The period key also serves to assign payments.
Note: Fee Calculation is now possible by Period Key, rather than Fee Calculation Date only
© SAP 2008
In the last step you define exact start and end dates for each period in the IMG, not in the academic
calendar! IMG path: Student Accounting Basic Settings Maintain Fee Calculation Period.
When calculating a fee the system automatically chooses the period that is valid on the date of
calculation. The calculation period might defer from the duration of the session.
If the system finds more than one active period it will execute and display all calculations.
Features inlcuded in the Fee Calculation Process
• Delta posting (Self-correcting program)
• Manual corrections are possible
• FM- and CO-Integration
• Single and mass runs
• Parallel processing with variable package size
• Event-triggered fee calculation is possible
• Flexible due date determination
Fee Calculation can be based on different credit values (rather than just Optimum Credits): IMG:
SLCM Student Accounting Fees Pricing Pricing Procedures Maintain Credit Type
for Pricing
• 0 = Optimum (from Module data)
• 1 = Minimum (from Module data)
• 2 = Maximum (from Module data)
• 3 = Attempted (from Module Booking)
• 4 = Module Value (from Module data)
Multiple booking statuses can be mapped to a single value for Fee Calculation. This reduces the
number of condition records needed. Example: Map ‘successfully completed’ and ‘unsuccessfully
completed’ to ‘booked’ for pricing purposes
• IMG task: SLCM Student Accounting Fees Pricing Pricing Procedures Map
Module Booking Statuses for Fee Calculation
© SAP AG
IHE102
14-18
1 4 .2 Fe e Ca lc ulat ion: Fe e Distribut ion I nfot ype
Fee Distribution’ is available for the following Objects:
O, SM, SE, SC, CG, and F
The Infotype allows for Tuition Fee Distribution to be defined based upon
a Section or Campus, for example Tuition Posting by Academic
Session (Sub-Type provides mapping to an Academic Session).
Individual Fee Calculation results (e.g. amounts calculated for specific
modules) can be saved (‘Per Item’ tuition fees)
© SAP 2009
Infotype ‘Fee Distribution’ is available for the following Objects:
• O, SM, SE, SC, CG, and F
• The Infotype allows for Tuition Fee Distribution to be defined based upon a Section or Campus,
for example
- Tuition Posting by Academic Session
• (New Sub-Type provides mapping to an Academic Session).
• Individual Fee Calculation results (e.g. amounts calculated for specific modules) can be saved
(‘Per Item’ tuition fees)
© SAP AG
IHE102
14-19
1 4 .2 Fe e Ca lc ulat ion Proc e ss: Due Dat e Sc he dule
Due Date Schedule
Due Date Schedules (DDS) describe
how to split up liabilities into a payment plan and
when payment is due (for each of the partial payments)
Partial Payments
can consist of:
a percentage (of the total amount)
a fixed amount
the rest
NOTE: Each partial payment is an original open item which itself can be
split up into an installment plan.
© SAP 2009
A DDS leads to a single due date or a sequence of due dates according to a time limit or time limit
sequence. The due date schedule is used to apportion liabilities and determine when payment is due.
A DDS is a required entry even if you do not want to apportion the liability. In that case, you have to
create a DDS with only one payment date.
DDS is set up in a generic way using TLS and TL which are assigned to actual dates via the
academic calendar – can be reused for different periods as long as business rules do not change.
Concept compatible with handling of dates in Student Lifecycle Management
used in several processes (e.g. last booking date in booking rules and DDS).
© SAP AG
IHE102
TL and TLS can be
14-20
1 4 .2 Applica t ion Fe e s
Typical Business Scenario:
Students have to pay a fixed fee per (admission) application
(Undergraduate, Graduate, International Admission)
The appropriate Fee Amount and Revenue Account is defined by the system.
They are given the option to pay this fee online via credit card
The application is supposed to process only after the fee has been paid.
Features:
1. Function module which authorizes a credit card number and posts a document
on the student‘s account.
2. Function module to set a customer status at the application when the fee has
been paid.
3. The definition of a wait event in the workflow is necessary. Process is continued when status
Fee paid has been set.
4. The Application Fee Requests (ISR) can be used to process Application
Fees on the web.
© SAP 2009
© SAP AG
IHE102
14-21
1 4 .2 Fe e Ca lc ulat ion Proc e ss – T opic Sum ma ry
You are now able to:
Describe the fee calculation process and audit
the results
Know how to set up a fee calculation process in
the system and define due dates
Understand the use of fee calculation
documents and delta postings
Explain Application Fees
© SAP 2009
© SAP AG
IHE102
14-22
1 4 .3 Audit of Fe e Calc ulat ion – T opic Obje ct ive s
After completing this topic, you will be able to:
Describe the fee calculation process and audit the
results
Know how to set up a fee calculation process in the
system and define due dates
Understand the use of fee calculation documents
and delta postings
© SAP 2009
© SAP AG
IHE102
14-23
1 4 .3 Audit of Fe e Ca lc ula t ion
The Fee Calculation produces FI-CA documents:
Financial Documents -> Contract Accounting
Fee Calculation Documents -> Analysis & Invoicing
Fee Calculation History
Tables: CMACDB_*
Header:
Student data, fee calculation parameters and final result including manual adjustments
Details:
Snapshot of calculation basis, i.e. current bookings (program of study and/or modules
with event package)
FI-CA documents:
New and old documents, documents for manual adjustments
Price per item (optional)
The condition records are not stored
© SAP 2009
The fee calculation creates Student Lifecycle Management Fee Calculation Documents in addition
to financial (FI-CA/contract accounting) documents. These Student Lifecycle Management
documents can be used for audits, analysis and invoicing since they contain academic information, i.
e. Program of Study or Modules and relevant Event Package, used in a particular fee calculation run.
The Fee Calculation Document Header (table CMACDB_FEEHD) contains the overall results for
all manual and mass runs. The single fee run for an individual student may include manual
adjustments.
The Fee Calculation Document Details are stored in tables:
• CMACDB_FEESC, CMACDB_FEESM, CMACDB_FEEFICA, CMACDB_ITEMRES
Note:
A fee calculation run may produce Fee Calculation Documents but not Financial Documents (FICA).
• Example: When the delta amount of a fee posting equals 0 then a Fee Calculation Document is
created but no Financial Document is posted. This could happen when a student adds and drops
bookings which do not change the fee amount.
The user must have authorization to create or display Student Lifecycle Management fee calculation
documents. (Authorization object: P_CM_FCDOC)
© SAP AG
IHE102
14-24
1 4 .3 Audit of Fe e Ca lc ula t ion and Invoic ing –
Fee Ca lcula tion H ist ory
Fee calculation documents with detailed results are created for better analysis.
Results can be used for successful fee calculation mass runs (Fee Calculation History) .
Exceptions: Runs with errors and simulation runs
The data used in the fee calculation are stored NOT the results.
When the user initiates the fee analysis for a particular student, the result is recalculated
based on the stored pricing information.
Therefore
Do not change the Pricing and Fee Calculation Procedures after use in production.
Use the Validity dates in the Condition Records.
The Application Log lists documents and errors for each student.
© SAP 2009
The Fee Calculation History uses the Student Lifecycle Management documents to provide an audit
trail of successful fee calculations. A simulation run is a fee calculation run which was not posted,
i.e. no documents have been stored. The collection of stored information allows a detailed analysis
of mass runs. You can access the Fee Calculation History by choosing: SAP Menu Student
Lifecycle Management
Student Accounting
Fee Calculation
Fee Calculation History.
For a single student, you can also trigger the Fee Calculation History transaction from the student
file (click on icon to the right of the calculator icon).
Note: Before you can store Student Lifecycle Management Fee Calculation Documents, you need to
set up the necessary configuration: IMG: Student Lifecycle Management
Student Accounting
Fees
Posting
Storing the price per item may be irrelevant for institutions with fee caps. It may also impact
performance. This feature is switched off in the standard delivery.
The condition records are not stored in the Fee Calculation History since they are already available
in the IMG where the information is accessible by date.
Recommendation: Always include the validity dates (start & end dates) when defining condition
records. If the price changes then insert a line with the new price and the appropriate start date.
You access the Application Log via: SAP Menu
Accounting
Fee Calculation
Student Lifecycle Management
Student
Application Log.
The log provides:
• quick statistics on the number of students processed in a particular run and the total number of
messages by message status, i.e. errors (red), warnings (yellow), and successes (green).
• detailed information by student (filter by message status: select the desired status and deselect the
others)
• detailed error message(s) per student (click on „?“)
© SAP AG
IHE102
14-25
1 4 .3 Audit of Fe e Calc ulat ion and I nvoic ing –
Se le c t ion M et hods for Fina nc ia l M ass Act ivitie s
Selection methods are available for the Fee Calculation and Fee Calculation History
and standard financial mass processes.
Selection Methods:
STNR = Students by Student
Number with Variant “all”
STNS = Single Student
© SAP 2009
Selection methods are available for fee related mass processes and standard FI-CA processes.
SAP delivers two selection methods. The variant is always customer-defined. You can also define
additional customer-specific selection methods.
IMG Path: Student Lifecycle Management
Settings
Student Lifecycle Management Processes
General
Selection Methods
The selection methods can now be used in FI-CA mass activities as well. SAP delivers group frame
9150 “Student Lifecycle Management : General Student Selection”. This group frame can be used to
develop customer-specific layouts for the relevant mass process.
IMG: Student Lifecycle Management
Student Accounting Basic Settings
Use of Selection
Methods in Mass FI-CA Activities (provides good documentation of required definitions)
IMG: Financial Accounting
Contract Accounts Receivable and Payable
Define Layouts for Mass Activities
© SAP AG
IHE102
Technical Settings
14-26
1 4 .3 Audit of Fe e Ca lc ula t ion and Invoic ing –
T opic Ove rvie w
You are now able to:
Describe the fee calculation process and audit
the results
Know how to set up a fee calculation process
in the system and define due dates
Understand the use of fee calculation
documents and delta postings
© SAP 2009
© SAP AG
IHE102
14-27
1 4 .4 Gra nt s and Gra nt Eva lua t ion – T opic
Obje c t ive s
After completing this topic, you will be able to:
Understand the Student and Grant Master Data of
Grants and their evaluation
© SAP 2009
© SAP AG
IHE102
14-28
1 4 .4 Gra nt s and Gra nt Eva lua t ion: Busine ss
Sc ena rio
Your university processes financial aid and other public and
private sponsorships.
A student expects a grant that covers a portion of the
tuition fees. You want to record the process from the
expected aid to disbursed aid in the accounting system.
© SAP 2009
© SAP AG
IHE102
14-29
1 4 .4 Gra nt s and Gra nt Eva lua t ion: Sponsor
Ma st e r Da t a / Sponsor Acc ount
Student Lifecycle Management
Contract Accounting
Sponsor
Business Partner
Define Grants and
Maintain Grant
Master Data
Sponsor
Account
Grant 1
Sponsor
Account
Grant 2
Name Grant
Grant Type
SP Pattern
Sponsor Name
Sponsor Account
Internally/externally
administrated
Re/Payment
FM Area, Fund
Sponsor
Account
Grant 3
© SAP 2009
IMG activities are grouped into four categories:
Basic Settings (applies to internally and externally managed grants)
Grant Management with the Student Lifecycle Management System
• i.e. grants managed internally in Student Lifecycle Management
Grant Management with External System
• i.e. grants managed externally in a 3rd party software package
Posting (applies to internally and externally managed grants)
• IMG: Student Lifecycle Management > Student Accounting > Grants
In Student Accounting you create a student object and a Business Partner object and link the two
together. For sponsor accounting, you link a grant to a sponsor account. However, since contract
accounts or contracts have to belong to at least one Business Partner, you have to create a Business
Partner for every sponsor.
Most sponsors offer just one grant.
Some government agencies may offer multiple aid programs as depicted above
SLCM uses the following terminology in grants and grants evaluation:
• Grants (also known as Financial Aid/Sponsoring
• Appropriations (to describe grants patterns)
• Grant Prerequisite Types
• Grant Disbursement Types
© SAP AG
IHE102
14-30
1 4 .4 Gra nt s and Gra nt Eva lua t ion - Financ ia l
Aid Disburse me nt s Pre pa ra t ion
Before you are able to calculate and post financial aid, the following steps
must be executed:
1. Sponsor Master Data: Business Partner, Sponsor Account
2. Grant Master Data: Payment Conditions, sponsored fees, other rules
3. GL Account/FM Determination Rules: Main/SubTA for sponsor and student,
document type and number ranges
4. Student Master Data - Sponsor tab: which grant, which amount, under which
conditions, when?
© SAP 2009
Steps 1 - 3 are necessary for externally and internally managed aid
Step 4:
• For internally-managed aid the information required in this step has to be entered manually
• For externally-managed aid the interface will update the sponsor tab.
Exclusion of Estimated Aid from Sponsor's Account
Customers can indicate for each grant, whether estimated or anticipated aid postings should appear
on the sponsor's account.
© SAP AG
IHE102
14-31
1 4 .4 Gra nt s and Gra nt Eva lua t ion - Financ ia l
Aid a nd Sponsoring Configura tion
For sponsorships and financial aid consider the following:
1. Is it an internally or externally-managed aid?
2. Which Fees are sponsored? E.g. all costs, tuition, special class, housing
3. Under which conditions is the aid granted? E.g. minimum of credits, certain
Program of Study, certain courses
4. What are the payment conditions? (Up to) a certain percentage, (up to) a certain
amount
5. What are the process steps? When is it disbursed? Shall it be displayed in the
student account? e.g. expected, awarded, accepted and disbursed
6. Where shall they be posted to? Which GL- Accounts and FM Assignments are
appropriate?
© SAP 2009
Grant Types can be used to control the posting of financial documents in contract accounting.
For Grant Status see the following example:
A university defines the following process steps in connection with private sponsors:
• To be defined = student told that he will apply for aid
- No aid shall be displayed or calculated yet
• Expected = student told that he actually applied for aid and for which amount
- Aid can be calculated as expected aid and shall be posted as planned document
• Confirmed = student said that he got the confirmation from the sponsor (and accepted it)
- Aid shall be calculated and disbursement is authorized; open item shall be posted on student
account and on sponsor account
• Cancelled = sponsor did not pay/student will not use aid
- Postings shall be reversed
Note that for internally managed aid customers can define their own statuses. That might be required
if an institution records e.g. only confirmed financial aid.
© SAP AG
IHE102
14-32
1 4 .4 Gra nt s and Gra nt Eva lua t ion
Grant Evaluation
Used for sponsored students
Definition of conditions is possible
Different payment types are possible
The result will be posted as credit on the student‘s account
Expected aid could also be calculated
© SAP 2009
Grants and Grant Evaluation distinguishes between internally and Externally Managed Aid:
Externally-managed aid
• The process from application for aid until final disbursement is triggered and controlled with an
external software
• The relevant information for posting comes into Student Lifecycle Management through an
interface
• In Student Lifecycle Management the incoming information has to be reflected in corresponding
data
Internally-managed aid
• The different steps until the disbursement of the aid are managed within Student Lifecycle
Management
• No interface is needed
• All relevant information is maintained within Student Lifecycle Management
Default Grant Details
• When the user assigns internal grants to a student on the student master data screen, the default
values for the grant details are automatically copied when the Detail Grant Assignment button is
chosen.
• The user can change the default values.
• Default conditions can be assigned to internal grants as well.
© SAP AG
IHE102
14-33
1 4 .4 Gra nt s and Gra nt Eva lua t ion – T opic
Sum m a ry
You are now able to:
Understand the Student and Grant Master Data of
Grants and their evaluation
© SAP 2009
© SAP AG
IHE102
14-34
1 4 .5 Gene ra l I nforma t ion on St ude nt
Ac count ing – Int e gra t ion Sce na rios w it h PS-CD
SAP Business Partner
PS-CD/Student Acc.
FI-CA
FI
SLCM
HR
The SAP Business Partner and its Master Data Structure represents an
Integration of Student Lifecycle Management with the accounting functionalities of
Public Sector Collection and Disbursement.
© SAP 2008
© SAP AG
IHE102
14-35
1 4 .5 Gene ra l I nforma t ion on St ude nt
Ac count ing – Int e gra t ion Sce na rios w it h PS-CD
Fee Calculation
FI-CADocuments
Grant Evaluation
FI-CADocuments
Application Fees
FI-CADocuments
PS-CD
© SAP 2008
© SAP AG
IHE102
14-36
1 4 .5 Gene ra l I nforma t ion on St ude nt
Ac count ing – H olds and Re ce iva ble Proce sse s
Financial Holds
Prevents students with outstanding fees from further Module-Bookings
Registrations are based on the same characteristics as other holds
Receivable Processes
Request
Inbound correspondence (request)
Dunning
for overdue receivables (e.g. tuition fees) or additional receivables (e.g.interest)
Payment
e.g. Cash, Check, payment card, bank transfer
Clearing
Defines how an open item in an account is assigned to an offsetting item to produce zero
balance. Student Accounting distinguishes between complete and partial clearing.
© SAP 2009
Financial Holds
• Setting is integrated into dunning runs
• A financial hold can be removed manually by an authorized user, automatically by doing a
payment or if the dunning run which set the hold is canceled
Request
• Inbound correspondence (request) represents a business partner‘s obligation to file a written item,
such as a letter, application, statement, declaration, tax return, confirmation. The correspondence
request is generated based on the rule stored in the contract object.
Dunning
• A business partner (student, sponsor, etc.) is dunned for overdue receivables (tuition fees, library
fines, parking tickets) or/and additional receivables (service charges, interest). A dunning
procedure determines the conditions and actions related to the dunning.
Payment
• The following incoming payments are initiated by the customer: Cash, Check, payment card,
bank transfer, Payment Forms and open items are invoiced and dunned.
Clearing
• In clearing the amount due equals the amount paid
• Rules for clearing are customized as clearing variant. The clearing variant is either assigned to a
contract account or the system derives it from hard-coded clearing types.
© SAP AG
IHE102
14-37
1 4 . Ove rvie w St ude nt Ac counting: U nit
Sum m a ry
You are now able to:
Describe the fee calculation process and the
audit of fee calculation
Explain the parameters and data that influence
the fee calculation
Derive due dates and use different periods for
fee calculation and posting
Understand the concept for grants and their
evaluation
Get on overview on general information
regarding student accounting processes
© SAP 2009
© SAP AG
IHE102
14-38
I H E1 02 St udent Lifec yc le M anagem ent :
1 5 . T ools
1. Academic Structure and Curriculum Management
2. Academic Calendar
3. Event Planning and Class Scheduling
4. Student Data Maintenance
5. Admissions
6. External Work and Equivalency Determination
7. Program Registration
8. Course Registration/Module Booking
9. Grading, Assessments, and Examination
10. Attendance Tracking
11. Audits
12. Progression
13. Graduation
14. Student Accounting
15. Overview on Tools (Correspondence, etc.)
© SAP 2009
© SAP AG
IHE102
15-1
1 5 . T ools
Content:
15.1 Academic Services
15.2 Audit Trail
15.3 Selection Methods
15.4 Mass Processes
15.5 Correspondence
15.6 Archiving
15.7 Authorizations
15.8 Rules and Regulations
15.9 Reporting
© SAP 2009
© SAP AG
IHE102
15-2
1 5 . T ools
After completing this unit, you will be able to:
Know about Student and Faculty Self Services in Student Lifecycle
Management
Understand the audit trail in Student Lifecycle Management including
activity documents and change documents
Understand the concept of Selection Methods
Understand the correspondence concept in Student Lifecycle
Management
Understand which data can be archived
Understand the authorization concept used in Student Lifecycle
Management
Explain how Administrative Rules and Academic Regulations can be
set up with the system
© SAP 2009
© SAP AG
IHE102
15-3
1 5 .1 Ac ade m ic Se rvic e s - Obje c t ive s
After completing this topic, you will be able to:
Understand the Academic Advisor functionality
Describe additional Faculty Self Services
Describe the User Interface for Students
© SAP 2008
© SAP AG
IHE102
15-4
1 5 .1 Ac a de mic Advisor Use r I nt erfa c e Fe at ure s
Advisor Work Center
Worklist of assigned students and search option
Ready to use BW Reports and option to configure additional reports
Service Map (e.g. Equivalency Determination Service and Audit Simulation)
Student Info Center
Student Factsheet with personnel and communication data
Academic overview and status information
Option to customize displayed views and contexts
Application Service
Module Plan functionality and Audit Check
© SAP 2009
The Advisor Work Center includes the following features:
• Service Links
• Collaboration
• Work List
• Quick Search
The purpose of the Student Info Center is to
• Identify the student
• View the information needed for advising, e.g. academic record
• Modify necessary information, e.g. set or remove holds
• Start related services, e. g, propose modules for course booking
Advisors can give proposals for module booking with the help of the application service Module
Plan.
For view the Implementation Cookbook for the Academic Advisor User Interface please go to the
BPX for HER at: https://www.sdn.sap.com/irj/sdn/bpx-highered
© SAP AG
IHE102
15-5
1 5 .1 Ac a de mic Advisor Use r I nt erfa c e Be ne fit s
Advisor Work Center
Advisors can access all required functions and services at a single entry point
All assigned students are visible at one view and additional ones can be searched for
Emails can be sent to individual students or group of students directly from the worklist
Student Info Center
Up-to-date student information is available in real time
User interface can be configured and customized to meet advisor’s needs
Advisors can quickly get an overview on the student’s status and academic standing
Booking (Module) Plan
Allows students and advisors to plan for successful program completion
Flexible search capabilities (Credits, Day/time, Instructor)
Seamless integration with Degree Audit and Advisor UI
© SAP 2009
Features of the Booking Plan Degree Audit:
• Audit page displays audit check results, which indicate whether a student has fulfilled
requirements of a program of study
• Detail information on an audit check is available
© SAP AG
IHE102
15-6
1 5 .1 Furt her Fa culty a nd Adm inistra tive Servic e s
Web request form for new Courses (w/ Workflow)
A web-based faculty self-service application allows faculty members to request that a new
course be added to the course catalog.
The system contains a workflow template that handles the routing of the request to the
department head and to the registrar's office for approval.
Event Planning UI w/Room Search and Faculty Workload
web-based user interface for searching for rooms based on location, capacity, equipment, and
availability. Included is a web-based view of room details with a Weekly Calendar view of
room availability and the contact person for the course.
Transcript Quick-Entry Web application
Easy maintenance Web Dynpro application for external transcript
Allows editing existing transcript information
© SAP 2009
New course request Web Dynpro: PIQ_COURSEREQUEST and workflow template
CRG_Approval (29800012)
Event Planning Web Dynpros:
• PIQ_ROOMINFO
• PIQ_ROOMSEARCH
Transcript Web Dynpro: PIQ_MAINTAIN_TRANSCRIPT
(For students requesting a transcript via self service Web Dynpro PIQ_ST_TRANSCRIPT_REQ is
available)
© SAP AG
IHE102
15-7
1 5 .1 St ude nt U ser I nt e rfa c e Fe at ures
A user interface (UI) is available for students at higher education institutions. The
Student Web application allows students to access a number of self-services from a
single entry point.
The Student UI groups together various self-services that a student can access
through a page in the portal, such as the Course Registration Web application
© SAP 2009
Prerequisites
• This function is available if you have activated the business function
(ISHERCM_UI_STUDENT).
• You have uploaded the portal content for Student role to the portal.
• You have mapped the student's user to his or her student number in the back-end system.
You have made the settings in Customizing for Student Lifecycle Management under Role-Based
Web UI Student .
© SAP AG
IHE102
15-8
1 5 .1 Ac ade m ic Se rvic e s – Sum ma ry
Now you are able to
Understand the Academic Advisor functionality
Describe additional faculty services
Describe the features of the Student User Interface
© SAP 2009
© SAP AG
IHE102
15-9
1 5 .2 Audit T ra il
After completing this topic, you will be able to:
Explain how data changes are tracked in Student Lifecycle
Management
Understand the difference between activity documents and
change documents
Explain what an activity is and where activities are used
© SAP 2009
© SAP AG
IHE102
15-10
1 5 .2 Audit T ra il – Ove rvie w
Change admission application:
Student: Andrew London
Program: B.A. History => B.A. Nat. Science
SAVE
changes
Acad. Year: 2008
Stage: 2 => 1
Activity
Documents
Belongs to
es
rit
w
writes
Application
Data
can be linked
Change
Documents
© SAP 2009
To track master data changes and changes within administrative processes, an Audit Trail enables
you to keep track of which data was changed when and by whom. Student Lifecycle Management
offers two concepts: Change Documents and Activity Documents.
• Change Documents: log master data changes and always refer to an Application.
• Activity Documents: log business activities and always refer to a Student.
• Change Documents: can be linked to an Activity Document.
Example: “Change Application” activity:
An Admission Record with the status “undecided” is changed.
• The system writes a Change Document for this admission record logging all field changes.
• It also writes an Activity Document for the student and the “Create Application” activity. The
system links the Activity Document to the Change Document for the admission record, thus
creating a link between the business audit trail and technical audit trail.
© SAP AG
IHE102
15-11
1 5 .2 Audit T ra il – Cha nge Doc um ent s
Change Documents show the technical audit trail – functions are:
Record changes to database tables
Are mainly used for master data objects
Example: Change documents for the student’s address
Cannot be deleted or changed
Can be archived
Change documents are written for:
Business partner data
Contract account data
Contract object data
Appraisal data (grading)
Requirement profiles
..........
© SAP 2009
When you change student master data, the system logs changes in the infotypes by creating change
documents. To view the change documents in student master data, choose:
• Extras → Change Documents → For this Student
• Extras → Change Documents → For this Tab Page
Also, changes for registration, specializations, equivalency determination etc. are logged via change
documents.
Change documents for admission, module booking, appraisal, etc. and the link to activity documents
are only recorded if the creation of change documents is activated for Infotype 1001, relationships
506 and 530. You can activate this in IMG using the path: Student Lifecycle Management → Basic
Settings → Change Documents.
© SAP AG
IHE102
15-12
1 5 .2 Audit T ra il – Ac t ivity Doc um ent s
Activity Documents show the business audit trail – functions are:
Keep a record of activities in Student Administration
Can contain additional information
Example: Module Booking Context
Cannot be deleted or changed
Can be archived
Example: Keep record of all registration activities for a student including
Registration
Re-registration
Leave of absence
Change of program
De-registration
Cancellation of all actions
© SAP 2009
Activity Documents are used to log student life cycle processes, such as all Registration. They
provide an audit trail that can be displayed in the Activity Documents tab page of the Student File.
For every Activity Document all fields of the document header are displayed in the detail view. If
further details are logged for an activity, then those details are displayed as additional tab pages in
the activity document detail display.
© SAP AG
IHE102
15-13
1 5 .2 Audit T ra il – Ac t ivitie s a nd Ac t ivit y
Docume nt s
The system writes Activity Documents automatically
Whenever a process step declared as an activity is performed, an Activity Document is
created.
When Change Documents for database tables are recorded, a link between the change
document and the Activity Document is stored.
You can display an activity document overview in the student file
Name of the activity
Creation date and time, user who created the document
Name of the program for program-related activities
Details for selected activities
Detail data for activity (progression)
Change documents for selected activities (admission, module booking)
An authorization check for the display of activity documents is performed
© SAP 2009
Activity documents are written only for existing activities. Activities are delivered by SAP.
Activity documents are available for nearly all processes. For some processes, the activity
documents contain only headers. For others, also details are documented.
Authorization check for activity documents: You can only view activity documents if you have the
authorization for the activity itself or to display the data that is changed by the activity.
Example: In order to display an activity document for admission, you need the authorization to
display relationship 530 (Infotype 1001, subtype A530).
Note: Program RHIQPROC_DISPLAY is available for displaying activity documents across
multiple students:
• Selection criteria are included for choosing specific activities that should be included, such as
Admissions Execution or Change of Specialization.
• You can view detailed Change Documents for each activity document, by double clicking on the
activity document line.
© SAP AG
IHE102
15-14
1 5 .2 Audit T ra il: T opic Sum m a ry
You should now be able to:
Explain how data changes are tracked in Student Lifecycle
Management
Understand the difference between Activity Documents and
Change Documents
Explain what Activities are and where they are used
© SAP 2009
© SAP AG
IHE102
15-15
1 5 .3 Se lec t ions M e t hods: T opic Obje c tive s
After completing this topic, you will be able to:
Understand the concept of Selection Methods
Describe the usage of Selection Methods
© SAP 2009
© SAP AG
IHE102
15-16
1 5 .3 Se lec t ion M e thods – Conc ept
Selection Methods are used within Student Lifecycle Management to
generate a list of objects, such as Students or Modules, that can be included
in reports, correspondence generation, and other mass processing functions.
Most SAP-delivered processes and reports already allow for the use of
Selection Methods. However it is also possible to use Selection Methods in
customer-defined processes and ABAP reports as well as in mass
processing functions in Student Lifecycle Management. Furthermore, the list
of objects returned by a Selection Method can easily be further filtered using
additional report selection parameters.
Business Example: You wish to perform an admissions process (such as generating
correspondence) for only a subset of your applicants using specific selection criteria.
© SAP 2009
The available Business add-in (BAdI) HRPIQ00SELMETHOD can be used to implement the
Selection Methods that shall be used for selection of Student Lifecycle Management objects: IMG
for Student Lifecycle Management -> Processes in Student Lifecycle Management-> General
Settings-> Selection Methods-> BAdI: Selection Method
Customer selection methods can be created by implementing the BAdI. If customers create a
documentation for their BAdI implementation, they can display the BAdI documentation in the
application when they select this selection method by choosing Information (symbol) (see SAP
selection method STAT).
Transaction PIQSELT1 may be used to test selection methods. The result of Selection Method
testing depends on the user authorization. The result can therefore differ from the result of another
user. The selection methods check the user’s structural authorization and general authorization.
Specific activity (process) authorizations are not checked.
The output of a selection using a selection method are object-IDs which are used by the program.
Report program parameters have no influence on the selection method result.
Note that the report program cannot use the parameters of a selection variant.
A report program has a hard-coded selection method group assignment. The selection method group
determines which object type will be selected. Selection methods can only be assigned to a selection
method group if they support the object type.
Report programs often use an additional result filter to guarantee that only those objects which fulfill
a particular precondition are processed (for example, the program type condition checks if the
student has an admission or an open study segment).
© SAP AG
IHE102
15-17
1 5 .3 Se lec t ion M e thods – I m ple me nt a t ion
Selection Methods are organized in to Selection Method Groups. Each report
or process may only make use of a single Selection Method Group, so it is
important to include all relevant Selection Methods in the proper groups.
Steps:
Create the Selection Method Group(s).
Assign Selection Methods to Selection Method Groups.
Selection Method Group
Selection Method
Selection Variant
© SAP 2009
SAP delivers frequently used data selections as selection methods.
• The selection methods in a particular application are combined to a selection method group.
• Each selection method contains one or more selection variants. The selection variant is used to
fill the parameters of a selection method at the application level.
Implementation:
• In addition to the Selection Method Groups offered by SAP, customers may create their own.
This is done in the IMG: Student Lifecycle Management -> Student Lifecycle Management
Processes-> General Settings-> Selection Methods-> Assign Selection Methods to Selection
Method Group.
Example cases for Selection Methods and Selection Variants:
• You want to search for students by student numbers in Student Lifecycle Management (Selection
Method).
• You want to search for students by student numbers in Student Lifecycle Management between
100 and 200 (Selection Variant).
© SAP AG
IHE102
15-18
1 5 .3 Use Ca se s for Se le ct ion M et hods
Many times it is useful to use the output of one process as the input for another
report or process.
1. SAP offers the ability to use a file of Student Numbers as the input for any
Selection Method enabled process. In this way, a file of Student Numbers
could be produced from an external application, and the students indicated in
the file could be used for a Student Lifecycle Management process.
2. Selection Methods can also be used in delivered FI-CA transactions. These
generally process based upon selections of Business Partners. Since it is more
useful to select the student records to be processed based upon Student
Numbers, it is necessary to adapt certain FI-CA transactions.
© SAP 2009
The Selection Method ‘STNR’ provides the capability to upload a list of student numbers via a file.
The uploaded Text File should have one Student Number per line.
In the Selection Method Variant creation screen, select ‘Multiple Selection’ and then ‘Import from
Text File’.
The process to adapt FI-CA transaction in order to use them in Selection Methods is described in the
IMG: Student Lifecycle Management-> Student Accounting-> Basic Settings->Using Selection
Methods in Mass FI-CA Activities.
For details on this topic please view the Selection Methods Cookbook which is available on the
Business Process Platform for Higher Education (BPX) at https://www.sdn.sap.com/irj/bpx/highered
--> Knowledge Center -> Student Lifecycle Management Implementation Guidelines -> Audit Trail
in Student Lifecycle Management. The Selection Methods Cookbook provides a ABAP code
excerpt of a fully-functional example of how a Selection Method is properly combined with report
parameters. This sample program is not delivered but can be easily copied as text and pasted into the
ABAP editor (SE38).
© SAP AG
IHE102
15-19
1 5 .3 Se lec t ion M e thods – De live re d in SLCM
Admissions Data Selection Method (ADM2)
To select students based on Admissions data.
Graduation Related Selection Method (AGD)
To select students based upon progress classification, performance indexes, and
anticipated graduation date. The main use of this selection method is to identify
students who are likely to graduate at the same time.
Selection Method for Course Registration and Appraisals (APPR)
To select students based upon registration in specific courses and grade results.
Selection Method for Students with Conferred Qualifications (STCQ)
To select students that have specific qualification data
Selection Method for Student Master Data (BKGW)
The selection method has been enhanced to include a number of fields from the
Student Master Data, such as Organizational Assignment, Fee Calculation Data, and
Residency Data.
© SAP 2009
The delivered selection methods are part of the MP01 Mass Processing selection method group.
The Admissions Data Selection Method allows users to select students based on the following
admissions data:
• Academic Year and Session
• Various Admission Data fields
• Program of Study
• Specializations
• Student Master
• Student File
• Transcripts
• Test Scores
The only mandatory selection parameters are academic year and session. If multiple selection
parameters are filled in, they should always be treated with the AND operator.
• All parameters should be treated as optional.
© SAP AG
IHE102
15-20
1 5 .3 Se lec t ions M e t hods: T opic Sum ma ry
You should now be able to:
Understand the concept of selection methods
Describe the usage of selection methods
© SAP 2009
© SAP AG
IHE102
15-21
1 5 .4 M a ss Proce sse s: T opic Objec t ive s
After completing this topic, you will be able to:
Understand the Mass Processing functions delivered
with Student Lifecycle Management
Understand how to use Selection Methods with the
delivered mass processing functions
© SAP 2009
© SAP AG
IHE102
15-22
1 5 .4 M a ss Proce ssing Re port s - Ove rvie w
The following Mass Processing Reports are delivered with Student Lifecycle
Management to perform a mass administration process on a selected group of
students:
1.
2.
3.
4.
5.
6.
Assignment of Student Group and Fee Category
Mass-Processing of Holds & Statuses
Assignment of Module Booking Windows
Transfer of Course Registrations upon Cancellations
‘I’ to ‘F’ Grade Conversion
Update of Anticipated Graduation Date
© SAP 2009
You can access the reports in the SAP menu for Student Lifecycle Management -> Tools -> Reports
© SAP AG
IHE102
15-23
1 5 .4 M a ss Proce ssing Re port s
1. Mass Assignment of Student Group and Fee Category
Allows for assignment of a student group or fee category to a population of students
based upon flexible selection criteria, including admissions and registration data.
2. Mass Assignment of Holds & Statuses
Business Scenario:
Holds or Statuses can be used to restrict the students from performing certain campus
management processes. For example, universities can prevent students from
registering to courses if they have not paid the fees on time as per the schedule. This
restriction is time dependent.
Once the student satisfies the condition which caused for setting the hold, the
restriction can be removed by deactivating the hold/status.
Solution:
A report activates holds to a set of students in a mass process using flexible criteria.
© SAP 2009
Mass Assignment of Student Group and Fee Category
• Transaction PIQMPSTATTR
• Program RHIQMPSTUDENTATTR_ASG
• Select the „Clear“ attribute if you wish to initialize the Student Group or Fee Category for a
selection of students.
Mass Assignment of Holds & Statuses
• Both student and study-specific holds can be managed
• Available transactions and reports:
- Transaction PIQMPSTATUSIND
- Program RHIQMPSTATUSIND_SET
The Mass Assignment of Holds & Statuses uses the internally developed mass processing
framework from Student Lifecycle Management and follows the architecture of the framework.
Using the framework, the following were integrated with the reports:
• Schedule manager
• Selection methods
• Parallel processing
• Application log
© SAP AG
IHE102
15-24
1 5 .4 Ma ss Assignm ent of M odule Book ing Window s
3. Mass Assignment of Module Booking Windows
Business Scenario:
In universities certain students or groups of students need to be given priority for
course registration. For example students in higher progress classifications
(sophomore) should be allowed to register for courses before students from lower
progress classifications (freshman) register them.
Solution:
Module booking windows are assigned to specific groups of students within a mass
process, based on flexible selection criteria.
Module booking windows are time periods in which only the assigned students for that
booking window are allowed to book the course. In the above example, sophomores
could be assigned a module booking window different from freshman so that both are
not allowed to book the courses at a time.
© SAP 2009
Mass Assignment of Module Booking Windows
• Available transactions and reports:
- Transaction PIQBKGWINDOW
- Program RHIQMPBKGWINDOW_ASG
• In order to make use of the existing Selection Method BAdI HRPIQ00SELMETHOD (Select
students for assigning booking windows) needs to be implemented.
The mass assignment program can also be used to re-initialize the booking windows for groups of
students
Note that Booking Windows can only be applied in the described way if the associated Time Limits
are defined in the Academic Calendar
This mass processing functionality uses the internally developed mass processing framework from
Student Lifecycle Management and follows the architecture of the framework. Using the framework,
the following were integrated with the reports:
• Schedule manager
• Selection methods
• Parallel processing
• Application log
© SAP AG
IHE102
15-25
1 5 .4 M ass Tra nsfer of Course Re gist rat ions
4. Mass Transfer of Course Registrations upon Cancellations
Business Scenario:
Due to low enrollment numbers, the university decides to cancel a course (module) or
a section (event package) to which students are already booked (registered).
Solution:
Before canceling the module or event package, the student bookings on the module or
event package can be transferred to another module or event package or event. This
will allow students to still book another course which is needed to progress in their
studies. As a consequence, the students’ studies are not interrupted on cancellation of
the particular module or section.
The following scenarios are supported:
Transfer module bookings from one module to another module
Transfer module bookings from one event package to another event package. The
event package at the target can be from a different module.
© SAP 2009
Available transactions and reports:
• Transaction PIQMPMODBKG
• Program RHIQMPMODBKG_TRANSFER
Once an object is selected as the source, only students who have booked to that specific object will
be moved. For example, if a Module is selected, then students booked to the Module directly (with
no specific Event Package), will be moved. Students who have booked that Module with a specific
Event Package would not be moved in that case.
The Booking Context (Program Type or Program) does not change during this process. Rules are not
checked, aside from capacity. It is assumed that any overrides, exceptions, etc. that were granted for
the original Module Booking still apply.
Bookings will be moved in the order of the original bookings (determined by the time/date stamp of
the original booking activity). Once capacity is reached, the normal wait-listing and capacity rules
apply.
Simulation mode is available
The report for transferring the module bookings from module to module or from an event package to
another does not use the mass processing framework. The look and feel of this report is similar to
the other reports but the application log differs.
© SAP AG
IHE102
15-26
1 5 .4 ‘I’ t o ‘F’ Gra de Conve rsion M a ss Re port
5. ‘I’ to ‘F’ Grade Conversion Mass Report
Business Scenario:
During the grading process, there are situations where a student has not completed or
turned in enough coursework for the instructor to assign a proper grade.
Solution:
A grade of ‘Incomplete’ or ‘I’ is entered into the system.
The student has a certain amount of time, determined by the University, to complete
the work so that the ‘I’ grade can be changed.
If the student has not taken appropriate action by that date, and the instructor has not
granted an extension, the grade of ‘I’ is converted into a grade of ‘F’
-> Incomplete grade symbols are changed to Failed grade symbols, when a specific
configurable time limit in the Academic Calendar has been reached.
© SAP 2009
Transaction and Program:
• Transaction PIQMP_AGRCONVERT
• Program RHIQMP_GRADE_CONVERT
Related topics: correspondence form for notifying students of Incomplete grades and Appraisal userinterface (GUI and Self-Service) that allows instructors to enter an new deadline:
Steps:
• The date for the conversion of grades from ‘I’ to ‘F’ needs to be maintained as a Time Limit in
the Academic Calendar.
• Prior to the time limit, several jobs must be scheduled. The first is a correspondence job to
initially send a notification to students who have ‘incomplete’ grade symbols recorded. Students
must request extensions from their instructors (the ‘old-fashioned’ way). If the instructor wishes
to grant an extension, the new deadline for the extension will be stored in the ‘Latest Appraisal
Date’ field of the appraisal.
• The second job is a periodic job which checks to see if any deadlines have passed (includes the
standard deadline in the Academic Calendar as well as granted extensions), and automatically
converts the grade to a ‘Failed’ grade symbol.
• Any final reminders need to be scheduled as additional correspondence jobs.
• The actual grade symbol used to represent the ‘F’ is defined in the Mass Processing selection
screen, as are the grade symbols that represent the ‘Incomplete’ status.
Customizing:
• Define Deadline for Completion of Work in IMG. Specify the time limit you want to use for
completion of academic work by a student.
• Student Lifecycle Management
Student Lifecycle Management Processes
Incomplete Grades Define Deadline for Completion of Work
© SAP AG
IHE102
Appraisal
15-27
1 5 .4 M ass U pda te of Antic ipat e d Gra dua t ion Dat e
6. Mass Update of Anticipated Graduation Date
Business Scenario:
A university wants to select students who are expected to graduate at the same date.
Solution:
Selection Method ‘AGD’ (assigned to Selection Group ‘MP01’) is provided for selecting
students who are likely to have the same anticipated graduation date.
Transaction and Program :
Transaction PIQAGDUPDATE
Program RHIQAGDUPDATE
© SAP 2009
Prior to using the Selection Method, the desired implementations of the BADi
‘HRPIQ00_ST_DETERMINE’ must be activated. The implementations provide for the following
selection functionality:
• AGD – to select students based upon their currently assigned Anticipated Graduation Date
• AUD – to select students who have a specific Audit result stored
• PIX – to select students who have a specific value for certain performance indices
• PRG – to select students who have a specific Progression result
Activation of the BADi allows to use all of the selection criteria when creating a Selection Variant
for the Selection Method.
• This can be done via transaction SE18.
In order for the graduation date to be properly set, the appropriate Time Limit in the Academic
Calendar must be set in the IMG
• Student Lifecycle Management
Anticipated Graduation Date
Academic Calendar
Assign Time Limit for Calculation of
Note: The Time Limit must be defined within the Academic Calendar as well.
Use case: Students from the Selection Variant “AGD” will have their AGD for any full time
undergraduate program updated to be Spring (session 30) of academic year 2009-10 if you mark the
appropriate selection “Update AGD for Full Time Registrations”. If in addition the option ‘Replace
Existing AGD Date’ is checked, then also those students who have already a recorded AGD are
updated.
© SAP AG
IHE102
15-28
1 5 .4 M a ss Proce sse s: T opic Sum m a ry
You should now be able to:
Explain the Mass Processing functions delivered with
Student Lifecycle Management
Use Selection Methods with the delivered Mass
Processing functions
© SAP 2009
© SAP AG
IHE102
15-29
1 5 .5 Corre spondence : T opic Objec t ive s
After completing this topic, you will be able to:
Understand the correspondence concept
Know the basics about creating and printing documents
Explain how correspondence in Student Lifecycle
Management provides business process support
© SAP 2009
© SAP AG
IHE102
15-30
1 5 .5 Corre spondence – Ove rvie w
The Correspondence Tool enables documents to be printed Individually or
via Mass Processing.
The Correspondence Tool makes it easy for you to create correspondence related to
individual and mass requests.
The Correspondence Tool in Student Administration contains the functions you need to
output documents for the activities performed in Student Lifecycle Management.
Student Lifecycle Management uses the Print Workbench to print documents
The Print Workbench uses Smart Forms for configuration and layout of correspondence
forms.
© SAP 2009
© SAP AG
IHE102
15-31
1 5 .5 Corre spondence T ype s
The Correspondence Type represents an activity or a
type of correspondence within a process:
Student Lifecycle Management 01
ADMISSION PROCESSES
Student Lifecycle Management 00
STUDENT PROCESSES
Diploma certificates
Acceptance letter
Qualifications
Rejection letter
Progression results
Confirmation letter
Admission data
External test results
The Correspondence Tool can be used to print documents from
Admission and Student Processes.
© SAP 2009
The Correspondence Type defines the nature of the correspondence and the control attributes of the
correspondence process.
Correspondence Types belong to the Correspondence Tool.
Two Correspondence Types are defined in Student Lifecycle Management:
• Student Lifecycle Management 00: student correspondence
• Student Lifecycle Management 01: admission correspondence
© SAP AG
IHE102
15-32
1 5 .5 Corre sponde nc e T ool a nd Print Work benc h
Correspondence Tool
Correspondence Types
Print Workbench
Student
Lifecycle
Management
Customer
Form Classes
• are predefined data structures
specific to an application
• contain all the data that can be used
in the dependent application forms
• are responsible for providing data
used for correspondence within the
process
Form Class
You create Application Forms based on
form classes.
You can define several application forms for
each form class, e.g., different invoices for
diploma certificates, qualifications, and
acceptance letters.
Application
Forms
© SAP 2009
In Student Lifecycle Management form classes “admission” and “student “ are delivered. They are
part of the standard and owned by SAP.
You can delete the parts of a form class you do not require, but you must never change its nodes or
create additional nodes.
Application forms are created on the basis of form classes. Student Lifecycle Management provides
example forms that you may use to create your own forms.
You can adjust application forms to your requirements and enhance your functions with USER
EXITS.
You must always specify a form class for the application form.
You can use collections instead of application forms. A collection is a configurable and executable
row of application forms belonging to the same or different form classes.
You must define the output of the application form. For this purpose, the Smart Forms tool is used
by Student Lifecycle Management.
© SAP AG
IHE102
15-33
1 5 .5 Cre at e a nd Print Corresponde nc e
Student and admission correspondence can be created individually or in
bulk. There are specific transactions defined for this purpose:
Student Transactions
Admission Transactions
Create Student Correspondence
Correspondence
12/31/2009 – Transcript
Create Admission Correspondence
The created correspondence is displayed in the student
file.
The yellow triangle indicates that correspondence was
created but not printed.
10/12/2009 – Admission
Correspondence
12.12.2008 – Transcript
10.12.2008 – Admission
You can print the correspondence for one student
from the student file.
Printed correspondence is displayed in the student
file.
The green circle indicates that created
correspondence was printed.
© SAP 2009
Example for the generation of a student correspondence, created individually:
The student Andrew attended several courses last semester. For these courses, he received grades
and credits. He has now come to you to obtain his transcript for the last semester.
As an employee of the university you first generate the transcript using the “create student
correspondence” function and then print out the correspondence (transcript) you have created.
In order to output outgoing correspondence, that is, get printed documents, it is necessary to create
and print correspondence.
You can start the creation and print process with a mass processing transaction:
CREATE CORRESPONDENCE:
• Student Correspondence: Transaction: PIQCORRSTC
• Admission Correspondence: Transaction: PIQCORADMC
PRINT CORRESPONDENCE
• Student Correspondence: Transaction: PIQCORRSTP
• Admission Correspondence: Transaction: PIQCORADMP
You may also create the correspondence directly in the correspondence tab of the student file. This
allows you to create and print documents individually. Choose [Generate Correspondence] on the
Correspondence tab in the Student File to create and print Ad-hoc Correspondence. You need to
select Correspondence Type and Application Form to create or to create and print correspondence.
© SAP AG
IHE102
15-34
1 5 .5 Corre spondence – Print ing Run
The data which is stored in the correspondence container prior to
correspondence creation is determined for the correspondence print run and
transferred to the Print Workbench.
In a correspondence print run, you can print single or multiple items of
correspondence.
You can select the correspondence to be included in a print run in the same
way as you select the correspondence for a creation run.
Printing Run
Correspondence
Container
DB
Workbench
Central Development
Environment
© SAP 2009
Printing Correspondence – Features:
• Print Workbench (uses SmartForms)
• Print single correspondence item
• Print multiple correspondence items in mass runs
• Student file functions on the correspondence
• Tab page (after correspondence printing)
• Correspondence history
© SAP AG
IHE102
15-35
1 5 .5 Corre sponde nc e – Busine ss Proce ss Support
in St ude nt Lifec yc le Ma na ge me nt
Student Transcript
Adobe PDF-based form is available for official student transcripts (e.g. with quality
points, progression results, etc.)
‘Incomplete’ Grade Notifications
Adobe PDF-based student correspondence form to notify students that they have an
Incomplete grade recorded for one or more courses. They will also be notified about
the deadline for turning in their work, before the grade is converted to a Fail.
Enhanced Correspondence Send Control
Customers can assign a default correspondence delivery mechanism, (e.g. FAX, Email, or print), for each individual Correspondence Form.
Student Term Bill (invoice form) including
Debit or credit amount that the student has in a particular term
All term activity and estimated aid postings with outstanding items summarized by
due date
Program and course registrations for the student.
© SAP 2009
Incomplete grade notifications:
• Application form ISHERCMGRADE_INCOMPLETE
• IMG paths:
- Student Lifecycle Management -> Student Lifecycle Management Processes -> Appraisal ->
Missing Grades
- Student Lifecycle Management -> Student Lifecycle Management Processes -> Appraisal ->
Incomplete Grades ->Define Deadline for Completion of Work
• Settings for automatic notifications of missing grades:
- Transaction PIQAGR_SENDALRT
- Program RHIQAGR_SENDALERT
- IMG path: Student Lifecycle Management -> Student Lifecycle Management Processes ->
Missing Grades
Enhanced Send Control:
• IMG for Student Lifecycle Management -> Student Lifecycle Management Processes -> General
Settings -> Correspondence -> Technical Settings -> Assign Dispatch Control to Application
Form
© SAP AG
IHE102
15-36
1 5 .5 Corre sponde nc e – Busine ss Proce ss Support
in St ude nt Lifec yc le Ma na ge me nt
Enrollment Confirmation (Admissions Correspondence)
an Adobe PDF-based form, that can be included in an applicant's acceptance packet.
The new correspondence form allows the accepted applicant to confirm their
upcoming enrollment at the university by paying a deposit.
Module Correspondence
Correspondence can be generated using Module/Event as selection object
Transaction code PIQCORRSMC
© SAP 2009
Enrollment confirmation:
• Application form ISHERCM_SAMPLE_ADMISSION_CARD
• Customizing path in IMG: Student Lifecycle Management -> Student Lifecycle Management
Processes -> Admission, Registration and De-registration -> Admission -> Create Time Limit
for Enrollment Confirmation Fee
Module Correspondence:
• Designate relevant application forms in IMG: SLCM Processes in SLCM General Settings
Correspondence Basic Settings Define type of Module Correspondence
• Use Form Class ISHERCMSF_OFFER
© SAP AG
IHE102
15-37
1 5 .5 Corre spondence : T opic Summ a ry
You should now be able to:
Understand the correspondence concept
Know the basics about creating and printing documents
Explain how correspondence in Student Lifecycle
Management provides business process support
© SAP 2009
© SAP AG
IHE102
15-38
1 5 .6 Archiving: T opic Obje c t ive s
After completing this topic, you will be able to:
Understand the concept of archiving
Get an overview of data that can be archived
© SAP 2009
© SAP AG
IHE102
15-39
1 5 .6 Archiving – Da ta Arc hiving Roa dmap
Create Data
Student
Contract
Account
Registration and
Admission
Contract
Object
Module and
Event Booking
Posting
Documents
Program Type
Progression
Program
Progression
Archive data should be in the
reverse order of created data
ISR
Application
Academic
Record/History
Archive Data
© SAP 2009
Depending on an application’s specific requirements, different scenarios for archiving and deleting
data can be implemented.
• Writing and deleting are separated to ensure data security and database consistency. If an archive
file had an error and not all of the data was available, but the delete program deleted the data
from the database, the data would be lost (or at least very expensive to recover).
• The use of “Archiving Status” can prevent data loss that may occur if data that has already been
archived but not yet deleted is changed.
• For details on the subject please refer to the Archiving Guideline for Student Lifecycle
Management which is available at: https://www.sdn.sap.com/irj/sdn/bpx-highered -> Student
Lifecycle Management Best Practices, Implementation Guidelines, and Tutorials -> Archiving
and Deletion in Student Lifecycle Management.
• The following data are not considered for archiving:
- Academic Calendar
- Academic Structure
- Qualifications
- Academic Scales
© SAP AG
IHE102
15-40
1 5 .6 Archiving – Wha t c an be a rc hived (1)
Archiving Activity Documents
You can archive all activity documents (option: for selected activities) that were created
before a specified date.
Archive all activity documents for students who were de-registered within a specified time
interval.
Archiving Student Account Data
You can archive contract account and contract object master data for “inactive” students who
were de-registered from programs several years ago or any selected students.
Delete Event Bookings Without Archiving
You can delete all students’ event bookings for events that were finished before a specified
date.
Delete all students’ event bookings for students who were de-registered during a specified
time interval (precondition: the students do not have an admission or a registration).
© SAP 2009
There are different ways how you can access archived data in Student Lifecycle Management. The
first one is to use the Archive Explorer.
Enter transaction code SARA to enter the Archive Explorer in order to view archived data.
Transaction SARA is used for archiving administration data:
• Start of background processes Archive – Delete – Read - Reload
• Analysis of the archived tables
• Archiving job overview
• Print spool
• Management of the archived files
A second way is displaying activity documents within the application „student file“.
• On the tab page [Activity Documents] in the Student File, you can display the activity documents
which are created to track student administrative processes.
© SAP AG
IHE102
15-41
1 5 .6 Archiving – Wha t c an be a rc hived (2)
Archiving study data:
Preparation: Set archiving flag for study data
Display archived study data in the Student File and Academic Work Overview
Generate correspondence for student whose study data has been archived
Rebuild study data from the archive to the Student File
Archiving student master data:
Preparation: Set archiving flag for student master data
Display archived student master data via the Archive Explorer (not possible via standard
maintenance dialogue)
Archiving student related person data:
Archive business partners which are related persons to students
Preparation: Set archiving flag for related persons
Display archived data via the Archive Explorer
© SAP 2009
The system archives study data, student / applicant master data and data of related persons to
students which are flagged for archiving. The relevant students are selected with a selection method.
Set archiving flag for study data / student master data:
• You can set an archiving flag for the study data of students who are selected with a selection
method via report RHIQST_ARCHIVING_PREPARE or you set the archiving flag for one
student via the Student File.
Archiving of study data / student master data:
• You can manage the archiving of study data with the archiving object HRIQ_STYDT and the
archiving of student master data with the archiving object CA_BUPA, as well as the archiving of
student related persons.
• You can display archived study data in the Student File and Academic Work Overview.
• You can display archived student master data and related persons in the Archive Explorer
(SARE) with the archive infostructure SAP_HRIQ_BUPA1 in a technical view. You cannot
access archived student master data via the standard maintenance dialog.
• You can still generate correspondence for students whose study data has been archived.
• You can rebuild study data from the archive to the Student File, so that all academic work and
qualifications from a previous study period are available for Student Lifecycle Management
follow-up processes. Business case: If the student comes back to take another degree; if you want
to change the transcript after archiving.
© SAP AG
IHE102
15-42
1 5 .6 Archiving: T opic Sum ma ry
You should now be able to:
Understand the concept of archiving
Get an overview of data that can be archived
© SAP 2009
© SAP AG
IHE102
15-43
1 5 .7 Aut horiza t ions: T opic Obje c t ive s
After completing this topic, you will be able to:
Understand the authorization concept used within Student
Lifecycle Management
Explain the difference between composite roles and
individual roles
© SAP 2009
© SAP AG
IHE102
15-44
1 5 .7 Aut horiza t ions – Ove rvie w
Authorization concept of Student Lifecycle Management includes
General authorization
Student Lifecycle Management authorization for activities (processes) and applicationspecific checks
Structural Authorization
Authorizations needed for other application areas
Access to Business Partner
Access to Student Accounting
Access to Training and Event Management
© SAP 2009
Users also require authorizations for functions of the application areas which are integrated in
Student Lifecycle Management (Business Partner, Student Accounting, Training and Event
Management).
Student Lifecycle Management authorization concept is built upon the ERP authorization concept.
• For details on the subject please refer to the Authorization Guideline for Student Lifecycle
Management which is available at: https://www.sdn.sap.com/irj/sdn/bpx-highered -> Student
Lifecycle Management Best Practices, Implementation Guidelines, and Tutorials ->
Authorization in Student Lifecycle Management.
© SAP AG
IHE102
15-45
1 5 .7 Aut horiza t ions – Role s and Func t ions
Roles
Roles are classified into composite roles and individual roles
Composite roles consist of multiple individual roles
Individual roles are composed of numerous smaller, coherent activities (in general
transactions)
Functions
Student Lifecycle Management functions are divided into two parts:
Master data access (student master data, academic objects)
Activity execution (e.g. registration, module booking) with and without additional authorization
checks
© SAP 2009
Student Lifecycle Management delivers several roles which combine authorizations and tasks which
are usually needed by a person executing a certain role. Example:
• Role “Instructor” is delivered. For example, the instructor has access to appraisals and
authorization to maintain grades for students in appraisals.
Activities are defined process steps in Student Administration
Master data access:
The execution of functions which are used to create and change master data are protected by a
combination of authorization objects (general authorization) and a structural authorization (object
and evaluation path).
Activity execution:
Student Lifecycle Management has its own authorization object (P_CM_PROC) for activities (e.g.
Registration, Module Booking, etc.). The authorization for activity execution is checked using the
PIQPROCESS authorization fields (activity). The structural authorization only restricts the objects
which the user is allowed to process irrespective of the activity.
© SAP AG
IHE102
15-46
1 5 .7 Aut horiza t ions: T opic Sum m a ry
You should now be able to:
Understand the authorization concept used within
Student Lifecycle Management
Explain the difference between composite roles and
individual roles
© SAP 2009
© SAP AG
IHE102
15-47
1 5 .8 Rule s & Regula t ions: T opic Objec t ive s
After completing this topic, you will be able to:
Understand the concept of rules and regulations
Understand how Rule Containers are attached to
processes and to the academic structure
Describe the structure of a VSR rule
Understand how rules can be overriden
Understand and use status indicators (statuses and
holds)
© SAP 2009
© SAP AG
IHE102
15-48
1 5 .8 Rule s & Regula t ions – Adm inist ra tive a nd
Ac adem ic Rule s
Student Lifecycle Management allows you to set up various rules and to
validate them during various processes.
Process
Administrative Rules
Academic Rules
Admission
Application received in time?
Univ. entrance certificate?
Registration
Fees paid?
Good academic standing?
Module Booking
Module booking period?
Prerequisites fulfilled?
Progression
Progression hold set?
Minimum credits per year
completed?
Rules and Regulations
© SAP 2009
For details on the subject please refer to the Rules Cookbook for Student Lifecycle Management
which is available at: https://www.sdn.sap.com/irj/sdn/bpx-highered -> Student Lifecycle
Management Best Practices, Implementation Guidelines, and Tutorials -> Rules and Regulations in
Student Lifecycle Management.
© SAP AG
IHE102
15-49
1 5 .8 Rule s & Regula t ions – Ca llup Point s
What are callup points?
Defined points within Student Lifecycle Management processes where rules can be
checked.
Delivered for student life cycle processes, e.g.
Registration – register student to program of study
Module booking (single) – save individual booking
Delivered by SAP
Can also be defined by the customer
Used for
Alumni
Recruitment
Rules and regulations
Holds and statuses
Retrieval of calendar data
Calculation of fees
De-registration
Admission
Equivalency
Determination
Graduation
Degree
Auditing
Registration
Other checks
Change of
Program
Course
Registration
Callup point 1
Examination &
Grading
Callup point 2
Progression
Re-registration
Callup point 3
© SAP 2009
Callup points are points in the system at which checks can be performed. These callup points are
predefined by SAP.
Callup points are used for various purposes. In the IMG, you can assign the following to callup
points:
• Rule containers - Rules in the Rule Containers are checked at the predefined points (see VSR)
• Evaluation paths for search of academic calendar objects - evaluation paths enable you to use
different calendars for some predefined activities.
• Hold types and status types - holds and statuses of these types are checked automatically at
predefined points within the processes.
Table T7PIQCHECKTP contains the available callup points. Callup points which can be used for
status indicators have a special flag set – “Relevant for Status Indicator”. Status indicators can be
attached to these designated callup points only.
You can define your own callup points and use these in your own (customer) programs. You can use
function module HRIQ_HS_STATUSIND_CHECK to perform checks at the callup points you
define.
© SAP AG
IHE102
15-50
1 5 .8 Rule s & Regula t ions – Rule Cont a ine rs &
Ca ll up Point s
Callup Points:
Academic callup points
Non-academic callup points
IMG - Customizing
Callup Point
Callup Point 1
Callup Point 2
Non academic
callup points
RC
Rule Container
Academic Objects
O, SC, CG, SM, SE
Callup Point
Academic
callup points
© SAP 2009
A Rule Container is a Student Lifecycle Management object (RC) in which you can collect the rules
to be checked at certain points within a process. The rules in the Rule Container are activated by
attaching it to a Callup Point. Rule Containers are created with transaction PIQRC or from the SAP
Menu Path: Student Lifecycle Management → Academic Structure (Curriculum)→ Rules→ Edit
Rule Container.
You assign one or more Rule Containers to the callup points of different applications. These callup
points are referred to as non-academic callup points because they are checked independent of objects
in the academic structure. The relevant Student Lifecycle Management application processes the
assigned Rule Containers when the callup point occurs. Academic callup points, on the other hand,
directly link Rule Containers with objects of the academic structure (for example, in the program
catalog). Both the academic and non-academic callup points are predefined by SAP.
• Attach Rule Containers to objects of the academic structure by creating relationships, and define
the callup points for Rule Containers as additional relationship data.
- You can use the program catalog to attach the Rule Container to academic objects.
•
Attach Rule Containers directly to callup points.
- You do so in the IMG under Student Lifecycle Management Processes > General Setting
- >Rules > Rule Containers > Assign Rule Containers to Callup Points.
All rules within a Rule Container which are:
• defined for a Callup point
• attached to a process-relevant academic structure object
• are checked when the Callup point occurs.
Example: Student registration for a new Program => check before saving if registration rules
(defined at Program level) are fulfilled.
© SAP AG
IHE102
15-51
15 .8 Rule s & Re gula t ions – Rule Struc t ure w it h V SR
RC
Rule Container
1:
n:
Rule Modules
1:
n:
Composed
of
VSR:
Validations
Substitutions
Rules
Substitution
Rules
Rules
Validation
Rules
Rule
Elements
Rules
© SAP 2009
A Rule Container (object type RC) includes “Rule Modules” (infotype). The Rule Module can refer
to the tool “VSR” and is composed of elements: validations, substitutions and rules (VSR = userdefined substitution and validation of data)
Validation: validates the data entered against user-defined rules
• Data is checked against values and value intervals
• User-defined Boolean statements are used to validate data
Substitution:
• Data is replaced by other values (via value definition or exits)
Rules:
• Modular building blocks that consist of the statements used for rules in validations and
substitutions and contain field values and Boolean statements. Input for the definition of Boolean
logic statements:
- Boolean logic statement, using operators like AND, OR, NOT
- Table fields (PIQRULEMASTERS, etc.)
- Data provided is dependent on callup points.
© SAP AG
IHE102
15-52
1 5 .8 Rule s & Regula t ions – Ex a mple of a
V a lida t ion
=> Check during module booking – list booking
(callup point 0002)
?
?
Message
if check result
= false ??
Prerequisite
Check
Message
Students who registered
for full-time study
Sum of booked
(=attempted) credits for
current session >= 30
Message type I (information):
“Required number of credits not
booked yet”
© SAP 2009
You can create Validations in customizing using the IMG path: Student Lifecycle Management >
Processes in Student Lifecycle Management > General Settings > Rules > Rule Elements > Maintain
Validations:
• Define application area for the VSR and choose between:
- Academic rules
- Calendar rules
- Formal rules
- Progression
• Create a validation step with:
- Prerequisite
- Check
- Message
• Create 1 - 999 steps in one validation.
© SAP AG
IHE102
15-53
1 5 .8 Rule s & Regula t ions – Ex a mple of a
Subst it ut ion
?
Prerequisite
A <--> B
Substitution
Total earned credits >= 12
Set field “progress
classification” to
'’sophomore”
© SAP 2009
You can create Substitutions in customizing using the IMG path: Student Lifecycle Management >
Processes in Student Lifecycle Management > General Settings > Rules > Rule Elements > Maintain
Substitutions:
• Define application area for the VSR and choose between:
- Academic rules
- Calendar rules
- Formal rules
- Progression
• Create a substitution step with:
- Prerequisite
- Values which are to be substituted
• Create 1 - 999 steps in one substitution.
© SAP AG
IHE102
15-54
1 5 .8 Rule s & Regula t ions – M e ssa ge Displa y
After a rule check is performed, messages related to this check are displayed in a
message log.
The message log consists of:
All the rules that were checked by the application
VSR rules, holds, hard-coded checks, status indicators
All positive and negative rule results are displayed as an icon
Green light for positive results
Red light for negative results
Yellow light for pending icon: checks which were postponed because of a conditional
booking check
Message text
Message type (W, E, I, or “–” for suppressed messages)
Callup point at which rules were checked
Override indicator or pending indicator
© SAP 2009
In Student Lifecycle Management processes, rule checks can be performed at one or more Callup
points. If these rule checks are not completed successfully, the system outputs messages and collects
the relevant messages in a message log. The message log is displayed to the User, giving short text
and access to the long text for each message.
The system permits you to override this message log if it contains only warnings (type W),
information messages (type I), and success messages (type S).
To create your own messages, you should create a new message class using transaction SE 91. You
can then add your messages to this message class.
© SAP AG
IHE102
15-55
1 5 .8 Rule s & Regula t ions – Rule Ove rriding
Messages = I/W/E message is output if a rule is not fulfilled
Process is stopped by an E message
Process can be stopped by user if I/W message appears
Rule Overriding
Any rules, which appear as messages, can be overridden by user if
Message is released for overriding
Message is related to a rule module with an extended check flag and a Rule Conatiner with a conditional
booking flag
User is authorized to override the message
Preparation:
1. Define which messages are allowed to be overridden (IMG)
2. Define which user is allowed to override which message (RC)
This information is kept in a Rule Conatiner
3. Override message (message log display)
© SAP 2009
ADVANTAGE: Authorized users can continue a process even though a rule is not fulfilled
Before you can override messages, you have to flag the messages which may be overridden and
define how the system should react in case of an override.
When you have created the required messages, you can maintain the authorizations for rule
overriding in a Rule Container. This action alone activates the override option for a message.
When you have performed steps 1 and 2, the message log display offers an override function to
users who are authorized to override the message.
© SAP AG
IHE102
15-56
1 5 .8 Rule s & Regula t ions – Conce pt of Holds
a nd St a t use s
Status Indicator Category
Status Type
Hold Type
Status Grouping
Hold Grouping
(For Customer Status)
Status Indicator
Hold
Status
© SAP 2009
Status indicator is the generic term for statuses and holds. You have to maintain status types and
hold types in customizing before you can create specific statuses and holds for each type in student
records.
Status indicators of both categories can be assigned to status groupings or hold groupings. These
groupings enable you to sort the status indicators in the hold and status overview of the Student File
and in search helps.
Status types and hold types can both be defined by the customer:
Status types can be customer status types or system status types. You can create customer status
types and determine when they are activated and deactivated. The system status types are delivered
by SAP, and SAP determines when they are activated and deactivated.
• System statuses: admitted applicant, rejected applicant, applicant, alumnus, attending, nonattending, student, de-registered, deceased
SAP does not deliver hold types. You must therefore define the required hold types in customizing.
Note: You cannot switch off a system status, but you can deactivate its display (IMG: Student
Lifecycle Management Master Data > Students > Status Display).
© SAP AG
IHE102
15-57
1 5 .8 Rule s & Regula t ions – Block ing a Proce ss
How does a status indicator (hold or status) block a process?
Status
Indicator
Assign in IMG to
Callup point
Hardcoded check:
Is the status indicator set for ST
or CS of the same type as the one
assigned to the callup point?
Is the status indicator active on the
given key date?
Message is displayed:
Message type I, W, or E
Process is blocked
according to message
type
Yes
No
Nothing
happens
© SAP 2009
Active status indicators can block activities at predefined callup points. The system performs a
check at these callup points. When a status indicator of any type is assigned to a callup point
(reflecting a certain process or step of the process) in the IMG, the system checks if an active hold or
status is set for the student object (object type ST) or the study object (object type CS) on the given
key date. If so, the system displays a message and blocks the process step according to the message
type.
You can define the message you want the system to display when a status indicator blocks a process.
The message type determines the system reaction:
Information message (message type I): The system displays the message but does not interrupt the
process.
Warning message (message type W): The system displays the message and you can decide to carry
on with the process or to cancel the application.
Error message (message type E): The system displays the message in a dialog box and cancels the
process. You cannot carry on with the process.
• The message override concept enables selected users to override an error message and carry on
with the process.
• Messages can also be sent to students in Student Self Service Scenarios created by customers.
Note: Not all callup points can be used for status indicators. The ones that can be used are explicitly
marked as relevant for status indicators in table T7PIQCHECKTP.
© SAP AG
IHE102
15-58
1 5 .8 Rule s & Re gulat ions – Act ivity Ba se d Che c k s
The VSR and the holds frameworks allow checks at callup points to be executed for
chosen activities only.
VSR
Here – wherever possible – the activity ID is provided to the framework, so that it can
optionally be evaluated as prerequisite in a validation step. A validation can thus be relevant
for specific activities only, although the callup point is relevant for other activities as well.
Holds
In this case holds – which still have to be assigned to callup points – can optionally be
assigned to activities as well.
© SAP 2009
Customizable checks can be executed at designated callup points in Student Lifecycle Management.
Student related activities (like program registration) can be blocked at such callup points.
There are two ways to implement such checks:
• Using the VSR framework (Validations, Substitutions and Rules)
• Or using holds
The same callup points are sometimes used in the context of several related activities (e.g. create a
sessional registration, create a leave of absence, change a sessional registration and change a leave
of absence). Up to now it was not possible to assign checks at callup points to certain activities only.
© SAP AG
IHE102
15-59
1 5 .8 Rule s & Regula t ions: T opic Summ a ry
You should now be able to:
Understand the concept of rules and regulations
Understand how Rule Conatiners are attached
to processes and to the academic structure
Describe the structure of a VSR rule
Understand how rules can be overriden
Understand and use status indicators (statuses
and holds)
© SAP 2009
© SAP AG
IHE102
15-60
1 5 .9 St udent Life c yc le M a nage me nt and BW
Extractors of Student Lifecycle Management Business Content
Customers can use these extractors to load data from Student Lifecycle Management to BW
in order to perform analytical reporting, using either queries that were delivered by SAP, or
own queries. Examples:
Master data, such as:
Module
Event
Event Package
Transactional data, such as:
Module Booking
Event Offering
Program Completions
Stage Completions
Program Type Progression
Texts, such as:
Progression Category
Module Booking Status
© SAP 2009
For details on the subject please refer to the Reporing Guideline for Student Lifecycle Management
which is available at: https://www.sdn.sap.com/irj/sdn/bpx-highered -> Reporting in Student
LIfecylce Management with SAP BI.
© SAP AG
IHE102
15-61
1 5 .9 Re port s – St a nda rd De live ry
Change of Specialization
Faculty Workload RFC and Report
Mass Student Group / Fee Category Assignment
Mass Holds Management / Booking Window Assignment
Mass Transfer of Course Registrations upon Cancellation
“I” to “F” Grade Conversion
Report and File Export for Performance Indicies
Activity Documents
Rule Container Generation Report
Enhanced Waitlist Move-Up Report
© SAP 2009
© SAP AG
IHE102
15-62
1 5 . Ge ne ra l Conce pt s a nd T ools: U nit
Sum m a ry
You should now be able to:
Name the available Self Services in Student Lifecycle
Management
Understand the audit trail in Student Lifecycle Management
including activity documents and change documents
Understand the concept of selection methods
Understand correspondence in Student Lifecycle Management
Understand which data can be archived
Understand the authorization concept used in Student Lifecycle
Management
Explain how administrative rules and academic regulations can be
set up with the system
Be aware of the BW reporting options
© SAP 2009
© SAP AG
IHE102
15-63
© SAP AG
IHE102
15-64