[OPEN-ILS-GENERAL] Self Check / ILL issue - Blocking checkout

[Josh Stompro]

Hello Michele,

We did look at that also, but we would like to keep using the normal process of placing items in transit to the branch where they are needed, and then hold shelf procedure, even if the items are kept behind the desk.  Going into transit would still work though, but what would happen once the item arrives and gets checked in?  I would think the status would change to on holdshelf from the ILL status.

We are a consolidated system with a central ILL department that handles requests for our 22 locations.  So the incoming ILL items always come in to our central location and get added to the system by our ILL staff member.  Then she places the hold and sends the item out to the patron’s pickup location.  So our branches are not handling incoming ILL’s directly from the sending organization.

Josh Stompro - LARL IT Director

From: Open-ils-general [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Morgan, Michele
Sent: Wednesday, April 06, 2016 2:51 PM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] Self Check / ILL issue - Blocking checkout

Josh,
Have you considered using a different status for the ILL items?
We have the library setting "Selfcheck override events list" configured to automatically override the COPY_NOT_AVAILABLE block. But we also have the library setting "Block copy checkout status" configured to prevent checkout of some individual statuses.
You could give these items the ILL status, and block self checkout for that status using the library settings.
Hope this helps,
Michele

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


On Wed, Apr 6, 2016 at 3:27 PM, Thomas Berezansky <tsbere at mvlc.org<mailto:tsbere at mvlc.org>> wrote:
For reference:

I had thoughts about creating a "origin type" like field in the circ matrix "Staff", "OPAC", "Selfcheck", etc. Then you could set rules based on that to say "Staff can renew this, but you can't OPAC renew this" and "this can't be checked out at a selfcheck,". Add in an option on accounts in SIPServer for what context to use and you could have that context be different across SIP2 users.

The use cases I have heard are all similar to "A game case (with barcode on the outside per delivery rules) sits on the shelf, but the disk/cartridge/whatever is actually behind the reference desk".


Quoting Elaine Hardy <ehardy at georgialibraries.org<mailto:ehardy at georgialibraries.org>>:
Josh,

I don't think this is ​a problem for a software solution. I think it is
best solved by ILL workflow changes and staff education.

In PINES, ILL staff are instructed to check the item out to the patron when
they create the pre-cat record so that the due date is set correctly. As
you mentioned, it doesn't matter when the patron picks up the item, it is
still due back to the lending library at their set date. ILL staff are also
instructed to renew the item so that it cannot be renewed by the patron.
(We don't have a circ modifier expressly for ILLs, since initially, you
could not choose a circ modifier for a pre-cat. We should add one but it
hasn't been on my radar to do so and PINES libraries haven't asked for one).

The item also generally has a book strap that identifies it as an ILL item
so that it can be correctly handled on check out and return (provided the
patron leaves the strap on).

I don't know if self checkout differs, but if I try to check out, in the
client, an item already checked out to me, I get an error message telling
me that. I still would not want the item to go to the holds shelf since I
would want the patron to be verbally told the due date and any other
information. Having ILL staff check the item out may solve the self check
problem if it does inadvertently get placed there.

Elaine



J. Elaine Hardy
PINES & Collaborative Projects Manager
Georgia Public Library Service/PINES
1800 Century Place, Ste. 150
Atlanta, GA 30045

404.235.7128<tel:404.235.7128> Office
404.548.4241<tel:404.548.4241> Cell
404.235.7201<tel:404.235.7201> FAX

On Wed, Apr 6, 2016 at 2:21 PM, Josh Stompro <stomproj at exchange.larl.org<mailto:stomproj at exchange.larl.org>>
wrote:
Thanks for the idea been.  I am referring to the web based self check, I
should have clarified that.
Josh

Josh Stompro - LARL IT Director


-----Original Message-----
From: Open-ils-general [mailto:
open-ils-general-bounces at list.georgialibraries.org<mailto:open-ils-general-bounces at list.georgialibraries.org>] On Behalf Of Ben Shum
Sent: Wednesday, April 06, 2016 11:40 AM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] Self Check / ILL issue - Blocking checkout

Presuming you mean the Evergreen web selfcheck, I could only think of a
workaround approach like follows:

If you were to designate the workstation for the selfcheck to be a
different org unit (like an opac invisible child unit of the parent
library), then include a circ policy in circ_matrix_matchpoint that says,
don't circ items of a particular copy location (the ILL one) or circ
modifier (if you have an ILL circ mod?), but leave the rest to fallthrough
back up to the parent org unit rules, then the selfcheck could function
differently with regards to those materials.

Otherwise, I've found it more common that staff wanted items to be
completely restricted and not allowed for checkout (i.e. circulate = false
on the item or copy location levels) and to deal with it at the desk as you
hint would be burdensome.

Some development required maybe if we want to avoid any crazy workarounds
like the one I posit above.

And if you're talking about SIP2-based selfchecks, that's a whole other
ball game entirely....

Just thinking aloud, hope some of that might prove helpful.

-- Ben

On Wed, Apr 6, 2016 at 12:02 PM, Josh Stompro <stomproj at exchange.larl.org<mailto:stomproj at exchange.larl.org>>
wrote:
> Hello Everyone,
>
>
>
> My coworker is working on an issue with out of state ILL items, that
> we always want to have due on a specific date, even when the customer
> doesn’t pickup the item right away.  And she has been trying to figure
> out if there is a way to block a specific item from being checked out
> at the self check, but allow it to be checked out by staff without using
an override.
>
>
>
> With these items we don’t want them to go on the holdshelf, since we
> need staff to read the documentation attached and set a specific due
> date.  But they will accidentally get placed on the hold shelf, so we
> would like the self checks to not process the checkouts.
>
>
>
> I’ve looked at hard due dates documentation, but that doesn’t seem
> like it would since this situation isn’t what it was designed for.  We
> have also looked at using item alerts, but blocking based on the alert
> event would affect too many users negatively in our system since we
> use the alerts for situations that don’t require a checkout to be
blocked.
>
>
>
> We would like to avoid setting the items to non-circulate since that
> would require staff to override, which we don’t want to be a common
> occurrence that staff get used to.
>
>
>
> If something to address this doesn’t already exist, would anyone else
> find it useful to be able to block checkouts at the self check for
> specific items, but allow the checkout for staff users without an
> override?  Maybe the self check could block based on a list of
> circ_modifiers?  If something like this may be useful to more than one
> location, it might make a good enhancement.
>
>
>
> Thanks
>
> Josh
>
>
>
> Lake Agassiz Regional Library - Moorhead MN larl.org<http://larl.org>
>
> Josh Stompro     | Office 218.233.3757 EXT-139<tel:218.233.3757%20EXT-139>
>
> LARL IT Director | Cell 218.790.2110<tel:218.790.2110>
>
>

--
Thomas Berezansky
Assistant Network Administrator
Merrimack Valley Library Consortium
4 High ST, Suite 175
North Andover, MA 01845
Phone: 978-557-8161<tel:978-557-8161>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20160407/c27c744c/attachment-0001.html>