This section of the workshop will explore the following:

1
Introduction

• This section of the workshop will explore the
  following
• OPAC requesting, both local and consortial
• Request processing
• UB Integration and patron group mapping
• We presume that you have some familiarity with
  the Voyager Circulation client, Call Slip Daemon,
  OPAC WebVoyage, and System Administration.

2
Requesting Components

• People
• Patron - initiates Request in the PAC
• Library Staff - process the Requests in Voyager
  clients
• Voyager Clients
• PAC - Place Requests
• Call Slip Daemon - Process Requests
• Circulation - Check Out/Discharge
• System Administration - Policies to make it work

3
Requests Through the PAC

• Retrieve Item
• Search the Catalog (Local or UC)
• Login or Select Request button
• Complete required information
• Identify HOME Library (UB only)
• Library ID
• Last Name
• Choose type of Request to display the Request
  Form
• Add Library ID to Request Form
• Choose Pick-up Location/Desk (if applicable)
• Submit Request

4
Requests Through the PAC (Cont.)

• Patron Account Information
• Patron Account Information Displays
• Items charged
• Requests pending
• Items available for pick-up
• Fines/fees

5
LOCAL Call Slips

• IF your librarys policies allow paging
  (patrons initiating requests from WebVoyáge) or
• your library allows staff to initiate requests
  from the staff client
• AND IF
• your library will send the item directly to
  the patron, or hold the item at the pick-up
  location (hold shelf) for the patron to pick up
• THEN
• you will use Call Slip to inform your library
  staff of items to be pulled from shelving/storage
  locations on behalf of patrons.
• REGARDLESS
• whether or not you implement local Call Slip
  your staff will still use the Call Slip Daemon to
  process UB requests.

6
Types of printed slips Request / Route / Hold

• Request Slip Prints from the Call Slip client.
  Displays item information for library staff to
  pull the correct requested item from the
  shelving/storage location.
• Route Slip May print from the Call Slip client,
  the Circulation client, or the Cataloging client.
  The Route Slip contains address or routing
  information so staff can forward an item to the
  correct Happening or Pick-Up location.
• Hold Slip Prints from the Circulation client.
  The Hold Slip is attached to the item, and the
  item is placed on a Hold Shelf until the item is
  picked up by the patron, or returned to the
  items home library and shelving/storage
  location..

7
Call Slip Queues

• Request Queues Where requests for items are
  received and processed, using the Voyager Call
  Slip Daemon.

8
Call SlipsIn WebVoyáge
Examples of how SysAdmin values for Call Slip may
appear in WebVoyáge
Processing Code
No-Fill Reasons
Sys Admin / Call Slips / Values No-Fill Reasons
9
Call Slip Configuration Callslip.ini for
printing Call Slips
See I-Share recommendation at http//www.carli.i
llinois.edu/mem-prod/I-Share/circ/V6callslip.ini

• Call Slip Print Template
• Request date\T\F102\T\T\ Request ID\T\F101
• Location\T\F411
• Call Number\T\F301
• Item Barcode\A\F401\a
• Author \T\F203
• Title \T\F202
• Enumeration\T\F409\T\ Year\T\F404
• User comments\T\F109
• \
• Route to
• I-Share Library
• Library Pick Up Location\T\F105
• For Patron Barcode\T\A\F525\a

On your PC -- c\Voyager\Misc\Callslip.ini
10
Call Slip Configuration Call Slip printed from
Callslip.ini

• Callslip Request 1/31/2006 24117 PM
• Request Date 1/31/2006 240 PM RequestID2
• Location Main
• Call Number SF446 .M65
• Item Barcode
• Author Montgomery, John, 1916-
• Title World of Cats
• Enumeration Year
• User Comments
• Route to
• I-Share Library
• Library Pick Up Location Media Department
• For Patron Barcode

On your PC -- c\Voyager\Misc\Callslip.ini
11
Call Slip Configuration Callslip.ini for
printing Route Slips

• Routing Slip Print Stanza
• ROUTE ITEM Item Barcode\A\F401\a
• \Call Number\T\F301
• \Copy Info\T\F409
• TO
• Library\T\F600
• \
• Location\T\F601
• Address \F602
• \F603
• \F604
• \F607, \F608 \F609
• \F610
• Patron Category\T\F526\T\T\
• Patron Barcode\T\A\F525\a
• \

• IF an item needs to be sent from one location to
  a Circulation Desk via some form of mail or
  distribution system, you will also produce a
  Route Slip that identifies where to send the
  item first for processing.

On your PC -- c\Voyager\Misc\Callslip.ini
12
PC Config File Route Slip printed from
Callslip.ini

• Route Item 1/31/2006 24500 PM
• ROUTE ITEM
• Item Barcode
• Call Number SF446 .M65
• Copy Info c.1
• TO
• Library ILDS ISU-3 Illinois State University
• Location Main Circulation
• Address ISU Distribution Office
• 101 Somewhere Drive
• Normal, IL 61799
• US
• Patron Category Academic Employee
• Patron Barcode

On your PC -- c\Voyager\Misc\Callslip.ini
13
PC Config File Slips printed from the circ.ini
file

• Route slips, along with various other
  circulation-related printed slips e.g.,
  discharge and date due slips, etc. also print
  from the Circ client. Route slips print when
  items that will be routing to another happening
  location are discharged.
• The circ.ini file is less flexible than the
  callslip.ini file no action codes, etc., but
  you can change things like font size and margins,
  if you will be using a receipt printer at the
  Circ Desk.
• Each slip in the circ.ini file has its own stanza
  which can be edited, using a text editor.

On your PC -- c\Voyager\Circulation\circ.i
ni
14
Call Slip DaemonPreferences

• Once the Call Slip client is running, go to File
  / Preferences.
• This will allow you to configure more Call Slip
  Preferences used by this PC when printing and
  displaying requests and route slips.
• Decision Set .ini to Read Only? See Call Slip
  Daemon Implementation Users Guide, pg 4-16.

Call Slip Daemon / File / Preferences
15
Call Slip ClientPreferences
Refer to the Voyager documentation for most of
the options for this screen. There is one
section, however, to note Email Options.
When an item is Discharged at the pick-up
location, Voyager updates the item status and
sends an Available for pick-up notice to the
patron. If the patron also receives an Item
filled e-mail, the patron may assume the item is
also available to be picked up. In a consortial
environment, this is confusing for the patron.
CARLI Recommends DO NOT check these boxes!
Call Slip Daemon / File / Preferences
16
Universal Borrowing UB Rules, by Design

• Here are some hard-coded Voyager UB rules

The Circulation Policies that govern a UB
transaction (such as the Loan Period) are
determined by the library that owns the
item. The Circulation Limits that allow or block
a patrons request for an item (such as fine
limits or max. number of items than can be
borrowed by a patron at any one time) are
determined by the library that owns the item.
17
Universal Borrowing UB Rules, by Design
Since Circulation Policies and Limits are
determined by the items owning library, the
patrons home library has no input into several
Circulation Policies when a UB transaction
occurs, such as
If the remote library will accept requests from
that patron The types of items the patron can
request Whether or not items may be renewed How
fines are calculated or collected How long the
item may be borrowed Maximum limits on fees,
loans, overdues, etc.
18
Universal Borrowing UB Rules, by Design

• Your librarys CIRC Client

Will display only a limited amount of
information about UB transactions. From the item
record Patron information on a charge or
request From the patron record Item
information on requests pending or
available Will not display a remote librarys
requests, charges, over-dues, or fees accrued by
your librarys patrons.
Only the patrons My Account in WebVoyáge will
display ALL of a patrons current
Voyager-related circulation activity.
19
Universal BorrowingConfiguration

• Libraries in I-Share should configure the UB
  SysAdmin and Client components consistently.
  Otherwise,
• Route Slips from some libraries may be
  incomplete.
• Patrons and library staff will not know when to
  expect the item status to change, or what the
  next status will be.
• Request and item status displays in My Account
  will be confusing.
• Some patrons may wrongly be prevented from
  initiating requests.
• Staff may not be able to process UB transaction
  items correctly.

20
Universal BorrowingExample transaction Request

• Patty Patron (from UIUC) requests an item owned
  by ISU.
• ISU fills the request.
• Call Slip prints a route slip with address info.
• Item status is changed to In Transit On Hold to
  xxx.
• ISU forwards the item to the UIUC address on the
  route slip
• The patrons pick-up location at UIUC.
• The item arrives at UIUC.

21
Universal BorrowingExample transaction Route
Charge

• The item is sent to the patrons pick-up
  location, and the pick-up
• location discharges the item.
• Once the item has been discharged
• Item status is changed to On Hold.
• Notice is generated, informing the patron that
  the item is ready for pick up.
• UIUC places the item on the Hold Shelf at the
  patrons pick-up location.
• The patron picks up and charges out the item.

22
Universal BorrowingExample transaction
Discharge

• The patron returns the item to a circulation desk
  at UIUC.
• UIUC discharges the item.
• The CIRC client prints a route slip with ISU
  address info.
• Item status is is changed to In Transit
  Discharged.
• UIUC sends the item back to the ISU address on
  the route slip
• a de-centralized ISU Circ Happening location,
• a centralized ISU Circ Happening location, or
• a distribution center at ISU, which will forward
  the item
• to the items shelving/storage location.
• The item arrives at ISU. ISU staff discharge the
  item to remove In Transit status

23
Universal BorrowingExample transaction
Discharge

• No matter which ISU Circ Happening location
  receives the item at ISU, the receiving Circ
  Happening location discharges the item and
  forwards the the item to the correct
  shelving/storage location.
• Once the item has been received and discharged
• Item status is changed to Discharged.
• The shelving interval passes (a time you
  configure in Voyager to estimate how long it
  takes your library to reshelve items).
• Circjob1 runs overnight and changes the item
  status to Not Charged.
• Hopefully, ISU has since re-shelved the item.

24
UB Request PromotionSo, How Does it Work?
An example

• UIUC, ISU, and the other I-Share libraries are
  in a resource sharing network that is currently
  using UB and Request Promotion.
• Lets say that Patty Patron -- a patron at
  UIUC-- requests a specific item from ISU.
• Voyager creates a Call Slip request at ISU.
• ISU discovers that the item is too damaged to be
  sent to Patty.
• ISU un-fills the request.
• That night, Circjob32 runs and tries
• to promote the request based on DBCODE in
• ISUs promote.cfg file

ISUs DBCODE
DBCODE UIUCdb OAKdb WIUdb
25
UB Request PromotionSo, How Does it Work?

• Circjob32
• 1. Steps through the libraries in ISUs DBCODE
• UIUCdb is not eligible to receive this
  request
• therefore, UIUCdb is not queried
• OAKdb is eligible to receive this request
• therefore, OAKdb is queried
• OAKdb has an available copy.
• 2. Creates a new Call Slip -- a title-level
  request --
• -- in OAKs appropriate Call Slip Queue.
• 3. Archives the un-filled request at ISU

ISUs DBCODE
DBCODE UIUCdb OAKdb WIUdb
More on this shortly.
26
UB Request PromotionIneligible for promote

• On the previous slide, circjob32 did not try to
  promote the request to UIUC. Why not?
• A library in DBCODE is not eligible to
  receive a promoted request when the library is
  the patrons home library.
• - UIUC is Patty Patrons home library.
• - Promote assumes that some other library is
  trying to fill
• the request because Pattys home library --
  UIUC --
• does not have an available copy.
• - Therefore, UIUC is not eligible to receive
  Pattys request
• from Request Promote.

27
UB Request PromotionIneligible for promote

• Also A library in DBCODE is not eligible to
  receive a promoted request when the library
  has already un-filled the request.
• A request is promoted based on the promote.cfg of
  the library that un-filled the request. In other
  words

- ISU has promoted the request to OAK. - OAK
receives the request, then discovers the item is
lost. - OAK un-fills the request. OAKs next run
of Circjob-32 will promote the request based on
OAKs promote.cfg file. - OAKs DBCODE ISU
has already un-filled the request. UIUC is the
patrons home library. The first eligible
library in OAKs DBCODE is WIU.
OAKs DBCODE
DBCODE ISUdb UIUCdb WIUdb
28
UB Request PromotionTitle-Level Requests

• Request Promote searches eligible libraries to
  find a bib record that matches the promoting
  request based on search criteria defined in
  SERIALS or MONOGRAPHSstanzas of each
  librarys promote.cfg file. The promoted request
  receives the bib_id of the first bib record that
  matches the search criteria.
• Because a newly promoted request is based on the
  bib_id instead of the item_id, the promoted
  request is a title-level request.

29
UB Request PromotionEnd of the Line

• There are several ways a request can reach the
  end of the line -- when a request cannot be
  promoted and will never be filled
• 1. None of the libraries in the DBCODE list can
  receive the request. Each library is either
• -- ineligible because it is the patrons home
  library,
• -- ineligible because it has already no-filled
  the request, or
• -- eligible, but does not have a Not Charged or
  Discharged copy of the item.
• 2. The patrons needed by date has expired.

30
UB Request Promotion Report to assist staff

• CARLI staff have developed a custom-report for
  I-Share libraries to assist them in informing
  their patrons when their requests cant be
  promoted any further.
• Voyager does not have such a utility
• Available in the librarys ftp account. File
  name dead_req_XXX_mmmdd_yyy.txt
• Contains bibliographic and patron information so
  that staff can advise the patron on subsequent
  requesting alternatives