[OPEN-ILS-GENERAL] Fulfillment Prioritization

[Hardy, Elaine]

Thomas,

While improving the hold fulfillment along these lines would be helpful
for our patrons and staff, I do see some problems with the idea to
"hijack" an in transit item to fulfill the hold. While these issues won't
necessarily occur if there are plenty of copies of a title within a
consortium, I do see them occurring for those titles with few copies in
the consortium. The problems I outline below would be if there are no
copies in the local system for the original hold to fulfill and a hold for
a patron at the owning library hijacks it after it is received at the
original hold library.

A lot of patrons monitor their holds, especially if it is an item they
need by a certain date or just really want to read. If suddenly a copy
that was in transit to them is back to waiting for a copy, I see unhappy
patrons. Unhappy patrons that the front desk staff would need to deal
with, without understanding themselves why it happened. I can see staff
adding to the unhappiness if they let the patron know they saw the item
come through and it went right back out.

Another potential problem is increased costs in courier service, depending
on how a library pays for that service. We pay per pickup, but if someone
pays per package, immediately sending an in transit item back out might
add costs. Although other changes that would make the local copy more
likely to be trapped would decrease costs and might balance this. It is
also going to increase staff time when they have to repackage the item to
send it back out for what they would see as no  reason.

Another potential problem, at least in PINES, is that it could increase
the amount of time all holds on an item would take to be filled as well as
that individual hold by the local patron. It is very possible that the
"hijacked" item takes another week or longer to make it back to the local
patron, where an item at a nearby, out of system, library would be there
faster. For us, this is because of the time it can take to get from branch
to central, where the statewide courier picks it up and then the time on
the other end from central library to branch. Some systems can only afford
once a week pickup at their branches. So, even when the courier delivers
from central library to central library within days, another two weeks can
be added to transit times because of local issues.

As I re-read your steps, how you are thinking of the design may make some
of the above not occur (if you mean that if there is no local item at the
holding library, the item will stay to fulfill that hold before it returns
to the owning library) but I just wanted to make sure you've considered
them.

Elaine
 
 
J. Elaine Hardy
PINES Bibliographic Projects and Metadata Manager
Georgia Public Library Service,
A Unit of the University System of Georgia
1800 Century Place, Suite 150
Atlanta, Ga. 30345-4304
404.235-7128
404.235-7201, fax
 
ehardy at georgialibraries.org
www.georgialibraries.org
http://www.georgialibraries.org/pines/


-----Original Message-----
From: open-ils-general-bounces at list.georgialibraries.org
[mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of
Thomas Berezansky
Sent: Friday, March 09, 2012 5:04 PM
To: Evergreen Discussion Group
Subject: [OPEN-ILS-GENERAL] Fulfillment Prioritization

There is a desire for copies to fill local holds before going into
transit, even when there are already copies in transit. This would result
in copies showing up to fill holds that are already filled, but would also
allow for holds to go to the hold shelf faster when a copy is already
right there.

I have worked out the following thoughts for this, but would like more
opinions before work is started on it.

The general idea would be to add a new Org Unit setting to control the
behavior. When enabled copies returned to the library would:

1 - Look for non-captured holds at the current location. If any exist,
capture for them and move on to the hold shelf.
2 - Look for captured but in transit holds at the current location. If any
exist, "hijack" that hold and move on to the hold shelf. The original copy
will remain in transit.
3 - Resume all other holds/transit/reshelving/etc code normally.

This may require teaching the hold targeter to update the list of copies
*without* wiping the captured state of in-transit holds, perhaps with a
special parameter passed in. That parameter may be best supplied when
doing the "Retarget Local Holds" checkin modifier work, rather than as
part of normal hold targeting. Especially if the first additional
limitation below is included.

I am thinking that there may need to be additional limitations, for sanity
purposes, but am not sure about them:

1 - Limit to copies owned by the library that the checkin is happening at.

This would basically prioritize local copies as filling local holds, but
would not prevent someone else's copy from transiting. That transit may
even be back to their own library.

2 - Not run the code if capturing local holds as transits.

Because otherwise you may just be displacing things that are intentionally
in a limbo-transit state.

3 - Require a checkin modifier be active, which may remove the need for
YAOUS.

If replacing the YAOUS then this would allow for per-workstation
decisions. If alongside the YAOUS then the YAOUS being disabled could be
used to hide the checkin modifier outright. Either way SIP may need to be
taught how to (optionally) enable this modifier.

4 - In the event of a Force or Recall hold being in the stack, *never*
fill a different hold instead.

These are copy level "force cut in line because we have a really good
reason" holds in Master/2.2, and I don't think we should avoid transiting
to fill them.

Thomas Berezansky
Merrimack Valley Library Consortium