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

[Morgan, Michele]

Hi Josh,

Please see below:



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


On Wed, Jan 25, 2017 at 9:50 AM, Josh Stompro <stomproj at exchange.larl.org>
wrote:

> Michele, I’ve been thinking about your recommendation off and on, and now
> a year later I’m looking back into making this change,  but I want to make
> sure I understand all the issues created from this change.
>
>
>
> ·         Pull list shouldn’t be effected; only available/reshelving
> items should show up on the pull list.
>
Correct.

> ·         Missing items could still be hidden from the catalog, so public
> users wouldn’t place holds on titles that have no visible copies.
>
Correct, the opac_visible flag for the status could still be FALSE.


> ·         Patrons may be able to place holds on titles that have
> non-holdable visible copies along with invisible holdable copies.
>
Yes, that's true...

> ·         Staff will be able to place holds on titles that have only
> missing copies.
>
Also true, but the good thing is, allowing holds of this kind can alert
staff that there's a need.

> ·         Any reports that make use of config.copy_status.holdable may
> need to manually exclude missing status, for purchase alert/high demand
> holds reports for instance.  We wouldn’t want a missing copy to count
> towards a hold/copy ratio.  It may not be possible to use the built in
> reporter hold/copy ratio data sources at all since they would consider all
> Missing  copies holdable and count them as holdable copies.
>
Yes, that's a good point. In our reports we generally use explicit status
criteria.

> ·         We already have a report that goes twice a month with lists of
> holds on titles that have no holdable copies so staff can deal with them,
> so that should cover the ones that slip through.
>
Yes, that should cover it. We feel that allowing rather than denying
unfillable-at-the-moment holds and using frequent reports to identify the
unfillable holds provides valuable information for library staff. After
all, patrons don't want just the titles libraries have readily available at
the moment. We maintain a series of reports run daily for our libraries for
managing holds which helps them identify the holds that need attention.

>
>
> Does that seem to cover it?
>
>
>
> Could you also let me know what the other statuses were that you changed.
> How about lost status?  We move things to lost fairly quickly (14 days
> overdue) so we have quite a few lost items.
>

We actually changed most of the statuses to be holdable, only a few like
Bindery, Discard/Weed and a few others that are rarely used are still
nonholdable. Lost and Lost and Paid and pretty much all other statuses are
holdable.

This seems to be working well for us, libraries only need to use the
retarget checkin modifier for newly added items.

Hope this info helps with your decision process,
Michele


>
>
> I wonder if there has ever been any thought on having a new copy status
> flag, something like ‘capture allowed’.   Something that would allow copies
> to be captured to fill holds, but wouldn’t count as holdable.  Maybe
> action.hold_copy map could have a flag so when targeting or looking for
> holdable copies only holdable copies would be considered, but during check
> in captureable copies would be considered for opportunistic capture.  That
> way certain statuses (lost/missing/long overdue/cataloging) might work a
> little smoother at check in.
>
>
>
> Thanks
>
>
>
> Josh Stompro - LARL IT Director
>
>
>
> *From:* Open-ils-general [mailto:open-ils-general-bounc
> es at list.georgialibraries.org] *On Behalf Of *Josh Stompro
> *Sent:* Thursday, March 31, 2016 1:45 PM
>
> *To:* Evergreen Discussion Group
> *Subject:* Re: [OPEN-ILS-GENERAL] Missing item check-in - handling holds
>
>
>
> Michele,
>
>
>
> Thanks for the suggestion.  We will look into trying this out.
>
>
>
>
> Josh Stompro - LARL IT Director
>
>
>
> *From:* Open-ils-general [mailto:open-ils-general-bounc
> es at list.georgialibraries.org
> <open-ils-general-bounces at list.georgialibraries.org>] *On Behalf Of *Morgan,
> Michele
> *Sent:* Wednesday, March 30, 2016 10:05 AM
> *To:* Evergreen Discussion Group
> *Subject:* Re: [OPEN-ILS-GENERAL] Missing item check-in - handling holds
>
>
>
> 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/20170130/8a13b616/attachment-0001.html>