[OPEN-ILS-GENERAL] Missing item check-in - handling holds

Morgan, Michele mmorgan at noblenet.org
Wed Mar 30 11:04:32 EDT 2016


Josh,

To avoid the issues with Missing copies not capturing holds, we changed the
config.copy_status.holdable flag for the Missing status to TRUE. This means
that items with status Missing get entries in the hold_copy_map and can be
captured when checked in.

We did this with a handful of the more transient statuses that were not
holdable by default and that has worked well to help with the checkin
issues.

It's true that making these statuses holdable can result in holds being
placed on records with no items currently available, but we provide reports
to help our libraries follow up on these.

That said, I like your idea of attacking the problem based on the copy
that's being checked in without forcing all that retargeting.

Hope this helps,
Michele

--
Michele M. Morgan, Technical Assistant
North of Boston Library Exchange, Danvers Massachusetts
mmorgan at noblenet.org


On Fri, Mar 25, 2016 at 11:48 AM, Josh Stompro <stomproj at exchange.larl.org>
wrote:

> Hello, does anyone have any suggestions with how to best handle
> missing/lost items with holds at check-in?  What I think is happening is
> that the missing items don’t have any entries in action.hold_copy_map since
> they were not holdable.  Now that they are available again, there will be
> no entries in the hold copy map until the first hold gets retargeted.  So
> the check-in either sends the item to re-shelving or in-transit back to the
> circ lib, even though there may be holds waiting locally or at a closer
> location than the circ lib.
>
>
>
> The copy will show up on the pull list after at least one of the holds
> gets retargeted, but it won’t necessarily be the correct hold that is next
> in line until 24 hours later.
>
>
>
> The work arounds that I know of are to use the Retarget Local Holds &
> Retarget all statuses check in modifiers, which will help if there are any
> local holds.  But if there are no local holds then this won’t address the
> issue.  The second work around is to manually select holds to retarget from
> the holds list.
>
>
>
> Has anyone worked out a way for this to happen automatically, so that at a
> status change from a non-holdable to holdable status the copy gets added to
> the hold copy map for all active holds, so opportunistic capture works with
> the expected results without needing work arounds?
>
>
>
> I’ve looked at the check-in modifiers that tsbere added, looking to see
> how feasible it would be to have a “Retarget All Holds” mode, which looks
> possible, but could lead to long pauses during check-in while all the holds
> are re-targeted for titles with many holds.  Or maybe the re-target local
> holds could have a depth setting, so it would grab all the holds in a
> branch or system, or consortium.
>
>
>
> I wonder if it would be possible to attack the problem based on the copy
> vs calling the retarget function for each hold?  I wonder if a simpler
> process would work, one that just tries to add the copy to the hold copy
> map for each hold, without trying to figure out which hold should have the
> current_copy set to that copy.  Then the opportunistic capture process can
> make the final decision.   But I guess that could delay capture
> unnecessarily if stalling is in use.  Or maybe stalling could be ignored
> when no holds are targeting a copy.
>
>
>
> Thanks
>
> Josh
>
>
>
> Lake Agassiz Regional Library - Moorhead MN larl.org
>
> Josh Stompro     | Office 218.233.3757 EXT-139
>
> LARL IT Director | Cell 218.790.2110
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20160330/b1c31b5c/attachment.html>


More information about the Open-ils-general mailing list