Bug 9717 - Local use recorded for holds/transfers
Summary: Local use recorded for holds/transfers
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor with 10 votes (vote)
Assignee: Bugs List
QA Contact:
URL:
Keywords:
: 13313 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-02-26 20:37 UTC by Nicole C. Engard
Modified: 2023-09-27 20:39 UTC (History)
18 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2013-02-26 20:37:32 UTC
If RecordLocalUseOnReturn is set to "Record" then whenever a hold item is returned from another library, it is being recorded as local use. The library scans the item at check in to cancel the "in transit" status and the item is counted as local use. This seems inaccurate to me. This is going to inflate the local use counts so that libraries think that that many more items are being used in-house when in reality the item is being returned from use at another library in the group.

I think that RecordLocalUseOnReturn should only record local use when there is no other status, like holds, transfers, etc.
Comment 1 Liz Rea 2013-02-27 00:26:47 UTC
Just as the devils advocate - 

if a librarian has to do something with an item (such as check it in from a transfer) that could conceivably be understood as a local use - the librarian had to use it to get it back on the shelf, just like they would have if they had picked up the item off of a table after a patron had used it and not put it away.

I guess what I am saying is, we would need a concrete idea of what exactly librarians mean, and what counts as a local use. I would want to hear this information from actual in the field librarians.
Comment 2 e-Libris Technologies 2013-02-27 14:24:11 UTC
I agree with Nicole. The purpose of recording "local" or "in-house" use is to allow libraries to count how many items are used in the library but not checked out. Turning on this system preference gives libraries a more efficient way of tracking these items instead of having to create a statistical user and check out "local use" items to this user. 

If libraries need to track how many times an item is "handled" without being checked out, one solution is to have two settings for this system preference. One setting would track local use only while the second setting would count local use and any checkins linked to transfers or holds.
Comment 3 Nicole C. Engard 2013-02-27 16:24:47 UTC
Response from a library:

----------

Yes, we had the same problem and turn off the setting and went back to a user account to count in house use.

Our problem is that it inflates the number both when holds are check in and when items in transit are checked in.

We went from and average in house of 2 to 3 thousand per library to over 50 thousand. That was because it was count transit check in and holds.


Alex Hatley
Library Technology Manager 
Corpus Christi Public Libraries
Comment 4 Nicole C. Engard 2013-02-27 16:25:40 UTC
Another email response:

---------

I vote with Nora, this bug (9717) needs to be fixed.
 
Nancy Keener
Systems Librarian
Comment 5 Christopher Brannon 2013-02-27 16:25:53 UTC
I think it should be up to the library (consortium) as to what should be counted as local use.  I can agree on both sides about staff handling books that are transferred. I think the absolute best solution for this issue is that there needs to be a new admin option on what to count as local use.

One could argue, if scanning a book that is returning from a transfer is local use, than why wouldn't inventory scanning?  Why is handling and scanning in one situation different from another?  But then again, if you are only wanting to get a count of actual patron uses outside of issues, why count non patron handling?

Christopher
Comment 6 jminges 2013-02-27 16:33:23 UTC
I agree with Nora that the only practical way for local use to function is for patron in-library use that will not be tracked as a circulation. Not that our libraries actually try to track that but they could, particularly in a sampling situation. Considering the processing of returned items, or any other technical processing as local use might theoretically be valid but eliminates the possibility of useful data for patron in-library use.
Comment 7 Nicole C. Engard 2013-02-27 17:51:06 UTC
Another via email:

-----------------

It seems to me that "local use" is pretty clearly defined in libraryland. What Liz is describing is not local use, it's local handling. Not the same thing. I would be in favor of measuring legitimate, actual local use. Inflating use stats is dishonest and counterproductive in the long run. My opinion only.
Comment 8 Nicole C. Engard 2013-02-27 17:52:52 UTC
This is me - not relaying another's email :)

I think that right now we have lots of ways to track local handling using action_logs and statistics so I don't think local use should be used for that.  Maybe changing the preference to have more options - count only items that are not checked out, count items not checked out and received as transfers, etc.

Nicole
Comment 9 Nicole C. Engard 2013-02-27 17:54:50 UTC
Another email:

--------

The question is do we follow the letter or the spirit of the rule. The spirit of local use is actual local use by you know, a human patron, the letter of the rule says if it was touched in any way that counts as local use. I vote that the rule should follow the spirit not the letter.
Comment 10 Nicole C. Engard 2013-02-27 18:40:41 UTC
Another email:

------


Here is our libray's opinion - (Thanks for asking!)

we don’t feel that it’s a bug. we think it’s a legitimate counting of in-house usage.

But we won’t be devastated if it gets called a bug and “fixed".

Adrea Lund
Head of Adult Services
Grand County Public Library
Comment 11 Chris Cormack 2013-02-27 19:19:55 UTC
Right, so it's pretty clear that since at least one library is using it in the way it was written to work changing it first everyone would be a regression. One of the important things with koha is that it works for your library, not how someone else, not even another library, thinks it should work. So we will need to change the behaviour in a way that means it can still work the way it does, as we as be able to work the new way.
Comment 12 Liz Rea 2013-02-27 20:33:52 UTC
Cool, that's helpful.

So a syspref to change the behaviour is in order, rather than a global fix.
Comment 13 Nicole C. Engard 2013-02-27 23:11:22 UTC
Comment via email:

-------

Hi Nicole,

Our library sponsored this development and first I want to say that has been working out really well for us. Although we do have two branches, we don't have a lot of books in transit, so we wouldn't see our local use inflated much from books in transit. Given that, we see no problem in changing the way local use works to not count books in transit. However, we would still like books that have a hold on them to have a local use recorded when checked in. For us, it's just a matter of how our library works and the way we use holds. Given that, I'd like to recommend that if changes are made, they be made as additional system preferences to allow libraries the option to opt in our out of the changes.

Thanks for sending this out for comment,
Amber
Comment 14 Kathy 2013-02-28 19:20:57 UTC
I agree with those that have argued that the concept of "in house use" is well-established in Library Land. This should be recording actual use of those items that don't necessarily check out of the library, but are used and re-shelved by staff (usually).

This information can assist alot when weeding non-circulating collections or those areas, often children's items or non-fiction that are used in the building.

A solution of having a variety of sys prefs that deal with various options would work for all, but we really need to fix things now. We changed our sys pref because we didn't realize Koha would begin counting the incoming transfers, etc., and now our statistics are compromised.
Comment 15 Chris Cormack 2013-02-28 19:24:14 UTC
(In reply to comment #14)
> I agree with those that have argued that the concept of "in house use" is
> well-established in Library Land. This should be recording actual use of
> those items that don't necessarily check out of the library, but are used
> and re-shelved by staff (usually).
> 
> This information can assist alot when weeding non-circulating collections or
> those areas, often children's items or non-fiction that are used in the
> building.
> 
> A solution of having a variety of sys prefs that deal with various options
> would work for all, but we really need to fix things now. We changed our sys
> pref because we didn't realize Koha would begin counting the incoming
> transfers, etc., and now our statistics are compromised.

Excellent it sounds like you will be willing to sponsor a developer to write a patch to implement the new sysprefs then? Or even better someone from your library doing the patch?
Comment 16 Barton Chittenden 2016-07-26 17:51:34 UTC
*** Bug 13313 has been marked as a duplicate of this bug. ***
Comment 17 Donna 2021-04-23 13:25:25 UTC
Changing this from enhancement to bug.  Transfers are counted/reported on separately, and as such, should not be included in local use automatically.  While the ideal fix to this double stats would be some of the options described earlier in this bug, the first step could be a system preference that determines whether or not transfers should count as local use.

This is not an insignificant issue for libraries.
Comment 18 Christopher Brannon 2021-04-23 14:41:13 UTC
It my be a topic for another bug, but I think different libraries consider local use in different ways.  Some think local use should reflect every time a book is scanned.  Some want it to only reflect browses (checked in when not checked out, showing that it was only looked at and not for some other purpose).  Some think holds and transfers shouldn't count.  Some think checking in cancelled holds shouldn't count.  We have very little control over what this counter counts.
Comment 19 David Cook 2022-08-09 05:58:44 UTC
I just bumped into this for the first time, and I really didn't expect this bug to be such a saga...

After reviewing the code in C4/Circulation.pm, the patch could theoretically be small, but it looks like no one can agree on what should or should not constitute a local use. 

But the thing is... if it's not recorded as "localuse", it's actually going to be recorded as a "return" anyway, so perhaps it's a much of a muchness. 

If people do care enough, I suppose we could have a multiple value system preference like RecordLocalUseExceptions which defines a list of situations where "return" is logged instead of "localuse". For example, you might want to record "return" instead of "localuse" if it's "OnHold" or "HasTransfer" (although this could be split into several different ones... since you can have outbound and inbound tranfers).
Comment 20 Christopher Brannon 2023-02-14 00:43:31 UTC
Because there is no way to know, when scanning an item, if it is being scanned solely for a local use or 'browse', it makes it difficult to separate a specific 'browse' count from other things it is doing.

In other ILS systems, I've seen a completely separate task button for counting browses.

The problem with an all in one scan is, how does it know when something is only to be scanned as a browse, how does it know it is completing something else, or how does it know it should do both?

If we had a preference to provide an isolated scan for browses, we could allow libraries to continue what they do with regular scanning elsewhere.  Localuse would function just as it always does.  But having the 'browse' feature on, it could provide another function on the top scan bar, and scanning items there could increment a totally new 'browse' counter - a new field in the item record.  And it would do everything else that Koha already does if needed - process a return, trigger holds or transfers, mark items found, record a local use, etc.  But the needed and specific 'browse' would be counted only if using that tab on the top input bar.  It would be a purposeful scan to indicate something specific about that item, and not just an arbitrary count that could have been for any number of things other than a browsed item.

Thoughts?