UKCS Version 3.0 LMS Functional Requirements

United Kingdom Core Specification (UKCS) Functional Requirements for Library Management Systems

Compiled by Juliet Leeves Library Systems Consultant

Version 3.0 The UKCS has been made available free of charge due to the cooperation of Juliet Leeves and Ken Chad Consulting Ltd.1 It is downloaded from the LibTechRFP website.

If you require further help in reviewing your library systems or procuring new systems contact Ken Chad at Ken Chad Consulting. www.kenchadconsulting.com

Creative Commons Attribution Share-Alike Non-Commercial 3.0 License.

You are free: to Share — to copy, distribute and transmit the work to Remix — to adapt the work

Under the following conditions: Attribution — You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). Noncommercial — You may not use this work for commercial purposes. Share Alike — If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

With the understanding that: Waiver — Any of the above conditions can be waived if you get permission from the copyright holder. Public Domain — Where the work or any of its elements is in the public domain under applicable law, that status is in no way affected by the license. Other Rights — In no way are any of the following rights affected by the license: Your fair dealing or fair use rights, or other applicable copyright exceptions and limitations; The author's moral rights; Rights other persons may have either in the work itself or in how the work is used, such as publicity or privacy rights. Notice — For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to this web page.

Prepared in consultation with: DS Ex Libris UK Infor Innovative Europe IS Oxford Sirsi/Dynix Talis Information Systems

1 For the background to this imitative see: 'Making it easier to specify systems'. By Ken Chad & Juliet Leeves. CILIP Libraries+Information Gazette. 2nd December 2010. Available from the Ken Chad Consulting website http://www.kenchadconsulting.com/wp-content/uploads/2010/12/Making_it_easier_to_specify_systems_Dec2010.pdf UKCS Version 3.0 LMS Functional Requirements

©Juliet Leeves 2007 2 UKCS Version 3.0 LMS Functional Requirements

How to use the UKCS

The UKCS has been developed to reduce the effort involved in specifying standard functionality which is available on all library management systems (LMSs). It was compiled in consultation with a number of LMS suppliers who agreed a core set of requirements, together with a variant set to meet the needs of differing market sectors. The model agreed with suppliers for the UKCS was a checklist of basic functions which could be expected on any LMS. The checklist is intended to form one part of an Operational Requirement (OR), which is normally included in an Invitation To Tender (ITT) in formal procurement procedures. However, it can also be used in less formal procedures as a simple checklist of features.

It is important to recognise that the UKCS is not an accreditation scheme, and whilst suppliers have agreed a core set of functions which should be available on any LMS, validation of individual supplier responses remains the responsibility of individual libraries. It will still be necessary to evaluate core functionality at supplier demonstrations and site visits – for example, libraries will want to ensure a sensible workflow for the issue process, where a ‘full compliance’ response has been given in the core specification. Libraries will not, however, have to spend time specifying basic functionality in detail or evaluating equally detailed responses, but can concentrate on areas of functionality which are not provided on all systems – in other words, on the differences between systems.

The UKCS should not be regarded as a generic specification, but rather as the core of a complete specification, which will take into account both local requirements and the relative importance of the core requirements. It is essential, therefore, that libraries review the requirements in the UKCS, paying particular attention to the Importance column (explained below), rather than just including the UKCS as an ‘added extra’. This will also help avoid duplication of requirements and wasted effort.

The UKCS is, by definition, geared towards UK market requirements. Terminology is as used in the UK (e.g. supplier rather than vendor, reservation rather than hold). Where necessary, compliance is required with UK law, e.g. Disability Discrimination Act.

Checklist model

The UKCS takes the form of a checklist which details core functionality for the following main functional areas:

 Bibliographic database management  OPAC and end user services  Circulation control  Acquisitions  Serials control  Document delivery and inter-library loans  Management information

©Juliet Leeves 2007 3 UKCS Version 3.0 LMS Functional Requirements

The checklist comprises the following columns:

Requirement number

Each number is prefixed by R for core requirement or V for variant requirement. Libraries should not change the numbering or text of these requirements – this is because suppliers will have set up standard responses to the UKCS.

Additional requirements or changes to the standard requirements for these functional areas should be specified in a separate section of the OR. Other requirements, such as technical, training and support etc, should also be covered separately (see below for what is not covered).

Type

For variant requirements, the type of library is given: A (Academic), P (Public) and/or S (Special).

Requirement

This column contains a text description of the function.

Importance

There is provision for libraries to indicate the importance of each requirement. The following values are suggested:

3 Important (or mandatory) 2 Highly desirable 1 Desirable 0 Not required (or not applicable).

The reason for the zero value is for libraries to indicate to suppliers where a core or variant requirement is not required or not applicable. This allows for the checklist to be used by a wide variety of libraries which may place differing importance on these requirements, or indeed not need them at all. This can also be used to indicate where a complete functional area is not required – for example, if the Document Delivery function is not needed, all requirements in this section could be marked zero and suppliers instructed not to respond to this section.

It is important that requirements are flagged as not required or not applicable, even if the other values are not used. This is so that suppliers will know they do not have to respond to the requirement. Academic libraries, for example, should flag any variant public library requirements (P) as not applicable.

Compliance

This column should be left blank for suppliers to indicate their compliance with each requirement. The form of the supplier’s response should be defined by the library and made clear in the instructions to suppliers. One of the following forms of response is suggested:

1) Yes/No response – this is the simplest form of response for the checklist approach. Suppliers should be instructed that ‘Yes’ means fully supported and on general release.

©Juliet Leeves 2007 4 UKCS Version 3.0 LMS Functional Requirements

2) Response codes – the following codes are suggested:

A Fully supported and on general release B Partially supported and on general release C Planned for a future release D Not supported

Additional information – libraries can indicate in their instructions to suppliers if they want suppliers to provide additional information along with the compliance rating. Some libraries find it helpful to have additional information, perhaps explaining how a particular requirement is met. It should be remembered, however, that all these responses have to be read (!) and many of the core requirements can be regarded as standard. A compromise might be to flag a requirement (e.g. by an asterisk) if additional information is required.

Suppliers can also, at the discretion of the library, be invited to add their own comments, if they feel a particular response needs further clarification, e.g. if a ‘partially supported’ code is used, or a date if planned for a future release.

Further instances where additional information can be useful are detailed below.

Evaluating suppliers’ responses is one of the most time-consuming parts of the procurement process, and it is often difficult to differentiate between systems, particularly at the functional level. A large number of the core requirements will be available on all library systems, and the differences may lie in newer aspects of functionality or local requirements, which will be specified separately. The advantage of the UKCS is that it allows libraries to concentrate on critical and important aspects of functionality, over and above the core list, safe in the knowledge that the basic functionality is covered. It is also important to recognise that the functional evaluation is only one part of the process, and other evaluation criteria will be equally, if not more, important, such as supplier viability, technical aspects and, not least, cost.

Instructions to suppliers

Instructions to suppliers are normally covered in the ITT. It is important that instructions and information concerning the UKCS are given, including:

 codes to be used for indicating importance of requirements  how to respond to requirements which have been coded as ‘not required/applicable’  forms of response for compliance  instructions regarding additional information.

What is not covered

The requirements covered by the UKCS relate to core functionality for the main functional areas listed above. As already mentioned, additional requirements for these areas should be specified separately.

Library management systems often include optional software for other services, such as resource discovery systems/portals, e-resource management and reading lists. These are not currently covered by UKCS. In any case, they may often be supplied independently of the LMS.

©Juliet Leeves 2007 5 UKCS Version 3.0 LMS Functional Requirements

Requirements relating to inter-operability with local or corporate systems, e.g. customer contact centres or organisational portals, are not covered and would need to be specified separately.

The UKCS concentrates on library-system specific functionality, and does not cover general techniques provided by underlying operating systems, e.g. Windows techniques such as cut and paste, drop down menus etc.

Users should be aware that functional requirements form only one part of an OR. An OR will normally consist of the following sections:

 Introduction  Background information  Technical requirements, e.g. database, networking and operating systems, system operation and administration, character sets, data migration, barcodes/RFID tags, inter-operability with other local or corporate systems  Functional requirements (UKCS plus additional local functional requirements)  Optional software requirements, e.g. resource discovery system/portal, e-resource management, reading lists  Support and training requirements  Various appendices including statistical information about the library

The OR will itself normally form part of an Invitation to Tender (ITT) where a formal procurement is involved. For further advice concerning tender procedures and contracts, libraries should consult a procurement professional.

Standards

Whilst it is important that the relevant standards are specified in the UKCS, the checklist approach may not be sufficient to determine compliance, and this is one area where libraries may wish to ask for additional information to ascertain how the standard is implemented (often involving the use of profiles) and how it affects functionality. A useful guide to standards issued before 2002 is ‘The RFP Writer’s Guide to Standards for Library Systems’ which can be found at: http://www.niso.org/standards/std_resources.html. As stated previously, it is important to follow up how standards are used at system demonstrations and site visits.

A particular UK difficulty relates to inter-library loans (ILL). Whilst the UKCS includes reference to the international ILL protocol (ISO 10160/10161), it has also been necessary to include requirements for the British Library Document Supply Centre ARTTel and ARTEmail systems, because only these systems support the full range of services and delivery options which BLDSC offer (the ISO/ILL gateway ARTISO does not yet offer the full range of delivery options).

Customisation

Throughout the UKCS, reference has been made to ‘library-defined’ options, e.g. screen layouts, fields and field labels, indexes, record displays etc. Libraries may wish to ascertain through additional information from the supplier, whether such customisation is done by the supplier or by the library, and if done by the library, whether any special expertise is needed. It is also suggested that suppliers are asked if software upgrades impact on any configuration done by the library. As before, it is important that libraries see the actual interface for system configuration at supplier demonstrations and site visits.

©Juliet Leeves 2007 6 UKCS Version 3.0 LMS Functional Requirements

Disclaimer

Every attempt has been made to provide accurate information in the UKCS, but the author accepts no liability for errors or omissions, or for loss or damage arising from using the UKCS.

The guidance given in the section ‘How to use the UKCS’ does not constitute definitive or legal advice and should not be regarded as a substitute therefor. The author does not accept any liability for any loss suffered by persons who consult this section, whether or not such loss is suffered directly or indirectly as a result of reliance placed on guidance given in this section.

©Juliet Leeves 2007 7 UKCS Version 3.0 LMS Functional Requirements e e c Type Requirement c n n a a i t l r p o p m o m I C

1. General functionality The system must: incorporate the following functions: R1 bibliographic database management (including authority control) R2 OPAC and end user services R3 circulation control R4 acquisitions R5 serials control R6 document delivery and inter-library loans R7 management information R8 be integrated with data only needing to be entered once to support all functions R9 support realtime updating in all functions R10 track staff operations for audit purposes R11 provide for progressing material through the various stages of processing, so that at all times the current status of an item can be shown, e.g. on order, in cataloguing R12 provide for multi-site operation R13 comply with the relevant provisions of the Disability Discrimination Act 1995 R14 comply with the Web Accessibility Initiative Level AA R15 comply with the relevant provisions of the Special Educational Needs and Disability Act 2001 R16 comply with the provisions of the Data Protection Act 1998 Operation and user interface The system must: R17 provide a graphical user interface in all functions R18 provide for direct access between functions where workflows dictate this R19 allow staff to initiate a database search from any point in the system where workflows dictate this R20 provide for use of function/hot keys for frequently used functions R21 allow navigation tasks to be performed via the keyboard as well as with a mouse R22 allow different searching/display options for staff for different functions R23 allow library-defined inactivity time-outs in all functions Help R24 The system must have help facilities, to include: R25 screen examples R26 context-sensitive help R27 search option for help on given topics R28 tutorials Customisation and configuration The Library must be able to customise the system in the following areas: R29 screen layouts for public access ©Juliet Leeves 2007 8 UKCS Version 3.0 LMS Functional Requirements

R30 bibliographic fields and field labels R31 indexes R32 record displays R33 help texts R34 The interface for system configuration must be consistent with the rest of the system Access to the system R35 Access to the system must be password protected R36 Access should be prevented if a pre-set number of tries is exceeded The system must allow: R37 different levels of access to functions/sub-functions according to level of user R38 suppression of disallowed options R39 restriction of groups of users/workstations to specific functions R40 maintenance of access levels by the Library

2. Bibliographic database management General The system: R41 must provide for creating and maintaining bibliographic records must support: R42 MARC21 R43 Dewey (current edition) R44 Library of Congress classification (current edition) R45 Library of Congress Subject Headings (current edition) V1 A/S MeSH (current edition) R46 ISO 2108 (ISBN, current revision) R47 must allow extra local bibliographic fields to be defined R48 must not impose limits on record, field or subfield size, or the number of fields in a record (beyond that imposed by the MARC format) Record import and export The system must: R49 allow online access to a range of library-defined databases using Z39.50 (current version) and provide for the import of bibliographic records R50 provide for the import of authority records R51 provide for the import of records in batch and in realtime, i.e. direct to the cataloguing screen R52 allow imported records, which match records already on the database, to overwrite or merge with those records, or be rejected, according to library- defined parameters R53 allow the export of records in MARC21 exchange format Record creation and editing The system must: R54 provide a full-screen edit interface for creating bibliographic records R55 allow for library-defined templates for different types of material, e.g. monographs, serials R56 provide both a MARC and labelled input interface R57 prevent the creation of duplicate records by allowing pre-searching and matching on various fields including control numbers (ISBN, ISSN) R58 allow existing records, from external sources or the internal database, to be

©Juliet Leeves 2007 9 UKCS Version 3.0 LMS Functional Requirements

copied and used as the basis for a new record R59 allow data common to more than one record to be duplicated for a succession of records R60 validate ISBN-10 and ISBN-13 R61 validate ISSNs R62 allow for adding new copies to an existing record R63 provide for the online deletion of bibliographic records; it must not be possible to delete a bibliographic record if it still has item (copy) records attached R64 provide for immediate retrieval on all access points defined by the library Authority control The system must: R65 support MARC21 Authorities format allow for authority control on certain fields, to include: R66 authors R67 subjects R68 series R69 provide for the creation, editing and deletion of authority records R70 allow access to authority records during record creation for checking/selecting headings R71 allow display of works associated with an authority heading R72 allow for global changes of headings and merging of headings, with associated records amended automatically Electronic resources R73 The system must allow for the input of URLs, URNs and other URIs in bibliographic records for electronic location and access information R74 The system must incorporate a link checker Item (copy) record management R75 The system must allow unique item identifiers (e.g. barcodes, RFID tags) to be assigned to item records on the system R76 There must be no effective limit to the number of item records linked to the bibliographic record R77 It must be possible to specify library-defined defaults for item data and to copy item data from one record to another R78 It must be possible to mark copies as withdrawn or deleted R79 The system must give a warning if the last copy is being withdrawn or deleted R80 It must be possible to assign a replacement item identifier to an item, and transfer all transaction data to the new item record Stock management R81 The system must provide a stock checking facility, allowing the use of portable devices to store and upload item identifiers (e.g. barcodes, RFID tags) to the database, and report inconsistencies R82 The system must provide routines for bulk changes of data, e.g. location, loan category

3. OPAC and end user services NB: The term OPAC is used to refer to both staff and end user access to the system. The requirements are defined in the context of a web-based OPAC.

©Juliet Leeves 2007 10 UKCS Version 3.0 LMS Functional Requirements

General The system must: R83 provide an online public access catalogue (OPAC) for use by end users R84 provide additional access to the bibliographic database for staff use only in the different functions, to include: R85 additional indexes R86 ability to access all records in stock, on order, in process etc. R87 additional information relating to loans, borrowers, items on order etc. R88 additional displays, e.g. MARC format R89 The system must support Z39.50 (current version) client and server R90 It must be possible to display help, including examples, on search screens R91 It must be possible to suppress certain categories of material from display to the end user on the OPAC (e.g. no copies available for loan/request) R92 It must be possible to suppress individual bibliographic records from display to the end user on the OPAC Indexing The system must allow the Library to define: R93 which fields/subfields or combination of fields/subfields are indexed for the different search options R94 which search options are offered to staff and end users R95 the type of indexing applied, e.g. keyword, phrase/browse (i.e. with implicit right-hand truncation) The system must be able to sort the classification index for the following schemes, in accordance with general principles for the scheme: R96 Dewey (current edition) R97 Library of Congress (current edition) Interface The system must provide: R98 a simple (novice) interface, including non-Boolean searching R99 an advanced search interface, including: R10 explicit use of Boolean operators AND, OR, NOT 0 R10 specific fields to search 1 R10 left-hand truncation 2 R10 right-hand truncation 3 R10 wildcards 4 R10 links on search screens and results displays to other search options, e.g. 5 browse index R10 at all times, a display of the current search 6 Searching R10 It must be possible to perform a keyword search across all defined indexes 7 or on selected indexes R10 All commands and search keys must be case-insensitive and it must be 8 possible to ignore diacritics and punctuation for searching R10 The system must allow searching using variant spellings

©Juliet Leeves 2007 11 UKCS Version 3.0 LMS Functional Requirements

Search limits The system must offer the ability to pre-limit searches: R11 by date (including open and closed range of dates) 0 R11 by language 1 R11 by format of publication (e.g. video, serial) 2 R11 to particular collections 3 R11 by location 4 The system must offer the ability to post-limit searches: R11 by date (including open and closed range of dates) 5 R11 by language 6 R11 by format of publication (e.g. video, serial) 7 R11 to particular collections 8 R11 by location 9 Display of search results and navigation The system must: R12 provide different levels of display (brief, full) and allow the Library to 0 define which elements in a record are included in each display R12 allow default sort order of search results to be library-defined for each 1 search type R12 allow the user to be able to change the default sort order 2 R12 allow users to view serial holdings, including serials check-in and latest 3 issue information R12 display the record immediately in the event of a single hit being retrieved 4 (rather than intermediate index display) R12 support hypertext links between elements in records allowing highlighted 5 index terms to be used as the basis of further searches R12 support hypertext links from cross references to authorised headings 6 R12 support hypertext links from bibliographic records to other electronic 7 information resources both local and remote via URLs, URNs and other URIs Output and saving The system must: R12 allow users to mark or select references for printing and downloading 8 R12 allow users to review and edit the list and to sort items 9 R13 allow users to download lists of saved records to disk or e-mail or to send 0 to an attached or network printer

©Juliet Leeves 2007 12 UKCS Version 3.0 LMS Functional Requirements

R13 offer a range of output formats for exported records, including: 1 R13 full and brief records 2 R13 MARC21 3 R13 ASCII 4 R13 EndNote 5 R13 ProCite 6 R13 library-defined formats 7 Self-service options R13 The system must allow users access to their own records and transaction 8 details (as authorised by user ID/PIN). Transaction details must include: R13 loans 9 R14 reservations 0 R14 fines 1 R14 ILL requests 2 R14 purchase requests 3 Users must be able to: R14 make reservations 4 R14 cancel reservations 5 V2 A make bookings for short loan material R14 make renewals 6 R14 make ILL requests and view progress 7 R14 make purchase requests 8 R14 update their contact details 9 R15 The system must interface with automated telephone renewal systems for 0 self-service renewals via this method, using the SIP2/NCIP standards R15 The system must interface with self-issue/return devices using the 1 SIP2/NCIP standards R15 All circulation parameter settings (e.g. loan rules, borrower blocks) must 2 also apply to self-service functions

4. Circulation control Circulation policies R15 Circulation policies must be library-defined ©Juliet Leeves 2007 13 UKCS Version 3.0 LMS Functional Requirements

Circulation policies must be determined by a combination of: R15 borrower category 4 R15 item category 5 R15 location 6 Circulation policies determined in this way must include: R15 loan periods (expressed in days, weeks, months, extended/fixed date) 7 R15 reference only 8 R15 loan entitlements (per item category and overall) 9 R16 renewal periods (according to method, e.g. phone, self-service etc) 0 R16 renewal limits by method 1 R16 reservations - charges 2 R16 reservations – allow/disallow 3 R16 reservations - maximum number (by item category and overall) 4 R16 reservations - loan period reduction if more than one 5 R16 reservations - length of time held on reservations shelf 6 R16 reservations - expiry period for unsatisfied reservations 7 R16 fine rates (normal and special rates, e.g. overdue reserved item) 8 R16 maximum fines 9 R17 charges – subscription/membership 0 R17 charges – hire charges 1 R17 notice production – type (e.g. overdue and frequency) 2 R17 notice production - format (e.g. print or e-mail) 3 R17 It must be possible to apply library-defined grace periods 4 R17 The system must maintain a calendar of closed dates for each location. All 5 circulation transactions including due dates, fines, recalls and reservations awaiting collection must take account of closed days R17 Authorised library staff must be able to update parameters with immediate 6 effect General circulation functions

©Juliet Leeves 2007 14 UKCS Version 3.0 LMS Functional Requirements

R17 The system must provide automatic blocks/alerts on borrowers, including: 7 R17 expired ticket 8 R17 outstanding fines/fees (library-definable threshold) 9 R18 overdue/recalled items (library-defined threshold) 0 R18 over entitlement 1 R18 Automatic blocks/alerts must be automatically removed 2 R18 The system must allow authorised staff to input manual blocks with an 3 explanatory message R18 Authorised staff must be able to override any borrower or item block. 4 R18 The system must show the status of items (e.g. reserved, awaiting 5 collection) at all times to both staff and end users R18 The system must maintain a loan history for both items and borrowers, 6 retrievable for a library-defined period R18 The system must support the circulation of uncatalogued items and 7 recording of brief information when issuing, using library-defined defaults for loan control and trapping such items on return to allow full details to be input R18 The system must allow for loans of multiple sets, e.g. music, drama sets 8 V3 P The system must allow end users to borrow, return and renew items at any service point V4 P The system must alert the operator to items which need to be returned to their ‘home’ location and manage the transit of such items, showing their current status at all times Issue, return and renewal R18 It must be possible to enter the unique item identifier (e.g. barcode, RFID 9 tag) by machine (e.g. scanner, reader) or manual input R19 Item identifier only must be required for return 0 R19 Borrower and item status must be automatically checked on all three 1 functions; any blocks/ accompanying messages must be displayed with an audible warning R19 It must be possible to override the calculated due date at the point of 2 issue/renewal, subject to borrower and item checks R19 Borrower expiry date must override due date; warning of imminent expiry 3 date must be given on screen R19 The system must allow a means of ending the current transaction (to 4 prevent the issue of items to a previously accessed borrower) V5 A It must be possible to backdate the date of return to accommodate book drop returns R19 The system must allow for flagging items as ‘claimed returned’, leaving the 5 item linked to the borrower as a claimed returned item but suppressing notices and fines R19 It must be possible to flag items as ‘lost’, leaving the item linked to the

©Juliet Leeves 2007 15 UKCS Version 3.0 LMS Functional Requirements

borrower as a lost item, but suppressing notices and fines R19 The system must alert staff of ‘lost’ items on issue and return 7 R19 It must be possible to flag items as ‘damaged’ and alert staff and end users 8 on issue and return R19 It must be possible to flag items with multiple elements, e.g. triple CD 9 packs, and alert staff/users on issue and return to ensure sets are complete The system must: R20 allow bulk renewal of all items on loan (subject to borrower and item 0 checks), or selected items R20 prevent renewal of overdue items (library defined threshold), reserved or 1 recalled items, and items over the renewal limit allow for renewal of unseen items via: R20 telephone 2 R20 self-renewal via OPAC 3 R20 self-renewal via automated telephone answering service 4 R20 flag method of renewal 5 R20 provide direct access to the borrower record for personal details and details 6 of loans, fines and reservations, from issue, return or renewal functions R20 provide direct access to the full item record, including reservation 7 information, from the borrower's loan record Fines and charges The system must: R20 show details for each fine or charge, e.g. the loan which incurred the fine 8 R20 accumulate fines and charges for payment in a single transaction 9 R21 allow for payment to be accepted either in the Return function or by direct 0 access to the fine payment screen from the Return function R21 allow payment in full or part against any individual charge 1 R21 allow payment in full or part against all charges 2 R21 allow authorised staff to waive all or some fines/charges owing. The 3 reason for the waiver must be recorded. R21 It must be possible to defer payment (at the discretion of the library) 4 R21 It must be possible to record the payment method 5 V6 P The system must enable group payment of fines, e.g. families R21 It must be possible to print receipts of fines/charges paid on attached or 6 networked printer R21 The system must include cash management functions to enable balancing 7 of income received on the system with that recorded on tills R21 It must be possible to set a default replacement cost (where cost not 8 specified on item record) for lost books R21 It must be possible to set processing/administration fees

©Juliet Leeves 2007 16 UKCS Version 3.0 LMS Functional Requirements

R22 Financial history should be retrievable for a library-defined period 0 R22 It must be possible to handle other charges, including: 1 R22 subscription/membership charges 2 R22 hire charges 3 R22 reservation charges 4 R22 library sales 5 R22 The system must allow refunds to be made and recorded 6 Reservations The system must: R22 allow title-level (first available copy) reservations by staff and end users 7 R22 allow item category and copy specific reservations by staff only 8 V7 P allow grouping of locations to satisfy reservations R22 allow/disallow reservations on items on order 9 R23 allow/disallow available items (i.e. on shelf) to be reserved if reservation 0 placed in the library R23 automatically notify staff at each site of reservations for items not on loan 1 (remote reservations) for shelf check R23 allow staff to record ‘not found’ status against remote reservation request 2 R23 allow for remote reservation requests to be routed between sites if on shelf 3 copy at more than one site R23 allow for a default collection point to be specified which can be changed if 4 required by staff/end users R23 allow reduction of loan periods when there are outstanding reservations on 5 items R23 allow generation of recall notices for reserved items (recall item due back 6 soonest), and reduction of the loan period R23 alert staff of a reservation on an item on return from loan and notify the 7 requester that the item is awaiting collection R23 alert staff/end users if a reservation is awaiting collection, whenever the 8 user record is accessed R23 allow for reservations to be cancelled automatically on expiration 9 R24 allow for reservations to be cancelled manually by staff (with provision for 0 reason) R24 Staff must be able to change the order of the reservation queue 1 R24 It must be possible to set an expiry date for uncollected reservations, with 2 automatic notification to staff (to remove from reserve shelf) R24 It must be possible to set an expiry date for unsatisfied reservations, with

automatic notification to end users Bookings R24 The system must support booking of equipment, e.g. PCs, either directly on 4 the system or via an interface with a bookings system using SIP2/NCIP standards Borrower records R24 It must be possible to import and update borrower information from the 5 organisational database R24 The system must be able to generate a PIN number automatically or to 6 accept an externally derived PIN R24 It must be possible to create/edit borrower records manually in addition to 7 importing them V8 P It must be possible to duplicate data common to more than one borrower, e.g. family details R24 Fields for the borrower record must be library-defined. Standard fields 8 must include: R24 name 9 R25 address (provision for at least two addresses) 0 R25 e-mail address (provision for at least two addresses) 1 V9 A automatic use of address by date (term/vacation) R25 telephone numbers 2 R25 borrower category 3 V10 P date of birth (under 18s) V11 P home branch V12 A location/department V13 A course R25 joining date 4 R25 date of expiry 5 R25 last use 6 R25 free text notes/messages 7 V14 P The system must provide an automatic change to borrower category, once the borrower reaches 18 R25 Borrower records must be accessible by name and number 8 R25 Library staff must be able to delete borrowers' records, in bulk or 9 individually, except where current transactions or blocks are outstanding R26 It must be possible to delete records by the date of expiry 0 R26 When a library card is being replaced, the existing borrower's details must 1 be carried across from the old card R26 It must be possible to flag a borrower barcode/library card as ‘lost’, 2 prohibiting transactions on that card and alerting staff when it is used

R26 The system must be able to generate unique user numbers and accept 3 numbers from an externally derived source Notices R26 The system must allow automatic generation of notices, including: 4 R26 overdue letters 5 R26 fines 6 R26 replacement costs 7 R26 recalls 8 R26 notification of item awaiting collection 9 The system must allow notices to be generated in a range of formats, to include: R27 print 0 R27 e-mail 1 R27 SMS messaging 2 R27 Text and format of notices must be library-defined 3 A Short loans V15 A The system must allow for short loan periods to be set, including both hourly and overnight loans V16 A Hourly loans must cater for both rolling hourly periods (e.g. items due back four hours after issue) and fixed times V17 A It must be possible to maintain items in a short loan collection by allocating temporary short loan status linked to courses and reading lists V18 A It must be possible to set specific parameters for short loan items, to include: V19 A loan periods V20 A loan entitlements V21 A renewal periods V22 A renewal limits V23 A reservations V24 A fine rates V25 A notice production V26 A The system must support bookings of short loan items for a given date/time P Mobile library services P The system must offer equivalent circulation functions to mobile libraries, to include: V27 P issue, return and renewal of items V28 P borrower loans and messages V29 P fines and charges V30 P interception of reserved items V31 P borrower registration V32 P borrower search ©Juliet Leeves 2007 19 UKCS Version 3.0 LMS Functional Requirements

V33 P OPAC search V34 P It must be possible to list all stop points and group them into routes V35 P Loans must be associated with a stop point/route V36 P The system must support bulk renewals of all loans at a stop point (for use if stop point is postponed) V37 P Mobile library transactions must be synchronised with the main library system P Housebound services P The system must support services to the housebound to include: V38 P profiles and borrower history of housebound readers to enable selections to be made V39 P generation of pick lists V40 P issue and return of selected items to individual housebound readers according to specific parameters V41 P block issue and return of selected items to day centres, homes etc according to specific parameters P Project/group loans V42 P It must be possible to group multiple items for issue under a single ‘parent’ identifier V43 P It must be possible to return items from the project/group loan individually V44 P The system must automatically return the ‘parent’ item when the last on- loan item in the group has been returned V45 P It must be possible to unlink on-loan items from the project/group loan, so that the rest of the project/group loan can be re-issued P Stock rotation V46 P It must be possible to move collections of stock from branch to branch on a rotating basis V47 P The rota must incorporate dates for transfer of collections and produce an alert when collections are due to be moved V48 P Items on loan in a collection must be routed to the new location Back-up circulation R27 In the event of system or network failure, there must be a back-up 4 circulation function capable of handling all issue and return transactions without disruption to services R27 Recovery of transactions must be possible as soon as the system is back 5 online R27 All recovered transactions must be time-stamped so that later transactions 6 supersede earlier ones R27 The system must report on current reservations on recovered return 7 transactions

5. Acquisitions NB: This section covers the acquisition of all material, including monographs and serials. Specific reference to serials is made where necessary. Ongoing control of serial issues (i.e. check-in, claiming, routing and binding) is covered in 6 below. General R27 There must be provision for acquiring print and non-print material, 8 including monographs and serials, with integrated financial management and a common supplier file

R27 An audit trail must be maintained for all material at all stages of the 9 acquisitions process The system must support Electronic Data Interchange (EDI) in conformance with the EDIFACT standards, to include the following EDI transactions for both monographs and serials: R28 orders 0 R28 claims 1 R28 cancellations 2 R28 acknowledgements 3 R28 invoices 4 R28 reports 5 R28 quotes 6 R28 fulfilments 7 R28 It must be possible to produce acquisitions notices in print format 8 R28 Format and content of acquisitions notices must be library-definable 9 R29 The system must allow for input to be corrected and amended at all stages, 0 including ‘undo’ operations R29 It must be possible to display on order records on the OPAC and 1 allow/disallow reservations to be placed R29 It must be possible to read barcodes printed on books as an aid in 2 acquisitions processing R29 It must be possible to read barcodes printed on serials as an aid in 3 acquisitions processing R29 The system must support the import of order/bibliographic data from 4 suppliers, e.g. from showroom visits or suppliers’ websites. Potential requirements file R29 It must be possible to hold potential order records on the system (e.g. 5 approvals lists). Bibliographic data R29 It must be possible to input bibliographic data for order records both by 6 direct input and by use of imported bibliographic records at the order stage. Requirements for bibliographic data entry/import are the same as described under bibliographic database management (see 2 above). R29 It must be possible to input both brief and full data at the order stage 7 R29 The system must allow for bibliographic and item information on order 8 records to be used as the basis for catalogue records and vice-versa Supplier records The following fields must be included: R29 supplier code 9

R30 name and address 0 R30 telephone, fax, e-mail, web address 1 R30 contact names 2 R30 account number 3 R30 standard discount 4 R30 VAT number 5 R30 EDI transmission details 6 R30 chasing regime (library-defined) 7 R30 servicing arrangements 8 R30 delivery charges 9 R31 fields for notes to staff and suppliers 0 R31 It must be possible to create orders for suppliers not used on a regular basis, 1 i.e. without having to enter full supplier details Pre-order searching R31 The system must allow pre-order searching of both stock and order records 2 using any library-defined index Ordering The system must: R31 allow session defaults to be set when creating orders, e.g. default supplier, 3 fund, currency, location V49 P allow session defaults to be defined by location R31 allow order data to be carried forward for a succession of records 4 R31 allow existing order records to be copied to form new order e.g. for 5 ordering additional copies be capable of dealing with a variety of order types, including: R31 firm orders 6 R31 approvals 7 R31 subscriptions 8 R31 payment with order 9 R32 It must be possible to handle multi-part or standing orders, i.e. where 0 multiple parts for a single order need to be receipted, invoiced and catalogued separately R32 It must be possible to handle donations, i.e. where an order has not been 1 created. R32 It must be possible to handle exchanges, i.e. where an order has not been

created. The order record must include the following elements in addition to the bibliographic data: R32 supplier 3 R32 unit price 4 R32 fund 5 R32 currency 6 R32 location 7 R32 number of copies 8 R32 date of order 9 R33 order number 0 R33 order status e.g. urgent 1 R33 order type 2 R33 subscription period (if applicable) 3 R33 subscription renewal date (if applicable) 4 R33 notes to suppliers 5 R33 notes to staff 6 R33 requester/recommender information (if applicable) 7 R33 supplier report 8 R33 claims 9 R34 source, e.g. user request, staff recommendation 0 Order records must be accessible by: R34 bibliographic data elements 1 R34 order number, 2 R34 supplier, 3 R34 order status 4 R34 order type 5 R34 order date

It must be possible to access the following data directly from the order record (where applicable): R34 full bibliographic record 7 R34 check-in screens 8 R34 invoicing procedure and payment details 9 R35 prediction pattern 0 R35 supplier record 1 R35 The system must allow for multiple copies of all types of items including 2 subscriptions to be ordered for different locations and from different funds R35 It must be possible to flag subscription orders either to renew automatically 3 or to alert staff before manual renewal is due R35 It must be possible to block automatic renewal if no parts have been 4 received for any order and/or no payment has been made for purchase orders and to provide a report/message to supplier on such blocked records. R35 Once orders have been placed, funds should be committed immediately. 5 Any subsequent amendment to price information must automatically update commitments R35 It must be possible to link to e-mail/fax functions for sending of orders by 6 these methods rather than print/EDI Reports from suppliers The system must: R35 alert staff to outstanding reservations when a report on an order is received 7 R35 notify users who have requested/ recommended items when a report on an 8 order is received Receipting The system must: R35 allow receipt of items and invoice processing to be carried out in a single 9 operation or separately as required be able to handle: R36 partial receipt of an order 0 R36 return of damaged, incorrect or unwanted items 1 R36 variations in price/currency since order 2 R36 changes in bibliographic information. 3 R36 orders received on approval 4 R36 It must be possible to record the receipt of items for which there is no 5 order, e.g. donation R36 Reservations/requests must be alerted at the receipting stage and the 6 requester notified Invoice processing

R36 It must be possible to handle invoices before receipt, at the time of receipt 7 or at a later date The system must be able to handle: R36 credit notes 8 R36 pro-forma invoices 9 R37 subscription invoices 0 R37 discounts 1 R37 on approval payments 2 R37 fund transfers 3 R37 handling charges 4 Invoice records must include the following details: R37 supplier details 5 R37 invoice number 6 R37 invoice date 7 R37 invoice total 8 R37 discount amount 9 R38 Delivery/postage and packing charges 0 R38 VAT 1 R38 supplier servicing charges (lamination, labelling etc) 2 R38 links to display orders invoiced 3 R38 free text note field 4 R38 The system must allow online display of invoice data for a library-defined 5 period R38 Invoice processing must reconcile invoice totals and individual amounts 6 charged on invoices with line items The system must provide an alert before accepting invoice data for the following: R38 items which have been cancelled 7 R38 items which have claims outstanding 8 R38 items which are charged to over-committed and overspent funds 9 R39 if no parts have been received

Fund accounting R39 It must be possible to set up and display hierarchies of funds 1 R39 The system must allow transfer of monies between funds 2 The system must maintain and display for each fund: R39 fund allocation 3 R39 expenditure 4 R39 commitment 5 R39 cash balance 6 R39 Each fund should have the facility for library-defined limits on 7 commitment and expenditure and warnings must be generated when these are reached R39 The system must maintain a currency exchange table which can be updated 8 regularly; changes to the currency exchange table should automatically update commitments R39 The system must provide procedures for dealing with closing funds at the 9 end of the financial year. It must be possible to roll over commitments to next financial year R40 For serial subscription renewals, the system must carry forward 0 commitment based on the actual total cost of that subscription for the previous financial year R40 It must be possible to compare fund records for a library-defined number of 1 previous financial years Claiming and cancellations The system must: R40 allow a library-defined default claim period for each supplier 2 R40 allow for the default claim period to be amended on individual orders. 3 Amendment of the delivery date should automatically reset the claims cycle R40 It must be possible to link to e-mail/fax functions for sending of claims by 4 these methods rather than print/EDI R40 allow staff to force or suppress claims for individual items and 5 subscriptions R40 allow staff to either review items flagged for claiming before claims are 6 generated, or generate claims without prior review R40 allow authorised staff to cancel an order 7 R40 allow authorised staff to transfer an order to another supplier 8 R40 commitment details must be immediately adjusted upon cancellation of an 9 order R41 notify users who have requested/recommended an item if the order is 0 cancelled Export/import of data R41 The system must allow the export of financial data to organisational

financial systems

6. Serials control NB: This section covers ongoing control of serials, i.e. check-in, claiming, routing and binding. Bibliographic record creation for serials is covered in 2 above; ordering, subscription control, invoicing and fund maintenance is covered in 5 above General The system must provide for ongoing control of serial issues with regard to: R41 check-in 2 R41 claiming 3 R41 routing 4 R41 binding 5 R41 The system must allow for site-specific check-in, displaying only ‘their’ 6 issues for check-in It must be possible to access directly the following information attached to a serial title: R41 receipt details 7 R41 claims details 8 R41 routing details 9 R42 binding details 0 R42 invoice details 1 R42 The system must display latest issue information on the OPAC and update 2 serial holdings data automatically Check-in The system must: allow access to serial records by the following keys: R42 title 3 R42 ISSN 4 R42 issue barcode 5 R42 offer the option to show several expected/outstanding issues as well as just 6 the next expected issue R42 allow the creation of free-text notes at both title and issue level 7 R42 display notes at point of check-in 8 R42 allow for check-in of non-standard issues, including: 9 R43 supplements ©Juliet Leeves 2007 27 UKCS Version 3.0 LMS Functional Requirements

R43 special issues 1 R43 parts received out of sequence 2 R43 combined and double-numbered issues 3 R43 duplicates 4 R43 indexes 5 R43 allow staff to ‘unreceive’ an issue receipted in error 6 R43 alert staff to gaps in receipted issues at point of check-in 7 Prediction of issues The system must: R43 provide the facility to predict a wide range of publication patterns in terms 8 of number of issues per week, per month, per year or over several years (biennial, triennial etc) R43 allow patterns to support irregular but predictable publications such as 9 combined issues, supplements and indexes R44 handle irregular and unpredictable publications 0 R44 allow for changing the prediction pattern within a subscription year 1 R44 allow for stopping or suspending prediction for an individual title 2 R44 accommodate delays of any duration between nominal and actual date of 3 publication R44 support at least four levels of enumeration 4 R44 allow any combination of numeric, alphanumeric or date descriptors 5 R44 allow for volumes commencing at any time during the year 6 R44 allow for volumes covering more than one year 7 R44 allow for multiple volumes within a year 8 R44 allow for both continuous and restart issue numbering within volumes 9 R45 provide the option either to require a subscription renewal before parts are 0 predicted for the next subscription period, or to allow subscriptions/predictions to roll over without manual intervention Claiming The system must: R45 generate claims based on predicted expected issue date together with 1 library-defined claim period (by title or supplier) R45 allow prior review of claims by staff 2

R45 generate claims for skipped issues automatically on receipt of subsequent 3 issues R45 allow for linking to e-mail/fax functions for sending of claims by these 4 methods rather than print/EDI R45 allow for supplier reports to be added to issues claimed; amendment of 5 delivery date should reset the claims cycle R45 Claim formats and claim messages must be library-defined 6 Routing The system must: R45 allow the creation and maintenance of routing lists for specific copies of 7 individual titles using the borrower file R45 allow lists of titles/recipients to be edited on an individual or global basis 8 R45 alert staff to a routing list at check-in 9 R46 allow printing of routing lists at check-in, either on an individual basis or at 0 the end of a check-in session R46 alert staff to routed issues not returned 1 R46 Format of routing slips must be library-defined 2 Binding control The system must: R46 flag and identify items ready for binding according to library-defined 3 requirements R4 hold binder details and instructions 64 R4 record items at binding (issue, return, overdue) 65 R4 offer financial controls for binding 66

7. Document delivery and inter-library loans General Document delivery and inter-library loans must be integrated with the rest of the system, including: R46 the OPAC (for users to input requests and view progress) 7 R46 borrower records (to control ILL privileges) 8 R46 circulation control (for ongoing control of inter-library loans) 9 R47 For requests input via the OPAC, there must be facilities for staff to 0 authorise and process requests R47 The system must support ISO 10160/10161 ILL protocol (current version) 1 R47 The system must support the current procedures and formats specified by 2 the British Library Document Supply Centre (BLDSC)

R47 The system should support requests to other libraries 3 R47 A file of supplying libraries must be maintained, accessible by code and 4 library name R47 Format and content of notices must be library-definable 5 R47 It must be possible to archive completed document delivery/ILL requests 6 and make them available for access by staff for a library-defined period Request process The system must: R47 check eligibility to place requests (by borrower category) and any blocks 7 on the user which may inhibit the request R47 allow a limit to be imposed on the number of concurrent requests from any 8 user (by borrower category), with an overall limit over a library-defined period of time R47 provide varying templates for entering the request (for monographs, serials, 9 serial articles, conferences etc) R48 allow users entering requests via the OPAC to specify a collection point (if 0 applicable) R48 allow requests to be created by uploading data from external databases, e.g. 1 BLDSC databases R48 allow library staff to amend the bibliographic and other request details 2 before and after transmission of request R48 allow for checking requests against the OPAC 3 R48 allow for special requirements to be added to requests, e.g. loan essential, 4 translation only R48 allow for BLDSC transaction codes to be added to requests, e.g. RENEW, 5 CANCEL etc. R48 handle urgent requests, e.g. phone requests, and suppress transmission of 6 the request concerned R48 allow staff to access the request record in a number of ways, including: 7 R48 bibliographic details 8 R48 from the user record 9 The user record must display: R49 ILL items on loan 0 R49 outstanding requests 1 R49 progress reports 2 R49 Requests must be displayed in chronological order with most recent first 3 R49 The system must support the electronic transmission of requests to BLDSC 4 via ARTTel2/ARTEmail with an option to print or e-mail requests to other libraries if required. R49 Error detection must be provided and it must be possible to amend and 5 retransmit files

R49 It must be possible to change lenders for outstanding requests 6 R49 It must be possible to initiate action to revive a cancelled request or to re- 7 request a wrongly-supplied item Receipt and loan The system must record the receipt of the following (with date of receipt automatically recorded): R49 photocopy for retention 8 R49 item for loan or use in the Library 9 R50 It must be possible to amend the supplying library if different from the 0 library from which the item was originally requested The system must: R50 record the direct delivery of photocopied documents to the end user from 1 BLDSC (as reported by BLDSC) R50 produce requester’s address in label format for sending out photocopies 2 from Library R50 record completion of items sent out from BLDSC/Library 3 R50 allow for ongoing control of reference and loan items (issue, renewal, 4 recall, return, overdues, fines) via the circulation function, with specific parameters for such items, e.g. loan periods, fines, notices R50 allow a default due date to be set for each lending library (library-defined) 5 for loan items, and for ‘issuing’ items to be used in the Library R50 take account of closed days when calculating return dates 6 R50 create a loan period that includes both a return date and an automatic 7 extension (subject to recall) in line with BLDSC lending policy R50 notify the requester on receipt of an item, with details of collection point, 8 due date, renewal conditions, and whether item is for use in the Library only R50 notify Library staff if an item has not been collected within a library- 9 defined period of time R51 notifications must be possible by e-mail, print, and also appear on user’s 0 record on OPAC Renewals The system must: R51 manage renewal of loans, both from other libraries, and from BLDSC who 1 require renewals to be made on a new request number R51 allow for the electronic transmission of the renewal request to BLDSC 2 R51 produce printed or e-mail notices to renew with other libraries 3 Reports The system must: R51 recognise standard BLDSC report codes and translate them to appear as 4 text on the system R51 allow free text reports to be input and for standard reports to be amended as 5 necessary R51 generate reports for requesters, lenders and library staff, which may be

printed, e-mailed, and/or displayed on the OPAC (for end users) R51 allow for a reapplication to the same supplier or a different supplier after 7 receiving a reply from the requester Chasers and cancellations The system must: R51 generate chasers according to library-defined regimes 8 R51 transmit chasers electronically to BLDSC 9 R52 generate printed or e-mail chasers for other suppliers 0 R52 allow for requests to be cancelled 1 R52 allow for logging the reason for the cancellation 2 R52 generate cancellation notices to the supplier and requester 3 R52 transmit cancellation requests electronically to BLDSC 4 Charges and funds R52 It must be possible to handle charges imposed by document delivery 5 suppliers R52 The system must support deposit and billing accounts 6 R52 It must be possible to set up a number of accounting methods for one 7 supplier R52 The system must allow funds to be set up for document delivery/ILL 8 R52 Funds in ILL/document delivery should be linked to Acquisitions funds 9 The system must maintain and display for each fund: R53 fund allocation 0 R53 expenditure 1 R53 commitment 2 R53 cash balance 3 Loans to other libraries R53 The system must provide a facility for loaning to other libraries 4 R53 Control of loans (issue, renewal, recall, return, overdues) must use library- 5 defined parameters.

8. Management information General R53 The system must provide standard management information from the main 6 functional areas (see below) R53 It must be possible for the Library to define how long data is retained on

the system for use in reporting. R53 It must be possible for the Library to define and run its own regular and ad 8 hoc reports without using a complex query language and without the intervention of systems staff R53 It must be possible to save report specifications for re-use 9 R54 It must be possible to tailor pre-defined management information reports 0 and to run these on a regular or ad hoc basis R54 Layout and filing order of reports should be library-definable, with 1 standard layouts also provided R54 The system must be able to provide statistical information on an hourly, 2 daily, weekly, monthly and annual (academic/financial year) basis R54 It must be possible to produce snapshot statistics 3 It must be possible to: R54 view reports and statistics online 4 R54 output reports and statistics via e-mail 5 R54 output reports and statistics to electronic files (for ftp, download etc.) 6 R54 output reports and statistics to local and system printers 7 R54 download data from the system into standard PC packages for further 8 analysis, e.g. spreadsheets, databases R54 Data must be exportable in ASCII and comma-delimited formats 9 V50 A The system must provide pre-defined reports to meet the requirements of SCONUL V51 P The system must provide pre-defined reports to meet the requirements of CIPFA V52 P The system must provide pre-defined reports to meet Public Lending Right requirements Standard reports must include the following: Bibliographic database management R55 Statistics of records added to the database, broken down by library-defined 0 categories, e.g. material type, class mark, type of record (local/external) R55 Lists of titles selected by a combination of a range of categories, e.g. date 1 of input, class-mark / shelf-mark, material type R55 Bibliographic records with no items attached 2 R55 Lists of new authority headings 3 R55 Withdrawals 4 R55 Inventory and stock check reports 5 OPAC R55 Usage statistics by title 6 R55 Usage by borrower category

R55 Usage by type of search 8 R55 Failed searches 9 R56 Self-service transactions 0 Circulation R56 Reports and statistics relating to circulation transactions, including: issues, 1 returns, renewals, fines, reservations, with accumulation on an hourly, daily, weekly, monthly and annual basis; breakdown of statistics by borrower/loan status/collection category/ broad classification and any combination of these R56 Reports on reservations: reserved items not on loan (for shelf check); 2 reserved books with over a library-defined number of reservations (purchase alert); reserved books that have passed their holding date; uncollected reservations; outstanding reservations including number of days outstanding R56 Reports on borrowers with fines and overdues 3 R56 Lists of titles with specified loan status or collection category 4 R56 Lists of borrowers with tickets due to expire within library-defined period 5 R56 Analysis of borrower information: by academic department/borrower 6 category; levels of library usage and non-usage V53 P Reports on stock rotation activity, including: items in a particular rotating collection; current site of any item in a rotating collection; total items at a given site which are part of a rotating collection V54 P Mobile library statistics, including stop points Acquisitions (relating to serial as well as monograph orders) R56 Acquisitions statistics, by library-defined categories including: 7 gift/purchase; material type; supplier; fund; country of publication R56 Outstanding orders by supplier, by fund / order date / order number / 8 material type R56 Completed orders by supplier / fund / material type 9 R57 All orders, by financial year; broken down by material type and supplier 0 R57 Cancelled orders 1 R57 requests for purchase from users 2 R57 Lists of suppliers 3 R57 Analysis of supplier performance e.g. average supply time, price and 4 discount information, level of non-supply R57 Monthly, annual and on demand fund reports, including commitment and 5 expenditure R57 Expenditure by supplier 6

R57 Expenditure by library-defined subject areas / departments 7 R57 Lists of recent accessions 8 R57 Statistics of EDI transactions 9 R58 Reports on unsuccessful transmissions 0 Serials control R58 Lists of titles with unfulfilled claims, after penultimate and final claims, by 1 supplier R58 Cancelled subscriptions, by supplier / financial year 2 R58 Cumulating daily, monthly and annual totals of issues checked-in, by 3 library-defined categories, e.g. frequency, fund code R58 Lists of current serials by combinations of: title, classmark, supplier, 4 material type, fund code R58 Binding: number of volumes sent to bind, number returned, analysis of 5 time spent at binding Inter-library loans R58 Statistics of ILL requests satisfied / unsatisfied / cancelled / outstanding 6 R58 Statistics of items by supplier: requests satisfied / unsatisfied, by material 7 type R58 Costs by supplier/fund/material type 8 R58 Relative statistics of photocopies supplied / items for home loan / items 9 issued for reference use R59 Supply times: average; shortest; longest 0 R59 Statistics of items requested, broken down by borrower category and 1 material type R59 Statistics of items supplied to other libraries: requests satisfied / unsatisfied, 2 by material type