USER DOCUMENTATION

Booking Management

 Ex Libris Ltd., 2003

Release 15.5.1

Last Update: September 15, 2003

Table of Contents

1. Introduction

2. Booking Management Setup – General

Scheme

3. Patron Interface

3.1 Standard Browse (in Booking Library)

3.2 Full Catalog Record

3.3 Booking Request

Booking Request (type A)

Booking Request (type B)

Booking Request (type C)

3.4 Request Confirmation

3.5 List of Patron’s Booking Requests

4. Staff Interface

4.1 Circulation

4.2 Record View

Search

Results List

Full Record View

List of Copies and Booking Requests

Create Booking Request

Create Booking Request Calendar Wizard

Booking Request (time filled in from Calendar Wizard)

Confirm Request

Re-allocation of Booking Requests

4.3 Patron View

Search

Patron List

4.4 View/Update/Delete/Loan

List of Bookings on Patron

List of Bookings on Record

Expand

Update

4.5Printouts

5. BOOKING Catalog Record

6. Item Records

7. Service Hours

8. Preview and Release Times

9. Deadtime

10. Setup of Relevant Configuration Tables

Indexing( /tab in the BOOKING library)

tab15 in the ADM library/tab

tab25 in the ADM library/tab

tab57 in the ADM library/tab

tab_hold_request in the ADM library/tab

tab10 in the ADM library/tab

tab_expand (/tab in the BOOKING library)

tab_booking_06 (/tab in the BOOKING library)

last-tme-sequence (UTIL G/2 in the BOOKING library)

Alephe/library – relation

www_server.conf

tab_base.eng in alephe/tab

xxx70 WEB OPAC pages in www_f_eng

Patron Records

11. Batch Services

12. Booking Module Password Authorizations

1. Introduction

The Booking Management component of the ALEPH 500 Integrated Library System is used to reserve an item for use at a later time. Booking can be applied to any type of object, including traditional library materials (such as books and videotapes), moveable equipment (such as projectors, VCRs, laptop computers), and stationary objects (such as rooms, internet stations). In addition to advance booking, the component includes facilities for tracking maintenance of equipment and creating pull and pickup lists for delivery of equipment. The Booking Management component provides an interface with Circulation Management. The patron can view a list of the bookings he has made. The items can be loaned to the patron, in which case the rich facilities of ALEPH 500’s Circulation Management can be used for generating overdue notices and calculating late return fees. Loans can be viewed in the regular manner in the patron’s loans list.

2. Booking Management Setup – General

The system uses an ALEPH “library”. In the ALEPH DEMO setup, these are the USM70 and USM71 libraries. A particular site can choose any 5-character code as the name, and should set up multiple booking libraries, on a one-to-one relationship with ADM libraries. The library is defined as DOC-TYPE-BIB, and is a BIB library in all aspects of cataloging, indexing and retrieval. The record contains special fields used by the Booking Management component.

Scheme

There are different ways to manage the Booking Library setup. The DEMO setup assumes that library materials (such as videotapes) are cataloged in the library’s bibliographic database. No special cataloging is required. The fact that the item is intended for booking is indicated in the item record, by the item status (tab15.eng, col.8 = B). Non-bibliographic objects (such as equipment and rooms) are cataloged only in the booking database.

The assumption is that the library will not want to “clutter” or “dirty” its bibliographic database with records for non-bibliographic objects. However, the library can opt to catalog everything in the general bibliographic database.

There is a batch process for creating records in the booking library for material that is defined has a “booking” item status, and has been cataloged in the bibliographic database.

If the object is cataloged in the booking library (e.g., USM70), there is a direct link to the ADMinistrative record and its associated item record(s). If the object is cataloged in the BIB library, there is a link to the BIB library record, through which there is a link to the BIB’s ADM library record.

The patron can place requests either through the booking database or the regular BIBliographic database. The database s/he accesses depends on library setup, policy and end-user guidelines. In either case, whether the patron has accessed the booking database or the regular OPAC, s/he is automatically presented with the booking database page for registering a request.

3. Patron Interface

3.1 Standard Browse (in Booking Library)

In the patron interface, the end-user searches the booking database in the same manner as the OPAC, by means of browse indexes or keywords.

3.2 Full Catalog Record

A booking request is initiated when a single full record is displayed in the booking library’s database, or from the “Request” link on the list of items in the bibliographic library’s database.

In the booking library’s database, this appears as follows:

In the bibliographic library’s database, this appears as follows:

3.3 Booking Request

The system displays a calendar, on which it is apparent which slots are available. The end-user marks the slots and submits the request. The system performs checks; if the request is blocked, relevant messages are displayed.

If the user is permitted to request that the material be delivered, a drop-down list will display the list of delivery location options. The display of “delivery locations” is dependent on the check of the patron status against the DLV field.

If the patron checks the “Reminder” checkbox on the booking confirmation, s/he will be informed when a booking time approaches. The “Print Reminders for Booking Requests (04)” batch service is used to notify the patrons.

Booking Request (type A)

Booking Request (type B)

Booking Request (type C)

3.4 Request Confirmation

If the booking request is allowed, a confirmation screen appears.

3.5 List of Patron’s Booking Requests

The booking requests of a patron are listed under the User (“My Library Card”), similar to loans, hold requests, etc. The patron is allowed to delete his own booking request.

4. Staff Interface

The staff interface is accessed from <ALEPH Web Server>/E. Login with authorized password is required. When a request is placed, the system performs the same checks as are performed in the Patron Interface. Relevant messages are displayed, but the request action is not blocked. The operator can decide whether or not to continue (confirm).

The following functions are included in the staff interface:

  • Search by patron ID/barcode/name. The last patron is saved for the duration of the session.
  • Search for BOOKING records (by phrase, keyword, system number, booking sequence number, item barcode, booking date). The last record is saved for the duration of the session.
  • Display the result list of BOOKING records, with the ability to display a single record.
  • On a single record, ability to:
  • see the list of bookings for the record within a defined time span
  • create, delete or update a booking
  • loan a booked item (if the booking time is current)
  • temporarily remove an item from circulation
  • View patron’s current and future booking requests:
  • booking request can be updated or deleted
  • currently booked item can be loaned
  • Loan item – using item and patron barcode
  • Return item – using item barcode
  • Handling of Materials Booking printouts. Viewing, printing and deleting files in XXX70 data_print directory.

4.1 Circulation

A LOAN is performed in the Circulation Window of the Booking Staff Interface. A Z36 loan record is created (and can be used for follow-up), and BOOKING fields are updated: TME $$h is updated to “L” and CPY $$s is updated to “L”.

A RETURN is performed in the Circulation Window of the Booking Staff Interface. The Z36 record is moved to Z36H and BOOKING fields are updated: TME field is updated to $$h “H” and the CPY $$s is updated to “A”.

If the item being checked in has “deadtime” defined in the SCT field, the item is automatically checked out to DEADTIME for the period of time defined for deadtime. When an item which is checked out to DEADTIME is checked in, it becomes available again. In this manner, the library can control the actual deadtime.

The library must create a patron with ID DEADTIME.

4.2 Record View

A booking is placed on the full record view. Therefore, the first step in creating a request is to search for a single record. A record can be found by keywords (including request date or date-time), system number, request sequence number or barcode. If the search query finds more than one record, a brief list of records is displayed, and the operator chooses a record from the list.

Search

Results List

Full Record View

The full view is made up of three sections on one page: List of Copies, List of Bookings and Record Description. A button to “Create Booking Request” displays the request input form.

List of Copies and Booking Requests

The default for number of days for “From – To” is set in the booking_period_interval in www_server.conf file.


Create Booking Request

Create Booking Request Calendar Wizard

Booking Request (time filled in from Calendar Wizard)

Confirm Request

Re-allocation of Booking Requests

When a copy becomes unusable (lost, in repair), staff will invoke the “Reallocation” function on the list of copies in the Staff interface.

It is possible to perform an online check of the effect on bookings that removing a copy from circulation (for a particular time period) will have. This function can be used to re-distribute booking requests when a copy becomes unavailable (damaged, lost, in repair, etc.). Clicking the Re-allocation link on the relevant copy displays the list of bookings that are endangered. When the link on the copy is clicked, the system checks to see whether there are future booking requests that can no longer be fulfilled, because there will not be enough copies, and it displays these requests. The operator can then choose a request for potential deletion, after which the system re-checks availability, and re-displays requests that cannot be filled. The process can be repeated until the best solution is found, at which point the operator deletes the desired request(s).

After clicking the Re-allocation link, the following page appears. Requests that conflict for the time period requested are listed under “Conflicting requests”. Clicking the Booking Seq. link transfers the request to “Suspended requests” and re-displays the “Conflicting requests” list.

When all conflicting requests have been resolved, clicking “Go” prepares a “deleted request letter” which will print for all the requests listed under “Suspending requests”, and updates the status of the copy (CPY $$s) and the requests (TME $$h) to X.

4.3 Patron View

The booking requests that have been placed by or for a patron are displayed under the patron. The patron record can be searched on the "Search” window by entering the patron ID or by entering the patron name in order to browse the patron list and choose from there.

Search

Patron List

4.4 View/Update/Delete/Loan

A booking record can be updated from either the Patron view or the Record view. In both instances, a list of the bookings is displayed with operation icons E, U, D, L:

- E displays the request in an expanded view

- U displays the request in update mode

- D deletes the request

- L performs loan. The L icon is displayed only when the booking request time is current.

List of Bookings on Patron

List of Bookings on Record

Expand

Update

4.5Printouts

Files created by Materials Booking are handled through use of the ‘Printouts’ tab.


A list of the files found in the data_print directory is shown. Each file can be viewed, deleted or printed using the icons to the left of the file name. The list can be sorted by name, size or date.

In addition, multiple files can be selected and deleted using the ‘Delete’ icon that is found above the file list.

5. BOOKING Catalog Record

The Booking record has special fields for booking management:

  • ALW (optional) – sets the authorization parameters for placing a request
  • SCT – type of schedule (time unit)
  • CPY – contains details of the item record; in many respects (data and functionality), this field is parallel to the ALEPH Z30 item record
  • DLV (optional)– used to indicate that the object is “deliverable” and is used to control who may ask to have the item delivered
  • TME – contains details on the booking or the loan; in many respects this field is parallel to the ALEPH Z37 (hold) and Z36 (loan) records
  • MNT (optional) – equipment maintenance parameters, for createng maintenance lists
  • TYP (optional) – contains the code of the material type
  • CMP (optional) – contains TYP codes; can be used as suggestion of other related materials to book [codes are displayed, additional functionality (create set) is planned]
  • ACQ (optional) – contains acquisition information

One CPY field can have multiple related TME fields. The connection between a loaned CPY and its TME field is contained in subfield $$8 in each of the fields.
Additional fields can be set using MARC or mnemonic codes; e.g., 245 for TITLE, DSC for DESCRIPTION.

There must be a separate booking record for each location and schedule type. Multiple copies of the same item are listed on one booking record. Each booking record also has Z30 item records for each CPY.

  • ALW field: Contains repeated subfield a, with each subfield defining:

|asublibrary, patron status allowed, fee amount.

The system checks the status of the Z305 (local patron) record. If # is used instead of status, all statuses are allowed.

Fee amount is optional. There will also be a cash transaction (tab18.eng), similar to a hold request [not yet implemented]

If check type “r” is defined in the BKING section of the ADM library’s tab_hold_request table, the system checks the patron’s expiry date.

Note: Records that don’t have ALW field can be loaned to all patrons.

  • SCT field: Contains parameters for the type of schedule:

|atype of scheduling unit

A=day, request cannot be placed for less than a full day

B=hour

C=hour-with automatic extension backward and/or forward, if the item is requested when the library is closed

|pparameters

sublibrary=xxxxx<sublibrary code from tab_sublibrary>

max=nn<maximum number of adjoining time units that can be booked at one time; e.g., for 2-hour slot $$a is B and $$p is max=02>

autoex=Y/N<extend through library closed time to next open time, if end-of-request time falls into a closed time>

adjacency=Y/N<allow booking of adjacent times>

deadtime=nn:nn<time (hh:mm) required for maintenance after use; e.g., re-winding a tape, re-imaging a laptop. When an item is returned, it is automatically loaned to “DEADTIME” for this period, and is unavailable for request.

  • CPY field: The field is repeated for each copy of the item

|8link number (sequence number, used to link TME and MNT fields to the particular copy)

|bsublibrary

|c collection

|llocation

|didentifier of the copy (barcode)

|eidentifier of the copy (Z30_REC_KEY)

|fitem loan status code (matches tab15 and Z30)

|gitem processing status code (matches tab15 and Z30)

|scurrent status of copy (on loan, lost, maintenance…)A=available; L=on loan: any other character means not available.

|udate copy was last updated (z30-update-date)

Notes:

The loan status code in tab15.eng should have “B” in col.8 to indicate that this

is a “bookable” item.

The CPY fields can be created from Z30 item records, using the Create CPY Fields (booking-02) batch service. It is preferable to create them in this manner than to add or modify the data directly in the CPY field in the Cataloging function. In order to disallow update in Cataloging, add the following line to usm70/pc_tab/catalog/permission.dat: USERNAME CPY## N

  • DLV field: This field indicates the patron status that is allowed to request that the material be delivered. The presence of the field indicates that this is a “deliverable” object. It contains repeated subfields a and b, with each subfield defining:

|asublibrary + patron status allowed; separated by a comma; repeat the subfield for multiple patron statuses

|blocation code + delivery time (hh:mm) + location text; separated by a comma; repeat the subfield for multiple locations. If the delivery time is left blank, the system uses the environment variable defined in booking_delivery_time in www_server.conf file.

  • TME field: Repeated for each request and/or use of a copy. When a request is loaned, the TME field is updated.

|8link number (sequence number, used to link TME field to a particular CPY field). Present only when copy is loaned.

|arequester/user ID

|bnotify patron (by e-mail) of approaching booking time (Y/N)

|cexpanded request date:time from (nnnnnnnn:nnnn), taking into account delivery

|dexpanded request date:time to (nnnnnnnn:nnnn), taking into account delivery and dead time

|trequest date:time from (nnnnnnnn:nnnn) (as input on request form)

|qrequest date:time to (nnnnnnnn:nnnn) (as input on request form)

|elast interest date:time [for future development for regular request functionality]

|fdate:time (nnnnnnnn:nnnn) that request was made (system generated)

|greturn date:time (nnnnnnnn:nnnn)

|hcurrent transaction status (R=request, L=loan, H=returned, X=unsuccessful re-allocation)

|nfree text note

|ppickup (i.e., delivery) location

|srequest sequence number - system assigned, unique over all booking requests; uses Z52-last-tme-sequence, and must be registered in the booking library’s Z52 sequences (UTIL G/2).

  • MNT field: Maintenance can be set as a function of time or of number of uses, whichever comes first.

|8 link number (sequence number, used to link MNT field to a particular CPY field)