Cornell University Library Voyager Implementation Site    

Voyager Access Services Implementation Committee
Patron Database Subcommittee
Meeting, Monday, December 13

Present: Peter Hoyt, Joel Zumoff, Howard Raskin, Sara Spoonhower, Susan Currie

We reviewed the specs for the SIF that Peter had prepared in preparation for our 11:00 AM conference call with Marlene Harris from Endeavor. Susan gave a quick overview of the patron functions in Voyager. Patrons can be searched by barcode (charge ID), institution ID (will be our employee ID), SSN and name. Once again, we will need to use the term patron barcode to replace our current terminology of Charge ID even though the majority of the ID numbers we process are on a magnetic stripe on the ID.

Questions and answers from our talk included:

1. A question about the library location code of 10 characters "as defined by library in System Administration" During our talk with Marlene, she stated that this field should be blank..

2. We asked for an explanation of how the HOLD and Protect fields work in the patron file. First, all patrons must have a permanent address which is the first address entered. There are fields also for e-mail and temporary addresses both of which must have effective dates. If the patron wants mail held for a particular address, the HOLD button is checked. Hold should NOT be checked for the permanent address. The PROTECT button will protect an address field when the patron file is updated (if we don't want the address overwritten). When sending notices, the system checks addresses in the following order: e-mail, temporary, permanent. The system checks each address for effective dates and to see if the HOLD mail box is checked. If the current date is between the effective dates and the HOLD mail button is not checked, the system will use that address. So, if the e-mail address is checked HOLD, it will not be used or if the e-mail address has an effective date range of Jan 24 - May 17, and the notice is generated June 1st, the e-mail address will not be used.

3. We established that we want to use the first 3 statistical category fields to store the CU, RE, PE information.

4. Joel asked for a clarification of how the Institution ID and the SSN interact with the barcode. Marlene will investigate further and get back to us. We did confirm that we MUST have a unique institution ID for EVERY record. From Marlene:

"The purpose of this field is for matching during patron updates. Patron records loaded during the initial patron load or any patron update load must have one field or the other non-blank and unique for each patron. Records with blank SSAN and ID fields will not load, records with non-unique fields will update the record they match. It is not a requirement for the system that records created in-house have either the SSAN or Inst. ID filled in, but if both are blank, the record created in-house can NEVER be updated in a patron update load. If a patron record in a patron update load duplicates a record already in the system that has a blank SSAN or Inst. ID, a second patron record will be loaded for the patron."

Peter and Joel confirmed that we can use the unique part of each charge ID (888....etc.) as the unique number for records we create. Peter thought it would not be too difficult to pull that unique number and have it put into the patron records in NOTIS prior to the actual migration.

Marlene and Peter discussed specifics of loading patron records in the Oracle database.

5. We discussed the situations where we might want to have multiple barcodes (For example, a student is hired as a staff person). Patrons cannot have two active barcodes at one time if they are in the same patron group. We will start with ONE active barcode per patron and leave the others blank. We asked if Voyager overlays records in the case of lost ID's where the Registrar simply changes the last digit on the ID to indicate the number of cards issued to a student. We think that in the case of lost ID's, the old barcode will be changed to the new one but we will want to verify this with Marlene. We need to be aware of semantics when talking about either NOTIS or Voyager--talking about Voyager patron groups can be confusing since we are used to NOTIS patron groups as the origin of the record (PE, RE, CU).

6. We talked briefly about item statuses. During our data extract, two sets of files will be left on our NOTIS server--one for creating our new database and one of all data logged including item statuses that we specify. Then, those item statuses can be printed for us to review and update records in Voyager. The best thing for us to do is to decide now how to use item conditions in NOTIS that we know will migrate to Voyager. Also, we will have to decide how to move items charged to pseudopatrons to item conditions. For Bind, Lost, Missing, this is fairly simple. For Dept and Proc, it is harder.

7. We talked a bit about reserve locations and circulation policy groups. The parameters we should keep in mind when setting this up include the return address on notices, calendars, intervals for sending out notices, etc. Marlene noted that because we have done a lot of the work in NOTIS for simplifying this, we will be in pretty good shape for setting up policy groups in Voyager. However, there is still considerable work to be done in circulation policy and configuration set up.

- Library Management System Implementation Site - Cornell University Library - Ithaca NY -
last modified on: December 21, 1999