Endeavor Implementation
Project > Contract Status:
>Tasks and Issues Remaining
>Acceptance and Payment in the Agreement between UH and EISI
>Development Requirements in the Agreement between UH and EISI
>System Performance Acceptance Test in the Agreement between UH and EISI
Endeavor Implementation Project
Contract Status
Tasks and Issues Remaining
- Endeavor (EISI) to perform work to enable direct link to Hawaii Pacific Journal Index (HPJI) without need to access it via the path UH Shared Database : Other Libraries : Citation Databases. [Migration of HPJI data to a citation database has been accepted by UH.]
- EISI to deliver Unicode language features, including CJK (Phases 1 and 2). Display of 88x field data due in Voyager 2000 remains problematic. [UH is a development partner with EISI in this project.]
Unicode (CJK) - This project will require major input from Technical
and Public Services. Although this project is thought of as CJK, it
should be called Unicode because it involves all languges with different
characters and not just CJK. Phase I involves the displaying of CJK
characters (880 field). Phase II involves mapping the current database to
the Unicode character sets and a rewriting of the Cataloging Client
Module to allow inputting of special characters. There will be a test
database in Endeavor to allow evaluation of special characters such as
Hawaiian, Thai, Greek, etc. November 20, 2001, is the deadline for UH to
submit test records to Endeavor (most records will be CJK but also include
other languages). K. T. Yao is the contact person for the Unicode
Project. Phase III involves the "searching" phase during which Public
Services will evaluate whether diacritics can be searched and retrieved.
For the testing of Unicode, two methods will be available: (1) a glyph
server will display CJK script below the roman alphabet version of a CJK
bid record and (2) a second database equipped with Unicode fonts has yet
to be created but which will require Windows 2000 or later (like XP)
because only they are Unicode compliant. An important consideration about
the Unicode Project to remember: Unicode is NOT an option; failure to
adopt Unicode will mean no future Endeavor upgrades. According to our
contractual agreement with Endeavor, UH is a development partner, but not
a beta site; a beta site requires a separate test server which we do not
have.
Approximate timeline for the Unicode Project:
Phase I - CJK will be tested primarily from November and be ongoing
Phase II - General specifications due mid-January 2002; Technical
specifications due mid-March 2002; Project ongoing April through August
2002 (testing will occur); Beta release projected for Fall 2002
- EISI to resolve ADA non-accessibility issues in WebVoyage [Bobby test: main problem is missing "alt" tags for images.]
- EISI and UH to discuss disputes regarding EISI functionality as stated in its RFP proposal. [Disputes to be listed in final report by UH.]
- UH will likely not do a performance test as part of acceptance. Response times appear to be satisfactory for the way the system is used now.
Acceptance and Payment in the Agreement between UH and EISI
IV. ACCEPTANCE AND PAYMENT
A. This Agreement shall be effective upon the date of the last
signature of this Agreement.
B. Acceptance of the SOFTWARE is defined as the following:
CUSTOMER shall have a period of forty-five (45) days following
successful final migration of CUSTOMER's records as listed in Appendix
B-3 to validate that the SOFTWARE provides the functions described in
ENDEAVOR's response to CUSTOMER's RFP as currently available and
described in Appendix A and complies with ENDEAVOR's published
documentation listed in Appendix D and that such functions are
successfully operating in the CUSTOMER's environment.
An explicit condition for the beginning of the acceptance period is the
successful installation into the CUSTOMER's environment of Release 2000
of the SOFTWARE. Within this period, and considered to be a condition
of acceptance, CUSTOMER will also conduct a performance test as
described in Appendix J.
At the end of this forty-five (45) day period, the CUSTOMER shall submit
in writing a letter accepting the system or a list denoting any
significant discrepancy between the operation of a feature and the
product documentation. If written notice is not received by ENDEAVOR
within ten business days of the end of the forty-five (45) day period,
CUSTOMER will be deemed to have accepted the SOFTWARE.
ENDEAVOR shall have sixty (60) days to correct any reported discrepancy
or to reach agreement with CUSTOMER on the functionality. CUSTOMER
shall have forty-five (45) days to test corrections. If the discrepancy
has not been corrected, at the mutual agreement of both parties, the
sixty (60) day period to correct and the forty-five (45) day period to
verify the correction may be repeated until the discrepancy is corrected
and the system is accepted in writing.
If ENDEAVOR is unable to satisfactorily make such corrections, and if
any uncorrected discrepancy shall materially inhibit the CUSTOMER's
production usage of the SOFTWARE, then CUSTOMER shall have the option to
terminate this Agreement, return the SOFTWARE and related documentation
to ENDEAVOR, and receive a prompt and full refund of any SOFTWARE
license fees and service fees paid hereunder, with the exception of
actual travel expenses.
C. CUSTOMER agrees to pay License Fees for the SOFTWARE products as
described in Appendix B-1 according to the payment schedule shown there.
D. Tax Clearance for Final Payment
[Not reproduced here]
V. COOPERATIVE DEVELOPMENT
A. As an integral part of this Agreement, ENDEAVOR and CUSTOMER agree
to work together to design and implement support for the Chinese,
Japanese and Korean and other non-Roman character sets within the
SOFTWARE. The focus of these enhancements is the support of these
non-Roman character sets within bibliographic records through the use of
Unicode. The exact scope of the enhancements will be decided during the
cooperative development process, but is tentatively envisioned as a
phased project, including the following phases:
Phase I: Display of Non-Roman Characters in Public Access (Release
2000) The first phase of the project will map characters from existing
database records into Unicode for public display. Client platforms
supported will be a web browser and Windows NT client. Searching for
these records will use the transliterated fields, but displays will
include the vernacular. Non-Roman characters will display in the Web
with the appropriate character representations if the user has
downloaded the correct fonts.
ENDEAVOR will use UTF8 encoding for the Unicode character
representations. The Public Access API will include a font set
identification. If the client is not capable of accepting Unicode,
characters will be transmitted in the Latin I character set.
The display mapping for this phase applies to all "left-to-right"
languages. (Note that Arabic and Hebrew are included in a separate
phase.)
Phase II: Keyboard Input and Editing of CJK Characters (Release 2001)
This phase will allow for character input and editing by displaying a
virtual keyboard on the monitor or by using a US keyboard and mapping
characters to another script. (These mechanisms are similar to those
currently employed in the SOFTWARE for support of the ALA Extended
Character Set.) This non-Roman character input and editing will require
the Windows NT client operating system. Another portion of this phase
will involve character mapping for online import, bulk import, and
record export.
Phase III: Sorting and Searching of Non-Roman Scripts (tentatively
Release 2001) The third phase of Unicode implementation will involve the
development of algorithms to provide culturally accurate sorting of
non-Roman characters. This project will encompass normalization for both
indexing and searching. Note that currently, Unicode supports unified
Han. Mapping between EACC and Unicode is not yet finalized. ENDEAVOR
will implement CJK Unicode from the MARBI draft and adopt the final
mapping when it is accepted by MARBI.
Phase IV: Support for Bi-Directional Languages (tentatively Release
2002) As mentioned under Phase I, bi-directional languages such as
Hebrew and Arabic will also be supported. This phase includes display
mapping, character input and editing, as well as sorting and searching
of bi-directional languages.
This cooperative development effort will result in changes being made to
the generic version of the SOFTWARE. ENDEAVOR shall have full ownership
rights to the changes. These changes are not made as works for hire.
Additional customers may be involved in this cooperative development
effort. CUSTOMER agrees to work as part of a group and to provide input
appropriate for libraries of equivalent size and complexity through the
course of the project.
B. CUSTOMER has made requests for functional enhancements to the
SOFTWARE. Those requests and ENDEAVOR'S responses are detailed in
Appendix I. Those enhancements listed as being part of Release 2000 are
a payment milestone for CUSTOMER and those functions must be supplied
before CUSTOMER makes that milestone payment. Additional further
enhancements, including those listed in Appendix I as being provided as
part of Release 2001 of the SOFTWARE, are explicitly not required as
conditions of acceptance of the SOFTWARE or condition of payment.
Development Requirements in the Agreement between UH and EISI
APPENDIX I
University of Hawaii Endeavor Voyager Development Requirements And
Endeavor's Response
December 9, 1999
This Appendix has two main sections:
Section A. Complete List of CUSTOMER Development Requirements and
ENDEAVOR's responses.
Section B. Summary of those CUSTOMER Development
Requirements to be part of Release 2000.
Section A. Complete List of CUSTOMER Development Requirements and
ENDEAVOR's responses. Web OPAC
Priority 1 (ordered)
1. Limits in effect to be displayed on search screen and results
screen. (Limiting)
Response: Release 2000. This enhancement is included in the next
release.
2. Display next expected issue(s) of a serial and claimed status of
an issue. (Search Results)
Response: This enhancement is not currently scheduled. In recent work
with a task force of acquisitions and serials staff, this was not rated
highly.
3. Ability to search for a specific volume and issue of a serial.
(Searching)
Response: Partially available. It is possible in the Request function
for a user to place a request for a specific volume of a serial if those
volume have been barcoded. The Request function allows the display of
the complete list of items attached to a holding record in order to
support request for a specific volume of a serial.
It is also possible to display all received issues in the OPAC. Issues
are displayed in reverse chronological order so that the latest received
issues are displayed first.
4. Ability to combine search sets in a search history search.
(Searching)
Response: This feature will be a part of Release 2001.
5. Proximity options. (Searching)
Response: Partially available. There are currently no plans to
implement explicit proximity options. However, the relevance searching
algorithm included implicit proximity searching. The relevance ranking
is higher when the words are close to each other.
It is also possible to do exact phrase searching. The use of quotation
marks to create a bound phrase is supported in keyword searching. The
"as a phrase" option is supported in the Builder (complex) search type.
6. Ability to mark records on unlimited number of pages before
saving. (Marking and Output)
Response: Release 2000. The next release will include this
enhancement.
Priority 2 (unordered)
7. Ability for user to apply limits to search results and re-execute
the search. (Limiting)
Response: Release 2000. This enhancement is being added in the next
release. Users will be able to do the current limiting before the
search and will also be able to apply limits after the search and
reexecute.
8. System to retain limits for searches re-executed from the search
history. (Limiting)
Response: This enhancement is not currently scheduled.
9. Ability for user to define (or override default) sort order for
search results. (Sorting)
Response: Release 2000. The user will be able to resort search
results in the next release.
10. Ability to sort on fields including, but not limited to, author,
title, publication date, location, call number. (Sorting)
Response: Partially in Release 2000. In the next release of Voyager,
the end user will be able to resort by author, title and date (both
ascending and descending).
11. Ability to have format options for export of records (including
full or brief record, and Endnote and/or ProCite) (Marking and Output)
Response: Release 2000. It is possible today for the library to define
the output format. With Release 2000, it will be possible to define
multiple (up to 10) output formats, which will be presented to the user
in a dropdown menu.
12. Ability to create a personal list (with sort options) before
export. (Marking and Output)
Response: Partially available. It is currently possible for a user to
mark just some of the results on a page and download just the marked
records. With Release 2000, it will be possible to mark records
throughout the complete search results and download all marked records
with a single command.
13. Ability to "jump to" a record in the search results list.
(Navigation)
Response: Release 2000. The display and use of jump bars will be
supported in the next release.
14. Ability to disable or override the relevance ranking. (Search
Results)
Response: Currently available. It is currently possible to enable or
disable relevance ranking for both keyword searching and for complex
searching. This is a library option, allowing the library to decide
where to offer relevance ranking and to then create bibliographic
instruction materials.
15. Search window available on every screen. (Search Results)
Response: Currently available. The search button appears on every
screen, allowing a user to initiate a new search from any step. In
addition in Release 2000, the search entry box with the text originally
entered by the user will appear on the results screen, making it easy
and apparent to the user how to modify the search.
16. Left and internal truncation options. (Searching)
Response: These searching options are planned, but are not yet
scheduled for a specific release.
17. Stop word list for English language initial articles so that they
are disregarded in title searches, regardless of how they were tagged in
the MARC record. (Searching)
Response: Voyager does not specifically employ "stopwords" per se.
Stopwords as used in legacy applications reject a search that includes
those words. Instead, Voyager keyword searching uses the "noise word"
technique, which filters out the very common words without rejecting the
search. The stop words can thus be used for bound phrase searches, such
as "Vitamin A", but are ignored for most searches.
18. Breakdown of multi-term search results, i.e. display which terms
do not co-exist. (Searching)
Response: This enhancement is not currently planned.
19. Ability to search on status of item, i.e. available copies only.
(Searching)
Response: Partial with Release 2000. Rather than make the user ask for
availability, in Release 2000 Endeavor will automatically display an
availability indicator on the index screen.
Circulation
Priority 1 (ordered)
1. When returning a lost book, must have the ability to have the
lost charge deducted while leaving the processing fee on the record, and
ability to generate notice of refund due if fine already paid.
Response: Release 2001. This is a requested enhancement and it will be
included in Release 2001.
2. Universal borrower ability if we have separate patron files to
be able to permit staff to view/copy the patron record from other UH
institutions and to view delinquencies from other UH institutions.
Response: This capability is currently in development for delivery at
the end of 2000. However, there is an additional cost for this feature.
For the system outlined in the Agreement, the Universal Borrowing
application will be offered at the UniversityÕs option for a fee of
$35,000.
3. Ability to trace/search an item and attach it to a patron
record with the ability to send notification to the patron on a regular
cycle.
Response: Currently available. There are two current options for this.
If the patron is looking for an item that is not charged to another
patron, but is not on the shelf, the operator can place a hold for the
user. That will provide continuous tracking for the user and allows the
generation of a report on "old unfilled holds" for the staff.
If the patron claims to have returned the item, setting the item status
to "claims returned" allows the library staff to create a report of
items with that status, which can serve as a tracking report.
4. Ability to change information that displays on the Charge
screen (currently not enough information displays on initial screen).
Alternative: make the patron address screen the default.
Response: While the patron address information is available with a
single click, we understand that the University wishes to have it
displayed directly on the charge screen. Endeavor commits to making
this change for Release 2001.
The initial charge screen currently shows the amount of fines, the
number of items charged, the number of holds trapped, the number of
holds in que, and the number of notes in the patron record. There is
also an indication if this is a proxy patron.
The overdue status on an item currently displays in the patron
information list in the Web opac, as well as on the display of the list
of items charged in circulation.
5. Ability to have multiple holds/recalls on an item and have the
loan period automatically shortened.
Response: Currently available for recalls. This capability exists
today for recalls. Voyager views holds as a passive request and does
not support shortening the loan period for holds.
Priority 2 (unordered)
6. Ability to identify a proxy borrower when selected from a
browse list.
Response: The proxy indicator appears on the charge screen when the
patron identifier is scanned and on any screen where the patron
information is entered (such as the hold screen).
7. Block editing of a holdings record if the item is charged out.
Response: This is not supported. Voyager users feel that it is an
advantage to be able to do maintenance on records while the item is
charged. Of course, the item may not be deleted while charged.
8. Ability to set the system to track the last three borrowers
that HAD the item charged out.
Response: Partially available. Today there is an option to track all
borrowers who have had the item or not to track which borrowers have had
the item. We are willing to consider the change that is suggested
here, which we interpret to mean that only a limited amount of data on
the past borrowers would be retained.
9. Attach a claims returned status to a patron record and have
the ability to clear the status from the patron record.
Response: Currently available. We believe this is a semantic issue.
Voyager supports the ability to set and remove a claims returned status
on any item record, including when the record is charged to a patron.
Rather than marking the patron, who may have a number of items charged,
the status is set on the item record(s).
10. Ability to print notices on demand or automatically on system
set time frames.
Response: Currently available. Voyager employs a number of techniques
to facilitate this. Notices are initially generated at the server and
are automatically dispersed to the appropriate site for printing. The
notice job may be run at the server as often and as frequently as
desired. This job can be set to run automatically by placing it on a
chron tab.
Once sent to the printer, the notices may be printed at the locationÕs
option. This can also be automatically scheduled.
11. Ability to view selected transactions on a patron's record
defined by type of transaction (i.e. overdue, reserve, charges, fees)
Response: Currently available. Voyager displays icons on the patrons
record for the number of items charged, the number of current holds and
recalls, the number of notes on the patronÕs record, and the amount of
fees. By clicking on any one of these icons, the operator sees the
detail. The number of items overdue is part of the display of the
number of items charged.
12. Ability to place patron placed item level and title level
holds.
Response: Currently available. We interpret this to mean that the end
user should be able to place both title level and item level holds and
recalls through the public catalog. This is currently supported in the
Request dialog for a hold or a recall and even for a call slip.
Priority 3 (unordered)
13. Ability to link temporary conversion records to full bib
records without re-keying data.
Response: Currently supported. The cataloging function of Voyager
supports a relink function which allows for the unlinking of holds and
item data from a temporary or incomplete bibliographic record and the
relinking of that information to a more complete bibliographic record.
14. Item and patron notes should be automatically date-stamped.
Response: This is not currently available.
15. Ability to print receipts for Charge, Discharge, and Renew
sessions, rather than individual slips per item.
Response: This is not currently supported. Our users have indicated a
preference for a slip for each item.
16. Ability to review receipts on screen prior to printing.
Response: This is not currently available. Our users have indicated
that they do not want to have to view and confirm each slip before
printing.
17. Ability to print multiple copies of multiple page receipts.
Response: Partially available. The type of form used for receipt
printing is determined by the library. If the library wishes to have
multi-part forms for receipts, this can be done.
18. Ability to sort notices by branch, type, and patron type.
Response: Currently available. Notices are automatically sorted by
branch and type by Voyager as they are created and routed to the print
stations. If the library then wishes to have a sort by patron type,
this is possible since notices are stored in Microsoft Access at the
local print stations. The library would create this extra sorting
routine in Access.
Reserve
1. Increase the 999 minute parameter wherever it exists - up to at
least 9999 minutes (which is almost 7 days).
Response: Currently available. Instead of setting the parameter in
minutes for the longer loans, the library is able to set those in hours
or days. This is supported in System Administration, the module where
the parameters are set and maintained.
(It is true that some media scheduling options are set in minutes only,
but you are not licensing media scheduling.)
Electronic Reserves
1. Where charges for online use are assessed (e.g. electronic
reserves, document delivery, anything else with a per delivery/per page
charge associated) - ability to handle subsidies for certain patron
types
Response: This is a planned capability. It is not currently scheduled.
User Fees
1. Ability to apply/charge USAGE (aka "rental") fees _up front_ for
particular combination categories of materials and patrons (this would
be the $3.00 fee to CC libraries and $23 fee to other borrowers of
videos)
Response: Currently available in Media Scheduling. This capability
exists within our Media Scheduling module.
User Initiated Services
1. Ability to generate automatic email confirmations for patron
placed functions (esp. renewals, short loan requests)
Response: This is not currently supported. The public catalog does
display a renewal indicator on the list of charged items as soon as the
renewal is successful. We feel this is a more direct method of
notification.
Cataloging
Priority 1 (ordered)
1. Ability to index and search CJK scripts by language-specific
Romanization schemes (with ability to delimit or modify searches using
Romanized CJK words by tone for Chinese; syllable length (long or short
vowel) for Japanese), character components (root graphical parts of the
characters, called "radicals"); ability to link related forms of a
single character (e.g., Chinese traditional, Chinese simplified,
Japanese versions).
Response: Endeavor has a plan for supporting CJK. That plan is
included in the Agreement as a contractual obligation.
2. Ability to input and edit online records in Chinese, Japanese,
Korean.
Response: This is phase II of the CJK plan and it is currently
scheduled to be part of Release 2001.
3. Provision of an user-friendly (natural language, labelled gui)
interface for creation and updating of holdings records for non-serial
multi-part works. That is, we want a gui interface feature for all
formats similar to that provided in the serials control module, which
will not require opening up the serials module. Importance of function:
Lack of a user-friendly interface will negatively impact workflow.
Response: Currently available. The acquisitions portion of the
software supports the creation of records for multi-part works. Also,
both the circulation module and the cataloging module support graphical
creation of multi-part items without requiring the use of the serials
functions.
4. Ability to do offline record input and modification when network
connection to server fails. Importance of function: a) This is
important to the remote sites because network connections have
historically been unstable. b) Important to UHM because we do not want
Collections Services staff idle during downtime.
Response: This is not possible. The data resides on the server. If
the data is not available to the client because the server cannot be
contacted, it is not possible. It is possible to continue to edit a
record on the client if the network or the server becomes unavailable.
It is also possible to import records to the client from CD files or
(depending on the type of telecommunication connection) from OCLC.
These records can then be stored on the client and uploaded when the
server connection is restored.
5. Ability to link directly to related order information and serial
holdings information from within Cataloging function, i.e., not opening
up a separate module window. Importance of function: Having this will
facilitate workflow and troubleshooting (e.g., lost worksheets).
Response: This is being implemented in Release 2000. There will be a
direct link to the order data from the cataloging record.
Priority 2 (ordered)
6. Ability to input and edit other non-Roman script languages: Thai
(top priority), Hindi, other South Asian and Southeast Asian scripts,
Cyrillic (secondary priority).
Response: Our project will address languages beyond CJK in some
prioritized order which is not yet completely determined. We do know
that Cyrillic will be the first language after CJK, but we are open to
discussion of the order following Cyrillic.
7. Incorporate into the validation function, duplication checks
with notification and override capability of International Standard Book
Number (ISBN), International Standard Serial Number (ISSN), and Library
of Congress Card Number (LCCN). Importance of function: a) Will
facilitate precise match points required for automated duplicate check
for batch processes. b) Promotes database accuracy.
Response: Currently available. These fields are currently supported as
part of the deduplication algorithms. The library may set up multiple
deduplication profiles and may utilize different profiles at different
times, both for online maintenance and for batch loading. Up to ten
fields may be included in any particular profile.
8. Provide online alert with option to quit when staff tries to
delete an authority record with links to bibliographic headings.
Response: Currently available. The Voyager database structure includes
a linking table which indicates if (and how many) bibliographic records
are linked to an authority record. This is checked when the operator
attempts to delete an authority record.
9. When a single bibliographic record is linked to item records for
multiple copies or multiple volumes, the system should allow any common
element in these item records to be updated with a single command
instead of doing each individually. Importance of function: Having this
will facilitate workflow.
Response: We understand this requirement. It is currently supported in
certain areas. For example, the call number that displays on an item
record is automatically updated if the call number in the holdings
record is changed. In Release 2001, the location information will also
be automatically updated.
10. Ability to directly access an item record for a particular
volume or copy for editing purposes. For example, to change volume 500
of a thousand-volume series, it should not be necessary to page down
repeatedly; it should be possible to get to volume 500 directly.
Importance of function: Having this will facilitate workflow.
Response: Currently available. An item record can be directly access
for editing by searching by bar code number. It is also possible to
pick an individual item record off the index of item records, although
if there are many item records the index may be multi-screen.
11. Provide automatic re-mapping of shared data elements in the
fixed fields and blanking out of non-shared elements when the format of
a bibliographic record is changed. Importance of function: Having this
will facilitate workflow and increase accuracy.
Response: Currently available. There is a command in cataloging that
allows the change of format of the bibliographic record. This command
re-maps the fixed fields and displays online to the operator any
conflicts in fixed field elements caused by the format change.
12. Provide automatic reformatting of LCCN, ISBN, ISSN to MARC 21
standards during input. For example, system should force or supply the
required three spaces before number portion of an LCCN). Importance of
function: a) Will facilitate precise match points required for
automated duplicate check for batch processes. b) Promotes database
accuracy.
Response: This is not currently supported.
13. Ability to locate entries in long lists of MARC 21 codes or a
long section of MARC 21 documentation by means other than scrolling,
such as keyword search or a jump command. Importance of function:
Having this will facilitate workflow.
Response: Release 2000. MARC 21 will be supported in Release 2000 of
Voyager. To get to an element in a long list, the operator keys the
first character.
14. Provide duplicate call number alert feature when call numbers
are entered or changed in the same local catalog. Importance of
function: Having this will increase accuracy and reduce need to
re-process items with call number conflicts.
Response: Currently available. Voyager supports an alert for duplicate
call numbers. However, because Voyager also support "bound-withs",
duplicate call numbers are allowed.
Serials
Priority 1 (ordered)
1. System must provide complete bindery functions as specified in
RFP.
Response: Endeavor commits to providing the first phase of a bindery
module as part of Release 2001 with at least the functions described
below. We will also carefully evaluate all of the UniversityÕs
specifications as we put together our design.
The first phase will include at least the following functionality: ·
automatic creation of pull lists · automated online updating of holdings
information in Serials and OPAC, as follows:
After system generates bindery pull list, library collects issues and
executes a "send to bindery" instruction for selected issues. System
displays "at bindery" status indication in Serials and OPAC (either for
the issues or the collapsed volume). When volume received from binder,
library links volume barcode and system removes/changes status
indication.
2. System must be able to load invoice data received in delimited
format from serials jobbers (including Swets, Ebsco, Faxon, Radmore,
William Hein, and Popular Subscription).
Response: Release 2000. In the next release, Endeavor will be
including a program designed to take what we call "embedded order data"
and automatically build order records and bibliographic records. This
will allow libraries to directly load order data supplied by vendors who
are not UNEDIFACT compliant.
Three vendors are currently certified by Endeavor for UNEDIFACT invoice
processing. Those three vendors are Swets, Ebsco, and Faxon.
3. System must be able to match invoice entries to system records
using complex criteria, including but not limited to vendor reference
number.
Response: Currently available. The invoice function in acquisitions
includes searching by a number of criteria to match incoming invoices to
purchase orders.
4. System must support production of an online, printable summary
report of invoice loads, including exception (i.e. error) reports for no
price, duplicate title, no existing holdings, and no existing payment
record.
Response: Currently available. For those invoices with no price, the
system alerts both with an online exception report and with a printed
report. Both types of notifications are also done for a duplicate
title. If there are multiple duplicate titles, then the system makes
the operator choose which title to overlay. If there are no existing
holdings, then the system again prompts both online and in print. "No
existing payment record" does not apply to Voyager. The automatic
creation of the invoice record is the payment record.
5. As an automatic part of the claiming process, system must
display claim and missing status in the OPAC with library-defined
terminology, e.g. "Claimed".
Response: This enhancement is not currently scheduled. It was not
highly rated by the customer task force.
6. Payment history list must display on a single (vertically
scrollable) printable screen, in addition to information currently
displayed: payment amount, subscription coverage, and fund information
without requiring any additional clicks.
Response: Release 2000. Changes in the user interface in the next
release will include a single screen display of payment history.
However, it will be necessary to do one click from that payment history
to get some of the information required here.
7. System must be able to "jump" to a specific volume/issue/date
of a serial without scrolling and be able to perform any serials
function at that point.
Response: This is not currently supported. While Endeavor has
discussed how to provide this, there are no concrete plans at this time.
8. System must be able to check in a range of issues
simultaneously.
Response: Release 2000. In the next release it will be possible to
highlight multiple issues and check all of them in with a single click,
using the "quick checkin" button.
Priority 2 (ordered)
9. System must be able to sort check-in information by date of
issue, date of receipt, or volume/issue designation.
Response: The serials checkin function automatically sorts receipts by
enumeration/chronology. Regardless of the date of receipt, issues are
automatically sorted into the correct volume/number sequence.
10. System must provide a real-time, printable, online staff
display of summary holdings that mimics the public display without
requiring staff to exit the system and search the OPAC.
Response: Because the format of this data is quite customizable, there
is no one single "public display" of the summary holdings data. The
staff can view the MARC holdings data easily from several places.
11. System must have option to display on a single (vertically
scrollable) printable screen the history of all components (i.e. regular
issues, supplements, indexes) of a title in a combined list.
Response: This is not currently supported. There is a combined
scrollable list of all components of a title. Clicking on an individual
component provides a scrollable list of all issues of that component.
12. System must provide a standard report to predict serials
expenditures based on current year's orders, cancellations, renewals,
and multiple inflation factors.
Response: Currently available. This is part of the reports from fiscal
year end close. It is also possible to have the system automatically
set up the next yearÕs budget, including an inflation factor.
13. System must be able to automatically claim an issue even if
title has no active order.
Response: This is not possible. The structure of Voyager requires an
open purchase order in order to receive and claim issues.
14. System must automatically alert the operator with a pop-up
window that requires operator confirmation if a cancelled, ceased,
monographic, or non-current title is being used for check-in, without
preventing check-in.
Response: Partially available. Voyager has two mechanisms that support
this requirement. The "checkin note" is a popup note that the operator
can create and which pops up each time the component is accessed for
checkin. It is possible to have any text in a pop-up note, and it is a
handy way of alerting the checkin staff to some exceptional condition.
Checkin can proceed once the message is acknowledged.
The other mechanism is the automatic warning from Voyager if checkin is
attempted for a closed pattern. The alert is automatic, but checkin is
not allowed. A pattern record can be closed for the present issue or
for any future specified issue. If closed for a future issue, checkin
is allowed until there are no more issues available to checkin.
Acquisitions
Priority 1 (ordered)
1. 4.1.108 "In support of shelf-ready processing, system shall
support ability to create order and invoice records from data embedded
in vendor/locally defined US/MARC tags in bibliographic records".
Endeavor responds that this ability is in Beta test and will be
available in early 2000.
This ability to interface with Blackwell's Book Services (BBS) is
currently working in CARL. We are able to load tapes for bibliographic
and accounting records which then create order records with a minimum of
additional keying in the acquisitions module SRAQ. Need for this
ability is also stated in 8.1.6 "System shall link invoice data to
specific orders/records, whether data entry is manual or electronic."
In its interface with BBS, Endeavor must be beyond Beta and provide
complete interface, including Collection Manager. See 0.1.18.3.
"System shall provide interfaces to major bibliographic files (OCLC,
RLIN, Blackwell North America, Swets, etc.) for deriving, receiving and
transmitting data." Endeavor should be working with BBS for full
interface. We need complete connectivity with BBS from day one.
Response: Release 2000. Endeavor understands the importance of this
feature. We are in development of this feature now, and it will be
included in the next release. The new function will extract order data
which has been embedded in a bibliographic record and will use that data
to automatically create a purchase order.
Until this development is complete, there is no workaround for the order
data embedded in these records. However, the barcode data can be
processed using currently available bulk import programs. Voyager will
create the necessary holdings and item records from the data embedded in
the bibliographic record.
2. 4.1.9.8 "System shall provide an acquisitions record which
includes a description of the material...and at least the following:
volume number". There is no discrete data field for entering volume
number. The suggested place for entering volume information is in the
"Notes" field, which appears to be a catch-all for any data field, which
may be missing. This is not satisfactory and results in the need to
scroll through the "Notes" field at point of receipt, claim, or
cancellation for volume information.
Response: Release 2000. A field is being added to the invoice record
in Release 2000 for this information. It is currently possible to
specify specific volumes for ordering by creating a multi-part order
type.
3. 4.1.15 "System shall be able to pull into an acquisitions record
any applicable data (e.g. vendor code, currency code) from files in the
acquisitions functions/module..." Voyager does this, but does not allow
the operator to key in fund number, location, or other information
directly even if the operator knows that information. Voyager requires
that the operator click on ellipses, scroll through a list, highlight
and click on the desired information. This is inefficient. How much
faster it is for an operator to type in "1000" or "Asia". There are
order defaults, which can be preset, appropriate for batch ordering, but
not for individual ordering. Also, there is a real need to minimize
the number of mouse clicks required for any transaction in the
acquisitions module.
Response: Release 2000. In the next release, the operator will be able
to directly key the location and fund information if known. In
addition, there is a significant amount of work being done on the
interface to reduce clicks and to make the interface more streamlined.
4. 4.1.19.17 "System shall provide an acquisitions record which
includes ... Selector's name". There is no discrete data field for the
name of the librarian responsible for placing the order. This is a must
have for reporting purposes. It is not acceptable to put this
information in the "Notes" field.
Response: Currently available. The order record includes a field
called Requestor that can be used for the selector identification.
However, please remember that the note field is keyword searchable, so
that it is also possible to keyword search the notes fields for a
selectorÕs name
5. Print Purchase Orders. The purchase order sample in Reports
shows a simple, domestic 3-line address. We need the assurance that
4-line and 5-line addresses will print properly. See samples below from
our vendor file: . Institute of Pacific Studies University of the South
Pacific PO Box 1168 Suva, FIJI
National Central Library Bureau of International Exchange of
Publications 20, Chungshan S. Road Taipei, Taiwan 10040 REPUBLIC OF
CHINA
Response: Currently available. There are five (5) address lines, plus
the city, state and country, which are used by the purchase order print
program.
Priority 2 (ordered)
6. 4.1.26 "System shall allow staff to print a purchase order with
one purchase order number .1) for one title .2) for multiple titles".
Voyager has both parts of this ability, but the printing of one purchase
order number for a single title is poorly developed. Choosing this
method of purchase order creation results in a single title with single
purchase order number printing on a full page - a terrible waste of
paper! In addition, when orders print on single sheets of paper, staff
must sort the sheets by vendor and collate them for mailing.
Imagine the volume of paper and increased postage costs for orders sent
to Asia and Pacific Island vendors where EDI is a development in the
distant future. The Library will see a dramatic increase in postal
charges ($.60 per half ounce).
Endeavor should write a program to print all orders to a single vendor
in any one day in continuous list format. In our advanced technological
age this ability should be readily achieved. For the sake of the
environment and economy, this is a must have.
Response: Not available. If the library wishes to add to purchase
orders, it can simply leave the order as status pending and add
additional line items to it. Line items can be added to a pending
purchase order at any time until the operator approves the order.
7. Boolean Search: A demo of Acquisitions Prototype 2000 showed
promise of increased efficiency and user friendliness, but lacked
Boolean search capability which is available in the current release. We
trust that Boolean searching will be included in the new version of
Acquisitions.
Response: Release 2000. None of the Boolean searching is being removed
in the user interface enhancements.
8. 4.1.12 "System shall be able to check new orders against
library's holdings". 4.1.13 "System shall be able to check new orders
against the "on order" file by title and ISBN". There needs to be both
a title and ISBN or ISSN check against the database at the point of
approving purchase orders as title changes are common. If duplication
is found, the operator should be alerted or warned, but not stopped from
ordering.
Response: Partially available. Voyager does an automatic duplicate
check at the time of approval of the order. If duplication is found,
there is an online warning. The operator can choose to proceed.
The ISBN and ISSN checks are available in the cataloging deduplication
profiles, but are not currently part of the online duplicate order
check.
9. 4.1.27 "System shall produce print purchase orders with selected,
locally defined data from the acquisitions record". The sample purchase
orders in Reports prints author and his dates. The latter is not
necessary. We would like the assurance that the Library can truly
tailor purchase orders to include all information that will make the
purchase order intelligible to the vendor and that there will be help
from Endeavor to do this tailoring.
Response: The printed purchase order in Voyager is created using
MicroSoft Access. The basic system report functions pass purchase order
data to the Access printing program. This allows the Library to tailor
the formatting of the data and to suppress fields which are not desired.
10. 4.1.37 "System shall allow staff to edit any data field prior
to receipt". Once a purchase order has been approved, Voyager does not
allow editing of data. The workaround for editing or correcting data
once a purchase order has been approved is Byzantine. Also, 4.1.38
"System shall allow authorized staff to edit fields after payment is
made." Editing after payment is made is not possible in Voyager, but
should be with proper authorization.
Response: Release 2000. With the next release it will be possible to
change the amount, vendor, fund and location on a approved purchase
order. The issue of editing invoices after approved for payment is a
more difficult because of the need for audit trail. However, it is
currently possible to add notes to an approved invoice.
11. 4.1.99 "System shall be able to produce an online, on-demand
report of the number of items and titles received against a particular
fund for a specified time period". 4.1.102 "System shall be able to
produce interactive, online reports on demand which can be printed".
Vendor responded in the affirmative in the RFP, but this ability was not
seen in the demos.
Interactive, online, on-demand reports are currently available in SRAQ
where staff may define reports and receive the results immediately at a
workstation and print the screen. Staff do not need to move outside
the acquisitions module to request programming to extract the
information from an Oracle database for loading into Access or even to
select from a list of canned reports. (It is my understanding that
there is no "print screen" ability in Voyager.)
This is a reporting feature frequently used by selectors to provide
instant information (e.g., a list of titles ordered last week). This
ability was demonstrated for Endeavor staff during previous visits as it
is a highly valuable feature. Currently, there is nothing in Voyager,
which fills the need for instant reporting. Endeavor responded
affirmatively to 4.1.99 and 4.1.102.
Endeavor Reports include a section on Acquisitions, the samples provided
were not reports, but print products (e.g., claims, cancellations,
purchase orders). There are few reports for acquisitions and no
reports, which address collection management issues (e.g., how many
books received on the gathering plan circulate). Canned reports
focusing on collection management statistics are a must have.
Also, among the canned reports there should be a section devoted to the
annual statistical reporting needs of ARL libraries. There should be a
package of reports designed to provide these statistics for the 25 ARL
libraries now in the Endeavor family. This is a must have.
Response: Currently available. Because it is possible to create
reports from Voyager using any SQL report writer (such as Microsoft
Access), this requirement is met. Any report created by Voyager or
created using Access can be run online at a workstation. Reports
created using Access are run from Access.
Searches done within the Voyager modules, such as acquisitions, can be
printed using a utility program (such as PrintScreen, which is a piece
of freeware). This feature allows a slector to use the Booelan
searching capabilities inside acquisitions (create date range of last
week) and then print the resulting list.
With Release 99, Endeavor has supplied many new pre-created reports,
including a number focusing on collection analysis and statistical
reporting. There is no specific ARL report package, but the data is
available.
12. 4.1.16 "System shall alert operator to existence of special
ordering instructions for a vendor." If there are special ordering
instructions (e.g., prepayment required or library maintains standing
order with vendor, etc.), the operator needs this information and needs
an alert before proceeding with the order.
Response: This is not currently planned.
13. 4.1.47 "System shall be able to alert operator that there are
special handling notes (e.g. rush) attached to an acquisitions record.
"There is no alert of any kind. Upon receipt of an item, the receiver
is forced to scroll through and read the Notes field for any special
handling instructions. An alert, pop-up preferred, is needed.
Response: Currently available. The rush indicator is a special box on
the purchase order screen. No scrolling is necessary to see it. In
fact, even if there are notes in the note field, those notes are visible
on the initial purchase order screen if the monitor used in large
enough.
14. Purchase Orders. The Library accepts the purchase order number
supplied by Voyager, but would like to supply a Julian date prefix.
Voyager allows the addition of a prefix, but requires the operator to
input the Julian date with each purchase order. Our intention is to
order using one title/one purchase order number which will, therefore,
require the repeated keying in of a Julian date, an inefficiency which a
sophisticated system such as Voyager must be able to solve with a preset
default prefix.
Response: Currently available. This is currently possible by resetting
the sequencer for purchase order numbers.
15. 4.1.62 "System shall allow staff to attach notes to
cancellations by selecting from a menu..." 4.1.63 "System shall allow
staff to enter a minimum of 200 characters of additional
cancellation-related notes to the vendor" Voyager responded
affirmatively to both requirements, but Voyager does not allow the
notes to be printed on the paper cancellation notice to be sent to the
vendor. This defeats the whole purpose of vendor notes. Notes to
vendors must print on all print products.
Response: Currently available. The receive function of Voyager gives
the operator access to a screen where the item can be marked for return
or cancellation or any other reason for further examining the item. The
reason codes are defined by the library and display in a pick list to
the operator. The reason(s) selected do print on the correspondence
created by the system.
In addition, Voyager supports an 80 character note to vendor field on
purchase orders.
16. 4.1.86 "System shall alert operator to existence of duplicate
vendor code." 4.1.87 "System shall alert operator to existence of more
than one vendor with same name." When a library's vendor file exceeds
12,000, there is likelihood of duplication of vendor code and vendor
name, something this Library has experienced. An alert to the operator,
pop-up preferred, is needed.
Response: Currently available. Voyager requires that the vendor code be
unique. A duplicate vendor code is not allowed.
17. 4.1.82.4 - 4.1.82.8 "System shall allow staff to create and
maintain an online supplier file of vendors...for ordering..., for
claiming..., for returning..., for payment..., for client
representative...". Most of the elements listed in this requirement are
provided, but email is lacking. A discrete field for email address is
needed for each tab of the vendor record.
Response: Currently available. The contact name field of the vendor
record may be used for e-mail address.
18. 4.1.93.9 "System shall include discrete data fields in each
fund account for elements including...fund manager". There is no
discrete data field for fund manager. It was suggested that this
information could be put into "Notes". This solution is not acceptable
as there will be reports run based on fund manager. A discrete data
field for this information is needed for reporting purposes.
Response: Currently available. The Institution ID field may be used
for this purpose. Also because the notes fields are keyword indexed,
reports can be run by fund manager even if it is put in the notes field.
19. 4.1.72-4.1.80 "System shall be able to record and report
desiderata entries for future recommendation for ordering with discrete
data fields...". The Desiderata File is a separate section of the RFP
for a reason. It is envisioned as a tool, separate but integrated, in
the Acquisitions Module, for selectors to record, edit, prioritize
request from faculty, publishers' announcements, titles from selection
tools(e.g., Choice), etc. which then can be sent to the Acquisitions
Department when ready for ordering.
Endeavor has suggested workarounds with elements already in Voyager,
which may be usable, but highly makeshift. Pre-order selection is a
process found in every library. If libraries are to move out of the age
of paper worksheets into a complete online environment for selecting and
ordering, a Desiderata File for use by selectors is a must have. Please
see attached specifications.
Response: What is currently available in Voyager is the ability to use
pending purchase orders as desiderata records. A selector can create a
pending purchase order with themselves identified in the record.
Pending orders may stay in the system as pending as long as desired.
By using this mechanism, there is no need for the acquisitions
department to copy or rekey data to create purchase orders from
desiderata. Simply changing the vendor and assigning the fund codes
creates an order.
20. 4.2-4.2.11 The Gifts & Exchange (G&E) section is a separate
section of the RFP for a reason. It is envisioned as a tool, separate
but integrated in the Acquisitions Module. The G&E section of any ARL
library plays an important role in the acquisition and exchange of
scholarly materials.
There were 41 positive responses from Endeavor in this section of the
RFP; there were 14 negative responses. It would appear that Voyager can
meet many of the requirements though solutions involved workarounds
using order records and the vendor file. This not the answer.
Developing G&E abilities within the Acquisitions Module would be useful
tool that is now lacking in all automated library systems. Please see
attached specifications.
Response: Voyager acquisitions has routines incorporated into it for
gifts. For example, an order type of "gift" is defined in Voyager.
Other routines have been incorporated for dealing with gifts.
21. Voyager 98.1 Acquisitions Manual. The organization of the
Manual is puzzling as topics and nstructions do not follow an expected
workflow(e.g., "Before You Begin" includes "Printing Labels";
"Acquisitions Login Information" is the penultimate topic in Chapter I).
Review and revision of the Manual should be a priority with the release
of the new Acquisitions Module.
Response: Release 2000. There will be significant revisions to the
documentation as part of the next release.
Fiscal
Priority 1 (ordered)
1. 8.1.8 "System shall provide payment documentation in both
paper and electronic format, including itemized information as defined
by the library to meet the requirements of an external funding agency".
We need the assurance that Endeavor can and will produce a voucher
(which we call a receiving report) that will conform to the University's
Disbursing Office's requirement.
Response: Currently available. Voyager produces vouchers, both printed
and online. Printed vouchers may be reformatted in the same way as
other printed products.
2. 8.1.4.3 and 8.1.4.5 "System shall provide multiple security
levels for all fiscal transactions, including data correction... at the
highest level, total reversal of transaction". We require the ability
to correct or edit data in an invoice at any time including after an
invoice is approved or even after payment has been made.
Response: This is not planned. Voyager has been designed to include an
audit trail and to act as an auditable set of transactions. This goal,
which overall improves efficiency, cannot be met if any and all data can
be changed at any time.
3. 8.2.12 "System should allow global change to a specific set
of transactions by authorized staff". Changes are not global. They
must be made line-by-line. Endeavor responded "We need clarification on
the types of transactions." An example is changing all orders from Fund
X to Fund Y.
Clarification: Specifically we are referring to situations in which a
fund number (or ledger is to be closed out and all open orders must then
be assigned to another fund number (or ledger). The new fund number
(legder) is created, and a global command is then needed to transfer the
open orders from the old fund number (or ledger) to the newly created
fund number (or ledger).
Response: Currently available. For the specific situation outlined in
the clarification, this is accomplished through the existing fiscal year
end close programs. These programs allow the rollover of open orders
and the creation of rules for how ledgers and funds should be handled.
4. 8.3.16 and 8.3.17 "System should allow encumbered items to
be rolled over into the new fiscal year globally or by specific
designated fund" and "System should allow funds to be closed at the end
of the fiscal year globally or by specific designated fund". Year-end
processing is only available globally (all funds within a group) and not
by a single, designated fund. The Fiscal Office requires the ability to
have the option of performing end-of-year processing in batch process or
by single, designated fund.
Response: Currently available. The fiscal year end programs allow
changes to all ledgers or to an individual ledger. A ledger is simply a
group of funds.
5. 8.1.12.2 "At the operator's option, system shall allow the
recording of postage and handling, discounts, sales tax, VAT, and
similar one-line entries on invoices to be calculated and distributed by
the system over multiple items on an invoice", including postpayments.
This ability is currently working in SRAQ. It is regularly used
particularly for invoices from Asia and the Pacific where it is not
unusual for the cost of shipping to exceed the cost of the materials and
the true cost of an item must include shipping charges. Manual
calculation and distribution of shipping (and other costs) is
time-consuming and tedious. Computers do this kind of job easily when
programmed. This is a must have for efficiency of fiscal operations.
Response: This enhancement will be part of Release 2001.
Priority 2 (ordered)
6. 8.2.3 "System should alert the operator to potential
duplicate payment". It does not. Duplicate payments have occurred,
generally as a result of duplicate invoice numbers either from a single
vendor or multiple vendors. The system needs to alert the operator to
the possibility of duplicate payment or duplicate invoice numbers.
Endeavor answered affirmatively to this requirement, but was not able to
demonstrate it.
Response: Currently available. Once a line item on an invoice has been
noted as received and paid, it cannot be received and paid again. The
system does not allow it. If an operator tries to receive and invoice
items off a purchase order that have already been received, this is
alerted. VoyagerÕs mechanism for this is to automatically update the
line item status on the purchase order from the invoice. As the
operator processes the invoice (or as it is loaded via UN/EDIFACT), the
status of the line item on the appropriate purchase order is updated.
7. 8.2.18 "System should allow authorized staff to cut checks
within specified limits locally, i.e. within the library". Connectivity
to the Library internal impress check printer is an important issue. As
the Fiscal Office is authorized to cut checks up to a $500 limit, the
development of this ability would streamline a daily activity and save
staff time. Voyager's answer to this specification was negative. We
would like them to consider seriously its implementation.
Response: This is not currently possible. We will consider how the
University might easily implement this.
8. 8.2.7 "System should allow the updating of currency conversion
tables from an on-line source with the proper authorization". This
ability is not currently available through a Voyager connection. It
should be so that the updating is done by the system, not an operator.
Response: This is a desirable enhancement. We will seriously consider
it, but we need to research how this data might be transferred. While
there are good sources of data that post it to the Web, it is not clear
to us what export routines are available.
UNCOVER INTERFACE
1. It is necessary for the University of Hawaii to continue to interface
with the Uncover system. This requires that we transfer both patron
data and serials holdings data on a regular basis.
Response: Currently available. Although the University currently has
proprietary programs for these data transfers, Endeavor has two standard
data transfers that can be used for this. Our bursar interface programs
will extract and transmit patron information and our bulk export program
will extract and transmit MARC holdings information for serials. This
is not to say that these standard programs are as customized as the
proprietary programs, but they provide the basic output. In both the
case of the patron information and the case of the serials holdings
information, Uncover may need to do some intermediate reformatting of
the data in order to load it into the Uncover system.
If Endeavor needs to do a customized export of the serials holdings data
by specific criteria, we will do such an extract for $2,500. The
extracted data will still be in the MARC format for holdings. Section B.
Summary of those CUSTOMER Development Requirements to be part of
Release 2000.
CUSTOMER has made requests for functional enhancements to the SOFTWARE.
Those requests and ENDEAVORÕS responses are detailed in Section A of
Appendix I. Those enhancements listed as being part of Release 2000 are
a payment milestone for CUSTOMER and those functions must be supplied
before CUSTOMER makes that milestone payment.
This section repeats requirements and responses from above. Item
numbers refer to numbering in University of Hawaii Endeavor Voyager
Development Requirements, from Section A. This summary list of
Commitments and ENDEAVORÕs Responses in University of Hawaii Endeavor
Voyager Development Requirements above shall be used together to
determine ENDEAVOR's commitments to CUSTOMER for Release 2000 of the
SOFTWARE.
WEB OPAC
1. Limits in effect to be displayed on search screen and results screen.
(Limiting)
Response: Release 2000. This enhancement is included in the next
release.
6. Ability to mark records on unlimited number of pages before saving.
(Marking and Output)
Response: Release 2000. The next release will include this
enhancement.
7. Ability for user to apply limits to search results and re-execute the
search. (Limiting)
Response: Release 2000. This enhancement is being added in the next
release. Users will be able to do the current limiting before the search
and will also be able to apply limits after the search and reexecute.
9. Ability for user to define (or override default) sort order for
search results. (Sorting)
Response: Release 2000. The user will be able to resort search
results in the next release.
10. Ability to sort on fields including, but not limited to, author,
title, publication date, location, call number. (Sorting)
Response: Partially in Release 2000. In the next release of Voyager,
the end user will be able to resort by author, title and date (both
ascending and descending).
11. Ability to have format options for export of records (including full
or brief record, and Endnote and/or ProCite) (Marking and Output)
Response: Release 2000. It is possible today for the library to define
the output format. With Release 2000, it will be possible to define
multiple (up to 10) output formats, which will be presented to the user
in a dropdown menu.
13. Ability to "jump to" a record in the search results list.
(Navigation)
Response: Release 2000. The display and use of jump bars will be
supported in the next release.
15. Search window available on every screen. (Search Results)
Response: Currently available. The search button appears on every
screen, allowing a user to initiate a new search from any step. In
addition in Release 2000, the search entry box with the text originally
entered by the user will appear on the results screen, making it easy
and apparent to the user how to modify the search.
19. Ability to search on status of item, i.e. available copies only.
(Searching)
Response: Partial with Release 2000. Rather than make the user ask for
availability, in Release 2000 Endeavor will automatically display an
availability indicator on the index screen.
CATALOGING
5. Ability to link directly to related order information and serial
holdings information from within Cataloging function, i.e., not opening
up a separate module window. Importance of function: Having this will
facilitate workflow and troubleshooting (e.g., lost worksheets).
Response: This is being implemented in Release 2000. There will be a
direct link to the order data from the cataloging record.
13. Ability to locate entries in long lists of MARC 21 codes or a long
section of MARC 21 documentation by means other than scrolling, such as
keyword search or a jump command. Importance of function: Having this
will facilitate workflow.
Response: Release 2000. MARC 21 will be supported in Release 2000 of
Voyager. To get to an element in a long list, the operator keys the
first character.
SERIALS
2. System must be able to load invoice data received in delimited format
from serials jobbers (including Swets, Ebsco, Faxon, Radmore, William
Hein, and Popular Subscription).
Response: Release 2000. In the next release, Endeavor will be
including a program designed to take what we call "embedded order data"
and automatically build order records and bibliographic records. This
will allow libraries to directly load order data supplied by vendors who
are not UNEDIFACT compliant.
Three vendors are currently certified by Endeavor for UNEDIFACT invoice
processing. Those three vendors are Swets, Ebsco, and Faxon.
6. Payment history list must display on a single (vertically scrollable)
printable screen, in addition to information currently displayed:
payment amount, subscription coverage, and fund information without
requiring any additional clicks.
Response: Release 2000. Changes in the user interface in the next
release will include a single screen display of payment history.
However, it will be necessary to do one click from that payment history
to get some of the information required here.
8. System must be able to check in a range of issues simultaneously.
Response: Release 2000. In the next release it will be possible to
highlight multiple issues and check all of them in with a single click,
using the "quick checkin" button.
ACQUISITIONS
1. 4.1.108 "In support of shelf-ready processing, system shall
support ability to create order and invoice records from data embedded
in vendor/locally defined US/MARC tags in bibliographic records".
Endeavor responds that this ability is in Beta test and will be
available in early 2000.
This ability to interface with Blackwell's Book Services (BBS) is
currently working in CARL. We are able to load tapes for bibliographic
and accounting records which then create order records with a minimum of
additional keying in the acquisitions module SRAQ. Need for this
ability is also stated in 8.1.6 "System shall link invoice data to
specific orders/records, whether data entry is manual or electronic."
In its interface with BBS, Endeavor must be beyond Beta and provide
complete interface, including Collection Manager. See 0.1.18.3.
"System shall provide interfaces to major bibliographic files (OCLC,
RLIN, Blackwell North America, Swets, etc.) for deriving, receiving and
transmitting data." Endeavor should be working with BBS for full
interface. We need complete connectivity with BBS from day one.
Response: Release 2000. Endeavor understands the importance of this
feature. We are in development of this feature now, and it will be
included in the next release. The new function will extract order data
which has been embedded in a bibliographic record and will use that data
to automatically create a purchase order.
Until this development is complete, there is no workaround for the order
data embedded in these records. However, the barcode data can be
processed using currently available bulk import programs. Voyager will
create the necessary holdings and item records from the data embedded in
the bibliographic record.
2. 4.1.9.8 "System shall provide an acquisitions record which
includes a description of the material...and at least the following:
volume number". There is no discrete data field for entering volume
number. The suggested place for entering volume information is in the
"Notes" field, which appears to be a catch-all for any data field, which
may be missing. This is not satisfactory and results in the need to
scroll through the "Notes" field at point of receipt, claim, or
cancellation for volume information.
Response: Release 2000. A field is being added to the invoice record
in Release 2000 for this information. It is currently possible to
specify specific volumes for ordering by creating a multi-part order
type.
3. 4.1.15 "System shall be able to pull into an acquisitions record
any applicable data (e.g. vendor code, currency code) from files in the
acquisitions functions/module..." Voyager does this, but does not allow
the operator to key in fund number, location, or other information
directly even if the operator knows that information. Voyager requires
that the operator click on ellipses, scroll through a list, highlight
and click on the desired information. This is inefficient. How much
faster it is for an operator to type in "1000" or "Asia". There are
order defaults, which can be preset, appropriate for batch ordering, but
not for individual ordering. Also, there is a real need to minimize
the number of mouse clicks required for any transaction in the
acquisitions module.
Response: Release 2000. In the next release, the operator will be able
to directly key the location and fund information if known. In
addition, there is a significant amount of work being done on the
interface to reduce clicks and to make the interface more streamlined.
7. Boolean Search: A demo of Acquisitions Prototype 2000 showed
promise of increased efficiency and user friendliness, but lacked
Boolean search capability which is available in the current release. We
trust that Boolean searching will be included in the new version of
Acquisitions.
Response: Release 2000. None of the Boolean searching is being removed
in the user interface enhancements.
10. 4.1.37 "System shall allow staff to edit any data field prior
to receipt". Once a purchase order has been approved, Voyager does not
allow editing of data. The workaround for editing or correcting data
once a purchase order has been approved is Byzantine. Also, 4.1.38
"System shall allow authorized staff to edit fields after payment is
made." Editing after payment is made is not possible in Voyager, but
should be with proper authorization.
Response: Release 2000. With the next release it will be possible to
change the amount, vendor, fund and location on a approved purchase
order. The issue of editing invoices after approved for payment is a
more difficult because of the need for audit trail. However, it is
currently possible to add notes to an approved invoice.
21. Voyager 98.1 Acquisitions Manual. The organization of the Manual
is puzzling as topics and instructions do not follow an expected
workflow (e.g., "Before You Begin" includes "Printing Labels";
"Acquisitions Login Information" is the penultimate topic in Chapter I).
Review and revision of the Manual should be a priority with the release
of the new Acquisitions Module.
Response: Release 2000. There will be significant revisions to the
documentation as part of the next release.
System Performance Acceptance Test in the Agreement between UH and EISI
APPENDIX J. System Performance Acceptance Test
This Appendix outlines a test to measure the general performance goals
for the software. CUSTOMER is entitled to perform this test to ensure
that the SOFTWARE meets the performance outlined here.
Performance is defined as how quickly the system responds to requests
under an array of different types and levels of transactions within the
CUSTOMER'S environment. Although the CUSTOMER has licensed an unlimited
quantity of concurrent public access users, this test shall be performed
with no greater than 250 concurrent public access users.
This test will be performed on CUSTOMERÕS production server hardware
configuration with CUSTOMER'S production database. CUSTOMER will conduct
the test. At ENDEAVOR'S option, ENDEAVOR personnel may monitor the test.
The SOFTWARE shall be considered to have satisfied the conditions of the
test if the response time for ninety-five percent (95%) of all
transaction types is within the times listed below for the average and
maximum load. For each transaction type the response time for
ninety-five percent (95%) shall be within the times shown.
Average system use is defined as 200 or less concurrent public access
connections and 240 or less concurrent staff connections doing a normal
mix of transactions in production usage. Maximum system usage is defined
as 200 to 250 concurrent public access connections and 290 concurrent
staff connections.
Should the SOFTWARE fail to deliver the stated performance, ENDEAVOR
agrees to diagnose SOFTWARE, hardware and network conditions at no cost
to CUSTOMER. CUSTOMER agrees to provide ENDEAVOR access to the system to
perform such diagnosis and to implement changes suggested by ENDEAVOR.
As detailed in Paragraph IV. B., CUSTOMER shall notify ENDEAVOR in
writing of the outcome of the performance test. Retesting, if necessary,
shall be according to the conditions and timeframes stated in that
Paragraph.
The performance goals for average and maximum response times are listed
below.
Response times are measured and defined as the time between the last
network packet being detected as sent to the server across the network
segment and the first network packet representing the serverÕs response,
using standard network management tools, such as the netstat utilities
in UNIX.
Searches in any module and using Response time (seconds)
a Web browser for public access Average (95% of the time) Maximum
Numeric 3 5
Heading (a/t/s) 3 5
Bib record from index 3 5
Display holdings 3 5
One selected bib record to next 2 5
Search redirect (e.g., headings) 3 7
Phrase 3 5
Keyword (single term) 3 10
Keyword (two terms) 5 20
Boolean 5 20
Other 3 5
Circulation
Charge 2 3
Discharge 2 3
Renewal 2 3
Add patron 3 5
Edit patron 3 5
Delete patron 3 5
Item inquiry 3 5
Acquisitions/Serials
Add record 5 8
Edit record 5 8
Delete record 5 8
Financial calculations 5 8
Serials check-in 2 5
Cataloging
Add holding 5 8
Edit holding 5 8
Delete holding 5 8
Add record 5 8
Edit record 5 8
Delete record 5 8
Authority Control
Add record 5 8
Edit record 5 8
Delete record 5 8
Course Reserve
Add course 3 5
Edit course 3 5
Delete course 3 5
Add item 3 5
Edit item 3 5
Delete item 3 5
Ongoing Performance
If at any time (and if the CUSTOMER has not exceeded the number of
concurrent users and database size detailed in this License) the
CUSTOMER does not receive the response times detailed above, ENDEAVOR
will work with the CUSTOMER to diagnose the problem and recommend a
solution. The CUSTOMER will not be charged for any ENDEAVOR staff time
spent diagnosing the problem.
Comments
to Wil Frost, University of Hawai'i at Manoa Library, 2550 The Mall,
Honolulu, Hawaii 96822 USA. Last modified: December 28, 2001.