> 0.0 General > 1.0 Circulation > 2.0 Reserves > 3.1 Interlibrary Loan > 3.2 Electronic Reserves > 3.3 Media/Materials Booking > 4.0 Acquisitions > 5.0 Serials > 6.0 Cataloging > 7.0 WebVoyage > 8.0 Fiscal > 9.0 Application Administration > 10.0 System Administration > 11.0 Support Services
(Contact: Wil Frost, Hamilton Library)
0.1.18 System shall provide interfaces to: 0.1.18.2 University student information systems. Comment: checking with Systems to see if this specification is satisfied. 0.1.19 System shall be fully compliant with the following standards: 0.1.19.3 Z39.57 (Non-serial holdings statements). Comment: checking with Serials Committee to see if this specification is satisfied. 0.1.21 System shall have the capability to comply with the Americans with Disabilities Act. Comment: WebVoyage does not pass the Bobby Test, which is the standard at the University of Hawaii (primarily a problem with missing ALT tags).
(Contact: Susan Murata, Kapiolani Community College Library)
1.1.2 System shall provide an online backup function when main Circulation module/function is "down" or otherwise inaccessible. Voyager does have an online backup function by means of the offline circulation feature, but it is very limited in regards to what it can do. It cannot automatically calculate loan periods, enforce blocks, or verify whether patrons can borrow an item. This poses a great inconvienience since besides having to have a circ checkout station for each item loan period, it is likely that a student who is not registered (especially at the beginning of the semester) will charge out books. 1.1.4 System shall correctly calculate and recalculate due dates and fines under all circumstances regardless of modifications that have been applied to the transaction. Voyager does not correctly calculate due dates in the circulation module under several circumstances: For items that have been scheduled in Media Scheduling, the due date is incorrectly calculated. For a second recall the backdate does not work (?). When backdating an item from a foreign location upon check in, the backdate does not take. For items whose loan periods were assigned by overriding the original loan period, the backdate feature does not work, fines are assessed according to the original loan period. For items with a status of Cataloging Review or Circulation Review, or for that matter any item record with an odd status, the backdate feature does not work. 1.1.6 System shall allow patrons to view information about their circulation transactions in the online catalog from any physical point of access to the system. Patrons are not able to log in to the Patron Information feature of WebVoyage when: They have multiple barcodes which are the same with different patron groups (ie. 1000000000 OuzU and 1000000000 OCKU). Their patron record or barcode is expired. They have a block on their record (ie. due to fines and fees). In the patron information screen only the permanent address is displayed. 1.1.7 System shall allow patrons to place requests to hold or page items by means of the online catalog from any physical point of access to the system. This feature is not currently being used by Hawaii Voyager Libraries since it is a title level hold (which places a hold on the first available item of a title, even if it is from another library). 1.2.3 System should allow staff to scroll backward and forward in browse lists (of transactions, patron names, financial histories, etc.). Backward scrolling does not work from the point of entry. 1.2.7 System should allow staff to re-execute a previous search for patrons without the need to rekey. Only general name searches can be re-executed, even then if you exit the patron search window you will not be able to re-execute the search. Specific searches such as by barcode number, social security number, or a specific name can not be re-executed at all. 1.1 Patron records should be searchable by ID number. One is unable to search by Voyager patron id number in the circulation module. This would be useful as circ notices by default use this id number instead of the patron barcode. 1.10 Added (or proxy) borrowers should be searched in a way that identifies them as added or proxy borrowers. From the main borrower's patron record one can identify who their added borrowers are, but from the added borrower's record it is not possible to see who the main borrower is. Since proxy transactions go directly onto the account of the main borrower, in cases where this borrower is an institution patron blocks will be reached sooner, causing all added borrowers who are under that institutional main borrower to be blocked. 1.17.1 When registering new patrons, system should alert staff if a duplicate (e.g. patron ID number) is entered. Voyager allows you to write a patron record with a duplicate barcode without notifying you that this has happened. 1.3.25 System should interface with University of Hawaii cashier's office systems so that the patron may clear library financial obligations at the cashier's office (without need to make a separate trip to the library business office). There is currently no interface between the two systems. 1.4.9 System should allow staff with proper security level to obtain/view information pertaining to specific item in real time. No proper security (?). 1.4.10 During charge/renew, system should alert staff when an item has an outstanding transaction (e.g. checked out, on hold, recalled, fines, blocks, notes). Holds in Voyager are completely passive, staff are not alerted when an item on hold is charged out to someone. Instead notice is given and a hold slip generated when an item is returned. This is particularly a problem with on shelf holds where someone other than the patron who placed the hold is able to borrow an item without being blocked. 1.4.11 During return, system should alert staff when an item has an outstanding transaction (e.g. on hold, recalled, fines, notes, claims returned, lost and paid, in-transit). Voyager will alert staff to a lost item that has been returned but not a lost item that has been paid for (for the purposes of crediting the patron for the lost book replacement charge). As a workaround a "lost and paid" patron account had to be created for each campus. 1.4.14 System should be able to place requests for traces/searches on items with "shelf" status online, but which are not physically on the shelf. Voyager has no trace feature, instead there is a cumbersome workaround where an item a patron wishes to trace is charged to a "Mr. Missing" account along with a hold being placed for the requesting patron. On a regular basis a list of items charged by "Mr. Missing" is generated and used as a search list. If the item is found it is checked in and a hold slip is printed. 1.4.16 System should allow items to automatically receive "intransit" status when returned at different circulating locations other than the "home" or "owning" location. Voyager notifies the discharging operator with the alert, "Item belongs to a foreign circ policy group's location:" and then generates a routing slip to return the item to its home location. However, upon discharge at the home location the only notice that is given is a "Browse" prompt in the FYI column. 1.5.5 - 1.5.9 After institution specified limit, system should notify institution that multiple holds or recalls exist. System should produce lists of title-level and item-level holds placed for other UH institutions for ILL processing. Voyager does not automatically notify an institution of the presence of multiple holds or recalls after a specified limit or produce lists of title-level and item-level holds placed for other sites for ILL processing. Instead these need to be created as reports in SQL or MS Access by staff. 1.6.3 System should allow blocks applied to patrons to be automatically cleared, in real time, when they satisfy their delinquencies. When a lost item is returned Voyager does not forgive the lost item replacement cost and/or the processing fee and there is no option to do so within the circulation portion of the SysAdmin client. Instead staff must manually forgive both whenever a lost book is returned, placing more work on them. 1.6.13 System should be able to archive the financial history of a patron by library specified dates/time periods. Voyager does not do this by automatic means provided within the circulation module, rather this has to be done through custom reporting via SQL or MS Access. 1.7.5.2 System should have canned notes (e.g. from a pre-set list or table). Voyager currently does not have canned notes which an operator may choose from a pre-set list or table. 1.7.9.9 Printed receipts/slips should be available for lost and paid items. No receipt or slip specific for lost and paid items are generated in Voyager when they are returned. 1.7.17.6 Notices produced should include one for traces (items not found). There is no trace feature in Voyager, so no trace notice is produced. The notice that is produced with the "Mr. Missing" workaround when an item is found is actually an item available notice for items on hold when they are returned. 1.7.17.10 - 1.7.17.12 Notices produced should include for the collection agency, State Tax Setoff, and Registar/Cashier's Office (to invoke a financial block on further registration by the patron). There are no canned notices in Voyager for the collection agency, State Tax Setoff, or the Registar/Cashier's Office. These reports and notices had to be custom programmed by our consortium's Systems Office. 1.7.23.8 System should be able to provide, on any schedule (e.g. hourly, daily, monthly, fiscal year-to-date), statistical reports by owning location for items put on search (traced?). There is no trace feature in Voyager, so there is no statistical report for traces. 1.7.28.6 Daily list of fiscal transactions should include date and time of transaction. The Voyager exception reports include date but not time. 1.7.29 System should allow daily list of items to be searched (items with trace statuses) to be produced. Voyager does not have a trace feature so no list of items to be searched is produced. The closest thing would be the list of items charged out to "Mr. Missing" when using the workaround. 1.7.33 System should allow weekly list of invoices generated to be produced. Voyager produces a list of invoices daily not weekly. 1.7.35 - 1.7.36 System should generate a list of problem borrowers to be produced automatically on a library determined schedule, on demand, and for specific borrower types. Voyager does not generate a list of problem borrowers automatically, rather one has to be created using SQL or MS Access. 1.7.39.1 System should allow shelf list reports for heavily circulated titles. A list of heavily circulated titles can be generated in Voyager through one of the prepackaged MS Access reports. 1.7.43.3 Each institution should have the option to generate/send notices by a combination of both email and paper/printout. Notices cannot be send out by both paper and email in Voyager, one must choose between one or the other. 1.7.44 Telephone notification should be available as an option. There is no option for telephone notification. 1.8.6, 1.8.7 System should allow special fees to be set up for specified borrower or item types. There is no way in Voyager to set special fees for a specified item type or patron group. 1.8.8.1 System should allow lost book charges to be generated based on a pre-set table of prices. Voyager does not have a pre-set table of prices for lost book replacement fees. 1.8.8.4 System should allow lost book charges to be generated based on item format/material type. Lost book charges can be assessed in Voyager by item type but not by material. 1.9.3 System should allow patrons to place recall requests using the online catalog from any physical point of access to the system. Voyager does not allow one to place recalls via WebVoyage from any physical point of access to the system. 1.9.7 System should allow patrons to place requests for traces/searches on items with "shelf" status online, but that are not physically on the shelf. Patrons cannot place a trace for an item via WebVoyage as Voyager does not have a trace feature at all. 1.9.18 System should allow patrons to pay fines and fees online. This feature is not available in Voyager. 1.9.23 System should allow patron initiated orders/requests to be automatically routed to library staff selectors. There is no system level opac form in WebVoyage that allows a patron to place an order/request for an item. Instead a custom form has to be created by staff which is limited in regards to layout and processing.
(Contact: Ruth Marie Quirk, Lois Tom, Sinclair Library)
2.1.1 When backdating an reserve item at the circ location, fines are applied as if the backdating was not done. When Circulating a reserve item from a foreign location, the override must be done. 2.4.9.5 Reserves items that are not owened by the library are suppressed from the online catalog. Reserves does not allow for search by standard bib search keys just within reserves, and since they are suppressed from the webvoyage they are not searchable. 2.4.11 There is no Pending reserve status, so we cannot tell even in circulation what is currently pending reserves. We have to check each list individually to see what is on a reserve list but is still waiting to go on reserve (pending) 2.4.15.2 Cannot tell in the reserve module, you must go to item record, or printed reports 2.4.15.3 The list can be pending, but not the items as requested 2.4.15.4 No archive, but you can keep old lists 2.5.3.1 Not able to specify or configure times. it is on demand only 2.7.2 Only works from home location. does not work from foreign locations (note this did work in release 99.1)
(Contacts: Ruth Marie Quirk, Lois Tom, Sinclair Library; DeeDee Acosta, Hamilton Library)
3.1.15 Copyright clearance/compliance cannot be tracked. 3.1.16 ILL requests for items are not automatically checked against local library holdings. 3.1.22.3 Delivery fees are not automatically billed.
(Contacts: Ruth Marie Quirk, Lois Tom, Sinclair Library)
3.2.2 When you add an e-item it makes the title display multiple times on the webvoyage reserve list, once for the print once for the electronic, even though they share the same bibliographic record 3.2.4.1 - 3.6.2 The only files we can confirm work are weblinks to PDF format. These will download, display and print. 3.2.9 - 3.12.3 Image server does not handle for multipage text (OCR) documents, But it would work okay for image files. We did not use Image servers so we cannot comment on these specifications. 3.2.17 No copyright compliance software 3.2.18 No Copyright clearance management software 3.2.23 - 24.2 No fees can be applied automatically no mechanism for subsidized, or debit accounting
(Contacts: Ruth Marie Quirk, Lois Tom, Sinclair Library)
3.3.1 It looks feels and works very differently from Circ. 3.3.2 Functions are not integrated with Circ. There are problems with circ when an item has a media type but is not actually scheduled it cannot circ. When an item is scheduled backdating in circ does not work. Fines and fees don't work in media scheduling at all (we would like fine to work just like circ, fees don't work in circ or Media scheduling.) 3.3.11 Fines and fees not working at all in Media Scheduling 3.3.12 There is no calendar that let's you know when things are available there is a calendar for all items that shows when there are bookings. 3.3.14--3.3.14.4 Since there is no availability calendar. 3.3.15.1 Availability not calculated to account for library specified preparation time prior to delivery/shipping 3.3.20.1 - 3.3.20.5 Usage fees not automatically applied to specific patrons, patron types, material/media formats, and delivery methods. they cannot even be done manually from within Media scheduling you have to leave and go to circ. 3.3.21.1, 3.3.21.4 - 3.3.21.6 Booking parameters not library definable for restrictions, delivery shipping methods, fine rates, usages and other fees 3.3.21 - 3.3.23.3 Bookings requests not blocked within library-defined time prior to show date, shipping preparation date, shipping date 3.3.24.1 - 3.3.24.3 Different blocking thresholds not assigned/configured to apply to specific formats, delivery/shipping methods, patron types/categories 3.3.26.1 Confirmation notices not automatically produced and sent via email 3.3.27 Production of confirmation notices printed on demand, not configured by library 3.3.28 The system does not allow different notices to be output at different times, there are no overdues, pickup notices or no shows. 3.3.30.1 Production of confirmation notices cannot be turned off for individual patron 3.3.34.1 - 3.3.34.2 Pull list information does not include item call number or item barcode number. And Pull list can only be done for the next 48 hours, so if we are closed for a weekend or more, we cannot pull for the next open day. 3.3.34.7 - 3.3.34.8 Pull list information does not include show date(s) or date item should be returned 3.3.36.1 - 3.3.36.8 No printed packing slips, that we can find so non of these things are on it. The Pull list does not include them either. 3.3.37.1 - 3.3.37.2 Delivery lists not configured to print for any library-defined time 3.3.38 No separate lists for each/all forms of delivery methods being produced 3.3.42.2 - 3.3.42.7 Statistics and reports not produced by and do not include patron types, format/material, shipping method, number of overdue items, items not returned/overdue, fines assessed. 3.3.41 - 3.3.43.2 Statistics and reports not cumulated weekly or monthly 3.3.44.1 - 3.3.44.2 Media catalogs and/04 bibliographies not produced by library definable/selected subject category or format. We did not do E-Reserves, because we have not started using it, and since UHM Admin turned down our proposal to start it on a very small scale ASAP, we will not have information to evaluate it.
(Contact: Thelma Diercks, Hamilton Library)
SUMMARY Version 2000 did not turn a pumpkin into a carriage. The functionality and design of version 2000 show some improvement over its predecessor, but leaves much to be desired. In general, the Acquisitions Module does most of what it has to do and with a bit of coaxing it performs satisfactorily. This summary focuses on certain Technical Specifications regarding which Endeavor answered affirmatively, but which remain unfilled. Section 4.1.9. ELEMENTS OF A PURCHASE ORDER. Missing are unique fields for basic data: alternate purchase order number, vendor stock number, volume number, foreign currency and its U.S. equivalent, selector's name, acquisitions status. Endeavor suggests that this information be put in the "Notes" field. This solution is not acceptable. Section 4.1.20. HISTORY. We asked for a history of all actions taken and by whom. Voyager identifies only the last person who touched a record. 4.1.23. OVER ENCUMBRANCE/ OVER EXPENDITURE. Once an operator is alerted to possible over encumbrance or over expenditure, we asked that the operator be allowed to continue with the transaction after affirming that this is the chosen course. This ability is important particularly at the end of the year when funds need to be fully encumbered or spent. An orderer generally knows that certain items will not be delivered in time and a receiver may need to complete an invoice with a small overage which can be covered by transfer of funds. 4.1.27. PRINT PURCHASE ORDERS. We asked for purchase orders with "selected, locally defined data". Voyager supplies "canned" purchase orders to which no additional data can be added. 4.1.72. DESIDERATA FILE. This was a golden opportunity for Endeavor to develop a useful feature for all libraries trying to eliminate paper requests. The intent and vision of a Desiderata File for selectors was to provide a distinct pre-order functionality within the Acquisitions Module. Endeavor answered affirmatively to all points in this Section, but none of the intended functionality is provided. 4.1.82. VENDOR FILE. This was another area where Endeavor could have developed a useful feature. Technical Specifications for this Section describes a directory equivalent to the "yellow pages" of telephone books, identifying vendors by type and country. Some clever person may have found a workaround to accomplish this, but we have opted to identify our vendors as domestic or foreign to avoid inherent problems. The design of the Vendor File does not allow for easy use. The pages are crowded, not well organized and do not accommodate all the data elements we requested. 4.1.102. REPORTS. A most useful feature of our former system was the ability to produce interactive, online, on demand reports within the Acquisitions Module. The queries were simple (e.g., What titles are ordered by Selector XXX?) There is no such ability in Voyager though Endeavor answered affirmatively to the Technical Specifications. Comment on DOCUMENTATION. The VOYAGER 2000.1 ACQUISITIONS MANUAL (August 15, 2000) shows some small improvement from earlier manuals. "Logging In" and "Logging Off" appear early in Chapter I rather than being buried mid-chapter, but "Printing Labels" strangely continues to appear in the section titled "Before You Begin". There continues to be room for major improvement in logical organization and coverage of all aspects of the module. The Manual is divided into three sections: Chapter I - Voyager Acquisitions - pp. 1-621; Chapter II - Fiscal Period Closing - pp. 623-655 and Chapter III - EDI - pp. 657-768. What would make more sense would be separate chapters based on workflow activities: search/order activities; receiving/invoice processing activities; serials check-in; fiscal activities; files (vendor, currency, ledgers) with everything thoroughly indexed. A glossary of terms as used by Voyager would also be helpful (e.g., how does Voyager define "available cash"). Frequently encountered problems and their solutions would be a helpful addition to the Manual, especially with the close alliance between Acquisitions and Cataloging (e.g., how can a purchase order be moved from one bibliographic record to another without having to recreate the purchase order and its invoice). PRIMARY REQUIREMENTS 4.1.1.1 Systems shall provideÉserials management function/module for tracking, ordering, renewing and paying for subscriptions and serial standing orders. Comment: It would be ideal to have serials check in separated from other acquisitions functions (e.g., ledgers, purchase orders), to be in effect an automated cardex which would be accessible for viewing by Circulation and Reference staff. 4.1.2 System shall be able to define levels of access based on functions performed by staff using password security. 4.1.3 System shall be able to set password access at the function or task-specific level. Comment: We have found that profiles are too generic making assignment based on functions either too inclusive or too exclusive. Individualized password access is not possible. ORDERING 4.1.6 System shall be able to order, record and report the SERVICES related to the acquisition of library materials, including but not limited to É 4.1.6.1 memberships; 4.1.6.2 transportation. Comment: Voyager does not order, record and report the above without creation of a bibliographic record, forcing the creation of a "dumb" bib records 4.1.9 System shall provide an acquisition record which includes a description of the material or service being acquired, and at least the following: 4.1.9.3 alternate purchase order number. Comment: Regarding alternate purchase order number, Voyager responds that such a number can be put in the "Notes" field making it searchable and reportable. We would prefer a unique field for alternate purchase order numbers which will print on purchase orders, claims, etc and which would allow tracking of materials received on blanket orders, series standing orders, etc. 4.1.9.7 vendor stock number. Comment: No place for vendor stock number 4.1.9.8 volume number. Comment: This important piece of information is missing; workaround is to include volume number as part of the title. 4.1.9.11 foreign currency and its U.S. equivalent. Comment: Does not print on PO in both currencies; does not indicate if price is domestic or foreign on PO. Also, fund number is missing from PO. 4.1.9.14 field for external notes to vendor. Comment: The field is too short for most messages. 4.1.9.15 reportable fields, locally determined, such as, but not limited to language, format, monographs, serials Comment: Not yet tried and tested. 4.1.9.17 selectorÕs name. Comment: There is no unique field for the selectorÕs name; workaround suggested by Endeavor is to put this information in the "Notes" field which requires operator to click on the field and read through all the notes. Not acceptable. 4.1.9.18 faculty requesterÕs name. Comment: There is a place for faculty requesterÕs name. Our expectation for filling this requirement was that there be direct email capability by clicking on the name. 4.1.9.19 donorÕs name. Comment: same as above 4.1.9.20 acquisitions status (e.g., new order, prepaid, claimed, etc.). Comment: Calling up a line item does not provide selectors (with READ ONLY access) with complete information about the status of an order (e.g., prepaid, claimed specifically). 4.1.10 System shall be able to record in a discrete data field the type of order, including, but not limited to the following 4.1.10.2 subscription; 4.1.10.5 blanket order; 4.1.10.7 another edition ; 4.1.10.8 added copy; 4.1.10.9 replacement copy; 4.1.10.10 sample issue; 4.1.10.11 monograph continuation; 4.1.10.12 search and quote; 4.1.10.13 confirming order for book in hand. Comment: System does not have discrete data fields for the above. Though the lack of discrete data fields does not directly inhibit ability to function, Endeavor did answer in the affirmative that these fields were available. In some cases, Endeavor commented that certain types were planned for a later release. 4.1.11 System shall be able to record in a discrete data field in the acquisitions record the means of acquisitions, including but not limited to received 4.1.11.1 on the basis of membership; 4.1.11.4 as depository item; 4.1.11.5 against a deposit account; 4.1.11.6 against a standing order; 4.1.11.7 against a blanket order; 4.1.11.8 prepaid order. Comment: With the exception of received as a gift and received on exchange, there are no discrete fields for the any of the above and to which Endeavor answered affirmatively. 4.1.12 System shall be able to check new orders against libraryÕs holdings. Comment: The System checks against holdings, but with unforgiving exactness. The location must be the exact location which makes if difficult to see the whole picture when placing an order (i.e., added copy) for another location. In addition, it performs a search by title rather than ISBN. If ISBN were the first to be searched, all copies of a title would display. We prefer that the search be first by ISBN. 4.1.13 System shall be able to check new orders against the "on order" file by 4.1.11 title; 4.1.13.2 ISBN Comment: There is no separate "on order" file in Voyager Acquisitions. When checking new orders, the System searches the entire database, not an "on order" file. We recommend a separate file of materials which have been ordered. 4.1.14 System shall be able to check new orders and alert operator to existing umbrella order records including but not limited to 4.1.11 blanket orders; 4.1.13.2 standing orders. Comment: Though Endeavor responded affirmatively, there are no operator alerts for either. 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 function/module (e.g., vendor file, currency code table, etc.) and other functions/modules (e.g. PAC). Comment: Endeavor partially meets this requirement through sessions defaults setting. Requirements have not been fully tested. Our experience has shown there to be ledger inconsistencies with pulling in fy 2001 or fy 2002 ledgers. The problem is not easily duplicated and may be corrected by removing the FMIS number from inactive funds. Additional testing needed. 4.1.16 System shall alert operator to existence of special ordering instructions for a vendor. Comment: Endeavor answered affirmatively. The System does not alert operator. 4.1.19 System shall provide order templates based on type of order. Comment: Order templates are not provided for the 14 types of orders listed in 4.1.10. Templates must be created by each operator on his/her PC which doesnÕt seem at all efficient and may result in inconsistency among operator templates. 4.1.20 System shall be able to record the staff member responsible for an acquisition action and 4.1.20.1 maintain a history of all such actions. Comment: Only the last person who touched the record is identified. There is no history of all actions. 4.1.23 Without preventing a transaction from proceeding, system shall alert operator entering an acquisition transaction of possible 4.1.21 overencumbrance of a fund; 4.1.23.2 overexpenditure of a fund Comment: Endeavor comments that it "allows option to over commit and/or over expend a fund by a percentage set by the library". This is true, but the intention of this requirement was to allow an operator to proceed with entering or receiving an order after being alerted. There are times (e.g., end of year) when it is appropriate for the operator to overencumber or overexpend beyond the limits set by the percentages in the system, especially if the amount is miniscule and the operator is aware of materials which are not likely to be received before the close of the fiscal year. We would like the System to query the operator "Are you sure you want to over encumber (or overexpend)?"and allow the operator to continue with placing an order or receiving an order. 4.1.25 System shall allow staff to select method of transmission including but not limited to 4.1.25.2 faxed purchase order; 4.1.25.3 emailed. Comment: Endeavor answered affirmatively which is misleading as transmission can be by fax or email, but not from within the Acquisitions module. Regarding 4.1.25.4 electronic data interchange (EDI), this has yet to be tried and tested. 4.1.27 System shall produce print purchase orders with selected, locally defined data from the acquisitions record (see 4.1.9) Comment: The canned purchase order report can be manipulated in terms of placement of data fields which are predetermined, but no additional data can be added to the canned purchase order. That we cannot add a unique field for edition statement or volume number means we must apply workarounds. Endeavor responded affirmatively to this requirement and added the comment "Most sites need to print a variety of notices as a result of acquisitions activities. For example, purchase orders and vouchers (often in an institution-mandated format), claim letters, and cancellation notices all must be generated following online activity." The comment indicates that our requirement has not been understood. 4.1.31 System shall allow staff to choose whether order record is displayed to public and staff, or whether order record is displayed to staff onlyÉ 4.1.31.2 anytime during the life of an order Comment: Not yet tested. All orders are currently suppressed. Sometime in the future, they will be unsuppressed. We would like to be able to unsuppress either individually or globally. 4.1.32 System shall allow staff to choose to display different messages to staff and to the public (e.g., to staff, "Rush RBR" or to the public, "On Order". Comment: Not yet tested. At this point, we believe that this function exists in Cataloging, not in Acquisitions 4.1.39 System shall allow authorized staff to reactivate a cancelled order Comment: "Reactivate" is the word subject to interpretation. Order cannot be reactivated, but it can be copied over and redone. RECEIVING 4.1.43 System shall provide a means to update order status from a menu which includeÉ4.1.43.4 returned; 4.1.43.5 damaged; 4.1.43.6 rejected. Comment: These three options are not available via menu. 4.1.44 System shall allow staff to change type of currency (foreign or U.S.) in acquisitions record at point of receipt Comment: Endeavor replies affirmatively, but changing currency type at point of receipt is not possible. Currency changes can occur only when an invoice is created from scratch (line by line). In this situation the operator is allowed to change currency type. 4.1.45 System shall allow staff to choose to barcode or not to barcode an item upon receipt Comment: Not yet tried. 4.1.46 System shall be able to alert operator that there are special handling notes (e.g., rush) attached to an acquisitions record Comment: There is no alert for "rush" items. Only "Requester" pops up. 4.1.47 System shall allow staff to move an acquisitions record from an attached bibliographic record to another bibliographic record (i.e., when another edition is received) Comment: Yes, it is possible, but is not an easy process, especially if the invoice has already been paid. CLAIMING 4.1.51 Based on predetermined cycle(s) entered in the vendor record by the library, system shall be able to produce claims for materials not received. Comment: Not thoroughly explored. Claims go to a "problem list" which is, unfortunately, in chronological order rather than alphabetical by title which makes locating an item difficult. Also the "problem list" intermixes claims from both the Serials and Acquisitions Departments. There is some remembrance that the v.2000 Training Video gave contrary data, but this has to be checked. 4.1.52 System shall allow staff to override order claim cycle in vendor record Comment: Experience is incomplete. Our understanding is that this is possible if s different claim period is designated in the purchase order. 4.1.55 System shall allow staff to select method of transmission of claim, including 4.1.55.2 faxed; 4.1.55.3 emailed. Comment: Endeavor answered affirmatively which is misleading as transmission can be by fax or email, but not from within the Acquisitions module. Regarding 4.1.53.4 electronic data interchange (EDI), this has yet to be tried and tested. 4.1.58 System shall display in the acquisitions record the 4.1.58.1 number to times a claim has been sent; 4.1.58.2 dates the claims were sent Comment: Not yet observed. CANCELLING 4.1.60. 2 System shall allow staff to suppress cancellation. Comment: Not yet tested. 4.1.61 System shall allow staff to select method of transmission of cancellation including 4.1.61.2 faxed; 4.1.61.3 emailed. Comment: Endeavor answered affirmatively which is misleading as transmission can be by fax or email, but not from within the Acquisitions module. Regarding 4.1.61 electronic data interchange (EDI), this has yet to be tried and tested. 4.1.62 System shall allow staff to attach notes to cancellation by selecting from a menu which includes, but is not limited to 4.1.52.1 "Item no longer needed" Comment: There is no menu for cancellation messages from which a selection can be made. 4.1.63 System shall allow staff to enter a minimum of 200 characters of additional cancellation-related notes to the vendor. Comment: This is related to 4.1.57: System shall allow staff to enter a minimum of 200 characters of additional claim-related notes to the vendor. This specification works allowing entry of additional characters which print on the claim. This similar specification for cancellations allows entry, but does not print on the cancellation. 4.1.66 System shall automatically remove "on order" record from public display when an order is cancelled . Comment: Not yet tried as all orders are currently suppressed. 4.1.67 System shall be able to create claims, cancellations, and other acquisitions actions for transmission to vendors. Comment: See above comment regarding purchase orders and the inability to display volume number, edition, etc. INVOICE PROCESSING 4.1.70 System shall allow authorized staff to process invoices for payment, by using functions including but not limited to 4.1.70.1 upon receipt of item, receive and record information such as cost, transportation charges, currency, etc. Comment: Adding information is possible when an invoice is created from scratch (line by line), but operator is otherwise limited to what can be added to an invoice created from a received/approved purchase order. 4.1.70 System shall allow authorized staff to process invoices for payment, by using functions including but not limited to: 4.1.70.4 handle invoice numbers duplicated by different vendors. Comment: "Handle" was probably the wrong word to use. "Distinguish" or "differentiate" would have been better words. The System accepts duplicate invoice numbers from different vendors (and the same vendor). 4/1/70.5 Édistribute postage and handling charges and other supplementary costs over items in an invoice. Comment: The word missing from the requirement is "automatically". The intent of the requirement was to have the System distribute supplementary costs over items on an invoice. Distribution of supplementary costs must be done manually, item by item. DESIDERTA 4.1.72 System shall be able to record and report desiderata entries for future recommendation for ordering with discrete data elements. Comments about this section follow at the listing of the requirements. 4.1.73 System shall allow authorized staff (selectors) to create desiderata records, which can contain a title (245) only 4.1.74 System shall be able to use bibliographic records from outside sources to create desiderata records (e.g. another libraryÕs catalog on the Web, citation or index database, Books in Print) 4.1.75 System shall be able to suppress desiderata records from public display 4.1.76 System shall create individual lists for staff (selectors) entering desiderata records 4.1.77 System shall provide access search points available in PAC, including keyword search, to desiderata file 4.1.78 System shall support retrieval search methods for desiderata file as listed in 4.1.72 - 4.1.72-16 4.1.79 System shall allow authorized staff to complete or edit a desiderata record 4.1.80 System shall support sorting of desiderata records by discrete data fields as listed in 4.1.72 - 4.1.72.16 4.1.81 System shall allow authorized staff (selectors) to transmit desiderata records to acquisitions office for order placement Comment: In describing the requirements for a selectorsÕ DESIDERATA FILE, the intent and vision was for a distinct pre-order functionality for selectors within the Acquisitions module. Selectors would be able to keep a separate file even if only limited information is entered (title and requester). Selectors would be able, using Z39.50, to pull in bibliographic records from outside sources. Each selector would have a file that would be password protected. The selectorsÕ DESIDERATA FILE would be searchable by any distinct data field. Selectors would be able to prioritize items, approve, and forward titles for ordering by the Acquisitions Department. Selectors would be able to define reports, be able to enter parameters (from the DESIDERATA FILE and from Acquisitions Data) online and interactively receive the results which can be viewed at and printed from a workstation. This reporting ability is vital to selectors' day-to-day needs and has been outlined in another section (4.1.102) and other documents. Endeavor answered affirmatively to all points in the requirements for the DESIDERATA FILE, but the functionality intended for this section is not available. VENDOR FILE 4.1.82 System shall allow staff to create and maintain an online supplier file of vendors, domestic and internationalÉ 4.1.82.4 for ordering, vendor address, phone, fax, email, standard address number (SAN), contact person, and notes; 4.1.82.5 for claiming, vendor address, phone, fax, email, SAN, contact person, and notes; 4.1.82.6 for returning, vendor address, phone, fax email, SAN, contact person, and notes; 4.1.82.7 for payment, vendor address, phone, fax, email, SAN, contact person, and notes; 4.1.82.8 for client representative, address, phone, fax, email and notes Comment: The organization of the vendor section of Acquisitions is crowded into screens which do not accommodate all the elements we have asked for (e.g., email for ordering, contact person for each function). In the address section, the 2nd line does not consistently print (i.e., Attn: XXXX). As with other mention of fax and email, it would be ideal to make the connection via the System in the future. A vendorÕs url falls into the same desirable functionality. 4.1.82.12 (System shall allowÉdata fields forÉ) currency/currencies used by vendor. Comment: Only one currency type can be associated with a vendor. If there is need to calculate based on another currency type, this must be done when creating an invoice. 4.1.82.13 (System shall allowÉdata fields forÉ) standing order indicator. Comment: There is no data field for a standing order indicator. As with other elements, it can be put into the catch-all "Notes" field. 4.1.82.17 (System shall allowÉdata fields forÉ) vendor specific notes which will default automatically to the acquisitions record. Comment: Notes do not default from the vendor record into the acquisitions records though other data will appear (e.g., vendor code) 4.1.83. System shall allow staff to search vendor file by keyword in: 4.1.81 name(s); 4.1.83.2 addresses for ordering, returning, claiming, paying. Comment: Addresses are not keyword searchable though EndeavorÕs answer was affirmative. Only the first line of the vendor name is searchable which makes finding departments of larger entities very difficult (e.g., City and County of Honolulu on 1st line; Department of Water on 2nd line). 4.1.86 System shall alert operator to existence of duplicate vendor code. Comment: It does not alert the operator. 4.1.87 System shall alert operator to existence of more than one vendor with the same name. Comment: It does not alert the operator. 4.1.88 System shall allow authorized staff to block the use of a vendor record. Comment: It does not allow blocking the use of a vendor record. 4.1.90 System shall be able to provide reports on vendor performance including but no limited to: 4.1.90.1 number of outstanding orders; 4.1.90.2 number of orders filled; 4.1.90.3 average fill rate; 4.1.90.4 average supply time; 4.1.90.5 average discount. Comment: Not yet tested. 4.1.91 System shall be able to provide reports on dollars spent with a vendor for date range selected by the library. Comment: Not yet tested for date range. FUND DATA 4.1.96 System shall be able to display both current year and past year allocations and activities. Comment: Yes, can display both current and past year allocations and activities, but in writing our requirements, we neglected to say "On the same screen" in order to make comparisons with ease. 4.1.99 Systems shall be able to produce an online, on-demand report of the number of items and titles received against a particular for a specified time period. Comment: Reports are not online, but can be requested as custom reports. 4.1.99a System shall be able to calculate and report the average cost for items purchased on a particular fund for a specified time period. Comment: Not yet tested. REPORTS 4.1.102 System shall be able to produce interactive, online reports on demand which can be printed. Comment: There are no interactive, online reports on demand which a selector or acquisitions staff can produce from their PCs. 4.1.103 System shall allow library determine format of reports. Comment: There is some liberty with formatting canned reports, but as there are no interactive, online reports on demand, they cannot be formatted. 4.1.105 System shall allow staff to choose: 4.1..05.1 list format (all titles); 4.1.105.2 summary format (i.e. all titles). Comment: Same comment as 4.1.103. 4.1.106 System shall be able to produce reports based on a classification range for cataloged materials using acquisitions data (e.g. books classified in Library Congress NA class that were ordered in a certain date range). Comment: Not yet tested in the Acquisitions module. Endeavor answered affirmatively without comment. We would like an explanation. 4.1.107 System shall support ability to output locally defined fiscal data in fixed length block form for delivery to University fiscal offices. Comment: Not yet tested. INPUT/OUTPUT 4.1.109 In support of shelf-ready processing, system shall support ability to create holdings and item records from data embedded in vendor/locally defined USMARC tags in bibliographic records. Comment: Currently being tested and implemented. 4.1.109 System shall support the generation of purchase orders, claims and cancellations in electronic format. Comment: Not yet tested. 4.1.110 System shall support user configurable data sets for output of electronic orders, claims and cancellations. Comment: Not yet tested. 4.1.111 System shall support complex matching routines to link incoming acquisitions data with bibliographic records when data comes in separate files or already exists in the system database. Comment: Currently being tested. 4.1.112 System shall support seamless, real-time importing of bibliographic and order data from materials vendor utilizing Web interfaces (e.g. BNA Collection Manager). Comment: Currently being explored with BlackwellÕs Book Services. Comment from Endeavor is that this ability is available in Cataloging and planned for Acquisitions. SECONDARY REQUIREMENTS GIFTS AND EXCHANGE FUNCTIONS 4.2 - 4.2.11 System shall be able to record and report the acquisition of GIFTS in all formatsÉ; System shall be able to record and report the acquisitions by EXCHANGE of materials in all formatsÉ Comment: Developing a distinct and separate section within or outside the Acquisitions Module would be useful to libraries which need to report collection development and management statistics. To the requirements listed in this section of the RFP Endeavor said yes to 38 specifications; no to 13 specifications; yes/no to one. What this amounts to is a series of adaptations and/or workarounds to achieve a Gifts and Exchange functionality. The Gifts section should be able to provide tallies, i.e., a record of a donor's gift and an end-of-year count of all gifts. The Exchange section should be able to record agreements (e.g., what materials are exchanged between the libraries). Often materials exchanged are serials which may require a claiming function. Both Gifts and Exchange have a need for files similar to a vendor file, but the data to be entered for G&E is unique in ways which make the acquisitions vendor file not adaptable for use by G&E. A G&E file should be able to report the acquisition of gifts or acquisition by exchange of materials. As reports are broken down by format (e.g. ARL statistics), the System needs to supply discrete fields for all formats, including but not limited to books, serials, microforms, manuscripts, moving images, photographs, prints, drawings, computer software, electronic files, sound recordings, musical scores, archival materials (e.g. congressional papers measured in feet), etc. DATA INPUT/OUTPUT 4.3 - 4.3.7 System shall support processing of acquisitions and fiscal data received in EDI/EDIFACT compliant format, including but not limited to complex matching routines, rejection for manual review of specified records, user designated reportsÉ.(Only the 1st specification is quoted here.) Comment: Not yet tried and tested. The responses from Endeavor are all affirmative or planned functionalities.
(Contact: Amy Carlson, Hamilton Library)
SUMMARY Management of serials titles comprises more than just ordering, receipt and claim of Serials titles. Knowledge of the bibliographic record, updating holdings information as well as knowledge of acquisitions functions is required to work with serials. In the Voyager environment this means use of both the Cataloging module and the Acquisitions module to manage our serials subscriptions. The complexity of our work increases as we work in two separate modules. The bulk of our functional requirements fall into the Acquisitions module. Although Voyager does fulfill many of our functional requirements quite literally, in many cases we had a different interpretation of the specification in mind. Our most troubling functional requirement deals with serial prediction. Serials prediction is usually the strongest part of a serials management system. We found serials prediction to be one of the weaker points of the system. Prediction and claiming ensures receipt of the materials we purchase. PRIMARY REQUIREMENTS 5.1.1.3 Record ID. Comment: Cannot copy the record ID to paste it into a search. We must manually write it down to re-key the number into a search box. This is inefficient for a Windows environment. Relying on memory or written notes could increase search errors, hampering serial control record retrieval. 5.1.1.6. Locally assigned ID. Unmet: At this time we cannot search by a locally defined ID unless we manually input the ID into the component. 5.1.1.7. Vendor ID. Comment: No known definition. However, the Vendor code is a searchable field. 5.1.2. System shall be able to receive and post payment for various types and formats of serials, including but not limited to: 5.1.2.3. electronic formats. Comment: Lacks sufficient indexed customizable fields for coding essential electronic resource acquisitions information such as subscriber number, access restrictions, login/password, URL, and access restriction notes. 5.1.3. System should be able to receive various types of receipts, including but not limited to: Comment: Purchase order is not entirely editable. We have a qualified ability to edit. Our serials purchase orders are ongoing, yet with the limited ability to edit the approved purchase orders, we will have many more to manually recreate if at the time of receipt or payment we must edit or make a change to the original purchase order. Additionally, the receipt status of serials, (received partial or received complete), relate only to the copy received and are misleading. 5.1.4. System shall be able to post payment for various types of receipts, including but not limited to: 5.1.4.7-5.1.4.8. unnumbered issues; supplements. Comment: The Acquisitions department handles unnumbered issues. We have not yet tested payments for unnumbered issues or supplements. 5.1.5. System shall be able to predict future issue(s) automatically when an issue is received: 5.1.5.1. for various types of serials; 5.1.5.2. for various formats of serials; 5.1.5.3. for all levels of enumeration; 5.1.5.4. for all levels of chronology; 5.1.5.5. based on publication pattern; 5.1.5.6. based on library defined criteria. Comment: Although the system does allow the operator to predict some types of materials, the underlying algorithm driving the prediction seems to lack the robust strength required to predict the various types of materials we check-in on a regular basis. We subscribe to 24,000 serial titles with a variety of needs. The system has numerous types of captions to use with our diverse materials, but only provides us with limited options for chronology. Likewise, the algorithm driving the prediction does not allow for more than one frequency. Yet, so many of our publicationsÑwhich are extremely regular in their receiptÑutilize more than one frequency (example: a title that comes monthly, but in December we receive two copies. Thus the title is a monthly until December, in which it becomes semi-monthly). We must manually edit patterns, and continuously open and close patterns as a means to keep the patterns very regular. But if we should become too busy or forget, we may have a lapse or we may not know that we needed to claim the second issue in December. Predictability of serial issues is the most important function of a serials management system. For Voyager, this happens to be one of the weaker parts of the system. 5.1.12. Systems shall be able to update serials holdings statements when issues are received: 5.1.12.1. Automatically [From Endeavor: For each issue]; 5.1.12.2. on command [From Endeavor: For each volume]. Comment: This relates to the collapse function, which we do not use at this time. We will not use the collapse function until it conforms to MARC standards. The collapse function will update the holding statements neither automatically nor on command as intended by the original specifications. 5.1.16 System shall be able to store and display subscription and issue receipts, orders, and payments for a library specified period of time. Comment: What issues we would like to display in OPAC may not be the same number of issues we would like to see in receipt history in the serials check-in. However, if issues are removed from the OPAC display to allow for a more streamlined OPAC, staff will lose vital receipt information in serials check-in history. 5.1.16.1-5.1.16.3 System shall be able to archive older: receipts; payments; orders. Comment: Not yet tested 5.1.17.1-5.1.17.3 System shall be able to remove older: receipts; payments; orders. Comment: Not yet tested. 5.1.18. System shall be able to set password levels for serials functions at task specific levels. Unmet: Although some profiles are determined through tasks, the profile levels are too generic for practical use. To create the profile one must define certain tasks. However, in both the Acquisitions module as well as the Cataloging module, one cannot completely isolate and choose tasks. Some tasks are associated with other tasks in a profile, so that a user may have too few abilities to do the same amount of work as with the previous system or, in many cases, too many abilities. A finer level of specificity would have allowed for greater security. 5.1.19 System shall have a working bindery component. Comment: Endeavor may unveil the bindery in the next upgrade, but most likely, the bindery unit may take more time than expected. We would like to note that although we do utilize the LARS system, we have taken a step back by migrating from CARL to Voyager. CARL would give bindery alerts. Now we must rely on manual work: pulling issues from the shelf by hand. 5.1.20.1-5.1.20.3. System shall be able to automatically generate a claim for: an overdue issue; a gap; a lapse in history. Comment: Although the system will automatically place an issue on the problems list, a staff member must 1. find it on the problems list and 2. mark it for claim. Once marked for claiming, a systems staff member must run a report to print out the claim. This may not have been the original conception of an automatic claim. 5.1.20.4 An imperfect copy. Unmet: not automatic. 5.1.22. System shall be able to generate repeat claims at automatic or defined intervals. Comment: not yet tested. 5.1.24-5.1.29. EDI: Not tested. SECONDARY REQUIREMENTS 5.2 Serials Control 5.2.1 System should allow staff to input and update, without having to move in and out of modules, for the following types of data or record: 5.2.1.1. serials control. Comment: A staff member must have both the acquisitions and cataloging clients open to utilize full functionality. At this time we have no universal login to open all modules (and profiles tied to our logins) at one time. If staff member must input or update a bibliographic record in cataloging, while working in the Acquisitions client and she does not already have the Cataloging module open, then she must put her work on hold until she finished opening up the cataloging client. 5.2.2. System should allow staff to view all relevant information related to a serials title and return to the serials control function without having to search again. Relevant information includes bibliographic, authority, order, payment, vendor, fund and item records and the OPAC display. Comment: Depending upon the set preferences and workflows, a staff member may be able to return to s window or display without having to search again. To accomplish the viewing suggested in this specification, a staff member must have three module windows open (Acquisitions, Cataloging as well as an internet browser to view OPAC) and multiple internal windows open within each module. This causes the system to have problems such as run-time errors. Although the specification is met, Voyager does not provide quick, easy, or streamlined access to the multiple parts of serials control simply because serials functions are scattered throughout both the Acquisitions Module and the Cataloging Module. 5.2.3. System should include popup, or equivalent selections for various fields and tags, including but not limited to: 5.2.3.1. publication status; 5.2.3.2. copy status; 5.2.3.3. branch; 5.2.3.4. location; 5.2.3.5. frequency of publication; 5.2.3.6. NISO fields; 5.2.3.7. CONSER fields; 5.2.3.9. source of publication (e.g. purchase, gift, exchange, deposit); 5.2.3.10 volume and number designation. Comment: These information elements appear in the 008 in the Holdings records (MFHD), but not in serials check-in. In order to see these data elements, a staff member must bridge to Cataloging in the Acquisitions module (usually by selecting the MARC record button), select a MFHD through the hierarchy display and click on the 008 tag. The specification does not indicate where a staff member may find information, yet the most relevant place would be in the Acquisitions module where information would be of the greatest use to the Serials staff member. 5.2.3.5.Frequency of publication: unmet. 5.2.11. System should be able to create an analytic record, and: 5.2.11.2. link to subscription; 5.2.11.3. allow viewing of analytic contents from main serial record. Comment: not tested. 5.2.13. System should have email capability for: 5.2.13.1. claim information; 5.2.13.3. invoice information. Unmet: We cannot email directly from the system. There is no connection between Voyager and our email application. The only way we could email claim and invoice information is to re-key the information into an email message. This does not meet the intent of the specification. 5.3 Receipt, Check-in 5.3.1 System should provide information in a single window to identify title/copy for check-in, including but not limited to: 5.3.1.3. location; 5.3.1.4. call number; 5.3.1.7. vendorÕs title number; 5.3.1.8. frequency. Unmet: 5.3.1.4. call number is not on the same window as the other information listed in the specification. A staff member cannot see the call number if utilizing the Quick check-in, and must use the regular check-in to see the call number one screen away. At the point of receipt, the staff member will find the call number. One cannot see the call number on the same screen as vendor, component name, journal title (from the 245), and the expected issues, which was the original intent of the specification. In order to see the Vendor title number, a staff member would have to click back to the purchase order and open up the line item, which requires three to four extra clicks of the mouse. Nor can one see the frequency, until manual input of publication pattern has been complete. Only then can one see the frequency. One could see the frequency if it could be pulled in form the 891 tag in the bibliographic record. Comment: Not all of the required information exists on one screen in Serials check-in. the system requires you to click at least once away from the main check-in screen to see most of the pertinent or useful information. One click away, with just the brief popup check-in note to warn, could mean more missed issues, more difficult claims or potential check-in errors. 5.3.1.13 dates issues expected. Comment: The issue expected date is on the main check-in screen (and can also be accessed in subscription maintenance). Only the next expected issue is the default highlighted issue. In order to view the expected date, a staff member must highlight an issue by clicking on the issue number. Issue expected date, although on the same screen, is still one click away. 5.3.15 System should offer at the time of check-in the option to link to item record via typed input: 5.3.15.2. in batch mode. Comment: Not tested. 5.3.20 System should warn operator if a canceled or ceased title is being checked-in. Comment: Not tested. 5.3.6 System should check-in of multiple copies of the same issue received at the same time at staff discretion: 5.3.6.1. all at once; 5.3.6.2. one at a time. Comment: The system does NOT allow us to check in multiple copies at one time if the multiple copies have different MFHD locations, which would require separate line items and separate components. We can receive more than one issue of a title, but not more than one copy of an issue. 5.4 Binding 5.4.1.1-5.4.3.5. Comment: Endeavor plans to incorporate binding into the Acquisitions module in a later release. We have lost some functionality for bindery that we had on CARL, our previous system. 5.5 Claims 5.5.8. System should be able to create a hold before a claim is generated, and allow staff to: 5.5.8.3. suppress claim later. Comment: Not yet tested. 5.5.17. System should identify subscriptions due for renewal. Comment: System will only generate a claim for payment and not a claim for renewal. Once Purchase order falls to the problem list, a staff member must search in the problem list, find the order and then mark the order for claim. This is not automatic. 5.5.18. System should identify subscription overdue for renewal. Comment: Similar problem to 5.5.17. 5.5.19. System should identify new subscriptions with no first issue received within a specified period of time. Comment: Voyager cannot claim for an issue unless the first issue of the subscription has been received. One suggested work around: checking-in a dummy issue. But without manual editing, the system will not automatically identify new subscriptions without a first issue received. 5.6. Reports 5.6.1. System should include a variety of standard serials management reports, including but not limited to: 5.6.1.1 active titles; 5.6.1.2. number of dead titles; 5.6.1.3. number of current titles. Comment: Not tested. Security as compared to accessibility is one of the problems with the reports, which can be run from Voyager. In our previous system, CARL, we could run a variety of reports from our workstations. Because of the complexity of running reports in Voyager (and because of the raw data, which one can access at the point of running reports) we no longer have the flexibility to run reports direct from our workstation. 5.6 Fiscal Data 5.7.4. System should allow staff, in real time, to copy payment information pertaining to a serial title/copy. Comment: We are disappointed with how the system complies with this functionality requirement. We cannot copy and paste as we had hoped with this information, nor do we find information fields populated in real time. We must refresh or clear the workspace or something equivalent. Also, the fiscal information we would need to copy and paste is separated into multiple different places between check-in history and maintenance, the purchase order, invoice information and information an operator must input manually into the notes. 5.7.3 System should allow staff, in real time, to edit payment information pertaining to a serial title/copy, including but not limited to: 5.7.3.1 start date of subscription/standing order; 5.7.3.2. fund number; 5.7.3.3. payment cycle; 5.7.3.5. vendorÕs name; 5.7.3.6. notes. Comment: If the invoice is still pending, a staff member can change much of the information listed above. However, if the invoice has been approved, a staff member would need to recreate invoice in order to make changes. Also, if we had a change in Vendor, we would have to input the change to our notes. 5.9 Data Input/Output 5.9.1. System should allow staff to generate claims in electronic form for file transfer (FTP) or other transmission to vendors. Comment: Not tested. 5.9.3. System should support output of selected bibliographic holdings and bindery data (compliant with Z39.76), for export to a commercial automated bindery system (such as LARS or ABLE). Comment: Not tested. The answer from Endeavor is affirmative that we can output select bibliographic holdings, although this may not be possible. We will need to test this specification. 5.9.4. System should support seamless extraction from Web documents and import into the system of bibliographic and holdings data, including but not limited to: 5.9.4.1. META tags; 5.9.4.2. URLs; 5.9.4.3. USMARC 856 tag data; 5.9.4.4. digital object identifiers (DOI). Met: This specification is met through the Cataloging module and not through the Acquisitions module.
(Contact: Michelle Sturges, Kapiolani Community College Library)
SUMMARY Voyager Cataloging meets most of the functional specifications. A few aspects were found to be lacking, however. There is no easy way to undo additions, edits or deletions when working in a MARC record. Data in holdings records are not automatically updated when item records are added, deleted or edited. Users of the label printing option cannot custom-define labels to meet special needs. Call number searches do not sort correctly for all call numbers. Implementation of Unicode for display, online input and online editing of non-Roman scripts appears to have fallen behind schedule. The highest number of unmet specifications were in areas having to do with work done by Systems Office personnel, such as batch processing of MARC records, bulk importing of MARC records, global search/replace of selected MARC data, and global changes to selected MARC data. These unmet specifications mean that a more limited and conservative approach has to be used when work involves large-scale manipulation of MARC data than was the case with the previous ILS. Minimal testing suggests that Voyager authority control operations are functional, but with imperfections as noted below. Those functions include -Importing name and subject authority records manually,* -Editing and deleting authority records manually, -Bulk importing of LCSH authority records, -Global headings change operation (changing existing single-subfield or multiple subfield strings in authorized fields in bibs).** *Can import records manually but a workaround is required, for reasons which we cannot explain. Despite tinkering with the authority duplicate detection profiles, we found that manual import chokes on the 035 field and requires editing of the field before permitting the incoming authority record to be boated (filed into the database). **Global change jobs (cataloging jobs no. 11-13) worked on our sample of four subject authority records, but for reasons which we cannot explain, left one of the authority records behind in the queue after the final job was run. 6.1.1 System shall support visible transaction logs for creation and updating of authority records UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.5 System shall support the USMARC/MARC21 Format for Authority Data UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.7 System shall accept/import records in USMARC/MARC21 Authority format UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.8 System shall allow the creation of records in USMARC/MARC21 Authority format UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.9 System shall store for retrieval records in USMARC/MARC21 Authority format UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.10 System shall index in real time records in USMARC/MARC21 Authority format UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.12 System shall output records in USMARC/MARC21 Authority format UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.13.2 System shall allow staff to create and edit in real time authority records UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.15.1 System shall display diacritics QUALIFIED ACCEPTANCE: Certain characters such as the Angstrom and Candrabindu display incompletely, making it difficult to identify them. 6.1.15.2 System shall display special characters QUALIFIED ACCEPTANCE: Certain characters such as the Angstrom and Candrabindu display incompletely, making it difficult to identify them. 6.1.19.1 System shall support true shelf list order sort and display capabilities for all call number sequences including but not limited to Library of Congress sequence. UNMET: The call number search does not sort numeric elements of the call number numerically, and thus does not display true shelf list order. E.g., Voyager sorts call numbers ending with numeric elements like this: v.1, v.10, v.100, v.11, v.2. In order to support true shelf list order, call number search must display like this: v.1, v.2, v.10, v.11, v.100 6.1.19.4 System shall support true shelf list order sort and display capabilities for all call number sequences including but not limited to local call number sequences UNMET: The call number search does not sort numeric elements of the call number numerically, and thus does not display true shelf list order. E.g., Voyager sorts call numbers ending with numeric elements like this: v.1, v.10, v.100, v.11, v.2. In order to support true shelf list order, call number search must display like this: v.1, v.2, v.10, v.11, v.100 6.1.21.2 System shall support full-screen editing and word processing capabilities for the following types of records defined in the USMARC/MARC21 format: authority UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.28 System shall have online, interactive authority control UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.30 System shall support sharing of authority files between libraries UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.31 System shall support global change in the authority function UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.32 Global changes in the authority function shall appear in all functions/modules in real time UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.35 System shall support the local creation and editing of authority records UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.37 The authority records shall include edit trails, including but not limited to the date the record was added to the local database; the date of the latest external update; the date of the latest local, online edit; the date of the latest batch/offline process; identification of the original operator; identification of the last editor. UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.1.40.1 System shall generate call number labels in user defined formats UNMET: The formats are not user defined; all that an operator can do is create a spinelabel.ini file from a list of pre-defined tags (most of which work) and then manually parse the information to produce a spine label. 6.1.40.2 System shall generate call number labels in user defined formats in batches UNMET: The formats are not user defined; all that an operator can do is create a spinelabel.ini file from a list of pre-defined tags (most of which work) and then manually parse the information to produce a spine label. Furthermore, there is no batch functionality. Every label must be printed individually, there being no way to store the parsed information. 6.1.40.3 System shall generate call number labels in user-defined formats on demand UNMET: The formats are not user defined; all that an operator can do is create a spinelabel.ini file from a list of pre-defined tags (most of which work) and then manually parse the information to produce a spine label. 6.1.47.2 System shall support the ability for locally configurable automatic masking of scripting adjustments or changes to bibliographic records as part of real-time or batch processing, including but not limited to moving data from one tag into a new tag. UNMET: System cannot do this within Endeavor supplied software. 6.1.47.3 System shall support the ability for locally configurable automatic masking of scripting adjustments or changes to bibliographic records as part of real-time or batch processing, including but not limited to creation of variable length tags based on data elements in fixed fields UNMET: System cannot do this within Endeavor supplied software. 6.3.2 System should display non-Roman scripts in Unicode standard, including but not limited to: (1) Chinese, (2) Japanese, (3) Korean scripts. UNMET: System does not display non-roman scripts in Unicode standard. 6.14 System should display call numbers in shelf list order. UNMET: The call number search does not sort numeric elements of the call number numerically, and thus does not display true shelf list order. E.g., Voyager sorts call numbers ending with numeric elements like this: v.1, v.10, v.100, v.11, v.2. In order to support true shelf list order, call number search must display like this: v.1, v.2, v.10, v.11, v.100 6.4.8 System should allow non-Roman scripts in Unicode standard to be input and edited online, including but not limited to: (1) Chinese, (2) Japanese, (3) Korean scripts. UNMET: System does not allow non-Roman scripts in Unicode standard to be input and edited online. Indications are that this functionality will not be available within the timeline Endeavor specified in its response. 6.4.15 System should provide recovery options when records are deleted MARGINALLY ACCEPTABLE: The deletion file that Endeavor points to as meeting this specification does contain data from deleted records but does not appear to contain data that was deleted as part of a merge or replace operation. 6.4.23 System should support the undoing of additions/editing/deletions within a record. UNMET: There is no undo function to retrieve data after it has been edited or deleted from within a record. 6.4.37 System should support global search and replace operations to (1) tag designations, (2) indicators, (3) subfield codes, (4) data in variable fields, (5) codes in fixed fields. UNMET: With 99.1 doing these things ourselves would negate our Oracle license. Version 2000 includes an untested, non-Endeavor product .that cannot be supported by Endeavor customer support. 6.4.38 System should support global changes across selected records UNMET: With 99.1 doing these things ourselves would negate our Oracle license. Version 2000 includes an untested, non-Endeavor product .that cannot be supported by Endeavor customer support. Section 6.6 Authority - General, Creating, Editing, Validation (6.6.1 - 6.6.29) UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.7.20 System should support identification of authority record sets containing a specified string of characters UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.7.20.1 System should permit flagging of identified records for global change UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.8.5 System should update in real time summary holdings and holdings records when item records are added, edited, deleted, merged UNMET: Holdings statements (summary holdings in field 866, 867 or 868) have to be manually edited to reflect changes in the library holdings when changes are made to item records. 6.8.9.7 For holdings and item records, System should support exporting UNMET: We have been unable to export item records. 6.8.10 System should allow staff to move holdings information from one bibliographic record another MARGINALLY MET: A bug (incident #45562) means that the System requires that bib edit capability be present for move holdings function to work. We have no information on when this bug will be fixed. 6.10.1 System should provide a means for importing authority records from external sources utilizing Z39.50 servers. UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.10.3.2 System should support the following parameter-driven automated functionality within the bibliographic records load software: complex matching routines for duplicate checking, including multiple match points UNMET: Multiple match points means more than one match point taken in conjunction, not consecutively. (System only looks at one match point at a time, stopping when it first hits a match. You canÕt set it to say only truly match if there is a match on A AND B. System only matches on A OR B.) 6.10.3.6 System should support the following parameter-driven automated functionality within the bibliographic records load software: validation of authority controlled headings against local authority. UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.10.3.7 System should support the following parameter-driven automated functionality within the bibliographic records load software: validation of tags, subfields and indicators of incoming records against locally configurable validation tables, such as USMARC, OCLCMarc, local UNMET: The load does not do validation against the locally configured tables. Records are loaded as is with no reports flagging records that have invalid MARC elements. 6.10.3.8 System should support the following parameter-driven automated functionality within the bibliographic records load software: reports and/or review files of validation mismatches UNMET: The load does not do validation against the locally configured tables. Records are loaded as is with no reports flagging records that have invalid MARC elements. 6.10.4 System should support the following parameter-driven automated functionality within the authority records load software: (1) checking for duplicate records; (2) complex matching routines for duplicate checking, including multiple match points; (3) ability to have identified duplicates placed in a review file with capabilities for moving records from review file into main database; (4) ability to have identified duplicates overlay existing authority records and globally change headings; (5) ability to locally configure retention of local authority records over incoming records from other sources; (6) ability to selectively overlay and/or retain local data during an overlay process; (7) retention of data as entered in compliance with USMARC/MARC21 and UNICODE standards; (8) validation of tags, subfields and indicators of incoming records against locally configurable validation tables, such as USMARC, local; (9) reports and/or review files of validation mismatches. UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met. 6.10.6 System should support concurrent execution of batch and real-time processing of bibliographic, authority and holdings records with session-specific reports UNMET: When running multiple bib bulk imports, resulting reports are not clearly separated. Due to the Authority file problem, we have not been able to test behavior when running multiple imports of different kinds of records. 6.10.9.1 System should support USMARC/MARC21 and UNICODE compliant exporting of authorities including but not limited to: output of locally created Name Authority Cooperative Program (NACO) records to bibliographic utilities. UNABLE TO TEST: The authority database freeze due to the duplicate record problem has prevented us from evaluating whether this specification has been met.
(Contact: Gwen Sinclair, Hamilton Library)
SUMMARY Overall, WebVoyage meets most of the functional specifications. In several areas, however, functionality is not as expected. First, many features of WebVoyage cannot be customized. For example, some buttons cannot be renamed, and MARC fields cannot be selected for display in several cases. Second, searching does not function as desired in some instances. Especially problematic are call number searches, which do not sort correctly for accession-type call numbers, and subject and name authority searches, which cannot be limited. Third, Unicode implementation has lagged and many characters, particularly in CJK and other Asian languages, do not display correctly. Finally, sorting holdings by location (holdings sort groups) does not work as expected in our consortial environment. WEBVOYAGE 99.1 7.1.1.5 WebVoyage is not configurable at the workstation level. 7.1.2 While each library can define its own indexes, in fact we have had to limit the number of indexes created because a larger number of indexes would slow System response. 7.1.8 The display of UNICODE characters does not work. For Chinese, it often strips out some characters and displays either wrong or unidentifiable characters. Japanese kana are usually missing, and Korean hangul doesn't seem to display at all. 7.1.9 & 7.12.5 Some diacritic marks do not display properly. For example, superscripts larger than 3 and subscripts display as regular numbers. The macron is displayed in front of the character, not over it. The pseudo ? displays as a question mark. In cases where there are multiple diacritics on one character, as in Vietnamese, they do not all display correctly. There may be other examples, but it appears that Voyager handles diacritics for European languages much better than for Asian languages. 7.1.9 Some call number searching (e.g., SuDocs) requires punctuation. For example, a call number search for A 1.2 does not produce the same results as searching A 1.2:. Accession-type call numbers cannot be accurately searched if preceded by a prefix (e.g., CD-ROM, Videotape). 7.1.13 Data elements other than the call number are not searchable in the holdings record. Item records are not searchable in WebVoyage. 7.1.15.19 The item barcode cannot be searched in WebVoyage and does not display in OPAC. 7.1.22 This feature was not available in 99.1 (implemented in 2000.1). 7.2.9 Accession-type call numbers are not interpreted as integers if preceded by a prefix. For example, Videotape 3539 appears in the title list ahead of Videotape 354. 7.3.24 Limits are not available for left-anchored headings or call number searches. 7.5.11.2 MARC format can be printed, but not saved or e-mailed in labeled format. 7.6.5 Some display elements are hard coded (e.g., label and location of search and reset buttons, location of search limits button). Perhaps the most egregious examples are: 1) The code to display electronic resources in the record display will not display 856 subfield u if there is a subfield z present. The Library cannot change this configuration. The Library should be able to choose whether to display $u, $z, or both. 2) The brief title display cannot be configured to display the main entry; it displays whichever title entry is first alphabetically. The result is that the searched-for title may not actually display on the title list, and important subfields such as subfield p and subfield h may not be visible in the title list. Libraries should be able to choose which fields comprise the brief title display. 7.6.27 Holdings sort display apparently does not use the userÕs web client IP address; it looks at the IP address of the Voyager web server. The result is that unless the user logs in, UH ManoaÕs holdings always display first, because the web server is located at UH Manoa. This feature does work in the Windows OPAC. WEBVOYAGE 2000.1 19 Users cannot limit by circulation status. The availability indicator does not work when there are multiple holdings.
(Contact: Thelma Diercks, Hamilton Library)
SUMMARY There are thirteen Technical Specifications which UHM could not test (e.g., retain invoice data and audit trails for five years) or has not yet encountered (e.g., processing of returned or voided checks). Endeavor has answered affirmatively to these thirteen specifications. Once tested, we assume that we will have the option to note discrepancies. What follows are some notable Technical Specifications which remain unfilled though Endeavor answered affirmatively. 8.1.4 HIGHEST SECURITY LEVEL. We asked for the ability to reverse totally any fiscal transaction. This level of reversal is not provided. Transaction must be deleted and redone. 8.1.8 PURCHASE ORDER RECEIVING REPORT. "Rage over a lost penny" (Beethoven 1795) might describe the frustration encountered by Endeavor and UHM in the attempt to produce the Report. UHM has found a workaround. 8.1.12 DISTRIBUTION OF P&H (ETC). UHM asked for calculation and distribution of miscellaneous charges over an invoice "by the system". Voyager is unable to do this. This continues to be a manual operation. 8.2.3 OPERATOR ALERT. Voyager accepts duplicate invoice numbers without alerting the operator and thus creates the potential for duplicate payment. 8.2.12 GLOBAL CHANGE. Endeavor did not answer yes or no to this Specification, but asked for clarification. The ability needed is to move a group of orders from one fund to another. Example: If a gift fund is received and orders placed on another fund can be appropriately moved to the new gift fund. PRIMARY REQUIREMENTS 8.1.3 System shall calculate costs in both foreign and US currency. Comment: Yes, the System does the dual calculation, but it is not seen until after invoice approval. We would prefer to see the figures prior to approval. Also, the conversion rate does not display until after approval. 8.1.4 System shall provide multiple security levels for all fiscal transactions, including: 4.1.4.5 at the highest level, total reversal of transaction. Comment: Though Endeavor answered affirmatively, total reversal is not possible. Transaction must be deleted and redone. 8.1.16 System shall link invoice data to specific orders/records, whether data entry is manual or electronic. Comment: Electronic linking has yet to be tested. 8.1.7 For invoices not connected to immediate receipt (e.g. prepayments, subscriptions, memberships, deposit accounts), system shall provide for the description of coverage and tracking of later receipts. Comment: Serials tracking of subscriptions is ok, but tracking of other methods as blanket orders is not possible. 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 system. Comment: The completion of the Purchase Order Receiving Report (PORR) is pending. Electronic interface with the University FMIS system is not yet in place. 8.1.11 System shall allow the establishment and maintenance of funds not tied to fiscal years (e.g. gift/endowment accounts). Comment: This is accomplished setting a distant closing date (e.g. 2050) which works, but is not completely satisfactory to the Fiscal Office. 8.1.12 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 8.1.12.2 calculated and distributed by the system over multiple items on an invoice. Comment: Distribution of a lump sum over multiple items on an invoice is not automatically done by the system; the operator must do it manually. 8.1.13 System shall allow, at the libraryÕs option: 8.1.13.1 electronic entry of invoice data via standard EDI (X12/EDIFACT). Comment: Not yet tried and tested. 8.1.15 System shall retain invoice data and audit trails online for the legally required five (5) years. Comment: Unable to test at this time. 8.2.3 System should alert the operator to potential duplicate payments. Comment: This specification is related to Acquisitions 4.1.70 (see below). The System accepts duplicate invoice numbers from different vendors (and the same vendor) and, thus, the potential duplicate payment is a real possibility. The System does not alert the operator. 4.1.70 System shall allow authorized staff to process invoices for payment, by using functions including but not limited to: 4.1.70.4 handle invoice numbers duplicated by different vendors. Comment: "Handle" was probably the wrong word to use. "Distinguish" or "differentiate" would have been better words. The System accepts duplicate invoice numbers from different vendors (and the same vendor). 8.2.5 System should allow payment from overexpended funds with appropriate authorization. Comment: EndeavorÕs comment is "Voyager allows the option to over commit and/or over expend a fund by a percentage set by the library. Different percentages can be entered for warning and for limiting Over Commit and Over Expend". This is true, but the intent of this specification was all an operator with appropriate authorization to override the Over Commit and/or Over Expend percentages based on net allocation. System does allow overriding. 8.2.7 System should allow the updating of currency conversion from tables from an on-line source with the proper authorization. Comment: The intent of this specification was to provide for automatic updating of the currency conversion table. We, unfortunately, omitted the words "by the system automatically". Yes, an operator with proper authorization can update the currency conversion table manually. 8.2.9 System should allow for the processing of credit memos, returned or voided checks, with proper authorization, and including: 8.2.9.1 a full audit trail for such transactions. Comment: Not yet tried or tested. This situation has not yet been encountered. 8.2.12 System should allow global change to a specific set of transactions by authorized staff. Comment: Endeavor responded "We need clarification on the types of transactions" and did not answer yes or no. An example of the type of transaction covered by this specification is the moving a group of orders charged to a fund to another fund (e.g. if a gift fund is received and orders placed on another fund can be appropriately moved to the new gift fund). 8.2.13 At the libraryÕs option, system should allow authorized staff to access invoice data by: 8.2.13.2 truncated invoice number. Comment: Not yet tried or tested. This situation has not yet been encountered. 8.2.14 System should allow authorized staff to search for invoice data by any and all of the following data elements: 8.1.14.4 account number. Comment: Searching by FMIS number or the vendor account number has yet to be tried and tested. 8.2.15 System should allow authorized staff to limit the above searches by any or all of the following data elements: 8.2.15.3 invoice date; 8.2.15.4 invoice date range. Comment: Not yet tried or tested. 8.2.16 System should provide for the archiving of fiscal records at the end of the legal five (5) year retention period. Comment: Not able to test. We would like to know how Endeavor intends to do this as they have answered affirmatively. 8.2.17 System should transfer payment information to a check printing/processing program external to the library (e.g. the UniversityÕs Disbursing Office). Comment: Not able to test connection between the Library and the Disbursing Office is not yet available. We would like to know how Endeavor intends to do this as they have answered affirmatively 8.2.20 System should provide a system to control credit card accounts. Comment: The answer is yes, but at this point the specification is up for discussion Ð what kind of system to control credit card accounts? 8.3.8 System should allow overencumbrance limits to be set either globally or by individual fund. Comment: Globally is not applicable here as limits are set for each ledger. 8.3.9 System should allow overexpenditure limits to be set either globally or by individual fund. Comment: Globally is not applicable here as limits are set for each ledger. 8.3.11 System shall provide a notes field for entry of a minimum of 200 characters of free text. Comment: Not yet tried and tested. 8.3.12 System shall allow authorized staff to set thresholds for encumbrances and expenditures in terms of percentage or dollar amount. Comment: Setting thresholds by percentage is possible, but not by dollar amount. Endeavor replied affirmatively probably because we used "or" rather than "and". 8.3.14 System shall allow authorized staff to designate a fund as active or inactive. Comment: What Endeavor had in mind when answering affirmatively we do not know, but we have found a workaround for this. 8.3.15 System should, upon request by an authorized staff member, report all funds which have cash balances. Comment: Again, the intent of this specification as with reports in Acquisitions is to have an online, interactive ability to query the system and get an immediate answer. We are aware that this kind of report can be done through the Reporter Module and the Systems Office. 8.3.16 System should allow encumbered items to be rolled over into the new fiscal year: 8.3.16.2 by specific designated fund. Comment: Roll over is by ledger only, not by specific designated fund. Endeavor replied affirmatively to this specification. 8.3.17 System should allow funds to be closed at the end of the fiscal year: 8.3.17.2 by specific designated fund. Comment: Fiscal Period Close is done by ledger and not by specific designated fund. Endeavor replied affirmatively to this specification. 8.3.18 System should report to the operator when a fund about to be closed contains an encumbered balance. Comment: This is accomplished by before FPC fund snapshot for an entire ledger, but the intent of this specification is to have a report that the operator can request interactively online. 8.3.22 System should allow authorized staff to export selected data to a spreadsheet or database program (e.g. Excel, Access). Comment: Not yet tried or tested. 8.3.23 System should allow authorized staff to view online all records encumbered on a given fund. Comment: Searching by fund is limited to the following options: fund name, fund code, ledger name, PO number and invoice number without the ability to qualify these searches by a specific status (e.g. only those records with approved/sent status). Searching by order has the option of searching by status, but retrieve all orders on all funds with the status being searched. 8.3.24 System should allow authorized staff to view online all records expended on a given fund. Comment: Same comment as 8.3.23. 8.3.26 If archived, System should purge records from the live file selectively as defined by the library. Comment: Not tried or tested. In this case, we need to know from Endeavor how this accomplished as the answer was affirmative. 8.3.27 If archived and purged from the live file, System should allow records to be retrieved on demand. Comment: Same as comments as 8.3.26. 8.3.28 If retrievable (searchable) system should allow export to a third party program (e.g. Excel) for manipulation and analysis. Comment: Regarding purging (8.3.26); retrieving (8.3.27), it is not known if these actions are possible. If they are, we assume the records can be exported, but obviously this needs testing.
(Contact: James Adamson, Hamilton Library)
9.1.7 Essentially Z39.50 is implemented in Voyager. Staff have concluded however, that it is not robust enough. It was decided to implement Z39.50 for the Library of Congress and Auckland. 9.1.8 We believe this requirement is met via entries listed under 9.1.8 and specifically with the statement, "data manipulation of any database element." We believe that with certification, certified department personnel can read, write and update database elements via customize programming. 9.1.15 The University of Hawaii defined "holdings" information differently than what Endeavor defined it to be. What we call holdings information, Endeavor calls "item" information. Currently we cannot find any way to export "item" information. 9.2.2.4 It appears Access Control which includes filtering by IP address for domain level access is not functioning properly (Gwenn) 9.2.5 Auxiliary system does not provide access to patron information, thus blocks are not implemented. During periods of non-access to the system, patrons can essentially by pass thresholds. 9.2.8 Upgrade release scripts for patches donÕt take into account virtual hosts implementations so Hawaii Systems programmers must manually fix all other directories for the virtual host after the patch script has been run. Further, in upgrade from version 99.1 to 2000 changes in database server (end1) did not have all the changes, as did the application server (end2). Endeavor assumed it was the same. Thus SystemÕs staff had to spend an hour with the system being down trying to get changes put in and WebVoyage searching up. During this time there was no searching. 9.2.10.3 Does not meet 9.2.10.5 Does not meet 9.2.10.6 Does not meet 9.2.10.11 Not all data is normalized (change in one place updates "all" occurrences, thus could lead to data integrity problems if an occurrence is forgotten about.) For example, the location element. 9.2.14 Item data associated with the MFHDS within the MARC format. (we have not determined how this is done.)
(Contact: James Adamson, Hamilton Library)
10.1.6 Only passwords are encrypted. Connections are not. 10.2 NOTE: Fault tolerant, High Availability (HA), and Compute Through Failure, these options only available with redundant hardware configuration. Administration did not choose this option due to costs. However, the Systems Department specified, designed and acquisitioned a triple mirrored disk array configuration for HA and recovery at the storage level. 10.2.9 NOTE: This option is available but Endeavor currently has this option turned off due to data loads being undertaken on the system.
(Contact: James Adamson, Hamilton Library)
All specifications met.