1 / 17

Status Management

Status Management. Zack Lane ReCAP Coordinator September 2012. ReCAP Columbia University . Logging Request Data. Status management applies to how CUL knows what is and is not available for request at ReCAP

amanda
Download Presentation

Status Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Status Management Zack Lane ReCAP Coordinator September 2012 ReCAP Columbia University

  2. 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 ReCAP Columbia University

  3. 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 ReCAP Columbia University

  4. In and At Rest Refile Out on Return PWI /PWD 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 ReCAP Columbia University

  5. 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 ReCAP Columbia University

  6. Timeline from Request to Refile (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 charged in CLIO a b c d e 1 day 1 day 1day to 5 years 2-4 days ReCAP Columbia University

  7. Timeline from Request to Refile • 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) charged in CLIO a b c d e 1 day 1 day 1day to 5 years 2-4 days ReCAP Columbia University

  8. Schematic for Status Management Pending Directory LAS (ReCAP) + Request Submission Tracking Database - Request Directory “Big File” (CUL) + ReCAP Columbia University

  9. Moment of Request • 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 Pending Directory Request Submission Tracking Database Request Directory ReCAP Columbia University

  10. 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 ReCAP Columbia University

  11. 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) + ReCAP Columbia University

  12. Tracking Database • All requests are logged in the Tracking Database (including failed requests) • rusdraws data from the Tracking Database • rus is used to notify patrons after ReCAP delivers item Request Submission Tracking Database ReCAP Columbia University

  13. 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 ReCAP Columbia University

  14. - + 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) ReCAP Columbia University

  15. 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) + ReCAP Columbia University

  16. Status Management • Status management preserves the integrity of availability • Patrons place requests confident that collections will arrive quickly charged in CLIO a b c d e 1 day 1 day 1day to 5 years 2-4 days ReCAP Columbia University

  17. 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 ReCAP Columbia University

More Related