may 2006 release 7 - ogeechee technical college business information this documentation is...

What can we help you achieve?

Banner General Release GuideMay 2006

Release 7.3

Confidential Business Information

This documentation is proprietary information of SunGard Higher Education and is not to be copied, reproduced, lent or disposed of, nor used for any purpose other than that for which it is specifically provided without the written permission of SunGard Higher Education.

Prepared By: SunGard Higher Education4 Country View RoadMalvern, Pennsylvania 19355United States of America

© 2006 SunGard. All rights reserved. The unauthorized possession, use, reproduction, distribution, display or disclosure of this material or the information contained herein is prohibited.

In preparing and providing this publication, SunGard Higher Education is not rendering legal, accounting, or other similar professional services. SunGard Higher Education makes no claims that an institution's use of this publication or the software for which it is provided will insure compliance with applicable federal or state laws, rules, or regulations. Each organization should seek legal, accounting and other similar professional services from competent providers of the organization's own choosing.

Without limitation, SunGard, the SunGard logo, Banner, Campus Pipeline, Luminis, PowerCAMPUS, Matrix, and Plus are trademarks or registered trademarks of SunGard Data Systems Inc. or its subsidiaries in the U.S. and other countries. Third-party names and marks referenced herein are trademarks or registered trademarks of their respective owners.

Release Guide

General System

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

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Mandatory Forms Regeneration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Section 1 Common Matching Enhancement - Functional . . . . . . . . 15

New Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Common Matching Source Search Form (GOICMSS) . . . . . . . . . . . . . . . . . . . 15

Changed Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Common Matching Form (GOAMTCH) . . . . . . . . . . . . . . . . . . . . . . . . . 16Common Matching Data Dictionary Form (GORCMDD). . . . . . . . . . . . . . . . . 20Common Matching Rules Form (GORCMRL). . . . . . . . . . . . . . . . . . . . . . . 20Common Matching Source Rules Form (GORCMSC) . . . . . . . . . . . . . . . . . . . 21Common Matching Source Code Validation Form (GTVCMSC) . . . . . . . . . . . . . 23

Section 2 Multi-Institution Functionality (MIF) Enhancement - Functional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Using MIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Home and Process Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25How to View the Institution Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26How to Switch Between Institution Codes . . . . . . . . . . . . . . . . . . . . . . . . 26How Changing Institution Codes Impacts your Banner Session. . . . . . . . . . . . . . 27

Section 3 Common Matching Enhancement - Technical . . . . . . . . 29

Changes to Common Matching Masking . . . . . . . . . . . . . . . . . . . . . . . . . 29

New Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Common Matching Display Hierarchy Table (GORCMDH) . . . . . . . . . . . . . . . 30

3

Table of Contents

Changed Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Common Matching Source Code Validation Table (GTVCMSC) . . . . . . . . . . . . . 31Common Matching Source Priority Table (GORCMSP). . . . . . . . . . . . . . . . . . 31Common Matching Source Rules Table (GORCMSC) . . . . . . . . . . . . . . . . . . 31Common Matching Name Translation Table (GORNAME) . . . . . . . . . . . . . . . . 32Common Matching Non-Person Name Translation Table (GORNPNM) . . . . . . . . . 32Common Matching Match Entry Global Temporary Table (GOTCMME) . . . . . . . . . 33Common Matching Data Dictionary Table (GORCMDD) . . . . . . . . . . . . . . . . 33

New SEED Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Options Maintenance Table (GUROPTM) . . . . . . . . . . . . . . . . . . . . . . . . 33

New View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

GOVCMID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Changed View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

GOVCMRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

New APIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Common Matching Display Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Changed APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Common Matching Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Common Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Common Matching Source Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Common Matching Source Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36GTVCMSC Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Changed Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

gokcmpk.sql gokcmpk1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

gokb_cm_rules1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Section 4 Multi-Institution Functionality (MIF) Enhancement - Technical41

Home and Process Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

New Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

VPDI Included Objects Form (GORVPDI) . . . . . . . . . . . . . . . . . . . . . . . . 42

Changed Form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Banner Global Initialization Form (GUAINIT) . . . . . . . . . . . . . . . . . . . . . . 43

General Release 7.3 May 20064 Release Guide Confidential

Table of Contents

Changed Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

gumappl.mmb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

New Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

MIF Forms Table (GOBVPDI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Changed Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

GTVVPDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Changed Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Dynamic Procedure Library (goqrpls.pll). . . . . . . . . . . . . . . . . . . . . . . . . 45Workflow Library (goqwflw.pll) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46General PL/SQL Oracle*Reports Library (goqorep.pll) . . . . . . . . . . . . . . . . . . 46Form Object Library (goqolib.fmb). . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

New GIF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

vpdi.gif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Changed JAR File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

banicons.jar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

SEED Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

New Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

gokvpda.sqlgokvpda1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

gspvpdi.sqlgspvpdi1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Changed BANSECR Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

gspvpds.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Changed Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

gstvpds0.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Sample Setup Rules for MIF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Sample Rule Setup for a Form Without a Key Block ID . . . . . . . . . . . . . . . . . 52Sample Rule Setup for a Form With a Key Block ID . . . . . . . . . . . . . . . . . . . 53About the All Institutions Dynamic LOV Template . . . . . . . . . . . . . . . . . . . . 54

May 2006 General Release 7.3Confidential Release Guide 5

Table of Contents

Section 5 API Enhancement - Technical . . . . . . . . . . . . . . . . . . . . 57

Changed Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

International Information Form (GOAINTL) . . . . . . . . . . . . . . . . . . . . . . . 57Medical Disability Rule Form (GORMEDR) . . . . . . . . . . . . . . . . . . . . . . . 58Medical Code Validation Form (STVMEDI). . . . . . . . . . . . . . . . . . . . . . . . 58General Medical Information Form (GOAMEDI) . . . . . . . . . . . . . . . . . . . . . 58

New Business Entity APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Medical Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Prior College . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Prior College Concentration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Prior College Degree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Prior College Major . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Prior College Minor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Visa Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Changed Business Entity API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

gb_address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

New Validation Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

STVADMR Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67STVHONR Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67STVPENT Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67STVVTYP Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

New Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Immunization Code Validation Table (GTVIMMU) . . . . . . . . . . . . . . . . . . . . 68Immunization Code Repeating Table (GORIMMU). . . . . . . . . . . . . . . . . . . . 69

Changed Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Document Information Table (GORDOCM) . . . . . . . . . . . . . . . . . . . . . . . 70Visa Code Table (GORVISA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Person Medical Information Repeating Table (SPRMEDI) . . . . . . . . . . . . . . . . . 71Prior College Concentration Table (SORCONC) . . . . . . . . . . . . . . . . . . . . . 72Prior College Degree Table (SORDEGR) . . . . . . . . . . . . . . . . . . . . . . . . . 72Prior College Major Table (SORMAJR) . . . . . . . . . . . . . . . . . . . . . . . . . . 72Prior College Minor Table (SORMINR) . . . . . . . . . . . . . . . . . . . . . . . . . . 72Prior College Table (SORPCOL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

New JAR File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

transporter.jar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

New PLUS Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

gselvisa.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73gupdvisa.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73gdelsdaxvisa.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73


Table of Contents

Changed PLUS Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

gdelintl.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74gupdintl.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Changed Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

gokintl.sqlgokint1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

stksbgi.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Section 6 Large Object Storage Enhancement - Technical . . . . . . . 75

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Considerations for Building Custom Applications . . . . . . . . . . . . . . . . . . . . 75

New API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Large Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

New Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Central Storage for Binary Large Objects Table (GORBLOB) . . . . . . . . . . . . . . . 79Large Object Validation Table (GTVBLOT). . . . . . . . . . . . . . . . . . . . . . . . 81ePrint Table (GORFILX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

New Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

gvkb_gtvblot0.sql (package specification)gvkb_gtvblot1.sql (package body) . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

gokeprt.sql (package specification)gokeprt1.sql (package body) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Changed Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

gokoutp.sql (package specification)gokout1.sql (package body) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

New Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

igtvblot73.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83gos_media_seq.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Large Object Storage Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Technical Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85


Table of Contents

Section 7 Oracle*Reports Changes - Technical . . . . . . . . . . . . . . . 87

Changed Form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

General User Preferences Maintenance Form (GUAUPRF) . . . . . . . . . . . . . . . . 87

Changed Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

User Preference Table (GURUPRF). . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Changed Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

General PL/SQL Oracle*Reports Library (goqorep.pll) . . . . . . . . . . . . . . . . . . 90Report Form Object Library (goqrlib.fmb) . . . . . . . . . . . . . . . . . . . . . . . . 90

New Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

iguruprf73.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Changed RDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Description of Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Section 8 Security Enhancement - Technical . . . . . . . . . . . . . . . . 95

Changed Form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Oracle/Banner Security Maintenance Form (GSASECR) . . . . . . . . . . . . . . . . . 95

Changed Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

gsposec.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96gssacct.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96gssbasg.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96gssclsm.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97gssobjm.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97gssprfm.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97gsspriv.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97gssrolc.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98gssrold.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98gssrolm.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98gsssels.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99gsssysg.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99gsssysp.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99gssusra.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99gssusrc.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100gssusrd.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100gssusrm.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100gssviol.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101


Table of Contents

Section 9 WebUtil Enhancement - Technical . . . . . . . . . . . . . . . . 103

New Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

General WebUtil File Extract Form (GUQWUTL) . . . . . . . . . . . . . . . . . . . . 104

Changed Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

General User Preferences Maintenance Form (GUAUPRF). . . . . . . . . . . . . . . . 104Saved Output Review Form (GJIREVO) . . . . . . . . . . . . . . . . . . . . . . . . . 105GASB Parameter Form (FGAGASB) . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Changed Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Dynamic Procedure Library (goqrpls.pll). . . . . . . . . . . . . . . . . . . . . . . . . 105

New JAR File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

banwebutl.jar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

New Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

gokwutl.sqlgokwut1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Section 10 Internationalization Changes - Technical. . . . . . . . . . . 107

Changed Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Function Affiliation Form (GEAFUNC) . . . . . . . . . . . . . . . . . . . . . . . . . . 107Banner Global Initialization Form (GUAINIT) . . . . . . . . . . . . . . . . . . . . . . 107Oracle/Banner Security Maintenance Form (GSASECR) . . . . . . . . . . . . . . . . . 107

Changed Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Section 11 Miscellaneous Enhancements . . . . . . . . . . . . . . . . . . . 109

Rebranding Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Banner/fsaATLAS Integration Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 110

New Business Process API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110New XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Miscellaneous New Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Business Rule Inquiry Form (GOIRSQL) . . . . . . . . . . . . . . . . . . . . . . . . . 112

Miscellaneous Changed Forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

General Menu Form (GUAGMNU) . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Data Display Mask Columns Form (GORDMCL). . . . . . . . . . . . . . . . . . . . . 113


Table of Contents

Banner Error and Warning Messages Form (GUAERRM) . . . . . . . . . . . . . . . . . 114General User Preferences Maintenance Form (GUAUPRF) . . . . . . . . . . . . . . . . 114Business Rules Form (GORRSQL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Oracle/Banner VPD Security Maintenance Form (GSAVPDI) . . . . . . . . . . . . . . . 115Business Rule Code Validation Form (GTVSQRU) . . . . . . . . . . . . . . . . . . . . 115Banner Global Initialization Form (GUAINIT) . . . . . . . . . . . . . . . . . . . . . . 116Set Institution Code Form (GUQSETI) . . . . . . . . . . . . . . . . . . . . . . . . . . 116Crosswalk Validation Form (GTVSDAX) . . . . . . . . . . . . . . . . . . . . . . . . . 116

Miscellaneous New Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Campus Card Holder XML Table (GURCARD) . . . . . . . . . . . . . . . . . . . . . . 116

Miscellaneous New API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

gokcard.sql gokcard1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Miscellaneous Changed Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

gumappl.mmb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Miscellaneous Changed Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

gokdbms.sqlgokdbm1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

gokpar1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118gokb_address1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118gokb_name_translate1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119gokb_np_name_trans1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119gokb_common1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Miscellaneous Changed Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

gppaddr.pc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Miscellaneous Changed Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Dynamic Procedure Library (goqrpls.pll) . . . . . . . . . . . . . . . . . . . . . . . . . 120Common Forms Object Library (goqclib.fmb) . . . . . . . . . . . . . . . . . . . . . . 122Form Object Library (goqolib.fmb) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Miscellaneous New Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

igurmesg73.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125ugurmesg73.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125stvsbgi1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125ssrxlst1.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125igtvsqpr73.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125ugubobjs73.sql. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125gdrbhlp70300.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Changed DBPROCS Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

gendbpr.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126


Table of Contents

New Master Compile Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Changed Master Compile Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

comform.bat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127comform.shl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127genform.shl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127genform.bat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127genform1.bat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128genform2.bat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128genview.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Changed PLUS Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

glramod.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

New XSD Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

genfsatlas.sql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Changed Readme File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

greadme.doc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Section 12 Problem Resolutions . . . . . . . . . . . . . . . . . . . . . . . . . 131

Letter Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Job Submission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Common Matching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Miscellaneous Forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Miscellaneous Scripts and Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . 146


Table of Contents

This page intentionally left blank


Introduction

Introduction

This guide documents Release 7.3 of the Banner General System. Release 7.3 includes enhancements, RPEs, and problem resolutions.

This document describes the following enhancements.

Common Matching

Numerous changes were made to improve Common Matching functionality and rule setup.

Multi-Institution Functionality (MIF)

Changes were made to allow MIF-enabled institutions to switch between different institution codes.

APIs

New APIs support the collection of biographic and demographic data.

Large Object Storage

Large Objects (LOBs) can now be stored in the database for retrieval by applications such as Banner Accounts Receivable’s eBill and the e~Print product.

Oracle*Reports Changes

New options are available for saving output of the type File on the Oracle Reports server. These options can be used to enhance the security of Oracle Reports at your institution.

Security

The Oracle/Banner Security Maintenance Form (GSASECR) and numerous security-related scripts were changed in order to facilitate ease of use.

WebUtil

Options were added so that users in RAC (and other) environments can save extracted data as a file on their local machine.

Internationalization

Changes were made to several Banner General objects in order to comply with Internationalization (I18N) standards. These changes support future Internationalization functionality.


Introduction

Prerequisites

The following must be installed prior to this release:

• Banner General Release 7.2

• Oracle Version 9.2.0.6

Note: For Open VMS clients who are using the Campus Card and/or Housing Integration APIs, Oracle Version 9.2.0.7 is required. If those APIs are not being used, then Version 9.2.0.5 is recommended. Version 9.2.0.6 is not available for Open VMS.

Mandatory Forms Regeneration

Changes were made to the Form Object Library (goqolib.fmb) that require the regeneration of all Banner forms for all Banner products. The changes include Rebranding, Multi-Institution Functionality (MIF), and INB performance improvements.


Section 1 Common Matching Enhancement - FunctionalNew Forms

Section 1 Common Matching Enhancement - Functional

Numerous improvements were made to Common Matching functionality. A new form enables you to query for matching sources for a particular element; field labels were changed to be simpler and clearer; and more options were added for modifying rules. This section summarizes these improvements.

A new Common Matching Handbook will be introduced in conjunction with the 7.3 user guide updates. It will contain all information related to Common Matching forms, processing, and tasks.

New Forms

Common Matching Source Search Form (GOICMSS)

Use this form to query for all matching sources for a particular element. You can also use it to quickly update the matching rules at your institution.

This form appears on the Common Matching Menu (*GENMATCH).

. . . . . . . . . . . . . . Fields

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Descriptions

Element Element to be used in Common Matching rules. Choices come from the Common Matching Data Dictionary (GORCMDD) list.

Note: Values are case sensitive.

Source Common Matching source code.

Rule Set Rule set priority of the matching source.

Length Length of the element.

Match on Null Data

Indicates whether you want to include matches on NULL data.

Edit Rules Button that calls the Common Matching Rules Form (GORCMRL) where you can edit the rules for the matching source.


Section 1 Common Matching Enhancement - Functional Changed Forms

Changed Forms

Common Matching Form (GOAMTCH)

Middle Name Processing Note

When an ID is updated, it was intentionally set to not create additional alternate ID records. The concern is that if a Middle Name exists in Banner and a new one is entered it would create an additional alternate ID record. If a user then goes to change those records, he/she will eventually experience a primary key violation for names.

Key Block Changes

A View Comments button was added to the Key block. This button can be used to view non-technical details about the matching source and related rule sets from GTVCMSC to better understand the type of data that should be entered in GOAMTCH and the matching results that are produced.

Data Entry Block Changes

The following changes were made to the Data Entry block:

• You can now enter either the SSN or the last name/non-person name for matching. The last name is no longer required.

Note: You should only use the SSN without last name in matching rules sets for online matching. It should not be used in batch processing.

User ID User ID that created or last modified the record.

Activity Date Date on which the record was created or last modified.

. . . . . . . . . . . . . . Fields

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Descriptions


Section 1 Common Matching Enhancement - FunctionalChanged Forms

• You can now restrict whether a new ID is created if any APIs fail due to missing or incomplete information An error message is presented in a pop-up window with additional information about the failure.

When the Create New button is used, the system checks to see if any APIs have failed. If the new Prevent ID Creation on API Failure check box on GORCMSC is checked, the appropriate error message will be displayed, and you will be prompted to enter the missing or incomplete information to complete the creation of the new ID. (The check box value on form GORCMSC is unchecked).

Note: This functionality can only be used online. It is not available in batch processing.

• You now have the option of displaying potential matches using the data entered on GOAMTCH, even if the number of characters entered is less than the length specified in the matching rule on GORCMRL. Use the new Allow Length Override checkbox on GORCMSC to capture any matches up to and including the specified length on for the rule.

For example, if you enter a last name with four characters, and the Length field on GORCMRL has been set to 5 for the rule, the system would display any records where the last name begins with the four characters entered on GOAMTCH.

• When you enter a ZIP + four ZIP or Postal Code and use Tab or Enter to leave the field, the related address information (city, state, county, country) is now automatically populated from GTVZIPC if the corresponding values exist.

• A View Comments button has been added to the Data Entry block. This button can be used to view non-technical details about the matching source and related rule sets from GTVCMSC to better understand the type of data that should be entered in GOAMTCH and the matching results that are produced. This button is also available from the Matches and the Potential Matches blocks.

• The buttons in the Data Entry block have been reordered to prevent the accidental creation of a new ID by inadvertently clicking on the Create New button.

Match Block Changes

The following changes were made to the Match block:

• Several of the fields in this block were reordered and new fields were added. The new fields are: All Telephones, and All E-mails.

• An asterisk (*) in the Matched Address field indicates that the address is inactive. The address code and type code displayed are from the direct match returned by the Common Matching package.



• The Match Priority and Match Results fields were combined to form the new Matching Rule Sets field. This field lists all the rule priorities that were matched by the record. It is a T list type of field, which means that it always contains a value, unlike a pull-down list (which contains a NULL value as the default for non-database items). It has the ability to display multiple records at once, which reduces the need to click through records with your mouse.

• The Clear button was renamed Clear and Return to Data Entry.

Potential Matches Block Changes

The following changes were made to the Potential Matches block:

• The number in parenthesis displayed on the Potential Matches tab now indicates the number of PIDMS that were returned, instead of the number of rows in GOVCMRT.

• Only one row per record is now displayed in the Potential Matches block.

• The fields in the Potential Matches block were reordered, and new fields were added. The new fields are: Matching or Hierarchical Address, All Telephones, and All E-mails.

• The Clear button was renamed Clear and Return to Data Entry.

• The Potential Matches block now displays All Addresses, All Telephones, and All E-mails in pull-down fields by PIDM to assist in determining if a potential match is actually a match. The All Telephones and All E-mails pull-down fields are new fields.

• An asterisk “*” will now be displayed next to the address type code of an inactive address, and also for Matched or Hierarchical Address, Telephone, E-mail, All Telephones, and All E-mails.

• The Match Priority and Match Results fields were combined to form the new Matching Rule Sets field. This field lists all the rule priorities that were matched by the record. It is a T list type of field, which means that it always contains a value, unlike a pull-down list (which contains a NULL value as the default for non-database items). It has the ability to display multiple records at once, which reduces the need to click through records with your mouse.

• If the alias is found as part of the primary match, then the message returned in the Matching Rule Sets is name match; however, if the PIDM is identified during the primary match as an ID or SSN match, and the alias is found during the secondary matching, then the results message is first name alias match.

• Improved messages in the Matching Rule Sets were created for transposed name matches, transposed date matches, and NULL matches.



Changes to Hierarchy Processing

The following changes were made to address hierarchy processing in the Potential Matches block:

You can now define a hierarchy for the display of address, telephone numbers, and e-mail addresses. This hierarchy will be used for two conditions: 1) when no address fields are used in the rule set, and/or 2) when address rules are used in the rule set, but the potential match record does not have an address that matches.

• If address information has been included in a matching source rule set, and the potential match record has an address which matches, that address will be displayed in the Potential Matches block. (This is the existing functionality.)

• If address information has been included in a matching source rule set, and the potential match record has no address which matches, and a hierarchy has been established for the matching source, and the potential match record has an address type listed in the hierarchy, that address will be displayed in the Potential Matches block.

• If address has been included in a matching source rule set, and the potential match record has no address which matches, and a display hierarchy has been established for the matching source, and the potential match record has no address types listed on the hierarchy, the message “No Matching or Hierarchical Address Found” will be displayed in the new Matching or Hierarchical Address field.

• This same logic is true for the telephone and e-mail address information. If there is no match or hierarchical type associated with the record, the message No Matches will be displayed in the Telephone and E-mail fields. (This message is shorter, as these field lengths are smaller.)

• The address source code data is now passed from GOAMTCH to the GOTCMME table. The GOTCMME_ASRC_CODE column has been added to the GOTCMME table. The value in the GOTCMME_ASRC_CODE column is loaded to the SPRADDR_ASRC_CODE column in GOAMTCH using the gb_address API.

The updates to address hierarchy processing also benefit Student data load processing (recruiting test score and source data loads - SAT, ACT, ACT EOS, GMAT, GRE, PSAT, PETERSONS, PCU, AMCAS):

• When records are matched through batch processing, SRTLOAD loads the address source from the temporary tables to the SPRADDR table. SRRSRIN then calls SRKPREL to push the address data, and therefore loads the SRTADDR_ASRC_CODE value to the SPRADDR_ASRC_CODE field.

• Previously, when matching was performed manually using SRIPREL and GOAMTCH, SRIPREL saved the prospect’s address to the GOTCMME table. GOAMTCH then created the address for the new person record from the GOTCMME table, but those addresses were missing the ASCR_CODE data. This data is now included when GOAMTCH is used for manual matching.



Common Matching Data Dictionary Form (GORCMDD)

A new element (SPBPERS_BIRTH_DATE) was added to this form to enable full-date comparison on Birth Date. This value also accommodates the new Transpose Month and Day option (refer to GORCMSC description for details).

Additionally, the field label Required was changed to Core Matching Element in order to be easier to understand.

The SSN and Last Name/Non-Person Name elements are now Core Matching Elements.

Common Matching Rules Form (GORCMRL)

The names of several fields were changed in order to be easier to understand:

Additionally, you can now create comments for a rule set and/or matching rules. Comments for a rule set are recorded in the new Rule Set Comment field. Comments for matching rules can be created automatically by pressing the new Create Comments from Matching Rules button. Comments can also be entered manually.

Two new warning messages were added. A warning message appears if you attempt to delete an element that is designated as a Core Matching Element, or if you try to save a rule set that does not contain all Core Matching Elements.

. . . . . . . . . . . . . . Fields

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Descriptions

Rule Set Previously, this block was titled Rule Priorities.

Insert Core Matching Elements

Previously, this button was titled Create Required Rules.

Match on Null Data – Yes or No

Previously, this field was the Data Required indicator.

Choosing the Yes button for this field corresponds to checking the Exists check box in the previous version of Banner. This choice indicates that Banner and/or incoming data can be NULL or identical to be considered a Match.

Choosing the No button corresponds to checking the Required check box in the previous version. This choice indicates that Banner and incoming data must be NOT NULL and identical to be considered a Match.



Common Matching Source Rules Form (GORCMSC)

New options for building rules were added to this form.

Note: If you use these options, keep in mind that they will increase processing time and also yield more potential matches.

Options block fields

. . . . . . . . . . . . . . Fields

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Descriptions

Transpose Date Month / Day

You must include the Birth Date element in your rule in order to use this option.

The package will look for a match on the full birth date. If one is not found, it will then look at just the month and the day, and then transpose the month and day.

For example, if you enter 01/05 on GOAMTCH, you will receive matches on January 5th and May 1st.

Transpose First Name / Last Name

This option allows for the first and last names to be transposed.

Thomas Lee = Lee Thomas

Allow Alias Wildcard Use

This option appends a % (percent wildcard character) to incoming data in order to search for similar rows in alias tables.

For example, if you enter Bet on GOAMTCH, Common Matching will find Beth = Elizabeth in the alias table and return potential matches with a first or middle name of Elizabeth.

Allow Length Override

This option uses the length of incoming data to search for matches on name fields, if the length of data on the rule is greater than the data input.

For example, assume that you have a rule that specifies a length of 5 for First Name.

With the Allow Length Override option, if you enter Sam in First Name field on GOAMTCH, then potential matches that begin with Sam, such as Samuel, Samantha, and Samson will be found as potential matches.

Prevent ID Creation on API Failure

If you want to use this option, you must provide complete information for Address, Telephone and/or E-mail in order to create the new ID.

You can proceed with ID creation by removing partial information.

This option does not affect batch loads.



Hierarchy of Display fields

Create Hierarchy of Display Using Defaults (button)

Use this button to populate the Address, Telephone, and E-mail fields in the Hierarchy of Display blocks (GORCMDH table) from the Data Entry / Update Defaults values (GORCMSC table).

. . . . . . . . . . . . . . Fields

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Descriptions

Address This option allows address information to display even if it does not match. Matched addresses that are found by the Common Matching package display first. If no matching addresses are found, then the address type hierarchy that you specify in this block is used.

If you chose the Create Hierarchy of Display Using Defaults button in the previous block, then the address types in this block are the default hierarchy values from GORCMSC. You can add address types, or rearrange their order.

Telephone This option allows telephone information to display even if it does not match. Matched telephone numbers that are found by the Common Matching package display first. If no matching telephone numbers are found, then the telephone type hierarchy that you specify in this block is used.

If you chose the Create Hierarchy of Display Using Defaults button in the previous block, then the telephone types in this block are the default hierarchy values from GORCMSC. You can add telephone types, or rearrange their order.

E-mail This option allows e-mail information to display even if it does not match. Matched e-mail addresses that are found by the Common Matching package display first. If no matching e-mail addresses are found, then the e-mail type hierarchy that you specify in this block is used.

If you chose the Create Hierarchy of Display Using Defaults button in the previous block, then the e-mail types in this block are the default hierarchy values from GORCMSC. You can add e-mail types, or rearrange their order.

. . . . . . . . . . . . . . Fields

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Descriptions



Common Matching Source Code Validation Form (GTVCMSC)

The new Comment field enables you to create a comment up to 4,000 characters in length. This comment will appear on GORCMRL and GOAMTCH. You can click the Edit button to edit the comment.


Section 2 Multi-Institution Functionality (MIF) Enhancement - FunctionalUsing MIF

Section 2 Multi-Institution Functionality (MIF) Enhancement - Functional

Multi-Institution Functionality (MIF) enables a user to switch between Institution Codes while logged into Banner.

Note: MIF is only available at schools that have implemented Virtual Private Database (VPD) functionality. If your institution is interested in using MIF, it is strongly recommended that SunGard Higher Education Application Practices perform the implementation. Do not attempt to make VPD changes to the database on your own.

Using MIF

Home and Process Contexts

At institutions that use MIF, all forms that are MIF-enabled display two contexts in the title bar: the home context and the process context. In the following example, the home context appears first, and is enclosed in parentheses. The process context appears second, and has no parentheses.


Section 2 Multi-Institution Functionality (MIF) Enhancement - Functional Using MIF

Home Context

The home context is the Institution Code that you choose on the Set Institution Form (GUQSETI) when you log in to your Banner session. Your options for choosing the home context vary according to how Institution Codes are set up for you on the Oracle/Banner VPD Security Maintenance Form (GSAVPDI):

• If there are multiple Institution Codes set up for your User ID on the User Assignment tab of GSAVPDI, then you will have multiple codes from which to choose the home context for your Banner session. If you exit GUQSETI without manually selecting a code, then the code designated as your default Institution Code on GSAVPDI will be used as the home context. Your default code always appears first in the GUQSETI list, and is highlighted.

• If there is only one Institution Code set up on the User Assignment tab, then that code will be used as your home context, and GUQSETI will not appear when you log in.

• If no codes are set up for you on the User Assignment tab, then the Banner system default Institution Code will be used as your home context.

Process Context

The process context is the Institution Code to which you switch during your Banner session. If you do not change codes during the session, then your process context will be the same as your home context.

How to View the Institution Code

If your institution already uses Virtual Private Databases (VPD), you will see a change in the location of the Institution Code on your forms. Previously, it was located in a field on the form, but now it is located in the title bar of Banner.

How to Switch Between Institution Codes

If MIF has been implemented at your institution, you can switch between the databases at different campuses that comprise your institution. The databases to which you have access depend upon your user role and the particular security that has been set up for you.


Section 2 Multi-Institution Functionality (MIF) Enhancement - FunctionalUsing MIF

To Switch to Another Institution Code:

1. Click the icon on the toolbar.

--OR--

Press the Ctrl-Shift-F10 keys simultaneously.

2. Enter an Institution Code. You can use the Search button to select a code from the Institution Code Validation (GTVVPDI) list, or, if you want to view further information about the available codes, click the View Existing Institutions Values link. If you select a row from the Existing Institution Values list, the values are brought back to the key block of the form. You can then view the data related to those particular values elsewhere on the form.

3. Click OK.

This Institution Code (the “process context”) now appears in the title bar after the code under which you logged in (the “home context”). Depending on the security policies established by the institution, you may have the ability to insert, update, or delete information using this selected institution code, or you may be limited to only viewing data with this selected institution.

How Changing Institution Codes Impacts your Banner Session

Banner processes always use the user’s default Institution Code that is set on GSAVPDI. If you choose a different institution on the Set Institution Code Form (GUQSETI) when you log in to Banner, then this value becomes your default and is used by Banner processes, regardless of whether you switch to another code during the session. It is important to note, however, that the Banner forms you use during your session use the Institution Code to which you have switched, as long as those forms are MIF-enabled.


Section 2 Multi-Institution Functionality (MIF) Enhancement - Functional Using MIF

When you change Institution Codes during a session, the code that the forms use is the code that appears second in your title bar. The code you chose on GUQSETI upon login appears first in the title bar.

Example of title bar after you have switched Institution Codes:(CAMP1) : CAMP2

(CAMP1) is the code you chose upon login. It is always used by Banner processes, regardless of whether you change Institution Codes.

CAMP2 is the code to which you changed. It is used by Banner forms.

Oracle Reports

Running Oracle Reports From the Form

Oracle Reports are run using the process context setting (Camp 2 in the preceding example), as long as the form from which the report is being called is listed on GORVPDI.

Note: If the form that calls the Oracle Report is not listed on GORVPDI, then the report can only be run under the user's home context.

Running Oracle Reports From Job Submission

If you have Oracle Reports that can only be run via GJAPCTL, or if the Oracle Report is initiated through GJAPCTL, then the home context is used.

If users need to use the process context for Oracle Reports that are initiated through GJAPCTL, then you may consider adding GJAPCTL to GORVPDI. However, this causes the process context to appear in the title bar of GJAPCTL, which then allows the user to change Institution Codes. A user who is executing a C process or other Banner report might assume that the process or report is being executed under the process context institution, which is not the case. The change in the Institution Code is only effective for Oracle Reports.


Section 3 Common Matching Enhancement - TechnicalChanges to Common Matching Masking

Section 3 Common Matching Enhancement - Technical

Changes to Common Matching Masking

Masking functionality was improved for Common Matching by adding the new GOVCMID view which enables you to view one row per PIDM on the Potential Matches block.

Additionally, a new block replaced the existing GOVCMRT_SUSPENSE block on the Common Matching Form (GOAMTCH), and as a result, numerous form items were renamed. Several items on the GOVCMRT_MATCH block were renamed as well, although the block itself was not renamed.

Note: Existing masking records for individual text-type form items were consolidated into pull-down list form items. If any Masking records existed for those form items, you must manually add new Masking rows for the corresponding pull-down list or grouped form items.

GOVCMID Block

GOVCMRT_MATCH Block

OLD ITEM NAME NEW ITEM NAME

MATCH_CITY MATCH_CITY_STATE_ZIP

MATCH_STATE_CODE MATCH_ZIP_CODE

OLD ITEM NAME NEW ITEM NAME

MATCH_ATYP_DESCRIPTION ADDRESS_LIST

MATCH_ADDRESS_STATUS_IND ADDRESS_LIST

GOVCMRT_CMSR_PRIORITY_NO MATCH_LIST

GOVCMRT_MESSAGE MATCH_LIST


Section 3 Common Matching Enhancement - Technical New Table

The following scripts perform the renaming changes in the GORDMSK and GORDMCL tables:

• dgordmsk73.sql--Deletes the old item names from GORDMSK.

• dgordmcl73.sql--Deletes the old item names from GORDMCL.

• ugordmsk73.sql--Updates GORDMSK with the new and changed item names.

• ugordmcl73.sql--Updates GORDMCL with the new and changed item names.

New Table

Common Matching Display Hierarchy Table (GORCMDH)

This table stores the hierarchy of display elements.

The following scripts create this table:

• gorcmdh1.sql--Creates the table.

• gorcmdh2.sql--Creates the primary key.

• gorcmdh3.sql--Creates the foreign key.

• gorcmdh4.sql--Creates the comments on columns.

Name Type Nullable Comments

GORCMDH_CMSC_CODE VARCHAR2(20) N Common Matching Source Code.

GORCMDH_HIER_TYPE VARCHAR2(4) N Hierarchy Type Code.

GORCMDH_HIER_SEQ_NO NUMBER(2) N Hierarchy Sequence Number.

GORCMDH_HIER_CODE VARCHAR2(4) N Hierarchy Code.

GORCMDH_USER_ID VARCHAR2(30) N User ID.

GORCMDH_ACTIVITY_DATE DATE N Activity Date.

GORCMDH_DATA_ORIGIN VARCHAR2(30) N Data Origin.


Section 3 Common Matching Enhancement - TechnicalChanged Tables

Changed Tables

Common Matching Source Code Validation Table (GTVCMSC)

A column was added to this table to store a long description of the matching source that is displayed in the Comment field on GOAMTCH.

The following scripts add the new column to the table:

• gtvcmsc1.sql--Adds the long_desc column.

• gtvcmsc2.sql--Adds the comment on column.

Common Matching Source Priority Table (GORCMSP)

A column was added to this table to store a long description for the rule set. The description can be viewed/updated in the Rule Set Comment field on GORCMRL. It is view-only on GOAMTCH.

The following scripts make these changes:

• gorcmsp1.sql--Adds the long_desc column.

• gorcmsp2.sql--Adds the comment on column.

Common Matching Source Rules Table (GORCMSC)

Five new indicator columns were added to this table to support options for matching on transposed name, transposed date, alias, length overrides, and API failure.


GORCMSC_TRANSPOSE_DATE_IND VARCHAR2(1) N Transpose Date Indicator.

GORCMSC_TRANSPOSE_NAME_IND VARCHAR2(1) N Transpose Name Indicator.

GORCMSC_ALIAS_WILDCARD_IND VARCHAR2(1) N Wildcard Alias Indicator.


Section 3 Common Matching Enhancement - Technical Changed Tables


• gorcmsc1.sql--Adds the five indicator columns.

• gorcmsc2.sql--Populates the new indicator columns.

• gorcmsc3.sql--Makes the new indicator columns not null.

• gorcmsc4.sql--Adds the comments on columns.

Common Matching Name Translation Table (GORNAME)

Indexes were created on this table for Name and Alias.

The KEY1 and KEY2 indexes were removed from this table.


• gorname6.sql--Drops key index1.

• gorname7.sql--Drops key index2.

• gorname8.sql--Creates the new indexes.

Common Matching Non-Person Name Translation Table (GORNPNM)

Two new columns were added to this table to store the compressed values of the Name and Alias columns.

GORCMSC_LENGTH_OVERRIDE_IND VARCHAR2(1) N Length Override Indicator.

GORCMSC_API_FAILURE_IND VARCHAR2(1) N API Failure Indicator.


GORNPNM_NAME_COMPRESS VARCHAR(60) Y Compressed name value.

GORNPNM_ALIAS_COMPRESS VARCHAR(60) Y Compressed alias value.



Section 3 Common Matching Enhancement - TechnicalNew SEED Data


• gornpnm1.sql--Adds the two new columns.

• gornpnm2.sql--Updates the values with the compressed values of the name and alias columns.

• gornpnm3.sql--Creates the index on the name and alias columns.

• gornpnm4.sql--Creates the comments on columns.

Common Matching Match Entry Global Temporary Table (GOTCMME)

The Last Name column (GOTCMME_LAST_NAME) was changed to allow NULL values. This allows a match on SSN without having a Last Name required.

Note: SunGard Higher Education recommends that you use SSN without Last Name for online processing only (not batch).


• gotcmme1.sql--Makes last name nullable.

• gotcmme2.sql--Adds the Address Source Code.

• gotcmme3.sql--Creates the comment on column.

Common Matching Data Dictionary Table (GORCMDD)

A record was added to store the full Birth Date.

The following scripts makes this change:

• gorcmdd1.sql--Creates the comment on column.

• igorcmdd73.sql --Inserts a new data dictionary record for Birth Date.

• ugorcmdd73.sql--Updates the SPBPERS SSN column.

New SEED Data

Options Maintenance Table (GUROPTM)

A row was added to this table in order for GORCMSC to support the new button that generates the Hierarchy of Display from Default Values.


Section 3 Common Matching Enhancement - Technical New View

New View

GOVCMID

This view enables you to view Common Matching results in a one row per PIDM format on the Potential Matches block of GOAMTCH.

Changed View

GOVCMRT

The Name Change logic in this view was changed so that the position of the asterisk is now after the last name.

The ID Change logic was changed to look for an ID Change value. Previously, it was checking for a Name Change value.

New APIs

Common Matching Display Hierarchy

This API provides the Common Business interface for Common Matching Display Hierarchy.

gb_cm_disp_hier

gokb_cm_disp_hier0.sql (package specification)gokb_cm_disp_hier1.sql (package body)

This package contains the basic procedures and functions that allow users to query, insert, update, or delete data in the Common Matching Display Hierarchy Table (GORCMDH).


Section 3 Common Matching Enhancement - TechnicalChanged APIs

gokb_cm_disp_hier_r0.sql (package specification)gokb_cm_disp_hier_r1.sql (package body)

This package contains supporting rules for the Common Matching Display Hierarchy API for the Common Matching Display Hierarchy Table (GORCMDH).

gokb_cm_disp_hier_s0.sql (package specification)gokb_cm_disp_hier_s1.sql (package body)

The package contains the error messages for the Common Matching Display Hierarchy API.

gokd_gorcmdh0.sql (package specification)gokd_gorcmdh1.sql (package body)

This DML package provides support for the Common Matching Display Hierarchy API.

Changed APIs

Common Matching Data Dictionary

gb_cm_data_dictionary

gokb_cm_data_dict0.sql (package specification)gokb_cm_data_dict1.sql (package body)

This package was changed to support the new function which returns a column based on the element selected in GORCMDD.

Common Matching Rules

gb_cm_rules_str

gokb_cm_rules_s0.sql (package specification)gokb_cm_rules_s1.sql (package body)

This package was changed to support the modified form prompts in GORCMSR.


Section 3 Common Matching Enhancement - Technical Changed APIs

Common Matching Source Priority

gb_cm_source_priority

gokb_cm_srce_prior0.sql (package specification)gokb_cm_srce_prior1.sql (package body)gokb_cm_srce_prior_r0.sql (rules package specification)gokb_cm_srce_prior_r1.sql (rules package body)gokd_gorcmsp0.sql (DML package specification)gokd_gorcmsp1.sql (DML package body)

Most of the packages in this API were changed to support the new long description column in GORCMSP.

Common Matching Source Rules

gb_cm_source_rules

gokb_cm_srce_rule0.sql (package specification)gokb_cm_srce_rule1.sql (package body)gokb_cm_srce_rule_r0.sql (rules package specification)gokb_cm_srce_rule_r1.sql (rules package body)gokb_cm_srce_rule_s0.sql (strings package specification)gokb_cm_srce_rule_s1.sql (strings package body)gokd_gorcmsc0.sql (DML package specification)gokd_gorcmsc1.sql (DML package body)

This API was changed to support the five new Common Matching indicators in GORCMSC.

GTVCMSC Validation

gb_gtvcmsc

gvkd_gtvcmsc0.sql (package specification)gvkd_gtvcmsc1.sql (package body)

This validation API was changed to provide support for the new long description column in GTVCMSC.


Section 3 Common Matching Enhancement - TechnicalChanged Packages

Changed Packages

gokcmpk.sql gokcmpk1.sql

The Common Matching package was changed to support the improved functionality of Common Matching. Changes are sorted by functional impact.

Last Name Not Required

The P_PRIMARY_MATCH_NAME routine was changed to verify whether the user has provided a value for the last name. If no value is provided, then the package skips the rest of the logic in this section.

Full Date Comparison

• Support was added to the P_MATCH_SPBPERS routine to support full-date comparison. This section already contained support to validate the three separate sections of the birth date. The support for this comparison will be made if there is a rule defined for the birth date and all three values have been entered by the user.

• A new constant was added for SPRIDEN_BIRTH_DATE.

• New logic was added to P_MATCH_SPBPERS to verify that a rule exists for this attribute. If it does, then the package verifies that all three parts of the date have been entered. When both of these conditions are met, a full-date comparison is performed using the GOTCMME_BIRTH_MON, GOTCMME_BIRTH_DAY, and GOTCMME_BIRTH_YEAR columns matching to the SPBPERS_BIRTH_DATE values.

Cross Matching of Month and Day

The package was changed so that if the SPRIDEN_BIRTH_DATE rule exists, then the GOTCMME_BIRTH_MON and GOTCMME_BIRTH_DAY are verified to be not null. If these two conditions are met, then a match is performed for these two columns against the month and day of the SPBPERS_BIRTH_DATE. If a match does not occur, then the package checks to see if the Transpose Date indicator is set to Y. If so, then the order of GOTCMME_BIRTH_MON and GOTCMME_BIRTH_DAY is switched, and compared to the month and day of the SPBPERS_BIRTH_DATE.


Section 3 Common Matching Enhancement - Technical Changed Packages

Matching on Transposed Names

The insert statements in which name matching occurs were moved to a new procedure called P_INSERT_NAMES. Logic in the P_PRIMARY_MATCH_NAME procedure was then modified to call this new procedure, passing in the data for the comparison logic. As a result, the P_PRIMARY_MATCH_NAME routine now performs the standard name matching logic by calling the P_INSERT_NAMES procedure. When this is complete, a check of the Transpose Name indicator is performed. If the indicator is set to Y, then P_INSERT_NAMES is called again, passing in the search data with the names transposed.

Person Name Alias Changes

Previously, the search length criteria rules were applied differently to the data from the GOTCMME table than to the database item, which resulted in fewer matches. Accordingly, the routine was modified to apply the search length rules to both of these items and store them in local variables. The query was then modified to use these local variables in the query. Additionally, logic was added to check the Alias Wildcard indicator to determine whether to append the % (percent wildcard) character. The query was modified to perform a LIKE query regardless of whether the % was applied.

Non-person Name Alias Changes

• The changes that were applied to the person alias function were applied to the non-person alias function. Refer to Person Name Alias Changes for details.

• The F_NP_ALIAS_EXISTS routine was renamed F_TEST_NP_NAME to make it consistent with the name of the person alias function. Additionally, the function was made public so that it could be implemented in the name search queries in a method similar to the person alias function.

Search Length Override

This procedure was modified so that the start position and search length are calculated for name items. Then, the Length Override indicator is evaluated. If the indicator is set to Y, then the length of the user-entered data is compared to the rule length. If the length of the data entered is less than the rule length, then the length of the data is used instead of the rule length.


Section 3 Common Matching Enhancement - TechnicalChanged Packages

Miscellaneous Performance Improvements

• Entity Code--Calls to F_GET_ENTITY_CDE in several routines were removed and placed in the P_COMMON_MATCHING routine, so that the entity code associated with a given source code is now stored in a global variable, rather than being retrieved every time the primary and secondary match routines are executed.

• Elements--The P_COMMON_MATCHING routine was changed to load all of the data dictionary element descriptions into a PL/SQL table indexed by the column name and globally accessible. Queries to retrieve the data element descriptions were simplified and improved, since they no longer needed to join the GORCMDD and GORCMSR tables.

• Column rules for each priority--As part of the query join (see preceding change), the column rules for required, search position, and search length were being fetched in all queries. Since the column rules are specific to each priority that exists for the source code, the priority looping logic in the P_COMMON_MATCHING procedure was changed to load all of the column rules into a PL/SQL table indexed by column name. The values in the PL/SQL table are accessible globally. All of the queries were rewritten to remove the joins needed to obtain this information. The Length Override indicator is checked and implemented accordingly as part of this logic.

• A new P_GET_RULES routine was added so that all of the places in the package where column rules are needed can now call this procedure to have the PL/SQL table values returned. Calls to this new routine were added to all of the procedures where they were needed.

• Determine if user procedures exist--User-defined procedures can be associated with each priority. The previous logic attempted to verify whether they existed for each priority as each one was being processed. The logic was updated to perform one call to populate a global variable if any rules exist for the source code. Now, a global variable is tested. If no rules exist for the source code, then the process skips querying the table for each priority.

• Repeated logic for message building, data comparison, and other tasks was consolidated into procedures.

• Unused message constants were removed.

• Counting of the match, no match, and missing increment results is now solely performed in the new P_INCREMENT_CNTS routine.

• Many of the IF…THEN…ELSIF…END IF commands were replaced with CASE statements for faster performance.

• A new P_INCREMENT_RESULT_TABLE function was created to perform the incrementing of the result table for match, no match, and missing counts. Previously, this logic was executed in several routines.

• A new P_SET_RESULT_TABLE procedure was added to interpret the values in the result table and set the match, no match, or missing indicators. Previously, this logic was executed in several routines.

• A new P_MATCH_MSG procedure was added to build the match, no match, or missing message which is returned after each test. Previously, this logic was executed in several routines.


Section 3 Common Matching Enhancement - Technical Changed Packages

• A new P_POPULATE_DATAREC procedure was added to load the various local variable values into the data record which is passed between the many procedures. This change reduced the repeated commands and consolidated logic.

• A new P_INSERT_NAMES routine was added perform the primary name matching logic. This was done so that the separate routine could be used as part of the primary name search and as part of the name transposing (refer to preceding text for details). The SQL statements which referenced the GORNPNM table were modified to use the new compress search columns, instead of having to apply the compress function as part of the query.

• The order of the routines in the package was changed so that none of the empty declarations were required.

• Many of the redundant local variables were removed and replaced with global variables. The global variables only need to be declared once, reducing the number of variables needed by the package.

• Queries with embedded cursors were modified to remove the joins to the Dictionary and Element tables. Refer to the notes on Elements and Column rules in the preceding text for details.

• The name matching queries for non-person processing were changed to remove the direct joins to the Non-Person Alias table and to add a call to the F_TEST_NP_NAME function to the where clause. Non-person name matching queries were changed to perform the same sub-query to the SPRIDEN table as the person name matching queries, improving performance.

• The P_COMMON_MATCHING routine was changed to verify that a source code has been passed. Previously, this was not done and the user would receive an incorrect error message about an Invalid ID. If the source code is not passed, then an appropriate error message is generated.

gokb_cm_rules1.sql

This package was changed to allow checking to occur such that all Core Element Matching Rules for *all* users are validated, not just those that were added by the current user.

The user only receives a caution that their rule does not contain all Core Elements, and is not stopped during the rule build process.


Section 4 Multi-Institution Functionality (MIF) Enhancement - TechnicalChanged Packages

Section 4 Multi-Institution Functionality (MIF) Enhancement - Technical

Multi-Institution Functionality (MIF) enables a user to switch between Institution Codes while logged into Banner. By using MIF, data can be segmented by different organizational entities, such as campuses, within the same physical Banner database environment.

Note: MIF is only available at schools that have implemented Virtual Private Database (VPD) functionality. If your institution is interested in using MIF, it is strongly recommended that SunGard Higher Education Application Practices perform the implementation. Do not attempt to make VPD changes to the database on your own.

You can only set up MIF after VPD has been implemented. Additionally, several WebTailor components are required for setup if MIF is used in Self-Service Banner or Luminis Channels for Banner. Refer to the Middle Tier Implementation Guide for instructions about configuring MIF.

Home and Process Contexts

At institutions that use MIF, all forms that are MIF-enabled display two contexts in the title bar: the home context and the process context. In the following example, the home context appears first, and is enclosed in parentheses. The process context appears second, and has no parentheses.


Section 4 Multi-Institution Functionality (MIF) Enhancement - Technical New Form

Home Context

The home context is the Institution Code that you choose on the Set Institution Form (GUQSETI) when you log in to your Banner session. Your options for choosing the home context vary according to how Institution Codes are set up for you on the Oracle/Banner VPD Security Maintenance Form (GSAVPDI):

• If there are multiple Institution Codes set up for your User ID on the User Assignment tab of GSAVPDI, then you will have multiple codes from which to choose the home context for your Banner session. If you exit GUQSETI without manually selecting a code, then the code designated as your default Institution Code on GSAVPDI will be used as the home context. Your default code always appears first in the GUQSETI list, and is highlighted.

• If there is only one Institution Code set up on the User Assignment tab, then that code will be used as your home context, and GUQSETI will not appear when you log in.

• If no codes are set up for you on the User Assignment tab, then the Banner system default Institution Code will be used as your home context.

Process Context

The process context is the Institution Code to which you switch during your Banner session. If you do not change codes during the session, then your process context will be the same as your home context.

New Form

VPDI Included Objects Form (GORVPDI)

Use this form to list the forms that are enabled for MIF at your institution. When a form is added to this list, then both the home and process contexts appear in the title bar of the form.

If you add a form that has had VPD changes applied to it, then the MIF toolbar button becomes active and users can access the Institution Code Validation list of values (LOV) from that form. For forms that have not had VPD applied to them, the button is not active.

Note: Do not add forms that do not re-query data and use the Rollback function. If the data cannot be re-queried, then the user should not be changing Institution Codes while on that form.

This form appears on the Miscellaneous General Forms Menu (*GENMISC).


Section 4 Multi-Institution Functionality (MIF) Enhancement - TechnicalChanged Form

Changed Form

Banner Global Initialization Form (GUAINIT)

This form was changed so that if Banner is launched from Luminis in a MIF environment, then GUQSETI does not appear. Instead, when a user logs in to Banner through Luminis, the home context is set to the institution that was being viewed in the channel from which Banner was called.

Additionally, if a user is running two applications and the MIF code is not transferred correctly to the second application, then an error occurs and the user cannot access Banner. The following error message appears: Missing Institution Code - Contact System Administrator.

Changed Menu

gumappl.mmb

The MIF button was added to the ICONS menu on the toolbar. This menu item calls the G$_VPDI.CALL_VPDI_COMPONENT procedure, which enables users to switch Institution Codes.

Several labels were changed for the existing FGAC and VPDI icons in order to be consistent with the new MIF functionality.

. . . . . . . . . . . . . . Fields

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Descriptions

Object Name Name of the Banner object. Choices come from the Object Maintenance Form (GUAOBJS) list.

Description Description of the Banner object. This value comes from the description associated with the object on GUAOBJS.


User ID User ID that created or modified the record.


Section 4 Multi-Institution Functionality (MIF) Enhancement - Technical New Table

New Table

MIF Forms Table (GOBVPDI)

This table stores the MIF-enabled forms.

The following scripts create the GOBVPDI table:

• gobvpdi1.sql--Creates the table.

• gobvpdi2.sql--Creates the primary key.

• gobvpdi3.sql--Creates the comments on table and columns.


GOBVPDI_OBJECT VARCHAR2(30) N OBJECT NAME: The name of the Banner Form with VPDI enabled functionality.

GOBVPDI_USER_ID VARCHAR2(30) N USER ID: User ID of the user who created or last updated the record.

GOBVPDI_ACTIVITY_DATE DATE N ACTIVITY DATE: Date the record was created or last updated.

GOBVPDI_DATA_ORIGIN VARCHAR(2)30 Y DATA ORIGIN: Source system that created or updated the row.


Section 4 Multi-Institution Functionality (MIF) Enhancement - TechnicalChanged Table

Changed Table

GTVVPDI

A GTVVPDI public synonym was created for this table. It enables grant selects on GTVVPDI to public.

Changed Libraries

Dynamic Procedure Library (goqrpls.pll)

The new MIF toolbar button was added to the G$_TOOLBAR package.

The Institution Code Validation list of values (LOV) window was added to this library. It is comprised of the following elements:

• GTVVPDI_RG

• GTVVPDI_LOV

• G$_VPDI_ALL_RG

• G$_VPDI_ALL_LOV

• G$_VPDI_WINDOW

• G$_VPDI_CANVAS

• G$_VPDI_BLOCK

Note: This window cannot be used in a block on a form where the Rollback command has been disabled. When the user changes the MIF code and returns to the form, then the Rollback command is issued, and then the data is re-queried. The re-querying can only occur if the default behavior in the form is to re-query after the Rollback command has been executed. Otherwise, the user must re-query the data manually.

Logic was added to the G$_WIN_CLOSED procedure so that the Institution Code Validation list of values (LOV) window closes correctly.

The following PL/SQL routines were modified to support MIF:

• G$_SET_INST_PROPERTY

• G$_SECURED_FORM_CALL_PL

• G$_GOQOLIB_KEY_TRIGGER.B2K_EXIT_FORM


Section 4 Multi-Institution Functionality (MIF) Enhancement - Technical Changed Libraries

Workflow Library (goqwflw.pll)

This library was changed so that if Banner is called from a Workflow, then the Institution Code being used in the Workflow is also the one used for the Banner session. GUQSETI does not appear.

Note: The Institution Code cannot be changed if Banner was called from a Workflow.

Additionally, the following procedures were modified to support MIF:

• G$_WF_WAIT_FOR_WORK.WF_INIT_GLOBALS

• WF_PERFORM_AUTO_LOGON--Includes the logic to handle MIF parameters

• G$_WF_BA.GET_WORK

A new global, GLOBAL.WF_VPDI_HOME_CODE, supports MIF.

A new call was added to WFIKWIBC.get_workitem_queue that includes a VPDI parameter.

The new vpdiCodeNotMatch exception was added to display an error message if a user is running two applications and the MIF code is not transferred correctly to the second application. The following error message appears: Missing Institution Code - Contact System Administrator.

General PL/SQL Oracle*Reports Library (goqorep.pll)

A new package, G$_REPORT_VPDI, was added to this library.

New parameters were added to the G$_SCR_RUN_REPORTS package.

Two new functions were added to the G$_SCT_RUN_REPORT_SERVER and G$_SCT_RUN_REPORT_ONLINE procedures:

• p_vpdi_home_code

• p_vpdi_process_code


Section 4 Multi-Institution Functionality (MIF) Enhancement - TechnicalNew GIF File

Form Object Library (goqolib.fmb)

Note: Changes to this library require that all forms be regenerated for Release 7.3.

Several new objects were added to the G$_TOOLBAR object group to support MIF:

• gtvvvpdi_rg

• gtvvpdi_lov

• g$_vpdi_all_rg

• g$_vpdi_all_lov--Contains the title Existing Institution Values • g$_vpdi_window

• g$_vpdi_canvas

• g$_vpdi_block

The KEY_F10 was defined in G$_FORM_CLASS class to call G$_VPDI.CALL_VPDI_COMPONENT.

Logic was added to the following triggers in the G$_FORM_CLASS class:

• G$_VERIFY_ACCESS

• G$_REVOKE_ACCESS

• POST-FORM

• KEY-EXIT

New GIF File

vpdi.gif

This image supports the new MIF button on the toolbar.

Changed JAR File

banicons.jar

The vpdi.gif image was added to this .jar file.


Section 4 Multi-Institution Functionality (MIF) Enhancement - Technical SEED Data

SEED Data

The following SEED data were added to the GTVSQPR table. The script that inserts these values is igtvspqr73.sql.

New Packages

gokvpda.sqlgokvpda1.sql

This BANINST1 package is the VPD adapter interface that controls the integration with custom VPD policy functions. It sets application context and home context for all Unified Digital Campus components.

The API package to this call is: GOKVPDA.p_set_vpdi_for_query.

In addition to MIF support, this interface is also used for Banner forms, Oracle Reports, Banner jobs, BXS, and Workflow integration.

gspvpdi.sqlgspvpdi1.sql

This BANSECR package provides a list of MIF codes based on PIDM and checks user home verification for BXS.

GTVSQPR_CODE GTVSQPR_DESC GTVSQPR_USER_ID ------------ ------------ --------------- VPD VPD Processing GENERAL


Section 4 Multi-Institution Functionality (MIF) Enhancement - TechnicalChanged BANSECR Package

Changed BANSECR Package

gspvpds.sql

The following procedures were added to this package to support MIF for the Unified Digital Campus (UDC):

• g$_vpdi_get_mif_codes

• g$_vpdi_set_current_inst_code_

• g$_vpdi_get_current_inst_code

• g$_is_mif_enabled

• g$_vpdi_get_proc_context_fnc

Changed Trigger

gstvpds0.sql

This BANSECR logon trigger must be disabled due to the 7.3 redesign of Multi-Institution Functionality. If Application Practices has not installed this modification at your site, then the trigger must be disabled; otherwise, you will not be able to run Banner. A disable statement was added to the script to assist you.


Section 4 Multi-Institution Functionality (MIF) Enhancement - Technical Sample Setup Rules for MIF

Sample Setup Rules for MIF

When a form is added to GORVPDI, then the Institution List window will appear on that form when a user tries to switch Institution Codes. The following example illustrates the window on the Basic Course Information Form (SCACRSE).

The Institution List on SCACRSE


Section 4 Multi-Institution Functionality (MIF) Enhancement - TechnicalSample Setup Rules for MIF

If a user chooses the View Existing Institution Values link from that window, then the available values appear in the LOV:

The List of Values for SCACRSE

In order for the list of values to be populated for a form, you must build Dynamic SQL statements on the Business Rules Form (GORRSQL). The SQL is used to populate the form’s LOV to show data across the institution, and enables the user to select values to bring back to the key block.

In the first example in the following pages, the Basic Course Information Form (SCACRSE) is used to illustrate how to build the required rules for a MIF-enabled form that does not have an ID in the key block.

The second example illustrates the rules for a form that has an ID in the key block, such as the Transcript Events and Comments Form (SHATCMT).



Sample Rule Setup for a Form Without a Key Block ID

1. Go to the Business Rule Process Code Validation Form (GTVSQPR) and enter the name of the process code. VPD is delivered as SEED data.

2. Go to the Business Rule Code Validation Form (GTVSQRU) and create a name for the rule, for example, SCACRSE.

3. Go to the Business Rules Form (GORRSQL) and enter the VPD process code and the SCACRSE rule you created, and then create a SQL statement for the rule.

Note: Make sure the Active check box is checked, and that the Sequence number for your rule is one of one (sequences of more than one are not supported).

GORRSQL with Dynamic LOV Metadata for SCACRSE



Example:

Sample Rule Setup for a Form With a Key Block ID

1. Go to the Business Rule Process Code Validation Form (GTVSQPR) and enter the name of the process code. VPD is delivered as SEED data.

2. Go to the Business Rule Code Validation Form (GTVSQRU) and create a name for the rule, for example, SHATCMT.

3. Go to the Business Rule Parameter Code Validation Form (GTVSQPA) and create a parameter code, for example, PIDM_VPD.

4. Go to the Business Rule Process Parameters Form (GORSQPA) and associate the parameter code you just created with the VPD process code.

5. Go to the Business Rules Form (GORRSQL) and enter the VPD process code, and the SHATCMT rule you created, and then create a SQL statement for the rule. Make sure your statement contains the following:

(a) Add [PIDM] item mapped to the ID field on a form to the mapping list.

Example:shrevnt_vpdi_code||'=G$_VPDI_BLOCK.VPDI_CODE<KEY_BLOCK.PIDM>'

SELECT scbcrse_vpdi_code, scbcrse_subj_code, scbcrse_crse_numb,

scbcrse_eff_term, scbcrky_term_code_end, scbcrse_title,

'X','X','X','X',

'VPDI Code::Subject::Course::Start Term::End

Term::Title::NONE::NONE::NONE::NONE',

scbcrse_subj_code||'=SCACRSE_KEY_BLOCK.SCACRSE_SUBJ_CODE'||

'::'||

scbcrse_crse_numb||'=SCACRSE_KEY_BLOCK.SCACRSE_CRSE_NUMB'||

'::'||

scbcrse_eff_term||'=SCACRSE_KEY_BLOCK.SCACRSE_TERM_CODE_EFF'||

'::'||

scbcrse_vpdi_code||'=G$_VPDI_BLOCK.VPDI_CODE'

FROM scbcrky, scbcrse

WHERE scbcrky_subj_code = scbcrse_subj_code

AND scbcrky_crse_numb = scbcrse_crse_numb

AND scbcrky_vpdi_code = scbcrse_vpdi_code

AND scbcrse_vpdi_code = NVL( ':1', scbcrse_vpdi_code )

ORDER BY scbcrse_vpdi_code, scbcrky_subj_code,scbcrky_crse_numb,scbcrse_eff_term



(b) Add =:PIDM_VPD defined in GORSQPA Form to 'where clause'.

Example:where shrevnt_pidm=:PIDM_VPD

Note: Make sure the Active check box is checked, and that the Sequence number for your rule is one of one (sequences of more than one are not supported).

Example: GORRSQL with Dynamic LOV Metadata for SHATCMT

About the All Institutions Dynamic LOV Template

The All Institutions Dynamic LOV component is based on the template rule shown below.

Assumptions

1. There will be only 10 available columns in the LOV that are mapped to the corresponding fields in a key block. The following table shows these columns:

• Columns one through 10 are reserved for column values that are retrieved by a query. If there is no column available, then by design, the value must be X.

• There must be 10 values selected, separated by ',' . Ten columns must match 10 cells in a table.

Example:scbcrse_vpdi_code, scbcrse_subj_code, scbcrse_crse_numb,scbcrse_eff_term, scbcrky_term_code_end, scbcrse_title,

'X','X','X','X'

Column 1 scbcrse_vpdi_codeColumn 2 scbcrse_subj_code

SELECT /*DISTINCT*/ shrevnt_vpdi_code,shrevnt_even_code,shrevnt_levl_code, shrevnt_orig_code,'X','X','X','X','X','X', 'Miff Code::Event Code::Level Code::Originator Code::NONE::NONE::NONE::NONE::NONE::NONE', shrevnt_levl_code||'=KEY_BLOCK.KEYBLCK_LEVL_CODE'|| '::'|| shrevnt_orig_code||'=KEY_BLOCK.KEYBLCK_ORIG_CODE'|| '::'|| shrevnt_vpdi_code||'=G$_VPDI_BLOCK.VPDI_CODE<KEY_BLOCK.PIDM>' FROM shrevntwhere shrevnt_pidm=:PIDM_VPDAND shrevnt_vpdi_code = NVL( ':1', shrevnt_vpdi_code )

1 2 3 4 5 6 7 8 9 10 11 12Data Data Data Data Data Data Data Data Data Data Titles

RulesData Binding Rules



Column 3 scbcrse_crse_numbColumn 4 scbcrse_eff_termColumn 5 scbcrky_term_code_endColumn 6 scbcrse_titleColumn 7 XColumn 8 XColumn 9 XColumn 10 X

• Column 11 is reserved for LOV Titles separated by '::' delimeter.

If there is no title provided, then the value must be NONE.

There must be 10 parameters separated by a '::' delimeter.

Example:'VPDI Code::Subject::Course::Start Term::EndTerm::Title::NONE::NONE::NONE::NONE'

• Column 12 is reserved for mapping values to the corresponding fields in a Banner form.

Example:

2. The following condition must be also provided for all SQL statements for data binding:

AND scbcrse_vpdi_code = NVL( ':1', scbcrse_vpdi_code )

scbcrse_subj_code||'=SCACRSE_KEY_BLOCK.SCACRSE_SUBJ_CODE'|| '::'||scbcrse_crse_numb||'=SCACRSE_KEY_BLOCK.SCACRSE_CRSE_NUMB'|| '::'||scbcrse_eff_term||'=SCACRSE_KEY_BLOCK.SCACRSE_TERM_CODE_EFF'|| '::'||scbcrse_vpdi_code||'=G$_VPDI_BLOCK.VPDI_CODE'


Section 5 API Enhancement - TechnicalChanged Forms

Section 5 API Enhancement - Technical

Numerous APIs were created in order to support the collection of Visa, medical, and college degree data. The APIs and tables related to medical and immunization codes support the XML Transcript enhancement in Banner Student. For information about using XML Transcript, refer to the Banner Student 7.3 Release Guide.

Changed Forms

International Information Form (GOAINTL)

Calls to the new Visa Code API (gb_visa) were added to this form.

This form was modified to no longer use the following GTVSDAX default values:

GROUP : INTERNATIONAL

Previously, when a new Visa record was created on the GOAINTL form and these fields were left blank, values were stored in the database according to the rules established in GTVSDAX.

Code Description

VISADATDEF Default Visa Start and End Date

VISAISSDEF Visa Issuing Authority Default for Inserts

VISANBRDEF Default Visa Number

VISANTNDEF Default Nation where Visa is Issued


Section 5 API Enhancement - Technical Changed Forms

Because the GORVISA table was changed to allow these fields to be null, the form no longer defaults values into the database when the fields are left blank. Any data that was previously created with default values will now display on the form if the values are still in the database.

Optional scripts (described in following pages) are delivered with this release to identify those records the have default values, so that the records can be manually reviewed and those fields can be updated to be blank, where appropriate. If the scripts are not run, and the GORVISA records are not updated, the result will be that the default values will now display on the GOAINTL form, where previously those fields would have appeared blank.

Medical Disability Rule Form (GORMEDR)

The Medical Code field was expanded from two to ten characters in order to hold the PESC standard code for immunization.

The gormedr1.sql script makes the table change that supports this form.

Medical Code Validation Form (STVMEDI)


The stvmedi1.sql script makes the table change that supports this form.

General Medical Information Form (GOAMEDI)


The new Medical Date field enables you to record the date associated with the Medical Code so you can track immunization schedules or any date-related medical information.


Section 5 API Enhancement - TechnicalNew Business Entity APIs

New Business Entity APIs

Medical Code

This API maintains information about medical conditions of people at your institution, including students, faculty, and staff.

gb_medical

gokb_medical0.sql (package specification)gokb_medical1.sql (package body)

This package contains the basic procedures and functions that allow users to query, insert, update, or delete data in the Person Medical Information Repeating (SPRMEDI) table.

gb_medical_rules

gokb_medical_r0.sql (package specification)gokb_medical_r1.sql (package body)

This package contains supporting rules for the Medical Code API for the Person Medical Information Repeating (SPRMEDI) table.

gb_medical_strings

gokb_medical_s0.sql (package specification)gokb_medical_s1.sql (package body)

The package contains the error messages for the Medical Code API.

gb_medical_dml

gokd_medical0.sql (package specification)gokd_medical1.sql (package body)

This DML package supports the Medical Code API.


Section 5 API Enhancement - Technical New Business Entity APIs

Prior College

This API maintains a person's educational background, including institutions attended, degrees received at each institution (majors, minors, and areas of concentration).

gb_prior_college

gokb_prior_college0.sql (package specification)gokb_prior_college1.sql (package body)

This package contains the basic procedures and functions that allow users to query, insert, update, or delete data in the Prior College (SORPCOL) table.

gb_prior_college_rules

gokb_prior_college_r0.sql (package specification)gokb_prior_college_r1.sql (package body)

This package contains supporting rules for the Prior College API for the Prior College (SORPCOL) table.

gb_prior_college_strings

gokb_prior_college_s0.sql (package specification)gokb_prior_college_s1.sql (package body)

The package contains the error messages for the Prior College API.

gb_prior_college_dml

gokd_sorpcol0.sql (package specification)gokd_sorpcol1.sql (package body)

This DML package supports the Prior College API.

Prior College Concentration

This API maintains a person's educational background, including institutions attended, degrees received at each institution, and majors, minors, and areas of concentration at each institution.



gb_pcol_concentration

gokb_pcol_conc0.sql (package specification)gokb_pcol_conc1.sql (package body)

This package contains the basic procedures and functions that allow users to query, insert, update, or delete data in the Prior College Concentration (SORCONC) table.

gb_pcol_concentration_rules

gokb_pcol_conc_r0.sql (package specification)gokb_pcol_conc_r1.sql (package body)

This package contains supporting rules for the Prior College Concentration API for the Prior College Concentration (SORCONC) table.

gb_pcol_concentration_strings

gokb_pcol_conc_s0.sql (package specification)gokb_pcol_conc_s1.sql (package body)

The package contains the error messages for the Prior College Concentration API.

gb_pcol_concentration_dml

gokd_sorconc0.sql (package specification)gokd_sorconc1.sql (package body)

This DML package supports the Prior College Concentration API.



Prior College Degree


gb_pcol_degree

gokb_pcol_degree0.sql (package specification)gokb_pcol_degree1.sql (package body)

This package contains the basic procedures and functions that allow users to query, insert, update, or delete data in the Prior College Degree (SORDEGR) table.

gb_pcol_degree_rules

gokb_pcol_degree_r0.sql (package specification)gokb_pcol_degree_r1.sql (package body)

This package contains supporting rules for the Prior College Degree API for the Prior College Degree (SORDEGR) table.

gb_pcol_degree_strings

gokb_pcol_degree_s0.sql (package specification)gokb_pcol_degree_s1.sql (package body)

The package contains the error messages for the Prior College Degree API.

gb_pcol_degree_dml

gokd_sordegr0.sql (package specification)gokd_sordegr1.sql (package body)

This DML package supports the Prior College Degree API.



Prior College Major


gb_pcol_major

gokb_pcol_major0.sql (package specification)gokb_pcol_major1.sql (package body)

This package contains the basic procedures and functions that allow users to query, insert, update, or delete data in the Prior College Major (SORMAJR) table.

gb_pcol_major_rules

gokb_pcol_major_r0.sql (package specification)gokb_pcol_major_r1.sql (package body)

This package contains supporting rules for the Prior College Major API for the Prior College Major (SORMAJR) table.

gb_pcol_major_strings

gokb_pcol_major_s0.sql (package specification)gokb_pcol_major_s1.sql (package body)

The package contains the error messages for the Prior College Major API.

gb_pcol_major_dml

gokd_sormajr0.sql (package specification)gokd_sormajr1.sql (package body)

This DML package supports the Prior College Major API.



Prior College Minor


gb_pcol_minor

gokb_pcol_minor0.sql (package specification)gokb_pcol_minor1.sql (package body)

This package contains the basic procedures and functions that allow users to query, insert, update, or delete data in the Prior College Minor (SORMINR) table.

gb_pcol_minor_rules

gokb_pcol_minor_r0.sql (package specification)gokb_pcol_minor_r1.sql (package body)

This package contains supporting rules for the Prior College Minor API for the Prior College Minor (SORMINR) table.

gb_pcol_minor_strings

gokb_pcol_minor_s0.sql (package specification)gokb_pcol_minor_s1.sql (package body)

The package contains the error messages for the Prior College Minor API.

gb_pcol_minor_dml

gokd_sorminr0.sql (package specification)gokd_sorminr1.sql (package body)

This DML package supports the Prior College Minor API.



Visa Code

gb_visa

gokb_visa0.sql (package specification)gokb_visa1.sql (package body)

This package contains the basic procedures and functions that allow users to query, insert, update, or delete data in the Visa Code (GORVISA) table.

gb_visa_rules

gokb_visa_r0.sql (package specification)gokb_visa_r1.sql (package body)

This package contains supporting rules for the Visa Code API for the Visa Code (GORVISA) table.

gb_visa_strings

gokb_visa_s0.sql (package specification)gokb_visa_s1.sql (package body)

The package contains the error messages for the Visa Code API.

gb_visa_dml

gokd_gorvisa0.sql (package specification)gokd_gorvisa1.sql (package body)

This DML package supports the Visa Code API.


Section 5 API Enhancement - Technical Changed Business Entity API

Changed Business Entity API

gb_address

The order of parameters passed to the user exit was corrected so that both p_create and p_update are the same. This may require clients with a local user exit package to adjust the order of parameters to match. Please carefully check the order of the parameters in your user exit procedure. This change corrects defect #CMS-DFCT104168.

Note: To correct a Banner Finance defect, the Finance Rules parameter was added to the p_validate call, and as a result, also to the user exit.

The client user exit procedure must have a signature similar to the following:

(p_pidm spraddr.spraddr_pidm%TYPE,p_atyp_code spraddr.spraddr_atyp_code%TYPE,p_seqno spraddr.spraddr_seqno%TYPE,p_from_date spraddr.spraddr_from_date%TYPE,p_to_date spraddr.spraddr_to_date%TYPE,p_street_line1 spraddr.spraddr_street_line1%TYPE,p_street_line2 spraddr.spraddr_street_line2%TYPE,p_street_line3 spraddr.spraddr_street_line3%TYPE,p_city spraddr.spraddr_city%TYPE,p_stat_code spraddr.spraddr_stat_code%TYPE,p_zip spraddr.spraddr_zip%TYPE,p_cnty_code spraddr.spraddr_cnty_code%TYPE,p_natn_code spraddr.spraddr_natn_code%TYPE,p_status_ind spraddr.spraddr_status_ind%TYPE,p_user spraddr.spraddr_user%TYPE,p_asrc_code spraddr.spraddr_asrc_code%TYPE,p_delivery_point spraddr.spraddr_delivery_point%TYPE,p_correction_digit spraddr.spraddr_correction_digit%TYPE,p_carrier_route spraddr.spraddr_carrier_route%TYPE,p_gst_tax_id spraddr.spraddr_gst_tax_id%TYPE,p_reviewed_ind spraddr.spraddr_reviewed_ind%TYPE,p_reviewed_user spraddr.spraddr_reviewed_user%TYPE,p_data_origin spraddr.spraddr_data_origin%TYPE ,p_finance_rules VARCHAR2,p_rowid spraddr.spraddr_seqno%TYPE DEFAULT NULL) IS ...


Section 5 API Enhancement - TechnicalNew Validation Packages

New Validation Packages

STVADMR Validation

gb_stvadmr

gvkb_stvadmr0.sql (package specification)gvkb_stvadmr1.sql (package body)

This API provides validation support for the STVADMR table.

STVHONR Validation

gb_stvhonr

gvkb_stvhonr0.sql (package specification)gvkb_stvhonr1.sql (package body)

This API provides validation support for the STVHONR table.

STVPENT Validation

gb_stvpent

gvkb_stvpent0.sql (package specification)gvkb_stvpent1.sql (package body)

This API provides validation support for the STVPENT table.

STVVTYP Validation

gb_stvvtyp

gvkb_stvvtyp0.sql (package specification)gvkb_stvvtyp1.sql (package body)

This API provides validation support for the STVVTYP table.


Section 5 API Enhancement - Technical New Tables

New Tables

Immunization Code Validation Table (GTVIMMU)

This tables stores immunization codes.


• gtvimmu1.sql--Creates the table.

• gtvimmu2.sql--Creates the primary key.

• gtvimmu3.sql--Creates the comments on columns.

Note: The API for this table will be delivered in a future release.


GTVIMMU_CODE VARCHAR2(10) N Immunization Code.

GTVIMMU_DESC VARCHAR2(30) N Immunization Description.

GTVIMMU_USER_ID VARCHAR2(30) N USER ID: User ID of the user who created or last updated the record.

GTVIMMU_ACTIVITY_DATE DATE N ACTIVITY DATE: Date the record was created or last updated.

GTVIMMU_DATA_ORIGIN VARCHAR(2)30 Y DATA ORIGIN: Source system that created or updated the row.


Section 5 API Enhancement - TechnicalNew Tables

Immunization Code Repeating Table (GORIMMU)

This table stores the immunization codes, dates, and comments by PIDM.


• gorimmu1.sql--Creates the table.

• gorimmu2.sql--Creates the primary key.

• gorimmu3.sql--Creates the constraints.

• gorimmu4.sql--Creates the comments on columns.

Note: The API for this table will be delivered in a future release.


GORIMMU_PIDM NUMBER(8) N PIDM: user value

GORIMMU_IMMU_CODE VARCHAR2(10) N Immunization Code

GORIMMU_IMMU_DATE DATE Y Date of immunization

GORIMMU_COMMENT VARCHAR2(4000) Y Immunization Comment

GORIMMU_USER_ID VARCHAR2(30) N USER ID: User ID of the user who created or last updated the record.

GORIMMU_ACTIVITY_DATE DATE N ACTIVITY DATE: Date the record was created or last updated.

GORIMMU_DATA_ORIGIN VARCHAR2(30) Y DATA ORIGIN: Source system that created or updated the row.


Section 5 API Enhancement - Technical Changed Tables

Changed Tables

Document Information Table (GORDOCM)

The primary key in this table was changed to PIDM, Sequence Number, Visa Type, and Document Code.

The Visa Number field was changed to allow a NULL value, so that you may enter data at a later time. Previously, it required a value.

The following scripts are used to make the changes to this table:

• gordocm1.sql--Drops the foreign key from the table.

• gordocm2.sql--Drops the existing primary key from the table.

• gordocm3.sql--Changes the visa_number column to allow NULL values.

• gordocm4.sql--Makes the primary key changes.

• gordocm5.sql--Recreates the foreign key.

Visa Code Table (GORVISA)

The primary key in this table was changed to PIDM, Sequence Number, and Visa Type.

The following fields were changed to allow NULL values, so that you may enter data at a later time. Previously, they required a value.

• Visa Number

• Issuing Nation

• Visa Issuing Authority Code

• Start Date

• Expiration Date

A Data Origin column was added to this table:


GORVISA_DATA_ORIGIN VARCHAR2(30) Y DATA ORIGIN: Source system that created or updated the row.


Section 5 API Enhancement - TechnicalChanged Tables


• gorvisa1.sql--Drops the existing primary key from the table.

• gorvisa2.sql--Changes the five columns to allow NULL values. Refer to previous page for list of columns.

• gorvisa3.sql--Makes the primary key changes.

• gorvisa4.sql--Adds the GORVISA_DATA_ORIGIN column.

• gorvisa5.sql--Creates the comment on the new GORVISA_DATA_ORIGIN column.

Person Medical Information Repeating Table (SPRMEDI)

The Medical Code column was expanded to 10 characters.

Additionally, the SPRMEDI_DISP_IND column was changed to be NOT NULL. Any existing NULL values were changed to N.

Two new columns was added to this table:

The following scripts make the changes to the SPRMEDI table, which supports this form:

• sprmedi1.sql--Adds the new medi_code_date column to SPRMEDI.

• sprmedi2.sql--Adds the comment on the new column.

• sprmedi3.sql--Expands the Medical Code field to 10 characters.

• sprmedi4.sql--Adds the Data Origin column.

• sprmedi5.sql--Updates the SPRMEDI_DISP_IND to N where it was NULL.

• sprmedi6.sql--Changes the SPRMEDI_DISP_IND column to be NOT NULL.

• sprmedi7.sql--Adds the comments on the new columns.


MEDI_CODE_DATE VARCHAR2(10) N Medical Code Date.

SPRMEDI_DATA_ORIGIN VARCHAR2(30) Y DATA ORIGIN: Source system that created or updated the row.


Section 5 API Enhancement - Technical Changed Tables

Prior College Concentration Table (SORCONC)

New columns were added to support the gb_pcol_concentration API.


• sorconc1.sql--Adds the new API columns.

• sorconc2.sql--Adds the comments on the API columns.

Prior College Degree Table (SORDEGR)

New columns were added to support the gb_pcol_degree API.


• sordegr1.sql--Adds the new API columns.

• sordegr2.sql--Adds the comments on the API columns.

Prior College Major Table (SORMAJR)

New columns were added to support the gb_pcol_major API.


• sormajr1.sql--Adds the new API columns.

• sormajr2.sql--Adds the comments on the API columns.

Prior College Minor Table (SORMINR)

New columns were added to support the gb_pcol_minor API.


• sorminr1.sql--Adds the new API columns.

• sorminr2.sql--Adds the comments on the API columns.

Prior College Table (SORPCOL)

New columns were added to support the gb_prior_college API.


• sorpcol1.sql--Adds the new API columns.

• sorpcol2.sql--Adds the comments on the API columns.


Section 5 API Enhancement - TechnicalNew JAR File

New JAR File

transporter.jar

This file supports the Banner Student 7.3 XML Transcript export process (shrpese.jar). The XML Transcript feature uses the FTP component located in transporter.jar to send files over the Internet to a remote server. For more information about transporter.jar, refer to the Batch Integration Framework SDK documentation.

New PLUS Scripts

Three new PLUS scripts were added to support the enhanced Visa Code functionality.

gselvisa.sql

This optional script is used to select any GTVSDAX records from GORVISA that are no longer used. If you are using this script, it must be run prior to the gupdvisa.sql and gdelsdaxvisa.sql scripts. The script will produce a report of GORVISA rows that contain the default values that were established in GTVSDAX. This report should be reviewed prior to running the update scripts: gupdvisa.sql and gdelsdaxvias.sql.

gupdvisa.sql

This optional script is used to update the GORVISA and GORDOCM tables by setting old default GTVSDAX international values to NULL. This script must be run after gselvisa.sql and before gdelsdaxvisa.sql.

gdelsdaxvisa.sql

This optional script is used to delete GTVSDAX international codes that are no longer used. This script must be run after gselvisa.sql and gupdvisa.sql.


Section 5 API Enhancement - Technical Changed PLUS Scripts

Changed PLUS Scripts

Two PLUS scripts were changed to support the enhanced Visa Code functionality.

gdelintl.sql

This script supports the implementation of Multivisa 5.5. It deletes rows from the international tables GOBINTL, GORVISA, and GORDOCM from SPRINTL. Comments were added to the audit trail related to the new Visa structure. This script must be run prior to the gselvisa.sql, gupdvisa.sql, and gdelsdaxvisa.sql scripts (described in New PLUS Scripts).

gupdintl.sql

Any GTVSDAX international default values were removed from this script because those values are no longer being used. If data has not yet been migrated from SPRINTL, this script should be run prior to the gselvisa.sql, gupdvisa.sql, and gdelsdaxvisa.sql scripts (described in New PLUS Scripts).

Changed Packages

Two packages were changed to support the enhanced Visa Code functionality.

gokintl.sqlgokint1.sql

All GORVISA functions and procedures that are now part of the Visa Code API (gb_visa) were removed from this package.

stksbgi.sql

Functions were added to this package to support messaging.


Section 6 Large Object Storage Enhancement - TechnicalOverview

Section 6 Large Object Storage Enhancement - Technical

Overview

This enhancement provides centralized Large Object (LOB) storage for Banner applications using a new table, GORBLOB, and a new API, gb_large_object. Large Object storage enables users to store files, such as Portable Document Format (PDF) documents, in the database.

In the current release, it is used by Accounts Receivable’s eBill functionality, as well as for the e~Print product. Refer to the Accounts Receivable release guide for information about using eBill, or to the e~Print documentation for information about using e~Print.

You may use the gb_large_object API for other purposes, but those uses are not currently supported by SunGard Higher Education. For institutions interested in building their own secured applications that handle Large Objects, SunGard Higher Education recommends reading Oracle Application Developer's Guide - Large Objects (LOBs) prior to working with the tables and APIs in this enhancement.

Note for RAC Users

The 7.3 release does not support files being displayed in a RAC (Real Application Clusters) environment from INB.

Considerations for Building Custom Applications

About Storing Internal LOBs

To use internal LOBs, you must create a separate tablespace for temporary LOB processing. SunGard Higher Education recommends that you make your temporary LOB tablespaces extendable. The General 7.3 installation has you create a Large Object tablespace named BANLOB, with Autoextend On by default. If you are not going to be loading statements into the database at this time, you can change the default 1000M allocation for this tablespace to a smaller number.


Section 6 Large Object Storage Enhancement - Technical Overview

About Storing BFILEs

While SunGard Higher Education supports both internal LOBs and BFILEs, it is strongly recommend that you store your data as internal LOBs. (For the eBill enhancement, you will make this decision when you store the Statement files.) There are many issues with storing files in the file system that should be understood before choosing the BFILE option.

Choosing Between Internal LOBs and BFILEs

Large object data can consume large amounts of disk space. The disk space will be used regardless of whether the LOB data is managed inside the database or outside on the file system. However, internal LOB storage provides many features such as:

• Transaction recovery--LOB data is committed and rolled back like any other data.

• Backup--LOB data is backed up and restored like any other data in the database.

• Security--Security is provided by the baseline Banner security rather than server file system security.

• Space management--The LOB data can be managed in a separate tablespace specifically allocated for this purpose.

BFILE storage is an option for clients who require the data to be stored outside the database, but who need to access it from within the database. The interface provided by the gb_large_object package makes the physical storage location of the data transparent to the application program.

If you choose to use BFILE storage, carefully consider these issues:

• FILE locators do not participate in database exports. In other words, only the locator is exported, not the data.

• The data in the file system is read-only, so BFILEs cannot be updated.

• When an application purges index data from its local table (i.e. TBBSTMT), rather than delete the corresponding GORBLOB row, it will flag that row for later deletion if the data is stored as BFILE. The file system file is not deleted. Only the GORBLOB record is flagged as deleted. The purging of the file system files is a system administration task. The system administrator will then have to use a script similar to the following script in order to identify and delete the file system file, and then go back and delete the GORBLOB rows.


Section 6 Large Object Storage Enhancement - TechnicalNew API

/*This is a sample script you might use if you are storing large objects as BFILES, and the application has flagged the GORBLOB record for deletion.

Once you run this and obtain the list of files no longer being referenced by the application, remove them from the file system, and then delete the gorblob rows.*/

set serveroutput onDECLARE

lv_file_name VARCHAR2(100);

BEGIN

FOR purged_bfiles in (

SELECT gorblob_media_id

FROM gorblob

WHERE gorblob_bfile IS NOT NULL

AND gorblob_deleted = 'Y') LOOP

lv_file_name:= gb_large_object.f_get_bfile_location(purged_bfiles.gorblob_media_id);

dbms_output.put_line( 'rm '||lv_file_name);

END LOOP;

end;

/

New API

Large Object

The Large Object API allows users to query, insert, update, or delete data in the Large Object (GORBLOB) table. It supports the tb_statement API that allows Banner Accounts Receivable users to store and retrieve billing statements. It also supports e~Print functionality.

Security Considerations

The Large Object API is not intended as a document management system and is not secured using Banner security. It does not have execute grants (except for EPRINT) or public synonyms. Therefore, access to it must be made through a separate secured application. In this release, those applications are Accounts Receivable eBill and e~Print. They gain access to gb_large_object in different ways.


Section 6 Large Object Storage Enhancement - Technical New API

eBill manages storage of Statement files and the link to the Large Object Media ID (gorblob_media_id) through the Statement Header Table (TBBSTMT) using the tb_statement API. Access to view the stored file is provided via a new Self-Service page with normal student validation, and from a new form TGISTMT secured by Internet-Native Banner controls. The form currently uses the GOKOUTP package to call gb_large_object to render the stored file, using DBMS_PIPES to secure the connection.

e~Print uses a separate secured server. When e~print is installed, a special user (EPRINT) is created, and an explicit grant is made on gb_large_object to the user EPRINT. This is the only explicit grant on the gb_large_object package, and only exists once e~Print is installed. Clients using e~Print are directed to the e~Print installation guide for details on setting up and securing the e~Print connection.

gb_large_object

gokb_large_object0.sql (package specification)gokb_large_object1.sql (package body)

This package contains the basic procedures and functions that allow users to query, insert, update, or delete data in the Large Object (GORBLOB) table.

gb_large_object_rules

gokb_large_object_r0.sql (package specification)gokb_large_object_r1.sql (package body)

This package contains supporting rules for the Large Object API for the Large Object (GORBLOB) table.

gb_large_object_strings

gokb_large_object_s0.sql (package specification) gokb_large_object_s1.sql (package body)

The package contains the error messages for the Large Object API.

dml_gorblob

gokd_gorblob0.sql (package specification)gokd_gorblob1.sql (package body)

This DML package supports the insert, update, and delete operations of the new Large Object API.


Section 6 Large Object Storage Enhancement - TechnicalNew Tables

New Tables

Central Storage for Binary Large Objects Table (GORBLOB)

The Large Object table stores files that are defined on GTVBLOT, such as PDF files. It can store files of many different types, which can then be downloaded to the end user via their browser.

This table was designed for use with the Banner Accounts Receivable tb_statement API that supports the new eBill functionality, which stores individual statement files in PDF or other appropriate format. The Media ID assigned when creating a record in GORBLOB is captured in the Statement Header Table (TBBSTMT) to provide the link for subsequent access to the file.

For details regarding the parameters handling file storage, refer to the API technical documentation of the Large Object API (gb_large_object).


GORBLOB_MEDIA_ID INTEGER N Media ID: Unique Generated ID number

GORBLOB_BLOT_CODE VARCHAR2(30) N BINARY LARGE OBJECT TYPE: Code that describes the contents of the BLOB.

GORBLOB_USER_ID VARCHAR2(30) N USER ID: User ID of the user who created or last updated the record.

GORBLOB_ACTIVITY_DATE DATE N ACTIVITY DATE: Date the record was created or last updated.


Section 6 Large Object Storage Enhancement - Technical New Tables

The following scripts create the GORBLOB table:

• gorblob1.sql--Creates GORBLOB table.

• gorblob2.sql--Creates GORBLOB primary key script.

• gorblob3.sql--Creates GORBLOB constraints.

• gorblob4.sql--Creates GORBLOB comments on table and columns.

Note: During the install process, you will have a opportunity to review and set the table sizing parameters as usual. In addition, you will be able to set the LOB storage tablespace name and LOB chunksize. For our testing, the default chunksize of 8,000 worked fine. If you have plans for using this table for other purposes, you are encouraged to read about chunksize in the Oracle Application Developer's Guide - Large Objects (LOBs) manual. Chunksize cannot be altered once the table is created.

GORBLOB_BLOB BLOB Y BINARY LARGE OBJECT: A reference pointer to the binary large object stored in the database.

GORBLOB_BFILE BFILE Y The bfile locator pointing to the file system file.

GORBLOB_DELETED VARCHAR2(1) Y DELETED: The record is flagged for deletion from the associated file system file. It may be deleted if this column has a value of Y. Once the file is deleted this row may be deleted from the GORBLOB table.

GORBLOB_DATA_ORIGIN VARCHAR2(30) Y DATA ORIGIN: Source system that created or updated the row.



Section 6 Large Object Storage Enhancement - TechnicalNew Tables

Large Object Validation Table (GTVBLOT)

This table stores the valid object types that may be used in the GORBLOB table.

The following scripts create the GTVBLOT table:

• gtvblot1.sql--GTVBLOT create table script.

• gtvblot2.sql--GTVBLOT primary key script.

• gtvblot3.sql--GTVBLOT comment on table and columns script.

The igtvblot73.sql script inserts SEED data into the GTVBLOT table. Refer to New Scripts in this section for the values.

ePrint Table (GORFILX)

The following scripts create the GORFILX table:

• gorfilx1.sql--Creates the table.

• gorfilx2.sql--Creates the primary key.

• gorfilx3.sql--Creates the comments on the table and columns.


GTVBLOT_CODE VARCHAR2(30) NOT NULL

Object code.

GTVBLOT_DESC VARCHAR2(30) NOT NULL

Object description.

GTVBLOT_MIME_TYPE VARCHAR2(100) NOT NULL

Mime type. Controls how files are displayed when they are called.

GTVBLOT_USER_ID VARCHAR2(30) NOT NULL

User ID

GTVBLOT_ACTIVITY_DATE DATE NOT NULL

Activity Date

GTVBLOT_DATA_ORIGIN VARCHAR2(30) NOT NULL

Data Origin


Section 6 Large Object Storage Enhancement - Technical New Packages

New Packages

gvkb_gtvblot0.sql (package specification)gvkb_gtvblot1.sql (package body)

This validation package supports the Large Object API.

gokeprt.sql (package specification)gokeprt1.sql (package body)

This API package contains procedures for e~Print to load Job Submission output files into the database for later retrieval.

Changed Package

gokoutp.sql (package specification)gokout1.sql (package body)

This package implements new functionality that allows files stored as Large Objects to be displayed in a browser using the appropriate mime type.

Note: The 7.3 release does not support the display of stored files in a RAC environment from the TGISTMT form, which uses this package.


Section 6 Large Object Storage Enhancement - TechnicalNew Scripts

New Scripts

igtvblot73.sql

This script inserts the following values as SEED data into the GTVBLOT table:

Note: Note that the GTVBLOT_MIME_TYPE is the exact text passed to the browser to define the content type. This tells the browser what program to use to display the content. If this text is incorrect, the browser may have trouble displaying that type of file.

gos_media_seq.sql

This script creates an Oracle sequence which is used to generate the media_id.

Large Object Storage Guidelines

The following information is provided to help you estimate how much space you might need to allocate for storage of billing statements and other documents in the GORBLOB table. The space required obviously will vary depending on the average size of your documents. The time estimates presented here are for just loading the files into the database, and do not include time preparing the files. Obviously these times will vary depending on your hardware.

We loaded 19,929 billing statement records through the eBill interface. A simple PL/Sql script loaded one of 10 sample statements from the file system for each pidm in our test SPRIDEN table. The statements were approximately 56k in size (ranging from 56,740 to 57,296 bytes), and were PDF files prepared by Evisions FormFusion which contained some graphics. Run time was approximately 80 minutes, about 250 documents per minute.

GTVBLOT_CODE GTVBLOT_DESC GTVBLOT_MIME_TYPE GTVBLOT_USER_ID GTVBLOT_ACTIVITY_DATE GTVBLOT_DATA_ORIGIN------------ ------------ --------------- --------------------- ------------- ------------------PDF Portable Document Format application/PDF GENERAL SYSDATE BannerDOC Microsoft Word Format application/msword GENERAL SYSDATE BannerGIF Graphic Interchange Format image/gif GENERAL SYSDATE BannerJPG JPEG Format image/jpeg GENERAL SYSDATE BannerLIS Plain Text Format text/plain GENERAL SYSDATE BannerTIF Tag Image File Format image/tiff GENERAL SYSDATE BannerTXT Plain Text Format text/plain GENERAL SYSDATE BannerXLS Microsoft Excel Format application/vnd.ms-excel GENERAL SYSDATE BannerWAV Waveform Audio Format audio/wav GENERAL SYSDATE Banner


Section 6 Large Object Storage Enhancement - Technical Large Object Storage Guidelines

Our average file size was about 56,901 bytes, so we accumulated about 5% overhead which includes the overhead in the tbbstmt table and index, and the gorblob table and index.

To estimate disk space requirements for storing LOBs internally, you might use a formula like this: ( Avg File Size * Avg Number of Statements per run * Number of statement run in history * 1.06) / 1073741824 (1 Gig) = number of Gigabytes of disk space used.

Segment Name Owner Segment Type Tablespace Bytes

GORBLOB GENERAL TABLE TS1 3,145,728

PK_GORBLOB GENERAL INDEX TS1 393,216

Total Gorblob 3,538,944

GORBLOB_BLOB_NDX GENERAL LOBINDEX TS2 65,536

GORBLOB_BLOB_STORAGE GENERAL LOBSEGMENT TS2 1,184,890,880

Total LOB Storage 1,184,956,416

PK_TBBSTMT TAISMGR INDEX TS1 393,216

TBBSTMT TAISMGR TABLE TS1 2,097,152

Total TBBSTMT 2,490,368

Grand Total 1,190,985,728


Section 6 Large Object Storage Enhancement - TechnicalTechnical Note

Technical Note

Initial testing of the Oracle package WPG_DOCLOAD, which is used to display the files that have been stored caused the browser to simply hang. Subsequently, it was discovered that there were two versions of the WPG_DOCLOAD package in our environment. Apparently, when Oracle moved the Web packages from the OAS schema to SYS, they failed to drop the old package, thus leaving two of them in the system. Therefore, before you proceed, use the following select statement to check your system and make sure there are no extra copies of WPG_DOCLOAD. Note in the results below that only SYS owns this package. Any others should be dropped.

select owner, object_name, object_typefrom dba_objectswhere object_name = 'WPG_DOCLOAD'

OWNER OBJECT_NAME OBJECT_TYPE------------------- --------------------- -------------SYS WPG_DOCLOAD PACKAGESYS WPG_DOCLOAD PACKAGE BODYPUBLIC WPG_DOCLOAD SYNONYM


Section 6 Large Object Storage Enhancement - Technical Technical Note



Section 7 Oracle*Reports Changes - TechnicalChanged Form

Section 7 Oracle*Reports Changes - Technical

Several changes were made to enhance the security of Oracle Reports output. The changes made to enhance security when the Destination Type parameter is set to File correct defect #CMS-DFCT105960. The changes made because Destination Name field must be null if the Destination Type is set to Cache are the result of miscellaneous modifications.

Changed Form

General User Preferences Maintenance Form (GUAUPRF)

A record was added to the Directory Options tab that allows you to control the file name format and location of Oracle Reports output. With this record, you can control where users send their report output when the report Destination Type is set to File (DESTYPE=FILE).

If you change nothing on the BASELINE row (i.e., where GURUPRF_USER_ID is equal to BASELINE), then the value DEFAULT_BEHAVIOR is used, and users send their output to the drive/folder/subfolder specified in the Destination Name field or to the default directory on the Reports server, if Destination Name is valued with only a file name. This is the same way this feature worked in previous releases. However, you have the option to enter the name of and Oracle Reports root-level folder/subfolder value (including an ending slash).

To this root-level folder/subfolder value, you have the option to append:

• An indication for including a timestamp in the report file name (date)

• An indication for having the report file written to an oracle-username-subfolder (user)

• Indications for both timestamp and username subfolder (user,date)

Note: If your institution chooses not to append the string date to the report file name, then you must otherwise ensure that duplicate file names are not overwritten.

Note: If you use any of the new options, keep in mind that the methods you use to periodically purge the output on your Reports server may need to be adjusted. Also, when running the reports, users will enter just the file name (and extension) in the Destination Name field. The configured options will be dynamically constructed into this entered Destination Name value.


Section 7 Oracle*Reports Changes - Technical Changed Form

The delivered value for BASELINE is DEFAULT_BEHAVIOR. You may change this value to one of the following options:

• A root-level folder (including an ending slash) to which all Oracle Reports output with a Destination Type of File will be sent. This root-level folder must exist and be writable by the Reports server.

Example of the BASELINE row configuration

Windows:f:\orep_root\

Unix/Linux:/u02/orep_root/

Example of what output might look like with this BASELINE row configuration

Windows:f:\orep_root\sample_report.pdf

Unix/Linux:/u02/orep_root/sample_report.pdf

Note: If you choose this option, make sure that all Oracle Reports users are configured to access files at this root location, and that the Windows share (or Unix security) is configured accordingly. Users need read access to this folder. Additionally, make sure that they do not send report output with sensitive data to this folder.

If a value exists in the User Value field for this corresponding type of BASELINE row, it will be ignored.

• A root-level folder and the string user . If desired, users may specify subfolders within their username folder by entering the name of the subfolder in the corresponding User Value field of GUAUPRF (including an ending slash). This specified subfolder must exist.


Windows:f:\orep_root\user

Unix/Linux:/u02/orep_root/user


Windows:f:\orep_root\jdoe\sample_report.pdf

Unix/Linux:/u02/orep_root/jdoesample_report.pdf


Section 7 Oracle*Reports Changes - TechnicalChanged Form

Example of what output might look like if a User Value subfolder of xyz\ (for Windows) or xyz/ (for Unix) is specified on the users GUAUPRF row

Windows:f:\orep_root\jdoe\xyz\sample_report.pdf

Unix/Linux:/u02/orep_root/jdoe/xyz/sample_report.pdf

Note: You must create user folders for Oracle user IDs, if you choose this option. If you do not, the Reports server will not be able to write the file to the specified location. It is recommended that you create Windows share (or Unix security) on these user folders.

• A root-level folder and the string date. If you choose this option, then a unique time stamp will be appended to the end of the report name, so that files will not be overwritten.


Windows:f:\orep_root\date

Unix/Linux:/u02/orep_root/date


Windows:f:\orep_root\sample_report20061212081255.pdf

Unix/Linux:/u02/orep_root/sample_report20061212081255.pdf

• A root-level folder and the strings user,date.


Windows:f:\orep_root\user,date

Unix/Linux:/u02/orep_root/user,date


Windows:f:\orep_root\jdoe\sample_report20061212081255.pdf

Unix/Linux:/u02/orep_root/jdoe/sample_report20061212081255.pdf

Note: You must create user folders for Oracle user IDs if you choose this option. If you do not, the Reports server will not be able to write the file to the specified location. It is recommended that you create Windows share (or Unix security) on these user folders.


Section 7 Oracle*Reports Changes - Technical Changed Table

Changed Table

User Preference Table (GURUPRF)

A new row was added to this table which allows you to customize the way Oracle Reports are named and stored on the Reports server. Refer to the changes to GUAUPRF for more information.

Changed Libraries

General PL/SQL Oracle*Reports Library (goqorep.pll)

The G$_BANNER_REPORT_EDITING.EDIT_OREP_ROW package was changed so that you cannot choose a value for the Destination Name parameter if you choose a Destination Type of Cache. The Destination Name field must be null.

Report Form Object Library (goqrlib.fmb)

This library was changed so that you can only use a Destination Type of Cache if you also choose an Execution Mode of Runtime and a Communication Mode of Synchronous. These changes are contained in the WHEN-LIST-CHANGED trigger of the G$_BANNER_REPORT_BLOCK.OREP_DESTYPE package.

Additionally, the Required indicator was set to Yes for the G$_BANNER_REPORT_BLOCK.OREP_PARAMFORM_DESIGNATION package.

When you choose a Destination Type of Cache, the Parameter Form is automatically populated with an Execution Mode of Runtime, a Communication Mode of Synchronous, and a Parameter Form value of Yes by default. When you choose a Destination Type of File, Printer, or Mail, the Parameter Form is automatically populated with an Execution Mode of Batch, a Communication Mode of Asynchronous, and a Parameter Form value of No by default.

Note: The following forms must be regenerated in order to use the GOQRLIB modifications:

Finance

• Standard 1034 Billing Form (FRR134B)

• Standard 269 Report Form (FRR269R)


Section 7 Oracle*Reports Changes - TechnicalNew Script



• Standard 272 Report Form (FRR272R)

• Canadian Standard Report Form (FRRCNSF)

• Generic Bill Form (FRRGENB)

• Generic Report Form (FRRGENR)

Accounts Receivable

• Detail Code Control Form - Finance Form (TFADETC)

• Detail Code Control Form - Student Form (TSADETC)

• Detail Category Code Validation Form (TTVDCAT)

New Script

iguruprf73.sql

This script inserts a new row into the GURUPRF table so that you can control the behavior of report output when the report Destination Type is set to File (DESTYPE=FILE). The delivered value is a BASELINE user row with a value of DEFAULT_BEHAVIOR. This row controls the Runtime behavior of the BASELINE Oracle*Reports. The DEFAULT_BEHAVIOR value provides behavior equivalent to previous releases.

Changed RDF Files

Changes were made to the following BASELINE Oracle Report RDF Files. These changes were made after all 7.0 and 7.1 changes to Oracle Reports RDF Files were made. You need to make these changes to custom Oracle Reports at your site.

• FRR134B - Standard 1034 Billing Form

• FRR269R - Standard 269 Report Form



• FRR272R - Standard 272 Report Form

• FRRCNSF - Canadian Standard Report Form

• FRRGENB - Generic Bill Form


Section 7 Oracle*Reports Changes - Technical Changed RDF Files

• FRRGENR - Generic Report Form

• SARETBL - Electronic Application Report

• TGRDETC - Detail Code Report

Description of Changes

Before opening the equivalent to the BASELINE 7.1 version of the RDF file for modification, be sure that your REPORTS_PATH can see the 7.3 version of goqorel.pll.

1. Open the equivalent to BASELINE 7.1 version of the RDF file for modification using Reports*Builder10g.

2. Under the Data Model, add these two new User Parameters:

• P_VPDI_HOME_CODE Datatype = Character Width = 6

• P_VPDI_PROCESS_CODE Datatype = Character Width = 6

3. Modify the Before Parameter Form (BEFOREPFORM) trigger to include a call to (GOQOREP.pll).G$_REPORT_VPDI.SET_VPDI.

Snippet of code from BEFOREPFORM showing line to add:

.

.

.

---- Exception pragmas.--

PRAGMA EXCEPTION_INIT(NO_OBJECT,-20100);PRAGMA EXCEPTION_INIT(NO_INST,-20101);PRAGMA EXCEPTION_INIT(NO_ACCESS,-20102);PRAGMA EXCEPTION_INIT(NO_PASSWORD,-20103);PRAGMA EXCEPTION_INIT(INVALID_VERSION,-20104);PRAGMA EXCEPTION_INIT(INVALID_ACCESS,-20105);PRAGMA EXCEPTION_INIT(NAME_MISMATCH,-20106);

--BEGIN-- Set VPDI

G$_REPORT_VPDI.SET_VPDI( :P_VPDI_HOME_CODE, :P_VPDI_PROCESS_CODE ); <---ADD

---- -- Start Security CheckG$_REPORT_SECURITY.G$_REPORT_VERIFY_ACCESS( 'TGRDETC', '7.3' ) ;-- -- End Security Check--

.

.

.


Section 7 Oracle*Reports Changes - TechnicalChanged RDF Files

4. Modify the After Parameter Form (AFTERPFORM) trigger to validate the Destination Name field if the Destination Type is FILE.

Snippet of code from AFTERPFORM showing lines to add:

function AfterPForm return boolean is

--lv_uprf_orep_root_dir VARCHAR2(500); <---ADDlv_valid VARCHAR2(2); <---ADD--BEGINIF UPPER(:DESTYPE) = 'FILE' THEN <---ADDlv_uprf_orep_root_dir := G$_OREP_GET_UPRF_ROOT_FILE('BASELINE'); <---ADD--IF UPPER(lv_uprf_orep_root_dir) <> 'DEFAULT_BEHAVIOR' THEN <---ADDlv_valid := G$_OREP_IS_ROOT_DIR_VALID(:DESNAME); <---ADD--IF lv_valid = '01' THEN <---ADDSRW.MESSAGE(1000,'*ERROR* DESTYPE=FILE. DESNAME compromises specified configuration. Run will Terminate.'); <---ADDRETURN(FALSE); <---ADD--ELSIF lv_valid = '02' THEN <---ADDSRW.MESSAGE(1000,'*ERROR* DESTYPE=FILE. DESNAME should not specify drive. Run will Terminate.'); <---ADDRETURN(FALSE); <---ADD--ELSE <---ADD-- lv_valid is '00' <---ADDNULL; <---ADDEND IF; <---ADDEND IF; <---ADDEND IF; <---ADD--

.

.

.

5. Create an appropriate entry for the audit trail, save the RDF file, and convert it to a REP file.


Section 7 Oracle*Reports Changes - Technical Changed RDF Files



Section 8 Security Enhancement - TechnicalChanged Form

Section 8 Security Enhancement - Technical

Several components of Banner security were enhanced. Numerous Distributed Security scripts were updated so that it is now easier for the security manager at your institution to allow other groups or individuals to perform security duties for their organization. Prompts in the scripts were made clearer, and many commands in the scripts were reorganized for ease of use.

Distributed Security is a feature that reduces the amount of maintenance that can only be performed by the main Banner security manager. Refer to the Banner Security Technical Reference Manual for details.

Changed Form

Oracle/Banner Security Maintenance Form (GSASECR)

The following improvements were made to this form:

• The CREATE_NEW_USER_PREP and ALTER_USER_PREP routines were changed to disable or enable the LOCK, UNLOCK, and EXPIRE buttons, since these buttons are not valid until a user exists.

• The order of the tab canvases was changed so that the Institution Profile tab now appears last, in response to concerns about having it display the SEED numbers on the first screen. This change satisfies RPE #CMS-RPE47666.

• You can now create user names longer than 19 characters.

• Three additional globals were created in the PRE-FORM trigger to support distributed security users who run the form directly and then attempt to perform calls to other forms.

• The SET ROLE command was moved to a stand-alone routine. The CHECK_TYPE trigger in the G$_NAV_BLOCK now calls the SET ROLE routine in order to re-establish the role being used by the user. Previously, the role setting was not being re-established if attempting to call another form via the F5 function. Logic was added to the PRE-FORM trigger to disable menu items when the form is running in stand alone-mode.

• The user default role record group was updated to include user-defined default roles. Previously, the logic only allowed BAN_DEFAULT% roles to be displayed. Logic was added to support the USR_DEFAULT% roles.


Section 8 Security Enhancement - Technical Changed Scripts

Changed Scripts

Security scripts were changed to make them easier to use and to no longer display your passwords on the screen while you are entering them.

gsposec.sql

The following changes were made to this script:

• The logic that is applied for the object security predicate was changed for improved performance.

• SQL*Plus was removed from the list of excluded objects.

gssacct.sql


• Processing logic was changed so that you are now prompted for the system password without it being displayed on the screen.

• Unneeded variables were removed.

• Prompt and variable names were updated to be more descriptive.

• Logic was changed to prompt for the BANSECR password, so that the BANSECR user creates the user and role, and performs most of the other activities. Connecting as the SYSTEM user is now used only to grant the system privilege.

gssbasg.sql


• The BANINST1 execute grants were moved from this script to the gsssysg.sql script, because permission should only be granted to the role, not the user. The BANINST1 connection was removed since it was no longer needed.


• Several new grants were added.


Section 8 Security Enhancement - TechnicalChanged Scripts

gssclsm.sql


• The CONNECT commands were changed so that a prompt now appears for the user, and when you enter the password, it does not appear on the screen.


• Insert/update privileges on GURUCLS were added to the role, rather than the individual user.

• An UNDEFINE command was added to the variable so that the value is not carried forward to another script after the first one is run.

gssobjm.sql






gssprfm.sql






gsspriv.sql

Prompt and variable names were updated to be more descriptive.



gssrolc.sql






• Privileges were added to allow this user to grant execute privileges on procedures that are owned by users other than BANINST1.

gssrold.sql




• A new GUBROLE grant was added to support the ability to delete roles.

• An update was added on the GURUOBJ table.


gssrolm.sql




• A grant was added to this script to execute baninst1_sql_pkg.




gsssels.sql





gsssysg.sql


• New grants that were needed for previous releases were added. Previously, the script had not been updated correctly.



• The GRANT ALTER USER grant was removed since it only belongs in the script needed for user maintenance (gssusra.sql).

gsssysp.sql





gssusra.sql







gssusrc.sql





• A GRANT ANY PRIVILEGE grant was added, so that when creating a new user by duplicating another user, this user will be able to duplicate the privileges. The create any, execute any, and drop any procedures were also added, since the user being created by duplicating another user may have direct grants from other users.

gssusrd.sql





gssusrm.sql





• The ALTER USER grant was removed from this script, because it is now issued in the alter and create user scripts. It is not needed for the drop user script.



gssviol.sql






Section 9 WebUtil Enhancement - TechnicalChanged Scripts

Section 9 WebUtil Enhancement - Technical

WebUtil is an Oracle utility, portions of which SunGard Higher Education has made available in the 7.3 General release to assist in file transfer. If configured, WebUtil provides a way to extract data from Banner to a user’s desktop, whether by using Banner’s data extract feature, the GASB Parameter Form (FGAGASB), or the Saved Output Review Form (GJIREVO). Although it was primarily intended to provide a data extract solution for institutions with a RAC (Real Application Clusters) environment, SunGard Higher Education recommends that all institutions adopt this solution.

With WebUtil, end users will not notice a significant change to the way in which they save their extracted data. A new form, the General WebUtil File Extract Form (GUQWUTL), will appear on their screen when they choose to extract data, and from there, they are prompted to save their file. If desired, they can specify a local directory to save their output by entering the path in the User Value field for the Local directory for saving output record on GUAUPRF. By default, the local directory is the directory specified in the Default Value field for that record.

Behind the scenes, however, a row in the General User Preference Table (GURUPRF) determines whether to launch the WebUtil option, and subsequently, the General WebUtil File Extract Form (GUQWUTL).

Before an institution can use WebUtil, several configuration steps are necessary. Refer to the Middle Tier Implementation Guide for information about downloading and configuring the various components necessary to implement WebUtil.

The Banner Getting Started Guide contains end-user information about using the data extract feature. The Banner Finance User Guide contains information about the GASB Parameter Form (FGAGASB). The Saved Output Review Form (GJIREVO) is described in the Banner General User Guide.


Section 9 WebUtil Enhancement - Technical New Form

New Form

General WebUtil File Extract Form (GUQWUTL)

This form appears when you select the option to extract data in a WebUtil-enabled Banner session. It displays a message about whether the data were extracted successfully, and enables you to save the output to a file on your local machine by using the Save File button.

Note: If your system administrator has not configured WebUtil at your institution, and you change the GUAUPRF record for Data Extract Format to WEBUTIL, then you will receive an error if you try to extract data to a file using GUQWUTL.

Note: There is a known issue when saving the file on a Macintosh workstation. The file does not target the local directory (and subdirectory, if specified), when given proper syntax. The file does transfer properly and completely; however, the file transfers to the top-level directory of the Macintosh hard drive, and has somewhat cryptic file name. The user may need to manually rename and move the file on the Macintosh workstation.

Changed Forms


Two changes were made to support the WebUtil option.

Directory Options Tab

• An previously-suppressed record was reintroduced to enable end users to specify their own default local directory. The row has these column values: GURUPRF_GROUP=DATA_EXTRACT, GURUPRF_KEY=WIN32COMMON, and GURUPRF_STRING=DIRECTORY.

• The WEBUTIL option was added to the record for Data Extract Format. This change is part of the WHEN-VALIDATE-ITEM trigger on the GURUPRF_DIR.GURUPRF_VALUE item. The change was also made to the PRE-UPDATE trigger in the GURUPRF_DIR block.


Section 9 WebUtil Enhancement - TechnicalChanged Library

Saved Output Review Form (GJIREVO)

The SAVE_AND_PRINT trigger was changed to include the WebUtil option.

Additionally, the list of values on this form was enlarged to be easier to read.

GASB Parameter Form (FGAGASB)

The PRINT_TO_WEB trigger was changed to include the WebUtil option.

Changed Library


The WebUtil option was added to the G$_DATA_EXTRACT routine.

New JAR File

banwebutl.jar

This .jar file supports the WebUtil functionality. For configuration information, refer to the Middle Tier Implementation Guide. This file is a re-named version of Oracle’s frmwebutil.jar file.


Section 9 WebUtil Enhancement - Technical New Package

New Package

gokwutl.sqlgokwut1.sql

This Oracle database package supports the WebUtil functionality. It was modified for BANINST1 privileges. This package is a re-named version of Oracle’s WebUtil package.


Section 10 Internationalization Changes - TechnicalChanged Forms

Section 10 Internationalization Changes - Technical

Changes were made to several Banner General objects in order to comply with Internationalization (I18N) standards. These changes support future Internationalization functionality.

Changed Forms

Function Affiliation Form (GEAFUNC)

References in the code to days of the week were changed from the English word (Monday, for example) to g$_date.nls_*, where the asterisk (*) is the abbreviation for the specific day (for example, g$_date.nls_mon).


Timestamp references in the code were changed in order to comply with I18N standards.

Missing G$_NLS calls were added to the LAUNCH_FORM_LOGIC procedure.

Oracle/Banner Security Maintenance Form (GSASECR)

Calls to the G$_NLS procedure were added to all message commands in support of Internationalization.


Section 10 Internationalization Changes - Technical Changed Libraries

Changed Libraries


The initialization logic was moved from the main begin-end statement of GOQRPLS.G$_FORMS_NLS to the correct location in GUAINIT’s when-new-form-instance trigger.


Section 11 Miscellaneous EnhancementsRebranding Changes

Section 11 Miscellaneous Enhancements

This section describes small changes that were made to Banner General that are not part of a larger functional or technical enhancement.

Rebranding Changes

Numerous objects were changed to reflect the new SunGard Higher Education branding.

• Form Object Library (goqolib.fmb)--References to prior product names were updated. This library was also changed for Multi-Institution Functionality (MIF).

• Help Form (GUAHELP)--The label for the Banner radio button was changed.

• About Banner Form (GUAABOT)--Banner product name was updated.

• General Menu Form (GUAGMNU)--Images and product name were updated.

• Banner Global Initialization Form (GUAINIT)--Images and product name were updated.

• Banner Error and Warning Messages Form (GUAERRM)--The window title was changed.

• gummappl.mmb--The names on various menu items and icons were updated.

The following images were updated:

• banicons.gif

• banner.gif

• my_institution.gif

• sct_about.gif


Section 11 Miscellaneous Enhancements Banner/fsaATLAS Integration Changes

Banner/fsaATLAS Integration Changes

A new Process Level API supports the retrieval of international student data from Banner to import to fsaATLAS. The new process level API provides seamless integration between Banner and fsaATLAS.

About APIs

A Business Process API executes a business process, spanning calls to multiple Banner Entity APIs in the context of a single transaction. It may expose one or more interfaces for different purposes: An XML interface to support integrations such as Web Services; an Oracle Object Type (OOT) interface to support simple handling of complex types; or a simple type interface to support legacy applications that cannot immediately take advantage of OOTs or XML.

New Business Process API

gp_international_student

gokp_internatl_stud0.sql package specification andgokp_internalt_stud1.sql package body

This Process Level API works in conjunction with Banner Population Selection to retrieve international student data for individuals defined by the institution. The API may be executed to retrieve new records for fsaATLAS from Banner, or to update existing fsaATLAS records. Data will be returned to fsaATLAS in XML format. Refer to the fsaATLAS Technical Guide for information about the processing procedures for this API specific to fsaATLAS.

For additional information, refer to the API technical documentation available via the Customer Support Center.

Note: When it is available, you can also refer to the message schema documentation provided for each integration solution.


Section 11 Miscellaneous EnhancementsBanner/fsaATLAS Integration Changes

New XML Schema

international_student.xsd

This file is the XML schema document for the fsaATLAS XML document. The gp_international_student Business Process API uses this schema to build the Oracle Object Types and to populate the elements.

Note: XML schemas must be registered in Oracle using the dbms_schema.registerschema function prior to compiling Process API packages. The registration process creates the predefined Oracle Object Types.

This file is located in the General production subdirectory xsd.

Oracle Object Types

The XSD registration process creates the following predefined Oracle Object Types in the Oracle database:

• FSAATLAS_RESPONSE_DATA

• FSA_STUDENT_INFO

• FSA_STUD_BIO

• FSA_BIRTH_COUNTRY_NT

• FSA_BIRTH_COUNTRY_CODE

• FSA_STUD_PROFILE

• FSA_UNITED_STATES_ADDRESS

• FSA_FOREIGN_ADDRESS

• FSA_MAILING_ADDRESS


Section 11 Miscellaneous Enhancements Miscellaneous New Form

Miscellaneous New Form

Business Rule Inquiry Form (GOIRSQL)

Use this form to query existing business rules by process code, rule code, or both. This form appears on the Business Rule Builder Menu (*GENBUSINESSRULE).

. . . . . . . . . . . . . . Fields

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Descriptions

Process Process code. The process code you entered on GORRSQL appears in this field if you accessed GOIRSQL from GORRSQL.

Rule Rule code. The rule code you entered on GORRSQL appears in this field if you accessed GOIRSQL from GORRSQL.

Process Process code.

Rule Rule code.

Sequence Sequence Number.

Start Date Start date of the process code.

End Date End date of the process code.

Active Check box that indicates whether the process code is active or inactive.

Validated Check box that indicates whether the process code is validated.

System Required Check box that indicates whether the process code is system-required.

User ID User ID that created or last modified the record.



Section 11 Miscellaneous EnhancementsMiscellaneous Changed Forms

Miscellaneous Changed Forms

General Menu Form (GUAGMNU)

This form was changed so that the My Link to the Banner Change Password Form (GUAPSWD) does not appear for users who are not authorized to use the GUAPSWD. This change satisfies RPE #CMS-RPE46826.

Additionally, the following changes were made:

• The new GET_CANVAS_COLORS routine loads the different values for the menu canvas colors into globals. The SET_CANVAS_COLORS routine was changed to use the new globals. The PRE-FORM trigger was changed to call the GET_CANVAS_COLORS routine before calling SET_CANVAS_COLORS. CALL_ROUTINE was changed to call the SET_CANVAS_COLORS routine, so that if the user changed any of the canvas colors on GUAUPRF, the change would appear.

• Performance-gathering calls were removed from the DBMS_UTILITY package.

• The autohint for the Go item was updated to be consistent with the F5 navigation item.

• The DO_FORM_CALL was changed to populate several globals which were being set either in the GUAINIT form or as part of the G$_SECURED_FORM_CALL. This improves startup time and form navigation.

• Several of the large IF-ELSE-THEN commands were rewritten with CASE commands for improved performance.

• The check mark message image now always appears if there are pending messages, and not just the first time the menu is accessed.

• Unused code was removed.

• Some of the large IF commands in the CHECK_TYPE trigger were replaced with a CASE command, as was the KEY-NEXT-ITEM trigger on the NEXT_SELECTION item. CASE commands are more efficient than large IF commands.

Data Display Mask Columns Form (GORDMCL)

The Data Type field (GORDMCL.GORDMCL_DATA_TYPE_CODE) and the Length field (GORCDMCL.GORDMCL_DATA_LENGTH) were changed to auto-populate from the Item (GORDMCL.GORDMCL_COLUMN_NAME) LOV trigger SHOW_CLMN_LOV.

Additionally, Tooltip text and AutoHint text for the System Required check box were changed to explain that checking the box can only be reset by using SQL.

These changes satisfy RPE #49001.


Section 11 Miscellaneous Enhancements Miscellaneous Changed Forms

Banner Error and Warning Messages Form (GUAERRM)

The form and window titles were changed to Banner Error and Warning Messages instead of simply Error Messages.

A missing implementation class attribute was added to the Close button.

The DISPLAY_MSG item and the ERR_MSG parameter were changed to have a maximum length of 4,000 characters, to match the maximum API error message length. A new scroll bar was added to accommodate longer messages.

Various form-level navigation triggers were updated so they do not appear when a user performs a Show Keys function. The canvas and window were enlarged so that it is easier to read the messages.


Two new fields were added:

Additionally, the following changes were made:

• An IF test was added to the exit logic if the NAME_IN(:SYSTEM.TRIGGER_ITEM) is NULL. Previously, the SET_VA_PROPERTY failed if the third parameter was NULL with iDS/AS10g Release2 (10.1.2.0.2).

• The PRE_FORM_TRG trigger logic was changed to check whether the user is running with a query-only role, and if so, Banner does not attempt to create any missing user preference records.

• The tab navigation logic was changed to test if any of the check boxes have been changed, and to warn the user about pending changes.

• The block-level trigger GURUPRF_UI.APPLY_COLOR was changed.

. . . . . . . . . . . . . . Fields

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Descriptions

Display Duplicate SSN/SIN/TIN Warning

This check box specifies whether a warning message will appear if a user tries to create a new ID in Banner with a SSN/SIN/TIN that is already being used.

By checking this box, a pop-up error message window will be displayed for any duplicate SSNs when a user is creating a new ID.

Include Header Row in Data Extract

This check box enables users to specify whether they want to always have a column heading on their data extract file. By checking this box, column headings will always be added to their extract file.


Section 11 Miscellaneous EnhancementsMiscellaneous Changed Forms

Business Rules Form (GORRSQL)

A Copy To block was added to this form to enable users to create and modify business rules more easily.

Oracle/Banner VPD Security Maintenance Form (GSAVPDI)

The PRE-FORM trigger was updated to dynamically call the dbms_application_info package to set the information about the current module and role. The values set are used by the PRE-COMMIT logic to determine whether updates are allowed or not. The PRE-FORM trigger was changed to remove the call to the DBMS_SESSION package and replace it with a call to G$_TRACE_PKG.DO_EXEC_SQL. Logic was added to the PRE-FORM trigger to create a global.nls_date_format if it does not already exist for when the form is run standalone.

Three new globals were added to the PRE-FORM trigger to support the distributed security users running the form directly and then attempting to perform calls to other forms. The SET ROLE command was moved to a standalone routine. The CHECK_TYPE trigger in the G$_NAV_BLOCK was changed to call the SET ROLE routine to re-establish the role being used by the user. Previously, the role setting was not being re-established if attempting to call another form via the F5 function. The logic which was disabling the menu items was moved from the PRE-FORM trigger to the WHEN-NEW-FORM-INSTANCE trigger. There were routines being called from the WHEN-NEW-FORM-INSTANCE trigger that were resetting the disabled items.

Initialization of the GLOBAL.INSTITUTION_CODE and GLOBAL.DEFAULT_INSTITUTION_CODE was added in the PRE-FORM trigger to support the MIF enhancements. The local version of gtvvpdi_lov and gtvvpdi_rg were removed and placed in a subclass in GOQOLIB.

The PRE-FORM trigger was changed to verify that the user has access to the tables in either of the blocks. If the user does not have access, then an error message appears and the form closes. Logic was added to disable either of the tabs if the user does not have access to the respective table. The ON-ERROR logic was updated to test if the user attempted to provide a user/password via the URL but the logon failed.

Workflow globals were added to support running the form in standalone mode.

Business Rule Code Validation Form (GTVSQRU)

The stacked canvas and corresponding references were removed from this form, and the layout of the form was standardized.


Section 11 Miscellaneous Enhancements Miscellaneous New Table


Logic was changed in this form so that command line and URL parameters are passed correctly to GUQSETI. Previously, the TIMING parameter was not being passed to GUAINIT when the user exited the GUQSETI form after logging in to Banner. Additionally, an error appeared when a user requested a valid object type (other than a form) when the KEEP_ALIVE parameter was set to Yes.

Set Institution Code Form (GUQSETI)

Logic in this form was changed so that the TIMING parameter in GUAINIT works correctly when a user exits from GUQSETI after login.

Crosswalk Validation Form (GTVSDAX)

The letters Y and Z are now being reserved as the first-position letters for the GTVSDAX_INTERNAL_CODE column for client-created GTVSDAX rows (for example, ZORTASM). Sungard Higher Education will not use these particular letters in baseline GTVSDAX rows, so that clients’ data will not be overwritten by future deliverables.

Miscellaneous New Table

Campus Card Holder XML Table (GURCARD)

This table was added to decrease the execution time of the GetEligibleCardholders Web service that is available with the Integration for Campus Card integration solution. It stores the ShowEligibleCardHolders XML documents that are produced by the GetEligibleCardHolders API, which is now invoked by a server process on a scheduled time interval.


GURCARD_ROLE VARCHAR2(200) N CAMPUS CARD HOLDER ROLE: Campus Card Holder role name.


Section 11 Miscellaneous EnhancementsMiscellaneous New API

The following scripts create the GURCARD table:

• gurcard1.sql--Creates the table.

• gurcard2.sql--Creates the primary key constraint.

• gurcard3.sql--Creates the comments on table and columns.

Miscellaneous New API

gokcard.sql gokcard1.sql

This API package was added to enable the retrieval of ShowEligibleCardholders XML documents from the new GURCARD table. The API is now used by the GetEligibleCardholders Web service when it is invoked to retrieve the appropriate XML document to provide as a response to the service request. As a result, execution time of the Web service was improved.

GURCARD_XML GENERAL.XMLTYPE

N CAMPUS CARD HOLDER XML: Campus Card Holder XML document.

GURCARD_USER_ID VARCHAR2(30) N USER ID: User ID of the User who created or last updated the record.

GURCARD_ACTIVITY_DATE DATE N ACTIVITY DATE: Date the record was created or last updated.

GURCARD_DATA_ORIGIN VARCHAR2(30) Y DATA ORIGIN: Source system that created or updated the row.



Section 11 Miscellaneous Enhancements Miscellaneous Changed Menu

Miscellaneous Changed Menu

gumappl.mmb

The direct access menu entry was changed to launch the F5 navigation.

New entries were added for FIRST_ROWS_1, FIRST_ROWS_10, and FIRST_ROWS_100 optimizer options to the HELP.TECHNICAL menu. These entries each call the G$_TRACE_PKG.SET_OPTIMIZER_FIRST_ROWS procedure and pass in the respective number. The menu start calls were updated to enable or disable these new menu entries just like the other optimizer options that already exist.

The logic which invokes the calendar, calculator, and About Banner calls was changed to perform the revoke access logic prior to calling the forms. These calls were missing the correct security-revoking logic.

Miscellaneous Changed Packages

gokdbms.sqlgokdbm1.sql

An additional parameter was added to this package.

gokpar1.sql

Implicit inserts were corrected in this package by specifying column names.

gokb_address1.sql

The p_update routine was modified to test if the status has changed as part of the transaction. If the status has not changed, then the routine does not update the telephone record.

A Finance address can now be updated even if the To and From dates exist in the current record. The check is only performed in the p_create routine.


Section 11 Miscellaneous EnhancementsMiscellaneous Changed Procedures

gokb_name_translate1.sql

The extra UPPER command was removed from the f_build_gorname_rec routine, where it was building the compressed version of the name and alias columns. The function being called already performs does the UPPER command.

gokb_np_name_trans1.sql

Support was added for the two new compressed name columns in the GORNPNM table. The support was added to this package so that the names do not need to be compressed on demand, which will improve the performance of the Common Matching API.

gokb_common1.sql

The logic in the f_err_msg_remove_delim_tbl routine was changed to not use the genutil.strtok routine. Logic in this routine was rewritten to do the parsing of the logic locally. Since the genutil package only supports a single character at a time, valid characters such as ":" in a message caused it not to work.

Miscellaneous Changed Procedures

gppaddr.pc

Implicit inserts into the SPRCOLR table were corrected by specifying column names.


Section 11 Miscellaneous Enhancements Miscellaneous Changed Libraries

Miscellaneous Changed Libraries


Performance Improvements

• The G$_SECURED_FORM_CALL was updated to verify whether the extended query setting has been obtained, and if not, fetch it. It was also updated to verify if the call_query setting has been obtained, and if not, fetch it. These were removed from GUAINIT in order to improve startup time. The change also stores the settings in globals, which eliminates the need to call the database function every time the procedure is invoked.

• The G$_QUERY_ONLY_ROLE call was moved from the G$_POP_UP_MENU routine to the G$_FORM_STARTUP routine, because it only needs to be called once.

• Obsolete logic and variables from several routines was removed.

• The G$_NAVIGATION_FRAME package body was changed to process the popup menu entries the same way it processes options. This affected the changing of the description, enabling, and disabling of entries. This modification eliminates the need to completely rebuild the popup menu each time a change is made.

• The G$_GOQOLIB_PP_TRIGGER package body now loads options in the PRE_FORM routine rather than the PRE_BLOCK routine, because PRE_BLOCK options loading was less efficient.

Error Message Changes

The following changes were made to the G$_DISPLAY_ERR_MSG procedure:

• This procedure now accepts a new parameter that will control whether or not to force a Rollback. The new parameter allows warning messages to be passed in and displayed.

• The maximum size of error messages passed to the procedure was increased to 4,000 characters.

• The logic was updated to insert a carriage return at the end of each sentence in order to improve readability.

• The procedure now accepts an additional parameter which signals that the message being passed should be displayed, but that the transaction should not be rolled back. The default value is to perform the Rollback. This procedure is used by the API logic to display all error messages from any called API. This change supports the Human Resources product, which requires warnings without forcing the transaction to be rolled back in JOBS processing.


Section 11 Miscellaneous EnhancementsMiscellaneous Changed Libraries

New Routines

• The new G$_GET_UPRF_DE_PROMPTS routine obtains the user setting for whether to include the column headings with the data extract.

• The G$_GET_UPRF_DUP_SNN_ALERT routine retrieves a user's GUAUPRF setting for whether he/she wants to be warned about duplicate SSN/SIN/TFNs.

• The G$_GET_UPRF_DE_PROMPTS routine retrieves a user's GUAUPRF setting for including column headings in the data extract. Additionally, support for this new user preference was added to the G$_WRITE_BLOCK routine. The routine invokes this function to determine whether to include the column headers as the data is being extracted.

Miscellaneous Changes

• Several item declarations which are never used were removed from the G$_GOQOLIB_PP_TRIGGER.PRE_BLOCK trigger.

• Obsolete code and variables were removed from the G$_SECURED_FORM_CALL, and the code was changed to make it more efficient.

• Long names are now handled better by the G$_BUILD_FULL_NAME routine. Previously, if the name was extremely long, an unhandled exception was raised. A new local variable was created of sufficient length to hold the maximum value of the name being built, and then truncate the value of this variable according to the length parameter. The value is then returned to the calling routine.

• Logic was added to create the GLOBAL.MDI_TITLE global if it did not exist. This change was in response to an issue with the current logic of the G$_SECURED_FORM_CALL when a form was called directly from a channel. The GLOBAL.MDI_TITLE did not get created beforehand, and therefore, caused an error.

• The G$_WRITE_BLOCK logic now truncates the data to 1,998 characters and appends the closing double quote. Previously, if the data exceeded the support length of 2,000 characters, the closing double quote was lost.

• Unused local variables were removed from the G$_VPDI package.

• The G$_GET_MAIN_WINDOW_TITLE routine was changed to retrieve only the baseline description of an object to display in the title bar; custom descriptions are not displayed.



Common Forms Object Library (goqclib.fmb)

Any blocks in this library that had the User ID and Activity Date items enabled (thus allowing users to enter a User ID or Activity Date) were changed so that these fields are no longer enabled.

Additionally, numerous window-specific changes are described below.

Current ID Window

• Null Triggers Added--Products can implement a custom version of this NULL trigger: SPRIDEN_CURRENT.EDIT_EMPLOYEE_STATUS.

• SPRADDR Sequence Number Null--The ON-INSERT trigger in the SPRADDR block was changed to initialize the SPRADDR_SEQNO item to NULL prior to calling the API. The item should never have a value, except the one given it by the API, but sometimes, the API thought the item had a value.

• Automatic Key Block Refresh--After a name change, the key block name is automatically refreshed. Previously, users had to roll back to the key block in order to refresh the value.

• SSN Duplicate Message--If a user checks the Display Duplicate SSN/SIN/TIN Warning check box on GUAUPRF, then a pop-up error message window will be displayed for duplicate SSNs.

• The KEY-COMMIT trigger on the SPRIDEN_CURRENT block was updated to test for success after attempting to issue the NEXT_ITEM and PREVIOUS_ITEM commands. Previously, a POST-CHANGE or WHEN-VALIDATE-ITEM failure would not stop the processing and caused error messages to be displayed twice.

• Navigation logic in the SPRIDEN_CURRENT.SPRIDEN_ID.KEY-PREV-ITEM trigger now checks if the marital code is visible, to determine how the cursor should navigate. Previously, the marital code was not visible in some forms.

• The SPRIDEN_CURRENT.WHEN-NEW-BLOCK-INSTANCE trigger now enables and disables the Search buttons only if they are visible.

• Name-related items on the SPRIDEN_CURRENT canvas were adjusted so that all of the items are correctly spaced.

Alternate ID Window

The following navigation issues were corrected:

• The SPRIDEN_ID item in the SPRIDEN_PREVIOUS block was changed to allow Enter Query mode.

• Logic was added to the WHEN-NEW-RECORD-INSTANCE, WHEN-NEW-ITEM-INSTANCE, and KEY-NEXT-ITEM triggers in the SPRIDEN_PREVIOUS block to verify if the block is currently in Enter Query mode and, if so, change some of the navigation features.


Section 11 Miscellaneous EnhancementsMiscellaneous Changed Libraries

• The navigation logic in the SPRIDEN_PREVIOUS block was consolidated into common triggers which can be called from various routines.

• Logic was added to the KEY-COMMIT trigger in the SPRIDEN_PREVIOUS block to cause a re-query after the commit succeeds, in order to eliminate possible locking issues. This was only an issue when the record being deleted required that another record be updated first, in order to preserve the name or ID change so the re-query had the appropriate condition for the situation.

Additionally, The Name Type description now displays. The cursors in the POST-QUERY and WHEN-VALIDATE-ITEM in the SPRIDEN_PREVIOUS block were changed to use the existing API for the Name Type code in order to retrieve the description.

Address Window

• The telephone record is now only updated for a change in address status. Previously, every address change also updated the primary phone, even though there were no changes to the telephone.

• When a telephone number is added on the Address window, there is now a check to see if the telephone number already exists. If the same telephone number exists but is not primary, then the record gets updated to be primary. A new telephone record does not get inserted.

• A new SET_FINANCE_DATES trigger was added to allow Banner Finance users to create addresses with NULL To and From dates. This trigger is called by the POST-CHANGE on the Address Type item. By default, the trigger does not perform any task. It will be modified by Banner Finance forms to do custom date handling in the future.

Telephone Window

Addresses can now be changed to inactive without changing the primary telephone number to not primary. Previously, if an address had a primary telephone and the address was made inactive, then telephone was also made inactive. When the telephone record was subsequently updated on the Telephone window, the record could not be inactive and primary.



Biographical Information Window

• SSN Duplicate Message--If a user checks the Display Duplicate SSN/SIN/TIN Warning check box on GUAUPRF, then a pop-up error message window will be displayed for duplicate SSNs.

• Changes for Race Ethnicity--Logic was moved from the individual forms to GOQCLIB . This was now possible since all product forms have been delivered for the Race/Ethnicity changes.

• Null Triggers Added--Products can implement custom versions of the following null triggers:

• SPBPERS.EDIT_PERS_GENDER

• SPBPERS.CHECK_FOR_EMPLOYEE

• SPBPERS.EDIT_BIRTH_DATE

• SPBPERS.EDIT_COBRA_ELIGIBILITY

• SPBPERS.EDIT_PERS_AGE

• SPBPERS.CONVERT_ETHN_CODE

• The SPBPERS.CHECK_SSN trigger is now a Null trigger.

• The GORPRAC.KEY-NXTBLK trigger now executes KEY_NXTBLOCK_TRG, instead of simply issuing a NEXT_BLOCK command for consistency. A GORPRAC.KEY-PRVBLK trigger was added so that it performs like all of the other blocks (verifies that there are no pending changes).

• Logic was added to the SPBPERS.CONVERT_ETHN_CODE trigger to call the G$_CONVERT_ETHN_CODE library routine to perform the ethnicity conversion.

• The SPBPERS block was changed so that on the SPBPERS_ETHN_CDE, SPBPERS_CONFIRMED_RE_CDE,SPBPERS_CONFIRMED_RE_DATE, and SPBPERS_CONFIRMED_RE_DATE_DBT items, the VISIBLE property is set to True.

• Logic was added to clear the value in the Age item (which is calculated) if the Birth Date is cleared.

Form Object Library (goqolib.fmb)

Note: Changes to this library require that all forms be regenerated for Release 7.3. Refer to the Multi-Institution Functionality (MIF) Enhancement and the Rebranding sections for information about other changes to this library.

The obsolete record group and LOV for GTVFMFD were removed. The STVDAYS_RG Select statement was updated to correctly apply the format mask to the Activity Date column and to apply a column alias.

The STVHLDD_LOV and STVHLDD_RG items were changed so that the columns match the order in which they appear in STVHLDD the form.


Section 11 Miscellaneous EnhancementsMiscellaneous New Scripts

Miscellaneous New Scripts

igurmesg73.sql

This script inserts rows for the new APIs into the GURMESG table.

ugurmesg73.sql

This script updates existing GURMESG rows.

stvsbgi1.sql

This script adds a comment on column in the STVSBGI table.

ssrxlst1.sql

This script creates an index on the SSRXLST Banner Common table.

igtvsqpr73.sql

This script inserts a new row in the GTVSQPR table.

ugubobjs73.sql

This script updates the GUBOBJS table.

gdrbhlp70300.sql

This script updates Dynamic Help entries in the GUBBHLP table.


Section 11 Miscellaneous Enhancements Changed DBPROCS Script

Changed DBPROCS Script

gendbpr.sql

New dbprocs were added for:

• Medical code

• XML transcripts

• Large Objects

• Prior college

• Visa

Additionally, entries were added for the following:

• gokcard

• gokeprt

• gokwutl

• International Student process

• gokvpda

• gspvpdi

• The disabled code to was added to gstvpds0.sql.

New Master Compile Scripts

These new form generate scripts support Oracle Application Server 10g Release 2 (10.1.2), which contains Oracle*Forms and Oracle*Reports version 10.1.2.0.2:

• comformr2.bat

• genformr2.bat

• genform1r2.bat

• genform2r2.bat

• comformr2.shl

• genformr2.shl

• genform2r2.shl


Section 11 Miscellaneous EnhancementsChanged Master Compile Scripts

Changed Master Compile Scripts

comform.bat

The form generate command was changed. Additionally, compile_all=special and module_type=form were added.

comform.shl

Compile_all=special was added for menu and form objects.

Additionally, compile_all=yes was changed to compile_all=special for .pll files.

genform.shl

The following entries were added:

• goirsql

• goicmss

• gorvpdi

• guqwutl

• Compile_all=special for menu and form objects

Additionally, compile_all=yes was changed to compile_all=special for .pll files.

genform.bat

The following entries were added:

• goirsql

• goicmss

• gorvpdi

• guqwutl

• Compile_all=special for menu and form objects

Additionally, compile_all=yes was changed to compile_all=special for .pll files, and module_type=form for form objects was added back into this script.


Section 11 Miscellaneous Enhancements Changed PLUS Script

genform1.bat

In this script, compile_all=yes was changed to compile_all=special for .pll files, and module_type=form for form objects was added back into this script.

genform2.bat

Compile_all=special was added for .pll files, and module_type=form for form objects was added back into this script.

genview.sql

The new GOVCMID view was added to this view driver script.

Changed PLUS Script

glramod.sql

The sequence for marking the modification complete was changed from 9,000 to 9,800 due to a defect where the SQL was greater than 9000.

New XSD Script

genfsatlas.sql

This driver script is used to unregister and register the fsaATLAS XML schema.


Section 11 Miscellaneous EnhancementsChanged Readme File

Changed Readme File

greadme.doc

The following scripts were added to this document:

• gselvisa.sql

• gdelsdaxvisa.sql

• gupdvisa.sql

Additionally, the gupdintl.sql and gdelintl.sql entries were updated.


Section 11 Miscellaneous Enhancements Changed Readme File



Section 12 Problem ResolutionsLetter Generation

Section 12 Problem Resolutions

This section lists the problem resolutions included in Release 7.3.

Letter Generation

GUIMAIL (#105078)Description: The List function does not work on several fields.

Impact: Even though this is an inquiry form, the List function is still necessary to view the description for the code.

Resolution: No changes were made to resolve this problem. Descriptions are visible in Query mode, which is how the form was designed. This defect is now resolved.

GUALETR (#1-6KLOH)Description: GUALETR pulled up the incorrect paragraphs for the letter code entered.

Impact: GUALETR is incorrectly displaying paragraphs assigned to letter = TG_LETTER, which is misleading and causing potential error on GLBLSEL process. The problem is the "_" is being treated as a single character positional wild card in GUALETR So the system is displaying anything with TG as the beginning first 2 characters, then interpreting "_" as a wildcard.

Resolution: The WHERE clause was changed to return only rows associated with Key Block 'Letter'.

Job Submission

GJAPCTL (#1-7E177)Description: The Special Print option was incorrectly available for certain Windows database servers.

Impact: It incorrectly appeared that you could choose the Special Print option for Windows database servers.

Resolution: The Special Print field was disabled for Windows database server.


Section 12 Problem Resolutions Common Matching

GORPGEO (#CMS-DFCT103381)Description: GORPGEO did not check the GLBEXTR_USER_ID, which caused all selections with the same name to be processed.

Impact: An additional parameter to specify User ID needed to be added to the program and the SEED data.

Resolution: The new popSel_userID parameter was added, as well as a new routine ask_popSel_userID. Cursor_30 was changed to include the User ID of Population Selection.

GJAPDFT (#CMS-DFCT105726)Description: The AutoHelp had incorrect instructions on how to remove user defaults.

Impact: The AutoHelp needed to be corrected.

Resolution: The AutoHelp now contains the correct instructions.

(#CMS-DFCT78742)Description: The help text on GJAPDFT incorrectly stated: User Default Value; select REMOVE RECORD to remove this value or select CLEAR BLOCK to remove all default values.

Impact: The user received the error: Undefined function key. Press <Show Keys> for a list of valid keys.

Resolution: Help text was changed to User Default Value; select DELETE RECORD to remove this value or select CLEAR BLOCK to remove all default values.

Common Matching

GOAMTCH (#CMS-DFCT103345)Description: No current address was available after Common Matching update of existing ID.

Impact: Sequence 2 address remained unchanged, but the sequence 1 address, with the current date range marked inactive, left the person with no current address.

Resolution: Both addresses remain unchanged and the message returned is 'Address not updated'.

(#CMS-DFCT105716)Description: Form did not have Options.

Impact: Options were missing from this form.

Resolution: Options were added.


Section 12 Problem ResolutionsSecurity

(#CMS-DFCT105807)Description: The gender displayed on GOAMTCH changed to null after creating a new person with a gender of Not Available.

Impact: The gender was incorrectly displayed.

Resolution: The correct gender now appears on GOAMTCH.

(#CMS-DFCT105897)Description: While running Duplicate Check, the following error occurred: FRM-40735: GET_MATCH_DETAILS trigger raised unhandled exception ORA-06502 for certain data and common matching rules.

Impact: An error occurred.

Resolution: The maximum length of several fields were increased so the error no longer occurs.

(#CMS-DFCT105958)Description: Common Matching is creating SPBPERS records for non-persons.

Impact: SPBPERS records are being created for non-persons.

Resolution: This form was changed so that non-person records are no longer created in SPBPERS.

Security

GSASECR (#1-B1087)Description: The logic only allowed BAN_DEFAULT% roles to be displayed.

Impact: Necessary roles were excluded.

Resolution: The user default role record group was updated to include user-defined default roles.

(#CMS-DFCT10224)Description: Distributed security users could not create roles with the naming convention BAN_XXXX. Secondly, those users were unable to delete roles. Lastly, Distributed security users were unable to copy from existing roles that contained object privileges, such as BAN_DEFAULT_REPORT or USR_REPORT.

Impact: Distributed Security users could not perform needed tasks.

Resolution: Distributed security scripts and GSASECR were updated for the 7.3 release, so these problems no longer occur. Refer to the Security Enhancement section for details.


Section 12 Problem Resolutions Security

(#1-5GA6N)Description: When a BANSECR user tried to add a system privilege to a role on GSASECR, a Call to DO_EXEC_SQL routine failed error occurred.


Resolution: BANSECR users can now add system privileges to a role.

(#CMS-DFCT102587)Description: Distributed security (distsecr) users received the following error: FRM-40737 Illegal restricted procedure GO_BLOCK.

Impact: Distributed security users received errors when running GSASECR.

Resolution: Distributed security scripts and GSASECR were updated for the 7.3 release, so this problem no longer occurs. Refer to the Security Enhancement section for details.

(#CMS-DFCT105161)Description: On the User Maintenance window of GSASECR, creating a user caused the following error: *ERROR* Call to SQL_TRACE routine failed pressing EXPIRE/LOCK/UNLOCK button.

Impact: A error was displayed if the user attempted to use the Expire, Lock, and Unlock buttons while creating a user.

Resolution: The GSASECR form was modified to disable Expire, Lock, and Unlock buttons while creating a user.

gssbasg.sql (#CMS-DFCT79526)Description: Distributed security users received an Oracle error when trying to delete a role.

Impact: The following error message appeared: FRM-40735 - WHEN-BUTTON-PRESSED trigger raised unhandled exception ORA-1031.

Resolution: A new GUBROLE grant was added to support the ability to delete roles.

gssrolm.sqlgssrolc.sql

(#1-5GA66)Description: Problem with distributed security when adding a direct table grant to a role identifier BANINST1_SQL_PKG must be declared

Impact: Distributed security users received an error on the GSASECR form when they performed the following tasks: On GSASECR, chose the Role Maintenance tab, chose a role name, chose Role Privileges, clicked Add Object, and saved the record. This error appeared: DBMS error in EXECUTE_FOREIGN_SQL is:ORA-06550 line1, column 23: PLS-00201: identifier 'BANINST1_SQL_PKG' must be declared ORA-06550: line.

Resolution: Execute privileges were granted on the BANINST1_sql_pkg to the BANSECR_TEST user in the gssrolm.sql script.


Section 12 Problem ResolutionsSecurity

gsssysg.sql (#1-4T76E)Description: When signing on to GSASECR (either stand-alone or via GUAINIT/GUAGMNU) using a distributed security account, the following error occurred: FRM-40735: PRE-FORM trigger raised unhandled exception ORA-04067.

Impact: There was a missing grant in the gsssysg.sql distributed security script. Because of the missing grant, the distributed security users were receiving an error when opening the GSASECR form. The error was FRM-40735" Pre-FORM trigger raised UE ORA 04067.

Resolution: The distributed security script gsssysg.sql was updated to include grant execute on G$_DATE. This resolves the error that was being encountered by a distributed user when calling GSASECR.

(#1-5GA2K)Description: Distributed security received the following error: FRM-40735 PRE-COMMIT trigger ORA-04067.

Impact: Distributed security users received errors when accessing GSASECR.


(#CMS-DFCT102299)Description: Distributed security users received the following error: ORA-04067 and ORA-00942.

Impact: Distributed users received an error when opening GSASECR.


(#CMS-DFCT103064)Description: Distributed security users with BXS installed received the following error: FRM-40735:PRE-FORM trigger raised unhandled exception ORA-04067.

Impact: Distributed security users received errors when running GSEASECR if BXS was installed.

Resolution: The gsssysg.sql script was updated to include grants for BXS objects.

(#CMS-DFCT104757)Description: Distributed security users received the following error: FRM-40735: WHEN-BUTTON-PRESSED trigger raised unhandled exception ORA-1031.

Impact: Distributed security user received the following error when attempting to delete a user: FRM-40735: WHEN-BUTTON-PRESSED trigger raised unhandled exception ORA-1031.



Section 12 Problem Resolutions Security

(#CMS-DFCT89563)Description: Distributed security users received an ORA-942 error when logging in to GSASECR.

Impact: An error occurred on login.


(#CMS-DFCT93026)Description: Distributed security users received the following error: ORA-04067 BANINST1.GB_COMMON.

Impact: Distributed security users could not update times on the Profile Maintenance tab of GSASECR.


goksss1.sql gokcss1.sql gokssso.sql

(#1-44TCP)Description: The ORA-27045 Can Cause Datafile Header Corruption error occurred in these packages.


Resolution: The function f_usermap was changed to use the dbms_ldap.unbind function to unbind the LDAP session.

(#CMS-DFCT105858)Description: Last activity time was not being handled properly for Self-Service Banner (SSB) and/or Internet-Native Banner (INB) via Single Sign-on (SSO) through Luminis.

Impact: The activity time was handled incorrectly.

Resolution: Login parameter was added to p_cp_lastact and time= 0 was added instead of current time.

(#CMS-DFCT106003)Description: Sporadic instances in which one user may possibly be viewing the Internet-Native Banner (INB) session of another user who is simultaneously accessing INB, when INB is accessed via Single Sign-on (SSO) through Luminis.

Impact: One user may possibly be viewing the INB session of another user who is simultaneously accessing INB .

Resolution: DBMS_RANDOM function was modified to use SEED values. In adition, encrypted value of user is being added to the token to make it unique.


Section 12 Problem ResolutionsMiscellaneous Forms

Miscellaneous Forms

GOAMTCH (#CMS-DFCT105323)Description: An error when exiting this form: FRM-40815: Variable GLOBAL.KEY_PIDM does not exist.

Impact: The form was changed.

Resolution: This error no longer appears when exiting the form.

GORNAME (#CMS-DFCT104944)Description: GORNAME name and alias detail were not taking effect unless a user logs out and logs back into Banner.

Impact: Users needed to log out of Banner and log back in for matching to recognize new entries in the GORNAME table.

Resolution: Entries are recognized immediately upon being entered into GORNAME.

GUAGMNU (#1-I13ZQ and #1-5N33S)Description: When keyboard navigation is used in the menu tree (forms 9i and above), the user must press 'enter' and then 'tab' to launch a form. The documentation should indicate this. In Forms 6i, just the 'enter' key would launch the form. This has caused some confusion.

Impact: Prior to 7.3, when using keyboard navigation, you must use the tab key to open a form once you have highlighted it.

Resolution: In 7.3, pressing the Enter key will open a highlighted form.

GUAPMNU (#1-D9STJ)Description: There was a performance problem when accessing GUAPMNU on Oracle Database 10g.

Impact: There was a performance problem when accessing GUAPMNU on Oracle Database 10g.

Resolution: There is no longer a performance problem.


Section 12 Problem Resolutions Miscellaneous Forms

GUAUPRF (#CMS-DFCT105809)Description: Updating information on GUAUPRF sometimes resulted in the error: Could not reserve record (2 tries). Keep Trying? [YES or NO].

Impact: The PRE_FORM_TRG trigger was updated to create all missing user preferences records for a user. This is done to allow the blocks to be redesigned to be based on the user's records instead of baseline records. The design and logic in the UI, Directory, Links, and Menu blocks were changed to be based on the user's records and not on baseline's records. Logic was added to the PRE-BLOCK triggers to verify that no pending changes exist before allowing navigation.

Resolution: At start up, all user preference records are now created for the user. All blocks now query the user's records. Option records will be changed accordingly.

(#CMS-DFCT102454)Description: The Banner splash screen appeared and then the session ended due to a character limitation on the My Links portion of the form.

Impact: The menu form could not handle descriptions greater than 90 characters.

Resolution: The GURUPRF_LINKS block was changed to limit the length of the description entered to 90 characters.

(#1-B1F1K)Description: Masking data in GUAUPRF resulted in the error: FRM-40112: Attempted go_item to non enabled item.

Impact: When certain fields are masked on the GUAUPRF form, an frm error is the first thing that displays on the form. The form is actually usable at this point, but the error will appear each time the user attempts navigation to the block containing the masked fields.

Resolution: The GO_ITEM commands were replaced with GO_BLOCK commands to address navigation issues when items are masked.

GUITINH (#LN71-0040-1719)Description: TFN was changed to TIN in the title bar of this form.

Impact: The title bar had the wrong name.

Resolution: The correct name now appears.


Section 12 Problem ResolutionsMenus

GXRBANK (#1-7EN2Z)Description: The FRM 40735 Edit_Fund_Code trigger raised ORA 060502 error occurred when querying on a bank code.

Impact: Unable to create, update or query bank codes which have associated Fund and cash account codes but the chart of accounts field on the bank code is not populated on GXRBANK, and the Fund orAccount code exists in multiple chart of accounts.

Resolution: The size of sql_stmt variable was increased to 2,000 from 200 in triggers edit_fund_code and edit_acct_code_cash. Additionally, a ROWNUM = 1 predicate was added to the where clause of the SQL statement string sql_stmt in the triggers edit_fund_code and edit_acct_code_cash.

GORADMS (#1-DH13E)Description: Users were unable to enter required values.

Impact: Users were unable to enter data on this form.

Resolution: Users can now correctly enter data on this form.

Menus

GUMAPPL (#1-D7A5I)Description: The GUAINST indicator for the SQL Trace Enabled check box did not disable the SQL Trace menu options.

Impact: Because it was not possible to turn off the SQL Trace option, it was possible that users could unintentionally create very large trace files.

Resolution: When the SQL Trace Enabled checkbox is unchecked, the option to Turn on SQL Trace via the Help-Technical Support Menu is correctly disabled.

(#1-CFBA3)Description: The Cut and Copy menu items copied the entire contents of an item, rather than just what was selected.

Impact: The Cut and Copy menu items copied the entire contents of an item, rather than just what was selected.

Resolution: The properties for the Cut, Copy, and Paste menu items were changed so that the properties correctly match their intended properties.


Section 12 Problem Resolutions Libraries

Libraries

goqrpls.pll (#1-AW2CF)Description: Options (GUROPTM rows) were being loaded inefficiently.

Impact: Inefficiencies which caused performance problems were: additional loading of options being performed within the pre-block trigger and the pop-up menu being rebuilt completely instead of a disabling/enabling of affected menu items.

Resolution: Options now load in an efficient manner.

(#1-66J86)Description: When running 7.x queries in any forms that contain the ampersand (&) in the query text with EXTENDED_QUERY disabled, the following error occurred: *WARNING* Extended Query functionality has been disabled.


Resolution: This library was changed so that queries can now contain ampersands without creating an error.

GOQCLIB (#1-5T2S4)Description: Entering a duplicate SSN on SPAPERS did not open a pop-up window with the duplicate SSN message.

Impact: On some forms/ tabs of the %IDEN forms the SSN duplicate warning pop-up was not displaying.

Resolution: The POST-CHANGE trigger on SPBPERS.SPBPERS_SSN, and the WHEN-VALIDATE-ITEM trigger on SPRIDEN_CURRENT.PERS_SSN were changed to call a new routine in GOQRPLS to determine the user preference setting for displaying the duplicate SSN/SIN/TFN warning message. Logic in the WHEN-VALIDATE-ITEM was removed because it was attempting to keep the other SSN item in synchronization. Since navigation to each tab caused a query to occur, they automatically received the updated value. This also eliminated the duplicate warning message.


Section 12 Problem ResolutionsAPIs

(#1-HJM5B)Description: When an address was marked INACTIVE, the matching telephone record was not marked as INACTIVE. Conversely, when an inactive address was marked ACTIVE, the corresponding inactive telephone record was also not marked ACTIVE.

Impact: When the telephone number was updated to inactive, the telephone window would not allow it to be the primary phone.Therefore the telephone would no longer display on the related address record, on the address window. The user did not intend to break the relationship between the telephone and address when inactivating the telephone, but the telephone window required it.

Resolution: The Telephone window was changed so that when the telephone record is made inactive it can still remain primary. As long as the telephone record is primary, the telephone will display on the address window. If a user purposely changes the telephone record to not be the primary one, it will not display on the address window. If the user attempts to add an identical telephone number on the address window for the same address and seqno that is not primary, the system will recognize that it already exists and update the primary indicator to Y, rather than inserting an entire new telephone record having the same number.

goqolib.fmb (#1-AOVW1)Description: Some forms’ Date/Time fields displayed a very small portion of the time component.

Impact: The time component shows partially hidden in the Date field.

Resolution: The G$_DATETIME_CLASS class was restored so the format mask for DD-MON-RRRR from the G$_DATE_CLASS class is inherited in the G$_DATETIME_CLASS class.

APIs

gokb_address_r1.sql gokb_address_r0.sql gokb_address_s1.sql

(#1-6K0TV)Description: There was no edit in the Address API to prevent an address from being created when the From Date was greater than the To Date.

Impact: You could create an address with a From Date greater than the To Date.

Resolution: There is now an edit to prevent an address from being created when the From Date is greater than the To Date.

gokb_address1.sql

(#CMS-DFCT104168)Description: Refer to Changed APIs in the API Enhancement section for information about this defect.


Section 12 Problem Resolutions APIs

gokb_address_s1.sql

(#1-6A0GJ)Description: The error message was incorrect for STATE NATN REQUIRED.

Impact: The error message was changed.

Resolution: The correct error message is now displayed.

gokb_room_assign_r1.sql

(#CMS-DFCT79394, CMS-DFCT105936)Description: A room that has a Must Match indicator set for an attribute in a previous effective term still requires the override restrictions check box to be checked, even though the room assignment term is not within the prior effective term's range.

Impact: The Must Match indicator message was presented incorrectly on SLARASG in a newer term when the room had been defined as Must Match on SLARDEF in a prior term, but had been turned off in the newer term. The message was picked up incorrectly from the prior term definition.

Resolution: The dynamic SQL code was changed in gokb_room_assign_r1.sql to reference the SLRRDEF table. It no longer checks the Must Match indicator in the subquery. gokb_room_assign1.sql was also changed to delete an extra CLOSE lv_cursor command.

gokb_room_assign1.sql

(#CMS-DFCT106105)Description: SLRROLL rolled correct housing term dates, but incorrect dates for assessment.

Impact: When the dates of the academic term and the dates of the housing term are different on STVTERM, SLRROLL rolled the dates of the housing term, but based the monthly/daily calculation on the dates of the academic term, which resulted in an incorrect assessment. This issue existed in SLARASG, SLAMASG, and SLAPASG

Resolution: Modified the p_calc_day_mon_term procedure in gokb_room_assign1.sql to use STVTERM_HOUSING_START_DATE and STVTERM_HOUSING_END_DATE instead of STVTERM_START_DATE and STVTERM_END_DATE.

gokp_cardholder1.sql

(#1-5PEUN)Description: When international phone numbers exceeded 12 characters, this error occurred: PL/SQL numeric or value error character string buffer too small.

Impact: Maximum size allowed by XML Schema for phone number international codes was smaller than Banner value for international codes.

Resolution: For variables based on the rco_telephone type, populate InternationalCountryCode element with null instead of the Banner international code from the SPRADDR table.



(#1-5PEVW)Description: CardholderGender was sometimes missing in CardholderIdentity.

Impact: If a person had no SPBPERS data, no CardholderGender was being passed to the message. CardholderGender is a required element of CardholderIdentity.

Resolution: If SPBPERS record is missing, or spbpers_sex column is null for a given cardholder, then their gender element is set to N.

(#1-5PEWK, 1-5QFYA)Description: If no cardholders were selected, the response was an empty message, which is not valid XML.

Impact: This scenario requested a group of cardholders for a Role that had no active rules in Banner. The API returned an empty message, which did not validate against the schema.

Resolution: An error is now raised and a fault returned if no cardholders are selected.

(#1-6KLRH)Description: Residence phone number attached to residence address was not returned in response message.

Impact: Residence phone number attached to residence address was not returned in response message.

Resolution: In f_cardholder function, address hierarchy, as well as phone hierarchy, are both passed in the call to gokpapi.f_get_telephone_oot.

(#1-5QFYY)Description: No work telephone numbers were returned in response message.

Impact: No work telephone numbers were returned in response message.

Resolution: In f_cardholder function, call gokpapi.f_get_telephone_oot rather than a combination of f_get_address_telephone_rowid and gb_telephone.f_query_by_rowid.

gokp_entity_address1.sql

(#1-5PEPX)Description: Process API response messages labeled all Identifiers as 'BannerUID' when some are IMSIDs or LogonIDs.

Impact: The response message will give the correct Name of the ID Type associated with the Value shown.

Resolution: In f_add_entity_address, populate the first extent of AddressIdentifier in the response with the first extent of the incoming message, which is used to identify the entity. In f_expire_entity_address, return the entire request AddressIdentifier in the response message, as received.


Section 12 Problem Resolutions APIs

(#1-5PE8T)Description: AddEntityAddress. When I use Nation 157, the address is created without Street (I had two) and State.

Impact: Process will now create a complete address including State (Province) and up to 3 Street Lines.

Resolution: Use first extent of Region to obtain value for State/Province Code. Use the first 3 extents of AddressLine as street_line1,2, and 3.

(#1-5PES7)Description: Process API expects AddressIdentifier IdValue/@name pairs to appear in certain order

Impact: If the order of the AddressIdentifier IdValue/@name pairs varied, the ID, address type, and address sequence were not handled correctly, leading to false errors.

Resolution: Add local variables to hold these ID, address type, and sequence number, and loop through the collection making assignments of the values based on the @name attribute. If a valid ID @name is not found, raise error instead of calling gokpapi.f_get_pidm. As a part of this correction, all the address request and response messages are changed to use SequenceNumber rather than AddressSequence for references to spraddr_seqno (added CONSTANTs for type and sequence labels).

(#1-5PET4, 1-5PETI)Description: Address already inactive returns wrong fault message.

Impact: If address is not found when attempting to change expiration date, it is important to know if that is due to an already inactive address.

Resolution: If an active address is not found, use gb_address.f_get_status to check for Inactive address and raise appropriate message.

(#1-5PEPJ)Description: ExpireEntityAddress. Neither spraddr_user nor spraddr_data_origin is being updated in Banner. There is no way to tell who inactivated the record.

Impact: SPRADDR_USER and SPRADDR_DATA_ORIGIN are not consistently populated when address is added or expired.

Resolution: When adding address, the User should be the Requestor if populated, or the Proxy User by default. For expire address, the User is the Proxy User. In both cases Data Origin is set from the "source" of the EntityAddress.

(#1-5PE96)Description: SPRADDR_STATUS_IND always set to inactive by process API.

Impact: Status is incorrectly set to I (Inactive) when address is expired.

Resolution: Commented out the update to the status indicator. Change of the to_date is sufficient to terminate the address at the appropriate point in time.



(#1-DEK81)Description: Address should be inactivated when From Date = To Date.

Impact: When vendor wants to correct an address before the student has moved in, they have no way to update, delete, or inactivate the first address, they can only expire the address. To keep the incorrect address from interfering with the addition of accurate address data, the incorrect address must be inactivated.

Resolution: In ExpireEntityAddress, conditionally set the Inactive indicator when the To Date requested matches the From Date existing record.

gokp_person_identity1.sql

(#1-5QG28)Description: No match type is returned in ShowPersonIdentity message.

Impact: This package was changed.

Resolution: The overall match status is now returned in the matchType attribute.

(#1-5QG2M)Description: A default Common Matching source code on GORCMUS is not being applied to Common Matching search.

Impact: The package was changed.

Resolution: The default source code is now applied correctly.

(#1-5QG3H)Description: Incorrect number of records were returned by the response.

Impact: Incorrect number of records were returned by the response.

Resolution: The limit value (defaults to 20) was changed to control how many rows are returned from the result set. This ensures the count of records return is the same as the actual number of records returned.

(#1-5QG45)Description: The GTVSDAX rule that specifies which Common Matching source code to use was not being applied to the Common Matching search.

Impact: The program was not calling the function that looks up the Common Matching rule.

Resolution: The program now correctly passes the rule to the Common Matching procedure. The CM procedure has been enhanced to report a NULL source code or an invalid source code. This should also prevent the erroneous Invalid ID error.

(#1-5TUS9, 1-F0U8N)Description: Process API returned an unclear fault message when GTVSDAX rule was not accurate.

Impact: Misleading error message ID not found when CMSC code is invalid or NULL.

Resolution: This API now raises the exception Invalid Common Matching Source Code in f_get_cmsc_code if CMSC is NULL or if there are no rules for the given CMSC code.


Section 12 Problem Resolutions Miscellaneous Scripts and Packages

gokb_email_r1.sql

(#CMS-DFCT105822)Description: Multiple Preferred E-mail addresses of the same E-mail type were allowed.

Impact: The API was changed.

Resolution: Only one Preferred E-mail addresses of the same E-mail type is now allowed.

gokb_bio1.sql (#1-CZU0X)Description: SSN changes were not logged correctly when the SSN was changed from or to a NULL value.

Impact: Incorrect logging of SSN changes.

Resolution: SSN changes that involve a NULL value are now logged correctly.

gokb_classtimes1.sql

(#1-DDH3Z)Description: When the Meeting Time API was called, the p_validate routine was executed. This problem was originally reported for SSRSCMT (as the same number).

Impact: The p_validateroutine was executed when it should not have been.

Resolution: A context variable was added so that when the API is called, p_validate is not executed. gokb_classtimes1.sql was also changed to acknowledge the context variable and to not execute p_validate.

(#1-ERMGX)Description: SSRSMNT.pc called the p_update procedure to update SSRMEET records from the output of Schedule25. This in turn called p_validate, which generated edit errors that cause SSRSCMT.pc to abort.

Impact: The program aborted.

Resolution: p_update was changed to only call p_validate for objects other than ssrscmt.pc.

Miscellaneous Scripts and Packages

gukmen1.sql (#1-69KLU)Description: There was a performance impact with Cost-Based Optimizer.

Impact: When moving to Cost-Based Optimizer, the user may experience a performance problem when logging into Banner.

Resolution: Added hint to main menu building query. The hint tells the optimizer to use the rule characteristics instead of CBO.


Section 12 Problem ResolutionsMiscellaneous Scripts and Packages

gokpapi1.sql (#1-5PEUN)Description: Processing errors occurred when the International telephone number exceeded 11 characters.

Impact: Maximum size allowed by XML schema for phone number international codes was smaller than Banner value for international codes.

Resolution: For variables based on the rco_telephone type, the InternationalCountryCode element is now populated with NULL instead of the Banner international code from the SPRADDR table.

gokpar1.sql (#1-DH14K)Description: This process had implicit inserts that needed to be changed to include the table columns in the insert.

Impact: The table columns were added to the insert.

Resolution: This process now functions correctly.

gokcmpk1.sql (#1-69KK1)Description: There was a performance impact due to Cost-Based Optimizer.

Impact: When moving to Cost-Based Optimizer, users may experience performance problems with the Common Matching process. This performance issue may be experienced in GOAMTCH and batch load processes.

Resolution: Added hints to 3 main queries to use the rule hint instead of CBO.

gokisql1.sql (#1-BBUQ3)Description: This package caused performance issues for the SQL in the rule which had group by clauses.

Impact: The ICGORLDI batch process for LDI performed poorly.

Resolution: A new function was added to parse the SQL string and to add a PIDM clause next to the Select clause.


Section 12 Problem Resolutions Miscellaneous Scripts and Packages

SunGard Higher Education4 Country View RoadMalvern, PA 19355

1-800-223-7036www.sungardhe.com


may 2006 release 7 - ogeechee technical college business information this documentation is...

Documents