[OPEN-ILS-GENERAL] Fulfillment Prioritization

[Thomas Berezansky]

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