Status ManagementZack Lane

ReCAP CoordinatorSeptember 2012

ReCAPColumbia University

ReCAPColumbia University

Logging Request Data Status management applies to how CUL

knows what is and is not available for request at ReCAP

CUL and ReCAP maintain separate record keeping systems that are synchronized on daily basis

This presentation illustrates how the two databases are kept in sync

Schematic drawings simplify the process visually

ReCAPColumbia University

Available at ReCAP for Request Item must be accessioned at ReCAP Status at ReCAP must be

◦ In and At Rest ◦ Refile

Status Out on Return indicates that the book has been retrieved and delivered to Columbia

Items Out on Return are unavailable for request

ReCAPColumbia University

Status in LAS There are four primary

statuses in LAS◦ In and At Rest : On

shelf and available◦ Refile : Received,

available but not yet on shelf

◦ Out on Return : Not on shelf and unavailable

◦ PWI/PWD : Permanently withdrawn from ReCAP

In and At Rest

Out on Return

Refile

PWI/PWD

ReCAPColumbia University

Status Management CUL has a dynamic model

for request via CLIO Availability is immediately

updated after request Multiple requests for the

same object are prevented Information about requests

is archived Subsequent request

permitted after refile at ReCAP

ReCAPColumbia University

(a) moment of request =(b) retrieved by ReCAP, routed for delivery(c) received by CUL and charged (d) returned to CUL Circ and discharged(e) received by ReCAP and refiled

Timeline from Request to Refile

a b

1 d

ay

1 d

ay

2-4

days

1d

ay

to5 y

ears

d eccharged in CLIO

ReCAPColumbia University

Timeline from Request to Refile

a b

1 d

ay

1 d

ay

2-4

days

1d

ay

to5 y

ears

d eccharged in CLIO

Item is available for request before (a) and after (e)

Presence of barcode in Pending Directory, then “Big File” prevents request between (a) and (e)

Active charge prevents request between (c) and (d)

ReCAPColumbia University

Schematic for Status Management

+

-

Pending Directory

Request Submission Tracking Database

Request Directory

+ LAS (ReCAP)

“Big File” (CUL)

ReCAPColumbia University

Patron clicks on “Submit” button

Item barcode is copied into three separate files

These files allow CUL to… ◦ alert ReCAP of

retrievals◦ log data for patron

notification and record keeping

◦ maintain integrity of status management

Moment of Request

Pending Directory

Request Submission Tracking Database

Request Directory

ReCAPColumbia University

Pending Directory Request data

accumulates for transfer to ReCAP at 7:15am, 11:45am and 2:45pm

Subsequent requests for same item are prevented by automatic check of Pending Directory

Pending Directory

Request Submission

ReCAPColumbia University

Request Data Sent to ReCAP

Three times daily (Mon-Fri) data from Pending Directory is sent to ReCAP

ReCAP returns an error report of failed requests

Contents of Pending Directory are cleared daily

Pending Directory + LAS (ReCAP)

ReCAPColumbia University

Tracking Database

All requests are logged in the Tracking Database (including failed requests)

rus draws data from the Tracking Database

rus is used to notify patrons after ReCAP delivers item

Request Submission Tracking Database

ReCAPColumbia University

Request Directory

Request directory used to maintain integrity of status management

Feeds into “Big File,” which tracks all items Out on Return from ReCAP

Request Submission

Request Directory

ReCAPColumbia University

CUL “Big File” “Big File” tracks

unavailable ReCAP books that are Out on Return

CLIO and LAS do not have a dynamic connection

CUL must keep a separate record of items Out on Return from ReCAP

This is how CUL knows what is not available for request

+

-

“Big File” (CUL)

ReCAPColumbia University

Syncing LAS and CUL “Big File” Every weekday morning

a daily run removes available barcodes from “Big File”

Items with status In and At Rest and Refile in LAS are removed from “Big File”

They are now again available for request in CLIO

+

-

+ LAS (ReCAP)

“Big File” (CUL)

ReCAPColumbia University

Status management preserves the integrity of availability

Patrons place requests confident that collections will arrive quickly

Status Management

a b

1 d

ay

1 d

ay

2-4

days

1d

ay

to5 y

ears

d eccharged in CLIO

ReCAPColumbia University

Other Related Information LITO staff have designed mechanisms to

control access and insert request buttons ◦ Access Permissions : How access to CUL’s Offsite

collections is controlled◦ The Offsite Request Button : How and when it

appears in CLIO CUL staff have several methods to request

material - all methods log and archive data◦ ReCAP Request Mechanisms : Describes different

mechanisms used to request from ReCAP