SCT Banner Student / Release Guide / 7.1

SCT Banner 

Student 

Release Guide 

May 2005 

Release 7.1

Confidential Business Information 

This documentation is proprietary information of SunGard SCT and is not to be copied, reproduced, lent or disposed of, nor used for any 

purpose other than that for which it is specifically provided without the written permission of SunGard SCT. 

Prepared By: 

SunGard SCT 

4 Country View Road 

Malvern, Pennsylvania 19355 

United States of America 

© SunGard 2005. All rights reserved. The unauthorized possession, use, reproduction, distribution, display or disclosure of this material or 

the information contained herein is prohibited. 

In preparing and providing this publication, SunGard SCT is not rendering legal, accounting, or other similar professional services. SunGard 

SCT makes no claims that an institution's use of this publication or the software for which it is provided will insure compliance with applicable 

federal or state laws, rules, or regulations. Each organization should seek legal, accounting and other similar professional services from 

competent providers of the organization's own choosing. 

SunGard, the SunGard logo, SCT, the SCT logo, and Banner, Campus Pipeline, Luminis, PowerCAMPUS, SCT fsaATLAS, SCT Matrix, SCT 

Plus, SCT OnSite and SCT PocketRecruiter are trademarks or registered trademarks of SunGard Data Systems Inc. or its subsidiaries in the 

U.S. and other countries. All other trade names are trademarks or registered trademarks of their respective holders.

Release Guide 

Student System 

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

Enhancements for 7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

Miscellaneous Enhancements (RPEs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

Problem Resolutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

Section 1 Concurrent Curricula Phase 2 - Functional . . . . . . . . . . 15 

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

Processing Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

Purging Curriculum and Field of Study Rows. . . . . . . . . . . . . . . . . . . . . . . 15 

Tracking Non-Destructive Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

Examining SOBLMOD Maximums during Conversion Process . . . . . . . . . . . . . . 19 

Using the Roll Indicator on SORLCUR . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

Determining Which Curriculum Rows are Current . . . . . . . . . . . . . . . . . . . . 24 

Modifying the Curriculum and Field of Study Sort Order . . . . . . . . . . . . . . . . . 29 

Changed Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

Curriculum Status Validation Form (STVCSTS) . . . . . . . . . . . . . . . . . . . . . . 30 

Quick Recruit Form (SRAQUIK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

Recruit Prospect Information Form (SRARECR) . . . . . . . . . . . . . . . . . . . . . . 30 

Quick Entry Form (SAAQUIK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

Admissions Application Form (SAAADMS) . . . . . . . . . . . . . . . . . . . . . . . . 31 

General Student Form (SGASTDN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

Student Course Registration Form (SFAREGS). . . . . . . . . . . . . . . . . . . . . . . 31 

Degrees and Other Formal Awards Form (SHADEGR) . . . . . . . . . . . . . . . . . . 31 

Learner Curriculum Query Form (SOILCUR) . . . . . . . . . . . . . . . . . . . . . . . 32 

Admissions Decision and Rating Batch Entry Form (SAADCBT) . . . . . . . . . . . . . 32 

Admissions Decision Form (SAADCRV) . . . . . . . . . . . . . . . . . . . . . . . . . 32 

New Reports and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

Learner Curriculum Purge Process (SOPLCPG) . . . . . . . . . . . . . . . . . . . . . . 32 

Non-Destructive Curric Update Report (SORLCHG) . . . . . . . . . . . . . . . . . . . 34 

Changed Reports and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

Learner Curriculum Conversion Process (SOPLCCV) . . . . . . . . . . . . . . . . . . . 36 

Admit Decision Calc Report (SARBDSN) . . . . . . . . . . . . . . . . . . . . . . . . . 36 

3

Table of Contents 

Student Type Update Report (SHRTYPE) . . . . . . . . . . . . . . . . . . . . . . . . . 37 

Degree Status Update Report (SHRDEGS) . . . . . . . . . . . . . . . . . . . . . . . . 37 

Report Samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

Learner Curriculum Purge Process (SOPLCPG). . . . . . . . . . . . . . . . . . . . . . 37 

Non-Destructive Curric Update Report (SORLCHG) . . . . . . . . . . . . . . . . . . . 37 

Section 2 Loading Delimited Prospect Files - AMCAS Phase 1 - 

Functional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 

Process Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 

Loading Packages and Procedures from Temporary Tables to Production Tables 

(SRKPREL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 

New Forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 

Tape File Delimiter Type Rules (SORDLIM) . . . . . . . . . . . . . . . . . . . . . . . 64 

Tape File Test Score Controls (SRATPTS) . . . . . . . . . . . . . . . . . . . . . . . . . 64 

Changed Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 

Test Score Information Form (SOATEST) . . . . . . . . . . . . . . . . . . . . . . . . . 65 

Tape Code Conversion Form (SOTCNVT) . . . . . . . . . . . . . . . . . . . . . . . . 71 

Electronic Admissions Application Rules Form (SAAERUL). . . . . . . . . . . . . . . . 72 

Tape Field Position Rule Form (SRATPFD) . . . . . . . . . . . . . . . . . . . . . . . . 75 

Changed Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 

Search Tape Control Menu (*SEARCHCONT) . . . . . . . . . . . . . . . . . . . . . . 78 

Changed Reports and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 

AMCAS Data Load Process (SAPAMAL) . . . . . . . . . . . . . . . . . . . . . . . . . 78 

Electronic Prospect Load (SRTLOAD) . . . . . . . . . . . . . . . . . . . . . . . . . . 78 


AMCAS Data Load Process (SAPAMAL) . . . . . . . . . . . . . . . . . . . . . . . . . 79 

Electronic Prospect Load (SRTLOAD) . . . . . . . . . . . . . . . . . . . . . . . . . . 79 

Section 3 Fee Assessment Drop/Delete Processing - Functional . . . 101 

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 

Updated Functionality for the Drop/Delete Process . . . . . . . . . . . . . . . . . . 101 

Examples of Drop/Delete Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 

Student Release 7.1 May 2005 

4 Release Guide Confidential


Registration Activity Processing Order . . . . . . . . . . . . . . . . . . . . . . . . . . 105 

Examples of Registration Activity Processing Order . . . . . . . . . . . . . . . . . . . 105 

Changed Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 

Class Attendance Roster Form (SFAALST) . . . . . . . . . . . . . . . . . . . . . . . . 111 

Class Roster Form (SFASLST) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 

New Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 

Fee Assessment Report (SFRFEES) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 

Changed Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 

Purge Fee Assessment Audit Process (SFPFAUD) . . . . . . . . . . . . . . . . . . . . . 112 

Report Sample. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 

Fee Assessment Report (SFRFEES) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 

Section 4 Fee Assessment Registration Updates - Functional . . . . . 127 

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 

Using Optional Swapping Processing with Refund by Course . . . . . . . . . . . . 127 

Refund by Course Processing and Examples . . . . . . . . . . . . . . . . . . . . . . . 127 

Swapping and Section Fees Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 130 

Manually Updating Existing Registration Status Codes. . . . . . . . . . . . . . . . . 130 

Storing Related Values and Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 

Updating Open Learning Registration Processes . . . . . . . . . . . . . . . . . . . . 133 

Capturing Rule Data During Processing . . . . . . . . . . . . . . . . . . . . . . . . . 133 

Processing Amounts Greater Than 9999.99 . . . . . . . . . . . . . . . . . . . . . . . 134 

Using ActionLine Fee Assessment Scripts . . . . . . . . . . . . . . . . . . . . . . . . 135 

srsobterm.sql - Script to Identify Term Base Information . . . . . . . . . . . . . . . . . 135 

srsfrareg.sql - Script to Identify Open Learning Registration Course Extension 

Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 

srsfrstcr.sql - Script to Identify Student Registration Information . . . . . . . . . . . . . 135 

srsfrfaud.sql - Script to Identify Registration Fee Assessment Audit Information . . . . . 136 

srsfbetrm.sql - Script to Identify Student Enrollment Information . . . . . . . . . . . . . 136 

srsfrafee.sql - Script to Identify Student Additional Fees Information . . . . . . . . . . . 136 

May 2005 Student Release 7.1 

Confidential Release Guide 5


Changed Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 

Crosswalk Validation Form (GTVSDAX) . . . . . . . . . . . . . . . . . . . . . . . . . 136 

Registration Additional Fees Control Form (SFAAFEE) . . . . . . . . . . . . . . . . . . 137 

Registration Additional Fees Form (SFAEFEE) . . . . . . . . . . . . . . . . . . . . . . . 137 

Registration Fee Assessment Audit History Form (SFAFAUD) . . . . . . . . . . . . . . . 137 

Student Registration History and Extension Form (SFARHST) . . . . . . . . . . . . . . . 137 

Term Control Form (SOATERM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 

Section 5 Concurrent Curricula Phase 2 - Technical . . . . . . . . . . . 139 

New Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 

Curriculum Term Parameter Global Temporary Table (SOTVCUR) . . . . . . . . . . . . 139 

Curriculum Base Verification Global Temporary Table (SOTLCUR) . . . . . . . . . . . 139 

Field of Study Verification Global Temporary Table (SOTLFOS) . . . . . . . . . . . . . 140 

Changed Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 

Field of Study Table (SORLFOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 

Curriculum Term Parameter Global Temporary Table (SOTVCUR) . . . . . . . . . . . . 140 

Changed Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 

SAKDCSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 

SAKMODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 

SAKL010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 

SHKROLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 

SOKLCUR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 

Changed Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 

p_create_recruit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 

p_create_applicant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 

p_create_student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 

p_copy_lcur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 

p_copy_lfos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 

p_create_lfos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 

p_create_secondary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 

p_load_application_two . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 

p_process_graderoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 

p_process_fieldofstudy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 

p_convert_curr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 

Obsolete Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 

copy_lcur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 

copy_lfos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 

New Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 

f_lcur_count_status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 

f_lfos_count_status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 




New Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 

sorlfos1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 

sinvcsts1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

Changed Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

NEW_SORLCUR_INST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

CURRICULUM_COMMIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

VALIDATE_CURRICULUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

Changed Object Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

SOQOLIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

Changed APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 

sb_curriculum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 

sb_learner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 

Seed Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 

Section 6 Loading Delimited Prospect Files - AMCAS Phase 1 - 

Technical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 

New Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 

Tape file Delimiter Type Rules Table (SORDLIM) . . . . . . . . . . . . . . . . . . . . 149 

Tape File Test Score Control Table (SRRTPTS) . . . . . . . . . . . . . . . . . . . . . . 149 

Changed Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 

Temporary Tape Name Table (SRTTPFD). . . . . . . . . . . . . . . . . . . . . . . . . 149 


SRKPREL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 

SRKPRE1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 

New Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 

srkcomm.insert_comm_plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 

Changed Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 

p_migrate_prospect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 

New Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 

New Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 




New APIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 

New Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 

Section 7 Fee Assessment Drop/Delete Processing - Technical. . . . 153 

New Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 

Registration Drop-Delete Collector Table For Fee Assessment (SFRREDG) . . . . . . . . 153 


Student Course Registration Repeating Table (SFRSTCR) . . . . . . . . . . . . . . . . . 154 

Fee Assessment Audit Table (SFRFAUD) . . . . . . . . . . . . . . . . . . . . . . . . . 154 


SFKEDIT1 - Package Body for Registration Edits . . . . . . . . . . . . . . . . . . . . . 155 

SFKMODS - Package Specification for Objects Used to Process Student and Related 

Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 

SFKMOD1 - Package Body for Objects Used to Process Student and Related Data. . . . 155 

SFKFEES - Package Specification for Registration Fee Assessment . . . . . . . . . . . . 156 

SFKFEE1 - Package Body for Registration Fee Assessment . . . . . . . . . . . . . . . . 156 

New Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 

sfkmods.p_insert_sfrregd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 

sfkmods.p_delete_sfrregd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 

sfkmod1.p_insert_sfrregd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 

sfkmod1.p_delete_sfrregd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 


sfkedit.p_update_regs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 

sfkfee1.p_create_nondrop_hrs_sfrfaud . . . . . . . . . . . . . . . . . . . . . . . . . . 158 

sfkfee1.p_get_last_assess_flat_data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 

sfkfee1.p_calc_reg_hr_liability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 

sfkfee1.p_processfeeassessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 

sfkfee1.p_studentfees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 

sfkfee1.p_levelfees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 

sfkfee1.p_campusfees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 

sfkfee1.p_attributefees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 

New Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 

sfkfees.f_DD_since_last_assess. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 

sfkfee1.f_DD_since_last_assess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 

sfkfees.f_get_sfrstcr_date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 

sfkfee1.f_get_sfrstcr_date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 




Changed Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 

sfkfee1.f_get_prev_nondrop_hrs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 

sfkfee1.f_prev_flat_rule_met . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 

New Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 

scrfees1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 

ssrfees1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 

sfrfaud1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 

sfrregd1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 

sfrregd2.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

sfrregd3.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

sfrregd4.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

sfrregd5.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

sfrregd6.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

sfrregd7.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

sfrregd8.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

sfrregd9.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

sfrregd10.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

sfrstcr1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

sftstcr1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 

sftstcr2.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 

sfvregd.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 

sinssdax2.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 

Fee Assessment Script Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 

Changed Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 

st_sfrstcr_post_update_row . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 

st_sfrstcr_post_delete_row . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

New Primary Key Constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

New Foreign Key Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

New Banner View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

SFVREGD - View Student Registered and Dropped/Deleted Courses For Fee 

Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

Section 8 Fee Assessment Registration Updates - Technical . . . . . . 171 


Student Course Registration Repeating Table (SFRSTCR) . . . . . . . . . . . . . . . . . 171 

Student Enrollment Status Table (SFBETRM) . . . . . . . . . . . . . . . . . . . . . . . 171 

Additional Registration Information Table (SFRAREG) . . . . . . . . . . . . . . . . . . 171 

Fee Assessment Audit Table (SFRFAUD) . . . . . . . . . . . . . . . . . . . . . . . . . 171 

Registration Additional Fees Repeating Table (SFRAFEE) . . . . . . . . . . . . . . . . . 172 

Term Base Table (SOBTERM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 





SFKEDIT - Registration Edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 

SFKMODS - Registration Modifications . . . . . . . . . . . . . . . . . . . . . . . . . 174 

SFKFEES - Registration Fee Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . 174 

SFKOLRL - Open Learning Refunding Rules . . . . . . . . . . . . . . . . . . . . . . . 174 

New Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 

sfkmods.p_insert_sfrregd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 

sfkmods.p_delete_sfrregd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 

sfkfees.p_process_hours_swap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 


sfkedit.p_update_regs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 

sfkmods.p_insert_sfrareg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 

sfkmods.p_update_sfrareg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 

sfkmods.p_insert_sfrstcr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 

sfkmods.p_update_sfrstcr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 

sfkfees.p_processfeeassessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 

sfkfees.p_reverse_na_charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 

sfkfees.p_processcourse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 

sfkfees.p_extensionfees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 

sfkfees.p_insert_sfrfaud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 

sfkfees.p_apply_rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 

New Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 

sfkfees.f_flat_rule_exists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 

Changed Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 

sfkolrl.f_calculate_percent_complete . . . . . . . . . . . . . . . . . . . . . . . . . . 178 

New Scripts - ActionLine Fee Assessment Scripts . . . . . . . . . . . . . . . . . . . . 179 

srsobterm.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 

srsfrareg.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 

srsfrstcr.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 

srsfrfaud.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 

srsfbetrm.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 

srsfrafee.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 

New Scripts - Seed Data Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 

sfrareg1.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 

sfrareg2.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

sfrareg3.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

sfrareg4.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

sobterm1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

sobterm2.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

sobterm 3.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

sobterm4.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

sobterm5.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 




sobterm6.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

sfrstcr1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 

sfrstcr2.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 

sfbetrm1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 

sfbetrm2.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 

sfbetrm3.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 

sfrfaud1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 

sfrfaud2.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 

sfrafee1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 

gtvsdax1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 

Changed Banner View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 

SFVFAUD - View Student Registration Fee Assessment Audit . . . . . . . . . . . . . . 183 

Changed API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 

sb_term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 

Section 9 Miscellaneous Enhancements . . . . . . . . . . . . . . . . . . . . 185 

IPEDS Spring 2005 Regulatory Updates . . . . . . . . . . . . . . . . . . . . . . . . . 185 

Common Matching Update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 

RPEs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 

Concurrent Curricula Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 

AMCAS Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 

Registration Fee Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 

Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 

Section 10 Problem Resolutions . . . . . . . . . . . . . . . . . . . . . . . . . 195 

Catalog Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 

Schedule Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 

General Person Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 

Location Management Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 

Recruiting Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 

Admissions Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 

General Student Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 




Registration Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 

Academic History Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 

CAPP Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 

Overall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 

MIS Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 

Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 


Dormitory Address Creation Report (SLRDADD) . . . . . . . . . . . . . . . . . . . . . 221 

Student Schedule Report (SFRSCHD). . . . . . . . . . . . . . . . . . . . . . . . . . . 222 

IPEDS Total Activity Report (SHRIACT). . . . . . . . . . . . . . . . . . . . . . . . . . 222 



Introduction 

Introduction 

This document describes Release 7.1 of the Banner Student System. The 

following information is included in Release 7.1. 

Enhancements for 7.1 

The following enhancements are new for Release 7.1. 

Concurrent Curricula Phase 2 

Phase 2 of the Concurrent Curricula enhancement allows an institution to record 

and use multiple curricula for a person as they move through the student cycle. This 

phase delivers the table and API structure used by concurrent curricula to store the 

multiple curricula. 

Loading Delimited Electronic Prospect Files - AMCAS Phase 1 

Phase 1 of this enhancement centralizes data load processing in Banner Student, 

specifically using the Electronic Prospect Load (SRTLOAD). 

Fee Assessment Drop/Delete Processing 

This enhancement contains updates for the drop/delete (DD) process for fee 

assessment that correct a number of problem resolutions. 

Fee Assessment Registration Updates 

This enhancement contains problem resolutions related to swapping processing for 

refunding by course and updating existing registration status codes, as well as 

updates to open learning registration. 

Miscellaneous Enhancements (RPEs) 

This section lists RPEs and small enhancements by module. This section also 

includes IPEDS regulatory updates. 

Problem Resolutions 

This section contains descriptions of problem resolutions by module. 



Introduction 

This page intentionally left blank 



Section 1 Concurrent Curricula Phase 2 - Functional 

Overview 

Section 1 

Concurrent Curricula Phase 2 - Functional 

This enhancement is new for Release 7.1. 

Overview 

Phase 2 of this enhancement provides additional Concurrent Curricula 

functionality through a new report used to track non-destructive updates, as well as 

a new process used to purge non-current and inactive curricula. In addition, several 

processing features that were deferred from Release 7.0 are included. RPEs are also 

included in this phase of the enhancement. 

This enhancement includes corrections for the following problem resolutions: 

#100821, #100822, #100823, and #102295. The following RPEs are also included: 

#44150, #44156, and #44157. 

Processing Changes 

Purging Curriculum and Field of Study Rows 

The new Learner Curriculum Purge Process (SOPLCPG) is used to purge 

SORLCUR rows and/or SORLFOS rows for Admissions and Recruiting records. 

This process satisfies RPE #44157. 

Since users may not want to maintain inactive and non-current curriculum records 

on a student, they can use SOPLCPG to purge inactive and non-current student 

curricula. This process deletes an SORLCUR row and its associated SORLFOS 

row(s). However, this process is restricted to only purging the curriculum records 

that are part of Recruiting and Admissions. The Learner (General Student) and 

Outcome (Academic History) curriculum records are not considered by this 

process. 

• Inactive curriculum rows are defined as rows where the Activity field has a type 

of INACTIVE (SORLCUR_CACT_CODE). Whether an activity code is inactive is 

determined on SORCACT. Any code established on SORCACT that does not 

have the SOBCACT_ACTIVE_IND set to Y is deemed to be inactive. 

• Non-current curriculum rows are defined as rows that have a value of N in the 

Current field in the Curriculum or Field of Study blocks. The value that 

populates the field is located in the SOVLCUR_CURRENT_IND and 

SOVLFOS_CURRENT_IND view fields. 





The SOPLCPG process ensures that if a curriculum record (SORLCUR) is removed, 

all related field of study rows (SORLFOS) are also removed. This process only 

purges curriculum rows that are inactive and non-current. Field of study rows are 

only purged in association with their respective curriculum record. Therefore, if a 

curriculum record is current and has an associated SORLFOS row that is noncurrent 

and inactive, the SORLFOS row will not be purged. 

This process is run for an ID or a population selection, by term and/or learner 

module, and can be run in update or audit mode. 

Please refer to the “New Reports and Processes” section for parameter information. 

Tracking Non-Destructive Updates 

The new Non-Destructive Curric Update Report (SORLCHG) is used to show nondestructive 

updates made to curriculum and/or field of study records. This process 

satisfies RPE #44156. 

A non-destructive update is used in the curriculum rows to maintain a history of all 

changes to a learner's curriculum, as no updates are allowed to existing curriculum 

and field of study records. The process used to update existing curriculum 

information is to duplicate the existing record, and then update the newly created 

record with the appropriate changes (i.e., to inactivate the record and indicate why 

it was inactivated). This report may be used to track changes made in curriculum, 

attempt to establish trends, and determine curriculum retention. The process 

selects SORLFOS rows independently of the associated SORLCUR rows. 

Note: Users are allowed to delete curriculum and field of study records. 

Deleted records are not considered non-destructive and will not be 

displayed on the report. 

The system will determine if a record has a non-destructive update using the 

following criteria: 

• If a row is non-current, the SOVLCUR_CURRENT_IND and/or the 

SOVLFOS_CURRENT_IND fields are set to N. 

or 

• If a row has a curriculum activity status of type INACTIVE (the 

SOBCACT_ACTIVE_IND is set to N). 

Note: A row can be inactive and still be current. Conversely, a row can be noncurrent 

and still be active. 

This report is run for an ID, all IDs, or a population selection, by term and/or 

learner module, by start and end dates, by curriculum status and/or curriculum 

activity status, and by searches on SORLCUR, SORLFOS or both. 





Output Sort Order 

The report sort order is based on the following criteria: 

• Records are sorted by last name, first name, middle name, and Banner ID (in 

ascending order). 

• Within each returned ID, the curriculum non-destructive updates are sorted by 

module (Recruiting, Admissions, Learner, Outcome), term code (in 

descending order), key sequence number (in ascending order), and then by 

curriculum sequence number (in descending order). 

• The SORLFOS rows are sorted by type (major first, minor second, 

concentration third, user-defined SORLFOS types fourth (in alpha ascending 

order)), priority (in ascending order), and sequence number (in descending 

order). 

Report Type Parameter Options 

The Report Type parameter allows you to define output three ways. Enter A to run 

the search against SORLCUR and SORLFOS, L to run the search against SORLCUR 

only, or F to run the search against SORLFOS only. The default is A. 

Value of L 

If you enter the value L, the output appears as follows when the curriculum with the 

non-destructive update is current and active: 

• The current, active curriculum and its current, active field of study are followed 

by all previous (non-current) curriculum occurrences with the same priority. 

These print in descending curriculum sequence order. 

• The non-current curriculum has the word “OLD” printed to the right of its 

learner type module. 

• All fields of study are printed for the non-current curriculum. 

If you enter the value L, the output appears as follows when the curriculum with the 

non-destructive update is not active: 

• Only the inactive curriculum is printed along with all of its fields of study. 

Value of F 

If you enter the value F, the output appears as follows: 

• The curriculum with the non-destructive field of study change is printed along 

with all its fields of study. 

Value of A 

This option combines the options for the values L and F. If you enter the value A, 

the output appears as follows: 





• If the curriculum has a non-destructive update, then processing follows the 

same rules as described above for the value L. 

• If the field of study has a non-destructive update and the curriculum does not, 

then processing follows the same rules as described for the value F. 

Term Code Records that are Non-Current or Inactive 

When using the term code to search for records with non-destructive updates, the 

report retrieves records with non-destructive updates for that term. It does not 

retrieve non-current records from SORLCUR and SORLFOS that match the 

entered term code. 

• When processing non-current records by term, the process does not look at the 

term code of a non-current row when matching the entered term code. It looks 

at the term of the record that caused the row to become non-current. This is 

particularly significant for Learner and Outcome type modules. The term 

code will always be the same on the non-destructive update curriculum and the 

current curriculum, if the module is Admissions or Recruit. 

For example, 

A student has the following Learner module curriculum: 

Program Priority Term Current Status 

BA-MATH 1 200510 Y Active 

If the learner decided to change his program in Term 200610 to BS- 

ECONOMICS, but the institution wanted to retain the record of the original 

program, the record would look as follows: 

Program Priority Term Current Status 

BA-ECONOMICS 1 200610 Y Active 

BA-MATH 1 200510 N Active 

If you run SORLCHG for term 200510, you will not retrieve the student shown 

above, since the change that caused the row to become non-current occurred 

in 200610. If you run the report for term 200610, you will retrieve the 

SORLCUR row for BA-MATH. Term 200610 is the term in which the nondestructive 

update took place and caused the BA-MATH program to be noncurrent. 

• When processing inactive records term, the process uses the term code of the 

inactive row that is current to determine if the row can be included. The term 

code for the term when the row was made inactive is an accurate date for the 

parameters. The logic used to determine if a row is inactive is much simpler, 

since the only way a row can be made inactive is to insert a row of type 

INACTIVE. 





Start/End Dates for Records that are Non-Current or Inactive 

When using the start and/or end dates to search for records with non-destructive 

updates, the report retrieves records as follows. 

• When processing non-current records by start and/or end date, the report takes 

into consideration that updates are not allowed on a curriculum row, and the 

activity (start or end) date of the non-current row is not an indicator of when 

the row became non-current. Therefore, the parameters do not look for the 

activity date of the non-current row. 

For example, if a user creates an SORLCUR record with a priority of 1 in 

January, and then inserts a second SORLCUR record with a priority of 1 in 

March, the SORLCUR record from January would now be non-current (since 

the later entry of March has the same priority and a higher sequence number). 

However, the activity date on the non-current record is still January. It does not 

get updated, although the row was made non-current in March. 

When determining if a non-current row falls within the entered date range, the 

report will use the activity date of the highest sequence number of the row with 

the same priority that is current. Therefore, the report looks for when a row 

was made non-current, not the activity date of the non-current row. 

• When processing inactive records by start and /or end date, the report uses the 

activity date of the inactive row that is current to determine if the row can be 

included. The activity date of when the row was made inactive is an accurate 

date for the parameters. 

Please refer to the “New Reports and Processes” section for parameter information. 

Examining SOBLMOD Maximums during Conversion Process 

This updated processing satisfies problem resolution #100821. 

Conversion from Base Tables to SORLCUR and SORLFOS 

The curriculum conversion process did not provide error processing for the 

established SOBLMOD maximums to determine what to records should be 

converted. The process attempted to convert existing primary as well as secondary 

curriculum records. This could lead to errors when the SOBLMOD maximum 

allowed was less that what was currently in the base table. 





For example, if an applicant had two curricula specified in the SARADAP table 

(primary and secondary) and the SOBLMOD maximum allowed curriculum for the 

Admissions module was one, the conversion process would attempt to populate the 

SORLCUR table with the two curricula specified in SARADAP. This caused the 

conversion process to abort with the error that the SOBLMOD maximum allowed 

had been exceeded. 

The conversion process now looks at the SOBLMOD maximum allowed for a 

module when converting curricula records and does not produce an error when the 

maximum is exceeded. The conversion process will continue to convert all 

curriculum records from the base table. However, instead of generating an error 

when the base table number of curricula exceeds the SOBLMOD maximum 

number, the conversion process will take the curricula that exceed the maximum 

and make those records inactive. So in the second scenario above, the process 

would now convert both majors. However, only the primary major will be active; the 

other major will be converted to SORLFOS, but will be inactive with a status of 

OVERLOAD. 

Forms and Processes that Call the Conversion Process 

To convert data for a single ID or a larger population, you can run the Learner 

Curriculum Conversion Process (SOPLCCV). The process can be run for an 

individual ID, for all IDs with curricula records (using a parameter value of %), or 

for a population selection. The conversion process can be called as well from the 

following forms and processes: SRARECR, SRAQUIK, SAAADMS, SAAQUIK, 

SOILCUR, SGASTDN, SFAREGS, SHADEGR, the grade roll process in SFAALST, 

SFASLST, and SHRROLL, the electronic prospect push process from SRIPREL, the 

electronic applicant push process from SAAEAPS, the decision process from 

SAADCBT and SAADCRV, the end of term processing in SHRTYPE and SHRDEGS, 

the Self-Service Quick Admit, and the Self-Service Registration Term Update. 

Standardized Copy from One Learner Module to Another 

Processing for how each of the processes validates the number of curricula allowed 

and how they process any overload has been standardized. Certain processes roll or 

push curriculum data from one learner module to another. For example, the grade 

roll process from SFAALST and SFASLST rolls Learner (General Student) 

information to the Learner Outcome (Academic History) and updates records on 

SHADEGR. 

Inconsistencies existed in how the various processes handled rolling curricula when 

the sending module had more curricula records to roll than were allowed by the 

receiving module. Certain processes produced an error when you attempted to roll 

more curricula than were allowed. Others did not produce an error, but would only 

roll the allowable number of curricula. The following examples discuss this. 

• On SOACTRL, the Learner module allows three majors per curriculum, and 

the Outcome module only allows two. A student that has three active majors 

specified for the module of LEARNER has completed a term. Grades are 





entered, and an attempt is made to roll grades to Outcome (Academic 

History). The roll process would fail, since the Outcome module does not 

allow students to have three active majors. None of the records would be 

rolled. 

• On SOACTRL, the Admissions module allows three majors per curriculum, 

and the Learner module only allows two. A student has three active majors 

established for the module of ADMISSIONS. A decision to admit the student is 

entered that creates a general student record. The decision process 

determines that all three majors cannot be rolled to the Learner module. 

Therefore, the process only rolls the two majors that are of the highest priority. 

This results in a partial roll of records. 

The following forms call processes that would generate error or non-roll conditions: 

SRIPREL, SFAALST, SFASLST, and SAAQUIK. The following forms call processes 

that would create non-error or partial roll conditions: SAADCBT, SAADCRV, and 

SAAEAPS. 

To standardize handling of curricula records overload processing and still alert the 

user that records were or were not rolled to the Learner module, all curricula 

records are now rolled from one module to another. If the conversion process 

determines that the maximum number of curricula allowed is less than the number 

of curricula to be rolled, it will make the "overload" curricula records inactive. The 

overload curricula records will be the records with the lowest priority. The process 

will inactivate curriculum records until the number of curricula equals the 

maximum count allowed. 

In order to differentiate between a curriculum row that was made inactive due to the 

overload scenario and one that was made inactive manually by a user, when the 

system inactivates a curriculum row, it will set the Activity field 

(SORLCUR_CACT_CODE and/or SORLFOS_CACT_CODE) to OVERLOAD. This value has 

been added to STVCSTS as delivered seed data, that is system-required and inactive. 

For example, on SOACTRL, the rules are set up so that the Learner Module field 

for a value of LEARNER allows three majors. The Learner Module field for a value 

of OUTCOME allows two majors. A student with a general student record has three 

active majors for a curriculum. The majors for LEARNER would appear as follows: 

Priority Major Name Status 

1 Math ACTIVE 

2 Engineering ACTIVE 

3 Statistics ACTIVE 

When grades are entered and rolled, the following data is captured for the 

curriculum record in the Outcome module: 





Priority Major Name Status 

1 Math ACTIVE 

2 Engineering ACTIVE 

3 Statistics OVERLOAD 

Since the Statistics major had the lowest priority, and the receiving SOBLMOD 

record only allowed for two majors, the major was rolled, but it was changed to an 

inactive status of OVERLOAD. 

Conversion from the Key Block of Forms 

The forms that process curriculum data and allow conversion from the Key Block 

(SRAQUIK, SRARECR, SAAQUIK, SAAADMS, SGASTDN, SFAREGS, SHADEGR, 

and SOILCUR) did not allow you to insert a record which exceeded the maximum 

number of curricula allowed in SOBLMOD. Also, on forms were it was allowed, the 

Duplicate Record function displayed an error if the duplicated record's number of 

curricula exceeded what was currently allowed on SOBCTRL. 

When a user attempted to insert a new curriculum record that exceeded the 

SOBLMOD count, an error would occur. Now, when an application is being 

created, and a record from SRASUMI or SAASUMI is used to populate the form, any 

excess curricula records will be inactivated. Also, when performing a Duplicate 

Record function, any excess curriculum records will be inactivated. If a user is 

manually creating or inserting a curriculum record on a form, and enters more 

SORLCUR or SORLFOS types than are allowed on SOACTRL, the form will display 

an error. The overload processing is only used when records are created or 

populated by processes, from summary forms, or by duplicate record functionality. 

Reducing Maximum Counts after a Record is Created 

To reduce the maximum counts after a record is created, consider the following. A 

student could have two active curriculum records for a learner module, and a user 

could subsequently reduce the amount of curricula allowed on SOACTRL for that 

learner module to one. 

For example, a student has two curriculum records specified on SAAADMS, and the 

institution decides that only one curriculum record for the Admissions module 

would be allowed. Now the student has exceeded the maximum curricula allowed 

for the SOBLMOD record for Admissions. When this student record is accessed, the 

conversion process will mark the active curricula with the lowest priority as inactive, 

in order to bring the record into compliance with the maximum setting on 

SOACTRL. 





Using the Roll Indicator on SORLCUR 

This modified processing satisfies problem resolution #100822. 

In Release 7.0, the Roll Indicator on the SORLCUR table (SORLCUR_ROLL_IND) was 

a not NULL field. The only possible values were N and Y, with the default being Y. 

This was set on a curriculum record by first checking if the curriculum record had 

a curriculum rule established on SOACURR. If that was so, and the curriculum was 

a primary one, the system used the value on SOACURR for the program 

(SOBCURR_PRIM_ROLL_IND). If it was a secondary curriculum only (all that are not 

primary), the system used the secondary curriculum value 

(SOBCURR_SECD_ROLL_IND). If it was not established on SOACURR, the system used 

the default setting on SOACTRL. 

The Roll Indicator was and is only applicable to the Learner Module. This specified 

if a curriculum record was to be rolled to Academic History (Outcome). However, 

since it was a not NULL field, the values were set for Recruiting, Admissions, and 

Outcome. Since the default was Y, it was possible to have curricula in the Recruiting, 

Admissions, and Outcome modules with the indicator set to Y. This led to confusion 

when viewing the curriculum records on SOILCUR and seeing a record for a 

module of RECRUIT with a Roll Indicator set to Y. 

Since the Create Learner Outcome field was part of the Curriculum block, a user 

could not simply update it. The user had the ability to change the default value of 

this indicator on SFAREGS and SGASTDN in the following instances: 

• when inserting a new curriculum record. 

• when using the Duplicate Record function. The value of the duplicated record 

was populated in the roll to the Create Learner Outcome field of the new 

record, but the user could change it. 

• when using the Change Curriculum button. 

New Field Design and New Field Value 

To modify this situation, a third value of D (Default) has been created for the 

SORLCUR_ROLL_IND on SORLCUR, and the Create Learner Outcome checkbox has 

been renamed and redesigned. This field is now called Roll Learner and is a radio 

group. The choices are Yes, No, or Default. The default setting for this field is Default. 

• Select Yes to roll the learner record to academic history (outcome). 

• Select No to not roll the learner record. 

• Select Default for non-learner modules so that curriculum rules are used from 

SOACURR and SOACTRL. 

Calls to the curriculum API (sb_curriculum.p_create) for non-learner module 

forms and processes have been modified to set the SORLCUR_ROLL_IND to D (set 

p_roll_ind = D) when a curriculum record is created. You can change the setting 

of the Roll Indicator from D to a Y or N, using Roll Learner field on SGASTDN and 

SFAREGS. 





SAAQUIK and the admissions decision process that creates a learner curriculum in 

SAKMODS set the Roll Indicator to D so the values from SOACURR or SOACTRL 

are used. The BWSKXMIS process in self-service copies the value from the previous 

sequence of the curriculum. 

That way, it can be determined if the user checked Y or N accurately. The D tells the 

system to use the value from SOACURR or SOACTRL. If the user checks Y or N, the 

user is overriding the default. The API then determines if the module is LEARNER 

or not and sets the value of the Roll Indicator on SORLCUR appropriately. 

The following forms and packages/routines have had changes made to their 

curriculum API calls to facilitate this field change: 

• SRAQUIK 

• SRARECR 

• SAAQUIK (creation of application and recruit records) 

• SAAADMS 

• SHADEGR 

• SAKLMOD 

• SHKROLS (history roll, creation of the outcome curriculum from the learner) 

• SAKL010 (creation of application for electronic applicant) 

• SAKMODS (creation of application or recruit records) 

All inserts of new curricula will set the value of the SORLCUR_ROLL_IND field to D. 

The API determines the final value for the field based upon learner module 

(STVLMOD) and the settings on SOACURR and SOACTRL. It is important to note 

that D is only used as an initial value. No records will be written to the database with 

a value of D in the SORLCUR_ROLL_IND field. All modules other than Learner 

(General Student) will be set to N. 

Determining Which Curriculum Rows are Current 

This modified processing satisfies problem resolution #100823. 

SORLCUR and SORLFOS both contain Current Indicator fields which are used to 

determine which curriculum and field of study rows are the most recent or current 

for a priority. The CURRENT_IND and ACTIVE_IND columns in the The SOVLCUR 

and SOVLFOS views contain fields that tell which curriculum and field of study rows 

are current and active. 

• The value in the CURRENT_IND field is calculated for values of Y and N. 

• The value in the ACTIVE_IND field is derived from the curriculum status rules 

defined on SORCACT and is based on the values in the SORLCUR_CACT_CODE 

and SORLFOS_CACT_CODE fields. 





The following section describes how current and active concurrent curriculum rows 

are selected by learner module. Recruiting, Admissions, and Academic History 

(Outcome) use the same processing. General Student (Learner) has some extra 

processing to discuss. 

Recruiting 

1. For Recruiting, select the recruit record from SRBRECR. 

2. Then select the current and active base recruiting concurrent curriculum rows 

where the recruit term and key sequence number match those on SOVLCUR, 

and where the SOVLCUR_CURRENT_IND is Y and the SOVLCUR_ACTIVE_IND is Y. 

3. Then select all current and active field of study rows for the base curriculum 

where the SOVLFOS_CURRENT_IND is Y and the SOVLFOS_ACTIVE_IND is Y. 

Admissions 

1. For Admissions, select the application record from SARADAP. 

2. Then select the current and active base admissions concurrent curriculum 

rows where the application term and application number match the 

SOVLCUR term and key sequence number and where the 

SOVLCUR_CURRENT_IND is Y and the SOVLCUR_ACTIVE_IND is Y. 



Academic History (Outcome) 

1. For Academic History (Outcome), select the degree record from SHRDGMR. 

2. Then select the current and active base history concurrent curriculum rows 

where the degree sequence number matches the SOVLCUR key sequence 

number and where the SOVLCUR_CURRENT_IND is Y and the 

SOVLCUR_ACTIVE_IND is Y. 



General Student (Learner) 

For General Student (Learner), the process is much more complex due to the use 

of effective term processing. Concurrent curricula processing was not considering 

effective term usage when determining the most current row on SORLCUR. 

Effective term will now be used to determine the curriculum status for a term. 





When a student had an existing general student record and another general student 

record was created for a prior term, the effective term was not included in the 

process to prioritize the learner curriculum records. For example, when a student 

enrolled in the fall semester, and a general student record was created for term 

200510 with the following curriculum, the record would look like the following. 

Curriculum 

Type 

Curriculum Name Priority Terms Activity field Current 

Curriculum BS in Physics 1 200510 - 99999 ACTIVE Y 

Major Vector Physics 1 ACTIVE Y 

However, if the student then decided to take courses over a summer semester, a 

general student record would be created for the prior term of 200440. The 

curriculum record for that term would appear as follows. 

Curriculum 

Type 

Curriculum Name Priority Terms Activity field Current 

Curriculum BS in Chemistry 1 200440 - 200510 ACTIVE Y 

Major Bio-Chemistry 1 ACTIVE Y 

Since the curriculum process did not look at the effective term, the curriculum 

record for 200510 would appear as follows. 

Curriculum 

Type 

Curriculum Name Priority Activity field Current 

Curriculum BS in Chemistry 1 ACTIVE Y 

Major Bio-Chemistry 1 ACTIVE Y 

Curriculum BS in Physics 1 ACTIVE N 

Major Vector Physics 1 ACTIVE N 

The 200510 curriculum is no longer current, since the curriculum that was entered 

last (200440) has the same priority number and a higher sequence number. So 

looking at the student's record for 200510 would show that the BS in Chemistry is 

the primary curriculum. 

In Release 7.0, Learner module processing looked at all curriculum records with 

term codes that were less than the SGBSTDN end term. Now, the processing 

evaluates the curriculum records with terms that fall between the effective term and 

end term to determine which rows are current. 





In other curriculum module records, whether a row is current or non-current is 

static, (unless a new row is inserted). The status does not vary based on the term 

code or sequence number of the record you are reviewing. For example, an 

Admissions SORLCUR row is current for a 200510 application. If a second 

application is created for the student, it does not impact the status of the initial 

application. The two applications are exclusive and have their own current rows. 

Learner (general student) records are not tied to key sequence numbers. 

Therefore, a Learner row on SORLCUR can be current for one term and noncurrent 

for another, or primary for one term and secondary for another. For 

example, a Learner record is created for term 200510 with an end term of 999999 

and a priority one curriculum. The student registers for a summer course in term 

200440 with a different priority one curriculum, thereby creating a second learner 

record for effective term 200440 with an end term of 200510. If you consider the 

learner record for term 200440 in processing, the curriculum entered for that term 

is primary and current. However, if you consider the term 200510 in processing, the 

curriculum entered in 200440 is now non-current, since the 200510 record has the 

same priority. 

It is important to note that the SORLCUR row for the term code of 200440 is not 

inactivated by the end date of the associated SGBSTDN record. It is still an active 

curriculum record for the term of 200510. If the SORLCUR row entered for 200440 

was a higher priority than the one entered in 200510, the 200440 row on SORLCUR 

would be the primary term of 200510. 

To summarize: 

• All curriculum records with a term that is less than the SGBSTDN end term are 

grouped by priority. 

• For each priority, find the maximum term that is less than the end term of the 

SGBSTDN record. 

• Determine if the curriculum record of the maximum term is active. If it is 

active, then it is current for the SGBSTDN record. 

Current and active concurrent curricula rows are selected by learner module as 

follows: 

1. For General Student, select the learner record from SGBSTDN. 

2. The system inserts the record into the SOTVCUR temporary table for the 

learner current calculation. 

This step is only necessary if you want to select active concurrent curriculum 

records based on a specific SGBSTDN effective term. The process used to 

determine the current indicator uses the highest SGBSTDN effective term if 

this step is not performed. 

Note: If the SOTVCUR record is not created, the Current Indicator setting is 

going to be based on the highest SGBSTDN effective term. 





The Current Indicator setting is based on the key column values for the 

module record. In the case of the general student record, there is no 

base except the effective term. The calculation of the Current Indicator 

for the learner curriculum is based on the highest SORLCUR sequence 

number for the lowest SGBSTDN effective term, or the highest 

curriculum term for a given priority that is less then the SGBSTDN end 

term. The term added to SOTVCUR defines the SGBSTDN effective 

term being processed, the default term being the highest SGBSTDN 

term. 

3. Then select the current and active base concurrent curriculum rows by term 

and sequence number from SOVLCUR, where the SOVLCUR_CURRENT_IND is Y 

and the SOVLCUR_ACTIVE_IND is Y. 



The curriculum prioritizing process looks at the effective term for a curriculum 

record when the Learner Module is set to LEARNER, to determine what the highest 

priority curriculum is for an effective term. Therefore, the sb_curriculum API 

determines if the Learner Module is set to LEARNER. If yes, the process determines 

the effective term for the curriculum. Within that effective term, the process takes 

the highest sequence number of the lowest priority and sets it as "primary" for the 

effective term. This means that a learner can have multiple primary curriculum 

records, depending on the effective term. 

The Curriculum blocks on SGASTDN and SFAREGS display all curriculum records 

where the term (SORLCUR_TERM_CODE) is less than the end term of the SGBSTDN 

record. For example, 

Curriculum 

SORLCUR 

Term 

Priority Sequence Effective Term End Term 

BA-Math 200510 1 1 200510 999999 

BS-Biology 200440 1 2 200440 200510 

In the above case, the curriculum record for the earlier term was entered last, so it 

has a higher sequence number. If term 200440 was entered in the Key Block of 

SGASTDN, you would only see the BS-Biology curriculum, since the BA-Math 

effective term is not less than the end term. 

If term 200510 was entered in the Key Block, curriculum BA-Math would display as 

primary and current, and BS-Biology would displays as n on-current. The processing 

would determine that there were multiple active priority one curriculum records for 

this term. However, instead of selecting the one with the highest sequence number 

(as in other SOBLMOD rows), the curriculum with the greatest 

SORLCUR_TERM_CODE value is selected. 





Modifying the Curriculum and Field of Study Sort Order 

Records had been sorted in priority order instead of in current order. The sort order 

for records has been modified on SRAQUIK, SRARECR, SAAQUIK, SAAADMS, 

SGASTDN, SFAREGS, and SHADEGR. This satisfies problem resolution #102295. 

All current rows are now displayed before non-current rows. With field of study rows, 

the sort hierarchy has been changed to: current, major, active and current, priority 

(in ascending order), inactive or non-current, sequence number (in descending 

order). The same is true for current minor, current concentration, and current userdefined 

rows, which follow in that order. Non- current rows are displayed after 

current rows in the same order. Curriculum rows are sorted by term code, key 

sequence number, active and current, priority number, inactive or non-current, 

and then curriculum sequence (in descending order). 

For example, if a student had the following SORLFOS rows: 

SORLFOS Type Current Active Priority 

Math Major Y Y 2 

Environmental 

Studies 

Major Y N 1 

Physics Major N Y 1 

Vector Analysis Concentration Y Y 1 

Fusion 

Techniques 

Concentration Y Y 2 

Space Travel Minor N Y 1 

Mechanics Vocation Y Y 1 

The sort order would display as follows: 

# SORLFOS Type Current Active Priority 

1 Math Major Y Y 2 

2 Environmental 

Studies 

Major Y N 1 

3 Vector Analysis Concentration Y Y 1 

4 Fusion 

Techniques 

Concentration Y Y 2 




Changed Forms 

# SORLFOS Type Current Active Priority 

5 Mechanics Vocation Y Y 1 

6 Physics Major N Y 1 

7 Space Travel Minor N Y 1 

The sort order on SOILCUR separates curricula records by learner module 

(STVLMOD). Therefore, the highest sort criteria is by learner module, instead of by 

current record. The sort order is: Recruit, Admissions, Learner, Outcome, and then 

any user-defined modules in alpha, ascending order. 

Changed Forms 

Curriculum Status Validation Form (STVCSTS) 

The new value of OVERLOAD has been added to this form for use with processing 

maximum curriculum records on SOBLMOD and rolling the records to the General 

Student module. 

The sinvcsts1.sql script is delivered to make this change. 

Quick Recruit Form (SRAQUIK) 

The call to the curriculum API has been modified to work with the changes made to 

the Roll Learner radio group. 

Recruit Prospect Information Form (SRARECR) 



The form has been modified to use the new f_lcur_count_status and 

f_lfos_count_status functions. 

Quick Entry Form (SAAQUIK) 






Changed Forms 

Admissions Application Form (SAAADMS) 



The form has been modified to use the new f_lcur_count_status and 

f_lfos_count_status functions. 

General Student Form (SGASTDN) 

The Create Learner Outcome checkbox has been renamed and redesigned. This 

field is now called Roll Learner and is a radio group. The choices are Yes, No, or 

Default. 





The default setting for this field is Default. 

The stored term code used in concurrent curricula processing is now the effective 

term code. It is stored on SOTVCUR and inserted using the 

soklcur.p_create_sotvcur package.procedure. 

Student Course Registration Form (SFAREGS) 



Default. 





The default setting for this field is Default. 

Degrees and Other Formal Awards Form (SHADEGR) 


the Roll Leaner radio group. 




New Reports and Processes 

Learner Curriculum Query Form (SOILCUR) 

This modification satisfies problem resolution #100822. 



Default. 





The default setting for this field is Default. The values stored in the database are Y, 

N, and D. 

This modification satisfies problem resolution #102295. 

The sort order on SOILCUR has been modified. The sort order separates curricula 

records by learner module (STVLMOD). Therefore, the highest sort criteria is by 

learner module, instead of by current record. The sort order is: Recruit, Admissions, 

Learner, Outcome, and then any user-defined modules in alpha, ascending order. 

Admissions Decision and Rating Batch Entry Form (SAADCBT) 



Admissions Decision Form (SAADCRV) 




Learner Curriculum Purge Process (SOPLCPG) 

This new process satisfies RPE #44157. 





The new Learner Curriculum Purge Process (SOPLCPG) is used to purge 

SORLCUR rows and/or SORLFOS rows for Admissions and Recruiting records. 

This process calls the sb_curriculum.p_delete API which in turn calls the 

sb_fieldofstudy.p_delete API to delete all selected curriculum and fields of 

study records. 

Since users may not want to maintain inactive and non-current curriculum records 

on a student, they can use SOPLCPG to purge inactive and non-current student 

curricula. This process deletes an SORLCUR row and its associated SORLFOS 

row(s). However, this process is restricted to only purging the curriculum records 

that are part of Recruiting and Admissions. The Learner (General Student) and 

Outcome (Academic History) curriculum records are not considered by this 

process. 

• Inactive curriculum rows are defined as rows where the Activity field has a type 

of INACTIVE (SORLCUR_CACT_CODE). Whether an activity code is inactive is 

determined on SORCACT. Any code established on SORCACT that does not 

have the SOBCACT_ACTIVE_IND set to Y is deemed to be inactive. 

• Non-current curriculum rows are defined as rows that have a value of N in the 

Current field in the Curriculum or Field of Study blocks. The value that 

populates the field is located in the SOVLCUR_CURRENT_IND and 

SOVLFOS_CURRENT_IND view fields. 

The SOPLCPG process ensures that if a curriculum record (SORLCUR) is removed, 

all related field of study rows (SORLFOS) are also removed. This process only 

purges curriculum rows that are inactive and non-current. Field of study rows are 

only purged in association with their respective curriculum record. Therefore, if a 

curriculum record is current and has an associated SORLFOS row that is noncurrent 

and inactive, the SORLFOS row will not be purged. 

The following parameters are used with this process. 

• Learner Module - Optional, Enter the student learner module code for the purge 

process. Valid values come from STVLMOD. 

The only valid values for this parameter are ADMISSIONS and RECRUIT. If this 

parameter is left blank, all curriculum (SORLCUR) and field of study 

(SORLFOS) records for Admissions and Recruiting are examined for the 

population selection and/or individual IDs (SPRIDEN). 

• Term Code - Optional, Enter the term code for which records are to be purged 

or leave blank for all terms. Valid values from STVTERM. 

If this parameter is left blank, the report will use the highest SGBSTDN record 

for the Learner module to determine which curriculum record is current. 

• Learner ID - Optional, Enter the ID or IDs for the student(s) to be processed. 

• Application Code - Optional, Enter the application code for the population 

selection. 

• Selection Identifier - Optional, Enter the selection ID for the population 

selection. 





• Creator ID - Optional, Enter the creator ID for the population selection. 

• User ID - Optional, Enter the user ID for the population selection. 

• Run Mode - Required, Enter A to run in Audit Mode or U to run in Update 

Mode. The default is A. 

• Report Type - Required, Enter D to print a detail report or S to print a summary 

report. The default is D. The detail report lists each ID and the associated 

curriculum detail. 

The output report includes control totals (number of records read and number of 

records deleted) and lists the parameters. 

This process can be run for an ID or a population selection, by term and/or learner 

module, and can be run in update or audit mode. 

Please refer to the landscaped section that follows for parameter detail and report 

output sample information. 

Non-Destructive Curric Update Report (SORLCHG) 

This new process satisfies RPE #44156. 

This report is used to show non-destructive updates made to curriculum and/or 

field of study records. A non-destructive update is used in the curriculum rows to 

maintain a history of all changes to a learner's curriculum, as no updates are allowed 

to existing curriculum and field of study records. The process used to update 

existing curriculum information is to duplicate the existing record, and then update 

the newly created record with the appropriate changes (i.e., to inactivate the record 

and indicate why it was inactivated). This report may be used to track changes made 

in curriculum, attempt to establish trends, and determine curriculum retention. 

Note: Users are allowed to delete curriculum and field of study records. 

Deleted records are not considered non-destructive and will not be 

displayed on the report. 

The system will determine if a record has a non-destructive update using the 

following criteria: 

• If a row is non-current, the SOVLCUR_CURRENT_IND and/or the 

SOVLFOS_CURRENT_IND fields are set to N. 

or 

• If a row has a curriculum activity status of type INACTIVE (the 

SOBCACT_ACTIVE_IND is set to N). 

Note: A row can be inactive and still be current. Conversely, a row can be noncurrent 

and still be active. 

The report can be run against both SORLCUR and SORLFOS, SORLCUR only, or 

SORLFOS only. 






• Records are sorted by last name, first name, middle name, and Banner ID (in 

ascending order). 

• Within each returned ID, the curriculum non-destructive updates are sorted by 

module (Recruiting, Admissions, Learner, Outcome), term code (in 

descending order), key sequence number (in ascending order), and then by 

curriculum sequence number (in descending order). 

• The SORLFOS rows are sorted by type (major first, minor second, 

concentration third), priority (in ascending order), and sequence number (in 

descending order). 

The following parameters are used with this report. 

• Learner ID - Optional, Enter the ID or IDs for the student(s) to be processed, or 

enter % for all. 

• Application Code - Optional, Enter the application code for the population 

selection. 

• Selection Identifier - Optional, Enter the selection ID for the population 

selection. 

• Creator ID - Optional, Enter the creator ID for the population selection. 

• User ID - Optional, Enter the user ID for the population selection. 

• Learner Module - Optional, Enter the student learner module code for which 

non-destructive updates should be retrieved. Valid values come from 

STVLMOD. 

• Term Code - Optional, Enter the term code for which records are to be selected 

or leave blank for all terms. You cannot enter multiple term codes. Valid values 

from STVTERM. 

• If this parameter is left blank, the report will use the highest SGBSTDN 

record for the Learner module to determine which curriculum record is 

current. 

• This parameter retrieves records with non-destructive updates for that 

term. It does not retrieve non-current records from SORLCUR and 

SORLFOS that match the entered term code. 

• Start Date - Optional, Enter the earliest date for which non-destructive updates 

should be retrieved. If this parameter is left blank, all dates are included. 

• End Date - Optional, Enter the latest date for which non-destructive updates 

should be retrieved. If this parameter is left blank, all dates are included. 

• CSTS Code - Optional, Enter the curriculum status to be used in searching for 

non-destructive updates. Valid values come from the Curriculum Status 

Validation Form (STVCSTS). This parameter only applies to field of study 

rows. 




Changed Reports and Processes 

This parameter should only be used with a Report Type parameter setting of F. 

The Report Type parameter setting of A displays curriculum and field of study 

non-destructive updates. The curriculum non-destructive updates are not 

selected based on the value in the CSTS Code parameter. 

• CACT Code - Optional, Enter the curriculum activity status to be used in 

searching for non-destructive updates. Valid values come from the Curriculum 

Activity Status Validation Form (STVCACT). 

• Report Type - Required, Enter A to run the search against SORLCUR and 

SORLFOS, L to run the search against SORLCUR only, or F to run the search 

against SORLFOS only. The default is A. 

This report can be run for an ID, all IDs, or a population selection, by term and/or 

learner module, by start and end dates, by curriculum status and/or curriculum 

activity status, and by searches on SORLCUR, SORLFOS or both. 

Please refer to the landscaped section that follows for parameter detail and report 

output sample information. 


Learner Curriculum Conversion Process (SOPLCCV) 

This modified process satisfies RPE #46150. 

The following changes were made to SOPLCCV: 

• The Learner ID parameter has been modified. You can now enter an ID 

number or enter % to select all SPRIDEN IDs where a recruiting, admissions, 

learner, or outcome record exists. If you enter a module in the Student Learner 

Module parameter, the process will check for records only in that module. 

• Records are now saved after every 1,000 entries instead of after each 

conversion. 

• Report totals have been corrected. 

Admit Decision Calc Report (SARBDSN) 

This report was changed to use the default value of D for the learner curriculum Roll 

Learner radio group. 




Report Samples 

Student Type Update Report (SHRTYPE) 

This report was changed to send the general learner effective term to the 

soklcur.p_create_sotvcur procedure. The API call to 

sb_curriculum.p_create was changed to send NULL values to the academic 

standing effective term and code. 

Degree Status Update Report (SHRDEGS) 

This report was changed to send the general learner effective term to the 

soklcur.p_create_sotvcur procedure. The API call to 

sb_curriculum.p_create was changed to send NULL values to the academic 

standing effective term and code. 



Please see the following landscaped section for report parameters and sample 

output. 



output. 








Section 1 - Concurrent Curricula Phase 2 

Sample Reports 


Description 

This process is used to purge SORLCUR rows and/or SORLFOS rows for Admissions and Recruiting records. This process 

calls the sb_curriculum.p_delete API which in turn calls the sb_fieldofstudy.p_delete API to delete all selected 

curriculum and fields of study records. This process is run for an ID or a population selection, by term and/or learner module, 

and can be run in update or audit mode. 

Since users may not want to maintain inactive and non-current curriculum records on a student, they can use SOPLCPG to 

purge inactive and non-current student curricula. This process deletes an SORLCUR row and its associated SORLFOS row(s). 

However, this process is restricted to only purging the curriculum records that are part of Recruiting and Admissions. The 

Learner (General Student) and Outcome (Academic History) curriculum records are not considered by this process. 

• Inactive curriculum rows are defined as rows where the Activity field has of a type of INACTIVE (SORLCUR_CACT_CODE). 

Whether an activity code is inactive is determined on SORCACT. Any code established on SORCACT that does not have 

the SOBCACT_ACTIVE_IND set to Y is deemed to be inactive. 

• Non-current curriculum rows are defined as rows that have a value of N in the Current field in the Curriculum or Field 

of Study blocks. The value that populates the field is located in the SOVLCUR_CURRENT_IND and SOVLFOS_CURRENT_IND 

view fields. 

The SOPLCPG process ensures that if a curriculum record (SORLCUR) is removed, all related field of study rows (SORLFOS) 

are also removed. This process only purges curriculum rows that are inactive and non-current. Field of study rows are only 

purged in association with their respective curriculum record. Therefore, if a curriculum record is current and has an 

associated SORLFOS row that is non-current and inactive, the SORLFOS row will not be purged. 

The output report includes control totals (number of records read and number of records deleted) and lists the parameters. 





Parameters Name Required Description Values 

Learner Module No Enter the student learner module code for the 

conversion process. 

Learner Module Validation Form 

(STVLMOD) 

The only valid values for this parameter are 

ADMISSIONS and RECRUIT. If this parameter is left 

blank, all curriculum (SORLCUR) and field of study 

(SORLFOS) records for Admissions and Recruiting 

are examined for the population selection and/or 

individual IDs (SPRIDEN). 

Term No Enter the term code for which records are to be 

processed. 

Term Code Validation Form 

(STVTERM) 

If this parameter is left blank, the report will use the 

highest SGBSTDN record for the Learner module to 

determine which curriculum record is current. 

Learner ID No Enter the ID or IDs for the student(s) to be 

processed. 





Parameters (cont.) Name Required Description Values 

Application Code No Enter the code that identifies the general area for 

which the selection identifier was defined. All or 

none of the population selection parameters must be 

entered. 

Application Inquiry Form (GLIAPPL) 

The Population Selection Extract Inquiry Form 

(GLIEXTR) may be used to review the people who 

will be processed in the load from the selection 

identifier and application code entered. 

Selection Identifier No Enter the code that identifies the population with 

which you wish to work. The selection identifier 

must be defined on the Population Selection 

Definition Rules Form (GLRSLCT). All or none of 

the population selection parameters must be 

entered. 

Population Selection Inquiry Form 

(GLISLCT) 

Creator ID No Enter the user ID of the person who created the 

population rules. All or none of the population 

selection parameters must be entered. 

User ID No Enter the user ID for the population selection. This 

is the ID of the user who selected the population of 

people. This may or may not be the same as the 

Creator ID. All or none of the population selection 

parameters must be entered. 






Run Mode Yes Enter A to run in Audit Mode or U to run in Update 

Mode and update the database records. The default 

is A. 

A 

U 

Audit mode 

Update mode 

Report Type Yes Enter D to print a detail report or S to print a 

summary report. The default is D. The detail report 

lists each ID and the associated curriculum detail. 

D 

S 

Detail report 

Summary report 

Report Sample—Learner Curriculum Purge Process (SOPLCPG) — see the following pages 





PAGE 1 

SOPLCPG 7.1 BANNER System Test RUN DATE 05-MAY-2005 

Curriculum Purge Process RUN TIME 12:13 PM 

LEVEL / COLL / 

NAME / DEGREE / PROGRAM / CAMP CACT / 

ID MODULE TERM LFOS TYPE DEPT CSTS SEQ PRI USER ID DATE 

_________ ___________________ ____ _____ ______________ ____ ___________ ___ ___ ___________ ___________ 

180600005 Heaton, Randy 

ADMISSIONS 200510 UG/BA BA-ECON AD/ INACTIVE 9 3 SYSTEST22 05-MAY-2005 

ECON MAJOR INPROGRESS 1 1 SYSTEST22 05-MAY-2005 

FIN MINOR INPROGRESS 2 1 SYSTEST22 05-MAY-2005 

180600035 Howe, Melissa 

ADMISSIONS 200510 UG/BBA BBA-ACCT BU/ INACTIVE 4 2 SYSTEST22 05-MAY-2005 

ACCT MAJOR INPROGRESS 1 1 SYSTEST22 05-MAY-2005 

BUSI MINOR INPROGRESS 2 2 SYSTEST22 05-MAY-2005 

RECRUIT 200510 UG/BS BS-MARKETING BU/M INACTIVE 6 2 SYSTEST22 05-MAY-2005 

BHS MAJOR INPROGRESS 1 1 SYSTEST22 05-MAY-2005 

180600001 Law, Paula 

RECRUIT 200510 UG/BA BA-ENGLISH AS/ INACTIVE 3 3 SYSTEST22 18-APR-2005 

ENGL MAJOR ENGL INPROGRESS 1 1 SYSTEST22 18-APR-2005 

ART VOCATION INPROGRESS 2 1 SYSTEST22 18-APR-2005 

180600000 Neesan, Marissa 

ADMISSIONS 200510 UG/BA BA-ENGLISH AS/ INACTIVE 6 2 SYSTEST22 18-APR-2005 

ENGL MAJOR ENGL INPROGRESS 1 1 SYSTEST22 18-APR-2005 

RECRUIT 200410 UG/BA BA-ECON AD/ INACTIVE 11 2 SYSTEST22 18-APR-2005 

ECON MAJOR INPROGRESS 1 1 SYSTEST22 18-APR-2005 

RECRUIT 200510 UG/BA BA-ENGLISH AS/ INACTIVE 3 2 SYSTEST22 18-APR-2005 

ENGL MAJOR ENGL CHANGED 1 1 SYSTEST22 18-APR-2005 

SOC MAJOR CHANGED 2 2 SYSTEST22 18-APR-2005 





PAGE 2 

SOPLCPG 7.1 BANNER System Test RUN DATE 05-MAY-2005 

Curriculum Purge Process RUN TIME 12:13 PM 

* * * REPORT CONTROL INFORMATION * * * 

Parameters were entered via Job Submission. 

Parameter Name Value 

_____________________________ ________________ 

Parameter Seq No: 17833 

Number Learners Selected: 4 

Number Curriculum Deleted: 7 

Number Field of Study Deleted: 11 

Module: 

Term Code: 

ID: 

Application Code: MAG 

Selection Identifier: MICHAEL_CC_POP 

Creator ID: SYSTEST22 

User Id: SYSTEST22 

Run Mode (Audit or Update): A 

Detail Report: D 






Description 

This report is used to show non-destructive updates made to curriculum and/or field of study records. This report is run for 

an ID, all IDs, or a population selection, by term and/or learner module, by start and end dates, by curriculum status and/or 

curriculum activity status, and by searches on SORLCUR, SORLFOS or both. 

A non-destructive update is used in the curriculum rows to maintain a history of all changes to a learner's curriculum, as no 

updates are allowed to existing curriculum and field of study records. The process used to update existing curriculum 

information is to duplicate the existing record, and then update the newly created record with the appropriate changes (i.e., 

to inactivate the record and indicate why it was inactivated). This report may be used to track changes made in curriculum, 

attempt to establish trends, and determine curriculum retention. The process selects SORLFOS rows independently of the 

associated SORLCUR rows. 

Note: Users are allowed to delete curriculum and field of study records. Deleted records are not considered nondestructive 

and will not be displayed on the report. 

The system will determine if a record has a non-destructive update using the following criteria: 

• If a row is non-current, the SOVLCUR_CURRENT_IND and/or the SOVLFOS_CURRENT_IND fields are set to N. 

or 

• If a row has a curriculum activity status of type INACTIVE (the SOBCACT_ACTIVE_IND is set to N). 

Note: A row can be inactive and still be current. Conversely, a row can be non-current and still be active. 


• Records are sorted by last name, first name, middle name, and Banner ID (in ascending order). 





• Within each returned ID, the curriculum non-destructive updates are sorted by module (Recruiting, Admissions, Learner, 

Outcome), term code (in descending order), key sequence number (in ascending order), and then by curriculum 

sequence number (in descending order). 

• The SORLFOS rows are sorted by type (major first, minor second, concentration third, user-defined SORLFOS types 

fourth (in alpha ascending order)), priority (in ascending order), and sequence number (in descending order). 


Learner ID No Enter the ID or IDs for the student(s) to be 

processed, or enter % for all. 




entered. 











entered. 


(GLISLCT) 














Learner Module No Enter the student learner module code for the 

conversion process. 

Term Code No Enter the term code for which records are to be 

processed. You cannot enter multiple term codes. 

Learner Module Validation Form 

(STVLMOD) 


(STVTERM) 

If this parameter is left blank, the report will use the 

highest SGBSTDN record for the Learner module to 

determine which curriculum record is current. 

This parameter retrieves records with nondestructive 

updates for that term. It does not retrieve 

non-current records from SORLCUR and SORLFOS 

that match the entered term code. 

Start Date No Enter the earliest date for which non-destructive 

updates should be retrieved. If this parameter is left 

blank, all dates are included. 






End Date No Enter the latest date for which non-destructive 

updates should be retrieved. If this parameter is left 

blank, all dates are included 

CSTS Code No Enter the curriculum status to be used in searching 

for non-destructive updates. This parameter only 

applies to field of study rows. 

Curriculum Status Validation Form 

(STVCSTS) 

This parameter should only be used with a Report 

Type parameter setting of F. The Report Type 

parameter setting of A displays curriculum and field 

of study non-destructive updates. The curriculum 

non-destructive updates are not selected based on 

the value in the CSTS Code parameter. 

CACT Code No Enter the curriculum activity status to be used in 

searching for non-destructive updates. 

Curriculum Activity Status Validation 

Form (STVCACT) 

Report Type Yes Enter A to run the search against SORLCUR and 

SORLFOS, L to run the search against SORLCUR 

only, or F to run the search against SORLFOS only. 

The default is A. 

A 

L 

F 

SORLCUR and SORLFOS 

SORLCUR only 

SORLFOS only 

Report Sample—Non-Destructive Curric Update Report (SORLCHG) — see the following pages 





PAGE 1 

SORLCHG 7.1 BANNER System Test RUN DATE 05-MAY-2005 

Non-Destructive Curric Updates RUN TIME 11:56 AM 

COLL / C A 

NAME / LEVEL / PROGRAM / CAMP CACT / U C 

ID MODULE TERM DEGREE FIELD OF STUDY DEPT CSTS SEQ PRI R T USER ID DATE 

__ ______ ____ _____ ______________ ____ ____ ___ ___ _ _ _______ ____ 

180600010 Barr, Steven 

RECRUIT 200510 UG/BS VAT M/M ACTIVE 1 1 Y Y SYSTEST22 19-APR-2005 

ACCT - MAJ APPLIED 3 1 Y Y SYSTEST22 19-APR-2005 

ACCT - MAJ INPROGRESS 1 1 N Y SYSTEST22 19-APR-2005 

ECON - MAJ APPLIED 4 2 Y Y SYSTEST22 19-APR-2005 

ECON - MAJ INPROGRESS 2 2 N Y SYSTEST22 19-APR-2005 

ADMISSIONS 200510 UG/BS VAT M/M ACTIVE 3 1 Y Y SYSTEST22 19-APR-2005 

ACCT - MAJ APPACCEPT 3 1 Y Y SYSTEST22 19-APR-2005 


ECON - MAJ OVERLOAD 2 2 Y N SYSTEST22 19-APR-2005 

ADMISSIONS 200510 UG/BS SMED AS/ ACTIVE 4 2 Y Y SYSTEST22 19-APR-2005 

ATHL - MAJ APPACCEPT 3 1 Y Y SYSTEST22 19-APR-2005 

ATHL - MAJ INPROGRESS 1 1 N Y SYSTEST22 19-APR-2005 

RETR - MAJ APPACCEPT 4 2 Y Y SYSTEST22 19-APR-2005 

RETR - MAJ INPROGRESS 2 2 N Y SYSTEST22 19-APR-2005 

LEARNER 200510 UG/BA BA-ECON AD/ ACTIVE 7 2 Y Y SYSTEST22 22-APR-2005 

ECON - MAJ INPROGRESS 1 1 Y Y SYSTEST22 22-APR-2005 

LEARNER (OLD) 200510 UG/BS SMED AS/ INACTIVE 6 2 N N SYSTEST22 19-APR-2005 

ATHL - MAJ INPROGRESS 1 1 N N SYSTEST22 19-APR-2005 

RETR - MAJ INPROGRESS 2 2 N N SYSTEST22 19-APR-2005 

180600009 Bigelow, Lynn 

LEARNER 200510 UG/BS SMED AS/ ACTIVE 6 2 Y Y SYSTEST22 22-APR-2005 

ATHL - MAJ INPROGRESS 1 3 Y Y SYSTEST22 22-APR-2005 

LEARNER (OLD) 200510 UG/BS VAT M/M ACTIVE 3 2 N Y SYSTEST22 19-APR-2005 


OUTCOME 200510 UG/BS VAT M/M INACTIVE 5 2 Y N SYSTEST22 19-APR-2005 

ECON - MAJ SOUGHT 1 1 Y Y SYSTEST22 19-APR-2005 

180600020 Bird, Richard 

LEARNER 200520 UG/BS BS-MARKETING BU/M ACTIVE 4 1 Y Y SYSTEST22 22-APR-2005 

BHS - MAJ INPROGRESS 1 1 Y Y SYSTEST22 22-APR-2005 

LEARNER (OLD) 200510 UG/BS BS-MARKETING BU/M ACTIVE 1 1 N Y SYSTEST22 22-APR-2005 

BHS - MAJ INPROGRESS 1 1 N Y SYSTEST22 22-APR-2005 

180600030 DeCerio, Michele 

ADMISSIONS 200610 UG/BA BS-MAG AS/M ACTIVE 6 1 Y Y SYSTEST22 29-APR-2005 

CHLD - MAJ INPROGRESS 1 1 Y Y SYSTEST22 29-APR-2005 

FIN - MAJ APPLIED 2 2 Y N SYSTEST22 02-MAY-2005 

LEARNER 200610 UG/BA BS-MAG AS/M ACTIVE 5 1 Y Y SYSTEST22 29-APR-2005 


LEARNER (OLD) 200520 UG/BS SMED AS/ ACTIVE 3 1 N Y SYSTEST22 29-APR-2005 





PAGE 2 



COLL / C A 



__ ______ ____ _____ ______________ ____ ____ ___ ___ _ _ _______ ____ 

180600030 DeCerio, Michele 

LEARNER (OLD) 200520 UG/BS SMED AS/ ACTIVE 3 1 N Y SYSTEST22 29-APR-2005 




180600011 DiGiovanni, Carol 


FIN - MAJ APPACCEPT 2 1 Y Y SYSTEST22 21-APR-2005 

FIN - MAJ INPROGRESS 1 1 N Y SYSTEST22 21-APR-2005 

ADMISSIONS 200510 UG/BA BS-MAG AS/M ACTIVE 2 2 Y Y SYSTEST22 21-APR-2005 

CHLD - MAJ APPACCEPT 4 1 Y Y SYSTEST22 21-APR-2005 

CHLD - MAJ INPROGRESS 1 1 N Y SYSTEST22 21-APR-2005 

DISC - MIN APPACCEPT 5 2 Y Y SYSTEST22 21-APR-2005 

DISC - MIN INPROGRESS 2 2 N Y SYSTEST22 21-APR-2005 

PERC - CON APPACCEPT 6 2 Y Y SYSTEST22 21-APR-2005 

PERC - CON INPROGRESS 3 2 N Y SYSTEST22 21-APR-2005 

LEARNER 200510 UG/BA BA-LOGIC AS/M ACTIVE 5 2 Y Y SYSTEST22 22-APR-2005 

ART - MAJ INPROGRESS 1 1 Y Y SYSTEST22 22-APR-2005 

LEARNER (OLD) 200510 UG/BA BS-MAG AS/M INACTIVE 4 2 N N SYSTEST22 21-APR-2005 

CHLD - MAJ INPROGRESS 1 1 N N SYSTEST22 21-APR-2005 

DISC - MIN INPROGRESS 2 2 N N SYSTEST22 21-APR-2005 

PERC - CON INPROGRESS 3 2 N N SYSTEST22 21-APR-2005 

180600008 Downey, James 

ADMISSIONS 200510 UG/BA BA-ECON AD/ ACTIVE 2 1 Y Y SYSTEST22 19-APR-2005 


CF - MAJ OVERLOAD 2 2 Y N SYSTEST22 19-APR-2005 

OUTCOME 200510 UG/BA BA-ECON AD/ ACTIVE 3 1 Y Y SYSTEST22 19-APR-2005 

ECON - MAJ SOUGHT 1 1 Y Y SYSTEST22 19-APR-2005 

CF - MAJ OVERLOAD 2 2 Y N SYSTEST22 19-APR-2005 

180600006 Good, Shannon 

ADMISSIONS 200510 UG/BA BA-ECON AD/ ACTIVE 1 1 Y Y SYSTEST22 19-APR-2005 

ECON - MAJ APPACCEPT 5 1 Y Y SYSTEST22 19-APR-2005 


MIN5 - MIN APPACCEPT 6 1 Y Y SYSTEST22 19-APR-2005 

MIN5 - MIN INPROGRESS 2 1 N Y SYSTEST22 19-APR-2005 

FIN - MIN APPACCEPT 7 2 Y Y SYSTEST22 19-APR-2005 

FIN - MIN INPROGRESS 3 2 N Y SYSTEST22 19-APR-2005 

ANTH - MIN APPACCEPT 8 3 Y Y SYSTEST22 19-APR-2005 

ANTH - MIN INPROGRESS 4 3 N Y SYSTEST22 19-APR-2005 






PAGE 3 



COLL / C A 



__ ______ ____ _____ ______________ ____ ____ ___ ___ _ _ _______ ____ 

180600006 Good, Shannon 



MIN5 - MIN INPROGRESS 2 1 Y Y SYSTEST22 19-APR-2005 

FIN - MIN INPROGRESS 3 2 Y Y SYSTEST22 19-APR-2005 

ANTH - MIN OVERLOAD 4 3 Y N SYSTEST22 19-APR-2005 

180600014 Gotwals, Doris 

ADMISSIONS 200510 UG/BS VAT M/M INACTIVE 5 1 Y N SYSTEST22 21-APR-2005 

ACCT - MAJ CHANGED 1 1 Y N SYSTEST22 21-APR-2005 

180600025 Greene, Anne 

LEARNER 200610 UG/BA BA-ENGLISH AS/ ACTIVE 4 1 Y Y SYSTEST22 25-APR-2005 

ENLT - MAJ 2420 INPROGRESS 1 1 Y Y SYSTEST22 25-APR-2005 

LEARNER (OLD) 200510 UG/BA BA-ANTHRO AS/M ACTIVE 1 1 N Y SYSTEST22 25-APR-2005 

ANTH - MAJ INPROGRESS 1 1 N Y SYSTEST22 25-APR-2005 

180600029 Hart, Robyn 

OUTCOME 200410 UG/BS VAT M/M ACTIVE 5 1 Y Y SYSTEST22 26-APR-2005 

ACCT - MAJ SOUGHT 1 1 Y Y SYSTEST22 26-APR-2005 

OUTCOME (OLD) 200510 UG/BA BS-MAG AS/M ACTIVE 4 1 N Y SYSTEST22 26-APR-2005 

CHLD - MAJ SOUGHT 1 1 N Y SYSTEST22 26-APR-2005 

180600005 Heaton, Randy 







LEARNER 200510 UG/BS SMED AS/ INACTIVE 4 2 Y N SYSTEST22 19-APR-2005 

ATHL - MAJ INPROGRESS 1 1 Y N SYSTEST22 19-APR-2005 

OUTCOME 200510 UG/BS SMED AS/ ACTIVE 8 2 Y Y SYSTEST22 29-APR-2005 

RETR - MAJ SOUGHT 1 1 Y Y SYSTEST22 29-APR-2005 

OUTCOME (OLD) 200510 UG/BA BS-MAG AS/M INACTIVE 7 2 N N SYSTEST22 29-APR-2005 

CHLD - MAJ SOUGHT 1 1 N Y SYSTEST22 29-APR-2005 

180600017 Lafferty, Elizabeth 

LEARNER 200610 UG/BA BA-LOGIC AS/M ACTIVE 4 1 Y Y SYSTEST22 21-APR-2005 

ACCT - MAJ INPROGRESS 1 1 Y Y SYSTEST22 21-APR-2005 

LEARNER (OLD) 200510 UG/BA BA-IBUS SB/ ACTIVE 1 1 N Y SYSTEST22 21-APR-2005 


180600004 Law, Jay 






PAGE 4 



COLL / C A 



__ ______ ____ _____ ______________ ____ ____ ___ ___ _ _ _______ ____ 

180600004 Law, Jay 


RETR - MAJ APPACCEPT 3 1 Y Y SYSTEST22 19-APR-2005 

RETR - MAJ INPROGRESS 2 1 N Y SYSTEST22 19-APR-2005 





ECOM - MIN APPACCEPT 4 1 Y Y SYSTEST22 19-APR-2005 

ECOM - MIN INPROGRESS 2 1 N Y SYSTEST22 19-APR-2005 

LEARNER 200510 UG/BS VAT M/M INACTIVE 4 2 Y N SYSTEST22 19-APR-2005 

FIN - MAJ INPROGRESS 1 1 Y N SYSTEST22 19-APR-2005 

ECOM - MIN INPROGRESS 2 1 Y N SYSTEST22 19-APR-2005 

180600001 Law, Paula 

RECRUIT 200510 UG/BS SMED AS/ ACTIVE 2 2 Y Y SYSTEST22 18-APR-2005 


RECRUIT (OLD) 200510 UG/BA BS-MAG AS/M ACTIVE 1 2 N Y SYSTEST22 18-APR-2005 




RECRUIT (OLD) 200510 UG/BA BA-ENGLISH AS/ INACTIVE 3 3 N N SYSTEST22 18-APR-2005 

ENGL - MAJ ENGL INPROGRESS 1 1 N Y SYSTEST22 18-APR-2005 

ART - VOC INPROGRESS 2 1 N Y SYSTEST22 18-APR-2005 

180600028 Marchewski, Walter 

LEARNER 200610 UG/BA BA_DMF AS/ ACTIVE 3 1 Y Y SYSTEST22 26-APR-2005 

BIOC - MAJ BIOL INPROGRESS 1 1 Y Y SYSTEST22 26-APR-2005 



180600016 Martinelli, Sarah 

LEARNER 200610 UG/BA BS-MAG AS/M ACTIVE 3 1 Y Y SYSTEST22 21-APR-2005 


LEARNER (OLD) 200510 UG/BA BS-MAG AS/M ACTIVE 1 1 N Y SYSTEST22 21-APR-2005 


180600007 Munera, Jack 



FIN - MAJ OVERLOAD 2 2 Y N SYSTEST22 19-APR-2005 






PAGE 5 



COLL / C A 



__ ______ ____ _____ ______________ ____ ____ ___ ___ _ _ _______ ____ 

180600007 Munera, Jack 



FIN - MAJ OVERLOAD 2 2 Y N SYSTEST22 19-APR-2005 

180600000 Neesan, Marissa 


FIN - MAJ INPROGRESS 1 1 Y Y SYSTEST22 18-APR-2005 

RECRUIT (OLD) 200410 UG/BA BA-ECON AD/ INACTIVE 11 2 N N SYSTEST22 18-APR-2005 



FIN - MAJ APPLIED 6 1 Y Y SYSTEST22 18-APR-2005 




ACCT - MAJ INPROGRESS 2 2 N N SYSTEST22 18-APR-2005 

ECOM - MIN APPLIED 8 1 Y Y SYSTEST22 18-APR-2005 

ECOM - MIN INPROGRESS 4 1 N Y SYSTEST22 18-APR-2005 

EUTL - CON APPLIED 9 1 Y Y SYSTEST22 18-APR-2005 

EUTL - CON INPROGRESS 5 1 N Y SYSTEST22 18-APR-2005 



RECRUIT (OLD) 200510 UG/BA BA-ENGLISH AS/ INACTIVE 3 2 N N SYSTEST22 18-APR-2005 

ENGL - MAJ ENGL CHANGED 1 1 N Y SYSTEST22 18-APR-2005 

SOC - MAJ CHANGED 2 2 N Y SYSTEST22 18-APR-2005 

RECRUIT (OLD) 200510 UG/BA BA-ENGLISH AS/ ACTIVE 2 2 N Y SYSTEST22 18-APR-2005 


SOC - MAJ INPROGRESS 2 2 N Y SYSTEST22 18-APR-2005 



FIN - MAJ CHANGED 2 1 N Y SYSTEST22 18-APR-2005 




ATHL - MAJ CHANGED 2 1 N Y SYSTEST22 18-APR-2005 


ADMISSIONS (OLD) 200510 UG/BA BA-ENGLISH AS/ INACTIVE 6 2 N N SYSTEST22 18-APR-2005 


180600003 Olsen, Dan 






PAGE 6 



COLL / C A 



__ ______ ____ _____ ______________ ____ ____ ___ ___ _ _ _______ ____ 

180600003 Olsen, Dan 








LEARNER 200510 UG/BS VAT M/M ACTIVE 2 1 Y Y SYSTEST22 19-APR-2005 


FIN - MAJ INPROGRESS 2 2 Y Y SYSTEST22 19-APR-2005 

ECON - MAJ OVERLOAD 3 3 Y N SYSTEST22 19-APR-2005 

180600002 Rhoads, Barbara 


FIN - MAJ APPLIED 6 1 Y Y SYSTEST22 19-APR-2005 






ART - MAJ APPLIED 9 4 Y Y SYSTEST22 19-APR-2005 

ART - MAJ INPROGRESS 4 4 N Y SYSTEST22 19-APR-2005 

BUSI - MAJ INPROGRESS 5 5 Y N SYSTEST22 19-APR-2005 








ART - MAJ OVERLOAD 4 4 Y N SYSTEST22 19-APR-2005 

180600019 Stierly, Gladys 

LEARNER 200610 UG/BS BS-MARKETING BU/M ACTIVE 4 1 Y Y SYSTEST22 22-APR-2005 

BHS - MAJ INPROGRESS 1 1 Y Y SYSTEST22 22-APR-2005 

LEARNER (OLD) 200510 UG/BS BS-MARKETING BU/M ACTIVE 1 1 N Y SYSTEST22 22-APR-2005 

BHS - MAJ INPROGRESS 1 1 N Y SYSTEST22 22-APR-2005 





PAGE 7 




Parameters were entered via Job Submission. 


______________ _____ 


Number of Learner IDs: 21 

Learner ID: 

Application Code: MAG 

Selection Identifier: MICHAEL_CC_POP 

Creator ID: SYSTEST22 

User Id: SYSTEST22 

Learner Module: 

Term Code: 

Start Date: 

End Date: 

CSTS Code: 

CACT Code: 

Report Type: A 








Section 2 Loading Delimited Prospect Files - AMCAS Phase 1 - Functional 

Overview 

Section 2 

Loading Delimited Prospect Files - AMCAS 

Phase 1 - Functional 


Overview 

Phase 1 of this enhancement provides additional functionality for the Electronic 

Prospect Load Process (SRTLOAD) so that delimited files can be loaded. This 

capability will allow SRTLOAD to load AMCAS medical school data to Banner as of 

the Banner Student 7.2 release (Phase 2 of the enhancement), thereby centralizing 

all Banner Student data load processing. 

Other processing improvements have also been made, such as how test scores are 

read from their data sources and the addition of new rules on SAAERUL to provide 

users with more flexibility in determining what should happen when prospect 

records are loaded. Lastly, functionality was added to the existing AMCAS Data 

Load Process (SAPAMAL) so that users can choose to create Banner IDs using either 

a generated ID or an SSN. 

This enhancement includes the following RPEs: #30816, #38172, #28187, and 

#26832. 




Process Flows 

Process Flows 

Loading Packages and Procedures from Temporary Tables to 

Production Tables (SRKPREL) 

Overview 

Person 

exists 

No 

Create person data 

CREATE- 

NEWRECR 

Yes 

Insert recruit info 

Yes 

No 

goto eval app 

UPDATEIFAPP 

=Nand 

SARADAP_EXISTS 

=Y 

No 

Update 2 

Yes 

Update 1 




Process Flows 

Creating Person Data 

RECRUIT_ 

EXISTS = Y 

Yes 

p_insert_spbpers 

p_insert_spraddr 

p_insert_sprtele 

No 

p_insert_spriden 

p_insert_goremal 

p_insert_intl 

LOAD 

INTEREST 

No 

SORHSCH_EXISTS 

and 

RECRUIT_EXISTS 

No 

HSCHSELF 

REPORT 

p_insert_sorhsch 

SORPCOL_EXISTS 

and 

RECRUIT_EXISTS 

Yes 

Yes 

p_insert_sorints 

p_insert_sorhsch_selfreport 

Yes 

No 

Yes 

p_insert_sorpcol 

p_insert_srttest 

goto eval app 




Process Flows 

Evaluating the Application 

CREATE- 

NEWAPPL 

No 

END SRKPREL 

Yes 

sakmods.p_create_application 




Process Flows 

Inserting Recruiting Information 

p_insert_srbrecr 

CREATE 

CONT 

Yes 

p_insert_sorcont 

No 

CREATE 

LEARNED 

Yes 

p_insert_srrlend 

No 

CREATE 

MATERIALS 

Yes 

p_insert_gurmail 

No 

CREATE 

SRCE 

Yes 

p_insert_srrrsrc 

No 

COMM 

PLAN 

Yes 

p_insert_commplan 

No 

goto eval app 




Process Flows 

Updating Recruiting Information - Part 1 

CREATE 

CONT 

Yes 


No 

srbrecr_ 

campus_ 

exists 

Yes 

CREATE 

SRCE 

Yes 

p_insert_recruit_srrrsrc 

No 

No 

CREATE 

LEARNED 

Yes 


No 

p_insert_sarrsrc 

CREATE 

MATERIALS 

Yes 


(recruit) 

CREATE 

MATERIALS 

Yes 

No 

No 


(application) 

create person data 

goto eval app 




Process Flows 

Updating Recruiting Information - Part 2 

CREATE 

NEWRECR 

Yes 

Yes 

p_insert_srbrecr 

No 

Create person data 

No 

Match 

exists 

No 

SRBRECR_ 

EXISTS 

(SRBRECR_EXISTS = N and 

CREATECONT = Y) or 

SRBRECR_EXISTS = Y or 

SARADAP_EXISTS = Y 

Yes 


Yes 

Yes 

No 

NMCREATE 

NEWRECR 

No 


CREATELEARNED = Y) or 



Yes 


NMCREATE 

NEWRECR 

No 

goto eval app 

Yes 

No 

Update 



CREATEMATERIALS = Y) or 



Yes 



No 



CREATESRCE = Y) or 



Yes 

p_insert_srrrsrc 

No 

SARADAP_ 

EXISTS 

Yes 

No 

p_update_srrrsrc 

p_update_sarrsrc 

COMMPLAN 

Yes 

p_insert_commplan 

goto eval app 

goto eval app 

No 




New Forms 

New Forms 

Tape File Delimiter Type Rules (SORDLIM) 

Use this form to assign a delimiter and/or marker to a specific tape code. The 

delimiter and/or marker should match those contained in the delimited input file 

to be used with this tape code. 

Fields 

. . . . . . . . . . . . . . 

Tape Code 

Descriptions 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Enter the data file/tape code for the rule. 

(lookup) List Electronic Datafile and Tape 

Validation (STVTAPE) 

Description 

This is the description of the tape code. It defaults in from the 

tape code selected from the List of Values. 

Delimiter 

Enter the delimiter which indicates a new field on the tape, such 

as a comma. 

Marker 

Enter the marker used in addition to the delimiter to enclose the 

field data, such as an apostrophe. 

System Required 

Check this box if the rule is system required. 

User ID 

This is the ID of the user who created or updated the rule. 

Activity Date 

This is the date the rule was created or updated. 

Tape File Test Score Controls (SRATPTS) 

Use this form to map the test code which contains the “date taken” to all the other 

test codes for which that date taken applies. For example, the date taken for one set 

of SAT I scores is contained in only one place, even though that date applies to both 

the SAT Verbal and Math scores. 

This satisfies RPE #30816. 




Changed Forms 

Fields 

. . . . . . . . . . . . . . 

Test Code 

Descriptions 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Enter the test code to which a date origin will be assigned. 

(lookup) List Test Code Validation 

(STVTESC) 

Description 

This is the description of the test code. It defaults in from the 

tape code selected from the List of Values. 

Test Code Date 

Origin 

Enter the test code date origin for the test code. 

(lookup) List Test Code Validation 

(STVTESC) 

System Required 

Check this box if the rule is system required. 

User ID 

This is the ID of the user who created or updated the rule. 

Activity Date 

This is the date the rule was created or updated. 

Changed Forms 

Test Score Information Form (SOATEST) 

This form has been redesigned for this release to allow more rows of data to be 

accessible in the main window. The Test Score Information block has been 

expanded with three tabs: Test Scores (1), Test Scores (2), and Test Scores (3). The 

fields in this block have been reordered slightly and are viewable using the three 

new tabs. No fields have been added or removed. 

The forms documentation that follows shows the new field order and tab navigation. 

Updated Form Documentation - Test Score Information Form 

(SOATEST) 

Use this form to create and update test score information for an applicant. Test 

score information can be added or updated automatically via the tape load process 

or manually. 




Changed Forms 

If a test score is a checklist item on a student's admissions application, the checklist 

will be automatically updated with the most recent test date information (date 

taken) from SOATEST. 

Prerequisite 

The ID must exist before test scores can be entered. You can create an ID on the 

General Person Identification Form (SPAIDEN).The tape load process will add the 

person prior to loading the scores, if the person does not exist. 

Main Window 

Use this window to record test scores for the student whose ID you enter in the Key 

Block. 

Key Block 

Use the Key Block to enter the ID of the student for whom test score information is 

being created or updated. 

Select the Individual’s Checklist Items option in the Options Menu to view checklist 

items for the ID in the Key Block by term and application number. 

Fields 

. . . . . . . . . . . . . . 

ID 

Descriptions 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

ID and name of the student for whom test score information is 

being created or updated. The ID must exist before test scores 

can be entered. You can create an ID on the General Person 

Identification Form (SPAIDEN). 

Column: Not a base table item 

Test Score Information Block 

Use the Test Score Information block to record test scores. This block can be 

expanded using the Test Scores (1), Test Scores (2), and Test Scores (3) tabs. Each 

tab displays additional fields for each record in the block. 

Select the Individual’s Checklist Items option in the Options Menu to view checklist 

items for the ID in the Key Block by term and application number. 




Changed Forms 

Fields 

. . . . . . . . . . . . . . 

Test Code 

Descriptions 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Test score code and description associated with the various tests 

(for example, SAT and ACT). Choices come from the Test Score 

Validation Form (STVTESC). 

Column: SORTEST_TESC_CODE 

Test Score 

Score for the test. The valid range for the test score is displayed 

at the bottom of the Display block. 

Information from the Test Score Validation Form (STVTESC) 

appears at the bottom of the screen in the Display block, and 

displays when you move your cursor to this field. 

Column: SORTEST_TEST_SCORE 

Use the Test Scores (1) tab to view these fields. 

Test Date 

Date the test was taken. This date is entered automatically in the 

untitled Comment field associated with the test in the Checklist 

Summary window of the Admissions Application Form 

(SAAADMS). 

Note: If a test score is a checklist item on a student's 

admissions application, the checklist is automatically 

updated with the most recent test date from the Test 

Date field on SOATEST. 

Column: SORTEST_TEST_DATE 

Admission 

Request 

Code that links test scores entered on this form with admissions 

request test scores in the Checklist Detail window on the 

Admission Application Form (SAAADMS). When this code 

matches the Admissions Request (Checklist Item Code) in the 

Checklist Detail window, the Received Date in the Checklist 

Detail window is updated if the date is blank. Choices come from 

the Admissions Request Code Validation (STVADMR) list. 

Note: Information appears in this field automatically if the 

test score is defined in the Admissions Checklist 

Request Item field on the Test Code Validation Form 

(STVTESC). 

Source: This value comes from STVTESC. It can be changed. 

Column: SORTEST_ADMR_CODE 




Changed Forms 

Fields 

. . . . . . . . . . . . . . 

Source 

Descriptions 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Source used to enter the associated test score (for example, 

magnetic tape or self reported). Choices come from the 

Admission Test Score Source (STVTSRC) list. 

Equivalency 

Indicator 

This checkbox is a not null field whose default value is N. If the 

checkbox is checked (Y), then the corresponding test record was 

created as the result of the equivalency processing function 

within SRKTEST. When a test score is inserted into SORTEST via 

the SRKTEST package, if an equivalency is created for that test 

score, the Equivalency Indicator checkbox will be checked (Y). 

In addition, the effective term code of the record from 

SOATEQU used in determining the equivalency score will be 

inserted into the Term field (SORTEST_TERM_CODE_ENTRY) of 

the equivalent test score record. This helps determine which 

equivalency record was used in calculating the equivalency for a 

specific test score. 

Column: SORTEST_EQUIV_IND 

Revised or 

Recentered 

Code that indicates whether the SAT score is recentered, revised, 

or both. Choices are: 

X -- The score is revised. 

R -- The score is recentered. 

Z -- The score is revised and recentered. 

Null - The score is not revised or recentered. 

Source: This value is loaded during the tape load process. 

Column: SORTEST_RCRV_IND 


Administration 

Type 

Method used to administer the test (for example, locally or 

nationally). Choices come from the Admissions Test 

Administration Type Validation list (STVTADM). 

Column: SORTEST_TADM_CODE 

Purpose 

Purpose or reason for taking the test. Choices come from the Test 

Purpose Validation (STVTEPR) list. 

Column: SORTEST_TEPR_CODE 




Changed Forms 

Fields 

. . . . . . . . . . . . . . 

Form 

Descriptions 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Test form code. This field is informational only. Choices come 

from the Test Form Validation (STVTEFR) list. 

Column: SORTEST_TEFR_CODE 

Accommodation 

Special accommodations made for this test and student. Choices 

come from the Test Accommodation Validation (STVTEAC) list. 

Column: SORTEST_TEAC_CODE 

Instrument 

Instrument used to take the test. Choices come from the Test 

Instrument Validation (STVTEIN) list. 

Column: SORTEST_TEIN_CODE 


Term 

Term during which the test score information was recorded, or 

the term for which the applicant is applying. Choices come from 

the Term Code Validation (STVTERM) list or the Admissions 

Application Summary Form (SAASUMI). 

Test scores can be stand-alone or associated with an application. 

If association with an application is desired, the term and 

application number entered must represent a valid application. 

(Test scores added by the AMCAS application load process will 

associate the MCAT score with a specific application.) 

Column: SORTEST_TERM_CODE_ENTRY 

Application 

Number 

Application number. Use zero (0) for no specific application. 

Choices come from the Admissions Application Summary Form 

(SAASUMI). 

Test scores can be stand-alone or associated with an application. 

If association with an application is desired, the term and 

application number entered must represent a valid application. 


associate the MCAT score with a specific application.) 

Column: SORTEST_APPL_NO 




Changed Forms 

Fields 

. . . . . . . . . . . . . . 

Release 

Indicator 

Descriptions 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Checkbox that indicates that the person authorized release of 

information to other parties, for example, for search services use. 


set the Release Indicator when Med/Mar processing is 

authorized by the person.) Choices are: 

checked -- Release of information is authorized. 

unchecked -- Release of information is not authorized. 

Column: SORTEST_RELEASE_IND 

Instrument ID 

Instrument used to record the document number used by the 

person for a test. (Writing Sample test scores loaded by the 

AMCAS application load process use this field to store the 

Writing Sample Lithocode.) 

Column: SORTEST_INSTR_ID 

SAT Essay ID 

Web SAT Essay ID from the essay portion of the SAT test. 

Column: SORTEST_SAT_ESSAY_ID 

Display Block 

Use the Display block (untitled) to display information from the Test Code 

Validation Form (STVTESC). The information displayed depends on the cursor 

location in the Test Score Information block. As you select each record in the Test 

Score Information block, the data associated with the selected test code is displayed 

in the Display block. 

Fields 

. . . . . . . . . . . . . . 

Test Type 

(untitled) 

Descriptions 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Test type of the selected test code. 

Source: This value comes from the Test Code Validation Form 

(STVTESC). 

Column: Base table item 

Scores must be 

Characteristics of the test score to be entered. This code begins 

with the length of the test score followed by the type of 

characters. 


(STVTESC). 

Column: Not a base table item (code and description) 




Changed Forms 

Fields 

. . . . . . . . . . . . . . 

characters in 

range of 

Descriptions 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Range of numbers or letters between which the score must fall to 

be valid for the selected test code. 


(STVTESC). 

Column: Not base table items 

Tape Code Conversion Form (SOTCNVT) 

A Copy Values button has been added to the Key Block. Use this button to copy 

values from one interface code to another. When you select the button, the List of 

Values will display a row for each interface code which contains conversion values 

for the validation table entered in the Key Block. If no validation table name is 

entered, then the List of Values will display all interface codes that contain 

conversion records. 

For example, if you have an Interface Code of PCU, and that code has conversions 

for Validation Table Name INTS (interests) defined on SOTCNVT, and you want to 

copy that data to an Interface Code of SAT, do the following. 

1. Enter SAT in the Interface Code field and INTS in the Validation Table Name 

field. 

2. Select the Copy Values button. 

3. Select PCU from the Interface Codes for the Table window that appears and 

select OK. The rows from PCU with the table name equal to INTS are copied 

back to SOTCNVT for the Interface Code of SAT and the Validation Table 

Name of INTS. 

If you want all conversion values from one interface code (i.e, PCU) copied to 

another interface code (i.e, SAT), do the following: 

1. Enter SAT in the Interface Code field, and leave the Validation Table Name 

field blank. 

2. Select the Copy Values button. 

3. The Interface Codes with Conversion Rules window will appear, displaying all 

the interface codes that contain any conversion records. 





Changed Forms 

Electronic Admissions Application Rules Form (SAAERUL) 

The following changes have been made to the form. 

New Button 

A new Copy PREL Group button has been added to the form. This button is used to 

copy existing PREL rules to a new group code. Once the values have been copied, 

the System Required Indicator defaults to N or unchecked, so you can customize the 

group settings. This allows users to customize the PREL rules based on each PREL 

code used, instead of the same set of values applying to all PREL codes. 

For example, if a PREL code of SAT exists and you want it to be processed differently 

based on the rules for a group code of PREL on SAAERUL, then do the following. 

1. Define a new group code on the EDI Rule Group Validation Form (STVEGRP) 

for SAT. (The new group code must match the PREL code). 

2. Enter SAT in the Group field on SAAERUL. 

3. Select the Copy PREL Group button. All of the rules that exist for the PREL 

group code will be copied to your new SAT group code. 

4. You can customize those values, and they will be applied only when the PREL 

code used on SRTLOAD, SRRSRIN, or SRRPREL is SAT. 

New Rules 

New rules have been added to the form for the group code of PREL to provide more 

flexibility when creating recruiting records, addresses, and phone numbers. A new 

script, sinserul.sql, is being delivered which inserts all available rows into 

SAAERUL for each group code. If a row already exists in your table, the insert script 

will bypass inserting that row. 


Note: Rules for SAAERUL are provided by SunGard SCT through a script. No 

rules should be added locally. 

Group Code Rule Label Rule Description Delivered Value 

PREL CREATENEWRECR * No Recruit exists; create one UPDATEME 

PREL MCREATENEWRECR Matched Recruit exists; create UPDATEME 

PREL NMCREATENEWRECR Non-match Recr exists; create UPDATEME 

PREL NEWADDRESS * No Address exists; create one UPDATEME 




Changed Forms 

Group Code Rule Label Rule Description Delivered Value 

PREL ADDRDIFFTYPE Addr w/Diff Addr Type exists UPDATEME 

PREL ADDRSAMETYPE Addr w/Same Addr Type exists UPDATEME 

PREL NEWPHONE * No Phone exists; create one UPDATEME 

PREL PHONDIFFTYPE Phone w/Diff Type exists; add UPDATEME 

PREL PHONSAMETYPE Phone w/Same Type exists; add UPDATEME 

* These are existing rules that have new functionality with this release. 

For the existing rule label CREATENEWRECR (no recruit exists, create new 

recruit), the possible values are Y or N. When an incoming record is being loaded 

and matched to an existing Banner person, the code will check if a recruiting record 

already exists for the person. If none does, then the code will check the 

CREATENEWRECR rule. If the rule value is Y, then the incoming data will be used 

to create a recruiting record. If the rule value is N, then no recruiting record will be 

created. 

The two new rules used for creating a recruiting record are MCREATENEWRECR 

(matching recruit exists, create new recruit) and NMCREATENEWRECR (nonmatching 

recruit exists, create new recruit). 

• The possible values for MCREATENEWRECR are Y, N, or U (Update). If an 

incoming record is being loaded, the program will determine if a matching 

recruiting record already exists. An existing recruiting record matches if it has 

the same term, level, and optionally campus. 

• If the incoming record matches the existing recruiting record, and the 

MCREATENEWRECR rule value is Y, then a new recruiting record will be 

created. 

• If the MCREATENEWRECR rule value is U, then no new recruiting 

record will be created, and instead, the existing recruiting record will be 

updated. 

• If the MCREATENEWRECR rule value is N, then no recruiting record will 

be added, and the existing recruit record will not be updated. 

• The possible values for NMCREATENEWRECR are Y or N. If an incoming 

record is being loaded, and it does not match to an existing recruiting record 

(based on term, level, and optionally campus), then the code will check the 

NMCREATENEWRECR rule to determine whether or not to create a new 

recruiting record. 

The existing rule label NEWADDRESS (no address exists, create one) is used when 

no address currently exists for the person in Banner. The possible values are Y or N. 

If the rule value is set to Y and no address currently exists for the person, the 

incoming address will be loaded. 




Changed Forms 

The two new rules used for creating an address record are ADDRDIFFTYPE (address 

exists with different address type, add address) and ADDRSAMETYPE (address 

exists with same address type, add address). The possible values for the new rules are 

Y or N. 

• If an address already exists in Banner, and the incoming address record has the 

same address type, the address record will be inserted if the ADDRSAMETYPE 

rule value is Y. 

• If the incoming address record has an address type that differs from the 

existing Banner address record, and the ADDRDIFFTYPE rule value is Y, then 

the incoming address record will be loaded. If the ADDRDIFFTYPE rule value 

is N, it will not be loaded. 

The existing rule label NEWPHONE (no phone exists, create one) is used when no 

phone number currently exists for the person in Banner. The possible values are Y 

or N, where Y creates a new phone number, and N does not create a new phone 

number. 

The two new rules used for creating a phone record are PHONDIFFTYPE (phone 

number exists with different phone type, add phone) and PHONSAMETYPE 

(phone number exists with same phone type, add phone). The possible values for 

the new rules are Y or N. 

• If a telephone record already exists in Banner, and the incoming telephone 

record has the same phone type, the phone number will be inserted if the 

PHONSAMETYPE rule value is Y. 

• If the incoming phone record has a phone type that differs from the existing 

Banner phone type, and the PHONDIFFTYPE rule value is Y, then the 

incoming phone number will be loaded. If the value is N, it will not be loaded. 

Web for Prospects allows users to enter extra phone numbers in Student Self-Service 

that are not associated with a specific address. If extra phone numbers are entered 

by prospects on the Web, they will be processed in conjunction with address/phone 

data as follows: 

1. The primary address (Address 1) is loaded to Banner along with its associated 

phone number using the new PREL rules identified above. 

2. The secondary address (Address 2), if it exists, is loaded to Banner along with 

its associated phone number using the new PREL rules identified above. 

3. The extra phone numbers entered are processed one at a time, based on the 

alphabetical order of the telephone type, using the new PREL rules identified 

above. 

For example: 

• NEWPHONE = Y 

• NEWADDRESS =Y 




Changed Forms 

• PHONSAMETYPE = N 

• PHONDIFFTYPE = Y 

The person being loaded is new to Banner and has entered a mailing address and 

phone number. In addition, they have entered a separate “mailing” phone number 

and a “business” phone number. When the record is processed, the mailing address 

and phone number will be loaded, because the NEWADDRESS and NEWPHONE 

rules are both set to Y. 

Next, the business phone number will be processed, because it falls first 

alphabetically based on the phone type. The business phone number will be loaded, 

because it is a different type than the already processed mailing phone number, and 

the PHONDIFFTYPE rule is set to Y. The mailing phone number will then be 

processed. It will also be loaded to Banner, because it is a different type than one of 

the existing Banner phone numbers (the business phone that was just processed), 

and the PHONDIFFTYPE rule is se to Y. 

Tape Field Position Rule Form (SRATPFD) 

This form has been modified to display different fields depending on whether the 

specified tape code is for a positional layout, such as SAT or ACT, or for a sequential 

layout, such as a comma delimited file. The fields displayed are determined by the 

tape code entered in the Key Block. 

The Re-sequence and Save button has been added to the Rules block for the 

Sequential Layout display. This button is used to automatically re-sequence the data 

fields and then save the changes. Use this button if it becomes necessary to insert 

an additional row into the form. This button was added to make it easier to insert a 

row given that the sequence numbers need to be entered sequentially. 

Updated Form Information - Tape Field Position Rule Form (SRATPFD) 

Use this form to define either the exact positions in which each field exists on a 

search or test score tape or the relative position of each field and then to assign the 

value in those positions to the appropriate Banner fields. 

This form, in combination with the Electronic Prospect Load (SRTLOAD), the 

Electronic Prospect Match (SSRSRIN), and the Migrate Electronic Prospects 

Process (SRRPREL), allows institutions to set up tape loads that are not supported 

by SunGard SCT, such as AP (Advanced Placement exams) or other search or test 

score tapes. 




Changed Forms 

This form displays two sets of information. It displays fields for a default positional 

layout (such as SAT or ACT) or for a sequential layout (such as a comma delimited 

file). The layout displayed is determined by the tape code entered in the Key Block. 

If the tape code has been defined on the Tape File Delimiter Type Rules Form 

(SORDLIM), then the fields required to define a sequential delimited file will be 

displayed. If the tape code has not been defined on SORDLIM, then the fields 

required to define a positional layout will be displayed. 

Main Window 

The main window contains two blocks. The Rules block can be displayed in a default 

positional layout or a sequential layout, depending on the type of tape code entered 

in the Key Block. 

Key Block 

The following fields are in the Key Block. 

Fields 

. . . . . . . . . . . . . . 

Tape Code 

Descriptions 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Enter the tape code for the tape field position rule. 

(lookup) List Tape Codes (STVTAPE) 

Record Number 

Enter the record number for the rule. 

(lookup) List Tape Record Number 

Rules Block - Default Positional Layout 

The default positional layout contains the following fields. 

Fields 

. . . . . . . . . . . . . . 

Field Name 

Descriptions 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

This is the tape field name for the tape in the Key Block. 

(lookup) List Tape Field Names (STVTPFD) 

Start Position 

This is the starting position of the field on the tape/file. 

End Position 

This is the ending position of the field on the tape/file. 




Changed Forms 

Fields 

. . . . . . . . . . . . . . 

Occurrence 

Descriptions 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

This is the occurrence of the data item on the tape. It can be used 

to accommodate those tape values that may occur multiple times 

such as test scores for different test dates. The fields defined in 

this form are delivered by SunGard SCT. 

Activity Date 

This is the date the record was created or updated. 

Rules Block - Sequential Layout 

Use the Re-sequence and Save button to automatically re-sequence the data fields 

and then save the changes. Use this button if it becomes necessary to insert an 

additional row into the form. 

The sequential layout contains the following fields. 

Fields 

. . . . . . . . . . . . . . 

Field Name 

Descriptions 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

This is the tape field name for the tape in the Key Block. 

(lookup) List Tape Field Names (STVTPFD) 

Sequence 

Number 

This is the relative position of the tape field on the data file. The 

sequence numbers must be sequential (i.e., 1, 2, 3, etc.). 

Occurrence 

This is the occurrence of the data item on the tape. It can be used 

to accommodate those tape values that may occur multiple times 

such as test scores for different test dates. The fields defined in 

this form are delivered by SunGard SCT. 

Activity Date 

This is the date the record was created or updated. 

More buttons in the Rules Block - Sequential Layout 

Mouse Keyboard Result 

Re-sequence 

and Save 

N/A 

Add row, re-sequence data fields, 

save changes. 




Changed Menu 

Changed Menu 

Search Tape Control Menu (*SEARCHCONT) 

Two news forms and one existing form have been added to this menu: 

• Tape File Delimiter Type Rules Form (SORDLIM) 

• Tape File Test Score Controls Form (SRATPTS) 

• Tape Code Conversion Form (SOTCNVT) 


AMCAS Data Load Process (SAPAMAL) 

Two parameters have been added to the process: 

• Use the new SSN or Generated ID parameter to designate which ID is to be 

used. This parameter is required. Enter S to use the SSN from the data file as 

the ID or G to always generate a new ID. 

• Use the Update Existing SSN parameter to designate if an existing SSN is to be 

updated by the process. This parameter is required. Enter Y to update the 

existing SSN in the SPBPERS table with the SSN from the data file or N to not 

update the existing SSN. 

If the user enters Y and an SSN already exists for the person in Banner, that 

existing SSN will then be stored in the SSN/SIN/TIN History Table 

(GURHLOG) and will be viewable on the SSN/SIN/TIN History Form 

(GUITINH). 

Electronic Prospect Load (SRTLOAD) 

This process previously read input files based on start and end positions. Now, based 

on whether rules for file delimiters or delimiters/markers exist in the new 

SORDLIM table for a given tape code, the process will either look for the fields by 

position or by sequence number as defined in the SRRTPFD_START_POS field. 

The reference to the Test Code Validation Table (STVTESC) used by SRTLOAD for 

test codes has been replaced with the STVTESC_TESC_CODE_DATE_ORIGIN field. 

Also, the maximum size of the table has been increased from 49 to 500 for test codes. 





A new parameter has been added to the process. Use the Default Test Month 

parameter to designate the default month for the test, if none exists on the input 

file. This parameter is optional. Valid values are 01 - 12. 

This modification satisfies RPE #26832. 




output. 



output. 








Section 2 - Loading Delimited Electronic Prospect Files - AMCAS Phase 1 



Description 

This process loads AMCAS application data from the AMCAS Temporary Table (SATAMAL) to the Banner database. 

Based upon the selections made for the Run Mode (A or U) and Match on ID and Last Name Only Y/N parameters, the 

process will perform matching on ID and last name or ID, last name, and date of birth. Match results can be New, Match, or 

Reject. 

If run in Audit mode with the Create New Records Parameter (Y or N) set to N, record matching will occur and records will 

be written to two temporary tables which are used by the AMCAS Data Load Reports Process (SARAMAL) to produce various 

audit and error reports. 

Table 

SATARPT 

SATAHLD 

Description 

Includes match status and data to assist in name and ID change reporting. 

Includes information on data not loaded. 

If you do not run SAPAMAL in Audit mode before running it in Update mode, you will not be able to produce audit and error reports using 

SARAMAL. 

Note: The breakout totals for NEW, MATCHED, and REJECTED persons will not be available on the update output report if 

the SARAMAL process is not submitted prior to running SAPAMAL in Update Mode. 

If run in Update mode, the report will insert or update records based upon the data contained in SATAMAL. Each time 

SAPAMAL is run, it processes records in the AMCAS Temporary Table (SATAMAL) where the Processed Indicator 

(SATAMAL_PROCESS_IND) is Y (needs to be processed). 





If a visa type exists on the incoming AMCAS file, a visa record will be created on GORVISA. The visa number will be set to 

SAPAMAL_UNKNOWN. The nation of issue will be set to the country of citizenship if provided, otherwise it will be taken from 

the GTVSDAX VISANTNDEF record. The issuing authority will be taken from the GTVSDAX VISAISSDEF record. If an nation 

of citizenship exists, it will be loaded to GOBINTL. If the birth state is set to FR and a nation of birth exists, it will also be loaded 

to GOBINTL. 

Data will be inserted or updated in the following tables. In some cases, updates will overlay existing data, and in others, only 

null fields will be updated. 

Table 

SPRIDEN 

SPRADDR 

SPRTELE 

Description 

Inserts of new records; updates to existing records to make them non-current when new SPRIDEN 

records are inserted for name or ID changes. 

Stores a history of addresses associated with the parameter-specified address type. 

• If an incoming address matches an existing Banner address of the same address type, 

nothing will happen. 

• If the incoming address is different from the existing Banner address, then the 

existing address will be end-dated with the system date minus one if its To: Date field 

is blank. The new address will be inserted with a From: Date equal to the system date. 

• If the existing address has a To: Date that has not yet occurred, then the new address 

will be added with a From: Date of one greater than the To: Date of the existing 

address. 

Loads telephone numbers and links them to the parameter-specified address type. 

• If a new address is entered, then the telephone number associated with it will be 

inserted. 

• If a new phone number is received with no corresponding address change and the 

Update Records parameter is set to Y, then the new phone number will update the 

existing phone number. 





Table 

SPBPERS 

GOBINTL 

SORCRSS 

SORGPAT 

SORTEST 

SARADAP 

SABSUPL 

SORPCOL 

SORDEGR 

SORMAJR 

SORCCOL 

GOREMAL 

Description 

Updates to null fields only. 

Updates the Nation of Citizen field (GOBINTL_NATN_CODE_LEGAL) with incoming AMCAS data 

even if the field is not null. The Nation of Birth field (GOBINTL_NATN_CODE_BIRTH) will only be 

updated if it is null. 

Overlay of existing data. 


Inserts only; no records will be updated. 

Inserts only, no records will be updated. 


Insert only, no data to be updated. 

Updates to null fields only. 

Inserts only, no data to be updated. 

Inserts only, no data to be updated. 







School Code Yes Enter the AMCAS school code. If an invalid school 

code is entered, the process will terminate and the 

message “Invalid School Code” will print in the Control 

Report section of the output. 

Term Code Yes Enter the term to be used as the entry term for 

admissions applications created by the process. 

Program Code No Enter the program code for the applications, if the 

Program field in the application is to be populated. 


(STVTERM) 

Program Definition Rules Form 

(SMAPRLE) 

Level Code Yes Enter the level code for the applications. Level Code Validation Form 

(STVLEVL) 

College Code Yes Enter the college code for the applications. College Code Validation Form 

(STVCOLL) 

Degree Code Yes Enter the degree code for the applications. Degree Code Validation Form 

(STVDEGC) 

Major Code Yes Enter the major code for the applications. Major, Minor, Concentration Code 

Validation Form (STVMAJR) 

Campus Code Yes Enter the campus code for the applications. Campus Code Validation Form 

(STVCAMP) 






Student Type Code Yes Enter the student type code for the applications. Student Type Code Validation Form 

(STVSTYP) 

Address Type Code Yes Enter the address type code for the applications. Address Type Code Validation Form 

(STVATYP) 

Run Mode (A or U) Yes Enter A to perform record matching and write 

temporary table entries which will be used by 

SARAMAL to produce a variety of audit reports. 

Enter U to update the database records with the 

application data. The default value is A. 

A 

U 

Audit 

Update 

Match on ID/Last Name 

Only Y/N 

Yes 

Enter Y to match on ID and last name, or enter N to 

match on ID, last name, and birthdate. The default 

value is N. 

Y 

N 

Match on ID and last name 

Match on ID, last name, birthdate 

Please see the notes that follow for this parameter. 

Note: When set to Y, the process will "match" incoming data to an existing record if there is a 

match between the AMCAS SSN (or AMCAS previous SSN) and either the SPRIDEN_ID or 

SPBPERS_SSN fields and the AMCAS LAST NAME (or AMCAS previous LAST NAME) and the 

SPRIDEN_LAST_NAME field . The result of ID and last name only matching can be either Match, 

New, or Rejected (i.e., matches on either ID or last name, but not both). 






Note: When set to N, the process will match on ID first (based upon AMCAS SSN) compared 

to both SPRIDEN_ID and SPBPERS_SSN, and then will attempt to match AMCAS Last Name 

(and AMCAS previous last name) to Banner last name for the selected record, and then 

AMCAS Birthdate to Banner date of birth. If data does not match for either subsequent check, 

the record will be rejected. 

Create New Records (Y 

or N) 

Yes 

Enter Y to create new records when the match status 

is New, or enter N to not create new records. The 

default value is Y. 

Y 

N 

Create records 

Do not create records 

For Update Mode: When set to Y, new pidms will be 

generated for records whose match status is New, 

and other associated data will be inserted. When set 

to N, new pidms will not be generated, and no other 

data will be inserted for records whose match status 

is New. 

For Audit Mode: In order to produce the audit reports 

using SARAMAL, SAPAMAL must be run in Audit 

Mode with the Create New Records parameter set to N. 






Update Records (Y/N) Yes Enter Y to update existing data for matched records. 

Enter N to not update existing data for matched 

records. 

When set to Y, changes to existing Banner data will 

be processed as indicated in the table list in the 

report description. When N, no existing Banner 

data will be updated, and only new records will be 

inserted. 

Y 

N 

Update data 

Do not update data 

Update Prev Year Appl 

Fields 

Yes 

Enter a Y to update the previous application year 

fields on SOASUPL. Enter an N if these fields 

should not be updated. 

Y 

N 

Update SOASUPL 

Do not update SOASUPL 

Use Checklist Rules Only No Enter Y to apply checklist rules from SAACHKB only, 

or enter N to apply all checklist rules (from 

SAACHKB and system-generated items). 

Y 

N 

SAACHKB checklist rules only 

All checklist items 

Load High School GPA 

and Hours 

No 

Enter Y to load high school GPA and hours data or N 

to bypass this option. If this parameter is left blank, 

the value defaults to N. 

Y 

N 

Load GPA and hours 

Do not load GPA and hours 






SSN or Generated ID Yes Enter S to use the SSN from the data file or G to 

always generate a new ID. 

Note: If the ID is generated or the incoming data is 

all zeros (as is the case with some ACT records), the 

process will display GEN in the ID field on the output 

report when the report is executed in audit mode. 

The actual generated IDs will display on the output 

report when the report is executed in update mode. 

S 

G 

Use SSN from data file 

Generate new ID 

Update Existing SSN Yes Enter Y to update the existing SSN in the SPBPERS 

table with the SSN from the data file or N to not 

update the existing SSN. 

If you enter Y and an SSN already exists for the 

person in Banner, that existing SSN will then be 

stored in the SSN/SIN/TIN History Table 

(GURHLOG) and will be viewable on the SSN/SIN/ 

TIN History Form (GUITINH) 

Y 

N 

Update existing SSN 

Do not update existing SSN 





Report Sample—AMCAS Data Load Process (SAPAMAL) 

31-MAR-2005 20:24:17 BANNER University 

AMCAS Data Load Process SAPAMAL 

904162508 Grivetti, Janice AAMC ID match/No SSN match. Using Banner ID. 

Grivetti, Janice Bio/Demo Data Updated. 

Grivetti, Janice Address Data Added. 

Grivetti, Janice Telephone Data Added. 

Grivetti, Janice International Data Added. 

Grivetti, Janice Application Added. 

Grivetti, Janice Supplemental Data Added. 

Grivetti, Janice GPA 1BCPM Data Added. 

Grivetti, Janice GPA 1AO Data Added. 

Grivetti, Janice GPA 1TOT Data Added. 















Grivetti, Janice Course Summary 1BCPMH Data Added. 

Grivetti, Janice Course Summary 1AOH Data Added. 










Grivetti, Janice Test Type VR Added. 

Grivetti, Janice Test Type PS Added. 

Grivetti, Janice Test Type WS Added. 

Grivetti, Janice Test Type BS Added. 

Grivetti, Janice Test Type VR Added. 

Grivetti, Janice Test Type PS Added. 

Grivetti, Janice Test Type WS Added. 

Grivetti, Janice Test Type BS Added. 

Grivetti, Janice Email Address added. 

906273609 Kwon, Soo Hyun No SSN/AAMC ID match. New ID. 

Kwon, Soo Hyun Bio/Demo Data Added. 

Kwon, Soo Hyun Address Data Added. 





SAPAMAL (continued) 

Kwon, Soo Hyun Telephone Data Added. 

Kwon, Soo Hyun International Data Added. 

Kwon, Soo Hyun Application Added. 

Kwon, Soo Hyun Supplemental Data Added. 

Kwon, Soo Hyun Prior College Data Added. 

Kwon, Soo Hyun Prior College Degree Data Added. 01-MAY-2001 

Kwon, Soo Hyun Prior College Major Data Added. 

Kwon, Soo Hyun Prior College Degree Data Added. 01-MAY-2002 

Kwon, Soo Hyun Prior College Major Data Added. 

Kwon, Soo Hyun GPA 1BCPM Data Added. 

Kwon, Soo Hyun GPA 1AO Data Added. 

Kwon, Soo Hyun GPA 1TOT Data Added 



Kwon, Soo Hyun GPA 2TOT Data Added. 













Kwon, Soo Hyun Course Summary 1BCPMH Data Added. 

Kwon, Soo Hyun Course Summary 1AOH Data Added. 











Kwon, Soo Hyun Course Summary 8PFPH Data Added. 

Kwon, Soo Hyun Test Type VR Added. 

Kwon, Soo Hyun Test Type PS Added. 

Kwon, Soo Hyun Test Type WS Added. 

Kwon, Soo Hyun Test Type BS Added. 

Kwon, Soo Hyun Email Address added. 

Kwon, Soo Hyun AAMC ID Data Added. 

908384706 Ettekal, Yashar REJECT: No Last Name match. 






902162504 Jordan, Christopher SSN match. Using Banner ID. 

Jordan, Christopher Bio/Demo Data Updated. 

Jordan, Christopher Address Data Added. 

Jordan, Christopher Telephone Data Added. 

Jordan, Christopher International Data Added. 

Jordan, Christopher Application Added. 

Jordan, Christopher Supplemental Data Added. 

Jordan, Christopher Prior College Data Added. 

Jordan, Christopher Prior College Degree Data Added. 

Jordan, Christopher Prior College Major Data Added. 

Jordan, Christopher GPA 1BCPM Data Added. 

Jordan, Christopher GPA 1AO Data Added. 

Jordan, Christopher GPA 1TOT Data Added. 













Jordan, Christopher Course Summary 1BCPMH Data Added. 

Jordan, Christopher Course Summary 1AOH Data Added. 









Jordan, Christopher Course Summary 8PFPH Data Added. 

Jordan, Christopher Test Type VR Added. 

Jordan, Christopher Test Type PS Added. 

Jordan, Christopher Test Type WS Added. 

Jordan, Christopher Test Type BS Added. 

Jordan, Christopher Email Address added. 

Jordan, Christopher AAMC ID Data Added. 

907984923 Kordy, Kattayoun AAMC ID match/No SSN match. Using Banner ID. 

Kordy, Kattayoun Bio/Demo Data Updated. 

Kordy, Kattayoun Address Data Added. 

Kordy, Kattayoun Telephone Data Added. 

Kordy, Kattayoun International Data Added. 

Kordy, Kattayoun Application Added. 

Kordy, Kattayoun Supplemental Data Added. 

Kordy, Kattayoun Prior College Data Added. 

Kordy, Kattayoun Prior College Degree Data Added. 01-OCT-2003 






Kordy, Kattayoun Prior College Major Data Added. 


Kordy, Kattayoun Prior College Degree Data Added. 



Kordy, Kattayoun Prior College Degree Data Added. 


Kordy, Kattayoun GPA 1BCPM Data Added. 

Kordy, Kattayoun GPA 1AO Data Added. 

Kordy, Kattayoun GPA 1TOT Data Added. 










Kordy, Kattayoun Course Summary 1BCPMH Data Added. 

Kordy, Kattayoun Course Summary 1AOH Data Added. 







Kordy, Kattayoun Test Type VR Added. 

Kordy, Kattayoun Test Type PS Added. 

Kordy, Kattayoun Test Type WS Added. 

Kordy, Kattayoun Test Type BS Added. 

Kordy, Kattayoun Test Type VR Added. 

Kordy, Kattayoun Test Type PS Added. 

Kordy, Kattayoun Test Type WS Added. 

Kordy, Kattayoun Test Type BS Added. 

Kordy, Kattayoun Email Address added. 





31-MAR-2005 20:24:17 BANNER University 

AMCAS Data Load Process SAPAMAL 

RPTNAME: SAPAMAL 

SCHOOL CODE: 118 

APPLICATION TERM REQUIRED: 200510 

PROGRAM: 

LEVEL: MD 

COLLEGE: MD 

DEGREE: MD 

MAJOR: MED 

CAMPUS: M 

STUDENT TYPE: N 

ADDRESS TYPE: PR 

AUDIT/UPDATE: U 

MATCH ON ID AND LAST NAME ONLY: N 

CREATE NEW RECORDS: Y 

UPDATE PREVIOUS APPLICATION YEAR FIELDS (Y/N): Y 

UPDATE INFORMATION FOR CHANGED RECORDS: Y 

USE RULES FOR CHECKLIST ONLY: N 

DO YOU WANT TO LOAD HS GPA AND HOURS (Y/N): N 

USE SSN OR GENERATE ID (S/G): S 

UPDATE EXISTING SSN (Y/N): N 

* * * REPORT CONTROL INFORMATION - SAPAMAL - Release 7.1 * * * 

Counts reflect results of latest run of SARAMAL report program for this data. 

Number of NEW Persons Processed: 1 

Number of MATCHED Persons Processed: 3 

Number of REJECTED Persons Processed: 1 

Total Number of Persons Processed: 5 






Description 

This process loads data from a search input file (for example, College Guide/SSS, or Peterson) or a test score report file (for 

example, SAT, ACT, GRE, or GMAT) to the following temporary tables: SRTIDEN, SRTPERS, SRTTELE, SRTADDR, 

SRTTEST, SRTPREL, SRTHSCH, SRTPCOL, SRTEMAL. The data in these tables is available using the Search Tape View 

(SRVPREL). The process also creates an audit report detailing the status of each record on the input file. 

If the record exists, then the match status on the search tape table for this record is set to M (Matched). If the record is not 

matched, then the match status is set to N (New). If the record is considered a suspense (for example, some elements are 

matched but not enough to be considered a match), then the match status is set to S (Suspense). 

You should do the following in preparation for running SRTLOAD: 

• Set up the corresponding interface (INFC) code value on STVPREL. 

• Assign the appropriate matching source code to the interface code on STVINFC. 

• Set up rules on SOTCNVT for the conversion of the tape values to the SCT Banner validation table values. 

The codes listed below are compared to SOTCNVT for conversion to SCT Banner values and for default values. 

If the code on the tape is blank, the value “*” is matched against SOTCNVT. If the tape value is not blank, the incoming value 

is matched against SOTCNVT. If there is no available conversion for the tape value or the tape value is not valid on the SCT 

Banner validation table, the literal DEFAULT is matched against SOTCNVT. If this is not available, then an error message is 

printed on the report. 

On SOTCNVT, the following tables are validated: NATN, CITZ, STAT, INTS, ETHN, DEGC, MAJR, RELG, CNTY, TADM, 

TERM, DEPT, VTYP, EDLV, and EGOL. 

The exceptions for determining conversions and default values are for the major code, interest code, term code, level code, 

campus code, contact type code, source code, address type code, email type code, and telephone code. SRTLOAD will analyze 

the high school or prior college graduation date against SOTCNVT to determine the term code. 





If there is no match, the value from the Term Code parameter is used. The level code, address type code, telephone type 

code, and email code inserted will always be from the input parameter value. If no source code or contact type code are 

entered in the input parameters, the value from STVINFC for the interface will be used. In addition, the test score source 

inserted on test scores will be the one created on STVINFC. 

The fields INTS and MAJR can have multiple values in multiple fields for some types of tape loads. The * and DEFAULT 

functionality will only work on the first match attempt for the field MAJR(MAJR1). If there are values in fields MAJR2, MAJR3, 

or MAJR4, the process will attempt to match the values against the SOTCNVT crosswalk and the values in STVMAJR. If no 

match is found for these, the output report will display an error indicating the field and the error. INTS will not use the * or 

the DEFAULT functionality due to the possibility of many records existing on the incoming data file. 

The default values on SRAPRED are used if the corresponding parameter on SRTLOAD is blank. If the corresponding 

parameter on SRTLOAD is blank, SRTLOAD will first use the data that exists on the incoming tape for such fields as Term, 

Major, etc. If no value exists on the tape, then SRTLOAD will use the data in the parameter. If no value exists in the parameter, 

SRTLOAD will use the value on SRAPRED. Certain fields (i.e., Tape Source, SBGI Code, etc.) will be populated from STVINFC 

if no value exists on SRAPRED. 


Data File Name Yes Enter the file name/path containing the search tape 

records or test score tape records to be loaded (for 

example, /tmp/search.data). 

Electronic Prospect 

Code 

Yes 

Enter the electronic prospect code to be used in the 

load. 

Electronic Prospect Validation Form 

(STVPREL) 

Tape ID No Enter the additional ID of the tape, which is useful if 

multiple tapes are being loaded for the same 

electronic prospect code. 






SSN or Generated ID Yes Enter S to use the SSN from the data file or G to 

always generate a new ID. 

Note: If the ID is generated or the incoming data is 

all zeros (as is the case with some ACT records), the 

process will display GEN in the ID field on the output 

report when the report is executed in audit mode. 

The actual generated IDs will display on the output 

report when the report is executed in update mode. 

S 

G 

Use SSN from data file 

Generate a new ID 

Term Code No Enter the term code that will be used if a term code 

cannot be determined from the high school 

graduation date on the search or test score tape and 

the SOTCNVT conversion rules, or if no term has 

been entered on SRAPRED. 

Level Code Yes Enter the level code that will go on the prospect’s 

recruit record. 

Campus Code No Enter the campus code that will go on the prospect’s 

recruit record if entered. 

Contact Code No Enter the contact code that will go on the prospect’s 

recruit record. 

Source Code No Enter the source/background institution code that 

will go on the prospect’s recruit record. 


(STVTERM) 

Level Code Validation Form 

(STVLEVL) 

Campus Code Validation Form 

(STVCAMP) 

Contact Type Code Validation Form 

(STVCTYP) 

Source/Background Institution Code 

Validation Form (STVSBGI) 






Address Type Code Yes Enter the address type code for the prospect’s 

address to be used. If no value is entered, MA is the 

default. 

Address Type Code Validation Form 

(STVATYP) 

Email Type Code No Enter the email type code for the prospect’s email. E-mail Address Type Validation Form 

(GTVEMAL) 

Print Test Scores Yes Enter Y to print test scores on the report while 

processing test score records. Enter N to suppress 

printing test scores. 

Y 

N 

Print test scores 

Do not print test scores 

Default Test Month No Enter the default month for the test. Valid values are 

01 - 12. 

Telephone Type Code No Enter the default telephone type code for the 

prospect’s recruit record. 

Telephone Type Validation Form 

(STVTELE) 

Run Mode Yes Enter U to update the database or A to run an audit 

report. 

Note: Run the process in audit mode to determine 

which values are missing from SCT Banner (for 

example, high school codes, major codes). If these 

values are not created in SCT Banner and converted 

using SOTCNVT where appropriate, the value will 

not be loaded into SCT Banner. 

U 

A 

Update the database 

Produce audit report 





Report Sample—Electronic Prospect Load (SRTLOAD) 

12-APR-2005 20:32:22 BANNER University Page: 1 

Electronic Prospect Load SRTLOAD 

ID NAME SBGI GRD YR STREET CITY ST ZIP/CNTRY BIRTH DATE 

*GEN* Soe, Lark 1527 Samuel,s Ave. Malvern PA 19312 12/01/1975 

TEST CODE TEST DATE SCORE 

S01 220 

S01 350 

S01 450 

*GEN* Lob, Jane 1452 Holland Street Jackson MI 20345 11/02/1973 


S01 750 

S01 800 

S01 650 

*GEN* Lampli, Dwane 12 Billard Lane Townson MD 21617 10/03/1970 


S01 650 

S01 760 

S01 450 

*GEN* Ruean, Wanda 687 Juniper Drive Alamber AL 23145 08/05/1990 


S01 570 

S01 765 

S01 800 





12-APR-2005 20:32:22 BANNER University Page: 2 

Electronic Prospect Load SRTLOAD 

RPTNAME: SRTLOAD 

FILENAME : /export/home/dflath/delmm6.dat 

TAPE CODE : DAYNAM2 Dayna delimeter & marker 

PREL CODE : DFTM 

INFC CODE : DWEP 

TAPE ID : Tape6 

TERM CODE : 200510 * Value Input * 

LEVEL CODE : UG 

SSN,GENERATE ID : S 

CAMPUS CODE : 

CONTACT CODE : WEB * Value From STVINFC Used * 

SOURCE CODE : WEBPRO * Value From STVINFC Used * 

ADDRESS TYPE : PR 

EMAIL TYPE : HOME 

TELE TYPE : PR 

PRINT TESTS : Y 

RUN MODE : A 

* * * REPORT CONTROL INFORMATION - SRTLOAD - Release 7.1 * * * 

Number of Records Read from Tape: 4 

Total of Prospects Loaded : 4 

Total of PIDMs Matched : 0 

Total of Conversion Errors : 0 








Section 3 Fee Assessment Drop/Delete Processing - Functional 

Overview 

Section 3 Fee Assessment Drop/Delete Processing - 

Functional 


Overview 

This enhancement contains updates for the drop/delete (DD) process for fee 

assessment that correct a number of problem resolutions. It also includes the 

delivery of a new table and table changes to several tables used in fee assessment. 

Some of the changes are required for the drop/delete modifications, while others 

are necessary to maintain data integrity and data consistency. 

A new fee assessment report is also being delivered. The report produces a basic 

summary of learner data that may have been used as assessment rule criteria. This 

information can be used for assessment verification and can assist in 

troubleshooting assessment results. 

A set of scripts is delivered to help in collecting fee assessment-related information 

for a specific term/student ID, so users can communicate their data setup when 

reporting issues to the ActionLine and potentially examine their rules to verify setup 

and assist in troubleshooting issues at their institution. 

Corrections for problem resolutions: #95159, #98383, #90228, and #92891 are 

included in this release. RPE #43856 is also included. 

Updated Functionality for the Drop/Delete Process 

This release provides updates to drop/delete (DD) processing in fee assessment. 

Two distinct problem resolutions for the SFKFEE1 package are related to this 

processing. One solution has been developed to enhance the drop/delete process 

and resolve these issues. 

The two issues are: 

1. When a student dropped a course and moved from a flat hours rule (flat 

charge) to a per credit hour rule, and then a drop/delete was performed on 

another course, incorrect results were received. (#95159) 

2. Incorrect refunding was occurring for fee assessment rules that had flat and 

overload charges when a student moved out of overload range after some 





courses had been dropped/deleted. Initially, if a student was in an overload 

range, the fees were assessed correctly. Later in the process, courses were 

dropped/deleted completely (for example, due to entry error), which took the 

student out of overload range and into the flat range. Re-running fee 

assessment did not correctly reverse the overload charges. (#98383) 

Processing dropped/deleted (DD) courses in fee assessment now treats the 

assessment as if registration for the course that is being dropped/deleted never 

occurred. When students have qualified for a flat charge rule in the past and a 

drop/delete had occurred since the last assessment, the assessment process needed 

to re-assess the student from the top down, and in essence start over with the 

assessment. Fee assessment will now go back and recalculate the student's 

assessment and make the appropriate adjustments to fee assessment and the 

student's account. This top down assessment methodology will occur for flat charge 

refunding as it already does for refund by course processing. Reassessment will need 

to be re-run for each refund interim to determine the correct assessment. Fee 

assessment processing on all registration status codes that do not count in 

assessment will be treated in the same manner as with the drop/delete processing. 

To accomplish this, fee assessment will create intermediate assessment audit rows in 

SFRFAUD without posting any changes to accounting. The following will take place: 

1. Assessment processing will check to see if the student has ever met a flat charge 

rule and has had a drop/delete issued since the last assessment was run. 

2. Assessment processing will then select all registration records with a status code 

where STVRSTS_INCL_ASSESS is set to Y as RE. The liability for each course will 

be stored in SFTFEES as the full billing hours with 100% liability. 

3. The SFTFEES rows will be processed, and assessment rule evaluation 

performed. 

4. The assessment liability will be stored in SFRFAUD using a 

SFRFAUD_ASSESS_RFND_PENLTY_CDE value of D. 

5. The SFTFEES rows will be deleted. 

6. Assessment will then proceed to perform regular assessment processing. 

Examples of Drop/Delete Processing 

The following examples illustrate the new drop/delete processing. 

Example 1: 

Drop/delete a course that has a status of RE, and the student remains in the per 

hour range. The flat hour range is 12 hours with no overload fee. 

1. The student’s initial registration is for 15 hours and is assessed. 

• The student is liable for 15 hours. 





2. The student drops 3 hours during a 90% refund interim and is assessed. 

• The student remains in the flat hour range and has no change in 

assessment. The student is currently liable for 12 hours. 

3. The student drops an additional 3 hours during a 50% refund interim and is 

assessed. 

• The student drops out of the flat hour range and into the per hour 

assessment. The flat fee assessed will be reversed, and the per hour fee will 

be assessed. The student is liable for 10.5 hours (9 non-dropped hours, 

plus 50% of the 3 dropped hours (1.5)). 

4. The student drops/deletes an additional 3 hours and is assessed. 

• This is the point where the error occurred. However, the following should 

now occur at this point in the process. 

When the student drops/deletes the course, the assessment will go back and reassess 

the student as if they were never registered for the last 3 hours that were dropped/ 

deleted. The assessment process will calculate the student's assessment as if the 

following had occurred: 

1. The student's initial registration would be considered for 12 hours. 

• The student is in the flat hour range and is liable for 12 hours. 

2. The student drops 3 hours during a 90% refund interim. 

• The student drops out of the flat hour range and into the per hour range. 

The flat fee assessed will be reversed, and the per hour fee will be assessed. 

The student is liable for 9.3 hours (9 non-dropped hours, plus 10% of the 

3 dropped hours (.3)). 

3. The student drops an additional 3 hours during a 50% refund interim. 

• The student stays in the per hour range. A credit will be applied to the 

student's account for a percentage of the course that was dropped. The 

student is liable for 7.8 hours (6 non-dropped hours plus .3 liable hours 

from the previous drop, plus 50% of the current 3 dropped hours (1.5)). 

4. The end result is that the student is liable for 7.8 hours and is assessed at a per 

hour rate. 

Example 2: 

Drop/delete a course that was previously dropped, and student stays in per hour 

range. The flat hour range is 12 hours. 










The student is liable for 9.3 hours (9 non-dropped hours, plus 10% of the 

3 dropped hours (.3)). 

3. The student drops/deletes the same 3 hour course they withdrew from at 90% 

and is assessed. 




the student as if they were never registered for the last 3 hours that were dropped/ 




• The student is liable for 9 hours, and a per hour charge should occur. 

2. The end result is that the student is liable for 9 hours and is assessed at a per 

hour rate. 

Example 3: 

Drop/delete a course, and add another course at the same time that will cause the 

student to go back into the flat hour range and out of per hour range. The flat hour 

range is 12 hours. 






The student is liable for 9.3 hours (9 non-dropped hours, plus 10% for 3 

of the dropped hours (.3). (3 have no penalty because of flat rate.) 

3. The student drops/deletes another 3 hour course, adds 6 hours at the same 

time, and is assessed. 




the student as if they were never registered for the 3 hours that were dropped/ 






Registration Activity Processing Order 


• The student is in the flat hour range and is liable for 12 hours. 

2. The student drops 6 hours during a 90% refund interim. 


The student is liable for 6.6 hours (6 non-dropped hours, plus 10% for the 

6 of the dropped hours (.6)). 

3. The student adds 6 hours, is again in the flat hour range, and is now liable for 

12.6 hours (12 non-dropped and .6 (6*.10 of liability for dropped course)). 

4. The end result is that the student is liable for 12.6 hours and is assessed at a flat 

rate. 


Fee Assessment will process registration transactions in sequential order based on 

the registration status date. Since the processing is performed chronologically, the 

order in which adds and drops are entered may impact the determined student 

liable billing hours. 

Examples of Registration Activity Processing Order 

This set of examples uses a student rule that is set up for refund by course/flat 

charge refund processing. 

Detail 

Code 

Per Credit Min Max Liable Hrs 

From 

Liable Hrs 

To 

Flat Charge 

From 

Flat Charge 

To 

Flat Charge 

Amount 

Overload 

CRED 100.00 0 9999.99 .01 11.99 

FLAT 100.00 0 9999.99 12.00 99.99 12.00 99.99 1200 18 

Example 1: 

A student registers for 19 hours and qualifies for flat charging. The student's fee 

assessment audit is as follows: 





Detail Code FLAT 1200.00 

Rule Student Hours 19.0 

Rule Liable Hours 19.0 

Rule Flat Hour Range 12.0 - 99.99 

Overload Hours 1.0 

The student drops two hours during a 90% refund period and adds an additional 

four hours immediately following the drop. Both registration changes are 

performed in the same session. Fee assessment is then run. 

The student's new fee assessment audit is as follows: 






Calculation: 

Current Non-Dropped 

(ND) Hours 

Drop Two Hours at a 

90% Refund 

17.0 

0.1 

Penalty on one overload hour. No penalty on second 

hour because student remains in the flat charge hour 

range. 

19 previous liable hours - 18 overload start = 1 liable 

Overload hour: 1 * .1 = .1 

Add Four Hours 4.0 

Total Liable Hours 21.1 





Example 2: 

The student registers for 19 hours. The student's fee assessment audit is as follows: 






The student adds an additional four hours and drops two hours during a 90% 

refund period immediately following the add. Both registration changes are 


The student’s new fee assessment audit is as follows: 










Calculation: 


(ND) Hours 

17.0 

Add Four Hours 4.0 

17 ND hours + 4 new hours = 21 ND hours 

Drop Two Hours at a 

90% Refund 

0.2 

Penalty on two overload hours since student is registered 

in 21 hours. 

21 NDs > overload start 18 hours 

All dropped hours have overload liability. 

2 dropped hours * .1 = .2 


Example 3: 

The student registers for 14 hours and qualifies for flat charging. The student's fee 







The student drops four hours during a 90% refund period and adds an additional 

two hours immediately following the drop. Both registration changes are performed 

in the same session. Fee assessment is then run. 











Calculation: 


(ND) Hours 

Drop Four Hours at a 

90% Refund 

10.0 

0.2 

10% penalty on two of the four hours. No penalty on two 

of the hours, because two of the four hours were in the 

flat charge range. 

14 previous liable hours - 4 dropped hours = 10 

Start for flat is 12 hours. 

2 of the 4 dropped hours are in the flat range. 

2 remaining dropped hours have liability. 

2* .1 = .2 

Add 2 Hours 2.0 


Example 4: 

The student registers for 14 hours and qualifies for flat charging. The student's fee 











The student adds an additional two hours and drops four hours during a 90% 

refund period immediately following the add. Both registration changes are 








Calculation: 


(ND) Hours 

4.0 

Add 2 Hours 2.0 

14 + 2 = 16 

Drop Four Hours at a 

90% Refund 

0.0 

No penalty on any of the dropped hours, as student is 

back in the flat hour range after the add. 


16 ND hours - 4 dropped hours = 12 




Changed Forms 

Changed Forms 

Class Attendance Roster Form (SFAALST) 

The SFRSTCR_ACTIVITY_DATE has been modified to include a timestamp. 

Class Roster Form (SFASLST) 

The SFRSTCR_ACTIVITY_DATE has been modified to include a timestamp. 

New Report 

Fee Assessment Report (SFRFEES) 

This report is used to assist in trouble shooting and debugging fee assessment 

processing. It is intended to be an efficient way to gather needed information when 

a question on arises on fee assessment. The report will be the primary method for 

the ActionLine to obtain contact data, (along with additional delivered SQL*Plus 

scripts). 

This report lists various data values stored for a student that have the potential to 

meet registration assessment rule criteria. The values displayed are for enrollment 

data, student data, curriculum data, course registration data, optional mock fee 

assessment data, previous and current fee assessment, and accounts receivable 

records. The report processes a single ID or a population selection for a term. This 

report may be used for assessment verification and can be helpful when 

troubleshooting assessment results. The supported parameters will be expanded in 

later releases to assist with reviewing assessment information. 

This report can also be used as a tool for institutions to evaluate their processing 

rules or check on a specific group of students. For example, an institution may want 

to update a rule. They could take a sample population selection, and then compare 

the current assessment with a mock assessment to determine if this change would be 

appropriate. Another potential use would be if a user wanted to review assessment 

results for students who have a specific drop registration status (i.e., DD). They 

would create a population selection containing these students, and run the report. 

This allows them to easily compare the current assessment to the previous one, and 

determine if the refund was performed correctly. 




Changed Process 

The following parameters are used with this process: 

• Term - Required, Enter the registration term for which fee assessment is to be 

reported. Valid values come from the Term Code Validation Form 

(STVTERM). 

• Student ID - Optional, Enter the ID of the student for which fee assessment is to 

be reported. 

• Application Code - Optional, Enter the code that identifies the general area for 

which the selection identifier was defined. Note: All or none of the population 


• Selection ID - Optional, Enter the code that identifies the population with which 

you wish to work. The selection identifier must be defined on the Population 

Selection Definition Rules Form (GLRSLCT). 

• Creator ID - Optional, Enter the user ID of the person who created the 

population rules. 

• User ID - Optional, Enter the user ID for the population selection. This is the 

ID of the user who selected the population of people. This may or may not be 

the same as the Creator ID. 

• Mock Fee Assessment Indicator - Required, Enter Y to process mock fee assessment 

or N to not process mock fee assessment. The default is N. 

• Mock Assessment Effective Date - Optional, Enter the date for the mock fee 

assessment in DD-MON-YYYY format. 

The Mock Assessment Effective Date parameter is the equivalent of the 

Assessment Date parameter in Registration Fee Assessment Process 

(SFRFASC). This parameter was created for future use and will be used to 

expand on the details of accounting transactions. 

• Assessment Detail Indicator - Required, Enter a value to select the level of report 

detail. Enter C for current detail, P for previous detail, or B for both kinds of 

information. The default is B. 

• Sort Order - Required, Enter a value to select the sort order for the output. Enter 

N for name order or I for student ID order. The default is N. 

Changed Process 

Purge Fee Assessment Audit Process (SFPFAUD) 

This process has been modified to prevent the intermediate assessment audit that is 

created to handle records with a status of DD from being purged. These interim 

records will not be purged until a flat charge rule qualification has re-occurred. This 

will ensure that future assessments will have accurate previous assessment records 

available for fee assessment processing. 




Report Sample 

The process deletes SFRFAUD rows for qualified students by assessment rule type 

(STUDENT, LEVEL, CAMPUS, ATTR). The processes has been updated to consider 

if a student has had prior flat rule qualification but has been reassessed due to 

having a drop/delete issued. Since the student's assessment in essence starts over 

when the drop/delete is realized by assessment, any prior assessment audit records 

that record prior flat charge rule qualification can be safely purged. 

SFPFAUD first determines if a drop/delete scenario has been handled by 

assessment. If it has, any assessment audit prior to the drop/delete being handled 

can be purged. The process checks to see if a date is found for when a drop/delete 

was handled, and then goes on to delete all assessment audit prior to the drop/ 

delete, making sure to retain the last assessment audit. 

Report Sample 



output. 




Report Sample 




Section 3 - Fee Assessment Drop/Delete Processing 

Sample Report 


Description 

This report is used to assist in trouble shooting and debugging fee assessment processing. It is intended to be an efficient way 

to gather needed information when a question on arises on fee assessment. The report will be the primary method for the 

ActionLine to obtain contact data, (along with additional delivered SQL*Plus scripts). 

This report lists various data values stored for a student that have the potential to meet registration assessment rule criteria. 

The values displayed are for enrollment data, student data, curriculum data, course registration data, optional mock fee 

assessment data, previous and current fee assessment, and accounts receivable records. The report processes a single ID or a 

population selection for a term. The report also lists a basic summary of learner data that may be used for assessment 

verification and can be helpful when troubleshooting assessment results. The supported parameters will be expanded in later 

releases to assist with reviewing assessment information. 

This report can also be used as a tool for institutions to evaluate their processing rules or check on a specific group of students. 

For example, an institution may want to update a rule. They could take a sample population selection, and then compare the 

current assessment with a mock assessment to determine if this change would be appropriate. Another potential use would be 

if a user wanted to review assessment results for students who have a specific drop registration status (i.e., DD). They would 

create a population selection containing these students, and run the report. This allows them to easily compare the current 

assessment to the previous one, and determine if the refund was performed correctly. 


Term Yes Enter the registration term for which fee assessment 

is to be reported. 


(STVTERM) 

Student ID No Enter the ID of the student for which fee assessment 

is to be reported. 




Sample Report 





entered. 











entered. 


(GLISLCT) 












Sample Report 


Mock Assessment 

Indicator 

Yes 

Enter Y to process mock fee assessment or N to not 

process mock fee assessment. The default is N. 

Y 

N 

Mock assessment 

No mock assessment 

Mock Assessment 

Effective Date 

No 

Enter the date for the mock fee assessment in DD- 

MON-YYYY format. 

This parameter is the equivalent of the Assessment 

Date parameter in Registration Fee Assessment 

Process (SFRFASC). This parameter was created for 

future use and will be used to expand on the details 

of accounting transactions. 

Assessment Detail 

Indicator 

Yes 

Enter a value to select the level of report detail. 

Enter C for current detail, P for previous detail, or B 

for both kinds of information. The default is B. 

C 

P 

B 

Current 

Previous 

Both 

Sort Order Yes Enter a value to select the sort order for the output. 

Enter N for name order or I for student ID order. 

The default is N. 

N 

I 

Order by name 

Order by student ID 

Report Sample—Fee Assessment Report (SFRFEES) — see the following pages 




Sample Report 

This sample shows population selection. 

PAGE 1 

SFRFEES 7.1 Banner University RUN DATE 26-JAN-2005 

200955 Fee Assessment Criteria Report RUN TIME 04:53 PM 

Term Student ID Student Name Message 

200955 A00003392 Arcuri, James 

Enrollment: Add Date ESTS Code/Date Last Assessment Date Activity Date 

26-JAN-05 EL 26-JAN-2005 00:00:00 26-JAN-2005 10:29:58 26-JAN-2005 10:29:58 

Student: Level Admit Term MAJR Program Rate Class STYP RESD Activity Date Attributes 

UG 199810 ART FPPC FR N R 26-JAN-2005 00:00:00 

Course: CRN CAMP Level PTRM RSTS Code/Date GMOD INSM SCHD Bill Waive Credits Attributes 

55016 M UG 1 RE 26-JAN-2005 08:12:40 S CLASS L 3.000 3.000 3.000 FEES 

55019 M UG 1 RE 26-JAN-2005 08:12:46 S L 3.000 3.000 3.000 FEES 


55008 M UG 1 RE 26-JAN-2005 10:27:03 S C 4.000 4.000 4.000 FEES 

Mock Assessment: 26-JAN-2005 16:53:04 

Course Liability: 

Bill TUI TUI FEE FEE 

CRN RSTS Code/Date PTRM LVL CAMP GMOD INSM SCHD Hrs Liab% Liab Hrs Liab% Liab Hrs 

55016 RE 26-JAN-2005 08:12:40 1 UG M S CLASS L 3 100 3 100 3 

55019 RE 26-JAN-2005 08:12:46 1 UG M S L 3 100 3 100 3 

55003 RE 26-JAN-2005 10:08:12 1 UG M S L 4 100 4 100 4 

55008 RE 26-JAN-2005 10:27:03 1 UG M S C 4 100 4 100 4 

Audit Seq Detail Description Amount Tran Date Rule Type/No CRN 

2 FLAT Tuition Flat 1,200.00 26-JAN-2005 STUDENT 2 

Net Audit Liability: 1,200.00 

Acct Srce Detail Description Amount CRN 

R CRED Tuition Per Credit 0.00 

R FLAT Tuition Flat 1,200.00 

Registration Accounting Total: 1,200.00 

Current Assessment: 26-JAN-2005 10:29:58 








Previous Assessment: 26-JAN-2005 10:08:39 


4 CRED Tuition Per Credit 1,000.00 26-JAN-2005 STUDENT 1 





Sample Report 

PAGE 2 




200955 A00003392 Arcuri, James 


R CRED Tuition Per Credit 1,000.00 


Rules: Crse Crse Crse From To From To Flat OL Hr Stud Stud Stud 

Type Seq Wv CAMP LEVL ATTR DETL Per Hr Min Max LiabHrs LiabHrs FlatHrs FlatHrs Amount StartPTRM LEVL MAJR Rate 

R STUDENT 1 N CRED 100.00 0.00 99999.00 0.01 11.99 FPPC 

R STUDENT 2 N FLAT 100.00 0.00 99999.00 12.00 99.00 12.00 99.00 1200.00 18.00 FPPC 


200955 A00003406 Carson, Heather 















55019 RE 26-JAN-2005 10:48:07 1 UG M S L 3 100 3 100 3 

55003 RE 26-JAN-2005 10:50:05 1 UG M S L 4 100 4 100 4 

55008 RE 26-JAN-2005 10:53:50 1 UG M S C 4 100 4 100 4 











Sample Report 

PAGE 3 




200955 A00003406 Carson, Heather 










2 CRED Tuition Per Credit 600.00 26-JAN-2005 STUDENT 1 

Net Audit Liability: 600.00 



Registration Accounting Total: 600.00 






200955 A00003389 Thomas, Lisa 



















Sample Report 

PAGE 4 




200955 A00003389 Thomas, Lisa 


55019 RE 25-JAN-2005 10:49:18 1 UG M S L 3 100 3 100 3 

55003 RE 25-JAN-2005 11:03:27 1 UG M S L 4 100 4 100 4 

55008 RE 25-JAN-2005 11:09:09 1 UG M S C 4 100 4 100 4 

55020 RE 26-JAN-2005 11:09:50 1 UG M S L 3 100 3 100 3 

55013 RE 26-JAN-2005 11:11:10 1 UG M S L 4 100 4 100 4 



























Processed: 3 




Sample Report 

PAGE 5 




Parameters have been entered via Job Submission. 


_____________________________ ________________ 


Term: 200955 

Student ID: 

Application name: STUDENT 

Selection name: TEMP 

Selection creator ID: PBERRY 

Selection user ID: PBERRY 

Run Mock Assessment: Y 

Mock Assessment Eff date: 

Assessment detail indicator: B 

Sort order: N 

Start date/time: 26-JAN-2005 04:53 PM 

End date/time: 26-JAN-2005 04:53 PM 




Sample Report 

This sample shows section and extension fees. 

PAGE 1 




200520 A00003379 Johnson, Paul 




GR 199810 ANTH MA-ANTHRO N R 21-JAN-2005 00:00:00 


10356 M GR 1 RE 21-JAN-2005 11:33:06 S TR L 3.000 3.000 3.000 0001 

10379 M GR RX 21-JAN-2005 11:38:01 S WEB L 2.222 .000 1.111 

10387 M GR DC 21-JAN-2005 12:21:05 S WEB L 3.000 3.000 .000 

10419 B UG 1 RE 27-JAN-2005 14:26:04 S WEB L 3.000 3.000 3.000 





10356 RE 21-JAN-2005 11:33:06 1 GR M S TR L 3 100 3 100 3 

10379 RX 21-JAN-2005 11:38:01 GR M S WEB L 2.222 100 2.222 100 2.222 

10387 DC 21-JAN-2005 12:21:05 GR M S WEB L 3 50 1.5 50 1.5 

10419 RE 27-JAN-2005 14:26:04 1 UG B S WEB L 3 100 3 100 3 


1 EXTN Extension Charge 125.00 27-JAN-2005 Extension Fee 10379 

2 COMP Computer Fees 28.00 27-JAN-2005 Section Fee 10356 

3 T101 Undergraduate Tuition 25.00 27-JAN-2005 Section Fee 10387 

4 MIS2 Misc. Charge - Aux. Srvc Rev. 2,022.11 27-JAN-2005 Section Fee 10419 

6 T101 Undergraduate Tuition 972.20 27-JAN-2005 STUDENT 16 

7 ACTF Activity Fee 20.00 27-JAN-2005 STUDENT 17 

8 T102 Graduate Tuition 1,344.40 27-JAN-2005 LEVEL 16 

9 ATH1 Athletic Fee 75.00 27-JAN-2005 



R ACTF Activity Fee 20.00 

R ATH1 Athletic Fee 75.00 

R COMP Computer Fees 28.00 

R EXTN Extension Charge 125.00 

R MIS2 Misc. Charge - Aux. Srvc Rev. 2,022.11 

R T101 Undergraduate Tuition 997.20 

R T102 Graduate Tuition 1,344.40 








Sample Report 

PAGE 2 




200520 A00003379 Johnson, Paul 




































R LEVEL 16 N GR T102 200.00 0.00 200000.00 0.01 9999.00 

R STUDENT 16 N T101 100.00 0.00 999999.00 0.01 9999.00 

R STUDENT 17 N ACTF 0.00 20.00 20.00 0.01 9999.00 

Processed: 1 




Sample Report 

PAGE 3 




Parameters have been entered via Job Submission. 


_____________________________ ________________ 


Term: 200520 

Student ID: A00003379 

Application name: 

Selection name: 

Selection creator ID: 

Selection user ID: 

Run Mock Assessment: Y 

Mock Assessment Eff date: 

Assessment detail indicator: B 

Sort order: N 

Start date/time: 27-JAN-2005 02:27 PM 

End date/time: 27-JAN-2005 02:27 PM 




Sample Report 




Section 4 Fee Assessment Registration Updates - Functional 

Overview 

Section 4 Fee Assessment Registration Updates - 

Functional 


Overview 

This enhancement contains problem resolutions related to swapping processing for 

refunding by course and updating existing registration status codes, as well as 

updates to open learning registration. Swapping is the ability to exchange course 

billing hours during a defined period of time without incurring a penalty. 

Corrections for problem resolutions: #92398, #95410, and #93021 are included in 

this enhancement. RPEs #35999 and #38431 are also included. 

Using Optional Swapping Processing with Refund by Course 

Users now have the ability to use optional swapping processing with refund by 

course refund processing. This satisfies problem resolution #92398. 

Swapping can be defined as the exchange (dropping and adding) of billing hours 

within the same day with no additional liability. This functionally is optional, and an 

institution can choose to invoke this functionally or use the current processing with 

liability for dropped hours. 

The Allow Swapping (Indicator) has been added to the Term Control Form 

(SOATERM), to allow an institution to turn on swapping on a term-by-term basis if 

desired. 

Note: Open learning courses are not considered in the swapping algorithm, as 

they carry their own refund method. 

Refund by Course Processing and Examples 

If a student drops and adds course billing hours on the same day during a refund by 

course refund period, assessment will only determine liability on the difference of 

the excess of dropped billing hours. This will allow an implicit 100% refund on the 

liable billing hours calculated for the offsetting drop. This may occur with any 

combination of hours. 





For example, the Total Billing Hours Dropped - Total Billing Hours Added = Net 

Billing Hours Dropped. 

If an intermediate assessment has occurred between the drop and add activity, fee 

assessment will post an adjusting entry for the difference for the appropriate detail 

codes to the student’s account. 

Here are eight examples that illustrate this. 

Example 1: A student drops a three hour course and adds a three hour course in 

the same day. 

A student drops three hours and adds three hours on the same day. The 

resulting hours are the same; therefore, no liability is associated with the 

dropped hours. 

(Drops - Adds = Net) (3-3=0) 

Considered swapping for three hours. The student has no liability for the 

dropped billing hours. 

Example 2: A student drops a three hour course and adds a two hour course and 

a one hour course in the same day. 

A student drops three hours and adds a two hour course and a one hour course 

on the same day. The resulting hours are the same; therefore, no liability is 

associated with the dropped hours. 

(Drops - Adds = Net) (3-(2+1)=0) 



Example 3: A student drops two, two hour courses and adds a four hour course 

on the same day. 

A student drops two, two hour courses and adds a four-hour course on the same 

day. The resulting hours are the same; therefore, no liability is associated with 

the dropped hours. 

(Drops - Adds = Net) ((2+2)-4=0) 

Considered swapping for four hours.The student has no liability for the 


Example 4: A student drops a three hour course and adds a three hour course 

and a two hour course on the same day. 





A student drops a three hour course and adds a three hour course and a two 

hour course on the same day. The resulting hours for the drop can be offset with 

a portion of the added hours; therefore, no liability is associated with the 

dropped hours. 

(Drops - Adds = Net) (3-(3+2)=-2) 



Example 5: A student drops a three hour course and adds two, two hour courses 

on the same day. 

A student drops three hours and adds two, two hour courses on the same day. 

The resulting hours for the drop can be offset with a portion of the added 

hours; therefore, no liability is associated with the dropped hours. 

(Drops - Adds = Net) (3-(2+2)=-1) 

Considered swapping for three hours.The student has no liability for the 


Example 6: A student drops a three hour course and adds a four hour course on 

the same day. 

A student drops three hours and adds a four hour course on the same day. The 

resulting hours for the drop can be offset with a portion of the added hours; 

therefore, no liability is associated with the dropped hours. 

(Drops - Adds = Net) (3-4=-1) 



Example 7: A student drops a four hour course and adds a two hour course in the 

same day. 

A student drops four hours and adds a two hour course on the same day. A 

portion of the resulting hours for the drop can be offset with the added hours; 

therefore, a penalty is assessed for only the hour dropped in excess of the added 

hours for the day. 

(Drops - Adds = Net) (4-2=2) 

Considered swapping for two hours. The student has liability for two of the four 


Example 8: A student adds two, three hour courses and later drops one of the 

courses on the same day. 




Manually Updating Existing Registration Status Codes 

A student adds two, three hour courses and later drops one of the courses on 

the same day. The resulting hours for the drop can be offset with a portion of 

the added hours; therefore, no liability is associated with the dropped hours. A 

100% implicit refund exists for three hours. The end result is that the student 

will be charged for only three of the hours added that day. 

(Drops - Adds = Net) (3-6=-3) 



Swapping and Section Fees Examples 

Section fees are not considered as part of swapping processing. If section fees are 

attached to a course that later is used for swapping, the section fee liability remains. 

Example 1: A student drops a three hour course that has a flat section fee 

attached during a 60% refund period and adds a three hour course in the same 

day. 

A student drops a three hour course that has a flat section fee attached during 

a 60% refund period and adds a three hour course in the same day. The 

resulting hours are the same; therefore, no liability is associated with the 

dropped hours for the fee rules, but the section fee has a 40% liability. 

Example 2: A student drops a three hour course that has a per billing hour 

section fee attached during a 60% refund period and adds a three hour course 

in the same day. 

A student drops a three hour course that has a per billing hour section fee 

attached during a 60% refund period and adds a three hour course in the same 

day. The resulting hours are the same; therefore, no liability is associated with 

the dropped hours for the fee rules, but the section fee has a 40% liability. 


Assessment processing will now work correctly when an existing registration status 

code (a non-dropped code) is overwritten/updated with the same value. This 

satisfies problem resolution #95410. 





If an existing course has the same registration status code (a non-dropped code) 

retyped over the existing code, no change in assessment should occur. If a course is 

changed from a lesser registration status to full registration status, any refund 

penalties or liability assessed need to be reversed. A new column, 

SFRSTCR_ASSESS_ACTIVITY_DATE, has been added to the SFRSTCR table to 

monitor this. 

The SFRSTCR table has been modified to capture a fee assessment activity date to 

determine if a course needs to be processed in the next assessment. If flat charge 

refunding is in effect for the assessment, as it is the only method of refunding that 

determines and processes registration changes that have occurred since the last 

assessment, and a user types over an existing code, reassessment was occurring for 

that section and should not have occurred. The date in the new 

SFRSTCR_ASSESS_ACTIVITY_DATE column is used to determine which registration 

records need to be selected for assessment. 

As part of the registration processing, if the registration record is newly added or 

has had a change in its registration status, the SFRSTCR_ASSESS_ACTIVITY_DATE 

field will be updated with the current date and time, so the fee assessment process 

will know that this record needs to be processed. The SFRSTCR record only will be 

selected for flat charge refund processing, if the SFRSTCR_ASSESS_ACTIVITY_DATE 

is greater than the SFBETRM_ASSESSMENT_DATE, which is the date when the student 

was last assessed. On those records that do not need to be processed, the 

SFRSTCR_ASSESS_ACTIVITY_DATE field will not be updated. 

Note: Institutions not using assessment flat charge rule definitions and flat 

charge refunding will not be impacted by this change. 

• If both the original course registration status code (STVRSTS) and the new 

course registration status code are for a non-dropped course (i.e., the course is 

being added), and the original add was already assessed, then the 

SFRSTCR_ACTIVITY_DATE field is always updated, but the 

SFRSTCR_ASSESS_ACTIVITY_DATE field is not updated, since the course is not 

newly added and does not need to be assessed. 

• If either the original course registration status code (STVRSTS) or the new 

course registration status code are for a dropped course, which is defined as the 

STVRSTS_WITHDRAW_IND is set to Y, then the following criteria checking is 

performed. 

• If the new course registration status code and the original course 

registration status code are equal (the SFTREGS_RSTS_CODE field value 

equals the original SFRSTCR_RSTS_CODE field value), registration 

processing checks to see if the date on the new course registration status 

code (SFTREGS_RSTS_DATE) is different from the date on the original 

record (SFRSTCR_RSTS_DATE). If they are different, then the student has 

made a change and may qualify for a different refund. This record needs 

to be re-evaluated, and therefore the SFRSTCR_ACTIVITY_DATE and the 

SFRSTCR_ASSESS_ACTIVITY_DATE must be updated, so next assessment 

picks up the change. 




Storing Related Values and Options 

• If the new course registration status code is for a dropped course and the 

original course registration status code is for an added course, the 

SFRSTCR_ACTIVITY_DATE and the SFRSTCR_ASSESS_ACTIVITY_DATE 

must be updated, so that the next assessment processes the drop. 

Storing Related Values and Options 

Fee assessment options were stored on both SOATERM and GTVSDAX. These 

options needed to be moved to one location so users could have a central place to 

set up their assessment controls for a term. Values and options related to fee 

assessment now reside solely on SOATERM. SOATERM and GTVSDAX have been 

modified to achieve this. 

The following changes have been made to the main window of SOATERM: 

• The Registration Fee Assessment section has been updated. 

• The new Allow Swapping (Indicator) has been added to this section. 

Check this box to use course/hours swapping in fee assessment. 

• The new Reverse Non Tuition/Fee Charges (Indicator) has been added 

to this section. Check this box to allow registration fee assessment to 

reverse non-tuition or non-fee charges for detail codes with a category 

code other than TUI or FEE. (This indicator replaces the GTVSDAX row 

for FAREVNRF.) 

• The Web Self-Service and Voice Response heading was updated to read “Web 

Self-Service, Voice Response and Partner Systems”. 

• Two new sections were added under the Web Self-Service, Voice Response and 

Partner Systems section: “Fee Assessment” and “Control Settings”. 

• The four fee assessment options are now grouped under the Fee Assessment 

heading. 

• The Print Bill and Master Web Term Control fields, as well as the Process Web 

Controls button have been moved from the Web Self-Service, Voice Response 

and Partner Systems section to the Control Settings section. 

• The Synchronize Partner Systems field has been moved from the Gradebook 

Parameters section to the Control Settings section. 




Updating Open Learning Registration Processes 

The following change has been made to GTVSDAX: 

• The FAREVNRF rule for the group code of FEE ASSESSMENT, with a description 

of Reverse Non-Refundable Fees, has been removed from GTVSDAX. 

Updating Open Learning Registration Processes 

Corrections have been made to open learning registration to resolve problem 

resolution #93021. 

The issue was that when a student dropped an open learning course with an 

extension prior to the beginning of that extension, an incorrect refund was given 

for the extension that was not a full 100%. 

This has been resolved through the addition of a new registration date that is 

assigned to the registration status code for the extension. This date is stored in the 

SFRAREG table, in the new SFRAREG_RSTS_DATE field. The new field will store the 

date when a course registration status code (STVRSTS) is created or updated for an 

extension record. This allows an extension record to have its own registration status 

date that is separate from the course registration status date. This date is used in the 

calculations for open learning refund processing. The Student Registration History 

and Extension Form (SFARHST) has been modified to display this date in the new 

Course Status Date field in the Registration Extensions window. 

Capturing Rule Data During Processing 

The Fee Assessment Audit Table (SFRFAUD) has been modified to capture rule data 

as static values at the time they are processed. This satisfies RPE #35999. 

RPE #35999 states that while using SFAFAUD to investigate a student's charges, 

when the amount for the charge on SFRRGFE has been changed, SFRFAUD records 

created before the change show the new PER_CREDIT_CHARGE amount (i.e., the 

updated SFFRGFE amount on the Fee Assessment Audit Detail window). It would 

be more accurate to store the PER_CREDIT_CHARGE amount on SFRFAUD, so that it 

can be displayed correctly on SFAFAUD. SFAFAUD has been updated to display this. 

New columns have been added to SFRFAUD to store the per credit charge amount 

used at the time the charge was calculated. Two scripts (sfrfaud1.sql and 

sfrfaud2.sql) are delivered to add the new table columns and comments to 

SFRFAUD to record the key SFRRGFE rule values as static values at the time the 

assessment is run. If the SFRRGFE rule values are updated after the assessment was 

run, the rule values in effect at the time of the assessment are preserved. 




Processing Amounts Greater Than 9999.99 

The new columns are: 

SFRFAUD_RGFE_PER_CRED_CHARGE 

SFRFAUD_RGFE_FLAT_FEE_AMOUNT 

SFRFAUD_RGFE_FROM_FLAT_HRS 

SFRFAUD_RGFE_TO_FLAT_HRS 

SFRFAUD_RGFE_CRSE_OL_START_HR 

In addition, new data columns have been added that will be used in a future release 

to capture and retain needed data for the correct processing of fee assessment 

refunds by enrollment status and the refund by total process. 

These new columns are: 

SFRFAUD_ESTS_TUI_LIAB_PERCENT 

SFRFAUD_ESTS_FEE_LIAB_PERCENT 

SFRFAUD_RBT_TUI_PENLTY_ PERCENT 

SFRFAUD_RBT_FEE_PENLTY_PERCENT 

These columns have been added for future use in fee assessment audit data 

recording when enrollment status refunds are in effect for an assessment. The 

outstanding issues with enrollment status refunding in assessment are slated for 

correction in a future release. The recording of the enrollment status liability 

percentages as part of the assessment audit when an enrollment status refund is in 

effect for the assessment will provide the ability for assessment processing to 

concisely determine if an enrollment status refund was previously processed, as well 

as if the refund percentage has changed since the previous refund was processed. 

Processing Amounts Greater Than 9999.99 

The SFRAFEE_AMOUNT table column has been expanded to handle numbers greater 

than 9999.99. In conjunction with this change, the associated fields on the SFAAFEE 

and SFAEFEE forms have also been modified to display the full field value. This 

satisfies RPE #38431. 

RPE #38431 requested that the SFRAFEE_AMOUNT field be able to handle amounts 

that are greater than 9999.99. This also affected SFAAFEE and SFAEFEE. 

The Amount column on the SFRAFEE table, the Amount field on SFAAFEE and the 

Charge field on SFAEFEE have been modified to display an expanded number value 

of NUMBER(12,2). Previously, they only displayed NUMBER(6,2). 




Using ActionLine Fee Assessment Scripts 

Using ActionLine Fee Assessment Scripts 

The fee assessment script set delivered for use by the ActionLine is discussed in the 

“Fee Assessment Drop/Delete Processing - Technical” section of this release guide. 

It is listed under “New Scripts” and then under “Fee Assessment Script Set”. Scripts 

in this set are also used to add the new columns discussed in the “Fee Assessment 

Registration Updates” enhancement. The following scripts are used to add these 

new columns. 

srsobterm.sql - Script to Identify Term Base Information 

This script adds the following new columns to SOBTERM: 

Column Name 

SOBTERM_ASSESS_SWAP_HRS_IND 

SOBTERM_ASSESS_REV_ NRF_IND 

SOBTERM_ASSESS_REG_GRACE_IND 

Column Heading in Report 

Swap Hours 

Reverse NRF 

Reg Grace 

srsfrareg.sql - Script to Identify Open Learning Registration Course 

Extension Information 

This script adds the following new column to SFRAREG, for use with the 

SFRAREG_RSTS_CODE: 

Column Name 

SFRAREG_RSTS_DATE 


RSTS Date 

srsfrstcr.sql - Script to Identify Student Registration Information 

This script adds the following new column to SFRSTCR, for use with the 

SFRSTCR_ADD_DATE: 

Column Name 

SFRSTCR_ASSESS_ACTIVITY_DATE 


Assess Activity Date 




Changed Forms 

srsfrfaud.sql - Script to Identify Registration Fee Assessment Audit 

Information 

This script adds the new enrollment status and refund by total columns to 

SFRFAUD: 

Column Name 



SFRFAUD_RBT_TUI_PENLTY_PERCENT 



ESTS TUI Liable Pcnt 

ESTS FEE Liable Pcnt 

RBT TUI Penlty Pcnt 

RBT FEE Penlty Pcnt 

Note: These SFRFAUD columns are for future use. 

srsfbetrm.sql - Script to Identify Student Enrollment Information 

This script adds the following new column to SFBETRM, for use with the 

SFBETRM_INITIAL_REG_DATE: 

Column Name 

SFBETRM_INITIAL_REG_DATE 


Initial Reg Date 

Note: The SFBETRM_INITIAL_REG_DATE column is for future use. 

srsfrafee.sql - Script to Identify Student Additional Fees Information 

This script verifies the selection and printing of the altered SFRAFEE_AMOUNT 

column. 

Changed Forms 

Crosswalk Validation Form (GTVSDAX) 

The FAREVNRF rule for the group code of FEE ASSESSMENT, with a description of 

Reverse Non-Refundable Fees, has been removed from GTVSDAX. This has been 

replaced by the new Reverse Non Tuition/Fee Charges (Indicator) on SOATERM. 




Changed Forms 

Registration Additional Fees Control Form (SFAAFEE) 

The Amount field has been modified to display an expanded number value. It used 

to display NUMBER(6,2). It now displays NUMBER(12,2) or values greater than 

9999.99. 

Registration Additional Fees Form (SFAEFEE) 

The Charge field has been modified to display an expanded number value. It used 

to display NUMBER(6,2). It now displays NUMBER(12,2)or values greater than 

9999.99. 

Registration Fee Assessment Audit History Form (SFAFAUD) 

This form has been modified so that existing fields use the new columns on 

SFRFAUD. 

Form Field 

PER_CRED_CHARGE 

FROM_FLAT_HR 

TO_FLAT_HR 

OVERLOAD_PER_CRED_CHARGE 

Uses Table Field 





Student Registration History and Extension Form (SFARHST) 

The Course Status Date field has been added to the Registration Extensions window. 

This field is used to display the registration date that is assigned to the registration 

status code for the course extension. This date is stored in the SFRAREG table, in 

the new SFRAREG_RSTS_DATE field. The new field will store the date when a course 

registration status code (STVRSTS) is created or updated for an extension record. 

This allows an extension record to have its own registration status date that is 

separate from the course registration status date. This date is used in the 

calculations for open learning refund processing. 

Term Control Form (SOATERM) 

The following changes have been made to the form to consolidate fee assessment 

options: 

The following changes have been made to the main window of SOATERM: 




Changed Forms 

• The Registration Fee Assessment section has been updated. 

• The new Allow Swapping (Indicator) has been added to this section. 

Check this box to use course/hours swapping in fee assessment. 

• The new Reverse Non Tuition/Fee Charges (Indicator) has been added 

to this section. Check this box to allow registration fee assessment to 

reverse non-tuition or non-fee charges for detail codes with a category 

code other than TUI or FEE. (This indicator replaces the GTVSDAX row 

for FAREVNRF.) 

• The Web Self-Service and Voice Response heading was updated to read “Web 

Self-Service, Voice Response and Partner Systems”. 

• Two new sections were added under the Web Self-Service, Voice Response and 

Partner Systems section: “Fee Assessment” and “Control Settings”. 

• The four fee assessment options are now grouped under the Fee Assessment 

heading. 

• The Print Bill and Master Web Term Control fields, as well as the Process Web 

Controls button have been moved from the Web Self-Service, Voice Response 

and Partner Systems section to the Control Settings section. 

• The Synchronize Partner Systems field has been moved from the Gradebook 

Parameters section to the Control Settings section. 



Section 5 Concurrent Curricula Phase 2 - Technical 

New Tables 

Section 5 

Concurrent Curricula Phase 2 - Technical 


New Tables 

Curriculum Term Parameter Global Temporary Table (SOTVCUR) 

This temporary table is only used for general student (learner) records to determine 

which curriculum record is to be used by the SOVLCUR or SOVLFOS views. A 

function called by the views calculates which curriculum record is the most current 

and sets the view’s Current Indicator. The term added to SOTVCUR defines the 

SGBSTDN effective term being processed, the default term being the highest 

SGBSTDN term. 

SOTVCUR_PIDM 

SOTVCUR_LMOD_CODE 

SOTVCUR_TERM_CODE 

NOT NULL NUMBER(8) 

NOT NULL VARCHAR2(15) 


This table was delivered in Release 7.0 but was not documented in the release guide. 

Curriculum Base Verification Global Temporary Table (SOTLCUR) 

This table is used to store the current curriculum during data entry of the 

curriculum on SAAQUIK, SRAQUIK, SAAADMS, SRARECR, SGASTDN, 

SHADEGR, and SFAREGS. 

SOTLCUR_PIDM 

SOTLCUR_SEQNO 

SOTLCUR_LMOD_CODE 

SOTLCUR_TERM_CODE 

SOTLCUR_KEY_SEQNO 

SOTLCUR_CACT_CODE 

SOTLCUR_PRIORITY_NO 

SOTLCUR_LEVL_CODE 

SOTLCUR_COLL_CODE 

SOTLCUR_DEGC_CODE 

SOTLCUR_TERM_CODE_CTLG 

SOTLCUR_CAMP_CODE 

SOTLCUR_PROGRAM 








VARCHAR2(2) 

VARCHAR2(2) 

VARCHAR2(6) 

VARCHAR2(6) 

VARCHAR2(3) 

VARCHAR2(12) 





Changed Tables 

Field of Study Verification Global Temporary Table (SOTLFOS) 

This table is used to store the current field of study for a curriculum during data 

entry of the curriculum on SAAQUIK, SRAQUIK, SAAADMS, SRARECR, 

SGASTDN, SHADEGR, and SFAREGS. 

SOTLFOS_PIDM 

SOTLFOS_LCUR_SEQNO 

SOTLFOS_SEQNO 

SOTLFOS_CACT_CODE 

SOTLFOS_LFST_CODE 

SOTLFOS_PRIORITY_NO 

SOTLFOS_MAJR_CODE 

SOTLFOS_DEPT_CODE 

SOTLFOS_TERM_CODE_CTLG 







VARCHAR2(4) 

VARCHAR2(4) 

VARCHAR2(6) 



Field of Study Table (SORLFOS) 

The comment on the SORLFOS_TMST_CODE field has been updated to read, “ TIME 

STATUS CODE: time status code to indicate the intent of the student’s pursuit of 

the field of study.” 

The sorlfos1.sql script is delivered to make this change. 

Curriculum Term Parameter Global Temporary Table (SOTVCUR) 

Inserts into this table have been changed to insert the SGBSTDN_TERM_CODE_EFF 

value instead of the end term. 

Changed Packages 

SAKDCSN 

The logic to calculate the Roll Curriculum to Academic History Indicator was 

removed so that the sb_curriculum.p_create API will manage the setting of this 

indicator. 





SAKMODS 

The p_create_recruit, p_create_applicant, p_create_student, and 

p_copy_lcur procedures were changed to send a value of D to the 

sb_curriculum.p_create p_roll_ind parameter. 

The procedures including: p_create_student, p_create_lfos, p_copy_lfos, 

and p_copy_lcur, were changed to call the new procedures 

soklcur.f_lfos_count_status and sokclur.f_lcur_count_status to set the 

curriculum activity status value (STVCACT) to INACTIVE and curriculum status 

value (STVCSTS) to OVERFLOW if the count of curriculum or field of study has been 

exceeded. 

SAKL010 

The call to the sb_curriculum.p_create API was changed to send a value of D to 

the p_roll_ind parameter. 

The function calls to soklcur.f_lcur_count_status and 

soklcur.f_lfos_count_status in the p_create_secondary procedure were 

added to set the curriculum activity status value (STVCACT) to INACTIVE and 

curriculum status value (STVCSTS) to OVERFLOW if the count of curriculum or 

field of study has been exceeded. 

SHKROLS 

The call to the sb_curriculum.p_create API was changed to send a value of D to 

the p_roll_ind parameter. This affects the grade roll process in SFAALST, 

SFASLST, and SHRROLL. 

The function calls to soklcur.f_lcur_count_status and 

soklcur.f_lfos_count_status in the grade roll procedures were added to set the 



exceeded. 

SOKLCUR 

The f_lcur_count_status and f_lfos_count_status functions have been 

added to the package for use with SOBLMOD maximum counts. 

The p_create_sotvcur procedure is now used to insert the effective term into 

SOTVCUR. 




Changed Procedures 

The conversion p_convert_curr was changed to call the new functions 

soklcur.f_lcur_count_status and soklcur.f_lfos_count_status to set the 



exceeded. 

The conversion p_convert_curr was changed to send a value of D for Admissions, 

Recruiting, and Outcome curriculum in the p_roll_ind parameters for the 

sb_curriculum.p_create API. 


p_create_recruit 

The sakmods.p_create_recruit procedure has been modified to use the new 

f_lcur_count_status and f_lfos_count_status functions. 

p_create_applicant 

The sakmods.p_create_applicant procedure has been modified to use the new 


p_create_student 

The sakmods.p_create_student procedure has been modified to use the new 


p_copy_lcur 

The sakmods.p_copy_lcur procedure has been modified to use the new 


p_copy_lfos 

The sakmods.p_copy_lfos procedure has been modified to use the new 






p_create_lfos 

The sakmods.p_create_lfos procedure has been modified to use the new 


p_create_secondary 

The sakl010.p_create_secondary procedure has been modified to use the new 


p_load_application_two 

The sakl010.p_load_application_two procedure has been modified to use the 

new f_lcur_count_status and f_lfos_count_status functions and to send a 

value of D for the Curriculum Roll Indicator in the sb_curriculum.p_create for 

the secondary curriculum. 

p_process_graderoll 

The shkrols.p_process_graderoll procedure has been modified to use the new 

f_lcur_count_status function and to send a value of D for the Curriculum Roll 

Indicator in the sb_curriculum.p_create for the secondary curriculum. 

p_process_fieldofstudy 

The shkrols.p_process_fieldofstudy procedure has been modified to use the 

new f_lfos_count_status function. 

p_convert_curr 

The soklcur.p_convert_curr procedure has been modified to use the new 


The soklcur.p_convert_curr procedure was changed to send a value of D for 

Admissions, Recruiting, and Outcome curriculum in the p_roll_ind parameters 

for the sb_curriculum.p_create API. 




Obsolete Procedures 

Obsolete Procedures 

copy_lcur 

The copy_lcur procedure is obsolete. It has been replaced by the 

sakmods.p_copy_lcur procedure. 

copy_lfos 

The copy_lfos procedure is obsolete. It has been replaced by the 

sakmods.p_copy_lfos procedure. 

New Functions 

f_lcur_count_status 

This function is used to change a curriculum record’s status to inactive when 

maximum counts have been exceeded on SOBLMOD. 

f_lfos_count_status 

This function is used to change a curriculum record’s activity status to INACTIVE 

and the curriculum status to OVERFLOW when maximum counts have been 

exceeded on SOBLMOD. 

New Scripts 

sorlfos1.sql 

This script is delivered to update a comment on the SORLFOS_TMST_CODE field in 

the Field of Study Table (SORLFOS). 




Changed Triggers 

sinvcsts1.sql 

This script is delivered to add the value OVERLOAD to STVCSTS. 


NEW_SORLCUR_INST 

This trigger has been modified to update SOTVCUR with the effective term. 

CURRICULUM_COMMIT 


VALIDATE_CURRICULUM 


Changed Object Library 

SOQOLIB 

This library has been modified to incorporate the Roll Learner radio group field on 

SGASTDN, SFAREGS, and SOILCUR. 

The sort order of the curriculum data in the “curriculum” and “field of study” blocks 

on SRARECR, SAAADMS, SGASTDN, SFAREGS, SHADEGR, and SOILCUR has 

been changed. 

The new sort order for the SORLCUR data is: 

• module 

• term code (if the module is not LEANER or OUTCOME 

• key sequence 

• current and active 

• priority 

• SORLCUR sequence (in descending order) 




Changed APIs 

The new sort order for the SORLFOS data is: 

• field of study (major, minor, concentration) 

• current and active 

• priority 

• SORLFOS sequence (in descending order) 

Changed APIs 

sb_curriculum 

The sort order for SORLCUR data in the sb_curriculum.f_query_current API 

has been changed to: 

• priority number 

• term code 

• sequence number (in descending order) 

The sb_curriculum.f_find_max_seqno API has been modified to select the 

general student record (SGBSTDN) that is current based on the SORLCUR term 

and the effective term. 

The sb_curriculum_rules_.p_validate_insert API has been modified to 

accommodate the new roll to curriculum value of D and the new processing rules 

for the learner effective term. 

sb_learner 

The p_delete was changed to send the general student effective term to 

soklcur.p_create_sotvcur. 

The procedure p_copy_learner was changed to send a NULL value to the 

academic standing term and code value. 




Seed Data 

Seed Data 

The following seed data is delivered with this release. 

Script Value Table 

sinvcsts1.sql OVERLOAD STVCSTS 




Seed Data 




Section 6 Loading Delimited Prospect Files - AMCAS Phase 1 - Technical 

New Tables 

Section 6 

Loading Delimited Prospect Files - AMCAS 

Phase 1 - Technical 


New Tables 

Tape file Delimiter Type Rules Table (SORDLIM) 

This table is used to store delimiters and/or markers that can be assigned to tape 

codes. 

SORDLIM_TAPE_CODE VARCHAR2(10) NOT NULL, 

SORDLIM_DELIMITER VARCHAR2(1) NOT NULL, 

SORDLIM_ACTIVITY_DATE DATE NOT NULL, 

SORDLIM_USER_ID VARCHAR2(30) NOT NULL, 

SORDLIM_SYS_REQ_IND VARCHAR2(1) NOT NULL, 

SORDLIM_MARKER 

VARCHAR2(1), 

SORDLIM_DATA_ORIGIN 

VARCHAR2 

Tape File Test Score Control Table (SRRTPTS) 

This table is used to store test codes that contain the "date taken", so they can be 

mapped to all the other test codes for which that date taken applies. 

SRRTPTS_TESC_CODE VARCHAR2(4) NOT NULL, 

SRRTPTS_TESC_CODE_DATE_ORIGIN VARCHAR2(4) NOT NULL, 

SRRTPTS_ACTIVITY_DATE DATE NOT NULL, 

SRRTPTS_USER_ID VARCHAR2(30) NOT NULL, 

SRRTPTS_SYS_REQ_IND VARCHAR2(1) NOT NULL, 

SRRTPTS_DATA_ORIGIN 

VARCHAR2(30) 

Changed Table 

Temporary Tape Name Table (SRTTPFD) 

The srttpdf_end_pos field in this table has been made nullable. 






SRKPREL 

SKRPREL has been modified to accommodate the new SAAERUL values/rules. 

SRKPRE1 

SRKPRE1 has been modified to accommodate the new SAAERUL values/rules. 

New Procedure 

srkcomm.insert_comm_plan 

The new package and procedure srkcomm.insert_comm_plan has been added to 

create communication plans. 

The following procedures have been added for use with the SORDLIM table: 

• sokd_sordlim0.sql 

• sokd_sordlim1.slq 

• sokb_datafile_delimiter0.sql 

• sokb_datafile_delimiter1.sql 

• sokb_datafile_delimiter_r0.sql 

• sokb_datafile_delimiter_r1.sql 

• sokb_datafile_delimiter_s0.sql 

• sokb_datafile_delimiter_s1.sql 

• sokd_srrtpts0.sql 

• sokd_srrtpts1.slq 

• sokb_datafile_test_score0.sql 

• sokb_datafile_test_score1.sql 

• sokb_datafile_test_score_r0.sql 

• sokb_datafile_test_score_r1.sql 

• sokb_datafile_test_score_s0.sql 

• sokb_datafile_test_score_s1.sql 




Changed Procedure 

Changed Procedure 

p_migrate_prospect 

This procedure has been updated to match the processing detailed in the process 

flows included in the “Loading Delimited Prospect Files - AMCAS Phase 1 - 

Functional” section of the release guide. 

New Indexes 

An index has been added to place a primary key constraint on the 

SORDLIM_TAPE_CODE. 

An index has been added to place a primary key constraint on the 

SRRTPTS_TESC_CODE. 

New Constraints 

A constraint has been added to place a foreign key constraint on the 

SORDLIM_TAPE_CODE. 

A constraint has been added to place a foreign key constraint on the 

SRRTPTS_TESC_CODEE. 

New APIs 

The following APIs are delivered in this release. 

Table Form API Object Name API Entity Name Task Performed 

SORDLIM SORDLIM sb_datafile_deli 

miter 

SRRTPTS SRATPTS sb_datafile_test_ 

score 

FILEDELIMETER 

FILETESTSCORE 

Maintains datafile file 

delimeters 

Maintains date origins for 

STVTESC codes 




New Scripts 

New Scripts 

The following scripts are delivered with this release. 

Script Table Description 

sinserul.sql SARERUL Inserts rules into SAAERUL 

sordlim1.sql SORDLIM Creates new Tape file Delimiter Type Rules 

Table (SORDLIM) 

sordlim2.sql SORDLIM Adds Foreign Key to STVTAPE 

sordlim3.sql SORDLIM Adds Primary Key to SORDLIM 

sordlim4.sql SORDLIM Adds comments to SORDLIM 

srttpdf1.sql SRTTPFD Modifies SRTTPFD to make 

srttpdf_end_pos nullable 

srrtpts1.sql SRRTPTS Creates new Tape File Test Score Control 

Table (SRRTPTS) 

srrtpts2.sql SRRTPTS Adds Foreign Key to STVTESC 

srrtpts3.sql SRRTPTS Adds Primary Key to SRRTPTS 

srrtpts4.sql SRRTPTS Adds comments to SRTTPFD 

sintpts1.sql SRRTPTS Inserts seed data for SRTTPFD 



Section 7 Fee Assessment Drop/Delete Processing - Technical 

New Table 

Section 7 Fee Assessment Drop/Delete Processing - 

Technical 


New Table 

Registration Drop-Delete Collector Table For Fee Assessment 

(SFRREDG) 

This table is used to temporarily house dropped and deleted registration records 

(SFRSTCR) until they are processed by fee assessment. Once fee assessment 

processes the dropped/deleted courses, the collector records will be deleted from 

the table. 

Registration processing uses SFTREGS as a work pad before posting registration 

changes to SFRSTCR. The post-update and post-delete triggers on SFRSTCR post 

the records to SFRSTCA. The registration process then performs the following: 

• SFRSTCR rows are copied to SFTREGS. 

• Registration changes (add, drops) are processed, and registration edit checks 

are performed. 

• Statuses are checked for a value of DD equals Remove (SFTREGS_REMOVE_IND is 

set to Y), after all errors have been cleared. 

Then the following takes place: 

• Before the SFRSTCR row is deleted where the SFTREGS_REMOVE_IND is 

set to Y, the SFRSTCR_RSTS_CODE is updated with the drop/delete student 

course registration code (STVRSTS), and the SFRSTCR_REMOVE_IND is set 

to Y. (The post-update trigger on SFRSTCR is updated to not write this 

row to SFRSTCA.) 

• The record is inserted into the SFRREGD collector table, and then it is 

deleted from SFRSTCR. 

• The registration audit record can then be written after the record has 

been deleted from SFRSTCR. 





The following columns are in this table: 

SFRREGD_TERM_CODE NOT NULL VARCHAR2(6) 

SFRREGD_PIDM NOT NULL NUMBER(8) 

SFRREGD_CRN NOT NULL VARCHAR2(5) 

SFRREGD_USER NOT NULL VARCHAR2(30) 

SFRREGD_ACTIVITY_DATE NOT NULL DATE 

SFRREGD_RSTS_CODE 

VARCHAR2(2) 

SFRREGD_RSTS_DATE 

DATE 

SFRREGD_BILL_HR 

NUMBER(7,3) 

SFRREGD_WAIV_HR 

NUMBER(7,3) 

SFRREGD_CREDIT_HR 

NUMBER(7,3) 

SFRREGD_ADD_DATE 

DATE 

SFRREGD_LEVL_CODE 

VARCHAR2(2) 

SFRREGD_CAMP_CODE 

VARCHAR2(3) 

SFRREGD_SCHD_CODE 

VARCHAR2(3) 

SFRREGD_PTRM_CODE 

VARCHAR2(3) 

SFRREGD_GMOD_CODE 

VARCHAR2(1) 


Student Course Registration Repeating Table (SFRSTCR) 

The SFRSTCR _ERROR_FLAG field has been changed. It will be set to X when the 

Remove Record function is performed, and the record is allowed to be removed. 

The field is set to X to handle the needed data processing until the SFRSTCR record 

is deleted. 

The sfrstcr1.sql script is delivered to add a new column comment on the 

SFRSTCR _ERROR_FLAG. 

The SFRSTCR _ERROR_FLAG field identifies an error associated with the registration 

of a CRN. Valid values are F (Fatal), D (Do not count in enrollment), L (Waitlisted), 

O (Override), W (Warning), and X (Delete). (X is only used by the SFRSTCR POST 

UPDATE database trigger). 

The SFRSTCR_ACTIVITY_DATE has been modified to include a timestamp when 

grades are processed using the SFAALST and SFASLST forms. The timestamp was 

previously missing and was set to 00:00:00 by default. 

Fee Assessment Audit Table (SFRFAUD) 

The sfrfaud1.sql script is delivered to add new column comments on the 

SFRFAUD_ASSESS_RFND_PENLTY_CDE. 





The SFRFAUD_ASSESS_RFND_PENLTY_CDE field is code that indicates how the audit 

record originated. Valid values are A (Assessment), D (Drop/delete occurred since 

last assessment - flat charge refunding only), E (Course extension), I (Informational 

record), N (Non-dropped hours), P (Penalty), and R (Refund). 


SFKEDIT1 - Package Body for Registration Edits 

This package has been modified to track dropped/deleted registration records in 

SFRSTCA, when the SFRSTCR record is physically removed (DD equals Remove). 

The SFTREGS record uses the SFTREGS_REMOVE_IND flag to indicate that the course 

is to be deleted. 

Currently, when SFTREGS data is processed and moved to SFRSTCR, it checks for 

courses with the flag set in SFTREGS and proceeds to delete those rows from 

SFRSTCR. The post-delete trigger on SFRSTCR then creates a row in SFRSTCA, but 

the status code is not set to the DD value; it is set to the value that was in SFRSTCR 

before the DD value was captured in SFTREGS. This processing has been altered so 

the DD code itself is recorded. 

Before the SFRSTCR row is deleted where the SFTREGS_REMOVE_IND is set to Y, the 

SFRSTCR_RSTS_CODE is updated with the dropped/deleted student course 

registration status code (STVRSTS), and the SFRSTCR_REMOVE_IND is set to Y. (The 

post-update trigger on SFRSTCR is updated to not write this row to SFRSTCA.) The 

registration audit record will be written when the record is deleted from SFRSTCR. 

Also, a record is inserted into the SFRREGD collector table, before the record is 

deleted from SFRSTCR. 

SFKMODS - Package Specification for Objects Used to Process 

Student and Related Data 

New insert and delete procedures have been added to the package to track the 

dropped/deleted records in the new Registration Drop-Delete Collector Table For 

Fee Assessment (SFRREDG). 

SFKMOD1 - Package Body for Objects Used to Process Student and 

Related Data 

New insert and delete procedures have been added to the package to track the 

dropped/deleted records in the new Registration Drop-Delete Collector Table For 






SFKFEES - Package Specification for Registration Fee Assessment 

The package has been modified to allow registration fee assessment to process all 

registration records that have been dropped/deleted and do not count in 

assessment. Registration records that do not count in assessment with a status of DD 

Retain are housed in SFRSTCR. Registration records with a status of DD Remove will 

be housed in the new SFRREGD collector table until fee assessment has handled the 

scenario of the dropped/deleted records. 

The current issue with processing registration records with a status of DD that do not 

count in assessment occurs only in flat charge refunding. The basic design for flat 

charge refunding is for assessment processing to use a special algorithm when flat 

charge rules have been met and a course withdrawal (student course registration 

code with the STVRSTS_INCL_ASSESS set to Y and the STVRSTS_WITHDRAW_IND set 

to Y) has occurred. Up until the point when a course withdrawal occurs, assessment 

will use regular billing hours liability processing. The algorithm for flat charge 

refunding exists, because the concept of "free" or "bulk" hours needs to be honored. 

Assessment processing needs to know if records do not count in assessment or if any 

drop/delete activity has occurred since the last assessment was run for the student. 

A new identification method (top down) has been created and set up within 

assessment processing. This information is used to direct assessment to use either 

flat charge refunding or conventional liability processing for the assessment. 

When a student has previously qualified for a flat charge rule in assessment, and 

course withdrawals have occurred, and a drop/delete has been issued for the 

student since their last assessment, the student will need to be assessed from "the top 

down", meaning the student needs to be assessed using conventional hours liability 

processing rather than through flat charge refunding. This allows for the dropped/ 

deleted course to be treated as though it never existed. 

SFKFEE1 - Package Body for Registration Fee Assessment 

The package has been modified to allow registration fee assessment to process all 

registration records that have been dropped/deleted and do not count in 

assessment. Registration records that do not count in assessment with a status of DD 

Retain are housed in SFRSTCR. Registration records with a status of DD Remove will 

be housed in the new SFRREGD collector table until fee assessment has handled the 

scenario of the dropped/deleted records. 

The current issue with processing registration records with a status of DD that do not 

count in assessment occurs only in flat charge refunding. The basic design for flat 

charge refunding is for assessment processing to use a special algorithm when flat 

charge rules have been met and a course withdrawal (student course registration 

code with the STVRSTS_INCL_ASSESS set to Y and the STVRSTS_WITHDRAW_IND set 

to Y) has occurred. Up until the point when a course withdrawal occurs, assessment 

will use regular billing hours liability processing. The algorithm for flat charge 

refunding exists, because the concept of "free" or "bulk" hours needs to be honored. 




New Procedures 

Assessment processing needs to know if records do not count in assessment or if any 

drop/delete activity has occurred since the last assessment was run for the student. 

A new identification method (top down) has been created and set up within 

assessment processing. This information is used to direct assessment to use either 

flat charge refunding or conventional liability processing for the assessment. 

When a student has previously qualified for a flat charge rule in assessment, and 

course withdrawals have occurred, and a drop/delete has been issued for the 

student since their last assessment, the student will need to be assessed from "the top 

down", meaning the student needs to be assessed using conventional hours liability 

processing rather than through flat charge refunding. This allows for the dropped/ 

deleted course to be treated as though it never existed. 


sfkmods.p_insert_sfrregd 

This procedure inserts drop/delete remove registration records into SFRREGD. 

sfkmods.p_delete_sfrregd 

This procedure deletes records from SFRREGD for PIDM, TERM, and CRN (if 

specified). 

sfkmod1.p_insert_sfrregd 

This procedure is used to insert rows into SFRREGD. 

sfkmod1.p_delete_sfrregd 

This procedure is used to delete rows from SFRREGD. 


sfkedit.p_update_regs 

This procedure has been modified to work with the updated drop/delete remove 

processing. 





sfkfee1.p_create_nondrop_hrs_sfrfaud 

This procedure has been modified to determine the total registration billing hours 

for all course registration status codes that are marked to be counted in assessment 

when any drop/delete registration activity has occurred since the last assessment for 

records that do not count in assessment. These total registration billing hours serve 

as the new starting point for the student's registration activity since the courses that 

have been dropped/deleted and do not count in assessment are not considered in 

the total. 

A new type of audit record with an SFRFAUD_ASSESS_RFND_PENLTY_CDE of D is 

written to SFRFAUD to capture the total registered billing hours when courses that 

are dropped/deleted and do not count in assessment are not considered during 

processing. A generated note is captured in the SFRFAUD_NOTE for "DD/not count in 

assessment status handled. Total registered hours are ." 

sfkfee1.p_get_last_assess_flat_data 

This procedure has been updated to determine what the most recent assessment 

date is for courses that are dropped/deleted that do not count in assessment. The 

cursors in the procedure processing have been modified to determine the last 

assessment data changes that occurred on or after the date when registration activity 

occurred for the courses that did not count in assessment and were dropped/ 

deleted. When flat charge refunding is in effect for an assessment, the assessment 

processing is only concerned with flat charge rule qualification that has occurred 

after the activity for the courses that did not count in assessment that were dropped/ 

deleted, since this is when a student's assessment would start over. 

sfkfee1.p_calc_reg_hr_liability 

This procedure has been modified to check for registration activity for courses that 

do not count in assessment that were dropped/deleted since the last assessment. 

This checking occurs if refund by total is not in effect, so the total liable billing hours 

are accrued as part of the intermediate assessment audit, which is determined using 

conventional billing hour liability. 

sfkfee1.p_processfeeassessment 

This procedure has been modified to perform mock fee assessment when drop/ 

delete processing has occurred since the last assessment for courses that do not 

count in assessment. The fee assessment liability determined during the mock 

assessment captures what the students starting liable hours are when registration 

activity for dropped/deleted courses that do not count in assessment is not 

considered. No accounting records are created during this step. After returning 

from building the intermediate fee assessment audit, SFKFEES goes on to perform 

an assessment by processing the registration activity in date/time order. 





Note: The static date determined for the intermediate assessment is one second 

less than the subsequent assessment that occurs afterward. 

sfkfee1.p_studentfees 

This procedure has been modified to check if any courses that do not count in 

assessment have not been dropped/deleted since the last assessment, after 

determining that drops have occurred and that a flat STUDENT rule was met before 

setting the BOOLEAN PREV_FLAT_HR_RULE_MET to TRUE. This BOOLEAN rule 

controls key parts of the flat charge refund processing. 

If any courses that do not count in assessment have been dropped/deleted since the 

last assessment, after determining that drops have occurred and that a flat STUDENT 

rule was met, the BOOLEAN PREV_FLAT_HR_RULE_MET will be set to FALSE. The 

assessment processing will use conventional billing hour liability to determine the 

intermediate assessment liability. 

sfkfee1.p_levelfees 



determining that drops have occurred and that a flat LEVEL rule was met for the 

course level code before setting the BOOLEAN PREV_FLAT_HR_RULE_MET to TRUE. 

This BOOLEAN rule controls key parts of the flat charge refund processing. 


last assessment, after determining that drops have occurred and that a flat LEVEL 

rule was met for the course level code, the BOOLEAN PREV_FLAT_HR_RULE_MET 

will be set to FALSE. The assessment processing will use conventional billing hour 

liability to determine the intermediate assessment liability. 

sfkfee1.p_campusfees 



determining that drops have occurred and that a flat CAMPUS rule was met for the 

course campus code before setting the BOOLEAN PREV_FLAT_HR_RULE_MET to 

TRUE. This BOOLEAN rule controls key parts of the flat charge refund processing. 


last assessment, after determining that drops have occurred and that a flat CAMPUS 

rule was met for the course campus code, the BOOLEAN PREV_FLAT_HR_RULE_MET 

will be set to FALSE. The assessment processing will use conventional billing hour 

liability to determine the intermediate assessment liability. 




New Functions 

sfkfee1.p_attributefees 



determining that drops have occurred and that a flat ATTR rule was met for the 

course attribute code before setting the BOOLEAN PREV_FLAT_HR_RULE_MET to 

TRUE. This BOOLEAN rule controls key parts of the flat charge refund processing. 


last assessment, after determining that drops have occurred and that a flat ATTR 

rule was met for the course attribute code, the BOOLEAN 

PREV_FLAT_HR_RULE_MET will be set to FALSE. The assessment processing will use 

conventional billing hour liability to determine the intermediate assessment 

liability. 

New Functions 

sfkfees.f_DD_since_last_assess 

This function is used to determine if a drop/delete registration activity has occurred 

for courses that do not count in assessment since the last assessment was processed. 

sfkfee1.f_DD_since_last_assess 

This function is used to determine if a drop/delete registration activity has occurred 

for courses that do not count in assessment since the last assessment was processed. 

sfkfees.f_get_sfrstcr_date 

This function is used to determine the SFRSTCR_ACTIVITY_DATE for a given CRN. 

The date the registration record was last updated is needed during assessment 

processing when handling registration activity that occurred prior to the last 

assessment. 

sfkfee1.f_get_sfrstcr_date 

This function is used to determine the SFRSTCR_ACTIVITY_DATE for a given CRN. 

The date the registration record was last updated is needed during assessment 

processing when handling registration activity that occurred prior to the last 

assessment. 




Changed Functions 

Changed Functions 

sfkfee1.f_get_prev_nondrop_hrs 

This function has been modified to include determining the total billing hours from 

the intermediate assessment, when the assessment handled the dropped/deleted 

courses that did not count in assessment. 

sfkfee1.f_prev_flat_rule_met 

This function has been modified to check if any flat charge rules have been met in 

a past assessment. Previously, this function only checked for prior flat charge rule 

qualification for a specific rule type. The function was enhanced to invoke needed 

assessment processing. It now allows checking for any flat charge rule qualification 

used in conjunction with registration activity for dropped/deleted courses that did 

not count in assessment, that occurred since the last assessment. 

New Scripts 

scrfees1.sql 

This script is used to set the SCRFEES_FTYP_CODE to BILL, when the 

SCRFEES_FEE_IND is set to C. 

ssrfees1.sql 

This script is used to set the SSRFEES_FTYP_CODE to BILL, when the 

SSRFEES_FEE_IND is set to C. 

sfrfaud1.sql 

This script is used to add new column comments on the 

SFRFAUD_ASSESS_RFND_PENLTY_CDE. 

sfrregd1.sql 

This script is used to create the new Registration Drop-Delete Collector Table For 





New Scripts 

sfrregd2.sql 

This script is used to add table and column comments for SFRREGD. 

sfrregd3.sql 

This script is used to add a primary key constraint to SFRREGD across 3 columns to 

ensure row uniqueness. 

sfrregd4.sql 

This script is used to add the FK1_SFRREGD_INV_STVTERM_CODE. 

sfrregd5.sql 

This script is used to add the FK1_SFRREGD_INV_STVRSTS_CODE. 

sfrregd6.sql 

This script is used to add the FK1_SFRREGD_INV_STVLEVL_CODE. 

sfrregd7.sql 

This script is used to add the FK1_SFRREGD_INV_STVCAMP_CODE. 

sfrregd8.sql 

This script is used to add the FK1_SFRREGD_INV_STVSCHD_CODE. 

sfrregd9.sql 

This script is used to add the FK1_SFRREGD_INV_STVPTRM_CODE. 

sfrregd10.sql 

This script is used to add the FK1_SFRREGD_INV_STVGMOD_CODE. 

sfrstcr1.sql 

This script is used to add a new comment on column for SFRSTCR _ERROR_FLAG. 




New Scripts 

sftstcr1.sql 

This script is used to update the database trigger st_sfrstcr_post_update_row 

on SFRSTCR. 

sftstcr2.sql 

This script is used to update the database trigger st_sfrstcr_post_delete_row 

on SFRSTCR. 

sfvregd.sql 

This script is used to create view and column comments for the SFVREGD view. 

sinssdax2.sql 

This script is used to create the GTVSDAX rule with an Internal Code of FAREVNRF 

for a Group (Code) of FEE ASSESSMENT with a default value of N for the External 

Code. 

Fee Assessment Script Set 

A new set of SQL reporting scripts is being delivered to assist with evaluating and 

reviewing registration fee assessment data. 

Note: Scripts in this set are also used to add new columns discussed in the “Fee 

Assessment Registration Updates” enhancement. Please see the “New 

Scripts - ActionLine Fee Assessment Scripts” section in the “Fee 

Assessment Registration Updates - Technical” section of this release 

guide for additional new script information. 

Overview 

This fee assessment script set is used to assist with evaluating and reviewing 

registration fee assessment data. These scripts provide an institution with the ability 

to easily gather term-based rule and fee assessment-related data for a term, as well as 

registration information for a specific student. The scripts are designed to provide 

a standardized method for institutions to list and examine rule and assessment data 

for a specific student ID and term so as to assist them in troubleshooting assessment 

issues independently. 




New Scripts 

The generated report files from these scripts can also be used as a standardized 

method for providing the ActionLine with institution test case data when reporting 

assessment-related issues and creating assessment-related contacts. 

These scripts are delivered as part of the PLUS directory, and they can be run from 

the SQL*Plus command prompt. Some script output is in a .csv (comma 

separated value) file format. This was done to make the data easier to use. 

A total of 27 scripts are being delivered. One of the scripts is a driver script, which 

calls the remaining 26 scripts. (You must run the srdriver.sql script first.) A total 

of four output files are generated: one .lis file and three .csv files. 

All four files follow a standard naming convention using the specific student ID and 

term. 

• The .lis file name follows the naming convention _.lis. For 

example, if the scripts were run for term 200409 and student ID 123456789, the 

generated file would be named 200409_123456789.lis. 

• The .csv files (data from SSBSECT, SFRRGFE, and SFRFAUD) follow the 

same naming convention. These files would be named: 

__ssbsect.csv, __sfrrgfe.csv, and 

__sfrfaud.csv. 

Description of Scripts 

The following scripts and the tables they report on are listed below: 

Script Name 

Table Reported 

On 

Description 

srdriver.sql N/A Driver script for the series of assessment data reporting scripts used to create 

fee assessment contacts with ActionLine. 

Input Parameters: 

• Term - Required, no wildcards 

• ID - Required, no wildcards 

srgtvsdax.sql GTVSDAX Script used to identify crosswalk/conversion information for the rules with an 

Internal Group (Code) of FEE ASSESSMENT. 

srsfbests.sql SFBESTS Script used to identify refund by enrollment status/student registration status 

information which defines when the enrollment status code can be used 

during the specified term. 

srsfbetrm.sql SFBETRM Script used to identify student registration/enrollment information for a 

specific student ID and term. 




New Scripts 

Script Name 


On 

Description 

srsfbrfst.sql SFBRFST 

Script used to identify refund by enrollment status/student refund 

percentage information which defines the refund period and percentage for 

the enrollment status code during the specified term. 

srsfrafee.sql 

SFRAFEE, 

SFREFEE 

Script used to identify student registration additional fees information for a 


srsfrareg.sql SFRAREG Script used to identify open learning course registration extension 

information for a specific student ID and term. 

srsfrfaud.sql SFRFAUD Script used to identify registration fee assessment audit information for a 

specific student ID and term. Output is a .csv file. 

srsfrfmax.sql SFRFMAX Script used to identify minimum and maximum registration fee information. 

Defines minimum and maximum charges needed for a detail code for a 

specific term. 

srsfrrfcr.sql SFRRFCR Script used to identify course refund percentage information for a specific 

term. 

srsfrrfnd.sql SFRRFND Script used to identify refund by total refund/penalty periods for a specific 

term. 

srsfrrgfe.sql SFRRGFE Script used to identify registration fee assessment rules information for a 

specific student ID and term. Output is a .csv file. 

srsfrrsts.sql SFRRSTS Script used to identify refund by course/registration status by term 

information. Defines when student course registration codes can be used 


srsfrstcr.sql SFRSTCR Script used to identify student course registration information for a specific 

student ID and term. 

srsobterm.sql SOBTERM Script used to identify base term information for a specified term. 

srssbsect.sql SSBSECT Script used to identify general base section information for a specified term. 

Output is a .csv file. 

srssrattr.sql SSRATTR Script used to identify degree program attribute information for a specified 

term. 

srssrextn.sql SSREXTN Script used to identify open learning registration extension rule information 

for a specified term. 

srssrfees.sql SSRFEES Script used to identify section fee information for a specified term. 

srssrrfnd.sql SSRRFND Script used to identify open learning registration/section refunding 

information for a specified term. 




New Scripts 

Script Name 


On 

Description 

srssrrsts.sql SSRRSTS Script used to identify open learning registration/section registration status 

code information for a specified term. 

srstvests.sql STVESTS Script used to identify student enrollment/registration status information 

which defines enrollment status codes. 

srstvftyp.sql STVFTYP Script used to identify fee type validation information. 

srstvrsts.sql STVRSTS Script used to identify course registration status validation information. 

srtbbctrl.sql TBBCTRL Script used to identify accounts receivable billing control information. 

srtbbdetc.sql TBBDETC Script used to identify detail charge/payment code definition information. 

srtbraccd.sql TBRACCD Script used to identify account charge/payment detail information for a 


How to Run the Scripts 

Use these steps to run the scripts, generate the data output files, and send the files 

to the ActionLine. 

1. Verify that the above scripts exist under $BANNER_HOME/student/plus and 

$BANNER_LINKS. 

2. Navigate to the directory to which the output files can be written. 

3. Run the script set from the SQL*Plus prompt by typing the name of the driving 

script, srdriver, preceded by the @ command or the start command: 

SQLPLUS> @$BANNER_LINKS/srdriver. 

4. Enter values for the two input parameters at the prompt: 

• ID - Required, the ID for the student 

• Term - Required, the term for the student 

5. Review the following files that are created by the series of SQL scripts: 

• _.lis 

• __ssbsect.csv 

• __sfrrgfe.csv 

• __sfrfaud.csv 

6. Transfer the output files to your PC in ASCII using File Transfer Protocol (FTP) 

software. 

7. Email the files to ambanstu@sungardsct.com. If you are sending output files to 

the ActionLine as part of creating a contact, attach the four output files to the 

email message. 




New Scripts 

Files Produced by the Scripts 

Here is a breakdown of what is reported in each of the four files produced by the 

scripts. 

_.lis File 

The _.lis file is comprised of the following data: 

1. Term and Control Data 

• GTVSDAX - crosswalk/conversion information. 

• SOBTERM - term-based information for a specified term. 

• TBBCTRL - accounts receivable billing control information. 

• SFRFMAX - registration fees maximum information that defines 

minimum and maximum charges needed for a detail code for a specific 

term. 

• STVRSTS - course registration validation status information. 

• STVESTS - student registration status validation information that defines 

enrollment status codes. 

• SSRATTR - degree program attribute information for a specified term. 

• STVFTYP - fee type validation information. 

2. Refund Data 

• Refund By Course 

• SFRRSTS - refund by course/registration status by term information. 

defines when a student course registration code can be used during 

the specified term. 

• SFRRFCR - refund by course refund percentage information for 

specific term. 

• Refund By Total 

• SFRRFND - refund by total/refund control information which 

defines penalty periods for refund by total for a specific term. 

• Refund By Enrollment Status 

• SFBESTS - refund by enrollment status/student registration status 

information which defines when enrollment status code can be used 


• SFBRFST - refund by enrollment status/student refund percentage 

information which defines the refund period and percentage for the 

enrollment code during the specified term. 

• Open Learning Registration Refunding 

• SSRRSTS - open learning registration/section open learning 

registration status code information for a specified term. 

• SSREXTN - open learning registration/section open learning 

registration extension rules information for a specified term. 





• SSRRFND - open learning registration/section open learning 

registration refunding information for a specified term. 

3. Student and Student Registration Data 

• SFBETRM - student registration table information for a specific ID/term. 

• SFRSTCR - student course registration information for specific ID/term. 

• SSRFEES - section fees repeating information for a specified term. 

• SFRAFEE - registration additional fees, student registration additional 

fees, and detail charge/payment code definition information for a 


• SFRAREG - open learning additional and student course registration 

information for a specific student ID/term. 

• TBRACCD - account charge/payment detail information for specific ID/ 

term. 

Note: SSBSECT data is spooled to a separate .csv file named 

__ssbsect.csv. 

SFRFAUD data is spooled to a separate .csv file named 

__sfrfaud.csv. 

SFRRGFE data is spooled to a separate .csv file named 

__sfrrgfe.csv. 

4. Detail Code Definitions 

• TBBDETC - detail charge/payment code definition information. 

.csv Files 

The remaining data is written to three comma separated value (.csv) files in 

delimited format, and the files may be viewed as spreadsheets with Microsoft Excel. 

• __ssbsect.csv - section information for a specific term. 

• __sfrfaud.csv - registration fee assessment audit information 

for a specific student ID and term. 

• __sfrrgfe.csv - registration fee assessment rules information. 


st_sfrstcr_post_update_row 

Script sftstcr1.sql is delivered to update the database trigger 

st_sfrstcr_post_update_row on SFRSTCR. 




New Primary Key Constraint 

st_sfrstcr_post_delete_row 

Script sftstcr2.sql is delivered to update the database trigger 

st_sfrstcr_post_delete_row on SFRSTCR. 

The end result of these trigger changes is that one row is written out to SFRSTCA to 

record the drop/delete remove transaction with the drop/delete student course 

registration code and the correct comment "Record deleted: DD-MON-YYYY". 

New Primary Key Constraint 

The following primary key constraint has been added: 

PK_SFRREGD, Primary Key across 

SFRREGD_TERM_CODE, 

SFRREGD_PIDM, 

SFRREGD_CRN 

New Foreign Key Constraints 

The following foreign key constraints have been added: 

• FK1_SFRREGD_INV_STVTERM_CODE 

• FK1_SFRREGD_INV_STVRSTS_CODE 

• FK1_SFRREGD_INV_STVLEVL_CODE 

• FK1_SFRREGD_INV_STVCAMP_CODE 

• FK1_SFRREGD_INV_STVSCHD_CODE 

• FK1_SFRREGD_INV_STVPTRM_CODE 

• FK1_SFRREGD_INV_STVGMOD_CODE 

New Banner View 

SFVREGD - View Student Registered and Dropped/Deleted Courses 

For Fee Assessment 

This view joins the SFRSTCR table and the new SFRREGD table to cumulatively list 

all registration records for a student, including those that have been dropped/ 

deleted and removed. The view is used in fee assessment processing to determine if 




New Banner View 

courses have been dropped/deleted for a student since their last assessment was 

produced. It is also used in the new SFRFEES report, to cumulatively list all 

registration records for a student, including those that have been dropped/deleted 

and removed. 

SFVREGD_TERM_CODE 

SFVREGD_PIDM 

SFVREGD_CRN 

SFVREGD_LEVL_CODE 

SFVREGD_CAMP_CODE 

SFVREGD_PTRM_CODE 

SFVREGD_RSTS_CODE 

SFVREGD_RSTS_DATE 

SFVREGD_CREDIT_HR 

SFVREGD_BILL_HR 

SFVREGD_WAIV_HR 

SFVREGD_GMOD_CODE 

SFVREGD_INSM_CODE 

SFVREGD_SCHD_CODE 

SFVREGD_WITHDRAW_IND 

SFVREGD_INCL_ASSESS 

SFVREGD_ACTIVITY_DATE 



Section 8 Fee Assessment Registration Updates - Technical 


Section 8 Fee Assessment Registration Updates - 

Technical 



Student Course Registration Repeating Table (SFRSTCR) 

The following column has been added to the table: 

SFRSTCR_ASSESS_ACTIVITY_DATE NULL DATE 

This new column is set during registration processing when data in the registration 

record is updated that can impact fee assessment. This column is consulted in flat 

charge refund processing when changed courses to be processed are identified. 

Student Enrollment Status Table (SFBETRM) 


SFBETRM_INITIAL_REG_DATE NOT NULL DATE 

This column is for future use. This column will indicate the date when a student's 

initial or original registration occurred. This date will be consulted in registration 

fee assessment when initial registration grace is in effect for a term. 

Additional Registration Information Table (SFRAREG) 


SFRAREG_RSTS_DATE NOT NULL DATE 

This column indicates the registration status date assigned to the registration status 

code for a course extension. 

Fee Assessment Audit Table (SFRFAUD) 

The following columns have been added to the table: 





SFRFAUD_RGFE_PER_CRED_CHARGE NULL NUMBER(12,2) 

SFRFAUD_RGFE_FLAT_FEE_AMOUNT NULL NUMBER(12,2) 

SFRFAUD_RGFE_FROM_FLAT_HRS NULL NUMBER(9,3) 

SFRFAUD_RGFE_TO_FLAT_HRS NULL NUMBER(9,3) 

SFRFAUD_RGFE_CRSE_OL_START_HR NULL NUMBER(9,3) 

These columns are defined as follows: 

• Column SFRFAUD_RGFE_PER_CRED_CHARGE indicates the value of the 

SFRRGFE_PER_CRED_CHARGE in effect at the time of the assessment. 

• Column SFRFAUD_ RGFE_FLAT_FEE_AMOUNT indicates the value of the 

SFRRGFE_FLAT_FEE_AMOUNT in effect at the time of the assessment. 

• Column SFRFAUD_RGFE_FROM_FLAT_HRS indicates the value of the 

SFRRGFE_FROM_FLAT_HRS in effect at the time of the assessment. 

• Column SFRFAUD_RGFE_TO_FLAT_HRS indicates the value of the 

SFRRGFE_TO_FLAT_HRS in effect at the time of the assessment. 

• Column SFRFAUD_RGFE_CRSE_OL_START_HR indicates the value of the 

SFRRGFE_CRSE_OL_START_HR at the time of the assessment. 

The following columns have been added to the table for future use in fee 

assessment: 

SFRFAUD_ESTS_TUI_LIAB_PERCENT NULL NUMBER(5,2) 

SFRFAUD_ESTS_FEE_LIAB_PERCENT NULL NUMBER(5,2) 

SFRFAUD_RBT_TUI_PENLTY_PERCENT NULL NUMBER(5,2) 

SFRFAUD_RBT_FEE_PENLTY_PERCENT NULL NUMBER(5,2) 

These columns are defined as follows: 

• Column SFRFAUD_ESTS_TUI_LIAB_PERCENT indicates the tuition liability 

percentage in effect for the enrollment status refund. 

• Column SFRFAUD_ESTS_FEE_LIAB_PERCENT indicates the fees liability 

percentage in effect for the enrollment status refund. 

• Column SFRFAUD_RBT_TUI_PENLTY_PERCENT indicates the tuition penalty 

percentage in effect for the refund by total penalty period. 

• Column SFRFAUD_RBT_FEE_PENLTY_PERCENT indicates the fee penalty 

percentage in effect for the refund by total penalty period. 

Registration Additional Fees Repeating Table (SFRAFEE) 

The following column has been modified: 

SFRAFEE_AMOUNT NULL NUMBER(12,2) 

Previously, the column definition for the SFRAFEE_AMOUNT column was 

NUMBER(6,2). 





Term Base Table (SOBTERM) 

The following columns have been added to the table: 

SOBTERM_ASSESS_SWAP_IND NOT NULL VARCHAR2(1) 

SOBTERM_ASSESS_REV_NRF_IND NOT NULL VARCHAR2(1) 

SOBTERM_ASSESS_REG_GRACE_IND NOT NULL VARCHAR2(1) 

These columns are defined as follows 

• Column SOBTERM_ASSESS_SWAP_HRS_IND indicates whether to allow course 

hours swapping in registration fee assessment. 

• Column SOBTERM_ASSESS_REV_NRF_IND indicates whether to allow the 

reversal of charges to detail codes having a category code other than TUI or FEE 

in registration fee assessment. 

• Column SOBTERM_ASSESS_REG_GRACE_IND indicates whether to allow grace 

when dropping a course with the same amount of billing hours as a course 

added on the same initial day of a student's registration. This new column is for 

future use. 

Currently, the SOBTERM_ASSESS_REG_GRACE_IND column only exists on the 

SOBTERM table and not on the SOATERM form. The default setting is N, since it 

is a required field. This column will be used in a future release when functionality 

that allows initial registration day grace for dropped courses is delivered. 


SFKEDIT - Registration Edits 

Please refer to the "New Procedures", "Changed Procedures", "New Functions", and 

"Changed Functions" sections below for further detail on the changes made to this 

package. 

Please refer to the “Fee Assessment Registration Hours Swapping - Functional” 

section of this release guide for a detailed explanation of the functional processing 

additions and changes. 





SFKMODS - Registration Modifications 



package. 




SFKFEES - Registration Fee Assessment 



package. 




SFKOLRL - Open Learning Refunding Rules 



package. 





sfkmods.p_insert_sfrregd 

This procedure inserts registration records into the SFRREGD collector table for 

processing by fee assessment. 

sfkmods.p_delete_sfrregd 

This procedure deletes records from the SFRREGD collector table by PIDM, term, 

and CRN if specified. 





sfkfees.p_process_hours_swap 

This procedure determines the amount of dropped course billing hours that qualify 

for hour swapping by doing the following: 

• Determining the registration date(s) having drop activity. 

• Determining the sum of the dropped course billing hours 

(SFTFEES_REG_BILL_HR where the course registration status code denotes 

WD; the STVRSTS_WITHDRAW_IND is set to Y) for the date having the drop 

activity. 

• Determining the sum of the added course billing hours 

(SFTFEES_REG_BILL_HR where the course registration status code does not 

denote WD; the STVRSTS_WITHDRAW_IND is set to N) for the date having drop 

activity. 

• If more hours are added than are dropped on the given day, all the 

dropped hours are considered to be swapped. The liability for the 

dropped courses that are considered to be swapped is set to 0% by 

updating the SFTFEES_TUIT_LIAB_PERCENTAGE and 

SFTFEES_FEES_LIAB_PERCENTAGE values to 0. 

• If more hours are dropped than are added on the given day, the net 

difference in hours is calculated using the equation: net_dropped_hours 

= dropped_hours - added_hours. SFTFEES is then updated to have 

liability on the net dropped hours in one of the dropped courses. The 

liability percentages are retained so the net hours dropped is handled at 

the correct refund rate for the drop date. 


sfkedit.p_update_regs 

The following changes have been made to this procedure: 

• The procedure has been modified to set the value of the 

SFRSTCR_ASSESS_ACTIVITY_DATE if the RSTS_CODE has changed from a nonwithdrawal 

code to a withdrawal code. 

• The procedure has been modified to set the value of the 

SFBETRM_INITIAL_REG_DATE field if that field is NULL. 

• The process for deleting pre-existing registration records from SFRSTCR now 

work as follows: 





If flat charge refunding is in effect, a dropped/deleted record is written to the 

SFRREGD collector table before the record is deleted from SFRSTCR, unless 

the prior course registration status code (STVRSTS) had the Count in 

Assessment (Indicator) set to N, and that record had already been processed by 

fee assessment. 

sfkmods.p_insert_sfrareg 

The new SFRAREG_RSTS_DATE field has been added to the insert of SFRAREG. 

sfkmods.p_update_sfrareg 

The new SFRAREG_RSTS_DATE field has been added to the update of SFRAREG. 

sfkmods.p_insert_sfrstcr 

The new SFRSTCR_ASSESSMENT_ACTIVITY_DATE field has been added to the insert 

of SFRSTCR. 

sfkmods.p_update_sfrstcr 

The new SFRSTCR_ASSESSMENT_ACTIVITY_DATE field has been added to the 

update of SFRSTCR. 

sfkfees.p_processfeeassessment 

The procedure has been updated to determine if swapping is enabled for the term 

(SOBTERM_ASSESS_SWAP_IND is set to Y) and calls the new procedure 

sfkfees.p_process_hours_swap if it is enabled. 

sfkfees.p_reverse_na_charges 

The procedure has been updated to no longer use the obsolete GTVSDAX rule for 

FAREVNRF. The new SOBTERM_ASSESS_REV_NRF_IND column is used instead. 

sfkfees.p_processcourse 

The SFRAREG_C CURSOR in the procedure has been updated to select the 

SFRAREG_RSTS_CODE and SFRAREG_RSTS_DATE. 





sfkfees.p_extensionfees 

The cursor EXTN_FEES_C in the sfkfees.p_extensionfees procedure has been 

updated to select the SFRAREG_RSTS_DATE. 

The call to sfkolrl.p_determine_refund has been updated to pass in the value 

of SFRAREG_RSTS_DATE. (Previously, the value of the SFRSTCR_RSTS_DATE was 

passed in.) 

sfkfees.p_insert_sfrfaud 

The sfkfees.p_insert_sfrfaud procedure has been updated to populate the 

new columns on SFRFAUD. 

The following procedures that call the sfkfees.p_insert_sfrfaud procedure 

have also been updated to pass NULL values to the new columns: 

• p_create_nondrop_hrs_sfrfaud, one occurrence 

• p_sectionfees, one occurrence 

• p_extensionfees, one occurrence 

• p_calc_flat_hr_liability, one occurrence 

• p_calc_rfst_liability, two occurrences 

• p_additionalfees, one occurrence 

• p_totalfees, one occurrence 

• p_calc_rbt_refunds, three occurrences 

• p_reverse_na_charges, two occurrences 

• p_post_rbt_penalties, two occurrences 

The sfkfees.p_apply_rules procedure that calls the 

sfkfees.p_insert_sfrfaud procedure has been updated to pass in the actual rule 

values for recording in the new columns. 

sfkfees.p_apply_rules 

The sfkfees.p_apply_rules procedure has been updated to pass in the values 

from the rule being met for recording in the new columns. 




New Function 

New Function 

sfkfees.f_flat_rule_exists 

The sfkfees.f_flat_rule_exists function has been added for use in 

registration to insert rows into the SFRREGD table, which only occurs if flat charge 

assessment rules are defined for the term. 

Changed Function 

sfkolrl.f_calculate_percent_complete 

The sfkolor1.f_calculate_percent_complete function has been modified to 

not add "1" in the calculation to determine the number of days elapsed when 

calculating refunds that consider the use of the refund duration rule on SSARULE. 

The days_elapsed calculation has been updated to no longer add “1” after 

subtracting the start date from the registration status date, as well as to no longer use 

zero if the resulting amount from the calculation is less than 0. 

The calculation was changed from: 

to: 

GREATEST(regstatus_date_in - start_date_in + 1, 0); 

(regstatus_date_in - start_date_in); 

The function was updated to check if days_elapsed are greater than or equal to 0 

and add 1 if that is true. This allows for negative days elapsed to be processed, where 

the drop is done before the start date, to correctly meet a 0 rule. 

If the days_elapsed is greater than or equal to 0, a day must be added, since the 

day the course that is dropped has been used, and the total needs to include that 

day. 




New Scripts - ActionLine Fee Assessment Scripts 

New Scripts - ActionLine Fee Assessment Scripts 

The fee assessment script set delivered for use by the ActionLine is discussed in the 

“Fee Assessment Drop/Delete Processing - Technical” section of this release guide. 

It is listed under “New Scripts” and then under “Fee Assessment Script Set”. Scripts 

in this set are also used to add the new columns discussed in the “Fee Assessment 

Registration Updates” enhancement. The following scripts are used to add these 

new columns. 

srsobterm.sql 

This script adds the following new columns to SOBTERM for use with base term 

information: 

Column Name 

SOBTERM_ASSESS_SWAP_HRS_IND 




Swap Hours 

Reverse NRF 

Reg Grace 

srsfrareg.sql 

This script adds the following new column to SFRAREG, for use with the 

SFRAREG_RSTS_CODE when processing extensions for open learning courses: 

Column Name 

SFRAREG_RSTS_DATE 


RSTS Date 

srsfrstcr.sql 

This script adds the following new column to SFRSTCR, for use with the 

SFRSTCR_ADD_DATE when identifying student registration information: 

Column Name 

SFRSTCR_ASSESS_ACTIVITY_DATE 


Assess Act Date 




New Scripts - Seed Data Scripts 

srsfrfaud.sql 

This script adds the new enrollment status and refund by total columns to 

SFRFAUD, as well as the columns to record the SFRRGFE rule values in effect at the 

time of the assessment for processing registration fee assessment audit information: 

Column Name 









ESTS TUI Liable Pcnt 

ESTS FEE Liable Pcnt 

Rule Per Cred Chrg 

Rule Flat Fee Amt 

Rule From Flat Hrs 

Rule To Flat Hrs 

Rule Crse OL Start Hr 

srsfbetrm.sql 

This script adds the following new column to SFBETRM, for use with the 

SFBETRM_INITIAL_REG_DATE when identifying student enrollment information: 

Column Name 

SFBETRM_INITIAL_REG_DATE 


Initial Reg Date 

srsfrafee.sql 

This script verifies the selection and printing of the altered SFRAFEE_AMOUNT 

column, for use with identifying student additional fees information. 


These scripts are delivered to provide seed data. 

sfrareg1.sql 

This script adds the new SFRAREG_RSTS_DATE column to the SFRAREG table. 





sfrareg2.sql 

This script adds the comment on column for the SFRAREG_RSTS_DATE column. 

sfrareg3.sql 

This script populates the SFRAREG_RSTS_DATE column with the 

SFRAREG_START_DATE value. 

sfrareg4.sql 

This script sets the SFRAREG_RSTS_DATE column to NOT NULL. 

sobterm1.sql 

This script adds the following new columns to the SOBTERM table: 

SOBTERM_ASSESS_SWAP_IND 



sobterm2.sql 

This script adds the comments on column for the new columns. 

sobterm 3.sql 

This script populates the value of the SOBTERM_ASSESS_REV_ NRF_IND column 

based on the value of the existing GTVSDAX row for the FAREVNRF rule. 

sobterm4.sql 

This script sets the value of the SOBTERM_ASSESS_SWAP_IND column to N. 

sobterm5.sql 

This script sets the value of the SOBTERM_ASSESS_REG_GRACE_IND column to N. 

sobterm6.sql 

This scripts sets the new columns to NOT NULL. 





sfrstcr1.sql 

This script adds the new SFRSTCR_ASSESS_ACTIVITY_DATE column to the 

SFRSTCR table. 

sfrstcr2.sql 

This script adds the comment on column for the SFRSTCR_ASSESS_ACTIVITY_DATE 

column. 

sfbetrm1.sql 

This script adds the new SFBETRM_INITIAL_REG_DATE column to the SFBETRM 

table. 

sfbetrm2.sql 

This script adds the comment on column for the SFBETRM_INITIAL_REG_DATE 

column. 

sfbetrm3.sql 

This script populates the SFBETRM_INITIAL_REG_DATE column with the 

SFBETRM_ADD_DATE for pre-existing rows. 

sfrfaud1.sql 

This script adds the following columns to the SFRFAUD table. 



SFRFAUD_RBT_TUI_PENLTY_PERCENT 







sfrfaud2.sql 

This script adds the comments on column for the new columns on SFRFAUD. 




Changed Banner View 

sfrafee1.sql 

This script modifies the SFRAFEE_AMOUNT column definition on the SFRAFEES 

table from NUMBER(6,2) to NUMBER(12,2). 

gtvsdax1.sql 

This script removes the FAREVNRF rule for the group code of FEE ASSESSMENT 

from GTVSDAX. 

Changed Banner View 

SFVFAUD - View Student Registration Fee Assessment Audit 

The following columns have been added to the view: 

SFVFAUD_RGFE_PER_CRED_CHARGE 

SFVFAUD_RGFE_FLAT_FEE_AMOUNT 

SFVFAUD_RGFE_FROM_FLAT_HRS 

SFVFAUD_RGFE_TO_FLAT_HRS 

SFVFAUD_RGFE_CRSE_OL_START_HR 

NUMBER(12,2) 

NUMBER(12,2) 

NUMBER(9,3) 

NUMBER(9,3) 

NUMBER(9,3) 

Changed API 

sb_term 

The sb_term API has been modified for this release. 

Table Form API Object Name API Entity Name Task Performed 

SOBTERM SOATERM sb_term TERM Maintains controls for a 

specific term - no create 

allowed, only update and 

delete 

All of the sb_term API signatures and query records have been changed to include 

the three new SOBTERM columns, and validation and error messages have been 

added for each new column. 




Changed API 




Section 9 Miscellaneous Enhancements 

IPEDS Spring 2005 Regulatory Updates 

Section 9 

Miscellaneous Enhancements 


SHRIACT (#101908) 

New Requirement 

The National Center for Educational Statistics (NCES) has added a new 

requirement to the Fall Total Activity Reporting for schools. This new section (G) 

requires that schools determine the percentage of Full-Time First Time 

Undergraduates who are retained from one fall term to the next. (Part-time is 

determined separately.) Retention is counted as fall to fall only. 

A full-time cohort person does not have to remain full-time to count as retained. For 

example, if Cohort A is enrolled in fall 2003 as full-time but is part-time in fall 2004, 

said student is counted as retained. 

For purposes of this reporting cycle, institutions are required to report the percent 

of students who were in the Fall 2003 Full-Time First Time Undergraduate Cohort 

who subsequently enrolled in the fall 2004 term. Likewise they must report the same 

data reflecting the Fall First Time Part-Time Undergraduate Cohort. 

This requires that new section, G - Retention Data of First Time Undergraduates 

from Fall to Fall, be added to SHRIACT. PART G has been added to the Web Upload 

File, to report first-time fall cohorts who returned the following fall. 

New Parameters 

Four new parameters have been added to SHRIACT: 

• Effective Term of Fall Cohort, Optional - Enter the cohort effective term for 

report Part G. Valid values come from the Term Code Validation Form 

(STVTERM). 

• Retention Term of Fall Cohort, Optional - Enter the cohort retention term for 

report Part G. Valid values come from the Term Code Validation Form 

(STVTERM). 

• Full-time Fall Cohort Code, Optional - Enter the full-time, first-time, cohort 

code for report Part G. Valid values come from the Cohort Code Validation 

Form (STVCHRT). 





• Part-time Fall Cohort Code, Optional - Enter the part-time, first-time, cohort 

code for report Part G. Valid values come from the Cohort Code Validation 

Form (STVCHRT). 

Key Pair Value File Format 

The key pair value file format is the standard from the National Center for 

Educational Statistics (NCES) which was used for the Web upload option in the 

Total Activity Report (SHRIACT). 

Import/Export File Layout Specification for Winter 2004-2005/Spring 2005 Data Collection 

Fall Enrollment Section - Key Value Pair File (*.txt) 

Field ID (Key) Description Valid Entries SCT Banner Values 

UNITID UNITID nnnnnn=Valid UnitID This is the institution code defined on 

SHACTRL in the NCES Unit ID field. 

SURVSECT Survey section “EF” - Enrollment N/A 

PART 

Part of survey 

section 

“E”, “F”, “G” 

N/A 

RACE Race j = 1 to 8, refer to race/ 

ethnicity table, 

applicable to Parts A and 

E 

SLEVEL Student Level j = 1 to 3, refer to student 

level table - Part B, 

applicable to Parts B and 

E 

SEX Sex k = 1-Men, 2-Women, 

applicable to Parts A, B 

and E 

This value comes from the race defined on 

SPAPERS in the SPBPERS table. Please see the 

Race/Ethnicity Values section which follows. 

This level code comes from the applicable 

SHRDGMR record and is matched against the 

code(s) entered in the run parameters. 

This value comes from the gender defined on 

SPAPERS in the SPBPERS table. 

COUNT 

Number of 

students enrolled 

1 to 99999, for zero 

value see note below 

after sample file, 

applicable to Parts A, B, 

C, D, and E 

N/A 

CREDHRSU 

12 month 

undergraduate 

instructional 

activity CREDIT 

hours 

0 to 9999999, only 

applicable to Part F 

This is the credit hours stored on SHRTCKG. 





Import/Export File Layout Specification for Winter 2004-2005/Spring 2005 Data Collection 

Fall Enrollment Section - Key Value Pair File (*.txt) 

CONTHRS 

12 month 

undergraduate 

instructional 

activity 

CONTACT hours 

0 to 9999999, only 


This is the sum of the lecture, lab, and other 

hours from SCBCRSE. 

CREDHRSG 

12 month 

graduate 

instructional 

activity CREDIT 

hours 

0 to 9999999, only 


This is the credit hours stored on SHRTCKG. 

REP_YEAR 

Indicate which 

full 12 month 

period is used to 

report UNDU- 

PLICATED 

student count 

1 - July 1, 2003 - June 30. 

2004 

2 - September 1, 2003 - 

August 31, 2004 

Used only in Part F 

Selection is based on a comparison between 

term dates as defined on STVTERM and dates 

entered in the run parameters. 

RET_PCF 

Percentage of 

full-time fall 2002 

cohort who were 

re-enrolled in fall 

2003 

0 to 100 or blank, only 

applicable to Part G 

This is the calculated percentage retained who 

were full-time. 

RET_PCP 

Percentage of 

part-time fall 

2002 cohort who 

were re-enrolled 

in fall 2003 

0 to 100 or blank, only 

applicable to Part G 

This is the calculated percentage retained who 

were part-time. 

Sample Upload File 

Here is a sample of how the upload file might appear. The new information for Part 

G appears in the last line of data. 





Sample record: 

UNITID=1234,SURVSECT=EF,PART=E,SLEVEL=1,RACE=1,SEX=1,COUNT=1 













...... 

UNITID=1234,SURVSECT=EF,PART=F,REP_YEAR=2,CREDHRSU=737,CONTHRS=233,CREDHRSG=42 

UNITID=1234,SURVSECT=EF,PART=G,RET_PCF=87,RET_PCP=84 

Note: If there is zero enrollment for any category (student level, age, state) the 

line does not have to be included in the import file. For Part C, HS=1 and 

2 are not mutually exclusive categories. If first-time students who 

graduated from high school in the past 12 months are reported (HS=2) 

for any state, then also report those students as all first-time students 

(HS=1). Sort Order: UNITID,SURVSECT,PART. 

New Functions 

Five new functions have been created for this update: 

• CALC_PART_G 

This function retrieves the counts of students in full-time and part-time cohorts 

and calculates the percentages of those who returned the following fall term. 

• READEFFTERM 

This function reads the value for the Effective Term of Fall Cohort parameter 

from the Process Run Parameter Table (GJBPRUN). 

• READRETTERM 

This function reads the value for the Retention Term of Fall Cohort parameter 

from the Process Run Parameter Table (GJBPRUN). 

• READ_COHORT_CODE 

This function reads the values for full-time and part-time cohort codes from the 

Person Collector Table (SPRCOLR). 

• PRINT_COHORT_CODE 

This function prints the values for full-time and part-time cohort codes on the 

control report. 

Changed Function 

The CREATE_WEB_REC has been modified so that PART G will be generated for the 

Web upload file. 




Common Matching Update 

New Variables 

15 new variables have been added for processing. They are: 

static CHAR11 ask_ft_cohort=""; 

static CHAR11 ask_pt_cohort=""; 

static CHAR11 cohort_code=""; 

static CHAR7 ask_cohort_eff_term=""; 

static CHAR7 cohort_eff_term=""; 

static CHAR7 ask_cohort_ret_term=""; 

static CHAR7 cohort_ret_term=""; 

static CHAR2 ft_cohort_ind="N"; 

static CHAR2 pt_cohort_ind="N"; 

static NUMSTR ft_cohort_count=""; 

static NUMSTR pt_cohort_count=""; 

static NUMSTR ft_retain_count=""; 

static NUMSTR pt_retain_count=""; 

static NUMSTR ft_cohort_pct=""; 

static NUMSTR pt_cohort_pct=""; 

Resolved in Release 7.1. 

Common Matching Update 

Here is an updated set of rules for use with common matching in Banner Student. 

Priority Column Name Data Element Length Required/Exists 

1 SPRIDEN_SEARCH_LAST_NAME LAST NAME/NON-PERSON NAME 10 Required 

SPRIDEN_SEARCH_FIRST_NAME FIRST NAME 10 Required 

SPBPERS_SSN SSN/SIN/TIN 9 Required 

SPBPERS_BIRTH_DAY DATE OF BIRTH DAY 2 Exists 

SPBPERS_BIRTH_MONTH DATE OF BIRTH MONTH 2 Exists 

SPBPERS_BIRTH_YEAR DATE OF BIRTH YEAR 2 Exists 

SPRADDR_ZIP ZIP/POSTAL CODE 5 Exists 



SPBPERS_SSN SSN/SIN/TIN 9 Exists 





RPEs 

Priority Column Name Data Element Length Required/Exists 



SPRADDR_CITY CITY 10 Exists 







SPRADDR_CITY CITY 10 Exists 


RPEs 

Concurrent Curricula Phase 2 

The following RPEs are delivered with this enhancement and are discussed in the 

enhancement documentation: 

• #44156 

• #44157 

• #46150 

AMCAS Phase 1 

The following RPEs are delivered with this enhancement and are discussed in the 

enhancement documentation: 

• #26832 

• #28187 




RPEs 

• #30816 

• #38172 

Registration Fee Assessment 

SFAFAUD (#35999) 

RPE #35999 states that while using SFAFAUD to investigate a student's charges, 

when the amount for the charge on SFRRGFE has been changed, SFRFAUD records 

created before the change show the new PER_CREDIT_CHARGE amount (i.e., the 

updated SFFRGFE amount on the Fee Assessment Audit Detail window). It would 

be more accurate to store the PER_CREDIT_CHARGE amount on SFRFAUD, so that it 

can be displayed correctly on SFAFAUD. 

To incorporate this, new columns have been added to SFRFAUD to store the per 

credit charge amount used at the time the charge was calculated. A script is 

delivered to add the new table columns to SFRFAUD to record the key SFRRGFE 

rule values as static values at the time the assessment is run. If the SFRRGFE rule 

values are updated after the assessment was run, the rule values in effect at the time 

of the assessment are preserved. 

The new columns are: 






In addition, new data columns are used to capture and retain needed data for the 

correct processing of fee assessment refunds by enrollment status and the refund by 

total process. 

These new columns are: 



SFRFAUD_RBT_TUI_PENLTY_ PERCENT 


These columns have been added for future use in fee assessment audit data 

recording when enrollment status refunds are in effect for an assessment. The 

outstanding issues with enrollment status refunding in assessment are slated for 

correction in a future release. The recording of the enrollment status liability 

percentages as part of the assessment audit when an enrollment status refund is in 

effect for the assessment will provide the ability for assessment processing to 

concisely determine if an enrollment status refund was previously processed, as well 

as if the refund percentage has changed since the previous refund was processed. 

Delivered in Release 7.1. 




RPEs 

SFRAFEE (#38431) 

RPE #38431 requested that the SFRAFEE_AMOUNT field be able to handle amounts 

that are greater than 99999.99. This also affects SFAAFEE and SFAEFEE. 

The Amount column on the report and the Amount fields on SFAAFEE and 

SFAEFEE have been modified to display an expanded number value from 

NUMBER(6,2) to NUMBER(12,2). Delivered in Release 7.1. 

Registration 

SFRSCHD (#30434) 

RPE #30434 requested that the actual course dates be printed on the Student 

Schedule Report (SFRSCHD). 

This enhancement was delivered but not documented in the 6.0 release with the 

addition of the Print Reg Start/End Dates parameter. The actual dates printed have 

been further enhanced to more accurately reflect when the student is actively 

enrolled in and attending the course. The specific dates that are printed depend on 

the conditions outlined below. 

Start and End Dates for Open Learning Sections 

The start date for all open learning sections will print the SFRAREG_START_DATE 

from the “0” extension record. 

The end date for all open learning sections will print the 

SFRAREG_COMPLETION_DATE for the maximum extension records that exist. 

Dates associated with meeting time records, if they exist, are not printed. 

Start and End Dates for Traditional Sections 

The start date for a traditional section will print the SSRMEET_START_DATE(s) 

associated with the meeting time(s). 

The end date for a traditional section will print the SSRMEET_END_DATE(s) 

associated with the meeting time(s) 

If no meeting times are defined for a traditional section, the start date will print the 

SSBSECT_PTRM_START_DATE, and the end date will print the 

SSBSECT_PTRM_END_DATE. If those dates are NULL, the SOBPTRM_START_DATE and 

the SOBPRTM_END_DATE will be printed. 




RPEs 


RPE #38453 requested the ability to print schedules for multiple terms using a single 

sleep/wake process on the Student Schedule Report (SFRSCHD). 

This release now permits the user to enter % for the Process Term parameter when 

processing in COLLECTOR mode. (Sleep/wake requires the entry of 

COLLECTOR in the ID Number parameter). Previously, sleep/wake processing was 

restricted to a single process term, and multiple sleep/wake processes were required 

to print schedules for different terms. 




RPEs 




Section 10 Problem Resolutions 

Catalog Module 

Section 10 

Problem Resolutions 

Catalog Module 

Form 

SCACRSE (#93497) 

An error message was received (“Cannot insert if from term not equal to key block term") 

when maintaining room attribute preferences, if a prior term partition preferences 

record existed. The copy and insert functions on this form have been modified to 

correct this. Resolved in Release 7.1. 


The Long Title Exists field did not work correctly when the term in the Key Block 

did not match the from term for the course. The Long Title Exists field will now 

display on SCACRSE when a course is viewed that has a different effective term from 

the one built for the long title. Resolved in Release 7.1. 


Previously, you could enter a course number that was longer than five characters, 

but you would then receive an error. Now, when you attempt to enter a course 

number that is longer than five characters, no error is displayed. Only five characters 

are displayed in the field. Resolved in Release 7.1. 

SCACRSE (#101961) 

The error message that was displayed in the Partition field was not complete when 

you attempted to enter a negative number in the Preference field. The error 

message now reads: “FRM-40207: Must be in range 00 to 99” if you attempt to enter a 

value outside that range. Resolved in Release 7.1. 


The Total Term Contact Hours High field (SCBCRSE_CONT_HR_HIGH) field is now 

navigable and updateable as it was in previous versions of Banner. Resolved in 

Release 7.1. 




Schedule Module 

Schedule Module 

Form 

SSASECT (#99243 and 82557) 

When a user changed a grade mode, they did not receive a warning that changes to 

grade mode may have affected fee assessment. Now, if registration records exist, and 

a change to a grade mode is attempted in SSASECT, the user receives this message: 

"Warning, Grade Mode changes at the section level will not be realized by previously registered 

students unless dropped and re-registered." Resolved in Release 7.1. 

SSASECT (#95856) 

An edit check was enforced to prevent a change to the instructional method if 

enrollment records existed for a section. The same edit check should be added to 

the schedule type because of the potential impact to fee assessment. The message 

“Changing schedule type may impact Registration Fee Assessment.” has been added. 


Package 

SOKB_SECTION1 (#102324) 

The sb_section API has been modified to fix the missing lv_proc_call in the 

p_create and p_update procedures for user exit. Resolved in Release 7.1. 

Table 

SSBSECT (#97727) 

When List and a Select were performed, a user could change the schedule type 

when a meeting time record existed. This has been corrected. Resolved in Release 

7.1. 

Report 

SSRROLL (#101462) 

SSRROLL would abort with a unique constraint error (“ORA-00001: unique constraint 

(SATURN.UK1_SSRMPRT_REC) violated”) when the Roll Meeting Time Partition 

Preferences parameter was set to Y and if sections in the roll from term had meeting 

time records with partition preferences specified. SSRROLL has been modified to 

prevent the unique constraint error when meeting time partition preferences are 

rolled. Resolved in Release 7.1. 




General Person Module 

SSRROLL (#90483) 

SSRROLL was not rolling corequisites or cross-listed sections correctly. The 

documentation did not specify what would happen if a user entered Y for the Roll 

Corequisites parameter and/or Y for the Roll Cross List Data parameter but 

entered N for the Roll CRNs parameter. Corequisites and cross-listed data must be 

tied to their specific CRN numbers in the roll process, because the information is 

section specific. 

SSRROLL has been modified so that if the user enters N for the Roll CRNs 

parameter but enters Y for the Roll Corequisites parameter and/or the Roll Cross 

List Data parameter, the Y will be ignored and the corequisites and cross-listed data 

will not be rolled. The Report Control information will display N for the Roll 

Corequisites and Roll Cross List Data parameters. 

The Banner 7.X User Guide documentation will incorporate a documentation 

update for SSRROLL which states that: CRNs must be rolled in order to roll 

corequisites and cross-listed data. If you enter N for Roll CRNs but enter Y for the 

Roll Corequisites and/or the Roll Cross List Data parameters, the Y will be ignored, 

and N will be printed as the value for those parameters in the Report Control 

information. 


General Person Module 

Forms 

SPAIDEN, 

SPAPERS 

(#101958) 

Problem resolution #101947 necessitated that functionality be moved out of 

GOQCLIB. The reference in GOQCLIB to sokcpln.p_create_materials caused 

problems if the school didn’t have Banner Student installed. Code has been 

removed from GOQCLIB and added back into SPAIDEN and SPAPERS for the 

CHECK_MATERIALS trigger. Resolved in Release 7.1. 

Location Management Module 

Forms 

SLABLDG (#101864) 

You are now able to enter attributes on this form. Resolved in Release 7.1. 




Recruiting Module 

SLAEVNT (#66707) 

When you changed the date for a meeting time, the day of week did not change. A 

conflict error did not display, and you could save the record. This has been 

corrected. Resolved in Release 7.1. 

SLARDEF (#88599) 

An overlapping dates error was received on the Room Inactivation block when 

multiple records were being set up, and dates were not overlapping. This has been 


SLARDEF (#102046) 

You can now compile the form without receiving any errors. Resolved in Release 7.1. 

Report 

SLRDADD (#65699) 

When SLRDADD was run, the SPRADDR_USER and SPRADDR_ASRC_CODE were not 

being updated. A new parameter has been added to SLRDADD to correct this. The 

Address Source parameter is optional and allows you to select values from the 

Address Source Validation Form (STVASRC). Resolved in Release 7.1. 


Documentation 

SRARAPT (#102361) 

The sentence “All appointments and visits entered from this form will appear on the 

Recruit Prospect Information Form (SRARECR), and likewise all appointments and 

visits entered on SRARECR will appear on SRARAPT.” was incorrect and has been 

removed from the form description text in the user guide. This change is reflected 

in the 7.1 version of the user guide. Resolved in Release 7.1. 

Forms 

SRARECR (#102073) 

Tabs are now displayed correctly and are navigable when Rollback is used. Resolved 

in Release 7.1. 





SRARECR (#103082) 

The level code entered in the Key Block will now default correctly into the 

Curriculum block. Previously, the value of 00 was defaulting in. Resolved in Release 


SRIPREL, 

SRRPREL 

(#102125) 

The Student Type field was not being populated even though the student type value 

was defaulted to F on SRAPRED. The student type value will now properly default 

from SRAPRED. Resolved in Release 7.1. 

Reports 

SRRSRIN (#101803) 

The duplicate checking performed by the report was using the SORNAME table. 

SRRSROM has been modified in to use the GORNAME table. Resolved in Release 


SRRSRIN (#101809) 

Performance issues that caused the report to run slowly have been resolved. 


SRTLOAD (#93482) 

The birthday is now loaded correctly, and the birth year is no longer set to the 

century. Resolved in Release 7.1. 


The SOBSEQN_ACTIVITY_DATE is now updated when you generate IDs when 

running SRTLOAD. Resolved in Release 7.1. 


SRTLOAD was creating a SRTINTL record for each person that was processed from 

a data file. GOBINTL records were then created for each person from the SRTINTL 

records. The tapeload process populated the GOBINTL_SPOUSE_IND and 

GOBINTL_SIGNATURE_IND fields with the value T, and also populated the PIDM, 

USER_ID, and ACTIVITY_DATE fields. No other fields were populated. When 

information was viewed for these students on the GOAINTL form, no data was 

displayed. SRTLOAD will no longer create SRTINTL/GOBINTL records. This has 

been corrected. Resolved in Release 7.1. 




Admissions Module 


Forms 

SAADCBT (#98367 and #95839) 

Various issues regarding the decision status information have been corrected on the 

form. 

• The application summary was keeping the same decision status as existed on 

the first application displayed. The Decision Status field data now changes as 

the user scrolls through the applications in the Application Summary block. 

• The decision status description for code 35 now reads, “Decision Created. Student 

Record Created”. 

• When a decision code is entered in the key with an invalid term, the name data 

no longer disappears, and an error message is displayed. 

• If a decision code and a valid term are entered in the key with an invalid 

application number, the autohint now displays an error message, and the 

Decision Status field remains blank. 

• The decision status now displays the appropriate description for each 

application as it becomes active in the Application Summary block. 


SAADCBT (#102038) 

Decisions with the Applicant Acceptance flag set to Y on STVAPDC are now updated 

to SAADCRV when entered on SAADCBT. Resolved in Release 7.1. 

SAADCBT (#91295) 

SAADCBT now performs the same way that SAADCRV does. If two or more 

applications exist for the same term, and a decision code to create a student record 

is entered on one of those applications, then the subsequent entry of a decision 

code where the Inactive Application box is checked on STVAPDC for a different 

application will not affect the existing student record. It only affects the application. 


SAADCBT (#87837) 

The scrolling functionality in the Application Summary block has been modified to 

display the correct associated information in the Batch Entry block. Resolved in 


SAADCRV (#101804) 

SAADCRV will now create automatic decisions correctly. The WHERE clause on the 

SAVDCSN block was modified to use the application number and term from the 

SARADAP block, instead of the global variables. Resolved in Release 7.1. 





SAADCSN (#90581) 

You can now enter a numeric grade value as well as an alphabetic value in the Grade 

field in the High School Subject block. Resolved in Release 7.1. 

SAAEAPS, 

SAAETBL, 

SAKL020 

(#90239) 

The SARADDR_NATN_CDE field on SAAETBL was truncating values to three places 

and causing an error. This occurred when the nation code entered on a Web 

application was longer than four places. Another truncation error was occurring in 

the SARPERS_ETHN_CODE field. 

The SARPERS_NATN_CDE_CITZ field has been expanded to five places. The 

SARPERS_NATN_CDE_BIRTH field has been expanded to five places. The 

SARPERS_STAT_CDE_BIRTH field has been expanded to three places. 


SAAERUL (#78143) 

An insert script, sinserul.sql, is provided to populate all the rules used on 

SAAERUL. Records do not need to be inserted manually. The documentation for 

SAAERUL has also been updated to reflect this. Resolved in Release 7.1. 

SAAETBL (#94905) 

The SARADDR_CNTY_CDE field has been expanded to from three to five characters to 

avoid truncation errors for country codes. Resolved in Release 7.1. 

SAAQUAN (#95937) 

The Essay Answer field was not allowing the manual entry of more than 4,000 

characters, and although the autohint message said the transaction was applied and 

saved, the data was not being saved. This has been corrected. 

Other changes have also been made: 

• The form has been modified so the user can access all the applications in the 

summary whether they use the mouse/scroll bar or the keyboard. 

• The SARADAP and SARQUAN blocks have been modified so that an entered 

question and answer are applied to the correct application whether the 

mouse/scroll bar or keyboard is used. 

• The Full/Part Time field has been renamed the Full or Part Time field. 


SAARRAT, 

sokb_ 

admissions1. 

sql, 

sokb_ 

admissions0 

,sql 

(#97532 and #92640) 

When an admissions application is deleted online, the process will now check to see 

if there is an SOAGPAT record for that term and application number for that ID. All 

associated rows will be deleted. This is also true for SAARRAT and SOACRSS. 






SAASUMI (#97969) 

The ID is now properly returned to the ID field, even if the cursor is in the Term 

Code field when you access SOAIDEN and bring a value back to SAASUMI. 

Previously, the ID would populate the Term Code field. Resolved in Release 7.1. 

Packages 

SAKCHK1 (#99781) 

When a new checklist rule was entered on SAACHKB that did not have the 

Mandatory Indicator checked, checklist items were still being created with the 

Mandatory Indicator checked from a previous rule. This has been corrected. 


SAKL010 (#91727) 

None of the residency rules in sakl010.f_get_banner_resd (i.e., 

OUTRESIDCODE or FORRESIDCODE) were being validated, if the 

SARRQST_RESP_FLAG was set to N for the SARRQST_QSTN_CODE of RS. This has been 


SAKL030, 

SAKPCOM, 

SAKVAPL 

(#91538) 

GOBINTL records will no longer be created for pushed Web IDs when no 

international data exists for the application. Resolved in Release 7.1. 

SAKP120 (#100023) 

The DUPLAPPLMAJR label and the P120 procedure (Entry Curriculum 

Verification) and R0010 routine (Duplicate Application for Major) Override flag 

could not be reviewed when running SARETMT. This allowed applications with 

duplicate majors to be created when running SARETMT. This has been corrected. 


Reports 

SARDBSN (#101828) 

Users are now able to enter a high school GPA value that is alpha, and the decision 

process does not abort with an error. Resolved in Release 7.1. 

SARAMAL (#99424) 

The SARAMAL process was not updating the SATAMAL_MATCH_IND to N for New 

records that had SSNs and were delivered in the AMCAS data file. These same 

records were not being inserted into the SATARPT table. This caused several issues: 




General Student Module 

1. The APPLICATION ADDED section did not list applications for those AMCAS 

records where an SSN existed. 

2. When SAPAMAL was run in Update Mode, the Total Number of Persons 

Processed was not equal to the Number of New, Matched, and Rejected 

Persons. 

This has been corrected. Resolved in Release 7.1. 

SURLOAD (#101813) 

The process will now run on an NT platform without displaying an error or looping 

on the last record. The Generated or Published parameter is now required. 


General Student Module 

Forms 

SGAADVR (#96725) 

The advisor termination record is now removed from the database when the advisor 

is removed from the student record. Previously, the termination record remained 

in the database as a ghost record, which prohibited the deletion of the general 

student record. Resolved in Release 7.1. 


The second Detailed Student Information option has been removed from 

GUROPTM. Although this option was defined with the GUROPTM_CAPACITY field set 

to M (Maintenance), the GEN_STUDENT_BTN_TRG field always called SGASTDN in 

query mode. In addition, the Student Info button is no longer displayed on the 

form. Resolved in Release 7.1. 


It is no longer possible for a user to assign a deceased advisor to a student on 

SGAADVR. The user now receives an error, and the record cannot be saved. 



The primary advisor is now being displayed on future terms. This error created the 

possibility of being able to set up multiple advisors as the primary advisor. Updates 

are now prevented when the key term and from term are not equal. You must use 

the Maintenance button to create a primary advisor on a future term. Resolved in 





Registration Module 


Double-clicking on the Advisor Type field now appropriately displays the List of 

Values for the field. Previously, double-clicking on the Advisor Type field performed 

an Exit function rather than a List function. This only occurred when SGAADVR 

had been called from SGASTDN using the Duplicate Field function. Resolved in 


SGASPRT (#94583) 

When SGASTDN is accessed through the Options Menu, it is now displayed in 

Query Mode. Resolved in Release 7.1. 


Forms 

SFAREGS (#102012) 

If you were in the Registration Information block and you accessed the Student 

Term window to update student term information, when you exited from the 

window, the cursor returned to the CRN block, and you had to use a Previous Block 

to return to where you had started, which caused the form to try to insert a new 

SFBETRM record. 

Any time changes are saved in the Student Term window, courses are re-evaluated, 

and fee assessment is run. So, the cursor is always returned to the CRN block, even 

if the user came from the Enrollment block. The insert into SFBETRM has been 


SFAREGS (#102126) 

When you entered CRNs, if the you inadvertently entered a Y or an A in the 

Override field, the message: "*Error* No fatal error to override, or override(s) already set. 

Clear field to continue." was displayed. However, using Clear Item did not resolve the 

error, and the error continued. You had to clear the block to be able to enter the 

data again. The Clear Item function will now address the error. Resolved in Release 


SFARQST (#102218) 

If a student does not have a hold, you can look up requests by term or date range. If 

an active hold exists, you can only look up requests by term code. This logic exists, 

because hold passwords can only be defined by term. If no hold password has been 

defined for the term, “OVR’ is the expected default in the SFARQST logic. The 

default password logic has been incorporated into the non-term logic request on 

SFARQST. If a student has a hold and a non-term request is made, you can use the 

default “OVR” password to override the hold and continue. Resolved in Release 7.1. 





Table 

SFRSRPO (#89355) 

When you entered the same override for the same subject, course number, and 

section number but for a different CRN, you received the Oracle error: “Unable to 

INSERT record”. The SFRSRPO_KEY_INDEX unique index has been dropped and 

recreated as non-unique to correct this. Resolved in Release 7.1. 

Packages 

SFKCUR1 (#99103) 

Cursors have been modified to address performance issues. Resolved in Release 7.1. 

SFKCURS (#99104) 


SFKFEE1 (#101383) 

When you tried to assess fees using SFAREGS or SFRFASC for a student who had a 

null SGBSTDN_RESD_CODE, you received an error. This check has been removed, and 

the error no longer appears. Resolved in Release 7.1. 

SFKFEE1 (#95159) 

When flat charge (plateau) processing was used, and a student dropped a course 

which took them from the flat charge rule to the per hour rule, and then a drop/ 

delete (DD) was performed on another course, incorrect results were received. The 

drop/delete was not processed, although SFAFAUD indicated the correct number 

of total non-dropped hours. If the drop/delete was performed before the other 

course was dropped, the correct results were received. This has been corrected. 


SFKFEE1 (#98383) 

Incorrect refunding was occurring for fee assessment rules that had flat and 

overload charges when the student moved out of overload range after some courses 

had been dropped/deleted (DD). This has been corrected. Resolved in Release 7.1. 

SFKFEE1 (#97768) 

When courses for a student were drop-deleted and fee assessment was run, an 

incorrect source code may have been used. Fee assessment was using the same 

source code as the first charge (using the same detail code), even if that charge was 

not from Registration. The procedure p_reverse_na_charges has been updated 

to assign a source code of R at all times, and the cursor tbraccd_srce_c has been 

removed. Resolved in Release 7.1. 





SFKFEE1 (#92595) 

When fees were assessed using SFRFASC, and the Assessment Date parameter value 

was blank, if accounting records existed, the TBRACCD_ORIG_CHG_IND field may not 

have been set for new transactions that were posted after the first original charges 

had been posted. This has been corrected. Resolved in Release 7.1. 

SFKFEE1 (#97741) 

The section fee was not being reversed when the fee was removed from SSADETL 

or when the amount was updated to $0.00, if the category code had been set to 

something other than TUI/FEE, and the FAREVNRF rule was set to N on GTVSDAX. 

This has been modified to allow the $0.00 amount to be reversed. Removing the fee 

will no longer trigger a reversal if the GTVSDAX row for the FAREVNRF rule is set to 

N. Resolved in Release 7.1. 

SFKFEE1 (#96413) 

The minimum amount on SFAFMAX will now be enforced during a 100% refund 

by course refund period. The minimum amount was being enforced for other 

percentage refunds. Resolved in Release 7.1. 

SFKFEE1 (#102981) 

The following error occurred when fee assessment was run: “ORA-01852: seconds 

must be between 0 and 59”. Whenever the seconds in the current time were zero (0), 

the intermediate_date calculation set the seconds portion of the date to -1. This 

was resolved as follows: If seconds are 0, set seconds to 59, and check if minutes are 

0. If minutes are 0, reduce hours by 1, and set minutes and seconds to 59. Otherwise 

subtract 1 from seconds. Resolved in Release 7.1. 

SFKFEE1 (#95410) 

The rule student/liable hours on SFAFAUD were not being correctly updated when 

a user retyped the RE course status over an existing course status on SFAREGS 

during a flat charge refund period. This has been corrected. Resolved in Release 7.1. 

SFKFEES (#102087) 

The DD (Dropped/Deleted) process was not assessing the correct results when used 

after a DC (Dropped Course) had been processed, and SFARGFE was set up with per 

credit hour rules. This has been corrected. Resolved in Release 7.1. 

SFKFEES, 

SFKFEE1 

SFKFEE1/ 

SFKFEES 

(#92398) 

If a student dropped and added equal amounts of credits on the same day during 

an SFARSTS refund period, the student was incorrectly charged the liability. This 

has been corrected by the updates to fee assessment for swapping hours. Resolved 


(#93763 and #89566) 

When a future date was entered on SFAREGS (or used for SFRFASC), and that date 

was greater than the future effective date that had been defined on SOATERM, the 

SOATERM future effective date was being used. This has been corrected so that the 

greater of the SOATERM or SFAERGS (SFRFASC) dates will be used. 





Also, charges for open learning courses and extensions now use the effective date 

rule on SOATERM. Resolved in Release 7.1. 

SFKFEE1, 

SFKOLR1 

(#93021) 

When a student drops an open learning course with an extension, prior to the 

beginning of the extension, the correct refund is now given. Resolved in Release 7.1. 

SFKOLR1 (#99321) 

Refunds from SSARULE were being calculated incorrectly, because the wrong 

duration refund rule was being used. This has been corrected. Resolved in Release 


SFKPRE1 (#98909) 

An error occurred on SFAREGS, and deadlocks occurred in the registration process 

when CAPP area prerequisites were used, and the user ended the transaction via the 

Back button, the menu links, or restarted a Web session. This has been corrected. 


SFKWAI1 (#93764) 

When a student dropped a cross-listed course that had a waitlist, other students 

could register for the other cross-listed course that had no waitlist. This has been 

corrected. The student attempting to register will receive a waitlist error. Resolved 


Banner View 

SFVSTMS (#92296) 

Course status codes from STVRSTS with the Withdrawal Indicator set to Y 

(SFRSTCR_ERROR_FLAG is D) were no longer being displayed on SFAREGQ when 

used on SFAREGS. This has been corrected, and the Print on Schedule field 

determines if a course status should be displayed. Resolved in Release 7.1. 

Reports 


This problem resolution concerns three issues with sleep/wake processing. 

Corrections and enhancements have been applied to address these issues as follows: 

1. You could not use a value of % in the Process Term parameter to process 

schedules for multiple terms. 

SFRSCHD sleep/wake processing has been enhanced to support the value of 

% in the Process Term parameter. This enhancement reduces the number of 

sleep/wake processes required to support student schedule printing. 





2. When multiple terms were requested, the term printed in the page header in 

the left corner was not the correct term. (For example, when % was entered 

for Process Term, % was printed under date/time, and "ALL TERMS" was 

printed in the schedule header). 

SFRSCHD will now print either the correct term description in the centered 

page heading information when either % or a specific term is entered for the 

Process Term parameter. If the Start Range From and To Dates parameter 

values are specified, those dates will be printed in the centered heading 

information, and the literal "All Terms" will be printed in the upper left page 

header. 

3. If a student had an SFBETRM record that did not affect headcount and 

SFRSTCR records that did not count in enrollment, a schedule was printed. 

This schedule (Page 1) had no page break and was followed by a new student 

schedule on the same page labeled as Page 2. 

SFRSCHD will now incorporate the page break correctly so that the next 

student schedule begins with a new page. If a student has no course 

registration records, or if all of the existing course registration records for a 

student have course registration status codes that do not have the Print on 

Schedule checkbox checked on STVRSTS, then no schedule will be printed for 

the student if SFRSCHD is run with the ID Number parameter set to an 

individual student ID or set to COLLECTOR. 

A schedule will be printed for the student if all students are requested for a 

process term (the ID Number parameter is blank), or if the student is included 

in a population selection that is requested. In those cases, the message "* * NO 

ENROLLMENT RECORD EXISTS FOR STUDENT * *” will appear in the output. 

Please note that the STVRSTS Print on Schedule checkbox also controls which 

courses are displayed on the Registration Query Form (SFAREGQ). 



As of Release 6.0, the student schedule printed only the sections the student was 

actively registered in and did not correctly include dropped/withdrawn sections. 

This problem was caused by a change in logic in which a new view was referenced, 

and only course statuses where the Withdrawal Indicator checkbox on STVRSTS was 

unchecked were selected for printing. 

The view is no longer referenced, and the pre-6.0 logic has been reinstated, so that 

courses selected for printing in SFRSCHD are determined solely by the value of the 

Print on Schedule checkbox associated with course statuses on STVRSTS. Any 

course registration status codes (registered, dropped, withdrawn, etc.) where the 

Print on Schedule checkbox is checked will now be printed. 

Please note that a student schedule will be printed if a registration term header 

record exists (SFBETRM), regardless of the student's enrollment status (STVESTS) 





or whether any course registration records exist. If no course registration records 

exist, the message “* * NO ENROLLMENT RECORDS EXIST FOR STUDENT * *” will 

be printed in the output. 



Formatting changes had truncated the printing of the course title from the full 30 

character positions down to 28 positions. Adjustments were made in formatting and 

layout so all 30 positions will now be printed when the consolidated one line per 

course format is used (5.X format) or the expanded two line per course format is 

used (when one or more of the open learning registration parameters is set to Y). 


SFRSCHD (92346) 

The meeting type (GTVMTYP) for open learning sections did not print on the 

hardcopy student schedule output (SFRSCHD) but was displayed in the student's 

self-service schedule. This inconsistency has been addressed by modifying the 

format and layout of the student hardcopy schedule when any of the open learning 

parameters are selected. 

If one or more open learning parameters (Print Long Section Title, Print Schedule 

Type, Print Instructional Method, Print Registration Start/End Dates) is selected for 

printing, or if the report is run for multiple terms, the meeting type will print. 

In addressing outstanding 6.X defect corrections for SFRSCHD, the consolidated 

5.X one course per line format has been restored. The one course per line format 

will print as long as none of the open learning registration parameters is requested, 

and the report is run for a single term. Please note that the meeting type will not 

print in the one course per line format because of spacing restrictions. 



Multiple meeting times did not always print on the student schedule. If some 

meeting times were associated with an instructor, but others were not, only the 

meeting times associated with the instructor were printed. 

SFRSCHD has been corrected so that all meeting time information will print, 

whether instructors exist or not. Please note that multiple lines will be used to print 

multiple meeting times and/or instructors for an individual course. 

Also: 

• If meeting time information exists with buildings/rooms but no meeting times, 

TBA will be printed under the Time heading. 

• If meeting time information exists without building/room information, TBA 

will be printed under the Build and Room headings. 





• If no instructors exist for meeting times, STAFF will be printed under the 

Instructor heading. 



An alignment and formatting problem occurred when printing building 

information if days existed but no start/end times existed. Building and room 

information will now print in the correct position under the Build and Room 

headings when start/end times do exist or do not exist. Please note that when 

building and room information exists without times, TBD will be printed under the 

Time heading. Resolved in Release 7.1. 


You could not run SFRSCHD using Sleep/Wake Method One. SFRSCHD has been 

corrected to support Method One. Please note that while SunGard SCT no longer 

supports the execution of processes from the command line, processes that run in 

sleep/wake, including SFRSCHD, are supported. 

Please refer to the Banner General Technical Reference Manual for information about 

the various components of sleep/wake processing. Sleep/Wake Method One 

requires that the .dat response file must be constructed in the order in which the 

parameters are prompted for when running SFRSCHD from the command line. 

This order is different than the order of the parameters displayed in job submission 

(GJAPCTL). 

Below is a sample .dat file for SFRSCHD using Sleep/Wake Method One in 7.1: 

.dat File Value 

 

 

COLLECTOR 

Parameter Prompt (in order displayed using command line 

execution) 

Parameter Sequence Number 

Selection Identifier (population selection is not valid for 

sleep/wake processing) 

ID 

% Process Term (% for all terms, or a single term value 

such as 200510) 

 

Address Selection Date (blank assumes today's date or 

enter a specific date) 

1MA Address Hierarchy 1 

2PR 

Address Hierarchy 2 (add more lines if additional 

address hierarchies are desired) 





.dat File Value 

 

HPLAS1 

N 

Y 

Parameter Prompt (in order displayed using command line 

execution) 

Include blank line to indicate end of Address 

Hierarchies 

Printer (printer schedules will print to; enter same value 

on SOADEST, and set up the printer with the correct 

print command string on GTVPRNT) 

Process by Campus 

Run in Sleep/Wake 

300 Sleep/Wake Interval (value is number of seconds 

between sleep/wake cycles) 

 

 

Start Range From Date 

Start Range To Date 

% Schedule Type 

% Instructional Method 

N 

N 

N 

N 

Print Long Section Title 

Print Schedule Type 

Print Instructional Method 

Print Registration Start/End Dates 

Number of Lines Printed Per Page (55) 

The specific responses above will vary depending on your institution's codes and setup. 

Note: Please note that SunGard SCT strongly recommends that institutions use 

the online forms (such as GJASWPT) for initiating and maintaining 

sleep/wake processes. Please refer to the Banner General Technical Reference 

Manual for more information. Resolved in Release 7.1. 


An inconsistency existed in how course dates from SFRAREG were printed in the 

Student Schedule (SFRSCHD) for traditional versus non-traditional (open learning 

registration) courses. 





• For open learning sections, the SFRAREG_START_DATE from the “0” extension 

record and the SFRAREG_COMPLETION DATE from the maximum extension 

record will be printed for the course start and end dates. Dates associated with 

meeting time records, if they exist for an open learning course, will not be 

printed. 

• The SFRAREG start and completion dates are printed to most accurately reflect 

the time period the student is enrolled in the course. For traditional (non-open 

learning) sections, if meeting times are assigned, the start date will print the 

SSRMEET_START_DATE(s), and the end date will print the associated 

SSRMEET_END_DATE(s). 

• If meeting times are not defined for a traditional section, then the 

SSBSECT_PTRM_START_DATE and SSBSECT_PTRM_END_DATE will be printed as 

the start and end dates. If the SSBSECT start and end dates are null, then the 

SOBPTRM_START_DATE and SOBPTRM_END_DATE will be printed. 



If the user did not enter a value in the Instructional Method (%=all) parameter, the 

process would not produce any output. Instructional method is not a required 

value, and entering % or leaving the parameter blank resulted in no output. 

SFRSCHD has been modified so that the appropriate records will be selected and 

processed if none of the courses in the term are populated with an instructional 

method code, and the user enters either a % or leaves the value blank for 

Instructional Method parameter. Resolved in Release 7.1. 

SFRSCHD (#103150) 

The report will now print only the records from the SFRCBRQ collector table for a 

specific term when that term is entered in the Process Term parameter. Previously, 

records for all terms were being printed, even when a term was specified. Resolved 


SFRSLST (#102288) 

SFRSLST was using the level of the course (which may have been different than the 

level of the student) to calculate the student’s classification. When the program 

called soklibs.p_class_calc, it passed the course level from SFRSTCR, rather 

than the student level from SGBSTDN. This has been corrected to use the level 

from SGBSTDN. Resolved in Release 7.1. 

SFRWDRL (#97160) 

The Oracle error (“value larger than specified precision allows for this column”) that 

caused the report to abort has been corrected. Resolved in Release 7.1. 




Academic History Module 


Documentation 

SHAPCMP (#93975) 

The following note has been added to the form text to clarify how the degree GPA 

is processed. 

Note: Pre-Banner institutional and transfer hours entered on this form are not 

used in the calculation of the degree GPA. These course hours must be 

articulated, in order to be applied to the degree GPA. 


Forms 

SHADEGR (#100781) 

You can now create a degree record with a status of AW using the new curriculum 

processing. Resolved in Release 7.1. 

SHADEGR (#99395) 

You can now enter a major code in the Major field in the Dual Degree window 

manually or using the List of Values. Resolved in Release 7.1. 

SHARQTS (#98069) 

When transcript data was queried, the display of the query results was sorted by Last 

Name, but within Last Name, the earliest SHARQTC sequence number was being 

displayed first. The sort has been reversed so that you will now see the highest (latest 

request) listed first in the results. This matches how records are displayed on 

SHARQTC, where the latest request is the first one displayed when the form is 

entered. Resolved in Release 7.1. 


If a sent date was entered that was earlier than the print date, you were caught in a 

continual loop of pop-up error windows: "ERROR-Sent Date must be greater than the 

print date." The form never allowed you to correct the sent date, and you had to quit 

out of Banner. This has been corrected. Resolved in Release 7.1. 






When multiple instances of SHARQTS were in use, and users tried to modify the 

same data in the Sent Date field, the second instance locked up rather than 

displaying an error. An additional issue was that the Sent Date data was only saved 

when the Save option was selected from the File menu. This has been corrected. 



The query results are now displayed in name order. Previously, they were displayed 

in PIDM order. Resolved in Release 7.1. 


When selecting an ID and using the Request Detail option, the ID is now being 

carried over to SHARQTC. Also, changing the selected ID on SHARQTS and using 

the Request Detail option will now bring the selected ID to SHARQTC instead of the 

previous ID. Resolved in Release 7.1. 

SHATATC (#81466) 

The List of Values for the Level field is now properly displayed when the effective 

term of the transfer course is not equal to the effective term of the transfer 

institution established on SOABGTA. Resolved in Release 7.1. 


You can no longer set the Primary Indicator to Y for more than one record per 

effective term within the same group code. Resolved in Release 7.1. 


The Equivalencies Exist (Indicator) is now being set to Y when the equivalent course 

is entered on SHATATR, and you exit back to SHATATC. You no longer need to requery 

the form to see the indicator is set to Y. Resolved in Release 7.1. 

SHATATC, 

SHATATR 

(#82323) 

The SHATATR form no longer creates orphan records in the SHRTATC table when 

groups are changed to be non-groups. 

The following changes were made to both forms: 

• Three new, non-displayed, non-base table items have been added to the 

SHBTATC table that will hold the original group, term, and level information. 

• The Pre-Update trigger on the SHBTATC block has been modified to find the 

current SHBTATC database values for the group, term, and level (updateable 

fields) for the SHBTATC record being processed. This information is stored in 

the newly created SHBTATC block items. 





• The Post-Update trigger on the SHBTATC block has been modified to use 

these retrieved values, along with the non-updateable key values, to locate the 

corresponding records on SHRTATC, SHRTCMT, SHRICMT, and SHRTRAT, 

and then update these records with the latest group, term, and level 

information. 

The following changes were only made to SHATATR: 

• A When-Validate-Record trigger has been added on the SHBTATC block to 

ensure that a change to term, group, or level will result in the CHECK_PRIMARY 

trigger being called. 

• The CHECK_PRIMARY trigger has been modified to look for the combination of 

subject and course when determining if there is another record in the group 

with the Primary Indicator set to Y. 


SHATATR (#102546) 

When you access the List of Values for the Subject field and select the course you 

wish to use, you will no longer be prompted to save your changes and then be 

returned to the Key Block. The appropriate fields will be populated, and you can 

continue in the form. Resolved in Release 7.1. 

SHATATR (#102015) 

SHATATR will now recognize a null value in the Calendar Type and Multiplier field 

on SOABGTA as a change in rules. Resolved in Release 7.1. 

SHATATR (#77340) 

Equivalent courses could not be saved when the course had a course attribute that 

had been ended as of that term. The error "FRM-40735: POST-INSERT trigger raised 

unhandled exception ORA-01400." was displayed. This has been corrected. Resolved in 



You will no longer receive an error message stating that changes must be committed 

when performing a series of Next Block functions through the form. Resolved in 



The Rollback function no longer removes data from the Key Block fields. Using 

Rollback from the Comments block now takes you to the Key Block. Also, you no 

longer receive an error message when using a series of Next Block functions to move 

through the form. Resolved in Release 7.1. 


When duplicating a record where the Equivalence (Indicator) is set to Y, you can 

now change the indicator to N or Null and save. Previously, you received an error 

message when trying to change the value. Resolved in Release 7.1. 






When SHATATR is called from SHATAEQ, performing Exit or Cancel functions 

from SHATATR no longer invokes an Exit with Value function. SHATAEQ is not 

updated with the course information that was current on SHATATR. Resolved in 


Reports 

SHRASTD (#99569 and #99065) 

Dean's List calculations have been corrected when using combined GPAs in the rule 

on SHAACST. Resolved in Release 7.1. 

SHRASTD (#96378) 

Academic standing did not update the maximum hours for a future term when the 

current term grade and GPA hours did not count in the GPA. This has been 


SHRDEGS (#72695) 

Fields added to the SGBSTDN table were not added to the report. The 7.0 release 

introduced the sb_learner API. All inserts, updates, and deletes on SGBSTDN 

were rewritten to use the new API. This API accounts for all columns. Resolved in 


SHRDEGS (#103104) 

SHRDEGS would not run successfully in update mode (whether using a population 

selection or running in mass mode) if any student had an academic standing 

override code and a term on their latest general student record. This has been 

corrected. The sb_learner API call has been modified to send NULL academic 

standing and term values. Resolved in Release 7.1. 

SHREDIY (#103081) 

The column positions in the sediflt.dat file are now correct for the latest version 

of EDI.SMART processing. Resolved in Release 7.1. 

SHREDIY (#99568) 

In-progress coursework was not appearing in the sediflt.dat file (as it does when 

running a transcript using SHRTRTC). In-progress work will now be correctly 

included as output in the file used for the EDI transmission. Resolved in Release 7.1. 

SHREDIY (#95218) 

SHREDIY could not be run using the population selection option. This has been 

corrected, and SHREDIY will also permit the entry of multiple IDs in the job 

submission parameters. Resolved in Release 7.1. 




CAPP Module 

SHRIACT (#98501) 

SHRIACT will now count non-resident aliens correctly in its summary. Resolved in 


SHRTRTC (#101412) 

SHRTRTC no longer adds a charge to the student’s account when a transcript has 

been paid for by a credit card via a transcript request on the Web. Resolved in 


SHRTRTC (#97057) 

A transcript was printed when it should not have been: when a student had academic 

history for one course level, had only in-progress courses for a different course level, 

AL was requested on SHARQTC, and the value was cleared out of the In-Progress 

field. Now, if an in-progress cutoff term is not specified, only rolled grades will be 

considered (SFRSTCR_GRDE_DATE not null) when the report determines the levels 

for which transcripts should be printed. Resolved in Release 7.1. 

CAPP Module 

Reports 

SMRCMPL (#86381) 

All cursors that contained duplicate references to *_ATTR_CODE in the ORDER BY 

statement have been corrected to include a reference to *ATTS_CODE as well. 


SMRRULE (#98861) 

Changes have been made to the SCT_DEBUG section to correct compile errors. 


Overall 

Documentation 

SOAFOLK (#103161) 

The form documentation in the Student User Guide has been updated so that the 

Telephone fields now reflect the correct column information. The untitled fields for 

Area Code, Phone Number, and Extension now reference the SPRTELE table 

instead of the SPRADDR table. Resolved in Release 7.1. 




Overall 

Curriculum 

Curriculum 

Conversion 

(#100821) 

The curriculum conversion process for the handling of curriculum overflow values 

has been standardized. Please refer to the “Concurrent Curriculum Phase 2” 

documentation included in this release guide for more information. Resolved in 


CURRICULUM 

API (sb_curric 

ulum) 

(#100822) 

A third value has been created for the SORLCUR_ROLL_IND on SOILCUR. The radio 

group now displays Yes, No, and Default. Please refer to the “Concurrent Curriculum 

Phase 2” documentation included in this release guide for more information. 


CURRICULUM 

API (sb_curric 

ulum) 

(#100823) 

Curriculum prioritization processing has been modified to consider the effective 

term when determining the highest priority curriculum for the Learner module. 

Please refer to the “Concurrent Curriculum Phase 2” documentation included in 

this release guide for more information. Resolved in Release 7.1. 

Forms 

SOAGPAT, 

SOACRSS, 

sokb_ 

admissions1. 

sql, 

sokb_ 

admissions0 

,sql 

(#97532 and #92640) 

When an admissions application is deleted online, the process will now check to see 

if there is an SOAGPAT record for that term and application number for that ID. All 

associated rows will be deleted. This is also true for SAARRAT and SOACRSS. 


SOAGPAT (#91135) 

You can now update the School and Application Number fields by selecting a value 

from the List of Values or by entering a value directly. Resolved in Release 7.1. 

SOAHSCH, 

SOAPCOL 

(#92075) 

You can now enter GPA data, and extra trailing zeroes will not be appended. 


SOAHOLD (#45067) 

A hold type code can no longer be updated or replaced by another code when 

entered by another user. The message "field protected against update" is now displayed. 





Overall 

SOAPLAN (#95980) 

When an existing communication plan was activated or deactivated, the following 

error was received: “ERROR: Only 1 record allowed for same module, term and sequence 

number.” This has been corrected. This problem resolution is related to #77920, 

which was delivered in Release 7.0. Resolved in Release 7.1. 

SOATEST, 

sakchk1.sql 

(#101422) 

When using equivalent test score processing, the SARCHKL_CODE_VALUE is now 

updated with the test code when the checklist row is updated. Resolved in Release 


SOAXREF, 

sokxref.sql 

(#94875) 

You will no longer receive an error message that the STVNATN_DESC is an invalid 

identifier when you try to default in the nation codes for STVNATN. Resolved in 


SOAPGEO, 

SOASGEO, 

SORPGEO, 

SORSGEO 

(#96656) 

These objects have been removed from GUAOBJS. They do not exist. Resolved in 


Packages 

SOKCURR (#101957) 

An error was displayed when you attempted to use the Change Curriculum button to 

duplicate an SGASTDN record. The SORLCUR_ROLLED_SEQNO field and the 

SORLFOS_ROLLED_SEQNO field were not being set to NULL when a curriculum was 

inactivated using the Change Curriculum button in the Curriculum window. This has 

been corrected. Resolved in Release 7.1. 

SOKCUR1 (#102308) 

Uncommented out test coding has been removed from the 

sokcurr.f_MajrAttach function. Resolved in Release 7.1. 

SOKLIBS (#99105) 


Library 

SOQOLIB (#103168) 

Using the Change Curriculum button on SGASTDN and SFAREGS will now correctly 

copy the admit term, term code, and matriculation term to the new curriculum row. 





MIS Reports 

Reports 

SOPLCCV (#100762) 

If no module was entered in the job submission parameters, the process executed 

the Admissions, Recruiting, Outcome, and then Learner conversions in that order. 

Those conversion subroutines assumed that the Recruit would be printed first, then 

Admissions. If the person selected did not have one of these records to be 

converted, the print was not advanced, and the total columns for the person became 

misaligned. The solution was to move the printing of the detail in the processing, 

so that it is printed after the conversion for all modules has taken place. Resolved in 


SORCPLN (#93059 and #99867) 

Previously, SORCPLN did not assign a different communication plan for the second 

or any subsequent applications within a term. This has been corrected. The 

correction of problem resolution #93059 also corrects problem resolution #99867 

in which the same communication plan was not being assigned to an applicant in a 

different term. This has also been corrected. Resolved in Release 7.1. 

MIS Reports 

SERSBREC (#87666) 

Three parameters were required and have been made optional, as the associated 

fields in the output file are no longer required. The Prior College Attendance Begin 

Date, the Prior College Attendance End Date, and the Gain Status parameters are 

now optional. Resolved in Release 7.1. 


SB22 is now properly converted to the four digit year when the education level code 

is a number. Resolved in Release 7.1. 


For SB09, Student Residence Code, out of state students were being reported as 600 

instead of 600ss, where ss is the state of residence. This has been corrected. Resolved 


SERSMREC (#97180) 

SERSMREC is now correctly counting students who are enrolled who have 

enrollment status codes (STVESTS) other than EL. Resolved in Release 7.1. 

SERSXREC (#97302) 

SERSXREC now checks that the SSBSECT_GRADABLE_IND is set to N or NULL in the 

SXCURSOR. Resolved in Release 7.1. 




Validation 

SERSXREC (#86735) 

SERSXREC now evaluates academic history for potential grade changes to a 

student’s course. Resolved in Release 7.1. 

Validation 

Forms 

STVSBGI (#93711) 

You cannot delete a code from STVSBGI if associated child records exist on 

SOAPCOL, SOAHSCH, or SOASBGI. Previously, the system did not check for these 

records, and if codes were deleted from STVSBGI, orphan records were created. 


STVTPFD, 

sinvpfd3.sql 

(#99387) 

The sinvpfd3.sql script inserted the following incorrect values into STVTPFD: 

• S07_TEST_CODE 



The script should have inserted the following values: 

• S07_TEST_SCORE 



This has been corrected. Resolved in Release 7.1. 


Dormitory Address Creation Report (SLRDADD) 


output. 





Student Schedule Report (SFRSCHD) 


output. 

IPEDS Total Activity Report (SHRIACT) 


output. 



Section 10 - Problem Resolutions 


Dormitory Address Creation Report (SLRDADD) 

Description 

This report is used to create dormitory address information from the housing assignments. The address associated with the 

dormitory assignment is maintained in the Building Definition Form (SLABLDG). This job will create a dormitory address 

for each active room assignment that falls within the requested room assignment date. 

A check prevents a new dormitory address from being created if a record of the type selected in the parameters exists with no 

effective dates. For example, if a Dormitory Address (DO) exists with no effective dates and the Dormitory Address Creation 

Report is run for the term 199301, and a new DO address is to be created based on the person's assignments, an error message 

is generated, and no update will occur. 


Process Term Yes Enter the term code representing the term for which 

the assignments are to be created. 


(STVTERM) 

Room Assignment Date Yes Enter the date on which the assignments take effect. 

This parameter is used to specify that only those 

room assignments which are active on the date 

selected are used to create address records. 

For example, if an assignment runs from 9/1 

through 9/15, and the user enters 9/16 in this 

parameter, then the assignments will not be selected. 






Address Type Yes Enter the address type by which the created address 

should be referenced. 

Address Source No Enter the address source by which the created 

address should be referenced. 


(STVATYP) 

Address Source Validation Form 

(STVASRC) 

Report Sample—Dormitory Address Creation Report (SLRDADD) 

01-MAR-2005 11:53:56 BANNER University PAGE 1 

199610 Dormitory Address Creation SLRDADD 

210009608 Applebee, Bruce James 

27-JUL-1995 31-DEC-1995 DOAK 20 

Doak Residence Hall Room 20 

141 Harwood Road 

PO Box 55 

Newtown Square, MA 19355 

COUNTY: 020 

PHONE: 417 2345555 45AV 

210009607 Noonan, Roberta 

22-AUG-1995 14-DEC-1995 INGLE 1A 

Inglewood Apartments 1A 

Residency Lane 

Banner University 

Malvern, PA 19355 





01-MAR-2005 11:53:56 BANNER University PAGE 2 

199610 Dormitory Address Creation SLRDADD 

RPTNAME: SLRDADD 

TERM: 199610 

ROOM ASSIGNMENT DATE: 26-AUG-1995 

ADDRESS TYPE: DA 

ADDRESS SOURCE: INFR 

STUDENTS SELECTED: 2 

NUMBER OF POTENTIAL ADDRESS CREATIONS: 2 

NUMBER OF ACTUAL ADDRESSES CREATED: 2 

* * * REPORT CONTROL INFORMATION - SLRDADD - Release 7.1 * * * 





Student Schedule Report (SFRSCHD) 

Description 

This process generates the student schedule for the term. It can be requested online through the Student Course Registration 

Form (SFAREGS) or in batch through this process. You may also print a student’s schedule as part of the combined 

schedule/bill. Please see the Accounts Receivable User Guide for information on the Student Invoice/Billing Statement 

(TSRCBIL). 

Note: If SFRSCHD is run directly from SFAREGS using sleep/wake processing, the open learning processing is not used. 

The start from and to dates are used to isolate all registration records in a range. For traditional courses (which are assigned 

to a part-of-term), the part-of-term start date associated with the section is used to determine inclusion. For open learning 

courses, the start date of the original SFRAREG record for the student is used. 

If you need to isolate a portion of a term for processing, enter either a valid term or a wildcard (%) to search all terms. The 

wildcard feature is only permitted if start from and to dates are also entered. In this instance, only registration records in a 

particular term matching the date range entered would be selected. 

Term Date Range Results 

Fall 1999 

All registration records for the Fall 1999 term 

would be selected. 

Fall 1999 01-SEP-1999 to 

30-NOV-1999 

All registration records with a registration start 

date between the date range (inclusive) for the 

% 01-SEP-1999 to 

30-NOV-1999 

Fall 1999 term would be selected. 

All registration records with a registration start 

date between the date range (inclusive), 

regardless of term, would be selected. 

Note: If no meeting records (days, times, building, room) are defined for an open learning section, N/A is printed on the 

report output. 





Output Notes: 

• If the report is run for a single term, and the open learning parameters are set to N, the report prints in the one line per 

course format, unless there are multiple meeting times/instructors. 

• If the report is run for multiple terms, (and the Process Term parameter is set to %, which requires a date range), or if 

any of the open learning parameters are set to Y, a second line is generated. The course title prints below the detail line. 

• If the ID Number parameter is set to COLLECTOR, term is irrelevant. A single term code or a term value of % can be 

entered, and the date range is ignored, if entered. As mentioned above, if the open learning parameters are set to N, the 

report prints in the one line per course format. 

• Meeting type (GTVMTYP) prints on all reports, except on the one line per course format. 

• If the Print Long Section Title parameter is set to Y, the title wraps in chunks of 40 characters (40, 40, 20). 


ID Number No To request a specific schedule, enter that person's ID 

number, enter a NULL value to request all IDs, or 

enter the word "COLLECTOR" to process all 

students in the collector file. 

Process Term Yes Enter the term code representing the term for which 

schedules are to be printed, or enter % to process 

schedules for multiple terms. 


(STVTERM) 

Start Range From Date No Enter the start date for which registration records 

are to be processed. 

The term is displayed on the report for the 

registration record for use with the registration start 

date information. 






Start Range To Date No Enter the end date for which registration records are 

to be processed. 

Schedule Type (% for 

all) 

No 

Enter the schedule type code or codes for the 

sections to be processed, or enter % for all. The 

default is %. For example, you could select all 

sections with a schedule type of self-paced. 

Schedule Type Code Validation Form 

(STVSCHD) 

Instructional Method (% 

for all) 

No 

Enter the instructional method or methods for the 

sections to be processed, or enter % for all. The 

default is %. For example, you could select all 

sections with an instructional method of Web-based. 

Instructional Method Validation Form 

(GTVINSM) 

Address Selection Date No Which address, effective on this date, do you want to 

print on the student schedules. Leave blank for 

today; enter in date format DD-MON-YYYY. 

Address Hierarchy Yes Enter the address type to be printed on the student 

schedules; multiple requests are permitted and must 

be entered in priority sequence. 


(STVATYP) 

For example, 1MA 2PR will first print the mailing 

address, and if none is found, will print the 

permanent address. Enter each parameter, then hit 

Return for the next prompt. Returning with a null 

value will move you on to the next parameter. 






Printer No Enter the printer destination for schedules. 

Note: This field is required when you are running 

this report for the collector file. 

Campus Processing 

Indicator 

Yes 

Enter Y to process specific campuses. Enter N to 

process all campuses. 

Y 

N 

Specific campuses 

All campuses 

Campus No Enter the course campus for which the student 

schedules are to be produced. 

Campus Code Validation Form 

(STVCAMP) 

Note: If the Campus Processing Indicator parameter 

is set to Y, then the Campus parameter is required. 






entered. 


(GLISLCT) 









entered. 









Run in Sleep/Wake 

Mode 

No 

Enter Y to start sleep/wake cycling for this process 

and printer. 

Sleep Interval No Enter the time in seconds to process pauses before 

resuming execution. The lowest enterable value is 1. 

The highest enterable value is 999999. 

Print Long Section Title Yes Enter Y to print the long section title from the 

syllabus (SSRSYLN) or N to print the existing course 

title from the section (SSBSECT) or from SCBCRSE 

if the section title is null. The default is N. 






Print Schedule Type Yes Enter Y to print the schedule type code for the 

section on the output or N to not print the code. This 

parameter allows institutions using pre-printed 

forms to control the presentation of the data on the 

report. The default is N. 

Print Instructional 

Method 

Yes 

Enter Y to print the instructional method code for 

the section on the output or N to not print the code. 

This parameter allows institutions using pre-printed 



Print Reg Start/End 

Dates 

Yes 

Enter Y to print the registration start and end dates 

(the original registration start date and the most 

current expected completion date) for the section 

on the output or N to not print the dates. This 

parameter allows institutions using pre-printed 



Print Control Report Required Enter Y to print a control report page or N to not 

print a control report page. The default is N. 

Y 

N 

Print control page 

Do not print control page 

Report Sample—Student Schedule Report (SFRSCHD) — see the following pages 





This sample is the one line report for a single term, with all open learning parameters set to N. 

06-FEB-2005 21:01:56 BANNER University PAGE 1 

200340 Student Schedule SFRSCHD 

Spring 2003 

Jones, Jack A00027451 

123 Main Street 

Bethlehem, PA 18000 

P/T CRN SUBJ CRSE SEC CMP TITLE CREDITS LV ST DAYS TIME BUILD ROOM INSTRUCTOR 

1 1006 MUSI 110 1 M Music Theory 1 3.000 UG RE TR 1000-1130am HUM 403 Connors T 

TR 0100-0250pm HUM 103 Connors T 

TWR 0300-0430pm TBA TBA Connors T 

1 1008 ART 1100 1 M Introduction to Art 3.000 UG RE MWF 0800-0850am TBA TBA STAFF 

1 1009 ACCT 102 1 M Accounting 102 .000 UG DC MWF 0900-0950am TBA TBA Burns L 

1 1013 ASTR 100 1 M Introduction to Astronomy 3.000 UG RE MWF 0800-0850am TBA TBA STAFF 

1 1016 ANTH 6000 1 M Independent Study in Anthro 4.000 UG RE TBA TBA TBA TBA STAFF 

1 1018 POLS 485 0 M Advanced Political Science 4.000 UG RE TBA TBA TBA TBA STAFF 

CREDITS 17.000 CEUS .000 







Fall 2002 

* * * REPORT CONTROL INFORMATION - SFRSCHD - Release 7.1 * * * 

RPTNAME: SFRSCHD 

ID NUMBER: A00027451 

TERM: 200310 

START RANGE FROM DATE: 

START RANGE TO DATE: 

SCHEDULE TYPE: % 

INSTRUCTIONAL METHOD: % 

ADDRESS SELECTION DATE: 03-FEB-2005 

ADDRESS TYPE LIST: 1MA 

PROCESSED BY CAMPUS: N 

SELECTION IDENTIFIER: 

APPLICATION CODE: 

CREATOR ID: 

RUN IN SLEEP/WAKE MODE (Y/N): N 

PRINT LONG SECTION TITLE: N 

PRINT SCHEDULE TYPE: N 

PRINT INSTRUCTIONAL METHOD: N 

PRINT REGISTRATION START/END DATES: N 

PRINT CONTROL REPORT: Y 

SCHEDULE COUNT: 1 





This sample is the two line report for multiple terms with a date range, with all open learning parameters set to N. 


All Terms Student Schedule SFRSCHD 

01-JAN-2004 to 31-JAN-2005 

Jones, Jenny 123456789 

4 Country View Rd 


TERM P/T CRN SUBJ CRSE SEC CMP CREDITS LV ST MTYP DAYS TIME BUILD ROOM INSTRUCTOR 

200409 1016 ASTR 100 001 M 3.000 UG RW CLAS MWF 0800-0850am TECH 201 Bell Z 

Beginner's Astronomy CLAS MWF 0800-0850am TECH 201 Burns L 

DISC MWF 0900-0950am TBA TBA Bell Z 

DISC MWF 0900-0950am TBA TBA Burns L 

200420 1 20005 ARCH 253 001 D 2.000 UG RW TBA TBA TBA TBA STAFF 

Contemporary Architecture 

200520 20005 ARCH 500 001 A 3.000 UG RW CLAS F 1100-0100pm SCI 102 McGonagall M 

Senior Study in Architecture 

200610 1 10017 ENGL 1005 001 M 3.000 UG RW CLAS MWF 1000-1050am HUM 403 Compin S 

Literature & Composition I 

200610 1 10104 ART 36 001 M 3.000 UG RW CLAS MWF 0900-0950am TBA TBA McGonagall M 

Art of the Renaissance 








01-JAN-2004 to 31-JAN-2005 



ID NUMBER: 123456789 

TERM: % 

START RANGE FROM DATE: 01-JAN-2004 

START RANGE TO DATE: 31-JAN-2005 








CREATOR ID: 












This sample is the two line report for a single term, with Print Reg Start/End Dates set to Y. 



Spring 2003 




P/T CRN SUBJ CRSE SEC CMP CREDITS LV ST START END MTYP DAYS TIME BUILD ROOM INSTRUCTOR 

1 1006 MUSI 110 1 M 3.000 UG RE 01/01/03-03/20/03 CLAS TR 1000-1130am HUM 403 Connors T 

Music Theory 1 03/21/03-04/10/03 CLAS TR 0100-0250pm HUM 103 Connors T 

04/11/03-05/15/03 CLAS TWR 0300-0430pm TBA TBA Connors T 

1 1008 ART 1100 1 M 3.000 UG RE 01/01/03-05/01/03 CLAS MWF 0800-0850am TBA TBA STAFF 

Introduction to Art 

1 1009 ACCT 102 1 M .000 UG DC 01/01/03-05/01/03 CLAS MWF 0900-0950am TBA TBA Burns L 

Accounting 102 

1 1013 ASTR 100 1 M 3.000 UG RE 02/01/03-05/15/03 CLAS MWF 0800-0850am TBA TBA STAFF 

Introduction to Astronomy 

1 1016 ANTH 6000 1 M 4.000 UG RE 01/01/03-05/01/03 TBA TBA TBA TBA STAFF 

Independent Study in Anthro 

1 1018 POLS 485 0 M 4.000 UG RE 01/01/03-05/01/03 TBA TBA TBA TBA STAFF 

Advanced Political Science 








Fall 2002 




TERM: 200310 










CREATOR ID: 





PRINT REGISTRATION START/END DATES: Y 






This sample is the two line report for a single term, with Print Instructional Method set to Y and Print Schedule Type set to Y. 



Spring 2003 




P/T CRN SUBJ CRSE SEC CMP CREDITS LV ST SCH INSM MTYP DAYS TIME BUILD ROOM INSTRUCTOR 

1 1006 MUSI 110 1 M 3.000 UG RE L TR CLAS TR 1000-1130am HUM 403 Connors T 

Music Theory 1 CLAS TR 0100-0250pm HUM 103 Connors T 

CLAS TWR 0300-0430pm TBA TBA Connors T 

1 1008 ART 1100 1 M 3.000 UG RE L CLAS MWF 0800-0850am TBA TBA STAFF 

Introduction to Art 

1 1009 ACCT 102 1 M .000 UG DC L TR CLAS MWF 0900-0950am TBA TBA Burns L 

Accounting 102 

1 1013 ASTR 100 1 M 3.000 UG RE L WEB CLAS MWF 0800-0850am TBA TBA STAFF 

Introduction to Astronomy 

1 1016 ANTH 6000 1 M 4.000 UG RE L VIDEO TBA TBA TBA TBA STAFF 

Independent Study in Anthro 

1 1018 POLS 485 0 M 4.000 UG RE L TR TBA TBA TBA TBA STAFF 

Advanced Political Science 








Fall 2002 




TERM: 200310 










CREATOR ID: 



PRINT SCHEDULE TYPE: Y 

PRINT INSTRUCTIONAL METHOD: Y 








This sample is the two line report for a single term, with all open learning parameters set to Y. 



Spring 2003 




P/T CRN SUBJ CRSE SEC CMP CREDITS LV ST START END MTYP DAYS TIME BUILD ROOM INSTRUCTOR 

INSM SCH 

1 1006 MUSI 110 1 M 3.000 UG RE 01/01/03-03/20/03 CLAS TR 1000-1130am HUM 403 Connors T 

TR L Music Theory 1 03/21/03-04/10/03 CLAS TR 0100-0250pm HUM 103 Connors T 

04/11/03-05/15/03 CLAS TWR 0300-0430pm TBA TBA Connors T 

1 1008 ART 1100 1 M 3.000 UG RE 01/01/03-05/01/03 CLAS MWF 0800-0850am TBA TBA STAFF 

L Introduction to Art 

1 1009 ACCT 102 1 M .000 UG DC 01/01/03-05/01/03 CLAS MWF 0900-0950am TBA TBA Burns L 

TR L Accounting 102 

1 1013 ASTR 100 1 M 3.000 UG RE 02/01/03-05/15/03 CLAS MWF 0800-0850am TBA TBA STAFF 

WEB L Introduction to Astronomy 

1 1016 ANTH 6000 1 M 4.000 UG RE 01/01/03-05/01/03 TBA TBA TBA TBA STAFF 

VIDEO L Independent Study in Anthro 

1 1018 POLS 485 0 M 4.000 UG RE 01/01/03-05/01/03 TBA TBA TBA TBA STAFF 

TR L Advanced International Politics: How the 

World Works in the 21st Century 








Fall 2002 




TERM: 200310 










CREATOR ID: 


PRINT LONG SECTION TITLE: Y 










This sample is the two line report for multiple terms, with all open learning parameters set to Y. 



01-JAN-2004 to 31-JAN-2005 

Jones, Jenny 123456789 

4 Country View Rd 


TERM P/T CRN SUBJ CRSE SEC CMP CREDITS LV ST START END MTYP DAYS TIME BUILD ROOM INSTRUCTOR 

INSM SCH 

200409 1016 ASTR 100 001 M 3.000 UG RW 09/21/03-01/31/04 CLAS MWF 0800-0850am TECH 201 Bell Z 

TR L Beginner's Astronomy CLAS MWF 0800-0850am TECH 201 Burns L 

DISC MWF 0900-0950am TBA TBA Bell Z 

DISC MWF 0900-0950am TBA TBA Burns L 

200420 1 20005 ARCH 253 001 D 2.000 UG RW 02/01/04-05/31/04 TBA TBA TBA TBA STAFF 

TR L A Study of the Architecture and Interior 

Design of Frank Lloyd Wright 

200520 20005 ARCH 500 001 A 3.000 UG RW 10/21/04-03/31/05 CLAS F 1100-0100pm SCI 102 McGonagall M 

TR L Senior Study in Architecture 

200610 1 10017 ENGL 1005 001 M 3.000 UG RW 09/01/05-12/21/05 CLAS MWF 1000-1050am HUM 403 Compin S 

L Literature & Composition I 

200610 1 10104 ART 36 001 M 3.000 UG RW 09/01/05-12/21/05 CLAS MWF 0900-0950am TBA TBA McGonagall M 

TR L Art of the Renaissance 








01-JAN-2004 to 31-JAN-2005 



ID NUMBER: 123456789 

TERM: % 

START RANGE FROM DATE: 01-JAN-2004 

START RANGE TO DATE: 31-JAN-2005 








CREATOR ID: 


PRINT LONG SECTION TITLE: Y 










IPEDS Total Activity Report (SHRIACT) 

Description 

In SHRIACT, both credit hours attempted in a 12-month period and unduplicated headcount of students are shown. All 

courses that have the Applied to Degree flag in the Degree Applied Table (SHRTCKD) set to Y will be used to count credit 

hours attempted for the period specified by the parameters. 

This report looks at the information maintained in Academic History, not in Registration. Therefore, if a course has not yet 

been rolled to history, it will not be reported. 

For each course that falls within the period specified by the parameters, enrollment, total credit hours and contact hours will 

be shown. If there is no enrollment in a course, the course will not be shown. The course is broken down by the course level 

and term. The courses that should not be included in the report can be subtracted from all totals. 

Contact hours are calculated by adding the term contact hours together (lecture, lab, and other hours), as defined on the 

Basic Course Information Form (SCACRSE), and by multiplying that number by the number of students enrolled in the 

course. 

Contact Hours = (Lecture Hours + Lab Hours + Other Hours) X number of students enrolled in course 

The unduplicated headcount is calculated by taking those students who have at least one degree credit course in their 

academic history record (SHACRSE). Students are reported according to their student level. If a student has more than one 

level during a year, the student is counted by the level he/she is in the last term of the report. 






Start Date of Report 

Period 

Yes 

Enter the first day of the 12-month period covered by 

the report. Enter in date format, DD-MON-YYYY. 

End Date of Report 

Period 

Yes 

Enter the last day of the 12-month period covered by 

the report. Enter in date format, DD-MON-YYYY. 

Undergraduate Level 

Code 

Yes 

Enter the undergraduate level to be shown on the 

report. Multiple values may be entered. 


(STVLEVL) 

Graduate Level Code No Enter the graduate level to be shown on the report. 

Multiple values may be entered. 

Professional Level Code No Enter the professional level to be shown on the 

report. Multiple values may be entered. 


(STVLEVL) 


(STVLEVL) 

Effective Term of Fall 

Cohort 

Retention Term of Fall 

Cohort 

No Enter the cohort effective term for report Part G. Term Code Validation Form 

(STVTERM) 

No Enter the cohort retention term for report Part G. Term Code Validation Form 

(STVTERM) 

Full-time Fall Cohort 

Code 

No 

Enter the full-time, first-time, cohort code for report 

Part G. 

Cohort Code Validation Form 

(STVCHRT) 






Part-time Fall Cohort 

Code 

No 

Enter the part-time, first-time, cohort code for report 

Part G. 

Cohort Code Validation Form 

(STVCHRT) 

Report Format Yes Enter 1 to produce hardcopy output. Enter 2 to 

produce output in a Web upload file format. Enter 3 

to produce both formats. 3 is the default. 

1 Hardcopy output 

2 Web upload file 

3 Both 

Report Sample—IPEDS Total Activity Report (SHRIACT)—see the following pages 





Sample of Hardcopy Output 

04-MAY-2005 12:53:30 Banner University PAGE 1 

Ipeds Total Activity Report SHRIACT 

LEVEL: GR Graduate 

Degree Description Count 

BS Bachelor of Science 1 

MA Master of Arts 2 

Level Totals 3 

LEVEL: PR Professional 


CERT Certificate Program 7 


LEVEL: UG Undergraduate UG 


BA Bachelor of Arts 105 

BS Bachelor of Science 18 

MA Master of Arts 1 

BBA Bachelor of Business Admin. 1 

BSN BS in Nursing 1 

BSME Bach of Science & Mech Eng 1 

DIPL Diploma 1 

BSDD Bachelor of Science Degree 10 


Total 148 






200410 Ipeds Total Activity Report SHRIACT 


TERM: 200410 Fall 2004 Term 1 

CAMPUS: M Main 

Subject Course Enrolled Total Credits Total Contact 

DAN 101 1 4.000 0.000 

DAN 201 1 4.000 0.000 

ACCT 1122 1 3.000 0.000 

ANTH 3100 2 6.000 6.000 

ANTH 4080 3 9.000 9.000 

ECON 200 2 6.000 0.000 

FREN 2010 2 6.000 6.000 

Campus Totals 12 38.000 21.000 

Term Totals 12 38.000 21.000 





BIOL 103 1 4.000 0.000 

Campus Totals 1 4.000 0.000 

Term Totals 1 4.000 0.000 

Level Totals 13 42.000 21.000 







LEVEL: PR Professional 




GEO 199 2 2.000 0.000 

GEO 300 1 3.000 0.000 

ANTH 4080 4 12.000 12.000 

HIST 1380 3 9.000 0.000 

Campus Totals 10 26.000 12.000 

Term Totals 10 26.000 12.000 

Level Totals 10 26.000 12.000 









CAMPUS: 


ARTS 326 1 4.000 0.000 




CAMPUS: 1 Campus One 


ZOOL 1001 1 3.000 3.000 




CAMPUS: A Annandale 


BIO 101 17 68.000 0.000 

ARTH 200 2 6.000 0.000 












PE 1 6 3.000 0.000 

PE 3 4 2.000 0.000 

PE 100 4 8.000 0.000 

ART F100 2 8.000 0.000 

ART F111 1 4.000 0.000 

BOT 104 2 8.000 0.000 

BUS 200 2 6.000 0.000 

CLA 101 3 11.000 0.000 

CLA 102 3 9.000 0.000 

CLS 201 2 8.000 0.000 

GEO 199 1 1.000 0.000 

GEO 300 4 12.000 0.000 

HUM 200 7 46.000 42.000 

HUM 401 1 3.000 3.000 

HUM 500 1 6.000 2.000 

PSY 2210 1 3.000 0.000 

ACCT 210 1 3.000 3.000 

ACCT 403 2 10.000 0.000 

ACCT 1122 15 58.000 0.000 

ANIM F315 1 3.000 0.000 

ANTH 10A 1 5.000 0.000 

ANTH 3100 19 57.000 57.000 

ANTH 4080 4 12.000 12.000 

ARTS 325 10 40.000 0.000 

ARTS 326 2 8.000 0.000 

ASTR 1101 7 23.000 21.000 

ASTR F220 1 3.000 0.000 

BIOL 1205 2 8.000 0.000 

CHEM 1001 5 15.000 0.000 

CHEM 1131 2 6.000 6.000 

COMM 200 1 3.000 0.000 

DANC 100 10 20.000 0.000 

DANC 200 3 3.000 0.000 

DANC 201 3 3.000 0.000 

DANC 202 4 4.000 0.000 

DENG 88215 1 0.000 0.000 

ECON 200 14 42.000 0.000 

ECON 1102 6 18.000 18.000 

ELEC M1 1 3.000 0.000 

ENGL 112 5 15.000 0.000 

ENGL 220 1 3.000 3.000 

FREN 1010 2 6.000 6.000 

FREN 2010 5 15.000 15.000 

HIST 191 3 11.000 0.000 











HIST 1380 4 12.000 0.000 

MATH 100 1 4.000 0.000 

MATH 556 2 6.000 0.000 

MATH 0530 1 3.000 0.000 

MUSC 100 1 3.000 3.000 

NSCI 204 3 12.000 0.000 

PLSI 101 1 5.000 0.000 

PSYC 1000 1 3.000 3.000 

PSYC 2000 2 6.000 0.000 

SPAN 423 1 1.000 0.000 

STAT 2107 1 3.000 3.000 

URBN 99997 1 6.000 0.000 

URBN 99999 1 9.000 0.000 

ZOOL 1500 1 3.000 0.000 

Campus Totals 196 611.000 197.000 

Term Totals 217 692.000 200.000 





LIT II 1 4.000 4.000 

ARTH 101 4 16.000 20.000 

ASTR 1101 1 3.000 3.000 

BIOL 103 2 8.000 0.000 

DANC 101 1 2.000 2.000 

DRAM 101 2 8.000 0.000 

NSCI 103 1 4.000 4.000 

Campus Totals 12 45.000 33.000 

Term Totals 12 45.000 33.000 

Level Totals 229 737.000 233.000 











Year Totals 252 805.000 266.000 



Total Total Total 

Count Credit Hrs Contact Hrs 

Undergraduates 229 737.000 233.000 

Graduates 13 42.000 

Professionals 10 







AMERICAN 

INDIAN ASIAN 

NON- BLACK OR OR WHITE RACE/ 

LEVELS RESIDENT NON- ALASKAN PACIFIC NON- ETHNICITY GRAND TOTAL 

ALIEN HISPANIC NATIVE ISLANDER HISPANIC HISPANIC UNKNOWN ALL STUDENTS 

M F U M F U M F U M F U M F U M F U M F U M F U 

UNDERGRADUATES 1 4 0 1 3 1 0 1 0 2 2 0 2 1 1 55 59 1 2 1 1 63 71 4 

PROFESSIONALS 0 0 0 0 1 0 0 0 0 0 2 0 0 0 0 2 1 0 0 0 1 0 0 7 

GRADUATES 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 3 0 0 



* * * REPORT CONTROL INFORMATION - SHRIACT - Release 7.1 * * * 

START DATE OF REPORT PERIOD: 01-SEP-2004 

END DATE OF REPORT PERIOD: 01-JAN-2005 

UNDERGRADUATE LEVELS: UG 

GRADUATE LEVELS: LW GR 

PROFESSIONAL LEVELS: PR 

FALL COHORT EFFECTIVE TERM: 200410 

FALL COHORT RETENTION TERM: 200510 

FULL-TIME FALL COHORT CODE: FTUGTESFT 

PART-TIME FALL COHORT CODE: FTUGTESPT 

REPORT FORMAT: 1-Hard Copy; 2 Web Upload File; 3-Both: 3 

RECORD COUNT: 148 





Sample Excerpt from Web Upload Text File 














...... 

UNITID=1234,SURVSECT=EF,PART=F,REP_YEAR=2,CREDHRSU=737,CONTHRS=233,CREDHRSG=42 

UNITID=1234,SURVSECT=EF,PART=G,RET_PCF=87,RET_PCP=84

SCT Banner Student / Release Guide / 7.1

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?