This is an update to Tracey's message from yesterday. See added items 4.1
and 4.2 for information on two order record conversion errors which affect
status displays on the Order List. ... KA
Conversion overview
For the record, the conversion of data from HOLLIS to Aleph included:
Bibs 10,380,352
Holdings 11,028,704
Items 8,327,506
Orders 172,750
As well as records for patrons, loans, vendors, and funds.
Total bytes converted: 32,276,693,124
Conversion Maps
Conversion maps have been prepared for all HOLLIS to ALEPH data elements.
These maps show where HOLLIS data was converted to and from where ALEPH data was
derived. They are being put up on the OIS Web Site. Some maps are
already posted, the remaining maps will be available in the next day or two.
Although these maps do not give all conversion values, they serve as a guide to
locating information, which formerly resided in HOLLIS.
Conversion problems/issues
In general the conversion of the data from HULPR to Aleph was a grand success
and a huge accomplishment, HOWEVER, there are a few issues and problems that we
want to bring to your attention. If you discover conversion problems not
listed below, please report them through the Aleph Support Center at: http://hul.harvard.edu/ois/systems/aleph/support.html
1. Collections Codes:
A small number of collection codes ($c) from HULPR did not convert correctly
to the Aleph Collection codes in the Holdings record 852 $c. In cases where
the HULPR collection did not convert, the collection code "ERROR" was converted
to the 852 $c. OIS has begun a clean up project for these collection codes.
If your library has been affected by this problem, someone from OIS will contact
you to alert you to the problem.
2. Received orders:
For orders that were completely received through HULPR, orders were not converted
and item records were not created. Instead, we created a holdings record
with an 852 $z (Public display note) with the phrase "ordered received"
to alert the public that the material had been ordered and received but not
yet been cataloged. One oversight was that "ordered-received" notes
were NOT created for any inactive orders that had been weeded from HULPR.
HULPR Records with LOC subfields g , s, or n, giving location and
status information, converted properly to 852 subfield z in the Aleph Holdings
record.
3. Patrons
3.1. PATRONS WITH RE-ISSUE DIGITS.
All patrons have an Aleph "Patron ID" (system id), a single
active "Barcode" (type '01') and possibly one or more "Additional
ID's". Most patrons with Additional ID's are those who have been issued multiple
Harvard ID's. The last digit of the Harvard ID is known as the re-issue
digit, and it is incremented whenever the ID is replaced (most commonly, after
being reported lost or stolen). If any items were still charged to the earlier
ID's at the time we converted to Aleph, these ID's, while expired or otherwise
invalid, were converted as well. Therefore, on Day One, the system will recognize
these ID's when scanned into the Patron Bar.
PLEASE NOTE, however: when you attempt to loan an item to the patron, the
earliest barcode is the one that was converted to the active "Barcode"
field. In this case, the system will produce a message that the id has expired
and will require an override to loan the item unless the patron record is modified
per instructions below. An additional problem with this is that
patrons holding these id's will not be able to use their PINs to perform reader
empowerment functions in the OPAC.
OIS is looking into programmatically addressing this issue; for now there are
the following options:
·Use
the override function and the loan will be processed properly.
·Manually
correct the patron record so that the barcode with the highest re-issue digit
is the active "barcode". Follow these steps:
a) Open the Global Information for the patron and go to the Additional
Ids tab. Note the highest re-issue digit.
b) Change the '01' Barcode type to barcode with the highest re-issue digit
by going to the tab labeled "1. Patron Information" and changing
the Barcode: field. Although it doesn't matter whether you also
change the verification field (it is not actually used by the system), for
consistency, we recommend that you do change the verification field as well.
c) The earlier barcodes can be deleted by going back to the Addition Ids
tab. [If they are changed to Not Active (NA) the system still allows charges
to the record; therefore, we recommend that you delete them because they
are most likely to be invalid (lost, stolen) id's. Loans, holds and
cash transactions are all associated with a patron via the Aleph PATRON
ID (as opposed to the individual barcode) so no loans, holds and cash will
be lost.]
3.2. EXPIRATION DATES ON SOME PSEUDO-PATRONS AND SPECIAL BORROWER RECORDS
Due to inconsistencies with how these were coded in HOLLIS, many pseudopatrons
and special borrowers that should still be active were converted with the conversion
date in the expiration date field of the sublibrary's local borrower record.
From what we have seen, in most cases, the "ALEPH" local user expires
on 09/09/09, but the sublibrary-specific local borrower record is expired.
If a loan against one of these records is attempted, the system will disallow
the loan.
Rather than overriding the loan, we suggest going to the sublibrary-specific local
borrower record (scroll through the list of sublibraries on the local user record
until you see yours), click the "Get defaults" button, verify the expiration
date and the click "Update." Aleph does not allow the term
"INDEF" as a valid date; therefore, you will need to choose a valid
date.
3.3.CHARGES TO LOST PSEUDOPATRONS All items that had been charged in HULPR to a pseudo-patron representing "Lost",
were converted to Aleph with a Loan status =LOST and an Item Processing Status=MI.
Wherever possible, items were converted with the tracking information that associates
the lost item with the patron who lost the book. Thus, these loans have
essentially been migrated to the original borrower, with the loan status changed
to "Lost" and the Item Processing status changed to "MI".
If the tracking information wasn't available because it wasn't on the charge record
in HOLLIS, then the item WILL be charged to a pseudo-patron which represents "Lost".
For this reason, a long 'has' list in HULPR for a Lost pseudopatron is likely
to result in a much shorter list in Aleph.
3.4. Converted Patron record problems We have identified 246 converted patron records in Aleph that have a Patron
ID that is the same as a Patron Barcode on another record. Scanning these
patron barcodes results in retrieval of the wrong patron. We are asking
your assistance in manually fixing these as soon as you can. Please be assured
that to the best of our knowledge, loans to these patrons are intact.
Aleph will prevent future instances of this in newly created records, but to be
sure about this, we are also asking units to dispose of certain unused barcodes
(see below).
A list of the problematic records is on the OIS Web site; below are the instructions
for fixing them. Please let me know if you have any questions. We
regret the inconvenience and appreciate your assistance in addressing this in
a timely manner.
1) In Aleph, locate the pseudopatron or special borrower by NAME (not by either
number) as provided in the attached list.
2) When you have located the Patron record in the Aleph patron list, do NOT click
select. Instead, click once on the User ID column and press <cntl>
c to copy the User ID.
3) Close the patron list. Clear the Patron bar and enter the copied User ID into
the patron bar (this is the only place it will be brought up properly - don't
enter from user list).
4) Now you have the patron record. Click on the Global Information tab.
The "Barcode" and the "Barcode verification" fields must be
replaced with a new barcode. For pseudopatrons, this should be relatively
straightforward. It will be more problematic for the handful of special
borrowers that are in the list, as they will need to be re-issued new special
borrower barcodes. Some of these appear to be expired and would not have
converted if they didn't have any loans
All problematic records are 8-Digit Type 'A' Barcodes. Use replacement
barcodes that are higher than 00400000. If you do not have any of these,
please let Martha Creedon know. If you have any barcodes in the range under
00400000, please let Martha know and then dispose of them.
4.1 ARRIVAL STATUS ON CONVERTED ORDERS
Arrival Status codes were converted incorrectly. This coding error affects
the display of Arr St on the Order List. Arr St will only change if arrival
is recorded via the Arrivals button. The Arr St display will not change
if you record arrival as part of the invoice payment process (by clicking on YES
when asked "Would you like to record the material as having arrived?).
Note that an arrival record is made in these cases but the display does not change.
You can force Arr St to change by clicking on Arrivals button then Modify to display
the arrival that was created. Click on OK to save it and the Arr St on Order
List will change.
We are working on a fix for this problem (which we hope will also correct display
for arrivals recorded since July 8).
For now, we recommend recording arrivals via the Arrivals button.
4.1 INVOICE STATUS ON CONVERTED ORDERS
Invoice Status codes were converted incorrectly. This coding error affects
the display of Inv St on the Order List. It will not change when you create
an invoice. There is no way to force this to change as there is for Arr
St.
We are working on a fix for this problem (which we hope will also correct display
for invoices created since July 8).
Tracey Robinson
Head, Office for Information Systems
Harvard University Library
Cambridge, MA 02138