Sample Request for Proposal

Lincoln Trail Libraries System Information

The Lincoln Trail Libraries System Mission Statement

≥Lincoln Trail Libraries System advocates, collaborates, and facilitates education and cooperation to empower information agencies to improve and expand access to and delivery of information resources.≤

LTLS requests the Vendor respond to this mission statement in regards to how the Vendor can help LTLS meet this mission.

Lincoln Trail Libraries System Automation Goals

The LTLS goals that specifically address automation are as follows:

1. Expand and optimize core cooperative services

ÄContinue to support a shared integrated library system as needed by member libraries and the public

ÄSupport the contribution of quality bibliographic records to the ILS and OCLC

ÄEncourage additional libraries to participate in the ILS

ÄWork with other library and information agencies to provide broad access to the holdings of libraries regionally, statewide, nationally, and globally

ÄEnhance patron-initiated interlibrary loan

ÄSupport the continued development of tools to identify and locate bibliographic information

ÄIncrease access to full text information resources

2. Encourage and promote partnerships, collaboration, and creative information services

ÄWork to expand the ILS to support community information services

3. Explore and integrate new technologies and services

ÄWork with member libraries to digitize unique resources and make them available to the public

ÄExplore ways to utilize digitization technology

ÄResearch technologies hat are being introduced and evaluate the impact they may have on library information services

LTLS requests the Vendor respond to the automation goals in showing us how you will help us meet these goals.

Lincoln Trail Libraries System Plan for Selection of a Library Automation System

Description of Proposal

The Lincoln Trail Libraries System (LTLS) based in Champaign, Illinois, seeks proposals for a shared integrated library system (ILS) for member libraries. This document provides vendors of such systems with information required to prepare the proposals.

LTLS is a multi-type library system serving libraries in Champaign, Vermilion, Piatt, Douglas, Ford, Iroquois, Clark, Coles, and Edgar counties. The system serves a total of 124 libraries, including 53 public libraries, 9 academic libraries, 17 special libraries and 47 school libraries.

The automation consortium currently uses epixtechπs Dynix system.

Response Instructions

A. Issue of the Request for Proposal

This Request For Proposal (RFP) is issued by LTLS. The resulting contract will be administered by LTLS and the administrator shall be:

Jan Ison

Executive Director

Lincoln Trail Libraries System

1704 W. Interstate Drive

Champaign, IL 61822

B. Request for RFP Clarification

Questions and requests for clarification concerning this RFP shall be submitted to:

Pat Boze

Consultant

Lincoln Trail Libraries System

1704 W. Interstate Drive

Champaign, IL 61822

Questions shall be submitted in writing on or before 12:00 noon CST on ?. LTLS shall provide written responses, and any additional information as may be necessary, to all vendors to whom the RFP is known to have been distributed by LTLS, by 4:00 p.m. CST on ?.

All contact and communication regarding this RFP shall be directed to the above contact. Vendors shall not communicate with individual participating libraries regarding this RFP.

C. Proposal Submission and Due Date

The vendor shall submit one signed original and six copies of the signed proposal. An electronic copy of the responses to the Technical Requirements in Microsoft Word format, as formatted within the RFP, shall be included in order to facilitate the review and comparison of the proposals. A minimum of two copies of the original of any and all attachments shall be provided. All proposals must be received no later than 4:00 p.m. CST on ?

Proposal packets must be delivered to:

Pat Boze

Consultant

Lincoln Trail Libraries System

1704 W. Interstate Drive

Champaign, IL 61822

D. Proposal Validity

Vendors shall state in the proposal that all information in the proposal, including terms and prices, is effective and binding and will remain so for a minimum of 120 days from the due date of the proposals. Vendors shall be released from this binding once they receive notification of the acceptance of another proposal.

E. Compliance with Laws

The Vendor certifies that it is not barred from being awarded a contract or subcontract under Section 10.1 of the Illinois Purchasing Act.

The Vendor certifies that it has not been barred from contracting with a unit of State or local government as a result of a violation of Section 33E-3 or 33E-4 of the Illinois Criminal Code of 1961 [720 ILCS 5/33E-1 et seq.].

The Vendor certifies that it has or will disclose, under penalties of perjury, its correct social security number if an individual or sole proprietor, or its Employer Identification Number, if a partnership, corporation, or other entity; the manner in which it is doing business; and its state and United States residency status.

The Vendor agrees to complete, if awarded the contract, the Drug Free Workplace Certification which will become a part of the contract.

The Vendor certifies that it has not and will not commit a civil rights violation as defined in the Illinois Human Rights Act [775 ILCS 5/1-101 et seq.] and further agrees to take affirmative action to ensure that no civil rights violation is committed. The Vendor further certifies that it does not and will not discriminate in its employment practices against persons because of their race, religion, sex, place of national origin, or any other protected classification and that any subcontractors will so certify in their own contracts.

The Vendor certifies that they will comply with the Prevailing Wage Law of Illinois [820 ILCS 130/0.01 et seq.] and that any subcontractors will so certify in their own contracts.

The Vendor acknowledges the illegality of sexual harassment and acknowledges Illinois Public Act 87-1257 and certifies that it is, has been, and will be in compliance therewith.

The Vendor certifies that it is, has been and will be in compliance with all applicable Federal, State and local laws, regulations and ordinances pertaining to the performance of work hereunder.

The Vendor agrees and certifies that it will keep and maintain for a minimum of five (5) years after completion of the contract, adequate books, records, and supporting documents to verify the amounts, recipients, and use of all disbursements of funds passing in conjunction with the contract; the contract and all books, records and supporting documents related to the contract shall be available for review and audit; and the contractor agrees to cooperate fully with any audit. Failure to maintain the books, records and supporting documents required by this section shall establish a presumption in favor of the System or State of Illinois for the recovery of any funds paid under the contract for which adequate books, records and supporting documents are not available to support their purported disbursement.

F. Performance Bond

The vendor may be asked to provide a statement demonstrating financial ability to complete the project and a statement that the vendor meets indemnification and performance bond requirements. Vendor shall identify any cost to LTLS for a performance bond or indemnification in the total amount of the contract.

The bond shall be provided in a form acceptable to LTLS at the time contract documents are signed, and shall remain in effect for the duration of the contract or until final acceptance of the installed system by LTLS, whichever shall first occur.

No executed performance bond is required from proposers at the time of submitting a proposal.

G. Publicity and News Releases

No announcements or news releases pertaining to this solicitation of proposals, this project, the selection of proposers, or the award of any contract shall be made by the proposer or its representatives without the prior written approval of LTLS.

H. Proposal Contents

1. Information shall be included in the proposal in the order in which it is requested in the RFP.

2. Identify, in the proposal, any sections that include proprietary or confidential information that the vendor requests be treated as confidential material.

3. Include the RFP title and proposal due date.

4. Include one complete set of systems and user documentation that explains the
configuration, functionality, and operation of the proposed system.

5. Include a list of all hardware proposed, including make, model, quantity and capacity.

6. Include certification and statements of compliance with laws as requested in Section II E.

7. Include the vendor identification, including:

7.1. Name, address, telephone number, FAX number, and URL of vendor

7.2. Name, address, telephone number, FAX number, and e-mail address of the person(s) who will be representing the vendor

7.3. Signature of the officer of the vendor who is authorized to bind the vendor to all commitments specified in the proposal

8. Include a vendor profile, including:

8.1. A brief statement describing the nature, scope, and history of the firmπs business operations, its size, number and qualifications of key personnel, and number of years in business.

8.2. A brief history of the product(s) proposed.

8.3. A breakdown of the companyπs total staffing by function: sales and marketing, research and development, technical support, and administration and finance.

8.4. A description of the companyπs long-term strategy and plans to ensure that the system(s) proposed and the company remain viable in the market.

8.5. A description of how user participation is handled as part of the development process, and specify the methods used to receive, assess, and respond to input from participating libraries.

8.6. A list of the names, addresses, telephone numbers, contact persons, and e-mail addresses for five customers of products and services similar to those to be provided through this proposal. To the extent possible, customersπ profiles should be similar to that of LTLS.

8.7. Additional information to be provided for these customers includes 1) name and version of system purchased; 2) number of licenses/workstations; 3) modules currently in operation; 4) number of libraries in consortium; 5) size of bibliographic database and size of patron file; 6) operational date; 7) number of participating libraries; 8) server platform and operating system; and 9) URL of Web catalog.

8.8. Total number of operational installations of the proposed system.

8.9. Total number of operational installations of the proposed system with at least as many licenses as required by LTLS. Include customer name and number of licenses.

8.10. Total number of the vendorπs customers.

8.11. Total number of sales of the proposed system within the past twelve months.

8.12. Total number of sales to new customers within the past twelve months.

8.13. List of customers for which the proposed product replaced a Geac PLUS system.

8.14. Include a time line for the past two years for software upgrades and releases. Include the product name, release number, date of the release, and level of release (functional, patch/fix, etc.).

8.15. Identify the name and version of the operating system and database management system used.

8.16. Most recent annual report.

8.17. Most recent financial statement for the company or division responsible for the system being proposed.

8.18. Contact information for a bank officer able to warrant the companyπs financial condition.

8.19. A statement that the vendor carries full and adequate insurance as required by federal or state law, including workersπ compensation insurance, employees liability insurance, and general liability insurance.

8.20. Include any supplementary materials that may be helpful in reviewing the proposal and more completely understanding the products and services that would be provided.

9. Include a standard implementation plan, describing:

9.1. How the project will be scheduled.

9.2. Proposed levels of project staffing by vendor including a list of the personnel to be assigned to the project.

9.3. How the librariesπ policies regarding circulation, database access, privileges, etc., will be configured on the vendorπs system.

9.4. How the migration of bibliographic, item, authority, transaction, and patron records will be performed.

9.5. Vendorπs requirements for site preparation including space, power, humidity and other environmental requirements.

9.6. Vendorπs proposed training plan for library staff, including optional follow-up training within 90 days of operation.

9.7. Vendorπs procedures for handling software and hardware support and upgrades.

9.8. Vendorπs recommendation or requirement for a test or training server.

9.9. The vendor shall agree that the details of the final implementation plan will be mutually determined by LTLS and the vendor.

9.10. Issues included in the management plan are subject to discussion and revision in contract negotiations.

10. Include completed Mandatory Proposal Form as provided. A separate form shall be provided for each of the following options:

10.1. All current participating libraries as listed in the Appendix

10.2. All current participating libraries plus potential libraries as listed in the Appendix

10.3. Alternative server operating system (please specify), if available.

11. Include a statement on price breaks for additional quantity of licenses or additional capacity.

12. Include a proposed payment plan. Issues included in the payment plan are subject to discussion and revision in contract negotiations.

13. Respond to all items in Sections 1 through 16 of the Technical Requirements.

14. Owners, users, or other cooperative entities which are submitting proposals shall include current membership and governance documents that LTLS would be expected to accept.

I. Third Party Products

Any third party products included as a part of the vendorπs proposal shall be identified. The vendor shall state how maintenance for third party products will be provided and what arrangements the vendor has for continuing support should the third party product no longer be supported by its developer. The relationship of the vendor to that product, such as ≥authorized reseller,≤ shall be stated.

J. Proposal Clarification

LTLS reserves the right to request one or more written addenda to the vendorπs proposal to clarify one or more items in the vendorπs proposal. Such a request shall be made prior to the selection of a successful vendor. These addenda shall become part of the vendorπs proposal.

Timetable

The timetable for this project includes the following dates. It may be necessary for LTLS to adjust the dates throughout the process. Vendors will be notified of any changes.

RFP issued

Written questions due

Responses to vendor questions

Proposal due

Demonstration by vendor

Selection of proposal

Contract negotiations begin

Operational date

Lincoln Trail Libraries System Statistics

The following projected statistics shall be used to size the system. In all instances when determining the transaction capacity of the system, err on the generous side.

	Current Year	Current Year + 5 years
Titles	643,292
Volumes	1,901,385
Circulation	3,555,217
Patron Records	200,676
Serials Records	6,400
PAC Workstations	125
Staff Workstations	320

Materials Developed by LTLS

All software developed by LTLS acting without the Vendor shall be the exclusive property of the Library and/or College.

Hardware Purchases

LTLS reserves the right to obtain computer hardware and peripherals from whatever source it chooses. The Vendor will please comment on the maintenance of such hardware and peripherals obtained from other sources.

Cost Sheet Requirement

There should be no hidden fees or costs. All costs should be included in the cost section of this proposal. The Vendor is required to include a cost section detailing the software, hardware, peripherals, supplies and services it is providing. This should include quantity, item description, total cost and maintenance pricing. The Vendor is invited to provide optional products and services labeled as such.

General Vendor and System Information

The items in this section require a written response explaining where to turn for the requested information, or as a direct response to the issue.

Documentation

A sample of the documentation for all modules purchased shall be provided by the Vendor.

Required List of References

The Vendor must provide a list of three customer references by whom such software has been purchased; the list must include: Name of customer, address, contact person, and telephone number.

Contract Negotiations

Final resolution of all contract issues, language, and terminology will be made at the time of the final Library/Vendor negotiations. LTLS requests the Vendor include a sample contract.

Installation and Training

The Vendor shall provide detailed information describing the installation and training procedures provided for each module purchased and the costs for such training must be listed on the costs sheet as a separate line item.

Maintenance and Support Services and Costs

The Vendor will describe its maintenance/support program in detail. The library expects this to include: number of hours customer service is available, provisions for a toll-free support number, description of customer service on the World Wide Web, options for different support plans, how often enhancements to the software are expected, description of any user groups and listservs, and any other data the Vendor feels is relevant to maintenance and support.

System Description

Please include a summary of your systemπs capabilities, including screen shots.

System Architecture

Please describe your systemπs architecture, specifically addressing the issues of client/server, scalability and network compatibility.

System Modification

The system must allow the Library staff to change most parameters without Vendor programmer intervention and programming fees. These parameters may be modified or changed by the Library without consulting the Vendor at any time. Library parameters include circulation rules, statistical category definitions, library hours, passwords, and so on.

Reports Generator

The Vendor must describe the report generator and provide sample reports.

System Security

The Vendor must describe the security features available in all modules of the proposed system. The Library expects this to include security of each module and specific functions within each module.

System Backup

The Vendor must indicate how the system guards against data loss and/or corruption. Vendor should explain routine system backup procedures. The Vendor should describe whether the system must be down during backup or performed after hours.

System Specifications

Please answer the following questions with ≥Complies,≤ ≥Development Date ____≤, or ≥Does not Comply.≤ Further explanation can be given after the initial response.

O. General

0.1 The system must be built upon client/server technology,

0.2 The system must run on a network of any size and/or topology. Please describe networking compatibility of your system.

0.3 The system must be searchable via the Libraryπs web site.

0.4 The system must comply fully with the Z39.50 Version 3 standard on both the client and server sides.

0.5 The system must utilize an SQL relational database to store data.

0.6 The system must include the following modules: OPAC (for staff and patrons), Cataloging (with authority control), Circulation (with Self Check-out), Serials, Serials Binding, Acquisitions, Reserve Book Room, Media Scheduling, Inventory, Interlibrary Loan, Digization Scanning/Cataloging.

0.7 The system must be completely Windows-based, not just ≥screen scrape≤ technology.

0.8 The staff clients must run on Windows 95/98/NT/2000 or XP.

0.9 The server operating system must not be proprietary and must include a choice of HP-UX, AIX, Sun Solaris or Windows 2000/NT/XP.

0.10 The system must be fully scaleable. The Vendor will please discuss scalability of the system (i.e., the ability to add modules, clients and other servers over time).

0.11 Staff should be able to configure the system without vendor intervention. Please discuss the ability and ease of customization in the proposed system.

0.12 The system must accommodate multiple levels of security: network level, database level, application level, record and field level.

0.13 System user IDs must accommodate up to 30 characters.

0.14 The system administrator must be able to configure different data entry fields as ≥mandatory,≤ requiring the user to place information in that field (such as in patron records, POs, etc.).

0.15 The system must be coded in C, C++, or other industry standard languages. Please describe.

0.16 The system must include a single user interface for all modules, and must never require exiting from one module to do work in another.

0.17 This interface must have a consistent look and feel, and should be fully customizable by each staff member.

0.18 Each staff memberπs customizations should be tied to his or her log in and should travel with them from workstation to workstation.

0.19 Other applications such word processing, e-mail, and a web browser should be able to be launched from within the library application.

0.20 The system must load records, index, and perform other database management tasks during hours of normal use without degrading system performance or response time.

0.21 The ability to export statisticsl data for import into a database or spreadsheet application must be supported.

I. Public Access Catalog

Vendor: Please provide a brief summary of your systemπs Patron Access Catalog (PAC) module.

Public Access Catalog (PAC) refers to an integrated subsystem that allows patrons to search and browse the bibliographic database according to Library-specified parameters.

The on-line catalog must include a web-based interface and be easy to use both by novices and experienced users.

Please answer the following questions with ≥Complies,≤ ≥Development Date ____≤, or ≥Does not Comply.≤ Further explanation can be given after the initial response.

Standards/Environment

I.1 The system must be fully compliant with the MARC 21 and UNICODE standards.

I.2 The system should be able to search any Z39.50 compliant database or server.

I.3 The system must run on a TCP/IP network.

I.4 Commands should be executed via pull-down menus and command buttons.

I.5 The client must run in Windows 95/98/2000/NT and XP and make use of Windows navigation techniques.

I.6 The system must include a web-based interface; patrons should be able to search our system via the World Wide Web.

I.7 The system must have full multi-tasking capability; staff should be able to search PAC and edit a bibliographic record simultaneously without switching between modules.

I.8 The system must interact with the circulation system in real-time in order to show accurate holdings statuses.

I.9 The system must accommodate session pooling that allows multiple patrons to access the catalog with a single database license (there must not be simultaneous user limits for remote usage).

I.10 The system should have the ability to display device-friendly PAC screens on a handheld, small screen, mobile computing device, such as a personal digital assistant (PDA)

I.11 The ability to support a request module that alllows users to complete online forms to request services, including but not limited to the following at a system level: cancel holds, place holds. The ability to support a request module that alllows users to complete online forms to request services, including but not limited to the following at a building level: suggest purchases, interlibrary loan, suggestions or comments, reference questions, online patron registration.

I.12 The ability to report usage statistics including, but not limited to the following: number of searches by type of search, number of searches by time, in hours, frequency of terms entered, searches by hits retrieved, searches by workstation.

Indexing

I.13 The system must be able to index for searching any MARC or Dublin Core field or tag.

I.14 Must offer browsing by Author, Title, Subject, Call Number, and exact match indexes for LCCN, ISSN, and ISBN.

I.15 The system shall allow the Library the option of building a separate set of indexes for staff searches.

I.16 The system must allow keyword, alphabetic, and exact match searching.

I.17 The system must enable the library to set up their subject indexes so as to ignore ≥spacer characters≤ in alphabetizing the index. For example, Art, Ancient should appear between Art, AfricaãWest and ArtãBelgium. Setting up the index to ignore spacer characters should not be mandatory but should be an option.

Searching

I.18 Patrons must enter searches through a graphical, web-based user-friendly search screen.

I.19 The system must have easy-to-follow prompts throughout the inquiry process.

I.20 Patrons must be able to easily choose an index to search.

I.21 Multiple continuous spaces or space equivalents must be compressed to a single space.

I.22 Apostrophes, quotation marks, parentheses, brackets, and diacritic marks must be ignored. All other punctuation and special characters should be treated as spaces.

I.23 Character case must be disregarded.

I.24 Beginning a new search should require no more than one keystroke or mouse click.

I.25 The system must enable patrons to search the holdings of specified default group of libraries or all of the libraries in the system.

I.26 The system must inform the user of the number of records that satisfy the search specifications and display brief bibliographic data for those records. The user should be able to page forward and backward through the individual title records. The user should be able to see all ≥available≤ windows up to the point of the search in a stackable or cascaded format.

I.27 The system must allow the patron to move forward and backward in a search, exploring alternative paths without having to retrace the entire original search.

I.28 The system must retain on the screen the term or terms used as a search string for an inquiry against the database until the user goes to another search, to allow checking for errors in input if no matches are found and to validate which terms were found in the system.

I.29 The system must save previous searches done during the same session and allow them to be modified and reinitiated.

I.30 The system must be able to save search strings to hard disk for use in a future search session.

I.31 The system must allow the user to download, print or e-mail search results.

I.32 The system must automatically include ≥see≤ and ≥see also≤ references in the alphabetical listing of the authority forms in the authority list to direct the patron to the valid form.

I.33 The system must be able to go directly from a keyword search to browsing by the shelf list by call number or to browsing by title.

I.30 The system must allow the user to browse the authority list.

Advanced Searching, Sorting & Limiting

I.30 The system must be able to perform multiple-index searching.

I.31 The system must provide sorting of hits that are retrieved by at least two fields.

I.32 The system must provide search limiting once the initial result set has been retrieved.

I.33 The system shall provide search limiting by operators such as less than, more than, less than or equal to, more than or equal to, and equal to.

I.34 The system must provide pre-search restricting by item format and location.

I.35 The system must allow implicit Boolean searches. That is, the system allows users to enter keywords without Boolean connectors and process a search as if ≥AND≤ connectors were used.

I.36 The system must allow for the use of Boolean operators: AND, OR, NOT, and XOR.

I.37 The system must allow multiple terms in using Boolean operators.

I.38 The system must recognize a defined, right-hand truncation symbol in keyword searching.

I.39 The system must allow a selected search to be sorted by title, author, publisher, publication date, subject, or call number. It must allow a sort by publication date in descending order.

I.40 The system must allow simultaneous, broadcast searching of web content or licensed databases in addition to library catalog.

II.40 The system must have the capability to preformulate searches (with limits and sorts) and store them as HTML links, creating predefined searches.

I.41 The system must allow

Display

I.42 The system must display a brief record, with locations of holdings shown, if more than one location holds a particular title.

I.43 The system must indicate the branch and location in branch for each item displayed.

I.44 Must have color highlighting of keyword that is being searched on the display screen.

I.45 The system must allow the Library to define summary screen and bibliographic displays.

I.46 The system should be able to retrieve and display multimedia files (including Web sites) that are cataloged in a recordπs 856 tag.

I.47 The system should provide a list of newly acquired items displayable in categories (i.e., titles, serials, authors, etc.).

I.48 The system should be able to display MARC and Dublin Core record information for reserve items.

I.49 The system should give the library the option to displayãor not displayãthe next expected issue of a serial publication.

I.50 The system must display full-screen bibliographic and authority records.

I.51 The system must be capable of displaying enriched content, such as book covers, book reviews, summaries, and table of contents.

I.52 The system must have a Kids searching interface. It must be possible to switch easily between the standard interface and the Kids interface.

I.53 The system must have a Spanish searching interface. It must be possible to switch easily between English and Spanish.

I.54 The system must display thumbnail and full scanned images that reside in a digitized format, as well as accompanying cataloging information for that particular image.

Patron Empowerment

I.55 Patrons should be able to access their own patron records directly from the OPAC by entering their Patron ID numbers.

I.56 Patrons should be able to generate a list of items they have checked out.

I.57 Patrons should be able to display their own library fees/fines.

I.58 Patrons should be able to place a hold on a title directly from the OPAC.

I.59 Patrons should be able to place a copy-specific hold directly from the OPAC.

I.60 Patrons should be able to specify a date after which an item they have placed on hold is no longer needed.

I.61 The patron should be able to search for an item, and then place an interlibrary loan request for that item directly from OPAC.

I.62 The user should not have to re-type the bibliographic information when placing an ILL request; the system should retrieve the information automatically.

I.63 The system must enable patrons to renew their own materials.

I.64 The system must require the patron to enter their user ID before performing any of these patron empowerment features.

I.65 The system should enable patrons to mark bibliographic entries to a saved list, which can then be downloaded or emailed.

I.66 The ability to recognize remoter users and allow them to place holds on items on the shelf must be supported.

II. Cataloging Module

Vendor: Please provide a brief summary of your systemπs Cataloging module.

Standards and Environment

II.1 The database must be updated in real-time and must be shared among all modules.

II.2 The Cataloging module must be Windows-based.

II.3 Commands must be executed via pull-down menus and command buttons.

II.4 The system must provide full-screen MARC editing by mouse or keyboard. Vendor will describe or provide a sample screen.

II.5 The windows in the cataloging module must be movable and resizable. It must be possible to have two records open simultaneously side by side. Please provide a screen shot.

II.6 Cut, Copy and Paste commands must be available for MARC and Dublin Core record editing.

II.7 The system must be capable of merging bibliographic records, re-attaching all existing item records from the old bib to the new bib.

II.8 The database must store records for all types of media for which there is a defined MARC and Dublin Core record.

II.9 The Vendor must be able to convert any existing machine-readable database into the proper formats for the proposed system.

II.10 The system must handle any MARC and Dublin Core format (i.e., books, serials, AV, films).

II.11 The system must also allow multiple records to be edited at one time, with the ability to copy information from one record to the other.

II.12 Procedures for additions, modifications, and deletions online must be logical and easy to learn.

II.13 The system must recognize record-level and field-level security options. This security must prevent unauthorized users from accessing the SQL database.

II.14 The system must allow authorized staff members to record the owning institution for each bibliographic and authority record in the system.

II.15 Record ownership information that is contained in imported records must be retained upon import.

II.16 The system should support the UNICODE standard for multi-lingual cataloging.

II.17 The system should properly sort and sequence international characters in the list based on the index chosen.

II.18 The system must have the ability to index and allow access by a variety of classification schemes, including Dewey, Library of Congress, SuDocs, or free text must be supported.

II.19 The system must accommodate the MARC21 Format for Holdings Data.

II.20 The system must have the ability to incorporate US MARC validation tables to verify a high quality and consistency of cataloging input must be supported.

II.21 The ability to review the consequences of a global change to the database before it is made must be supported.

Cataloging Features

II.22 The system must provide a non-MARC bibliographic workform≠a simplified interface that allows staff members unfamiliar with MARC to catalog bibliographic records. This non-MARC bibliographic workform can also be used to catalog items not supported by MARC, such as Arabic records. The data should be stored in MARC-like format, allowing it to be stored, retrieved, indexed, and searched using the same processes as full MARC records.

II.23 The system must also provide bibliographic workforms in MARC and Dublin Core format.

II.24 The system must not delete items with the status of ≥checked out≤ and must inform the operator before deleting an item with a patron hold.

II.25 The library must be able to add fields to workform templates.

II.26 The system must handle brief records for items not fully cataloged, as well as materials for which full catalog records are not created and to which only identifiers are assigned for purposes of circulation control. This format shall be defined by the Library.

II.27 Authority files must permit appropriate ≥see≤ and ≥see also≤ cross-references.

II.28 Item records may be created manually or through batch creation.

II.29 Item records must be easily accessible from the parent bibliographic record with one keystroke.

II.30 When manually creating item records, bibliographic information found on the bibliographic record must be automatically transferred to the item records.

II.31                  When a second or third item is added to the collection, the following fields are assumed to be the same and are copied from holdings #1:
a.          Collection
b.         Call number
c.          Agency
d.         Item type (for circulation parameters)
e.          Publication date

II.32 Any field that is copied into a new item record may be edited at any time.

II.33                  The item record must contain, but must not be limited to, the following fields:
a.       Title
b.      Collection
c.       Call number
d.      Copy/volumes
e.       Item type
f.       Item statistical class
g.      Owning and lending agencies
h.      Price
i.       Publication date
j.       Added/modified
k.      Use count
l.       Date last used
m.     Hold status
n.      Patron ID number in hold queue
o.      Circulation statistics
p.      Number of times renewed
q.      In-library use statistics

II.30 Cataloging must be able to attach an item barcode prefix in its item barcode lookup command, so that users need only enter the significant digits in a search.

II.31 The system must be able to prevent specified bibliographic records from appearing in public access search indexes. For example, the system must be able to flag unshelved or lost items for display in search indexes that only library staff can view.

II.32 The system must accommodate three different kinds of search indexes:
a. staff only
b. public
c. combined staff and public

II.33 The system must be able to generate default 008 tags.

II.34 Authority-controlled fields must take the text entered and pass it automatically as a search to the authority file. The system must then present a display of entries from which the operator may select the appropriate insert. Authorized operators may, on the spot, create new authority records if no existing records are discovered.

II.35 The system must allow a list of holdings to be displayed. The operator may then add or modify items.

II.36 The entire record must be displayed, but only the portion of the field to be modified will need to be re-input. The Vendor must describe editing capabilities.

II.37                  The system must provide on-screen entry aids that provide the following:
a.       Tag description for the tag currently being edited
b.      Fixed field values via code list
c.       Coded lists of valid tags and subfields

II.38 The system shall display labels for each field or subfield when information is entered. Help screens should be available.

II.39 The user should be allowed to batch-create item records by specifying a starting and ending barcode number.

II.40 A code must be validated against a list of similar codes.

II.41 Item records must be established with suitable fields so that (for example) audiovisual records will be distinct from periodicals.

II.42 Records may be keyed manually.

II.43 The system must allow a staff member to search remote and local Z39.50 databases for MARC and Dublin Core records, and then send those records directly to Cataloging, to be modified and then saved directly to the database.

II.44 The system must generate and print a report of all new records with an LCCN, ISBN, or ISSN number matching any LCCN, ISBN, ISSN number already in the database.

Database Architecture

II.45 The database must not be proprietary, and must reside in a Sybase SQL or Microsoft SQL relational database.

II.46 Custom reports must be available via any SQL-compliant application.

II.47 The database must be able to store a varied number of variable-length single- and multiple-value fields.

II.48 Item records must allow for single and multi-value fields.

II.49 The system must be capable of creating and maintaining a bibliographic database with full USMARC and Dublin Core records and utilizing appropriate data from those files in each subsystem.

II.50 The system must be capable of creating and maintaining a bibliographic database with full European UNIMARC records and utilizing appropriate data from those files in each subsystem.

II.51 Records in the holdings file must be linked to the bibliographic file. Multiple copies of books, separate film prints, or individual series issues must share a common bibliographic file record.

II.52 Multiple agencies may share the same ≥title file.≤

II.53                  Bibliographic records must contain, but not be limited to, the following fields:
a.       Title
b.      Author
c.       Call number
d.      Imprint
e.       Publication date
f.       Edition
g.      Collation
h.      LCCN
i.       ISBN
j.       Series
k.      Generate notes
l.       Content notes
m.     Subject(s)
n.      Variant title
o.      Date added or modified
p.      ISSN

II.54 The system must accommodate library-defined MARC and Dublin Core tags.

II.55 The system must maintain only one file for each designated authority controlled field, regardless of the number of agencies sharing the database.

II.56                  The proposed system controls must allow restrictions on the input and reading of data. These controls include:
a.       Restrictions on staff who are allowed to add, delete, or modify the bibliographic record
b.      Batch deletion of tagged title within Library specified parameters (e.g., aging)
c.       Retaining on system records for which no holding exists, with display only to authorized users
         (i.e., no display in Public Catalog), with the option to purge
d.      Capability for authorized operators to replace all occurrences of a data field (e.g., change
         collection description from ≥R≤ to ≥Ref≤ in batch mode)

II.57 The system must be able to link bibliographic records. For example, the system must link the bibliographic record of a translation title to the bibliographic record of the original title; the system must be able to link all the editions of the same title together so that the patron can research and locate all copies that are directly related to the original title the patron retrieved.

II.58 The system must ensure that bib records are attached to valid authority records

II.59 Authority records must be accessible from bibliographic records with one keystroke.

II.60 The system must ensure that See Also references are attached to valid authority records.

II.61 The system must ensure that See references are attached to valid authority records.

II.62 The system must be able to display/edit serials Summary of Holdings within the Cataloging module.

Editing

II.62 The system must provide the ability to make global changes to authority records.

II.63 The system must use standard Windows navigation and editing techniques.

II.64 The system must include a spell-check feature.

II.65 The system must monitor the MARC and Dublin Core data displayed in the MARC and Dublin Core record and display incorrect or improper values in a separate frame.

Importing/Exporting

II.66 The system must be capable of importing records from bibliographic utilities such as OCLC and RLIN without having to use a specialized or dedicated workstation.

II.67 The Vendor must combine and overlay records from bibliographic utilities, using library-defined match points.

II.68 There must be an option not to overlay duplicate bibliographic records.

II.69 Users should be able to define local fields that should not be overlaid during the bibliographic import process.

II.70 The system must be able to batch export authorities.

II.71 The user should be able to specify whether imported records will convert to the USMARC or MARC 21 format.

II.72 The system must be able to schedule a specific date and time to import recordsãsuch as when the library is closed.

II.73 The system must import MARC 21 records into the system.

II.74 The system must transfer records across databases and servers.

II.75 The system must be capable of selecting a batch of authority, holdings, or bibliographic records for export or printing, based on a search for records that contain or match specified data such as date added or date deleted.

Authorities

II.76 The system must provide authority files for desired fields (i.e., personal and corporate names, series and subject headings) with appropriate cross-references for each.

II.77 The system must accept MARC-format authority file tapes.

II.78 The system must be able to import authority records online from outside sources.

II.79 Each heading in the authority file must be linked to each occurrence of that heading in the bibliographic file so that all occurrences of a heading may be modified globally.

II.80 The system must produce, on demand, a listing of authority files.

II.81 The system must permit multiple selection of authority records to attach to a bibliographic record simultaneously.

II.82 Only authorized operators may input authority records. These operators must have a password for this specific function.

II.83 Authority records may be created from within the general bibliographic file maintenance programs.

II.84 Whenever an authority file controlled field on a bibliographic record is entered or updated, the system must search the authority file to validate the forms.

II.85 If the form entered already has been established, then the system must assume the form is valid.

II.86 If the form has not been established, then the system must automatically display a relevant set of entries from the authority file, based on the data entered.

II.87 One of the authority entries may be selected or the new authority form may be added.

II.88 The system must be able to retrieve an authority record by authority key number.

II.89 The system must provide support for LC/MeSH headings, with the ability to create separate subject indexes based on the source of the authority headings.

II.90 The system must allow addition of authority records to be attached to multiple records without returning to the authority file.

II.91 The system must accommodate multi-use authority records (for example, a Mark Twain authority record that functions as both an Author Authority and Subject Authority record).

II.92 The system must support conditional authority headings, meaning that the system supports the ability to enter text in an authority controlled tag can either be controlled as an authority record or merely kept as uncontrolled text.

II.93 Information held in local subfields in authority records should be preserved and should not be modified in any way by the system.

II.94 The system must allow a staff member to attach authority records to multiple bibliographic records simultaneously.

II.95 The system must give the ability to automatically eliminate blind references.

Miscellaneous

II.96 The system must print spine and pocket labels.

II.97 The system must enable staff members to view the status or creation information for authority and bibliographic records. Staff must be able to view:
a. The recordπs creation date and time.
b. The name of the operator who created or updated the record.
c. The recordπs most recent update date and time.
d. The recordπs current cataloging status.
e. The date and time of the recordπs previous status change.

II.98 The system must accommodate copy records, as distinct from item records. Copy records represent multiple sets of a title that has several item records attached to it. The copy record is then attached to the titleπs bibliographic record. (For example, you might have four sets of the World Book encyclopedia with 26 volumes in each set. Instead of displaying an item record for every volume in each set, you can create a copy record for each set and attach it to the bibliographic record for World Book.)

III. Circulation Module

Vendor: Please provide a brief summary of your systemπs Circulation module.

Checkout

III.1 The system must read barcodes. Please describe what type of barcodes your system supports.

III.2 The system must allow entry of the borrowerπs and the itemπs identification/barcode using a light pen, barcode wand, laser scanner and/or keyboard.

III.3 The system must provide a check digit to assure that the numbers have been accurately entered. The system must alert the operator visually and audibly when the barcode label is incomplete or incorrect.

III.4 The operator must access a patronπs record by barcode entry, partial or full name search, student ID number, or other identifier.

III.5 The system must be able to check out items when the borrowerπs barcode card is not presented.

III.6 The system must alert the operator if no record exists for the patron entered, allowing for easy addition (completing only required fields on the patron record) and full checkout on first visit.

III.7 The system must use a temporary record and permit circulation of library materials that are not yet in the bibliographic database. At checkin, the system should alert the operator that only a temporary record exists, allowing the operator to complete the remaining fields.

III.8 When entering a temporary item record during circulation, staff must have the option to either fast-add both a bibliographic and an item record for uncataloged items, or to search PAC for an existing bibliographic record to which they can then fast-add an item record.

III.9 The system must automatically display on the checkout screen: patron name, patron barcode number, item identification number, short title, due date, due time (if applicable). Outstanding blocks must be automatically displayed when the patron record is accessed.

III.10 The system must checkout items with missing barcodes.

III.11 The system must allow a group charge in a single operation.

III.12 The system must charge/transfer materials to special borrowers/locations (i.e. bindery, mending, etc.).

III.13 The system must be able to check out multiple items after entering a single patron barcode.

III.14 The system must list outstanding holds for a patron on demand.

III.15 The system must automatically switch patron records if a patron barcode is entered when an item barcode is expected.

III.16 The system must check out materials that have been temporarily reassigned or transferred from another branch or borrowed from another library.

III.17 The system must have an automatic, web-based means of authenticating patrons who belong to other libraries which have reciprocal borrowing agreements.

III.18 The system must detect items that have not been checked in, allowing for a checkout function.

III.19 The system must ≥time out≤ after a library set interval (in seconds) to prevent items being charged to a subsequent patron on the previous patron validation.

III.20 The system should be able to interface with a self-checkout machine from 3M that allows borrowers to check out their own materials.

III.21 If the system includes a self-checkout feature within the system itself the vendor will please explain and describe.

III.22 The system must have an automatic address check at specified time intervals to maintain patron records.

III.23 The system must allow the library to determine circulation parameters according to item and patron (i.e., loan periods, fine rates, etc.).

III.24 The system must accommodate separate circulation privileges by location.

III.25 The system must allow an operator to adjust easily an itemπs assigned due date via the terminal keyboard for individual or unique conditions.

III.26                 The system must produce circulation slips, such as borrower receipts, for Circulation transactions. Borrower receipts must be generated for:
a.          single checkin
b.         group checkin
c.          single checkout (due date slips)
d.         group checkout (checkout receipts)
e.          payments
f.          refunds
g          renewals
h.         holds

Loan Periods

III.26 The system must allow any item to be checked out for any period of time (days, hours, or minutes).

III.27 The system must allow and adjust loan periods for holidays and closed library hours.

III.28 The system must enable staff to define special loan and fine rules that can override standard Circulation defaults.

III.29 The system must allow fixed due dates and multiple fixed due dates.

III.30 The system must allow for indefinite loan periods.

III.31 The system must allow the library to define the grace period used in circulating overdue items, fines, notices, etc.

III.32 The system must alert the operator if the loan period of the item is not the patronπs standard period, so that the borrower can be given the correct date due.

Checkin

III.33 Staff must be able to search PAC during checkout or checkin, and then return to checkout or checkin without having to rescan the ID card or barcode, or interrupting checkout or checkin procedures.

III.34 The system must check in items using (a) the current date and time, (b) yesterdayπs date (for book drop returns), and (c) date and time specified by the library.

III.35 The system must check in multiple items after entering a single patron barcode number.

III.36 The system must check in items by entering the item barcode by light pen, laser scanner or keyboard.

III.37 The system must check in items whose barcodes are missing.

III.38 The system must alert the operator if a copy belongs to another library location.

III.39 The system must allow the operator to print a checkin receipt for the patron.

III.40 The system must allow the following display at checkin: name, ID number of patron, title and due date of item.

III.41 The system must provide the option to exempt fees and fines as individual cases arise.

III.42 Exempting fines and/or fees should be a password-controlled function.

III.43 The system must break the link between the item record and patron record at checkin. A history of the patronπs checkout transactions should NOT be maintained, except in the instance of a damaged item checkin.

III.44 The system must alert the operator at checkin if an item is on hold, displaying either the name of the patron who has requested the hold or instructions for notifying the patron. The system must require operator acknowledgment before proceeding with the checkin.

III.45 The system must allow the operator to access information about the item being checked in without leaving the checkin function. The system must provide at least the following information: item barcode number, patronπs name, patronπs ID number, shortened title, and due date of item.

III.46 The system must allow the operator to search the item being checked in (i.e., in the event of a missing barcode, etc.) without leaving the checkin function.

III.47                 The system will alert the operator when items checked in have one of the following statuses:
a.          On hold
b.         Needs full cataloging
c.          Lost item (Found)
d.         Missing Item (Found)

III.48 The system must print a list of items tagged as ≥lost≤ after a specified period of time.

III.49 The system must permit an operator to tag an item as ≥borrower claims item returned,≤ and must keep a record of such tags.

III.50 The system must allow an authorized operator to change the status of an item being checked in (lost, claimed returned, damaged, etc.)

III.51 The date upon which any item is assigned a special status must be recorded on the item. This date may be used as a criterion for additional processing (e.g., assign all items ≥Missing since Feb. 1≤ to status of ≥lost≤).

III.52 The status of items may be changed by an authorized operator to any valid status (for example, ≥missing≤ to ≥lost≤) by entry of the barcode by lightpen, laser, or keyboard. The status of items with missing barcodes also may be changed.

III.53 The system must record on the item the date on which a special status was assigned. This date may be used as a criterion for additional processing (i.e., assign all items ≥missing since Feb. 1≤ to status of ≥lost≤).

III.54 The system must allow for additional library-defined statuses without programmer intervention.

III.55 Staff must be able to toggle between checkin and checkout with one keystroke.

III.56 The system must be able to create workslips for items needing to be cataloged and items in transit.

Blocks

III.57 The system must automatically alert the operator in the event of a patron or item block (i.e., non-circulation item, patron is impounded). Such blocks must require operator acknowledgment before checkout can proceed.

III.58 The system must allow the operator to view a detail screen of the block without leaving the checkin function.

III.59 Item and patron blocks must be library-defined. The system should allow the operator to easily display blocks, detailing reasons for block(s). All blocks must have the option to be overridden by an authorized operator.

III.60 The system must block patrons with overdue materials or unpaid fines with the option to override.

III.61 The system must allow payment in full or partial payment of fines and fees at time of checkout.

III.62 The system must check to see if an item is being held, blocking the checkout if an item is in the hold file. The system must allow an authorized operator to override the block.

III.63 The system must give the option to require a passkey when staff members attempt to override a block on certain borrower transactions. These transactions must meet any of the specific situations that are set by the library: number of items out, overdues, claims returned or lost, pending requests made, and the dollar amount of fines.

III.64 The system must automatically alert the operator of a patron or item block. The operator must acknowledge the block before the renewal can proceed.

III.65 The system must clear patron records of old blocks according to a specified date. Cleared records may be purged.

III.66 Staff must be able to delete blocks using a single command.

Renewals

III.67 The system must allow the operator to renew all items or an easily specified list of items. A single command should cause the system to renew materials without having to enter each item separately.

III.68 The system must allow the patrons to renew items by phone or in person.

III.69 The system must automatically calculate a new due date based on library-set parameters for renewals.

III.70 The system must allow the patron to renew overdue items with the request of payment or no payment. This must require an authorized operator.

III.71 The system must automatically tabulate and display all fines for each overdue item renewed and must post any unpaid amounts to the borrowerπs account.

III.72 The system must allow the operator to manually change the due date of renewed items.

III.73 The system must allow the library to restrict the number of renewals that can be made by a patron in person or by phone according to the patron or item type.

Fines

III.74 The system must allow each library/branch/agency to set independent parameters for fines, notice production, etc. Rates may vary according to location and type of material and type of patron.

III.75 An authorized operator may attach a fee to a patron record for any reason. A free-text message may be associated with the fee.

III.76 The system must calculate and display fines at time of checkin or renewal. Full or partial payment may be accepted at checkin. The system must permit a free text message for each line.

III.77 The system must print receipts for fines paid showing date, time, amount, and items for which money was received.

III.78                 The system must provide a way to track accounts receivable. The system must:
a.          Allow staff to track payments and changes by fee type
b.         Provide payment receipts and invoices
c.          Generates statistics and management reports.

III.79 The system must permit a free-text message for each line when accepting payment for fines or fees.

III.80 The system must permit an authorized operator to waive or modify system assigned charges. The system must prompt for an operator ID (e.g., initials, employee number, etc.).

III.81 The system must allow an authorized operator to access the patronπs fines and payments record, itemizing the details of each block.

III.82 The system must maintain a record of fines or fees levied, fines or fees waived, fines or fees collected by agency.

III.83 The system must provide data showing system-wide fines or fees collected for specified periods.

III.84 The system must print (on demand) billing notices for patrons exceeding the threshold levels of unpaid fines or number of overdues.

III.85 The system must, on demand, print overdue notice reminders of all materials overdue since the last printing or subsequent notice reminders.

III.86 The system must prepare a Final Notice incorporating the replacement price of the item.

III.87 If a book billed as a ≥lost book≤ is returned to the library, the system must automatically cancel the lost status and must produce a bill for outstanding overdues fines. Should the money have already been collected, credit due the patron must be prepared, minus a processing fee.

III.88 The system must purge outstanding bills for fines within specified date.

III.89 The system must create billing notices for damaged items.

III.90 The system must reprint (or partially print) a run of bills, notices, etc., within the same day.

III.91 The system must include unpaid balance for fines and bills to be included on all patron and availability notices.

III.92 The system must accommodate ≥reminder invoices,≤ where all current unpaid fees/fines can be combined onto one invoice.

Overdues

III.93 System must set a maximum fine amount and number of overdues that can be overridden with an authorized password.

III.94 The system should allow the library to specify text for overdue notices and allow sorting such notices by any field in the borrower record.

Holds

III.95 The system must allow holds to be placed: by TITLE such that the first-available copy will fill the request, and by ITEM such that only a designated copy will fill the request.

III.96                 The system must allow the patron to specify the notification method when placing a hold:
a.          mail
b.         phone
c.          electronic mail

III.97 The system must automatically check for a borrowerπs outstanding requests at checkout and renewal times.

III.98 The system must allow an operator to optionally specify a last acceptable date for a hold, after which time, the material is no longer needed.

III.99 The system must block a patron from placing more than one hold on the same item.

III.100 The system must allow the library to set a threshold for the number of holds that a patron can make.

III.101 The system must alert the operator when materials on hold are renewed or checked in, displaying either the name of the patron placing the hold or instructions to notify the patron.

III.102 The system must verify the correct patron is checking out material at time of the loan.

III.103 The system must allow easy hold cancellations, making a note on the patronπs record.

III.104 The system must allow an operator to optionally specify a last acceptable date for a hold, after which time the material is no longer needed. The system must automatically clear holds not filled by such dates and automatically readjust the hold queue.

III.105 The system must allow an authorized operator to view on-line the patron record for which a particular item is being held.

III.106 When circulation staff fills a hold, the system must automatically display any comments related to the request that were entered at the time the request was placed.

III.107 The system must prepare a ≥purchase alert≤ when the ratio of holds to the number of available copies exceeds a library-set threshold.

III.108 The system must produce notices alerting patrons of materials being held with an indication of when to pick up material, and by what date.

III.109 The system must allow for the printing of hold slips to be placed in items being held, showing the patron name.

III.110 The system must allow an authorized operator to review holds for any given patron.

III.111 The system must monitor the length of time items sit on the hold shelf. If the time exceeds the number of days defined to hold, the hold must be canceled and an appropriate note made on the patronπs record. If other patrons are in the queue, notification must be signaled for them.

III.112 The system must maintain multiple holds in a queue with oldest first.

III.113 The system must allow an authorized operator to view and alter the sequence of holds within a queue.

III.114 The system must be able to automatically generate a recall if the hold queue size reaches a library-determined threshold.

Borrower Information

III.115 The library will create the initial patron file by downloading from an existing database and in some cases by manual entry. If downloading from an existing database, the creation of patron records must allow importing of existing data from delimited ASCII format. The system also must allow for exporting of data from patron database in delimited ASCII format. Vendor must give the datafile structure to the Library.

III.116 The system must be able to import borrower records, with the ability to import multiple values for a single item (such as multiple addresses or phone numbers).

III.117 The system must allow operators to register patrons without exiting the checkout function.

III.118 When a patron record is fast-added during checkout, the system must automatically open the checkout window and display the newly-added borrowerπs name in the window.

III.119 Each of the data elements in the patron file must be variable length.

III.120               The information entered and stored in the patron database must include, but not be limited to, the following fields:
a.          Last name
b.         First name and middle initial
c.          Street address
d.         City and state
e.          Zip code
f.          Phone number
g.         Statistical categories to include:
            1. Birth date
            2. Location code.
h.         Sex
i.          Guardian ID
j.          Patron class code
k.         Registration date (mm/dd/yy)
l.          Expiration date (mm/yy)
m.        Bar code label number
n.         Delinquency, stop, lost/stolen card report, etc.
o.         Issuing library (may be apparent from bar code number)
p.         Date the card was last issued (mm/dd/yy)
q.         Date of last update to record
r.          Fines and charges
s.          Overdues

III.121 The system must be able to calculate the patron expiration date based on an established loan period, or assign a specific expiration date to each borrower type.

III.122 The library must control circulation policies by assigning a patron category to the patronπs record.

III.123 The system must allow an authorized operator to suspend borrower privileges.

III.124 The library must be able to define as many different patron type categories as they desire.

III. 118.           The following information must be stored in and linked to the patronπs record:
a.    Date of registration
b.   Number of items overdue and checked out
c.    Fine and/or other charge amount owing
d.   Payment
e.    Date of payment
f.    Identification of items on hold
g.   Default item loan period
h.   Date overdue notice sent
i.    Identification of items checked out
j.    Number of times patron claims returned items
k.   Patron status
l.    Message relating to patron

III. 119. The system must not allow duplicate patron records.

III. 120. The system must provide for coded fields to expedite the entry of patron information. Codes entered must be verified against a list of existing codes to ensure database integrity.

III. 121. It must be possible to search the patron file without exiting the checkout function.

III. 122. Patron information must be held confidential and must only be accessed by those operators who have the appropriate passwords and codes.

III. 123. The patron file must be accessed by using the patronπs surname, bar code, or another alternative identifier provided by the library.

III. 124.           The following information may be updated by an authorized person:
a.    Date of registration
b.   Number of items overdue and checked out
c.    Fine and/or other amount owing
d.   Payment
e.    Date of payment
f.    Identification of items checked out
g.   Default item loan period
h.   Date overdue notice sent
i.    Identification of items on hold
j.    Number of times patron ≥claims returned≤ items
k.   Patron status
l.    Message relating to patron

III. 125. The system must allow the operator to reassign a new barcode to the patron when a patron card is lost, changing the status of the old barcode to ≥lost≤ and the status of the new barcode to ≥active.≤ Patron information and items charged to the patron from the old barcode must be linked to the new barcode.

III. 126. The system must be able to reactivate patron barcodes that were thought to be lost but then were found.

III. 127. The system must not delete patron records that have patron blocks (overdue items, fines, etc.).

III. 128. The system must enable patrons to designate representatives who can check out and renew items in their names. The system must link the patron to the items checked out and to the proxy who completed the transaction.

III. 129. Patron statistical information may be obtained from a specific field or a combination of fields on the patron record.

III. 130. The system must provide a printed statistical report on the number of patrons currently registered, by patron status, type, and location (issuing agency/zip code).

III. 131.           The system must maintain on-line records of the following transactions by patron:
a.    total amount of unpaid fined
b.   total amount of unpaid charges for lost or damaged items
c.    current transactions or those items that are currently checked out to the patron
d.   date of last library transaction

III. 132. The system must provide a Save As option for notes and other lists (in case staff members want to save out a list of blocks or items).

Miscellaneous

III. 143. The Vendor must describe and provide sample circulation statistics and reports that are available.

III. 144. The system must track circulation statistics generated both by checkins and checkouts.

III. 145. There must be a backup circulation option to perform circulation activities in case the system goes down.

III. 146. The system must provide for a report generator for custom reports to be written and generated by the library.

IV. Acquisitions

Vendor: Please provide a brief summary of your systemπs Acquisitions module.

Standards and Environment

IV. 1. The acquisitions module shall be available from all staff workstations on the system to users with the appropriate passwords.

IV. 2. The acquisitions module should be graphical; commands should be executed via pull-down menus and command buttons.

IV. 3. The acquisitions module should run under Windows 95/98 or NT.

IV. 4. An interactive record structure shall be employed so that transactions on one record will cause changes in several online files.

IV. 5. Password security for the acquisitions module shall delineate a variety of access levels based on the functions performed.

IV. 6. Records in the acquisitions module shall be updated online in real time.

IV. 7. An appropriately authorized user shall be able to retrieve and change existing acquisitions records online.

IV. 8. Once an acquisition record is created, all further information shall be treated as an update to the initial record.

General Acquisitions Functions

IV. 9.          The following acquisitions functions shall be accommodated:
a.       Pre-order searching
b.       Ordering
c.       Claiming
d.       Cancellation of orders
e.       Receipt processing
f.        Fund accounting
g.       Vendor accounting
h.       Currency control
i.        Statistics and report compilation.

IV. 10.       A variety of types of materials shall be accommodated, including but not limited to, the following:
a.       Monographs
b.       Monographs in series
c.       Serials
d.       Law reports and statutes
e.       Continuations
f.        Documents
g.       Musical scores.

IV. 11.       The system shall accommodate and identify items in a variety of formats, including but not limited to:
a.       print
b.       microfilm
c.       microfiche
d.       microcard
e.       film
f.        video
g.       audio
h.       magnetic tape
i.        software.

IV. 12. The system shall report the current status of all titles ordered or received.

IV. 13.       Data stored in the acquisitions files shall include but not be limited to:
a.       Bibliographic information
b.       Acquisitions type (order, gift, approval, etc.)
c.       Status information (received, etc.)
d.       Library/branch/copy/fund information
e.       Invoice information
f.        Vendor information
g.       Vendor report information (i.e., vendor performance statistics).
h.       Basic fund accounting information
i.        Requester
j.        Location (i.e., destination)
l.        Instructions to vendor (free text)
m.      Internal processing instructions (free text; non-printing on order form).

IV. 14.       An acquisition record shall be accessible online through at least the following access points:
a.       Purchase order number
b.       Main entry
c.       Title
d.       Author/title key
e.       Library of Congress Card Number
f.        ISSN/ISBN

IV. 15. Data in MARC and Dublin Core format can be retrieved from external sources and used to overlay the short bibs created from order records.

IV. 16. The system shall permit the recording of holds against titles on order and in process.

IV. 17. The system shall provide for the retention of records under conditions such as: item out of print, publication canceled, order canceled, etc.

IV. 18. An acquisitions record shall be created for each title on order or received.

IV. 19. The system shall permit and maintain records of out of print and other canceled orders, and shall provide for purging the same in individual or batch mode.

IV. 20. The system shall accommodate desiderata files.

IV. 21. The desiderata file should be searchable.

IV. 22. The desiderata file shall generate ≥consider for re-activation≤ reports based on dates incorporated in desiderata records.

IV. 23. The system shall display the appropriate screen format and prompts for bibliographic information to be entered or transferred from elsewhere in the system.

IV. 24. No re-keying of information already in the system shall be required.

IV. 25.       The display for an acquisitions record shall include:
a.       Bibliographic information
b.       Acquisition type
c.       Status (activity) information
d.       Library/branch/copy/fund information
e.       Invoice information
f.        Vendor information
g.       Handling information
h.       Basic fund accounting information
i.        Requester
j.        Location (i.e., destination)
k.       Instructions to vendor (free text)
l.        Internal processing instructions (free text; non-printing on order form)

IV. 26.       The status (activities) information element shall include:
a.       Status
b.       The date the status was set
c.       A free text message area for further description of the status

IV. 27.       Valid statuses (activities) shall include:
a.       Record ready to have purchase order produced
b.       Entered partial
c.       Claimed
d.       Canceled
e.       Received partial
f.        Received complete
g.       Report information received from the vendor
h.       Returned partial
i.        Returned complete
j.        Invoice received
l.        Received without invoice
m.      Invoice claimed
n.       Invoice overdue
o.       Invoice paid
p.       Reorder

IV. 28. All of the statuses referred to in item 27 above can be ascertained viewing the activities which have occurred for each line. These activities can be viewed in summary or in detail for all or selected lines of an order.

IV. 29. Items are to be created at order time, receipt time, or on demand, depending on the setup designated by the library. Items are not created based on completion of an order. However, the user may create items on demand based on the completion of the order.

IV. 30. Any change in an acquisition file shall result in appropriate amendment of copy(ies) of that record in the bibliographic database.

IV. 31. The system shall be capable of accepting new bibliographic information about a title at any time after order placement or when its receipt is recorded.

IV. 32.       The system shall produce outputs in individual or batch mode, including, but not limited to:
a.       New or revised purchase orders
b.       Claim letters/notices/lists
c.       Cancellation notices
d.       Return notices
e.       List of cancellations
f.        Selection lists
g.       New title reports
h.       Purchase alert notices
i.        Hold availability notices
j.        Lists of invoices not cleared
k.       Vendor lists
l.        Vendor performance reports
m.      Open order reports
n.       Fund status reports
o.       Payment vouchers

Fund Accounting

IV. 33. The system shall be able to create an unlimited number of multi-level fund accounts.

IV. 34. The fund file shall be updated automatically to indicate file encumbrances and debits as a result of actions on the Acquisition file.

IV. 35. The system shall provide fund information updated in real time.

IV. 36. The system shall provide periodic, cumulative fund activity and commitment reports.

IV. 37. The system shall be capable of accommodating multi-fund shared acquisitions.

IV. 38. The system shall identify funds by codes of up to 7 characters and a year.

IV. 39. Encumbering should be automatic if a budget is identified.

IV. 40.       Fund file records shall include the following information:
a.       Amount budgeted
b.       Amount encumbered
c.       Amount expended
d.       Uncommitted balance
e.       Cash balance

IV. 41. When a proposed transaction would either over-encumber or overspend an account (i.e., draw the balance below zero), the user is warned by the system, but not prevented, from proceeding.

IV. 42. The system shall permit closing of accounts.

IV. 43. The system should be able to close out the prior yearπs accounts with or without moving encumbrances from the prior year forward as part of the close-out process.

IV. 44. The system should be capable of creating new accounts for a current or new year.

IV. 45. The system shall have the capability of producing reports for all funds for a specific budget/year.

IV. 46. The system shall be capable of reporting the number of items and titles received against a particular fund over varying periods of time.

IV. 47. The system shall be capable of producing vouchers for payment to vendors.

IV. 48. The system shall provide vendor name/address information for mailing by the library using window envelopes, if desired.

IV. 49. The system shall handle the conversion of foreign currency prices.

IV. 50. Lists of invoices not cleared or not cleared within a specified period after receipt shall be available upon demand.

IV. 51. Invoices shall be accessible by vendor invoice number.

IV. 52. The system shall accommodate refunds and partial order payments.

IV. 53. The system shall permit the sharing of order costs between funds.

IV. 54. The system shall be capable of calculating average annual costs for categories of materials by fund.

IV. 55. The system shall be capable of retaining fund accounting information online for a library specified period.

IV. 56. Once fund information is no longer required to be retained online, the system shall provide for output onto tape.

IV. 57. The system must be able to record expenditures not associated with online orders, for example: for items selected from vendorsπ warehouse shelves.

IV. 58. The system must provide a fund audit trail for any financial changes to the funds made by library staff.

IV. 59. The audit trail should track who made manual changes to fund balances, when they made the changes, on which fund the changes were made, and by how much the changes were made.

IV. 60. The system should enable a report generator to compile custom reports on the audit trail.

Ordering

IV. 61. The system shall permit online and off-line communication with, and ordering from, suppliers.

IV. 62. The system shall be capable of printing purchase orders on 8-1/2 by 11 inch multiple part forms.

IV. 63. The system shall be able to output purchase orders on paper forms or on magnetic tape.

IV. 64. The system shall be capable of transmitting an order outline such as accords with the NISO online ordering standard (BISAC).

IV. 65. It shall be possible to key in new acquisition records.

IV. 66. The system shall be able to handle reorders from another vendor.

IV. 67.       The system shall accommodate the following order types:
a.       Firm order
b.       Prepayment
c.       Selection list
d.       Gift
e.       Exchange
f.        Membership acquisitions
g.       On approval
h.       Blanket order
i.        Standing order
j.        Subscription
k.       Continuation
l.        Deposit Account
m.      US Government Document

IV. 68. The system shall provide a PO screen on which Acquisitions titles can be entered. Printed POs are to be produced on demand.

IV. 69. Vendor and item information shall be accessible and modifiable from the PO.

IV. 70. The system shall be capable of storing orders entered for later review and release by an authorized person.

IV. 71. The system shall support both the production of one purchase order for each title and the combination of orders to one vendor.

IV. 72. The system shall prohibit the assignment of duplicate order numbers, whether entered manually or assigned automatically.

IV. 73. The system shall allow the Librarian to conduct a ≥pre-order search≤ to see if a title has been ordered.

IV. 74.       It shall be possible to order the output of the following subsets of purchase orders:
a.       All purchase orders
b.       All orders for a particular vendor
c.       All orders for a particular fund(s)
d.       All orders for a particular order type(s)
e.       All orders for a particular location(s)

IV. 75.       Printing of purchase orders on paper forms shall be available (online or off-line) in batch mode. At least the following items shall be included on printed order forms:
a.       Author
b.       Title
c.       Edition (note field)
d.       Publisher (note field)
e.       Date of publication (note field)
f.        Series (note field)
g.       Number of the volume(s) being ordered
h.       Price
i.        Total number of copies being ordered
j.        ≥RUSH≤ indications (note field)
k.       Name of jobber
l.        Date of order
m.      System-supplied order number
n.       Free-text instructions (≥do not catalog≤)

IV. 76.       The following activities shall be performed concurrently with the production of purchase orders:
a.       Addition of purchase order number to vendor file
b.       Updating encumbrances in the fund file
c.       Sorting the purchase orders by vendor number

IV. 77. Online POs should closely resemble an actual printed PO.

IV. 78. System must accommodate multiple library billing and shipping addresses (for example, on a purchase order you can have items shipped directly to specified departments instead of the libraryπs main receiving area.)

IV. 79. System must be able to transmit electronic orders using the EDIFACT protocol.

IV. 80. The system must support Edifact and Enhanced Edifact (for order acknowledgement and order processing messages).

Receiving

IV. 81. The system shall be capable of maintaining routing records and producing routing slips.

IV. 82. The system shall be able to identify different copies from different sources.

IV. 83. The system shall be capable of handling receipt of items with invoices and invoices without items.

IV. 84. When receipt of an item is recorded, the system shall update all files, including vendor and financial files.

IV. 85. When the receipt of an item is recorded, the system shall automatically update the display associated with the copy of the acquisitions record in the bibliographic file from ≥on order≤ to ≥in process.≤

IV. 86. Upon entry of receipt information, the system shall update the vendor file, including vendor report statistics.

IV. 87. When receipt of a purchase order is complete and the invoice has been received, the acquisition record shall be flagged to allow its later deletion from the acquisitions file.

Vendor File

IV. 88. The module shall accommodate an online vendor file.

IV. 89. The vendor file shall accommodate vendor names and addresses, including order address, remittance address, claims address, and returns address.

IV. 90.       The vendor file shall accommodate vendor performance statistics.
a.       Titles Ordered and Received by Vendor
b.       Copies Ordered and Received by Vendor
c.       Amounts Paid (by Vendor) with subcategories for extra charges and materials
d.       Amounts on Account (by Vendor)
e.       Actual Cost vs. Unit Prices
f.        Average Fill Time (by Vendor)
g.       Average Percent Fill Time (by Vendor)
h.       Number of Claims by Vendor

IV. 91. A formatted screen shall be provided for entry of vendor file data.

IV. 92. Appropriate prompts shall be provided for keying of vendor file records.

IV. 93. Records in the vendor file shall be accessible by both vendor name and ID.

IV. 94.       Vendor file records shall include the following information:
a.       Vendor name
b.       Vendor address (order and remittance)
c.       Library supplied vendor claim period indicator
d.       Vendor statistics
e.       Discounts, by vendor
f.        Libraryπs vendor account number

IV. 95. It shall be possible to determine vendor performance as manifested by supply times and discounts.

IV. 96. The system shall be capable of printing the vendor file to provide a hard copy listing of all vendors used by the library.

IV. 97. The system shall be capable of supporting a default vendor option.

IV. 98. The system should generate vendor statistics by vendor and by date.

Claiming

IV. 99. Claiming shall be based on the vendor.

IV. 100. Claims may be forced or suspended by the operator.

IV. 101. Each vendor record shall contain a claim cycle default value.

IV. 102. The system shall automatically produce claim notices for purchase orders for which material has not been received by the time indicated by the claim cycle recorded in the vendorπs record.

IV. 103. Vendor performance data shall include the number of items claimed and canceled.

IV. 104. The claim cycle shall be capable of being overridden for a particular purchase order.

V. Serials

Vendor: Please provide a brief summary of your systemπs Serials module.

Standards and Environment

V. 1. The Serials module must be graphical; commands must be issued via pull-down menus and command buttons.

V. 2. The Serials module must be intuitive and easy to learn.

V. 3. The serials control module shall be available from all staff workstations to all who have the appropriate passwords.

V. 4. Interactive records shall be maintained so that transactions in one record cause changes in others.

V. 5.        The system shall include the following serials control capabilities:
a.          Check-in
b.         Claiming
c.          Routing
d.         Summary holdings, by copy
e.          Bindery preparation
f.          Report generation.

General Functionality

V. 6.        The system shall have the ability to accommodate all types of serials, including, but not restricted to:
a.          Periodicals
b.         Continuations
c.          Law reports
d.         Newspapers
e.          Annuals
f.          Governmental
g.         Memoirs
h.         Proceedings
i.          Transactions
j.          Indexes
k.         Supplements
l.          Loose-leaf material.

V. 7. The system shall be able to handle pocket parts, replacements, supplements, and other pieces related to a serial.

V. 8.        The system shall provide the ability to search for serials records by at least:
a.          Title
b.         Variant title
c.          Call number
d.         ISSN
e.          Publisher
f.          Vendor
g.         Budget number
h.         Purchase order number
i.          Location
j.          Uniform code
k.         Corporate author/title
l.          Conference title
m.        System assigned number
n.         SuDOC number
o.         Linked title
p.         Keyword
q.         Subject
r.          Language
s.          Bibliographic utility number.

V. 9. The system shall have the ability to distinguish among multiple copies from the same or different sources.

V. 10. The system shall be able to accommodate records of various numbers of screens.

V. 11. The system shall be able to list the holdings of individual facilities and locations separately, with a symbol for the location.

V. 12. The system shall be able to output brief subsets of bibliographic and holdings records for online or tape reporting to external union lists.

V. 13.          The system shall have the ability to produce a variety of statistical reports including, but not restricted to:
a.       Number of titles
b.      Number of volumes, reels, sheets, etc.
c.       Number of copies
d.      Number of issues checked in by period
e.       Number of claims issued by type, by supplier, etc., recorded in the system
f.       Number of titles purchased
g.      Number of titles received on deposit
h.      Number of titles received by gift or exchange
i.       Number of back issues or added copies received
j.       Statistical reports available by determined time periods, i.e., quarterly, semi-annually, etc.
k.      Statistical reports from individual libraries
l.       Titles without current subscriptions
m.     Total number of titles on subscription

V. 14. The system shall provide access to specific issues of a particular title without requiring scrolling through all of the holdings record.

V. 15. The system shall distinguish between bound and unbound volumes.

Serials Control

V. 16. Records shall contain current issue status separate from other holdings, binding records, and routing instructions.

V. 17. The system shall have the capability to show gaps in holdings.

V. 18. The system shall have the ability to print listings of gaps in holdings (i.e., list of missing issues).

V. 19. The system shall provide for records to note unwanted titles, withdrawn titles, canceled titles, and other negative acquisition decisions.

V. 20. The system shall provide an area within each record for special instructions, such as retention, special routing or handling, special check-in procedures, etc.

V. 21. The system shall be able to produce lists of subscriptions due for renewal within a library specified time period.

V. 22. The system must include a Staff Note field in all copy records.

V. 23. The system must support the reverse chronological display of serials issues, to aid in quick location of the most recently acquired issues.

Checkin

V. 24. For those titles which follow a predictable pattern of publication, the system shall base check-in procedures on the prediction of the expected chronology and enumeration of the next expected issue.

V. 25. The system shall support the check-in of multiple copies of an issue on a single check-in screen even when these copies are accommodated in separate copy records.

V. 26.          For titles with a predictable pattern of enumeration and chronology:
a.       Check-in of issues earlier or later than the next expected issue shall be possible by using a        minimum number of keystrokes.
b.      The operator shall not be required to key any data onto the check-in screen, except to indicate the      number of copies received when this is more or less than the number of copies expected by the            system.
c.       Check-in of issues earlier or later than the next expected issue may be accomplished by the     operator keying adjustments to the expected issue information displayed.
d.      Accept change of pattern of enumeration or chronology by authorized operator.
e.       The system shall be able to archive old check-in information and automatically create new check-      in screen.

V. 27. For titles which do not have a predictable pattern of enumeration or chronology, the system shall function so as to require minimal keying of data by the operator.

V. 28. The system shall be capable of locating a title for check-in by scanning SISAC issue identification printed on serials, as well as by operator keying.

V. 29. The system shall provide support for the input of item specific control numbers in barcode form from labels affixed to items during check-in processing.

V. 30. The system shall be able to print call number labels and routing slips at the check-in station immediately as an issue is checked in.

V. 31. The system must accommodate default prefixes and suffixes on labels; for example, you can create a prefix such as ≥Location≤ to appear before the location line on the labels.

V. 32. Printing of labels and slips shall be adjustable by an operator so that a group of products may be output at the end of a check-in session, or so that the capability can be suppressed altogether.

V. 33. The system shall have the ability to detect an attempt to check-in an issue which is in excess of the libraryπs identified requirements.

V. 34. The system shall provide the operator with direction as to appropriate action for handling the excess issue.

V. 35. The system shall be able to automatically identify issues of a serial that are overdue (i.e., that have not been checked-in).

V. 36.          Recognition of overdue issues shall be available regardless of whether or not the title is received on a paid subscription, and might include the following situations:
a.       Failure to receive any issues against a new order within a library specified period after the date of            expected first receipt recorded when the order was placed.
b.      Failure to receive the next issue within the expected time frame automatically determined by      calculations based on publication frequency data and a library specified ≥grace≤ period.
c.       In a title with a predictable pattern of publication, receipt of an issue later than the expected next issue.
d.      In a title with a predictable pattern of enumeration, receipt of an issue later in the numeric          sequence than the next expected issue.
e.       For titles which the library receives in multiple copies, receipt of fewer than the required number           of copies within a library specified time period after check-in of the first copy.
f.       For items which do not have predictable patterns of frequency or enumeration, identification of            items for which there has been no check-in activity within a library specified period.

V. 37. The system shall be able to display the check-in record with a minimal number of keystrokes.

V. 38. The system shall record automatically the date an issue is received.

V. 39. The system shall retain the receiving dates for at least the 105 most recent issues.

V. 40. The system shall accommodate a copy checkin note of unlimited length.

V. 41. System must allow serials to be checked in at multiple locations.

Routing

V. 42. The system shall be able to maintain routing records and produce routing slips.

V. 43. Routing lists shall be serial-specific; checkin priority on copies will ordinarily cause the first copy received to go to the first route defined. The operator may override and force a specific assignment, as needed.

V. 44. The recipient file shall accommodate recipientsπ names and locations.

V. 45. The system shall accommodate both standard and customizing routing lists.

V. 46. The system shall have the ability to prioritize the order of recipients on routing lists according to the priority of the individual and, secondarily, the recipientπs location.

V. 47. The system shall be able to provide a display or printout of all individuals receiving specific titles.

V. 48. The system shall be able to output printed routing lists at the checkin operatorπs terminal.

V. 49. Such lists shall be available individually or in operator-defined batches.

Prediction

V. 50. The system must allow you to create a prediction pattern for every serial record.

V. 51. Conversely, prediction patterns must not be mandatory; you must be able to create a serial record without creating a prediction pattern for that serial.

V. 52. Predictions may be created manually or from a template.

V. 53. Predictions may be copied from another titleπs setup.

V. 54. The system shall provide for all types of frequencies, and shall allow for easy adjustment if frequency changes.

V. 55. The system shall provide for up to seven hierarchical levels of serials holding enumeration.

V. 56. The system shall be able to display the enumeration and chronology of the next expected issue of a title recorded in the system.

V. 57. System must accommodate free text enumeration for enumeration that is not predictable.

Summary of Holdings

V. 58. For each copy, the system shall be capable of automatically summarizing individual issue holdings into a consolidated statement of holding.

V. 59. The automatic summarization capability shall be available for each copy.

V. 60. In the system, summaries of holdings shall be displayed separately for each copy, one after the other, in a single bibliographic display. Each material format is by definition a separate serial and, therefore, a separate copy.

V. 61. The system shall update holdings statements automatically by receipt of issue or bound volume.

V. 62. System must include a staff-only note field in the Summary of Holdings.

V. 63. System must include a Public Note field of unlimited length in the Summary of Holdings.

Claiming

V. 64. The system shall provide for forced claiming.

V. 65. Manual intervention shall override system-generated flags, if authorized.

V. 66. The time lag for second and third claims shall be defined on the vendor record.

V. 67. The claim cycle shall be capable of being overridden for specific items.

V. 68. The system shall provide for resetting the expected date or marking a particular issue as unavailable or not published.

V. 69. The system shall be able to delete claims from the claim cycle.

V. 70. Staff should be able to review claims before printing.

V. 71. Claims shall be transmitted to vendors via the ANSI X.12 standard.

V. 72. System must accommodate a Claim-to address for vendors; only claims are sent to that address.

V. 73. System must let you specify a date and recover/review all the claims that were sent on that date.

Bindery

V. 74. The system shall be able to indicate when an item is ready to be considered for binding.

V. 75.          The system shall support a variety of approaches for determining binding readiness, including:
a.       Upon receipt of the first issue in ≥next≤ volume
b.      At regular intervals specified by the library
c.       Receipt of index and/or title page
d.      Predictable receipt of binder furnished by publisher

V. 76. The system shall provide the library with the option to delay flagging for binding readiness until any outstanding issues have been received or removed from the missing issues file.

V. 77. The system shall provide access to lists of items identified as ready for binding for staff review both online and in print.

V. 78.          It shall be possible to select subsets of this file for review based on a variety of selection criteria including:
a.       Name of bindery
b       Range of dates during which items were flagged as ready for binding
c.       Location

VI. Reserve Book Room

Standards and Environment

VI.1. The Reserve Book Room module must be graphical; commands must be executed via pull-down menus and command buttons.

VI.2. The Reserve Book Room module must use the same database as the rest of the library automation system.

VI.3. The Reserve Book Room client must run on Windows 95.

VI.4. The Reserve Book Room module must keep records on instructors and courses.

General Functionality

VI.5. System must track and keep statistical information on reserve course materials.

VI.6. System must be able to place an item on reserve for more than one course.

VI.7. System must be able to associate a course with multiple instructors.

VI.8. System must be able to track reserve statistics.

VI.9. System must maintain permanent item information in ≥archive≤ while material is on reserve.

VI.10. System must have the ability to archive and subsequently re-activate reserve records, both manually and with automatic reminders.

VI.11. Reserve materials must be searchable by course instructor, course title, and course number.

VI.12. System must have automated workflows for flagging reserve materials.

VI.13. System must have automated workflows for withdrawing materials from reserve.

VI.14. System must accommodate shorter loan periods: minutes, hours and days.

VI.15. System must accommodate more than one course name in the same course record.

VI.16. System must accommodate default settings to reserve items with similar reserve information.

VI.17. System must include a Codes Lookup feature for data entry.

VII. Interlibrary Loan

Standards and Environment

VII. 1. The ILL system should be graphical; commands should be executed via pull-down menus and command buttons.

VII. 2. The ILL client should run under Windows 95/98 or NT.

VII. 3. The ILL server should run under Windows NT.

VII. 4. The ILL client should run on a Pentium PC.

VII. 5. The ILL client should interface with many library automation systems, such as Horizon, Dynix, and NOTIS.

VII. 6. The ILL system should comply with Z39.50 standards.

VII. 7. The system should be scaleable and configurable by library staff.

VII. 8. The system should be built upon a relational database.

VII. 9. The system should be able to accept requests from any library automation system via the ISO/ILL 10161 protocol.

VII. 10. The system should be able to search any Z39.50 source to retrieve information.

VII. 11. Client should run on a PC with these specifications as a minimum:
Pentium II
128 MB RAM
1 GB Hard Disk
Network Interface Card
Approved Network Package/Protocol
Windows NT v4.0 or higher
Color SVGA Monitor

ILL Functionality

VII. 14. The system should automate borrowing and lending activity among libraries.

VII. 15. The system should manage all activity on one database.

VII. 16. The system should link to the local circulation and patron databases.

VII. 17. The system should search local and remote library catalogs.

VII. 18. The system should interface with external messaging utilities via the ISO/ILL 10161 protocol or SMTP standard Internet e-mail protocols.

VII. 19. The system should interface with commercial document suppliers via the ISO/ILL 10161 protocol or SMTP standard Internet e-mail protocols.

VII. 20. The system should communicate with other ILL systems regardless of hardware and software issues, so long as they comply with Z39.69 and Z39.70.

VII. 21. Patrons should be able to submit ILL requests via the Internet.

VII. 22. Patrons should be able to submit ILL requests via e-mail.

VII. 23. Patrons should be able to submit ILL requests via any system that supports the ISO/ILL standard.

VII. 24. Patrons should be able to track the status of their request(s) through a Web interface.

VII. 25. The system should automatically notify patrons of the receipt of their requested information.

VII. 26. The system should interact with OCLCπs ILL system via the ISO/ILL 10161 protocol.

VII. 27. The system should allow staff to review patronπs ILL requests before they are transmitted.

VII. 28. Conversely, the system should not require staff to review patronπs ILL requests.

VII. 29. The system should keep a broad range of statistics.

VII. 30. The system should be able to generate a broad range of reports.

VII. 31. The system should capture and store statistics concerning the fulfillment of lending transactions.

VII. 32. Use of the system should eliminate any need for an ILL paper trail.

VII. 33. System must provide tools to assist the staff to determine the best and/or least expensive provider for the request based upon lending partnerπs profiles.

VII. 34. System must provide tools to search the local catalog for the itemπs availability.

VII. 35. System must send patron notifications by mail, e-mail, or fax.

VIII. Media Scheduling

VIII. 1. The system must enable a library to set up a separate collection and circulation process for media-related items.

VIII. 2. The system must employ a graphical user interface.

VIII. 3. The system must be fully integrated with other modules in the system and must use the same database.

VIII. 4. Audio-visual materials, media equipment, computer terminals, and conference rooms should be searchable and available for scheduling by authorized staff.

VIII. 5. Users must be able to search for an item by title or date range and view reserve schedules for those items.

VIII. 6. The system must use a single interface for both searching and scheduling.

VIII. 7. The system must use ≥hotkeys≤ for easy adjustment to reservations.

VIII. 8. The system must use pop-up calendars for date selection.

VIII. 9. The system must accommodate session defaults to speed order entry.

VIII. 10. The system must link to the main patron database for reservation purposes.

VIII. 11. The pickup location, return location, and operator ID must default to those most recently used.

VIII. 12. New reservation dates & times must also default to those last used since the program started.

VIII. 13. The schedule timeline must appear on the same screen where reservations may be edited.

VIII. 14. The scheduling capability must include a draggable time bar to adjust reservations. User must be able to drag just the beginning, just the end, or the entire time bar.

IX. Inventory and Backup Circulation

IX. 1. Circulation must be able to monitor the inventory status of any portion of a libraryπs collection.

IX. 2. The system shall support an inventory of any portion of the collections by scanning items on the shelves using a portable scanner.

IX. 3. It shall be possible to load the inventory results into the system and have the compared against the database and the transaction file of the library. The system shall produce a listing of all items not on the shelf or in circulation by comparing the inventory against both database and circulation records.

IX. 4. The aforementioned comparison shall include:

a. items shelved out of order

b. items missing from the shelves but not checked out

c. items checked out but on the shelves.

IX. 5. The inventory date must be added to the item record for each item inventoried.

IX. 6. The system must be able to perform inventory and normal circulation activities simultaneously without affecting accuracy of the inventory or degrading response times for regular circulation transactions.

IX. 7. Inventory must also identify bar-coded items found on the shelves for which there are no item records in the database (presumably items which belong to other libraries).

IX. 8. Staff must be able to use the portable scanner to record items used in the library but not checked out by scanning barcode labels on the materials before they are re-shelved and batch load those transactions to the database.

IX. 9. In the event of a server or network failure, it must be possible to record charge and discharge materials offline on a circulation or portable workstation and to load these transactions into the online circulation system at a later time.

IX. 10. The files of ID numbers of the ≥server-down module≤ should be batch processed to update the database when the server is brought back on‑line.

IX. 11. The system must allow simultaneous loading of downtime batch files from different branches when the system, or access to the system, becomes available without degradation of response time.

IX. 12. The system shall support an inventory of any portion of the collections by scanning items on the shelves using a portable scanner.

IX. 13. It shall be possible to load the inventory results into the system and have the compared against the database and the transaction file of the library. The system shall produce a listing of all items not on the shelf or in circulation by comparing the inventory against both database and circulation records.

IX. 14. The aforementioned comparison shall include:

a. items shelved out of order

b. items missing from the shelves but not checked out

c. items checked out but on the shelves.

IX. 15. The inventory date must be added to the item record for each item inventoried.

IX. 16. The system must be able to perform inventory and normal circulation activities simultaneously without affecting accuracy of the inventory or degrading response times for regular circulation transactions.

IX. 17. Inventory must also identify bar-coded items found on the shelves for which there are no item records in the database (presumably items which belong to other libraries).

IX. 18. Staff must be able to use the portable scanner to record items used in the library but not checked out by scanning barcode labels on the materials before they are re-shelved and batch load those transactions to the database.

IX. 19. In the event of a server or network failure, it must be possible to record charge and discharge materials offline on a circulation or portable workstation and to load these transactions into the online circulation system at a later time.

IX. 20. The files of ID numbers of the ≥server-down module≤ should be batch processed to update the database when the server is brought back on‑line.

IX. 21. The system must allow simultaneous loading of downtime batch files from different branches when the system, or access to the system, becomes available without degradation of response time.

X. Outreach/Homebound Services

X. 1. System must support a homebound or outreach service.

X. 2. System must create user profiles and maintain reading histories.

X. 3. System must manage selection, check-out, delivery, and return of items to special users.

X. 4. System must assign users to delivery route or shipping schedule.

X. 5. System must have ability to set and determine total number of items and/or format that users wishes at each delivery.

X. 6 All public and staff interfaces must comply with Priority Level 1 of the W3C Accessibility Initiative (WAI) guidelines. Compliance with Priority Level 2 is preferred.

X. 7 The ability to maintain an unlimited number of user profiles for an individual user must be supported.

X. 8 The ability to manage the selection, check-out, delivery, and return of items to special users and groups or users must be supported.

X. 9 The ability to add special services information to existing patron records must be supported.

X. 10. The ability to set and determine how frequently the user wants to repeat materials must be supported.

X. 11. The ability to maintain lists of seasonal materials that the user wishes to receive must be supported.

X. 12. The ability to easily identify materials that match a userπs interest profile must be supported.

X. 13. The ability to allow staff to accept or reject each suggested title individually or to accept the entire list with a keystroke must be supported.

X. 14. The ability to automatically place holds on selected items until they are retrieved from shelves by staff must be supported.

X. 15. The ability to modify the user record, including the routing, number of items requested, and other information must be supported.

X. 16. The ability to skip a scheduled delivery must be supported.

X. 17. The ability to suspend services to a particular user for an extended period of time or indefinitely must be supported.

X. 18. The ability to sort pick lists by call number must be supported.

X. 19. The ability to identify delivery route or location on the pick list must be supported.

X. 20. The ability to print packing slips and address labels must be supported.

X. 21. The ability to manage outreach records, including purging records, changing delivery schedules and routes, and deleting history records, must be supported.

XI. Digitization/Archiving

XI. 1. The ability to enable users to access stored material quickly and easily from their desktop using a Web browser and any appropriate viewers must be supported.

XI. 2. The ability to search, retrieve and view multiple media formats including those below must be supported:

text and images in ASCII, HTML, SGML, TIFF (CCITT Group 3 and Group 4), JPEG, GIF, BMP, PCX, DCX, and PDF and others; audio and video clips; streaming audio and video; other electronic files.

XI. 3. The ability to provide the following methods of searching and viewing media must be supported:

browse a hierarchical (tree) structure and view the metadata record and/or the media with a mouse click; search metadata records, with a full text search engine and view the search result list and then view the metadata record and/or the media with a mouse click; provide for full text searching of the textual information within captured documents, with natural language queries and then view the metadata record and/or the media with a mouse click; link to an automated library catalog, through fields, such as the MARC 856 field, and by clicking on the link access the archive for viewing of the metadata record and the media

XI. 4. The ability to receive and register published documents from an electronic document management system must be supported. The ability to accommodate digitized media and intelligent documents from other sources must be supported.

XI. 5. The ability to handle common image file formats must be supported.

XI. 6. The system should also be capable of supporting the following: native application as viewers, generic format viewers, portable document viewers, such as Adobe Acrobat PDF

XI. 7. The ability to provide access with multiple levels of control available must be supported.

XI. 8. The ability to enable an administrator to define the policies associated with metadata records must be supported.

XI. 9. Metadata records can be defined to contain either: attribute information or files

XI. 10. The ability to enable a user to create and modify metadata records must be supported.

XI. 11. The ability for a user to be able to select a åparentπ metadata record and the order within the åparentπ metadata record in which the new metadata record is to be created must be supported.

XI. 12. The ability to allow a user to delete metadata records and the files associated with the metadata records must be supported.

XI. 13. The ability to allow a user to create and modify a hierarchy of metadata records based on the configuration of the metadata record organizational policies must be supported.

XI. 14. The ability to allow a user to browse the metadata record hierarchy and view detailed information contained within any selected metadata record must be supported.

XI. 15. The ability to restrict access to metadata records and their associated files based on user access levels must be supported.

XI. 16. The ability to enable a user to import one or more files from a local or remote system and associate them with a metadata record within the archive must be supported.

XI. 17. The ability to scan images and associate those images with a metadata record with the archive must be supported.

XI. 18. The ability to enable a user to insert image pages within a metadata record when importing or scanning image pages must be supported.

XI. 19. The ability to enable a user to view a file associated with a metadata record must be supported.

XI. 20. The ability for the viewers to support the following types of files must be supported: TIFF (CCITT Group 3 and Group 4), JPEG, GIF, BMP, PCX, DCX, PDF

XI. 21. The ability to launch an external-viewing program to view a file type not supported within the included archive file viewer must be supported.

XI. 22. The ability to allow a user to navigate the image pages associated with a metadata record must be supported.

XI. 23. The ability to allow a user to do a word-based search to locate metadata records must be supported.

XI. 24. The ability to search the name and description fields of the metadata record and also support compound Boolean searches (AND, OR, NOT) when searching multiple metadata record types, must be supported.

XI. 25. The viewer must allow a user to: zoom in and zoom out of the currently displayed image, pan the view of the displayed image using a pan window

XI. 26. The viewer must allow a user to make basic image display adjustments while viewing the current document, including:

*scale to gray

*contrast

*brightness

*rotation

*scaling

*color inversion

*image mirroring

XI. 27. The ability to print a single page, a range of pages, or an entire set of pages associated with a metadata record to a user-specified printer must be supported.

XI. 28. The ability to enable an administrator to bulkload both metadata record data and associated files into the system must be supported.

XI. 29 The ability to configure how the graphical user interface positions windows, including their size and location must be supported.