III and Banner: Making the Data Work for You Barbara Kriigel and Patrick Armatis University of Michigan--Dearborn

n 8,000 students n Commuter campus n Banner went live for fall 1997 term (Student and Financial Aid) n Implemented GUI, version n Currently running 3.1 n Library participated in implementation and continues to participate post-imp

Banner n Made up of a number of primary systems u Student, Alumni/Development, Finance, Financial Aid, Human Resources, etc. n Each primary system is comprised of application modules u Ex. Student system has recruiting, admissions, registration, general person, etc. n Each application module has associated forms (screens) u windows group fields of related information

Banner Security n Security can be placed at a variety of levels depending on user’s need u system level, application level, form level-- UMD goes to application/form level n User “rights” can be set at various levels u query only, query/update, query/update/delete n Be restrictive in assigning security levels and add additional “rights” as necessary u UMD experienced significant paranoia in allowing access to Banner

Banner Forms n Validation Forms u define values which can be entered in specific fields n Rule/Control Forms u define rules which impact processing on other forms n Application Forms u where you enter, update or view information n Query Forms u view information only

Banner Form Names 7-LETTER FORM NAMES SOAHOLD (form to place/release a hold) SOAHOLD (form to place/release a hold) n Position 1-- primary system owning form u S=Student, A=Alumni, F=Fin., R=Fin. Aid, etc. n Position 2 -- application module owning form u O=Overall, A=Admissions, P=Person, etc. n Position 3 -- type of form, report, process or table u A=Application, Q=Query, V=Validation, etc. n Positions name for form, process, etc. u HOLD, ZIPC, CNTY, etc.

Forms & Data Relevant to Library n HOLDS u SOAHOLD -- place/release a hold u STVHLLD -- defines hold codes, description of code, and what restrictions are associated with code F registration, enrollment verification, transcript, graduation, grades, accounts receivable can be blocked n REGISTRATION u SFAREGQ -- list of courses (by term) for which a student registered

Forms & Data Relevant to Library (cont) n IDENTIFICATION FORM u SPAIDEN -- name(s), address(es), phone(s) n COMMENT FORM u SPACMNT -- any kind of information can be stored in a comment field; UMD stores library barcode in a comment field u STVCMTT -- define comment codes, description of code n DEGREE SUMMARY FORM u SHADGMQ -- Graduation status & term

Forms & Data Relevant to Library (cont) n FACULTY INFORMATION FORM u SIAINST -- status, category, staff type, college, dept, etc. F UMD uses info to assign ptype, privileges, etc. in III n ADDRESS u GOAEMAL -- addresses (preferred), unique names, etc. u GTVEMAL -- defines codes, description of code

Forms & Data Relevant to Library (cont) n Personal Menu u GUAPMNU F user defines list of forms included on menu F helps eliminate need to know 7-letter form name or clicking through menus F helps provide security u UMD Circulation staff personal menu F SOAHOLD, SIAINST, SPAIDEN, SPACMNT, SFAREGQ, GOAEMAL, SHADGMQ, GUAPMNU

Future Areas of Interest to Library n Accounts Receivable n Financial Aid for library student workers n Fund raising/donors in Alumni

Placing Holds n Create a III file of patrons who need holds u print list with Banner ID (ID, SSN) and name u script can be written to automatically place hold n Place Hold u Search ID/Name, verify that hold does not exist, select type of hold (ex. LB), use today’s date as “FROM” and default date for “TO”, add originator code (ex. LIBR), save, rollback/exit u UMD not using reason for hold or amount

Releasing Holds n Retrieve patron Banner record n Change “TO” date to current date and save u as soon as record is saved, all restrictions associated with hold are released n Can temporarily release hold by changing “FROM” date to a future date n WARNING: Anyone with update access to SOAHOLD can place/release ANY hold

Creating an III Patron File

Why create your own queries? n Library can create/update patron file as often as necessary u on old system, ITS staff created file as their time allowed n Data is up-to-date and accurate u less hand-keying by library staff n Library controls content and format of data in patron record

Creating a Patron File n Locate where data is stored in Banner n Create a Microsoft Access query u library staff attended Access training sessions u other SQL software packages are available; use package commonly used by institution n Convert data into format for III n Load data in III

Locate Data n Data may be in an Oracle table different than the Banner form where you view the data--Banner form usually consists of multiple Oracle tables n Using the Dynamic Help Query to determine table name of data n Banner form data may be “calculated” at time of viewing and thereby not available on the Oracle tables

Creating an Access Query n Linking Tables u data is scattered across several tables, linking the tables together creates a new table which contains only specified information n PIDM (Personal Identification Master) u unique number assigned when a “general person” record is created (equivalent to III’s patron record number) u found on all Oracle tables u does not display in Banner anywhere

Creating an Access Query (cont) n Selecting the data from tables u select all information needed u each data element is located in it’s own field (ie last, first and middle name) u different data “types” are stored in the same table (ie permanent, business, mailing addresses u indicators F Change - denotes previous data F Primary - denotes preferred data F Inactive - denotes expired data

Creating an Access Query (cont) n De-duping u check for dups (duplicates) while building query in order to determine: F why dup occurred (missing indicator, duplicate record in Banner) F can dup be prevented (use indicator, create separate query, multiple linking) u change query to prevent dup F if dup can’t be prevented, decide if data is necessary

Creating an Access Query (cont) n Adding subsequent tables u link next table and check results (dups, correct info, etc) u sometimes necessary to go back and change earlier query n Running queries u can be time consuming depending on system usage, hardware, software, query logic, etc. u results may vary since Banner is real time system

Creating an Access Query (cont) n Tips for creating queries (Lessons learned the hard way) u start with one table at a time u for complicated tables (ie address, phone) create simple query which contains only data type you desire u create one “master” query that uses table of PIDMs to extract all necessary data u use macros to import and export data, run queries, etc.

Result 36 Banner data elements (from 9 oracle tables and 4 mapping tables) 13 III patron fields

Converting Data n III format options for importing patron data u MARC u 80-Column Punched Card Image u Text File Image u Text File Image with RECORD label u Other formats possible (contact III) F comma delimited

Load Data n FTS/FTP data into III n Load the Patron Records u Read/Write Marc records n Check the error log and make corrections u patron record in use by system

How Much Time is Spent? n The entire process (querying, converting, loading and making corrections) takes 30 minutes at UMD n Time varies depending on system usage, full load vs partial load, etc.

Synchronizing Holds between Banner and III n Create Access query to compare holds in Banner and III u verify that everyone who should be on hold is actually on hold and vice versa n Place and release holds as necessary

Script to Automatically Place Holds in Banner n “Create a list” in III of patron records who meet criteria n “List” desired data to a file n Convert III data to comma delimited file n Load file into Access and update LB_HOLD Oracle table n Login to server and run script n View LB_HOLD Oracle table for results (ie holds placed, patrons not found)

Questions?????? Presentation available at: Barbara Kriigel 313/ / Patrick Armatis 313/ /