ukcs version3 cc licensed rev

7/31/2019 UKCS Version3 CC Licensed Rev

1/35

United Kingdom Core Specification

(UKCS)Functional Requirements for Library Management Systems

Compiled by Juliet Leeves

Library Systems Consultant

Version 3.0The 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.

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 websitehttp://www.kenchadconsulting.com/wp-content/uploads/2010/12/Making_it_easier_to_specify_systems_Dec2010.pdf

You are free:

to Share to copy, distribute and transmit the workto 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 thisone.

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 thisweb page.
http://www.kenchadconsulting.com/http://www.creativecommons.org/licenses/by-nc-sa/3.0http://www.creativecommons.org/licenses/by-nc-sa/3.0http://www.kenchadconsulting.com/wp-content/uploads/2010/12/Making_it_easier_to_specify_systems_Dec2010.pdfhttp://www.creativecommons.org/licenses/by-nc-sa/3.0http://www.kenchadconsulting.com/wp-content/uploads/2010/12/Making_it_easier_to_specify_systems_Dec2010.pdfhttp://www.kenchadconsulting.com/http://www.creativecommons.org/licenses/by-nc-sa/3.0


2/35

UKCS Version 3.0 LMS Functional Requirements

Juliet Leeves 2007

Juliet Leeves 2007 2


3/35


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 checklistof 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 basicfunctionality 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 differencesbetween

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 theUK (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



4/35


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 Desirable0 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 therequirement. 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 suppliers 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.



5/35


OR

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 aparticular 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 iscovered. 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 resourcediscovery 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.



6/35


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

Writers 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 requirementsfor 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.

http://www.niso.org/standards/std_resources.htmlhttp://www.niso.org/standards/std_resources.html


7/35


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 legaladvice 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.



8/35


Type Requirement

Importance

Compliance

1. General functionalityThe system must:

incorporate the following functions:

i. bibliographic database management (including authority control)

ii. OPAC and end user services

iii. circulation control

iv. acquisitions

v. serials control

vi. document delivery and inter-library loans

vii. management informationviii. be integrated with data only needing to be entered once to support all

functions

ix. support realtime updating in all functions

x. track staff operations for audit purposes

xi. 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

xii. provide for multi-site operation

xiii. comply with the relevant provisions of the Disability Discrimination Act

1995

xiv. comply with the Web Accessibility Initiative Level AA

xv. comply with the relevant provisions of the Special Educational Needs and

Disability Act 2001

xvi. comply with the provisions of the Data Protection Act 1998

Operation and user interface

The system must:

xvii. provide a graphical user interface in all functions

xviii

.

provide for direct access between functions where workflows dictate this

xix. allow staff to initiate a database search from any point in the system where

workflows dictate thisxx. provide for use of function/hot keys for frequently used functions

xxi. allow navigation tasks to be performed via the keyboard as well as with a

mouse

xxii. allow different searching/display options for staff for different functions

xxiii

.

allow library-defined inactivity time-outs in all functions

Help

xxiv

.

The system must have help facilities, to include:

xxv. screen examples

xxvi

.

context-sensitive help

xxvi search option for help on given topics



9/35


xxvi

ii.

tutorials

Customisation and configuration

The Library must be able to customise the system in the following areas:

xxix. screen layouts for public access

xxx. bibliographic fields and field labels

xxxi

.

indexes

xxxi

i.

record displays

xxxi

ii.

help texts

xxxi

v.

The interface for system configuration must be consistent with the rest of the

system

Access to the systemxxx

v.

Access to the system must be password protected

xxx

vi.

Access should be prevented if a pre-set number of tries is exceeded

The system must allow:

xxx

vii.

different levels of access to functions/sub-functions according to level of

user

xxx

viii.

suppression of disallowed options

xxxi

x.

restriction of groups of users/workstations to specific functions

xl. maintenance of access levels by the Library

2. Bibliographic database managementGeneral

The system:

xli. must provide for creating and maintaining bibliographic records

must support:

xlii. MARC21

xliii. Dewey (current edition)

xliv. Library of Congress classification (current edition)xlv. Library of Congress Subject Headings (current edition)

V1 A/S MeSH (current edition)

xlvi. ISO 2108 (ISBN, current revision)

xlvii

.

must allow extra local bibliographic fields to be defined

xlvii

i.

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:

xlix. allow online access to a range of library-defined databases using Z39.50(current version) and provide for the import of bibliographic records

l. provide for the import of authority records



10/35


li. provide for the import of records in batch and in realtime, i.e. direct to the

cataloguing screen

lii. 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

liii. allow the export of records in MARC21 exchange format

Record creation and editing

The system must:

liv. provide a full-screen edit interface for creating bibliographic records

lv. allow for library-defined templates for different types of material, e.g.

monographs, serials

lvi. provide both a MARC and labelled input interface

lvii. prevent the creation of duplicate records by allowing pre-searching and

matching on various fields including control numbers (ISBN, ISSN)

lviii. allow existing records, from external sources or the internal database, to be

copied and used as the basis for a new record

lix. allow data common to more than one record to be duplicated for a successionof records

lx. validate ISBN-10 and ISBN-13

lxi. validate ISSNs

lxii. allow for adding new copies to an existing record

lxiii. 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

lxiv. provide for immediate retrieval on all access points defined by the library

Authority control

The system must:

lxv. support MARC21 Authorities format

allow for authority control on certain fields, to include:

lxvi. authors

lxvii

.

subjects

lxvii

i.

series

lxix. provide for the creation, editing and deletion of authority records

lxx. allow access to authority records during record creation for

checking/selecting headings

lxxi. allow display of works associated with an authority headinglxxii

.

allow for global changes of headings and merging of headings, with

associated records amended automatically

Electronic resources

lxxii

i.

The system must allow for the input of URLs, URNs and other URIs in

bibliographic records for electronic location and access information

lxxi

v.

The system must incorporate a link checker

Item (copy) record management

lxxv

.

The system must allow unique item identifiers (e.g. barcodes, RFID tags) to

be assigned to item records on the system

lxxv

i.

There must be no effective limit to the number of item records linked to the

bibliographic record

lxxv It must be possible to specify library-defined defaults for item data and to



11/35


copy item data from one record to another

lxxv

iii.

It must be possible to mark copies as withdrawn or deleted

lxxi

x.

The system must give a warning if the last copy is being withdrawn or

deleted

lxxx

.

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

lxxx

i.

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

lxxx

ii.

The system must provide routines for bulk changes of data, e.g. location,

loan category

3. OPAC and end user servicesNB: 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.General

The system must:

lxxx

iii.

provide an online public access catalogue (OPAC) for use by end users

lxxx

iv.

provide additional access to the bibliographic database for staff use only in

the different functions, to include:

lxxx

v.

additional indexes

lxxx

vi.

ability to access all records in stock, on order, in process etc.

lxxx

vii.

additional information relating to loans, borrowers, items on order etc.

lxxx

viii.

additional displays, e.g. MARC format

lxxx

ix.

The system must support Z39.50 (current version) client and server

xc. It must be possible to display help, including examples, on search screens

xci. 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)

xcii. It must be possible to suppress individual bibliographic records from display

to the end user on the OPACIndexing

The system must allow the Library to define:

xciii

.

which fields/subfields or combination of fields/subfields are indexed for the

different search options

xciv

.

which search options are offered to staff and end users

xcv. 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:

xcvi

.

Dewey (current edition)

xcvi Library of Congress (current edition)



12/35


Interface

The system must provide:

xcvi

ii.

a simple (novice) interface, including non-Boolean searching

xcix. an advanced search interface, including:

c. explicit use of Boolean operators AND, OR, NOT

ci. specific fields to search

cii. left-hand truncation

ciii. right-hand truncation

civ. wildcards

cv. links on search screens and results displays to other search options, e.g.

browse index

cvi. at all times, a display of the current search

Searching

cvii. It must be possible to perform a keyword search across all defined indexes oron selected indexes

cviii

.

All commands and search keys must be case-insensitive and it must be

possible to ignore diacritics and punctuation for searching

cix. The system must allow searching using variant spellings

Search limits

The system must offer the ability to pre-limit searches:

cx. by date (including open and closed range of dates)

cxi. by language

cxii. by format of publication (e.g. video, serial)

cxiii. to particular collections

cxiv

.

by location

The system must offer the ability to post-limit searches:

cxv. by date (including open and closed range of dates)

cxvi

.

by language

cxvi

i.

by format of publication (e.g. video, serial)

cxvi

ii.

to particular collections

cxix

.

by location

Display of search results and navigation

The system must:

cxx. provide different levels of display (brief, full) and allow the Library to define

which elements in a record are included in each display

cxxi

.

allow default sort order of search results to be library-defined for each search

type

cxxi

i.

allow the user to be able to change the default sort order

cxxi

ii.

allow users to view serial holdings, including serials check-in and latest issue

information



13/35


cxxi

v.

display the record immediately in the event of a single hit being retrieved

(rather than intermediate index display)

cxxv

.

support hypertext links between elements in records allowing highlighted

index terms to be used as the basis of further searches

cxxv

i.

support hypertext links from cross references to authorised headings

cxxv

ii.

support hypertext links from bibliographic records to other electronic

information resources both local and remote via URLs, URNs and other

URIs

Output and saving

The system must:

cxxv

iii.

allow users to mark or select references for printing and downloading

cxxi

x.

allow users to review and edit the list and to sort items

cxxx

.

allow users to download lists of saved records to disk or e-mail or to send to

an attached or network printercxxx

i.

offer a range of output formats for exported records, including:

cxxx

ii.

full and brief records

cxxx

iii.

MARC21

cxxx

iv.

ASCII

cxxx

v.

EndNote

cxxx

vi.

ProCite

cxxx

vii.

library-defined formats

Self-service options

cxxx

viii.

The system must allow users access to their own records and transaction

details (as authorised by user ID/PIN). Transaction details must include:

cxxx

ix.

loans

cxl. reservations

cxli. finescxlii

.

ILL requests

cxlii

i.

purchase requests

Users must be able to:

cxli

v.

make reservations

cxlv

.

cancel reservations

V2 A make bookings for short loan material

cxlv

i.

make renewals

cxlv make ILL requests and view progress



14/35


cxlv

iii.

make purchase requests

cxli

x.

update their contact details

cl. The system must interface with automated telephone renewal systems for

self-service renewals via this method, using the SIP2/NCIP standards

cli. The system must interface with self-issue/return devices using the

SIP2/NCIP standards

clii. All circulation parameter settings (e.g. loan rules, borrower blocks) must also

apply to self-service functions

4. Circulation controlCirculation policies

cliii. Circulation policies must be library-defined

Circulation policies must be determined by a combination of:

cliv. borrower categoryclv. item category

clvi. location

Circulation policies determined in this way must include:

clvii

.

loan periods (expressed in days, weeks, months, extended/fixed date)

clvii

i.

reference only

clix. loan entitlements (per item category and overall)

clx. renewal periods (according to method, e.g. phone, self-service etc)

clxi. renewal limits by methodclxii

.

reservations - charges

clxii

i.

reservations allow/disallow

clxi

v.

reservations - maximum number (by item category and overall)

clxv

.

reservations - loan period reduction if more than one

clxv

i.

reservations - length of time held on reservations shelf

clxvii.

reservations - expiry period for unsatisfied reservations

clxv

iii.

fine rates (normal and special rates, e.g. overdue reserved item)

clxi

x.

maximum fines

clxx

.

charges subscription/membership

clxx

i.

charges hire charges

clxxii. notice production type (e.g. overdue and frequency)

clxx notice production - format (e.g. print or e-mail)



15/35


clxx

iv.

It must be possible to apply library-defined grace periods

clxx

v.

The system must maintain a calendar of closed dates for each location. All

circulation transactions including due dates, fines, recalls and reservations

awaiting collection must take account of closed days

clxx

vi.

Authorised library staff must be able to update parameters with immediate

effect

General circulation functions

clxx

vii.

The system must provide automatic blocks/alerts on borrowers, including:

clxx

viii.

expired ticket

clxx

ix.

outstanding fines/fees (library-definable threshold)

clxx

x.

overdue/recalled items (library-defined threshold)

clxx

xi.

over entitlement

clxx

xii.

Automatic blocks/alerts must be automatically removed

clxx

xiii.

The system must allow authorised staff to input manual blocks with an

explanatory message

clxx

xiv.

Authorised staff must be able to override any borrower or item block.

clxx

xv.

The system must show the status of items (e.g. reserved, awaiting collection)

at all times to both staff and end users

clxx

xvi.

The system must maintain a loan history for both items and borrowers,

retrievable for a library-defined period

clxx

xvii.

The system must support the circulation of uncatalogued items and 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

clxx

xviii

.

The system must allow for loans of multiple sets, e.g. music, drama sets

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 totheir home location and manage the transit of such items, showing their

current status at all times

Issue, return and renewal

clxx

xix.

It must be possible to enter the unique item identifier (e.g. barcode, RFID

tag) by machine (e.g. scanner, reader) or manual input

cxc. Item identifier only must be required for return

cxci. Borrower and item status must be automatically checked on all three

functions; any blocks/ accompanying messages must be displayed with an

audible warning

cxcii

.

It must be possible to override the calculated due date at the point of

issue/renewal, subject to borrower and item checkscxcii

i.

Borrower expiry date must override due date; warning of imminent expiry

date must be given on screen



16/35


cxci

v.

The system must allow a means of ending the current transaction (to 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

cxcv

.

The system must allow for flagging items as claimed returned, leaving the

item linked to the borrower as a claimed returned item but suppressing

notices and fines

cxcv

i.

It must be possible to flag items as lost, leaving the item linked to the

borrower as a lost item, but suppressing notices and fines

cxcv

ii.

The system must alert staff of lost items on issue and return

cxcv

iii.

It must be possible to flag items as damaged and alert staff and end users

on issue and return

cxci

x.

It must be possible to flag items with multiple elements, e.g. triple CD packs,

and alert staff/users on issue and return to ensure sets are complete

The system must:

cc. allow bulk renewal of all items on loan (subject to borrower and itemchecks), or selected items

cci. prevent renewal of overdue items (library defined threshold), reserved or

recalled items, and items over the renewal limit

allow for renewal of unseen items via:

ccii. telephone

cciii

.

self-renewal via OPAC

cciv. self-renewal via automated telephone answering service

ccv. flag method of renewal

ccvi. provide direct access to the borrower record for personal details and details

of loans, fines and reservations, from issue, return or renewal functions

ccvii

.

provide direct access to the full item record, including reservation

information, from the borrower's loan record

Fines and charges

The system must:

ccvii

i.

show details for each fine or charge, e.g. the loan which incurred the fine

ccix. accumulate fines and charges for payment in a single transaction

ccx. allow for payment to be accepted either in the Return function or by direct

access to the fine payment screen from the Return function

ccxi. allow payment in full or part against any individual chargeccxii

.

allow payment in full or part against all charges

ccxii

i.

allow authorised staff to waive all or some fines/charges owing. The reason

for the waiver must be recorded.

ccxi

v.

It must be possible to defer payment (at the discretion of the library)

ccxv

.

It must be possible to record the payment method

V6 P The system must enable group payment of fines, e.g. families

ccxv

i.

It must be possible to print receipts of fines/charges paid on attached or

networked printer

ccxv

ii.

The system must include cash management functions to enable balancing of

income received on the system with that recorded on tills



17/35


ccxv

iii.

It must be possible to set a default replacement cost (where cost not specified

on item record) for lost books

ccxi

x.

It must be possible to set processing/administration fees

ccxx

.

Financial history should be retrievable for a library-defined period

ccxx

i.

It must be possible to handle other charges, including:

ccxx

ii.

subscription/membership charges

ccxx

iii.

hire charges

ccxx

iv.

reservation charges

ccxx

v.

library sales

ccxxvi.

The system must allow refunds to be made and recorded

Reservations

The system must:

ccxx

vii.

allow title-level (first available copy) reservations by staff and end users

ccxx

viii.

allow item category and copy specific reservations by staff only

V7 P allow grouping of locations to satisfy reservations

ccxx

ix.

allow/disallow reservations on items on order

ccxx

x.

allow/disallow available items (i.e. on shelf) to be reserved if reservation

placed in the library

ccxx

xi.

automatically notify staff at each site of reservations for items not on loan

(remote reservations) for shelf check

ccxx

xii.

allow staff to record not found status against remote reservation request

ccxx

xiii.

allow for remote reservation requests to be routed between sites if on shelf

copy at more than one site

ccxx

xiv.

allow for a default collection point to be specified which can be changed if

required by staff/end users

ccxxxv.

allow reduction of loan periods when there are outstanding reservations onitems

ccxx

xvi.

allow generation of recall notices for reserved items (recall item due back

soonest), and reduction of the loan period

ccxx

xvii.

alert staff of a reservation on an item on return from loan and notify the

requester that the item is awaiting collection

ccxx

xviii

.

alert staff/end users if a reservation is awaiting collection, whenever the user

record is accessed

ccxx

xix.

allow for reservations to be cancelled automatically on expiration

ccxl. allow for reservations to be cancelled manually by staff (with provision forreason)

ccxli Staff must be able to change the order of the reservation queue



18/35


ccxli

i.

It must be possible to set an expiry date for uncollected reservations, with

automatic notification to staff (to remove from reserve shelf)

ccxli

ii.

It must be possible to set an expiry date for unsatisfied reservations, with

automatic notification to end users

Bookings

ccxli

v.

The system must support booking of equipment, e.g. PCs, either directly on

the system or via an interface with a bookings system using SIP2/NCIP

standards

Borrower records

ccxl

v.

It must be possible to import and update borrower information from the

organisational database

ccxl

vi.

The system must be able to generate a PIN number automatically or to accept

an externally derived PIN

ccxl

vii.

It must be possible to create/edit borrower records manually in addition to

importing them

V8 P It must be possible to duplicate data common to more than one borrower, e.g.family details

ccxl

viii.

Fields for the borrower record must be library-defined. Standard fields must

include:

ccxli

x.

name

ccl. address (provision for at least two addresses)

ccli. e-mail address (provision for at least two addresses)

V9 A automatic use of address by date (term/vacation)

cclii

.

telephone numbers

cclii

i.

borrower category

V10 P date of birth (under 18s)

V11 P home branch

V12 A location/department

V13 A course

ccliv

.

joining date

cclv. date of expiry

cclvi

.

last use

cclvi

i.

free text notes/messages

V14 P The system must provide an automatic change to borrower category, once

the borrower reaches 18

cclvi

ii.

Borrower records must be accessible by name and number

cclix

.

Library staff must be able to delete borrowers' records, in bulk or

individually, except where current transactions or blocks are outstanding

cclx. It must be possible to delete records by the date of expiry

cclxi

.

When a library card is being replaced, the existing borrower's details must be

carried across from the old card

cclxi

i.

It must be possible to flag a borrower barcode/library card as lost,

prohibiting transactions on that card and alerting staff when it is used



19/35


cclxi

ii.

The system must be able to generate unique user numbers and accept

numbers from an externally derived source

Notices

cclxi

v.

The system must allow automatic generation of notices, including:

cclx

v.

overdue letters

cclx

vi.

fines

cclx

vii.

replacement costs

cclx

viii.

recalls

cclxi

x.

notification of item awaiting collection

The system must allow notices to be generated in a range of formats, to

include:cclx

x.

print

cclx

xi.

e-mail

cclx

xii.

SMS messaging

cclx

xiii.

Text and format of notices must be library-defined

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 reservationsV24 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



20/35


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 librarysystem

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 loansV42 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

cclx

xiv.

In the event of system or network failure, there must be a back-up circulation

function capable of handling all issue and return transactions without

disruption to services

cclx

xv.

Recovery of transactions must be possible as soon as the system is back

online

cclx

xvi.

All recovered transactions must be time-stamped so that later transactions

supersede earlier onescclx

xvii.

The system must report on current reservations on recovered return

transactions

5. AcquisitionsNB: 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

cclxxviii

.

There must be provision for acquiring print and non-print material, includingmonographs and serials, with integrated financial management and a

common supplier file



21/35


cclx

xix.

An audit trail must be maintained for all material at all stages of the

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:

cclx

xx.

orders

cclx

xxi.

claims

cclx

xxii.

cancellations

cclx

xxiii

.

acknowledgements

cclx

xxiv

.

invoices

cclx

xxv.

reports

cclx

xxvi

.

quotes

cclx

xxvi

i.

fulfilments

cclx

xxvi

ii.

It must be possible to produce acquisitions notices in print format

cclx

xxix

.

Format and content of acquisitions notices must be library-definable

ccxc

.

The system must allow for input to be corrected and amended at all stages,

including undo operations

ccxc

i.

It must be possible to display on order records on the OPAC and

allow/disallow reservations to be placed

ccxc

ii.It must bepossibleto readbarcodes printed on books as an aid in acquisitions

processing

ccxciii.

It must be possible to read barcodes printed on serials as an aid inacquisitions processing

ccxc

iv.

The system must support the import of order/bibliographic data from

suppliers, e.g. from showroom visits or suppliers websites.

Potential requirements file

ccxc

v.

It must be possible to hold potential order records on the system (e.g.

approvals lists).

Bibliographic data

ccxc

vi.

It must be possible to input bibliographic data for order records both by

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).ccxc

vii.

It must be possible to input both brief and full data at the order stage



22/35


ccxc

viii.

The system must allow for bibliographic and item information on order

records to be used as the basis for catalogue records and vice-versa

Supplier records

The following fields must be included:

ccxc

ix.

supplier code

ccc. name and address

ccci. telephone, fax, e-mail, web address

cccii

.

contact names

cccii

i.

account number

ccci

v.

standard discount

cccv

.

VAT number

cccvi.

EDI transmission details

cccv

ii.

chasing regime (library-defined)

cccv

iii.

servicing arrangements

ccci

x.

delivery charges

cccx

.

fields for notes to staff and suppliers

cccx

i.

It must be possible to create orders for suppliers not used on a regular basis,

i.e. without having to enter full supplier details

Pre-order searching

cccx

ii.

The system must allow pre-order searching of both stock and order records

using any library-defined index

Ordering

The system must:

cccx

iii.

allow session defaults to be set when creating orders, e.g. default supplier,

fund, currency, location

V49 P allow session defaults to be defined by location

cccx

iv.

allow order data to be carried forward for a succession of records

cccx

v.

allow existing order records to be copied to form new order e.g. for ordering

additional copies

be capable of dealing with a variety of order types, including:

cccx

vi.

firm orders

cccx

vii.

approvals

cccx

viii.

subscriptions

cccxix. payment with order

cccx It must be possible to handle multi-part or standing orders, i.e. where



23/35


multiple parts for a single order need to be receipted, invoiced and

catalogued separately

cccx

xi.

It must be possible to handle donations, i.e. where an order has not been

created.

cccx

xii.

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:

cccx

xiii.

supplier

cccx

xiv.

unit price

cccx

xv.

fund

cccx

xvi.

currency

cccxxvii.

location

cccx

xviii

.

number of copies

cccx

xix.

date of order

cccx

xx.

order number

cccx

xxi.

order status e.g. urgent

cccx

xxii.

order type

cccx

xxiii

.

subscription period (if applicable)

cccx

xxiv

.

subscription renewal date (if applicable)

cccx

xxv.

notes to suppliers

cccxxxvi

.

notes to staff

cccx

xxvi

i.

requester/recommender information (if applicable)

cccx

xxvi

ii.

supplier report

cccx

xxix

.

claims

cccx

l.

source, e.g. user request, staff recommendation



24/35


Order records must be accessible by:

cccx

li.

bibliographic data elements

cccx

lii.

order number,

cccx

liii.

supplier,

cccx

liv.

order status

cccx

lv.

order type

cccx

lvi.

order date

It must be possible to access the following data directly from the order record

(where applicable):

cccx

lvii.

full bibliographic record

cccx

lviii.

check-in screens

cccx

lix.

invoicing procedure and payment details

cccl. prediction pattern

cccli

.

supplier record

cccli

i.

The system must allow for multiple copies of all types of items including

subscriptions to be ordered for different locations and from different funds

cccli

ii.

It must be possible to flag subscription orders either to renew automatically

or to alert staff before manual renewal is due

cccli

v.

It must be possible to block automatic renewal if no parts have been 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.

cccl

v.

Once orders have been placed, funds should be committed immediately.

Any subsequent amendment to price information must automatically update

commitments

cccl

vi.

It must be possible to link to e-mail/fax functions for sending of orders by

these methods rather than print/EDI

Reports from suppliers

The system must:cccl

vii.

alert staff to outstanding reservations when a report on an order is received

cccl

viii.

notify users who have requested/ recommended items when a report on an

order is received

Receipting

The system must:

cccli

x.

allow receipt of items and invoice processing to be carried out in a single

operation or separately as required

be able to handle:

cccl

x.

partial receipt of an order

cccl

xi.

return of damaged, incorrect or unwanted items



25/35


cccl

xii.

variations in price/currency since order

cccl

xiii.

changes in bibliographic information.

cccl

xiv.

orders received on approval

cccl

xv.

It must be possible to record the receipt of items for which there is no order,

e.g. donation

cccl

xvi.

Reservations/requests must be alerted at the receipting stage and the

requester notified

Invoice processing

cccl

xvii.

It must be possible to handle invoices before receipt, at the time of receipt or

at a later date

The system must be able to handle:

cccl

xviii

.

credit notes

cccl

xix.

pro-forma invoices

cccl

xx.

subscription invoices

cccl

xxi.

discounts

cccl

xxii.

on approval payments

cccl

xxiii

.

fund transfers

cccl

xxiv

.

handling charges

Invoice records must include the following details:

cccl

xxv.

supplier details

cccl

xxvi

.

invoice number

ccclxxvi

i.

invoice date

cccl

xxvi

ii.

invoice total

cccl

xxix

.

discount amount

cccl

xxx.

Delivery/postage and packing charges

ccclxxxi

.

VAT



26/35


cccl

xxxi

i.

supplier servicing charges (lamination, labelling etc)

cccl

xxxi

ii.

links to display orders invoiced

cccl

xxxi

v.

free text note field

cccl

xxx

v.

The system must allow online display of invoice data for a library-defined

period

cccl

xxx

vi.

Invoice processing must reconcile invoice totals and individual amounts

charged on invoices with line items

The system must provide an alert before accepting invoice data for the

following:cccl

xxx

vii.

items which have been cancelled

cccl

xxx

viii.

items which have claims outstanding

cccl

xxxi

x.

items which are charged to over-committed and overspent funds

cccx

c.

if no parts have been received

Fund accounting

cccx

ci.

It must be possible to set up and display hierarchies of funds

cccx

cii.

The system must allow transfer of monies between funds

The system must maintain and display for each fund:

cccx

ciii.

fund allocation

cccx

civ.

expenditure

cccx

cv.

commitment

cccx

cvi.

cash balance

cccx

cvii.

Each fund should have the facility for library-defined limits on commitment

and expenditure and warnings must be generated when these are reached

cccx

cviii

.

The system must maintain a currency exchange table which can be updated

regularly; changes to the currency exchange table should automatically

update commitments

cccx

cix.

The system must provide procedures for dealing with closing funds at the

end of the financial year. It must be possible to roll over commitments tonext financial year

cd. For serial subscription renewals, the system must carry forward commitment



27/35


based on the actual total cost of that subscription for the previous financial

year

cdi. It must be possible to compare fund records for a library-defined number of

previous financial years

Claiming and cancellations

The system must:

cdii. allow a library-defined default claim period for each supplier

cdiii

.

allow for the default claim period to be amended on individual orders.

Amendment of the delivery date should automatically reset the claims cycle

cdiv

.

It must be possible to link to e-mail/fax functions for sending of claims by

these methods rather than print/EDI

cdv. allow staff to force or suppress claims for individual items and subscriptions

cdvi

.

allow staff to either review items flagged for claiming before claims are

generated, or generate claims without prior review

cdvi

i.

allow authorised staff to cancel an order

cdviii.

allow authorised staff to transfer an order to another supplier

cdix

.

commitment details must be immediately adjusted upon cancellation of an

order

cdx. notify users who have requested/recommended an item if the order is

cancelled

Export/import of data

cdxi

.

The system must allow the export of financial data to organisational financial

systems

6. Serials controlNB: 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:

cdxi

i.

check-in

cdxi

ii.

claiming

cdxiv.

routing

cdxv

.

binding

cdxv

i.

The system must allow for site-specific check-in, displaying only their

issues for check-in

It must be possible to access directly the following information attached to a

serial title:

cdxv

ii.

receipt details

cdxv

iii.

claims details

cdxi

x.

routing details



28/35


cdxx

.

binding details

cdxx

i.

invoice details

cdxx

ii.

The system must display latest issue information on the OPAC and update

serial holdings data automatically

Check-in

The system must:

allow access to serial records by the following keys:

cdxx

iii.

title

cdxx

iv.

ISSN

cdxx

v.

issue barcode

cdxx

vi.

offer the option to show several expected/outstanding issues as well as just

the next expected issuecdxx

vii.

allow the creation of free-text notes at both title and issue level

cdxx

viii.

display notes at point of check-in

cdxx

ix.

allow for check-in of non-standard issues, including:

cdxx

x.

supplements

cdxx

xi.

special issues

cdxx

xii.

parts received out of sequence

cdxx

xiii.

combined and double-numbered issues

cdxx

xiv.

duplicates

cdxx

xv.

indexes

cdxx

xvi.

allow staff to unreceive an issue receipted in error

cdxxxvii.

alert staff to gaps in receipted issues at point of check-in

Prediction of issues

The system must:

cdxx

xviii

.

provide the facility to predict a wide range of publication patterns in terms of

number of issues per week, per month, per year or over several years

(biennial, triennial etc)

cdxx

xix.

allow patterns to support irregular but predictable publications such as

combined issues, supplements and indexes

cdxl

.

handle irregular and unpredictable publications

cdxli

.

allow for changing the prediction pattern within a subscription year

cdxl allow for stopping or suspending prediction for an individual title



29/35


cdxl

iii.

accommodate delays of any duration between nominal and actual date of

publication

cdxl

iv.

support at least four levels of enumeration

cdxl

v.

allow any combination of numeric, alphanumeric or date descriptors

cdxl

vi.

allow for volumes commencing at any time during the year

cdxl

vii.

allow for volumes covering more than one year

cdxl

viii.

allow for multiple volumes within a year

cdxl

ix.

allow for both continuous and restart issue numbering within volumes

cdl. provide the option either to require a subscription renewal before parts are

predicted for the next subscription period, or to allowsubscriptions/predictions to roll over without manual intervention

Claiming

The system must:

cdli. generate claims based on predicted expected issue date together with library-

defined claim period (by title or supplier)

cdlii

.

allow prior review of claims by staff

cdlii

i.

generate claims for skipped issues automatically on receipt of subsequent

issues

cdli

v.

allow for linking to e-mail/fax functions for sending of claims by these

methods rather than print/EDI

cdlv

.

allow for supplier reports to be added to issues claimed; amendment of

delivery date should reset the claims cycle

cdlv

i.

Claim formats and claim messages must be library-defined

Routing

The system must:

cdlv

ii.

allow the creation and maintenance of routing lists for specific copies of

individual titles using the borrower file

cdlv

iii.

allow lists of titles/recipients to be edited on an individual or global basis

cdli

x.

alert staff to a routing list at check-in

cdlx

.

allow printing of routing lists at check-in, either on an individual basis or at

the end of a check-in session

cdlx

i.

alert staff to routed issues not returned

cdlx

ii.

Format of routing slips must be library-defined

Binding control

The system must:

cdlx

iii.

flag and identify items ready for binding according to library-defined

requirements

cdl hold binder details and instructions



30/35


cdl

xv.

record items at binding (issue, return, overdue)

cdl

xvi.

offer financial controls for binding

7. Document delivery and inter-library loansGeneral

Document delivery and inter-library loans must be integrated with the rest of

the system, including:

cdlx

vii.

the OPAC (for users to input requests and view progress)

cdlx

viii.

borrower records (to control ILL privileges)

cdlx

ix.

circulation control (for ongoing control of inter-library loans)

cdlx

x.

For requests input via the OPAC, there must be facilities for staff to

authorise and process requests

cdlx

xi.

The system must support ISO 10160/10161 ILL protocol (current version)

cdlx

xii.

The system must support the current procedures and formats specified by the

British Library Document Supply Centre (BLDSC)

cdlx

xiii.

The system should support requests to other libraries

cdlx

xiv.

A file of supplying libraries must be maintained, accessible by code and

library namecdlx

xv.

Format and content of notices must be library-definable

cdlx

xvi.

It must be possible to archive completed document delivery/ILL requests and

make them available for access by staff for a library-defined period

Request process

The system must:

cdlx

xvii.

check eligibility to place requests (by borrower category) and any blocks on

the user which may inhibit the request

cdlx

xviii

.

allow a limit to be imposed on the number of concurrent requests from any

user (by borrower category), with an overall limit over a library-defined

period of timecdlx

xix.

provide varying templates for entering the request (for monographs, serials,

serial articles, conferences etc)

cdlx

xx.

allow users entering requests via the OPAC to specify a collection point (if

applicable)

cdlx

xxi.

allow requests to be created by uploading data from external databases, e.g.

BLDSC databases

cdlx

xxii.

allow library staff to amend the bibliographic and other request details before

and after transmission of request

cdlx

xxiii.

allow for checking requests against the OPAC

cdlx allow for special requirements to be added to requests, e.g. loan essential,



31/35


translation only

cdlx

xxv.

allow for BLDSC transaction codes to be added to requests, e.g. RENEW,

CANCEL etc.

cdlx

xxvi

.

handle urgent requests, e.g. phone requests, and suppress transmission of the

request concerned

cdlx

xxvi

i.

allow staff to access the request record in a number of ways, including:

cdlx

xxvi

ii.

bibliographic details

cdlx

xxix

.

from the user record

The user record must display:

cdxc.

ILL items on loan

cdxc

i.

outstanding requests

cdxc

ii.

progress reports

cdxc

iii.

Requests must be displayed in chronological order with most recent first

cdxc

iv.

The system must support the electronic transmission of requests to BLDSC

via ARTTel2/ARTEmail with an option to print or e-mail requests to other

libraries if required.

cdxcv.

Error detection must be provided and it must be possible to amend andretransmit files

cdxc

vi.

It must be possible to change lenders for outstanding requests

cdxc

vii.

It must be possible to initiate action to revive a cancelled request or to re-

request a wrongly-supplied item

Receipt and loan

The system must record the receipt of the following (with date of receipt

automatically recorded):

cdxc

viii.

photocopy for retention

cdxc

ix.

item for loan or use in the Library

d. It must be possible to amend the supplying library if different from the

library from which the item was originally requested

The system must:

di. record the direct delivery of photocopied documents to the end user from

BLDSC (as reported by BLDSC)

dii. produce requesters address in label format for sending out photocopies from

Library

diii. record completion of items sent out from BLDSC/Library

div. allow for ongoing control of reference and loan items (issue, renewal, recall,return, overdues, fines) via the circulation function, with specific parameters

for such items, e.g. loan periods, fines, notices



32/35


dv. allow a default due date to be set for each lending library (library-defined)

for loan items, and for issuing items to be used in the Library

dvi. take account of closed days when calculating return dates

dvii. create a loan period that includes both a return date and an automatic

extension (subject to recall) in line with BLDSC lending policy

dviii

.

notify the requester on receipt of an item, with details of collection point, due

date, renewal conditions, and whether item is for use in the Library only

dix. notify Library staff if an item has not been collected within a library-defined

period of time

dx. notifications must be possible by e-mail, print, and also appear on users

record on OPAC

Renewals

The system must:

dxi. manage renewal of loans, both from other libraries, and from BLDSC who

require renewals to be made on a new request number

dxii. allow for the electronic transmission of the renewal request to BLDSC

dxiii.

produce printed or e-mail notices to renew with other libraries

Reports

The system must:

dxiv

.

recognise standard BLDSC report codes and translate them to appear as text

on the system

dxv. allow free text reports to be input and for standard reports to be amended as

necessary

dxvi

.

generate reports for requesters, lenders and library staff, which may be

printed, e-mailed, and/or displayed on the OPAC (for end users)

dxvi

i.

allow for a reapplication to the same supplier or a different supplier after

receiving a reply from the requester

Chasers and cancellations

The system must:

dxvi

ii.

generate chasers according to library-defined regimes

dxix

.

transmit chasers electronically to BLDSC

dxx. generate printed or e-mail chasers for other suppliers

dxxi

.

allow for requests to be cancelled

dxxii.

allow for logging the reason for the cancellation

dxxi

ii.

generate cancellation notices to the supplier and requester

dxxi

v.

transmit cancellation requests electronically to BLDSC

Charges and funds

dxx

v.

It must be possible to handle charges imposed by document delivery

suppliers

dxx

vi.

The system must support deposit and billing accounts

dxx

vii.

It must be possible to set up a number of accounting methods for one

supplier

dxx The system must allow funds to be set up for document delivery/ILL



33/35


dxxi

x.

Funds in ILL/document delivery should be linked to Acquisitions funds

The system must maintain and display for each fund:

dxx

x.

fund allocation

dxx

xi.

expenditure

dxx

xii.

commitment

dxx

xiii.

cash balance

Loans to other libraries

dxx

xiv.

The system must provide a facility for loaning to other libraries

dxx

xv.

Control of loans (issue, renewal, recall, return, overdues) must use library-

defined parameters.

8. Management informationGeneral

dxx

xvi.

The system must provide standard management information from the main

functional areas (see below)

dxx

xvii.

It must be possible for the Library to define how long data is retained on the

system for use in reporting.

dxx

xviii

.

It must be possible for the Library to define and run its own regular and ad

hoc reports without using a complex query language and without the

intervention of systems staffdxx

xix.

It must be possible to save report specifications for re-use

dxl. It must be possible to tailor pre-defined management information reports and

to run these on a regular or ad hoc basis

dxli. Layout and filing order of reports should be library-definable, with standard

layouts also provided

dxlii

.

The system must be able to provide statistical information on an hourly,

daily, weekly, monthly and annual (academic/financial year) basis

dxlii

i.

It must be possible to produce snapshot statistics

It must be possible to:dxli

v.

view reports and statistics online

dxlv

.

output reports and statistics via e-mail

dxlv

i.

output reports and statistics to electronic files (for ftp, download etc.)

dxlv

ii.

output reports and statistics to local and system printers

dxlv

iii.

download data from the system into standard PC packages for further

analysis, e.g. spreadsheets, databasesdxli

x.

Data must be exportable in ASCII and comma-delimited formats



34/35


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

dl. Statistics of records added to the database, broken down by library-defined

categories, e.g. material type, class mark, type of record (local/external)

dli. Lists of titles selected by a combination of a range of categories, e.g. date of

input, class-mark / shelf-mark, material type

dlii. Bibliographic records with no items attached

dliii. Lists of new authority headings

dliv. Withdrawals

dlv. Inventory and stock check reports

OPACdlvi. Usage statistics by title

dlvii

.

Usage by borrower category

dlvii

i.

Usage by type of search

dlix. Failed searches

dlx. Self-service transactions

Circulation

dlxi. Reports and statistics relating to circulation transactions, including: issues,

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

dlxii

.

Reports on reservations: reserved items not on loan (for shelf check);

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

dlxii

i.

Reports on borrowers with fines and overdues

dlxi

v.

Lists of titles with specified loan status or collection category

dlxv.

Lists of borrowers with tickets due to expire within library-defined period

dlxv

i.

Analysis of borrower information: by academic department/borrower

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)

dlxv

ii.

Acquisitions statistics, by library-defined categories including: gift/purchase;

material type; supplier; fund; country of publication

dlxv

iii.

Outstanding orders by supplier, by fund / order date / order number /

material type

dlxi Completed orders by supplier / fund / material type



35/35


dlxx

.

All orders, by financial year; broken down by material type and supplier

dlxx

i.

Cancelled orders

dlxx

ii.

requests for purchase from users

dlxx

iii.

Lists of suppliers

dlxx

iv.

Analysis of supplier performance e.g. average supply time, price and

discount information, level of non-supply

dlxx

v.

Monthly, annual and on demand fund reports, including commitment and

expenditure

dlxx

vi.

Expenditure by supplier

dlxx

vii.

Expenditure by library-defined subject areas / departments

dlxx

viii.

Lists of recent accessions

dlxx

ix.

Statistics of EDI transactions

dlxx

x.

Reports on unsuccessful transmissions

Serials control

dlxx

xi.

Lists of titles with unfulfilled claims, after penultimate and final claims, by

supplier

dlxx

xii.

Cancelled subscriptions, by supplier / financial year

dlxx

xiii.

Cumulating daily, monthly and annual totals of issues checked-in, by library-

defined categories, e.g. frequency, fund code

dlxx

xiv.

Lists of current serials by combinations of: title, classmark, supplier, material

type, fund code

dlxx

xv.

Binding: number of volumes sent to bind, number returned, analysis of time

spent at binding

Inter-library loans

dlxx

xvi.

Statistics of ILL requests satisfied / unsatisfied / cancelled / outstanding

dlxxxvii.

Statistics of items by supplier: requests satisfied / unsatisfied, by materialtype

dlxx

xviii

.

Costs by supplier/fund/material type

dlxx

xix.

Relative statistics of photocopies supplied / items for home loan / items

issued for reference use

dxc. Supply times: average; shortest; longest

dxci

.

Statistics of items requested, broken down by borrower category and material

type

dxci

i.

Statistics of items supplied to other libraries: requests satisfied / unsatisfied,

by material type

ukcs version3 cc licensed rev

Documents