Re: [OPEN-ILS-GENERAL] Fulfillment Prioritization
Having given the problem some more thought, I have come up with the following alternate implementation. Instead of an org unit setting, or checkin modifier, I would create a new matchpoint table, similar to the circ and hold matchpoint tables, complete with a weighting set. A simplified view of that table would be similar to this: Transit Source Transit Destination (Checkin Library) Transit Item Owning Library Transit Item Circ Library Checkin Item Owning Library Checkin Item Circ Library Min Time in Transit Max Time in Transit Min Hold Age (Possibly Min Stalling Age) Max Hold Age (Possibly Max Stalling Age) Allow Hold Recapture With the exception of Allow Hold Recapture all of the fields would be optional. In the event that no matching rule is found (which would be the default) then hold recapture would be disallowed. As an extra catch, I would want to tie the org unit fields (the first six) to the Relative Org Unit work from my Circ and Holds rewrite, allowing things like the transit destination is the checkin item circ library as a global rule. This delays my ability to work on this until that work is completed. I believe that the mapping table will allow for all existing use cases that have come up, including some that I came up with while considering it. Including, but not limited to, avoiding intentionally making *any* transit useless by only recapturing if the transiting copy is coming home anyway (as it would for reshelving). The Min/Max Transit times would allow for not recapturing a transit that is expected to finish shortly, or to allow recapture when the transit has taken so long so as to be deemed lost in transit (the ultimate in useless transits, I suspect). The Min/Max Hold Age (see my circ/hold rewrite email for why I say possibly the Stalling age) would allow for things like a hold must be a week old before we are willing to recapture for it and similar, in the event that is desired by someone. I would, of course, still want to not run the code when capturing local holds as transits and would still want to not allow recapture instead of transiting for a force or recall hold. I am considering whether or not a don't recapture local holds checkin modifier would be a good idea to force the code to not run. Also, while thinking about it, I am not sure this code should ever run when FIFO is active. Oh, and on the subject of the don't transit when a copy is on the local shelf and never allow an item to go into transit when there is a local copy, checked out or otherwise I think that is best covered by things like stalling periods and soft boundaries, which I think already cover all of that if configured correctly. Thomas Berezansky Merrimack Valley Library Consortium
Re: [OPEN-ILS-GENERAL] Fulfillment Prioritization
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 eha...@georgialibraries.org www.georgialibraries.org http://www.georgialibraries.org/pines/ -Original Message- From: open-ils-general-boun...@list.georgialibraries.org [mailto:open-ils-general-boun...@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
Re: [OPEN-ILS-GENERAL] Fulfillment Prioritization
I think you have the hijack backwards. You are assuming that an in transit hold will be hijacked and pulled back to the home library. In fact, the only hijacked transits will be Patron A has a hold with a copy in transit, we will ignore the in transit copy and put this copy we are checking in on the shelf for them *right now* instead, pushing the transiting copy off of the hold. No patron will get a copy that was going to a different patron as a result. It looks like most of your other concerns on this stem from that initial misunderstanding, though you are correct that things may go right back into transit when they show up. That is no different than if a hold is canceled while in transit, though. Thomas Berezansky Merrimack Valley Library Consortium Quoting Hardy, Elaine eha...@georgialibraries.org: 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 eha...@georgialibraries.org www.georgialibraries.org http://www.georgialibraries.org/pines/ -Original Message- From: open-ils-general-boun...@list.georgialibraries.org [mailto:open-ils-general-boun...@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
Re: [OPEN-ILS-GENERAL] Fulfillment Prioritization
That was my misunderstanding, so glad for the clarification. Rather ask now than after it's been developed... Then my pretend-it's-magic request -- when an in-transit item is re-directed, have a message pop up (with twenty seven eight-by-ten color glossy pictures with circles and arrows and a paragraph on the back of each one) that explains that the original hold was cancelled because a local hold was found to fill it. 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 eha...@georgialibraries.org www.georgialibraries.org http://www.georgialibraries.org/pines/ -Original Message- From: open-ils-general-boun...@list.georgialibraries.org [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Thomas Berezansky Sent: Monday, March 12, 2012 8:34 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Fulfillment Prioritization I think you have the hijack backwards. You are assuming that an in transit hold will be hijacked and pulled back to the home library. In fact, the only hijacked transits will be Patron A has a hold with a copy in transit, we will ignore the in transit copy and put this copy we are checking in on the shelf for them *right now* instead, pushing the transiting copy off of the hold. No patron will get a copy that was going to a different patron as a result. It looks like most of your other concerns on this stem from that initial misunderstanding, though you are correct that things may go right back into transit when they show up. That is no different than if a hold is canceled while in transit, though. Thomas Berezansky Merrimack Valley Library Consortium
Re: [OPEN-ILS-GENERAL] Fulfillment Prioritization
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 eha...@georgialibraries.org www.georgialibraries.org http://www.georgialibraries.org/pines/ -Original Message- From: open-ils-general-boun...@list.georgialibraries.org [mailto:open-ils-general-boun...@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
Re: [OPEN-ILS-GENERAL] Fulfillment Prioritization
Costs incurred for useless transits (a good working term) for PINES libraries would include staff time in processing the transit as well as the customer service problems increased time in delivery could cause. However, developing a seamless (to frontline staff) way to maximize the number of local items fulfilling local holds while minimizing useless transits caused by that, would go a long way toward minimizing the staff and patron customer service problems caused by any useless transits. I will say that frontline staff get really aggrieved when they have to deal with useless transits -- which they would also define as a transit that occurs from another library when the title is on their shelf. Having a way to trap that local item when it was returned, even though there already is an item in transit to fill it . I'm not sure how that would be seen by frontline staff. It would make the patron happier since presumably they would get the item faster. But it still might be seen as an increased work burden by staff because they have to process that useless transit. What they want (and I argue against) is for no outside system item to be transited as long as there is a local item that could fulfill the hold -- even if that local item is checked out. To me, that would really increase patron wait time since the nonlocal transited item could arrive before the local item is returned. I would not want to see my misunderstanding of Thomas's proposal -- an item from Library A arriving at library B being immediately re-transited back to Library A for a local patron hold there, leaving the patron at library B without the requested item until another could arrive to replace it. The costs in staff time and bad customer service that would result from that scenario wouldn't, in my opinion, be made up in the advantage of more local items filling local holds. Luckily, I was mistaken in what he is proposing. 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 eha...@georgialibraries.org www.georgialibraries.org http://www.georgialibraries.org/pines/ -Original Message- From: open-ils-general-boun...@list.georgialibraries.org [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Mike Rylander Sent: Monday, March 12, 2012 9:54 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Fulfillment Prioritization On Mon, Mar 12, 2012 at 8:34 AM, Thomas Berezansky tsb...@mvlc.org wrote: I think you have the hijack backwards. You are assuming that an in transit hold will be hijacked and pulled back to the home library. In fact, the only hijacked transits will be Patron A has a hold with a copy in transit, we will ignore the in transit copy and put this copy we are checking in on the shelf for them *right now* instead, pushing the transiting copy off of the hold. No patron will get a copy that was going to a different patron as a result. It looks like most of your other concerns on this stem from that initial misunderstanding, though you are correct that things may go right back into transit when they show up. That is no different than if a hold is canceled while in transit, though. So that we're all using the same terms, I'll offer some definitions for the context of the discussion: * A useful hold transit is one that ends with an item on a hold shelf * A useless hold transit is one that ends in another transit -- either to fill a different remote hold or a return transit The problem, from the PINES perspective IIUC, is increasing useless transits. The is that a useless transit costs on average twice what a useful one does, both in terms of the time of the item being completely unavailable to anyone, and in money spent by the library. On the other hand, a useful transit costs the patron some amount of time waiting for their item to arrive. So the balance that must be struck is to reduce the cost to both parties as much as possible to some minimum. From an objective point of view in a PINES-like environment, because there is a monetary cost to useless transits, the importance of reducing these is greater than the importance of reducing the wait time for the patron, and hold hijacking would tend increase the number (and aggregate cost) of useless transits. [NOTE: This is an over-simplification of reality for the sake of argument. For PINES, there may be no direct monetary cost for each useless transits, but there can be significant costs down the road at courier contract renewal if the load caused by newly useless transits makes the total volume increase well beyond the purely-useful transit load.] The inverse, of course, could be true for an organization with fixed courier costs, or extremely low per-transit costs. For them the opportunity costs in terms of patron service may
[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
