Dead Requests Report

Requests and Promotes that could not be filled by an I-Share library

Description of the Request Promotion Process:

When a patron places a request for an item through the OPAC, a call slip or UB request is sent to a library to fill the request. Ideally, the library is able to fill the request.

When the library does not fill the request, one of two things can happen:

If the library does nothing to the request, then the request will "Expire" usually within 4 days after the request was initially placed. When Voyager expires the request, the request will disappear from the library's call slip queue.
If the library selects a "No-Fill" reason and then unfills the request, the request will immediately disappear from the library's call slip queue.

NOTE: The terms No-Fill, nofill, and unfill are used interchangably by various I-Share library staff members. This document uses "No-Fill" because that is the term used in Voyager's Call Slip module.

Once a request has been no-filled by the library or expired by Voyager, Voyager will attempt to forward the request to another I-Share library to be filled. The Endeavor term for forwarding the request in this fashion is “Request Promotion”. The order in which libraries receive promoted requests is determined by each library’s promotexxx.cfg file, an internal system file that is used during the run of the library’s daily Request Promotion job [circjob32].

Once a request has been promoted to another I-Share library, the request will be filled or unfilled by the library, or eventually expired by Voyager. Every time a request is no-filled or expired, Voyager will try to promote the request.

Description of the Problem:

If several libraries No-Fill a request, Voyager will reach a point where the request can no longer be promoted: either there are no other I-Share libraries that have an available copy of the title, or there are no other libraries that hold the title.

If a request has a status of Expired or No-Filled, and the request cannot be promoted to another library, it can't be filled.

At this stage, the request is called a dead request.

Unfortunately, Voyager does not have a mechanism to notify a patron that a request will not be filled by any I-Share library. This is what the patron will see in the OPAC in the Request Information section of MyAccount:

The request will have a status of No-Filled, which displays in the OPAC as "In Process".
The request will display in the Pending Requests section on the MyAccount screen for the duration of the archive period--a setting in each libraries' call slip system administration.
Then the request will archive and disappear from WebVoyáge.

The patron will receive no written notice or email explaining that the request could not be filled. Eventually the request will simply disappear from their MyAccount screen without any further explanation.

The Solution:

CARLI Data Services has prepared a report that will help libraries identify their patrons that currently have dead requests. Depending on the library's policies, the library can:

contact patrons to let them know their requests will not be filled,
help the patrons re-initiate the requests,
choose to submit requests to alternate ILL services, etc.

The report contains the following information:

Fields to help libraries identify their patrons' requests that are now dead
patron_home_db	In your report you will ONLY receive information regarding your library's patrons. The data in this field has two formats:
	XXXdb	tells you that your patron originally placed this request against an item owned by your library.
	Z_XXX	tells you that your patron initially submitted this request as a UB request; i.e., the request was placed against an item owned by another library.
patron	The patron's first and last name
patron_barcode	The patron's barcode -- this value is pulled from the patron stub record at another library; this value is usually the same as the patron's barcode at your library, but occasionally it may be different.
email	The patron's email address
req_date	If the request has never been promoted, this date is the date the request was made. If the request has been promoted, this date is the last time the request was promoted.
date_needed_by	For UB requests, requests have a finite life span; the life span is calculated by the "Needed By" value entered on the UB request form. For example, if the "Needed By" value is 21 days (the default), Voyager will automatically cancel the request after 21 days if the request has not yet been filled.
oclc_number	MARC 035a		normalized OCLC number.
title	MARC 245ab		brief title
author	MARC 100/110/111		author
pubdate	MARC 260c		publisher date

Fields to help CARLI Data Services with troubleshooting, when needed
req_library	The library that last received this request, either by patron initiation or by the promote process.
call_slip_id	The call slip id number for the request at the last library.
req_status	The request status for the request at the last library.
stub_id	Internal Voyager identifier for the patron's stub patron record.
home_id	Internal Voyager identifier for the patron's home patron record.
note_and_req_hist	Note field from the latest version of the request; it shows the request's promote history.
status_date	The last time the status of the request was changed at the last library.

Specific information about the dead requests report:

CARLI Data Services will run the report every night after all the promotion jobs have completed.
The reports should be placed in the ftp directories every day around 8 am. You will receive a report only if you have patrons that have dead requests; if your patrons have no dead requests, you will not get a report.
It is possible that some libraries will never have patrons with dead requests, so will never receive a dead request report.
Although dead requests live in the Voyager system for a certain number of days before getting archived, each dead request should appear on the report only one day.
All reports are being placed in each library's [XXXftp] directory on the Voyager Reports server [files.carli.illinois.edu].
The report name starts with "dead_req", followed by the library code and the run date of the last promote run. For example, below is the name of a dead request report created after the promote job for ISU completed on September 4th at 4:16 a.m.:
- dead_req_ISU_Sep04_0416.txt
Because the date is embedded in the name of the file, daily files will not be overwritten by later reports.
The report will be a tab-delimited file with a file extension of .txt; it should easily load into MS Excel. After importing into Excel, some libraries may have the following formatting glitches:
- if the date fields look like this: '########', make the date fields wide enough to fit all of the dates in the date columns.
- if the patron_barcode field looks like this: '3.4E+0', make the barcode field wide enough to fit 14-character barcodes. If the barcode is still unreadable,
select the patron_barcode column
go to <alt> Format / Cells
go the Number tab
Select "Number"
Set the number of decimal places to 0 (zero)
click <OK>
make sure the column is wide enough to fit all the barcodes