[OPEN-ILS-GENERAL] Recalls in Evergreen

[Frances Dean McNamara]

Geoff,

I revised my document to include some options to cover what you want to do, I think.  We, too, actually have most every hold be a recall.  So recalls need to be at the level of the specific copy/volume, not at the title level.  In our current system we set the parameters to patrons can only do recalls, and only on items that are checked out, not things on the shelf.  We don't have enough staff to page for them.  I think Evergreen needs to handle both types of situations, both the title level holds that are used now, and the volume specific recalls that we need.

Frances McNamara
University of Chicago

-----Original Message-----
From: open-ils-general-bounces at list.georgialibraries.org [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Geoff Sinclair
Sent: Friday, March 06, 2009 8:47 AM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] Recalls in Evergreen

Frances Dean McNamara wrote:
>
> I can see that Recalls are on the list of features for the 2.0 version 
> of Evergreen. We have written up what we mean by recalls in the 
> attached document. This is an important feature for academic libraries 
> that allow some borrowers to take materials out for an extended period 
> of time and need to be able to call those items back when they are 
> needed for a class or another researcher. It's especially important 
> for academic libraries that support graduate work.
>
> I wanted to put this description out for comment by other Evergreen 
> users to see if all needs are met. I didn't see any other description 
> of recalls on the Wiki. We do not have a proposed method of 
> implementing this or detail on how it would be done, but it would be 
> useful to have a discussion of whether this meets the need of others 
> who might use a recall feature.
>
> Let me know.
>
> Frances McNamara
>
> University of Chicago
>

Great stuff! We want to approach Recalls from a slightly different 
angle, although our current ILS hasn't done a very good job of 
supporting this!

1) For undergraduates, our Recalls are more informational:
-- The main purpose is to tell the student, in a friendly way, that 
another patron wants the book they have, and would they mind bringing it 
back as soon as they can if they're finished with it? We'd prefer to 
phone them.
-- We don't want to change the due date (their loan periods fairly short 
to begin with).
-- We'd like them to have the book for a few days before we send them a 
Recall notice (so they don't get a phone call or Recall notice the day 
after they check out a book).
-- We haven't increased late fines for Recalled books, but we might 
consider this in the future.

2) For Faculty, our Recalls are more functional:
-- We have extended loan periods for Faculty, so we would like Recalls 
to shorten those loan periods, to something approaching the 
undergraduate loan period.
-- We'd like to send them a Recall notice immediately, to give them as 
much time as possible to return the book.
-- We don't have fines for faculty, but we'd like to block them from 
borrowing new books if they're holding on to a recalled book.

3) We'd like holds to generate Recalls in *most* instances.
-- In our present ILS, we have some special patrons, such as "Repair" 
and "Bindery". For example, when we checkout a book that's in need of 
repair, we place a hold on it for the "Repair" patron, so we know the 
patron isn't responsible for the damage when it's returned to us, and 
then it's routed into our repair workflow. In these cases, we wouldn't 
want a "Repair" hold to prevent a real patron from renewing the book, 
and we wouldn't want it to generate a Recall notice.

Maybe this last point reflects a workaround particular to our ILS, and 
there's a better way to do this in Evergreen? :-\

Geoff

-- 
Geoff Sinclair
Manager of Technical Services
Education Centre Library, Nipissing University / Canadore College
Tel: 705-474-3450 x4439
E-mail: geoffs at nipissingu.ca
Web: http://www.eclibrary.ca


-------------- next part --------------
A non-text attachment was scrubbed...
Name: EVRecalls.doc
Type: application/msword
Size: 38400 bytes
Desc: EVRecalls.doc
Url : http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20090310/5460bccc/attachment-0001.doc