1 / 30

III and Banner: Making the Data Work for You

III and Banner: Making the Data Work for You. Barbara Kriigel and Patrick Armatis University of Michigan--Dearborn. University of Michigan--Dearborn. 8,000 students Commuter campus Banner went live for fall 1997 term (Student and Financial Aid) Implemented GUI, version 2.1.5

emile
Download Presentation

III and Banner: Making the Data Work for You

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. University of Michigan--Dearborn • 8,000 students • Commuter campus • Banner went live for fall 1997 term (Student and Financial Aid) • Implemented GUI, version 2.1.5 • Currently running 3.1 • Library participated in implementation and continues to participate post-imp

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

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

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

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

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

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

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

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

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

  12. Placing Holds • Create a III file of patrons who need holds • print list with Banner ID (ID, SSN) and name • script can be written to automatically place hold • Place Hold • 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 • UMD not using reason for hold or amount

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

  14. Creating an III Patron File

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

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

  17. Locate Data • 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 • Using the Dynamic Help Query to determine table name of data • Banner form data may be “calculated” at time of viewing and thereby not available on the Oracle tables

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

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

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

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

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

  23. Result36 Banner data elements (from 9 oracle tables and 4 mapping tables) 13 III patron fields

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

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

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

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

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

  29. Questions?????? Presentation available at: http://www.umd.umich.edu/lib/iug Barbara Kriigel bkriigel@umich.edu 313/593-5614 Patrick Armatis parmatis@umich.edu 313/593-5564

More Related