1. Barcode Tracking At ReCAP ReCAP LAS CUL “Big File” + - Pending Directory SubmitTracking Database Request Directory + Columbia University 2/6/09 Zack Lane ReCAP Coordinator

2. Logging Request Data This presentation outlines how request data is collected and archived CUL and ReCAP maintain separate record keeping databases that must be constantly reconciled Describes how the two databases are kept “in sync” Schematic simplifies the process visually

3. Status Management of CUL Collections at ReCAP CUL has a dynamic access model for ReCAP collections Patrons request off-site items via OPAC Availability is immediately updated Multiple requests for the same object are prevented Information about requests is archived

4. Request Mechanisms LITO staff have designed mechanisms to control request permissions, insert request buttons and track availability CUL staff have several methods to request material from ReCAP All methods track and update request information

5. Related Documentation "Request from OFFSITE" button : How and when it appears in CLIO"Request from OFFSITE" button ReCAP Request Mechanisms : Describes different mechanisms used to request from ReCAPReCAP Request Mechanisms Tk Item Status at ReCAP : Details on the different item statuses assigned in LAS

6. ReCAP LAS CUL “Big File” + - Pending Directory SubmitTracking Database Request Directory + Overall Schematic

7. CUL “Big File” + - CUL and ReCAP databases 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 and is not available for request CUL’s “Big File” is our local file of items “Out on Return” from ReCAP

8. Synchronized Records Data at CUL and ReCAP must be synchronized for accurate record keeping Both institutions need to know what is and what is not available for request ReCAP LAS CUL “Big File” + - Pending Directory Submit Request Directory +

9. Pending Directory SubmitTracking Database Request Directory Moment of Request Patron clicks on “Submit” button to complete a successful request Item barcode is copied into 3 separate files These files allow CUL to alert ReCAP of retrievals, maintain internal availability file and log data for patron notification and record keeping

10. Pending Directory Request data accumulates for transfer to ReCAP at 10.30am and 3.30pm daily Subsequent requests for same item are prevented by automatic check of Pending Directory Pending Directory Submit

11. Request Data Sent to ReCAP Twice daily (Mon.-Fri.) data from Pending Directory is sent to ReCAP ReCAP returns an error report of failed requests Contents are cleared during daily reconciliation ReCAP LAS Pending Directory

12. Syncing LAS with CUL “Big File” Every morning (Mon.-Fri.) a daily run synchronizes CUL and ReCAP’s records LAS records with item status In and At Rest and REFILE are removed from CUL’s “Big File” After books return to ReCAP, they become available for request in CLIO ReCAP LAS CUL “Big File” -

13. Item Status At ReCAP There are four primary item statuses at ReCAP: In and At Rest: On shelf and available Refile: Received, not yet on shelf and available Out on Return: Not on shelf and unavailable PWI/PWD: Permanently withdrawn from ReCAP In and At Rest Out on Return REFILE PWI/PWD

14. Tracking Database All submitted requests are logged in the Tracking Database (including failed requests) Staff use rus to notify patrons upon arrival of itemrus rus draws data from the Tracking Database SubmitTracking Database