Re: [OPEN-ILS-GENERAL] Circulation And Holds "Rewrite"
Going down your replies... For relative OU matching: I was planning on allow both absolute and relative matching in the same matchpoint, but not on the same *field*. That is, each "ou" field in the matchpoint would be allowed to be null, a specific OU, or a relative OU. Thus, you could say that the user's home library is SYS1 OR the user's home library is the item circ library, and that wouldn't affect your ability to choose absolute or relative for the item's circ library field in the same matchpoint. For Stalling Start: I was thinking that a solution there would be if you re-froze the hold for longer than the stalling period then the stalling period would be reset on thaw. For Age Protection: I don't want to tear out the existing age protection checks from the INDB functions. I do want to be able to override them, say to do age protection entirely with matchpoint rules. Thus I want to add a boolean to the matchpoint that says "if this is true then skip the age protection checking block so that we don't say this is age protected". Matching on the age protect rule then gives the benefit of being able to reproduce age protection with the custom codes and more granular checks than just the transit range and age. For subparts: For my current view of implementation I am planning on using a second mapping table for the subparts already which would basically map the parts table to itself in a many to many relationship. I apologize if I implied that I would be creating an entirely new kind of "part" there. Thomas Berezansky Merrimack Valley Library Consortium Quoting Mike Rylander : This shouldn't be construed as implicit endorsement of the whole plan, but I have some initial thoughts below. Overall, it's heading in a good direction, IMO. On Mon, Mar 12, 2012 at 1:20 PM, Thomas Berezansky wrote: I would like to make a number of changes to circulation and holds, but have determined that they will interact with each other significantly code-wise. Thus I am planning to do them as one large project, rather than as smaller chunks that would be difficult to keep working with each other independently. Before I begin, however, I would like input on the plans I have so far. [snip] Relative Org Units ~~ One major limitation of the Circ and Hold matrix tables is that all org unit checks are done with absolute org units. In order to say, for example, "the user's home library is the item's circ library" you need one rule per home library. I want to resolve that by adding relative org unit lookups. For a given org unit checking column you would be able to say "I want to match based on this specific org unit (current behavior) or an org unit defined by the user, item, or for holds the requestor". My current plans are to support the following fields for the relative lookups: * User's home library * Item's circ library * Item's owning library * Requestor's home library (for holds only) I plan on putting these checks into a table to allow for some customization, specifically to allow for depth modification. That would allow you to check against, for example, the system the user's home library is in instead of just the specific branch. Both modes (absolute and relative OUs) need to be allowed on the same matchpoint. That way you can say "for items owned by a branch in system X /and/ the user's home library is the item's circ library". Stalling Start ~~ Currently stalling doesn't take into account when a hold was suspended, or re-activated. That means that a hold can "eat up" the entire stalling period by being frozen. The goal here is to add a new field to holds that is reset when the hold is placed or re-activated. That field would then be used for stalling calculations, allowing for stalling periods to occur on a hold that spent weeks suspended. Would freezing and then thawing a hold cause it to go through a new stalling period, or does this only apply to holds that start frozen? Or, perhaps, are frozen within the initial stalling period? Age Protection ~~ Currently age protection in INDB rules is a copy level one rule check, but is remarkably inflexible. The addition of custom failure codes will permit a hold rule to pretend to be age protection, but without a couple of additional fields on the hold matrix that may not be enough. Thus, I want to add two more fields to the hold matrix for age protection purposes. The first is a match field for the age protection rule in use, to allow matching of copies that use specific age protection rules. This would allow, for example, the addition of a second age protection check on top of the normal one for a second range, so a rule that limits to the branch could then be extended to include the system for an extra period of time. The second field I want to add is a result field to allow a rule to skip the normal age protection checks. Set globally you would be moving age
Re: [OPEN-ILS-GENERAL] Holds on serials issuances
On 03/12/2012 12:00 PM, Mary Llewellyn wrote: Hi Lebbeous, All this took place within the staff client. I set up a list of one person on a stream for a distribution of a subscription. I successfully set up a prediction. I went to Serials Batch Receive. The routing box was checked off as well as the "Receive?" box. I also had the Create Units box checked off. I clicked on the Receive Selected Items box and up popped a box with the error message TypeError: xulG.urls is undefined." No tab with a routing list opened up. Hi again Mary, You can reproduce this error at will, right? If so, can you open the Javascript console in the staff client first (in the staff client menus, follow Admin -> For developers -> Javascript console), and within the Javascript console click "Clear" right before you trigger the error in another tab? I'd be interested in any error messages from the bottom of the console (not the CSS-related warnings that always fill console) that appear coincident with the pop-up about TypeError, as well as any errors from the same moment in your server logs, if you have access to those. I think that information will be more telling than the TypeError message, which I'm afraid I still can't reproduce, and which isn't giving me any ideas so far. Thanks! -- Lebbeous Fogle-Weekley | Software Developer | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: lebbe...@esilibrary.com | web: http://www.esilibrary.com
Re: [OPEN-ILS-GENERAL] Circulation And Holds "Rewrite"
This shouldn't be construed as implicit endorsement of the whole plan, but I have some initial thoughts below. Overall, it's heading in a good direction, IMO. On Mon, Mar 12, 2012 at 1:20 PM, Thomas Berezansky wrote: > I would like to make a number of changes to circulation and holds, but have > determined that they will interact with each other significantly code-wise. > Thus I am planning to do them as one large project, rather than as smaller > chunks that would be difficult to keep working with each other > independently. Before I begin, however, I would like input on the plans I > have so far. [snip] > Relative Org Units > ~~ > > One major limitation of the Circ and Hold matrix tables is that all org unit > checks are done with absolute org units. In order to say, for example, "the > user's home library is the item's circ library" you need one rule per home > library. > > I want to resolve that by adding relative org unit lookups. For a given org > unit checking column you would be able to say "I want to match based on this > specific org unit (current behavior) or an org unit defined by the user, > item, or for holds the requestor". > > My current plans are to support the following fields for the relative > lookups: > > * User's home library > * Item's circ library > * Item's owning library > * Requestor's home library (for holds only) > > I plan on putting these checks into a table to allow for some customization, > specifically to allow for depth modification. That would allow you to check > against, for example, the system the user's home library is in instead of > just the specific branch. > Both modes (absolute and relative OUs) need to be allowed on the same matchpoint. That way you can say "for items owned by a branch in system X /and/ the user's home library is the item's circ library". > Stalling Start > ~~ > > Currently stalling doesn't take into account when a hold was suspended, or > re-activated. That means that a hold can "eat up" the entire stalling period > by being frozen. > > The goal here is to add a new field to holds that is reset when the hold is > placed or re-activated. That field would then be used for stalling > calculations, allowing for stalling periods to occur on a hold that spent > weeks suspended. > Would freezing and then thawing a hold cause it to go through a new stalling period, or does this only apply to holds that start frozen? Or, perhaps, are frozen within the initial stalling period? > Age Protection > ~~ > > Currently age protection in INDB rules is a copy level one rule check, but > is remarkably inflexible. The addition of custom failure codes will permit a > hold rule to pretend to be age protection, but without a couple of > additional fields on the hold matrix that may not be enough. > > Thus, I want to add two more fields to the hold matrix for age protection > purposes. The first is a match field for the age protection rule in use, to > allow matching of copies that use specific age protection rules. This would > allow, for example, the addition of a second age protection check on top of > the normal one for a second range, so a rule that limits to the branch could > then be extended to include the system for an extra period of time. > > The second field I want to add is a result field to allow a rule to skip the > normal age protection checks. Set globally you would be moving age > protection checks 100% into the hold matrix rules, but there are other use > cases as well. For example, a special user group that gets to ignore age > protection for some reason. > I'm not following this last part. > Subparts > > > Currently a copy can have a single part assigned to them. This can be a > problem when a patron wants, say, a single DVD from a box set, but the box > set is broken up in multiple ways. The patron has the option of picking one > part that covers the DVD they want and waiting for that hold to fill or > placing one hold for each part that contains the DVD they want and possibly > getting them all at once. > > This would solve that problem by creating an optional list of "Subparts" for > each part. If set then the part would fill holds for the part itself or > subparts thereof. > > For example, if you have a "Disc 1-3" part you could have subparts of "Disc > 1", "Disc 2", "Disc 3", "Disc 1-2", and "Disc 2-3". The "Disc 1-2" part may > be defined as having "Disc 1" and "Disc 2" as subparts, and the same for > "Disc 2-3" with "Disc 2" and "Disc 3". A patron placing a hold on "Disc 2" > would then be able to get a copy flagged as "Disc 2" directly, or a copy > that is flagged as "Disc 1-3", "Disc 1-2", or "Disc 2-3" to fill their hold. > > A secondary checkbox, only visible when subparts are in use, could allow for > patrons to indicate whether they want any part that can fill the request or > only the specific part they are selecting. > Alternative idea: how about a part grouping map. Usi
[OPEN-ILS-GENERAL] Circulation And Holds "Rewrite"
I would like to make a number of changes to circulation and holds, but have determined that they will interact with each other significantly code-wise. Thus I am planning to do them as one large project, rather than as smaller chunks that would be difficult to keep working with each other independently. Before I begin, however, I would like input on the plans I have so far. Also, before anyone panics about some of the more significant changes listed here I would like to point out that there is no chance of this work making it into 2.2 at this time. I highly recommend you read the HTML version of this email, if only for formatting purposes. You can find it at http://mvlcstaff.org/circ_holds_rewrite.html and it contains everything here except for this note to go look at it. General Changes --- Some of the changes I am looking to make apply equally to circulation and holds, and are the main reason I am changing circulation and holds at the same time. Remove Legacy Script Support At this point Legacy Circ Scripts are not recommended for use, and most groups appear to be trying to move away from them. In addition to that, I suspect that some of the things I am looking to change are being done to make INDB act, to the rest of the system, more like the legacy scripts do. As a result of this, rather than attempt to tie any new features into the legacy script support, I would prefer to tear the legacy script support out entirely. This has additional side benefits as well, such as removing a source of confusion for new developers from the code base. I am willing to work with people on reasonable lists of things that they can currently accomplish with scripts that INDB won't be able to handle, even if I don't see a significant need for the functionality myself. Updated Editors ~~~ One of the biggest complaints, if not the biggest complaint, about the circ and hold matrices is the horrendous state of the editors. Thus I plan on re-writing them from scratch to hopefully be more useful. Included in this would be a filtering interface and use of the server-side weighting values to order the fields as close to as the server will when applying them as possible. I also hope to put in "test" fields where patron and item barcodes can be input to determine what rules would apply. Splitting "Grouped" Failure Reasons ~~~ Currently a number of failure reasons share a single failure code. For example, right now you cannot distinguish a matrix rule saying no from the copy saying no from the copy location saying no for circulation or holds. That means you can't assign different override permissions for each failure reason, leaving them at all or nothing. To my knowledge this is being done to make INDB look more like legacy scripts. See above for my thoughts on that. I would like to split these "grouped" reasons into their individual codes, removing the old codes and exposing the INDB backend codes instead. Custom Failure Codes In addition to splitting up the "Grouped" codes I feel it would be good to allow for custom failure codes, with descriptions, to be placed into the system. This would allow for Circ and Hold matrix rows that disallow the circulation or hold to return a code other than the current "the row said no" failure code. In addition, the Circulation Limit Sets feature would also get the ability to have these codes applied. This would allow for staff to get descriptive reasons for why a circulation failed, rather than a simple "the rules said no" response. For example, you may have "Local Use Only" patrons that can't circulate items out of other libraries, or perhaps you want to indicate that an item isn't suitable for patrons flagged as juvenile. As an added benefit you would then be able to assign override permissions based on these failure codes, giving even more granular control over what can and cannot be overridden. These failure codes would come from a global list of valid codes, one each for the circ and hold matrix (because some codes make no sense in one context, but others may be fine in both). Relative Org Units ~~ One major limitation of the Circ and Hold matrix tables is that all org unit checks are done with absolute org units. In order to say, for example, "the user's home library is the item's circ library" you need one rule per home library. I want to resolve that by adding relative org unit lookups. For a given org unit checking column you would be able to say "I want to match based on this specific org unit (current behavior) or an org unit defined by the user, item, or for holds the requestor". My current plans are to support the following fields for the relative lookups: * User's home library * Item's circ library * Item's owning
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 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 te
Re: [OPEN-ILS-GENERAL] Holds on serials issuances
Hi Lebbeous, All this took place within the staff client. I set up a list of one person on a stream for a distribution of a subscription. I successfully set up a prediction. I went to Serials Batch Receive. The routing box was checked off as well as the "Receive?" box. I also had the Create Units box checked off. I clicked on the Receive Selected Items box and up popped a box with the error message TypeError: xulG.urls is undefined." No tab with a routing list opened up. I hope this helps. Thanks! Mary -Original Message- From: open-ils-general-boun...@list.georgialibraries.org [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Lebbeous Fogle-Weekley Sent: Monday, March 12, 2012 9:12 AM To: open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] Holds on serials issuances On 03/08/2012 10:30 AM, Lebbeous Fogle-Weekley wrote: >> 2. In the streams area, I was able to create a small routing list, >> but got an error when I tried to receive an issuance with the routing >> box checked. "TypeError: xulG.urls is undefined." > > That sounds like a bug, and if I can't readily reproduce it, I'll come > back soon to ask you for more details on how it happened for you. > Hi again Mary, I wasn't able to reproduce this in my development environment running master, but can you tell me more about it? Regarding the error message you quote, did you see it in a pop-up dialog, in the Javascript console, or elsewhere? If you saw it in the Javascript console, was it the bottom-most error message at the time you tried the receive operation? Was a staff client tab opened for the routing list, but then the list either didn't display at all or didn't print? Or was there not even a tab opened (this is what typically happens for routing list printing). Thanks! -- Lebbeous Fogle-Weekley | Software Developer | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: lebbe...@esilibrary.com | web: http://www.esilibrary.com
Re: [OPEN-ILS-GENERAL] Fulfillment Prioritization
On Mon, Mar 12, 2012 at 8:34 AM, Thomas Berezansky 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 be measurably higher than the monetary and unavailability costs to the library. In that case this feature would be useful. IMO, assuming my analysis is sound and given the structural differences required to make one or the other of the above true, I'd suggest that this would need to be a bit more complex than outlined above, and because of that it should be controlled by an Org Setting instead of "circ staff choice". The added complexity would be to only hijack holds when the transiting copy is coming from a particular subset of the org hierarchy. For an Evergreen instance in use by a single library system that wants hijacking across the board, this would be the top of the org tree, of course. But, for a PINES-like installation, it might be set up to allow this only within a single regional system where, for instance, they have an internal courier system that has no per-transit costs and does daily intra-system delivery. This is partially suggested by the "only hijack with locally-owned copies", but I would go further and say that the transit source and destination should play a role as well, because it's not really the copy we're concerned with, but the cost of making a useful transit useless (though the copy's ownership is something that's useful to consider, especially politically). Make sense? -- Mike Rylander | Director of Research and Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com > > Thomas Berezansky > Merrimack Valley Library Consortium > > > Quoting "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 tha
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] Holds on serials issuances
On 03/08/2012 10:30 AM, Lebbeous Fogle-Weekley wrote: 2. In the streams area, I was able to create a small routing list, but got an error when I tried to receive an issuance with the routing box checked. "TypeError: xulG.urls is undefined." That sounds like a bug, and if I can't readily reproduce it, I'll come back soon to ask you for more details on how it happened for you. Hi again Mary, I wasn't able to reproduce this in my development environment running master, but can you tell me more about it? Regarding the error message you quote, did you see it in a pop-up dialog, in the Javascript console, or elsewhere? If you saw it in the Javascript console, was it the bottom-most error message at the time you tried the receive operation? Was a staff client tab opened for the routing list, but then the list either didn't display at all or didn't print? Or was there not even a tab opened (this is what typically happens for routing list printing). Thanks! -- Lebbeous Fogle-Weekley | Software Developer | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: lebbe...@esilibrary.com | web: http://www.esilibrary.com
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" : 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
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 trans
