SCT Banner Student / Release Guide / 7.0

SCT BannerStudentRelease GuideJanuary 2005Release 7.0

Confidential Business InformationThis documentation is proprietary information of SunGard SCT and is not to be copied, reproduced, lent or disposed of, nor used for anypurpose other than that for which it is specifically provided without the written permission of SunGard SCT.Prepared By:SunGard SCT4 Country View RoadMalvern, Pennsylvania 19355United States of America© SunGard 2004 - 2005. All rights reserved. The unauthorized possession, use, reproduction, distribution, display or disclosure of this materialor the information contained herein is prohibited.In preparing and providing this publication, SunGard SCT is not rendering legal, accounting, or other similar professional services. SunGardSCT makes no claims that an institution's use of this publication or the software for which it is provided will insure compliance with applicablefederal or state laws, rules, or regulations. Each organization should seek legal, accounting and other similar professional services fromcompetent providers of the organization's own choosing.SunGard, the SunGard logo, SCT, the SCT logo, and Banner, Campus Pipeline, Luminis, PowerCAMPUS, SCT Matrix, SCT Plus, SCT OnSiteand SCT PocketRecruiter are trademarks or registered trademarks of SunGard Data Systems Inc. or its subsidiaries in the U.S. and othercountries. All other trade names are trademarks or registered trademarks of their respective holders.

Release GuideStudent SystemIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Enhancements for 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Documentation Updates for 7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Enhancements from Interim Releases. . . . . . . . . . . . . . . . . . . . . . . . . . . 18Miscellaneous Enhancements (RPEs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Problem Resolutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Section 1 New User Interface - Functional . . . . . . . . . . . . . . . . . . 19Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Overall Changes to Form Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Tabbed Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20List of Tabbed Student Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Other Student Form/Window Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 25Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Code/Description Fields and Lists of Values . . . . . . . . . . . . . . . . . . . . . . . 27Standardization of Label Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Main Menu Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Main Menu Form (GUAGMNU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Enhanced User Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29General User Preferences Maintenance Form (GUAUPRF) . . . . . . . . . . . . . . . . 29Standardization of Identification Forms . . . . . . . . . . . . . . . . . . . . . . . . . . 32Accessibility Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Miscellaneous Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Toolbar Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Banner Bookshelf Button Removed. . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Table of ContentsChange to Keystroke Behavior of Pulldown Item Lists . . . . . . . . . . . . . . . . . . 34Color of Disabled Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Section 2 New Banner Online Help - Functional . . . . . . . . . . . . . 35Accessing Online Help from a Form . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Accessing the Help Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36The SCT Banner Help Center Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Features of Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Browsing for Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Searching for Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Using the Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Using the Field Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39How Does Online Help Affect Other Types of Help? . . . . . . . . . . . . . . . . . 40Section 3 Concurrent Curricula Phase I - Functional. . . . . . . . . . . 41Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Concurrent Curricula Foundation Goals . . . . . . . . . . . . . . . . . . . . . . . . . 42New Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43New Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43New Curriculum Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Assigning and Using Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Backfilling Curriculum Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Non-Destructive Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Attached to Major Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46New Curriculum Window and Curriculum Blocks . . . . . . . . . . . . . . . . . . . . 47Details of Concurrent Curricula Foundation . . . . . . . . . . . . . . . . . . . . . . . 47New Curriculum Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Using Priorities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Backfilling Existing Curriculum Fields (p_backload_curr). . . . . . . . . . . . . . . . . 53Curriculum API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Recruiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Admissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Admissions Decision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Student Release 7.0 January 20054 Release Guide Confidential

Table of ContentsGeneral Student - Learner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Grade Roll to Learner Outcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Academic History - Learner Outcome . . . . . . . . . . . . . . . . . . . . . . . . . . 67Conversion of Curriculum Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Overview of Concurrent Curricula Process . . . . . . . . . . . . . . . . . . . . . . . 69Creating and Updating Curriculum Data . . . . . . . . . . . . . . . . . . . . . . . . . 71Creating a Primary Curriculum with One Major and One Minor. . . . . . . . . . . . . 71Creating a Secondary Curriculum with One Major and One Concentration . . . . . . . 72Changing a Major to One within the Same Program . . . . . . . . . . . . . . . . . . . 73Changing a Major to One within a Different Program . . . . . . . . . . . . . . . . . . 74Changing a Campus Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Inactivating a Curriculum Record (Without Adding a New Record) . . . . . . . . . . . 76New Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Learner Field of Study Type Validation Form (GTVLFST) . . . . . . . . . . . . . . . . . 77Learner Curriculum Activity Validation Form (STVCACT) . . . . . . . . . . . . . . . . 77Curriculum Status Validation Form (STVCSTS) . . . . . . . . . . . . . . . . . . . . . . 78Learner Module Validation Form (STVLMOD) . . . . . . . . . . . . . . . . . . . . . . 78Learner Curriculum Query Form (SOILCUR). . . . . . . . . . . . . . . . . . . . . . . 79Learner Curriculum Activity Rules Form (SORCACT). . . . . . . . . . . . . . . . . . . 83New Curriculum Window and Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . 84Curriculum Window - (SRARECR, SAAADMS, SGASTDN, SFAREGS, SHADEGR) . . . . 84Curriculum Summary and Field of Study Summary Blocks - (SRARECR, SAAADMS,SGASTDN, SHADEGR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Curriculum and Field of Study Mini-Blocks - (SRAQUIK, SAAQUIK). . . . . . . . . . . 93Changed Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Admission Application Decision Code Validation Form (STVAPDC) . . . . . . . . . . . 94Degree Status Code Validation Form (STVDEGS) . . . . . . . . . . . . . . . . . . . . 94Student Status Code Validation Form (STVSTST) . . . . . . . . . . . . . . . . . . . . . 94Admissions Decision and Rating Batch Entry Form (SAADCBT) . . . . . . . . . . . . . 95Admissions Decision Form (SAADCRV) . . . . . . . . . . . . . . . . . . . . . . . . . 95Recruit Prospect Information Form (SRARECR). . . . . . . . . . . . . . . . . . . . . . 96Quick Recruit Form (SRAQUIK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Admissions Application Form (SAAADMS) . . . . . . . . . . . . . . . . . . . . . . . 97Quick Entry Form (SAAQUIK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98General Student Form (SGASTDN). . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Student Course Registration Form (SFAREGS) . . . . . . . . . . . . . . . . . . . . . . 99Degrees and Other Formal Awards Form (SHADEGR) . . . . . . . . . . . . . . . . . . 99Curriculum Rules Control Form (SOACTRL) . . . . . . . . . . . . . . . . . . . . . . . 100Changed Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Curriculum Rules and Control Menu (*CURRIC). . . . . . . . . . . . . . . . . . . . . 101Validation Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101January 2005 Student Release 7.0Confidential Release Guide 5

Table of ContentsNew Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Learner Curriculum Conversion Process (SOPLCCV) . . . . . . . . . . . . . . . . . . . 102Changed Reports and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103AMCAS Data Load Process (SAPAMAL) . . . . . . . . . . . . . . . . . . . . . . . . . 103Admission Decision Criteria Report (SARBDSN) . . . . . . . . . . . . . . . . . . . . . 103Elec App Verify/Load Process (SARETMT) . . . . . . . . . . . . . . . . . . . . . . . . 103Degree Status Update Report (SHRDEGS) . . . . . . . . . . . . . . . . . . . . . . . . 104Grade Roll to Academic History (SHRROLL) . . . . . . . . . . . . . . . . . . . . . . . 104Student Type Update Report (SHRTYPE) . . . . . . . . . . . . . . . . . . . . . . . . . 104Report Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Learner Curriculum Conversion Process (SOPLCCV) . . . . . . . . . . . . . . . . . . . 104Section 4 New Value-Based Security and PersonallyIdentifiable Information Security Using Fine-GrainedAccess Control - Functional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Using This Enhancement with Banner Student . . . . . . . . . . . . . . . . . . . . . 112Banner Student VBS Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Banner Student Institutional Example Using VBS. . . . . . . . . . . . . . . . . . . . . 113Banner Student PII Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Banner Student Institutional Example for PII . . . . . . . . . . . . . . . . . . . . . . . 115How to Use Banner Student VBS Domains. . . . . . . . . . . . . . . . . . . . . . . . 116How to Use Banner General VBS Domains with Student . . . . . . . . . . . . . . . . 139Changed Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Overall Error Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Person Search Form (SOAIDEN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Obsolete Form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Value-Based Security Person Access Query Form (SOIVPAC) . . . . . . . . . . . . . . 144Changed Menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Student System Management Menu (*SMANAGER) . . . . . . . . . . . . . . . . . . . 144Section 5 Common Matching - Functional . . . . . . . . . . . . . . . . . . 145Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Setting Up Common Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Student Release 7.0 January 20056 Release Guide Confidential

Table of ContentsHow the New Matching Process Works . . . . . . . . . . . . . . . . . . . . . . . . . 148New Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Matched Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Potentially Matched Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Rule Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Matching Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149How the Algorithm Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Forms Used with Matching Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Common Matching Entry Form (GOAMTCH) . . . . . . . . . . . . . . . . . . . . . . 156General Person Identification Form (SPAIDEN) . . . . . . . . . . . . . . . . . . . . . 158Quick Recruit Form (SRAQUIK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Quick Entry Form (SAAQUIK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Data Loads Used with Matching Process. . . . . . . . . . . . . . . . . . . . . . . . . 160Electronic Prospect Inquiry Form (SRIPREL) . . . . . . . . . . . . . . . . . . . . . . . 160Electronic Prospect Match (SRRSRIN) and Migrate Electronic Prospects Process(SRRPREL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Electronic Application Process Form (SAAEAPS) . . . . . . . . . . . . . . . . . . . . . 162Online Transcripts Activity List Form (SHAEDIS) . . . . . . . . . . . . . . . . . . . . . 164New Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Common Matching Entry Form (GOAMTCH) . . . . . . . . . . . . . . . . . . . . . . 165Changed Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176General Person Identification Form (SPAIDEN) . . . . . . . . . . . . . . . . . . . . . 176Quick Recruit Form (SRAQUIK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Electronic Prospect Inquiry Form (SRIPREL) . . . . . . . . . . . . . . . . . . . . . . . 177Quick Entry Form (SAAQUIK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Electronic Application Process Form (SAAEAPS) . . . . . . . . . . . . . . . . . . . . . 177Online Transcripts Activity List Form (SHAEDIS) . . . . . . . . . . . . . . . . . . . . . 177Person Search Form (SOAIDEN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Person Search Detail Form (SOAIDNS) . . . . . . . . . . . . . . . . . . . . . . . . . 178Tape Interface Rules Form (SOAINFR) . . . . . . . . . . . . . . . . . . . . . . . . . . 178Interface Validation Form (STVINFC) . . . . . . . . . . . . . . . . . . . . . . . . . . 178Electronic Applicant Web Default Rules Form (SAAWADF) . . . . . . . . . . . . . . . 178Electronic Prospect Validation Form (STVPREL) . . . . . . . . . . . . . . . . . . . . . 178Obsolete Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179First Name Translation Rules Form (SOANAME) . . . . . . . . . . . . . . . . . . . . . 179Person Matching Form (SOQMTCH). . . . . . . . . . . . . . . . . . . . . . . . . . . 179Prospect Matching Form (SRQMTCH) . . . . . . . . . . . . . . . . . . . . . . . . . . 179January 2005 Student Release 7.0Confidential Release Guide 7

Table of ContentsChanged Menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179General Person (*PERSON) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Search Tape Control Menu (*SEARCHCONT) . . . . . . . . . . . . . . . . . . . . . . 179Student System Management Menu (*SMANAGER) . . . . . . . . . . . . . . . . . . . 179Forms Not on Menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Changed Reports and Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Electronic Prospect Match (SRRSRIN) . . . . . . . . . . . . . . . . . . . . . . . . . . 180Elec App Verify/Load Process (SARETMT) . . . . . . . . . . . . . . . . . . . . . . . . 180Report Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Elec App Verify/Load Process (SARETMT) . . . . . . . . . . . . . . . . . . . . . . . . 180Section 6 Improved Drop/Withdrawal Processing(Defect 49132) - Functional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189New Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Automatic Drops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Administrative Drops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192New Rules on GTVSDAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Changed Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195Process Control Code Validation Form (STVPROC) . . . . . . . . . . . . . . . . . . . 195Course Registration Status Code Validation Form (STVRSTS) . . . . . . . . . . . . . . . 195Section Registration Status Codes Form (SSARULE). . . . . . . . . . . . . . . . . . . . 196Student Course Registration Form (SFAREGS) . . . . . . . . . . . . . . . . . . . . . . 196Student Course Registration Audit Form (SFASTCA) . . . . . . . . . . . . . . . . . . . 196Web Display List Customization Form (SOAWDSP) . . . . . . . . . . . . . . . . . . . 196New Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197Registration Admin Messages Report (SFRRGAM) . . . . . . . . . . . . . . . . . . . . 197Section 7 Concurrent Curricula Phase 1 - Technical . . . . . . . . . . . 199Curricula Checking and APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199New Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Learner Field of Study Type Validation Table (GTVLFST) . . . . . . . . . . . . . . . . . 203Learner Curriculum Activity Status Table (STVCACT). . . . . . . . . . . . . . . . . . . 203Curriculum Status Validation Table (STVCSTS) . . . . . . . . . . . . . . . . . . . . . . 203Learner Module Validation Table (STVLMOD) . . . . . . . . . . . . . . . . . . . . . . 203Curriculum Activity Status Rules Table (SOBCACT) . . . . . . . . . . . . . . . . . . . 203Student Release 7.0 January 20058 Release Guide Confidential

Table of ContentsLearner Curriculum Frequency Rules Table (SOBLMOD) . . . . . . . . . . . . . . . . 204Learner Curricula Table (SORLCUR) . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Field of Study Table (SORFLOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205Changed Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Admission Application Decision Code Validation Table (STVAPDC). . . . . . . . . . . 206Degree Status Code Validation Table (STVDEGS) . . . . . . . . . . . . . . . . . . . . 206Student Status Code Validation Table (STVSTST) . . . . . . . . . . . . . . . . . . . . . 207Recruiting Base Table (SRBRECR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Admissions Application Repeating Table (SARADAP) . . . . . . . . . . . . . . . . . . 208Student Base Table (SGBSTDN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209Degree Table (SHRDGMR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211New Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212SOKLCUR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Curriculum Conversion Using Functions. . . . . . . . . . . . . . . . . . . . . . . . . 215Changed Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216SRKPREL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216SAKDCSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216SAKL010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216SAKMODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217SAKQADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217SHKMODS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217SHKROLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218SOKCURR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218SOKCMSG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219New Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220p_backload_curr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220p_convert_curr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220p_push_recruit_curriculum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220p_push_decision_curriculum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220p_default_status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221p_push_degree_curriculum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Changed Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221p_insert_srbrecr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221p_create_recruit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222p_create_applicant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222p_create_student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222New Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222f_current_lfos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222f_lfos_rowid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222f_lfos_priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223f_current_lcur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223f_lcur_rowid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223January 2005 Student Release 7.0Confidential Release Guide 9

Table of Contentsf_lcur_priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223f_count_lcur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224f_count_lfos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224New Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224Seed Data Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224New Triggers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225call_curriculum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225enable_curriculum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225disable_curriculum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225post_forms_commit_trg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Changed Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Admissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226General Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226New Indexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227SORLCUR_KEY_INDEX on SORLCUR . . . . . . . . . . . . . . . . . . . . . . . . . . 227SORLFOS_KEY_INDEX on SORLFOS . . . . . . . . . . . . . . . . . . . . . . . . . . 227New Primary Key Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227pk_gtvlfst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227pk_stvcsts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227pk_stvcact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227pk_stvlmod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227pk_soblmod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228pk_sobcact. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228pk_sorlcur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228pk_sorlfos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228New Foreign Key Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228New Banner Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Curriculum Base View (SOVLCUR) . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Field of Study View (SOVLFOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Changed Object Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231GOQOLIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231SOQOLIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Seed Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Learner Field of Study Type Validation Table (GTVLFST) . . . . . . . . . . . . . . . . . 231Learner Curriculum Activity Status Table (STVCACT). . . . . . . . . . . . . . . . . . . 232Curriculum Status Validation Table (STVCSTS) . . . . . . . . . . . . . . . . . . . . . . 232Student Release 7.0 January 200510 Release Guide Confidential

Table of ContentsLearner Module Validation Table (STVLMOD) . . . . . . . . . . . . . . . . . . . . . . 233Curriculum Activity Status Rules Table (SOBCACT) . . . . . . . . . . . . . . . . . . . 233Learner Curriculum Frequency Rules Table (SOBLMOD) . . . . . . . . . . . . . . . . 233Section 8 New Value-Based Security and PersonallyIdentifiable Information Security Using Fine-GrainedAccess Control - Technical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Changed Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Person Identification/Name Repeating Table (SPRIDEN) . . . . . . . . . . . . . . . . . 235Changed Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Obsolete Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Obsolete Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Obsolete Banner Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Changed Object:Access Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Seed Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Domain Driver Table Seed Data for GORFDMN. . . . . . . . . . . . . . . . . . . . . 242VBS Policy Table Seed Data (GORFDPL). . . . . . . . . . . . . . . . . . . . . . . . . 243PII Policy Table (GORFDPI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Section 9 Common Matching - Technical. . . . . . . . . . . . . . . . . . . 259New Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Student Common Matching Match Entry Temporary Table (SOTCMME) . . . . . . . . . 259Changed Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260Interface Code Validation Table (STVINFC) . . . . . . . . . . . . . . . . . . . . . . . 260Obsolete Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260Interface Rules Repeating Table (SORINFR) . . . . . . . . . . . . . . . . . . . . . . . 260First Name Translation Rules Table (SORNAME) . . . . . . . . . . . . . . . . . . . . . 260Changed Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260SAKQADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260SAKMTCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261January 2005 Student Release 7.0Confidential Release Guide 11

Table of ContentsNew Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262stvinfc1.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262igorname70.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262Section 10 APIs - Technical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263API Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263APIs Used in Banner Student . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264SARADAP API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265SCBCRSE API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266SFBETRM API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267SFRSTCR API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268SGBSTDN API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269SHRDGMR API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270SIBINST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270SIRASGN API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271SLBRMAP API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272SLRMASG API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272SLRPASG API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273SLRRMAT API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273SOBCACT API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273SOBLMOD API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274SOBTERM API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274SORLCUR API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276SORLFOS API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277SRBRECR API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278SSBSECT API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279APIs Used in Banner General With Student Forms and Tables . . . . . . . . . . . . 280Changed Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281Section 11 Improved Drop/Withdrawal Processing(Defect 49132) - Technical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283New Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Registration Administrative Message Temporary Table (SFTRGAM). . . . . . . . . . . . 283Student Release 7.0 January 200512 Release Guide Confidential

Table of ContentsChanged Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Course Registration Status Code Validation Table (STVRSTS). . . . . . . . . . . . . . . 283Registration Temporary Table (SFTREGS). . . . . . . . . . . . . . . . . . . . . . . . . 284Student Course Registration Archive Table (SFRSTCA) . . . . . . . . . . . . . . . . . . 284New Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284sfkedit.p_connected_group_edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284sfkedit.p_group_edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284sfkedit.p_update_regs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285sfkedit.p_web_group_edits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285sfkmods.p_admin_msgs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285sfkmods.p_delete_sftrgam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285sfkmods.p_insert_sftrgam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285sfkmods.p_insert_sftrgam_capp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285sfkmods.p_reset_sftregs_fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285sfkmods.p_set_sftregs_error_link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285sfkmods.p_swap_rsts_codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286Changed Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286sfkfunc.p_check_corq_sftregs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286sfkfunc.p_check_dupl_sftregs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286sfkfunc.p_check_link_sftregs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286sfkfunc.p_check_maxh_sftregs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287sfkfunc.p_check_time_sftregs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287sfkmods.p_insert_sftregs_from_stcr . . . . . . . . . . . . . . . . . . . . . . . . . . . 287sfkpreq.p_open_all_courses_c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287sfkpreq.p_open_conc_courses_c . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288sfkpreq.p_open_registration_c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288sfkpreq.p_prerequisitecheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288sfkpreq.p_update_registration_msg . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Obsolete Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288sfkedit.p_final_edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288New Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289sfkfunc.f_autodrop_setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289sfkfunc.f_do_admindrop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289sfkfunc.f_fatal_error_count . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289sfkfunc.f_get_capp_tech_error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289sfkfunc.f_get_rsts_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289Changed Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289sfkfunc.f_registration_access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289New Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290sinsproc.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290sinssdax.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290sinsvtab.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290January 2005 Student Release 7.0Confidential Release Guide 13

Table of ContentsChanged Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290sfttreg0.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290sfttreg1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290sfttreg2.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291sftstcr0.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291sftstcr1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291sftstcr2.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291sfkcurs.drop_problems_c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291sfkcurs.scrgmodc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291sfkcurs.scrlevlc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292sfkcurs.rstsrowc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292New Record Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292sfkcurs.drop_problems_rec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292New PLSQL Table Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292sfkcurs.drop_problems_rec_tabtype . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Changed View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293sftregs_v.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293Section 12 Miscellaneous Enhancements . . . . . . . . . . . . . . . . . . . 295New Banner Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295Changed Object Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295New Course Maintenance Form (SHATCKN) . . . . . . . . . . . . . . . . . . . . . . 296Validation Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296RPEs for Student. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297Term Code Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298Oracle 9.2 Order By Modifications in Release 6.2 . . . . . . . . . . . . . . . . . . . 299Oracle 9.2 Order By Modifications in Release 6.1 . . . . . . . . . . . . . . . . . . . 299Recruiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301Electronic Prospect Match (SRRSRIN) . . . . . . . . . . . . . . . . . . . . . . . . . . 301Admissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Electronic Admissions Person Table (SARPERS). . . . . . . . . . . . . . . . . . . . . . 304Electronic Application Report (SARETBL) . . . . . . . . . . . . . . . . . . . . . . . . 304Package sakmtch.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305Student Release 7.0 January 200514 Release Guide Confidential

Table of ContentsPCU Tape Load Regulatory Winter 2005 Updates . . . . . . . . . . . . . . . . . . . 305AMCAS Regulatory Fall 2004 Updates . . . . . . . . . . . . . . . . . . . . . . . . . . 306SAT Tape Load Regulatory Fall 2004 Updates . . . . . . . . . . . . . . . . . . . . . . 307ACT Tape Load Regulatory Fall 2004 Updates . . . . . . . . . . . . . . . . . . . . . 311ACT EOS Search Tape Regulatory Fall 2004 Updates . . . . . . . . . . . . . . . . . 313Tape Load Regulatory Fall 2003 Updates . . . . . . . . . . . . . . . . . . . . . . . . 314IPEDS Regulatory Fall/Winter 2003 Updates . . . . . . . . . . . . . . . . . . . . . . 314Racial/Ethnic Status Report (SHRIETH). . . . . . . . . . . . . . . . . . . . . . . . . . 314Section 13 Problem Resolutions . . . . . . . . . . . . . . . . . . . . . . . . . 317Catalog Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317Schedule Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318Course Request and Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323General Person Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324Support Services Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325Faculty Load Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326Location Management Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326Recruiting Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330Admissions Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336General Student Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344Registration Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346Academic History Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367CAPP Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388Overall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395January 2005 Student Release 7.0Confidential Release Guide 15

Table of ContentsMIS Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402FTES Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404Report Sample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405Electronic Application Report (SARETBL) . . . . . . . . . . . . . . . . . . . . . . . . 405Student Release 7.0 January 200516 Release Guide Confidential

IntroductionIntroductionThis document describes Release 7.0 of the Banner Student System. Thefollowing information is included in Release 7.0.Enhancements for 7.0The following enhancements are new for Release 7.0.New User InterfaceChanges were made to the user interface to enhance form usability. consistency, andaccessibility for layout, field tags, buttons, navigation, Lists of Values, tabbedwindows, and other items.New Banner Online HelpOnline help is being delivered for Banner form, field, and procedural/taskdocumentation. This help system runs in a Web browser.Concurrent Curricula - Phase 1Phase 1 of the Concurrent Curricula enhancement allows an institution to recordand use multiple curricula for a person as they move through the student cycle. Thisphase delivers the table and API structure used by concurrent curricula to store themultiple curricula.New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access ControlThe new Value-Based Security (VBS) using Fine-Grained Access Control (FGAC)provides functionality that replaces existing Value-Based Security processing. NewValue-Based Security and Personally Identifiable Information Security (PII) areused with Student product domains to secure data and restrict access toinformation.Common MatchingThe Common Matching enhancement is used to prevent the creation of multiplePIDMs in Banner. Basic person APIs are used to provide common logic for PIDMcreation. Common Matching checks for possible database matches before newrecords are inserted, whether new records are created by data loaded in batch orentered online.January 2005 Student Release 7.0Confidential Release Guide 17

IntroductionAPIsApplication Programming Interfaces (APIs) are used to facilitate the integration ofSCT Banner with other applications on campus and simplify code by encapsulatingbusiness logic in database packages. An API is a central program that creates,updates, and deletes data. APIs also execute and validate business rules beforeinserting or updating information.Documentation Updates for 7.0Chapter 2, Using Banner, has been removed from the Student User Guide. Thisinformation can now be found in the SCT Banner Getting Started Guide.Chapter 1, Database Schematics, has been removed from the Student TRM Supplement.This information can now be found in the Entity Relationship Diagrams (ERDs)available on the ActionWeb.Enhancements from Interim ReleasesThe following enhancements were contained in interim releases. They aresummarized in this document with references to detailed information contained inthe SCT Banner Student User Guide and the Student Object:Access Reporting Guide.sRelease Contents Release Date6.2 Tape Load Regulatory Updates, ProblemResolutionsAugust 20046.1 Improved Drop/Withdrawal Processing December 2003Miscellaneous Enhancements (RPEs)This section lists RPEs and small enhancements by module. This section alsoincludes AMCAS, tape load, and IPEDS regulatory updates.Problem ResolutionsThis section contains descriptions of problem resolutions by module.Student Release 7.0 January 200518 Release Guide Confidential

Section I New User Interface - FunctionalOverviewSection INew User Interface - FunctionalOverviewRelease 7.0 features a new user interface. Components of the interface aredescribed in this section.Note: Information about how SunGard SCT implemented the 7.0 userinterface changes is contained in the 7.0 UI Methodology Handbook.Overall Changes to Form LayoutMany changes have been made to improve the usability of Banner forms. Improvedalignment of screen elements, including the Key Block, Description fields, and fieldlabels, enhances overall readability. More code is visible for all Code, ID, and SSN/SIN/TIN fields as a result of field expansion, and all elements are grouped logicallyon the form. Block headings are labeled consistently. Labels, checkboxes, and radiobuttons are now easier to read and select. Called forms have been positioned todisplay more of the calling form, when appropriate.Buttons were enhanced as well. At the top of a column for fields that have both alabel and a button, the label now always appears on top of the button. Additionally,buttons have “tool tips” that pop up when the mouse is on top of them.Navigation between forms was also improved. When in the Go To field on theGeneral Menu (GUAGMNU), the Up and Down arrow keys enable you to navigateto recently accessed forms. Choose the Display Navigation Window key (F5) fromany form to quickly navigate to any other form.Note: The Display Navigation Window key does not work in query mode.January 2005 Student Release 7.0Confidential Release Guide 19

Section I New User Interface - FunctionalTabbed InterfaceOther changes to overall form layout are described below.• Improved screen resolution—1025x768 screen resolution allows ample roomfor displaying user interface components. This enhancement eliminated manyscrolling or stacked canvases.• Consistency with Luminis—The new Banner user interface displays the colorsand style of the Luminis UI.• Consistent Confidential and Deceased messages—For most Banner products, thesemessages always appear on the top left of the first line of the form.Note: Banner Advancement displays Deceased Spouse messages on the right sideof the form. Banner Human Resources does not display messages on thetop left of the form.Tabbed InterfaceSelected forms now have a tabbed interface rather than the traditional Bannerwindow appearance. Tabs are used to arrange information in a meaningful way, andallow you to navigate easily between groups or blocks of information. You can selectthe tab, use the Ctrl and Tab keys, or use the Next Block and Previous Blockfunctions. Tab titles reflect the contents of a particular window or grouping ofinformation.For tabbed forms that contain windows of parent/child information, the main tabappears in the top row. The dependent information appears on tabs lower on thewindow and below the top-level tab to which the information is related.Student Release 7.0 January 200520 Release Guide Confidential

Section I New User Interface - FunctionalTabbed InterfaceUse any of the following to navigate within tabbed forms:• Control-Tab moves forward, and Control-Shift-Tab moves backward through thetabs on a form.• Control-Page Up moves forward, and Control-Page Down moves backwardthrough the tabs.• The List Tab Pages key (F2) displays a list of other tabbed windows on the form.Use the mouse or the Up and Down arrow keys to select a different tab. Forforms that have tabs within a tabbed window, navigation is based on thelocation of the cursor when List Tab Pages is selected.Note: Some forms have only one tab because they call a window which is now apart of GOQCLIB. For information about these changes, refer to theStandardization of Identification Forms section of this document.List of Tabbed Student FormsThe following Student forms use the tabbed design. The chart below lists the newtabs and notes where secondary windows have been combined or removed.Form Tabs Other Window ChangesSAAADMS • Application• Curricula• Fees, Mail Submission,Withdrawal Data• Checklist• Sources, Interests, Comments• Contacts, Cohorts, AttributesSAADCBT • Batch Entry• Assign Ratings• The Primary Curriculum and SecondaryCurriculum windows have been removed. Theinformation from those windows is now displayed inthe new Curriculum window which is accessed bythe Curricula tab.• The Checklist Summary and Checklist Detailswindows have been combined into the Checklistwindow.• The Additional Information, WithdrawalInstitution, Application Fee Information, and MailSubmission windows have been combined into onewindow accessed by the Fees, Mail Submission,Withdrawal Data tab.N/AJanuary 2005 Student Release 7.0Confidential Release Guide 21

Section I New User Interface - FunctionalTabbed InterfaceForm Tabs Other Window ChangesSAADCRVIn the Application Summary block:• Decision Processing• High School Review• Prior College and DegreeReview• Test Score ReviewIn the Decision Data block:N/A• Application Decision• Application Decision Letter• Decision Calculator• Rating ReviewSAAEAPS • Electronic Applications• Verification Steps• Review Results• Change PINSAAQUIK • Quick Admit• AddressesSAAWADF • Default Curriculum• E-mail and Credit Card Rules• Matching and QuickStart Rules• Web Signature LettersN/A• The Primary Curriculum window has beenremoved. The information from that window is nowdisplayed in the Curricula Summary and Field ofStudy Summary blocks in the main window.• The Application Information window has beenremoved. Information from that window is nowdisplayed in the Applicant and Recruit Informationblock in the main window.• The Delivery Point Information window has beenremoved. Information from that window is nowdisplayed in the Addresses window which isaccessed by the Addresses tab.• The Checklist Email Link window and the CreditCard Rules window have been combined into onewindow accessed by the E-mail and Credit CardRules tab.• The Web Matching Rules window and theAutomated Processing Rules window have beencombined into one window accessed by theMatching and QuickStart Rules tab.Student Release 7.0 January 200522 Release Guide Confidential

Section I New User Interface - FunctionalTabbed InterfaceForm Tabs Other Window ChangesSFAREGS • Registration• Student Term• Curricula• Time StatusSGASTDN • Learner• Curricula• Activities• Veteran• Comments• Academic and GraduationStatus, Dual Degree• MiscellaneousSHADEGR • Learner Outcome• Curricula• Dual Degree• Honors• Institutional Courses• Transfer Courses• Non-Course Work• Course Attributes• The Student Information window has beenrenamed the Student Term window. Theinformation from this window is now displayed ineither the Student Term window or in the newCurriculum window.• The new Curriculum window has been added and isaccessed by the Curricula tab.• The Student Information block has been renamedthe General Learner block.• The Primary Curriculum and SecondaryCurriculum windows have been removed. Theinformation from those windows is now displayed inthe new Curriculum window which is accessed bythe Curricula tab.• The Student Activity window is now called theLearner window.• The Academic Status, Graduation Data, and DualDegree windows have been combined into onewindow accessed by the Academic and GraduationStatus, Dual Degree tab.• The Additional Student Information window hasbeen removed. The information from that windowis now displayed in the Additional Informationblock of the main window.• The Primary Curriculum and SecondaryCurriculum windows have been removed. Theinformation from those windows is now displayed inthe new Curriculum window which is accessed bythe Curricula tab.• The Degree Information block in the main windowhas been renamed the Learner OutcomeInformation block.January 2005 Student Release 7.0Confidential Release Guide 23

Section I New User Interface - FunctionalTabbed InterfaceForm Tabs Other Window ChangesSPAIDEN • Current Identification• Alternate Identification• Address• Telephone• Biographical• E-mail• Emergency Contact• The ID and Name Source Information window hasbeen removed. The information from this windowis now displayed in the ID and Name Source blockin the main window.• The Legal Name window has been removed. Theinformation from this window is now displayed inthe Person block in the main window.• The Delivery Information window has beenremoved. The information from this window is nowdisplayed in the Address window accessed by theAddress tab.• New windows have been added to display telephoneinformation from SPATELE, biographicalinformation from SPAPERS, email informationfrom GOAEMAL, and emergency contactinformation from SPAEMRG. These windows areaccessed by the Telephone, Biographical, E-mail,and Emergency Contact tabs respectively.SPATELE • Telephone • The Telephone tab has been added so the maininformation block is displayed as a secondarytabbed window on SPAIDEN.SPAPERS • Biographical • The Biographical tab has been added so the maininformation block is displayed as a secondarytabbed window on SPAIDEN.SPAEMRG • Emergency Contact • The Emergency Contact tab has been added so themain information block is displayed as a secondarytabbed window on SPAIDEN.SOACURR • Base Curriculum Rules• Majors and Departments• Rule-Based Concentrations *• Minors• Module ControlSOAHSCH • High School Details• High School Subjects• High School AddressSOAPCOL • Prior College and Degree• Majors, Minors, Concentrations• Prior College Address• * On the secondary windows, the Rule-BasedConcentrations tab is named Major-DependantConcentrations.N/AN/AStudent Release 7.0 January 200524 Release Guide Confidential

Section I New User Interface - FunctionalTabbed InterfaceForm Tabs Other Window ChangesSRAPREL • Electronic Prospect Detail• Test Scores and Interests• Requested MaterialsSRAQUIK • Quick Recruit• Addresses• Interests, Sources, Contacts• Default OptionsSRARECR • Recruit• Curricula• Sources and Interests• Contacts, Cohorts, Attributes• Comments and LearnedN/A• The Address Bar Code window has been removed.The information from this window is now displayedin the Addresses window which is accessed by theAddresses tab.• The Additional Information window has beenremoved. The information from that window is nowdisplayed in the Recruit Data block of the mainwindow.• The Withdrawal Institution window has beenremoved. The information from that window is nowdisplayed in the Recruit Data block in the mainwindow.• The Primary Curriculum window has beenremoved. The information from that window is nowdisplayed in the new Curriculum window which isaccessed by the Curricula tab.Other Student Form/Window ChangesThe following forms have been modified to display all blocks in one main window.Previously, they were comprised of multiple windows.FormSFIWDRLSFQSECTSHACRSESHATATCWindow ChangesThe Comments window has been removed. The information fromthat window is now displayed in the main window.The Override Information window has been removed. Theinformation from that window is now displayed in the mainwindow.The Course Title window has been removed. The informationfrom that window is now displayed in the main window.The Transfer Course Comments window has been removed. Theinformation from that window is now displayed in the mainwindow in the Comments block.January 2005 Student Release 7.0Confidential Release Guide 25

Section I New User Interface - FunctionalOptionsFormSHATATRSLARMATSLIAEVNSOACRSSSOAGPATSOATERMSSASECTSSATEXTSSASYLBSUAMAILWindow ChangesThe Institution Course Attributes and Institution CourseComments windows have been removed. The information fromthese windows is now displayed in the main window in theAttributes block and the Comments block.The Roommate Room Attributes window has been removed. Theinformation from that window is now displayed in the RoommateRoom Attributes block in the main window.The Available Rooms window has been removed. The informationfrom that window is now displayed in the Available Rooms block inthe main window.The School Name window has been removed. The informationfrom that window is now displayed in the main window.The School Name window has been removed. The informationfrom that window is now displayed in the main window.The Web Display Controls window has been removed. Theinformation from that window is now displayed in the WebProcessing Controls window.The Attendance Method Information and the Additional CreditCard Hour Information windows have been removed. Theinformation contained in those windows is now displayed in themain window.The Long Comments window has been removed. The informationfrom that window is now displayed in the main window.The Technical Requirements window has been removed. Theinformation from that window is now displayed in the RequiredMaterials window.The Mail Additional Information window has been removed. Theinformation from that window is now displayed in the mainwindow.OptionsThe available options can now be accessed by right-clicking on a form fromanywhere on the blank canvas (not from a field).This list contains Rollback, Save, Exit,Print, and Add to Personal Menu, as well as any form-specific options.Student Release 7.0 January 200526 Release Guide Confidential

Section I New User Interface - FunctionalCode/Description Fields and Lists of ValuesTip: In order to see the form on the personal menu which has been added throughthe Option List window, you must first refresh the menu by either clicking the Menulink on GUAGMNU or entering refresh in the Go To field.If the Search button opens an Option List window, you are now able to tab amongthe choices and use the Enter key or space bar to make your selection.Code/Description Fields and Lists of ValuesWhen you double-click in a Code/Description field, the List of Values (LOV) forthat field will open. When you double-click on a field other than Code/Descriptionthat has an LOV, the LOV will not open.Note: This functionality existed in Banner 6.x, but the non-Code/Descriptionfields had a Search button then, rather than the 7.0 button. The fieldslooked different in version 6.x, but the double-click functionality was thesame.Tip: Changing the color of Code/Description fields with User Preferences can helpyou visually identify fields in which double-clicking will invoke an LOV.Standardization of Label TextIncreased screen size allows for clearer labels. As a result, many field labels are nowspelled out. When abbreviations are necessary, they have been standardized acrossBanner. Conversely, redundant labels have been eliminated.For example, a field in Banner Student could have been named Web Ind. The fieldlabel would now read Web Indicator. Or a field could have been named Sys Req. Thefield label would now read System Required. Also, some fields have been renamedfor clarity or consistency. For example, the CEU Hours field on SHATPRT is nowcalled the CEU Units field.Main Menu ChangesMany changes have been made to the main menu, including toolbar changes,improved navigation with the Go To feature, and options to create links to favoriteURLs or forms using My Links.January 2005 Student Release 7.0Confidential Release Guide 27

Section I New User Interface - FunctionalMain Menu ChangesMain Menu Form (GUAGMNU)Toolbar ChangesThe entire toolbar is now accessible from the main menu.Menu NavigationThe Go field is now named the Go To field.Note: In order for Banner to log security violations more effectively, you can nolonger search for an object using the code/description search from thisfield. You can still search by using the List of Values button, and thenperforming your search on GUIOBJS.You can now launch a QuickFlow directly from the Go To field, rather than firstbeing directed to the QuickFlow Form (GUAQFLW).The Products field is now a pulldown menu that expands the menu for the selectedproduct. The Menu and Site Map buttons are now links.The Help Center link accesses the SCT Banner Help Center. Refer to New BannerOnline Help for information about the new help system.My LinksThe Change Banner Password link goes to the Oracle Password Change Form(GUAPSWD), where you can change your password.The Check Banner Message link takes you to the Banner Message Form(GUAMESG), where you can view your messages. A green checkmark appears nextto the link when you initially log in and have pending messages, or whenever a newmessage arrives. The pop-up alert for new messages is no longer displayed.Personal links enable you to create up to six links to favorite URLs or often-usedBanner objects. Refer to the Enhanced User Preferences section of this document forinformation about creating personal links.The My Institution section is designed to reflect your institution’s Web site andpicture. Your DBA or site administrator can log in as the baseline user and set up thedefault web site link on GUAUPRF. Any user can change his/her link by accessingGUAUPRF and changing the value in the User Value field for the My Institutionrecord.Note: The default image can be changed by replacing the appropriate image inthe banicons.jar file delivered with Banner. The image must be 163 x141 pixels, or Banner will distort it to fit.Student Release 7.0 January 200528 Release Guide Confidential

Section I New User Interface - FunctionalEnhanced User PreferencesBroadcast MessagesThe Broadcast Message button on the toolbar becomes enabled whenever youreceive a broadcast message. You can view your message(s) in the BroadcastMessages section at the bottom of the screen.Users with a security class of Broadcast can send broadcast messages to all users. Tosend a broadcast message, create it on GUAMESG as usual, and choose BASELINEas the recipient.Enhanced User PreferencesAlthough Banner now features the colors and style of Luminis, you have the optionof customizing the colors via the General User Preferences Maintenance Form(GUAUPRF). Custom colors can be specified at the site level, by logging in as thebaseline user and changing the values in the Default Value fields, and also at theindividual user level, by changing the values in the User Value fields.Note: Most of the changes you make on this form appear immediately on allBanner forms; however, the General Menu Form (GUAGMNU) will notdisplay changed title bar preferences for form name, release number, ordatabase instance until you log out and log back in.General User Preferences Maintenance Form (GUAUPRF)Many changes have been made to this form for Release 7.0. Baseline users now havethe option to cancel out of a change prior to saving it. Additionally, all changes madewhile logged in as the baseline user are saved in the GURTPRF table. Lastly, newusers who are added to the database initially have the same user preferences as thebaseline ID.Note: Existing users’ records will no longer be removed from the GURTPRFtable when the baseline user’s preferences are updated.Display Options WindowThe Form Name Display Option pulldown list has been changed to the DisplayForm Name on Menu checkbox.Options (checkboxes) related to the client/server environment have beenremoved:January 2005 Student Release 7.0Confidential Release Guide 29

Section I New User Interface - FunctionalEnhanced User Preferences• Display Horizontal Toolbar—Resized canvas has eliminated the need for thisoption.• Display Vertical Toolbar—Resized canvas has eliminated the need for thisoption.• Display Bubble Help—Bubble Help has been replaced with tool tips, whichalways display.New Alert Options enable you to customize how you are prompted by Banner for thefollowing:• Prompt Before Exiting Banner—Check this box if you want Banner to verifythat you want to quit the Banner session before exiting.• Display Additional Confidential Warning—Check this box if you want Bannerto display an extra Confidential message for records that contain confidentialinformation.• Display Additional Deceased Warning—Check this box if you want Banner todisplay an extra Deceased message for records associated with a deceasedperson.You can use the User Interface Color Settings to customize the color of the followingitems:• Buttons, such as Cancel and OK (buttons in the toolbar are not included).• Canvas of all forms• Record highlighting• Scroll and separator bars• Code/Description prompts• Canvases within the main menu, including the broadcast message, menu, andmenu tree canvasesTo change the color of an item at the user level:1. Go to User Interface Color Settings section of the Display Options window.2. In the User Value field for the item you want to change, choose a color.Note: You can select a pre-defined color from the palette, or create your ownshade by using HSB (Hue Saturation Brightness) or RGB (Red GreenBlue) values.3. Select OK.4. Save.Note: SunGard SCT delivers the default values as seed data. If you change thedefault colors as the baseline user, all users who have not set colors at theindividual user level will see the baseline colors you selected.Student Release 7.0 January 200530 Release Guide Confidential

Section I New User Interface - FunctionalEnhanced User PreferencesDirectory Options WindowThe option for specifying the location of a client/server path to write the dataextract file to has been removed.Specifying a locationA directory option for specifying the location of your Banner ID images has beenadded. These are the images that appear on the Personal Image Form (GUAIMGE)for an ID when you select Help>Display ID Image.To specify a location:1. Access GUAUPRF as the baseline user.2. Select the Directory Options tab to access the Directory Options window.3. Find the Enter the location of your Banner ID images record.4. Enter the location of your image directory in the User Value field.5. Save your changes.Creating a personal linkYou can create a link from the main menu to a Web site or Banner object usingPersonal Links. Make sure you do not have pop-ups blocked with any third-partysoftware. Pop-up blockers can interfere with the performance of your personal links.To create a link:1. Go to the General User Preferences Maintenance Form (GUAUPRF).2. Choose the My Links tab to access the My Links window.3. Enter a description of your link in the User Value field associated with the firstpersonal link description.4. Enter the URL or Banner object name in the User Value field associated withthe first personal link URL or Banner object.5. Save. You must exit Banner and log back in to see your changes.Note: You can create up to six personal links. Each personal link is comprisedof two records—the description and the URL/object. Make sure thedescription record matches the corresponding URL or Banner objectrecord. The following example illustrates a personal link for a weatherWeb site.January 2005 Student Release 7.0Confidential Release Guide 31

Section I New User Interface - FunctionalStandardization of Identification FormsField Name Name of Your Link URL or Banner objectDescriptionDefault ValueEnter the description for the“My Personal Link 1” link.Your first personal linkdescriptionEnter the URL or Bannerobject for the “My PersonalLink 1” link.Your first personal link URL orBanner objectUser Value My weather page www.weather.comStandardization of Identification FormsThe new General Common Library (GOQCLIB) allows all identification forms inBanner to share the same code and basic layout, which includes a tabbed interface(refer to the Tabbed Interface section for details). This includes the General PersonIdentification Form (SPAIDEN).The following windows are a part of GOQCLIB. Any changes you make to thewindows included in this library will appear in all forms that use them.• Current IDNote: A name change on the Current ID window will not display in the KeyBlock until the user returns to the Key Block or accesses another window withinthe form.• Alternate ID• Address• Telephone• Biographical• E-mail• Emergency ContactAdditional Student forms that use these windows are listed below. Your institutionmay use these windows on custom forms as well.• Quick Entry Form (SAAQUIK)• Emergency Contact Form (SPAEMRG)• General Person Identification Form (SPAPERS)• General Person Telephone Form (SPATELE)• Quick Recruit Form (SRAQUIK)Note: If a form calls only one of the windows, then it may have only one tab.Student Release 7.0 January 200532 Release Guide Confidential

Section I New User Interface - FunctionalAccessibility EnhancementsAccessibility EnhancementsSeveral enhancements have been made to improve the accessibility of Banner forms:• When using keystrokes to access an Option List that is called from a button, youcan now use Tab and Shift-Tab to navigate through the options. Use the Enterkey to select the option.• Whenever possible, the word "Information" has been removed from blockheadings.Miscellaneous EnhancementsToolbar ButtonsNew buttons have been added to the toolbar:• The Broadcast Message button becomes enabled when new system-widemessage(s) are available.• The Fine-Grained Access Control Security button becomes enabled if there areany FGAC rules active for the user in the database.The Graph Information and Show Keys buttons have been removed from thetoolbar.Banner Bookshelf Button RemovedThe Banner Bookshelf button has been removed from the toolbar. Enhancements tothe Adobe Reader ® search feature only work when files are launched within theReader application and not when Reader is launched within a browser window.Maximum performance of search and index features is achieved by setting up ashortcut on your desktop to where the Bookshelf file is located at your institution.To create a shortcut to the Banner Bookshelf on your desktop:1. Open Windows Explorer.2. Browse to the location where the Bookshelf directory is stored at yourinstitution (bdoc5x, bdoc6x, or bdoc7x, depending upon the version of Banneryou are using).3. Right click bkshlfxx.pdf, and choose Create Shortcut.January 2005 Student Release 7.0Confidential Release Guide 33

Section I New User Interface - FunctionalMiscellaneous Enhancements4. Drag the shortcut to your desktop.5. (Optional) Rename it.Change to Keystroke Behavior of Pulldown Item ListsTo expand a pulldown menu so that it displays all available list items at once, use theAlt and Down arrow keys simultaneously. Once the list is expanded, you can scrollthrough the list using the Up and Down arrow keys (in previous versions of OracleForms, the Down arrow key expanded the list).Tip: You can use the arrow keys to scroll through the items one at a time, regardlessof whether the list is expanded.In Student, some forms with Data/No Data buttons that were used to accesssecondary windows may now have a Select field in place of the buttons. You can usethe pulldown options from the Select field to access the secondary windows. Anexample of this can be found on SAAETBL.Color of Disabled TextAs delivered, disabled text is black (the same as regular text), but you can change itto any color you'd like. For more information, please refer to the Oracle Developer forSCT Banner Implementation Guide.Student Release 7.0 January 200534 Release Guide Confidential

Section 2 New Banner Online Help - FunctionalSection 2New Banner Online Help - FunctionalRelease 7.0 features a new online help system that contains information about formsand fields, as well as tasks you can perform with Banner. This help system runs in aWeb browser, and is available by choosing the Online Help button on the toolbar orthe Online Help option from the Help pulldown menu. Additionally, you can accessonline help by selecting the Help Center link on the main menu.Online help will be updated to coincide with deliveries of the Banner Bookshelf(approximately twice a year). Information about installing and configuring onlinehelp is contained in the Oracle Developer for SCT Banner Implementation Guide.Note: The Online Help button, Help Center link, and Online Help option fromthe Help pulldown menu are active upon installation of the 7.0 release,but do not lead to any online help content. Online help content will beavailable for download in Spring 2005 via the ActionWeb. In themeantime, your site administrator can download and install aplaceholder online help system according to the instructions in theBanner General 7.0 Release Guide.The new help system is not currently designed to be customized. Any changes madeto help files will be overwritten by subsequent deliveries of online help. SunGardSCT recommends maintaining customized information in Local Dynamic Helpwithin Banner.Tip: For forms with no help, the Banner online help error page may not appear forInternet Explorer users who use IE’s “friendly” error messages by default. Foroptimal performance in IE, clear the Show friendly HTTP error messages checkboxthat is located on the Advanced tab of your Internet Options.January 2005 Student Release 7.0Confidential Release Guide 35

Section 2 New Banner Online Help - FunctionalAccessing Online Help from a FormAccessing Online Help from a FormThe Online Help button and Help menu option initially display information aboutthe form on which you are working:Accessing the Help CenterIf you want information about forms and tasks for another Banner product, use theHelp Center link, which is available from the main menu of Banner, or fromanywhere within the help system.From the Main MenuFrom Within the Help SystemStudent Release 7.0 January 200536 Release Guide Confidential

Section 2 New Banner Online Help - FunctionalFeatures of Online HelpThe SCT Banner Help Center PageFrom either the main menu or within the help system, the Help Center appears:Note: Only products that are licensed at your site appear on the Help Centerpage.Features of Online HelpYou can browse, search, and use the index to locate topics in online help.Browsing for TopicsThe Contents tab and the bread crumb trail both enable you to browse for topicscategorically. Form and field information is organized by Banner module. Taskinformation is contained under the Procedures heading.January 2005 Student Release 7.0Confidential Release Guide 37

Section 2 New Banner Online Help - FunctionalFeatures of Online HelpBrowsing with the Contents tabSearching for TopicsThe Search tab allows you to search for topics within the help system. You can alsouse your browser’s “search on page” feature to find specific text on a help page.Searching with the Search tabStudent Release 7.0 January 200538 Release Guide Confidential

Section 2 New Banner Online Help - FunctionalFeatures of Online HelpUsing the IndexThe Index tab provides an alphabetical listing of topics within the help system.When you enter the letters of a term, the index will scroll through the topics to theclosest alphabetical match.Searching with the Index tabUsing the Field LinkMany form descriptions are quite long, so sometimes you will find a link that goes tofield descriptions on a separate page.Using the field linkJanuary 2005 Student Release 7.0Confidential Release Guide 39

Section 2 New Banner Online Help - FunctionalHow Does Online Help Affect Other Types of Help?How Does Online Help Affect Other Types of Help?The new online help replaces the WinHelp online help introduced in Release 4.0.All content from WinHelp has been incorporated in the new online help.No changes are planned for the Banner Bookshelf as a result of the new online help.The PDF files that comprise the Bookshelf are the most efficient way to print Bannerdocumentation for reference.For 7.0, SCT-delivered Dynamic Help will not change, but eventually, SunGard SCTplans to phase it out. Local Dynamic Help and Item Properties (choices availablefrom the Help pulldown menu in Banner) both display column information whenit is available. There are no plans to phase out Local Dynamic Help.Student Release 7.0 January 200540 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalOverviewSection 3Concurrent Curricula Phase I - FunctionalThis enhancement is new for Release 7.0.OverviewThe concurrent curricula enhancement allows an institution to record and usemultiple curricula for a person as they move through the student cycle. Phase I ofthis enhancement delivers the structure used by concurrent curricula to store themultiple curricula. This structure provides a means to maintain a completehistorical picture of a person’s curricula. This phase does not provide newfunctionality that uses the multiple curricula, although it does allow you toimmediately store unlimited curricula.Curriculum data is being moved out of the Recruiting, Admissions, GeneralStudent, and Academic History tables, into two separate, distinct curriculum tables.One table allows for the entry of unlimited curricula, while the other storesunlimited majors, minors, and concentrations per curriculum. Curricula can beprioritized as primary, secondary, etc. and are controlled by rules on SOACTRL asto the number of curricula, majors, minors, and concentrations that can be attachedto a record.Along with new database objects delivered with this enhancement, ApplicationProgramming Interfaces (APIs) are used to update the original curricula columnsso that existing processes will continue to recognize and reference the originalcurriculum data (two majors, two minors, six concentrations). In a 7.x release,functionality and rules will be implemented to allow for the tracking and use ofconcurrent curricula. At that time, the API used to update the original curriculacolumns will be desupported.The Banner 7.0 lays the foundation for concurrent curricula. The following updatesare included in the release:• Two new tables are delivered to store all curriculum data for a learner.• A new data entry window has been created to allow the entry of unlimitedcurricula (concurrent curricula), as well as unlimited majors, minors, andconcentrations associated with a curriculum.• A backfill process is used to update the original curriculum columns so thatexisting processes will continue to function in the same way as in Banner 6.X.All existing Banner baseline processes will continue to read curriculuminformation from the existing primary and secondary curriculum fields, ratherthan from the associated fields in the new tables.January 2005 Student Release 7.0Confidential Release Guide 41

Section 3 Concurrent Curricula Phase I - FunctionalConcurrent Curricula Foundation Goals• The Curriculum Rules Control Form (SOACTRL) has been modified to allowinstitutions to restrict how much curriculum data can be entered by users.SunGard SCT suggests that clients continue to restrict the number ofcurriculum records that can be active concurrently to just a primary andsecondary curriculum.CAPP does not use the new table structure at this time.Note: For the purpose of this enhancement, we are now referring to studentsas “learners”, the General Student module as the “Learner module”, andto academic history as the “learner outcome”.Concurrent Curricula Foundation GoalsThe goals of this first phase or foundation of Concurrent Curricula are to:• Move the curriculum data from the current tables (SRBRECR, SARADAP,SGBSTDN, SHRDGMR) into a centralized table structure (SORLCUR - basecurriculum, SORLFOS - field of study) used by all modules.• Implement a key structure where each row of curriculum data isassociated with its corresponding module.• Implement a database structure that allows the entry of unlimitedcurricula (with unlimited majors, minors, and concentrations).• Build a bridge back to the curriculum fields on SRBRECR, SARADAP,SGBSTDN, and SHRDGMR.• Insert curriculum data into the new structure.• Backfill the old curriculum columns in SRBRECR, SARADAP, SGBSTDN,and SHRDGMR with the curriculum data that has been added to the newSORLCUR and SORLFOS tables.• Allow forms and reports to continue to reference the current tablestructure (SRBRECR, SARADAP, SGBSTDN, SHRDGMR) for curriculuminformation.• Provide basic table APIs for Recruit, Applicant, General Learner, and LearnerOutcome (that will create, update, and delete rows from the correspondingtables), and provide separate table APIs for the new curriculum tables.• Deliver modified Banner objects (SRARECR, SRAQUIK, SAAADMS,SAAQUIK, SGASTDN, SFAREGS, SHADEGR) that use the APIs for Recruit,Applicant, General Learner, and Learner Outcome and the curriculum tables.• Use a centralized curriculum user interface.• Allow all existing forms (SRARECR, SRAQUIK, SAAADMS, SAAQUIK,SFAREGS, SGASTDN, SHADEGR) that maintain curriculum data toreference the same curriculum data through a central curriculumwindow.Student Release 7.0 January 200542 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalNew Concepts• Have the new inquiry form (SOILCUR) reference the same curriculumwindow, in query-only mode.• Provide conversion scripts for Recruit, Applicant, General Learner, andLearner Outcome curriculum data to move existing curriculum data to thenew table structure. These scripts can be executed in batch or automaticallyfrom forms when it is determined that the person’s curriculum data has not yetbeen converted.New ConceptsThe Concurrent Curricula Foundation project introduces several new concepts thatwill require attention during the implementation of Banner 7.0. These concepts are:• new terminology• new curriculum tables• assignment of priorities to curricula and fields of study• backfill of curriculum data• non-destructive updates• Attached to Major field• status codes• new Curriculum window and Curriculum Summary blockNew TerminologyAs of Banner 7.0, we are referring to students as "learners," and to academic historyas the "learner outcome."• “Learner” was chosen to encompass both the traditional student (someone 18- 22 years of age pursuing an undergraduate degree), as well as the personpursuing additional education for a variety of reasons such as work or personalfulfillment.• “Outcome” identifies the result a learner expects to obtain after theireducational experience with the institution (i.e., degree, certificate, etc.).This change exists within each form and within the documentation but does notaffect form names (i.e., SGASTDN is still the General Student Form) or menunames. This change also does not affect the overall name of the product (i.e, SCTBanner Student).January 2005 Student Release 7.0Confidential Release Guide 43

Section 3 Concurrent Curricula Phase I - FunctionalNew ConceptsNew Curriculum TablesTwo separate tables are now used to store base curriculum data and field of studydata. These tables are SORLCUR and SORLFOS. Base curriculum data stored in theSORLCUR table includes: program, level, college, degree, and campus, while theSORLFOS table stores the majors, minors, and concentrations. The SORLCURtable contains a Module field which identifies the module (RECRUIT, ADMISSIONS,LEARNER, OUTCOME) in which the curriculum data was created. In addition, theSORLCUR table contains a Key Sequence Number field that ties the curriculumrecord to its corresponding recruiting (recruit sequence number), application(application number), or degree (degree sequence number) record. TheSORLFOS table includes a Type field which indicates if the row is for a major, minor,or concentration. The table structure now allows for unlimited occurrences of bothtypes of information.You can decide the number of curricula and fields of study you want to allow to beentered per module. The data counts for the maximums currently allowed aredelivered as seed data. They are: two curricula (one for recruiting), two majors, twominors, and six concentrations. These counts can be increased or decreased onSOACTRL, in the new Number of Curricula Allowed block, where you can specifyby module the number of curricula, majors, minors, and concentrations that can beentered. Curricula are backfilled to the existing Student tables up to the deliveredcounts.Assigning and Using PrioritiesWhen a learner is enrolled in multiple concurrent curricula, a method must exist tocategorize or organize those multiple curricula as they relate to one another. A newfield (Priority) will be used to accomplish this. The Priority field will also be usedin Banner 7.0 to identify which curriculum is the primary curriculum, which is thesecondary curriculum, and so forth. This is necessary to support the backfill of thenew curriculum information into the existing curriculum columns in theRecruiting, Admissions, Learner (General Student), and Outcome (AcademicHistory degree) table structures (the structures as they exist in Banner 6.X).Although the Banner 7.0 release allows institutions to enter more curricula than willbe backfilled into the existing curriculum fields, SunGard SCT suggests that clientscontinue to restrict the number of curriculum that can be active concurrently to justa primary and secondary curriculum. All existing Banner baseline processes(transcript, enrollment verification, registration restrictions, Web display, NSLCreporting, etc.) will continue to read curriculum information from the existingprimary and secondary curriculum fields rather than the associated fields in the newtables.Student Release 7.0 January 200544 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalNew ConceptsBackfilling Curriculum DataIn Banner 7.0, the backfill of curriculum information into the existing tablestructures is handled by the new Curriculum API (application programminginterface). The API will update the original curriculum columns so that existingprocesses will continue to function in the same way as in Banner 6.X. The Banner6.X curriculum structure allows for two concurrent active curricula, each with up totwo majors, two minors, and six concentrations, with the exception of Recruiting.Recruiting allows for one curriculum. All Banner 7.0 baseline processes (transcript,enrollment verification, registration restrictions, Web display, NSLC reporting, etc.)will continue to reference curriculum information from the Banner 6.X tables.Although the Banner 7.0 release allows institutions to enter more curricula than willbe backfilled into the existing curriculum fields, SunGard SCT suggests thatinstitutions continue to restrict the number of curriculum records that can be activeconcurrently to just a primary and secondary curriculum.Note: Even if your institution changes the values in SOACTRL to allow morecurricula, majors, minors, and/or concentrations than are currentlyallowed in Banner 6.X, only the number allowed in Banner 6.X will bebackfilled. The backfill only populates fields that existed in Banner 6.X.Non-Destructive UpdatesThe new Curriculum window supports non-destructive updates. The purpose ofnon-destructive updates is to maintain a history of all changes to a learner'scurriculum. For this reason, no updates are allowed to existing curriculum and fieldof study records. The process to update existing curriculum information is toduplicate the existing record and then update the newly created record with theappropriate changes (i.e., to inactivate the record and indicate why it wasinactivated). Then the user must add a new record to represent the learner's newor current curriculum. The user is allowed to delete curriculum and field of studyrecords. Institutions are encouraged to establish a policy on retaining historicalrecords.Attached to Major FieldThe Field of Study block in the Curriculum window contains a field called Attachedto Major. This field is used to identify the major to which a concentration isattached. If a field of study row is being entered, and the Type field has a value ofCONCENTRATION, then the Attached to Major field will be enabled. If curriculumchecking is turned on (using SOACTRL), when the user selects the Search featureon the Attached to Major field, those majors will be displayed:• that have been entered so far in the Field of Study blockand• that the concentration is attached to based on the corresponding curriculumrule.January 2005 Student Release 7.0Confidential Release Guide 45

Section 3 Concurrent Curricula Phase I - FunctionalDetails of Concurrent Curricula FoundationFor 7.0, the Priority field also has a secondary use. It is used to determine how tobackfill curriculum data from the new curriculum tables to the existing primary andsecondary curriculum fields. The backfill algorithm and its use of the prioritynumber are discussed later in this section.Examples of the New Curriculum Tables And Using PrioritiesIn the example, the following processing occurs:1. The SORLCUR row with a priority of 1 (Program is BA_UG) will be selected bythe backfill algorithm to become the primary curriculum for applicationnumber 1: as it has the lowest priority number, it is the row with the highestSORLCUR sequence number for that priority, and it is active. This curriculumis for application number 1, because the STVLMOD code is ADMISSIONS, andthe key sequence number is 1.2. The SORLFOS row for a Major of ART is tied to its SORLCUR row by use ofthe SORLCUR sequence number field. (See 1 ** in the examples below.) EachSORLCUR sequence number is unique, so it can only refer to one SORLCURrow. This row will become the Major1 for the primary curriculum: as it has thelowest priority, it has the highest SORLFOS sequence number row for thatpriority, and it is active.3. The SORLFOS row for a Major of ENGL is also tied its SORLCUR row by itsSORLCUR sequence number. (See 1 ** in the examples below.) It will becomeMajor2 for the primary curriculum, because: it has the next lowest prioritynumber after the Major of ART row, it has an LFOS type of MAJOR, and it isactive.4. The SORLCUR row with a priority of 2 (Program is BS_UG) will be selected bythe backfill algorithm as the secondary curriculum, because its row has thenext lowest priority number after the BA_UG row. It will have a Major1 of BUSI,as there is only one SORLFOS row attached to it (by the SORLCUR sequencenumber of 2), that is the most recent and is active. (See 2 *** in the examplesbelow.)SORLCURLMOD Term Key Seq LCURSeqPriority Program Level Camp College Degree ActivityStatusADM * 200510 1 1 ** 1 BA_UG UG AS BA ACTIVEADM * 200510 1 2 *** 2 BS_UG AS BS ACTIVE* In the LMOD column, the ADM value is an abbreviation for the learner modulecode ADMISSIONS.Student Release 7.0 January 200548 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalDetails of Concurrent Curricula FoundationSORLFOSLFOSTypeTermLFOSSeqLCURSeqPriorityLFOSCodeActivityStatusCurriculum StatusMAJOR 200510 1 1 ** 1 ART ACTIVE INPROGRESSMAJOR 200510 2 1 ** 2 ENGL ACTIVE INPROGRESSMAJOR 200510 3 2 *** 1 BUSI ACTIVE INPROGRESSStatus CodesTwo new kinds of status codes are used with concurrent curricula.• Curriculum activity status codes are maintained on STVCACT. These statuscodes are assigned a value of active or inactive on SORCACT. A curriculum orfield of study row can be designated as active or inactive using the CurriculumActivity Status Code field. Possible values are: ACTIVE, INACTIVE, orREMOVED.• Curriculum statuses codes are maintained on STVCSTS. These statuses areused to associate actions on the student’s record with an SORLFOS record andexist only on the Field of Study block. For example, when a learner initiallyapplies for a major of English, the curriculum status code on the SORLFOS rowwill be INPROGRESS. If the student decides to instead apply for Art History, theuser might now set the curriculum status code on the English row to beCHANGED or CHANGED MAJOR. Delivered values are: APPACCEPT, APPLIED,AWARDED, CHANGED, COMPLETED, DENIED, INPROGRESS, INSTACCEPT,PENDING, or SOUGHT.Automatic curriculum status code updates take place in Recruiting, Admissions,General Student, and Academic History. When status codes are “updated” ordecisions entered, the appropriate rows in the SORLCUR and SORLFOS tables areduplicated, and a new curriculum status is entered on the new row. You candetermine which curriculum status codes are to be mapped to each status ordecision code. If none are mapped, then default values will be used instead.• The curriculum status code for a recruit's major is automatically “updated” toAPPLIED if the recruit applies for admission to the same curriculum (term,college, level, and degree).• The curriculum status for the applicant is “updated” in Admissions when adecision is entered on an application. When a decision is entered, the activeSORLFOS rows for the application are duplicated. The curriculum status codeentered on these duplicated rows comes from the curriculum status codeassociated with the decision code on STVAPDC. If no curriculum status codehas been associated with the decision code, then seed data values are used forapplications that are accepted by the institution or applicant or are denied.January 2005 Student Release 7.0Confidential Release Guide 49

Section 3 Concurrent Curricula Phase I - FunctionalDetails of Concurrent Curricula Foundation• The curriculum status for the learner is updated in General Student based onthe student status. These codes come from STVSTST. If no valid codes exist onSTVSTST, then no updated curriculum row will be created.• The curriculum status for the learner outcome is updated in Academic Historywhen the degree status is modified. These codes come from STVDEGS. Seeddata values are used when a degree status is changed to awarded, and no validcodes exist on STVDEGS.For example, when a student’s application is institutionally accepted, the mostrecent SORLFOS rows with that application sequence number (key sequencenumber) will be duplicated if they are active, and the new curriculum status will bederived from STVAPDC. If no curriculum status code has been associated with the“institution acceptance” decision code, a curriculum status code of INSTACCEPTwill be used. This gives the institution a complete picture of the student’scurriculum. In addition, as functionality is added to use the new curriculum data,actions may take place at the curriculum level, as well as the application level.Curricula Status and Curricula Activity Status DefaultsThe following table illustrates how the curriculum status codes and curriculumactivity status codes are defaulted during processing.Activity Module Object Description Status Source Activity Status CurriculumStatusCreateRecordRecruitingSRARECR,SRAQUIKNew curriculum orfield of study addedACTIVEINPROGRESSDuplicateRecordRecruitingSRARECR,SRAQUIKCurriculum or fieldof study duplicatedValues clearedon new recordValues clearedon new recordNew recruitcreatedRecruitingSAAQUIK,SAKQADMWeb quickadmitRequest to addrecruit duringquick admitACTIVEAPPLIEDNew recruitcreatedRecruitingSAAQUIK,SAKQADMWeb quickadmitRequest to addrecruit duringquick admit, butapplication is notcreatedACTIVEINPROGRESSNewapplicationcreatedRecruitingSAKMODS.p_create_application,SAAADMSNew applicationcreated, recruitfield of study withsame major,curriculum term,level, and degree isduplicatedACTIVEAPPLIEDStudent Release 7.0 January 200550 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalDetails of Concurrent Curricula FoundationActivity Module Object Description Status Source Activity Status CurriculumStatusNew recruitaddedRecruiting SRKPREL New recruit addedvia data load or Webprospects,application notcreatedACTIVEINPROGRESSNew recruitaddedRecruiting SRKPREL New recruit addedvia data load or Webprospects,application createdACTIVEAPPLIEDRecruitrecordconvertedRecruitingSOILCUR,SRARECR,SRAQUIK,SRKPREL,SAAQUIK,SORLCCVConversion fromSRBRECR toSORLCUR,SORLFOSQueries SARADAPto find match withterm, level, degree,majorACTIVEAPPLIEDRecruitrecordconvertedRecruitingSOILCUR,SRARECR,SRAQUIK,SRKPREL,SAAQUIK,SORLCCVConversion fromSRBRECR toSORLCUR,SORLFOSNo SARADAPmatchACTIVEINPROGRESSCreateRecordAdmissions SAAADMS New curriculum orfield of study addedACTIVEINPROGRESSDuplicateRecordAdmissions SAAADMS Curriculum or fieldof study duplicatedValues clearedon new recordValues clearedon new recordNewapplicationcreatedAdmissions SAAQUIK Request to addapplication duringquick admit, useadmissionapplicationdecision code onSAAQUIKACTIVESTDNACCEPTNewapplicationcreatedAdmissions SAKL010 Push WebapplicationACTIVEINPROGRESSNewapplicationcreatedAdmissions SRKPREL New applicationadded through dataloadACTIVEINPROGRESSDecisionmadeAdmissionsSAADCRV,SARDCSN,SAADCBT,SARBDSN,SAKQADM(Web quickadmit)Decision enteredfor application,admissions field ofstudy copied, newstatus enteredACTIVEDerived fromSTVAPDC. *January 2005 Student Release 7.0Confidential Release Guide 51

Section 3 Concurrent Curricula Phase I - FunctionalDetails of Concurrent Curricula FoundationActivity Module Object Description Status Source Activity Status CurriculumStatus* If no curriculum status code has been associated with the decision code entered, the curriculum statusdefaults to INSTACCEPT if the decision is significant decision and institution accept. It defaults to STDNACEPTif the decision is significant decision and student accept. It defaults to DENIED if the decision is significantdecision and rejected. If none apply, no action is taken.ApplicationrecordconvertedAdmissionsSOILCUR,SAAADMS,SAAQUIK,SAADCRV,SAADCBT,SAKL010,SORLCCVSARADAP rowsconverted toSORLCUR andSORLFOSACTIVEDerived fromSTVAPDC **** If no decisions are made for the application, use INPROGRESS. If the decision has been made, usecurriculum status mapped to latest decision code entered on STVAPDC. If no values exist on STVAPDC,defaults to INSTACCEPT if significant decision and institution accept. Defaults to STDNACCEPT if significantdecision and student accept. Defaults to DENIED, if decision is significant decision and is rejected.CreateRecordLEARNERSAAQUIK,SGASTDN,SFAREGS,SAKQADM(Web quickadmit)New curriculum orfield of study addedACTIVEDerived fromSTVSTST, if novalue exists, useINPROGRESSDuplicateRecordLEARNERSAAQUIK,SGASTDN,SFAREGSCurriculum or fieldof study duplicatedValues clearedon new record,make RolledIndicatorNULLValues clearedon new record,make RolledIndicatorNULLLearnerrecordconvertedLEARNERSOILCUR,SAAQUIK,SAADCRV,SAADCBT,SGASTDN,SAKL010,SORLCCVSGBSTDN rowsconverted toSORLCUR andSORLFOSACTIVEDerived fromSTVSTST, if novalue exists, useINPROGRESSCreateRecordOutcome SHADEGR New curriculum orfield of study addedSOQOLIB,NEW_SORLCUR_INST callsp_default_statusACTIVEDerived fromSTVDEGS, if novalue exists, useSOUGHT (ifdegree status isNULL), usePENDING ifstatus is PN, useAWARDED ifstatus is AWDuplicateRecordOutcome SHADEGR Curriculum or fieldof study duplicatedValues clearedon new recordValues clearedon new recordStudent Release 7.0 January 200552 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalDetails of Concurrent Curricula FoundationActivity Module Object Description Status Source Activity Status CurriculumStatusDegreestatusupdatedOUTCOMESHADEGR,SHRDEGSDegree statusupdated to nextvalue, field of studycopied for thedegree, andcurriculum statusupdated to thatvalueACTIVEDerived fromSTVDEGS, if novalue exists, useSOUGHT (ifdegree status isSO), usePENDING ifstatus is PN, useAWARDED ifstatus is AWNew degreeandcurriculumcreatedfrom graderollOUTCOME SHKMODS New degree,curriculum, andfield of studyadded, copied fromLEARNER moduleACTIVEDerived fromSTVDEGS, if novalue exists, useSOUGHT (ifdegree status isSO), usePENDING ifstatus is PN, useAWARDED ifstatus is AWField ofstudy addedvia graderollOUTCOME SHKMODS New field of studyadded to existingdegree, copiedfrom LEARNERmodule field ofstudyDerived fromSTVDEGS, if novalue exists, useACTIVEDerived fromSTVDEGS, if novalue exists, useSOUGHT (ifdegree status isSO), usePENDING ifstatus is PN, useAWARDED ifstatus is AWLearneroutcomerecordcreatedOUTCOMESOILCUR,SHADEGR,SHRDEGS,SHKMODS,SORLCCVSHRDGMR rowsconverted toSORLCUR andSORLFOSDerived fromSTVDEGS, if novalue exists, useACTIVEDerived fromSTVDEGS, if novalue exists, useSOUGHT (ifdegree status isSO), usePENDING ifstatus is PN, useAWARDED ifstatus is AWBackfilling Existing Curriculum Fields (p_backload_curr)The Backfill procedure (p_backload_curr) is used to update the curriculum fieldson the existing curriculum tables (SRBRECR, SARADAP, SGBSTDN, andSHRDGMR) with the data that has been inserted into the SORLCUR and SORLFOStables.January 2005 Student Release 7.0Confidential Release Guide 53

Section 3 Concurrent Curricula Phase I - FunctionalDetails of Concurrent Curricula FoundationThe Curriculum API calls the Backfill procedure for the appropriate modules andinserts or updates the existing curriculum columns. Inserts are performed based onthe priority of the curriculum row from highest to lowest (i.e., 1 is a higher prioritythan 3).Module/FormsRecruiting (SRAQUIK, SRARECR, SAAQUIK)Admissions (SAAQUIK, SAAADMS)Learner (SAAQUIK, SGASTDN, SFAREGS)Outcome (SHADEGR)Table Curriculum FieldsSRBRECRSARADAPSGBSTDNSHRDGMRIn future releases, the Backfill procedure will be removed, and the new concurrentcurricula table structure will be enabled and reported against. All selects ofcurriculum data will be changed to use the new table structures, and all processingwill use the data in these tables.Note: For Banner 7.0, the new curriculum data structures will not impactcurrent report processing, as the data will be backfilled. All existingprocesses will find the data where it is expected to be stored.Backfill AlgorithmThe algorithm used to backfill curriculum data into existing tables is as follows:1. Beginning with the lowest priority number, select the SORLCUR row with thehighest sequence number and see if the activity status for the row is active.2. If it is active, make that row the primary curriculum. If it is not active, continueto the next lowest priority SORLCUR row and repeat.3. Repeat the same process for the SORLFOS rows associated with the selectedSORLCUR row, to fill in the Major1, Major2, Minor1, and Minor2 fields.Concentrations 1 through 3 for Major1 and Major2 are backfilled by firstselecting the SORLFOS concentration rows that have an Attached to Majorvalue of either the Major1 or Major2.Once all concentrations that are attached to either Major1 or Major2 havebeen backfilled, the remaining SORLFOS concentration rows are backfilled tothe remaining concentration fields.4. Then, using the next lowest priority number, select the SORLCUR row with thehighest sequence number and determine if it is active.5. If it is active, make that row the secondary curriculum. If it is not active,continue to the next lowest priority SORLCUR row and repeat.Student Release 7.0 January 200554 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalDetails of Concurrent Curricula Foundation6. Repeat the process for the SORLFOS rows associated with the selectedSORLCUR row, to fill in the Major1, Major2, Minor1, and Minor2 fields.Concentrations 1 through 3 for Major1 and Major2 are backfilled by firstselecting the SORLFOS concentration rows that have an Attached to Majorvalue of either the Major1 or Major2.Once all concentrations that are attached to either Major 1 or Major 2 havebeen backfilled, the remaining SORLFOS concentration rows are backfilled tothe remaining concentration fields.RecruitingCurriculum data is entered in the Curriculum window on SRARECR or in theCurriculum mini-block on SRAQUIK, or a row is created automatically through theStudent Self-Service admissions or prospects processing. The Curriculum windowuses edits to enforce existing restrictions (such as, at least one active major must becreated). When the curriculum records are saved, the Curriculum API is run toinsert and save the data. It then calls the Backfill procedure, which performs thefollowing tasks:1. The Backfill procedure selects the lowest priority row on SORLCUR having thehighest sequence number, for the learner module of RECRUIT, for the givenadministrative sequence number, and checks for an ACTIVE status. If the statusis ACTIVE, this record is made the primary curriculum on SRBRECR for thatrecruit, and the appropriate values are copied to the SRBRECR curriculumfields. If the status is INACTIVE, the next lowest priority row on SORLCUR forthe module of RECRUIT is selected and processed using the same criteria.2. The Backfill procedure then selects the lowest priority row on SORLFOShaving the highest sequence number, for the learner module of RECRUIT, forthe type of Major, and the same SORLCUR sequence number as above (justentered in Step 1), and checks for an ACTIVE status. If the status is ACTIVE, thisrecord is designated as Major1 for the primary curriculum chosen above forthat recruit, and the field values are copied to the SRBRECR curriculum fields.This process is repeated to find the next lowest priority SORLFOS row with thehighest SORLFOS sequence number that is active for the SORLCUR sequencenumber with a type of MAJOR. This is designated as Major2 for the primarycurriculum.3. The Backfill procedures selects the lowest priority rows on SORLFOS havingthe highest sequence numbers for the learner module of RECRUIT, for the typeof Minor, and the same SORLCUR sequence number as chosen above, andchecks for an ACTIVE status. If the status is ACTIVE, this record is designatedas Minor1 for the primary curriculum chosen above for that recruit.This process is repeated to find the next lowest priority SORLFOS row with thehighest SORLFOS sequence number that is active for the SORLCUR sequencenumber with a type of Minor. This is designated as Minor2 for the primarycurriculum.January 2005 Student Release 7.0Confidential Release Guide 55

Section 3 Concurrent Curricula Phase I - FunctionalDetails of Concurrent Curricula Foundation4. The Backfill procedure then repeats the algorithm described above to backfillup to six concentrations.The maximum number of SORLCUR rows that will be selected from any curriculumfor backfilling is two. (Only one is for Recruiting.)AdmissionsThis processing is the same as it is in Recruiting, but uses the SARADAP table andthe learner module of ADMISSIONS, with the added processing to also insert datafor a secondary curriculum.The maximum number of SORLCUR rows that will be selected for backfilling is two.If you want to have four majors associated with the same curriculum, and you wanttwo of those majors to display in the primary curriculum fields and two to display inthe secondary curriculum fields, then you will need to insert two SORLCUR rowsthat are identical except for their priority numbers. Then two of the majors shouldbe associated with one SORLCUR row, and the other two majors should beassociated with the second SORLCUR row.General StudentThis processing is similar to Recruiting, but uses the SGBSTDN table and the learnermodule of LEARNER.When decision codes are entered and/or SGBSTDN records are created, thefollowing processing takes place.1. A record is inserted into SGBSTDN using the data from the acceptedapplication.2. The Curriculum API is run to create entries in SORLCUR and SORLFOS for amodule of LEARNER using the curriculum data from the accepted application.3. The Backfill procedure is called to insert data into the curriculum fields onSGBSTDN.If rows are created using SAAQUIK, and a student record is created and not rolledfrom Admissions, then only rows with a learner module of LEARNER would beinserted into SORLCUR and SORLFOS. If SAAQUIK is used to create not only astudent record but also a recruiting and/or application record, then theappropriate SORLCUR and SORLFOS rows would be inserted with a learnermodule of RECRUIT and/or ADMISSIONS.Records are selected for backfilling by using the lowest priority SORLCUR row withthe highest sequence number, for the learner module of LEARNER. If the row isACTIVE and has a term code that is less than the To Term on the student recordbeing backfilled, the row is backfilled into the primary curriculum fields. Then eachof the SORLFOS rows attached to the backfilled SORLCUR row is examined in asimilar fashion. This process is repeated to determine if a secondary curriculumexists for the selected student record.Student Release 7.0 January 200556 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalDetails of Concurrent Curricula FoundationSince student records (SGASTDN) are effective term driven, a new student recordneeds to be created whenever a new SORLCUR and/or SORLFOS record is createdfor a term that does not match the effective term on any of the existing studentrecords. This is to ensure that the Backfill process works correctly and only backfillsthe appropriate curriculum rows to the appropriate student record.SFAREGS is used to update any student term or curriculum information if thestudent is registered for the term. Like SGASTDN, since it is effective term driven, anew student record must exist or be created whenever a new SORLCUR and/orSORLFOS record needs to be created for a term that does not match the effectiveterm of any existing student record. SFAREGS will automatically create a newstudent record whenever a new SORLCUR and/or SORLFOS record is created fora Key Block term that does not match the effective term on any of the existingstudent records. This is to ensure that the backfill process works correctly and onlybackfills the appropriate curriculum rows to the appropriate student record.Academic HistoryThis processing is the same as Recruiting, but uses the SHRDGMR table and thelearner module of OUTCOME.Backfilling ExamplesIf a recruit applied to History (priority 1) and Biology (priority 2) in the Bachelorof Arts undergraduate program (BA_UG), and the Web application is pushed, thefollowing takes place:• A row is inserted into SORLCUR to track the base curriculum (BA_UG) for theAdmissions module.• Two rows are inserted into SORLFOS for the field of study data, one for eachmajor (History and Biology).• The data entered into SORLCUR and SORLFOS is backfilled to theappropriate primary curriculum fields in SARADAP.Note: The values in the Module and Key Sequence fields displayed for theSORLFOS table are for demonstration purposes only. That data isactually determined by mapping an SORLFOS row to its parentSORLCUR row using the SORLCUR sequence number. Columnsholding curriculum rule numbers have been left out of the example.SORLCURLMOD Term Key Seq LCURSeqPriority Program Level Camp College Degree ActivityStatusADM * 200510 1 1 1 BA_UG UG AS BA ACTIVEJanuary 2005 Student Release 7.0Confidential Release Guide 57

Section 3 Concurrent Curricula Phase I - FunctionalDetails of Concurrent Curricula Foundation* In the LMOD column, the ADM value is an abbreviation for the learner modulecode ADMISSIONS.SORLFOSLMODLFOSTypeTermKeySeqLCURSeqPriorityLFOSSeqLFOSCodeAtt’d ConcMajr RuleActivityStatusCurriculumStatusADM * MAJR 200510 1 1 1 1 HIST ACTIVE INPROGRESSADM MAJR 200510 1 1 2 2 BIOL ACTIVE INPROGRESS* In the LMOD column, the ADM value is an abbreviation for the learner modulecode ADMISSIONS.SARADAP - Primary CurriculumTerm Appl No Term Ctlg Program Level Degree College Major 1 Major 2 Campus200510 1 200510 BA_UG UG BA AS HIST BIOLTo continue the example, if a student is accepted by the institution and wishes tohave two majors, the following takes place:• The Admissions field of study rows for History and Biology are duplicated, andthe status on the new rows is updated to INSTACCEPT.• A new SORLCUR row is created for the General Student (Learner) record totrack the student’s curriculum, and new SORLFOS (field of study) rows arecreated for History and Biology to track the student’s majors.• The Backfill procedure back fills the General Student (Learner) record(SGBSTDN) with the appropriate curriculum and field of study data.SORLCURLMOD Term Key Seq LCURSeqPriorityCurricRuleProg Level Camp College Degree ActivityStatusADM * 200510 1 1 1 240 BA_UG UG AS BA ACTIVELEARNER 200510 99 2 1 240 BA_UG UG AS BA ACTIVE* In the LMOD column, the ADM value is an abbreviation for the learner modulecode ADMISSIONS.Student Release 7.0 January 200558 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalCurriculum APISORLFOSLMODLFOSTypeLCUR Seq Priority LFOS Seq LFOSCodeLFOS RuleAtt’d ConcMajr RuleActivityStatusCurriculumStatusADM * MAJR 1 1 1 HIST 81 ACTIVE INPROGRESSADM MAJR 1 2 2 BIOL 73 ACTIVE INPROGRESSADM MAJR 1 1 3 HIST 81 ACTIVE INSTACCEPTADM MAJR 1 2 4 BIOL 73 ACTIVE INSTACCEPTLEARNER MAJR 2 1 1 HIST 81 ACTIVE INPROGRESSLEARNER MAJR 2 2 2 BIOL 73 ACTIVE INPROGRESS* In the LMOD column, the ADM value is an abbreviation for the learner modulecode ADMISSIONS.SGBSTDN - Primary CurriculumEffectiveTermTerm Ctlg Program Level Degree College Major 1 Major 2 Campus200510 200510 BA_UG UG BA AS HIST BIOLCurriculum APIA new Curriculum API has been created to insert data into the new curriculumtables (SORLCUR and SORLFOS) and to also call the Backfill procedure. TheSORLCUR and SORLFOS tables use APIs and DML procedures to do the following:• select the SORLCUR sequence number for the primary curricula for themodule record,• select the SORLCUR sequence number for the secondary curricula for themodule record,• select the major 1, major 2, minor 1, minor 2, concentration 1, concentration2, concentration 3, concentration 4, concentration 5, and concentration 6 forthe module record,• view of primary curricula from SORLCUR and SORLFOS, and• view of secondary curricula from SORLCUR and SORLFOS.January 2005 Student Release 7.0Confidential Release Guide 59

Section 3 Concurrent Curricula Phase I - FunctionalCurriculum APIRecruitingWhen a new row is inserted in SORLCUR:• The learner module code is automatically set to RECRUIT.• The key sequence number is set to the same number as the administrativesequence number of the recruiting record.• The activity status is set to Active.When a new row is inserted in SORLFOS:• If the insert is automatic (i.e., via Prospects Self-Service or tape load), theactivity status is populated with a status of ACTIVE, and the curriculum status ispopulated with a status of PENDING.• If the insert is manual, the activity status is populated with a status of ACTIVE,and the curriculum status is populated with a status of PENDING. However, youcan change these values before saving the record.When a row is to be changed in SORLCUR and/or SORLFOS:• To inactivate an existing SORLCUR record and add a new one, select theSORLCUR row to be inactivated, and select the Change Curriculum button.This will automatically duplicate and inactivate the selected row, and a new rowwill be inserted for the user to enter curriculum data.• To inactivate or change an existing SORLCUR or SORLFOS row, select the rowto be inactivated or changed. Perform an Insert Record function and then aDuplicate Record function. If an SORLCUR row is duplicated, all of itscorresponding SORLFOS rows are duplicated as well. All the fields from theselected row are duplicated, except for the activity and curriculum statuses.These two fields are made NULL. You can then modify the row with theappropriate curriculum and activity status codes.In the example below, the user wants to change the English major to an Art major.The user selects the active SORLFOS English row, performs an Insert Record andthen a Duplicate Record. The activity and curriculum status fields on the newlyduplicated row will be NULL. The user can set the activity status to INACTIVE andthe curriculum status to CHANGED to indicate that the record was inactivated dueto a major change. The user then inserts another SORLFOS row for the new majorof Art.Table Curriculum Record ResultSORLFOS 200510, ENGL, ACTIVE, PENDING Row to be changedSORLFOS200510, ENGL, INACTIVE, CHANGEMAJORRow that was duplicatedSORLFOS 200510, ART, ACTIVE, PENDING New field of study (major)Student Release 7.0 January 200560 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalCurriculum APIAdmissionsWhen a new row is inserted in SORLCUR:• The learner module code is automatically set to ADMISSIONS.• The key sequence number is set to the same number as the admissionsapplication number of the application record.• The activity status is set to Active.When a new row is inserted in SORLFOS:• If the insert is automatic (i.e., Admissions Self-Service or tape load), the activitystatus is populated with a status of ACTIVE, and the curriculum status ispopulated with a status of INPROGRESS.• If the insert is manual, the activity status is populated with a status of ACTIVE,and the curriculum status is populated with a status of INPROGRESS. However,you can change these values before saving the record.• If a matching recruiting record exists (i.e., the term, major, level, and degreeof the application match an existing recruit record), the recruit SORLFOS rowis duplicated with an activity status of ACTIVE and a curriculum status ofAPPLIED.When a row is to be changed in SORLCUR and/or SORLFOS:• To inactivate an existing SORLCUR record and add a new one, select theSORLCUR row to be inactivated, and select the Change Curriculum button.This will automatically duplicate and inactivate the selected row, and a new rowwill be inserted for the user to enter curriculum data.• To inactivate or change an existing SORLCUR or SORLFOS row, select the rowto be inactivated or changed. Perform an Insert Record function and then aDuplicate Record function. If an SORLCUR row is duplicated, all of itscorresponding SORLFOS rows are duplicated as well. All of the fields from theselected row are duplicated, except for the activity and curriculum statuses.These two fields are made NULL. You can then modify the row with theappropriate curriculum and activity status codes.Note: If a decision code has been assigned to an application and a studentrecord has been created, and the user attempts to insert an additionalcurriculum row for that application (i.e., with a learner module ofADMISSIONS), then a warning message is displayed indicating that thedata will be saved, but the corresponding student record will not beupdated.January 2005 Student Release 7.0Confidential Release Guide 61

Section 3 Concurrent Curricula Phase I - FunctionalCurriculum APIAdmissions DecisionBecause admission decision codes are user-defined, you can choose whichcurriculum status code to map to your institution’s decision codes. This allows youto automatically create a complete history of curriculum activity, showing how theapplicant has moved through each phase of the decision process.A new column (STVAPDC_CSTS) has been added to the STVAPDC table and form.This field is validated against STVCSTS and is nullable.When a decision code is entered for an application, a new row or rows will beautomatically inserted into SORLFOS for that application (with a module equal toADMISSIONS, etc.) for all SORLFOS rows that are currently active for thatapplication. These new rows will have an activity status of ACTIVE and a curriculumstatus that is derived from the new STVAPDC_CSTS field on STVAPDC for thedecision code entered. If no value is entered in this field on STVAPDC, then thefollowing values will be defaulted:• The Significant Decision and Institution Acceptance (Indicators) are checkedfor the decision code, the curriculum status is INSTACCEPT, and the activitystatus is ACTIVE.• The Significant Decision and Applicant Acceptance (Indicators) are checkedfor the decision code, the curriculum status is APPACCEPT, and the activitystatus is ACTIVE.• The Significant Decision and Institution Rejection (Indicators) are checked forthe decision code, the curriculum status is DENIED, and the activity status isACTIVE.Rows will only be automatically inserted into the SORLFOS table based on thedecision codes, when a decision code is inserted into SARAPPD for a givenapplication via SAAQUIK, SAADCRV, SAADCBT, or Quick Start Admissionsprocessing.For example, in Admissions:TableSORLCURSORLFOSSORLFOSSORLFOSCurriculum Record200510, BA_UG, ACTIVE200510, ENGL, ACTIVE, INPROGRESS200510, ENGL, ACTIVE, INSTACCEPT200510, ENGL, ACTIVE, APPACCEPTStudent Release 7.0 January 200562 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalCurriculum APIFor example, in General Student:TableSORLCURSORLFOSCurriculum Record200510, BA_UG, ACTIVE200510, ENGL, ACTIVE, INPROGRESSGeneral Student - LearnerWhen a new row is inserted in SORLCUR:• The learner module code is automatically set to LEARNER.• The key sequence number is set to 99, since learner records do not havesequence numbers.• The activity status is set to ACTIVE.When a new row is inserted in SORLFOS:• If the insert is automatic, the curriculum status is populated with the value thathas been assigned on STVSTST for the corresponding student status. If novalue has been assigned on STVSTST, then the activity status is populated witha status of ACTIVE, and the curriculum status is populated with a status ofINPROGRESS.• If the insert is manual, the curriculum status is populated with the value thathas been assigned on STVSTST for the corresponding student status. If novalue has been assigned on STVSTST, then the activity status is populated witha status of ACTIVE, and the curriculum status is populated with a status ofINPROGRESS. However, you can change these values before saving the record.When a row is to be changed in SORLCUR and/or SORLFOS:• To inactivate an existing SORLCUR record and add a new one, select theSORLCUR row to be inactivated, and select the Change Curriculum button.This will automatically duplicate and inactivate the selected row, and a new rowwill be inserted for the user to enter curriculum data.• To inactivate or change an existing SORLCUR or SORLFOS row, select the rowto be inactivated or changed. Perform an Insert Record function and then aDuplicate Record function. If an SORLCUR row is duplicated, all of itscorresponding SORLFOS rows are duplicated as well. All of the fields from theselected row are duplicated, except for the activity and curriculum statuses.These two fields are made NULL. You can then modify the row with theappropriate curriculum and activity status codes.January 2005 Student Release 7.0Confidential Release Guide 63

Section 3 Concurrent Curricula Phase I - FunctionalCurriculum APIGrade Roll to Learner OutcomeThe following processing is used to roll Learner (General Student) informationfrom SBGSTDN to the Learner Outcome (Academic History) and update recordson SHADEGR via the Grade Roll to Academic History Process (SHRROLL).1. The most current SGBSTDN record for the person is read. This is determinedby checking for the maximum learner effective term record that is less than orequal to the term on the course.2. The SORLCUR table is read, and the highest sequence number row for eachpriority is selected, beginning with the lowest priority number row first. Allrows are selected where the term code on SORLCUR is less than the To Termof the selected SGBSTDN record.3. If the SORLCUR_ROLLED_IND is set to N, processing will end. Otherwise,continue to the next step.4. If the SORLCUR_ROLLED_SEQNO is blank, the following may occur.(a)A new SHADEGR record is created if the learner SORLCUR row is activeand,No outcome SORLCUR row exists with the same college, degree, level,and program.orAn outcome SORLCUR row exists with the same college, degree, level,and program with status of AW (awarded).(b)An existing SHADEGR record is updated if:An outcome SORLCUR row exists with the same college, degree, leveland program with status that is not equal to AW (awarded).• If the learner SORLCUR row is active, use the SHRDGMR_KEY_SEQNOfield on the matched outcome row to determine which outcome rowcan be updated. (This is used if a curriculum was started, inactivated,and then re-started).• If the learner SORLCUR row is inactive, check for the last rolledlearner SORLCUR row for the same priority (i.e., theSORLCUR_ROLLED_SEQNO field will not be null). Select theSHRDGMR_LCUR_SEQNO value from the ROLLED_SEQNO field of the lastrolled learner record to determine which outcome row is to beupdated. If no rolled learner SORLCUR row exists for that priority,do not process the SORLCUR record. (You only need to roll aninactive record, if the record was previously rolled to academichistory while it was active).(c)The copy process for a new or updated SHRDGMR record is as follows.Student Release 7.0 January 200564 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalCurriculum APIThe learner SORLCUR row is copied, and the module is changed toOUTCOME.The SORLCUR_ROLLED_SEQNO field on the learner SORLCUR row isupdated to that of the SORLCUR sequence number of the newSORLCUR row for the OUTCOME module.All the active SORLFOS rows attached to the rolled learner SORLCURrow (the highest sequence number for each priority) are read and copiedto the new outcome curriculum.The SORLFOS rolled sequence number (SORLFOS_ROLLED_SEQNO) isupdated with the new outcome SORLFOS sequence number.The curriculum status on the newly created SORLFOS outcome rows isdefaulted from STVDEGS. If none exists there, the delivered defaults areused.5. If the SORLCUR_ROLLED_SEQNO is not blank (i.e., it was previously rolled), thefollowing may occur.(a)(b)(c)The SORLCUR rows’ corresponding SORLFOS rows are read to find rowswith blank rolled sequence numbers, and the highest sequence numberper priority is selected.If the selected SORLFOS row is inactive, then it is not rolled if the samefield of study type and priority were not previously rolled. (You candetermine if the row was previously rolled by selecting the last rolledlearner SORLFOS row for the same SORLCUR priority. If none exists, itwas not previously rolled.)Copy all other SORLFOS rows to the outcome SORLFOS rows for theoutcomes curriculum previously rolled, (using theSORLCUR_ROLLED_SEQNO value of the learner SORLCUR row to whichthis SORLFOR row is attached). Update the SORLFOS_ROLLED_SEQNOfield with the new outcome SORLFOS_SEQNO value. The curriculum statuson the newly created SORLFOS outcome rows is defaulted fromSTVDEGS. If none exists there, the delivered defaults are used.Example:Here is an example of how the SORLCUR_ROLLED_SEQNO andSORLFOS_ROLLED_SEQNO fields are used when grade roll processing is run.January 2005 Student Release 7.0Confidential Release Guide 65

Section 3 Concurrent Curricula Phase I - FunctionalCurriculum APIA student has an English major in the BA_UG program:TableSORLCURSORLFOSCurriculum Record200510, BA_UG, ACTIVE, ROLLED_SEQNO field is NULL200510, ENGL, ACTIVE, INPROGRESS, ROLLED_SEQNO field isNULLGrades are rolled at end of first semester.For the student:TableCurriculum RecordSORLCUR 200510, BA_UG, ACTIVE, ROLLED_SEQNO field is 1SORLFOS 200510, ENGL, ACTIVE, INPROGRESS, ROLLED_SEQNO field is 1For academic history:TableCurriculum RecordSORLCUR 200510, BA_UG, ACTIVE, LCUR_SEQ field is 1SORLFOS 200510, ENGL, ACTIVE, SOUGHT, LFOS_SEQ field is 1The student changes their major to Art:For the student:TableCurriculum RecordSORLCUR 200510, BA_UG, ACTIVE, ROLLED_SEQNO field is 1SORLFOS 200510, ENGL, ACTIVE, INPROGRESS, ROLLED_SEQNO field is 1SORLFOSSORLFOS200510, ENGL, INACTIVE, CHANGED, ROLLED_SEQNO field isNULL200510, ART, ACTIVE, INPROGRESS, ROLLED_SEQNO field is NULLThe next time SHRROLL is run, the process will take into account the newlyduplicated SORLFOS row for English (activity status is INACTIVE) with aROLLED_SEQNO field that is NULL.It will check the corresponding SORLCUR row (to find its rolled sequence numbervalue - 1), and it will use that value to insert an SORLFOS row with a learner moduleof OUTCOME and an activity status of INACTIVE, and in so doing will inactivate theexisting active ENGL row in Academic History for sequence number 1.Student Release 7.0 January 200566 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalCurriculum APIIt will then take into account the next LEARNER row in SORLFOS for ART, whichalso has a ROLLED_SEQNO field that is NULL. It will check that this SORLFOS rowalso has an associated SORLCUR row with a ROLLED_SEQNO field that is 1, and it willnow insert a new SORLFOS row with a learner module of OUTCOME for a major ofART with a status of ACTIVE.The activity status on the newly created OUTCOME rows will be set to ACTIVE orINACTIVE depending on the curriculum status of the corresponding GeneralStudent row which had the ROLLED_SEQNO field set to NULL.For Academic History:TableCurriculum RecordSORLCUR 200510, BA_UG, ACTIVE, LCUR_SEQ field is 1SORLFOS 200510, ENGL, ACTIVE, SOUGHT, LFOS_SEQ field is 1SORLFOS 200510, ENGL, INACTIVE, CHANGED, LFOS_SEQ field is 2SORLFOS 200510, ART, ACTIVE, SOUGHT, LFOS_SEQ field is 3For the student:TableCurriculum RecordSORLCUR 200510, BA_UG, ACTIVE, ROLLED_SEQNO field is 1SORLFOS 200510, ENGL, ACTIVE, SOUGHT, ROLLED_SEQNO field is 1SORLFOS 200510, ENGL, INACTIVE, CHANGED, ROLLED_SEQNO field is 2SORLFOS 200510, ART, ACTIVE, SOUGHT, ROLLED_SEQNO field is 3Academic History - Learner OutcomeWhen a new row is inserted in SORLCUR:• The learner module code is automatically set to OUTCOME.• The key sequence number is set to the same number as the degree sequencenumber of the learner outcome record.• The activity status is set to ACTIVE.January 2005 Student Release 7.0Confidential Release Guide 67

Section 3 Concurrent Curricula Phase I - FunctionalCurriculum APIWhen a new row is inserted in SORLFOS:• If the insert is automatic, the curriculum status is populated with the value thathas been assigned on STVDEGS for the corresponding degree status. If novalue has been assigned on STVDEGS, then the activity status is populated witha status of ACTIVE, and the curriculum status is populated with a status ofINPROGRESS.• If the insert is manual, the curriculum status is populated with the value thathas been assigned on STVDEGS for the corresponding degree status. If novalue has been assigned on STVDEGS, then the activity status is populated witha status of ACTIVE, and the curriculum status is populated with a status ofINPROGRESS. However, you can change these values before saving the record.When a row is to be changed in SORLCUR and/or SORLFOS:• To inactivate an existing SORLCUR record and add a new one, select theSORLCUR row to be inactivated, and click on the Change Curriculum button.This will automatically duplicate and inactivate the selected row, and a new rowwill be inserted for the user to enter curriculum data.• To inactivate or change an existing SORLCUR or SORLFOS row, select the rowto be inactivated or changed. Perform an Insert Record function and then aDuplicate Record function. If an SORLCUR row is duplicated, all of itscorresponding SORLFOS rows are duplicated as well. All of the fields from theselected row are duplicated, except for the activity and curriculum statuses.These two fields are made NULL. You can then modify the row with theappropriate curriculum and activity status codes.If a degree record already exists (i.e., one exists with a status of PENDING), and thedegree status is changed to some other status (such as SOUGHT), the form willautomatically insert new SORFLOS rows for the given degree record with theappropriate curriculum status codes from STVDEGS based on the new degree statuscode entered. If no value has been assigned on STVDEGS for the curriculum status,then the curriculum status value will default based on the Awarded Indicator settingassociated with the degree status code. If the newly added degree status has anAwarded Indicator of A (AWARDED), then the curriculum status will be set toAWARDED. If the degree status entered has an Awarded Indicator of P (PENDING),then the curriculum status will be set to PENDING. If the degree status entered hasan Awarded Indicator of NULL, then the curriculum status will be set to SOUGHT.The default activity status for these three options will be set to ACTIVE.When the Degree Status Update Report (SHRDEGS) is run, degree records areautomatically created, as well as student records. When this report creates a newdegree record (based on the parameter values), the API will use the curriculumstatus code stored on STVDEGS for the given degree status code of the degreerecord that is created. This allows you to determine which curriculum status codeshould be assigned based on the degree status code. In addition, if SHRDEGScreates a new student record, the API will use the curriculum status code assignedon STVSTST when the New Student Status parameter is selected.Student Release 7.0 January 200568 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalProcess FlowConversion of Curriculum DataCurriculum data that resides in Banner pre-7.0 base tables (i.e, SRBRECR,SARADAP, etc.) will be automatically converted to the new SORLCUR andSORLFOS tables when the person's ID is accessed from SRARECR, SRAQUIK,SAAADMS, SAAQUIK, SGASTDN, SFAREGS, or SHADEGR.When the ID is accessed from any of these forms and a Next Block is performedfrom the Key Block, the conversion program, soklcur.p_convert_curriculum,will convert all existing curriculum data in these base tables to the new SORLCURand SORLFOS tables, if no rows exist in the SORLCUR and SORLFOS tables for thespecified ID.To convert data for a single ID or a larger population, your institution can run thenew Learner Curriculum Conversion Process (SOPLCCV). The process can be runfor an individual ID or for a population selection.Note: Prior to implementing any post 7.0 releases, all Banner curriculum rowsmust be converted to use the new SORLCUR and SORLFOS tables.Process FlowOverview of Concurrent Curricula ProcessThis diagram illustrates the flow of curriculum data within the new concurrentcurricula processing for Recruiting, Admissions, General Student, Registration, andAcademic History.Curriculum data now populates two new tables, SORLCUR and SORLFOS. Thatdata is then backfilled by the Bridge API to the existing curriculum fields in theSRBRECR, SARADAP, SGBSTDN, and SHRDGMR tables.January 2005 Student Release 7.0Confidential Release Guide 69

Section 3 Concurrent Curricula Phase I - FunctionalProcess FlowData MapFormsRecruitGeneral Rec/Recr infoTermCurriculum 1Recruit Source InfoRecruit CohortRecruit CommentsSRARECRSRBRECR, SRRCHRT,SRRCMNT, SRRRSRC,SRRLCUR7.0 BridgeAdmissionsGeneral Rec/Adm infoTerm and Appl NumberCurriculum 1Curriculum 2Adm Source InfoAdm CohortAdm CommentsAdm Quest & AnswAdm ChecklistSAAADMSSARADAP, SARSRCE,SARCHRT, SARCMNT,SARLCUR, SARQUAN,SARCHKL7.0 BridgeCurriculum Base(SORLCUR)General StudentGeneral Student infoSequence NumberEffective TermCurriculum 1Curriculum 27.0 BridgeGen Stu Source InfoGen Stu CohortGen Stu CommentsCurriculum Fieldof Study(SORLFOS)SGASTDNSGRSRCE, SGRCHRT,SGRCMNT, SGRLCURRegistrationTerm, StatusCRN, Status,TermSFAREGSSFRSTCR, SFRAREGAcademic HistoryAcademic History infoDegree Sequence NumberTermCurriculum 1Curriculum 2Academic HistoryTerm, Status7.0 BridgeAcademic History CoursesTerm, CourseSHADEGRSHRDGMR, SHRTRAN,SHRLCURSOAOLIB-SOALCURSORLCUR, SORLFOSStudent Release 7.0 January 200570 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalCreating and Updating Curriculum DataCreating and Updating Curriculum DataThis section outlines the steps you need to follow to create new curriculum and fieldof study records, to change a major (or minor or concentration) within the samecurricula, or to change a major to one within a different curricula.Note: When you are inserting a new curriculum or field of study record, at leastone row with a Type of MAJOR must exist.If you are entering a field of study row for a concentration, then theOption List for the Field of Study field will display the choices AllConcentrations or Attached Concentrations. The AttachedConcentrations option will display all concentrations that are attachedeither to the base curriculum or to any of the majors entered so far.In addition, if you are entering a field of study row for a concentration,then the Attached to Major field will be enabled, and the List of Valuesfor the field will display a list of the majors to which this concentration isattached that have already been entered in the Field of Study block.Creating a Primary Curriculum with One Major and One MinorUse the following steps to create a primary curriculum record with one major andone minor:1. Use Next Block or select the Curricula tab (from the main window ofSRARECR, SAAADMS, SGASTDN, SFAREGS, or SHADEGR) to access theCurriculum window.2. Enter curriculum data in the Curriculum block fields including:(a) Set the Priority field to 2.(b)(c)Set the Program field to the code for your program.If the program entered allows multiple campuses, enter the correctcampus code in the Campus field.3. Use Next Block to access the Field of Study block.4. Enter field of study data in the Field of Study block fields including:(a) Set the Priority field to 1.(b)(c)Set the Type field to MAJOR.Use the default value in the Status field or select a different one.January 2005 Student Release 7.0Confidential Release Guide 71

Section 3 Concurrent Curricula Phase I - FunctionalCreating and Updating Curriculum Data(d) Set the Field of Study field to the appropriate major code.5. Perform a Next Record or Insert function.6. Repeat Step 4 with the Priority field set to 1 and the Type field set to MINOR.7. Save your changes.Creating a Secondary Curriculum with One Major and OneConcentrationUse the following steps to create a secondary curriculum record with one major andone concentration:1. Use Next Block or select the Curricula tab (from the main window ofSRARECR, SAAADMS, SGASTDN, SFAREGS, or SHADEGR) to access theCurriculum window.2. Enter curriculum data in the Curriculum block fields including:(a)(b)(c)Set the Priority field to a number at least one greater than the numberentered in example above for primary curriculum (for example, 3).Set the Program field to the code for your program.If the program entered allows multiple campuses, enter the correctcampus code in the Campus field.3. Use Next Block to access the Field of Study block.4. Enter field of study data in the Field of Study block fields including:(a) Set the Priority field to 1.(b)(c)Set the Type field to MAJOR.Use the default value in the Status field or select a different one.(d) Set the Field of Study field to the appropriate major code.5. Perform a Next Record or Insert function.6. Repeat Step 4 with the Priority field set to 1 and the Type field set toCONCENTRATION.7. If the concentration is attached to a major, then the Attached to Major field willbe enabled, and you can choose the major code for the major to which theconcentration is attached.8. Save your changes.Student Release 7.0 January 200572 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalCreating and Updating Curriculum DataChanging a Major to One within the Same ProgramYou can use one of the following two options when changing a major to one withinthe same program. You can choose to maintain a complete history of the curriculachanges, or you can choose to maintain a minimal history of the curricula changes.Option 1 - Maintaining a Complete History of the ChangesUse the following steps to change a major to one that is within the same programwhile keeping a complete history of the change:1. Use Next Block or select the Curricula tab (from the main window ofSRARECR, SAAADMS, SGASTDN, SFAREGS, or SHADEGR) to access theCurriculum window.2. Use Next Block from the Curriculum block to access the Field of Study block.3. Perform an Insert Record and then a Duplicate Record function from the fieldof study row with the major you wish to change.4. On the duplicated record, change the Activity status code to INACTIVE, andchange the Status field value to a status code that describes why the major isbeing changed.5. Insert a new record and fill in the Priority, Type, Status (optional), and Fieldof Study fields for the new major.6. Save your changes.Option 2 - Maintaining a Minimal History of the ChangesUse the following steps to change a major to one that is within the same programwhile keeping a minimal history of the change:1. Use Next Block or select the Curricula tab (from the main window ofSRARECR, SAAADMS, SGASTDN, SFAREGS, or SHADEGR) to access theCurriculum window.2. Use Next Block from the Curriculum block to access the Field of Study block.3. Perform an Insert Record and then a Duplicate Record function from the fieldof study row with the major you wish to change.4. On the duplicated record, enter an appropriate activity status, status code, andfield of study code for the new major. The key is that the priority numberremains the same as the priority for the major row that is no longer to be active.5. Save your changes.January 2005 Student Release 7.0Confidential Release Guide 73

Section 3 Concurrent Curricula Phase I - FunctionalCreating and Updating Curriculum DataChanging a Major to One within a Different ProgramYou can use one of the following two options when changing a major to one withina different program. You can choose to maintain a complete history of the curriculachanges, or you can choose to maintain a minimal history of the curricula changes.Option 1 - Maintaining a Complete History of the ChangesUse the following steps to change a major to one that is within a different programwhile keeping a complete history of the change:1. Use Next Block or select the Curricula tab (from the main window ofSRARECR, SAAADMS, SGASTDN, SFAREGS, or SHADEGR) to access theCurriculum window.2. Select the curriculum row to be changed.3. Select the Change Curriculum button. The following will occur automatically:(a)(b)(c)A record will be inserted and duplicated from the curriculum record thatwas selected. An insert record and duplicate record will also beperformed for each field of study row attached to the selected curriculumrow.The duplicated curriculum and field of study rows will be inactivated.A new curriculum row will be inserted to allow for the entry of the newcurriculum. Enter the information for priority, program, etc., aspreviously described.4. Use Next Block to access the Field of Study block. Enter the data (priority,type, field of study, etc.) for the new major.5. Save your changes.Option 2 - Maintaining a Minimal History of the ChangesUse the following steps to change a major to one that is within a different programwhile keeping a minimal history of the change:1. Use Next Block or select the Curricula tab (from the main window ofSRARECR, SAAADMS, SGASTDN, SFAREGS, or SHADEGR) to access theCurriculum window.2. Insert a new row for the curriculum associated with the new major in theCurriculum block. Ensure that you enter the same priority number as that onthe curriculum row that is no longer valid.3. Use Next Block to access the Field of Study block.Student Release 7.0 January 200574 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalCreating and Updating Curriculum Data4. Insert a new field of study row for the new major code. Because this new fieldof study row is tied to a different SORLCUR row, the priority does not need tobe the same as the inactivated field of study row.5. Save your changes.Changing a Campus CodeYou can use one of the following two options when changing a campus code. Youcan choose to maintain a complete history of the campus changes, or you canchoose to maintain a minimal history of the campus changes.Option 1 - Maintaining a Complete History of the Campus ChangesUse the following steps to change a campus code while keeping a complete historyof the change:1. Use Next Block or select the Curricula tab (from the main window ofSRARECR, SAAADMS, SGASTDN, SFAREGS, or SHADEGR) to access theCurriculum window.2. Select the curriculum row to be changed.3. Select the Change Curriculum button. The following will occur automatically:(a)(b)(c)A record will be inserted and duplicated from the curriculum record thatwas selected. An insert record and duplicate record will also beperformed for all field of study rows that were attached to the inactivatedcurriculum row.The duplicated curriculum and field of study rows will be inactivated.A new curriculum row will be inserted to allow for the entry of the newcurriculum. Enter the information for priority, program, new campus,etc., for the new record.4. Use Next Block to access the Field of Study block. Enter the data (priority,type, field of study, etc.) for the new field of study.5. Save your changes.Option 2 - Maintaining a Minimal History of the Campus ChangesUse the following steps to change a campus code while keeping a minimal history ofthe change:January 2005 Student Release 7.0Confidential Release Guide 75

Section 3 Concurrent Curricula Phase I - FunctionalCreating and Updating Curriculum Data1. Use Next Block or select the Curricula tab (from the main window ofSRARECR, SAAADMS, SGASTDN, SFAREGS, or SHADEGR) to access theCurriculum window.2. Select the curriculum row to be changed.3. Perform an Insert Record and then a Duplicate Record function from thecurriculum row with the campus you wish to change.4. Enter the appropriate campus code on the newly created curriculum row.5. Use Next Block to access the Field of Study block. Enter the appropriateactivity and curriculum status codes.6. Save your changes.Inactivating a Curriculum Record (Without Adding a New Record)Use the following steps to inactivate an existing curriculum record without creatinga new record:Note: This will only work if another active curriculum record already exists.1. Use Next Block or select the Curricula tab (from the main window ofSRARECR, SAAADMS, SGASTDN, SFAREGS, or SHADEGR) to access theCurriculum window.2. Select the curriculum row to be changed.3. Perform an Insert Record and then a Duplicate Record function from thecurriculum row that is to be inactivated.4. On the newly duplicated row, change the activity status to INACTIVE.5. Use Next Block to access the Field of Study block.6. On the duplicated field of study row, enter the appropriate activity status toinactivate the field of study row, along with a curriculum status code thatexplains why the row was inactivated.7. Save your changes.Student Release 7.0 January 200576 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalNew FormsNew FormsLearner Field of Study Type Validation Form (GTVLFST)This form is used to maintain field of study type codes.Fields. . . . . . . . . . . . . .CodeDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the code for the learner’s field of study type, such asMAJOR, MINOR, CONCENTRATION.DescriptionThis is the description of the field of study code.System RequiredThe System Required checkbox is used to determine whichvalues are required by the system. If the System Requiredcheckbox is checked, the validation table record cannot bedeleted.This indicator is set to Y for delivered values.User IDThis field displays the user ID of the person who created therecord.Activity DateThis field displays the date the record was created or modified.Learner Curriculum Activity Validation Form (STVCACT)This form is used to maintain curriculum activity status codes.Fields. . . . . . . . . . . . . .Activity StatusCodeDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the activity status code for the curriculum, such asACTIVE, INACTIVE, REMOVED.DescriptionThis is the description of the curriculum activity status code.User IDThis field displays the user ID of the person who created therecord.January 2005 Student Release 7.0Confidential Release Guide 77

Section 3 Concurrent Curricula Phase I - FunctionalNew FormsFields. . . . . . . . . . . . . .Activity DateDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This field displays the date the record was created or modified.Curriculum Status Validation Form (STVCSTS)This form is used to maintain curriculum status codes.Fields. . . . . . . . . . . . . .CurriculumStatus CodeDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the status code for the learner’s curriculum, such asAPPACCEPT, APPLIED, AWARDED, CHANGED, COMPLETED,DENIED, INPROGRESS, INSTACCEPT, PENDING, SOUGHT.DescriptionThis is the description of the curriculum status code.System RequiredThe System Required checkbox is used to determine whichvalues are required by the system. If the System Requiredcheckbox is checked, the validation table record cannot bedeleted.This indicator is set to Y for delivered values.User IDThis field displays the user ID of the person who created therecord.Activity DateThis field displays the date the record was created or modified.Learner Module Validation Form (STVLMOD)This form is used to maintain the codes for the Banner modules in which thecurriculum processing takes place.Fields. . . . . . . . . . . . . .Module CodeDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the code for the Banner module, such as RECRUIT,ADMISSIONS, LEARNER, OUTCOME.DescriptionThis is the description of the module code.Student Release 7.0 January 200578 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalNew FormsFields. . . . . . . . . . . . . .User IDDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This field displays the user ID of the person who created therecord.Activity DateThis field displays the date the record was created or modified.Learner Curriculum Query Form (SOILCUR)This form is used to query on all fields contained within the SORLCUR andSORLFOS tables for all learner module codes (RECRUIT, ADMISSIONS, LEARNER,OUTCOME) for a specified ID. This form is similar to the Curriculum window, butit contains all the data fields and is not dependent upon a specific module forprocessing.You can select a learner module, term, or key sequence number in the Key Block todefine the query, or you may leave these Key Block fields blank to select allcurriculum records for the ID. When you initially access the form, all curriculumrecords are displayed for the ID in the Key Block with the sort order described laterin this document.Records can be sorted by current or all, depending on the setting of the Currentfield, which indicates if the curriculum displayed is the most current for the priority(Y), is not the most recent for the priority (N), or displays all records (NULL).• Current (Y) displays the most recent row for each given priority (i.e., the highestsequence number for each priority).• Not Current (N) displays all rows for each priority that are not the most recent.• NULL displays all rows for the specified ID.Enter a Y in the Current field to display only the current curriculum rows for eachpriority.Key BlockThis block is used to define the query for the learner’s curriculum information.Fields. . . . . . . . . . . . . .IDDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Enter the ID of the learner for which you wish to see curriculuminformation.(lookup) List Person Search Form(SOAIDEN)January 2005 Student Release 7.0Confidential Release Guide 79

Section 3 Concurrent Curricula Phase I - FunctionalNew FormsFields. . . . . . . . . . . . . .SummaryDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This field allows you to search on existing records in Recruiting,Admissions, General Student, and Academic History for the ID inthe key. Select the type of summary you wish to view, and queryon the learner. You can then Exit with Value to bring that record’scurriculum data back into SOILCUR.Choices are:Recruit Summary - Prospect Summary Form (SRASUMI)Applicant Summary - Admissions Application Summary Form(SAASUMI)Learner Summary - General Student Summary Form (SGASTDQ)Learner Outcome Summary - Degree Summary Form (SHADGMQ)ModuleThis is the learner module for which you wish to see curriculuminformation.(lookup) List Learner Module Validation(STVLMOD)TermThis is the term for which you wish to see the curriculuminformation.(lookup) List Term Code Validation(STVTERM)Key SequenceThis is the sequence number for the module record, eitherrecruiting, application, or degree.Curriculum BlockThis block is used to view the curriculum details for the learner.Fields. . . . . . . . . . . . . .Record ofDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This field displays the number of curriculum records that existfor the ID based on the data entered in the Key Block, forexample Record 1 of 5. You can scroll through the records usingthe Previous Record and Next Record arrow buttons. As you scrollthrough the records, the data in the Curriculum and Field ofStudy blocks changes for each record.Student Release 7.0 January 200580 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalNew FormsFields. . . . . . . . . . . . . .CurrentDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This field specifies if the record is the most current for thepriority or not. Valid values are Y (Current), N (Not Current), orNULL (All records).Seq NumThis field specifies the SORLCUR_SEQNO associated with theselected curriculum row.Key SequenceThis is the key sequence number of the module record that isassociated with the curriculum record. This sequence numberwill be the same as either the recruiting, application, or degreesequence number. If the record is for a learner, the key sequencenumber will always be 99.TermThis is the term code for the module’s curriculum record.Catalog TermThis is the catalog term code for the module’s curriculum record.PriorityThis is the priority number that defines the curriculum rank.ProgramThis is the program for the module’s curriculum record.LevelThis is the level for the module’s curriculum record.ModuleThis is the learner module code for the curriculum and field ofstudy.CampusThis is the campus for the module’s curriculum record.CollegeThis is the college for the module’s curriculum record.DegreeThis is the degree for the module’s curriculum record.ActivityThis is the curriculum activity status code.Start DateThis is the start date of the curriculum. (This field is not used atthis time.)End DateThis is the end date of the curriculum. (This field is not used atthis time.)January 2005 Student Release 7.0Confidential Release Guide 81

Section 3 Concurrent Curricula Phase I - FunctionalNew FormsFields. . . . . . . . . . . . . .Create LearnerOutcomeDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This checkbox is checked (set to Y) if the learner curriculumshould be rolled to academic history (outcome).User IDThis field displays the user ID of the person who created therecord.Activity DateThis field displays the date the record was created or modified.Admission TypeThis is the admissions type code for the learner curriculum.Admission TermThis is the term code for admittance for the learner curriculum.MatriculatedTermThis is the term code for matriculation for the learnercurriculum.End TermThis is the term code for the end of the curriculum. (This field isnot used at this time.)Field of Study BlockThis block is used to view the field of study details for the learner.Fields. . . . . . . . . . . . . .CurrentDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This field specifies if the record is the most current for thepriority or not. Valid values are Y (Current), N (Not Current), orNULL (All records).Seq NumThis field specifies the SORLFOS_SEQNO associated with theselected curriculum row.PriorityThis is the priority number that defines the field of study rank.ActivityThis is the curriculum activity status for the field of study.Start DateThis is the start date for the field of study. (This field is not usedat this time.)TermThis is the term code for the field of study.Student Release 7.0 January 200582 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalNew FormsFields. . . . . . . . . . . . . .TypeDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is type code for the learner field of study.StatusThis is the curriculum status for the field of study.End DateThis is the end date for the field of study. (This field is not usedat this time.)Field of StudyThis is the major, minor, or concentration code for the field ofstudy.Attached toMajorThis is the major code associated with an attached concentrationfor a field of study row.DepartmentThis is the department code for the field of study.Full or Part TimeThis is the time status code for the field of study.Catalog TermThis is the catalog term for the field of study.End TermThis is the term code for the end term of the field of study. (Thisfield is not used at this time.)User IDThis field displays the user ID of the person who created therecord.Activity DateThis field displays the date the record was created or modified.Learner Curriculum Activity Rules Form (SORCACT)This form is used to set up rules to designate which curriculum activity status codesare active.Fields. . . . . . . . . . . . . .CurriculumActivity StatusDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the code for the curriculum activity status, such asACTIVE, INACTIVE, REMOVED.(lookup) List Curriculum Activity Status(STVCACT)January 2005 Student Release 7.0Confidential Release Guide 83

Section 3 Concurrent Curricula Phase I - FunctionalNew Curriculum Window and BlocksFields. . . . . . . . . . . . . .DescriptionDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the description of the curriculum activity status code.Active IndicatorCheck this box to indicate that the curriculum activity status codeis active. Uncheck this box to indicate that the curriculum activitystatus code is inactive.System RequiredIndicatorThe System Required Indicator checkbox is used to determinewhich values are required by the system. If the System RequiredIndicator checkbox is checked, the record cannot be deleted.User IDThis field displays the user ID of the person who created therecord.Activity DateThis field displays the date the record was created or modified.New Curriculum Window and BlocksCurriculum Window - (SRARECR, SAAADMS, SGASTDN, SFAREGS,SHADEGR)This new window is accessed from SRARECR, SAAADMS, SGASTDN, SFAREGS, andSHADEGR using the Curricula tab. (This window is also known as the Curriculablock, when it is referred to as a block within a form.) A new curriculum groupobject, S$_CURRICULUM_WINDOW, has been delivered for use with the newcurriculum window.This window lives in the SOQOLIB library and will be referenced on the Studentforms where curriculum data is entered (SAAADMS, SRARECR, SGASTDN,SHADEGR, SFAREGS). A new global value is used to indicate the module(STVLMOD code) for the curriculum (RECRUIT, ADMISSIONS, LEARNER, etc.). Itselects the rows for the module, PIDM, term code, and key sequence number. Theblock on-update, on-insert, and on-delete triggers call the API to maintain thecurriculum data.This window will only display the appropriate fields for curriculum rows for themodule from which it is being called. For example, if the window is called fromSAAADMS, then only curriculum rows where the module code is ADMISSIONSwould be returned. The fields displayed will differ, depending on the modulereferenced. Access the Learner Curriculum Query Form (SOILCUR) to see all thepossible fields that exist for the window.Student Release 7.0 January 200584 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalNew Curriculum Window and BlocksYou can perform a query to select only the most current records for each priority forthe ID in either the Curriculum or Field of Study blocks by entering Y in the Currentfield. You can enter N to see records that are not current. You can also select allrecords by leaving the Current field blank.You can insert and delete records in this window. You cannot update existingrecords, as the history of the curriculum and field of study data needs to bepreserved. If you wish to change data in a curriculum record, you must either usethe Change Curriculum button or duplicate the existing row and make the changeon the new row. For example, to deactivate a record, use Duplicate Record toduplicate the row to be inactivated. On the duplicated row, change the activitystatus, and if applicable, the curriculum status, to INACTIVE. Then use thecurriculum status to identify why the record is being deactivated. Insert the new rowthat you want to be active, and save the changes.The processing for the window ensures that all corresponding data elements permodule that were made nullable in the SRBRECR, SARADAP, SGBSTDN, andSHRDGMR tables are entered for 7.0.You can use the Options Menu on the forms with curriculum data to accessSOILCUR and view curriculum information for all modules.Field Display for Curriculum WindowThe fields displayed in the Curriculum window will vary, depending on the modulecalling the window.• Recruiting: All data fields are displayed except Create Learner Outcome,Admission Type, Admission Term, Matriculated Term, End Term, and Module.• Admissions: All data fields are displayed except Create Learner Outcome,Admission Type, Admission Term, Matriculated Term, End Term, and Module.• Learner: All data fields are displayed including Create Learner Outcome,Admission Type, Admission Term, Matriculated Term, and End Term, andModule.• Outcome: All data fields are displayed except Create Learner Outcome,Admission Type, Admission Term, Matriculated Term, and End Term, andModule.Sort Order for Curriculum WindowRecords in the Curriculum window can be sorted by current or not current,depending on the setting of the Current field, which indicates if the curriculum isthe most current for the priority (Y) or is not the most current (N).The default for the Curriculum window is to display all curriculum records for thegiven ID, term, and key sequence number.January 2005 Student Release 7.0Confidential Release Guide 85

Section 3 Concurrent Curricula Phase I - FunctionalNew Curriculum Window and Blocks• Current displays the most recent row for each given priority (i.e., the highestsequence number for each priority). This assumes you are only displaying rowsfor the given learner module and key sequence number.• Not Current displays rows for the given learner module and key sequencenumber that are not the most recent.• NULL displays all rows for the given learner module and key sequence number.The following sort order is used to determine how records will be displayed once thepopulation to be displayed has been determined. This sort order applies to all placeswhere curriculum data is displayed.For SORLCUR:• Module (On SOILCUR only; as module is a default value on all other forms,and each form only displays data for its module.)• Priority number, in ascending order (As the lowest priority number is the mostimportant, it is displayed first.)• SORLCUR sequence number, in descending order (This is so the mostrecently entered records are displayed first.)For SORLFOS:• Field of study type: major, minor, and then concentration• Priority, in ascending order• SORLFOS sequence number, in descending orderCurriculum Block in the Curriculum WindowThis block is used to enter and view the curriculum details for the recruit, applicant,learner, or learner outcome.Use the Change Curriculum button to inactivate the selected row by duplicating itand giving it an activity status of INACTIVE and then inserting a new row in whichyou can enter a new curriculum record.Fields. . . . . . . . . . . . . .Record ofDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This field displays the number of curriculum records that existfor the ID based on the data entered in the Key Block, forexample Record 1 of 5. You can scroll through the records usingthe Previous Record and Next Record arrow buttons. As you scrollthrough the records, the data in the Curriculum and Field ofStudy blocks changes for each record.Student Release 7.0 January 200586 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalNew Curriculum Window and BlocksFields. . . . . . . . . . . . . .CurrentDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This field specifies if the record is the current row for the priority.Valid values are Y (Current) or N (Not Current).Key SequenceThis is the key sequence number of the module record that isassociated with the curriculum record. This sequence numberwill be the same as either the recruiting, application, or degreesequence number, or it will be 99 for a learner sequence record.Column: SORLCUR_KEY_SEQNOTermThis is the term code for the module’s curriculum record.(lookup) List Term Code Validation(STVTERM)Column: SORLCUR_TERM_CODECatalog TermThis is the catalog term code for the module’s curriculum record.(lookup) List Term Code Validation(STVTERM)Column: SORLCUR_TERM_CODE_CTLGPriorityThis is the priority number that defines the curriculum rank.Column: SORLCUR_PRIORITY_NOProgramThis is the program for the module’s curriculum record.(lookup) List All Program Codes(SMAPRLE)(lookup) Help Base Curriculum Rules byProgram(lookup) Count Hits Change Curriculum(lookup) Edit Curriculum Rules(SOACURR)Column: SORLCUR_PROGRAMJanuary 2005 Student Release 7.0Confidential Release Guide 87

Section 3 Concurrent Curricula Phase I - FunctionalNew Curriculum Window and BlocksFields. . . . . . . . . . . . . .LevelDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the level for the module’s curriculum record.(lookup) List Level Code Validation(STVLEVL)(lookup) Help Base Curriculum Rules byLevel(lookup) Count Hits Change CurriculumColumn: SORLCUR_LEVL_CODECampusThis is the campus for the module’s curriculum record.(lookup) List Campus Validation(STVCAMP)(lookup) Help Base Curriculum Rules byCampus(lookup) Count Hits Change CurriculumColumn: SORLCUR_CAMP_CODECollegeThis is the college for the module’s curriculum record.(lookup) List College Validation(STVCOLL)(lookup) Help Base Curriculum Rules byCollege(lookup) Count Hits Change CurriculumColumn: SORLCUR_COLL_CODEDegreeThis is the degree for the module’s curriculum record.(lookup) List Degree Code Validation(STVDEGC)(lookup) Help Base Curriculum Rules byDegree(lookup) Count Hits Change CurriculumColumn: SORLCUR_DEGC_CODEActivityThis is the curriculum activity status code.(lookup) List Curriculum Activity Status(SOBCACT)Column: SORLCUR_CACT_CODEStudent Release 7.0 January 200588 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalNew Curriculum Window and BlocksFields. . . . . . . . . . . . . .Start DateDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the start date of the curriculum. (This field is not used atthis time.)Column: SORLCUR_START_DATEEnd DateThis is the end date of the curriculum. (This field is not used atthis time.)Column: SORLCUR_END_DATECreate LearnerOutcome *This checkbox is checked (set to Y) if the learner curriculumshould be rolled to history (outcome).* This field is only displayed on the SGASTDN and SFAREGSCurriculum windows.Column: SORLCUR_ROLL_INDUser IDThis field displays the user ID of the person who created therecord.Column: SORLCUR_USER_IDActivity DateThis field displays the date the record was created or modified.Column: SORLCUR_ACTIVITY_DATEAdmission Type*This is the admissions type code for the learner curriculum.* This field is only displayed on the SGASTDN and SFAREGSCurriculum windows.(lookup) List Admission Type Validation(STVADMT)Column: SORLCUR_ADMT_CODEAdmission Term*This is the term code for admittance from the learnercurriculum.* This field is only displayed on the SGASTDN and SFAREGSCurriculum windows.(lookup) List Term Code Validation(STVTERM)Column: SORLCUR_TERM_CODE_ADMITJanuary 2005 Student Release 7.0Confidential Release Guide 89

Section 3 Concurrent Curricula Phase I - FunctionalNew Curriculum Window and BlocksFields. . . . . . . . . . . . . .MatriculatedTerm *Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the term code for matriculation from the learnercurriculum.* This field is only displayed on the SGASTDN and SFAREGSCurriculum windows.(lookup) List Term Code Validation(STVTERM)Column: SORLCUR_TERM_CODE_MATRICEnd Term *This is the term code for the end of the curriculum. (This field isnot used at this time.)* This field is only displayed on the SGASTDN and SFAREGSCurriculum windows.(lookup) List Term Code Validation(STVTERM)Column: SORLCUR_TERM_CODE_ENDMore buttons in the Curriculum BlockMouse Keyboard ResultChangeCurriculumN/AInactivates selected row, inserts newrow for new curriculum recordField of Study Block in the Curriculum WindowThis block is used to enter and view the field of study details for the recruit,applicant, learner, or learner outcome.Fields. . . . . . . . . . . . . .CurrentDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This field specifies if the record is the current row for the priority.Valid values are Y (Current) or N (Not Current).PriorityThis is the priority number that defines the field of study rank.Column: SORLFOS_PRIORITY_NOStudent Release 7.0 January 200590 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalNew Curriculum Window and BlocksFields. . . . . . . . . . . . . .ActivityDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the curriculum activity status for the field of study.(lookup) List Curriculum Activity Status(SOBCACT)Column: SORLFOS_CACT_CODEStart DateThis is the start date for the field of study. (This field is not usedat this time.)Column: SORLFOS_START_DATETermThis is the term code for the field of study. This value defaultsfrom the Curriculum block.Column: SORLFOS_TERM_CODETypeThis is the type code for the learner field of study. It identifieswhether the row is for a major, minor, or concentration.(lookup) List Learner Field of Study Types(GTVLFST)Column: SORLFOS_LFST_CODEStatusThis is the curriculum status for the field of study.(lookup) List Curriculum Status (STVCSTS)Column: SORLFOS_CSTS_CODEEnd DateThis is the end date for the field of study. (This field is not usedat this time.)Column: SORLFOS_END_DATEField of StudyThis is the major, minor, or concentration code for the field ofstudy.(lookup) List All Major, Minor, orConcentration Codes(lookup) Help Attached Majors, Minors, orConcentrationsColumn: SORLFOS_MAJR_CODEJanuary 2005 Student Release 7.0Confidential Release Guide 91

Section 3 Concurrent Curricula Phase I - FunctionalNew Curriculum Window and BlocksFields. . . . . . . . . . . . . .Attached toMajorDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the code for the attached major for the field of study. Thisfield indicates to which major a concentration is attached, ifappropriate. This field is only enabled if the field of study type isCONCENTRATION.(lookup) List All Major Codes(lookup) Help Attached Majors(lookup) Edit Curriculum Rules(SOACURR)Column: SORLFOS_MAJR_CODE_ATTACHDepartmentThis is the department code for the field of study.(lookup) List All Department Codes(lookup) Help Attached DepartmentsColumn: SORLFOS_DEPT_CODEFull or Part TimeThis is the time status code for the field of study.(lookup) List Time Status Code Validation(STVTMST)Column: SORLFOS_TMST_CODECatalog TermThis is the catalog term for the field of study.(lookup) List Term Code Validation(STVTERM)Column: SORLFOS_TERM_CODE_CTLGEnd TermThis is the term code for the end term of the field of study. (Thisfield is not used at this time.)(lookup) List Term Code Validation(STVTERM)Column: SORLFOS_TERM_CODE_ENDUser IDThis field displays the user ID of the person who created therecord.Column: SORLFOS_USER_IDActivity DateThis field displays the date the record was created or modified.Column: SORLFOS_ACTIVITY_DATEStudent Release 7.0 January 200592 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalNew Curriculum Window and BlocksCurriculum Summary and Field of Study Summary Blocks - (SRARECR,SAAADMS, SGASTDN, SHADEGR)Curriculum Summary and Field of Study Summary blocks have been added to themain windows of SRARECR, SAAADMS, SGASTDN, and SHADEGR. These blocksare query only for the ID in the Key Block. You need to access the Curriculumwindow in these forms to insert or delete curriculum records.The Curriculum Summary and Field of Study Summary blocks display the mostrecent curriculum data for each priority if the curriculum row is ACTIVE. Theblocks display the critical curriculum fields so that users can quickly determine whatcurricula the learner is pursuing without having to use the Curricula tab to view theseparate Curriculum window. In order to make it easier for users to identify whichcurriculum records have been backfilled into the primary and secondarycurriculum fields, the key words Primary or Secondary are displayed next to theCurriculum Summary block title to identify these two rows.These blocks will only display the appropriate fields for curriculum rows for themodule from which it is being called. For example, if the window is called fromSAAADMS, then only curriculum rows where the module code is ADMISSIONSwould be returned. Access the Learner Curriculum Query Form (SOILCUR) to seeall the possible fields that exist for the window. You can use the Options Menu onthe forms with curriculum data to access SOILCUR and view curriculuminformation for all modules.Curriculum and Field of Study Mini-Blocks - (SRAQUIK, SAAQUIK)Curriculum and Field of Study mini-blocks have been added to SRAQUIK andSAAQUIK in place of the separate Curriculum window. This allows you to enter ordelete curriculum data quickly, without having to navigate to another tabbedwindow. These new mini-blocks contain the key fields required to create acurriculum record. These blocks are mini-versions of the Curriculum and Field ofStudy blocks found in the Curriculum window on SRARECR, SAAADMS,SGASTDN, SFAREGS, and SHADEGR. Data entered in these blocks still updates theSORLCUR and SORLFOS tables. You can use the Options Menu on the forms withcurriculum data to access SOILCUR and view curriculum information for allmodules.Note: Due to limitations in Oracle 10G, forms with curriculum data could notcontain both the Curriculum and Field of Study mini-blocks and theseparate Curriculum window at the same time.January 2005 Student Release 7.0Confidential Release Guide 93

Section 3 Concurrent Curricula Phase I - FunctionalChanged FormsChanged FormsAdmission Application Decision Code Validation Form (STVAPDC)This form has been modified for this enhancement. A new Curriculum Status fieldhas been added.Fields. . . . . . . . . . . . . .CurriculumStatusDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the curriculum status for the admissions decision code.(lookup) List Curriculum Status (STVCSTS)Degree Status Code Validation Form (STVDEGS)This form has been modified for this enhancement. A new Curriculum Status fieldhas been added.When degree status codes are created on STVDEGS, a curriculum status code ofAwarded can not be entered if the row being created has the Awarded Indicator setto a value other than A. In addition, a curriculum status code of Pending can not beentered if the Awarded Indicator does not equal P.Fields. . . . . . . . . . . . . .CurriculumStatusDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the curriculum status for the degree status code.(lookup) List Curriculum Status (STVCSTS)Student Status Code Validation Form (STVSTST)This form has been modified for this enhancement. A new Curriculum Status fieldhas been added.Fields. . . . . . . . . . . . . .CurriculumStatusDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the curriculum status for the student status code.(lookup) List Curriculum Status (STVCSTS)Student Release 7.0 January 200594 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalChanged FormsAdmissions Decision and Rating Batch Entry Form (SAADCBT)The following changes have been made to this form:• The tabbed user interface design has been applied.• The curriculum checking in the form has been changed to use the newSORLCUR and SORLFOS rows for validating curricula and fields of study forsignificant student accept decisions. The validation will take place on only themaximum number of curricula and fields of study for Learner (GeneralStudent), as determined on SOACTRL, and only that number of curriculumrows will be pushed from Admissions to Learner (General Student).• The field of study status in Admissions is also pushed, depending on the settingof the STVAPDC indicators for the decision. Either the STVAPDC_CSTS_CODEvalue in the STVAPDC table or a default value is used. The default values arefor significant decisions only and include:• I f the stvapdc_row.stvapdc_signf_ind field is set to Y, and thestvapdc_row.stvapdc_reject_ind field is set to Y, then thedefault_csts value is changed to DENIED.• I f the stvapdc_row.stvapdc_signf_ind field is set to Y, and thestvapdc_row.stvapdc_inst_acc_ind field is set to Y, then thedefault_csts value is changed to INSTACCEPT.• I f the stvapdc_row.stvapdc_signf_ind field is set to Y, and thestvapdc_row.stvapdc_stdn_acc_ind field is set to Y, then thedefault_csts value is changed to APPACCEPT.The Learner (General Student) field of study status code defaults toINPROGRESS.Admissions Decision Form (SAADCRV)The following changes have been made to this form:• The tabbed user interface design has been applied.• The curriculum checking in the form has been changed to use the newSORLCUR and SORLFOS rows for validating curricula and fields of study forsignificant student accept decisions. The validation will take place on only themaximum number of curricula and fields of study for Learner (GeneralStudent), as determined on SOACTRL, and only that number of curriculumrows will be pushed from Admissions to Learner (General Student).• The field of study status in Admissions is also pushed, depending on the settingof the STVAPDC indicators for the decision. Either the STVAPDC_CSTS_CODEvalue in the STVAPDC table or a default value is used. The default values arefor significant decisions only and include:• I f the stvapdc_row.stvapdc_signf_ind field is set to Y, and thestvapdc_row.stvapdc_reject_ind field is set to Y, then thedefault_csts value is changed to DENIED.January 2005 Student Release 7.0Confidential Release Guide 95

Section 3 Concurrent Curricula Phase I - FunctionalChanged Forms• I f the stvapdc_row.stvapdc_signf_ind field is set to Y, and thestvapdc_row.stvapdc_inst_acc_ind field is set to Y, then thedefault_csts value is changed to INSTACCEPT.• I f the stvapdc_row.stvapdc_signf_ind field is set to Y, and thestvapdc_row.stvapdc_stdn_acc_ind field is set to Y, then thedefault_csts value is changed to APPACCEPT.The Learner (General Student) field of study status code defaults toINPROGRESS.Recruit Prospect Information Form (SRARECR)This form has been modified for this enhancement.• The Primary Curriculum window and button have been removed. Curriculuminformation is now entered and displayed in the new Curriculum windowwhich is accessed by the Curricula tab.• The new Curriculum window has been added to the form.• The main window has been redesigned to include the new CurriculumSummary and Field of Study Summary blocks.• The Additional Information window has been removed. The information fromthat window is now displayed in the Recruit Data block of the main window.• The Withdrawal Institution window has been removed. The information fromthat window is now displayed in the Recruit Data block in the main window.• Database maintenance activity now calls the appropriate API for the modulebeing processed.• When the form is accessed, it sets the global LMOD_CODE equal to a value ofRECRUIT.• The form no longer updates the curriculum data. It calls the new CurriculumAPI to update curriculum fields.• The Options Menu has been updated to access the new Learner CurriculumQuery Form (SOILCUR) and the new Curriculum window.• The tabbed user interface design has been applied.• The processing for the form ensures that all corresponding data elements thatwere made nullable in the SRBRECR table are entered for 7.0.Quick Recruit Form (SRAQUIK)This form has been modified for this enhancement.• The curriculum data fields have been removed.• The main window has been redesigned to include the new Curriculum andField of Study mini-blocks.Student Release 7.0 January 200596 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalChanged Forms• The Address Bar Code window has been removed. The information from thiswindow is now displayed in the Addresses window which is accessed by theAddresses tab.• The Options Menu has been updated to access the new Learner CurriculumQuery Form (SOILCUR).• The tabbed user interface design has been applied.• The form now calls the GOAMTCH form to assist with preventing the creationof duplicate person records. GOAMTCH will be displayed if the user does nothave the Exclude User checkbox checked on GORCMUS. If Exclude User ischecked, then the Current Identification window will be used to create the newperson (as occurred in Banner prior to version 7.0).For more information on using SRAQUIK with GOAMTCH, please see theCommon Matching sections of this release guide.Admissions Application Form (SAAADMS)This form has been modified for this enhancement.• The Primary Curriculum and Secondary Curriculum windows and buttonshave been removed. Curriculum information is now entered and displayed inthe new Curriculum window which is accessed by the Curricula tab.• The new Curriculum window has been added to the form.• The main window has been redesigned to include the new CurriculumSummary and Field of Study Summary blocks.• The Checklist Summary and Checklist Details windows have been combinedinto one window accessed by the Checklist tab.• The Additional Information, Withdrawal Institution, Application FeeInformation, and Mail Submission windows have been combined into onewindow accessed by the Fees, Mail Submission, Withdrawal Data tab.• Database maintenance activity now calls the appropriate API for the modulebeing processed.• When the form is accessed, it sets the global LMOD_CODE equal to a value ofADMISSION.• The form no longer updates the curriculum data. It calls the new CurriculumAPI to update curriculum fields.• The Options Menu has been updated to access the new Learner CurriculumQuery Form (SOILCUR) and the new Curriculum window.• The tabbed user interface design has been applied.• The processing for the form ensures that all corresponding data elements thatwere made nullable in the SARADAP table are entered for 7.0.January 2005 Student Release 7.0Confidential Release Guide 97

Section 3 Concurrent Curricula Phase I - FunctionalChanged FormsQuick Entry Form (SAAQUIK)This form has been modified for this enhancement.• The Primary Curriculum window has been removed. The information fromthat window is now displayed in the Curriculum and Field of Study mini-blocksin the main window.• The main window has been redesigned to include the new Curriculum andField of Study mini-blocks.• The Application Information window has been removed. Information fromthat window is now displayed in the Applicant and Recruit Information blockin the main window.• The Delivery Point Information window has been removed. Information fromthat window is now displayed in the Addresses window which is accessed by theAddresses tab.• The Options Menu has been updated to allow access to the new LearnerCurriculum Query Form (SOILCUR).• The tabbed user interface design has been applied.• The form now calls the GOAMTCH form to assist with preventing the creationof duplicate person records. GOAMTCH will be displayed if the user does nothave the Exclude User checkbox checked on GORCMUS. If Exclude User ischecked, then the Current Identification window will be used to create the newperson (as occurred in Banner prior to version 7.0).For more information on using SAAQUIK with GOAMTCH, please see theCommon Matching sections of this release guide.General Student Form (SGASTDN)This form has been modified for this enhancement.• The Primary Curriculum and Secondary Curriculum windows and buttonshave been removed. Curriculum information is now entered and displayed inthe new Curriculum window which is accessed by the Curricula tab.• The new Curriculum window has been added to the form.• The main window has been redesigned to include the new CurriculumSummary and Field of Study Summary blocks.• The Student Information block has been renamed the General Learner block.• The Student Activity window is now called the Learner Activity window.• The Academic Status, Graduation Data, and Dual Degree windows have beencombined into one window accessed by the Academic and Graduation Status,Dual Degree tab.• The Additional Student Information window has been removed. Theinformation from that window is now displayed in the Additional Informationblock of the main window.Student Release 7.0 January 200598 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalChanged Forms• Database maintenance activity now calls the appropriate API for the modulebeing processed.• When the form is accessed, it sets the global LMOD_CODE equal to a value ofLEARNER.• The form no longer updates the curriculum data. It calls the new CurriculumAPI to update curriculum fields.• The Options Menu has been updated to access the new Learner CurriculumQuery Form (SOILCUR) and the new Curriculum window.• The tabbed user interface design has been applied.• The processing for the form ensures that all corresponding data elements thatwere made nullable in the SGBSTDN table are entered for 7.0.Student Course Registration Form (SFAREGS)This form has been modified for this enhancement.• The new Curriculum window has been added to the form.• The Options Menu has been updated to access the new Curriculum window.• Student's courses are re-evaluated, and fee assessment is run (Immediateassessment or Create collector record, as specified in the Fees field), wheneverchanges are saved on the Curriculum window.• The Student Information window has been renamed the Student Termwindow.• The curriculum fields in the Student Term window have been removed.• The tabbed user interface design has been applied.Degrees and Other Formal Awards Form (SHADEGR)This form has been modified for this enhancement.• The Primary Curriculum and Secondary Curriculum windows have beenremoved. Curriculum information is now entered and displayed in the newCurriculum window which is accessed by the Curricula tab.• The new Curriculum window has been added to the form.• The main window has been redesigned to include the new CurriculumSummary and Field of Study Summary blocks.• The Degree Information block in the main window has been renamed theLearner Outcome Information block.• Database maintenance activity now calls the appropriate API for the modulebeing processed.• When the form is accessed, it sets the global LMOD_CODE equal to a value ofOUTCOME.January 2005 Student Release 7.0Confidential Release Guide 99

Section 3 Concurrent Curricula Phase I - FunctionalChanged Forms• The form no longer updates the curriculum data. It calls the new CurriculumAPI to update curriculum fields.• The Options Menu has been updated to access the new Learner CurriculumQuery Form (SOILCUR) and the new Curriculum window.• The tabbed user interface design has been applied.• The processing for the form ensures that all corresponding data elements thatwere made nullable in the SHRDGMR table are entered for 7.0.Curriculum Rules Control Form (SOACTRL)This form has been modified for this enhancement.A new block has been added to the main window. The Number of Curricula Allowedblock displays data from the SOBLMOD table. Seed data values are delivered for thenumber of currently allowed curricula (based on pre-7.0 processing), but you canchange these values and allow for the entry of additional curricula. You can specifyby module the number of curricula, majors, minors, and concentrations that can beused. However, only the maximum value allowed for each category in pre-7.0Banner will be updated by the Backfill API.You can decide the number of curricula and fields of study you want to allow for useper module. The currently allowed curricula values are: two curricula (one forRecruiting), two majors per curricula, two minors per curricula, and sixconcentrations per curricula.Note: Although the Banner 7.0 release allows institutions to enter morecurricula than will be backfilled into the existing curriculum fields,SunGard SCT suggests that clients continue to restrict the number ofcurriculum that can be active concurrently to just a primary andsecondary curriculum.The following fields are in this block.Fields. . . . . . . . . . . . . .Learner ModuleDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the Banner module for which the number of curricula,majors, minors, and concentrations are being defined.(lookup) List Learner Module Validation(STVLMOD)CurriculaThis is the number of active curricula allowed for the module.MajorsThis is the number of active majors allowed per curricula for themodule.Student Release 7.0 January 2005100 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalChanged MenusFields. . . . . . . . . . . . . .MinorsDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .This is the number of active minors allowed per curricula for themodule.ConcentrationsThis is the number of active concentrations allowed per curriculafor the module.System RequiredThe System Required checkbox is used to determine whichvalues are required by the system. If the System Requiredcheckbox is checked, the record cannot be deleted.UserThis field displays the user ID of the person who created therecord.Activity DateThis field displays the date the record was created or modified.Changed MenusCurriculum Rules and Control Menu (*CURRIC)The Learner Curriculum Activity Rules Form (SORCACT) and the LearnerCurriculum Query Form (SOILCUR) have been added to the Curriculum Rules andControl Menu (*CURRIC).Note: *CURRIC can be accessed in Recruiting (*RECRUIT), Admissions(*ADMCONTROL), General Student (*GSTCONTROL), Registration(*REGCONTROL), Academic History (*AHISTORYA), and CAPP(*CAPP).Validation MenusThe Learner Field of Study Type Validation Form (GTVLFST) has been added tothe General Validation Forms Menu (*GTDVALD) in Banner Student and theValidation Form Sub Menu [GTVDUNT - GTVPURP] (*GENEVVAL2) in BannerGeneral.The Learner Curriculum Activity Validation Form (STVCACT) has been added tothe Validation Form Sub Menu [STVATTR - STVCAMP] (*STDVALD1D).January 2005 Student Release 7.0Confidential Release Guide 101

Section 3 Concurrent Curricula Phase I - FunctionalNew ProcessThe Curriculum Status Validation Form (STVCSTS) has been added to theValidation Form Sub Menu [STVCSTA - STVDAYS] (*STDVALD1G).The Learner Module Validation Form (STVLMOD) has been added to theValidation Form Sub Menu [STVLEAV - STVMEET] (*STDVALD2E).New ProcessLearner Curriculum Conversion Process (SOPLCCV)This process will read the input population and run the curriculum conversionprocess. You must enter a valid ID or create a population selection to run thisprocess.The following parameters are used with this process.• Student Learner Module - Optional, Enter the student learner module code forthe conversion process. Valid values come from STVLMOD.• Term - Optional, Enter the term code for which records are to be processed.Valid values from STVTERM.• Learner ID - Optional, Enter the ID or IDs for the student(s) to be processed.• Application Code - Optional, Enter the application code for the populationselection.• Selection Identifier - Optional, Enter the selection ID for the populationselection.• Creator ID - Optional, Enter the creator ID for the population selection.• User ID - Optional, Enter the user ID for the population selection.• Rerun Conversion Indicator - Required, Enter Y to delete and rebuild curriculumrecords, or enter N to leave the records as they are. The default is N.• Report Type - Optional, Enter D to produce a detailed report or S to produce asummary report. The default is S.• Run Mode - Required, Enter A to run in Audit Mode or U to run in UpdateMode. The default is A.The detailed output indicates the ID and name of each Banner person whosecurriculum data has been converted, as well as how many records within eachmodule have been converted. In addition, the report indicates how many BannerIDs have been processed in total. The summary output displays totals only.Student Release 7.0 January 2005102 Release Guide Confidential

Section 3 Concurrent Curricula Phase I - FunctionalChanged Reports and ProcessesChanged Reports and ProcessesAMCAS Data Load Process (SAPAMAL)APIs have been added to SAPAMAL to perform the following tasks.APIgb_commongb_identificationgb_biogb_telephonegb_emailsb_admissionsapplicationTaskGenerate PIDMs and IDsCreate SPRIDEN dataCreate SPBPERS dataCreate SPRTELE dataCreate GOREMAL dataUpdate the SARADAP status codeIn addition, the sakmods.p_create_application package was modified to call thefollowing APIs:• sb_admissionsapplication• sb_curriculum• sb_fieldofstudyAdmission Decision Criteria Report (SARBDSN)This report now calls the SGBSTDN p_update API.Elec App Verify/Load Process (SARETMT)APIs have been added to SARETMT to perform the following tasks.APIgb_commongb_identificationTaskGenerate PIDMs and IDsCreate SPRIDEN dataCalls to SAKMODS remain the same, but SAKMODS has been changed to call thefollowing APIs:January 2005 Student Release 7.0Confidential Release Guide 103

Section 3 Concurrent Curricula Phase I - FunctionalReport Sample• sb_admissionsapplication• sb_curriculum• sb_fieldofstudyPackages called by sakvapl.p_load_recds have been modified to call thefollowing APIs:PackageSAKL010SAKL020SAKL040SAKL045SAKL050APIssb_curriculum, sb_fieldofstudygb_identification, gb_biogb_addressgb_emailgb_telephoneDegree Status Update Report (SHRDEGS)Lock procedures have been removed for SHRDGMR and SGBSTDN. The process isnow updated by an API.Grade Roll to Academic History (SHRROLL)The process has been updated to use APIs and to create the degree record in thenew curriculum tables (SORLCUR and SORLFOS). It also calls the Backfillprocedure.Student Type Update Report (SHRTYPE)The insert and update to SGBSTDN have been replaced with APIs.Report SampleLearner Curriculum Conversion Process (SOPLCCV)Please see the following landscaped section for report parameters and sampleoutput.Student Release 7.0 January 2005104 Release Guide Confidential

Section 3 - Concurrent Curricula Phase 1Sample ReportLearner Curriculum Conversion Process (SOPLCCV)DescriptionThis process is used to read the input population and run the curriculum conversion process. You must enter a valid ID orcreate a population selection to run this process.The detailed output indicates the ID and name of each Banner person whose curriculum data has been converted, as well ashow many records within each module have been converted. In addition, the report indicates how many Banner IDs have beenprocessed in total. The summary output displays the totals.Parameters Name Required? Description ValuesStudent Learner Module No Enter the student learner module code for theconversion process.Term No Enter the term code for which records are to beprocessed.Learner Module Validation Form(STVLMOD)Term Code Validation Form(STVTERM)Learner ID No Enter the ID or IDs for the student(s) to beprocessed.Student Release 7.0 January 2005105 Release Guide Confidential

Section 3 - Concurrent Curricula Phase 1Sample ReportParameters (cont.) Name Required? Description ValuesApplication Code No Enter the code that identifies the general area forwhich the selection identifier was defined. All ornone of the population selection parameters must beentered.Application Inquiry Form (GLIAPPL)The Population Selection Extract Inquiry Form(GLIEXTR) may be used to review the people whowill be processed in the load from the selectionidentifier and application code entered.Selection Identifier No Enter the code that identifies the population withwhich you wish to work. The selection identifiermust be defined on the Population SelectionDefinition Rules Form (GLRSLCT). All or none ofthe population selection parameters must beentered.Population Selection Inquiry Form(GLISLCT)Creator ID No Enter the user ID of the person who created thepopulation rules. All or none of the populationselection parameters must be entered.User ID No Enter the user ID for the population selection. Thisis the ID of the user who selected the population ofpeople. This may or may not be the same as theCreator ID. All or none of the population selectionparameters must be entered.Student Release 7.0 January 2005106 Release Guide Confidential

Section 3 - Concurrent Curricula Phase 1Sample ReportParameters (cont.) Name Required? Description ValuesRerun ConversionIndicatorYesEnter Y to delete and rebuild curriculum records, orenter N to leave the records as they are. The defaultis N.YNDelete and rebuild recordsDo not delete and rebuild recordsReport Type No Enter D to produce a detailed report or S to producea summary report. The default is S.DSDetail reportSummary reportRun Mode Yes Enter A to run in Audit Mode or U to run in UpdateMode and update the database records. The defaultis A.AUAudit modeUpdate modeReport Sample—Learner Curriculum Conversion Process (SOPLCCV) — see the following pagesStudent Release 7.0 January 2005107 Release Guide Confidential

Section 3 - Concurrent Curricula Phase 1Sample ReportThis sample shows the Detail Report.PAGE 1SOPLCCV 7.0 BANNER University RUN DATE 16-DEC-2004ALL TERMS Learner Curriculum Conversion RUN TIME 10:40 AMStudent ID Student Name Recruit Converted Admissions Converted Learner Converted Outcome Converted058800061 Casey, Patrick 1 2058800045 Fisher, Gary 1 1 1058800048 King, Wayne 1 1 1 1058800047 Zimmerman, Gene 1 2 1 1Totals 3 3 4 5Processed: 4Student Release 7.0 January 2005108 Release Guide Confidential

Section 3 - Concurrent Curricula Phase 1Sample ReportPAGE 2SOPLCCV 7.0 BANNER University RUN DATE 16-DEC-2004ALL TERMS Learner Curriculum Conversion RUN TIME 10:40 AM* * * REPORT CONTROL INFORMATION * * *Parameters have been entered via Job Submission.Parameter Name Value_____________________________ ________________Parameter Seq No: 28979Module: ALLTerm: ALL TERMSLearner ID:Application name: STUDENTSelection name: 199510_NEW_UG_TRANSelection creator ID: SAISUSRSelection user ID: MGOODMANRerun conversion: NReport type: DRun mode: AStart date/time: 16-DEC-2004 10:40 AMEnd date/time: 16-DEC-2004 10:40 AMStudent Release 7.0 January 2005109 Release Guide Confidential

Section 3 - Concurrent Curricula Phase 1Sample ReportThis page intentionally left blankStudent Release 7.0 January 2005110 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalOverviewSection 4New Value-Based Security and PersonallyIdentifiable Information Security UsingFine-Grained Access Control - FunctionalThis enhancement is new for Release 7.0.This section provides functional detail about the Student product domains and howto use them in the New Value-Based Security and Personally IdentifiableInformation Security.OverviewThe new Value-Based Security (VBS) using Fine-Grained Access Control (FGAC)provides functionality that replaces existing Value-Based Security processing.Existing Value-Based Security, which was based on secured views, and its relatedobjects are no longer supported with Release 7.0. However, FGAC can be used tosecure a new version of VBS processing if you wish to use it in that capacity. VBS usesexisting columns to secure data, which is appropriate for sets of tables that containsecurity data and for securing small sets of data.Note: Secured views, table triggers, and form triggers have been removed fromthe following modules and replaced with seed data to define domainsand domain tables: Recruiting, Admissions, General Student, test scores,GPA, Catalog, Schedule, and RORSTAT in Banner Financial Aid.While Banner already provides role security and object level security, Fine-GrainedAccess Control is used for controlling row level security. You can restrict which rowsare displayed to a user. Security checking takes place when the rows are accessed.FGAC dynamically modifies an SQL statement in a transparent way to users byadding a condition (WHERE clause) which restricts the rows shown to the user.FGAC security can be defined on a table column in a primary table for predefineddomains in Banner Student. These domains are in the Catalog, Schedule,Recruiting, Admissions, and General Student modules. Test score and transfer GPAdomain information is also controlled within these modules. FGAC can also be usedto secure Personally Identifiable Information (PII).Please refer to the SCT Banner General 7.0 Release Guide for more information on thisenhancement.January 2005 Student Release 7.0Confidential Release Guide 111

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentUsing This Enhancement with Banner StudentBanner Student VBS DomainsA Banner FGAC domain is an area in Banner that has a common driving table. Anexample of a domain is Student Admissions, where the driver table is SARADAP. Alllesser tables in Admissions are part of the domain and will follow the restrictions thatare set based on the rules defined for the Admissions domain.Seed data is delivered to define Student VBS domains. The following domains aredelivered in Release 7.0.• SB_CATALOG_VBS• SB_SCHEDULE_VBS• SB_CURRICULUM_VBS• SB_FIELDOFSTUDY_VBS• SB_RECRUIT_VBS• SB_ADMISSIONS_VBS• SB_LEARNER_VBS• SB_TESTSCORES_VBS• SB_TESTSCORES_STUDENT_VBS• SB_TESTCODES_VBS• SB_OTHERGPA_VBS• SB_OTHERGPA_STUDENT_VBS• SB_OTHERGPACODES_VBSThe following domains are delivered with General using Student tables.• GB_ADDRESS_VBS (SPRADDR)• GB_MEDICAL_VBS (SPRMEDI)• GB_TELEPHONE_VBS (SPRTELE)The following table lists the delivered domains with descriptions and the associateddriver tables.Domain Description Driver TableSB_CATALOG_VBS Catalog SCBCRSESB_SCHEDULE_VBS Schedule SSBSECTSB_CURRICULUM_VBSRecruiting, Admissions,Learner, Outcome BaseCurriculumSORLCURStudent Release 7.0 January 2005112 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentDomain Description Driver TableSB_FIELDOFSTUDY_VBSRecruiting, Admissions,Learner, Outcome Base Fieldsof StudySORLFOSSB_RECRUIT_VBS Recruiting SRBRECRSB_ADMISSIONS_VBS Admissions SARADAPSB_LEARNER_VBS General Student SGBSTDNSB_TESTSCORES_VBS Test Scores SORTESTSB_TESTSCORES_STUDENT_VBSTest scores for learners, userhas accessSORTESTSB_TESTCODES_VBS Test Codes STVTESCSB_OTHERGPA_VBS Other GPA SORGPATSB_OTHERGPA_STUDENT_VBSOther GPAs for learners, userhas accessSORGPATSB_OTHERGPACODES_VBS Other GPA Codes STVGPATBanner Student Institutional Example Using VBSThe process used for defining VBS using FGAC is found in the SCT Banner General7.0 Release Guide. This example is an overview of the kinds of security that can beemployed when using Banner FGAC. For more examples, please refer to the sectionin this release guide titled How to Use Banner Student VBS Domains.An institution has two colleges, the College of Arts and Sciences and the College ofEducation. Each college has its own Admissions Office and Registrar’s Office.The Admissions Office can insert, update, delete, and select all recruiting andapplications in their own college. They can also admit their applicants into theircollege, but they cannot change the General Student record. In addition, they canonly query the recruiting, application, and student records in the other college.The Registrar’s Office in both colleges can update, delete, insert, and query GeneralStudent records. They can view all recruiting and application records.1. Create a business profile group for the College of Arts and Sciences for theRegistrar’s Office and another one for the Admissions Office on the FGACBusiness Profile Assignments Form (GOAFBPR).2. Create a third and fourth business profile group for the College of EducationRegistrar’s Office and another one for the Admissions Office on GOAFBPR.January 2005 Student Release 7.0Confidential Release Guide 113

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner Student3. Insert the assigned business profile code for each user on GOAFBPR.4. Create and activate the FGAC codes for the College of Arts and Sciences andfor the College of Education on the FGAC Group Rules Form (GOAFGAC).5. For each group, enter the domains (Admissions - SB_ADMISSIONS_VBS andStudent - SB_LEARNER_VBS) and the predicate SQL statement that will matchthe table’s college to the access list using GOAFGAC.6. Enter the business profile groups for each domain, and check the appropriateSelect, Insert, Update, and Delete access checkboxes found in the BusinessProfile Access to Predicate block in the Access to Predicate window onGOAFGAC.The result of setting up the restrictions using the new VBS with FGAC procedures isthat the Admissions Office in the College of Arts and Sciences will be able to insert,update, and delete only applications that have their college code in the College fieldin the Curricula Summary - Primary block on SAAADMS. They can view all otherapplications, but Oracle FGAC will prevent them from making changes to otherapplications. The College of Education Admissions Office will have similarrestrictions placed upon them. They can view applications in the College of Artsand Sciences, but Oracle FGAC will prevent them from modifying thoseapplications.Banner Student PII DomainsTwo types of domains are delivered for Banner FGAC, one for VBS and another forPII. You can implement PII and/or VBS. They are not dependent on one another.PII is executed for all system users, although certain users and program objects canbe exempt. They are system-required only on the SPRIDEN table and are used forthe selection of General Person data.PII domains are used to define a processing area, which is tied to a driver table. Toaccess a SPRIDEN row, the PIDM must have a row in one of the PII domains to whichthe user is assigned. Users will be able to access PII only for records in theirprocessing area. For example, if you work in the Admissions office, you will only beable to view PII for student applicants. Masking rules can be used on forms toprevent the display of sensitive data, such as a date or SSN.PII processing does not require the definition of a predicate. The use of thepredicate is dictated by the PII domain driver tables and the PII column. TheGOKFGAC package is used to construct the predicates for PII functions for selectinginformation.Seed data is delivered to define Student PII domains. The following domains aredelivered in Release 7.0.Student Release 7.0 January 2005114 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentDomain Code Driver Table PII Column NameSB_FACULTY_PII SIBINST SIBINST_PIDMSB_HOUSING_PII SLBRMAP SLBRMAP_PIDMSB_RECRUIT_PII SARADAP SRBRECR_PIDMSB_ADMISSIONS_PII SARADAP SARADAP_PIDMSB_GENSTUDENT_PII SGBSTDN SGBSTDN_PIDMSB_REGISTRATION_PII SFBETRM SFBETRM_PIDMSB_TRANSFER_PII SHRTTRM SHRTTRM_PIDMBanner Student Institutional Example for PIIThe process used for defining VBS using FGAC is found in the SCT Banner General7.0 Release Guide. This example is an overview of the kinds of security that can beemployed when using Banner FGAC.The goal of this example is to restrict access to ID and name information based onthe work location of the user and the functional location of data for the ID.• Staff members in the Admissions, Registration, Student Billing, and StudentDean's offices are assigned to the functional locations of Admissions,Enrollment, and General Student.• Staff members in the Payroll area are assigned to the functional locations ofApplicant, Benefits, and Beneficiary.• When the staff members in the Admissions office open a Banner form andenter an ID that does not have a record in Admissions, Enrollment, or GeneralStudent, it will appear as if the ID does not exist in the system.• When staff members in the Payroll area open a Banner form and enter an IDthat does not have a record in any of the Human Resources areas, it will againappear as if the ID does not exist for the system.Typically, the Student System administrative offices do not have access to Payrolltype forms, and the Payroll area may not have access to Student Systemadministrative forms. That alone prevents access to the data in those products. PIIgoes one step farther and prevents these offices from viewing the lists of people thatexist for the other products.January 2005 Student Release 7.0Confidential Release Guide 115

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentHow to Use Banner Student VBS DomainsThe following section provides information about Banner Student domains andhow they can be implemented.CatalogDomain Description Driver TablesSB_CATALOG_VBS Course Catalog SCBCRSE SCRSYLO, SCRSYRM, SCRSYTR,SCRTEXT, SCRSYLN, SCRFEES,SCRGMOD, SCRLEVL, SCRRARE,SCRRCAM, SCRRCLS, SCRRCMP,SCRRCOL. SCRRDEG, SCRRLVL,SCRRMAJR, SCRRPRG, SCRRTRM,SCRRTST, SCRSBGI, SCBCDTL,SCBCRSE, SCBDESC, SCBSUPPThe Catalog domain predicates should be used to control the insertion, updating,and deletion of data. The impact of having predicates to control selection of thecatalog is far reaching in Banner Student and may cause corrupt data. For example,the course title is derived from the catalog if not it is not available from the schedule.The course title appears on many pages and reports.Restriction Mode Columns Used in Restrictions Column DescriptionInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteSCBCRSE_SUBJ_CODESCBCRSE_CRSE_NUMBSCBCRSE_EFF_TERMSCBCRSE_COLL_CODESCBCRSE_DIVS_CODESCBCRSE_DEPT_CODESCBCRSE_CSTA_CODESCBCRSE_CIPC_CODESubject area of the courseCourse number associated with the subject for the courseTerm this version of the course becomes effectiveCollege which offers the courseDivision which offers the courseDepartment which offers the courseStatus code for the courseCIP code (primary subject matter) for the courseStudent Release 7.0 January 2005116 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentBusiness Cases Using SB_CATALOG_VBSRestrict by subject or department orcollege (using Insert, Update, Delete)Business Case IssuesRestrict maintenance by college, department, or subjectSCBCRSE_SUBJ_CODE IN ('1','2')ANDSCBCRSE_DEPT_CODE IN ('1','2')ANDSCBCRSE_COLL_CODE IN ('1','2')Other Business Case Examples Using SB_CATALOG_VBSN/AObjects that may beimpacted by restrictionsSCACRSESCADETLSCARRESSCAPREQSCASRESSCABASESCASYLBFaculty Self-ServicePossible ImpactsMaintenance of course catalog informationMaintenance of course catalog informationMaintenance of course catalog informationMaintenance of course catalog informationMaintenance of course catalog informationMaintenance of base catalog informationMaintenance of course catalog syllabusMaintenance of course catalog informationJanuary 2005 Student Release 7.0Confidential Release Guide 117

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentScheduleDomain Description Driver TablesSB_SCHEDULE_VBS Class Schedule SSBSECT SSBDESC, SSBFSEC, SSBOVRR,SSBSECT, SSRATTR, SSRBLCK,SSRCORQ, SSREVAL, SSREXTN,SSRFEES, SSRLINK, SSRMEET,SSRMPRT, SSRMRDF, SSRRARE,SSRRCLS, SSRRCMP, SSRRDEG,SCRRLVL, SSRRMAJ, SSRRPRG,SSRRSTS, SSRRTST, SSRSCCD, SSRSPRT,SSRSRDF, SSRSYLN, SSRSYLO,SSRSYRM, SSRSYTR, SSRTEXT,SSRXLST, SSRRESV, SSRRFND,SSRRLVL, SSRRMAJ, SSRRPRGThe Schedule domain predicates should be used to control the insertion, updating,and deletion of data. It is recommended that the selection restrictions not beapplied to the Schedule tables. This could impact viewing student course data ontranscripts and other online course reports.Note: Special processing has been added to the learner registration validationand update package SFKEDIT to turn FGAC off so that enrollmentcounts will not be compromised by VBS restrictions.Restriction Mode Columns Used in Restrictions Column DescriptionInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteSSBSECT_INSM_CODESSBSECT_TERM_CODESSBSECT_PTRM_CODESSBSECT_SUBJ_CODESSBSECT_SSTS_CODESSBSECT_SCHD_CODESSBSECT_CAMP_CODEInstructional method code assigned to the sectionTerm code for the course section informationPart-of-term in which the section is offeredSubject code for the sectionStatus of the sectionInstructional type of the section being scheduledCampus on which the section is scheduledStudent Release 7.0 January 2005118 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentRestriction Mode Columns Used in Restrictions Column DescriptionInsert, Update,DeleteInsert, Update,DeleteSSBSECT_GMOD_CODESSBSECT_SESS_CODEGrading mode for the sectionSession in which the section is scheduledBusiness Cases Using SB_SCHEDULE_VBSRestrict by subject or campus or sessionor schedule type (using Insert, Update,Delete)Business Case IssuesRestrict maintenance of the schedule to subject, campus, or grademode typesSSBSECT_SUBJ_CODE IN ('1','2')ANDSSBSECT_CAMP_CODE IN ('1','2')ANDSSBSECT_GMOD_CODE IN ('1','2')Other Business Case Examples Using SB_SCHEDULE_VBSN/AObjects that may beimpacted by restrictionsSSASECTSSADETLSSATEXTSSAPREQSSASYLBSSARULESSAACCLSSAASECSSAEVALSSAOVRRSSASECQFaculty Self-ServicePossible ImpactsMaintenance of schedule informationMaintenance of schedule informationMaintenance of schedule informationMaintenance of schedule informationMaintenance of schedule informationMaintenance of schedule informationMaintenance of schedule informationMaintenance of schedule informationMaintenance of schedule informationMaintenance of schedule informationMaintenance of schedule informationMaintenance of schedule informationJanuary 2005 Student Release 7.0Confidential Release Guide 119

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentCurriculumDomain Description Driver TablesSB_CURRICULUM_VBSRecruiting,Admissions, Learner,Outcome, BaseCurriculumSORLCURSORLCURStaring with Banner 7.0, all curriculum data is maintained in the new basecurriculum and field of study tables SORLCUR and SORLFOS. Restrictions on theinsertion and deletion of curriculum data should now be written against these newtables and not against SRBRECR, SARADAP, and SGASTDN. Also starting withBanner 7.0, curriculum data can no longer be updated. The process used to changedata includes copying the curriculum record using the key insert/key duplicate andmaking changes to the new record.If the user wishes to restrict selection against SRBRECR, SARADAP, and SGASTDNbased on the primary or secondary curriculum, they can continue to use thosetables’ curriculum columns in building selection, updating, and deletion rulesagainst those tables. The primary and secondary curriculum data are now backfilledfrom SORLCUR and SORLFOS to SARADAP, SRBRECR, and SGASTDN after allinserts have occurred.If selection restrictions are built using the SRBRECR, SARADAP, and SGASTDNcurriculum data columns, an alternative check needs to be added for the data to benull. The Curriculum API validates the existence of the host record before allowingan insert. For example, you cannot insert an application module curriculum if theapplication does not exist. The application will appear to not exist if the rule is onlyfor non-null values.Restriction Mode Columns Used in Restrictions Column DescriptionInsert, Delete SORLCUR_LMOD_CODE Learner module code for the curriculumInsert, Delete SORLCUR_TERM_CODE Term code for the curriculumInsert, Delete SORLCUR_LEVL_CODE Level code for the curriculumInsert, Delete SORLCUR_COLL_CODE College code for the curriculumInsert, Delete SORLCUR_DEGC_CODE Degree code for the curriculumInsert, Delete SORLCUR_TERM_CODE_CTLG Catalog term code for the learner curriculumInsert, Delete SORLCUR_ADMT_CODE Admit code for the learner’s admission to the curriculumInsert, Delete SORLCUR_CAMP_CODE Campus code for the curriculumInsert, Delete SORLCUR_PROGRAM Program code for the curriculumStudent Release 7.0 January 2005120 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentBusiness Cases UsingSB_CURRICULUM_VBSRestrict recruits by curriculumSORLCUR_LMOD_CODE =sb_curriculum.f_recruit ANDSORLCUR_LEVL_CODE = 'X' ANDSORLCUR_COLL_CODE = 'XX'Business Case IssuesNeed to restrict various campus offices that recruit differentpopulations for different programsOther Business Case Examples Using SB_CURRICULUM_VBSApplicants by curriculumSORLCUR_LMOD_CODE = sb_curriculum.f_admissions ANDSORLCUR_LEVL_CODE = 'X' ANDSORLCUR_COLL_CODE = 'XX'Learners by curriculumSORLCUR_LMOD_CODE = sb_curriculum.f_learner ANDSORLCUR_LEVL_CODE = 'X' ANDSORLCUR_COLL_CODE = 'XX'Outcome by curriculumSORLCUR_LMOD_CODE = sb_curriculum.f_outcome ANDSORLCUR_LEVL_CODE = 'X' ANDSORLCUR_COLL_CODE = 'XX'Objects that may beimpacted by restrictions *SRAQUIKSAAADMSSGASTDNSAAQUIKSRARECRSFAREGSSHADEGRSRIPRELSAADCRVPossible Impacts **Cannot save the recruit, application, or learner record if primary curriculum cannotbe savedCannot save the application if primary curriculum cannot be savedMaintenance of the learner's curriculumCannot create the learner record, application, or recruit record since the curriculumcannot be savedCannot save the recruit record if primary curriculum cannot be savedMaintenance of the learner's curriculumMaintenance of the learner's outcome curriculumCannot create the recruit or application for prospectCannot add a decision to applicant that will result in a learner record being createdJanuary 2005 Student Release 7.0Confidential Release Guide 121

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentObjects that may beimpacted by restrictions *SAADCBTSAAEAPSOnline Grade RollSOVLCURPossible Impacts **Cannot add a decision to applicant that will result in a learner record being createdCannot push the application for an electronic applicantCannot create the outcome record or add unrolled curriculum during the onlinegrade rollsSelection of curriculum information* Impacted objects do not include Banner batch objects. All job type objects arelisted in the Banner General FGAC GORFEOB object. Banner security turns VBSusing FGAC off when an object exists in the GORFEOB table.** This list may not include all possible impacts. This needs to be reviewed by eachinstitution based on the type of restrictive rule coded on GOAFGAC.Field of StudyDomain Description Driver TablesSB_FIELDOFSTUDY_VBSRecruiting,Admissions, Learner,Outcome, Base Fieldsof StudySORLFOSSORLFOSRestriction Mode Columns Used in Restrictions Column DescriptionInsert, Delete SORLFOS_MAJR_CODE_ATTACH Major code to which the concentration is attachedInsert, Delete SORLFOS_MAJR_CODE Major code for the field of studyInsert, Delete SORLFOS_DEPT_CODE Department code associated with the major field of studyInsert, Delete SORLFOS_TMST_CODE Time status code used to indicate the intent of thestudent’s perusal of the field of studyBusiness Cases UsingSB_FIELDOFSTUDY_VBSRestrict any learner module by majorBusiness Case IssuesNeed to restrict major changes to certain departments by departmentSORLFOS_DEPT_CODE = 'XXX' ANDSORLFOS_MAJR_CODE = 'XXX' ANDSORLFOS_LFST_CODE =sb_fieldofstudy_str.f_majorStudent Release 7.0 January 2005122 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentOther Business Case Examples Using SB_FIELDOFSTUDY_VBSRecruits by department or majorSORLFOS_DEPT_CODE = 'XXX' ANDSORLFOS_MAJR_CODE = 'XXX' ANDEXISTS (SELECT 'X' FROM SORLCUR WHERESORLCUR_PIDM = SORLFOS_PIDM AND SORLCUR_SEQNO = SORLFOS_LCUR_SEQNO ANDSORLCUR_LMOD_CODE = sb_curriculum_str.f_recruit)Applicants by department or majorSORLFOS_DEPT_CODE = 'XXX' ANDSORLFOS_MAJR_CODE = 'XXX' ANDEXISTS (SELECT 'X' FROM SORLCUR WHERE SORLCUR_PIDM = SORLFOS_PIDM ANDSORLCUR_SEQNO = SORLFOS_LCUR_SEQNO AND SORLCUR_LMOD_CODE = sb_curriculum_str.f_admissions)Learners by department or majorSORLFOS_DEPT_CODE = 'XXX' ANDSORLFOS_MAJR_CODE = 'XXX' ANDEXISTS (SELECT 'X' FROM SORLCUR WHERE SORLCUR_PIDM = SORLFOS_PIDM ANDSORLCUR_SEQNO = SORLFOS_LCUR_SEQNO AND SORLCUR_LMOD_CODE = sb_curriculum_str.f_learner)Outcome by department or majorSORLFOS_DEPT_CODE = 'XXX' ANDSORLFOS_MAJR_CODE = 'XXX' ANDEXISTS (SELECT 'X' FROM SORLCUR WHERE SORLCUR_PIDM = SORLFOS_PIDM ANDSORLCUR_SEQNO = SORLFOS_LCUR_SEQNO AND SORLCUR_LMOD_CODE = sb_curriculum_str.f_outcome)Objects that may beimpacted by restrictionsSRAQUIKSAAADMSSGASTDNSAAQUIKSRARECRSFAREGSSHADEGRSRIPRELSAADCRVPossible ImpactsCannot save recruit, application, or learner record if primary curriculum cannot besavedCannot save application if primary curriculum cannot be savedMaintenance of learner's curriculumCannot create the recruit, application, or learner record since the curriculum cannotbe savedCannot save recruit record if primary curriculum cannot be savedMaintenance of learner's curriculumMaintenance of learner's outcome curriculumCannot create the recruit or application for prospectCannot add a decision to an applicant that will result in a learner record being createdJanuary 2005 Student Release 7.0Confidential Release Guide 123

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentObjects that may beimpacted by restrictionsSAADCBTSAAEAPSOnline Grade RollSOVLFOSPossible ImpactsCannot add a decision to an applicant that will result in a learner record being createdCannot push the application for an electronic applicantCannot create the outcome record or add unrolled curriculum during the onlinegrade rollSelection of field of study informationRecruitDomain Description Driver TablesSB_RECRUIT_VBS Recruiting SRBRECR SRBRECR, SRRLEND, SRRRATT,SRRRSRC, SRRCHRTThe Recruit domain predicates built on non-curriculum items are meant to controlthe selection, insertion, updating, and deletion of the recruit data. Predicates thatinclude the primary or secondary curriculum items on SRBRECR can only be usedto control selection of the recruit data.Restriction Mode Columns Used in Restrictions Column DescriptionSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSRBRECR_TERM_CODESRBRECR_RECR_CODESRBRECR_RSTA_CODESRBRECR_ADMT_CODESRBRECR_FULL_PART_INDSRBRECR_RTYP_CODESRBRECR_RESD_CODESRBRECR_SESS_CODEEffective term where recruiting records will be viewed orcreated.Recruiter assigned to the prospect recruiting recordStatus of the prospect associated with the recruitingrecordAdmission type code for the prospect recruiting recordIndicates if prospect will be full-time or part-time studentRecruit type code for the prospect recruiting recordResidency code for the prospect recruiting recordSession code for the prospect recruiting recordStudent Release 7.0 January 2005124 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentRestriction Mode Columns Used in Restrictions Column DescriptionSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSRBRECR_SITE_CODESRBRECR_STYP_CODESRBRECR_TERM_CODESRBRECR_DEPT_CODESRBRECR_LEVL_CODESRBRECR_DEGC_CODESRBRECR_MAJR_CODESRBRECR_CAMP_CODESRBRECR_COLL_CODESRBRECR_PROGRAM_1SRBRECR_TERM_CODE_CTLG_1Site code for the prospect recruiting recordStudent type code for the prospect recruiting recordEffective term where recruiting records will be viewed orcreatedDepartment associated with the prospect recruitingrecordLevel code associated with the prospect recruiting recordDegree code associated with the prospect recruitingrecordMajor code associated with the prospect recruitingrecordCampus code associated with the prospect recruitingrecordCollege code associated with the prospect recruitingrecordCurriculum 1 program code associated with the prospectrecruiting recordCurriculum 1 catalog term code associated with theprospect recruiting recordBusiness Cases Using SB_RECRUIT_VBSRestrict by instate recruits (using Select,Insert, Update, Delete)Business Case IssuesNeed to restrict creation of the recruit based on if applicant is instateor out of stateSRBRECR_RESD_CODE = 'R'Restrict selection of recruit recordsbased on the primary curriculum(using Select, Update, Delete)Need to restrict selection, updating, and deletion of the recruit recordbased on the primary curriculum level and major(SRBRECR_LEVL_CODE = 'X' ANDSRBRECR_MAJR_CODE = 'XXXX') OR(SRBRECR_LEVL_CODE IS NULL ANDSRBRECR_MAJR_CODE IS NULL)January 2005 Student Release 7.0Confidential Release Guide 125

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentOther Business Case Examples Using SB_RECRUIT_VBSBy recruiter typeSRBRECR_RTYP_CODE = 'GR'By full-time recruitsSRBRECR_FULL_PART_TIME = 'F'By recruiterSRBRECR_RECR_CODE IN ('1','2')Objects that may beimpacted by restrictionsSRARECRSRAQUIKSRIPRELSAAQUIKSRARINFSRASRCESOASRVWSRASUMISOASBSMSOAPCSMStudent and FinancialAid product views withpolicy tables forSB_RECRUIT_VBSPossible ImpactsRecruit record maintenanceRecruit record quick entryCreate recruit record during create process for an electronic prospectCreate recruit record during quick admissions processView recruiting informationView recruiting informationView recruiting informationView recruiting informationView recruiting informationView recruiting informationView recruiting informationAdmissionsDomain Description Driver TablesSB_ADMISSIONS_VBSAdmissionsApplicationSARADAPSARADAP, SARAPPD, SARCHKL,SARCHRT, SARDSCL, SARQUAN,SARRRAT, SARRSRCStudent Release 7.0 January 2005126 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentThe Admissions domain predicates built on non-curriculum items are meant tocontrol the selection, insertion, updating, and deletion of the application data.Predicates that include the primary or secondary curriculum items should only beused to control selection, updating, or deletion of the application.In addition, the curriculum data is null until the backfill has been run, and anypredicate that checks the application curriculum should also check alternatively ifthe curriculum fields are null. This is required for the curriculum APIs to complete,because one of the checks in the curriculum insert is that the host record must exist.Restriction Mode Columns Used in Restrictions Column DescriptionSelect, Insert,Update, DeleteSARADAP_TERM_CODE_ENTRYTerm associated with the information on applicantrecordSelect, Insert,Update, DeleteSARADAP_APST_CODE Status of the applicationSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSARADAP_ADMT_CODESARADAP_STYP_CODEAdmission type of the applicantType of student the applicant will become if admittedSelect, Insert,Update, DeleteSARADAP_SITE_CODE Site to which applicant is applyingSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Update,DeleteSelect, Update,DeleteSARADAP_RESD_CODESARADAP_FULL_PART_INDSARADAP_SESS_CODESARADAP_RATE_CODESARADAP_RECR_CODESARADAP_RTYP_CODESARADAP_LEVL_CODESARADAP_CAMP_CODEResidency classification of the applicantIdentifies if applicant intention is for full or part timeenrollmentSession applicant is applying forSpecific assessment rate assigned to the studentRecruiter code for the applicantRecruit type code for the applicantLevel for which the applicant is applyingCampus to which applicant is applyingJanuary 2005 Student Release 7.0Confidential Release Guide 127

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentRestriction Mode Columns Used in Restrictions Column DescriptionSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSARADAP_COLL_CODE_1SARADAP_DEGC_CODE_1SARADAP_MAJR_CODE_1SARADAP_DEPT_CODESARADAP_PROGRAM_1SARADAP_TERM_CODE_CTLG_1Primary college to which applicant is applyingPrimary degree for which applicant is applyingPrimary major for which applicant is applyingDepartment to which applicant is applyingCurriculum 1 program code for which applicant isapplyingCurriculum 1 catalog term code for which applicant isapplyingBusiness Cases UsingSB_ADMISSIONS_VBSRestrict by instate applicants (usingSelect, Insert, Update, Delete)Business Case IssuesNeed to restrict creation of the application based on if applicant isinstate or out of stateSARADAP_RESD_CODE = ''Restrict applications by primary leveland college (using Select, Update,Delete)Need to restrict selection, updating, and deletion of the applicationbased on the primary curriculum level and college(SARADAP_LEVL_CODE = 'UG' ANDSARADAP_COLL_CODE_1 = 'AS') OR(SARADAP_LEVL_CODE IS NULL ANDSARADAP_COLL_CODE_1 IS NULL)Other Business Case Examples Using SB_ADMISSIONS_VBSBy instate applicantsSARADAP_RESD_CODE = 'R'By full-time applicantsSARADAP_FULL_PART_TIME = 'F'By admit typeSARADAP_ADMT_CODE IN ('1','2')Student Release 7.0 January 2005128 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentObjects that may beimpacted by restrictionsSAAACKLSAAQUANSAAADMSSAAQUIKSAARRATSAADCRVSAADCBTSRIPRELSOASUPLSOAGPATSOASRVWSAASUMISOASBSMSOAPCSMStudent and FinancialAid product views withpolicy tables forSB_ADMISSIONS_VBSPossible ImpactsMaintenance of checklist itemsMaintenance of application questions and answersMaintenance of applicationsCreate application function on the quick admissions processMaintenance of admissions ratingsMaintenance of decisionsMaintenance of decisions and admissions ratingsCreate application in the create recruit function for the electronic prospectsMaintenance of supplemental application informationMaintenance of other GPAs for applicantView application informationView application informationView application informationView application informationView application informationLearner (General Student)Domain Description Driver TablesSB_LEARNER_VBS General Student SGBSTDN SGBEOPS, SGBOEDU, SGBSTDN,SGRACMT, SGBUSER, SGRADVR,SGRASSI, SGRASST, SGRCHRT,SGRCMNT, SGRCOOP, SGRDSER,SGRDISA, SGRDUTY, SGRESEL,SGRSACT, SGRSATT, SGRSCMT,SGRSPRT, SGRVETNJanuary 2005 Student Release 7.0Confidential Release Guide 129

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentThe Learner domain predicates built on non-curriculum items are meant to controlthe insertion, updating, and deletion of the learner data. Predicates that include theprimary or secondary curriculum items on SGBSTDN can only be used to controlselection of the learner data.Restriction Mode Columns Used in Restrictions Column DescriptionInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteInsert, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSGBSTDN_TERM_CODE_GRADSGBSTDN_ACYR_CODESGBSTDN_SITE_CODESGBSTDN_TERM_CODE_EFFSGBSTDN_STST_CODESGBSTDN_STYP_CODESGBSTDN_FULL_PART_INDSGBSTDN_SESS_CODESGBSTDN_RESD_CODESGBSTDN_ADMT_CODESGBSTDN_DEPT_CODESGBSTDN_PROGRAM_1SGBSTDN_TERM_CODE_CTLG_1SGBSTDN_LEVL_CODESGBSTDN_TERM_CODE_ADMITTerm student intends to graduateYear student intends to graduateSite code for the student recordEffective term associated with student recordStudent status for the effective termStudent type for the effective termIndicates whether the student is full-time or part-timeSession student is attending for the effective termResidency status of the student for the effective termAdmissions type from the admissions applicationDepartment code for the effective termCurriculum 1 program code for the effective termCurriculum 1 catalog term code for the effective termLevel of the student for the effective termTerm student was first admitted to institutionStudent Release 7.0 January 2005130 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentRestriction Mode Columns Used in Restrictions Column DescriptionSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSelect, Update,DeleteSGBSTDN_CAMP_CODESGBSTDN_COLL_CODE_1SGBSTDN_DEGC_CODE_1SGBSTDN_MAJR_CODE_1Campus location associated with the student for theeffective termCollege associated with the primary curriculum for theeffective termDegree within the primary curriculum for the effectivetermPrimary major within the primary curriculum for theeffective termBusiness Cases Using SB_LEARNER_VBSRestrict by instate students (usingInsert, Update, Delete)Business Case IssuesNeed to restrict creation of the learner based on if person is instate orout of stateSGBSTDN_RESD_CODE = 'R'Restrict selection of learner recordsbased on the primary curriculum(using Select, Update, Delete)(SRBRECR_LEVL_CODE = 'X' ANDSRBRECR_MAJR_CODE = 'XXXX') OR(SGBSTDN_LEVL_CODE IS NULL ANDSGBSTDN_MAJR_CODE IS NULL)Other Business Case Examples Using SB_LEARNER_VBSBy full-time learnersSGBSTDN _FULL_PART_TIME = 'F'By student typeSGBSTDN_STYP_CODE IN ('AS','NS')Selection by primary curriculumSGBSTDN_LEVL_CODE = 'XX' ANDSGBSTDN_COLL_CODE = 'XX' OR(SGBSTDN_LEVL_CODE IS NULL ANDSGBSTGDN_COLL_CODE_1 IS NULL)Selection by admissions codeSGBSTDN_ADMT_CODE = 'XX'January 2005 Student Release 7.0Confidential Release Guide 131

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentObjects that may beimpacted by restrictionsSGASTDNSFAREGSSAADCRVSAADCBTSOASRVWSGASTDQSGACOOPSGAEOPSSGASPRTSGAADVRSGADISASGAUSDFStudent and FinancialAid product views withpolicy tables forSB_LEARNER_VBSPossible ImpactsMaintain general learner informationMaintain general learner informationAdmit application and create learnerAdmit application and create learnerView general learner informationView general learner informationMaintain general learner informationMaintain general learner informationMaintain general learner informationMaintain general learner informationMaintain general learner informationMaintain general learner informationView application informationTest ScoresDomain Description Driver TablesSB_TESTSCORES_VBS Test Scores SORTEST SORTESTRestriction Mode Columns Used in Restrictions Column DescriptionSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSORTEST_TESC_CODESORTEST_TSRC_CODESORTEST_TADM_CODETest score code associated with various tests, i.e., SAT,ACTTest source or how the test score was entered, i.e., dataload or self-reportedAdministrative type of a particular test, i.e., locally ornationally administeredStudent Release 7.0 January 2005132 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentRestriction Mode Columns Used in Restrictions Column DescriptionSelect, Insert,Update, DeleteSORTEST_ADMR_CODEAdmissions checklist item code which is cross-referencedBusiness Cases UsingSB_TESTSCORES_VBSRestrict by test code (using Insert,Update, Delete)Business Case IssuesRestrict maintenance to specific test codesSORTEST_TESC_CODE in('1','2','3')Other Business Case Examples Using SB_TESTSCORES_VBSBy admission request checklist codeSORTEST_ADMR_CODE in ('1','2','3')Objects that may beimpacted by restrictionsSOATESTSAADCRVSRIPRELSAAEAPSStudent and FinancialAid views with queriesagainst SORTESTPossible ImpactsSelection of test scoresDecision calculatorInsertion of test scores during creation or updating of recruit and application fromelectronic prospectInsertion of test scores during creation or updating of application from electronicapplicantSelection of recordsStudent Test ScoresDomain Description Driver TablesSB_TESTSCORES_STUDENT_VBSTest Scores for Learnerfor Which User hasAccessSORTESTSORTESTJanuary 2005 Student Release 7.0Confidential Release Guide 133

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentThis domain comes with a built-in function that limits access to test scores based onthe existence of recruit, applicant, or learner records. If the learner has one of thesemodule records and the user has access to one of them, then they will have access tothe associated test scores for the student. If the learner does not have one of thesemodule records, then the user has access to the test scores.Restriction Mode Columns Used in Restrictions Column DescriptionSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSORTEST_TESC_CODESORTEST_TSRC_CODESORTEST_TADM_CODESORTEST_ADMR_CODETest score code associated with various tests, i.e., SAT,ACTTest source or how the test score was entered, i.e., dataload or self-reportedAdministrative type of a particular test, i.e., locally ornationally administeredAdmissions checklist item code which is cross-referencedBusiness Cases UsingSB_TESTSCORES_STUDENT_VBSBusiness Case IssuesRestrict access to test scores (usingInsert, Update, Delete)Limit user access to test scores if thelearner has a record in their processingarea (recruiting, application, or generalstudent), and they have access to thatrecord. If the learner does not have oneof these records, the user then hasaccess to all test scores.No restrictive predicate is required forthe above.Other Business Case Examples Using SB_TESTSCORES_STUDENT_VBSBy admission request checklist codeSORTEST_ADMR_CODE in ('1','2','3')Objects that may beimpacted by restrictionsSOATESTSAADCRVPossible ImpactsSelection of test scoresDecision calculatorStudent Release 7.0 January 2005134 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentObjects that may beimpacted by restrictionsSRIPRELSAAEAPSStudent and FinancialAid views with queriesagainst SORTESTPossible ImpactsInsertion of test scores during creation or updating of recruit and application fromelectronic prospectInsertion of test scores during creation or updating of application from electronicapplicantSelection of recordsTest CodesDomain Description Driver TablesSB_TESTCODES_VBS Test Codes STVTESC STVTESCTest code predicates can be used to limit the List of Values to only the test codes theuser is restricted to for insertion. If a Select restriction is placed on the Test CodeValidation Table (STVTESC), the same restriction needs to be added using theSB_TESTSCORES_VBS or SB_TESTSCORES_STUDENT_VBS domains. If this is notdone, you may have to deal with missing descriptions and form error messagesduring the query process on SOATEST and all other forms that display test scores.Restriction Mode Columns Used in Restrictions Column DescriptionSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSTVTESC_CODESTVTESC_ADMR_CODETest code for the testAdmissions materials required with the associated testBusiness Cases UsingSB_TESTCODES_VBSRestrict by test code (using Insert,Update, Delete)Business Case IssuesRestrict to specific test codesSTVTESC_CODE in ('1','2','3')Other Business Case Examples Using SB_TESTCODES_VBSN/AJanuary 2005 Student Release 7.0Confidential Release Guide 135

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentObjects that may beimpacted by restrictionsSTVTESCSOATESTSAADCRVSRIPRELSAAEAPSSOABGIYSAADCSNStudent and FinancialAid views with queriesagainst STVTESCPossible ImpactsSelection and maintenance of test codesSelection of test scoresDecision calculatorInsertion of test scores during creation or updating of recruit and application fromelectronic prospectInsertion of test scores during creation or updating of application from electronicapplicantSelection and maintenance of test types for institutionDecision calculator rulesSelection of recordsOther GPAsDomain Description Driver TablesSB_OTHERGPA_VBS Other GPAs SORGPAT SORGPATRestriction Mode Columns Used in Restrictions Column DescriptionSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSORGPAT_GPAT_CODESORGPAT_SBGI_CODEOther GPA type codeSource from which the other GPA originatedBusiness Cases UsingSB_OTHERGPA_VBSBusiness Case IssuesRestrict by GPA type (using Insert,Update, Delete)SORGPAT_GPAT_CODE IN ('1','2')Student Release 7.0 January 2005136 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentOther Business Case Examples Using SB_OTHERGPA_VBSBy source or background institution code, limiting access based on sourceSORGPAT_GPAT_CODE IN ('1','2')Objects that may beimpacted by restrictionsSOAGPATStudent views withqueries againstSORGPATPossible ImpactsSelection and maintenance of other GPA scores for learnerSelection of recordsStudent Other GPAsDomain Description Driver TablesSB_OTHERGPA_STUDENT_VBSOther GPAs forlearners, for whichuser has accessSORGPATSORGPATThis domain comes with a built-in function that limits access to other student GPAsbased on the existence of recruiting, applicant, or learner records. If the learner hasone of these module records, and the user has access to one of them, then they willhave access to the other student GPAs.Restriction Mode Columns Used in Restrictions Column DescriptionSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSORGPAT_GPAT_CODESORGPAT_SBGI_CODEOther GPA type codeSource from which the other GPA originatedJanuary 2005 Student Release 7.0Confidential Release Guide 137

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentBusiness Cases UsingSB_OTHERGPA_STUDENT_VBSBusiness Case IssuesRestrict access to GPAs (using Insert,Update, Delete)Limit user access to GPAs if the learnerhas a record in their processing area(recruiting, application, or generalstudent), and they have access to thatrecord. If the learner does not have oneof these records, the user then hasaccess to all GPAs.No restrictive predicate is required forthe above.Other Business Case Examples Using SB_OTHERGPA_STUDENT_VBSBy source or background institution code, limiting access based on GPA typeSORGPAT_GPAT_CODE IN ('1','2')Objects that may beimpacted by restrictionsSOAGPATStudent views withqueries againstSORGPATPossible ImpactsSelection and maintenance of other GPA scores for learnerSelection of recordsOther GPA Type CodesDomain Description Driver TablesSB_OTHERGPACODES_VBS Other GPA Codes STVGPAT STVGPATGPA type code predicates can be used to limit the List Of Values to only the GPAcodes applicable to data in their area. If a Select restriction is placed on the GPAType Code Validation Table (STVGPAT), the same restriction needs to be addedusing the SB_OTHERGPA_VBS or SB_OTHERGPA_STUDENT_VBS domains. If this is notdone, you may have to deal with missing descriptions and form error messagesduring the query process on SOAGPAT and all other forms that display other GPAs.Student Release 7.0 January 2005138 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentRestriction Mode Columns Used in Restrictions Column DescriptionInsert, Update,DeleteSTVGPAT_CODEGPA code for the studentBusiness Cases UsingSB_OTHERGPACODES_VBSBusiness Case IssuesRestrict by GPA code (using Insert,Update, Delete)STVGPAT_CODE in ('1','2','3')Other Business Case Examples Using SB_OTHERGPACODES_VBSN/AObjects that may beimpacted by restrictionsSTVGPATSOAGPATPossible ImpactsSelection and maintenance of other GPA type codesSelection and maintenance of other GPA scores for learnerHow to Use Banner General VBS Domains with StudentThe following section provides information about Banner General domains that useStudent drivers and tables and how they can be implemented.AddressesDomain Description Driver TablesGB_SPRADDR_VBS Person Addresses SPRADDR SPRADDRRestriction Mode Columns Used in Restrictions Column DescriptionSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSPRADDR_ASRC_CODESPRADDR_ATYP_CODESPRADDR_STAT_CODEAddress source code associated with the personType of address associated with the personState/province associated with the person’s addressJanuary 2005 Student Release 7.0Confidential Release Guide 139

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentRestriction Mode Columns Used in Restrictions Column DescriptionSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSPRADDR_ZIPSPRADDR_NATN_CODEZIP code associated with the person’s addressNation/country associated with the person’s addressBusiness Cases Using GB_SPRADDR_VBSBusiness Case IssuesRestrict by address type (using Select,Insert, Update, Delete)SPRADDR_ATYP_CODE IN ('MA','W2')Other Business Case Examples Using GB_SPRADDR_VBSBy address maintenance by the address sourceSPRADDR_ASRC_CODE IN ('SELF','POST')By maintenance of addresses by state, ZIP, or nationSPRADDR_STAT_CODE IN ('MA','VT','NH','ME','NY','RI')Student objects that may beimpacted by restrictionsSPAIDENSAAQUIKSRAQUIKPossible ImpactsMaintenance of addressesMaintenance of addressesMaintenance of addressesOther product objects thatmay be impacted byrestrictionsAPAIDENFOAIDENFTMAGCYFTMCUSTFTMFMGRFTMVENDPossible ImpactsMaintenance of addressesMaintenance of addressesMaintenance of addressesMaintenance of addressesMaintenance of addressesMaintenance of addressesStudent Release 7.0 January 2005140 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentOther product objects thatmay be impacted byrestrictionsGOAADDRPEA1PAYPPAIDENPossible ImpactsMaintenance of addressesMaintenance of addressesMaintenance of addressesTelephonesDomain Description Driver TablesGB_SPRTELE_VBSPerson TelephoneNumbersSPRTELESPRTELERestriction Mode Columns Used in Restrictions Column DescriptionSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSPRTELE_TELE_CODESPRTELE_ATYP_CODETelephone type code for the person’s telephone numberOptional address type code associated with telephonenumberBusiness Cases Using GB_SPRTELE_VBSBusiness Case IssuesRestrict by telephone type (usingSelect, Insert, Update, Delete)SPRTELE_TELE_CODE IN('HOME','FAX')Other Business Case Examples Using GB_SPRTELE_VBSN/AObjects that may beimpacted by restrictionsSPAIDENSAAQUIKSRAQUIKSPATELEPossible ImpactsMaintenance of telephone numberMaintenance of telephone numberMaintenance of telephone numberMaintenance of telephone numberJanuary 2005 Student Release 7.0Confidential Release Guide 141

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalUsing This Enhancement with Banner StudentMedicalDomain Description Driver TablesGB_SPRMEDI_VBSPerson MedicalInformationSPRMEDISPRMEDIRestriction Mode Columns Used in Restrictions Column DescriptionSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSelect, Insert,Update, DeleteSPRMEDI_MEDI_CODESPRMEDI_MDEQ_CODESPRMEDI_DISA_CODESPRMEDI_SPSR_CODEMedical code associated with the personMedical equipment code associated with the personDisability type code associated with the personDisability service code available to the personBusiness Cases Using GB_SPRMEDI_VBSRestrict by medical code (using Select,Insert, Update, Delete)Business Case IssuesDifferent health professionals are used for different medical issuesSPRMEDI_MEDI_CODE = 'DE'Other Business Case Examples Using GB_SPRMEDI_VBSN/AObjects that may beimpacted by restrictionsSAAEAPSStudent viewsPossible ImpactsPush application with medical informationSelection of medical informationOther product objects thatmay be impacted byrestrictionsGOAMEDIPEAEACCPayroll viewsPossible ImpactsMaintenance of medical informationMaintenance of employee accommodationsSelection of medical informationStudent Release 7.0 January 2005142 Release Guide Confidential

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalChanged FormsChanged FormsOverall Error ModificationThe following forms have been modified. The Value-Based Security error has beenremoved.SAAADMSSAADCRVSAAQUIKSCABASESCACRSESCADETLSCARRESSCASRCHSCASRESSCASYLBSGASTDNSOAGPATSOATESTSOQOLIBSRAQUIKSRARECRSSAACCLSSAEVALSSAEXCLSSAOVRRSSAPREQSSARRESSSARULESSASBSHSSASECTSSASYLBSSATEXTSSAWSECSSAXLSTPerson Search Form (SOAIDEN)This form has been modified to store the selected PIDM in the temporary accesscontext variable if the user has turned on cross domain searching on the FGACPerson User Defaults Form (GOAFPUD).January 2005 Student Release 7.0Confidential Release Guide 143

Section 4 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - FunctionalObsolete FormObsolete FormValue-Based Security Person Access Query Form (SOIVPAC)This form is being desupported in Banner Student. The new FGAC PredicateInquiry Form (GOIFGAC) is used in Banner 7.0 to display the predicates by tableand user.Changed MenusStudent System Management Menu (*SMANAGER)The Value-Based Security Person Access Query Form (SOIVPAC) has been removedfrom the Student System Management Menu (*SMANAGER).Student Release 7.0 January 2005144 Release Guide Confidential

Section 5 Common Matching - FunctionalOverviewSection 5Common Matching - FunctionalThis enhancement is new for Release 7.0.OverviewThe Common Matching enhancement has been designed to prevent the creation ofmultiple PIDMs for a single person or non-person in Banner. Basic person APIs havebeen developed to provide common logic for how all PIDMs are created. These APIsinclude: identification information (SPRIDEN), biographic and demographicinformation (SPBPERS), address information (SPRADDR), telephone information(SPRTELE), email information (GOREMAL), and emergency contact information(SPREMRG). You can turn Common Matching on and off as needed, either for theinstitution or for a specific user.Common Matching uses a central, rule-based algorithm to check for possibledatabase matches before a new person or non-person record is inserted into theSPRIDEN table. The same algorithm is used for new records created by data loadedvia batch processes and data entered in online forms (such as SPAIDEN). A newmatch package is used to perform the matching algorithm.You can still perform required searches from SPAIDEN before new records areinserted into the database. If a person or non-person record already exists, you canupdate it with new information from the current source, such as a new address typeor a new email type. The existing record will not be overwritten. Alias tables inBanner General are now used to store aliases for first and middle names, as well asnon-person names. These aliases are used by the matching algorithm.New forms in Banner General are used to set up Common Matching. The newCommon Matching Entry Form (GOAMTCH) is used with SPAIDEN and otherforms in Student to enter information for a new ID and then execute the matchingprocess before a new PIDM is created in Banner. You can enable the matchingprocess at your institution using the Online Matching Process Enabled (Indicator)on the Installation Controls Form (GUAINST). If the matching process is enabledon GUAINST, all users are required to perform matching.You can exempt selected users from the matching process on the new CommonMatching User Setup Form (GORCMUS). You can also set up user online matchingsource defaults on GORCMUS. You can build multiple rules on the new CommonMatching Rules Form (GORCMRL) for matching persons or non-persons, usingfields and field lengths from a new data dictionary. Special matching procedures canalso be attached to rules allowing the algorithm to match on fields that are notcommon (i.e., high school data).January 2005 Student Release 7.0Confidential Release Guide 145

Section 5 Common Matching - FunctionalSetting Up Common MatchingCommon Matching specifically affects the SPAIDEN, SRAQUIK, SAAQUIK,SRIPREL, SAAEAPS, and SHAEDIS forms in Student. The Common MatchingEntry Form (GOAMTCH) is used with these forms as follows:• Users who are not excluded on GORCMUS will see GOAMTCH automaticallyfrom SPAIDEN, SRAQUIK, and SAAQUIK. If they are excluded, data entry willremain the same as in pre-7.0 Banner releases.• GOAMTCH can be turned off when a new person is created on SPAIDEN,SRAQUIK, and SAAQUIK. It cannot be turned off when a new person iscreated on SRIPREL, SAAEAPS, or SHAEDIS, since GOAMTCH replaces theobsolete SOQMTCH and SRQMTCH forms formerly used by those threeforms.• GOAMTCH replaces the SOQMTCH and SRQMTCH forms that werepreviously used by SRIPREL, SAAEAPS, and SHAEDIS to perform matching.SOQMTCH and SRQMTCH are now obsolete.• Data in the temporary tables behind SRIPREL, SAAEAPS, and SHAEDIS iscopied to the GOAMTCH temporary table. If changes to that data are made onGOAMTCH, the changed data will be used by the calling form (SRIPREL,SAAEAPS, or SHAEDIS) when a new record is loaded.• For SRIPREL, SAAEAPS, and SHAEDIS, GOAMTCH is used to attempt tomatch data for a person in a temporary table to data for a person alreadycreated in Banner, before the person is loaded into Banner.• The interface codes on STVINFC are now associated with Common Matchingrules using the Common Matching Source field. If the codes are not tied toCommon Matching, they will not be used in the matching process.Please refer to the SCT Banner General 7.0 Release Guide for more information on theGeneral forms used with this enhancement.Setting Up Common MatchingIn order to use Common Matching at your institution, you must enable it using theOnline Matching Process Enabled (Indicator) on the Installation Controls Form(GUAINST).Use the following steps to set up Common Matching processing.1. Create source codes.Use the Common Matching Source Codes Validation Form (GTVCMSC) tocreate the various source codes that may be used in Common Matching. Theseare similar to the interface codes that exist in Banner Student. Rules will beassigned to these source codes to be used with the matching algorithm.Student Release 7.0 January 2005146 Release Guide Confidential

Section 5 Common Matching - FunctionalSetting Up Common Matching2. Set up defaults for the source codes.Use the Common Matching Source Code Form (GORCMSC) to set up thedefaults to be used with a particular source code.Be sure that you set up your matching source code on GORCMSC prior tosetting up the rules associated with it on GORCMRL.For example, you can assign default address, telephone, and email types to thesource code which will default into GOAMTCH if the source code is used fromthere. GORCMSC is also used to identify whether the source code will be usedto perform matching against person data and/or non-person data and whetherthe source code can be used with online matching. Optionally, you candesignate other specific forms a user can navigate to in order to see moredetailed information about possible matched records by using the Detailsbutton on GOAMTCH.3. Assign default online matching source codes to a user ID.Use the Common Matching User Setup Form (GORCMUS) to assign a defaultonline matching source code to a specific Oracle user ID. In addition, you canspecify whether a specific user ID is allowed to choose from other matchingsource codes, or if they are restricted to using just the default source code. Youcan also indicate if a specific user ID is excluded from having to use onlineCommon Matching.For example, if a user is a “super-user” who never creates duplicate PIDMrecords, they may be exempted from having the GOAMTCH form appear fromSPAIDEN by checking the Exclude User (Indicator).4. Set up the matching rules associated with the source codes.The Common Matching Rules Form (GORCMRL) is used to set up the actualmatching rules associated with the source codes. Previously, SOAINFR was usedin Banner Student to define the specific matching rules for an interface code.Now, GORCMRL is used for this purpose.Use this form to create each rule, assign a priority to it, and then assign thespecific database fields for each rule which will be used by the matchingalgorithm. You can also copy previously created rules, as well as add specificprocedures for matching components that are not contained within BannerGeneral (i.e, matching on high school data for Banner Student).Note: Previously on SOAINFR, if a field was to be included in a rule but was notrequired, it had an indicator set to Y. With Common Matching, that samefield would now be specified as Exists on GORCMRL.January 2005 Student Release 7.0Confidential Release Guide 147

Section 5 Common Matching - FunctionalHow the New Matching Process WorksHow the New Matching Process WorksWhen you enter an ID on SPAIDEN and then execute the matching process, you canreceive a match status of “New”, “Match”, or “Potential Match”.New RecordsRecords are matched with a status of “New” if no records match, based on the rulesthat have been set up. When a record is identified as being new, the General PersonAPIs are used to insert the data into SPRIDEN, SPRADDR, SPRTELE, SPBPERS,and/or GOREMAL. Once the record is made new, you are returned to SPAIDEN.Matched RecordsRecords are matched with a status of “Match” if one, and only one, record in Bannermatches the incoming person based on the rules that have been set up.Data for the matched PIDM is displayed for review by the user. You can select thematched record and return to the main window of SPAIDEN, or you can select andupdate the matched person with data entered in the Data Entry block onGOAMTCH before returning to SPAIDEN.Potentially Matched RecordsRecords are matched with a status of “Potential Match” (or “Suspense”) if some, butnot all, fields match someone in Banner based on the rules that have been set up.For example, the first and last names for the record match, but the date of birth doesnot match.You can create the person as “New” or ”Match”, or you can select one of thepotentially matched records as the “Match”.Rule ExamplesHere are some ways you can build rules for matching in Banner Student.Priority Column Name Data Element Length Required/Exists1 SPRIDEN_SEARCH_LAST_NAME LAST NAME/NON-PERSON NAME 10 RequiredSPRIDEN_SEARCH_FIRST_NAME FIRST NAME 10 RequiredSPBPERS_SSN SSN/SIN/TIN 9 RequiredStudent Release 7.0 January 2005148 Release Guide Confidential

Section 5 Common Matching - FunctionalMatching AlgorithmPriority Column Name Data Element Length Required/Exists2 SPRIDEN_SEARCH_LAST_NAME LAST NAME/NON-PERSON NAME 10 RequiredSPRIDEN_SEARCH_FIRST_NAME FIRST NAME 10 RequiredSPBPERS_SSN SSN/SIN/TIN 9 ExistsSPBPERS_BIRTH_DAY DATE OF BIRTH DAY 2 ExistsSPBPERS_BIRTH_MONTH DATE OF BIRTH MONTH 2 ExistsSPBPERS_BIRTH_YEAR DATE OF BIRTH YEAR 2 ExistsSPRADDR_CITY CITY 10 ExistsSPRADDR_ZIP ZIP/POSTAL CODE 5 Exists3 SPRIDEN_SEARCH_LAST_NAME LAST NAME/NON-PERSON NAME 10 RequiredSPRIDEN_SEARCH_FIRST_NAME FIRST NAME 10 RequiredSPBPERS_BIRTH_DAY DATE OF BIRTH DAY 2 ExistsSPBPERS_BIRTH_MONTH DATE OF BIRTH MONTH 2 ExistsSPBPERS_BIRTH_YEAR DATE OF BIRTH YEAR 2 ExistsSPRADDR_CITY CITY 10 ExistsSPRADDR_ZIP ZIP/POSTAL CODE 5 ExistsMatching AlgorithmOverviewThe new matching algorithm used with Common Matching processing is composedof two matches - primary and secondary. The primary match selects a pool of Bannerrecords that may match based on first, middle, or last name, and/or SSN and ID. Ifa record is selected as part of the primary match, then it will be one of the potentialmatches. The secondary match then looks at all the records from the primary matchpool and uses the rest of the fields in the matching rule to see if only one recordmatches exactly. If only one record matches exactly, that record is a match. If morethan one record matches, then all those records that match or partially matchbecome the potential matches.January 2005 Student Release 7.0Confidential Release Guide 149

Section 5 Common Matching - FunctionalMatching AlgorithmAn exception to this process is if an incoming record has passed the primary match,but all of the other non-name elements included in the matching rule do not match,then the person is made new.For example, a rule could be set up as follows:Element Required LengthLast Name Required 10First Name Exists 8City Exists 8ZIP Exists 5Date of Birth ExistsBanner contains a SPRIDEN record for Joseph Smith in Tampa, FL, born on April11, 1982. The incoming record is also for a Joseph Smith who lives in Boston, MA,and who was born on August 11, 1981. Assuming there were no other Joseph Smithsin the Banner database, the incoming record would be marked New. It wouldnormally have been marked as Suspended, because the first and last names matched,but as the rest of the elements in the rule (City, ZIP, Date of Birth) specifically didnot match, the person was made new.How the Algorithm WorksThe Common Matching algorithm allows for the processing of multiple rules.Priority numbers must be defined for each rule indicating the sequence in which tothey are to be processed. The strictest rule should be assigned the first priority (i.e.,#1). The algorithm will process each rule in order, separately and completely.• The first step performed by the algorithm is primary matching for the rule.This step defines the population on which the rest of the processing(secondary match) will be performed. If no match occurs during the primarymatch, then the external record is considered to be new.• The second step performed by the algorithm is secondary matching processingagainst the results of the primary match. If the secondary match determines anexact match on only one record, the external source record is considered to bea match.If more than one record is matched to the criteria, the external source record isconsidered to be in suspense. The external source record will be considered to bein suspense if data matches part of the criteria of the rules but does not match allthe criteria. If the results of the rule are new or matched, the results are returned tothe calling process. No other rules are processed.When all the rules have been processed, the algorithm will interrogate the resultsand return the results to the calling process. The match status (new, matched, orsuspense) will be returned, as well as a results message providing the elements thatwere matched, not matched, or missing as a result of processing the rule.Student Release 7.0 January 2005150 Release Guide Confidential

Section 5 Common Matching - FunctionalMatching AlgorithmWhen processing online, if a record is determined to be a match using one rule butto be in suspense using one or more additional rules, the record's match status willbe set to match, but the user will still be able to view the potentially matched records.Rule IndicatorsThe Data Required field on GORCMRL is used for the matching rules can be set toExists or Required.• A value of Required indicates that the data field associated with the indicator isrequired and must be present on the external source and in Banner. If the fieldon either the external source or in Banner is null for a data element with theData Required field set to Required, then the data element is considered to benot matched. If all data elements are required, but all of the data elements inthe secondary match are null either in Banner or the external source, therecord will be suspended for review.• A value of Exists indicates that either the external source or the Banner valuecan be null. If either or both values are null, the field is considered to be amatch.Field Length ValuesWhenever a length is specified for a rule on the Common Matching Rules Form(GORCMRL), the comparison is made using the rule length of the fields. Forexample, using the last name, the comparison would be between the rule lengths ofthe last name on the external source to the rule length of the last name in Banner.If the rule length is five, then the first five characters of the external source last nameare compared to the first five characters of the Banner last name.A negative length may be entered for the ID and SSN/SIN/TFN to reverse the orderfrom last to first. For example, if -5 is entered for the length of the SSN/SIN/TIN,the last five characters of the external source will be compared to the last fivecharacters of the Banner SSN/SIN/TIN.For example, for the rule below:Last Name length = 4First Name length = 3SSN/SIN/TFN length = -4Patricia Longnecker, SSN/SIN/TFN #555116789The results would be:The first four characters of the last name would be used: LONGThe first three characters of the first name would be used: PATThe last four characters of the SSN/SIN/TFN would be used: 6789January 2005 Student Release 7.0Confidential Release Guide 151

Section 5 Common Matching - FunctionalMatching AlgorithmPrimary Matching LogicThe primary matching process uses Last Name/Non-Person name(SPRIDEN_SEARCH_LAST_NAME), which is a required data element for CommonMatching. If First Name (SPRIDEN_SEARCH_FIRST_NAME) or Middle Name(SPRIDEN_SEARCH_MI) are specified data elements in a rule, these will also be usedas part of the primary match for the name. In addition, if ID (SPRIDEN_ID) and/orSSN/SIN/TFN (SPBPERS_SSN) are specified data elements in a rule, they will beused as part of the primary match.The Common Matching process will use the Match Type (Indicator) setting that hasbeen established for the matching source on the Common Matching Source CodeRules Form (GORCMSC) to determine which records are to be selected in Banner.• When the Match Type (Indicator) is set to Person, person records will beselected. When GORCMSC_ENTITY_CDE is set to P, records will be selected fromSPRIDEN where SPRIDEN_ENTITY_IND is set to P.• When the Match Type (Indicator) is set to Non-Person, non-person records willbe selected. When GORCMSC_ENTITY_CDE is set to C, records will be selectedfrom SPRIDEN where SPRIDEN_ENTITY_IND is set to C.• When the Match Type (Indicator) is set to Both, person and non-person recordswill be selected. When GORCMSC_ENTITY_CDE is set to B, records will be selectedfrom SPRIDEN where SPRIDEN_ENTITY_IND is set to P or C.The following steps are used in the primary matching process:Either Step 1 or Step 2 below must be true for a record to pass the primary match. If the externalrecord fails the primary match, then the match status will be marked as new.1. If the SSN/SIN/TFN is defined for the matching source and rule prioritynumber, retrieve all records from Banner with a matching SSN/SIN/TFN.The SSN/SIN/TFN data element is defined as part of the rule, and theSPBPERS_SSN is equal to the external source SSN/SIN/TFN.2. If First Name and/or Middle Name are defined for the matching source andrule priority number, combine them with the Last Name criteria, and retrieveall records from Banner with a matching name.Note: When matching non-person records, the First and Middle Names shouldnot be included as part of the rule.(a)The following must be true:SPRIDEN_SEARCH_LAST_NAME must equal the last name on the externalsource for the specified length.Student Release 7.0 January 2005152 Release Guide Confidential

Section 5 Common Matching - FunctionalMatching AlgorithmNote: If the matching source is defined to match non-person records, andSPRIDEN_SEARCH_LAST_NAME is not like the non-person name from theexternal Source, the matching algorithm will check to see if a matchingrecord exists on the GORNPNM alias table.(b)One of the following must be true:First Name data element is not defined.orFirst Name data element is defined for the rule, andSPRIDEN_SEARCH_FIRST_NAME is equal to the external source first namefor the specified length.Note: If the SPRIDEN_SEARCH_FIRST_NAME is not like the first name from theexternal source, the matching algorithm will check to see if a matchingrecord exists on the GORNAME alias table (if the matching source isdefined to match person records).(c)One of the following must be true:Middle Name data element is not defined.orMiddle Name data element is defined for the rule, andSPRIDEN_SEARCH_MI is equal to the external source middle name for thespecified length.Note: If the SPRIDEN_SEARCH_MI is not like the middle name from the externalsource, the matching algorithm will check to see if a matching recordexists on the GORNAME alias table (if the matching source is defined tomatch person records).3. If ID is defined for the matching source and rule priority number, retrieve allrecords from Banner with a matching ID.The ID data element is defined as part of the rule, and SPRIDEN_ID is equal tothe external source ID.Secondary Matching LogicThe secondary matching process compares the data elements defined for thematching source and rule priority number for all records returned by the primarymatching process. The goal of the secondary match is to find an exact matchbetween the external source record and a Banner record.January 2005 Student Release 7.0Confidential Release Guide 153

Section 5 Common Matching - FunctionalMatching AlgorithmWhen comparing a data field that has the Data Required (Indicator) set to Exists, anull value may exist either in Banner or the external source. If a null value existseither in Banner or the external source for the data element, the data element isconsidered to be matched.When the Data Required (Indicator) is set to Required, if a null value exists either inBanner or the external source for the data element, the data element is consideredto be not matched.This step is repeated for each of the data elements for the rule, and one conditionmust be true for each for an external source record to be considered to be a match.• Data element is not defined.• Data element Data Required (Indicator) is set to Exists or Required, and theBanner value is equal to the external source value for the specified length.or• Data element Data Required (Indicator) is set to Exists, and the Banner value isnull.or• Data element Data Required (Indicator) is set to Exists, and the external sourcevalue is null.When the data being matched is part of a logical unit (such as an address), thelogical unit is matched separately and completely. For example, when matching oncity and ZIP code, the city and ZIP code must be associated with one address.Note: There is an exception to be aware of. For an external source record to beconsidered as new when the record has already passed the primarymatch, all non-name data elements must be determined as not being amatch, and none of the non-name elements may be null.Examples of Matching Algorithm Process and ResultsHere are some examples of how the matching algorithm works.Example 1:If all required data elements are missing, the record will be suspended.Last Name = RequiredFirst Name = RequiredDate of Birth Day = RequiredDate of Birth Month = RequiredDate of Birth Year = RequiredCity = RequiredBanner values: Mildred Jones, Date of Birth = 08/17/1957, City = TopekaStudent Release 7.0 January 2005154 Release Guide Confidential

Section 5 Common Matching - FunctionalMatching AlgorithmExternal values: Mildred JonesThe external record will pass the primary match, because the first and last namesmatch. However, since all other data elements are missing (i.e, null) from theexternal source (not matched but are null), the record will be suspended.Example 2:The external record passes the primary match as the first and last name matchesagainst two Banner records. These two records are then used in the secondarymatch.Rule 1 Rule 2Last Name = RFirst Name = YSSN = YDate of Birth = YCity = YLast Name = RFirst Name = YDate of Birth = YCity = YZIP Code = YZIP Code = YThe value R stands for Required. The value Y stands for Exists.Banner values:Record 1 - Alberta Rockville, 330229101, Largesse, 06259, 05/01/1985Record 2 - Alberta Rockville, no SSN, Pomfret, 19355, no Date of BirthExternal values: Alberta Rockville, 330229101, Largesse, 06259, no Date of BirthThe external record will pass the primary match, because the first and last namesmatch at least one Banner record with the same first and last names.• Using Rule 1 and the matching algorithm, the external record will be matchedagainst Banner record 1. It will be suspended against Banner record 2.• Using Rule 2, the external record will be suspended against Banner record 1,as well as Banner record 2. Since an exact match was found, the algorithm willreturn a match.Example 3:The external record passes the primary match, which usually means that the matchstatus will be Suspense at a minimum. However, in this case, because none of thenon-name/SSN fields match, the external record has a match status of New.January 2005 Student Release 7.0Confidential Release Guide 155

Section 5 Common Matching - FunctionalForms Used with Matching ProcessRule 1 Rule 2Last Name = RFirst Name = RSSN = YDate of Birth = YCity = YLast Name = RFirst Name = RDate of Birth = YCity = YZIP Code = YZIP Code = YThe value R stands for Required. The value Y stands for Exists.Banner values: Tomasso Dalimonte, SSN = null, Date of Birth = 06/02/78, City =Marikesh, ZIP = 11233External values: Tomasso Dalimonte, SSN = null, Date of Birth = 09/07/59, City =Woodstock, ZIP = 06281The external record will pass the primary match, because the first and last namesmatch. Normally, this would mean that the record would be suspended at aminimum. However, because the Date of Birth, City, and ZIP Code fields specificallydo not match (i.e., none of them are null), then the record's match status is set toNew. This is the only exception to the basic matching algorithm.Forms Used with Matching ProcessCommon Matching Entry Form (GOAMTCH)If Common Matching is turned on (on GUAINST), and the user is not excludedfrom Common Matching on GORCMUS, GOAMTCH is called from the Key Blockof SPAIDEN, SRAQUIK, SAAQUIK when an ID is generated or entered, and the IDdoes not already exist in Banner. Whether or not Common Matching is turned on,the user will be able to access GOAMTCH from SRIPREL, SAAEAPS, and SHAEDISas part of the matching process for data loads.You can enter information for name, address, telephone, date of birth, SSN, etc., inthe Data Entry block. The data entered can be used to assist with matching if thematching rule contains the field being entered. Regardless, the data entered in theData Entry block will be stored in Banner if the person is found to be new.Student Release 7.0 January 2005156 Release Guide Confidential

Section 5 Common Matching - FunctionalForms Used with Matching ProcessThe matching process is called when you perform a Next Block from the Data Entryblock or select the Duplicate Check button. Use the Duplicate Check button toexecute the matching process at any time during the entry of person information.Only those data elements in this form can be used for online matching rules.The Match block is automatically displayed after the matching process is completedand a match is found. This block is accessed using Next Block or the Match tab. Thedata entered remains in the Data Entry block. You can choose to clear the Matchinformation using the Clear button. You will then be returned to the Data Entryblock. The address information in the Match block displays the address type andaddress data that was matched in the matching algorithm.The Potential Matches block displays the potential matches (formerly known assuspense records) found during the search. The number of records found isdisplayed in parentheses in the tab, i.e., “Potential Matches (42)”. You can scrollthrough the potential match records to see the information in each that potentiallymatches the information in the Data Entry block.If any address fields are included in the matching rules being used, and a matchexists on the address of a potential match, then that address will be displayed for thatrecord. To see all address records for a selected potential match, select the AllAddresses pulldown list.Note: If you use GOAMTCH by itself to match a person to an existing personin Banner, and the existing person in Banner has an address of the sameaddress type (where the addresses themselves do not match), the existingBanner address will be inactivated, and the address that was entered onGOAMTCH will be inserted.If you use SAAEAPS or SRIPREL to match a person via GOAMTCH andthe same scenario exists, SRIPREL and SAAEAPS will put an end date onthe existing Banner address and then insert the new address.If the matching rule contains a row for telephone number and/or email address,and a match exists on the telephone number or email address of a potential match,then the phone number and/or email address will be displayed. The date of birthand gender will be displayed for any potential match if they exist in Banner for thepotentially matched record, regardless of whether date of birth or gender are usedin the matching rule.The Match Results field displays the result of the matching algorithm for each fieldincluded in the matching rule. This allows a user to know what data elements thematching rule was using, even if they do not have access to the Common MatchingRules Form (GORCMRL).For example, in the screen below, you can see how the data in the Birth Date andGender fields is displayed for all potential matches, even though neither field existsin the matching rules. You can also see the fields included in the matching rule inthe Match Results field: Name Match, Address Match, Email Match. In addition, you cansee all the Banner addresses for the selected potential match using the All AddressesJanuary 2005 Student Release 7.0Confidential Release Guide 157

Section 5 Common Matching - FunctionalForms Used with Matching Processfield pulldown list. On record number one (ID A00027735) the match results showan email match, even though none exists. That occurred because if the matchingrule on GORCMRL has the Element field set to Email and the Data Required fieldset to Exists, a null email address on either the Banner record or the incomingrecord is still considered to be a match.For more information on how to use GOAMTCH and to review field information,refer to the New Form topic in this enhancement.General Person Identification Form (SPAIDEN)You can access the new Common Matching Entry Form (GOAMTCH) fromSPAIDEN. To do this, turn on Common Matching for the institution using theOnline Matching Process Enabled (Indicator) on GUAINST. In addition, the userattempting to access GOAMTCH must not have been excluded from using it onGORCMUS. However, even if a user has been excluded from Common Matchingon GORCMUS, they can still access GOAMTCH through the Banner GeneralCommon Matching Menu (*GENMATCH) or through the Options Menu.To open GOAMTCH from SPAIDEN: type GENERATED in the ID field, select theGenerate ID button, or enter an ID in the ID field that does not exist in Banner. TheGOAMTCH form will automatically appear. If a person record is created using onlyStudent Release 7.0 January 2005158 Release Guide Confidential

Section 5 Common Matching - FunctionalForms Used with Matching Processthe GOAMTCH form, the Origin field (on SPAIDEN and SPRIDEN) will be set toGOAMTCH. If the person record is created using SRRSRIN or SRIPREL, then theOrigin field will be set to SRKPREL.For more information on how to use GOAMTCH, refer to the New Form topic in thisenhancement.Quick Recruit Form (SRAQUIK)GOAMTCH will be called automatically from SRAQUIK if Common Matching hasbeen turned on in GUAINST and if the user has not been excluded from CommonMatching on GORCMUS. To open GOAMTCH from SRAQUIK: enter GENERATEDin the ID field, select the Generate ID button, or enter an ID in the ID field that doesnot exist in Banner.If the user has been excluded from Common Matching, and they enter GENERATEDin the ID field, select the Generate ID button, or enter an ID in the ID field that doesnot exist in Banner, the Current Identification window will be displayed (asoccurred in Banner prior to version 7.0), allowing the user to enter a new person'sfirst, middle, and last name.For more information on how to use GOAMTCH, refer to the New Form topic in thisenhancement.Quick Entry Form (SAAQUIK)GOAMTCH will be called automatically from SAAQUIK if Common Matching hasbeen turned on in GUAINST and if the user has not been excluded from CommonMatching on GORCMUS. To open GOAMTCH from SAAQUIK: enter GENERATEDin the ID field, select the Generate ID button, or enter an ID in the ID field that doesnot exist in Banner.If the user has been excluded from Common Matching, and they enter GENERATEDin the ID field, select the Generate ID button, or enter an ID in the ID field that doesnot exist in Banner, the Current Identification window will be displayed (asoccurred in Banner prior to version 7.0), allowing the user to enter a new person'sfirst, middle, and last name.For more information on how to use GOAMTCH, refer to the New Form topic in thisenhancement.January 2005 Student Release 7.0Confidential Release Guide 159

Section 5 Common Matching - FunctionalData Loads Used with Matching ProcessData Loads Used with Matching ProcessElectronic Prospect Inquiry Form (SRIPREL)SRIPREL now uses the new GOAMTCH form and the Common Matching algorithmfor data load processing. This greatly improves the user’s ability to determine if theincoming record matches an existing Banner record.Use the following steps to resolve suspended records or to match and load newrecords from SRIPREL.1. Query for prospect records (where the Match Status is S for “suspended”), orby other parameters.2. If you want to view details about the selected record, choose the Details(SRAPREL) item from the Options Menu. If you want to use the matchingalgorithm against the selected record, then choose the Match (GOAMTCH)item from the Options Menu.3. Before you can access GOAMTCH, you will be asked to assign an ID to the newuser, either a generated ID or the person's SSN. When the data is saved, you willbe taken to GOAMTCH.4. When you enter GOAMTCH, the ID field will contain either the wordGENERATED or the selected record’s SSN. The Matching Source field willcontain the matching source code that has been assigned to the interface code,which is also assigned to the electronic prospect code of the selected record onSTVPREL.If no matching source code has been assigned to the interface code, then theMatching Source field will contain the default matching source code that hasbeen assigned to the user ID on GORCMUS. If no default source code hasbeen assigned on GORCMUS, then you will be able to select any matchingsource code from the List of Values.5. Perform a Next Block to populate the Data Entry block with all of the data forthe incoming prospect record that is present in the temporary tables.6. You can update or adjust the data in the Data Entry block if it does not meetyour institution’s data standards. These updates will be copied back to thetemporary tables and used when the prospect's record is created.7. Perform a Next Block to run the matching algorithm. The algorithm willdetermine if the incoming record is new, matched, or a potential match.8. Determine if the record is to be new or matched, and select the appropriatebutton.Student Release 7.0 January 2005160 Release Guide Confidential

Section 5 Common Matching - FunctionalData Loads Used with Matching Process9. The user will be automatically returned to SRIPREL. The match status willalways be Matched, as the person has now been created in Banner viaGOAMTCH. Continue with regular SRIPREL load processing.Electronic Prospect Match (SRRSRIN) and Migrate ElectronicProspects Process (SRRPREL)Users should review how Common Matching works with electronic prospectprocessing when using SRRSRIN and SRRPREL.SRRSRIN will not load recruits to Banner when the Auto Load (Skip Dup Chk)parameter is set to Y and data does not conform to API restrictions.When records with a matched (M) or new (N) status are flagged, the records willnot be loaded to Banner when the Auto Load (Skip Dup Chk) parameter is setto Y if information required to create the record (such as an address) isincomplete.SRRSRIN will now flag records with incomplete addresses or other incompleteinformation as having a status of suspense (S), and these suspended records willneed to be fixed manually on SRIPREL and/or GOAMTCH. It is very importantto fix the incorrect and/or missing information at this point, prior tocontinuing with the matching process. If the incomplete data is not corrected,SRRSRIN will fail.Note: SRRSRIN is the only process that generates records with a match status ofN in Banner 7.0. All records that are processed manually on GOAMTCHwill still have a match status of M, even when you choose to create a newrecord.Here is an example of SRRSRIN output when incomplete addresses are found afterthe process is run with the Auto Load (Skip Dup Chk) parameter set to Y.ID Name Status Term Level Major High School ResultP00002378 Adams, Adam S 199510 UG ARTS UNKNHS Prospect not loadedA00024505 Adams, Alison M 199510 UG ARTS UNKNHS Loaded 29-NOV-2004P00002429 Adebowale, Morayo S 199510 UG ARTS UNKNHS Prospect not loadedA00027348 Albert, Dawn M 199510 UG ARTS UNKNHS Loaded 29-NOV-2004When SRRSRIN is run with the Auto Load (Skip Dup Chk) parameter set to N, thereis no address check, so records will be flagged as matched (M) or new (N), whetherthey have complete address information or not.Since records on a tape with incomplete data such as incomplete addresses willnot be loaded to Banner, SRRPREL has been modified so that records that wereflagged N or M and also have incomplete data will have the match statusJanuary 2005 Student Release 7.0Confidential Release Guide 161

Section 5 Common Matching - FunctionalData Loads Used with Matching Processchanged to S. Again, these suspended records will need to be fixed manually onSRIPREL and/or GOAMTCH. It is very important to fix the incorrect and/ormissing information at this point, prior to continuing the matching process. Ifthe incomplete data is not corrected, SRRSRIN will fail.Here is an example of SRRPREL output when incomplete addresses are found afterSRRSRIN is run with the Auto Load (Skip Dup Chk) parameter set to N.ID Name Status Term Level Major High School ResultA00023291 Abrams, Anthony S 199510 UG ARTS UNKNHS Prospect not loadedA00024505 Adams, Alison M 199510 UG ARTS UNKNHS Loaded 30-NOV-2004A00027662 Martinez, Robert S 199510 UG ARTS UNKNHS Prospect not loadedWhen using SRIPREL, if an attempt is made to load a matched (M) or new (N)record (the Create Recruit item is selected from the Options Menu), and data isincomplete, an error is displayed in the autohint: “Error: Data Error. Prospect has beenput into suspense.” At this point the match status for the record is changed back to S.You can then navigate to GOAMTCH to update the incomplete data (such asmissing address information) and match the record appropriately.Electronic Application Process Form (SAAEAPS)SAAEAPS now uses the new GOAMTCH form and Common Matching algorithm toassist in matching incoming Web and EDI application records to existing Bannerrecords.Use the following steps to resolve suspended records or to match and load newrecords from SAAEAPS.1. Query for the admissions records that have been suspended (where theApplication Status is U for “suspended”), or by any of the other fields.2. Set the Accepted Indicator to Y if it is still set to U.3. Select the Verification Steps tab or the Manual Verification Steps option fromthe Options Menu to access the Verification Steps window.4. Mark any of the person or application steps complete, except for the IDVR step,and then save the changes.5. Select the IDVR step, and then choose the Associate Person with ID item fromthe Options Menu.6. This opens the Associate Person with ID window, where you can choose whichtype of Banner ID to assign to the selected record.Student Release 7.0 January 2005162 Release Guide Confidential

Section 5 Common Matching - FunctionalData Loads Used with Matching Process7. After choosing the appropriate ID type, either save the changes or select theAssociate Person with an ID button. This will display GOAMTCH.8. The ID displayed on GOAMTCH should match the option chosen in theAssociate Person with ID window. The Matching Source field should containthe source code that has been assigned to the interface code on SAAWADF forthe application type of the selected Web application. This source code can bechanged if desired.If no interface code has been specified for the application type on SAAWADF,then the Matching Source field will contain the default source code assigned tothe user ID on GORCMUS. If no default source code has been assigned onGORCMUS, you will be able to select a source code from the List of Values.Perform a Next Block to populate the Data Entry block with all of the data forthe incoming electronic applicant record that is present in the temporarytables.9. You can update or adjust the data in the Data Entry block if it does not meetyour institution’s data standards. These updates will be copied back to thetemporary tables and used when the applicant's record is created.10. Once the data has been “cleaned up”, use a Next Block function to call thematching algorithm, or select the Duplicate Check button.11. The incoming electronic application can be a match, a potential match, or anew record:(a)(b)(c)If the incoming electronic application is found to be a match to someonein Banner, the Banner record will be displayed in the Match block.If the incoming electronic application is found to be a potential matchagainst more than one existing Banner record, then all of the possiblematches will be displayed in the Potential Matches window.If the electronic application is found to be a new record, an Alert Box willbe displayed with a message asking if you want to create the new person.12. If the person is found to be an exact match, you can do one of three things:(a)(b)(c)Match the incoming record to the Banner record but not update any nullfields that exist for the person in Banner by selecting the Select ID button.Match the incoming record to the Banner record and choose to updateany null fields that exist for the person in Banner with data on theincoming record by selecting the Update ID button.Choose to ignore the matched status, and create the person as new byselecting the Create New button.January 2005 Student Release 7.0Confidential Release Guide 163

Section 5 Common Matching - FunctionalData Loads Used with Matching Process13. After selecting one of the options above, the user will be returned to theVerification Steps window, and the IDVR step will be marked as complete.Continue processing the electronic applicant as needed.Online Transcripts Activity List Form (SHAEDIS)SHAEDIS now uses the new GOAMTCH form and the Common Matchingalgorithm to assist in matching incoming records to existing Banner records. Inaddition, you can now create a new person record from GOAMTCH for the personon SHAEDIS.Use the following steps to determine if a person on SHAEDIS matches an existingBanner record or if the person can be created as a new record.1. Query for those records where the Status is VERF and the Pending or CompleteIndicator is set to P.2. Select the record to be matched. Perform either a Next Block function, orselect Verify ID from the Options Menu to call GOAMTCH.3. The form will display the ID of the record from SHAEDIS. If this ID alreadyexists in Banner, then you must replace the ID with the word GENERATED.This will allow GOAMTCH to use a generated ID if the person selected onSHAEDIS is new to Banner.4. The value in the Matching Source field will be defaulted from the OnlineMatching Source field on GORCMUS for the user ID. If the user ID is allowedto use other matching source codes (based on the setting of the Allow OtherMatching Sources checkbox on GORCMUS), then you can change the valueon the Matching Source field on GOAMTCH.5. Use a Next Block to populate the Data Entry block with all of the data for theincoming transcript record that is present in the temporary tables.6. You can update or adjust the data in the Data Entry block if it does not meetyour institution’s data standards. These updates will be copied back to thetemporary tables and used when the prospect's record is created.7. The incoming person’s transcript record can be a match, a potential match, ora new record:(a)(b)(c)If the incoming transcript is found to be a match to someone in Banner,the Banner record will be displayed in the Match block.If the incoming transcript is found to be a possible match against morethan one existing Banner record, then all of the possible matches will bedisplayed in the Potential Matches window.If the transcript is found to be a new record, an Alert Box will be displayedwith a message asking if you want to create the new person.Student Release 7.0 January 2005164 Release Guide Confidential

Section 5 Common Matching - FunctionalNew Form8. If the person is found to be an exact match, you can do one of three things:(a)(b)(c)Match the incoming record to the Banner record but not update any nullfields that exist for the person in Banner by selecting the Select ID button.Match the incoming record to the Banner record and choose to updateany null fields that exist for the person in Banner with data on theincoming record by selecting the Update ID button.Choose to ignore the matched status, and create the person as new byselecting the Create New button.9. After selecting one of the options above, the user will be returned to SHAEDISwhere they can continue processing the record. The asterisk (*) that hadappeared in the unlabeled field to the left of the Last Name field to indicatethe person had not been verified will no longer be displayed.New FormCommon Matching Entry Form (GOAMTCH)If Common Matching is turned on (on GUAINST), and the user is not excludedfrom Common Matching on GORCMUS, GOAMTCH is called from the Key Blockof SPAIDEN, SRAQUIK, SAAQUIK when an ID is generated or entered, and the IDdoes not already exist in Banner. Whether or not Common Matching is turned on,the user will be able to access GOAMTCH from SRIPREL, SAAEAPS, and SHAEDISas part of the matching process for data loads.You can enter information for name, address, telephone, date of birth, SSN, etc., inthe Data Entry block. The data entered can be used to assist with matching if thematching rule contains the field being entered. Regardless, the data entered in theData Entry block will be stored in Banner if the person is found to be new.The matching process is called when you perform a Next Block from the Data Entryblock or select the Duplicate Check button. Use the Duplicate Check button toexecute the matching process at any time during the entry of person information.Only those data elements in this form can be used for online matching rules.Note: If GOAMTCH is called from another form where you can createidentification records, the GENERATE ID button does not appear in theKey Block.In Banner Student, this form is found on the General Person Menu (*PERSON).January 2005 Student Release 7.0Confidential Release Guide 165

Section 5 Common Matching - FunctionalNew FormWildcards and Special CharactersYou can use this form to search for identification records, and you do not need touse wildcard characters (%). You can enter partial information without using awildcard character.The programming logic treats searching and creating data differently:• If you enter % in the First Name field, for example, and create a new record,% will be stored as the person's first name.• If you use a wildcard to search for a record, the Common Matching process willstrip it out. The process removes special characters and forces the data to beuppercase.For example, if you search for Jon%s, the Common Matching process willsearch for JONS, and Jones will not be considered a match.First name is required for all searches for person records. If you want to search onlast name only, you can enter the last name and enter a special character for the firstname.Button DetailThe following buttons are used on GOAMTCH:• Create NewSelect this button if the Common Matching process does not return a recordthat matches the one you are entering, or if none of the potential matches thatwas returned matches the record you are entering. This creates a new PIDM inBanner. If biographical data, email address, telephone number, or completeaddress information has been entered in the Data Entry block, thecorresponding records will created in Banner.• Select IDSelect this button if Common Matching has found an existing record that is amatch for the one you are entering. This populates the form on which you wereentering data with the existing Banner data for that person or non-person. Youare automatically taken back to the original form, and a new PIDM is not addedto the database.• Update IDSelect this button if Common Matching has found a record that matches theone you're entering, and you have entered information in GOAMTCH thatshould be added to the existing record. Only null fields on the existing Bannerrecord will be updated. The record is changed, but a new PIDM is not addedto the database.Student Release 7.0 January 2005166 Release Guide Confidential

Section 5 Common Matching - FunctionalNew FormFor example, if Common Matching finds the person's record but there is nobilling address, and you have added the billing address in the Data Entry block,selecting this button will add a billing address record to the existing addressrecords.• DetailsSelect this button if Common Matching has found potential matches and youneed to do additional research to see if any of them match the record you areadding. A list of forms will appear, from which you can select the form you wishto access.Note: The list of research forms displayed by selecting the Details button isdetermined by how the matching source code is set up on the CommonMatching Source Code Rules Form (GORCMSC). If you do not set upany forms to be called, the Details button will be disabled.• Duplicate CheckSelect this button to trigger the Common Matching process withoutperforming a Next Block function.The following results will occur when the Duplicate Check button is used:1. The record is new. No match has been found in the database. The record canbe created without any additional processing, and Banner will assign a newPIDM to it.2. A match is found for the record. Common Matching has found one, and onlyone, Banner record that matches the record based on the rules. The CommonMatching Entry Form (GOAMTCH) appears with the Match tab highlighted.The user must review the displayed data to see if the matched Banner record isthe same as the one they are trying to enter.(a)If the record found in the database is the same as the one being entered,you can select the person or non-person as a match, or update the recordwith additional information, but Banner will not assign a new PIDM.Note: You can only update fields on an existing Banner record if they are nullin the Banner database. If data already exists for those fields, it will notbe overwritten.(b)If the record found in the database is not the same as the one beingentered, you can create a new record. Banner will assign a new PIDM tothe record when it is saved.3. A potential match is found. Common Matching has found at least one recordwhere some of the fields identified in the rule match the record being entered,but not all.January 2005 Student Release 7.0Confidential Release Guide 167

Section 5 Common Matching - FunctionalNew FormFor example, the first name and last name are the same, and the mailingaddress is the same, but the date of birth is different. GOAMTCH then appearswith the Potential Matches tab highlighted. You can review each potentialmatch to determine if one is, in fact, a match. If multiple records meet thematching criteria, they are all displayed in the Potential Matches block.(a)(b)If one of the potential matches is the same as the one being entered, youcan select the record as a match, or update it with additional information.Banner will not assign a new PIDM. If the record is updated, existing datawill not be overwritten.If none of the potential matches is the same as the one being entered, youcan create a new record. Banner will assign a new PIDM to the record.Key BlockUse this block to enter the ID to be matched and the matching source code for thematch rules to be used in the search.The following fields are in the Key Block.Fields. . . . . . . . . . . . . .IDDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .The ID that is being compared to existing IDs in the database formatching.This must be a generated value (select the Generate ID button orenter GENERATED in the ID field), or an ID that does notcurrently exist in the database.MatchingSourceThe common matching source code associated with the userentering the new ID. This source code will determine which rulesthe Common Matching algorithm uses to search for a match. Ifyou checked the Allow Other Matching Sources check box on theGORCMUS form for this user, that person will be able to select adifferent source code.(lookup) List Common Matching SourceCode (GTVCMSC)More buttons in the Key BlockMouse Keyboard ResultGenerate ID N/A Generate new one-up Banner IDStudent Release 7.0 January 2005168 Release Guide Confidential

Section 5 Common Matching - FunctionalNew FormData Entry BlockEnter the information for the person or non-person in this block, unless it has beenpopulated automatically from the original form where you were working (i.e.,SRIPREL). The Common Matching algorithm will use the rules for the matchingsource to see if an identification record already exists in the database for that personor non-person.The following fields are in the Data Entry block.Fields. . . . . . . . . . . . . .Last NameDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Last name of the person being matched. Either Last Name orNon-Person Name is required.First NameFirst name of the person being matched.Middle NameMiddle name of the person being matched.Address TypeAddress type code for the address being entered. This will beautomatically populated if a default value for address type is setup for the matching source code on GORCMSC.This field is not used by the Common Matching algorithm todetermine if the identification record being entered alreadyexists in the database. It is used to populate a new record whenno existing record was found or to update an existing recordwhen that field was null in the database.(lookup) List Address Type Validation(STVATYP)Street Line 1First line of the street address.This field is not used by the Common Matching algorithm todetermine if the identification record being entered alreadyexists in the database. It is used to populate a new record whenno existing record was found or to update an existing recordwhen that field was null in the database.Street Line 2Second line of the street address.This field is not used by the Common Matching algorithm todetermine if the identification record being entered alreadyexists in the database. It is used to populate a new record whenno existing record was found or to update an existing recordwhen that field was null in the database.January 2005 Student Release 7.0Confidential Release Guide 169

Section 5 Common Matching - FunctionalNew FormFields. . . . . . . . . . . . . .Street Line 3Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Third line of the street address.This field is not used by the Common Matching algorithm todetermine if the identification record being entered alreadyexists in the database. It is used to populate a new record whenno existing record was found or to update an existing recordwhen that field was null in the database.CityCity of the address.State orProvinceState or province code for the address.(lookup) List State/Province CodeValidation (STVSTAT)ZIP or PostalCodeZIP or postal code for the address.(lookup) List ZIP/Postal Code ValidationForm (GTVZIPC)CountyCounty code for the address.(lookup) List County Code Validation(STVCNTY)NationNation code for the address.(lookup) List Nation Validation (STVNATN)Non-PersonNameName of the non-person being entered into the database. EitherLast Name or Non-Person Name is required.SSN/SIN/TINSocial Security Number, Social Insurance Number, or TaxIdentification Number of the person or non-person beingentered into the database.Birth Date DayThe two-digit birth day.Birth DateMonthThe two-digit birth month.Birth Date YearThe four-digit birth year.Student Release 7.0 January 2005170 Release Guide Confidential

Section 5 Common Matching - FunctionalNew FormFields. . . . . . . . . . . . . .GenderDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .The person's gender.Valid values are: Female, Male, Not Available, NULL.E-mail TypeEmail type code for the email address being entered. This will beautomatically populated if a default value for email type is set upfor the matching source code on GORCMSC.This field is not used by the Common Matching algorithm todetermine if the identification record being entered alreadyexists in the database. It is used to populate a new record whenno existing record was found or to update an existing recordwhen that field was null in the database.(lookup) List E-mail Type Validation(GTVEMAL)E-mailEmail address of the person or non-person being added to thedatabase.Telephone TypeTelephone type code for the telephone number being entered.This will be automatically populated if a default value fortelephone type is set up for the matching source code onGORCMSC.This field is not used by the Common Matching algorithm todetermine if the identification record being entered alreadyexists in the database. It is used to populate a new record whenno existing record was found or to update an existing recordwhen that field was null in the database.(lookup) List Telephone Type Validation(STVTELE)Telephone (AreaCode)The three-character telephone area code.TelephoneNumber(Untitled)The seven-character telephone number.TelephoneExtension(Untitled)The four-character telephone extension.January 2005 Student Release 7.0Confidential Release Guide 171

Section 5 Common Matching - FunctionalNew FormRecords are held in suspense, as partially matched, and you can use the followingbuttons to continue processing.More buttons in the Data Entry BlockMouse Keyboard ResultCreate New Create as New (F6) Reject all matches; create record asnewSelect ID Select ID (F4) Match ID in Data Entry block to ID inMatch blockUpdate ID Update Matched (Shift + F4) Match ID in Data Entry block to ID inMatch block and insert data intonull fields in SPBPERS,SPRADDR, and/or GOREMALtablesDetails Detail Options (F8) Display list of forms for additionalmatch researchDuplicateCheckCommit (F10) or Next BlockExecute match algorithm, run asneeded from Data Entry blockuntil match is satisfactoryMatch BlockThis block is accessed using Next Block or the Match tab. The Match block isautomatically displayed after the matching process is completed and a match isfound. The data entered remains in the Data Entry block. You can choose to clearthe Match information using the Clear button. You will then be returned to the DataEntry block. The address information in the Match block displays the address typeand address data that was matched in the matching algorithm.If the record found by the matching process is a match for the record being entered,use the Select ID button to bring the information back to the form on which youwere entering data, or use the Update ID button if you have added information tothe Data Entry block that does not exist in the database record. If you have a largenumber of potential matches, you may want to select the Clear button to erase theinformation in this block and enter more restrictive criteria in the Data Entry block.You can enter additional information to reduce the number of potential matchesfound by the Common Matching process. To see the new list of potential matches,you must execute the process again by performing a Next Block function orselecting the Duplicate Check button.Note: The Common Matching process uses the rules defined for the MatchingSource in the Key Block to determine if the identification record beingentered already exists on the Banner database. If you do not receive theresults you expect after the Common Matching process has beenexecuted, review the rules for the Matching Source on GORCMRL.Student Release 7.0 January 2005172 Release Guide Confidential

Section 5 Common Matching - FunctionalNew FormThe following fields are in this block. All the fields in this block are display-only, nondatabasefields.Fields. . . . . . . . . . . . . .IDDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Identification number of the matched record.If an asterisk (*) appears next to the ID, the match occurred onan alternate ID, and the alternate ID is the one that is displayed.NameName associated with the ID.If an asterisk (*) appears next to the name, the match occurredon the alternate name, and the alternate name is the one that isdisplayed.AddressAddress associated with the ID in the Match block.The address information will be displayed if any address fieldswere part of the rule and a match occurred on one of the addressrecords.TelephoneTelephone number associated with the ID in the Match block.The telephone number will be displayed if any telephone fieldswere part of the rule and a match occurred on one of thetelephone fields.Birth DateBirth date associated with the ID.SSN/SIN/TINSocial Security Number, Social Insurance Number, or TaxIdentification Number associated with the ID.E-mailEmail address that matches the email address in the Data Entryblock.This is the same email address that appears in the Data Entryblock if the email address was used in the matching rules onGORCMRL.GenderGender of the person.All AddressesPulldown list that displays all of the addresses for the matched ID.Only the Street Line 1, City, State, and ZIP Code are displayed foreach address.January 2005 Student Release 7.0Confidential Release Guide 173

Section 5 Common Matching - FunctionalNew FormFields. . . . . . . . . . . . . .Match PriorityDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Indicates the rule priority (set up on GORCMRL) of the rule thatthe Common Matching algorithm used to find the match.Match ResultsLists the criteria on which the match is based.More buttons in the Match BlockMouse Keyboard ResultClear N/A Clear Match block data to add orchange data for the matchPotential Matches BlockThe Potential Matches block displays the potential matches (formerly known assuspense records) found during the search. The number of records found isdisplayed in parentheses in the tab, i.e., “Potential Matches (42)”. You can scrollthrough the potential match records to see the information in each that potentiallymatches the information in the Data Entry block.If any address fields are included in the matching rules being used, and a matchexists on the address of a potential match, then that address will be displayed for thatrecord. To see all address records for a selected potential match, select the AllAddresses pulldown list.Note: If you use GOAMTCH by itself to match a person to an existing personin Banner, and the existing person in Banner has an address of the sameaddress type (where the addresses themselves do not match), the existingBanner address will be inactivated, and the address that was entered onGOAMTCH will be inserted.If you use SAAEAPS or SRIPREL to match a person via GOAMTCH andthe same scenario exists, SRIPREL and SAAEAPS will put an end date onthe existing Banner address and then insert the new address.If the matching rule contains a row for telephone number and/or email address,and a match exists on the telephone number or email address of a potential match,then the phone number and/or email address will be displayed. The date of birthand gender will be displayed for any potential match if they exist in Banner for thepotentially matched record, regardless of whether date of birth or gender are usedin the matching rule.Student Release 7.0 January 2005174 Release Guide Confidential

Section 5 Common Matching - FunctionalNew FormThe Match Results field displays the result of the matching algorithm for each fieldincluded in the matching rule. This allows a user to know what data elements thematching rule was using, even if they do not have access to the Common MatchingRules Form (GORCMRL).To find more information about a record, select it and then select the Details buttonin the Data Entry block. A list of forms will be displayed, and you can select the formyou wish to access.The following fields are in this block.Fields. . . . . . . . . . . . . .IDDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Identification number of the potential match.If an asterisk (*) appears next to the ID, the match occurred onthe alternate ID, and the alternate ID is the one that is displayed.NameName associated with the ID.If an asterisk (*) appears next to the name, the match occurredon the alternate name, and the alternate name is the one that isdisplayed.SSN/SIN/TINSocial Security Number, Social Insurance Number, or TaxIdentification Number of the potential match from the Bannerdatabase.AddressAddress of the potential match from the Banner database.The address will be displayed if any address fields were part of therule and a match occurred.CityCity of the matched address from the Banner database.StateState of the matched address from the Banner database.ZIP/PostalZIP code or postal code of the matched address from the Bannerdatabase.NationNation code of the matched address from the Banner database.TelephoneTelephone number of the potential match from the Bannerdatabase.The telephone number will be displayed if any telephone fieldswere part of the rule and a match occurred.January 2005 Student Release 7.0Confidential Release Guide 175

Section 5 Common Matching - FunctionalChanged FormsFields. . . . . . . . . . . . . .E-mailDescriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Email address of the potential match from the Banner database.This is the same email address that appears in the Data Entryblock if the email address was used in the matching rules onGORCMRL.Birth DateBirth date of the potential match from the Banner database.GenderGender of the potential match from the Banner database.All AddressesPulldown list that displays all of the addresses for the matched ID.Only the Street Line 1, City, State, and ZIP Code are displayed foreach address.Match PriorityIndicates the rule priority (set up on GORCMRL) of the rule thatthe Common Matching algorithm used to find the match.Match ResultsLists the criteria on which the match is based.More buttons in the Match BlockMouse Keyboard ResultClear N/A Clear Potential Matches block data toadd or change data for thepotential matchChanged FormsGeneral Person Identification Form (SPAIDEN)You can access the new Common Matching Entry Form (GOAMTCH) fromSPAIDEN using the Common Matching (GOAMTCH) item in the Options Menu.SPRIDEN rows can be created on GOAMTCH.Student Release 7.0 January 2005176 Release Guide Confidential

Section 5 Common Matching - FunctionalChanged FormsQuick Recruit Form (SRAQUIK)You can access the new Common Matching Entry Form (GOAMTCH) fromSRAQUIK using the Common Matching (GOAMTCH) item in the Options Menu.SPRIDEN rows can be created on GOAMTCH.When Common Matching is turned on globally or for user ID, GOAMTCH isdisplayed in place of the Current Identification window.Electronic Prospect Inquiry Form (SRIPREL)You can access the new Common Matching Entry Form (GOAMTCH) fromSRIPREL using the Match (GOAMTCH) item in the Options Menu.SPRIDEN rows can be created on GOAMTCH. Data field values that are updated onGOAMTCH will be copied back to their associated temporary tables on SRIPREL.SRIPREL used to call SRQMTCH, which is now obsolete.Quick Entry Form (SAAQUIK)You can access the new Common Matching Entry Form (GOAMTCH) fromSAAQUIK using the Common Matching (GOAMTCH) item in the Options Menu.SPRIDEN rows can be created on GOAMTCH.When Common Matching is turned on globally or for user ID, GOAMTCH isdisplayed in place of the Current Identification window.Electronic Application Process Form (SAAEAPS)You can access the new Common Matching Entry Form (GOAMTCH) fromSAAEAPS using the Associate Person with ID item in the Options Menu when youare in the Manual Person Verification Steps block.SPRIDEN rows can be created on GOAMTCH. Data field values that are updated onGOAMTCH will be copied back to their associated temporary tables on SAAEAPS.SAAEAPS used to call SOQMTCH, which is now obsolete.Online Transcripts Activity List Form (SHAEDIS)You can access the new Common Matching Entry Form (GOAMTCH) fromSHAEDIS using a Next Block from the unmatched name.January 2005 Student Release 7.0Confidential Release Guide 177

Section 5 Common Matching - FunctionalChanged FormsSPRIDEN rows can be created on GOAMTCH. Data field values that are updated onGOAMTCH will be copied back to their associated temporary tables.SHAEDIS used to call SOQMTCH, which is now obsolete.Person Search Form (SOAIDEN)You can access the new Common Matching Entry Form (GOAMTCH) fromSOAIDEN. SPRIDEN rows can be created on GOAMTCH.Person Search Detail Form (SOAIDNS)You can access the new Common Matching Entry Form (GOAMTCH) fromSOAIDNS. SPRIDEN rows can be created on GOAMTCH.Tape Interface Rules Form (SOAINFR)This form has been replaced by the new Common Matching Rules Form(GORCMRL). SOAINFR is now a query only form, so current rules can still bedisplayed but not updated.Interface Validation Form (STVINFC)You can now map an interface code to a Common Matching source rule.The Common Matching Source field has been added to link the student matchingprocess with the new match routine. Valid values for this field come from theCommon Matching Online Source Code (GTVCMSC) list.Electronic Applicant Web Default Rules Form (SAAWADF)References to the obsolete SORINFR table have been changed to the STVINFCtable, which links the interface code to the Common Matching source code.Electronic Prospect Validation Form (STVPREL)References to the obsolete SORINFR table have been changed to the STVINFCtable, which links the interface code to the Common Matching source code.Student Release 7.0 January 2005178 Release Guide Confidential

Section 5 Common Matching - FunctionalObsolete FormsObsolete FormsFirst Name Translation Rules Form (SOANAME)This form has been replaced by the Name Translation Names Form (GORNAME).Person Matching Form (SOQMTCH)This form has been replaced by GOAMTCH.Prospect Matching Form (SRQMTCH)This form has been replaced by GOAMTCH.Changed MenusGeneral Person (*PERSON)The Common Matching Entry Form (GOAMTCH) has been added to the GeneralPerson Menu (*PERSON) in Banner Student. This form is also listed on menus inBanner General and Banner Financial Aid.Search Tape Control Menu (*SEARCHCONT)The First Name Translation Rules Form (SOANAME) has been removed from theSearch Tape Control Menu (*SEARCHCONT).Student System Management Menu (*SMANAGER)The First Name Translation Rules Form (SOANAME) has been removed from theStudent System Management Menu (*SMANAGER).January 2005 Student Release 7.0Confidential Release Guide 179

Section 5 Common Matching - FunctionalChanged Reports and ProcessesForms Not on MenusPlease note that the Person Matching Form (SOQMTCH) and the ProspectMatching Form (SRQMTCH), which are now obsolete, were not displayed on anyBanner Student menus.Changed Reports and ProcessesElectronic Prospect Match (SRRSRIN)This process has been updated to call the new matching procedure, instead ofcalling SAKMTCH. A new SAKMTCH procedure, p_insert_sotcmme, is used topopulate the temporary table for high school matching data fields.Elec App Verify/Load Process (SARETMT)This process has been updated to call the new matching procedure, instead ofcalling SAKMTCH. A new SAKMTCH procedure, p_insert_sotcmme, is used topopulate the temporary table for high school matching data fields.The following parameters have been removed from the process:• Match only on SSN and Last Name• Match on Current SPRIDEN• Last Name Only Match LengthThe Interface Code w/Match Rules parameter now uses the matching rulesassociated with the interface code on STVINFC to match the application to Banner.If users want to match on just SSN and last name, they can create a matching ruleon GORCMRL to do so.Report SampleElec App Verify/Load Process (SARETMT)Please see the following landscaped section for report parameters and sampleoutput.Student Release 7.0 January 2005180 Release Guide Confidential

Section 5 - Common MatchingSample ReportElec App Verify/Load Process (SARETMT)DescriptionThis process matches, verifies, and loads electronic applications to Banner production tables using the matching rules definedon SOAINFR or by matching on SSN and Last Name. The process performs the test score equivalency lookup and then storesthe equivalent test scores if applicable.This process has three report sections. The first two sections are optional and collect and print the following: successfullyverified and/or loaded applications, applications with verification or load errors, and detail or summary information. Thethird section is the control page.Processing NotesThe Interface Code parameter provides the values for the matching algorithm, which determines if the record status is eitherNew, Matched, Suspense, or Error. The matching needs to be done only for new applicants. If the person is not matched toa Banner record, a new SPRIDEN row will be created for the person with either a generated ID or the SSN, the SABSTUD rowwill be created with a new pidm value, and the Person Status (Indicator) will be updated to Y. If the person matches a Bannerrecord, the SABSTUD row will be created with the Banner pidm value, and the Person Status (Indicator) will be updated toY. If the person falls into the suspense group, the Person Status (Indicator) will be updated to S. Applications must have a Yin the Person Status (Indicator) before they can be pushed into Banner production.The Previously Applied and Previously Attended elements appear in the Name section of the Web data entry pages. Assumingthese elements are added to the Name section using SAAWAPP, if the student is in suspense status, and they state that theyhave never attended or submitted an application, the person status will be changed from Suspense to New.If the electronic applicant read in the main select has already been through the match phase and they have a SPRIDEN record,the match step will be bypassed. This may happen in the case of applicants who are initially put into the match-suspense state.The user needs to resolve the suspense issue using SAAEAPS. They have the option of completing the verification processonline after resolving the match issues and accepting the person status or re-running SARETMT.Student Release 7.0 January 2005181 Release Guide Confidential

Section 5 - Common MatchingSample ReportThe electronic applicant may also have a SPRIDEN record if they have been identified as an existing student at the onset ofthe web application process. The web application packages already insert the PIDM in the electronic application holdingtables. In this case the matching steps will also be bypassed.If the Override App. Status Ind. parameter is set to N, then this step must be done manually on SAAEAPS, if there are anyapplication status rules defined on STVASTA. If there are no application status rules, the applicant’s application status willautomatically be set to Y.If the Override App. Status Ind. parameter is set to Y, the applicant’s Application Status (Indicator) will automatically be set toY. The Application Status (Indicator) must be Y before the application is pushed into Banner production.Once the electronic application has been matched or determined to be new, the verification package is executed. This is thesame processing as that which occurs in SAAEAPS. The verification rules follow the procedures and routines entered onSAAECRL for a given application type. Once the verification process has been completed successfully, the Process (Indicator)on SAAEAPS is set to V for Verified. Applications must have a V in the Process (Indicator) field before they can be pushed intoBanner production.The last task is to load the application into Banner. To achieve this, the application must be completed, have an acceptedstatus, the manual person and application verification Completion Indicators must both be Y, and the Process (Indicator)must be V. Once the application is loaded, the Process (Indicator) which displays on SAAEAPS will be updated to the valueP for application pushed.Parameters Name Required? Description ValuesInterface Code w/MatchRulesYesEnter the interface code associated with thematching rules on GORCMRL to be used inmatching the application to Banner.Interface Validation Form (STVINFC)Application Source No Enter the application source code for the electronicapplications, or enter % for all.EDI Application Source CodeValidation Form (STVAPLS)Student Release 7.0 January 2005182 Release Guide Confidential

Section 5 - Common MatchingSample ReportParameters (cont.) Name Required? Description ValuesApplication Type No Enter the application type code for the electronicapplications, or enter % for all.Application Type Code ValidationForm (STVWAPP)Start Date Range No Enter the start date for when the applications werecreated in format DD-MON-YYYY.End Date Range No Enter the end date for when the applications werecreated in format DD-MON-YYYY.Term Code No Enter the term code for the electronic applications,or enter % for all.Term Code Validation Form(STVTERM)Override App. StatusInd.YesEnter Y to override the application status indicatoror N to not override the indicator. The default is Y.YNOverride statusDo not overrideOverride App. AcceptInd.YesEnter Y to override the application accept indicatoror N to not override the indicator. The default is Y.YNOverride acceptDo not overrideUse Generated ID, SSN,or Web IDYesEnter G to use the Generated ID, S to use the SSN,or E to use the Web ID for the application beingmatched, verified, and pushed. The default is G.GSEGenerated IDSSNWeb IDStudent Release 7.0 January 2005183 Release Guide Confidential

Section 5 - Common MatchingSample ReportParameters (cont.) Name Required? Description ValuesPrint Detail/Summaryor ErrorsYesEnter D for Print Detail, E for Errors, B for Both, orS for Summary. The default is D.DEDetailErrorsIf D is entered, the electronic application ID, BannerID, name, application source and type, term, matchstatus, and curriculum will be printed.BSBothSummaryIf E is entered, the electronic application ID, BannerID, name, application source and type, term, matchstatus, and the process indicator error message willbe printed.If S is entered, summary information will be printed.Audit or Update Yes Enter A to produce an audit report or U to updatethe database.AUAuditUpdateStudent Release 7.0 January 2005184 Release Guide Confidential

Section 5 - Common MatchingSample ReportParameters (cont.) Name Required? Description ValuesCreate Recruit Records Yor NYesEnter Y to call the sakmods.p_create_recruitpackage after the application is pushed to create acorresponding recruit record for the applicant.Enter N to not create a corresponding recruitrecord. The default is N.YNCreate recruit recordDo not create recruit recordSource Code for RecruitRecordNoEnter the SBGI source code to be inserted in thenewly created recruit record. Valid values come fromSTVSBGI, and the SBGI source code selected will beinserted in the recruit record. The value enteredinto this field will be inserted in theSRRRSRC_SBGI_CODE field for the recruit record.Source/Background Institution CodeValidation Form (STVSBGI)Student Release 7.0 January 2005185 Release Guide Confidential

Section 5 - Common MatchingSample ReportReport Sample—Elec App Verify/Load Process (SARETMT)16-DEC-2004 13:59:25 BANNER University PAGE 1Electronic Applicant Verify/Load Process SARETMTC O M P A R I S O N P R O C E S S I N GInterface Type: DAYTReport Print: DETAILSProcess Date: 16-DEC-2004ID NAME TERM APP NO SOURCE TYPE ADD DATE STATUS SPRIDEN ID PROC IND* * * CURRICULUM * * * * * * FIELDS IN ERROR * * *bonner Bonner, Charles 200310 1 WEB DA 22-SEP-2004 N/A A00023095 V Push ErrBS in Marketingbdelpapa Delpapa, Bonnie K 200310 2 WEB DA 10-SEP-2004 MATCH A00022382 E Verify ErrBA in Anthropology210009107 George, Gail 200310 4 WEB DA 23-NOV-2004 N/A 210009107 P PushedBA in Artpaulklee Klee, Paul 200310 4 WEB DA 05-NOV-2004 N/A 300444012 P PushedBA in BotanyStudent Release 7.0 January 2005186 Release Guide Confidential

Section 5 - Common MatchingSample Report16-DEC-2004 13:59:25 BANNER University PAGE 2Electronic Applicant Verify/Load Process SARETMT* * * REPORT CONTROL INFORMATION - SARETMT - Release 7.0 * * *Report Name............: SARETMTMatch Interface Type...: DAYTSource(s)..............: WEBApplication Types(s)...: All Types UsedStart Date.............: 01-JAN-2004End Date...............: 31-DEC-2004Terms Used.............: 200310Override App. Status Ind.: YOverride App. Accept Ind.: YSSN or Generated ID....: GReport Print...........: DAudit/Update Mode......: ACreate Recruit.........: YRecruit Source .........:RECORDS READ COUNT.....: 4REPORT COUNTS:Suspend................: 0Match Errors...........: 0New Persons............: 0Matched Persons........: 1Total Processed through..Match Process........: 1Total Held.............: 0Total Verified.........: 1Total Verify Errors....: 1Total Pushed...........: 2Total Push Errors......: 1Student Release 7.0 January 2005187 Release Guide Confidential

Section 5 - Common MatchingSample ReportThis page intentionally left blankStudent Release 7.0 January 2005188 Release Guide Confidential

Section 6 Improved Drop/Withdrawal Processing (Defect 49132) - FunctionalOverviewSection 6Improved Drop/Withdrawal Processing(Defect 49132) - FunctionalThis enhancement was included in Release 6.1 and contained fixes related to Defect49132.This enhancement includes modifications and updates for baseline BannerStudent, as well as Faculty and Advisors Self-Service, Student Self-Service, and VoiceResponse. Please refer to the release guides for these products for additionalinformation.Please refer to the Registration chapter of the Student User Guide for detailedprocedure information, processing examples, report parameters, and a reportoutput sample.OverviewPreviously, when a student was registered in two associated or “connected” courses(co-requisites, pre-requisites, or linked courses), and a user requested that one ofthe courses be dropped, the course was allowed to be dropped. Standardregistration error checking then caused the other (associated) course to be droppedas part of the schedule cleanup processing. This resulted in the student beingdropped from both classes without being warned and without the possibility ofoverriding the change or being prevented from making the original change. Thestudent was also then given a 100% refund for the associated dropped course, whichin many cases was incorrect. Basically, if the user inadvertently or unknowinglydropped a course that was associated with other courses on the student’s schedule,all associated courses were automatically dropped.With the delivery of this enhancement, courses cannot be dropped via the Web orVoice Response and refunded at 100% unless the drop meets criteria specified intwo new rules on the Crosswalk Validation Form (GTVSDAX) and has been assignedthe appropriate setup code (allowing a course to be dropped and refunded at100%) on the Course Registration Status Form (SFARSTS) (for traditional courses)or the Schedule Processing Rules Form (SSARULE) (for Open Learning courses).Connected courses are included in this processing.Note: A connected course will no longer be dropped and given a 100% refundunless the code is designated for use on SFARSTS or SSARULE.Errors are tracked as the following:January 2005 Student Release 7.0Confidential Release Guide 189

Section 6 Improved Drop/Withdrawal Processing (Defect 49132) - FunctionalOverview• Registration add (displayed on the Add or Drop Classes page[bwlkfrad.P_FacAddDropCrse] when a class is added), which reports errorsthat are encountered when a student is trying unsuccessfully to register for aclass, for example a time conflict.• Registration update (displayed on the Add or Drop Classes page), which appearswhen a connected course is dropped or withdrawn from and either has nodrop code assigned or has multiple drop codes assigned, and can also appearwhen a student tries to change the status of a course that has a connection.• Administrative (not displayed to the student), which can be reviewed on the newRegistration Admin Messages Report (SFRRGAM).Web registration now uses the Type field on the Course Registration Status CodeValidation Form (STVRSTS) to determine the type of code that can be placed onthe student course and the processing that is affected based on this code. This typecode determines what is displayed in the Action pulldown list on the Add or DropClasses page.• If the course status is marked as an R (Registered) type code, then all other typecodes can be displayed (depending on their availability).• If the course status is marked as a D (Drop) or W (Withdrawal), then only Rtype actions will be displayed.The system no longer allows a student to drop a course that has already beendropped or withdrawn from.Note: If the Type field is left blank, unexpected results can occur.New TerminologyThe documentation for this release introduces several new terms, which are definedas follows.• Connected refers to courses that are associated with each other via co-requisites,pre-requisites, or links.• Connection refers to a set of connected courses. For example, the connectedcourses of Biology 101 lecture and lab (co-requisites) would be considered aconnection.Automatic DropsAn automatic drop is one that occurs if certain conditions are met when a userattempts to drop a connected course. When a connected course is dropped, theappropriate drop code and refund (if any) are applied to the student.A single, active drop code must be available for a successful connected or automaticdrop to occur.Student Release 7.0 January 2005190 Release Guide Confidential

Section 6 Improved Drop/Withdrawal Processing (Defect 49132) - FunctionalOverview• If no drop codes exist for any part of a connection, no courses in theconnection are allowed to be dropped.• If multiple drop codes exist for any part of a connection, no courses in theconnection are allowed to be dropped automatically. This is because the systemdoes not choose which drop code to use for the automatic drop. In this case,the user can initiate the drop by selecting one of the multiple drop codes wherenecessary. The drop is processed with the selected drop code, and the refund(if any) associated with the code is applied.When a student is dropped or withdraws from a connected course without droppingthe entire connection, the system determines which of the following conditionsapplies and takes the necessary action.Note: In Voice Response, error checking is performed on each CRN as it isentered. Because of this, if you enter N for the AUTODROP rule, it willnot be possible for connected courses to be dropped. Therefore, SCTrecommends that you use either C or Y for the AUTODROP rule.The connected course(s) that can be dropped are dropped with the appropriatedrop code based on the settings on the following forms:• Crosswalk Validation Form (GTVSDAX)• Course Registration Status Form (SFARSTS) (for traditional courses)• Schedule Processing Rules Form (SSARULE) (for Open Learning courses)The code designated in WEBRSTSDRP is no longer used as a “clean up” code forregistration errors related to automatic drops and administrative drops. Otherwise,the WEBRSTSDRP code works as usual. (For example, if a user tries to register astudent for Psychology 200 and the registration results in a PREQ or TEST SCOREerror, the DW code is used to remove the course from the schedule and reverse anycharges that were associated with it.)Another change to WEBRSTSDRP code processing is that if your institution doesnot allow a student’s last class to be dropped via the Web (that is, the external codefor WEBDROPLST is N), then the system will not drop a connection if the studentis not registered in any other classes.Connected Drops Allowed with User ApprovalYou want the system to notify the user if one course is dropped, but a course to whichit is associated is not, thereby allowing the user to choose to drop both or to dropneither. To accomplish this, you have set the external code to C for the AUTODROPrule.January 2005 Student Release 7.0Confidential Release Guide 191

Section 6 Improved Drop/Withdrawal Processing (Defect 49132) - FunctionalOverviewConnected Drops Processed AutomaticallyYou want the system to automatically drop a linked course if the course to which itis linked is dropped. To accomplish this, you have set the external code to Y for theAUTODROP rule.Connected Drops Not AllowedYou do not want students to be able to drop a connected course unless all thecourses in the connection are dropped simultaneously by the user. To accomplishthis, you have set the external code to N for the AUTODROP rule.Drop Last Class Not AllowedYou do not want a student to be able to drop his or her last class via the Web. Toaccomplish this, you have set the external code to N for the WEBDROPLST rule.Administrative DropsAn administrative drop is one that occurs automatically when a user accesses astudent’s registration record after certain changes that affect registration recordsoccur within the system, after registration has opened and enrollment for a courseexists. These changes can include:• A CRN’s pre-requisites are changed.• A CRN’s co-requisites are changed.• A CRN is linked to another CRN.• An approval requirement is added to a CRN.• The number of hours associated with a CRN are changed (which can cause astudent already registered to exceed a maximum-hours limit).• The meeting day or time of a CRN is changed (which can cause a time conflictin a student’s schedule).• An equivalent course is added (which can cause a duplicate course error on thestudent's schedule).When a student has registered and later their registration record is accessed via theWeb or Voice Response, the system determines whether any of the above kinds ofchanges occurred. If so, the system determines which of the following conditionsapplies and takes the necessary action.If the student’s record is accessed and changed in the Student Course RegistrationForm (SFAREGS), any administrative errors encountered must be resolved.You can run the new Registration Admin Messages Report (SFRRGAM) to reviewadministrative drop errors that need to be resolved.Student Release 7.0 January 2005192 Release Guide Confidential

Section 6 Improved Drop/Withdrawal Processing (Defect 49132) - FunctionalOverviewAdministrative Drop if an Approval is Added to a CRNYou want the system to perform administrative drops. To accomplish this, you haveto set the external code to Y for the ADMINDROP rule. You have also included asingle, active drop code (DC for Drop Course) for the specific section on theseforms:• Schedule Processing Rules Form (SSARULE) (for Open Learning courses)• Course Registration Status Form (SFARSTS) (for traditional courses)Administrative Drop if a Co-requisite is Added to a CRNYou want the system to perform administrative drops. To accomplish this, you haveset the external code to Y for the ADMINDROP rule. You have included a single,active drop code (DC for Drop Course) on the Schedule Processing Rules Form(SSARULE) for two specific sections.Administrative Drops if Active Drop Codes are Not DefinedYou want the system to perform administrative drops. To accomplish this, you haveset the external code to Y for the ADMINDROP rule. You have included a single,active drop code (DC for Drop Course) for the specific section on the ScheduleProcessing Rules Form (SSARULE), but you have not defined an active drop codefor another specific section on SSARULE (for Open Learning courses) or theCourse Registration Status Form (SFARSTS) (for traditional courses).Administrative Drops if Other Errors are Found during ProcessingYou want the system to perform administrative drops. To accomplish this, you haveset the external code to Y for the ADMINDROP rule. You have also included asingle, active drop code (DC for Drop Course) on the Schedule Processing RulesForm (SSARULE) and the Course Registration Status Form (SFARSTS) for twospecific sections, but you have not defined an active drop code for another specificsection.New Rules on GTVSDAXTwo new rules are used on the Crosswalk Validation Form (GTVSDAX) with theimproved drop/withdrawal processing. These rules are delivered via scripts.AUTODROPThe AUTODROP rule is used to determine whether connected courses that are inerror can be dropped using Self-Service or Voice Response.January 2005 Student Release 7.0Confidential Release Guide 193

Section 6 Improved Drop/Withdrawal Processing (Defect 49132) - FunctionalOverviewExternal Code Internal Code Internal CodeSequence NumberInternal Code Group Description Activity DateC AUTODROP N/A REGISTRATION Drop connectedcoursesSysdateThis rule can be set to process the dropping of connected courses in three ways:• C (Confirm) - Automatic drops are allowed for connected courses, after input isreceived from the user. This is the default value.• Y (Yes) - Automatic drops are allowed for connected courses. A single, activedrop code must exist for all connected courses that would be dropped. Noinput is needed from the user.• N (No) - No automatic drops are allowed for connected courses. The user mustinitiate dropping the connected courses. All connected courses must bedropped at the same time.Note: In Voice Response, error checking is performed on each CRN as it isentered. Because of this, if you enter N for the AUTODROP rule, it willnot be possible for connected courses to be dropped. Therefore, SCTrecommends that you use either C or Y for the AUTODROP rule.If multiple drop codes exist or no drop codes exist, no connected course drops areallowed to occur.ADMINDROPThe ADMINDROP rule is used to drop courses where schedule or restrictionchanges have occurred after enrollment exists or where in-progress pre-requisiteshave failed.External Code Internal Code Internal CodeSequence NumberInternal Code Group Description Activity DateY ADMINDROP N/A REGISTRATION Drop courses in adminerrorSysdateThis rule can be set to process the dropping of courses in two ways:• Y (Yes) - Courses with administrative errors are allowed to be dropped if a single,active drop code is available for the section or the part-of-term. This is thedefault value.• N (No) - Courses that have administrative errors are not dropped. Run theRegistration Admin Messages Report (SFRRGAM) to see errors in the student’sschedule. Registration leaves the courses with administrative errors in theirregistered status on the schedule.Student Release 7.0 January 2005194 Release Guide Confidential

Section 6 Improved Drop/Withdrawal Processing (Defect 49132) - FunctionalChanged FormsYou can run the SFRRGAM report to review any errors in the student’s scheduleregardless of how the ADMINDROP rule is set up.The Registration Administrative Message Temporary Table (SFTRGAM) stores theerror messages that result from the use of the ADMINDROP rule to drop coursesduring the registration session.Changed FormsProcess Control Code Validation Form (STVPROC)Two new codes are being delivered via scripts for use with this form. These codes aresystem required.• DISPLAYHOLDS - Display Student HoldsThis code is used by Faculty and Advisors Self-Service and is affected by therules that are set up for the advisor types or faculty attributes on SOAFAPC.• DISPLAYTESTS - Display Test ScoresThis code is used by Faculty and Advisors Self-Service and is affected by therules that are set up for the advisor types or faculty attributes on SOAFAPC.For more information about how these codes are used with hold and test scoreprocessing in Faculty and Advisors Self-Service, please refer to the Faculty andAdvisors Self-Service Release Guide.Course Registration Status Code Validation Form (STVRSTS)The VR (Status Type for Voice Response) field has been renamed the Type (StatusType) field.Note: The Type (Status Type) field must be filled in for every status code that isin use. If the Type (Status Type) field is left blank, unexpected results canoccur.This field is used to assign a status type to describe the course registration status codefor baseline, self-service, or telephone applications. Valid values are R (Registered),D (Dropped), L (Waitlisted), W (Withdrawn).Self-Service registration now uses both the Type (Status Type) and the courseregistration status code for the student's course and does not allow like codes to bedisplayed in the action pulldown list. This field must be populated or unexpectedresults may occur.January 2005 Student Release 7.0Confidential Release Guide 195

Section 6 Improved Drop/Withdrawal Processing (Defect 49132) - FunctionalChanged FormsFor more information about how status type processing is used in Student Self-Service and Faculty and Advisors Self-Service, please refer to the Student Self-ServiceRelease Guide and the Faculty and Advisors Self-Service Release Guide.Section Registration Status Codes Form (SSARULE)The VR (Status Type for Voice Response) field has been renamed the Type (StatusType) field.This field is used to assign a status type to describe the course registration status codefor baseline, self-service, or telephone applications. Valid values are R (Registered),D (Dropped), L (Waitlisted), W (Withdrawn).This field is display only and represents the value defined for the status code inSTVRSTS.Student Course Registration Form (SFAREGS)The Type (Status Type) field has been added to the Registration Information block.This field is used to assign a status type to describe the course registration status codefor baseline, self-service, or telephone applications. Valid values are R (Registered),D (Dropped), L (Waitlisted), W (Withdrawn).This field is display only and represents the value defined for the status code inSTVRSTS.Student Course Registration Audit Form (SFASTCA)A new field has been added to indicate which registration table generated the auditrecord displayed on SFASTCA.The Source field has values of either TEMP or BASE. TEMP denotes the record wasgenerated by the SFTREGS table triggers. BASE denotes the record was generatedby the SFRSTCR table triggers.Web Display List Customization Form (SOAWDSP)A new validation table choice has been added to the form. You can now enterSTVTESC in the Validation Table Name field or select it from the internal WebDisplay Validation Tables List (STVVTAB). This allows test scores to display on theWeb in Faculty and Advisors Self-Service.Student Release 7.0 January 2005196 Release Guide Confidential

Section 6 Improved Drop/Withdrawal Processing (Defect 49132) - FunctionalNew ReportNew ReportRegistration Admin Messages Report (SFRRGAM)This report is used to track registration errors for administrative purposes, check forin-progress pre-requisites errors, and view any potential schedule conflicts due tochanges in class schedule. You can use the error checking settings for registrationrestrictions on SOATERM when the report is run, or you can define the errorchecking settings using the individual report parameters.This report reruns the edit checking based on the settings entered by the user.These errors are not stored anywhere in the database, as this information canchange constantly.If a single term is entered in the Term Code parameter, both of the date parameters(Start Date From Date and Start Date To Date) will be set to NULL for the runningof the report, even if valid dates have been entered in these two parameters. Thecontrol report will display NULL for these two fields, even though they contain theuser-entered values in Banner job submission (GJAPCTL).If a date range is used for the report (i.e., the Term Code parameter is set to %),the Use SOATERM Error Check Flags parameter will be set to N for this running ofthe report, even though it may have been set to Y on GJAPCTL. The field value willbe displayed on the control report as N, indicating that the SOATERM errorchecking values were not used for this specific running of the report. The valuesthat exist on GJAPCTL for all the error checking parameters will be used for thisspecific running of the report, and they will be displayed on the control report.January 2005 Student Release 7.0Confidential Release Guide 197

Section 6 Improved Drop/Withdrawal Processing (Defect 49132) - FunctionalNew ReportThis page intentionally left blankStudent Release 7.0 January 2005198 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalCurricula Checking and APIsSection 7Concurrent Curricula Phase 1 - TechnicalThis enhancement is new for Release 7.0.Curricula Checking and APIsThe curriculum and field of study APIs are used to validate the curriculumaccording to the rules on SOACURR. An in and out parameter exists on thecurriculum and field of study p_create APIs to override any raised failure and toreturn the severity level so the user interface can manage the message if necessary.• If the override is blank, the API will abort if there is a fatal curriculum error,and the API error message handler will display the error.• If the override has a value of S (Suppress Error), the API will not fail but alsowill not insert the data.• If the override value has a value of N (No Curriculum Checking), the API willnot fail, and it will insert the data.In all cases, the real severity level and error number are returned so the userinterface can display any messages.The following is a list of places where the curriculum data is checked and the typeof error interaction that occurs as a result. If the API is allowed to fail, the object willdisplay a standard Banner API error message window with the error.Object Banner Activity Curriculum Checking API OverrideIndicatorSRARECRInsert new Recruitingcurriculum dataAllow API failure if the curriculum is in errorand the Recruiting severity level is F. Userinterface will display a warning if severity level isa warning, but API will not fail.NULLSRAQUIKInsert new Recruitingcurriculum dataAllow API failure if the curriculum is in errorand the Recruiting severity level is F. Userinterface will display a warning if severity level isa warning, but API will not fail.NULLSRKPRELCall sakmods. p_create_recruitDo not perform any curriculum checking. Callp_create_recruit with an override to anycurriculum checking and error reporting fromthe API.NJanuary 2005 Student Release 7.0Confidential Release Guide 199

Section 7 Concurrent Curricula Phase 1 - TechnicalCurricula Checking and APIsObject Banner Activity Curriculum Checking API OverrideIndicatorSRKPRELCall sakmods. p_create_applicationDo not perform any curriculum checking. Callp_create_application with an override to anycurriculum checking and error reporting fromthe API.NSAAADMSInsert new Admissionscurriculum dataAllow API failure if the curriculum is in errorand the Admissions severity level is F. Userinterface will display a warning if severity level isa warning, but API will not fail.NULLSAAQUIKInsert new Recruitingcurriculum dataAllow API failure if the curriculum is in errorand the Recruiting severity level is F. Userinterface will display a warning if severity level isa warning, but API will not fail.NULLSAAQUIKInsert new Admissionscurriculum dataAllow API failure if the curriculum is in errorand the Admissions severity level is F. Userinterface will display a warning if severity level isa warning, but API will not fail.NULLSAAQUIKInsert new Learnercurriculum dataAllow API failure if the curriculum is in errorand the Learner severity level is F. Userinterface will display a warning if severity level isa warning, but API will not fail.NULLSAADCBTInsert new Learner rowwhen student is admittedDisplay curriculum error in the message line forboth fatal and warning errors. If there is a fatalerror, abort the API, but not the remainingcommit processing.SSAADCBTDuplicate/changecurriculum and activitystatuses in Admissions, basedon new admissionapplication decision codesDo not perform any curriculum checking.NSAADCRVInsert new Learner rowwhen student is admittedAllow API failure if the curriculum is in errorand the Learner severity level is F. Userinterface will display a warning if severity level isa warning, but API will not fail.NULLSAADCRVDuplicate/changecurriculum and activitystatuses in Admissions, basedon new admissionapplication decision codesDo not perform any curriculum checking.NStudent Release 7.0 January 2005200 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalCurricula Checking and APIsObject Banner Activity Curriculum Checking API OverrideIndicatorSARBDSNSARBDSNCall sakmods. p_create_studentDuplicate active learnercurriculum and field ofstudy, and apply newcurriculum status andactivity status, if the studentstatus code has differentcodes then those current onSORLCUR and SORLFOSDo not perform any curriculum checking.Do not perform any curriculum checking.SAKMODS p_create_recruit Use IN parameter in p_create_recruit toindicate if API should abend if a fatalcurriculum error is found. Use OUT parameterin the procedure to return the first fatal errornumber found. If the user interface requiresthis should be processed, the error will exist andthe processing can be halted.SAKMODS p_create_application Use IN parameter in p_create_applicationto indicate if API should abend if a fatalcurriculum error is found. Use OUT parameterin the procedure to return the first fatal errornumber found. If the user interface requiresthis should be processed, the error will exist andthe processing can be halted.SAKMODS p_create_student Use IN parameter in p_create_student toindicate if API should abend if a fatalcurriculum error is found. Use OUT parameterin the procedure to return the first fatal errornumber found. If the user interface requiresthis should be processed, the error will exist andthe processing can be halted.Callingprocess sendsappropriatevalueCallingprocess sendsappropriatevalueCallingprocess sendsappropriatevalueSAKDCRVp_auto_decision callssakmods.p_create_studentDo not perform any curriculum checking. Callp_create_student with an override to anycurriculum checking and error reporting fromthe API.NSAKQADMCall sakmods.p_create_recruitDo not perform any curriculum checking. Callp_create_recruit with an override to anycurriculum checking and error reporting fromthe API.NJanuary 2005 Student Release 7.0Confidential Release Guide 201

Section 7 Concurrent Curricula Phase 1 - TechnicalCurricula Checking and APIsObject Banner Activity Curriculum Checking API OverrideIndicatorSAKL010Call sakmods. p_create_applicationDo not perform any curriculum checking. Callp_create_application with an override to anycurriculum checking and error reporting fromthe API.NSGASTDNInsert new Learnercurriculum dataAllow API failure if the curriculum is in errorand the Learner severity level is F. Userinterface will display a warning if severity level isa warning, but API will not fail.NULLSHADEGRInsert new Outcomecurriculum dataAllow API failure if the curriculum is in errorand the Outcome severity level is F. Userinterface will display a warning if severity level isa warning, but API will not fail.NULLSHADEGRDuplicate active curriculumand field of study data andapply new curriculum andactivity statuses if the degreestatus code is changed onSHRDGMRDo not perform any curriculum checking.NSHRDEGSUpdate or insert learnerwith new student status. Goto duplicate activecurriculum and field of studyand apply new curriculumstatus and activity status, ifthey are different fromprevious versions.Do not perform any curriculum checking.NSHRDEGSUpdate outcome with newdegree status code. Go toduplicate active curriculumand field of study and applynew curriculum status andactivity status, if they aredifferent from previousversions.Do not perform any curriculum checking.NSHKMODSInsert outcome (degree)and curriculumDo not perform any curriculum checking.NStudent Release 7.0 January 2005202 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalNew TablesNew TablesLearner Field of Study Type Validation Table (GTVLFST)This table is used to house the field of study code information for entries attachedto the curriculum base.GTVLFST_CODEGTVLFST_DESCGTVLFST_SYS_REQ_INDGTVLFST_USER_IDGTVLFST_ACTIVITY_DATENOT NULL VARCHAR2(15)NOT NULL VARCHAR2(30)NOT NULL VARCHAR2(1)NOT NULL VARCHAR2(30)NOT NULL DATELearner Curriculum Activity Status Table (STVCACT)This table is used to house the curriculum activity status codes.STVCACT_CODESTVCACT_DESCSTVCACT_USER_IDSTVCACT_ACTIVITY_DATENOT NULL VARCHAR2(15)NOT NULL VARCHAR2(30)NOT NULL VARCHAR2(30)NOT NULL DATECurriculum Status Validation Table (STVCSTS)This table is used to house the curriculum status codes.STVCSTS_CODESTVCSTS_DESCSTVCSTS_USER_IDSTVCSTS_ACTIVITY_DATESTVCSTS_SYS_REQ_INDNOT NULL VARCHAR2(15)NOT NULL VARCHAR2(30)NOT NULL VARCHAR2(30)NOT NULL DATENOT NULL VARCHAR2(1)Learner Module Validation Table (STVLMOD)This table is used to house the modules codes used for curriculum processing.STVLMOD_CODESTVLMOD_DESCSTVLMOD_ACTIVITY_DATESTVLMOD_USER_IDNOT NULL VARCHAR2(15)NOT NULL VARCHAR2(30)NOT NULL DATENOT NULL VARCHAR2(30)Curriculum Activity Status Rules Table (SOBCACT)This rules table is used to house curriculum status code information, such as whichcodes are active.January 2005 Student Release 7.0Confidential Release Guide 203

Section 7 Concurrent Curricula Phase 1 - TechnicalNew TablesSOBCACT_CACT_CODESOBCACT_ACTIVE_INDSOBCACT_SYS_REQ_INDSOBCACT_USER_IDSOBCACT_ACTIVITY_DATENOT NULL VARCHAR2(15)NOT NULL VARCHAR2(1)NOT NULL VARCHAR2(1)NOT NULL VARCHAR2(30)NOT NULL DATELearner Curriculum Frequency Rules Table (SOBLMOD)This table is used to store the number of curricula, majors, minors, andconcentrations by module (RECRUIT, ADMISSSIONS, LEARNER, OUTCOME)that are allowed to be entered.You can update the values in this table, but the Bridge API will still only backfill withthe delivered maximum values.The row level logic on the SORLCUR and SORLFOS tables will restrict the numberof active rows to the values defined in the SOBLMOD table, which can be accessedthrough the SOACTRL form.SOBLMOD_LMOD_CODESOBLMOD_SYS_REQ_INDSOBLMOD_MAX_CURRICULASOBLMOD_MAX_MAJORSSOBLMOD_MAX_MINORSSOBLMOD_MAX_CONCENTRATIONSSOBLMOD_USER_IDSOBLMOD_ACTIVITY_DATENOT NULL VARCHAR2(15)NOT NULL VARCHAR2(1)NOT NULL NUMBER(8)NOT NULL NUMBER(8)NOT NULL NUMBER(8)NOT NULL NUMBER(8)NOT NULL VARCHAR2(30)NOT NULL DATELearner Curricula Table (SORLCUR)This table is used to house the base curriculum information for the learner.The term code may have a different meaning for each of the modules. The term forthe recruit is the term code of interest, whereas the term for the application is theterm of entry. On the general student record the term is the effective term.The KEY_SEQNO number will always be populated with a value of 99 for a generalstudent record. Otherwise, it will be populated with the module's sequence number(i.e., SRBRECR_ADMIN_SEQNO, SARADAP_APPL_NO, or SHRDGMR_SEQNO).The number of active rows is validated against the SOBLMOD_MAX_CURRICULA fieldfor the PIDM, term, key sequence number and learner module. The student cannothave more than that number of active rows at one time.Student Release 7.0 January 2005204 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalNew TablesSORLCUR_PIDMNOT NULL NUMBER(8)SORLCUR_SEQNONOT NULL NUMBER(4)SORLCUR_LMOD_CODENOT NULL VARCHAR2(15)SORLCUR_TERM_CODENOT NULL VARCHAR2(6)SORLCUR_KEY_SEQNONOT NULL NUMBER(2)SORLCUR_PRIORITY_NONOT NULL NUMBER(4)SORLCUR_ROLL_INDNOT NULL VARCHAR2(1)SORLCUR_CACT_CODENOT NULL VARCHAR2(15)SORLCUR_USER_IDNOT NULL VARCHAR2(30)SORLCUR_DATA_ORGINNOT NULL VARCHAR2(30)SORLCUR_ACTIVITY_DATENOT NULL DATESORLCUR_LEVL_CODENOT NULL VARCHAR2(2)SORLCUR_COLL_CODENOT NULL VARCHAR2(2)SORLCUR_DEGC_CODENOT NULL VARCHAR2(6)SORLCUR_TERM_CODE_CTLGNOT NULL VARCHAR2(6)SORLCUR_TERM_CODE_ENDVARCHAR2(6)SORLCUR_TERM_CODE_MATRICVARCHAR2(6)SORLCUR_TERM_CODE_ADMITVARCHAR2(6)SORLCUR_ADMT_CODEVARCHAR2(2)SORLCUR_CAMP_CODEVARCHAR2(3)SORLCUR_PROGRAMVARCHAR2(12)SORLCUR_START_DATEDATESORLCUR_END_DATEDATESORLCUR_CURR_RULENUMBER(8)SORLCUR_ROLLED_SEQNO NUMBER(4)Field of Study Table (SORFLOS)This table is used to maintain the field of study rule that is attached to thecurriculum rule.The number of active rows for the PIDM, term, key sequence number, learnermodule code, and learner field of study code is validated against theSOBLMOD_MAX_MAJORS, SOBLMOD_MAX_MINORS, andSOBLMOD_MAX_CONCENTRATIONS fields for the learner module code fields for eachfield of study type. The student cannot have more than that number of active rowsat one time for the term and key sequence number. The key sequence number valuewill always be 99 for general student records.The SORLFOS_LFOS_RULE is populated with the SORCMJR_RULE, SORCMNR_RULE, orSORCCMN_RULE value, depending on the value of the LFOS_CODE field. The learnerfield of study code (LFOS_CODE) indicates if the row is a major, minor, orconcentration. The SORLFOS_CMJR_RULE_CCON_ATTACH field is populated with theSORCMJR_RULE value of the major associated with this attached concentration. Ifcurriculum rules are not used, the SORLFOS_MAJR_CODE_ATTACH field is populatedwith the code of the major to which the concentration is attached.January 2005 Student Release 7.0Confidential Release Guide 205

Section 7 Concurrent Curricula Phase 1 - TechnicalChanged TablesSORLFOS_PIDMSORLFOS_LCUR_SEQNOSORLFOS_SEQNOSORLFOS_LFST_CODESORLFOS_TERM_CODESORLFOS_PRIORITY_NOSORLFOS_CSTS_CODESORLFOS_CACT_CODESORLFOS_DATA_ORGINSORLFOS_USER_IDSORLFOS_ACTIVITY_DATESORLFOS_MAJR_CODESORLFOS_TERM_CODE_CTLGSORLFOS_TERM_CODE_ENDSORLFOS_DEPT_CODESORLFOS_LFOS_RULESORLFOS_CONC_ATTACH_RULESORLFOS_START_DATESORLFOS_END_DATESORLFOS_TMST_CODESORLFOS_ROLLED_SEQNOSORLFOS_MAJR_CODE_ATTACHNOT NULL NUMBER(8)NOT NULL NUMBER(4)NOT NULL NUMBER(4)NOT NULL VARCHAR2(4)(= MAJOR, MINOR, CONCENTRATION)NOT NULL VARCHAR2(6)NOT NULL NUMBER(4)NOT NULL VARCHAR2(15)NOT NULL VARCHAR2(15)NOT NULL VARCHAR2(30)NOT NULL VARCHAR2(30)NOT NULL DATENOT NULL VARCHAR2(4)(= BIOL, ART, etc.)NOT NULL VARCHAR2(6)VARCHAR2(6)VARCHAR2(4)NUMBER(8)NUMBER(8)(if not null, = rule of major to whichconcentration is attached)DATEDATEVARCHAR2(2)NUMBER(4)VARCHAR2(4)Changed TablesAdmission Application Decision Code Validation Table (STVAPDC)The following fields have been added to the table.STVAPDC_CSTS_CODESTVAPDC_CACT_CODEVARCHAR2(15)VARCHAR2(15)Note: The STVAPDC_CACT_CODE field is not used at this time.Degree Status Code Validation Table (STVDEGS)The following fields have been added to the table.STVDEGS_CSTS_CODESTVDEGS_CACT_CODEVARCHAR2(15)VARCHAR2(15)Note: The STVDEGS_CACT_CODE field is not used at this time.Student Release 7.0 January 2005206 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalChanged TablesStudent Status Code Validation Table (STVSTST)The following fields have been added to the table.STVSTST_CSTS_CODESTVSTST_CACT_CODEVARCHAR2(15)VARCHAR2(15)Note: The STVSTST_CACT_CODE field is not used at this time.Recruiting Base Table (SRBRECR)The following fields have been added to the table.SRBRECR_DATA_ORIGINSRBRECR_USER_IDVARCHAR2(30)VARCHAR2(30)The following curriculum fields have been modified so they are nullable. This is toaccommodate that curriculum values are now stored in the new SORLCUR andSORLFOS tables, and that they will no longer be stored in these tables due tochanges to be delivered in a future Banner 7.X release.SRBRECR_LEVL_CODESRBRECR_DEGC_CODESRBRECR_MAJR_CODEVARCHAR2(2)VARCHAR2(6)VARCHAR2(4)The following fields are now maintained with data entered in SORLCUR andSORLFOS. The curriculum commit processing calls the procedure that updates thecurriculum columns on SRBRECR. (See the new procedure p_backload_curr andthe new triggers post_forms_commit_trg.)SRBRECR_DEPT_CODESRBRECR_LEVL_CODESRBRECR_DEGC_CODESRBRECR_MAJR_CODESRBRECR_ADMT_CODESRBRECR_CAMP_CODESRBRECR_COLL_CODESRBRECR_MAJR_CODE2SRBRECR_PROGRAM_1SRBRECR_TERM_CODE_CTLG_1SRBRECR_DEPT_CODE_2SRBRECR_MAJR_CODE_CONC_111SRBRECR_MAJR_CODE_CONC_112SRBRECR_MAJR_CODE_CONC_113SRBRECR_MAJR_CODE_CONC_121SRBRECR_MAJR_CODE_CONC_122SRBRECR_MAJR_CODE_CONC_123SRBRECR_MAJR_CODE_MINR_1SRBRECR_MAJR_CODE_MINR_1_2SRBRECR_CURR_RULE_1SRBRECR_CMJR_RULE_1_1SRBRECR_CCON_RULE_11_1SRBRECR_CCON_RULE_11_2VARCHAR2(4)VARCHAR2(2)VARCHAR2(6)VARCHAR2(4)VARCHAR2(2)VARCHAR2(3)VARCHAR2(2)VARCHAR2(4)VARCHAR2(12)VARCHAR2(6)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)January 2005 Student Release 7.0Confidential Release Guide 207

Section 7 Concurrent Curricula Phase 1 - TechnicalChanged TablesSRBRECR_CCON_RULE_11_3SRBRECR_CMJR_RULE_1_2SRBRECR_CCON_RULE_12_1SRBRECR_CCON_RULE_12_2SRBRECR_CCON_RULE_12_3SRBRECR_CMNR_RULE_1_1SRBRECR_CMNR_RULE_1_2NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)Admissions Application Repeating Table (SARADAP)The following fields have been added to the table.SARADAP_DATA_ORIGINSARADAP_USER_IDVARCHAR2(30)VARCHAR2(30)The following curriculum fields have been modified so they are nullable. This is toaccommodate that curriculum values are now stored in the new SORLCUR andSORLFOS tables, and that they will no longer be stored in these tables due tochanges to be delivered in a future Banner 7.X release.SARADAP_LEVL_CODEVARCHAR2(2)SARADAP_COLL_CODE_1 VARCHAR2(2)SARADAP_DEGC_CODE_1 VARCHAR2(6)SARADAP_MAJR_CODE_1 VARCHAR2(4)The following fields are now maintained with data entered in SORLCUR andSORLFOS. The curriculum commit processing calls the procedure that updates thecurriculum columns on SARADAP. (See the new procedure p_backload_curr andthe new triggers post_forms_commit_trg.)SARADAP_LEVL_CODESARADAP_CAMP_CODESARADAP_COLL_CODE_1SARADAP_DEGC_CODE_1SARADAP_MAJR_CODE_1SARADAP_COLL_CODE_2SARADAP_DEGC_CODE_2SARADAP_MAJR_CODE_2SARADAP_MAJR_CODE_CONC_1SARADAP_DEPT_CODESARADAP_DEPT_CODE_2SARADAP_MAJR_CODE_CONC_2SARADAP_PROGRAM_1SARADAP_TERM_CODE_CTLG_1SARADAP_MAJR_CODE_1_2SARADAP_DEPT_CODE_1_2SARADAP_MAJR_CODE_CONC_1_2SARADAP_MAJR_CODE_CONC_1_3SARADAP_MAJR_CODE_CONC_121SARADAP_MAJR_CODE_CONC_122SARADAP_MAJR_CODE_CONC_123SARADAP_MAJR_CODE_MINR_1_1SARADAP_MAJR_CODE_MINR_1_2SARADAP_PROGRAM_2SARADAP_TERM_CODE_CTLG_2VARCHAR2(2)VARCHAR2(3)VARCHAR2(2)VARCHAR2(6)VARCHAR2(4)VARCHAR2(2)VARCHAR2(6)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(12)VARCHAR2(6)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(12)VARCHAR2(6)Student Release 7.0 January 2005208 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalChanged TablesSARADAP_LEVL_CODE_2SARADAP_CAMP_CODE_2SARADAP_MAJR_CODE_2_2SARADAP_DEPT_CODE_2_2SARADAP_MAJR_CODE_CONC_211SARADAP_MAJR_CODE_CONC_212SARADAP_MAJR_CODE_CONC_213SARADAP_MAJR_CODE_CONC_221SARADAP_MAJR_CODE_CONC_222SARADAP_MAJR_CODE_CONC_223SARADAP_MAJR_CODE_MINR_2_1SARADAP_MAJR_CODE_MINR_2_2SARADAP_CURR_RULE_1SARADAP_CMJR_RULE_1_1SARADAP_CCON_RULE_11_1SARADAP_CCON_RULE_11_2SARADAP_CCON_RULE_11_3SARADAP_CMJR_RULE_1_2SARADAP_CCON_RULE_12_1SARADAP_CCON_RULE_12_2SARADAP_CCON_RULE_12_3SARADAP_CMNR_RULE_1_1SARADAP_CMNR_RULE_1_2SARADAP_CURR_RULE_2SARADAP_CMJR_RULE_2_1SARADAP_CCON_RULE_21_1SARADAP_CCON_RULE_21_2SARADAP_CCON_RULE_21_3SARADAP_CMJR_RULE_2_2SARADAP_CCON_RULE_22_1SARADAP_CCON_RULE_22_2SARADAP_CCON_RULE_22_3SARADAP_CMNR_RULE_2_1SARADAP_CMNR_RULE_2_2VARCHAR2(2)VARCHAR2(3)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)Student Base Table (SGBSTDN)The following fields have been added to the table.SGBSTDN_DATA_ORIGINSGBSTDN_USER_IDVARCHAR2(30)VARCHAR2(30)The following curriculum fields have been modified so they are nullable. This is toaccommodate that curriculum values are now stored in the new SORLCUR andSORLFOS tables, and that they will no longer be stored in these tables due tochanges to be delivered in a future Banner 7.X release.SGBSTDN_LEVL_CODESGBSTDN_COLL_CODE_1SGBSTDN_DEGC_CODE_1SGBSTDN_MAJR_CODE_1SGBSTDN_PRIM_ROLL_INDSGBSTDN_SECD_ROLL_INDVARCHAR2(2)VARCHAR2(2)VARCHAR2(6)VARCHAR2(4)VARCHAR2(1)VARCHAR2(1)January 2005 Student Release 7.0Confidential Release Guide 209

Section 7 Concurrent Curricula Phase 1 - TechnicalChanged TablesThe following fields are now maintained with data entered in SORLCUR andSORLFOS. The curriculum commit processing calls the procedure that updates thecurriculum columns on SGBSTDN. (See the new procedure p_backload_curr andthe new triggers post_forms_commit_trg.)SGBSTDN_LEVL_CODESGBSTDN_TERM_CODE_MATRICSGBSTDN_TERM_CODE_ADMITSGBSTDN_CAMP_CODESGBSTDN_COLL_CODE_1SGBSTDN_DEGC_CODE_1SGBSTDN_MAJR_CODE_1SGBSTDN_MAJR_CODE_MINR_1SGBSTDN_MAJR_CODE_MINR_1_2SGBSTDN_MAJR_CODE_CONC_1SGBSTDN_MAJR_CODE_CONC_1_2SGBSTDN_MAJR_CODE_CONC_1_3SGBSTDN_COLL_CODE_2SGBSTDN_DEGC_CODE_2SGBSTDN_MAJR_CODE_2SGBSTDN_MAJR_CODE_MINR_2SGBSTDN_MAJR_CODE_MINR_2_2SGBSTDN_MAJR_CODE_CONC_2SGBSTDN_MAJR_CODE_CONC_2_2SGBSTDN_MAJR_CODE_CONC_2_3SGBSTDN_MAJR_CODE_1_2SGBSTDN_MAJR_CODE_2_2SGBSTDN_DEPT_CODESGBSTDN_SITE_CODESGBSTDN_DEPT_CODE_2SGBSTDN_MAJR_CODE_DUALSGBSTDN_PRIM_ROLL_INDSGBSTDN_PROGRAM_1SGBSTDN_TERM_CODE_CTLG_1SGBSTDN_DEPT_CODE_1_2SGBSTDN_MAJR_CODE_CONC_121SGBSTDN_MAJR_CODE_CONC_122SGBSTDN_MAJR_CODE_CONC_123SGBSTDN_SECD_ROLL_INDSGBSTDN_TERM_CODE_ADMIT_2SGBSTDN_ADMT_CODE_2SGBSTDN_PROGRAM_2SGBSTDN_TERM_CODE_CTLG_2SGBSTDN_LEVL_CODE_2SGBSTDN_CAMP_CODE_2SGBSTDN_DEPT_CODE_2_2SGBSTDN_MAJR_CODE_CONC_221SGBSTDN_MAJR_CODE_CONC_222SGBSTDN_MAJR_CODE_CONC_223SGBSTDN_CURR_RULE_1SGBSTDN_CMJR_RULE_1_1SGBSTDN_CCON_RULE_11_1SGBSTDN_CCON_RULE_11_2SGBSTDN_CCON_RULE_11_3SGBSTDN_CMJR_RULE_1_2SGBSTDN_CCON_RULE_12_1SGBSTDN_CCON_RULE_12_2SGBSTDN_CCON_RULE_12_3VARCHAR2(2)VARCHAR2(6)VARCHAR2(6)VARCHAR2(3)VARCHAR2(2)VARCHAR2(6)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(2)VARCHAR2(6)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(3)VARCHAR2(4)VARCHAR2(4)VARCHAR2(1)VARCHAR2(12)VARCHAR2(6)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(1)VARCHAR2(6)VARCHAR2(2)VARCHAR2(12)VARCHAR2(6)VARCHAR2(2)VARCHAR2(3)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)Student Release 7.0 January 2005210 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalChanged TablesSGBSTDN_CMNR_RULE_1_1SGBSTDN_CMNR_RULE_1_2SGBSTDN_CURR_RULE_2SGBSTDN_CMJR_RULE_2_1SGBSTDN_CCON_RULE_21_1SGBSTDN_CCON_RULE_21_2SGBSTDN_CCON_RULE_21_3SGBSTDN_CMJR_RULE_2_2SGBSTDN_CCON_RULE_22_1SGBSTDN_CCON_RULE_22_2SGBSTDN_CCON_RULE_22_3SGBSTDN_CMNR_RULE_2_1SGBSTDN_CMNR_RULE_2_2NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)Degree Table (SHRDGMR)The following fields have been added to the table.SHRDGMR_DATA_ORIGINSHRDGMR_USER_IDVARCHAR2(30)VARCHAR2(30)The following curriculum fields have been modified so they are nullable. This is toaccommodate that curriculum values are now stored in the new SORLCUR andSORLFOS tables, and that they will no longer be stored in these tables due tochanges to be delivered in a future Banner 7.X release.SHRDGMR_DEGC_CODESHRDGMR_LEVL_CODESHRDGMR_COLL_CODE_1SHRDGMR_MAJR_CODE_1VARCHAR2(6)VARCHAR2(2)VARCHAR2(2)VARCHAR2(4)The following fields are now maintained with data entered in SORLCUR andSORLFOS. The curriculum commit processing calls the procedure that updates thecurriculum columns on SHRDGMR. (See the new procedure p_backload_currand the new triggers post_forms_commit_trg.)SHRDGMR_DEGC_CODESHRDGMR_LEVL_CODESHRDGMR_COLL_CODE_1SHRDGMR_MAJR_CODE_1SHRDGMR_MAJR_CODE_MINR_1SHRDGMR_MAJR_CODE_CONC_1SHRDGMR_MAJR_CODE_MINR_1_2SHRDGMR_MAJR_CODE_CONC_1_2SHRDGMR_MAJR_CODE_CONC_1_3SHRDGMR_MAJR_CODE_MINR_2_2SHRDGMR_MAJR_CODE_CONC_2_2SHRDGMR_MAJR_CODE_CONC_2_3SHRDGMR_COLL_CODE_2SHRDGMR_MAJR_CODE_2SHRDGMR_MAJR_CODE_MINR_2SHRDGMR_MAJR_CODE_CONC_2SHRDGMR_DEPT_CODESHRDGMR_DEPT_CODE_2SHRDGMR_MAJR_CODE_1_2VARCHAR2(6)VARCHAR2(2)VARCHAR2(2)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(2)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)January 2005 Student Release 7.0Confidential Release Guide 211

Section 7 Concurrent Curricula Phase 1 - TechnicalNew PackageSHRDGMR_MAJR_CODE_2_2SHRDGMR_PROGRAMSHRDGMR_TERM_CODE_CTLG_1SHRDGMR_DEPT_CODE_1_2SHRDGMR_DEPT_CODE_2_2SHRDGMR_MAJR_CODE_CONC_121SHRDGMR_MAJR_CODE_CONC_122SHRDGMR_MAJR_CODE_CONC_123SHRDGMR_TERM_CODE_CTLG_2SHRDGMR_CAMP_CODE_2SHRDGMR_MAJR_CODE_CONC_221SHRDGMR_MAJR_CODE_CONC_222SHRDGMR_MAJR_CODE_CONC_223SHRDGMR_CURR_RULE_1SHRDGMR_CMJR_RULE_1_1SHRDGMR_CCON_RULE_11_1SHRDGMR_CCON_RULE_11_2SHRDGMR_CCON_RULE_11_3SHRDGMR_CMJR_RULE_1_2SHRDGMR_CCON_RULE_12_1SHRDGMR_CCON_RULE_12_2SHRDGMR_CCON_RULE_12_3SHRDGMR_CMNR_RULE_1_1SHRDGMR_CMNR_RULE_1_2SHRDGMR_CURR_RULE_2SHRDGMR_CMJR_RULE_2_1SHRDGMR_CCON_RULE_21_1SHRDGMR_CCON_RULE_21_2SHRDGMR_CCON_RULE_21_3SHRDGMR_CMJR_RULE_2_2SHRDGMR_CCON_RULE_22_1SHRDGMR_CCON_RULE_22_2SHRDGMR_CCON_RULE_22_3SHRDGMR_CMNR_RULE_2_1SHRDGMR_CMNR_RULE_2_2VARCHAR2(4)VARCHAR2(12)VARCHAR2(6)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)VARCHAR2(6)VARCHAR2(3)VARCHAR2(4)VARCHAR2(4)VARCHAR2(4)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)NUMBER(8)New PackageSOKLCURThis new package is used to query curriculum data. The following functions arecontained in this package.Student Release 7.0 January 2005212 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalNew PackageFunctionf_current_lfosf_current_lcurf_count_lfosf_count_lcurf_lfos_rowidf_lcur_rowidf_convert_recruitf_convert_applicantf_convert_learnerf_convert_outcomef_validate_degs_cstsf_find_rolled_degreeDescriptionThis function will return a Y or N if the SORLFOS rowis the active one for the priority.This function will return a Y or N if the SORLCUR rowis the active one for the priority.This function will return a Y or N for the check that thefield of study can be entered based on the counts onSOBLMOD.This function will return a Y or N for the check that thecurriculum can be entered based on the counts onSOBLMOD.This function returns the major, minor, orconcentration for a priority.This function calls the P_LCUR_PRIORITY but returnsback just the ROWID.This reads all SRBRECR records for a PIDM andconverts the curricula data to SORLCUR andSORLFOS This calls p_convert_curr.This reads all SARADAP records for a PIDM andconverts the curricula data to SORLCUR andSORLFOS. This calls p_convert_curr.This reads all SGBSTDN records for a PIDM andconverts the curricula data to SORLCUR andSORLFOS This calls p_convert_curr.This reads all SHRDGMR records for a PIDM andconverts the curricula data to SORLCUR andSORLFOS This calls p_convert_curr.This validates the curriculum status (CSTS) value ondegree records. Degrees cannot be awarded if thedegree status is not set to awarded.This finds previously rolled degree records with thesame priority, college, and level and is used in thegrade roll process to create new SHRDGMR rows.January 2005 Student Release 7.0Confidential Release Guide 213

Section 7 Concurrent Curricula Phase 1 - TechnicalNew PackageThe following procedures are contained in this package.Procedurep_lcur_priorityp_lfos_priorityp_backload_datap_convert_currp_default_statusp_push_decision_curriculump_push_degree_curriculump_push_recruit_curriculumDescriptionThis procedure returns the curriculum for a priority.This procedure returns the field of study for a priority.This procedure updates the primary and secondarycurricula on a student record. It calls the module’sDML to update the curriculum columns in the originalcolumns.This procedure converts data on SRBRECR, SARADAP,SGBSTDN, and SHRDGMR to the new tablesSORLCUR and SORLFOS.This procedure determines the curriculum activitystatus (CACT) and curriculum status (CSTS) codes tobe used when curricula are inserted.This procedure moves the application’s curium to thenew status based on the decision made. New rows arecreated only if the curriculum activity status (CACT)and curriculum status (CSTS) values on STVAPDC arefilled, or the decision is a rejection, institutionacceptance, or student acceptance.This procedure moves the degree curriculum to thenew status when the degree is awarded. New rows arecreated only if the degree is moved to an awardedstatus.This procedure moves the recruit curriculum toapplied when an application is created.p_learner_lcur_rolled This procedure is run from the outcome conversion. Itqueries the learner SORLCUR record to find a matchwith PIDM, level, degree, and program. It updates therolled sequence number with the newSHRDGMR_LCUR_SEQNO.p_learner_lfos_rolledp_create_sotvcurThis procedure is run from the outcome conversion. Itqueries the learner SORLFOS record to find a matchwith PIDM and major. It updates the rolled sequencenumber with the new SHRDGMR_LFOS_SEQNO.This procedure creates and/or updates the sessiontemporary record used in the SOVLCUR view.Student Release 7.0 January 2005214 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalNew PackageCurriculum Conversion Using FunctionsFour of the new functions delivered in package SOKLCUR (f_convert_recruit,f_convert_applicant, f_convert_learner, and f_convert_outcome) are usedto call the APIs to do the insert activity. The functions can be launched from a batchprocess or when the a form with curriculum data is initially opened at yourinstitution. This includes: SRARECR, SRAQUIK, SAAADMS, SAAQUIK, SGASTDN,SFAREGS, and SHADEGR. These forms will check to see if the curriculum data hasbeen converted, and if it has not, the function will be executed for the PIDM.The table below explains how the functions convert the curriculum data.Function Name Table Read Conversion Step API Task Data Convertedinto Tablef_convert_recruit SRBRECR Convert primarycurriculumf_convert_applicant SARADAP Convert primarycurriculumConvert secondarycurriculumf_convert_learner SGBSTDN Convert primarycurriculumConvert secondarycurriculumf_convert_outcome SHRDGMR Convert primarycurriculumInsert recruiting curriculumbaseInsert recruiting curriculumstudy entryInsert admissionscurriculum baseInsert admissionscurriculum study entryInsert admissionscurriculum baseInsert admissionscurriculum study entryInsert learner curriculumbaseInsert learner curriculumstudy entryInsert learner curriculumbaseInsert learner curriculumstudy entryInsert history curriculumbaseInsert history curriculumstudy entrySORLCURSORLFOSSORLCURSORLFOSSORLCURSORLFOSSORLCURSORLFOSSORLCURSORLFOSSORLCURSORLFOSJanuary 2005 Student Release 7.0Confidential Release Guide 215

Section 7 Concurrent Curricula Phase 1 - TechnicalChanged PackagesFunction Name Table Read Conversion Step API Task Data Convertedinto TableConvert secondarycurriculumInsert history curriculumbaseInsert history curriculumstudy entrySORLCURSORLFOSChanged PackagesSRKPRELThe p_insert_srbrecr procedure has been modified to call thesakmods.p_create_recruit procedure for curriculum processing.Parameters have been added to the sakmods.p_create_recruit andp_create_appliction for curriculum status (CSTS) and curriculum activity status(CACT) code values.SAKDCSNTwo arguments were added in p_auto_decision call tosakmods.p_create_student:• saradap_row.saradap_term_code_entry• saradap_row.saradap_appl_noA call was also added to p_push_decision_curriculum after the SARAPPD insertis completed.SAKL010The following changes have been made:• The p_saradap_insert procedure has been modified to callsb_admissions.p_create to create the application information, to read theSARETRY and SAREFOS to get the curriculum information, and to call thesb_curriculum.p_create and the sb_fieldofstudy.p_create for all thecurriculum data that is found.• The procedure p_saradap_update has been deleted, and the procedurep_create_secondary has been added.Student Release 7.0 January 2005216 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalChanged Packages• In procedure p_load_application_one, the call to p_saradap_update hasbeen replaced with a call to p_create_secondary to backfill data intoSARADAP from the SORLFOS rows.• The ltrim function has been added to chkl_comment with L999D99 in thecomment.SAKMODSThe following changes have been made:• The p_create_recruit, p_create_application, and p_create_studentprocedures have been modified to call the new APIs to insert the SRBRECR,SARADAP, and SGBSTDN data.• The p_insert_sarappd procedure has been modified to include theSORLCUR and SORLFOS conversion for the LEARNER and ADMISSIONSmodules.• The p_create_recruit procedure has been modified to use the newcurriculum processing when creating a recruiting record.• The p_create_student procedure has been modified to use the newcurriculum processing when creating a student record.• The p_create_application procedure has been modified to insertcurriculum data into the SORLCUR and SORLFOS tables.SAKQADMNew parameters have been added to p_create_recruit to include the curriculumactivity status (CACT) and curriculum status (CSTS) codes. These codes are set andthen passed in the package.Deletes from SARADAP have been changed to call the Admissions Delete API.SHKMODSThe p_insert_shrdgmr and p_update_shrdgmr procedures have been removed.These procedures were called from SHKROLS, which has been modified to call theSHRDGMR APIs.January 2005 Student Release 7.0Confidential Release Guide 217

Section 7 Concurrent Curricula Phase 1 - TechnicalChanged PackagesSHKROLSThe following changes have been made:• All old SGBSTDN curriculum columns have been removed from theroll_record type.• All SGBSTDN curriculum columns have been removed from the select inp_get_student_course.• In procedure p_process_graderoll, the logic was replaced around thedecision for whether the new SHRDGMR record is created by selecting thelearner SORLCUR record and finding active records that have a null rolledsequence.• A new procedure, p_process_fieldofstudy, has been added to roll thelearner fields of study to the outcome curricula.• The p_process_degree1, p_process_degree2, p_insert_degree1,p_insert_degree2, p_update_degree1, and p_update_degree2 procedureshave been removed.• The p_process_degree procedure has been modified to call just thep_insert_degree procedure.• The p_insert_degree now calls the SHRDGMR API.• The p_update_degree procedure now compares dual degree information tothe learner record and then calls the API to perform any updates.SOKCURRTwo new procedures have been added:• A new procedure, p_checklfos, has been added to consolidate curriculumchecking on majors, minors, and concentrations for the new curriculumSORLFOS table.This procedure combines the p_checkmajor, p_checkminor, andp_checkconcentrations into one procedure, so that the edits on SORLFOSonly have to call one procedure.P_checklfos is used for validating that the learner field of study is part of thecurriculum. This normally happens through the p_checkcurriculum, whenthe row (SRBRECR, SARADAP, SGBSTDN, or SHRDGMR) is committed. Thecurriculum is checked as a whole. Each LFOS is checked when the row isvalidated.• Another new procedure, p_conclfosattach, has also been added. Thisprocedure will send back a value of Y if there are concentrations attached tothe base curriculum or concentrations attached to any of the majors on thecurriculum.Student Release 7.0 January 2005218 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalChanged PackagesProcessingThe SOKCURR package has also been modified to process data as follows:• The input parameters for the curriculum checking procedures now includethe module (RECRUIT, ADMISSIONS, LEARNER, OUTCOME), SORLCURrule number, SORLCUR sequence number, and the specific item's sequencenumber. The routines will read the value using the SORLCUR sequencenumber and the SORLFOS sequence number, as well as the SORLFOS learnermodule code.• Curriculum data is inserted into the SORLCUR and SORLFOS tables and isdefaulted into the SOACURR curriculum rule. Lists of Values are built fromthe SOACURR rules and the entered curriculum.• Each curriculum row is validated individually. If any entry is invalid, theappropriate warning or fatal error is displayed. The curriculum validationprocesses are:• p_checkbase• p_checkmajor• p_checkminor• p_checkconc• If any part of the curriculum is missing that is required (such as the majorcode), the Curriculum Group Object window processing will enforce the entryof the required data when the record is saved.In a later release, the window processing will enforce whatever rules have beenset up for each curriculum for required and non-required data.SOKCMSGThis procedure is related to SOKCURR, and it returns the error message and thecolumn the error pertains to. For example, if the major is missing on SARADAP, thiswill return the column SARADAP_MAJR_CODE_1 with the appropriate error message.The new procedure p_sorlcurerroritem has been added and is used to find themissing item on the form after the p_verifydata procedure has been executed inthe CURRICULUM_COMMIT trigger.The new function f_sorlcurerrormsg has been added and works likef_curriculumerrormsg. SMARQCM still uses the f_curriculumerrormsgprocedure, f_sorlcurerrormsg is used for the new curriculum window. Thisprocedure returns the curriculum error message.January 2005 Student Release 7.0Confidential Release Guide 219

Section 7 Concurrent Curricula Phase 1 - TechnicalNew ProceduresNew Proceduresp_backload_currThis procedure in package SOKLCUR updates the primary and secondary curriculaon any of the student records (SRBRECR, SARADAP, SGASTDN, SHRDGMR).It calls the module's DML to update the curriculum columns in the original recordfrom the SORLCUR and SORLFOS columns. This is called from theCOMMIT_CURRICULUM form trigger. It is also called fromsakmods.p_create_application, sakmods.p_create_student,sakmods.p_create_recruit, and in shkmods.p_create_degree.p_convert_currThis procedure in package SOKLCUR converts data on the SRBRECR, SARADAP,SGBSTDN, and SHRDGMR tables to the new SORLCUR and SORLFOS tables.The logic in the procedure is as follows:1. Find if the input module record exists (SRBRECR, SARADAP, SGBSTDN, andSHRDGMR).2. Insert the primary and secondary curricula and their majors, minors, andconcentrations.p_push_recruit_curriculumThis procedure in package SOKLCUR is executed only under certain conditions,namely after an application is created from the recruit record. This is called inSAAADMS, SAAQUIK, and sokmods.p_create_application.This procedure determines if the application is a match to the recruit. If so, it willduplicate all of the recruiting records active for LCUR and LFOS and update thecodes to reflect the fact that the application has been created. The new curriculumstatus code is APPLIED, and the activity status code is ACTIVE.A match occurs if the new application has the same major, degree, level, and term.p_push_decision_curriculumThis procedure in package SOKLCUR determines which curriculum status andactivity status codes are used if a decision has been entered on an application. Thecurrent learner field of study and learner curriculum will be duplicated, and theStudent Release 7.0 January 2005220 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalChanged Procedurescurriculum status code selected, based on what has been entered on STVAPDC. Ifthe curriculum status code has not been entered on the STVAPDC row, the activitystatus code ACTIVE and the curriculum status code ACCEPTED will be used, but theyare only used if the decision results in the creation of a General Student record.This function is executed from the SAADCRV, SAADCBT, SARDCBT, andSARDCSN processes where decisions are posted. This is also executed from theSAAQUIK form if the Create Application checkbox is checked. The application willbe created, and the Curriculum and Field Of Study Create API will have the valuesfrom the STVAPDC table, or the values ACTIVE and ACCEPTED will be used.p_default_statusThis procedure in package SOKLCUR is executed whenever a new learner record iscreated to determine the default curriculum status code. If the module code isLEARNER, the curriculum status code is based on the student status code. In theCurriculum and Field Of Study Create API, the STVSTST table is queried to find thedefault curriculum status code for LEARNER.This procedure is called from SAAQUIK, SGASTDN, SHRDEGS, and SHRTYPE.p_push_degree_curriculumThis procedure in package SOKLCUR is executed when the degree status codechanges on the SHRDGMR table. If a curriculum status code exists on theSTVDEGS table, all active curricula and fields of study will be duplicated, and thecurriculum status code updated with the new code. If the degree status changes toan awarded status, and the curriculum status code does not appear on the STVDEGStable, the default values of ACTIVE and AWARDED will be used.This procedure is called from SHADEGR and SHRDEGS.In the Curriculum and Field Of Study Create API, the STVDEGS table is queried tofind the default curriculum status code and used to insert it on the new record. Thiskind of activity would not require the p_push_degree_curriculum procedure tobe executed, such as when grades are rolled and the degree initially created. Theuser can specify which curriculum status code is inserted.Changed Proceduresp_insert_srbrecrThis procedure in package SRKPREL has been modified so that it no longer insertsor updates the curriculum data on the SRBRECR table.January 2005 Student Release 7.0Confidential Release Guide 221

Section 7 Concurrent Curricula Phase 1 - TechnicalNew FunctionsIt now calls sakmods.p_create_recruit, which in turn inserts the SRBRECR,SORLCUR, and SORLFOS rows and calls procedure p_backload_curr to updatethe SRBRECR curriculum data fields.p_create_recruitThis procedure in package SAKMODS has been modified so that it no longer insertsor updates the curriculum data on the SRBRECR table.It now inserts the SRBRECR, SORLCUR, and SORLFOS rows and callsp_backload_curr to update the SRBRECR curriculum data fields.p_create_applicantThis procedure in package SAKMODS has been modified so that it no longer insertsor updates the curriculum data on the SARADAP table.It now inserts the SARADAP, SORLCUR, and SORLFOS rows and callsp_backload_curr to update the SARADAP curriculum data fields.p_create_studentThis procedure in package SAKMODS has been modified so that it no longer insertsor updates the curriculum data on the SGBSTDN table.It now inserts the SGBSTDN, SORLCUR, and SORLFOS rows and callsp_backload_curr to update the SGBSTDN curriculum data fields.New Functionsf_current_lfosThis function returns a value of Y or N if the SORLFOS row is the latest row for aPIDM, LCUR SEQNO, and PRIORTY.f_lfos_rowidThis function uses the P_LFOS_PRIORITY function but passes back just the ROWID.This function is used in views that need to report a major, minor, or concentrationfor a particular curriculum.Student Release 7.0 January 2005222 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalNew Functionsf_lfos_priorityThis function uses the lowest active priority number to determine the primary andsecondary curriculum that will be used by the Bridge API to populate SRBRECR,SARADAP, SGBSTDN, and SHRDGMR. This function returns the major, minor, orconcentration for a priority. For example, it would return the first major of theprimary curriculum.This function selects the lowest priority SORLFOS rows with the highest SORLFOSsequence numbers, a field of study of Major, and the same SORLCUR sequencenumber as selected above and then checks for an ACTIVE status. This process will beduplicated for minors and concentrations.f_current_lcurThis function returns a value of Y or N if the LCUR is the most current one for theLMOD, PIDM, TERM, KEYSEQNO, and PRIORITY.f_lcur_rowidThis function calls the P_LCUR_PRIORITY function but returns back just theROWID. This function is used in views that need to report a particular curriculum.It is an easy way to extract just the ROWID so the view can then query thecurriculum.f_lcur_priorityThis function determines the primary and secondary curriculum that will be usedby the Bridge API to populate SRBRECR, SARADAP, SGBSTDN, and SHRDGMR.This function returns the curriculum for a priority. For example, it would return theprimary curriculum.This function selects the lowest priority SORLCUR row with the highest SORLCURsequence number for learner module and checks for an ACTIVE status. If the statusfor the row is ACTIVE, it is determined to be the primary curriculum. If the statusfor the row is INACTIVE, the next lowest priority SORLCUR row is selected using thesame criteria, until all the SORLCUR rows have been reviewed, or until themaximum number of curriculum rows have been returned as defined onSOBLMOD.January 2005 Student Release 7.0Confidential Release Guide 223

Section 7 Concurrent Curricula Phase 1 - TechnicalNew Scriptsf_count_lcurThis function will return a value of Y or N for the check that the curriculum can beentered based on the counts on SOBLMOD. For example, if the value of theSOBLMOD_MAX_CURRICULA field for the Admissions module is two, and the userenters a third active LCUR row, that is an error. This function is executed from theAPI.f_count_lfosThis function will return a value of Y or N for the check that the field of study canbe entered based on the counts on SOBLMOD. For example, if the value of eitherthe SOBLMOD_MAX_MAJORS field, the SOBLMOD_MAX_MINORS field, or theSOBLMOD_MAX_CONCENTRATIONS field for the Admissions module is two, and theuser enters a third active LCUR row, that is an error. This function is executed fromthe API.New ScriptsSeed Data Scriptsigtvlfst70.sqlThis script is used to load field of study values on GTVLFST.isobcact70.sqlThis script is used to load the curriculum activity status rules on SOBCACT.isoblmod70.sqlThis script is used to load the maximum number for curriculum rules onSOBLMOD.istvcact70.sqlThis script is used to load the curriculum activity status codes on STVCACT.Student Release 7.0 January 2005224 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalNew Triggersistvcsts70.sqlThis script is used to load the curriculum status codes on STVCSTS.stvlmod.sqlThis script is used to load curriculum module values on STVLMOD.New Triggerscall_curriculumThis trigger is used to call the new Curriculum Summary window when the Curriculatab is selected or when the user navigates to the Curricula (SORLCUR) block.enable_curriculumThis form level trigger is used to enable all other items on the form (for SORLCURand SORLFOS blocks) so you can use the mouse to access any of the fields once thecurriculum and field of study data have been saved. This is used on the SRAQUIKand SAAQUIK forms.disable_curriculumThis form level trigger is used to disable all other items on the form (for SORLCURand SORLFOS blocks) so you cannot use the mouse to access any of the fields untilthe curriculum and field of study data have been saved. This is used on theSRAQUIK and SAAQUIK forms.post_forms_commit_trgThis form level trigger is used to set up the curriculum variables and call thecurriculum_commit trigger. The curriculum_commit trigger executes thebackfill p_backload_data procedure.January 2005 Student Release 7.0Confidential Release Guide 225

Section 7 Concurrent Curricula Phase 1 - TechnicalChanged TriggersChanged TriggersAdmissionsThe Copy_stdn trigger on SAAQUIK has been modified to fire after the curriculumdata has been entered for the quick admit.The Fill_adms trigger on SAAQUIK has been modified to call thesb_admissionsapplication.p_create and then copy the learner curriculumrows to the admissions record.The Fill_recr trigger on SAAQUIK has been modified to copy the learnercurriculum rows to the recruiting record.The pre-delete trigger in the SGBSTDN block of SAAQUIK has been modified tocheck for active SORLCUR data.The form level trigger sgbstdn_insert on SAADCRV has been modified to passthe application number and the term to sakmods.p_create_student.The form level trigger update_student on SAADCRV has been modified to updatethe student record via sb_learner.p_update.The curriculum triggers have been removed from SARDSCL, which is used bySAADCBT.General StudentThe key_delrec trigger in the SGBSTDN block on SGASTDN has been modifiedto check for SORLCUR records when deleting student records.The On-Insert trigger on SGASTDN has been modified to call thesb_learner.p_create procedure.The On-Delete trigger on SGASTDN has been modified to call thesb_learner.p_delete procedure.The On-Update trigger on SGASTDN has been modified to call thesb_learner.p_udpate procedure.RegistrationThe key_commit_cont trigger in the SGBSTDN block of SFAREGS has beenmodified to call the sb_learner.p_create.Student Release 7.0 January 2005226 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalNew IndexesNew IndexesTwo new indexes are delivered for the purpose of preventing users from enteringduplicate priority numbers for a curriculum or field of study type.SORLCUR_KEY_INDEX on SORLCURsorlcur_pidm,sorlcur_lmod_code,sorlcur_term_code,sorlcur_key_seqno,sorlcur_priority_noSORLFOS_KEY_INDEX on SORLFOSsorlfos_pidm,sorlfos_lcur_seqno,sorlfos_lfst_code,sorlfos_priority_noNew Primary Key Constraintspk_gtvlfstThe pk_gtvlfst primary key constraint has been added to GTVLFST.pk_stvcstsThe pk_stvcsts primary key constraint has been added to STVCSTS.pk_stvcactThe pk_stvcact primary key constraint has been added to STVCACT.pk_stvlmodThe pk_stvlmod primary key constraint has been added to STVLMOD.January 2005 Student Release 7.0Confidential Release Guide 227

Section 7 Concurrent Curricula Phase 1 - TechnicalNew Foreign Key Constraintspk_soblmodThe pk_soblmod primary key constraint has been added to SOBLMOD.pk_sobcactThe pk_sobcact primary key constraint has been added to SOBCACT.pk_sorlcurThe pk_sorlcur primary key constraint has been added to SORLCUR.pk_sorlfosThe pk_sorlfos primary key constraint has been added to SORLFOS.New Foreign Key ConstraintsThe following foreign key constraints have been added.• fk1_sorlcur_inv_stvlevl_code foreign key (sorlcur_levl_code)• fk1_sorlcur_inv_stvadmt_code foreign key (sorlcur_admt_code)• fk1_sorlcur_inv_stvcamp_code foreign key (sorlcur_camp_code)• fk1_sorlcur_inv_stvcoll_code foreign key (sorlcur_coll_code)• fk1_sorlcur_inv_stvdegc_code foreign key (sorlcur_degc_code)• fk1_sorlcur_inv_smrprle_key foreign key (sorlcur_program)• fk1_sorlcur_inv_stvterm_code foreign key (sorlcur_term_code)• fk2_sorlcur_inv_stvterm_code foreign key(sorlcur_term_code_admit)• fk3_sorlcur_inv_stvterm_code foreign key(sorlcur_term_code_matric)• fk5_sorlcur_inv_stvterm_code foreign key(sorlcur_term_code_ctlg)• fk4_sorlcur_inv_stvterm_code foreign key(sorlcur_term_code_end)• fk1_sorlcur_inv_stvlmod_code foreign key (sorlcur_lmod_code)Student Release 7.0 January 2005228 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalNew Banner Views• fk1_sorlcur_inv_stvcsts_code foreign key (sorlcur_csts_code)• fk1_sorlcur_inv_stvcact_code foreign key (sorlcur_cact_code)• fk1_soblmod_inv_stvlmod_code foreign key (soblmod_lmod_code)• fk1_sorlfos_inv_sorlcur_key foreign key (sorlfos_pidm,sorlfos_lcur_seqno)• fk1_sorlfos_inv_stvterm_code foreign key (sorlfos_term_code)• fk2_sorlfos_inv_stvterm_code foreign key(sorlfos_term_code_end)• fk3_sorlfos_inv_stvterm_code foreign key(sorlfos_term_code_ctlg)• fk1_sorlfos_inv_stvcsts_code foreign key (sorlfos_csts_code)• fk1_sorlfos_inv_stvcact_code foreign key (sorlfos_cact_code)• fk1_sorlfos_inv_stvmajr_code foreign key (sorlfos_majr_code)• fk1_sorlfos_inv_stvdept_code foreign key (sorlfos_dept_code)• fk1_sorlfos_inv_gtvlfst_code foreign key (sorlfos_lfst_code)• fk1_sorlfos_inv_stvtmst_code foreign key (sorlfos_tmst_code)• fk1_sobcact_inv_stvcact_code foreign key (sobcact_cact_code)New Banner ViewsCurriculum Base View (SOVLCUR)This Banner view is used to select curriculum based on the current and activestatuses. Current means it has the highest sequence number for the priority. Activemeans the Active Indicator for the curriculum activity status (CACT) on SOBCACTis set to Y.SOVLCUR_PIDMSOVLCUR_SEQNOSOVLCUR_LMOD_CODESOVLCUR_TERM_CODESOVLCUR_KEY_SEQNOSOVLCUR_PRIORITY_NOSOVLCUR_ROLL_INDSOVLCUR_CACT_CODESOVLCUR_USER_IDSOVLCUR_DATA_ORIGINSOVLCUR_ACTIVITY_DATEJanuary 2005 Student Release 7.0Confidential Release Guide 229

Section 7 Concurrent Curricula Phase 1 - TechnicalNew Banner ViewsSOVLCUR_LEVL_CODESOVLCUR_COLL_CODESOVLCUR_DEGC_CODESOVLCUR_TERM_CODE_CTLGSOVLCUR_TERM_CODE_ENDSOVLCUR_TERM_CODE_MATRICSOVLCUR_TERM_CODE_ADMITSOVLCUR_ADMT_CODESOVLCUR_CAMP_CODESOVLCUR_PROGRAMSOVLCUR_START_DATESOVLCUR_END_DATESOVLCUR_CURR_RULESOVLCUR_ROLLED_SEQNOSOVLCUR_CURRENT_INDSOVLCUR_ACTIVE_INDSOVLCUR_ROWIDField of Study View (SOVLFOS)This Banner view is used to select fields of study based on the current and activestatuses. Current means it has the highest sequence number for the priority andfield of study type. Active means the Active Indicator for the curriculum activitystatus (CACT) on SOBCACT is set to Y.SOVLFOS_PIDMSOVLFOS_LCUR_SEQNOSOVLFOS_SEQNOSOVLFOS_LFST_CODESOVLFOS_TERM_CODESOVLFOS_PRIORITY_NOSOVLFOS_CSTS_CODESOVLFOS_CACT_CODESOVLFOS_DATA_ORIGINSOVLFOS_USER_IDSOVLFOS_ACTIVITY_DATESOVLFOS_MAJR_CODESOVLFOS_TERM_CODE_CTLGSOVLFOS_TERM_CODE_ENDSOVLFOS_DEPT_CODESOVLFOS_LFOS_RULESOVLFOS_CONC_ATTACH_RULESOVLFOS_CONC_ATTACH_MAJR_CODESOVLFOS_MAJR_CODE_ATTACHSOVLFOS_START_DATESOVLFOS_END_DATESOVLFOS_TMST_CODESOVLFOS_ROLLED_SEQNOSOVLFOS_CURRENT_INDSOVLFOS_ACTIVE_INDSOVLFOS_ROWIDStudent Release 7.0 January 2005230 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalChanged Object LibrariesChanged Object LibrariesGOQOLIBGTVLFST_RG and GTVLFST_LOV were added for the new GTVLFST table.SOQOLIBSTVCACT_RG and STVCACT_LOV were added for the new STVCACT table.STVCSTS_RG and STVCSTS_LOV were added for the new STVCSTS table.STVLMOD_RG and STVLMOD_LOV were added for the new STVLMOD table.The new curriculum group object (S$_CURRICULUM_WINDOW) for the newCurriculum Group Object window is stored here.Seed DataLearner Field of Study Type Validation Table (GTVLFST)The following seed data is delivered for this table.Field of Study Code Description System Required IndicatorMAJOR Major YMINOR Minor YCONCENTRATION Concentration YJanuary 2005 Student Release 7.0Confidential Release Guide 231

Section 7 Concurrent Curricula Phase 1 - TechnicalSeed DataLearner Curriculum Activity Status Table (STVCACT)The following seed data is delivered for this table.Activity Status CodeACTIVEINACTIVEREMOVEDDescriptionActive CurriculumInactive CurriculumRemovedCurriculum Status Validation Table (STVCSTS)The following seed data is delivered for this table.Curriculum Status Code Description System Required IndicatorAPPACCEPT Applicant Acceptance YAPPLIED Application Exists YAWARDED Degree Awarded YCHANGED Changed YCOMPLETED Completed YDENIEDApplication has beenrejectedYINPROGRESS In Progress YINSTACCEPT Institution Acceptance YPENDING Pending YSOUGHT Degree has sought status YStudent Release 7.0 January 2005232 Release Guide Confidential

Section 7 Concurrent Curricula Phase 1 - TechnicalSeed DataLearner Module Validation Table (STVLMOD)The following seed data is delivered for this table.Module CodeRECRUITADMISSIONSLEARNEROUTCOMEDescriptionRecruitingAdmissionsStudentStudent OutcomeCurriculum Activity Status Rules Table (SOBCACT)The following seed data is delivered for this table.Activity Status Code Active Indicator System Required IndicatorACTIVE Y YINACTIVE Y YREMOVED N YLearner Curriculum Frequency Rules Table (SOBLMOD)The following seed data is delivered for this table.Module CodeNumber ofCurriculaNumber ofMajorsNumber ofMinorsNumber ofConcentrationsRECRUIT 1 2 2 6ADMISSIONS 2 2 2 6LEARNER 2 2 2 6OUTCOME 2 2 2 6January 2005 Student Release 7.0Confidential Release Guide 233

Section 7 Concurrent Curricula Phase 1 - TechnicalSeed DataThis page intentionally left blankStudent Release 7.0 January 2005234 Release Guide Confidential

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalChanged TableSection 8New Value-Based Security and PersonallyIdentifiable Information Security UsingFine-Grained Access Control - TechnicalThis enhancement is new for Release 7.0.This section provides technical detail about the Student product domains and howto use them in the New Value-Based Security and Personally IdentifiableInformation Security.Changed TablePerson Identification/Name Repeating Table (SPRIDEN)A new column has been added, SPRIDEN_CREATE_FDMN_CODE. This column is NOTNULL, varchar2(30).APIs in Banner 7.0 are used to populate this column. The column will have thectx_fg_fdmn_code_home value. This is the context variable that houses the PIIdomain of the user’s home domain from GOAFPUD.Changed PackagesThe following Banner packages have been modified. Lines were added to turn VBSusing FGAC off at the start of the procedure and to turn it back on at the end of theprocedure.PackageSAKCHKBSFKEDITProceduresp_updappstatusp_pre_editp_group_editsp_connected_group_editsp_web_group_editsp_update_regsJanuary 2005 Student Release 7.0Confidential Release Guide 235

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalObsolete ProceduresObsolete ProceduresThe following database procedures were used with Value-Based Security and arenow obsolete.Database Proceduresscfcvbs.sqlscfsvbs.sqlsckvbs1.sqlsckvbsr.sqlsofv001.sqlsofv002.sqlsofv003.sqlsofv004.sqlsofv005.sqlsofv006.sqlsofv007.sqlsofv008.sqlsofv009.sqlsofv010.sqlsofv011.sqlsofv012.sqls0fv013.sqlsokwev1.sqlsokwevn.sqlsopctlg.sqlsopschd.sqlsopv005.sqlsskvbs1.sqlAffected ObjectF_CheckVBSCatalogAccessF_CheckVBSScheduleAccessF_CheckVBSCatalogBaseAccessF_CheckVBSCourseAccessN/AF_IsRecruitF_IsApplicantF_IsStudentF_IsHistory (Entire function commented out)F_IsFaculty (Entire function commented out)F_ValidVBSValueF_CHKAPPLICANTF_CHKSTUDENTF_ChkRecruitF_ValidationCodeAccessF_CheckPIDMAccessF_GetSrbrecrSeqNoF_GetSaradapSeqNoWorkflow eventsWorkflow eventsP_GetCatalogItemsP_GetScheduleItemsP_VBSMarkerF_CheckVBSBaseScheduleAccessStudent Release 7.0 January 2005236 Release Guide Confidential

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalObsolete TriggersDatabase Proceduressskvbsr.sqlsopv003.sqlAffected ObjectN/AP_PopulateGorvmgaObsolete TriggersThe following database triggers were used with Value-Based Security and are nowobsolete.Database Triggersatadap1.sqlsatadap2.sqlsatadap3.sqlsatappd1.sqlsatappd2.sqlsctattr1.sqlsctattr2.sqlsctattr3.sqlsctcorq1.sqlsctcorq2.sqlsctcorq3.sqlsctcrky2.sqlsctcrky3.sqlsctcrse1.sqlsctcrse2.sqlsctcrse3.sqlsctdesc1.sqlsctdesc2.sqlsctdesc3.sqlscteqiv1.sqlscteqiv2.sqlscteqiv3.sqlsctfees1.sqlsctfees2.sqlsctfees3.sqlsctgmod1.sqlsctgmod2.sqlsctgmod3.sqlsctlevl1.sqlsctlevl2.sqlsctlevl3.sqlsctrare1.sqlsctrare2.sqlsctrare3.sqlsctrcam1.sqlsctrcam2.sqlAffected ObjectSARADAPSARADAPSARADAPSARAPPDSARAPPDSCRATTRSCRATTRSCRATTRSCRCORQSCRCORQSCRCORQSCBCRKYSCBCKRYSCBCRSESCBCRSESCBCRSESCBDESCSCBDESCSCBDESCSCREQIVSCREQIVSCREQIVSCRFEESSCRFEESSCRFEESSCRGMODSCRGMODSCRGMODSCRLEVLSCRLEVLSCRLEVLSCRRARESCRRARESCRRARESCRRCAMSCRRCAMJanuary 2005 Student Release 7.0Confidential Release Guide 237

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalObsolete TriggersDatabase Triggersctrcam3.sqlsctrcls1.sqlsctrcls2.sqlsctrcls3.sqlsctrcmp1.sqlsctrcmp2.sqlsctrcmp3.sqlsctrcol1.sqlsctrcol2.sqlsctrcol3.sqlsctrdeg1.sqlsctrdeg2.sqlsctrdeg3.sqlsctrlvl1.sqlsctrlvl2.sqlsctrlvl3.sqlsctrmaj1.sqlsctrmaj2.sqlsctrmaj3.sqlsctrprg1.sqlsctrprg2.sqlsctrprg3.sqlsctrtrm1.sqlsctrtrm2.sqlsctrtrm3.sqlsctrtst1.sqlsctrtst2.sqlsctrtst3.sqlsctsbgi1.sqlsctsbgi2.sqlsctsbgi3.sqlsctschd1.sqlsctschd2.sqlsctschd3.sqlsctsupp1.sqlsctsupp2.sqlsctsupp3.sqlsctsyln1.sqlsctsyln2.sqlsctsyln3.sqlsctsylo1.sqlsctsylo2.sqlsctsylo3.sqlsctsyrm1.sqlsctsyrm2.sqlsctsyrm3.sqlsctsytr1.sqlsctsytr2.sqlsctsytr3.sqlscttext1.sqlscttext2.sqlscttext3.sqlAffected ObjectSCRRCAMSCRRCLSSCRRCLSSCRRCLSSCRRCMPSCRRCMPSCRRCMPSCRRCOLSCRRCOLSCRRCOLSCRRDEGSCRRDEGSCRRDEGSCRRLVLSCRRLVLSCRRLVLSCRRMAJSCRRMAJSCRRMAJSCRRPRGSCRRPRGSCRRPRGSCRRTRMSCRRTRMSCRRTRMSCRRTSTSCRRTSTSCRRTSTSCRSBGISCRSBGISCRSBGISCRSCHDSCRSCHDSCRSCHDSCRSUPPSCRSUPPSCRSUPPSCRSYLNSCRSYLNSCRSYLNSCRSYLOSCRSYLOSCRSYLOSCRSYRMSCRSYRMSCRSYRMSCRSYTRSCRSYTRSCRSYTRSCRTEXTSCRTEXTSCRTEXTStudent Release 7.0 January 2005238 Release Guide Confidential

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalObsolete TriggersDatabase Triggersgtstdn1.sqlsgtstdn2.sqlsgtstdn3.sqlsottest1.sqlsottest2.sqlsrtrecr1.sqlsrtrecr2.sqlsrtrecr3.sqlsstattr1.sqlsstattr2.sqlsstattr3.sqlsstblck1.sqlsstblck2.sqlsstblck3.sqlsstcorq1.sqlsstcorq2.sqlsstcorq3.sqlsstdesc1.sqlsstdesc2.sqlsstdesc3.sqlssteval1.sqlssteval2.sqlssteval3.sqlsstextn1.sqlsstextn2.sqlsstextn3.sqlsstfees1.sqlsstfees2.sqlsstfees3.sqlsstfsec1.sqlsstfsec2.sqlsstfsec3.sqlsstlink1.sqlsstlink2.sqlsstlink3.sqlsstmeet1.sqlsstmeet2.sqlsstmeet3.sqlsstovrr1.sqlsstovrr2.sqlsstovrr3.sqlsstrare1.sqlsstrare2.sqlsstrare3.sqlsstrcls1.sqlsstrcls2.sqlsstrcls3.sqlsstrcmp1.sqlsstrcmp2.sqlsstrcmp3.sqlsstrcol1.sqlsstrcol2.sqlAffected ObjectSGBSTDNSGBSTDNSGBSTDNSORTESTSORTESTSRBRECRSRBRECRSRBRECRSSRATTRSSRATTRSSRATTRSSRBLCKSSRBLCKSSRBLCKSSRCORQSSRCORQSSRCORQSSRDESCSSRDESCSSRDESCSSREVALSSREVALSSREVALSSREXTNSSREXTNSSREXTNSSRFEESSSRFEESSSRFEESSSRFSECSSRFSECSSRFSECSSRLINKSSRLINKSSRLINKSSRMEETSSRMEETSSRMEETSSROVRRSSROVRRSSROVRRSSRRARESSRRARESSRRARESSRRCLSSSRRCLSSSRRCLSSSRRCMPSSRRCMPSSRRCMPSSRRCOLSSRRCOLJanuary 2005 Student Release 7.0Confidential Release Guide 239

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalObsolete TriggersDatabase Triggersstrcol3.sqlsstrdeg1.sqlsstrdeg2.sqlsstrdeg3.sqlsstresv1.sqlsstresv2.sqlsstresv3.sqlsstrfnd1.sqlsstrfnd2.sqlsstrfnd3.sqlsstrlvl1.sqlsstrlvl2.sqlsstrlvl3.sqlsstrmaj1.sqlsstrmaj2.sqlsstrmaj3.sqlsstrprg1.sqlsstrprg2.sqlsstrprg3.sqlsstrsts1.sqlsstrsts2.sqlsstrsts3.sqlsstsccd1.sqlsstsccd2.sqlsstsccd3.sqlsstsect1.sqlsstsect2.sqlsstsect3.sqlsstssec1.sqlsstssec2.sqlsstssec3.sqlsstsyln1.sqlsstsyln2.sqlsstsyln3.sqlsstsylo1.sqlsstsylo2.sqlsstsylo3.sqlsstsyrm1.sqlsstsyrm2.sqlsstsyrm3.sqlsstsytr1.sqlsstsytr2.sqlsstsytr3.sqlssttext1.sqlssttext2.sqlssttext3.sqlsstxlst1.sqlsstxlst2.sqlsstxlst3.sqlAffected ObjectSSRRCOLSSRRDEGSSRRDEGSSRRDEGSSRRESVSSRRESVSSRRESVSSRRFNDSSRRFNDSSRRFNDSSRRLVLSSRRLVLSSRRLVLSSRRMAJSSRRMAJSSRRMAJSSRRPRGSSRRPRGSSRRPRGSSRRTSTSSRRTSTSSRRTSTSSRSCCDSSRSCCDSSRSCCDSSBSECTSSBSECTSSBSECTSSBSSECSSBSSECSSBSSECSSRSYLNSSRSYLNSSRSYLNSSRSYLOSSRSYLOSSRSYLOSSRSYRMSSRSYRMSSRSYRMSSRSYTRSSRSYTRSSRSYTRSSRTEXTSSRTEXTSSRTEXTSSRXLSTSSRXLSTSSRXLSTStudent Release 7.0 January 2005240 Release Guide Confidential

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalObsolete Banner ViewsObsolete Banner ViewsThe following Banner views were used with Value-Based Security and are nowobsolete.ViewSRBRECR_SECUREDSARADAP_SECUREDSGBSTDN_SECUREDSTVGPAT_SECUREDSORGPAT_SECUREDSORTEST_SECUREDSTVTESC_SECUREDSupporting Scriptsovrecr.sqlsovadap.sqlsovstdn.sqlsovgpa1.sqlsovgpat.sqlsovtes1.sqlsovtesc.sqlChanged Object:Access ViewsThe following Object:Access views have had Value-Based Security processingremoved.Object:Access ViewAS_RECRUITING_DATAAS_RECRUITING_SOURCE_ANALYSISAS_ADMISSIONS_APPLICANTAS_STUDENT_DATASupporting Scriptsrvrcr0.sqlsrvrsr0.sqlsavadm0.sqlsgvstd0.sqlSeed DataThe following seed data is delivered with this enhancement.January 2005 Student Release 7.0Confidential Release Guide 241

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Driver Table Seed Data for GORFDMNThe following domain driver table seed data for each domain on the FGAC DomainValidation Form (GTVFDMN) is delivered for use with FGAC for Banner Student.Domain Description Driver TableSB_CATALOG_VBS Catalog SCBCRSESB_SCHEDULE_VBS Schedule SSBSECTSB_CURRICULUM_VBSSB_FIELDOFSTUDY_VBSRecruiting, Admissions,Learner, Outcome BaseCurriculumRecruiting, Admissions,Learner, Outcome Base Fieldsof StudySORLCURSORLFOSSB_RECRUIT_VBS Recruiting SRBRECRSB_ADMISSIONS_VBS Admissions SARADAPSB_LEARNER_VBS General Student SGBSTDNSB_TESTSCORES_VBS Test Scores SORTESTSB_TESTSCORES_STUDENT_VBSTest scores for learners, userhas accessSORTESTSB_TESTCODES_VBS Test Codes STVTESCSB_OTHERGPA_VBS Other GPA SORGPATSB_OTHERGPA_STUDENT_VBSOther GPAs for learners, userhas accessSORGPATSB_OTHERGPACODES_VBS Other GPA Codes STVGPATSB_FACULTY_PII Faculty SIBINSTSB_HOUSING_PII Housing SLBRMAPSB_RECRUIT_PII Recruiting SARADAPSB_ADMISSIONS_PII Admissions SARADAPSB_GENSTUDENT_PII General Student SGBSTDNSB_REGISTRATION_PII Registration Enrollment SFBETRMSB_TRANSFER_PII Transfer Course Maintenance SHRTTRMStudent Release 7.0 January 2005242 Release Guide Confidential

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataVBS Policy Table Seed Data (GORFDPL)The following domain policy table seed data is delivered for use with FGAC forBanner Student. Domains are listed by driver table and with the tables wherepredicate functions are built. This data is found on the FGAC VBS Table Rules Form(GORFDPL). Entries on this form are required for Oracle policy creation. Thedriver SQL joins the policy table to the domain driver table. VBS restrictions arewritten for the domain driver table.Domain Policy Table Driver SQLSB_CATALOG_VBSSCBCRSESB_CATALOG_VBS SCBDESC EXISTS (SELECT 'X' FROM SCBCRSE WHERESCBCRSE_CRSE_NUMB =SCBDESC_CRSE_NUMB ANDSCBCRSE_SUBJ_CODE =SCBDESC_SUBJ_CODE ANDSCBCRSE_EFF_TERM =(SELECT MAX(A.SCBCRSE_EFF_TERM) FROMSCBCRSE A WHERE A.SCBCRSE_SUBJ_CODE =SCBDESC_SUBJ_CODE ANDA.SCBCRSE_CRSE_NUMB =SCBDESC_CRSE_NUMB ANDA.SCBCRSE_EFF_TERM

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_CATALOG_VBS SCRCORQ EXISTS (SELECT 'X' FROM SCBCRSE WHERESCBCRSE_CRSE_NUMB =SCRCORQ_CRSE_NUMB ANDSCBCRSE_SUBJ_CODE =SCRCORQ_SUBJ_CODE ANDSCBCRSE_EFF_TERM =(SELECT MAX(A.SCBCRSE_EFF_TERM) FROMSCBCRSE A WHERE A.SCBCRSE_SUBJ_CODE =SCRCORQ_SUBJ_CODE ANDA.SCBCRSE_CRSE_NUMB =SCRCORQ_CRSE_NUMB ANDA.SCBCRSE_EFF_TERM

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_CATALOG_VBS SCRFEES EXISTS (SELECT 'X' FROM SCBCRSE WHERESCBCRSE_CRSE_NUMB =SCRFEES_CRSE_NUMB ANDSCBCRSE_SUBJ_CODE =SCRFEES_SUBJ_CODE ANDSCBCRSE_EFF_TERM =(SELECT MAX(A.SCBCRSE_EFF_TERM) FROMSCBCRSE A WHERE A.SCBCRSE_SUBJ_CODE =SCRFEES_SUBJ_CODE ANDA.SCBCRSE_CRSE_NUMB =SCRFEES_CRSE_NUMB ANDA.SCBCRSE_EFF_TERM

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_CATALOG_VBS SCRRCAM EXISTS (SELECT 'X' FROM SCBCRSE WHERESCBCRSE_CRSE_NUMB =SCRRCAM_CRSE_NUMB ANDSCBCRSE_SUBJ_CODE =SCRRCAM_SUBJ_CODE ANDSCBCRSE_EFF_TERM =(SELECT MAX(A.SCBCRSE_EFF_TERM) FROMSCBCRSE A WHERE A.SCBCRSE_SUBJ_CODE =SCRRCAM_SUBJ_CODE ANDA.SCBCRSE_CRSE_NUMB =SCRRCAM_CRSE_NUMB ANDA.SCBCRSE_EFF_TERM

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_CATALOG_VBS SCRRDEG EXISTS (SELECT 'X' FROM SCBCRSE WHERESCBCRSE_CRSE_NUMB =SCRRDEG_CRSE_NUMB ANDSCBCRSE_SUBJ_CODE =SCRRDEG_SUBJ_CODE ANDSCBCRSE_EFF_TERM =(SELECT MAX(A.SCBCRSE_EFF_TERM) FROMSCBCRSE A WHERE A.SCBCRSE_SUBJ_CODE =SCRRDEG_SUBJ_CODE ANDA.SCBCRSE_CRSE_NUMB =SCRRDEG_CRSE_NUMB ANDA.SCBCRSE_EFF_TERM

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_CATALOG_VBS SCRRTRM EXISTS (SELECT 'X' FROM SCBCRSE WHERESCBCRSE_CRSE_NUMB =SCRRTRM_CRSE_NUMB ANDSCBCRSE_SUBJ_CODE =SCRRTRM_SUBJ_CODE ANDSCBCRSE_EFF_TERM =(SELECT MAX(A.SCBCRSE_EFF_TERM) FROMSCBCRSE A WHERE A.SCBCRSE_SUBJ_CODE =SCRRTRM_SUBJ_CODE ANDA.SCBCRSE_CRSE_NUMB =SCRRTRM_CRSE_NUMB ANDA.SCBCRSE_EFF_TERM

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_CATALOG_VBS SCRSYLN EXISTS (SELECT 'X' FROM SCBCRSE WHERESCBCRSE_CRSE_NUMB =SCRSYLN_CRSE_NUMB ANDSCBCRSE_SUBJ_CODE =SCRSYLN_SUBJ_CODE ANDSCBCRSE_EFF_TERM =(SELECT MAX(A.SCBCRSE_EFF_TERM) FROMSCBCRSE A WHERE A.SCBCRSE_SUBJ_CODE =SCRSYLN_SUBJ_CODE ANDA.SCBCRSE_CRSE_NUMB =SCRSYLN_CRSE_NUMB ANDA.SCBCRSE_EFF_TERM

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_CATALOG_VBS SCRTEXT EXISTS (SELECT 'X' FROM SCBCRSE WHERESCBCRSE_CRSE_NUMB =SCRTEXT_CRSE_NUMB ANDSCBCRSE_SUBJ_CODE =SCRTEXT_SUBJ_CODE ANDSCBCRSE_EFF_TERM =(SELECT MAX(A.SCBCRSE_EFF_TERM) FROMSCBCRSE A WHERE A.SCBCRSE_SUBJ_CODE =SCRTEXT_SUBJ_CODE ANDA.SCBCRSE_CRSE_NUMB =SCRTEXT_CRSE_NUMB ANDA.SCBCRSE_EFF_TERM

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_SCHEDULE_VBS SSRCORQ EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRCORQ_CRN ANDSSBSECT_TERM_CODE =SSRCORQ_TERM_CODESB_SCHEDULE_VBS SSREVAL EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSREVAL_CRN ANDSSBSECT_TERM_CODE =SSREVAL_TERM_CODESB_SCHEDULE_VBS SSREXTN EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSREXTN_CRN ANDSSBSECT_TERM_CODE =SSREXTN_TERM_CODESB_SCHEDULE_VBS SSRFEES EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRFEES_CRN ANDSSBSECT_TERM_CODE =SSRFEES_TERM_CODESB_SCHEDULE_VBS SSRLINK EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRLINK_CRN ANDSSBSECT_TERM_CODE =SSRLINK_TERM_CODESB_SCHEDULE_VBS SSRMEET EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRMEET_CRN ANDSSBSECT_TERM_CODE =SSRMEET_TERM_CODESB_SCHEDULE_VBS SSRMPRT EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRMPRT_CRN ANDSSBSECT_TERM_CODE =SSRMPRT_TERM_CODESB_SCHEDULE_VBS SSRMRDF EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRMRDF_CRN AND SSBSECT_TERM_CODE =SSRMRDF_TERM_CODESB_SCHEDULE_VBS SSRRARE EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRRARE_CRN ANDSSBSECT_TERM_CODE =SSRRARE_TERM_CODEJanuary 2005 Student Release 7.0Confidential Release Guide 251

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_SCHEDULE_VBS SSRRCLS EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRRCLS_CRN ANDSSBSECT_TERM_CODE =SSRRCLS_TERM_CODESB_SCHEDULE_VBS SSRRCMP EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRRCMP_CRN ANDSSBSECT_TERM_CODE =SSRRCMP_TERM_CODESB_SCHEDULE_VBS SSRRCOL EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRRCOL_CRN ANDSSBSECT_TERM_CODE =SSRRCOL_TERM_CODESB_SCHEDULE_VBS SSRRDEG EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRRDEG_CRN ANDSSBSECT_TERM_CODE =SSRRDEG_TERM_CODESB_SCHEDULE_VBS SSRRESV EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRRESV_CRN ANDSSBSECT_TERM_CODE =SSRRESV_TERM_CODESB_SCHEDULE_VBS SSRRFND EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRRFND_CRN ANDSSBSECT_TERM_CODE =SSRRFND_TERM_CODESB_SCHEDULE_VBS SSRRLVL EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRRLVL_CRN ANDSSBSECT_TERM_CODE =SSRRLVL_TERM_CODESB_SCHEDULE_VBS SSRRMAJ EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRRMAJ_CRN ANDSSBSECT_TERM_CODE =SSRRMAJ_TERM_CODESB_SCHEDULE_VBS SSRRPRG EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRRPRG_CRN ANDSSBSECT_TERM_CODE =SSRRPRG_TERM_CODEStudent Release 7.0 January 2005252 Release Guide Confidential

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_SCHEDULE_VBS SSRRSTS EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRRSTS_CRN ANDSSBSECT_TERM_CODE =SSRRSTS_TERM_CODESB_SCHEDULE_VBS SSRRTST EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRRTST_CRN ANDSSBSECT_TERM_CODE =SSRRTST_TERM_CODESB_SCHEDULE_VBS SSRSCCD EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRSCCD_CRN ANDSSBSECT_TERM_CODE =SSRSCCD_TERM_CODESB_SCHEDULE_VBS SSRSPRT EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRSPRT_CRN ANDSSBSECT_TERM_CODE =SSRSPRT_TERM_CODESB_SCHEDULE_VBS SSRSRDF EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRSRDF_CRN ANDSSBSECT_TERM_CODE =SSRSRDF_TERM_CODESB_SCHEDULE_VBS SSRSYLN EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRSYLN_CRN ANDSSBSECT_TERM_CODE =SSRSYLN_TERM_CODESB_SCHEDULE_VBS SSRSYLO EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRSYLO_CRN ANDSSBSECT_TERM_CODE =SSRSYLO_TERM_CODESB_SCHEDULE_VBS SSRSYRM EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRSYRM_CRN ANDSSBSECT_TERM_CODE =SSRSYRM_TERM_CODESB_SCHEDULE_VBS SSRSYTR EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRSYTR_CRN ANDSSBSECT_TERM_CODE =SSRSYTR_TERM_CODEJanuary 2005 Student Release 7.0Confidential Release Guide 253

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_SCHEDULE_VBS SSRTEXT EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRTEXT_CRN ANDSSBSECT_TERM_CODE =SSRTEXT_TERM_CODESB_SCHEDULE_VBS SSRXLST EXISTS (SELECT 'X' FROM SSBSECT WHERESSBSECT_CRN =SSRXLST_CRN ANDSSBSECT_TERM_CODE =SSRXLST_TERM_CODESB_CURRICULUM_VBSSB_FIELDOFSTUDY_VBSSB_RECRUIT_VBSSORLCURSORLFOSSRBRECRSB_RECRUIT_VBS SRRCHRT EXISTS (SELECT 'X' FROM SRBRECR WHERESRBRECR_PIDM =SRRCHRT_PIDM ANDSRBRECR_TERM_CODE =SRRCHRT_TERM_CODE ANDSRBRECR_ADMIN_SEQNO =SRRCHRT_ADMIN_SEQNOSB_RECRUIT_VBS SRRLEND EXISTS (SELECT 'X' FROM SRBRECR WHERESRBRECR_PIDM =SRRLEND_PIDM ANDSRBRECR_TERM_CODE =SRRLEND_TERM_CODE ANDSRBRECR_ADMIN_SEQNO =SRRLEND_ADMIN_SEQNOSB_RECRUIT_VBS SRRRATT EXISTS (SELECT 'X' FROM SRBRECR WHERESRBRECR_PIDM =SRRRATT_PIDM ANDSRBRECR_TERM_CODE =SRRRATT_TERM_CODE ANDSRBRECR_ADMIN_SEQNO =SRRRATT_ADMIN_SEQNOSB_RECRUIT_VBS SRRRSRC EXISTS (SELECT 'X' FROM SRBRECR WHERESRBRECR_PIDM =SRRRSRC_PIDM ANDSRBRECR_TERM_CODE =SRRRSRC_TERM_CODE ANDSRBRECR_ADMIN_SEQNO =SRRRSRC_ADMIN_SEQNOStudent Release 7.0 January 2005254 Release Guide Confidential

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_ADMISSIONS_VBS SARACMT EXISTS (SELECT 'X' FROM SARADAP WHERESARADAP_PIDM = SARACMT_PIDM ANDSARADAP_TERM_CODE_ENTRY =SARACMT_TERM_CODE ANDSARADAP_APPL_NO =SARACMT_APPL_NOSB_ADMISSIONS_VBSSARADAPSB_ADMISSIONS_VBS SARAPPD EXISTS (SELECT 'X' FROM SARADAP WHERESARADAP_PIDM = SARAPPD_PIDM ANDSARADAP_TERM_CODE_ENTRY =SARAPPD_TERM_CODE_ENTRY ANDSARADAP_APPL_NO =SARAPPD_APPL_NOSB_ADMISSIONS_VBS SARCHKL EXISTS (SELECT 'X' FROM SARADAP WHERESARADAP_PIDM = SARCHKL_PIDM ANDSARADAP_TERM_CODE_ENTRY =SARCHKL_TERM_CODE_ENTRY ANDSARADAP_APPL_NO =SARCHKL_APPL_NOSB_ADMISSIONS_VBS SARCHRT EXISTS (SELECT 'X' FROM SARADAP WHERESARADAP_PIDM = SARCHRT_PIDM ANDSARADAP_TERM_CODE_ENTRY =SARCHRT_TERM_CODE_ENTRY ANDSARADAP_APPL_NO =SARCHRT_APPL_NOSB_ADMISSIONS_VBS SARDSCL EXISTS (SELECT 'X' FROM SARADAP WHERESARADAP_PIDM = SARDSCL_PIDM ANDSARADAP_TERM_CODE_ENTRY =SARDSCL_TERM_CODE ANDSARADAP_APPL_NO =SARDSCL_APPL_NOSB_ADMISSIONS_VBS SARQUAN EXISTS (SELECT 'X' FROM SARADAP WHERESARADAP_PIDM = SARQUAN_PIDM ANDSARADAP_TERM_CODE_ENTRY =SARQUAN_TERM_CODE_ENTRY ANDSARADAP_APPL_NO =SARQUAN_APPL_NOSB_ADMISSIONS_VBS SARRRAT EXISTS (SELECT 'X' FROM SARADAP WHERESARADAP_PIDM = SARRRAT_PIDM ANDSARADAP_TERM_CODE_ENTRY =SARRRAT_TERM_CODE ANDSARADAP_APPL_NO =SARRRAT_APPL_NOJanuary 2005 Student Release 7.0Confidential Release Guide 255

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_ADMISSIONS_VBS SARRSRC EXISTS (SELECT 'X' FROM SARADAP WHERESARADAP_PIDM = SARRSRC_PIDM ANDSARADAP_TERM_CODE_ENTRY =SARRSRC_TERM_CODE_ENTRY ANDSARADAP_APPL_NO =SARRSRC_APPL_NOSB_ADMISSIONS_VBS SARAATT EXISTS (SELECT 'X' FROM SARADAP WHERESARADAP_PIDM = SARAATT_PIDM ANDSARADAP_TERM_CODE_ENTRY =SARAATT_TERM_CODE_ENTRY ANDSARADAP_APPL_NO = SARAATT_APPL_NOSB_ADMISSIONS_VBS SABSUPL EXISTS (SELECT 'X' FROM SARADAP WHERESARADAP_PIDM = SABSUPL_PIDM ANDSARADAP_TERM_CODE_ENTRY =SABSUPL_TERM_CODE_ENTRY ANDSARADAP_APPL_NO = SABSUPL_APPL_NOSB_LEARNER_VBS SGBEOPS EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGBEOPS_PIDMSB_LEARNER_VBS SGBOEDU EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGBOEDU_PIDMSB_LEARNER_VBSSGBSTDNSB_LEARNER_VBS SGBUSER EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGBUSER_PIDMSB_LEARNER_VBS SGRACMT EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRACMT_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRACMT_TERM_CODE_EFFSB_LEARNER_VBS SGRADVR EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRADVR_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRADVR_TERM_CODE_EFFSB_LEARNER_VBS SGRASSI EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRASSI_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRASSI_TERM_CODE_EFFSB_LEARNER_VBS SGRASST EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRASST_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRASST_TERM_CODE_EFFSB_LEARNER_VBS SGRCHRT EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRCHRT_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRCHRT_TERM_CODE_EFFStudent Release 7.0 January 2005256 Release Guide Confidential

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_LEARNER_VBS SGRCMNT EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRCMNT_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRCMNT_TERM_CODESB_LEARNER_VBS SGRCOOP EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRCOOP_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRCOOP_TERM_CODESB_LEARNER_VBS SGRDISA EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRDISA_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRDISA_TERM_CODESB_LEARNER_VBS SGRDSER EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRDSER_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRDSER_TERM_CODESB_LEARNER_VBS SGRDUTY EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRDUTY_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRDUTY_TERM_CODESB_LEARNER_VBS SGRESEL EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRESEL_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRESEL_TERM_CODE_EFFSB_LEARNER_VBS SGRSACT EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRSACT_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRSACT_TERM_CODESB_LEARNER_VBS SGRSATT EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRSATT_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRSATT_TERM_CODE_EFFSB_LEARNER_VBS SGRSCMT EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRSCMT_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRSCMT_TERM_CODESB_LEARNER_VBS SGRSPRT EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRSPRT_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRSPRT_TERM_CODESB_LEARNER_VBS SGRVETN EXISTS (SELECT 'X' FROM SGBSTDN WHERESGBSTDN_PIDM = SGRVETN_PIDM ANDSGBSTDN_TERM_CODE_EFF =SGRVETN_TERM_CODE_VAJanuary 2005 Student Release 7.0Confidential Release Guide 257

Section 8 New Value-Based Security and Personally Identifiable Information Security Using Fine-Grained Access Control - TechnicalSeed DataDomain Policy Table Driver SQLSB_TESTSCORES_VBSSORTESTSB_TESTSCORES_STUDENT_VBS SORTEST SOKFGAC.F_FIND_IF_STUDENT(SORTEST_PIDM) = 'Y'SB_TESTCODES_VBSSB_OTHERGPA_VBSSTVTESCSORGPATSB_OTHERGPA_STUDENT_VBS SORGPAT SOKFGAC.F_FIND_IF_STUDENT(SORGPAT_PIDM) = 'Y'SB_OTHERGPA_CODES_VBSSTVGPATPII Policy Table (GORFDPI)The following row is delivered for the GORFDPI table, for use with the SPRIDENtable, which is owned by the STUDENT table owner.Table NameSPRIDENCode that Links Table Predicate to Domain Driver Table(GOBFDMN)gokfgac.f_find_pii_domainStudent Release 7.0 January 2005258 Release Guide Confidential

Section 9 Common Matching - TechnicalNew TableSection 9Common Matching - TechnicalThis enhancement is new for Release 7.0.New TableStudent Common Matching Match Entry Temporary Table(SOTCMME)This temporary table is used to store student-specific high school data elements forthe Common Matching processing.The following columns are on this table:SOTCMME_SBGI_CODEVARCHAR2(6)High School Code: The source or background code number of the high schoolfor the person to be created.SOTCMME_SBGI_NAMEVARCHAR2(30)High School Name: The name of the high school for the person to be created.SOTCMME_SBGI_CITYVARCHAR2(20)High School City: The city associated with the address of the high school of theperson to be created.SOTCMME_SBGI_STAT_CODEVARCHAR2(3)High School State: The state or province code associated with the address of thehigh school of the person to be created.SOTCMME_SBGI_ZIPVARCHAR2(10)High School ZIP: The ZIP or postal code associated with the address of the highschool of the person to be created.January 2005 Student Release 7.0Confidential Release Guide 259

Section 9 Common Matching - TechnicalChanged TableChanged TableInterface Code Validation Table (STVINFC)A new Common Matching Source Code column has been added to link the studentmatching process with the new match routine. The STVINFC_ CMSC_CODE field hasbeen added to the validation form and the table.STVINFC_CMSC_CODEVARCHAR2(20)Obsolete TablesInterface Rules Repeating Table (SORINFR)This table is obsolete. It has been replaced by the new GORCMSC table.First Name Translation Rules Table (SORNAME)This table is obsolete. It has been replaced by the new GORNAME table.Note: First and middle names are now checked against the new GORNAMEtable.Changed PackagesSAKQADMThis package is used for quick admit processing. It has been modified to use the newCommon Matching processing. The following changes have been made:• Procedure p_select_saveaps has been changed to eliminate compressedname fields and to select email address and nation data.• Calls to the following SAKMTCH procedures have been eliminated:• p_select_infc_rule_inds• p_match_errorallStudent Release 7.0 January 2005260 Release Guide Confidential

Section 9 Common Matching - TechnicalChanged Packages• f_check_errorall• p_match_ssn_ln• p_auto_match (replaced with Common Matching procedure)• Associated variables have been removed.• The Common Matching process has been implemented with calls to theGOKCMPK package procedures.SAKMTCHThe following procedures and functions in this package have been removed andmade obsolete:• p_auto_match• p_select_infc_rule_inds• p_match_errorall• p_match_ssn_ln• f_check_errorallThe following new procedures and functions have been added for use withCommon Matching:• p_match_sorhschThis procedure retrieves data from the Student Common Matching MatchEntry Temporary Table (SOTCMME) (calls p_open_sorhsch_cv) and callsthe GOKCMPK package to perform the matching.• p_insert_sotcmmeThis procedure inserts high school data fields into the Student CommonMatching Match Entry Temporary Table (SOTCMME).• p_open_sorhsch_cvThis procedure (private to SAKMTCH) retrieves high school data from theStudent Common Matching Match Entry Temporary Table (SOTCMME).• f_sorhsch_existsThis function (private to SAKMTCH) checks to see if the SORHSCH row existsfor the incoming PIDM.Note: Since you can create rules to match on last name and SSN withoutincluding first name, the procedure p_match_ssn_ln has beeneliminated.January 2005 Student Release 7.0Confidential Release Guide 261

Section 9 Common Matching - TechnicalNew ScriptsNew Scriptsstvinfc1.sqlThis script is used to create the new STVINFC_CMSC_CODE column on STVINFC.STVINFC_CMSC_CODEVARCHAR2(20)igorname70.sqlThis script is used to create the new entries in the GORNAME table and to migrateentries from the SORNAME table to the GORNAME table.Student Release 7.0 January 2005262 Release Guide Confidential

Section 10 APIs - TechnicalAPI DisclaimerSection 10APIs - TechnicalThis enhancement is new for Release 7.0.API DisclaimerWarning: Please be advised that several APIs are currently intended to only supportinternal operations.To ensure data integrity, these APIs are not supported when called byexternal applications or interfaces to manipulate data. Therecommendation for external applications is to use message levelintegration to integrate with these entities in SCT Banner.The following APIs come under this disclaimer:• gb_stvterm• sb_course_registration• sb_enrollment• sb_facassignment• sb_learnercurricstatus• sp_gradingOverviewApplication Programming Interfaces (APIs) are delivered with Banner 7.0 tofacilitate the integration of SCT Banner with other applications on campus andsimplify code by encapsulating business logic in database packages. An API is acentral program that creates, updates, and deletes data. APIs also execute andvalidate business rules before inserting or updating information.Tables that work with the APIs have had USER_ID and DATA_SOURCE fields added tothem, if those fields did not already exist.January 2005 Student Release 7.0Confidential Release Guide 263

Section 10 APIs - TechnicalAPIs Used in Banner StudentAPIs Used in Banner StudentThe following tables and forms now use APIs to process data in Banner Student. Theform listed next to the table in this chart is the representative source used to buildthe API validation and business rules. The APIs replace the corresponding code inthe Banner forms.Note: Most of the APIs support create, update, and delete signatures.Exceptions, such as queries, are noted under Task Performed.Table Form API Object Name API Entity Name Task PerformedSARADAP SAAADMS sb_admissionsapplicationADMISSIONSAPPLICATIONMaintains admissionsapplicationsSCBCRSE SCACRSE sb_course COURSE Maintains basic course cataloginformationSFBETRM SFAREGS sb_enrollment ENROLLMENT Maintains learner enrollmentstatusSFRSTCR SFAREGS sb_course_registrationREGISTRATIONQueries student courseregistration recordsSFRSTCR N/A sp_grading GRADING Supports the existing midtermand final grade exchangebetween WebCT and BannerSGBSTDN SGASTDN sb_learner LEARNER Maintains learner informationSHRDGMR SHADEGR sb_learneroutcome LEARNEROUTCOME Maintains program outcome,degree, and award informationSIBINST SIAINST sb_faculty FACULTY Maintains faculty member andadvisor informationSIRASGN SIAASGN sb_facassignment FACULTYASSIGNMENT Maintains course assignmentsfor a faculty member or advisorSLRBMAP SLARMAP sb_roompreference ROOMPREFERENCE Maintains dorm room andmeal plan applicationsSLRMASG SLAMASG sb_mealassignment MEALASSIGNMENT Maintains meal assignmentsSLRPASG SLAPASG sb_phoneassignmentPHONEASSIGNMENTMaintains telephoneassignmentsSLRRMAT SLARMAT sb_roommate ROOMMATE Maintains roommateapplicationsStudent Release 7.0 January 2005264 Release Guide Confidential

Section 10 APIs - TechnicalAPIs Used in Banner StudentTable Form API Object Name API Entity Name Task PerformedSOBCACT SORCACT sb_learnercurricstatusLEARNERCURRICSTATUSMaintains learner curriculumactivity and status rulesSOBLMOD SOACTRL sb_learnermodule LEARNERMODULE Maintains learner module rulesSOBTERM SOATERM sb_term TERM Maintains controls for aspecific term - no createallowed, only update anddeleteSORLCUR SOQOLIB sb_curriculum CURRICULUM Maintains learner curriculuminformationSORLFOS SOQOLIB sb_fieldofstudy FIELDOFSTUDY Maintains learner curriculumfield of study informationSRBRECR SRARECR sb_recruit RECRUIT Maintains prospectiveapplicant informationSSBSECT SSASECT sb_section SECTION Maintains the schedule ofclasses as defined in the coursecatalogSARADAP APIProduct Entity Filename Object TableStudent sb_admissionsapplication sokb_admissions0.sqlsokb_admissions1.sqlsokb_admissions_r0.sqlsokb_admissions_r1.sqlsokb_admissions_strg0.sqlsokb_admissions_strg1.sqlsaaadms.fmbsaadcbt.fmbsaadcrv.fmbsaaquik.fmbsaarrat.fmbsoahsch.fmbsoapcol.fmbsoatest.fmbsapamal.pcsakchkb.sqlsakl010.sqlsakmods.sqlsakqadm.sqlSARADAPDescription: This package provides the common business interface for theAdmissions Application API (sb_admissionsapplication).A person can have many applications for admissions to an institution. Internalidentification number, term code, and application number are the keys for eachapplication.January 2005 Student Release 7.0Confidential Release Guide 265

Section 10 APIs - TechnicalAPIs Used in Banner StudentStarting with Banner 7.0, all curriculum and field of study data are maintained onthe SORLCUR and SORLFOS tables (sb_curriculum API and sb_fieldofstudyAPI). When an application record is created, a primary curriculum and primarymajor field of study must also be created. At the conclusion of the curriculum andfield of study insert, the primary and secondary curriculum data is backfilled to thecurriculum on the application record.SCBCRSE APIProduct Entity Filename Object TableStudent sb_course sokb_course0.sqlsokb_course1.sqlsokb_course_rules0.sqlsokb_course_rules1.sqlsokb_course_strg0.sqlsokb_course_strg1.sqlscabase.fmbscacrse.fmbscapreq.fmbSCBCRSEDescription: This package provides the common business interface for the CourseAPI (sb_course).Course records are created by subject code, course number, and effective term andmust exist before course sections can be created for registration purposes. Theeffective term value of '000000' has a special meaning that represents the beginningof time. Effective terms should always be populated with codes that are strictlynumeric, to reflect the correct chronological sequence for building the coursecatalog and associated sections for registration terms within academic years.Upon initial creation of a course record for a particular subject code and coursenumber, a course base maintenance record is created (SCBCRKY), using theeffective term from the course record as the start term for the course basemaintenance record. New course records for the same subject code and coursenumber may then be created only for effective terms that are greater than the startterm of the course base maintenance record.If course information needs to be updated for a term that does not match theeffective term of any existing course records, a new course record with theappropriate effective term must be created.Course records may not be deleted if section records exist for the particular subjectcode and course number, within the effective term range. If no section records existwithin the effective term range of the course record, the record may be deleted,unless it is the initial course record that was created (that is, the one with the lowesteffective term). The initial course record may only be deleted via the Course BaseMaintenance Form (SCABASE).At least one level code, grading mode code, and schedule type code must beprovided when creating a new course record.Student Release 7.0 January 2005266 Release Guide Confidential

Section 10 APIs - TechnicalAPIs Used in Banner StudentSFBETRM APIProduct Entity Filename Object TableStudent sb_enrollment sokb_enrollment0.sqlsokb_enrollment1.sqlsokb_enrollment_r0.sqlsokb_enrollment_r1.sqlsokb_enrollment_s0.sqlsokb_enrollment_s1.sqlsfamass.fmbsfaregs.fmbtsaspay.fmbsfpfreq.pcsfpregs.pcsfrrnop.pcsfrtmst.pcshrastd.pctsrcbil.pctsrtbil.pcbwsklib1.sqlbwlkfsf1.sqlsfkfees.sqlsfkmods.sqlshkpre1.sqlSFBETRMDescription: This package provides the common business interface for theEnrollment API (sb_enrollment).One enrollment record for each student per term (on the SFBETRM table) isrequired to support the course registration process.A number of conditions will prevent a student from enrolling and registering forclasses. A student will not be permitted to enroll if one or more of the followingconditions is true:• The person is not a student.• A hold that prevents registration is currently active.• The student's status does not allow registration.• The enrollment date is not between the start and end dates for the enrollmentstatus rule.• The enrollment status prevents registration.• The combined academic standing prevents registration.• The combined academic standing override prevents registration.• The end of term academic standing prevents registration.• The academic standing override prevents registration.Depending on rules specific to each institution, creating, updating, or deletingenrollment records may impact tuition and fee assessment. Batch fee assessment willprocess and update any outstanding adjustments to tuition and fees that may beappropriate. Also, multiple rules may exist that would default the enrollmentmaximum hours credit hours for registration.January 2005 Student Release 7.0Confidential Release Guide 267

Section 10 APIs - TechnicalAPIs Used in Banner StudentManual updates to default values override previous default values. If manuallyupdated, any future changes that are needed also require manual adjustment withone exception. Calculation of academic standing includes an option to updateenrollment maximum hours for a future term.Enrollment records may not be deleted if course registration exists for the term.Note: For the current release, the Create, Update, and Delete API calls are notsupported.SFRSTCR APIProduct Entity Filename Object TableStudent sb_course_registration sokb_course_reg0.sqlsokb_course_reg1.sqlsokb_course_reg_r0.sqlsokb_course_reg_r1.sqlsokb_course_reg_s0.sqlsokb_course_reg_s1.sqlsfaregs.fmbSFRSTCRDescription: This package provides the common business interface for the CourseRegistration API (sb_course_registration).Course registration information includes the details of the current status of eachstudent enrollment in a course section. Student course enrollment informationincludes the course registration number (CRN), course registration status (such asregistered, dropped, audit), status date, number of credit and billing hours, courselevel, and grading mode, as well as indicators to show if overrides were granted forany of the registration errors that may have been encountered during theregistration process. In addition, midterm and final grades are posted to courseregistration records that are gradable.Course registration information is used in several business processes and functions,including display of student schedule information, calculation of studentenrollment time status, fee assessment and refunding calculations, enrollmentverification processing, and (CAPP) compliance processing.Course registration always reflects the most current information for a student'sregistration in a specific course for a term. The complete audit trail of courseenrollment changes is captured and stored in the audit table SFRSTCA. Courseregistration information is processed from the following sources based on businessrules established by each institution:• Banner Student Registration module course administrative processing• Student Self-Service and Faculty and Advisor Self-ServiceStudent Release 7.0 January 2005268 Release Guide Confidential

Section 10 APIs - TechnicalAPIs Used in Banner Student• Banner Voice Response• Course Request and Scheduling batch processingFor the current release the API supports only the Query signature. The Insert,Update, and Delete signatures and not supported. Any call to the Insert, Update,and Delete signature will result in an error message. The API call is not supportedfor the current release.SGBSTDN APIProduct Entity Filename Object TableStudent sb_learner sokb_learner0.sqlsokb_learner1.sqlsokb_learner_rules0.sqlsokb_learner_rules1.sqlsokb_learner_strg0.sqlsokb_learner_strg1.sqlsaadcbt.fmbsaadcrv.fmbsaaquik.fmbsakmods.sqlsfaregs.fmbsgastdn.fmbsgpblck.pcsgpstdn.pcshrdegs.pcshrtype.pcbwskxmis.sqlSGBSTDNDescription: This package provides the common business interface for the LearnerAPI (sb_learner).The learner record is created during admissions and is required for registration.Once the student registers for courses, data that impacts fee assessment, courseprerequisites, or restrictions can be updated only on SFAREGS.Starting with Banner 7.0, all curriculum and field of study data are maintained onthe tables SORLCUR and SORLFOS (sb_curriculum API and sb_fieldofstudyAPI). When a learner record is created, a primary curriculum and primary majorfield of study must also be created. At the conclusion of the curriculum and field ofstudy insert, the primary and secondary curriculum data is backfilled to thecurriculum on the learner record.January 2005 Student Release 7.0Confidential Release Guide 269

Section 10 APIs - TechnicalAPIs Used in Banner StudentSHRDGMR APIProduct Entity Filename Object TableStudent sb_learneroutcome sokb_learneroutcome0.sqlsokb_learneroutcome1.sqlsokb_learner_outcm_r0.sqlsokb_learner_outcm_r1.sqlsokb_learner_outcm_s0.sqlsokb_learner_outcm_s1.sqlshadegr.fmbshamcat.fmbshamdeg.fmbshamdip.fmbshrdegs.pcshrtype.pcshkmods.sqlshkrols.sqlSHRDGMRDescription: This package provides the common business interface for the LearnerOutcome API (sb_learneroutcome).The learner outcome record is created when courses are rolled to academic historyafter begin graded. Starting with Banner 7.0, the Roll to Academic History Indicatorhas been moved from the learner record (SGBSTDN) to the curriculum base table(SORLCUR). New outcome records are created for a learner if the college, degree,level, and program are different on the outcome curriculum or if the outcome hasbeen awarded.Starting with Banner 7.0, all curriculum and field of study data are maintained onthe tables SORLCUR and SORLFOS (sb_curriculum API and sb_fieldofstudyAPI). When a learner outcome record is created, a primary curriculum and primarymajor field of study must also be created. At the conclusion of the curriculum andfield of study insert, the primary and secondary curriculum data is backfilled to thecurriculum on the learner outcome record.SIBINST APIProduct Entity Filename Object TableStudent sb_faculty sokb_faculty0.sqlsokb_faculty1.sqlsokb_faculty_rules0.sqlsokb_faculty_rules1.sqlsokb_faculty_strg0.sqlsokb_faculty_strg1.sqlsiainst.fmbSIBINSTDescription: This package provides the common business interface for the FacultyAPI (sb_faculty).Faculty information defines the persons who serve as instructors and advisors. Aperson record must exist before a faculty/advisor record can be created.Student Release 7.0 January 2005270 Release Guide Confidential

Section 10 APIs - TechnicalAPIs Used in Banner StudentFaculty and advisor information is effective term-based. Faculty information can bevalid over multiple terms. New effective terms are created to reflect changes infaculty status and status date, availability as a instructor (faculty) and/or advisor,category, staff type, and workload rule. Faculty and advisor processing logic willreturn the maximum effective term record that is less than or equal to theprocessing term if there is no exact match on term.A faculty member can be both an instructor and an advisor. The Faculty (Indicator)is set to Y to allow instructional and non-instructional assignments for the term. Ifno instructional assignments are permitted, the Faculty (Indicator) is blank (NULL).The Advisor (Indicator) is set to Y to allow assignment as an advisor for the term. Ifno advising assignments are permitted, the Advisor (Indicator) is blank (NULL).Instructors must have an active status to be given instructional and non-instructionalassignments for the term. Instructor status cannot be changed to inactive for theterm if instructional and/or non-instructional assignments exist. Active status isdetermined based on the setting of the Active (Indicator) for the Faculty StatusCode Validation Form (STVFCST).Two data items within the faculty table (SIBINST) are no longer in use. TheContract Type (SIBINST_FCNT_CODE) and Contract Rules (SIBINST_CNTR_CODE)information are recorded on a different table (SIRICNT). The SIRICNT table isused in contract processing.SIRASGN APIProduct Entity Filename Object TableStudent sb_facassignment sokb_fac_assign0.sqlsokb_fac_assign1.sqlsokb_fac_assign_r0.sqlsokb_fac_assign_r1.sqlsokb_fac_assign_strg0.sqlsokb_fac_assign_strg1.sqlsiaasgn.fmbssasect.fmbsipasgn.pcsspschd.pcssrroll.pcSIRASGNDescription: This package provides the common business interface for the FacultyAssignment API (sb_facassignment).Faculty assignments track instructional responsibilities for valid course sections.Only active faculty for the term specified may be assigned to sections. Themandatory fields are ID, Term, CRN, Category, Percent Responsibility, andPercentage of Session.• The CRN value must be a valid section for the term specified.• Percent Responsibility and Percentage of Session values must be between 0and 100.• Other control values for a faculty assignment exist.January 2005 Student Release 7.0Confidential Release Guide 271

Section 10 APIs - TechnicalAPIs Used in Banner Student• The Override Conflicts (Indicator) can be NULL or O.• The Primary Instructor (Indicator) can be NULL or Y.• A valid CRN can only have one primary instructor.• The Workload value must be between 0 and 999999.999.When a new faculty member is assigned to a CRN, some values are defaulted. Thevalues for the Contract Type, Category, Calculated Workload, and PrimaryInstructor will be defaulted in. If the Position Number and Position Number Suffixfields are entered and the Banner Human Resources system is installed, these valuesmust indicate a valid employee job.An update to a faculty assignment is restricted to certain fields. Workload, PercentResponsibility, Percentage of Session, Contract Type, Position Number, andPosition Number Suffix can be updated.You can only delete a primary faculty assignment record if no other records exist.SLBRMAP APIProduct Entity Filename Object TableStudent sb_roompreference sokb_room_pref0.sqlsokb_room_pref1.sqlsokb_room_pref_rules0.sqlsokb_room_pref_rules1.sqlsokb_room_pref_strg0.sqlsokb_room_pref_strg1.sqlslarmap.fmbslphous.pcSLBRMAPDescription: This package provides the common business interface for the RoomPreference API (sb_roompreference).SLRMASG APIProduct Entity Filename Object TableStudent sb_mealassignment sokb_meal_assign0.sqlsokb_meal_assign1.sqlsokb_meal_assign_r0.sqlsokb_meal_assign_r1.sqlsokb_meal_assign_s0.sqlsokb_meal_assign_s1.sqlslamasg.fmbtsaspay.fmbslphous.pcslrroll.pctsrcbil.pctsrtbil.pcslkmod1.sqlSLRMASGDescription: This package provides the common business interface for the MealAssignment API (sb_mealassignment).Student Release 7.0 January 2005272 Release Guide Confidential

Section 10 APIs - TechnicalAPIs Used in Banner StudentSLRPASG APIProduct Entity Filename Object TableStudent sb_phoneassignment sokb_phone_assign0.sqlsokb_phone_assign1.sqlsokb_phone_assign_r0.sqlsokb_phone_assign_r1.sqlsokb_phone_assign_s0.sqlsokb_phone_assign_s1.sqlslapasg.fmbtsaspay.fmbslphous.pctsrcbil.pctsrtbil.pcSLRPASGDescription: This package provides the common business interface for the PhoneAssignment API (sb_phoneassignment).SLRRMAT APIProduct Entity Filename Object TableStudent sb_roommate sokb_roommate0.sqlsokb_roommate1.sqlsokb_roommate_rules0.sqlsokb_roommate_rles1.sqlsokb_roommate_strg0.sqlsokb_roommate_strg1.sqlslarmat.fmbslphous.pcSLRRMATDescription: This package provides the common business interface for the RoommateAPI (sb_roommate).SOBCACT APIProduct Entity Filename Object TableStudent sb_learnercurricstatus sokb_learnercurrst0.sqlsokb_learnercurrst1.sqlsokb_learnercurrst_r0.sqlsokb_learnercurrst_r1.sqlsokb_learnercurrst_s0.sqlsokb_learnercurrst_s1.sqlsorcact.fmbSOBCACTDescription: This package provides the common business interface for the LearnerCurriculum Status API (sb_learnercurricstatus).SOBCACT is the rules table used to indicate which learner curriculum status codesare active and whether they are system-required.January 2005 Student Release 7.0Confidential Release Guide 273

Section 10 APIs - TechnicalAPIs Used in Banner StudentSOBLMOD APIProduct Entity Filename Object TableStudent sb_learnermodule sokb_learner_mod0.sqlsokb_learner_mod1.sqlsokb_learner_mod_r0.sqlsokb_learner_mod_r1.sqlsokb_learner_mod_s0.sqlsokb_learner_mod_s1.sqlsoactrl.fmbSOBLMODDescription: This package provides the common business interface for the LearnerModule API (sb_learnermodule).The SOBLMOD table is used to store the number of curricula, majors, minors, andconcentrations by module (Recruiting, Admissions, Student, Academic History)that are allowed to be entered.Seed data will be delivered with the existing limitations. This table can be updated,but the Bridge API will still only backfill data with the delivered maximums in theinitial release.SOBTERM APIProduct Entity Filename Object TableStudent sb_term sokb_term0.sqlsokb_term1.sqlsokb_term_r0.sqlsokb_term_r1.sqlsokb_term_s0.sqlsokb_term_s1.sqlsoaterm.fmbssasect.fmbssrroll.pcSOBTERMDescription: This package provides the common business interface for the Term API(sb_term).One record for each term is required to support high level controls for severalbusiness functions and processes associated with registration, grading, feeassessment, and CAPP for administrative and self-service users.A valid term code must exist (on the STVTERM table) before the base term recordcan be created.Student Release 7.0 January 2005274 Release Guide Confidential

Section 10 APIs - TechnicalAPIs Used in Banner StudentThe Original Charge Cutoff Date value must fall between the start and end datespecified for the term code.The majority of these indicators are set to Y to turn themon and N to turn them off. An exception to the indicators is registration errorchecking. A select group of the registration error checks allow either a fatal (F) orno check (N) setting. A different group allows a warning (W) in addition to fatal andno check.An update to the base term record is restricted in a specific circumstance.The CRN Starting Sequence Number (the one-up number) can never be updatedto a lower value. This is because the CRN Starting Sequence Number value is usedto generate a unique CRN for new course sections as they are added for the termeither online or through the process of rolling sections from an existing term to anew term.A base term record cannot be deleted if course sections have been created for theterm. If no sections exist, all part-of-term records must be deleted before the termcontrol itself can be deleted.When a new base term record is created, a part-of-term one record must also becreated (on the SOBPTRM table). To facilitate this rule, the create signature is notexposed for this business entity. A new base term record must be created. Any callto the create signature will return an error message. The API call is not supportedfor the current release.January 2005 Student Release 7.0Confidential Release Guide 275

Section 10 APIs - TechnicalAPIs Used in Banner StudentSORLCUR APIProduct Entity Filename Object TableStudent sb_curriculum sokb_curriculum0.sqlsokb_curriculum1.sqlsokb_curriculum_r0.sqlsokb_curriculum_r1.sqlsokb_curriculum_s0.sqlsokb_curriculum_s1.sqlsoqolib.fmbGroup objectreferenced in:saaadms.fmbsaaquik.fmbsraquik.fmbsrarecr.fmbsfaregs.fmbshadegr.fmbsgastdn.fmbsoilcur.fmbAlso:soplccv.pcbwskxmis.sqlsakl010.sqlsakmods.sqlshkrols.sqlsoklcur.sqlsokb_learner1.sqlsokb_learneroutcome1.sqlsokb_recruit1.sqlsokb_admissions1.sqlSORLCURDescription: This package provides the common business interface for the LearnerBase Curriculum API (sb_curriculum).This API works with the Concurrent Curricula foundation. In releases before 7.0,curriculum data resided in the Admissions table SARADAP, Recruiting tableSRBRECR, General Student (Learner) table SGBSTDN, and Academic History(Learner Outcome) table SHRDGMR. Beginning with Release 7.0, curriculum dataresides in the Learner Curricula Table (SORLCUR) and the Field of Study Table(SORLFOS).All processes that update curriculum have the following logic.1. Convert existing curriculum data to the new foundation. This is done with thefunctions:• soklcur.f_convert_recruit• soklcur.f_convert_applicant• soklcur.f_convert_learner• soklcur.f_convert_outcome2. Insert a module record (tables SRBRECR, SARADAP, SGBSTDN, orSHRDGMR).Student Release 7.0 January 2005276 Release Guide Confidential

Section 10 APIs - TechnicalAPIs Used in Banner Student3. Insert a primary curriculum (table SORLCUR), and then insert at least onemajor (table SORLFOS).4. Backfill curriculum data from the base curriculum and fields of study to theoriginal curriculum columns in Recruiting (SRBRECR), Admissions(SARADAP), Learner (SGBSTDN), and Learner Outcome (SHRDGMR).The backfill procedure is soklcur.p_backload_cur(p_lmod,p_term_code, p_keyseqno, p_pidm).The method of backfilling ensures that reporting and other processing will not beinterrupted during the implementation of the curriculum tables in Banner Studentand Financial Aid.There is no update API for the curriculum and field of study entities. Themethodology is to employ non-destructive updates. To make a change, the user mustduplicate a curriculum record and make the changes on the newly inserted record.This preserves an audit trail of all changes to the curriculum.SORLFOS APIProduct Entity Filename Object TableStudent sb_fieldofstudy sokb_fieldstudy0.sqlsokb_fieldstudy.sqlsokb_fieldstudy_r0.sqlsokb_fieldstudy_r1.sqlsokb_fieldstudy_s0.sqlsokb_fieldstudy_s1.sqlsoqolib.fmbGroup objectreferenced in:saaadms.fmbsaaquik.fmbsraquik.fmbsrarecr.fmbsfaregs.fmbshadegr.fmbsgastdn.fmbsoilcur.fmbAlso:soplccv.pcbwskxmis.sqlsakl010.sqlsakmods.sqlshkrols.sqlsoklcur.sqlsokb_learner1.sqlsokb_learneroutcome1.sqlsokb_recruit1.sqlsokb_admissions1.sqlSORLFOSJanuary 2005 Student Release 7.0Confidential Release Guide 277

Section 10 APIs - TechnicalAPIs Used in Banner StudentDescription: This package provides the common business interface for the Field ofStudy API (sb_fieldofstudy).The field of study is part of the learner curriculum and is the major, minor, orconcentration. The field of study table (SORLFOS) is the child table of thecurriculum table (SORLCUR).SRBRECR APIProduct Entity Filename Object TableStudent sb_recruit sokb_recruit0.sqlsokb_recruit.sqlsokb_recruit_rules0.sqlsokb_recruit_rules1.sqlsokb_recruit_strg0.sqlsokb_recruit_strg1.sqlsaaquik.fmbsrarecr.fmbrcrtp05.pcsrrinqr.pcsakmods.sqlsrkprel.sqlSRBRECRDescription: This package provides the common business interface for the RecruitAPI (sb_recruit).A person may have many recruiting records. However, each recruiting record isuniquely defined by the internal identification number, term code, andadministrative sequence number.The Selected (Indicator) defines which record is the preferred recruiting record forthe term. Only one recruiting record per term may have the Selected (Indicator) setto Y.Starting with Banner 7.0, all curriculum and field of study data are maintained onthe SORLCUR and SORLFOS tables (sb_curriculum API and sb_fieldofstudyAPI). When a recruiting record is created, a primary curriculum and primary majorfield of study must also be created. At the conclusion of the curriculum and field ofstudy insert, the primary and secondary curriculum data are backfilled to thecurriculum on the recruit record.Student Release 7.0 January 2005278 Release Guide Confidential

Section 10 APIs - TechnicalAPIs Used in Banner StudentSSBSECT APIProduct Entity Filename Object TableStudent sb_section sokb_section0.sqlsokb_section1.sqlsokb_section_r0.sqlsokb_section_r1.sqlsokb_section_s0.sqlsokb_section_s1.sqlssaaccl.fmbssasect.fmbshagcom.fmbsfpfreq.pcsfpwait.pcsfrrnop.pcsspschd.pcssrroll.pcsskmods.sqlSSBSECTDescription: This package provides the common business interface for the SectionAPI (sb_section).Section records are created by term, subject code, and course number. They areassigned a system-generated Course Reference Number (CRN), based on the valueof the CRN one-up number in the Term Base Table (SOBTERM). The sequencenumber attached to the section, also referred to as the section number, must beunique for the term, subject, and course number, unless the sequence number is 0.Any number of sections may exist with a sequence number of 0 for the same term,subject code, and course number.To create a new section, the subject code and course number must exist in theCourse Base Maintenance Table (SCBCRKY), where the term code of the section isbetween the start term and the end term of the course base maintenance record.The title remains NULL on the section record unless it differs from the title on thecourse general information base record (SCBCRSE) for the subject code, coursenumber, and effective term.Campus restrictions defined in the Course Campus Restriction Repeating Table(SCRRCMP) or term restrictions defined in the Course Term Restriction RepeatingTable (SCRRTRM) may prohibit a section from being created. Also, a user may berestricted from creating sections for certain campuses, based on entries in theCampus Security Table (SOBPROF).Two types of section records, traditional and open learning, may be created.Traditional sections are term-based and require all part-of-term information. Openlearning sections, while created for a particular term, are date-based. The learnermay register within a specified date range (between the registration from date andthe registration to date) and may begin study with a specified date range (betweenthe learner start from date and the learner start to date). The maximum amount oftime the learner has to complete the course is defined by the number of units andthe duration code (e.g., 10 WEEKS).January 2005 Student Release 7.0Confidential Release Guide 279

Section 10 APIs - TechnicalAPIs Used in Banner General With Student Forms and TablesThe institution may define a number of extensions for an open learning section.The learner may apply for any number of extensions, within the institution-definedlimit, if they are unable to complete the course in the allocated amount of time. Fora traditional section, extensions are not applicable, and the number of extensionsshould be set to 0.Updates to section information may be restricted if enrollment exists. If enrollmentexists, updates are not permitted to the schedule type or instructional method,because those values can be included in tuition and fee assessment calculation rules.The part-of-term values may not be changed if enrollment exists or if the section wasoriginally created as an open learning section.Sections may not be deleted if enrollment exists. The maximum enrollment countand the waitlist capacity are determined by the institution. (Waitlisting is used onlyfor traditional sections.) The actual enrollment count, the number of seatsavailable, the waitlist count, and the waitlist available are updated by the Registrationmodule and should not be updated by any other means.APIs Used in Banner General With Student Forms and TablesThe following Student tables and forms now use APIs to process data in BannerGeneral and Banner Student.Table Form API Object Name API Entity Name Task PerformedSLBBLDG SLABLDG gb_bldgdefinition BLDGDEFINITION Maintains buildinginformationSLBRDEF SLARDEF gb_roomdefinition ROOMDEFINITION Maintains room information bybuildingSLRRASG SLARASG gb_roomassignment ROOMASSIGNMENT Maintains dorm roomassignmentsSPBPERS SPAPERS gb_bio BIO Maintains biographic/demographic information foran individualSPRADDR SPAIDEN gb_address ADDRESS Maintains address informationSPREMRG SPAEMRG gb_emergency_contactEMERGENCY_CONTACTMaintains emergency contactinformation for an individualSPRHOLD SOAHOLD gb_hold HOLD Places or removes holds on anaccountStudent Release 7.0 January 2005280 Release Guide Confidential

Section 10 APIs - TechnicalChanged TablesTable Form API Object Name API Entity Name Task PerformedSPRIDEN SPAIDEN gb_identification IDENTIFICATION Maintains person and nonpersonbiographic/demographic informationSPRTELE SPATELE gb_telephone TELEPHONE Maintains telephoneinformationSSRMEET SSASECT gb_classtimes CLASSTIMES Maintains section and eventmeeting timesSTVTERM STVTERM gb_stvterm STVTERM Queries term validationinformationChanged TablesA number of tables were modified for use with APIs. Two fields were added to eachtable: one for DATA_ORIGIN and one for USER_ID. For example, on the SARADAPtable the fields appear as:SARADAP_DATA_ORIGINSARADAP_USER_IDVARCHAR2(30)VARCHAR2(30)The DATA_ORIGIN and USER_ID fields have been added to the following tables:• SARADAP• SCBCRSE• SGBSTDN• SHRDGMR• SHRTCKG• SIBINST• SIRASGN• SLBBLDG• SLBRMAP• SLRMASG• SLRPASG• SLRRASG• SLRRDEF• SLRRMAT• SOBTERM• SRBRECRJanuary 2005 Student Release 7.0Confidential Release Guide 281

Section 10 APIs - TechnicalChanged Tables• SSBSECT• SSRMEETNote: SPRTELE is also used with APIs and already contains both fields.Some tables already contained a USER or USER_ID field, so only the DATA_ORIGINfield was added.The DATA_ORIGIN field has been added to the following tables:• SFBETRM• SFRAREG• SFRSTCA• SFRSTCR• SPRHOLDStudent Release 7.0 January 2005282 Release Guide Confidential

Section 11 Improved Drop/Withdrawal Processing (Defect 49132) - TechnicalNew TableSection 11Improved Drop/Withdrawal Processing(Defect 49132) - TechnicalThis enhancement was included in Release 6.1 and contained fixes related to Defect49132.This enhancement includes modifications and updates for baseline BannerStudent, as well as Faculty and Advisors Self-Service, Student Self-Service, and VoiceResponse. Please refer to the release guides for these products for additionalinformation.New TableRegistration Administrative Message Temporary Table (SFTRGAM)This temporary table is used to hold administrative error messages during Self-Service and Voice Response registration processing.SFTRGAM_PIDM NOT NULL NUMBER(8);SFTRGAM_TERM_CODE NOT NULL VARCHAR2(6);SFTRGAM_CRN NOT NULL VARCHAR2(5);SFTRGAM_MESSAGE NOT NULL VARCHAR2(25);Changed TablesCourse Registration Status Code Validation Table (STVRSTS)The comment for the STVRSTS_VOICE_TYPE column has been modified to read asfollows: “The Status Code Type used in Voice Response, Web Registration, andBaseline registration (SFAREGS). Valid values are R - Registered (Enrolled), D -Dropped, L - Waitlisted, W - Withdrawn status.”January 2005 Student Release 7.0Confidential Release Guide 283

Section 11 Improved Drop/Withdrawal Processing (Defect 49132) - TechnicalNew ProceduresRegistration Temporary Table (SFTREGS)These columns have also been added to the table:SFTREGS_HOLD_RSTS_CODESFTREGS_HOLD_RSTS_DATESFTREGS_HOLD_RSTS_TYPESFTREGS_HOLD_CREDITSSFTREGS_HOLD_GRDE_CODESFTREGS_HOLD_MESSAGESFTREGS_HOLD_ERROR_FLAGSFTREGS_HOLD_LEVL_CODESFTREGS_HOLD_GMOD_CODESFTREGS_ERROR_LINKVARCHAR2(2);DATE;VARCHAR2(1);NUMBER(7,3);VARCHAR2(6);VARCHAR2(25);VARCHAR2(1);VARCHAR2(2);VARCHAR2(1);NUMBER;All columns except for SFTREGS_ERROR_LINK will be initialized when the SFTREGStable is initially loaded. These hold fields are used by Self-Service and VoiceResponse to reinstate the initial values if a drop code cannot be found for a course,or if the student chooses not to drop the course when the AUTODROP rule is set toC.The SFTREGS_ERROR_LINK field is used to link courses in error to courses that thestudent is requesting to drop during a Self-Service or Voice Response registrationsession. SFAREGS does not use these fields.Student Course Registration Archive Table (SFRSTCA)The SFRSTCA_SOURCE_CDE column has been added to the table to support the newSource field on SFASTCA.New Proceduressfkedit.p_connected_group_editsThis procedure is called from Self-Service (via sfkedit.p_web_group_edits) andVoice Response when drops are processed. It is a subset of skedit.p_ group_editsand only performs checking for pre-requisites, co-requisites, and linked courses.sfkedit.p_group_editsThis procedure is called from SFAREGS and Voice Response when all group editsare desired. It is also called from sfkedit.p_web_group_edits.Student Release 7.0 January 2005284 Release Guide Confidential

Section 11 Improved Drop/Withdrawal Processing (Defect 49132) - TechnicalNew Proceduressfkedit.p_update_regsThis procedure performs the final capacity check and updates the base tables.sfkedit.p_web_group_editsThis procedure processes group edits in Self-Service and also updates droppedrecords on SFTREGS.sfkmods.p_admin_msgsThis procedure is called from sfkfunc.f_registration_access after records areloaded to SFTREGS. It executes sfkedit.p_group_edits andsfkfunc.p_check_appr, and also loads fatal errors into SFTRGAM.sfkmods.p_delete_sftrgamThis procedure deletes all rows from SFTRGAM for pidm and term.sfkmods.p_insert_sftrgamThis procedure inserts rows into SFTRGAM for pidm, term, and CRN.sfkmods.p_insert_sftrgam_cappThis procedure inserts rows into SFTRGAM for pidm, term, and CRN equal to00000, if a CAPP error occurs.sfkmods.p_reset_sftregs_fieldsThis procedure is called from Self-Service and Voice Response if a drop code cannotbe found for a course or if a student replies N when asked to confirm theAUTODROP rule.Two updates are performed. The first update sets the SFTREGS_REC_STAT field to R,so that an SFRSTCA record is created. The second update sets theSFTREGS_REC_STAT field back to Q, and no SFRSTCA record is created.sfkmods.p_set_sftregs_error_linkThis procedure updates SFTREGS_ERROR_LINK when the student's drop requestcauses errors on connected courses.January 2005 Student Release 7.0Confidential Release Guide 285

Section 11 Improved Drop/Withdrawal Processing (Defect 49132) - TechnicalChanged Proceduressfkmods.p_swap_rsts_codesThis procedure is called from sfkedit.p_web_group_edits to enable processingto look at each drop request independently, in order to identify connected coursesthat are going into error due to the drop request.Changed ProceduresThe following procedures have been modified for the new drop error processing:sfkfunc.p_check_corq_sftregsThis procedure has been modified to handle administrative error processingcorrectly. When checking for administrative errors, processing should notimmediately flag connected courses that go into error, because only trueadministrative errors are to be written to SFTRGAM.During regular registration error checking, a course that exists in SFTRGAM forpidm, term, and CRN with the identical error message is not flagged as an error.Courses with a registration status type of D or W on SFTREGS are excluded whenexisting registrations are evaluated, just as courses with an error flag of F, D, or Lhave always been excluded.sfkfunc.p_check_dupl_sftregsThis procedure has been modified to handle administrative error processingcorrectly. When checking for administrative errors, processing should notimmediately flag connected courses that go into error, because only trueadministrative errors are to be written to SFTRGAM.During regular registration error checking, a course that exists in SFTRGAM forpidm, term, and CRN with the identical error message is not flagged as an error.Courses with a registration status type of D or W on SFTREGS are excluded whenexisting registrations are evaluated, just as courses with an error flag of F, D, or Lhave always been excluded.sfkfunc.p_check_link_sftregsThis procedure has been modified to handle administrative error processingcorrectly. When checking for administrative errors, processing should notimmediately flag connected courses that go into error, because only trueadministrative errors are to be written to SFTRGAM.Student Release 7.0 January 2005286 Release Guide Confidential

Section 11 Improved Drop/Withdrawal Processing (Defect 49132) - TechnicalChanged ProceduresDuring regular registration error checking, a course that exists in SFTRGAM forpidm, term, and CRN with the identical error message is not flagged as an error.Courses with a registration status type of D or W on SFTREGS are excluded whenexisting registrations are evaluated, just as courses with an error flag of F, D, or Lhave always been excluded.sfkfunc.p_check_maxh_sftregsThis procedure has been modified to handle administrative error processingcorrectly. When checking for administrative errors, processing should notimmediately flag connected courses that go into error, because only trueadministrative errors are to be written to SFTRGAM.During regular registration error checking, a course that exists in SFTRGAM forpidm, term, and CRN with the identical error message is not flagged as an error.Courses with a registration status type of D or W on SFTREGS are excluded whenexisting registrations are evaluated, just as courses with an error flag of F, D, or Lhave always been excluded.sfkfunc.p_check_time_sftregsThis procedure has been modified to handle administrative error processingcorrectly. When checking for administrative errors, processing should notimmediately flag connected courses that go into error, because only trueadministrative errors are to be written to SFTRGAM.During regular registration error checking, a course that exists in SFTRGAM forpidm, term, and CRN with the identical error message is not flagged as an error.Courses with a registration status type of D or W on SFTREGS are excluded whenexisting registrations are evaluated, just as courses with an error flag of F, D, or Lhave always been excluded.sfkmods.p_insert_sftregs_from_stcrThis procedure has been modified to initialize new fields on SFTREGS.sfkpreq.p_open_all_courses_cThis procedure has been modified so that courses with a registration status type ofD or W on SFTREGS are excluded, just as courses with an error flag of F, D, or L onSFTREGS are excluded.January 2005 Student Release 7.0Confidential Release Guide 287

Section 11 Improved Drop/Withdrawal Processing (Defect 49132) - TechnicalObsolete Proceduresfkpreq.p_open_conc_courses_cThis procedure has been modified so that courses with a registration status type ofD or W on SFTREGS are excluded, just as courses with an error flag of F, D, or L onSFTREGS are excluded.sfkpreq.p_open_registration_cThis procedure has been modified so that courses with a registration status type ofD or W on SFTREGS are excluded, just as courses with an error flag of F, D, or L onSFTREGS are excluded.sfkpreq.p_prerequisitecheckThis procedure has been modified to pass the value of I from SFRRGAM when thereport is run for in-progress pre-requisites. It is set to N by sfkedit.p_group_edits(from both registration and SFRRGAM, if the report is run for all administrativeerrors). It is also set to N by sfkedit.p_connected_group_edits.sfkpreq.p_update_registration_msgThis procedure has been modified so that courses that exist in SFTRGAM for PIDM,Term, and CRN with the identical error message are excluded.Obsolete ProcedureThe following procedure is obsolete with Release 6.1.sfkedit.p_final_editThis procedure is no longer used in Student baseline, Self-Service, and VoiceResponse to perform group edits.• Baseline (SFAREGS) now uses sfkedit.p_group_edits andsfkedit.p_update_regs.• Self-Service now uses sfkedit.p_web_group_edits andsfkedit.p_update_regs.• Voice Response now uses sfkedit.p_group_edits andsfkedit.p_update_regs.For more information on this processing, please review the release guides for theSelf-Service and Voice Response products.Student Release 7.0 January 2005288 Release Guide Confidential

Section 11 Improved Drop/Withdrawal Processing (Defect 49132) - TechnicalNew FunctionsNew Functionssfkfunc.f_autodrop_settingThis function is called from Self-Service and Voice Response as needed and returnsthe GTVSDAX AUTODROP rule setting.sfkfunc.f_do_admindropThis function is called from Self-Service and Voice Response as needed and returnsa value of TRUE or FALSE based on the setting of the GTVSDAX ADMINDROPrule.sfkfunc.f_fatal_error_countThis function is called from sfkedit.p_group_edits,sfkedit.p_connected_group_edits, and sfkedit.p_update_regs. It returns acount of fatal errors on SFTREGS.sfkfunc.f_get_capp_tech_errorThis function returns a value of CAPP or PIPE when a CAPP technical error hasoccurred. It is called from Self-Service and Voice Response at beginning ofregistration session, after the call to sfkfunc.f_registration_access.sfkfunc.f_get_rsts_typeThis function returns the STVRSTS_VOICE_TYPE value for the student courseregistration status code. It is called from Self-Service whenever the student courseregistration status code is changed on an existing course.Changed Functionsfkfunc.f_registration_accessA new parameter, bypass_admin_in, has been added to the function. This is set toY by SFAREGS and by the Change Class Options page in Self-Service, so that the callto sfkmods.p_admin_msgs is bypassed.January 2005 Student Release 7.0Confidential Release Guide 289

Section 11 Improved Drop/Withdrawal Processing (Defect 49132) - TechnicalNew ScriptsUsing Add/Drop through Self-Service and Voice Response sets the parameter toNULL, so that administrative error messages are found and written to SFTRGAM atthe start of the registration session.New Scriptssinsproc.sqlThis script is used to populate the new values of DISPLAYHOLDS andDISPLAYTESTS on STVPROC.sinssdax.sqlThis script is used to populate the two new rules on GTVSDAX for ADMINDROPand AUTODROP. ADMINDROP will be delivered set to N. AUTODROP will bedelivered set to C.sinsvtab.sqlThis script is used to add the value STVTESC to the internal Web Display ValidationTables List (STVVTAB) on SOAWDSP, to allow test scores to display on the Web inFaculty and Advisors Self-Service.Changed Triggerssfttreg0.sqlThis database trigger has been modified to set the new columnSFRSTCA_SOURCE_CDE to a value of TEMP.sfttreg1.sqlThis database trigger has been modified to set the new columnSFRSTCA_SOURCE_CDE to a value of TEMP.Student Release 7.0 January 2005290 Release Guide Confidential

Section 11 Improved Drop/Withdrawal Processing (Defect 49132) - TechnicalChanged TriggersChanges have also been made so that audit records (SFRSTCA) are not created ifSFTREGS_REC_STAT is equal to D. This status is used by Self-Service to temporarilymark drop requests, so that drops may be stepped through, one-by-one.sfttreg2.sqlThis database trigger has been modified to set the new columnSFRSTCA_SOURCE_CDE to a value of TEMP.sftstcr0.sqlThis database trigger has been modified to set the new columnSFRSTCA_SOURCE_CDE to a value of BASE.sftstcr1.sqlThis database trigger has been modified to set the new columnSFRSTCA_SOURCE_CDE to a value of BASE.sftstcr2.sqlThis database trigger has been modified to set the new columnSFRSTCA_SOURCE_CDE to a value of BASE.New Cursorsfkcurs.drop_problems_cThis cursor is used by Self-Service Add/Drop to select pre-existing courses fromSFTREGS that have been flagged with fatal errors.Changed Cursorssfkcurs.scrgmodcThis cursor has been modified for Virtual Private Database compliance.January 2005 Student Release 7.0Confidential Release Guide 291

Section 11 Improved Drop/Withdrawal Processing (Defect 49132) - TechnicalNew Record Structuresfkcurs.scrlevlcThis cursor has been modified for Virtual Private Database compliance.Obsolete Cursorsfkcurs.rstsrowcThis cursor is obsolete as of Release 6.1. It has been replaced with thepackage.procedure bwckcoms.p_open_rstsrowc. Please see the Self-Servicerelease guides for more information.New Record Structuresfkcurs.drop_problems_recThis new record structure is used by the new cursor sfkcurs.drop_problems tostore registration records that may need to be dropped, due to the existence of fatalerrors, when the records have not otherwise been requested to be dropped. Theserecords are passed from procedure to procedure within the Self-Service code.New PLSQL Table Typesfkcurs.drop_problems_rec_tabtypeThis new table type is used to store multiple records of typesfkcurs.drop_problems_rec.Student Release 7.0 January 2005292 Release Guide Confidential

Section 11 Improved Drop/Withdrawal Processing (Defect 49132) - TechnicalChanged ViewChanged Viewsftregs_v.sqlThis view has been modified to include the new fields on SFTREGS when it selectsfields from that table.January 2005 Student Release 7.0Confidential Release Guide 293

Section 11 Improved Drop/Withdrawal Processing (Defect 49132) - TechnicalChanged ViewThis page intentionally left blankStudent Release 7.0 January 2005294 Release Guide Confidential

Section 12 Miscellaneous EnhancementsNew Banner Online HelpSection 12Miscellaneous EnhancementsNew Banner Online HelpRelease 7.0 features a new online help system which is not included as part of thestandard beta release. For information about how the system functions, refer to theBanner 7.0 Information Center on the SunGard SCT ActionWeb.Note: The Online Help button, Help Center link, and Online Help option fromthe Help pulldown menu are active for the beta release, but do not leadto any online help content. Online help content will be available inSpring 2005 via the ActionWeb.Changed Object NamesThe following objects have been renamed for this release.Object Old Name New NameSCATEXT College/Department Text Form College and Department Text FormSCAPREQSSAPREQCatalog Pre-requiste and Test Score RestrictionsFormSchedule Pre-requiste and Test ScoreRestrictions FormCatalog Prerequisite and Test Score RestrictionsFormSchedule Prerequisite and Test ScoreRestrictions FormSHAPCMP Pre Banner Summary Hours and GPA Form Pre-Banner Summary Hours and GPA FormSTVPWAV Pre-requisite Waiver Code Validation Form Prerequisite Waiver Code Validation FormSOASBGI Source/Background Institution Base Form Source or Background Institution Base FormSFRPINI Pre-requiste Pipe Initialization Process Compliance Listener Start Up ProcessSFRPIPE Pre-requiste Pipe Process Compliance Pipe ProcessJanuary 2005 Student Release 7.0Confidential Release Guide 295

Section 12 Miscellaneous EnhancementsNew Course Maintenance Form (SHATCKN)New Course Maintenance Form (SHATCKN)The new Course Maintenance Form (SHATCKN) replaces the three separate formsthat used to handle pre-catalog, catalog, and section-dependent coursemaintenance in Academic History. SHATCKN references the Institutional CourseTerm Maintenance Repeating Table (SHRTCKN).The Catalog-Dependent Course Maintenance Form (SHATCKC), the Pre-CatalogCourse Maintenance Form (SHATCKP), and the Section-Dependent CourseMaintenance Form (SHATCKS) are obsolete. SHATCKC, SHATCKP, and SHATCKSwere not on any menus in Banner Student.You can access SHATCKN from SHAINST and SHACRSE using course data for aterm, where you can change the course details, based upon how the course isvalidated. Validation still occurs using SCACRSE (Catalog), SSASECT (Schedulesection), or does not occur if the record contains Pre-Catalog (Pre-Banner)information.Data for new entries is pushed into course history (bypassing the need to register forand roll courses) using direct access in Banner. You cannot push data into historyfor a term unless a term header record already exists on SHAINST.Validation CheckingA new Validation Check field has been added to the Key Block. This field is used toindicate the level of validation to be performed using pulldown choices for: Schedule,Catalog, and Pre-Banner.When SHATCKN is called from SHAINST or SHACRSE, the new validationprocessing is set as follows:• If SHATCKS would have been called, (the course is based upon a section builtin SSASECT), the Validation Check field is set to Schedule.• If SHATCKC would have been called, (the course was entered with Catalogonly, and no section existed for that record), the Validation Check field is setto Catalog.• If SHATCKP would have been called, (the course was a pre-catalog entry anddid not reference either section or catalog information), the Validation Checkfield is set to Pre-Banner.Edit checking within the form is determined by the setting of the Validation Checkfield.Student Release 7.0 January 2005296 Release Guide Confidential

Section 12 Miscellaneous EnhancementsRPEs for Student• If you choose Schedule, then the same edit checking occurs that was previouslyperformed by SHATCKS.• If you choose Catalog, then the same edit checking occurs that was previouslyperformed by SHATCKC.• If you choose Pre-Banner, then the same edit checking occurs that waspreviously performed by SHATCKP.RPEs for StudentSFKEDIT,SFKFUN1,SFKFUNC(#32286)These packages have been modified to check waitlisted courses for time conflictswith registered courses using a new rule on GTVSDAX.• The procedure p_check_time_wl_sftregs has been added to SFKFUN1 andSFKFUNC, to be executed if the new rule is set to N.• SFKEDIT has been modified to call either sfkfunc.p_check_time_sftregsor sfkfunc.p_check_time_wl_sftregs, depending on the setting of the newrule.A new WLTIMECON rule has been added to GTVSDAX to allow you to specify whena course can be waitlisted if a registered course already exists in that time slot.• If this rule is set to Y, a course can be waitlisted, even if a registered class alreadyexists for that time slot.• If this rule is set to N, a course may not be waitlisted if a registered class alreadyexists for that time slot.External Code Internal Code Internal CodeSequence NumberInternal Code Group Description Activity DateN WLTIMECON NULL REGISTRATION Should waitlistedclasses recognize timeconflict errors?SysdateScript sinssdax1.sql is delivered by SunGard SCT to add this rule to GTVSDAX.Delivered in Release 6.2.SPVPERS (RPE #25499(This view has been modified to improve efficiency while doing a search by SSN onRCRSUSP or SOQMTCH. Delivered in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 297

Section 12 Miscellaneous EnhancementsTerm Code ValuesSMRCMPL (RPE #16955)Previously, if a requirement was defined using a subject code and course numberrange and/or a subject code, course number range, and a course attribute,compliance did not use courses that were defined in the catalog as equivalent tocourses that would satisfy the requirement. Modifications have been made to ensurethat compliance will now use courses and their attributes if they are defined asequivalents of those courses that would satisfy the requirement. Delivered in Release7.0.SOATERM(No RPE number)The Dynamic Schedule Term field has been renamed the Master Web Term Controlfield. Delivered in Release 7.0.SORNAME (RPE #34410)An initial set of seed data is being delivered with Release 6.1 for use in theSORNAME table and the First Name Translation Rules Form (SOANAME). Thedata is delivered in a new script, sinsname.sql. This allows you to create equivalentnames to be used with the match process, such as Rob equals Robert, whenmatching is taking place. Delivered in Release 6.1.Term Code ValuesAs some institutions use alpha characters in their term codes, program code hasbeen removed from objects where the term code was converted to a numeric value.This will prevent errors from occurring during processing using APIs.The following objects have been modified:sgastdn.fmbsgastdq.fmbslarmap.fmbssasect.fmbsivfacl.sqlslphous.pcslrroll.pcshrastd.pcshrrpts.pcStudent Release 7.0 January 2005298 Release Guide Confidential

Section 12 Miscellaneous EnhancementsOracle 9.2 Order By Modifications in Release 6.2Oracle 9.2 Order By Modifications in Release 6.2S% (#94482)Objects that had SQL “group by” statements, but not “order by” statements, havehad “order by” statements added to run correctly under Oracle 9.2. The followingforms and reports have been modified:slamasg.fmbslapasg.fmbsoaadas.fmbsoaccol.fmbsoaeltr.fmbsoaqgeo.fmbsoqolib.fmbsraquik.fmbsrarecr.fmbsrasrce.fmbsratpfd.fmbsfrenrl.pcslrroll.pcsorcpln.pcsoremal.pcsorinfr.pcsrremal.pcsrrenrh.pcThe “order by “changes were originally delivered in Release 6.1. These objects werenot modified at that time, but they were listed in the 6.1 Release Guide along withall the other modified objects. They have since been modified in Release 6.2 andRelease 7.0.Resolved in Release 7.0.Oracle 9.2 Order By Modifications in Release 6.1Objects that had SQL “group by” statements, but not “order by” statements, havehad “order by” statements added to run correctly under Oracle 9.2. The followingforms, reports, and scripts have been modified:saaackl.fmbsaaadms.fmbsaadcrv.fmbsaaecrl.fmbsaaectm.fmbsaaquik.fmbsaarrft.fmbsaawaad.fmbJanuary 2005 Student Release 7.0Confidential Release Guide 299

Section 12 Miscellaneous EnhancementsOracle 9.2 Order By Modifications in Release 6.1saawadf.fmbsaawapp.fmbsaawatr.fmbscarres.fmbseandtl.fmbseasdtl.fmbsfacreq.fmbsfaregf.fmbsfarovr.fmbsfasrpo.fmbsfqsecm.fmbsgastdn.fmbshagrde.fmbshataeq.fmbshatatc.fmbshatatr.fmbshatrns.fmbshatrta.fmbsiaasgn.fmbsiacona.fmbsialvas.fmbsmiaout.fmbsmiarea.fmbsmigout.fmbsmiprog.fmbsoasupl.fmbspaemrg.fmbssactrl.fmbssasect.fmbstvwsct.fmbstvwthd.fmbsapadms.pcsaremal.pcsaretmt.pcscrbult.pcscrrfun.pcsfpfaud.pcsfpregs.pcsfrhcnt.pcsfrlink.pcsfrslst.pcshrcatt.pcshrcgpa.pcshrcipc.pcshrconv.pcshrgpac.pcshrgrde.pcshriact.pcshriage.pcshricip.pcshrieth.pcshrigrs.pcshriqus.pcshrires.pcshrrpts.pcshrtrtc.pcsirctal.pcStudent Release 7.0 January 2005300 Release Guide Confidential

Section 12 Miscellaneous EnhancementsRecruitingsmrbcmp.pcsmrgevl.pcsmrjobs.pcsmrrule.pcsrrenrl.pcssrscrm.pcssrsect.pcssrtaly.pcsafdcsn.sqlsakchk1.sqlsakenr1.sqlsakmtc1.sqlscklib1.sqlsffetrm1.sqlsfkfee1.sqlsfkfees.sqlshkcgpa.sqlshkegr1.sqlshkmod1.sqlshkrpt1.sqlsmkatr1.sqlsmkgtr1.sqlsmkotr1.sqlsmkptr1.sqlsskolr1.sqlDelivered in Release 6.1.RecruitingElectronic Prospect Match (SRRSRIN)(#87322)Obsolete ParameterThe Match on Current SPRIDEN parameter is obsolete and has been removed fromthe process.New ParameterA new parameter has been added to the process. The Auto Load (Skip Dup Chk)parameter is required, and is used to automatically load new or matched IDs whenset to Y or perform duplicate processing when set to N. The default setting is N.January 2005 Student Release 7.0Confidential Release Guide 301

Section 12 Miscellaneous EnhancementsRecruitingProcessingAuto Load ParameterThe Auto Load (Skip Dup Chk) parameter on SRRSRIN allows you to choosewhether to flag duplicates on a tape or skip the duplicate checking process to reducethe number of duplicates that would need to be handled manually on SRIPREL.Duplicates are flagged by SRRSRIN when the temporary tables contain recordshaving the same name and date of birth for the prospect code and/or tape IDchosen as parameter values when running SRRSRIN.SRRSRIN may find duplicates in the following circumstances:• Single tapes may report the same individual more than once for the prospectcode/tape ID.• Individual tapes may be loaded to the temporary tables multiple times usingthe same prospect code and/or tape ID.• Multiple tapes for the same prospect code could be loaded to the temporarytables with the same tape ID, and the same name could appear across multipletapes.• Web prospects having the same prospect code, name, and date of birth couldbe loaded to the temporary tables.The Auto Load (Skip Dup Chk) parameter is used to bypass the flagging ofduplicates by SRRSRIN and to automatically load records to Banner. Auto loadprocessing replaces the manual processing of matching and loading thoseduplicates on SRIPREL.When the Auto Load (Skip Dup Chk) parameter is set to Y, the matching process isinvoked, and NEW or MATCHED prospects are flagged. Those prospects areimmediately loaded to Banner. Duplicate checking does not occur.Since the records are loaded to Banner as flagged, each prospect that follows on thetape is evaluated against any records loaded, facilitating more matches, andpreventing records from being flagged as duplicates. When the Auto Load (SkipDup Chk) parameter is set to Y, records that were previously flagged as LOADEDmanually on SRIPREL for the same tape type and tape ID will not be processed bySRRSRIN.When the Auto Load (Skip Dup Chk) parameter is set to Y, the SRRSRIN output filewill resemble the SRRPREL output file with the information regarding the prospectsthat have been loaded.If SRRPREL is run after SRRSRIN is run, with the Auto Load (Skip Dup Chk)parameter set to Y for the same prospect code and tape ID, there will be no recordsprocessed. If all records are processed by SRRSRIN when the Auto Load (Skip DupChk) parameter is set to Y, there is no reason to run SRRPREL.Student Release 7.0 January 2005302 Release Guide Confidential

Section 12 Miscellaneous EnhancementsRecruitingFor example,30-OCT-2003 13:18:27 BANNER University Page: 1Migrate Electronic ProspectsSRRPREL* * * REPORT CONTROL INFORMATION - SRRPREL - Release 6.1 * * *RPTNAME: SRRPRELPREL CODE: SATTAPE ID : s7MATCH STATUS: ANumber of Prospects Read:Number of Prospects Migrated to Production Banner:Number of Prospects NOT Migrated to Production Banner:Note: Suspended records or records in error may still be found when the AutoLoad (Skip Dup Chk) parameter is set to Y. These records will need to behandled manually on SRIPREL.The process works as follows:If a tape ID selected by SRRSRIN contains multiple occurrences of John Smith withthe same date of birth or SSN, then when the Auto Load (Skip Dup Chk) parameteris set to Y, the first occurrence of John Smith will be flagged as NEW (or MATCHED),and the record will immediately be loaded to Banner.If subsequent occurrences of the same John Smith are evaluated on the same tape,each one will be found to be matched against the prior record for John Smith thatwas already loaded as NEW (or MATCHED) to Banner. Prior to the availability of theAuto Load (Skip Dup Chk) parameter, each occurrence of John Smith with samedate of birth or SSN would have been flagged as a duplicate on tape. Duplicates thenneeded to be handled manually on SRIPREL.Note: When the Auto Load (Skip Dup Chk) parameter is set to Y, the value forthe Report Type parameter in SRRSRIN will be ignored.Duplicate ProcessingIf the Auto Load (Skip Dup Chk) parameter is set to N, the Report Typeparameter value will be passed to SRRSRIN, and the check for duplicateson tape will occur.Duplicate processing has also been modified as part of this problem resolution.If the Auto Load (Skip Dup Chk) parameter is set to N, then duplicate processingwill now run before match processing. In addition, duplicate processing performsthe following checks:1. If two records have the same SSN, they will be marked as duplicates.2. If two records have the same first and last names and the same dates of birth,they will be marked as duplicates.January 2005 Student Release 7.0Confidential Release Guide 303

Section 12 Miscellaneous EnhancementsAdmissionsThe first name match will also use any nick name data created on SOANAME,if no first name matches are found. In addition, if either of the incoming Dateof Birth fields are null, but the first and last names match, a record will still beconsidered to be a duplicate.Delivered in Release 6.1.Please see the Admissions chapter of the Student User Guide for an updated reportsample.AdmissionsElectronic Admissions Person Table (SARPERS)Changed ColumnsThe SARPERS_LAST_NAME and SARPERS_FORMER_NAME columns have beenincreased from VARCHAR2(35) to VARCHAR2(60). Delivered in Release 6.1.Electronic Application Report (SARETBL)The infrastructure of Oracle Reports has changed significantly between Reports 6iand Reports 10g. Please refer to the Banner 7 FAQ for the known issues with OracleReports and Banner. Please refer to the Banner General 7.0 Release Guide for detailedinformation on Oracle reports.For SARETBL specifically, parameters have been reordered and renamed, and newparameters have been added to the report as part of a technology upgrade forOracle Reports. You can now select an output format and type, as well as choosingto run the report while you wait or behind the scenes. An optional Banner OracleReport Values window has been added to allow access to some report controls. Youcan also view activity on the Reports Server for Oracle reports that have been run.The new parameter order is:• Application Source• Add Date• Web ID• Destination Format• Destination Type• Destination NameStudent Release 7.0 January 2005304 Release Guide Confidential

Section 12 Miscellaneous EnhancementsPCU Tape Load Regulatory Winter 2005 Updates• Execution Mode• Communication Mode• Parameter Form• Show Report Value WindowThe Destination parameter has been renamed the Destination Type parameter.Values for this parameter have also been changed. Preview and Screen have beenremoved, and CACHE has been added to display the report on the screen. CACHEis the default.The new parameters for the report are:• Destination Format• Execution Mode• Communication Mode• Parameter Form• Show Report Value WindowThis parameter has no impact on job submission. Please refer to the BannerGeneral 7.0 Release Guide for more information on this parameter.Please see the landscaped report information at the end of this section for the newparameter information.Package sakmtch.sql(RPE #31054)Changes were made in the sakmtch.sql package to improve efficiency andperformance. The sorccol1.sql script is delivered to add a new index to theSORCCOL_PIDM column in the SORCCOL table. Delivered in Release 6.1.PCU Tape Load Regulatory Winter 2005 UpdatesSRATPFD,suptpfd11.sql(#98602)The new PCU (Private College Guide Search) Tape Load Regulatory changes for2005 required updates to the Tape Field Position Rule Form (SRATPFD). Thesuptpfd11.sql script is delivered to make these updates.The changes to SRATPFD are as follows:January 2005 Student Release 7.0Confidential Release Guide 305

Section 12 Miscellaneous EnhancementsAMCAS Regulatory Fall 2004 Updates• The First Name field positions have been changed from 17 - 30 to 17 - 35.• The Middle Initial field positions have been changed from 31 - 31 to 36 - 36.• The Last Name field positions have been changed from 32 - 46 to 37 - 55.• The Foreign Indicator in positions 225 - 225 has been removed as it is no longerused. This field is now blank.• The Email Address field positions have been changed from 467 - 500 to 341 -400.Field Name Start Position End Position LengthNAME_FIRST 017 035 19NAME_MI 036 036 1NAME_LAST 037 055 19No longer used 220 - blank 227 - blank 8 - blankEMAIL_ADDR 341 400 60AMCAS Regulatory Fall 2004 UpdatesSARAMXF (#97515)Changes made by AMCAS to the admissions action file layout necessitate changes tothe AMCAS Extract File (SARAMXF). AMCAS is combining the file layouts used forAMCAS and non-AMCAS schools into one layout. This new layout has five new fieldsat the end, only one of which is required. This new DELROW field is used to indicatethat the prior action sent for an applicant needs to either be corrected or deleted.The other four fields are NULL. Also, you can no longer use the NA decision codeto identify rows that are in error.The sinserul2.sql script is used to add a new row to SAAERUL where the valuein the Group field is ADMS, the value in the Rule Label field is AMCASDELCODE,the value in the Rule Description field is AMCAS Delete Decision Code, and the valuein the Value field is D. This script is delivered by SunGard SCT.SARAMXF retrieves the most recent decision row for an applicant using theSAVAMC2 view. The date of this decision code record is verified as greater than orequal to the value in the SABSUPL_AGENCY_REPORT_DATE field. If this is the case, theprocess continues. Otherwise, the process goes to the next applicant/application. Ifthe decision code (SAVAMC2_ADMIT_ACTION_CODE) equals the decision code in newAMCASDELCODE rule on SAAERUL, then the process finds the next most recentdecision row for the applicant where the decision code equals a decision code crossreferencedon SOAXREF, where the value in the EDI Label field is STVAPDC, andthe value in the EDI Qualifier field is AN%.Student Release 7.0 January 2005306 Release Guide Confidential

Section 12 Miscellaneous EnhancementsSAT Tape Load Regulatory Fall 2004 UpdatesThis decision code is used to create the record to be sent in the AMCAS flat file. Avalue of D is inserted into the new DELROW field on the flat file to indicate that aprior row (which is identical) should be removed. The value of theSABSUPL_AGENCY_REPORT_DATE field is updated with the system date. Additionalpipe delimiters have been inserted as needed to handle final four fields, which areNULL.The sinsxref1.sql script is used to populate the row on SOAXREF where:• the value in the EDI Label field is STVAPDC,• the value in the EDI Qualifier field is AN,• the value in the EDI Value field is D,• the value in the Banner Value field is UPDATE ME, and• the value in the Description field is AMCAS Delete Decision.This script is delivered by SunGard SCT. Users must change UPDATE ME to the codevalue for an AMCAS Delete Decision in their STVAPDC table. They may also have toenter the code value for an AMCAS Delete Decision on STVAPDC.Resolved in Release 7.0.SAT Tape Load Regulatory Fall 2004 UpdatesSOATEST (#94528)The following changes have been made to the SAT Tape Load Process for the 2004-2005 reporting year.Three scripts are delivered by SunGard SCT to facilitate these changes. They are:sintesc2.sql, sinvpfd3.sql, and suptpfd11.sql.1. Three new SAT test scores have been added.• A three-digit SAT Writing Score, S07, has been added to STVTESC,STVTPFD, and SRATPFD and will be loaded to SORTEST/SOATEST.• A two-digit SAT Essay Subscore, S08, has been added to STVTESC,STVTPFD, and SRATPFD and will be loaded to SORTEST/SOATEST.• A two-digit SAT Writing Multiple-choice (MC) Subscore, S09, has beenadded to STVTESC, STVTPFD, and SRATPFD and will be loaded toSORTEST/SOATEST.Note: You may already have S03, S04, and S05 updated on SRATPFD, sincethose test codes have been delivered in the past. The start and endpositions for S03, S04, and S05 are currently defined in the locationsrequired for S07, S08, and S09. When we deliver the script to insert S07,January 2005 Student Release 7.0Confidential Release Guide 307

Section 12 Miscellaneous EnhancementsSAT Tape Load Regulatory Fall 2004 UpdatesS08, and S09, we will be replacing S03, S04, and S05, since they are notcurrently reported by the SAT. If you are using S03, S04, and/or S05 forinstitutional reasons, you will need to replace these codes and positionsafter running the update script for S07, S08, and S09.Tape Updates:Tape Positions Test Score Description140 - 143 Test Date No change, (MM/YY)144 Educational Level No change, numeric string145 BLANK (1) N/A146 Revised Score Indicator No change, blank = not revised,Z = revised147 - 149 Verbal Score No change, 200 - 800 range150 - 152 Math Score No change, 200 - 800 range153 - 155 Writing Score 200 - 800 range(previously blank fields)156 - 157 Essay Subscore 00 - 12 range(previously blank fields)158 - 159 MC Subscore 20 - 80 range(previously blank fields)160 - 179 SAT Score Admin 2 Defined same as positions 140 - 159180 - 199 SAT Score Admin 3 Defined same as positions 140 - 159200 - 219 SAT Score Admin 4 Defined same as positions 140 - 159220 - 239 SAT Score Admin 5 Defined same as positions 140 - 159240 - 259 SAT Score Admin 6 Defined same as positions 140 - 159On STVTESC:TestCodeDescriptionNumber ofPositionsRequiredData TypeMinimum/MaximumScoresSystemRequiredS07 SAT Writing 3 Numeric 200 - 800 YesS08 SAT Essay Subscore 2 Numeric 00 - 12 YesS09 SAT MC Subscore 2 Numeric 20 - 80 YesStudent Release 7.0 January 2005308 Release Guide Confidential

Section 12 Miscellaneous EnhancementsSAT Tape Load Regulatory Fall 2004 UpdatesOn STVTPFD:Tape/File Field Name Codes Description System RequiredS07_TEST_CODE SAT S07 Score YesS08_TEST_CODE SAT S08 Score YesS09_TEST_CODE SAT S09 Score YesOn SRATPFD:SRATPFD Tape Field Names Start Position End Position Occurrence Activity DateS07_TEST_SCORE 153 155 1 %S08_TEST_SCORE 156 157 1 %S09_TEST_SCORE 158 159 1 %S07_TEST_SCORE 173 175 2 %S08_TEST_SCORE 176 177 2 %S09_TEST_SCORE 178 179 2 %S07_TEST_SCORE 193 195 3 %S08_TEST_SCORE 196 197 3 %S09_TEST_SCORE 198 199 3 %S07_TEST_SCORE 213 215 4 %S08_TEST_SCORE 216 217 4 %S09_TEST_SCORE 218 219 4 %S07_TEST_SCORE 233 235 5 %S08_TEST_SCORE 236 237 5 %S09_TEST_SCORE 238 239 5 %S07_TEST_SCORE 253 255 6 %S08_TEST_SCORE 256 257 6 %S09_TEST_SCORE 258 259 6 %2. A new SAT Essay ID has been added.• An SAT Essay ID has been added to STVTPFD and SRATPFD.January 2005 Student Release 7.0Confidential Release Guide 309

Section 12 Miscellaneous EnhancementsSAT Tape Load Regulatory Fall 2004 Updates• New fields have also been added to SRTTEST and SORTEST toaccommodate this information. The fields are:SRTTEST_SAT_ESSAY_IDSORTEST_SAT_ESSAY_IDVARCHAR2(10)VARCHAR2(10)• SOATEST will display the SAT Essay ID information in the new SAT EssayID field.• SRTLOAD will load the SAT Essay ID to the SRTTEST temporary table.• SRRPREL will load the SAT Essay ID to SORTEST/SOATEST for thecorresponding writing/essay score S07.Tape Updates:Tape Positions Test Score Description500 - 509 SAT Essay ID Number Latest Ten-digit alpha-numeric(removed score analysissection)510 - 519 SAT Essay ID Number Admin 2 Ten-digit alpha-numeric(removed score analysissection)520 - 529 SAT Essay ID Number Admin 3 Ten-digit alpha-numeric(removed score analysissection)530 - 539 SAT Essay ID Number Admin 4 Ten-digit alpha-numeric(removed score analysissection)540 - 549 SAT Essay ID Number Admin 5 Ten-digit alpha-numeric(removed score analysissection)550 - 559 SAT Essay ID Number Admin 6 Ten-digit alpha-numeric(removed score analysissection)On STVTPFD:Tape/File Field Name Codes Description System RequiredSAT_ESSAY_ID SAT Essay ID YesStudent Release 7.0 January 2005310 Release Guide Confidential

Section 12 Miscellaneous EnhancementsACT Tape Load Regulatory Fall 2004 UpdatesOn SRATPFD:SRATPFD Tape Field Names Start Position End Position Occurrence Activity DateSAT_ESSAY_ID 500 509 1 %SAT_ESSAY_ID 510 519 2 %SAT_ESSAY_ID 520 529 3 %SAT_ESSAY_ID 530 539 4 %SAT_ESSAY_ID 540 549 5 %SAT_ESSAY_ID 550 559 6 %3. A new Email Address tape field name has been added.An new Email Address tape field name has been added to SRATPFD to load theemail address to GOREMAL/GOAEMAL.Tape Updates:Tape Positions Test Score Description579 - 628 Email Address Fifty-digit alpha-numeric string(removed score analysissection)On SRATPFD:SRATPFD Tape Field Names Start Position End Position Occurrence Activity DateEMAIL_ADDR 579 628 1 %Resolved in Release 6.2.ACT Tape Load Regulatory Fall 2004 UpdatesSRATPFD (#94582)The following changes have been made to the ACT Tape Load Process for the 2004-2005 reporting year.January 2005 Student Release 7.0Confidential Release Guide 311

Section 12 Miscellaneous EnhancementsACT Tape Load Regulatory Fall 2004 Updates1. Four new ACT test scores have been added for reporting: Combined English/Writing, Writing Subscore, Norm Combined English/Writing, and NormWriting.Tape Positions Test Score Description Minimum/Maximum Scores163 - 164 Combined English/Writing 01 - 36 range(previously blank fields)165 - 166 Writing Subscore 02 - 12 range(previously blank fields)167 - 168 Norm Combined English/Writing 01 - 99 range(previously blank fields)169 - 170 Norm Writing 01 - 99 range(previously blank fields)2. These test scores have also been added to STVTESC with corresponding testcodes: A07, SWR, NEW, and NWR. The test scores are delivered with a data typeof numeric.TestCodeDescriptionNumber ofPositionsRequiredData TypeMinimum/MaximumScoresSystemRequiredA07ACT Combined English/Writing2 Numeric 01 - 36 YesSWR ACT Subscore Writing 2 Numeric 02 - 12 YesNEWACT Norm English/Writing2 Numeric 01 - 99 YesNWR ACT Norm Writing 2 Numeric 01 - 99 Yes3. Four new tape/file field name codes have been added to STVTPFD:A07_TEST_SCORE, SWR_TEST_SCORE, NEW_TEST_SCORE, andNWR_TEST_SCORE. All are required.Tape/File Field Name Codes Description System RequiredA07_TEST_SCOREACT Combined English/WritingYesSWR_TEST_SCORE ACT Subscore Writing YesNEW_TEST_SCORE ACT Norm English/Writing YesNWR_TEST_SCORE ACT Norm Writing YesStudent Release 7.0 January 2005312 Release Guide Confidential

Section 12 Miscellaneous EnhancementsACT EOS Search Tape Regulatory Fall 2004 Updates4. The four new tape field names and their associated positions have also beeninserted/updated in SRTTPFD and SRATPFD. These positions are currentlyblank on tapes processed prior to the 2004-2005 changes.SRATPFD Tape Field Names Start Position End Position Occurrence Activity DateA07_TEST_SCORE 163 164 1 %SWR_TEST_SCORE 165 166 1 %NEW_TEST_SCORE 167 168 1 %NWR_TEST_SCORE 169 170 1 %5. SRTLOAD has been modified to load the four new test scores to the SRTTESTtemporary tables. SRRPREL and SRKPREL will then load the new scores toSCT Banner.Resolved in Release 6.2.ACT EOS Search Tape Regulatory Fall 2004 UpdatesSRTLOAD (#95217)The following changes have been made to the ACT EOS Search Tape Process for the2004-2005 reporting year.1. Position 159:159 GenderThe gender position on the tape remains the same. However, the gender codeshave been modified.The gender codes on the tape were:• 1 = Male• 2 = Female• Blank = No gender reportedThe gender codes have been changed to:• M = Male• F = Female• Blank = No gender reportedSCT Banner accommodates the previous gender coding on the tape, as well asthe new gender coding.January 2005 Student Release 7.0Confidential Release Guide 313

Section 12 Miscellaneous EnhancementsTape Load Regulatory Fall 2003 Updates2. SRTLOAD has been modified for the EOS_ACT prospect code (on STVPREL)to accommodate the gender codes changes.Resolved in Release 6.2.Tape Load Regulatory Fall 2003 UpdatesScriptsuptpfd9.sql (#88537)PSAT/SSS Tape Load Regulatory changes for October 2003 and the 03-04 reportingyear include the following changes:• Positions 191-192 have been changed from HS Grade Level to HS Grad Year.• STVTPFD has a defined field for HSCH_GRAD_YEAR.• On SRATPFD, the field name HSCH_GRADE_LEVEL for positions 191-192 canbe manually changed to HSCH_GRAD_YEAR.• The suptpfd.sql script is delivered to update SRATPFD electronically.Resolved in Release 6.1.IPEDS Regulatory Fall/Winter 2003 UpdatesRacial/Ethnic Status Report (SHRIETH)(#90538)The NCES has changed their requirements for IPEDS Web upload data for theWinter 2003 intake (Fall Enrollment). This update synchronizes the existingregulatory requirements and NCES requirements.The following modifications were made to the Web upload file from the Racial/Ethnic Status Report (SHRIETH) for the Winter 2003 intake.These existing lines are no longer required:Student Release 7.0 January 2005314 Release Guide Confidential

Section 12 Miscellaneous EnhancementsIPEDS Regulatory Fall/Winter 2003 UpdatesLineDescription6 Total, Full-time, degree/certificate-seeking undergraduate8 Total, Full-time, undergraduate20 Total, Part-time, degree/certificate-seeking undergraduate22 Total, Part-time, undergraduateThese new lines are now required:LineDescription3 Total, Full-time, other degree/certificate-seeking undergraduate7 Total, Full-time, non-degree/certificate-seeking undergraduate17 Part-time, other degree/certificate-seeking undergraduate21 Part-time, non-degree/certificate-seeking undergraduateDelivered in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 315

Section 12 Miscellaneous EnhancementsIPEDS Regulatory Fall/Winter 2003 UpdatesThis page intentionally left blankStudent Release 7.0 January 2005316 Release Guide Confidential

Section 13 Problem ResolutionsCatalog ModuleSection 13Problem ResolutionsCatalog ModuleFormsSCACRSE (#89895)The Contact High (SCBCRSE_CONT_HR_HIGH) field was no longer navigable norupdateable as it had been in previous versions of the form. This has been corrected.Resolved in Release 7.0.SCACRSE (#84976)Due to form navigation issues, CEU hours were only calculated when the userperformed a Next Field from the Hours - CEU/Credit Low field. The calculationnow occurs when either lecture, lab, or other hours are entered. Resolved in Release6.1.SCACRSE (#77040)The Partition Preferences block and the Room Attribute Preferences block (sectionand meeting time preferences) have been modified to only accept values of 01, 02,03, or 04. The following error message will be displayed if a value other than thesehas been entered: “*ERROR* Schedule25 only allows values 01 - 04”. Resolved inRelease 6.1.SCACRSE (#72836)When a course number contains an underscore (_), it can be used as a one positionwildcard, but incorrect information is then displayed in the Course Information,Course Level, and Grading Mode Blocks. This has been corrected. Resolved inRelease 6.1.SCADETL (#88640)A warning message will now be displayed when an attempt is made to update/change a value which may have an impact on fee assessment. Resolved in Release7.0.SCADETL (#76789)The correct default font size is now used when data is entered in the Course Textblock. Resolved in Release 7.0.January 2005 Student Release 7.0Confidential Release Guide 317

Section 13 Problem ResolutionsSchedule ModuleSCADETL (#88184)You must now enter a fee type when creating fee records. A default value of FLATwill be used if no fee type is entered. Resolved in Release 6.1.SCAPREQ (#82858)The logic to retrieve appropriate grades, based on the effective term of the course,was modified to ensure that the appropriate information is displayed in the CourseTest Score & Pre-requisite Restrictions block. Resolved in Release 6.1.SCAPREQ (#80764)The form was incorrectly permitting data changes in the Course Test Score & PrerequisiteRestrictions block when the term in the Key Block was not equal to theeffective term of the course. Additional edits have been added, and the followingerror message will now be displayed: "Cannot update unless from term equals key term".Resolved in Release 6.1.SCAPREQ (#76159)When copying course test score and pre-requisite restrictions to a new term, theform was displaying an Oracle error: “(FRM-40508: ORACLE ERROR: Unable toINSERT)”, even though the new records had been created. A problem with thegrade edit was found and corrected. Resolved in Release 6.1.SCARRES (#84604)The programs displayed in the Existing Programs List of Values accessed from theProgram Restriction block are now sorted by program, rather than being presentedin a random order. Resolved in Release 6.1.Schedule ModuleFormsSSABLCK (#85823)When a duplicate section is added to a block in SSABLCK, a warning message willbe displayed. As this is only a warning message, the section will be added to theblock. The user is then free to determine the next course of action. Resolved inRelease 6.1.SSABLCK (#66521)When the status of a section attached to block was changed from one that permitsregistration to one that does not, a warning message was issued informing the userof this situation. Unfortunately, the section information was not displayed, therebypreventing any corrective action. You can now view the section information of thecancelled/inactive section. Resolved in Release 6.1.Student Release 7.0 January 2005318 Release Guide Confidential

Section 13 Problem ResolutionsSchedule ModuleSSADETL andSSASECT(#88640)A warning message will now be displayed when an attempt is made to update/change a value which may have an impact on fee assessment. Resolved in Release7.0.SSADETL (#82228)When available co-requisite sections were queried, the Corequisite Query List ofValues displayed truncated Ptrm and Camp field values. These fields have beenexpanded to accommodate the maximum value of three characters. Resolved inRelease 6.1.SSADETL andsstattr3.sql(#78616)Value-Based Security was inappropriately preventing the deletion of degreeprogram attribute records in the form. Modifications were made so the VBS profileinformation is now accurately interpreted. Resolved in Release 6.1.SSADETL (#88184)You must now enter a fee type when creating fee records. A default value of FLATwill be used if no fee type is entered. Resolved in Release 6.1.SSAMATX (#88759)You can now perform a Rollback, and the form is reset to query mode withoutreceiving an error. Resolved in Release 7.0.SSASECT (#92374 and #96335)The word “attendance” is now spelled correctly in the Attendance Method field tag.Resolved in Release 7.0.SSASECT (#87634)The Print checkbox on SSASECT now controls only whether a class is printed in theClass Schedule Report (SSRSECT).The Web/VR Avail checkbox on SSASECT now controls only whether a class can beviewed and registered for via the Web or using Voice Response.A new CRNDIRECT rule has been added to GTVSDAX to allow you to specifywhether a class that is not VR/Web available can be registered for or updated on theAdd or Drop Classes page in self-service if the CRN is known.External Code Internal Code Internal CodeSequence NumberInternal Code Group Description Activity DateY/N CRNDIRECT NULL WEBREG Allow direct CRNentry/updateSysdateScript sinssdax1.sql is delivered by SunGard SCT to add this rule to GTVSDAX.Resolved in Release 6.2January 2005 Student Release 7.0Confidential Release Guide 319

Section 13 Problem ResolutionsSchedule ModuleSSASECT andSSASBSH(#77040)The Partition Preferences blocks and the Room Attribute Preferences blocks(section and meeting time preferences) have been modified to only accept values of01, 02, 03, or 04. The following error message will be displayed if a value other thanthese has been entered: “*ERROR* Schedule25 only allows values 01 - 04”. Resolved inRelease 6.1.SSASECT (#90119)The enrollment information was not being calculated correctly when reserved seatswere assigned to the section. The doubling of the new calculated seats has beencorrected. The modification of the Property Sheet has rectified the incorrect displayof 9 in the Maximum Seats field in the Reserved Seats window. Resolved in Release6.1.SSASECT (#90061)An Oracle error was displayed when meeting time records were created for sectionswith fractional credit hours. Due to the change in Oracle versions, the manipulationof data did not work the same as in previous versions, and as a result, the credit hourinformation was not processed correctly. The code has been changed to process thedata in the same manner as prior releases. Resolved in Release 6.1.SSASECT (#89720)Field navigation issues with the Additional Credit Hour Information window havebeen corrected. The cursor will now be positioned in the Section Lecture ContactHours field when the window is accessed. When the Return button is selected fromthis window, the cursor is returned to the Section Total Contact Hours field in themain window. Resolved in Release 6.1.SSASECT (#88178)SSASECT does not permit the instructional method to change when registrationrecords have been processed for the section. However, it should be possible tochange the contents of that field prior to enrollments. The editing logic has beencorrected to permit a change to an instructional method that has zero (0)registration records. Resolved in Release 6.1.SSASECT (#73121)When room restrictions were defined for a classroom, these restrictions were notcorrectly queried when the building and/or room was assigned to a meeting recordin SSASECT.This logic has been modified to examine the inactivation dates and times. If themeeting time is being created for a date or time period defined as blacked out forthe room, an error message: “*ERROR* Room has usage restrictions for this time period”will be displayed. You will not be permitted to save the meeting record until theerror is corrected, either by selecting a different room or changing the meeting timedates/times. Resolved in Release 6.1.Student Release 7.0 January 2005320 Release Guide Confidential

Section 13 Problem ResolutionsSchedule ModuleSSASECT (#77494)When a CEU section was created, the CEU hours were not calculated correctly if themouse was used to navigate through the fields. If the section was updated, thecalculation was not performed unless one of the credit hour values was changed.Once the calculation was performed, the CEU hours worked correctly. Logic hasbeen added to the form to consistently calculate the CEU hours, regardless ofwhether mouse or keyboard navigation is used. Resolved in Release 6.1.SSASECT (#69993)When new sections were created using the copy functionality, the VR/Web Avail flagwas always set to checked (or Y on the SSBSECT table). Modifications were made toensure that the parent values, whether checked or unchecked, are correctlyrepresented on the new section record. Resolved in Release 6.1.SSASECT (#65373)Due to Faculty Load implications, a change in schedule type will not result in anupdate of the schedule type housed on the meeting record(s). This will continue tobe a manual process. However, the logic was changed to prevent a schedule typechange after students have registered for the section. Resolved in Release 6.1.SSASECT (#50918)VBS security did not prevent the updating of information contained on theEnrollment Data window of SSASECT, even though that information is housed inthe SSBSECT table. The logic has been expanded to restrict access to enrollmentdata. Resolved in Release 6.1.SSAXMTI (#86831)The Select function was not available when meeting times/instructors were beingcopied from one crosslisted section to another. This only occurred when SSAXMTIwas accessed using the Options Menu in the Meeting Time block of SSASECT. IfSSAXMTI was accessed using the Duplicate Item function in SSASECT, the Selectfunction was already available. The Select function is now available when SSAXMTIis accessed using the Options Menu in the Meeting Time block of SSASECT.Resolved in Release 6.1.SSATEXT (#76789)The correct default font size is now used when data is entered in the Section Textblock. Resolved in Release 7.0.Triggersstresv2.sql (#88840)If a user was defined in Value-Based Security and was trying to register a student fora CRN which had reserved seating, the user received the following message: “FRM-40735: FINAL_EDITS trigger raised unhandled exception ORA-20005.” If the user wasgiven access to the Class Schedule module, everything worked. But if the user hadupdate privileges for the Class Schedule module with restrictions for certainJanuary 2005 Student Release 7.0Confidential Release Guide 321

Section 13 Problem ResolutionsSchedule Moduledepartments, they could not register students for CRNs which did not belong tothose departments. This seemed to only happen for CRNs that had reserved seating.This situation has been corrected. Resolved in Release 6.2.ReportsSSRROLL (#89609)The fee type (SSRFEES_FTYP_CODE) is now included in the term roll of section fees.Resolved in Release 6.1.SSRSCMT (#74190)When the output from Schedule25 was incorporated into the Work Table(SSTSCHW), the table field associated with a Thursday room allocation was notbeing updated correctly. The logic has been changed to key into the table. Resolvedin Release 6.1.SSRSCRM (#77335)Due to the constraints of the layout of the datain.dat file, the duplicate meetingtime issue (handling CRNs with two identical SSRMEET records that do not have abuilding or room assignment) requires a workaround when running this report. Ifthe meeting times are adjusted by one minute, a unique meeting time record will becreated and will be scheduled by Schedule25. An exception report has been addedto SSRSCRM to highlight potential duplication issues. This will provide notificationthat adjustments to the meeting records are required. Resolved in Release 6.1.Please see the Class Schedule chapter of the Student User Guide for an updated reportsample.SSRSCRM andSSRSCUP(#77229)The term in the section controls (SSACTRL) is now being treated as an effectiveterm. If a campus code is not entered in the parameters when SSRSCRM orSSRSCUP are run, then the control record for the applicable effective term with nocampus code is used as a valid control record. When SSRSCUP is run, it is especiallyimportant to use the same control record as was used for SSRSCRM processing ifsection control values are different from effective term to effective term.Unfortunately, there is not a programmatic way to ensure this. Resolved in Release6.1.SSRSCUP (#77200)When the exceptions files (losers.dat and notposs.dat) created fromSchedule25 are incorporated with the Banner worktable (SSTSCHW), any roominformation contained in those files will be nulled. Resolved in Release 6.1.SSRSECT (#89281)Due to an Oracle 9i Bug(#2713010: Query with GROUP BY clause with two or morecolumns does not order output), SSRSECT did not print the output in college,division, and department order when that option for the Order 1 - Subj, 2 - Coll, Div,Student Release 7.0 January 2005322 Release Guide Confidential

Section 13 Problem ResolutionsCourse Request and SchedulingDept parameter was selected. In previous releases of Oracle, there was an implicit“order by” ordering corresponding to the “group by” sequence. The appropriatecode has been added to SSRSECT to print the output order correctly when the Coll,Div, Dept option is selected. Resolved in Release 6.1.SSRTALY(#94276 - General)This object was modified as part of Banner General problem resolution #94276 forGJIREVO. Column headings will now be underlined correctly on the report output.Resolved in Release 6.2.Course Request and SchedulingReportsSCTC2000 andSCTD0600(#93159)The programs will now compile on LINUX. “EXTERNAL” was removed from theassign clauses. Since the batch scheduling files are released together, SCTC1000,SCTC1500, SCTC3000, and SCTH1000 are also being delivered. Resolved in Release6.2.SCT% (#80599)The COBOL processes used with Course Request and Scheduling can now be runthrough job submission. Also, the word “EXTERNAL” has been removed from allfile assignments and will no longer cause compile errors.The following processes have been updated:• SCTC1000• SCTC1500• SCTC2000• SCTC3000• SCTD0600• SCTH1000• SCTSORTResolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 323

Section 13 Problem ResolutionsGeneral Person ModuleControl Filestucreq.ctlstucreq.ctl(No defect number)And updated version of this object is being delivered that includes 6.x modificationsthat were previously not found in 7.0. Resolved in Release 7.0.(No defect number)This object is being delivered for use with the Expanded Credit Hours and GPAFields enhancement that was included in Release 6.0. Resolved in Release 6.2.General Person ModuleFormsSPAIDEN (#88265)When Oracle Patchset 13 was applied, the cursor behaved differently when recordswere inserted and copied in the Address block. This has been corrected by Oracle9i. Resolved in Release 7.0.SPAIDEN (#87990)An update script is being delivered to delete the GUROPTM row “Email AddressTES” from the Options Menu for the Address Information block. This option is notneeded as the existing “Email Addresses” option can be used to access GOAEMAL.This was originally #81016. Resolved in Release 6.1.SPAIDEN (#89505)If a ZIP code corresponded to more than one city or state on GTVZIPC, when thatZIP code was entered on SPAIDEN, the form defaulted in the last city listedalphabetically, with the message: "WARNING-Multiple Cities exist for this ZIP/Postalcode; press LIST to select one." However, in the Address Information window onSRAQUIK or SAAQUIK, the form populated the first city alphabetically, and nowarning message was displayed. The correct city will now be populated, and thewarning message will be displayed. Also the warning message has been modified toread the same on SRAQUIK, SAAQUIK, and SPAIDEN. Resolved in Release 6.1.SPAIDEN (#73389)The erroneous Email Addresses TEST link has been removed from the OptionsMenu. Resolved in Release 6.1.SPAIDEN (#87878)Time stamps on the SPRIDEN_ACTIVITY_DATE are now handled accurately andconsistently. Resolved in Release 6.1.Student Release 7.0 January 2005324 Release Guide Confidential

Section 13 Problem ResolutionsSupport Services ModuleSPAPERS (#89039)When an SSN/SIN/TFN is saved that already exists in the database, the pop-upwindow with a warning message will now be displayed consistently. The message inthe window reads: “*WARNING* SSN/SIN/TFN/ already assigned to another record.”Resolved in Release 6.2.TableSPBPERS (#71953)Problem resolution #45031 completed in Release 5.2 corrected the situation whereSPAPERS was updating the SPBPERS_CONFID_IND field to Y or Null, instead of Y orN. The code fix set the value of the SPBPERS_CONFID_IND field to N when theConfidential (Indicator) field was unchecked on SPAPERS. This correction workedwith future records but not past records. Past records now have three values for theSPBPERS_CONFID_IND field: Y, N, or Null.A new non-display field has been added to the SPBPERS block for theSPBPERS_CONFID_IND field, that sets the initial field value to N instead of Null.The following objects affected by this scenario have also been corrected in Release6.1 or in a previous release.• sfarqst.fmb - Corrected in Release 5.4.• sprpdir.pc - Corrected in Release 5.4.0.1.• slarmap.fmb - Corrected in Release 5.4.0.1.• shacrse.fmb - Corrected in Release 5.4.0.1.• sortape.pc - This object was made obsolete with Release 6.0.• saaquik.fmb - Corrected in Release 6.1.• sraquik.fmb - Corrected in Release 6.1.• srkpre1.sql - Corrected in Release 6.1.• supdper1.sql - Corrected in Release 6.1.Support Services ModuleFormsSEADETL (#93197)Previously, place holders for the *CONFIDENTIAL* and *DECEASED* messagesappeared as white blotches above the ID field in the Key Block. These blotches havebeen removed as part of the new user interface technical methodology beingapplied to all forms where the messages appear. Resolved in Release 7.0.January 2005 Student Release 7.0Confidential Release Guide 325

Section 13 Problem ResolutionsFaculty Load ModuleSEASQRY (#78774)Previously, the font of the Term field was different from that of the ID and ServiceGroup fields. This has been corrected. Resolved in Release 7.0.Faculty Load ModuleFormsSIAASGN (#90176)SIAASGN was allowing instructors to be assigned even when they were inactive forthe term. (The Faculty checkbox on SIAINST was unchecked.) This has beencorrected. Resolved in Release 6.1.SIAINST (#67038)The form header now reads Faculty/Advisor Information Form, which matches theform name on the *FACULTY menu. Resolved in Release 7.0.TableSIBFACD_TMP(No associated number)This table is obsolete and is no longer used in Faculty Load processing. Resolved inRelease 7.0.Location Management ModuleFormsSLAEVNT (#93417)Room usage restriction checking in the Meeting Times window will now considerthe time and/or date range of the room inactivation on SLARDEF. Resolved inRelease 6.2.SLAEVNT (#65723)When a new event was entered only on SLAEVNT, when you tried to use Save, thefollowing error was displayed: "ERROR-Days of the week must be entered in order to SAVEthe record." This message was incorrect because it forced the entry of the Start(Date), End (Date), M, T, W, T, F, S, U (Days of the Week), Begin (Time), and EndStudent Release 7.0 January 2005326 Release Guide Confidential

Section 13 Problem ResolutionsLocation Management Module(Time) fields before the record could be saved. The event can now be saved withoutmeeting information and without receiving an error. Resolved in Release 6.1.SLAEVNT (#84736)When free form comments were entered in the Comments Block, the entire line washighlighted and erased when the user typed a character in the last position of theline/field. This has been corrected. Resolved in Release 6.1.SLAMASG,SLAPASG,SLARASGSLAMASG,SLAPASG,SLARASG(#93817)If a person did not have any meal, phone, or room assignments, when you used NextBlock, a pop-up message appeared stating: “Query caused no records to be received.” Thismessage no longer appears, as it was annoying to users entering data, and it alreadyappears in the auto hint line. Resolved in Release 7.0.(#73208)The Lists of Values for the Meal Plan (SLAMASG), Phone Rate (SLAPASG), andRate (SLARASG) fields have been modified, and an error message has been addedto ensure that the term entered in the Term field in the Key Block matches the termon the meal plan rate, phone rate, or room rate record. The term codes must matchso that the correct rate values for the term are displayed in the List of Values.Resolved in Release 7.0.SLAMASG (#89160)You can now update the auto-calculated days/months/term values as you could inprevious versions of Banner. Resolved in Release 6.1.SLAMSCD,SLAPSCDSLAMSCD,SLAPSCD(#76645 and #85884)When you first entered these forms to define records (i.e,. no previous valuesexisted), and you performed a Next Block from the Key Block, you received theerror: “FRM-40350: Query caused no records to be retrieved.” This was followed by asecond error: “FRM-41105: You cannot query records without a saved parent record.” Youcould then enter your data. These errors no longer occur. Resolved in Release 7.0.(#78814)When creating new assignment code records for the first time in a term, after youperformed a Next Block from the Key Block, you received the error: “FRM-40350:Query caused no records to be retrieved.” This was followed by a second error: “FRM-41105: You cannot query records without a saved parent record.” You will now only receivethe message one time in the auto hint line. Resolved in Release 7.0.SLAPASG (#89161)You can now update the auto-calculated days/months/term values as you could inprevious versions of Banner. Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 327

Section 13 Problem ResolutionsLocation Management ModuleSLARASG (#77756)SLARASG was allowing multiple entries of the same data for the same studentbeyond the designated room capacity. This has been corrected and uses the new APIprocessing to properly check the capacity, thereby preventing the room capacityfrom being exceeded if the same ID is used multiple times. Resolved in Release 7.0.SLARASG (#89111)You can now update the auto-calculated days/months/term values as you could inprevious versions of Banner. Resolved in Release 6.1.SLARASG (#66986)If the room rate that defaults from SLARDEF to SLARASG is changed to anothervalue, and then the assignment is subsequently inactivated, the room rate changesto the SLARDEF default when the record is saved. This causes confusion in billingprocesses when trying to reconstruct at what non-default rate a person was charged.Inactivating a room will no longer change the room rate. Resolved in Release 6.1.SLARASG (#81261)You can change the default room rate for the building (SLBBLDG_RRCD_CODE) or forthe room (SLBRDEF_RRCD_CODE) for an applicant. However, if the room statuschanges from one value to another, the updated room rate is replaced by the defaultroom rate. This can lead to incorrect re-assessments if the change in the room rateis not noticed. SLARASG has been corrected so that the room rate will not changewhen the room status changes from one value to another. Resolved in Release 6.1.SLARASG (#87309)If SLARDEF did not have a default room rate, and the rate was manually entered onSLARASG, when the room status was changed, the room rate disappeared, and therecord could not be saved.On SLARASG, when the room status is changed for a record and the room rate onSLARDEF for that room is NULL, the original rate on the record will now remain.The room status can now be changed to a valid status code that has a refund ruleattached to it on SLAASCD, and refunds will be processed accordingly. Resolved inRelease 6.1.SLARDEF (#80574)After you tabbed out of the Capacity and Maximum fields, the cursor disappeared.It should be visible in the Gender radio group and then in the Room Type radiogroup. The radio group options were not being highlighted to reflect the locationof the cursor. This has been corrected. Resolved in Release 7.0.SLARDEF (#84736)When free form comments were entered in the Comments Block, the entire line washighlighted and erased when the user typed a character in the last position of theline/field. This has been corrected. Resolved in Release 6.1.Student Release 7.0 January 2005328 Release Guide Confidential

Section 13 Problem ResolutionsLocation Management ModuleSLARMAP (#78171)SLARMAP did not allow the use of alpha-numeric term codes. The form now allowsyou to create an application for any term that is valid on STVTERM. Resolved inRelease 7.0.Note: As some institutions use alpha characters in their term codes, programcode has been removed from objects where the term code was convertedto a numeric value. This will prevent errors from occurring duringprocessing using APIs.Object:Access ViewSLVRES2 (#88056)Certain GPA-related substring functions had not been modified to accommodatethe larger values that can now be used as a result of the Expanded Credit Hour andGPA functionality. The result was that the view AS_RESIDENTIAL_LIFE couldpotentially return null values for GPA fields. The necessary modifications have nowbeen added to this view. Resolved in Release 6.1.ReportsSLRDADD (#92657)Errors received when the process was compiled have been corrected. Resolved inRelease 6.2.SLRROLL (#74927)The description of the Room Assignment Status Code parameter in thedocumentation has been corrected to read that only one active room assignment isrolled at a time. Resolved in Release 7.0.SLRROLLSLRSCHD(No defect number)The Room Assignment Status Code, Room Assignment Status Date, MealAssignment Status Code, Meal Assignment Status Date, Phone Assignment StatusCode, and Phone Assignment Status Date parameters are now required whether thereport is run in audit mode or in update mode. Resolved in Release 7.0.(No defect number)The Room Rate Code, Room Assignment Status Code, and Room Assignment StatusDate parameters are now required whether the report is run in audit mode or inupdate mode. Resolved in Release 7.0.SLRSCHE (#95406)This report will now run through job submission using VMS. Resolved in Release6.2.January 2005 Student Release 7.0Confidential Release Guide 329

Section 13 Problem ResolutionsRecruiting ModuleSLRSCHE (#80599)This COBOL report can now be run through job submission. Also, the word“EXTERNAL” has been removed from all file assignments and will no longer causecompile errors. Resolved in Release 6.1.Recruiting ModuleFormsSRAQUIK (#89505)If a ZIP code corresponded to more than one city or state on GTVZIPC, when thatZIP code was entered on SPAIDEN, the form defaulted in the last city listedalphabetically, with the message: "WARNING-Multiple Cities exist for this ZIP/Postalcode; press LIST to select one." However, in the Address Information window onSRAQUIK or SAAQUIK, the form populated the first city alphabetically, and nowarning message was displayed. The correct city will now be populated, and thewarning message will be displayed. Also the warning message has been modified toread the same on SRAQUIK, SAAQUIK, and SPAIDEN. Resolved in Release 6.1.SRAQUIK (#84905)When searching for a ZIP code from the Address Information block, if more thanone city existed for a ZIP code, selecting any of the cities would always return thefirst city alphabetically listed. The correct city is now returned. Resolved in Release6.1.SRAQUIK (#89616)You can no longer enter erroneous dates in the Date of Birth field. Resolved inRelease 6.1.SRAQUIK (#87878)Time stamps on the SPRIDEN_ACTIVITY_DATE are now handled accurately andconsistently. Resolved in Release 6.1.SRAPRED,SRAQUIK,SRARECR(#88804)If the Catalog Term field on SRAPRED was left NULL when the recruiting recordwas loaded to Banner from Self-Service, two catalog term issues occurred.1. An error (“Do you want to save your changes?” ) was displayed on SRARECR thefirst time the recruiting record was accessed. This should not have happened,as no changes had been made on the form.2. The first time you accessed SRAQUIK, the Catalog Term value was missing.Then as you tabbed through the record, the Recruitment Term value wasupdated based on the recruiting term.Student Release 7.0 January 2005330 Release Guide Confidential

Section 13 Problem ResolutionsRecruiting ModuleThese issues have been corrected. Resolved in Release 6.1.SRAPRED(No associated number)The Web Electronic Prospect Code field in the Key Block has been renamed theElectronic Prospect Code. Resolved in Release 7.0.SRARECR (#87658)When you entered a value in the Program field, the description of the program wasdisplayed to the right of the entry. When the entry was saved, the descriptiondisappeared. If you used Next Block to continue into the form, an existing programcode was displayed, but not the description. The program code description is notdisplayed in the Curriculum block in Banner 7.0, due to the redesign of SRARECR.Resolved in Release 7.0.SRIPREL,SRKPREL(#96409)When a new prospect was loaded to Banner, the activity date on SOBSEQN was notbeing updated for the ID after the prospect was pushed to Banner and the BannerID was generated. This has been corrected. Resolved in Release 7.0.PackagesSRKPRE1 (#97662)When CREATENEWAPPL rule was set to Y and/or the UPDATEIFAPP rule was setto Y, SRKPRE1 was incorrectly updating the SARADAP_SBGI_CODE field with theSRTPREL_SBGI_CODE field value. The SRTPREL_SBGI_CODE field value should onlyhave been loaded to the SARRSRC_SBGI_CODE field. The SARADAP_SBGI_CODE fieldvalue will no longer be updated/inserted in these circumstances. Resolved inRelease 7.0.SRKPRE1 (#86788)If a person had more than one record in GORVISA with the same visa type, samevisa number, same issued date and start date, and same date requested and end date,SRRPREL displayed an error and failed. This has been corrected. Resolved inRelease 6.1.SRKPREL (#88530)The following error was received SRRPREL was run: “ORA-01427: single-row subqueryreturns more than one row.” This error occurred for a matched person having an SSNloaded as the ID in the temporary table and more than one row in SPRIDEN withthe same SSN in the temporary table. This has been corrected. Also, theSPRIDEN_ORIGIN field will not be changed for matched records. It will be updatedfor new records only. Resolved in Release 6.1.SRKPREL (#88193)Test scores will now be validated on STVTESC upon loading to SOATEST. Resolvedin Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 331

Section 13 Problem ResolutionsRecruiting ModuleSRKPREL (#87318)When the high school rank is entered for Web prospects, and the prospect ismigrated to Banner, the percentile will now be calculated correctly on SOAHSCH.Resolved in Release 6.1.Object:Access ViewAS_RECRUITING_DATAsrvrsr1.sql,srvrcr1.sql(#76547)The view returned incorrect age results in the Current Age and Age When Recruitedfields when a person was deceased. The view returned the age at death for both ofthose fields. This has been corrected. Resolved in Release 6.1.Note: The object srvrcr0.sql was regenerated and is delivered with thisrelease. However, it has not been modified for problem resolution#76547.ReportsSRRPREL (#89520)When the srkpre1.sql package generated a new Banner ID for a student, thegenerated Banner ID was not displayed on the report. SRRPREL will now print thepermanent Banner ID. Resolved in Release 6.1.SRRSRIN (#93217)The report will no longer insert two form feeds between the pages of the DuplicateSection information when there is more than one page of duplicates in the outputand the report is run with the Auto Load (Skip Dup Chk) parameter set to N.Resolved in Release 7.0.SRRSRIN (#93219)When SRRSRIN was run with the Auto Load (Skip Dup Chk) parameter set to Y, onlyone record was printing per page for Page 2 and any additional pages of the reportoutput. This has been corrected. Resolved in Release 6.2.SRRSRIN (#93217)There were two form feeds occurring between the pages of the Duplicate Sectionoutput and the Matched Section output. This has been corrected. Resolved inRelease 6.2.SRRSRIN (#64095)Duplicate records will no longer be listed on the report multiple times. Resolved inRelease 6.1.Student Release 7.0 January 2005332 Release Guide Confidential

Section 13 Problem ResolutionsRecruiting ModuleSRTLOAD,SOTCNVT(#98542)The GMAT data file supplies a four-digit code in positions 349-352 for college code.When FICE codes are used on STVSBGI to define college codes, rather than usingthe four-digit GMAT codes, SRTLOAD incorrectly assigns the wrong college code tothe GMAT records. There is no way to translate the GMAT college codes to the FICEcodes using SOTCNVT. This has been corrected. SOTCNVT will now allow for thesetup for STVSBGI codes, and SRTLOAD will convert the prior college STVSBGIcodes.You now have the option to use SOTCNVT with an Interface Type of GMAT and aValidation Table Name of SBGI. These conversion rules are tied directly to theSRATPFD variable PCOL_SBGI_CODE.• When a conversion rule exists on SOTCNVT for the value on the tape or whena DEFAULT or * rule exists, the converted STVSBGI value will be loaded to thetemporary table and pushed to Banner.• When no conversion rule exists for the code, the SAAERUL value forUNKNOWNPCOL will be loaded to the temporary table and pushed toBanner.• If there is no valid conversion rule and no SAAERUL value exists forUNKNOWNPCOL, no value will be loaded to the temporary table or pushedto Banner.• When there is no valid conversion rule or valid SAAERUL value, a message willbe displayed in the SRTLOAD output file indicating that there is no value to beloaded.Resolved in Release 7.0.SRTLOAD (#92202)When the College Board Student Search Service (SSS) tape was delivered with thePSAT/NMSQT in positions 248-250 and no SAT major in positions 156-158,SRTLOAD would abort with an error when the SAAERUL Rule Label PSATMAJORfor Group Code PREL was set to Y. SRTLOAD will now accommodate these files.Resolved in Release 6.2.Review of Processing SAT Majors and PSAT Majors:Student Search Service (SSS) tape files may include any combination of an SATmajor in positions 156:158 and/or a PSAT major in positions 248:250. Dependingon how your SOTCNVT rules have been built, the major listed in positions 156:158will be the major code that is loaded to the Temporary Table fieldSRTPREL_MAJR_CODE, which is a NOT NULL field. If your SAAERUL Rule LabelLOADMAJOR for Group Code PREL is set to Y, this is the major that will be loadedto the Banner Recruiting Major 1. If a major code appears in positions 159:161, andRule Label LOADMAJOR is set to Y, then this is the major code that will be loadedto the Banner Recruiting Major 2. In addition, all majors listed on the tape will beconverted to interests based on the SAAERUL settings for Rule LabelsMAJOR2INTEREST, LOADINTEREST, and INTERESTMAX for the Group CodePREL.January 2005 Student Release 7.0Confidential Release Guide 333

Section 13 Problem ResolutionsRecruiting ModuleIf a PSAT major is listed on the tape in positions 248:250, and the SAAERUL RuleLabel PSATMAJOR for Group Code PREL is set to Y, then the PSAT major will beloaded in the SRTPREL_MAJR_CODE field, whether or not an SAT major is listed ontape in positions 156:160. This allows you to use the PSAT major on the tape as themajor to be loaded for the Banner Recruiting Major 1, if the Rule LabelLOADMAJOR for Group Code PREL is set to Y. When the PSAT major code isloaded to the SRTPREL_MAJR_CODE field, all the other majors are moved down inorder. So, if an SAT major code is listed in positions 156:158, and the PSAT majorreplaces it, that major code will now reside in positions 161:163 and will be loadedas the Banner Recruiting Major 2, if the Rule Label LOADMAJOR is set to Y. Thesame interests rules would apply at this point in the processing.Note: PSAT major codes and interests are converted differently than SAT majorcodes and interests. Separate rules apply on SOTCNVT. Please see theRecruiting or Admissions procedures sections in the Banner Student UserGuide for further information on Tape Load Processing.SRTLOAD (#84918)DEFAULT and * TERM conversions defined on SOTCNVT were being ignored bySRTLOAD for the recruiting term and catalog term.• The SOTCNVT rules for TERM were loaded first, if they existed.• The SRTLOAD term was loaded second if no SOTCNVT rule existed and theSRTLOAD Term Code parameter had been updated with a term value.• The SRAPRED rule for recruit term was used third if no SOTCNVT rule existedand no SRTLOAD term existed.• The Term 000000 would be defaulted if no prior term had been set up onSOTCNVT or entered on SRTLOAD or SRAPRED.Also, recruiting records were being created with incorrect catalog terms.These issues have been corrected. Resolved in Release 6.1.SRTLOAD (#88804)There are many times that records in data files will include a student's high schoolgraduation date but not a high school code. When SRTLOAD is run, since no schoolcode exists, a row is not created in SRTHSCH for the student, and therefore, theknown graduation year is never stored in the temporary tables. In this situation,SRTLOAD seems to use the default term parameters from SRTLOAD or SRAPRED,and it never checks the original data file for a more accurate term code for theSRARECR record. This has been corrected. Resolved in Release 6.1.SRTLOAD (#87244)In Student Releases 5.6 and 6.0, the use of a Prospect ID was established onSRTLOAD and the Web. The PROSPECT_ID function in SOBSEQN was delivered,as well as the prefix value P.Student Release 7.0 January 2005334 Release Guide Confidential

Section 13 Problem ResolutionsRecruiting ModuleAll prospects loaded into the temporary tables via the Web or using SRTLOADwould have the prefix P. Enhancements were also delivered to SRIPREL migrationprocessing to allow you to generate or enter a new Banner ID to replace theSRTIDEN_ID.When the PROSPECT_ID was changed to equal the Banner ID, duplicate IDs couldresult. If both the Prospect and Banner IDs were set to the same prefix, or both wereset to NULL when loading new records to SPRIDEN from the temporary tables,duplicate IDs could be encountered. Records in the temporary tables would notload and had to be manually processed on SRIPREL.To resolve this, SRTLOAD and electronic prospects will now only load generatedProspect IDs to the temporary table. This will avoid wasting generated Banner IDsthat were also loading to the temporary tables. If the tape or Web prospect has anSSN, and SRTLOAD or SAAERUL is set to use the SSN, the SSN will be loaded tothe temporary table.SRQMTCH had options for you to manually generate a Banner ID or to manuallyenter an ID. Since these IDs would now never be loaded to Banner, generating aProspect ID is the only option available to prevent duplicate errors.SRRPREL and SRIPREL now generate a brand new Banner ID only when loadingthe prospect to Banner the first time. Prospect IDs that were created in thetemporary table SRTIDEN will never be loaded to Banner, unless the SSN waschosen as the temporary ID. Then the SSN will load to Banner if it is found to be aNew record.Note: If you are loading Web Prospects or tape records using the SSN as thetemporary SRTIDEN _ID (SAAERUL: Group PREL, Label WEBGENID,is set to S for Generate ID if Web Prospect or SRTLOAD: SSN orGenerated ID parameter is set to S), and during the matching process(on SRIPREL or SRRSRIN) the record is determined to be New (nomatch in Banner), but a Banner ID does exist that happens to beidentical to the SSN that was loaded into the temporary table, uponloading this New record to Banner (via SRIPREL or SRRPREL), an errorwill appear:142228889 Boatwright,KwameN 200010 UG 000 311420 Potential Dup ID on SPRIDENIn this situation, the record must have a new Prospect ID generated onSRIPREL and/or SRQMTCH in order to be loaded to Banner and soavoid the possible creation of duplicate IDs.Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 335

Section 13 Problem ResolutionsAdmissions ModuleAdmissions ModuleFormsGOAPGEO (#92338)GORPGEO will now run the generate materials package for communication plans,and materials/letters based on the geographic division code and the geographicregion code will also be updated. Resolved in Release 7.0.SAAADMS (#85133)Invalid curriculum errors have been resolved, as the new SORLCUR and SORLFOSAPIs will perform a Rollback if a fatal curriculum error exists. Resolved in Release7.0.SAAADMS (#88265)When Oracle Patchset 13 was applied, the cursor behaved differently when recordswere inserted and copied. Previously, when records were inserted and copied, thecursor would appear in the Term field, and the whole value was highlighted. Afterpatchset 13 was applied, the cursor appeared on the first space to the left of the field.The data in the field was not highlighted. This required users to use extra steps whenprocessing data on this form. They had to highlight the data in order to type over itor otherwise delete the data first. This has been corrected by Oracle 9i. Resolved inRelease 7.0.SAAADMS (#90308)The Item and Item Description fields in the Application Checklist block can bepopulated manually or by selecting a value from the List of Values. If a manuallyentered value is replaced with a value from the List of Values, the description will beautomatically updated. This reflects how these fields worked in the 5.6 version ofBanner. Resolved in Release 7.0.SAAADMS (#89308)The form will now display the administrator’s primary name and not the alternatename. Resolved in Release 7.0.SAAADMS (#92959)Description fields that were truncated in internet native Banner have beenexpanded as part of the 7.0 user interface enhancements. Resolved in Release 7.0.SAAADMS (#89797)The Institution Attended field in the Withdrawal Data block now automaticallyconverts entered codes to uppercase. Resolved in Release 7.0.Student Release 7.0 January 2005336 Release Guide Confidential

Section 13 Problem ResolutionsAdmissions ModuleSAAADMS (#76909)When the GUBINST_FINAID_INSTALLED field was not checked on GUAINST, andthe GUBINST_FINAID_IND field was also not checked on GUAINST, some BannerStudent processes still created records in the SORFADR table. Under theseconditions:• If an ID was created and an SPAPERS record was created, SORFADR wasupdated with a record for that PIDM.• If an ID was created and an SAAADMS record was created, SORFADR wasupdated with a record for that PIDM.• If an ID was created, and an SHADEGR record was created, SORFADR wasupdated with a record for that PIDM.When the GUBINST_FINAID_IND field is set to N, no SORFADR row should becreated.The following objects have been modified to correct this:• saaadms.fmb• saadcrv.fmb• saaquik.fmb• sgastdn.fmb• shadegr.fmb• shatrns.fmb• siafdeg.fmb• smarqcm.fmb• soapcol.fmb• spaiden.fmb• spapers.fmb• sfrrnop.pc• shkcgpa.sqlResolved in Release 6.1.SAADCBT (#98027)The 7.0 user interface project allows the form canvas to display all fields without ahorizontal scrolling bar. The ratings information has been moved to a separatewindow that is accessed by a tab. Resolved in Release 7.0.SAADCBT (#87055)When SAADCBT updated the Key Block decision code in SAADCRV, it also changedthe application status (SARADAP_APST_CODE) from an I or C to a D (Decision Made).This occurred for decision codes where the STVAPDC_SIGNF_IND field was NULL.These types of decision codes should not change the application status, as they donot change it when the code is entered directly onto SAADCRV. This has beencorrected. Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 337

Section 13 Problem ResolutionsAdmissions ModuleSAADCRV (#89840)Three issues have been resolved.1. The Outstanding Documents field in the Application Summary block wasdisplaying the reverse value. If outstanding checklist items existed, the fielddisplayed a NULL value rather than a Y. If you performed an Execute Query,the Y value would appear. This has been corrected.2. Querying in the Application Summary block was not working correctly. If anApplicant had three SAAADMS records:200310 - Application 1200410 - Application 2200410 - Application 3Application 3 for 200410 was displayed first. If a query was performed for200310 - Application 1, the results again displayed the first application (200410- Application 3). This has been corrected.3. The scroll bar is no longer disabled.Resolved in Release 7.0.SAAEAPS (#94778)The SARHEAD_APPL_COMP_IND field and the SARHEAD_COMPLETE_DATE field arenow working correctly. When the SARHEAD_APPL_COMP_IND is checked, theSARHEAD_COMPLETE_DATE field is populated. When the SARHEAD_APPL_COMP_INDis unchecked, the SARHEAD_COMPLETE_DATE field will be NULL. Resolved inRelease 7.0.SAAEAPS (#85103)You will no longer have difficulty accessing a Web ID on SAAEAPS if the Webapplicant has inserted an initial or trailing blank when creating their login ID.Resolved in Release 6.1.SAAERUL (#78626)You will no longer receive the following error when INTERESTMAX is not definedon SAAERUL: “Configuration Error - No data found in table SARERUL -INTERESTMAX.” This was corrected under problem resolution #88804. Resolved inRelease 6.1.SAAETBL (#90239)A truncation error occurred on the SARADDR_NATN_CDE field when Web applicationdata was viewed that had four or more digits. Only the first three digits weredisplayed. This could cause the nation code match to be incorrect. The itemproperties for the field have been changed from three to five. Resolved in Release7.0.Student Release 7.0 January 2005338 Release Guide Confidential

Section 13 Problem ResolutionsAdmissions ModuleSAAQUIK (#94244)GOPVALT1.sql was causing improper error messages to appear with Value-BasedSecurity. This has been corrected.Previously, the concept for VBS access was that a recruit record, admissions record,or a general student record already existed for the person. The record was one towhich the user did not have access. Consequently, the user could not access thatperson at all, even to add a valid row, (one to which the user did have access). ThePIDM was unavailable for that module. Now, the concept has changed so that thePIDM will always be available for the addition of a valid row, (one to which the userhas access). Banner will no longer check the existing rows for the validity of accessto that person (PIDM). Resolved in Release 7.0.SAAQUIK (#89505)If a ZIP code corresponded to more than one city or state on GTVZIPC, when thatZIP code was entered on SPAIDEN, the form defaulted in the last city listedalphabetically, with the message: "WARNING-Multiple Cities exist for this ZIP/Postalcode; press LIST to select one." However, in the Address Information window onSRAQUIK or SAAQUIK, the form populated the first city alphabetically, and nowarning message was displayed. The correct city will now be populated, and thewarning message will be displayed. Also the warning message has been modified toread the same on SRAQUIK, SAAQUIK, and SPAIDEN. Resolved in Release 6.1.SAAQUIK (#84905)When searching for a ZIP code from the Address Information block, if more thanone city existed for a ZIP code, selecting any of the cities would always return thefirst city alphabetically listed. The correct city is now returned. Resolved in Release6.1.SAAQUIK (#85416)In the situation where, if a student record already existed for a given term and level,and registration existed but for a term other than the one in the Key Block, you weresupposed to receive the following error message: "*ERROR* Student record exists forterm, use a different term." This error will now be displayed correctly. Resolved inRelease 6.1.SAAQUIK (#86779)When adding a second major in the Primary Curriculum window, after you pressedEnter or Tab, the department code for Major 2 was defaulted into the Dept 1 field,which is associated with Major 1. The Dept 2 field was left blank. This caused a fatalcurriculum error. You had to manually enter the Dept 2 value, and then manuallyre-enter the Dept 1 value. Now, when you Tab out of Major 1 or Major 2, theassociated department codes will automatically default in for the correct major.Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 339

Section 13 Problem ResolutionsAdmissions ModuleSAAQUIK (#84570)Values for major and department did not default from SOACURR when a programwas entered manually rather than by using the Quick Admit rules. Only one majorand department were defined for the program on SOACURR. Other values such asdegree and level were updated from SOACURR. This has been corrected. Resolvedin Release 6.1.SAAQUIK (#87878)Time stamps on the SPRIDEN_ACTIVITY_DATE are now handled accurately andconsistently. Resolved in Release 6.1.SAARRAT (#89519)The administrator name will now be displayed whether or not the Confidential(Indicator) has been checked on SPAPERS. Resolved in Release 7.0.SAARRAT (#90862)The length of the SARADAP_COLL_CODE_2 field has been expanded to threepositions to prevent a truncation error caused by the campus code for the secondarycurriculum on SAAADMS. Resolved in Release 7.0.SAARRFT (#79613)The SSRRRFT table had a unique constraint that did not containSARRRFT_DEGC_CODE. This has been corrected. Resolved in Release 6.1.SAAWADP (#84751)When you attempted to remove the last record in the form and then performed aSave function, a "Field must be entered" error message was displayed in the Auto Hintline. When you used Rollback or Exit, a message box was displayed requesting thatyou save the changes. This has been corrected. Resolved in Release 6.1.SAAWAPP (#86152)You will no longer receive the message: "ERROR-Only 20 free format questions willdisplay on the Admissions Additional Information Web Page; only 10 free format questions willdisplay on the other Admissions Web pages." when trying to add questions to theAdditional Information section of the online application, and you have more than10 but less than 20 questions defined. Resolved in Release 6.1.TableSARPERS andSAKP020(#77087)The SARPERS_LAST_NAME field has been expanded from 35 characters toVARCHAR2(60) so that it matches the length used by SPRIDEN when a last name isentered through Web Admissions. Resolved in Release 6.1Student Release 7.0 January 2005340 Release Guide Confidential

Section 13 Problem ResolutionsAdmissions ModulePackagesSAKENRL (#88715)You will no longer receive the following error when you enter a date range in theKey Block of SFARQST: “FRM-40735: VALIDATE_KEYS trigger raised unhandledexception ORA-04067.” Resolved in Release 6.1.SAKL020,SAK1020,SAK1060,SAK1090(#85239)Problem resolution #82804, delivered in ED posting p80513, corrected the issuewhere the package was not updating the SPBPERS_ACTIVITY_DATE when the pushresulted in a change to the record. However, now the SPBPERS_ACTIVITY_DATE isupdated, regardless of any other SPBPERS record changes. SAKL020 (SPBPERS),SAKL060 (SORHSCH), and SAKL090 (SORDEGR) have been modified to correctthis. Resolved in Release 6.1.SAKL020 andsinsprtn.sql(#85389)On SAAWAPP, the Web Section value of Name, has an Element Code of Prev_Last.However, when information is filled in by the applicant on the Web and pushed, theinformation is not populated in the Alternate Identification block of SPAIDEN.There do not seem to be any Verification Procedures/Routines for pushing thisinformation.This has been corrected. Routine R0030 (Previous Last Name Check) has beenadded to Procedure P020 (Name Verification) on SAAECRL using the scriptsinsprtn.sql. Resolved in Release 6.1.SAKL060 (#93299)The high school graduation date from Web applications is now converted andpushed into Banner properly during the load process on SAAEAPS. Resolved inRelease 6.2.SAKL140 (#88117)You will no longer receive an error when loading test scores and pushing themthrough SAAEAPS, when the student’s test score already exists in SORTEST.Resolved in Release 6.1.SAKMOD (#84617)The st_spriden_name_compress trigger and the p_insert_spriden procedurein sakmod1.sql both compress the SPRIDEN name and then convert it to uppercase.The newer object in SAKMOD is redundant. This is resolved using the new commonSPRIDEN API for all names and IDs that are entered into the database. Resolved inRelease 7.0.SAKMTC1 (#86543)SARETMT was creating duplicate IDs in Banner when:January 2005 Student Release 7.0Confidential Release Guide 341

Section 13 Problem ResolutionsAdmissions Module• The Match Only on SSN and Last Name parameter was set to Y (for Yes), andthe SSN or Generated ID parameter was set to S (for SSN).• The incoming Web application had the same SSN as an existing SSN withinBanner.• That existing Banner SSN was also that person's Banner ID.Because the value in the Match Only on SSN and Last Name parameter was Y andthe value in the SNN or Generated ID parameter was S, the incoming record wouldhave been marked as New. However, since the incoming record's SSN equaled anexisting Banner ID, duplicate records were being created. Now, even if a record isfound to be New based on the matching algorithm, it will be marked as Suspended ifthe SSN matches an existing Banner ID. Resolved in Release 6.1.SAKMTCH (#72839)When SRRSRIN is run with the Match Only on SSN and Last Name parameter set toY, it will no longer update the match status to M (Match) and leave the PIDM null.Resolved in Release 6.1.SAKMTCH (#88853)For columns where you could specify the match length in SORINFR, there were twodifferent methods used, and they did not necessarily produce the same results. Thishas been corrected. Resolved in Release 6.1.SAKQAD1 (#89284)Admissions holds will now be released on the same day as the date entered in the To(Date) field on SOAHOLD. The function f_check_appl_hold cursor and theget_appl_hold_c where clause have been modified to correct this. Resolved inRelease 6.1.Object:Access ViewAS_ADM_APPLI-CATIONsafdcsn.sql(#80623)Application decision codes will now be reported in the correct order in the view,based on the timestamp for the decision code on SAADCRV. Resolved in Release6.1.Banner ViewsSAVLIF1 andSRVLIF1(#74708)Calls from the views to the F_TEST_SCORE_FNC function for the SAT_MATH andSAT_VERBAL test scores will no longer return NULL values. The argument for theWHICH_ONE parameter is now set to HIGH to return the individual score. Resolvedin Release 6.1.Student Release 7.0 January 2005342 Release Guide Confidential

Section 13 Problem ResolutionsAdmissions ModuleReportsSAPAMAL (#79354)The process no longer performs intermittent commits while in Audit Mode.Resolved in Release 6.1.SAR189U (#94402)The process will no longer produce an Oracle error if the SST01 segment is presentby itself, without any SSE lines or other optional segments. Resolved in Release 6.2.SARBDSN (#88936)When you enter % for all terms in the Applicant Entry Term parameter and entera decision code in the Application Decision Code parameter, the process will nowlist all applicable IDs. Resolved in Release 6.1.SARBDSN (#78535)This problem resolution has three parts.1. If a record on SAAADMS had the following primary curriculum values: Major1/Department 1, Concentration 1, 2, 3; Major 2/Department 2, Concentration1, 2, 3; Minor 1 and Minor 2; when SARBDSN created the SGASTDN record,only the following values were created in the primary curriculum: Major 1/Department 1 and Concentration 1.2. When SARBDSN created the SGASTDN record, the Catalog Term value wasnot carried over from SAAADMS.3. When SARBDSN created the SGASTDN record, the Create/Update AcademicHistory Degree Record field was not checked (set to Y) in the PrimaryCurriculum window, although the SOACURR rules for that program codeindicate that it should have been.These issues have been corrected. Resolved in Release 6.1.SAREBTL (#62924)Overlapping and misalignment of data on the output that occurred when the SSNwas missing has been corrected. Resolved in Release 7.0.SARRATE (#88175)The process is now using effective term functionality when evaluating the factorcodes associated with a formula. Resolved in Release 6.1.SARRATE (#84991)You will no longer encounter an error when more than two pages of data aregenerated. Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 343

Section 13 Problem ResolutionsGeneral Student ModuleGeneral Student ModuleFormsSGACOOP (#84736)When free form comments were entered in the Comments Block, the entire line washighlighted and erased when the user typed a character in the last position of theline/field. This has been corrected. Resolved in Release 6.1.SGAASTQ (#74861)You can now query on criteria in all fields whether you access the form directly orfrom SGAASST. Resolved in Release 7.0.SGASADD andSGASTDN(#88640)A warning message will now be displayed when an attempt is made to update/change a value which may have an impact on fee assessment. Resolved in Release7.0.SGASTDN (#74960)If you queried on and selected a block code in the Additional Student Informationwindow, you were not returned to this window. Instead the Academic Status windowwas displayed. This has been corrected. Resolved in Release 7.0.Please note that in Banner 7.0, the Additional Student Information window hasbeen removed. The information from that window is now displayed in theAdditional Information block of the main window. Also, the Academic Status,Graduation Data, and Dual Degree windows have been combined into one windowaccessed by the Academic and Graduation Status, Dual Degree tab.SGASTDN (#77367)When a general student record is created through an admissions decision onSAADCRV, the SGBSTDN_ACTIVITY_DATE includes a time stamp. When theSGASTDN record is created from SAAQUIK, there is no time stamp on theSGBSTDN record. The API delivered in Banner 7.0 has corrected this issue.Resolved in Release 7.0.SGASTDN (#87669, #84908, #68885, #67459)Updates to curriculum records with registration on SGBSTDN were not correctlyidentified. SGASTDN now passes a restrictive message to the new curriculum blocks.If the message exists, a form trigger failure is raised when an Insert, DuplicateRecord, and Delete are attempted on the new SORLFOS and SORLCUR blocks.Resolved in Release 7.0.Student Release 7.0 January 2005344 Release Guide Confidential

Section 13 Problem ResolutionsGeneral Student ModuleSGASTDN (#92689)The major code description was not being populated correctly. The major code andits description have been moved to the new SORLFOS block, and this has beencorrected. Resolved in Release 7.0.SGASTDN (#85133)Invalid curriculum errors have been resolved, as the new SORLCUR and SORLFOSAPIs will perform a Rollback if a fatal curriculum error exists. Resolved in Release7.0.SGASTDN (#84235)When a program was updated, and you tried to access the Primary Curriculumwindow to update the major information, you were forced to save the changes. Thiscaused a fatal warning primary curriculum message to be displayed. Once themessage was accepted, you could continue the update.This has been corrected as part of the Concurrent Curriculum enhancement. Thecurriculum data has been moved off of the SGBSTDN table and onto the newSORLCUR and SORLFOS tables. Curriculum data is entered in the new curriculumblocks on SGASTDN. The Primary Curriculum window is no longer used.Resolved in Release 7.0.SGASTDN (#67459)The Major 1 (Description) in the Primary Curriculum window was displaying thewrong description and could not be changed because registration existed for thestudent. With the redesign of the form and the addition of the Curricula block, thishas been corrected. Resolved in Release 7.0.SGASTDN (#73133)The Secondary Curriculum button was active, but the bubble help message read “NoData”, when data existed for the student. With the redesign of the form and theaddition of the Curricula block, the Primary Curriculum and Secondary Curriculumbuttons have been removed. A tab is now used to access the curriculum information.Resolved in Release 7.0.SGASTDN (#89055)The message "ERROR-Both progress evaluation standing and term must be filled in or bothmust be blank..." was displayed when you tried to update an SGASTDN record after ithad been duplicated for a new effective term using SFAREGS. This has beencorrected, and override values are now left blank on the new term record. Resolvedin Release 7.0.SGASTDN (#92681)An SGASTDN record could be updated even though this change affected feeassessment for a term in which registration had already occurred. If a term withregistration records existed, then the system should have required that the changebe made using SFAREGS. This has been corrected. Resolved in Release 7.0.January 2005 Student Release 7.0Confidential Release Guide 345

Section 13 Problem ResolutionsRegistration ModuleSGASTDN (#88399)When you accessed GUASYST from SGASTDN, the ID that appeared in GUASYSTwas the previous one used by that form, not the ID from SGASTDN. The ID fromSGASTDN is now carried to GUASYST. Resolved in Release 7.0.SGASTDN (#94244)GOPVALT1.sql was causing improper error messages to appear with Value-BasedSecurity. This has been corrected.Previously, the concept for VBS access was that a recruit record, admissions record,or a general student record already existed for the person. The record was one towhich the user did not have access. Consequently, the user could not access thatperson at all, even to add a valid row, (one to which the user did have access). ThePIDM was unavailable for that module. Now, the concept has changed so that thePIDM will always be available for the addition of a valid row, (one to which the userhas access). Banner will no longer check the existing rows for the validity of accessto that person (PIDM). Resolved in Release 7.0.Object:Access ViewSGVSTD2 (#88056)Certain GPA-related substring functions had not been modified to accommodatethe larger values that can now be used as a result of the Expanded Credit Hour andGPA functionality. The result was that the view AS_STUDENT_DATA could potentiallyreturn null values for GPA fields. The necessary modifications have now been addedto this view. Resolved in Release 6.1.Registration ModuleFormsSFAALST (#45466)The ID global variable (the ID of the last student queried) was not being populatedcorrectly, and as a result, was not being used when student information was queriedfrom the Class Attendance Roster Form (SFAALST). To correct this, changes weremade in the Options Maintenance Form (GUAOPTM). No form changes wererequired on SFAALST. The ID of the student associated with the row the cursor isplaced on will now be used to populate the Key Block of the General PersonIdentification Form (SPAIDEN) when using the ID, Names, and Addresses option.Resolved in Release 6.1.Student Release 7.0 January 2005346 Release Guide Confidential

Section 13 Problem ResolutionsRegistration ModuleSFAALST (#77855)The Date field, which displays the activity date of the individual student record, wasnot accessible except by using the scoll bar at the bottom of the form. Thenavigation has been modified. It is now possible to perform a Next Field from theGrade Comment field to view this field. This field is query only, and no updates areallowed. Resolved in Release 6.1.SFAALST andSFASLST(#78913)Security access, as defined in GSASECR, prohibits the entering of grades. However,this was not effective in restricting the rolling of grades to Academic History.Therefore, if the user has query only access to SFAALST or SFASLST, and they try tocheck the Roll checkbox in the Key Block, they will not be permitted to do so andwill receive the following message: “*ERROR* Your security access prohibits the rolling ofgrades. Contact your data administrator.” Resolved in Release 6.1.SFAFAUD (#87675)When using the Options Menu to navigate to either SFAREGF, TSAAREV, orTSADETL, the ID in the Key Block of those called forms was the Previous ID usedin the Key Block of SFAFAUD. The ID was not defaulting into those forms whenusing the Options Menu. This has been corrected. Resolved in Release 6.1.SFAFAUD (#87251)An Oracle error occurred when users attempted to run the process to purge all ofthe transactions. This has been corrected. Resolved in Release 6.1.SFAREGF (#88342)SFRFAUD records were not being deleted after mock assessment had beenperformed more than once without exiting SFAREGF. This may have causederroneous results in subsequent assessments using SFAREGS. The mock assessmentprocess now deletes the SFRFAUD rows when the user rolls back or exits out of themock assessment. Resolved in Release 6.1.SFAREGF (#88518)The amount in the Total Charge field was calculated incorrectly if fee assessmentproduced more than the eight transaction records displayed in either the FeeAssessment With Min/Max Applied or Fee Assessment Without Min/Max AppliedMock Assessment windows. This has been corrected. Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 347

Section 13 Problem ResolutionsRegistration ModuleSFAREGS (#89784)When section status was changed from allowing registration to not allowingregistration after the section was on the student's schedule, and the courseregistration status code was then changed to one that counted in enrollment(whether the prior course registration status code had been counted in enrollmentor not), the Message field remained blank, but the auto-hint displayed "Studentschedule has errors. Correct or delete to continue." This has been corrected. Resolved inRelease 7.0.SFAREGS (#93483)The “Registered” message should not be displayed for a course until all errors havebeen satisfied. This has been corrected. Resolved in Release 7.0.SFAREGS (#93951)The form will no longer hang when a course is added by entering the subject, courseand section, rather than the CRN, if the course is a duplicate of one that alreadyexists on student's schedule. Resolved in Release 7.0.SFAREGS (#90200)Previously, you could change the student ‘s status to one that did not allowregistration, without receiving any warning that the student had active registrationrecords. Now, you will receive an alert message if this occurs. You will also not be ableto proceed to the SFTREGS block if registration is prohibited. Resolved in Release7.0.SFAREGS (#93166)When using the Delete all CRNs functionality, it was possible to not have feesassessed online or a collector record created. You could use Rollback or Exit fromthe SFBETRM and SFTREGS blocks without using Save. This has been corrected,and you can no longer exit from the form without saving your changes. Resolved inRelease 7.0.SFAREGS (#91298)When on-line assessment was disabled on SOATERM, and changes for a studentwere made through the Student Term window, a fee assessment collector record(SFRBTCH) was not being created. This has been corrected, and a collector recordis now created. Resolved in Release 7.0.SFAREGS (#94395)When no SFRTHST records existed prior to the manual addition of a time status,the date comparison in the SFRTHST PRE-INSERT trigger didn't work, because it wascomparing the TMST_DATE on the USER-created record to NULL. Consequently,the SFBETRM_TMST_... fields were not being updated, which allowed SFRTMST tocreate a SYSTEM record, even though a USER record already existed. This has beencorrected. Resolved in Release 6.2.Student Release 7.0 January 2005348 Release Guide Confidential

Section 13 Problem ResolutionsRegistration ModuleSFAREGS (#93575)The Options Menu was not displaying the associated form names for the options ifthe user preference on GUAUPRF was set to display the Menu Bar Options. Thiswas corrected by updating the appropriate Form Called information for theSFAREGS records that are displayed in the Options Maintenance Form(GUAOPTM). Resolved in Release 6.2.SFAREGS (#89995)SFRFASC was calculating the fees correctly, but when a registration was backdated,the current date was being used in the accounting. When a registration wasbackdated, SFAREGS used the current date, instead of picking up the backdate.This affected backdated refunds, especially if backdating was done in a refund bytotal period. This has been corrected. Resolved in Release 6.1.SFARGFE (#95879)When you entered rule and entity types, selected the Copy Rules to New Termbutton, and then manually entered the program code in the Registration Chargesand Fees block, you received a form error. This has been corrected. Resolved inRelease 7.0.SFARCTL (#93479)The Duplicate Record function was causing difficulties when a Rollback was used,after an ORACLE INSERT error had occurred, and changes could not be saved.This can be prevented by clicking in the Key Block, changing the term code value,and saving the records for the new term. The Key Block term code has been disabledwhen there are errors pending in the main block. Resolved in Release 6.2.SFAREGS (#84990)If the SFRSTCR_RSTS_DATE was not within the date range for the course registrationstatus code in SFARSTS, an error message was displayed: “*ERROR* STATUSFunction cannot be performed at this time. Press CLEAR BLOCK" for every previouslyexisting course where the course registration status code was no longer valid.A trigger has been adjusted to allow one error status message to be displayed whenthe SFRSTCR_RSTS_DATE is no longer valid. Resolved in Release 6.1.SFAREGS (#84524)The error that occurred when data was “Extracted With Key” has been corrected.Resolved in Release 6.1.SFAREGS (#87856)If audit records were not created as part of the Release 5.6 migration, and a changein student data occurred without a change in registration data and then anassessment was performed, the audit records used to capture the snapshot of the lastassessment were not created due to the registration data not being changed. Thisprevented the needed reversals based on the change in student data from occurring.A function has been added to create the audit record (if none exists) when NextBlock is used from the Key Block of SFAREGS. Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 349

Section 13 Problem ResolutionsRegistration ModuleSFAREGS (#85260)When dropping a course that had been graded, the "Warning-Course has been graded"message was only displaying in the auto hint line. This has been adjusted to displayin the auto hint line and provide a pop-up window message. Resolved in Release 6.1.SFAREGS (#89015)When using the Time Status History window to manually insert a time status that hasa older time status date than the current time status for a student, the SFBETRMrecord was being updated with the older time status information. This has beencorrected so that the most recent time status data is in the SFBETRM record.Resolved in Release 6.1.SFAREGS (#68167)Hold dates were not being evaluated correctly when the (Registration) Date in KeyBlock was back-dated. This has been corrected. Resolved in Release 6.1.SFAREGS (#83473)When you were in the Key Block, and ETRM record was displayed, you could do aPrevious Block function, which caused problems with security access. This has beencorrected. Resolved in Release 6.1.SFAREGS (#71446)The ID in the Key Block was not carried to another form if the ID was changed andthen a new form was selected using the Direct Access option from the Oracle Filemenu. This has been corrected. Resolved in Release 6.1.SFAREGS (#51776)If an administrator changed the SSBSECT_PTRM_CODE, when the student’sregistration was reinstated, the new PTRM code did not get moved into the courserecord. This has been corrected. Resolved in Release 6.1.SFAREGS (#84259)Error messages will no longer be displayed when enrollment statuses are updated.Resolved in Release 6.1.SFAREGS (#83922)When an enrollment status was changed to one which did not affect the course butwhich did prevent registration (on STVESTS), the following error was receivedwhen that status code was entered on SFAREGS: "Enrollment Status prohibitsregistration." After acknowledging this message, the auto help area displayed: "FRM-40700: No such trigger CHECK_OUT." The SFBETRM_ESTS_CODE was changed,however, and fees could be assessed. This has been corrected. Resolved in Release6.1.SFAREGS (#77925)When the CRN was incorrectly typed and then overtyped with correct CRN, the levelcode was not being changed to the new level code. This was causing a student toStudent Release 7.0 January 2005350 Release Guide Confidential

Section 13 Problem ResolutionsRegistration Modulepossibly be registered in the wrong level. This has been corrected. Resolved inRelease 6.1.SFAREGS (#85768)When a new course was added and a fatal error encountered, the removal of thatcourse was not being recorded in SFRSTCA table. This has been corrected so thatdeleted records will also generate a transaction in SFRSTCA. Resolved in Release6.1.SFAREGS (#87408)The previous assessment date (SFBETRM_ASSESSMENT_DATE) will now displaycorrectly. Resolved in Release 6.1.SFAREGS (#89258)When courses were removed using the Delete all CRNs? checkbox, and you selectedthe N - Batch for Updates option in the Fees field for fee assessment processing, nocollector record was being written to SFRBTCH. This has been corrected.With the introduction of the Registration Fee Assessment Process (SFRFASC) inBanner Releases 5.6 and 6.0, the three options for use with fee assessmentprocessing in the Fees field became obsolete. There are only two valid options foruse with fee assessment: Y(es) - Immediate assessment or N(o) - Create collector record. Theoptions for the Fees field have been updated to reflect these choices.Resolved in Release 6.1.SFARHST (#88461)When multiple extension codes were available in the Extension block, and you triedto insert a new record and then select a status code, an error message was displayed,and the ability to insert a record was denied. You can now select the appropriatestatus code after the Insert Record has been performed. Resolved in Release 6.1.SFARQST (#90295)You can now request an enrollment verification for a student with a pre-Bannerregistration term. Resolved in Release 7.0.SFARQST (#82020)The hold override password did not work if registration was not permitted in theterm. This has been corrected. Resolved in Release 6.1.SFARQST (#88524)When Pers/Comp field was null and you entered an address type in the Addr Typefield, the student's name was defaulted in, but not the student's ID. This resulted inthe name not being stored in SFRENRL, so it was not displayed the next time therecord was queried. This has been corrected. Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 351

Section 13 Problem ResolutionsRegistration ModuleSFARQST (#85718)You will no longer receive the error "FRM-40508: ORACLE error unable to INSERTrecord" and "ORA-01401:Inserted value to large for column" when you enter a namelonger than 30 characters in the Forwarding Name field and use Save. This wascorrected when problem resolution #67754 was resolved in Release 5.6. Resolved inRelease 6.1.SFASLST (#49817)When the Course Section Detail option is selected from the main window, theSchedule Form (SSASECT) will now be displayed. Also, when you return to the formafter selecting the View Summary of Section option from the Key Block, the cursorwill be placed in the Key Block. Resolved in Release 6.1.SFARGRP (#93475)The display length of the Group Priority field was set to four characters instead offive. When a group code with a five-character priority value was assigned to astudent, the field value was displayed as ####. This has been corrected. Resolved inRelease 6.2.SFIRGRP (#93476)The display length of the Group Priority field was set to four characters instead offive. When a group code with a five-character priority value was assigned to astudent, the field value was displayed as ####. This has been corrected. Resolved inRelease 6.2.SFIRGRP (#91646)The CONFIDENTIAL message was displayed incorrectly for students when theSPBPERS_CONFID_IND field was set to N. This has been corrected. Resolved inRelease 6.2.SFIRGRP (#79884)The form showed the total count of people in the group but did not display the listof students in the group. The list of students is now displayed. Resolved in Release6.1.SFQSECM (#76541)When accessing SFQSECM (from SFAREGS) the cursor no longer disappears and iscorrectly positioned in the CRN field. Resolved in Release 7.0.SFQSECM (#87719)When using SFQSECM (from SFAREGS) to search for an alternate class, openlearning courses were not considered in the time conflict checking. As a result, theTC (Time Conflict Indicator) did not contain an asterisk. The TC (Time ConflictIndicator) is now activated for open learning sections. Resolved in Release 6.1.Student Release 7.0 January 2005352 Release Guide Confidential

Section 13 Problem ResolutionsRegistration ModulePackagesSFKCURS (#92036)This package has been modified to correct performance problems when gradeswere displayed in self-service, specifically the delay that existed when terms havingposted grades were displayed. Resolved in Release 6.2.SFKCUR1 (#85264)This package has been modified so that Term is now available for selection for“Grade Detail” in self-service when there is an error flag of W (Warning), andwarning messages exist for the registration record (CRN). Resolved in Release 6.2.SFKCUR1 (#93402)This package has been modified so that ungraded courses with an error flag of W(Warning), as well as an error message, are now listed on the Midterm Grades Webpage. Resolved in Release 6.2.SFKCURS,SFKCUR1SFKCURS andSFKCUR1(#93759)These packages have been modified to correctly display in self-service only thosesubject codes that have classes created for the term or date range, that have beenweb-enabled on STVSUBJ. Resolved in Release 6.2.(#49132)Courses will no longer be inappropriately dropped due to re-evaluation. Resolved inRelease 6.1.SFKEDIT1 (#92836)It is no longer possible for a student to register via the Web for part of a linkedsection, when they attempt to drop one section and replace it with another section,and that results in a time conflict. Resolved in Release 6.2.SFKEDIT1 (#93898)The deadlocking error message should no longer be displayed in Web registration.The p_update_regs procedure has been modified to correct this. CRNs for thePIDM and term are now locked all at one time, instead of as each CRN is updated.Courses are now locked in CRN order. Resolved in Release 6.2.SFKEDIT andSFKEDIT1(#88546)Courses added or dropped from the Web are now properly updating theSFRSTCR_CREDIT_HR_HOLD and SFRSTCR_BILL_HR_HOLD fields. Resolved inRelease 6.1.January 2005 Student Release 7.0Confidential Release Guide 353

Section 13 Problem ResolutionsRegistration ModuleSFKFEE1 (#93655)The Copy Rules to New Term functionality was not working properly when identicalrules existed as PREBILL and REGULAR entry types. When these identical rulesexisted, only the PREBILL entry type rules were being copied. The REGULAR entrytype rules were not being considered. This has been corrected, so that each rule typeis considered when rules are copied to another term. Resolved in Release 7.0.SFKFEE1 (#93498)When using grade mode, instructional method, or schedule type rules, SFARGFErequired that Assess by Course (Indicator) be checked (set to Y). However, once therule was created, you could uncheck the Assess by Course (Indicator) save thechange. This has been corrected, and users are now prohibited from turning off theAccess By Course (Indicator) for these types of rules. Resolved in Release 7.0.SFKFEE1 (#91541)When an SFAFMAX rule was created after an initial assessment, this rule was notbeing enforced upon subsequent runs of SFRFASC. This has been corrected.Resolved in Release 7.0.SFKFEE1 (#94329)If Track by CRN was enabled when Drop all CRNs functionality was used, and thenthe enrollment record (SFBETRM) was removed, reversals of section fees werebeing written without the CRN. This caused erroneous subsequent assessments ifthe student re-registered. This has been corrected. Resolved in Release 7.0.SFKFEE1 (#96425)When SFKFEE1 checked that the assessment transactions were the first for the termfor the PIDM being processed, the variable storing the Original Charge Indicatorvalue (ORIG_CHG_IND) was set to Y, but this variable was not being reset before thenext PIDM was processed. This has been corrected. Resolved in Release 7.0.SFKFEE1 (#95935)When the last course was dropped during a 100% course refund and a mockassessment was performed using SFAREGF before the actual assessment wasperformed, the actual assessment was not issuing the refund, since the lastassessment date had been updated by the SFAREGF mock assessment. This hasbeen corrected. Resolved in Release 7.0.SFKFEE1 (#93995)When online assessment was disabled on SOATERM, and the SFBETRM record wasremoved via SFAREGS when registration accounting transactions existed,registration charges were not being reversed. The Update p_process_etrm_droptrigger has been modified to include setting the variable create_accd_ind to Y toallow TBRACCD inserts to occur. Resolved in Release 7.0.SFKFEE1 (#89864)Additional fees from SFAAFEE/SFAEFEE will now be assessed when a totalwithdrawal is performed. Resolved in Release 7.0.Student Release 7.0 January 2005354 Release Guide Confidential

Section 13 Problem ResolutionsRegistration ModuleSFKFEE1 (#91660)Incorrect results for reversals were calculated when the course status code did notcount in assessment, the course status code was used during an SFARFND refundperiod, and the clearing account detail codes were used. Instead of calculating a100% reversal, the process incorrectly calculated a penalty. The correct result wasreceived if no clearing account detail codes were used on SFARFND. This has beencorrected so that no penalty is calculated. Resolved in Release 7.0.SFKFEE1 (#91956)When future dating was used in the Key Block on SFAREGS, the future effective datewas not being captured and saved correctly in Accounts Receivable, when theTSACTRL effective date was set as the date of the charges. This has been correctedso the future date is reflected. Resolved in Release 6.2.SFKFEE1 (#91982)Penalties should not have been calculated when an ESTS refund was in effect andrefund by total was enabled for the term. This has been corrected. Resolved inRelease 6.2.SFKFEE,SFKFEE1(#91555)Non-refundable fees were being reversed. When a student no longer qualified for acharge to a detail code having a category code other than TUI or FEE, the chargeswere being reversed. Some institutions want only TUI and FEE charges to qualify forreversal. There is now an option to reverse or not reverse charges to detail codeshaving a category code other than TUI or FEE.A new GTVSDAX rule can be created with an Internal Code of FAREVNRF for aGroup Code of FEE ASSESSMENT with a default value of N for the External Code.When the value of N is used, charges to detail codes having a category code otherthan TUI or FEE will not be reversed during fee assessment. For institutions that wishto use the reversal, the GTVSDAX rule should be updated to an External Code of Y.If GTVSDAX is not updated, the External Code will be set to N.Note: In the absence of a GTVSDAX rule, assessment will default to notreversing charges to detail codes with a category code other than TUIand FEE.The new rule on GTVSDAX is delivered by SunGard SCT in a script.External Code Internal Code Internal CodeSequence NumberInternal Code Group Description Activity DateN FAREVNRF FEE ASSESSMENT Reverse Non-TUI/FEEChargesSysdateResolved in Release 6.2.January 2005 Student Release 7.0Confidential Release Guide 355

Section 13 Problem ResolutionsRegistration ModuleSFKFEE1 (#89820)Tuition and fees are now being reversed when a student drops a course from theWeb using the DW drop code. Resolved in Release 6.1.SFKFEE1 (#89241)Dropping a student in an active refund period when using flat rule processing(plateaus) did not calculate the correct refund when the SFARGFE rules in use wereset by course level. (The Rule Type field was set to LEVEL.) This also occurred forthe course campus and course attribute rules. (The Rule Type field was set to eitherCAMPUS or ATTR.)Fee assessment processing has been corrected so that when "plateau" charging isused and refunding rules are set for level, campus, and/or attribute processing, theresults are now consistent with when the rules are set for student processing. (TheRule Type field is set to STUDENT.) Resolved in Release 6.1.SFKFEE1 (#89995)SFRFASC was calculating the fees correctly, but when a registration was backdated,the current date was being used in the accounting. When a registration wasbackdated, SFAREGS used the current date, instead of picking up the backdate.This affected backdated refunds, especially if backdating was done in a refund bytotal period. This has been corrected. Resolved in Release 6.1.SFKFEE1 (#89300)When a section fee was assigned to a student, the Note field in the Detail AuditInformation window contained a dollar ($) sign for currency in the text. As this wasnot appropriate for international users, the $ has been removed from the Notesfield. The $ sign will no longer display for any new transactions created after thiscorrection is installed. Removal of previously posted $ signs will require an SQLupdate. Resolved in Release 6.1.SFKFEE1 (#88805)Incorrect assessments (refunds) were calculated when a course had a section fee(SSADETL), the refund rules were defined on SFAESTS, and Track by CRN waschecked on SOATERM. Incorrect results also occurred when there was a 100%refund period defined in SFAESTS under these conditions. These issues have beencorrected. Resolved in Release 6.1.SFKFEE1 (#87305)If a charge rule was established on SSADETL using a detail code other than TUI orFEE, that charge was not being applied to the student's account or the audit historyrecord for the student. This has been corrected. This problem resolution alsocorrects #87337. Resolved in Release 6.1.SFKFEE1 (#88708)When a refund was calculated from an SFAESTS refund period, the assessmentprocess was not inserting a total non-dropped hours record in SFRFAUD (placeholder 0.00 amount record viewed in SFAFAUD). This can lead to a mis-Student Release 7.0 January 2005356 Release Guide Confidential

Section 13 Problem ResolutionsRegistration Moduleinterpretation of the audit liability data. The Audit History Table (SFRFAUD) willnow display the .00 placeholder record when the SFAESTS refund takes place.Resolved in Release 6.1.SFKFEE1 (#88676)Non-TUI and/or non-FEE category detail code charges were being reversed whenrefunding was being performed from SFAESTS. This has been corrected so that areversal does not occur on detail codes other than TUI and/or FEE, and theSFAESTS refund process will correctly apply the refund to detail codes of TUI orFEE. Resolved in Release 6.1.SFKFEE1 (#88326)When using Track by CRN and section fees, SFRFASC will now assess reversalscorrectly. Resolved in Release 6.1.SFKFEE1 (#87325)When certain rules were in place that calculated a $0.00 charge, $0.00 transactionswere inserted into TBRACCD. This has been corrected. Resolved in Release 6.1.SFKFEE1 (#87360)The SFRFASC report should only list students who have had an adjustment in theirassessment. This worked until the first student with an adjustment was processed bythe report. Then every student was listed on the report, whether they had anadjustment or not. The output file has been corrected to print only those recordsfor which there has been an assessment adjustment. Resolved in Release 6.1.SFKFEE1 (#87678)When using the DD (Drop/Delete) course status on SFAREGS to issue a 100%refund (or any STVRSTS code which has Count in Asmt unchecked), if you accessSFAREGF to query the Mock Fee Assessment windows, return back to SFAREGS andperform an online fee assessment, the corresponding tuition/fees are not reversed.There is no method available to assess that 100% refund from either SFAREGS orby running SFRFASC in Batch.After querying SFAREGF from SFAREGS before the online fee assessment,SFAFAUD displays: "Most Recent Assessment Total = 0.00" although nothing has as yetbeen assessed. The only option is to re-register the student for all the courses andassess fees online (which creates a duplicate set of SFAFAUD records for originalassessment), then use the drop/delete status on the courses once again fromSFAREGS. You then process the online fee assessment, and the correct tuition/feesreversals are calculated.Note: The value 0.00 in the Most Recent Assessment Total field causes anysubsequent adjustment in fee assessment to be handled incorrectly, notjust the drop/delete situation.January 2005 Student Release 7.0Confidential Release Guide 357

Section 13 Problem ResolutionsRegistration ModuleThis situation was resolved by the corrections made for problem resolutions #87360(SFRFASC listing students who did not have an assessment update) and #87325(posting of $0.00 to the TBRACCD record). Resolved in Release 6.1.SFKFEE1 (#87662)If the SFAFMAX data was created after SFRFASC had been initially run and then reassessmenttook place either online or in batch, the process did not recalculatetuition/fees based upon the new SFAFMAX rules. This has been corrected. Resolvedin Release 6.1.SFKFEE1 (#89145)When no refund periods were defined in a refund by total term, refunding usingESTS codes applied a 100% refund. It appeared that the process ignored theSFAESTS refund rules and only considered the SFARFND rules, if they were in effectfor the effective date of the change in enrollment status. If no SFARFND rules werein effect, the process refunded 100% of the fee.ESTS refunds can now be applied when refunding by total is used for the term. Thecode checks to see if the ESTS refunds are in effect, and the ESTS refunds are nowused correctly. Refund by total rules are still applicable, but if the ESTS rules arevalid for the date that the changed enrollment status is applied, the correct ESTSrefund percentage is used. Resolved in Release 6.1.SFKFEE1 andSFKFEES(#88907)Refunding by total did not calculate the correct refund by total penalty amountunder the following circumstances:1. Refunding by total was used, and clearing account detail codes were definedon SFARFND.2. Courses were charged per credit fees on SSADETL using section fees.3. There was a tuition discount defined on SFARGFE, which had been entered asa negative rule for course level and used a different detail code from the oneon SSADETL.The code for refunding by total has been modified to correctly use the "negativerules" as they apply and to assess the correct penalty amount based upon the newliability for all TUI or FEE DCAT detail codes, even if the detail codes used for thenegative rules are different than the detail codes used for the charges from thesection fees.Changes have also been made to SFKFEES so section fees are used correctly whenthe fee types of CRED and BILL are used with refunding by total processing.Resolved in Release 6.1.Student Release 7.0 January 2005358 Release Guide Confidential

Section 13 Problem ResolutionsRegistration ModuleSFKFEE1 andSFKFEESSFKFEE1 andSFKFEESSFKFEE1 andSFKFEESSFKFEE1 andSFKFEESSFKFEE1 andSFKFEESSFKFEE1,SFKFEES, andSFPFAUD(#88291, #88583, and #88663)There is a problem when backing out a fee that was originally charged on SFARGFEusing negative rule. A detail code that previously generated a charge, that nowevaluates to a $0.00 charge, was not adjusting the original charge to zero. Twoadditional problem resolutions were reported (#88583 and #88663), which wererelated to the resolution to #88291. These issues have been corrected. Resolved inRelease 6.1.(#88025)Refunds from SFAESTS were not being calculated correctly. When tuition and feeswere originally assessed by a flat rate and the student was subsequently withdrawn byenrollment status, the refunding was done using course liable billing hours and notapplying the percent refund to the total currency charge for the student. Refundingprocessing using SFAESTS has been corrected. Resolved in Release 6.1.(#87611)If an original assessment was run without creating accounting records, and thestudent was dropped/deleted from their courses, and then a subsequent assessmentwith postings to accounting was run, the reversals appeared on the student's accounteven though the original assessment was not recorded in accounting. This has beenupdated to verify that assessment records exist prior to posting a reversal. Resolvedin Release 6.1.(#89669)If an ESTS (enrollment status) drop assessment had taken place in the previousversion of fee assessment (SFRFASM/SFRFAS1), and then the new version of feeassessment was installed, when SFRFASC was run in update mode and no auditrecords existed, the ESTS refund was reapplied to the remainder that was left fromthe first refund. ESTS refunding has been corrected to look at the assessment dates,correctly update the audit records, and not reapply the ESTS refund. Resolved inRelease 6.1.(#89515 and #87629)When flat charge hours were used, if multiple courses were dropped individuallyand fees were assessed after each drop, an incorrect amount might have beenrefunded. If all of the courses were dropped at the same time, fee assessmentrefunded the correct amount. Refunding using what was formerly referred to as a"plateau" and is now referred to as "from flat hour" processing has been correctedand determines the correct liable hours in the calculations when "from flat hours"exist. Resolved in Release 6.1.(#92435)Student, level, and campus rules on SFARGFE produced incorrect refunds forrefund by course processing when flat charging was in effect. This was reflected onSFAFAUD by incorrect values for the rule student hours and the rule liable hours.The process was assessing refunds at 100%, rather than using the SFARSTS refundrules.January 2005 Student Release 7.0Confidential Release Guide 359

Section 13 Problem ResolutionsRegistration ModuleSince the SFPFAUD process was purging all rows except for the last assessment, theaudit data for previous flat charge qualifications was also being purged in most cases.This caused the assessment processing in SFKFEES to use an incorrect starting pointfor the flat charge processing. SFKFEES also handled overload hours incorrectly,which resulted in erroneous assessments.This situation has been resolved, and SFKFEES, SFKFEE1, and SFPFAUD have beenupdated.The following changes have been made to SFKFEES:• A new function, f_prev_flat_rule_met, has been added which replaces thelogic in p_check_prev_flat_hr_rule_met.• A new procedure, p_get_last_assess_flat_date, has been added.• The rule_type parameter has been removed from functionf_get_prev_nondrop_hrs.• The parameter list for procedure p_get_last_assess_flat_data has beenupdated.The following changes have been made to SFKFEE1:• P_procesfeeassessment has been modified to always update the assessmentdate in SFBETRM.• P_check_prev_flat_hr_rule_met has been renamed asf_prev_flat_rule_met.• A new procedure, p_get_last_assess_flat_data, has been added.• Calls have been added to p_get_last_assess_flat_data inp_studentfees, p_levelfees, p_campusfees, and p_attributefees.• F_get_prev_nondrop_hrs has been updated by the removal of parameterrule_type_in and now reverts back to the selection of the true non-droppedhours.• P_calc_flat_hr_liability has been updated.The following changes have been made to SFPFAUD:• If student has ever qualified for a flat charge rule, audit records from previousflat charge qualifications are now prevented from being purged. These recordsare needed for flat charge refunding.• New functions have been created:• Purge_sfrfaud_student (void)• Purge_sfrfaud_level (void)• Purge_sfrfaud_campus (void)• Purge_sfrfaud_attr (void)• Purge_sfrfaud_sect_fees (void)• Purge_sfrfaud_nd_hrs (void)Student Release 7.0 January 2005360 Release Guide Confidential

Section 13 Problem ResolutionsRegistration Module• Any_flat_qualification (void)• Sel_levl_code_crse (int mode)• Sel_camp_code_crse (int mode)• Sel_attr_code_crse (int mode)• Flat_rule_qualification (char *rule_type, char *rule_value)The following steps should be used to update any incorrect assessment records:1. Identify students with inaccurate assessments due to flat charge refundingissues.2. Record the course drop history for the students (the CRN, the RSTS code, andthe date for each dropped course).3. Purge the SFRFAUD audit data for the students.4. Re-register the students, and assess them.5. Drop the appropriate courses using the RSTS codes and dates noted in Step 2above.6. Run SFRFASC in audit mode, if you want to preview the results prior to postingthe assessment.7. Review and verify the assessment results.8. Run the assessment in update mode, if the assessment was previewed in auditmode.Resolved in Release 6.2.SFKFEES (#97218)Activity dates were not being updated when Fee Assessment was run either online orin batch.• When Fee Assessment updated the SFBETRM_ASSESSMENT_DATE, theSFBETRM_ACTIVITY_DATE was not being updated.• When online assessment was disabled and the charge for the open learningextension was not assessed on the same day that the extension was granted, theSFRAREG_ACTIVITY_DATE was not being updated.These activity dates will now be updated correctly. Resolved in Release 7.0.SFKFEES (#87337)Changes made to fix problem resolution #87305 have also corrected #87337. Detailcodes that had a category other than TUI or FEE were not being assessed when therule existed in the section fees for a CRN in SSADETL. This has been corrected.Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 361

Section 13 Problem ResolutionsRegistration ModuleSFKFEES (#88382)If SFARGFE rules used different detail codes when in a per credit to flat chargingscenario and refunding was using refund by total processing, fee assessmentcalculated an incorrect refund and penalty charge. Refund by total processing hasbeen rewritten to accommodate the use of different detail codes and to assesspenalties correctly whether clearing detail codes are placed in SFARFND or if thedetail codes are left blank. Resolved in Release 6.1.SFKFEES (#87903)When using refunding by total, fee assessment was creating an incorrect penaltycharge if a detail code was removed from a section after the student had registeredand been assessed for that charge and then was re-assessed using SFAREGS (afterthe removal of the section fee detail code from the CRN). This has been correctedso the removal of a detail code for section fees will create a simple reversal (nopenalty charge is posted) after re-assessment occurs in a refund by total term.Resolved in Release 6.1.SFKEDIT1 andSFKFUN1SFKFUN1 andSFKFUNCSFKFUN1 andSFKFUNC(#90995)You cannot register for connected courses such as links and co-requisites if one partof the connection must be waitlisted. The same is also true for concurrent prerequisites.Resolved in Release 6.2.(#85027)A student was allowed to register for both a course and its equivalent within the sameterm. This has been prevented, and a Duplicate Course error will be returned if thisaction is attempted. Resolved in Release 6.1.(#89739)The “DUPL EQUIV” error on SFAREGS will now show the correct CRN in the errormessage. The procedure P_CHECK_DUPL_SFTREGS and the function F_DUPL_EQUIVwere modified. Resolved in Release 6.2.SFKFUN1 (#93409)Registration via the Web no longer permits you to register for a course and aduplicate equivalent course. An error message will now be displayed in thiscircumstance. Resolved in Release 6.2.SFKFUN1 (#85041 and #76841)Duplicate courses that are linked are now recognized as duplicates and do not allowregistration. Resolved in Release 6.1.SFKFUN1 (#87601)In sfkfun1.sql, function f_registration_access, the cursor is used to test forrows locked for update by another user. If locked rows are found, an exception israised as soon as the cursor is opened. Conditions have been added to the exceptionhandler, to see if cursors are open before trying to close them. Resolved in Release6.1.Student Release 7.0 January 2005362 Release Guide Confidential

Section 13 Problem ResolutionsRegistration ModuleSFKFUN1 (#85644)Under certain conditions the procedure SFKFUNC.P_get repeat_data yieldeddifferent results in an Oracle 9i database than in an Oracle 8i database. This hasbeen corrected. Resolved in Release 6.1.SFKMODS,SFKMOD1,SFKFUNC,SFKFUN1,SFKEDIT(#93029)Courses are no longer inappropriately dropped when registration restrictions andoverrides are placed on the student after registration has taken place. Resolved inRelease 6.2.SFKOLR1 (#88782)The Usage Cutoff Duration (To) value on SSARULE was not being calculatedcorrectly and appeared to be off or late by one week when the Duration (Unit Code)field on SSASECT was set to WEEK. The Usage Cutoff Duration (To) value shouldnot have been truncated, and the field was too small. The field should match thedefinition of the SSRRTST_USAGE_CUTOFF_DUR_TO field. The definition ofDURATION_COMPLETE_OUT has been modified to correct this. Resolved in Release6.1.SFKPREQ,SFKPRE1,SFKFUN1(#93487)When the connected, linked sections of a course were given the course status of WL(Waitlisted), a link error was received on all sections. Now, waitlisted courses willsatisfy group edits for other waitlisted course restrictions. Resolved in Release 6.2.SFKWAI1 (#82332)Cross-listed sections that had a student waitlisted were allowing a new student toregister, even when there was someone on the waitlist, instead of displaying awarning message. A warning message will now be displayed notifying the user thatthe class is open and is cross-listed but that a waitlist exists. Resolved in Release 6.1.SFTSTCR1 (#86205)Component and sub-component records were being deleted when the registrationstatus was replaced with one defined in STVRSTS with the W/D Ind(icator) set to Y(checked). Therefore, if the student was re-registered in the course, newcomponent/sub-component records were not being created. The corrective actiontaken was to leave these records intact unless the registration record was physicallyremoved. Resolved in Release 6.1.FunctionSFFCRHR (#92372)The Return_field had a type of sfrstcr.sfrstcr_gpa_hours. It should havehad a type of shrlgpa.shrlgpa_gpa_hours, since it holds the sums of theSFRSTCR fields. This has been corrected. Resolved in Release 6.2.January 2005 Student Release 7.0Confidential Release Guide 363

Section 13 Problem ResolutionsRegistration ModuleBanner ViewSFVSECM (#87719)The TC (Time Conflict) field on SFQSECM will now be activated for open learningsections. Resolved in Release 6.1.Scriptsfrtfan.sql (#90998)The dollar sign ($) was removed from the report produced by SFRTFAN sinceinternational clients do not require it. Resolved in Release 7.0.ReportsSFRENRL (#79214)A student's time status may not have been reportedly correctly, because manual timetime status overrides on SFAREGS were not being considered. To address this issue,the enrollment verification process now first checks to determine if a manualoverride time status history record exists for the appropriate term on SFAREGS. Ifit does exist, the manual override time status will be reported. If no manual timestatus exists, then the existing time status calculation within SFRENRL will be usedto calculate and report the student's time status, based on the value entered for theTime Status Calc Credit Type parameter (either E for Earned Hours or A forAttempted Hours as recorded in Academic History). Resolved in Release 6.2.SFRENRL (#88257)The GPA will now print within the right margin, and the term description in theTerm Information will no longer be incorrectly split up and wrapped to anotherline. Resolved in Release 6.2.SFRENRL (#91259)The report will now run to completion when printing multiple comment lines for astudent where a page break is needed, and the comments are continued on a newpage. Resolved in Release 6.2.SFPFAUD (#89080)SFPFAUD only removed records when an individual ID was entered in the IDparameter. The pidm field was not populated for the delete unless an ID had beensupplied when the process was run. SFPFAUD will now remove records even whenan ID has not been entered in the ID parameter. Resolved in Release 6.1.SFRFASC (#92940)The Control Page of the report will now reflect the correct version number.Resolved in Release 6.2.Student Release 7.0 January 2005364 Release Guide Confidential

Section 13 Problem ResolutionsRegistration ModuleSFRFASC (#89283)The deadlocking error situation which occurred if the report was run at the sametime that fees were being assessed using online fee assessment on SFAREGS hasbeen corrected. Resolved in Release 6.1.SFRFASC (#87516)When SFAFASC was run in batch mode with the collector table, the SFRBTCHcollector table entries were not being deleted if there was no change in a student'sassessment. This has been updated to delete collector records as they are processed.Resolved in Release 6.1.SFRFASC (#88736)Two issues were reported with the printed output from the report:1. When the Accounting Detail to Print parameter was set to A (All), the processprinted payments and other charges that were not related to the fee assessmentprocess. The report should have printed only Source = R transactions (andSource of 1-9 for SFARFND penalty charges).2. There was no Grand Total at the end of the report. This amount can beimportant to proving the associated cashier session (TGACREV) and thesubsequent feed to finance (TGRFEED).The following changes have been made:• This report has been revised and updated to print only source codes of R and1-9.• A Total has been added to the report.• The CRN for a course is now printed when charges are derived from sectionfees.• Placeholder commas have been added for clarity.Resolved in Release 6.1.Please see the Registration chapter of the Student User Guide for an updated reportsample.SFRFASC (#87896)The future effective date defined on SOATERM was not being used when SFRFASCwas run in batch mode. If the value in the Assessment Date parameter was NULL,SFRFASC was using the system date and should have been using the effective dateon SOATERM, if it date was greater than the system date. This has been corrected.Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 365

Section 13 Problem ResolutionsRegistration ModuleSFRFASC (#90518)When SFRFASC was run in batch for a group of students, the SFRFAUD recordscould not be viewed from SFAFAUD or from within the database, since the recordswere not being saved as each student was processed. The records are now saved aseach student is processed. Resolved in Release 6.1.SFRNSLC (#67828)When a student had graduated from more than one degree with the same level, thestudent was not being represented correctly, as a graduate, in the clearinghouse file.This has been corrected. An EB4 code is now generated on the ENR record.Resolved in Release 6.1.SFRRGAM (#91920)A compiler warning was received on some systems due to the existence of anunreachable line of code. This has been corrected. Resolved in Release 6.2.SFRRGAM (#94590)SFRRGAM was updating the SFRSTCA table, which should not have happened.Three triggers (sfttreg0.sql, sfttreg1.sql, and sfttreg2.sql) have beenmodified to recognize when they are being fired from the SFRRGAM process and tono longer update the SFRSTCA table. Resolved in Release 6.2.SFRSCHD(#94276 - General)This object was modified as part of Banner General problem resolution #94276 forGJIREVO. Column headings will now be underlined correctly on the report output.Resolved in Release 6.2.SFRSCHD (#90203)Two changes have been made to the report. First, a blank page will no longer printafter the student’s schedule. Second, a new parameter has been added to the report.The Print Control Report parameter is required. Enter Y to print a control reportpage or N to not print a control report page. The default is N. The scriptgibpdefschd21.sql is delivered to updated this report. Resolved in Release 6.2.SFRSCHD (#89245)SFRSCHD was not producing any student schedules when a population selectionwas used. In addition, the record count may have been incorrect in certainsituations. These issues have been corrected. Resolved in Release 6.1.SFRSCHD (#85559)The Printer parameter used with the sleep/wake process was set at 10 characters andshould accept 30 characters. This has been corrected. Resolved in Release 6.1.SFRSCHD (#89008)A closing comment has been added to correct warning messages that were receivedwhen users tried to compile SFRSCHD. Resolved in Release 6.1.Student Release 7.0 January 2005366 Release Guide Confidential

Section 13 Problem ResolutionsAcademic History ModuleSFRSCHD (#88996)SFRSCHD will now run in sleep/wake mode. Resolved in Release 6.1.SFRSLST (#90915)The SFVSTMS view has been modified to correct the slow response time whichoccurred when SFRSLST was run. Resolved in Release 6.2.SFRSLST (#91815)SFRSLST will now show wait-listed students or other students who have registrationstatuses that are not gradable. Resolved in Release 6.2.SFRSLST (#88035)In the Oracle 9i environment, students were not being sorted in alphabetical orderwhen the Class Roster Report (SFRSLST) was run. This was due to a sortingproblem with Oracle when an ORDER BY clause was not included in the code. Theappropriate changes have been made to facilitate proper sorting. Resolved inRelease 6.1.SFRSSCR (#90601)Students with prior degrees that were currently enrolled were incorrectly given agraduated enrollment status rather than their current enrollment status, such asfull-time enrolled. This has been corrected. Resolved in Release 6.1.Academic History ModuleFormsSHADEGR (#82738)When a degree status was set to AW, you could still edit items associated with anawarded degree that were formerly protected against update, such as level, campus,college, honors, applied courses, and graduation status information. You could alsodelete the degree record. You must now change the degree status to PN or SO beforeyou can edit or delete the degree record. Resolved in Release 7.0.SHADEGR (#86055)You can now update the Fee Date in the Graduation Information when the FeeCharge (Indicator) is NULL. Resolved in Release 7.0.SHADEGR (#83402)When you enter a graduation detail code that has a term code default defined onTSADETC, the term code will now default in with the amount and effective date.Resolved in Release 7.0.January 2005 Student Release 7.0Confidential Release Guide 367

Section 13 Problem ResolutionsAcademic History ModuleSHADEGR (#84736)When free form comments were entered in the Comments Block, the entire line washighlighted and erased when the user typed a character in the last position of theline/field. This has been corrected. Resolved in Release 6.1.SHAEDIS (#73204)A Verify ID option has been added to the Options Menu for use with matching IDs.Resolved in Release 7.0.SHAGCOM (#79393)When you tab through the fields in the Component Definition block, the Must Pass(Indicator) is now highlighted when the cursor is in that field. Resolved in Release7.0.SHAINST (#74935)The Options Menu item for Course Maintenance that accessed SHATCKS but hadbubble help for SHATCKP, has been corrected to access the new SHATCKN form,which replaces and is a combination of SHATCKC, SHATCKS, and SHATCP in 7.0.Resolved in Release 7.0.SHAINST (#77885)GPAs are now calculated on SHATCKC, SHATCKP, and SHATCKS (which arereplaced by SHATCKN in 7.0) when you exit the forms to capture any changes thathave been made. The trigger GPA_CHANGES is now used to determine if GPAs shouldbe recalculated. Resolved in Release 6.2.SHAPCMP (#93119)Insert errors occurred when the last row of SHAPCMP was deleted, and navigationin SHATERM was not possible. This has been corrected. Resolved in Release 6.2.SHAPCMP (#92855)SHRTGPA records that were entered in error could not be deleted. The OracleError “Unable to INSERT record occurs when deletion is done” was displayed. Also,SHATERM displayed an “INVALID CODE” error when the user accessed the form toview the results. This has been corrected. Resolved in Release 6.2.SHAPCMP (#88677)When you enter a value of 0 for Quality Points and a value of 0 for the GPA Hours,you will no longer receive an error. Resolved in Release 6.1.SHARPTR (#92887)Both blocks of this form interact with database tables. As such, neither blockfunctions as a Key Block, so the Rollback function does not work properly. When auser would perform a Rollback, any subsequent attempts to update and saveinformation would generate an error message. Consequently, the Rollback functionhas been inactivated. Resolved in Release 7.0.Student Release 7.0 January 2005368 Release Guide Confidential

Section 13 Problem ResolutionsAcademic History ModuleSHARPTR (#92817)The title bar on the form now reflects the correct form name, the Repeat/MultipleCourse Rules Form (SHARPTR). Resolved in Release 7.0.SHARQTC (#90605)When a request with a fee was saved for non-existent course level, the student wascharged for a transcript fee, even though no transcript was produced. The form willnow check for an SHRLGPA record or an SFRSTCR record for that level and term.When no course data exists for a level entered in the form, the form will return themessage " ERROR** Course data for student does not exist at this level, press list for validlevels". The transcript request cannot occur, and therefore, no charge can be postedto the student’s account. Resolved in Release 6.2.SHARQTC (#92829)You can now enter and save a sent date that is equal to the request date withoutreceiving an error message. Resolved in Release 6.2.SHARQTC (#93258)If you leave the (Transcript) Type field NULL, you will now receive the autohintmessage "Field must be entered." Resolved in Release 6.2.SHARQTC (#92882)Institutional users can now update records on SHARQTC without receiving an errormessage, even if a Web user had previously requested a transcript with a Web userID. Resolved in Release 6.2.SHARQTC (#93031)You could create and save a transcript request using AL when multiple levels existedand the GPA needed to be recalculated. The system will now correctly notify the userif there is a GPA that needs to be recalculated at any level when multiple levels exist.Resolved in Release 6.2.SHARQTC (#87379)The size of the SHTTRAN_NATN_DESC field has been changed from 28 to 30characters to prevent an error in the (Issued to) Nation (Code) field that occurredwhen the nation description was a full 30 characters. Resolved in Release 6.1.SHARQTC (#85909)The student address type could be updated after the transcript had been produced.You now cannot change the address type when the print date is not NULL. Resolvedin Release 6.1.SHARQTC (#86956)When a transcript request was duplicated from a transcript request that had atranscript sent date, the sent date was copied and updated into the new request. Thisshould not happen. The transcript sent date from an existing request will no longerbe copied into a new request. Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 369

Section 13 Problem ResolutionsAcademic History ModuleSHARQTC (#87435)You will now receive an error message when leaving the Level field if you enter aninvalid code. Previously, you were not prompted with an error message for an invalidcode until you tried to save your changes.The following issues were also corrected on the form:• You can now perform searches from the SHTTRAN block and the STVLEVLfield.• The buttons in the SHTTRAN block are only enabled when appropriate.Previously they were always enabled.• The fields and vertical scrollbar have been moved to the left to accommodateviewing the scrollbar on the Internet Native version of the form.• Colons have been added to field tags that did not have them.• The abbreviated Stat field tag has been updated to be the Status field.• The abbreviated Intl Access field tag has been updated to be the InternationalAccess field.• Auto hint text has been added to the Transcript Sent Date field.• The (Transcript) Type is now a required field.Resolved in Release 6.1.SHARQTS (#92741)You will no longer receive the global variable errors: “FRM-40815 VariableGLOBAL.REQUST_DATE does not exist”, or “FRM-40815 VariableGLOBAL.SENT_DATE does not exist” when entering the form. Resolved in Release 6.2.SHARQTS (#93339)Records in the form were previously sorted by PIDM. Records are now sorted by lastname. Resolved in Release 6.2.SHARQTS (#77117)Fields which did not display their complete values in Internet Native Banner havebeen adjusted for size, layout, and scrolling ability to correct this. Resolved inRelease 6.1.SHARQTS (#85903)You could not update the Sent Date value to a date that was less than the Print Datevalue. You will now receive an error message when the Sent Date value is a date thatis prior to the Print Date value, or when the Sent Date value is NULL and the PrintDate value is NULL.The following issues were also corrected on the form:Student Release 7.0 January 2005370 Release Guide Confidential

Section 13 Problem ResolutionsAcademic History Module• Buttons are now enabled and disabled correctly when you navigate from andto the Key Block.• When you use Rollback or re-enter the form, the Key Block variables are nowsaved and populated.• When you use Rollback, the ID and name in the Key Block are remembered.Resolved in Release 6.1.SHATAEQ (#89014)SHRTGRD allows a grade code to be defined up to six characters in length, andpreviously, if the transfer grade was more than three positions, SHATAEQ wouldgive the following error when rolling the transfer work to history: “FRM-40735:ROLL_TRTK trigger raised unhandled exception ORA-6502”. This has been corrected.Resolved in Release 6.1.SHATAEQ (#84868)It is no longer possible to save an institutional equivalent with a NULL subject code,course number, and/or credit hours. Previously, this was possible if one used O(override) in the articulation switch and accidentally nulled out the value in one ofthe required fields. Resolved in Release 6.1.SHATAEQ andSHKTAE1(#85303 and #84518)Two issues have been resolved:1. Previously, the articulation process did not always assign the correct number ofcredits to the equivalent courses. This issue resulted from the correction forproblem resolution #78302, which did not account for transfer courses thathad a range of possible credit values defined in the transfer catalog.As such, the articulation process has been modified so that the following logicwill be used when assigning credit hour values to equivalent courses:• If the Credits Used field in Equivalent Course block of SHATATR is notnull, assign that value to the equivalent course.• If the Calendar Type and Multiplier field for the institution defined in isnot null, calculate the equivalent course credits by multiplying thetransfer course's credits (as entered in SHATAEQ) by the value in theCalendar Type and Multiplier field.• If the value in the Calendar Type and Multiplier field on SOABGTA forthe institution is null, assign the value entered for the transfer course (asentered in SHATAEQ) to the equivalent course.2. If a user mistakenly entered an alpha character in the Attendance Period fieldand performed a Save, an error was received: "ERROR- "FRM-50016: Legalcharacters are 0-9- E". Also, the message looped so that the only method availableto stop the message was the termination of the Banner session.January 2005 Student Release 7.0Confidential Release Guide 371

Section 13 Problem ResolutionsAcademic History ModuleIn this situation, the user will now receive a more appropriate error message(i.e., “Must be in range 0 - 99”) and will be able to make the message go awaywithout ending their Banner session.Resolved in Release 6.1.SHATAEQ (#85388)Previously, the form would always use the apply to level value from the TransferringInstitution's Attendance Period 1 record for each institutional equivalent course'slevel code, even if multiple attendance periods were defined using different applyto level values. This has been corrected. Resolved in Release 6.1.SHATAEQ (#85299)Previously, when duplicate transfer courses were entered across attendance periods(as opposed to within the same attendance period), you were likely to receive a“ROLL_TRTK trigger raised unhandled exception” error message. This was most likelyto occur when one-to-one or one-to-many articulations were present and when oneor all of "many" equivalent courses had attributes. This has been corrected.Resolved in Release 6.1.SHATAEQ (#84477)The situation where erroneous term GPA records were created by changing thetransfer term and/or level code after a transfer course had been articulated hasbeen corrected. Previously, you could change the term code and level code on atransfer course, even after performing articulation, using the Search button andthen selecting a code from the List of Values. The issued has been resolved bydisabling the Search buttons after articulation has been performed. Resolved inRelease 6.1.SHATAEQ (#88379, #87978, and #87370)You will no longer receive the error message: “FRM-40735: EQUATE_TRIG triggerraised unhandled exception ORA-06502” when trying to articulate transfer courses.Resolved in Release 6.1.SHATCKN,shkcgpa.sqlPlease read:SHATCKC,SHATCKP,SHATCKS(#97976)When changing a level, if you typed over the code instead of unchecking thePrimary Level Indicator and then using Remove Record, the SHRTGPA andSHRLGPA records were not being updated. This has been corrected. Resolved inRelease 6.3.Note:Please be aware that SHATCKC, SHATCKP, and SHATCKS have been combined and replacedin Release 7.0 with one new form, SHATCKN. The problem resolutions from 6.2 listed belowthat refer to the obsolete forms (SHATCKC, SHATCKP, and SHATCKS), also apply to the newSHATCKN form, as those changes have been absorbed into the new form.Student Release 7.0 January 2005372 Release Guide Confidential

Section 13 Problem ResolutionsAcademic History ModuleSHATCKC (#89959)When selecting a code from the List of Values for the Schd field in the Course Detailblock, the entire schedule type code is now returned, instead of just one character.Resolved in Release 6.2.SHATCKC (#79650)Part-of-term start and end dates were being replaced with section dates when thecourse record was created and saved. Also, dates were not being defaulted in whenpartial dates were entered. The date fields will now work correctly. Resolved inRelease 6.2.SHATCKC (#70317)You can no longer proceed to the Grades block using the mouse if the subject andcourse are not valid at the Catalog level. Resolved in Release 6.2.SHATCKP (#59605)You can now enter an institutional CRN, and it will not be overwritten with a systemgeneratedvalue. Resolved in Release 6.2.SHATCKS (#77755)You can now enter a grade comment without receiving an error, whether you areentering a new grade or changing a grade, manually or using the List of Values.Resolved in Release 6.2.SHATCKC,SHATCKP,SHATCKSSHATCKC,SHATCKP,SHATCKSSHATCKC,SHATCKP,SHATCKS(#90237)When a new course was added and saved, the GPA recalculation message had to beacknowledged two times. The processing of the updates in all course maintenanceforms has changed with this release. You will no longer receive pop-up messageswhen a GPA is recalculated. The message appears in the auto-hint text and will notappear multiple times. Resolved in Release 6.2.(#79753)Deleting a graded, rolled course with a calculated GPA correctly causes updates tothe GPA data. GPA recalculation now takes place when you save your changes, notwhen you exit from the form. This allows GPAs to be updated accurately based uponvarious data changes that affect GPA calculation within these forms. Updatemessages in these forms have also been changed. You will now see the "GPA is beingrecalculated" message in the autohint text, after you perform the Save, along withconfirmation that the transaction is complete and the records have been applied.Resolved in Release 6.2.(#85300)Previously, duplicate primary records could be saved using the Record/InsertRecord/Duplicate function. Once saved, you could not delete one of the duplicates.These forms now allow you to edit the setting of the Primary Level Ind(icator) andwill not save more than one level with a Primary Level Ind(icator) that is checked.Resolved in Release 6.2.January 2005 Student Release 7.0Confidential Release Guide 373

Section 13 Problem ResolutionsAcademic History ModuleSHATCKC,SHATCKP,SHATCKSSHATCKC,SHATCKP,SHATCKSSHATCKC,SHATCKP(#77885)Many institutions do not recalculate GPAs inside Banner forms due to legacy systemdata that will be changed by the Banner GPA calculation. SHATCKS, SHATCKP, andSHATCKC have been updated to perform the GPA recalculation only when datathat affects GPA is changed. Therefore, changing instructor information or attributecodes will no longer execute the term GPA recalculation process. Resolved inRelease 6.2.(#85729)The activity date on SHRTCKL will now be updated when existing course levelinformation is changed. Resolved in Release 6.2.(#45713)It is now possible to change the primary instructor or add instructors after the initialinformation has been saved, without exiting from the form. Also, you can save titlechanges, including new titles, and then continue editing, without exiting from theform. Resolved in Release 6.2.SHATERM (#93559)The record counter will no longer add a blank record as the last record of the query.The correct number of records will now be displayed as you progress through theterms. Resolved in Release 6.2.SHATERM (#92292)The truncated value for a course level will now display accurately as you movethrough the records. It will no longer alternate between the rounded and truncatedvalues. Resolved in Release 6.2.SHATERM (#55168)The auto hint text for the Level field in the Key Block has been edited to read,"Course Level Codes By Person, Press LIST for Valid Codes". Resolved in Release 6.2.SHATERM (#68327)The tag on the Progress Evaluation Standing field to has been changed to ProgressEvaluation. Resolved in Release 6.1.SHATERM (#81086 and #83463)You can now use the Term GPA and Crse Detail item in the Options Menu from theKey Block to access the Term GPA and Course Detail Information window. Resolvedin Release 6.1.Student Release 7.0 January 2005374 Release Guide Confidential

Section 13 Problem ResolutionsAcademic History ModuleSHATRNS (#84832)Three issues have been resolved:1. Previously, after performing the List and Select functions from the Subject andCourse fields in the Equivalent Course Detail block, you received the message:"ERROR-Invalid Code; press LIST for valid codes”, and the cursor would be in theGrade field. This no longer occurs.2. Previously, updating the Effective Term and/or Apply to Level fields in theTransfer Attendance Period block created an additional SHRTGPA record forevery change in term and/or level. These extra term GPA records wereviewable via SHATERM in the Term GPA block. Now, the proper way to changethe Effective Term and/or Apply to Level fields is to perform a RemoveRecord function for the SHRTRAM record which, in turn, deletes thecorresponding SHRTGPA record.3. Previously, when entering data directly in the Equivalent Course Detail block,you could not tab or use the Enter key to move to the Course field afterentering a value in the Subject field. You would receive multiple errormessages. This no longer occurs.Resolved in Release 6.1.SHATRNS (#87215)Previously if you performed the List and Select functions from any field that allowedit, auto hint would display "form trigger list values copy [DATABASE_COLUMN_NAME]".Also, in the Equivalent Course Detail Block, performing a Select function from theList of Existing Courses from either the Subject field or Course field would onlyinsert the subject code. The Course and associated Hours fields were not updated.These issues have been corrected. Resolved in Release 6.1.SHATRNS (#87520)Previously, there were a few implicit insert statements into the SHRTGPA,SHRLGPA, and SHRTRCD tables which were causing problems for Virtual PrivateDatabase functions. These insert statements have been corrected. Resolved inRelease 6.1.FunctionSHFPGPA (#92372)Previously, when queries were performed that accessed prior term GPA data forreports, the following errors were returned:“ora-06502 PL/sql numeric or value error: character string buffer too small”“ora-06512 BANINST1.F_concat_prev_term_gpa line 27”This has been corrected. Resolved in Release 6.2.January 2005 Student Release 7.0Confidential Release Guide 375

Section 13 Problem ResolutionsAcademic History ModulePackagesSHKCGPA (#93139)When SHATRNS was used to enter transfer credits with a term code of 000000, theGPA calculation did not reflect the assigned grade. It recorded all zeroes. SHKCGPAhas been modified to correctly display calculated GPAs and assigned grades.Resolved in Release 6.2.SHKCGPA (#91717)GPA calculation did not occur correctly in SHRRPTS or SHRCGPA when transfercourses were marked as repeat conditions. The recalculation of GPAs has beenupdated to correctly include and exclude values when transfer courses areconsidered in repeat processing. Resolved in Release 6.2.SHKCGPA (#57642)Courses that apply to two levels will no longer be counted twice when the GPA iscalculated using SHQDEGR. Resolved in Release 6.1.SHKCGPA (#38455)The problem with inconsistent GPAs displaying on transcripts produced by SCTBanner Student and Self Service Student has been resolved by the consolidation ofall GPA calculations into one package (SHKCGPA). (This fix was included inRelease 6.0, but was not included in the Release Guide.) Resolved in Release 6.1.SHKCGPA (#89761)Previously, in WebCAPP when a program or area GPA was a whole number. (i.e.,4.0), it was displaying as .00. This has been corrected. Resolved in Release 6.1.SHKPRE1 (#86435)The Progress Evaluation Process (SHRPREV) was not taking grade changes intoaccount when determining the percentage of courses the student had completed.This caused students to be given erroneous progress evaluation status codes for theterm. If a grade is changed that changes a student's progress evaluation, thechanges are now considered when SHRPREV is run. Resolved in Release 6.1.SHKPRE1 (#91898)The Progress Evaluation Process (SHRPREV) did not consider transfer hours incumulative hours for existing progress evaluation rules. SHRPREV has beenadjusted so that transfer hours are included when the cumulative hours areconsidered for progress evaluation rule qualification as defined in the academicstanding rules. Resolved in Release 6.2.SHKPRE1 (#91723)The Progress Evaluation Process (SHRPREV) did not use cumulative hours up toand including the term for which the process was run. The existence of future termhours caused incorrect PREV rules to be assigned based upon the student’scumulative hours beyond the term entered in job submission.Student Release 7.0 January 2005376 Release Guide Confidential

Section 13 Problem ResolutionsAcademic History ModuleThis has been corrected so that when future term hours exist, SHRPREV nowdetermines what the student's hours are up to and including the term for which theprocess is run and not just the overall cumulative hours for that student. Resolvedin Release 6.2.SHKROLS,SHKROL1(#82235)These functions have been updated to prevent SHRROLL from aborting due to thelength of the grade_sub variable, which needed to be modified as the grade codeshad been expanded. Resolved in Release 6.2.SHKRPT1 (#87140)If an equivalent course was entered in a pre-Banner term, it was not beingrecognized by registration error checking as a repeat. The same course, when takenin a Catalog/Schedule term, generated the correct error message. This has beencorrected to recognize a pre-Banner equivalent course. Resolved in Release 6.1.SHKRPT1 (#57680)Unrolled, graded courses and equivalent courses will now be handled correctly inrepeat processing. Resolved in Release 6.1.SHKRPT1 (#88701)The SHRGRDE_REPEAT_INCLUDE_IND flag will now be used when the report is run.The shkrpt1.sql function was also modified to select the proper rule whenchecking for the in-progress course. Resolved in Release 6.1.ReportsSHPTRTC (#67953)EDI records will now be deleted when the Mode parameter is set to U. Resolved inRelease 6.1.SHPTRTC (#79886)When you run the process in update mode, the Report Control page will now display“NUMBER OF TRANSCRIPT REQUESTS DELETED” instead of “NUMBER OFTRANSFER REQUESTS DELETED”. Resolved in Release 6.1.SHRASTD (#94096)The report will now update the Dean’s List standings when the rule on SHAACSThas a type of C (institutional and transfer combined). Resolved in Release 6.2.SHRASTD (#88894)SHRASTD was not updating the academic standings, it was printing different termcodes on different pages of the report, and it was printing the wrong term code inthe control report. The process has been corrected to update the academicstandings accurately and to print the correct term codes on the output. Resolved inRelease 6.1.January 2005 Student Release 7.0Confidential Release Guide 377

Section 13 Problem ResolutionsAcademic History ModuleSHRASTD (#87522)When a student has no GPA hours, the academic standing for the end of term nowproperly reverts to the previous calculation, not the override. Resolved in Release6.1.SHRASTD (#88884)The correct term codes will now be printed on the report output and on the controlpage, and the academic standings will be updated correctly. Resolved in Release 6.1.SHREDIP (#87902)SHREDIP stops running with an error: “! *ERROR* Unprocessable line” whentranscripts contained multiple degree records. A new structure of list proceduresfor linked lists of record types has been added to correct this. Resolved in Release6.1.SHREDIY (#93030)The GPA was not printing properly in the flat file. The digits after the decimal pointwere not printing when they were zeroes. SHKCGPA has been modified to use twodigits, not six digits. The GPA will now be formatted properly when printed in theflat file. Resolved in Release 6.2.SHREDIY (#94155)Issues with the sediflt.dat file and the sedictl.dat file have been corrected.The control characters that were present in the sedictl.dat file have beenremoved, and the extra data reported on the ends of lines in the sediflt.dat fileno longer appear in the development database when the process is run. Resolved inRelease 6.2.SHREDIY (#94815)Inconsistent results that occurred in the SHREDIY output (sediflt.dat file) whena student had in-progress courses have been corrected. In cases where some coursesfor a term were graded and others remained in-progress, the courses had not beenprinting. Resolved in Release 6.2.SHREDIYA new GPA Format parameter has been added to the report for use with expandedGPA and credit hours values. This parameter is optional. Enter R to print roundedGPAs on the report or T to print truncated GPAs on the report. The default valueis R.Other changes have also been made to the report for use with expanded GPA andcredit hours values.• A new call to shkcgpa.p_trunc_or_round has been added for use every timethe GPA is selected, with a total of seven occurrences.• Changes have also been made to variable sizes and select format masks.• The trans_credits variable has been increased to a length of 9 and themask to a length of 990.99.Student Release 7.0 January 2005378 Release Guide Confidential

Section 13 Problem ResolutionsAcademic History Module• The fields: attempted_hours, degree_attempt_tot,degree_gpa_hrs_tot, degree_passed_total, earn_hours,gpa_hours, total_attempt_hours, total_earn_hours,total_gpa_hours, trans_attempt_hours, trans_earn_hours, andtrans_gpa_hours have been increased to a length of 13 and the mask toa length of 99999990.999.• The fields: degree_gpa_tot_T04, gpa, total_gpa, and trans_gpa havebeen increased to a length of 14 and the mask to a length of990.999999999.• The fields: degree_points_tot, qpoints, total_q_points, andtrans_q_points have been increased to a length of 16 and the formatmask to a length of 99999990.999999.• The credits format mask has been changed to a length of 9990.099.• The quality_points format has been changed to a length of 099.999.• The total_inprogress_credits format has been changed to a lengthof 99999990.999.• The length of the record variable has been increased from 81 to 94characters.Please see the Academic History chapter of the Student User Guide for an updatedreport sample.SHREDIY (#82009)If a student had in-progress courses but had no academic history, EDI was notprinting data in the sediflt.dat file regarding the student's in-progress courses.This has been corrected. Resolved in Release 6.1.SHREDIY (#80919)Two issues have been resolved:• SHREDIY did not write the name of the transfer institution into the SC recordunless there was an attendance period begin date. That date is not required inSHATRNS, so the process should check for a description instead of the date.Corrections were made so that the transfer institution prints in thesediflt.dat file when no attendance start and end dates are recorded inSHATRNS.• SHREDIY was not populating the quality points field on the C1 record fortransfer courses. This field was populated correctly for institutional courses.Because of this, CRS12 was null for all transfer work on our EDI transcripts.The quality points are now displaying correctly for transfer work in thesediflt.dat files.Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 379

Section 13 Problem ResolutionsAcademic History ModuleSHREDIY (#88016)In certain cases, SHREDIY was placing an erroneous value in the sedilog.dat file,causing EDI.Smart not to process the SEDILOG file, thus not finishing the PrepareOutbound EDI. This has been corrected. Resolved in Release 6.1.SHRETRP (#78739)The Sending Inst Code to Purge parameter % option was not working with thevalidation for this process. When you entered % in the parameter, you received apop-up error stating that the parameter value failed the STVSBGI_EQUAL validation.This has been corrected, the error is no longer returned, and using the % value willallow the job to be submitted and run successfully. Resolved in Release 6.1.SHRGRDE (#93741)An error was displayed when the report was run for midterm grades for a studentwho did not have any transfer work or grades in history. Grade mailers can now berun for all students using expanded hours, even when students do not have anytransfer work or grades in history. Resolved in Release 6.2.SHRGRDE (#90242)Mid-term grade mailers will no longer print courses that have a registration status ofwaitlist. Resolved in Release 6.2.SHRGRDE (#88903, #87248, and #90242)The GPA/Quality Points/Credit Hours were not being rounded or truncatedcorrectly on the output when the pre-6.0 formats for truncation, GPA display, andquality points display were selected for processing on SHAGPAR and the PrintExpanded Quality Pts/GPA parameter was set to N. This has been corrected.Resolved in Release 6.1.SHRGRDE (#62586)Transfer GPA values greater than 9.99 were not printing correctly even when thePrint Expanded Quality Pts/GPA parameter was set to Y. This has been corrected.Resolved in Release 6.1.SHRIACT,SHRICIP,SHRIPDS(#86539)Non-resident aliens were not being identified correctly as a result of the changesmade to capture visa information. This could result in inaccurate information beingtransmitted to the NCES. The SHRIACT, SHRIPDS, and SHRICIP processes havebeen modified to capture non-resident status from the information entered inGOAINTL rather than SPAINTL. Resolved in Release 6.1.SHRICIP (#89344)Modifications have been made to the Web upload file to satisfy NCES requirements.The SURVSECT field has been changed from COM to C01 to reflect that 1990 CIPcodes were used. If your institution is using 2000 CIP Codes, this value will need tobe changed manually from C01 to C02. Resolved in Release 6.1.Student Release 7.0 January 2005380 Release Guide Confidential

Section 13 Problem ResolutionsAcademic History ModuleSHRIGRS (#61547)SHRIGRS was reporting some students as not enrolled who actually had graduatedwith four-year degrees. This was caused by a missing where degree status =awarded clause in the subquery select min(a.shrdgmr_grad_date) of theget_graduate function.If a second SHRDGMR record existed for a person for a bachelor's degree whichhad never been awarded, and that record had an earlier graduation date (populatedby the Grade Roll Process from the expected graduation date in SGBSTDN), the"real" degree-awarded record was not selected, because it did not have the earliestgraduation date. The subquery should have selected the earliest graduation datewhere the degree was awarded.This has been corrected. Resolved in Release 6.2.SHRROLL (#82235)When the process was run with the Print Selection parameter set to E (Error), thereport did list the student and the grade that were in error, but the report omittedthe CRN information. You could not tell which CRN was in error. This has beencorrected. Resolved in Release 6.2.sSHRRPTS andSHKRPT1(#57324)Several issues related to use of transfer courses by repeat processing have beencorrected.• SHRRPTS had a problem with a repeat situation involving a transfer course ifand only if a repeat situation also existed with an institutional course. This hasbeen corrected. If a transfer course is the only course in student's history thatwill present a repeat situation, the institutional course and the transfer coursewill print with the appropriate notation that it is a possible transfer case.• If the only course to be selected as a repeat in the student's academic historywas a transfer course, repeat processing did not select that student forevaluation. This has been corrected.• In addition, the Repeat (Indicator) was not always updated in SHATRNS whenthe report was run in update mode.• Issues related to the calculation of GPAs (SHKCPGA) for repeated transfercourses were also addressed.Resolved in Release 6.2.SHRRPTS andSHKRPT1(#90244)The student was not listed on the report if there was only one course whichexceeded or equaled the minimum evaluation grade on SHARPTR for all repeatedcourses. While this problem resolution only referred to minimum grades, the samesituation occurred when there were different levels, titles, and schedule type errors.This has been corrected. Resolved in Release 6.2.January 2005 Student Release 7.0Confidential Release Guide 381

Section 13 Problem ResolutionsAcademic History ModuleSHRRPTS andSHRCGPA(#91717)When transfer work had been marked with an I(nclude), A(verage) or E(xclude) onSHATRNS, the transfer GPA records were not being recalculated. Now, whenlooping through the collector records (with or without a population), the processwill now recalculate the transfer GPA record for any institution and/or attendanceperiods where the term in the collector matches the attendance period inSHRTRAM. Resolved in Release 6.2.SHRRPTS (#85298)Courses with manually included grades were not being processed by the report,which resulted in too many courses being included. The correct courses were notalways excluded, based on the rules on SHARPTR, when repeat processing was run.Manually included grades will now be counted first, so they are counted correctly.Resolved in Release 6.2.SHRRPTS (#92759)The report will now sort courses by CRN within the term for an ID. Previously, thesort order used was by term within the CRN. Resolved in Release 6.2.SHRRPTS (#91317)The SHRRPEQ_SEQ_NO field has been redefined as NUMBER(3) to consider studentswith over 100 courses and prevent an error when running the report. Previously, themaximum number of courses considered was 99. Resolved in Release 6.2.SHRRPTS (#92482)The page breaks in the report will now occur after the last record for each level whenmultiple course levels are selected. Resolved in Release 6.2.SHRRPTS (#89307)The report was printing the sequence number in the Section column instead of theactual section number. This has been corrected. Resolved in Release 6.2.SHRRPTS (#91317)The SHRRPEQ_SEQ_NO column has been redefined as NUMBER(3), instead ofNUMBER(2). When SHRRPTS inserts the 100th row for a student who has 100 ormore courses in academic history, the process will no longer display an error.Resolved in Release 6.2.SHRRPTS (#88701)The SHRGRDE_REPEAT_INCLUDE_IND flag will now be used when the report is run.The shkrpt1.sql function was also modified to select the proper rule whenchecking for the in-progress course. Resolved in Release 6.1.SHRRPTS (#88625)Repeat processing will now look at the evaluation grade on the SHARPTR rules forusing repeat hours. Resolved in Release 6.1.Student Release 7.0 January 2005382 Release Guide Confidential

Section 13 Problem ResolutionsAcademic History ModuleSHRRPTS (#89825)Repeat processing was incorrectly flagging a repeatable course (which had beenrepeated) as part of the evaluation of a non-repeatable course (which had not beenrepeated). Repeat processing incorrectly flagged both courses when only oneshould have been evaluated. When there was only one course to be evaluated,processing should have returned and deleted that row. In the previous code, therow remained and was evaluated with the next course. This scenario has beencorrected. Resolved in Release 6.1.SHRTAEQ (#92757)The alignment of transfer and institutional credit total values has been improved.The credit hour total values now line up better with their column headings.Resolved in Release 7.0.SHRTAEQ (#95740)The process has been modified to handle long values in the Transfer CourseSubject, Course, and Title fields more effectively. Any values in the aforementionedfields exceeding the space allotted for the column will be truncated on the primaryrow for that record. However, any value that is truncated on the primary row will beprinted in full on the next row. Similar functionality has been added to theInstitutional Equivalent side of the report for course titles that exceed the spaceavailable on the primary row for the record. Resolved in Release 7.0.SHRTAEQ (#86595)Previously, the process would list only one level of transfer course work in theTransfer Summary section even though multiple levels existed. This has beencorrected. Resolved in Release 6.1.SHRTAEQ (#61601)The process output was not correctly formatting transfer course details when eitherthe subject and/or the course number was longer than six characters. Given thatthere is a finite amount of space available on each detail line, the report wasoriginally designed to display only the first six characters of the subject code and/orcourse number fields even though each field allows up to 60 characters. Whentransfer courses are entered with long values in either of these fields, only the firstsix characters will display on the main detail line, but the full value will display onnext the line below. Also, if a transfer course with a long subject code or coursenumber was the last one in the list, the full value did not display. This has beencorrected. Resolved in Release 6.1.SHRTAEQ (#59382)In the Institution Equivalent column of the report, long course titles were beingprinted on two lines, with the first line being fully justified. This was adding a lot ofspace between the words on the first line. Now, long course titles will wrap withinthe column and be right justified. Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 383

Section 13 Problem ResolutionsAcademic History ModuleSHRTECA (#78900)The process that generates the report will no longer print multiple equivalentcourses when there is only one set up. Previously, when the primary course of amany-to-one equivalency was also defined as a standalone course that had a differentequivalency than when it was part of a group, the report would list both equivalentcourses under each occurrence of the transfer course. Resolved in Release 6.1.SHRTPOP (#79448)Four issues were found when running SHRTPOP:1. When the advisor is entered, it is ignored by the process.2. The process is selecting more students than it should.3. The process selects students that do not have a degree record that matches thedegree code entered in the parameter.4. The selected count is off by one in some cases.These issues have all been corrected. Resolved in Release 6.1.SHRTPOP (#70245)SHRTRTC did not produce transcripts for PIDMs that had been placed into theSHTTRTC temporary table when the SHTTRTC_TERM column had a NULL value.SHRTPOP is the process used to populate the SHTTRTC_TERM column. This hasbeen corrected so that entering % in the Selection Term parameter in SHRTPOPand then running SHRTRTC will accurately print the transcript for the populationselected. Resolved in Release 6.1.SHRTPOP (#60276)SHRTRTC produced data for only one level when multiple levels existed, and datawas extracted for processing using SHRTPOP. Using SHRTPOP to create thetranscript selection will now produce all levels when running SHRTRTC and havingthe Transcript Population File parameter set to Y. Resolved in Release 6.1.SHRTRTC (#94479)Transcripts will now print correctly, with the issued date printed on the first line ofeach page and without extra line spacing after the issued date. Resolved in Release6.2.SHRTRTC (#94484)The degree GPA will now be rounded correctly according to the rules set up onSHAGPAR. The GPA rule is used to round or truncate the GPA, instead of thequality points rule. Resolved in Release 6.2.Student Release 7.0 January 2005384 Release Guide Confidential

Section 13 Problem ResolutionsAcademic History ModuleSHRTRTC (#94253)When an include or exclude repeat indicator was assigned to a transfer course, theI or E was not being printed on the transcript as is done with institutional courses.Therefore, transfer GPA data may not agree with the course listing. This has beencorrected. Resolved in Release 6.2.SHRTRTC (#90761)Unless you had institution totals, transfer totals, and overall totals turned on in thetranscript type rules for two column transcripts, the “END OF TRANSCRIPT”message would be printed at the bottom of column one, even if additionalinformation was printed in column two. This has been corrected as a result of fixesmade for problem resolutions #90639, #91924, and #92284. Resolved in Release 6.2.SHRTRTC (#90639)Transcripts were printing correctly, except when an alignment page was printed. Inthis case, the first person's transcript after the alignment did not advance to the nextpage. This has been corrected. Resolved in Release 6.2.SHRTRTC (#91924)When the option to print transfer totals was not checked on SHATPRT, and transfercoursework existed for the ID for which the transcript was being run, the followingerror was displayed:“SHRTRTC:Receive error cannot produce transcript: v 6.1: Connected. RUNSEQUENCE NUMBER: ERM-EXTRATE: Unmatched call to table(T_END)”This has been corrected. Resolved in Release 6.2.SHRTRTC (#92284)CEU course start and end dates were not printing when requested from the rules onSHATPRT, and the SHRTCKN part-of-term start and end dates were populated afterthe grade roll. The dates will now print correctly after grades are rolled. Resolved inRelease 6.2.SHRTRTC (#90217)When there were two terms in progress, the term dates were not correct. Forexample, Fall and Spring in-progress courses were all displayed with the Spring termdates. This has been corrected. Resolved in Release 6.2.SHRTRTC (#88330)The grade points (Pts column), when printed on the transcript, did not adhere tothe SHAGPAR rules, when these rules differed from the default values. Whilecorrecting this issue, an additional error was found in the line counting for thetranscript where the line limit was being exceeded. The grade point display is nowcorrect, and the line count for transcripts is 55. Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 385

Section 13 Problem ResolutionsAcademic History ModuleSHRTRTC (#78056)SHRTRTC will now compile when the Run in Sleep/Wake Mode parameter is set toN. Resolved in Release 6.1.SHRTRTC (#62612)The transcript output was incorrect under certain conditions when the A (All) levelwas used.• A student had completed UG level courses.• The student was admitted to a new level (GR) and registered for GR levelcourses.• The GR registration was changed to a registration status that did not count inenrollment.A graduate-level transcript was produced with the output showing all zeros. Thetranscript process has been updated to prevent for this from occurring. Resolved inRelease 6.1.SHRTRTC (#64848)When SHRTRTC was run from job submission using an ID that was less than ninecharacters, and a request number was also entered, the SHRTRTC.lis file was empty.SHRTRTC was expecting a nine-character ID to be entered. This has beencorrected. If you enter an ID that is less than nine characters, followed by a threedigit sequence number, the process will find the ID and print the transcript data asexpected. Resolved in Release 6.1.SHRTRTC (#59886)A student with a registration status code that had the Grd (Gradable Indicator)unchecked in STVRSTS would receive a transcript with that course listed as "INPROGRESS". When a course is ungradable as controlled by the registration statuscode and when a section is recorded as ungradable, neither should not be reportedas "IN PROGRESS." This has been corrected. Resolved in Release 6.1.SHRTRTC (#87122)SHRTRTC was printing the header of Page 2 on the bottom of Page 1. Also, thesecond copy of the transcript was not starting on a new page but directly beneaththe "END OF TRANSCRIPT" line. The page break errors have been corrected.Resolved in Release 6.1.SHRTRTC (#88953)Changes have been made to prevent the header for Page 2 from printing on aseparate page, prevent the printing of a blank page at the end of the transcript, andprevent the “CONTINUED ON PAGE 2” message from wrapping improperly.Resolved in Release 6.1.Student Release 7.0 January 2005386 Release Guide Confidential

Section 13 Problem ResolutionsAcademic History ModuleSHTRTRC (#77610)The issue of the degree GPA displaying differently on transcripts than the way it doesin several Banner forms (e.g., SHAINST, SHATERM, SHADEGR, and SHARQTC)has been resolved by work done during the Expanded Credit Hours & GPA projectdelivered in Release 6.0. Resolved in Release 6.1.SHRTRTC (#88657)When the Transfer Totals field was unchecked on the Transcript Type Rules Form(SHATPRT), that information was still displayed on the transcript. SHRTRTC hasbeen corrected so that when Transfer Totals field is not checked, the transfer totalswill no longer be printed on the transcript. Resolved in Release 6.1.SHRTRTC (#88478)Individual transfer courses may have had details truncated or displayed as ###.#when large numbers were used, even if the expanded credit hours print option wasselected. This display error has been corrected. Resolved in Release 6.1.SHRTRTC (#88036)After upgrading to Release 6.0, and accepting the default values on SHAGPAR, thefollowing error was received in the .log file: "WRN-LONGTOK: Token "QPts:" exceedscontaining column width (4). This has been corrected. Resolved in Release 6.1.SHRTRTC (#89356)Entering an ID alone in the ID and (Sequence) as XXXXXXXXX00 parameter didnot generate all eligible pending transcripts for the ID. The ID and sequencenumber were required in order for a transcript to be generated. Now, entering theID number without a sequence number following it will produce all previouslyunprocessed transcript requests for that ID. Resolved in Release 6.1.SHRTRTC (#89037 and (#90064)GPAs will no longer be rounded when the Print Expanded Hours Formatsparameter is set to N. Resolved in Release 6.1.SHRTRTC (#90365)When the Print Expanded Hours Formats parameter is set to N, the transfersummary information will now print on one line instead of two. Also, the Dean’s Listinformation will only be printed once, and will not replace the academic standinginformation. Resolved in Release 6.1.SHRTRTC (#90184)A course display line will no longer be printed for every course in the .log file whenthe Print Expanded Hours Formats parameter is set to N. Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 387

Section 13 Problem ResolutionsCAPP ModuleCAPP ModuleDocumentationHandbook (#99111)The Use Catalog field definition that appears multiple times in CAPP has beenupdated to read: “Checkbox used to indicate whether the system should use any ofthe courses within the range defined in the Course Low and Course High fields thatare included in your course catalog. If this checkbox is cleared, compliance will useany course the student has completed (history, transfer, in-progress, and planned)to attempt to meet this requirement.” Resolved in Release 7.0.Handbook (#97284)An erroneous reference to SMACRLT in Chapter 6 has been changed to SMACPRT.Resolved in Release 7.0.Handbook (#97520)The following text has been removed from Chapter 6:“Make sure that a print code exists on the Compliance Print Code ValidationForm (STVPRNT). This code is used to populate the DISPTEXT internal codein the WEBCAPP group on GTVSDAX. This code is in turn used for the printcode in CAPP for its display, including program, area, group, and rule text. Ifno code is designated, no text will print.”The DISPTEXT rule on GTVSDAX is no longer used with STVPRNT. TheSMAWCRL form now handles that processing. Resolved in Release 7.0.Handbook (#94137)Previously, the Student CAPP Handbook contained an inaccuracy related to StudentAttributes processing. On page 6-1 the handbook stated: "All of a student'sattributes, regardless of their effective term, are considered by compliance." Thehandbook has been edited to clarify that only those student attributes in effect as ofthe evaluation term on a compliance request will be considered during processing.Resolved in Release 6.2.FormsSMAAREA (#92893)The Copy function accessed via the Maintenance button in the Course/AttributeAttachment window now works properly. Resolved in Release 6.2.Student Release 7.0 January 2005388 Release Guide Confidential

Section 13 Problem ResolutionsCAPP ModuleSMAAREA (#77171)When performing maintenance in the Area Restricted Subjects/Attributes blocks(i.e., copying entries from one term code to another), the form will no longer copydata from the Course Low field into the Course High field. The entries will now becopied to the correct field. Resolved in Release 6.1.SMAAREA (#78473)When defining requirements in the Course/Attribute Attachments block, you arenow able to type valid term code values in the Must Be Taken Between Start and Endfields without having to select them from the list of values (STVTERM). Resolved inRelease 6.1.SMAAREA (#79714)The spelling of the word "Maintenance" has been corrected in the Course /Attribute Attachment block. Resolved in Release 6.1.SMAAREA (#80091)Performing an Insert Record function between existing rows of text in the Area Textblock no longer results in receiving the message: “*ERROR* Cannot create record unlessfrom term equal key block term.” Resolved in Release 6.1.SMAAREA (#81316)While building an area requirement that includes a range of courses, but excludesstudents with a certain student attribute code, you will no longer receive thefollowing error message: “ORA-01400: cannot insert NULL into("SATURN"."SMRAEXL"."SMRAEXL_AREA")” when you attempt to save theexclusion. Resolved in Release 6.1.SMAAREA (#82116)The Attached (Indicator) in the General Requirements block can no longermistakenly be set to null by a user when maintenance is performed on an area. TheAttached (Indicator) is no longer navigable, so a user cannot null it out by mistake.Resolved in Release 6.1.SMAAREA (#83135)The form no longer prevents you from performing a Next Field from the Test(Code) field in the Course/Attribute Attachment block. You can now tab througheach field on a detail line. Resolved in Release 6.1.SMAAREA (#64943)The form no longer allows you to save two rules with the same name. Previously, ifyou had created two rules with the same name, when you clicked on the Searchbutton to access the umbrella and details for the second rule, it took you to therecord for the first rule. Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 389

Section 13 Problem ResolutionsCAPP ModuleSMAAREA andSMAGROP(#61474)The Duplicate Record function has been modified to work the same in the Course/Attribute Attachment Block as in the Rule Detail Block. Resolved in Release 6.1.SMAGROP (#64943)The form no longer allows you to save two rules with the same name. Previously, ifyou had created two rules with the same name, when you clicked on the Searchbutton to access the umbrella and details for the second rule, it took you to therecord for the first rule. Resolved in Release 6.2.SMARQCM (#81206)The form did not have horizontal scroll bar in the Planned Courses window, eventhough there was information in the "box", which indicated there was more datathat could be displayed. The extra data could be viewed and/or updated using theTab key. However, the navigation did not follow the normal Banner convention,which used the horizontal scroll bar. This has been corrected. Resolved in Release7.0.SMARQCM (#66709)Previously, after processing a compliance request, you were able to change and saveany data relating to the request, even though the message received upon accessingit indicated that you could not change the data. This situation has been resolved.Also, after a request has been processed, the Submit for Processing option is nowdisabled. Resolved in Release 6.2.SMARQCM (#72796)Previously, when you entered a program code in the Compliance Curriculumwindow by selecting it from a list of valid program codes and then you entered amajor code in the same manner, sometimes the entries were saved, and sometimesthe system returned you to the main request window of the form. You then wererequired to re-enter all the curriculum information. This situation has beencorrected. Resolved in Release 6.2.SMARQCM (#81206)Previously, the form did not have a horizontal scroll bar in the Planned Courseswindow, even though there was information in the scrollable canvas indicating thatadditional information could be viewed. A horizontal scroll bar has now been addedto the Planned Courses window. Resolved in Release 6.2.SMARQCM (#88378)Previously, when SMARQCM was called with an ID/Name carried from anotherform, the default cursor location was in the Holds field rather than in the ID field.This has been corrected. Resolved in Release 6.2.SMARQCM (#89535)Previously, if you used the Next Block function while working in the Copy Requestwindow, you received inappropriate error messages. Therefore, that function hasbeen disabled in the Copy Request window. Resolved in Release 6.2.Student Release 7.0 January 2005390 Release Guide Confidential

Section 13 Problem ResolutionsCAPP ModuleSMASARA (#80729)The debug message “call set default” no longer appears in the autohint for the ID andName fields. Resolved in Release 7.0.SMIAOUT (#94517)The Edit button that allows you to navigate to a rule-with-rule in the Detail Area RuleRequirement window is now enabled. Resolved in Release 7.0.ReportsSMRBCMP (#93908)Previously, when run in batch using a population selection, compliance may haveaborted as a result of a unique constraint error in the Split Courses Temporary Table(SMTSPLT). This issue has been resolved. Resolved in Release 7.0.SMRBCMP (#72548)Previously, when you requested that graduation date and admit term be printed ona compliance report, these items were not displayed when the request was processedin batch using a population selection and pointing the curriculum source to theGeneral Student record. This issue has been resolved.However, this issue was also reported to happen when a new request was copied fromone that had already been processed. It is explained in the documentation that thisbehavior is expected, and therefore, in this situation the issue was not addressed asa defect.Resolved in Release 6.2.SMRBCMP (#80499)Previously, when the Batch Compliance Process was run with a population selectionand the Curriculum Source parameter was set to use the General Student record,the hardcopy output indicated: “Curr Srce : Degree #0”. This issue has been resolved.Resolved in Release 6.2.SMRBCMP (#81576)Previously, when batch compliance was run and the Send to Advisors parameter wasset to Y, the message “***WARNING - No Address ***” would print below the advisor'sname, even though the documentation indicates that no advisor address would beprinted. This situation has been resolved. Resolved in Release 6.2.SMRBCMP (#80498)Previously, when the Batch Compliance Process was run in Population Selectionmode, if the Send to Advisors parameter was left null, no output was produced. Now,if this parameter is left null, the process will use the default value of N.Also, in order to make the process more user friendly, the following changes havebeen made to the parameter definitions for the process:January 2005 Student Release 7.0Confidential Release Guide 391

Section 13 Problem ResolutionsCAPP Module• Parameter 8, Degree Status - The help text now reads: “Degree Status.Required if parameter 7 is D(egree).”• Parameter 9, Hardcopy for Population? - The Optional/Required setting hasbeen changed to “Required”.• Parameter 12, Send to Advisors - The Optional/Required setting has beenchanged to “Required”.• Parameter 13, Primary Advisor Only? - The help text now reads: “Produceoutput for primary advisor only. Y/N are valid. Req'd if parm 12 is N.”• Parameter 15, Address Hierarchy - The help text now reads: “Priority andaddress type (ex: 1MA). Do not enter if output is for advisor(s).”• Parameter 17, Sort Order - The Optional/Required setting has been changedto “Required”.Resolved in Release 6.2.SMRCMPL (#95461)As a result of the Expanded Credit Hours and GPA Fields enhancementimplemented in Banner 6.0, in-progress courses were not being used by compliancewhen minimum grade codes with a numeric value greater than 99 were defined.This has been corrected. Resolved in Release 7.0.SMRCMPL (#81952)Previously, credits split by a requirement defined by only a course attribute mighthave been incorrectly reused, even though Reuse Indicator fields for all areas wereset to None/None. This has been corrected. Resolved in Release 7.0.SMRCMPL (#89114)Previously, due to an error in the second pass logic, available courses were not alwaysapplied to detail requirements when they were defined using set/subsets andsubject, course number, and course attributes together. This has been corrected.Resolved in Release 7.0.SMRCMPL (#89608)Previously, a course might have been applied to a requirement even though itscredits exceeded the credit per course high value defined for the requirement. Thishas been corrected. Resolved in Release 7.0.SMRCMPL (#73701)Previously, if a requirement indicated that a specific course and an attribute must beavailable to be satisfied, an equivalent course might have been applied torequirement, even though the course attribute did not exist on that equivalentcourse. Course detail line and rules processing have been modified to enforce theattribute requirement, even when an equivalent course is being applied to therequirement. Resolved in Release 7.0.Student Release 7.0 January 2005392 Release Guide Confidential

Section 13 Problem ResolutionsCAPP ModuleSMRCMPL (#67242)Previously, if major, concentration, and/or minor information was included in theAdditional Curriculum window of SMARQCM, those areas were processed to theexclusion of major, concentration, and/or minor information that had beenentered in the Compliance Curriculum window. This has been corrected. Resolvedin Release 6.2.SMRCMPL (#78842)Previously, when a rule was used in a group, if the detail requirement had amaximum number of courses specified, more than that number may have beenused. This occurred when two courses that could have been applied to the samerequirement were duplicates. Also, values of actual credits and courses used in ruleumbrella were incorrect. This has been corrected. Resolved in Release 6.2.SMRCMPL (#73840)Previously, when multiple rules were used in an area, a course that should have beensplit, with its credits applied to two of the rules, was not being used correctly. Creditswere not being applied to the second rule. Also, the rule was marked as met, but itsdetail requirement was not. This occurred regardless of whether sets and subsetswere used on the detail lines in the rules. This has been corrected. Resolved inRelease 6.2.SMRCMPL (#72144)Previously, when a rule umbrella had allowed a total maximum number of credits,and the rule detail lines each allowed a maximum number of credits that was lessthan the value in the umbrella, a course might have been split and have itsremaining credits applied incorrectly to a different detail requirement within therule. This has been corrected. Resolved in Release 6.2.SMRCMPL (#72859)In some cases in which list processing was in effect, a course was not being appliedto a detail requirement when the overall condition was not met. This has beencorrected. Resolved in Release 6.2.SMRCMPL (#88215)Previously, when a requirement was defined in a way that a specific number ofcourses were needed, in some cases, zero credit courses might have been applied tothe requirement, but the requirement would not be met. As such, the conditionwould not be met, and neither would the area. This has been corrected. Resolved inRelease 6.2.SMRCMPL (#78926)Previously, rule processing did not always apply available courses when set/subsetvalues were null. This has been corrected. Resolved in Release 6.2.January 2005 Student Release 7.0Confidential Release Guide 393

Section 13 Problem ResolutionsCAPP ModuleSMRCMPL (#82385)Previously, when a program was processed in Multiple Entity mode, and a course wasflagged as potentially used because it did not satisfy an entire requirement that waspart of an OR condition, it was released to be used in another area. In Single Entitymode, the course was correctly used only in the area in which the Potential Usage(Indicator) had been set. This has been corrected. Resolved in Release 6.2.SMRCMPL (#73545)Previously, when a waiver that had its Count (Indicator) unchecked on STVACTNwas used within a rule, the requirement was not marked as met. If this same waivercode was applied to a non-rule requirement, the requirement was marked as met.Modifications have been made to ensure that such waiver codes will be usedconsistently, regardless of the type of requirement to which they are applied.Resolved in Release 6.2.SMRCMPL (#87884)Previously, when a course attribute alone was used to define the requirement in arule, and there was a maximum number of courses with that attribute allowed, themaximum number of courses was sometimes exceeded with the additional course(s)listed with the Potential Usage (Indicator) checked. The credits from the extracourse(s) were counted toward the area and program totals. This has beencorrected. Resolved in Release 6.2.SMRCMPL (#75009)Previously, when rules-within-rules were used, the main rule umbrella was beingsatisfied, but its maximum credit allowance was being exceeded. This has beencorrected. Resolved in Release 6.2SMRCMPL (#74723)Previously, when a rule had a mixture of attached courses and rules-within-rules, andthe student did not have sufficient courses to complete the overall rule, compliancemight not have used the maximum number of available courses in the rule. This hasbeen corrected. Resolved in Release 6.2SMRCMPL (#89192)Previously, when a course had both lab (one credit) and lecture (three credits)components, and the requirement in a rule was for four credits or two courses, thesame course credits were returned for both the lab and lecture. This situation hasbeen corrected. Resolved in Release 6.2.SMRCMPL,SMKCGPA(#77133)When an area's requirements are defined using set/subset logic within a rule, evenif a requirement is not completely met, compliance will now use applicable coursesfor the requirement. Resolved in Release 6.1.Student Release 7.0 January 2005394 Release Guide Confidential

Section 13 Problem ResolutionsOverallSMRCMPL,SMKCGPASMRCMPL,SMKCGPASMRCMPL,SMKCGPA(#71156)Split credits were not being used correctly when set/subset rule processing wasinvolved. Previously, if the course reuse indicator was set to IN for an area that hadset/subset rule processing, the next area was not using the available split creditsfrom the previous area. The split credits were not displayed in unused courseseither. This has been corrected. Resolved in Release 6.1.(#82232, #87110, and #84938)Placing a restriction on the maximum number of credits from a subject code and acourse number range in the Program Restricted Subject/Attribute window will nowcorrectly limit the credits used from available courses during compliance. Resolvedin Release 6.1.(#82123)Areas with Restricted Subjects/Attributes will no longer prevent the usage of anyand all courses containing the restricted subject and/or attribute code(s). Resolvedin Release 6.1.SMRCRLT (#78689)Previously, in the Courses Not Used section of logical page 3, if a course wasexcluded because it had been repeated, the report printed the credit value from theprevious course for the repeated course. This has been corrected. Resolved inRelease 6.2.SMRCRLT (#90580)The program will now compile cleanly against the 5.6.0.1 version of the compliancecode found in Patch #82123. Resolved in Release 6.1.SMREVAL (#91559)Previously, depending upon the operating system used by your server, you may havereceived compiler warnings after applying Banner Student Patches #82123 and#90580. Modifications were made to numerous debug statements to eliminate thesecompiler warning messages. Resolved in Release 6.2.OverallFormsS% (No defect number)The *CONFIDENTIAL* and *DECEASED* messages that are displayed on Studentforms above the ID field in the Key Block have been modified. They are nowdisplayed in mixed case, without the asterisks, i.e, Confidential and Deceased. Resolvedin Release 7.0.January 2005 Student Release 7.0Confidential Release Guide 395

Section 13 Problem ResolutionsOverallS% (#77382)Some forms were generating compile errors but the .fmx file was still being created.This has been corrected during the 7.0 user interface project. The forms nowcompile without warnings or errors. Resolved in Release 7.0.SOAAPPT (#92688)Users were unable to keep track of appointments accurately, as the appointmentdate changed to the system date whenever a record was updated. Now theappointment date will remain constant when other changes are made to the form.In addition, when a contact record is created from an appointment record, the timestamp associated with the contact will be that of the from time for the appointment.Resolved in Release 7.0.SOAAPPT (#79253)When dates are entered in the Appointment Date Range Start and AppointmentDate Range End fields, you can no longer enter a start date that is later than the enddate. Resolved in Release 7.0.SOAAPPT (#92715 and #92688)When an appointment record is updated, the new appointment date will now bedisplayed when the record is saved. Resolved in Release 6.2.SOAAPPT (#86008)The timestamp for contacts will no longer default to 12:00:00 when entered in thethe Appointments block. Contact records now display a system date with the correcttimestamp. Resolved in Release 6.1.SOAAPPT (#89178)When a record was removed, and a Save was performed, the following error wasdisplayed: "ERROR-From Time, To Time, and Appointment Date must be entered." You hadto then either use Exit or Rollback and answer Yes to the “Save Changes” message forthe record to be deleted. This has been corrected. Resolved in Release 6.1.SOABGTA (#59376)The List of Values that is displayed for the Calendar Type and Multiplier field is nowcorrectly titled Transfer Articulation Calendar Type (STVCALD). Previously, theseven letter form name had incorrectly read “STVCALC”. Resolved in Release 7.0.SOACURR (#86203)When inserting a record, you can now either enter a level code or select one fromthe List of Values without receiving an error. Resolved in Release 7.0.Student Release 7.0 January 2005396 Release Guide Confidential

Section 13 Problem ResolutionsOverallSOAELTR (#88278)The Text Field was designed to accept up to 250 characters (Maximum DataLength). However, when the full 250characters were used, and the Text button wasselected to view the text in the Letter window, the following error was received:"FRM-40735: WHEN-NEW-BLOCK-INSTANCE trigger raised unhandled exception ORA-06502." This has been corrected, and the letter is now displayed in its entirety in theLetter window. Resolved in Release 7.0.SOAELTR (#89659)The system-generated sequence numbers are now being incremented by ten (10)instead of one (1) and can be updated. Resolved in Release 7.0.SOAGPAT(No defect number)The School Name option has been removed from the Options Menu. Resolved inRelease 7.0.SOAHOLD (#67617)The ID in Key Block of SOAHOLD will now be carried to other forms when youselect those forms from the Options Menu. Resolved in Release 7.0.SOAHOLD (#93472)The ID in Key Block of SOAHOLD will now be carried to SPAIDEN when you selectIDs, Names and Addresses from the Options Menu. Resolved in Release 7.0.SOAIDEN (#90795)When SOAIDEN was called from specific forms using Internet Native Banner, thecursor disappeared. You had to click the mouse in order to see the cursor. Thisoccurred when the Search feature was used. If function keys were used to callSOAIDEN, the cursor was visible.Calling SOAIDEN from the following forms caused the cursor to disappear:• SAAQUIK• SAAADMS• SRAQUIK• SRARECR• SGASTDNThis has been corrected. Resolved in Release 7.0.SOAMATL (#73180)When a new record is entered in the Material block, and you use the mouse tonavigate to the Material Rules block, the data in the Material block will no longerdisappear. Resolved in Release 6.1.January 2005 Student Release 7.0Confidential Release Guide 397

Section 13 Problem ResolutionsOverallSOAMATL (#78250)The minimum and maximum test scores are now validated against STVTESC for thetest codes in the test score rule. Resolved in Release 6.1.SOAORUL (#93407)A previous correction for SOAORUL (Problem Resolution #89939) resulted in anORA-6502 error (POST_QUERY trigger raised unhandled exception) if records withthree-digit campus codes had been saved. This error occurred when records withthree-digit campus codes that had been successfully saved in the database wererequeried. SOAORUL records can now be successfully requeried, regardless of thelength of the campus field associated with the record. Resolved in Release 6.2.SOAORUL (#89939)The form did not allow the entry of a three-character campus code either manuallyor from the STVCAMP List of Values. The field sizing for the Camp(us Code) fieldhas been corrected. Resolved in Release 6.1.SOAPCOL (#89801)When the admissions request code is null on a college record, the form will nolonger display the admissions request code description of the default admissionsrequest code from STVSBGI. Resolved in Release 7.0.SOAPCOL (#90417)The Dynamic Help for the Hours and GPA fields in the Degree Information blockhas been updated to reflect the expanded GPA and credit hours formats. Resolvedin Release 6.2.SOAPLAN (#64445)The correct name associated with the ID will now be brought back to SOAPLANwhen the record is selected from SOAIDEN. Resolved in Release 6.1.SOAPLAN (#77920)Depending on the rules set up on SOACOMM, SORCPLN was allowing theassignment of multiple (different) communication plans through theCommunication Plan Change window on SRAQUIK, SRARECR, SAAQUIK,SAAADMS, and SGASTDN. Multiple (different) communication plans were allowedfor the same module, same term, and same sequence number. Once the plans hadbeen assigned, they could be viewed on SOAPLAN. However, if those same two planswere entered manually on SOAPLAN and saved, the following error was received:“ERROR: Only 1 record allowed for same module, term and sequence number.” SinceSORCPLN allowed this to occur, SOAPLAN should function the same way. This hasbeen corrected. Resolved in Release 6.1.SOASBGI (#87968)When an address is updated on SOASBGI, the SOBSBGI_ACTIVITY_DATE will nowbe updated appropriately. Resolved in Release 7.0.Student Release 7.0 January 2005398 Release Guide Confidential

Section 13 Problem ResolutionsOverallSOASBGI (#89880)You can now use Previous Block to navigate through the three blocks on SOASBGI,without the Comments, Directions, and Text block being skipped. Resolved inRelease 7.0.SOASUPL (#95702)The Prior College field will now automatically change an alpha and/oralphanumeric code to upper case, when the STVSBGI code is entered directly intothe field in lower case. This will prevent the error that was occurring: "ERROR-Invalid SBGI code; press LOV for valid values." Resolved in Release 7.0.SOATERM (#84753)The comments on column for two fields on SOBTERM have been updated tocorrect Dynamic Help.• The comment for the SOBTERM_BYCRN_IND field is now “Assess fees by CRNIndicator.”• The comment for the SOBTERM_MIDTERM_WEB_IND field is now “Indicateswhether to allow mid-term grade display via the Web for the term.”Script sobterm1.sql is delivered to perform these updates.Resolved in Release 7.0.SOATERM,sinsssec.sql,sinsfsec.sql(#88327)As part of the Banner Student 6.0 upgrade, a script was included that incorrectlyinserted records into the SSBSSEC table (for students) and the SSBFSEC table (forfaculty) for all existing courses. Since SSBSSEC and SSBFSEC records existed, thesesection level settings overrode the setup on SOATERM. That gave the impressionthat the SOATERM Web display controls no longer functioned properly.To correct this, you can run the following scripts as BANINST1.• Script sinsssec2.sql will delete all existing SSBSSEC rows.• Script sinsfsec2.sql will delete all SSBFSEC rows built where thecorresponding SSBSECT_PTRM_CODE is not null, leaving any rows that havebeen built for open learning sections.Resolved in Release 6.2.SOATERM (#94157)The forms documentation now includes the Catalog Search Controls, the ScheduleSearch Controls, and the navigation needed to access them. The field definitions inthe Web Processing Controls window have been updated, and the fields in the WebDisplay Controls window have been added. This updated version of SOATERM isavailable in the 6.1 Student User Guide on the ActionWeb. Resolved in Release 6.2.January 2005 Student Release 7.0Confidential Release Guide 399

Section 13 Problem ResolutionsOverallSOATEST (#86545)The auto format now works for the (Test) Taken field. The bevel on the stackedcanvas windows has been removed. The period on the Acom field tag has beenremoved. Resolved in Release 6.1.SOATEST (#86098)If an ID was less than nine characters in length, a Next Block could not beperformed from the Key Block unless you first used Tab or Enter to display the fullname. When SOATEST was called from another form, if the ID entered was less thannine characters, and a Next Block was immediately performed from the Key Block,the following error was displayed: "ERROR-A valid ID must be entered for this function.”These issues have been corrected. Resolved in Release 6.1.SOATEST andsrktes1.sql(#84939)Numeric test score ranges on STVTESC were not being enforced on SOATEST. Testscore ranges from 0.0 to 6.0 (for example) allowed the entry of the score 470 withoutdisplaying an error. Test score ranges from 200-800 (for example) allowed the entryof the score 3.5 without displaying an error. This has been corrected. Also, taperecords with test scores that are not within a range found on STVTESC are nowprevented from being loaded to SOATEST. Resolved in Release 6.1.SOATEST andsrktes1.sql(#83578)The Space key is now considered as a “special character”, and the space isrecognized on SOATEST as a valid alphanumeric character for a test score. Resolvedin Release 6.1.SOAXCUR (#83278)It was possible to update the Effective Term From field for the corresponding majorcode. This actually updated the SORCMJR_TERM_CODE_EFF field in the Major-Dependent Concentrations window of SOACURR. A major could mistakenly bedisabled or discontinued due to this situation. The Effective Term From field hasbeen made not updatable. Resolved in Release 6.1.SOQHOLD (#62598)When you are in SFAREGS and a student has a hold that prevents registration, youcan access SOQHOLD using the Search feature next to the Holds (Indicator).SOQHOLD will display the hold that is preventing registration. If you perform aRollback function and type in other IDs on SOQHOLD, you will now see any holdsfor those IDs. When you exit from SOQHOLD, the original ID will still be displayedon SFAREGS. Resolved in Release 7.0.SOQMTCH (#79612)You will no longer receive an error using the Person Search from SAAEAPS whenmore than one record exists for the same state on SOAXREF for the STVSTAT label.Resolved in Release 6.1.Student Release 7.0 January 2005400 Release Guide Confidential

Section 13 Problem ResolutionsOverallSUAMAIL (#79651)It was possible to leave the Key Block without entering a value in the ID field. Theerror message "*Error* a valid ID must be entered for this function" was displayed in apop-up window and in auto help, but the cursor still navigated to the next block. Nodata was returned when queried. You cannot navigate to the main block of the formwithout entering a valid ID in the Key Block. Resolved in Release 6.1.SUAMAIL (#78154)Once an SUAMAIL record had been created with an initials code(GURMAIL_INIT_CODE), the initials code could not be deleted online. Other Bannermail forms (e.g., RUAMAIL, PUAMAIL) allow initials to be removed withoutremoving the entire record. You can now remove initials on SUAMAIL withoutremoving the entire record. Resolved in Release 6.1.SUAMAIL (#61529)When you remove the value in the GURMAIL_DATE_INIT field and save the record,the system date should default into the field. The value in the GURMAIL_DATE_INITfield should not have to be entered manually. This has been corrected. Resolved inRelease 6.1.Forms LibrarySOQOLIB (#88184)You must now enter a fee type when creating fee records. A default value of FLATwill be used if no fee type is entered. Resolved in Release 6.1.FunctionsSOKLIB1 (#87364)If the Permit checkbox in the Registration information on SOATERM is notchecked, no search criteria that has been designated on SOATERM or SOAWDSPwill be displayed. This has been corrected. Resolved in Release 6.1.SOKLIBS (#87363)The error “No Terms Available” will now display appropriately when registration ismarked as not permitted on SOATERM. Resolved in Release 6.1.ReportSORCPLN (#98301)A new report output sample has been added to the User Guide to show the Act andTyp columns that had been added to the report in Banner 4.3. Resolved in Release7.0.January 2005 Student Release 7.0Confidential Release Guide 401

Section 13 Problem ResolutionsMIS ReportsMIS ReportsSER% (#80599)The COBOL processes used with MIS have been modified. The word “EXTERNAL”has been removed from all file assignments and will no longer cause compile errors.The following extracts have been updated:• SERCBREC• SERSAREC• SERSBREC• SERSDREC• SERSEREC• SERSIREC• SERSMREC• SERSPREC• SERSXREC• SERXBREC• SERXCREC• SERXEREC• SERXFRECResolved in Release 6.1.SERSBREC (#88575)The file layout was incorrect for non-transfer students. The transfer earned units,attempted units, and GPA were coming out as 088888 (a zero and five digits of 8)instead of 888888 (six digits of 8). This has been corrected. Resolved in Release 6.1.SERSBREC (#89310)The corrections for problem resolutions #73580 (GPAs are now correctly reportedwhen degree attendance dates are null.) and #72373 (Academic standing is nowcorrectly populated.), which were delivered in Banner ED posting 4.4.2.1, have alsobeen made for Banner 6.1. Resolved in Release 6.1.SERSEREC (#86296)The SGBOEDU_EOPS_CODE is now set when a record is not found in the CARECURSOR.Also, the program no longer reports records when the STCRCURSOR does not find amatching registration status based the value in the Registration Status Codeparameter. Resolved in Release 6.1.Student Release 7.0 January 2005402 Release Guide Confidential

Section 13 Problem ResolutionsFTES ReportsSERSMREC (#87101)The California MIS DED II changes implemented for the Summer of 2002 includedchanging the SM03 Special Services Needs. The 10th position, which was blank, isnow used as an active position for CalWORKS. SERSMREC has been updated toreflect this. Resolved in Release 6.1.SERSPREC andMISSPRECSERSAREC,SERSPREC,MISSAREC,MISSPREC(#88601)The record-number-identifier and the student-program-co-unique-code are now inthe correct order in the extract file. Please note that SERSPREC must have a 000000entry in the STVCIPC table in order for this job to run. Resolved in Release 6.1.(#88600)Proper line feeds have been added to SERSAREC and SERSPREC. Please also notethat SERSPREC must have a 000000 entry in the STVCIPC table in order for this jobto run. Resolved in Release 6.1.SERXEREC (#93159)The program will now compile on LINUX. “EXTERNAL” was removed from theassign clauses. Resolved in Release 6.2.SERXEREC andMISXEREC(#87099)The MIS DED II changes for adding XE04 starting with Fall 2002 have now beenadded to this program. Element XE04 FACULTY-ASSIGNMENT-HOURLY-RATE999V99 047-051 have been added to the extract. Resolved in Release 6.2.SERXFREC (#87667)XF07 (Session-Total-Hours for sections with multiple sessions) is now calculatedcorrectly. Resolved in Release 6.1.FTES ReportsSADA3202,SADA3203,SADA3204(#94178)The hard coded registration status of RE has been removed. A new parameter hasbeen added to the report to set the value of the Type field (STVRSTS_VOICE_TYPE)on STVRSTS.The new Count in Enrollment Indicator parameter is required, and multiple valuescan be entered. Valid values are R (Registered), W (Withdrawal), D (Drop), or L(Waitlisted).The value selected is used to determine which course registration status codes onSTVRSTS are to be counted in enrollment when the registration status date is priorto the section's census one date.January 2005 Student Release 7.0Confidential Release Guide 403

Section 13 Problem ResolutionsValidationYou should select the values your institution wishes to use, to be counted asenrollment for state reporting. Adding these values will not change yourinstitutions’s existing Voice Response setup and/or functionality.Resolved in Release 6.2.SADA% (#80599)The COBOL processes used with FTES have been modified. The word“EXTERNAL” has been removed from all file assignments and will no longer causecompile errors.The following processes have been updated:• SADA3202• SADA3203• SADA3204• SADA3205• SADA3206• SADAFLEX• SADAPRNT• SADASORTResolved in Release 6.1.ValidationDocumentationSTVATYP (97519)The reference to PA being a required value on STVATYP for tape load processinghas been removed. Only MA is used with SRTLOAD as a required value. Resolved inRelease 7.0.FormsSTVCOLL (#89162)You can now access the College Code Validation Form (STVCOLL) using the Searchbutton in job submission without receiving an error when selecting values from theCollege Code parameter in SRRINQR and the Student College parameter inAPPSTDI. Also, APPSTDI no longer ignores the Student College parameter when itis run. Resolved in Release 7.0.Student Release 7.0 January 2005404 Release Guide Confidential

Section 13 Problem ResolutionsReport SampleSTVPREL (#85727)You now receive an “Undefined Function Key” error message if you try to perform aNext Block in the form. Resolved in Release 7.0.STVVOED(No defect number)Comments on the table that read “VACATION EDUCATION” have been changedto correctly read “VOCATIONAL EDUCATION” using the stvvoed1.sql script.Resolved in Release 7.0.STVWLTT (#84839)You will not longer receive the Oracle error: “Unable to INSERT Record." ORA-01400:cannot insert NULL into ("SATURN"."STVWLTT"."STVWLTT_ELMT_CODE")” when anew record is created without a module code. Instead, the correct message "Fieldmust be entered" will be displayed. Resolved in Release 6.1.STVWSSO (#93399)The STVWSSO_USER_ID field has been expanded to VARCHAR2(30) to beconsistent with other forms and to prevent an error on IDs longer than 12characters. Script stvwsso1.sql is delivered to make this change for the column.Resolved in Release 6.2.Report SampleElectronic Application Report (SARETBL)Please see the following landscaped section for report parameters and sampleoutput.January 2005 Student Release 7.0Confidential Release Guide 405

Section 13 Problem ResolutionsReport SampleThis page intentionally left blankStudent Release 7.0 January 2005406 Release Guide Confidential

Section 13 - Problem ResolutionsSample ReportElectronic Application Report (SARETBL)DescriptionThis report is used to view information about a student’s electronic admissions application. The report is a companion to theElectronic Application Submitted Form (SAAETBL). There is no control page for this report.Note: This is an Oracle report. It is run through job submission on GJAPCTL.Parameters Name Required? Description ValuesApplication Source No Enter the source of the admissions application suchas EDI or WEB.EDI Application Source CodeValidation Form (STVAPLS)Note: While this parameter is not required, eitherthe Application Source, Add Date, or Web IDparameter must be entered for the report to produceoutput.Add Date No Enter the date in DD-MON-YYYY format that theapplication was completed.Note: While this parameter is not required, eitherthe Application Source, Add Date, or Web IDparameter must be entered for the report to produceoutput.Student Release 7.0 January 2005407 Release Guide Confidential

Section 13 - Problem ResolutionsSample ReportParameters (cont.) Name Required? Description ValuesWeb ID No Enter the Web ID of the student for which you wishto see electronic application information.Note: While this parameter is not required, eitherthe Application Source, Add Date, or Web IDparameter must be entered for the report to produceoutput.Destination Format Yes Use the list of values to select the format of the reportoutput.The default format is PDF.DELIMITEDDELIMITED DATAHTMLHTMLCSSPOSTSCRIPT (This format is notcurrently supported.)PRINTER DESTINATION (This formatis not currently supported.)RTFXMLStudent Release 7.0 January 2005408 Release Guide Confidential

Section 13 - Problem ResolutionsSample ReportParameters (cont.) Name Required? Description ValuesDestination Type Yes Use the list of values to select CACHE, FILE, MAIL, orPRINTER, to indicate where the report outputshould be directed.You may use CACHE to display the output, and thenyou can print the report.CACHE Display report on screenFILE Save report to a fileMAIL Send report via emailPRINTER Print reportThe default is CACHE.Destination Name No Enter the name of the destination where the outputtype selected above should be directed. Thedestination name can be 30 characters in length.For example:FILE - Enter a valid drive-folder-filename (f:\share\myfile.pdf).Note: Due to the potentially sensitive nature of report output information, you should sendoutput to a file where only the user has read access.MAIL - Enter a valid email address (jdoe@aol.com). Enter multiple addresses with commas asseparators.PRINTER - Enter a valid printer name. If you selected PRINTER in the Destination Typeparameter, and the value is left blank in the Destination Name parameter, the default reportserver printer will be used.Student Release 7.0 January 2005409 Release Guide Confidential

Section 13 - Problem ResolutionsSample ReportParameters (cont.) Name Required? Description ValuesExecution Mode Yes Enter the execution mode for the report asRUNTIME (from the form) or BATCH (from jobsubmission).RUNTIME Run from the formBATCHRun from job submissionThe default is RUNTIME.Communication Mode Yes Enter the communication mode for synchronous(SYNC) or asynchronous (ASYNC).Synchronous specifies that control is returned to thecalling form after the report has completed itsprocessing.Asynchronous specifies that control is returned tothe calling form immediately, even if the report hasnot completed its processing.The default is SYNC.SYNCASYNCWait on Banner form forreport resultsRun report behind thescenesStudent Release 7.0 January 2005410 Release Guide Confidential

Section 13 - Problem ResolutionsSample ReportParameters (cont.) Name Required? Description ValuesParameter Form Yes Enter YES to display the Oracle Report ParametersForm or NO to not display the Oracle ReportParameters Form.The default is NO.NO Do not display Report ParametersFormYES Display Report Parameters FormShow Report ValueWindowYesEnter YES to display the Report Value Window or NOto not display the Report Value Window.NO Do not display Report ValueWindowNote: This parameter has no impact on jobsubmission.YES Display Report Value WindowThe default is NO.Student Release 7.0 January 2005411 Release Guide Confidential

Section 13 - Problem ResolutionsSample ReportReport Sample—Electronic Application Report (SARETBL)Student Release 7.0 January 2005412 Release Guide Confidential

Section 13 - Problem ResolutionsSample ReportStudent Release 7.0 January 2005413 Release Guide Confidential

Section 13 - Problem ResolutionsSample ReportStudent Release 7.0 January 2005414 Release Guide Confidential