student lifecycle management data transfer guide

Student Lifecycle Management Data Transfer Guide

Applies to: This document applies to Student Lifecycle Management EHP 3. For more information, visit the Higher Education & Research homepage.

Summary This document provides a guideline for Student Lifecycle Management customers who need to transfer data and prepare a Migration Concept for Student Lifecycle Management.

Author: Jeroen Boeracker

Company: SAP

Created on: 01 January 2008

Author Bio Jeroen Boeracker is a developer in the Student Lifecycle Management development team.

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

https://www.sdn.sap.com/irj/sdn/bpx-highered



Table of Contents 1. Introduction .....................................................................................................................................................4

1.1 Scope of the Document ............................................................................................................................4 1.2 Target Group.............................................................................................................................................4

2. Technical Overview ........................................................................................................................................5 2.1 Glossary ....................................................................................................................................................5

2.1.1 Batch Input..........................................................................................................................................................5 2.1.2 BDT Framework..................................................................................................................................................5 2.1.3 Direct Input..........................................................................................................................................................5 2.1.4 Data Transfer Workbench ...................................................................................................................................5 2.1.5 External Data Transfer ........................................................................................................................................5 2.1.6 HR Framework....................................................................................................................................................5 2.1.7 Legacy System Migration Workbench (LSMW)...................................................................................................5 2.1.8 Transaction Recorder..........................................................................................................................................5

2.2 Frameworks used in Student Lifecycle Management ...............................................................................6 2.2.1 Data Migration for Student Data..........................................................................................................................6 2.2.2 Data Migration for HCM Objects .........................................................................................................................7 2.2.3 Data Migration for BDT Objects ..........................................................................................................................8 2.2.4 Data Migration for further Student Lifecycle Management Objects .....................................................................8

2.3 Recurring Questions .................................................................................................................................9 2.3.1 Data Consistency................................................................................................................................................9 2.3.2 Internal and External Number Assignment..........................................................................................................9 2.3.3 Data Types..........................................................................................................................................................9

3. Data Transfer for SLCM................................................................................................................................10 3.1 Principles.................................................................................................................................................10

3.1.1 Technical Consistency and Business Consistency ...........................................................................................10 3.1.2 Activity Documents............................................................................................................................................10

3.2 SLCM Setup and Data Transfer..............................................................................................................10 3.3. Data Groups...........................................................................................................................................11

3.3.1 Data not relevant for Data Transfer...................................................................................................................13 3.3.2 Data not considered by now..............................................................................................................................13

3.4 Order for SLCM Data Transfer................................................................................................................14 4. Data Transfer for Data Groups .....................................................................................................................15

4.1 ORG1 Organizational Structure ..............................................................................................................15 4.2 ACSTRUC1, ACSTRUC2 and ACSTRUC3: Academic Structure incl. Internal Qualifications...............15 4.3 EVENT1: Event Management: Short-Term Objects ...............................................................................15 4.4 EXTACSTRUC1: External Academic Structure......................................................................................15 4.5 SP1: Sponsor Data .................................................................................................................................16 4.6 SP2: Grants.............................................................................................................................................16 4.7 PA1: Personnel Administration 1 ............................................................................................................16 4.8 STMD1: Student Objects and Personal Data .........................................................................................16 4.9 STACC1: Student Contract Account and Objects ..................................................................................16 4.10 STMD2: Student Address and Bank Details.........................................................................................17 4.11 STMD3: Student Sponsor Data ............................................................................................................17



4.12 STMD4: Further Student Data ..............................................................................................................17 4.13 STMD5: Student Status Indicators........................................................................................................17 4.14 RP1: Related Persons ..........................................................................................................................17 4.15 STMD6: Relationship from Student to Related Persons.......................................................................17 4.16 STMD7: Student Notes .........................................................................................................................17 4.17 STAPPR1: Sub Appraisals ...................................................................................................................18 4.18 STEH1: External Achievements............................................................................................................18 4.19 STCI: Individual Work ...........................................................................................................................18 4.20 STAH1: Student Admission and Registration Data ..............................................................................18 4.21 STAH2: Student Specialization Data ....................................................................................................18 4.22 STAH3: Academic Work .......................................................................................................................18 4.23 STEV1: Students Event Bookings and Bookings to Academic Units W/O Dates ................................18 4.24 STAH4: Student Qualifications .............................................................................................................18 4.25 STAH5: Program Type Progression Data.............................................................................................19 4.26 STAH6: Program Progression Data......................................................................................................19 4.27 FICA1: FI-CA Data................................................................................................................................19

5. Building a Prototype for SLCM Data Transfer ..............................................................................................20 6. Appendix.......................................................................................................................................................21

6.1 Additional Sources of Information ...........................................................................................................21 6.2 Main Identifiers for SLCM Master Data...................................................................................................21 6.3 Info about HCM Objects..........................................................................................................................23 6.4 Deletion Report for Students...................................................................................................................23 6.5 List of Interfaces......................................................................................................................................23 6.6 Detailed description of interfaces............................................................................................................24

6.6.1 HRIQ_STUDENT_STUDIES_DT_RFC.............................................................................................................24 6.6.2 HRIQ_AW_ACWORK_DT_RFC .......................................................................................................................31 6.6.3 HRIQ_PROG_GR_DT_RFC .............................................................................................................................35 6.6.4 HRIQ_CONFERQRFC_CREATEFROMDATA .................................................................................................36 6.6.5 HRIQ_TRANSCRIPT_CREATE........................................................................................................................38 6.6.6 HRIQ_TESTRESULTS_CREATE.....................................................................................................................38 6.6.7 HRIQ_RFC_STNOTE_CREATE.......................................................................................................................38 6.6.8 HRIQ_RFC_AGM_CREATE.............................................................................................................................40

Copyright...........................................................................................................................................................44



1. Introduction

1.1 Scope of the Document

The intention of this document is to gather information relevant for Student Lifecycle Management customers for data transfer.

This document is neither a general introduction to data transfer to the SAP ERP System nor can it serve as an introduction to the SAP Student Lifecycle Management product. It contains additional information that is considered useful for setting up a Migration Concept for Student Lifecycle Management. In-depth knowledge of the Student Lifecycle Management applications and the setup involved are a prerequisite for this document.

1.2 Target Group

The document contains information relevant to

• Student Lifecycle Management Consultants

• Members of the SLCM Implementation Team

• Developers designing and implementing Data transfer Programs



2. Technical Overview The SAP System provides several tools and techniques to transfer data from legacy systems.

Which tool might be useful for your project depends on your chosen data transfer concept, whether specific data transfer programs are available, on performance needs and also on the know-how and experience available in your project team.

2.1 Glossary

2.1.1 Batch Input

Interface that allows to transfer large amounts of data to an SAP system. During Batch-Input the ERP dialogue screens are processed.

2.1.2 BDT Framework

Business Data Toolset. Programming Environment used for the development of the application objects Business Partner, Contract Account and Contract Object.

2.1.3 Direct Input

Alternative to batch input.

With direct input consistency checks are performed by SAP function modules whereas batch input uses screens to do this. Direct input brings considerable performance advantages and is used as the standard data transfer technique for BDT objects.

2.1.4 Data Transfer Workbench

Transaction SXDA. Workbench to support data transfer for Business objects. Can be used with Business object type PDOTYPES and report RHALTD00 to import objects of the HCM Framework.

2.1.5 External Data Transfer

Term used for data transfer using Direct Input. (Standard Method for Business Partners, Contract Accounts and Contract Objects)

2.1.6 HR Framework

Term used for the Toolset to develop so-called PD object types and infotypes. This framework is used for Organizational Management, Training and Event Management and also for parts of the Student Lifecycle Management Product.

2.1.7 Legacy System Migration Workbench (LSMW)

The LSMW Workbench is an SAP ERP based tool specifically built to support data migration. The LSMW is available free of charge as an add-On to the SAP System from the SAP Service Marketplace.

2.1.8 Transaction Recorder

Transaction SHDB. Tool to record a series of transactions and their screens. You can use the recording to create data transfer programs that use batch input or CALL TRANSACTION, Batch input sessions, Test data or Function Modules.



2.2 Frameworks used in Student Lifecycle Management

Student Lifecycle Management builds up on two powerful SAP Frameworks, the HCM Framework and the BDT Framework, but not all objects are developed using one of those frameworks.

• Many objects of the Internal academic Structure, the External academic Structure and also parts of the Student Record are implemented defining object types and infotypes of the HCM Framework.

• The SAP Business Partner (which is an integral part of the Student Record), Contract Accounts and Contract Objects are implemented as BDT objects.

• There are also objects that do not fit into one of those frameworks, e.g. the SLCM appraisal.

2.2.1 Data Migration for Student Data

Student data should be migrated using the BAPIs or RFC-enabled function modules provided by Student Lifecycle Management.

• Check the data transfer guideline in the SAP Service Marketplace

• As the student business partner record uses a combination of the BDT Framework and the HCM framework, student records must be created using BAPI_STUDENT_CREATEFROMDATA3

• For student admission and registration data the function module HRIQ_STUDENT_STUDIES_DT_RFC should be used

Hints for programmers of data transfer programs:

• Avoid nested loops over internal tables in your data transfer programs

• Use packages for the database update if possible

• Do a performance trace for your data transfer programs.

• Check that the run time increases at the worst linear with increasing package sizes

Technical checks and business checks during data transfer

• Technical checks: Verify data consistency from a technical point of view. Ensure data consistency.

o Example: Value for booking reason transferred from legacy system must be setup as a valid booking reason in SLCM customizing

• Business checks: Verify data consistency from a business point of view. Ensure business process compliance.

o Example: Student that books a module must fulfill all prerequisites setup for this module.

Student Lifecycle Management often provides separate data transfer function modules that only process the technical checks but do not process the business checks.

Example:

• Function module HRIQ_STUDENT_BOOKING: For student module booking self-service

o Processes technical and business checks.

• Function module HRIQ_AW_ACWORK_DT_RFC: For data transfer of academic work data

o Processes only technical checks.



2.2.2 Data Migration for HCM Objects

To support data transfer of HCM objects and infotypes tHCMee reports are provided within the HCM Framework:

• RHALTD00: This report supports legacy data transfer for Personnel Planning data. It presupposes a sequential file with infotype records and generates a Batch-Input File for transaction PP02. Report RHALTD00 is also registered for the data transfer Workbench for the generic Business object type PDOTYPES that can be used for data transfer of HCM objects.

• RHMOVE00: On the basis of the selection criteria, this report creates a sequential file using records from the HCM database.

• RHMOVE40: With this report, you can display and change sequential datasets of HCM data that were created using report RHMOVE00.

In order to get familiar with those reports you can create an HCM object in dialogue e.g. a Program of Study with infotypes, export the data with report RHMOVE00 into a sequential file, edit the sequential file with report RHMOVE40 (only character fields) and load the data into the system using report RHALTD00.

Report RHALTD00 is the standard tool for data transfer for Organizational Units, Jobs, Positions, Event Types etc. Therefore HCM consultants with experience in data transfer for Organizational Management and Training and Event Management will be able to advise on this tool.

Remarks

As report RHALTD00 creates a Batch-Input File for Transaction PP02 the infotype screens are processed. This has the advantage that the business logic from the screen is processed. The disadvantage of the Batch-Input Technique is the higher system load due to the screen processing.

Transaction PP02 also allows maintenance for infotypes that are excluded from direct maintenance with Transaction PP01 because database consistency can only be reached using purpose built maintenance dialogues. This often applies for infotypes created within activities like Registration and Module Booking. (Example: infotype 1771 for Sessional Registrations, infotype 1770 for Study Data and infotype 1769 for Study Segments should not be loaded with RHALTD00. For data transfer of Study Segments and Sessional Registrations a specific Function Module is provided.).

It is strongly discouraged to use report RHALTD00 to load infotypes that cannot be maintained with Transaction PP01 because this probably results in an inconsistent database.

Restriction

For technical reasons report RHALTD00 can currently not be used to create Student Lifecycle Management relationships with additional Data. (Example: For the relationship 500 - Program of Study (SC) consists of Module (SM) – the attributes mandatory item, core item, first stage and last stage are stored as additional data. This relationship can not be created using RHALTD00). For those relationships a specific data transfer Program could be generated using the Transaction Recorder for Transaction PP02.



2.2.3 Data Migration for BDT Objects

External data transfer is the standard technique for data transfer for BDT objects using the Direct Input Interface.

For the BDT objects Business Partner, Contract Account and Contract Object specific data transfer Programs and their documentation are available in the IMG:

• Business Partner: e.g. Student Lifecycle Management -> Master Data -> Students -> Students as Business Partners -> …-> SAP Business Partner -> External data transfer

• Contract Account: Financial Accounting -> Contract Accounting -> Basic Functions -> Contract Accounts -> Data Transfer

• Contract Object: Financial Accounting -> Contract Accounting -> Data Transfer

The objects use the Direct Input Structures BUS_DI (Business Partner), FKKVK_DI (Contract Account) and PSOB_DI (Contract Object) that contain only fields of type Character.

FI-CA consultants with experience in data transfer for Business Partners and Contract Accounts will be able to advise on those tools.

Restriction

Student Business Partners must not be created using the BDT Direct Input Technique for general business partners. Instead Function Module BAPI_STUDENT_CREATEFROMDATA3 must be used as this is the only way to create a consistent student record with all parts, the HCM object, the BDT object and the link. Once the Student Record was created in this way, address Data can be created using the BDT Direct Input Technique.

2.2.4 Data Migration for further Student Lifecycle Management Objects

For SLCM objects that are neither an HCM object nor a BDT object, specific data transfer programs are not available yet.

For those objects either a Function Module for data import is provided (e.g. BAPI_STUDENT_CREATEFROMDATA3) or an existing dialogue with Batch-Input can be used. Details of the function modules available can be found in chapter 0.

Based on the (Receiver) Structures of the Function Module Interfaces (or the Fields available on the dialogue screens for Batch-Input) a corresponding (Sender) Structure in Character Format should be defined. With a program a sequential file is read into the sender structure, converted to the receiving structure and the Function Module (or Batch-Input) is called.

Remark

In Student Lifecycle Management many Function Modules are developed according to the programming model for BAPIs and also named as BAPI_* in order to officially release them as BAPIs in a later Release. Although in many circumstance those Function Modules can be used in the same way as released BAPIs (e.g. using an RFC connection), it must be emphasized that none of those Function Modules are officially released in SLCM 4.64 and thus those BAPIs are not assigned to a BOR object type. Specific data transfer Programs and message types (IDOCs) are not available for SLCM-specific BAPIs or RFCs.



2.3 Recurring Questions

2.3.1 Data Consistency

Only consistent Data Records should be imported into the ERP system.

If data is written directly into the ERP database tables by customer-specific programs with direct database updates consistency checks are not performed and it is very likely that the data is inconsistent.

In order to ensure data consistency an interface that performs the necessary consistency checks should be used.

There is no general recommendation if Batch-Input, Direct Input or Function Modules should be used. The decision for a method must be taken for every business object considering and performance needs and if consistency checks are performed.

2.3.2 Internal and External Number Assignment

Every object needs a technical identifier like the HCM object ID, the Contract Account Number etc.

After the Go-Live-Date object identifiers for new objects are often created automatically from an internal number range. During data transfer an object identifier is often needed in several steps during the conversion process. If internal number assignment is also used during data transfer, then the identifier needs to be known in the legacy system or an intermediate step of the conversion process.

For this reason it’s usually easier to use external number assignment for data transfer if possible. The external number could be the same identifier as used in the legacy system or an identifier which is easily derived from the legacy system.

2.3.3 Data Types

When using Function Modules, Batch-Input or Direct Input for Data Import the receiver structures must be analyzed. Non-character fields are often the cause for data conversion errors e.g. fields with the ERP Data type DEC like the relationship Percentage.

Often only fields with character format are used for the sequential file that is created from the legacy system. In this case for every non-character field of the receiving structure a corresponding field with character format will be used in the sending structure and after the import into the ERP system the data will be converted from the sender structure to the receiving structure.



3. Data Transfer for SLCM

3.1 Principles

3.1.1 Technical Consistency and Business Consistency

Student Lifecycle Management aims to provide Interfaces for data transfer that ensure data consistency for the migrated data, but not all business checks will be carried out during the data transfer.

Example:

Migration of admission Data (Student 012345 is admitted for Program of Study A123 for Academic Year 1999)

• Technical Consistency is checked:

o The Student and Program of Study exist.

o The Academic Year is maintained in the Customizing Table.

• Business Consistency is not checked:

o The time limit for admissions for the Academic Year 1999 ends at the 10.05.1999. This time limit is not checked.

This implies that VSR-Checks are usually not called when using the data transfer Interfaces.

3.1.2 Activity Documents

Within Interfaces that are provided specifically for SLCM data transfer, no activity Documents will be written.

3.2 SLCM Setup and Data Transfer

Every Student Lifecycle Management implementation is different. Depending on the main business processes of the University, the academic Structure and Customizing might be setup in a very different manner.

Especially the scope of the SLCM implementation and the chosen time point of changing over from the legacy system to the SLCM system (Big Bang-Approach or Step-by-Step-Approach) have a huge impact on the data transfer Concept.

Those choices result in a multitude of different possible situations. Therefore a data transfer Strategy that might be good in general might not be possible or even wrong for a particular project implementation.



3.3. Data Groups

Considering the technical and semantic nature of Student Lifecycle Management Data the objects and database tables are grouped in order to illustrate the dependency between the data groups and to discuss possible conversion approaches. The list is non-exhaustive.

Group Identifier Group Description Objects Database Tables / infotypes (non-exhaustive)

Organizational Data

ORG1 Organizational Structure

Org. Unit (O);

Location (F)

Infotype 1000, relationships, infotypes for attributes

ACSTRUC1 Internal academic Structure, Module and above

Program of Study(SC), Module Group(CG), Module (SM), Credited Work(CW)


ACSTRUC2 Internal academic Structure below the Module

Event Type (D), Eventless Event (EL) with Object attributes


ACSTRUC3 Internal Qualifications Internal Qualifications (CQ)

Infotype 1000, infotypes for attributes

EVENT1 Event Management: Short-Term objects

Short-Term Event Packages (SE),

Events (E) with object attributes


EXTACSTRUC1 External academic Structure

External Organization (EO), External Subjects (SU), External Qualifications (EQ)


SP1 Sponsor Data Business Partners

Sponsors Contract Account and Objects

BUT000, etc.

FKKVK,

FKKVKP etc.

SP2 Grants Grant Master Record SLCMACGRANT, etc.

PA1 Personnel Administration 1

Employees (P) PA-Infotype 0001 etc.

Student-Related Data

STMD1 Student objects and Personal Data

Student (ST), Business Partner(BUPA),

Infotype 1000 (ST), BUT000 (BP), SLCMACBPST, infotypes 1702, 1701, 1703, 1704, 1705, 1706, 1711, relationship 502



STMD2 Student address and Bank Details

Business Partner Bank Details

Address and address Usage

Payment Cards

BUT0BK

BUT020, BUT021, ADR*

BUT0CC

STMD3 Student Sponsor Data Sponsor Data SLCMACGRANT, SLCMACGRANTT

STMD4 Further Student Data Visa Data

Further activities

Students Advisor

Alumnus-Relationship

Infotype 1712

Infotype 1718

Relationship 515

Relationship 541

STMD5 Student Status Indicators

Customer Status and Holds

Infotype 1728

RP1

Related Persons Business Partners in Role ‘Citizen’ with additional Data

BUT000 etc., DPSCITIZEN

STMD6 Relationship from Student to Related Persons

Relationship 521

STMD7 Student Notes Free Format Notes

Coded Notes

Infotype 1707

SapScript-Text object

STAPPR1 Sub Appraisals Sub Appraisals for an existing Top Appraisal

PIQDBAGR*

STEH1 Students External achievements

Transcripts

Test Scores

Infotype 1719

Infotype 1721

STACC1 Student Contract Account

Contract Account

Contract Object

FKKVK

FKKVKP

SLCMACCADD

DPSOB

SLCMACCODD etc.

STCI Individual Work Individual Work object (CI) incl. CI-Booking

Infotype 1000, relationships (Booking-Relationship 547), infotype 1774, 1775

STAH1 Student Admission and Program Registration Data

Study object, admission Records, Study Segments, Sessional Registration Records

Relationships ST-517-CS ST-530-CS, 513, 514,

Infotypes 1769, 1770, 1771

STAH2 Student Specialization Data

Specialization Record Relationship 516



STAH3 Students academic Work

Resident and transfer academic Work, Module Usage

Relationship 506, Appraisal Tables PIQDBAGR*, infotype 1724

STAH4 Students Qualifications

Resident and transfer Qualifications

Relationship 532 and Appraisal

STAH5 Students Program Type Progression Data

Infotype 1737

STAH6 Students Program Progression Data

Infotype 1772

STEV1 Students Event Bookings

Event Management relationships

Bookings to Academic Units W/O Dates

Relationships 025, 040 and 547 (ST-547-EL)

FICA1 FI-CA Data Documents .

3.3.1 Data not relevant for Data Transfer

The following data are not considered in this document as they are currently seen as not relevant for data transfer from a business point of view:

• Offering Patterns for Events

• Transfer Agreements

• Activity Documents for any SLCM activity

• Rule Containers (RC), Rule Modules, Rule Elements

• ISR applications

3.3.2 Data not considered by now

User Data

• Is there any need to transfer User Data (e.g. a Password) from a Legacy System to SLCM? An alternative would be to create a new user with a new initial password.



3.4 Order for SLCM Data Transfer

Preconditions

It is a precondition for the data transfer that all necessary customizing settings have been done.

The diagram shows the dependency of the data groups thus suggesting a data transfer plan by reading the diagram from top to bottom.

ORG1Org. Structure

Customizing

Order for CM Data Transfer

ACSTRUC1Int. Acad.

Structure, SMand above

ACSTRUC2Int. Acad.Structurebelow SM RP1

RelatedPersons

ACSTRUC3Internal

Qualifications

EXTACSTRUC1External Ac.

StructureSP1

Sponsors

SP2Grants

STMD1Student Objects

STMD2Address,

Bank

STMD3Student

Sponsor Data

STMD4Further

Student Data

STMD5Status

Indicators

STMD6Relationship

ST-RP

STMD7Notes

STAPPR1Supappraisal

s

STEH1External

Achievements

STACC1ContractAccount

STCIIndividual

Work

STAH1Admission

andRegistration

STAH2Specialization

STAH3Academic

Work

STAH6Program

Progression

STAH5Program

TypeProgression

STEV1Event

Bookings

PA1Employees

FICA1FICA Data

STAH4Students

Qualifications

EVENT1Events



4. Data Transfer for Data Groups

4.1 ORG1 Organizational Structure

In most projects, the organizational structure is created within the HCM implementation project. During the implementation of Student Lifecycle Management the Organizational Structure might be extended.

Mostly the Organizational Structure will be maintained manually in the SAP System.

If Organizational Units and their relationships shall be created using data transfer, the standard method for HCM objects can be used. (Chapter 0)

Remark

Sometimes the begin date of the Organizational Units in your Organizational Structure was set to the Go-Live-Date of the HCM Project. If you need to create relationships to Organizational Units for earlier time intervals, then report RHBEGDA0 can be used to change the begin date for objects of the HCM Framework.

4.2 ACSTRUC1, ACSTRUC2 and ACSTRUC3: Academic Structure incl. Internal Qualifications

Data Transfer

In most projects, the academic structure is created manually in the SLCM system. If objects of the Academic Structure and their relationships and infotypes shall be created using data transfer, the Standard Method for HCM objects can be used. (Chapter 0)

Validity of the Objects of the Academic Structure

In order to import the Students academic History (Registration Records, academic Work and Qualifications) at a later stage it is necessary to create the objects of the Academic Structure with a begin date that is far enough in the past because the SLCM System requires for all Registration and academic Work Records a valid object of the Academic Structure.

Example: In order to create a Registration Record for the Academic Year 2007, a Program of Study with a validity spanning the Academic Year 2007 must exist in the SLCM System.

The level of detail that needs to be maintained for the past academic structure depends on the level of detail that needs to be maintained for the academic history. Therefore you should check which level of detail you require for future follow-up processes.

4.3 EVENT1: Event Management: Short-Term Objects

There are two possibilities to create Events and Event Packages:

The Standard Technique for HCM infotypes could be used. As there are many relationships involved in setting up an event the creation of the sequential file becomes very complex.

For this reason it might be easier to use the following Function Modules to create the objects:

• HCMIQ_EVENT_CREATE

• HCMIQ_CREATE_EVENTPACKAGE

• HCMIQ_CREATE_EVENTLESS_EVENT

4.4 EXTACSTRUC1: External Academic Structure

Depending on the number of objects required the external academic structure can either be created manually in the SAP system or using function modules to create the objects External Organization, Subject and External Qualification.




4.5 SP1: Sponsor Data

t,

system using the Direct Input technique for the BDT framework.

ords are either manually created in the SLCM

Personnel Administration 1

ion master records is part of the HCM implementation

:

ust be used to create Student Master istent Student Master Records. It must be

ed that the infotypes Personal Data (1702) and Status attributes (1701) should also only be d using this Function Module or BAPI_STUDENT_CHANGE3. The other infotypes could be

instance and change the instance within one LUW. types within one LUW. Example:

e combined I_STUDENT*

nt and the mandatory contract objects are created.

b) The automatic creation of contract account and objects is switched off during data transfer of the Student Master Records (IMG: SLCM -> Master Data -> Students -> Students as Business Partners -> Deactivate Automatic Student Account Creation.) Then Contract Accounts and Objects are created using Direct Input. After the successful conversion the automatic creation of contract accounts is switched on again.

Depending on the number of Sponsors the Master Records (involving Business Partner, Contract AccounContract Objects) are either manually created in the SLCM system or can be transferred from the legacy

4.6 SP2: Grants

Depending on the number of Grants the Grant Master Recsystem or with the Transaction Recorder a Batch-Input Program can be generated for Transaction PIQGM.

4.7 PA1:

This data group is only mentioned for completeness because employees (object P) can be assigned as advisor for a student directly or via a position (object S).

In most projects, data transfer for employee and positproject.

Data transfer for employee master records is supported in a similar way as for HCM-PD objects. (IMGPersonnel Administration -> Tools -> Data Transfer Workbench).

4.8 STMD1: Student Objects and Personal Data

The function module BAPI_STUDENT_CREATEFROMDATA3 mRecords because it is currently the only way to create consemphasizmaintainetransferred using the standard technique for HCM objects as the PP01-Screens provide exactly the same consistency checks as the Function Modules BAPI_STUDENT*.

See also the next chapter for Student Contract Accounts.

Remark

When using Student-BAPIS it is not possible to create an But it is possible to create an instance and add further infoBAPI_STUDENT_CREATEFROMDATA3 and BAPI_STUDENT_CHANGE3 cannot be combined in one LUW, but BAPI_STUDENT_CREATEFROMDATA and BAPI_STUDENT_IDENTIFIC_ADD can bwithin one LUW. For details refer to the documentation of the function modules BAP

4.9 STACC1: Student Contract Account and Objects

The standard method for data transfer of contract account and contract object data is certainly Direct Input, but consideration must be given to the SLCM functionality that with every student master record automatically a contract accou

There are two options for the data transfer of Contract Accounts and Objects

a) The Contract Account and all mandatory Contract Objects are automatically created with the Student Master Record. In a second step the attributes of the contract account and objects are changed using Direct Input.


4.10 STMD2: Student Address and Bank Details

It is suggested to use Direct Input for data transfer for addresses, Bank Details and Payment Cards of Student Business Partners.

Alternatively the Function Modules BAPI_STUDENT_ADDRESS* , BAPI_STUDENT_BANK* and BAPI_STUDENT_PCARD* could be used.

4.11 STMD3: Student Sponsor Data

Student Sponsor data should be transferred using the Direct Input Technique for BDT Objects. The fields for Sponsor data are located in the include structures ISPS_BPSTCA_DI and ISPS_BPSTCA2_DI in structure BUS_DI.

4.12 STMD4: Further Student Data

Further student infotypes can be loaded using the Standard HCM report RHALTD00.

Visa/Registration data can also be loaded using the Function Modules BAPI_STUDENT_IDENTIFIC* e.g. BAPI_STUDENT_IDENTIFICATION_ADD.

4.13 STMD5: Student Status Indicators

For student status indicators (Holds and Customer Status) the Function Modules HCMIQ_HS_HOLD_WRITE and HCMIQ_HS_STATUS_CUS_WRITE should be used.

Holds and customer status can be assigned to the object types Student (ST) and Studies (CS).

4.14 RP1: Related Persons

Related Persons are created as Business Partners with Role ‘Citizen’. To create those records either the Direct Input Method for Business Partner can be used (SLCM-specific data is contained in include ISPS_DPSCITIZEN_DI of structure BUS_DI) or the following Function Modules could be used:

• General Business Partner BAPIs in Function Group BUBA_3: BAPI_BUPA_*

• PSCI_CITIZEN_CREATE_FROM_DATA: Creates a Business Partner with Role Citizen and role-specific data.

• PSCI_CITIZEN_CHANGE: Change role-specific data for related persons.

4.15 STMD6: Relationship from Student to Related Persons

The following Function Modules can be used to maintain the relationship from a Student to a Related Person:

HCMIQ_STRELPERSON_CHANGE

HCMIQ_STRELPERSON_CREATE

HCMIQ_STRELPERSON_DELETE

HCMIQ_STRELPERSON_DELIMIT

HCMIQ_STRELPERSON_GETLISTFROMRP

HCMIQ_STRELPERSON_GETLISTOFRP

4.16 STMD7: Student Notes

See Function Module HCMIQ_RFC_STNOTE_CREATE.



4.17 STAPPR1: Sub Appraisals

Sub appraisals for an existing appraisal can be created using the Function Module HCMIQ_AGR_RFC_APPR_CREATE. The field UPAGRID of the import parameter I_APPRAISAL must be filled with the appraisal ID of the corresponding top appraisal.

4.18 STEH1: External Achievements

The following function modules are provided for creating external achievements:

HCMIQ_TRANSCRIPT_CREATE

HCMIQ_TESTRESULTS_CREATE

4.19 STCI: Individual Work

Individual work objects could be created using the standard method for the HCM framework, report RHALTD00. In order to transfer the booking relationship 547 it might be necessary to develop a specific program because of the additional data containing the ID of the corresponding module booking record.

Remarks

• During the creation of the booking relationship it is checked that the CI object (Infotype 1000) is valid for the complete validity interval of the relationship.

• Creation of the module work records ( 0) is a prerequisite for the creation of the booking relationship for the CI object.

4.20 STAH1: Student Admission and Registration Data

See function module HCMIQ_STUDENT_STUDIES_DT_RFC.

4.21 STAH2: Student Specialization Data

See function module HCMIQ_STUDENT_STUDIES_DT_RFC.

Comment: With the function module HCMIQ_STUDENT_STUDIES_DT_RFC it is possible to transfer admission, registration and specialization data for a student within one call.

4.22 STAH3: Academic Work

See Function Module HCMIQ_AW_ACWORK_DT_RFC) for data transfer of academic work records.

This Function Module will allow the transfer of all academic work with the Top Appraisal data:

• Completed module work (= ‘module booking records’)

• transferred module work

• credited work

4.23 STEV1: Students Event Bookings and Bookings to Academic Units W/O Dates

Event Bookings for Students could be imported using the standard method for the HCM Framework.

Alternatively the Function Modules from Function Group RHVI could be used e.g. BAPI_BOOK_ATTENDANCE.

For students bookings to academic units w/o dates the function module HCMIQ_EL_STUDENT_REGISTRATION could be used.

Bookings to Academic Units W/O Dates could also be imported using the standard method for the HCM Framework.

4.24 STAH4: Student Qualifications

Function Module HCMIQ_CONFERQRFC_CREATEFROMDATA can be used for data transfer.



4.25 STAH5: Program Type Progression Data

See Function Module for data transfer HCMIQ_PROG_GR_DT_RFC.

4.26 STAH6: Program Progression Data

Only four fields in infotype 1772 are relevant: Academic Year, Session, Stage and Progression Status. Records for infotype 1772 should be created using the Standard data transfer Method for HCM infotypes.

Remark:

Infotype 1772 is stored with the CS Object.

4.27 FICA1: FI-CA Data

IS-PS-CA offers a flat file interface for mass updates. Reports RFKKBIB0/RFKKBIB1 (development class FKKB) use structures BFKKGR00, BFKKKO, BFKKOP and BFKKOPK in order to generate direct input of documents.

Moreover, several BAPIs are released for the customer. They can be found in function group FKK_BOR_DOC of development class FKKB. The methods post document, change document, check existence of document, read document details, get list of documents, cancel document, and reset document clearing are available.

The BOR object type for these BAPIs is CA_DOC. Some important BAPIs are:

CtrAcDocument.Create BAPI_CTRACDOCUMENT_CREATE CtrAcDocument.Change BAPI_CTRACDOCUMENT_CHANGE CtrAcDocument.GetDetail BAPI_CTRACDOCUMENT_GETDETAIL CtrAcDocument.Reverse BAPI_CTRACDOCUMENT_REVERSE CtrAcDocument.ReverseClearing BAPI_CTRACDOCUMENT_REVERSECLR



5. Building a Prototype for SLCM Data Transfer A prototype implementation for the following scenario could be attempted in order to get familiar with the different techniques and typical data transfer Questions:

Prototype: Conversion of Student Master Records with

o Personal data (using BAPI_STUDENT_CREATEFROMDATA3)

o Challenge data (using BAPI_STUDENT_CREATEFROMDATA3)

o Address data (using BDT Direct Input)

o VISA/Registration data (using report RHALTD00 for infotype 1712)

This Prototype is suggested for the following reasons:

• All 3 different techniques (data transfer for the HCM Framework, data transfer for the BDT Framework, data transfer using SLCM Function Modules) involved in a data transfer Project are covered.

• A concept for object identifiers needs to be defined.

• Decimal Fields and Dates are used (Challenge Percentage, Birth Date)

Remark: There are Function Modules available for VISA/Registration data. The motivation to choose Report RHALTD00 as a possible data transfer technique in this example was to incorporate all HCM techniques within one simple example.



6. Appendix

6.1 Additional Sources of Information

SAP Library -> BC Basis Programming Interfaces -> Data Transfer (describes Transaction Recorder)

SAP Library -> Cross Application Components -> CA Data Transfer (describes Data Transfer Workbench, External Data Transfer)

The LSMW (Legacy System Migration Workbench) can be downloaded free of charge from the SAP Service Marketplace. For further information see http://www.service.sap.com/LSMW (Data Migration from Non-SAP Systems to SAP Systems – Quick Introduction to working with the Legacy System Workbench).

OSS Notes

311440 Batch-Input and Controls

101014 Legacy System Migration Workbench

6.2 Main Identifiers for SLCM Master Data

Field Description Type

Student Object ID Technical Identifier for the HCM Objects Student (ST). Identifier used for most Student BAPIs (BAPI_STUDENT*) and Function Modules.

NUMC 8

Student Number Main Student Identifier in Student Lifecycle Management. The Student Number is not used as a technical key of database Tables and can be changed. Maintenance Transactions in Student Lifecycle Management work with the Student Number

CHAR 12

Business Partner Number Identifier for all Business Partners. Used for Business Partners in the Role Groupings Student, Related Person etc. Identifier used for Business Partner BAPIs (Function Modules BAPI_BUPA* ) and also for Direct Input for BDT Objects Business Partner.

CHAR10

Contract Account Number Key identifying a contract account CHAR12

Contract Object Identifier Key identifying a contract object CHAR20

Study Object ID Technical Identifier for the Study Object. To every Study Object exactly one Student and one Program of Study are assigned All Program-Related data for a Student is stored with the Key of the CS object. Within Function Modules for Program-Related data

NUMC8


http://www.service.sap.com/LSMW



Academic Work ID Unique Identifier for a Module Booking or Credited Work Object Record

CHAR32

Grant ID Identifier for Grant Master Record CHAR20

Object ID (Academic Structure)

Technical Identifier for objects of the Academic Structure.

NUMC8

Database Tables

The following list contains the most important database tables for the technical identifiers. Depending on the chosen data transfer concept strategy it might be useful to directly access those tables for data transfer and conversion programs or to load those tables into the memory or into external tools.

Database Table Fields (Key Fields)

SLCMACBPST Student Object ID, Student Number, Student Business Partner Number

HCMP1000 Object Table of HCM Objects

Object ID, Short Text of Object (Time-dependent!)

HCMP1001 Relationships between HCM Objects:

Object type (OTYPE) and Object ID (OBJID) of first object; Object type (SCLAS) and Object Id (SOBID) of second object (SOBID)

Examples:

ST Object – 517 – CS Object (has / belongs to)

CS Object – 514 - SC Object (is instance of / has instance)

O Object – 501 – SC Object (offers / is offered by)

ST Object – 521 – BP Object for Related Person (is related to / is related to)

BUT000 Business Partner Number

FKKVK Contract Account Number

FKKVKP Contract Account Number, Business Partner Number (for Student Account and Sponsor Accounts)

DPSOB Contract Object Identifier

DPSOB_BP_ACC Contract Object Identifier, Business Partner Number

SLCMACBPSTCA Student Business Partner Number, Grant Identifier

SLCMACGRANT Grant Identifier, Sponsor Contract Account Number


Function Modules

These Function Modules might be useful within data transfer programs to determine technical identifiers.

Function Module Comment

BAPI_STUDENT_NUMBERS_GET Reads Student Object ID, Student Number and Business Partner Number with one of those numbers given.

HCMIQ_STUDIES_ST_SC_READ Reads object Ids of Student and Program of Study for a Study Object(CS)

HCMIQ_STUDENT_STUDY_FOR_SC_GET Reads object id of Study Object for a Student and Program of Study (if existing).

PMIQ_BUPA_READ_CONTRACT_ACCT Reads Contract Account and Contract Object data for the Students Contract Account

6.3 Info about HCM Objects

Report RHIQ_HCMOBJINFO is a basic, but useful tool that provides a quick overview about the relationships and infotypes that are allowed for an HCM object type.

6.4 Deletion Report for Students

Report RHIQ_STUDENT_DELETE supports the deletion of Student Business Partners with all related Contract Accounts, Contract Objects and Related Persons. A Selection Method can be used for the selection of the Students for the deletion report.

6.5 List of Interfaces

Interface Usage

HRIQ_STUDENT_STUDIES_DT_RFC

Create admission, registration and specialization data

HRIQ_AW_ACWORK_DT_RFC Create academic work in Student Lifecycle Management using student object id and academic work object id (SM or CW object)

HRIQ_PROG_GR_DT_RFC Create progression result in Student Lifecycle Management using student object id

HRIQ_CONFERQRFC_CREATEFROMDATA Create qualification data in Student Lifecycle Management using student object id and qualification object id (CQ)

HRIQ_TRANSCRIPTS_CREATE Create transcript record for Student

HRIQ_TESTRESULTS_CREATE Create test score record for student

HRIQ_RFC_STNOTE_CREATE Create student note

HRIQ_RFC_AGM_CREATE Create Transfer Regulation for an external organization

Note: This description does not exclude future minor changes of the interfaces. English terms are not finalized yet in all cases.



6.6 Detailed description of interfaces

6.6.1 HRIQ_STUDENT_STUDIES_DT_RFC This function module can be used to transfer admission, registration and specialization data for one student within one Call Function statement. It is possible to transfer data for several programs of study using only one call. The function module must be called for every student separately. For the data imported in tables ADMISSIONS, STUDY_SEGMENTS, SESSIONAL_REGISTS, SPECIALIZATIONS Infotype records and relationships for the CS object will be created in the SAP system. Interface: Parameter-Name Parameter-Type

Importing-Parameter PLANVERSION PLVAR STUDENTOBJECTID PIQSTUDENT

Table-Parameter ADMISSIONS PIQRFC_ADMISSION STUDY_SEGMENTS PIQRFC_STUDYSEGMENTS SESSIONAL_REGISTS PIQRFC_SESS_REGISTS SPECIALIZATIONS PIQRFC_STUDY_SPECIALIZATIONS RETURN BAPIRET2 STUDY_OBJECTS_OUT PIQRFC_STUDYOBJECTS

This function module uses the same structures for the Table-Parameters as the function module HRIQ_STUDENT_STUDIES_GET_RFC. The structures are available and direct navigation to data elements and check tables in the SAP Dictionary is possible.

6.6.1.1 General Comments for Parameters

Academic years and sessions

For all academic years and sessions time limit 0100 must be maintained in the academic calendar of the program of study or the organizational unit.

For programs with a session variant with the academic year as primary unit only the academic year is mandatory, the session is optional.

Student, study and program object ID

This function module uses the same structures as HRIQ_STUDENT_STUDIES_GET_RFC and it is also intended to use the same structures for function modules returning data for several students. Therefore the student object id is contained in all structures.

There is no need to fill the student object id in the tables. If the field is filled, then it must be the same value as in the import parameter STUDENTOBJECTID.

It is possible to fill either the study object id or the program object id to identify the students program of study. For data transfer usually the program object id will be filled and if necessary the study object for a student and program will be created by this function module.

In parameter STUDY_OBJECTS_OUT the study objects of all programs of study

Combination checks

The following dependencies between the data imported and also data which might be already stored in the SAP database will be checked:

• It is not allowed to hold two admission records for the same program in status planned or admitted with the same academic year and session (defined by ADM_AYEAR and ADM_PERID). For admissions for the whole academic year (to programs with a session variant with the academic year as primary unit) it’s not allowed to have another admission for the same year but with a session.



• It is not allowed to hold two study segment records for the same program with overlapping time interval (defined by BEGDA and ENDDA).

• It is not allowed to hold two sessional registration records for the same program with overlapping time interval (defined by BEGDA and ENDDA).

• For every active (not cancelled) sessional registration record a study segment record must exist for the complete time interval.

6.6.1.2 Parameter ADMISSIONS

For every admission record one line in the table should be filled. Detailed explanation of parameter ADMISSIONS (Table of type PIQRFC_ADMISSION):

Component Datatype Length Description Comment

STUDENT_OBJECTID NUMC 8 Object Id Student Optional. If filled, must be same as Parameter STUDENTOBJECTID

STUDY_OBJECTID NUMC 8 Object ID of Object Study (CS)

Either Study Object ID or Program Object ID must be filled.

PROGRAM_OBJECTID NUMC 8 Program of Study Object ID

See STUDY_OBJECTID

BEGDA DATS 8 Start Date Optional.

If filled, then it will be checked that Date is inside time limit 0100 for Academic Year/Session..

ENDDA DATS 8 End Date See BEGDA

ADMIS_STATUS CHAR 1 Admission Status Mandatory.

Values:

1 – Admitted/Approved

2 - Applied

5 - Rejected

CHOICE_NO NUMC 2 Program Choice Optional

Value table T7PIQCHOICES

ACAD_YEAR NUMC 4 Academic Year Mandatory.

Value Table T7PIQYEAR.

ACAD_SESSION NUMC 3 Academic Session Mandatory/Optional depending on Primary Unit of Program

Value Table T7PIQPERIOD

STAGE NUMC 2 Stage Mandatory/Optional depending if Program uses Program Plan

Value Table T7PIQLEVPERVAR (T7PIQLEVEL)



PROGRESS_CLASS CHAR 4 Progress Classification Optional

Value Table T7PIQPROGCPERVAR (T7PIQPROGCLASS)

PARTTIME CHAR 1 Indicator: Part-time Study Optional

Values: space, X

ADMIS_CATEGORY CHAR 2 Admission Category Optional

Value Table T7PIQADMCATEG

REGIST_TYPE CHAR 2 Registration Type Optional

Value Table T7PIQENRCATEG

ADMISSION_CODE CHAR 12 Admission Code Optional

COMPL_LENGTH_STUDY NUMC 3 Completed Length of Study

Optional

NOTIFICATION_NO CHAR 12 Notification Number Optional.

If filled, it is checked if Notificaton exists

6.6.1.3 Parameter STUDY_SEGMENTS

Study segments contain information when a student started to study a program and ended a program of study that means it spans the time interval when the student was considered as pursuing this program of study. For every active sessional registration a study segment must exist.

If study segment information cannot be extracted from a legacy system then it is suggested to create exactly one study segment for every program of study where sessional registration exists. In this case the study segment could be build up in the following way:

• Fill BEGDA with the begin date of the first sessional registration

• Fill ENDDA with the end date of the last sessional registration if the student does not follow this program of study any more. Otherwise fill should begin with the begin Therefore

• Use RA01 for BEG_PROCESS

• Use RW01 for END_PROCESS and create a reason like ‘Data Transfer’ to fill END_REASON Detailed explanation of parameter STUDY_SEGMENTS (Table of type PIQRFC_STUDYSEGMENTS):

Component Datatype Length Description Comment STUDENT_OBJECTID NUMC 8 Object Id Student See above

STUDY_OBJECTID NUMC 8 Object ID of Object Study (CS) See above

PROGRAM_OBJECTID NUMC 8 Program of Study Object ID See above

BEGDA DATS 8 Start Date of Program Registration Mandatory. Begin of Study Segment

ENDDA DATS 8 End Date of Program Registration Optional.

End of Study Segment

Leave initial or fill with 99991231 for open study segments when student is not deregistered from program yet.



BEG_PROCESS CHAR 4 Activity for Program Registration Mandatory:

Possible Values:

RA01 – Initial Registration

RQ01 – Change of Program

BEG_REASON NUMC 4 Activity Reason Depends on value for BEG_PROCESS:

Not allowed for RA01

Mandatory for RQ01

Value Table T7PIQPROCREASON (T7PIQREASON)

BEG_KEY_DATE DATS 8 Key Date for Begin of Study Segment

Mandatory

Possible Values:

RA01 – Initial Registration


END_PROCESS CHAR 4 Activity for De-registration from Program

Mandatory if ENDDA is not 99991231

Possible Values:


RW01 – Withdrawal from Program

RV01 – Dismissal from Program

END_REASON NUMC 4 De-registration Reason Mandatory if ENDDA is not 99991231

Depends on value for END_PROCESS:


END_KEY_DATE DATS 8 Key Date for End of Study Segment.

Mandatory if ENDDA is not 99991231

LAST_ATTENDANCE DATS 8 Last Day of Attendance Optional

Check LAST_ATTENDANCE < ENDDA

Not allowed if ENDDA is 99991231



6.6.1.4 Parameter SESS_REGISTS

For every sessional registration and every program of study one line in the table should be filled.

Detailed explanation of parameter SESS_REGISTS (Table of type PIQRFC_SESSIONAL_REGISTS):


STUDENT_OBJECTID NUMC 8 Object Id Student See above


See above


See above

BEGDA DATS 8 Start Date Optional.

If filled, then it will be checked that Date is inside time limit 0100 for Academic Year/Session..

ENDDA DATS 8 End Date See ENDDA

STUDY_PRIORITY CHAR 2 Program Priority (In Period)

Values:

‘1 ‘ – Main Program

‘2 ‘ – Additional Program

ACAD_YEAR NUMC 4 Academic Year Mandatory.

Value Table T7PIQYEAR.

ACAD_SESSION NUMC 3 Academic Session Mandatory/Optional depending on Primary Unit of Program

Value Table T7PIQPERIOD

STAGE NUMC 2 Stage Mandatory/Optional depending if Program uses Program Plan

Value Table T7PIQLEVPERVAR (T7PIQLEVEL)

REGIST_DATE DATS 8 Key Date for Sessional Registration

Mandatory

PARTTIME CHAR 1 Indicator: Part-time Study Optional

Values: space, X

LEAVE_REASON NUMC 4 Leave of Absence Reason

Depends on REGIST_STATUS.

Not allowed for 1 – attending

Mandatory for 2 – non-attending

COMPL_LENGTH_STUDY NUMC 3 Completed Length of Study

Optional

REGIST_TYPE CHAR 2 Registration Type Mandatory.

Value Table T7PIQENRCATEG



DEGREE_SEEKING CHAR 1 Pursuing Degree Studies Leave empty.

Only relevant for GET function module

REGIST_STATUS CHAR 1 Sessional Registration Status

Mandatory

Values:

1 – attending (normal Registration)

2 – non-attending (for Leave)

REGIST_STATE CHAR 1 Sessional Registration Status Specification

Mandatory

Values:

A – active

I- inactive (means cancelled)

REGIST_CLASS CHAR 2 Registration Classification

Optional

Value Table T7PIQREGCLASS

CANCEL_PROCESS CHAR 4 Cancellation Activity (For Registration)

Mandatory if REGIST_STATE is I – inactive.

Fill with value:

RM03 – Cancel Sessional Registration

CANCEL_REASON NUMC 4 Cancellation Reason (For Registration)


Depends on value for CANCEL_PROCESS


CANCEL_DATE DATS 8 Key Date for Cancellation (Sess. Registration)


6.6.1.5 Parameter STUDY_SPECIALIZATIONS

For every specialization assignment one line should be added to this table.

Detailed explanation of parameter STUDY_SPECIALIZATIONS (Table of type PIQRFC_STUDY_SPECIALIZATIONS)


STUDENT_OBJECTID NUMC 8 Object Id Student See above


See above


See above

MODULEGROUP_OBJECTID NUMC 8 Object ID of Module Group

Mandatory



MODULEGROUP_CATEGORY CHAR 4 Module Group Category

Leave empty.

If filled, it will be checked if same as MODULEGROUP_CATEGORY

BEGDA DATS 8 Start Date Mandatory

Start Date of specialization assignment

ENDDA DATS 8 End Date Mandatory

End Date of specialization assignment

MODULEGROUP_PRIORITY CHAR 2 Priority Depends on module group variant for program.

If the order of module groups for a category must be maintained according to customizing of module group variants then fill this field with the order ‘1’, ‘2’, ‘3’ etc.

Check for numeric entry.

6.6.1.6 Parameter STUDY_OBJECTS_OUT

For every program where new records were created, one line containing the technical information about the study object will be added to this table.

Detailed explanation of parameter STUDY_OBJECTS_OUT (Table of type PIQRFC_STUDY_OBJECTS)


STUDENT_OBJECTID NUMC 8 Object Id Student



STUDY_OBJECT_BEGDA DATS 8 Technical Begin Date of Study Object

STUDY_OBJECT_ENDDA DATS 8 Technical End Date of Study Object



6.6.2 HRIQ_AW_ACWORK_DT_RFC

This remote enabled function module creates an academic work record for a specified student object id. Academic work is represented either by a SM object (Module) or a CW object (Credited Work). It is also possible to create one top appraisal per academic work record together with multiple appraisers. The usage of the academic work for program types and/or programs can also be imported – with this information the usage lists at the student object (infotype 1725) or the corresponding study object(s) (infotype 1724) will be updated. Optionally an event package can be imported. Sub-appraisals and appraisal elements, as well as event bookings are not supported. Resident work must be assigned to an academic year/session, for which the student must have a sessional registration. Interface: Parameter-Name Parameter-Type

Importing-Parameter PLANVERSION PLVAR STUDENTOBJECTID PIQSTUDENT ACADEMICWORK PIQAW_ACWORK LANGUAGE_ISO BAPI_LAISO-LANGU_ISO LANGUAGE SY-LANGU

Exporting-Parameter ACADEMICWORKID PIQAWID

Table-Parameter APPRAISERS PIQAGR_APPRAISER PROGTYPEUSAGE PIQPROGC_VAR PROGUSAGE PIQSCOBJID RETURN BAPIRET2

6.6.2.1 Parameter ACADEMICWORK

This parameter imports data of an academic work record together with grading data (top-appraisal).

For resident work, i.e. both modules and credited work with blank TRANSFERFLAG, an academic year and optionally academic session must be entered. If start and end dates of academic work (AWBEGDATE and AWENDDATE) are initial, the start and end dates of the corresponding academic year/session will be derived from the academic calendar. CA object and relevant relationships must be valid at the date of data transfer. If AWBEGDATE and AWENDDATE are imported they must be the start and end dates of the corresponding academic year/session, that’s why these two fields are optional for resident work. The timelimits for all required years/sessions must be available in the academic calendar (CA object which can be found using the standard evaluation path starting from the SM/CW object and using relationships valid on the date of the data transfer). The student must also have a sessional registration for this academic year/session.

For transfer work, academic year and session must be initial. The start and end dates of academic work (AWBEGDATE and AWENDDATE) must be set by the program calling the function module HRIQ_AW_ACWORK_DT_RFC. AWENDDATE is critical, because it identifies in the current data model the default date from which on an academic work record is relevant for the program type progression (could be changed through a BAdI implementation).


AWOTYPE CHAR 2 Object type Mandatory. Only object types SM and CW are supported

AWOBJID NUMC 8 Academic Work Object ID (Object Type SM/CW)

Mandatory. SM/CW object must exist



AWBEGDATE DATS 8 Start Date Should be set to the begin date of the academic year/session, during which the academic work was done. For transfer work, this would be the date of acknowledgment

AWENDDATE DATS 8 End Date Should be set to the end date of the academic year/session, during which the academic work was done. For transfer work, this would be the date of acknowledgment. This will be the date, from which the academic work can be used for progression runs and calculation of performance indices – i.e. this will be the ‘valid from’-date of the corresponding entry in the usage list (infotype 1724 of object type ST)

AWLOCKFLAG CHAR 1 Change lock flag

Optional. If this flag is set to ‘X’, the record will be locked for changes by normal users. Only administrators with special authorization can update it

AWSTATUS NUMC 2

Module Booking Status

Mandatory. Value table T7PIQSMSTAT

CANCELREASON CHAR 4 Cancellation Reason

Optional. Value table T7PIQWITHDRAWN. This field can only be filled if AWSTATUS is 4, Booking Cancelled

CANCELDATE DATS 8 Cancellation Date

Optional. This field can only be imported if AWSTATUS is 4, Booking Cancelled

BOOKDATE DATS 8 Booking Date Optional.

AWRATING CHAR 3 Special Assessment Method for Module

Optional. Value table T7PIQSMRATING. If entered, there will be a check to verify if AWRATING allows grade and/or credits

CHARGEFREE CHAR 1 Free of Charge Optional.

TRANSFERFLAG CHAR 1 Indicator: Transfer Course

Optional. Must be set to ‘X’ to mark transfer work.

EVENTPACKAGE NUMC 8 Event Package Optional. If information

is needed, which can be derived from an event package, e.g. campus, a SE object id can be imported

ACAD_SESSION NUMC 3 Academic Session

This field can only be filled if ACAD_YEAR is imported as well. Value table T7PIQPERIOD



ACAD_YEAR NUMC 4 Academic Year This field must be filled with a valid academic year for resident work. For transfer work, where TRANSFERFLAG is set to ‘X’, this field must be initial. Value table T7PIQYEAR

BOOKREASON CHAR 4 Reason for the Module Booking

Optional. Value table T7PIQBOOKREASON

ANNULMENT CHAR 1 Exclusion Indicator for Module Bookings

Optional. Value table T7PIQ_MR_ANNUL

AGRTYPE NUMC 4 Appraisal type Mandatory. Value table T7PIQAGR_TYPE

AGRSTAT CHAR 5 Appraisal status

Optional. Value table T7PIQAGRC_STAT

GRADESYMBOL CHAR 10 Grade Symbol Optional. Can only be imported if AWRATING allows grades. For cancelled records entry is allowed only if CANCELREASON is relevant for grading.

GRADE DEC 8,2 Grade norm value

Optional. GRADE is the norm value as internally used in SLCM. If imported, must be consistent with GRADESYMBOL and GRADESCALE

GRADESCALE CHAR 4 Scale-ID

Optional. Must be imported only if GRADESYMBOL is not blank. Value table T7PIQSCALE

AGRNOTRATED CHAR 1 Grade Not Relevant

Optional.

AGRDATE DATS 8 Appraisal Date Optional.

AGRCOMPLETED CHAR 1 Flag agreement completed

Optional. If this flag is set to ‘X’, AWSTATUS must be either 2, Successfully completed, or 3, Unsuccessfully completed. GRADESYMBOL and GRADESCALE must also be entered.

CPATTEMP QUAN 10,5 Attempted Credits

Optional. Can be imported, only if AWRATING allows credits. For cancelled records only if CANCELREASON allows grading.

CPEARNED QUAN 10,5 Earned Credits Optional. . CPEARNED < CPATTEMP

CPGRADED QUAN 10,5 Graded Credits Optional. CPGRADED < CPATTEMP

CPUNIT UNIT 3 Unit of Measurement for Credit

Optional. Must be filled if credits are imported. Value table T006



AWTEXT CHAR 50 Student specific text of academic work

Optional

6.6.2.2 Parameter APPRAISERS

In this table parameter multiple appraisers can be imported – one appraiser (must be a valid object in the SAP system) per line.


OTYPE CHAR 2 Objekttyp Mandatory

REALO CHAR 45 Erweiterte ObjektId

Mandatory

PLVAR CHAR 2 Planvariante Optional. If imported, must be consistent to parameter PLANVERSION

6.6.2.3 Parameter PROGTYPEUSAGE

In this table parameter program types (one per line) can be imported to keep the context in which the module or the credited work was completed or transferred. The program type context is critical for the use of program type progression and calculation of program type based performance indices.


PROGTYPEUSAGE CHAR 4 Program Type Optional. If imported, the program types will be used to update usage lists in infotype 1725 of the ST object

6.6.2.4 Parameter PROGUSAGE

In this table parameter programs of study (one per line) can be imported to keep the context in which the module or the credited work was completed or transferred.


PROGUSAGE NUMC 8 Program of Study Object ID

Optional. Identifies a valid SC object. If imported, the programs of study will be used to update usage lists in infotype 1724 of the CS object



6.6.2.5 Parameter ACADEMICWORKID


ACADEMICWORKID CHAR 32 Academic Work ID

For each created academic work record a unique identifier will be returned (different from the ID of the corresponding top-appraisal)

6.6.3 HRIQ_PROG_GR_DT_RFC

This remote enabled function module creates progression results record for a specified student object id. The progression results are only created if no Progression result for the specified program type and progression type exist. Interface: Parameter-Name Parameter-Type

Importing-Parameter PLANVERSION PLVAR STUDENTOBJECTID PIQSTUDENT

Exporting-Parameter

Table-Parameter PROG_RESULTS PIQPROG_GR_RESULT_CREATE RETURN BAPIRET2

6.6.3.1 Parameter PROG_RESULTS

Component Name Data Element Type/ Length

Description Comment

PROGRAM_TYPE PIQPROGC_VAR CHAR4 Program type ID

Mandatory.

PROGRESSION_CATEGORY

PIQPROG_TYPE CHAR1 Progression category

Mandatory. Academic honors Academic standing Academic standing for financial aid Progress classification Progress classification for financial aid

CHECK_TO PIQPROG_GR_CHECK_TO DATS End ate of Check period.

Mandatory Must be unique in table. Check From is implicit last Check to dates next day

VALID_FROM PIQPROG_GR_VALID_FROM

DATS Begin date of Validity

Mandatory Must be grater equal the CHECK_TO date. Validity to date is implicit the day before the next valid from date.

ACAD_YEAR PIQPROG_GR_PERYR CHAR4 Academic Year Academic Year for the

progression result. This should be usually the academic year of the check period.



ACAD_SESSION PIQPROG_GR_PERID CHAR4 Academic Session

Academic session for the progression result. This should be usually the academic year of the check period.

PROGRESSION_RESULT

PIQPROG_GR_RESULT_G CHAR4 Result ID. Mandatory.

PROGRESSION_RESULT_STATUS

PIQPROG_GR_RESULT_STATUS

CHAR1 Result status: final, pending, projected

Mandatory

6.6.4 HRIQ_CONFERQRFC_CREATEFROMDATA

This remote enabled function module creates a qualification record. For every qualification record one relationship 532 from the student (ST) to the qualification (CQ) and an appraisal record is created. Interface: Parameter-Name Parameter-Type

Importing-Parameter IV_PLVAR PLVAR IS_CONFERQ PIQCONFERQ

Exporting-Parameter IV_AGRID PIQAGRID

Table-Parameter ET_RETURN BAPIRET2 IT_CONFERQ_FUNC PIQCONFERQ_FUNC

6.6.4.1 Parameter IS_CONFERQ

Detailed explanation of parameter IS_CONFERQ (Structure PIQCONFERQ)


STUDENT_ID NUMC 8 Student Object Id Mandatory: Object-ID of student; object type ST

NORMVAL DEC 8 Standard Value of Proficiency on Scale

Optional. NORMVAL is the norm value as internally used in SLCM. If imported it must be consistent with GRADESYMBOL and GRADESCALE; if not imported the norm value is automatically determined by system

GRADESYMBOL CHAR 10 Grade Symbol Optional: if grade symbol is imported also scale has to be imported; a check will take place which checks if grade symbol is allowed for scale

SCALE CHAR 4 Scale ID Optional. Must be imported only if GRADESYMBOL is not blank. Value table T7PIQSCALE



CQNOTE CHAR 32 GUID - Unique Note Identifier CANNOT BE USED and is cleared in function module

CONF_COMMENT CHAR 50 Comment about the Qualification Optional; all characters allowed

CONFER_DATE DATS 8 Conferment Date Optional

AYEAR NUMC 4 Academic Year Optional; value table T7PIQYEAR

APERIOD NUMC 3 Academic Session Optional; value table is T7PIQPERIOD, if period is imported also year has to be imported; period is checked against year (relation table T7PIQYEARPRD)

VALID_FROM DATS 8 Validity Begin Optional

VALID_TO DATS 8 Validity End Optional

TRANSFERRED CHAR 1 Indicator: Transfer Course Indicates if qualification was transferred (Process ED)

CQ_ID NUMC 8 Object ID internal qualification Mandatory: Object-ID of qualification; object type CQ

PERIDFORCQ NUMC 3 Number of Periods to achieve a Qualification

Optional

PERIDFORCQUNIT CHAR 1 Unit for Number of Periods Optional: Allowed values are:

1 – academic years

2 –academic periods

REFOBJ_OTYPE CHAR 2 Object Type Optional: Object the qualification should be conferred for. Currently only programs make sense as ‘reference object’ which are represented by object type SC

REFOBJ_REALO CHAR 45 Extended Object ID Optional: see parameter REFOBJ_OTYPE; is OBJECT-ID of a program of study. If this parameter is filled REFONJ_OTYPE has also to be imported



6.6.4.2 Parameter IT_CONFERQ_FUNC

Detailed explanation of parameter IT_CONFERQ_FUNC (Structure PIQCONFERQ_FUNC):

Functions are obligatory; functions are checked against customizing table T7PIQAGR_FUNCOTY. The structure of this table includes following fields: MANDT, PROCESS, FUNCTION and OTYPE. Example of a function: Function: Conferring Institution. This function is customized like follows: for processes CQ01-CQ04 object type O is allowed. That means a conferring institution can only be a organizational unit.


SEQNR CHAR 3 Consecutive Numbers Sequential number; have to be unique in the importing table

OTYPE CHAR 2 Object Type Objet type of function e.g. Organizational Unit

REALO CHAR 45 Extended Object ID Object-ID, e.g. of an organizational unit

FUNCTION CHAR 4 Function ID of function; value table is T7PIQAGR_FUNC

6.6.5 HRIQ_TRANSCRIPT_CREATE

See function module HRIQ_TRANSCRIPT_CREATE.

6.6.6 HRIQ_TESTRESULTS_CREATE

See function module HRIQ_TESTRESULTS_CREATE.

6.6.7 HRIQ_RFC_STNOTE_CREATE

Short summary: Extension for Student Notes

The functionality for student notes will be enhanced in the following way:

• For every note type a note type category must be defined in customizing. Note categories are system-defined: (Free Format Note or Coded Note).

• For every note type it must be defined in customizing if the following context fields are not allowed, optional or mandatory.

o Program

o Stage

o Program Type

o Year and Session

This function module can be used to create student notes that can be free format notes or coded notes.

Interface:

Parameter-Name Parameter-Type

Importing-Parameter

PLANVERSION PLVAR

STUDENTOBJECTID PIQSTUDENT



NOTE_TYPE PIQNOTE_TYPE

NOTE_CONTEXT PIQNOTE_CONTEXT_KEY

NOTE_TITLE PIQNOTE_TITLE

Table-Parameter

NOTE_TEXT PIQNOTE_LINE

RETURN BAPIRET2

6.6.7.1 Parameter PLANVERSION

Planning version.

Optional.

If the value is empty, the function module gets the active planning version.

6.6.7.2 Parameter STUDENTOBJECTID

Student object ID.

Required.

6.6.7.3 Parameter NOTE_TYPE

Note type for the Note

Required.

6.6.7.4 Parameter NOTE_TITLE

The title of the note text

Optional. Only allowed for free format notes.

6.6.7.5 Parameter NOTE_CONTEXT

The field values in this structure depend on the attributes of the note type. The parameter is defined as optional, but might be required depending on the note type.

Component Data type Length Description Comment

PROGRAM_OBJECTID NUMC 8 Object ID Program

Mandatory, optional or not allowed depending on note type attributes

PROGRAM_TYPE CHAR 4 Program Type


STAGE NUMC 2 Stage Mandatory, optional or not allowed depending on note type attributes

ACAD_YEAR NUMC 4 Academic Year


ACAD_SESSION NUMC 3 Academic Session




6.6.7.6 Parameter NOTE_TEXT(Importing)

Component Data Type Length Description Comment

TDLINE CHAR 132 Text Not allowed for coded notes.

6.6.8 HRIQ_RFC_AGM_CREATE

Description: Use this FM to create Transfer Regulations for an external organizational unit.

Interface:

Parameter-Name Parameter-Type

Importing-Parameter

IV_EXTERNAL_ORG PIQEDEO

IV_PLVAR PLVAR

IV_COMMIT XFELD

Tables-Parameter

IT_AGM_HEADER PIQAGM_S_RFC_HEAD

IT_AGM_HEADER_TXT PIQAGM_S_RFC_HEAD_TEXT

IT_AGM_INT PIQAGM_S_RFC_INT

IT_AGM_EXT PIQAGM_S_RFC_EXT

ET_AGMID PIQAGM_S_AGMID_AGREE_NO

ET_RETURN BAPIRET2

6.6.8.1 Parameter IV_EXTERNAL_ORG

ID of the external organization (PD object type EO).

Required.

6.6.8.2 Parameter IV_PLVAR

Planning version.

Optional.

If the value is empty, the function module gets the active planning version.

6.6.8.3 Parameter IV_COMMIT

COMMIT WORK Control; set this flag to ‘X’ if data should be written to database within the FM call.

Optional, default value is SPACE, that means no COMMIT WORK is done.



6.6.8.4 Parameter IT_AGM_HEADER

Header information of Transfer Regulations. For one entry in this table several entries in tables IT_AGM_HEADER_TXT, IT_AGM_INT and IT_AGM_EXT can exist.

Component Datatype Length Description Comment TRANSFER_AGREE_NO

PIQAGM_EXTERNAL_NO 6 Number used to relate table entries of IT_AGM_HEADER-TXT, IT_AGM_INT and IT_AGM_EXT, required if several Transfer Regulations are created

This is NOT the ID of the Transfer Regulation, it is just a temporary number only used to relate / assign entries in different tables

EXTERNAL_BEGIN_DATE

PIQEDEXT_BEGDA 8 Valid From Date for Completion of Ext. Academic Achievement

EXTERNAL_END_DATE PIQEDEXT_ENDDA 8 Valid To Date for Completion of Ext. Academic Achievement

VALID_BEGIN_DATE PIQEDAGM_VALID_BEG 8 Validity Start Date of Transfer Regulation

VALID_END_DATE PIQEDAGM_VALID_END 8 Validity End Date of Transfer Regulation

FREE_CHARACTERS10 PIQEDFREE10 10 Characteristic 1 for Up To 10-Character Customer Entries

FREE_CHARACTERS20 PIQEDFREE20 20 Characteristic 2 for Up To 20-Character Customer Entries

PRIORITY PIQEDPRIORITY 2 Priority of Transfer Regulation

6.6.8.5 Parameter IT_AGM_HEADER_TXT

Text table for Transfer Regulations.


PIQAGM_EXTERNAL_NO 6 Temporary Number

See Parameter IT_AGM_HEADER

LANGUAGE LANGU 1 Language Key

AGREEMENT_TEXT PIQEDAGMTEXT 40 Text of Transfer Regulation



6.6.8.6 Parameter IT_AGM_EXT

Required external academic work (subjects, external qualifications) which will lead through a equivalency determination to internal academic work (credited work, modules, internal qualifications) (IT_AGM_INT). Between tables IT_AGM_EXT and IT_AGM_INT there is a n:m relationship, the relations are defined via a assignment number (TRANSFER_AGREEMENT_NO). See also table IT_AGM_HEADER.




EXTERNAL_OBJECT_TYPE

PIQEDEXTOTYPE 2 Object Type of External Academic Work or Qualification

Allowed object types are: SU = Subject, EQ = External Qualifcation

EXTERNAL_OBJECT HROBJID 8 Object ID

ACADEMIC_SCALE_ID PIQSCALE_ID 4 Academic Scale Identification (ID)

REQUIRED_GRADE PIQEDREQGRADE 10 Required Minimum Grade for External Academic Achievement

6.6.8.7 Parameter IT_AGM_INT

Internal academic work which is acknowledged for external academic work (IT_AGM_EXT). Between tables IT_AGM_EXT and IT_AGM_INT there is a n:m relationship, the relations are defined via a assignment number (TRANSFER_AGREEMENT_NO). See also table IT_AGM_HEADER.




INTERNAL_OBJECT_TYPE

PIQEDINTOTYPE 2 Object Type of Internal Academic Achievement

Allowed object types are: CW =Credited Work, SM = Module, CQ = Internal Qualification

INTERNAL_OBJECT OBJEKTID 8 Object ID

PROGRAM_TYPE PIQPROGC_VAR 4 Program Type

WITH_CREDITS PIQEDWITHCREDITS 1 Allocation of Credits for Internal Academic Achievement

WITH_GRADE PIQEDWITHGRADE 1 Allocation of Grade for Internal Academic Achievement

CREDIT PIQCP 10 Credit

CREDIT_UNIT PIQCPUNIT 3 Unit of Measurement for Credits

WITH_GRADE_DCR PIQEDWITHGRADEDCR 1 Graded Credits



6.6.8.8 Parameter ET_AGMID

Table of created Transfer Regulation Ids.

6.6.8.9 Parameter ET_RETURN

Table with Messages.

Related Content For more information, visit the Higher Education & Research homepage.





Copyright © 2008 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

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

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

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

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