[Koha-bugs] [Bug 25975] New: Receiving a manual transfer triggers another transfer (non-floating collection)

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25975

            Bug ID: 25975
           Summary: Receiving a manual transfer triggers another transfer
                    (non-floating collection)
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5 - low
         Component: Circulation
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: caroline.cyr-la-rose at inlibro.com
        QA Contact: testopia at bugs.koha-community.org
                CC: gmcharlt at gmail.com, kyle.m.hall at gmail.com

I'm putting this out there, I'm not sure if the use case is something that
would work in all libraries or if I'm completely beside the point...

If the circulation rules are set to 'item returns home' and you do a manual
transfer (for whatever reason, like that library needed that book for a display
or something), when the other library receives the transfer, it is
automatically put back in transit to go back to its home library. Which is kind
of logical, but not? Why would you do a manual transfer if it's just to be sent
back?

I can see several use cases for this, outside of a floating collection
situation:
1) special display
A library wants to make a special display and asks the other libraries to send
some material over. This system does not have a floating collection policy, but
they still exchange materials depending on needs (e.g. holds). If the other
libraries send 'manual' transfers, the library making the special display
receives them by checking them in (this currently triggers a transfer back to
the home library), puts them on display. If a user checks them out and then
returns them, the transfer to home branch will be triggered. If no users check
them out after the end of the display, the library can send them back by
checking them in.

2) temporary high demand
A school board loans out textbooks at the beginning of each year. Some schools
have more students than others so they ask other libraries to send their
surplus of textbooks over to satisfy the demand. Again, no floating policy for
general circulation. The smaller libraries send their surplus textbooks via
'manual' transfers, the larger library receives the transfers by checking them
in (this currently triggers a transfer back to home branch). They check them
out to students who haven't had their textbooks yet. When the students bring
back the textbooks, the check in triggers a transfer back to the home library.
If the library received more than needed, they can send back the texts to their
home library by checking them in.

3) course reserves
Similar to the two previous cases. A university has a course and needs some
material from other libraries for course reserves.

4) biblio-mobile
Again no floating policy, but during the summer, the library system has a
biblio-bus going to local parks. All libraries temporarily contribute to the
biblio-bus collection, but they want their materials back after.

In all these cases, the collections don't normally float, the materials are
only needed temporarily, and there is not one specific user who requested the
materials through a hold. Are manual transfers not the way to go in these
cases?

I think there are two potential solutions to this :
1) receiving a transfer is either not done through checkin or the checkin to
receive a transfer does not trigger another transfer (if there is an unreceived
'manual' branch transfer, and the item is checked in at the destination
library, do not send back home)
2) add a 'cancel transfer' button to the transfer dialog (when the destination
library receives the transfer through a checkin, a transfer back home is
triggered, but the receiving library could cancel the transfer in order to keep
the item). Right now, you can only click 'OK' or 'Print slip'.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.