Bug 10378 - Enable checked out items to be transferred without returning them
Summary: Enable checked out items to be transferred without returning them
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-29 16:42 UTC by Kyle M Hall
Modified: 2020-06-04 20:32 UTC (History)
3 users (show)

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


Attachments
Bug 10378 - Enable checked out items to be transferred without returning them (5.27 KB, patch)
2013-05-29 16:47 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 10378 - Enable checked out items to be transferred without returning them (7.39 KB, patch)
2013-05-29 16:58 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 10378 - Enable checked out items to be transferred without returning them [ v3.10.05 ] (7.48 KB, patch)
2013-05-29 17:00 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2013-05-29 16:42:43 UTC
When items are transferred, they are automatically returned to the transferred-from library. Some libraries would like to be able to use the transfer system without automatically returning the item and having it removed from the patron record.

Scenario:
LibraryA of multi-library system is checking in items from the overnight dropbox. The librarian pulls out a damaged item, but it is an item owned and checked out from LibraryB. Instead of removing the item from the patrons checked out items, the library would like to transfer the item, still checked out, back to LibraryB so that LibraryB may decide how to deal with the damaged item.
Comment 1 Kyle M Hall 2013-05-29 16:47:28 UTC Comment hidden (obsolete)
Comment 2 Kyle M Hall 2013-05-29 16:58:13 UTC
Created attachment 18477 [details] [review]
Bug 10378 - Enable checked out items to be transferred without returning them

When items are transferred, they are automatically returned to the
transferred-from library. Some libraries would like to be able to use
the transfer system without automatically returning the item and having
it removed from the patron record.

Scenario:
LibraryA of multi-library system is checking in items from the overnight
dropbox. The librarian pulls out a damaged item, but it is an item owned
and checked out from LibraryB. Instead of removing the item from the
patrons checked out items, the library would like to transfer the item,
still checked out, back to LibraryB so that LibraryB may decide
how to deal with the damaged item.

Test Plan:
 1) Apply this patch
 2) Run updatedatabase.pl
 3) Ensure that ReturnItemWhenTransferred is enabled
 4) Check an item out to a borrower
 5) Transfer the item to another library
 6) Verify the item was returned and removed from the patron's issues
 7) Disable ReturnItemWhenTransferred
 8) Check an item out to a borrower
 9) Transfer the item to another library
10) Verify the item is still listed in the patron's current issues
Comment 3 Kyle M Hall 2013-05-29 17:00:24 UTC Comment hidden (obsolete)
Comment 4 Galen Charlton 2013-05-31 20:02:30 UTC
Exploring the consequences a bit ... the libraries in question are OK with the possibility that the loan might incur overdue fines while in transit back to the owning library?  And they *always* want manual transits to not check the item in?

If the answer to the second question is along the lines of "on a case-by-case basis", I wonder if the syspref should simply enable the _option_ of transiting without returning, in conjunction with a checkbox (and possibly a user permission) for a circ staffer to indicate that a particular loan should not be checked in.
Comment 5 Kyle M Hall 2013-06-07 13:34:16 UTC
That's not a bad idea. However, another issue is that Koha has simply not been written with the idea an item can be checkout out and in transit at the same time. It appears that there are parts of Koha that will assume a checked out item isn't being transferred and not display the in transit message.

I think this idea only half-baked and needs some followups, if it is to be pushed.

(In reply to comment #4)
> Exploring the consequences a bit ... the libraries in question are OK with
> the possibility that the loan might incur overdue fines while in transit
> back to the owning library?  And they *always* want manual transits to not
> check the item in?
> 
> If the answer to the second question is along the lines of "on a
> case-by-case basis", I wonder if the syspref should simply enable the
> _option_ of transiting without returning, in conjunction with a checkbox
> (and possibly a user permission) for a circ staffer to indicate that a
> particular loan should not be checked in.
Comment 6 Galen Charlton 2013-06-07 16:30:29 UTC
(In reply to comment #5)
> That's not a bad idea. However, another issue is that Koha has simply not
> been written with the idea an item can be checkout out and in transit at the
> same time. It appears that there are parts of Koha that will assume a
> checked out item isn't being transferred and not display the in transit
> message.

Indeed -- from the patron's point of view, the item is no longer in her possession, and she has returned it to a library.  And it's easy to understand why Koha makes the assumption that checked out == in the patron's nominal possession, therefore can't be transiting between libraries.

Maybe a different way to tackle the problem is add a way of keeping track that a loan was returned to the "wrong" library?  That way, the loan can still be checked in while providing some hooks for functionality to penalize the patron, if that's what your customer is after.

A starting point might be added a returnbranch column to issues.  That would be useful for other purposes, particularly for consortia and large multi-branch systems.

Anyway, due to our mutual agreement that this idea needs more work, I'm setting this bug to In Discussion.
Comment 7 Nick Clemens (kidclamp) 2019-06-06 19:02:35 UTC
Not sponsored, no current work planned here