Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Title-level hold allows item status that doesn't allow holds to fulfill request

    • Article Type: General
    • Product: Aleph
    • Product Version: 20, 21, 22, 23

    Description:
    This morning, one of our sublibraries was discharging a reserve item (item status 14 - two hour loan). It was accepted to fill an outstanding title-level hold request instead of the standard loan item. We have tab15.eng set to not allow holds on item status 14 on our development server. Tab16 is set also to not allow holds on this sublibrary/item status combination. Tab100 is set to consider only items of the same item status for fulfillment of holds.

    How is it that the item status 14 was able to fulfill the hold? Just because it was the first one discharged? How do we adjust our settings to not allow an item status to fulfill a hold request?

       [Later:]
    As our new semester has begun, this has become a serious problem. Some of our titles have 16 hold requests on them and the only work-around we can come up with is to delete those title-level requests that are becoming linked to 2-hour loans (item status 14) and re-submit item level requests for the standard loan items (item status 01). This is a lot of manual work that the staff don't have time to do.

    Resolution:
    Ex Libris response: Changing the current behaviour is not possible through Support channels; it would require an enhancement request.

    [The site switched from title-level requests back to item-level requests in order to avoid this problem.]

     

    Additional Information:

    One site noticed was that, if the item was in a separate sublibrary from the reserve location, they didn’t see the problem. (One of their libraries has Reserves set up in a separate sublibrary and almost never has this issue, while another library has Reserves in the same sublibrary as the general collection and has run into the issue often.)   It's when the item and the reserve item reside in the same sublibrary that they see this behavior.  

    Once the sublibrary (holding-group) is a potential target for the item, it seems the first copy discharged there triggers the hold.

    Their other workaround has been to make sure all copies within a sublibrary are on reserve, but that isn’t always practical.

     


    • Article last edited: 4-Oct-/2018